Have you ever struggled with CSS? Have you found it hard to structure a large CSS codebase, even when using methodologies like BEM or OOCSS? Have you tried using CSS-in-JS solutions, but struggled with the setup or lack of typing? Or maybe you've used Tailwind, but find the initial bundle size intimidating, or the tooling to reduce it too complex?

Stitches is a new CSS-in-JS library from Modulz and Christian Alfoni, creator of Cerebral and Overmind. It promises "Near-zero runtime, server-side rendering, multi-variant support, and best-in-class developer experience."

We'll take a look at what this means, and how Stitches compares to existing CSS-in-JS solutions like Styled Components, Emotion and Material UI.

Getting started

Stitches provides two separate libraries, @stitches/core for framework-agnostic functionality, and @stitches/react which is similar to Styled Components for React.

@stitches/core

Stitches can be used without any specific view framework, and provides us with several benefits, for example:

Type safe CSS

Minimal CSS size due to atomic classes

Custom token support

We'll take a look at each one of these.

Type safe CSS

Here is a very simple example using nothing but @stitches/core:

When using a modern editor like VS Code, we can get full autocompletion of CSS properties with Stitches:

No more mistyped CSS properties!

Atomic classes

The above example renders into:

What are all these classes? Let's take a look:

Stitches splits up our styles into separate atomic classes; this is useful because components with the same style only need a single class definition per property, e.g. _initial_pl_hmLUax, which maps to padding-left: 1rem, is used both for our root and content classes!

Atomic classes means less CSS, which makes our page load faster. This is a good thing.

Custom tokens

Even the simplest web page needs some kind of overall look and feel, which might be as simple as a preferred font and color palette, or a full theme with customized components, predefined margin sizes and all the bells and whistles.

To avoid having to repeat yourself with your selected colors or sizes, Stitches lets you define custom tokens:

Here we can see we have defined a couple of colors, primaryText and primaryBlue. Notice how these actually show up with autocompletion when we define the classes! This also works for the other kinds of tokens like sizes, radiiand many more.

Themes

Stitches also provides an easy way to create themes with your existing tokens:

Here we create a new class darkTheme, which will override the colors for our custom tokens, generated using CSS variables:

While Stitches does all these things behind the covers, the end result as a developer is very intuitive and easy to use!

@stitches/react

React is pretty popular, to say the least. To make it easier to build styleable, reusable components with React, there are several great styling libraries like Styled Components, Chakra UI and Material UI.

Stitches provides a simple alternative to these, and can be used either with only @stitches/core as shown above, or with @stitches/react for a more component-based approach.

Let's look at an example:

Here we create a styled config using some custom tokens for colors, padding and border radius. To make the usage of the tokens more obvious, we prefix them with $.

One cool thing to notice is that we can mix and match tokens with regular units, as in padding: '$medium 2rem'.

Once we have our config, we can very easily create styled versions of components, for example the native button DOM element.

Variants

To build a complete design system or component library, we probably want several variants of each component, for example a small, medium and big button. Thankfully, Stitches makes this very easy:

Here we have defined three size variants, each with their custom padding and font size. The result is a custom Button component with a strongly typed property size that can be one of large, medium or small. You will even get an error if you try to set a size that doesn't exist!

Final words

Stitches is a fresh breath in the ever-growing ecosystem of CSS and React components. Personally I find it extremely pleasing to work with, and would recommend everyone to try it out!

To find out more, check out stitches.dev, or install it right now with npm install @stitches/core @stitches/react and start making your own performant, responsive design system today!

Wrap up your CSS with Stitches!

There are many ways to make sure that your audience is following along as you present. Here comes a few learning points we had from analyzing different talks, both our own talks, the king of Norway, and many many others 👑

Some examples of talk analysis

At December 7th, I introduced the concept of recreational talk analysis. In our competency group on talks, we have also done this in a more structured format, analyzing both each others on competency days, as well as more renowned "third-party" speakers. In this article, I share the most important results!

Know your audience!

First and foremost, you need to go quickly through for yourself before your talk; who is your audience, really? Is the audience the steering group in a company wanting all the answers, your best friends at your bachelorette party wanting a good time, or children trying to learn coding?

