Nothing big, just a tiny program written in Go to decode a JWT with go-jose and print the JSON contents to the console. I wanted a short name. JWT decode or jwtd. No fancy name, just a useful tool.

A friend asked if it could verify signatures or decrypt JWE contents. Nope, but that was a perfect opportunity to try Opus 4.6 which was pretty new at the time.

Many iterations and tokens later, the jwtd can do much more. Yes, it’s mostly written by AI agents, but it’s still small enough to understand what’s going on and there’s a pretty large test suite to ensure quality. I use multiple models and regularly check if something can be improved, make security audits etc. – I will not ship a program I can’t understand or I feel insecure about.

What?

The main focus is still decoding JWTs and showing the contents. Of course with colored output and human-readable timestamps (an expiration warning for exp fields is coming soon). We support a wide variety of JWS signatures, JWE key types and JWE content encryption algorithms.

There’s an interactive mode for tokens and keys, so you don’t have to clean up your history afterwards. You can also pipe a token into jwtd if you like. We’re also accepting keys via environment variable and even support raw HMAC secrets.

Where?

All major operating systems are supported, but to be honest, my main focus is macOS and Linux. You can get jwtd via Homebrew, the AUR, Fedora COPR, Nix and Scoop. WinGET is coming soon. There are also pre-built deb and rpm packages available on GitHub.

How?

To decode a token just supply it as argument:

$ jwtd eyJhbGciOiJSUzI1NiIs...

Header:
{
  "alg": "RS256",
  "typ": "JWT"
}

Payload:
{
  "sub": "user_2048",
  "admin": true,
  "iat": "2026-07-22T03:00:00Z (1784689200)",
  "exp": "2026-07-22T04:00:00Z (1784692800)",
  "note": null
}

Signature: eyJfX2p3dGRfXyI...

Need to verify a JWS signature?

jwtd --key /path/to/public-key.pem eyJhbGciOiJSUzI1NiIs...

For decryption just use the private key instead of the public key.

Don’t want to pass the key path as parameter? No problem, just use the environment variable JWTD_KEY.

To use the interactive mode just omit the token or the value of the key parameter.

That’s just a small overview, you can find a full usage guide, every installation option and more on the official website jwtd.sh or on GitHub.

It’s a TUI written in Rust and uses similar or the same libraries as rg, fd, fzf and bat, but in one package. There are no external dependencies and it comes for macOS, Linux and Windows in aarch64 and x86-64.

Currently srchr is not available via package managers, but there’s an installation script:

curl -fsSL https://raw.githubusercontent.com/webcodr/srchr/main/install.sh | sh

I will also publish srchr on Homebrew, the AUR and perhaps some other package managers.

Beware, it’s still under development and the UI is functional, but not finished yet. At the moment there is just a hardcoded Tokyo Night inspired color theme, but this will also change in the near future.

srchr on GitHub

Update

It’s now available on Homebrew for macOS and Linux!

brew install webcodr/tap/srchr

I don’t know that stuff?

First things first. If you already know fd or the other tools from above, feel free to skip this section.

• fd is a more user-friendly replacement for find
• rg or ripgrep is grep on steroids, respecting git ignore files and skipping binaries or hidden files
• fzf is a command-line fuzzy finder. You basically can pipe everything into fzf and just type to filter the output
• bat is a modern version of cat with syntax highlighting and git integration

Say hi to rgp and fdp

function rgp
    set -l search_term $argv[1]

    if test -z "$search_term"
        echo "Usage: rgp <search_term>"

        return 1
    end

    rg -l $search_term | fzf --preview 'bat --color always {}' --bind 'enter:become("$EDITOR" {+})'
end

function fdp
    set -l search_term $argv[1]

    if test -z "$search_term"
        echo "Usage: fdp <search_term>"

        return 1
    end

    fd -tf $search_term | fzf --preview 'bat --color always {}' --bind 'enter:become("$EDITOR" {+})'
end

That’s all you need. Put them into your fish config file or the fish functions folder.

Usage

rgp something – this will use rg to recursively search the current directory for files with something inside. The result is piped into fzf. You can now filter the result further with fzf or select a file with the arrow keys and bat will give you a live preview of the file with syntax highlighting. Pressing enter will open the selected file with your default editor (environment variable EDITOR).

