Ferie. Endelig. Vi skal hjem, til hvit jul og til skiføre. Billettene er for lengst booket, inkludert ski. Den digitale reisen har gått som smurt, men nå ender den brått i innsjekkingsskranken på Gardermoen, med en motvillig SAS-ansatt i rubben. Hvorfor blir det slik, at inntrykket man har fått av et selskap digitalt, kan ta en helomvending i møte med mennesker og kultur?

Vi skrur tiden et par måneder tilbake i tid. Jeg booker flybilletter på nett. Legger til seter, bagasje og ski. Betaler. Jeg er ganske fornøyd med de nye nettsidene til SAS. Bestillingen gikk overraskende smud. Spesielt er jeg fornøyd med muligheten til å bytte ut en «vanlig» bagasje med ski i bestillingen, og dermed slippe å betale dyrt for spesialbagasje. Det nye mottoet er jeg litt undrende over. «We are travelers». Kombinert med ansattes reisetips. Et forsøk på å oppfattes som «på lag med kunden» antar jeg, at «sammen kommer vi oss ut i verden». Tja. Enklere booking gjør det for så vidt enklere å reise. Tenker jeg.

Vi hopper frem i tid igjen. Det er avreisedag og vi befinner oss på Gardermoen, der vi har blitt videresendt til SAS’ innsjekkingsskranke fordi automaten ikke spiller på lag. Nedenfor er et utdrag av samtalen som finner sted:

«Du har ikke booket ski»

«Jo. Det står her på billetten min. Innsjekket bagasje: Skibag.»

«Hvor har du booket den?»

«På sas.no»

«Er du sikker på at du ikke har booket et annet sted?»

«Ja jeg er sikker»

«Ok, vi får fikse det her»

...

«Da blir det 540 kr å betale»

«Hæ? For skiene»?

«Ja»

«Men jeg har jo lagt det til i bestillingen på nett. Det står jo her: 1 stk skibag!»

«Ja, men de er ikke betalt for»

«Neivel? Hvordan kan de ikke være betalt for? Jeg la de jo til billetten før jeg betalte?»

«Nei, jeg vet ikke»

«Men 540 kr? Det koster vel ikke så mye på nett?»

«Nei, det koster mer å betale på flyplassen»

«Men, de er jo bestilt på nett! Det står jo her på kvitteringen! Hvordan skal jeg kunne betale på nett hvis ikke skiene legges til betalingen når jeg bestiller!?»

...

Jeg stopper der. Klokken var tre, det var 40 minutter til avgang og jeg hadde ikke spist lunsj. Tonen eskalerte litt kan du si. Jeg opplever selv at jeg har gjort alt riktig: Jeg har brukt SAS’ nettsider. Lagt til ski. Betalt. Men det er hun i skranken som bestemmer om jeg får med meg skiene eller om jeg må sette de igjen på Gardermoen. Og det er jeg som har et fly jeg skal rekke og en sulten 2-åring hengende i buksebenet. Det er klart jeg betaler. Men det fikk meg til å reflektere over dette nye mottoet: We are travelers. Er vi egentlig det? Er vi på lag om å løse dette og få til denne reisen? Eller er det jeg som er den reisende, mens hun er den som lar meg reise? På nød og neppe, og på SAS’ premisser?

Når visjon, kultur og image ikke er i synk

SAS tjener her som eksempel på et problem som er velkjent nok til at det har blitt forsket på. De er på ingen måte alene om å havne i en situasjon der kunden opplever at det selskapet kommuniserer ikke står i stil til kundens faktiske opplevelse av selskapet. I artikkelen «Are the strategic stars aligned for your corporate brand» omtales visjon, kultur og image som tre strategiske stjerner som må være i synk for at man skal kunne lykkes med sin merkevarestrategi. Når disse ikke er i synk ender vi opp med gap som kan gjøre at hele strategien faller i grus.

Image-visjon gap

Ethvert selskap er en merkevare. Kundene har et bilde og inntrykk av selskapet, hva de står for og hva man som kunde kan forvente. Denne oppfatningen har selskapet begrenset kontroll over, siden den eies vel så mye av den som står på utsiden, slik som kundene, som de som sitter på innsiden og lager strategier. De fleste selskaper legger derfor betydelige ressurser i å markedsføre seg, for å sikre at kundens inntrykk av selskapet gjenspeiler visjonen. Dersom kundenes inntrykk avviker fra visjonen, har man et image-visjon gap.

Nikes visjon var å lage «high-performance athletic shoes» til toppidrettsutøvere. Så oppdaget de at halvparten av salget var til folk som brukte Nike som hverdagssko, og de lanserte dermed en egen linje med hverdagssko – som ingen kjøpte. Kundene kjøpte Nike fordi de ønsket å gå i samme sko som idolene sine, de likte atlet-imaget, og det var ikke før Nike innså dette at de virkelig kunne «sko seg» på visjonen sin.

Image-kultur gap

Men, kundens oppfatning av selskapet avhenger ikke bare av hva man kommuniserer ut gjennom mottoer og markedsføring. For å lykkes med en visjon, for eksempel at man skal spille på lag med kunden, må også kulturen, altså de ansattes verdier, holdninger og handlinger, gjenspeile visjonen. Dersom kunden opplever at de ansatte i selskapet gjør noe annet enn det selskaper formidler at de skal gjøre, har man et image-kultur gap.