Giving it some minutes in advance to understand who your audience is really helps when it comes to keeping them focused. If you organize your bachelorette-speech in the same way as the presentation to the steering group committee, they would get bored. The other way around, the steering group would perhaps raise some eyebrows on structuring laying out the Q3 numbers as a bachelorette-party-speech.

Alternate style and break up your flow!

In every presentation, it can be good to do something that breaks with the normal flow in your presentation. Especially if it's a longer presentation. Your may for example "break up" by:

Play a video in one of the slides

Ask somebody in the audience a question

Do something completely different in just 1 slide

Play a part of a song

Say something humorous

Do something "live" at the scene

Techniques

Play on people emotions

Make sure people feel that you are talking about them:

Address all the members of your audience directly in the beginning of your presentation

Let the audience know that you are seeing each and one of them.

Tell stories that people can relate to. Use examples from your audience's everyday life to explain something. Something that you think every member of the audience can relate to.

Be humorous

Humor has a natural way of keeping people focused during a talk! Be spontaneous with your jokes. However, be careful not to use it too much. Also, only use humor if it comes natural to you.

Be personal and open

There are good reasons for the success of TV shows like Keeping up with the Kardashians, The Osbournes and Paradise hotel; we all love to listen to other's secrets!

If you are comfortable with it, being personal, open and honest on stage can really engage your audience. Especially curious human beings will really get their ears out.

Gestures, body language and pitch of voice

Lastly, some tips on gestures, body language:

Use your hands to emphasize special points in your talk!

Make sure to get direct eye contact with your audience

Try "preaching" to your audience

As Trond will talk more about tomorrow, there is also a lot you can do with your pitch of voice during a presentation. More on this in the next article 🚀

Keep your audience engaged!

The other day, a group of designers here at Bekk was so lucky to get a super interesting presentation about emotions from a psychologist. The Psychologist was Lars Hære.

The topic Lars talked about was emotions. I’m not going to repeat everything he presented, but I’m going to give you a super short sum-up of the revelation I got, and a Ted-talk to get your mind spinning 🤯

The 5 basic emotions

First of all, there are 5 basic emotions. And to everybody who has watched Inside out you might remember Joy, Fear, Sadness, Disgust, and Anger. The interesting thing that Lars pointed out is that there are four emotions that are “negative”, and only one that's positive, Joy. That's unfair 😫. But evolution and our instinct to survive might have some good reasons why.

The revelation:\ In most services, we are not trying to make people feel joy, but to avoid people to feel any of the other four “negative” emotions! If it doesn’t make you angry, scared, disgusted, or sad, it’s probably a well-designed service 👍



Then to the Ted-talk, what if machines themselves could read these emotions, what opportunities could that make? 🤷‍♂️

Lars presentation was much more exciting than this article, and if you are interested in the topic, I urge you to visit the webpage for the coming book about design and psycology that he is writing togheter with deisgner, Erling Hamsø: https://designogpsykologi.no



Design and emotions

I sitt forrige selskap lagde seriegründer Kyrre Wathne whitelabel-løsninger i skyen. Det fikk ham til å tenke på om ikke de store skytjenestene snart vil tilrettelegge for noen nye forretningsmodeller som innovative selskaper kan benytte seg av.

Vi tenker høyt sammen.

Hva kommer etter SaaS?

In this article, we compare error handling methods in Kotlin; specifically: exceptions, Either, and Result.

Traditionally, we may use exceptions to handle errors. We perform some action and throw an exception if something goes wrong. But, if you are calling a function, how do you know if it can throw an exception at all? And if it does, what kind of exception? These are hard questions to answer, enter Either:

Either can be used as a typesafe alternative for error handling. Either holds one of two values, a Left or a Right. When we call a function which returns an Either, we are forced to handle both a successful and an unsuccessful case, and get to know exactly what this function returns. On the other hand, if we were to use exceptions, there is no method signature for the developer to see what cases may occur. Developers may annotate a function with @Throws, but since this is optional, it is not dependable. Therefore, with lack of a complete method signature, developers must either ignore the exception or interpret the function body and all possible underlying method calls.

Let us say that we want to validate a user object using an opaque type. Look at the code below. The only way to obtain an instance of ValidatedUser is to provide a RawUser with a valid email address to the static validate function.

And we may call it like so:

