With the age of continuous delivery sometimes comes the need for creating multiple short-lived test environments. There a many ways one could achieve this, but in this blog post I'll use Kubernetes external-dns. The basic idea is to create one test environment per code branch, and create what I like to call preview environments which use the git-commit SHA as part of the hostname where the app will be hosted. OK, let's get started!

I'll be hosting my preview environments on Digital Ocean's hosted Kubernetes service, so you'll need an account with them. In addition, you'll need a registered domain name; Personally I always keep a couple domain names around for demos like this one, but I'll be referring to example.com in the code below.

We'll be using some command line tools too, so make sure you install the following tools using your favourite package manager

doctl (Digitial Ocean CLI)

tfenv (A Terraform version manager)

kubectl (Kubernetes CLI)

helm v3 (Kubernetes package manager)

jsonnet (A data templating language)

Software defined infrastructure using Terraform

Let's start out by defining your infrastructure using Terraform. We'll spin up a small k8s cluster and a DNS zone.

First create a Terraform variables file in JSON format (you'll see why we use JSON instead of HCL in a few moments). It should look similar to this (make sure you replace example.com with your domain name):

Next, define the k8s cluster and create the DNS zone with DO:

Next, grab an access token from your account pages at DO, and export it to your shell:

To create this tiny infrastructure with DO, run the usual terraform apply. This will, unlike some other cloud vendors like for instance Microsoft Azure, just take a few minutes to complete.

Now, this apply actually created a DNS zone for you with DO, and you'll have to add NS records to your existing DNS provider config. Since we'll be using .preview.example.com as suffix for all our preview domain names, your can delegate only this subdomain to the DO name servers (you might also consider this a security feature, as in "blast radius" mitigation, in case you don't trust external-dns). Put config similar to the following in the root name server of your domain name:

Deploy time: external-dns!

Before we can move on running commands against our k8s cluster, we first have to get hold of our k8s credentials. Retrieve the kubeconfig by running the command output by the previous terraform apply (doctl kubernetes cluster kubeconfig save xxxxx).

Next, deploy an nginx ingress controller using helm v3:

Continue by deploying external-dns, piping jsonnet output to kubectl. We're using jsonnet here in order to keep our config nice and DRY. Notice how we're using the same variables config file as for terraform, and how we're reading env vars into the config:

To deploy the previous config to your k8s cluster, run the following command:

Deploy time: cert manager with ACME DNS01!

Next, we want to make sure to add TLS support to our preview environments. We do that by installing cert-manager in our cluster

Next, we add a couple ClusterIssuers to our cluster to make sure cert-manager is using let's encrypt as the certificate authority:

Deploy the CRDs to the cluster using the following command:

Deploy time: example app

We're approaching the finish line, and will end this tutorial by deploying an example app (dummy nginx container including Ingress, Service and Deployment). Notice the annotations on the different resources. Also notice that the mypreview domain name is set on the host fields (this is what is actually picked up by external-dns and propageted into the DO DNS Zone).

Apply config to cluster by running the following command:

Success!

If all goes well, you should now have a preview environment running at https://mypreview.preview.example.com

Final comments

Wow! What happened to the promised git SHA being part of the domain name? That is left as an exercise to the reader! How you do it is really up to you and your CI/CD workflow, but the only thing you should need to adapt is the way you deploy the actual deployment - the rest will remain more or less unchanged (Hint: replace mypreview with your git commit).

Creating preview environments using Kubernetes external-dns

Welcome to another year of the functional programming advent calendar! Every day until December 24th you will get an article, video or other functional programming related content that hopefully will make the waiting feel a bit shorter! 😄

As previous years the articles will span a large range of topics and complexity. If you are looking for something beginner friendly, or more advanced topics, there should be something for everyone these next 23 days.

Let’s start this advent of with a look at the basics: what is functional programming (FP)? This question has been answered many times before, in many different ways. We took our own stab at it last year. Even though there are no single definition for FP and many different ways to approach it, there are some things that are shared throughout the related communities.

Functional programming in 40 minutes

Today I want to use the words and pictures of Russ Olsen and highlight his talk from GOTO 2018. Russ is a great communicator and I love the down to earth and practical perspective he brings in this talk. He explains functional programming in an understandable way and shows why people prefer FP. I hope you enjoy!

Link: https://youtu.be/0if71HOyVjY

What is your favorite FP intro talk?

What is Functional Programming?

React Native is a React framework developed by Facebook to write code for mobile applications. In this article I will share some things I found interesting over the years working with this technology.

I have worked with React Native for some years now, and have encountered one or two things that got me thinking “huh, so that’s how it is”. At my current project, we are developing an application in React Native. Therefore I have chosen some things that I think are interesting (or a little bit frustrating) to present to you for this first article of react.christmas 2020.

The origin of React Native

In 2012, Mark Zuckerberg said:

The biggest mistake we made as a company was betting too much on HTML as opposed to native

This was because Facebook was eager to use HTML5 for iOS and Android. However, this was not optimal for the stability and speed. So they were interested in making applications more natively to get better user experiences. Then, a man named Jordan Walke had been working on how to generate UI components natively from JavaScript. Since it was a success, there was arranged an internal hackathon in Facebook based on this work, creating a prototype for React Native. As a result of this great work, they presented an introduction for React Native at React Conf in 2015!

Five years and still version 0.63

React Native was released five years ago, in 2015, as a stable release. Today it is widely used in production by lots of both small and big companies, like Facebook, Discord and Tesla. With over almost 10,000 pull requests, and nearly 20,000 closed issues on Github, it has still not reached a major version following the semver convention. Per December 1st 2020, React Native is on version 0.63.4.

There have been some questions about when they will start using major version numbers, and they said earlier that they may bump to version 1.0.0 when a milestone is reached, but this has yet to be done. Maybe they will do like React, which went from version 0.14 to 15.0, which is quite a leap!

<View/> and <Text/> and other components

React Native has a syntax that are pretty much equal to React, but with some differences. Instead of HTML tags such as <div> and <p>, you have <View> and <Text> components. You need to import these components for each file you are writing layout specific code. Take a look at the example below:

View is used to group your components, and structure them the way you like. In addition, React has made it mandatory to put all your strings inside a Text component. And we are not done yet! When creating an app with lots of information that goes outside the screen vertically, you need to wrap your components in a ScrollView to manage to scroll to the bottom. So a piece of advice from my experience: Always test your application with different screen sizes. I may have published an app perfect for iPhone X, where you were not able to see the bottom text for an iPhone 5...

Let’s continue! You have an out-of-the box Button component in the style of native iOS and Android, but you can always add styling to get the look you want. And if you want to create your own pressable areas, you can use TouchableOpacity which responds to touches on components you wrap it with.

I recommend having a look at the common components documentation for React Native if you want to know more!

StyleSheet.create()

Let’s talk about styles. Many of you may have a love/hate relationship with CSS. Sometimes inheritance may be a bit of a struggle, sometimes it is nice to not write the same styling all over again, time after time.

In React Native, you lose the concept of inheritance, because the styling for a component is declared in a StyleSheet object, and need to be added to each view. The stylesheet object is an abstraction of CSS stylesheet and has a little bit different syntax. In React Native you use JavaScript to to style your components. For instance, instead of kebab-case you need to use camelCase to declare your styling. In addition, everything except numbers needs to be written as a string. Look at the example below!

As mentioned in the section about the components, you need to import the Text component from React Native when adding text to your layout. I assume you want to have the same font for your whole application, not different based on what the developer has remembered to add when developing the component. So one tip regarding font styles is to create your own component, let's call it ThemedText, which uses the Text component and add the correct font here. This way you can rely on the font being correct throughout your application. Write it once, use it everywhere.

Flexing the boxes

Flexbox came and swept us off our feet after being accepted by the W3C in 2013. By being able to easily arrange your elements where you want inside a container regardless of size was a nice addition to the CSS language.

To use Flexbox in CSS, you specify display: flex;. When you do that, a set of default settings is set as you can see in the documentation. When accessing the flex property, the default value for flex-direction is row. This means that every component in the container will be placed horizontally on your screen. However, when using Flexbox in React Native, the default for flexDirection is column.

Why, you ask? Well, I would assume that for the web applications, often designed for larger screens, you have a lot more horizontal space you can use. For native applications there are somewhat limited how much you can put in a row, so defaulting to a vertical stacking order will be more useful. This is not a big deal, but I thought it was a little bit nifty!

iOS and Android

The concept of React Native is to write code once to target several platforms. Even though this works in most cases, there are still some pain points when developing for both iOS and Android. Having developed an application in React Native over the past years, I have experienced the “but it's working differently for iOS” moment when debugging the Android app, countless times.

For instance, when making your application accessible, not everything is equal for both iOS and Android. React Native has added support for different accessibility use cases, but not every one of them is supported for both platforms. There was one case, where I wanted the application to read the changes on the screen for the user, even though the user is not focusing on that given component. For instance when the time of departure for a bus changes, it is crucial to notify the user. This resulted in adding two ways to get the voiceover feature to read the changes. One way to notify the iPhone users, another to help the Android users.

Fortunately, React Native gives you the possibility to select which code you want to apply for iOS or Android by using Platform. By using it you can apply the part of code you want to execute for the given platform. Look at the Hello World example below!

It is also nice to use to apply the correct styling for your code. For example, at the bottom of the screen on an iPhone X where the home button used to be, there is this swipe indicator you can use to close your app. When placing buttons at the bottom of your page, it will be good on Android but will overlap with the swipe indicator. This results in the need for adding different margins for the different platforms, look at the example:

Not used in the Messenger app

As mentioned in the introduction, React Native is developed by Facebook. Earlier this year, Facebook announced that they would release the Messenger app, written as native iOS and Android apps. Further on, AirBnb and Udacity said in 2018 they will no longer be developing their applications in React Native. The main reasons for this decision was more or less the immaturity of React Native.

There are several pros and cons with React Native. The easy setup and React-like syntax really gives it an advantage. But the differences between platforms (i.e. as I mentioned over with the accessibility) and the lack of some native components (i.e. push-notification and FaceId), it has a way to evolve. It will be interesting to follow this technology in the years to come!

That was it!

This was a little list of the most interesting things in React Native I have experienced over the years.

Hope you liked it!

Seven Interesting Things About React Native

We often admire the people who are great speakers. It seems to be little effort to them, but so difficult when we, the mere mortals, try the same thing. Yet, there are many good reasons for why you should help others learn. Let's have a look!

1. It helps you better understand the topic

To me, this has been a real eye-opener! By teaching others, you actually learn a lot yourself. Thinking about how you should deliver your message to the audience, demands a good understanding of the problem. By connecting these dots before you help others, you will gain a much better understanding.

2. You are helping someone

Even though experienced speakers seem to rock, it might not be enough for everyone to understand a topic. But you, oh you, with your personal experiences on the subject and different way of presenting, might hit just the right (learning) spot for someone in the audience. When you recognize an understanding between you and a listener in the audience, it feels like you are receiving a gift.

3. Becoming a better listener

By gaining experience through holding talks to others, you become much more aware when you are listening to others. Even the boring parts become interesting, as you now become interested in how it can be perceived boring, and how you can make the boring parts interesting. Interesting.

4. You will always need talk-like skills

You will always need talk-like skills to cope with everyday situations, such as shorter presentations at work, in a meeting or even when trying to make a compelling argument to your neighbour. It will also come in handy when holding a wedding speech, delivering a memorial speech at a funeral, or perhaps in your children’s confirmation. Why not start practicing the skill right away?

About this calendar

A warm welcome to this brand new talks.christmas-calendar! Throughout December, this calendar will give an introduction to several aspects of talks:

How to cope with stage fright

Tips & Tricks when holding presentations

Our analysis of different people holding talks

How to create a great slide deck

Rhetoric and persuasion

How to improvise

Why spend time teaching others?

We are really excited to present this year's calendar, and hope that you will enjoy reading it as much as we enjoyed writing it. Security as a topic is hotter than ever. While we count down the days until Christmas Eve you will be given new, original security content each day. Enjoy the countdown together with us!

We start by presenting a list of a few tips you as a developer can use to help your applications stay as secure as possible. This is not new, ground-breaking stuff, and hopefully you are familiar with much of it already. But, we hope that it can serve as a reminder for you, and that you can spend some time checking it out in the light of your own projects!

1. Get to know the current OWASP Top 10

OWASP Top 10 is a list of the most critical security risks for web applications. The last OWASP Top 10 came out in 2017, and OWASP is currently working on a 2020 edition. We encourage you to check out the OWASP Top 10 project website at https://owasp.org/www-project-top-ten/, and take a look at your own projects and see how these risks are being addressed.

2. Be creative

The one that knows most about how your application is supposed to be used is you, the developer. An attacker will have a different mindset. He or she will try to use your app in illogical ways, and in ways you might not have thought about. While you develop and test your applications, try to be a bit creative. Send unexpected input, navigate in illogical ways, and try to provoke errors. Chances are that you will discover a vulnerability or two.

Trying to hack your own applications is a fun exercise. A handy tool is the OWASP Zed Attack Proxy (ZAP), which is a free, open source tool. Check out https://zaproxy.org. You can also check out our post about Zap from last year, at https://security.christmas/2019/9

3. Automated dependency checking

We tend to have lots of dependencies in our applications. These dependencies can of course contain vulnerabilities, which thankfully might be discovered and patched in newer versions. However, if we don't continuously bump to the newest versions we get no advantage of those patches, and our applications are still as vulnerable as before.

If we let bumping dependencies be a manual task, it is easy to postpone it. A good idea is to let an automated tool continuously monitor your dependencies, and either warn you or try to fix it, if there is something wrong. There are several tools available, e.g. Github Security, Snyk and OWASP Dependency-check. Without revealing too much, there is a chance we will give you a more thorough introduction to one of these tools in the coming days.

If you have an automated tool in place, there is important to also have a regime to monitor and take action when the dependency checker tries to tell you something. You should also keep an eye on dead dependencies - dependencies that no longer are being patched. They most likely contain vulnerabilities, and you should look for something else to pull in instead.

4. Know your HTTP-headers

The HTTP-protocol comes with a set of headers that can help mitigate attacks and security vulnerabilities. Used correctly, they can enhance the security considerably. The following five headers are interesting to check out.



Content-Security-Policy

Protects you from XSS attacks. It prevents the browser from loading content from other sources than the ones you have specified.



Strict-Transport-Security

Enforces the browser to use TLS, e.g. ensures that the communication takes place over a secure transport channel like HTTPS.



X-Content-Type-Options

Stops the browser from trying to sniff the content type from MIME, and forces it to deal with the declared content-type only. nosniff is the only useful value here.



X-Frame-Options

Tells the browser whether you allow your site to be framed or not. By setting it to SAMEORIGIN, it will be allowed to frame your site at the same origin only.



Referrer-Policy

Controls how much information the browser includes when navigating from one document to another. By setting it to no-referrer, the browser will never send the referrer-header with requests that are made from your site. The Referrer-Policy can also be set in the Content-Security-Policy.

You can check the HTTP-headers on your own site at https://securityheaders.io , a project by Scott Helme. It will generate a report based on the findings on your site, and give you recommendations and guidelines on how to fix any problems.

5. Create a security.txt

If somebody finds a security vulnerability in your application, you probably would like to know about it so you can fix it. To make that happen, it is crucial that you let people know how to contact you. There are many examples that communication between someone finding a vulnerability and the organization or person behind the vulnerable site or app, can be cumbersome.

To make things easier, there is a proposed standard, security.txt, for how to easily get in touch about security issues. It is currently a RFC-draft submitted for review at IETF. The proposal is to put a file named security.txt under the path /.well-known/security.txt. It should at least contain information about how to get in touch, but comes with some other fields as well. You can read more at the project website https://securitytxt.org, and the RFC-draft at https://tools.ietf.org/html/draft-foudil-securitytxt-10.

Even though the RFC is still a draft, it has been adopted widely by major websites like Facebook, Dropbox and Github. So, you should do it too, and create a security.txt if you don't already have one. It builds trust and sends a signal that you take security seriously.

How to create more secure applications is of course not limited to this short list, and we have more to come. Stay tuned! Also remember to visit our other calendars.

Welcome to the Security Christmas Calendar!

Jingle bells, jingle bells, jingle all the way…

Den alarmerende lyden av bjelleklang varsler at nå er sesongen her på ny. Sesongen for å ta del i Norges mest utbredte ekstremsport. Julegaveshopping. Du tenkte nok i fjor som årene før at «neste år skal jeg starte tidligere slik at jeg slipper alt dette styret hvert evinnelige år». Likevel ville du nok til vanlig stått på et av Norges 243 (!) kjøpesentre med armene fulle av handleposer mens du kjenner svetten sildrende nedover nakke og rygg av altfor mye klær til å være inneklemt mellom haugevis av folk på trange butikker med termostaten skrudd til topps. I år sitter du kanskje heller foran pc-skjermen og scroller hvileløst rundt på nettbutikkene. Uansett kjenner du nok det velkjente stresset. Stresset av å prøve å oppfylle alle forventningene. Det er vanskelig å både imponere og vise hvor mye du bryr deg, enten det er en gave til Ola på 3, Sara på 40, Nils på 82 eller den vanskeligste av de alle, en gave til din bedre halvdel.

Det er i slike stressende stunder det er fristende å drømme seg bort til en situasjon der man bare kunne tatt opp mobilen og sendt en vipps-overføring, gjerne fulgt av noen hyggelige ord, til alle de som står på gavelista.

Det å skulle gi penger eller gavekort i stedet for gaver, er jo egentlig veldig rasjonelt. Når du gir en gave så risikerer du, selv om du håper at det skal være akkurat det personen har ønsket seg, at gaven ikke treffer. Dersom du derimot gir penger så kan vedkommende kjøpe seg det samme, dersom det er det som gir høyest nytte, eller kjøpe seg noe som personen vil sette enda mer pris på. Du sikrer derfor at mottaker av gaven oppnår minst like høy nytte med å gi penger og fjerner nedsiderisikoen. Dersom vi er slik økonomer flest antar at vi er, rasjonelt tenkende mennesker, så vil penger altså være en bedre gave å motta og ikke minst gjøre livet utrolig mye enklere for alle som skal gi gaver!

Dette må da noen ha tenkt på?

Jeg er ikke den første til å tenke i disse baner. Francesca Gino (Harvard) og Francis J. Flynn (Stanford) har forsket på hvilke gaver som foretrekkes. I en av studiene sine finner de at deltakerne i studien setter mer pris på å motta penger enn en gave, fra en ønskeliste de selv har satt opp, til tilsvarende verdi. Dette skulle vel bevise at vi fra nå av bare kan dra frem det digitale sjekkheftet ved alle festlige anledninger? Vel, det kommer an på. Dan Ariely, professor ved Duke University, peker på at selv om vi tror vi foretrekker penger så vil en slik gave oppfattes ulikt avhengig av hvilken relasjon det er mellom giver og mottaker. I studien til Gino & Flynn har ikke giver og mottaker noen eksisterende relasjon før studien. Det har derimot jeg og alle på min gaveliste.

Arielys tankegang er lettere å skjønne om vi ser på et eksempel. Tenk deg at du er på julemiddag hos svigers. Når maten er spist opp, reiser du deg og spør svigermor hvor mye du skal betale. «Vil 250 per pers dekke måltidet?». Jeg tror ikke jeg er alene om å grøsse av tanken på stillheten som ville etterfulgt et slikt spørsmål på julaften. Hadde jeg derimot tatt med en fin blomsteroppsats eller en flaske med godt innhold som en gave til vertskapet hadde nok reaksjonen vært en ganske annen.

I boken Predictably Irrational forklarer Dan Ariely at grunnen til at en slik situasjon kan oppstå, på tross av at vi i andre situasjoner foretrekker penger fremfor gaver fra en ønskeliste, er at vi her endrer en sosial relasjon til en markeds- eller transaksjonsrelasjon. Det sosiale forholdet som er preget av høflighet og gavmildhet blir plutselig endret til et markedsbasert forhold der enhver tjeneste og ytelse har en pris.

Gjelder dette for bedrifter også?

Tilsvarende dynamikk kan vi finne igjen hos bedrifter når det skjer endringer mellom sosiale og transaksjonsrelasjoner. For stadig flere bedrifter er det viktig å ha en personlig relasjon til de ansatte. Gjennom sosiale aktiviteter og ekte omtanke for hver enkelt ansatt skaper man økt lojalitet og bedre ytelse. I et arbeidsforhold der du opplever at selskapet genuint bryr seg om deg som menneske, så er det mer ok for deg om du av og til må lese en mail mens du ser på dagsrevyen. Men hva skjer om selskapet innfører en streng loggføring av når du starter og slutter på jobb for dagen? Ergrelsen over da å gjøre mer arbeid utenfor den offisielle arbeidsdagen, uten å føre eksakt antall timer for jobben, øker nok betraktelig. Ariely ville her argumentert for at bedriften har endret den sosiale relasjonen mellom arbeidstaker og bedrift til en markedsbasert relasjon. Kanskje noe å tenke over når man vurderer å gi de ansatte en fin gave eller en tusenlapp ekstra på lønnsslippen i desember? Hva ville gjort deg mest takknemlig og mest motivert?

Dette er også overførbart til hvordan selskaper behandler kunder. Stadig flere ønsker å ha en personlig relasjon til kundene sine og slik skape en dyp kundelojalitet. Et godt eksempel er lokalbanken, som skal være den trygge og nære banken som bryr seg om deg. Vel og bra, men da må man evne å vise lojalitet andre veien også. Dersom den vennlige lokalbanken setter betalingsfrister på 5 dager og sender purregebyr før du rekker å si «grevinnen og hovmesteren» faller nok følelsen av en god relasjon bort for kunden. Relasjonen kan til og med bli betydelig dårligere enn om banken i utgangspunktet hadde holdt kundeforholdet som et rent markedsbasert forhold.

Så, hva skal vi gjøre?

Økt bevissthet rundt hvordan endringer i relasjoner kan skje viser seg altså å være viktig for oss enten vi sitter i bedrifter eller stresser med julegavehandlingen. Før vi begynner å bytte ut alle gaver med kontanter er det derfor kanskje lurt å tenke over hvilken relasjon vi har til de rundt oss og om vi er villige til å ta sjansen på å endre den relasjonen til en markedsbasert relasjon.

Men, frykt ikke. Jeg har et lite tips til hvordan du kan, om ikke å redusere stresset i førjulstiden, klare å imponere mer med gavene dine. Forskning har nemlig vist at innpakning kan påvirke hvordan en gave oppfattes. For nære venner oppfattes en gave som mer verdifull dersom den har en kjip innpakning, mens en flott innpakning vil øke oppfattelsen av gaven for perifere bekjente.

Når det kommer til julegaver, er nok julenissens strategi den beste. Lykke til med innkjøpene! Vi sees nok på gullsmeden 23. desember neste år også …

Hvorfor gir ikke julenissen kontanter?

Welcome to this year's UX advent calendar! Last year was the premier for ux.christmas and this year we are doing it again. 24 days, 24 articles. Windows of inspiration, facts, a little insight into our world, and other things that we have worked with during this strange year of 2020. Herman is going to tell you a little about Figma. Citona and Sigurd share 5 things they wish they knew about working as a UX designer before they started, and Espen is writing about inspiration.

Some articles are written in English, others Norwegian. They are just short enough (2-3 minute read) to squeeze in while you wait for the gløgg* to be ready to drink at your home office. If you are hungry for more articles to devour we have lots to offer because the UX-calendar is not alone. This year, we have made 11 advent calendars(!), each with its own daily dose of original content made by people in Bekk. Head over to bekk.christmas to get an overview of it all!



Advent calendar and design?

There is something about advent calendars that makes me happy. So many memories from my childhood when I and my brothers shared an advent calendar our mother made for us. One day at a time counting down to the big day, Christmas Eve with Santa Claus and presents!

And that is exactly what an advent calendar is, it’s a kind of countdown that makes the long wait tolerable for an expectant child just as I was at that time.

In our world of design, we do a lot of manipulation to get different experiences of time. In a workshop, we can use a countdown to make people stressed so they are focusing on getting as many ideas as possible instead of letting critical thoughts stop the creative flow. If an application is loading slowly we’ll make a progress bar so the user can feel reassured and relaxed that everything is working though it takes time. All of this has to do with the experience of time. As a designer, you can’t change time itself, but you can change the experience of it.



Three elements for a designer to consider working with time

From Chris Kiess’s articles about The UX of Waiting and the Perception of Time* I found that you have three different elements you can manipulate if you are working with time. Actual measured speed, the perception of speed, and the tolerance of speed.

Actual measured speed might be the most obvious. If there is something that takes a long time to load you could always ask the developers really nicely if they can make the code more efficient and make the actual measured speed faster. This might be easy to do and a good solution, but sometimes it’s difficult, time-consuming, or impossible for the developers. Then you have to consider the other solutions.

The next element is the user's perception of speed. To change the perception of speed you have to work with the context around so the user perceives the time to go faster.\ As they say, time flies when you're having fun. If you are waiting for the gløgg to boil and you just stand there watching it, it feels really slow. But if you turn on the TV and start watching an episode of The Julekalender* the gløgg will boil before you can say “Olaaaaf”. The change of context has changed their perception of the 5 minutes from feeling like forever to something blazing fast. There are several ways we as designers can do this. For instance, we can disguise the wait with other tasks the user has to do. Maybe there is important information that the user has to read. Why not prompt the user to read it while waiting for something? Or you could give them an awesome animation, fun facts, or a riddle to focus on instead of waiting.

The last element is the user's tolerance of speed. When you don’t want to disguise the time the way you do by changing the perception of time, you have to increase the user’s tolerance of time. The most common example might be the progress bar. Giving the user a visual estimate of the time assures the user that even though it’s taking time, it's working and it will happen soon. You also have the electronic boards counting down minutes until the next bus arrives. They have to wait, and we don’t want to disguise the duration, but show it to calm and reassure the users that everything is under control.

As a designer, you can play around with these elements and combine them to make a good user experience of time.



So what about advent calendars?

First I thought it was only a perception of time thing, kind of “why not have a bit of fun while we are waiting?”. But remembering my childhood, considering that the target group for an advent calendar often is children, I also think it has a lot to do with tolerance. Children don’t have the same understanding of time as we grownups have. They are reallllly looking forward to Christmas Eve. A calendar might be a way to increase the children's tolerance to be able to wait for 24 days. We don't want to trick them by disguising it with something else, but to help them visualize the 24 days that probably would have felt like a million days of waiting without a calendar!

So that's my little UX perspective on advent calendars. I hope this year's calendars from Bekk can help you to withstand the long wait until Christmas Eve.







*Gløgg is a sort of mulled wine, non-alcoholic sort for the home office of course.

*The Julekalender is a Norwegian TV show advent calendar where one of the characters is famous for saying “Olaaaf”. The show aired in 1994.

*Chris Kiess’s articles about The UX of Waiting and the Perception of Time. I would recommend everybody to read it at his blog: https://chriskiess.medium.com/the-ux-of-waiting-and-the-perception-of-time-eab52c459ce3

A UX calendar to ease the wait for Christmas Eve! 

Welcome to the Elm christmas calendar, and to the first of 24 articles that will teach you some tricks and useful concepts you might not already know. Today we are discussing Tuples. It is perhaps Elm's simplest way of structuring data. We also introduce a concept recurring across several days; pattern matching, or destructuring. The first use-case is pattern matching of tuples in function declarations.

Tuples allow us to join values together into a single value. Elm, as of version 0.19, allows tuples of no more than 3 values. A function can receive a tuple as an argument or it can return one. The latter enables returning more than one value from a function. This requires more work in languages without tuples.

Here are som tuples:

The core module Tuple has helper functions for working with 2-tuples. E.g. Tuple.first and Tuple.second extract the respective values.

The pattern of types of its values make up the tuple's type as a whole. Hence, a tuple of String and Int cannot serve as a tuple of Int and String.

Pattern matching tuples

In a function that takes a tuple, there are two main ways of "receiving" the argument. Receiving the tuple as a single value is the straightforward approach.

Pattern matching the received tuple debloats the code considerably.

Pattern matching still works if you introduce a type alias for your tuple.

A look at core/Tuple

After establishing a basic understanding of a concept, I find it rewarding to look at API source code related to that concept. We saw how we could use Tuple.first to extract the first value from a tuple. Here is its source code.

Reading these type signatures can feel daunting at first. But let's apply what we know about tuples and how first works. Regarding the type annotation, (a, b) merely states that first takes a tuple of two values that might not be the same type. The return type is a, referring to the type of the first element of the incoming tuple. The type declaration is telling us: "I take a tuple of two values and return whatever type the tuple's first value had".

In line 2, we see that first makes use of pattern matching, albeit with a twist. first only needs the first value. The second value need not be named, but must be matched using the placeholder _.

Conclusion / TLDR

Elm has built-in syntax for creating tuples to structure data. When receiving a tuple as a parameter a similar syntax can be used to extract the tuple's values into separate variables. Heeding the notes in core/Tuple is advisable. When you need a little complexity in your data structure, tuples are rarely the right choice.

Once, twice, three times a value

JavaScript:Do you know addition?

Me:Of course! I learned mathematics when I was seven, addition is fairly easy!

JavaScript:Do you really know addition? Please solve this equation

Me:Eh?

JavaScript:Welcome to JavaScript addition!

If you have been working with JavaScript, you have probably seen a lot of usage with the + operator and discovered that the output is not necessarily what you expected.

The language supports using the + operator between (almost) all of the different data types - the results might therefore be confusing. In JavaScript, there is no compiler to hold your hand on your “addition journey”.

The addition operator either performs string concatenation or numeric addition.

With the rule above you should be able to understand all additions in JavaScript, but some of us need to see examples and explanations to fully understand the different scenarios.

First of all, remember that JavaScript performs the addition from left to right - evaluating parentheses first. This should be familiar with what you have learned in middle-grade mathematics.

As the rule states - with two numeric elements, the output is a numeric value:

1 + 1 = 2

String concatenation is well known between different programming languages and is a reasonable usage of the + operator:

"Santa" + " " + "Claus" = "Santa Claus"

So far, so good!

The most important “rules” with addition in JavaScript

Adding a non-numeric value to a numeric value will try to convert the non-numeric value to a numeric value, if possible. If not, both are converted to strings.

Adding a non-numeric value to some value will convert both values to strings before adding them.

So, what does that actually mean?

Confused? At least I am…

In the first line, a numeric and non-numeric value is added. Both are converted to strings before they are added

"1" + "2" = "12"

In the second line, there are both numeric addition and string concatenation. Remember, addition goes from left to right.

The third line only contains string concatenation.

"1" + "1" + "2" => "112"

Unfortunately, it doesn’t end here. Some other data types in JavaScript behave in a rather non-typical way when used for addition.

Boolean

What happens when you add something with a boolean value?

Boolean values can be converted to numeric values in JavaScript, and the result of the conversion is either 1 or 0.

Combining a boolean and a string value converts true to “true” and false to “false”.

Objects, arrays and functions

When one of the values in an addition is an object, array or function it will try to convert it to a primitive value. 1) Execute the valueOf()-function and use that value if it is a primitive 2) Execute the toString()-function

