So, since PHP Code Sniffer can also run JSLint, we thought we’d turn on JavaScript sniffing as well. It all sounds so easy, doesn’t it?

Ultimately, it is pretty easy to get PHP Code Sniffer running JSLint, but there were a whole bunch of hurdles that ended up taking me a couple of days to get over. So, I thought a blog post was in order. Here’s what you need to do:

1. Have a working installation of Java.

2. Have a working copy of PHP Code Sniffer, installed via PEAR.

3. Have a working installation of Rhino.

   Depending on your system you’ll want to do one of two things:

   • The simplest option is to install a Rhino binary, by doing something like the following on your system:

     apt-get install rhino
     

     This will put a rhino script on your executable path, and you’re good to go.

   • Alternatively, you’ll need to download Rhino from Mozilla’s website. Unfortunately, this download doesn’t contain a rhino passthrough script (which PHP Code Sniffer will later need), so we’ll need to create one. Thankfully it’s pretty simple, and can look like this:

     #!/bin/sh
     java -jar `dirname $0`/js.jar $@
     

     Here, we’ve made the assumption that we’ve put the rhino shell script and the js.jar file (the only file we need from the download) into the same directory.

4. Create a JSLint file that Rhino can use.

   For this, you’ll need to travel back in time to before Crockford stopped supporting Rhino.

   1. Download the last version of the rhino.js file from GitHub.

   2. Download the latest version of fulljslint.js from Github.

   3. Concatenate the two files together.

      cat fulljslint.js rhino.js > ultimatejslint.js
      

5. Tell PHP Code Sniffer where your rhino and ultimatejslint.js files are:

   phpcs --config-set rhino_path /path/to/rhino
   phpcs --config-set jslint_path /path/to/jslint.js
   

6. Run PHP Code Sniffer with a standard that knows about JSLint.

   • Either use the Squiz standard:

     phpcs --Standard=Squiz .
     

   • Or, add the Squiz JSLint Sniff to your own standard.

     In your standard’s getIncludedSniffs() function, add the following Sniff to the returned array:

     'Squiz/Sniffs/Debug/JSLint.php'
     

And that’s it. There’s a few steps, but once you’ve done them once, JSLint issues will show up as warning in your reporting. If you want to change the flags that JSLint has turned on, you’ll need to update the array at the start of the rhino.js file.

One of the processes that I introduced to the team about six months ago was that of a formal “dev check” after every task that we completed from our backlog. Whilst we call this process a dev check within our team, it could just as easily be called a peer review, or mini code review.

Up until the point that I introduced the dev check it had not been uncommon for a single person to work on a task, and for code to go through the testing environments and onto live without a single other human ever reading their code. Not the best situation to be in, and it meant that we ended up having more annoying bugs showing up on our test environments than we should have. These bugs were often things that a simple bit of human scrutiny would have caught, and we ended up wasting time going back and fixing them after the fact. Working this way also meant that we ended up with certain areas of the homepage that could only ever be worked on by certain people, because they were the only ones who had ever seen the code.

Like I said; not the best situation to be in.

So, six months ago, we introduced the formal dev check – a step to be completed for every single code related task in our backlog. And, I’m happy to say it’s been a very successful process for us – we now have far fewer bugs getting to test, and we have a lot more shared knowledge within the team.

What is a Dev Check?

Before any task is committed to trunk, a developer who didn’t work on it must say that they are happy with how it’s been completed.

I’m hoping that if you’re still reading at this point that you’re wanting to find out what goes into a successful dev check…

1. The task is “completed” by Rachel.

   At this point she has not committed anything to the trunk of the project. Depending on the size of the task, she might have created a development branch which she’ll have been committing to.

2. Rachel asks another member of the development team to come and do a dev check. On this occasion she asks Jon.

3. Jon comes over to Rachel’s desk where she will talk through all the changes she has made.

   As part of the discussion, Rachel may realise that some of the things she thought made sense in fact didn’t. This is great, and she’ll make the changes necessary and continue with the dev check.

4. After Rachel has finished explaining what she’s done for the task, and Jon’s asked as many questions as he feels is necessary he’ll either give the go ahead to commit the code to the trunk, or he’ll request various changes to be made to the codebase.

5. Rachel will then commit to trunk, build in the team’s test environment and pass off to the testers.

And that’s a dev check.

Out of this process Jon has learnt about a bit of the codebase that he might not otherwise have seen, Jo realised that she needed to shore up a couple of her tests, and the codebase has come out feeling more healthy. This is A Good Thing™.

What sort of things will the dev checker ask?

Up above there in the “What is a Dev Check” section you’ll have read about Jon asking “as many questions as he feels is necessary”, and I’m sure you’ll have said to yourself “But Neil, what are those questions? How will I know what’s sensible to ask?”.

Well, you’re in luck. By a process of trial and error, as a team we’ve come up with a bunch of questions that, if asked, will help to make sure that you both understand what’s going on and can confirm that the code written is of a high quality.

• Have new tests been written?

  These might be Unit Tests, or Automated Front-End Tests, or Security Tests. What matters is that valid tests have been written to cover the new functionality. You should also make sure that any pre-existing tests make sense.

• Do all the tests still pass?

  It should be a no-brainer, but of course you should make sure that all the tests still pass. There’s nothing worse that breaking The Build for the entire team just because you forgot to run a bunch of tests on your development machine first.

• Are standards adhered to?

  • PHP Code Sniffer
  • HTML/CSS Validation
  • JSLint
  • Whatever else works in your team

  These are important to us. We fail our builds if our code isn’t of high enough quality. Just sayin’.

• Does what you’ve written work across all the Level One browsers?

  Obviously this one’s a bit web development specific as it is, but it’s important in other spheres as well. Every piece of software that’s written is expected to run in one or more environments, and you should at least smoke test in a known subset of them to make sure there are no nasty surprises for your dedicated testing team.

• Can I see your diffs?

  Again, fairly obvious, but you should take a look to see what’s changed since the last time the code was checked in. Don’t just rely on the developer to remember what they’ve changed – I know I can’t remember half the time. This is what machines are good at – make use of them!

• Did any of the changes that were made affect any other code?

  This one should be obvious as well, but unfortunately it isn’t. It’s all too easy to look at the lines of code that have changed without looking at the later lines which make use of them. Don’t forget to look at the whole system.

• Is there anything that concerns you?

  The final question to ask, and in many cases the most important one. Oftentimes a developer will know that something smells a bit fishy, but keeps quiet about it in the hope that they won’t get called on it. By simply asking these questions though, we’ve found that these things end up getting talked about, and we end up with better code because of it.

How long does a dev check take?

After reading all that, I wouldn’t be surprised if you’re thinking “Woah! But how long does that all take? That seems like a long list of questions…”.

Well, in my team, we find that a dev check will take a little less than 10% of the time that the code and tests took to write initially. So, if the task took an hour to complete, the dev check would take roughly 5 minutes. A three hour task would take 15 minutes, and so on. It honestly doesn’t take much time once you get into the swing of things.

The Power of Veto

One of the most important things about dev checks is that everyone on the team is equal. Rachel may be the team leader, but Jon can still challenge her code and say that actually she hasn’t done everything required to “pass” the dev check.

The person performing a dev check always has power of veto to say that things, however small, need improving before code is allowed to be committed to the trunk.

Ultimately, the team is responsible for its own output, and everyone should be invested in that.

What do dev checks achieve?

As I’ve mentioned above, there are two main benefits to dev checking:

• Fewer bugs
• More knowledge of the codebase by more of the team.

Essentially the team will be more effective.

How do you get buy in?

Whilst there are obvious benefits to dev checks, sometimes you’ll need to gain buy-in from people before you can get started. Maybe it’ll be team members who think that this extra process is unnecessary, or maybe it’ll be The Boss who thinks that it’ll all just take far too long. What do you say to them?

Getting Buy In From Team Members?

• Everyone is equal.
• Anyone is able to say that a dev check cannot yet be completed.
• The team is responsible for the quality of the team’s output, not just one person.
• You won’t end up getting stuck on a horrible portion of the codebase any more, just because you were the last person to write code for it.

Getting Buy In From The Boss?

