I går skrev vi at kulturen i en organisasjon er avgjørende for å lykkes med å levere på målene vi har satt oss og lykkes med vår strategi. Vi snakket også om at kultur er komplekst, nettopp fordi det formes av hvordan vi mennesker samhandler med hverandre. Men, selv om det er abstrakt og komplekst så er kultur noe man både kan og bør arbeide aktivt med i hverdagen.

Det må være et samspill mellom dit du skal, hvordan du planlegger å komme dit og hvordan vi gjør ting her. Endringstakten i verden har økt enormt, og evnen til endring i seg selv blir stadig viktigere. Det betyr også at takten for endring av strategisk retning, innføring av nye initiativer og utføring av nye arbeidsoppgaver har økt for de fleste organisasjoner. Så når vi samtidig vet hvor viktig kulturen er for å lykkes i utførelsen av en strategi er det nødvendig å snakke litt mer konkret om hvordan vi kan jobbe med kultur.

Kulturnettverket

La oss begynne med å se på elementer som er med på å bygge en kultur. Det kulturelle nettverket til Gerry Johnson og Kevan Scholes (1992) gir et oversiktsbilde av ulike komponenter som er med på å forme en organisasjonskultur, som er gode knagger for å diskutere kultur og kulturtrekk.

Det kulturelle nettverket identifiserer seks hovedområder som utgjør kulturens «paradigme», altså antagelsene som tas for gitt i organisasjonen. Historiene vi forteller illustrerer heltene våre, suksessene vi er stolte av og feilene vi husker. Det er med på å vise hva vi er opptatt av gjennom temaene vi snakker om. Symbolene er de synlige tingene som viser hvem vi er og hva vi bryr oss om gjennom for eksempel måten vi kler oss på, hva slags lokaler vi har og hvilken designprofil vi kan assosieres med.

Når vi snakker om maktstrukturer handler ikke dette om organisasjonskartet, men om hvem som har reell makt. Hvem er de største «influencerne» i organisasjonen, for å si det på godt norsk. De er viktige advokater for hvordan vi gjør ting her. Videre har selvsagt den formelle organiseringen noe å si; om vi har en flat eller hierarkisk struktur og hvordan vi har definert kommunikasjonslinjene. Lange byråkratiske beslutningsveier gir mindre fart og kanskje mindre initiativ, enn når ansvar er bredt distribuert i organisasjonen. Den formelle organiseringen sier noe om kulturen vi legger opp til.

På toppen av dette har vi kontrollmekanismene som påvirker kulturen vår, blant annet i form av hvor konkurransepreget den er. Det er mekanismer som lønnssystemer, kvalitetskontroll og insentiver for å motivere til ønsket adferd. Hva vi måler og kontrollerer forteller mye om hvilket fokus vi har, og hva vi er opptatt av, som er definerende for kulturen. Til slutt har vi det vi kaller rutiner og ritualer som er de tingene vi gjør hos oss. Det viser hva vi verdsetter eller hva som er akseptert å bruke tid på. Eksempler på slike rutiner og ritualer er standups, tilbakemeldingsmøter og retroer i hverdagen, men også de større eventene og markeringene som fagdager, julebord eller kick-off. Alle er viktige kulturbyggende elementer.

Ny strategi, men samme kultur?

Som vi skrev i gårsdagens kalenderluke, er en strategi den planen vi har for å nå et mål. Hvis planen bryter med hvordan vi gjør ting her, uten at det tas grep for å justere det, står vi i stor fare for å mislykkes. Det er dermed viktig å forstå hvilke elementer i kulturen som kan fungerer som tilretteleggere for en ny strategi, og hvilke deler av kulturen som kan skape barrierer. Ved å være bevisst på hva slags kultur som bidrar på veien mot målet, kan man aktivt arbeide med å påvirke kulturen til å forsterke strategien, fremfor å hemme den. Når vi skal jobbe med kultur opp mot strategi kan de seks områdene i kulturnettverket være et fint utgangspunkt for å forstå mer om hva en ønsker å påvirke i organisasjonen.

For å vite hva vi trenger å endre, må vi først forstå hvor vi er i dag. Tidligere har vi skrevet om bruken av OCAI-rammeverket for å kartlegge dagens, og ønsket framtidig kultur. Kulturnettverket vi snakker om i dette innlegget er også et nyttig rammeverk som kan gi en økt bevissthet og forståelse for målrettet kulturendring. Nettverket gir oss et bilde på hvilke elementer som finnes i dagens kultur, samtidig som det blir enklere å sette fingeren på hvilke elementer man bør ha i en framtidig kultur, når vi vet den strategiske retningen vi ønsker å bevege oss i.

Det er noen sentrale spørsmål å ha i bakhodet i en slik øvelse, for å bli bevisst på hvor langt unna en ny strategi er den eksisterende kulturen:

Er dette en strategi som de ansatte kan føle eierskap til, og som de ser behovet for?

Er det en endringsdyktighet i organisasjonen, og er de ansatte mottakelige for en ny strategi?

Er det en mismatch mellom de som utformer strategien, og de som forventes å utføre den?

Er det subkulturer i organisasjonen, som kan oppleve en ny strategi på ulike måter?

Disse spørsmålene gir en pekepinn på utgangspunktet ditt: Hvor langt unna dagens organisasjonskultur er vi, og hvor omfattende kulturendringer tror vi må til. Deretter er det en nyttig øvelse å gå igjennom hvert punkt i kulturnettverket, og se på dagens tilstand. For å få den nødvendige innsikten kan det være verdifullt å gå i gangene, observere, snakke med folk uformelt, men også gjennomføre dybdeintervjuer for å forstå mer. Kanskje viser det seg at en får opp ulike sentrale elementer i kulturnettverket, for ulike subkulturer i organisasjonen.

