A handy feature in Kotlin is the ability to destructure datatypes into multiple variables. Given a data class Country:

And an instance country of Country:

We can use the syntax called destructuring declaration to extract the values of name, population and area from country, where the left-hand side of the assignment are comma separated variables wrapped in parentheses:

With this syntax, it is possible to assign multiple variables from properties of a single instance of an object, in one line. This code would give the same result without using destructuring declaration:

The variable names does not have to be the same as the names of the properties of the data class, and we can also specify the types like for regular variable assignments:

Destructuring declaration should not be confused with tuples found in other languages such as Python, Haskell, Scala and C#. While the syntax of destructuring declaration on the left-hand side looks very similar to tuples on the right-hand side, Kotlin does not have tuples. Here is an example to illustrate the similarity:

However, data classes can be seen as powerful tuples with the advantage of both being named themselves as well as their properties.

But how does the destructuring work? It is based on a convention of functions called component1(), component2(), ..., componentN(), where in the assignment val (v1, v2, ..., vN) = x, v1 would be assigned to x.component1(), v2 to x.component2() and so on. These functions are automatically generated for data classes, and would look like the following for the data class Country as extension functions:

This means that we can get destructuring capabilities on any data types, by defining componentN() functions. When destructuring, we can destructure as many, or few, variables as we like, as long as there are defined enough componentN() functions. So if we are not interested in the area variable of country, we can omit area in the destructuring:

If we are only interested in the population variable of country, we can replace the variable name for assigning name with an underscore:

Another useful case of destructuring found in the standard library is on lists, where component1() to component5() functions are defined, making it possible to destructure lists like this:

One should however be sure not to destructure more elements than the list contains, to avoid IndexOutOfBoundsException.

Destructuring can also be used in lambdas. So this lambda, printing the population property of country:

Could also be written like this:

Destructuring is one useful feature in Kotlin that contributes to keeping our code clean and concise. In the future, maybe we will see additional destructuring capabilities in Kotlin, like this proposal for pattern matching using the when expression.

Destructuring

In the previous christmas articles we have seen how to destructure tuples, records, and single-value custom types in the function arguments. Today we take a look at how to destructure values in let expressions, along with some of the use-cases where I find this the most helpful.

When writing functions, we often need to define some values in a let expression to simplify the function body. Let's look at a small example:

This is fine, but let expressions are more powerful than just defining single constants! 💪 They can be used to destructure compound values such as tuples, records, and custom types. To illustrate this, we look at examples from the three previous articles of this series and modify them by moving the destructuring into a let expression. If you haven't read the previous articles you should take a look at them now to get some context.

Destructuring tuples (from day 1)

In the first article of this series we saw how to destructure tuples in the function arguments. Now, we use the same example to do the same destructuring in a let expression:

In this example it would probably be just as simple to destructure the tuple directly in the function arguments, but now you know that this is possible, too!

Destructuring records (from day 2)

We can do the same thing with records, inspired by the example in the second article of this series:

Also here one could ask Why not just destructure the record directly in the arguments? One could just do that, but what technique to use and when is often based on personal preferences. In the case of records, I would personally prefer destructuring it in a let expression.

Destructuring single-constructor custom types (from day 3)

I guess you see the pattern now, and that you already see that the example from yesterday can also be destructured like this:

My favourite use-cases

Having shown the power of let expressions, I want to share my favourite use-cases for them. I'm lucky to get to write Elm every day at work, and the following two examples are taken from an Elm app for doing journey searches.

First, let's take a look at the update function. The Model contains a passenger picker which handles everything related to adding passengers to a journey search. The passenger picker has its own Model and a typical update function returning a Model and a Cmd. When calling this update function from the outer update function, then let expressions come in very handy:

Here the return value from calling PassengerPicker.update is destructured directly in the let expression. This way we can easily put the updated passenger picker into the Model while at the same time returning the passenger picker Cmd.

Next is an example where we decide what type of situation message to display on a journey suggestion:

Here, we define three values which are all based on the state of severity. By using a tuple in the let expression, we can define all three values at the same time using only one case expression. In comparison, look how repetitive this code is, where the same check is done for all three values:

Scenarios like this, where multiple values are based on the same condition, are where I use this kind of destructuring the most. Other than reducing duplicated code, one great thing about this pattern is that one can easily see what values are "connected" and that will change under the same conditions. Pretty neat, huh?

P.S. The dog has nothing to do with the article. It's just here for cuteness 🐶

The power of let expressions

Although I've been a professional developer for over seven years, there are still many programming terms I've yet to fully understand. I've heard the term "closures" many times, but I never really bothered to dive into the meaning of it. Maybe this is because I had a decent idea of what it was about, and I knew pretty well how to use it? It's about time I take the leap to figure this out, and finally get some closure.

Simple code

At first, I'd like to kick us off by going straight to some code.

To most developers this is pretty straightforward, especially if you've worked a bit with JavaScript. We create a function, inside of which we create a variable value and a function alertValue. This inner function will run alert(value), and we see this function is run right after it is created. Finally we run myFunc(), and we all sort of just know we will now get an alert box with the text "Hello world".

To me, having worked a fair bit with JavaScript, I kind of just take this for granted.

One step further

Before we start actually explaining closures, I'd like to take the previous code example one step further, to tickle your mind.

This time our outer function doesn't run the inner function. Instead, the inner function is returned. Then we store it in a variable innerFunc, and only now do we run this function.

So this time we don't run the inner function until after the outer function is done executing. This may raise some questions. Does value still exist? Will we get an error or an empty alert, or will we still see the alert box with the text "Hello world"?

In my mind, I just know this still works. But how and why does it work? Supposedly, this is what closures is all about!

Function scope and lexical environment

To understand closures we must also understand the available scopes in JavaScript and what a lexical environment is.

The scopes that are the easiest to understand are the global and the local scopes. If we take a look at our previous code block, we have defined myFunc and innerFunc in the global scope. Then we have value and alertValue which are defined in the local scope of myFunc.

But we also have another scope to consider: the outer function's scope, the lexical environment. This means that when we are inside alertValue we can also access the lexical environment of our function, which is the local scope of myFunc.

To sum it up, the available scopes in a function are:

Local scope

Outer function's scope

Global scope

Scope chain