fdp works similarly, but looks for file names instead of the file content and also pipes the result to fzf for further filtering, preview or opening the selected file.

Don’t like fish? Here’s a version that works with bash or zsh.

Note: the local keyword is not POSIX-compliant. If you need that, just remove it, but this makes search_term global, so use with care.

rgp() {
    local search_term=$1

    if [ -z "$search_term" ]; then
        echo "Usage: rgp <search_term>"
        
        return 1
    fi

    rg -l "$search_term" | fzf --preview 'bat --color always {}' --bind 'enter:become("$EDITOR" {+})'
}

fdp() {
    local search_term=$1

    if [ -z "$search_term" ]; then
        echo "Usage: fdp <search_term>"
        
        return 1
    fi

    fd -tf "$search_term" | fzf --preview 'bat --color always {}' --bind 'enter:become("$EDITOR" {+})'
}

btop

It’s top on steroids with a beautiful terminal UI. Way more information at a glance and just a joy to use.

delta

Do you often look at git diffs? Are you missing syntax highlighting? delta is here to help. Just install it, configure delta as pager for git and voila, diffs with syntax highlighting.

dog

Dog is a modern DNS lookup tool with colored output and a simple interface.

tokei

Are you a fan of statistics? Tokei can summarize file types, lines of code, comments or blank spaces of your project.

I’m currently converting a large Java project to Kotlin and tokei makes it easy to see the progress.

procs

A modern replacement for ps with colored output, keyword search, tree view and some useful helpers for networking (ports) and Docker.

lazygit

One of my favorites. Lazygit is a dead simple, yet powerful and elegant to use terminal UI for git. I’m not a fan of the git CLI and always preferred a GUI tool like Tower, but nowadays lazygit is my git client of choice. I don’t think there is a better git client out there. Even many NeoVim distributions support it out-of-the-box (LazyVim with LEADER + gg).

sd

Do you use sed? Do you like it? I don’t. sd is better, much better.

atuin

Atuin is a history replacement with a fuzzy finding search and sync/backup options (self-hosted if you need). It’s written in Rust (blazingly fast!) and stores the history entries in a SQLite db. You can even import your current history from your shell. Atuin supports bash, zsh, fish and NuShell.

bat

Need cat a lot? Bat is a cat clone on steroids with syntax highlighting, themes, git integration and much more.

eza

Everyone needs ls ? Nope, eza is much better. Colored output, icons via nerd fonts, git status tracking per file, tons of display options …

tldr

Reading a man page can be frustrating, why can’t I just have the TL;DR version? Well, tldr does exactly that. Just use it like man and enjoy the TL;DR version of a man page.

zoxide

Like its siblings, cd is a little dated and clunky. With zoxide you can easily jump to directories without typing the full path. It stores a history of your visited paths and you can jump via keywords to your directories.

chezmoi

You’re using multiple computers or just want a simple and reliable way to store your dot files? Chezmoi is your friend and stores your dot files in a git repo with syncing capabilities to other devices. It’s even possible to encrypt your files. If you have secrets in your dot files, chezmoi comes with integrations for many password managers to safely store your passwords, tokens etc.

starship

Your shell looks boring? Just theme it with starship! It’s pretty easy to build your own and if you don’t want to, there are many themes available. Starship also has integrations for many dev tools to show the current git status or currently active versions of your runtime environments like NodeJS, Rust, Go, Java etc.

fzf

Finding files with the usual suspects works fine, but fzf can do this faster and much more intuitive. It’s a fuzzy finding search within your current directory, processes, git commits, history (if you don’t like Atuin) and much more.

ripgrep

Ripgrep is a really fast regex-based search tool and can do much more than grep alone.

btop

Another top variant? Yup, but btop is way more like its modern GUI-based colleagues on macOS or Windows with CPU and GPU usage, process trees, I/O and disk activities, battery status …

A few weeks ago I 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 a passion, I asked a 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 do this properly and so I decided to rewrite this script as a small CLI tool program in Rust: Server Runner. Well, not a very creative name, but it does what it 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_64) and Windows (x86_64).

Installation via Cargo

cargo add server-runner

The source code is available on GitHub.

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 essential 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 latter is a 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

And 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 accidentally closed the terminal window or something similar happened during an 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 an 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 a 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 whatever key combination you want, 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 I won’t recommend it in the beginning. Pre-built 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 every one of them has a slightly different, but pretty useful function, like o which creates a new line below the cursor and starts insert mode.

