I’ve been looking at several MQTT brokers recently, and whilst I shan’t go into all the details of that, I shall post my hard-earned learnings on how to get VerneMQ built and running on macOS 10.12. This is all cobbled together from Googling various issues I ran into and bludgeoning my way to success, but hopefully this end to end description will be useful to somebody. To be honest, I have been massively put off VerneMQ because of this poor out-of-box developer experience and the extremely limited documentation.


  • Ensure XCode and its command line tools are installed, because we’ll need the command line compiler tools.
  • VerneMQ is built on Erlang, so we need to install that. Unfortunately the official “Erlang Installer” for mac didn’t work, giving an error: “erl could not be removed”. Thankfully brew works nicely. Don’t know why I didn’t try that straight off.
    • If you haven’t already got brew, install it from https://brew.sh. It’s really very quick and simple and a must-have tool anyway. Then install Erlang:
      > brew install erlang
  • Get the VerneMQ code:
    > git clone git://github.com/erlio/vernemq.git vernemq_git
    > cd vernemq_git
  • The build would fail with “vmq_passwd.c:32:10: fatal error: ‘openssl/evp.h’ file not found”, on macOS 10.11+, so we need to specify openssl location in CFLAGS. Ensure openssl is installed first if necessary, with brew:
    > brew install openssl
  • Get past an erlang rebar bug, caused by files being readonly, by making them readable (bit of a hacky workaround):
    > chmod -R u+w /usr/local/Cellar/erlang
  • Actually build it, now we have everything we need, adapting the path here as necessary to match the openssl version you actually have.
    > CFLAGS="-I /usr/local/Cellar/openssl/1.0.2k/include -L/usr/local/Cellar/openssl/1.0.2k/lib" make rel
  • If that succeeded (after a fair while) you should have the binaries in _build/default/rel/vernemq/bin/


It’s trivial to start the binary with default config:

_build/default/rel/vernemq/bin/vernemq start

Note that this starts it up then quits, but leaves the server running. You can do the same but with ‘stop’ to shut it down. See the docs on further things you can do with the vernemq binary.


If you’ve just built it and are running from the _build location, the config file it is using is at _build/default/rel/vernemq/etc/vernemq.conf

I turned on anonymous users and added a websockets listener by following the instructions in that file. I restarted the server (vernemq restart) and then was able to successfully publish and subscribe with the handy HiveMQ online WebSocket MQTT client.

I was recently frustrated by very slow tests and timeouts in my Java code, that would often show a similar stack trace (if they actually timed out):

    io.vertx.core.VertxException: Thread blocked
     at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
     at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:928)
     at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1323)
     at java.net.InetAddress.getLocalHost(InetAddress.java:1500)

I’ve highlighted the critical part. The Vertx bit is just what implements the timeout in my case. If you’re using a Mac and you see this, you’re probably having the same problem. You might also see Inet4AddressImpl in the stack trace instead of Inet6AddressImpl.

After a lot of web trawling and some help from a colleague (thanks Tim) I got to the bottom of it. I’m writing it up here, for my own benefit when I run into this again in the future, and because a lot of the existing resources weren’t clear and direct enough to solve my problem easily.

The fix

The slowness is caused by a domain name lookup that’s taking a few seconds each time, because for some reason your computer is asking the network about its own address, and timing out. I don’t fully understand the mechanics frankly, but the fix was simple in my case.

First, figure out what your computer thinks its hostname is, by running hostname in the terminal. Then use the value returned from that to add lines like this to your /etc/hosts file:

    # This works around slow lookup that we sometimes see in
    # java.net.Inet6AddressImpl.lookupAllHostAddr Sams-MacBook-Pro.local
    ::1 Sams-MacBook-Pro.local

This provides a direct answer for both IPv4 and IPv6, avoiding the slowness. This had the nice effect of bringing my Gradle build time down from 2 minutes to just 44 seconds, including all the tests.

