How to get rid of GitHub notifications

I don't like notifications. I've minimized the number of notifications I receive on my phone to basically: direct messages, and phone calls from my wife. I also don't like notifications on my desktop system. I've turned everything off on every system I use.

But there's one place that I visit constantly, every day, every hour, where I couldn't get rid of the tiny blue dot that indicates that something changed, someone commented, or something new has to be reviewed. And that's GitHub.

During my last vacation, I logged out of GitHub on all systems, just to avoid seeing that blue dot telling me that my colleagues at work are busy saving the world. I didn't do any programming during that time, but I still had to visit GitHub sometimes!

Anyways. The internet, of course, has a solution. Using uBlock Origin, I can remove only the tiny blue notifications indicator from my It's something like "right click >> block element >> select the blue dot".

In the uBlock settings under "My filters" there's now this entry:

! 1/15/2020

which solves all my problems. :D

Copy & paste from tmux to system clipboard

For the first time in many years I am using a Linux machine for my work. In general I am extremely pleased with the system I've set up. But of course, there are things that don't "just work".

Like... copy selected text from a tmux pane to the clipboard.

As usual, StackOverflow knows the answer. In short:

# .tmux.conf
set-option -g mouse on
set-option -s set-clipboard off
bind-key -T copy-mode-vi MouseDragEnd1Pane send-keys -X copy-pipe-and-cancel "xclip -se c -i"

Auf geht's Freiburg, kämpfen und siegen!

Gestern war ich das erste Mal seit 20 Jahren beim Eishockey. Nachdem ich damals einige Spiele der Providence Bruins miterleben durfte, war es diesmal ein DEL-Spiel zwischen den Adlern aus Mannheim und einer Brausetruppe aus München in der SAP-Arena hier um die Ecke.

Da ich weder die Regeln noch die Taktik dieses Spiels verstehe, habe ich mich auf die wichtigen Beobachtungen konzentriert.

Die Pausenshow

Die zwei Eispolierfahrzeuge brauchen zu zweit 5 Minuten, um die Eisfläche einmal abzufahren. Dabei hätten sie dafür bis zu 18 Minuten Zeit. Ich spüre deutliches Optimierungspotenzial.

Der Bierstand

Die Stadionwurst konnte ich mit Bargeld bezahlen. Das kenne ich aus den Fußballarenen der Neuzeit nicht mehr. Dafür ist das Bier genauso schlecht wie überall sonst auch.

Eben jener Bierstand ist zwischen den Halbzeitpausen übrigens wie leergefegt. Ideal, um die Toiletten zu besuchen und den Getränkevorrat aufzufüllen.

Die Fans

Die Fangesänge sind dieselben wie im Fußballstadion. Es werden allerdings nur die einfachen Songs gesungen, die die ich also auch noch mitsingen kann. Die individuellen Mannschafts- oder Städtenamen waren allerdings unverständlich, weshalb mein Gehirn überall immer "Freiburg" eingefügt hat. Sehr angenehm!

RaBa München bringt genauso viele Auswärtsfans mit wie RaBa Leipzig. Das war schon ziemlich lächerlich, denn Mannheim ist immer eine Reise wert.

Das Spiel

Neben 9 Toren fiel mir vom Spiel noch auf:

Da heult keiner, weil er mal unsanft zu Boden gebracht wird. Erfrischend anders. Andererseits war ich irritiert, dass es gar keine Faustkämpfe auf dem Eis gab. Das habe ich anders in Erinnerung.

Und der Videobeweis ist scheiße.

Anki vs. the RZL

Last week I went to our local hackspace, the RaumZeitLabor, and I talked to Cheatha about my recent adventures with Anki. There were a few other people there that listened to my ramblings as well, and their reactions were not at all what I had expected.

It wasn't a well-prepared talk or anything, but the ensuing discussion was eye-opening.

There were a few firmly held opinions:

  • memorizing facts using the flashcard method (Karteikartenlernen) is horrifying to many.
  • the same people say that it doesn't make sense for learning a programming language, because learning how to program is a matter of practice and practice alone.

I even confused Cheatha, which is hard to do. So my main takeaway from the evening is that there are many more ideas in what I'm working on than I realized, all of which I tried to put into one short talk. But that simply doesn't work. The ideas are:

  1. What is spaced-repetition learning? How and why does it work? What's it good for? (boring but necessary)
  2. How to leverage Anki's templating system to efficiently create effective flashcards. (fun for nerds like us, but…)
  3. How I captured and memorized vocabulary for learning Spanish when I lived in Mexico, and how I'm capturing and memorizing vocabulary while learning Ruby now. (my main focus right now)
  4. How I try to remember more of what I read: books, articles, documentation. (still a little fuzzy, also for me)
  5. tbc

I'll have to explore each of these ideas separately. And I will, because I still believe that it will benefit me. So I guess the very next question I have to answer is: what benefit do I hope to get from memorizing all this information? It's a valid question that until now got drowned by my excitement of learning the new tools and the perception of "making progress".

Better Anki Learning Steps

I've been playing around with Anki, the spaced repetition application, A LOT in the last few weeks. This will certainly not be the last post about Anki, but I'll start with a simple reference post for me to remember where I learned how Anki's learning steps work.

Check out this video:

It explains

  1. the different types of cards in Anki,
  2. how learning intervals are calculated,
  3. what the ease and interval modifiers are,
  4. what the ease factor is, and
  5. how answers modify the interval.

It also talks in depth about "Ease Hell", what it is, and how to avoid it.

