I like TypeScript. I also like Magic the Gathering. What if we combine them; can the magical domain of planeswalkers and spells help us understand the awesome but advanced type system of TypeScript?

Let's give it a shot! Starting with the basics, we will gradually introduce the various features of the TS type system, using Magic cards as examples.

The complete rules for MtG are out of scope for this article, but if you're interested you can check out MtG Arena, a free online game for PC where you can learn the game and play against other people.

Type Inference

Out of the box, TS will try to understand the types of objects you create, even without specifying a signature. Let's define an old classic, Llanowar Elves:

Now, these guys have a mana cost of 1 green mana, shown by a tree icon in the top right corner. They also have Power and Toughness scores of 1, shown by the 1/1 in the bottom right corner. Finally, they have an activated ability: They can be tapped for 1 green mana.

If all of this makes no sense to you, don't worry, we will simply use the attributes as examples for our TypeScript objects.

As we can see in this GIF from VS Code, we get full autocompletion without specifying a single type, and hovering over the llanowarElves variable shows us the entire type structure.

Types and interfaces

Great! But what if we want to do something strongly typed with it? We could create a type alias using the type keyword to define the types manually:

However, in this case we probably want to infer the types and save that information as a new type. We can do this using the typeof operator:

Cool! Now we can make functions that take an input parameter of type LlanowarElves. But we probably want to make our functions more generic, for example a function that works only on Creatures, or on something that can be tapped. This is where interface comes in handy:

Here we have added the interfaces Spell to require a manaCost, Creature with power and toughness, and Tappable as something with a tap ability. We have also declared that llanowarElves is all of these things, using &, the intersection type operator.

Now, in newer versions of TypeScript, types and interfaces are pretty much interchangeable. So what are the real differences between types and interfaces, and when do you want to use one over the other?

Declaration merging

1. Interfaces support declaration merging, types do not. Here we can see we declare Creature twice, with no errors, because the declarations do not conflict.

typeof and keyof

2. Results of the typeof and keyof operators can only be stored as types, not interfaces. Here we see using keyof Creature, which gives us a new type that is the discriminated union of string literals for the properties power, toughness and manaCost; i.e. variables of the CreatureProperties type can only be either one of those strings.

Syntax

3. Types have generally shorter syntax.

Rules of thumb

There might be other edge case differences as well, but these are the ones you'll most likely notice. So which one do we use when? I use the following rules of thumb:

Use interface when creating a reusable library. This makes it easier for consumers to merge declarations in case they need to expand the interface without inheriting it.

Use type when combining other types. I find the syntax is both shorter and more readable, and in some cases like typeof and keyof, only types can be used.

Otherwise, use whatever feels right. I usually use interfaces, but types are okay too :)

Union types and Generics

Now, there are several other card types in Magic than Creature. Here are a few:

This Forest is a Land card. This means you don't need Mana to play it, but you can only play one Land each turn. Also, lands can be tapped for Mana, similar to Llanowar Elves.

Arcane Flight is an Enchantment, which means it targets another card and provides a lasting effect. This specific card will increase the power and toughness by 1 when attached to a creature, as well as give it the flying ability.

So, how would we go about modelling different types of cards? Let's start by using |, the union type operator, to define all possible types of a card:

In addition to the existing Creature type, we have Land which is Tappable and also has a color, while Enchantment is a Spell and has a modifyTarget function. And the Card type can be either one of these, so if a function takes in a Card, you have to use type guards to differentiate between the type of cards.

One issue with the Enchantment type is that the target could be anything. But in the case of Arcane Flight, only creatures are valid targets. We can use generics to enforce this, let's modify our Enchantment interface declaration:

Now Enchantment takes in a generic parameter. This can be any type, as long as it is a Card. The default type is Card.

Now we can define arcaneFlight as an Enchantment<Creature> card, which means that its modifyTarget function will interpret the target as a Creature.

Mapped types and conditional types

Sometimes we have types that are very similar, but not quite the same. For example, in MtG, a Creature Token is a card that is exactly like a Creature, except it does not have a mana cost and can only exist on the battlefield, not in your hand.

To model a Creature Token in TS, we will use a built-in mapped typeOmit, with the implementation included here for reference (from lib.es5.d.ts):

Pick is a mapped type that allows specifying a type and a number of properties, and gives a new type containing only those properties.

Exclude is a conditional type that in this case removes the properties we want to omit, so Omit becomes a form of "reverse" Pick.

Now we can define our CreatureToken type:

As we can see, we no longer need to (or may) include manaCost for our centaur.

Mapped types and conditional types are really powerful, but can be quite hard to grasp. For a more in-depth look, I recommend the articles Mapped Types in TypeScript and Conditional Types in TypeScript by Marius Schulz, as well as the official TypeScript docs linked to above.

Conclusion

We have explored the wonderful world of TypeScript types, covering type inference, the difference between types and interfaces, union types and intersection types, generics, mapped types and conditional types.

If you are interested in learning more, I would recommend checking out the Awesome TypeScript GitHub repo for lots of curated resources to get you started!

The Magic of TypeScript

From the moment they’re born, animals learn by interacting with their surrounding environment. The basic question in the field of reinforcement learning is: can machines do the same?

Machine learning is often divided into three basic paradigms: supervised learning, unsupervised learning, and reinforcement learning.

