A Fresh Cup

Just a tiny bit of flotsam for today.

• 15 TDD steps to create a Rails application – How to get off on the right foot. There were many of us at RailsConf sheepishly admitting that we don’t always do TDD; this is one of the Rails core values that has not successfully stuck as the community has gone through its explosive growth phase. (via Ruby Inside)
• The Rails Community Cares – Charitable donations from RailsConf topped out around $33,000, or twenty bucks per attendee on the average. That’s not so shabby.

Back home and recovering.

• Report on Self-Serve Trip Scheduling Experiment – Jeff Barr’s successful use of a wiki to set his own meeting schedule while on the road makes me wonder whether the same principle can somehow be leveraged in a consulting business. I need to ponder this.
• Ruby on Rails meets the business world – New Google group following up on a successful panel at RailsConf.
• Bloated RailsConf Presentation Downloader – For those who would rather run code than click on links.
• Hi – I’m Ruby on Rails, Part 4 – This is the one that was previewed at the RailsConf closing keynote.
• A tool for creating Sculpted Prims easily – I expect I’ll be wanting this when sculpties make it on to the main grid in Second Life.

The day started out with the world premiere of the last of the Rails vs. PHP videos from the RailsEnvy guys. This was warmly received, as you might expect.

From there, we rolled right into Jamis Buck and Michael Koziarski from the Rails core team discussing The Rails Way . This was one of the best-loved keynotes of the whole conference, because they threw a bunch of code up on the screen; people were definitely hungry for more code in the presentations (a piece of feedback which I am sure the conference organizers have heard by now). A few of the points they raised:

• A model does not need to equate to an actual database table

• DRY is useful “but if the fix is worse than the original disease, don’t do it!”

• After you declare associations in your models, you should actually use them

• Take advantage of the helper methods in ActiveSupport to make your code’s intent clear

• Don’t cargo cult.

They held a Q&A session at the end of the keynote via IRC. This was only moderately successful; as with the other conference IRC channels, there was a lot of pointless chatter going on. (I dipped into the main IRC channel a few times, and found it pretty much impossible to extract any value from it).

For my first session of the day, I elected to watch Britt Selvitelle and Alex Payne talk about “Scaling Twitter”. This opened with Alex explaining the now-infamous interview; he maintains that he did not say that scaling on Rails is hard. Twitter was just a tiny project until SxSW and the follow-up media interest, at which point it took off.

Scaling has so far consisted mainly of throwing more boxes at the thing; they still just use a single database (with master-slave replication to a separate reporting database). Currently, Twitter is spread across 32 cores: 19 cores for Mongrel (120ish Mongrel instances), message processing and delivery across 16 cores, jabber across 2 cores, and MySQL on one big 8 core box. They’re using 16GB or so for memcache.

Other Twitter statistics:

• 200-300 connections per second

• Spiking 800 connections per second

• Has been as high as 11,000 connections per second

• MySQL has spiked to 2400 queries per second

• API traffic is 20x web traffic, so Alexa underestimates by at least this factor

Caching is their biggest optimization. Memcache is their friend, and they do a bunch of event-driven cache invalidation (if Bob is a friend of Alice and Bob twitters, then Alice’s friends timeline is invalid). They also denormalize the database as necessary. Another big help is Starling, a pure Ruby distributed queuing system that they wrote (and will probably open-source in the future).

Contrary to some reports on the Web, they’ve looked at ETags and it wouldn’t be a huge optimization for them – they’ve actually had valid ETags in the past. HTTP delivery is not their big issue.

Another big help in scaling: the Rails community. “Act like it’s a business plan. Get a board of advisors for your scaling plan, is our advice.”

From there, I wandered over to hear Amy Hoy’s talk “Rubber, Meet Road” about how developers and designers can work together. This was fun because Amy is an entertaining speaker, though I’m not sure how much I got out of it – I don’t so much understand this fear that many developers seem to have of designers. A lot of the talk boiled down to reminding everyone that both fields are perfectly valid, and things will move along much better if we all collaborate instead of fighting. But people seemed to get a lot out of it, which was cool.

