This website does not display correctly in Internet Explorer 8 and older browsers. The commenting system does not work either in these browsers. Sorry.

Blog » Coding

A new Thoughtworks screen saver

22 January 2022

Posted in Coding, Coding

Somehow I have a weak spot for screen savers, for writing screen savers that is. The combination of programming, maths, and beauty is just very appealing to me. So, when Thoughtworks went through the brand refresh last summer I took that as an invitation to write a new company screen saver. (I had written the previous ones, too.) The new screen saver animates one of the illustrations that were created as part of the brand refresh.

It is written in Swift but this time I didn't go for the low-level Metal graphics APIs. Instead, I used a higher-level abstraction (CALayers) that make the code simple while still providing decent performance. The code is open source and available on Github here.

Comments and related posts

A new web commenting system

10 February 2021

Posted in Coding, Coding

On websites like this one it’s still a good idea to add the option for readers to leave comments, I would argue. It opens the door for a dialogue.

Of course, I could simply add commenting functionality with one of the well-known software as a service commenting systems, but somehow I don’t want to force you, my visitors, to open accounts on some third-party system, and I’m trying to be privacy conscious with this website, which I wrote about in this post. For these reasons I chose the Juvia system many years ago. Unfortunately, at some point Juvia became unmaintained, and I found it harder and harder to run a Rails application with outdated dependencies.

Rather than trying to fix Juvia, which some other folks are doing now, I decided to write my own commenting system. (NIH is acceptable when it’s a hobby project.) Today, I’m happy to announce that a first version is in operation on this site and that the system is available as open source software.

Read the rest of this post

Rust: My first impressions

07 September 2018

Posted in Coding

At work I’m seeing more and more embedded software; over the past few years in, among others, coffee machines, forklifts, and cars. Embedded software needs to be fast and extremely efficient with hardware resources. In some cases it not even acceptable to have a tiny break for some garbage collection. So, typical tech stacks for backend development can’t be used, never mind anything that uses browser technologies. Unsurprisingly, almost all embedded software is written in C++, and, in fact, that is also what I used recently for a personal project with a micro-controller.

Now, if you’ve programmed in C++ you probably didn’t find the experience all too pleasant or productive compared to the developer experience we have in modern web development (server as well as browser). I certainly feel that way, and it seems like I’m not alone. Three hugely influential IT organisations, who had to deal with writing code in C or a C-based language, each decided to invent an entirely new programming language just so that they had a an alternative. The organisations are Apple (Swift), Google (Golang), and Mozilla (Rust).

My personal experience with Swift, when I wrote the Dancing Glyphs screensaver a couple of years ago, was mixed at best. I understand that a number of design decisions in the language that annoyed me as a programmer were made to help the compiler/optimiser generate more resource efficient code, ultimately giving the users longer battery life. Looking through the remaining choices, I went past Golang, which uses garbage collection, and set my eyes on Rust.

In this post I’ll describe my first impressions, some of the frustrating moments, but also the extremely impressive performance on a larger piece of code.

Read the rest of this post

The Swift effect

17 January 2018

Posted in Coding

In June 2014, at its annual developer conference, Apple announced that they had created a new programming language, named Swift, to replace the ageing Objective-C as the preferred language for writing applications for Apple devices.

I remember this well because also in 2014 I had decided to revamp the API for OCMock, a testing framework for Objective-C that I have been maintaining for a long time. Most of the work on the framework was done in April/May, and the Swift announcement came just days before the release of the new version of OCMock.

Immediately, I wondered what impact of Apple’s announcement would have on Objective-C and, in turn, on OCMock. Given Apple’s messaging around this, it was clear that most developers would eventually move to Swift. But how many? And how quickly?

Read the rest of this post

Using multiple Github accounts

21 December 2017

Posted in Coding

Two Octocats

Mixing work and private life always brings its problems. That is also true for open source software, and for being a member of the communities on Github. In my case, I have a number of repositories on Github that I would classify as personal; they are not linked to my work at ThoughtWorks. Some of these are significant projects in their own right.

