This weekend just gone, I attempted to compete in Railsrumble 2007 with an application I call ‘Kagtum’. The idea of Rails Rumble is to take 48 hours to build a Rails app from scratch in a competitive scenario. At around 7:30pm BST last night I realised I wasn’t going to finish the app and so I asked to be withdrawn, as I explained:

Maybe it was the fact I decided to try and compete on my own, and therefore didn’t have the advantage of a team. Maybe it was the fact it took half the first day just to get a working application stack up on linode. Maybe it was the Saturday afternoon spent in the company of friends rather than coding. Maybe the idea was too ambitious.

Maybe I just wasn’t good enough.

Whatever it was, I didn’t get enough of my idea implemented on the weekend of the 8th and 9th September 2007, that I wanted other people to look at it. I failed. There is no app here.

The ideas I played with in those 48 hours though, intrigue me, and they will be worked on over the coming weeks and months. The end goal is going to either be very interesting, or an exercise in futility. If you want to find out which, you can keep an eye on the blog and I’ll be making announcements there.

I will be judging, and I look forward to seeing other apps, so good luck. Until next year…

The first day did kill me - linode was under heavy load (not surprisingly, with over 100 teams trying to get their application stacks set up) and the guidance we had been given by way of a screencast was inaccurate in places. Top tip: when you’re in a hurry leave the rdoc behind and always pass “-d” to gem install.

Anyway, I still hope to judge - and I’d advise anybody with an interest in innovation to look out for the announcement that you can sign up for judging and take a look at the apps that were finished - but I thought I’d talk about Kagtum a little bit here, because the core is almost done and I’m confident I can get a working app out of the door soon. I’m also tempted to open source it.

It all started about 2 years ago when I was left distinctly underwhelmed by Wikinews. The problems with wikinews are many and pretty obvious to anybody who spends a few minutes digging.

The primary problem to my mind is that they’re using a piece of software designed to build an encyclopedia to build a news website which means all articles are given equal footing. It seems reasonable that they should be given equal footing, until you realise that unlike an encyclopedia, not all news items are equal. A world-famous opera singer dying is not equal to a drunken brawl in my local town centre, and neither are equal to the Iraqi PM losing the confidence of the Iraqi citizenship.

However, the core idea - news written by, and for, everybody is a great idea. I’ve spent the last two years playing with lots of ideas in my head and watched emerging developments in the online news and journalism scene before I came up with an answer: quite simply it comes down to targeting relevance.

If I am in Manchester UK, there are stories that are local to me I’m interested in that somebody in New York doesn’t want to see. Likewise, there are stories happening on the other side of the planet which are important to me because they have an impact on me, or because they are in an area I have an interest in. The “perfect” news website will know this, and present just the articles I need to see. Ideally, I also don’t want to be bogged down with partisan and opinionated pieces - I want impartial, simple, Economist-news-page-style articles that give me the leader and then show me what is out there being written about it.

Thus was born the concept of Kagtum - the phrase “kag tum” means “to bring news” in Sumerian, the script of which is the oldest written language currently known to mankind. Kagtum will be a wiki news site that helps target articles based on relevance to you and your life. Relevance is everything.

The idea is quite simple, but the algorithm needs some polish before I can roll it out: we create a news story perhaps based on a report in MSM, or perhaps as a first-hand eyewitness account, that points to online sources if available. We then attach to that story some “impact profiles” based on location or a tags.

For example, a story happening on my street (say, planning permission for a new development) would have a geocoded location and an impact radius of the local neighbourhood. A story happening in 10 Downing Street would also be tagged with that location but could have an impact on the whole of the UK. Suppose the latter story was a policy announcement on Iraq - we’d add Iraq as a location impact as well.

I then login and give my location as my postcode or street, which is geocoded, and the software knows that the story in my street is relevant to me, so is the story in Downing Street. It knows therefore, what is relevant to each and every user and displays the appropriate stories.

Let’s suppose however I have no interest in Iraq. We can tag stories and users can also add tags to their profile that they’re very interested in or very disinterested in. If I said I wanted all stories marked “Iraq” to be pushed down the queue then its relevance to me would be lowered - it might still appear, just not as prominently.

