Volta

This post is about Volta and why it should be the first thing you should install on your machine as a JavaScript developer. The Getting Started guide describes Volta like this:

Volta is a hassle-free way to manage your JavaScript command-line tools.

and

Volta solves the problem of global packages

and it’s

Managing your [JavaScript] toolchain

The first time I landed on the page I had problems really understanding what the Volta’s value was just by reading the descriptions. Somewhere in the docs they are talking about the JavaScript toolchain™. I never used that term before. What does it mean?

What is the “problem of global packages”?

The definition of “JavaScript toolchain”

In order to understand which problem Volta solves, let’s define what they mean by “JavaScript toolchain”.

The JavaScript toolchain that Volta manages for you consists of all the tooling that you need in order to run and install JavaScript packages as well as globally installed command-line tools.

You can categorize these tools into three categories:

1. The runtime, that would be Node.js
2. JavaScript package managers, that would be npm and Yarn
3. JavaScript CLI tools, that would be any globally installed npm package binaries

The problem of global packages

The problems of global packages are slightly different for the three categories mentioned above.

Node

The problem with a global JavaScript runtime is that you have to switch the runtime globally per project if you need different Node versions for different projects.

This can be done via a script whenever you enter the directory via command-line but the switch can be slow and any global packages you installed for one version are now not available anymore or might break because they depend on a specific version to work.

Package managers

A certain Node version comes with a certain npm version. Yarn global installs might require a certain Node version or just possibly not work with a certain version of Node.

Some projects might need different versions of package managers because they might rely on features that are differ between the version.

Global npm packages

For globally installed npm packages or JavaScript CLI tools as you might call them, the problem can be either of two things:

1. It is installed for the currently active Node version. That means it is not available when you switch to a different version.
2. Or it just uses whichever Node version is currently active which creates reliability issues because it might not be compatible for this version. In some cases it even needs to be recompiled.

Volta solves all of this and gets out of your way. Let me tell you how.

How Volta manages Node

Volta allows you to install Node via the Volta CLI. volta install node installs the latest LTS version of Node. You can also install a specific version with volta install node@10.15.3 for instance.

Whenever you run a Node program it will use the latest version you installed. If you need to use a specific version of Node for a project you can pin the currently active Node version to the project’s package.json with volta pin node or a different Node version with volta pin node@10 for instance.

From this point on all Node programs and locally installed npm packages that are being executed in this project are run on that pinned Node version and nothing else.

The pinning is nothing else besides an entry in the package.json. This means you can easily change the Node version by hand at any time if you want.

When you share this project via GitHub any other team member that has Volta installed on their machine will also automatically use the pinned Node version in that project. Volta will just go ahead and install it if you don’t have that specific version installed yet.

This is huge for teams. As long as Volta is installed everywhere it just takes care of using the right version per project and gets out of your way.

Many times I have experienced onboarding team members running into problems or experiencing inconsistencies because they were using a different Node version in a project.

How Volta manages package managers

Package managers can be installed and pinned per project with Volta.

On first install of a package manager Volta installs the latest stable Node version with it and binds the two so that the package manager works forever.

Via volta pin you can pin the package manager and desired version to a JavaScript project.

How Volta manages JavaScript CLI tools

Volta allows you to install any JavaScript CLI tool and will make sure it works forever once installed. If you want to install Sindre Sorhus’ tremendous Trash CLI tool you can do that by typing volta install trash-cli to use it.

Volta installs the latest LTS Node version with the tool if that version of Node was not installed yet and will always run the tool on that version of Node forever. No matter which version of Node you are using in your current project.

When you use a different Node version manager or install your Node versions globally yourself you can never be sure if all your CLI tools are working.

How it all works together

Once Node and package manager are pinned for a project and Volta is used by all devs on your team and your CI/CD automation, all weird bugs and weird behavior caused by incompatible Node and package manager versions are completely eliminated.

This tool unlocks extra stability levels for the JavaScript dev and essentially makes the toolchain much reliable.

Meaning: if your setup worked once it will definitely work again later. No matter what you globally install for other projects.

It’s one of the first things I install on a fresh system. I highly recommend you have a good look at Volta.

And on top of everything it is wicked fast because it’s written in Rust and Rust compiles down to a native binary.

New job, who dis?! - Engineering Manager edition

Last year my manager quit. I was offered his position and since December or so, I am an engineering manager.

It is strange to move from a well-defined role into such a hazily-defined one.

A few things have changed. I don’t code anymore at work and the relationship to my team has changed. Especially to those who now report to me.

I want to be the best possible manager to them that I can be, so I am busy learning.