If you’re lucky, you won’t need to get buy-in from The Boss, but in case you do, here are a couple of pointers:

• Quality is improved, leading to fewer bugs and happier users.
• The amount of time spent on dev checking is smaller than than that which would be spent fixing the bugs that would otherwise get through. The project will go live sooner, and you’ll have spent less money.

Improving the Dev Check

Any bug that is found is an opportunity to learn and improve our process.

Of course, sometimes bugs will still get through. When they do, you need to sit down and work out why that happened.

In the old world, we used to just accept that bugs happened, that they’d get found, and we would fix them. No more! Now, any bug that is found is an opportunity to learn and improve our process.

A real example of this happening came a few weeks ago. Tina had been doing her thing, updating a script that we use to help us with our release management. This was dev checked by Bradley, and as far as he was concerned the changes that had been made were good to go. So, he ticked off the dev check, and Tina carried on with her next task.

Fast forward to a week later, and Paul was getting down on the floor ready to give a presentation which required a screenshot of the script running. Unfortunately, it no longer worked – shock horror!

What had happened was that Bradley hadn’t realised that the line of code that was changed had impacted on further lines in the script. Moreover, he’d only seen the script run against the additional new requirements, and hadn’t confirmed that it still ran against the original requirements. Whoops.

What came out of this was an improvement to our dev checks – if code has changed we need to make sure that nothing else in our code has been affected by that change. It sounds simple, but it was a failing that we had, so we improved upon it.

Why not just have a big code review?

Big code reviews are great, and are something I very much enjoyed participating in when I was at Yahoo!. Unfortunately, whilst they’re very useful they’re also pretty time consuming, and require a fair amount of setup and teardown time in order to be useful.

Dev checks, on the other hand, are simple to get going with, only take a few minutes, and only have to involve a couple of people.

That’s not to say that you should get rid of larger code reviews. In my opinion they should still happen, but only for larger chunks of code. The formal dev check gives you the opportunity to review code and share knowledge often and with low cost.

Go forth and Dev Check!

And that’s it. If you’re working in a team that has bugs, or has bottlenecks of a single person being the only person who knows about certain areas of your product, then start dev checking. You won’t regret it.

Whilst the mojito may be my favourite rum based drink, what I’ll be found drink most often in the pub is a Dark Rum and Diet Coke. What I’ll want to be drinking though, is my variation of the Cuba Libre – the Cuba Libre Oscuro.

A standard Cuba Libre blends the flavours of Cuba (a white rum) and “The Free World” (Coca Cola), with a bunch of lime juice. In contrast, and as the name would suggest, the Oscuro is a Cuba Libre made with Darker Rum.

Right now I’m enjoying a golden 5 year El Dorado (a drink blended from rums with a minimum age of five years aged in oak barrels) , but I also enjoy it made with a nice shot of Captain Morgan’s. It’s a simple flavoursome drink, and very simple to make. Om nom nom.

Ingredients

• Half a lime
• Three ice cubes
• 1 shot of your favourite dark rum
• Diet Coke

Instructions

1. Roll your lime under your hand on a board to squish its insides a bit, thus encouraging the juices to flow once you cut into it.

2. Cut the lime in half across its body, and then cut one of those halves in half again. Squeeze the two quarters hard, and drop them into the glass.

   If you have no fresh limes (it happens!) I’ve been pleasantly surprised by Tesco’s bottled lime juice. Replace the half a lime with two and a half teaspoons of bottled juice. I measure two teaspoons, not worrying about any extra that spills over.

3. Add the ice to the lime juice.

4. Pour the rum over the ice.

5. Finally, you guessed it, top up with diet coke.

   The pouring action of each stage should mix the drink for you, leaving you with a tasty limey, rummy, cokey drink. Tasty.

Up until now I’ve used a collection of Smart Playlists which take into account my ratings, when I last listened to songs and a whole bunch of other information. At the last count, I had over 70 Smart Playlists feeding into each other to generate the playlists which finally get Synced over to my iPhone.

But there was something missing. Whilst I could generate playlists based on the mid-90s simplicity of the “Genre” tag, that tag is by design only able to identify one piece of information. So I wouldn’t be able to find, for example, all tracks in my collection that are “rock”, “funny” and performed by a “female”. And even if I could, I wouldn’t want to go and tag 40,000 tracks by hand. That way madness lies.

It turns out there’s a fairly simple solution to this – last.fm allows users to tag any and all tracks it knows about, and it keeps track of how many times each track has been tagged with each tag. So, it’s entirely possible to grab the top 15 tags for each track in my collection, add that data to my tracks somehow, and then query that.

The somehow turns out to be pretty simple too – the ID3 “comment” field is there for the taking, and by design is expected to be larger than any other field. Excellent. So that’s the “where to store” sorted, now how about “how to store so that the data is queryable”?

For this I took a trick out of Brian Suda’s book. A couple of years back I took a look at how he’d written his microformats parser using XSLT to be able to check for classes an element may or may not have – the trick being to wrap strings of classes with a space at the beginning and end so that every class always had spaces surrounding it. I used the same trick for storing my tag data, also wrapping it in a ‘lfm’ square bracketed enclosure to separate it from any other data in the comment.

So, the data I saved in the comment looked a little something like this:

[lfm: tag1 tag2 tag23 tag3 ]

You’re probably starting to see why wrapping in spaces is important now. Because iTunes’ Smart Playlist system can only perform simple string matching (Apple doesn’t seem to like regexes – AppleScript can’t do them natively either), you need some way of targetting the beginning and end of tags. Without those spaces, a query of “Comments contains 'tag2'” would return you both tag2 and tag23, which no-one wants. By requesting “Comments contains ' tag2 '” instead (note the extra spaces) you end up just being given tag2.

All this thinking is packaged up into a couple of scripts (though obviously take the latest code if you want to actually use it yourself) I wrote a couple of days ago that takes a given playlist from your iTunes library, asks last.fm for tags for each of the songs in that playlist, and then adds that data to the library using AppleScript.

Problems?

There are, unfortunately, a couple of issues with the script at the moment. First off, because last.fm allows anything and everything to be given as a tag, they can contain characters that need to be normalised out. Right now I’m doing that very simply (spaces to dashes mostly), but I should revisit the code and harden that normalisation – I’ve seen tagging bail out a couple of times because of unexpected data.

Next up, the fact that last.fm allows tags to be incredibly long coupled with the fact that under ID3 v2.x the comments field can only be 256 characters long means that it’s possible to run into issues with tagsets being too long to fit into the comments field. Add that to the fact that some songs in my collection legitimately contain comments already and that I want to add tags non-destructively, and we’re ending up with not much space for tags. So, an improvement that I’m planning on making to the script is to make sure that tags try to take up no more than the space that’s legitimately available to them.

The final issue that I’ve been having lives with last.fm’s track.getTopTags API method. Unfortunately at present the track.getTopTags API method does not perform any auto-correction of track names, which means that if you try to get the tags for something that does get auto-corrected by the system then you end up with the tags for the uncorrected track name. A subtle distinction, but it probably means that we end up with unmaintained tags that haven’t been touched for the year or so since auto-correction was turned on. A possible solution here if last.fm choose not to “fix” this behaviour (it could be argued that this is correct behaviour) would be to make a request out to Musicbrainz to get an ID for the track and then pass that into track.getTopTags instead. But that seems like a whole bunch of extra work for a not massive gain.

The final Smart Playlist

So, what about that Smart Playlist? After all, that’s the thing that all this work was done for.

In iTunes, select File, New Smart Playlist, and then enter the following:

Match all of the following rules:
    Comments contains ' female '
    Comments contains ' rock ' ...
    any of the following rules:
        Comments contains ' comedy '
        Comments contains ' funny '

This cunning playlist uses a Smart Playlist feature I wasn’t aware of until yesterday – rule groups. Up until now, I’d been pulling in other Smart Playlists as sources to perform the same job.

To create a new rule group in a Smart Playlist, simply click an ellipsis button in the Smart Playlist interface, rather than clicking on the plus button.

Essentially what these rule groups give you is the ability to nest rulesets, and generate very complex playlists that don’t have half their rules hidden in external playlists. In the playlist above we’re simply asking for all tracks tagged with “female”, “rock” and either “funny” or “comedy”. So essentially “female comedy rock”. At present this playlist returns me no items from my collection, but not everything’s been tagged yet. I’m hopeful.