In reinforcement learning (RL), software agents are left to fend for themselves in environments with unknown dynamics, and must learn how to behave by observing how the environment changes as a result of previous states and actions taken. To be able to distinguish between good or bad behaviour, the agent receives rewards and punishments based on the state of the environment, and its own actions.

The policy dictates the behaviour of an agent. The ultimate goal in reinforcement learning is for the agent to learn a policy which will maximize some objective function, often the total reward gained. A value function is often used to keep track of the expected values of certain states, or state-actions pairs. The value function can often be used to derive optimal actions directly.

During training, the agent interacts with the environment, and subsequently updates its policy based on the interaction. This means that a reinforcement learning algorithm trains using a simulation of some scenario, as opposed to using labeled data, as in supervised learning.

In some cases, an agent can interact with the environment for multiple steps and episodes at a time, collecting the experiences in what is called a replay buffer. These experiences can then be used for training later. This allows training to be completed in batches, which can be much more effective, especially when neural networks are used as function approximators.

A complete environment run from its initial state until the end is called an episode. Episodes contain some number of discrete time steps, and at each time step the agent receives an observation from the environment, containing the new state and a reward value, and chooses an action, which is then executed in the environment. This repeats until some end condition is met.

Recently, the field of deep reinforcement learning (DRL) has seen a surge of interest in the academic world. Deep reinforcement learning simply refers to reinforcement learning algorithms which use deep neural networks as function approximators, mostly to represent the policies and value function discussed earlier.

The field of reinforcement learning has been around for a long time, but has had a limited set of practical applications. Maintaining state was often done by having a lookup table for all states, which is infeasible for large observation spaces. Using neural networks as function approximators was possible, but learning was unstable, and was considered to be computationally infeasible for complex problems.

These were the main obstacles overcome in the Google DeepMind Deep Q-Networks paper (see relevant links), which is said to have sparked this wave of interest in the field of deep reinforcement learning. The paper also made it clear that reinforcement learning methods had huge potential in a popular field, namely games. Due to their deterministic nature and clearly defined rules, games make excellent reinforcement learning training environments.

The DQN paper, first published in 2013, showcased an approach which utilized deep neural networks as functions approximators at scale, in a popular RL algorithm known as Q-learning. DeepMind named the approach Deep Q-Networks (DQN), and trained an agent to play a wide range of Atari games (see image above) at a super-human level.

After a series of consecutive breakthroughs, DeepMind created AlphaZero, a general algorithm which could be trained to play games such as Go, Chess and Shogi, beating both human and computer program champions alike. You can read more about this in tomorrow's blog post.

These algorithms often start with a completely blank slate, tabula rasa. They create their policies from the ground up, without any preprogrammed baseline or rules created by humans. This allows the policies to be devoid of any human bias which is often introduced in algorithms designed explicitly by humans.

If one were to consider gameplay a war, it would be clear that the humans are losing. Deep reinforcement learning algorithms are starting to best humans at even more complicated games such as Dota 2 and StarCraft II, which include vast amounts of imperfect information and long-term strategizing, a combination which for a long time was considered infeasible for learning-based methods to overcome.

Interestingly, both of the approaches underpinning these algorithms, namely neural networks and reinforcement learning, are inspired by biology and nature. Neural networks started as an attempt to mimic the inner workings of the animal brain, and reinforcement learning is based on (a simplification of) how we believe animals learn. Stay tuned for tomorrow’s blog post, which will delve deeper into the potential of deep reinforcement learning by exploring one of the most sought after goals in all of AI: the quest for general intelligence.

For anyone looking for more in-depth resources, I strongly recommend checking out Spinning Up by OpenAI (link below). It includes theory, exercises, well documented implementations of cutting edge algorithms, and references to relevant papers and other resources. If you prefer purely theoretical resources, I would also like to recommend two great books: “Reinforcement Learning: An Introduction” by Sutton & Barto, and “Deep Reinforcement Learning: An Overview” by Yuxi Li.

Thanks for reading!

Reinforcement learning

It's time to get on the fun train. Start simple by introducing small pieces of Kotlin into your existing Java code.

Kotlin v1.0 was released in February 2016, almost four years ago. Since then the language has gained a lot of traction, and in 2019 Google made Kotlin the preferred language for Android app development. Kotlin has full interoperability with Java, making it easy to introduce Kotlin bit by bit into your existing Java code base. To set up your existing project, read Get started with Kotlin.

Once your project is ready for some Kotlin code, a good place to start can be to introduce Kotlin data classes into your Java code.

Data classes - when less is more

Data classes are designed for one thing: Holding data. A great first step when introducing Kotlin into your Java project is to convert your simple Java classes, such as DTOs, into Kotlin. In Java there's a lot of unnecessary boilerplate code needed to represent even the simplest of objects. A DTO class with two properties will stretch out across 17 lines.

A Java class such as the example above can be converted to a Kotlin data class, giving you immutability and null safety on all its properties in one line:

That's really all you need. One line, and you'll have access to both defined properties, a toString() function, equals() and hashCode(), as well as a copy() function. Your code will contain less clutter and become more concise. A simple start, well worth the little effort to change your existing Java code into something more robust and more maintainable.

Tip: If you convert a class which also contains methods that implement logic, keep in mind that you want to avoid tainting your pure data classes with functions containing logic. If you do need some logic connected to your data classes, check out the post on extension functions from the Kotlin advent calendar.

