Makefiles to Rule Them All

In my last blogpost you might have already stumbled over me using a Makefile to simplify a project task. My enthusiasm for Makefiles goes a bit further and I add one to most of my projects by now. Here is why I do this and how they make my everyday developer life a bit easier.

None of my projects is written in C or C++ which rely on a Makefile for compiling them. Instead my projects are written in JavaScript (Node), Ruby and PHP. I use the make command as a wrapper for the individual tools coming with each ecosystem to create a common interface. This way I can just run make test no matter whether the tests are in JavaScript and use Mocha or use PHPUnit.

Adding a Microblog to Jekyll

Since I learned about micro.blog back in January I wanted to give it a try on my blog. For the last few days I had a few attempts on it. And as you can see at xam.io/microblog and on micro.blog I was successful. Now I want to share how I implemented it.

A hat tip to the Creating a Microblog with Jekyll post which covers a lot of the groundwork. I picked up a lot of his ideas and will focus a bit more on the integration with my existing blog in this post.

Hello world! — For the lack of better words, this is my first micro.blog post. You can find me there as @xam.

A more thorough post on how I implemented it with Jekyll will follow.

Goodbye Google Analytics

I just removed Google Analytics from this blog. I use the Firefox Tracking Protection and thus Google Analytics is blocked on all websites I visit anyway (including this blog) — time to quit this double standard.

I ended up not bothering to have a permanent setup. Instead I run goaccess with the latest access logs whenever I want to look at the numbers:

zcat -f access.log* | goaccess

Deploying Jekyll with Bitbucket Pipelines

The technology behind this blog is in a permanent flux. It’s my primary playground to try out new stuff. As you might know, this Jekyll generates this blog. It is a static site generator which takes my posts (written as Markdown files) and generates the HTML pages you’re looking at right now. To be more specific: The source files are stored on Bitbucket.org and a server at Hetzner serves the HTML files. When changes are made in Bitbucket, it would trigger the Jekyll setup on the server to publish everything straight away.

Some time ago, Bitbucket.org introduced Pipelines. A feature which gives you the ability to run build and deployment scripts on Bitbucket itself. Curious on how much of a continuous deployment pipeline I could create, I decided to give it a try. To move Jekyll from running on my server to let Bitbucket take care of it. This post details the process and what I came up with and some general thoughts on this feature-set of Bitbucket.

PHP Integration Tests Using the Built-in Server

Microservices have plopped up everywhere and I have written a few of them at work by now. Given the limited scope I find microservices a pleasure to write tests for compared to most (legacy) monolith. In this post I want to share an approach on how to test microservices written in PHP using it’s built-in server and some pitfalls we encountered so far.

Let’s assume we have a nice little microservice built with Slim, Lumen or which ever framework you prefer. We have some routes that return JSON responses and accept various JSON payloads.

We’re able to run this application using PHP’s built-in server by running for example:

ENVIRONMENT=production php -S 0.0.0.0:8080 -t public public/index.php

In this case the public/index.php is the entry file for any HTTP request, and the server is no reachable at http://localhost:8080.

Also you already have a PHPUnit setup available which covers unit tests. For the sake of brevity we will skip the whole PHPUnit setup part and jump directly into writing tests against the built-in server.

Moving Clouds: Hello Hetzner

This page and most my other online stuff are now served from a small machine in the Hetzner Cloud. Previously I had a small droplet over at DigitalOcean. Using the smallest instances on both, I get about the same performance for half the costs. Since most stuff I run is based on static pages, there is currently not much need for a bigger instance.

The most tedious thing of moving all the stuff over, were the DNS entries. But all records got published surprisingly quickly, so that I had to wait for less than an hour in most cases. By now all caches should be updated and I shut down the old instance – of course with my fingers crossed that I didn’t forget anything.

For anybody curious, this is my current setup:

The Comeback of Feeds

A year ago I wrote how newsletters became my main way to stay up-to-date and how RSS died a little for me when Google Reader was sunsetted. Now it’s 2018 and things changed a bit: I’m back on the “feeds-are-awesome”-team.

As I tend to only keep mails in my inbox which are still “to-do”, the newsletters felt more and more like a task I had to complete. Especially whenever a few started to pile up, this became annoying. Recently I saw two things that spurred my interest in feeds again. On the one hand Brent Simmons is currently working on a new opensource feed reader for macOS, called Evergreen. And on the other hand I stumbled about micro.blog, a sort of RSS-based Twitter.

So I reactivated my Feedbin account – a web-based feed reader. For now I mostly subscribed to personal blogs of people I know and/or admire. And while I initially unsubscribed from a few newsletters, I notices a few days ago that you can subscribe to newsletters via Feedbin, so I re-subscribed to a few via Feedbin. For now I use the webinterface only and look forward to Evergreen gain the ability to sync with Feedbin.

On the second topic of micro.blog: The idea is that you can write twitter-like posts on your own blog and syndicate them through RSS. So all publishing happens decentralized under my own control. The platform micro.blog then consolidates all those feeds into a neat interface. I yet have to fully set my micro.blog up though.

