I’ve been in to photography since my Dad (who was a journalist) gave me his Olympus OM-1 SLR when I was a kid, which was released in 1972 and was entirely manual — the battery was optional and only powered the light meter.

Alas, my childhood OM-1 has seen better days.

When I hit 19 or so, I got a part-time job at the now-defunct Jessops camera store, and enjoyed my first income stream and a staff discount, which accelerated my photography interest quite a bit. My next camera was the EOS 3000N, a more modern film SLR. After that, I went digital with the EOS 300D, then an original 5D, then a 7D and after a brief stint with a 60D, I’ve landed with the wonderful EOS 6D.

Now, I’m not actually going to review the camera per se — there are lots of photography review websites far more qualified to do that than me. However, I do absolutely adore this thing — its image quality is superb and it’s beautifully light and easy to carry around. The incredible silent drive mode combined with the amazingly tiny 40mm f/2.8 STM pancake lens allows me to wander around the city and take photos without a bunch of people staring at me — I feel discreet with this setup, which is something I haven’t felt in years.

“I’m not fat, I’m just full-frame!”

However, this camera is the first SLR I’ve purchased that has a built-in shelf life on some of its features, which makes me slightly uncomfortable.

The March of Technology

I have a sort of love-hate relationship with technology, specifically computing technology. I’m a programmer, so obviously computing technology and I are intertwined, but I’m a firm believer that if the user is conscious that their machine has computers in it, the designers failed unless the product is specifically advertised as THIS IS A COMPUTER.

Let me give you an example. I’ve been fortunate enough to own several different cars so far in my life, and by far my favourite is the Mazda RX-8. The RX-8 is designed to be a mechanically brilliant car, and excels in this area — you can hurl it around the track like a madman and it’ll just lap it up and egg you on. When you’re driving, it’s all mechanical — a stubby gearstick sticks up directly from the gearbox, the steering has a very direct connection to the road, and on the dashboard you have a thing that tells you how fast the engine is going, another thing that tells you how fast the car is going, and not much else.

The RX-8’s dashboard.

Underneath this is an incredible amount of computing power trying to make sure I don’t slam face-first into the nearest wall — computers making sure the engine is mixing fuel correctly, computers to make sure the car goes in the direction I tell it to, and so on. However, back in the cockpit all you’re doing is giggling wildly as this glorious heap of metal seems to defy the laws of physics as it propels you around the twisty piece of Tarmac that is whatever racetrack you’re on, and there’s absolutely no indication in the car that there’s all this computing going on behind the scenes unless something goes wrong.

And that’s the way it should be.

Isn’t this supposed to be about a camera?

So, how is this relevant to the EOS 6D? Well, to me, cameras are like cars (and washing machines, toasters, fridges, etc) — they’re appliances designed to do a certain job. Your relationship with them is physical, and all of the control is done through the manipulation of buttons, switches and levers, not touch-screens or keyboards and mice. Sure, they’re computers on the inside, but if I’m conscious of that then something has gone wrong somewhere.

The 6D’s chassis (photo credit: Canon).

This is a physical device which I use to make photographs. Sure, it has a computer inside it, but that’s a detail you don’t care about — the specifications talk about the image quality and how well the camera stands up to rain, not gigahertz and RAM. In ten years, I should still be able to use it to take pictures and as long as I can get them out of the camera and into my computer, I’m set. The computing technology in this thing has one job — to help the user create the best photos they can.

It makes me slightly uncomfortable to switch on my camera to see this:

I’m not actually 100% sure why this feature irks me so much. The WiFi feature of the camera is incredibly useful — I can connect it to my computer or phone and shoot and preview shots wirelessly. However, seeing Facebook and Twitter icons on this thing crosses the line from an appliance to a computer. Before, my camera longevity concerns were all physical — how long will the shutter last? What happens if I get it wet? What if I drop it?

Now, I get to think about stuff other than my camera when thinking about my camera. Twitter are notorious about being strict with their API — what if it changes or goes away? What if Facebook goes the way of every other social network before it? That’s fine on a “big” computer — I’m already conditioned to have to update and change the software set on it, but my camera? It’s a metal box with buttons and switches on it, and I shouldn’t have to deal with “computer crap” like this.

Conclusion

Well, the EOS 6D is a great camera and you should all go buy one. However, seeing features like Facebook and Twitter integration in it make me worry about a future filled with appliances whose feature sets have shelf lives. It’s not just this camera, though — the whole industry is going this way, even cars. The Tesla Model S has Google Maps built right into the dashboard, for example.

My Olympus OM-1 is still exactly as functional as it was when it came out forty years ago. Will I be able to say that about my 6D forty years from now? How about if I bought a Model S? It seems that as technology advances, previously immutable appliances like cameras and cars are getting caught in the net of rapidly obsoleting technology.

Then again, maybe I’m just getting old. My first camera didn’t even require a battery, so obviously my idea of what a camera should be is biased towards a mechanical interface, and memories of mechanical cameras are going the way those of the floppy disk are.

Well over a year ago, I blogged about starting a project in which I replace a radio-controlled car’s guts with an Arduino and have it be able to navigate to a given GPS location.

Well, that project is finally underway.

Hardware

It very quickly became apparent that an Arduino wouldn’t cut it for the kind of computational work I want to do, mainly because of the tiny amount of RAM it has. I ended up with a pairing of a Raspberry Pi and an Arduino Uno. The Arduino’s job is to interface with the various sensors on the car and pass that information back to the Pi, which has a lot more resources for doing computation.

Note: This chapter is a fairly quick overview of how the car is put together. You can find a shopping list with exact components at the end of this post.

