Mondays. Mondays may be the time for contemplation and relaxation after the first working day of the week. However, Mondays may also be a good time to find your favourite position in the sofa, lean back and learn talk skills from others presenting. This blog post introduces talk analysis as a tool to be a become a better presenter yourself.

Talk analysis

Without even thinking about it, we are always continuously analysing when others are presenting to us. And when we present ourselves, we often tend to be our own greatest critics. However, in the group in Bekk behind this calendar, that focuses on presentation and dissemination, we have found that a more structured approach to talk analysis comes in handy when learning the best ways to present.

Structure the learning

Not much is needed in order to structure (and enhance) the analysis of a particular talk. For example, it may be as simple as writing down a sentence or two afterwards Some different examples:

What was the main thing you learned? What was it that the person did that made you remember exactly that lesson so well?

Underway in the presentation, write down 2 things that was particularly good, and 2 things that can be improved.

You may also take notes during the presentation along various dimensions:

Body Language - How did the presenter use his/hers body language? Did it have something to say in terms of your learning?

Pitch of voice - How did the presenter utilize his/hers tone/pitch of voice?

Speaker's style - Does this specific presenter have a particular style? What is your style?

Remedies - Do the person use a physical object to underpin his/hers arguments? Are they using the audience actively?

Analysis of each others

There is a lot of different kind of talks you can analyse! You may analyse the next american inaguration speech in January, a lightening talk at the next Javazone, or even a presentation in your team. In Bekk's competency group for talks, we have found it useful to lower the bar and give each other feedbacks, and provide your own analysis after you have listened to your colleagues present. Focus on what the person did well, and give a pointer towards what the person can focus on in the next presentation. Just remember to ask first if it's OK that you give your feedback.

Try it out for yourselves!

If you have some left over time during this monday, find a talk/presentation/speech that you remember as great, and perform a short and sweet analysis of your own. It's quite fun! If something doesn't comes to mind, you can find links to good sites for talks below.

And who know, maybe we posts some of your analysis during December? 🎅

Recreational talk analysis

A type class is a construct that defines a set of behaviours that can be adapted to different types. Unlike inheritance, the implementation of the behaviour for a type is decoupled from the definition of the type. In this post, we'll walk through an example that demonstrates this in Kotlin.

Lets use the example of finding the sum of something, like integers. From the standard library we have the sum function that can be applied to lists, listOf(1, 2, 3).sum(), resulting in 6. The sum function is implemented in the standard library as an extension function on Iterable:

Say we wanted to sum a list of java.math.BigDecimal, listOf(BigDecimal(1), BigDecimal(2), BigDecimal(3)).sum(). This does not compile because the function sum does not exist for BigDecimal. We could define it like the following code snippet, which is exactly the same as the implementation for Int except from swapping Int with BigDecimal:

To avoid repeating this implementation for all the types we want to sum, let's try creating an interface Addable so that we can make the sum function generic for subtypes of Addable:

The Addable interface has one function plus, adding two instances of T and returning the result.

Using the Addable interface, our sum function on Iterable would look like this:

One problem with this implementation is that we do not know how to represent the initial value for sum, namely zero. This is a problem when the iterable is empty, so we'll have to change the return type from T to T? and return null if the iterable is empty.

A second problem is that we cannot make BigDecimal extend our new Addable interface - or any other types that we use from other libraries. So to make this work for BigDecimal, we'll have to make a wrapper that can extend Addable:

This does not seem to be an ideal solution, whereas duplication of the function for different types will make it more convenient to use. In fact, the function sum is duplicated for Byte, Short, Int, Long, Float and Double in the standard library. However, let's try to redefine our Addable interface to a type class:

It is still an interface, but we have defined the plus function as an extension function on T since we do not intend for the interface to be inherited by T as in the previous version of the Addable interface. We want to decouple the behaviour of Addable for the type T, from the implementation of T.

Since the implementation of Addable for a type T will be decoupled from the implementation of T, we may add singleton behaviour to the type class, i.e. behaviour that is not related to a specific instance of T. That makes it possible to deal with the null issue from our previous implementation of sum with inheritance, by adding the function zero to the type class.

This is how the implementation of sum could be, using the Addable type class:

In this version, we provide an instance addable of Addable<T>. The variable sum is initialized to addable.zero() so that we do not need to worry about null when the list is empty. In the for-loop, we wrap the sum operation inside a block of addable.run, making Addable<T> the receiver type which makes the extension function plus available for instances of T.

To make it more convenient to create instances of the Addable type class, we can add a function instance to its companion object, taking the two functions zero and plus as parameters, and returning a new instance of Addable:

Now, it is easy to create an instance of Addable for BigDecimal:

Which can be used like this:

There is a proposal to enable compile-time dependency resolution with a new extension keyword to define instances of interfaces, and mechanisms to retrieve those instances by the with keyword. These changes could make it more convenient to use type classes in Kotlin in the future. For the above example, by enabling invocation of sum() without providing the type class instance of bigDecimalAddable().

If you found this short introduction to type classes in Kotlin interesting, you should definitely check out the Arrow library, which implements a number of type classes.

Type Classes

Azure has been growing rapidly in the enterprise in recent years. But its app services offering, which is the most important service for developers, is still mediocre. Kubernetes is, in my opinion, the only viable alternative for running applications in Azure. This blogpost explains how I came to that conclusion after roughly 6 years of working with Azure.

Azure, the expensive cloud

Users are forced into buying “Premium tier” to enable key functionality such as VPC/VNET integration:

Need API Management with virtual network connectivity? Must pay premium tier, monthly fee + consumption.

Need Functions with virtual network connectivity? Must pay premium tier, monthly fee + consumption.

Need a service bus with virtual network connectivity? Must pay premium tier, monthly fee + consumption.

Need a WAF with virtual network connectivity? Must pay premium tier, monthly fee + consumption.

I could continue the list with Azure AD, Redis cache, and so on, but you get the idea. This is not how the cloud was supposed to be, this pricing model simply does not scale.

VPC & Virtual networks

Accessing or running services inside a VPC / Virtual network is incredibly difficult and expensive. There are 3 ways to achieving it and they are all bad:



Application Service Environment (v2)

Slow

Limited in terms of functionality

Expensive.



Private Endpoints & regional VNET integration

Complicated to set up and maintain

Expensive



IP Source Whitelisting

Complicated to maintain

Not as secure as other solutions

Some resources don’t have static IPs

Consequently, many organizations choose to ignore that exposing databases directly to the internet is not recommended and simply run all their services without any virtual network. Authentication is then the only layer of security protecting those resources.

Automation & Infrastructure as code

Many years ago, I worked with the Azure Classic deployment model (sometimes referred to as ASM) where automation was extremely limited. In 2015, I switched completely to Azure Resource Manager (ARM) deployment model with PowerShell and JSON templates. Now, five years later, infrastructure as code is still a struggle for Azure, click-ops seems to be a standard approach for many organizations.

The tooling (ARM templates, PowerShell, Azure CLI, and now Biceps DSL) is just not good enough. I recommend everybody to adopt Terraform which has much better readability and modularity. In fact, Microsoft uses terraform to create and share landing zones (i.e. infrastructure blueprints) with customers and partners: https://github.com/Azure/caf-terraform-landingzones

Azure support

There are no words to describe how bad it is.

Stability & performance

Things have gotten better with the years, but I’ve still experienced 2 major disruptions of service in 2020 where Microsoft was unable to provide a clear root cause analysis. Here is one of them (App Services):

Upon investigation, engineers discovered one of the workers that your site was running on was unable to download the AAD Open ID configuration that is required for the feature to function. When it cannot download this configuration, the component returns 500s, as it has no way to safely authenticate the users. Unfortunately, this specific failure to download the configuration happens very rarely in our platform, and we have been unable to reproduce the issue for further investigation.

This is not what people expect when they pay for PaaS.

Kubernetes, hallelujah!

First and foremost, yes, Kubernetes is complex. But, some of the complexity can be abstracted away by using a managed Kubernetes service such as AKS (Azure Kubernetes Service).

AKS is fairly new and not the best on the market, but it solves the majority of the problems I’ve talked about in this blog post. AKS is getting full attention from Microsoft while App Services are stagnating. On top of that, Kubernetes benefits from a rich ecosystem supported by a vibrant community and a number of commercial companies.

I hope to have convinced you that Kubernetes is the only viable alternative for running applications in Azure.

👋

Can Kubernetes save Microsoft Azure?

A brief introduction to Reanimated 2's worklet directive and how it can help us animate our apps.

Reanimated has been part of the React Native ecosystem for quite some time. Popular libraries like React Navigation depend on it. What it does is it gives developers the opportunity to write and run animations on the UI-thread, making the dream of a constant 60 fps not too distant at all. The downside of Reanimated is its quite difficult-to-learn API. For instance, a simple calculation like 10 + 8 * 4 would be written as add(10, multiply(8, 4)) , and to be frank that is a fairly straight forward example. But this is all about to change with version 2 of Reanimated, currently in its first release candidate. In this version you write JavaScript. But fear not in regards of performance, the brilliant people of at Software Mansion, who are developing this, has granted us our very our JavaScript context on the UI thread to make sure that we won't be affected by potential obstacles our "normal" JS-code might be throwing out there.