British Airways lanserte en kampanje for å endre sitt image fra «The worlds favourite airline» til «The worlds favourite airline». For å kommunisere dette malte de flyenes haleror med kunst fra ulike verdensdeler. I det du satte deg på flyet møtte du imidlertid flyvertinner i tradisjonelle britiske uniformer som serverte engelsk tea i sølvservise. Opplevelsen de reisende fikk ved bruk av tjenesten var distinkt britisk, som ikke matchet det det imaget selskapet på forhånd hadde kommunisert.

Visjon-kultur gap

For at ansatte skal handle i tråd med visjonen, trenger du enten en visjon som bygger på selskapets eksisterende kultur, eller så må du jobbe med å endre kulturen slik at denne støtter opp om visjonen. Dette kan du lese mer om i Luke 10 der Thilde skriver om hvordan forme kulturen når man arbeider med strategi. Kultur spiser som kjent strategi til frokost, så hvis visjonen ikke er i synk med kulturen er det en risiko for at du ikke lykkes med å realisere visjonen og bygge det imaget du ønsker. Da har du et visjon-kultur gap, og visjonen var i beste fall en god frokost.

IBM var kjent for «livslang ansettelse», men iverksatte på 90-tallet en ny strategisk retning som krevde masseoppsigelser. Dette ledet til en intern vits om at IBM egentlig sto for I´ve Been Mislead. Strategien tok ikke hensyn til kulturen og verdiene selskapet var bygget på, og denne mismatchen skadet også IBMs image.

Hva har dette med flybilletter og ski å gjøre?

Jo, jeg opplever at SAS forsøker å kommunisere et nytt image, som antageligvis bygger på en ny visjon: We are travelers. Vi gir reisetips. Vi gjør det superenkelt å ta med ski på turen. Vi spiller på lag med kunden.

Men, her er det gap. Allerede da jeg så SAS’ nye motto oppsto et image-visjon gap. We are travelers. Det var ikke slik jeg oppfattet SAS. I mitt hode har SAS tilhørt den gamle skolen av flyselskaper, fra den tiden folk pyntet seg for å fly, som litt for lenge har holdt på gamle takter og stivbent regelverk. Jeg så ikke på de som et selskap som spiller på lag med kunden og gir en følelse av «vi». Men jeg tenkte også at dette nye mottoet var et friskt pust og en start på noe nytt, og håpet med det å se et mer moderne og kundesentrert SAS.

Men så skjedde dette på flyplassen da. Jeg hadde begynt å venne meg til «nye» SAS. Jeg var jo så fornøyd med bookingen, at det gikk så smud å legge til disse skiene. Men det hjelper så lite med fine motto og nye nettsider når du møter den samme, gamle stivbeinte holdningen i innsjekkingsskranken. Når den som skal hjelpe ikke har fått med seg at vi spiller på lag, at vi er sammen om å få til denne reisen, og du får følelsen av å måtte stå med lua i hånda og være glad du får fly i det store og hele. Her er det et image-kultur gap, og antageligvis også et visjon-kultur gap. Når de ansatte opptrer på en måte som hverken oppleves å være i tråd med imaget selskapet prøver å skape, eller den visjonen man må anta at ligger bak, da funker det ikke.

Kulturen har spist, og tilbake ligger kun smulene av det som kunne blitt en ny reise, sammen. Jeg heier absolutt på en ny og mer kundesentrert visjon, og håper SAS etterhvert lykkes med å bygge en kultur som støtter opp om det imaget de kommuniserer. Men akkurat nå føles det som jeg reiser alene.

Kan en merkevarestrategi gape over for mye? 

Remember the Global Surveillance Disclosures from Edward Snowden in June 2013? Of course. We all remember that faithful day when the world become a slightly more scary place, but also a bit more illuminated. What you might not remember, is the the widely publicized slide deck that the Guardian dubbed “Prism: the PowerPoint presentation so ugly it was meant to stay secret.” Top secret and scary? Certainly. Pretty and inspiring? Nope:

Well, I’ve been on my own journey of trial and error on how slides should look in order to captivate, entertain and, not least, inform the audience. Without the dubious joy of a TOP SECRET classification to protect me from prying eyes. As I divulged in my previous pre-holiday musings, experimentation has been a central theme for me when learning to embrace public speaking. So, let's have a look!

Basic: simple bulletpoints 👦

We've all been there! Standard template in Powerpoint, bulletpoints galore. Maybe even, for good measure, throw in some simple animations:

Obviously, it's not the most visually pleasing. But it gets the job done. It makes it easier for people to follow what you're saying, as there are pegs to help them focus their attention on the most important points you're making.

I often start with something like this to structure my thoughts and to get past the "OMG, I have NO idea how I'm gonna get this done" phase. But I very rarely end up with something looking like this.

Good for

Structuring thoughts

Those times when you've panicked and don't have time for anything else

Setting low expectations to your sense of esthetics

Gearing it up: bullet points with emphasis 🎯

If you've ever sat through an hour of slides like the ones above, you've probably noticed that it does very little to help your audience focus over time. Worse than looking dull, they give little information and does little to direct attention where you want it.

A simple step forward is to write out sentences a bit more, and for good measure highlight what would otherwise be the single point in a list:

This is usually my go to for short, to-the-point decision making type of presentations. If elaborated a bit further, they could also be used as handouts.

Good for

Summarizing contents without bells and whistles

Presentations that also need to be distributed afterwards

Creating quick presentations about a topic, with very little time spent on non-essentials

Captivating the audience: Photo time! 📸

I still remember the first time I saw a photo-centric slideset. I'd been working for about half a year, and I was totally doing basic bulletpoints in all of my own presentations. Then someone showed up with a set of quite vanilla stock photos. And it blew my mind.