Amy did tie Rails back into the talk by looking at how you can get designers (with an HTML/CSS background) involved in actually working with Rails applications. As such things go, Rails is fairly friendly (though “all templating languages make things worse”). Developers can help by making it friendlier:

• Write the Ruby code for the designers

• Create cheat sheets explaining the key uses of ActiveRecord and ERb in your own project

• Write helper methods to hide the much

• Lots of comments

• And don’t forget to teach them about Subversion

I found another table full of random folks to have lunch with (I tried to mix as much as possible during meals; networking is a large part of why I paid for this conference), and we had a wide-ranging discussion of everything from how to retread from Access to Rails, to search plugins, to open source. One of the topics that came up was what Microsoft is doing with Ruby on the DLR. Now, Scott Hanselman may have found interest in Microsoft spinning off the DLR code and developers to a separate non-profit organization, but all I can say is that he was talking to a different set of conference attendees than I was (I suspect Scott spent more time with the ThoughtWorkers and other enterprisey folks). I raised the question of the DLR in half a dozen groups, and the opinion was pretty well unanimous: no one trusted Microsoft in the least to keep their Ruby implementation pure, no one thought that it would be a safe component to depend on, and no one would even consider using it in a future application. The spectre of “embrace and extend (and extinguish)” still lives on.

I skipped one session and hung out and caught up on e-mail for a bit, and then caught the closing keynote with Dave Thomas. Dave started out with a satirical screenshot of rubymiddleagedwhiteguys.com (there had been some trouble with rubychicks.com during the conference) and went on to make the pitch that “I would like Rails to set the standard for the integration of people into the community.” I don’t have the energy for a long analysis of this stuff right now, but it’s good to see that the Rails community is at least at the point where community leaders are recognizing that diversity and openness are useful core values, although there are some community dynamics that are still keeping the Rails community overwhelmingly white, male, young, and closed.

The next topic was the charitable donations drive that was spearheaded by the Pragmatic Programmers. As of the start of the keynote, about $26,000 had come in – which wasn’t really an astounding amount for 1600 people, but not bad for 1600 people many of whom, I suspect, had never donated to anything. Dave suggested to other organizers that they keep the beg-a-thon up at future conferences: “Why don’t we make this the standard for all technical conferences to show that the industry cares?”

The meat of the keynote started off with a discussion of the exponential growth of Rails and the number of Rails developers. Dave argues that we need to start putting in place mechanisms to allow people to learn better and to have conversations: better documentations, more blogs, help sites, who knows what else. The key question is how are we going to help new people join us?

Also, as the effort involved in launching a web application drops, more and more web applications become possible, and more and more people can launch them. We need to welcome in people who are not hardcore programmers. But this also means we get a whole new pool of people to play with: designers, writers, people with cool new ideas whoever they may be. We need to try to be an inclusive crowd, not an insular and geeky crowd.

From here, Dave moved into a discussion of cargo cult programming. He made a pitch that we’re all doing it right now – broadly defined as doing things just because we’ve seen them work before. “There is no difference between the browser and the 3270 except that the browser can display better porn” (both are basically half-duplex devices). He urged the crowd to think beyond their habitual ways of doing things and to experiment.

Next rant: object-oriented programming. It’s called object-oriented not *class-oriented” but we spend all of our time modeling the world with hierarchies of classes. But the world is chaotic, there are almost no inheritance hierarchies in nature. He sees the way we’re using objects and classes as another cargo cult.

The bottom line: Don’t just receive knowledge. (Of course, this is what all prophets say when they tire of being prophets. It rarely works. It’s hard to get out of the business of being a prophet).

Dave ended, as one would expect of a closing keynote, with a challenge: “Go away from here, have fun, and do some good.”

The conference wrapped with a closing reception with food and more chitchat. I ended up in a discussion of the Rails community (I suspect our little group was not the only one on that topic). My bet is that this RailsConf will be the last time that the majority of the Rails community ever gets together in one place – by next year, there will be too many developers working in this space for a single conference to accommodate them. So I suspect we’re inevitably going to see fragmentation, not the sort of inclusivity that Dave Thomas was hoping for. Time will tell, though.

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