Other than us being able to write our animations in JS and with a very slick new API, we are also introduced to a few new concepts within the Reanimated sphere. One of these concepts being worklets.

Worklets, you say?

Really, a worklet is a JS function we define in our code that that gets compiled at runtime to be executed on its own JS-thread, far and away from React Natives own one. Defining a worklet is as easy as using the "worklet" directive when writing a function, like so:

Let us pretend for a second that we have an animation that we want to clamp as it's raging all over the place. And we decide that this is a perfect use-case for a worklet. We could make a rather naïve version that looks like this:

And to use this in our animation we write:

You might not use worklets too frequently while writing Reanimated 2, as quite a lot can be achieved within the hooks provided by the library itself. Software Mansion themselves even mentions this here. However, there are definitely use-cases for when to use them and I've found myself to write a fair few of them while developing apps.

Now we'll have a little peek into William Candillon's amazing toolbelt for Reanimated: Redash, which I can't recommend enough by the way. Here we'll see a fair few examples of worklets to make our day a little easier:

This is just a neat little function to convert radians, which you might be used to work with if you've previously been using Reanimated 1, into degrees. And again, the upside here is that we do write JS as we usually do, but it runs on a separate thread.

Or we can take a look at a slightly more advanced example:

Here we interpolate colours. I'm not going to go through the entire thing, but you can if you want to. But the three things worth noting are the processColor, interpolateColorsHSV and interpolateColorsRGB functions, as these are in fact also worklets. Meaning that worklets can depend on each other and share information between one another.

In conclusion, worklets are neat little helper functions to assist you while animating in Reanimated 2, without having to worry too much about performance. Granted, it's not bullet proof, but his way harder to mess up here than in regular JavaScript country.

Finally, with Reanimated 2, the verbose way of writing animations is long gone and the learning curve to implement awesome interactions has never been lower. Go ahead, give it a try, I can almost guarantee you won't regret it.

What and why and how are worklets in Reanimated 2?

The new version of ECMAScript, ES2021 is expected to be released in June 2021. What new features can we expect from the new release? This article covers some of the features in the upcoming release, and how we can put them to use.

String replaceAll()

This is perhaps the feature I am most excited about. With the old approach, in order to replace all occurrences of a substring, the method replace() combined with a global regular expression has been the way to go. However, with the new method replaceAll(), we can easily return a new string that replaces all instances of a pattern without the use of complicated regex.

This method also comes with a performance improvement as it uses string comparisons instead of regular expression matching.

Logical Assignment Operator

The Logical Assignment Operator combines Logical Operators ( &&, ||, ??) with Assignment Expressions (=).

The code example below shows this feature in use on the operators AND (&&), OR (||) and the Nullish Coalescing Operator (??) as well.

In the example below we have the variable money. Using the nullish coalescing operator, the defaultValue is only applied if the variable is undefined or null:

Using the Logical assignment operator , we get a slightly shorter syntax:

Curious about Operators? Stay tuned, there might be an article about the topic further into this JavaScript Christmas calendar :angel:.

Numeric Separators

Large numbers may be challenging to read with a first glance, especially when there are repeating digits. The Numeric Separator is a useful tool that separates digits with an underscore (_) in numeric literals, thus making numeric literals more readable. The separator can be used in different positions, with as many separators as you want, in groups of any size.

As we can see, the code becomes a lot more readable. Numeric separators also work for octal integer literals

Promise.any()

In short, this method is the opposite of Promise.all(). Promise.any() takes an iterable of promise objects, and resolves if any of the supplied objects resolves. It returns a single promise, the first one to resolve, with the value from that promise.

Consider the example below, we create three promises which we feed into Promise.any().

If none of the promises resolve, then a new type of exception, the AggregateError exception is thrown. AggregateError groups together individual errors into a single error in the form of an array of objects. Pretty neat!

Want to know more about promises? Visit this article from the 2019 Christmas calendar.

WeakRef

In JavaScript, references to objects are strongly held. This means that as long as a reference to the object exists, the object will not be garbage-collected but keeps the object in memory.

In scenarios where we do not want to keep objects in memory indefinitely, the WeakRef (Weak Reference) can be used to implement caches or mappings to large objects. When not in use, the memory can be garbage collected and generate a fresh cache when needed again.

A WeakRef is created using new WeakRef, and the reference is read with .deref().

JavaScript is continuously integrating new features, and today we have looked into some of the features coming in JavaScript ES2021. For more information on proposals, and what´s coming next, take closer look here

Whats new in ES2021?

