webcodr

Micro DSLs for builders with Kotlin

The builder pattern is a great tool and it’s heavily used in many Java projects and dependencies. But in a Kotlin code base it’s looks a little odd and out-of-date. In this short post I will show you how to write a micro DSL on top of builder with just a few lines of code.

I’m using Spring’s ResponseCookie class as base for the DSL as it has a builder already on-board.

A little example:

val cookie = ResponseCookie
    .from("cookie name", "cookie value")
    .httpOnly(true)
    .path("/")
    .build()

How would this look like with a micro DSL?

val cookie = createCookie("cookie name", "cookie value") {
    httpOnly(true)
    path("/")
}

Instead of calling the static method ResponseCookie.from() which returns a ResponseCookieBuilder object, you just give the function three parameters: two strings for name and value, and trailing lambda with the builder context. There is also no need to call ResponseCookieBuilder.build() anymore. It’s shorter and better to read. Since this is only a small example the advantages are not that big. Micro DSLs really shine with large and often used builders. They can also help to automate things, see below.

How?

fun createCookie(
    name: String, 
    value: String, 
    lambda: ResponseCookieBuilder.() -> Unit
) = ResponseCookie.from(name, value).apply(lambda).build()

Et voila, a new micro DSL is born. Deriving the trailing lambda function from ResponseCookieBuilder does the trick. The lambda function takes an instance of ResponseCookieBuilder as context of this, so it’s possible to access the methods of the given ResponseCookieBuilder inside the lambda function. All we have to do is to create an instance of ResponseCookieBuilder with ResponseCookie.from() and call Kotlin’s apply method on the builder object with the lambda function. It will automatically inject the current instance of ResponseCookieBuilder into the lambda function and apply the instructions inside the lambda function on the instance. To create a ResponseCookie object from the builder, just call the build method and return the result.

You can use this little trick with all builders. Need more automation? No problem! In my current project we’re using such micro DSLs to create product configurations. The factory method contains sanity checks after the lambda function was applied to the builder object. It will also fetch a YAML file via the product ID given to the builder. This data is parsed into an object and will be put into a property of the builder object. After the configuration object is created, the factory method will add to a map and return the instance to store in a variable. It’s now possible to directly access the configuration via its variable name or to fetch it from the map. The variable is very useful for tests, but if we have to fetch the configuration dynamically by ID from a string, the map is the way to go.

Of course there are other ways of achieving such automation, but the micro DSL approach is simple, improves readability and can also reduce redundant code. You can even easily nest builders to create a more powerful DSL. Spring’s Kotlin extensions also rely on micro DSLs and extension functions. Take Spring Security for example. Their fluent interface for the security configuration is awful to read and difficult to understand, but Spring also provides a Kotlin extension with a micro DSL for that. So much more intuitive and better to read. There are many more extensions like for bean creation, the MVC mock in tests etc.

US International Keyboard Layout Without Dead Keys

Depending on your country’s keyboard layout writing code can be quite annoying. The German ISO layout is an exceptional pain in the ass, as almost all relevant symbols require a modifier key, sometimes even two (I’m looking at you, Apple). German has some special characters (ä. ö, ü, ß) and it makes sense to have them readily available without modifier keys, but it just sucks for programming.

I decided to switch to the US ANSI layout and bought two new keyboards: a Keychron K3 Pro for my MacBook Pro (light and portable, perfect if I have to go to my company’s office) and Keychron Q1 version 2 for my Windows PC. By the way, the Q1 is heavily modded and will be tweaked further in the coming weeks. I will write an article about the mods after the keyboard is finished.

Both keyboards work great, but to type German special characters I have to use the US international layout on Windows and there’s a catch. Who would have thought, if Microsoft is involved? Certain keys like single quote/double quote or accents/tilde are so called dead keys.

If you press them, nothing will happen at first. Only after pressing the next key, the symbol will appear. So, if you want to type a text wrapped in double quotes, you press the the key and the double quote will appear, as soon as you type the first character of the actual text. It’s annoying as fuck and drives me crazy.

Solution

Unfortunately Microsoft does not ship an US international layout without dead keys for Windows. Most Linux distributions do exactly that, but I guess that’s to easy for a big international corporation like Microsoft.

