Ved enhver endringsprosess vil man som initiativtaker ofte oppleve negative tanker, følelser og oppførsel mot endringsinitiativ fra enkeltpersoner eller ulike grupper i organisasjonen. Det oppstår med andre ord endringsmotstand som kompliserer, krever uforutsette ressurser og reduserer fremgangen.

Noen typiske årsaker til endringsmotstand er:

Ja, endringsmotstand er en ressurs

Endringsmotstand er en viktig ressurs for deg som initiativtaker fordi det gir deg svært nyttig innsikt om hvordan du bør gå frem videre med endringen og hvilke problemer som må løses. Snakk med endringsmotstanderne, bruk tid på å forstå deres perspektiv og analyser deg fram til den faktiske årsaken til motstanden. Det vil hjelpe deg med å gjøre treffende justeringene i løpet av endringsreisen og øke sannsynligheten for en vellykket prosess.

Kilder:\ Choosing strategies for change av John Kotter og Leonard A.Schlesinger. Harvard Business Review, 2008. https://hbr.org/2008/07/choosing-strategies-for-change

Kan endringsmotstand være en ressurs?

Most of us use JUnit as our go-to testing framework, often without really considering the alternatives. Are you ready to try something new? Why not give Spek Framework a shot?

Spek Framework is a specification testing framework written in Kotlin. Being a specification oriented testing framework, Spek makes it easy to focus on functionality rather than implementation details when writing tests. Here is a simple example of what a test written in Spek may look like:

Spek offers two testing styles: Specification and Gherkin. The previous example made use of the Gherkin testing style, and those of you who are familiar with Gherkin and Behavior Driven Development will recognize the Given, When, Then syntax. Here's an example using the Specification testing style as well:

Don't like the default styles? Spek also makes it possible to write your tests in different styles than the standard ones.

An easy way of running blocks of code before and after test execution is essential in any testing framework. Spek provides the following options:

before/beforeGroup

beforeEach/beforeEachTest

after/afterGroup

afterEach/afterEachTest

Spek does not provide assertions, so you can use any assertion framework you like. If you combine Spek with assertion frameworks like Kluent or JUnit 5 Assertions you can develop tests that are easy to read and understand, even for team members with no technical background or programming experience.

Switching testing framework for an existing application can be a frustrating and time consuming task. Luckily, Spek is designed as a JUnit 5 test engine, so if your application is using JUnit 5 you can try out Spek for just a few tests without having to change test framework for the entire application.

One thing to be aware of is that Spek is currently maintained by one person. So far it has been updated on a regular basis, but we have no guarantees as to what will happen in the future.

Spek Framework

We live in a digital era where the most precious commodity no longer is oil or gold, but data. But what if this data, including personal files, customer lists and company data, flight traffic information, or even sensitive hospital records were stolen? What would you do, or pay, to get it back?

Ransomware has been on the rise the past years, where criminals effectively take all the data on your computer hostage and demand a ransom to give it back to you. Refusing to pay may result in your data being lost permanently.

Everyone is a potential target for ransomware, including single individuals, small to large companies, and even public institutions. A disconcerting trend is the targeting of hospitals and the public sector. Only last year the Hollywood Presbyterian Medical Center in Los Angeles was attacked by ransomware, blocking the company’s access to their own network and crucial patient data for 10 whole days. The hospital ended up paying the ransom of $17 000 in bitcoin to decrypt the data.

The demands have also increased drastically the last few years, where the average ransom payment having increased to an exorbitant $178 000 in Q2 of 2020. Some bigger companies also receive very high demands. For instance, Garmin was attacked in 2020 with an initial ransom demand of $10 million, which some sources claim they chose to pay. And this does not include the costs of other factors such as downtime, loss of revenue, mistrust from consumers, and resources used to get everything up and running again.

Clearly, ransomware is a growing problem with an increase in both attacks and in the ransom demands themselves, as well as the targeting of sectors with the possible consequence of directly endangering lives.

But how to the criminals make their attacks so successful, either forcing a victim to pay or having to accept the loss of their data? The main principle of ransomware is that attackers will encrypt all the files rendering them unreadable, and only by buying the key to decrypt the files will they be accessible again. The first step to achieve this, is to obtain access to a computer or network in order to install the ransomware.

How does ransomware get installed on my computer?

Ransomware is a type of malware, which is a malicious piece of software that installs itself without permission on someone’s computer or even an organization’s whole system. The most common ways the attackers get access to your computer are:

Phishing – a cyber-attack imitating a trusted source, where an employee or private person is tricked into installing the malware without knowing it. This can be through clicking a link or downloading an attachment in a seemingly legit email.

Drive by downloads – visiting compromised websites that then installs the malware on your computer.

Security vulnerabilities – if systems are not up to date and are known to have weaknesses, then attackers will exploit these to install their malware.

How does ransomware encrypt my files?

