Have you ever had an application that you wanted to automate the building, packing, and deployment for? In this article, I will show you how to can utilize Docker, Github Actions, and Azure App Services in just a few steps.

Introduction

We are going to create a simple CI/CD pipeline. The pipeline or concept that we will focus on will touch upon multiple technologies that may at first look a bit overwhelming. Therefore, I am trying to make this as simple as possible. Nevertheless, in the end, we have a working pipeline that you may actually copy/steal/improve for your own project.

Pre-requisites

You don't actually need anything to read this article and understand what's going on, but if you want to replicate this, then, this is the technology I have used.

.Net 5 SDK

Docker Desktop (regular Docker if on Linux)

I will stick to the command line to keep the article's steps working for all operating systems.

The full solution is available at these locations:

Github

Docker Hub

Deployed App

1. Create a sample application

To keep this as simple as possible, I suggest using one of the default applications that the dotnet cli gives us. The following command creates a new MVC solution in a folder called DockerSample.

We can test the application by navigating into the folder and run the following command.

Now we should be able to open our browser and see the following on localhost port 5001.

2. Adding Docker support to your application

Now that we have a working application, we can make sure the application builds and runs in a Docker container from a Docker image. To create our Docker image, we need to create a Dockerfile. Since Docker is supported by Microsoft, we can use the images they serve as a baseline for our image. We see that Microsoft has several images available that serves our purpose. Namely, SDK and AspNet Runtime.

We will use the SDK image to build our solution and the AspNet Runtime to run our solution. We are using both instead of just the SDK because the Runtime image is smaller. We want our final image to be as small as possible.

The recipe for creating our image is to understand how the build progress of a typical .Net application work. Typically, we want to the following in the following:

Download our dependencies (restore)

Build our solution (build)

Create an artifact of our application (publish)

Run the application (execute)

Let’s start defining our image. We first need to tell Docker which image we want to use as a baseline. We can set the working directory at the same time. We can do that by adding the following to our Dockerfile.

As you may have seen, I have named our image restore (i will come back to why later in this section).

To download/restore our dependencies, we add the following.

We are only caring about the project's dependencies; thus, we are only copying the .csproj file to /app inside our container. After that, we run the dotnet restore command using the CLI we have available from our base image.

Next, we need to copy the rest of our source files and build our solution.

In these steps, we create a new container named "build". This container derives from our previous image, namely "restore". After that, we copy the contents from our current directory (which includes our source code) from our local computer to the folder "/app" inside the container. Finally, we run the build command with some common flags for building a release.

Moving on, we need to publish our build as an artifact. We do that with the following instructions.

Again, we are creating a new container, but this time it's called "publish" and it derives from the container called "build". We then run the dotnet publish command to create an artifact and place it in a folder called artifacts.

Lastly, we need to run our artifact. That is where our runtime container comes in. In this step, we’ll take our artifact, copy it over to a new runtime container, and then set the entrypoint (which command to run when we start the container).

With that, we have a fully working Dockerfile that takes our application, builds it, places the runtime in a small container, and runs it. Our final Dockerfile should look something like this.

To build our docker image, we run docker build . --tag dockersample:latest in our terminal. The build output should look something like this.

Now, to run this image, we run the following command: docker run -p 8080:80 dockersample:latest . Notice the -p 8080:80, meaning that we will forward our local port 8080 to port 80 in our container. Consequently, we can view our application in our browser at localhost:8080.

3. Github Actions and pipeline

In the last step, we created a Dockerfile for our project. Moving on, we are going to take some shortcuts. If you want a short introduction to how Github Actions work, you may read my introduction article that explains the concept in greater detail than here.

Before we move on, we need to know where we are going to store our Docker image. In this article we are using DockerHub, therefore, we need to create a repository at Dockerhub. Actually, we could use whatever repository we have. Just note that the only requirement we have, for now, is that the repository is open.

Nevertheless, we need to authenticate with the repository in order to be able to push our image. With Dockerhub, this is quite simple. We may either use our username and password or, even better, use our username and a token.

Storing our username and password/token in our code is something you should never do. Luckily, with Github Actions, we are able to use secrets.

To configure our secrets, we navigate to Settings -> Secrets in our Github repository. Our secrets are encrypted, which means that once we have saved them, we are not able to view them again. However, we may replace or delete if we should need to in the future.

Now, let's move on. We will add a file called main.yml into a new folder in .github/workflows. In short, this where we store our Github Actions.

As you can see in main.yml file, we are creating a workflow with one job that consists of four steps. Remember, this is as simple as possible.

Let's dive into the steps in our job. First of all, we checkout our code (fancy word for cloning our git repo). Next, we build and tag the docker image that we configured in the previous section. After that, we log in to our Docker registry before we push our final image in the last step.

4. Creating and configuring our Azure App Service

Now, let's provision our AppService. I assume you are familiar with Azure App Service and its capabilities. We are going to create a Web App that runs on Linux (in a Docker container). If you are using the portal, you should see the following when you create the Web App.

Onward to the Docker tab. We need to configure what Docker image we should use and how we are going to retrieve it. This step can be complicated in many instances. So I will not cover how we deal with private registries. We are, therefore, going to use the same public image we created in the previous section.

We may configure to use that by selecting DockerHub, and then our image name. Hit "Review + create" and Voila!

Conclusion

In this article, we got a brief introduction on how we may use Docker and Github Actions to package and publish a .Net 5 on Dockerhub. Thereafter, we consumed that image on Azure App Service to make the .Net application publically accessible from all over the world. However, this pipeline is not complete, there are lots of things that could have been better. Nevertheless, I think that it may serve you in your current or your next project as a baseline that you will need to expand for your project to thrive. I hope that this has been helpful and that you now have another tool to use in the future.

Suggestions for further work

Like with any solution, it can often be improved. This is no exception. In fact, I think there is tons of room for improvement. However, I'll leave that to you. If you want some suggestions, this is what I recommend looking into.

Make your repository private, such that it is only available for your App Service.

Add triggers to your Github Action, such that you only run your Action, or parts of your Action, when something is pushed to the main branch.

