Working with lists in Elm is nice, but getting a sense of what’s inside a list can be tricky. In this article we will look at a techinque that allows us to get access to the elements inside a list.

We will start by looking at a somewhat finicky example. Let's say we have a list of text notes in our app, that we want to display. If there are multiple notes in the list, we would like to show all the elements in their minimized form. If there is only one note in the list, we would like to show a maximized view of that note, since showing a list with only one element is a waste in that case. And lastly, if the list is empty, we would like to display a message saying that the list is empty.

To meet those requirements, we could write something like this:

Now, this function is fine. But it could be a lot simpler! The main problem is in the case where we have only one text note. When we have entered the first branch of the if-statement, we know that there is exactly one element in the list, but we still have to use List.first to get access to that element. And since the compiler doesn't know that there is a first element in the list, we still have to account for the Nothing-case.

Wouldn't it be nice if we could get access to the elements inside the list at the same time as we got information about the structure of the list? Well sure, and there is actually a way to do this in Elm.

Pattern Matching on Lists

Before we get to the solution, let's take a short detour through list making. In Elm, we can create lists in multiple ways. We can use square brackets to create them: [ 1, 2, 3 ]. We can use functions, like List.singleton 1 (which results in the list [ 1 ]). We can also use the :: operator from the List module. The :: operator works by adding an element to the start of a list, like this:

Now, the :: operator is used for creating lists, but it can also be used to pattern match on lists in case-statements! Let's take a look at an example:

As we can see from the example, pattern matching on lists gives us information about the shape of the list at the same time that we get access to the elements in the list!

Let's use this technique to rewrite our view function from before:

Doesn't this look way better?

There are many more things you can do with pattern matching on lists, which we don't have time to get into today. But I suggest that you experiment to see what is possible! You could for instance get access to multiple elements (first :: second :: rest), or reverse the list (with List.reverse) and get access to the elements from the back. The possibilities aren't quite endless, but there are at least a long list of them.

Peeking Inside Lists

Cryptography is the science of secret writing with the goal of hiding the meaning of a message. When a message is encrypted with a secure algorithm, i.e. an encryption cipher, no one should be able to read it without the decryption key. However, the promise of security falls apart if the encryption algorithm is weak, or if someone has created a backdoor. In this article we’ll examine the modern history of encryption. We’ll learn that while the mathematical underpinnings of modern encryption is stronger than ever, government agencies have a history of thwarting efforts to reach the goal of truly secure communication.

The world’s first encryption ciphers often used algorithms that were themselves secret. The rather intuitive belief that security increases if the encryption details are hidden is a misconception, and is often referred to as security by obscurity. The algorithms that dominate the modern era rely on full openness, in accordance with Kerckhoffs's principle:

A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.

This transparency allows the rest of the world to attempt to break the cipher. Every failed attempt at breaking a cipher reinforces the belief that it is secure. While there is a chance that someone breaks a cipher and does not report it, there is a far greater chance that a homemade algorithm will be broken easily.

A big moment in cryptographic history

Up until 1972 there was no standard cipher for encrypting secret messages. The US National Bureau of Standards (NBS), which later became the National Institute for Standards and Technology (NIST), started an initiative for finding a single secure algorithm. This was rather revolutionary. The American government had traditionally kept their knowledge of cryptography to themselves - they considered it to be crucial to national security. As a result of the NIST initiative, several ciphers were proposed as candidates for the first encryption standard.

The most promising candidate was contributed by a team of cryptographers working at IBM. They developed a refined version of an earlier encryption cipher called Lucifer, which was first developed by Horst Feistel in the late 1960s. Their candidate was a block cipher with a key size of 128 bits. A block cipher is an algorithm that encrypts several bits at a time, i.e. a block of bits, as opposed to stream ciphers that encrypts bit by bit. A sufficiently large key size is necessary for a cipher to withstand brute force attacks, since these attacks generate all possible decryption keys. In context of a brute force attack, one would say that the larger the key size the more robust the cipher.

Speculation of NSA backdoors

When the NIST examined the security of the cipher candidates, they reached out to the National Security Agency (NSA) for assistance. At this point in time the NSA did not even admit their own existence. The involvement of the NSA lead to speculation and rumors, since the cipher went through a couple of peculiar alterations during the cooperation between NSA and IBM.

The most worrying change was that the key size was reduced from 128 bits to 56 bits. This made the cipher considerably less resistant to brute force attacks. Concerns were raised that this change was motivated by the NSA, in order to provide themselves with a backdoor. Maybe their computers were powerful enough to brute force a key size of 56 bits – but not quite powerful enough to brute force a key size of 128 bits?

The cipher was also altered to be resistant to attacks using differential cryptanalysis. That doesn’t sound too bad, but this particular attack was not known to the public until 1990 – almost 20 years later! If the NSA were familiar with an attack the world would need 20 more years to discover, it is not hard to believe that they might be able to brute force a 56 bit key. However, it should be noted that none of these claims have been proven.

