Edd Dumbill's Weblog: 'rails' articles

RailsConf, remotely

Edd Dumbill — 2008-06-02T12:01:03Z

I couldn't make it to RailsConf this year, but have been playing my part from afar. It gives me a small kick of pride to note that now RailsConf is run entirely out of Expectnation, which is of course Rails-based.

Here's a badge I clipped for my virtual scrapbook.

Join the conversation about this post

Telling stories with RSpec

Edd Dumbill — 2008-01-12T13:14:43Z

For a while now I've been writing RSpec specifications to test Expectnation, rather than "traditional" Rails unit tests. Although I don't completely get the Behaviour Driven Development hype around RSpec, I do find that it helps in writing more literate and maintainable test suites.

Until very recently, however, RSpec for Rails had no decent answer to Rails' integration tests. Integration tests enable the testing of compete scenarios, as opposed to the specific testing of methods or single HTTP operations that unit and functional testing provide.

For instance, our integration test suite for Expectnation tests things such as "a user tries to submit a proposal, is redirected to the account sign up page, signs up, and then is redirected to the proposal submission page". This involves multiple steps, and the whole suite of tests necessitates a lot of reuse.

The need for reuse resulted in trying to construct a DSL-like set of methods for each step, such as "user logs in with email X and password Y". It has gotten a bit tangled, especially when looking at test failures to see what's really gone wrong.

After a while, unravelling the test suite starts to feel like unpacking Christmas lights. (Photo: shoothead)

RSpec Story Framework

My problems with integration tests made the Story Framework, newly available in RSpec 1.1, look very interesting. Based around plain text descriptions of application behaviour, it lets you write integration tests with good reuse and good diagnostic reporting.

For example, here's a story I wrote to check the login process.

Story: login as an existing user
        As an unauthenticated user
        I want to log in to Expectnation
        So I can see my account details

        Scenario: login details are correct
                Given an event provider
                And my test@example.org account
                When I log in with email test@example.org and password foofoo
                Then I will be logged in
                And I will be shown the account page

The words such as "Given", "When" and "Then" are cues to the story runner to execute some code. Behind the story sits a collection of steps. Here's a couple of steps from this test:

Given "my $email account" do |email|
    @user = find_or_create_user_by_email({:email => email,
      :password => 'foofoo',
      :password_confirmation => 'foofoo'})
end

When "I log in with email $email and
                         password $password" do |email, password|
    post '/user/account/authenticate',
      :user => {:email => email, :password => password}
end

Notice how a clever bit of string matching allows you to pass parameters from the story prose.

With a small bit of bolting together, the prose stories are then run as code and the tests executed. One nice touch is that if you write a story which doesn't yet have code behind it, it is marked not as a pass or fail, but as pending, which means you can sit down and write all your stories and then get to coding the steps later. This beats writing empty tests which transparently pass.

To conclude, the RSpec Story Framework offers these advantages over Rails' integration tests:

Text-only stories makes it very easy to write and understand tests
The construction of steps for each line makes it easy and maintainable to construct reusable components for the tests

Edd 10.5 release notes

Edd Dumbill — 2007-11-14T16:03:04Z

I’ve had my head down with lots of hard work and exciting developments, and alas too little time to blog here. However, I wanted to post a few updates as to what’s been going on.

Expectnation

Most of my time’s been spent working on Expectnation, the conference and event management application my company works on.

The highlight of this quarter is that we launched registration facilities, so now in addition to planning content, creating your event web site and managing speakers, you can take money and register folk for your conference.

We’re very excited about adding this, and it makes Expectnation the ideal “conference in a box” system.

It’s a complete buzz to see submissions coming in for RailsConf using our software—Rails-based, of course!

Conferences

I’m currently gearing up to open the call for participation for XTech 2008. We’ll be in Dublin, Ireland, in early May 2008. More soon on this front.

Additionally, I’m going to be co-chair with Allison Randal for O’Reilly’s OSCON 2008. I can’t really say I’m filling Nat Torkington’s shoes (more like ironing his shirts) but needless to say it’s a great privilege about which I’m thoroughly excited.

With being so busy, I’ve not had the time to travel as nearly as much as I’d like this year (the small matter of the baby twins has some bearing on this, too). I’m very sad to be missing XML 2007, as the XML crowd remains the most erudite, eclectic and friendly bunch of people I’ve ever had the pleasure to work with.

Writing

My sporadic attempts to attain literary posterity will again come to the fore over the next few months, as a new project starts with my old friend and co-conspirator Simon St.Laurent. All hush-hush for now, but I look forward to sharing the news and maybe some early-access content here.

Join the conversation about this post

Collecting minimal user information

Edd Dumbill — 2007-06-22T15:37:46Z

