Year: 2017

    Planning the Wind-Down

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    It’s been five years now since, full of enthusiasm and convinced that SuccessWhale might make it big, I bought myself a server in London somewhere, and moved my web presence over from its previous shared hosting.

    I’ve learnt a lot in those years.

    I’ve learnt that despite the “S” in “SMTP”, running a mail server these days is anything but simple. Fighting viruses and spam is challenging, and in particular DKIM is a hassle to get right. I’ve learned that PGP is a nice idea, but I never did find one person to exchange encrypted mail with, or any real reason to do so.

    I’ve learned that LetsEncrypt makes setting up SSL certificates much easier and cheaper, but that configuring Apache to serve 23 HTTPS domains from a single machine with SNI is still difficult.

    I’ve learned that Linux Version Hell will bite you at some point, and Ruby Version Hell doubly so. Today the server runs three separate versions of Ruby, because not all my Ruby/Rails sites can be run with the same one. The www-data user has a home directory just for .rvm.

    I’ve learned that drive-by hackers and DoS attackers will find your server, often within hours of it going online, and that fail2ban and mod-blacklist are the sysadmin’s friend.

    I’ve learned that Open Source community drama can break stuff you depend on, sometimes without a decent way to recover, and every time you do a package update you risk something not working.

    All in all, it’s been a good experience. There have been some frustrating times and late nights fighting with configuration that should just work, but I’ve learned a lot in the process and gained a much greater understanding of how the internet works.

    However, I think it might be time to start winding it down. It’s no longer an interesting new experience, it’s just another thing that I have to keep an eye on and ensure it doesn’t break. Life, I find, is better when it’s simpler.

    As such I am working up a plan to migrate important things to other services over the coming weeks or months.

    • Email, contacts, calendar, file storage and photos I’ve already moved from my server to Google products. I’m no great lover of Google, but having struggled so long with email servers and clients’ spotty DAV support and OwnCloud updates breaking everything, I have to admit it’s so much easier.
    • This blog is based on Jekyll and can relatively easily be moved to GitHub Pages. We’d lose HTTPS support, but I don’t think that’s a major issue. ~500MB of images used by it currently sit on but could be brought into the repository. The challenge is the comments, which use my own Juvia server. There’s no migration path from that to anything, and I do want to keep the comments— particularly on the Raspberry Tank pages—as there’s a lot of helpful information there. Disqus is the logical non-self-hosted equivalent, but there’s no automated way of bringing the comments in. Maybe it’s time to migrate the whole site back to WordPress, since hosted solutions are easier to come by.
    • Software executables can use GitHub’s “releases” feature and be hosted there next to the source code.
    • Everything else on is pretty much junk, bits of it can be shared ad-hoc from Google Drive.
    • SuccessWhale, Can I Call It, Daily Promise, A Thousand Words and Westminster Hubble are effectively dead at this point. They can be taken down and replaced with portfolio pages saying “this is what I once made”.
    • Rimbaud’s House hasn’t been in use for a while anyway, it was a nice project but the camera has not proved useful and I do not trust the sensors enough to introduce full automation based on their readings.
    • Random little things like Marvellator, Terrible Fanfiction Idea Generator and the Business Processes Wiki can be converted to static pages, with JavaScript instead of PHP providing the active content, and hosted somewhere like GitHub Pages.

    A few potential sticking points are:

    • I host three WordPress sites for other people. Two are potentially old enough that they can be deleted or replaced with static pages; the other I could migrate to although that would involve paying extra.
    • My son’s Minecraft server is turned off 99% of the time, but if we do want to bring it back at some point, losing the server would mean losing that capability.
    • I do use the server as a VPN occasionally when on unsecured WiFi, but almost every critical app and website uses HTTPS these days, it’s not necessarily essential any more.

    Farewell to Facebook

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    My blogging history has not been lacking in posts where I consider deleting my Facebook profile. It’s been a common thread throughout that time that Facebook has its advantages (having become my sole practical means of contacting many old friends) and disadvantages (that it is a privacy-devouring monster). In the main, we have been willing to make a deal with the Devil in order to use the vast network of communication possibilities it opens up for us.

    After holding a Facebook account for 10 years, and apparently struggling with whether that was a good thing for at least six of them, today I deactivated my account—a temporary measure to see how it goes, before a potential full deletion in the near future.

    The last straw for Facebook was, as with the last straw for LinkedIn, a matter of privacy.

    Facebook’s “People You May Know” feature is often handy for finding friends-of-frients that you know. Occasionally it recommends someone you kind of know despite not having any common friends, and makes you wonder how the algorithm put two and two together. A little concerning sometimes, but not the end of the world.

    Today, Facebook’s recommendations went from “a little creepy” to “compromising friends’ private medical data”.

    I shan’t name any names, for obvious reasons, but I have a friend who is currently suffering from a particular medical problem. As part of their treatment, that friend has regular appointments with a medical professional, and in supporting my friend, I’ve previously been in contact with that person as well. The friend isn’t on Facebook at all, citing privacy concerns. I have not mentioned anything about them nor their problem on Facebook. And yet today, Facebook’s blissfully context-free recommendation algorithm started suggesting that I add that medical professional as a friend.


    As far as we can tell, what happened is this:

    1. I exchanged an email with the person, via my GMail address.
    2. I have GMail set to remember people I email by automatically adding them to my address book.
    3. I have an Android phone, which automatically syncs my Google contacts, so their email address became stored on my phone.
    4. I have had, in the past, the Facebook and Messenger apps on my phone. I had granted access to my contacts, so they could set contacts’ photos to their Facebook profile picture.
    5. The Facebook and/or Messenger apps hoovered up my contacts and sent them to their server.
    6. The person’s email address matched the one they used for their Facebook account, and so Facebook knew that we had some kind of connection.

    Now, it’s not entirely Facebook’s fault. Some of the fault lies with Google, and a not inconsiderable portion of the fault lies with me for not checking apps’ permissions and privacy policies. However, it’s the Facebook part of the puzzle that made the whole thing creepy, and so, that’s the part that has to go.

    So farewell, Facebook. You’ve made staying in touch with a lot of friends much easier over the last decade, and for that I’m grateful. And I’ve always known that the price for that was that you’d play fast and loose with my own privacy. But when you start to infringe on the privacy—and potentially the confidential medical information—of one of my most vulnerable friends, you crossed the line.

    I’m done.

    Migrating from Jekyll to WordPress

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    The final, and most difficult, part of the plan to wind down some of the more complex stuff I do on the internet was the migration of this site from Jekyll and Hashover to WordPress. It’s a decision I took with some trepidation, as I well remember ditching my old WordPress site for Jekyll (via Octopress) four years ago and enjoying the speed and security it brought.

    However, the workflow is what killed it. The typical “By the Numbers” film review is a shared activity with friends around the TV, which doesn’t lend itself to being sat at a desk at the only computer of mine that can reasonably compile the Jekyll site. I switched to hosting the site on GitHub pages and just editing the pages myself in a browser window, but uploading and linking images was still a multiple step, non-WYSIWYG game of making sure the URLs are all right, followed by a 3-minute compile stage where everyone is waiting to read the finished article and I have to explain why.

    Comments were worse still. I staggered between Juvia, a discontinued Rails application that I was out of my depth maintaining by myself, Disqus which “just worked” but put visitors off commenting, and HashOver where fighting spam involved finding offending new comments via ssh.

    Back on WordPress, things may be slower and security more of a concern, but comments are natively supported, I can drag images in, and preview posts on the fly. No compile stage!

    All in all the process took about 10 hours. If you’re contemplating a similar step, here are some useful hints, as unlike the reverse move, migrating in this direction seems to be a rare activity:

    1. This post was really useful, and RSS export/import does seem to be the best way of moving the main post data across. I moved my pages (20 of them) manually, and used the RSS method for my ~1000 posts.
    2. My Jekyll site had three levels of taxonomy – Collection, Category, and Tag. I believe it’s possible to create the same taxonomies in WordPress, but I didn’t bother. I moved one collection at a time, merged Jekyll’s categories and tags into WordPress’ tags, then Jekyll collections became WordPress categories.
    3. The RSS importer can’t import tags, only categories, so I imported everything as categories and used a “Categories to Tags converter” plugin to sort the mess out.
    4. The Disqus comment importer script from the page linked above worked well for importing a Disqus export, with the exception that Disqus comment and thread IDs are now greater than 2^32. The importer uses these as keys into maps, so I had to subtract arbitrary large numbers from the IDs (which PHP is perfectly happy to do) in order to make them usable as integer keys.
    5. I had a lot of files such as pictures in arbitrary locations which Jekyll is happy to deal with, but WordPress is not. I moved everything into “wp-content/uploads/” with some .htaccess redirects so that they can still be found.
    6. Recreating the Jekyll theme wasn’t too hard, although it took around half the total time. When I first moved away from WordPress its themes were a messy mystery to me, but with four years’ more experience, I can see the parallels between my Jekyll templates and WordPress’ ones, and the transition went very smoothly.

    Although it’s been a few days of working late into the night, I’m happy to say it’s now done. Hopefully the blog will be easier to manage from here on.

    No compile stage!

    Automating the Roast Dinner Timing Chart

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    Against all my expectations, the most popular page on this website (at least, the most visited) turns out to be “The Great Roast Dinner Timing Chart”, which was my attempt to help newbies at the revered British art of the Roast Dinner get their timings right. I first posted it over eight years ago—in the intervening time I have cooked a lot of roasts and tweaked my timings a bit, so it was in need of an update.

    I’ve also cooked roast dinners to serve at all sorts of different times, with variations on the ingredients, so I thought the old list to cook certain things for a fixed 7pm dishing-up time could use some improvements too. To that end, I’ve converted it from a static list to an automatically generated one that users can play with. Visitors to the page can now choose their meat and its weight, the accompaniments and the serving time, and the page will do some JavaScript magic to generate a chart just for them.

    If you’re interested, you can check out the source code on GitHub. It’s not much and not very complicated, but free for anyone to use and modify.

    For anyone who prefers the original non-automated version of the Roast Dinner Timing Chart, or anyone without JavaScript capability, you can still get to the old version here.

    Hopefully it will help someone on the way to cooking their best roast dinner yet! Discontinued as of Today

    This is a post from my blog, which is (mostly) no longer available online. This page has been preserved because it was linked to from somewhere, or got regular search hits, and therefore may be useful to somebody.

    As far as I know, SuccessWhale is not being actively used by anyone any more, so I have chosen not to renew the domain name when it expires today. Like most of my past web-based projects, it will continue to live on at an subdomain, in this case, but will not be actively maintained there.  As well as its graphical web interface, SuccessWhale also has a back-end API that used to run on a SuccessWhale subdomain. This has now moved to The OnoSendai Android client already uses this address for the API as of update 479, so you may need to update.

    Thank you to all the SuccessWhale users over the years!