A new year is closing in and so is a new release from Scala. Release candidate 1 is expected to be found sometime this December!

Version two of the language was released in 2006 and has so far seen a total of thirteen larger minor releases. Throughout these changes the language has evolved to places not foreseen. Implicits that were first introduced for implicit conversions gave rise to type classes, built upon to create implicit classes for extension methods, and macros for metaprogramming that to this day is still locked behind experimental flags, though still considered an important part of the language. A key part of the coming version is to formalize these patterns and be more opinionated. But under the hood there is lots more going on!

A unique challenge for Scala has been the combination of subtyping and dependent types. The theoretical foundation has been on rocky grounds up until 2016 when DOT Calculus (Dependent Object Types) was presented^subtypingPath. With that came Dotty, a reference implementation language translating to DOT calculus, and now soon to be Scala 3. Though going deep into these details is not important for end users, it is interesting to note that we are talking about a complete rewriting of the compiler.

If migration issues are a worrying factor, then it should please you to know that most application code bases seem simple to port. To ease the process a lot of the bigger users facing changes are delayed to version 3.1. Scala 3 will also be able to use Scala 2.13.4 binaries and vice versa. Most of the difficulties will be in the ecosystem migrating base libraries, which is well on its way! The community builds^scala2CommunityBuilds has been an enormous success for Scala 2 and the one for Scala 3 is soon up to 50 community libraries ^scala3CommunityBuilds! Not bad for unreleased software. Documentation on the migration process is being worked on the by the Scala Center^migration.

New Features

Simplicity and more opinionated patterns are one of the bigger design goals. In the example above we have started a small program in two lines of code. Try it out yourself through Scastie^scastieHelloWorld. But lines of code are far from everything regarding simplicity! The error messages are improved, and the type system will do a much better job aiding you while keeping the code sound. One example of that is that the compiler will give suggestions of what to import when implicits are missing from the scope. In the example error below, we can see a detailed error message from trying to use an extension method from the fantastic Cats^cats library. Learning which imports to use in libraries which are heavy on implicit usage has always been a sore spot for beginners. Now we immediately get a helping hand to continue.

All the examples can be run through Scastie and I can recommend trying them out. Note that they are an unprioritized random subset of all the new features. An up-to-date list of changes to the language can be found on the Dotty site^scala3Docs.

Enums

In earlier versions the de facto standard of enums have been to create a Java file with an enum, or create a sealed trait, or use some macro library. While sealed trait hierarchy do provide a working solution with exhaustive checking, it is far more general and requires a lot more boilerplate if one needs ordinality, hence the macro-based solutions.

