Cheap and cheerful uptime monitoring

When I was setting up reyhan.org I wanted to check that everything was working as expected, part of which was ensuring that requests were responding with 200 HTTP status codes, and if not then notify accordingly.

Running the following script using GitLab’s Pipeline Schedules does the job nicely:

A schedule was created to run updog.sh on an hourly basis.

The “build” passes if a 200 status code is returned, otherwise it fails. What’s useful is that GitLab will send an email if a build fails that contains the log output including the HTTP status code :)

How to migrate from Jekyll to WordPress

Last month the decision was made to consolidate years of newsletters, weblog posts and other minutiae from various Jekyll instances to one WordPress-powered deal.

A fair amount of time was spent researching the best, quickest (and easiest!) way to do this but, unsurprisingly, most searches turned up the opposite: migrating from WordPress to Jekyll — anyway — here’s now it’s done:

Jekyll instance

  1. Install the Jekyll Feed plugin.
  2. Do a jekyll build and ensure the generated feed.xml has all the posts that are intended to be migrated.

WordPress instance

  1. Download and install the WP All Import plugin: wp plugin install wp-all-import --activate.
  2. In WordPress Admin, click on the All Import link and upload the feed.xml file generated earlier.
  3. Follow the four-step process to map and import the feed.xml data file into the WordPress instance.

I’d have saved a bunch of time had I been pointed at the WP All Import plugin from the beginning, so hopefully this will help somebody in the future.

Are Google Authenticator accounts saved as part of iOS Backups?

UPDATE: I’ve since had varying results restoring a new iPhone from a backup — your mileage may vary!

TL;DR Creating an encrypted iOS backup in iTunes will back up your accounts held in Google Authenticator.

Having suffered performance issues with the iOS 11.1.1 update, I decided to restore my iPhone to factory settings, then restore from a backup but worried that I would lose the accounts held in Google Authenticator.

Are Google Authenticator accounts saved as part of iOS Backups?

I’m happy to report that if you create an encrypted iPhone backup in iTunes then all the accounts in Google Authenticator will be backed up, and will be present and correct when you restore your iPhone from your backup.

Heroku-style name generator

I put together a bash function to output a Heroku-style name.

The 2013 roundup

Following Karl’s 2013 roundup I thought I’d have a go at my own. This look longer than I expected.

OS X Applications

The only new application here is Moom. I spend much of my time with a fair few windows open and Moon gives me an unobtrusive way to organise windows superquick. I would recommend it in a heartbeat.

I’ve been a user of the rest of the applications since their respective births and they do their jobs admirably.

  • Chrome Canary – for development and surfing the information super highway
  • iTunes – for listening to my music
  • Moom – window manager
  • Pixelmator – image editing
  • Quicksilver – application launcher
  • Terminal – where I spend most of my time
  • Tweetbot – to share what I’m having for lunch
  • VLC – to watch all the videos

Terminal Applications

I’m living in the terminal more than ever and have recently moved my instant messaging and email to the command line. I find it more efficient to jump between tmux windows and sessions than between different attention-grabbing applications. A side effect is that I’m using the mouse at lot less which is better for my wrists.

  • Irssi – IRC client
  • Glances – operating system monitoring tool
  • MCabber – XMPP client
  • Mutt – email client
  • tmux – terminal multiplexer
  • Vim – the text editor of truth

iOS Applications of note

Although I only have two pages of applications on my iPhone I didn’t feel the need to list them all. Here are a small(ish) selection of ones that I use regularly and don’t think I could do without.

Hardware

  • Dell box – an ancient Dell box that runs Debian
  • Filco Majestouch 2 – mechanical keyboard
  • iPad mini
  • iPhone 5
  • Mac Mini – a media centre of sorts
  • MacBook Pro (with Alkr cover) – my primary machine
  • Raspberry Pi – I have two of these and love them for tinkering

Online services

I’m hoping 2014 will be the year I ditch third party email providers and move to a self-hosted deal. I’ve considered different ways to do this but none have struck me as particularly future-proof or time efficient.