Let's stop and think for a minute. If a function's available scope is its local scope and its lexical environment, then what happens when we nest more functions?

I just realized I might have given this one away in the topic, but let's break this down.

The scope of sum is its local scope, which contains a and the returned function sum2. The global scope is of course also available, but it always is, so let's not bother with that right now.

The scope of sum2 is its local scope, which contains b and the returned function sum3, but also its lexical environment, which is the scope of sum. So we can also access a and sum2 from within sum2.

The scope of sum3 is its local scope, which contains c and the returned function sum4, but also its lexical environment, which is the scope of sum2. So we can also access b and sum3, in addition to the lexical environment of sum2, which is the scope of sum. So we can also access a and sum2 from within sum3.

Phew! I'm not even going to try to explain the scope of sum4 in such detail. The point is that a function's scope includes its outer function's scope, and this results in a chain of function scopes.

This is also how recursion is possible. Like I said, the scope of sum2 contains sum2, so we are free to call or return sum2 from within sum2.

Closures

So now we understand what the lexical environment is. Hopefully you also knew already what a function is. So finally, it's time to reveal what a closure really is.

drumroll

A closure is a function which is enclosed with references to its lexical environment. In JavaScript, closures are created every time a function is created, at function creation time.

Wait, what? So all this time I thought I've just been making functions, I've actually been making closures? Well, yes!

Closures

Today we are going to explore five big hacks that took place in 2020. First we'll cover two hacks that targeted Norwegian companies Sykehuspartner and NHH. Then we'll take a look at a hack that targeted the Danish company ISS. To wrap things up we'll cover what is probably the two most high profile hacks of 2020: the Twitter phish and the CWT ransom.

Sykehuspartner

Sykehuspartner deliver IT, HR, project and logistics services to all hospitals in the Norwegian health region Helse Sør-Øst (Health South East). It manages vital IT systems for the hospitals, both clinical and administrative applications, as well as infrastructure and networks.

On august 22 2020 several of Sykehuspartners applications became the target of an unknown malicious actor. Only one hospital (Sykehuset Innlandet) was targeted in this attack. Not much is known by the type and scope of the attack, except for what type of data might possibly have been stolen. The potentially stolen data might include:

Information about the deceased

Health information about patients from research projects

Personal information about employees

Name and social security number (fødselsnummer) of students

From reports about the incident, we know that 25 patients and several employees have been notified of personal information having been stolen. Following the attack, the hospital has carried out a forced password change for all employees.

Sources

Sykehuspartner announcing attack

Sykehuspartners analysis of attack

NHH

In august this year, Norges handelshøgskole (NHH, English: Norwegian School of Economics), experienced a data heist. The school is one of the leading business schools in Europe and is located in the city of Bergen.

Usernames and passwords of both students and employees was compromised. The break in was discovered when the stolen credentials were uploaded to a “hacker” forum. The attack targeted a known vulnerability in an old version of the VPN service called Pulse Secure. An updated version that patches this vulnerability has been available since April 2019. But NHH is decommissioning the service and has thus been neglecting to update it. All students and employees were asked to change their passwords after the incident.

Sources

Norwegian news article about NHH attack

ISS

In the middle of February this year, ISS was hit by a ransomware attack. ISS is a global facility services company, founded in Copenhagen, Denmark. The company has 450,000 employees.

The ransomware was a massive malware attack across IT-systems and networks. Immediately after the attack was discovered, IT-access was removed to isolate the indicent. As reported by the company. Regardless of the actions taken, the company had to write down and change big parts of the IT-infrastructure. It is estimated that the attack will cost the company between 750 and 1340 million Norwegian kroner (NOK).

It was reported that customer data was not stolen.

Sources

Norwegian news article about ISS attack

Norwegian news article about aftermath of ISS attack

Twitter

Twitter, you know, the social media platform? Yes, that one. In July this year, it was hit with a phishing campaign that was used to target high-profile individuals, like Barack Obama, Joe Biden and Bill Gates.

Twitter stated that "This attack relied on a significant and concerted attempt to mislead certain employees and exploit human vulnerabilities to gain access to our internal systems".

The phish was used to get access to certain high-profile accounts. The compromised accounts were used to promote a bitcoin scam.

Sources

News article about Twitter hack

News article about Twitter hack - two weeks later

CWT

CWT is a travel management company that manages business travel, meetings and so on. The 27 of July this year, the company was hit by a massive ransomware attack that knocked 30,000 computers offline. The hackers claimed to have stolen two terabytes of files, including financial reports, security documents and employees’ personal data. CWT paid $4.5 million to the hackers to restore their systems.

One of the fascinating things about this hack was that the negotiation chat, where the company and the hackers met to talk, was left open to the public after the negotiations ended. This gives us a never before seen insight into how the negotiations between hacker and hacked works. As many others have noted after the chat became public, it is rarely advised to actually pay the hackers like CWT did. This is, of course, because of the precedence it sets and that the chance of getting scamed is very high.

Sources

News article about CWT attack

In conclusion

This is of course not a complete list of all the major hacks that were reported in 2020. It sure has been a very active year in this regard. As you can see, there are many ways of being vulnerable on the internet. If you want to better understand how to prevent some of these things happening to you, take a look at the previous three posts:

Application security check list

Github Security: Getting started with Dependabot

How secure is your build pipeline?

Also, be sure to follow this advent calendar for even more articles leading up to Christmas day!

Five big hacks of 2020

Maybe you have just been hired by a company that uses Figma? Maybe you have been using Sketch and Abstract for the last years and heard some good things about this new, up and coming design tool? Maybe you even have used Figma for a while and you’re curious if maybe there still are some tricks you haven’t yet learned? Well, look no further! The answers to all some of your questions lie ahead!




Where are you going with this?

An excellent question! While you were fast asleep getting your regular six to seven hours, I was up all night making a Figma course for you. So kick back, relax and enjoy your raw cocoa and bee pollen coffee. You can't slack too much though because you have to do most of the work from here on out…

I believe the quickest way to learn something is to try it for yourself. Therefore, I’ve decided that the best way to introduce you to Figma is to make a Figma file filled to the brim with practical exercises for you to explore and learn from. My goal is, at the end of the course, you'll know enough Figma to start creating sketches and wireframes of your own. The tutorial is inside this downloadable Figma-file, so you can add it to your own files and look at it whenever you want. You’re welcome.