In theory then, when I log in to kagtum, I would see stories about technology, politics and cricket, particularly with stories about my local neighbourhood (stories about technology in my neighbourhood would be even more prominent), whilst my friend who doesn’t care about anything but beer and football will see something perfectly tailored for his interests.

It may also be the case that there are multiple profiles for each user (home vs. work) and that a user can add multiple locations - where they live, where they work, where they grew up, where their parents live - and sees a mixture of stories about places they care about.

The biggest problem I had this weekend was developing the specifics of knowing which stories to show to each user. The problem isn’t hard algorithmically, but providing a technique that doesn’t harm performance and can scale to more than a few hundred users online at a time is proving a little tricky using standard ActiveRecord associations and using the methods baked into GeoKit by default.

There is also an issue of what we mean by “radius”. Saying “this story is important to everybody within 5 miles” is simple enough, but what if I say “to everybody within Greater Manchester”? I somehow need to know if a given longitude and latitude is within that district or not. The Radii Problem (as I came to call it whilst muttering to myself) is important and it’s difficult. I discovered it as I added a story in Washington that was important for the whole of the US - if I added a simple radius of 3,500 miles (to take in California) it of course also covered a huge chunk of Canada, Middle America, the Caribbean, the whole of the North Atlantic (including Ireland!) and most of the North Pole. For a story about domestic US politics, this is obviously needlessly “grabby”.

I have ideas on how to solve this problem, but they’re going to take a few weeks of playing with datasets from the UN and other agencies to be able to get them working smoothly.

There are other aspects I have planned for the site around developing narratives and helping individuals become kagtum journalists, but I’ll keep discussion of those for after the roll-out of both kagtum and the new vagueware.com.

I’ve turned comments on for this article, so if you have thoughts, ideas or suggestions, please leave them.

In the last few weeks, I’ve been evaluating source code I’ve written over the last year under closed source commercial agreements. I did this partly to try and look at what I did wrong and learn from those mistakes at a business level and technical level, but also to find out if there are common themes to anything I was working on that I could extract to make my life easier in future.

What I found shouldn’t surprise most people. Everything I did was about building forms, allowing data from those forms to be collected, and then looked at in some way. Every project looked like this:

• Define a form
• Build form
• Users input data into form
• Save data
• Look at data

Sometimes I would define/build the form and deliver the app, but at least two apps included the ability for users to build forms them (basically, survey software).

In fact, all web sites with UGC follow this model at some level - a blog engine is a form for a post, followed by the display of entered data in a particular way or set of ways. YouTube is a set of forms to handle file uploads followed by some data processing, and then displaying that content.

That’s quite interesting, because we have so far thought about web applications being custom little pieces of code in almost every case. Rails and similar frameworks enforce this model however, and make it easier by doing a lot of the heavy lifting involved in describing those processes. However, ultimately all we’re doing is putting lipstick onto relational databases. If that’s all we’re doing, surely there is a quicker way of doing it?

I was thinking that each of those stages in each application is already defined somehow as a real world business process we want to map into software. Why can’t we find a way of being able to quickly define a business process in code, and then just generate an application based on that definition?

It seems I’m a few years behind in my thinking. Business Process Management (BPM) is a mature area of development with a gazillion standards out there and it would seem XPDL is the XML-love of choice for this crowd. Digging further, I found something even cooler for the Rubyists amongst you: OpenWFEru nicknamed ‘Rufus’ amongst developers seems to have most of the heavy lifting done for you. The example looks promising.

This is interesting for me, because I have to build a couple of pieces of software soon which really are understanding workflows within teams, and I’d rather spend more time reading 19th-century books on political philosophy (hey, everybody’s got to have a hobby).

As a result I’m trying to work out how to hammer this into those projects. If I can find a way of being able to take the “I’ll look after the forms for you” aspect of Rails with the ease of defining workflows found in OpenWFEru and coupling them could you define a bunch of schemas and a workflow and then generate a better scaffolded Rails application? Would the controllers be able to mature over CRUD and do something more useful? Or could you build a CMS in Rails that uses user-generated workflows to allow for quickly hacked-together custom applications? It’s an intriguing bunch of thoughts…

