One of the pictures below is of a group of labradoodles. The other is of a bunch of fried chicken. Which is which? While this is an easy problem for most people, this was for a long time considered a virtually impossible problem for computers. Most traditional programming takes an input, performs a series of well defined steps, and produce some desired output. But what are the steps of recognizing a dog or a fried chicken?

When we recognize a dog or a piece of fried chicken, we don't go through a series of explicit steps. We have simply been exposed to enough dogs and pieces of fried chicken to know the difference. This is an important feature of learning: an ability to generalize from experience.

Rather than experience, we often speak of data. A machine learning program is first trained on a large amount of data and then it attempts to generalize the data in a way that can be applied to new situations. When trained, the program can be used to solve problems in the same domain as the training data.

There are three broad categories of machine learning: supervised learning, unsupervised learning and reinforcement learning.

In supervised learning, the program is trained using labeled data. Consider the problem above: A program is exposed to tens of thousands of pictures, labeled as being of either dogs or of fried chicken. Based on this, it develops some model of what a dog and a piece of fried chicken looks like. When exposed to a new image, it should be able to correctly identify it.

Unsupervised learning deals with unlabelled data. Typically, the program identifies patterns in the data. As an example, a streaming service may wish to segment their customers based on viewing habits. By having an algorithm look at which movies different customers rate highly, they may identify clusters of customers with similar interests, and use this to recommend movies they are likely to enjoy.

Reinforcement learning is learning by doing. The program, in this context referred to as the learning agent, attempts to solve some problem and adjusts its behaviour based on feedback on its actions. Game AI is often trained this way. A chess program might learn by playing games, first playing random moves and gradually learning to prefer moves that lead to victory and avoid those that lead to defeat.

The specific algorithms used are numerous, from traditional statistical methods predating the idea of artificial intelligence to algorithms inspired by the working of the human visual cortex. All of them are based on the same principle, however: real world problems are often too complex for neat, explicit step-by-step solutions, and are better solved by observing the world and identifying patterns.

What is Machine Learning?

The dire second level consequences of choosing a private PaaS...

For several years our advice has been to adopt managed cloud services from the global cloud vendors. However, many organizations in our market, especially in the public sector, are establishing on-premise private PaaS or CaaS platforms, usually based on Kubernetes or OpenShift. Although these platforms are superior compared to the previous generation of platforms, we claim that this approach is probably a disservice to the organizations. Let us explain.

The disadvantages of the private PaaS are well known. Infrastructure is acquired and operated in-house, not leveraging the cost and utilization factor benefits of the public cloud. In-house operations are not able to match the availability, scalability, security, robustness, observability, etc. of public cloud platforms. Additionally, they cannot match either the breadth of services or the innovation pace in the cloud. These disadvantages alone should be more than sufficient to not go down the PaaS route.

However, the main reason for warning against the private PaaS is more dire and obscure: For most organizations, the private PaaS will serve as a pretext for not adopting the public cloud. Management will be happy, “✔ we are in the cloud”. The IT Operations department, a heavy stakeholder in this discussion, will be happy; they move into the center of the organization (and they have even more work to do now to operate the old platform and the sparkling new platform). Even a few developers will be happy, as they get to develop, deploy to and operate a new platform while playing with new technology.

Looking into the crystal ball for the next few years, we see too many of these organizations still stuck on their private PaaS. The final nail in the coffin is that establishing a PaaS demands a lot of brainpower, and the best people will be allocated to this task. However, only a few organizations will have the capacity to succeed in this endeavor; the rest will end up with a half-baked, inconsistent platform. Meanwhile, little attention is used on moving to managed services in the public cloud.

Choosing a private PaaS is your decision. It does not have to be this way.

Private PaaS considered harmful

In case you haven't noticed: Passwords suck. Fortunately alternatives to that age-old authentication scheme are finally becoming practical. Today we will look at SQRL (Secure Quick Reliable Login), which aspires to become the simple and secure solution for your every-day authentication needs.

SQRL was originally invented in 2013 by Steve Gibson (these days best known as host of the podcast Security Now!). Over the past few years a lot of work has gone into making SQRL ready for the world. The specification was recently finalized, and several client and server implementations have been developed, making now a good time for curious developers to start experimenting with this promising technology.