Although visually pleasing, there are certainly times when loading up on photos isn't the way to go about it. It tends to give presentations a more lofty feeling, and for better or worse, it might pull some attention from what you're actually talking about.

Use photos that are related to what you're talking about if you can. But, alas, all presentations can't be about terroir and the ageing of wines. A time honored way of finding nice-looking free to use photos for presentation is Unsplash. Just remember to give credit to the photographer!

Good for

Visual and engaging story-telling

Captivating your audience

Distracting from your contents, intentionally or by accident

Mixing it up: emojis 🔥

Those who know me, know that I likeemojis. Emojis are a simple, if not necessarily tasteful, way of making your presentations more lively. They can be used to emphasize points, steer attention and set the mood for a given presentation.

The simplest way of using them, is just scattering them around in sentences and headings:

And once you start doing that, you can really go wild. Not saying that you should, just saying that you could:

Good for

Adding more life to simple presentations without too much work

Giving a more personal touch to your slides

Not looking professional

Let's get crazy: drawing! 👨‍🎨

For better or worse, a huge breakthrough for me was when I discovered the drawing tool in Powerpoint. It was one of those… moments. I was working in a weekend to get a presentation ready, I was getting a bit bored and was looking for something else. So, this abomination ended up in that presentation:

It can also be used for (slightly) more useful things:

Obviously, this isn't fit for all (or even most) situations, but I find it creates a really neat personal touch on light subjects.

Good for

When you want to add a personal touch

Lightening the mood with entertaining slides

Visualizing concepts, for example with technical drawings

Just because you can, doesn't mean you should: bring it all together! 🤠

You can probably see the trend here. And feel the worry: will he go there? And yes, I've went there. Before you judge: remember that all presentations have their context. Sometimes you want to teach, sometimes you want to preach, sometimes you need to win an argument. And sometimes you just want to entertain.

A relaxing opening slide: 

A much less relaxing opening slide: 

How to horizontally scale infrastructure: 

Good for

Creating stunning or surprising slides that capture people's attention by sheer audicity

Showing complex interactions and flow

Entertaining and creating emotion

So… now what?

So that's a brief intro to what I've been doing. And I'm pretty sure I don't really need to tell you that all of these are good ideas. Especially in all contexts. And that's the key word here: context.

I've used all the techniques described above with great success in the right context. And it's obvious that they could all crash completely when used at the wrong time.

In 12 years of giving presentation, my visual style has changed a lot. But most importantly, I've grown my toolbox. Sometimes I give straight up powerpoint presentations like everyone else, at other times I go completely bonkers with animations, drawings and everything else. Experimenting with what works and what's effective in a given context, makes creating presentations both more fun and gives a better effect over time.

So that's my message to you. There's more to giving presentations than standard templates and bullet points. Once you start opening that box, there's so much fun to be had!

The good, the Bad and the Hideous: experiments with visual presentation styles

There are many ways of structuring or designing your microservices. My thoughts on the matter are that there is no right way. However, there are some tips that I have experienced that I think are worth sharing, and that might fit your project as well.

1. Decompose the business problem.

The very first task I do when starting to design for microservices is to understand the business problem. Often, looking at what type of data we need to persist could give you a comprehensive understanding of the topic.

Let's have a look at an example. Your boss assigns you the task of building an e-commerce website (your boss must hate you if he or she ever gives you a job like that.). Nonetheless, we could start by looking at how we could structure/divide our microservices. Product Service - Will be responsible for holding all products. Inventory Service - Will be responsible for maintaining the inventory status for a product. Orders Service - Holds all the orders and their status. Shipping Service - Holds the shipping status and is responsible for shipping management. Payment Service - Holds all the payment/invoices statuses. Reviews Service - Holds the reviews from users regarding products. User Service - Holds all the user-related data, i.e., logins, passwords. With this approach, it becomes clear where all the data is supposed to be stored. For a new (or old) team member, it should be clear where they should implement a new feature. If a new feature doesn't clearly fit under any of those services, it might be a clear indication that it should probably have a microservice of its own.

I would also empathize that the current structure isn't necessarily the right solution one year from now, or even a couple of months. The project may change over time, but having smaller services, the transition from creating or removing an entire service, becomes far less the more sparse your services are.

2. Each microservice should be independent of each other.

There are probably many that say this, but I think it is important to empathize that microservices are what they are, namely MICROservices. They should not serve the application independently, yet they should handle their respective area or purpose alone, even if all other microservices are down.

To achieve this, it is essential that the building, deployment, and hosting of the microservice should not require any other services. By that, I mean that it is ok, for instance, to have an aggregated logging service that consolidates the logging from each service. I encourage that you have some system to handle logging like described in the 12-factor app. However, there should not be any code in each microservice that enables this behavior.

Centralization is your enemy when dealing with microservices. You should at all cost avoid any "Common Packages" that each microservice depend on to function. They are a big anti-pattern. Don't be afraid to duplicate code to mitigate this.

3. Datastores should never be shared between microservices.

A microservice is, in many ways, a sealed system. It has some entry points that abstract away the data storage and logic inside of it. Therefore, it should have some clearly defined API's for accessing and manipulating the data inside the service. Another service should never be allowed to access the same database directly. However, a microservice could consist of many separate processes that use the same datastore, for instance, a web api and a cron job. In those cases, I think that there are many does and don't. My takeaway from this is that if you manipulate data from two different parts of the microservice in the same way, then any side effects should be dispatched the same way.

When it comes to sharing data between microservices, there are many ways to share data and keep it updated. The easiest right out of the gate might be to use a managed solution like Azure Service Bus. However, there are other open-source solutions like, for instance, Rabbit MQ that might be an as good or even better solution for you.