Once the ransomware is installed, it encrypts all the data on your computer. Unfortunately, the encryption methods used now are so complex that it is unfeasible to decrypt the files without the decryption key, which is known only to the attackers. To achieve a secure encryption of your data, the attackers use a combination of symmetric and asymmetric encryption.

Symmetric encryption

One of the oldest ciphers in history is the shift cipher, which shifts each letter a set number of times back or forth in the alphabet. Knowing this set number, also referred to as the “key”, is therefore enough to both encrypt and decrypt a text. Julius Caesar was believed to use a shift cipher, substituting each letter with the one 3 spaces to the right. This is one of the simplest examples of a symmetric encryption.

Today, there are more advanced versions, which can be broadly categorized as block ciphers (encrypts in byte-sized blocks) or stream ciphers (encrypts single digits). These methods are fast and only require the same key to encrypt and decrypt.

Asymmetric encryption

Asymmetric encryption is slower and uses two keys instead of one: one public and one private. The private key is only in the possession of the key pair owner, whereas the public one is widely distributed. When using the public key to encrypt a message it can only be decrypted using the private key, and vice versa.

Ransomware take advantage of both encryption methods.

One of the most common ways a ransomware takes over your computer, is through the following steps:

When the ransomware is installed on a computer, it comes with an asymmetric public key, which it used to establish contact with the attackers’ server. All communication is encrypted using this asymmetric encryption, making it impossible to intercept and interpret the communication between the affected computer and the server.

The ransomware will then request a new asymmetric public key from the server, which is specific for the victim’s computer (making it impossible to share a key with other victims).

Once received, the ransomware also creates a symmetric key, which quickly encrypts all the files.

The symmetric key is then encrypted using the asymmetric key specific to the victim. This means that only the private key on the attackers’ server can be used to unlock the symmetric key, which again will decrypt all the files.

This makes the whole process fast and yet very secure, and almost impossible to decrypt without paying the ransom.

Victims of ransomware

Originally, ransomware was used to target individuals, with a low enough ransom so most people would choose to pay. While individuals are still affected, organizations are targeted on a more regular basis, and can offer a more lucrative pay-off if successful. In fact, one study showed that over half of the companies had been subjected to a ransomware attack in the past year, and that 73% of these attacks were successful. A recent trend also shows an increase in attacks targeting government institutions and hospitals.

Costs and solutions

An estimate shows that total ransom demands will reach a staggering 20 billion USD by 2021.

While paying the ransom is strongly discouraged as it helps create a marked for extorting money in this manner, some still choose to pay the ransom to retrieve their data. One recent study of 5000 IT people showed that about 26% chose to pay and that of these, 95% did actually get the decryption key needed to unlock their files again. Over half chose not to pay and instead used backups of their data, while the rest used other methods.

However, even though paying up may seem like the best way to get things restored again, it may actually double the costs of being affected. All organizations attacked by ransomware had a high cost due to downtime, network costs, lost opportunity etc. even without paying the ransom. In fact, the authors of this study argue that the organizations that chose to pay had the same costs as those who did not with getting their systems back online, except they also had the cost of removing the encryption in addition to their other expenses.

As most attacks are successful and as it is nearly impossible to decrypt your files after an attack, it’s best to try and prevent an attack in the first place. Good strategies include having regular and off-site backup of data, installing anti-ransomware on your system, training employees in recognizing phishing, and closing any technological vulnerabilites that could be exploited. Stay tuned for more on this and other good preventative measure in our next article.

Ransomware - a Devastating Form of Digital Extortion

I gave my first talk at a proper conference in 2009. A whopping 8 minutes and 30 seconds in rapid-fire Norwegian about the state of Scrum and Agile with the catchy title “Derre e itj smidi!!”. Those 510 seconds caused me more than two weeks of anxiety and poor sleep. It felt totally worth it, and I swore to never put myself in that position again.

Since then, public speaking has been a great fascination to me. Why is this so hard to most people, myself included? In my early years as a speaker, I discussed this a lot with people around me. Based on those discussions, the conventional claim that 75% of all people dread public speaking sounds way low, at least in the developer community.

These discussions led to a few unscientific observations:

Most people fear public speaking, and it’s common to have quite strong physical stress reactions.

There is little correlation between who does and doesn’t get nervous, and who actually gives good talks.

Many good speakers suffer anxiety over public speaking, but are consciously both dealing with that stress and putting it to use when preparing for talks.

Experiment 1: Establishing a safe space

Although I swore to never put myself in the position of having to prepare a talk again, it wasn’t long before temptation got the better of me again. The anxiety was still there, and it was long time before that really changed.

The real turning point was when I, with the help of people around me, realized that stress can be both good and bad. And, with practice, you can actually choose how to use it. When I started thinking about it, I realized that stress had helped me prepare well for talks all along. Both in terms of hours of preparation, but also with of being mentally and physically ready.