What to do? After a little bit of googling, I found a neat little tool, the Microsoft Keyboard Layout Creator. I’ve never heard of this program before but it’s legit and works fine.

If you’re having trouble with the dead keys like me, I recommend the following steps:

  1. Download the Microsoft Keyboard Layout Creator from Microsoft’s website
  2. Open it and load the US international layout via File -> Load Existing Keyboard...
  3. All dead keys are shown with a light grey background. You can remove their dead key status via the context menu
  4. Don’t forget to activate the shift layer via the checkboxes left of the keyboard layout and disable the dead keys as well
  5. Save your config
  6. Build the layout via Project -> Build DLL and Setup Package
  7. After the build finished, a dialog will ask you to open the build directory. Open it and run setup.exe to install the new layout
  8. Restart Windows. This should not be necessary, but unfortunately Windows is Windows …
  9. Go to Settings -> Time and Language -> Language and Region
  10. Select your preferred language and click the three dots and choose Language options
  11. Use Add a keyboard and select United States International - No Dead Keys
  12. I recommend to remove all other keyboard layouts, so they can’t interfere

Now you should have a working US international layout without those annoying dead keys. Happy typing!

Introducing Server Runner

In my recent adventures with Rust, I planned to write a REST API with the help of the excellent book “Zero To Production In Rest” from Luca Palmieri. That’s still happing, but as small side project, I wanted to write some kind of CLI tool.

A few weeks ago I had wrote a bash script to run some web servers and check their status until they’re up and running. When all servers are ready, a command would be executed and all servers would be closed after this command is finished. Since I hate bash with passion, I asked an friend to help me: ChatGPT.

I would never trust an AI in this day and age to write a code base for me, but for small scripts? Why not. As long as the scope is small and I can understand the code, ChatGPT is a really good tool. That script does exactly what I want and it’s easy enough to understand, even for me as a bash hater.

But I wanted to this properly and so I decided to rewrite this script as a small CLI tool program in Rust: Server Runner. Well, not very creative name, but it does what is says.

Configuration

Server Runner is quite simple and just needs a small YAML file as configuration. Here’s a small example.

servers:
  - name: "Hello World"
    url: "http://localhost:3000"
    command: "node index.js"
command: "node sleep.js"

To start server runner, just run:

server-runner -c servers.yaml

Server Runner will execute all server commands defined in the config section servers and waits until the URLs return HTTP 200. When all servers are up and running, the primary command will be started. After the command finished, all server processes will be killed off.

How do I get it?

Server Runner is available as a Cargo Crate and will be published soon on NPM with executables for macOS (aarch64, x86_64), Linux (aarch64, x86_86) and Windows (x86_64).

Installation via Cargo

cargo add server-runner

The source code is available on GitHub.

Terminal evolved

I always saw myself as a casual user of the terminal. I preferred zsh with the Prezto framework within in iTerm 2 with tabs and that’s about it. No more! A colleague of mine introduced me to kitty as terminal emulator, together with tmux and Neovim. That’s a lot to swallow. I was never a fan of the vi/vim user experience and more of a mouse guy. Well, what should I say? It’s awesome if you’re getting used to it. Let me explain …

JFYI

kitty, tmux and nvim are available in Homebrew on macOS and should be also available in your favorite package manager on Linux.

Be aware, that most examples contain some macOS-specific settings marked with corresponding comments, as I am a Mac user.

kitty

iTerm 2 is a pretty good terminal emulator with many features and way better than Apple’s sorry excuse of a terminal. To be fair, the macOS terminal app has gotten better over the years, but it still lacks essntial features like true color support. As good as iTerm 2 is, there’s one catch: iTerm 2 is slow. GPU-accelerated alternatives like kitty render much faster. Don’t get me wrong, iTerm 2 is no slouch and works well, but if you’re on the way to a terminal power-user, you will notice it. Switching between tmux windows is much faster in kitty or other terminal emulators like Alacritty. The later is really nice app, but unfortunately has some trouble with macOS key bindings within tmux and I found no easy solution to that. Kitty works out of the box.

Taming the kitten