Arduino

The Arduino has a prototype board attached to it, which on the underside has two three-pin connectors for connecting the car’s servos (one for speed, one for steering). The car’s speed controller is connected to the battery and provides the Arduino with power.

The top of the board (which is very messy — I intend to build a much neater one) hosts an accelerometer as well as a few cables for powering the Raspberry Pi, powering the Ultrasonic Sensors and reading data from the Ultrasonic sensors.

Black: Raspberry Pi power, Yellow and white: Ultrasonic sensor power, White four-lane: Ultrasonic sensor data, Raised red board: Accelerometer.

There are four Ultrasonic sensors mounted on the car’s body — three at the front and one at the rear. All the cabling for these sensors end up at a pair of connectors on the inside of the roof, which allows the body to easily be separated from the chassis when needed.

Leaving the body clear so you could see the electronics seemed like a good idea at the time, but instead it all looks messy and is really hard to photograph. Lesson learned!

The Arduino and prototype board are mounted inside an Arduino case that’s attached to the car’s chassis with zip ties. The case has a lid, but I’ve left it out of the photos to illustrate what goes there.

The vertical posts support the body, which rests on the clips. They can be raised to give more room.

Raspberry Pi

The Raspberry Pi is mated with a UI module from BitWizard, which hosts a 2x16 character LCD display, six buttons and a few breakout connectors for various serial busses.

Raspberry Pi with attached UI module. The garbled character to the right of the up arrow should be a down arrow, but there seems to be a bug in my custom character code!

The Raspberry Pi connects to the Arduino twice — once for power from the Arduino and once via USB to communicate with it. When it’s all assembled, it gets rather messy!

Thankfully, with the body on, it’s a lot cleaner. The final part is to find a housing for the Raspberry Pi and a place to mount it on the car itself.

Here’s a diagram of how everything fits together. Clear as mud!

Software

Arduino

The Arduino is running a very simple loop that polls the attached sensors and writes their values out to the serial port. ACCEL: lines are accelerometer readings in G, and DISTANCE: lines are ultrasonic sensor readings in cm.

1
2
3
4
5
6
7
8
9
10
11
12

ACCEL: 0.06,0.05,0.89
ACCEL: 0.07,0.05,0.90
ACCEL: 0.07,0.05,0.90
ACCEL: 0.06,0.05,0.90
ACCEL: 0.06,0.05,0.88
DISTANCE: 89,111,32,15
ACCEL: 0.07,0.05,0.89
ACCEL: 0.07,0.05,0.90
ACCEL: 0.07,0.04,0.90
ACCEL: 0.07,0.05,0.90
ACCEL: 0.07,0.06,0.90
DISTANCE: 89,111,32,15

Sample Arduino output.

In addition, the Arduino listens for input on the serial port for setting speed and steering values for the servos. This is not unlike the protocol used in my Arduino LED project, with two header bytes, a byte for the steering angle (0 - 180), a byte for the throttle angle (0 - 180) and a checksum byte.

Main Software Stack - Raspberry Pi

Everything so far is just enabling the main software stack of the car to observe and interact with the hardware in the car.

The main software stack is written in C# against the Mono Framework. I chose this setup because it’s pretty much the only nice Object-Oriented language available with a fully featured runtime available on multiple platforms (of course, there’s also Python and Java, but I prefer C# over those two). This setup allows me to write and debug the code on Mac OS X, then copy it over the the Raspberry Pi running Debian Linux for real-life use.

At the moment, the software stack is at the point where it’s a fully functional object model wrapping all of the implementation details of the car:

• The Sensor class tree provides objects representing the various sensors on the car, providing events for when their readouts change.

• The Servo class provides getters and setters for adjusting the servos on the car.

• The SerialCarHardwareInterface class implements the ICarHardwareInterface, which defines various methods for getting the sensors and servos on the car. This is split out into an interface for when I need to implement a mock car for testing AI routines without risking damage to my car or other property (it goes quite fast!).

• The CarHTTPServer class provides a simple REST API over HTTP to allow other computers on the network to observe the car’s sensors. This is great for writing tools to visualise the car’s status graphically.

RCSensorVisualizer showing the car’s accelerometer (top) and distance (bottom) sensor readouts graphically.

• The CarEventLoop class runs a dual loop for running AI code. The first loop is a low-latency loop that monitors the car’s sensors, which can have interrupt handlers attached to it — simple classes that decide if execution should be halted, for example if the car turns upside-down. The second loop runs on a different thread and is where the main AI processes will take place. This dual setup allows the car to detect if it’s upside-down and halt operation even an AI process is taking a long time.

• The I2CUIDevice class provides an interface to the screen mounted to the Raspberry Pi, allowing text to be written to the screen and firing events when buttons are pushed.

• The MenuController class as friends provide logic for presenting a menu system on the display, allowing menu item selection and navigation, as well as “screens” for presenting information or prompting the user to confirm a chosen action.

Bringing It All Together

Below is a video showing the whole lot working together. I scroll through the menus on the Raspberry Pi and observe sensor readouts as well as adjusting the steering and throttle.

The project is now ready for its next steps, which will be writing AI code to have the car navigate its surroundings. It doesn’t have GPS at the moment so it’ll be limited to “drive forwards and don’t crash into stuff” for now, but it’s a start!

You can find the code for this project over on my GitHub. It includes the Arduino Sketch, the C# software stack for the Raspberry Pi and and Objective-C Mac application for observing the sensors.

Shopping List

The project at the moment uses the following hardware:

• 1x Dual Hunter Monster Truck (Tamiya.com).
• 1x Raspberry Pi (RaspberryPi.org).
• 1x Raspberry Pi UI Module with 16x2 LCD (BitWizard.nl).
• 1x Arduino Uno (Arduino.cc).
• 1x Arduino Proto-shield (Arduino.cc).
• 1x ADXL345 Accelerometer (SparkFun.com).
• 4x SRF05 Ultrasonic Sensor (Robot-Electronics.co.uk).
• A ton of wires and stuff to link them all together.

There’ve been a few posts* floating around the internets recently discussing some rules about when to use Objective-C or not, mainly focusing on performance but touching on code readability and maintainability too. These posts are all written by intelligent people who make reasonable arguments, I get a rather uneasy feeling reading them.

For a little while I couldn’t place it, but today it came to me — these posts, to me at least, seem to be looking at the problem (or lack thereof) too closely, citing small code snippets and “rules” on how to fix them with the correct choice of language.

* Specifically, point 6 of that post.

Clarifying the Problem

Now, the discussion has become slightly muddled between two issues - one is that Objective-C’s runtime is slower than some other runtimes (like, say, C), and the other is of code efficiency. Since a method call has more overhead in Objective-C, inefficient code is affected more than that same code in C, so people jump to the conclusion that Objective-C is slow and the followup fix is to move to C.

Inefficient code will always be slow. However, since a method invocation has more overhead in Objective-C than C, C++ or most other static runtimes, people who’ve just learned about the Objective-C runtime will often blame the runtime and switch to C.

Unfortunately, I need to be blunt here: If you think your code is slow because Objective-C is slow, you’re wrong. Your code is slow because you wrote slow code.

The Bigger Picture

In day-to-day programming, you may end up in a situation in which you’re looking at objc_msgSend and thinking that Objective-C is too slow. If this is the case, there are only two outcomes.

1. You wrote inefficient code and need to go fix it. It sucks, but this will be 99.9% of cases.

2. You screwed up big-style and Objective-C genuinely isn’t the correct tool for the job at hand. This sucks even more, because you misunderstood your problem and now have to scrap all of the Objective-C code you wrote and write it again in something else. This will be very rare.

Thinking about one implementation detail in your runtime (and with Objective-C, that invariably becomes objc_msgSend) is not thinking about the bigger picture and you’ll go down a horrible road of writing little sections of code in C, copying data back and forth between the two runtimes and creating a big horrible mess. You’ll start thinking things like “Accessing this instance variable directly is way faster than using Objective-C properties. This’ll make my app fast!”, and will fall down that horrible trap of pre-optimising stuff that doesn’t actually make a difference.

Instead, you need to be thinking about the behaviour of your runtime and how it affects your problem. Ideally, you should do this before starting to implement your solution to that problem.

Problem 1: I looked at Instruments and objc_msgSend is 10% of my application’s usage!

Is your application actually slow? If not, who cares? If you’re making a lot of method calls, this is to be expected.

This problem has nothing to do with the Objective-C runtime.

Problem 2: I profiled my application when it’s acting slow, and it’s some Objective-C code slowing it down!

Make your code more efficient. Depending on the nature of the problem, one or more of these might help:

• Stop doing obviously silly things. Loading huge images lazily on the main thread, for instance.

• Learn about complexity and how to write more efficient code.

• Learn about perceptive performance. For example, if you do your work on a background thread and keep your UI fluid in the meantime, your application won’t feel slow. It’s better that your application remains fluid and takes ten seconds to do its work than it locking up for five seconds. Five seconds is indeed faster, but it feels a lot slower when an application’s UI is blocked.

This problem also has nothing to do with the Objective-C runtime.

Problem 3: I’ll be working in a realtime thread and I’m worried about the fact that Objective-C is a dynamic runtime!

Aha! Now we’re getting somewhere.

Objective-C isn’t slow. It simply isn’t. However, one thing that it is is dynamic. Objective-C’s dynamic runtime gives it all the wonderful features we adore, but it isn’t appropriate for some uses.

Real-time threads can be one of those uses.

But not because Objective-C is slow.

Because it’s dynamic.

A good example of a realtime thread is a Core Audio render thread. When I get that callback from Core Audio asking me for more audio data to play, I have x milliseconds to return that data before the audio pipelines run out of buffer and an under-run occurs, causing playback stuttering.

Because that number is measured in milliseconds rather than nanoseconds, Objective-C would be perfectly fast enough to perform it. In fact, if I wrote my audio code in Objective-C it’d likely work just fine. However, because I’m under contract to return data in a certain time, I can’t safely use a dynamic runtime like Objective-C to implement it.

C, for instance, has a static runtime and a fixed overhead for method calls. Copy some stuff to the stack, jump to the function’s memory offset, and away you go.

Objective-C, though, is dynamic and you can’t guarantee a thing. Anyone can load a class into the runtime that overrides -methodSignatureForSelector: and redirects your method calls elsewhere, or can use something like method_exchangeImplementations() to swap out method implementations entirely. This means that at runtime, you can’t count on anything being what you thought it was.

So, because I’m under contract to return within a certain time and I personally believe it’s bad form to use a dynamic runtime in such a situation, I choose to implement that problem entirely in C.

Conclusion

The decision to use the C language for problem 3 was entirely a high-level decision based on the behaviour of the Objective-C runtime compared with the problem at hand.

This is really how you should be thinking about your runtime. If you get to the point where you’ve got some slow code and are noticing an implementation detail of the runtime pop up, you need to go back and code better. If you’ve coded the best you possibly can, you need to learn to code better. If you’ve learned to code better and the runtime is still getting in the way, you chose the wrong runtime for the entire problem.

