I was fortunate enough to attend Rails Conf 2006, held between 6/23 and 6/25 in Chicago. I also participated in RailsDay 2006 on June 17th.
I’ve had a very edifying few weeks. I’m going to take a few minutes and enumerate (get it?) some of the bigger lessons learned:
- Know your problem domain.
This has to be my biggest stumbling block. I’m all about going into development, guns blazing and worry about the big picture later. This is a mistake in the Rails’ world of convention over configuration. If you take some time in the beginning to figure out what models you’re going to need and how they interact with each other, you’ll be much much better off.
- Put as much functionality into your models as you can.
Models are for your Business Logic. That concept escaped me until RailsDay (and even more so at RailsConf). In simple terms, you should be able to interact with your application from
script/consoleand still have it follow the rules for your specific area.
- Let Rails do it’s thing and get out your way.
This one was more from Martin Fowler’s keynote then anything. What Rails gives you is the ability to not worry so much about the “plumbing” of your app, and focus on what makes your problem domain interesting and unique.
- Don’t worry about the Rails Way, just get it out there and itterate!
I heard more then once, “But I want to know the Rails Way of doing it”. I’ve felt that MANY times, and I’m giving up. This is the worst kind of analysis paralysis. Just get it out there so you can work on something real and formed.
- Testing isn’t scary!
This was HUGE for me. I never tested because I thought it was hard and scary. During my RailsDay project (My one goal), I decided to just go for it with testing. You know what I found? It’s EASY. That plus Mike Clark’s Panel really taught me not only the ease of testing, but the utility. Here’s a side story, I just moved my app from Text Drive to my local server. It wasn’t working at all, so I decided to give my out of date tests a run (I gave up TDD at about 7pm on RailsDay), a LOT of them failed. It took some time to get them running, but now it works better. And each bug report that goes in gets a test case before it’s fixed.
- Everything is CRUD
This was a big part of DHH’s keynote. It was hotly debated afterwards, but regardless, it’s an interesting way to look at how you set up your application. The gist is this: most of your controllers should JUST do CRUD, and if you think that a controller can’t (like a login), maybe it can. And by reframing your problem in this way, problems just go away some times. I haven’t been able to try this out yet, but I’m looking forward to it.
- Nobody does it right the first time
This goes back to point 4. Basecamp didn’t spring-forth fully formed. Scott Raymond is still tweaking the “done” iconbuffet. What amazes me is that not only do all these apps keep getting bug-fixes, but developers actively go back and make their code “prettier”, which brings me to my final point
- Beauty matters
When you craft your code (even if it’s not the first iteration of it) to be pleasing to you, not only are you more willing to go back and work on it, but you’re more likely to be able to bring someone new into the project. And you’ll feel better about the whole process.
- Shoulder Surfing is way underrated
I was able to watch Amy Hoy and Scott Raymond work “live”. Amy was working on a design comp (whom received it right there over irc – AGILE!). Scott was doing Rails work. I have to say that those two experiences were huge for me. I’d like to see a panel next year of just live coding with breaks for questions. Between learning editor shortcuts, Rails and Ruby idioms and how some people “flow”, I think more can be conveyed then any text, video or talk can. Watching someone do what they do live is a very wide band. So thanks to both of you!