Web applications are in constant competition for a user's attention. Unlike shrink-wrap software, there's often no captive audience, and web apps must gently guide and woo users to help them to the best experience of the software.

This is particularly true when considering the problem of collecting personal details from a user. Collect too little information, and your app might not be able to function effectively. Collect too much information, and you raise the barrier for participation with your application. Users may either not be bothered, be alarmed at the apparent intrusion into their privacy, or fill out bogus information.

One size doesn't fit all

I originally stumbled on the issue in the development of Expectnation. The amount of information a conference speaker needs to give the organizers is significantly more than that of, say, a reviewer. An organizer will often want postal and phone details for a speaker, which are largely irrelevant to the review process. All conferences and events rely on the willingess of participants, so the path to participation needs to be as frictionless as possible.

Thus, a one-size-fits-all personal details form didn't make sense for us. At best, we could have simply made more fields optional, but that would result in missing information that we really did need.

Another solution would be to provide a dedicated personal details form per user type, e.g. different forms for speakers and reviewers. This is a non-starter, however, as users can take on many roles within a conference.

So, we had a problem on our hands: different levels of interaction with our application requires different levels of personal information.

We also had a second problem, which is that not all events and organizers want the same level of information. For example, a user group event is unlikely to need the same amount of information from speakers as an academic conference.

Thus we have two axes on which the amount of information required varies: by role, and by event.

Our solution: progressive disclosure

We concluded that we wanted to adhere to two principles in the collection of user information for Expectnation:

collect as little information from users as possible, and
allow organizers to determine the level of information they wish to collect.

The first objective was achieved by constructing a matrix of information items against user role, with the possible values of {required, optional, unused} for each item. We then achieved the second objective by allowing this matrix to be varied over each event.

We've named this concept "progressive disclosure."

What this means in practice is that a user is only ever asked for the information required to fulfil the roles they have within Expectnation. If they take on another role, they are asked for the additional information at that point, and not before.

Implementation concerns

Extract from disclosure level editing UI

It would be untrue to say that progressive disclosure is simple to implement.

A user in our system will have disclosure requirements that are the union of all of their roles in all of the events they attend. Within Ruby on Rails, this means the conventional validation logic is useless to us, as it only deals with static requirements. Secondly, disclosure requirements are expensive to compute, so we need to cache them, with the inevitable addition of issues such as cache invalidation.

Beyond the data model issues, the user interface issues are, if anything, more troublesome. From an end-user's point of view, the difficulty arises when we need extra information from them, and presenting this in a way that makes sense.

From the event organizer's point of view, we have the challenge of presenting a controlling user interface for rather a complex concept. Organizers must be able to change the level of required information either globally, or per-event.

We opted for a grid presentation, an extract from which is shown in the screenshot in this article. Over time we'll be able to see how effective this interface is, and what we can do to improve it.

Finally, we have chosen sensible defaults for all disclosure levels, as the best result would be that organizers have little need to reconfigure the settings in the first place.

Making it look easy

Because Expectnation is a general application for organizing events, rather than targetting one specific one, we've had to construct a framework for minimizing user information collection, as opposed to simple implementation of known scenarios.

At the end of the day we have added a fairly complicated subsystem and an extra degree of complexity to our codebase. However, the result from the user's point of view is increased simplicity and a streamlined experience.

Every time you embark on something that wide-reaching and complex, you have to ask yourself whether the feature is really worth it. In this case, though, the answer is a resounding "yes". The user is the most important factor in our software, and making their life easier in an unobtrusive manner is a priority.

Expectnation blog: Only ask users for the information you need

Join the conversation about this post

Jeni Tennison on women in computing

Edd Dumbill — 2007-06-21T12:08:12Z

For a long time I've been vexed by the gender bias of computing towards men. It's clear that computing has multiple issues, ranging from its perception to the nature of its society. As organizer of computing conferences, I care about ensuring that participation is meritocratic and inclusive.

As various debates have taken place over blogs in the past on women in computing, I have stayed silent. Not because I don't care, but because I really didn't know what to say. I try to understand, but at the end of the day I'm a man, I tend to misunderstand important points, and I suspect my contributions would come across as at best naïve, and more likely, patronising. So many conversations between men and women on this topic end up in mutual uncomprehension. Better to stay silent than be a fool.

This is why I'm very grateful for Jeni Tennison's analysis of women in computing. It is the most helpful blog post I have read recently on the topic. Perhaps it's because Jeni's British, and we share some of the same cultural assumptions and constraints. But more importantly, it's because her article builds bridges to my experience and understanding.

An argument of femininity

Rather than simply appealing to tribes of men and women, Jeni places the discussion in terms of feminine and masculine traits. Like many men, I identify with certain attitudes and preferences more closely allied to my feminine side. By not excluding me, her wording helped me view the points she unfolded in terms that my own experience, however poor, could identify with.

