Det er femte året vi gjennomfører Bekk Christmas, men det er første året vi har samlet hele fagmiljøet under én paraply. Og for et fagmiljø det er. Folk har poddet, progget, skrevet om fag, personlige erfaringer, tutorials, kakeoppskrifter – for en vanvittig fin bredde vi har hos folka våre!

Vi i julegjengen, som i år har stått for orkestreringen av det hele, har hatt en fantastisk reise gjennom de siste månedene. Og i dag, på selveste juleaften vil noen av oss dele med dere vår toppliste over hva vi har hatt mest glede av med årets julekalender.



Kristofer Selbekk – Julegeneral, Mr. Delingskultur og Allvitende Bekker

Topp 2 favoritter fra julekalenderen:

Da gruppearbeidet vart digitalt

Subscription Pattern with Compound Components



Det beste med årets julekalender:

Gleden av å dele

Det å dele noe man har lært, oppleves ofte som veldig givende. Om det er noe man akkurat har lært seg, eller noen refleksjoner basert på ti år i bransjen, så føles det alltid gøy å få tilbakemeldinger på det man har levert. Allikevel så er det mange som ikke tør. Det er overraskende vanlig å tro man ikke sitter på kunnskapsom andre ikke gjør, selv om det motsatte er tilfellet.

Bekk Christmas er en plattform som gjør deling mer tilgjengelig for flere Bekkere enn noen gang. Over de siste 5 årene har vi delt over 750 artikler, podcaster, tutorials og workshops. Vi har fått bidrag fra både administrerende direktør og nyansatte, og folk som bidrar én gang, bidrar gjerne igjen. Å dele som en del av en stor, divers gjeng gjør det hele litt mindre skummelt, og får folk som vanligvis sitter på gjerdet til å hoppe ned og publisere.



Synergien av et mangfoldig fagmiljø

Bekk har siden vi starta i 2000 skilt oss ut ved å samle teknologi, design og strategi under ett tak. Den synergien vi merker når forskjellige fagmiljøer samarbeider, kan være skikkelig inspirerende!

Bekk Christmas er organisert av en liten gjeng ekstremt talentfulle fagfolk fra alle deler av Bekk. Det å kunne se hvordan nye idéer skapes, bygges videre på og puttes ut i den virkelige verden på løpende bånd er intet mindre enn inspirerende.

Det er ikke bare gjennomføringen som er tverrfaglig – i år samlet vi artikler fra hele fagmiljøet under én paraply. Det gjør at du kan utforske et spekter av forskjellige, sammenkobla fagfelt, uten å føle at du må velge en "UX-kalender" eller en podcast om innovasjon. Av og til handler innholdet vårt om alt sammen på samme tid.





Ola Claussen – King of design og inspirasjons-coach

Topp 2 favoritter fra julekalenderen:

Hva bør en designer kunne 

Facilitation: What's your style?



Det beste med årets julekalender:

Lære ved å lage noe

Jeg har alltid vært en dårlig student når det kommer til bøker og "lesing". De tingene jeg kan best er ting jeg har lært gjennom praktiske prosjekter eller ved å lære bort og forklart til andre. Teamer som jeg har måtte dobbelsjekke, lage presentasjoner om, og tenke gjennom hvordan man skal kommunisere til fremmede. En gang i året så dukker det en gyllen mulighet til å gjøre dette i Bekk. Julekalenderen er et faglig fristed for å lære enda mer ved at man kan lage noe til andre! En faglig julegave 🎁



Et utgangspunkt for drøfting

Det å høre andre sine meninger og tolkninger. Det å kunne være enig eller uenig. Det å kunne bli overbevist av noen og lære nye ting. Endre mening fordi man endelig har forstått noe man trodde man forstod fra før. Det at andre deler av sine faglige tanker og kunnskap er i mitt hode bare en start på en faglig drøfting. Om jeg synes det er bra, dårlig, nytt eller gammelt, har ikke så mye å si, for det dukker opp tanker og drøftinger som jeg lærer noe av hver gang.





Kirstine Gyring - Dronning av god stemning og Oppdrag(else)sleder


Topp 3 favoritter fra julekalenderen:

Hvor feil kan man ta?

Are you the bad apple?

Bygger du teamet, eller sosialiserer dere?


Det beste med årets julekalender:

Nisse på taket og lavterskel julemoro får folk med!