Når vi får en forståelse for dagens tilstand er det behov for å gjøre en vurdering av hvilke elementer som er formålstjenlig for å lykkes med den nye strategien, som man bør fortsette å forsterke eller bevare, og hvilke kulturtrekk som er ødeleggende. Det er nyttig å tegne opp et bilde av hvilke elementer en ønsket fremtidig kultur bør inneholde for at vi skal lykkes med en ny strategisk retning, og gå aktivt inn for å tette gapet mellom dagens situasjon og ønsket fremtidig situasjon.

Ny leder. Ny strategi. Ny kultur?

La oss se på et eksempel, der en organisasjon har kunnet fungere godt i en bransje som ikke har blitt utfordret av innovative løsninger. Organisasjonen har sterke fagpersoner med høy teknisk kompetanse, og et høyt internt fokus. Men nå ønsker en ny sjef å utnytte vekstpotensialet i å gå fra et produktorientert selskap til mer tjeneste- og kundeorientert selskap med eksternt fokus. Det krever endrede holdninger, nye måter å gjøre ting på og en stor endring i hva de opptatt av. I dette tilfellet holder ikke for den nye sjefen å lage en god strategi for den nye retningen, hun må også forstå den eksisterende kulturen som rår i dag. Den sterke fagkulturen som er bygget opp over mange år, og har gitt suksess tidligere, skaper potensielt store barrierer for å kunne gjennomføre en ny strategi. Det å skulle utforme tjenester basert på brukerens behov er et helt nytt tankesett når de grunnleggende verdiene handler om sterke fageksperter som er vant til å bestemme selv.

Ved å gå opp kulturnettverket for dagens situasjon kan den nye lederen få et bilde på de viktige historiene, symbolene, uformelle maktstrukturene og så videre, som definerer selskapet i dag. Sammen med denne øvelsen bør hun gjøre en vurdering av hvilke trekk ved dagens kultur som vil være hemmende for den nye strategien — for eksempel at historier som fortelles om fagpersoners standhaftighet mot vanskelige kunder er suksesshistoriene. Hvordan kan hun istedet løfte frem og begynne å skape engasjement for historier som handler om fantastiske brukeropplevelser i møte med tjenesten?

En ofte anvendt metafor for hvordan ledere kan forme organisasjonskulturen, som kan nevnes opp mot dette eksempelet, er begrepet Ledere som kulturelle arkitekter. Det handler om den store innflytelsen en leders eksempel har på organisasjonskulturen, men ikke minst også hvordan en leders prioritering av aktiviteter for å fremme kulturbygging, sammen med folkene i organisasjonen, er av stor betydning for å få det til. En leder som velger å prioritere kultur har gode muligheter for å påvirke den, og dermed også større muligheter til å lykkes med endringer i selskapet over tid. For å få til kulturendring er det avgjørende at nøkkelpersoner som andre ansatte ser opp til tar eierskap og er advokater for en ny ønsket adferd. En kultur formes nettopp av at vi omgås hverandre og observerer hverandres adferd og væremåte for å forstå hvordan vi gjør ting her. I eksempelet over er det nok sentralt for den nye sjefen å finne slike interne advokater for kulturendring, som kan gå foran som gode eksempler, og definere tydelige aktiviteter for å skape endring.

Kultur trenger tid og tålmodighet

Kontinuerlig arbeid med kultur bør altså være en integrert del av det å være i bevegelse og å endre seg. Hvordan ønsker vi å gjøre ting her? En kultur endres ikke over natten, nettopp fordi menneskers adferd ikke endres over natten. Det tar tid, og det krever tålmodighet og målrettet arbeid.

Ved å bruke kulturnettverket til å kartlegge dagens historier, symboler, maktstrukturer, organisering, kontrollmekanismer og ritualer vil vi få et tydeligere bilde på hva som er viktig i dagens kultur. Samtidig er det å kartlegge hva som er nødvendig for å levere på en ny strategi, altså hva en ønsket fremtidig kultur bør inneholde for å kunne lykkes, viktig å være bevisst på. Til sammen gir dette et bilde på hva vi må slutte med og hva vi må begynne med, og hvilke konkrete aktiviteter vi kan igangsette for å skape endring. Men det er jo bare begynnelsen. Derfra handler det om å jobbe med kultur som en del av det å drive — og å delta — i en organisasjon.

Vi kan snakke mer om kultur, snakke mer om hva som former oss, og vi kan til en viss grad sette det i system. Og vi må huske at det koker ned til mennesker som skal fungere godt sammen i et trygt miljø, som fremmer adferden vi trenger — for målet vi ønsker å nå. Det å ha et bevisst forhold til kulturbygging sammen med strategiutvikling, er en god start.

Kan man forme kulturen når man arbeider med strategi?

He sees you when you’re sleeping, he knows when your awake, he knows if you ‘we been bad or good so be good for goodness sake. This is a line of a popular Christmas song. It obviously refers to Santa Claus. However… What if this is true, not only for Santa, but for large companies worldwide. We’ll take a closer look on the data you give and the repercussions.

In today’s modern world, our phones are an integral part of our lives. We carry it everywhere, whether it is at work, when we are out and about or in the hospital. In every situation, our phone is nearby. The phone gives us easy access to information, communication and you might say there is an app for everything. If you need to see the local weather, it is right there in your phone, the same goes for the directions to the cinema or if you want to know what your friends are up to – check your phone. And it is all free of charge. Well, not exactly, nothing is free.

The payment

Although you might not spend any money on an app, the app still collect a form of payment from you. Your information is the currency and it is collected through every action you make on the internet and in the apps on your phone. Your device information, your likes and dislikes and your email is just some of the data they might collect. And the hottest commodity is your location data. You might say the phone is a tracking device you wear 24/7.