I've often found contemporary computing communities to be suffocatingly macho. There's a strong pressure to succeed in terms of attention from the chattering bloggers, privileged inner circles and the capacity for vicious excoriation of those who fall from grace.

As I grew up through school and university, I held these sorts of social forms in contempt, as well as occasionally suffering at their hands. Yet now, bafflingly, I find myself under the impression I need to belong and compete in these spheres.

Self-efficacy

One of Jeni's central points is concern about one's own self-efficacy. This was the real revelation to me. I tend to assume most capable people I meet are aware of their own capability. Jeni turned this on its head for me when she wrote

... look at how Ruby on Rails is marketed. A big play is made of how easy it is. But if a language or framework is easy then people with low self-efficacy can’t win: if they manage to do something with it then they haven’t really achieved very much because anyone can do it; if they don’t manage to do something with it then they’re complete idiots. I’m not saying that we should advertise languages or frameworks as being hard, because obviously that can put people off as well, but a recognition of the barriers that people might face may, in a strange way, make them more approachable.

As Jeni brings her article to a close, it's with some shock and shame that I get the punchline loud and clear: "this isn't about you."

It's about empathy, inclusivity and selflessness. Human qualities that are unrestricted to either gender.

Join the conversation about this post

Why Bazaar rocks, and the highs and lows of its use with Rails

Edd Dumbill — 2007-06-20T11:04:52Z

While Subversion is for many the source code revision system of choice, I've never stopped long with it myself. Why? Because it's mostly a fixed-up CVS, and doesn't fix the really gnarly problem with revision control: merging.

Mark Shuttleworth has written an insightful little article on the key aspects of merging source code. Some of the points he makes underpin my choice of revision control system.

For several years now I've been a very contented user of Bazaar, in its first arch-based incarnation, and now in its latter form. The key reason has been ease of merging.

While most articles praising Bazaar are reports of open source development, I've also found it very handy for small in-house teams working on web applications.

There are very often multiple arcs of development going on at once, and the ease of merging makes it easy to ensure that long-running development arcs don't get ridiculously far from the main trunk of development. Bazaar's merging also makes it easier for lead developers to police the merging of the code base.

Using Bazaar with Rails and other tools

Working mostly with Rails, one repeatedly runs up against the assumption that Subversion is the golden path for revision control. This is perhaps a little telling about the level of participation most Rails-based projects have reached.

The tools story for a Bazaar user is both good and bad.

The good

Deployment: the Capistrano deployment system has support for Bazaar. I've written previously about the technique I use to deploy my Rails apps.
Collaboration: Trac is a wonderful integrated bug database, wiki and source code browser. Although it's a little hard to find, the trac-bzr integration works very well, and happily moves Trac out of the Subversion-based assumption that you can only have one repository root per project.

The bad

Continuous integration: with Expectnation, we've had to roll our own continuous integration system ('system' being rather a grand word for a shell script on a cronjob...) Most of the CI systems currently popular seem to assume Subversion.
Editor/IDE integration: some early work exists, but it's early days. I've not yet found anything making me want to leave the command line.

Join the conversation about this post

Really really getting the testing religion

Edd Dumbill — 2006-11-23T11:21:38Z

Writing tests is virtuous. It's the wholemeal bread of programming. Do it, and you'll be so much fitter. Except it tastes like cardboard and gets in the way of consuming the yummy treacle sponge of programming.

But now I've got the testing religion. I view the lack of tests with the disapprobation of a reformed smoker tutting and huffing at the merest suggestion of a Marlboro Light.

How did this happen and how can I be sure I won't backslide?

The moment of transition was the first time that a test saved me from releasing software with a bad bug in it. The theoretical knowledge of virtue was translated into the palpitating relief of not disgracing myself in public.

After that happened a few more times, I found myself desperately uncomfortable with the idea of releasing anything that didn't have decent test coverage. And so a virtuous habit is formed.

It's not just driven by fear. With the right tools to hand, writing tests can be a lot of fun. You don't always need to be "in the zone". If you've got a spare half hour here and there, you can use it to increase the coverage of your tests.

Getting better at testing is one of the ways I've become a much more proficient Rails developer over the last year of work on Expectnation. In case it helps anybody else, I thought I'd share some of the tools and techniques that are part of making Rails testing fun and effective.

Continuous testing

Whenever a checkin is made to our source repository, tests are run and the results emailed to everybody working on the project. As with the "you broke the build" disincentive, you need to be kept honest by frequent running of the tests.

There are a variety of tools around to help you do continuous integration with Rails, most of which have some dependence on you using Subversion for source control. In the event, I just created my own script to do what we required.