The default valueOf()-implementation is an empty object {} - which is not a primitive and it will try to convert it using toString(). The default toString()-value for an object is "[object Object]" - not very useful for addition. Unfortunately, I have seen this output many times during my time as a developer - it usually happens when I forget to specify the property of the object that should be part of the addition.

Sometimes, it might be handy to override the valueOf() or toString()-function and make it return something useful.

The return type is now a numeric value and it will add 34 with 1 - which is 35.

The same can be done for a function or a class - for both valueOf and toString.

For arrays, valueOf returns the array - which is not a primitive value. The output of its toString() is the content joined with a comma. An empty array is the same as an empty string.

Since you have been reading all along - here is a quiz for you:

PS: try to solve it before you check the browser console

Date

All rules have some exceptions...

All native ECMAScript objects except Date objects handle the absence of a hint as if the hint Number were given; Date objects handle the absence of a hint as if the hint String were given.

Date.valueOf returns a numeric type, but a date will be transformed into a string type when using the + operator.

Weirdos

Now that you know the important rules of addition, there are some data types you also should be aware of:

As you have read, addition is not as easy as we know from mathematics. However, if you remember some of the conversion rules above you might save yourself from some headaches in the future!

Javascript Addition

Alle snakker om innovasjon, men hva er det egentlig? Finnes det noen gode definisjoner som dekker et så sammensatt område?