And as a general benefit, this blog has now a favicon.

Firewatch

When Firewatch came out in early 2016 I wanted to play it. However I never got around to actually do so. Currently the game is on sale on all platforms. I opted for the PS4 version.

Firewatch Screenshot

So I spent the last two evenings immersed in a forest with walking on trails, talking to a person you don’t see throughout the whole game (but still feel like you know her) and becoming nervous about what’s actually going on.

The atmosphere of the game is astonishing. Just the end comes a bit too abrupt, but I really like the ambiguity of it. And there are a lot of questions left unanswered.

Looking forward to their next game: In the Valley of Gods.

Headphones — Round 3

As a reader of this blog, you might have noticed that I have a distinct interest in headphones. If you happen to be a colleague, you might even be a little bit amused about this foible of mine and how much time I spend on it. In the last post I mentioned that I didn’t had the chance yet to test the Bose QC 35 or the Sony MDR 1000X. This summer their successors to both were announced and long story short: This is a review of the Bose QC 35 II and the Sony WH 1000XM2.

Quick background: I am looking for headphones to use primarily while commuting and at work. They will be used paired to an iPhone and a MacBook Pro. Noise Cancelling is nice when on the train, and phone quality should be okay enough to participate in Skype calls at the office. Before this review I have been using the Plantronics BackBeat Pro 2 SE for almost a year. So this review will compare these three headphones.

Look & Feel

Both headphones come with similar cases. On first try the Bose one feels a bit lighter and fragile, whereas the Sony a bit more rigid. Nonetheless the build quality of both headphones is great.

The first time I wore them, I was surprised. I didn’t expect much difference to the Plantronics, but exactly that’s the case: They feel much nicer to wear. In particular there is more space between the ear and the earcups. When using them for an extended period of the time, the BackBeat Pro became uncomfortable as my ear ever so slightly touched the inner of the earcups. This is not the case for these two.

The 1000XM2 feels to sit a bit more tighter on the head already blocking a good amount of sound this way. The QC 35 II is a bit lighter. But without the direct comparison I could hardly notice these difference. Both were very comfortable to wear for 3-4 hours at a time, something I couldn’t do with the BackBeats.

Sound

Probably the most important part about headphones: Sound. To me they are in the same league as the BackBeat, probably also because the Apple devices support none of the proclaimed superior audio codecs the Sony supports. And after all neither the bitrate is at a level to satisfy real audiophiles nor is my listening as sensitive to notice.

From a general perspective the Sony set is a bit more on the bass-y side of the spectrum, whereas the Bose feels very neutral. In direct comparison the Sony offers a somewhat fuller sound when listening to music (mostly rock in my case), but at no point it felt like too much bass like Beats headphones. But again I could only notice the differences in sound when directly listening to same track on both headphones back to back. Only when I really intend to listen actively to loud rock music I occasionally missed a bit more bass on the Bose headphones.

I also tested both headphones to use as a headset for calls. I’ve gotten the feedback that the sound of my voice is much better in general than from the BackBeat Pro. Turns out those only recorded with 8 kHz whereas both the 1000XM2 and the QC35 II recorded with 16 kHz. Besides that they were slightly better on not transmitting all the background noise. That said, I’m curious how the Plantronics Voyager 8200 UC perform in this regard.

Noise Cancelling

In general I like Noise Cancelling on headphones but I couldn’t spot any distinct differences when using them in the office and on the subway. But the effect is noticeable and I had NC active most of the time.

I disabled the additional NC features of the Sony (reacting to air pressure and my current activity), because it irritated me most of the time. Also when I’m outside – even with NC enabled – I have them mostly at a volume level where I would nonetheless notice cars honk.

Handling

Here comes a general complaint: Even the old Plantronics BackBeat were already able to do multipoint Bluetooth. How can it be that Sony ships headphones without this feature? Especially in my case I would have two audio source close to each other most of the day: I want to enter the office listening to music from my iPhone, sit down at the desk, pause the music from the iPhone and start the music on my Mac.

To make this work with the Sony I would have to switch Bluetooth on and off all the time on either device, or enter the pairing mode on the headphones and the device. The Bose does support multipoint – although that’s also a bit buggy sometimes – and is therefore way better when I know that I want to switch sources multiple times a day.

Another point of interest are the controls: The Sony has touch controls and the Bose relies on buttons. While it needed some time until I figured out all touch gestures and how exactly I had to do them, it was just as easy to use as the physical nobs on the Bose.

Conclusion

I picked the Bose. The missing multipoint support of the Sony and the therefore tedious change between devices was a dealbreaker for me. Initially I was afraid to be annoyed by the very neutral sound of the Bose, but after more than a week of constant use, there is no such thing.

The improved comfort of the QC 35 II over the BackBeat Pro has me wearing headphones for way longer periods of time than before. Also I use them for calls more often. Previously I would often use some cheap In Ears with a cable for calls, just for a better microphone quality to not-annoy the others on the call.

All in all I couldn’t be happier with my new headphones, but of course I’m curious what the next generation of headphones has to offer.