Some of this data, we give willingly. This can be photos, statuses, interests and in some cases, who your friends are, where you live and so on. It is easy to believe that the information you give to a specific app will be contained within the app. This is often not the case. Selling consumer data is a multi-billion-dollar industry and your data is sold for targeted marketing, to analytics companies and to research.

You might not know what you do online every day, but the 50 apps you have on your phone does and what you do says a lot about you.

I have nothing to hide

You might not know why you should care about the fact that your data is collected, you have nothing to hide. A couple of emails with “special offers” in terms of marketing might not be the worst thing. But here is why you should care.

There are no restrictions on who can by this data and more parties are showing interest. In fact, earlier this year the Wall Street Journal found that the U.S government bought commercially available location data and used if for detecting undocumented immigrants or others trying to get across the U.S border. It also played a part in discovering a drug smuggling tunnel beneath the border between USA and Mexico in an abandoned KFC restaurant.

The police usually must acquire warrants to get this kind of information on your phone, but what if they can just buy it commercially? When is it ok to use these data and when is it surveillance? Like the comparisons the cryptographer Bruce Sneider draws: If the government said: “Whenever you make a new friend, you must inform the police”. We would laugh, but we willingly tell Facebook and Facebook informs the government. Or if the government says: ”Whenever you send a message or write a letter or send a note to somebody, send us a copy, please”. That would never happen, we would not do that. However, Google does it for you.

Throughout your days of using your phone or computer, you give pieces of information to each application or website, and although this data is supposed to be anonymous, it is not hard to connect the missing pieces. When seeing all the data from different sources together and by adding simple searches on specific information, your name and identity will be found and the data will no longer be anonymous. This was illustrated when The New York Times bought commercially sold location data. With this data they could easily find the person to whom the data belonged. Even though the name of the woman they were tracking, was not among the bought information, they deduced a lot about her. They could see that she was at a weight watchers meeting, doing a procedure at the dermatologist and by the amount of time she was spending at a school, she was most likely a teacher. The phone tracked her every two seconds and giving information about her she found disturbing.

NRK, a TV-channel in Norway did the same. By analysing the person’s patterns, they could see where he spent his days and where he spent his nights. By this information alone one can easily find out who lives at the address he slept at and who works at the address he was during the day, to find the name of the person using the phone. They even found that the person was going to interviews with another company, which he had not told anyone. And some time after these interviews he change his place of work.

All your data collected is a foundation for through analysis of you as a person. They can put you in boxes and make assumptions about you. Sometimes they are right, and sometimes they are not. If you are classified as likely to become a gambler, could it get in the way of you getting a loan in the future? Or could marketing pray on your weaknesses to get you to buy something you don’t need? You can easily be manipulated by companies gaining in-depth knowledge about you. This was proven by “Folkeopplysningen”, a show in Norway that informs the public about different topics. In one episode they manipulate an intelligent man to give up his company, his life’s work, purely based off of information found on him online. By his likes on Facebook, they could perform a personality test. By the pictures on Instagram they could see that he liked to work out, that he loved superheroes and all kind of other information. They staged a day for him to be considered for a super hero-part in a Hollywood production. All he had to do was give up his business. This is something he probably would never do if it wasn't for being manipulated for an entire day based on the information the TV-show could find on his social media and other online accounts.

What about GDPR

If you live in Europe, you have probably heard of General Data Protection Regulation or GDPR. GDPR is a legal framework that sets guidelines for the collection and processing of personal information from people who live in the EU. It is there to give consumers of the internet more right as to what data is collected.

As a consumer, you notice it best by having to accept the use of cookies on the web or by giving permissions to the apps of which data they can have access to. However, the government can only do so much if consumers keep accepting the usage. The web or phone applications often make it hard not to accept by writing the terms incomprehensible or too long. In some cases, you must even go to completely different applications to turn it all the way off. As long as it is easier to accept, we will accept. It can also be difficult to investigate where the commercially sold data comes from because not all companies are located in Europe and in some cases the terms does not specify all the different ways your data can be spread.

Off the grid

By highlighting some downsides of sharing data, you might feel the need to stop sharing data all together, but it is important to state that data sharing is not all bad. First of all, getting commercials tailored for you can be a good thing as you can get offers based off of previous purchases and get more effective services. Another great thing about sharing your data is that it can benefit scientists. Research on cancer be done studying patient data, why we are the way we are can be explored by looking at data from Facebook and so on. Looking at large sets of data can give us a better understanding of the world today.

The thing to think about is that you do not have to share your data all the time and to every app or website. For instance, a flashlight app does not need permissions to track your location. There are ways of sharing less data by limiting the apps on your phone to only sharing location data when the app is used or turning it completely of when you are not active on your phone.

When it is all said and done it is your data.

The data you give

What is Recoil ?

Recoil.js is a new state management library for React — offering a React-ish API and a simple and powerful way of dealing with global, asynchronous and derived state 🔥

Recoil aims to solve some specific challenges when working with modern React apps like flexible shared state, derived state and global observation. And like React, the original Recoil team works at Facebook.

If you have worked with React it should seem familiar. Just take a look at this example. First we use React with useState() to increment a number:

Now, making our state global is pretty straightforward using Recoil. All we need to do (almost 😇) is to replace useState with useRecoilState.

That's pretty cool! Not convinced? Keep on reading... 😄

Using Recoil - Examples

The examples below are taken from a simple demo application called FoodTalk. The app lets you sort, filter and search for recipes. Take a look at the demo or the source code on github.

Its a simple app, but it uses Recoil to solve some known challenges pretty well.

Atoms

An atom is simply a piece of state. It's like using react's useState(), except that any component can subscribe to it. By updating the atom value, all subscribed components will be re-rendered. In our recipe application we use atoms to store different types of state, like a search input:

To read and write to this atom we use useRecoilState.

Selectors

