Blog ported to WordPress

I’ve just finished porting my blog to WordPress.
My blog was originally written in Java before most blogging platforms existed.
This means that the code for it is old, and becoming increasingly difficult to maintain.

I wanted to make a small change recently and very quickly hit dependency hell.
So I decided maybe I should just port it all to WordPress and have one less legacy project to maintain.

Importing it was simple enough.
I generated a full RSS feed (remember those?) and used one of the provided importing tools.
The tricky part was maintaining permalinks.
Most people don’t seem to bother with this step when migrating blog platforms.
But I think it’s still pretty important.
It’s a permalink after all.

The way my blog generated them was different from the way WordPress does them.
So I ended up writing a script that converted them to WordPress format then tested each URL against the deployed site.
Any that resolved emitted the code for an Apache redirect into a text file.
Any that didn’t I had to fix up by hand.

Finally I was able to paste the redirect codes into my Apache config and send it live.

The only thing I’ve not been able to do yet is grab the old blog comments.
That’s still on my todo list.

How I am getting things done with Trello Workflows

As the resident Trello* fanboy amongst my friends I recently put together an email explaining a couple of ways that I get the most out of Trello.

I call these “Trello Workflows”.

In the interests of “sharing the knowledge” I’m converting that email into a blog post.

* Disclaimer: I get a month of free Trello Gold if you sign up using that link above.

The workflow for day to day stuff

The first of these workflows is for tracking day to day tasks.

Workflow for day to day stuff

The initial idea is explained in part 2 of this post by Ryan Carson.

Before you do anything, take 19 minutes and organize your todos for the day. I wake up at 4:54am every day, grab a coffee and open up my personal Trello Board and prioritize. Limiting this to 19 minutes keeps you focused and ensures you don’t spend all your time prioritizing instead of doing.

Please note that you don’t need to get up at 4:54am to do this.

I discovered this system from Leo Babauta of Zen Habits who has a few things to say about it too.

I’ve reworked this system a little and “made it my own” but the basic ideas are the same.

Changing it to suit you is quite important. I don’t like to have lots of non-critical cards in my Later list so I eventually created a “Rainy Day/Ongoing” list where I could put all of the tasks that are non-essential but that I’d still like to get around to one day.

I’ve been following that system for about 18 months and it’s amazing the amount of stuff I manage to get sorted now.

I no longer have to worry about forgetting to do things – I just make sure I track them on the board.

The only thing I have to remember to do is a quick daily review and then to have the discipline to add cards to it whenever new tasks roll in.

The other nice thing is that if you set a due date on a card and add yourself as a member Trello will email you a reminder when it’s due.

I’ve set up a template Trello board based on this that you can clone and start using.

The workflow for Big Goals

The second workflow is for managing the big goals.

You know, learn Spanish, climb Mount Everest, the kind of stuff that takes months or even years to accomplish.

Workflow for Big Goals

Again, there’s an excellent blog post explaining it all.

Some people call them “dreams”. Some call it a bucket list. I call them big, gray, looming rocks. No matter what you call them, we all have them: the things we want to do and experience before we die. Making your own bucket list gives you some perspective on your life and what you want out of it. But writing bucket lists and creating vision boards around them can only do much. Emptying that bucket calls for action.

The basic principle is to break down each task into smaller and smaller chunks until you’re left with 2-3 small things to do in a given week.

For example, one of my goals is to speak Spanish fluently (I’ll get around to climbing Mount Everest next year), my tasks for this week are to complete the next two stages of an online course I’ve signed up to.

Each of those steps is probably only 20 minutes work so I’ve committed to spend less than an hour a week on it.

This means that I’m not going to overload myself and burn out which then means that I have a better chance of achieving my goal.

I’ve only been doing this latter one for a few weeks but I’ve already felt the benefits.

I’ve found that I am making time to do these tasks whereas in previous weeks I would just completely forget about them.

I’ve set up a template Trello board based on this one as well.

Let me know how you get on with these by contacting me through the blog or pinging me on Twitter.

TODO: Refactor this

Anyone who’s worked on a sufficiently large code base will have probably come across a comment like this one.

// TODO: Refactor this

No doubt left there by some well-meaning developer and probably ignored by everybody else since.

Sometimes it will be accompanied by a rant about exactly what’s wrong with the code in question.

Comments like this serve no useful purpose!

They may serve as a bit of a stress-relief for the person inspired to write it but other than that are a waste of time. If the person leaving it wasn’t inclined to do the refactoring then what makes them think someone else will?