If you’re anything like me, as soon as you connect your laptop to an external display you’ll end up moving your applications around into a better position and size so that you can work happily. Then, when you disconnect your external display to go back onto the road OSX will do its best to put them somewhere sensible on your smaller laptop screen, but fails horribly.

Enter Cordless Dog’s “Stay” application.

Stay is a deceptively simple (at least the way I’m using it) application that lives in your Mac’s taskbar. First, set up your applications so that they’re positioned as you want them, then choose “Store Windows for all Applications” from the app’s dropdown menu. If you then want to restore applications to their stored position just pull down the menu again and choose “Restore Windows”. Simple.

To make things even more simple though, pop open the application preferences. There aren’t many options here (and there don’t need to be), but for my money it makes sense to turn on “Start Stay at login”, “Restore Windows as displays are connected and disconnected” and “Restore Windows as applications are launched”. And suddenly, as if by magic, application positioning with multiple displays starts working in the way it always should have done.

Cordless Dog’s “Stay” application costs a measly $15, and is worth every cent. Good job, Cordless Dog chaps!

UPDATE

As David Thompson pointed out, I should probably point out that currently Stay and Spaces don’t currently live marvellously happily together. If you’re a user of Spaces (I’m not), you should probably wait for a future release of Stay.

Cookies are awesome. They’re simple to make, tasty, you can freeze the dough and you can eat it raw if you want to. I love them all. If I had to choose to only make one type of cookie for the rest of my life though, I would choose these.

But why?

Well, I’ve got to admit that the main reason isn’t even in their name – it’s the cinnamon in them that I would gladly give up the chance to eat any other type of cookie for. It might not be the first flavour you’ll taste in them, but it’s there, and it gives the cookies a wonderful warmth that just wouldn’t find otherwise.

Don’t get me wrong, the oatmeal gives the cookies a wonderful chewy texture, and the raisins give a brilliant juiciness, but it’s the cinnamon that does the job for me every time.

So, chances are, if I say I’m going to be making you some cookies I’ll probably be making you The Oatmeal and Raisin cookies. Om nom nom.

Makes 25 small cookies, and takes about 20 minutes all told.

Ingredients

• 150g butter
• 85g soft brown sugar
• 50 granulated sugar
• 1 small egg
• 1/2 tsp vanilla extract
• 100g plain flour
• 1/2 tsp baking powder
• 1/4 tsp salt
• 1 tsp cinnamon
• 125g porridge oats
• 100g raisins

Instructions

1. Preheat your oven to 180ºc

2. Cream the butter and sugars together.

3. In a separate bowl, combine the egg and vanilla extract, before adding these to the creamed ingredients and mixing lightly.

4. In yet another bowl combine the flour, baking powder, salt and cinnamon. Then, you guessed it – mix this slowly into the creamy eggy mixture.

   I tend to do this a third at a time to make sure everything combines together.

5. Finally, mix your oatmeal and raisins and add them to the mix.

6. Make sure everything comes together, cover and place in the fridge.

   Ideally, leave your mixture in the fridge overnight, but if you can’t wait then make sure you leave it in there for at least half an hour. The reason we do this is to let everything firm up again, which in turn means that the cookies won’t spread to cover your entire baking tray when you cook them.

7. Once your cookie dough is fully chilled, use a tablespoon to remove small chunks, which you should form into balls. Place them on a baking tray – I tend to fit nine cookies on a tray.

   Try to handle your balls as little as possible – you want them chilled, remember?

8. Bake for 11 minutes. Allow to cool sightly before removing from baking tray and then leave to cool on a cooling rack.

   Alternatively, put a couple of cookies in a shallow bowl with some good quality vanilla ice-cream and nom.

It’s been quite warm here recently. Warm enough that I’ve not been sleeping too well, even with the bedroom windows wide open, and a fan on full blast all through the night. There’s no air conditioning here.

What I’ve had to keep my going though is the humble mojito. I love my mojitos. I’d love to blame Bruce Campbell in Burn Notice, but I’ve been enjoying them long before I started watching that show. There’s something about that combination of lime, mint and ice that makes a summer day wonderful.

But today I’m not making my normal strained mojito. Since True Blood is returning to our screens, I’ve been thinking about blood related drinks (you know, like you do). I’ve been making raspberry based mojitos for a while now, but I’ve only just realised what a gorgeous deep blood red you can get out of them. So, I decided to tweak my recipe a little bit and make something that really looked like blood.

The secret to this is in the double straining. Normally when I strain a mojito I’m left with bits of mint and lime flowing through the drink, contributing to the lovely green colour that I adore. For a drink that you’re wanting to look bloody though, this doesn’t quite work.

So, I double strain. As with most things I do, this is really easy. Instead of simply straining the drink, I hold a tea strainer between the cocktail shaker and the glass as I’m pouring. This has a finer mesh than the normal cocktail strainer, and so stops any bits of mint and any raspberry seeds entering the drink. What you’re left with is a very smooth, red drink.

Try it; I’m sure you’ll love it.

Ingredients

• Juice of half a lime
• 1 tablespoon of granulated sugar
• 12 mint leaves
• 15 raspberries
• 2 shots of light rum
• A load of ice

Instructions

1. First, squeeze the juice of half a lime into your cocktail shaker.

   Before cutting the lime, I will roll it hard against a table, pushing down on it as I go. This will smush the inside of the lime a bit, allowing the squeezing process to be a bit easier than otherwise.

2. Once you’ve squeezed the lime, cut the peel up and stick that in the shaker as well, along with the sugar, mint leaves and raspberries (in that order).

3. Using a muddler (or the end of a rolling pin), squish and rotate to puree the raspberries, rip the mint and combine everything together.

   You can use frozen raspberries if you like. In fact, I keep a stock of frozen blueberries and raspberries in my freezer all the year around for alcohol related emergencies. You never know when you might want a nice cocktail.

4. Add two shots of rum and a couple of icecubes. Shake vigorously.

   I find that singing a song at this point helps the process.

5. To a separate glass, add enough crushed ice to fill.

6. Now for the straining. Double strain the contents of your cocktail shaker into your glass of ice.

   So, why am I double straining here? Basically, your shaken mixture will contain lots of raspberry seeds and some shredded mint. Now, whilst the mint would look gorgeous in a normal mojito it doesn’t work too well for the True Blood variety. You want to get rid of all those bits and leave a nice smooth colourful drink.

   What I mean by double straining is strain normally using your built-in or hawthorn strainer and then immediately through a standard tea strainer. Your normal strainer will stop the lumps of ice and lime from entering your drink, and the tea strainer will keep hold of your raspberry pips and mint.

7. Finally, garnish with a few raspberries and a sprig of mint. Add a straw, and enjoy.

I love my Mexican food. Recently, I bought Thomasina Miers’ “Mexican Food Made Simple“, which turns out to be a fantastic collection of Mexican recipes from the former winner of Masterchef and founder of Wahaca.

Over the last few weeks I’ve been trying out a fair few of the recipes form the book, and making my own adjustments for taste and availability of ingredients. This Butternut Squash and Chorizo Salad has turned out to be a firm favourite, and not something I would have tried had it not been for this book.

Here’s my take on Thomasina’s recipe to serve two. Takes approximately 40 minutes.

Ingredients

• One small butternut squash (or half a medium one – even the smallest butternut squash can be too much for two).
• One finely chopped red chilli.
• Half a teaspoon of cumin seed – crushed.
• Half a teaspoon dried oregano.
• Olive oil.
• Half a red onion, roughly sliced.
• A punnet of baby tomatoes. I like a mix of red and yellow pomodorinos.
• A handful of fresh coriander leaves, chopped.
• Chorizo.
• A small bag of baby spinach.

Instructions

1. Preheat your oven to 190ºC.

2. Cut your butternut squash into 5cm or so pieces, making sure you remove the skin and seed.

   I hate this job. I’m not a fan of how butternut squash smells when raw, but I love the taste after it’s been roasted, so I put up with it. If I’m feeling incredibly lazy I’ll buy pre-cut stuff from the supermarket. This does not make me a bad person.