Notice that this entire post is devoid of any code samples. This is intentional — the point of this post is that you choose your language and runtime first based on your problem, not second because of a problem in your code. If you’re switching languages and runtimes halfway through a problem, the issue is your approach to solving the problem, not the language or runtime you’re using to solve it.

In 2005, two things happened: I bought a kickass car, and Aperture 1.0 was released at the rather eye-watering price of £349. At the end of the year, I was playing with Aperture’s photo book tool by putting some pictures of my car in a book and inadvertently started a tradition I simultaneously despise and adore: My Life In Pictures.

Every year, I make a photo book of the interesting stuff that year brought — an interesting outcome is that a book’s thickness is a great way to see how interesting a year was for me. 2009 is an embarrassing 35 pages, whereas 2008 and 2006 are both pushing 100.

I despise them during the construction phase because they take an age to make — over a week of evenings for a long one. By the end I’m so sick and tired of looking at those damn photos I hesitate to buy the book I put together. Thankfully I’ve learned to push through that feeling and order, because every single time a book arrives I adore the result and happily add it to the slowly expanding collection.

Inside 2012 In Pictures.

These things are expensive — 2012 In Pictures is 63 pages and ordered through Blurb, which came to around €55 plus tax and shipping. However, they’re well worth it and I’m already enjoying going back a few years ago and flicking through what I did in the past. They also make great gifts for family members who are into that sort of thing.

My Aperture library is over 15,000 photos strong, which isn’t huge, but it’s enough photos to make proper storage and tagging important.

My Aperture library is organised by Category, then by year (maybe), then by “event”. For example…

• Events
  • 2010
  • 2011
  • 2012
• Holidays and Trips
  • 2012
    • WWDC 2012
• People and Things
  • House

This seemed like a good idea to start with, but it’s actually fairly terrible. For example, I want a photo from WWDC 2012. Is that in Events or Holidays and Trips? I mean, it’s a “trip” for me, but WWDC is actually an event! This wishy-washy organisation isn’t so helpful when you’re trying to find photos from years ago. This, coupled with a complete lack of manual tagging, is a pain to work with.

A Fresh Start

After my previous post discussing Adobe Lightroom, not three weeks ago, basically concluded that I prefer Aperture, well, I’ve decided to slug it out a bit longer with Lightroom and do a long-term test.

On January 1st 2013, after waking up in the afternoon and noting that 2013 was in no was different to 2012, I launched Lightroom and pressed the “New Catalog” button. Starting then, I’d be using Lightroom for all of my photography work instead of Aperture, something I wasn’t sure would be a smart idea considering I didn’t actually like the program all that much. (I’ve since come to like Lightroom much more, but that’s for another post).

New year, New photo library!

With this fresh new start, I’m determined to start and keep up with a photo library that allows me to find my photos reasonably quickly and with as little frustration as possible. My library should meet the following criteria:

1. I shouldn’t be spending more than a few seconds per photo on import to get the metadata to a state of meeting the rest of these criteria.

2. A good portion of it should be automatable, if possible.

3. The metadata should allow me to, in the future, filter down my library to a reasonable number of candidates for the photo I’m actually looking for.

4. The data input for each photo must conform to a defined schema to keep metadata consistent.

My rationale behind the first entry is that if metadata input takes too long, I won’t bother doing it. The second entry helps the first become more of a reality. The third is a realisation of the first two — if my metadata entry isn’t taking very long, it won’t be that comprehensive, but if I can filter my 15,000 photos down to 150 candidates I’ll be able to find the photo I’m looking for manually in not too much time.

The last entry is to try and combat “tag creep”. I’ve seen this a lot, especially on blogs, where people just type in tags as they pop into their head. For example, in the photo above, well, it’s night. And there are fireworks. Oh, and trees. And clouds! night, fireworks, trees, clouds actually seems like a reasonable set of tags. However, my next fireworks shot is on the next night and there’s only one firework and it’s a starry night. night, firework, trees, starry. The only two tags those photos have in common are night and trees, neither of which are material to the photos! Clearly, we need a well-defined way of tagging photos.

It’s all about the questions!

Earlier this evening, I tweeted asking others how they organised their libraries, and quickly learned that everyone is different, and nobody seems to have a catch-all solution.

So, I started thinking about what I should tag my photos with and didn’t get far. Then, I started thinking about how I try to find photos once they’re in the library. That’s when I started getting somewhere — and I started listing all the questions I ask myself (and my photo library software) when trying to find my photos. Then I remembered that damnit, if I’m putting this effort into cataloging my library, the computer should be asking me the questions!

This brainwave has completely flipped how I think about metadata — it isn’t for finding the photo you want, but for dismissing the photos you don’t want.

The list below isn’t the questions I ask my computer to find photos — it’s the questions I want the computer to be able to ask me to get rid of the photos I’m not interested in:

Where did you put the photo on disk?

I’ll get this out of the way quickly — when trying to find photos, I never think about my computer or any detail of it. Therefore, I don’t care where my photos are on my computer. I let Aperture/Lightroom deal with them as they’d like to, and make sure I have backups. Hard drives, folders and filesystems are things for computers to deal with, not me. Therefore, I don’t use custom folder names or anything crazy like that.

What did you name the photo’s file?

Similar to my previous point, filenames have no hope of being helpful and I never think about them. There’s no way they can contain enough information to be useful, and one day you’ll encounter a USB stick formatted as FAT16 and you won’t be able to put your crazily-named files on it. I’ll let my computer deal with that and not care myself.

When did you take the photo?

Thankfully, assuming you have your camera’s clock set correctly, this is a non-issue. Time and date metadata is already present in my photos. Hooray!