Den 26. Oktober stod det en 10 meter høy julenisse på taket av kontoret vårt. Det var signalet om at Julekalenderen var i gang! Ordet spredde seg, og omtrent 70 bekkere troppet opp på Skuret for å bli med på kickoff for julekalenderen. Noen var helt nye til kalenderen, mens andre hadde bidratt tidligere år. Jeg opplevde at alle hadde til felles en veldig nysgjerrighet for hva som skulle skje og hvordan de kunne bidra, selv om de ikke nødvendigvis hadde en plan klar for hva de skulle lage. Ideene strømmet på hele kvelden, og folk sparret med hverandre om ting som kunne være kule, morsomme og nyttige å dele. Det hjalp nok også på engasjementet at vi hadde julemat fra Strøm Larsen og en 10 meter høy nisse stående på taket.


Deling og felles juleglede gir Psykologisk trygghet

I hverdagen min fokuserer jeg mye på å bygge høy grad av psykologisk trygghet. Jeg har en sterk formening om at man gjennom psykologisk trygghet skaper høyere trivsel, motivasjon og engasjement, som igjen kan skape økt prestasjon. Dette støtter også boken Accelerate opp under (Bendik Edvardsen har skrevet om den her). Jeg opplever at Bekk Christmas bidrar til nettopp dette. Hvorfor? Fordi bekkere bidrar uavhengig av erfaringsnivå i julekalenderen med deres meninger, innspill, forslag, kompetanse og erfaringer. Og det er noe av det som gjorde at jeg automatisk sa ja til Kristofer da han spurte om jeg ville være med i julegjengen. For hvor kult er det ikke å kunne være med å tilrettelegge for at enda flere blir inspirert til å dele, lære bort kunnskap, og lære ny kunnskap av andre?



Vikki N. Walle-Hansen – Nissens lille hjelper og Merkevare-mamma

Topp 2 favoritter fra julekalenderen:

Halvor Mundal ( i samråd med Arnold Schwarzenegger) stiller spørsmålet: hvor redde bør vi egentlig være for AI, og hva vi bør si til våre robotic overlords når den tid kommer?

Ola Claussen har hacket døren til leilighetskomplekset sitt – les her for å finne ut hvorfor og hvordan har gjorde dette

Det beste med årets julekalender:

Tverrfaglighet + Sosialt = <3

Som julegjengens eneste forretningsrådgiver, og som egentlig ikke har spesielt snøring på tech har jeg hatt enormt glede av å jobbe med et tverrfaglig team. Det å sitte tett på de kreative design-prosessene, og se hvordan man bygger en teknisk løsning fra scratch har gitt meg masse ny forståelse og glede. Hver gang jeg møter nye folk i Bekk bli jeg like positivt overrasket over hvor åpne, engasjerte og inkluderende de der. I en tid hvor vi i lang tid har sittet på hjemmekontor, og endt opp å jobbe mye alene er det utrolig inspirerende å få bli kjent og lære av kollegaer som du ikke har møtt før. Derfor elsker jeg bekk.christmas og digger julegjengen. Så stor takk til Anders, Beate, Kirstine, Kristofer, Jørun og Ola for å gjøre høsten min så mye bedre!

Takk for i år, vi gleder oss allerede til neste desember!



From all of us, to all of you a very merry Bekk.Christmas!

Ever wished you chose a slightly different data structure for your structured content? Let's learn how to fix it!

Sanity is a great way to manage your content. You define your schema by focusing on the content, not how it's going to be presented. That makes your content super flexible when you're say, redesigning your site, or coming up with new ways to present it.

However, sometimes those redesigns and new platforms uncover a a new need, or you realize you didn't make the very best design decisions up front. It happens to the best of us.

But by the time you realize your schema shortcoming, you already have lots of content, and updating your fields manually isn't something you have the time (or patience) to do. So what are your options?

Changing your content in Sanity

Luckily, Sanity is made by developers who are just as bad at structuring data as you are. Therefore, they made two ways for you to safely change your data, without too much fuzz.

The first way to change your content does require you to halt any editing while your change your content. You download a copy of your dataset, change it in your editor however you like (like search replacing strings) and upload a new copy of your dataset. Any changes made in the meantime will be lost – but if you're the sole editor, or you're few enough to tell people to take a break for a few while you do your work, this is a totally viable approach.

