Notes from a Messy Desk

So, it’s been kinda quiet around here lately. My desk is as messy as ever, but the notes never seem to make it here (mostly because I made a decision back in January to make this the “Rubaidh Company Blog” which put up a barrier of sorts to posting stuff regularly).

Expect service to resume shortly. In the meantime, you can always find me as @mathie on Twitter.

Having shaken off the binds of being the official company blog, Notes from a Messy Desk is looking somewhat … plain. I’m looking for somebody to design a new, shiny, theme (and associated Wordpress setup) that will make the most of the content here. Any volunteers? (Preferably Edinburgh-based, as I like to chat through designs and ideas face-to-face, but I’m open to trying out working remotely if you think you can make it work.)

As I mentioned at the tail end of last week, I presented Ruby and Rails is Awesome at the local Edinburgh Tech Meetup. The video of the presentation has just been uploaded to Vimeo, which you can watch right here:

Or you can see the video of Why Ruby (and Rails) is Awesome at Vimeo if you’re attempting to read this through a feed and the embedded version looked like tag soup.

I need to practice my presentation skills a lot. Too many “errrrrrr”s and way too much time spent looking at the speaker notes on my laptop!

I was invited to give a short introduction to Ruby on Rails at Tech Meetup in Edinburgh a couple of days ago. I’d been racking my brain for days on what to talk about — 15 minutes is too short for me to give a meaningful introduction to Rails — and eventually settled on telling a few stories.

The slides don’t make much sense on their own, so I’ve included the “script” of what I talked about too. I deviated quite a bit from the script as I got into it, so hopefully I should be able to provide audio (or, dread the thought, maybe even video) of the talk in due course.

Intro

I’m Graeme. I’m the Managing Director of Rubaidh Ltd, and have been developing Ruby on Rails applications professionally for 3 years now.

Telling Stories

To be honest, I didn’t know what my audience this evening was going to be like. I wasn’t sure if you’d all be business folks in suits, or whether you’d all be hardcore geeks that know more about web development than I could ever hope to. So I didn’t want to have slides full of code showing the technical prowess of Ruby. And equally, I didn’t want a bunch of pie charts showing the return on investment you can make from choosing Ruby on Rails as your strategic development platform.

Instead I’m going to tell you a few stories. These are stories that shaped my decisions and represent some of the things that make me realise the power of Ruby on Rails. They are all true stories. They all happened to me. I may have changed the odd detail to protect the guilty parties, though.

I hope that, in imparting these stories to you all, not only will you appreciate my choice, but you will also reflect upon the choices you could make to improve your current (and future) business.

Migrations

I used to have the pleasure of working full time on an open source email response management system. It was the first open source business in Scotland to receive VC funding and was a fantastic product with huge potential. (It still is, I’m sure, but I don’t keep up with development these days.)

As is always the case, there were a few skeletons in the development cupboard. One was migration. The first prototype of the product used an object database back end. This database did not scale well. In order to meet the scalability requirements of the hosted service for the business, we shifted to a SQL-based backing store. We also made the decision to support multiple SQL databases – primarily MySQL and PostgreSQL, though there was demand in the open source community for MS SQL Server support too.

And there’s where we hit our major problem. There was no database-agnostic layer between the application and the back end database. It was a problem to maintain the slightly different SQL queries for different databases, particularly since a major part of the application was full text searching and we delegated that task to the database.

However, the biggest trouble we ran into was migration. Migrating people from the object database back end to either PostgreSQL or MySQL. Migrating people from one SQL schema to another. Or, in the case of one client, migrating from the PostgeSQL back end to a MySQL one. Our home grown solution was flawed and wound up with a number of client installations having subtly different database schemas (my fault!). So, in addition to having to cope with different database back ends, the problem had grown exponentially into having to deal with different schemas. Yeuch.

When I first looked at Ruby on Rails, one of the features that caught my eye was its built in support for database migrations. In a back end-agnostic manner, it will allow you to plot the course of a database schema through the versions of an application, gracefully (and consistently!) moving from one version to the next. This totally blew my mind after a day of dealing with a customer who’s database schema didn’t quite match my expectations…

Deployment

This is another horror story about the very same application. What can I say? It’s what eventually made me jump to Rails.

The hosted service, at this point, was spread across two servers. We had sharded the data — free accounts on one server and paid accounts on the other. This at least meant that when the free trial server got overloaded, at least the paid accounts didn’t suffer.