Cool! So what’s in this course?

I’m glad you asked, friend! In the course, I’ll show you the layout and features of Figma and how to use them. You will be introduced to a plethora of different tools and menus, and get an overview of shortcuts and other techniques for making your life with Figma easier. This course will not make you a seasoned professional ready to tackle the most complex responsive layouts and modular design systems. It will, however, give you the skills necessary to continue experimenting and creating on your own.




So, where do I begin?

You can either duplicate the file from Figma Community or download the file and import it to Figma. Then it’s just a matter of opening the file and we’re off!

If you don’t know how to import files into Figma yet, don’t worry! Our good friends over at Figma have put together an easy tutorial for just that right here.




This course is based on a course by Martin Sangolt. If you know him you also know I have a lot to live up to, so let's go! No time to lose!

So you’ve opened Figma, now what?

Today I want to give you an introduction to the programming language Elixir, some of its features and why you might want to check it out!

The basics

First things first: Elixir is a concurrent functional language that runs on the Erlang VM. It is inspired by many different languages where Ruby and Erlang are most obvious ones based on the syntax.

Elixir is a strong, dynamically typed language. This puts it in the same category as Ruby and Python and it has optional functionality for compile time type checking as well.Elixirs data structures are immutable, but variables can be reassigned/rebound. ^rebinding This was a bit strange for me in that I got started with FP through Elm where there are no variables, just constants.

Elixir inherits a lot its data structures and related syntax from Erlang which in many ways is its biggest influence. Elixir Design Goals describes the relation to Erlang like this:

Elixir is meant to be compatible with the Erlang VM and the existing ecosystem. When we talk about Erlang, we can break it into three parts:



Elixir runs in the same virtual machine and is compatible with OTP. Not only that, all the tools and libraries available in the Erlang ecosystem are also available in Elixir, simply because there is no conversion cost from calling Erlang from Elixir and vice-versa.

A functional programming language, called Erlang

A set of design principles, called OTP (Open Telecom Plaform)

The Erlang Virtual Machine, referred to as EVM or BEAM

This is a great feature of Elixir that we will talk more about later.

As for other inspirations Elixir has docstrings from Python, polymorphism and protocols from Clojure, macros and meta-programming from different Lisps, just to name a few. [^inspiration]

Hello World!

As I said, Elixir is a concurrent functional programming language. For the functional part it means that Elixir mainly uses functions and modules for code structure and has other features that are associated with functional languages. We'll talk about the concurrent part later.

A hello world example in Elixir might look something like this:

Here we define a module with a function that simply writes "Hello, World!" to the console.

Killer applications

Many programming languages has "killer apps"; libraries, frameworks and use cases, that in themself are enough to justify the transition to the language or try it out. For Ruby it was the web framework Ruby on Rails and in many ways Elixir has its own Rails: Phoenix.

Phoenix web framework

Phoenix is inspired by Rails (the team originally behind Elixir was previously a Ruby shop) and was an early addition to the Elixir community. The creators of Phoenix has learned from years of Rails development and made their own opinions in addition to the natural changes needed when going from an object oriented language to a functional language. Compared to Rails Phoenix has with the help of the Erlang VM great performance. Some of you might have heard about Phoenix' amazing 2 million simultaneous web sockets benchmark!

The Nerves Project

Another interesting project in the Elixir ecosystem is the embedded/IoT project Nerves. Nerves makes it possible to use Elixir code to create embedded system where previously you would have had to use a low level language like C. This does not stop you from bringing your own code (like C, C++, Python, Rust, and more) while using Nerves as a platform for your IoT project. The project web site says:

Nerves is a complete IoT platform and infrastructure for you to build and deploy maintainable embedded systems.

The BEAM and OTP