In 1977, the NIST presented an altered version of the IBM cipher as the new standard, which they named the Data Encryption Standard (DES). It became the first modern, public, freely available encryption algorithm. All details regarding DES were made public, which is good practice since it allows researchers to scrutinize the mathematical details. However, the motivation for the design criteria remained secret. The public never learned why the key size was reduced, and this was the main cause for suspicion regarding the involvement of the NSA.

DES cracked through brute force attack

DES was initially meant to be the standard cipher for encryption for 10 years; from 1977 to 1987. But no serious weakness was found, and DES went on to reign as the standard algorithm for more than a decade past its due; until 1999. In the final years of DES, several attempts were made to design and build a machine to brute force it. Building such a machine would cost millions of dollars. It was speculated that only government agencies would have the necessary financial resources to build it, and by this time it was widely believed that the NSA could in fact crack DES.

As the price of hardware fell, the Electronic Frontier Foundation (EFF) built the machine Deep Crack. In 1998 Deep Crack was able to brute force DES in 56 hours. This event demonstrated that it was time to select a new standard cipher for encryption.

In 1997, the NIST initiated an open competition to find a new standard encryption cipher. The competition had five finalists: Rijndael, Mars, RC6, Serpent and Twofish. This time the selection process was completely transparent. In 2001, after three competitive rounds and intense cryptanalysis by the world’s foremost experts, the decision was made. The cipher Rijndael, designed by the Belgian cryptographers Joan Daemen and Vincent Rijmen, was declared as the new standard. It was given the name Advanced Encryption Standard (AES). This cipher has three possible key sizes: 128 bit, 192 bit and 256 bit. All these key sizes were sufficiently large to withstand brute force attacks.

AES is widely regarded as the most secure encryption cipher invented. It has been battle-tested for decades and is expected to remain the standard cipher for many years to come. So far there are neither any known critical weaknesses, nor suspicion of backdoors.

Attempts at legalizing government backdoors

Algorithms have matured to be practically unbreakable, but current legislative measures attempt to undermine the basic purpose of cryptography. There are recurrent proposals for allowing government backdoors. For instance, the recently proposed Lawful Access to Encrypted Data Act aims to force technology companies to implement backdoors. The right to privacy ends when the government institutions deem it useful to their own agenda. If such a law were to pass, the consequences would be immediate and severe. It would grant immense power to the government, and if a key is leaked or stolen, all encrypted communications are out in the open. Lawmakers argue that having a backdoor would help fight crime and terrorism, but this view assumes that criminals play by the rules and communicate through services using government issued encryption.

In the modern era the goal of private digital communication is, from a technological standpoint, a solved problem. It remains to see if future citizens will be able to enjoy digital privacy in their lives. It’s a question of balancing power between the government and the people – and problems of that nature are not solved as elegantly as cryptographic puzzles.

If you want to go further down the rabbit hole, I highly recommend listening to the following episode of the Darknet Diaries podcast: Episode 12 - Crypto Wars.

The secretive history of modern cryptography

A story about trying to use the Wizard of OZ method adding new functionality to our client’s product.

What is Wizard of OZ?

Wizard of OZ is a method of prototyping and testing a product or functionality. You have to trick the user to believe that the product or service they are using is automated or fully functional when it in reality isn’t. Behind the curtain is actually someone that is manually faking everything or part of what’s happening. It is important that the user doesn’t know this, and use the product as if it was a real product, giving real feedback.

A perfect example to explain this is voice interfaces (like Siri or Alexa). Making a voice interface is not easy, and probably expensive. So before you decide that you want to have a voice interface in your product you should test it. Is it worth spending all that time and money on? The good news is that testing it might not be that hard! Instead of actually making a working code to understand and process language, you could just have someone listening with a microphone, writing or doing the commands from the user, pretending to be a machine. Then you would get insights into how “smart” this voice interface have to be, and if it’s actually working as you hoped.



The Wizard of Oz method is perfect in the situation where functionality is expensive or very difficult to make, but faking it is easy.

The name “Wizard of Oz” is a reference to the book The Wonderful Wizard of Oz written by author L. Frank Baum in 1900 (and the iconic 1939 live-action film). Where a man hides behind a curtain pretending to be a mighty wizard by using different methods of changing his voice and projecting himself as a huge green head.



So lest try this method!

We got the task of making a notification system for a register we're responsible to maintain and develop. This register contains a lot of data collected from many different sources and the only way a user can find out if any of the data is changed is actually to search for it and look around. So our goal was to make the register more active in telling the user when something had changed.

Not easy to do, and we had a lot of questions. What would be interesting for the user to know? Notifications for everything would be overload? How do they want to get notified? When does it make sense to notify? How do they choose what to get notified about? etc...

We did have something that we felt was a big task and would take us a long time to make right. But we could fake it! with just a little research combined with a bit of guessing and good knowledge of how the registry worked. Being bold, we told the product owners that we wanted to test this and that we would have some sort of prototype/MVP finished within a month. Hoping this would be a quick way to get real feedback.

