Most web apps fetch data from a server. Fetching data from a server means that we don't have any data to put in our model when we initialize our app. In this article we will examine different strategies of modelling our app state when working with data from the server.

Dummy Values

We will start with an example to illustrate the problem. Let's say we are building an app that will fetch a list of articles from a server as soon as the app starts up. Our first approach might be to make a model like this:

This looks good, But we have to initialize the model somehow, and since we don't have any articles when starting off (because we haven't made the request yet) we would have to initialize the model like this:

This looks fine, but this strategy does pose some problems. One problem is that there is no way to know whether we are still waiting for the server to respond, or whether the server has responded, and there actually are no articles. You could imagine a user being a little scared if we display a message saying "There are no articles" for a second, before we actually get the articles and display them. The user might think that all their articles have been deleted, before realizing that the server was just a little slow to respond.

A Loading Field

One way to distinguish between a request that's still loading, and a request that returned an empty list is to add a loading field to our model, like this:

We can then initalize the loading field to be True, and when the request is finished, we set the loading field to be False. That way we can show nothing, or maybe a loading spinner, until the request is done.

But "loading" and "not loading" are not the only two states our app can be in: what if the request fails? In that case we would have to set the loading field to be False, since we are no longer loading, but then the user would definitely think that all their articles were gone. Even if the problem was only that the user lost their internet connection for a second.

An Error Field

To solve this issue, we could add another field to our model, called error. This field could also be a Bool, and be set to False unless the request failed. But maybe we want to keep the actual error in our model, to display different error messages depending on what kind of error we got? In that case we could make the error field a Maybe Http.Error, and if the error field was Nothing then the request succeeded (or is still loading), and if the error field is a Just Http.Error, then the request failed:

This solves our problems, but is kind of unruly to manage. Imagine for instance that we needed to make 3 network requests in our app, then we would have to have 9 fields to manage all this state, which would make the model a little bloated and hard to deal with. Also, there is another problem that this approach causes.

Impossible States

This is an example of a model state that is valid, as far as the compiler is concerned:

But what does this mean? We have a list of articles, but we also have an error. Did the request succeed or fail? Your guess is as good as mine. And what about this one:

We are still loading, but we have an error? How did we manage to do that? I don't know, but there is probably a bug that makes this happen.

How our app responds to these models is anyone's guess, but it's a recipe for disaster. And while we could just be extra diligent, and double check that we never end up in this state, wouldn't it be better if it was impossible to end up in this state?

Making Impossible States Impossible

In Richard Feldman's brilliant talk from 2016, he explains the concept of making impossible states impossible. Or said in another way: to make sure that only valid states are representable. Our approach thus far does not achieve that.

The problem is that we have three fields that can be changed independently, but that actually are dependent on one another. To solve this, we can replace all three fields with just a single field articles, of type RemoteArticles, which we define like this:

This one custom type allows for all the states that we want to be able to represent, and does not allow for any of the states that we want to be unrepresentable. The article request is either loading, or it has failed with an error, or it has succeeded, in which case we have a list of articles.

To use our articles, for instance in the view, we just have to pattern match on the articles field:

This approach serves to both simplify our code, by getting rid of multiple fields to handle one state, and to remove the possibility for a class of bugs in our app.

Conclusion

Modelling remote data with a custom type is a powerful technique, which can be adapted for different scenarios, depending on your app. You could for instance add a variant for NotAsked, if a request is only triggered by something else. And if you need the result of multiple requests before rendering something, you could combine the states for multiple requests in one custom type.

The Elm package directory has a package for RemoteData, which contains a custom type and some helper functions, but I usually prefer to make my own when using this pattern in Elm. However you decide to do it, I hope you try out this technique for modelling remote data in Elm.

Remote Data

Vipps er blitt allemannseie, men legger stadig til små og store nyvinninger. Som brukere kan vi nå pakke inn pengegaver i virtuelt gavepapir, vi kan betale regninger ved å ta bilde av dem og vi kan til og med få uknotete telefonabonnement fra Vipps. Hvordan rigger Vipps seg for så høy endringstakt?

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

Hva gjør Head of Product Engineering i Vipps?

kotlin.time is a small, experimental library introduced with Kotlin 1.3. Its main purpose is to simplify measuring and manipulating elapsed time.

A central class is Duration which is similar to java.time.Duration, but offers more syntactic sugar to simplify operations on elapsed time. In combination with extension properties and operator overloading, you can write things like

which will print 177687us. Another nice feature is the ability to decompose a Duration into convenient parts using toComponents

However, the library is perhaps most useful if you want to measure the duration of some block of code when executed. measureTime to the rescue

Or, if you need to return a result from your measured block of code, measureTimedValue is an alternative

Under the hood measureTime and measureTimedValue uses the corresponding functions on the underlying TimeSource. By default Monotonic is used, which is a TimeSource Implementation on top of System.nanoTime(), which is the monotonic (strictly increasing) clock in Java, and therefore the most robust way of measuring elapsed time. There is also a TestTimeSource implementation that can be used if you need to control the elapsed time for testing purposes.

TimeSource has a single function, markNow(), which returns a TimeMark. The TimeMark provides methods for checking how much time (as Duration) has passed since the mark, creating offsets from the mark, and checking if a marks has occurred or not.