Summary

If you work on a large Java application, but your team is curious about Kotlin, don't worry. You don't have to rewrite your entire app to start exploring Kotlin. You can start simple with data classes. You can even do it while you're still introducing more Java code. Try it on for size, and let the fun begin!

Read more about Kotlin data classes in our Kotlin advent calendar and in the Kotlin documentation, linked below.

Java ❤️ Kotlin

- Hvorfor? Hvorfor?



- Hvorfor?



- Hvorfor? Hvorfor? Hvorfor? Hvorfor?



- Slutt!



- ... Hvorfor?

Nysgjerrighet er en stor del av det å vokse opp. Nysgjerrighet driver en vilje til å lære, som hjelper oss å forstå verden rundt oss. I dialogen over kan man enkelt forestille seg et barn stille alle hvorfor’ene, og en voksen svare «Slutt!». Men det er ikke like lett å forestille seg at det er en voksen som stiller alle hvorfor’ene. Og her vil jeg komme med en påstand:

Nysgjerrigheten visner bort hos de fleste av oss etterhvert som vi vokser opp.

Jeg tror de fleste av dere som leser dette, og de fleste dere kjenner, var mer nysgjerrige da dere var 5 år enn hva dere er nå.

Hvorfor er det sånn?

Jeg spurte 3 kolleger under Bekks julebord om akkurat dette. Svarene jeg fikk var:

Kanskje det er fordi man bare er nysgjerrig frem til man slutter på skolen. Etter det handler det om å mestre. Ikke lære.



Alt er digitalt og magisk – og man forventer at det er magisk, så da trenger man ikke undres like mye og blir mindre nysgjerrig.



Jo mer man lærer jo mer er det mulig å være nysgjerrig på. Man må begrense nysgjerrigheten sin for å kunne fokusere. Det kan være at man blir for god til å begrense nysgjerrigheten...

«Hvorfor?» tenker du kanskje nå. \ Hvorfor sa du det?\ Hvorfor er har det noe med skolen å gjøre?\ Hvorfor blir man mindre nysgjerrig av at ting er magisk?\ Hvorfor må man begrense nysgjerrigheten for å fokusere? – Er ikke nysgjerrighet nettopp å fokusere?

__

J

e

g \ \ \ s

k

a

l \ \ \ i

k

k

e \ \ \ s

v

a

r

e \ \ \ p

å \ \ \ n

o

e \ \ \ a

v \ \ \ d

e

t

t

e \ \ \ n

å

. \ \ \ D

u \ \ \ s

k

a

l

.

__

__

Ok.

Nå er det på tide at jeg forteller hvorfor jeg skriver dette.

Jeg skriver denne teksten fordi jeg vil at hverdagen min, arbeidsplassen min og fritiden min, skal være et sted hvor jeg kan utforske og være nysgjerrig. Og jeg vil ikke bare være nysgjerrig alene i min egen lille hule. Jeg vil dele hverdagen min med andre nysgjerrige sjeler. Andre som kan reflektere og utstråle mer nysgjerrighet tilbake til meg. At vi sammen skal finne spennende eksperimenter og områder vi vil utforske. Det er jo sånn man finner ut av nye ting!

Jeg vil at vi virkelig skal lure på noe. At vi skal ha lyst til å vite svaret. At vi lurer så mye på svaret, at vi bare må finne ut hva det er. Men at når vi får vite svaret, så er vi fremdeles urolige. Utålmodige. Nysgjerrige. Det stopper ikke der. Ok, det er greit at vi fant et svar – men hvorfor er dette svaret? Hvorfor er ikke svaret noe annet? \ Vi vil vite hvorfor! \ Vi er nysgjerrige. \ Vi er utforskende.

Det er hit jeg vil. Det er derfor jeg skriver dette

For å forklare hva jeg prøver på her, har jeg funnet frem et sitat*. Sitatet sier noe om at man ikke skal fortelle folk hvordan de skal gjøre noe, men heller lære dem hvorfor du vil at de skal gjøre det. Og dette føler jeg at klør litt på myggestikket nysgjerrighet. Nettopp hvorfor gjør vi dette? Nok forklaring, her kommer sitatet:

If you want to build a ship, don’t gather people together to collect wood and don’t assign them tasks and work, but rather, teach them how to long for the immensity of the sea.



Antoine de Saint-Exupéry (paraphrased)

Hvis du føler deg nysgjerrig, skriv gjerne tilbake til meg ved å klikke på navnet mitt øverst på denne siden – eller utforsk noe du er nysgjerrig på. Nederst på siden under overskriften "Read more outside the calendar" har jeg noen forslag til ting du kan utforske, men kom gjerne med innspill på hva du skulle hatt på lista også.

*Det er vel og merke et feilsitert sitat som ingen er helt sikre på hvordan oppstod. Men samme det. Du var i hvert fall nysgjerrig nok til å sjekke hva den lille svarte stjernen midt i teksten stod for.

Utpust om viktigheten av å være nysgjerrig

Software has become an integrated part of life. It's everywhere, and the complexity is increasing. As developers, we're standing on the shoulders of giants. Most of the software running in our applications is written by someone else. But do you know what you're allowed to use the software for? And what your obligations are when using the software? All software has a license, which means it contains legal talk which "authorize the use, performance, or release of (something)."