Now I finally understand what Anki's Learning Phase is all about (12:34), and how to best use it. Money quote:

Answering a card incorrectly in the learning phase does not change its ease factor.

The proposed settings for the Learning Phase are:

  • Steps (minutes): 15 1440 8640
  • Graduating Interval (days): 15

These numbers are based on the SuperMemo 2 algorithm (18:34), which is what Anki is actually using, just not with sane default. Watch the whole video for more details. It's worth it!

What I've learned about the Irish

I spent the last few days in Dublin, Ireland, visiting a very good friend of mine. These are a few observations I made during my stay:

  • The Irish consider themselves much less European than I had thought.
  • Mainland Europe is simply called "Europe".
  • They hate the English.
  • Until recently, Ireland had been living in the Middle Ages, as is accurately portrayed in the 1991 movie The Commitments.
  • They frickin' love The Commitments.
  • Germans are forgiven for not knowing anything about Rugby.
  • I have a better chance of catching an SC Freiburg match in Dublin than I do in Mannheim.
  • They know how to make a good breakfast.
  • They call Americano an Americano.
  • Guinness is owned by big alcohol and employs mob tactics to block other beer makers from getting their products into pubs.
  • Irish pub culture is as strong and real as it is advertised. Loving it!

Jason Swett: How I write characterization tests

Let’s say I come across a piece of code that I want to refactor but unfortunately

a) I don’t understand what it does and
b) it’s not covered by tests.

Yupp. That's a problem. How I write characterization tests shows a technique for how to deal with this situation. I, too, use tests to figure out how a piece of code actually works. Works better for me than actually reading the code. 🤨

Speeding up RSpec with bundler standalone and springified binstubs

Testing Rails with RSpec is slow, or at least it feels slow to me in all the projects I am working on. Any speed gain helps my productivity when it reduces the time I'm waiting between writing code and running tests.

There are quite a few posts out there that tackle this problem. But most are pretty old, and none really worked for me, so I'm not going to link to them.

The book I'm reading inspired me to look into the bundler --standalone command. Not that I really understand what's happening there, but at least I got a little bit of a speed bump out of it.

Here's what I did, and how I'm running my tests now.


First I made sure my Rails app is installed with Spring enabled. Luckily, this is the default. In order to later run RSpec from spring, I added the spring-commands-rspec gem to my Gemfile.

gem 'spring-commands-rspec'


Next, I used bundler's standalone command,

$ bundle install --standalone --path .bundle

and then "springified" the installed binstubs.

$ bundle exec spring binstub --all


I encountered a problem with SQLite 1.4.0. I didn't investigate it further, but pinned the gem to version 1.3 instead.

group :development, :test do
  gem "sqlite3", "~> 1.3.6"

Afterwards I repeated the install command.

$ bundle install --standalone --path .bundle

Anytime you want to use bundle install, you now have to use bundle install --standalone instead. I created the bash alias bis for that.


I recently started using the vim-test plugin. That plugin has a neat option that makes it use the springified binstubs.

" .vimrc

let test#ruby#use_spring_binstub = 1

Now, when I'm editing app/models/transformer_spec.rb and I hit the return key in normal mode, vim-test executes

$ ./bin/spring rspec spec/models/transformer_spec.rb

Because of spring, everything's faster and I have actually seen tests being executed in less than a second. Still not super fast but better than before.

Teach vim-rails about request specs

Slowly but surely I'm getting to know the really interesting Rails-related Vim plugins. First and foremost: vim-rails. A new feature that I started using recently is the :A alternate file command. Basically, this makes it super quick to jump from a model file to its model spec file. Or from a controller to its spec.

Since Rails 5.?, controller specs have fallen out of DHH's favor. We now use request specs. Unfortunately, vim-rails doesn't know about request specs. Fortunately, we can tell it about them.

vim-rails is very well documented, and :help rails-projections provides the solution to this problem. This is what I put in my .vimrc, and now :A jumps between my controller files and the related request specs.

let g:rails_projections = {
      \ "app/controllers/*_controller.rb": {
      \   "test": [
      \     "spec/controllers/{}_controller_spec.rb",
      \     "spec/requests/{}_spec.rb"
      \   ],
      \ },
      \ "spec/requests/*_spec.rb": {
      \   "alternate": [
      \     "app/controllers/{}_controller.rb",
      \   ],
      \ }}

Running RSpec with a single keystroke in a separate tmux session

This is a tiny update to Running Specs from Vim, Sent to tmux via Tslime from the thoughtbot blog. Go read it, and realize that it's six years old.

vim-rspec has not been updated in two years. It probably still works fine, but there's a new vim plugin that does what vim-rspec does, just better: vim-test.

I finally set this up yesterday:

" Add vim-test and tslime to vim plugins.
Plug 'janko/vim-test'
Plug 'jgdavey/tslime.vim'


" Configure vim-test to execute test command using tslime
let test#strategy = "tslime"

" Configure <CR> aka the Return key to run my test file.
nmap <CR> :TestFile<CR>
" I'm still figuring out which test commands make the most sense
" in my workflow. Right now, this feels pretty good.
nmap <leader><CR> :TestLast<CR>

Now, when I'm in normal mode and hit the return key, rspec gets executed for the current file in a different tmux pane (!!). What I didn't understand before using this was how it would select the correct pane. Turns out, it's super easy. On the first run, it asks me for the tmux session, window, and pane (if necessary). After that, it remembers and it always sends the test command there. Super cool!