Today's tip is a nice, useful satirical Open Source repository for when you need to fake it to make it.

Volkswagen detects when your tests are being run in a CI server, and makes them pass.

Remember when Volkswagen were tampering with their emissons tests? Now there's a great way to emulate this for your software tests! Fake tests passing on all sorts of build servers 😄 It suuports TeamCity, Travis CI, GitLab CI and lots more!

Visit the repository on GitHub to learn more and have a good laugh 😄

volkswagen - for when you just need to pass your tests

This will be a short post on how to visualize bike rental data in Clojure. Let's get to it!

Starting coding

I'll assume you know how to install programs on your computer. You will need Clojure (brew install clojure on a Mac), and Leiningen, our package managing system (brew install leiningen). You will also have to have Java installed on your system.

To get something running, write lein new app city-bikes in your terminal. This will create a folder named city-bikes with a template project. To test that everything works correctly, cd into your folder and type lein run. Hopefully, you'll see Hello, World! printed out.

Now we're ready to start coding!

Reading data

First of all, we need some data to work with. We'll use open data provided by Oslo Citybikes. Download one of the JSON files containing bike rental data and put it in the root folder. Rename it to city-bikes.json.

We'll use Quil to visualize the data. It is a wrapper of Processing written for Clojure. To use Quil, we must add it as a dependency in our project. We will also need to process some JSON, so we'll add a dependency to the org.clojure/data.json library. To do that, update the project.clj file to look like this:

To download the dependencies, run lein deps in your terminal. To be able to use the dependencies, we must import them. Update the namespace declaration:

Let us take a look at the data: first of all we'll take a look at how the data looks. Using for example jq:

For this visualization, we're only interested in the start- and end-points and the duration of each bicycle trip.

We'll write a small Clojure function that takes a Clojure map and returns only the interesting keys (to avoid clutter when debugging, for example):

Now we can read the data into a Clojure variable:

Notice how we chain the computation: we start with an input, the name of the file we're interested in, and then we pass it to one function after another: first slurp the file (reading it as a string), and then parse it as a JSON. The result is a long list, over which we map the keep-interesting function.

To test how this works, try adding the following in your core.clj function:

After running lein deps && lein run, you should see the data of the first bicycle trip printed.

Visualize something

Now to the fun part! First we must setup Quil. Quil need a setup function, and a draw function. Add the following functions to core.clj:

and

and

Save, and run lein run. If everything works, you should see a big circle in the middle of the picture.

But we really want to plot bike rental data. We'll keep it simple and draw lines from the start position of the trip to the end position. We are given latitude and longitude, but want to draw them on a screen. A really simple way to do this, is to think of latitude and longitude as x- and y-coordinates. This works for small maps, because the Earth is approximately flat:

The above code snippet first finds the maximum and minimum latitudes and longitudes of all the trips, and then we normalize it to lie inside the canvas. We now have all we need top draw the trips. Update your draw function as so:

If you now run lein run, and everything is correct, you'll see a nice black and white visualization of all the trips. This is where it was nice that we wrote (q/stroke 100. 10) in the setup function: all lines drawn have very low opacity, so we can draw the same trip several times to increase intensity.

Finally, we'll add some color. We'll color the trips based on its duration. The following code maps all the durations and maps them to the interval 0-10.

Update your drawing function:

Notice how now each line has a different stroke depending on the duration.

Running, you should see something like this:

If you don't want to type all the code yourself, you can check out this Github repository, where I've uploaded the code. Clone it, and run lein run!

Visualize bike rental data in Clojure

You've probably seen someone on the internet write funny-looking but runnable JavaScript code using only six different characters. But how does that actually work?

You can write basically any JavaScript program on the planet using just these characters:

This is a well-known trick, but not that many developers know how it actually works. Today, we're gonna look at how it works under the hood. Let's create the string "self" using only our funny little subset of characters.

Our target string will be "self", as an homage to the programming language Self for being one of the inspirations for JavaScript.

How It Works: The Basics

What allows us to make all other characters superfluous is the fact that we can abuse JavaScript's type system and bizarre type conversion mechanisms.

We'll be using our six superhero characters this way: with [] we can create arrays, with the negation and addition operators ! and + we can do operations on them and finally use () to group operations.