You can read more about that approach in the docs, but this article is going to focus on the second, much more powerful way to change your content – sanity exec.

Meet sanity exec

Sanity ships with a very nice utility called sanity exec, which makes it possible to write and run scripts that change your dataset directly, without setting up a ton of boilerplate to authenticate first. You can change data while people are actively working on the content as well, and base your changes on GROQ lookups, for instance!

I'm going to share one of the migrations we did on this very site, and use it as an example. 

Our use case

We have a lot of content on this site, both in English and Norwegian. We wanted a way to set the correct <html lang /> tags and make the content filterable by language. Unfortunately, we didn't have a field for that.

We started by adding a field to our schema type, like so:

So now we have a place to save this information, and all new content we create will require you to fill it out.

Creating the boilerplate

To get started, let's create a new file in your studio folder called called migrations/fill-out-languages.js, and give it some empty methods for us to fill out later.

The strategy will be – create a GROQ query that specifies the n first elements we want to change, create the change we want to perform, perform that change, and loop this until our GROQ query doesn't return any elements.

Fetching documents

First, let's create a query that finds the first 100 posts that doesn't have a language specified.

If you're not very familiar with GROQ, there's a lot of great resources out there for you to learn it. I'd recommend reading the official documentation and the GROQ cheat sheet!In this query, I specify that I want all documents that has the type post, and that has a language field that is not defined. I then limit it to the first 100 records (that's the [0...100] part), and fetch the two fields _id, _rev and the plaintext content of our post.

Note - if you haven't seen the pt::text function before, that's fine - it's not a widely used feature of GROQ. You can read more about it (and similar functions) here.

Creating the change set

The next thing we want to implement, is to specify what changes we want to do with all of those documents we want to change. We do that by turning our documents into objects, with a predefined set of fields. Let's look at the code.



We set the ID of the document we want to change, and specify the change – or patch – we want to apply to that document. 

In this particular case, we want to set the language field to the correct value. You can also unset fields, by passing them as an array to the unset property.

We also specify the revision ID, which makes the transaction retry if a document has been changed since it was fetched. This is pretty cool, and makes these kinds of changes safe to do in a live studio environment with active editors. If somebody just edited a piece of content in the second between fetching records and processing them, we'll just try again the next round of fetching documents!

You might have been wondering how that figureOutLanguage function works. In our particular use case, I was able to just write a "simple" regular expression checking for the Norwegian special characters æ, ø and å. If they were found, we assume that the text is in Norwegian, and if they were not, we assume the content is in English. This won't be a 100 % match, but it will match enough records that a quick manual scan of all titles and languages will let us find the mismatches quickly enough. I asked Twitter what their preferred methods were, and got some really interesting approaches – like using the Google Translate APIs, or searching for the most common words – and if I hadn't done the migration by then, I probably would have followed their advice instead. However, quick and dirty did the job!

Migrating records recursively 😱

The next function we want to implement is the one that will orchestrate calling the functions we've implemented so far, until we're out of records.

Let's look at some code:



We fetch the documents, check if there are more documents to migrate, and if not, exit. 

If there are more documents left to migrate, we create the changes (or patches) we want to run.

Now, we have to create what's called a transaction. A transaction is a way to bundle several changes together, so that if one of them fail, we roll back the changes of all the changes bundled together. It's an old school database concept, so it's fine if you haven't encountered it before.

Now, to create these transactions, we are going to create a transaction through the sanity client, add all our changes to that transaction, and then return our transaction. There are several ways to do that, but I'm going to use a for loop.



Then, when we're done creating this transaction, we can wait for all of these transactions to finish by awaiting transaction.commit(). 

Note, that if you ever want to do a "dry run" of your migration (you probably should), you only need to comment out the transaction commit part of your code!

All together now

That's it - you're basically finished! Here's the complete script:



Running the migration

We've now written a great migration script. But how do we run it? Luckily, that's the easy party.

With any luck, this will run successfully, and data will be updated without disturbing your editors. Pretty cool!

Changing your data in Sanity shouldn't be a scary thing to do, and luckily, it isn't. The sanity exec method lets us create really nice looking migration scripts that in large part are reusable between migrations. 

Thanks for reading!

24-Dec

Today's posts

From all of us, to all of you a very merry Bekk.Christmas!

Migrating your data with sanity exec