I’ve accepted a new job, and for the first time in 15 years I’ll need to commute by car. A mere 8 or so miles, which I might occasionally cycle (though the half-decent cycle route is a lot longer) or even run (hey, it might happen) but realistically I need a car. We have a family car already, but I can’t take that to work everyday as the rest of the family need it, so car number two is required. Ideally a nice, reliable, every day driver, that’s comfortable, practical, good in stop-start traffic, and with great fuel economy.

So I fulfilled a long-held dream and bought this twenty five year old Porsche 944 S2.

Porsche 944 S2

It’s a beautiful thing, to me at least, though perhaps others see a relic of everything that was bad about the 80s. It’s a 1991 model from the end of the run, but basically an 80s car. It has a three litre inline four engine, putting out 211hp, that’s basically half of the eight cylinder 928 engine, with balance shafts to keep it smooth in four cylinder configuration. It has pop-up headlights. It even has a really very useable boot – seriously. Finally, and critically, there are two seats in the back that are genuinely big enough for my two kids. It’s lucky I and the wife have relatively short legs, so the front seats aren’t pushed back too far.

I was a bit worried about picking up the car and driving it back down the M1 to its new home, as the critical rubber timing belt has not been changed for 11 years, which is tantamount to engine suicide in these cars. If the belt breaks, the valves and pistons collide in a most unfortunate and expensive mess. The saving grace is that though the belt is elderly, it hasn’t done many miles – just 12,000. I will be having it changed and the whole car given a once-over by a local specialist ASAP. It’ll be interesting to see how much it ends up costing.

So what else is wrong with it? Lots! It’s a twenty five year old car, and I didn’t pay top-dollar so wasn’t expecting perfection. My inspection and test drive were a bit of blur, but here are the key things I picked up on.

  • Patches of lacquer gone in a couple of spots.
  • Some very minor dings, stone chips.
  • A small amount of rust bubbling behind front wheels.
  • Gear gaiter tatty.
  • Steering wheel tatty.
  • Some dash issues: ‘rosette’ grill slightly broken; trim lifting slightly.
  • Buttons worn – can’t make out the symbols on some of them any more.
  • Mats not secured well in the footwell because lugs they connect to are broken/missing.
  • Groan from steering at low speed.
  • Boot release switch doesn’t work.
  • No luggage blind or sunroof bag.
  • Some minor signs of oil from cam cover gasket in one spot.
  • Messed up rubber/foam thingy inside spring at front on one side.
  • Oil pressure gauge suspiciously showing 5 all the time when running.

These are all fixable or tolerable I reckon.

There was certainly enough good stuff to make me buy it.

  • Oil level and condition good.
  • Electrics all seem to work – though in my excitement I admit I failed to test every last thing.
  • Looks stunning from 2+ yards – i.e. the body is straight and paintwork pretty good.
  • Radio sounds good, with CD changer in the glovebox.
  • Tyres are brand new (Avon) and wheels in tip-top condition.
  • Very original – no nasty mods.
  • Drove nicely – comfortable cruising, smooth engine, decent gearbox.
  • Well kept history folder with each receipt in a plastic pocket. A good sign.

I should point out that for all its looks and sporty credentials, it’s not actually an especially fast car by modern standards. It doesn’t quite have the shove of the two-litre turbo diesel estate I normally drive – those turbo diesels are so torquey when the power whooshes in from the turbo. But it’s a beautiful classic, to be cherished and cosseted and most importantly, tinkered with! Expect more posts on the travails of old Porsche ownership as I get to grips with it, good and bad.

Test error

I was writing tests in Swift for a time parsing function, and on the way to getting it right, I saw some very confusing error output, as per the screenshot above. In that screenshot I’ve deliberately broken the test (the times don’t match) to invoke the red error text, but what’s interesting is that the error reports 04:02:15 and 04:03:15 instead of the times I actually used – 04:01 and 04:02 respectively.