On the 1st March (next Thursday, as I write this), I’m planning to do a mini re-launch of Vagueware.com and with a new website comes a new business model.

I will be phasing things in over the next 6-8 weeks. First, the “open innovation” phase, where ideas are thrown around, submitted and developed by anybody with an interest. Then the time to turn some of those ideas into real open source code, so anybody and everybody can develop the ideas further. And of course, run useful software. Finally a services model to make all your Rails deployment nightmares go away, and to bring some cashflow around those open source tools - support, maintenance, bespoke customisation will feature as well as hosted SaaS solutions.

However, I have a conundrum.

I’m busy finishing up work elsewhere right now. I have some todo items on older projects to close, and I am also involved in a second company completely unrelated to Vagueware that desperately needs some of my coding love right now. Time between now and next Thursday is tight. And the code base for the next version of Vagueware.com? Well, to be honest, barely started.

Right now, I need the splash page, and the ability for users to create accounts, edit wiki pages, for me to be able to structure some CMS around it all, add some forums, etc. It’s not a huge job, but to code it up from scratch even with the existing plugins out there might take longer than a week given other pulls on my time. It’s obvious that given the focus on it being a Ruby/Rails led set of projects, the time should be taken to develop the site itself in Rails.

There is an alternative though. Use something else other than Rails for now. Drupal does nearly everything I need and I could configure it all up this weekend ready to go. But it’s PHP. And that feels like a lie to me, and a lie to the other people I want to involve in this.

I could go meta and suggest that the first project is a tool to replace the site in Rails that would then allow Vagueware to become self-hosting. At least then the ideas would get started, and providing I was able to export everything from the inter-rim site when the job was done, nothing would be lost. It would allow those people who want to show up on day one to be involved in developing a community tool useful to them, and even have an input into how projects should be handled in the future. It could be an advantage.

It still feels like a major hack though. Anybody have any other ideas? I could delay the launch by another couple of weeks, but I’m keen to get started ASAP.

For a long time, I’ve had a problem explaining exactly why software engineering doesn’t work like other kinds of engineering. One of the issues I’ve had is trying to find the wording needed to explain that programmers don’t really build anything, and that to manage building software like building a bridge makes no sense. I couldn’t quite put my finger on the right words though.

Until now.

Jack W. Reeve’s essay on ‘What is Software Design?’ is the best work I’ve seen to date on the subject. He argues - convincingly - that programmers are designers, architects, draftsmen at a drawing board. We don’t build anything: compilers, linkers, interpreters do that for us. He points out how flawed an idea it is to produce a design document that can never truly represent the details of how the software will work, because it is an abstraction of an abstraction. The only accurate design is the software source code itself.

What’s more, it makes sense that in the same way that an architect can build a model, which can be turned into a few more detailed drawings, which can then be turned into engineering drawings, it makes sense to start all software development with a set of mock-ups which are then turned into a UI (say, static HTML) which then become plugged together with code. It’s like building a skyscraper by defining what the bits ‘users’ will see will look like, then working out how the nuts and bolts will hold it together: exactly what an architect does.

His essay dates from a time when the best language available to programmers to express their design was C++, and he argues that C++ helps his model of ‘design as code’ along nicely. It was the best language for the job because as an object-orientated language, it allowed an expression that most closely resembled how we abstractly thought about objects and data in the real World. Since then, of course, things have moved along a little bit.

I would argue today that Ruby is the best design language we have available to us. I claim this, because I actually find it easier and quicker to express an abstract design - which in turn can then execute - through Ruby than I do through a diagram or notation or pseudo-code.

At this point you might be thinking “yeah, right, whatever!”, but this isn’t some idle boast, I eat my own dog food.

The other day I needed to clarify a design point with another programmer via e-mail. I needed to express a HABTM relationship being used as a way of listing ‘exceptions’ to a ‘everybody/nobody’ flag stored in a model. The details aren’t important, but I considered for a moment the very best way of communicating this. I considered drawing a UML diagram. I thought about a quick sketch with some boxes, I considered a little pseudo-code. I then remembered that the programmer I was discussing this with could code Ruby, and maybe if I just developed a few stubs with some comments he’d get the idea.