To exit vim you have 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!

Navigation

To move the cursor you would just use the arrow keys in most other editors. But there is a more efficient key mapping in command mode: h (left), j (down), k (up) and l (right). No need to move your hand 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 the beginning. G navigates you to the 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 to 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 ThePrimeagen designed a Neovim plug-in to learn the navigation commands as a game. It’s pretty good and fun: https://github.com/ThePrimeagen/vim-be-good

AstroNvim has many plug-ins 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’s 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 to unpack, but there is so much more to show you. I will be back with more productivity tools and tips in the near future. Stay tuned!

It was quite simple and effective, but lacks comfort and does not work on iOS/iPadOS devices. After buying a new iPad Air and Magic Keyboard, I wanted a pragmatic way to write posts without my MacBook or PC.

I always wanted to try Netlify CMS, so this was my chance. The transition was really simple. I followed the guide for Hugo-based sites and adjusted the config to work with Hugo. That’s it. Netlify CMS works just fine with the already existing markdown files. Even custom frontmatter fields within the markdown files are no problem, just set them up in the config file.

A little more configuration in the Netlify admin panel is necessary, but the guide explains everything very well. It was just a matter of 15 minutes to get everything going.

If you use a static site generator and want to have a little more comfort, Netlify CMS makes it really simple. They provide guides for every major player like Gatsby, Jekyll or Nuxt and of course Hugo. You don’t even have to use GitHub. GitLab and BitBucket are supported as well. As are more complex workflows for more than one editor, custom authentication with OAuth or custom media libraries.

Editor

Netlify CMS supports markdown and has a basic, but decent editor with rich-text mode. But I wanted a little bit more, so I decided to write my posts in Ulysses — a specialized writing app with support of GitHub-flavored markdown, including syntax highlighting preview. It’s available for macOS and iOS/iPadOS. All files and settings are synched via iCloud. So, once you have setup everything, you’re good to go on any of your Apple devices.

Since Ulysses requires a subscription, I will use this to „force“ me writing more posts. 😁

I wrote this post entirely on my iPad Air and so far, I’m quite happy with the new workflow. Of course I will not write every post this way. New posts with code examples will be easier to handle on a Mac or PC. (Hey Apple, how about IntelliJ on an iPad?)

btw: even as an enthusiast of mechanical keyboards I have to say, it’s quite nice to type on a Magic Keyboard. I just have to get used to the smaller size. The Magic Keyboard for the 10.9“ iPad Air or 11“ iPad Pro is a compromise in size and some keys like tab, shift, backspace, enter and the umlaut keys (bracket keys on English keyboard layouts) are way smaller compared to normal-sized keyboards. Its bigger brother for the 13“ iPad Pro has a normal layout, but that monster of an iPad seems a bit excessive for my use case.

Actually I wanted to use Kotlin for a while now, but there were only minor tasks within the Java part of the project. That finally changed and we can focus to improve the Java backend drastically.

Part of this process was a library update. We decided to upgrade JUnit from 4 to 5. A big pain in the ass. I don’t think, I would do it again. JUnit 5 was also part of a bigger problem, even if it was actually PEBKAC.

Kotest and MockK features

If you already know about Kotest or want to know more about the problem I had, just skip to the next headline. The Kotest introduction is a little bit longer.

As I dived more and more into Kotlin, I stumbled over Kotest. A really neat testing framework for Kotlin. There’s nothing wrong with JUnit, but Kotest gives you way more awesome ways to structure your tests.

A little example:

package io.webcodr.demo

import io.webcodr.demo
import io.kotest.assertions.throwables.shouldThrow
import io.kotest.core.spec.style.FunSpec
import io.mockk.*

class UserServiceTest : FunSpec() {
    private val userRepository = mockk<UserRepository>()
    private val service = UserService(userRepository)
    private lateinit var user: User

    init {
        beforeTest {
            user = User(1, "Jane", "Doe", "jane@doe.com")
        }

        afterTest {
            clearAllMocks()
        }

        context("getUser()") {
            fun verifyRepoCalls() {
                verify {
                    userRepository.findById(1)
                }

                confirmVerified(userRepository)
            }

            test("should succeed") {
                every {
                    userRepository.findById(1)
                } returns user

                service.getUser(1).shouldBe(user)

                verifyRepoCalls()
            }

            test("should fail") {
                every {
                    userRepository.findById(1)
                } throws UserNotFoundException()

                shouldThrow<UserNotFoundException> {
                    service.getUser(1)
                }

                verifyRepoCalls()
            }
        }
    }
}

