Agile performance testing

At some point in the SDLC it becomes necessary to carry out performance tests to make sure that what you are building will function to an acceptable level. 

There are a few things you can take from this statement:

  1. “at some point” doesn’t have to be the end of development
  2. it should be part of the lifecycle
  3. you have to do it, it’s necessary
  4. tests don’t just happen, you have to perform them
  5. “what you are building” implies that you focus on the things you can control
  6. and finally, “at an acceptable level” means you should have a goal or objective.

In the vast majority of projects, these considerations are left until the end. I think it’s worth discussing the implications of this, as it’ll really help make the tests worthwhile and help you get the most out of the developed software.

Continue reading →

Steam Link and Steam Controller

Finally, after many months of waiting, I received my Steam Link & Steam Controller. For those who don’t know what this is, the Steam Link is more-or-less a wireless HDMI connection with some bells and whistles, a sort of reverse Chromecast. It connects to a PC and streams the display, audio, and controls so that you can use a living room television without having to drill holes in walls and run cables, or move the computer. Because it’s for gaming, it needs to be extremely low latency and for the most part it succeeds. The controller, as you might have guessed if you haven’t already seen one, is a wireless handheld device designed to work with traditional keyboard and mouse games. It too succeeds in some ways, but both have flaws and rough edges that really need polishing to make it appeal to those used to more mainstream offerings from Sony and Microsoft. Continue reading →

A simple link checker built with Rust

I needed a lightweight, simple, fast tool to check a long list of URL links from a plain text file, so I decided to write a small application in Rust. If you’ve not come across Rust before, it’s a high-performance, low-level language that offers memory safety without garbage collection, type inference, and great concurrency support. It’s a young language but shows great promise, and is ideal for this kind of application.

Having produced a simple first version of the application and posted it on GitHub ( I thought it might be useful to look at the code and explain how it works.

Continue reading →

CQ5 developer wiki

I’ve started to put together a public wiki for CQ5 & AEM6 resources, unimaginatively titled ‘AEM Developers’. It can be found at and is hosted on WikiDot. I’m using it as a place to promote links to articles that are useful, a blog roll, and profiles of developers and companies specialising in Adobe AEM. There’s an events section too that hopefully will fill out nicely as time goes on.

Please sign up and add any blogs or links to guides, and add comments to the pages that are already there. You’re all invited.

A reason to calibrate colours on OS X

I don’t really do much image manipulation but I’ve found a great reason to calibrate colours on OS X – to make it easier on the eyes when doing development. The machine I use most is a five-year-old Macbook Pro – nowhere near the display standard on modern machines but tolerable once configured right.

Open System Preferences, and go to Displays. The second tab is ‘colours’, which shows a list of available calibrations. I find the default settings way off on all three Macs I use, too bright and too low gamma making it look washed out.

Hit the calibrate button, enable expert mode, and follow the instructions. Near the end, there’s an option for gamma [I stick to 2.2], and then option for colour temperature. You can click on the labels or move the slider. For development, I find D50 [5000k] is soft on the eyes, whereas D65 [6500k] has a better representation of greyscales. Anything higher than this looks blue to me.

Whatever you do, make sure it’s comfortable for you. I find that unless all my displays are the same colour temperature and gamma, it’s unpleasant to move between machines.