Why?
First, I’m going to be talking (or prattling) about pipes and tubes at Russell Davies’ Interesting 2007. Should be excellent.
Then, when it’s over, I’m off to Alexandra Palace for Hack Day. I have some partners in crime there who I should be able to fall into line with.
Crikey. That’s a weekend and a half. I’m going to need a holiday.
Mac OSX 10.4 still only ships with PHP4, which is fine and all, but I eventually bit the bullet and decided to install PHP5.
The most immediately obvious way to do this is with Marc Liyanage’s excellent installer. I unzipped, installed the .pkg, and rebooted Apache.
Except Apache didn’t want to reboot. Apache refused to start, actually. Looked like a potential crisis!
Fortunately, a few minutes of digging found the solution. Pretty obvious, really:
you can’t load both mod_php4 and mod_php5 Apache modules at the same time.
I had mod_php4 enabled already. By commenting out the lines referring to it, Apache started up just fine, running PHP 5. Crisis averted.
As you probably know, when it comes to code (both in and out of work) I’m a Ruby and Rails guy. It’s not necessary to go into much detail “why”: the expressiveness of Ruby and the dynamism and speed of development in Rails are big wins for me.
But it’s not always possible – or practical – to knock out Rails applications for every task, and right now, I need to deploy something in PHP. Something very simple, that doesn’t warrant the deployment overheads of Rails (which we’re all aware of, right?)
Refusing to get caught up in WordPress if at all possible (not going into that again, either), I set out to look for a nice, well-documented, lightweight PHP web framework.
Continue reading this post…
As a Rubyist and Textmate user, you’ll probably be aware that def will tab-expand to stub out a method definition. You might also be aware that, for the purposes of Test::Unit, deft will tab-expand to a test method beginning def test_, allowing you to append the name of your test.
But that’s not much more help, because if we’re naming our tests properly, they’re probably going to have very_long_names, and hitting underscore all those times is a bit of a pain. So I rectified that, with this command (and it’s a command, rather than a snippet, because of all the processing it does). Pull up the commands dialog (Command-Opt-Control-C), create a new command in the Ruby bundle, and give it the following code:
#!/usr/bin/env ruby
name = STDIN.read.strip
testname = name.gsub(" ", "_").downcase
print <<OUTPUT
def test_#{testname}
\$0
end
OUTPUT
The command’s Input should be “Selected Text” or “Line”; its Output should be “Insert as Snippet”. The scope should be set to source.ruby. And give it whatever key definition you want; I’ve got it on ctrl-opt-shift-t.
Usage is easy. On a new line in your test file, type the name of your test in plain English with no punctuation, eg:
get to index should list all items
and then hit your shortcut. You’ll get the following out:
def test_get_to_index_should_list_all_items
end
and your cursor will be slap bang in the middle of the test, indented, ready to write. That’s what I really want from a test definition snippet – something more than deft supplies. It’s another minute or two’s work to make it strip punctuation, so you can convert real sentences to test cases. I just decided to condition myself to save on coding on this morning’s commute.
This is an idea spun out of conversation with Ben and Paul at last night’s LRUG – a physical device for alerting developers working in a continuous build environment as to how far they are from the trunk.
Because of the rate of change on an agile project, it’s important to keep your own personal codebase as close to the trunk as possible, otherwise you’ll spend a long while working on code that doesn’t fit with the current state of the system, or working around issues which may have been fixed. It’d be good to have some sort of physical display to alert you to this, rather than relying on typing svn up every five minutes.
Enter the continuous build barometer. It’s dead simple: it’s a dial you connect to your computer via a USB connection. The moment you do a checkout, the needle sets itself to 0. And then, as your codebase diverges from the trunk, the needle indicates how far (proportionally) your code diversifies from the original. And, of course, the moment you check in, the needle resets itself to zero.
Ideally, the continuous-build barometer needs to be made out of something reasonably heavy – I have this image of brass and wood, much like this example, if only to convey the weight that “checking in often” actually carries. In terms of making one… dial indicators seem to be quite pricey. It’d be easy to prototype with something like this ten-bar LED display, an Arduino board, and a short-ish script to compare the trunk with your local version, cronned to run regularly. Of course, I think the physical nature of the object is important, but it’d still be interesting to see what a working version in any form looked like.
That was one of my favourite things this month’s LRUG gave me, and it’s not really even code. Now: who wants one?
It’s been about two week since I went to FOWA2007 in London, and I’ve been meaning to write it up for a while. It was an… interesting experience, and I’ve been trying to find a way to frame why that is. Speeding on a train back from the provinces to London seemed a good way to concentrate my thoughts.
Last year’s FOWA was great: a one-day conference for
In a recent post about offshoring development work, Ryan Carson explains that the way you know when you’ve outgrown a freelance developer is this:
Getting bugs fixed and new features implemented starts taking fricken’ forever.
There’s some interesting discussion on the post – about eastern-European wage rates, about freelancing, etcetera – but there was one elephant in the room that nobody really mentioned, and I really think it’s necessary. And that’s this:
once your application is live, everything will take longer.
Whilst you’re in the build process, you can turn on a dime; you can commit new code at a moment’s notice, change the direction of the codebase or even the application, churn out features at a remarkable rate. And, when something doesn’t work (despite having passed the test suite… which you do have, right?), you patch it and move on. It’s a doozy.
Once you’re live, everything changes. You’ve got an active audience using the site – you might even have paying customers. You can’t afford for a single thing to go wrong. New features are no longer about build it, run the tests, check it in, deploy. Your testing on the development box has to be more fastidious. The integration between new functionality and the existing needs to be really well thought through. The design needs to be seamless with that which exists already. And, if it goes live and there’s still one of those totally unforseen bugs… you need to be ready to roll back at a moment’s notice, and put the feature on hold until it’s ready.
This is not new. Some teams are lucky enough to make many deploys daily; most can muster up daily fixes; some might go to weekly. But the effort that a feature requires post-launch is far more than it does pre-launch.
So it’s inevitable – freelancers or no – that the pace of development is going to fall off a bit post-launch. Hopefully, only a bit – but it’s not going to be the same rate unless you’re extremely lucky. You’ve also got to keep your users in mind, and break them into new functionality slowly.
It’s a hard transition, going from the development site to live. To you, as an owner, a developer, it feels like the same product – so the change in pace is a bit frustrating. And it’s important to keep the pace as fast as possible. Some fixes are critical, and need to go out the door the instant they’re done; others can wait a little longer – a day or two, if necessary – for release. It’s a rare, focused, hugely talented team that can splurge out new features like a machinegun.
Now, I’m sure that the problem is compounded by avoiding maintenance contracts (and so having to re-contract and re-hire) and having developers whose time is precious. But it’s always important to bear in mind that the latency of any web software development shoots up post-launch. So if it does: don’t immediately reach for the outsource button. Take stock, have some patience, and see what the product needs – how often it needs to be released, how often it needs to be improved. And then you can make that call a little better informed.
The other golden rule, incidentally, is never deploy on Friday. I hope the reasoning behind that is obvious.
I wrote my first proper Unit Tests in Ruby today. It felt good.
That probably sounds slightly gauche and hypocritical coming from a Rails developer. But remember – I’ve come from a front-end background; most of the time, other people make the tests; it’s up to me not to break them. I’m perfectly capable of editing tests to bring them in line with updated functionality; it just tends to have been the case that I’ve never really got my head around testing properly.
That changed recently, mainly thanks to Geoffrey Grosenbach’s excellent Peepcode screencasts. I’ve read a fair amount on testing up to now – Mark Pilgrim’s Dive Into Python is very good on the subject – but it was Geoffrey’s material that really clicked with me. (I’m watching his Capistrano one at the moment, and it’s certainly proving to be as good as the testing one).
I’ve always understood the point – and the utility – of test suites, but I’m pleased to have got my head around writing my own, starting with one (of several) projects on the back burner. Small steps at first, but it’s really satisfying to be working in a relatively test-driven manner.
And so I’ve been enjoying watching the dots fly by before those magic words come up: 0 errors, 0 failures. The Peepcode screencasts come strongly recommended, as well. Here’s to slightly more watertight code from now on.
I’ve got an article in a free supplement inside this week’s New Statesman. The PDF is available to download from that link – sadly, the HTML isn’t online yet. Still, it’s a cracking supplement – a nice range of content, very colourful, and a real departure for the NS. I’m on pages 28-30, if you’re interested – a biggish feature about where the British games industry might be going in the next few years, and the various challenges it presents. Quite challenging to write about the games industry for a more lay audience than usual; it’ll be interesting to see if the conclusions in the article hold up.
The answer may lie not in next-generation hardware, but in next-generation business models. For example, the British games industry emerged in the 1980s from the constraints that had previously beset the industry. At that time home computers, such as the BBC Micro or ZX Spectrum, were built to a budget, with limited power, developed for and by self-taught coders, often working alone. Now, there is a resurgence in popularity of games for very limited platforms: handheld consoles, mobile telephones, interactive TV and web browsers. And when developers have to work within tighter constraints, new ways to make and sell games – especially for smaller development firms – emerge.
Download the supplement if you’re even vaguely interested.
To cut a long story short: the slides for the talk I gave earlier this week are now available. You can find out more about the talk on the talks page of this site, or you can download the PDF (1.5mb). It should be fairly self-explanatory.
(A brief summary for those of you unable to scroll or click: it’s a client-side-developer’s perspective on Rails, and how to integrate client side development into the build process).