Five minutes later, I had not just produced stub code. I had some migrations that would build the tables needed in Rails, and I had a few methods I was proposing adding to a model. It was untested, and some DateTime handling code would need a little fleshing out, but I’d discovered it was just quicker to write the code than it would be to write the comments explaining what the code would do. I actually ended up writing a software design in my mail client, that I could copy and paste over into a code editor and with a little bit of expansion and testing, get running.

In other words, the perfect design notation seems to have been discovered - it’s not UML that generates stub C++ in a CASE tool, or some formal design notation. It’s Ruby that just, well, runs. It is perfect because it is the perfect balance of programming language and design notation.

So not only was Reeves right in saying that source code is the best detailed design possible, that we are designers at heart, that programming languages that work at an abstract level are a step in the right direction, that formal design tools are useless and pointless, but he was even right that eventually we’d produce a programming language that was just a compilable design notation.

We now have that tool and its name is Ruby.

UPDATE: Two separate comments - each without seeing the other, as I didn’t approve them until this morning - suggest that LISP is a better design tool than Ruby.

It is worth pointing out that Ruby is kind of a grandchild of Lisp because it inherits so much from Scheme, itself a dialect of Lisp.

So is Ruby just another Lisp dialect? No. Whilst borrowing aspects of Lisp, it is more closely related to Smalltalk in terms of its object-orientation. It also borrows from Python, Dylan and CLU. It uses the best of all of them - Lisp included - and makes something better.

Also, there is another important part of Ruby that Lisp (and Smalltalk to be fair) do not yet have: an easy way to rapidly produce production-level, deployable, useful software. I can build a web application in Ruby - thanks to Rails, or Camping - in relatively little time compared to 10 years ago in PHP or Perl. I suspect, although haven’t researched it fully, that to do the same in Lisp might take me a little longer.

Ruby has many of the great features of Lisp baked in, but many of its own bolted in to boot. What’s more, the design ethos of Ruby is its strongest point: Ruby is designed to make programming pleasurable. When you enjoy writing code, you write more of it in less time, and with fewer bugs. Lisp might be fun for those who enjoy it, but I agree to some extent with Larry Wall on this one: it “has the visual appeal of oatmeal with fingernail clippings mixed in”.

If you like Lisp, I suspect you will love Ruby, and you’ll find yourself more productive in it. Either way, I’ll concede that for some people in love with it, Lisp is as useful to them as a design language as Ruby is to me. We’re both lucky, we both know we are, and we’re both a step ahead of the C# and Java guys.

I still say Ruby rocks more though. :-P

UPDATE 2: Changed link to the PDF to point to one held at the official home and authorised version of these PDFs. Thanks to Daniel Read for pointing out my error in directing you all to a pirate copy.

Yesterday I talked a little about market rates and thinking about it overnight, I’m even more confused about the Ruby market rates.

I mentioned yesterday that the ‘sticker price’ for Vagueware is £300/day - normally discounted, mind - at which point most people do a quick mental calculation and assume I must be making £70k/year. Nothing could be further from the truth. Consider the following:

• A client is unlikely to end up paying that rate in the first place. It’s where negotiations start, and they normally end some 20-30% lower than that unless they’re in a hurry
• If the project over-runs and I get delayed, my time comes out of my pocket: I normally quote for ‘a job’ reckoned at ‘x days’ rather than as an actual day rate
• I’m not employed 100% of the time. Right now, I’m actually working 2 ‘work days’ per day by working 16 hours/day, but that’s rare. I’d say 70% utilisation is the norm.
• I pay my own NI and tax obviously
• They both require an accountant, plus I don’t want to deal with Companies’ House so that all costs money
• I have insurance, liability cover and legal costs to pay
• I pay my own sick and holiday pay. Actually, I can’t afford to take time off this year, so there won’t be any of that.
• If I want or need to do some training, I pay for that.
• I have to cover other costs - phone, post, fax, broadband etc.