When talking about the advantages of Elixir it is hard to not talk about the advantages of Erlang and its virtual machine, the BEAM (Bogdan's Erlang Abstract Machine). It is in many ways the biggest selling point for Elixir. We are now talking about the concurrent part of Elixir. Erlang and the BEAM has shown its resiliency over many years, exemplified in giving Ericsson 9 nines (99.9999999%) availability in their AXD301 switch.[^nine9s] It is known for its "let it break" philosophy and self-healing properties and by being compatible with Erlang, Elixir inherits a lot of these traits.

Elixirs creator, Jose Valim, attributes one of the motivational factors for the creation of Elixir to the rise of multi-core CPUs and the need to utilize these. Ruby and other languages with a global interperter lock (GIL) limits this, but the Erlang VM and the tools and design prinsiples of OTP have proven to be a great choice for creating concurrent, performant and resilient applications.

Everything is a process

Everything in the BEAM is a process. These are not OS processes, but lightweight processes which can be cheaply spawned and killed. In his PhD thesis the co-inventor of Erlang, Joe Armstrong, summarized Erlangs principles regarding processes:



Everything is a process.

Processes are strongly isolated.

Process creation and destruction is a lightweight operation.

Message passing is the only way for processes to interact.

Processes have unique names.

If you know the name of a process you can send it a message.

Processes share no resources.

Error handling is non-local.

Processes do what they are supposed to do or fail.

Sidenote: For some this may sound vaguely familiar. Some object oriented languages has had similar principles, but instead of processes they are applied to objects. Smalltalk is reported to be one of the inspirations to Erlang and it is fun to think about Erlang being a functional language but still be more object oriented than some object oriented languages. This is of course not the case as the definition of OOP has changed over time and Erlang is a functional language, but it is fun to ponder the similarities. 😄 Back to the main story! 😅

These unique principles for processes where they communicate through messages lays a great foundation for creating concurrent application, but there is one more piece to the puzzle: OTP.

OTP - The Open Telecom Platform

As with so many other parts of this article OTP is a big topic and could be a separate article, but I'll try make it short! Today the name is a bit strange but it was created by Ericsson for their telephone switches in the 80s and 90s so in that context in makes more sense.

OTP is an integral part of many Erlang applications. In essence OTP is a set of design principles and standards including tools and libraries to make it easier to create applications that adheres to them.[^otp]

Since Elixir is compatible with OTP we can leverage these principles and technologies that has been battle tested in high-pressure and critical applications for decades!

The take-away

Luckily you don't need to understand or know much about Erlang, BEAM and OTP. Without deep knowledge of these topics you can still reap the benefits of highly performing web applications and resilient IoT applications. It would certainly help but it is not a prerequisite. This is the great thing about Elixir: it is an approachable language with battle tested underpinnings! 💪

It might not be your idea of a perfect language. It is not mine either, but that does not stop me from using the great tools at my disposal. If you are all into Haskell or the likes it might not be something you would use and that is OK. Whatever your preferences are you might now know a little more about Elixir and Erlang and some more knowledge is always a good thing. 😄

If you would like to check Elixir out I recommend checking out the official Getting started guide or the interactive guide Try Elixir and then trying out a project with Phoenix or Nerves. Hands-on experience is always better than something you read on the internet! 🤓

Psst! By the way: there are other languages that run on the BEAM. Lisp variants and lately some work on strong statically compiled ML-like languges if you are into that!

[^inspiration]: What languages inspired the design of Elixir (programming language)? - Quora

[^nine9s]: Concurrency Oriented Programming in Erlang, p27 [^otp]: What is OTP?

The case for Elixir

Short and succinct presentations conveying a message crafted with flawless precision. Accompanied by a set number of slides shown for a limited time. Presenters pacing their speech to line up with perfection as the next slide appears. Lightning talks are like regular talks. Only on steroids.

Ripe with constraints, mastering lightning-talks requires focus and keeping out distractions. They should spark curiosity and even a sense of wonder and interest. Leaving your audience eager to find out more about this in their own.

Stay clear of the woods

Time is an obvious factor when it comes to lightning-talks, which means you will have to skip the deep dive into the nitty-gritty of things. That is not to say that lightning talks should be superficial. The presentation should still be substantive and worthy of the audiences time.

Single-idea-presentations

Limit yourself to a single idea or concept that you want to discuss and share with the audience. This will allow you to form a coherent argument about why this is important and engage your audience.

Sticking to a single idea or concept will make it easier to get to the point early on in your talk. Present your idea or concept, providing just enough background or context so that the audience will be able to follow you on your journey. The audience does not need to become experts on the topic, the allotted time does not allow for that.

This talk is about [insert topic here], and how this will make the world a better place for [us/them/everyone]

Designing for brevity and clarity

With limited time, and maybe a fixed number of slides, each of them must be designed with intent and focus. The slides should always support the story you are telling and enhance your message.

Consider what is the one thing you want your audience to take away from each slide. If you are using images, consider what connotations the audience will make of the imagery, or what feeling they will be left with.

Filling the slides with text is never a good idea, and even more so when it comes to lightning talks. You are running the risk of having the audience only reaching half-way down the slide before it changes. Be precise and terse when using text.

Some events will ask you to have slides change automatically after a given number of seconds. Prepare for it and use it to your advantage. When designing your slide deck, and in particular if you are using timed slide changes, the slides should allow for smooth transitions of your talk. Meaning that you should not have to stop talking mid-sentence because the slide changed.

On delivering the talk

Beware of the temptation to speed-talk. This is particularly true if you are still talking about the point made on the previous slide. If you start upping your pace, the audience will start stressing with you. The audience’s attention will shift from your message and to whether you will be able to get through everything before the next slide.

While it is tempting to think that “it’s just a few minutes”, rehearsing your lightning talk is key. Tuning your message and presentation to a perfect fit. The beauty of having a short amount of time is that you can rehearse several times.

Above all, enjoy the experience! The audience is rooting for you and are on your side.

Mastering lightning talks

Vekst er på mange måter livsnerven i ethvert selskap. I fraværet av vekst, vil et selskap stagnere og etterhvert forvitre.

Det er ikke rart at selskaper stadig ser etter nye måter å vokse på. Dette er spesielt viktig for oppstartsbedrifter som opererer med begrensede ressurser og utålmodige investorer. Til tross for at vi har tilgang til mer kundedata, metoder og dataverkøy enn noen gang, så sliter mange selskaper med vekst og å jobbe målrettet med de riktige vekstinitiativene. Et relativt nytt fagfelt som har vokst frem som et tilsvar til dette er growth hacking. Målet er å skape massiv vekst, ved at bedriften til enhver tid har laserfokus på vekst og eksperimenter som bidrar til dette. I denne julekalenderluken skal jeg introdusere dere for growth hacking og hvordan etablerte selskaper kan lære av vekstselskaper og deres tilnærming til vekst og eksperimenter.

Hva er Growth hacking

Det var i 2010 at gründeren Sean Ellis introduserte verden for begrepet growth hacking og siden har fagfeltet eksplodert, særlig i startupverden. Kort fortalt er growth hacking et paraplybegrep for strategier, metoder og et tankesett for å oppnå massiv vekst, på relativt beskjedne budsjetter og kort tid. Hyppige eksperimenter er et nøkkelord. Selskaper som ønsker å øke fokuset på vekst, bør ha et bevisst forhold til antall eksperimenter som gjennomføres hver uke. Gjennomføres nok eksperimenter over tid bidrar dette til å styrke kompetansen og kulturen på dette området, og det er nesten helt sikkert at noen av eksperimentene vil gi gevinst for bedriften. Det er nettopp dette etablerte selskaper kan lære av vekstselskaper; hensynsløs fokus på å skape massiv vekst gjennom hyppige eksperimenter.

Growth hacking slår ned de usynlige veggene mellom dataanalyse, programmering, produktutvikling og markedsføring. Det er få enkeltindivider som behersker alle disse fagfeltene godt, og det er derfor ikke uvanlig med såkalte growth teams som typisk jobber med å drive vekst eller utvikling av nye vekstinitiativer. I en jungel av data, strategier, verktøy og teknologi er det lett å miste fokus på de tingene som faktisk gir vekst. Vi i Bekk foreslår å ta et skritt tilbake for å identifisere vekstmålet og gjennomføre de eksperimentene som bidrar å nå dette målet - slik mange vekstselskaper gjør det!

Vekstsprint i fire steg

Vi bistår våre kunder med å identifisere og gjennomføre veksteksperimenter, gjennom en vekstsprint. En vekstsprint er en 4 stegs-øvelse som typisk gjennomføres av tverrfaglige produktteam eller vekstteam som utvikler nye produkter eller som ønsker å skape vekst på områder som stagnerer. Målet er å identifisere nordstjernemetrikken– den ene og viktigste metrikken for vekst og som best fanger verdiskapningen produktet leverer til kundene, og dermed skaper vekst for bedriften. Vekstsprinten bidrar også til å identifisere veksthindringer, det vil si friksjoner i kundereisen som hindrer vekst. Etter vekstsprinten vil teamet typisk sitte igjen med følgende:

Vi har identifisert 4 steg for enkelt å komme i gang med å identifisere veksteksperimenter. De kan oppsummeres i følgende figur:

1) Identifiser vekstmålet – din nordstjernemetrikk