Or maybe they optimistically think they can come back when they get some free time and do it. They almost never will find that free time – the comment will sit there until the developers on the team no longer even notice it anymore.

Here’s what I like to do when I come across some code that I think could do with some refactoring…

Consider working on it right away

If I have time and/or it’s in scope I’ll try to refactor it there and then.

If I can’t do it right away…

Raise a tech debt ticket in the bug tracking software

This creates an actionable task that can be discussed by the team and tracked.

Leave a TODO comment referencing the bug tracker number

This ties the code in question back to the ticket.

Add my name/initials to the comment

This gives people someone to talk to if they happen across the comment.

Oh yeah, and I save the rants for down the pub!

Dealing with the wardrobe from hell

I’ve been reading a lot about Minimalism lately.

It started when I heard about a site called Minimal Mac. That site led me to Zen Habits and then on to mnmlist and before you know it I’m reading a post about how to declutter a closet (or tidy a wardrobe as I call it).

Now I wasn’t really sure if I wanted to embrace the minimalist lifestyle or not but I did have a wardrobe that was in a right old state.

So posts like this tend to grab my attention.

I should stress – I don’t need to be told how to tidy my wardrobe, I just need to be told to clear out my damn wardrobe!

It’s a motivational thing.

And it seemed to do the trick as that following weekend I got started on the wardrobe from hell.

Getting started

There really was far too much stuff to tackle in one sitting.

So I logically divided it up into sections and did it over the course of several weekends.

I figured I’d lack motivation after a while and give up (this wasn’t the first time I’d tried to do this) but to my surprise the sense of accomplishment I got from clearing a section motivated me to do another section the following weekend.

The key thing was to make sure I had enough time to do a section completely so I could get that sense of accomplishment – the motivation killer is when you run out of time with the job half done.

Nobody wants to go back to a half-completed job.

Paper

I’m using the word “section” to mean any number of things.

Some “sections” were boxes of papers I’d been hanging on to for, um, several years.

Going through a box and deciding whether to shred, recycle or file away the papers inside was one of the tasks I dreaded.

There’s a reason there were papers inside going back years. I’d been putting off sorting through it for all that time.

Hmm, that was several dull afternoons of my life I’m never getting back.

No more random boxes

Other “sections” were boxes of stuff.

Generally speaking, I had two types of boxes; boxes of related things (like tools or camera gear) and boxes of random crap that didn’t seem to belong anywhere.

I wasn’t really concerned with the boxes of related things – I knew what was in them as I accessed them fairly regularly.

It was the random crap I had a problem with.

Boxes of random stuff are bad news.

As long as there is no rule about what does and doesn’t belong in them then effectively everything belongs in them.

And once you have a rule like that you’ll slowly but surely end up with a wardrobe that’s a big old tip again.

So, there will be no more random boxes.

If I really can’t figure out where something belongs then it’s quite likely I don’t even want it around.

I thought it would be quite hard to get rid of the stuff in the random boxes but it was fairly easy – most of it had been sat there untouched for years and really was junk.

Various bits already belonged somewhere else – camera bits or stuff for my bike etc.

The remainder ended up in the chuck pile.

Disposing of stuff

As for actually disposing of stuff.

Papers and bits of cardboard were all recycled (sensitive papers being shredded first of course).

Things like unwanted books, records and DVDs went to Oxfam (after being offered to friends – friends who clearly don’t share my tastes I might add!).

Unwanted electrical stuff went on either eBay or Freecycle.

Actually, hardly anything went on eBay – either everyone’s going minimalist or there’s a recession on as everyone was selling and nobody was buying.

Hmmm, I got rid of an all awful lot of stuff – I guess all that reading about minimalism has rubbed off on me after all.

Wiphi update

I recently blogged about buying an Acer Aspire Revo to sit under my TV.

It arrived as planned and setting it up was fairly straightforward.

I’ve had it for about six weeks and I’m mighty pleased with it.

It’s small, quiet and looks pretty cool too.

I plumped for Boxee as an interface to my music and videos and although it crashes now and again I quite like it.

It crashes less now that I am using the standard Ubuntu nVidia drivers from apt (I previously downloaded the latest drivers from the nVidia site but half my videos wouldn’t even play).

It runs so quiet I have now set it up to run email, DNS and DHCP thereby enabling me to shut down the large (noisy) tower PC that was previously performing those tasks.

I reckon with the electricity I save it’ll have paid for itself in 2-3 years!

Boxee has really impressed me.