When you consider all that, a ‘normal’ rate of £300/day actually works out to about £30k-£35k/year, and to get that requires more than a few 12-14/hour days. Given that I could get £5k/year more for working a 35-hour week for somebody else, you might think I’m mad. Truth is, I probably am.

In fact, I just looked at the books and this year due to a dry patch in the Spring, one project that over-ran by two months (I know how to pick awkward customers), and some high anticipated costs coming up (equipment upgrades) I’ll struggle to walk away with £18,000 after all is taken into account. I don’t do this for huge piles of cash though - I do it because I can be my own boss and work on my own projects when I’m not working for clients.

That said, this brings me back to the guys who are hiring themselves out at £150/day - how can they afford to do that? By my maths, that would mean living not on the £30k/year a quick mental calculation would suggest, but less than £8k/year! Unless:

• They somehow dramatically reduce their training, which I don’t think you can afford to do in something this fast moving
• Don’t allow any negotiation of rates, which doesn’t work with most clients - everybody likes a deal
• Are employed 100% of the time at that rate, difficult to do right now with Ruby
• Outsource all their work off-shore and so ‘double-load’ heavily: i.e. take on 100 hours work/week but only actually work 10 of them because other people are actually doing the heavy lifting.

I don’t think any of these are practical, so I’m quite confused by it. I just can’t see how the maths add up. In addition, I don’t understand how an IT recruitment consultant can think that is a ‘fair price’ for skills that cost a great deal to learn and keep up-to-date. How can they honestly justify offering a rate that when all is said and done works out to paying a skilled programmer less than an average forklift truck operator could take home?

Something smells about this…

There is no doubt that 37signals have had a deep effect on the web development community. Most people didn’t wake up to their antics until relatively recently, but the truth is that they’ve been dishing out design tips and hacks on their Signal vs. Noise blog for a while now. In the last couple of years though, things have become a little… ‘funky’.

First, there was Basecamp a.k.a. the ‘anti-MS Project’ for project management. It was cute, handy, useful and for the market it was designed for (web designers) almost perfect. From that, they extracted the undercarriage and realised they had a framework for not just producing project management applications, but almost any web application - Ruby on Rails - which has gone on to be one of the biggest growing development frameworks on the planet. Vagueware (as in, me) now codes exclusively in Ruby and specialises in Rails development.

The products kept on rolling out - Ta-da, Backpack, Writeboard, Campfire - and the fandom got more and more intense. As a result there are now people known simply as ’37signals fanboys’ because no matter what the guys produce, there is a queue of people ready to hand over the cash. Sometimes people asked what the hell was the fuss about. Writeboard, is after all, nothing more than a text box with version control.

As a result of all this attention, expectations for their first venture into online book publishing as a company were a little mixed. Some people were thinking ‘same old stuff, re-hashed’ whilst the fans… well, let’s just say they were ready to replace various holy texts with copies.

You won’t find Getting Real in any bookshop. It’s available online-only as a downloadable PDF. Every copy watermarked with a ‘Specially prepared for (your name here)’ at the bottom of every page. This is an unusual way to enter the mainstream book market, but as their July 20 update shows, a more than profitable one.

So is it worth the $19 to buy? Well, I bought a copy ages ago, skim-read it, and didn’t get a chance to sit down and give it a thorough reading until this last weekend. I thought as I had finally given it some love, to share what I found.

First things first - there are 16 sections, each having between two to nine chapters, with an average of about seven or eight. Each chapter is quite light, and generally tends to expand a little on the title. As a result you could, in theory, just read the list of chapter titles and get a good idea of the best ideas from the book. Most chapters are less than two full pages long, and include quotes from Kathy Sierra and Seth Godin, so the real ‘meat’ is in the concepts, not in the writing.

In fact, I am reminded here of a part of Zen and the Art of Motorcycle Maintenance where the principal character describes reading with his son. He suggests reading a sentence - just one - and then stopping and thinking about it. Talking about it. Dissecting, pulling, morphing it. At the end of it all, decide how you feel about it and then move onto the next sentence. After you’ve read that sentence, stop, and analyse that as you did the previous one.