Kitty’s configuration is very well documented, but can be overwhelming. There are hundreds of options to explore. One of the most important is the font. Grab yourself a nerd-font, add it to your OS and specify the font family. I’m using “Hack Nerd Font Mono” for this example. Just open your kitty config in ~/.config/kitty/kitty.conf and add the following:

# Replace with your preferred font
font_family			Hack Nerd Font Mono 
bold_font			auto
italic_font			auto
bold_italic_font	auto
# Replace with your preferred font size in points
font_size			17.0 

Save and reload the config via menu bar. Enjoy!

Now that’s out of the way, how about some comfort features?

# Set how many lines the buffer can scroll back
scrollback_lines 10000 

# Auto-detect URLs
detect_url yes
# Open URLs with ctrl + click
mouse_map ctrl+left press ungrabbed,grabbed mouse_click_url 

# Copy the mouse selection directly to the clipboard
copy_on_select yes 
# Paste on right click
mouse_map right press grabbed,ungrabbed no-op
mouse_map right click grabbed,ungrabbed paste_from_clipboard

# Enable macOS copy & paste via CMD + c/v
map cmd+c copy_to_clipboard
map cmd+v paste_from_clipboard

# Jump to beginning and end of a word with alt and arrow keys (macOS)
map alt+left send_text all \x1b\x62
map alt+right send_text all \x1b\x66

# Jump to beginning and end of a line with cmd and arrow keys (macOS)
map cmd+left send_text all \x01
map cmd+right send_text all \x05

# Nicer titlebar on macOS
macos_titlebar_color background

# Make vim the default editor for the kitty config
editor vim

Want some color? No problem, there are hundreds of themes available just a Google search away. I prefer Catppuccin Macchiato, but choose what ever you want. kitty config files support includes, so it’s easy to add a theme:

include ./theme.conf

Add put the file theme.conf in the same directory as the kitty config and paste your theme of choice into the file.

tmux

So, what the hell is tmux? If you need a terminal, tmux will be one of your best friends. Did you ever run something complex on the shell and accidently closed the terminal window or something similar happened during a SSH session? It sucks.

tmux sessions to the rescue! A session will be open until you close it, so even if your internet connection breaks down during a SSH session, nothing will vanish. Just connect to the server again and re-join the tmux session. Everything will be as you left it.

Just type tmux new or if you want to give the session a name tmux new -s my_new_session . Of course tmux can handle multiple sessions. To list all open sessions use tmux ls and to join a session type tmux a -t session_name .

After opening a new session, tmux will display window 0. Need more windows? No problem. Need a window inside an window? No problem, they are called panes. Windows can be split in horizontal or vertical panes, as many and wild as you like.

Inside a tmux session you can trigger commands via a so-called prefix key following one or more keys to tell tmux what you want to do. The default prefix key is ctrl + b . To split your current window into two horizontal panes press ctrl + b followed by % , for a vertical split use ctrl + b and ".

To close a pane, just exit the shell of the pane with exit. You can switch panes with ctrl + b followed by an arrow key in the corresponding direction.

Our new best friend ctrl + b is not the most intuitive key combination. I recommend using ctrl + a and map the caps lock key to ctrl (pro-tip: macOS can do this for you without tools or customizable keyboard firmware). It’s way faster and easier to press. Of course, you can map what ever key combination you, just beware of conflicts with other combinations like cmd + space.

To change the command key, go to your tmux config in ~/.tmux.conf and add the following lines:

unbind C-b
set -g prefix C-a
bind-key C-a send-prefix

This unbinds ctrl + b and sets the prefix key to ctrl + a. To reload the tmux config inside a session use tmux source-file ~/.tmux.conf.

More? More!

There is much more you can do. Here are some recommendations.

# Enable mouse support
set -g mouse on

# Set history limit to 100,000 lines
set-option -g history-limit 100000

# Enable true color support
set-option -sa terminal-overrides ",xterm*:Tc"

# Start windows and panes at 1, not 0
set -g base-index 1
set -g pane-base-index 1
set-window-option -g pane-base-index 1
set-option -g renumber-windows on

# Open new panes in the same directory as their parent pane
bind '"' split-window -v -c "#{pane_current_path}"
bind % split-window -h -c "#{pane_current_path}"