From code to cloud using .net 5, Docker, Github Actions and Azure App Services

Et av områdene med mest bevegelse for tiden er markedet for strømmetjenester.

Som en liten, norsk aktør har RiksTV valgt å satse på smidighet og innovasjon for å kunne være med i konkurransen. Men hvordan organiserer man seg for dette?

Håvard Hvassing og Jens Andreas Huseby tok en prat med Birgitte Seim-Haugen, som er produkteier for Strim i RiksTV.

Hvordan organiserer RiksTV seg for innovasjon i et produktteam?

There are plenty of buzzwords when it comes to type systems. Today we take a closer look at the concepts related to kinds.

Types

Type systems are cool. Or - some are cool, others can be a bit of a hassle, but they all strive to let your compiler check that your intentions (type annotations) match your implementation (actual code). So types are there to allow you to catch bugs even before your program runs. Pretty neat! The more advanced the type system, the more logic can be declared in types and the more bugs you can catch with the help of your trusty compiler.

Now, type systems were not created equal, and there are limitations to which guarantees your types can provide. Haskell is an example of a language with a very sophisticated type system, more or less derived from the mathematical field of category theory, closely related to formal logic. Unsurprisingly this allows for a bunch of fancy type magic that lets the compiler check a lot of complex logic on your programs if you just nudge it in the right direction.

Concrete Types

At the base level of our programs we have values, and these values have types. Int, String and Maybe [Bool] are all concrete types, which means that values in our programs can be these things. Everything else is abstractions over concrete types.

The definition of Maybe is essentially this:

The a here is a parametrically polymorphic type parameter. In a language like Java, a similar effect is achieved with generic types. In a language like English, this means that Maybe needs another type to become a concrete type. You can't have a value that's Just (sic.) Maybe: It is a type constructor, which is akin to a function in the domain of types: it takes a type and gives you another type.

Kinds

The kind of a type is an abstraction over its "shape" in terms of types. Concrete types are the simplest types, and they have kind *, pronounced "type".

Maybe has kind * -> * because it takes a concrete type as an argument and gives us another concrete type.

It follows that a type like Either has kind * -> * -> *. You get the idea.

Higher-kinded types

An Int or a String is just a value. In a pure functional language we can think of values as functions that take no arguments and return a value: Since there are no side effects and no arguments, the outcome is predetermined. We can conceptualize the order of a function as its level of abstraction from values. In this interpretation, values are functions of order 0.

A step up from values we have what are normally considered functions; a construct that operates on inputs and outputs that are values, so their level of abstraction is higher - they are of order 1. In general, a function of order n operates on inputs and outputs of order less than n.