Coverage reports

One of the big mental hurdles with testing is knowing how many tests you should aim for. You can't prove a negative: even if your tests are all passing it still doesn't tell you much about the tests you haven't written that might fail!

We use rcov as part of the continuous integration process, and post the results to our project web site. The pretty red and green bars give you some idea of when you're starting to get adequate test coverage, and the line-by-line breakdown is invaluable.

Tainting strings

One of the easiest errors to make in Rails templates is to miss the call to h(), to escape any HTML in an output string. The only real way to catch these errors is through automation. The wonderful safe_erb plugin helps you do just that. By using Ruby's tainting mechanism for strings, it throws an exception if you render any external data unescaped.

One of the beneficial side effects of safe_erb is that you then become very particular about ensuring your functional tests properly cover every action in your application. Tests such as get 'index', which before seemed mundane and redundant, are now essential, as you want to test for tainted strings.

In addition to the above techniques, there are a lot of fun shiny gadgets to help you write tests, such as ZenTest, but the three things above are the ones I've found to be of significant value.

I ought to conclude with words of praise for Rails. It goes out of its way to make testing an important part of the development lifecycle, and the availability of the of unit, functional and integration test functionality makes it easy to get started. Every time I teach somebody about Rails' testing features, they end up finding it very enjoyable.

Don't forget, testing can be fun!

Join the conversation about this post

A deployment pattern for Rails and bzr

Edd Dumbill — 2006-09-29T13:50:19Z

I can't get enough of the bzr revision control system, and I'm quite fond of Rails too. So, I thought I'd share my deployment setup for Rails applications using Capistrano and bzr.

Capistrano works on the assumption that you're deploying from a revision control system. Secondly, it requires that your deployment server is aware of how to access this system. This leaves you with various options, the most obvious of which are:

Host your source repository on your deployment server
Have your deployment server equipped with remote access to your source repository
Mirror your repository to your deployment server

Of these, option 1 is out for all but somewhat casual projects, option 2 either opens up your source repository more than I like, or needs fiddly tunnelling of SSH which I don't think Capistrano is up to yet (I only like to use key-based access with SSH, rather than password based access, which seems at the moment complicate life where Capistrano is concerned.)

I've opted for option 3. The pattern I use is this. On setting up the deployment server, I push a copy of the bzr repository to a private directory. Then, on deployment I first update that repository securely from the master repository inside my network, then export the new release locally on the server.

Here are the relevant bits of my Capistrano configuration:

set :repository, "/opt/repo_mirror/#{application}"

…

set :scm, :bzr
set :checkout, "branch"

…

task :before_update_code do
  `bzr push sftp://deploy.example.org/opt/repo_mirror/#{application}`
end

One big advantage of this over option 2, a remote source repository, is that only the changes are sent up to the server, and the bandwidth-intensive application checkout happens locally on the deployment machine.

The final bit of improvement this could stand is to have the bzr checkout use export and not branch, but I think I'll have to alter the Capistrano's bzr plugin in order to do this.

Join the conversation about this post

Rails deployment tip for Debian systems and Apache

Edd Dumbill — 2006-09-15T22:26:07Z

I deploy my Rails applications with Capistrano to an Ubuntu machine, which uses the excellent Debian style layout of Apache 2 configuration files.

To keep things tidy, I like to place the Apache configuration file inside the config directory of the Rails project, along with the rest of the configuration for the Rails application and Mongrel.

With the help of a couple of Capistrano rules I can then ensure that, on deployment, the latest Apache configuration file is also sent to the server:

# after setup, do a one-time link in
task :after_setup do
  sudo "ln -nfs #{current_path}/config/#{application}        
     /etc/apache2/sites-available/"
end

# cause apache2 to re-read. you probably have this rule anyway
task :restart do
  # if you're running mongrel_cluster, uncomment the following line
  # restart_mongrel_cluster
  sudo "/usr/sbin/apache2ctl graceful"
end

The first time round you'll probably want to do a2ensite yourapp manually, but this could easily be added into the after_setup rule.

Not rocket science, but a pleasing bit of configuration that keeps things tidy.

Join the conversation about this post

Load-balancing Mongrel with Apache 2.0

Edd Dumbill — 2006-09-13T18:40:37Z

You would be forgiven for thinking that using Mongrel clusters to serve Rails applications was only a good idea if you have Apache 2.2 installed, as this is what most of the instructions on the web advise.

However, there are good reasons for still running Apache 2.0, one of them being that it's the most up to date version packaged in Debian and Ubuntu Linux. So, without mod_proxy_balancer, what can you do?

A simple solution is to use the randomizing feature in mod_apache's rewrite map feature. Say for instance you had 3 Mongrel servers, running on ports 4000 to 4002 on localhost. First create a file map.txt containing these numbers:

ports  4000|4001|4002

Then ensure the following directives are present in your virtual host configuration:

ProxyRequests Off
ProxyPassReverse / http://localhost:4000/
ProxyPassReverse / http://localhost:4001/
ProxyPassReverse / http://localhost:4002/
ProxyPreserveHost On
RewriteEngine On
RewriteMap  servers rnd:/path/to/your/map.txt
RewriteRule ^/(images|stylesheets|javascripts)/?(.*) $0 [L]
RewriteRule ^/(.*)$ http://localhost:${servers:ports}/$1 [P,L]

Of course, Apache config is complex and I advise you to test this properly — it's possible if you are not careful to leave your web server as an open proxy.

Thanks to Matt Biddulph for pointing out this method to me. I've written it up as nobody else seemed to have done so thus far.

Join the conversation about this post

Illustrated Rails, smart folks and publication

Edd Dumbill — 2006-06-23T01:15:03Z

It's been a fun day today, the pre-conference warm up day for RailsConf.

Over breakfast with Surj Patel and Matt Biddulph, we got to talking about debuggers and poking around inside Rails applications. With Rails being so new, I was intrigued in what happens when you hand a Rails application over to somebody. Does all the Rails magic help or hinder their ability to understand what's going on?

What kind of ways are there, beyond documentation (which nobody writes), to communicate the workings of a Rails app? We thought that what might help would be some kind of graphical illustration of the flow of control, linked to a source viewer, that showed requests being processed. Rails is built in a convenient way for instrumentation and introspection, by virtue of the aggressive use of DSLs and Ruby's language features. Based on these, are there tools we can write to help people understand what a Rails application is doing?

I've not yet had enough experience of either handing off, or being handed, mature Rails apps to say for sure what's needed. But it's going to be a problem we all face when Rails sneaks further into the system. Java's redeeming quality in the enterprise is that it's damn hard to write anything one might consider idiomatic. As a consequence, there are predictable ways in which one can approach code written by somebody else, all other factors being equal. Will Rails idioms cause trouble for long-term maintainability?

Lunchtime included an interesting exchange with Rich Kilmer. Rich used to work for DARPA on RDF and OWL stuff, and has apparently written all manner of interesting Ruby code that processes RDF. It's a crime I'd not come across his work before, but it's all open sourced in the Semitar project. The project web page looks modest, but if Rich's description is anything to go by, it sounds a wonderfully appropriate way to approach programming for the semantic web.

Finally, I notice that, as the day finishes, IBM developerWorks have published my Introduction to Rails for DB2 developers.

RailsConf proper starts tomorrow.

Join the conversation about this post

Edd on Rails

Edd Dumbill — 2006-06-20T00:28:16Z

This Wednesday I'm heading out to Chicago to visit RailsConf. The full schedule has now been posted, and it looks like a pretty absorbing affair.

It amuses me that US-based conferences often have evening sessions timetabled. In Europe, I've always preferred to leave evenings empty so people can eat, drink and socialise. But in big city hotel-land, I can understand the appeal of timetabling more of the day.

Here's a selection of the talks I'm most interested in hearing: Internationalizing Rails (almost the number one question we got asked about Rails when we taught our tutorial at XTech), anything related to testing, Rails Application Optimization Techniques and Tools, Rails Deployment. Oh, and some guy's talking about his work at the BBC.

I've just finished writing an article for IBM developerWorks introducing Rails to DB2 users. (I had surprisingly little problem getting DB2 up and running in a matter of minutes on my Ubuntu box.) IBM's DB2 integration for Rails is a great development, and it's nice to see them pushing forward with Rails as a platform. I'm hoping they'll post the article up before RailsConf starts.

Given a bit more hacking time, I'll be intrigued to see how DB2's XML support can play with Rails.

I'll be staying at the conference hotel, and am very interested in meeting up with anyone building Rails apps of a decent scale, or looking for a project to work on. Do drop me an email.

Join the conversation about this post

Give me books, twice

Edd Dumbill — 2006-05-22T18:47:50Z

Two books have recently been published that I want to read.

Rails Recipes (Chad Fowler)
Building a Scalable Web Application (Cal Henderson)

The first of these I took delivery of instantly in PDF form, and a paper copy will make its way to me in due course so I have it as a handy reference.

The second of these is going to take 12-14 days from Amazon (5-7 days if ordered through O'Reilly's UK distributor Wiley).

There's been a lot of talk on David Heinemeier Hansson's blog about PDF publishing, but to me it's simply a way of getting me the information I need quickly. Normally, I want the paper copy too.