Our application need to handle a combination of state (derived state), and that's when we use a selector. In our recipe application we use a selector to return a filtered list of our recipes. Selectors are also memoized, making sure our performance is maintained.

We can use the same useRecoilValue() on selectors as we do on atoms. The cool thing here is that if our search state changes, our selector state will trigger a change as well.

Finally we need to add some spinners with React Suspense, which is supported out of the box.

Take a look at github to see all the code, which is also written in TypeScript. 😁

So what's great about Recoil ?

Libraries for React are constantly appearing, but Recoil.js is much more than “just another library”. Compared to other state libraries for React, Recoil feels like a fresh breath from the future - and it's great in so many ways:

Tailored for React

Recoil is made specifically for React and offers close compatibility with features like React Concurrent mode and React Suspense as we saw in the example. The team also claims to support new React features as they become available.

Easy to learn

When I tried Recoil I realized how complicated and difficult other state libraries like Redux were.

Recoil offers a simple API, with semantics and behavior in a known reactish manner. It also comes "boilerplate-free". All you need to get started is to wrap your code with RecoilRoot.

Flexible and powerful

The concept of atoms let us isolate state in small pieces, making it very flexible. By using selectors we can easily combine pieces of state and move between being synchronous and asynchronous without modifying the components. It's also easy to observe and/or persist the entire state - which use be used to synchronize our state with a server or debug our app with time travel.

Read more about the motivation for Recoil here.

Final thoughts

The concept of derived state is very powerful, and atoms and selectors let you build a flexible and maintainable application. Its super easy to get started, and it really feels like a natural extension of React. It might not be a silver bullet, but if you need a way to handle distributed state in a simple manner - Recoil is your friend. 👍

Recoil is still in alpha and parts of the API might change, but based on the fact that Recoil is created by a Facebook team and currenty has 10k stars on github - I would say it’s pretty safe to try out. 😄

I recommend watching Dave McCabe's presentation of Recoil. He explains why they made Recoil and demonstrates the power of atoms and selectors.

Recoil.js - State management for React 🔥

Reification. Like many other concepts, it can be applied in a number of different ways and it might carry slightly different meanings depending on the context. According to this definition, reification is simply the act of representing something abstract in a physical way. In Java, on the other hand, the term is used in the context of which types that are available to us at runtime. Additionally, in Kotlin we actually have a modifier keyword built into the language, namely reified. In this article we'll take a closer look at how reification and type erasure are connected, and more specifically how we can combine inline functions and reified type parameters in Kotlin to achieve things in generic functions that we normally would not be able to.

A brief introduction to type erasure

In order to get a good picture of how and when reification can help us, a little background is needed. Just like Java, Kotlin applies type erasure to generic function type parameters when our code is compiled. In other words, information about the actual type of our type parameters are by default not available to us at runtime. We can illustrate this by looking at some examples. Let's say we have the following generic functions which simply takes an argument of a generic type G and returns it:

To see what actually happens "under the hood" we can look at the decompiled bytecode (*). The functions we declared above will be decompiled to the following Java code (note that some annotations and other generated artifacts have been removed in this and the following examples, in order to make the them more terse):

Here we're observing how type erasure and bounded/unbounded type substitution have been applied by the compiler. Our simpleGenericFunctionWithoutBound-function has had its type parameter replaced by the concrete type Object. Similarly in simpleGenericFunctionWithBound it has been replaced by ExtendableClass, which we defined as the upper limit for our type parameter.

As a result of this substitution, there is no way for the JVM runtime to derive any information about the concrete type of the supplied argument when these functions are being invoked. We can invoke the generic functions with arguments of any type adhering to the bounds, but type information will ultimately be lost on the way. Put in another way, generic function type parameters are by-default defined as non-reifiable.

* The IntelliJ IDE comes with a handy tool for inspecting kotlin bytecode and its decompiled Java counterpart. This can be found under "Tools > Kotlin > Show Kotlin Bytecode".

The reified modifier keyword

So how can we reify our type parameters in the generic functions we defined above? Unfortunately there's no escaping the type erasure that the compiler applies. Instead, Kotlin can help us yet again with some of its language specific magic. We can modify one of the generic functions we defined earlier, and invoke it like so:

The inline modifier keyword tells the Kotlin compiler that we want to perform inline expansion of the function at the call-site. We will not go into the details of inlining (*), but it has some interesting implications which Kotlin can take advantage of to get around type erasure. Essentially what happens is that the content of the declared function body is duplicated and included wherever we're invoking the function.

Since we have information about the actual type of the type parameter at the call-site, maybe there is some way to carry over this information to runtime? This is what the reified modifier keyword instructs the compiler to do. Let's take another look at the decompiled byte code of our updated function:

Here we see how Kotlin has gotten around type erasure of type parameters: since inline expansion is performed, additional information can be included at the call-site - i.e. Kotlin can provide us with runtime information about the actual type of generic function type arguments! Specifically, in this example we now have access to the concrete type information about the parameter we invoked simpleGenericFunctionWithoutBounds with: ExtendableClass, on which we're accessing ::class.

Hopefully this article has helped in demystifying the concept of reification a little, and illustrated how we may take advantage of this concept to do things we otherwise would not be able to through the use of the reified keyword. Whether it is using the Reflection API as we did in the example above, using it for type checks and type casts, and so forth.

* You can read more about the inline modifier keyword in the Kotlin docs.

Bring your generic function type parameters back to life with the reified keyword

Jennifer Vessels has a unique experience with innovation from Silicon Valley and Oslo. Her clients include Adobe, Cisco and LiveNation as well as Innovasjon Norge, Tandberg and numerous Norwegian startups.

How would she describe the difference in how innovation works in these two places?

What can we learn from each other?

With Jennifer Vessels (Future Ready Innovator at Executive Growth Alliance), Jens Andreas Huseby, Rasmus Bauck and Moquan Chen.