• Keep them well facotred

• Document them

• Test them

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).

One of the things that DHH announced as a feature for Rails 2.0 in yesterday’s keynote was “breakpoints are back.” Given that I’m still at the stage in my Rails journey where my applications tend to spit out large stack traces at a moment’s notice, this was definitely of interest to me. So I took a few minutes today to find out how easy it was to do this with the current cutting-edge bits. The answer turns out to be, pretty easy. If you want to poke at this stuff today, here’s what you need to do.

1. Get on to Edge Rails (anything more recent than Changeset 6611 will do).

2. Install the ruby-debug gem:

sudo gem install ruby-debug

3. Build your Rails application (this step left as an exercise for the reader).

4. Start up your development server with

ruby script/server --debugger

If you haven’t looked at Edge lately, this now starts Mongrel by default instead of WEBrick.

5. Anywhere in your source where you want to fall out into irb, insert the single line of code

debugger

6. Browse to a page that will hit the debugger statement and then flip over to the terminal window where you started the server. You’ll be sitting at an irb prompt. You can evaluate expressions, inspect and change objects, and so on. Type cont to continue on with execution.

7. ruby-debug supports a bunch of other commands. To drop from irb into the debugger proper, type Ctrl-d. Type help to see the command list. Type irb to return to irb (and then cont to go on with your application’s business).

Today was the real start of RailsConf 2007, and of course it started with the keynotes. Program chair Chad Fowler was up first, warming everyone up by playing to the crowd. He pointed out that the wider world perceived Rails folks as arrogant bastards. People actually loved this; it’s how they want to be perceived, apparently.

Next came the main event: David Heinemeier Hansson talking about Rails 2.0. It looks like Rails 2.0 is going to be like current edge Rails, only more so – indeed, he remarked that 95% of what he was showing today was already in edge (and indeed, I’d already played with much of it, which gave me a warm feeling; I may not be as far behind the curve as I thought). Resource orientation is going to be the default way of building applications in 2.0; no surprise there. Action Web Service is being moved out of the default Rails install, though it will remain available as a plugin: “Rails is not Switzerland – Rails has an opinion.”

He also listed nine other things to like about Rails 2.0:

1. Breakpoints are back (via integration of ruby-debugger). I need to dig into this; being able to drop into a fully interactive debugger [take that, VB] by putting a single line of code in the source would be of great use to new people trying to learn this increasingly complex framework.

2. HTTP Performance. Multiple JavaScript and CSS files can be automatically consolidated into gzipped master files and served from asset hosts, along with other assets like images, making best use of multiple connections.

3. Query cache. This is a SQL cache in the Rails layer. Results will return from cache if it doesn’t see INSERT/UPDATE/DELETE activity since the previous identical SELECT statement. This clearly has some problems if you’re distributing your application across multiple servers, so presumably you can turn it off somehow.

4. action.mimetype.renderer – A new convention for splitting up URLs so that now you have people/index.html.erb, people/index.rss.erb, people/index.atom.builder and so on. The format and renderer are deducible from the URL.

5. config/initializers – Pull stuff out of config/environment.rb and put it in multiple files in config/initializers directory. So, it’s a way to organize the complexity, but the complexity is still there.

6. Sexy migrations – A simpler syntax for migrations which is already in edge

7. HTTP Authentication – Built in support for HTTP basic authentication with calls like authenticate_or_request_with_http_basic. This is good for APIs, not so good for user-oriented stuff.

8. The MIT assumption – Creating a new plugin with the generator now assumes the MIT license and generates one for you (because that’s what DHH prefers)

9. Spring cleaning – A lot of the deprecated stuff in 1.2 is going to move to plugins.

After a break, I ended up in “Building Community Applications with Rails”. This wasn’t the session I’d been planning on, but the conference organizers hadn’t made any attempt to put more popular sessions in larger rooms and some sessions were full past bursting. It seems like they could have used the data from “MyConfPlan”http://www.myconfplan.com/conferences/RailsConf2007 as a statistically valid sample for planning, although by midday MyConfPlan appeared to be permanently crashed anyway. This session was basically a “lessons learned” from Dan Benjamin, one of the the guys behind cork’d, and it was mostly pretty obvious advice without Rails-specific content.