4. Communication between each microservice.

In the perfect microservice environment, there is no synchronous communication with any other microservice. Instead, each microservice uses an event stream or bus to dispatch events whenever an action has taken place. Notice the past tense there. Ideally, we should never perform any synchronous communication with another microservice. If you can't find any other way, then the correct way might be to duplicate the data and store it within the context of both microservices.

Sometimes, it isn't to avoid having synchronous communication between two microservices. In those cases, I think you should restrict yourself to only doing as little as possible. Most likely, there may be another solution to your problem, but you should also know that in the real world, there is nothing as a perfect system.

5. Use containers

When it comes to building, deploying, and operating/hosting a microservice or an application. I can't think of anything simpler and more versatile than a container. It doesn't matter what container technology you use; there are many out there, some of being Docker and LXD. The idea that you build it once and run it anywhere is a dream come true to me.

There might be a steep learning curve to containers, but you don't need to know everything to get started. I think that just getting started is pretty straightforward and you should be able to expand from that idea to whatever floats your boat. In a previous post, I showed how you could use Docker with Github Actions and Dockerhub.

Another advantage of using containers is that you most likely will be using the "Build, Release, Run" principle of the 12-factor app by default. Meaning, you have an immutable build that is configurable through environment variables. Thus, combined with multiple environments, like testing, staging, and production, will ensure that you have the same codebase in all places.

Bonus - Cloud Native

The Cloud Native Computing Foundation is a foundation that, in short, works towards helping organizations and individuals creating modern, scalable, and robust applications. I think to say that their work is good is an understatement. They provide tools, guides, and certifications in many relevant topics. I would suggest that you get to know this foundation and at least have a look at the project they deem "Graduated projects". I think you will know what to do next after that.

Succeed with your microservices

When I studied computer science for five years there was a lot of mathematics. Equality was probably the simplest part. After ten years of working, I’ve done a lot of JavaScript. Equality is not the simplest part… Why?

First of all, JavaScript has two operators for equality: == and ===. In order to understand equality, we have to understand the difference between these two options. As we know equality from other programming languages and mathematics, === behaves the way we are used to.

So, if you’re able to keep == away from the JavaScript-codebase you’ll probably save yourself from unnecessary heart disease. Unfortunately, sooner or later we have to make changes in a codebase where == is commonly used - then it’s important to understand the consequences of making changes!

x == y

There are a lot of rules to be aware of when using ==. Let’s take a walkthrough of these rules and try to understand them by some examples.

1 If x and y is the same data type the behavior of == is the same as ===

This is a rule that can make refactoring == to === a bit easier. If you expect both values to be the same data type - add another equal sign and breathe!

2 Truthy if x and y is undefined and null

null and undefined are special cases and we have to accept that they are equal when using double-quotes. But I’m not sure if I like it...

3 If x and y are the data types number and string - try to convert the string into number and perform ==

If one value is a string type and the other is numeric, JavaScript compares the numeric value of the string. Remember, converting an empty string to a number results in 0.

4 If x or y is a boolean type - convert it to a number and perform ==

Boolean values converted to a number type results in 0 (false) or 1 (true). Be aware of the second line, after converting false to 0 the comparison is now a numeric and string data type. Fortunately, you have just learned how this works!

5 If x and y is respectively an Object and either String, Number, Bigint or Symbol - convert the Object to primitive and perform ==

Converting the data type object into primitive is usually done by returning the value of valueOf()-function. If this is not implemented or does not return a primitive value, then it returns the value of toString()-function.

6 If x and y is BigInt and Number then return true if the mathematical value is the same

7 If none of the above applies, return false!

As mentioned above, avoid using == in your JavaScript code. Unless all of the rules above fits in your, and your teammates, head - please use ===!

"JavaScript" != "Javascript"

In yesterday's post, we learned about inbound ports in Elm. Today, instead of receiving a message, we want to send a message from our Elm application to the outside world that is JavaScript.

At some point when writing an Elm program we might have the need to communicate something from inside our application to JavaScript, and as we have learned that is exactly the function of ports in Elm. We use ports to be able to bridge the world between JavaScript and Elm.

The first thing we will need to do in accomplishing sending a message from our application is to define our outgoing port.

From the definition of the function we can see that this simple port will send out a String value. We will send messages through this port when a user clicks a button in our application.

So how do we connect this outgoing port to our code in the Elm lifecycle? We will start by writing the view code where this button resides.

In this view we have a Html.button that when clicked, causes the update function to be called with the MsgSendOutgoingMessage.

The update function proceeds to call the port and supply the String that will be received in JavaScript. On the Javascript side we will be receiving the messages in the index.html file that we learned about in yesterday's post.

The message sent from Elm will be received in the above javascript function, and inside this code block we can proceed to do whatever we want to do with the information received from Elm.

We might want to send out a little more complicated messages than just a String type. In these other cases we can use Json-encoder to turn the desired Elm values into a json structure.

Outbound ports

When I first started out with Typescript I found it very difficult to create the correct types when making generic components. In this article we will create a generic Table component that can be used with any set of objects.

This article assumes you already have some basic knowledge about React and Typescript.

Lets get started!

I will be using a data set of cats.🐱 The cat objects will look like this:

But you can use any kind of data set you like.

The Table component takes in data and columns as props, then renders a TableHeader and TableRows. I will get back to those shortly. First lets take a closer look at the props defined in TableProps.

<T, K extends keyof T>

T means "any type is ok". In our case T will be the cat object. K extends keyof T means that K is a valid key of T:

We see that the K is used as a type for our key property. This means that key can only be one of the properties we have in our cat object: 'name', 'age', 'favoriteFood'...

The data that we send in is an Array<T>, so in our case an array of cat objects. But as I said, it could be anything!

Finally, the Table component returns JSX.Element. This is what a function component normally returns and you often don't have to define this return type as typescript will be able to guess the return type for you.

Custom headers

Lets look at the TableHeader component. It takes in columns as props, and the type definition is the same as for our table component.

By using our columns definition you can decide the order and width of each column without having to alter the data set in any way. If you want 'age' to be displayed before 'name' in your cat table, then all you do is define that in the columns definition. You can also decide to only display some of the properties in you data object.

Lets look at TableRows

It takes in both data and columns as props.

{row[column.key]}

We create each row by mapping though our data set (our list of cats 🐱). For each cat object we use the columns definition to pick which properties should be placed first, second, third... in our table. We do this by calling row[column.key]. Row is our cat. If column.key returns 'name' then this is the same as saying cat.['name'] or cat.name.

Putting it together

Now we are ready to use our Table!

We start by defining our data set which is of the type Cat[].

Then we must define how we'd like our columns to be displayed. Maybe we just want to show some of the properties. We could make a columns definition like this:

And then we send the data and columns into our table:

Now you can play around with the columns definition. Add the other properties from our cat object and define different widths for each column.

<Cat, keyof Cat>

When we create the columns definition for our cat object we see how the <T, K extends keyof T> is used with the specific definition: <Cat, keyof Cat>. In your columns definition try to alter the key: 'name', to key: 'Name' (capital N). Typescript will give you an error because "Name" is not a valid key of our cat object! This means that if you rename the properties in your data set typescript will let you know that you also have to rename the key property in your column definition! It's amazing!😻

A note on keyof

The keyof type is one of my favorite parts of typescript. When making the ColumnDefinitionType you might have wondered why we didn't do it like this instead:

To illustrate the difference let us look at these two, seemingly similar, functions:

These functions do the same thing. You send in an object and a key, and the functions returns the value for that property. So if we send in our cat object from before with the key 'name', we should get the name of the cat in return. Let's try it with the first function:

It gives an error! But we know that the name property is a string, so calling toLowerCase() on it should work, right 🤔? Not exactly. Because the type of our key is not linked to the 'name' property the function doesn't know which type it should return when we do obj[key](cat['name']). It could be any of the types defined within our Cat type: string | number | undefined.

If we call the second function however

We don't get an error! Because now there is a link between the type of the obj[key] and the key. Because the property 'name' is a string, cat['name'] will also be a string.

I hope you had fun making this Table component with me, and that you learned something new about typescript 😊

Create a generic table with React and Typescript

Det mangler alltid et punktum eller en hjelpetekst. Knappen er ikke helt midtstilt og det finnes skriveleifer her og der. Det er for lite eller for mye avstand mellom noen elementer, mobilversjonen avviker litt fra desktopversjonen og det er for lav kontrast på teksten i dark mode. Dette er eksempler på småfeil som fort oppstår. Hvorfor er det viktig å få fikset disse feilene? Og hvordan kan vi holde oversikt over dem og få de prioritert slik at de blir fikset?

Småfeilene nevnt ovenfor er det kanskje primært teamet bak tjenestene som er klar over, men hoper de seg opp over tid vil brukerne også etter hvert legge merke til dem. Min oppfatning er at for mange småfeil får tjenestene til å fremstå som uferdige. Dette igjen skader troverdigheten og i verste fall skaper utrygghet hos brukerne våre.

Jeg leste et sted at det er fort gjort å tenke at hvordan noe ser ut kun handler om noe overfladisk. Men når ting ser bra ut påvirker det hjernen din rent kjemisk. Stoffet dopamin, som gir følelsen av glede og velvære, frigjøres i kroppen vår. Jeg har ikke undersøkt om det finnes troverdig vitenskapelig forskning som understøtter dette. Men et kjapt googlesøk på “UI design dopamine” konstaterer likevel at dette blir påstått av flere, og ved å skumlese noen av artiklene virker det også som at dopamin kan knyttes til motivasjon. Det er fristende å dra den enkle slutningen at dersom tjenestene vi lager ser bra ut kan man fremprovosere produksjon av dopamin, som igjen øker motivasjonen til brukerne våre.

Uttrykket at noe “ser bra ut” kan bety så mangt, det gjør egentlig litt vondt å bruke det. Jeg synes det er et platt uttrykk, men akkurat til denne artikkelen fungerer det fordi uttrykket i seg selv også gjør det generelt, det handler om hvordan noe oppfattes visuelt. En tjeneste uten masse småfeil vil jeg påstå er en del av det å “se bra ut”.

Hvis vi da velger å være enige om at det er viktig å ikke feie alle småfeil under teppet trenger vi en oversikt over dem på en slik måte at de blir prioritert og deretter fikset. En kollega i Bekk tipset meg for noen år tilbake hvordan de løste dette i deres team. Løsningen var en egen oppgave som het UX-gjeld. En løsning jeg siden har videreført i alle team jeg har jobbet i. Fellesnevneren for disse teamene er et board, eller en tavle på godt norsk, hvor oppgaver flyter fra venstre til høyre avhengig av hvor i prosessen oppgaven befinner seg. UX-gjeld-oppgaven beveger seg ikke, den blir stående i kolonnen “Klar til å jobbes med”. Reglene er enkle: Hver gang man oppdager en feil som er “liten nok”, det vil si tar maksimalt noen få timer å fikse, så blir det et nytt punkt på listen i UX-gjeld-oppgaven. Hver gang en utvikler har litt ledig tid eller bare har lyst å jobbe med en litt lettbeint oppgave, kan de velge fritt hvilket punkt på listen de ønsker å ta tak i. For deretter å stryke det ut og opprette en egen subtask, eller deloppgave om du vil, som kan flyte gjennom boardet.