Vi har stilt spørsmålet til mange flinke folk som har ulike tilnærminger og prøver oss på en oppsummering. Med Moquan Chen, Pia Solheim, Jens Andreas Huseby - og mange flinke folk.

Julekalenderen 2020 om innovasjon kan du følge på podcasten Drypp fra Bekk.

Hva er innovasjon?

Welcome to the second year of the Bekk’s Kotlin advent calendar. If you followed us last year welcome back, and if you’re new this year you’re in for a treat. Each day leading up to Christmas Eve there will be a new post about Kotlin features, tooling, the Kotlin ecosystem and more!

This year sure has been different than most of us would have predicted back in 2019. 2020 has been a year filled with uncertainty and chaos, our lives have changed a lot and the new norm has become staying indoors and keeping social interaction to a minimum. Some things don't change though, so for today's post let's take a closer look at: Immutability.

Never Change

Kotlin has an easy way for us to differentiate the intent of a variable being changeable or not with the respective keywords var and val. For variables that we want to change we use var and for the ones we don’t we use val.

By denoting the variable with val we have an immutable variable. Awesome, right? If it had been that simple, there are always exceptions to the rule.

Consider the following example:

Even though deliveryCrew is defined as a val we can still change the data if the assigned object is mutable. It's important to know that val only makes the object reference immutable, not the data itself.