The computer of choice at this conference is overwhelmingly the Mac Book Pro – 95%, maybe. Many people are struggling with an apparently cranky wifi network; you can tell the ones with EVDO service because we’re just happily online.

In the next session slot I caught Scott Raymond’s “Doing REST Right”. He spent a lot of time talking about the underpinnings of REST, starting with Roy Fielding’s work, which was clearly not what the crowd was there for. Data point: about 30% of the crowd had built some amount of a REST application in Rails. Scott covered a number of the common questions people have as they’re moving into REST (what about transactions, concurrency, reliability), but again, it didn’t tie back to Rails. Talking to a few people after the session I got the impression that folks would have rather had a session that drilled more specifically into the REST support in edge Rails. This seems to be a pretty hands-on crowd, as well as one that is skewed towards people on their first, or first few, Rails applications.

The lunch break was marked by the same box crap food as yesterday. It’s a good thing I don’t come to conferences for the food. They’ve got quantity more than covered, but quality is fairly dismal.

After lunch I sat in on Ben Scofield’s “Building and Working with Static Sites in Ruby on Rails” session. The basic problem his company was dealing with was handling sites with a lot of static pages (hundreds). For just a few static pages, there’s no problem: you can use the obvious approaches of an action and a view for each page, or actionless views (put a file in the views folder, and the default route will serve it up fine in the controller’s layout).

For more complex sites, Ben moved through four solutions, which really amounted to four refinements of the solution that Viget developed as they moved from being a PHP shop to being a Rails shop. All depend on using a catch-all route similar to

map.connect "static/*path", :controller => "pages", :action => "show" 

And then putting the pieces back together in the show method

def show
  page_path = params[:path].join("/")
  if file exists ...

They gradually ended up with a Page model, a Variables model, and a Redirects model (Page has_many Variables, has_many Redirects), with all of the information filled in from database tables and the page content stored in the database as well so that it can be set up in the site search with ferret or solr or whatever.

Their solution has been packed up for reuse as a plugin application at http://www.viget.com/railsconf/ though he cautions that it’s still alpha code.

For my last session of the day, I decided to sample one from the “products and services” track – CodeGear’s Joe McGlynn speaking on “Ten Cool Things I Learned on the Path to Rails Enlightenment”. He spent about twenty minutes talking about ways that we grow up in our careers as software engineers, and I fear this was pretty much a throwaway; if you’ve read any of the literature from Fred Brooks on forward, you’ve seen this sort of thing before. Then he moved into the expected pitch for the new CodeGear Rails IDE. He invited all conference attendees to join the beta though after I looked at the amount of info they wanted to collect, I lost interest (apparently no one from CodeGear attended Dan Benjamin’s talk on making signups easy). The demo itself was pretty bad; when neither the product nor the speaker was compelling after ten minutes, I walked out, and I was far from the only one.

There wasn’t anything I wanted to catch in the last afternoon slot, so I took off for a bit, caught up on the web, and had some dinner. Then I came back for the evening keynotes. Evening keynotes strike me as a bizarre sort of thing, but I’ll play along.

First up was Steven Smith from FiveRuns with “Enterprise is not a Four Letter Word”. He spent time putting out facts and figures to prove that people love us, the press love us, and the enterprise market is huge, and ended up with a Monty Python clip with bad sound. Though the Python and the ragging on ASP.NET got a rise out of the crowd, I didn’t really find much content in this talk. Yeah, the enterprise market is huge and lots of people have download Rails, but what’s the connection between those two dots? I’ve chatted with half a dozen folks from actual enterprise-level shops at the conference, and they’re here because they’re interested to see what Rails can do, but they’re all pretty clear that it’s not even close to moving into their critical systems yet.

Next up was Avi Bryant with “Future History: Ruby at 30 Years”, which was probably the best talk of the day. He purported to be talking about a version of Ruby from 2025 that included a number of interesting features:

• A fast JIT-compiled Ruby VM
• Multiple commercial Ruby vendors
• A best in class IDE written in Ruby
• Standard Library entirely in Ruby
• Major financial/Enterprise use
• Massively scalability

Then he dropped the other shoe: he wasn’t talking about Ruby 2025, but about Smalltalk now, but “Ruby and Smalltalk are the same language” – similar syntax, similar concepts. If you buy into that premise, you can use the current state of Smalltalk to see the future of Ruby. For example, Smalltalk’s current state disproves the notion that there’s something about Ruby’s feature set that makes it inherently slow. (Of course, Avi didn’t mention that by the same analogy, in 30 years Ruby will be a marginalized language that most people don’t take seriously, kept alive by a small core of dedicated and occasionally shrill practitioners).

This idea didn’t go over all that well with the crowd, though things picked up a bit when Avi finished his slides early and moved into “presentation by committee,” taking questions and suggestions from the audience. It was clear that most people in the hall didn’t know much about Smalltalk, and most who did know didn’t think this would be a good path for Ruby, but there was some good back-and-forth.

The evening was capped by Ze Frank, who did some of his standard standup routines . This had nothing to do with Ruby or Rails, but the audience pretty much didn’t care. As for me, it was a “get off my lawn” moment; I could have gotten back to the hotel earlier and watched Leno if I’d wanted standup, which I didn’t particularly.

Thursday was somewhat the start of RailsConf 2007 – a day of tutorial sessions, for which one had to pay extra, so there were only a few hundred attendees (plus of course speakers, staff, and exhibitors) in the place. Since I’m attending for two reasons (to learn and to network), I sprung for the tutorials.

The day started off with a pastries-and-coffee conference style breakfast, that I’d rate about a 3 on a scale of 1 to 10. Oh well, I don’t go to these things for the food. I chatted through breakfast with a Portland native whose name I forget (I am, as you will no doubt see over coming days, terrible with names) about the prepress business and about being an older retread in an IT business. It’s a young crowd here this week; the average age is certainly under 30, putting me dangerously close to the “get off my lawn” part of the demographic. I heard someone claim 10% female attendees, but I wouldn’t put it that high from looking around; perhaps 5%.

For the morning, I attended “Is JavaScript Overrated? Or: How I Stopped Worrying and Put Prototype and script.aculo.us to Full Use” led by Thomas Fuchs. As Thomas is the author of the script.aculo.us library, it’s hardly surprising that his answer to the title question was “no”. I did learn quite a lot in this one, both about how to use the libraries in question and about how to work more effectively with FireBug. It was also nice to see the new features of the edge version demonstrated. Twitter-contact Sean O’Steen and I also tracked each other down during this session via Twitter messages and chatted a bit in the break.

Lunchtime was spent at a table with the one and only Scott Hanselman, who had a machine sent down by Microsoft’s John Lam with some of the latest DLR bits. Scott showed off crazy multiple dynamic language interop scenarios and we otherwise shot the breeze about random nonsense in the programming world.

In the afternoon, I started off in David Black’s session “Rails Routing Roundup.” This one, alas, proved to be far too basic for me – by the break he hadn’t even covered as much as I’d sussed out in my one and only article on the subject. Scott Hanselman was next to me and we bailed out at breaktime to troll the convention hall in search of interesting conversation. This led to some time listening to Ward Cunningham worry about upcoming issues in decimal rounding, as well as various Rails stuff.

After a while Scott headed out to beat the traffic and I took off back for the hotel. I ran into someone who tipped me to the existence of the Joyent party and spent an hour or so in their suite chatting with random folks, until the beer ran out and the party evaporated; consider this a failure of functional test for party planning. And that was the end of RailsConf stuff for the day for me.

Those attending RailsConf can now plan their detailed schedule with the nifty MyConfPlan . If you’re bored enough you can even look at my own plans .

• Simplist 2 For Public Consumption – Rails-based CMS.
• Capistrano 2.0 Preview 1 – The next version of Capistrano is coming. It even has its own web site now.