You may have already noticed that we catch Exception and not InvalidEmailException. This illustrates the main issue with exceptions, they are dynamically typed. The only way to know which exceptions might be thrown is to manually parse the function body (and the body of any internal function calls). This may not always be trivial, for example, if you are calling a function from an external library.

Luckily, there is a neat solution to this problem. Using the same RawUser class, we can implement it using Either from the Arrow library:

It is crystal clear what this function does from the signature alone. You either get a ValidationError or a ValidatedUser. Because Either is a sealed class, we also get exhaustive pattern matching using when. Additionally, we get smart casting which automatically gives us access to an a (the error) if it is a Left-instance, or a b (the success value) if it is a Right-instance.

There are cons to this approach as well as with exceptions. The choice of whether the error value is in the left or right slot is completely dependent on convention. It is easy to confuse, especially when you are working with different implementations where they are reversed (for example, Result in Rust and Kotlin-result). Consider this, which of these cases prints the error?

Either is rather generic, and thus, Left and Right may not make sense for the reader by itself. Additionally, you may also notice that Left and Right suddenly change to a and b. Not a huge problem, but readability suffers nonetheless.

If you want all the advantages of Either, but also want to stay semantically accurate in the context of error handling, check out Result<T, E>. Right changes to Ok, and Left to Err. It makes it significantly harder to confuse Left and Right as Ok and Err makes sense in their own right (pun intended).

Ah, delightful!

Error Handling in Kotlin Without Exceptions

Jeg så Lehmkuhlforelesningen på NHH 28. oktober 2020, hvor Rune Bjerke snakket om implementering av strategi i DnB. Han snakket om hvordan de på toppen (styret og toppledelsen) satt på bakrommet og meislet ut fine foiler med revolusjonerende tanker rundt hvordan DnB skulle lykkes i det utfordrende landskapet som lå foran dem. Han forteller om hvordan de inviterte til heldagssamling på Klækken Hotell for å presentere disse tankene, hvor mye de forberedte seg og hvor utrolig bra presentasjonen gikk. Det virket nesten som at de på et tidspunkt hadde tenkt at heldagssamlingen var leveransen, og at etter denne var jobben deres gjort. Rune forteller videre at når de kom tilbake til kontoret, innså de fort at jobben omtrent ikke var begynt, og at de fortsatt stod på startlinjen for implementering av ny strategi i DNB.

Foredraget fikk meg til å reflektere over hva som gjør at organisasjoner mislykkes med implementering av en ny strategi. Jeg har ut fra dette laget en oppskrift til jul på syv slag (i tråd med månedens juletema), som til sammen øker sannsynligheten for å ikke lykkes med implementering av ny strategi i organisasjonen:

Slag 1: Utarbeid strategien bak lukkede dører og lanser med et Big Bang i resten av organisasjonen. Gjerne på heldagssamling utenfor kontoret uten noe knytning til en vanlig arbeidsdag. Forvent samme engasjement og forståelse for de velvalgte ordene i strategien som du selv har når du snakker med folk i etterkant av samlingen.

Slag 2: Gjør det så fluffy som mulig, for å sikre at ingen forstår hva strategien egentlig betyr, men bruk konfetti (MASSE konfetti) når du presenterer – det funker alltid for å maksimere forvirring.

Slag 3: Sørg for at strategien ikke er i tråd med kulturen i organisasjonen, og ikke kast bort tiden på å jobbe med organisasjonens kultur hvis det skulle vise seg å være et gap. Var det ikke noen som sa Strategy eats culture for breakfast...?

Slag 4: La det være opp til tilfeldighetene hvordan strategien spres i organisasjonen. Skulle du være så uheldig at du har laget en kommunikasjonsplan, ikke la den dra for langt ut i tid. Tenk heller på den som en sjekkliste, og at det er fint med alt du kan sjekke av og bli ferdig med.

Slag 5: La det være opp til folket å oversette den nye strategien til sin arbeidshverdag. Ikke spill mellomlederne gode – det er synd om de faktisk kan svare på alle spørsmålene de vil få (det øker sannsynligheten for å lykkes).

Slag 6: Hvis noen som ikke kunne være med på samlingen skulle finne på å spørre om hva den nye strategien handler om, send den på e-post til dem – og pass på å ikke ha noe tilgjengelig tid i kalenderen din til presentasjon og diskusjon.

