Windy City Rails Part One

This weekend was the first ever Windy City Rails Conference and I was lucky enough to not only attend but also to speak. I thought I'd sum up the talks I attended in case anyone was interested.

After Ray Hightower, lead organizer of the conference, welcomed everyone Ryan Platte gave the first talk of the day: "Outside the sweet spot"

Ryan's talk was about getting Ruby and or Rails into a large organization which is committed to things like: Windows, Oracle, etc. I.E. not the typical Rails stack.

In Ryan's experience, Rails makes it's way into such an organization the following way: Some guy picks up a Rails book and says "Hey, this is way better than the excel spreadsheet we've been using." Then he talks one boss into the project, and maybe they hire some consultants to help. However the rest of the organization has issues with Rails (it's slow, not compatible with their stack).

Ryan's advice is:
  • Do top quality work quickly -- get out in front of criticism by having good early results
  • Communication -- talk to everyone
  • Model, model, model -- Spend some time on the soul of your application
  • Get to know the legacy tech and why it's there. Find out what will the people who wrote it feel about the changes? What will they hate. And what will they like. Get those arguments ready.
  • Use rest - it looks cool to the technical users

Warnings:
  • There's a temptation to add all the cool whiz-bang stuff Rails can do/is known for. Throwing in the kitchen sink is a good way to doom your project.
  • DBA's talk in SQL and will often times will refuse to run Ruby migrations.
  • While JRuby is cool - testing Ruby with object dependent on Java Objects means you'll have to test in JRuby and spinning up the jvm is slow.

Up next was Rails Q&A with David Heinemeier Hansson

This first question was about performance in Rails. David said this has been a big effort for 37 signals over the last few months and his advice is to optimize http first: gzip, minify js (use yslow to find problems. There's a google presentation about it you should see). There's a common problem with devs, they think about code speed first. 80% of rendering time of a page is http stuff. Code is only 20%. They are working on putting these into Rails. Ex: timestamping of assets (gotta set up your server to use this).

David said that a 200 millisecond response is the sweet spot for the user to feel like your web app is fast.

He talked a bit about Rails 2.2 thread safety -- good if you use JRuby or 1.9 (David thinks thread safety is optimizing the 20%)
I asked David whether Rails will be implementing any features from Ruby 1.9 that will force people to upgrade to a new Ruby. He said that there are absolutely no plans to abandon 1.8 support. There has been an effort to get Rails to run on 1.9 which is near completion. As for the speed boost of 1.9 (and YARV) he's only seen a 20% speed improvement in real world Rails examples.

David wants to pull out validations into their own thing (and you can add them into your own models) and he spent a little time talking about that.

There was a question about observers and David said the he thinks they are kinda are old to him as he uses now uses memcached so he's ripping out all his observers from his code. Expiring caches is a very hard problem and he really digs how memcached makes things easier.

Dave Hoover asked what David would have done differently if he had the last 4 years to do over again. David said he's not real big on regrets. He went on to say that if you had tried to do all the things you now know you would have to do, you never would have started. It would be too daunting. When he started Rails it was a 1000 or lines of code. Very doable. David is not a big fan of retrospectives.

Internationalization was like the 3rd feature requested ever. And it's a very hard problem. So they thought about it for a few years and let the people who really care about it sort it out. The Rails core team didn't much care about internationalization and they weren't experts. In this case the committee actually worked.

Asked about what he was excited about, David talked about memchached, http (the creators showed lots of foresight), and document databases (couch db and it's ilk)

David said that people often make the mistake of thinking that 2000 users is hard and so is 1 million so why not go for 1 million. They don't get that the scale of hardness is way different for 1 million. Basecamp was out for a year before it could even pay people's salaries. You win by staying in the game. Many companies self destruct trying to get too big too fast.


Then it was time for Dave Hoover's (of Obtiva) lightning talk. He admitted he was stealing from Uncle Bob's 2008 Agile keynote as he talked about software craftsmanship. Which was weird as I was sitting next to Micah Martin -- Uncle Bob's son. Dave cited the analogy of doctors washing their hands vs getting started on surgery. There was a time when hand washing was viewed as a needless use of time for a busy doctor. And we face the same problems as developers: Deliver features vs refactor/write clean code. Obtiva is trying to be about craftsmanship.

Well, that's all I feel like typing tonight. I'll wrap up the rest of the presentations tomorrow.

Comments

Bradly Feeley said…
Nice write up. I hadn't heard about making validations separate from the model. I wonder what this would look like.

Popular posts from this blog

Point Inside a Polygon in Ruby

What's a Good Flog Score?

SICP Wasn’t Written for You