Realizing and acknowledging this really helped. And it let me observe the anxiety in addition to just experiencing it. Observing it, I realized that it helped me both prepare and to be super aware while presenting.

And the best part: observing the positive parts of the stress, helped alleviate the negative effects. To be certain, they were still there. And to this day, they still are. But when I feel my palms getting sweaty before a talk now, it brings a smile to my face. Oh, it’s on!

Experiment 2: Minimum viable preparation

Stress turned to something slightly less negative, giving talks was getting more fun every time I did it. But at this point, much of my feeling of personal safety when giving talks was tied to feeling really prepared. Like really prepared. On average, I spent more than an hour of preparation on every minute of presentation I gave to larger crowds.

With stress becoming manageable, I was getting ready to consciously experiment with how I was doing things. My first ambition was to bring down the amount of time I was spending to prepare presentations. Or at least to better match the preparation time to the size of the occasion.

The first experiment was a talk about the now fairly exotic CoffeeScript programming language. I signed up to do a 15 minute introduction of CoffeeScript to a group of fifty students. The caveat: I didn’t really know CoffeeScript. I promised myself I wasn’t going to spend more than 3 hours on preparations, all included.

And the result? Well, it definitely wasn’t my best talk to date. But it wasn’t horrible either. And more importantly: it turns out the correlation between hours of preparation and quality of the talk isn’t linear! Unsurprisingly, you get better return of investment for the first 10 hours than the last 35 when preparing for a 45 minute talk.

I still keep the 1 hour per minute preparation rule in the back of my mind when giving talks, but I’m a lot more aware of when that’s actually required. The bigger the occasion, the better prepared I choose to be.

Experiment 3: Playing with the format

Finally realizing that every talk doesn’t need to consume all available time up to the moment of truth allowed me to really get going. I started differentiating a lot more with both preparation times and presentation styles.

One of the scarier things I did was giving a talk about giving talks. A talk about giving good talks. Yelp. Talk about anxiety inducing. The good thing was that the topic, for better or worse, made me self-aware about things like voice use and body language while giving talks, which was something I’d been more or less avoiding for years.

Crawling deeper into that rabbit hole, I created the over-engineered monster of a talk “Presentasjon 2.0”, which among other things included live heart rate in slides, a custom developed live feedback system and augmented reality slide progress control. Because, err, why not?

For the record, building everything required for that presentation took about 90 hours for 10 minutes of presentation. And generally got lukewarm feedback. I had fun, though!

Experiment 4: Bringing it all together

These two presentations weren’t particularly useful in themselves. And some would argue that they weren’t even that good. Most importantly for me, they taught me to be playful and to experiment consciously with presentations.

Some presentations require, and deserve, a lot of preparation. Others you can basically improvise. Sometimes you need text-heavy slides with a professional look and feel, sometimes emoji and weird drawings get your message across better.

The most important thing I’ve learned, is to take time to reflect on what I do, and the effect it has on others. I always take the time to, and suffer the agony of, watching recordings of myself when my talks are recorded. I discuss and get feedback from colleagues and friends. And mostly importantly: I consciously do things differently from time to time, and learn from what works and what doesn’t.

Take-aways

So, what can you take away from this?

Preparation is king (or queen!). The one thing you can control ahead of time is your own preparation. Giving a presentation is asking people to spend time listening to you, and they deserve that you’ve invested time in making sure you’re ready.

… but remember to adjust the amount of preparation you do to the occasion. The return of investment of preparation is non-linear!

Embrace anxiety. Nervousness when giving talks is entirely normal. Take the time to observe your own feelings, good and bad, and discuss them with close friends and family.

Observe the effect of what you do, and practice consciously adjusting your style. This goes for preparation, contents and personal style during the talk.

And last, but not least: try to have fun! When giving talks, I focus on two things. First, I want to make sure that whoever attends the talk gets something out of it. It can be learning, inspiration, insight – or even just entertainment. And I want to have fun doing it.

Fear, loathing and uneasy love: how experimentation taught me to enjoy public speaking

It's so easy nowadays to get a web application up and running in just a couple of minutes. We've got tools like Create-react-app, React boilerplate, Slingshot etc., which let developers set up and prototype anything blazing fast. These tools come with Webpack, Babel and more already configured for you, so you don't have to know anything about them or what they are used for. This is obviously very valuable and cost-effective, but we also have to remember to keep in touch with our roots and get some sense of what is going on under the hood. So for today's topic we will be going back to the basics and see how we can set up most of what we need from scratch!

Introduction - Setting up the project

Today we will looking at how one could set up a simple React application from scratch. You can get far by just using React together with Webpack and Babel, and that is exactly what we'll be looking at. The way we will do this is by first setting up a simple application that is displaying some text using JavaScript and HTML. Then throughout the article we will be adding Webpack, Babel and React to see how one would go about it and how it affects the code/project.

Lets start off by just adding an empty HTML file that imports Lodash:\ index.html