Som designer er denne listen super å ha fordi jeg, men også resten av teamet, har et sted å notere alle småfeil som oppdages. Det er godt å vite at vi har kontroll på dem selv om de ikke alltid blir fikset med en gang. Vi trenger heller ikke å diskutere prioriteringen av oppgavene, da utviklerne selv prioriterer å ta tak i dem når det passer. Utviklerne virker også fornøyd med å ha en slik liste, og flere har gitt uttrykk for at det er godt å kunne plukke noen lettbeinte småoppgaver og føle at det går unna. Slik får teamet strøket ut flere oppgaver på en liste i løpet av en dag, noe som føles utrolig godt når man normalt sitter med komplekse oppgaver som fort kan ta en uke eller to å løse.

Dukker det opp masse småfeil her og der i tjenestene du også jobber med? Og er det vanskelig å få de prioritert? Ja da fikk du kanskje et bittelite tips på bittelille julaften her.

Takk til Jonas, Anne Berit, Erik & Hanna for gjennomlesning og innspill. Og takk til Stian, kollegaen som ga meg tipset.

Et bittelite tips på bittelille julaften

In a chaotic, pandemic-ridden 2020, we've seen a heated debate on the need for efficient contact tracing that still respects privacy. There are many aspects to this debate — this blog post covers how one can submit data anonymously, while still providing a verifiably authentic upload token.

This year, governments, academia and industry rushed to introduce a number of smartphone-based contact tracing solutions. While all tried to make contact tracing as efficient as possible, they paid varying degrees of attention to their citizens’ privacy and anonymity. The Norwegian authorities also aimed to generate insights on how the regulatory measures influenced contact, hoping to know what was most effective.

As the summer of 2020 started, most solutions converged on using the Google/Apple Exposure Notification System (ENS), which enabled access to Bluetooth Low Energy even when the phone is inactive, but only on firm privacy requirements. Here, we explore recent cryptographic techniques to improve users’ anonymity in the newly released version of the Norwegian contact tracing app Smittestopp. This work is inspired by the Privacy Pass protocol which we introduced yesterday.

Anonymous Token in Smittestopp

Health authorities are trying to respond to the COVID-19 pandemic in multiple ways, including using smartphones to trace close contacts. The idea is that one could alert contacts in case of possible risk of infection. The dominant solution is the ENS, which in turn is largely based on the DP^3T initiative.

In ENS, phones within short range exchange codes, named “diagnosis keys”, and store them locally in case they maintain this distance for a certain time period. In case of infection, the health authorities can provide a person with an upload code, which enables the patients to upload all codes sent from their handset anonymously to a public bulletin board. Every other user can then access the bulletin board, and check if any of the codes corresponds to any of their locally stored ones.

As the Norwegian Institute for Public Health (FHI) announced their initial plans for a new version of Smittestopp (litt. translation: "Infection stop"), Eivind Arvesen questioned whether the suggested token system could trace users. After verifying that this indeed works, Tjerand Silde and Martin Strand wrote a note (Norwegian text only) describing how anonymous tokens can improve privacy while providing the same functionality as the suggested token system. The improved version is inspired by Privacy Pass, designed for anonymous web-browsing. Based on the above note, FHI encouraged a pull request to the official project. Henrik Walker Moe then joined the team to create a library on Anonymous Token implementation as an Open Source project. Several others helped integrate the library into Smittstopp. While the anonymous tokens will not be included in the app’s first version release on 21 December, we are optimistic it will come to a phone near you soon.

How it works

Using Smittestopp’s infrastructure and our notation for Privacy Pass, one could use anonymous tokens to ensure their uploads are private. Note that tokens could still be correlated using timings, so authorities should refrain from extensively logging requests.

The sequence of anonymous tokens in Smittestopp will be:

FHI generates public and private keys, and distributes the private key k to Fhi.Smittestopp.Backend and Fhi.Smittestopp.Verification. The app only gets the public key K.

Fhi.Smittestopp.App generates a request P from (t, r), and lets the user identify themselves against Fhi.Smittestopp.Verification.

Fhi.Smittestopp.Verification verifies the infection status, and generates the response (Q, (c, z)) based on k and P, where the latter two constitute the transcript of the zero-knowledge proof of correctness.

Fhi.Smittestopp.App verifies the proof, generates the tuple (t, W) from t, r and Q and submits it to Fhi.Smittestopp.Backend.

Fhi.Smittestopp.Backend verifies that W is generated from t and signed with the secret key k. It then stores t for as long as k is valid.

From presentation (in Norwegian): https://tjerandsilde.no/files/Anonym-Smittesporing.pdf.

A previous blog post discussed how privacy was handled in the first version of Smittestopp. We are happy to report that privacy has been a central aspect of the new app, and was endorsed by FHI. We believe that this work should be readily available for other countries' COVID-19 apps as well, and hope that this process also serves as a demonstration of how an open approach can bring in valuable contributions and expertise.

Finally, the interested reader can find a demo-version of our protocol written in Go at github.com/tjesi/anonymous-tokens, and a professionally built library in C# at github.com/HenrikWM/anonymous-tokens.

Anonymous Tokens for Private Contact Tracing