Kotest offers several different styles to write tests. I chose the FunSpec style for this example. You could also use a BDD-like or Jasmine-like style, if you want to.

It’s much more intuitive to nest tests with Kotest. To be fair, JUnit 5 allows you to use @Nested with an inner class to accomplish nesting as well, but it’s not as intuitive and harder to read than trailing lambdas.

Assertions are also a little easier to write. Kotest has over 100 different matchers. You can use them as extension functions, like in the example above or alternatively as infix functions, for example service.getUser(1) shouldBe user. It’s also quite simple to write custom matchers.

There are many more features like soft assertions, tagging, easy temporary file creation or handling for non-deterministic test cases.

For mocking we decided to use MockK, since it’s way more intuitive to use than Mockito with Kotlin. Don’t get me wrong, Mockito is a great library, but it has one flaw: the when method. when is a keyword in Kotlin and to use it with Mockito, you need to write it in backticks. That’s quite ugly and not intuitive at all.

So, in summary, Kotest offers a bunch of pretty neat features and is very intuitive to use. Of course, JUnit can achieve much of this as well, it’s just not that shiny and little harder to read.

The actual problem or: why the frak is there IntelliJ in the title?

If you migrate an old codebase to Kotlin and want to use Kotest, you will have no choice and have to use JUnit and Kotest in coexistence.

That shouldn’t be a problem, since Kotest uses the JUnit 5 Jupiter engine under the hood. But …

As I wrote a new service in Kotlin and some tests with Kotest, I could not start the JUnit tests anymore. As soon as the maven dependency of Kotest was present, IntelliJ didn’t recognize JUnit tests and used the Kotest files only. With mvn test (Maven Surefire) everything worked fine.

I tried several things and was ready to give up. Search engines didn’t find anything about this problem. Nothing on GitHub, nothing on Stack Overflow.

I hate to give up, so I decided to create a small demo project to open a GitHub issue. Well, that didn’t work out as intended, since the discovery of JUnit tests in the demo project worked fine. The IntelliJ JUnit runner did what it was supposed to: run JUnit and Kotest.

Well, frak. There must be some kind of configuration problem with my real project. I already looked at the IntelliJ runner config, Maven files etc. — nothing worked.

I compared the Maven files from both codebases and there was one difference: my real project did not include the JUnit Jupiter Engine dependency. Bingo. I added it to the Maven file and guess what? It worked like a charm.

What an embarrassment. As we upgraded from JUnit 4 to 5, we forgot to add the new dependency for the engine. I don’t know why the tests worked at all, but it seems the engine is not really necessary for all cases. But it can screw up test discovery quite well, if you forget it.

The dependency configuration in the POM file should look like this:

<dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter-api</artifactId>
    <version>${junit.version}</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter-engine</artifactId>
    <version>${junit.version}</version>
    <scope>test</scope>
</dependency>

Well, that was a long post, but IMO it was necessary to show how this problem came to be and even if you have no trouble at all, perhaps you’ll consider using Kotest. It’s awesome!

Gradle

I’m not sure, but this issue could happen with Gradle as well, when you are migrating to JUnit 5.

Extensions

Settings Sync

I love my Mac, but sometimes I have to do stuff (besides gaming) on my Windows PC as well. So, if I want to use the same config on both devices, I have to install my extensions and copy my config back and forth. That sucks. Settings Sync to the rescue! It syncs your settings, extensions etc. through the power of Gists on GitHub.

Download

Bookmarks

It’s quite simple: just bookmark certain lines of code you need often.

Download

EditorConfig for VS Code

Share your coding styles between editors, IDEs etc. on a per project basis. It’s really nice for teams as well.

Download

Bracket Pair Colorizer

Bracket madness? No more!

Update: The extension has been delisted, since VS Code now ships native bracket pair colorization — see the editor.bracketPairColorization.enabled setting.

Markdown All in One

Do you write a lot of Markdown? Here are some really useful helpers.

Download

Themes/Icons

Cobalt2