In my experience Functional Programming (FP) can be something that is hard to get your head around. This is particularly true if you're very set in your ways from working in another paradigm. In this short read I hope to explain my journey up the FP mountain, as well as detailing some of my obstacles along the way. While the main goal of the writing is to re-inspire people with disappointing prior experiences, I also hope it will create a spark of curiosity for first timers.

I still remember the day I first heard murmurs of functional programming. Just to set the mood, it was during my early days at university. We had this one co-student who was ridiculously far ahead of the rest of us when it came to actual programming capability. He had gotten himself mixed up in a fiery debate with another student on the topic of programming paradigms.

As anyone that has at least spent some time roaming the more primitive sides of the internet can attest, there is nothing more vicious than watching two developers argue over their pet preferences. Be it vim vs emacs, programming languages, version control systems or even source code indent style, these digital wars show no mercy.

Still curious, but afraid to interject, I quietly looked up functional programming for myself. To my shock and horror, I was met by an onslaught of jargon that bounced squarely off my head. Monad, Side Effects, Lambda, Currying, Purity, etc. Some words even seemingly imaginary.

Thoroughly put off, I slowly crawled back to my cozy and safe imperative den. It would take another two whole years before I even attempted to conquer this mountain again.

What is a Pie?

My second attempt, even being firmly handheld by the once fiery co-student was not without growing pains. Why was it I suddenly felt I needed help learning functional programming and not other paradigms? After having given it some thought, there were a couple reasons that came to mind. They can mostly be cataloged in two separate categories: the human and the paradigm specific.

One of the big paradigm specific issues is that some other paradigms just map more naturally to how we humans think. We usually perform tasks as a series of steps. To conceptualize my point let’s imagine a recipe, say we’re making a pie. Most recipes follow the same formula of listing the ingredients that we need at the top, much like we list variables at the top of classes in object-oriented programming. Then we have a step-by-step guide where we prepare and combine the ingredients, much like methods in a class.

A functional cooking recipe however would look more like this:

A pie is 45 minutes of 400F heat applied to 200g of final pie dough.



100g of final pie dough is a mix of 99g of pie dough stage 3 and 1g of salt.



99g of pie dough stage 3 is a mix of 79g of wheat flour and one egg.



(...)

This formula is not very useful when we only want to bake a pie once in a while. It would be very useful if we wanted to become career bakers, or maybe even build a baking factory. This form of a pie recipe forces us to think hard about the pie and define exactly what a pie is at any stage of the production (this is very zen-like).

If we used a traditional imperative recipe like described earlier and tried to flesh out the pie-making details, we would probably focus on splitting the process into more and more granular tasks and it might deteriorate to irrelevant questions like, "which hand do we use to add salt?"

Jargonitis

Another big reason is the wall of jargon mentioned earlier. Haskell for example, can at times seem purposefully convoluted. Being built by academic scholars, explains some of the jargon. That would be fine if in many cases it didn’t feel like it was built purely for academics as well. While Haskell’s high abstraction allows you to write some very cool generic code, it often also makes it harder to conceptualize.

Luckily for you readers there are several languages that don’t require a PhD. Some nice go-to’s not laden with jargon that helped me on my journey are Elm, Kotlin and Scala. I've also seen people recommend Scheme or other LISP derivatives, but the prefix syntax can be weird for humans. You also run the risk of getting caught in a sea of parentheses.

Fundamentals

Besides some of the paradigm specific issues outlined, I also feel some hindrance occurs at the personal level. At the time of my second attempt I had spent the last 3 years of my intellectual spare time learning to program. After which I felt like I had at least started to gain a modicum of mastery. Boy, how wrong I was... Being faced with FP again I was back to square one, a complete noob so to say.

Even being fully aware of my relative inexperience, I decided to go in head first on a concurrent threading assignment for a networking class. This is not to say FP is not equipped for concurrency, it is actually in many ways very suited for concurrency. Attempting it with no prior knowledge of syntax or concepts however, is an experience I would not wish on anyone.

Learning to walk before you run is an expression that had completely vacated my mind at that point. In retrospect this is a pitfall I have always tried to avoid. As in the wise words of Michael J. Jordan,

You can practice shooting eight hours a day, but if your technique is wrong, then all you become is very good at shooting the wrong way. Get the fundamentals down and the level of everything you do will rise.

Accustomization

Another part of the issue I had was that I had in many ways been indoctrinated in the OOP way of thinking. I already had biased ideas of how certain problems should be solved and would often bang my head against the wall trying to solve issues the OOP way.

This was a bad approach in hindsight. Instead of mapping my thought process to what I already knew, I should have followed the FP method without too much comparison. Please think back to when you first learned to program, you had no preconceived notion of how problems should be approached, you just did as you were told (metaphorically speaking).

