söndag 14 februari 2021

Test Driven Development Deluxe

You have probably already heard about the red-green-refactor workflow when practicing Test Driven Development: start with a failing test, make the test pass, refactor and repeat.

I don’t think I have ever been very strict about the TDD workflow. I usually jump back and forth between the code and the unit test, often begin with trying out naming of functions and less-important things like that. I also find refactoring difficult at that stage, probably because the goal is to write code that does something and that does it well enough. I find it much easier to reflect and come up with refactoring ideas once I see a Pull Request diff on GitHub.

Too much context switch

Until recently, I have failed to find a workflow that is seamless when writing, running and testing code. There is often context switching involved: executing commands that run tests in a terminal or navigating the test runner of an IDE. Sometimes that means a pause with a delay of seconds, or even minutes. The eyes and the brain have lost attention to the code. The focus and flow is gone. Now where was I?

What would Clojure do?

These days, the programming language that makes me 🤩 is Clojure. It has been quite a journey learning how to use the language and how to use the code editor properly. I guess most of us don’t pick up all the good parts of a language or a tool immediately. It takes a while to get there.

An example: my brain hasn’t had the bandwidth enough to get how to use the interactive REPL until recently. There has been a lot of other things to unpack: language syntax, functional programming concepts and keyboard shortcuts. On a positive note: there are opportunities for daily learning and that’s where I am today.

- Wow, I can evaluate an expression in the code editor and the result pops up right next to it!

Star struck. 🤩

The other day I was frustrated with the slow feedback from a CLI test command running in a terminal window. I guess it has something to do with the Java Virtual Machine starting up every time a command is executed. I’ve tried out tools with file watchers, reacting to changes, that speed things up - but there’s still context switching involved, moving your eyes off the editor & the code.

What would a Clojurist do? I think the answer would be:
- Use the REPL.

The REPL, you must use

With Clojure, using the REPL means writing code in the editor, with autocomplete and everything. Also, evaluating the code while in the editor. There is no need to write a statement in a separate terminal window. Your editor has a connection to the interactive REPL (a running server), that will evaluate your code and return the result back to you. With the interactive REPL, you can quickly try things out, without switching to a different tool or view.

This is what some people call REPL Driven Development. Before I learned about it, I have always thought of a REPL as something that is used in a terminal window, away from the editor and away from the code.

the interactive REPL in action

Development Deluxe

By combining REPL Driven & Test Driven Development we have a setup that solves the issues with context switching and slow test runs. From what I’ve learned and tried out so far, I think it is a very nice workflow. 🤩

A very nice workflow

With REPL Driven Development, you write code, evaluate it and get instant feedback while keeping your focus on the code. Maybe the quick visual feedback in the editor is good enough to continue working? Great. Or, you write one or two commands wrapped in a runnable Clojure (comment) block just below the functions, to simplify the evaluation.

Everyone needs a coffee break. Commit the code (yes, the commands too) and continue with it later. ☕

Take a break

Your brain has been charged and you feel refreshed again. When returning to the code, you realize that the commands are probably evolving into something similar to a unit test. Should it be a proper unit test? If so, wrap it in a (deftest) function with some assertions and put it in a separate file.

Here’s a tip: give the unit test the same namespace as the actual code, but add a -test suffix to it. When doing so, your code editor (if it is smart) can run the corresponding tests when in a namespace. If you are an Emacs user, simply press the keys C-c C-t n to run the tests.

Even though you have put the unit tests in a separate file, in a separate folder, there is no need to switch context. Your tests run from where you are and you get instant feedback on the result. Very cool.

I think this is Test Driven Development Deluxe. 🤩

Photo by Felipe Giacometti on Unsplash.

The screenshots are from email-attachments - A Clojure library that makes extracting attachments from email simple.

måndag 11 januari 2021

