Live-blogging and Micro-blogging

Exploring microblogging directly from WordPress. I’ve found this style of blogging really useful when working through a problem; a worklog/devlog of sorts so I can retrace my steps (those not covered by git commits).

This looks promising:

For live blogging I also found this free (open source) project.

Screenshot of LiveBlog splash page

My only fear with introducing yet another 3rd party service is over-all reliability.


Renewing SSL with crontab failed

LetsEncrypt SSL certificates expire every 90 days.

Looks like something not quite working with the auto renewal of SSL certs for my person domains. Caught an email from LetsEncrypt warning me that various domains were about to lose their certificates, despite a cron job running on the server.

To edit the crontab (Ubuntu):

 sudo crontab -e

Which now reads:

0 4 * * 1 /usr/bin/letsencrypt renew >> /var/log/le-renew.log

Updated cron to run on Mondays at 4am (using this handy cron calculator).

For reference…

sudo /usr/bin/letsencrypt renew

…will manually renew any certificates that are about to expire.



Deeply nested tables that are purely for layout. Horrible inline styles. He must be building emails…

The problem remains legacy email clients, and the bizarre long tail of support that results in. While desktop browsers have moved on and it has become relatively acceptable to focus support on “evergreen” browser, this move is happening much, much slower for email clients. The result is sprawling legacy code like the screenshot below.

Honestly. We don’t need to support Outlook 2013 do we? I can only imagine (with zero evidence, natch) that anyone still using broken HTML rendering mail clients like Outlook 20XX are doing so because they are in a corporate environment where they are not allowed to update or change their mail client.

But here’s the thing. Most of the clients I’ve worked with are commercial… public facing. How many folks are really using their corporate email client to read personal emails? I certainly wouldn’t be picking up emails from my personal accounts in a locked down environment. I imagine in many environments this may even be against company policy in the first place.

I do most of my email reading on my iOS devices, and it makes me cringe when I look at the size of some of the emails I receive: 90% (possibly another made-up figure) layout crap to support other email clients—clients that almost nobody uses outside of locked corporate desktops.

Modern handhelds have very good HTML email rendering. gMail even supports responsive emails now.

So can we please make this stop?

Screenshot of email markup
Email markup hell


My host (Digital Ocean) provides weekly full-server backups, and I can snapshot on the fly before I make any dramatic configuration changes. But this isn’t really fine-grained enough for a production environment.

Finally got around to doing something about that. All of my code is in GitHub, so I’m only really worried about content – and for that I needed a good, simple solution for WordPress. A place to start at least.

I came across the excellent UpdraftPlus plugin for WordPress, and after some fiddling around, I got it working nicely with my Google Drive account. Initially I wanted to use Dropbox, but frankly Dropbox’s free space is pitifully small. In an ideal world I’d connect any backups to Apple’s iCloud storage… after all I’m paying for a terabyte of it. Sadly, none of the services I looked at support that. Apple! Google Drive with 15Gb storage to the rescue, via the creation of an API key and authorising my web server, the backs are running smoothly.

Not that I’ve tested them yet.

…that’s for another weekend.

Split personality…

Writer Me likes to hang out with fellow writers, share fun links, talk about the process. There’s a lot of  hair-pulling and alcohol involved. Developer Me likes to chat tech with fellow developers, share experiments and talk workflow. There’s a lot of hair-pulling and alcohol involve.

I tend to do most of my tweeting from @shellbryson. This leads to a problem: there are two sets of folks I’m interactive with and 1) when I’m on a roll with writing I’m posting a tonne of writing things 2) when I’m deep in code experiments… Basically I need to pick an audience and stick with it. It’s a marketing thing (sigh).

Yesterday I created a new Twitter account dedicated to Developer Me@sherucode.

Banners and Avatars

New account, new art. I like my wee “sheru” Chibi—a left-over from working with the wondering AnimePicks team a few years back—but the avatar never really fit the developer me. Definitely not the writer me.

Cartoon image of Shell (Sheru)
Shell (Sheru) Chibi

Head scratching, and with zero time to do a full brand, I opted for something playful, but… code-y. What better than to use what I have to hand? Shot with an iPhone, retouched in PhotoShop:

Photo of Lego minifig.

Twitter likes a big banner, so I took another photo of what was literally in front of me… my keyboard. Then off into PhotoShop. Layer masks, blurs and radial fills and masking of letters and we have:

Retouched photograph of keyboard

It was fun to spend some time with PhotoShop again. Working for an agency means I tend to be given designs to implement, rather than having and hands-on during the design process.


Another crazy week as we get into the final few days before launch of a big new financial site at the studio. Meanwhile, I’ve managed to calve out a little time to play with React. I still have an issue with JSX and inlined CSS. It feels like a backwards step, mixing structure, JS and CSS together. All that careful separation of concerns that have been hard-fought over the years seem to somewhat fall aside when it comes to some of the modern framework.

Thing is, React is great. It makes a tonne of sense. It’s really cool to work with.

I’m still unsure how I’d fit it into a project where I care about rendering when JavaScript is not available. I also worry about page weight, given the lump of script that needs to be delivered with a React project. There are of course ways around this—loaders, server side rendering with Express—and certainly as web sites become more ‘app-like’ I expect to see more and more React based sites. The danger though comes from using React (et al) for sites that could be built far more simply using a standard technology stack. Not to mention easier to support.


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 ( 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.