Oslo vs Silicon Valley - what's the difference?

Stage freight and the history of the human species

In yesterdays hatch in this calendar, we learned how stage freight can be explained by the history of humans and we got to know more about the evolutionary aspect on why stepping on to a scene to present in front of other people can make our whole system to ring the alarm bell and telling us that this is something dangerous.

What can you do to handle stage freight?

To help you with what you can do yourself to handle the situation when stepping on to a scene (or pressing the button to share your screen in a video meeting) we have collected some tips and tricks that hopefully can help you prepare so you can stay calm when presenting.

Practice how to enter the stage

Physically test out how to enter the scene and find a way to stand up that that feels comfortable for you.

Film yourself

Pick up what ever you have available (phone, camera, pc) and film yourself. This might feel weird, but remember it is only for yourself. It can help you to hear both the pace and volume of how you speak and move.

Keep it simple

If you use words that are complicated or hard to pronounce or sentences with too many clauses it easy to end up stumbling on the words. Try to use words that are both easy to understand for the people listening - and for you to pronounce.

Make time for relaxing before presenting

If you are feeling nervous to present in front of a big audience its a good plan to plan to have moment of time before presenting to just lay down and relax your body and mind.

Have a pep talk with your self

Take a couple of deep breaths and tell yourself positive things.

Have a stretch

Move your head from one side to the other, lift your shoulders and stretch your back, legs and arms to get rid of physical tention in your body.

Think about your body language

Walk up steady with your head high and with a proud body language. Think about when to use your hands - and when not using them, try to keep your hands together.

Make your own ritual

To come in to the right mode both for your body and mind try setting up a short ritual that you do before presenting.

Examples can be:

Stretch your legs, arms and back

Massage your stomach

Take a deep breath and hold it

Breath out with three short out breaths while keeping your lips tight

Relax in neck and shoulders

Cross your arms on your chest

Through your arms up to breath in deep and fast

Through your arms down to breath out fast

Massage your jaw

Walk around and try to notice things you like in the room

Tips & tricks staying calm on stage

Today and tomorrow we are excited to have a guest writer sharing some of his thoughts on the topic of functional programming: Dillon Kearns, known for projects such as elm-graphql, elm-typescript-interop, and the Elm Radio podcast! We hope you enjoy!

One of my favorite things about functional programming is the ability to work and think in a very localized area of code. Let's talk about some of the patterns that make that possible.

I won't go into how immutability, managed effects, or lack of global variables help us reason locally - although they really do! What I want to focus on here is the power of individual transformations composed together, rather than making one big transformation. This concept is sometimes called a Combinator.

Top-Down Vs. Bottom-Up Transformations

In my JavaScript days, I remember a particularly tricky area of code where we had a big list of data in a format defined by the server. We needed to take product listings, pull out specific options and inventory information, normalize them, and then apply filters from the UI to show/hide and sort search results.

There were deeply nested fields, and some incongruities in the shape of the data. Some values were nullable. Some had specific normalization we needed to apply to get data from multiple sources to match.

We had a lot of big unit tests to make sure things were working. Even so, it was so difficult to go in to our series of lodash function calls and find where you needed to make a change. And once you did, you would want to make sure you added several new test cases to make sure you didn't miss a spot or mishandle a special case.

We would sit in awe as the person most familiar with the codebase correctly traversed the nested arrays and objects to get to the exact right place and make a change on the first try. It was a lot to hold in our heads, and it was quite error prone.

The challenge was that using that paradigm to normalize JSON data required thinking of the data as a monolith. We certainly abstracted out functions to help with parts of the normalization. And we used lodash to do functional style mapping over the arrays of data and key-value objects. But mapping over arrays and objects only gets you part of the way there. We still needed to keep a map in our heads of the structure of the data so we could go into a specific area, traverse it, and change it.

We weren't using TypeScript at the time, but even if we had been, the challenge would remain of having to navigate the structure from the top down in order to add a new transformation. Type-safety is a huge help, but it only gets you part of the way there to the benefits of localized reasoning.

What is a Combinator?

The term Combinator is used because you can combine the smaller units to build up the whole. A Combinator is the idea of building something up by combining small "base" values into more complex ones. The values could be a JSON Decoder, a syntax parser, a random number generator. The key is that the simplest form can be composed together to build something complex - but (this is important) the simple thing and the complex thing are the same kind of thing!

Combinators share some parallels with the concept of recursion (defining a function in terms of itself).

This recursive definition can be read as what a fibonacci number is (declarative), instead of how it is calculated (imperative). No mention of how to loop over in each iteration - it's simply written in terms of itself, like a math equation. It's pretty close to how you would teach fibonacci to a human. It just so happens that computers can understand it, too!

Recursion is a good analogy for Combinators:

A Combinator is declarative (not imperative)

A Combinator is either defined in terms of other Combinators (analogous to a recursive self-invocation), or it is a "base" combinator (analogous to a recursive base case)

Let's look at an example of a Combinator in Elm. The elm/json package is how you turn untyped JSON data into typed Elm data (or an ErrResult value if the structure doesn't match).

What are nameDecoder and birthdayDecoder? They're both some kind of Decoder. We're combining them. Note that we can think about the Decoders here at a high-level, and drop into the details as needed.

At some point, following our Decoder definitions we will find a Decoder that doesn't just compose Decoders, but directly resolves to a value (similar to our recursive base case).

Decode.string is going to resolve to some value. But we can compose Decoders together in more ways than just combining them or reading JSON values within a JSON property (like "full-name").

Another key technique for a Combinator is that we can transform them.

If we follow the definitions, we finally end up with a direct "base" Decoder for birthdayDecoder.