When a month, and probably a half, had gone we launched! The product we launched was an office form where you could sign up to get notifications. The notifications were e-mails. One of our developers had to manually check all the responses from the form to see what notifications the user had signed up for. Then register their e-mail address into a very simple* code he had made for the purpose of the prototype. If they wanted to stop the notifications they had to answer the e-mail with “stop” so we could remove them from the code again.



Our plan was to run this for a month to collect feedback and data. Then use that feedback to actually begin making a “real” notification system. This did not happen. This Wizard of Oz prototype did run for almost a year. So what did go wrong? And what worked?

Let’s start with the things that went wrong. The prototype seemed to work so well that our product owners wanted to prioritize other things. Thinking back at it, we probably, or obviously, did not explain this well enough before we started. This was, understandably, a completely different way of making IT from what they were used to. When we wanted to shut it down because of some errors that were invisible to the users, making it dangerous if they started to trust the prototype too much. We still did not get a “go” for shutting it down. Because the money to finish this was already spent on other things, and it’s obviously better with something a little unstable than nothing. (Or is it?)

But on the happy side, we did get a lot of feedback from users that we normally struggled to get in touch with. And the feedback we got was of better “quality” and more relevant than we probably would have gotten just by asking. We got to test a lot of functionality and the user experience of using something “real”. Some of what we learned was that getting notifications on e-mail actually worked really nice because the users are familiar with it and they get everything in “one place”. Someone actually discovered something that looked like fraud from one of the notifications. And some of our notification missed information that we did not know that they needed.

Staring on this project again this coming year, we have much more knowledge and several users that already are invested. We have much more insights than I think we would have gotten out of a “normal” research phase. And we have not used that much money on doing it. Hopefully, we will also learn from our errors communicating projects like this in the future 😅





*Simple might be a very incorrect way of describing code by a designer that does not know a lot about code. (But it was written fast, and the developer hates it himself.)

Getting to know The Wizard of Oz 

Innovasjon er en kreativ prosess som ikke må begrenses av strenge føringer. Eller? Kan man formulere rammer som bidrar og ikke er til hinder for til nyskaping?

Pia Solheim, Hilde Marie Flesland Torall og Jens Andreas Huseby diskuterer.

Trenger vi rammer for innovasjonsarbeidet?

Back in 2017, my team were working on a feature-packed, widely used mobile app with a legacy codebase. The app had way too much logic, logic of the complex sort, with loads of very old code calling old APIs. Build times were terrible. Noone had a complete understanding of the code.

To make matters worse: the company behind the app were in the middle of a perfect storm. The business was being changed by regulation. The core business idea were changing. This meant large changes coming to the digital side, including the app.

Naturally, we had quite mixed feelings about our ability to meet delivery expectations from the business side, given the bad state of the app codebase. We were at a crossroads, and felt we had to pick one of the following:

Negotiate a feature timeout while we frantically renovate the core code, or

Start a long-term migration plan towards a hybrid app, or

Write new features in React Native and eventually move all the JS code over to a new app shell

We decided to try out React Native. Roughly three years later, the app is now 100% JavaScript. The big business transformation has come a long way, and I’ve experienced that React Native as a technology has played a key role in that success.

This article contains some reflections on why switching from pure native technologies to React Native worked so well for us.

Starting Out Small Felt Really Safe

We gave React Natives two tests. First, we wrote a small feature with a few developers. Futhermore, we did a larger, several-month feature where the entire team participated. A critical part of the tests was making sure that React Native would work as the small cogwheel it would necessarily start out as, inside of the large legacy app monster.

The people involved in each phase would evaluate the React Native developer experience, carefully considering if moving forward with React Native would be the right choice for us. After all, continuing with RN would mean a long migration process. Lots of our features would exist in the old, smelly native code for a long time, we would have to manually ensure backwards compatibility, handle (deep) navigation from old to new code (and vice verca), and lots of other things.

Even with these challenges in mind, the team were crystal clear post-testing. React Native made work easier, faster and more fun! In case we’d conclude differently, the investment made was so low that we could safely discard the effort as a proof-of-concept, where the learnings were enough to justify the time spent.

Trying out new technology this way just seems like a very smart way to do it. It was also key that it was the voice of the developers spending all day with the technology that weighed the most.

We Actually Did Develop New Features Much Faster

They say React Native save you half the work. Since your code will run on both iOS and Android, it eliminates the need to develop separate code for each platform. Write code once – not twice. Neat!

In our experience, this was mostly true. We did end up doing minor platform customizations here and there. Shadows don’t work as well on Android as iOS. Sometimes you’d want different UI behaviours to adhere to platform guidelines. And as with web development, you’ll encounter visual bugs for each platform that need special attention.

I’d say we saved about 45% of the work involved. It’s not half - but it still makes a tremendous difference on productivity!

It’s also hard to not talk about the productivity boost obtained by Hot Reload (now Fast Refresh). Seeing the effect of my last code edit presented visually on screen immediately (with state preserved) is simply marvelous. Scale up the time saved for each little change with the amount of the developers involved and the amount of time spent… it’s just huge!

