Wintertime has always struck me as somewhat offset from the holiday season. The weather gets cold and dark, but snow seems to be in its primetime around January and February, at least here in Oslo. As a result, people around the world may have to resort to simply dreaming of a white Christmas. But regardless of where you live and the level of crystalline precipitation thereabouts, we have the technology to make it snow right now! In your browser at least.

There are a number of ways to make snow in your browser. For example, clever use of HTML and SCSS can get you some fairly dynamic snow. CSS really isn't built for that kind of thing though, and you'll often get some rough performance if you want a whole lot of particles. Plus, why stop at just snow? Let's make a nice winter landscape!

For today's article we'll use my weapon of choice for creative coding, namely p5.js. It's a library quite literally made for creative coding, effectively offering a wrapper around the HTML Canvas API to make it easier to work with. As opposed to Canvas, most of the p5 API is fairly self-explanatory. For example, drawing a circle is as simple as circle(x, y, diameter). Let's do that right now!

Drawing a delightful disk

As we move through this article we will provide sandboxes like the one below so you can see both the code and the result. The live editor doesn't seem to update the result, so just press "Open Sandbox" in the lower right corner if you want to tweak parameters. I highly recommend it! We will explain the code following each sandbox regardless.

P5 offers an API of functions and values, and it runs by looking for certain named functions in your code. The most important ones to know about are setup() and draw():

The setup function runs at the start when you open the sketch, and only once. That's handy for setting up your data structure, variables, and so on. Most importantly, you'll want to create a canvas element with a certain resolution. Here we went with (1080, 1350) because that's the maximum resolution Instagram accepts 😉. We also draw a background at the start for some warm cozy vibes to go with our upcoming snow.

Meanwhile, the draw function runs every time your screen renders a new frame. This typically occurs around 60 times per second, but some screens offer a higher frame rate. The draw function is where we'll place most of our shape computation, but for now we just draw a big circle at the center of the canvas.

I won't go too in-depth on the p5 API, as you can find just about everything you need in the reference or the examples. There's even an example of simulating snowflakes there, which served as one of the main inspirations for this article. Speaking of which, let's get started on simulating snow.

Simulating some static snow

We should probably have more than a single snowflake. In fact, we should probably have infinite snowflakes. There are many clever ways to do that kind of thing, and I wouldn't really say one way is worse than the other. As long as the code can expand to support more features then you'll be fine! You probably won't look back at the code when you feel like you've completed the sketch anyways, so don't fret over code quality. But I digress! Here is our first set of snowflakes:

At the top of the code I put some of the constants that can be tweaked for the sketch, making it easier to play around with values. In order to keep track of our snowflakes, I've created a very basic list of objects in the setup function where we'll store their position. At the start we'll just offer them a random spot on the canvas.

In the draw function we'll iterate through this list of objects and draw a circle to represent each snowflake. After it is drawn, we'll update the position of the snowflake so it will look like it moved in the next frame. If the snowflake has passed beyond the edge of the canvas, we'll just put it right back on the top again. Also note that we now draw the background at the start of every frame so we have a clear canvas every time we draw the snowflakes at their new positions.

This is a great start, but the snowflakes all seem fairly static. While their pattern is random, the pattern doesn't change and the looping can be very obvious as a result. Furthermore, our upcoming landscape scene is lacking in depth, so let's add some!

Learning to love layers of lists

To provide som illusion of depth, we can think of some basics of perspective. Like imagine looking out the window of a moving train and looking at the passing landscape. Things that are further away from the train look smaller and like they move slower. Conversely, things that are close by look bigger and move faster.

The snowflake data structure is now a list of lists, where the inner lists represent a layer of snowflakes. While we could have simply assigned a random layer to a snowflake at initialization, this structure will come in handy when we play around with depth again later. Now that the data structure is layered, we can make the snowflakes appear layered too. We've created the updateSnowflake() function to get all the snowflake computation in one place. The first thing we'll do is adjust the size of the snowflakes by simply scaling the size of the snowflakes with their layer index.

In terms of movement we can also make snowflakes in the back move slightly slower than the ones in the front. Instead of a single static layer, we now have multiple static layers! To alleviate this we can assign each snowflake with a mass during the setup function, which factors into the speed at which the snowflakes fall. That way the pattern of snowflakes will change ever so slightly.

Now we're really getting somewhere! We have layering and some fairly dynamic vertical movement. However, there's a whole other axis we can work with too! Let's get into making some wind.

Working with wavy wind

Wind is sort of chaotic, so we need some sort of randomness. We've already used “true” randomness for the positioning and mass of the snowflakes, but that won't necessarily help us here. If we were to randomly move the snowflakes now, it would look all jittery, so we need to somehow make it look smooth. Thankfully I have just the tool for the job, and its name is Perlin noise.

Perlin noise kind of deserves an article of its own, as it really is just about the most powerful tool p5 has to offer (in my opinion). In the simplest of terms, Perlin noise can be described as “random, but smooth”. Let's look at a quick comparison:

The noise() function works similarly to random(), in that both functions return a number between 0 and 1. The random function gives you a different result every time, and is great for when you want uniform distribution. The upside of the noise function is that when you call the function with the same parameters two times, you get the same result. Similarly, calling the function two times with similar parameters offers a similar result. If you really want to get into some use cases of Perlin noise, then I highly recommend the introduction to Daniel Shiffman's The Nature of Code. He uses a language called Processing, which is what p5.js is based on. The syntax is pretty much Java and all the functions work in pretty much the same way as they do in p5, so the code should be easy to translate. Anyway, let's get back to our wind.

The wind is computed in the latter half of our updateSnowflake() function. The noise function takes 1-3 parameters, representing dimensions. Or whatever you want them to, really. Let's dissect this line:

const wind = noise(snowflake.l, snowflake.y * WIND_CHANGE, frameCount * WIND_CHANGE) - 0.5;