Where did you take the photo?

Location, in my opinion, is one of the most important pieces of metadata a photo can have, even if it’s not that accurate. Hell, especially if it’s not that accurate! For example, I remember seeing an awesome car when I was a kid somewhere in France. That’s enough information (France, 1985 - 1995, Car) to filter out 99% of my library!

I already geolocate my photos in two ways — if I was out and about snapping away I’ll manually geolocate as best as I can when I return. Even if I find a year-old picture on some motorway in Germany, I’ll geolocate it to Germany and be done with it.

If I’m going on a photo walk — that is, a walk or similar with an express intent to take photos along the way - I’ll bring my bike’s GPS with me. It’s a Garmin Montana, and I specifically chose that rather expensive model because the battery lasts up to 16 hours. I can switch it on, throw it in my backpack and when I get home I have a trace of where I’ve been all day. Both Aperture and Lightroom contain tools to link this trace to your photos, automatically and accurately geotagging the day’s photos in an instant.

What is in the photo?

This one is a bit more difficult. Photos always contain lots of things. The photo above contains fireworks, the sky, clouds, trees, people, street lamps, buildings, snow, gravel, probably a mouse hibernating under a bush somewhere (Note: mice probably don’t hibernate in bushes), a bench, etc etc etc.

However, I never care what’s in the photo when looking for it. I care what the photo is of, and that photo is of fireworks. However, as discussed above, telling the computer what the photo is of can quickly get messy.

Instead, I’ve decided to distill this question down further, to a simple yes/no question:

Is the photo of a ______ ?

This way, tags can always be singular. Is the photo of a firework? Is it of a tree?

What environment was the photo taken in?

Sometimes, I want to find some pictures I know were taken at night, or in the snow, or both. Adding a tag for this would be useful!

Browsing

Sometimes, rather than searching for specific photos, I want to browse through all of the photos I took at, for example, WWDC 2012. In addition, I often keep a photo reference of progress on various projects such as my railway or robotic monster truck.

To allow this, I’ll continue to organise my photos by year, but rather than vague top-level folders I’ll stick with three: Projects, Events & Trips and Photography, the latter reserved for photos where the sole point of taking the photo was to make a beautiful photo.

Additionally, sometimes I want to browse (or share) my favourite photos, either because they’re photos I’m proud of technically or they just remind me of something amazing. For this, I’ll use the star rating system — typically photos in my library are ★★★★★ or nothing.

“Port of San Francisco”, a photo I consider ★★★★★.

The Metadata Schema

Based on these questions and the above criteria, I’ve settled on the following metadata schema on top of the metadata already added to the photo by the camera:

• Location, as accurately as possible.
• One tag for the environment (examples: Indoors, Snow, Rain).
• One tag for the subject matter unless it’s a photo of people, which must be singular (examples: Plane, Car, Landscape).
• One tag per primary person in the shot (examples: Tim, Chester, Me).
• If the photo was taken at night, the tag Night.

This metadata schema is quick to enter and will allow me to filter down my library fairly accurately based on the questions I typically ask when searching for photos. It’s also intentionally very restrictive to avoid tag creep — I don’t want to be entering twenty tags per photo in a year’s time as I slowly start adding more things in.

As for whether this will work, well, only time will tell. It can’t be worse than it was before, right?

So, you’ve decided that it’s time to do proper backups!

If you haven’t decided it’s time to do proper backups, you’re an idiot wrong. All drives, spinning, SSD or otherwise, have a spec called Mean Time Between Failures or MTBF. This is the average time a drive can be expected to work before it fails. Like brake discs on a car, they’re expected to wear out over time. Not fast, but they’re certainly expected to stop working.

Fortunately for you, my dear readers, I have the experience to help! Quoth my friend Tim:

You have, by far, the highest drive failure rate of anyone I know, and I work in a data centre with 1000s of them.

He’s quite right — over the past couple of years I’ve had two spinning disks and one SSD completely die on me. The spinning disks were in an always-on Mac mini and I finally cottoned-on to the fact that laptop drives aren’t designed for continuous running and the head generated therein, and the SSD succumbed to the dreaded 8MB bug that affects cheaper Intel SSDs, which isn’t as “fixed” as they claim.

Still, as a result I’ve gotten my backup regime to the point where the worst part of a drive failure is the effort of buying and replacing the broken drive, and the boredom of watching the progress bar slowly inch forwards as the restoration is done.

If my apartment building catches fire and all of my drives are lost, then the restoration process isn’t so smooth and I don’t have 100% data coverage, but I’ve got the important stuff covered.

I’ve also found a few tricks to ease the pain of restoring, which can be found below. A backup is useless unless it restores properly!

Local Backup

My local backup uses Time Machine to a Drobo connected to a Mac mini that’s at the other end of my apartment. The Drobo can survive a drive failure without breaking a sweat, and there’s a couple of fire walls between the two machines, so if a small fire breaks out with luck one of them will survive.

The Time Machine backup isn’t bootable, so if you’re in a situation where you’d need to carry on using your computer in as little time as possible, consider something like SuperDuper! or Carbon Copy Cloner to keep a live, bootable backup.

Offsite Backup: Online

For offsite backup, I backup my most important stuff (my Documents and Photos folders) online, which totals around 230Gb at the moment. Backing up everything isn’t very economical since it’d take too long, and I could live without most of my other stuff anyway, or get it from somewhere else.

My online backup uses Arq to backup to Amazon Glacier, which I just moved to using instead of Amazon S3. Amazon Glacier is cheaper than S3, but doesn’t have instant access to your data — you may have to wait a few hours between requesting your data and being able to download it. My logic is that if I’m in a situation where I need to recover using my online backup, having to wait a bit will be the least of my worries. Arq supports both S3 and Glacier just fine, so you can use whichever service you prefer.

