jarleton.dev

Crafting our own Option type in typescript

2022-05-01T00:00:00Z

1 · Who is that article for

In that article we will build our own Option type from the ground up.

It requires a bit of typescript knowledge. It will be a step by step process.

2 · What's our goal?

We will start from a simple program that

Asks the user its name
Crafts a message depending on whether the user provided a name or not
Logs a greeting message

What we will be looking for is a way to express that program using types first.

3 · The program

function userInput(): string | null {
    // some implementation
}

/** we will store the greeting message in that variable */
let greetingMessage: string

console.log('What is your name?')

const userName: String | null = userInput() // ask for the user name

if (userName !== null) {
    greetingMessage = `Hello user, I will call you ${userName} from now on`
} else {
    greetingMessage = 'Hello stranger! It seems I didn\'t quite catch your name'
}

console.log(greetingMessage)

4 · Finding a type saying a value can be empty

As of now the userInput function can either return a string or null but what if we wanted to return only one stable type instead of two?

From here, we need to find this new type. It should convey the idea that userInput can either return some value or none at all.

Starting with this in mind we can define two new types: Some and None

// None tells that it doesn't hold any value
type None = { isSome: false }

// Some tells it has some value of type A and hold it in a `value` field.
// A could be any type we could think of as in Some<String> or Some<number>.
type Some<A> = { isSome: true, value: A }

So our userInput can now return Some<String> | None, for our convenience we will introduce a type saying exactly this:

// An Option can either have Some value of type A or None at all
type Option<A> = None | Some<A>

which leads us to have a new signature for our userInput function conveying within one type that it is allowed to return nothing.

function userInput(): Option<String> {
    // some implementation
}

5 · Rewrite of our program using the new signature

Leveraging the new signature we can make the if statement closer to english

let greetingMessage: string
console.log('What is your name?')
const userName: Option<String> = userInput()

if (userName.isSome) {
    greetingMessage = `Hello user, I will call you ${userName.value} from now on`
} else {
    greetingMessage = 'Hello stranger! It seems I didn\'t quite catch your name'
}

console.log(greetingMessage)

userName.value can only be accessed if we first check userName.isSome making the program already safer.

6 · Giving Option some friends

Now that we have a cool type, we will give that type some functions to help it make it nicer.

The map function

We are looking into isSome then accessing the value, we could provide a function that says something like:

Given an option which might contain A
 
apply this function going from A to B

So we have an option which might contain B

We will call that function a map since it maps our Option<A> to Option<B> using our function.

Map signature will look like that:

function map<A, B>(transformation: (value: A) => B): (option: Option<A>) => Option<B> {
}

so we can now rewrite our program this way:

function greetAKnownUser(userName: String) {
    return `Hello user, I will call you ${userName} from now on`
}

let greetingMessage: string

console.log('What is your name?')

const userName: Option<String> = userInput()
const knownUserMessage = map(greetAKnownUser)(userName)

if (knownUserMessage.isSome) {
    greetingMessage = knownUserMessage.value
} else {
    greetingMessage = 'Hello stranger! It seems I didn\'t quite catch your name'
}

console.log(greetingMessage)

It starts to look closer and closer to some english statements, the one bit staying is this if /else.

The getOrElse function

What could we imagine from here to totally get rid of that if else?

We are now looking for a function saying something like:

Given an option which might contain A

And a default value of type A

Pick the value contained in the option, on None, pick the default value

Return a value of type A in any case

In other words, we would like to get the value or else get the default so the name seem clear, it is the getOrElse function:

/**
 * If option has some value, then it will return it, otherwise it will return the default passed value
 */
function getOrElse<A>(orElseValue: A): (option: Option<A>) => A {
}

Let's rewrite our program using that

function greetAKnownUser(userName: String) {
    return `Hello user, I will call you ${userName} from now on`
}

const greetStranger =
    'Hello stranger! It seems I didn\'t quite catch your name'

console.log('What is your name?')

const userName: Option<String> = userInput()
const knownUserMessage = map(greetAKnownUser)(userName)
const greetingMessage = getOrElse(greetStranger)(knownUserMessage)

console.log(greetingMessage)

Stopping here for a little, there are multiple things to say about what we have.

First, there is no longer a let awaiting the program to go in one of our if/else statement to be filled. From now on there is only constant using the value of the previous constant to decide its own value.

Second, there is no more if/else and in broader manner, there is no more imperative statements. We didn't provide any implementation yet for map and getOrElse and looking at the code we don't need it to know what the program does!

It is still not that nice to read, we could have a final utils to help us on the reading part

The pipe function

The pipe function is a dumb function. It takes a list of functions and calls the next one with the result of the previous one.

function pipe<A>(...ListOfFunctions): A {
    // some implementation
}

Which gives us this final result:

