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.