Manic week at work as we get closer to the release on a big financial site (hence the severe lack of updates here). Took some time out tonight to do some housekeeping.

Finally got around to adding IPv6 after reading various press regarding the increasing scarcity of IPv4 addresses. It’s a little more fuss to setup, but seems to work. Not that I can hit IPv6 addresses from this cable network…

While tinkering with the server, snapshotted, updated and patched everything.

A week ago I added Digital Oceans’ new monitoring beta tool, and it keeps bugging me that this server is using over 60% of its memory. Which doesn’t match what the memory monitor itself tells me on their admin panel. Something else to investigate…

Virgin Media were around today so we have a new 8-tuner set-top box and 200mbit internet. Long (very) story short, it’s taken 6 months to get a new modem from them. But hey, now we have the top tier TV and funky new 8-tuner set-top box too.



There’s nothing like the crunch at the end of a project to find out which processes are really working for you. Agile is a great methodology for approaching a project, but it can easily (and frequently, in my experience) lead to “ticket overload”. This is especially apparent at the end of projects where throughput of tickets is critical as the project rushes towards a hard deadline.

So why the deluge of tickets? Perhaps it’s a sign that something didn’t work earlier on. That QA were onboard far too late, or poorly scoped tickets or poor executed code. Overly ambitious requirements, or fiddly design. All of the above. And some of that is just natural entropy in a project-especially the long run ones where process expands to fill all available time.

It’s not always hard. We’ll do better next time. But sometimes we forget that process is there to help. Not strangle. We forget that we should be hungry to deliver, and delivery is more important than process.

Given a week to deliver something, you find a way to deliver. Any away, whatever it takes.

Given three months to deliver something, process finds a way to trip you up.

I believe in release often. Release small. Real deadlines. Real opportunity for the client to see something to feedback, to catch those changes and design glitches, the bad code or trippy UX. Release every week, twice a week, every other-day. Sit the client down and walk them through it. Show something. Be cool with what you’re showing them. It’s work in progress.

Real agile is iteration. Not invisible sprints without consequence or comment. Breaking a waterfall project into sprint and calling it agile is not agile.


A rolling discussion tonight regarding media queries (breakpoints) and the units to use. em, px, rem? This (zellwk.com/blog/media-query-units) article suggests that em behaves the most consistently across all browsers, but then digging into the comments, there’s a counter argument for px.

I like to use em/rem for elements that are truly relatively scaled. So things like borders and absolutely positioned elements I generally stick to px units.

Personally, I prefer px. em and rem are both relative units, units that scale based on font-size set by the user (or defaulted in the browser). Now take mobile: what if the user is using enlarged fonts. If the media queries (breakpoints) are also scaled because of the units used, how will that impact mobile?

Feels like I need to experiment more around this, but to quote a colleague…

just do what you want and let the browsers deal with the headache

…which frankly, sometimes is a good call.

More… wide…

Screenshot of improved UI for WordPress theme
More… wide.

It’s fleshing coming at a personal project with the learning of some of the big Agency projects of the last couple of years. The techniques learned scale well for this smaller project, but there’s also loads of room for improvement as ever.

Today had a fight with filtering Categories in WordPress. WordPress won. But I will not be beaten forever!


  • I’ve pulled all of the colours from the Sheru experimental theme so it uses just 3 base colours now. The rest are processed on the fly.
  • The site is no longer restricted-width (well, to a point)
  • Content now scales
  • All that gloomy black is gone. Bring on the brightness.
  • Prep for SVG icons.

Live editing

Live editing of themes inside WordPress admin is the scariest thing (but, y’know, awesome). Could so easily fry a site, and it scares me even more to think the number of custom themes must out there in the hands of clients with this feature enabled. Carnage.

So, cough, throwing caution to the wind, made a couple of live edits to this blogs bog-standard theme to filter out these posts from the far more interesting (?) code-tips etc on the front page. Also hid “recent posts” for now. The Project Sheru theme will allow filtering of those, but for now… it didn’t crash.

This is definitely not gitflow.

Project Sheru

Project Sheru: A Pattern Library based modern WordPress theme (and playpen).

  • Truly mobile first (code, UX, UI)
  • Truly responsive (natural visual breakpoints)
  • Accessible (screen reading, WCAG AA+ and ADA)
  • Modern development workflow (grunt + sass, handlebars patterns, clean theme)
  • Prototyping via CodePen
  • GitFlow on GibHub of WordPress theme and Pattern Library

This project has been time boxed for 2 months (February – March).