My friend Henning Glatter-Götz recommended the Managing Up podcast to me. I have listened to a bunch of episodes so far and it has been very helpful already.

If you are an engineering manager or are interested in becoming one, I highly recommend you check out Managing Up.

So far, my favorite episodes are:

Episode 5: One on Ones: The Basics

I loved hearing about how they approach their one-on-ones and about their different techniques on how to ask questions. It was also really great to learn how commonplace one-on-ones are in engineering organizations. One thing that surprised me was that it seems to be common to have weekly one-on-one meetings. We do it bi-weekly at LogMeIn. I think that it’s a good frequency if the one-on-ones are not skipped.

Episode 26: Creating Self-Managing Teams

This episode really exposed the experience the co-hosts of the show have. They are very open about mistakes they have made in the past and discuss how you might achieve “managing yourself out of a job”. This is a phrase that I have been thinking about a lot myself and I feel that should definitely be an engineering managers goal.

Build a Slack slash command app with Zeit’s Now

First of all: Now is so flipping great it’s not even funny. Basically it is this:

You write your app, type now and it’s deployed. You get back the URL under which it is deployed and that’s that. Every other deployment results in a new deployment under a new URL.

The latest deployment is always aliased to a URL that doesn’t change and that’s the address to your app or API.

If you hook up Github, your branches get deployed automatically as immutable deployments. The alias of those deployments contains the branch name. Every push results in a new deployment.

Now is a perfect fit if you want to create a slash command app for Slack.

Slash commands are super simple. When you send off a message like /mycommand yey all the command does is sending a post request over to a URL with your command and then prints out the response to you in Slack.

I used Micro (also made by our buddies at Zeit) to set up the API. Micro is a small no-config Node tool that allows you to create a microservice in no time. Write the function that takes the request and start the microservice with the micro command and you’re good to go.

Now comes with initialization templates that have configurations for different tools, frameworks, static site generators, etc. One of them is called node-micro which configures Micro for Now. In order to use it, type now init and then choose node-micro.

It works out of the box. If you start the now dev and curl localhost:3000 you get the hello world message as a response.

You can deploy that by just typing now on the terminal or by hooking up now with your GitHub repository.

Next, configure your Slack slash command. Give it a name and a slash command and the endpoint URL. In our case it would be the alias that was generated. The alias always points to the latest deployment.

When you use that slash command it will post back that hello world message back into your Slack chat as a response.

Now you are ready to take over the world with your Slack slash command!

I was at ReactEurope and now I "get" React Hooks

Last week, I went to Paris to spend some time there with my family and to attend ReactEurope.

Based on the kind of mediocre design of their website I did not expect a lot of care to go into the organization of the conference. I expected a dull conference room in a hotel and some interesting talks.

I got some interesting talks and a dull, stuffy conference room in a dull, ugly area of Paris. The room was too small for so many people though. The air was terrible and people coughing and sneezing all around me. I was not capable of spending a lot of time in there.

Instead, I took some time to read through the React Hooks documentation. Let me just take a second to say how well written and how thought-out the documentation is. Really world-class. Unlike the ReactEurope conference.

I also started rewriting my Grit editor from Preact and htm to React with hooks. Just so to get familiar with them.

It is always hard to convey how features like that impact your development experience without trying it out. I have only rewritten a small part of it so far but I like it a lot.

The concept of custom hooks especially seems to have a lot of impact when it comes to simplifying your code.

Here is an example.

In order for Grit to work the user has to store the path to their Markdown files in the settings. I store the settings by using this ace package called electron-store by Sindre Sorhus (Shout out to him, what would I do without his stellar open source work?!).

This path needs to be shown in the UI via a state variable and it has to be synced back to the electron-store if it is changed.

So I created this custom hook called useElectronStore to read the path from electron-store and to set the filePath state variable from it and to set both, the state variable and electron-store, with the new value once it is changed.

And it makes getting and setting electron-store values incredibly easy. The API basically looks like this:

const [someValue, setSomeValue] = useElectronStore('someValue', '');

The 'someValue'-string is the path in electron-store and the second value is the default value for it.

I can now say that I “get” React Hooks because ReactEurope was not that great. Works for me.

Announcing Grit: a Markdown editor for blogging with a static site generator

Last year I decided to write more. I thought I’d try a hosted solution because I wanted to concentrate on the writing and not on the fiddling with the site.

Micro.blog was the most attractive solution to me but after using it for a while I realized that, as a developer, I am not capable of leaving the building of my blog to somebody else. There were too many things I wanted to tweak/change, bugs I couldn’t live with etc.

So I ended up sticking with my Hugo solution.

