racing · software · open-source

Opinion: Robotic racing

Published on July 15, 2018 · 206 words · about 1 min reading time

Roborace, the autonomous racing company and car, has recently competed in the Goodwood Festival Of Speed. I am a huge proponent of autonomy in the automotive sector as a whole, but sporadically following Roborace's public outings make me wonder if autonomous racing will ever be a thing. Watch the hillclimb first:

A few questions answered first: Do I think this is impressive? Absolutely. Massive props to the team of engineers that got this car speeding up that hill. Do I think this makes sense? Totally, those outings push forward the state of autonomous driving for sure. So this post is not at all a bash on the achievements or intentions of Roborace at all.

But can I imagine myself watching a race of autonomous vehicles, should it ever happen? Hard to tell, but it sure doesn't get me to the edge of my seat right now. Reflecting on why I dig watching F1 or AMA Pro Supercross, the "human" parts (the odd errors, emotions, sense of danger ...) are most certainly a factor. Let's see where this goes, and make a call once we actually see an autonomous race on real racetracks.

Bonus, the onboard:

My favorite continuous integration providers (May 2018)

Published on May 24, 2018 · 280 words · about 1 min reading time

Seeing the following tweet yesterday, which links to a great article comparing multiple CI/CD providers

made me realize that I did indeed go through most of them at some point in time. So very shortly, here are my two cents:


I agree with the article, it's great, I use it to do CI/CD for this very website. Nothing much to say. The build UI is not great on mobile though. Cannot do iOS/Android builds though?

Travis CI

Still use it, gets the job done. Nothing more to add. It's running the danger-todoist builds.


I found the configuration weird in the beginning, but you can get used to it. Major plus: Can do both my iOS and Android builds for PitBuddy App for private repositories.


I think Nevercode aquired Buddybuild at some point. I was using Buddybuild for iOS builds and when I started to get an Android build going it just was impossible to setup and massively unreliably. Can't say much about Nevercode, but I am happy I left Buddybuild for Bitrise.

Bitbucket Pipelines

Obviously I just recently started using it, so far so good. Can't do iOS/Android. Build speeds are great up until now.

Gitlab CI

Is this the solution to doing both web, iOS and Android in one tool? Hosting the code there as well? Seems tempting! I like Gitlab the SCM tool, and Gitlab CI has come a long way.

That's it, just a quick reminder on what I already tried and would like to try.

FTP lives: Deploying a static site with Bitbucket pipelines

Published on May 23, 2018 · 529 words · about 2 min reading time