The ease with which I can play videos has got me ripping my existing DVDs so I can watch them through Boxee.

For me at least the age of disk-based media has passed – I can’t be doing with disks anymore.

Much as with my CDs once I rip them I put them in a box at the back of a cupboard and never refer to them again.

Wiphi Mark II

Almost five years ago I decided to build a “DIY streaming media thingy” to play music in the living room.

I went ahead and built it and very good it was too.

But it’s been getting a bit long in the tooth and it is a little too large for the TV stand so I have reluctantly decided to retire it.

The idea of doing without a PC in the living room lasted about two days before I was back on QuietPC planning Wiphi Mark II.

I had my eye on a case but after doing the maths I realised it was going to cost a fortune to build a new PC from scratch.

I was just about ready to abandon my plans when I caught sight of one of these on The Gadget Show.

I got even more excited when I found out there was a Linux version for £180 (annoyingly they were going for £150 a few months ago).

The Linux versions do seem to be rarer than hen’s teeth at the moment but I managed to track one down from eBuyer eventually.

Software wise I think I’m going to try out Boxee instead of my homebrew Wiphi code – I’m a little sad to give up on it but it’s quite clunky and basic compared to all the whizzy stuff you get with Boxee.

I’ve also found a useful guide to getting it all set up.

It arrives on Saturday.

That’s my weekend sorted then. 🙂

NVIDIA drivers in Ubuntu 8.10 (Intrepid Ibex)

I upgraded from Kubuntu 7.10 to Ubuntu 8.10 this morning.

This was via a fresh installation into a new partition.

Getting it running went fairly smoothly but trying to get the NVIDIA drivers working was a world of pain.

It seemed that no matter what I tried I always got the following error:

Failed to load the NVIDIA kernel module

Every tip and bit of advice I found online didn’t work.

It turns out that the linux kernel headers aren’t installed by default but are required by the nvidia drivers (I only wasted two hours finding this out!).

It’ll never work unless you install the linux headers first.

These commands fixed it for me (exact version numbers may vary according to current Linux kernel version and your particular video card).

apt-get install linux-headers-2.6.27-7-generic

apt-get install nvidia-glx-177

Hope this helps someone.

“Source control ate my files!”

Everyone who has worked in Software Development for long enough must have heard somebody say that source control ate their files – it’s up there with “Works on my machine” and other such silliness.

Invariably source control didn’t eat their files at all – the problem boiled down to a (sadly) not too uncommon condition of “Fear of Source Control“.

Here are some of the symptoms of such a fear.

Unwillingness to do an update

I worked on a project years back with a tight deadline, not a huge amount going on in the way of process and about 6 developers all coding like hell.

Invariably, every other update broke your local build as someone had changed an interface or forgotten to check in a file (we had no daily build either), so yes, updating was a pain.

For two of the less experienced team members their solution to this problem was to hold off updating as long as possible (they’d happily go two weeks without doing an update).

When I queried their approach their answer was that doing an update “broke things” so was best avoided.

This symptom of course goes hand in hand with…

Unwillingness to do a commit

As anyone who has worked with source control systems long enough knows, they won’t let you commit a file if there are outstanding changes to be merged in.

So, leaving long gaps between updates almost always leads to massive problems when you finally commit your changes.

Long update intervals lead to long commit intervals.

My usual solution to this is to do an update every morning before I start any development work for that day.

Of course, I now work on much saner projects where things don’t break so often (or when they are likely to break things then someone has already warned you in advance).

That way I get the small amount of pain out of the way without huge disruption to whatever I am working on.

I then commit my work once it’s complete and passes its tests.

I also try to pay attention to what my colleagues are doing on the project too so I can avoid nasty surprises.

Deleting other people’s code

I have seen this happen, usually when someone gets a merge conflict.

Merge conflicts are what happens when two people work on the same code at the same time and the changes from one person’s work are merged into the other’s work.

Sometimes this happens smoothly and everybody is happy and sometimes not so smoothly and one person is very unhappy.

In the face of a merge conflict the correct approach is to fix the code by hand, which often involves talking to the other person who worked on the file to ensure that both their changes and your changes are preserved.

The incorrect approach (and yes, I’ve seen it done) is to remove the offending lines (someone else’s code), keep yours and commit away. This is of course a “bad thing”.

Merge conflicts are of course best avoided, even experienced developers strongly dislike them.

The way to do this is through communication with your fellow team members and knowing who is working on what area of the code (Scrum-like daily meetings are great for keeping up with who is doing what).