3. Put your butternut squash, chilli, cumin and oregano into a roasting tin, add enough olive oil to coat lightly and mix.

4. Cook for 15 minutes.

5. Add the onion to the tin, mix, and cook for a further 10 minutes.

6. Add the tomatoes, and cook for a final 10 minutes.

7. Whilst the tomatoes are roasting, grind the coriander leaves into a paste in a pestle along with the salt and pepper. Add a tablespoon or so of olive oil, and mix. This will be your salad dressing.

8. Slice your chorizo and sear it on a griddle. Once seared, place the slices on some kitchen towel to drain.

9. Now that your vegetables have cooked, remove them from the oven and place in a large bowl. Add the coriander oil and gently mix.

10. Finally, line a shallow bowl with spinach leaves, pile on your vegetables and top with chorizo. Tasty, and the chilli gives it a lovely kick.

As time went on, I started paying attention to the “Most Popular” feeds on the homepage, and even managed to get on there myself a few times. It was a good way to find interesting techy links. Then, when the friends network facility was introduced I started following the links that my friends were saving as well. All was well.

However, I never really saved as many of the links that I found interesting as I could have done. There were plenty of occasions when I remembered telling people about particular pages because they were useful, but not being able to find them again myself. Oh, how I wished I’d added them to del.icio.us.

The problem is that I’m lazy. So, I was really happy when Packratius peeked its nose up to the cage bars. The idea behind Packratius is that it’ll keep an eye on your twitter activity and automagically add any links you tweet to del.icio.us (by default with a via:packrati.us tag). It’s deceptively simple, and something that deeply interested me – I immediately signed up.

A good idea gone overwhelming

As it turns out, so did quite a few of my friends. Overnight, my del.icio.us network feed went from being a carefully curated list of links to a mishmash of Carrots Glazed with Cum, gowalla updates and twitpics.

Now, to its credit, Packratius has options to allow you to not auto-delish links tweeted by any twitter clients that you define. This allows you to not auto tweet twitpics and the like. Of course, telling it to stop tweeting those things from your own twitter account is great, but it doesn’t stop you from seeing those updates from other people (/me looks pointedly at Simon Jobling). So, I needed to find a way to split these auto-delished URLs off from the main list.

As it turns out, whilst del.icio.us’ searching abilities are pretty powerful, you can’t do a simply negative search. So whilst you could say “Show me everything in my network feed tagged with ‘kittens’ but not ‘via:packrati.us’” you can’t say “Show me everything in my network feed not tagged with ‘via:packrati.us’”. Thankfully I came up with a solution to this – I created a Yahoo! Pipe called “del.icio.us network feed minus packratius“. (Catchy, huh?)

It’s a fairly simple pipe, with the following aims:

• Provide a feed of your del.icio.us network with items tagged with via:packrati.us removed.
• Easily customisable to show different peoples’ network feeds.

If you’ve been having similar problems with Packratius overwhelming your del.icio.us network feed, then give it a go. I know James Broad has been finding Packratius overwhelming – it was his tweet that inspired me to finally write this post up, in the hope of benefitting a few more people.

How does the pipe work?

Like I said, the pipe’s fairly simple – most of the complexity comes from generating the URL to load a given user’s del.icio.us network feed.

Once we’ve obtained the network feed, the only thing we need to do is discard all the feed items that contain via:packrati.us as a tag. Handily, del.icio.us provides us this information in its feeds:

<item>
  …
  <link>

http://wwp.greenwichmeantime.com/time-zone/africa/south-africa/

  </link>
  <description>
    South Africa is in Southern Africa, 
    at the southern tip of the continent of Africa.
    http:// bit.ly/am78yK
    #statingthebleedingobvious
  </description>
  <category domain="http://delicious.com/simey_j/">
    statingthebleedingobvious
  </category>
  <category domain="http://delicious.com/simey_j/">
    via:packrati.us
  </category>
</item>

In the feed item above (cut down for space), we can see that as well as via:packrati.us, a statingthebleedingobvious tag has been automatically generated from the hashtag in the original tweet. This is a great feature of Packratius, but it did mean that I ended up having to do more than a very simple filter to filter out the via:packrati.us tagged feed items.

Instead what I did was create a Filter block in pipes with rules that looked at the first 6 tags on each feed item (the idea being that there isn’t enough space in a tweet for more than 6 or so tags). If any of them matched via:packrati.us then they’re discarded from the feed.

The filter I created looked something a little like this:

Filter

Block items that match any of the following:

• item.category.0.content is via:packrati.us
• item.category.1.content is via:packrati.us
• item.category.2.content is via:packrati.us
• item.category.3.content is via:packrati.us
• item.category.4.content is via:packrati.us
• item.category.5.content is via:packrati.us
• item.category.content is via:packrati.us

Those first six filter rules cover the instance of more than one tag being applied to the item, and the final filter covers the intances where only a single tag exists. Simple.

And that’s all there is to it. Of course, writing this Pipe wouldn’t be necessary if del.icio.us allowed us to do a simple negative search. Still, it’s good that it’s nice and easy to generate this new feed using Pipes.

Hopefully it’ll be useful to a couple of you.

Even though Beer Near Me was only ever really built as a weekend project intended to help me learn about using the navigator.geolocation API, it was still pretty important to get some data to display on a map showing where the local beer was. After all, without that what would the point be?

Gathering the Data

To gather the local beer data I make several searches using the Google Local Search API – one that covers pubs, one for cocktail bars, one for off-licences, and so on. The searches I make to Google’s local search look something a little like this:

http://ajax.googleapis.com/ajax/services/search/local
    ?v=1.0
    sll={$sll}
    radius=1
    q={$thing}%20loc:{$sll}
    key={$apiKey}

Lets walk through those query string parameters…

• sll doesn’t actually stand for anything according to the docs, but denotes the centre point of of the search you’d like to perform. It’s a comma separated latitude/longitude value, so you’d use something like 52.2282962,0.1537945 for this parameter.

• radius is the radius around the centre point that you’d like to search within, in miles.

• q is the most important parameter by far though; being the query term for the thing you’re wanting to search for.

  You’ll notice that I’ve added a loc: onto the query. It turns out that without this undocumented extra bit of data, Google really doesn’t return much from its local searches. Before last week’s post I wasn’t using this extra qualifier, and whilst my searches were being centered around the expected point they weren’t returning much data.

  A case in point was around The Bricklayers Arms. Without the loc: qualifier The Bricklayers Arms was nowhere to be found. With the qualifier it suddenly started being returned by the searches to Google, along with a whole bunch of other local pubs.

Interpreting the Data

So, if that’s the search we make, what does the data we get back look like?

{
    "responseData": {
        "results": [
            {
                "GsearchResultClass":"GlocalSearch",
                "lat":"59.334743",
                "lng":"18.063034",
                "accuracy":"8",
                "title":"\u003cb\u003ePub\u003c/b\u003e",
                "titleNoFormatting":"Pub",
                "streetAddress":"Hötorget 13",
                "city":"Stockholm",
                "country":"Sweden",
                …
                "phoneNumbers":[
                    {"type":"","number":"08-782 19 30"},
                    {"type":"","number":"08-789 19 30"}
                ],
                "addressLines":[
                    "Hötorget 13",
                    "111 57 Stockholm, Sweden"
                ]
            },
            {
                // another result
            }
        ]
    }, 
    "responseDetails": null, 
    "responseStatus": 200
}

(The data above is, by necessity, just a snippet of what’s actually returned.)

You’ll notice first of all that each result we get has a GsearchResultClass of GlocalSearch set. This allows easy checking of the data type returned. For our searches, the result class will always be GlocalSearch, but other searches would return values for web searches, images searches and more.

Moving on to the data that actually interests us, each item has the expected lat and lng attributes, along with other useful smidgens of data such as title, streetAddress etc.

Of particular note are the title and titleNoFormatting attributes. You’ll notice that within the title field the word “pub” is encapsulated in encoded bold tags. Two things to note here; first, “pub” was the thing we searched for, so this gets emboldened in the standard display that Google would like to use for results (but we’re still provided titleNoFormatting if we’d like to have access to an unformatted string). Second, any formatting applied by google in its API results will be encoded in this way. In Beer Near Me, I take the easy way out for the data I’m needing, and use titleNoFormatting.