Unfortunately there are many little annoyances when blogging with a static site generator, due to the fact that your posts are a bunch of Markdown files in a folder with a specific file name and some frontmatter boilerplate in them.

Creating a blog post was always tedious. Too many little fiddly things to do before you could just start to write.

In order to remedy this I created a blog-cli that just scaffolds new blog posts for me. It works fine but I really wanted an editor that can do that for me.

That’s why I built Grit. It’s a little Electron app that lets you manage a folder full of Markdown posts and edit them as well.

It allows you to store the path to your Markdown files, filter through the files, create a new file, edit the file and publish via Git.

I used Preact and htm to write it because I was too lazy to set up a build step and I love writing code the browser can directly interpret. For the file editing part in Grit I am using CodeMirror which is a hell of a product, wow.

If you use Hugo, Jekyll, Gatsby or whatever other static site generator to build your blog and are looking for a little convenience there, give it a spin! See the current feature list on GitHub.

It’s an alpha version so there be dragons. But I am planning a bunch of improvements like: drag and drop images, configurable frontmatter and some enhancements around file-creation.

If you want, let me know what you think on Twitter.

Get off of Medium and publish a blog under your own domain

Nobody can wall that off behind a paywall.

Nobody can put a popup over your stuff and say “Don’t look at the content right now. It’s so much better if you login!”.

Nobody can build their brand off of your work. Nobody can make money off of your work, if you don’t want to.

Nobody can tell you “You can’t have your own domain on here.”

Your hoster will most likely not suddenly go: “Oops we just went out of business / were acquired, we’re deleting all your stuff but you can export it until tomorrow and fuck off, basically.”

And if they do, you can go and host that somewhere else.

You can still decide to re-distribute your content to places like Medium, dev.to, Micro.blog, Twitter, Instagram, Linkedin, Facebook and / or via a newsletter. It’s a good way to extend your readership.

You can have an RSS feed! That feed should always be under your domain!

Writing on the internet under other peoples / companies domain names is like giving away money.

Sure, sometimes it makes sense to guest-post on somebody else’s blog because it broadens your audience. That’s a good trade-off.

You should just always have a place that people can come back to that is yours.

Constraints Are Decisions You Don't Have to Make

Since I realized that constraints can produce more creative outcomes I‘ve been fascinated by it.

I think I first learned about it when the iPhone became popular and the form factor and usage patterns produced beautifully designed apps and then website and web app designs that were optimized for mobile.

I read up on it a little and there seems to be a pretty logical explanation for this.

In an environment of abundance the brain is not being challenged. The brain likes to be efficient as possible. If there is an abundance of resources it’s going to be harder to be creative because your brain has no incentive to really get into gear.

In a situation where you are confronted with resource scarcity of some kind, your brain has no choice to start turning up in order to find out how to work around the scarcity.

This results in more creative, out-of-the-box thinking.

I think there is a second element that plays a part in this as well: reduced cognitive load.

Resource scarcity could also be interpreted as: some decisions were already made for you. The fewer decisions you have to make, the more brain capacity is available to you to solve the problem at hand.

The Ultimate Recipe to Attract an Audience on the Internet

My awesome co-worker Emma Wedekind wrote this post about how she got 27K followers on Twitter.

It’s a great post with lots of good advice to grow high quality followers.

I was able to watch the whole ride and it was quite something. There is one thing I noticed about how she used Twitter that I think had significant influence in why she blew up.

She editorializes her Twitter account. She deliberately tweets content that might be valuable to the developer community. And she responds to tweets a lot.

She also keeps a very friendly, welcoming and helpful tone.

Be kind and provide value frequently and consistently over long stretches of time is basically the ultimate recipe for attracting and growing an audience on the internet. We’ve all seen this work many times.

It has happened many times over on YouTube, Twitter and of course many blogs.

The thing is, the hardest part is not to come up with the topics or to do the writing itself. The hardest part is to keep it going in a specific rhythm over long stretches of time.

It takes a lot of discipline to keep that up, it’s hard work. But if you can do it, it will pay off.

My hat goes off to Emma for doing it.

If you want an audience too, follow the ultimate recipe and you most likely will not blow up like Emma did, but you will for sure attract an audience that cares about what you have to say.

TFW You Realize What Technical Debt Actually Means

A few weeks ago I set out to write a blog post about technical debt and the complexities of getting rid of it, or some of it, when you work for a company.

I wanted to see what others had written about it and of course I landed on Martin Fowler’s article about technical debt. When I started reading it I realized that up to that point I didn’t really know what tech debt was.