If you like darker and bluish color themes, give Cobalt2 a try. The color choices with a contrast between yellow and blue can reduce strain on your eyes.

Download

Material Icon Theme

Matches nicely with Cobalt2 or other darker themes. There are a ton of icons for almost any file type and even for many special folders like node_modules etc.

Download

But that’s not the end. VS Code can do much more, you can find some other very useful tips and tricks on vscodecandothat.com (now offline, linked via the Wayback Machine).

Dear GitHub

Look, I want to like Atom, but there are too many caveats. Atom is slow and resource hungry as hell, which is especially bad on a mobile device. It literally eats my MacBook’s battery away. VS Code is not perfect either, but the general experience is much better. So, please, get your shit together and improve Atom. We need more awesome editors on the market!

Wenn sie kaputt ist, wird für ein paar Euro eine neue gekauft und gut ist. Manchmal gibt man auch etwas mehr aus, z.B. für ein Apple Keyboard oder ein besseres Modell von Logitech.

Dabei macht sich aber niemand Gedanken darüber, wie sie eigentlich funktioniert und ob da nicht gerade für uns Vieltipper Verbesserungspotenzial ist.

Die meisten Tastaturen haben eines gemeinsam: sie nutzen die sog. Rubberdome-Technik. Dabei wird beim Tastendruck eine Gumminoppe mit Kontaktpad nach unten auf die Platine gedrückt und so der Anschlag durch den Kontakt ausgelöst. Alle Noppen befinden sich auf einer Gummifolie, die einfach über die Platine gelegt wird. Kabel ans PCB, Tasten drauf, Gehäuse drumrum und fertig ist die Tastatur.

Das ist günstig, aber auch gut? Leider nein. Es gibt zwar durchaus ganz gute Vertreter dieser Gattung, aber die Schwachstellen haben sie alle gemein:

1. Um den Anschlag auszulösen, muss man die Taste vollständig durchdrücken.
2. Der Anschlag ist nicht über alle Tasten konsistent und verändert sich mit der Zeit.
3. Gerade bei den billigen Vertretern, mitunter aber auch bei den teuren ist das Gehäuse nicht verwindungssteif.
4. Geringe Haltbarkeit von max. 5 Millionen Anschlägen.

Die ersten drei Punkte fallen insbesondere für Vieltipper deutlich stärker ins Gewicht, als man meinen möchte. Vollständiges Durchdrücken der Tasten lässt die Hände bzw. Finger schnell ermüden – gleiches gilt, wenn sich die Tastatur beim Tippen verwindet bzw. nach unten verbiegt. Da sich der Anschlag ungleichmäßig über die Zeit und je nach Nutzung der Tasten verändert, kann sich kein Muskelgedächtnis bilden, um schneller tippen zu können.

Und jetzt?

Wie wär’s mit einer Alternative? Mechanische Tastaturen!

Huch? Sind die nicht sauteuer, laut und sperrig? So wie früher diese Totschläger von IBM …

Hach ja, das IBM Model M. Wenn man wollte, könnte man damit wohl wirklich Einbrecher niederschlagen. Zur Selbstverteidigung empfehle ich aber doch eher andere Gerätschaften.

Ein billiges Vergnügen sind mechanische Tastaturen wirklich nicht, aber sie sind es definitiv wert. Hier geht es schließlich um ein Werkzeug. Handwerker geben sich schließlich auch nicht mit einem Consumer-Akkuschrauber für 20 Euro zufrieden. Warum also sollten wir das bei unseren alltäglichen Helfern tun? Ob sie laut und groß sind, hängt dagegen ganz vom jeweiligen Geschmack ab.

Aha, und warum können die Dinger das nun besser?

Um die Kritikpunkte von oben direkt aufzugreifen:

1. Mechanische Schalter müssen nicht vollständig durchgedrückt werden, um einen Anschlag auszulösen – die Hälfte genügt. Die verbreitetsten Schalter (Cherry MX) haben einen Hub von insgesamt 4 mm und lösen darum nach 2 mm aus.
2. Der Anschlag verändert sich weder mit der Zeit noch nutzen sich verschiedene Tasten je nach Gebrauch unterschiedlich ab. So bildet sich mit der Zeit ein Muskelgedächtnis, das schnelleres und komfortableres Schreiben ermöglicht.
3. Bei guten mechanischen Tastaturen sind die Schalter auf einer Stahlplatte angebracht, darunter befindet sich die Platine mit der sie verlötet sind. Da verwindet und verbiegt sich nichts.
4. Mechanische Tastaturen halten Jahrzehnte durch. Die durchschnittliche Lebensdauer von Cherry-Schaltern liegt bei ca. 50 Mio. Anschlägen. Unzerstörbar sind sie aber natürlich nicht.