tmux

I switched to Vim because I was spending much of my time in a terminal. I’ve been using Screen for many years, mainly for kinda persistant tasks (like running a webcam) but found its performance a bit quirky.

These days I need something more scalable and robust so thought I’d bite the bullet and kick the tyres of tmux. It’s pretty sweet, here is my starter config.

I’m not going to write my own instructions on how to tmux but here are a few links that I found helpful:

Handy links I used to tmux

I’m also currently experiencing a curious bug where in Terminal.app on Mavericks:

tmux 1.8 has a bug that causes it to unexpectedly underline all characters when the status bar requests a bold color.

Colours on Vim and tmux

When using Vim (7.3) through tmux (1.8) I found that the Vim colour scheme looked strange. After much googling this was the solution that worked for me.

Set the following in your .vimrc1:

set term=screen-256color

Set the following in your .tmux.conf2:

set -g default-terminal "screen-256color"

This was very much trial and error3 but seems to work across both OS X and Debian boxes.

EDIT (5/12/13): Since I was struggling to understand colours in the terminal, I emailed the knowledgable @geraintrjones who sent me an excellent explanation (with some brilliant Serengeti animal analogies):

Terminal emulators tell the world about their capabilities with something called a $TERM variable.

The $TERM variable is a label that says “I am this kind of thing” – for instance, OS X’s Terminal.app has its default $TERM set to xterm256-color. You can see this by typing echo $TERM in the terminal. (you might see something else, and this is where the problem starts…)

This doesn’t tell you much on its own, but there is a big database called terminfo that lists all the $TERM variables, and what features something with, say, xterm256-color, supports.

Its like a label saying ‘Elephant’. When you look up ‘Elephant’ in the animal list, you see it has 4 legs, a trunk, and can support palanquins but requires a mahout.

You can see the terminfo entry for your terminal by typing infocmp $TERM (which will look up that terminal’s $TERM in your system’s terminfo database ).

You will see the number of colours listed like this: colors#[number]. xterm256-color for instance, will show colors#256, xterm-color will show colors#8.

This means that OS X’s Terminal.app is telling the world it can handle that number of colours. Applications like Vim see a label saying “I have all the xterm-color features!” and think, “Okay, I’d better give this old timer 8 colours”. Or they see xterm256-color and think, “Lets give this dude 256 colors”.

What should happen, is that tmux reads the $TERM value of your terminal, sees xterm256-color (or similar) , thinks “Okay, that’s a 256 colour terminal” and sets its $TERM to screen256-color. Vim running in tmux then reads tmux’s $TERM and goes, “Cool, I looked screen256-color up and it has 256 colours – let me crack out the 256 colour palettes, like a colourful boss”.

Terminal tells tmux its an Elephant, tmux tells Vim its an Elephant, Vim gets the mahouts out and preps the palanquin.

Whats probably happening is that your .bash_profile is setting a different $TERM – for instance, xterm-color.

Tmux then goes, “Okay, this is an 8 colour terminal, I’m gonna set my $TERM to screen“, which only has 8 colours. Vim then reads tmux’s $TERM and serves up a paltry 8 colours only.

So, terminal is telling tmux its an Antelope, so tmux tells vim its an Antelope, Vim leaves the mahout at home and you don’t get a palanquin, even though you could handle that sh_t.

So by setting set -g default-terminal "screen-256color" in your .tmux.conf, you are telling tmux to always set its $TERM to screen-256color, and then apps like Vim will look that up in terminfo and see, yup, supports 256 colours.

However, your .bash_profile gets run every new terminal right – so it’s run again , overriding the $TERM.

So, telling vim to use a different $TERM, i.e. set term=screen-256color in your .vimrc makes it use the features terminfo lists for screen-256color ,which includes 256 colours. You can use infocmp screen-256color if you’d like to see this.

So Tmux says, its an Elephant, then your .bash_profile changes the label to Antelope – then you have to have Vim tell itself “ignore that, its really an Elephant”.