It is worth noting that enums are syntactic sugar that is translated to a sealed trait at compile time. Enums will therefore also support the modeling of ADT's (Abstract Data Types) and GADT's (Generalized ADT's).

A homemade implementation of the Option ADT can now be as follows:

The new implicits: using/given and extension methods

One of the bigger sources of confusion have been implicits and all the contexts it is usable in. Need implicit conversion? Check. Type classes? Check. Extension methods? Check. Sending some contextual information? Check.

Extension Methods

Extension methods can shortly be explained as extending methods on types after they have been defined. This can be usable for extending the functionality of third-party libraries or for creating DSLs.

Let us say one wants to count the occurrences of a word in a list, say

The function countWords does not exist. Previously with the following in scope the code would have compile.

While this works perfectly fine, it is not easy for someone new to the language to understand what is going on. So now we can instead use the keyword extension, thus making the intention a lot clearer and easier to Google!

Type classes

Type classes are, in short, a way to do ad hoc polymorphism. One typical example of a type class is the Show type class. In Java, every class extends from Object and on Object we find a toString method. Being available everywhere is practical, but does it make sense for everything? I am not going to jump into that debate, but what if we could define something that gave us a def show: String method on every type that we find necessary, and if not defined then give us a compile error? To have such a class of functionality defined ad hoc for a type is a type class.

In Scala 2 this could look like the following (if you are new to the language, do not ponder on this example for too long!):

This works for its purpose, but there are a lot of concepts to grasp. If finding this in your codebase is the first introduction to these concepts, then good luck guessing what to google to understand it.

A rewrite of the same functionality to Scala 3 would use the new given keyword and extension methods.

One of the many small but significant differences to note is that there is no explicitly named reference to the given instance of the type class instances like showInt and showString in the Scala 2 example.

The keyword given is now used to define that something is implicitly available. To get a given value for some type then using is the new keyword:

For myFunc we have defined a function where we work on a type A that has an implementation of Show that is unnamed and defined numeric operations through a new type class, Numeric. The power of this is that within the function we have a well-defined set of things to do. If this had been from separate library, then we could just implement the given instances for our own types.

Show is not one of the conceptually important examples, but the use case for type classes is none the less a fantastic tool for many abstractions. Such examples can be to define specific functionality for types in generic code like myGenericFunction or modeling abstractions^applicatives.

Union types

To represent a coproduct of types.

Some of the possibilities this opens is to make type safe error handling simpler!

Previously this could be done by stacking Eithers or by making a sealed trait hierarchy. The downside of sealed traits is that the entire hierarchy must be defined in the same file upfront. Now, error types can be combined and built up anywhere!

Opaque types

Another mechanism to help with type safety in our applications is opaque types. They are type definitions where the enclosing type is only known within the same scope.

And lots more

Other interesting themes to dive into are intersection types, the newly built-in type class derivation support, explicit null handling, export clauses, and a new macro system. While the details are still being hammered out, it is interesting to ponder where all of this will take the language. Eager to try it out ^scastieHelloWorld?

A peek into Scala 3

Wouldn't it be sweet if you could automate writing code. Well, that's what we're taking a look at today. Metaprogramming, code generation, or in short; writing kotlin code that generates even more kotlin code 🤯.

Disclaimer: This article focuses on source code generation, and does not make any comparison to byte buddy, asm, javaassist or others.

Today we're going to take a look at kotlinpoet and some of the possibilities code generation offers.

In it's most simple form codegeneration can simply be any program, that when executed spits out valid sourcecode. As an example, a simple function which returns a print statement;

There is nothing spectacular going on here. When it is executed it prints out some valid code, that we potentially could use later. But, lets make it more complex and at the same time introduce todays star kotlinpoet;

Kotlinpoet doesn't do much in the example above, but as we'll see it will help us more further down the line. FileSpec and TypeSpec are kotlinpoet's representations of files and classes, and once we got a TypeSpec we can add in more stuff like properties, constructors and other functions.

To add a simple property to our Code class we use define a PropertySpec and add it to our already existing TypeSpec;

All of a sudden our class has a property and some import statements. Kotlinpoet keeps track of which import statements are needed to make our code work without us programming it explicitly. The complexity at this point is somewhat limited, but even now we get some help from the library.

Adding a function to our class continues in a similar vein;

Kotlinpoet correctly identified that the Code class is visible within our class, and thus didn't add an import or use the fully qualified name for the class. However, if we change the return type of our function to LONG it would include it as an import. Consequently it would also generate code that wouldn't compile as our function has return this which isn't a Long , whoopsi. Fortunately, we are generating kotlin source code, and the kotlin compiler would probably tell us that something was wrong.

This might seems like quite alot of work to get a small class. And while that might be true, it also opens up the possibility to automate some really cool stuff. Looking through the usage of kotlinpoet on mvnrepository we can see it being used by Arrow (Arrow-Meta), Microsoft Thrifty compiler plugin, the apollo-compiler and ExpediaGroup's graphql-kotlin.

Kotlin metaprogramming with kotlinpoet

If you're curious about doing tech talks, chances are you're stressed out about preparing for it. Let's see how it's done.

First, a few lines about myself. I'm 33 years old, and I've done about 100 presentations and talks throughout my life. Some of those talks have been for four or five colleagues in a cramped room, and others has been in front of hundreds of live spectators. Although the amount I prepare vary based on the impact that particular presentation has, I follow about the same procedure.

This article will show you what I plan to do, what I actually do, and what separates a great performance from a lackluster one.

Step 1: Decide on your own motivation

Before you even get started on the actual talk, you need to figure out what's in it for number 1. What do you want to get out of doing this talk? Do you want to learn something new by doing a talk about it? Do you want to position yourself as an expert on a particular topic? Do you want more visibility internally to get that promotion? Or do you have some other ulterior motive?

Discovering what lays behind your wish to do a presentation can help you decide on a topic, a format and even a way of structuring the talk itself. So I always reflect a little bit on why I want to hold a particular talk.

Step 2: Find a topic you're passionate about

Choosing the right topic to talk about makes a great presentation much easier to achieve. Hey, I'm sure I could've done a great talk about Java ServerFaces or my wife's skin care routine, but it would require me to put a lot more effort into getting my own excitement up.

Good talks are built on excitement, and if you don't have that initial spark, it's going to be a long steep hill to get there. You can get there eventually, sure, but it's much easier to just start out already excited.

So pick a topic you're passionate about. Excited about. Or perhaps just interested in getting leveling up in yourself!

Step 3: Write an outline

Once you've settled on a topic, write an initial outline of what you want to do.

I always start out with the same outline. It works with any topic, and gets me into the right frame of mind

It might look like a joke, but it's an integral part of my routine to create an outline. Next, I break that <topic> into a few more pieces, like so:

The amout of main points you want to make might differ depending on how long your talk will be, but try to break down your topic into at least a few sections.

Once you've gotten this far, fleshing out your outline is pretty simple. Below each of your main points, try to list a few "headings" of slides you want to show. Next, flesh those out with more detailed notes, and continue until you're happy with the level of detail so far.

Remember not to go too deep into the material though, this is mostly a tool to help you structure your talk and order your slides.-

Step 4: Create a simple slide set

I admire people that put a lot of effort into their slides, but I never do. At least not to begin with.

Before I even think about design and transitions, I just jot down my outline on slides, and go through them a few times. This is your initial first draft of your talk! It's not the best talk of all time, sure, but it's your talk, and people would learn from listening to you mumbling through it. You've already created shareable value, and if that's not an agile approach to talk development, I don't know what is.

You're going to iterate through this draft a couple of times, mostly to figure out what pieces you want to put in, and what now seems irrelevant. Perhaps you'll add a few slides in one section, or rip a few out of a different one - just work on this thin draft until you have something that feels about right.

Remember to keep the content of each slide short though! We'll address that in the next step.

Step 5: Make readable slides.

The next thing I do, is to have an initial pass at how the slides look. Decide on a theme you like, and apply it to all your slides. Note that you shouldn't start optimizing this too much yet, since you're still probably going to change a lot.

To me, slides is just a way to create mental "hooks" for people to relate what I'm saying to. I rarely use lists, and if I show code, I prefer to either type it out live or go through it with a highlighter tool line by line.

I'm a huge fan of having either no words or a single phrase per slide. Most people in the audience has a habit of zoning out of what you say to read what you've written on your slide, so if you keep it short, you'll have their attention back quicker.

I try to keep the font size legible, my transitions to a minimum, and avoid any animated "funny" GIFs if they're going to be on screen for any period of time. Outside of that, though, I'm sure you can find much better articles on creating pretty slides.

Step 5: Write speaker notes

When you've gotten this far, you're ready to prepare what to say. You've created an initial structure, you've mumbled through your main points a few times, but this is where you have the opportunity to create something really extraordinary.

The speaker notes is your actual talk, and where you'll write your nifty wordings and memorable quotes. You might not need them as much when presenting, but it's a great tool to use while writing and rehearsing your talk.

I always start out by typing out the bullet points I want to say. If I'm doing a longer talk, I often leave it at that, and just fine-tune their wording a bit as the talk progresses. If i'm doing a lightning talk, however, I often write the complete sentences I intend to say, and use bold text or other text styling to make the main points easier to find when I'm scanning the notes.

As a last tip on speaker notes - I always leave a single sentence in the first slide's speaker notes - "Relax buddy, you got this". It's both a great pick-me-up when I'm nervous to begin, and it's a funny "gaffe" if you just happen to put the speaker notes on the wrong screen when connecting your laptop to the projector. 😅

Step 6: Rehearse

I once got a tip to spend 1 hour rehearsing every minute of my talk. So if I was doing a 40 minute talk, that meant a full work-week of rehearsing. I have never even come close to that.

I always run through the talk in its entirety at least 3 or 4 times, and then I start iterating on the parts of the talk that makes me a bit nervous, or that I am the least happy with. If it's a lightning talk, I often do up to 10 or 12 iterations of the whole thing, but if it's a long-form talk, I rarely do more than 3 or 4.

The reason for not rehearsing too much on the longer talks is that I have… well, more time! If I mess something up, I can always get back on track by taking a couple of seconds to read the speaker notes, without the audience noticing a change in the tempo of my talk.

The amount of rehearsal needed can differ from person to person, from talk to talk and from format to format. If you're live-coding a lot, you definitely want to have that code in muscle memory, and a strategy to bail out if you're stuck on some typo. If you're doing a terse 10 minute talk, you definitely need to work on timing your pauses, and getting them to sound just right. If you're doing a longer talk, you might want to put some extra emphasis on your body language, too, since you'll have the opportunity to walk around a little bit more.

Step 7: Do the damn thing!

I mean, you could rehearse in front of an audience (I often do it in front of our 8 month old daughter), but what it really comes down to is just stepping onto that stage and saying the words. It's the most scary thing in the world until you get started, and then things just happen to unfold.

The seven rules of presenting like me

If you want to do what I do, these seven steps will make it happen.

Decide on your motivation for doing a talk

Find a topic you feel passionate about

Create an outline

Create some initial slides and iterate on the structure

Make the slides pretty(-ish)

Rehearse it until you feel decently confident you know what you're going to say

Step onto that stage!

Oh - and perhaps an eight rule of presenting like me: Repeat. Present often and about new topics. Pitch your talk to your team at work, to your local meetup and to the large international conferences. Do it again and again, until you feel you've done it too much, and then do it one more time just because.

And in no-time, you'll have the audacity to write articles on how to present stuff. Just like me 🎉

You're the only person that cares this deeply about this talk, so please remember these parting words: No-one cares if you screw this up. As a matter of fact - if you screw up royally, people will probably have forgotten as soon as they leave the room. If you do a great job, however, you'll get a ton of applause, praise, and people tend to mention it for the next time you catch up.

How to Present Like Me

A couple of years ago, a colleague and I created a small JavaScript application to toy around with some image processing techniques. I really enjoyed the project, and the other day I decided put the same functionality in my new React code.

One way of doing this would be to rewrite the whole thing, and to be honest, it probably would not have been that much work. But it got me thinking, how would I go about injecting the already written code into my React application? I haven't done anything like this before, and if you haven't either, this is a blog post for you!

The simple way

The easiest possible way I could imagine this being done, would be to include the html and the built JavaScript needed into my index.html, so that is where I will start.

The JavaScript depends on some html, so that has to be included as well.

And this works! However, while having the React code and the JavaScript code side by side is very simple, it is not very customisable.

Integrating with React

You see, while the JavaScript app in itself is nice enough, I actually wanted to "extract" the image processing functions from that app, and use those together with my React code, which meant having to import it into the React code.

Importing the code

First of all, this code is not in any package registry, so in order to have something to work with I simply put the git url into my package.json.

And so it begins..

Taking the naive approach, I want to import the code to use it in my dummy React app. So what happens when I import it?

Uh oh, TypeError: document.querySelector(...) is null. So the main problem here is that this code is not really made for being used in other applications. It does a bunch of stuff in index.js as it is imported, and it does not export any of the functions I wanted to reuse. Yikes.

However, since I co-authored the code, I can fork it and tweak on it a bit for my usage! The same would be alright with any other code as well as long as the license allows it. So: I fork the project, and remove all the noise in index.js and export the functions I need.

Then we can just use these functions in our code. I have made a new "FunctionalEditor" in React that uses the Editor and all the effect functions from the image-workshop:\ Note that I have to include the <canvas id="... because the JS depends on it.

And success! I get my own version of photoshop inside my React app!

querySelector >:(

And I am mostly happy with this. All is well as long as I have HTML-elements with a certain id, because the JavaScript code uses querySelector to find the DOM-elements to manipulate. This also puts restraints on my React code. In order to truly have customisable code, the JavaScript should not care what I name my elements or where I put them.

Instead of having the render function in the image-workshop use querySelector to grab the canvasses, it would be better to refer to the elements directly. That way, I can also basically send any canvas to be rendered.

Since the editor now needs access to the canvas-element, we can create refs that belong to the canvasses and pass them to the loadImage and applyEffect functions in Editor.js.

\ And that is pretty much it! This small JavaScript project is turned into a simple API, and used in modern React code. I hope you enjoyed this article, and hopefully the next time you encounter an awesome non-React library you'd like to try out, you won't be scared off!

Reusing existing JavaScript-code in your React app

This blog post will not focus on how or even why you should write your infrastructure as code. Rather, it will focus on how you, a curious developer working with Azure Resource Manager (ARM), can modularize your infrastructure code and share it with others through linked ARM templates. I will also show you the basic parts of a self-made "repository" of templates which makes using shared templates a breeze.

If you by any chance don't know what ARM templates are and you're still reading, here is a really short introduction: An ARM-template is essentially a JSON-object that describes your resources in Azure. It can take parameters as input and return certain values as outputs. There also exists various constructs for doing some simple conditional logic, loops, string manipulations, and more. Resources are created or updated using the template in a deployment that you submit to the Azure Resource Manager, Azure's deployment and management service. A simple template may look like this:

The beauty of ARM templates is that any template can be used as a part of another larger template. When you do this, you are linking a template into another – thus the name linked templates. To use another template as a linked template, you specify a resource of type deployment:

A deployment resource must have a unique name in the context of the template, as it is used as an identifier when referencing it. You may also pass parameters to the deployment. This particular template takes a single required parameter, storageAccountNameBase, and it is therefore specified in the parameters section of the deployment's properties. Additionally, since a linked template is a resource like any other, you can use all the same constructs as with other resource types (conditions, loops, and so on).

Templates can define values to output as a result of the deployment. This comes in handy when composing larger templates using several, smaller linked templates. To use outputs from a deployment, you need to reference it, and the simplest way of doing this is through its name:

Now you know the basics on how to break apart your monolithic ARM-templates into modularized components. But one question remains: How to share your linked templates with the world? Well, the keyword is in the name: "Linked" templates. Each resource of type deployment has a crucial property that you may have noticed already:

If the templateLink has the value of an URL that can be reached through the internet, the Resource Manager will download and execute the template at deploy-time. How you make your templates available though, is entirely up to you. There is no help from the framework, not even when it comes to versioning. ARM-templates do have a contentVersion-property, but it is more informational than anything else. But, since I've got your attention, I will share one way to make your own "registry" with versioned templates available for anyone who wants to use them. It's nothing like NPM, but it gets the job done!

First of all, you need some form of storage. This is an Azure blog post, so we will use a Storage Account for this purpose. You can create one using the Azure CLI like this (or use an ARM template 😉):

Now you have somewhere to upload templates. From this point, it is up to you how fancy you like to handle versioning and such. I've made a "monorepo" with this folder structure:

Then, I publish each new version of a template to a Blob Container. For simplicity, I've opted to use a single Container named "feed" to store templates, and I handle versioning using paths like this: /keyvault/vault/1.0.0/template.json.

The version is read from the template's contentVersion-property, and the path is constructed using the structure of the src-folder. I've omitted the publish action itself, because from here, your methods may vary. I would recommend using a single container, and make it readable with public anonymous access (don't keep secrets in your templates!):

Having the templates anonymously available makes consuming them a lot easier as you can hard code the full URL in the consuming templates like this:

With your "registry" in place, there should be nothing preventing you from breaking apart your brittle and monolithic ARM templates. Isolate reusable parts into standardized templates where you control behavior through parameters. If you do this, you will experience that the bar for setting up new projects is drastically lowered. Maintaining existing ones also becomes a lot easier, and, as a final bonus, you can now write code that deploys and verifies your infrastructure components - "unit tests" for your infrastructure code!

Sharing infrastructure as code with linked Azure Resource Manager templates

Have you ever needed to combine different Maybe-values to produce another value? In this article, we explore just that.

Let us say that we are given the task to implement a function that combines two values to some other type if, and only if, both values are present. For example, consider the following toContactPerson function:

This function is trivial to implement, at least if you are somewhat familiar with the Maybe type. With standard pattern-matching, toContactPerson can be implemented like this:

Simple enough, but you may have already noticed that this implementation is somewhat strenuous to read. Now, imagine how it would read if we expanded the ContactPerson record with additional fields such as address, phone number, email, etc. Not very pleasant!

Another, arguably much more readable, approach is to use the utility functions Maybe.map2, Maybe.map3, Maybe.map4, and so on. While Maybe.map takes a function a -> b and a Maybe a, Maybe.map2 takes a function a -> b -> c and two Maybes, Maybe a and Maybe b. The mapping function is applied if, and only if, both values are present. With Maybe.map2, our toContactPerson function can be improved to:

or if we exploit partial application:

Expanding ContactPerson further with more properties is also trivial:

Notice that there is no Maybe.map6 or above in the standard library of Elm. Consequently, if we shall ever need them, we have to get them elsewhere. We can either implement them ourselves or just use the Maybe.mapN-capabilities of the Maybe.Extra-library. Although, the need for Maybe.map6 and above can often be avoided by handling the Maybes at an earlier stage. If we, for example, are dealing with a form with multiple steps, we may be able to extract some of the values from their Maybe-wrapper before continuing to the next step in the form. At least the required fields, that is. In other words, it is often a good idea to check if the Maybes can be handled at an earlier stage before reaching for these functions.

Combining Maybes in Elm

En dag i november fikk jeg en AHA-opplevelse. Den gode, deilige følelsen hvor alt gir mening, hvor jeg følte meg et par kilo lettere. En ny sammenheng ble oppdaget, da jeg begynte å reflektere rundt at et produktteam, og spesielt samarbeid med ulike utviklere, på mange måter kan sammenlignes med et parforhold.

For å få et forhold til å fungere må det pleies. Man må sette av tid til hverandre og jobbe med å forstå hverandre, men i en travel hverdagen er dette vanskelig. Fokuset ligger for ofte på det som ikke fungerer. På frustrasjon over at den andre parten ikke tar med seg søpla når man forlater leiligheten, eller at man selv føler at man bidrar mer på hjemmefronten enn den andre.

Siden det er desember føler jeg meg ekstra kjærlig og gavmild. Jeg vil derfor dele hvordan jeg fikk denne aha-opplevelsen, inspirere flere til å se på samarbeid med kollegaer på en ny måte, og gi et aldri så lite tips til noe som gjorde mitt samarbeid med utviklerne mye bedre.

Disclaimer: La meg bare si at det ikke er meningen å dra alle over en kam, slik som de gjør i boken “Menn er fra Mars, kvinner Venus”. Jeg er fullt klar over at utviklere ikke er en homogen gruppe, ei heller interaksjonsdesignere. Vi er alle unike snøfnugg, og ting er ikke så verst på prosjektet heller. Sånn. La oss gå tilbake til historien.

Hverdagsproblematikken

Som interaksjonsdesigner opplever jeg ofte på prosjekt, og i prat med andre designere og utviklere, at samarbeidet mellom disse fagdisiplinene ofte byr på de samme og gjentagende utfordringene. Som eneste designer på teamet, har jeg behov for å gå gjennom en tankerekke, få feedback og forslag til hvordan utføre brukertester og intervju, idémyldre rundt løsninger på problemer, og sparring på skisser både fra et brukerperspektiv, men også fra et teknisk ståsted.

Når jeg står i disse prosessene og spør om hjelp, opplever jeg stadig at motivasjonen til å hjelpe meg er noe lav hos utviklerne.. “Det ser jo bra ut”, er svaret jeg ofte får, før de legger til at de absolutt ikke har noe mer å legge til. Thanks... Det er litt som når du spør om å få en mening fra typen om hva du skal ha på deg, og svaret er “alle kjolene ser fine ut”, før han vender blikket ned mot mobilen igjen. Jeg sitter ofte igjen og kjenner på en liten klump med ubehag.

Hvorfor er ikke utvikleren interessert? Sa jeg noe feil? Burde jeg ha gjort prosessen på en annen måte? Har jeg en forventning om at utviklerne ikke er motivert, og at jeg gjør det til et større problem enn det det egentlig er? Til syvende og sist, sitter jeg igjen med spørsmålet: er det så vanskelig å bare hjelpe meg litt, vi skal jo tross alt utvikle tjenesten sammen?

Oppvaskmøtet eller familierådet

I dag har vi et slags oppvaskmøte eller familieråd, som oftest kalles for retro i vår bransje. Hver fredag tester vi ut ulike metodikker, for å snakke om hvordan samarbeidet går. Dette er et kjempefint utgangspunkt for å ta tempen på samarbeidet. Overordnet ligger fokuset på hva som fungerer bra, hva vi bør stoppe å gjøre, og hva vi bør begynne med. Jeg tar ofte opp mitt behov og ønske om hjelp fra utviklerne i innsiktsfasen, at de ikke kan forvente at det bare skal ligge en skisse klart til utvikling, og når vi først tar tak i en oppgave så skal vi kontinuerlig samarbeide frem til vi har satt den i produksjon. Der og da både føler og tror jeg at vi er enige. Vi ER så enige! Med ny giv og energi setter vi i gang med de nye tiltakene som nok en gang skal redde oss fra et litt dysfunksjonelt arbeidsforhold. Helt til det går noen dager – toppen en uke. Og vi er tilbake der vi startet. Med vår noe humpete, luggete og lite dynamiske forhold. Litt som i et parforhold. Noen vaner er vanskeligere å endre enn andre.

Det var da det slo meg, den dagen i november. At i retroene har vi et for stort fokus på prosess, og på hva som ikke fungerer med den. Fokuset ligger på hvordan vi kan bli mer smidig, og få ting rett ut i produksjon. Generelt er mengden med negative post-it-lapper mye større enn de positive. Likeledes er fokuset vårt, etter at alle post-it-lappene er lest opp, på hva som ikke fungerer. Sjeldent hylles det som faktisk er bra i mer enn et par sekunder, før fokuset går over til det som ikke fungerer.

Jeg deler mine behov og ønsker om tiltak, men jeg/teamet tar oss sjeldent tid til den type samtalen om hvordan alle opplevde det, for retroen varer tross alt i én time. Vi stiller sjeldent spørsmål om hvordan hver enkelt føler at prosessen gikk, ble behovet deres møtt, og hvorfor tenker og føler man det slik? Jeg kjenner på en følelse av lettelse etter en diskusjon om en post-it-lapp. Samtidig sitter jeg igjen med at vi ikke kom helt til bunns i hvorfor ting er som det er.

Jeg får ikke den magiske følelsen som når man sitter i sofaen med kjæresten, hvor man bare lytter til hverandre, og forstår at man har bare misforstått hverandre. Vi snakker to forskjellig språk. Gary Chapman (2001) sier at man tar imot og viser kjærlighet overfor hverandre på fem ulike språk, og når man forstår hvilken kjærlighetsspråk den andre parten uttrykker, åpner det seg en helt ny verden fylt av ny kjærlig. Sånn er det også for oss ux- og visuelle designere, forretningsutviklere, front-, back- og full stack-utviklere. Vi snakker forskjellig kjærlighetsspråk overfor tjenesten vi lager. Vi har ulike interesser og fokus, men vi vil alle lage den beste tjenesten.

Vi må snakke sammen

Etter den magiske AHA-opplevelsen bestemte jeg meg for å kalle inn utviklerne til en litt uformell prat, for å forstå deres behov. Litt sånn som man gjør med kjæresten, hvor man innleder med “vi må snakke sammen”. Jeg ville spesielt forstå mer rundt hvordan det oppleves å være med på innsiktsfasen, og hvordan jeg kunne tilrettelegge og tilpasse meg, slik at jeg møter deres behov. Jeg trengte å få bekreftet/avkreftet om prosessen vår ikke bare føltes unaturlig ut for meg, men for resten av teamet, eller om jeg rett og slett har overtenkt alt, og at ting er fint for dem.

For å ikke overkomplisere det, tegnet jeg opp prosessen vår ekstremt overordnet i Miro – Innsikt, bygge og teste. Først satt vi hver for oss og skrev ned post-it-lapper om hva vi likte å jobbe med og hva som kunne oppleves som utfordrende i de ulike fasene innenfor produktutvikling. For hver lapp alle på teamet delte, stilte jeg oppfølgingsspørsmål for å virkelig forstå deres perspektiv, behov og motivasjon. Rett og slett for å kartlegge og forstå deres kjærlighetsspråk. Det var da jeg endelig fikk kjenne på den magiske følelsen av å forstå utviklerne på et nytt plan. De uttrykte at de veldig gjerne ville være med på innsiktsfasen, men følte ofte at de ikke hadde kompetansen til å bidra, som igjen forklarte den lave responsen. Og vi fikk snakket om hva som fungerte og ikke på en ny måte, fordi vi satt våre behov først.

Lykkelig avslutning

Ikke tolk denne artikkelen som at du skal begynne å se på utviklerne på teamet ditt som kjærestene dine, men noen ganger kan det være fint å sammenligne team-relasjonen med et parforhold. I hverdagen har man mest fokus på hva som ikke fungerer, og hva som kan være bedre. Det er vel litt sånn vi mennesker er bygd opp. Og en gang iblant trenger man å faktisk ta seg tid til å snakke om hverandres behov, om de blir møtt, samt hva man ønsker mer av i forholdet. Og i disse corona-times, kan det være ekstra fint å dyrke og bruke tid det på det som faktisk er bra.

Jeg lovet dere et aldri så lite tips også, og her kommer det:

For at innsiktsfasen skal bestå av et samarbeid mellom utviklere, forretningsutviklere og designer, gjennomfører vi innsiktsfasen cirka en uke før planlagt start på utvikling av ny eller forbedret funksjonalitet. Vi er tydeligere på hva vi har behov for av kompetanse, og hvordan vi kan og ikke hjelpe hverandre. Når Jira-oppgaven er klar til utvikling, er det tilfeldig hvilken utvikler som faktisk skal utvikle oppgaven. Skissene ligger klare, så utvikleren ikke blir frustrert. Til slutt, har det at flere utviklere bidrar på ulike faser av en funksjonalitet ført til en økt forståelse for hva vi bygger!

Kan et produktteam sammenlignes med et parforhold? 

Det er viktig å forstå hvilket strategimiljø du opererer i når du staker ut retning for fremtidig lønnsomhet. Både effektivisering for å redusere utgifter og utforskning av revolusjonerende forretningsideer har en investeringskostnad igjennom arbeidet for å realisere planene. Og genvinstrealiseringen i ulike strategiske miljøer har ulik hastighet.

Den kreative tankegangen som må til for å utvikle prosjekter innen de 4 mest nærliggende strategimiljøene beskrevet i «Your strategy needs a strategy» sier oss litt om hvor mye arbeid som går med til utvikling og hvor fort det går å hente ut gevinster.

4 kreative tankesett

Hva kreves det av tankearbeid for å finne en lønnsom mulighet i et av disse fire strategimiljøene? Her følger eksempler på hvordan du må tenke, og en lettbeint analyse av hva det vil koste å nå frem til lønnsomhet i realisering.

Klassisk miljø – direkte/sekvenstankegang

I et klassisk strategisk prosjekt handler mye om å finne et lønnsomt målbildet og sette opp en sekvens av tiltak som tar deg til målet. Tankesettet er da direkte, eller målrettet. Jo enklere hvert steg på veien er å gjennomføre, forutsatt at du opprettholder kvalitetsnivået som er nødvendig for å konkurrere i markedet med leveransen, jo raskere kan du realisere gevinst.

Dette passer til små, store og veldig store prosjekter. Eksempler kan være alt fra bytte av regnskapssystem til bygging av en demning.

Direkte tankegang er effektivt, rett på sak, og på den måten kostnadseffektivt. Det vil generere det resultatet du har satt deg fore å realisere, og er business case’et godt er gevinstrealiseringen rask.

Visjonært miljø – divergent tankegang

Hvis du skal utvikle en ny medisin kan det være aktuelt å se for seg at både teknologi og andre medisiner eller behandlingsformer som er under utvikling nå har lykkes før du kan realisere din ide. I det fremtisdscenariet kan du bruke divergent tankegang (utforske i forskjellige retninger) rundt din definerte visjon for fremtiden.

Dette er krevende arbeidet, både i forhold til analyser som kreves for å støtte opp under fremtidsvisjonen og i forhold til tankesettet som krever at du lever deg inn i denne fremtidige verden.

Divergent tankesett benyttes mye i forskning der verdiskapningen er kjent, men løsningene krever utforskning av mange nye og tidvis abstrakte løsningsforslag.

Men kjenner du til modellen for divergent tankegang, kan du kanskje komme raskere til antagelser om hvilken verdi som er attraktiv å realisere, og på den måten velge en lønnsom fremtidsvisjon å utforske.

Adaptivt miljø – assosiativ tankegang

De fleste som har jobbet med markedsføring er godt vant til assosiativ tankegang. Å forestille seg en liknende løsning som sine beste konkurrenter, med en liten vri kan gi en unik posisjon i markedet. Det er ikke alltid så viktig å tenke at løsningen du velger skal tilby en forbedret verdi eller reel innovasjon for kunden. Hvis kundene flokker seg rundt deg, så vinner du. I alle fall inntil videre.

Hvis det er enkelt å rimelig for deg å finne en unik posisjon ovenfor kunden, er det tilsvarende enkelt og raskt for konkurrenter som tenker på samme måten å finne den neste unike posisjonen, og du blir utkonkurrert.

Det er dog noen veldig positive sider ved å innse at du befinner deg i et adaptivt strategisk miljø. Assosiativ tenkning i digital produktutvikling er ofte mye mer fleksibel i forhold til å finne gode måter å tilfredsstille kunders behov en det en direkte målrettet tankegang. Og vesentlig raskere og billigere en både divergent (visjonær) og kognitiv (skapende).

Skapende miljø – kognitiv tankegang

Med kognitiv tankegang menes det å tilegne seg kunnskap og forstå. Dette er en omfattende måte å tenke på, der utforskning av ulike alternativer er hovedmetoden for å «bevise» at forretningsideen vil løse problemer for kunder.

Dette er helt grunnleggende i innovasjonsarbeidet og brukes ofte som modell for hvordan nye smidige organisasjoner skal drive videreutvikling i autonome team. Å finne ut hvilken forretningshypotese som løser problemer mest effektivt ved å bygge prototyper og teste ideene er solid utforskning, men dette er dyrt. Det tar lang tid, og hvis du ikke har flaks å treffer den beste veien mot en løsning på første forsøk, kan du risikere å føle deg bundet til å fortsette utforskning som ikke treffer et mål. Innser du at du har gått feil vei og må gå tilbake for å velge en ny vei løper både kostnader og tid.

Men denne tankegangen bærer frukter. Grundig og strukturert kognitiv utforskning endrer verden og innovasjon eller disrupsjon har vist seg å være svært lønnsomt.

Kilde:

«Your strategy needs a strategy» (Janmejaya Sinha, Knut Haanaes og Martin Reeves)

Bør kreativt tankesett styres av strategivalget?

Utviklere har en superkraft; de besitter selv nesten alt som skal til for å bygge et lønnsomt selskap.

Vi tar en prat med Kyrre Wathne, en utvikler som nylig (igjen) har solgt et selskap som han selv startet.

Fra utvikler til seriegründer

If you are well-versed in the JavasScript-universe, you probably know that functions are also objects in JavaScript. Everything you can do with regular objects and values, you can do with functions as well. You can pass them as parameters to other functions, declare them as variables or pass them around as you’d like. Since functions can be passed as parameters or returned as an output from another function, this has enabled higher-order functions to be built into the language.

In this article I will demonstrate how higher-order functions have allowed me to write readable and more maintainable code with fewer bugs, and how it coincidentally completely removed the need to write for-loops in my code!

But, what on earth is a higher-order function? Higher-order functions stem from the functional programming paradigm, and it is defined as a function that receives a function as an argument, or returns the function as an output.\ \ During the release of ES5, a number of higher-order functions were exposed as methods on the Array-prototype, meaning that these functions became available to every array in the JavaScript-ecosystem. The introduction of these methods massively changed the way I work with data in JavaScript, and I will now provide examples from a simple application where I display both the power and simplicity of these higher-order functions.

The Duckburg Lottery

Duckburg is about to hold a city lottery, and there are several hopeful contestants wanting to join Scrooge McDuck in the money bin. In this given lottery, a Duckburg-resident chooses a total of three numbers ranging from 1 to 99, and in order to win the grand prize, the lottery-contestants need guess all three numbers correctly. Accomplishing so grants you a total prize of a whopping $1,000,000!

First of all, the organizers want to know which of the residents are participating in the lottery, and they have tasked us with displaying it. The list of contestants is given on the following form:

\ In this given example, a simple for-loop could do the trick for us. We could loop through the contestants and append their names to a newly created array and log out the result. It could look something like this:

Even though this solution does the trick, wouldn’t it be better if JavaScript could abstract some of this logic away for us? It seems bothersome to have to create a new array manually each time we want to access properties from an existing array.

Introducing map()

As mentioned earlier, a number of higher-order functions is available to the Array-prototype, and Array.prototype.map() might do wonders for us in this example. map() is a non-destructive transformation method which takes an existing array as input and produces an output array, based on a callback function which controls how the new array should be transformed. The callback function is called on each item in the existing array and the return value of this function is added to a newly created array. The map-method returns the transformed array while leaving the original array unchanged!

In our task of displaying the names of the contestants in the lottery, we can now specify a callback function to be run on each item in the contestant-array, and all it has to do is return the name-property of a given contestant:

Instead of initiating a new array, writing a for-loop and pushing items to a new array, we now changed it to be a one-liner which returns a new array containing the names of the contestants! Also note that the original array is intact, and that the map-method returns a completely new array, making it a pure function with no dangerous side effect.\ \ However, just displaying the lottery contestants is not enough. We have now been tasked with determining which contestant has won the lottery and can join Scrooge McDuck in the money bin!

Extracting the winners of the lottery could be solved using plain for-loops and manual iteration:

Now, this is quite a mess. Double for-loops are rarely a pleasant sight to behold. In this example we need multiple loops, one for contestants, and one for each contestant’s lottery-numbers. By iterating through the numbers and asserting that each number is included in the winning numbers array, we can determine that Gladstone Gander was lucky enough to win the lottery (who would’ve thought, right?). But, surely there must be a simpler way to accomplish this rather than double for-loops? Could there possibly exist some higher-order functions in JavaScript which can do the trick us?

Filter to the rescue!

Array.prototype.filter() works similarly to map(), being a non-destructive function which iterates through each item in an existing array. The key difference between filter and map is that filter accepts a function predicate as the callback function, which is a function that returns a boolean value. The result of this predicate function determines whether the element should be included in the array. In short, it filters out values that do not pass the function predicate-test.\ \ Another method available to us on the Array-prototype is Array.prototype.every(). This method returns a boolean value, and it tests whether every element in the array passes the test implemented by the provided function. If every element passes the test, it returns the value true.\ \ Now, let’s try to apply these higher-order functions to our lottery application to determine the winner(s) of the lottery.

While the previous example consisted of double for-loops and manual iteration of the two arrays, this solution actually accomplishes the same feature as the previous example in just one line, by using two of the built-in higher-order functions in JavaScript! Since filter() can transform our contestants-array the way we want, we can apply every() as the function predicate to our filter function. This method returns true if all lottery-numbers are included in the winning-numbers-array, and thus only the winners of the lottery are added to our winners-array.

Computing with reduce

Now, after the lottery result is official, the organizers of the Duckburg-lottery have given us one final task. They want to know how much prize money they have to pay out to the winners of the lottery. As mentioned earlier, the winners of the lottery got a whopping prize of $1,000,000.\ \ Now, we need to compute a single value based on data from our array. We need to apply the same logic as when determining the winners of the lottery, but we need to accumulate a single value based on the data instead of creating a new array with winners. Array.prototype.reduce() is the higher-order-function that represents this pattern. Reduce builds a value by repeatedly taking a single element from the array and combining it with the current value. The parameters to the reduce-method is a combiner-function as well as a start value. The combiner-function takes two parameters, the accumulated value based on the iteration up until now and the next item in the array.\ \ In order to determine the prize money to be paid out for the lottery we can utilize the reduce-method like this:

Summary

The ability to pass functions as values to other functions is a very useful aspect of JavaScript. Higher-order functions allow for abstraction of iteration, filtering and value accumulation, and enable developers to instead focus on clean and readable code.\ The fact that higher-order functions are data-type agnostic when operating on data is also a nice feature, meaning that filter() works just as well filtering on strings as it does on numbers or any other data type you might specify in your function argument.\ \ Another key feature that the higher-order functions enforce is loose immutability. You never have to worry about mutating the existing array and having weird side effects, instead you create new values which you either can chain with another higher-order function or you can consume them later in your program.

Higher-order functions have certainly made my daily life as a JavaScript-developer much easier, and as a nice little bonus, I have stopped writing manual for-loops!

Higher-order functions in JavaScript

Looking for some inspiration? Something to learn? Here we give you a list of interesting people we follow. These people are worth listening to.



@troyhunt

Creator of haveibeenpwned.com. Active author and speaker. https://troyhunt.com



@scott_helme

Security researcher, entrepreneur and speaker. Creator of Report URI and Security Headers. https://scotthelme.co.uk/



@LiveOverflow

Making videos about various IT-security topics. Active participant in hacking competitions. Check out his YouTube-channel.



@thorsheim

Promoter of security & privacy, security evangelist. Founder of PasswordsCon.



@samykamkar

The man behind Samy Worm on MySpace, and a lot more. Visit samy.pl.



@briankrebs

Independent investigative journalist. Covers cybercrime, security and privacy. Author of 'Spam Nation'. Visit his blog.



@kevinmitnick

Chief Hacking Officer, security consultant, public speaker and author. Previously on FBI's most wanted list. https://www.mitnicksecurity.co



@stokfredrik

YouTube BugBounty profile. Security expert, hacker, speaker. Check out his YouTube-channel and https://www.stokfredrik.com/



@pati_gallardo

Founder of TurtleSec. Passionate about infosec, secure programming and security culture. Author and speaker. Visit patricia.no



@tawaterhouse

Worked on IT policy and politics at ICT Norway for approx 12 years. Speaker and author.



@dinodaizovi

Head of Security for Cash App at Square. Information security industry veteran. Active speaker and co-author of "The Art of Software Security Testing" and "The iOS Hacker's Handbook", among others. https://theta44.org/



@malwaretechblog

Marcus Hutchins, stopped WannaCry. Cybersecurity, malware, hacking, programming and infosec. https://www.malwaretech.com



@secdefence

Roar Thon from the Norwegian National Security Authority. Also co-hosting their podcast.

14-Dec

Today's posts