All Developers Code For Both Platforms

I’ve met hundreds of fine developers, if not thousands. But those skilled and efficient in both native iOS and native Android development - I can count them on one hand. And they’re not exactly looking for work.

With React Native, we experienced that the entire team could do work for both platforms. It’s hard to overstate the importance of this fact. Instead of having dedicated iOS and Android teams, we’d have a feature being made by the same person (or small group) on both platforms, reducing the overhead involved in coordination and organization between devs and designers, business folks, product owners, etc. Also, fewer people needed to learn the ins and outs of that particular feature in a quite complex domain.

This provides great flexibility and robustness for a development team, and was much needed in our setting.

Recruitment and Onboarding

Not too many people are familiar with native mobile technologies. In comparison, capable JavaScript/React-developers come a dime a dozen. We found that finding talent was easier, and the newcomers found themselves productive way quicker than we’d expect. In a period with frantic scaling and expansion, this was critical.

I can imagine recruiting top-notch mobile development specialists is easier if you’re a huge company with infinite resources. In that case, you could staff the necessary amount of specialist teams for iOS and Android and just steamroll whatever you’re making.

In the Norwegian market, with finite resources, easing your requirements from «five years of Swift» to «five years of JavaScript experience» makes all the difference. The programming language in itself is one thing, but there’s also the ecosystem, development enviroment, IDE, etc. Apple make a lot of really sweet products, but XCode surely isn’t one of them.

Team Organization

Our old codebase was.. entangled. I imagine it would be challenging to attempt doing distributed development on the same codebase across several teams. At least when aiming for near-continuous delivery. Doing a Spotify-like product team organization with an app dev in each team seemed utopian at the time.

Over the course of a few years, we went from a dedicated mobile team of five to a product team organization with near 20 mobile developer spread across all teams. This would be much harder without the flexibility and familiarity of «it’s just JavaScript» or «it´s just React». Not having to invest as much time and energy in specialist competencies for iOS or Android, app devs have more cognitive surplus to work on other things as well - web, cloud stuff, backend, UX-collaboration, etc.

Deploy To Production At Will

Mobile apps have always had a longer way to production. The «quality control» mechanism with manual app reviews adds several days to the pipeline. The Apple App Store was alone responsible for up to a 14-day delay at it’s worst, although the wait times have been vastly reduced since then. Now they’re averaging at about a day.

A good dev team in 2020 will deploy to production many times each day. Looking at some of the biggest Norwegian apps today, it is not uncommon to see two-three-four week old builds as the most recent one.

The negative effects of not releasing your code often, and not even having the possibility to release at will, are well documented. React Native with it’s over the air-update called CodePush allows for continous delivery, even for mobile apps!

CodePush allows your app code to download the latest version of the compressed JavaScript bundle from a third-party server. When a user opens the app, the new bundle is downloaded and immediately installed. Voilà – immediate deploy to production!

Our app’s release cycle went from semi-monthly to several releases per day. Paired with great monitoring, this reduces the need for testing. Non-critical bugs can be tolerated to a larger degree if they don’t reach your entire audience before they’re automatically detected and shortly fixed.

Product development is also way faster. The team can iterate on small changes on real customers in production as a part of the development process, instead of lengthy sketching and laboratory user testing. This made the entire organization more customer-focused and impatient for real customer feedback.

A Note On The Rewrite

The whole codebase transformation to React Native took about two years. We only wrote already-planned new features in React Native, allowing us to be productive and produce new features during the process. The business transformation underway meant that most of the features would have required changes anyway, and it could actually be faster to implement them from scratch in React Native than to modify the legacy code.

This meant that we didn’t need a feature-freeze period with the team stuck on unproductive rewrite work. However, when most of the old app was rewritten, we needed a month-long cleanup to move all the separate features in the old app over to a new, fresh React Native repo.

From around March 2017 until June 2019 the app was in a state where some features existed in the old codebase and others in the new codebase. That wasn’t a pleasant situation, but not more unpleasant than working in the old legacy codebase before.

Status As We’re Looming On 2021

A total of 10,000 commits have been made by 33 contributors across 5 teams.. Nearly 50 pull-requests from 14 authors was merged the past week. Our ability to deliver on business requirements have been strengthened. Looking back on our big choice of 2017, it’s truly awe-inspiring to see how big an effect a simple technology choice can have on helping teams reach lofty goals.

No technology is a silver bullet. React Native surely isn’t either. But it does have some truly wonderful effects on an impatient, agile, modern development organization that Swift, Kotlin or C# currently can’t offer, in my opinion.

10,000 Commits Later - Switching to React Native in 2017

Last year I wrote an article explaining functors in simple terms and show why they are useful. It has well received, but some felt it was lacking in details which is true and by design. There is more to be said and some crucial details that I glossed over so I will try to address some of them now. Let’s get nerdy!

Functor as a context