Only setting the Vim $TERM means tmux isn’t set up for 256 colour, so Vim tries giving 256 and fails. Only setting the tmux one means tmux is loaded for 256, but due to the .bash_profile changing the $TERM, everything thinks tmux is only prepped for 8.

Really, you shouldn’t be trying to override $TERM in .vimrc – because now, whenever you open Vim it thinks it’s in a terminal that has all the screen-256color features. This is only the case when its being opened in tmux!

Really really, you shouldn’t be overriding tmux either – if you make sure your terminal (in this example, OS X’s Terminal.app) has its $TERM set correctly, tmux will read it, see it can handle 256 colors and automatically set its $TERM to screen-256color.

The best solution would be to gently reassure the terminal that it is in fact an Elephant after all. Which probably means nixing a rouge export TERM=xterm-color from your .bash_profile.

TL;DR echo $TERM in a new terminal. If it doesn’t say xterm256-color, go look at your .bash_profile and wipe out any evil export TERM=.

How to webcam on Linux

I wanted to keep an eye on a family pet when I was out the house so installed Debian on an old box and set about investigating the weird and wonderful world of webcams on Linux1.

I stuck both single and multiple webcam configs on GitHub.

My requirements

  1. A webcam that takes a photo on detecting motion.
  2. Keep archive of past photos2.
  3. The most recent photo is uploaded to my server.

What I did

After a bit of a Googling, I decided on a piece of a software called webcam. Here’s how I got up and running:

Install webcam

apt-get install webcam

Create a .webcamrc

touch ~/.webcamrc

Example .webcamrc

Run webcam

webcam

Assuming you don’t get any errors your webcam should now be watching for changes. You can view the latest photo at your.server.com/webcam/capture.jpg and a local archive can be found at ~/webcam.

On investigating webcam software that supported multiple webcams I discovered Motion which seems to be the go-to webcam software for Linux that does all the things. After a day of messing about it with I got it working but found it did way more than I needed it to. I’ll stick my config on GitHub when I get the chance.

EDIT (1/10/13) My Motion config is now on GitHub.

Things I need to add to this post: ssh-agent + ssh-add; how webcam resolution is dependant on whether you’re using one USB bus for multiple webcams; managing your local archive with cron.


  1. When I was younger in the days of Mandrake Linux I did try and get various webcams working, to little success. 
  2. You can do loads of cool things with an archive! Shall experiment with ffmpeg

Redirect common URLs

I’ve previously pointed to thoughts on URL design. I am of the school of thought that a user should be able to navigate and understand your website’s hierarchy from the URL alone.

Continuing on this theme, your website should redirect common URLs.

For example, if a user visits http://example.com/contact, expecting your website’s Contact page where your Contact page actually lives at http://example.com/contact_us.html the user is going to have a bad time and probably a 404 for their trouble.

The solution is to redirect common URLs to their actual locations1.

Here are a bunch of URLs that I would expect to redirect to their respective locations:

  • http://example.com/contact
  • http://example.com/about
  • http://example.com/help
  • http://example.com/tos (or /terms)
  • http://example.com/privacy
  • http://example.com/join (or /signup, /register)
  • http://example.com/signin (or /login)
  • http://example.com/signout (or /logout)

I appreciate the above sounds like common sense but you’d be amazed at the amount of websites that don’t do this2.


  1. You could argue that you should be using these common URLs to start with but, you know. 
  2. It’s at this point I try to play click-the-link when the webpage has infinite scrolling — the rage. 

Thoughts on what I do

This morning I was on my way to work, sat on the train tapping away at some code when an elderly gentleman sat next to me.

At that moment I was completely immersed in what I was doing, in this case trying to figure out why a .json file wasn’t being parsed correctly.

I was getting a direct train but I occasionally change halfway. Distracted by Vim I made the mistake of forgetting which train I was on and got up to change. I quickly realised my mistake and, feeling like a fool, sat back down next to this gentleman who had now taken my previously held window seat.

