Critical infrastructures are, as the name suggests, critical to society and have in recent years become increasingly more digitalized. Such infrastructures include electric power, electronic communication, transport, as well as water supply and sewage. They are essential for the maintenance of societal functions that you and I depend on in our daily lives, and a disruption can paralyze a society and at worst lead to loss of life. Here, we will try to explain why critical infrastructures are especially difficult to secure against cyber attacks.

Digitalization

The digitalization of critical infrastructures increases efficiency, safety and availability, and lowers costs. It does however also enable the possibility of cyber attacks, which we unfortunately have witnessed on the Ukrainian power grid, Saudi Aramco Oil, or the transport company Maersk among others. This shows that securing critical infrastructure against cyber attacks is very important and highly relevant.

Legacy systems

Digitization usually involves introduction of IT into existing Operational Technology (OT) systems. OT systems are often legacy systems that interact with automation and mechanical equipment both locally in industrial facilities and between installations throughout regions. Hence, they are frequently used to monitor and control for instance power grids and oil platforms. OT systems, have until now, usually existed within closed networks with air-gaps. An air-gap is a strong security measure where components are physically isolated from the rest of the network. However, air-gaps are considered nearly impossible to achieve in today’s interconnected systems. As a result, legacy systems that were not created to be exposed to the Internet and its accompanying threats are now connected to the Internet. Unfortunately, such systems do not necessarily have the proper security mechanisms to defend themselves against the wide range of new attacks that the interconnectivity enables. But, to update the security measures is a complex task as legacy systems don’t always support new security mechanisms that are used in modern systems.

Strict availability requirements

As opposed to IT systems, OT systems often have life cycles of decades and components can run non-stop for years at a time. Downtime is usually not acceptable, so their strict availability requirements prevent frequent security patching. As availability is prioritized, confidentiality and integrity are given less priority. This may lead to time-consuming processes like encryption and decryption being omitted, thus transmitting passwords and commands in plaintext. These factors make it hard to protect the systems from sophisticated cyber attacks, and both legacy and newer systems have been exploited in several successful attacks.

Distributed systems

The usually distributed nature of critical infrastructures means securing many different types of devices with a large geographical distribution. This is challenging as varying methods have to be applied to components with different operational constraints. Cryptographic functions can for instance be a problem for small sensors in power grids with limited computational power, similarly to IoT devices as presented in this article from last year’s calendar.

Cyber-physical systems

As today’s critical infrastructures are both physical and virtual, security breaches can lead to safety breaches and vice versa. This does not only increase the complexity, but also escalates the possible consequences, and means that in worst-case scenarios hackers can cause train crashes or nuclear explosions. The other way around, a physical attack on a vulnerable sensor in a power grid can be the gateway into the core functionality and can thus enable a blackout. Monitoring systems in critical infrastructures often have to depend only on their sensors, which creates vulnerabilities and opportunities for exploitation. Physical sensors can be tampered with, making the input untrustworthy.

Complex security management

Security management, the process of protecting assets and preparing for the worst-case scenario, is often more complex in critical infrastructures. This is caused by the fact that the infrastructures are distributed systems that are both virtual and physical, and they are managed by different personnel with varying priorities and expertise. These factors mean that a great deal of coordination and a wide range of knowledge is needed in security management. What complicates the security management further is the ambiguous allocation of responsibility for protecting the infrastructures. Protecting critical infrastructures is of national interest, but the operation is often led by private corporations. These corporations are usually evaluated based on their economical achievements, thus focusing on maximizing efficiency.

Securing critical infrastructure is challenging, but the escalating number of attacks and the increased sophistication, as well as the possible fatal consequences illustrates the importance of proper cyber security in our critical infrastructures.

Why is securing critical infrastructure so difficult?

F# is a fun and mature functional-first programming language for the .NET platform. Taking the first steps to learn a new language can be daunting, so in this post, we'll give some pointers on where to start.

Getting started with F#

The JVM has a long tradition for hosting other lanugages than Java, and it even has some functional languages like Scala, Kotlin and Eta (Haskell). For CLR (.NET), there aren't as many choices, but the one it has is mature and a joy to use.

Description from fsharp.org

F# is a mature, open source, cross-platform, functional-first programming language. It empowers users and organizations to tackle complex computing problems with simple, maintainable and robust code.

And from Wikipedia

F# is a functional-first, general purpose, strongly typed, multi-paradigm programming language that encompasses functional, imperative, and object-oriented programming methods. F# is most often used as a cross-platform Common Language Infrastructure (CLI) language on .NET Core, but it can also generate JavaScript and graphics processing unit (GPU) code.

F# is a language in the ML-family, but borrows from other languages as well. While multi-paradigm, it has been designed to make functional programming the preferred paradigm. It is a very practical language with great interop with .NET and C#, so all the APIs and libraries you already know can be used. It has also always been developed in the open, and has a strong open-source community around it.

Several features of F# should also be somewhat familiar to modern C# programmers as C# has borrowed/been inspired by several features from F#. Async/await, pattern matching and records to name a few. I salute C# for these efforts, but it's difficult to retroactively add such features in a non-breaking way while gaining all the benefits. So these new features have a much cleaner design in F#, and there are yet features C# haven't gained.