In the previous article I said you could think of a functor as a structure or container that has a mapping function. This is not strictly wrong as it is one way of thinking about the concept, but can be a bit misleading and confusing as it does not fit all situations. For example a functions can in some cases be a functor. A structure might give us thoughts about data structures or types. Container is fitting when talking about lists or other types that can contain data. Is a function a structure or container? For this reason it is common to refer to some of the general concepts and abstractions we use in FP (functor, monad etc.) as contexts which has some properties.

The functor laws

Unlike my vague explanation in the previous article a functor is actually a very specific thing, and is defined by rules or properties the context has to adhere to. These laws come from mathematics, specifically a branch called Category Theory. This is an area that I will not claim much knowledge of but great minds have found similarities between this particular part of mathematics and what we do in programming.

In addition to having the map function, functors needs to follow some rules. The rules for functors are often called the functor laws. I'm not completely sure why. It might have something to do with math and also its sounds very sophisticated. :P Let’s get in on the sophistication!

1. Law of preservation of identity

The first law or rule of functors is that if the map function is given the identity function as its mapping function it will return the same functor. The identity function is just a function that has one argument which it returns right back (\x -> x in Elm or function(x){return x;} in JS).

Let’s use lists to visualize this a bit more. Elm actually has the identity function in its standard library so we will just use that one:

For the javascript example we will add the identify function inline:

When following this law the functor can not make any weird changes to the result. List.map someFunction [1,2,3,4] can never return an empty list. It can only map the function over the values. When mapping over a 4 item list, the returning list will always be a 4 item list.

2. Law of composition

The second law is not very complicated either but assumes that you know about composition. Lets quickly go through composition before looking at the next law.

Composition

Composition in functional programming (FP) is the ability to compose multiple functions into one single function. This is not often used in object oriented programming (OOP) but quite common in FP.

Composition is "gluing" functions together into one function. This is such a common thing to do that many languages have dedicated operators for this. Lets look at an example to see it in action to see why this might be useful. I'll be doing the examples in Elm as composition is a bit awkward in javascript and not that common.

Lets say you have a user record that has the fields name and age:

To get the age of a User record we can in Elm use an accessor function which is available for every field defined in a record.[^accessor] For the age field this function is called .age and has the type signature User -> Int. It takes a User type as an argument and returns a Int. In this case it is the content of the age field.

Go get the age from a user you would to:

At some point in your program you might have a User and need to display the age on a webpage, print it in a log or anything else that needs the age to be a string. To convert a Int into a String we can use the built-in function fromInt in the String module.

So where you have a user and need the age as a string you can use the compose operator in Elm to create a new function that gives you the user age as a string. I will write the type signatures for the functions as well so we can see how they fit together:

When the output of a function matches the input of another we can compose them together and make a new function that has the input of the first and output of the second. Note that >> is the rightwards compose operator.[^composeop]

The second law

Now that you hopefully know a bit about function composition lets look at the second law of functors. The rule says that composing functions into a single function and then mapping that function over the functor should produce the same result as mapping the individual functions over the functor in sequence. Lets look as some code to make sense of it:

In the example above we have a list of users and two constants[^const] that both are a list of the users’ ages as strings.

The first constant, agesThroughMaps, is defined using two map operations. The first run passes the .age accessor function to map and gives us a list of ages (of type Int). In the second map operation the String.fromInt is used to create a list of the users’ ages as String.

For the last constant, agesTthroughMaps, the list of the users age is created with one map operation where the function passed in to map is composed of the .age and fromInt functions with the compose operator (>>).

And this is the result of the second law: the values in the two constants should be equal. A list of strings: ["20", "22", "30"]

See full example in Ellie: https://ellie-app.com/bKhq8M4vyjYa1

The consequences of the laws

The laws might seem a bit random and not very helpful at first glance, but it can actually help us a lot. To be a functor the structure/container/context has to follow these laws. It can not do anything weird with the value/values in it or the function that is passed inn. The only thing it can do is apply the function to the value in the context. The functor might have some extra logic around when to apply the function. A list might be empty so there would be nothing to apply the function to and similarly with Maybe. Take a look at last years article to see a more complex example.

With these rules for what constitutes a functor in place the behavior of functors become predictable. So if we see it in code or talk about it with fellow coders we know exactly how it should behave! 😄

[^accessor]: You could use the syntax record.field_name as with JS objects (ex:user.age) as well but that does not serve our example that well. :P [^composeop]: There is a left compose as well. For our example it would look like: fromInt << .age and would create the same function. [^const]: In Elm all data structures are immutable and so are variables/binds so they are really constants. Elm does not support shadowing either.

Functors - Redux

Showing the audience a snippet of code can be an easy way of getting a complex concept across. Bekk being a tech-company it is inevitable that we will have to show code in our presentations at some point, which often leads to the question; how do I make my code look good?

Formatting your code by hand to make it look good is not a viable option if you are thinking of adding more than a few lines of code. And even with just a few lines, colour coding is going to be a pain.

The easiest way is to take a screenshot of the bit of code you need. This convenience comes with certain trade-offs, such as different font sizes between images, scaling and other oddities.