# Vim style pane selection
bind h select-pane -L
bind j select-pane -D 
bind k select-pane -U
bind l select-pane -R

# Shift arrow to switch windows
bind -n S-Left  previous-window
bind -n S-Right next-window

# Don't scroll down on copy via mouse
unbind -T copy-mode-vi MouseDragEnd1Pane

With mouse support you can resize panes with drag & drop and even get a context menu with a right click. By default tmux assigns numbers to windows for fast switching via ctrl + b and number key. Unfortunately the developers decided to begin with 0. This is technically correct, but on the keyboard it’s quite unintuitive, so we can tell tmux to begin with 1. The rest is pretty much self-explanatory.

Neovim

Why neo? Good old vim is extensible via vimscript. It works, but it’s like bash: ugly as fuck. Neovim is a fork of vim and replaces vimscript with support for lua-based extensions. So it’s still blazingly fast(tm) and much nicer to write extensions.

You could setup Neovim and the necessary extensions yourself, but won’t recommend it in the beginning. Pre-build configs like AstroNvim or NvChad will massively speed up the process and have great defaults. It can be very overwhelming to get used to vim/nvim, so I would recommend to wait with your own config until you get more familiar with a keyboard-based editor.

HELP! I can’t quit vim!

Don’t worry, you are not the first and will certainly not be the last. vim is a so-called modal-based editor. It has different modes like command, insert, visual etc. As you may have noticed, typing will not add text to the buffer. You need to press certain keys like i to enter insert mode to edit text. There are other keys to go in insert mode and everyone of them has slightly different, but pretty useful function, like o which creates a new line below the cursor and starts insert mode.

To exit vim you to leave the insert mode by pressing esc. Now you are in command mode and can quit by typing : to enter the command line mode and hit q for quit, followed by enter to execute the command.

If you want to save a file, enter command line mode and use w for write. It’s possible to chain certain commands. wq will save the file and quit vim.

Congratulations, you now know how to exit vim!

To move the cursor just use the arrow keys in most other editors. But there is more efficient key mapping in command mode: h (left), j (down), k (up) and l (right). No need to move your to the arrow keys anymore. To be honest, I’m still not comfortable with this way of navigation, but it’s objectively more efficient than moving the right hand to the arrow keys.

Of course vim has way more navigation possibilities. For example, the cursor can jump forward by one word with w and backwards with b. Press $ to jump to the end of the current line or 0 to beginning. G navigates you to last line and gg jumps to the first line. And there is so much more to explore. I recommend a decent vim cheat sheet to learn. But do yourself a favor and try not learn all keys at once. You will only become frustrated and give up more easily, it’s just too much to learn everything in the beginning.

Netflix developer and Twitch Streamer ThePrimagen designed a Neovim plug-in to learn the navigation commands as game. it’s pretty good and fun: https://github.com/ThePrimeagen/vim-be-good

AstroNvim has many plug-in out of the box. Syntax highlighting, linting, auto-formatting etc. are all there, but you need to install the corresponding servers, parsers etc.

To do this, enter command line mode and use LspInstall followed by the language name for installing a language server protocol. A language server for Tree-Sitter can be installed with TSInstall followed by the language name. If there nothing available, both commands will recommend plug-ins according to your input, if available.

Be aware, that LSPs and Tree-Sitter will not bring the necessary tools with them. If you install tooling for Rust, rust-analyzer has to be installed on the system. Same goes for ESlint, Prettier, Kotlin, Java etc.

The End

… for now

That was a lot unpack, but there is so much more to show to you. I will be back with more productivity tools and tips in the near future. Stay tuned!

Real-world performance of the Apple M1 in software development

There are enough videos on YouTube out there to show how awesome the new Macs are, but I want to share my perspective as a software developer.

About six weeks ago, I was too hyped not to buy an ARM-based Mac, so I ordered a basic MacBook Air with 8 GB RAM (16 GB was hard to get at this time). As strange as it sounds, I don’t regret buying only 8 GB of RAM. On an Intel-based Mac this would be an absolute pain in the ass, even my old 15” MacBook Pro Late 2017 with 16 GB struggles sometimes with RAM usage.