Formålet med det første steget er å identifisere hva som er teamets nordstjernemetrikk og dermed den metrikken som teamet ønsker å forbedre. For Facebook var den viktigste vekstmetrikken i starten antall brukere som la til 7 venner i løpet av de 10 første dagene. De fant ut at dette var den metrikken som best forklarte om de klarte å skape nettverkseffekter og viralvekst. Airbnb sin vekstmetrikk er antall netter reservert på plattformen. Dette fanger verdien som leveres til både gjester og utleiere, og dermed et godt tall på vekst for Airbnb.

Diskutert innad i teamet hva denne metrikken er og ha den i bakhodet i hele vekstsprinten.

2) Kartlegg veksthindringer i kundereisen

Growth hacking handler om å forstå hvor de største vekstmulighetene ligger i kundereisen. Det er derfor essensielt å forstå kundereisen og eventuelt hvor problemene oppstår for kundene. En måte å visualisere en slik kundereise på er å bruke pirate metrics. Den viser de viktigste vekstmetrikkene i kundereisen fra en kunde får vite om produktet ditt, til de eventuelt anbefaler det til andre. Figuren under viser hva de ulike metrikkene betyr.

Velg en relevant kundereise som er viktig for vekstmålet. Her er det en fordel å gå gjennom hver av de fem delene av kundereisen systematisk og i rekkefølge. Still deg følgende to spørsmål for hver del og kom opp med så mange veksthindringer som mulig:

Hindringer: Hva er det som hindrer at vi får vekst i [sett inn en pirate metric: Acquisition/Activation/Retention/Revenue/Referal]?

Muligheter: Hvilke vekstmuligheter har vi ikke utforsket enda eller bør utforske mer?

Det kan også være en idé å reformulere problemområdene til spørsmål, såkalt "How might we-statements". Dette hindrer at teamet graver seg for langt ned i problemene og åpne opp for nye muligheter. Etter endt brainstorming kan dere være hensiktsmessige å prioritere hvilke veksthindringer som skal utforskes videre i sprinten, for eksempel ved avstemning.

3) Utarbeid eksperimenter

Benytt listen med prioriterte veksthindringer som inspirasjon til å utarbeide så mange eksperimenter som mulig. Hent inspirasjon av andre som har gjort det før. Vi i Bekk har skrevet om dette tidligere og det finnes mange andre ressurser tilgjengelig. Eksperimentene består blant annet av hypoteser, konkrete handlinger og suksesskriterier. Eksperimentkortet består av 7 deler:

Vi skal utforske følgende veksthindring: Veksthindringen som teamet ønsker å løse og utforske videre.

Dette eksperiment går ut på: En kort beskrivelse av eksperimentet teamet skal gjennomføre.

Vi tror at: Hypotesen som teamet skal prøve å bevise/motbevise med dette eksperimentet.

For å gjennomføre eksperimentet skal vi: Hva teamet konkret skal gjøre for å gjennomføre eksperimentet, hver så konkret som mulig. Hvem er involvert? Trenger dere å ordne materiell?

Hypotesen er verifisert dersom: Hva skal dere måle og hvordan ser suksess ut?

Dette har vi lært av å utføre eksperimentet: Hva observerte dere helt konkret? Hvilke læringspunkter sitter teamet igjen med etter å ha gjennomført eksperimentet?

Veien videre blir: Hvordan skal teamet konkret ta tak i den læringen dere fikk og hva som er planen videre for agere på denne kunnskapen.

4) Prioriter og planlegg gjennomføringen av eksperimentene

I det siste steget skal dere prioritere hvilke av eksperimentene som skal gjennomføres basert på tre parametre: Impact, Ease og Confident - en såkalt ICE-Score. De beste eksperimentene løser vekstutfordringene, er enkel å gjennomføre og dere har stor tro på det som team. Skalaen går fra 1 til 10, hvor 1 er dårlig og 10 er bra.

Etter prioriteringsøvelsen sitter teamet igjen med en prioritert liste med eksperimenter, samt en backlog som kan tas tak i senere. Den store jobben er å gjennomføre og lære av eksperimentene.

Det anbefales å:

Lage en konkret plan over hvordan eksperimentene skal gjennomføres, samt hvem som skal gjøre hva. Hver konkret på deadlines og når dere eventuelt skal gjennomgå resultatene. Send gjerne ut kalenderinvitasjoner for å sikre at eksperimentene gjennomføres og gjennomgås.

Gjennomføre slike vekstsprinter med jevne mellomrom. Eksempelvis hvert kvartal for å fylle opp backlogen med eksperimenter. Vekstmetrikken kan endres over tid og livssyklusen til produktet.

Mål antall eksperimenter gjennomført hver uke og ha et bevist forhold til denne metrikken. Gjennomfører teamet mange nok eksperimenter, så skapes det en kultur for testing og feiling, samt at teamene lærer noe nytt ofte.

Nå har dere en oppskrift på hvordan teamet ditt kan komme i gang med å identifisere veksteksperimenter. Hvorfor ikke kickstarte nyåret med en vekstsprint!

Hva kan etablerte selskaper lære av vekstselskaper?

Faggruppene er Bekks fremste arena for utvikling og deling av kompetanse. Hvert år deltar alle som jobber i Bekk i én dedikert faggruppe. Samtlige grupper foreslås, ledes og videreføres av ansatte i Bekk. Et rent produkt av ekte lidenskap for fag og folk. Og i flere av faggruppene jobbes det med innovasjon, men med ulik innfallsvinkel.

