RailsConf 2008 is over and I’ve had some time to rest and recollect my thoughts on the sessions. Below is a quick summary of the main ideas I picked up in each session.

Friday 5/30/2008 (Day 1)

• Joel Spolsky keynote – The UI should help the user.
• Entrepreneurs on Rails – Work will always come in feast or famine cycles. It’s how you learn to deal with it that will determine your success.
• Hosting and the Woes – Caching is the key. Modern servers are powerful enough to handle a large load with some basic optimization and common sense.
• Faster better ORM with DataMapper – DataMapper shows that the Rails way is not the only way, we have the freedom to choose what tool will work best.
• The Profitable Programmer – You only have to spend one day a week to work on your idea. That’s how Peepcode was started.
• Microapps for Fun and Profit – Take a day off and build an application. Nothing is better for a developer than to create something new and show it off to the world.

Saturday 5/31/2008 (Day 2)

• Jeremy Kemper Keynote – Rails is improving at an impressive rate with the community support.
• Using Git to Manage and Deploy Rails Apps – Git is flexible and stupid simple once you get the underlying concepts. I’ve seen wikis and backup systems using git as the file storage.
• Advanced RESTful Rails – Sometimes the relationship between data should be the resource, not just the data itself.
• Lightning Talks – Didn’t really get much from the Lightning talks.
• Integration Testing with RSpec’s Story Runner – Doing full stack testing is really useful to check the interactions between discrete components but it isn’t easy or maintainable.
• Meta-programming and Ruby Internals for Rails Programmers – A deep understanding of your runtime environment will make you a better programmer.

Sunday 6/1/2008 (Day 3)

• “Design Patterns” in Ruby – Many of the “Design Patterns” in other languages can be trivially implemented using Ruby’s built in language constructs.
• Advanced Mongrel: Handlers and Plugins – Since Mongrel is written in Ruby, it can be easily extended using Ruby. This is an easy way to bypass the Rails stack.
• Oh the Fail I’ve Known – Failure is the best teacher so we all need to hurry up and fail our first 50 times.
• Building an App in 48 Hours, A Rails Rumble Case Study – 48 hours is a long crunch time and near the end many bad mistakes are made, predominately around testing.
• Rails Core Panel – Releasing Rails is taking longer to because testers are waiting for a release but the core needs edge tested more before hand.

I’ll be digging into a few of these topics over time. I’m looking to do some more with Microapps, Git, and meta-programming.

Eric