Moving away from the data that comes from a single API request, lets take a quick look at what happens once we move into the world of performing lots of searches at once. Since with Beer Near Me I’m making multiple calls to Google to gather beer related locations, there’s the pretty large possibility that more than one of the searches will return the same place within its results. The deduping I do on Beer Near Me is very simple in this case – I simply keep track of the latitudes and longitudes of all the places that have been returned. That way if any locations turn up in a position that’s already had data assigned it it I can ignore it. It’s not perfect, but it does the job well enough.

Caching the Data

The last thing I want to briefly mention that I’m doing with the data is caching it using PHP’s APC.

This was the first time I’d attempted using APC on one of my own projects, so I had to install it on my Ubuntu based dev box. I did that following these instructions.

The reason for using APC to cache the calls to Google’s Local Search is simple – network calls are expensive and slow. With on average five calls to Local Search occurring on each page load on Beer Near Me you’d hope that they wouldn’t be having to go across network every single time. So, I implemented a very simple cache check:

$url = "http://ajax.google…q=somesearch"
$urlHash = md5($url);

// Try and pull the data from cache
$results = apc_fetch($urlHash);

// If we don't find the data in cache we'll have to make
// an expensive call across the network.
if (!$results) {
    // Get the data however you'd normally get it
    …
    $results = curl_exec($ch);

    // now store the data in APC
    apc_store(
        $urlHash, // Key to identify the cache by
        $results, // Data from our curl call to store 
        $ttl      // Seconds - how long we'll cache for
    );
}

As you can see above, I’m only using two APC methods – apc_fetch and apc_store. Really, this is all you generally need for simple caching; one method for getting the data if it already exists, and one for storing it in the cache if you had to get the data from elsewhere.

With that in place, any further requests to that same location will be a lot faster, since we’ll have stored the results locally. Result. For Beer Near Me I can afford to be fairly aggressive with our caching, since for the most parts new pubs and cocktail bars won’t spring up over the course of a few minutes and become immediately available in Google’s search results.

No more locations

And that’s it. As far as I’m concerned, that’s everything I’ve done so far on Beer Near Me. It’s been a fun little weekend project, and whilst there’s more I’d like to do with it at some point, I think I’m going to leave it alone for a few weeks now. After all, Science HackDay is in just over two weeks time, and no doubt I’ll get wonderfully caught up in something new for that. Hopefully whatever I hack on will even be useful.

Now, there are lots of tutorials out there for the JavaScript based Google Maps API. So, if you want to learn how to use the JavaScript based API, then I urge you to pop off and look at one of those. For Beer Near Me, I started off using that API. However, for various reasons (slow to download over the phone network, scrolling issues on the iPhone), I decided to move away from that and towards the Google Static Map API. The big win for me in using the Static Map API is that it means the user only has to download a single image into their browser, and all the hard work of putting the map together is done on the server-side. The negatives are that you don’t get nice clickable areas on the map for free, and you don’t get to scroll around easily.

For me, the positives outweighed the negatives, so I went with the static map.

http://maps.google.com/maps/api/staticmap
    ?sensor=true
    &size=320x300
    &zoom=15
    &maptype=roadmap
    &mobile=true
    &center=lat,lon

As you can see, although there are a whole bunch of parameters needed to put a map together, they are all fairly simply. Lets walk through them one at a time:

• sensor: Required; either true or false. This simply tells google whether or not we used a sensor to generate this maps’s position. For us, this will always be true.
• size: Very simple, just width, an ‘x’, and then height in pixels.
• zoom: How zoomed in you are. 15 gives you a pretty zoomed in map.
• maptype: For us, a roadmap is what we want. You can also choose satellite or terrain, the same as if you were using the Google Maps site.
• mobile: Setting this to true allegedly gives you slightly simplified maps that have a lower weight.
• center: Finally, where the centre of our maps should be. Simple.

Put it all together and you get something a little like this.

Adding some custom markers

But, that’s a bit boring. Normal Google Maps let you add all sorts of custom icons. Well, we can do that too, by adding one or more markers parameters to the image URL. So, to add three icons to a map, two of them the same and the third different, you’d add something like the following to the above URL.

markers=
    icon:http:%3A%2F%2Furl.encoded%2Fimage.png
    |shadow:false
    |52.2282962,0.1537945
    |52.134152,-0.486364
&markers=
    icon:http:%3A%2F%2Furl.encoded%2Fotherimage.gif
    |shadow:false
    |52.135472,-0.491835

And that’s all there is to it. After you whack a load of markers onto the URL you’ll end up with something like the Tottenham Court Road on Beer Near Me, where you can see, amongst all the other drinking establishments, The Bricklayers Arms – the home of Pub Standards (the middle thursday of every month – tell your friends).

Making the map clickable

You might also notice on that page that if you click or tap on any of the icons on the map that you end with a popup telling you about the place. But how is this possible? Aren’t we using Google’s Static map API?

The answer is “yes, we’re still using Google’s Static map API”, but we’re using a little sliver of progressive enhancement to layer data on top of it. If you turn JavaScript and CSS off for a moment, you’ll notice a couple of lists underneath the map image. The first contains links which have targets pointing to the relevant items in the second list. So, with no CSS or JavaScript clicking the links will move you through the page to the data. Useful, but not yet useful enough.

So, what if the user has CSS enabled? What can we do then? Well, what I chose to do on Beer Near me was to position each of those links over the icon they were assigned to. First off, all the icons were the same size, so I created some base CSS that I could hang the final positions off:

#map_canvas {
    position: relative;
}

#map_canvas .marker,
#map_canvas .marker a {
    display: block;
    width: 30px;
    height: 30px;
    overflow: hidden;
    text-indent: -9000em;
    list-style: none;
}

#map_canvas .marker {
    position: absolute;
}

Of course, if we just did that then all the clickable areas on the map would be dumped up in the top right of the map, and no-one would be happy. So, we need to work out where to put those top and left directives.

Warning. Hard-coded Assumptions Incoming

Now, it turns out that if you’re zoomed in to a Google zoom of 15 then each pixel equates to roughly 0.0000266667 units of latitude and 0.0000421875 units of longitude. So, we can use this to work out where we’d like to position our clickable elements.

Lets take an example:

You have created a map that is 320 pixels wide and 300 pixels high, and zoomed to a level of 15. The centre of this map is at 51.510953,-0.133012.

A public drinking establishment (De Hems) exists at 51.512081,-0.131288. Assuming a 30×30 clickable area with its centre at De Hem’s location, what should the top and left co-ordinates of the clickable area be?

On Beer Near Me, I work out the numbers using some code that looks something like the following.

$mapHeightPix = 300;
$latPerPixel  = 0.0000266667;

$centreLat    = 51.510953;
$locationLat  = 51.512081;
$latDiff      = $locationLat - $centreLat;

$topPix = ($mapHeightPix / 2) - (int)($latDiff / $latPerPixel) - 15;

Unsurprisingly, there’s something remarkably similar for longitudes. (If you’re wondering, the answer was top: 93px; left: 185px;).

Now, with that code in place to position the clickable areas on the map users can click and be taken to the relevant item further down the page. On Beer Near Me I then layered on top some JavaScript to do a simple popup (again, look at the Tottenham Court Road page), but I’ll leave that as an exercise for the reader.

And that’s essentially that. What started as a simple weekend project to learn how to use the navigator.geolocation API ballooned slightly to encompass Google’s local search API and static maps APIs, and I ended up with something slightly useful. Maybe in a year or two I’ll have even made it pretty.

After all, having a latitude and longitude is all well and good, but as humans we tend not to think that way. So, it would be quite nice to give the user a street address identifying their location. As it turns out, this is pretty easy – the Google Local Search API has this functionality baked in.

http://ajax.googleapis.com/ajax/services/search/local
    ?v=1.0
    q=lat,lon
    key=yourgoogleapikey

If you add your comma separated latitude and longitude to the structure above, Google will very helpfully return you back a load of data that tells you where it thinks you are:

{
    "responseData": {
        "results": [{
            …
            "title": "Kelly Langley…",
            "streetAddress": "Cowley Road, Cavendish House…",
            "city": "Cambridge",
            …
        }]
    }
}

This is only a chunk of the data that gets returned by Google, but hopefully it should be enough to give you a taste of what’s available. The obvious thing to do at this point is grab the street address, and maybe the city, and output them as a string to show the user. This is what Beer Near Me is currently doing.

One piece of data we haven’t used yet though is the accuracy data that is returned by navigator.geolocation.getCurrentPosition. You’ll remember from the last post that accuracy is measured in metres and shows the confidence that the browser has of the location it’s returned. So, if accuracy is given as 500, then the user might be anywhere within a half kilometre radius of the given location – not particularly accurate, and saying that they were on a specific street would be misleading. If, on the other hand, the accuracy given was 25 then the user would be expected to be within a 25 metre radius of the given location – pretty damn accurate.

So, what can we do with this? Well, if we’re not happy that the accuracy is good enough then we could tell the user they were “Somewhere in city” instead of simply showing them the street name of their location. On Beer Near Me, I could also stop the “Find me some beer” button from working until the accuracy was good enough.

So, that’s how I’m dealing with showing the user where they are in a nice human readable way on Beer Near Me – it’s pretty easy, right? In the next entry I’ll finish off talking about the navigator.geolocation API by putting the user’s location onto a static Google Map.

I’ve split the presentation I gave up into three separate blog posts, which I’ll be putting up over the next few days. This one will cover basic use of the navigator.geolocation API, with the next two showing you how to use the data that gives you to find out where the user actually is, and to plot that data using Google’s static maps API.

To start, I should explain that Beer Near Me was only ever intended to be used as a platform to be used to help me learn about the navigator.geolocation API and how it works. All the data that gets shown by the site was initially kind of secondary to me, as was the map that I use to show it off.

Of course, navigator.geolocation turned out to be far easier to work with than I expected.

Support for navigator.geolocation

The first thing to be aware of is that right now, support for navigator.geolocation is pretty poor. If you’re using Firefox 3.5+ or Mobile Safari you can use it out of the box, and you can turn on geolocation support in Chrome, but apart from that you’re plain out of luck. Since the idea behind Beer Near Me was to learn about navigator.geolocation that means that right now I’m not supporting any other APIs.

It’s not all doom and gloom though. There are implementations of the API available for use in other browsers as plugins – for example Geode will get you support in earlier versions of Firefox 3, and Google Gears opens up the ability to play with geolocation in some other browsers. There’s also Loki (a Skyhook based plugin) that will get you support over a whole bunch of browsers but uses a differently specified API. Of course, I’ve not actually used any of these, so your guess is as good as mine as to whether they are any good or not. I seem to remember Loki looking interesting a couple of years ago.

Finding a location

So, how to actually use navigator.geolocation? Well, a good place to start would be checking whether the browser supports it. We’ll do this in JavaScript, since that’s the only place we can reliably perform the check.

if (navigator.geolocation) {
    // do geolocation
} else {
    // say sorry to the user
}

Pretty simple. It’s your standard JavaScript functionality check. If we have the functionality available then we can actually do something with it.

navigator.geolocation.getCurrentPosition(
    foundLocation, // a user generated function
    noLocation,    // yup, user generated too
    {
        enableHighAccuracy: true,
        maximumAge: 1800,
        timeout: 30
    }
);

Here, we’re calling getCurrentLocation() with two callback functions and some options. Once the browser (and the user) has decided whether or not to return a location, either the foundLocation or noLocation functions that you get to write are called, and the user’s location is passed into them.

Before we get to those callback functions though, lets talk for a minute about the options we’re passing into getCurrentPosition(). Essentially, what we’re saying in the code above is:

Try to give me highly accurate positioning if possible. I’d like to actually know where I am.

Oh, and if you have a position cached that’s no older than 30 minutes, could you give me that immediately please? I know that kind of contradicts what I said a moment ago, but I know better than you.

And one more thing – if it takes you longer than 30 seconds to work out where you are, just give up. There’s a good fellow.

And that’s it really, with that little bit of code we’ve set up the browser to do some magic and try and work out where it is.

Watching for changes to the user’s location

The only problem with this is that the iPhone in particular seems a bit rubbish at following these instructions. The first result it sends back seems to be uniformly Not Good, and generally quite old. So what can we do about that? Thankfully, there’s an easy answer provided to us in the API – the watchPosition() function. This uses exactly the same parameters as getCurrentLocation() and can simply be dropped in as a replacement for it.

watchPosition does what you’d expect it to do. Instead of finding a location once, it will keep watching the user’s location and call the success function whenever the location changes. The thing that watchPosition() is most useful for though, is getting more accurate locations as the user’s device tries different location finding techniques.

You see, different devices will try and locate themselves in different ways. Some of the techniques they’ll use will be be quick, some slow, and some very expensive when it comes to battery life. For example, here’s what the iPhone does, as I understand it:

1. First, the iPhone will look to see if there’s a location cached in its memory and give you that if available.

2. If you’re still watching for new locations, it will then try and grab a general location from the cell towers it knows about.

   Depending on the number of towers available, this might give you really good, or really bad accuracy. For example, in Bedford (where I live), using cell tower triangulation I get an accuracy which basically covers the entire town. Not particularly useful. It is quick though, and doesn’t really cost much in terms of power.

3. If the cell tower triangulation wasn’t awesome then the iPhone will gather information about all the WIFI hotspots it can see.

   This data gets sent to Skyhook, which does a whole bunch of triangulation and sends back a result. This is obviously slower than just hitting the cell towers, but it can give you a really accurate result depending on where you are (better than GPS in some built up areas).

4. Finally, if you’re still looking for a location, the iPhone will fire up the GPS.

   This is expensive, slow, and drains the battery, so is left as a last resort. It generally gives the best quality results though.

So, you see, things aren’t necessarily as simple as asking for a position. A whole bunch of stuff can be going on in the background, and grabbing the best location the user’s device knows about as time goes on can be very useful.

Using the location we’ve found

So, now that we’re requesting a location, what do we do once we actually get one? Lets have a look.

foundLocation = function(position) {
    // position.coords.latitude
    // position.coords.longitude
    // position.coords.accuracy
    // and more…
}

As you can see, the function we call on location finding success gets passed a single parameter – position. This object contains a coords object, and a timestamp representing the time the location was determined. It’s the coords object we’re interested in right now, since that contains the latitude, longitude and accuracy (measured in metres) of the user’s current location – all the information a grown chap could need for finding some beer. Other applications might make use of the altitude, heading and speed information, but that’s not vital when looking for beer, so I’m ignoring it for now.

Putting it all together

Quickly putting all this together, here’s some JavaScript you can copy and paste into a page to see this all in action.

/*global document, navigator */
var beerLocation = {
    foundLocation: function (position) {
        beerLocation.setPara(
            "Lat = " + position.coords.latitude + 
            ", lon = " + position.coords.longitude + 
            ", accuracy = " + position.coords.accuracy + "m");
    },

    noLocation: function () {
        beerLocation.setPara("Boo! You didn't share your location!");
    },

    noGeoLocation: function () {
        beerLocation.setPara(
            "Sorry, but your browser doesn't support geolocation.");
    },

    setPara: function (text) {
        var p = document.getElementById('location-info');
        if (!p) {
            p = document.createElement('p');
            p.id = 'location-info';
            document.body.appendChild(p);
        }

        p.innerHTML = text;
    }
};

if (navigator.geolocation) {
    navigator.geolocation.watchPosition(
        beerLocation.foundLocation, 
        beerLocation.noLocation,
        {
            enableHighAccuracy: true,
            maximumAge: 120000
        }
    );
} else {
    beerLocation.noGeoLocation();
}

Alternatively, take a look at it in situ and in action on my geolocation test page. The location shown by this page will keep updating as you move around or your device’s accuracy improves. For best results, try it out on an iPhone.

And finally

And that’s how easy it is to find a user’s location and keep updating it. You just need to do something with the latitude and longitude once you’ve found it.

In Beer Near Me I do two things with the location once it’s been found – I tell the user the street address of the location, and I display it on a map. And, of course, I’ll be writing about how I’m doing that in the next couple of posts.