Deploying a new version of the application was a manual process. We would ssh into each of the servers, stop the front end Apache server (so that nobody could mess with the application while it was in an inconsistent state), stop the application servers, update the code from the subversion repository, perform a number of other tidy-up tasks that I dread to recall, start the application servers, and finally restart the Apache servers. Deployments would take up to an hour.

One nightmare involved a number of complex database migrations because the two servers had wound up with an inconsistent schema. They needed to be made consistent because a free trial customer had just upgraded to a paid account. It took us about 2 days to sort the production platform out. Downtime was about 5 hours in total.

Shortly after that incident, I ran into Capistrano, the deployment tool of choice for Ruby on Rails applications. It gracefully allows you to manage front end web servers, application servers and database servers, running on 1 machine or spread across 20. With Capistrano, deployments are simple, fast and, mostly importantly, reversible. In some of our applications, we’re doing in the region of 10 deployments a day. This means that we are delivering production-ready features to the business users who are requesting them up to 10 times a day. Can you offer that kind of turnaround?

Of course, it’s not just Capistrano’s deployment assistance that allows us that level of efficiency, but it is a key factor.

Velocity

This last story is one from since I started working full time with Ruby on Rails, but it often reminds me why I still feel we made the correct business decision. At the tail end of 2006, the Chief Operating Officer of a start up approached me for a bit of consultancy. They had put together an awesome business plan for an online training platform which needed a large web application to be developed. The COO had done his research and decided that Ruby on Rails was the right development platform and, in particular, that Rubaidh was the right company to deliver the platform.

In order to secure the funding required for the project, the company had put together a detailed specification for the application, including cost estimates and staffing requirements. I believe those estimates showed that it would take 4 developers around 9 months to build the application.

We came in as a full time team of three developers, and we delivered working software to the business every two weeks. After 3 months, the system was complete enough to allow the editorial team to start entering the training courses. And after 5 months, we had a production-ready application which the sales team could use as a demonstration of the system’s potential.

Just to underline the point here. A project that was estimated (by an experienced software engineer and project manager) should have taken 36 person-months to deliver was, thanks to Ruby on Rails (and Agile development practices), delivered in 15 person-months.

JumpStart

With apologies to Sun for stealing their name (and to Thoughtbot for apparently stealing their idea — we thought of it independently, honest!), what presentation would be complete without pimping our own company a little? We are offering a service to get your next project off the ground fast. We will:

• Start building your dream web application, working as an experienced in-house team, immediately.

• Help you hire, and train, your in-house team.

• Gradually step away and let your in-house team take over, when they are ready.

We’ve already done this once, and it was a major success for both us and client, so we’ve decided to turn it into a service we offer.

Scotland on Rails

Scotland on Rails Conference 2009 is running on 26th-28th March in Pollock Halls in Edinburgh. Keynote speaker, and Rails Core member, Michael Koziarski, recently described last year’s conference as “the best small conference” he’d ever attended. That’s high praise, because he attends a lot of conferences!

This year, we’re featuring keynotes from Marcel Molina Jr, long time Rails Core team member, and Michael Feathers, an early adopter of Extreme Programming and Agile development practices, who is probably best known for his book, “Working Effectively with Legacy Code.”

We also have presentations from big names in the Ruby community, like Yehuda Katz (Merb), Dave Thomas (Pragmatic Programmers), Scott Chacon (GitHub) and Jim Weirich (definitely, without a doubt, a werewolf!).

Tickets are £175 for the conference, though there’s an early bird offer of £150 available until Feb 8th.

Prior to the two day conference, Chad Fowler and Marcel are running an all day charity tutorial. All the proceeds go to the Children’s Hospice Association Scotland. It’s a £75 minimum donation, but considering these folks are both Pragmatic Studio teachers (where the courses are nearly £300/day), it’s an utter steal.

Run, don’t walk, to scotlandonrails.com to sign up.

To close, I’d like to share a story from Jim Weirich, one of our speakers at Scotland on Rails. He was talking a couple of years ago at RailsConf Europe about a financial application he and his team had developed in Java. It took a team of 4 of them about 6 months. As an experiment, they tried a spike of it in Ruby. It took them 4 evenings.

That’s not the impressive part, though. After all, since they now had a deep understanding of the problem domain, naturally they would be able to translate the solution into another language quicker than they could have written it in the first place.

The impressive part? The total number of lines of Ruby code required to implement the application was less than the number of lines of the Java version …’s XML configuration.

I can haz questions?

So, questions?