A higher-order function is a function with order greater than 1 (who'd-a thunk it!) - in other words a function that operates on other functions. In an analogous way, a higher-kinded type is a type that operates on other types so that their level of abstraction from concrete types is greater than 1.

Exactly what we were looking for - a contrived example! Let's do a quick analysis of its kind: The StringContainerContainer takes a polymorphic type argument, so c has to be a "type" to something; * -> ?!. But that something cannot be a concrete type since it has to take String as a type parameter. String has kind *, so c must have kind * -> *, and StringContainerContainer therefore has kind (* -> *) -> *. We have found a type that operates on a more complex type than concrete types, so it is a higher-kinded type!

Note how this is fundamentally different from the kind of Either. Either is not a higher-kinded type since it only operates on concrete types: Haskell supports partial application in the type domain and the kind signatures are curried in the same way as their type counterparts. It follows that a partially applied Either String must have kind * -> *, so * -> * -> * is equivalent to * -> (* -> *).

Higher-kinded polymorphism

Functors exist in many languages. The essence of a functor is some context that you can map over, i.e. lift a function into the context and apply it in a sensible manner. A list is a straightforward example of a functor. In Haskell, functors are abstracted as a type class:

In the signature of fmap we see that the polymorphic type parameter f is simultaneously polymorphic in another type. The payoff is that we can supply a rich ecosystem of functionality based on these class operators that allow code reuse for any functor (or other type class) while keeping the guarantees of static typing.

Most languages do not support higher-kinded polymorphism. However, it turns out that it is possible to achieve a lightweight higher-kindedness in languages whose type systems only support first-order kinds through a process called type defunctionalisation (Yallop & White, Lightweight higher-kinded polymorphism, 2014). If you have half an hour to spare, I recommend this talk on how the concept is realised in Kotlin's functional abstraction library, Arrow.

Types and Kinds

Both object composition and inheritance are mechanisms that enable code reuse. While composition makes code reusable by composing objects with smaller well-defined behaviours into larger and more complex objects, inheritance makes code reusable by building class hierarchies where common behaviours are defined lower down in the hierarchy.

The delegation pattern is a design pattern based on object composition, where an object is delegating the work to other objects it has reference to. This might make it look like inheritance from the outside. A disadvantage with the delegation pattern is that it gives more boilerplate code in some languages. This is not the case for Kotlin, having first class support for the delegation pattern, applied using the by keyword. Let's walk through an example which demonstrates this.

We will use the example of an API to retrieve and submit wish lists, where we are going to implement a client to consume this API:

First, we have an interface HealthCheck, to check if the API is responding. Second, we have an interface WishListClient, defining the operations of the API, where we can submit and retrieve our wish list.

Below, we have an implementation of the WishListClient as an http client:

For this example, the implementation is stripped down to save space and for readability, but it will hopefully be realistic enough to make sense. The actual http calls are delegated to some HttpClient, composed as a constructor parameter to WishListHttpClient. We do not delegate directly to the HttpClient, we provide information about the url, and in a real world implementation, we might have some more logic to handle the request and the response. Here is how the stripped down HttpClient interface looks like:

Now, the implementation looks quite ok, but the next time we are going to implement an http client, it is likely that we would like to have a health check for that client as well. The only thing which will vary between the implementation of healthy for different clients is the url, so let's split the health check to its own implementation to work for arbitrary endpoints:

We can now change the WishListHttpClient to provide the health check functionality by composition, and delegate the functionality:

There is some boilerplate with the healthy function, which is only delegating to the healthCheck instance with no other logic. That's where the delegation pattern in Kotlin comes in:

When using the by keyword in the implementation of HealthCheck, referring to the healthCheck instance, the compiler will generate the method healthy in WishListHttpClient like in the previous version.

With the current implementation, it would be a bit complicated to create an instance of WishListHttpClient, which would look something like this, given a url and an instance of HttpClient:

Instead of delegating an instance of HealthCheck given as a constructor argument, we can delegate a new instance directly:

In this case, this gives better control of the url for /ping and /api since they are now defined in the same place, and it will be easier to instantiate given a url and an instance of HttpClient:

A probable scenario is that we would like to add a cache to the retrieveWishList function to lower the number of requests to the API. We can do this with minimal effort, creating a new class that delegates to an instance of WishListClient, only overriding the retrieveWishList function to add caching:

This article has shown some ways to use the built in delegation feature in Kotlin, and hopefully it might have been helpful in identifying cases where delegation can be useful. There are also other use cases for delegation i Kotlin, with delegated properties.

Delegation

Vi er to nyutdannede interaksjonsdesignere fra UiO som startet å jobbe hos Bekk i august. Fra tiden på skolebenken hadde vi lite erfaring med smidige team, og vi gikk derfor inn i arbeidslivet med nysgjerrighet for hvordan det å jobbe smidig fungerer i praksis. I denne artikkelen prøver vi å svare på noen spørsmål vi hadde før vi startet.

I Bekk bruker vi begrepet “kontinuerlig design” for å omtale en designers rolle i smidige team. Dette begrepet viste seg å innebære en ganske stor omveltning fra den tradisjonelle designprosessen, slik vi kjente den fra skolen. Den klassiske designprosessen består gjerne av flere steg man kan følge i en viss rekkefølge. For eksempel kan en typisk design thinking-prosess bestå av fem faser; samle innsikt, definere, idégenerere, prototype og til slutt teste. Stegene skal så klart itereres, men fungerer likevel som tydelige, definerbare faser. Det er trygt og godt. Sånn er ikke kontinuerlig design. I kontinuerlig design er mange baller i luften samtidig uten en helt åpenbar oppskrift å følge. Det er fordi omstendighetene kan endre seg så fort at det ikke er hensiktsmessig med en detaljert oppskrift. Raske endringer kan være utfordrende for hvem som helst, men kanskje spesielt for en som er ny i arbeidslivet og ikke har mange års erfaring å lene seg på.

Etter snart 5 måneder i arbeidslivet er vi mange erfaringer rikere og ønsker å dele våre tanker rundt noen store spørsmål vi hadde i begynnelsen. Kanskje det er nyttig for deg som student eller for deg som ikke er helt fortrolig med designrollen i et smidig team?

Er dette døden for detaljerte skisser?

Det tar lang tid å lage detaljerte skisser. Noen ganger er det ikke verdt det, og i et smidig team er det kanskje ikke nødvendig. Vi tror det er lurt å tenke aktivt på hva skissene skal brukes til. Enkle skisser kan være nyttige ved brukertester for å demonstrere et konsept. Av og til er detaljerte skisser nødvendige for at du som designer skal kunne se hvordan sluttresultatet blir – eller for å brukerteste detaljer. Dessverre har vi også erfart at detaljerte skisser kan få uheldige konsekvenser hvis det benyttes i feil situasjon. En veldig detaljert skisse ser gjerne ut som “ekte” vare og kan fort sette forventningene til ulike stakeholders for høyt. Det er verken kult for deg eller ditt team å ikke kunne møte disse forventningene. Vi har opplevd at ved å tenke aktivt på hva skissen skal brukes til, går vi ikke i den fellen.

PS: Siden penn og papir er litt vrient å dele digitalt anbefaler vi Sketchy Wireframes for Figma for å lage enkle skisser digitalt.

Har man tid til å lage kule brukeropplevelser?

Fokuset i smidige team er å få funksjonalitet fort ut til brukeren, slik at man kan begynne å måle og lære av reell bruk. Slike kontinuerlige leveranser skal gi verdi til både brukere og kunden. Ovenfor teamet og stakeholders kan det være vanskelig å argumentere for å bruke tid på det som tilsynelatende “bare” er en liten animasjon. Hvordan kan man da prioritere å designe for kule brukeropplevelser?

Dette synes vi er en vanskelig problemstilling som vi på ingen måte har funnet et fullstendig svar på. Men vi har forsøkt å stille oss selv spørsmålet “Hva kan jeg gjøre her med den tiden jeg har for at brukeropplevelsen kan løftes?”. Om du er alene som designer i et smidig team kan dette spørsmålet havne i bakhodet av og til. Da kan det være nyttig å hente inspirasjon fra andre designere. Det skal ikke mer enn en kjapp videosamtale til for å få innspill som kan løfte brukeropplevelsen. Har man ikke andre designere til rådighet kan man også invitere andre på teamet til en liten idégenereringsrunde. Vi har begge opplevd at det aller viktigste er å få et annet perspektiv enn ditt eget når man står fast og har dårlig tid. Det er også mulig å sette av en viss mengde av prosjekt-tiden til “hackaton” hvor du sammen med utviklerne kan bruke tid på å for eksempel lage kule animasjoner eller finpusse tekstene.

Hvordan kan man være så mye nedi “grøten” og se det store perspektivet samtidig?

Å være en designer i et smidig team betyr blant annet å følge oppgaver som utviklerne jobber med, samtidig som man planlegger hva som skal gjøres i neste sprint. Dette gjør at man blir sittende mye med enkeltoppgaver og små funksjoner i produktet. Vår opplevelse har vært at vi av og til glemmer å løfte blikket opp og se det store bildet av hvor produktet er på vei.

Hvordan tar man seg tid til å løfte blikket i en stressende hverdag? For å gjøre det har vi sett oss nødt til å ta en fot i bakken innimellom for å vurdere om det vi lager nå ivaretar målet til teamet. Sett gjerne av en halvtime med produkteier, utviklere eller noen andre på teamet kan være til hjelp for å forsikre seg om at du er på riktig vei.

_________________________________

Kort oppsummert kan vi si at å være designer i et smidig team betyr å være på forskudd, og se både detaljene og det store målbildet samtidig. Slike ferdigheter krever erfaring og det vil også variere hvordan man håndterer dette i ulike team, kunder og domener. Det er viktig å være tilpasningsdyktig, jobbe raskt og samtidig klare å sette av tid til å designe for gode brukeropplevelser.

Planen var egentlig å skrive noe om designsystem i smidige team, men i kjent studentstil er denne artikkelen produkt av et skikkelig skippertak. Kanskje vi er kvitt studentvanene neste år? God jul!🎅

Takk Anna og Live for gjennomlesning og støtte!

Å være nyutdannede designer på et smidig team

The past few months in 2020 has provided us with completely new challenges talk-wise.

My advice would be to try to stick to as normal procedure as possible, and in some way try to forget that the situation we are in, and that it is different from what we all want it to be.

Dont focus on what is not working.

First of all, most of us are at this point pretty tired of technical issues of various kinds, we are also fed up with joking about it, so why not try to to minimize the effects that these have on the points you want to get through? If you have issues with the camera or the sound, try discretely to fix it without drawing too much attention to it. We are more than used to this now. If it takes way too much time, you could consider adding a small comment, but try to tone it down.

What can you do to make it easier for yourself to hold the presentation? As many may have noticed, the lack of feedback you inevitably get from the audience when they are actually present with you, can be a bit off-putting.

Some platforms, like Zoom and Teams, have the functionality to choose a sequence of participants to focus on. Just as you would in a more classic talk, you can choose to watch more closely those who seems to paying the most attention, and have a vivid body language.

How to handle non-attentive audience?\ \ What do you do if you spot someone in your (maybe even preselected) audience who seems to drop their attention, or maybe even yawn or looking at their phone? Just as in a live setting there is really little you can do about it, other than trying to ignore it (and then focuse on someone with more orderly digital manners), and try to push through as unaffected as possible.

Dress normally.

\ Another tip would be to dress and act just as you would in the hopefully more normal setting we eventually will return to. To run your talk while standing should also be as natural as it would be in a live setting.

Remove background stuff.\ \ Also try to remove any background noise, both visually and audially, from your talk. While it still is somewhat cute with animals, plants, santa clauses or home-made snowmen in the background of your surroundings, this is probably still best in more familiar settings with your closer collegaues. Try to keep it a bit more professional and avoid needless distractions where you can.\ \ Keep clean slides.

Your slides may have to be altered a bit from a regular talk. Keeping slides clean is always a virtue - with the smaller screens that is most often used by the participants in a digital setting - one must focus even a bit more to keep headlines and text visual enough so the audience will be able to read it with as little effort as possible.

Good luck in honing your presentation skills even digitally!

How to improve your digital presentations.

After years of disagreements about the long awaited next version of ECMAScript, on December 3, 2009, the 5th edition was finally released. A full 10 years after the previous version. With it came a lot of security improvements, one of which is known as "strict mode".

Motivation

JavaScript is a strange language. Its history is complex, and it has come to accept some confusing code. In fact, so confusing it might actually be a bug you'd expect the compiler to let you know about.

Perhaps you accidentally mistyped a variable?

Surely the compiler will let you know you're assigning to an undeclared variable? Nope! You just got yourself a brand new variable called usreAge.

Perhaps you're unaware of reserved keywords?

Surely the compiler will let you know you're assigning to a reserved keyword? Nope! You've just saved the user's name as undefined.

Perhaps you mistyped a function parameter name?

Surely the compiler will let you know you have duplicate parameter names? Nope! The first parameter you pass your function will be ignored.

Perhaps you mistook a primitive type for an object?

Surely the compiler will let you know you can't create properties on a primitive type? Nope! This does nothing and fails silently.

Introducing strict mode

As I'm sure you can understand, the examples above allows for some crazy bugs and can even pose a serious security threat. To deal with this ECMAScript 5 introduces strict mode, a subset with some different semantics and more thorough error-checking. If you try to run any of the code examples above in strict mode it will result in some kind of error being thrown by the compiler. Because this is a "new" feature, not all browsers support this, but most modern browser do. Browsers not supporting strict mode will run strict mode code as if it was normal code.

Strict mode makes three general changes to normal JavaScript semantics. Shamelessly copied from MDN: 1. Eliminates some JavaScript silent errors by changing them to throw errors. 2. Fixes mistakes that make it difficult for JavaScript engines to perform optimizations: strict mode code can sometimes be made to run faster than identical code that's not strict mode. 3. Prohibits some syntax likely to be defined in future versions of ECMAScript.

How to activate strict mode

In order to be backwards compatible, and not cause any problems in older browsers, strict mode is not enabled by a statement, but by a literal expression. This literal expression will simply be ignored by older browsers, is it doesn't really do anything. To activate strict mode, just add the magic words 'use strict'; (or "use strict";) at the top of your code.

Strict mode can be activated for entire scripts or for individual functions. Also, JavaScript modules, introduced in ECMAScript 2015, are automatically in strict mode. The expression must be at the beginning of the script or function, before any other code.

Preparing for the future

In addition to adding security and preventing bugs, strict mode also adds a couple of other restrictions to help you write future-proof code.

Reserved keywords

This first restriction is pretty simple. A short list of identifiers (which weren't keywords yet at the time) become reserved keywords. These keywords are implements, interface, let, package, private, protected, public, static, and yield. In strict mode, these keywords are not allowed as variables or arguments.

Block level functions

This second restriction is a bit more complicated. Neither ECMAScript 3 nor ECMAScript 5 has block level functions as part of their specifications. Functions were only supposed to be at the top level of a script or of a function. However, many browsers implemented support for block level functions, but with incompatible semantics between them.

Strict mode in ES 5 prohibits such functions and causes a syntax error. Great! But then came ES 2015 which actually introduces block level functions in the specification. So then all is well in ES 2015? Nope, because Annex B introduces some additional ECMAScript features for web browsers causing some confusion to remain about block level functions when not running in strict mode.

Transitioning to strict mode

Hopefully most of the code you write in 2020 is already strict mode compatible. But in case it's not, or you need to tend to some old code, you might need a bit of help to adjust your codebase. That's fine, but it's getting late now, and I need to publish this blog post before midnight, so I really need to wrap this up. Fortunately for you, MDN has a great article on the subject. Have fun!

Strict mode

Building static pages with React is a great way to improve the experience of a website. But how do they work, and how can you still get the static pages to change when your data changes?

Why would I want static pages, isn't React all about dynamic client-side rendered content?

When you load a regular React app in a browser there are a lot of things happening in the background before you can see any content on the page. The browser has to load a lot of HTML, CSS, and JavaScript before any content can be displayed to the user.

First, after the JavaScript has been downloaded and parsed we can begin fetching data from an API. This can lead to waiting times, spinners, and an overall slower experience of the website.

With static pages, we can make sure the users see the content as soon as possible, by including the content in the initial HTML from the server. This means we will not have to wait for JavaScript to load before displaying meaningful content, and the users will not have to wait for potentially slow API-calls to finish before dynamic content is visible.

The difference in load times

Let us take an example of an article page. Below is the exact same component loaded in two different ways. The client-side approach fetches the article in a useEffect hook, while the static site approach fetches the article at build time and bundles it as part of the initial HTML.

Client-side renderingStatic site generation

What you are seeing in the two gifs is what a page looks like when it is reloaded using the two different approaches. This also applies to navigating from one page to another inside the same app. But, the greatest difference you will see is when loading the page for the first time.

Loading data in static pages

Static pages are rendered at build-time, which means you have to know which data to fetch at build-time as well. It also means that the data is constant for that build of the app, and you have to build the app all over again to update the content.

Enter the solution: incremental static regeneration (ISR)

With incremental rebuild we allow the previously static data to change without building the app from scratch. We can re-build pages on demand when changes occur, or at certain intervals when users load pages.

The interval-based approach relies mostly on timers. The application defines how often the page will be re-built. pages can be re-built whenever a user visits the page if the timer from the previous build has run out.

The on-demand approach works by allowing webhooks to trigger a rebuild of a page. This works great for headless content management systems, where a webhook can be triggered when an entry is changed. Rebuilds will then only be done when relevant data is changed.

What we can't do with static pages

With all this talk of pages being static, we leave out some of the parts that can't be static. Content such as user information, or browser-specific data is impossible to know at build-time.

This does not make it impossible to display such data on a static page. It only means that this data won't be available instantly like the static data. It can still be loaded on the client like with regular React apps!

Getting started with static pages in React

There are currently two major players in the market for building static pages with React, Next and Gatsby. There are of course other solutions, such as the upcoming Remix, and the possibility of building it yourself!

As of 2020 this site is built with Gatsby and uses static rendering for all articles.

This article uses Next as its building block for using static site generation. Next is a framework built around React. It offers a lot of functionality, such as static pages, routing, automatic bundle splitting, i18n, and much more. It can be used in much the same way as Create React App and is just as easy to set up.

Rendering only on the client

When rendering React on a client you'll start of with a very basic html template just to get the app started. Create React App builds something like this:

When the HTML has been parsed by the client the client will start loading CSS and JavaScript files. Once the JavaScript files have been loaded and parsed the react app will render in the root div.

Rendering on both the server and the client

Static site generation works in much the same way as client-side rendering. The initial HTML for a page will contain all the content since the app is rendered on the server. And it will be visible to the user before the JavaScript is parsed, or even downloaded!

When the JavaScript has finally loaded the client rehydrates the existing HTML instead of overwriting it. It takes over the HTML that was delivered by the server and renders it again on the client. It will now behave like any other React app. Operations such as navigating from one page in the app to another will render that page on the client, instead of waiting for the server to respond.

Static Site Generation with Next

Next uses a file-system based router, which means each route in the app has a corresponding file. This file exports the Component that will be rendered on that route, and can also export a set of functions for data fetching if needed.

Data fetching with static site generation

For static sites, we have to fetch data at build-time. With Next we can do this with the combination of getStaticProps and getStaticPaths. These functions are exported from the page file, which corresponds with a given route in our application. In this case, we will use the path /articles/[articleId], where articleId is a parameter in the URL.

With getStaticPaths you have to get all the URL parameters required for a static page. Since the URL we are using has a parameter we have to return a list of all the articles we want to be rendered as static pages.

Any articleId not present in the paths will direct to a 404 page by default. If we have too many articles to render at build time we can allow them to be rendered in runtime on the client with the fallback option.

getStaticProps is where we actually get the article we want to render. It gets called once for each path returned by getStaticPaths. The props returned by this function will be passed to the top-level component of our page.

Incremental Static Regeneration in Next

Since pages are rendered at build time we reach a problem when the data in our page changes. With static site generation, we would have to build our application all over again to update any of the pages.

With incremental static regeneration, we can re-render pages at defined intervals. Such as when a user requests the page to update. By using the revalidate option in getStaticProps we can define how long we should wait until the given page is re-rendered.

Combining static pages with dynamic data fetching

Static pages can work very well by themselves, but that won't stop you from combining them with other forms of data fetching!

As an earlier part of this calendar, we had an article on Intelligent fetching and caching with SWR.

To combine the two approaches we can populate the initial data of the SWR hook with static our data. By doing this you can get the best of both worlds, no loading times, and dynamic data you can mutate.

Ready to build static pages?

In short, static pages allow you to deliver content faster and with less strain on APIs and servers. With incremental regeneration, it is also possible to make the content dynamic to a certain extent.

Have you found any nice use cases for the technology, or are you otherwise eager to try it out? It's as easy to start as with any other React project, I've fallen in love with the concept and I'm sure you will love it too!

Rebuild static pages on-demand with incremental static regeneration

Elm doesn't have a concept of required and optional arguments. Every function takes all the arguments they specify, no more, no less. But sometimes we want to be able to specify only some arguments to a function, and use default values for the rest. The builder pattern is one solution to that challenge.

Let's start with a common use case for the builder pattern in Elm: view elements. These are reusable elements that can be used in view code in different places in an app. The most common examples are buttons, input fields, and links. What these elements have in common is that they should be reusable, but that they are not necessarily identical everywhere they are used. A button could be solid or just have an outline, and have different colors depending on where you use it. Text input fields could differ in size, have error messages, or be disabled.

If we were to write separate functions for each of these variants of view elements, we would end up with many similiar, but slightly different, functions, to account for all the combinations of characteristics.

There are multiple strategies to deal with this challenge in Elm, and Brian Hicks examines many of them in his excellent talk Robot Buttons from Mars, which is where I first learned about the builder pattern in Elm. To see the alternatives to the builder pattern, and the limitations with those alternatives, I would encourage you to watch that talk.

A Simple Text Field

We will examine this technique by creating an element for text input fields. We will start out with only required arguments, and build out the capabilities from there. We want our text field to take 3 required arguments: value (the text the user has typed), onChange (the message to be sent when the user types), and a label text, to help with accessibility. In our example we will start with the following, simplified HTML, where our required arguments are shown in braces:

We will keep all the functionality related to text inputs in one file, which we will call Input.elm. And we will structure our code around an opaque type called Input, which will hold all of our options for the text field. Input has the following type signature:

We will create a constructor function for making an Input, which will be exposed by our module:

To transform an Input into Html, we create the following function:

So to use our new view element, we do the following (where NameChanged is a message that takes a String as an argument):

If that's the only way our text fields look and behave, this would have been an extremely overengineered solution. But the moment we have different needs in different text fields, this solution starts to shine.

Expanding Capabilities

We can continue by adding the ability for our text fields to have a placeholder text. Placeholder texts shouldn't be required in all text fields in our app, so we will add it as a Maybe String in our options record:

Then we have to add it to our constructor. But crucially, we won't require it as an argument, we will just initialize it to Nothing:

To use the placeholder in the HTML, we modify the toHtml function to take the option into account:

To actually set a placeholder on a text field, we create the following function:

And to use the withPlaceholder function in our view, we simply add one line:

The handy thing here is that adding the placeholder capability to our Input module doesn't have to result in any code changes in places that already use the text field without a placeholder! This is especially important as your app starts to grow, and you are using a view element in tens or hundreds of places in your code!

Conclusion

In this article I have hopefully shown that the builder pattern is a nice way to handle optional arguments in Elm. Whether using the builder pattern is right for you in your app depends on the size and complexity of your code base. But if you find yourself adding a lot of helper functions for different variations of view elements, I hope you will give it a try. I, at least, have really enjoyed working with it.

The Builder Pattern

I gårsdagens luke skrev vi om hvordan bærekraft går fra å være en omdømmeparameter til en økonomisk nøkkelfaktor, og hvordan regulatoriske krav på både globalt og lokalt nivå spiller inn på selskapenes bærekraftsarbeid. Og i år kommer EU virkelig med en regulatorisk julegave – et klassifiseringssystem for bærekraft: EU-Taksonomien.

Hva er EU-Taksonomien?

EU-Taksonomien er en del av EU-kommisjonens handlingsplan for bærekraftig finans. Den ble lansert i år, og planen er å implementere klassifiseringssystemet innen utgangen av 2022. Enkelt forklart er taksonomien et sett med bransjespesifikke, tekniske krav som skal gjøre det enklere å klassifisere hvorvidt aktiviteter er bærekraftige eller ikke.

Bærekraftbegrepet vil som sådan gjennomgå en renselsesprosess, der bedrifters forsøk på grønnvasking ikke lenger vil være tilstrekkelig. Det bedrifter foretar seg av inntektsgivende aktiviteter og investeringer må oppfylle tre overordnede krav for å bli ansett som bærekraftige:



Aktiviteten må bidra vesentlig til minst ett av EUs seks miljømål, vurdert etter bestemte krav:

a. Begrensinger av klimaendringer

b. Tilpasning til klimaendringer

c. Bærekraftig bruk og beskyttelse av vann- og marine ressurser

d. Omstilling til en sirkulær økonomi

e. Forebyggelse og begrensing av forurensing

f. Beskyttelse og rehabilitering av biologisk mangfold og økosystemer



Aktiviteten kan ikke gjøre vesentlig skade på noen av de øvrige fem miljømålene, vurdert etter et sett med kriterier.



Aktiviteten må oppfylle sosiale minimumsstandarder basert på FNs prinsipper for næringsliv og menneskerettigheter, OECDs retningslinjer for flernasjonale selskaper og ILO-konvensjoner.

I første omgang, har EU prioritert å utvikle tekniske krav for de bransjene som har størst påvirkning på klimagassutslippene per i dag. Dette er 1) land- og jordbruk, 2) industri, 3) elektrisitet, gass, damp og varmtvannsforsyning, 4) vannforsyning, avløps- og renovasjonsvirksomhet, 5) transport og lagring, 6) informasjon og kommunikasjon, 7) bygg og anlegg, 8) forsikringstjenester og 9) ingeniørtjenester.