Vinh Nguyen, Valentina Sørlie, Kristoffer Solberg og Jens Andreas Huseby prater sammen om hvordan ulike faggrupper jobber med innovasjon.

Hvordan jobber vi med innovasjon i faggrupper i Bekk?

I juli falt en dom i den europeiske domstolen som vil få store konsekvenser for bruken av skytjenester i Europa. Max Schrems vant frem i sitt søksmål mot Facebook, hvor han mente at overføring av hans personopplysninger til USA var ulovlig. Denne avgjørelsen endrer ikke bare hvordan Facebook opererer, men kan potensielt forby bruk av de amerikanske skyleverandørene, samt leverandører i andre land som ikke har godt nok personvern.

Disclaimer: Undertegnede er ikke jurist, og innholdet i denne artikkelen er en tolkning av situasjonen slik den står pr 4. desember 2020. Det er mye usikkerhet knyttet til konsekvensene av denne dommen, og betydningen av den veiledningen EU har publisert. Du bør kontakte juridisk bistand for å vurdere hvordan dette påvirker ditt selskap.

Bakgrunn

Dommen som vi omtaler som Schrems-II er en domsavsigelse i EU-domstolen som omfatter Facebooks overføring av personopplysninger for en europeisk bruker til USA. Dommen gjør i korte trekk en vurdering av hvorvidt en overføring til USA kan ivareta de grunnleggende rettigheter europeiske borgere har. De vanligste overføringsgrunnlagene til USA har vært Privacy Shield og Standard Contractual Clauses (SCC).

Schrems-II-dommen gjør det klart at amerikansk lovgivning, spesielt FISA 702, gjør det umulig for amerikanske selskaper å tilby den nødvendige beskyttelsen for europeiske borgere. Dette går på tvers av Privacy Shield, og denne avtalen ble dermed ugyldiggjort av retten.

Amerikansk lovgivning

Amerikanske overvåkningslover er svært omfattende. Det er i utgangspunktet ikke noe uvanlig i det, men det er noen utfordringer med FISA 702 som gjør at den ikke er mulig å svelge for europeiske personvernmyndigheter. Loven pålegger enhver "electronic communications provider" å etterkomme krav om utlevering fra FISA-domstolen.

For det første er loven uten geografisk avgrensning. Det spiller ingen rolle hvor dataene er lagret. Et amerikansk selskap må hente dem ut uavhengig av lokalisering. Her vil man kunne se likheter til lovgivning i andre land. Selv om et norsk selskap oppbevarer dataene sine i Sverige, kan selskapet fortsatt bli pålagt å overlevere data til norske myndigheter.

Problemene blir større når vi ser på hemmeligholdet rundt FISA-dommer. Dommene er i det store og hele hemmelige, og man kan pålegges taushetsplikt ved utlevering. Dette betyr at den som får sine data utlevert ikke kan forsvare sine rettigheter på en effektiv måte.

Dette medfører at det i praksis er blitt nesten umulig å overføre persondata fra EU til USA. Med Privacy Shield ugyldig vil man måtte basere seg på SCC som overføringsgrunnlag. Men også her er det et krav til at man gjør vurderinger av hvorvidt rettighetene til EU-borgere vil kunne bli ivaretatt. Og domstolen har jo langt på vei sagt i klartekst at det ikke er tilfellet i USA. Dermed skal man gjøre grundige vurderinger før man velger å overføre persondata til USA.

Bruk av tjenester fra amerikanske selskaper

En langt større utfordring er at det gjennom denne dommen stilles spørsmålstegn ved hva som vil skje dersom et amerikansk morselskap får en utleveringsbegjæring rettet mot et datterselskap som er etablert i Europa og underlagt europeisk regelverk. De fleste skyleverandørene bruker denne selskapsstrukturen for å oppfylle kravene i GDPR. Eksempelvis har Microsoft Corporation opprettet selskapet Microsoft Azure Irland Limited i Irland, og det er dette selskapet som utfører alle tjenester for europeiske kunder.

Her mener dommen at det er en risiko for at selskapet vil komme i en skvis hvor de må velge mellom å ikke oppfylle kravene amerikanske myndigheter stiller, og å bryte europeisk personvernlovgivning. I denne situasjonen er man redd for at de vil velge det siste. Straffene for å bryte lovene på amerikansk side er strenge, og siden de kan være pålagt å holde slike henvendelser hemmelige kan det være fristende å bryte europeisk lovgivning i stillhet.

I slike tilfeller vil det ikke være tilstrekkelig at selskapet man har avtale med er europeisk, og at dataene behandles og oppbevares innefor EU/EØS. Det er fortsatt tenkelig at amerikanske myndigheter får tilgang, og dermed bryter man med GDPR.

Hvis denne tolkningen legges til grunn, betyr det at all bruk av tjenester med et amerikansk selskap i eierkjeden er forbudt. Dette er en ekstrem konsekvens av Schrems-II-dommen som i praksis vil ramme mange europeiske selskaper hardt i en lengre periode. Man ser antydninger til at flere forsøker å tolke kjennelsen dithen. Dette er nok også en av grunnene til at det europeiske personvernrådet har kommet med veiledning for å fortsatt sikre trygg overføring til tredjeland, som også kan brukes i denne typen tilfeller.

Anbefalinger fra det europeiske personvernrådet

Det europeiske personvernrådet (EDPB) har kommet med et sett anbefalinger for hvordan man skal gå frem om man ønsker å overføre data til tredjeland. I denne sammenhengen er det viktig å være klar over at all tilgang regnes som overføring. Hvis driftsleverandøren har ansatte utenfor EU som har tilgang til dataene, så regnes det som en overføring ut av EU. I tillegg regnes utlevering uten den behandlingsansvarliges kjennskap til tredjelands myndigheter som et scenario man må ta høyde for.

EDPB har kommet med en anbefaling for hvordan man skal gå frem for å vurdere om man er rammet av Schrems-avgjørelsen, og setter her også frem forslag til tiltak.

Kjenn overføringene dine

Verifiser overføringsverktøyene

Vurder aktuelle tredjelands lover

Iverksett avhjelpende tiltak

Iverksett formelle prosedyrer

Re-evaluer og overvåk løpende