There are also services that provide online backup solutions, such as CrashPlan, Mozy and many more. However, you have to trust them not to screw up (and going by a friend’s recent experiences, that’s not something you should do lightly). If they go out of business, bye-bye data. However, I trust Amazon not to go out of business any time soon, and Arq backs up using a documented format and there’s even an open-source command-line restoration tool on GitHub, so even if Arq stops being made, I can still get at my data.

Then again, these services do offer some great features such as mailing you a restoration DVD or hard drive if you have a slow internet connection — it’s up to you to weigh up the pros and cons of each method.

Offsite Backup: Offline

If you want everything safely offsite, or online backup isn’t feasible due to a slow internet connection (or both), you’ll want to start physically moving disks around. I don’t do this, but a good solution would be to have two separate backup disks and rotate them. For example:

• Have Time Machine (or whatever) backup to disk 1. Put disk 2 offsite somewhere, like in a locker at work.
• One week later, take disk 1 to work and bring disk 2 home with you.
• Have Time Machine backup to disk 2.
• One week later, take disk 2 to work and bring disk 1 home with you.
• Repeat forever!

As of Mountain Lion, Time Machine supports backing up to multiple disks properly, so swapping them out once a week will be seamless. With this setup, if your house catches fire and you lose everything, the worst case scenario is that your backup is a week behind.

Easing Restoration

For local restoration, there’s a few things you can do to make the restoration process a bit easier:

Getting the Operating System Running

If you have a modern Mac, it has a feature called Internet Recovery that allows the machine to download and install Mac OS X onto a completely blank drive.

However, if you don’t have a fast internet connection or if your Mac doesn’t have Internet Recovery (like my iMac), you can do what I did — I set up my Mac mini running Mac OS X Server (which is now a cheap add-on to Mac OS X from the App Store) to act as a NetInstall agent. It’s a really simple process — an assistant will ask you for a Mac OS X installer either from the App Store or an install DVD and convert it to a NetInstall image.

NetInstall images appear as any other startup disk would.

Once this is done, any Mac capable of running the Mac OS X version you’ve made an image of can boot up and install Mac OS X without having to hunt around for installation media. Simply connect your Mac to the same network as the server and hold Command+N as you switch it on.

Note: When installing over NetInstall, don’t be tempted to do it over WiFi. It’ll be slow and painful!

Double Note: NetInstall isn’t the same as NetBoot. NetBoot allows you to boot up a computer normally over the network, which isn’t the same.

Getting Yourself Up And Running

If you’re happy to leave your computer churning away for hours while your backup is being restored, simply have it restore “normally” through Time Machine or your backup software of choice. Your computer will be out of action for the duration of the restore, but it’s simple and your computer will be just like it was before this whole mess started.

However, if you’re like me, you’ll be impatient and will want to start doing stuff with your computer as soon as possible. Please note that this is a very advanced technique, and I’ve purposefully left the instructions vague to dissuade people from doing it. If you don’t know how to do any of the steps I detailed, you should just let your Mac restore fully through your backup software.

• Using your backup solution, restore as little as possible to get a functioning computer that includes your user account but not the contents of your Documents, Photos, etc folders.
• Log into your empty user.
• Start manually copying things from your backup into your home folder.

Using this technique, you can get up and running really quickly while your massive photo library restores in the background. However, it’s critically important that you restore your user from backup, as both the UID and UUID of the user on your computer must match the one in the backup otherwise you’ll get permissions problems.

The last thing to do is to copy the Library folder. This is invisible by default, and replacing your Library folder of the current user is a bad idea. Therefore, you need to:

• Copy the backed-up Library into your home folder with a new name, like “Library-New”.
• Reboot your Mac into Recovery Mode by holding Command+R as you reboot.
• In the Terminal in Recovery Mode, delete your user’s Library folder and move the “Library-New” into its place.

When you reboot normally, your user will be a mirror of what it was in the backup.

Last Words

The problem with backup is that it’s boring and a pain in the ass. What makes it worse is that computers are very good at hiding the fact that drives are, basically, starting to fail the day you buy them — they’re black boxes of electronics that people assume will keep working.

I’ve gone through enough drive failures to feel incredibly uneasy if my important data is in less than three places — my computer, my local backup and my online backup. Unfortunately, I only got this way by suffering data loss when a drive failed years ago and I had no backup.

If you’re reading this and haven’t already started backing up, I’m sure this advice and all other advice about backups will fall on deaf ears. However, once you do suffer data loss, I hope you come back to this article and that it’s useful for next time.

I’ll leave you with this final thought:

Close your eyes and imagine what you’d do if you went to switch on your computer and you found that it’s drives were completely blank. All of those thousands of hours poured into documents, all those photos of your friends and family, all gone. Forever.

If your answer is anything but “I’d buy a new drive and restore from my backup”, you’d better read this post again while buying external hard drives on Amazon.

As I’ve grown older (and I’m aware that, at 27, I’m not actually allowed to claim that I’m “old” yet), I seem to have settled into a middle ground between the random person on the street that doesn’t know what a browser is (YouTube Link) and full-out fanboy — something I like to call the educated fanboy.

The Educated Fanboy is someone who, like a normal fanboy, is completely fanatical about the things they choose to use. They research their product(s) to an insane degree, and end up knowing more than is useful (or even healthy) about the companies and products involved. However, unlike a normal fanboy, an educated fanboy is able to answer the question “So, why don’t you use competitor X instead?”