I tried reading like this once and it was an extraordinarily hard process, however I got a real insight into the material I hadn’t thought possible before. If I’m honest, if you look at the list of chapter headings, do the above, and you’re probably going to be able to get the core concepts down in your head without spending $19. That said, that’s an option for the poor - it’s not a lot of money, and the lazy would do best to save their mental energy and just shell out for the book.

Project management theories are all alike in one sense: they are codified common sense. PRINCE2 is basically a book that could be re-titled “Common Sense for Idiots” whilst agile is a way of letting developers work their own way whilst keeping management happy - mainly because management don’t think programmers have any sense whatsoever.

Getting Real is no different in this respect. It’s an “Agile-light” that concentrates on user experience above all else. However, it also stretches the boundaries of project management and touches on how to run a web product company in general. Sections that wouldn’t normally belong in a straight PM book include staffing, pricing and signup strategy, and how to keep customers happy would not belong in a traditional book on development methods.

It is also a book that is not meant to teach, but rather help you evangelise. It comes in a site license version (which at $49 is quite reasonable) so that you may spread the word amongst your team and help get the company on the same page. And that’s what this book is about - getting your team pulled together and heading in the same direction.

Project methodologies often concentrate on how best to document a project and how best to present that documentation within the team so that all concepts are clearly understood. Getting Real sets fire to that concept and suggests there is only one thing the business needs to worry about at any point in time: code that does what the customer expects.

To get a team to the point where they no longer need the traditional software lifecycle can take time and energy, and in many ways Getting Real can help short-circuit that. Reading it through with real-life examples can help convince you and your team that it’s at least worth a go - and that’s the biggest obstacle in changing any working style.

Some of the concepts do feel a little strange in places. For example, they suggest you should always have three people on the team: one developer, one designer, one person who can straddle both. This is just arbitrary and doesn’t make much sense. One programmer with design skills (or the money to get some if he can’t use OSWD or similar) could easily pull a project together with hard work - I should know - and a programmer with a designer on their own could easily do it. Where the third person steps in, I don’t know, or why it would be so dangerous to have four people, I’m not sure, but I’m guessing this ‘three person’ set up is just the way 37signals handled things themselves internally.

Their staffing advice is also a little strange. How can you assess a designer based on a week’s work? I’d rather assess them on a lifetime of work. Same with a programmer, if I’m honest. I also understand the point they make in saying that good wordsmiths will be better communicators, but only if the primary form of commuication is written - if you’re spending most of your time coding in ‘alone time’ and it’s the pub conversations where the real team collaboration is worked out, the fact they can write in iambic pentameter isn’t going to help you one jot. I’d say: hire people who fit, regardless of wordsmith skills.

The overall push with this book is one of getting something out of the door as quickly as possible. Interestingly it suggests we develop simple solutions that work well instead of complex solutions that are in perpetual beta, and in this I find myself in wholesale agreement. We live in an age of Web 2.0 where getting anything that feels as though it might impress out of the door is seen as a greater acheivement than getting the right thing - just enough to get customers using the product and being surprised by it - out of the door.

Overall it’s a pleasant read, inspiring in places, and has practical knowledge that beginners could make use of if they’ve never worked on a software team before. For those of us who might be considered ‘old hands’ by now, I’d say it’s an interesting twist on how to get over the procrastination of starting your own software product line, and I intend to make use of a lot of the advice - but not all of it.

That said, you need everybody in your team to be signed up to it for it to work, and it will take time for people to adjust. For example, last week I had a discussion with somebody on a project who had read this book and wanted to work in the Getting Real style, but had to be held back from drawing an entity-relationship diagram as the first stage. It would seem that old habits die hard, and despite all the good intentions of Getting Real, might take some time to overcome even with the converts.

I have recently decided that to become a better developer, I need to learn how to play chess properly. This might sound eccentric, but let me explain.

I know how to play chess in the same way most of us learnt how to play the guitar as teens - we knew where to put our fingers and strum along, not really attempting to get to grips with the underlying nature of the instrument. In other words I know the names and legal moves of all the pieces, I know the middle of the board if often the most important part to dominate early in the game, and that’s about it.