Let's start off with a simple array:

Negating an array with ! will coerce the array into a boolean. Arrays are considered to be truthy. Therefore, negating it will produce false:

Values of different types cannot be added together unless converted to similar types. JavaScript follows a pre-defined ruleset when doing conversions:

In the expression 2 + true, JavaScript will convert true to a number, resulting in the expression 2 + 1.

In the expression 2 + "2", JavaScript will convert the number of a string, resulting in 2 + "2" === "22".

These conversion rules aren't that bad, but it gets quite interesting quite quickly with other types.

JavaScript Array Coercions

Adding arrays together will convert them both to strings and concatenate them. Empty arrays turns into empty strings, so adding two arrays together yields the empty string.

The same will happen when adding an array with something else, lets say, a boolean.

Aha! Now we're conjured a string containing the characters we need to produce our end goal, the string "self".

If we could produce some numbers, we could extract the characters we need in the right sequence:

Let's go looking for numbers!

Creating Numbers

In the previous section, we coerced an array to a boolean. What happens if we coerce it to a number using +?

JavaScript will attempt to call valueOf on the array, which will fail and fall back to calling toString() on the array.

Converting a string to a number will produce the following results:

The empty string is a falsy value, like null, undefined and the number zero, so converting any of these to a number produces zero:

So converting an array to a number takes a detour converting to string first, finally producing zero:

Aha! We've managed to produce a number! Although, not a very useful one. However, we can keep playing the coercion game:

Negating zero will make the falsy value of zero into a truthy boolean. A truthy boolean as a number becomes... one!

Hooray! One one can become two ones... which is two. You get the point.

Using the substitutions we've learned to create numbers:

Putting It All Together

Let's put together all the things we've learned.

Arrays are truthful values, so negating them will produce false: ![] // false

JavaScript coercing rules state that adding arrays together will toString them: [] + [] // ""

Converting an array to a number becomes zero, when negated becomes true, when coerced to number becomes 1: +(!(+[])) === 1

Our final expression thus becomes:

Adapting our expression to this specific JavaScript dialect, where newlines and whitespaces are, of course, banned:

Easy as pie!

Thank you, Brendan Eich ❤️

Writing JavaScript With Only Six Characters



Tegnetusjer i ørten pastellfarger. Fancy penner. iPhone. Post-its i diverse størrelser; noen større enn en PC-skjermen, andre mindre enn et viskelær. En bok om “Real life Continuous Digital Design Thinking In Agile Organisations Service Blueprint Flow”. Macbook med “Wine&Design”-sticker. Kaffekopp, chiapudding og mandelmelk fra Kaffebrenneriet. Slik ville jeg, en utvikler, beskrevet en designers pult på 30 sekund.




En designer er en person som gir meg tegninger i fine farger for hvordan en nettside eller app skal se ut. Elsker det abstrakte, lever i en drømmeverden uten konsept over hva som er teknisk gjennomførbart.



- Henrik, jobbet som utvikler i 1 dag




Nå har jeg jobbet som utvikler i 3,5 år i et ganske stort og tverrfaglig team. I løpet av denne tiden har jeg samarbeidet med både grafiske designere, interaksjonsdesignere og tjenestedesignere, alle med hver sine styrker og syn på hvordan det vi lager skal fungere. Er det en ting jeg har funnet ut, så er det at min overfladiske beskrivelse av en designer er et stykke unna sannheten.

I min verden fantes det kun 1 type designere, og det var de som tegnet en skisse over noe som jeg i ettertid skulle programmere. Realiteten er at en slik skisse er et mulig resultat etter grundig innsiktsarbeid. Mesteparten av det jeg har programmert har ikke blitt bygget ut i fra en skisse, men heller en kontinuerlig dialog med designerne om brukerens behov og hva som er teknisk gjennomførbart.

Tett relatert til dette med skisser så finnes det en myte om at alle designere kan tegne. Sjokket var stort da jeg spurte om ikke designeren vår kunne trylle frem noen ikoner til en ny del av applikasjonen og jeg fikk til svar at det ikke var hennes sterkeste side. For å bekrefte/avkrefte denne myten jeg har hatt så tenkte jeg at i forbindelse med denne artikkelen at vi skulle kjøre et praktisk eksperiment. Deltakerne skulle være de 3 designerne vi har på prosjektet jeg sitter på til daglig. Oppgaven bestod i å tegne et utvalg ting i løpet av 1 minutt. Resultatet er åpent for tolkning:

Noe jeg tenkte en del over før var hvilket plan designere jobbet på. I mitt hode jobbet de på et abstrakt plan med fluffy idéer uten begrensningene fra virkeligheten. Vi utviklere er gode på å se hvilke begrensninger vi har i en verden bestående av 0ere og 1ere. Kall det gjerne en yrkesskade, for det henger tett sammen med hvor mange timer vi har brukt på å midtstille en knapp på en responsiv nettside.

Alle designerne jeg har møtt på i løpet av disse årene har hatt beina godt plantet på jorden og fluffy idéer er egentlig bare en del av en kreativ arbeidsmetode. Innovasjon og nye ideer oppstår for det meste ikke når vi ser på hvordan dagens løsning er. Her tror jeg vi utviklere har noe å lære. Strengt tatt er alt teknisk sett mulig å lage gitt nok ressurser og kloke hoder.

I forbindelse med denne kalenderluken spurte jeg designerne i Bekk om de kunne sende meg et bilde av pulten de sitter ved til daglig. Visjonen min var at jeg kom til å treffe ganske heftig med beskrivelsen min i innledningen. Det jeg egentlig sitter igjen med er at jeg har bomma til de grader. Designeres pulter kan deles i 2 grupper; de med rot i systemet og de med system i rotet.

Konklusjonen på visa er at mitt utgangspunkt for hva en designer er ikke stemmer helt med virkeligheten. I løpet av de siste årene i arbeid har jeg lært mye om en designers arbeidsmetoder, faglige styrker og hvordan jeg og designere kan jobbe sammen for å levere mest mulig verdi. Kort fortalt så er ikke en designer en som leverer fra seg fargerike skisser; en designer er like mye en utvikler som det jeg er i hverdagen.

..Og når det kommer til en designers pult mangler bildene jeg fikk mange elementer, men jeg vil gi meg selv et halvt poeng for post-its og Macbooks.




Takk til mine designkollegaer...

Stine M. Hjetland for tegning i intro og deltakalse i eksperiment 👏\ Elin Orsen og Emil Säll Fuglerud for deltakelse i eksperiment 👏\ Alle dere som sendte meg bilder av pulten deres 👏

Designere gjennom en utviklers øyne

In Kotlin, the standard way of handling errors is with exceptions, more specifically, unchecked exceptions. This is god mode. As long as the object we are throwing is a subtype of Throwable, we can do whatever we want. The compiler will not complain. This sounds like a good thing, right? Well, it depends.

Unchecked exceptions are, by definition, dynamically typed, and thus, not typesafe at compile-time. The compiler will not tell you what to catch or even whether what you are trying to catch will be thrown at all. You must either know or check it yourself. As the codebase and number of developers grow, knowing will become futile at some point, and lazy developers are more likely to not check than check. I would much rather have the compiler tell me then and there exactly what I might have missed.

Error Handling with Result<T, E>

A common way to deal with error handling, without the use of exceptions, is with a Result<T, E> type. This type comes in many shapes and forms and is also commonly referred to as Try or Either, but it primarily aims to enforce error handling in a typesafe way. A very barebone, yet fully functional, implementation is listed below.

Result is a superclass that can only be instantiated as an Ok or an Err. If you receive an instance of Result, the only way to get the encapsulated value is by explicitly checking whether it is an Ok or an Err instance. In other words, error handling is both enforced and compile-time typesafe. Simple enough, right? Let us look at an example.

In this example, the divide function either returns a String (the error case) or an Int (the quotient). Together with Kotlin's awesome when and smartcast functionality, the above code is minimal, easy to read, and straight to the point. Great!

But what about more complex problems you might ask. Well, this barebone implementation suffers from a readability problem when it comes to more complex problems, especially in the case of lambdas. Imagine being forced to check whether the result is an Ok or and Err in every step of a lambda pipeline. To illustrate the problem further, let us look at a function that should periodically transfer all changed users from a database to a third-party API. It performs the following subtasks:

Fetch the timestamp of the previous successful transfer from the database.

Fetch all users that have changed since this timestamp from the database.

Transfer all those users, one by one, to a third-party API.

Save the result of the transfer to the database.

The signature of the functions we use are as follows:

With the barebone implementation of Result listed above, this function may be implemented like this:

This implementation does not feel right. With all the error handling so tightly intertwined with the actual business logic, its readability suffers. Imagine that you needed to let the failure of each step propagate up the call-stack (an extremely common scenario). To do that, we could add else-clauses to all those ifs and then return the error. That would make it even more verbose and harder to read. There is, however, a simple fix for this readability problem: make Result<T, E> a monad. By adding a map and a flatMap function to the Result-type, we get the benefits of monadic chaining. For readability and explicitness, we name the flatMap function andThen (you will see why shortly) and also add a mapError function as well.

With these three functions added, let us see how improved the readability of the transferChangedUsers function becomes:

Neat, huh? Now it reads very much the same way as the specification points themselves! The error handling is no longer tightly intertwined with the business logic. Notice that both map and andThen do nothing when the result is an Err. This means that if we now needed to let the error of each step propagate up the call stack, we remove the mapError call at the end. If, for example, the call to getLastSuccessfulTransferTimestamp fails, none of the .andThen nor the .map calls are going to apply its transformation function.

We still have one challenge remaining, though. What if function C needed the result of function A and B as arguments, and both A and B could fail, and thus, return a Result<T, E>? As an example, picture the transferUser function from the above example suddenly needing an authentication token as input.

The signature of transferUser changes to:

and a new function to fetch a token is introduced:

The transferChangedUsers function could now look like this:

Notice the use of Pair. When we have to carry the results of previous actions through the chain, it becomes unreadable fast, very fast. Luckily, people have also found solutions to this problem, often referred to as monad comprehension, for-comprehension, async/await, etc. By adding monad comprehension to the Result type, we can make it look very much like conventional imperative code.

Now, that is much easier to follow! So, let us dissect what happens here. If you are familiar with async/await from javascript, this is the same concept, just in a different context. runResultTry can be seen as the equivalent of async, while .abortOnError() the equivalent of await. The implementation is listed below.

In simple terms, the runResultTry function takes a function as an argument and executes it in a try/catch. The .abortOnError function is a scoped extension function of the Result type, which is only available inside the block passed to runResultTry. When a result is an Err, the .abortOnError function aborts execution by jumping to the catch block of runResultTry, or else it unwraps and returns its encapsulated value. The fact that it uses exceptions internally is just an implementation detail, and not important. You may also notice the suspicious casts. These casts are a way to get around the fact that exceptions cannot have generic types (a consequence of dynamic typing and type erasure). Regardless, the casts are safe in the current implementation above.

When Should You Use Result<T, E>?

The Result type is not a silver bullet that fits every error-handling situation perfectly, at least not in languages with side effects. When this pattern is used to handle errors of functions where you do not care about the return value (i.e., impure functions), a problem arises: errors might be swallowed. If you are not prepared to receive a return value, it is very easy to forget to check whether the invocation failed. In situations where nothing fails or blows up, errors and bugs may be difficult to debug. In other words, exceptions might be a better choice in such situations. At least then, everything blows up and gets (hopefully) logged.

There are solutions/workarounds to this swallowing-problem, even for impure languages. Javascript, for example, has the global unhandledrejection-event, which fires whenever a promise is rejected but lacks an error handler (i.e., a .catch()). In Kotlin (and Java), we may utilize the finalize-method to implement the same concept, but on the other hand, finalize is only called when the object is about to be garbage collected, which makes it somewhat unreliable.

Currently, my rule of thumb is that you should use:

Exceptions when:

You treat all errors equally, and the type of the error is irrelevant. I.e.,

An error handler at the top-level of your application that only catches instances of Exception would suffice.

You do not try to recover from failure.

There is a high risk of the error being swallowed, either now or after a refactor in the future.

Result when:

None of the above points about exceptions apply.

Typesafe Error Handling in Kotlin

The release cycle of Java has changed quite dramatically recently, meaning we're getting new features at a more rapid pace than earlier. If you still hadn't had the time to read up on what's been going on the last releases, look no further!