It’s really amazing how good this small, passively cooled MacBook Air is keeping up. In many scenarios it even surpasses my MacBook Pro with ease. I never had an Intel-based MacBook Air, but the last time is used a dual-core CPU for development, was not pretty und that was a pretty decent i5 and not a ultra-low voltage i3.

Speed, Speed, Speed

Unfortunately I couldn’t really develop software on the MacBook Air for a while, since Java and IntelliJ were not available for aarch64-based Macs. Of course I tried Rosetta 2, but at least for these two, it’s quite slow. NodeJS on the other hand is incredibly fast.

All this changed after my christmas vacation. IntelliJ was updated and thankfully Azul released a JDK 8 for ARM-Macs. A native version of Visual Studio Code is also available and quite fast.

So, no more introductions, here are some real-world scenarios and numbers.

I currently work on a Java project with a steadily growing codebase of Kotlin. It’s a little special, since another part of the application is written in Ruby. We’re using JRuby, so it’s bundled all together with a Vue-based frontend in a WAR-File with Maven.

Maven Build Times

All build times are from fully cached dependencies, so there are no interferences from my internet connection.

Used devices:

  • 15” MacBook Pro Late 2017: Intel Core-i7 7700HQ, 16 GB RAM
  • 13” MacBook Air Late 2020: Apple M1, 8 GB RAM
  • PC: AMD Ryzen 9 3950X, 32 GB RAM
DeviceBuild time with testsBuild time without tests
MacBook Pro223 s183 s
MacBook Air85 s63 s
PC84 s66 s

Well, a small, passively cooled MacBook Air is as fast as a full-blown and custom water-cooled 16-core monster of a PC. The MacBook Pro gets utterly destroyed. To get this straight: the cheapest notebook Apple makes, destroys a MacBook Pro that costs more than twice as much.

Ruby Unit Test Times

The test suite contains 1,087 examples. Please keep in mind, that I had to use Rosetta 2 in order to get everything running on the MacBook Air, since not all used Ruby Gems are compatible with ARM at this time. All tests were run with Ruby 2.7.1.

DeviceTest duration
MacBook Pro native1.9 s
MacBook Air with Rosetta 21.1 s
PC native1.3 s

Yeah, it’s quite fast, compared to a Suite of Java-based unit tests, but even here the MacBook Pro has no chance at all.

Frontend Build Times

The frontend is a Vue-based single-page application. As with Ruby, I had to use NodeJS with Rosetta 2, since not all used modules are compatible with ARM.

DeviceTest duration
MacBook Pro native27.8 s
MacBook Air with Rosetta 220.7 s
PC native20.6 s

Well, it’s more than obvious now, that the MacBook Pro has no chance at all against my MacBook Air. It’s not just the performance. After a few seconds of load, the MacBook Pro sounds like my F/A-18C in DCS immediately before a carrier launch, while the MacBook Air has no fan and therefore makes no noise at all.

And the battery life. Oh my god. Ten straight hours of development with IntelliJ and Visual Studio Code is entirely possible now, all while staying cool and quiet.

Even the dreaded battery murderer Google Meet is no problem anymore. My MacBook Pro on battery would last perhaps 2.5h max. The MacBook Air is capable of 8, perhaps even 9 hours of Meet. It’s as insane as an 8h long Meet itself.

Ah, yes, there is another thing: Meet does not cripple the performance anymore. The MacBook Air is totally usable with a Meet going on, while my MacBook Pro becomes sluggish as hell and is barely usable (even without Chrome and frakking Google Keystone).

Conclusion

I will make it short: if your tools and languages are already supported or at least quite usable with Rosetta, go for it. I would recommend 16 GB or more (depending on future models), if you want to buy one. I’m surprised that a 8 GB MacBook Air is that capable and to be honest, I don’t feel like there a going to be a problem for a while, but no one regrets more RAM …

Air vs Pro

The 13” MacBook Pro is little faster over longer periods of load due to active cooling, it has more GPU-cores, the love or hated Touch Bar and a bigger battery. If you need this, go for it, but if you can wait, I’d recommend to wait for the new 14” and 16” Pro models.

They will be real power houses with 8 instead of 4 Firestorm cores, vastly more RAM and even bigger batteries. And hey, perhaps they come with MagSafe and some other ports we MacBook users didn’t see for a while.