Bekk Christmas is the culmination of decades of iterating on sharing culture. Let's dive into what this is, and how it came to be.

Bekk Christmas is entering its fifth year, and with it, a fresh new take on how we share what we know. 

What is Bekk Christmas?

Bekk Christmas is an annual tradition, where we share some of the favorite things we've learned the last year, through opinion pieces, tutorials, podcasts, deep dives and lots of other formats. We focus on what we know, which is typically something about technology, design or strategy – sometimes all at once.

Each day in December, we'll share a curated selection of articles, podcasts, talks and whatever other format we felt like. Pick the ones that seem interesting to you, and consume them while you're commuting, relaxing, working or pooping. 

You'll also find hundreds of other articles, tutorials and podcasts on this site, available through either exploring our archives or using the nifty search feature.

Either way, we're sure you'll find something useful, interesting and fun here. We hope you enjoy.

What's the history behind Bekk Christmas?

Bekk Christmas didn't start out as Bekk Christmas - it started with going domain shopping over a few glasses of wine. Kristofer Giltvedt Selbekk started his React lead career by purchasing react.christmas, hacking together a solution in CodeSandbox, and publishing 24 short articles about React in 24 days.

React Christmas picked up some traction, and when the next holiday season arrived, three other competency leads wanted to join in. A tradition was born.

The following couple of years, Bekk Christmas turned into a company-wide project, with 23 calendars and 552 pieces of content. Each with their own .christmas domain! At one point, the owner of the .christmas TLD even asked to sponsor us for bringing so much traffic to their fringe TLD.

To us, this is such a great symbol of our company culture. We love to share, love to learn and can't wait to share it with you.

What's different this year?

Previously, we had a ton of different domains, like react.christmas, ux.christmas and strategy.christmas. It was a fun approach to get started, but we soon noticed that it came with its own set of issues. We had to make sure we had 24 days worth of content for each topic, which made a lot of people stress out. In addition, we had to maintain ownership over tons of fringe domains forever. Not great.

To alleviate this, we've moved all content to a single platform, with a single domain – bekk.christmas. It's still the same concept, but you can find all our content in a single place.

We've also rewritten the website from scratch, and moved all of our content into Sanity's wonderful content platform. We're super excited to show it all off.

Who is Bekk?

If you don't live in Norway, you probably don't know who Bekk is. That's completely fine. Bekk is a 500+ people consultancy that specializes in technology, design, strategy and management consulting. 

We've been around since 2000, and work with some of Norway's largest clients to help create solutions for millions of users. Without being too corporate-y, we think.

If you live in Oslo or Trondheim, and are looking for a job, please send us your resume!



Merry Christmas!

Finally, we just want to wish everyone a merry Christmas. Or happy holidays, if Santa isn't your jam. We hope you find some cool stuff, and share it with your network if you did. 

👋 

Kristofer, Vikki, Jørund, Kirstine, Ola, Beate and Anders
The Christmas Crew

Welcome to a brand new Bekk Christmas

Have you ever inspected an object in your browser's console and stumbled upon the field [[Prototype]] or __proto__. Or maybe you have seen someone use the mystical prototype field on classes, such as String.prototype. Ever wondered what kind of sorcery this prototype is? Great! ️This article will hopefully make things a bit clearer, and make you an advanced prototype wizard. 🧙‍♂️

Categories of Object-Orientation

For us to understand what prototypes are we are going to have to talk about categories of object-orientation. Hold on! Before you close this article, I promise this isn't going to be one of those articles that go into the nitty-gritty of programming language theory. I intend only to poke at the surface of the rabbit hole, so this should be digestible by anyone who has basic knowledge of object-oriented programming. 

Still here? Awesome! Let's briefly look at two different categories of object-orientation, namely class-based and prototype-based object-orientation. 🤓

Class-based vs. Prototype-based Object-Orientation

Class-based and prototype-based object-orientation are categories referring to how inheritance is handled in the language. In class-based languages, such as Java, inheritance is defined in the class definitions through super-/sub-class relations, while in prototypical languages, objects inherit properties directly from other objects.