I’ve only just got round to reading the book, but I’m glad I did. As a learning book it’s deliberately quite lightweight and easy to get through in a short time, in the same way that Steve Krug‘s “Don’t Make Me Think” is designed to be absorbed in a couple of hours on a flight. All told, I spent about three hours with this book, on my tube journeys to and from work this week.

Robin starts her journey by briefly explaining the concepts of Contrast, Repetition, Alignment and Proximity (anyone spot an acronym there?), before moving on to explore each concept in greater detail. As Robin repeatedly tells us in her book, by being able to name the concepts you’re able to identify them and use them deliberately rather than accidentally.

The second half of the book deals with type; the different styles of typefaces, how to combine them and horrible errors of judgement to avoid.

Spread throughout the book are a bunch of mini quizzes and exercises designed to get you thinking about what you’ve just read. The quizzes are a nice touch, and I’m sure I’ve retained more knowledge because of them than I would have done if I’d just read through from cover to cover.

The book covers design in general, rather than being focussed on the web, print or presentations. Whilst Williams has written a book called “The Non-Designer’s Web Book” I specifically chose to buy this one because both I wanted a general overview book and because the web book is from 2005 (a lifetime ago on the web) and has some mixed reviews. “The Non-Designer’s Design Book” did not disappoint – it’s given me that overview that I was looking for, and I now feel a bit more comfortable that my designs will actually work.

“The Non-Designer’s Design Book” costs £23.99 in all good bookshops, or currently £12.30 on Amazon.

Another post, another chance to point to Lay the Table and show off a different recipe than the one Becs used. This time it’s for big fat nommery Chocolate Orange Cupcakes.

The cake mix is a fairly standard mix, with a bit of good quality cocoa powder thrown in. On top of that you have a nice fruity orange sugar syrup, all topped off with some zesty orange frosting.

Takes a couple of hours all told, ideally with a day in the middle. 20 minutes cooking time for the cakes.

These ingredients make 12 normal sized cupcakes or 24 little ones.

Ingredients

Zesty Orange Frosting

• 150g icing sugar
• 100g cream cheese (full fat!)
• 50g unsalted butter
• The grated zest of two oranges.

Orange Sugar Syrup

• The juice of one orange (about 5 tbsp)
• 75g caster sugar
• 1 tbsp Cointreau

Chocolate Cupcake base

• 100g unsalted butter
• 100g caster sugar
• 2 medium eggs
• 85g self raising flour
• 15g cocoa powder

Instructions

Zesty Orange Frosting

1. Cream the butter and sugar.

2. Add the cream cheese, and mix this in too.

3. Grate the zest of two oranges and, you guessed it, add this into the mix as well!

   Don’t chuck the oranges though – you’ll need one of them for the syrup.

Orange Sugar Syrup

1. Juice one of the oranges you had left over from the frosting.

2. Bring the orange juice and sugar to the boil, stirring to dissolve the sugar.

3. Let the syrup cool, and then stir in the Cointreau (or other orange liqueur if you prefer).

   Yes, this means there will be a tiny bit of alcohol in your cakes. If you’d prefer there not to be, just add another tablespoon of orange juice instead at this point.

4. Leave to infuse overnight if at all possible to let all the lovely flavours intermingle. If you can’t wait, then start making the cupcakes now instead.

Chocolate Cupcake

1. Preheat the oven to 160ºC.

2. Cream the butter and sugar.

3. Lightly beat the eggs, and slowly add them to the mix – combine on a medium speed.

4. Once the sugar, butter and eggs are combined, mix in the flour and cocoa powder at a low speed.

   That’s your cake mix – nice and simple.

5. Put your mix into your cupcake cases, and from there into the oven for 18-20 minutes.

   I use a children’s plastic icing plunger to place my cake mix into cases. I find this is much easier than using spoons, and quicker than using a proper icing bag (which is use for the proper icing).

6. Once the cakes have cooked, leave them to cool for ten minutes if you’re making normal cupcakes, or five minutes if you’re making mini ones.

7. Prick the top of the cupcakes a few times with something pointy like a cocktail stick, and using a pastry brush coat the tops with the sugar syrup.

   Be careful not to splash syrup everywhere, but also remember that the syrup is fantastic and will keep the cakes lovely and moist and add flavour so don’t be stingy. Don’t be worried if you have a load of syrup left though – that’s normal.

8. Once completely cooled, you can ice the cakes using your preferred method.

9. Finally, eat the damn cakes!

Last weekend was Becca’s birthday, and since I’d been promising her I’d make her a birthday cake I ended up scouring the internet for a nommy sounding recipe. Somehow I managed to miss the fabulous sounding recipe that Becs recently posted on Lay the Table, and instead settled on one from the BBC Good Food website, even though if I’m honest it didn’t visually appeal to me too much. As Becca said about the Good Food cake: “It looks like a f*cking breezeblock!”.

I’m ridiculously happy that I looked past that initial photo. What I ended up with after I tweaked things a bit was frankly fantastic. It’s ridiculously rich though, and definitely not something I could see myself making every week – it’s most certainly a treat cake.

Takes one hour and fifty minutes – twenty minutes preparation of the cake, one hour cooking, half an hour icing.

Ingredients

For the cake:

• 250g self raising flour
• 250g soft brown sugar
• 50g cocoa
• 250g plain chocolate
• 250g butter
• 4 eggs
• 200ml water

For the sauce and icing:

• 150g plain chocolate
• 250g milk chocolate
• 300ml single cream
• 25g butter
• 700g icing sugar

Instructions

The Cake

1. Preheat the oven to 160ºC.

2. Mix the flour, sugar and cocoa in a bowl.

3. Melt the chocolate, butter and water together in a pan.

4. Allow to cool slightly, and beat the wet into the dry mixture along with the eggs.

5. Dollop your mixture into a cake tin and bake for one hour.

The Icing

1. Whilst the cake cools, it’s time to make the icing.

   Melt the chocolate, butter and single cream in a pan, and mix until it becomes smooth and comes together.

2. Allow the sauce to cool for about 20 minutes.

3. Beat in about 250g of icing sugar.

   At this point the sauce should be rich, thick and dark.

4. Slice the cake in half, and spread as much of the sauce as you want between the slices. Put the top of the cake back onto the bottom.

5. Beat in the remaining icing sugar.

   The sauce will now have become icing, will be a lot lighter in colour and will form peaks in your bowl.

6. Apply the icing to the cake. Make it as messy as you want – there’s something magical about a fully iced cake covered in dozens of little peaks and troughs.

7. Allow the cake to set.

   Over the next couple of hours the icing will harden, allowing it to crunch when you bite into it. The inside of the cake and the rest of the icing will remain wonderfully moist and rich.

8. Host a party, or take the cake into work. This is one cake you certainly don’t want to keep to yourself.

I’m a big fan of flapjacks – they’re sweet and oaty and fruity and yummy. Even better, they’re gluten-free, so my coeliac friends can eat them too.

Most of the time I make mine with cherries and sultanas, but it’s just as easy to substitute in other ingredients.

Takes 10 minutes to prepare, 20 minutes to cook.

Ingredients

• 150g unsalted butter
• 200g light brown sugar
• 4 tbsp golden syrup
• 350g porridge oats
• 150g sultanas
• 100g glacé cherries

Instructions

1. Preheat oven to 180ºc

2. Melt butter, sugar and golden syrup in a pan.

3. Whilst the meltening is happening, chop up your cherries. I tend to take them down to quarters.

4. Once everything’s melted remove from the heat, and mix in the oats, cherries and sultanas.

5. Press into a tin, and cook for 20 minutes in the oven.

6. Once it’s out of the oven, let the flapjack cool for a few minutes before scoring it deeply into portion sized pieces.

7. Once cold, turn out the flapjack and break into pieces.

Anyway, enough of the pre-amble, lets see why I decided to do an unboxing of this t-shirt (all images link to larger versions on flickr)!

The t-shirt arrived in a nice simple, black posting bag, but it was immediately obvious to me that it didn’t just contain your average, limply inserted t-shirt. Oh no, it was obvious there was something more in here. Some sort of box.