Je nach Schalter-Typ gibt es auch noch zusätzliche Vor- und Nachteile, so dass man sie ganz nach seinen Präferenzen aussuchen kann.

Schalter-Typen

Ich beschränke mich hierbei auf die gängen Varianten von Cherry, da sie am häufigsten verbaut werden.

• MX blue: löst mit einem Klick-Geräusch aus und hat dazu beim Anschlag einen spürbaren Widerstand. Betätigungskraft: 60 cN
• MX brown: löst ohne Klick aus, besitzt aber den gleichen spürbaren Widerstand beim Anschlag wie der MX blue. Betätigungskraft: 55 cN
• MX black: linearer Schalter, löst beim Anschlag weder einen Klick noch einen Widerstand aus. Betätigungskraft: 60 cN
• MX red: wie MX black, nur mit geringerer Betätigungskraft: 45 cN

Darüber hinaus gibt es noch verschiedene Varianten der MX blue und MX brown mit höherer Betätigungskraft. Man trifft sie allerdings eher selten an, manche davon sind sogar regelrecht rar.

Grundsätzlich gilt es beim Kauf einer Tastatur zuerst den Schalter-Typ zu wählen. Zum Entwickeln oder Schreiben sind die MX blue definitiv die beste Wahl, da sie ein hör- und spürbares Feedback bieten und daher nach der Eingewöhnung, sehr schnelles und flüssiges Tippen ohne Ermüdungserscheinungen ermöglichen.

Nun mag natürlich so manchen das Klicken auf die Palme bringen, andere wiederum können nicht mehr ohne. Wer sich daran stört oder die Kollegen im Büro nicht zum Amoklauf treiben will, aber dennoch spüren möchte, wenn der Anschlag ausgelöst wird, sollte zum MX brown greifen. Er tippt sich ein klein wenig leichter und ist ohne den Klick erheblich leiser.

Findet man dagegen Widerstand zwecklos, sollte man einen Blick auf die MX black oder MX red werfen. Letzterer ist besonders bei Spielern sehr beliebt, da man sehr schnell mehrere Anschläge hintereinander auslösen kann, ohne wie ein Bekloppter auf die Tastatur hämmern zu müssen. Dafür neigt man u.U. eher zu Vertippern.

Grundsätzlich kann man die Schalter in drei Kategorien aufteilen: Profi-Tipper ohne Klick-Allergie, die eher wenig bis gar nicht spielen, werden mit MX blue am glücklichsten. Möchte man dagegen einen guten Allrounder zum Schreiben und Spielen, ist der MX brown das Mittel der Wahl. Wer mehr spielt als Texte tippt, dürfte mit einem MX black oder MX red am besten klarkommen.

Ich empfehle aber jedem, verschiedene Schaltertypen auszuprobieren. Es gibt genug Spieler, die sich nicht am Klicken des MX blue stören und den MX red hassen wie die Pest – und umgekehrt genauso.

Noch etwas zur Lautstärke: man kann auch mit einem nicht klickenden Schalter schön Krach machen, wenn man auf der Tastatur rumhackt wie ein Irrer. Dazu hängt der Geräuschpegel auch von der Konstruktion bzw. dem Gehäuse ab. Dazu später etwas mehr (dasKeyboard Model S vs. dasKeyboard 4 vs. Corsair K70).

Was kostet der Spaß und wo bekomme ich so ein Teil her?

Der Preis der gängigen Modelle liegt zwischen 60 und 200 Euro.

Die definitiv günstigste Wahl gibt’s von Cherry selbst mit dem MX Keyboard 3.0. Zu bekommen bei Amazon oder den gängigen Hardware-Händlern.

Ansonsten ist die Auswahl an Shops eher eingeschränkt. Die EU und insbesondere Deutschland gehören bei mechanischen Tastaturen eher zur dritten Welt.