Often, said conflicts can be avoided by a bit of advance planning (you do your bit, test and commit, then they update and pick up your changes before they do their bit etc).

Commenting out unused code

If you’re lucky it will be accompanied by a vague comment along the lines of “I don’t think this is used any more” .

This stems from the fear of not knowing how to use source control to retrieve old versions of a file.

The correct thing to do of course is to remove it, then commit that change and mention said removal in the commit log.

If the code is being replaced then a comment along the lines of “Replaced foobar1 with foobar2 – foobar1 code lives in version 4.1.2 in CVS” would be most appreciated by future developers (which could of course be you).

Committing backup versions of files

I’ve just finished working on a project where a binary file that was kept in CVS had no less than 7 alternate versions (none of which were used) checked in alongside it.

I spent ages working out what each one did, seeing it did nothing, then removing it from CVS.

Again it stems from confusion and fear of using source control to get access to older verions of a file.

The solution

The solution to all of these problem is of course to “lose that fear” and learn to love your source control tool.

One good way to start doing this is to stop using a GUI to manage your source control tool and learn the command line instead (assuming your tool has that option).

That will remove a lot of the mystery of what is going on.

Learn the mechanics of your source control tool by reading the manual.

Eric Sink has an excellent series of posts on source control that highlight some of the many benefits of using it.

The final thing to realise is that correct use of source control will save your bacon.

The initial learning investment will be repaid time and time again.

And that, is worth its weight in gold.

Thinking in Ruby

So, I’m learning Ruby (it only took me a year to get started!).

I’m working my way through Programming Ruby and doing a few different scripts to see what it can and can’t do.

Most of it seems fairly straightforward stuff and I’m liking what I’m seeing for the most part.

One of the things that crops up from time to time in examples in books and online is something along these lines:

print total unless total.zero?

That’s it, the “unless construct”.

I’ve seen this before in Perl and I’ve always avoided using it – I personally find it unintuitive so I always write my code in the if x do y style.

Do x unless y has always seemed a little, errr, backwards.

Seeing it again in Ruby I again decided I’d avoid using it and carry on as I had before – then I began to wonder if I was simply imposing my “Java programming style” on to my Ruby code.

It’s an easy enough trap to fall into, much like early C++ programmers wrapping their C-style static methods up in a class and think they were doing OO.

Thinking about it, most of my Perl code is written in a similar style to my Java – I always apply “use strict” and enable warnings, always put code into methods, almost always have a main method etc.

But hold on, am I writing Perl in a Java style and thereby restricting my ability with the language, or am I simply applying sensible practices to my Perl code?

My Perl code never really extended much beyond occasional scripts to process photos so I have no clear answer to that.

I hope that my Ruby coding will move beyond that (possibly into the realm of Ruby on Rails) so as it does I’ll have to constantly be asking myself if I am thinking in Java or thinking in Ruby.

Unchecked Exceptions

On our new project at work we’re using JPA sitting on top of Hibernate.

I’ve used Hibernate several times now and am familiar with it.

JPA is mostly similar in use but there are a few gotchas.

One that got me the other day was what happens when you write a query that you expect to return a single result.

In Hibernate I’d have called query.uniqueResult();

The Javadoc for that method says:

Convenience method to return a single instance that matches the query, or null if the query returns no results.

So, the query either returns my object or null (an exception is thrown if my query returns more than one result – fair enough).

I had to do something similar in JPA-land so I looked at its Query class.

It offered a similarly named method: query.getSingleResult();.

All good, I wrote my code, compiled it and restarted my application server.

Unfortunately, when I ran the code, it fell over with a NoResultException.

For my particular query, there were no results in our test database.

Fine, my code can deal with that, but clearly the JPA method works quite differently from the Hibernate version.

Its Javadoc says:

Execute a SELECT query that returns a single result.

Returns:

the result

Throws:

NoResultException – if there is no result


So, unlike the Hibernate version this one will throw an exception if the query returns no results.

Hmmmm, I think I prefer the Hibernate version.

Of course, if it had thrown a checked exception my code would not have even compiled.

As it was it was just luck that the database had no results so I found the problem right away.

I’m not saying unchecked exceptions are bad, on the whole I prefer them.

But there’s a certain element of retraining your brain to no longer rely on the compiler to tell you that you’re dealing with all possible error conditions.

I know, I know, there wouldn’t be a problem if I’d read the Javadoc up front, but how many people can honestly say that they read the Javadoc for every new method the first time that they call it?