A box covered by nothing less than the highest grade of bubblewrap known to man. (Okay, I might be overegging the pudding a little here, but it was wrapped in bubblewrap. You wouldn’t want the box getting damaged in transit now, would you?)

Of course, being an inquisitive chap I ripped the bubblewrap off the box and discovered a wonderful piece of custom artwork on an old-school VHS tape case. Frankly, this is a level of commitment I have never before seen in any t-shirt that I’ve bought. Of course, I’ve never bought anything that was in a limited edition of 50 worldwide before either, but that’s beside the point. Going to the trouble of creating a second piece of artwork to contain the t-shirt that I was actually purchasing is above and beyond the call of duty.

The box has a whole load of wonderful little touches, such as the rating certificate of “DB: Suitable only for persons of a really cool nature and an unatural (sic) love of film”, and the statement on the front that reads “…Life is a war, be a hero. Be a hero in an awesome t-shirt…”. This packaging makes me happy.

The t-shirt itself is also pretty damn fab. The weight is great, and the feel of the cloth is smooth to the touch. It’s a pity that the tiny text on the design is almost impossible to read, but that’s a very minor criticism. Other than that the design has transferred fantastically from Photoshop to t-shirt.

So, congratulations Alex. You’ve successfully made me happier opening this t-shirt than anyone has ever done before. Good job.

“Robocop: Directive 3 Baby Food” is part of a limited run of 50 t-shirts from Dark Bunny Tees, and is apparently still available for £25 from the website. You’d better get your skates on if you’re a fan though – I wouldn’t bet on it being around for long.

It takes about 15 minutes to cook and tastes fantastic. Serves 2.

Ingredients

• 4 – 5 rashers of bacon (we use Sainsbury’s Be Good to Yourself Bacon Medallions for this)
• 1 courgette
• Garlic puree
• 150g “light” creme fraiche (we used TESCO’s Healthy Living Creme Fraiche today)
• 4-5 balls of Tagliatelle
• Olive oil

Instructions

1. Slice the courgette in half lengthways, and then slice each half finely. Add it to a large frying pan with a little bit of olive oil and a good squeeze of garlic puree. Mix, and fry on a medium heat for a few minutes until soft.

2. Whilst the courgette is softening, remove the fat from your bacon and slice’n'dice into small pieces. Once the courgette is soft add the bacon to the pan. I tend to turn the heat up a bit now to brown the courgette a bit.

   If you want, you can add even more garlic puree at this point. Don’t forget to give everything a good mix.

3. Now that your bacon and courgette is frying, put your tagliatelle into a saucepan and start cooking it. We tend to put four to five balls in. This will be cooked in about 7 minutes.

4. Once the bacon is cooked, it’s time to add your creme fraiche. Just dollop it into the frying pan and mix. It’ll start to turn a creamy yellow colour as it pulls in the lovely juices from your bacon and courgette.

5. Give it a couple of minutes, then drain your tagliatelle and add it too to the frying pan. Mix everything together and serve immediately. Grate some parmesan on top if you’re feeling that way inclined.

Nommy.

It’s because of my love of ED-209, that loveable rogue from the Robocop films, that Becca bought me this wonderful t-shirt for Christmas. It’s one I’ve had my eye on for some time, since seeing it on Last Exit to Nowhere last year. Last Exit are one of those places that I end up going and looking at quite a lot, because they have rather nice movie based imagery that isn’t just a straight lift and shift from the movies in question.

This, however, is the first t-shirt that I’ve ended up getting from them. Normally I wouldn’t go for t-shirts that are printed on a white or creamy fabric, but since Becca bought this for me I didn’t have much choice. Frankly though, in the flesh I rather like this one. As a larger chap, I tend to think they help to make me look even bigger than I am, but happily this doesn’t seem to be the case with this one. This despite the fact that when I unwrapped it on Christmas morning I was convince that I’d been sent a t-shirt one size larger than I needed!

As it turns out, although the t-shirt was the same size as everything else I own, the neck was considerably larger and the shoulders a bit wider. A bit weird, but nothing that was off-putting to me once I put the t-shirt on.

“ED-209” is available from Last Exit to Nowhere for £18 and is printed on an “ice grey” shirt of no specified brand. And yes, I would buy that for a dollar.

Takes five minutes to prepare, then take as long as you want to drink it.

Ingredients

• 2 shots of rum
• Half a lime
• 2 teaspoons of granulated sugar
• 10 mint leaves
• A whole bunch of crushed ice
• Soda water if you really want it

Instructions

1. Spoon two tablespoons of granulated sugar into your cocktail shaker. Squeeze half a lime onto this, making sure to get as much juice out as you can. Drop the leftover husk of the lime in too. Now throw 10 or so mint leaves in as well (take them off the stalks).

2. Here’s where the magic happens – muddling the sugar, lime and mint together. If you’ve already got a muddler then great, use that. Otherwise, do as I do and use a simple wooden rolling pin.

   Push down into your mixture with your muddler, rotating as you do. This crushes the mint into your sugary limey mixture, releasing its essential oils and wonderful flavours as you do so. Remember how mint leaves don’t really smell of anything until you rub them together in your fingers? That’s what is happening here.

   Give it a good bit of pressure, and you’ll only need to muddle for a few seconds. We’ll now leave this to sit for a minute or two whilst we prepare the ice.

3. Fill the glass you’ll be making the mojito in twice with ice (I use a chunky half-pint glass), and empty this out into a tea towel. Gather the tea towel up to make sure none of the ice can escape, and then give it a few thwacks with a mallet. We use a cheap wooden one – it works a lot better than using the rolling pin again.

   Once the ice is sufficiently pulverised, add it to your glass. You’ll find that what once filled the glass twice should now pretty happily fit in just the once.

   The reason we crush the ice like this is to increase the available surface area to cool the liquid in the drink. If we do a good job of crushing it, we’ll end up with things getting so cold that the outside of the glass frosts over. Lovely.

   As you can see, these mojitos use a lot of ice. For this reason we tend to keep bags of the stuff in the freezer, just for cocktails.

4. We’re back to the cocktail shaker now, and we’re finally getting to the alcohol.

   Add a couple of ice cubes to the shaker, pour in two shots of your favourite white rum, put the top back on and shake roughly. Once you’ve finished shaking and everything’s mixed together nicely, strain into your ice-filled glass.

   Your ice will turn green as you pour over it, and you’ll get some tiny pieces of mint seeping through your drink.

5. At this point, I’d be done. I don’t think that these mojitos need anything adding to them to water them down, but depending on how you like yours you might want to. So, if you want to, add some soda water now.

6. Finally, add a straw and some mint to garnish, and sip happily.

Takes 30 minutes – 10 minutes preparation, 20 minutes cooking.

Ingredients

• 170g unsalted butter
• 50g granulated sugar
• 1/2 tsp vanilla extract
• 210g plain flour
• a pinch of salt

Instructions

1. Preheat your oven to 180ºc.

2. Cream the butter and sugar, then beat in the vanilla extract.

3. Add flour and salt, and mix until everything’s come together.

4. Press hard into a tin and bake for 20 minutes, or until slightly golden.

   If I’m making this Shortbread to turn into Millionaire’s Shortbread I like to line the tin with foil to make turning it out later easier.

5. Once the Shortbread comes out of the oven, if you’re just going to keep it as Shortbread then you might like to score it with a knife to make it easier to break into nommy pieces once it’s cool.

It’s unclear who has the upper hand in this shirt. Maybe the robot is just a gardener trying to trim back his garden. Maybe he was just taking a stroll when the plants attacked him. Maybe he’s some juvenile delinquent robot who just likes setting fire to things. Whatever the case, it makes for a nice t-shirt.

The thing I love most about this t-shirt though is the incredibly fine printing. It’s not something that came across in the photos on Uneetee’s site, but the printing really is fantastic. The design is made up of hundreds of individual strokes, resulting in an image that feels both old and new at the same time. The fact that the design isn’t made up of large blocks of colour also means that it breathes nicely during the summer. Not much of a problem this week, with all the snow that’s falling, but it’s good to know nonetheless.

“The Robotanist” is available from Uneetee for $18.99 and is printed on a dark green American Apparel shirt. It’s sold out if you’re an extra large man like me, but there are still a few available for everyone else.