Thanks to some great work by Daniel Wabyick and his team, Hardy has had a bunch of improvements over the last few weeks.

The biggest change in this version is that, if you have GraphicsMagick installed on your machine, Hardy will use it for native image diffs but fall back to the built-in method if you don't. The current image diff technique involves creating an HTML page with a canvas, opening that with PhantomJS, loading the image into the canvas and using imagediff.js to calculate the diffs. It works everywhere PhantomJS works but it's slow. Daniel benchmarked the difference and it's a huge performance gain if you rely on image diff tests.

There's also some minor improvement around logging and the cucumber report format but I'll write about them later once I've had a chance to update the Hardy website.

Well, kinda. Before giving my Automated CSS Testing talk at CSS Summit in July, I recorded a video of it as a backup. If everything fell apart during my presentation, Ari could seamlessly switch over the One I Made Earlier. Fortunately, the Internet did what it does best and just worked fine.

That means I have an Automated CSS Testing video all ready and waiting that nobody's seen!

Yes, it does get progressively darker as you watch. That's not your eyes playing tricks on you, that's me sitting on my balcony recording as the sun went down.

Due to what are probably very good evolutionary reasons, doodling helps some people concentrate. I'm one of those people.

On Friday I went to CSS Conf EU and, true to form, doodled my notes. I find it also helps if I draw a little cartoon of the speaker. Although they may be of no help to anyone, here are my notes from the conference. I don't claim they are complete or accurate but I can say I had quite good fun drawing them.

• 
• 
• 
• 
• 
• 
• 
• 
• 
• 

While developing the website for Hardy, it seemed obvious that I should be writing Hardy-based tests for it. What better way to figure out how to simplify testing than see what bits of the process were the hardest?

The site is hosted on GitHub using the gh-pages branch of the hardy.io project. I've played with various toolchains in GitHub pages in the past - csste.st uses Wintersmith, for example - but wanted to follow my own best practice suggestions and automate the process of getting an idea from inside my head, through the text editor, through a bunch of tests and out onto production as much as possible. The main Hardy project uses Travis CI to run unit and acceptance tests on every commit so it seemed obvious to use it for this. What I've ended up with is what I think is a nice, simple process. This is designed for sites hosted on GitHub Pages but is applicable to other sites run through Travis,

The manual steps of the process are:

• Make change in your website master branch
• Preview changes locally
• Commit changes and push to GitHub

After this, the automation takes over:

• Travis pulls latest commit
• Builds website project to dist folder in master branch
• Launch web server on Travis
• Run Hardy tests against local web server
• On successful test run, push (via git) to gh-pages branch

The full process is used to build hardy.io. Have a look at the .travis.yml, package.json and post_build.sh files mostly.