One interesting quirk of Pinboard is a complete absence of unit tests. I used to be a die-hard believer in testing, but in Pinboard tried a different approach, as an experiment. Instead of writng tests I try to be extremely careful in coding, and keep the code size small so I continue to understand it. I’ve found my defect rate to be pretty comparable to earlier projects that included extensive test suites and fixtures, but I am much more productive on Pinboard.

This quote is by Maciej Ceglowski and I can't agree enough.  When writing code I focus on understanding the problem and breaking it down in my mind (and the code) to manageable parts.  I then prototype the code, mess around with naming, strucutre it logically and only when I'm happy do I write tests at the end.  This is the exact opposite of what most test first die-hards would recommend.

I've found several issues with the traditional test first approach that have led me to write code this way:

• At the start when writing tests you don't understand the problem and must think it through. You invariably forget stuff in the same way you forget to spec out stuff when writing a 20 page spec if developing by the waterfall method.  By writing code first you actually get into the problem and work through exactly what is needed.
• You don't write code to make the tests pass.  This is dangerous as you lose the big picture of the problem you're trying to solve.  Instead you write code to make a test pass and there's no guarantee that the test suite you write is complete.  In fact nearly every time I've been pairing using test ping-pong the developer finds missing tests.  This highlights the downfall of such an approach.
• Tests can't be used as an excuse for defects.  I've worked on several client projects with other companies where the party will respond to an issue on a live site by writing a test and fixing it, passing responsability to the missing test (which they didn't write to start with). This is good practice at a technical level but infuriating from the clients point of view.  Why did this happen?  Because you forgot to write a test and missed out some functionality.  By writing the code first you get into the problem and understand it better so are less likely to miss areas of functionality.  As a second benefit it stops you shifting the blame to tests and makes you face up to the client.  This makes you really think things through when writing critical code.

To be clear I do value tests and for two reasons - as a protection against introducing regressions and as a sanity check at the end of writing a feature.  These tests can be easily written by somebody else against your final API with them working through the logic of the problem as well.

How well does it work?  Last years ago I wrote 5ft Shelf which has had 150,000 page views to date, runs on 10,000 lines of code and has had 3 bug reports.  Digital Delivery App has only been live a few months, runs on 4000 lines of code, and has had 1 bug report so far.  These rates are hugely lower than the other 10 or so rails projects I've consulted on (note most of these, but not all, are multi-developer projects which leads to greater bug rates due to developers incorrectly internalising how the application works)

Strongly linked to keeping my defect row low has been a constant drive for simple code above everything else.  This means not using the latest gem because it's fresh off the shelf & cool and not using some eleborate mega encapsulation system because you understand everything better than anyone else could possibly ever.  In the city (financial district of London) they call this "mental masturbation".  Less crudely Paul Battley sums this up perfectly with "narcissism is one of the biggest causes of technical problems".  Simplicty wins above everything else.

Permalink | Leave a comment  »

Just a quick note to say I've migrated my blog to Posterous. This post will hopefully trigger feedburner to pickup the new feed as well.

Permalink | Leave a comment  »

Recently Gmail rolled out a series of user interface improvements that I didn't really like. I tweeted about the changes and seemed to get many replies in agreement. Top of my annoyance list was adding a Mail/Contacts/Tasks context switch as the top most item on the left hand side. My annoyance was that the context switch seemed unnecessary for my usage of Gmail - I rarely go into contacts and I don't use the tasks area. Whilst I've no doubt both features are useful to other people, I like to keep my inbox lean and minimalist.

After a few days of usage I decided I hadn't adapted to the change and wrote a script to hide the links. I also took the opportunity to make a few other improvements to the standard GMail interface - most notably:

• Removes invite a friend and messenger panels
• Removes the select All/None tickbox
• Remove tips in footer
• Remove search the web button
• Remove adverts when viewing emails
• Makes the inbox area border complete rather than head off edge of the right edge of the screen

For those wondering how you access the contacts once the link has been removed you can do a keyboard shortcut of g then c. To get back to the inbox do g then i.

The difference can be seen in these two screenshots:

Permalink | Leave a comment  »

I'm not sure where the dream first came from but as long as I can remember I've always wanted to run a marathon. I'm not sure what exactly appealed about it since I spent my time as a kid playing football and tennis, not running. In fact I only really got into running when I left school although arguably I was pretty good at it whilst forced to do it in PE. Fast forwarding a few (or rather quite a few) years I joined an excellent running club when I moved to London, and taking inspiration from the fellow runners who had just done Paris marathon, I decided this year was going to be the one to do it. Running sub 3 was something I'd always dreamed of too although I was unsure if that was a realistic target for my first marathon or not. Talking to friends in the club it seems quite a few had tried and failed at what is for most club runners the most symbolic of marathon times (it's quite a nice round number ok?). Undaunted in late October I rocked up to a half marathon to get a gauge of how fit I was and whether this crazy sub 3 idea was going to be achievable. I finished the race in a surprising 1:27:02 and thoroughly enjoyed my first long race, getting lots of support from the locals, a few high 5s round the course and a top 50 finish. Not a bad gauge race and fast enough that I considered a 3 hour marathon a possibility.

Through November and December I concentrated on two main things: building my weekly milage trying to run upto 17 miles comfortably and improving my running technique. The first was quite simple in theory - run 13 miles one weekend, 15 the next, 17 the next and then repeat again. In reality the appalling winter weather, running considerably further than I've ever run before and the logistics of not getting lost around London made this somewhat more difficult than I imagined it first would be. These challenges were fairly insignificant compared to improving my running form though.

There was lots of talk on the running circuit about a book called Born to Run in which the story of an ultra-running tribe called the Tarahumara, the 30-100+ miles they compete in, and the benefits of running barefoot rather than in trainers are told. Although it was documented a lot of the fastest africans ran barefoot as children, nobody was really sure why it had such an effect on running speed. The fact the Tarahumara could run such long distances in flat sandals challenged the concept that buying the most expensive cushioned trainers possible was the best thing to do. In fact the reported injury rate in athletes was much lower before the cushioned trainer came along and the reason is somewhat obvious when all the facts become clear. Given the extra cushioning in modern trainers people start running in a style where they land on their heel rather than mid or forefoot. This is because the trainers heel cushioning encourages such a strike. Landing on your heel exerts much more force through your body though and thus increases the chances of injury. Hopping on your heel rather than forefoot, or trying to run down the street barefoot and landing on your heel, provide a great example of this.

I had spent the previous few years struggling with injuries and ended up buying more and more expensive trainers with additional cushioning to try and combat my injury woes. So reading the Born to Run book seemed like a revolution and convinced me of the need to alter my style. In the end I opted for the ChiRunning technique but the POSE method is fairly similar. Both teach you to run in a way much closer to how we run barefoot and land on either the mid or forefoot. Reducing impact force not only reduces injury risk but makes you more energy efficient over the course of a run and whilst I did spend some time injured adapting to the technique, I have been running much smoother since and spending much less time injured. In fact I've barely been injured at all since switching styles, I use cheaper less cushioned trainers and the trainers last a lot longer too.

By christmas my style was making big improvements and my fitness was starting to increase to the extent that going out for a 15 mile run seemed like no different than a 6 mile jog. Then somewhat inevitably, disaster struck. Over the christmas break I went for a 13 mile run whilst back visiting my parents and jogging along an old route that I used to cycle along, I faced an icy patch. I was only a few miles from home and the backtrack option was a good 6 miles, so I decided to run on with the hope the ice cleared. After a mile or so it eased and I managed to get home fairly unscathed, or so I thought. The next day the tendons in my left ankle were really sore and I was unable to run further than 2 miles. How could I have been so stupid? Right as the critical marathon training was about to kick off I was out injured. And not only that tendons are notoriously slow to heal.

Anger quickly turns to practicality and once back in London I went to see both a Physiotherapist and a Sports Massage person. In the end I found the sports massage to be much better as they actually worked on the problem, forcing blood to the area via massage, ultrasound and acupuncture, which inturn speeds up the healing. Phyios on the other hand spend a lot of time diagnosing the problem and then offering advice on strengthening weak muscles - useful, but not much help for overcoming your current injury. Of course this was my experience and your milage may vary (no pun intended).

In times of injury it's important to readjust your training schedule and try to keep fitness levels high by cross-training. I found swimming and cycling to be best for this although as your heart works at a lower level you need to spend more time doing these activities than you would running - eg 2 hours on the bike is equivalent to 1-1:30 of running. 2 hours on a bike in a gym, if the mental image hasn't already flashed across your mind, is boring as hell and motivating yourself to get to the session can be quite hard. Some intelligent scheduling can normally find a big sporting event on at the same time which helps speed away the time. This year I watched a lot of the Australian Open and really got into F1 - not bad things to do whilst cycling for 2 hours by any stretch of the imagination.

Luckily I had planned some time in to my training schedule to be lost to injury and/or illness (I highly recommend doing this), and as I got back running in early February my dreams of a 3 hour marathon were just about still alive. As the month progressed we moved on to doing a 20 miler every other weekend and a 13-15 miler on the other weekend. This was in addition to 1 interval, 1 medium (8-10 miles) and a couple of recovery runs. In a few weeks I topped over 50 miles per week although my milage was low compared to many (more on this later). I was also learning to pace myself well - or more accurately I bought a Garmin Forerunner 305 which has a GPS built in so you can see how far/fast you're running. It's extremely useful information to know if you're not racing as getting the pace wrong in a 20 mile run is not nice. I remember one training session with a few club mates where 2 of us ended up out front. At 18 miles my friend Dave was struggling and our pace was slipping back to 7:30s, so I agreed to meet him at the end and picked up the pace. I banged out a 6:30 mile and then starting struggling fast. Moving my legs was becoming difficult and as I crossed the finish line going slower than 8 minute miles, Dave shouted my name finishing less than 10s behind me. He was looking fresh and ready for a cool down, I was lying on the floor barely able to move! The lesson had been learnt - 26 miles is a long way and pacing it correctly is critical.

I also learnt the perils of stopping. Trying to even walk after 20 miles feels like somebody is stabbing you with a knife in the back of the hamstrings every step you take. To combat this I settled into a fairly nice routine after long runs. Firstly 5 minutes stretch off and put on compression tights. 2XU are the favourites among my club mates and my experience with them has been nothing sort of fantastic. They work by pumping blood into your muscles helping to clear out the lactic acid and consequently reduce soreness the next day. They also keep you nice and warm which becomes a big issue 10 minutes after finishing. As your body has been hot for so long stopping quickly results in a loss of body temperature, so this was something else that had to be dealt with. I'd put on compression gear, joggers, clean t-shirt, jumper and get somewhere warm if I wasn't finishing at home.

Next most important is to get some kind of fuel back into your body. Running 20 miles burns around 2000 calories depleting your glucose stores and ripping thousands of your muscles fibres to bits. There's a 20 minute window after exercise in which your body repsonds extremely well to any kind of nutrition you give it. The optimum blend (for running) is a 4-1 carb to protein formula. Although best to have this as proper solid food in reality it's not normally possible and a recovery drink is the best option. Also as your stomach shrinks the longer you exercise, it's unlikely you're going to want to drink it. It took me a few weeks to adapt to this but eventually my body caved and started taking it down. Finally you can then get home, shower and crash. And you will need to do crash - some prefer to go to bed for a few hours, personally I struggle to sleep after the post run high so just lied on the sofa for 3 hours under a blanket to keep warm. After that my body started to come round and I could eat and go do stuff. To be honest, the days I did a long run I didn't really do much else although as I adapted over the months it become easier. Oh and one more thing your immune system is weakened for a few days after such a long run so if there's a bug going round expect to get it :( That time crashed out on the sofa helps combat the start of this.

As I trained through February, perfected the recovery strategy and adapted to the increased milage recovering became easier, but the legs were always sore and I was always laid out for a few hours post training. As March rolled round, training was going well and I nailed a 21.5 mile run with an average pace of 6:42 a mile, exactly 10s faster than I'd need to do for the marathon. Surely that made me on target? Indeed it did, the excellent McMillan Running Calculator providing the calculations. Training was also taking its toll on me though and I spent a lot of February and March really quite tired. Luckily the sports massage guy I went to see noticed I was looking slightly anemic.

Training hard puts extra demands on your iron stores as your body increases the amount of red blood cells it needs. It's a fairly well documented phenomena in people training for long distances and its important to get lots of iron in your diet. Once I became aware of this I altered my diet to include more read meat and spinach and took a few teaspoons of Blackstrap Molasses each day. Blackstrap Molasses is produced from the left overs of sugar cane boiled up three times. It sounds, looks and tastes fairly disgusting but it's great for you, containing large amounts of iron, zinc, magnesium and even something that helps your body break down sugar and deal with it more effectively (needless to say they refine this out in for sugar you buy in supermarkets). After just 1 week I was amazed how much difference this made and to this day I still take Blackstrap Molasses a few times a week.

As race day dawned my thoughts turned to race strategy. The usual rules apply here - get there early, drop off your bags, go to the toilet, find your starting area, warm up and go to the toilet again. All the big marathons have "starting pens" which essentially put people of a similar pace together. It's not worth lying on your entry form here as you'll find yourself frustrated by slower runners in front of you or getting knocked over by faster ones coming from behind. If you think you're going to be on a nice boundary though (eg 4 hours) it's worth writing 3:59 as your predicted time. This will ensure you're in the 3:45-3:59 pace group rather than the 4:00 - 4:15 pace group. When there's 30,000 people crossing the starting line, that makes a lot of difference.

Once the race has started I like to make friends with people around me, it's much easier to run with people at the same pace as you. Throughout any race you'll hit highs and lows and running with other people means you drag them along when they're struggling and you get dragged along when you're struggling. My better than expected performance in the forementioned 21.5 miler was because I was running with 2 club mates at the same speed (sadly they both got injured before the marathon so I was running the main event alone). If you're pacing yourself correctly then you shouldn't be out of breath for the first half of the race so don't worry about any performance implications of talking. The other reason it's good to talk to the other runners is it's great for finding out information about the course - runners who have done it before and will point out hard miles, runners who drove the course the day before, or runners who know where there are lots of supporters. It's all great information to know and makes the earlier miles much more fun.

Water and energy strategy is really important. When training I carried a half litre bottle of water for 20 miles. This taught me to operate on less water than I'd get in a race whilst giving me enough to stop dehydration effecting my performance. Energy gels are important for giving your body instantly usable energy too as there isn't enough glucose stores in most people to run 26 miles. They taste pretty rubbish so experiment and find your favourite but I quite liked the Torq ones with Guarana. Some require you to have them with water whereas others don't. The Torq ones definitely require water but I favoured having the water about 4-5 mins after the gel or it made me feel sick. Experiment during training not the actual race!

I mentioned earlier that I did less miles than most other runners my speed. The reason was I took a less is more approach and ran all my long runs (except 1) at or within 15s per mile of marathon pace. On the downside this meant it took longer to recover and I couldn't train very well the following week. On the up side as it was my first marathon it meant I was fairly confident of finishing in the time I expected, knew my pacings well and knew how my body would react. It isn't the most efficient way to train but it gave me a lot of confidence and that was extremely valuable. Consequently going into the race I was confident but not arrogant.

As the last 3 weeks before the main event rolled round I started tapering. Tapering is a period where you reduce your weekly milage by 30%, 50% and then 70% in the final week. This lets your body recover from all your training whilst not losing too much fitness, leaving you in optimum shape for the big day. It's also important to adjust your diet to reflect the reduced amount of training or you will feel stuffed. This can be quite hard to do as pounding out so many miles increases your daily calorie intake by anything from 20-50%. At times during my training I would find myself eating a huge meal and then becoming hungry again 2 hours later, so in the tapering period it's important not to eat for the sake of it or rapid weight gain will ensue! In the final few days you need to build up the carb stores in your body and the best way to do this is to eat lots of slow release carbohydrates. Like many my favourite source become pasta and I'd make pasta bake for the few nights before the race. If you're travelling to the race becareful on where you eat out - anything to creamy or spicy is a bad idea. I had a spicy sausage pasta before my race and very nearly regretted it on race day.

As I mentioned we were due to run in Vienna but unfortunately that was the same time the Icelandic Volcano decided to erupt, grounding all european air traffic. This was gutting, 4 months training and I couldn't get to the start line. Luckily the club is well connected and after a few hours of panic, we managed to get offers of places at both Brighton and Sussex marathons although both had officially closed many weeks earlier. I opted for the Sussex one along with the rest of the club as it provided a half marathon option (which Vienna also did and some had signed up to, whereas Brighton didn't). As the gun went and I raced off I knew something wasn't right. At 3 miles I was struggling to hold pace and by 7 I was stupidly out of breath. I realised something was wrong and there was no point continuing so pulled out. Obviously this was hugely gutting and a massive disappointment after so much training but the next day I came down ill for a few days so I guess I was just unlucky. Thinking back there were a few warning signs the day before but I just put these down to pre-race nerves.

The next week I faced a choice - carry on moping and call it quits till the Autumn marathons or try and get a place in Edinburgh 4 weeks away. I refocused and opted for the later, got a quick weeks worth of training in and started the taper period again. Clearly this wasn't ideal as I had just spent 3 weeks resting so loss of fitness would become an issue. But if anything my pre-marathon races had suggested I'll be a few minutes under 3 hours, so I figured it was still on.

I arrived in Edinburgh the day before the big race to a rather hot 21c. I bought a running cap and prayed for much cooler weather the next day. On waking the sky had clouded over and it was cool walking to the start. Perfect conditions for marathon running in fact. As I entered the starting pen though the sun creaped out from behind a cloud - damn, but not to worry still plenty of cloud cover. By the time the gun went I noticed the cloud cover clearing but I wasn't paying too much attention, the crowds were cheering, the adrenaline was flowing, I started my watch and my second marathon began. Hopefully I'd finish this one.

In the first few miles you have to be really disaplined not to go too fast and keep on target pace. In Edinburgh this is especially true as the first few miles are down hill. I stuck to my race plan and didn't let myself exceed 6:40s. After the first 4 or 5 miles the sky was completely clear and it was clear this whole race would be in the sun. The race start at 10am was less than ideal too and it meant the later parts of the race would be in the midday sun. Bugger. Finally the course in Edinburgh wasn't helping either - it was basically a 3 mile run out the city and then a 13 miles out and 10 miles back to a finish (down the same sparsely populated road). By the time we got on the road at mile 3 it became clear there was going to be absolutely no shade. None of this had to matter though, I could let it matter but I wasn't going to, it was just things to be dealt with.

At mile 6 I started to feel a slight niggle in my left hamstring. Pounding out so many miles in training puts a big stress on your body as you adapt to the increased milage and the rather excellent Trigger Point Therapy Workbook had saved me many times through the months of training. In a race there's nothing you can do though - well actually you can stop but that's not ideal. At this point it was just a niggle so I switched my focus to something else, in this case the other hamstring. This one was fine and by thinking about that I was able to shift the doubts about my left one. It worked well and a mile later I heard no more from my left hamstring all race.

As I came through half way things were going really well. I ran through in 1:28:30, not out of breath and exactly where I wanted to be time wise. Within a few miles though things started to get difficult though. Through the water stations I was grabbing 2 bottles, one to drink and one to pour over myself. This has kept me good to 17 miles but now the sun was really intense. There were more warning signs too - the guy I passed collapsed under a tree, the guy dressed as a superhero stopped and the amount of people I was overtaking who were struggling was rapidly increasing.

Around 20 miles you normally evaluate how you're feeling and if good, pick up speed a bit for the last few miles. This time I knew how I was feeling and it wasn't good. My pace was slowing, I was dehydrating and, as I'd later find out, it was 25c. I knew at this point I had to refocus and look to finish the marathon not get a good time. I'd lost count of the amount of people I'd seen being sick or dropped out, hell even the eventual winner stopped for a short while to cool down. Although I was struggling I was overtaking lots of people who were struggling more and I had to use this to my advantage. This is the best thing about pacing yourself right from the beginning - not only is it a more efficient way to run but in the last quarter of the race it catches up with the runners who started too fast and you can pull them back in. This is motivating at the best of times. This is really motivating when you're running in 25c and your throat feels like you've just woken up after a stag night. At this point in the race it becomes as much a mind game as a physical one - keep going is hard physically, convincing yourself you can keep going is much harder.

The last 4 miles hurt a lot. From 18 to 22 I'd managed to keep running at 7:10, meaning from the dodgy calculations I was attempting to do whilst running, that I would have been within a minute of a 3 hours finish time. Very impressive given the conditions. But then my pace started to slip - 7:30, 7:40, 8:00, 8:20. Dehydration had caught up with me, my body could no longer cool itself and even the hose pipe of a local resident who sprayed me wasn't helping. At this point it's all about taking it one mile at a time. Thinking you've got 4 more left is enough to make you stop. Thinking you've got 1 mile and doing it 4 times is much more manageable. I first heard of this strategy watching the fantastic film Touching the Void and use it a lot in races.

By 24 I was starting to get a little worried. My legs and breathing were fine but my body was getting really hot. I made the decision to keep going although I knew I might not be too far off doing myself some serious damage. If I'd felt like this 4 miles from the end I would have stopped. As you exercise a lot you learn when you can push yourself and when something isn't right. I was definitely moved from the former to the later and I didn't want to take any silly risks. In the last two miles I become the person being overtaken but my focus was just on finishing and making sure I didn't deteriorate anymore.

As I finally crossed the line I was apparently looking very pale. As I collected my medal I turned to see some shade and a large collection of runners downing water looking very un-well. By the time I hydrated and cooled down I was fine but sadly many weren't. 1 in 40 runners needed medical attention and 1 person sadly died. I even heard (unverified) rumours they ran out of ambulances. It was pretty mean out there.

Finishing a marathon is a feeling that's very hard to describe. As I collapsed on the shady grass, medal in hand it was hard not to get emotional about the journey to this point. 5 months of training, countless early mornings, several major social events sacrificed for sunday races and endless training miles run, made finishing the race a relief comparable with finishing your finals at university. The cocktail of emotions pumping round my body were like nothing I've ever experienced. Once I rehydrated and the reality sunk in, I picked myself up and headed to try and see my friend finish. She should have been 30 minutes behind me but I was in such a bad way 40 minutes had passed by the time I got back to the start. I cut my losses and heading to the baggage collection area a hobbling mess. To be honest the ending to Edinburgh marathon was a joke, a 10 minute walk to pickup your bag and a further 15 minute walk to the bus (after running a f**king marathon). It didn't really matter though - I was just happy to have finished.

So bad race conditions aside, would I do one again? Yes I'd like to. The challenge of the learning about when to push your body and when to hold back, the nutrition and the discipline of training have all been worthwhile things to experience and practice. Above everything else the atmosphere of the race is unrivaled though - the spirit of the other racers, the people calling out your name and the cheer as you cross the line are really like nothing else. It's very easy to see why people get addicted to marathon running. I took a few weeks off running after the event to let my body recover but it wasn't long before I was craving the open road again. And it wasn't long before there was talk of another marathon. In October I'll be doing Amsterdam - I won't train hard like I did last time as I still feel a little tired from the long miles - but I will keep my long run fitness ticking over and hopefully go sub 3.

Permalink | Leave a comment  »

I love AB testing. I think it is either related to the fact I did a year of Maths at university before switching to Computer Science or because human psychology fascinates me. Either way when I launched 5ft Shelf I was keen to test lots. First on the agenda was the default shelf view. For those not familiar with the site you can view a shelf of books in one of two ways - cover view or spine view as we call it on the site (see screenshots - click to enlarge). Whilst my designer was sure that the cover view would be better I knew the target audience wasn't necessarily technical, and besides the cool factor of a 3D book shelf would capture attention. It was going to be an interesting AB test.

Traditionally when doing AB testing I've added the logic to the rails model (it doesn't really matter if you're not a rails developer, the point is it was in the application database). This had a few disadvantages. First up it didn't keep code or the database as clean as it could be in places. Secondly tools had to be built to then analyse the data and thirdly it couldn't be easily plotted against relevant variables such as those stored in analytics software.

So when Google announced custom variable support in Analytics I sat up and paid attention. By passing through my AB test number to Google Analytics I can do all the reporting associated with AB testing outside my application database and report against more complex metrics that I don't store such as bounce rate. Perfect, so let's get started:

The first step is to assign each user to your site a unique AB test number. I went for a random number in the range 1 to 120. Why so large? Well most AB test I perform are just 2 or 3 options. Depending on traffic you can go much larger but to be honest it becomes harder to understood the factors that lead to the users choice if you do that. Anyway 120 is 2*3*4*5 which means you can have 2, 3, 4 or 5 options (or any product of these numbers - eg 6,8...). This gives plenty of options for the future. So for every visitor that comes to 5ft Shelf they get a random number and this remains with them (unless they clear out their cookies).

I then pass this number through to Google Analytics via a custom variable. For example:

var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));