This blank slate approach let you freely digest the information without too much questioning. It's also in this blank slate approach I'd recommend you to take when approaching functional programming.

Key Takeaways

My venture into the FP world was not plain sailing. It did however give me some guiding principles whenever trying something new from that point on. Always begin by mastering the basics and always approach it with a blank slate. This is not to say you shouldn't be inquisitive. Asking questions is good, but it can also at times be counterproductive if it's not from the right state mind. It has to come from a place of "I want to know why", and not "I want to do something else entirely".

Besides the general advice of learning to walk before you can run and following a blank slate approach, I do also have some more specific advice related to functional programming. I'd avoid or at the very least be wary of languages suffering from jargonitis. The ones already mentioned all have a healthy-sized community, and the availability of nice books and tutorials to help you get started. I do have to point out that some of these do have an imperative fallback. Just be aware of this when trying to learn Functional Programming.

Now after having gone through some of the more concrete tips, my final advice is to please be open and ask yourself: what is a pie?

Overcoming the FP hurdle

Have you ever realized how important text is in the digital sphere? It’s impossible to avoid text, whether you are to read an article, search for information, watch a video, or complete a task. In fact, it is estimated that about 95 % of the internet is text (1). This vast ocean of text states the need to welcome everyone to read, interpret, and understand - regardless of their abilities or disabilities. If you design or develop digital content, you have a responsibility to do so. And I’m here to help!

Web accessibility aims to include everyone - to the best of their abilities - in the digital world. If you’ve ever stumbled upon WCAG 2.1 or other frameworks or guidelines for accessibility, you might have noticed that it's often about text. It might be about typefaces, fonts, visual appearance or hierarchy, or about code and what’s happening “behind the scenes”. This article aims to give you some clues about what makes typefaces and texts legible and readable. More specifically, the emphasis is on how to make text accessible for those who are able to receive textual content through their sight – e.g. those who can read without the help of screen readers.

Side note: There are ways to facilitate “reading” for people who are e.g. partially or completely blind, as well, but this is outside the scope of this article. I do, however, strongly recommend that you research this topic also!

Legibility and readability

I must admit that I for a long time believed that legibility and readability were synonyms. So, before we move on, some clarification is necessary. Readability refers to the text’s overall accessibility. In other words, how easy it is to read/receive a chunk of text. Legibility, on the other hand, refers to how easy it is for the reader to decode and differentiate individual letters in a word. I will refer to both terms in this article.

The design of legible and readable typefaces

The letters in a typeface should be clearly distinguishable

Clearly distinguishable letters in a typeface make it easier for the reader to decode a word within a sentence. In the examples shown above, it is quite clear which letters are distinguishable and not. The most common examples of similar letters are I and l (i.e. a capital i and a lowercase l). Helvetica, Arial, and Gill Sans are all popular and common typefaces. However, their legibility is weakened due to this problem. Even if there is a slight difference in the thickness and height of the two letters, these differences are so small that most of us struggle telling them apart.

The letters in a typeface should be airy and open

When using airy and open typefaces, the reader is less likely to perceive each letter as a blurry, closed shape. A dense C can for example be mistaken for being an O. “Impact” is an example of a typeface that has a low degree of airy- and openness. In general, such typefaces do best in large sizes and short sentences, e.g. as headlines.

The letterforms in a typeface should have an adequate internal contrast

Slight differences in a letter’s internal contrast - i.e. different thickness throughout the letter - make it easier for the reader to recognize its shape. The letterform becomes more unique, which strengthens the typeface’s readability. In the given examples, it is clear that the internal contrast should be neither too big, nor too small. Didot is an example of a typeface that has a high degree of internal contrast. It works well in large formats but is difficult to read in smaller sizes. Newzald on the other hand works pretty well in both sizes.

The letterforms in a typeface should have an adequate general contrast

Even though thin or light fonts can make your design seem minimalistic, clean, and airy, they do not promote good readability. Light and ultra-light fonts are usually difficult to read as they have too little contrast to the background. However, too much contrast – i.e. black or heavy fonts – results in a low degree of airy and openness (see point number 2), which again lowers legibility. Balance is key.

The design of readable texts

Contrast

The contrast between the text color and background color is important to promote readability. Too low contrast can make the text difficult to see. Too much contrast can strain the eyes and lead to fatigue (for example 100 % black text on 100 % white background). The latter especially goes for texts that you read over an extended time period.

Luckily, guidelines such as WCAG 2.1 provides us with a standard. The contrast ratio should be at least 4.5:1 for small-sized text and 3:1 for large-sized text. Text from 18 px and larger are considered “large text” (2).

Line length