const greetAKnownUser = (userName: String) =>
    `Hello user, I will call you ${userName} from now on`

const greetStranger =
    'Hello stranger! It seems I didn\'t quite catch your name'

console.log('What is your name?')

const greetingMessage = pipe(
    userInput(),
    map(greetAKnownUser),
    getOrElse(greetStranger)
)

console.log(greetingMessage)

7 · Conclusion

We now have the same program written twice:

the first one doesn't express the result of the program but tells what steps the computer should exactly take to obtain the correct message.
The second version declares the result of the program without telling which steps to take to achieve that result.

The declarative version tells what result we expect without telling how it should achieve such result

What did we gain introducing the Option type in our code? The first thing we got is safety! Indeed, by design our code won't allow to end up in a null situation anymore therefore anyone who works using our Option type will have to treat null edge cases.

We also gained in reusability and composability. We can split that program in multiple sub-functions that could be easily reused since it operates against the same type encasing the same assumptions.

On the other hand, we lost a bit in readability, after a while you get use to write and read your code in a functional flavor. It requires some habits and training making the code less accessible for the majority of the developers' community.

We also lost contact with the actual implementation, which imply that we trust whoever implemented getOrElse, map or pipe to have the correct implementation and the most stack safe possible.

So shall we invest more time in it? Knowing how to write such code seem to me important to understand that there is many ways to write the same code with different constraint and goals. In context of safety (our code can't produce uncontrolled edge-cases), bringing such functional practices fits well.

8 · If you have more time

About testing

We can now write things like:

function getUserGreetingFromOption(option: Option<String>): String {
    const knownUserMessage = map(greetAKnownUser)(userName)
    const greetingMessage = getOrElse(greetStranger)(knownUserMessage)
    return greetingMessage
}

const greetingMessage = getUserGreetingFromOption(userInput())

console.log(greetingMessage)

Why is that ability nice? because it will ease testing our system behavior by providing inputs and outputs. We no longer requires to mock userInput if we wish to test the return message we can directly do something like:

describe('getUserGreetingFromOption', () => {
    it('should greet stranger on none', () =>
        expect(getUserGreetingFromOption({isSome: false})).toEqual(greetStranger))

    it('should greet Amy', () =>
        expect(getUserGreetingFromOption({isSome: true, value: 'Amy'}))
            .toEqual(greetAKnownUser('Amy')))
})

Full implementation

////// Option
/// Definitions
// None tells that it doesn't hold any value
type None = { isSome: false }

// Some tells it has some value of type A and hold it in a `value` field
type Some<A> = { isSome: true, value: A }

// An Option can either have Some value of type A or None at all
type Option<A> = None | Some<A>

/// constructors
const some: <A>(value: A) => Option<A> = value => ({
    isSome: true,
    value
})

const none: () => None = () => ({
    isSome: false
})

/// destructors
const getOrElse: <A>(orElseValue: A) => (option: Option<A>) => A =
    defaultValue => option => option.isSome ? option.value : defaultValue

/// operations
const map: <A, B>(transformation: (value: A) => B) => (option: Option<A>) => Option<B> =
    transformation => option => option.isSome ? some(transformation(option.value)) : none()


////// Functions
/// Pipes
const pipe3: <A, B, C>(fn1: A, fn2: (a: A) => B, fn3: (b: B) => C) => C =
    (fn1, fn2, fn3) => fn3(fn2(fn1))


// ******************************************
const userInput = (): Option<String> =>
    some('Amy') // you can try with none()

const greetAKnownUser = (userName: String) =>
    `Hello! I will call you ${userName} from now on`

const greetStranger =
    'Hello! It seems I didn\'t quite catch your name'

console.log('What is your name?')

const greetingMessage = pipe3(
    userInput(),
    map(greetAKnownUser),
    getOrElse(greetStranger)
)

console.log(greetingMessage)

This article has been reviewed by Erwan Guyomarc'h and Alice Rouquette.

What is my job as a software engineer?

2021-11-01T00:00:00Z

A while back at a party someone asked me the usual question: "what do you do for a living?". In a bit of an automated manner I said that I was a software engineer for TomTom, the location company and that I was working on doing maps for autonomous vehicle.

I could see the usual spark in the topic, I make cars drives themselves! What an incredible thing to be part of.

As much as it is true I was bothered by how unrealistic that description of my work was. There are thousands of people making cars drives themselves around the globe! So what do I actually do? what is my actual day-to-day work?

1 · Thinking the complexity and make it reproducible

We then started a deeper discussion about our respective jobs, it turns out he also was a software engineer working into making a test framework for payment devices.

So let's finally answer that question. What we came up with as a job description is:

We think the complexity of a task from one end to the other, looking at all possible states, all transitions, all constraints and every needed operations.

Once we have a clear vision of the operations' maze that is needed in our mind we encode that within a machine to make it endlessly reproducible (given there is no Zombie apocalypse of course).

Okay, that's a convoluted way of explaining our work. There is a lot in here, let's unfold a bit.

First it means that whenever we interact with any computer in any way, the logic to do whatever the computer is doing (rendering this blog for example), was once spread among multiple of humans thoughts.

Second, we as developers holds a lot of complexity at any given time in our brain. We are retaining as much as possible the maze that is our code, from the format of the data to the error handling channel.

Third, I am not producing a map ever, the computer is, I am thinking on how to produce it with my coworkers in order for the machine to do the job.

2 · The color change

So, why am I writing about that besides being able to have an unconventional answer when asked what I do for a living?

Have you ever heard about that none technical person who casually asks to change the website color entirely?

Well, we as developers we have! Let me tell you what happen at that moment in our brain, we start to skim through the code in our head. We load the whole context of where and how those colors are defined, rendered, if there is any variations of those colors, if changing them might mean changing other colors to adapt the style, where are those other colors encoded and ingested by the system?

While we are loading such huge information context in our head to assess the query someone is looking at us expecting a quick answer (and often thinking that changing a color is easy).

3 · Know yourself and others

So what can we draw out of those observations?

As developers our job is to pre-think complexity and make it behave the same way for eternity.

That is a heavy task on an everyday job! Every morning loading thousands of already encoded cases, then thinking the next one, then transcribing it in the machine!

This post is not a complaint, I absolutely love my work, but I think it matters that the rest of the world understand our job from that perspective. Disturbing us during work is the same as blowing on a house card. Asking for a simple question is the same as asking for us to load half of the system in our brain to see where your question would fit.

Having more people aware of the cognitive load of our job makes working as a team easier. The same goes of course for every other job around software, the more we deeply understand others work the better we handle our interactions at work.

So next time someone asks you what you do for a living, think twice and ask yourself, what do you mentally and physically do exactly?

DevOps: Accelerate software not human

2021-11-01T00:00:00Z

1 · Coding is easy, building complex software is hard.

Coding your first line, learning your first program and starting to get result takes few weeks to some month, how exciting! In that regard, coding is easy to learn. Welcome to the beautiful world of developers.

After getting started with your new position you will start to hear questions regarding your code like:

How to interoperate pieces of software? When and how to design API? How will my code look like at runtime? How to tool my piece of code to be observable? How to enable end to end tracing? How to document both features and codes for everybody involved to be able to participate? How to react to failure or shortage of services? How to store the data, in which format, for which kind of queries? How to display it to none technical user? How to make a feature available in a nice manner to users?

Feeling overwhelmed? those are just few examples of all the questions that revolve around a bunch of line of code which will live for years somewhere within a data center.

Feeling overwhelmed by them is totally okay. Coding is easy, engineering and building complex software across a group of people and to the world is hard.

2 · DevOps culture and automation to the rescue right?

One of the principle of devops is having small changes. Such changes allow us to answer those question one by one against a context we, as human, can grasp.

This way we won't tool once our entire codebase but do it slowly for every bit of software we release out in the world.

Another cool thing about small changes are the fact that it is easier to manage for the whole development chain, bye bye long night deploying thousands of new line of codes and dozens of features. Now that you have small chunks of changes you can deploy in less than a minute. On top of that you can safely automate it!

Congratulation you can now gather feedback around a feature in less than a day and react as quickly... Or can you? Did the capacity to accelerate deployment and iteration actually change how fast, as human, we can react to that mountain of information lying in our observability systems?

3 · The human brain didn't become faster

Here goes the trap, now that the whole toolchain is as fast as computers can be to test, deploy and monitor your software, making a change should be as fast right?

In reality, it pushes the pressure from deploying once during hours to the everyday developers' life.

But the pace of our everyday life didn't change. It takes the same amount of time for human to design a feature, investigate a database performance, read a blog article or learn an entirely new framework.

Selling DevOps as accelerating and enabling people isn't fully right in the end. DevOps pushes some complexity out of the developers way but brings new one that challenges our time management and at it's core the time we have to stop and think about what we are doing, what we are coding, how and why.

4 · It's time to stop and think

I am not advocating against DevOps, I wouldn't code any other way now that I embraced it but that set of practices should be put in it's right place, not in the way of our time as developers. When aligned to the company or team culture, DevOps should actually free developers, product owner, designers and sales some time to gather, stop and think about what they are doing and selling and that time is incompressible whether we like it or not.

Us as developers should embrace deploying as soon as it is ready and get comfortable about having automated integration steps to have a safety net around our probable mistakes. This, on the other hand should not prevent us from taking the time to think our code through.

Let's respect our human pace and our limits regarding how much data we can consume or how long it takes to discuss our software. This way we can take the right decisions and iterate toward the right direction.