Alan Francis and I had the pleasure of speaking at RubyConf 2008 in Florida. We did a slightly newer take on Alan and Paul’s talk from RailsConf Europe 2008 entitled, “Ruby with an Accent: Organising a Regional Conference”, all about our experiences of organising and running Scotland on Rails.

Anyway, the lovely folks at Confreaks recorded the entire conference and have now uploaded the talks. You can find our talk here: Ruby with an Accent: Organising a regional conference. It’s definitely not my best performance ever (where did that accent come from?!), but the content is pretty useful.

In other news, registration for Scotland on Rails is now open. You can pick up an early bird ticket for just £150 (which is about $230) until 8th February. So, run, don’t walk, to the registration page to book your place now! I mean, can you afford to miss out on seeing Jim Weirich, Michael Feathers, Dave Thomas, Yehuda Katz and Marcel Molina Jr in Edinburgh this March? It’s going to be an awesome weekend!

Here at Rubaidh, we have a strong interest, and a desire to advocate the use of OpenSolaris. We find that it’s a scalable, solid, secure, maintainable platform for deploying Rails applications and our UK hosting service is based entirely upon OpenSolaris running on Sun hardware. We think it’s awesome.

With that in mind, we would like to get together with other people in Scotland who share our enthusiasm, along with those who are interested in learning more about what OpenSolaris has to offer. We have created the Scottish OpenSolaris User Group (currently just a placeholder ’til I get around to adding some content). Right now, we’re planning to meet up next Wednesday (14th January) after Tech Meetup to discuss what we can do as a group.

If you’d like to get more involved in the group, please join the mailing list and, if you can, pop along to the meeting next Wednesday (come along to Tech Meetup too, you can hear me talking about Ruby on Rails!).

Incidentally, the image was inspired by a conversation yesterday with a few friends. Apparently I may be the only person in Scotland who has an interest in both Ruby and OpenSolaris?

I have had call to contact a few companies this week about particular technical issues. Two in particular stood out and I’d like to contrast them with you.

First up was FiveRuns. I was messing around with my Manage account, updating some atrophied configuration (it’s one of these services where it’s good to have when I need it, but I don’t need it every day). I managed to break something by completely nuking one server from the control panel, removing the detector, and beginning the install again. Once installed, the server wasn’t showing up in the dashboard, though the individual applications and services were accessible.

Anyway, the problem is irrelevant. I fired off an email to support first thing in the morning (UK time). Naturally, FiveRuns are a US company and I didn’t expect a response for a while, so I forgot about it. Early in the afternoon, I get a response from Rachel asking specific technical questions which would help her resolve the problem. Clearly, this was somebody who understood the product and had researched the problem — that the Solaris detector wasn’t registering — before getting back to me. In fact, it turns out that the Solaris detector wasn’t starting because it couldn’t see the free disk space on one of my partitions (a ZFS/permissions problem) and Rachel’s pointer got me looking in the right place straight away.

I followed up with a couple of thoughts. Less than fifteen minutes later, Rachel got back to me again and we’d resolved the problem.

This isn’t the first time I’ve had cause to contact FiveRuns for assistance. In fact, I recall one particular instance where I had fired off 8 support requests before breakfast, and they were all resolved within the day. Some of those issues were escalated to members of the development team who got in touch directly to help resolve the issue.

Let me sum up here before moving on: FiveRuns have consistently been the best customer experience I have encountered in the web world. If you are services company online, you should be asking them how they do it.

Now the contrast. I’ve been a customer of another company since (according to the signup mail) August 2007. Their product is awesome: basically they supply the most rock solid, reliable DNS service available. There’s no doubt about that. However, their customer service is appalling. On 15th October, I fired in a billing enquiry because one of the reports was showing incorrect values, suggesting that I would be charged overages which I wasn’t due.

I received an automated acknowledgement immediately and, later that day, an email from a representative saying they were looking into it.

Let’s now fast forward to early December. We’ll assume that I’ve been so busy I didn’t notice they hadn’t followed up on my support query for 45 days. I happened to be updating a DNS record and figured I’d check the reports to make sure it was now showing the right value. Nope. I then checked through my email to see if I’d somehow missed the reply. No. They just hadn’t resolved, or followed up in 1.5 months.

So I decided that was the last straw and followed up to say I was cancelling the account and moving elsewhere. Since then there’s been a flurry of email, mostly telling me that I have a contract and I’m obliged to pay them money every month ’til doomsday. We’re currently quibbling over the part of the contract which states that “under customer satisfaction policies as $company offers from time to time for the Services, Customer may terminate this Agreement.” I have yet to receive an answer as to whether failing to answer billing queries within 45 days is acceptable under their “customer satisfaction policies”. If it is considered acceptable, I’m sure I’ll let you know.