While there might be areas where F# especially shine, for me, it's a general purpose language which fits business applications really well. It makes it easy to model domains in a way that's easy to read and reason about, while being robust and easy to change. Scott Wlaschin has a serie on Why Use F# which I wont try to replicate here, but might act as a nice starting point to see some of the benefits of the language and paradigm. If you're more into examples, my upcoming post about functional architecture (broken link until December 22nd) will demo an application using several key F# features to model a pure, functional architecture.

Everyone takes a different approach to learning, so I won't try to teach F# here, but rather give some links to work as possible starting points.

The main entry-point for F# would be the main website, fsharp.org. This is a treasure trove of links, and I'm pretty sure you can find direct links for everything I'm posting here from that site. From the about page, you'll find links to guides and more.

The quickest way to test code is using one of the online environments like the old try.fsharp.org or the newer tryfsharp.fsbolero.io, which is made with Bolero (Blazor for F#). For those wishing to use a local editor, there are plenty of editors available, with popular choices being Visual Studio (remember to enable it), Project Rider, Ionide for VSCode and Vim and fsharp-mode for Emacs.

The latest version, F# 5.0, which was released together with .NET 5.0, and had a strong focus on interactive programming (see .NET Interactive), so you can use Jupyter notebook, nteract and VSCode Notebooks. Together with it's static type system, and easy and terse syntax, it's a good fit data analysts and non-developers.

When I first started with functional programming and F#, I found Scott Wlaschins F# for fun and profit was filled with indispensable resources, and probably one of the biggest reasons I really got into FP.

In addition to fsharp.org, Microsoft is officially supporting the language, and therefore also has plenty of resources from the entrypoint at dot.net.

While you can use all .NET libraries, there are also plenty of libraries which has been created to play on the strengths of F#. fsharp.org has a nice overview of the community and the projects with links to important projects, the F# Community Project Incubation Space and the Awesome F# list (which has additional links at the bottom).

To stay up to date on what's going on in the F# world, I follow Sergey Tihons F# Weekly, which is a nice and thorough weekly aggregation.

So hopefully this will give you something to look at and play with if you're interested in a mature, practical and fun programming language.

Getting started with F#

Mange virksomheter satser på innovasjon for å møte trusselen fra raskere og disruptive startups.

Men er trusselen reell? Og er å innovere selv riktig respons?

Vi tok en prat med analytiker og rådgiver Salvador Baille.

Hvorfor innovere når gründere uansett vinner?

Dette er mine observasjoner og tanker jeg har gjort meg rundt interaksjonsdesign i spill som en gamer og ux designer. Du er kanskje ikke enig, eller har ikke tenkt noe særlig over det, men kanskje du blir litt mer oppmerksom nå?

Disclaimer!

Dette er mine observasjoner og tanker jeg har gjort meg rundt interaksjonsdesign i spill som en gamer og ux designer. Observasjoner av gode opplevelser, dårlige opplevelser eller bare tanker rundt design og layout av alt fra HUD, gameplay, menystrukturer, generell spillforståelse og flyt. Du er kanskje ikke enig, eller har ikke tenkt noe særlig over det, men kanskje du blir litt mer oppmerksom nå? Teksten inneholder også en del norsk/engelske blandingsord eller fornorskede ord fra spill- og gamingkulturen. Jeg er usikker på om det er en type dialekt eller skrivefeil… de er nå der så kan du bedømme selv.

Early days

Tidlige spill, utbredt på arkade, slik som pong og donkey kong, hadde et enkelt oppsett for brukeren. Pong hadde en stikke (joystick), du kunne føre pong-paddelen (den flaten som ballen skal treffe) opp, eller ned. Ganske intuitivt og enkelt. Dette passet spillet veldig bra da spillet er ganske enkelt. En ball spretter frem og tilbake over skjermen og den må treffe din eller motstanderens paddel for å sprette, ellers taper du. Men på pong var det ingen joystick på konsollen, men en bryter på kontrollen som skulle vris opp eller ned, men likevel er dette logisk, da du bare kan flytte paddelen opp eller ned. 

Senere kom det som blir kalt en joystick. Denne fulgte også spillene den skulle brukes på veldig godt. Et eksempel her er space invaders. Her er det du som skal forsvare jorden med et våpen på bakken, som kan bevege seg sidelengs, OG du kunne skyte. Derfor ble det lagt til en knapp! Form på spillkonsoll og funksjon i spill har fulgt hverandre tett, og med utvikling av mer komplekse spill, fulgte mer komplekse spillkonsoller, eller behov for mer funksjon i fysisk brukergrensesnitt. Men hva med det digitale brukergrensesnittet og og brukeropplevelsen i selve spillet?



Super Mario begynte sine tidlige dager som jumpman i Donkey kong serien som arkadespill, og senere konsoller. Supermario er en liten rørlegger som kan hoppe og spurte. Han kan hoppe på fiender og knuse murstein med hodet, samtidig som han samler mynt. Mariospillene tilhører en gruppe spill som kalles sideskrollende plattformspill. Dette er spill som er i 2D, man ser det fra siden og beveger seg fra venstre mot høyre. Det er aldri tvil om hvilken retning man skal gå, fordi man ikke kan gå tilbake mot venstre når spillet først er flyttet mot høyre. Men, hvordan visste man tidlig at man skal passe seg for flammekuler, og samtidig samle mynter og knuse murstein med hodet?

Siden spille ikke var så vanlig da som det er idag var det ikke alle som forsto disse enkle spillmekanikkene. Hvordan spiller man egentlig spill? Da var det ikke like lett å lese spillmediet. For å hjelpe spillerne i gang, ble det veldig vanlig å legge ved en spillmanual i spillesken. Denne ga deg forklaringer på hva knappene gjorde eller hvordan man skulle vinne i spillet. Denne boka var underholdene i seg selv og kunne inneholde finere illustrasjoner enn selve spillet, med bakgrunnsinfo om hvem karakterene var i spillet og hvorfor de var som de var. I dag derimot, er det mye sjeldnere at det følger med spillmanualer i fysiske spillesker. Kanskje det er fordi vi har en tendens til å prøve oss frem først, for så lese oss opp i etterkant. Dette gjør at det kreves veldig mye av brukergrensesnittet i spillet, og spilldesignet.

\ \ \ \ Som nevnt, i tidlige sideskrollende 2D-plattformer spill som super mario, gikk man fra venstre mot høyre, og dette var en god oppskrift som fungerte i 3 spill i super mario serien, men etterhvert som teknologien utviklet seg, utviklet vi oss også som spillere. Vi forstår mer, og det var et mindre behov for et regelhefte i spill, eller en game guide. Men med utvikling av 3D-spill, kom det nye utfordringer. Ta noe så enkelt som et hopp mellom to plattformer. I 2D-mario kan man beregne enkelt hvor mario vil lande, i 3D ga dette problemer. Dybde og lengde er ikke enkelt å formidle gjennom skjermen. Det som da ble gjort, var like enkelt som det var genialt, de la til en skygge under mario, som gir spillerne en indikasjon på hvor mario vil lande. Det er så subtilt at i et enkelt forsøk med A/B-testing syntes de spillerne uten skygge at å hoppe og beregnet hvor man skulle lande var umulig, mens de med skygge mente de bare instinktivt visste hvor mario ville lande.. Men vi ux-designere vet hvorfor 😜

Dette har i moderne spill utviklet seg mer, og kanskje blitt ennå mer subtilt. I dag produseres det en rekke veldig store “open-world” spill, hvor man mer eller mindre kan gjøre som man vil. Her er det litt opp til spilleren hvor man vil gå og hva man kan gjøre. Man kan sette seg opp markører og følge disse, eller gjøre forhåndsbestemte oppdrag som man blir guidet til. En av de mer subtile og vakre “pathguidene” - jeg har sett finnes i spillet ghost of tsushima. Her er det vinden, og bladene som danser i vinden som guider deg dit du skal.

En annen måte spillutviklere og designere kan gi deg informasjon på en diskre eller mindre diskre måte, er via guider i spillet, infobokser eller tutorials/training.

In game guiding

Zelda “hey, listen”

I spill har vi fra tid til annet møtt en fiktiv guide-karakter i spillet, som vil guide og hjelpe deg gjennom spillet. Dette ved ved for eksempel ved en fe i spillet The Legend of Zelda: Ocarina of Time, som sier til deg “Hey, listen!” , som kommer med tips og guides underveis. I world of warcraft, har personer med oppdrag (quest giver) til deg et utropstegn over seg, mens personer med spørsmålstegn tar imot fullførte oppdrag (quest ender).

Infobokser

Mario Oddesey

I super mario Oddesy på nintendo switch, har du med deg en partner in crime som du eller en annen person i ditt hus kan styre som kalles cappy. Dette er hatten til mario, med øyne, som du kan kaste på fiender eller sende på hodet til ting, og da får du kontroll over den tingen. Første gang du bruker cappy på en ny måte, vil det dukke opp en infoboks om hvordan du kontrollerer det du har tatt over med kontrolleren din. Cappy dukker også opp i cinematiske klipp i loading screens og forklarer deg ting og gir deg tips. Det hele føles dynamisk og progresjonen i spillet er også lagt opp til å bli vanskeligere mens du spiller deg dypere ned i spillet.

Tutorials/training

Apex legends, får ikke spille online før du har gjort training

Noen spill er totalt brutale, og kaster deg ut, in medias res. Andre spill som apex legends, som er 100% online pvp (player vs player) basert, har gjort det slik at du ikke får spille online, før du har fullført en treningssesjon. Dette er gjort med fullt overlegg fra utviklerne bak spillet, slik at du skal være best mulig rustet for online spilling. Du kan alltid gå tilbake til trening, for å lære deg nye teknikker eller øve i ro og mak, før du igjen kaster deg ut hvirvelvinden som er online pvp.

Jeg kan skrive utrolig mye mer om ux i spill, og dette er virkelig et helt eget fagfelt. Alt fra HUD i spill som differensierer fra fps til rpg spill, og menyer som er med på å matche spillet det skal inn i. Navigering i menyer og flyt i verdener og brett. Lanes i skytespill og lanes i bilspill. Men det blir dessverre for stort for denne korte artikkelen. Jeg vil heller avslutte med å dra en parallell fra ux i spill til vår hverdag. Når vi designer tjenester for kunder og oss selv, kan vi raskt se at måten vi forventer interaksjonsnivået til brukerne har økt raskt de siste årene. En tjeneste vi i dag leverer på lik linje med et spill i dag er noe helt annet enn for 6-7 år siden. For å fortsette å utvikle oss å skape intuitive løsninger, må vi kanskje se til en usynlig vind for brukeren, en naturlig flow som gjør det enklere for brukere å møte nye eller eksisterende løsninger på? Uansett så vil jeg nå tro at du ser på enkle og avanserte spill i et ganske nytt lys når du neste gang spiller et spill. Kanskje du til og med tar med deg noe nyttig lærdom inn til prosjekt!

Mine tips til spill i julen, med gode og dårlige brukergrensesnitt!

QWOP - PC - et av de vanskeligste spillene, brukergrensesnittsmessig

Firewatch - PC, Nintendo Switch - Utrolig vakker story og illustrert

Altos Collection - mobil, Switch - Vakkert sideskrollende 2d spill, for hele familien

UX i Gaming

Kotlin contracts are a way to help the compiler get more information about what the code actually does. Sometimes the compiler can’t infer all the information we as programmers know.

What are they? What do they mean? Where can we find them? Let's take a look at an example to get an idea of what contracts are good for.

As we have given str the type of a nullable String the compiler can’t know that str.toUpperCase is a safe operation here, even though we know that str is clearly never null. How can we use contracts to help us with this?

What is this magic? str.toUpperCase() now compiles. This is because we have told the compiler, or given it a contract, that says if getLength returns anything str cannot possibly be null. To share this arcane knowledge about our software with the compiler we placed a contract inside the getLength function. We have told the compiler that str cannot be null with returns() implies (str != null). Nothing stops us from sending in an actual null-value to getLength and breaking everything, but by using a contract we promise not to do that!

With contracts we describe behaviour we expect to happen using information the compiler doesn't know about. This means it is not necessarily correct, but it's a guarantee, or a contract, we give the compiler.

The returns statement inside the contract can be used to tell the behaviour we expect for when the function returns either true, false or null. Let's explore that, what happens if we give the compiler something thats only true for some cases?

When isUpperCase returns true we can be sure that our nullable string isn't null because we know the inner workings of our isUpperCase function, and while it's false we simply don't know and have to do an actual null-check. The point here is that we have helped the compiler with some extra information, so it has the same assumptions as we have.

There are also some other cool things we can do with contracts, namely give information about how we invoke a code block.

Using callsInPlace we can give information about how we use the block-lambda passed to our once function. In this case we are saying that we will invoke it EXACTLY_ONCE. This allows us to assign a val inside a different scope, where we normally can’t infer anything about how many times it would be called. For all the compiler knows the function could have looked something like this:

Without using contracts and implying that we only call the lambda once, we would get an error when trying to assign a value inside a different function scope. This is since the lambda might be called twice and we would try to reassign a val, which is a no-no.

If you look through the standard library you find contracts used a lot. And if we look at the source code of let we can see contracts being used.

This contract is what what allows us to write something like:

Again, this is because we as programmers have given the compiler a guarantee that { myInt = 45 } will only be invoked once. Neat.

A pitfall with contracts is that you might give the compiler the wrong idea, leading to unhappy times. Contracts are still experimental and personally I haven’t found too many uses for them in day to day development, but they are a cool feature that I hope we see expanded in the future.

Contracts

In today’s article, we’ll skip the tips, tricks, and wisdom of public speaking and say a few words about everyday conversation.

When systems and structure is of no help

A few months ago, a group of colleagues and I attended a workshop held by a professional actor and comedian. A number of challenges and activities were on the menu, but one marked me more than the others: Improvising a story together with a partner.

The game was as simple as it was engaging: First, partner up with someone. Second, listen to the few cues given by the instructor providing inspiration for the story. Third, begin telling the story - and invent on the go! Fourth, at the instructor’s signal, switch the person telling the story. This might be right in the middle of a sentence. Hear your partner out until you fear a new signal is, and take the lead once again. And so the story grows, perhaps together with your heart rate.

The participating group consisted of a broad range of people and backgrounds: designers, software devs, and managers. Personally, I work as a programmer, and I generally prefer to think things through before I either speak or act. I like it when things are being part of a larger system in a way that makes sense. Spontaneity and uncertainty are not my strongest assets - I get the feeling of lacking something to lean back on in case of unwanted surprises.

Being my usual self, this was the mindset I brought to the task we were assigned: Planning and setting up something of a structure for the story. I was not the only one - a bunch of the other people set out for the same, that is trying to plan and predict the outcome.

This approach failed spectacularly. The stories we all had planned out were just fine, but in the midst of the heat, combining them proved next to impossible. We would get hung up in the middle of sentences, struggling in our search for the next word and phrase which could fit into the grand plan we all had in mind. The situation was awkward rather than funny.

Engaging Creativity

Next, with a tiny bit of training, as well as a minor adjustment of the mind-set, we were now ready to take on the challenge once again. Based on our previous experience and tips from the coach, we now had a number of tricks in the back of our mind:

Listen to your partner, rather than preparing your next statement

Add adjectives

… then add some more

Visualize images in your mind, then express them

Express, rather than assess whatever comes to your mind

… in order to enter the flow state of the story-telling

The last two points cannot be stressed enough. The flow of the talk is everything and also providing the momentum necessary to come up with new ideas.

In hindsight, the game represented more than just an activity to have fun, get more acquainted, or to train for that specific game: The same learnings apply to any normal conversation you're having.

During your next conversation, try to listen a tad more to your partner than usually, and leave your own needs of concern behind for a moment - and try sprinkle in some words awakening the imagination. Welcome the feeling of uncertainty and enjoy the flow!

What Improvisation Taught Me About Conversations

My name is Tora, and I started working at Bekk this fall as a new React developer with a fresh Computer Science degree. I would like to share my journey into this new and exciting world with you!

Where to start?

When I first started working, I was almost completely new to React. I had only attended a few half-day courses during my years as a student and I was now assigned to a complex project written in React. However, some parts were written with modern React using Hooks and some parts were written with an older version of React.

I had no idea what Hooks were when I started out, and it didn't help that I couldn't tell the new and old React code apart. But, with a guiding hand from my colleague, we jumped right into it and started pair-programming on smaller tasks such as “Add a new button” or “Create a new filter”. These tasks were easy to start with, because I could study similar code from other places in the application and try to replicate the logic. Along the way, my colleague and mentor explained concepts such as hooks and components. I also used the React docs actively to better understand the theoretical concepts that were introduced to me and wrote down key takeaways from our solutions.

Next, we began refactoring older React into modern React. This helped me understand how Hooks work, and how they are actually used. It was mind-blowing to see how many lines of code that could now be replaced with a simple Hook. My experience with this approach was good. Because, after spending some time coding new functionality and at the same time trying to learn a new language, it was nice to focus more on syntax and understanding the different versions of React.

Online courses, another approach?

So far, my approach has been to dive right into a problem and use React to solve it. However, it is also possible to start with a beginner’s course, such as this workshop (in Norwegian). Here, you will work through different topics and solve small tasks related to that specific topic. This approach might give you a better theoretical understanding of what it is you are actually coding.

Online courses and workshops usually present the theory behind a concept before you’re supposed to implement it. This differs from my experience at work. Sometimes I didn’t understand that I had learned about certain React concepts already, simply because we had not discussed the concept of what we were implementing. For instance, my colleague and I would write a Hook to store some component specific state, without ever mentioning the word "hook". I knew what we were trying to achieve, but I didn’t understand at the time that useState was the Hook that I had read about earlier. An online course would probably present the theory before inviting me to try to implement the Hook.

Personally, I learn best by reading and writing, and not just by viewing and listening to other people explain things to me. I have previously tried lectures and online courses with other technologies, but my experience is that I generally don’t really learn what I am supposed to because of the lack of repetition and experience. So, pair-programming with a more experienced colleague has been great. I feel that I can challenge myself and try what I think is a possible solution. At the same time I have my colleague beside me who can give me small hints and explain when I stumble across something new.

As with anything that you are trying to learn, I recommend that you reflect on which learning style suits you best. If you would like to just dive right into a project like me, but you’re unsure of where to start, this page can be useful. And if you’re the type that likes to start from scratch and have small explanations for everything you do, maybe some of these workshops can be useful:

React and TypeScript

Animations in React

Testing React apps

What’s next?

So, am I a professional React coder now? Absolutely not. But I do know what a component is, I am more comfortable with using Hooks, and I am not completely lost when I have to solve a problem on my own in a never-before seen file in our project.

Going forwards, I would like to focus on better understanding the theoretical concepts behind my code, so that I can make more conscious decisions when developing. I also hope that I will feel confident enough in React to be able to help my new colleagues that will join our project next year! Maybe one day I will even understand what the ReactDOM really is 🤷‍♀️

A Tale of a React Newbie

It may become tedious to always check if a value in your records is on the supposed format. To be absolutely certain that a value correctly represents a property in your records, we can use opaque types!

In all languages, we might want to represent values that is easily representable by simple types like String and Int, these types does not, however, ensure that the desired values are correct. For example, we would expect a year to have at least four digits, or a full name to consist of a first and last name, etc.

In this record called Person we have two properties, one name and one birthYear. While this type alias can hold a name and a birth year, formatted in the correct way, we don’t have any guarantees that the values in the record actually are in that proper format. The point of this is that we want to be certain that the properties of this record represents the desired values the correct way.

Let's imagine that to create a Person the user needs to fill a form where he/she types in the mentioned properties. If we only checked that the fields were properly formatted when the user submitted the form, but continued to use Strings as the type of the name and birthYear fields, we wouldn’t know for certain that the fields were properly formatted after that check. Maybe we inadvertently changed one of the fields at some time after that, or maybe another person working on the code came along and changed how the check was, not knowing what format the fields needed to be in. To achieve the certainty that the property birthYear is in fact a year, we use opaque types.

Year is now a type and the property yearValue is inaccessible from other modules. Notice the way we expose Year, module Year exposing (Year, fromString). As you can see from the way we expose our type, we do not expose any constructor details which we would have done if we wrote ... exposing (Year(..), .... We only expose the fromString function so that we control entirely how the Year type is created. From the definition of the fromString function we can see that we only return the Year type if the String input is indeed a year.

Now we also have a way of validating the "year" input part of the form where the user creates a Person. The property birthYear is now guaranteed to be a year by the type system.

The opaque types version do produce some boilerplate code, but will oftentimes be much cleaner to work with as the interaction with the type is clearly defined through getter and setter functions. In a nutshell, opaque types can be used to ensure that we use a module as intended. It will expose everything you need to know on how to interact with it, and also impact your code to become cleaner where the module is used. Unnecessary implementation details will be hidden away and for the cost of some boilerplate code in the module it will be very easy to work with and extend functionality.

Greater type safety with opaque types!

You’ve done your fair share of JavaScript. You’ve shipped production code for years. You’re definitely no noob, nor a true expert. What’s the next step? How to find a learning path towards JavaScript mastery that actually motivates you to reach the next level? This article presents six alternative routes forward.

The Boring Path: Read A Book

This might not be for everyone, but if you’re not totally sure you grasp the inner workings of the language, there’s nothing like bunkering down with a great book. JavaScript has plenty of concepts that every professional developer should have solid understanding of. Closures, hoisting, context and «this», prototypical inheritance, async code are just some examples. I’d argue the most efficient (albeit not the most fun) way to learn them is through reading.

Eloquent Javascript (2018) by Marijn Haverbeke is a good place to start. If you prefer to read in the browser, check out javascript.info! These books are usually a bit thorough and cover most aspects of JavaScript. If you’re somewhat familiar with the language, make sure you skip the first chapters and skip directly to the complex matters you need help with.

The Playful Path: Playing With Code

Not the reading type, eh? Thats alright. Tons of awesome developers never opened one! There’s actually lots of fun games that involve coding JS. Even if you might not be guaranteed to learn as much as you do from the big JS bible, you’re almost guaranteed to invest quite a few more hours in it than you would reading a book.

Untrusted is one of my favourite games. In this cute ASCII-arted piece, you play by modifying parts of the source code to manipulate the environment or core game logic to allow the player to reach the level exit. It starts out easy but escalates quickly!

Elevator Saga is exactly that - you play by coding the elevator control logic. You win by transporting the required amount of people per level, and making sure no passenger waits longer than the designated max wait time for that particular level. A bit less playful, a tad more brain-wrenching.

The Hacker Path: Solve Them Puzzles

Fancy coding katas? On codewars.com you’ll find challenges of all levels, from the most basic to impossible difficult brain teasers. The UI is pleasant, the app is feature-rich and you code directly in the browser. Neat!

The Researchers Path: Read Others Code

At some point when a young musician is learning an instrument, he or she will reach a level where it is necessary to play with other musicians in order to improve. Similarily, a good developer will need to be exposed to great developers’ code to self become great.

Study the experts by looking at your favorite open-source project on GitHub. There’s no guarantee that the code you’ll find is perfect – but noone said that this exercise is about accepting what you’ll find and plainly copying others.

If no project comes to mind, I’d suggest popular frameworks like React, Vue or Next.

The Academic Path: Stepping Inside The Factory

What challenges do the people managing JavaScripts future face? What considerations must be done when discussing a new potential language feature? How do they think?

The people I’m talking about are members of the TC39 committee. They all work for big internet companies and meet roughly every other month. And the best part – all meeting agendas and notes are publically available on Github!

This means any aspiring JavaScript jedi can fill their mind with the tradeoffs, considerations and thoughts of the people in charge.

Have a look – agendas, notes and new language feature proposals.



The Creative Path: Build Your Own App

The expression «learning by doing» exists for a reason. It works!

Find an app idea that truly motivates you and go for it. The only problem is.. finding that idea cool enough that you’d want to pour hundreds of hours into it.. and finding those hours. This path is difficult, but very rewarding.

Everyone who’s ever had a all-consuming pet project know that awesome feeling. The awesome feeling you get when thinking about new features, or ways to improve the app, or ways to reach out to new users. It’s your own little startup – without it having to pay for the groceries (or maybe one day it will).

Good luck with your project!

Six Ways To Level Up Your JavaScript

Den siste tiden har vi sett stadig økende forventinger til at bedrifter skal ta samfunnsansvar og bidra til åpenhet knyttet til bærekraft. Gode intensjoner blir ikke lenger betraktet som tilstrekkelig, og dermed har bærekraft blitt mye mer enn en omdømmeparameter eller en kuriositet på utsiden av kjernedriften. Dette betyr at bærekraft i større og større grad utvikler seg til å bli en økonomisk nøkkelfaktor som begynner å gi utslag på bunnlinja.

Bærekraft som risikodriver

Bærekraft er et tema som blir aktualisert og løftet frem av en rekke ulike interessenter. Blant disse finner man investorer og bedriftseiere. De begynner å fatte interesse for bærekraft som en investering og vekstdriver, ikke bare et spørsmål om ansvarlighet og samfunnsansvar. Investorer krever gjerne høyere avkastning på virksomheter med betydelig negativ miljøpåvirkning fordi denne typen investeringer bærer en høyere risiko.

Som et eksempel, snakker finansbransjen om ESG-investeringer (forkortelse av Environmental, Social and Governance). Her blir bærekraft vurdert med utgangspunkt i bedriftens rapportering av bl.a. klimarisiko og -utslipp, og dermed blir disse parameterne viktige investeringskriterier. Finansmarkedet viser at ESG-investeringer får lavere avkastningskrav, og at investorer systematisk betaler et prispremium for aksjer i slike selskaper. Dette betyr at virksomheter som tar bærekraft alvorlig, og iverksetter konkrete tiltak for å bevege seg i en mer bærekraftig retning, blir belønnet med høyere selskapsverdi.

Videre begynner banker og finansinstitusjoner å tilby produkter med bedre vilkår til virksomheten som aktivt jobber med å bli mer bærekraftige. Det betyr at finansinstitusjoner vurderer et aktivt miljøansvar som en faktor som reduserer finansiell og operasjonell risiko. Dette har blant annet materialisert seg gjennom banker som diskriminerer på lånebetingelser, og dermed tilbyr mer attraktive låneprodukter til virksomheter som tar grep om egen negative miljøpåvirkning. Et annet eksempel er at finansieringsselskaper kan tilby mobilitetsaktører bedre betingelser på leasing av en elektrisk buss enn et fossildrevet alternativ.

Myndigheter og forbrukere belønner bærekraftige selskaper

Samtidig som private aktører heier frem virksomheter som jobber mot å bli mer bærekraftige, snøres nettet med miljøreguleringer og myndighetskrav stadig strammere. På globalt nivå har vi Parisavtalen som utgjør rammeverket for et internasjonalt klimasamarbeid, og som forplikter land til nasjonale utslippsmål. Avtalen representerer en massiv snuoperasjon fra dagens forretningsdrift, og fordrer formidable endringer i rammebetingelsene til nasjonal næringsvirksomhet. På lokalt nivå kan politiske vedtak forby enkelte typer drivstoff, eller pålegge restriksjoner på kjøring i byer. Prinsipielt betyr dette at myndighetene belønner bærekraftige virksomheter gjennom subsidier eller andre incentivordninger, mens virksomheter med en negativ miljøpåvirkning straffes med bøter og strengere regulatoriske krav på f.eks. produksjonsutslipp.

Til slutt observerer vi en stadig økende interesse og bevissthet rundt miljø og bærekraft i den generelle befolkningen. Dette fører med seg økte forventninger til at bedrifter tar samfunnsansvar og sikrer åpenhet rundet egne verdikjeder og produksjonsprosesser. Med endringer i befolkningens holdninger, følger naturlig nok også en dreining i kundepreferanser og atferdsmønster. Vi som kunder og forbrukere ønsker gjerne å bli mer bærekraftige, men sliter gjerne med gjennomføringsevnen.

Det å ta bærekraftige valg utfordrer vanene våre og påvirker livstilen vi har utviklet over tid, og det er derfor naturlig at vi beskytter oss mot disse endringene. For mange oppleves et gap mellom hvor bærekraftige vi ønsker å være, og hvor bærekraftige vi faktisk er. Dette kalles kognitiv dissonans. Det er rett og slett veldig vanskelig for oss å endre adferd over natta når problemet ikke er synlig i hverdagen vår. Derfor etterspør vi som kunder i stadig større grad produkter og tjenester som kan bistå oss med hjelp til å bli mer bærekraftige i hverdagen.

Utviklingen krever en kursendring

En rekke interessenter stiller altså strengere krav til mer bærekraftig forretningsdrift, grønnere produkter, og tjenester som bidrar til brukerens bærekraftige verdiskaping. Dette handler i essens om at pengestrømmer re-allokeres til mer bærekraftige virksomheter, og at kunder, myndigheter og investorer straffer virksomheter for miljørelaterte overtramp. Det blir rett og slett bedre butikk av å være bærekraftig.

Alt dette vil naturlig nok påvirke forretningsdriften i et økende antall selskaper. Som en naturlig konsekvens er det flere virksomheter som setter bærekraft høyt på agendaen, og dermed har lavkarbon blitt et viktig strategisk element. Dette fordrer at selskaper justerer kursen, inkludert endringer innen forretningsmodeller, organisasjonskultur og produktutvikling. Til og med giganter innen olje- og gassvirksomhet, selskaper som har basert sitt eksistensgrunnlag på å tilby markedet produkter som bidrar til klimautslipp, har begynt å inkorporere bærekraft i strategien. På ett tidspunkt i en ikke altfor fjern fremtid, vil bærekraft antageligvis være en hygienefaktor for de fleste selskaper med vekstambisjoner.

Bedrifter kan adressere bærekraftsproblemet gjennom minst to ulike tilnærminger; enten gjennom å ta ansvar ved å feie for egen dør, eller ved å behandle bærekraft som en mulighet med forretningsmessig verdi[1].

Førstnevnte handler om at bedrifter tar ansvar for egen negative miljøpåvirkning, og forsøker å redusere bedriftens egne utslipp. Som et eksempel kan produksjonsselskaper foreta endringer i produksjonsmetoder eller i bruk av produksjonsfaktorer. Et annet eksempel kan være virksomheter som gjør bevisste designgrep for å øke levetiden til et produkt, eller legger til rette for at produktet kan repareres. På den måten kan virksomheter ta ned risiko og kostander assosiert med prosesser som i utgangspunktet har negative miljøpåvirkninger.

Bedrifter kan også håndtere bærekraftsproblemet som en mulighet til å skape nye, kreative og inntekstgenerende forretningsmodeller gjennom håndtering av andres negative påvirkning. Dette kan handle om at produksjonsselskaper tar betalt for å samle CO2 som råvare i produksjonen av karbonnegativ plast. Bedrifter kan også posisjonere seg med en sirkulær forretningsmodell, og dermed påvirke øvrige ledd i verdikjeden for å sikre at bruksverdien til materialer, produkter og komponenter blir bevart så lenge som mulig. På den måten kan bedrifter bruke nye kundepreferanser og strenge regulatoriske krav til å opparbeide seg et vedvarende konkurransefortrinn.

Bærekraft utgjør et risikoelement

Vi tror at en strategi med et bærekraftselement og et langsiktig perspektiv på hvordan virksomheten skal sikre lavere karbonutslipp, kan gjøre virksomheter mer konkurransedyktig på sikt. For selskaper som evner å utnytte bærekraft som en mulighet, kan en omstilling til nye forretningsmodeller bli en gullgruve. For andre selskaper kan det kreve formidable transformasjonsprosesser som er helt nødvendige for å oppnå lønnsomhet på lengre sikt.

Økte forventninger til bærekraftig forretningsdrift resulterer altså i økte kostnader, større risiko og redusert inntjeningspotensial ved uansvarlig forretningsdrift. Det er allikevel sannsynlig at totalkostnaden ved å omstille seg i dag, er vesentlig mindre enn det den vil bli på lang sikt. Vi vil derfor argumentere for at dersom din virksomhet ikke har satt bærekraft på agendaen i strategiske og operasjonelle diskusjoner, er det på høy tid. Ikke fordi din bedrift nødvendigvis skal legge til bærekraft i kjernen av verdiforslaget, men fordi de færreste virksomheter har råd til å ignorere bærekraft som kostnads- og risikodriver i tiden fremover.

Kilde: [1] Jørgensen & Pedersen, Restart 2018

Bærekraft; fra omdømmeparameter til økonomisk nøkkelfaktor?

A while back we needed to host a react app. Sounds simple right? Thats just some static files (HTML, CSS and JS). It got a bit more complicated when we needed to add a navigation bar, that was shared across the organization. The contents of this nav-bar would change frequently, and we had no way of "subscribing" to these changes. Instead, it needed to be added, or decorated🎄 on top of our frontend app dynamically.

Originally, before going serverless, this decoration of our app was handled by a Node.js application that would append the nav-bar to the top of our HTML, and serve the decorated app.

The app ran in a container, that was deployed to the organizations own IaaS (infrastructure as a service) solution, built on top of kubernetes. Therefore any new deployment of this app was quite elaborate.

The deploy pipeline was something like this:

Push react app to github

CircleCI builds production version of frontend(npm run build)

CircleCI builds docker image

CircleCI pushes docker image to docker hub

IaaS solution pulls docker image

IaaS solution spins up container(s)

Thats a pretty extensive pipeline for a simple app. Time elapsed from git push to being "live" would usually be about 3-5 minutes. And if you deploy frequently (like we do), that adds up.

Going serverless

Dealing with containers and kubernetes is perhaps overly complex for a simple frontend application, such as ours. We therefore decided to go the serverless path:

Instead of having a single app that both decorated, and served the frontend, we would seperate the two: The react app would be deployed to an AWS S3 bucket, which provides functionality for hosting a static website. A serverless function would handle the decoration.

The serverless function, would then be the app-entrypoint for our users. In order to avoid the decorator function being executed for every request, we put a cdn that would cache the response, in front of the entire solution. The architecture we arrived at looked something like this.

GCP, AWS and Azure all provide Node.js serverless runtimes. We found AWS Lambdas to be the best alternative, both in regards to performance and pricing. Additionally, they have the nifty service Lambda@Edge which made executing the serverless function at the right time much simpler.

A serverless architecture provides for a much simpler deployment pipeline, at least for our use case 🤷‍ We ended up with three simple steps:

Push react app to github

CircleCI builds production version

CircleCI pushes HTML, CSS and JS to AWS S3

That's a bit nicer than our original 6 steps - and it uses about half the time 🏃‍♀️💨

Lessons learned

Going serverless was just one of many possible solutions for our use case, but we liked it. It made developer life simple(r) ☯ Deploying a serverless function is super easy, and lets you focus on writing your business logic, and disregard infrastructure. Now add in its infinite scaleability and smooth pipeline, and I'm convinced 🤓

17-Dec

Today's posts