Kotlin has a restricted menu of collection types available. Basically, it boils down to Set, List, and Map (even though Maptechnically is not a Collection), whereas java seemingly has a much larger lineup. For example, java's List interface has implementations like Stack, Vector and LinkedList. On top of that, the kotlin collection interfaces have less features than their java counterparts.

One rationale behind this design choice is probably platform interoperability - simpler interfaces would allow kotlin code to be more easily compiled down to javascript, mobile platforms, or other languages and virtual machines. Another reason is that extension methods and properties allow kotlin to add a lot more features to the various collections without "polluting" the interface. Finally, the corresponding java interfaces are all mutable, with methods like add and remove, while kotlin has explicit interfaces for mutable collections, like MutableList, MutableSet, and MutableMap. This is a cleaner, more readable alternative to the Unmodifiable* wrappers for the java.util.List interface in java.

Under the hood kotlin uses the corresponding java classes, and a bit of compiler magic to ensure that the types effectively seem to implement the kotlin interfaces, known as mapped types. Runtime, however, there is no difference between the java and kotlin counterparts. There is a couple of big benefits with this approach: first, instead of implementing new collections natively in kotlin, the battletested implementations of java can be used. Second, interoperability between java and kotlin is ensured. And it means you can still use thejava.util.Vector class, and get the extension goodies associated with the kotlin Collection and List interfaces in kotlin.

It goes the other way, too: if you decide to make an implementation of the kotlin List interface yourself, the compiler will replace it with java.util.List, and supply the missing method implementations itself, all throwing an UnsupportedOperationException. In other words, the kotlin collection interfaces are somewhat of an illusion.

Generally, it is a good idea to use factory methods for creating collections. Examples are listOf, setOf and mapOf, and the corresponding mutableListOf, mutableSetOf and mutibleMapOf for the mutable variants. It leaves your code less dependent on concrete implementations, which may or may not be portable across platforms, and open for future improvements to the default implementation.

Using mutableListOf will in the end give you an instance of java.util.ArrayList, while listOf returns an java.util.Arrays$ArrayList - a lightweight, read-only wrapper over an array. Except if the list is empty, which in the immutable case will give you the singleton EmptyList - a nice example of a simple optimization done for you. In the same vein setOf and mapOf will return LinkedHashSet and LinkedHashMap, respectively, and exactly the same in the mutable case. The linked versions ensure that the collections will be iterated in the same order as the items were added to them, but both of these have a higher memory footprint than HashSet and HashMap would have. If you need to deal with large sets or maps, this could be an issue, and you would want to use the more specialized factory methods, like hashSetOf and hashMapOf.

An interesting observation is that since the underlying type is the same for mutable and immutable Sets and Maps, the compiler will gladly accept a change to an immutable collection

which will print [B, C, D].

The fact that a collection is mutable, is not the same that the variable needs to be mutable. In fact, the opposite is closer to the truth. Consider

A mutable collection can (and should?) be assigned to a read-only variable. Even though the variable cannot be reassigned you can freely modify the collection. You would in principle expect better performance by modifying the contents of a single collection, rather than creating new instances from scratch (but is a premature optimization until you actually hit a performance problem, of course)

All in all, kotlin's handling of collections is a pragmatic compromise between interoperability, reuse, and readability. The result is robust, high-performing implementations, sleak interfaces, and an abundance of extensions to make your developer experience festive and joyful.

If you want to learn more about immutabiliy, have a look at this year's calendar's very first entry.

Collection magic

When I first started learning functional programming, I had already been programming for many years, mostly in object oriented languages the last decade. How would the architecture for a functional program look like? How can we avoid mutation, which is a cornerstone of OOP? How can functions be used as an abstraction?

Introduction

In this post, I'm going to show the design of a functional program which solved a difficult problem while being easy to get right and performant. By avoiding mutation, we were also able to implement "time-travel" to look how an action would affect the future, easy rollbacks and stale data detection.

In OOP, there are often deep call-stacks, which I consider a smell itself, and mutation of state and side-effects often happen at a deep level. When constructing an application which should be mostly pure with immutable data, we have to push the side-effects up the call-stack to the outer boundary. This means that we need to return to the caller rather than keep diving deeper in the call-stack.

To recap some terminology:

pure
Given the same arguments, it returns the same result. And it has no effect (other than generating heat) on the outside world. This means no visible mutation, and no visible side-effects.

immutable
Once a value is set, it cannot be changed. "Mutation" is done by constructing a new copy rather than modifying in place.

side-effect
A modification to state outside the local environment.

There are some key parts in the architecture I'm demoing here:

State
A record containing all state in the application

Operation
A small language of verbs which describes changes to State

ApplicationEvent
Some external event which should trigger changes to our state

Handler
A function which maps from an ApplicationEvent to an Operation

You don't need an event driven application to take advantage of the architecture in this post. Using just immutable state with pure functions to change the state, will still yield most of the benefits. Having events and a custom language might be a nice addition, or it might be over-engineering.

Given the above parts, the flow of the application is then:

Something triggers an ApplicationEvent

Handlers translates to Operations

We run each Operation on the State, producing an updated State

We use the new state for fun and profit

When the new state is produced, we can act on the result by interpreting the changes. We might validate the changes. We might save to the database. We might detect stale data by rerunning the application. We might use it for transactions. Our production implementation does all this, not just without any side-effects or mutation, but because there are no side-effects or mutations. We can safely rerun things, throw away things, copy, interpret results, and there are never a chance of introducing an error outside of our changes – Changes in one place can never affect something else.

Smaller demo

We'll go through the key parts of our Small demo. More/different comments are in the actual source file, so I encourage you to look there as well.