Punkt 1 er allerede en del av GDPR. Alle selskaper er pliktige til å føre protokoll over sin behandling av personopplysninger. Dette steget skal derfor bare være å sjekke protokollen for overføringer til tredjeland, eller til selskaper der utenlandske eierinteresser gjør det aktuelt å vurdere tredjelandslovverk ytterligere. Tilsvarende er punkt 6, at man løpende skal overvåke situasjonen med tanke på endringer som påvirker personvernet, noe GDPR allerede legger opp til - personvern er en kontinuerlig prosess, ikke en engangsøvelse.

De to mest krevende punktene her er 3 og 4. Som Jan Sandtrø skriver:

Også det at den enkelte behandlingsansvarlig skal gjøre en tilstrekkelig vurdering av lovgivningen i tredjelandet som overføringen skal skje til, herunder overvåkningslovgivning, samt å vurdere hvilke tiltak som kan iverksettes for å sikre behandlingen av personopplysninger til et nivå som er i det vesentlige på nivå med EU-retten, er en utopi.

Avhjelpende tiltak sier EDPB at kan komme i flere former, avtalemessige organisatoriske og tekniske. Det kan dermed høres ut som man har mange muligheter til å fikse problemet på et teoretisk nivå. Her er imidlertid EDBP klare på at det i mange tilfeller kun vil være tekniske tiltak som er godt nok, fordi avtalemessige og organisatoriske tiltak kan omgås av fremmede staters lovverk og hemmelige tjenester. Vi står dermed igjen med tekniske tiltak, og da helt spesifikt kryptering som det mest troverdige alternativet for å oppfylle dette punktet. Dersom man krypterer dataene på en slik måte at skyleverandøren ikke behandler dataene i klartekst, så regnes man i stor grad for å være sikker.

Det er allikevel åpne spørsmål rundt hvorvidt man må sikre at krypteringsnøklene aldri er i skyleverandørens besittelse, og hvor langt man må gå i å vurdere krypteringens levetid, fremmede makters evne til å knekke krypteringer og lignende scenarier.

Veien videre

Det er vanskelig å se for seg at EU kan leve med worst-case-utfallet av denne dommen, i alle fall på kort sikt. Det er heller ikke klart at det er denne ytterliggående tolkningen som er den riktige. Skulle det være tilfelle vil det også være overveiende sannsynlig at en domstol vil gripe inn og begrense omfanget av tolkningen. Om det ikke skjer vil mer eller mindre alle større selskaper i EU måtte haste-flytte sine data til nasjonale eller rent europeiske leverandører. Husk at det ved denne tolkningen ikke er tilstrekkelig at dataene lagres i EU eller ditt eget land, det er eierstrukturen i morselskapet som anses som avgjørende.

Domstoler er normalt sett mer pragmatiske enn datatilsyn. Dette ser man i den relaterte dommen i det franske rettssystemet hvor det franske datatilsynet forsøkte å bruke Schrems-II-dommen til å stanse den franske sentraliserte helseplattformen Health Data Hub (HDH) å bruke Microsoft Azure. Den høyeste administrative domstolen i Frankrike har avvist dette på flere grunnlag:

Schrems-II tar ikke direkte stilling til data som behandles i EU av et europeisk foretak, kun til faktisk intensjonell overføring til tredjeland.

Domstolen mente at amerikanske myndigheters interesse for dataene i HDH var rent hypotetisk.

Dataene som sendes til HDH er pseudonymiserte, og er også kryptert av Azure.

Dommen pålegger allikevel HDH å - i samarbeid med Microsoft - styrke personvernbeskyttelsen i løsningen ytterligere.

Denne dommen kom imidlertid før veiledningen til EDPB, og her bør man merke seg at EDPB ikke mener en subjektiv vurdering av interessen til en tredjestats myndighet er relevant.

EuroCloud

Et langsiktig alternativ kan være fremveksten av flere rent europeiske skyleverandører, som vi samlet kan omtale som "EuroCloud". Om den mest ytterliggående tolkningen av Schrems-II blir stående vil den danne et solid grunnlag for rent europeiske skyløsninger, uten eierinteresser utenfor EU-området. Det finnes i dag en rekke slike leverandører, men ingen som er i nærheten av de tre store amerikanske leverandørene.

Det er også en rekke utfordringer med EuroCloud. 24/7-support krever fulle skift med ansatte som jobber hele døgnet. Dette gir høyere kostnader. Vil det bli tilstrekkelig satsning på en slik løsning om det eneste som holder liv i den er en tolkningsdom? Leverandørene vil være sårbare for at vinden snur, og at EU plutselig tillater utenlandske skyløsninger å bruke dagens eierstruktur, eller godkjenner andre former for organisatoriske løsninger.

Hva gjør Datatilsynet

Dette er kanskje det spørsmålet flest stiller seg akkurat nå. På et nylig seminar om Schrems II holdt Tobias Judin fra Datatilsynet en presentasjon. Han var tydelig på flere ting.

For det første understreker Schrems-II-dommen datatilsynene (DPAene) sin plikt til å håndheve konsekvensene av dommen, og behandle de klager de får inn. Dette sikrer at DPAene ikke kan bruke skjønnsmessige vurderinger til å se bort fra denne dommen, eller utsette saker. Sterkt knyttet til dette: Det er ingen amnestiperiode. Overføringer med overføringsgrunnlag i Privacy Shield ble ulovlig med umiddelbar virkning da dommen falt, og alle andre konsekvenser av dommen er også tredd i kraft. Datatilsynet mener at det nå er så lenge siden dommen kom at vinduet for å forsøke å hevde uvitenhet er lukket. Det planlegges allerede tilsyn for 2021, og det vil være utenkelig at ikke Schrems-II står på agendaen her.

Max Schrems sin organisasjon NOYB har sendt inn 101 varsler til datatilsyn over hele europa for brudd på loven om overføring av personopplysninger til USA ved bruk av Google Analytics og Facebook Connect. I Norge har de klaget inn Sbanken, samt selskapene bak gamer.no og at.no. DPAene i Europa behandler nå disse klagene i fellesskap.

Datatilsynet anerkjenner at selskaper som drifter IT-løsningner i offentlig sky nå er i en krevende situasjon, men er tydelige på at det ikke fritar dem fra å måtte følge til enhver tid gjeldende lovgivning.

Hva blir utfallet av alt dette bråket?