Enter Visual Studio Code

What seems to be the best way, is copying the highlighted code directly from Visual Studio Code and pasting it into your presentation.

This does not work right out of the box, so you will have to enable this functionality first. In Visual Studio Code, press F1 to find your keyboard shortcuts, and search for @command:editor.action.clipboardCopyWithSyntaxHighlightingAction (or start typing “CopyWith” and it should appear). This will, as the name suggests, allow the editor to add text with highlighted syntax to your clipboard.

Assign a keybinding to it, like Cmd+Shift+C and you are ready to copying code with proper formatting. Back in your presentation tool of choice, you can now paste your code and hey’presto there it is in all its colour coded glory. Or close enough. In the image below you can see the difference between code pasted into PowerPoint and Keynote.

The font-size is minuscule in the Keynote-presentation, but it maintains indents which is nice. PowerPoint has a better grasp on font-size, but lacks the indenting. Both issues are easy enough to fix.

Not too keen on using Visual Studio?

Sublime 3 has the same type of support using one of the many highlighting packages. Open your package management (Cmd+Shift+P), select the option for installing packages, and search for “highlight”.

There should be a number of options to chose from. The first candidate lets you copy colour coded syntax either as rich text or as HTML. Simply select the code and right click to access the two options.

PowerPoint disregarded the new lines, but the code is coloured correctly.

Taking it up a notch

If you really want to control the output of your code or you intend to turn use markdown to write your presentations, Pandoc is the tool for you.

Converting code to presentations is as easy as pandoc -o presentation.pptx code.md. This will convert a Markdown formatted document (code.md) into a PowerPoint document (presentation.pptx).

As with most command line tools, that’s just the tip of the iceberg. Pandoc is an immensely powerful tool for converting text and documents into a variety of different formats. Pandoc allows you to write your entire presentation as Markdown, with code included. 

This document can then be parsed using the following command: pandoc -o presentation.pptx code.md

Which should result in somehing like this: 

It's not perfect right out of the box, but with minimal effort your slides and code will look the part.

Showing code in presentations

Does it really matter which serialization library you choose for your application? They're all pretty much the same, right? Right... It's story time!

You've just started developing your new WishList application, and you have decided to go with Gson as your serialization library. Gson is a very popular library for serializing and deserializing Java objects and JSON, and you see no reason to use anything else just because you are working on a Kotlin application this time. You create your wish list api that expects a WishList payload. The payload consists of a list of wishes and the name of the person who made the wishes. The application will then save the wish list and a trimmed version of the owner's name to your database. The payload looks like this:

But soon after you have published the api, you notice NullPointerExceptions in the logs when the code calls name.trim(). But, you say to yourself, name is a non-null type, how can it be null? After a closer look you realize that someone sent a payload that was missing the name parameter:

Why doesn't this fail during deserialization? The answer is that Gson doesn't respect non-null types in Kotlin. The way Gson sets property values is by using a default constructor if it exists. The default constructor takes no arguments, and if we define a constructor ourselves that does take arguments (like we have done under the hood for the data class WishList), then the default constructor is no longer available. Then Gson will use reflection to set the property values, and since Gson is made for Java, it does not know that non-null types mean.

For the same reason, you may see a similar behaviour if you use default values in the constructor, like this:

Gson will not use the default value "Rudolph" if the name parameter is missing or null.

We may think this is a bug in Gson, but it's actually not: Gson does not provide any Kotlin-specific support, and is only meant to work with Java. Although this has been reported as a bug and as a feature request to Gson several times, it doesn't look like Gson will support default values and non-null types anytime soon. So what do you do? It's getting close to Christmas, and you need to get your WishList application ready in time. There is always the option of writing your own TypeAdapterFactory. However, for most of us it will probably be easier to go for one of the serialization libraries that offers Kotlin-support, like Jackson or Moshi. After changing serialization library to Jackson the WishList application works as you expect. Just in time for Christmas!

Gson and Kotlin: The nightmare before christmas!

Maybe you are burning inside with an idea of an NPM package that could revolutionize the world? Or maybe you just want to see what it's all about? This article will be a simple tutorial on how you can get started with creating NPM packages - which I, personally, found to be a quite useful skill to have!

NPM, or Node Package Manager, is a software "library" where JavaScript developers can browse and find handy tools for their projects. These tools - or packages, to be more precise - could be frontend libraries (like react), a bunch of useful algorithms (like lodash), or command line tool enhancers (like chalk - actually made by a Norwegian NPM legend).

The NPM library is huge! Some developers have even created a drinking game because of this. However, where does these packages come from? And how can I create one? I am glad you asked! To answer this, we have to travel to the NPM package factory at the North Pole and gain Santa's tr... No, but seriously, how are they made?

Creating NPM packages are easier than you might think!

To start from the basics you will need a computer with Node.js installed.

Next, you will have to make sure that when you open your terminal (3 ways to open a terminal on Windows, 7 ways to open a terminal on Mac, Linux users should already know how to do this), write npm and press Enter ↵, it does not return an error, but rather:



If this is how your terminal looks like now, then you are ready to move on. If not, you can try out this link.

Create a folder

Before we begin with using NPM, it important that you work inside a folder (or directory) on your computer that is only dedicated to your NPM package. If you don't, you can risk publishing files with sensitive information! And we don't want sensitive information publicly on the Internet, do we?

As we have already opened our terminal from the previous step, we can easily create a folder just by typing in these commands:



Create or generate a package.json file

In every NPM project, there exists a file called package.json:

This is necessary as it first of all gives a name to your package. Secondly, it contains information about the version of the project - such that users of this package can ensure they are using the correct version. You can find information of all the configurations here.

The most important configuration to note here is the main value, which is set to index.js. index.js will now act as the entry file for the NPM package, meaning this is where you need to place your code. You can add more files later, but the entry file will always be the heart of your package and all other files needs to be connected to this file somehow.

Side note: Even though we will not be using this configuration, it is worth mentioning that you can use dependencies to include other packages into your package. This enables you to use every single one of the 1.4 million packages in your project! You should probably not include every package in your project, though, as your node_modules folder (containing your dependencies) can get quite big really fast, and some packages can introduce potential security issues. It is usually a good indication to use popular packages with few dependencies, and if that is not enough, you can use npm audit.

To make the package.json file, you get two choices:

Create a file with that name in your package folder. Then copy the code above into it.

Or type npm init into your terminal. You will then be prompted with a few questions which results in a generated package.json file.

Choose what you feel the most comfortable with.

Add some code into your index.js file

At last, you need to add some JavaScript code to your package that other projects can use. In this tutorial, we are making a package that can calculate days until Christmas.

The last line will make the function daysUntilChristmas accessible by those who want to use your package. Be sure to remember to include this!

Publishing your package to NPM

When you are ready to test your package, or actually release it, you will need to go through these steps:

1. Create a user on NPM and log in

If you do not have an NPM user - like most humans - you will need to sign up on the NPM website.

Back in the terminal, you will now need to run:

Now, just follow the instructions.

2. Set your package version

Before every release you will need to change your package version as it is not possible to overwrite a existing published version. However, changing a version is fairly simple. Just manually type this in your terminal:

You can also just change the version in package.json manually.

3. Publish your package!

This is the last step:

And tadaa! You will soon be able to see your package on https://www.npmjs.com/package/\<your-package> (you might also get some seconds of fame on the NPM frontpage 🤩), as well as adding it to your next project using npm install --save <your-package> or yarn add <your-package>. If you do not want your project to be publicly visible you can read about how it is done here and here.

Here is also a demo of the days-until-christmas package from the example which could be worth checking out:

The source code can be found here: https://github.com/niklasmh/days-until-christmas

Be also sure to check out the articles linked at the bottom if you want to dive deeper into the NPM world. There is so much you can do, and this article only scratched the tip of the iceberg.

What to do now

Now, you have few more things you can do in your future life:

Use your NPM package to revolutionize the world, or at least the developer world. You can also read about how it can revolutionize you, as well.

Shrink your monolith of a project into something smaller and easier to work with by moving some of your code into NPM packages. Within reasonable bounds, of course. Too many NPM packages could be a nightmare to maintain too.

Contribute to other NPM packages. I can really recommend this! #hacktoberfest

Copy your NPM package onto a USB stick and give it as a gift to your family and friends. I am sure they would appreciate it!

Thanks for reading! I hope you have created a wishlist, cause I already know what packages I want for Christmas 😏🎅

Create your first NPM package!