Her er et eksempel på hva et bransjespesifikt, teknisk krav kan være: For et offentlig transportmiddel, som er en del av transport- og lagringssektoren, gjelder følgende tekniske krav for å anses å bidra vesentlig til EUs miljømål nr. 1 om å begrense klimaendringer:

Transportmidler (f.eks. t-bane, trikk, buss og jernbane) som har null direkte utslipp, målt i gram CO2-ekvivalenter per passasjerkilometer (gCO2e/pkm), er kvalifisert. Blant annet hel-elektriske og hydrogenbaserte kjøretøy anses å ha null direkte utslipp.

Andre flåter er kvalifisert hvis direkte utslipp er under 50 gCO2e/pkm frem til 2025 (ikke-kvalifisert deretter).

I tillegg må transportmiddelet overholde krav om ikke å gjøre vesentlig skade på noen av de andre fem miljømålene, samt oppfylle sosiale minimumsstandarder knyttet til blant annet menneskerettigheter, for å være kvalifisert til å regnes som bærekraftig i henhold til EU-taksonomien.

Eksempelet ovenfor viser til spesifikke tallfestede terskelverdier for én bransje, og andre bransjer vil følgelig være tilknyttet andre terskelverdier innenfor felter relevant for den aktuelle bransjen. Disse kravene vil forplikte bedrifter til å foreta operasjonelle og strategiske grep for å sikre at forretningsdriften faktisk er bærekraftig.