Another small but significant benefit is that PDFs weigh very little! Having just taught a Rails tutorial at XTech, I can vouch that there was no way we wanted to carry around 30+ copies of the Rails book on the offchance attendees wanted to buy it.

Whereas some publishers have experimented with certain product lines available only as PDFs, I can't quite shake the feeling they're offering an inferior product in which they are not confident enough to commit to paper.

My suggestion is that PDF and print is not an "either/or" choice, but an "and/or".

Join the conversation about this post

Catching up

Edd Dumbill — 2006-04-10T22:56:32Z

Most of my energy recently has been devoted to organising things for XTech 2006, now just over a month away.

Here are some XTech-related snippets:

Mozilla Corporation has joined as a co-host. We'll have six Mozilla related presentations, plus a keynote about JavaScript 2 from Mozilla CTO Brendan Eich.
The Ajax Developers' Day continues to take shape. We're looking to add a Ajax toolkit lightning demo session at the end of the day. Contact me if you or your company wants to take part in this.
BarCamp Amsterdam II will be taking place directly after XTech. This will be a free-form participant-led conference, held over the weekend. Many XTech speakers and attendees are likely to hang around to take part.

MacBook

My new computer has arrived, an Apple MacBook Pro. I know I wrote some time ago about how disappointing it was for free software advocates to be using a non-free OS, and I am rather sad about this in some ways. I'll be writing in the near future about my impressions of the platform, and reasons for buying this machine.

Writing

My latest piece on Debian has been published over at O'Reilly, Installing Software on Debian. We've been a little slow getting through the publication of these, so I'll try and hurry the next few along.

Rails

Rails continues to impress. I wish I had more time than I do to use it, as it feels so right to work with. With Matt Biddulph I'll be teaching a day on Rails at XTech 2006. In the meantime, I highly recommend Chad Fowler's Rails Recipes, it covers the most common requirements from real-world web applications.

Oh, and I'm scheduled to attend RailsConf this June. My paper was (not too surprisingly) declined for the conference, but Matt's was accepted.

Join the conversation about this post

XTech schedule coming soon

Edd Dumbill — 2006-02-15T21:24:05Z

The selections for XTech are now almost complete. Over the weekend I drafted the schedule, which is under review right now by the programme committee.

Every year I say how hard a job this is because of the high standard of the submissions, and every year it seems to get harder. This year I found it almost heartbreaking to have to exclude some talks.

Number crunching

To illustrate, here are some statistics about the proposals and their selection. We received 177 submissions. Each of these abstracts were peer reviewed by at least 4 or 5 reviewers, from a panel of nearly 90 reviewers. From the graded results I shortlisted 105 proposals.

From that 105 I have had to fill 68 schedule slots, which meant about a third of the shortlisted proposals had to be excluded. Almost every single one of these would have been a great talk. They were so good, in fact, that I'm working on some ideas for adding to the schedule.

Notifications to accepted speakers will be sent at the beginning of next week. Rejection notices will follow a little while later. We don't want to send these out until we're sure we've done everything we can to accommodate as many quality presentations as possible.

I am enormously grateful to everyone who submitted a proposal. I can't wait to get the acceptance notices sent out so we can publish the schedule.

I can however reveal some early news about pre-conference tutorials. We'll have day-long tutorials on: Ruby on Rails; XSLT 2.0, XPath 2.0 & XQuery; and a Web 2.0 tech bootcamp. Also there'll be half-day tutorials on microformats, and XForms & XHTML 2.0.

Finally, it's worth noting that registration is now open. Also, if you work for somebody who would be interested in sponsoring the conference, do get in touch.

Join the conversation about this post

Places I'll be: Carson Summit, XTech, RailsConf

Edd Dumbill — 2006-02-06T20:20:51Z

The conference season starts again. Here are a few pointers to places where I'll be over the next few months.

Carson Summit on the Future of Web Apps

I'm really impressed with the group of folks that Ryan Carson's got together for this event. The emphasis on "lessons learned" is important to me, so I look forward to hearing more.

There's also a great connection in the topic with an article I wrote in October 1999, XML Inter-Application Protocols, in which I rave about applications moving to the web, the need for open standards, and the important role of XML in that through RSS and web services. All the stuff we're still just figuring out how to use! 7 February 2006, London.

XTech 2006

Being the conference chair I'm biased on this one, but it's safe to say that it's going to be an amazing event. Keynotes from Paul Graham, Amazon's Jeff Barr and Yahoo's Jeffrey McManus. Paper reviewing has just ended so next week we hope to publish a provisional conference schedule. 16-19 May 2006, Amsterdam.

RailsConf

Very excited to be going to the first ever Rails conference. I submitted a proposal, about which I've not yet heard. Being one of 80 such proposals, it looks like the competition's tough, but I'll be there whether speaking or not.