We've previously covered what's new in Java 11, and today I want to tell you a little bit about what has happened since then. Please beware that none of these versions are LTS (long term support) versions. So if you're not absolutely sure you'll be able to upgrade every six months until Java 17 is released, you might want to stay put on Java 11 for your most critical applications.

With that disclaimer out of the way, we can jump into the good stuff. I wont cover all new features (have a look at the JEP list for version 12, 13 and 14 if you'd like), but I'll highlight a few interesting language features.

Today I'm focused on two new features, another post with some additional features will be available in a couple of days.

Switch enhancements

switch has gotten some changes! They have been previewed in JDK 12 and again in 13 and are at time of writing aimed for release in JDK 14. We'll be getting one new feature for when switch is used as a statement and, in addition, it can also be used as an expression going forward.

Arrow labels

We can now use arrow labels (case X ->) in addition to the old case X: label in switch statements. Upon using arrow labels, only the expression or statement on the right hand side of the arrow will be executed. This means there will be no fall through so you no longer need to remember break;:

Switch expressions

switch can now be used as expressions, i.e. it can return a value. This means we won't have to first declare a variable, then assign a value in every single branch. Combined with arrow labels it allows us to express our intent in much fewer lines of code:

Sometimes you might be forced to execute a code block as part of a case expression. In order to combine this with arrow label syntax, you must yield a value at the end of the block:

You may also turn switches using the old style labels from statements to expressions by using yield.

⚠️ Please remember that it is the arrow label syntax that prevents fall through. That means, if you forget to yield, the next case expression will be evaluated and you might end up with the wrong result. I'd recommend you stay away from this syntax for this reason.

As usual more features leads to more complexity. We've certainly gotten a more feature rich switch, but as illustrated above it has also become much more complex. You have to remember which label style, : or ->, has fall through – and what was the point of yield again? Stephen Colebourne (you know, that guy who wrote Joda-Time) has written a much more in depth blog post where he raises some important questions regarding the UX of these features. If you're interested in the new switch features, make sure to read this first!

Pattern matching for instanceof

As a Java developer you've most likely been in a situation where you have to check if an object is a certain type, and if it is – cast it to that type. This pattern is widely used in e.g. equals implementations.

Introduced as a preview feature in JDK 14, instanceof is extended to take what's called a type test pattern instead of just a type. A type test pattern consists of a predicate and a binding variable.

⚠️ Disclaimer: This feature is currently not supported by IntelliJ. You can follow the progress in Jetbrain's issue tracker.

Consider the following example:

Using this new feature, you may rewrite as follows:

In the above example Person other is the type test pattern.

Inside the if block, you may use other and it's guaranteed to be a Person. other is, however, not accessible outside the if block.

⚠️ It's worth noting that the scope of a binding variable is determined by the semantics of the containing expressions, which might lead to some surprising results:

obj is not a String, s is some other variable in scope (e.g. a member of the enclosing class).

obj is a String, s is obj cast to String.

This is certainly not the most game changing feature in itself, but it sends a signal that Java is embracing pattern matching as a concept, a language feature many other popular languages has supported for a long time. And as an added bonus, your equals implementation can be shortened slightly to emphasize the important bits.

Enabling preview features

The new switch changes currently have preview status in the most recently released JDK version (13). This means you probably don't want to use them to a large extent in the code base you earn your living of. APIs could change, and there is still a chance the feature won't be promoted to a stable feature in its current form.

It is, however, valuable to experiment with them. Trying new features is a good way to broaden your skill set, and if there is something you strongly dislike about the usability of a feature you can even provide feedback to the JDK developers. Look for the Discussion label on a feature's JEP page (linked below) to find the correct mailing list.

To get started experimenting with preview features in the tool you use, follow the guides below:

Maven

To activate during compilation, add the following configuration to maven-compiler-plugin:

For test execution, add the following configuration to maven-surefire-plugin and/or maven-failsafe-plugin:

Gradle

Enable the compiler flag for compilation and test execution as follows:

IntelliJ

Go to Project Settings > Project and find the Project language level dropdown. If you previously targeted version 13 and want to enable the preview features, choose 13 (Preview).

What's new in Java 12, 13 and 14, part I

When I decided to write a blog post called "How to talk like a machine", I discovered that the question of how to write a simple blog post had a lot of deep implications. The follow-up question was "How can I make my blog post read like a machine-made blog post?". It turns out that there is a difference between writing a single paragraph of prose and a long essay in a natural language. There are a few things you need to be aware of when you write a machine-made blog post.

Did something feel a bit off about the paragraph above? That may be because it was written by an artificial neural network. The neural network is called GPT-2 and is a state of the art text generator. GPT-2 was given the sentence When I decided to write a blog post called "How to talk like a machine" as a starting point and came up with the rest of the paragraph by itself. In the following sections we will go through some fundamental theory regarding text generators.

Simply put, a text generator is a computer algorithm that generates text. There are different approaches, but we will focus on approaches based on neural networks in this post. The core goal for a text generator can be defined as "Given the text I have seen, what is the text most likely to follow?" and this goal can easily be translated into a prediction task for a neural network.

In order to train a network to perform this task, we have to represent words as numbers in some way. Luckily, some smart people have figured out a great way to do this through a concept know as word vectors. A word vector is a numeric vector representation of a word. These vector representations are often learned from a gigantic text corpus and captures relationships between words in the language. Some common algorithms for generating word vectors include Word2Vec, GloVe and BERT. Transforming a sentence into a sequence of vectors is the first step of a text generator.

Neural networks for text generation are usually designed to take a sequence of words (represented as vectors) as input, and output probabilities for the next word. The network is trained on sentences from a corpus of text we want it to mimic. We feed the network with sequences of words from the training corpus and the network tries to predict the word that follows. The more correct words the network predicts, the better it will be at mimicking the training text.

After the network is trained it has learned which words are most likely to follow each other in the training data. We can then generate text as follows:

Feed a seed to the network. This can be a sentence we want the network to work on from or just an empty string.

Make the network predict the probabilities for the next word.

Choose one of the words with the highest probability and add it to the end of the current sentence.

Feed the augmented sentence back to the network and repeat the process from step two.

Steps 2-4 can be repeated as many times as wanted to generate a text sequence of the length we need. The image below illustrates how the sequence of words are propagated through the neural network to produce the next word in the sentence.

You now have a basic understanding of how a text generator works. If you want to play with the text generator used to generate the first paragraph in this post you can visit https://talktotransformer.com and feed it a seed of your own. Have fun!

How to talk like a machine

Yesterday, we showed how to empower our users to stop our long running animations. But why force our users to manually stop animations, when they are screaming at us that they do not want animations!

In modern operating systems, users can specify that they prefer less animations than normal. In iOS and macOS, this is called Reduce Motion. On Windows you can disable “Show animation in Windows”, and on Android you can “Remove animations”. With this setting in place, modern web browsers supports the experimental media query prefers-reduced-motion. With this knowledge in hand, we can now remove animations for our users who’d rather not see them:

Great, this kind of work, if your animations and transitions start and stop at the same position. But that happens if your original transition start from outside the viewport? It just stays there forever, never getting the chance too see the light of day, poor thing!

A better solution is to let the animations and transitions finish in no time at all, making sure they at least stop in their final state, hoping the final state is inside the viewport:

But what about my beautiful animations and transitions?

By utilising the above css rules, we just made something special into something boring, but our users never told us they didn’t want any movement at all, they just told us the preferred less movement. They simply might be using an old device with poor performance and battery life, or they might struggle from a vestibular disorder, epilepsy or migraine sensitivities.

If you have ever enabled this setting on one of your devices, animations are not removed, but they change, because not all animations are problematic. You should really read Designing Safer Web Animation For Motion Sensitivity for details about problematic animations, but in short avoid:

large areas of motion

mismatching direction and speed (parallax effects and scrolljacking)

large perceived distance (like the animation on our site…)

In many cases, fading content into view using transitions is a good replacement for moving content, and is for instance widely used in iOS when reduce motion is active:

Thats all for today, I love animations, and hope too see more of this in the future, just be mindful of those who really can’t handle our crazy inventions :)