Hvem vil det påvirke?

Først og fremst er det finansmarkedsaktørene EU-taksonomien vil påvirke direkte. Med finansmarkedsaktører menes blant annet verdipapirforetak, investorer, kapitalforvaltere, forsikringsaktører m.m. Disse aktørene må kunne opplyse om hvor stor andel av et fond eller en portefølje som, ifølge EU-taksonomien, er bærekraftig. La oss kalle det en «grønn brøk».

I tillegg, vil alle børsnoterte foretak og virksomheter med flere enn 500 ansatte bli direkte påvirket gjennom en rapporteringsplikt som kommer i tillegg til det de i dag er pliktig til å redegjøre for om sitt samfunnsansvar. Selv om dette rapporteringsarbeidet vil være omfattende og ressurskrevende, er det nødvendig at disse selskapene må rapportere i hvilken grad deres inntektsstrømmer og investeringer er i tråd med EU-taksonomien. Hvis ikke, har ikke finansmarkedsaktørene nødvendig data til å kunne opplyse om sin grønne brøk.

Ettersom eierskapet til inntektsstrømmer og investeringer er distribuert rundt i flere divisjoner og på ulike nivåer i en organisasjon, vil EU-taksonomien på ett eller annet tidspunkt påvirke ansatte på alle nivå av organisasjonen. Når du som forretningsutvikler skal pitche en ny investering til ledergruppen, vil du sannsynligvis være helt avhengig av å ha med en klassifiseringsvurdering knyttet til bærekraft, sammen med markeds- og lønnsomhetsvurderingene.