kotlin.time is nice, little library which simplifies measuring and manipulating elapsed time compactly and robustly. It is still experimental, and its features can change (and has in the past). But if you are about to sprinkle your Kotlin code with large amounts of java.time.Duration, consider using this little native gem instead.

It's (Christmas) Time for Kotlin

This article will introduce an important and interesting concept in functional programming: Monoids. The focus will be on monoids in Haskell.

This article will introduce an important and interesting concept in functional programming: Monoids. The focus will be on monoids in Haskell.

What are monoids?

Monoid is a concept that comes from abstract algebra, where it is defined as : a set equipped with an associative binary operation and an identity element.

A binary operation on a set is a function that takes two arguments from the set and produces another one. Being associative means that the grouping of parentheses does not matter. For a binary operation <>, that means that x <> (y <> z) === (x <> y) <> z.

An identity element is an element of the set where mempty <> x === x and x <> mempty === x. So, it is kind of an "empty" element, that is "ignored" by <>.

Translated into Haskell:

A Set ==> A Type a

binary operation ==> a function <> :: a -> a -> a

identity element ==> mempty :: a

So, implemented in Haskell it could become:

This was how it was defined earlier, but now this class is split into two: Semigroup and Monoid. A semigroup is just a monoid without the identity element part, a monoid is then a semigroup with an identity. So now it is:

(When I refer to a "monoid instance" later in the article, I mean both the semigroup and monoid instance for a type, not just the monoid instance).

Basic Monoids

Let us start with some basic, but common and useful monoids.

Sum and Product

When we want to get the sum of values, we can use Sum. Sum is a monoid for numbers where the binary operation is addition (+) and the identity element is 0.

If we instead want to multiply values we can use Product. Here the binary operation is multiplication (*) and the identity element is 1.

But how do we use this on multiple values, like combining all the elements in a list using <>?

Foldable

Haskell has a type class for data structures that can be folded, called Foldable. To be folded just means to combine the values inside the structure, which is exactly what we want to do when using monoids.

What this function does is to apply the a -> m function on every a in the t a combining all the resulting m values using <> and uses mempty when the foldable is empty.

This a bit abstract, so let us see some concrete examples. Let us first look at lists:

We can see that foldMap f [x0,x1,x2,x3...,xn] === f x0 <> (f x1 <> (f x2 <> (f x3.... <> f xn))). But since <> needs to be associative, these parentheses does not matter, so it is the same as : f x0 <> f x1 <> f x2 <> f x3.... <> f xn

Maybe is also a foldable container.

When we don't need to transform the values inside the Foldable, we can use the fold function.

Now we have seen how to fold data structures using monoids, so let us take a look at some more monoid instances.

Any and All

All and Any are Bool newtypes for monoid instances for (&&) with mempty = True and (||) with mempty = False, respectively.

They can be use to check that any or all elements in a foldable container satisfies a predicate.

Bool can also be made into a monoid using the xor-operation.

Min and Max

When we want to find the maximal value, we can use the Max monoid.

For miniumum, we use Min.

As we can see, the identity element for Min is maxBound and Max is minBound.

This means that if we fold an empty container, we get a value which may be confusing in some cases.

Instead we sometimes want to represent this "failure" using Maybe.

Lifting a Semigroup into a Monoid

If we take a look at the Maybe data type: data Maybe a = Nothing | Just a, we can see that it can represent a set of values (Just a) with an additional element Nothing.

If the a's are monoids, we can combine them using <> and then chose Nothing as our identity element. In other words, we embeded a semigroup in a monoid by adjoining an identity.

The monoid instance for Maybe implements this idea:

We can use this to fold into a semigroup. An example of a semigroup that is not a monoid is First, which has the semigroup implementation a <> _ = a, meaning that it will always pick the left argument. There is understandably no identity element for this semigroup, but by using Maybe (First Int) we use Nothing as our identity. We have now created a monoid from the First semigroup, and can therefore use it in a fold.

Back to our "problem" with the min/max identity elements: If we now wrap up our type inside a Maybe, the result is more sensible.

Lists

Lists are monoids with (<>) = (++) and mempty = [].

In fact, the list is an important monoid, called the free monoid. This comes from the fact that if you take the requirements for a monoid and create the minimal structure needed to satisfy these requirements, you end up with list monoid instance.

Tuples

A very neat property about monoids is that they compose over products. Which in practice means, that if you have two monoids, you can combine them in a tuple, and then that tuple is also a monoid.

(This is also implemented for tuples of size 3,4 and 5)

This makes it easy to accumulate multiple monoid values in a single fold. We can use this to find the minimum, maximum, length, sum and product of a list, all in one pass in a neat way.

And for another example: Let us say that we have a list of x y coordinates and want to find, the bottom left and top right corner, i.e. (min x, min y) and (max x, max y).

Ap - Lifting a Monoid inta an Applicative

Applacatives have a strong connection to monoids. In categoory theory they are called lax monoidal functors. Every Applicative gives us a monoid, by defining (<>) = liftA2 (<>) and mempty = pure mempty. This is the instance for the Ap newtype.

We see here how <> for regular lists, just appends the lists toghether, but <> for Ap [] combines every element in the first list with every element in the second list, which mirrors the applicative instance for lists.

As we have seen earlier, in the regular Maybe monoid, Nothing is the identity element. Moreover, the applicative instance for maybe short circuits when you encounter Nothing. Because the monoid instance for Ap Maybe inherits this behaviour, the second example ends up being Nothing, but in the first example the Nothing is "ignored".