When you’re testing time-parsing code, the last thing you want is the test failures giving confusing/misleading figures so I had to get to the bottom of it.

It turns out that GMT and “Europe/London” timezones diverge through history (ignoring daylight savings). In fact, in the year 0 AD they were one minute and fifteen seconds different, and it’s this discrepancy that was showing up in my tests. Note that it doesn’t affect the test results themselves – only the display of NSDate values when there’s a test failure.

I was constructing test times from NSDateComponents and only specifying day, hour and minute, as that was all that was relevant to the tests. However that left the year defaulting to zero. I was also specifying timezone as NSTimeZone(name: “Europe/London”). The error messages from XCode only have an NSDate to work with however, which doesn’t have any notion of timezone, so XCode used UTC/GMT to format for display. And being year zero dates, the time comes out differently. The simple fix for me was to set the year in the NSDateComponents to 2015 to get everything into line.

What would happen if I ran the tests in the summer, when daylight savings is in the effect here in the UK? I’m not sure, but I might end up with times an hour out, for the same reason.

Here’s some code you can dump into a playground to demonstrate. The results are even weirder if you use “Europe/Paris” as the timezone, giving “”0001-01-01 10:35:39 +0000” as the output, just nine minutes and twenty-one seconds earlier, rather than the whole hour earlier that one might expect (and that you get if you use 2015).

// Demonstrate GMT/UTC != "Europe/London" in year zero.
let ukTimeZone = NSTimeZone(name: "Europe/London")!
let ukCalendar = NSCalendar(calendarIdentifier: NSCalendarIdentifierGregorian)
ukCalendar?.timeZone = ukTimeZone
let dateComponents = NSDateComponents()
// Reinstate this to fix things.
//dateComponents.year = 2015
dateComponents.hour = 10
dateComponents.minute = 45
dateComponents.timeZone = ukTimeZone
let date = ukCalendar?.dateFromComponents(dateComponents)
date?.debugDescription // "0001-01-01 10:46:15 +0000"


It’s actually pretty simple, if you know what you’re doing:

  • convert project to a workspace if it isn’t already
  • add Carthage/Checkouts/SWXMLHash/SWXMLHash.xcodeproj to the workspace
  • move playgrounds to the workspace (not a project)
  • build the SWXMLHash project.
  • import SWXMLHash successfully in your playground, as long as the target you have selected includes the SWXMLHash framework project.

But if you don’t know what you’re doing…

I struggled to “import SWXMLHash” in my XCode Playground. I kept getting an angry red error for the module import. SWXMLHash is a third party framework I wanted to experiment with, that makes XML parsing nice and simple (ish).

Having figured out the trick to getting third party frameworks working in playgrounds, I thought I’d document it and the pitfalls. Really it’s pretty much just a case of following Apple’s own documentation, but I still took a while to get it right, mostly due to still being on the learning curve for the ecosystem. So my instructions are more tailored to the innocent newbie.

In my case I’m using Carthage to fetch and build SWXMLHash, so I have a copy of the framework’s project source in my project’s Carthage/Checkouts/SWXMLHash directory. Which we can use later, but first…

You need to be using a Workspace, not a Project in XCode. I had a project because that’s what XCode gave me when I started my new world-beating app, and I didn’t know any better. Use File > Save as Workspace… to save a workspace file containing just your current project. It seems to be traditional to use the same name as the main project, so we end up with Foo.xcodeproj and Foo.xcworkspace files. From now on, always open the workspace not the project.

Now move your playgrounds out from your project and into the workspace – i.e. up a level. I did this by deleting the playground reference from within the original project, then adding it to the workspace with the + button in the very bottom-left of the XCode UI. That button adds to whatever is selected, so ensure nothing is selected (cmd-click on the currently selected item to deselect it). There are probably other ways. Hell, maybe you can even drag them, but I didn’t try that.