Den mest ytterliggående tolkningen vil skape store utfordringer i Europa, og det virker ikke sannsynlig at denne får stå uimotsagt. Et mer realistisk utfall er at EU på det nåværende tidspunkt ikke forbyr bruk av skyplattformer med eierinteresser utenfor EU, men heller formulerer unntak som naturlig vil innskrenkes etterhvert som "EuroCloud" blir mer konkurransedyktig. Det vil skape insentiver til å bygge ut denne typen tjenester i Europa, noe som gir arbeidsplasser, kompetanse og inntekter, samtidig som det over tid styrker personvernet til EU-borgere.

Når det er sagt har EU de siste årene vist at de er en seriøs pådriver for personvern, og ikke er villige til å bøye av for press fra store kommersielle interesser. Det kan tenkes at EU ønsker å bruke denne saken til å statuere et eksempel som viser hvor viktig personvernet er i EU, og at man kan stole på at dette ikke vil bli svekket.

Det blir også interessant å se hva Amazon, Google og Microsoft foretar seg framover. Det er sannsynligvis hektisk aktivitet på flere nivåer i disse selskapene for tida. Eksempelvis er ikke Max Schrems spesielt imponert over et utspill fra Microsoft for å betrygge kundene i denne sammenhengen.

Og uansett hvilken vei det går kan vi nok slå fast en ting med 100% sikkerhet. I 2021 kommer Datatilsynet på tilsyn til en behandlingsansvarlig nær deg!

Schrems-II – Slutten på skyen?

Every now and then, a library surfaces that change the way you're used to thinking. In this case, it is rethinking the data flow in your React app. SWR provides a complex data store with a simple interface, helping you write simple patterns with less code.

SWR has quickly become one of my favorite tools in my toolbox. The name SWR refers to the caching strategy stale-while-revalidate, and in its essence, the library provides just this, a caching strategy. The library is made by Vercel, the creators of Next.js, and has excellent documentation.

SWR has interfaces to easily cache resources from your backend, regardless of which underlying data fetching library you're using. You provide the data fetching, SWR handles the caching, and stores it for you. Simple as that. However, SWR delivers a much more useful set of tools to manage the whole process of using remote resources.

✨ Getting the data

Fetching data through the SWR is simple. The useSWR hook is your Swiss army knife.

The first argument is the cache key, and the second argument is the fetcher function used to fetch data. Noteworthy here is that the fetcher function parameters must match the cache key argument.

The data object is either undefined (which happens when initially loading) or data from the cache. error is undefined unless the fetcher function has thrown an exception or rejected the promise.

A typical fetcher function can look along the lines of this:

🤔 ...where is the cache and the strategy?

The caching strategy stale while revalidate essentially means that the data will be stored in the cache with the key as the identifier. As mentioned, the data will be undefined the first time the useSWR hook is used until it is loaded.

If the same key is used again, the stale data will be returned immediately, while the internals of SWR revalidates the data in the background. Once revalidation is done and the cache is refreshed, the new data will be reflected in the data object. This way, you can provide stale data while loading new data.

The useSWR hook exposes the revalidation status through the hook, which can be used to show some loading state.

☢️ Mutation

Cool, you've got a great way of fetching and caching data. But now, you might want to change some of that data. Perhaps you've sent an update request to the backend resource but don't want the UI to feel slow by waiting for another update of the data from that backend.

A mutate function is available through the library, and it gives us a few really convenient pieces of functionality. The mutate function signature looks like this:

The key is the cache key, data is the changed data object, and shouldRevalidate is whether or not to trigger revalidation of the data against the resource after mutating the data.

For an even tidier usage, you can pull out the Swiss army knife again, as the mutate function with a pre-set key is given through the useSWR hook; all you've got to do is ask!

Combining these to achieve the initial goal of a fast change while updating a resource, your function would look like this:

You may notice that we prevent revalidation in the first mutation. This is because a revalidation would load the data back to its initial state, as the update request might not have gone through yet.

But what about the other places using the same data?

Mutating the cache will cause the data in all the places using the same cache to be updated automatically!

⛔️ Deduplication

One of my favorite features of the library SWR is the deduplication feature. Deduplication is a long word, which essentially means SWR will prevent multiple uses of the useSWR hook with the same key to revalidate the same resource within a configured interval. In simple words; preventing the same request from being sent multiple times in a short period of time. Instead, a single request will be sent, and the result returned to each of the requestees.

This will allow you to use the same SWR hook across multiple components without any thought to data-flow. Where previously the resource would have been fetched in a parent component and passed down to the child components, you can now simply ask for the resource, and the resource will be made available.

Deduplication is, of course, configurable, and you can decide how long the interval should be.

♻️ Automatic retries

By default, SWR provides automatic retry of failed fetches. By default, this comes with a smart backoff mechanism to avoid retrying too often. You can also roll your own retry functions, which is a great place to insert logging or error tracking integrations, or any other custom behavior. 🤷🏻‍♂️

🏝 Staying fresh is a breeze

Sometimes, we need our data to be up to date, and you've probably already guessed that SWR provides some cool ways of doing this. In fact, there are multiple strategies for keeping your screen filled with the latest and greatest of data.

There's revalidation upon browser-tab focus, which is pretty self-explanatory. This gives you new data when you actually want it.

There's a revalidate upon reconnection, which gives clients with unstable and slow connections a break.

The more classic: revalidation of data upon set intervals. This one is smart, and won't revalidate data that isn't rendered on screen, and won't try to revalidate unfocused tabs or when the internet is disconnected (unless you tell it to).

🔧 Keeping track of the configurations

As you might have understood by now, the useSWR hook comes with a lot of possible configurations. If you want to configure these globally for your react app, you can do so just that by wrapping a part of your app with the SWRConfig like so:

Another tip is to abstract some of the most used caches into custom hooks for easier reuse. If you have a specific configuration for a cache and plan to reuse it, I really recommended doing so.

🏎 Ready to take it out for a spin?

The best way of getting to know SWR is to head over to the documentation and get started yourself. There are great examples and a long list of features to get to know. One of the latest exciting features is integration with the new Suspense API from React, which connects component loading with data fetching.

That's it for me, thank you for reading and happy holidays! 🎅🎄⛄️

4-Dec

Today's posts