JUnit 5 was released two years ago. Are you still running your tests with JUnit 4.12? Let’s change that, and get you started with JUnit 5.

Moving from 4.x to 5.x

If you want to use features available in Java 8 and above, you really should move to JUnit 5.

To migrate from JUnit 4.x to JUnit 5 you don’t have to rewrite all your tests at once. If you want to start using JUnit 5, do it. JUnit Vintage helps us with this. Get rid of JUnit 4 and include the JUnit Vintage Engine on your classpath. The vintage engine runs your old JUnit 4 tests in the context of JUnit 5.

Just add the following dependency to your pom.xml if you use Maven:

So far, so good. You should now be able to run your old JUnit 4.x tests with JUnit 5, but you're still not able to write new tests with JUnit 5. Add the following dependencies to your pom.xml to be able to use the new features provided with JUnit 5 in your tests:

Now you should be ready to get started with JUnit 5. Start by converting some of your old test annotations to the ones provided with JUnit 5.

Basic annotations

I won’t go into detail about every annotation in JUnit 5, but I’d like to focus on a few of them. The most important annotation is of course @Test, which is still used to denote that a given method is a test method. However, in JUnit 5 the @Test-annotation doesn’t declare any attributes. Test expectations, like expected throwables, should now be handled in an assertion instead.

Some of the annotations that have changed from JUnit 4 to JUnit 5:

The @Before and @After annotations have changed to @BeforeEach and @AfterEach

@BeforeAll and @AfterAll have been renamed to @BeforeClass and @AfterClass

@Ignore no longer exists. You can use @Disabled instead. Or maybe you can use some of the included annotations for conditional execution? Is your test only supposed to work on a specific OS? @EnabledOnOs({ LINUX, MAC }). Or maybe it shouldn’t run on Java 9? @DisabledOnJre(JAVA_9)

Integrating your tests with other frameworks

In JUnit 4 you could specify different test runners to integrate your tests with other frameworks, like the Spring Framework with the @RunWith annotation.

@RunWith no longer exists in JUnit 5. It has been replaced by @ExtendWith, which provides similar functionality.

You should have enough to get started with JUnit 5 in your projects. JUnit has an excellent JUnit 5 User Guide that you can use for a more comprehensive introduction to how you can best write your tests with JUnit 5.

If you want more handy JUnit 5 tips, be sure to check out:

Useful new features in JUnit 5

Get started with JUnit 5

Dette er del 2 av 6 kaffeprater om Smidig organisering. Vi diskuterer myndiggjorte team og diskuterer handlingsrommet og autonomiteten til teamene. Hvorfor snakker vi om myndiggjorte team fremfor autonome team?

Smidig organisering, del 2: Myndiggjorte team og hvordan gå fra vaskemaskinproduksjon til... noe annet?

I recently became a frontend developer. Again. The last time I was, was back in 2014. And it's pretty much like riding a bike: if you haven't done it in 5 years, you're going to feel pretty damn wobbly. Especially if the bikes started using create-react-app and Sagas in the meantime.

So, with all the wisdom of a child who just fell of his bike, I'm going to try to share a few insights on the state of ~biking~ frontend in 2019!

Types are here, and you should be using them

In 2014 I wrote my first big application using Backbone. Not particularly early to the party, I know, but it was definitely a step up from my former favourite frontend framework, jQuery Spaghetti 2.0. TypeScript was out already back then, but for some reason that was mostly for the .Net developers. Us Java guys were too cool. So instead we just passed around objects called data and opts, and console logged them to figure out what the heck was going on. And then we forgot to remove the console logging, and the application crashed in Internet Explorer in production.

Even then, writing large scale JavaScript application without types was starting to look like a rather shoddy idea. Coming back to frontend now, I had the pleasure of meeting a codebase where types had just been introduced. And what a joy! Not only does the types make life soo much easier, it even turns out that TypeScript has become a quite decent type system!

So, seriously: if you're writing JavaScript for money today and not using TypeScript, it's probably time to look that up.

The npm ecosystem turned out just as expected

"Oh great, even this guy caught the leftpad drama," you're probably thinking, and you're right. I did. Back in the day, the npm micro package ecosystem was all the rage. And why wouldn't it be? Everyone was super tired of Java, Spring and the whole one dependency to rule them all approach. So we did the only reasonable thing, and over-compensated by creating a million small packages.

Soo… leftpad happened. But that's obviously just one small symptom. How many packages do you currently have installed on your local development machine? How many different people authored those? How many of those authors are NSA or FSB? Oh well, best not to think too much about that.

Maybe in a few years we'll have Spring for JavaScript. At least there's some comfort in that!

React (kind of) turned out to be the endgame

For those of you too young (or too old and senile) to remember, there was a beautiful period of 5-6 years when we played Frontend Framework of the Year, where we would choose a new frontend framework to get excited about every year. And then run along and rewrite everything from last year to that.

Just kidding. Kinda.

I'm happy to see that React has gained some kind of permanent foothold. That kind of stability is good for tooling, good for developers, and certainly good for whoever is footing the bill. It also leads to sensible innovation, such as React Native. Which I've recently learned that also is available for web. React Native for React. What a time to be alive!