I am a truly terrible chess player, because I lack the ability to remember techniques and tactics, and I don’t have the patience to understand how to play an over-arching strategy. I just move pieces around the board in a way that seems defensive or attacking depending on where my opponent is in their game.

If I’m honest with myself, quite a large amount of my development time can feel like this as well - I know how to code, I have a general idea of what is sane and what isn’t, but I lack the inner development to be able to see project as a strategic objective with each method and line of code another tactic in the battle.

Battle? Who’s the opponent? Again, here I need to be honest with myself, because whilst customers changing requirements, project managers not knowing what is going on and flaky code on the production servers can be an enemy to productive coding, I have to admit I am my own worst enemy. I know it’s easier not to write the tests, not to refactor my code, not to think if I could replace that twenty lines of code with three, not to go back and make sure that my tests covered every possible fubar the users could throw at it, not to comment code properly, etc.

I hope by encouraging a strategic and tactical perspective in my work, my code will get better. Chess is great at training the brain to think in ways I think will be useful to me in my work. Not convinced? Well after just a half hour of reading up on basic chess strategy and tactics, I’ve come to the following conclusions about how to improve my day-to-day developmet:

• My language and development tools are my ‘material advantage’ in chess terms. Ruby - my language of choice these days - allows me to express ideas more easily than other langagues, and in less code. Rails gives me a lot of stuff for free. Unix does too. These are all advantages my ‘opponent’ does not have - it is often easier to write good code than it is to write bad code.
• Automated testing can be my defence. They give me confidence that code is generally correct and allow me to move forward safe in the knowledge that as I progress I’ve got those pieces at the back there covered.
• Documentation is like a ‘fork’ - I can challenge my understanding now and deal with my lack of understanding 12 months from now by making sure code is commented properly.
• If I encourage myself to think three, four, five moves ahead and think about what my ‘opponent’ might do as counter-attack, that’s going to make me both a better chess player, but a better developer too. Right now I spend way too much time thinking about the problem in front of me and maybe the problem coming after that one.

This might feel like I’m stretching an analogy, but really I’m just trying to stretch my brain to thinking in new ways. If I’m able to develop my skills as a chess player, I can’t see the harm it would do to other areas of my life.

Sun is going to be giving full support to Ruby, and will be shipping a Ruby parser built on top of the Java Virtual Machine apparently with Java and Ruby both being fully supported by the VM.

I still am not sure if this isn’t some weirdo-World practical joke. I expect to wake tomorrow morning to find this is just another version of the Parrot Joke (which eventually became a real project).

If true, it means Ruby is about to get incredibly mainstream, and I’m going to spend the next five years having some real fun. It also means Joel is going to look even more stupid with regards to stating that Ruby is not ‘enterprise-ready’.

One of the biggest problems with Ruby right now is the current parser is slow and we’re having to jump through hoops just to get performance up. With web applications it’s not a major problem until you start to scale, and then most of your performance problems can be ironed out with some cacheing and database schema optomisation. Through more clock cycles at the database server, and most web apps get quicker - Ruby isn’t the slow part in that equation. However, this changes the game - _if_ the parser Sun ships is nice and fast.

The mailing lists however are strangely quiet. It may be that too many people want to adore Matz for longer, or that the performance will suck against the new official parser in development, or that nobody believes it. Or it really doesn’t matter.

But I say that when a language gets mainstream commercial support from one of the largest tech companies on the planet, that language has arrived and we should be grateful for it. I only hope the Java kids don’t steal our lunch money when we turn up and we all play nicely together.

The above link is to a thread that points eventually here and here that both help convince me this isn’t some warped joke.

I always thought there was something interesting about Sun. I think they might be about to become my favourite company again. I might even take another look at Solaris in coming weeks to see if they’ve made it suck less than the last time I played about five years ago. See - this is smart thinking on their part. They’ve got me interested in what they’re doing again. Tres cool, non?

I spend most of my time these days writing in Ruby on Rails which is currently the darling of the web development community. I don’t just like coding in Rails, I love writing in Rails.