Dette vil kreve store omstillinger internt i de aller fleste virksomheter, og tiden er knapp. Da lønner det seg å begynne forberedelsene allerede nå.

Dette er det du bør gjøre:

1. Identifiser hvilke krav som påvirker din bransje og ditt selskap spesifikt

Det første du bør gå i gang med, er å sette deg inn i hvilke bransjer din virksomhet omfattes av, i henhold til taksonomiens definisjoner. Videre må du identifisere hvilke tekniske krav som stilles til bedriftens aktiviteter for å kunne defineres som bærekraftig.

2. Kartlegg nåsituasjonen

Med kravene som utgangspunkt, bør du kartlegge nåsituasjonen for alle dine inntektsstrømmer og investeringer, både kapitalkostnader (capex) og driftskostnader (opex). Det høres kanskje ut som et omfattende arbeid, og det kommer det også til å være. Her vil man være helt avhengig av å legge en god plan for arbeidet, foreta gode prioriteringer, og starte med det viktigste. Ettersom det er et nytt klassifiseringssystem, og bedriften din nødvendigvis ikke har gjort vurderingene før, vil øvelsen være krevende, men likevel nødvendig.

3. Definer målbilde og strategi

Ettersom kartlegging av nåsituasjon kan være et omfattende arbeid, bør startpunktet være å definere en tydelig strategi og et målbilde for bærekraft i selskapet. Hvor ønsker bedriften din å legge ambisjonsnivået? Taksonomien setter noen minimumskrav som må tilfredsstilles, men ønsker man å legge seg på dette nivået, eller ønsker man å innta en mer ledende posisjon? Minimumskravene vil fort bli hygienefaktorer i markedet for bærekraftig finans, og det kan gi et konkurransefortrinn dersom man forplikter seg til et mer ambisiøst målbilde.