SQRL uses public key cryptography to securely authenticate a user to a web site with minimal fuss, and without the user having to memorize or manage a multitude of passwords. It is based around the central premise of using a single master identity - the user's SQRL Identity - to predictably generate unique identities for every web site that the user authenticates to.

This is how logging in with SQRL works from a high level:

The user's web browser requests the web site's login page.

The web site presents a "Log in with SQRL" link on its login page, pointing to a SQRL URL like this: sqrl://www.example.com?nut=X7Kyfz9xr8jLt4aB9xQF. That "nut" parameter is a nonce, uniquely generated every time the login page loads.

The user clicks/presses that link on her PC/phone. This launches the local SQRL client app (or browser plugin), which receives the SQRL URL, including the nonce.

The client app takes the domain of the URL and runs it through an HMAC function, keyed by the user's 256-bit Master Key, to produce a site specific public/private key pair. Given the same domain, this procedure will always produce the same key pair. The public key serves as the user's identity for the site. It is how the site will know the user.

The client app uses the site specific private key to cryptographically sign the SQRL URL (including the nonce). The client then sends that signature to the web site server, along with the public key, ie. the user's site specific identity.

The server identifies the user by the provided public key, and uses this public key to verify the provided signature. A valid signature proves that the client is in possession of the associated private key. This securely authenticates the user's identity to the site.

The web server establishes a signed in session for the user and sends the URL for that session to the user's SQRL client.

The SQRL client receives the session URL and redirects the user's browser to the signed-in session.

The above image borrowed from the SQRL documentation nicely illustrates how SQRL generates site specific identities from the site domain name and the user's Master Key.

This relatively simple concept provides us with many desireable characteristics, most notable of which are:

No secrets to lose: Since the web site knows the user only by the site specific public key, which can in no way be used to infer the matching private key (let alone the Master Key), SQRL gives web sites no secrets to keep. Unlike a username and password, the public key alone can only identify a user to the particular site, not authenticate. So if a site gets breached and all its data is exposed, there is nothing there that will allow an attacker to impersonate a legitimate user.

Powerful anti-spoofing: Unlike traditional browser sign-in, the web site does not authenticate the browser session which initiated the sign-in process. Instead a URL to the new signed-in session is returned securely to the user's SQRL client app, which then redirects the user's browser. This effectively prevents man-in-the-middle and web-site spoofing attacks.

Privacy: Like password based authentication, but unlike federated authentication (such as "sign in with Google"), SQRL is strictly two party. No need to let Google and Facebook know which web sites you have registered an account with. Additionally SQRL produces a unique identity for each site the user authenticates with, which is in no way traceable back to the user's main SQRL Identity, nor any other site specific identity for another site.

No password management hell: Since each site specific identity is synthesized from the web site domain and the user's Master Key, the user only needs to remember one strong master password, which is used to locally unlock the SQRL client app and decrypt the Master Key, which resides in encrypted storage within the client app. Also a SQRL client app could use the device's TPM module to encrypt/decrypt the Master Key, allowing for the use of fingerprint readers and the like to make unlocking the SQRL client app even more frictionless.

All these benefits also put some responsibility on the user. Since the Master Key resides in the SQRL client app on the user's phone or PC, the user must take appropriate precautions to protect the SQRL client app on her device. If the user's chosen master password (which is used to encrypt and decrypt the Master Key) is not sufficiently strong, this of course weakens the overall security of the system. Also since there is no third party to turn to for help, the user must make sure to backup her SQRL Identity in case she loses her device. Fortunately this is easy to do. The SQRL Identity (ie. the 256-bit Master Key) can simply be printed in encrypted form as a QR code and/or human readable text on a piece of paper for offline storage. Importing the SQRL Identity into the SQRL client app on a new device is as simple as scanning a QR code or entering a bit of text. Encryption by the master password is preserved. But what if you forget the master password? Well, for this case you have the Rescue Code, which is generated when you first create your SQRL Identity. It absolutely must be stored in a safe place, as it can rescue you from pretty much any bad situation imaginable.

Now I hear you say: What about FIDO2/WebAuthn and hardware security keys? Some web sites have started to offer support for passwordless authentication using FIDO2 hardware keys. This offers similar security properties to SQRL (in some ways arguably better), while also being very simple to use. A major downside is difficulty of backup. The private keys are locked inside the hardware and cannot be accessed in any way. Thus the only way to do backup is to add multiple security keys to every web site you use. This can quickly become a maintenance nightmare. Locking up the keys inside the hardware does provide superior security at face value, but at a considerable cost of convenience. This cost may be too high for most users, which means that they must keep alternate (and less secure) authentication methods active as fallbacks, arguably negating the most important benefits of using security keys in the first place. It may be that SQRL strikes the security/convenience balance better.