There also exists another applicative instance for lists, namely ZipList, which combines elements pair-wise.

Set and Map

Both sets (Data.Set) and maps (Data.Map) have monoid instances, with their respective union as the binary operator and empty as the identity element.

As we can see, the Map monoid instance only keeps the values from the left map when encountering duplicate keys. Often we would like to combine the values instead. One alternative in this case is to use Map.unionsWith instead of <>

But sometimes we actually need this to be a monoid instance. The appendmap package provides a newtype AppendMap for exactly this purpose.



Haskell - A layman's deep-dive in monoids

I work on the internal applications in Bekk, including a front page that shows key information about employees and the company. One of the sections shows upcoming birthdays, so you can congratulate your colleagues on their big day. But something was missing. You know, that little extra that tends to light up people’s faces. How about some confetti bursting out the top of your head? 🎉

The goal was to make it as simple and quick as possible. No flashy frameworks, just plain HTML, CSS and JS. You can see the final result below. Let’s take a closer look at how it was made.

On our internal front page we have a carousel with employees, sorted by birthdays. Every upcoming birthday boy or girl has their own “card” in the carousel, with their image on it. Let’s say each card looks like this:

For simplification, let’s say that each employee object consists of three properties:

We can then define a method that's applied to every employee in the carousel, to check if they should have confetti or not.

We want to attach the confetti to the card if their birthday is today. First, we need to get a hold of their card in the DOM. Luckily, the DOM API provides us with the method document.getElementById(). Since each card in the DOM uses the employeeId as its id, we can do the following to get a hold on that card:

This enables us to manipulate the element in the DOM. We can append child elements to it during runtime!

What is confetti, anyway? Isn’t it just a collection of many small, colored dots, spread in multiple directions? That doesn't sound too complicated. And you guessed it – that’s exactly what we’re going to make next!

First, we create a new element, and add a className for styling:

Time to look at some CSS. If you're not familiar with the variables we have used, I'll explain that below. We define the styling for each dot, and an animation to go with it:

Okay, so we provided some custom variables to our style by writing var(--name). This allows us to vary the colors and animated motions of the dots. Now, we need to define these custom variables in our code to be able to access them in the CSS. They are defined in JavaScript using the style property of the dot element, supplying a property name and a value: dot.style.setProperty('--color', 'red');

We want the confetti dots to start from the same source, but end up in different, seemingly random x and y positions.

To simulate this randomness in our confetti, we create a simple method. It gives us a pseudo-random number within a specified range that we can use to set the end positions of x and y.

Let’s go ahead and define our custom properties using our random function:

Lastly, let’s define some happy colors for our confetti.

Then, we append the dot to the card using the method appendChild().

Puh! Let’s take a look at the result:

There you go! Awesome confetti with a few lines of code and no sweat. How about playing around with some confetti this holiday? Feel free to use it in your own project, and play with the different variables to customise it.

And remember: With great confetti comes great joy! :tada: :star_struck:

Sprinkle, Sprinkle, Little Card

I have always had stage fright. Growing up as a shy kid in a South-East Asian family, I was raised to mostly listen, to let the adults speak and to remain silent. Children were not supposed to be the center of attention at all. This probably affected me a lot as I grew up, getting used to being most comfortable when left unexposed.

12 years ago I started working at Bekk. Here I came across a coach that shared a few visualization techniques with me to help me cope with my anxiety when being on stage, being in the spotlight.

I have used these techniques several times, and especially when preparing for important presentations, for example competency days for the whole company or big conferences like JavaZone. Today I want to share the first technique with you! I call it The cinema.

The cinema 🎥

Close your eyes and try this one out.

Through your own eyes

Picture yourself sitting in the front row at the cinema.

Now imagine you stand up and walk up on stage in front of the audience.

Have a good look at the audience and start the first words of your presentation.

Imagine you finish the rest of your presentation and return to your seat.

Repeat this process a couple of times.

Zoom out

Now zoom out one step, and watch yourself in a movie instead.

Picture yourself sitting in the front row at the cinema and watching a movie.

In this movie, you see yourself sitting in a cinema. You stand up and walk up in front of the audience.

This person in the movie (you) takes a good look at the audience and then starts the presentation.

Watch yourself finish the presentation and return to your seat in the movie. The movie ends.

Repeat this process a couple of times.

Zoom out even more

Now zoom out even further, and watch yourself watching yourself! 🤯

Picture yourself sitting in the control room of the cinema, watching yourself sitting in the front row, watching yourself on the screen.

So you watch the person in front row (you) watching yourself stand up in the movie and walk up on stage.

This person in the movie (you) takes a good look at the audience and then starts the presentation.

Watch yourself watching yourself finish the presentation and return to your seat.

Repeat this process a couple of times.

The effect

Switching the view from watching yourself through your own eyes, and then from the outside, and then from even further away, made me somehow smaller and less exposed than I expected.

Repetition is also a key here. Doing this several times helped me practice the process to walk up, start the presentation, finish it and return to my seat. The more times I have been through the process, the less scary it got.

I hope some of this can help others cope with stage fright or other related feelings when being in the spotlight!

Visualization to cope with stage fright (part 1)