Finally, let me sum up here, too: it doesn’t matter how good your product is, if you have poor customer service, you will lose customers. And products are not difficult; somebody will come along with a similar product one day and your only differentiator will be your customer service.

Scott Chacon just asked on Twitter:

poll: gitsters – what do you love most about git and why it over other scm/dscms?

— chacon

I’m only going to answer the first part, really, as I haven’t really evaluated any other distributed SCM since Bitkeeper in 2002/3.

So, what do I love most about git? Well, it’s the branching, but maybe not in quite the same way as everybody else. My brain can be somewhat easily distracted (I have been compared to an over-caffeinated butterfly in the past). In addition to that, I have clients who’s number one OMG super-critical the-world-is-going-to-end bug fixes and feature requests can change on a daily basis.

So I have multiple lines of development running at once. On my own. In my own development tree on my laptop. I can switch from one line of development to another with a single command. I can combine features from one line of development into another. When I’ve finished one of the things I started, I can merge it back in. And I can rebase all my other lines of development to coincide with the changes.

Since I’ve got a great test suite, I can be sure that all of this branching and merging (which, in my case anyway, shows up quite a few conflicts) isn’t breaking code, either.

Anyway, that’s what I most love about git: not just short-lived branches, but an easy way to have multiple lines of development for arbitrary lengths of time and not have any of those lines rot over time.

Now, if only I had git stashed what I was doing before I context switched to write this post, I could apply it again and remember what I was supposed to be doing!

You may have noticed in the news that the UK VAT rate has temporarily been dropped from 17.5% to 15%. This change is effective from next Monday (1st December 2008) for 13 months.

Software developers have a nasty habit of making assumptions. (I know, I’m one of them.) The standard VAT rate in the UK has been steady at 17.5% for 17 years now and, well, I didn’t see this change coming. And I’ll bet that your web developers didn’t either. Fortunately in our instance, at least we had abstracted the VAT rate out into a constant so there is only one place in each application where we have had to make a change. And since we now have a better idea of the assumption we can make, it’s now a method which will return 17.5% unless it’s in a particular date range, at which point it will return 15% so we don’t have to repeat the fix next year!

So. How about your web applications? Do they handle UK VAT calculations? Are they going to do the right thing come next week? If you are not sure of the answers to those questions, please get in touch by emailing or calling us on 0131 273 5271. Rubaidh will be more than happy to validate your existing code base (no matter the language) and ensure it complies with the new VAT rules.

Rubaidh Ltd has recently moved in to new offices in Musselburgh, and this morning I came in to discover that the folks who run the building have put up a sign for our office. Shiny, eh?

While I’m posting, I’d like to welcome Mark Connell, the newest member of Rubaidh’s team. He is a software engineer, working from our Musselburgh office, mostly on internal Rubaidh projects. So keep your eyes peeled: we’ll have lots of exciting new projects coming up in the next few months!

(Posted via .)

I had a thought while I was heading out to RubyConf 2008. I’m currently looking for more contract Ruby work and so I was planning to noise up a few folks and see if there was anything going.

What I hadn’t realised is that I (and other UK developers) are particularly attractive to US companies right now since, due to the exchange rate fluctuation, my daily rate has dropped by 25% in the last 6 months!

Back in May 2008, when I was at RailsConf, the exchange rate was almost $2 to the pound sterling. Let’s say that, hypothetically, I charge £100/hour (I don’t, though I wish I could!) since it’s a nice round number. That would mean I would have to charge $220/hour to a US company just to maintain the same level of income (adding on a somewhat arbitrary 10% to cover the extra costs involved in getting money from a US company to my UK bank account).

Now, the exchange rate has dropped to about $1.50 to the pound. That in turn means that what I have to charge has dropped by 25%. Let’s continue the example from above. In order to maintain the same level of income, I would now only have to charge $165/hour. Doesn’t that sound a whole lot more hospitable?

So, US companies: if you’ve been toying with the idea of making use of the awesome pool of UK Ruby talent that’s available, now is the time to try it out!

And, to the UK Ruby talent; if you’ve always fancied the idea of remote working for a US company, now is a good time to convince them it’s worth a try. But only once I’ve got my books full again.

Oh, and the main, subtle, take-home point of this post: Rubaidh Ltd is looking for new work and is happy working for anybody, anywhere! Get in touch!

« Older Entries