What does that even mean? Well, instead of JavaScript having classes that contain the objects' shared properties, such as methods, JavaScript instead uses other objects to store this. These objects are what we call prototypes. So all instances of the same "class" in JavaScript will share the same prototype object.

Why does JavaScript use Prototypes when it also has Classes?

Here's the cool part, there aren't really any classes in JavaScript! 🤯

The class-syntax in JavaScript is just syntactic sugar for creating a prototype and an object-constructor function. Confused? Let's look at what this means. 

The following example shows how you could implement a Santa class in JavaScript. The Santa class has some property hasEatenCookies which is set in the constructor of the class. In addition, we also have a method to check if Santa is hungry. 🎅🍪🤰

Since JavaScript doesn't really have classes, this would be transformed into a prototype object and a function for constructing Santa objects, like the following:

Note: This is a somewhat simplified example of a class transformation, if you would like to see a more complete transformation you can check out this Babel REPL.

As we can see, the methods of the Santa class has been put into a normal object, while the constructing of objects has been made into a standard function. The santaConstructor function simply creates an object with the hasEatenCookie property, and the object is then assigned the santaPrototype.

How does Inheritance work with Prototypes?

It is actually quite simple. Since prototypes themselves are just objects, they can themselves also have prototypes. So if we made a subclass, BadSanta, of our Santa class, this would result in our BadSanta prototype having the Santa prototype as its prototype...

That was a lot of prototype at once. Let's instead look at some code. Below we have implemented our BadSanta class, which introduces a method to check if BadSanta cares if you've been naughty or nice.  

We could then create an instance of BadSanta and call the methods from both our BadSanta and our Santa class.

What is happening here is that for every time we try to reference an attribute on an object, there's a check performed to see if the attribute exists on the object. If it doesn't exist it will do the same check on its prototype, recursively.

So when we do willie.isHungry(), JavaScript will check if isHungry exists on the object willie. Since willie doesn't have any attribute with that name it will check its prototype, BadSanta. BadSanta doesn't have this attribute either, so it will check its prototype, Santa. Fortunately, the Santa prototype has this attribute, and we can use this function for our function call.

That's it!

As we have seen, prototypes aren't all that mystical. They are just objects used to share properties between objects, such as the methods we would define in a class. We also saw how inheritance is handled in JavaScript, where class-based languages has classes with superclasses, JavaScript instead has prototypes with parent prototypes. This is possible since prototypes themselves are just objects.

What are Prototypes in JavaScript?

Jeg jobber som UX-designer i et team som lager digitale tjenester, og jeg ønsker at flest mulig beslutninger i teamet skal tas ut fra et brukerperspektiv. Ikke alle. Men de fleste. Og sjansen for at det skal skje, øker hvis alle i teamet forstår brukerens opplevelse av tjenesten.


Her er en liten påminnelse jeg selv trenger. For at en skal kunne ta brukerens perspektiv, må en prøve å sette seg inn i brukerens situasjon og behov. En må ha kunnskap om brukeren og hvordan tjenesten oppleves. Så hvordan får hele teamet kunnskap om brukeren?

Først vil jeg fortelle om én måte å involvere teamet i innsiktsarbeidet. På den måten jeg har gjort det mange, mange ganger.

Se for deg at du som designer skal presentere noe

Designeren står foran teamet. Forteller brukerens steg gjennom en flyt. Fra en blir bevisst at en skal gjøre noe, til en har oppnådd det en skulle gjøre. En tjenestereise. Ofte ganske kompleks. Det er jo mange ulike “hvis sånn, så sånn”. Det er kanskje mange aktører inni bildet. Men det er blitt enklere å forstå ved å bli kuttet i små biter, og satt i system.

Se for deg en av de som hører på - for eksempel en av utviklerne i teamet

Brukerens reise blir presentert. Kanskje det er en flyt av postit-lapper. Og noen skisser. Det er mye ny informasjon. Mye detaljer. Flere, “hvis sånn, så sånn” og “hvis sånn, så ikke sånn”. Det er interessant. Det er lærerikt, ja, men det er vanskelig å få med seg alle detaljene. Dagene går og etter masse annet arbeid, så er det vanskelig å huske alle disse detaljene som ble presentert.