At the same time, an increasing number of clients I work with at ThoughtWorks keep their source code on Github. And to be specific: they use itself, not the on-premise Github Enterprise version. It never felt right to use my regular Github account in such cases, and I experienced real issues because of it. For example, one client regularly ran Gitrob, my membership in their repositories was a link to my non-work repositories, which Gitrob also scanned. Due to the way it works Gitrob has a tendency to report false positives, needlessly causing concern and extra work for the client team.

So, to avoid such issues I created another Github account purely for work. Easy as that? Turns out there is a significant problem; a problem that now has simple solution, but one that is difficult to find.

Read the rest of this post

Builder pattern in Objective-C

01 November 2011

Posted in Coding

Over the past few months I've spent a fair bit of time on a project using my MacBook Pro for development. This got me to run CCMenu again and, perhaps predictably, made me work on that in the evenings. While doing some long overdue refactorings I came across the need to construct domain objects in unit tests. So far I had used simple helper methods in the unit test itself, but the Java/Scala project I was on during the day made heavy use of the Builder pattern with fluent interfaces, and that got me thinking.

In the end I've come up with three variations of the Builder pattern in Objective-C, all of which have their pros and cons. In this post I want to show these patterns and invite comments on which one you prefer.

Read the rest of this post

Call Graph Visualisation with AspectJ and Dot

27 September 2008

Posted in Coding, Visualisation

One of my favourite tools to render graphs is GraphViz Dot and in an earlier entry I described how to use it to visualise Spring contexts. Today I want to showcase a different application.

Call graphs show how methods call each other, which can be useful for a variety of reasons. The example I use here is the graph rooted in a unit test suite, and in this case the graph gives an understanding of how localised the unit tests are, how much they are real unit tests or how close they are to mini-integration tests. In an ideal case the test method should call the method under test and nothing else. However, even with mock objects that's not always practical. And if, like myself, you fall into the classicist camp of unit testers, as described by Martin Fowler in Mocks aren't Stubs, you might actually not be too fussed about a few objects being involved in a single test. In either case, looking at the call graph shows you exactly which methods are covered by which unit tests.

There are several ways to generate calls graphs and I'm opting for dynamic analysis, which simply records the call graph while the code is being executed. A good theoretical reason is that dynamic analysis can handle polymorphism but a more practical reason is that it's actually really easy to do dynamic analysis; provided you use the right tools. The approach I describe in this article uses Eclipse AJDT to run the unit tests with a simple Java aspect that records the call graph and writes it out into a format that can be rendered more or less directly with Dot. Of course, this technique is not limited to creating graphs for unit test; it only depends on weaving an AspectJ aspect into a Java application.

Read the rest of this post

SpringViz and the 1000ft view

13 August 2008

Posted in Coding, Visualisation

The Spring framework has become ubiquitous in the Java world, and there are a large number of tools supporting developers of Spring-based applications. In this post I describe SpringViz; or, more accurately, my variant of it.

SpringViz helps developers with what is at the heart of a Spring-based application, the container and the contexts files that describe the beans. In larger projects these context files can grow quite a bit. Newer versions of the Spring framework introduced features that help reduce the clutter and there are vast numbers of blog posts voicing different opinions on what should and what shouldn't be in a context file but, no matter what, the number of beans in the context files will grow with the size of a project, and at some point it becomes difficult to understand the overall structure. This is no different from trying to maintain an understanding of a large codebase. In fact, I consider the context files to be code rather than configuration.

I've argued before (here and here for example) that to deal with the complexity and sheer size of software systems we need a 1000ft view. This is a view that uses visualisation techniques to aggregate large amounts of data and multiple metrics into one big picture. SpringViz provides that 1000ft view for Spring context files.

Read the rest of this post

Testing Cocoa Controllers with OCMock

04 July 2008

Posted in Coding

For a few releases the Apple development tools have included OCUnit and many developers have now started to write unit tests. There are lots of tutorials that explain how this is done for the straight-forward cases but there's one area of testing that has proven difficult on most platforms, and that is testing of the user interface. That said, there are a few things that make this an easier problem to solve with Cocoa and in this post I'll explain why.

Read the rest of this post