It remains to be seen if SQRL will get enough traction to make a dent in the dominance of passwords, but its security properties and ease of use are certainly compelling, and importantly: It is completely free and unencumbered by patents and intellectual rights. It is simple to implement SQRL support on the server side, in no small part due to the excellent documentation. Additionally SQRL authentication will happily coexist with traditional authentication methods on your web site. You can trivially allow existing users to add a SQRL identity which will be linked to their account, making for a smooth transition into a more secure future.

SQRL Client apps are available and in development for Windows, Mac, Linux, Android, iOS, as well as browser plugins. Server libraries exist for .NET Core, Java, Go and more. There is even a Wordpress plugin.

To learn more and try out SQRL for yourself, check out the links below. The documentation actually makes for a surprisingly engaging read!

Secure Quick Reliable Login (SQRL)

Hva er gevinstene med å levere kontinuerlig? Er kontinuerlige leveranser risikabelt? Vil brukerne egentlig ha det? Og er det noe alternativ?

Hvorfor driver vi med kontinuerlige leveranser?

In his book, Serious creativity, Edward De Bono presents his knowledge from more than 50 years of research on creativity. In it, he presents creativity as a skill that can be taught. The following are some of the key takeaways from the book.

The definition of creativity

We all have perceptions, concepts, and boundaries, creativity is about challenging these. Creativity is about breaking patterns and giving us an alternative approach to logical thinking in pursuit of solving problems. With creativity, we move beyond what is and into what could be.

Misconceptions

We have many misconceptions when it comes to creativity; some of these are:

"Creativity is something you're born with; it can't be learned."

"You have to be artistic to be creative."

"Creativity is crazy and illogical."

"Creativity requires particular conditions."

These represent a narrow, incomplete view of creativity and are holding us back. Take the last quote as an example – the thought that certain conditions make you creative is not entirely wrong. Everyday hassles can inhibit us from being creative. But by eliminating them, it can become more comfortable to be creative. Conditions are, therefore, not a prerequisite for creativity. Neither is "being artistic." It would seem that many see creative vs. logical as two extreme traits on an identity spectrum and would, therefore, identify as logical over creative.

Logical vs. creative thinking

Logical Thinking

Creative Thinking

To find the difference, we first need to know a bit about how the brain works. The brain is a self-organizing information system. That is, it collects and organizes information on the fly. Previous knowledge as well and the order of new information affect how this new information is stored.

Knowing this shows that our concept of "logical thinking" is fragile. In logical thinking, we start with a problem and navigate the information we have about that problem until we find a solution. This usually is efficient as we have solved similar problems before, but when there are new problems, we might get stuck in limiting patterns.

Creative thinking helps us break free from these patterns and navigate our knowledge in different ways. By using techniques such as "random input" and "provocation" we can change where we start our thinking process and therefore end up with other solutions than we could by logical thinking.

Creative techniques

Then how do we break these limiting patterns? There are many techniques we can use to trick our minds into thinking creatively, including "Provocation" and "Random Input".

Provocation

Provocation works similarly to random input. By providing a provocation that might seem illogical, and taking the time to think about the implications of the provocation, you can come up with ideas outside of our usual patterns. This can be thought of like 30 seconds of madness.

Let us try it! We are getting close to the holidays. What about:

PO: we do not buy each other presents this year

Does that statement sound like madness? A bit. Let us see what we can come up with if we accept this for 30 seconds and think about what effects it could have.

Ideas:

Maybe we could buy ourselves presents? We know what we want and need and can spend our own money on it.

Maybe we could make stuff for each other?

What about spending the money we would have used on presents on a trip instead?

Or maybe give it to a good cause?

Or use it on the house/car/other big things we need fixing

Or invest it so the money can grow for a few years and be used as part of mom and dad's retirement?

We could probably go on for some time. Just be accepting the provocation and trying to figure out how it could affect our lives instead of resisting it, we can come up with new ideas that might bring value as they are. Or we can find a middle ground that is more realistic.

Random input