Agenda

I aim to give an introduction to open source and licenses to make it easier for you to look into the details on your own when needed.

Source code available ≠ Freedom

What is freedom

History

Terminology and concepts

Short intro to some licenses

I Am Not A Lawyer (IANAL)

I Am Not A Lawyer! Don't take legal advice from strangers on the internet! Don't trust me! I'm serious! Leave now!

Religion

Believe it or not, but software licenses are much like religion. I've been called a zealot, communist, ignorant, dumb, and everything in between over this post.

So when you're talking about Open Source or licenses with people, tread softly, and don't be alarmed if someone gets very upset and starts attacking you -- much like religious debate.

Open Source Software ≠ Can use

The phrase "Open Source" has changed meaning over the last decade. It somehow became a buzzword, and suddenly everything is "Open Source" – but what does Open actually mean?

Open ≠ Gratis: We'll use the word gratis for "doesn't cost any money". Open Source software doesn't have to be gratis any more than closed source has to cost money. And gratis software doesn't have to be open source.

Open ≠ Freedom: Even though you have access to the source code, it doesn't mean you're actually allowed to use it as you please. You might be sued by just looking at the software.

Freedom ≠ Gratis: Being allowed to use something as you please still doesn't necessarily mean it has to be gratis. And being gratis doesn't mean you're allowed to use it for your needs.

Open ≠ Can Use: In short, Open Source doesn't mean you can or are allowed to use it

https://www.gnu.org/philosophy/open-source-misses-the-point.html

Free Open Source Software (FOSS)

Several projects and companies use custom licenses and modified versions of Open Source licenses. The motives for this might be many, but I suspect the primary motivation is because it might be easier to monetize, keep control, or reduce the risk of someone taking your work, making it better, and making you obsolete. Of course, purely speculations, and regardless of motivation, the loss of freedom might be problematic for the user.

When a project is released under such license, the correct term is Source Available, not Open Source, as a key of Open Source is that you should be able to use the code as you like. It will probably still be marketed as Open Source, so you need to keep a keen eye.

There are several organizations working to promote Open Source, Open Source Initiative (OSI) and Free Software Foundation (FSF) being two prominent players. While they agree on much, and OSI-approved licenses also being FSF-approved licenses, the FSF is more strict on what freedoms it requires. But remember that for the purpose of this post, OSI and FSF are good friends playing along nicely!

Free = Freedom: The Free talks about freedom to use as you like, which is only possible if the code is also open.

Free ≠ Gratis: FOSS still doesn't have to be gratis.

But to confuse the matter even further, the word Free is often misinterpreted as Gratis, and as such is sometimes used for software which restricts your freedom.

Because of this, yet another term has been coined, Free Libre Open Source Software (FLOSS). This haven't seen much widespread use yet, but give it a couple of years, and it has probably gained another meaning :)

Freedom

We've talked a bit about Freedom, but haven't given a definition. Free Software Foundation defines freedom as (emphasis mine):

The freedom to run the program as you wish, for any purpose (freedom 0).

The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1).

The freedom to redistribute copies so you can help others (freedom 2).

The freedom to distribute copies of your modified versions to others (freedom 3).

There are many non-free licenses out there, which restricts one or more of these freedoms. Think about what it would mean if a library you're using restricts the rights to redistribute. Or restricts what you're allowed to do with it.

https://www.gnu.org/philosophy/free-sw.html

History and some useful links

I've referred to FSF and GNU several times already without giving a reason for doing so, but there are good reasons. FSF and GNU are old projects created to support freedom in software.

Pre 1980, nearly all software was free.

During the 1980s, nearly all software became proprietary, non-free, closed source.

Gnu's Not Unix (GNU) was founded 1984 by Richard Stallman to create a free Unix operating system (OS).

Free Software Foundation (FSF) was founded in 1985 to help GNU and the free software movement financially

The GNU/Hurd kernel (core of the OS) is not yet ready. Linus Thorvalds released the Linux kernel in 1991.

GNU and Linux together makes a complete and free Unix-like OS

The GNU/Hurd kernel (core of the OS) is not yet ready. Linus Thorvalds released the Linux kernel in 1991.

GNU and Linux together makes a complete and free Unix-like OS

Linux Libre is Linux without non-free code

Free Software Directory lists a lot of free software

Software Freedom Conservancy helps defend free software

Copyright

Copyright is a central theme to licenses. It basically means the owner of the work.

Copyright is a form of intellectual property that grants the creator of an original creative work an exclusive legal right to determine whether and under what conditions this original work may be copied and used by others, usually for a limited term of years

No license means full copyright to those who wrote it. You cannot use it for any purpose at all as the author(s) didn't grant you any rights to the work. If you see something without a license, turn around and don't look back.

You might have seen people "licensing" work under Public Domain, but not every country accepts this definition, so using Public Domain software might be considered a breach of copyright. Do not use "Public Domain" licensed software.

Copyleft

In software we're standing on the shoulders of giants. Everything we do builds upon something someone else has already built. As such, we're often modifying software (often by including a library in our own code), and then distribute it as part of our own work.

Copyleft, distinguished from copyright, is the practice of offering people the right to freely distribute copies and modified versions of a work with the stipulation that the same rights be preserved in derivative works created later

