The age of IoT (Internet of Things) is upon us, and it poses a real challenge to the security of our home networks. This post will look at some practical approaches you can take to isolate untrustworthy devices from the rest of your home network.

What will you do if you wake up one morning to find that your new, smart coffee maker has been hijacked by a devious hacker? Maybe you don't get any coffee that morning, unless you pay a Bitcoin in ransom. Or perhaps the hacker does not care about coffee at all, but merely uses your all too vulnerable coffee maker as an access port to your network, and before you know it all hard drives in your house have been encrypted.

One thing is for certain: You will start thinking about how you could have prevented this travesty. The obvious answer is that you should never have connected your coffee maker to the Internet. (Why would you? Seriously?) But it seems we can't avoid the temptation to make ever more of our various devices "smart". The age of IoT (Internet of Things) is truly upon us, and while many uses of IoT technology have questionable value at best, it is undeniable that ubiquitous network and/or Internet connectivity creates possibilities which were unimaginable just a few decades ago. So whether the device that you can't live without is a smart coffee maker, smart light bulb, smart thermostat or a smart toilet (yes, that's a thing), the value-add comes at a price. Most IoT devices, especially cheap ones, run flaky software built around an outdated version of the Linux kernel riddled with security holes. Most of them will never be updated.

So what can you do, in your own home, to prevent these devices from posing a threat to the rest of your network? To understand this, we will now look at how your router actually protects the network from unwanted traffic from the outside, and why this protection is not sufficient in the age of IoT. We will then look at three different approaches you can take to split up your network and keep the insecure stuff isolated from the rest.

First line of defence: Network Address Translation (NAT)

All home routers have a kind of firewall, in the sense that they block all unexpected traffic from the outside. All devices on the local network have a local IP address (typically in the 192.168.x.x space or the 10.x.x.x space). These addresses are not globally routable; packets destined for these addresses simply cannot traverse the Internet. However this does not prevent devices inside the local network from contacting addresses on the global Internet. The router keeps track of all outbound connections initiated from addresses on the local network, making sure related packets from the outside are forwarded to the correct local address. Any packets from the outside which cannot be associated with a recent request from the inside are dropped by the router. For more details on how this works, see this Wikipedia article.

This is all well and good, so long as you can trust the integrity of all the devices on your network, and that the servers they communicate with are all perfectly well-behaved Internet citizens, kept up-to-date and secure at all times. This is of course a pipe dream. If just one of those servers is compromised (or outright malicious from the start), the route to taking control of the IoT device with which it communicates is short. The device can be made part of a large globally spanning botnet and used to launch DDoS attacks against critical infrastructure anywhere in the world. If the device has some processing power, it may be put to work mining cryptocurrency. Or it may simply be used as an entry point, and a malicious software suite may be used to look for known vulnerabilites in other devices on your network, which are promptly taken control of in a similar manner.

Limiting the damage potential: Network segmentation



The above image shows a typical home network, with all devices connected in a flat network structure.

To limit the damage potential of a compromised device, you should split up your network, isolating all devices you do not fully trust on their own IoT network, and keeping trusted devices on the main network. A trusted device is typically a computer, tablet or mobile phone which receives frequent and timely security updates, and whose vendor has a track record of decent security. (Note that this rules out most Android phones older than three years, but that is a story for another time.)

We will now look at three different approaches you can take to segment your network.

Multiple routers

The most obvious solution is to use two different routers to create two physically separate networks. To do this properly you actually need three routers: The router provided by your ISP (Internet Service Provider) as well as two additional ones. When set up like in the diagram, this provides complete isolation between the two networks with devices on them. There is a third network here, and that is the one consisting of the three routers. That network is now the WAN (Wide Area Network) side of the two lower routers. Unexpected traffic from here is not allowed to enter either of the two lower networks, thanks to NAT.

But what if the Internet cable/fiber is terminated in your living room (which is quite typical), and you have to set up all these routers there? If you live with people, they may not appreciate the living room looking like a techno dungeon. And you probably wouldn't either. The mess can be reduced somewhat by using the ISP router for the IoT network (provided its wifi has sufficient strength to reach all your devices), and connecting your main router to the ISP router as a client. Now the IoT network is the WAN side of your main router, and the trusted devices on the inside are still invisible to the vicious IoT devices in your home.

Ok, I know. Two routers in the living room is not great either. Thankfully there is a simpler solution.

Guest network

Many routers provide the option to enable a guest network. When implemented correctly this gives you a second WiFi network with a separate SSID and password. Any devices connected to this network should be isolated from everything on your main network. If the router vendor has done things right, the devices on the guest network should not even be able to see each other. The guest network simply provides its clients with access to the Internet. This is ideal for sharing bandwidth with your guests, whose phones you should probably not trust to be secure enough to enter your main WiFi. It is also ideal for IoT devices which only need access to the Internet, ie. they have no (legitimate) need to talk to any other devices in your house directly. This applies to many IoT devices, which only need to communicate with a remote server, and you get access to monitoring and control capabilities via an app which also communicates with that server.

But what if your devices actually need to talk to each other directly, on the local network? An example could be casting video to a Chromecast device or music to a Spotify-enabled smart speaker. Well, you could just forfeit and put those devices on the main network. But there is another way.

Virtual networks (VLAN)

If you have a VLAN capable router, you can configure multiple virtual networks which run on the same physical infrastructure, whether this infrastructure consists of WiFi, cable or both. It works by attaching VLAN-specific tags to the Layer 2 data frames which are sent around the network. You set up the different VLANs in the router's admin interface, and then specify which VLAN should be attached to each physical Ethernet port on the router's integrated switch, as well as downstream VLAN capable switches connected to the router. You can also set up multiple WiFi SSIDs and attach them to VLANs in a similar manner.

Let's look at an example using physical connections (illustrated in the above diagram). We create two VLANs called MainNet and IoTNet. We enable MainNet on the switch's ports 1 and 2, and IoTNet on ports 3 and 4. Then we connect two computers (by ethernet cable) to ports 1 and 2, and a smart TV and a smart speaker to ports 3 and 4 respectively. Even though these devices are now physically connected to the same switch, the computers cannot see the smart devices, and vice versa. Even if the SmartTV knew the IP address of the PC connected to port 1 and wanted to talk to it, it would not be able to do so directly via the switch. This is because the data frames coming from the TV will be tagged with the IoTNet specific tag when entering port 3 on the switch. These tagged frames are not allowed to traverse port 1, which requires all frames to be tagged with the MainNet specific tag. Since the switch cannot forward this traffic directly to the destination, it is instead sent to the router. Now the firewall rules programmed into the router will decide whether the smart TV on IoTNet should be allowed to talk to the PC on MainNet. You can probably see that this is an extremely flexible approach, which enables strict segmentation as a base, but allows for configuration of exceptions where needed.



This concept works for small networks as well as large, as you can see in the above diagram. Multiple VLAN programmable switches can be connected to the router, and wireless access points can be connected to provide WiFi. You can create multiple VLANs to separate your devices into smaller groups, further minimizing the risk of a mass network compromise.

If your home network topology is somewhat complex, consisting of a mix of wired and wireless devices scattered throughout the house, then VLANs are the ideal way to make sure each device is only allowed to talk to the stuff it needs to. Note again that you will need a VLAN capable router (which may have an integrated switch and WiFi access point), as well as VLAN enabled switches and access points if you need to expand beyond the connectivity of the router. In this case you will be doing yourself a favor by choosing hardware from a single product line, as the job of configuring it all will be much simpler when all the devices are meant to work together.

Wrapping up

Using a guest network is probably the right solution for most people to significantly decrease the risk associated with rogue IoT devices on the network. VLANs provide more flexibility at the cost of complexity. You decide which approach is right for your network.

Further reading

If you want to learn more about the security and insecurity of your home network, check out some of these resources:

IoT security at home (bekk.christmas 2020)

Essential tips for securing your home network (bekk.christmas 2018), most of which you should probably do before embarking on the wonderful journey of network segmentation.

NAT explained in detail (Wikipedia)

Routersecurity.org by Michael Horowitz. If you want to really go down the rabbit hole of network security, this is the place.

Segment your home network today!

Drypp er en lavterskel podcast fra Bekk.

En liten gjeng samlet inn heftige påstander og inviterte til Drypp-innspillingskveld på Trondheimskontoret - med julebrus, godis og god stemning. Resultatet ble seks episoder med brannfakler. God lytt.

Brannfakkel - Trenger vi tester i 2021? (Del 6 av 6)

Mange viktige valg tas på tidspunkter der vår kapasitet til å fatte gode beslutninger er tynnslitt. Med et bevisst forhold til valgene vi tar i løpet av en dag, og hvordan vi fatter disse, kan vi frigjøre tid og tankekraft til å prioritere og fatte bedre beslutninger.

Vi er alle opptatt av å fatte gode beslutninger, enten det er på arbeidsplassen eller på hjemmebane. Mye tid og krefter brukes på å optimalisere beslutninger, gjerne gjennom omfattende undersøkelser og analyser, eller gjennom ulike tiltak som sørger for at vi er uthvilt og oppvakt når vi står overfor valg. Et virkemiddel som det imidlertid snakkes mindre om, men som likevel kan ha stor betydning for vår evne til å fatte gode beslutninger, er å motvirke fenomenet som heter beslutningstretthet.

Beslutningstretthet gjør oss til dårligere beslutningstakere

Beslutningstretthet (decision fatigue på engelsk) referer til den avtagende kvaliteten på en persons beslutninger etter en lengre sesjon med gjentatt beslutningstaking. I The New York Times beskriver John Tierney fenomenet og han viser til en rekke eksperimenter som finner at dømmekraft og viljestyrke svekkes betydelig når personer har måttet fatte mange (dels vanskelige) beslutninger på rad. Negative tendenser i vurderingsevnen vår, slik som kortsiktighet, impulsivitet, prokrastinering og beslutningsvegring, forsterkes av beslutningstretthet. «Beslutningsmuskelen» vår er altså lik andre muskler i kroppen – den blir sliten.

Denne innsikten bør være interessant for alle som til daglig står overfor valg og ønsker å fatte gode beslutninger. Se for deg at du og teamet ditt skal bestemme noen tiltak for kommende kvartal på slutten av et tretimers arbeidsmøte med tøffe diskusjoner. Å definere tiltak var hele hensikten med møtet, men teamets beslutningsmuskler er utslitt. Snarere enn å ta nok et vanskelig veivalg beslutter dere å heller fortsette forrige kvartals aktiviteter, og utsette veivalget til neste kvartal. Mon tro om situasjonen er annerledes neste kvartal. Eksempelet er banalt, men eksemplifiserer et viktig poeng: Mange viktige valg tas på tidspunkter der vår kapasitet til å fatte gode beslutninger er tynnslitt.

Dersom vi ønsker å være gode beslutningstakere bør vi derfor ha et bevisst forhold til beslutningstretthet, og gjøre målrettede grep for å redusere effekten av dette når vi står overfor valg.

Beslutningstretthet kan motvirkes

Neil Parsicha foreslår i sin bok, The Happiness Equation, et rammeverk som kan benyttes for å redusere antall beslutninger du må bruke din beslutningskapasitet på. Rammeverket tar form av en 2x2-matrise, der beslutninger kategoriseres basert på to dimensjoner: (1) hvor viktige de er, og (2) hvor tidkrevende de er.

Viktigheten til en beslutning handler om hvor store konsekvensene ved å fatte en gal beslutning er, og i hvilken grad beslutningen er reversibel. De viktigste valgene vi står ovenfor vil typisk ha store og irreversible konsekvenser for flere mennesker enn oss selv.

Hvor tidkrevende en beslutning er handler om hvor mye informasjon du trenger for å kunne fatte en kvalifisert beslutning, hvor vanskelig denne informasjonen er å oppdrive, samt hvor store analyser som behøves for å omsette informasjonen til et beslutningsgrunnlag.

Basert på hvordan et valg slår ut langs disse to dimensjonene vil en kunne kategorisere valg i fire forskjellige grupper. Rammeverket hevder deretter at en bør behandle de ulike kategoriene av valg på bestemte måter, slik at en kan maksimere sin evne til å fatte gode beslutninger i de viktigste og vanskeligste valgene.

La oss se litt nærmere på hver av disse fire kategoriene.

#1 Uviktig og rask - Automatiser

Eksempler:

Hvordan skal jeg reise til jobb?

Hva skal jeg ha på meg i dag?

Mange av de valgene vi tar hver dag er av denne typen. Beslutningene fattes ofte spontant eller i siste liten, konsekvensene er små, men de tærer likevel på beslutningskapasiteten vår. Vi kan redusere kapasiteten vi bruker på disse beslutningene ved å automatisere valgene. Heller enn å begynne dagen med å beslutte dagens antrekk, kan du ha en fast ukesplan for skjortene dine. Barack Obama, som uavhengig av ens politisk ståsted må regnes som en erfaren beslutningstaker, eksemplifiserer slik automatisering ved å kun ha på seg grå eller blå dresser. Mon tro om det er enkle dressvalg som gir overskudd til å styre landet.

#2 Uviktig og tidkrevende - Reguler og begrens

Eksempler:

Hvordan skal jeg svare på denne e-posten?

Burde jeg vaske leiligheten min?

Valgene som ikke er viktige, men som likevel kan ta lang tid å beslutte, skal vi ifølge rammeverket regulere eller begrense. Å besvare e-post kan ofte være en tidstyv når vi skal skifte kontekst, oppdrive informasjonen vi trenger for å svare, og kanskje bruke tid på å en god formulering. En løsning er å regulere tiden vi bruker på dette til noen designerte tidsrom i løpet av dagen, slik slipper vi å stadig rives ut av pågående arbeid. Videre kan det være nyttig å begrense tiden en faktisk bruker på å fatte uviktige beslutninger ved å sette konkrete (helst korte) tidsfrister til seg selv (ofte kalt «timeboxing»).

#3 Viktig og rask - Iverksett

Eksempler:

Skal jeg høre hvordan det står til med en kollega?

Når skal jeg hente barna i barnehagen?

Valg som kan ha stor betydning, men som likevel kan fattes raskt, bør håndteres og gjennomføres med en gang de oppstår. Er du usikker på om en kollega trenger noen å snakke med? Spør vedkommende med en gang for å unngå å dvele på valget. Mange valg som kunne vært tatt raskt kan bli tids- og kapasitetstyver dersom de ikke håndteres så fort de oppstår. Disse valgene bør derfor iverksettes så fort som mulig.

#4 Viktig og tidkrevende - Diskuter og prioriter

Eksempler:

Hva skal selskapet vårt være i fremtiden?

Skal jeg forlate mitt gamle liv og følge drømmen om å bo på seilbåt?

Dette er de store og vanskelige valgene vi møter, enten på arbeidsplassen eller på hjemmebane. Gjennom historien har det blitt sagt mye smart om hvordan en fatter slike beslutninger, og jeg vil ikke forsøke å oppsummere alt i dette blogginnlegget. Uavhengig av typen valg og hvilken tilnærming som benyttes for å fatte beslutningen, vil imidlertid en kvalifisert beslutning kreve både ledig tid og overskudd. Parsicha vektlegger at dersom du behandler de øvrige tre kategoriene på anbefalt måte vil du ha tid til å diskutere de viktige og tidkrevende valgene på en bedre måte.

Reduser din beslutningstretthet

Som beslutningstakere må vi være bevisst på beslutningstretthet og hvordan dette svekker vår evne til å fatte gode beslutninger. Ved å ha et bevisst forhold til valgene vi tar i løpet av en dag, og hvordan vi fatter disse, kan vi frigjøre tid og tankekraft til å prioritere og fatte bedre beslutninger i valgene som virkelig gjelder.

Enkle grep kan redusere den negative effekten av beslutningstretthet på dine valg. En enkel øvelse er å identifisere noen valg du må ta i løpet av en vanlig dag, og kategorisere disse basert på rammeverket beskrevet over. Når du har kategorisert valgene kan du utforme noen tiltak for å automatisere, regulere eller effektuere vekk disse valgene. Gir dette deg noe frigjort tid og kapasitet? Blokk ut litt tid i kalenderen til målrettet grubling over dine store beslutninger – hva enn de måtte være.

God beslutningstaking!

Unngå beslutningstretthet når du tar viktige valg 

How you can increase the performance of your Elm application using Html.Lazy, and why that motivated me to look into elm-css.

A few weeks ago, I got to sit down with a colleague of mine to fix a performance issue with one of our customer’s search page. The page looks something like this:

This page is one Elm app. Its job is to present the user with a list of results that match a search the user has made, and let the user make a new search if they find no suitable result.

Before reading the next paragraph, keep in mind that the actual application is much more complex than the simple drawing I’ve just shown you. The illustration is only there to make it easier to understand the problem and the solution we arrived at.

The page worked as intended, but felt a bit slow. There were small, but noticeable, delays between characters when changing the content of the search field. When clicking a button you might notice a tiny delay before anything happened. The animation for clicking the search button, which due to a bug in elm-animator wasn't using css animations, was choppy.

Now, the reason we were looking into this was because we, the developers, were unhappy about it. We hadn’t received any user feedback from our users that the page was slow. It wouldn’t even surprise me if most of our users didn’t notice any performance problem at all, much like many don’t notice the difference between a native- and an electron-app unless comparing them side-by-side. Well, the choppy animation was probably noticable, but that had only been in the app for a few days at this point.

In other words, the reason we were looking into this was because the performance didn’t meet our own high standards, not because it had become an actual problem… yet.

Finding the problem

Whenever there is a performance problem, we need to find a reproducible way to measure it. Since we already had a choppy animation, we simply triggered the animation a couple of times while running the browser’s builtin profiler.

Here are the results:

The root of our performance problem stems from a function called _Char_toCode, which is being called by two elm-cssfunctions: VirtualDom.Styled.getClassnameand Hash.fromString.

Since our animation isn't using css animations (again, due to a bug in elm-animator), every stage of the animation causes the view function of our Elm application to run. It seems that the most expensive part of our view function is when elm-cssgenerates class names for the HTML elements.

If the only problem we had was a choppy animation, we could re-implement it using css animations ourselves. However, since the app had a general feeling of sluggishness, that wouldn’t fix all our issues.

One could attempt to refactor the code to use less HTML elements, thereby giving elm-css less work to do. But when looking over the code, we didn't find any obvious way to do this. Even if we did manage to remove a bunch of HTML elements without changing the look of the page, we had no idea if it would be enough to fix our performance problems.

Enter Html.Lazy

Elm’s HTML package has a series of functions in a module calledHtml.Lazy, which lets you change a view function so that it is only called when its input arguments have changed. If the input arguments are the same as when the view was previously called, it will tell Elm's virtual dom implementation to make no changes to this particular part of the DOM without calling the actual view function.

As an example, if we have a view function call like:

viewSearchResults currentDate results

We can make it lazy by re-writing it to:

Html.lazy2 viewSearchResults currentDate results

And then viewSearchResults will only be called if there is reason to believe that it could return something different, which potentially avoids all the computation that function has to make.

elm-css has its own implementation of Html.Lazy, Html.Styled.Lazy, and so in theory we should be able to use this trick to give elm-css much less work to do, thereby increasing our performance.

It did turn out to be the case. Today, the search page runs much faster thanks to two lines of code that wrap our view functions using Html.Styled.Lazy. However, in order for those two lines to work we did have to do quite a bit of refactoring, in part because of how this optimization works.

The problem with Html.Lazy

The first thing we had to fix was some bad design on our part.

The search page is structured like two separate Elm views. The top part of the page, the search box, is one view while the results is another. It is natural then, that both of these top-level view functions become wrapped in Html.Styled.Lazyfunctions. This way, if you edit the text in the search box, the computation for rendering the search results can be skipped.

However, both view functions, as well as their sub-views, take in the entire model as an input argument. This doesn’t play too well with Html.Lazy, as the view will be triggered whenever the input changes, and since the input is the model itself, it will trigger every time one of its fields changes, even if that field isn’t being used in the particular view.

It’s also problematic from a code design perspective, as the views become very tightly coupled to the entire state of the application.

It took some time to refactor this so that both view functions had their own, entirely separate, piece of the model. Strangely enough, the application felt just as sluggish as before.

In order to reduce the amount of refactoring, we had opted not to change the actual application model, as that would also require us to refactor the init and update functions. Instead, we divided the application model into separate pieces as part of the view function itself.

So, where we previously had code like this:



We now had:

But this didn’t work.

The reason is that functions in Html.Styled.Lazy have a different notion of equality than Elm itself. In general, two things are considered equal in Elm if they represent the same value. However, Html.Styled.Lazy functions only considers two things to be equal if they are the same reference.

Since we were constructing a new searchModel and resultsModel object every time the view function was being called, they would never be considered equal to the previous input by Html.Styled.Lazyfunctions, even if comparing them with Elm's == would return true.

Realizing this, we went on and refactored the application model to have its own search and results sub-models. This also required big changes to our init and update functions.

After another hour or two we had a better structured application. Not only that, the animation was running silky-smooth and there were no noticable delays anywhere.

In conclusion

Html.Lazy, or Html.Styled.Lazy, can be a great way to improve the performance of your Elm applications. However, it's an optimization that is easy to get wrong.

Html.Lazy is the only construct in Elm that has the notion of reference equality. Because of that, it's an easy thing to forget when refactoring code, especially if you're not working on the same code base on a daily basis. You now need to be careful to retain reference equality in update and view functions around your code, something you normally don’t need to worry about.

If you don’t, nothing bad happens other than performance becoming worse, which you may or may not notice depending on your hardware, if you have Elm’s debugger running, or the code paths you’re triggering.

So while Html.Lazy can be a great tool, I found myself wishing that elm-csswas fast enough that we didn't have to use this optimization at all.

Tomorrow, I’ll take a deep dive into the inner workings of elm-css and explain how I found a way to nearly double the performance of the framework.

Fixing a performance problem in Elm using Html.Lazy

What are UI sounds and how can we use them to create better user experiences?

Digital user interfaces have become a huge part of our lives. We look at them most of our days when we are on our phones and our computers, and UI sounds have followed with it. You may or may not be familiar with UI sounds, but you are surrounding yourself with them on a daily basis. UI sounds are the sounds made by devices, software and applications we interact with. For example the small clicking sound you hear when you tap away on the digital keyboard on your phone. Some of the sounds are so well integrated that we barely notice or think about them. They are just there.



A brief history lesson

In the early days of digital UIs, sounds were something mainly used in video games, and not an integrated part of other user interfaces. Even the original table tennis-themed game «Pong» (launched in 1972), had some basic UI sounds. Imagine the small beeps when the digital ball hits the walls or the paddles. It was not mind-blowing sound effects, but it helped to highlight the interaction. In later games, UI sounds brought the players into an even more immersive experience, with different types of UI sounds such as notifications, feedback and soundtracks, which I will go into detail later.

Maybe not the first, but as with many things from Apple, they made UI sounds a thing. Kicking it off with redesigning the startup sound on the Macintosh computers in 1991. The startup sound that had been used before 1991 was dissonant and ambiguous, not signifying if the computer had crashed or if was booting up.

I thought, I gotta have this meditative sound, I used to joke about it being a palate cleanser for the ears.

- Jim Reekes - the creator of the Apple Macintosh startup sound

Today the startup sound is something we regard as a very distinct Apple trademark.



Types of UI sound

The different kinds of sounds can be differentiated into types, depending on the purpose of the sound. What is the sound trying to achieve? It’s not always a clear distinction, and sound can be a bit of several types, but I will try to describe them as best I can.



Notification sounds

Notification sounds are well… notifications. It’s the dings and beeps you hear when you get a new message. And it could also be the sound that signifies that your download is complete. But if we look outside of the world of smartphones, it could also be the alarm systems on a ship that tells the captain that the ship is on collision course or about to sail into shallow waters.



Interaction/feedback sounds

Interaction sounds are the immediate sound you get as a response to your actions with the user interface. Clicking sounds, small dings and so on. My personal favourite is the inflating and deflating balloon sound you get if you hold down the «thumbs up» emoji on Messenger.



A third category, which is harder to give one proper name or title, is the sound I would call purely delightful sounds. Sounds that are function more or less as something to spice up the user experience. For example, the Mac startup sound which was mentioned earlier is a hybrid of a notification sound and a sound designed to spice up the experience of turning on your computer.



When and where to use UI sounds

UI sounds can bring an extra level of detail to a user interface. Just be aware of when and where. Too much can become annoying and distracting. If you decide to dive into UI sounds, consulting a sound designer would be a good way to start. Making even the smallest clicks are time-consuming, complicated and don’t always turn out as what you hoped for if, you’re not a trained or experienced sound designer.

UI sounds are maybe not the most important thing when designing great user interfaces and user experiences, but can add the touch of something extra. UI sounds are still a field within interaction design with the potential for coming up with new ways of using them. Even though we have come a long way in implementing sounds in digital objects and applications there is still so much that can be explored.

14-Dec

Today's posts

Segment your home network today!

Brannfakkel - Trenger vi tester i 2021? (Del 6 av 6)

Unngå beslutningstretthet når du tar viktige valg

Fixing a performance problem in Elm using Html.Lazy

An introduction to UI sounds