Random input is a method where a list of random input, usually words, but photos could work too, is collected and shared one item at a time. The person ideating thinks of a problem and uses the random input to affect the ideas they generate. The random input helps you break the logical patterns you are used to following and forcing you to take detours through other topics that might seem unrelated but can spark new ideas.

How can we use this in practice? Let's say we want to give someone a present and are stuck. We can then create a list of topics related to gifts.

It can look something like:

Sports gear

Activity

Clothing

Necessities

This list could have been more random, but as we are are looking for gifts, this should be enough. By writing down 5 ideas or as many as you can come up with for each word, you should be able to come up with a few ideas that should solve your need.

Ideas:

Football

Bike

Going to the movies

Laser tag

Sweater

Socks

Shampo

Applying some of these techniques and the knowledge that creativity is just a way of thinking lets us see more solutions and, therefore, often solve problems better. Creativity challenges let us our perceptions, concepts, and boundaries. Our understanding of creativity affects how we use it. Knowing creativity is a skill that can be taught and used in serious situations enhances our options when solving problems.

Key takeaways from Edward De Bono’s "Serious creativity"

Custom properties doesn't look like much, but is one of the real super powers of CSS. Let's see what it's all about!

I'm currently working on a client's design systems team. It's a lot of fun. We have the opportunity to implement something completely from scratch - and it's been a blast. This presented us with the option to play with the power of the so-called dynamic properties of CSS - and see how they can be used to improve the readability, maintainability and flexibility of the system.

What are custom properties?

CSS Custom Properties - or CSS Variables as everybody still calls them - is a fun new way to specify a value once, and use it throughout your code base. And since they're just CSS, they cascade down the tree of HTML, and can be overridden at any point. They are specified like this:

and are used like this:

Another way you can think of them is like named arguments to your selectors, that can be overridden from the outside.

But with great css custom property comes great responsibility - but how could that power be wielded for good? How about in a design system?

Get to the :root of the issue

The first thing we did, was to specify the custom properties on the :root level. For most purposes, it's the same as html with a higher specificity score.

We wanted to specify the most basic of properties - the background color, and the text colors. Just for funs, let's specify them in primary, secondary and tertiary pairings:

Then, we get to use these to specify our typography colors:

Woah - that's a lot of syntax for something we could've done with a pre-processor like SCSS - where's the payoff?

The sweet, sweet payoff

The payoff comes whenever you want to create something that breaks with this initial design. Let's say you want to specify a pop-out section of your site that wants extra attention. How can we implement this?

Previously, we'd have to specify a new set of classes with a new set of colors on it. Now, we just need to change the custom properties!

Let's create a new class popout-section that looks extra delicious:

Now, if we wrap our previous classes in this class, we get the updated values automatically, with nothing else required!

This is an incredibly powerful pattern that can create some really nice-looking effects. In addition, you barely add a byte to your CSS, and your code is still super-readable.

Theming

With a nicely thought out group of global custom properties in your arsenal, global theming becomes a case of a few lines of code. We can use the same technique as before, but place our modifier class on the <body />-tag for example.

We simply change the values of our custom properties, like so:

That's really all there is to it. Since we're using the custom properties in the rest of the code, these will be updated automatically.

Preferred theming - also known as dark mode!

Most sites doesn't have the time or need for several themes - but since iOS 13 came out, dark mode has become really popular. Implementing it is now as easy as a single media query!

Just remember that you also need to change the values in lower-level overrides, like the .popout-section above. Otherwise, it's smooth sailing.

Bonus tip - use with inline styles too!

Sometimes, we just want to play around with values, or perhaps we want to set them dynamically with JavaScript. In those cases, it's nice to know that you can specify css properties through the style prop in HTML as well!

But what about IE?

Always the party pooper, Microsoft's black sheep Internet Explorer 11 doesn't support CSS properties. It's not a problem for my current project, but it will probably be for you.

PostCSS to the rescue! This CSS post-processing tool lets us use the initial values as the default, if it isn't supported. It's added by adding this plugin to your PostCSS config.

Use them today!

CSS custom properties is an incredibly powerful addition to the language that polyfills nicely and can do wonders for your codebase.

If you want to dig in deeper, I suggest you start watching the talk and article linked below. Both are amazing deep dives that turns you into a CSS custom property wiz in an hour.

Switch it up with CSS custom properties