Another crazy thing you can do to get around the immutability of using val, I'm not sure why you would do this, is to override the getter of the val to make it return something random.

Even though the val-keyword doesn't ensure immutability in Kotlin, using it we’ll come a long way to make sure our data is immutable and not an ever changing chaos.

Immutability is generally a really good idea. It makes your code easy to follow and you're sure that the data you're working on isn't being changed by passing it to some function.

Nothing is a silver bullet though. So what are the drawbacks of immutability? One of the drawbacks can be a loss of performance, though in almost all day to day cases that cost is worth it. Check out Romans great post about the cost of immutability in kotlin: Immutability we can afford.

Data classes in Kotlin come with a copy function to make a copy of an object with some changes to it, like changing the age of a user: user.copy(age = user.age + 1). This works great for simple objects. But what about trying to change deeply nested data structures? This can lead to some ugly code for sure. My first thought when encountering this is "can I change this to be less nested and less messy?", usually the answer is yes, but if the answer to that question is no, then a concept from functional programming called Optics might be of help.

To sum it up: Immutability is generally a good idea and immutable data makes your code a lot easier to reason about. Kotlin might not be as immutable as you think, and even though using val doesn't guarantee immutability it goes a very long way of making the intention of your code clear and your data unchangeable. Immutability, never change!

The Advent Spirit

Want more Kotlin? Check out our last year's Kotlin advent calendar or have fun solving the daily programming puzzles over at Advent of Code. I'm for sure going to solve some of them!

1-Dec

Today's posts