🎶 It's beginning to look at lot like Christmas...🎶 You have put up your favorite decorations, candle lights are sparkling in the windows and Christmas cookies are baking in the oven making a nostalgic scent. You can almost feel the Christmas spirit. But, wait a minute, what's that ruining this perfect Christmas feeling? Is it dirty react code?! There are “this”, a looong render method and even “classes” all over the place. With only four days left it's probably time to do some proper refactoring of your react code. Here are four steps which I have recognized to help me get going. It's time to roll up your sleeves.

The objective of cleaning is not just to clean, but to feel happiness living within that environment

Remember the feeling of a clean house or apartment, you know where everything is and you feel at ease. I find it mentally comforting to have the same feeling when looking at my react code. You can do this bit by bit, or in a larger batch, but I've found that the key is to do it regularly. There are great benefits to having clean code. It's easier to read, write and update your code, making it faster for you to do what really matters with your application. The goal when coding is not just to solve your current problem and make it work, but to do it the right way. You want to be proud of your code and feel happiness when further working with it.

This year we are going to refactor this Advent Candles application:

Looking at the code we can spot the use of classes class App extends React.Component, there are states for each of the candles, and what looks like separate functions for controlling each state.

Does this code make you feel happy?

Well, me neither, so let's work through this refactoring.

Does this spark joy?

Where to start? Looking at the code you might already spot some issues that you would change, but where to start? In this application I would probably start with refactoring from the use of class to a functional component. Writing classes require more code, you need to extend from React.Component and have a render function, while writing a functional component is a plain JavaScript function. After React came with the 16.8 update you can also have stateful components, so it's now an easy choice. A corresponding easy first step for your refactoring might be replacing the class with a functional component.

In the Advent Candles the class is replaced by a functional component and the states now use the React.useState()

Resulting in a component that can look something like this after this first initial refactoring:

How we used the old states:

Refactored code using the new states:

From 32 lines to 5 for the part we have refactored, I call that a good beginning!

\ Here is the code after the first refactoring.

Let it DRY, let it DRY, let it DRY ❄️

There are four candle lights and corresponding states for them all. Is there a pattern that repeats itself? I would say yes, and we can refactor this. It is finally time to DRY the code. DRY, or “Do not Repeat Yourself” is a principle to reduce repetition and avoid redundancy. In our application we have four candles all rendered in one large return. There are several elements that are similar, making this a perfect candidate for DRYing and make new smaller and reusable components. So, from a single large implementation we can create a small reusable component called Candle.

Let’s split this large component into smaller reusable components.

In the return() there are four candles that have the same functionality, a state that keeps track if the light is on or off and number for which candle it is. In addition, we will pass it the property of the candle number. It can look like this:

Now, if we want to make changes to the Candle we can do it once at one place affecting all the candles. In the App we can now just include as many Candle components as we want and pass them the desired props. Sounds scalable?

Every time you repeat yourself, and start copy paste, it should ring a bell. This will help you from ending up with large and bulky components that you have a hard time remembering what to do when scrolling through the component. Just, “Let it DRY, let it DRY, let it DRY”.

Highlight the important and get rid of the unnecessary

Some refactoring changes are easier than others, but still important. Here is a bullet list I find useful to go through every once in a while:

Get rid of comments, unused imports and unused code.

Go through the names - will someone else understand what they mean a year from now?

Improve readability with destructuring your props. Instead of (props) and props.description you can destructure and pass down the props like this ({description}) and description.

Our Advent Candles are getting cleaner and cleaner, just look at them.

Make it sparkle!

Let's sprinkle some magic on our application that will also be a gift to ourselves in the year to come. With adding tests to your application, your future you will thank you. Using react-testing-library you can test your react components how a user would use them. React-testing-library is focused on the way the components are used, and not so much the implementation details of the components. Rather than having access to props and state, the tests are related to how the user interacts with the components. If you want to read further about react-testing-library, I can recommend this article.

So, let's connect the dots, how does this relate to our refactoring? Tests can actually indicate if further refactoring is needed. If you have to write long tests in order to test your component, it is probably time to split the component. The Advent Candles application first had one single large implementation of the User Interface. However, when refactoring the code, we split the code into two functional components; App and Candle and we now have an application that is easier to test. So, in order to increase testability it's a good practice to split components into smaller independent components.

\ Here is how our Advent Candles application looks like with some tests. Click on the Tests tab to run the tests.

Writing the tests based on the components behavior also has some advantages for future refactoring. What the component wants to accomplish. When refactoring the Advent Candle application, we did not change what the components did, only how they did this. This is a key element to be a support for refactoring instead of a redraw. When we a year from now want to refactor the application, we can do this without using a lot of time trying to understand how the tests worked, and what will make them pass. So, with behavior-based tests we can in the future do further refactoring and know that the tests will tell us only if we do changes that change the behavior. They can give you confidence knowing that you don't break anything, and you can work faster and write new functionality. We can now test the components individually, and when in the future we change the code we have a better understanding for where in the code the break is happening if one test breaks. Neat huh?

It's beginning to look a lot like Christmas

Now it is actually beginning to look a lot like Christmas. We have refactored our Advent Candles Christmas decoration - thrown away the old class component, made a small reusable Candle component, removed the dust and refactored the application to something that sparks joy.

The Advent Candles still look the same and have the same functionality, but you know that underneath the code is more scalable and testable, and it's easier to further implement new functionality. So, with no more dirty code to get annoyed by, just code ready for future functionality and refactoring supported by our magic tests it's finally beginning to look a lot like Christmas.

4 steps for the getting your React code ready for Christmas