Fanboy answer: BECAUSE MACS ARE SHIT.

Educated Fanboy answer: I like iOS, but the UI is starting to stagnate a little so I thought I’d hop over and try Android. It’s more interesting, but I miss the seamless integration that iCloud gives you.

Being an Educated Fanboy is why I’m currently using an Android phone after using an iPhone for years, is why I nearly replaced my Canon SLR with a Nikon one despite having a rather large pile of Canon lenses, and is why I have both an iMac and a Windows PC sitting at my desk.

To The Point, Already!

Right! So, I’ve been using Apple’s Aperture as my photography tool since it was at version 1.0 and cost £300. Many years later, I’ve finally decided to sit down and give Adobe’s Lightroom (or, more accurately, Adobe® Photoshop® Lightroom® 4) a go.

Like most fanboy things — Canon vs. Nikon, Xbox vs. Playstation, Corvette vs. Viper, Chrome vs. Safari, Aperture vs. Lightroom, etc — the thing that’ll swing it one way or another for a particular person will be fairly small in the grand scheme of the overall product. All of them are fine products, and nobody can intelligently claim someone is wrong for going one way or the other.

In the Lightroom vs. Aperture fight for my own personal use, the fight came down to three things:

• Lightroom’s Noise Reduction is absolutely amazing.
• Aperture’s book templates are way better than Lightroom’s.
• Lightroom’s workflow MAKES ME WANT TO PUNCH THINGS.

And the workflow is what makes Lightroom fall over for me. When making a book, every time I wanted to make an adjustment to an image I had to hop over to the Develop module, completely removing my book workspace from the screen and breaking my flow. For a while, I just started playing with the Noise Reduction slider to make myself happy again, but considering that I’ve never wanted to de-noise a photo before and that I make books relatively often, there’s no way me and Lightroom can be happy together.

But man, that Noise Reduction…

Today, after a slightly extended trip home from work, I hit 1,000km ridden on my bike since March 25th this year, which is enough to ride from South London to Monaco in a straight line! In those eight months, I have…

• Spent 71 hours on my bikes.
• Gone on 81 separate rides, which averages 2.5 per week.
• My longest ride was just over 30km.

You can see my full cycling stats on my Strava profile.

The ride home from work that tipped me over 1,000km.

My new bike has been put through a wide range of terrain, from the dry, sandy mountains of the Alps to wet but smooth rides into work to the muddy, dirty, leafy forests in there area around my home.

One of the reasons I replaced my bike this year was that my old bike had suffered from neglect. A few years ago I rode it a lot in wet, gravelly conditions and fine pieces of gravel got everywhere. I didn’t get my bike serviced (or service it myself), and the gravel wore away at irreparable parts of the frame. It wasn’t gone by any means, but as the bike started needing serious money spending to replace work parts, I didn’t want to spend that money on a failing frame.

Cycling in wet, muddy conditions takes its toll on me, too!

So, I’m preparing to give my bike a thorough service now I’ll be winding the riding down as it gets snowy. Armed with the knowledge I’ve gained over the years and The Big Blue Book of Bicycle Repair, I’ll be spending a weekend taking my bike apart and thoroughly cleaning and re-lubricating the sensitive parts. Since I’ll have it apart anyway, I’ve decided to do a couple of upgrades to the brake system (new hoses) and the tyres (converting to tubeless). It’ll be as good as new!

Here’s my list of tasks. It’ll be a busy weekend!

Brakes

• Bleed brake lines (if needed)
• Adjust lever travel and reach

Rear Gears

• Remove cassette and clean
• Clean and re-lubricate derailleur
• Check gear cables for smoothness/fraying, re-lubricate or replace if needed
• Check and adjust gear shifting

Rest of Drivechain

• Check chain for stretch, replace if needed
• Remove crank and bottom bracket, clean, lubricate and reassemble
• Check wheels and axles for lubrication, correct tightness

Suspension

• Check seals and pressures
• Re-adjust if needed

Frame

• Check frame for cracks etc
• Clean frame, sticker/paint over damage, observe friction points

Miscellaneous

• Check saddle height and position
• Remove dropper post, clean and re-lubricate if needed

It’s October, and winter is in the air! In Sweden, that means you hunker down and prepare from the oncoming arctic darkness. Since Swedish infrastructure survives this just fine and food isn’t a problem, that means it’s time to build toys, er… models!

I’ve written about models railways on and off on this blog for a few years. However, last year we moved into an apartment large enough for me to dedicate a room to a railway. No more cramped lofts!

Over the next few months, I’m planning to slowly build up a scenic model railway layout complete with towns, forests, lakes and so on. Turns out this quite a huge undertaking, and I’ve already spent a month planning and starting the build. Here we go!

InterCity 125 and Mallard.

Planning

The track, once properly laid, will be pretty much permanent - surrounded by scenery, attached to point motors and have its power lines soldered in. Because of this, make sure you take your sweet time settling on the layout!

I used an app called RailModeller to try various layouts on the computer. Once I’d settled on a rough design, I bought the track plus extras (RailModeller will give you a list of exactly what track you need to create the layout you’ve made) and plonked it down on the board. Inevitably, you’ll tweak the layout once you see it in real life - make sure you keep your changes in sync with RailModeller so you have an accurate inventory of track, and so you can try virtual changes at any time.

Once you have trains running around track set loosely on the table, start asking some questions:

• Is the track too dense? You need space for scenery.
• Is the track too sparse? After all, it is a model railway?
• What’ll go in that gap? How about over there?
• How about more interesting features like tunnels and bridges?
• Is there a station?
• Is there enough storage space to park trains when not in use?
• Is there at least one complete loop so you can set a train running on its own?