try {
    var pageTracker = _gat._getTracker("UA-11028671-1");
    pageTracker._setCustomVar(1, "shelf_view", "USERS_AB_NUMER", 1);
    pageTracker._trackPageview();
} catch(err) {}

The USERS_AB_NUMBER needs replacing with the users actual ab number. In ruby I used:

@site_preferences.ab_test_number.modulo(2)

as I was only testing two options.  You can substitute this code as appropriate for the number of AB choices you have (and to your language of choice if not using Ruby).

A few notable things:

• The first argument in the custom variable index number. Google analytics provides you with 5 of these so you can feasibly track upto five AB tests at once.
• The second argument is the name. I use this to identify the name of the AB test for easy identification in Analytics at a later date
• The third argument is the value we want to store against the name. I used the ab number modulo 2 as that is what is used to display the different options in the view of the application. If you use more complex logic you should substitute it here. You're not limited to numbers though - you can also store strings
• The last argument is the the scope of the variable. For AB testing you'll nearly always want 1 for visitor level. More on this can be found in the Analytics help centre if you need it

Note: you can just pass through the AB test number but you will have to combine each number's entries into 2 sets in this example. This is a real pain as one set will be 1,3,5,..119 the next 2,4,6,..120, so unless you like maths best let your application do the logic and keep the data in analytics simple.