Line length refers to how many characters there are per line of text. In general, shorter lines are the easiest to read, as too long lines can be tiring for the eyes. The longer a line of text becomes, the longer our eyes have to track the text horizontally. This makes it harder and harder to keep up with the vertical process of switching between lines when you read. In the end, you might lose track of where you are within the text. But then again, too short lines are tiring as well, as it makes you switch vertical focus too often.

Keep your line length between 45-75 characters per line (including spacing) (3).

Line-height

Line height is the spacing between each line in your text. If the line-height becomes too small, the text can become cramped and blurred together. If it’s too big it is easy to get lost.

Line height is usually set as a percentage of the text size. Generally, the preferred line-height is about 150 % of the text size (3). So, if you have text that is 16 px, you could set your line-height to 24, which is 150 % of 16.

Alignment

How you choose to align your text affects its readability. In general, there are two types of alignment styles you should avoid.

The first is justified text: when the spaces between words or letters are stretched to make the text align both on the left-hand side and the right-hand side of the text column. Justified texts usually have many unnaturally large spaces and “rivers”. This lowers readability. Furthermore, it is easier to navigate a text when the right-hand side is uneven (as it is when you use “flush left” alignment) because each line has its individual length.

The second is centered text: when the text is symmetrically aligned along the axis in the middle of the text column. You should first and foremost avoid this because it is difficult to see where a new line starts. When there is no permanent start to a new line the reader can easily get lost in the paragraph and lose focus. Because of this, centered text does best in headings or short paragraphs.

Conclusion

As you can see, many factors influence the accessibility of text. If you are lucky enough to work with a design system, many of these guidelines are likely a default part of the components you work with. However, it is always good to bear in mind these guidelines and that you have a commitment to make digital content receivable and understandable. Easy measures can make a lot of difference for your users, whether they are visually impaired, stressed, dyslexic, tired, color blind, distracted or so on. Good luck!

Digital typography and accessibility

Zero Trust is a security model where each component has its own perimeter. This is different from a traditional security model where all components inside of a given perimeter are regarded as safe or trusted. It was introduced as a reaction to the traditional network security model as a measure against lateral movement after a breach.

In Zero Trust Networks by Evan Gilman, Doug Barth, a Zero Trust network is defined as a network built on five fundamental assertions:

The network is always assumed to be hostile

External and internal threats exist on the network at all times

Network locality is not sufficient for deciding trust in a network

Every device, user, and network flow is authenticated and authorized

Policies must be dynamic and calculated from as many sources of data as possible

The core of Zero Trust is to "never trust, always verify", closely related to the principle of least privilege, stating that any user, program, or process should have the bare minimum privileges necessary to perform its tasks. In order to make sure that an application works well in a Zero Trust environment, we need to minimize the risk of lateral movement by isolating potential data breaches as much as possible. In the context of application development, these five assertions can be summarized into the following guidelines:

Treat all hosts as if they are Internet-facing (assertions 1-3)

Delegate authentication and authorization to a supporting system (assertions 4-5)

Given that all hosts are regarded as Internet-facing, we need to ensure that all communication channels are secure, even if they were at some point regarded as internal. This means that we should encrypt all internal and external network traffic that we don't want to expose, including (but not limited to) traffic between applications and databases. This will make it difficult for an attacker to snoop traffic, even if he or she has gained access to an internal network.

By delegating authentication and authorization to a supporting system (control plane), it is possible to enable centralized access auditing and policy enforcement based on selected criteria. This means that we don't need to create complex logic to verify devices and users in each application as it will be handled by the control plane. In a more practical sense, we should opt for federated identity combined with standardized authorization protocols like OAuth 2.0. In modern web applications, it may be worth looking into JWT to represent claims securely.

Regardless of which authorization method you choose, make sure that each client that is granted access will be given its own account. Never share credentials between services or users. One account per client makes it possible to remove access if one client is compromised, and makes it possible to trace traffic back to a single source when investigating an incident, or analyzing traffic in general.

There are no Zero Trust products. There are products that work well in Zero Trust environments and those that don't. — Palo Alto Networks

That should cover the basics. If you would like to dive deeper into the subject, I highly recommend Zero Trust Networks by Evan Gilman, Doug Barth.

Zero Trust for application developers

With Elm's strong types, we must be precise when writing our business code. Precision is a good thing, but it often has the drawback of being verbose. Ad hoc tuples can save the day with clear and precise syntax!

A typical case is when you need to check multiple values. Let's say the user has chosen a size and optional color name for their product:

And we want to put a suitable text in their confirmation dialogue:

Instead of indenting away into these nested case-expressions, a common trick is to use an ad hoc tuple combining the two values into ( size, color ). Notice how clear this make the outcomes of each case:

Or consider if this if .. else expression for the email adress of a fictional company:

This can be more consisely expressed with case .. of on a tuple:

Don't topple the tuple

Before we run off with our newly acquired hammer and see a world of nails, beware that tuples in Elm are intentionally restricted to maximum three members.

The reasoning is that if you combine more values than this, you are probably better off with a proper data structure like a record where the fields are named. This is a strong restriction, but all the good kids will get the gift of clean readable code.

Simplify your code with ad hoc tuples

Det legges mye penger i tiltak som skal bidra både til innovasjon i seg selv og til økt innovasjonsevne for bedriften. Men gjøres det innovasjon, eller er det mest teater? Og hvordan kan man unngå teateret?

Se for deg at du jobber i et tradisjonelt selskap. Forretningen surrer og går, men nye selskaper, produkter og tjenester popper stadig opp og truer det etablerte. Valget står mellom å «innovere eller dø». Ledelsen hiver seg rundt. Vegger rives, og der det før var cellekontorer finnes det nå beanbags i spreke farger, palmer, whiteboards og post-its. Innimellom kan man også se folk i lokalet. Da har noen gått inn i kalenderen og booket dette rommet, som kanskje heter «Innovasjon» eller «Kreativitet». De skal ha workshop, og det skal innoveres.

Rommet er ikke problemet. Det er kjekt å ha rom tilrettelagt for kreativt arbeid. Problemet er når det man kaller innovasjon kun skjer i dette rommet, og hverken før man går inn i rommet eller etter man har forlatt det. Når den gode idéen henger igjen på tavlen eller gjemmes bort mellom to sider i en notatbok, da driver man ikke med reell innovasjon, men med innovasjonsteater. Jeg synes Marte Gråberg får fram poenget godt i sin innovasjonsbuzzordliste, der hun beskriver innovasjonsteater som «Å etablere en innovasjonslab med gule og blå puter, VR-briller og shuffleboard, for deretter å rapportere til styret at vi er i gang med innovasjonen.»

Jeg tror ikke bedrifter bevisst driver med innovasjonsteater. Innovasjon er ønsket, og ledelsen forsøker så godt de kan å legge til rette for innovasjon; men tiltakene strekker ikke alltid til. Det kan være flere grunner til det, men jeg mener mange selskaper har forbedringspotensiale på spesielt to områder: 1) Tydelighet rundt hvorfor man ønsker innovasjon, hva man legger i ordet innovasjon, og hva man forventer, og 2) tilrettelegging for innovasjon gjennom organisering, måling, belønning, ledelse og kulturbygging.

Retning og rammer for innovasjon

De som har tatt del i kreative prosesser eller idégenereringsøvelser vet at det er vanskelig å komme opp med gode idéer uten å ha et utgangspunkt. Kreativitet kommer ikke ut av det blå; men fordi man kjenner på et behov som ikke er godt nok dekket, eller man opplever et problem som man ønsker å finne en løsning på (se også forrige luke om hvorfor riktig problemdefinisjon er viktig for nyskaping). Vi arbeider gjerne mye og lenge med å forstå kunders behov og problemer, men bruker vi nok tid på å forstå selskapets behov og problemer, og hvilke av disse vi bør løse?

Min opplevelse er at smidig produkt- og tjenesteutvikling kan gå på bekostning av strategiarbeid. Jeg mener ikke at smidig er feil og at vi skal tilbake til produktbestilling, men sier som Ole Brumm: Ja takk, begge deler. Etter min mening er det helt nødvendig å forstå selskapets ambisjoner før man setter i gang innovasjonsinitiativer, fordi det både gir retning og rammer for arbeidet: Hva ønsker vi som selskap oppnå? Hva skal vi være? For hvem? Og hva skal vi ikke være?

No Isolation skal bidra til mindre ensomhet. De kunne sikker videreutviklet roboten sin til å bli resepsjonist i et hotell, men i stedet har de laget et nytt produkt til en ny målgruppe der isolasjon og ensomhet er et problem. reMarkable kunne bygget inn e-post og meldingstjenester i sitt skrivebrett, men de skal bidra til bedre tenkning og har derfor valgt bort sosiale medier eller andre distraksjoner.

I tillegg til å være bevisst hvor man vil med selskapet, kan det også være verdt å stille seg spørsmål om hva man legger i ordet innovasjon. Skal det være radikalt? Inkrementelt? Nært kjerne? Helt nytt? Er det ok å foreslå en helt ny forretningsmodell, eller er dagens forretningsmodell «urørlig» og noe man må holde seg innenfor? Dette er ikke bare viktige rammer for innovasjonsarbeidet, men også for å kunne designe en organisasjon og strukturer som legger til rette for den typen innovasjon man ønsker.