Contributing to Open source often requires a healthy dose of inspiration. By following accounts on Twitter that focus on the subjects that the most matter to you, you might find the inspiration you seek.

We have compiled a short list of some of the accounts that we follow. Hopefully they'll inspire you too!

Developers

@dan_abramov (Co-creator of Redux, JavaScript)

@davidfowl (ASP.NET , Roslyn)

@kentcdodds (JavaScript/frontend),

@khellang (Web, Open source activist)

@selbekk (React influencer, JavaScript/frontend)

@housecor (React & JavaScript)

@yegor256 (Software development & architecture)

@baeldung (Security, OAuth, software development)

Foundations

@owasp (Open Web Application Security Project (OWASP) is a worldwide not-for-profit charitable organization focused on improving the security of software.)

@OpenSourceOrg (Global non-profit that promotes and protects open source software, development & communities through education and advocacy)

@linuxfoundation (Non-profit organization enabling mass innovation through open source)

Podcasts and communities

@ThePracticalDev (Posts from the dev.to community and the general life of a developer, with a healthy dose of humour)

@avdtechpodcast (To improve the dialogue between ‘ed’ and ‘tech’ through storytelling, for better innovation and impact)

@osintpodcast (Open Source Intelligence (OSINT) podcast - news related to social media, data privacy, open source intelligence, investigative journalism as well as tools and resources to improve your research.)

Open source on Twitter

Architecture in Functional Programming (FP) and Object Oriented Programming (OOP) is very different. While the class is the main abstraction in OOP, the function is the abstraction in FP. Looking over the fence, it seems impossible to solve problems using the other paradigm. In order to learn how to design program with functions, we must first learn how they work in FP as a function is not the same as a method.

This is not intended to be an in-depth introduction to functions, but rather show how a few features works together that allows us to build larger functionality based on smaller building blocks.

I'll use F# to show the concepts here. Not all languages works the same way, but a lot should easily transfer to your functional language of choice. F# is a functional-first, multi-paradigm, programming language for the .NET platform.

The syntax highlighted blocks in this post might be immediately followed by a block with non-highlighted evaluation of the preceding example. This is the same result you would get if you typed the block in the read-eval-print-loop (repl) manually. You can follow there examples by using fsi.exe on Windows or fsharpi on *nix operating systems.

A block of source code like the following:

Might be immediately followed by a block like the following, which shows the result of evaluating the code block.

Let's dive in with a small example. We'll implement the following pseudo-C# function in F#:

let will bind a symbol to a value or function. Here we bind the name add to a function taking two parameters. The syntax for functions is a lot terser than C#. Parameters and arguments are separated by space rather than comma, and we don't wrap them in parenthesis. The types are also inferred in many cases so you don't have to specify them when it doesn't improve the program. The last expression is also returned from the function automatically.

The type of the function is int -> int -> int, which means it takes two ints and returns an int. A function taking int and string, returning float, would be int -> string -> float.

You might have seen lambdas (nameless functions) in various other languages, and in F#, it's called fun

We can also bind anonymous functions, thus giving it a name.

A function has parameters. The value we "pass in" for a parameter is called an argument. We say that we apply a function to arguments. For the above example, x and y are parameters. 2 and 3 are arguments. We apply the anonymous function to these arguments, thus binding the parameters x to 2 and y to 3. When the last parameter is bound, the function is evaluated.

Notice that this is exactly the same as our first version of add! let add x y = x + y is just a shorthand for let add = fun x y -> x + y.

But I've been lying about this function; It isn't a function taking two parameters at all! It's a function taking a single argument, returning a function that takes a single argument!

This also means that -> is right associative. The type int -> int -> int should read (int -> (int -> int)); takes a single int, returns a function which takes an int and returns an int.

Notice that the innermost lambda fun y refers to the variable x which defined as a parameter or in the body of the lambda. This means x is a free variable, which must be evaluated from the surrounding environment.

But.. If add takes a single parameter, what happens if we call it with a single argument?

This is called Partial Function Application. We're applying the function add to 2, thus binding x to 2 in the environment of fun y. In the fun y lambda, x is no longer free, and it's the same as alsoAdd2 . We say that a function with free variables such as fun y is a closure (closes over its environment).

The process of translating a function from many parameters to nested functions taking only a single parameter is called currying. In languages such as F# and Haskell, this is automatic; all functions takes just a single parameter, and functions taking multiple parameters are just syntactic sugar.