CSS Accessibility - you make me sick!

Design is complex - and ever increasingly so. It requires full collaboration between all teams and professions involved in the process. A shared design language makes teams work together more effectively. That’s why companies invest in design systems. But how can we make sure that it works for our product and improves our productivity?

Design systems should let product teams take a systematic approach to their work. But all design systems are not equally effective. Some help product teams create coherent experience; others produce confusing designs. We can measure the system's success by how well it helps us achieve the purpose of the product.

What is the reason you need a design system?

Perhaps you are creating a solution to an imaginary problem? Or do you just want a design system because others have one? None of these reasons suffices - obviously.

Creating a design system is time-consuming. And it could easily slow a small team down instead of moving them forward. The time you spend building a design system, you can't spend building a product. And if you don't have a clear direction, creating a design system risks being a waste.

A design system should come from the need to increase efficiency – when work is being slowed down by lack of design direction. But you also have to consider this mechanism: Those who create the design system believes firmly in its importance, and those who it's meant for tend to think they do better without it.

So how do you make it work?

You need clear directions for designers and developers:

Map out user's needs, goals, and motivations

First we need to understand who our users are and what are their goals, needs, and motivations. This information should be the foundation of the design system you want to create.

Express the purpose of the product

The product's purpose should inform design and development decisions. This purpose should be expressed in one sentence. The purpose should be natural, otherwise, the team won’t believe in it.