So although there are interesting alternatives like Elm around, it looks like React is going to be worth your investment for at least a few years to come.

JavaScript has become a Proper Language

Speaking of stuff that's been around for a few years, it's a pleasure to see the state of JavaScript these days. Back in the days, the most important thing when learning JavaScript was figuring out why it sucked and how to work around that.

These days, most things seem to work as expected, and there aren't that many bad parts. Even browsers seems to mostly behaving nicely, and more or less the same way, which is nice. Although, I must say that I am looking forward to giving a talk on why the correct way of comparing things in JavaScript is equalequalequal.

Build times are… meh

One of the great things about JavaScript when coming from the deep, dark caves of backend was the (almost) zero build time. That's definitely gone. I'm guessing the stable language I touted in the previous section didn't come for free. It looks like the average frontend build today would make my 2010 maven builds blush with embarrassment, in terms of build time, dependency madness and complexity.

I guess that just comes with maturity. Before a language has any use in enterprise applications (which I'm starting to figure out means 'real world' applications), the last thing anyone wants to deal with is dependency management, backwards compatibility and other boring enterprise stuff. But that quickly passes once your 20 million dollar business starts to fall apart because someone upgraded Babel.

JavaScript is definitely way past that point by now, and it's interesting to see how mature the toolchain has become. And hey, I get to take breaks to get coffee while My Code Is Building.

Developer tooling is… meh

With the maturity of the toolchain, developer tooling has improved. React and especially Redux provides some great debugging functionality, but overall, I'm a bit disappointed that the state of things aren't better than they are. Source maps are good, but the fact that the standard debuggers can't evaluate variables properly with source maps is a bit of a bummer.

There might be things I should know here that I don't, but I was hoping that we'd be well past the point where console.log and attaching things to global state are reasonable approaches to debugging.

In short

All in all, things are not bad in the world of frontend. The community is thriving, and innovation is both rapid and reasonably well directed. So, I guess I could reasonably say that things used to be worse. The coffee was bitter, and the developers were too. These days the coffee is single lot, the function scope is predictable, and the developers are hopefully slightly less bitter than they used to be.

So, if you yourself is part of the frontend community, enjoy it! Frontend as an area of expertise has undergone huge changes the last few years, and I dare say most are for the much better.

The State of Frontend, Five Years Later

Today's interview is with @olivtassinari. Olivier is a developer and the co-creator of the UI component library for React: Material-UI.

The questions below came from a simple question we asked ourselves:

if you had the chance, what would you ask an Open source maintainer/person/community member.

Here we go!

What are your biggest challenges in working with Open source today and how do you handle them?

The biggest challenge in developing open-source code is how you subsidize it, at scale. There aren’t that many options. The first one is to rely on the spare time of individuals. This requires to break down problems into chunks small enough individuals can solve independently.

The second one is to be a company that can leverage the project into an acquisition channel/common language for a paid product. The third one is to reach the critical size required for crowdfunding to work. We try to leverage these 3 approaches as the best possible in Material-UI. The paid product segment is what has been working the best for us so far.

Are there any useful tools you use to make your GitHub-life easier to manage, and if so, could you share a few of them with us?

I manage all the notifications with Gmail, the snooze feature is extremely useful.

You can save time by delaying things

I use Trello to study potential problems we will fix in the future. We aggressively move all support questions to StackOverflow.

How can repository-owners facilitate contributions from newcomers in Open source?

You have to make it as easy and valuable as possible, making it worth the time of somebody contribution, more valuable than the other ways people can invest their time.

We go very far on this end, as we are speaking, you can find about +10% of our open issues in the repository (+30) that have the “good first issue” flag and git diff of what the solution of the problem can look like and that we would likely accept.

If you could time-travel to when you first started, what advice would you give yourself as an Open source rookie?

I would tell myself to be much more aggressively in the way I invest my time, it’s so easy to get distracted by non important problems, to have more emotional courage and trust in myself.

Can you describe how you see the future of Open source, what new directions or paths do you think it will take?

10 years ago, paid UI libraries were leading the market, it had a market size above $1b/year. Today, it’s the opposite, open source UI libraries lead the market. We see open source UI libraries of better quality than paid UI libraries but that are far behind from a comprehensiveness perspective. Material-UI is working on this problem 🙂.

We are exploring the feasibility of an open core model. It’s the best approach we can think of to solve the comprehensiveness problem. We might see more projects try this direction.

Thanks for taking the time to talk with us Olivier! 💪

Interview with Olivier Tassinari

A typical cloud architecture - from a cloud native solution to a public cloud solution - consists of multiple connected services. Some of these services are your own, others are third-party services. Common for these is that they all communicate with each other over a network and that they depend on each other's availability.

When your application integrates with another service - your application must handle erroneous behavior from the service. Thinking resilience is, based on my experience, something we developers often forget and is first addressed once we experience availability issues with the service in production.

Timeout

When your application calls an external service, the service may not always respond. If this call is a synchronous call as part of a HTTP request to your application, the response will be delayed until the call to the external service times out. If your application continues to receive requests that cause calls to this external service, the long-lasting requests could begin to pile up. The web server running your application has a limited number of threads for handling requests, and when all these are in use, the web server will begin dropping new requests. Being aware of the timeout set on the client contacting this service might be crucial for keeping your application fully operational.

The client you are using to call the external service most likely has a default timeout value set, but it is not a value you can rely on is correct for your application. Especially in generic HTTP clients, default timeouts are usually set very high. For example, HttpClient found in .NET has a default timeout of 100 seconds. Knowing what to expect from the service you are calling and the context of your application, you should adjust the timeout to fit your needs. When using client libraries made for calling a service provided by e.g. a public cloud provider, you can usually expect more correctly set default timeouts. Anyhow, it is still a good idea to get familiar with what timeout the client is using. The service provider does not know how you are using their service and in some cases the timeouts set in the client library does not fit the context and nature of your application.

Changing the timeout on clients is usually pretty straight forward, but not in all cases. For these cases there exists resilience libraries that can be used to encapsulate client calls providing a configurable timeout. Polly is a popular resilience library for .NET, and has a Timeout-policy which can be used to do this. In resilience4j, a go-to resilience library for Java, resilience4j-timelimiter can be used.

Automatic retry

Sometimes, a service is unavailable for a short time. E.g. a node hosting the service goes down and the load balancer in front is still sending some traffic to the node, or a network issue causes a few packages to be dropped. These kinds of transient errors are very common in a cloud architecture. Having set a correct timeout towards this service will cause our application quickly to abort when the service is not responding, but we still will have to respond with an error. This is annoying, especially if the service overall is available - it was just our call to it that failed.

Before assuming that a service is unavailable when we get a transient error from it, we can retry to see if we get a successful response. This type of functionality can be built into to the client that is making the calls to the service and to be performed automatically on certain erroneous behavior. This is often referred to as automatic retry.

When applying automatic retry, many different retry strategies can be used. The simplest strategies are to either immediately retry or wait some predefined time before retrying - often with multiple attempts. But usually when a service responds with an error you do not know how long this behavior will last. You do not want to retry without giving the service time to come up again, but you do not want to wait longer than necessary either. A popular strategy is exponential back-off, where you begin with a very short wait period, and increase it exponentially before each retry attempt. Choosing the correct retry strategy depends on the use case of your application. If the call to the service is a synchronous one, you probably cannot afford many retry attempts and long wait periods. If it is asynchronous, something like exponential back-off can greatly increase the likelihood of the call being successful.

A common mistake is to retry errors that are not transient communication errors. Retrying errors like application exceptions make little sense as these errors usually do not just go away. Also, not all non-successful HTTP response codes should be treated as transient errors. For example, a service call returning a 404 will most likely continue to return 404 and retrying it will be useless.

Dedicated client libraries often have automatic retry built-in and the parameters are usually configurable - at least more basic retry strategies. If you find that the library you are using cannot be configured the way you want, these can easily be wrapped by a resilience library to achieve the retry strategy you need. The same libraries can be used to wrap generic HTTP clients with a retry strategy as well. Polly has the Retry- and WaitAndRetry-policies and resilience4j has resilience4j-retry, both allowing to configure advanced retry strategies.

Circuit breakers

Automatic retry is good for handling transient errors from a service, but if the service is unavailable for a longer time it will not help retrying the service repeatedly. In these situations, the focus should be on making sure your application handles that the service in fact is unavailable. One step to achieve this is to prevent your application from keep calling a service that is down. This will let your application respond momentarily in situations where a dependent service is down because it does not need to wait for a failing call. A much-used resilience pattern for this is the circuit breaker pattern.

I will not go into detail on circuit breakers, but in short, they allow calls to the service as long as the service is healthy. If calls begin to fail it will start bypassing calls to the service and instead just fail immediately. After a while bypassing calls, it will try to let through a single request to see if the service is back up. If it is up, following calls will also be allowed through, and if the call still fails it will continue to bypass calls. For a detailed explanation of the circuit breaker pattern, I recommend Martin Fowler's article on it.

In comparison to automatic retry, it is rarer that a service's client library has a circuit breaker built into it. At least that it is configurable. But you have probably already guessed that you can use a resilience library to achieve this. Both Polly and resilience4j has highly configurable circuit breakers with advanced features.

When using circuit breakers, it is recommended to monitor the state of each of them. Knowing if it is the circuit breaker that is blocking calls can greatly help in debugging situations. Adding monitoring of your circuit breakers into your existing monitoring system is usually quite easy with the circuit breakers found in resilience frameworks. For this reason, even if the client library has a built-in circuit breaker, it could also be a good idea to use the circuit breaker in your resilience framework instead so that you can monitor all your circuit breakers in the same way.

Summary

As communicating with external services is a big part of a typical cloud architecture, we have seen why thinking resilience could be important to achieve a robust cloud solution. Setting a timeout, performing automatic retry and applying a circuit breaker can increase the resilience of your application in different scenarios. Other techniques that we have not discussed here can be applied as well, like bulkhead isolation, fallback strategies and caching. Make sure to check them out in your preferred resilience library if you find any of them interesting. And finally, if you would like to dive deeper into building resilient software, make sure to check out Michael T. Nygard's book Release it!.

Resilience in a cloud architecture

Historier sender ungene våre til drømmeland. Historier bygger solide merkevarer og får tårer til å trille på kino. Historier skaper helter. Skurker. Presidenter. Mytologier. Konspirasjoner. Legender. De er limet som skaper et fornuftig narrativ vi kan forholde oss til i dag, i morgen og til dagen historiene våre er alt som er igjen.

Velkommen til en liten historietime. Om historier.

__



"For example, when I speak to female audiences, I get more personal and raw by telling childhood stories where the odds were stacked against me, which encourages the ladies to have resilience in overcoming hardships. I don't tell those same stories when I speak to a buttoned-up group of men. The men, instead, get stories about my quest for empathy."



– Nancy Duarte, a best-selling author with thirty years of CEO-ing under her belt.



Det var en gang…



Disse fire ordene, i akkurat denne rekkefølgen, er gjenkjennelige for de fleste av oss. De skaper en umiddelbart forventning om hva som straks følger. Helter og prinsesser. Troll og hekser. Nederlag, seier og halve kongeriket. "Bare en fortelling til. Pliiiis. Ta den om den grønne votten. Så mååå du fortelle om Askeladden", kommanderes det fra de minste.



Men hva med oss voksne? Hvilke historier vil vi bli fortalt? Og hvilke forteller vi? Hvor er våre helter og prinsesser? Og hvem stikker av med halve kongeriket, aksjer i firmaet og en ny Tesla? Alle elsker historien om Volkswagen og året de inntok det amerikanske bilmarkedet på 60-tallet, anført av reklamelegenden Bill Bernbach. Litt færre husker historien om Google Wave eller juice og melk-konstellasjonen Dus fra Tine.



Sistnevnte gjør seg kanskje ikke like godt på sengekanten som i pensumbøkene. Men det er jaggu en historie verdt å fortelle, den også.



---



Fire grunner til at historiefortelling er effektivt:



Gode historier etablerer raskere tillit mellom avsender og mottaker.



De gjør folk mer mottakelige for hva du sier.



Gode historier kommuniserer verdier. Hva står du for og hvorfor skal jeg bry meg?



Som et verktøy for læring er historier overlegent. Det er en egenskap de beste foredragsholderne, lærerne og politikerne vet å unytte til det fulle. Og tekstforfattere.



---



Gode historier er universelle



De rører ved noe i oss, uansett hvilken himmelretning vi tilhører, og hvilken epoke du har levd eller lever i, og omfatter alt fra urgamle fortellinger rundt leirbålet, eventyr og sagn til uforglemmelige filmøyeblikk, improviserte fortellinger på sengekanten, fantastiske reklamer og verdenskjent litteratur.

God historiefortelling og retorikk var helt avgjørende for å hjelpe en tyskprodusert bil å etablere seg i Amerika i etterkrigstiden.



__



Gode historier er big business



Ett døgn etter at Disney lanserte sin Plus-tjeneste nådde de 10 millioner abonnenter 👀



https://fortune.com/2019/11/13/disney-plus-10-million-subscribers-free-trial-verizon-stock/







__



Historier speiler samtiden



Fakta: Vi forstår det ukjente gjennom det kjente. Forenklede forklaringer på universets daglige mysterier har vært - og er fremdeles– tvingende nødvendig. For hvis man ikke skjønte hva som faktisk foregikk, var det mye enklere å koble det til den mest åpenbare sammenhengen innen rekkevidde. Lyn og torden, Tor med hammer'n. Menneskets opprinnelse, Adam og Eva. Big bang, Gud. Vant i lotto og hadde på meg den gamle lusekoften etter bestefar? Min nye lykkegenser 🦄



Finurlige koblinger som for meg er en hyllest til hjernens ubegrensede arsenal av fantasi. Uten den hadde verden vært gråsur og bleik.

Skaperne av TV-serien Game of Thrones fikk erfare fansens vrede når historien tok en vending som brøt med karakterenes utvikling gjennom 7 sesonger. Merkevarer opplever det samme med jevne mellomrom når oppdateringer slippes, design endres eller tjenester fjernes. (Valgte et spoilerfritt bilde for sikkerhets skyld)



Snakking ga oss et forsprang



Mennesker har en utløpsdato, men historier lever evig. Historiefortelling er derfor sannsynligvis den mest effektive, og mest utprøvde, måten å videreformidle mening fra et menneske til et annet, skriver Mitch Ditkoff i Huffpost. Historiefortelling stammer fra tiden mennesker satt rundt leirbålet og utvekslet de første, spede forsøkene på en brukbar samtale, for rundt 100 000 år siden, i følge evolusjonspsykologen Steven Pinker. Språk ble et verktøy du måtte mestre for å overleve, på lik linje med å lage ild og bygge våpen. Og da, som nå, var historiene en ettertraktet sosial valuta. For hvem liker vel ikke dem som fanger oppmerksomheten vår med retorikkens usynlige håv?



Instant everything



For hvert teknologiske fremskritt, endres måten vi kommuniserer på. Nye kanaler, nye narrativ. Friendster. En gang i tiden var noveller og føljetong det hotteste man kunne oppleve. Så kom Myspace. Facebook. Instagram. Snapchat. TikTok. Plutselig hadde alle en historie å fortelle. Om kvaliteten på historiefortellingen økte, det kan diskuteres. Mer av alt ble det i alle fall.



Og viktigere enn noensinne ble det å finne folka som mestrer historiefortellingens kunst, de som kan skjære gjennom metertykke vegger av digital støy med verbale piruetter og skriftlig laserpresisjon.

Just as the brain detects patterns in the visual forms of nature - a face, a figure, a flower - and in sound, so too it detects patterns in information. Stories are recognizable patterns, and in those patterns we find meaning. We use stories to make sense of our world and to share that understanding with others.



– Frank Rose, expert on digital culture, editor for Wired

Historiefortelling skjer ikke utelukkende med ord. Når du skriver inn passordet, holder Yetien hendene foran øynene. Underforstått forteller de oss at de bryr seg om vårt personvern.



__



Vi er historiedrevne individer



Veldig kort fortalt: hjernen din liker å gjøre ting enkelt. Den elsker snarveier. Hyller deg når du skummer avisforsidene, trekker raske konklusjoner og dømmer folk basert på stereotyper og rykter. Hjernen din hater komplekse forklaringer, at du utfordrer dine egne holdninger og vil helst slippe enhver form for kognitivt etterarbeid. Hjernen din liker historier for de gjør ting enkelt. Historier er hendelser, fiktive som faktiske, sendt gjennom en retorisk hensiktskvern (les: hjernen) for å bli en fortelling med et formål, å selge noe, forføre noen, vekke latter, overbevise. Også videre. Før du leser videre, se denne reklamefilmen fra IKEA 👇🏻



https://www.youtube.com/watch?v=jU-cori12KU



Fortell det som er, som det er



Ingen liker å bli lurt. Kamuflerte hensikter og påkostede, misledende budskap uten oppriktighet i bånn, kveler tilliten. Si det som det er, rått og brutalt. Eller elegant, vakkert, tydelig, forklarende. Alt ettersom. Historier som vekker emosjoner gjør det lettere å forvalte tillit. På samme måte som tekster som forenkler og oppklarer sikrer lojale og fornøyde brukere. Gode, sårbare og ærlige tekster og historier er god service, god merkevarebygging og god fornøyelse.



Og viktigst av alt



Det finnes ikke ett konkret svar på hvorfor vi forteller historier. Mye viktigere er begeistringen og den endeløse undringen over tingenes tilstand, kommunikasjon som et emosjonelt bindemiddel og hvordan ord endrer adferd.









In communications, familiarity breeds apathy.



- Bill Bernbach, legendarisk reklameguru

En liten historietime. Om historier.

Suspense is and will become a game changer when it comes to data fetching. It changes the way we structure our code, think about loading states and gives a better experience for both the developers and the users' interface.

Yesterday we looked at how Suspense can be used to support code splitting and lazy loading of components. Today however, we are going to look to the future and see what Suspense will become. We will learn more about Suspense for data fetching and what Suspense is really all about: Creating a great loading experience for your app!

Suspense for data fetching

Suspense lets you delay the rendering of parts of the application tree until a condition is met. This condition can either be that an asset is loaded or, soon, that data is fetched. While waiting for the condition to be met, Suspense will render a fallback component instead. This might be a spinner, a loading animation or any other dumb component.

Suspense, as of React 16.6, is only waiting for lazy loaded components or code. The idea of Suspense in the future, is that it does not matter what it is, it can wait for anything – including data. This means that it could also be images or any other thing you fetch asynchronously.

Faster loading time

When we create an application, we strive for fast loading times and a UI the users can interact with as soon as possible. We can accomplish this in apps today, but can we do even better?

As we develop components in need of external data, we usually fetch on render. When the component renders it notice that it is lacking data, witch triggers an componantDidMount() or an effect. We then fetch the data and while we wait, we render a spinner. When we get the data, we render the component again. This render will trigger the child’s loading state and we get a new spinner. It creates a waterfall of data fetching.

With Suspense, we don’t wait for the data to come back. We start rendering as soon as the fetch request is sent. Let’s see how this might look:

The first thing we notice is the resource. I will not go into what this is so for all intents and purposes, let’s call it a store. When read() is called it will return the data or, if the data does not exist, a fetch is triggered.

React goes down the tree to render components. When React tries to render WishList, which is wrapped in a suspense component, WishList will suspend as the data is not yet fetched. React then skips WishList and try to render other components in the tree until there is nothing left to try. In our example, this means that the requests for WishList data and GiftTable data will go in parallel instead of a sequence as it would have done without Suspense. As our components are suspended React will find the closest suspense component above it in the tree and show the fallback as it waits for the data.

Percieved performance

Your application might load as fast as it possibly can, but if the users experience a bunch of intermediate loading states and UI parts jumping around on the page as more content appears, your application will seem slower than it is. This is perceived performance.

As mentioned, with the waterfall method of data fetching we often see today, we can trigger multiple different loaders all over our page. When one spinner is replaced with actual content another one might be displayed. Our components to replace these spinners can also be shown to the users seemingly at random depending on the response time. The user might get content on the lower part of the page before the content on the top. If we haven’t allocated fixed spaces for this content to appear in, an element the user has started interacting with can suddenly move down the page. This is a perfect situation for Suspense to save the day!

If you use Suspense to handle your loading state while you fetch you can minimize the number of spinners. As a suspended component will look for the nearest Suspense above it in the tree for the fallback to render, you can place Suspense farther up, wrapping multiple components that, in the user’s mind, fits together. The users will then hopefully see fewer loaders and a more holistic loading state.

SuspenseList

Another way to control how your user perceive your loading state is by using SuspenseList. Let’s look at an example again:

In this example, we have no control over the order these components are displayed to the user. One way of insuring that GiftTable is not displayed before WishList is to wrap them in the same Suspense component. However, this means that you must wait for the data response of both WhisList and GiftTable to display either one. What we do instead is to add SuspenseList.

SuspenseList controls the order the closes Suspense components appear in, independent of the order of the fetch responses. The property revealOrder makes the children appear in the same order as in the tree by setting the property to "forwards". It can also make all the children be displayed at once or in the opposite order as in the tree by setting the revealOrder to "together" og "backwards" respectively.

With the tail property set to "collapsed" you can also tell Suspense to only show one fallback component at the time instead of both in this example.

useTransition

As Caroline Odden mentions in the article about Concurrent Mode we can also wait a given time before we do a page transition with useTransition(). This is especially helpful in a page transition where we have a lot of data to be fetched. Read more about useTransitions in Stop… Render Time!

Developer experience

Suspense has the added perk of not only enabling us to make great user experiences, but also great developer experiences.

The fact that we can remove the loading states from the component itself gives us more readable code and less boiler plate. This also means that you can easily add more control over a component or less, by adding a Suspense parent or putting it further up the tree. It is so flexible and it gives developers more time to focus on how the users experiences the applications loading states.

Not enough

Even though this was a long article, it was quite a superficial walkthrough of Suspense for data fetching. I recommend spending more time learning about Suspense. Why don’t watch the keynote from React conf 2019 on your way to work or read the great material posted by React you find below.

Can you feel the Suspense?!

Sealed classes in Kotlin are a concept close to enums that we are used to from other languages. While enums are used to represent a set of values — sealed classes are used for representing restricted class hierarchies. This means that each type have to be within a limited set of values and can have several instances containing state. This gives us the possibility to make more expressive data models.

Declaring sealed classes

To declare a sealed class — put the sealed modifier in front of the class name. Note that a sealed class can have subclasses, but all of them must be declared in the same file as the sealed class itself.

To illustrate this, let's look into a simple example. In this example we are doing a payment with different payment methods:

Each of these payment methods have different requirements for input data. When handling a CreditCard payment we need a token and expireDate. A DirectPayment however only requires a phoneNumber.

As we can see here, each of the values have to extend the sealed class PaymentMethod. Every type defined inside PaymentMethod, might have their own state, extend state from PaymentMethod or they can even be an object with no state at all.

Utilizing the when expression

The real power of sealed classes can be seen using the when expression. As described earlier, there is a restricted set of possible types when defining sealed classes. This restriction makes it possible for the compiler to warn you if you are not handling all possible outcomes in the when expression.

In the following example we are trying to process a payment:

This code will not compile. Can you see what's missing in the processPayment function?🤔

As you probably could see, we didn't handle all possible outcomes of PaymentMethod. Let's add the missing type DirectPayment to the processPayment method:

The above code will now compile since all possible values of PaymentMethod is handled inside the when expression.

Another important benefit we get from using when expressions, is smartcast. When the paymentMethod matches one of the is statements - we can use the object directly without the need for explicit casting.

Summary

Sealed classes gives us a new tool for creating cleaner and better data models. By utilizing sealed classes with the when expression, the compiler will also help us to handle all possible values. Even though this sometimes might feel cumbersome, it will definitely make the code more solid and more maintainable.

Sealed classes

Når vi surfer på nettet i dag er det meste av trafikken kryptert. Bruksstatistikk fra Google viser at ca. 90 prosent av nettstedene som lastes i nettleseren Chrome lastes over HTTPS. Selv om mye av innholdet vi laster opp og ned over internett er beskyttet, er det fortsatt mye annen informasjon om internettaktiviteten vår som er tilgjengelig for uvedkommende.

Så å si all aktivitet på internett starter med et DNS-oppslag. Formålet med DNS er å oversette lesbare domenenavn, f.eks. bekk.no, til en IP-adresse som brukes til å opprette en forbindelse til en annen datamaskin. Disse oppslagene sendes som standard i klartekst, noe som betyr at andre enkelt kan lese og endre denne trafikken. Det betyr blant annet at:

Regimer som ønsker å begrense innbyggernes tilgang til informasjon bruker det til å blokkere DNS-oppslag på utvalgte domener.

NSA og andre etterretningstjenester rundt om i verden utnytter dette i sine angreps- og overvåkningsverktøy.

Amerikanske internettleverandører kan logge DNS-oppslag og selge informasjonen til tredjeparter.

En angriper kan returnere en annen IP-adresse enn den faktiske for å sende brukere til en side kontrollert av angriperen, kjent som DNS-kapring. I 2011 ble iranske innbyggere sendt til en falsk versjon av Gmail som antakeligvis ble brukt til å overvåke e-postene deres.

Hvordan kan vi beskytte oss mot disse problemene? Internet Engineering Task Force har standardisert to protokoller for sikker transport av DNS, nemlig DNS-over-TLS (DoT) og DNS-over-HTTPS (DoH). Begge protokollene baserer seg på offentlig-nøkkel-kryptografi for sikker kommunikasjon, men opererer på forskjellig nivå i nettverksstakken. DoT baserer seg på at man oppretter en sikker tilkobling mellom klient og tjener vha. TLS på en kjent port, 853 som standard, og sender vanlige DNS-meldinger over denne tilkoblingen. DoH bruker HTTPS for å kryptere kommunikasjonen og benytter en egen mediatype for å sende DNS-oppslag og -responser. Et typisk DoH-oppslag ser slik ut:

Standarden spesifiserer ikke hvordan man finner IP-adressen til DoH-tilbyderen (cloudflare-dns.com i dette tilfellet), men den kan f.eks. inkluderes som en del av konfigurasjonen eller hentes vha. et tradisjonelt DNS-oppslag.

Den viktigste forskjellen mellom protokollene er at DoT separerer de krypterte DNS-forespørslene til en egen port, mens DoH-trafikk ikke er mulig å skille fra annen HTTPS-trafikk. De som er mest opptatt av personvern foretrekker derfor DoH, mens de som mener at det å kunne oppdage og beskytte nettverk mot ondsinnet aktivitet er viktigere, foretrekker DoT. Du kan lese mer om dette her.

Stadig flere DNS-klienter og -tilbydere implementerer disse standardene, men i skrivende stund er man fortsatt avhengig av å aktivt konfigurere kryptert DNS på enhetene sine selv. Det er i ferd med å endre seg. Firefox har allerede begynt å rulle ut DoH som standard for amerikanske brukere, mens Opera og Chrome har annonsert eksperimentell støtte for DoH i kommende versjoner av nettleserene.

Utrullingen av kryptert DNS som standard er kontroversiell. Nettleserene kommer til å benytte en innebygget liste av DoH-tilbydere og dermed ignorere de vanlige DNS-innstillingene i operativsystemet. Det betyr at internettleverandørers foreldrekontroll omgås og bedrifters mulighet til å detektere og hindre uønsket nettverkstrafikk begrenses. En annen bekymring er at DNS-trafikken sentraliseres hos kommersielle selskaper i USA, noe som hverken er bra for personvernet eller robustheten til systemet.

De som forsvarer DoH sier at «DNS-verden» kan takke seg selv fordi de så langt har mislyktes i å tilby kryptert DNS. Nettleserene har dermed ikke noe annet valg dersom de skal gi brukerene sine sikre domenenavnoppslag innen rimelig tid. Electronic Frontier Foundation deler bekymringene angående sentraliseringen av DNS, men sier samtidig at fordelene utveier ulempene og at sentraliseringseffekten kan reduseres ved at nettverksoperatørene selv tilbyr kryptert DNS.

Til tross for kontroversene blir begge standardene stadig mer utbredt. Noen av de mest brukte nettleserene tester som nevnt ut DoH, mens DoT ble inkludert i Android 9. En oversikt over implementasjoner blir løpende oppdatert her. Selv om det er uenighet om hvilken standard som er best, virker det i hvert fall som om det er bred enighet om at kryptert DNS er et viktig steg i retning av en tryggere internetthverdag.

Kryptert DNS

When creating a website, you are trying to solve some real-world problems. People don't come to your site to look at the website. There might be exciting content or important information they need. Often the information they need is copied into some other application.

The following table contains some cells that are easy to copy, and some that are a bit harder to copy.

For the next few minutes, we will explore how we can make all the cells with data easy to copy for most of the browsers in use today!

User select:all;

By adding some CSS to the table, we can make all the text in the cells are selectable by a single click. This solution currently works for Firefox and Chrome.

The CSS we have added to the table is:

When you click on some content in an element with the style user-select: all;, the browser knows it should treat all the content as one atom. This styling lets the user click anywhere in the element and get all of the text selected.

Let us see how this works in practice:

Cursor

When you click on any of the content in cells, all of the cells are selected. But we do not communicate this to the users at this point. We need some way to let the user know in advance what is going to happen when they click on the text. By adding the style cursor: cell; to the cell, we let the user know the content of the cell can be selected.

‍

Polyfill-ish

We now have a solution that lets Chrome and Firefox users understand that they can select the content of a cell, but we want to support the rest of the internet too.

First, we add a class to the elements we want to be possible to select by only clicking on the element.

Then we add the following polyfill to be loaded at the end of our document.

The final result should work for most browsers.

It is nice to know we can do a lot without having to rely on libraries :smiley: Some CSS and a bit of JavaScript goes a long way. It is also lovely to see that a simple solution can bring much value to your users, but you have to make sure they are communicated clearly!

Gotta Select'em all

First of all, this is not a Git article. This article will give a short introduction to a set of trees almost as powerful as Christmas trees: decision trees.

In this article we will briefly go through what a decision tree is, and reasons for why you should be using these trees.

In short, decision trees are models used in the field of machine learning to predict the value of a target variable based on multiple input variables. Some machine learning techniques are hard to learn and near impossible to fully understand - decision trees on the other hand can be really simple.

We will start off with a super short description of the structure of a decision tree model. The first gray circle at the top is called the root node, this is where we start. The rest of the gray circles are just called nodes - except the ones at the bottom, without any preceding nodes, these are called leafs. Take a look:

Decision trees can, as already pointed out, be simple and straightforward. Let's make the simplest possible tree, and let's use it for predicting if guests at a restaurant are vegetarian or not. Try it out:

This machine learning technique is pretty intuitive to work with, you start at the top (root node) and work your way down answering questions. The nodes asks the questions, and in the end the leafs gives us the prediction. Let’s add a question:

In the examples above the trees are only made up of one or two questions, and to be fair, there are many different types of decision trees and some of them can be complex and less intuitive to work with. That said, regular decision trees do not need to be a lot more complicated than this. At first one could think trees are too simple to handle complex problems, yet, with more nodes this technique can be surprisingly powerful.

However, trees are not always convenient. With lots of data and features, trees can be huge. They are also prone to overfitting. They get too familiar with training data, and when a real data sample is pushed through the tree, the slightest difference can send you down the wrong track and into a wrong classification. Let’s say you ask the question above at a seafood restaurant. The guests might not be vegetarian, but asking if they ate beef here will get us nowhere.

This is where bagging and boosting comes in. These techniques fall in the category: ensemble learning/models. An illustration of bagging and boosting is found below. These are techniques that utilize many weak models to create a stronger one. In other words: ensemble methods combine several decision trees to produce a better prediction than a single tree. Two well known tree based methods that use bagging and boosting respectively are Random Forest and XGBoost. But how can many trees be better than a single tree? Lets focus on bagging. Bagging is simply making a lot of similar models and use all the predictions from these models to give a more accurate result. As we mentioned in the section above, single regular decision trees are prone to overfitting. To fight this we use some simple techniques like: preventing the tree from growing too large, only split on a small random set of features, or train on only portion of the training data. When doing this the trees are less likely to memorize the training data. However, when making hundreds of random trees like this we are more likely to catch edge cases. We ask all our random trees what they think this specific restaurant guest ate, and the class with the most votes wins! All these random trees are called, you guessed it, Random Forest.

Many machine learning techniques are like a black box. For example, in neural networks, we have no idea what conclusions the neural network drew. That's not the case with trees. We can easily visualize the decision, that's just the nature of the trees. By starting at the top and answering questions on our way down, we can see and understand each small decision made up by the tree. It's difficult to get lost, just follow the branch out of the tree. I would say it's easier to get lost in Git branches than in a decision tree.

Lost in branches?

In this article I will give a brief overview of what a monad is. Later articles in this series will use monadic features in different programming examples, therefore I thought it would be a good idea to first give an overview of what a monad is. I will use metaphors to explain the concept, and I will not give any code examples in this article.

You're using monads!

I'm sure most of you are already using monads, even without knowing it. You see, monads are hidden behind various names in different programming languages. Promises, Tasks, Maybes, Optionals, and Lists are all examples of monads. :exploding_head:

Some context

A monad is a concept that belongs to a branch of mathematics called category theory, where it was introduced in the 1960s. It wasn't until the 1990s that monads were found useful in programming. In category theory, a monad can be defined like this:

Definition 1. A monad over a category C is a triple (T,η,µ) where T : C → C is a functor, η : idC → T and µ : T2 → T are natural transformations such that:



µA ◦ TµA = µA ◦ µTA\ µA ◦ ηTA = idTA = µA ◦ TηA

This is probably pretty incomprehensible if you're not familiar with category theory. Luckily it is not needed for understanding and using monads in the context of programming. I just wanted to show the formal definition before moving to the more tangible way of talking about monads in the following section.

Useful metaphors

To understand monads, either you have studied category theory or not, we need to concretize them with metaphors. We simply cannot think about such abstract concepts without introducing some sort of metaphor. In this section I will explain one of the most common metaphors for monads, namely a monad as a container.

A monad as a container

A monad can be seen as a container around some value, along with operations on that value. Concretely, in programming we can think of a monad as a datatype with two operations: >>= (pronounced bind) and return.

A little simplified, >>= takes a container with a value inside, applies a function to the value, and puts the new value back in the container. return takes a value and puts it in a container. One concrete example of a container monad is Maybe. Maybe is a datatype that either contains a value (Just x) or it is empty (Nothing). To do operations on a Maybe value, we must first check if the value is present or not. This makes it tedious to compose operations on a Maybe, as we need to unwrap the value for every step. This is where our monadic friend >>= comes in handy, as it lets us compose functions on monadic values, such as Maybe, effortlessly.

Rounding up

Was this all a little too fluffy to grasp? I agree, therefore I recommend checking out this awesome visualization of how we work with monads in programming. I hope this gave you a little intuition for what monads are, and that it helps when they return in later articles.

And remember, a monad is just a monoid in the category of endofunctors, what's the big deal 😉

5-Dec

Today's posts