Simple (within parentheses)

  • - Hey, what's ClojureScript?
  • - It's a thing that compiles Clojure to JavaScript.
  • - I get it. What's Clojure?
  • - It's a Lisp.
  • - ???
  • - You know, a functional programming language that uses a lot of parentheses.
  • - I … get it? 🤯

Don't worry. In this post, I will share some of the basics that I have learned about Clojure and ClojureScript.


With Clojure, you can write simple, functional and minimalistic code. Some of the cool things with Clojure are:

  • data is immutable
  • the REPL is a powerful tool
  • few keystrokes to make things happen

Clojure runs on top of Java, suitable for all kinds of "backend" things. It also runs on top of JavaScript. Yes, JavaScript - making it possible to develop all kinds of apps, tools, products and websites. There's even an option to run in a .NET runtime, but I haven’t tried out that one yet.

What does it look like?

Even though the syntax may look unfamiliar, you can already see in this silly example the less amount of keystrokes needed using Clojure, compared to JavaScript.


Everything you write in Clojure is a list, wrapped in parentheses. That may sound weird. I agree, it is weird. But your eyes will get used to it. In short, the format of writing something in Clojure is:

(operator operands) or even (function arguments)

Here is an example:

... and how it would be written in JavaScript:

If all this is new to you, you might have this expression in your face right now: 😬

That is perfectly normal. I have looked like that a lot during 2020. When digging deeper, you may need to go through The 12 Stages of Learning Clojure.


With ClojureScript, you develop web apps and write simple React components. You write code in Clojure, compile it to native JavaScript and run it in your favorite browser. The compilation happens all the time and automagically as you type.

Just like with Java or .NET in the backend, ClojureScript has native access to JavaScript. You can use and interact with your favorite npm packages and React components just as you would with JavaScript.

Reagent and React

I'm going to fast-forward a bit by adding a ClojureScript library called Reagent. With Reagent, you write React components but with Hiccup instead of JSX. Wait, what?

View components are built up using Clojure data structures. The example above creates html elements with Clojure vectors and keywords. This style is called Hiccup. It will save you a lot of keystrokes and you'll have a lot less of scrolling in your code editor.

What about state?

I'll fast-forward again by adding a very nice library called re-frame.

From the re-frame docs:
“... It has reactivity, unidirectional data flow, pristinely pure functions, interceptors, coeffects, conveyor belts, algebraic effects, statechart-friendliness and claims an immaculate hammock conception. All while being both simple and easy. ...” 💥🤯💥

With re-frame, data is stored in one place called the "app db". Your components will fire events and subscribe to changes in the app db. The cool thing is that you write code in a sequential way, making it very readable and easy to understand. However, the syntax of the actual events and subscriptions might take a while to understand, at least if you are new to Clojure in general.

Here, we have a Reagent component that adds a button component, only when the app is disconnected. It is subscribing to changes of disconnected in the app db. React will re-render the components when the app state has changed.

Cool, but can I use my favorite editor?

Yes, most likely. I know there are Clojure plugins for VS Code, Atom, Sublime Text and intelliJ. I use Emacs, because ... I just like it.

There is something important and special going on with developers and their text editors. I think you will be able to find your favorite dev setup. I also think that you will learn a lot of new programming concepts and styles when reading more about this cool language and its libraries.

Photo by Marcos Paulo Prado on Unsplash

tisdag 29 december 2020

The 12 stages of learning Clojure

In 2020, I've been on quite a learning journey. I joined a team where we write code in Clojure, a very different language from what I’m used to. It turns out writing Clojure is a very nice developer experience, but it could take a while to get it.

You might have to go through some (or all) of the 12 stages of learning Clojure.

1. "I have no idea what I'm looking at."

2. "Where does that code end? Where does it begin? Why are there so many parentheses?"

3. "I'm totally lost."

4. "Will I ever learn? Am I smart enough?"

5. "I will never learn. I'm not smart enough. I want ice cream!"

6. "Hmmm, wait a minute ... map, reduce, filter. This is something I recognize."

7. "Yes. Clojure, yes, yes."