Establish clear design principles

Clear design principles are the foundation of any functioning design system. They should capture the essence of what good design means for the company and provide practical recommendations for product teams on how to achieve it.

Measure your progress

Implementing a design system is a process, and you need to ensure that the system is helpful through the process. But it can be hard to predict how a change will affect the user experience, so it's a good idea to define metrics and track them as you go.

Conclusion

A design system should be the guide to your product development. It enhances design-driven culture – it encourages people who work on the product to think of the purpose of their design. The design system's ultimate purpose is to give a better understanding of your users and a better user experience.

Why (not) make a design system?

“The s in IoT stands for security” is a joke as old as the shared code base used in your IoT web-camera. Usually we mock IoT for having little or bad security, but the real issue is perhaps that IoT can't have good security.

The problem however is that even if we solve the following headaces of IoT: shared codebases, dependency insecurities, and somehow find a way to keep devices up to date; we still face an even bigger problem! The architecture is flawed, as the devices are not computationaly strong enough to provide randomness.

This means that the devices that make your home or offices smart, is the weakest point of your network, and the easiest way for an intruder to get access to the network.

Before we dive into why we need randomness, let's look at what random is. Jackson Pollock, the artist that painted the picture on top of this article has a seemingly random way of generating his art. It is however the opposite! There is a lot of non-ranomness to it, Pollock takes advatage of fluid dynamics, and some even states that the pictures reflect fractal geometry that shows up in clouds and coast lines. So what is random? Javas implementation of Random()? or perhaps SecureRandom()? \ Can anything as predictable as a computer be random?\ Without diving into chaos theory and discussing the plilosophy of randomness, lets jump back up to what we need randomness for in computers.

What do we use this randomness for? The short answer is for cryptography. More in detail it is how we generate secrets used for encryption. The link between random and entropy is that entropy is the randomness collected by applications and the operating system.\ In the ye olden days, entropy was calculated from the clock of the computer. So, if you knew the exact time of the computer, it was possible to statistically reduce the number of attempts needed to break the encryption. Today we (hopefully) rely on well tested and hardened libraries for cryptography. These libraries use all sorts of mechanisms for generating entropy. Keyboard timings, or mouse movements, some even use fan noises to generate entropy well. We need something that is random, speaking from a philosophical point; computers are not.. IoT struggles more as it is hard to computationally achieve randomness with cheap and underpowered cpu’s, often no keyboard timings, or mouse movements, that are used to generate randomness.

NIST perhaps has a solution: Entrypy-as-a-Service, but should we trust a centralized authority for a service of such fundamental importance?

I highly recomend you checkout the link to NIST proposition for a new service, and Cloudflares LavaRand. If you are the lazy type, you should checkout Tom Scott's video on LavaRand.

The problem with IoT and random

Entur operates the national registry for all public transport in Norway, collecting data from 60 public transportation operators. The registry contains data about 21,000 daily departures on 3,000 routes. This data is open and free to use for app and service developers.