Playgrounds can only deal with Frameworks whose project is within the same workspace. If you’ve only got a .framework file I believe you can put it in with the system frameworks in the right place on disk and it will be found, as a workaround, but I’ve got the project courtesy of Carthage so we’re OK here. Add that project (Carthage/Checkouts/SWXMLHash/SWXMLHash.xcodeproj in my case) to the workspace via that bottom-left + button. Build that freshly added framework project for Mac by selecting the relevant scheme from the dropdown in the toolbar and selecting Product > Build.

Now, in your playground, you should be able to import and use that framework, but there’s one final wrinkle: the currently selected target must include the SWXMLHash framework project. Targets that include the Carthage-built framework don’t count – it has to be the framework project that you added above. So for example, selecting the SWXMLHash target itself works. You want the OSX build, because that’s the variant of the framework that is used in the playground.

It’s also probably for the best that your playgrounds now exist in a workspace rather than in a project, cleanliness-wise. It should look something like the image below, with playground, framework project and my own project in the workspace, and the module import working correctly in the playground

Workspace setup

Flowering Anubias

I posted recently about my latest attempt to banish the dreaded black hair algae from my tropical aquarium. Well, I’m happy to say that it seems to have worked and now keeping the tank clean is a breeze! No more scraping, scrubbing and bleaching everything in the tank every few weeks.

To reiterate, the new tactics were as follows, aimed at lowering the phosphates that were probably powering the algae’s rampant growth.

  • Add live plants, to consume the phosphates in the water.
  • Change the feeding regime:
    • use a lower-phosphate food, rather than the “premium” stuff we had been using
    • feed less overall, as we were probably over-feeding and the excess, high-phosphate food was lingering.

I had been battling this scourge for the last year or more, so I am delighted to have solved the problem.

Also, live plants are more fun than plastic ones. The Anubias is flowering already, as you can see in the picture.

Apple Watch battery

Do Apple Watch owners suffer “range anxiety”, in the same manner as electric car owners? In my experience, yes, but it fades quite quickly once expectations and experience collide and settle down.

For my usage so far – albeit just a week and a half – my 42mm watch generally has more than 50% left when I hit the sack, having been on my wrist approx 06:45 to 23:00. Given that I have no qualms at all about charging it every night, that’s pretty good, and better than a lot of scare stories had led me to expect. Of course if I was going camping for a week it would be utterly useless, but I accept that it’s just not the right product for that scene.

How much do I really use it though? I don’t stare at it all day long, especially as the novelty starts to wear off. Apple are correct: its rightful place in the world is for fleeting interactions lasting just a few seconds, and I have quickly settled into that very casual relationship with it. Right now, I use it to:

  • check the time (obviously)
  • check the weather
  • to see what song is playing on my iPhone when I don’t recognise it
  • to see incoming messages and tweets (but very rarely to respond to them)
  • to snooze/dismiss calendar alerts
  • to quickly set a timer for an ad-hoc reminder
  • to take incoming calls, before getting my iPhone out and switching to that – but I hope to get out of that habit
  • for running (much more about that in a future post)
  • for keeping tabs on general activity via Apple’s ‘Activity’ app with its all-knowing three circles

I’ve had one day where the battery ran out prematurely. Very prematurely, at 1830! That morning I’d gone for a 5km run using Apple’s built-in ‘Workout’ app – my first and only time with that app so far – which had knocked the battery down to 84% by 0700. That actually didn’t seem too bad for the run itself, since it was working hard keeping track of heart rate etc. but I still don’t understand how it came to expire later on, from being a mere 16% down at the start. Perhaps the battery level reporting was poor and when it said 84% it was actually much lower. Indeed when it flaked out, it was reporting 13% so maybe calibration was poor, and maybe I’m closer to the wire than I think when I go to bed with an apparently healthy percentage left. We’ll see how future experiments pan out.