So while you might have been granted the rights to use something, you might not have been granted the rights to distribute it or combine it with other software.

Viral licenses

There's a lot of licenses out there, and they have wildly different purposes. As such, there are situations where parts of one license will clash with parts of another license.

Several licenses require that you use the same license for derivative work, which makes the license viral – it infects your own work. Luckily, several licenses are compatible with one another, and allows you to use one license as long as your own work is one of the compatible licenses.

If you use a GPL library, you need to use a GPL compatible license for your own work. GPL is a viral license by design to make sure nobody removes a users freedom.

Multiple licenses and copyright attribution

Because of copyleft, patents etc, a lot of people might be unable to use certain licenses. To circumvent this, much software is released under several different licenses, also called dual licensing (in the case of two) or multi licensing.

Remember that copyright is given in full to the author to a work. So a contributor will have full copyright for the contributions. The project thus cannot grant someone else access to this contribution without explicit consent from the author.

Copyright is needed in order to change or upgrade a license, to distribute under other licenses, and to take legal actions against infringements. Because of this, some projects requires the authors to sign over contributions to the project/entity owning the project.

https://www.gnu.org/licenses/why-assign.html

A bit about some popular licenses

There's a lot of different licenses out there. Some are more popular than others, and libraries released in 2019 often use a different license than a library released in 2009. Some are good for products, and others are good for libraries, and some licenses might be problematic to use for commercial use or proprietary code.

The following licenses are pretty common, and you should at least look at some bullet points describing them.

Lots of freedom

AGPL (GNU Affero General Public License)

Like GPL, but includes software accessed over the network

GPL (GNU General Public License)

Users are allowed to run, study, share and modify the software

Derivative work must also include these freedoms

For libraries

Should be quite safe, but has some demands on the user, e.g. attribution.

LGPL

Apache 2.0

Expat (MIT)

BOOST

ZLIB

JPEG

BSD (3-clause / modified)

Public Domain

"Do whatever you want, but don't sue me"

CC0

Unlicence: Rather use CC0

Public Domain: Might not be valid in many countries – stay away

Non-free

GNU defines these as non-free by various reasons (like the phrase "do good not evil", which limits use and is subjective)

Artistic License 1.0

The JSON License

Microsoft Shared Source License

Creative Commons NonCommercial

Creative Commons Noderivatives

What license should I choose?

When choosing the license, you have to consider the licenses of the software you're using. They probably have restrictions on what license you can choose.

GNU has a nice recommendation list:

Small programs/code snippets (\<300 lines): Apache 2.0

Libraries you want to see used (same domain as non-free libraries): Apache 2.0

Other libraries wher GPL is unpractical: LGPL

Other libraries: GPL

Running on servers: AGPL

Longer documentation: GFDL

Short documentation: GNU all-permissive license

https://www.gnu.org/licenses/license-recommendations.html

References

Few people read licenses from cover to cover anymore as someone has done the dirty-work of categorizing the legal-talk, making it digestible for the rest of us.

https://www.gnu.org/licenses/license-list.html

https://tldrlegal.com/

https://choosealicense.com

https://choosealicense.com/appendix/

Transitive licenses

It's turtles all the way down. You're responsible for transitive libraries. Do you know that no libraries of the libraries of the libraries of the libraries use a license wrongly?

If they break the rules, so do you!

Your package manager should include ways for you to find out what licenses are in use. Search for "license checker" or similar for your package manager.

Stack Overflow

Now that we've learned that licenses can both grant you rights to use something and built upon on it, what about all the snippets on the internet where there is no explicit LICENSE along with the code. Have you read the Terms And Conditions for all sites you are a member of? When you publish code on their site, do you think you have copyright, or did you check a box when signing up for the service (after reading the long legal document of course)?

You haven't ever copied code from the internet without knowing the full extend of the license?

…. Have you ever copied code from Stack Overflow? …

requires you to release all derivative works under this same license. You must give credit to the original author of the work, state their name and the title of the original work, say that you modified the work if you did and include the attribution logo

Ref Creative Commons Attribution Share Alike-(cc-sa)

Summary

IANAL! Don't trust random legal advice from random strangers on the internet!

Source Available ≠ Freedom

Freedom ≠ Gratis

Use free licenses and submit your work under free licenses

Make contributors sign over copyright

Release under more than one license if necessary

You're probably violating licenses! Clean up your act.

Open ≠ Free ≠ Gratis

Cloudflare Workers is a service that let's you run serverless functions on Cloudflare's Edge Network close to where the user is located. Combined with the V8 JavaScript engine this lets you write highly scalable functions in the cloud with fast startup and response times. This article shows how you can get started using Cloudflare Workers, and present some possible use cases.

Introduction

Function as a Service (FaaS) is becoming more and more common, and all major cloud providers have their own FaaS offering. AWS has Lambda, Google has Cloud Functions and Azure has Azure Functions. One thing all these services have in common, is that they are built on top of container technology. The underlying container is abstracted away from the user, but the underlying runtime is based on containers on all these services.

Using containers works quite well, but one issue that often is mentioned when talking about FaaS is cold starts. Cold starts refers to the delay between the execution of a function after someone invokes it. If your function gets triggered often, the underlying container is running and "warm", and will execute your function immediately. But if it's been a long time since your function has been triggered, the underlying container is not running and "cold". The next time your function is triggered, you have to wait for the underlying container to start, and the language runtime has to be initialised before your function is executed.