Yes. It still exists. Not the entire world has moved to a fancy pants containerized Kubernetes - Serverless - Cloud Hosting (I don't even know the actual latest trends) setup yet. Case in point is, website to my hobby iOS and Android app for rc car racing enthusiasts. The website is plain static html, no preprocessors, no javascript, build steps or the likes. It is hosted on my families 1und1 webspace. So how did I deploy this in the past? Yes, I took the trusty FTP program and copied the files (insert laughter here).

Bitbucket pipelines

The code for the site itself is versioned in a private repo on, and bitbucket does come with their version of CI/CD tooling called "pipelines". I wanted to use this since setting up yet another external CI integration like travis or circleci felt a bit overkill for this. Granted, the site did not have any tests/verification at all so far.

BackstopJS once more

Having no tests or verification mechanism at all is not a great prerequisite for a continuous delivery toolchain, even for a static site. This would mean broken versions of the site would be deployed without warning. So once more backstopjs to the rescue. Setting up backstopjs was again without hassle, it can resolve file:// urls no problem. So a set of reference images were quickly created and I could look at reproducing those images in the pipeline.

The pipeline

Bitbucket pipelines are configured through a bitbucket-pipelines.yml file. No surprises here, thats in essence how most of the CI providers do it. The two cornerstones of the pipeline are two docker images. One to run the visual regression tests, the other to do the deployment. That's a "test->deploy" pipeline in a nutshell. This is the configuration in it's entirety:

The test step, run directly on the official backstopjs docker container, is simply executing the test task of backstopjs. This compares three reference images (three because I set up three viewport sizes once more) against what is currently rendered when opening the index.html. When they are identical, the deploy pipeline step is triggered. Deploy is, as mentioned, as simple as copying the relevant files to the correct directory on the webspace. Already a while ago I found a git plugin to accomplish this. It is called git-ftp and solves my issue very smoothly. As for backstop, a docker image already exists just to run git ftp. So all I needed to do (and I have struggled to get this working in the past) was to create a separate ftp user (for security reasons), add the FTP_USER, FTP_PASSWORD and FTP_URL environment variables to the bitbucket pipelines settings and voilá, continuous deployment for a static site with the safety net of visual regression tests it is 🎉. git ftp can use a separate ignore file to tune what content to deploy or omit.

Lessons learned

Shipping code from the iPhone

Published on May 4, 2018 · 775 words · about 3 min reading time

After traveling abroad for more than two weeks and then spending two days laying by the pool I naturally got a bit of a tech craving. To spend the afternoon I set myself the challenge of fixing a small bug on this blog, having nothing more than some Hotel WiFi™ and my iPhone at hand. But that must be enough, right? Let‘s see how it went.

The objective

In this blog I display a permalink hash next to the blog posts title, which is a link to view the post separately as well. When using e.g. Safari‘s „Reader“ mode, this hash symbol is of no use and should not be there.

Initial Bug

The journey

So how can we get started on this? First we need access to the repo of course. I had come across an app called Working Copy, and looking that up in the App Store was promising: I can check out the repo to my iPhone. What a time to be alive!  Not only can I check out the source code, but it comes with text editing capabilities as well. Making the change was pretty easy it seemed. I first browsed for the test that verifies the permalink, and removed the expected hash symbol from there.

Which lead to the first realization: I cannot run the tests on my iPhone. While that definitely kills the quick feedback loop I so much long for, it is fine for very simple changes (because CI will save me) and the occasional holiday-deploy. Alas I made the change, committed and pushed, and opened the PR. Opening the PR can be done on, however strangely only via the desktop version. This triggers the continuous integration build on, and duly notified me that I forgot to make the production code change to go with the test change! Oh well, another commit and push and I was looking good, build passing. At least concerning the crystal code. But what about the CSS? For now I had only removed the hash symbol, but we still want it to be there through CSS. So that‘s limitation two: I have no way to play around with the CSS on the blog. Firstly because of the lack of an actual dev environment on the phone, but also because I don’t yet run visual regression testing on CI. My way out of this was to fire up and use that as a playground. Again, because the change was pretty trivial and I just needed to confirm one assumption I had. That proved true and with it I was ready to merge the PR, using GitHub's website. As continuous deployment was already set up as well this was actually all there was to it. The build job passed as expected, sending off the deploy job straight after it and after 5 minutes or so I could visit the live page and confirm that indeed everything still looks the same, but the hash symbol is not showing up in Reader mode. Cool ✅

Fixed bugFixed bug visual

The aftermath

Switching between GitHub's mobile and desktop version was kind of clunky and still didn't allow me to upload any screenshots. I then realized that my twitter feed had mentioned Ryan Nystroms GitHawk in the past. One more trip to the App Store and yes yes yes, that is much more pleasant than the website!

Editing issues / PRs is way more comfortable and image upload works as intended. That will be a much better combo I think, I am looking forward to using that for the next exercise.

What Worked

What didn‘t work

Of course this exercise was purely recreational. I was in no way forced to write or deploy code from halfway across the world on my iPhone, but I kind of wanted to.

Refactoring CSS

Published on April 8, 2018 · 448 words · about 2 min reading time

One shortcoming of this permanently-work-in-progress blog of mine was the rendering on mobile devices. The experience of browsing the blog on a phone or tablet was less than ideal: text touching the borders of the screen, images overflowing the main section, social media links being out of place, and many more. It was a long standing issue. So I set off on fixing this. While digging straight into the first CSS changes and fiddling in the developer console of Chrome, I remembered what I wrote in the Snapshot TDD post:

Things of visual nature are not unit-tested easily, which is why they are often simply untested. We usually don't test stylesheets, colors, images etc. However we can't say those things are unimportant.

Unhappy about the workflow I just started and taking into account the above thought, I typed some words into google and emerged with this awesome tool: BackstopJS. It's headlined with "Visual regression testing for web apps" and was exactly what I was looking for. It provides a safety net for changing the visual nature of something rendered in a browser by taking and comparing screenshots. Basically exactly what I manually and crudely setup for the e-ink dashboard, just so much more awesome.

Setup and usage

Both setting up and using BackstopJS is dead simple and can be explained in this short snippet:

You will get a really nice page telling you that the tests were failing. Why? Because you have not approved any reference images yet. Once you look at those images and assert that this is currently the way things are looking, go ahead and backstop approve those. Now you are golden and able to make changes to your pages CSS without having to fear to a) break thinks if you are refactoring, or b) having a super quick way to get an overview of the changes you made across multiple pages of your blog in different viewports.


With my page being a blog, the content obviously will continuously change, making the comparison of the current look against reference images unfeasable. Luckily this is an easy fix: I created a new database containing exactly one sample post, which uses all the usual tags like h1-h6, lists, blockquotes to showcase most of the styles coming into play.

This is how the current reference image looks in tablet mode:

Tablet reference image for sample post


As always, you can follow along to the PR on github. One example of a change to the reference image can be seen here. I must say I am mega impressed with BackstopJS and will try to use that again in the future. One open task is to get that running on CircleCI as well.

Next page »