Die bisher besten Quellen, die ich neben Amazon ausmachen konnte: GetDigital (dasKeyboard, Ducky, Filco, Leopold), CaseKing (Cherry und Ducky), The Keyboard Company UK (primär Filco und deren Zubehör).

Ansonsten stellen diverse bekannte Marken aus dem Spiele-Sektor wie Corsair, Razer, CMstorm, Func und auch Logitech mechanische Tastaturen her, die man auch in gängigen Läden und Shops bekommt.

Für professionelle Anwender rate ich zu Filco, Ducky oder dasKeyboard, da sie qualitativ etwas mehr bieten. Besonders Ducky und Filco bauen regelrechte Panzer. Grundsätzlich kann man mit den anderen aber nicht viel falsch machen. Man sollte aber inzwischen aufpassen, von welchem Hersteller die Switches sind. Da gibt es leider nicht nur Unterschiede in der Schaltcharakteristik, weil inzwischen wegen abgelaufener Patente auch billigere Kopien der MX-Schalter auf dem Markt sind, zu deren Haltbarkeit es noch keine Erfahrungswerte gibt. Die einschlägigen Foren sehen die Sache allerdings weniger gelassen …

Meine Erfahrung

Ich hatte mich im November vergangenen Jahres dazu entschlossen eine mechanische Tastatur auszuprobieren und entschied mich für eine Corsair K70 mit MX brown und blauer Hintergrundbeleuchtung. Die Tastatur hing nur an meinem Windows-Rechner, an dem ich eher wenig schreibe und mehr spiele.

Abgesehen von der Lautstärke durch die offene Konstruktion ohne einen Rahmen, der die Tasten umgibt, war ich mit der K70 sehr zufrieden. Nach einem Tipp im Computerbase-Forum, habe ich Gummi-O-Ringe zwischen die Tasten und Schalter montiert, was die Lautstärke deutlich dämpfte. Allerdings verändern solche Maßnahmen den Anschlag – einfach ausprobieren, die Ringe kann man sehr günstig kaufen.

Für meine Arbeit als Entwickler, die ich ausschließlich am Mac verrichte, habe ich längere Zeit eine geeignete mechanische Tastatur gesucht. Zum Testen entschied ich mich für ein dasKeyboard Model S Professional for Mac mit MX blue. Leider gibt es dieses Modell nur mit ANSI-Layout, was mich anfangs vom Kauf abgehalten hat und mit dem ich schließlich auch nicht zurechtkam. Der ständige Wechsel bringt einen nur durcheinander und das deutsche Tasten-Mapping (ISO-Layout) mit einem ANSI-Layout zu nutzen klappt auch nicht – da fehlt schließlich eine Taste.

Die MX blue dagegen haben mich auf Anhieb begeistert. Kurzum: ich habe die Tastatur gegen ein dasKeyboard 4 mit MX blue umgetauscht. Die hat zwar kein Mac-Layout, aber das lässt sich durch den Tausch der Tastenkappen und ein paar Einstellungen in OS X problemlos anpassen. Außerdem funktionieren die Media-Tasten und selbst der Lautstärkeregler ohne jegliche Anpassung mit OS X. Wozu da also noch ein spezielles Mac-Modell?

Parallel ließ mich leider die K70 im Stich. Innerhalb eines halben Jahres gingen drei LEDs der Hintergrundbeleuchtung kaputt. Nach einer Recherche in den Corsair-Foren scheint das ein verbreitetes Problem mit den blauen LEDs (gibt auch rote) bei der K70 zu sein. Corsair hat das Modell zwischenzeitlich vom Markt genommen und wird wohl demnächst eine überarbeitete Version liefern.

Amazon nahm die K70 anstandslos zurück und als Ersatz habe ich mich für ein dasKeyboard 4 mit MX brown entschieden und es bisher nicht bereut.

Zum Abrunden des Portfolios der MX-Schalter, habe ich mir noch als Abwechslung zu den beiden dasKeyboard eine Ducky Shine 3 mit MX black gegönnt. Sie wirkt noch einen Tick solider, hat ein abnehmbares Kabel und zig Beleuchtungsoptionen. Der lineare Gang und höhere Widerstand der Switches ist etwas gewöhnungsbedürftig, aber angenehm, besonders beim Spielen.