Cloudflare Workers takes a different approach to FaaS, and instead of using container technology they use the V8 JavaScript engine as the underlying runtime. This is the same engine used by Chromium and Node.js. Cloudflare Workers makes it possible to run hundreds, or thousands of different functions in their own sandboxed environment on the same underlying V8 engine (called Isolates). When we don't have to wait for a container to start, this leads to very fast startup times, and in practice no cold starts. The functions are also executed close to the user, as they executes on Cloudflare existing Edge network which they use for their CDN product.

How does this look in practice?

Cloudflare offers a CLI tool called Wrangler to let you manage your workers. Wrangler can be installed via npm with the command npm i @cloudflare/wrangler -g.

To bootstrap a JavaScript project, simply run the following command.

This command creates a folder including all files from the template passed in as the last argument. In the folder you have one index.js file which contains your function code.

A Cloudflare Worker consists of two main parts. The first part is an event listener which listens to a so called FetchEvent. This event handler will be called everytime there comes a new HTTP request to your worker.

The last part is an event handler that returns a Response object, and is passed as an argument to the event's respondWith method. In this example all clients will get a Hello Christmas! text in response.

How to deploy your worker

Wrangler comes with a preview command which lets you test your worker by taking your built worker project, and upload it to a unique URL at cloudflareworkers.com. This means that you don't test your worker locally, but actually with the workers runtime. If you add a --watch flag to your preview command, the worker will be updated immediately when you save your function code.

To deploy your function you use the publish command. After setting up wrangler with the correct permissions, wrangler will deploy your worker either to a custom domain managed by Cloudflare, or to a workers domain. After a few seconds the URL for your brand new worker is printed, and you can invoke your function by navigating to the URL.

Use cases

The example above is of course a simple hello world example, and you might think what can Cloudflare Workers actually be used for? If you already uses Cloudflare as a CDN, workers could be a good way for redirecting or rewriting the response based on the incoming request. This example show for instance how a worker could be used to return a response based on the incoming request’s URL, HTTP method, User Agent and other criteria.

But workers could also be used for more standalone functionality, like hosting a React App or building a function that generates QR codes.

Summary

Cloudflare Workers is a really interesting alternative in the FaaS market. Especially since it's based on the V8 JavaScript Engine instead of containers. It's also especially attractive if you already uses Cloudflare as a CDN, and it will be fun to see how the service evolves in the next months.

It's also worth mentioning that while Cloudflare recommends using their CLI tool Wrangler, it's supported by Serverless Framework (using the Serverless Cloudflare Workers plugin) and Terraform (using the Terraform Cloudflare Provider).

Cloudflare Workers

So far, in this calendar, we have talked about CSS grids, at least on four occasions. Make sure to check them out if you haven't already!

Oops! I Grid it again - an introduction to CSS grids

Don't suffer like I Grid - SafIEty first - how to support grids in IE

Bleeding edge - making your grids bleed - on bleeding into the grid gaps

CSS Grid's Best Friend - Aligning items within cells.

I'm a believer in learning by doing. If you are like me, then you might have read about CSS grids, but not yet used it. Well, that changes now!

Grid Garden is a cute little game that lets you try out positioning in CSS Grid in a quick and fun manner. Head over there and have a few minutes for yourself meditating in this busy time of the years while weeding your virtual garden!

Weeding the Grid

Snakker vi fortsatt om behov i den klassiske Maslow's pyramiden? Eller ser man på behov som noe annet? Og hvordan jobber vi med behov i vår bransje? Altså, hvordan sporer du ønsket om enkel innlogging tilbake til Big Bang? Jens Andreas Huseby, Linda Halvorsen og Moquan Chen drikker kaffe og prater.

Hvor kommer behov fra?

There are a lot of ways to define a function in Kotlin and lambdas are a central part of that. Lets take a look at some ways we can define a function in Kotlin.

The first thing we'll take a look at is the familiar function with typed arguments, a function body and a return type. In Kotlin we can define them as follows:

Function

This is fine, but for many functions, we can do better and improve the readability by making it a single expression function.

Single Expression Function

This approach often leads to more concise and readable code, but be careful of trying to make everything into single expression functions; it can get messy!

One of the great things about Kotlin is that you can assign functions to variables. This has some cool implications. Functions are first-class citizens, meaning we can pass them as we would with any variable. Let's take a look at how we assign a function to a variable.

Lambdas

To create a function variable we've introduced some new syntax. We have a function type (Int, Int) -> Int and a lambda expression { a, b -> a + b }. The function type is really just an interface for a function. We can't use that interface elsewhere, but it's still an interface describing what a function takes as arguments, in our case (Int, Int), and what it returns (Int). The second part is the lambda expression. A lambda expression is an anonymous functions with some (or zero) parameters (a, b) and a body (a + b).

In Kotlin you will often see lambda expressions. Let's take a quick look at one of the functions in the standard library.

A lambda! { it + 1 }. This might look a little weird the first time you encounter it. There are no parenthesis around the argument! What is happening here? So this is some cool syntactic sugar Kotlin supplies us with. If the last argument of a function is a lambda, we can omit the parenthesis, meaning that sumBy { it + 1 } is the same as sumBy({ it + 1}).