Currying and closures are the main features we need to start creating more complex functions by combining more primitive functions.

Closures can also be used to hide implementation details or state. The following example creates a counter. You can never modify the variable directly.

A common pattern in programming is to process some data in a pipeline without caring much about the intermediate steps.

In functional programming, we can build bigger functions by composing smaller functions.

The strange 'a types are generic arguments, and they will be inferred from the functions you pass into compose. If we don't omit redundant parenthesis, it becomes clearer (a -> b) -> (b -> c) -> (a -> c). "Given a function from a to b and a function from b to c, create a new function from a to c".

compose will first run the first function, and then use the result of the first as an argument to the second function. And this can be nested so we can create arbitrary complex functions compose (compose first next) last.

While this works fine, there's a bit noise in the form of parenthesis and function names. Luckily, F# contains an infix alias for compose.

Composing a set of operations would now be op1 >> op2 >> op3 >> .. >> opN

Another useful function is apply. It's the kind of functions that looks utterly useless, but makes "pipelines" a lot easier to read.

Soooo… Instead of writing f 1 we can write apply 1 f! Profit! But when we consider partial application, apply 1 will create a function that will pass 1 as an argument to any function. This can be used to supply common parameters to functions. apply connection transaction config creates a function that will send those arguments to the functions you apply. apply also has a useful infix version, |>, which shows a common use-case for apply.

This could also be written as

Or even

This concludes our little introduction. We've talked a bit about currying, partial function application, arguments, parameters, closures, compose and apply. There's a lot more to be said about each of these topics, and a whole lot more about functions in general. But this is enough to start exploring how to use functions for abstractions rather than classes.

The F of FP

The ... operator that arrived to javascript with ES6 is really handy, and can be used in quite a lot of situations. Technically it is two different things; a Rest parameter and a spread operator. Let's take a look at how they work.

Rest parameter

Lets say you have an array such as this one:

If you only want the first element of the array, while keeping the rest of the elements in a separate list, you can split the array like this

As you can see, using ...restOfTheNames puts the remaining elements of the list into a new list. This is called destructuring and is handy in a number of ways. It can also be used for objects, like this:

As shown above, destructuring lets us extract the firstName property, while keeping the rest in a separate object.

Finally, the rest parameter is really useful when working with function arguments:

In the example above, firstArgument will contain "Lisa" while the rest argument will be a list containing the rest of the arguments. In this case ["Simpson", "Springfield"]

Spread operator

If the rest parameter was yin, the spread operator would be its yang. It looks exactly the same as the rest parameter, but works a little bit differently.

The spread operator lets us expand elements such as objects and arrays. Lets see how it works.

The operation above "spreads" the withoutMarge-array into the wholeFamily array. And the resulting array will contain all the names ["Marge", "Lisa", "Homer", "Bart"]. Spreading can also be used to extend objects, like this:

This way of using the spread operator is also handy for overwriting properties in existing objects.

Technically, using the spread operator to extend and overwrite parts of objects actually creates new objects, which means it can be used instead of the old and cumbersome Object.assign() API. If you want to copy an object, you can just do this:

In summary, the ... operator can be used either as a rest parameter, or a spread operator. The rest parameter lets us gather array elements, object values, or function arguments into a single variable, while the spread operator lets us expand them to multiple variables.

Hopefully this article showed you some useful examples, happy coding!

How ... works in Javascript

The promise of Concurrent Mode was made at a conference in 2018. The React team claim that this famous new feature would help with the issues with rendering, allowing to pause the render when the need to do more important tasks should occur. Let's take a closer look!

The concept of Concurrent Mode is not a new revolutionary feature, but for React it creates some nice new opportunities. Even though most React applications are fast, you often stumble across some issues with slow rendering. If you have triggered some sort of list update or other CPU-intense task, and you want to go on with your life, it's not always that easy. If your device is busy rendering an exceptionally big list, it will not be able to give feedback for other events before it's done. To make an analogy, imagine you have that one friend that only talks and talks, and you never get possibility to say anything. That's rendering - and it blocks even though you have more important stuff to do!

The Concept of Concurrent Mode