When I reopened my laptop, the gentleman (who I’ll call Joe) struck up a conversation. He told me that a few months ago he bought a MacBook after many, many years of using Windows.

I asked him why he decided to switch to a Mac after years of using Windows and he told me that his son and daughter-in-law both use Macs and after having a go found them to be more user friendly. That said, he went on to explain that he was still getting used to the OS X operating system.

What was remarkable about talking to Joe was his appreciation of good user interface. He was genuinely excited by OS X and there were times where he dropped to a guilty whisper as he told me something he found particularly brilliant, as if you shouldn’t feel such delight in a user experience.

My motivation for doing what I do is the opportunity to craft experiences that delight. A delightful user interface should not be an exception but the norm.

How to Raspberry Pi

I bought a Raspberry Pi because. Here are a bunch of instructions I used to get up and running.

Get an Operating System

  1. Download an operating system. I used Raspbian “wheezy” which is Debian, optimised for Raspberry Pi.
  2. Plug in your SD card and run df -h to find out the device name of the filesystem’s partition (eg. /dev/disk1s1)
  3. Unmount that bad boy

    sudo diskutil unmount /dev/disk1s1

  4. Get the raw device name for the disk (eg. /dev/disk1s1 => /dev/rdisk1 — ignore the trailing s1)
  5. Write the image

sudo dd bs=1m if=~/Downloads/2012-09-18-wheezy-raspbian.img of=/dev/rdisk1

SSH into the Raspberry Pi

  1. Hook the Raspberry Pi up to the power and internets
  2. ssh [email protected] with the password raspberry

Create new user

  1. sudo adduser your-username
  2. sudo adduser your-username sudo
  3. logout

Login as your new user

ssh [email protected] with whatever password you chose

Delete default pi user because security

sudo userdel -r pi

Update your box

sudo apt-get update
sudo apt-get upgrade

Git commands

A bunch of commands I use, forget and have to Google again.

Save your stash with a handy comment

git stash save "your message here"

See a list of changes the next git push will make

git diff --name-status origin/your-branch

Unstage local commits

git reset --soft HEAD^

Amend most recent commit

git commit --amend

Delete a Local branch

git branch -D your-branch

Delete a Remote branch

git push origin --delete your-branch

Clone a Remote branch

git checkout -b branch-name origin/the-branch-you-want-to-clone

Rename a branch

git branch -m old-branch-name new-branch-name

Reset your Current branch to origin/a-branch (Any changes to tracked files in the working tree since commit are discarded)

git reset --hard origin/a-branch

i miss w

But there was something special about ‘w’ for me. In those days of shared servers I would auto-run a shell script that would parse ‘w’ and highlight my friends and see what they were up to and if they were available to talk. If they were in Pine of course you wouldn’t bug them, but if they were just idle in a shell or working on homework, they were probably up for talking or helping you find some new wares site or want to meet up for a slice of pizza.

I still think there’s something else you can do with status. I just haven’t figured it out yet.

Beautiful URLs

Jim Ray links to a good post by Kyle Neath about URL design (emphasis mine):

Any regular semi-technical user of your site should be able to navigate 90% of your app based off memory of the URL structure. In order to achieve this, your URLs will need to be pragmatic. Almost like they were a math equation — many simple rules combined in a strategic fashion to get to the page they want.

A thousand times yes. I’m reminded of Simon Willison’s notes on a talk Tom Coates gave in 2006 which are still massively valid1 (emphasis mine):

Good URLs should:

  • be permanent references to resources
  • have a 1-to-1 correlation with concepts
  • use directories to represent hierarchy (e.g. subordinate parts)
  • NOT reflect the underlying technology – especially if it might change
  • reflect the structure of the data
  • be predictable/guessable/hackable
  • be as human readable as possible

Good URLs are beautiful and a mark of design quality

Furthermore, a page’s <title> should be a reply to it’s URL.


  1. PDF of Coates’ slides from Future of Web Apps ’06: Native to a Web of Data
Tag: jekyll-import