Eine weitere Anmerkung zur Lautstärke: die dasKeyboard 4 haben zwischen ihrer Deckplatte aus Aluminium und der Stahlplatte einen sehr festen Schaumstoff, der die Geräuschkulisse dämpft. Der Unterschied zum Vorgängermodell oder auch der Corsair K70 ist ziemlich gewaltig. Sogar die MX blue-Version ist leiser als die K70 samt Gummi-O-Ringen. Die Ducky liegt durch ihre sehr stabile Konstruktion auch recht gut im Vergleich. Dazu tragen aber auch die MX black sicherlich ihren Teil bei.

Generell habe ich mit keiner der Tastaturen eine schlechte Tipp-Erfahrung gemacht. Nur das ANSI-Layout und die defekten LEDs haben mich zu einem Umtausch veranlasst.

Fazit

Nachdem ich nun in einem halben Jahr drei Hersteller und drei unterschiedliche Schalter-Typen durch habe, kann ich nur sagen, dass mich mechanische Tastaturen begeistern, wenn sie nicht sogar eine Sammlerwut entfacht haben (ich hoffe nicht, das wäre ein teures Hobby).

Der Tipp-Komfort und die Zuverlässigkeit sind es mir aber wert. Schließlich sind die Tastaturen auch maßgeblich daran beteiligt, dass ich überhaupt Geld verdiene. Wenn man die Unterschiede erstmal kennt, möchte man nur ungern zu Rubberdome-Tastaturen zurückkehren. Selbst mein früher geliebtes Apple Keyboard lasse ich für eine mechanische Tastatur links liegen.

Dazu gibt es eine unglaubliche Vielfalt an Individualisierungsmöglichkeiten. Seien es nun Tastenkappen, modifizierte Federn in den Schaltern oder gar leicht verrückte Dinge wie Tastatur-Bausätze, mit denen man wirklich alles bis ins letzte Detail für sich anpassen und austüfteln kann. Interessenten zu diesen Themen sowie Kaufberatung etc. kann ich das Forum geekhack ans Herz legen.

Leider wird TextMate kaum noch weiterentwickelt. Der letzte Release ist Monate her und TextMate 2 grenzt schon fast an Vaporware. Im Büro (sowohl früher als auch jetzt bei Chip) habe ich nun seit über einem halben Jahr auch einen Mac, daher kommt Notepad++ nicht als Alternative in Frage. Diverse Versuche mit Wine bzw. WineBottler haben sich als Schuss in den Ofen erwiesen.

Zu meinem großen Glück bin ich dann zufällig über Sublime Text 2 gestolpert. Zuerst dachte ich, es wäre nur ein billiger TextMate-Klon, aber weit gefehlt. Das Ding ist richtig toll.

Warum? Darum

• Läuft unter OS X, Windows und sogar Linux.
• Kann von Haus aus eine Menge, ohne überladen zu sein (gutes Syntax-Highlighting, umfangreiche Suchfunktionen, Code-Folding, Code Completion etc.)
• Bis ins letzte Detail konfigurierbar (nur über JSON-Files, keine GUI bisher).
• Erweiterbar über sog. Packages, die es für so ziemlich alles gibt, von ActionScript über Git bis Zen Coding (ein Großteil der TextMate Bundles ist kompatibel!)
• Sehr schnell und keine Probleme mit extrem langen Zeilen (TextMate gerät da teilweise unglaublich ins Stocken bishin zum Absturz).
• Tabs (ja, die kann TextMate auch, aber nur innerhalb von Projekten).
• Regelmäßige Updates.

Wie effizient man mit Sublime Text und ein paar kleinen Tools entwickeln kann, zeigt Andrey Tarantsov in einem sehr schönen Video. Da zeigt sich auch mal wieder, dass für Web-Entwickler OS X immer noch die beste Plattform ist — viele Tools gibt es für Windows schlichtweg nicht. Mal davon abgesehen, dass Arbeiten mit einem Terminal immer noch eine Qual ist. Cygwin ist hier zwar ein Segen, aber auch nicht allmächtig, da es nicht für alles Wichtige kompatible Versionen gibt (Stichwort Ruby Gems …).

Da Sublime Text 2 Shareware ist und beliebig lange getestet werden kann, rate ich jedem Entwickler ihn zumindest auszuprobieren — es lohnt sich. Und wer schon immer einen TextMate-ähnlichen Editor für Windows oder Linux gesucht hat: hier ist er!