Now we've passed the data through to Google Analytics we need to make application specific logic in your views to render the different AB tests (again substitute for your test setup and language):

if @site_preferences.ab_test_number.modulo(2) == 0
  # Render option 1
else
  # Render option 2
end

Finally we need to create a custom report in Google Analytics. Login and click 'Custom Reporting' down the left hand side. Then click 'Manage Custom Reports' underneath and then 'Create new report'. You can then drag the metrics which you wish to measure along the top (think what would constitute as a success in your test - longer page views, lower bounce rate etc) and the dimensions down below (you'll probably only want the Custom Variables here). Make sure you get the Custom Variable values not the keys. The screenshot below should show you how it looks (hover to increase size).

Then it's just a case of waiting however long you want to run your test case for and logging into analytics to see the results. You'll hopefully end up with a chart looking something like the one shown below (hover to increase size). Note here the real data you're after is not in the graph but the table below.

So for those of you that asked that's why 5ft Shelf switched to spine view as the default, there's your answer :D Happy AB testing folks.

Permalink | Leave a comment  »

Today I can announce 5ft Shelf - a site to do just that:

In 1909 Dr Eliot, then President of Harvard University, claimed a liberal education could be achieved by reading a collection of books that would total no more than 5ft in width. A local publisher challenged him to name them and he responded with what became known as the Harvard Classics. Shifting forward 100 years and into the age of the internet, we're trying to find out what the modern equivalent would be.  A lot has happened in the last century and we felt it would be impossible to get a fair representation of people’s interests without introducing two quintessential formats for modern living—music albums and movies. Rather than use a single authoritative source for the modern shelf, we've taken the opposite approach by allowing users to create their own shelf.  We then combine all the users' shelves to find the most popular items and create our top 5ft shelf ("the ultimate shelf").

The sites offers a little more than the introduction eludes to.  Amongst other features, mini-shelves contain the most popular items in a given subject area and the recommendation algorithm makes personalised recommendations based on the items on your shelf.  For more details read the 5ft Shelf blog Going Live post

As with all projects there has been big highs and hard lows but overall it has been great fun and scratching a personal itch was particularly satisfying.  On a more technical / agile development note I intend to publish two separate blog posts on the results of my endeavors.  The first will be on Getting Real and my experiences using the 37 signals development approach, along with some productivity experiments I performed myself during the time.  The second will be on how long it takes to get a startup to market.  I'm used to tracking time spent on projects for clients so I did the same for this project and found some interesting results.

Look for both blog posts in the coming weeks and in the meantime please do check out 5ft Shelf and pass it along to anyone who you think might be interested.

Permalink | Leave a comment  »

Alex did a good introduction talk to CouchDB at Scotland on Rails. Towards the end of the talk he did an overview of the current ruby plugins/gems available for interfacing with CouchDB, one of which was my own CouchFoo. Alex's opinion was that any ORM for CouchDB should be as thin as possible just wrapping the Ruby to JSON object translation. I raised my opinion in the question section at the end by saying that I didn't agree and thought the ORM should map the level of functionality available in ActiveRecord. This sparked a debate both in the talk and via Twitter of the best approach for an ORM for CouchDB to take. As a result I agreed to write this blog post to outline my views.

CouchDB is a document orientated database with a HTTP interface amongst other features. When I first started using it I played with the database a lot via simple interactions through CURL. In the same way I feel it is important to know SQL before using any higher level API to store and retrieve objects in a relational database, I feel it is important to understand how CouchDB works before using a library to interact with it. As with most areas of computing you will find a range of opinions over what level you interact with the database - there are the purists who like to write SQL queries for each database query performed and those who are willing to sacrifice a bit of performance (maybe not having the optimum query run each time) for the time efficiencies realized whilst developing. I align quite well with the Rails mantra on this one - I'm willing to sacrifice perfect SQL each time for the efficiency gains made whilst developing. Part of Alex's argument was that you should be as close to the database as possible because the Ruby to JSON conversion is much less than the Ruby to SQL conversion. Whilst I don't disagree that it's important to know how CouchDB works, I do disagree on the level at which any Ruby library should sit. I'm happy to pay a small price in terms of extra ruby code executed because I want as clean as DSL as possible.

Whilst developing CouchDB I tried all the existing ruby libraries and as I worked through them I ran into several issues. After using ActiveRecord's save and find methods it was particularly annoying to use a library that used different method names for the same conceptual operations (eg get instead of find). This wasn't a major issue of course I just forked the library and made changes. But as time went on there were features that I missed from ActiveRecord. Validations, callbacks, finders and associations were the prime contenders. Then dynamic finders and named scopes got added to the list. In the end changing the existing libraries became so much work I decided to start with ActiveRecord and work from there.

Of the features in ActiveRecord Associations are perhaps the most controversial on whether they should apply to Document orientated databases or not. The argument goes that if you're trying to use associations you don't understand how CouchDB should be used. I disagree on this point - a simple counter argument is presented by having a document that allows comments. Those comments could be stored inline in the document itself or in separate documents that have a reference to their parent. This is association whichever way you look at it. Which approach you decide to use will depend on your application and the characteristics of it. Incidentally Alex's gem did a great job of this letting the user specify in the association whether they wanted the object stored inline or not. This has since been removed from his gem but is something that's definitely on the TODO list for CouchFoo.

For me CouchDB lends itself well to two distinct domains. Firstly domains where documents are used - that is an object where the fields that are stored to the database change depending on the object. Secondly domains where you wish to take advantage of some of CouchDB's features not present (or poorly implemented) in relational databases - a HTTP interface, fantastic scaling ability due to bi-directional replication, and schema free nature (see this excellent article on friendfeed experience with MySQL) are just a few that spring to mind. People may use CouchDB for the second set of criteria even though their database design could be considered quite structured, and I fully expect this group of people to rise as CouchDB reaches 1.0. However that wasn't why I wrote CouchFoo, my project fell into the first domain. Whilst I provided a way to use ActiveRecord's higher level API I also provided access to a database object that allows simple storage and retrieval of documents by id. If that is all the functionality you require then I would expect CouchREST would be a better choice. However I believe in reality you will quickly find you need to add validations to a field, or maybe add an association or two. And as soon as you start on that slope I believe CouchFoo to be a better choice.

Ultimately I created CouchFoo as I missed the richness of the ActiveRecord API. Whilst I don't believe my library will be perfect for everyone it has received a lot of good feedback. To paraphrase DHH I didn't create the perfect framework for everyone else, I created it for me. I only hope that other people find it useful.

Permalink | Leave a comment  »

Thanks to a lucky draw at dConstruct last year I bagged two free tickets to this years SXSW. I decided to invite Jim along for no other reason that he was likely to be the closest to the event. I'd never been to Texas before and despite hearing many bad reports, word was Austin really wasn't quite as bad.

And what a surprise it was - a laid back city with fairly liberal attitudes. Once I got over the English-American language barrier (swap line for queue, register for till and give me for can I have) things seemed to go well. The line up of talks was amazing - Gary Vaynerchuk was awesome although sadly I only caught the last 20 minutes (good video of him here at FOWA), Brian Brushwood did an excellent talk based on his scam school series, James Powderly gave a fascinating talk of his grafitti art and getting detained in China, and there was an extremely useful panel on how to give good presentations. That's one of the parts I enjoyed the most - the sheer diversity of talks. In addition there were more informal talks where the presenter started off for 10 minutes before opening up to the room - going freelance and becoming productive were two of my favourites in this format. Of course due to the sheer volume of talks many good ones were missed - Larry Lessig seems the prime candidate here. They're going to make all the talks available for download so I'm looking forward to catching what I missed.

The talks are only half of Southby though. The night life is great and there's loads of parties with free drink and beer flowing. These seemed quite hit and miss with the Digg party being awful and the queue to get a signature from Kevin Rose a really quite distressing sight. But for every flop there were some good ones that provided entertainment as wide ranging as Burlesque and live photoshop drawing.

I met plenty of new interesting people, and bumped into quite a few from England although I know of least two out there who I didn't bump into all week. Other highlights included the weather, free wifi everywhere, a film called Burma VJ we randomly caught and England destroy France in the Rugby. More random things included drive through banks and a gig featuring a hip-hop group I strangely enjoyed. And the downers? Well I can't finish without digging just how awful the all american diet is (suprisingly I didn't want my meal in a sea of melted cheese but gee thanks). Overall though a great experience and well worth it if you've never made the trip.

Permalink | Leave a comment  »

ActiveRecord allows you to serialize objects into text columns through YAML. This seems useful but in my experience is under-used. One of the primary reasons for this is it's not possible to use the data that the object encapsulates without the ruby model. For example it's not possible to find on the contents of that object or for that matter, modify the object with languages that lack YAML support. With CouchDB all data is stored in JSON so this is not an issue.

The project I wrote CouchFoo for used complex ACLs and I wanted to encapsulate this all in an object rather than use several many-many relationships and construct an ACL object based on their contents. So how do you this with CouchFoo? Simple, any object can be assigned as a property in a CouchFoo model as long as it has a .to_json method and a class .from_json method. The methods do what you'd expect, for example:

class DataObjectAttributeList

  attr_accessor :attributes

  # Constructs the object from JSON
  def self.from_json(json)
    DataObjectAttributeList.new(json)
  end

  # Converts the object to JSON
  def to_json
    @attributes
  end

  def initialize(initials = {}, *args)
    @attributes = initials
  end
end

This is just a simple example storing a hash but the structure could be as complex as you'd like. In the future I plan to add inline associations to CouchFoo, so rather than have a one-to-many association where the many are accessed via a second database query you could have the objects stored as part of the parent contents. Performance wise, this is normally much more efficient (although not in all situations - eg heavy write and low read).

Overall, this becomes a very addictive way of developing and in the same way you start to question whether you need a relational database, you start to question whether you should store associated objects inline or separately.

Permalink | Leave a comment  »

CouchDB is an excellent database, designed especially for distributed applications. To quote the official site site:

Apache CouchDB is a distributed, fault-tolerant and schema-free document-oriented database accessible via a RESTful HTTP/JSON API. Among other features, it provides robust, incremental replication with bi-directional conflict detection and resolution, and is queryable and indexable using a table-oriented view engine with JavaScript acting as the default view definition language.

along with the knowledge it's written in Erlang, you know it's going to go be a winner in the future.

For one of my current freelance projects I needed to store data in a document fashion - ie unstructured. This made CouchDB an ideal candidate. There were several ruby gems available: CouchPotato, CouchREST, ActiveCouch and RelaxDB gems. Each offered its own benefits and own challenges. After hacking with each I couldn’t get a library was happy with. So I started with ActiveRecord and modified it to work with CouchDB. And so CouchFoo was born.

In the end I ended up with a gem that mirrors ActiveRecord in all but a few minor places. In particular:

• CouchDB is schema free so property defintions for the document are defined in the model (like DataMapper)
• :select, :joins, :having, :group, :from and :lock are not available on find or associations as they don’t apply (locking is handled as conflict resolution at insertion time)
• :conditions can only accept a hash and not an array or SQL. For example :conditions => {:user_name => "Georgio_1999"}
• :offset is less efficient in CouchDB - there’s more on this in the rdoc
• :order is applied after results are retrieved from the database. Therefore :order cannot be used with :limit without a new option :use_key. This is explained fully in the quick start guide and CouchFoo#find documentation
• :include isn’t implemented yet but the finders and associations still accept the option so you won’t need to make any code changes
• By default results are ordered by document key. The key uses a UUID scheme so these don’t auto-increment and are likely to come out in a different order to insertion. default_sort can be used on a model to sort by create date by default and overcome this
• validates_uniqueness_of has had the :case_sensitive option removed
• Because there’s no SQL there’s no SQL finder methods
• Timezones, aggregations and fixtures are not yet implemented
• The price of index updating is paid when next accessing the index rather than the point of insertion. This can be more efficient or less depending on your application. It may make sense to use an external process to do the updating for you - see CouchFoo#find for more on this
• On that note, occasional compacting of CouchDB is required to recover space from old versions of documents and keep performance high. This can be kicked off in several ways (see quick start guide)

The RDoc for the gem contains more details on each of these differences, new features that I added, a quick start guide and additional areas of responsibility to think about when using CouchDB (in particular performance).

As a quick overview, basic operations are the same as ActiveRecord:

class Address < CouchFoo::Base
property :number, Integer
property :street, String
property :postcode # Any generic type is fine as long as .to_json can be called on it
end

address1 = Address.create(:number => 3, :street => "My Street", :postcode => "secret") # Create address
address2 = Address.create(:number => 27, :street => "Another Street", :postcode => "secret")
Address.all # = [address1, address2] or maybe [address2, address2] depending on key generation
Address.first    # = address1 or address2 depending on keys so probably isn't as expected
Address.find_by_street("My Street") # = address1

As key generation is through a UUID scheme, the order can't be predicted. However you can order the results by default:

class Address < CouchFoo::Base
property :number, Integer
property :street, String
property :postcode # Any generic type is fine as long as .to_json can be called on it
property :created_at, DateTime

default_sort :created_at
end

Address.all # = [address1, address2]
Address.first    # = address1 or address2, sorting is applied after results
Address.first(:use_key => :created_at) # = address1 but at the price of creating a new index

Note that there's an optimisation that will order results by created_at if there are no conditions so in the above case, the default_sort wasn't required. However when using with conditions it will be required so it makes sense to use at all times.

Conditions work slightly differently:

Address.find(:all, :conditions {:street => "My Street"}) # = address1, creates index on :street
Address.find(:all, :conditions {:created_at => "sometime"}) # Uses same index as :use_key => :created_at
Address.find(:all, :use_key => :street, :startkey => 'p') # All streets from p in alphabet, reuses the index created 2 lines up

As well as providing support for people using relational databases, CouchFoo attempts to provide a library for those wanting to use CouchDB as a document-orientated database:

class Document < CouchFoo::Base
property :number, Integer
property :street, String

view :number_ordered, "function(doc) {emit([doc.number , doc.street], doc); }", nil, :descending => true
end

Document.number_ordered(:limit => 75) # Will get the last 75 documents in the database ordered by number, street attributes

Associations work as expected but you must to remember to add the properties required for an association (we’ll make this automatic soon):

class House < CouchFoo::Base
has_many :windows
end

class Window < CouchFoo::Base
property :house_id, String
belongs_to :house
end

There's a few bits left to tidy up (as noted in the readme) but generally speaking it's now ready for use by others. Grab it on github and feel free to fork and send me pull requests.

And now to do something I've not being doing a lot of lately, spend some more time on the Couch...

Permalink | Leave a comment  »

With the recent announcement that Rails and MERB will merge and my preference for DataMapper I decided to plug datamapper into rails for my next freelance project. The theory goes this should make the upgrade path to Rails 3 a lot simpler!

It's currently possible to use Datamapper with Rails, heck even DHH himself commented so, but it's not quite easy as using ActiveRecord. After a quick Google I only ran into question of how to do it, no howto guide. So I set out to make mine own - it really was quite simple in the end:

sudo gem install addressable data_objects do_mysql # do_mysql can be changed for do_postgres or do_sqlite3 as appropriate
sudo gem install dm-core dm-more

In the dm-more github repos there's a folder called rails_datamapper which is a plugin for rails to add datamapper support. This doesn't install with the dm-more gem so it's a case of cloning the git repository and copy the folder to your rails project:

git clone git://github.com/sam/dm-more.git 
cp -R dm-more/rails_datamapper /vendor/plugins

Then edit your project environment.rb file and add the following lines:

# Load the required gems in the correct order 
config.gem "addressable", :lib => "addressable/uri" 
config.gem "data_objects" 
config.gem "do_mysql" 
config.gem "dm-core"  

# Make datamapper load first as some plugins have dependencies on it
config.plugins = [ :rails_datamapper, :all ]

# Remove ActiveRecord if you no longer need it
config.frameworks -= [ :active_record ]

The connection to the database will be made by the rails_datamapper plugin using your database.yml configuration file. You'll need to use a slightly different format for datamapper:

development: 
:repositories: 
:adapter: mysql 
:database: opnli_dev

Or alternately you can specify your own initializer and forgo the rails plugin:

hash = YAML.load(File.new(RAILS_ROOT + "/config/database.yml")) DataMapper.setup(:default, hash[RAILS_ENV])

The only real gotcha in using datamapper is some rails plugins assume you're using ActiveRecord. Hopefully this won't be the case in the future, but for now you'll need to get forking!

Permalink | Leave a comment  »

For those readers of my blog who don't live in the rails world I highly recommend checking out Git, a distributed version control system. It has been big in the rails world since early this year for several good reasons:

• It has distributed and offline functionality
• Making and merging branches is a breeze - encouraging you to try experiments in branches
• It uses much less space than alternatives, such as Subversion, and only has one .git folder at the base of your project
• It's in active development with constant releases of new features (but stable enough to be used for the linux kernel)

The terminology is slightly different from subversion and friends but once you've got used to it you never look back!

Merb was very quick to jump on the git bandwagon and rails followed not much later. Practically this made distributed development a hell of a lot easier, but it also had some nice knock on effects. Patching is now a lot quicker too - you simply fork the project, make a fix and inform the admin who can then choose to merge back into the master (if they see fit). It's made the process for fixing bugs a hell of a lot quicker.

Soon after git came along the fantastic github.com followed making it easy to host remote repositories. And so to the reason for me writing this post - github just launched git pages where you can upload your own page to front your repositories. It's a neat idea and naturally is all managed through a git repository. You simply create your site in a repository, push to github and the deployment is automatic. Although it's only simple HTML pages, it's a great proof of concept of other things that could be possible. My effort can be found here which following the git ethos I just forked from somebody else

Permalink | Leave a comment  »

On a personal note I presented on nanite which is a background processing solution for rails and merb. It was quite a technical talk and I was trying to get a lot into the 30 minutes timeslot, so it felt a little rushed. Nevertheless most people seemed to grab the concept and the live demo at the end went really well. For those that missed the event I'm sure the videos will be online soon, but in the meantime there's an excellent coverage on this blog and the slides from my presentation are available on slideshare or below:

Permalink | Leave a comment  »

I've just pushed two plugins to github. The first is an improvement on the standard Defensio plugin that only checks the validity of your API key when posting articles or comments. This is better than checking each time a model that uses the plugin is instantiated as it doesn't require contact with the Defensio API (so is faster) and also won't bring your site to a standstill if someone is just viewing a page and the Defensio service is down.

The second updates the highly useful timed fragment cache plugin by Richard Livsey to support Rails 2.1

Permalink | Leave a comment  »

For the last 6 weeks I've been head deep coding for a new startup wordia.com The idea is rather fresh - to allow people to learn the meaning of words by watching videos of people saying what the word means to them. So far my favourites include invention by Nikki Grahame of big brother fame, bannana by two randoms at Edinburgh festival and, as everybody looked up rude words when they first got access to a real dictionary, incest.

It's been a really hard few work so was very rewarding on launch day (after 4.5 hours of sleep) to see London's press arrive at our launch event (see photo left). The site went down well and we featured in most the major newspapers in the following days. It was also great to meet our backer Michael Birch in person having recently exited from Bebo

In the coming months we've lot of new features planned and exciting people lined up to film with. I'll also be dropping back down to 3 days per week so I can get working on my own projects again. It should be an exciting 3 months.

Permalink | Leave a comment  »

Of more interest though was this later post about calculating the medal table by country population (I have long used this argument to explain why America gets more medals than us). Pretty interesting I thought, but of course this goes deeper. There are other factors that would truly measure a nations athletic talent - national expenditure on sport and maybe even climate are two that spring to mind.

Australia, one of the best sporting nations, is still considering a review of the way they fund sport after such a dismal performance though. Using the freakonomics chart they shouldn't be so disappointed (even if they did get beaten by New Zealand)!

Permalink | Leave a comment  »

Lately I've been working on a stock trading program that automatically trades and saves the results to a database (more details to follow in the not too distant future...)  Naturally the choice of language was ruby, and for the front end, a rails application.  Once coded, I bundled the stock trading program into the rails lib folder and reused the rails model for saving to the database.

I ran into a slight problem doing this though as ActiveRecord needs configuring manually outside the rails framework but I wanted to follow best practices and keep my code DRY. After a quick search I found a clean solution that allows you to re-use the database.yml configuration file from the rails application:

dbconfig = YAML::load(File.open('config/database.yml'))
ActiveRecord::Base.establish_connection(dbconfig["development"])

This snippet got me thinking about YAML which I use a lot but have never played with in Ruby. It turns out the YAML class is basically a hash that uses strings (gotcha not keys) to access a simple hierarchy:

dbconfig = YAML::load(File.open('config/database.yml')) 
dbconfig["development"]["adapter"] # = mysql [/sourcecode]

All very simple stuff but if its never crossed your mind before, you yet again appreciate the elegance of ruby.

Permalink | Leave a comment  »

This week I've been working on a client project where I needed to import a massive XML dataset into a database.  The XML was non-standard and broke its own rules in several places.  Consequently my rake task quickly become very complicated and I needed some tests to ensure I wasn't breaking previous work.  This leads to a rather interesting question: how do you test rake tasks?  After a bit of googling I found a rather neat solution of simply pulling out the rake code to a class. For example, rather than:

desc "Import the XML" 
task :import => :cleanup do   
  File.open(XML_FILE) do |file|     
  # Do importing here...   
end 
end

do something more like

desc "Import the XML" 
task :import => :cleanup do
   File.open(XML_FILE) do |file|
     XMLImporter.parse_lines(file)
   end 
end

XMLImporter can then be tested in the normal way. Good ruby - clean and effective.

Permalink | Leave a comment  »

I had a few issues getting a Capistrano file to work with Git and frozen MERB the last few days. The script below is how I finally cracked it and also has starters and stoppers for Memcached and my forked backgroundrb for MERB.

# Basic deploy details
set :application, "myapp"
set :deploy_to, "/var/www/apps/#{application}"
set :mongrel_conf, "#{deploy_to}/current/config/mongrel_cluster.yml"

# Repository details
set :repository,  "git@ipaddress:reposname.git"
set :scm, "git"
set :scm_passphrase, ""
set :set_branch, "origin/master"
set :git_enable_submodules, 1

# Required to get git password prompt
default_run_options[:pty] = true

# Set the user account to use for deployment and running
set :user, "deploy"
set :use_sudo, false

# Server details
role :app, "mysite.com"
role :web, "mysite.com"
role :db,  "mysite.com", :primary => true

desc "Deploy to the production server"
task :production do
role :app, "mysite.com"
role :web, "mysite.com"
role :db,  "mysite.com", :primary => true
end

desc "Change the database configuration file"
task :after_update_code do
run "mv #{release_path}/config/database.yml.production #{release_path}/config/database.yml"

# Remove code we don't want on the server
run "rm -rf #{release_path}/autotest"
run "rm #{release_path}/config/deploy.rb"
run "rm -rf #{release_path}/coverage"
run "rm -rf #{release_path}/spec"
run "rm -rf #{release_path}/stories"

# Make config directory just readable
run "chmod 700 #{release_path}/config"
run "chmod 400 #{release_path}/config/*"
run "chmod 700 #{release_path}/config/environments"
run "chmod 700 #{release_path}/config/initializers"
run "chmod 400 #{release_path}/config/environments/*"

# Make frozen-merb bin file executable
run "chmod 755 #{release_path}/framework/merb-more/merb-freezer/bin/frozen-merb"
end

# Override db:migrate as it calls rails specific stuff
namespace :deploy do
desc "Migrate the database"
task :migrate, :roles => :db do
run "cd #{release_path}; rake db:migrate MERB_ENV=production"
end
end

# Override the default deploy options to use backgroundrb, memcached and mongrel
namespace :deploy do
namespace :backgroundrb do
desc "Start backgroundrb"
task :start, :roles => :app do
invoke_command "cd /var/www/apps/bablo/current && script/backgroundrb start -- -r production", :via => run_method
end
task :stop, :roles => :app do
invoke_command "cd /var/www/apps/bablo/current && script/backgroundrb stop", :via => run_method
end
end

namespace :memcached do
desc "Start memcached"
task :start, :roles => :app do
run "memcached -l 127.0.0.1 -d -m 96 -p 17898"
end
task :stop, :roles => :app do
run "killall -s TERM memcached"
end
end

namespace :mongrel do
desc "Start mongrel"
task :start, :roles => :app do
invoke_command "cd /var/www/apps/bablo/current && #{release_path}/framework/merb-more/merb-freezer/bin/frozen-merb -d -e production -c 5", :via => run_method
end
desc "Stop mongrel"
task :stop, :roles => :app do
invoke_command "cd /var/www/apps/bablo/current && #{release_path}/framework/merb-more/merb-freezer/bin/frozen-merb -K all", :via => run_method
end
end

desc "Custom restart task for mongrel cluster"
task :restart, :roles => :app, :except => { :no_release => true } do
deploy.backgroundrb.stop
deploy.memcached.stop
deploy.memcached.start
deploy.mongrel.stop
deploy.mongrel.start
deploy.backgroundrb.start # Doesn't work if straight after the stop
end

desc "Custom start task for mongrel cluster"
task :start, :roles => :app do
deploy.backgroundrb.start
deploy.memcached.start
deploy.mongrel.start
end

desc "Custom stop task for mongrel cluster"
task :stop, :roles => :app do
deploy.backgroundrb.stop
deploy.memcached.stop
deploy.mongrel.stop
end
end

I've still not managed to get Git caching working with submodules, so any input on this would be appreciated (it seems to work fine without submodules). 

Updated: Fixed in Capistrano 2.4

Permalink | Leave a comment  »

I presented on MERB last weekend at Barcamp London 4 I've been using the technology the last two months at Bablo so it was good to share my experience with other users. With it being quite a bleeding edge technology there was just a small gang of us there but there was plenty of good discussion. The talk I gave had a purposely provocative title but ended with a great quote by Ezra

more choices make the Ruby ecosystem a better place. So let’s just stop with the Rails VS Merb stuff. How about people choose what framework they want to use based on the frameworks merits and features rather then religious arguments about how my framework can beat up your framework.

I was then flicking through some slides from the recent RubyConf and was mightily impressed by a slide from the end of the MERB talk:

It's consider a bug if:
* It's not documented
* MERB gets slower
* There's a public API change without prior deprecation in a timely manner

It seems the guys at EngineYard have a great attitude, not to mention a really well thought out framework. I'm looking forward to using it fulltime.

Permalink | Leave a comment  »