Organisering for innovasjon

Hvordan man bør organisere seg for innovasjon henger sammen med hva man ønsker å oppnå. Altså retningen og rammene for innovasjon. Så langt har jeg ikke sett noen selskaper som gjør innovasjon helt likt, men jeg forsøker meg likevel på en grov inndeling av typiske organiseringer for innovasjon, og noen fordeler og ulemper knyttet til disse:

1. Innovasjon i linja

Kan passe dersom området du ønsker å innovere på er nært kjerne og krever dyp domenekunnskap. Dette krever imidlertid at de ansatte gis rom til å drive med nytenkning og innovasjon; men min erfaring er dessverre at mange ledere tar for lett på dette og tenker at innovasjon er noe man kan gjøre «innimellom» eller på kveldstid (på sin egen fritid!). Noen vil påstå at linja ikke er egnet for mer radikal innovasjon, fordi man sitter så «inne i boksen», men mange innovasjoner kommer nettopp fra mennesker som har sittet i linja, som kjenner materien godt, og som har lurt på om man ikke kan gjøre dette bedre, enklere, raskere. Men, fordi disse ikke får rom til å utvikle idéen tar de den i stedet med seg ut av selskapet og starter opp for seg selv – og selskapet går dermed glipp av innovasjonsmuligheten.

2. Innovasjon i autonome team

Et autonomt team skjermes i større grad fra daglig drift, slik at de ansatte får rom til å utforske et behov eller problem. Teamet skal ikke være større enn at de kan dele to pizza, og når de samtidig skal ta de fleste beslutninger selv blir det ekstremt viktig at teamet innehar den kompetansen som trengs innen design, teknologi, forretning og domene. Men, en fare når teamet er lite samtidig som de forventes å levere nye løsninger raskt, er at det går på bekostning av hvor bredt man søker etter nye løsninger og hvorvidt man faktisk evner å lukke dører underveis. Det kan være lett å forelske seg i den éne idéen, og det å lukke dører blir enda vanskeligere dersom selskapet ikke har en kultur hvor det å "feile" er både akseptert og forventet. Jeg har tidligere skrevet en bloggpost om smidig organisering der du kan lese mer om viktigheten av en utforskende om menneskeorientert kultur, og du kan også lytte vil våre Drypp-episoder om psykologisk trygghet.

3. Innovasjon i egen enhet

For at ansatte skal få tid til å drive med innovasjon velger mange selskaper å etablere en egen innovasjonsenhet eller «lab». Denne kan være innenfor eller utenfor selskapet, og må som autonome team bemannes med kompetanse innen design, teknologi, forretning og domene. I tillegg har man gjerne egne personer som er gode på prosess og metode for innovasjon, og anledning til å involvere andre fra organisasjonen ved behov. Innovasjonsenheter har gjerne mulighet til å utforske mange idéer i et hurtig tempo, og til å forvalte en mer balansert portefølje av idéer og initiativer enn det et autonomt team har ressurser til. En fare med innovasjonsenheter er imidlertid dersom ideér og konsepter «overleveres» til linja for realisering; så her gjelder det å tenke gjennom hvordan idéer skal tas videre, av hvem, og hvorvidt ressursene i enheten skal være faste eller mer fleksible. For et praktisk eksempel kan du lytte til vår Drypp-episode om hvordan Storebrand har rigget seg for innovasjon.

Avslutningsvis ønsker jeg å gjenta det som ble sagt innledningsvis: Organisering av innovasjon avhenger av hva du ønsker å oppnå. Bruk tid på å finne ut av dette først, så tror jeg sjansene for å lykkes med innovasjon og unngå teater er langt større!

...

Lurer du på hvorfor jeg nesten bare har skrevet om organisering, og ikke om måling, belønning, ledelse og kultur?

Du kan lære mer om måling i vårt blogginnlegg om OKR for å lykkes med smidig produktutvikling og høre om hvorvidt OKR er for toppstyrt på Drypp.

Du kan lese om hvorfor du ikke bør glemme kultur i en krevende hverdag på bloggen vår, du kan høre om kultur og OCAI på Drypp, og vi vil også komme innom kultur og lederens rolle som kulturell arkitekt senere i denne kalenderen.

Du kan lære mer om innovasjon ved å lytte til hele 24 luker om temaet på Drypp nå i desember!

Hvordan unngå innovasjonsteater?

Når bør man begynne å tenke på å beskytte verdiene man skaper i et innovasjonsprosjekt? Og hvordan går man frem?

Pia Solheim, Fredrik Matheson og Jens Andreas Huseby i samtale med Joakim Marstrander som jobber med IPR og innovasjon som partner i EY.

7-Dec

Today's posts