There is one more thing here, the it parameter, some more syntax sugar. If a lambda has a single argument we can simply refer to it by the it keyword: { myArgument -> myArgument + 1 } is the same thing as { it + 1 }.

The sumBy function takes a function as an argument. How can we do that in our code? Let's take a closer look at source code of sumBy.

To take a function as a parameter we use a function type, and in sumBy it's defined as selector: (T) -> Int. A generic argument that results in a number, and for sumBy that makes a lot of sense. We can supply whatever we want as long as the result is a number.

And there we have it! A function that can take functions as arguments. There are two ways we can invoke it. We can pass a function variable or simply writing a lambda:

sumBy(article)

In Kotlin, we have a few choices on how to define our functions. We can use functions with bodies, single expression functions or lambdas. They all have their place and their usage so don't be afraid to experiment and find what gives your code the best readability. Don't be afraid to dive in to the source code of the standard library. It's good, often easy to understand and can give you some inspiration on how to structure your own code!

On wavelength with lambdas

A short tale about my struggle to comprehend why C# isn't a functional language.

In an effort to learn Haskell I have started to work through the exercises at exercism.io. It is an excellent site that provides classical programming exercises in loads of different languages. You get feedback from experienced mentors, and the feedback I have received so far has been really thoughtful and useful. I am learning tons!

I am having a go at learning Haskell. Not because this is something I will ever need. It is rather an attempt to get my head around functional programming, and to me Haskell doesn’t seem to have any practical application beyond that.

Although I am struggling, it is great fun!

My background is in OO programming, mostly using C#. C# being the versatile language it is, I have had the perception that whatever you do in other programming languages, you can with a little more code and hassle achieve in C# as well. If need be, I can program C# using a functional paradigm. And, of course I use recursion all the time. I know all there is to know about recursion.

Obviously, I can’t know much about functional programming!

One of my tasks was to implement a function that returns the nth prime number.

Googling for a Haskell implementation of the problem, I would consider cheating. But using Wikipedia to find a general algorithm is not beneath my standards. So I jumped over to this page and found a small optimisation I probably wouldn’t have thought of myself.

The final solution was published, and I was pretty happy with my own efforts; a beauty of just 30 lines.

I had used most of what I had learned so far, and recursion too. (It seems like all the problems presented in functional programming courses invites a recursive solution.)

In exercism, you get the option to publish your solution, and to look at other users published solutions. I browsed some of them. For instance this:

Not only is it much shorter, it also applies a combination of recursion and lazy partial execution of the function. This led me to understand how little I had understood.

Now, it is conceivable that this is the canonical solution to this particular problem, but still my head exploded.

Is this at all possible to achieve in an OO language? I sat down and tried to restore the honour of C# by solving it with recursion and lazy implementation in my old familiar language. (With a little more code and hassle.)

No, I don’t think it is possible to solve it this way in C#.

In about 50 lines the snippet achieves almost but not quite what Haskell could do in seven. I just took a massive code golf defeat.

I think I have learned something new today.

The struggle continues.

That one time I thought I understood recursion

Testing your apps is becoming so easy, it's starting to become worth the trouble!

Let me tell you a little Christmas secret: I've never really been a fan of testing. It takes up so much time, makes it harder to refactor your project, and you always feel like you haven't done enough. Testing is a recipe for feeling bad about your efforts. Unless, of course, you have :100: % test coverage, but that's bad in its own right.

So screw testing, right? Well...

Truth of the matter is we need those grinchy buzzkills to keep us moving with any kind of confidence. Because no matter how bad writing tests seems to be, doing all of those checks manually on every deploy is definitely not going to happen.

Luckily for us JavaScript developers, testing our apps - and particularly React apps - have become much easier the last couple of years. I'll share some of my hard bought tips from the last couple of years worth of consulting, and hope that you'll find them enjoyable.

Avoid testing!

The best kind of test is the one you don't have to write explicitly. And as it turns out, we don't have to write most of the tests we used to write!

A good type system - like TypeScript or Flow well, TypeScript - will catch a whole class of bugs for you without you having to write a single test. Personally, most of the bugs I've introduced over the years could probably have been caught by a type system. Now the darn web app won't show up until I fix them!

So trust a guy that used to hate type systems - embrace that shit right away. Why? Because

is a lot less to write than

Lint your heart out

If you're not familiar with linting, it's the process of analyzing your code, and checking it against a set of requirements. Sounds a lot like testing, right?

Truth is, there's two types of linting - annoying and useful. The annoying type of linting is the kind that complains about the trivial stuff like formatting. An automatic bike-shedding tool, of sorts. Just use Prettier, and skip this entire class of annoyance in your pull requests.

The useful kind of linting is the one that catch potential bugs, code smells and accessibility issues in your code. This is the one you want to invest in.

eslint is the industry linting standard, and I suggest you install the eslint-config-react-app preset as well. With these in your arsenal, you'll be catching and squashing those bugs in no time - all without writing a single line of test code.

Use the right tooling

Back when I was taught how to test in JavaScript, we used Jasmine and Mocha and Chai and a lot of other tea flavors for some reason. Never thought about that common theme until now, actually 🤔 Cool, anyhow, stop using all of that stuff right away! There's better tools out there now, and you should be using those instead.