Uffizzi (https://uffizzi.com) is a new cloud platform that helps developers deploy and host applications with zero cloud infrastructure knowledge. Uffizzi is similar to Heroku in many ways, but it is built on top of GKE, which means that it has a very solid and scalable foundation. This blog post is a quick guide to deploying applications to Uffizzi.

Getting started

Uffizzi proposes different paid plans for hosting, but I'm using the free environment for this demo. It provides:

0.5Gb of memory

Custom Domain

Free SSL

Unlimited Build Minutes

Continuous Deployment

The source code is on Github and the application is live at https://uffizzi.bekkops.com/

CI/CD pipeline

Uffizzi can set up and deploy an application directly from Github. There is no need for a Dockerfile, it uses Heroku buildpacks to detect the appropriate stack and build the container:

Uffizzi watches our Github repository and automatically builds and deploys changes immediately. It worked very well for my simple application, but there is no debugging possibility. Alternatively, Uffizzy can monitor a Dockerhub account and automatically deploy new images as soon as they are pushed.

Custom Domain

Uffizzi is one of the few platforms that offers custom domains + SSL as a part of its free offering. It's always annoying to have to use Cloudflare or AWS Cloudfront on top of a website just to solve that problem. You got kudos for that, Uffizi.

Conclusion

Overall, Uffizzi provides a great experience for those who just want to run a web application without handling all the cloud infrastructure around. The free environment is fully functional and even provides custom domains with SSL. Give it a try if you are looking for a zero ops platform for your application.

👋

Uffizzi App Platform

I 2012 publiserte smidige coacher i Spotify en bloggpost hvor de beskrev hvordan de skalerte smidig praksis i strømmetjenesten. Her tok de for seg hvordan de organiserte produktutviklingen i autonome, kryssfunksjonelle produktteam med ansvar for hver sine funksjonsområder (Squads), samtidig som samhandling på kryss og tvers av organisasjonen skjedde gjennom blant annet Tribes, Chapters og Guilds. Spotify var midt i en aggressiv vekstperiode, og ble ansett som et vellykket eksempel på digital produktutvikling.

Det vi ser de neste årene er at coacher, konsulenter og andre fagfolk raskt er ute med å anbefale Spotify sin modell som en blueprint på hvordan din organisasjon skal lykkes med å bli mer smidig. Og konsekvensen av dette er at det i mange norske bedrifter nå eksisterer Squads, Tribes, Chapters og Guilds. Dessverre er det ikke like mange som klarer å hente ut effektene fra dette i form av hurtighet og tilpasningsdyktighet. Jeg har gjort meg noen refleksjoner rundt hva som kan være årsaken.

1. Har du definert et tydelig hvorfor?

Smidige produktteam er en løsning på et problem eller et behov. Og det er det mange som glemmer å tydelig definere, som en rettesnor som skal veilede gjennom en større omorganisering. Det kan for eksempel være å øke innovasjongraden, korte ned time-to-market, treffe markedet bedre med nye tjenester eller øke eierskap og motivasjon i digital utvikling. Hva du ønsker å oppnå betyr noe for hvordan din produktutviklingsrigg bør organiseres.

2. Har du husket på det som ligger «under panseret» i din organisasjon?

Det coachene i Spotify beskrev i sin artikkel er det vi kaller «smidig praksis»; hvilke teamstrukturer og kompetanse de satte sammen, teamstørrelse, hva de kalte de ulike formene for samarbeid og samhandling mellom team. Men smidige praksiser er bare toppen av isfjellet. Smidig produktutvikling består nemlig også av prinsipper og verdier – den delen av isfjellet som ligger under havoverflaten. De mer usynlige retningslinjene for teamene, som påvirker handlingsrommet og hvilket mandat de tar og får. Etablerte prinsipper og kultur kan bli en stor hindring for å lykkes med innføring av produktteam, hvis ikke disse også adresseres og vurderes i lys av det man ønsker å oppnå. Jo lenger ned i isfjellet vi kommer, jo vanskeligere er det å lykkes med et blueprint fra Spotify på smidig praksis.

3. Har du tenkt over hva du gjør etter squads, tribes, chapters og guilds er på plass?

De dårlige nyhetene er at smidig organisering langt fra en engangsgreie, og det betyr også at arbeidet med smidig organisering vil fortsette i årene etter du har innført ny organisering. Det handler om å bli bedre til å omstille seg kontinuerlig og skape en tilpasningsdyktig organisasjon som kan agere raskt på endringer. Et godt eksempel er NAV som i løpet av fire arbeidsdager klarte å lage en løsning for forskuddsbetaling av dagpenger i lys av Covid-19, og fikk betalt ut en milliard kroner. De sier selv at de ikke hadde klart dette for noen år tilbake, men er nå rigget med riktig teknologi, kompetanse og arbeidsmetodikk. De organisasjonene som er best på dette har endringsdyktighet innbakt i kulturen, og har skapt rom for prøving og feiling både i produktutvikling og organisasjonsutvikling. En åpen delings- og samarbeidskultur med høy grad av tillit gir rom for at prinsipper og smidig praksis kan endres og tilpasses kontinuerlig.

4. Har du problemer med at resten av organisasjonen ikke jobber eller forstår smidig?

Det er ikke problemfritt å rigge produktteamene for kontinuerlig endring i en ellers byråkratisk organisasjon, og denne problemstillingen er det mange norske bedrifter som nå står ovenfor. En ting er sikkert, hvis du velger å organisere deg for smidig produktutvikling, så må du også verne om den konstruksjonen du skaper, selv når byråkratiet kjemper imot. De som lykkes, er de produktteamene som klarer å skape armslag mot resten av organisasjonen – eksempelvis gjennom å inkludere folk med både organisatorisk og forretningsmessig forståelse i produktteamene med én oppgave; å skape en smidig lunge som gir teamet rom til å puste. I parallell er det naturlig å jobbe med å øke forståelsen i resten av organisasjonen, slik at de mekanismene som jobber imot vil endres over tid.

There is no silver bullet

Det finnes dessverre ingen «one size fits all» når det kommer til organisering av produktteam. Det er ingen «silver bullet». Det handler om å forstå hvilke problemer du forsøker å løse i din organisasjon, og kombinere med dine rammebetingelser. Det er derfor ikke så attraktivt å «steal with pride» her... Vi anbefaler heller å «steal and tweak with pride» - så lenge du husker på hva det er du ønsker å oppnå.

8-Dec

Today's posts