This time, we are transforming the raw String into an Elm Time.Posix value. iso8601StringToTime is a function that takes a String and gives a Result String Time.Posix. When we transform the "base" Decoder (Decode.string), the type changes with it.

These are some of the basic building blocks of a Combinator. Let's explore how these building blocks lend themselves to breaking down a problem into smaller pieces, without needing to pull in all the surrounding context.

Combinators are trees

With the JS code where I was working with JSON from the server, I was working on the data top-down, and carving out new "seams" to transform data as needed. In contrast, with a Combinator you already have a place to work. You can visualize a Combinator as a tree. You build up a complex Combinator from the bottom up, and you can think locally about any sub-problem (think sub-tree). Each sub-problem is like a little box that you can work in. Once you find the right box, you don't need to worry about what's outside of that box, you can just focus on what's inside the box you're working on. You don't need to create a new point to make your transformation, because it already exists.

For example, if we need to normalize the names we're getting from the server, we just find the right box and work within that.

Or if the name may have a different format, we just make that change within our box, blissfully unaware of the JSON structure surrounding our box.

Joël Quenneville has a nice visualization of this concept in his article Elm's Universal Pattern.

Intermediary Data

Another quality of transforming data in an imperative style is that it can happen in multiple passes. Each iteration to transform the data can yield an intermediary data format that isn't useful except as input to the next transformation phase.

By using a Combinator, you can avoid passing data through various transformation stages. A Combinator represents a set of operations/transformations. You don't actually use the Combinator until you've built it up. If you need to tweak something, you transform the Combinator. So the data is never exposed in your app in an intermediary format.

We are building up both the JSON Decoder and its type information at the same time. Since the types and operations/transformations are in sync, we are guaranteed to either

End up with well-typed data (happy path), or

End up with a clear error

I really love this quality of the Combinator pattern. This gives you explicit, clearly defined paths, with types fully describing the possibilites. Take a look at Alexis King's article Parse, Don't Validate for some great insights about that.

Combinators Beyond JSON Decoders

This pattern isn't specific to a language, like Elm, or a domain, like JSON.

You can use these same concepts in TypeScript with a library like io-ts. And you can apply this thinking to a lot more problems than JSON. Some examples in the Elm ecosystem:

elm/random

elm/parser

Creating fuzzers (property-based test data) in elm/test

elm-graphql

elm-validate

Next Post

Thanks for reading! In the next post, I will share lessons learned about this technique and how it made me realize why I loved one type-safe library I built, and am now rebuilding another to learn these lessons a few years later.

Combinators - Inverting Top-Down Transforms

It is time to unleash the christmas spirit hiding behind that noisy fan in your computer. In this article, we will use shaders in WebGL to make animations no one could imagine in JavaScript before.

All good developers will get presents from Santa. So I am absolutely sure that you have read the previous calendar entry 3D with WebGL and three.js. Although, if you have dabbled in WebGL before, that is not strictly necessary. All of the final code can be found in our repository

A shady proposal

The best thing about shaders is the unlimited supply of puns around the word shader. They are small programs written to be executed for every point and every pixel on the screen.

Every 3D game you play is made up of many three-pointed polygons that are rendered onto the pixels on your display monitor. The position of all the points, and the color of all the pixels, are the output values of these shaders.

three.js comes with default shaders that cover the most basic use cases. But we are not basic, are we? No, we are special! To write our own shaders we simply replace each material with a special ShaderMaterial:

These are the parameters:

uniforms: A record of global variables passed from the JavaScript code to the shader code. Useful for passing things like time, light positions or texture images

vertexShader: The shader program (as a string) to be run once for every point in all the polygons

fragmentShader: The shader program (also a string) to be run once for every pixel that make up those polygons

We are going to make a sphere that wobbles when we press it. This is our shady proposal! We start with a sphere with diameter of 1, consisting of 128 times 256 facets. Like a disco ball!

This is added to the scene just like any other stuff:

Now it will be rendered to the screen, but it won't work of course, because we have to define the uniforms and shader code!

The uniforms are simply a JavaScript object with entries for each variable. I am going to use time to track the neverending passing of time (in seconds). And then I am going to have the clever little animationTime to control the wobble animation, where 0.0 is the start and 1.0 is the end:

I will update these uniforms for every rendered frame:

Check out these shades

That was all pretty much boilerplate, if you ask me! Now we are ready for the actual shader code. It is written in GL Shading Language, which is very close to our old pal C. This is the vertex shader code:

What the hell is going on here? Well, it turns out, a lot of math. We have 3- and 4 dimensional vectors (vec3 and vec4) and we have matrix multiplication (* is used for both matrix multiplication and simple scalar multiplication).

This is the reason people don't dabble in shaders! Let us not understand all of this, but simply modify (fancy word for hack) the code to do fun things!

The resulting output gl_Position is the "2D position" of the point as rendered on the screen, and the input is the point's position in 3D space on the 3D sphere. So all this trouble is simply to tell the GPU where to render all the points on the screen. But we can modify the point's position before these calculations, and by that making the sphere wobble.

Let us calculate an offset vector that is to be added to all positions. The offset should be a bump in the direction of the surface normal, with a certain amplitude:

There are many ways to make random bumps. But we do it simple, and combine sine waves in each dimension:

To make our sphere chill down easily, we reduce the frequency and amplitude as animationTime goes by:

Shaders come in pairs, so we need a fragment shader to give color to our pixels. Since the vertex shader was such a head exploding ordeal, we keep it simple and use the surface normal vector as RGB color value:

Finally we have our result. Check out those curves!

Sandbox and final code

You find all the working code in our repository. You can also play around in the sandbox below:

Raw GPU power with shaders in three.js