Once you’re settled on a layout that’ll make a good model, it’s time to make the track more permanent so you can build it!

My final layout in RailModeller. Real life is a little more flexible than RealModeller, so it’s ok if things don’t exactly line up.

Assembling

Things will get messy when you start assembing the layout!

Electrical

My layout is digital, powered by a system called DCC. DCC is a standard that uses AC current to power the trains and connected accessories. Each train/accessory has a unique address, and commands to them are encoded by varying the frequency of the AC current. This makes the electrical component of the layout slightly more fragile than a traditional DC system, so the layout is wired with a “master” wire running underneath the board, connecting to the track every few metres by smaller wires soldered to the track and passing through holes in the board.

The motors connected to the points are connected to the master wire directly rather than to the track, again through holes in the board.

Ramps

The ramps are made from 9mm plywood, strengthened by thicker timber underneath where appropriate. The drop from the point the 9mm plywood hits the board to the board itself is done using a polystyrene gradient from Woodland Scenics.

When designing and building ramps, it’s important not to make them too steep - about 4% is the steepest you can realistically get away with!

Track Bed

To keep the trains running smoothly and quietly, it’s important to have the track running on a foam or cork bed. I used track bedding once again from Woodland Scenics.

This will likely be the most tedious part of the initial build of the layout - it took me a few days to put the bedding on mine. The bedding needs to be cut and curved correctly then glued onto the track. Points are even harder!

…however, once it’s done it’ll be clean, tidy and smooth running.

Controlling

As mentioned earlier, my layout runs using a digital system called DCC. My controller is fairly normal looking, with a little UI to choose which train or accessory you’d like to control. While controlling trains like this is a lot of fun, controlling accessories is less so. There are thirteen sets of points on my layout, and unlike trains, they can’t be named. When I need to switch a point to drive a train into a siding, it’s often difficult to remember if that point is number 8 or 9.

This is where a piece of software called RailMaster comes in. Plug in the controller via USB and you can use it to build a rough version of your layout, telling it which points are where. Once you’re done, you can click the points on the map of your layout to switch them.

My layout in RailMaster.

The software can also control the trains and runs alongside the controller, allowing you to switch between the software and the controller as you wish.

Next Steps

And with that, my track is completely assembled, ready for the arid wooden plains to be converted into lush forests and busy towns.

And obviously, I didn’t attach my GoPro to a train and make any stupid… oh, who am I kidding?

Time to start stocking up on fake trees!

In March, I publicly announced I wanted to get fit enough to go snowboarding and have fun. In May, I talked about how I’d rekindled a love of mountain biking that I had before I moved to Sweden.

Soon after that, my fiancée and I decided to take our mountain bikes on a planned summer trip to the French Alps. I’d been saving for a new bike for a couple of months, and ended up going into crunch mode to try and get it before we left. I was successful, and a couple of weeks ago we set off to France with my shiny new yellow bike strapped to the back!

It didn’t stay this shiny for long!

2,400km each way. Totally worth it!

What greeted us after over 24 hours of driving over two days was, well, stunning.

Beats flat old Sweden any day.

Les 2 Alpes

Some of the ski resorts turn into mountain biking parks during the summer, and we were lucky enough to have one within a couple of hours of where we were staying. The general idea is that you rock up to the resort, pay for a lift pass and you get to fly down the fun descents while having lifts escort you and your bike bike up to the top again.

We ended up spending two days at Les 2 Alpes, which gave some of the most awesome bike riding I’ve experienced. It was a lot more technical than I was expecting, and on one of the routes were were thinking “This is a green run?!” a lot of the time.

As I’m helpfully pointing out, you can see some of the lower courses carving their way down the opposite mountain.

A rest stop halfway down one of the more difficult “green” runs.

It sucks to have to stop to adjust stuff, but at least there’s a nice view while you do it!

I also took my new GoPro camera with me, and we had fun attaching the camera to various bits of our bikes and ourselves. I’m really pleased with the result!

If you’re interested in a less editied version, here’s a complete run down the shorter green route at Les 2 Alpes, Vallée Blanche. Warning: There’s some horrible noise from my brakes in this video, which is discussed below!

Casualties

Unfortunately, everything has a weakest link. Much like a lower-end MacBook Pro might be held back by a crappy graphics card, my bike’s weakest stock component is widely known to be its brakes. Keeping a larger-framed gentleman such as myself in check down mountainsides generates a lot of heat, and two days worth of downhill work caused my brakes to start shrieking in pain, vibrating at the exact frequency to send a horrible resonance through my whole bike.

A day’s work of braking causes heat discolouration on my bike’s brake discs.

This is a well-known problem with the brakes (Avid Elixir 7) my bike was kitted out with from the factory, and while there are elaborate ways people have found to fix (or at least mitigate) it, I decided that I’d rather replace them entirely than have a set of brakes that I’d never be 100% confident in.

Thankfully, unlike a MacBook Pro, upgrading components on a bike is fairly simple, and I fitted some beefy Shimano XT brakes to mine when I got back to Sweden. These bad boys are well known to be tough, and even have heatsinks on the brake pads to help dissipate heat better.

Wait, there was an original goal?

Right! Snowboarding. The original plan was to get fit enough for snowboarding. I’ve already cycled over 550km this year and I’m aiming to hit 1,000km before the Swedish winter makes cycling too cold and/or dangerous to do. I genuinely feel a lot fitter already and think I’ll be physically fine when I hit the slopes without wheels.

As always, you can follow my efforts on Strava as I slowly make my way towards my goal.