Dele innsikt

Det jeg ønsket som designer var å involvere teamet i brukerinnsikten gjennom å dele, men det betyr ikke nødvendigvis at jeg klarte å legge tilrette for læring. Jeg har kanskje glemt litt hvordan det kan være å sitte på mottakersiden av en presentasjon over en slik flyt. Det er ofte veldig mye kompleksitet. Mye ny informasjon. Mye viktige detaljer. Jeg har i det siste reflektert litt over hvordan man tilegner seg ny kunnskap og lærer best.

For å øke kunnskapen din om et tema - Hvordan lærer du best?

Jeg lærer best ved å jobbe med materien. For eksempel etter et intervju, å dykke inn i det vi har snakket om. Lese notatene igjen. Trekke ut det viktigste. Kanskje visualisere det i en historie om brukeren. Kanskje sette det inn i presentasjonsformat. Å trekke ut noen hovedfunn som kan deles på Slack. Å kna innsikten gjentatte ganger. Det er gjennom denne gjentatte “knaingen” av innsikten at jeg faktisk lærer mye. At kunnskapen setter seg, og at jeg kan bruke det når jeg skal argumentere for valg i designet av tjenesten. Kunnskapen om brukeren setter seg i ryggmargen.

Jeg husker best hvis det blir knyttet følelser til temaet. Som den første gangen jeg fikk observere noen bruke det vi hadde laget. En følelse av å være litt flau. Og litt stolt. Og veldig engasjert til å få dette digitale produktet til å bli enda bedre.

Eller den gangen en person gråt på intervju på grunn av en vanskelig situasjon i livet. Jeg forsto litt bedre hvordan konteksten og livet påvirket bruken av tjenesten.

Eller han som var med på en brukertest, som hadde så grove hender fra tungt fysisk arbeid at det var vanskelig å trykke på små taster på mobilen.

Dette var for mange år siden. Jeg husker disse brukerne enda.

At hele teamet er involvert i innsiktsarbeidet

Tilbake til historien om utvikleren som hører på at designeren prøver å formidle brukerens reise. Jeg har vært den designeren mange ganger. Og det kommer helt sikkert til å være meg også mange ganger i fremtiden.  

Men, jeg skal gjøre mindre av det. Jeg skal gjøre mer av det som virkelig kan bidra til å øke teamets kunnskap om brukeren. Først gjennom å snakke med teamet om viktigheten av at alle vi i teamet forstår brukerens reise gjennom det digitale produktet vi lager. Og, ved å involvere hele teamet til alt av innsiktsarbeid. Invitere med utvikler og produkteier i intervjuer. På observasjon. På analysearbeid. Det burde være en selvfølgelighet, egentlig. Det er ikke nødvendigvis det at alle alltid skal være med på alt. Ikke at hele teamet skal ha akkurat de samme arbeidsoppgavene knyttet til brukerinnsikt. Men at designeren gjerne tar rollen som fasilitator for at hele teamet får brukerens perspektiv inn i ryggmargen. Flere valg og bestluninger blir tatt ut i fra å ha brukerens beste i sikte. Og slik blir de beste tjenestene designet.

For hvordan lærer du best noe komplekst?

Mindre “lære bort”, og mer “lære sammen”

It's easy to think of software security as something related to code, but we must remember that it is equally as much a question of people. Security must not become a purely technical exercise. The human factor is central, but can often be the most difficult thing to address. Let's look at how we can create a security culture, and how this can be an important part of your security work.

Photo by Cherrydeck on Unsplash

What is a security culture?

Before we talk about why we need a security culture and how to create it, we should define what it is.

A security culture is a culture where:

security is given focus and attention

everyone sees security as part of their job

security is a natural part of all work that is done

questions and curiosity is central

making errors is ok

We want to create a workplace where all of these are present and central to being a part of the company. While some of these factors are quite obviously part of making a company more secure, some of them might not immediately strike us as important for security.