First of all, we supply the snowflake layer as a parameter. That way we get slightly different wind for each layer, contributing to the chaos of it all. Secondly, we send in the current y-position of the snowflake. This is kind of what we did in the random vs. noise comparison above, just rotated 90 degrees. Thirdly, we change the Perlin noise over time. The frameCount value is provided to us by p5, and represents the number of frames that have passed since the sketch initialized. Note that the last two parameters here are tuned by our `WIND_CHANGE constant, which is a fairly low number. This ties back to the whole “similar parameters get similar values” thing, as a smaller change in parameters makes for a smoother curve.

Finally, the noise function returns a value between 0 and 1. We subtract -0.5 so that it returns a value between -0.5 and 0.5, making the snow swing back and forth.

With the wind in order, we now have ourselves some pretty cool snow! Honestly, writing the explanation took ten times the amount of time it took to code the snow itself. Once you get into the groove and start to get familiar with the tools at your disposal, the possibilities are endless! With our snow in order, we can combine our depth system and Perlin noise to generate some landscape to go with it! Let's hide the snowflakes for now and get to work on this winter wonderland.

Making majestic mountains

The ideal winter landscape will undoubtedly differ from person to person, but today I'll offer some escapism from the gray and dark city life many of us have grown accustomed to. Let's make a beautiful winter morning with great weather and some sweeping scenery!

We've added a more appropriate sky color, a sun, and some mountain ridges. The sun is drawn right on top of the background in the draw function. Our custom drawSun function is fairly simple, as it really is just a circle with some colored shadow. The shadow is an excellent example of how one can still use methods and properties of the Canvas API within p5, giving us this grossly incandescent sun!

For the mountain ridges we've made our own custom draw function again, called drawRidge(). This is where our layers of snow come in handy too, as we can call the drawRidge function as we iterate through our layers of snowflakes. This will then draw the layers in order so that the snowflakes should fall between the mountain ridges, providing additional depth! If each snowflake was simply assigned a random depth instead of the data structure itself being layered, we wouldn't get this effect.

The drawRidge function does a few neat things. First of all, we've defined two ridge colors at the top of the file, and we use those to determine the color of each ridge. P5 provides us with the lerpColor() function, which blends one color with a certain amount of the other. The first two parameters are our colors, and the third is a number between 0 and 1 determining how close the result will be to the first or second color. For example, using lerpColor(“red”, “blue”, 0.25) would result in a purple color closer to red, whereas lerpColor(“red”, “blue”, 1) would be completely blue. We opted for a lighter and more desaturated color in the distance, with a darker and somewhat clearer color close by. This again offers some illusion of depth, and we get a pretty cool stepwise gradient effect. Now I can't say I know as much about color theory as I'd like, but it also kind of looks like a given ridge gets lighter when it's closer to the next ridge, even though we only use one color per ridge. My eyes may be playing tricks on me, but this little optical illusion offers more depth to the scene, so I won't complain.

For the actual drawing of the ridge, we are given a y-coordinate and iterate through the row of pixels at that given coordinate. Simply drawing this shape would just give a straight line, but we use Perlin noise to make smooth and satisfyingly random inclines across the ridge. How far we zoom in on the noise determines how smooth the steps between the noise is, so we can make these ridges jagged and chaotic by simply tweaking some parameters too.

Note that we step over some pixels to reduce the amount of computation needed. One can hardly tell the difference visually with our default parameters, but chaotic ridges would look more spiky as a result of this.

Ready to reveal our riveting results

We're getting very close to the end result here, but the sun isn't quite right. It's sort of always the same flat thing, but how would we make it more dynamic? We could place the sun randomly, but I like how it looks just peeking over the ridges in the back. However, that implies our scene is sort of a sunrise or sunset, which is typically accompanied by a gradient in the sky! Thankfully we have already made just the thing for that. Oh, and we should also turn that snow back on.

I don't know about you, but that looks pretty nice to me. The layers of snow fall down gently between the mountain ridges, and we get that great gradient effect in the sky too. For the sky we just used the drawRidge function with different colors a few times before drawing the sun. The colors of the sky ridges are determined by blending the color of the sun with the original sky color.

Now that we have a playground, let's play around with some parameters and see what we can get out of it! You can open the final sandbox yourselves here, tweak parameters, save, and the result should update. Here are some images I got from tweaking the parameters at the top:

Simply tweaking the noise amp and zoom can make a big visual difference. In the image above we can make the ridges more akin to sand dunes, dense forests, or the kind of hostile looking mountains that are one medieval castle away from being the home of a secluded vampire. Colors make a huge difference too, as the dunes may as well be the rolling hills of a Windows wallpaper or waves at sea.

And that brings us to the end of this article! You can find the final source code in my generative art repository here.

Advice for aspiring artists

We've really only scratched the surface of what p5 is capable of, and what can be done in the world of generative art. Describing the full breadth of possibilities would require an article all by itself. So instead of that, I'll recommend some places you can get some inspiration! These days I get most of my inspiration from the subreddit r/generative as there are so many different people posting all kinds of crazy shit. There are also Instagram hashtags like #generativeart if that's more your kind of thing. For specific people to check out I'd recommend the following Instagram accounts:

Tyler Hobbs

Kjetil Golid

Ilya Borisov

Joshua Bagley

Most importantly I hope you're inspired to make weird stuff of your own! I obviously recommend p5 as it feels super familiar if you've ever worked with JavaScript before. As mentioned earlier, they have some great examples where you can just jump into their web editor and get to tweaking. The reference really comes in handy along the way too.

I've only really been messing around with it here and there for a few months, as may be evident by my own Instagram account, but I find that the main limitation is creativity. Then again, I believe Steve Jobs said that great artists steal. I also believe he was quoting Picasso, who may have been rephrasing Igor Stravinsky, which really goes to show that the whole “take credit for someone else's idea” thing can really pan out in the end. I mean just look at The Lion King, the core concept is basically Hamlet with more talking animals and less murder.

That's why my artistic process usually just involves looking at all the great art other people make and wonder “how did they do that”, and then start trying to make it from scratch. It becomes reverse engineering of sorts, which can be a fun technical challenge by itself. And sure, sometimes it doesn't pan out. Maybe the sketch ends up being a bit too much of the same because you found the original to be just right. That's why I don't post a lot of what I make, it just feels like it's lacking a certain je ne sais quoi.

Other times though, something goes wrong in the right way. Maybe you multiplied the wrong variables together, or you wondered what would happen if you set a variable to something completely different. Suddenly you've turned your inspiration into something new entirely! That's why it doesn't do to dwell on creative integrity, what matters is that you just try stuff out and see what happens along the way. After all, we don't make mistakes, we just have happy accidents.

Let It Snow with Perlin Noise in p5.js

So you have a Kubernetes-cluster and a bunch of applications. You trigger deploys by manually pushing templated yaml to your cluster. The codebase is large and the manual processes time-consuming and error-prone. You need a better way. Well, let me help you with an opinionated suggestion.

ArgoCD

ArgoCD is a continuous delivery tool for Kubernetes that uses Git repos as the source-of-truth for the desired state of the cluster (following the GitOps philosophy). It runs inside the cluster and continuously monitor the Git repos for changes, rendering them into Kubernetes manifests and applying them to the cluster. So, contrary to the common pipeline approach where changes are pushed in, ArgoCD pulls them. As shown below, it comes with a UI for visualizing resources and their relations, which is particularly handy for newcomers to Kubernetes. (The UI may also be used to administer applications, repositories etc, but then you are engaging in ClickOps rather than GitOps).

The central component is the custom resource Application which basically is a pointer to a Git repo containing code that can be rendered into Kubernetes manifests. You may specify branch/tag, path, whether it should be automatically synced, inject parameters etc. See the doc (which is excellent btw) for an example showing all the knobs.

Deployment orchestration

Applications often consist of multiple components that need to be updated during a deploy, and sometimes these components have an internal ordering that must be honored. I.e. "first do this and then do that". Tools that were not built specifically for deploys are often lacking here. Luckily, ArgoCD solves this elegantly using resource hooks and sync waves.

App-of-apps

Finally, one of the gems of ArgoCD is the pattern which is referred to as App-of-apps:

An Application may point to a Git repo that renders additional Application CRs (again pointing to other Git repo), continuing in as long a chain as necessary.

So you can effectively bootstrap your entire stack by seeding ArgoCD with a single root Application that transitively renders all your Applications and underlying resources. No clicking required. You can of course also propagate relevant parameters such as <env> to all applications as needed.

Jsonnet

When it comes to selecting a tool/language for describing the Kubernetes-manifests there will be lots of opinions. This is currently mine:

I am a developer and I like to write code. I like to find the right abstractions and create generic, reusable pieces. I have always struggled with templating languages like Jinja2 or Go-templates because they are so limited and always "get in my way". After reading Using Jsonnet does not have to be complex and Why the f**k are we templating yaml? I tried out jsonnet. I had heard it was a bit complex, but my initial skepticism was blown away after trying it. It felt much more familiar than awkward templating languages and factoring the code into reusable components was very easy (see for example bitnami/kube-libsonnet).

In jsonnet, it is quite simple to build a library allowing you to generate the full stack of Kubernetes objects (deployment, service, network policies, ingress, service monitor, etc) just by declaring the stack's config. Something similar to what you would do in a Helm values-file, but achieved with code rather than templating. Below is an example of what that might look like.

If done right, all resources can still be fully patchable. And since the jsonnet code is rendered into JSON which Kubernetes speaks natively, it will (like YAML) still allow you to do stuff like:



Validate the resources:



Dry-run against a cluster:



Diff against a cluster:

This is of course typically handled by ArgoCD, but it might still be useful as development tools.

Putting the pieces together

Using the app-of-apps pattern referred to above, it is possible to seed the ArgoCD-installation with a single Application which will transitively render all Applications for the system. It might look something like:

The root-repo will render the echoserver Application and propagate relevant tlas such as <env>. That repo will in turn render the app-specific Kubernetes-manifests. It might look something like:

New Applications are then added by pushing changes to argocd-root and deployments are triggered by pushing changes to argocd-apps.

Voilà! No more manual deploys and hopefully a tidier codebase 🎉.

Automating deploys to Kubernetes using ArgoCD and jsonnet

Typeclasses are a way to allow functions to take constraints on the type of arguments, allowing for ad hoc polymorphic functions (we say ad hoc as the function for the concrete type is provided when invoked). They were originally introduced as a way to overload arithmetic and equality operators in Haskell, but they have many other uses as well. Interfaces are a similar concept in object-oriented languages.

You can use the + function to add both integers and floats, so the type of + clearly can't be Int -> Int -> Int or Float -> Float -> Float. We can't insert arbitrary types ([3] + [4] is an error for instance, by trying to add two lists), so the type of + must be more restrictive than a -> a -> a. The type of + is actually

where Num a => denotes a typeclass constraint on the type a, requiring to be an instance of the Num typeclass.

The powerful part of defining functions on constrained types is that it is extensible, and we can implement a typeclass if we want to be able to use these functions for our custom types. Let's say we are modeling an analog clock in our program, and we have a type for time:

we can then provide an instance for the Eq typeclass (the name Eq derives from equality), which allows us to compare types using (==) for equal and (/=) for not equal:

Note that by just implementing (==), we can also use the (/=) operator for AnalogTime values. Now that AnalogTime has an instance for the Eq typeclass, we can also provide an instance for the Ord typeclass. The Ord typeclass has functions for types with an ordering, or in other words types that can be compared with for example > or <. This is because all Ord instances are required to have an Eq instance, as we can see from the definition:

The "freebies" of typeclasses

As we saw with the Eq instance we didn't have to provide all functions for the functions of the typeclass. This benefit might not seem to be significant when looking at Eq, but for other typeclasses like Foldable you get a whole load of functions already defined if you implement a sufficient part of the typeclass functions.

If we look at the info for the Ord typeclass we can see that the minimal definition is providing (<=). Just by providing a function for comparing lesser than or equal, we gain the other comparisons, as well as the max and min functions for free. Additionally, we are guaranteed that the definitions for our typeclass are coherent this way. In other words, the definitions have to internally make sense, such that we can't have that a > b && b > a for instance.

A world without custom typeclasses

In Haskell we can define custom typeclasses, and also provide instances for any custom type as a typeclass. In the Elm programming language we cannot define custom typeclasses, and you are also unable to provide instances for the existing typeclasses. There are some typeclasses in Elm, such as number, comparable and appendable, which allow for functions such as (+), (>=) and (++) to take in a variety of built-in types. If you want to write functions that can work for several different types as long as they have some function defined, the functions you need have to be an explicit part of the function's type.

The Elm definition looks similar to a Haskell definition using typeclasses:

This way you don't have the added abstraction of providing a mapping to some other type. It is easier to use the Ord typeclass still, as you have more functions out of the box such as min that can be used.

A difference between the Haskell and Elm examples is that for Haskell the correct function for comparing the elements will be sourced by the Ord instance for a (whichever type a turns out to be), but for the Elm examples you have to provide the correct instance when calling the function.

The need to know the types is easier to see if you look at the map-functions in the Elm standard library. Instead of having a single map-function for some typeclass (Functor for instance), Elm provides different mapping functions for the standard containers (such as List.map, Dict.map, Maybe.map and so on). This way you don't need typeclasses for Functors, but there is no way to map over some structure in Elm without also knowing what that structure is. This is a tighter coupling to the types used. If the underlying type changes in your model, say from a List to a Maybe, then any functions simply mapping over the elements now have to provide the appropriate mapping function.

Custom typeclasses in Elm?

In some ways you are able to do a similar thing to typeclasses in Elm by passing around records containing the necessary definitions for a typeclass:

And we can now use this to again define our list sort:

Not too far off from our Haskell listSort!

You still can't extend the built-in typeclasses and the typeclass functions aren't provided implicitly, but you can write functions using a constrained type as you know that the caller has to provide the instance for your typeclass. We also lose the guarantee of coherence for the typeclass functions. Even if you wrote a helper function that fills the rest of the instances from a minimal definition, we could still provide an Ord record where the lessThan- and greaterThan-functions are the same.

One thing that breaks with this approach is typeclasses for higher-kinded polymorphism. Trying to use a record to implement a similar set of functions as Foldable in Haskell (the typeclass of types that can be "folded over", a more general version of reduce for instance) illustrates this issue.

It is sufficient to only define foldr for a Foldable instance, similar to (<=) for Ord.

We can see from the definition of foldr that we have a type t that operates in a similar way to List (as an example) where the type isn't just List but List of a. If we try the same approach as for Ord we get a syntax error on the t a part of the function definition, as this is not supported in Elm.

If you want to try typeclasses like these in Elm there is a package with several custom typeclasses implemented, by the way of using type aliases for records.

Typeclasses in Haskell (and Elm?)

Stadig flere retter fokus mot klimaendringene, og vi som forbrukere og privatpersoner ytrer et ønske om å bli mer bærekraftige. Samtidig observerer vi et gap mellom holdninger (hva folk ønsker å gjøre), og adferd (hva vi faktisk gjør).

Mange av oss vil gjerne velge bærekraftig, men når det kommer til stykket kan det være andre behov som føles viktigere. Plutselig kan det å komme seg raskere til jobb eller anskaffe nye høyttalere til en god deal på Black Friday trumfe vårt iboende ønske om å handle bærekraftig. Kan grønn nudging benyttes som verktøy for å gi oss en dult i grønn retning?

Det er ingen hemmelighet at vi mennesker ikke tar 100 % rasjonelle valg absolutt hele tiden. Vi favoriserer blant annet gevinster i nåtid fremfor langsiktige gevinster, vi favoriserer status quo fremfor forandring, og vi favoriserer personlige gevinster fremfor gevinster for samfunnet. Alle disse vurderingsskjevhetene vil isolert sett gi lavere prioritet til bærekraftig verdiskaping, da denne i stor grad gir gevinster frem i tid, krever forandring og gir verdier på samfunnsnivå.

I tillegg har vi som mennesker begrenset mental kapasitet, og det er ubegripelig mange små beslutninger i hverdagen som konkurrerer om vår begrensede oppmerksomhet. Tid og krefter strekker ikke alltid til, og fokus er ikke alltid til stede i gjerningsøyeblikket. Veldig mange beslutninger tar vi rett og slett automatisk, uten at vi vurderer langsiktig gevinst eller samfunnsnytte. Bærekraftsforkjemperen prioriterer kanskje av sin mentale kapital for å aktivt ta bærekraftige valg. Men det er langt fra alle forbrukere som prioriterer dette der de løper i dette marsvinhjulet kalt hverdag. Og uforvarende kan en global pandemi eller økonomisk krise treffe og stjele betydelig fokus fra den gjengse forbruker. For å bistå oss forbrukere bør bedrifter derfor utvikle produkter og tjenester som gjør det sømløst og enkelt å velge bærekraftig.

Hva er "nudging" og hvordan kan det brukes?

I Bekk designer vi digitale produkter og tjenester. Felles for flere av disse er at de også påvirker det fysiske miljøet, det kan være gjennom reisevaner, sykemelding eller sparing. Akkurat som vi designer kundereiser som skal gjøre det sømløst å bestille billetter fra A til Å, søke sykemelding eller spare smart, må vi sikre at det blir sømløst å velge bærekraftige alternativer i disse produktene og tjenestene. I dette øyemed kan grønn nudging kan være et verktøy verdt å utforske.

Nudging, eller «dulting» på godt norsk, defineres som målrettede endringer i individers beslutningsarkitektur som påvirker adferd gjennom endringer i miljøet. Kort og godt handler dette om å påvirke folks adferd i en bestemt retning, gjerne ved å revurdere hvordan ulike valgmuligheter presenteres. Du fjerner ikke valgalternativer, men du endrer oppsettet. Et eksempel kan være endret oppsett av en meny på Foodora der vegetaralternativer gis økt synlighet. Eller det kan være at standardløsningen ved bestilling av take-away er uten engangsbestikk fremfor med (de fleste har bestikk i heimen).

Det er mange alternative redskap i verktøykassen nudging – det handler rett og slett om å bedre forstå psykologien bak valg. På den måten kan digitale produkter og tjenester bistå oss forbrukere der vi selv kommer litt til kort. Ulike redskap kan være å endre standardløsningen, endre oppsett av valgalternativer, eller rett og slett tilby annen type informasjon (levetid på produktet, besparelser i karbonutslipp ved å velge et alternativ fremfor et annet, osv.). Et godt eksempel her er Kolonial.no som ved bestilling av hjemlevering synliggjør hvilke leveringstidspunkt de også leverer til naboen Spar miljøet! Bestill til samme tid som en nabo. Ved å være transparente bistår de kunden i å velge miljøvennlig, samtidig som det gir økt forretningsmessig verdi gjennom besparelser i fraktkostnader.

Viktige spørsmål man kan stille seg som produktutvikler, er gjerne: Er det noen beslutningsnoder i kundereisen der kunden stilles ovenfor mer eller mindre bærekraftige alternativer? Kan du gjøre noen enkle grep for å gjøre det lettere for kunden å velge mer bærekraftig? Kanskje åpner til og med forretningsmodellen din opp for å tjene på at kundene dultes i en mer bærekraftig retning? Bra for bedriften, bra for miljøet og positivt for forbrukeren som får hjelp til å velge bærekraftig. Selv takker jeg i hvert fall gledelig ja til avlastning i det å ta bærekraftige valg. Særlig nå i julestria, når alt fra gaveinnkjøp til julebakst konkurrerer om min oppmerksomhet!

Kan vi "dultes" i en grønnere retning? 

Kotlin introduces a lot of new language features for us developers. Those features allows us to create code that is type-safe, easy to write and easy to reason about. A good example of this are the type-safe builders a.k.a DSLs, and in this article we're taking a look at how we can create our own DSLs.

First things first, lets talk about what we mean by domain specific language (DSL). In alot of ways we can think of it as a mini-language, or an API specifically designed to solve a very specific problem. Looking around the internet you'll find example of DSLs being used to instantiate complex datastructures, configuring the build-system, configuring webserver, building layouts for android app, and a whole lot more.

In this article however we're taking a crack at retrofitting a DSL to kotlinpoet. Those of you who have read "Kotlin metaprogramming with kotlinpoet " have gotten a small introduction. But to recap, kotlinpoet is Java/Kotlin API for generating .kt source files. And as we'll see it comes with a "java-ish" API, but maybe we can make it feel a bit more like kotlin-happiness. The article ended with an example of generating a simple class containing a single property and a single function.

Whichs prints;

At this point we know the output we want, and we pretty much know how to achieve it using kotlintpoet's API. The thing we need to figure out is how our custom kotlin-kotlinpoet-dsl is going to work. And this, to me, shows off one of the best features of the kotlin language; its flexibility. Prettymuch regardless of how we want our DSL to work, look and feel, it would be possible to create it. So lets start with the dream scenario;

Our idealized code does however have some major flaws. Most notably using the keywords class and as in a way that the compiler really disapproves of. Renaming class -> clazz and as -> withType, we do however reach a point at which it is actually possible to implement a working example.

We'll start by implementing the major function file, class, property and function, as these are pretty similar to each other.

These four function work in a very similar way, by the fact that they all first create a Builder, then applies the customization, and lastly either returns the built type or adds it to the parent context. Whenever we want to add the type to a parent context we need access to that context, and that is why clazz, property and function are implemented as extention functions on their respective parent context.

In order to support writing "statement" withType STRING we need need to add another function to our codebase.

This is a specialization of kotlin's predefined to function. But we add withType simply to help readability in this case.

The last thing we'll look at is the body. Since BodySpec isn't something kotlinpoet provides we'll create our own abstraction in this case;

Here we add BodySpecBuider as a stand in for the original FunSpec.Builder in order to add an easy way of defining the function body. We also borrow the concept of using String.unaryPlus from kotlinx.html. This is needed to turn the simple string statements into function call expressions.

And by now our final code looks something like this;

In this article we've used extensions functions, lambdas with receivers, and infix functions to implement our DSL. All of which are really cool features of the Kotlin language. They enables us to write expressive and readable code in a new way, and we've seen how we can use these to features to change how we interact with already predefined APIs.

Creating domain-specific languages

I often find myself coming into code bases that I haven't worked with before to fix a bug or add some new feature. This is honestly more often that not quite challenging.

Recently, santa needed my help to improve the gift generator that the North pole uses to find the perfect christmas gifts. Santa suggested that I should tweak the parameters that are sent into the generator to make it more precise.

What I always do when working with a new code base is that I read it through top-down. I start with the <App />-component that wraps the application, and navigate myself down to the component that I'm going to work with. When I finally find the relevant component, I might be met by something like this:

Sure, that doesn't look so bad. But a problem with this component is that it's quite hard to figure out what props actually contains. In my eyes props simply hides some of the most important information that determines how a component works, the input.

In this case, it's clear that props contains the input props.wishlist, props.child.name and a function props.naughtyOrNice. So what is props.wishlist? Maybe it's a list? But if that's the case, what does the list contain? Is it a list of strings or a list of objects containing more information? Also, does props.child contain any other information than name? It certaintly seems like it, since it would be weird to have an object with only one value in it...

My point is, if we know what information is available to our components, it is a lot easier to figure out what the component does and how to change it without breaking the application somehow.

So how can Typescript help?

After consulting with Santa, I converted the component to Typescript and added types to make it easier to work with. It ended up like this:

With these type definitions added to the component, it's not necessary to go on a treasure hunt to find input used by the component. In the case of SantasGiftGenerator, Typescript makes it easier to answer previously unanswered questions:

wishlist is a list of strings.

child is actually an object which contains information about age and favouriteColor in addition to name.

The function naughtyOrNice() takes the string name as input, and either returns the string Naugthy or Nice.

Even though you need to write some extra lines of code to add type definitions to your components, I'd say it's worth it a hundred times over! Well, maybe that's a bit exaggerated, but type definitions will most likely save a lot of time for the next person working with the code, and maybe even your future self.

Other neat advantages

Of course, there's a heap of other advantages that comes with typed languages.

Since Typescript gives more informations about functions and components, most popular IDEs uses this information to improve auto-completion. And to be honest, coding without auto-completion is just a pain.

The Typescript compiler also makes you a lot more confident when changing your code. When you add, remove, or change the input of a component, the compiler will output useful error messages that helps you understand how much impact such a change has.

Anyway, that's my two cents when it comes to adding static typing to Javascript, either through Typescript or with some other tool such as Flow.

Stay typed!

Maintainable React components with Typescript

Mange virksomheter satser på innovasjon for å møte trusselen fra nettgiganter som Google eller Amazon.\ Men har man noe å stille opp mot disse? Og er det ikke nesten blitt en jernlov i internettøkonomien at vinnerne tar alt?\ \ Vi tok en prat med analytiker og rådgiver Salvador Baille.

Hvorfor innovere når internettgigantene uansett vinner?

One of the great advantages of Elm is its strong runtime guarantees, and one important technique it uses to achieve this is using data types such as Maybe and Result to handle errors, instead of having values like null or undefined in the language. These structures are very nice to work with, but if you don't know the tools at your disposal, they can be tricky.

Suppose you have some data such as:

This was supposed to be a list of integers, but for whatever reason whoever provided you with this data also left in a bunch of garbage like "a87". You're only interested in the strings that are valid integers, and you also want to work with them as integers, not strings. Let's start writing our convert function.

We can convert strings to integers with the function

and we can use our old friend List.map to apply the conversion to all the elements in the list:

Now we have our integers, wrapped in Just, so all we have to do now is to remove the values that are Nothing.

"I know this one! That's List.filter, right?", you might have said prior to learning the lesson that I am getting to in this post. Let's try.

There are two problems with this solution:

First of all, isJust is not provided by the core library. We could get it from elm-community/maybe-extra, or we could save ourselves a dependency and just define it ourselves:

Now we can see if it works:

We got rid of the bad entries, but we have another problem. All our values are still wrapped up in Just! Each time you would want to use these values, you would have to handle the case of it being Nothing, even though we just made sure all the Nothing-values are gone. We have now introduced an impossible state 💀. What we really want is a function with the type

as opposed to what we had, which was:

Fortunately the solution is very simple! The core library provides the function which does exactly this:

List.filterMap takes a function that produces a Maybe, and applies that functions to all the elements of a list while unpacking the Just-values, and removing the Nothing-values.

Our final convert function can then be defined simply as:

Conclusion

Error handling in Elm is easy as long as you you have the right functions in your tool belt. With List.filterMap and a few more you will be able to handle anything 🎉

A Bunch of Nothing

So, you’ve conquered your fear of taking the stage, you’ve prepared your presentation to perfection, and things are going well. But still the audience all seem a bit careless, and it feels like your delivery is lacking that little extra. I think it’s time to introduce the real power of your voice.

Now first of all; congratulations! Taking the stage is a big win, but now we want to get even better. I totally understand you though – you’ve gone through a rollercoaster of emotions and feelings just to get to this point, and how your voice sounds isn’t really on the top of your list of concerns, right? After all, you’ve been using your voice your whole life, how much different could it sound in this context? It turns out a lot, because without even thinking about it, many people don’t use their voice the same way in public speaking as in day-to-day conversations. Now your focus is elsewhere and you’re concerned about so many other aspects of the presentation. Other times it’s almost like a defense mechanism; “If I don’t speak up, I won’t make a fool of myself”. I like to think it's the other way around.

Think about it, you’re at the lunch table at work or school, telling your friends a hilarious story about a crazy incident that happened this weekend. To really re-live and bring the story to life, you use your voice in all sorts of manners to be engaging and translate the feelings of what happened. But then you go on stage, and you talk like you’re reading the newspaper – not exactly enthusiastic. So how exactly can you use your voice to draw the audience in? Well, here are at least three core features I’d like you to think about:

Tempo

Some people talk slowly, others talk really fast. Usually, it’s the latter for most people during presentations. Non-stop. Be sure not drain the energy of your audience by going at a steady high-speed pace throughout, because that requires a lot of focus and attention of them as well, and you don’t really give them a chance to take it all in. It can also be used according to the situation; talk fast when describing a stressing or exciting situation, and slowly when depicting something taking painfully long time or when emphasizing a point.

Even taking a one or two second… pause… can help to recapture the attention of the audience.

Volume

“And then it all went boom”. Try to say this sentence first with a constant low volume, and then once where you max the volume when saying “BOOM”. See how much of a difference it makes? Important points should be spoken out louder, and aside notes lower. Also be sure to generally speak up loud enough so everyone in the room can hear you. It both shows and gives confidence.

Pitch

Imagine meeting an acquaintance at the grocery store that you don’t care much for. But to not come along as a rude idiot, I’m sure most of you start out with a “Oh, hi there!”. Now if you just say this line in a flat tone you’re not really convincing this person, but introduce a little high pitch, and you come along as much more friendly. Same in presentations; convey trivial stuff in high pitch, and more serious and authoritative stuff in low pitch.

The keyword for all three is variation.

Think that you’re reading a story book to a child, and how you actively would use you voice then. At first it will feel uncomfortable and forced, but give it a few tries, and you’ll hopefully start to make use of this without even thinking.

Or imagine attending a concert, where the vocalist either sings about love or rough break-ups, happy days or dark days. Either way, they always put their heart and soul into it, and you can almost feel what they’re feeling. It makes all the difference on how you perceive the lyrics and relate to them.

Now just to be clear, some presentations are perfectly fine with a more straight-forward use of your voice. After all, not everything needs to be that dramatic or convey feelings. But they can be useful tools to give variation to your presentations, help to really emphasize and underline your points, and engage your audience. I hope you give it a try, one small step at a time!

The power of your voice

As designers we are used to working on new domains, problems, and design challenges, and we are left with interesting reflections and insights about them. In an attempt to share some of these insights, I have written this article about the design challenges and solutions of designing for an online auction. Hopefully it can serve as inspiration or insight for other designers!

If I say “online auction”, I’m guessing that eBay is one of the first things you think of. At least that was the first site I thought of when introduced to a new project I would be designing for: an online auction for a company that leases machinery such as tractors, trucks, and wheel loaders (one of many new machines I’ve come to learn about!).

After scouring Dribbble, Pinterest, and Behance on the great search for inspiration, I soon realized that there are few insights and barely any data about online auctions and best practices, especially from a UX perspective. The online auctions I visited were often unorganized and, well, not very inspiring (hello, eBay 😬). I was left with lots of questions: how does online bidding work? What is a proxy bid? How do the users prefer to follow an auction? What type of information do they want? When do they want it?

One of the first things my team of two developers, a product owner, and myself as a UX designer did was get to know our users through interviews and surveys. It was difficult to get the user group to talk to us, and they just kept repeating “make it simple”. So, we realized that these farmers, truck drivers, and construction workers appreciate simple interfaces they can use while operating their machines, which they spend most of their days doing. They have a unique, close bond to their machines and a lot of knowledge about them, yet they are not particularly technical. What they want to be doing is using their machines, not spending lots of time online trying to place bids.

I came to understand that there are several essential elements to an online auction, and that it is absolutely critical that they work well and are simple to use, especially when the user is committing himself to bids of millions of krones. Physical auctions are fast-paced and the prices rise quickly, and this is exactly what happens during the final minutes of an online auction as well. Therefore it is imperative that the user knows how to place a bid and that the site doesn’t go down (yes, we stress-tested this multiple times 😅).

We spent many months designing and building the auction. Although we wanted to release early to get direct feedback from users, there was a lot of functionality that had to be ready before a release. I regularly tested my designs and the flow I had made on the users I could get a hold of, iterating on everything from the information architecture to the microcopy, yet we launched with a slight uncertainty of how the product would be received. After launching our product in October we have been observing and monitoring how the auction is being used, as well as communicating with actual users. This is an attempt to summarize some challenges and key learnings of how to design for an online auction, or similar platforms, such as the article I would have wanted to read many months ago.



All the information is important, so structure wisely

When working on the information architecture for an active auction, we realized that pretty much all the information on the page is equally important for the users. This includes photos, information about the machine, and auction-specific information. Our hypothesis is that if users can’t find enough information, they won’t bother bidding.

This is quite a lot of information, so we had to structure the page in an organized way, making it easy to scan while giving enough detail. We knew from a survey that photos were especially important, and placed a photo carousel at the top of the page, along with the name of the machine and the current highest bid. The user can get a quick overview of what they are looking at, and the status of the auction. We also located the input fields for placing bids at the top, considering this is what most users return to the auction to do - place a new bid.

We compressed some information to save space, such as the photo carousel and an expand/collapse box for the bidding log (which can get really long - the record is 165 bids!). By following up on emails and phone calls from users asking questions about the machines, we can keep iterating on the design and information architecture to give them what they need when they need it.



Proxy bidding is logical, yet so complicated

Proxy bidding is pretty straightforward - you enter the highest amount you are willing to buy the machine for and place the bid. The system then automatically bids for you until your maximum sum has been reached. Pretty simple, right? Well, we thought so too, but when writing the logic for proxy bidding we realized that there are plenty of edge cases. What happens when two users place the same proxy bid? What about when four users have submitted proxy bids and someone bids over all of them? We knew that about 50% of our users use proxy bidding, and if we thought it was complicated, it was definitely complicated for them.

To make it easier to understand we created separate input fields for regular bids and proxy bids. Many other online auctions only use one field for placing bids, which can be confusing for the user. By displaying the users’ maximum bid right beneath the input field they are always updated on what bid they have placed. We also added a link to an explanation of proxy bidding with concrete examples, and designed the bidding log to be scannable and transparent when it comes to different types of bids, more on that below.



Make bidding simple, and always give feedback

Our main activation goal is for a user to place a bid, so we have focused on making bidding understandable and simple. By displaying two separate input fields for bidding, the user gets a feeling of control, and we can keep them updated by displaying personalized contextual information.

We observed that the users wanted more concrete feedback on how they were doing in the auction. Therefore we added instant feedback after they have submitted a bid, telling the user that their bid is accepted and if they are in the lead or have been outbid by a proxy bid.

We decided to add a fake 2-second delay after submitting a bid before showing the feedback. This gives the user a feeling that the system is working hard to review and accept their bid. We also prioritized sending notifications to the bidders when they have been outbid, as well as when there is two hours left of the auction. This is essential to keep the bidders updated, as well as for retention. From our insights we know that some users prefer to be notified on SMS and others on email, so we give them the choice during registration.



The bidding log can get long, so make it scannable and transparent

Transparency is imperative in an auction. The users should always be able to see a complete log of the bids that have come in, down to the second they were placed. The log should be structured well and easy to scan. Also, don’t underestimate white space!

Based on user feedback we have iterated on our bidding log a few times. Users often look for their own bids in the log to see where they stand, so we chose to highlight your own bids with a background color and changed the bidder-ID to “my bid”. We also needed a way to show which bids were proxy bids. Many auctions use an asterisk (*) to visualize a proxy bid, but we discovered that it wasn’t very scannable. A text label became invisible next to a bid, and took too much space on mobiles. We tried using a robot-icon, but it was too detailed in such a small size. We are currently using a refresh icon to show the automatic part of it, but this has been mistaken as an icon to refresh the bidding log, so we are searching for an icon that represents proxy bids even better.



Nudge the user, but stay away from dark patterns

As mentioned earlier, our ultimate goal is to get the users to place a bid. E-commerce websites sometimes use nudging to get users to buy something - such as stating that there are few items left, or that 20 people have bought the item in the last hour. We decided to use elements to nudge the user, such as saying that there have been many bids in the last hour, or that there is little time left, yet being aware of staying away from dark patterns. We never lie when displaying these numbers, and we don’t trick the users into placing bids in any way. We even get them to confirm their bids before actually submitting them, and letting them know when the sum seems too high.

----

Hopefully you’ve gained some insights into the challenges and potential solutions to designing user friendly online auctions. Perhaps you’ve learned something you can bring back to your own project? I’m looking forward to continuing the online auction journey, and learning even more about wheel loaders and forklifts! 😄🚜

Designing for online auctions

What is the state of your IoT (Internet of Things)-security in your home? Do you have any gadgets on your network that are vulnerable to exploitation? Maybe you have any devices you do not recognize? If you own an IoT-device then you should be curious about how it talks to the Internet and how security is taken care of.

We've all heard the horror stories. Whether it's hacked baby monitors or talking toys, consumers and developers seem to agree on one thing; don’t trust your IoT-devices. This article tries to explain common security flaws with IoT-devices and includes a comprehensive "do-it-yourself" guide on how you can minimize the security threat.

Before we dive into the guide, what is an IoT-device and what security concerns should we be aware of?

IoT-devices in your home

The Internet of things promises us connected devices in your home talking to each other and the Internet. The connectivity enables your printer, fridge, vacuum cleaning robot or floor-heaters to be automated while you are on-the-go and not at home. Maybe even more efficient home-management. But should we put our trust into the vendor of our IoT coffe-machine that they won't leak our data, won't get hacked and has privacy and GDPR as their core focus? What priorities do these vendors have and how does that affect us?

Security concerns

Default / Weak passwords

"Box fresh" devices often have a default password. If your device has a weak or easy to guess password then it will be susceptible to guessing attacks. Default passwords are easily obtained from the Internet

Missing security updates

IoT-devices are often built on pre-existing technologies such as the Linux operating system or using HTTP services such as Apache or NGINX. Over time, flaws are discovered in all software products which should be addressed. Failure to update against known vulnerabilities in supporting software will increase the chances of a remote attacker being able to compromise the device.

Insecure web administration

Some devices offer some form of web application to provision and administer the device. These interfaces are vulnerable to the same risks as enterprise applications or Internet sites.

Use of insecure protocols

An insecure protocol includes (but is not limited to): ftp, telnet, http or SNMP. The protocol is said to be insecure if it employs no transport layer encryption or has known security weaknesses. Those listed all fall into the first category.

It is common to offer administration functions over most of the listed protocols. The impact of using insecure protocols is that an attacker on the same network would be able to conduct a man-in-the-middle (MiTM) exploitation to compromise the device.

Bad configuration

All networked services are potential avenues for an attacker to target your device. A vulnerability assessment of these networked services would uncover known flaws. Most likely your device is powered by an embedded operating system. To gain defence in depth review the operating system for configuration weaknesses such as: processes with elevated privileges, file permissions etc.

Insecure data storage

If your device can store data locally then you need to be aware of the risks of doing so. Are your controls robust enough to prevent trivial retrieval of sensitive information? Do you use some form of encryption to protect data while the device is powered off?

"Do-it-yourself" security checklist



Change default passwords:

Refer to the manual, do an online search, or contact the manufacturer for advice.



Check for firmware and system updates:

Even a brand new device could need a security update. Refer to the manual, do an online search, or contact the manufacturer for advice.



Apply updates regularly:

Manufacturers patch bugs and flaws on an ongoing basis – and so should you.Sign up for automatic updates or software update alerts when possible.



Set up a guest WiFi network for IoT-devices to connect to:

Isolate your IoT-devices from your home computers to reduce risk to important data. If you need advice, start with an online search for your WiFi router model. Many devices make it easy to set up a guest network.



Disable Universal Plug-and-Play (UPnP) functionality:

Some IoT-devices can leave your home firewall vulnerable to attack via UPnP. Unless you specifically need it for an IoT-device, turn off UPnP. An online search can help you find advice for your specific model.



Google {name of the device} + CVE:

You should see if there exists one or more Common Vulnerabilities and Exposures (CVE) for your device. If there is, see if the manufacturer of your device has patched the CVE in one of the software updates, or consider sending them an email letting them know. If the CVE is serious, you should consider turning your IoT off until there is a fix available.



Check for open ports:

Nmap-cheatsheet

First obtain the IP-address of your device. This can be done by looking for "connected devices" on your router or do a network scan with nmap.



Does your device expose any ports?



What does that port do? (google port + {port number})



Can you connect to your device through the port? For example through your web browser, ftp client, ssh?



Example of a generic scan for performing host discovery on your subnet:

nmap -sP 192.168.1.0/24

Secondly do a full service scan on your device. Grab a cup of coffee, this usually takes some time.



Example of a specific scan to find printer's open ports on your subnet:

nmap -p 515,9100 192.168.1.0/24 -oG - | grep open

16-Dec

Today's posts