Looking for some entertainment while you decorate the Christmas tree or order the latest Christmas gifts? Today we share some of our favorite podcasts.



Darknet Diaries

True stories from the dark side of the Internet. Hosted by security veteran Jack Rhysider. A podcast about hackers, breaches, shadow government activity, hacktivism, cybercrime, and all the things that dwell on the hidden parts of the network.



Hackable?

This podcast covers topics that should be relevant for anyone even outside the security industry. From Wi-Fi to webcams and cars to computers, the episodes expose the places hackers may hit, and explain how they get our information. The hosts, Geoff Siskind and Bruce Snell, explore where we’re susceptible in our daily routines, without even realizing it.



Security Now

Hosted by Steve Gibson, the man who coined the term spyware and created the first anti-spyware program, and Leo Laporte. They discuss, in understandable terms, the hottest topics and latest news in security today.



Reply All

Not really a pure security podcast, but rather about the "life on the internet" in general. It occasionally has some hacker stories. Hosted by PJ Vogt, Alex Goldman, and Emmanuel Dzotsi.



Hunting Warhead

Hunting Warhead follows journalists and police on a global mission to expose the darkest corners of the internet. Host Daemon Fairless tracks down the investigators, survivors and criminals themselves.

Our favorite podcasts

I gårsdagens luke skrev vi om at for å oppnå finansiell verdiskapning, bør en konsernstrategi legge til rette for vekst og/eller lønnsomhetsforbedringer. Hvordan bør vi gå frem for å vokse? Og hvordan bør vi gå frem for å forbedre lønnsomheten?

Ikke all vekst skaper den samme verdien

Hvordan bør vi vokse? Skal vi ekspandere til et nytt marked, lage et nytt produkt eller kjøpe opp en konkurrent? Selskaper står overfor et bredt spekter av strategiske vekstalternativer, og det kan være vanskelig å ta beslutningen om hvordan man skal vokse. Selskaper bør tilstrebe verdiskapende vekst, altså at veksten isolert sett har tilstrekkelig lønnsomhet til å skape verdi.

Grafen over viser hvordan ulike typer vekst skaper ulik verdi basert på studier av aktører i det amerikanske markedet for forbrukervarer. Grafen viser verdiskapningen av å øke omsetningen med en krone, for de ulike alternativene.

Studien fant at den mest verdiøkende måten å vokse på er gjennom å introdusere nye produkter, da man ofte utnytter eksisterende kapabiliteter og kompetanse i virksomheten, og allerede har distribusjon og andre viktige elementer etablert. Å utvide et eksisterende marked er også en relativt verdiøkende form for vekst, ved at man for eksempel påvirker kunder til å konsumere mer av produktet.

En annen vekststrategi er å ta markedsandeler fra konkurrenter, men her ser man at verdien som skapes varierer fra negativ til moderat positiv. Det koster å ta markedsandeler fra konkurrenter, i form av markedsføring og reduksjon i priser, som igjen raskt kan møtes fra konkurrentene.

I et marked i vekst er verdiøkningen større enn dersom markedet er stabilt, som følge av at en økt markedsandel ikke bare gir økt vekst her og nå, men også fremover. Et eksempel på dette er det stabile markedet for boliglån. Dersom DNB aggressivt ønsker å øke sine markedsandeler er de nødt til å tilby en bedre rente, som igjen fører til at konkurrentene tilpasser seg på det lave nivået og således ødelegger verdi for DNB og konkurrentene.

En siste måte å oppnå vekst er gjennom oppkjøp av andre selskaper, og vi ser her at verdiøkningen som oppstår er lav. Dette kommer som følge av at prisen man betaler ved oppkjøp ofte reflekterer verdien den nye virksomheten vil skape, og at man derfor betaler fra seg den fremtidige verdiskapningen til dagens eier av virksomheten.

Disse funnene er kun basert på en bransje i det amerikanske markedet, og det er sannsynlig at det er store forskjeller mellom bransjer og for ulike selskaper. Det enkelte selskap bør derfor gjennomføre grundige analyser og business case på lønnsomheten og verdiskapningen som vil følge av ulike strategiske vekstalternativer.

Lønnsomhetsforbedring kan bli kontra-produktivt

Lønnsomhet avhenger av marginene som oppnås, altså forskjellen på inntekter og kostnader. Vi kan øke inntektene gjennom å endre inntektsmodell, endre prisstrategier, forbedre verdiforslag, forbedre pakketering og forbedre salgs- og distribusjonsmodell. Vi kan redusere kostnadene gjennom kostnadskutting, prosessforbedring, effektivisering og produktivitetsvekst. Lønnsomhetsforbedringer gjennom å øke inntekter og kutte kostnader gir direkte resultater på bunnlinjen og er derfor noe enhver virksomhet indirekte kontinuerlig bedriver, og bør ha en strategisk og analytisk tilnærming rundt.

Kostnadskutting er en populær aktivitet da det gir konkrete, målbare resultater og slår rett inn på bunnlinjen i dag. Men etter et visst nivå kan kostnadskutting bli verdiødeleggende, der det går utover verdiforslaget, inntektspotensialet og vekstpotensialet. Dersom en restaurant-kjede kutter kostnader ved å reforhandle innkjøpsbetingelser, vil ikke betalingsviljen til forbrukerne gå ned – men dersom restaurant-kjeden reduserer kvaliteten i sine ingredienser, vil betalingsviljen til forbrukerne gå ned. Å øke inntekter gjennom å øke priser, kan også være en strategi som gir økt lønnsomhet til et visst punkt – der kundene flykter og andre aktører utkonkurrerer deg på pris. De fleste virksomheter opererer i kompetitive aktørlandskap der det er utfordrende å ta høyere priser enn konkurrentene uten å differensiere seg og skape verdi for kundene.

