racing · software · open-source

50 Million Lines of Bugs

Published on December 8, 2017 · 126 words · less than a minute reading time

I often think about the following Mercedes-Benz advert:

In what world having whatever many lines of code should be something to brag about is beyond me. The tweet already hints at this nicely. But the marketing department seemed to have a different opinion in this case.

While I don't have credible numbers to back this, I think we can agree more code correlates with more bugs in some way. So Mercedes-Benz, please, try to keep the number of lines of code in your cars as low as possibly can be.

Lucky Crystal

Published on December 3, 2017 · 239 words · about 1 min reading time

In the ever changing landscape of web frameworks, there is a new kid on the block: Lucky. Lucky is written in Crystal, a statically typed programming language heavily inspired by Ruby's syntax, which claims to be

Fast as C, slick as Ruby

For this blog however, being as fast as C is mostly irrelevant, I'm sure it'd be plenty fine running in Ruby as well. What I rather value is developer productivity, or "getting something done in half an hour before going to bed". On that end, the Lucky + Crystal combination performed pretty well and I got a rewrite of this website shipped in a few hours of work.

Type safe html

What I find super interesting about Lucky is the way it deals with the task of rendering html. While the plethora of templating engines like ERB, Twig or Crystal's ECR are easy to work with and simple enough to understand, there's something about using plain Crystal code to markup html. The following gist is an example method from this blogs source code:

As you can see it was trivial to extract methods to render reoccuring or more complex parts of the layout. It's just code. Also the compiler will complain if we produce invalid code, so we cannot forget to close tags. That's kind of a big deal to me.

I look forward to spending more time in Lucky and Crystal, they both get a thumbs up for now!

Chrome vs Safari

Published on June 1, 2016 · 140 words · less than a minute reading time

Chrome and Safari are both great browsers. They each have their pros and cons. I tend to be undecided on which one I like better. Chrome has great developer tools. I never really got warm with Safari's. As usual, Safari is tightly integrated with OS X. Tab sync to iOS's Safari being one of them. Generally using less memory. Lately I tend to use Safari more then Chrome. But out of old habits I often start a new window in Chrome and browse for a few minutes before remembering that I wanted to use Safari. So here it is, the solution to all of my problems to a tiny annoyance of my incredibly blessed life:

This will take all of your windows and tabs you currently have open in Google Chrome, and replicate them in Safari. Switch browsers with the touch of a button.


Published on June 1, 2016 · 149 words · less than a minute reading time

I really can't stand much of the negativity some people exhibit in their daily lives. Just give it a second dude. Sometimes we really need to take a step back and appreciate what we take for granted. Without further ado, here's list of problems you probably never needed to worry about:

And with those menaces out of the picture, you are likely free to enjoy all of this:

I just feel that this has to be called to mind from time to time. This is not the norm. You are rich.

Local variable

Published on April 23, 2016 · 261 words · about 1 min reading time

This is the first installment of "A vs. B", the series on the details of (mostly unit) tests. Without going into much detail, having an extensive set of unit tests to verify the behaviour of the parts composing a computer program is of immense value. But since those tests are code as well, we should look at the quality of those tests with laser eyes as well.

This specific example is PHP code and assumes an xUnit style test, in this case using PHPUnit. The tools and even language however are completely besides the issue I want to focus on. So here are the two variants:



Example A uses the local variable name to both as a parameter to the method call on the system under test as well as to specify the expected value to the assertion. Example B in contrast does not use a local variable. It simply uses the string literal "Peter" twice. While there is some obvious duplication to the literal in variant B, I personally still tend to go this route. While I agree that you'd have to change two lines of code if you were to call "Peter" "Mark" instead, how often are you going to change the string?

Being able to recognize a dead clear assertion (firstname should equal "Peter") by looking only at a single line of code is very useful to me. This becomes increasingly helpful when you have to spot the line where a test failure is coming from.

There you go "A vs. B", round one. What do you think?

« Previous page · Next page »