4. Kartlegg gapet

Når nåsituasjonen og målbildet er på plass, bør man identifisere gapet som på sikt må tettes. Innenfor noen områder kan man ligge godt an, mens på andre områder har man kanskje en lengre vei å gå. Det er viktig å presisere at taksonomien ikke krever at alle økonomiske aktiviteter er bærekraftige. Den sier bare at dersom du ønsker å klassifisere den som bærekraftig, må den oppfylle taksonomiens krav. Det betyr også at gapet ikke nødvendigvis må tettes i sin helhet. Strategien og målbildet vil derfor være et essensielt fundament for å identifisere hvilke gap som skal tettes.

5. Utforme tiltak som forankres i hele organisasjonen

Med et grunnleggende kartleggingsarbeid i bunn, og en tydelig ambisjon som beskriver hvor bærekraftig selskapet skal være, er tiden kommet for å lage en tydelig plan for hvordan virksomheten skal jobbe seg mot målbildet som er definert. Her vil systematiske målstyringsverktøy, eksempelvis OKR, kunne være svært nyttig. På denne måten vil man få forankret og operasjonalisert strategien på alle nivå, slik man er omforent om hvor man skal og hva som skal til for å nå målbildet. Og det er her jobben starter.

Det helt sikkert at EU-Taksonomien vil komme i stor fart inn i næringslivet. Det er forventet at den vil utvikles over tid, og at skruene strammes til etter hvert som den forankres godt i hele det globale næringslivet. Stegene som er beskrevet ovenfor er på mange måter en stor engangsøvelse i implementeringsfasen, men rapporteringsplikten vil vedvare. Det samme vil markedskreftene i finansmarkedene og blant kundene, og disse vil mest sannsynlig belønne de som lykkes.

EU-Taksonomien krever ikke at du blir mer bærekraftig, det er kun et klassifiseringssystem. Men, de som velger om du skal få tilgang på deres kapital eller ikke kan komme til å kreve det. Ikke gå i den fellen at du ser på taksonomien som noen minimumskrav du må forholde deg til. Bruk den heller som en kickstarter for å skape en fundamental bærekraftig strategi og forretning.

EU-Taksonomien – Den endelige kickstarter for bærekraftig forretning?

A CTF is a hacking competition. The participants compete for the highest score, by hacking intentionally vulnerable apps. It's a great deal of fun competing, but how does one host a CTF? This is the story of how I've been doing it, and how my CTF rig has evolved.