Though I'm arriving on June 21, I'm not booked in for the Rails Guidebook day, so I'm open to suggestions as to activities for June 22. 22-25 June 2006, Chicago.

Join the conversation about this post

Why Rails?

Edd Dumbill — 2006-01-21T11:43:56Z

When I moved this blog from being Zope-backed to using Rails several people got in touch to ask why. This is a brief explanation of why I've moved.

Firstly I should point out I've had a long and mostly happy experience with Zope. I got into Zope originally because I'd spent some time in constructing web frameworks from scratch (we're talking 1995-1999 here) and found that not only does a framework need good templating, it needs reusable components within that.

Zope seemed like a good fit, so I spent some time getting up to speed and was happy there. However, there were some things that didn't make me feel completely comfortable. Zope offered a very stark choice between developing through the web based interface (DTML methods, etc.) and writing raw Python. To do really useful stuff, you had to get into the Python side of things, but also learn a lot about Zope guts that wasn't really well documented.

I spent more time than I probably should have had to reading Zope's own source code in order to figure out how things worked. Fine, for my own silly little projects, but not practical in general. It was hard to get the overall view of a project, and hard to test. The learning curve was a little too steep, I suppose.

So, once I'd got to a certain point I stopped, and looked around for a platform that gave me more code visibility and testability. Loyal readers will know I've looked at ASP.NET and Python, Quixote and Cheetah. ASP.NET I rejected because I didn't view Mono's web application server as mature enough at the time, and I also had reservations about ASP.NET's non-free baggage. Python, Quixote and Cheetah looked a lot more friendly.

What I wrote about Quixote and Cheetah at the time was "this combination isn't adequately presented and described anywhere." These were good technologies, but not integrated as a framework. I started work on integrating them, and made some interesting progress. I was correct that Python lacked a solid modern framework, and the time was certainly right for it, as we can now see by the emergence of Django and TurboGears.

However, at the same time I started looking at Rails and found out that it did pretty much what I wanted. To be honest, I'd avoided it for a while as a friend once did me the disservice of calling Ruby a cross between Python and Perl. "Why ruin Python?", I thought. And it takes me a while to get over the hype barrier before I conclude that there's a "there" there.

Now I've been using Rails for a while, I find its attractions have changed for me. The thrill of not having to write basic functionality over and over again has given way to more select pleasures. Writing in Ruby itself is a rewarding experience, as its idioms become plainer over time.

Sure, you can write Java or Perl in any language, and that's where I started off. But the subtle elegance of the Ruby idiom is a slowly appreciated and highly satisfying flavour. For developers who consider themselves as poets and artists too, I can't think of a better language.

Join the conversation about this post

Rails, Bazaar and SwitchTower

Edd Dumbill — 2006-01-19T12:00:18Z

I have just submitted an enhancement to SwitchTower to let you use Bazaar as a source control system.

SwitchTower is a deployment framework for Ruby on Rails applications, allowing fine-grained control over deployment of Rails applications to one or many servers.

My contributed module lets people who use Bazaar join in the fun. Until such time as my patch is approved, save it in the app/switchtower/scm directory of your Rails app. The module assumes that the Rails application is in the root of your tree.

In your SwitchTower deploy.rb file, add:

set :repository, "you@example.com--archive/whatever--trunk--1.0"
set :scm, :baz
set :checkout, "export"

The "export" setting can be omitted if you really want baz to check out all the {arch} directories full of version control junk onto your live servers.

Note that the repository follows a specific version. If you branch your deployed version, you'll need to change the repository to the new version.

Join the conversation about this post

A clean sweep

Edd Dumbill — 2006-01-15T13:33:57Z

Firstly, if you haven't the faintest interest in the software I use to write this weblog, please feel free to go and do something more interesting right now.

Now I'm in the company of dedicated readers of colophons, I will proceed.

Redesign and reimplementation

This weblog, which has now been running for over two and a half years, originally ran on some custom software I'd hacked up in Zope: at that time my web development platform of choice.

Today, I've relaunched with another custom content management engine, this time written using Rails. It's been a lot of fun to write, and a good excuse to sharpen my Rails skills further.

The design has also been fun. It's a little basic right now, but I hope easy to read. Of course, the font is Lucida Grande, which ensures that I am fully Web 2.0 compliant.

The main new feature is that the tags I give articles are now made public. I used to tag posts for my RSS feed, but not publish them on the site. Now they are public--what few tags I currently have--and it's possible to find RSS and Atom feeds just for certain subsections of my writing.

I worry sometimes about spamming the various Planet aggregator sites my blog features in, so this gives me a way to direct content specifically at them. That said, at least for Planet XML I like hearing about everything the community members have to say, not just their on-topic posts.

New URLs

My blog now has a new location, http://times.usefulinc.com/, and new places for RSS and Atom feeds:

Tools used

Emacs
Ruby on Rails
Firefox
GIMP
Bazaar
TinyMCE

Join the conversation about this post

On Rails, conferences and execution

Edd Dumbill — 2005-08-21T12:32:29Z

Another collection of bits from this month.

Like everybody and their aunt, I've been working with Ruby on Rails for the last few months. It's been fun, and there's lots to learn. One snippet learned along the way was to avoid MySQL ENUMs, which meant some re-engineering of a legacy table. There's also trouble where tables don't have integer primary keys.

A new deployment toolkit for Rails has been released, SwitchTower, which I intend to test out soon. One of the impressive things about Rails compared to my previous PHP or Zope based solutions is the recognition of the different production and development needs.

I've been doing more work on BlueZ in Debian. The latest 2.19 release of the bluetooth tools is now available. Meanwhile, Bastien Nocera has pushed another release of GNOME Bluetooth--his help and involvement in the project has really rescued it from my lack of free time. We hope to push the web site and releases all over onto gnome.org soon. I plan to finally come through on my promise to get GNOME Bluetooth into Debian.

The conference carousel continues to whirl. OSCON was good, but I'm exhausted with west coast US travel right now. In addition to being photographed and finger-printed on the way in to the US, I had to be photographed and finger-printed on the way out as well. Add to that a special TSA scan, and it made the 24-hour door-to-door journey even more weary. I've many friends in the US, and always enjoy my time there, but each time I go it gets a little more inconvenient.

EuroOSCON, this October in Amsterdam, is a lot nearer. I'm a bit last-minute on this (despite being part of the program committee), but I'm attempting to get a repeat of the Mono tutorial from OSCON going here.

Transatlantic travel woes nonwithstanding, I'm planning on heading to XML 2005, for which the schedule has just been published. I'm also looking at the ETech 2006 call for participation. I know I've got things of interest to talk about at ETech, I'm just struggling to sort them out into a coherent proposal. I really want to talk somehow about desktop Linux, linked in to all the other current topics in the call for proposal (productivity, web 2.0, user interfaces). Especially within the corporation and the developing world, desktop Linux has the potential to act as a huge magnifier on new ideas of productivity and UI.

Talking of magnifiers, I loved this succinct explanation on the relationship between ideas and execution in a successful enterprise. Execution is worth millions. That's why alpha geeks rarely make it rich: we're always moving on to the next big idea. Right now I'm in an "execution" phase, working at a company I co-founded in 1998. Part of the reason for making the move was a recognition that as a writer I never got to do the execution phase. Now I can tell you, execution is the difficult bit.

I'm hearing an increasing amount about identity, always a topic that's burbled on in the background ever since Microsoft's Passport program (ah, what cruel overtones the name carries in the light of today's current travel security woes). Now I see that Mozilla's Mike Shaver is working on identity. I'll have to start following the debate a little more closely now, after dabbling around the edges of it with FOAF and PGP.