Currying (👈 which you read about in yesterday's post) enables partial application, which lets us split up functions into small logical building blocks which are easier to both read and work with.

In programming languages where you don't have currying, you'll get a compiler error if you do not provide all the arguments to a function. As you've just learned yesterday, however, currying will instead return a new function if you provide a subset of its arguments. Such a function is known as a partially applied function.

Let's see a simple example.

We all want hard presents for christmas, lets write a function to check that a present is hard using currying. We will use the function String.contains from the Elm core library. This is it's type signature👇

It takes two Strings, checking to see if the first String´ is part of the secondString, then returning a Bool of True or False. Here we can make use of partial application to see if a present is hard or soft by making a function that receives the description of a present.

We partially apply the String.contains function to write a function to check if a present is desirable or not. The second String will be supplied to the String.contains function where the isHardPresent function is used.

Simply supply the description of the present and the function will tell you if the present is worth buying. If we want to be a little more effective when christmas shopping, we can do this operation with lists of presents by using the function List.filter.

The filter function takes a predicate and a list. It then only keeps elements that satisfy this predicate.

We only supply the predicate argument to the List.filter function here, and can now use this function on all our lists of presents. As you can see, partial application can be used in a number of useful ways! And just like that you have good present/bad present filter function ready to accompany you when christmas shopping🎅

Partial application of functions!

You've got a Kubernetes cluster running your application on Google Cloud Platform (GCP), managed by Terraform. Metrics from your cluster, from your app or any other instance in our cluster - what to do with them? Sure, you've got Metrics Explorer in GCP that lets you play around with the metrics. Another option is to create a monitoring dashboard by manually selecting the metrics, aggregations, alignments, etc. to be shown. However, this can also be managed with Terraform, allowing a lot more control over your monitoring.

Defining a Stackdriver monitoring dashboard

While Terraform has a lot of thoroughly documented resources - the resource defining a dashboard in GCP is really basic. The google_monitoring_dashboard resource takes only one argument - the dashboard configuration defined as JSON.

In this example we'll create a dashboard that displays the restarts of the pods in our cluster. There are two pods - one frontend pod and one backend pod. We want to display a graph for each - showing the restart count of each one. Thus, two widgets have to be created. Both pods are correspondingly labelled with app=backend and app=frontend. For each widget to display the desired metric, the correct filter have to be applied.

Applying this Terraform module creates your dashboard, My Christmas dashboard, where the widgets are shown in a grid. It should look something like this:

Adding more widgets is as simple as filtering and aggregating the metrics as you wish.

Something is wrong - alert me!

To set up alerting in GCP Stackdriver, you'll need a notification channel. This can be manually set up in Stackdriver, but Terraform can handle this as well.

The google_monitoring_notification_channel Terraform resource is used to create a notification channel. Notification channels can be channels such as e-mails, SMS' or a Slack channel. For example, a Slack notification channel can be added as follows:

Now, we can use this notification channel when we define our alerting policies. We'll define alerts for the widgets we created in the dashboard. An alerting policy is created with the google_monitoring_alert_policy, like this:

These alerts will fire if the threshold defined in condition is met. The condition_threshold for both pods, in this example, is when the pod restarts more than 5 times over a period of 60 seconds. An alert message is then sent to the selected notification channel, the Slack channel in our case.

Application specific metrics

This article highlights how to monitor and alert based on metrics from a Kubernetes container. These metrics are automatically exported to Stackdriver. If Prometheus, for example, is scraping metrics from your applications, you'll need the Stackdriver Prometheus sidecar to export the metrics to Stackdriver. The sidecar is added here.

Go ahead, do it!

Managing monitoring and alerting with Terraform is super easy, and versioning the monitoring of your cluster is so helpful ifwhen you screw up. Instead of messing around in the metrics explorer and creating monitoring resources on-the-fly; mess around in the metrics explorer and Terraform the monitoring! You and your team will not regret it.

Terraform managed monitoring and alerting in GCP Stackdriver

Spar i fond, sa de. Det er smart, sa de. Men løsningene, derimot, er ikke det.

Jeg har alltid elsket pengetrær. Sparegrisene sto smilende på rekke og rad i barndomshjemmet mitt. BSU-kontoen ble opprettet så fort jeg kunne, og selvfølgelig alltid fylt opp til randen 1. januar hvert år. Neida, så jeg har alltid elsket pengetrær. Enten i fysisk eller digital form.

Trodde jeg.

For la meg repetere det jeg nettopp påsto en gang til, som om jeg viser deg en keynote, og prøver å skape et poeng som du skal bli nysgjerrig av:

Jeg har alltid elsket pengetrær. Enten i fysisk eller *strek over* digital form.



Fondsparing = anti antirynkekrem

Jeg som trodde jeg var nokså teknologisk kyndig og pengesavy, fikk meg en real knekk da jeg begynte å deale med fondssparing i SpareBank 1. Løsningen er som en evig lang gjettelek av “hva skjer når du trykker på denne knappen, tro?”. Og i det du tror du har forstått navigasjonen, har de søren meg lekt Facebook og lansert en ny komponent som bare kødder til hele flyten.

Til alle banker der ute: Ikke lek Facebook. Ikke tro at kontinuerlig design løser alle problemer for kundene deres. Spesielt ikke når det gjelder deres økonomiske fremtid.

Fader, altså. Om jeg bare hadde investert i en skikkelig rynkekrem i stedet. Da hadde jeg sikkert ledd hele veien til banken. Uten en eneste smilerynke. Som dette:



Men i stedet for ser jeg slik ut:

Jup, fondsparing har gitt meg rynker, du trenger ikke å si det. Jeg ser rett og slett gammel ut. Gammel og fortvila. Fondsparing har gått på helsa løs.

Det hører dog til historien at jeg, før jeg begynte å investere i fond, ikke opprettet aksjesparekonto. Du vet, den kontoen du må opprette for å kunne shuffle kjøp og salg av aksjefond skattefritt, før du eventuelt putter pengene og den da beskattede avkastningen i en bankkonto.

Det var dumt av meg. Men min mestringsfølelse av å investere i fond raste like mye som aksjene i DNB Health care A da jeg endelig fikk surra meg til å opprette en, også, skal jeg si deg.



Rådgivningsartikler er ikke kommunikativt og direkte nok

Selv om SpareBank 1 har informative og godt skrevne rådgivningsartikler om fond- og aksjekjøp, savner jeg betryggende mikrotekster, sånne korte tekster som dukker opp mens du gjør ting i en digital tjeneste — spesielt når du oppretter en aksjesparekonto.

OG, når dét er sagt, hadde jeg aldri hatt noe vondt av en liten, vennlig dult nederst i mobilbanken, som kanskje sa noe som “Hanna, du sparer og sparer i fond. Men NÅ er det vel kanskje på tide med en aksjesparekonto? _Opprett aksjesparekonto_”. Og så hadde jeg trykket meg videre inn der, og fått god veiledning underveis på hvordan jeg kunne knyttet denne aksjesparekontoen opp til mine allerede godt etablerte investeringsplaner, sparemål og månedlige cashflow. Først DA hadde vi begynt å snakke.



Ubehagelig uoversiktlig

Bare forsøket på å organisere en pengeflyt som beskrevet over, ga meg 40 nye grå hårstrå, økt puls, hetetokter og indre uro. Har fondsparing kastet meg rett inn i overgangsalderen eller er dette bare en kroppslig reaksjon på ubehagelig brukeropplevelse av noe som betyr ganske mye for meg? For er det noe dette er, så er det ubehagelig.

Ubehagelig å føle at du ikke har kontroll på dine oppsparte midler. Ikke vite hvor fremtidens økonomi befinner seg (jaja, hvem vet vel det uansett når en investerer i fond), eller hvordan du får koblet aksjesparekontoen din opp til ulike beholdninger og sparemål. Alt i løsningen ligger liksom så til rette for at fondsparing skal oppleves strukturelt, men når det kommer til stykket, skorter det på et symbiotisk forhold mellom det logiske og teknologiske.

Det er rett og slett for mange veier til rom i form av en evig runddans for hvordan du liksom på en smart måte skal kunne kjøpe andeler i et fond. Og på den andre siden er det, ironisk nok, for trangt rom for muligheten til å kjøpe fond med aksjesparekontoen din. Slik oppleves det i hvert fall for meg. Aksjesparekontoen min har blitt problemet.



Ikke aksjesparekonto vs. aksjesparekonto

For ja! Det er dritlett å shoppe fra brukskontoen — altså sette brukskontoen opp som belastningskontoen! Det har jeg gjort lenge nå. Jeg følte meg som Jordan Belfort på Wallstreet, shoppet litt andeler her og der, fulgte nøye med på rentene hver dag, spekulerte i hva som kunne være lønnsomt å spare i, og tenkte at herfra går det bare oppover! Så opprettet jeg aksjesparekonto, og det var som om 2008 slo meg i trynet.

Jeg fikk ikke pengene, altså de faste månedlige kjøpene som jeg ville sette opp, til å flyte gjennom aksjesparekontoen.

Så jeg forsøkte manuelt, da. Og bare se her, se hvor knotete dét var:

“Hmm, ligger svaret i å først navigere gjennom “min oversikt”, så til “fond”, så til “kjøp” — men vent, hvor er aksjesparekontoen som et alternativ til belastningskonto ved kjøp da? Eller er det heller lurt å trykke på “aksjesparekonto” under “min oversikt”, for så “kjøp fond”? Ja, der var visst aksjesparekontoen automatisk belastningskonto, ja. Men den splittede delen av aksjesparekontoen jeg ønsker å bruke, viser 0,00 kr? Okei, så jeg må dele opp hvor mye penger den skal få ha i seg, og bare dét tar et par-tre dager å vente på, fordi en avdeling i Trømsø skal fikse det.”

Og sånn går no dagan, mens du forsøker å være smart og handle når aksjene har en liten nedgang. Men det kan du bare glemme, når du må vente på å få tilgang til pengene du la inn i kontoen, fordi de må splittes av banken for at de skal kunne gå til rett sparemål. Det er til å få hodepine av. Og jeg angrer på at jeg opprettet aksjesparekonto nå. Eller mest av alt angrer jeg vel kanskje på at jeg ikke opprettet aksjesparekonto fra starten av. MEN! Som jeg prøver å forklare, har i hvert fall dét sin logiske forklaring: Det krever mindre og oppleves enklere å kjøpe i fond når kjøpet foregår utenfor en aksjesparekonto — altså bare direkte fra brukskontoen din.



Like rotete som mitt 90 år gamle hode

Navigasjonen for hvordan du kan få til en forutsigbar pengeflyt hver måned, er like rotete som hodet mitt kommer til å være når jeg er 90. Jeg føler meg gammel, dum og ubrukelig (uten at jeg sier at gamle folk automatisk er dumme og ubrukelige, det vil jeg understreke!). Men jeg er, i motsetning til denne fondssparingsløsningen, smart. Smart nok til å vite at det er denne løsningen som er på en måte gammel, dum og ubrukelig.

Vi går en seig og pinefull død i møte om alle digitale løsninger for fondsparing forblir som dette. Kanskje det er best å investere aksjer i et begravelsesbyrå med “begravelse” som sparemål. Så får i det minste de minste en bekymring mindre.

Men da må jeg jo splitte aksjesparekontoen!

Jeg får si som de fleste andre 59-åringer i det ganske land her: Alt var mye bedre før. Tiden med sparegrisen føltes mye mer oversiktlig. Akk og ved, jeg som følte jeg hadde grønne seddelfingre. Nå er jeg redd mitt pengetre er i ferd med å visne.

10-Dec

Today's posts