As I mention in the introduction, the concept of Concurrent Mode is not a new one. Take processors as an example. Processors got a scheduler which prioritizes the most important tasks when a resource is available. The same goes for the JavaScript compiler, but instead of a processor, it has a single thread for user interaction (the UI thread) we have to use wisely. If this thread "freezes" due to work overload, we can't react (pun intended) to new events until the work is done. Concurrent Mode want to prevent this by creating several "mini-threads" within the UI main thread, and with its own scheduler it can maintain the responsiveness.

The User Experience

The once rendering, always rendering problem is sometimes hard to avoid, because even though your application has nice performance, the device the user has may not be strong enough to handle it. Factors as network speed and device capabilities may cause your application to stutter, even though you have done a nice job with throttling and debouncing.

There are some events that you want to happen immediately, for instance hovering over elements or typing into an input field. If your device is busy rendering the list, the hover effect is not visible before it is done with the previous task. And the scroll may freeze(!#$%&). When React begins to render, you can't stop it until it is done. Concurrent Mode will focus on human interactions; simple tasks like hover and scroll should happen instantly, while navigation to new sites and loading new data is more acceptable to be more time consuming (they claim research has shown).

Interruptible Rendering

With Concurrent Mode, the rendering can be interrupted. If the user triggers another more important event, it will pause the rendering and do the desired task, before returning to the original task to finish the job. The degree of what is important is determined by heuristics, to know how to prioritize this new update. It will (hopefully) make your application more responsive!

I don't think you should rely on the fact that Concurrent Mode will solve all you performance issues. However, I think it will be a nice helper in the heavy list-rendering React-applications out there.

Intentional Loading Sequences

It is a common action when you navigate to a new site on your website, and you simultaneously want to fetch data. But it is a little annoying being redirected to a new page with no content or it is just showing some kind of a loading indicator. So what if React could make you stay on the previous page just a little bit longer so you can skip the bad loading state? By doing this you cover the fact that you don't have all the data you need to show right now, and it doesn't feel like an eternity for the user. When the user has triggered an action which leads to a site transition, React can start creating the new page (in memory) and wait before updating DOM until it is ready. And most importantly; the "old" site is still interactive. This feature is not impossible to create today, but with Concurrent Mode it is already built-in!

To be able to create the intentional loading sequences, React offers the new useTransition hook:

The startTransition value is a function, which could be used on the state we want to intentionally load. isPending tells us if the transition is going on! If you put your data fetching inside the startTransition function, it will wait the amount of time you passed as config. This will tell React how long you are willing to wait before showing some output to the user.

Let's take a look at an example where we use the startTransition as an onClick event for a button that should get some asynchronous data when it's pressed:

One feature that occur hand in hand with Concurrent Mode and this transition example, which I have not written about, is Suspense, but we will revisit this topic in a later article!

How to Enable it

Concurrent Mode is yet to be released, but is available in an experimental release tag. Kent C. Dodds has written a post on how to enable it, but the short version goes like this:

To get the version with Concurrent Mode, you need to install this experimental version of React:

Next, to enable it you simply need to make some changes in your entry file, and use the createRoot from ReactDOM:

In addition to be able to use Concurrent Mode, they strongly advise to use Strict Mode, which luckily was written about in yesterday's article!

What Now?

The date for a stable release of Concurrent Mode has not yet been announced, but keep calm and keep an eye on the releases-page for React! Perhaps we'll get a little Christmas present from the React-team? 🙏

Meanwhile, you can enjoy the experimental version (but perhaps not use it in production just yet!).

Stop... Render Time!

One of the most common mistakes of many programming languages is accessing a member of a null reference which results in an exception. Most people have probably experienced getting NullPointerExceptions in Java, or NPE for short. Kotlin's type system, on the other hand, is aimed at eliminating this.

In Kotlin, the type system distinguishes between nullable references and non-nullable references. For example, a String variable cannot be null.

Preferably you wouldn't want to introduce nullability into your code, but sometimes null is inevitable and then it's important to know how to keep your code null safe.

To allow, then, an object to be null, we can declare it as a nullable object by suffixing the type with ?

Now, if you try to access a member of nice, it's guaranteed not to cause an NPE, but since naughty is nullable, if you try to do the same on it, the compiler reports an error.

To get round this we can check whether the variable is null by doing

Or by using the safe call operator ?.

The safe call operator returns the length of naughty if it is not null and null otherwise. You might be familiar with this this type of from other languages like C#.

Safe calls are especially usefully in chains.

This return null if any part of the chain is null.

We can also handle nullable objects using the elvis operator ?:

The elvis operator here returns the length of naughty if naughty is not null or -1 otherwise.

You can also tell Kotlin that a nullable object cannot be null by using the !! operator. This converts any nullable type to a non-nullable type and throws an exception if the value is null

Thus, if you like and want to get NullPointerExceptions, you still can! You just have to ask for it first.

Null Safety

Most developers will at some point be exposed to a dependency injection framework, and at first glance the whole thing can seem magical and hard to understand. Here we'll try to create a conceptual model of how DI-frameworks work.

Disclaimer: Throughout this post we'll make references to the Spring framework. However, this post is not a Spring tutorial nor an explaination of how Spring works.

What is it

Dependency injection (DI) is, at its core, an implementation of the Inversion of Control (IoC) principle. Which simply means changing your classes from creating its own dependencies, to a solution where your classes just requests its dependencies.

Let's look at an example to better understand what we're talking about. Starting off with how classes are wired together in application without a DI framework;

In the example without a DI-framework you'll observe that Controller must have an understanding of how Service is created, and what dependencies Service needs. And in the case where the DAO class suddenly needs a second constructor argument it would require changes to all the classes in the example. We can however make the non-DI example a bit more future-proof by moving dependency instantiation to the Config class;

In small and simple applications this may be acceptable, as introducing a DI-framework also introduces complexity. But as the application grows this Config class may become rather large and hard to maintain. And we're interested in how DI-frameworks work, so let's continue by looking at an example using the fictional library DIY;

It should be noted that this is not the full story, and we'll take a look at what changes were made in order for DIY to understand how the classes should be wired together.

So, how does it work?

At its most basic you can think of DIY as a glorified Map, often referred to as the IoC Container. Populating the map can be achieved in several ways, but we'll focus on an annotation-based approach, e.g using @Bean, @Component, @Inject, etc. @Bean and @Component would be equivalent to map.put, whereas @Inject is equivalent to map.get.

To start we'll look at the lifecycle of DIY, which can be split into three distinct phases: 1. Scanning 2. Instantiation 3. Injection

Scanning

Before anything can happen the library needs to get a concept of which classes the application needs. Spring supports a multitude of options here, but we'll focus on the simplest case; classpath-scanning searching for classes annotated with @Component and a default constructor. To help us in our efforts we'll use a nifty little library called reflections which will help us scan the classpath.

Finding all classes of interest is as simple as:

Instantiation

After finding all classes that the application needs we move on to instantiating these. Since we required all classes to have a default constructor we can simply call Class::newInstance for each of the classes found.

Injection

After instantiating all classes we're left with injecting dependencies where they are needed. All of the classes we found can potentially include fields annotated with @Inject, meaning they're dependent on another class. Hence we need to iterate through the list of beans and connect them together.

We iterate through all beans, finding all fields annotated with Inject and set their value. resolve can be implemented rather straight forward by just finding the first bean which can be assigned to the field-type.

At this point the DIY library has completed its job, and we should now be able to run DIY.get(Controller.class) and receive a instance of Controller with all fields populated by DIY.

Complicating matters

We made a lot of assumptions and made a really scoped down version of what you may expect from a DI framework. Some of the issues include:

Having multiple beans of the same type. There is no way to differentiate between beans of similar types. Spring provides a way of naming your bean; @Bean(name = "my-awesome-controller"), and then requesting that specific bean by using @Named("my-awesome-controller") in addition to @Inject.

Code in the constructor of a bean. Strictly speaking you may create a default constructor and add some code there. But since the bean is instantiated before the injection-phase it will not have the resolved values at that point. Spring's solution comes in the form of the annotation @PostConstruct, which can be added to a method in the class and executed whenever Spring has injected the requested dependencies.

Constructor Injection. Some people prefer constructor injection instead of field injection. E.g allowing classes to specify a constructor with its dependencies instead of annotating every field. This is supported in Spring by simply annotating the constructor instead of each field in the class. For this to work the library needs to instantiate classes in topological order (hence circular dependencies will no longer work).

The @Bean annotation. We did not use the @Bean annotation in our library. Supplementing the scanning phase to support the annotation can be achieved by scanning for all classes including methods annotated by @Bean, instantiate the containing class, and invoking the annotated method.

2-Dec

Today's posts