Slag 7: Sørg for at de ansatte blir målt på helt andre ting – eventuelt kan du bare la være å endre det de blir målt på i dag. Det er et sikkert knep for å få folk til å fortsette som før.

Dette var mine syv slag til jul, som vil hjelpe deg til å ikke lykkes med implementering av ny strategi.

Skulle du derimot ha et ønske om å lykkes, skal jeg avsløre mitt aller beste råd (utover å sette motsatt fortegn på slag 1-7): Gjenta budskapet om og om igjen. De som strategien vil ha størst konsekvenser for (de ansatte) har ikke fått samme modningsperiode som de som har utarbeidet strategien. Gi dem den tiden, og sørg for å lukke dette kunnskapsgapet, slik at dere står på samme grunn når strategien skal komme til live. Rune Bjerke forteller blant annet om hvordan de laget en elevator pitch som de presenterte i heisen (som forresten også involverte noe froskekostyme), og at de gjentok det samme budskapet til nye personer, om og om igjen.

Det er på ingen måte lett å lykkes med å implementere ny strategi i en organisasjon, men mangel på involvering, kommunikasjon og tydelighet vil med sikkerhet stikke kjepper i hjulene. Det blir ikke lettere i disse Covid-tider når folk ikke lenger møtes ved kaffemaskinen (eller i heisen), men det blir på ingen måte mindre viktig.

Hvordan mislykkes med implementering av ny strategi?

The year was 1996, and it’s the 11th of November. Macarena is topping the charts, Bill Clinton wins his second presidential term, and an article in a very peculiar e-zine is published which would change the world of information security forever. The publication in question was Phrack, an e-zine for and by hackers. The article in question was Aleph One’s “Smashing the Stack for fun and profit”, thus began what many regards as the golden age of software exploitation.

Smashing the stack for fun and profit was the first-ever article to in detail describe the buffer overflow vulnerability. Sure, buffer overflows were already being exploited in the wild prior to the release of Aleph One paper, but it had never been documented to this extent before. A lot has happened since the golden days. We have 64 bit-systems, compiler protections, kernel protections, and so on. While the examples from the paper aren’t possible without some dangerous compiler tweaks, the essence of the stack-based buffer overflow is still the same.

Buffer Overflows

So, what is a buffer overflow? An easy way to explain it is to imagine a spreadsheet containing a list of items. Each item has an id, a name, and a price. Imagine has implemented a very poor system for updating the items.

Now, what would happen if someone entered in a bunch of A’s while updating the name? Since this terrible spreadsheet app lacks bounds checking on the name, the value of name overflows into the price field. Now the price of the third item is 9 A’s. If we think a little more creatively about this, this means that we are able to write anything we want to the price field by carefully crafting a payload, that allows us to set the price to 1. Now that would be bad for business.

Ok, now we know the essence of what a buffer flow is, but what about the stack?

The Stack

Imagine a stack of plates, you can put (push) another plate on top of the already stacked plates, and you can remove a plate (pop) from the stack. I won’t go into great detail about how it works, but what you need to know is that each program executed by the operating system has its own stack, but instead of dinner plates the stack stores stack frames. You see, every time a program calls a function, it pushes a new stack frame on the stack. This frame contains the parameters for the function, its variables, and data needed to get back to the previous frame.

The Return Pointer

An important part of data needed to return from the function is the return pointer. It stores the memory address for where to resume execution after a function has been called. You can think of this part of the stack frame as the price field from the spreadsheet example. If you can overwrite the return pointer, you may redirect the code flow of the program.

Exploitation

But how do we redirect the code flow? The classic way, as described in smashing the stack, is to use shellcode. Shellcode is raw machine code, which typically executes a command shell. The attack creates the payload, by figuring out how much input is needed in order to overflow the return pointer. This is typically done by trial and error with the aid of a debugger. Next, the attacker uses the debugger to find the location of where the shellcode will end up in memory. If the exploit is successful, it will overflow the return address with the location of the shellcode, start executing the shellcode.

Now a lot has happened since the 90s, and the buffer overflow like it is presented in smashing the stack for fun and profit is no longer exploitable on modern systems. However, as application hardening evolved so did the techniques for exploitation.