Why is it important that making errors is ok? Making errors in security tends to be bad, should we not foster an environment where making errors is discouraged? While I'm not saying that we should make mistakes on purpose, I am saying that we should not punish, admonish, or in any other way discipline those who make them. Making mistakes is human, and everyone at your company will make mistakes, small or large. How we treat people when they make mistakes is critical in forming their actions, and how they try to fix their mistake - or hide it.

Why security culture?

A security culture is an essential part of any organisation that creates anything that requires any amount of security. If you process personal information, create physical products for the medical sector, or just need to ensure that competitors can't copy your newest ideas, you will most likely rely on multiple layers of technical security measures. But these are worthless if the people in the organisation can easily be tricked into clicking some phishing links, will let anyone into the building, or just don't understand the reason for the security measures, and find workarounds.

We create a security culture because we recognise that any system that has a human component, has humans as part of their security model. As such, we must secure also these human parts of the system, and that is best done by creating a security culture.

How to create a security culture?

Creating culture is extremely difficult. If you have ever tried, you will know that you can't just tell people "In this company, our culture is to be kind to one another". Sure, that might plant a seed for some people, but culture is a fluent and dynamic thing. It evolves in the interconnectivity between people, and only a continuous effort can steer it in a specific direction. I believe that the four most important things a workplace can do to promote good security culture is the following:

Focus on security awareness

First and foremost, I believe that security is more about awareness than anything else. Security in the digital information age is extremely complex, and most people have no intuitive concept of information security. Continuous training, small everyday tips, and a general focus on security in all tasks, not just those that are directly related to security work, is needed to ensure that everyone feels that security is part of their jobs. When something is talked about by everyone in an organisation, regardless of role, leadership responsibility, and responsibilities, it becomes part of the identity of the company.

Create a feeling of safety

People need to feel safe in a workplace in order for a security culture to work. We are asking people to ask questions and be curious about a difficult and abstract field. This will lead to a lot of questions that people will feel are "stupid", and we will have to explain basic concepts. Unless everyone has the necessary psychological safety, you will never be able to create a security culture.

Ensure slack in the workday

Unfortunately, making sure our products are secure takes time. Time that could have been spent on new features, customer support, or other improvements. Most teams have more tasks than they could conceive completing. Stacking a pile of security related tasks on top of this is often not possible. We need to create enough slack in the workday for the team to be allowed to think about, discuss, and work on, security.

Promote good leadership

All the previous points require one thing: Good leadership! However hard employees might try, they can not by themselves create the necessary focus on security in all parts of the organisation. They can not create the psychological safety needed, and it is their bosses that must create the slack in their workdays. This is, as all leadership, an ongoing process. Do not fall into the trap of thinking that once a good security culture has been established, it will sustain itself indefinitely. If you take your hands of the steering wheel, do not be surprised if these success criteria vanish before your eyes!

What does good security culture look like?

I feel that the project I currently work at has a well above average security culture, so I thought I would share some stories that show what good security culture might look like in a normal workday.

As the head of security, it is my job to ensure that we work every day to make a more secure product. But I can't do that alone, it requires that everyone is onboard. When a new feature is developed, the first time I usually hear of it is when a developer from the team in charge reaches out to me. Usually, I get a description of the feature, and then some reflections on the security implications, if any controllers are to be implemented to mediate some of the risk, and questions they might have. 

Almost always, this conversation starts because the team have thought about security when designing the feature, and decided that they need to make sure that they have thought about all relevant issues. Sometimes we follow this conversation with a formal security review, sometimes the changes are so small that it's not necessary. But the most important thing is that the security of the feature has been thought of from the start, making it integrated into the solution, not slapped on top at the very end.

Security culture also relates to the non-technical interactions we have. Such as when there is suddenly someone in the office, wearing work clothes and appears to be working on the ventilation system. Most places, this would be something that is briefly registered before people return to their work. 

We instead have people immediately asking the worker who they are, and what work they are doing. Then, our office manager is called to validate that we or the building owners have indeed ordered the work to be completed. This ensures that someone can't just show up at our offices looking like a contractor and walk around undisturbed.