It seams that while being confronted with the eternal vastness of software engineering, this is what my brain does: when I hear a term for the first time and I can deduce its approximate meaning from context, I store it as a known term. Even though I don’t know exactly what it is.

What I deduced it to be was: “Legacy code, that makes it hard to maintain your code or to add features.”

And every time I heard or used the term “technical debt” there was a tiny little voice in the back of my head going: “Why is it “debt”!? I don’t get it.”

Anyways good ol’ Martin cleaned up that part of my brain and made it crystal clear for me:

Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt.

Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice.

We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.

It’s a metaphor! It is actually a term that was invented in order to explain consequences of sloppy coding to people in suits!

Fowler goes on to write:

The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline.

The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.

Thank. You. Technical debt can lead to crippling interest payments. These can slow down your development teams so badly that you can’t compete anymore.

The term “technical debt” carries all the information you need in order to make the argument to company leadership why getting rid of it or keeping it at bay may be a wise business decision.

Who knew?! 😂

Nested Loops Bow-Out

As you may know, I am a member of the JavaScript band Nested Loops. We performed on the last three opening performces of JSConf.eu.

We will not be performing at JSConf.eu this year.

It was a great honor and privilege for us to be able to do that and we are thankful for the opportunity.

We produced original music for the conference and performed it in a browser. If you want, you can re-live of our performances on YouTube. And you can listen to our story on the Changelog podcast here.

I have no idea if we will ever perform again at JSConf.eu or any other event.

If you want to talk to us about performing at your JavaScript conference or any other event, or if you needs some original music just drop me an email or DM me on Twitter.

How to Use Async Functions

This article by Dr. Axel Rauschmayer was exactly what I needed to wrap my head around how to use async functions without confusion.

Because I was just using them intuitively so far and because of their synchronous style I got confused about when to try-catch. I also attempted to call an async function without await in front of it while using await in its body, fully expecting it will be executed synchronously.

It’s important to remember that the foundation of async functions is Promises.

The most interesting parts of Axel’s article to me, were these:

• Async functions are started synchronously, settled asynchronously
• Parallelism
• Immediately Invoked Async Function Expressions

blog-cli: A CLI for Blogging with Static Site Generators

My blog is built with Hugo. Every blog I ever had was built with a static site generator or a file based CMS. I love static site generators, they make content management simple, they are secure and it’s fun to build websites with them.

For me, they have one problem: creating a blog post is annoying. Typically the file for the post needs to have the date in it and the slug and then you need to put in the Front Matter for the post. It is all just very tedious and annoying.

That’s why I made blog-cli. It creates the Markdown file for me at the right location with the correct file name, inserts the basic Front Matter and opens the file in my favorite Markdown editor. This means I go from post idea to writing in 1 second.

This should work for most static site generators. At least for simple setups.

Here is how it works.

First you have to install blog-cli. You need Node.js and npm for that.

npm install --global @kahlil/blog-cli

Then you need to tell blog-cli where you want it to put your posts.

blog --path ~/my-blog/posts

Then you need to tell blog-cli about your favorite Markdown Editor.

blog --editor 'ia writer'

Now you are all set and you can create a new post and open it in your editor by simple specifying a slug.

blog my-new-cool-post

This will create a new file with the filename: 2019-01-17-my-new-cool-post.md in the directory you specified, ~/my-blog/posts in this case.

The Front Matter that is inserted looks something like this:

---
draft: true
date: 2019-01-18T10:03:48.620Z
title: ""
---

Now, if you are part of the cool kids club then you probably keep your files in a Git repository, commit new blog posts and push them to Github at which point it gets deployed to Netlify.

It turns out that blog-cli can help you with that as well!

blog --publish

Will automatically commit all changes with the message ‘new post’ and execute a git push.

Nifty, right?! If you are static-site-generator-blogging as well I hope blog-cli can help you.

If you have any ideas to improve it please send an issue or a PR on GitHub.

Blogging is Back

I’m excited about blogs this year. It really feels like blogs and RSS feeds are back. I am especially happy to see some developers getting serious about it.

Dan Abramov started the year off with a barrage of really good posts of which some already went viral. People even started to translate them into different languages. Wow.

Yoshua Wuyts started the year with a new blog as well. With a sick dark theme, too.

CSS Tricks relaunched their blog with an amazing dark theme design. Not a new blog obviously but man did they make a splash with this. Their post about how they came up with the design is really impressive.

Just a few days ago I stumbled over remove.bg. You can upload any picture with a face on it and it will give you back the same picture with the background removed and made transparent. It’s quite astonishing. How do they do this?!

This Next.js MDX Blog Kit sure looks interesting!