8. "OMG, this language is so powerful. OMG, I even understand some of it."

9. "defn, keywords, multi-methods, macros, juxt, slurp, ha ha ha ha ..."

10. "Pretty clean. Yeah, I've learned the keyboard shortcut to nicely format the code. And threading macros are nice!"

11. "I ❤️ Clojure. Everything about it makes sense. It's is the language I've been searching for all my life."

12. "Empty your mind, be formless, shapeless - like water. Now you put water into a cup, it becomes the cup. You put water into a bottle, it becomes the bottle. You put it in a teapot, it becomes the teapot. Water can flow, or it can crash. Be water, my friend." *

You might wonder what stage I'm currently in. Well, probably somewhere between 🙂 and 😀.

Here's some of the sources that I have learned a lot from:

I'm sure I will keep trying, failing, learning and mostly smiling in 2021 ✨

* Yes, Bruce Lee said that.

måndag 28 december 2020

The ZooKeeper's New Year's Resolution

(... will probably not be lose weight. Because it has already been fulfilled)

What happened during 2020?

The Node.js ZooKeeper Client - simply called zookeeper - have been released 5 times and the current version is now 4.7.1.

🎉 Packaging

The source code is packaged differently, making the footprint a lot smaller and the install process simplified. To summarize: the ZooKeeper lost weight.

🎉 Prebuilds make the install process really, really fast

The install process is faster than ever. If you are a Mac OS X or Windows user, there is no longer any need to build an AddOn during the install process. Everything is already included in the package, thanks to a cool tool called prebuildify. Linux user? Don't worry, the installer will quickly build a Native Node.js AddOn for the Linux flavor you are running. During 2021 we will probably include prebuilds for the most common Linux flavors.

🎉 TypeScript

TypeScript declarations makes the Developer Experience very nice. With type hints, function parameter docs and autocomplete.

🎉 async zookeeper

Promise based functions are the default.
await client.create(path, data, constants.ZOO_EPHEMERAL);

🎉 Same client for all platforms

The same version of the C Client source code is now used in Linux, Mac OS X and Windows 10 to build a Node.js native AddOn. Before that, there was an issue with Windows clients connecting to a ZooKeeper server v3.4.8 that made us add a workaround - reverting to a really old client version for Windows users. But that is now solved and all platforms share the same set of modern features. Yay!

🚀 What's next?

Adding support for the new node types introduced in Apache ZooKeeper server v3.5.5:
Container and TTL. The features will probably be released during January 2021.

🎉 Happy New Year! 🎉

söndag 3 maj 2020

Developers and their text editors

Developers and their text editors

The text editor, or IDE, is probably the developers' best friend. Is the editor almost like a ... family member? You spend a lot of time with your text editor: writing, navigating and reading code. Just like a family member, a text editor can be a source of inspiration, annoying, joyful, difficult to figure out and probably something you will need a break from at times.

For a couple of months, I've been on quite a learning journey. I have joined a team where we write code in Clojure, a radically different language from what I’m used to. I also decided to try out a new editor: Emacs, radically different from tools that I am used to.

I still struggle with the context switch of copying some text from a browser (using the well known key combinations ⌘+c and ⌘+v) - to copy-paste in Emacs, using the Kill-ring-save (M-w) and Yank commands (C-y).

So why did I choose Emacs?
It is in fact a very good Clojure editor. There's a lot of really nice plugins and features for writing Clojure and ClojureScript. Also, compared to programming languages like Python or JavaScript, it seems there aren’t that many tools out there designed for Clojure development. Once you have the features and key combinations in place, Emacs is a very nice developer experience.

Clojure is a very nice developer experience. 💫

It turns out that Emacs also is really good for writing Python and JavaScript. I guess you could use Emacs for anything text based, but I'm not there yet.

Here's my current Clojure, Python and JavaScript friendly Emacs configuration that will probably be updated continuously as I learn more, and how to replace annoying text editor defaults.