Finally, some Ubuntu notes. I've installed Breezy, the current unstable release, onto my main development PC and it's playing pretty nicely so far. Highlights include Evolution running faster with my IMAP, and the Beagle search tool. Annoyingly, the Rails-related Ruby in Ubuntu bug is still an issue--I suspect the news that people run scripting languages other than Python is still a shock to some folk. While Breezy will fix this, it's a shame that no backport is yet available for Hoary.

It would be good for Linux in general to get this sorted: Ubuntu is starting to have an OS X-like role in moving people over to Unix-like systems, and to have it run hot ticket packages like Rails flawlessly is a good way to get people into Linux.

Join the conversation about this post

Edd Dumbill's Weblog: 'rails' articles

RailsConf, remotely

Telling stories with RSpec

RSpec Story Framework

Further reading

Edd 10.5 release notes

Expectnation

Conferences

Writing

Collecting minimal user information

One size doesn't fit all

Our solution: progressive disclosure

Implementation concerns

Making it look easy

Jeni Tennison on women in computing

An argument of femininity

Self-efficacy

Why Bazaar rocks, and the highs and lows of its use with Rails

Using Bazaar with Rails and other tools

The good

The bad

Really really getting the testing religion

Continuous testing

Coverage reports

Tainting strings

A deployment pattern for Rails and bzr

Rails deployment tip for Debian systems and Apache

Load-balancing Mongrel with Apache 2.0

Illustrated Rails, smart folks and publication

Edd on Rails

Give me books, twice

Catching up

XTech schedule coming soon

Number crunching

Places I'll be: Carson Summit, XTech, RailsConf

Why Rails?

Rails, Bazaar and SwitchTower

A clean sweep

On Rails, conferences and execution