Finally, when your security culture is good, people are not afraid to ask questions when something seems a bit off. I get lots of questions that start with "I don't think this is something dangerous, but I want to make sure". This is excellent, both because some of the things people experience are actually things we would like to do something about (phishing, unusual requests from vendors etc.), but also because there is a lot of learning for everyone in these situations.

Make your security culture better today!

If you read this and want to do something about your security culture - you can! Look at the 4 factors I have mentioned that are part of creating a security culture. 1) Focus on security awareness, 2) Create a feeling of safety, 3) Ensure slack in the workday and 4) Promote good leadership. Spend a couple of minutes thinking about how your company could improve. Perhaps you could send a short security email once a month about a relevant topic to the entire organisation? Or maybe as a leader you can ensure that developers have the time in their day to patch those security flaws they know about, but never get around to fixing?

Building a better culture is not about monumental actions, or large transformations, it is about the small conscious steps we take every day to move in the direction of a more secure company.

Creating great security culture

Drypp er en lavterskel podcast fra Bekk. I denne episoden snakker vi om nudging.

Hva er nudging? (Del 1 av 3)

Vi snakker jul, julekaker og maskinlæring!

Det nærmer seg jul nok en gang og lukten av nystekte julekaker brer om seg i det ganske land. For et par år siden satt vi i den samme situasjonen og funderte på hva vi skulle bake dette året. Selv om de syv slag er tradisjonsrike julekaker så er det lett å kjenne behov for litt fornying på kakefatet. Vi tok derfor på oss oppgaven ingen hadde gitt oss – å lage det 8. slag til jul.

For ordens skyld (selv om du selvfølgelig husker dem😉) er de originale sju julekakeslagene: Sandkaker, Pepperkaker, Fattigmann, Goro, Berlinerkranser, Krumkaker og Serinakaker. Disse kakene i tillegg til en rekke andre julekaker og «juleaktige» kaker ble datagrunnlaget vi startet med i vår søken etter en ny julekake. Heller enn å stole på egen intuisjon og konditorferdigheter besluttet vi at det enkleste ville være å benytte maskinlæring til jobben.

Desember 2019 ble preget av mer arbeid foran pc’en enn over grytene, men til slutt var det klart for å lage og teste den nye julekaken. Vi regnet den som en gigantisk suksess, men vi rakk ikke å fortelle hele omverdenen om den nye kakens fortreffelighet før 24.desember. Merkelig nok var det ikke så mange som startet julebaksten på selveste julaften, og to år senere har ikke det 8.slag jul fått det store nedslagsfeltet i den norske julekakefolkesjela som vi håpet. Det ønsker vi å gjøre noe med og henter derfor frem hva vi gjorde og hvordan oppskriften ble, slik at du kan bli med oss og lage Norges nyeste og beste julekake!

Planen vår var enkel. Vi baserte oss på julekakeoppskrifter vi kjente fra før og ville bruke maskinlæring til å lage en oppskrift som var både ny og innovativ, men likevel inneholdt kjernen av det som gjør en julekake til nettopp en julekake. Mer presist brukte vi et nevralt nettverk basert på åpen kildekode, textgenrnn. Den kom ferdig trent ut av boksen, og den kjørte i Google Colab, som gjorde det lett å trene den på nytt på våre julekakeoppskrifter.

Vi hopper her lekent over alle detaljene om hvordan et nevralt nettverk virker, men om du er interessert i dette anbefaler vi å lese litt rundt på våre tidligere blogginnlegg. Det viktigste du behøver å få med deg er at modellen ble trent på store mengder generisk tekst fra rundt omkring på Internett. Dette gjorde den i stand til å produsere noe vi kjenner igjen som tekst, og ikke bare en tilfeldig strøm av tegn. Når vi så trente den på våre oppskrifter, bruker den det den allerede har lært om generisk tekst og tilpasser vektene i modellen til våre spesifikke tekster. Slik får vi et nevralt nettverk som ikke bare kan produsere noe som ser ut som tekst – det kan rett og slett produsere julekakeoppskrifter!