I love it, because the time from the conception of an idea to having production-ready deployable code is shorter than with any other framework I’ve ever worked with. When I came up with ideas in the past, i procrastinated about developing them, because the pain development meant that one small feature could see me fighting my computer for a week. Rails is different, providing you think carefully before putting hand to keyboard.

The language it uses - Ruby - is so beautiful and elegant to work with on a day to day basis, that it feels like it’s eminated from some weird hypnotic cult from Japan. Funnily enough, that’s pretty much exactly where it came from, and the pleasant idolatry of Matz - the language’s creator - means that the community is one of the nicest to hang around. Not since my regular hanging out with the FreeBSD guys have I had so much fun.

Right now though, Ruby on Rails is going through a bit of a rough patch. Not a big one, but it’s there.

Firstly, the community is full of new people who have been told that anybody can write a Rails application, and they figured that as they installed their own wireless router/got bluetooth working on their laptop/know what FPS stand for, that they can have a go. Cool! The more the merrier.

But they sometimes give up at the first problem they face and run to the mailing lists asking for basic advice. This isn’t their fault, this is our - the community’s - fault. The documentation out there is either rather terse and not beginner-friendly or it costs money that some people just can’t spare.

Then there is the jealous crowd, who are now realising that the last 10 years of perfecting their Java kung-fu may have been usurped in less than two years and are rather hacked off that some upstart is stealing their glory. They want to fight back. The way they manifest this is quite odd and rather easy to defeat, as a set of arguments but it’s annoying. The real problem is, a little set of battles are now going to roll out over the web that will breed resentment.

The really horrible thing is, RoR’s critics have one really valid point: building multiple-language websites in Rails sucks. It should be easy, but it’s not. The reason is because Rails is what is known as “highly-opinionated software” - i.e. the developers on the core team take an opinion on something, and if they don’t like it, it doesn’t go in. They don’t think localization support belongs in the core system, because they don’t need it.

As a result, the 5 billion people on the planet who don’t speak English are going to find Rails sites a little harder to work with than they should. It wouldn’t take much to fix this state of affairs though: it just requires the Rails team to take an opinion on how to handle Unicode, localization and i18n in general. There are tools out there to help you do it all, as bolt-on extras, but how dumb does that sound: “Hi, we’ve got this framework to help the World become an interconnected one, to produce the next generation of web apps, but, eh… well, speak English or struggle, right?”

There is then another issue with the opinions of Rails core team that means it doesn’t all end with i18n and localization support. Some of their opinions are just outright silly.

Last month they decided that when they found a security hole, instead of doing ‘full disclosure’ and telling everybody what was going on, to just tell everybody to upgrade. What this meant was that clued up hackers could look at the source code and in about 10 minutes work out what had been patched and how to exploit it, but the lesser clued-up people didn’t know how to assess how urgent it was for them to upgrade: did they tell their CEO the site needed to go down immediately, or did they just do an upgrade in the next maintenance cycle overnight? Opinions can be a great way to provide focus, but the opinions of the core team are actually starting to hurt Rails sometimes.

I genuinely believe that Rails is one of the greatest web app frameworks developed - not because it’s fancy, but because it does something amazing at the business level as well as the technical level: reduce the time from idea to deployment.

You can’t argue with that, and in itself it starts to make up for the poor localization support and odd security announcement procedures, but the time has come: Rails needs to touch the rest of the planet, and the opinions formed by the core need to take into account the community’s opinions more than core’s from here on in.

One solution might be for the Rails core team to take a leaf out of the FreeBSD cores team’s: become an electable body, thereby allowing developers to have a say in the future of the framework.

After all, this is no longer a toy app or a simple project that DHH is doing on contract for 37signals - this is an industry with thousands of full-time professionals in it. Our rent money and kid’s college funds depend on this code base now, and we can’t risk letting the FUD-spreaders actually make valid points. We also need to help the newbies out better - the more people developing Rails scalable multi-lingual Rails apps, the more stupid the FUDers look. That’s my opinion for the software, but I know it doesn’t count for anything compared to many others.

In the meantime, Rails has some interesting times ahead of it, as does Ruby. Personally, I can’t wait.