How it all began

I'm a huge proponent of Capture The Flag competitions, and I've been involved in the CTF scene since my university days. Lucky for me, there was a CTF club at the University of Oslo. I've always been curious about hacking and the club quickly caught my attention. The club formerly known as UiO CTF (now Oslo CTF) organized workshops and competitions. Soon enough I was a dedicated member of the group and was heavily involved in organizing both competitions and workshops. One of my fondest memories is when we hosted an on-campus CTF with over 80 attendees, and we called a large Norwegian pizza restaurant chain requesting pizza for 80 people. The pizza place wasn't too happy, but they delivered while the head of the security department's jaw dropped when figured out that the department had to pay for 80 peoples worth of pizza. We had an absolute blast.

Challenges

of the CTF Club Hosting a CTF is a challenge in itself, infrastructure is hard. Especially while being an inexperienced student. The hosting infrastructure has gone through a few revisions during my time with the club. It started out very manual. Spinning up a virtual machine and deploying every task individually, configuring certificates manually with nginx. Everything hosted using the free credits you get, when signing up for a Google Cloud Platform account. It worked, but it was a pain. The next evolution of the platform was the use of containers. Every task had its own container, and it made starting the challenges easier. My friend ended up writing a bash script for starting everything. We finally had some degree of automation, and we kept working on the platform. More and more scripts were written. We had a script for pulling the challenges from GitHub, one for starting everything, and another for modifying nginx configurations files to set up TLS certificates and subdomains, and another for setting up CTFd. In the end, we ended up with a hack job of epic proportions which consisted of several python and bash scripts. It was getting out of hand, and it became excruciatingly unmaintainable, but it did the job.

Still in the game

I graduated with a master’s degree in Computer Science with a heavy focus on Information Security and remained involved with the CTF club post-graduation. Real life awaited me and joined Bekk as a consultant in 2019. Soon enough I became involved with the security group at Bekk. The new direction of the security group was to improve security skills and knowledge through the use of CTF-challenges and wargames. The timing could not have been better, and I felt that I could bring something valuable to the group as a whole given my CTF experience. The security group also provides internal and external services. Security consulting, workshops, and so on.

The Pandemic

Covid19 hit like a brick, chaos emerged, the S&P 500 tanked, and the Bekk recruitment apparatus had to pivot quickly in order. Company presentations at universities and colleges were no longer possible, thus emerged project Pangea. The goal was an online platform consisting of multiple presentations, articles, activities, and competitions. Every part of Bekk was encouraged to contribute, and I got a request for organizing a CTF. I was excited, and I grossly underestimated the time and effort needed to pull it all together. I could have just reused the stuff we had made during the time at Oslo-CTF, but it didn't feel right, since I didn't technically own it, so I started working on my own infrastructure. Oh boy, how I grossly underestimated the time and effort needed to pull this thing off.

Chasing clouds

I dug out a few tasks I had made in the past and started working on quite a few new ones. This was the "easy" part, the challenge was the infrastructure. As I was comfortable with Google Cloud Platform, I picked GCP as my cloud provider. The first thing I looked at was Google Cloud Run, a really neat serverless service. Dockerize the challenge, deploy, and only pay when the container is processing incoming and outgoing traffic. It seemed too good to be true, and unfortunately, it was. I had this odd edge case, where quite a few challenges required interaction over raw TCP. The problem was that Cloud Run requires apps that communicate over HTTP, so back to the drawing board I went. The next obvious choice was Google Compute Engine, a virtual machine.

Automation Nation

Since every challenge was a docker container, in addition to there being a docker image for CTFd I ended up putting it all into a docker-compose file. Now I could easily start every challenge rapidly, but I still had the issue of setting up subdomains and TLS certificates. I had used nginx in the past, but as I started configuring, I soon realized that it would be far too tedious to do manually. There had to be a better way, and there was. After some intense research, I discovered Traefik. Traefik was a total game-changer, if only we had known about this back in my university days. It could do subdomains, service discovery, certificates, and routing. Again, it seemed almost too good to be true, but luckily for me, this time it turned out to be to be the missing piece to the puzzle.

The Missing Piece

Traefik was a little finicky to begin with, with their documentation was somewhat lacking in examples. Especially when it came to the business of issuing certificates. I wanted to issue a wild card certificate, but there weren't good any examples in the documentation on how to do this. Secondly, my domain provider didn't even support wild card certs in with their DNS service. Cloudflare came to the rescue. It was free, and very straight forward to set up. Quite a few StackOverflow threads later, I finally figured out how to accomplish what I wanted to achieve. This was the final piece of my infrastructure puzzle. Traefik, CTFd, and the challenges all bundled together in a docker-compose file. One docker-compose up -d later, and I was good to go. All though I did mess things up by repeatedly deleting a folder containing certificates causing my infrastructure to request way too many certs from Let's Encrypt and having to change the subdomains of multiple challenges, it was overall a great success. I managed to pull it all together before the deadline. Hours of hard work and research finally paid off. The CTF was a success and ran without any major hiccups.

Future Improvements

My new platform is by no means perfect, and there are some things I wish were different. Like having a proper CI/CD pipeline for deploying the challenges. I don't think my setup will scale very well, and I wish to introduce proper container orchestration with Kubernetes in the future. At least it fits my current needs and is way more modular and reusable than it has ever been. I've put down hours and hours of work, and I have learned so much about so many new things throughout the whole process. It has ultimately been a rewarding experience. This may not be the best way to host a CTF. I don't even know if it a good way to host CTF, but this has been how I host a CTF.

Onwards and upwards!

I started out with a total mess and ended up with something I can live with, and it suits my current needs. It's easy to set up, and it does the job. Hopefully, this may be of some use if you ever plan on host a CTF for your friends, colleagues, or CTF club. There are several improvements to be made, and I'll keep hacking at it when I find the time. The dream is to build a platform that can be set up with a click in a matter of seconds at the click of a button, but there's a long way to go, and a bumpy road ahead. The current rig probably won't survive over 9000 hackers, but it has survived 30 hackers with great ease.

18-Dec

Today's posts