Based on this registry Entur also provides Norway’s public transport route planner and ticketing app - Entur - with over 250 000 downloads. The app is developed using React Native, and it’s supplemented with a lot of Google Firebase features. In this post we’ll be highlighting how we use the Firebase Remote Config feature and the Cloud Functions.

Firebase Remote Config

First of all, Firebase Remote config is a really great tool. It has helped us in many ways to handle a lot of the challenges we’ve experienced while doing app development. When we release a new app for the AppStore it could have been everything from a few hours to days since we sent the app to Apple for approval. And when the app is available in AppStore, it can take up to several days, weeks or months before the users updates their app. This means that there are a lot of users out there that uses different versions. Fortunately, a lot of users do an automatically update every night, so most of our users will normally use the latest version within a few days.

So to be able to handle feature toggling or changes in all the different app versions, we’ve set up several remotely configurable parameters in the app. Let’s say that there are some general alert or notice information that we want all our users to know if they open their app. To handle this we’ve added a remote config parameter called info-message, which shows up in the app if it contains any text. When the app launches, it will get the latest data from Remote Config and show this to the user. And with the Conditions feature in Remote Config, we are able to schedule a config message based on time, date, app versions etc. to when the message will be showed in the app. This is very handy to set up during the day if there is any planned maintenance that we want to inform about during the night.

In December we have put a cute Santa hat on the profile icon in the app. The code for this feature has been included in all the latest versions of the app. During December we can toggle this feature on, and turn it back off again in January. No need for a timely app release, only a simple remote config change.

Firebase Cloud Functions

When we first started developing the Entur app three years ago, all the communication to the API’s was done directly from the client. This worked well in the beginning, but as the number of active users increased, and we also needed several authenticated API calls, we started looking for something or someone that could be our BFF, or at least our Backend for Frontend. Since we already were in the Firebase domain, a natural choice was to try out Cloud Functions.

Cloud Functions for Firebase let you automatically run backend code in response to events triggered by Firebase features and HTTPS requests. Your code is stored in Google's cloud and runs in a managed environment. There's no need to manage and scale your own servers.



https://firebase.google.com/docs/functions

Sounds great, right! But there was especially one thing we were curious about if we wore going to use Cloud Functions. And that was the cold start. Since these functions are serverless, the cloud server might shut down if there is no traffic, and then have to start up again it’s triggered. SInce there is no built-in way to keep the server running, our workaround was pinging some of our functions now and then to ensure that it was kept alive, so that the app user would get a fast response.

With more active users calling our API’s through our BFF, this pinging might no longer be necessary any more, because most of our functions now is being kept alive by continuous traffic.

In retrospective, we are very satisfied with what cloud functions have provided us. It was fast and easy to get up to run, it is stable and scales automatically. It is something we really would recommend if you want a simple backend to get started with. Nevertheless, we are now thinking about porting some of our functions to something like Google Cloud Run. This will give us some extra features that Firebase Functions can’t give us right now. This be processing concurrent requests on the same instance, as well as being able to reduce the latency even more than what we can get from Cloud Functions.

More Firebase features

Firebase offers a lot of different features. Remote config and Cloud Functions are just two of them. For caching of data and backup of the public transport tickets we are using Cloud Firestore, a scalable NoSQL database. Fabric.io was previously used for app distribution, but this is now all integrated into Firebase App Distribution. And for testing of new app features, we are using Firebase A/B Testing to get some real world statistics of how successful or unsuccessful this new functionality might end up to be.

Summary

Using Firebase for the last couple of years have for us been a very satisfying experience. To be able to have at least some control of the features in a distributed mobile application, Firebase have provided us with the functionality we been needed. Remote config have enabled us to turn features on and off, or add scheduled information messages directly into everyone's app. While Firebase Cloud Functions have made it possible for us to move a lot of business logic out of the app to a more controllable environment.

We are looking forward to see what more to come from Firebase over the next years!

Firebase features, React Native and Entur

Therese Borge Lied, Nora Guthe og Snorre Gryte tar praten om bærekraft i produktutvikling over en kaffe. Vi snakker litt om hva bærekraftige produkter kan være, og gapet mellom holdninger og faktisk adferd.

17-Dec

Today's posts