The demo will model changes to an Order Line in an online shopping chart. It's probably completely overkill for such use, but it's difficult to create good examples – see an actual use-case in the Large demo.

We can Add an OrderLine, we can Increment and Decrement the count, and we can Remove an OrderLine. To make things a bit more interesting, I also added a Reset and Add with another initial count than 1.

We'll use an integer as a unique id for the OrderLine, and a integer for the actual count and initial value.

Defining a custom language for our domain

We encode the possible operations on an OrderLine using a Discriminated Union (also called a Sum Type). These operations are the verbs in our domain, and our Embedded Domain Specific Language (EDSL) for manipulating OrderLine items.

Only Set is needed to support our described operations, but we create some more constructs in our language. Putting more in the language will make mapping events to operations simpler as the language is more expressive, at the cost of a more complex language. It's difficult to decide what goes in the language, and what should only be helper functions. If you need to distinguish between different operations (e.g. increment vs set) when interpreting the operations, having them as separate operations might be a good idea.

Application state as an immutable record

The State is where we hold information about all OrderItems. The state includes things necessary to execute our lanugage. In addition, we keep things which is convenient for other usecases, but could in theory just as well be held in other structures. The Audit field is a list of all operations which has been executed, which makes it easy to do things like maintaining an audit log, persisting changes, detecting stale data, rollback transactions, and so on.

Our last field, LastPersisted, is state for the interpreter which persists changes to disk. Depending on the interpreter and application, this state might be better to keep separate.

Having a single structure makes it easy to have a clean architecture without much boilerplate (just State -> State functions), but it can be difficult to find out what information is used where, and who changes what. As with any decision, it's a tradeoff, but having a simple architecture might be more beneficial than a clean separation of state – remember, there is no mutation or side-effects in the functions which operates on the state!

Helpers for "manipulating" state, i.e. State -> State functions

As you start creating mappings from ApplicationEvent to Operation, you'll quickly see patterns repeating for state querying and manipulation. I like to extract these to helper functions as I go. For our demo, I've created three helper functions.

Notice that the design here is to "never fail", and rather just return sensible defaults instead. This of course depends on the application, but this demo is modelled after our production application, which should never fail to process an event.

Interpreting our language and executing on State

With the helper functions, we're now able to process our language. We'll look at each operation, and manipulate the state accordingly. As a final step, we log the operation we've executed. Even though we "execute" the language, we're not mutating any existing state or doing any side-effects. We're creating a new state as we go. It's thus important that we use immutable/persistent datastructures that's fast for such use, and that we're using them correctly e.g. by prepending to the list rather than appending.

You might notice a print inside here, and scream SIDE-EFFECT! And yes, it's true, but it's for demo purposes, and you shouldn't do this :)

Interpreting our language and auditlog to persist to database

Now that we have a way of changing the state, we can write an interpreter that runs side-effects. This simulates writing to a database. Remember that this interpreter has its state in State, so it has to return a copy of it. In Haskell, this would be a State -> IO State function as it has side-effects, but in F#, we just do side-effects without help from the type-system. The interpreters can be made more efficient by avoiding unnecessary work. [Add 1, Remove 1] can be reduced to a noop.

Mapping application events to our custom language

We still haven't hooked our implementation up to the outer application, but let's do this now. The key part is our Handler function which does the mapping. It can access the state in case it needs to look at anything, and it returns an Operation option in case the ApplicationEvent should trigger a change in the state. An alternative implementation could return Operation list instead to support 0+ rather than just 0-1. For events which should trigger more than one change, we can just write multiple handlers, which is what we did in our production application. In retrospect, a list would have been more expressive, and might have made some mappings more readable.

Given an event has happened in the application, we need a way to run this through all possible handlers, accumulating the changes. This implementation runs in sequence, where each handler will see the changes done by the previous. Depending on the use-case, you might want to run them in parallel, merging the result, or similar.

When we write handlers, we'll quickly notice some patterns, and we can write helpers for these. As the handlers are functions, the helpers are in the form of Higher Order Functions, which means functions that takes functions as arguments and/or returns a new function as the result – our helpers does both. For our usecase, we'll define two functions to avoid writing too much type-casting. Our production application has helpers down to the operations as many different events should trigger the same operations.

Now we can create the mappings themselves. As our language is complex, the handlers are simple. If the language was much smaller, complexity would have to be pushed into helper functions and/or handlers. This is a tradeoff, and there is probably no right or wrong answer. Think about how this would relate to the programming languages you know. Simpler programming languages, pushes the complexity to the users, while in more expressive languages, the complexity can be hidden in libraries. We're using the helpers here, but there's nothing wrong with dropping down a level when needed.

Our events is very simple

And as the events map nicely to our language, the handlers are also simple.

Demoing our implementation

And that should be everything needed to support our application. We can test it by running some events through the system. We first create a couple of orderlines and does some changes to them. We then persist the result, and finally do some more changes and persist again. We'll see that the second persist will only process the new changes.

The output from the demo application

Concluding remarks

This concludes our little demo, with an architecture which is pure, immutable, and side-effect free. The side-effects is pushed to the boundaries, making the core of the application easy to test and make bug free. Check out the repository for some code and the larger demo based on the production application. If you're interested in learning more about F#, I wrote a short post with various useful links at the Getting Started With F# calendar post.

A Functional Architecture Demo

Smidige produktteam fungerer godt for inkrementell innovasjon, men er det også en god tilnærming til radikal innovasjon?

Mats Knutsen-Valen, Jens Andreas Huseby og Moquan Chen tok en prat med Marit Andreassen, som er Head of Product Engineering i Vipps.

22-Dec

Today's posts