A couple of themes ran through a lot of discussions I had with other conference attendees today: that yesterday’s sessions were by and large too basic, and that it was really hard to tell in advance how technical any given session was going to be. I don’t know if the RailsConf organizers will ever run across this blog (I’m still a tiny fish in a rapidly-growing community), but here’s a summary of the suggestions that I heard over and over again:
- Split the conference into tracks, so that it would be clear which sessions were targeted at hardcore developers, designers, newcomers, or whatever (but don’t require people to stick to a particular track).
- Tag each session’s description with a level (100/200/300) indicating its planned depth.
- Use the data from MyConfPlan to intelligently plan room sizes. Some sessions should have been in double rooms, others could have been shoved down to the smaller rooms on level C.
Anyhow, on to the doings from Saturday…
I had breakfast with Brian Hogan and some of his cronies, discussing various issues and trying jointly to recover from the night before. Then it was off to the keynotes. First up was Cyndi Mitchell from ThoughtWorks Studios (the newly-created products division of ThoughtWorks) arguing that we should “Bring Ruby to the Enterprise, Not the Other Way ‘Round.” Her basic point was that “enterprise” used to mean “to boldly go where no one has gone before” and that the association with bloatware, incompetence, and corruption is the effect of big IT devaluing things. “We” (meaning Rails folks) need to reclaim the word. ThoughtWorks is already billing millions to banks, telecoms, and so on for mission critical systems in Rails; 40% of their new project revenue is now Rails projects in the enterprise. She uses this to argue that simplicity, elegance, power, and speed to delivery can be a selling point into smart enterprises.
Of course this segued into a product pitch, since ThoughtWorks is one of the big RailsConf sponsors. She announced RubyWorks , a Ruby production stack packaged to make it easy to install Rails applications into the enterprise, with 24×7 support for RubyWorks and JRuby coming in June. She also mentioned CruiseControl.rb and Mingle (agile project management built on Rails and JRuby) and promised that other developer tools and libraries would be coming from ThoughtWorks for the community.
Cyndi’s Bottom line: we are in a position to reclaim the enterprise with Ruby on Rails and at the same time to make a giant leap forward for our industry. The new approach from the Rails team and the Rails community is valuable to businesses and more businesses will be taking this up. This has created a gap in the market: businesses need tools and support. In a market-driven economy, gaps get filled; it’s up to us to fill this gap. If we don’t, the Bad Enterprise people will fill it. We need to be bold enough to bring Ruby and Rails to the enterprise.
Next up was Tim Bray, with a keynote that was part rambling, part talking about how Rails fits into wider topics of Web standards and the development ecosystem, and part Sun commercial (several people commented to me later that they thought there was too much Sun commercial, but hey, that’s his job). Tim started with a quick audience survey that split us up into about 40% startup folks, 40% corporate, and 20% independent. He also commented on the lack of women at RailsConf, though he didn’t dwell on this.
“Sun loves Ruby,” according to Tim. They’re employing half of the JRuby core team, and Matz is building the next generation Ruby on a donated Sun server (and donating servers to worthy open source projects is something Sun can do easily; send Tim some e-mail if you’re one). NetBeans is being retooled to be a good environment for Ruby development. No secret to why Sun is doing this: supporting programming communities ultimately helps Sun sell more stuff.
Tim then went into his theory of how to make money on free products:
1. Adoption – If someone will look at your product and adopt it, that gives you a chance to make money from it. This requires removing friction. The biggest piece of friction you can remove is money friction.
2. Deployment – The customer doesn’t see any business value until after the software is deployed.
3. Monetization at the point of value – (somehow) collect money at the point where a live system goes on the air and starts bringing in customer value. No serious system will deploy unless it is supported.
Therefore the path to success is to remove up-front friction, and sell support contracts.
Tim made a pitch that Rails could succeed in very large enterprises, beyond our wildest dreams, and asked, “What next?” The answer: Java, .NET, PHP will never go away. Heck, Cobol will never go away. New Cobol is still being written. The network is heterogeneous. Rails applicationss will need to coexist, essentially forever.
How do we get all these things talking to each other? Tim thinks the answer is REST, and he went on from this to make a pitch for ETags, and asked whether we can make Rails be smarter about computing ETags, and give hooks to developers for using ETags from application code.
He followed this with a discussion of the Atom Publishing Protocol as an example of how REST works: the goal is for everything to have a Publish button. Why can’t Rails have a plugin to handle both ends of this?
The alternative to REST is, of course, WS-*. Tim says pooh. (“delivering crap, and not much of it”). But you can’t ignore it, which is why Sun makes WSIT , which lets you talk to the WCF stack from Java or JRuby.
Wrapup: Tim asked the question: Which are the big developer issues that matter?
The conventional wisdom is that the major Web languages have their own areas of strength:
Java: compute performance, tooling
PHP: web scaling, ease of use
Rails, time to market, maintainability
Tim’s opinion: The two things that matter more than anything else are time to market and maintainability. Vast applause, everyone leaves the keynote happy.
The first morning session I attended was Glenn Vanderburg’s “Custom Rails Helpers: Keeping Your Views DRY”. This was a mid-level session that was just about perfect for me after a few months of poking at Rails with a stick. He started by reviewing the reasons why views are a problem in the average application (the mix of languages, and refactoring a mix is hard, plus the stuff you need to build helpers isn’t used anywhere else in Rails). He then moved through four types of helpers:
1. Simple HTML helpers
2. Generating JavaScript
3. Form Builders
4. Complex Helpers
Key points included
- Learn from the built-in Rails helpers
- Don’t mix languages if you don’t have to
From there, it was off to “The Business of Rails” panel. I expected this one to just be a light interlude for me – after all, I’ve been in business for myself for most of the last 15 years – and I got what I expected. Geoffrey Grosenbach was clearly the rockstar of the crowd, proving once again that having a personal brand is a big deal. Justin Gehtland pointed out the obvious, to applause: “None of us would be up here if it were not for Dave Thomas”. Just about everyone on the panel started out with the Rails screencast; I wonder if that’s still true for people entering Rails today? The biggest problem most of these guys were having was finding designers who will take rails seriously; Joe O’Brien: “If you find a designer, hide them.”
I spent my lunch break talking with folks from a few startups using Rails. Another thing I’m hearing over and over here is that startups, especially in hot areas like SF Bay, are finding it very hard to find Rails developers to hire.
Jarkko Laine’s “Angel on the Shoulder” session explored the question of how Rails encourages you to write good code. His answer fell into three parts:
1. Teach
2. Make doing the right things as easy as not doing them
3. If all else fails, trick people into doing the right things
There wasn’t a lot new here for me, but it was amusing to run across the concept of “syntactic vinegar”: being punished for doing the wrong thing by ending up with ugly code.
Rob Kaufman discussed importing and exporting big datasets in “Big Stinking Piles of Data”. A few of his key points:
1. Couple import and export – This is a good way to get testing, write export at same time as import, then you can test by round-tripping.
2. Use format samples. Easier to get agreement on samples than specs, you’ll need them for testing anyway.
3. Handshakes rule. Get confirmation of success or failure ASAP.
He also pointed out the obvious: if you’re using rake tasks to move data around, you should be testing the rake tasks too. He ran through a whole batch of tools, commenting on their bugs and working points: FasterCSV, net-sftp, net-ftp, open-uri, curb, gpgme. His proposed architecture for managing this sort of thing: import and export in the model, interface to partners in the controller, background tasks and file transfer in rake using curb and active resource.
I ended the day’s sessions by going to the “Open Mic Demo Session”, where a batch of folks got five minutes each to show off their stuff. I didn’t catch everyone’s name (sorry!) but I’ll link to what I can:
MasterView is a templating engine that lets you add directives to HTML and generate layouts, partials, and HTML helpers as a result.
YikeSite is a very simple content management system aimed at non profits and others who want to edit little bits of the page in the browser.
The guys from Revolution Health showed up Revolution Pages (codenamed “Fabric”), a personal page creation tool that allows all sorts of fancy editing in the browser. Watch the Revolution on Rails blog, where they’re releasing a batch of stuff back to the community.
Someone who’s name I didn’t catch showed off cnu_config, a custom configuration library that allowed multiple levels of overlaying and overriding in configuration files. This should be on RubyForge as a gem next week. (Apparently RubyForge is having issues just at the moment).
Someone else showed us just how easy it is to set up CruiseControl.rb – certainly way easier than the original CruiseControl or CruiseControl.net. So if you’ve been avoiding the Ruby variant because of bad past experiences, don’t.
Brian from JanRain , who wrote the OpenID library for Ruby, demonstrated Pibb , a group discussion tool based around OpenID. It looked pretty cool. You need an OpenID to participate.
Parker Thompson showed us Divine Caroline , one of their client sites (sorry, no porn). They had to write a plugin to do distributed page caching, which really helped out their performance. It will be on RubyForge soon, and they’re looking for help.
Someone showed off MyWaves , a platform that allows people to share, watch, and publish videos to mobile phones.
Fernand Galiana demonstrated the MOle plugin , which allows you to monitor what users are actually doing in your application. A single configuration file decorates everything you want to track, and then you can log to database, file, e-mail, Yahoo! gadget, or who knows what else. This was the crowd favorite of the day.
We wrapped with a developer from BountySource demonstrating statusfy, which lets you see real-time statistics on a map mashup via JavaScript inserted on your own site – essentially, instant TwitterVision. This was a crowd-pleaser too.
After the afternoon sessions, I headed out to a dinner for Microsoft retreads organized by Jeff Cohen from Softies on Rails . We ate a bunch of pizza and had an extensive discussion of the place of Microsoft in the Rails ecosystem, as well as sundry other topics.
Back at the convention center, I did catch one of the Birds of a Feather sessions – “Solo Rails Developers, Unite!” This ended up being one of the highlights of the day for me, as we exchanged a lot of good information on working as a solo practitioner, and made plans to ramp up a mailing list to stay in touch (e-mail me if this interests you).