Vi må med andre ord sørge for å ikke forbedre marginer så mye at det går ut over kundene våre og/eller vår evne til å vokse og fungere optimalt. Det er som regel enkelt å forbedre marginer på kort sikt, men det tar tid å observere de virkelige konsekvensene. DNB kan øke utlånsrentene med 0,1% i dag og få forbedret lønnsomhet i Q1 2021, men gradvis vil kunder flykte til konkurrenter. Telenor kan kutte 1000 stillinger nå, men å observere de virkelige lønnsomhetskonsekvensene av det kan ta lang tid. Noen grep er lavthengende frukter, og utfordringen ligger i gråsonene der man ikke med sikkerhet kjenner til den langsiktige lønnsomhetseffekten av de ulike tiltakene. Da gjelder det å ha en strukturert og datadrevet tilnærming, og eksperimentere seg frem til et optimum – gjennom å for eksempel øke prisene med 1% og måle hvordan det slår ut på volumet og lønnsomheten.

Selskaper bør søke etter muligheter for verdiskapende vekst, og lønnsomhet bør forbedres gjennom kontinuerlig forbedring av marginer gjennom optimering av priser og kostnadsnivåer. Selskaper står med andre ord ovenfor viktige strategiske beslutninger når det gjelder hvordan lønnsomhet og vekst skal forbedres. Det er derfor viktig at man har en analytisk og datadrevet tilnærming der man ser helheten og estimerer effekten av ulike strategiske grep.

Hvordan oppnå verdiskapende vekst og forbedre lønnsomhet?

“Why don't they run the application on the cloud?” - every time a service goes down under heavy traffic this is a common response. Some developers seem to think that as long as you are running in the cloud, you are home free. Everything in the cloud can scale to infinity.

This is of course not the case.

It is easier to make an application that can scale to infinity in the cloud, but it is not necessarily easy.

Architectures

IaaS (Infrastructure As A Service) is hard to scale automatically. Most cloud services have some mechanics available to set up auto scaling of IaaS, but it requires a lot of work in order to set it up correctly. As it is impossible for the cloud service to know what kind of software that is running on the machines, nothing can be done automatically.

CaaS (Container As A Service) has many of the same problems that IaaS has. The difference is that containers are often smaller and contain less services than the IaaS containers, and the tooling around scaling is easier to use.

PaaS (Platform As A Service) is per definition easy to scale. All you deploy is a software package that the cloud services chooses how to deploy. As long as the cloud service support some kind of auto scaling you should be good to go.

FaaS (Functions As A Service) has scaling built into the architecture. No FaaS functions should have any state, and hence there should be no problem having unlimited instances of them.

Scaling your application

Regardless of which type of cloud you choose, it’s quite easy to scale stateless applications. Usually you just need more instances of them and a load balancer in front. The real problem is connected to your application’s side effects. These side effects include for instance databases and search engines where you pay for capacity (i.e. memory limit and cpu limit), not usage. When the price model is connected to capacity, you will have a problem from day one. When you need more capacity, it isn’t possible to quickly increase it. In my current project we are running on Heroku with PostgreSQL-databases. In order to increase the capacity of the database, we have to take down the application so we don’t miss any commits to the database. This is not feasible in an environment where you have to be available all the time, regardless of the current load of the system.

How to solve this problem

Given that you have dependencies that do not easily scale, how do you handle it? It depends on several factors. First of all, is the problem related to writing og reading? How realtime does your data need to be? How complex is the integration and how much business logic resides in the integrated service?

Rewrite dependencies

You may choose to rewrite those dependencies, for instance migrate from a sql-database to a column-oriented database. However, there are many problems with this approach. First of all, you might not have a team that knows any other databases, so you will have to recruit new people. Your application might also depend on the structure and functionality of the sql-database that other databases do not support very well. To perform such a huge task just to satisfy non-functional requirements, without getting any business value from it, might not go down well with the people paying the bills.

Add some asynchronicity

You might consider adding a scalable persistent queue of some sort between the application and the database. Doing this enables you to have full control over how much load you are putting on the database. However this will only scale the writes, and you will get a delay before what you have written to the queue is available for reading from the database.

If reading from the integration is where you have scaling problems, you might choose to propagate changes written to the database to other datasources, like a search engine, file storage or other databases. Some databases have built in support for Master/Slave architectures that makes this quite easy to do. As with using a queue for writing, this approach will also make the data available at the slaves some seconds later than when you wrote it. However, if you need realtime data in some parts of your application you can read from the master database.

Rent a huge database server

This might be the best short time solution. It might feel expensive, but compared to the development cost in the previous solutions it is nothing. Make sure to rent a server that will handle as much traffic as you think you will have in the next year. Of course, if you suddenly have a spike in traffic that you didn’t foresee, you will go down.

Queuing your customers

One solution I haven’t discussed is simply to have a limit on how much traffic you can handle. Ticket vendors and stores having black friday do this. If the amount of traffic is too much, the customers will be put in a queue. Let's just pray that they’ll stick around long enough to do what they came to your site to do