The allure of being able to walk into an Apple Store, try one on and get instant purchasing gratification was just too much, and I caved. Having decided to get an Apple Watch to develop apps against, but never having actually liked the look of them, my opinion changed the moment I fondled one in the store. The quality feel is simply exceptional and it was immediately comfortable on my wrist, but the best and most surprising thing was the size.

I don’t have large wrists but the larger 42mm watch sits very nicely indeed. It is definitively not a hefty lump of technology struggling to masquerade as a watch. And I say that because I had expected it to be ungainly and oversized, based on my limited experience of Android devices.

But how have they achieved this? Wonders of electronic miniaturisation of course, with miserly power consumption allowing for a tinier battery than the competition. But that’s not the most cunning part in my opinion.

The crucial trick was to employ a rectangular screen and a user interface with a black background. This affords many subtle wins over much of the competition!

Rectangular screen

Many Android watches have gone for a circular screen – which best mirrors the classic round watch look. But it’s hard to use the circular space efficiently for displaying information other than a clock face. Apple’s rectangular screen is (comparatively) easy to fill up with well-spaced information, even though it’s tiny. To show a block of text on a circular screen means lots of wasted curved scraps of space. As a developer I’m glad I don’t have to create apps for circular screens!

Black background – black bezel

The Apple Watch user interface employs a black background throughout, which merges seamlessly into the black bezel around the screen, with the glass wrapping over both. The shine of the curved glass edge and the super-deep black of the OLED screen means it really is an invisible transition. This means that the user interface elements can run right out to the edges and corners of the screen, without requiring any padding to space them pleasingly away from those edges. The physical bezel outside the screen is that padding.

Again, this maximises the usable space whilst keeping the package small. Competing watches that have a distinct bezel have to inset UI elements and so a surprising amount of power-draining screen real-estate is wasted.

Also, with an OLED screen, a black background is directly better for power consumption, as each pixel is individually illuminated (there is no separate backlight) and black pixels consume the least power.

UI tricks to maintain the illusion

The ‘home screen’ is a hexagonal grid of circular icons, which immediately diffuses the rectilinear reality. The most cunning part of all though is how the icons smoothly shrink down to nothing as they approach the physical limits of the screen. This stops them being chopped off at the straight edge and so maintains the inky black illusion.


Elsewhere in the user interface, elements with non-black backgrounds are heavily rounded. Of course the screen edges reveal themselves when scrolling vertically through content, or sideways between glances, but those are usually fairly brief transitions, and the illusion can only go so far.

Bonus: no lugs

Unrelated to the points above, but worth mentioning for its vital impact on the sense of size, the strap connects to the case seamlessly via Apple’s custom attachment (all the better to sell you expensive replacements) but this negates the need for two lugs top and bottom, sticking out and increasing the height of the device.

Finally, some amateur prognostication

As smart phones evolved it turned out that telephony was way down on the list of real users’ activities. There will probably be a similar story with ‘smart watches’, with years of exciting evolution ahead, not just for the raw technology but to establish a successful form and function. It’s anthropology as much as it is technology. People’s habits and expectations, and fashion too will evolve alongside the gadgets.

Right now many vendors are trying to replicate the traditional watch in form, it being the obvious starting point, but I predict that we’ll quickly move on from that as people get used to having their digital lives reflected in miniature on their wrists. One of the clock faces that Apple provides is named “Modular”  – shown in the image at the top of this post – and is a very utilitarian grid of configurable information. At first I didn’t like it, but already it has won me over and I find it striking how far I’ve already been moved away from the traditional watch. Once again, the rectangular format plays well to this direction.

On the fashion front, I notice in the mirror that the Apple Watch on my wrist is a featureless, glossy black blob on a black strap when it’s not illuminated. This is quite a departure from the aesthetic of a traditional watch, and right now I’m not especially keen on it. But before long that will be an accepted norm that doesn’t seem strange or out of place.

Who knows – maybe my thoughts here are completely out of whack with what Apple were thinking. It’ll be interesting to see how things develop.