racing · software · open-source

Chrome vs Safari#

Published on June 1, 2016

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.

Lucky#

Published on June 1, 2016

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

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:

A

B

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?

Saturday#

Published on April 23, 2016

Today is a saturday. It's a slow day. I barely got up, cooked & ate, binge-watched a ton of tv series. "Fear the Walking Dead" is off of my watchlist after the pilot already. To not waste this day completely, the plan was to finally launch a site where visitors can vote on their preferred tests. Tests as in software tests, so code to verify the correctness of a piece of a computer program. However, after diving deep into Ruby on Rails again, I saw this super epic tweet:

This got me thinking. Instead of getting hung up on building from scratch something that would be a blog for the most part, I should really focus on "shipping". That's why, for the n-th time, I stopped working on the site codenamed "writing-better-tests". Instead I set foot into the world of static site generators, fired up this thing called Hugo, and wrote these lines.

As for the future of this page, we will have to wait and see. I would love to continuosly add new content, mainly on the topic of software development. I do have a post or two in my mind already, so stay tuned ...

« Previous page