Skal en lære modellen hva en julekakeoppskrift er, blir det litt snaut med de vanlige sju slagene. For å få noe mer data å trene på, la vi hodene i bløt og fant fram til 25 forskjellige kaker vi på en eller annen måte anser som juleaktige. Dette er fortsatt ikke all verden med data, men i alle fall betydelig mer enn sju. Selv om mye er ferdig i modellen som den er, måtte vi ty til en del fikling og eksperimentering med parametere for å få et brukbart resultat. Vi skal ikke gå inn på hvorfor vi satte rnn til 256, kjørte 1000 iterasjoner og valgte en modell på ordnivå og ikke tegnnivå. Kortversjonen er at modellen etter hvert begynte å produsere tekst som dette:



Her kan man merke seg temperaturparameteren. Den angir hvor mye tilfeldighet modellen baker inn i resultatet. Et lavt tall gir lite innslag av tilfeldighet, og fører typisk bare til teksten «2 teskjeer kardemomme», eller noe annet som er veldig vanlig i de fleste julekakeoppskrifter.

Etter 1000 iterasjoner begynte resultatet å se nokså lovende ut.



Dokumentasjonen til textgenrnn er tydelig på at man ikke kan forvente perfekt tekst og at det ofte vil være nødvendig med noe manuell justering i etterkant. Vi kjørte derfor modellen 10 ganger og valgte den oppskriften vi hadde mest tro på som et utgangspunkt.

300 g mel

0,5 dl melk

0,5 dl kremfløte

150 g rosiner

2 ts kardemomme

1 sitron

175 g sukker

100 g smeltet smør

2 ss brandy/likør

1 egg

Vi valgte denne oppskriften fordi den har en betydelig andel tørre ingredienser (mel og sukker), væske (melk, egg, kremfløte og smør) og interessante smaksingredienser (rosiner, kardemomme, sitron og brandy). Et fantastisk utgangspunkt for en julekake.

Vi bestemte oss for å se hva slags rolle ingrediensene vanligvis har i sine oppskrifter og baserer vår fremgangsmåte på at:

Mel er vanligvis basen og blandes med resten av de tørre ingrediensene, i dette tilfellet sukker og kardemomme, før væsken tilsettes.

Smeltet smør blandes gjerne med sukker og avkjøles før det tilsettes blandes med resten.

Fløte, melk og egg blandes sammen med smør og sukker.

Sitron tilsettes som regel for sitt smakfulle skall, og tilsettes sammen med melet og de andre tørre ingrediensene.

Brandy tilsettes sammen med resten av væsken.

Dette gir oss følgende bakeinstruksjoner:

Smelt smør og bland inn sukker. La blandingen avkjøles.

Kremfløte, melk, egg og brandy blandes sammen og tilsettes avkjølt smør og sukker.

Riv skallet til sitronen og bland inn mel, sukker, kardemomme og rosiner.

Dette gav en fast og fin deig som kan formes i ulike figurer om du ønsker det, før de stekes på en langpanne på 200°C til de er gylne. Slik ble resultatet:





Og der har du det!

Det 8.slag julekake. Vi har besluttet å kalle den for Bekkstang, da den garantert knekker i gang julestemningen i heimen! Bak dem gjerne avlange for maksimal innlevelse! Smaken på kakene var helt nydelig, og vi vil si at bruken av sitron og brandy er rett og slett genialt!

Vi håper du har lyst til å prøve denne oppskriften for å friske opp det tradisjonelle julekakefatet. Men først og fremst håper vi at dette innlegget har inspirert deg til å utforske mulighetsrommet som ligger i maskinlæring: Det finnes ingen grenser for hva man kan få til dersom vi bruker fantasien! I dette tilfellet kunne vi i tillegg brukt maskinlæring for å bestemme formen på kakene, fremgangsmåten og navnet på kaken, men vi ønsket også å vise at det ikke krever all verden av jobb å lage noe som er litt morsomt – og i dette tilfellet, veldig smakfullt!

Lykke til med både baking og maskinlæring!

1-Dec

Today's posts

Welcome to a brand new Bekk Christmas

What are Prototypes in JavaScript?

Mindre “lære bort”, og mer “lære sammen”

Creating great security culture

Hva er nudging? (Del 1 av 3)

Det 8. slag jul