Scaling vs development speed vs complexity vs cost

There are several things you can do in order to handle scaling of your application and services. However they all come with a cost. The man hours required to write the scaling, the effect this scaling has on your development speed and the increased complexity of your application. If your time to market is drastically increased after you have implemented advanced unlimited scaling, you might not need the scaling after all.

In summary, consider scaling requirements vs development speed vs complexity vs cost of implementing before you do anything drastically.

Scaling is harder than you think

I en nasjonal dugnad, én søndag i året har over 100 000 mennesker banket på dører i hele Norge for et godt formål. Hva skjer når man ikke lenger kan samles fysisk og hvordan erstatter man denne aktiviteten digitalt på kun seks uker?! 😱

Spleis er en av TV-aksjonens viktigste samarbeidspartnere og ble i år leverandør av de digitale bøssene til årets aksjon. Spleis er en norsk folkefinansieringstjeneste der folk enkelt kan starte digitale innsamlinger. Vi er to designere som til daglig sitter hos Spleis og skal i dagens luke fortelle litt om våre erfaringer fra å erstatte en fysisk løsning med noe heldigitalt.

Konseptet digital bøsse fikk en sped start allerede i 2018. Hypotesen var da at bøssebærerne kunne samle inn enda mer penger med en digital innsamling etter at de hadde gått med sin fysiske bøsse. I 2019 lagde vi en pilot der flere fikk testet løsningen. I år, i disse koronatider, ble året vi virkelig fikk testet ut konseptet digital bøsse ved å erstatte hele bøsseløsningen.

TV-aksjonen er verdens største innsamlingsaksjon og en stor nasjonal dugnad der privatpersoner, næringsliv, skoler, regjeringen, kongehuset, og mange flere over hele landet kommer sammen for å engasjere seg på ulike måter. En av de viktigste aktivitetene tradisjonelt sett har vært den fysiske bøssebærerrunden. Nå som den ble avlyst, måtte vi være kreative og tenke nytt om hvordan Spleis kunne engasjere flest mulig bøssebærere.

Hvordan ivareta dugnadsånden med digitale bøsser?

1. Gjøre det så enkelt som mulig å komme i gang

De som melder seg som bøssebærere representerer alle deler av den norske befolkningen, fra barnefamilier, besteforeldre til miljøengasjerte ungdommer. En av de viktigste prioriteringene var derfor å gjøre det så enkelt som mulig for hvem som helst å komme i gang med en digital bøsse. Både de som enkelt tar i bruk nye digitale tjenester og de som generelt sett synes teknologi er noe herk. Vi fokuserte mye på å gjøre registreringen, og det å opprette en digital bøsse, så sømløs som mulig.Det gjorde vi ved å beholde registreringsskjemaet likt som tidligere år. Videre ble den digitale bøssen automatisk generert ved å hente navn og postnummer fra registreringen og et predefinert bilde, tekst og belønninger ble lagt til.

2. Få frem det personlige med å være digital bøssebærer

Et annet mål var å gjøre den «digitale bøssebærer-opplevelsen» like personlig som det tradisjonelle møtet i døren. En digital løsning åpnet samtidig for at giverne i tillegg kunne bli litt bedre kjent med personen bak bøssen. De som ønsket det kunne derfor legge inn et bilde av seg selv og beskrive sitt engasjement for saken ved å redigere teksten og belønningene. Av erfaring fra Spleis vet vi at personlige innsamlinger gjerne engasjerer mer når innsamlingen deles i nettverket til innsamler. 

3. Skape tilhørighet nasjonalt og lokalt

Som bøssebærer er man en av mange engasjerte frivillige fra hele Norge. Vi ønsket å trekke frem at de var en del av et større fellesskap både lokalt og nasjonalt. En søkeside ble satt opp så folk enkelt kunne finne bøssene til naboer, bekjente eller andre fra samme lokalområde. Statistikk som «antall bøsser» og «innsamlet beløp per innbygger» ble lagt til på bøssesøket for å synliggjøre aktiviteten både på kommune og fylkesnivå. Dette økte engasjementet blant de frivillige lokallagene som jobbet med å rekruttere flere bøssebærere. Folk begynte å engasjere seg for å få opp det innsamlede beløpet i sin kommune ved å dele statistikken i sosiale medier med en oppfordring til flere om å gi.

En av de viktigste suksessfaktorene på Spleis er hvor mye penger folk klarer å samle inn. For TV-aksjonen var det også viktig å ivareta dugnadsfølelsen. Det ble derfor lagt til en hyllest til bøssebærerne inne på bøssene sammen med tall på antall bøssebærere fra samme by. Vi ønsket med det å rette vel så mye fokus på det positive ved å engasjere seg, som på hvor mye hver av dem klarte å samle inn.

Videre viste det seg at flere ønsket å samle inn til en digital bøsse sammen som en gruppe, og ny funksjonalitet ble lagt til på rekordtid for å gjøre det mulig. To fine eksempler er bøssene til håndballaget Vipers og Norges seilforbund. For å motivere til større giverglede blant bedrifter gjorde vi det mulig å sette opp samlesider der ulike avdelinger kunne konkurrere mot hverandre om å samle inn mest. Mange bedrifter valgte også å doble beløpet som de ansatte gav til spleisen og gav dette som et felles bidrag til TV-aksjonen.