The first defense against these sorts of attacks was NX, non-executable stack. This mitigation prevents code being executed in regions of the stack meant for data. This mitigation prevents the use of shellcode on the stack, but from this a very clever trick was discovered.

Return-To-Libc

As I mentioned, the return pointer has to point to a valid memory address. We cannot redirect code execution to somewhere on the stack, as it is marked as non-executable. But what if we point it to somewhere that already exists? Enter the return-to-libc technique. The concept is simple, we jump to a already existing function that will allow us to get code execution. There's multiple way to do this, but the most popular is to jump to the c library function system().

We can't jump directly into system(), as it needs to be called with a useful string such as /bin/sh. In order to pull this off, we can leverage program instructions that modify cpu registers or the stack, as long as they are followed by a return instruction. The return instruction moves the stack pointer, meaning that we can chain together multiple instructions, as it will return into the next memory address we supply on the chain. These instructions are known as gadgets. By using this technique, we can write the string bin/sh in the register that is used as the first function parameter (on 32-bit systems, functions parameters are pushed onto the stack instead).

ROP

Actually, we don't even need access to library functions at all. If we chain together enough gadgets in a clever way, we can execute directly by using a system call. This is known as return-oriented programming (ROP) and is actually Turing complete! Meaning we can make the program to behave in any way we desire. Some people have actually implemented programming languages that run on top of a vulnerable program using return-oriented programming!

Stack Cookies, ASLR and PIE

Further attempts were made to stop exploitation, but they only succeed at making exploitation more involved. Like stack cookies, a special numeric value placed before the return pointer. If you corrupt this value, execution will terminate. However, these can be leaked and in some cases brute-forced.

Next we have ASLR, or address space layout randomization. This mitigations offsets memory addresses with a random value. This can be defeated by leaking addresses in order to calculate the offset.

The last one we're going to cover is Position Independent Executables or PIE for short. This mitigation is used in combination with ASLR. PIE randomly shuffles each section of the program i.e., we no longer know where anything is in memory. This makes leaking a lot more complicated, but it is defeatable by getting the right memory leaks.

Hacking Like it's 1996 - a short history of the stack buffer overflow.

A special year is coming to its end, we look back at the pandemic dominating most of the news (fake or not). Despite the fact that he apparently is immune, it is still a special year for Santa Claus. This year he began his journey towards the cloud for his on-north-pole infrastructure.

The challenge

With a growing number of people on the planet, every year the number of presents made by Santa Claus and his elves are increasing. As a consequence Santa Claus needs to improve his efficiency, not just the way he produces content for all the gifts, but also the way he and his team maintain, improve and extend the on-north-pole infrastructure. An increased number of servers require more man-hours to maintain and ensure everything is working as expected. Moving some infrastructure to the cloud will help him prepare for growth and hopefully also free up time for his valuable elves.

Performing a lift-and-shift migration is not possible for several reasons so he decided to adopt a hybrid approach. All new work is developed in the cloud while his existing infrastructure on-north-pole continues to support the legacy software.

The on-north-pole infrastructure consists of mainly Windows servers and he chose Microsoft Azure as his cloud platform. In this post we look into how he established the connection between Azure and on-north-pole to ensure data from on-north-pole is available seamlessly in the cloud.

Azure App Service Hybrid Connection

How can Santa access on-north-pole services from Azure without opening the entire network to the internet? One alternative, called Hybrid Connection, allows Santa's on-north-pole network to privately extend Azure Cloud. As shown in the illustration below, taken from the documentation, there are few moving parts and it is quick and easy to set up.

Santa Claus wants to expose a new API providing information about his elves. The API should be created in the cloud as a Web App, but some of the data he needs is only available from servers on-north-pole. To establish this Santa Claus needs:

a Web App to expose the new API in the cloud

an Azure Relay to work as the hybrid connection between on-north-pole and the cloud

to install the Hybrid Connection Manager on the server on-north-pole

Provisioning the infrastructure

Santa Claus is no fan of click-ops, which basically is the process of having manual routines for setting up and maintaining infrastructure. Instead, he prefers to use Terraform as his infrastructure-as-code tool for automating such mundane tasks.

The Web App

The Web App is a simple API and can be hosted in a PaaS in Azure. In order to provision an app service using Terraform this is what is required:

The Relay