Jest has become the de facto winner of the testing wars - and that's in no small part because of its incredible user experience. You can get started with a simple npm i jest, minimal (yet flexible) configuration, and an incredible test watcher experience that is just... great.

But even with Jest, JavaScript testing was a fragile mess at best. We had Enzyme for a bit, which simplified things, but tests were still fragile af.

2 years ago (wow, has it really been that long?), Kent C. Dodds introduced the React Testing Library, which was the Jest moment of React testing libraries.

The React Testing Library (or @testing-library/react as it's now known) does a few things very well. It makes sure you're only testing the output, and skipping the implementation details. It also nudges you toward writing accessible apps, while allowing flexibility where you need it. Finally, it makes testing async code a breeze.

Write tests like your user would

We've eliminated much of the need for manually written tests by now, but there are still a few left we have to write. The ones that mimic your user's behavior.

Whenever I've written a component or piece of UI I find the need to test, I tend to sit down and write up all the scenarios I want to test first. It might look like this:

Then, I implement. I use the selectors provided by react-testing-library@testing-library/react to test the output, and I interact with what I've written like the user would have - with clicks, change events and focusing stuff.

I writer longer tests than I used to, too. By asserting that regular interactions - like clicking an accordion, then closing it, then opening it again - works as intended, I feel more like a user writing down steps than a test writer. And that makes me feel good.

TDD if you want, not because of Uncle Bob

Test driven development is a cool technique to write tests - but it's not always a good fit for the way you write code, or the way that particular feature should be written.

Instead, play around with the way you write tests until you find something that works for you. Whereas iterating the red-green-refactor ladder makes sense for some business critical functionality, it's a huge waste of time for more trivial UIs.

And I'm not sure if it was ever applicable for modern UI programming. One of the main features of TDD back in the days was its quick feedback loop - a feature that's replaced and in many cases surpassed by hot reloading and test watchers. Perhaps it's a better technique when developing your Kotlin backends?

So that's it - a few strongly worded paragraphs about how I feel about testing. You might find several of them trivial, and if so I hate to have wasted your time. But at least you didn't waste your time writing bullshit tests, like you used to.

Takkformeg. 👋

How I test my React apps in 2019

Does the US government sponsor the development of the darknet? What is The Onion Router project and why should you be anonymous on the internet?

Today most users of the internet have, to some degree, understood that their activities are traceable and there is probably someone that can see what you did, when you did it, even if your iPhone has private browsing enabled. Others do not, and could not care less. “I have nothing to hide”

When, what we know of today as the net, was developed, we have a sneaking suspicion that the inventors were more than happy that it actually worked, than they were worried about security and privacy. Imagine the sheer joy that sending packets over networks actually worked in the late seventies. Using simple, but neatly designed, protocols, they were able to route packets across the world. Security was not high on their agenda.

Today however, we use the internet for far more than anyone of the original researchers could have foreseen. The net is used for just about anything, from doing business, reading news, communicating and let’s not forget, watching cat videos on social media. The global nature of the internet gives anyone, anywhere in the world, the freedom to publish content, from palm of their hand.

The fair share of the internet is happy post their selfies and send the mandatory “happy birthday” greeting on Facebook. There are however locations and situations where the consequences of posting news an oppressive regime or leaking documents, which proves misconduct by authorities, can be dangerous or even illegal. Fake news and false leaked documents are a rising problem, but we must not under estimate the effect organizations such as WikiLeaks and individuals like Chelsea Manning and Edward Snowden have had on our understanding of the world we live in. Before the prevalence of the internet, leakers and inside sources had to find journalists, and a newspaper, that were willing to publish their information. Publishing information on the internet should in theory be easy, but many major platforms have limitations on what content they will let their users publish. The operators of these networks can also be ordered by law enforcement to give out information about the source of the content.

Sometimes you need the option to be anonymous. The Onion Router, known as TOR, is a network where the traffic is routed via a number of special TOR nodes to conceal where the traffic originates and the traffic is encrypted. Each time the traffic bounces through the nodes, is encrypted, like layers in an onion. In the onion network the traffic cannot, easily, be eavesdropped. When the traffic leaves the onion network, through an exit node, is will be routed like normal internet packets. The overhead with encrypting and bouncing via the onion nodes reduce the throughput of the onion network, so that using TOR for everyday usage is not a pleasant experience.

Many of the ideas behind the onion router was developed by employees of the United States Naval Research Laboratory in the late 80-ties. The American government continued to sponsor the development via different organizations. However, in 2004, the source code was transferred to the Electronic Frontiers Foundation, which did much the fiscal sponsorship of the TOR project. Today the development is funded by a wide range of companies and organizations and releases are made available for users and researchers.

Today TOR is probably associated with more shady activities by criminals, hacktivists and services as the now defunct Silk Road. But not even TOR is a guarantee that someone can intercept your messaging or avoid you being tracked on the net. Evidence provided by Edward Snowden has shown that nation agencies such as the FBI has attacked use of the TOR network.

Maybe you do not need to be anonymous on the internet, maybe the technology can be abused and maybe it is not 100% secure, but it is good to know that we have bright minds working on solutions for these problems. If you want to play around with onion routing and have a spare Raspberry Pi laying around, you can transform it to a TOR network router. Check out this link.

Happy privacy.

18-Dec

Today's posts