4. Veilede gjennom alternative aktiviteter

Etter å ha opprettet en digital bøsse, var det ikke gitt hva man skulle gjøre for å nå ut til folk. I stedet for å gå rundt og banke på dører, måtte vi komme opp med alternative aktiviteter som blant annet kunne gjennomføres fra sofaen. Til det ble det satt opp en introduksjons-side første gang man gikk inn på den digitale bøssen i tillegg til gjøremålskort med tips om aktiviteter man burde gjøre for å spre bøssen. Vi laget delingsmateriale som enkelt kunne lastes ned fra spleisen, både delingsbilder i ulike formater til sosiale medier, og en plakat som kunne printes ut og henges opp. Spesielt fint var det å se at delingsbildene ble tatt godt i bruk like etter lansering og prydet newsfeeden på instagram.

Hvordan gjøre dette på seks uker?

Høy fart og riktige prioriteringer var avgjørende faktorer da vi i løpet av en seks ukers periode skulle hjelpe TV-aksjonen med å gå fra fysiske til digitale bøsser. Det var spesielt to ting som økte produktiviteten i teamet:

Daglige prioriteringer

Som et autonomt team i Spleis, er vi vant til å prioritere sammen ukentlig. Med høy fart og kort tid til levering fant vi fort ut det var viktig å være synkroniserte på tvers av oppgavene. Særlig siden det var mange avklaringer med flere aktører og mange baller i lufta med lite konkrete oppgaver. \ \ Etter et par uker fant vi ut at det var mer produktivt med daglige prioriteringsrunder. Vi satte opp et Trello-board for hva som skulle prioriteres etter rekkefølgen, «I arbeid», «Nå», «Neste», «Senere» og til slutt «Nye ideer» til prioritering. Disse var basert på daglig innsikt som ble plukket opp fortløpende. Målet var at alt som ble prioritert «Nå» skulle være fullført innen samme dag. Dette gjorde at vi som designere alltid måtte ligge et hestehode foran utviklerne med å avklare hva vi skulle løse. Etter at oppgavene var prioritert, designet vi ofte løsningene sammen med utviklerne på teamet. Nye features ble ofte satt rett i prod og vi kunne allerede samme dag se det i bruk og optimalisere fortløpende.\ \ De daglige prioriteringene sørget for at hele teamet fikk eierskap til ulike oppgaver og ikke minst fokus mot et felles mål.

Hele teamet på kundeservice

Kundeservice har vært en viktig kanal for innsikt til teamet siden Spleis ble startet i 2016. Med høy fart, lite tid til testing og hyppige lanseringer ble kundeservice en avgjørende kanal for innsikt da vi skulle onboarde nye brukere og ikke minst lansere ny funksjonalitet fortløpende under TV-aksjonen. Det ble derfor ekstra viktig at vi kunne fange opp spørsmål, bugs og utfordringer brukerne våre hadde med en gang.

Til vanlig rullerer hele teamet på å svare på kundeservice. Designer, utvikler, forretningsrådgiver, produkteier, marketing – til og med daglig leder bytter på å svare på kundeservice-henvendelser.

Den store fordelen med at kundeservice er en del av teamet, er at alle sitter nært på problemene brukerne opplever og får ekstra eierskap og forståelse av hva som bør forbedres. Ikke minst har vi erfart at kundeservice er en viktig del av hele brukerreisen. Brukerne får en mye bedre opplevelse med tjenesten om de blir hørt og hjulpet videre når de har behov for hjelp. På det mest hektiske, mot innspurten av aksjonsdagen opplevde vi at nettsiden ble treg og flere brukere fikk ikke til å logge seg inn eller donere penger. Mens utviklerne febrilsk jobbet med å løse problemene, så sørget vi andre for å lytte til brukerne, forsikre om at vi jobbet med saken og at vi ville si ifra når vi hadde en løsning.

Målet med å sitte nært på kundeservice og brukerne våre er enkelt og greit å få ned antall henvendelser, noe som betyr færre problemer og dermed bedre brukeropplevelser. De daglige prioriteringene, basert på fersk innsikt fra kundeservice og testing i produksjon, bidro til at vi kunne holde høy fart og ta noen "bets" underveis.

Så, hvordan gikk digital bøsse lurer du kanskje på?

Etter noen intense uker med lange kvelder og høy fart på hvert vårt hjemmekontor kunne vi 19. oktober puste lettet ut. TV-aksjonen og WWF var veldig fornøyde med årets sluttresultat og at mange tidligere bøssebærere kjente igjen dugnaden og ønsket å opprette en bøsse for sin “tur”. Digitaliseringen av bøssa bidro i tillegg til at flere nye meldte seg som bøssebærer i år, som ikke hadde deltatt tidligere.

Vi er veldig stolte av hva Spleis-teamet klarte å levere på rekordtid. Det ble satt mange nye rekorder på Spleis og det innsamlede beløpet ble seksdoblet fra resultatet for TV-aksjonen på Spleis i 2019. Det var rørende å se alle som tok i bruk de digitale bøssene og gjorde dem til sine egne. Alt fra tre generasjoner, Besteforeldrenes klimaaksjon, Frida Ånnevik til selve statsminister Erna sin digitale bøsse. Håper du også vil bidra med å være digital bøssebærer neste år 🎅

Tusen takk til Anne Berit Bjering med gode innspill og korrekturlesning!

20-Dec

Today's posts