In order to send messages from the cloud app to on-north-pole Santa Claus needs a relay to forward these messages, or requests as they will appear to the user:

The relay is the service bus namespace which can have one or more connections to a host on-north-pole. One connection is bound to a combination of host and port number. Below, the connection from the relay to the service on-north-pole is defined in Terraform.

An observant eye will see that the tag user_metadata contains a key-value-paired JSON holding the host and port number combination on-north-pole. Santa needs this to make the connection valid once established in Azure.

Connecting the Web App and the Relay

Santa creates a hybrid connection between the Web App and the Relay as the last step. According to the documentation this can be done using the following Terraform:

Santa runs it and it completes successfully and everything seems to work as intended. Now the infrastructure is established with the Web App talking to the Relay, which is configured to talk to on-north-pole.

Navigating into Azure and to the newly created Web App, select Networking in the side menu followed by Configure your hybrid connection endpoints Santa Claus sees the following status for the connection he just made from the Web App to the Relay.

It basically says it is Not Connected and he needs to perform the last step in the hybrid connection configuration.

The last (and manual) step

Finally, to make the outbound connection to Azure, Santa Claus has to download the Hybrid Connection Manager onto the server to be connected to Azure. Running the Hybrid Connection Manager on this server he discovers that something went wrong with the provisioning. The hybrid connection manager reports "No endpoint configured".

With this error it is not possible to connect to Azure, and after some research it turns out that this is a known issue with the Terraform azurerm provider. Until it is fixed, the connection from the Web App to the Relay cannot be done using Terraform and must manually be done using https://portal.azure.com on the Web App itself. Santa promises to put the developer who fixes this issue twice on the nice-list.

Manually adding the hybrid connection between the Web App and the Relay solves the endpoint configuration failure, consequently allowing the Hybrid Connection Manager to establish the connection towards Azure.

Conclusion

Using Azure Hybrid Connections and Terraform Santa Claus and his team are able to start utilizing the cloud without having to perform a large lift-and-shift operation. The Hybrid Connection is quick and easy to setup, but unfortunately requires a couple of manual steps which results in some click-ops that Santa Claus would like to be without. Despite the manual steps, they manage to expose data from on-north-pole and they have successfully started their cloud journey - whether the hybrid connection will remain as part of their infrastructure or not we'll have to see next Christmas.

The complete Terraform for this can be found in the repository here.

Have a merry hybrid Christmas

Working with the Maybe type in Elm may result in excessive pattern matching because Elm forces us to handle all possible outcomes. In this article, we investigate how the Maybe.andThen function can be used to improve readability by reducing unnecessary pattern matching and boilerplate code.

Consider that we want to implement a function that takes a String name which consists of several names and returns the last name if it exists. The signature can look something like this:

We implement the toLastName function by splitting the String on space, reversing the list, and finally collecting the first element in the reversed list. Using Maybe.map, we can do it like this:

As you can see, we end up with Maybe (Maybe String) after List.head operation, because head operation returns a Maybe String. Therefore, we have to use a Maybe.withDefault, in order to extract the inner Maybe. To remove this line of unnecessary code, we can use the andThen function:

andThen implementation

andThen is a function very similar to map, but the mapping function is of type a -> Maybe b rather than a -> b. Just like with map, the transformation function we supply as parameter one is only applied if parameter two is present (i.e., a Just). andThen returns the return type from the transformation function, but if Maybe a is Nothing, andThen returns Nothing and thus proceeds to the next chain in the pipeline. Essentially, this means that you don’t have to pattern match the Maybe you are working with, which reduces boilerplate code.

By using andThen function, we can remove the excessive line in the previous implementation:

As we have seen so far in this article, andThen is suitable for transformations that may fail, in contrary to map. map is fit for transformations that cannot fail. As such, we can also use andThen as a filter. By forcing the transformation to fail, by returning Nothing, when the value does not satisfy some condition, we have created a filter.

Let’s say that we reimplement the same toLastName function, but this time we want to return Nothing if the last last name is less than seven characters. Using map, we can implement it like this:

In this example, we also end up with a Maybe String and thus need an additional withDefault expression. If we, on the other hand, make use of andThen, we remove this line:

Reducing boilerplate code in Elm with Maybe.andThen