Let's now add some text to the site using Javascript. Consider the following file index.js

Now if we call our JavaScript code from an inline script in the html file, we can display some text.

Cool, but we can do better!

Configuring Webpack

This part is not as scary as some people might think, and we will see here that it's quite easy to get a simple configuration that lets us get started with our application. But first and foremost, what is Webpack and why do we need it?

What

Webpack is a "module bundler" for the web, which in practice means that it takes all your assets (JS, CSS, Images, etc.) and packages them into bundles that browsers understand.

Why

To execute JavaScript code in the browser we have to include every .js file in a script tag in the html page, make sure they are loaded in the correct order so e.g utility functions are loaded before other parts of the code that rely on them, and so on. This is tedious, error prone and hardly scales well. It is much easier to work with modules, but the problem is that browsers don't understand them - well not unless you translate it for them.

Let's recreate the code sample above but this time using modules and Webpack.

Run npm init to initialize the package manager for the project

Install webpack along with a html plugin, npm install webpack html-webpack-plugin --save-dev

For Webpack to know what to do, we need to specify a configuration file webpack.config.js:

In the configuration file above, we tell Webpack to look for the index.js file in the src folder to start its bundling process, and that the output should be in a file called main.js in a new folder /dist. The purpose of the html plugin is that it generates an HTML5 file that includes all your Webpack-bundles in the body using script tags.

Now that Webpack is in place, we can rewrite our index.js file to use the installed version of Lodash that we got through npm.

All we need to do now is to run npx webpack to start the bundling process and serve our new files. Open the ./dist/index.html and check to see that it works!

Setting up Babel

The next step is to configure Babel. But before we jump right into it, I'll try to explain its function and usage as briefly as possible.

What

Babel is a "transpiler" for JavaScript. A transpiler is a tool used to take a high-level programming language and turn it into another (or same) high-level programming language. In our case, Babel takes JavaScript code and turns it into backwards compatible JavaScript code.

Why

The JavaScript language is continuously being updated with new features and functionality which browsers cannot really keep up with. This means that using the latest language features might break your application for some or all browsers. To be able to use the latest features and ensure that we do not mess things up, we can use babel to convert our current code to another equivalent piece of code that we know is universally supported.

Now that you're an expert on transpiling, let's set it up!

Babel is configured using presets. There are two presets that we're interested in, babel-preset-env and preset-react, which we need to install. For Babel to work at all we also need to install the core-library. Lastly, for Webpack to be able to talk to Babel during its bundling process, it needs babel-loader. We won't dive into Webpack loaders in this article, but essentially what you need to know is that Babel is configured using presets and babel-loader is what helps Webpack use Babel.

Now go ahead and run:

npm install @babel-core @babel-preset-env @preset-react --save-dev\ npm install babel-loader

Then add the presets to your .babelrc configuration file:

Lastly, we need to update our Webpack config file and tell Webpack to use babel during its bundling process.

The configuration above tells Webpack to use Babel for files matching the regexp given in test, which are files ending with .js or .jsx.

Putting the pieces together

We have almost everything we need! The last missing piece is obviously to incorporate React.

Go ahead and install React: npm install react react-dom\ And then rewrite the pesky old JavaScript code in src/index.js using React:

Done! We should now have a fully working application that is built using React, Webpack and Babel. There are of course a lot more tools that could help you and your project on its way, but the goal of this article is just to show how one could set up a very basic working project from scratch. I hope you have found this article somewhat useful. If you wish to learn more, please visit the links down below.

Merry Christmas!

Back to basics - Setting up a minimal React project from scratch

If the bulk of your programming experience comes from C-like languages, there’s a chance you find pipes, |>and <| some of the most distinct features of Elm. Roll up your sleeves, it's time to master the art of piping.

Their shape partly reveals what they do; something goes to the right |> or to the left <|. Yet you quickly realize you need to really understand what they do to in turn understand Elm. They have the role of operators in Elm and they control function application.

Below is one way of calculating the sum of the n first natural numbers ( 1 + 2 + 3 + .. n = ? )

We make a list of numbers with 1 as the first and n as the last element. Then we pass that list to List.sum. We need parens around the call to List.range. Without them, List.sum would assume the function List.range itself was its argument. This is because function calls are left-associative in Elm.

We can use a pipe to get rid of the parens.

The improvement might not be apparent. Now, at least the steps are shown in order. Let's assume we instead wanted the sum of the squares of the first n numbers: ( 1² + 2² + 3² + .. n² = ? ).

The former requires us to parse the parens, to spot the order of the statements. In this case the order is right to left. The latter variant instantly reveals the different steps in perfect order of execution. It forms a pipeline.

The backwards pipe, <|could be used to express the same sequence of calls as its brother |>, but in the opposite order. The example above, with the same formatting, would put List.sum first and on a line of its own. This is confusing since in reality it is the last function called. It is better expressed on one line:

This is closer to how one would write in a language that uses parens for function calls. However, long sequences of <| quickly produce long lines. It is almost always possible to express the same sequence using |> . My personal rules of thumb are:

Try to express things vertically with |>

Dont mix |> and <| in the same expression

Use a single <| in an expression to avoid parens

Of these, number 3 deserves additional examples. Recall day 1, when we noticed that we can pair two values with both syntax (1, "one") and the function Tuple.pair. One way this function is useful is with pipes. In the code below, we pair an argument to the function tup with the result of some other expression. With a pipe and Tuple.pair it looks cleaner than if we would use normal tuple syntax.

Going deep

|> is one of Elm’s operators. Like +, it’s an infix operator which gets its two operands from either side. + adds the left and right operand together. As you will learn more about in coming days, + and all other operators are functions in Elm. This is the type signature for +

(+) : number -> number -> number

|> has its own type signature:

(|>) : a -> (a -> b) -> b

This signature tells us that the left operand (first argument) is an a value, the second operand is something that changes an a value into a b value, and the result is a b. Studying these type signatures might seem like an unnecessarily academic activity, but reading and understanding type signatures will enable you to identify where and how you can use pipes in your own code. In my experience the compiler becomes even more helpful with a basic understanding of what type each side of the pipe is expected to have.

Lord of the pipes

Have you ever wanted to add extra functionality to strings? With tagged template literals you can build useful templates, add logic, or write different languages inside strings. How can that be useful, and how does it even work? Dive into how tagged template literals let us build enhanced strings!

The template literal is a nice and useful addition to the JavaScript language. It lets you write multi-line strings, and insert variables where they are used in the string.

Let me tell you out the template literals bigger sibling, the tagged template literal. They let you tap into the power of template literals by augmenting the inserted variables and strings the way you want!

Spice them up with tagged templates

Tagged templates are like another level on top of regular template literals. They are written the same way, with the addition of a tag in front of the string.

In this case, template is the name of a tag. Tags are functions that you can write for yourself, or download as part of a library or framework.

Creating tagged templates for yourself

Tagged template literals follow a pretty consistent formula. It is a function where the first argument is all the strings in the template, split on the places where a variable is inserted. Then all the variables are passed as rest parameters.