Ever wondered where to declare your constants, or static methods in Kotlin? Even though Kotlin has no explicit notion of statics, there are multiple ways of mimicking the same behavior.

A static is a field or function that is independent of class instances and can be accessed directly, e.g. a global constant. Coming from a Java background, one often defaults to using companion objects - at least I do 🤷‍♂️ This will typically result in something like this:

the constant is then accessed from Foo.baz

Seeing that Kotlin allows for defining top level constants and functions, that is, constants and functions defined outside of any class, one can usually make do with something like this:

Both of these approaches are acceptable for some usages, but unless you really want to tightly couple a field with some class, top level definitions is the way to go. For most uses, companion objects are simply expensive and overkill. Here's why: When creating a companion object and placing constants inside of it, the Kotlin compiler decorates🎄 its outer class with an object, namely the companion object, in addition to the structure needed for instantiating and accessing it.

By using IntelliJ’s Bytecode Viewer and Java Decompiler tools, we can compare our Kotlin source code to its equivalent Java counterpart. Let's have a closer look at the companion object approach:

This concise Kotlin implementation will yield bytecode equivalent to the following Java code:

That's a lot of fuzz for a simple static variable 🤯

A top level const, like const val santa = "claus" results in a much less bloated Java block:

In addition to providing more efficient bytecode, the syntax of top level declarations is simply cleaner. So, unless you really need companion object specific behavior, stick with top level declarations 👌

If you want to group multiple constants within a single block, the object constructor is useful. It creates a singleton object that can encapsulate your constant, in a readable and efficient manner:

The three elves defined inside the Northpole object are all static members within a single class in the equvalent Java code:

Conclusion

There are multiple ways of mimicking statics in Kotlin. Companion objects gives you a "static" block within a class, but with a tiny bit of overhead compared to its Java counterpart. Instead you could make use of top level constants and functions, declared outside of any class. And if you have multiple related constants (or functions), consider wrapping them inside an object declaration.

Companion object vs top level val

By utilizing Tone.js one could easily produce some sounds, and if you’re lucky it could be quite musical. In this article we’ll look at combining React with Tone.js to make a simple sequencer.

Tone.js is, by their own description, a “Web Audio framework for creating interactive music in the browser”. Its API is quite low level, with good flexibility with regards to asynchronous tasks and extensibility of sounds to produce. Today we’ll create what’s known as a music sequencer, which is a way to sequence a series of notes.

\ First, some music theory. For the rest of this article we will utilize the notes C, D, E, G and A. This creates what is known as the C Major Pentatonic Scale. Why these notes and this scale? In simple terms, it means all the notes sound good together. Thus increasing our chance of making something that sounds musical. I wont go into why these notes sounds the way they do, as it is way beyond the scope of this article. You'll just have to trust me on this one.

Now, let's bootstrap a project using create-react-app, and then add Tone.js with npm install tone \ Then we’ll import Tone.JS, create a synthesizer, or synth for short, which will generate our notes. Then attach our synth to five buttons, and play one of the five chosen notes when they’re pressed.

triggerAttackRelease takes two arguments: the note to be played, and its duration. The note is a combination of the note name (e.g C) and the number is which octave it is played in, meaning how high or low. The duration 8n means an eighth-note, meaning, an eighth of the duration of the bar we’re currently in. (Side note: a bar is usually four beats of four quarter-notes, and by extension, the same bar can also hold eight eighth-notes)

Now, let’s make a grid, with our five special notes stacked on top of each other in ascending order, and as we’re playing eighth-notes, let’s make the grid 8 spaces wide. For each eight note, a column in our grid will be played, and sequencing through a column at a time, before starting over at the start. Thus, we need to save the state of each note in the grid if it is going to be played or not.

Then we’ll use Tone.Sequence to make our sequencer. As our potential hit machine now could play several tones simultaneously, we’ll first change our synth for a polysynth. Thus being able to play multiple (poly) tones at the same time. Our triggerAttackRelease function can now take an array of notes as its first parameter

That’s it for our musical sequencer. It’s not much, but it’ll get you going with Tone.js, which has great documentation. You could also take a look at the examples and demos on their website for more inspiration. Who knows, maybe your future is in making sick tunes with Tone.js? Somebody get Grammy on the phone!

15-Dec

Today's posts