The template tag`Hello, ${name}! will give us the strings ["Hello, ", "!"] and the parameter name.

The example above might not be the most useful by itself, so let us go for a more generalized approach. To allow an arbitrary amount of variables in the template we can collect all the rest parameters to a list of variables. This leaves us with the list strings and all the variables in values.

The template above doesn't do anything special yet. It combines the strings and values to create the original string. To build further on this we can add the logic we want to enhance the strings or values!

Writing other languages inside of JavaScript

One of the very useful features that can be created with tagged templates is the paring of different languages inside JavaScript. Let us take an example of a tag that renders markdown. This can be quite useful for generating larger pieces of text in a front end in a more human-readable format.

We can create the above md tag by using a markdown renderer to render our string to html of our required format, without any extra hassle. The template can return whatever you want, it doesn't even have to be a string!

For a more in-depth example, we can try to construct our own tag which queries an SQL database. The template lets you write regular SQL queries as regular strings. Values can be inserted where they are used in the string. While the sql tag builds the query, sanitizes the values, and executes a query behind the scenes.

Use cases in the wild

A few popular libraries have found their way to include tagged templates. Some even use them as part of their core functionality. Many of these libraries even include plugins for your editor. Many add support for syntax highlighting templates for the correct language!

Some notable ones include:

Apollos graphql-tag

With the graphql-tag library, you can write queries in GraphQL directly in JavaScript. The queries can be syntax highlighted as GraphQL. The template returns the query as GraphQL AST (Abstract Syntax Tree) instead of a regular string.

Styled Components

Styled Components is a library that lets you create CSS styling inside of JavaScript files with tagged template literals. Each html tag has a corresponding tag, and the template returns a React component with the CSS in the template as scoped styling for that component. There are also a lot of similar libraries like Emotion that follow much of the same formula.

lit-html and lit-element

Lit-html is a library for rendering html with tagged template literals. The templates are made to make updating the dom easy and efficient, and only the changes are rendered to the DOM. You can combine lit-html with frameworks like lit-element to create web-components.

Enhanced strings with tagged template literals

Kubernetes has become the de facto container orchestrator since it's initial release in 2014. It is a great tool for managing diverse workloads in clusters of machines, possibly spanning multiple availability zones. As the usage grows, new requirements for how to deploy and operate specialized software emerges. The Operator pattern is one of the more prominent responses to these new requirements.

The Operator pattern is best described in the official Kubernetes documentation:

The Operator pattern aims to capture the key aim of a human operator who is managing a service or set of services. Human operators who look after specific applications and services have deep knowledge of how the system ought to behave, how to deploy it, and how to react if there are problems.



People who run workloads on Kubernetes often like to use automation to take care of repeatable tasks. The Operator pattern captures how you can write code to automate a task beyond what Kubernetes itself provides.

TL;DR Operators automate operation of applications and services with human know-how.

How does an Operator work?

An Operator consists at a minimum of one Custom Resource Definition (CRD) and a Controller. The CRD describes the various configuration options for this kind of resource. Given a custom resource for a PostgresDatabase, one might find options for specifying custom StorageClasses, resource allocation, backup schedule/destinations, authentication methods, etc.

Given an instance (CR) of PostgresDatabase, it's now the job of the controller to ensure that the desired state is reconciled with the cluster. In this example one can assume that the controller will create a StatefulSet for running the database itself, along with needed configuration in a ConfigMap, certificates for mutual TLS in a Secret. Backup can be done by either mounting and writing to a volume defined in the CR or injecting a sidecar for sending backups to another location.

Patching, reboots and failovers can be specified in the CR and taken care of by the controller, using methods recommended by experienced DBA's. The fact that complex operational knowledge can be encoded into the controller is a key enabler for many organizations that would like to run complex software, but not necessarily invest countless hours into learning the nitty-gritty details on how to operate it.

Like any other software there will be bugs and abstractions will leak. There's no silver bullet.

How do I create my own Operator?

As with the rest of the Kubernetes community, multiple solutions exists.

For a declarative experience, check out KUDU

If you'd like a more official way to do it, see kubebuilder

The most popular option seems to be Operator SDK

As with most cloud native software, Go seems to be the lingua franca. There is nothing stopping you from writing an Operator in Java, C#, Python or any other language that can communicate with the Kubernetes APIs.

Examples of known Operators

The community has produced a lot of Operators for about everything one can imagine. These are some popular examples:

Argo CD – a declarative, GitOps continuous delivery tool for Kubernetes.

cert-manager – automatically provisions TLS certificates via the ACME protocol. Can be used with certificate issuers such as Let's Encrypt, Buypass and ZeroSSL.

Prometheus Operator – often used in combination with kube-prometheus for a batteries included monitoring suite

KubeDB – a real-life implementation of the PostgresDatabase example, plus support for MySQL/MariaDB/MongoDB/Redis/Memcached and more

Header image: RIA Novosti archive, image #305015 / Alexey Danichev / CC-BY-SA 3.0

Kubernetes Operators 101

Innovation thrives when different ideas and people meet, also between companies. What can Norwegian companies learn from Silicon Valley style innovation?

With Jennifer Vessels (Future Ready Innovator at Executive Growth Alliance), Jens Andreas Huseby, Rasmus Bauck and Moquan Chen.

How do you collaborate on innovation?

Noe skjer i bussvinduet. Tre diagonale former beveger seg i formasjon. Så fem til. Er det gjenskinnet fra vinduene i det kontorbygget?

Vinduene fargelegges av reklameskilt og gatelys.

«Hvor sitter du når du ser dette, da?», spør min kjære i telefonen. «Jeg sitter jo inne på bussen da», sier jeg. «Ja, i lotus i midtgangen da eller? Hvor sitter du i bussen liksom?». Hmm, lotus høres bra ut. Når jeg nå sitter her skulende mot midtgangen og skal skrive noe om inspirasjon, tenker jeg det vel så gjerne kunne vært et ode til Hanna...men det får bli i en annen kalender kanskje, heh.

Nå svingte bussen, og vinduene ble til diamanter gitt.

Men hva er det der i mellom dem, som holder diamantene sammen og orkestrerer hele forestillingen? Edderkopper. Beksvarte edderkopper. Bena deres danner en litt skummel matrise. Hva om jeg satte typografien i den? Farger, grid, typo, bevegelse. Dette begynner å ligne noe.

Gleder meg til å prøve det ut kjenner jeg. Men nå har edderkoppene fått pels, og de slynger seg fra diamant til diamant? «Imma come at you like a spidermonkey!!» hører jeg kid’en til Ricky Bobby AKA Will Ferrell si. Nei, det her sklir ut... «Er det dette som er inspirasjooon da asså?» spør spidermonkeyen fra vinduet, hånlig.

Lille frekkas. Vet ikke? Kanskje en dagdrøm rett og slett, eller noe rart jeg fikk i kaffen. Hvordan vet man forskjellen? Mellom en dagdrøm, rar kaffe, inspirasjon, affeksjon, innsikt?

I kreativt arbeid, og i annet arbeid og i livet i det hele tatt, har jeg opplevd å bli inspirert og u-inspirert på mange ulike måter. Jeg har gått langs kaia, sett på bølgesprut med vinden piskende i fjeset, og kjent på en følelse av mulighet og driv bruse opp i meg. Og så har jeg gått langs kaia, og bare kjent meg kald og våt egentlig.

En gang full av iver, og en annen gang bare kald. Det er tydelig at inspirasjonen ikke har fast bopel på den kaia i hvert fall. For en landstryker og fante-fark, hah. Og fantastisk fabeldyr samtidig! Kommer og går inspirasjonen som den vil?

Det kjennes slik noen ganger, sikkert for alle som jobber med noe kreativt tipper jeg. Inspirasjonen er på en måte uløselig knyttet til det kreative arbeidet. Jeg er fanget i et forhold skjønner jeg, dysfunksjonelt er det også – i mer eller mindre passende grad heh.

Det er mye å lære ved å stå i dette forholdet da, erfaring etter erfaring forteller noe om hva som fungerer, og ikke. Men det er lett å havne i rutiner også, lett å ta ting for gitt. «Nå skal jeg lage en app, så nå går turen til pinterest for å se på apper, check!». Det er lett å slutte å reflektere over hva som beveger samspillet med dette fabeldyret kanskje? Her er en refleksjon da: Mer forståelse = Bedre partner?

Ja la oss forstå det bedre. Men, til et slikt foretak trenger vi nok profesjonell hjelp... ooog...(liten kunstpause for effekt)...her kommer den! Dette er nevroforskerne Arne Dietrich og Riam Kanso i en gjennomgang av mangfoldige studier der forskere, ved hjelp av EEG, scanning og annet, prøver å se kreativitet i hjernen – let’s go!

«To most neuroscientists, the prospect of looking for creativity in the brain must seem like trying to nail jelly to the wall.”

Ok, eeh…her må vi kanskje ta noen steg tilbake ja.

Det viser seg at inspirasjon og kreativitet er vanskelig å se forekomme i hjernen. Det blir ikke mindre mystisk og mytisk med forskning da altså. Eller? Dietrich og Kanso forteller mer:

“It is hard to believe that creative behavior, in all its manifestations, from carrying out exquisitely choreographed dance moves, to scientific discovery, constructing poems, and coming up with ingenious ideas of what to do with a brick, engages a common set of brain areas or depends on a limited set of mental processes”

Fra dette kan vi forstå at kreativitet og inspirasjon er komplekse konstellasjoner, alltid i bevegelse og vanskelige å måle med apparater. Hørt den gamle floskelen om at «kreativ tenkning, jo, det skjer i høyre hjernehalvdel det!», hm? Den tror jeg du trygt kan legge død.

Men der måleinstrumentene til nevroforskere har hatt utfordringer (vel å merke tror de ikke det er umulig å måle, de har bare ikke løst det ennå), har psykologien hatt mer hell. Og det med metoder kanskje gjennkjennbare for dere som har drevet med innsiktsarbeid for eksempel. Intervjuer, kontrollerte «brukertester», selv-rapportering og andre forsøk der en f.eks ser på hva som kjennetegner noen som ofte blir inspirert, eller leverer kreativitet ofte, har fremmet en betydelig mengde kunnskap.

I denne artikkelen refererer forskere fra College of William and Mary i Williamsburg til flere slike studier, bl.a denne:

«In three studies of different types of writing (poetry, science, and fiction), self-reported state inspiration during the writing process uniquely predicted creativity of the final product, as assessed by expert judges…”

Men prøver en å observere noe av denne inspirasjonen og kreativiteten utspille seg i gjennom bilder av hjerneaktivitet, er det som om den ikke eksisterer. Det er noe mystisk og fascinerende ved det aspektet, som minner meg om nettopp forholdet til inspirasjon. Du kan ikke tvinge det frem, men du kan la noe annet fremkalle det i deg dersom du åpner for det.

Et liv i samspill med inspirasjon krever jobb altså, what else is new? Hva skal vi med den informasjonen egentlig? Men spør deg selv, neste gang du besøker en gammel kjenning av en inspirasjonskilde: Ble du inspirert der igjen? Eller var det heller trygghet i konvensjon, eller løsning du fant? Hvordan beveger du deg i denne dansen mon tro...er det lenge siden du og inspirasjonen fant på noe nytt?

Vent da, nå må jeg gå av her, og Hanna er fortsatt i telefonen vøtt. «Hjemme snart? Hva er planene dine i kveld a?» spør hun... «i kveld har jeg en date med en grid, noe typo og et fabeldyr, ikke bli sjalu da ❤️»

Inspirasjon: En date med et fabeldyr

Today we are excited to reveal the second article from our guest writer Dillon Kearns, known for projects such as elm-graphql, elm-typescript-interop, and the Elm Radio podcast! If you didn't catch the one from yesterday, be sure to check it out as well! We hope you enjoy!

At Elm Conf 2018, I gave a talk called Types Without Borders. In the talk, I discussed the idea of preserving type information when crossing the boundary between languages or environments.

I gave a demo of two different libraries that follow that principle: elm-graphql, and elm-typescript-interop. elm-graphql has stood the test of time quite well.

elm-typescript-interop was a solid idea at the time, but it missed something fundamentally that elm-graphql got right. So I'm rethinking it from scratch and introducing a new incarnation of that project that I'm, creatively, calling elm-ts-interop. In this post, I'll explore the missing piece, which needed a fresh look after a few years to discover: using a Combinator approach. I wrote about Combinators in-depth in yesterday's post. Before I explain the new approach in elm-ts-interop, let me describe the original approach of elm-typescript-interop.

The original elm-typescript-interop

The idea of elm-typescript-interop is to look at your Elm source code and find all the ports and their type information. In Elm, a port is a way to send messages to or from JavaScript. Since JavaScript doesn't have the same guarantees that Elm does, ports are a way to have an environment with sound types and no runtime exceptions. But you can still communicate with JavaScript, just by sending messages with the concept of the Actor Model - messages can go out, and messages can come in.

You define a port with a type annotation like this:

You can learn more in the Elm Guide's section on ports.

And in your app, you would call

elm-typescript-interop takes that type information and generates TypeScript type definitions for setting up your Elm code. This is quite handy because it gives you

Intellisense for autocompletions when you wire up your ports in your JavaScript entrypoint

TypeScript errors if you pass in incorrect data

TypeScript type information about the incoming data from Elm

Wiring up your ports looks something like this:

elm-typescript-interop generates TypeScript declarations to bring some type-safety to this process. In hindsight, this type-safety is great, but the overall approach misses the bigger picture.

The problem with the original approach

People would often ask, "what's the best way to send your Elm Custom Types through a port?" Elm automatically sends basic types through ports, like String, Int, records, lists, etc. You can also send generic JSON data through a port. You'll have to use the elm/json package to turn your data to or from typed Elm data. If you're wondering why Elm doesn't just automatically convert any type to JSON, Evan Czaplicki's document describing his vision for data interchange is worth a read.

Initially, I thought that I would eventually come up with a way to automatically serialize more advanced Elm types, again by statically analyzing your Elm source code. Then you could serialize that data into TypeScript types automatically. I tried sketching out some design ideas, but never came up with anything that felt satisfying.

So what that left you with was using elm-typescript-interop to be a serialization/de-serialization layer. But you would then need a second layer to convert that into proper Elm data.

Let's take our example from above

What if our ideal data type in Elm doesn't have that exact shape that we want to send to TypeScript? Let's say our ideal Elm type is this

Now we need a translation function to turn that data type into a format that our port can serialize.

Just as we couldn't use our ideal data type in Elm because it used an advanced type that can't be automatically serialized, our ideal TypeScript type that we want to serialize to can't be expressed directly. We can't use expressive TypeScript types like discriminated unions.

But specific limitations with serializing to/from advanced data types isn't the root problem. Regardless of those limitations, we can't assume that the data format needed in TypeScript and the ideal format in our Elm code are the same. So we need to transfer the data, while also transforming it. If you read yesterday's post, this may all ring a bell. You guessed it - it's time for a Combinator!

Getting the best of both worlds with Combinators

Let's say our ideal type that TypeScript would like to work with looks like this

Our elm-ts-interopEncoder would look something like this:

Just by writing this Elm code, we have the exact TypeScript type type Event = Error | PageNavigation that was our ideal TypeScript type! This allows us to express much more nuanced types between Elm and TypeScript (in this case we have a TypeScript Discriminated Union, for example). The type information from this Encoder is synced by running an elm-ts-interop command-line tool.

This Encoder does two things:

Acts as an Adaptor to get the formats to line up (think American-to-European power adaptor)

Preserves type information on both sides as it does this!

This is crucial. In building up the adaptor, the API builds up type information about what data it expects to come in, and what data types can go out. This is the missing piece from Types Without Borders! Why is this so important? There are several benefits:

We can express much more nuanced type information through this API

This is a Combinator, so we can build up very complex transformations by composing together easy-to-understand building blocks (see yesterday's post on Combinators)

Because of this new approach, we now have the added benefit that we can use a single Elm port to send all possible messages to TypeScript, and a single port to receive all messages from TypeScript.

That means instead of remembering to register each port, but getting no warning if we forget one, we can use TypeScript to guarantee that we've handled every incoming message!

Again, this is because of the power of the Combinator pattern. Since a Combinator is just built up of other Combinators, we can build up very complex data serialization out of smaller pieces, and then combine them into one type that's nice to work with in an exhaustive switch statement[^exhaustive-switch]!

Sneak peak of elm-ts-interop

Thanks for reading! I'll be releasing elm-ts-interop very soon, so stay tuned. If you want a sneak peak, you can browse this preview of the documentation. I'd love to hear your thoughts. Let me know what you think on Twitter @dillontkearns!

[^exhaustive-switch]: To make sure you get errors if your switch statements are missing a case in TypeScript, you'll need to either use this trick, or use the @typescript-eslint/switch-exhaustiveness-checkeslint rule.

11-Dec

Today's posts