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:

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

  2. 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/console and still have it follow the rules for your specific area.

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

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

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

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

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

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

  9. 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!

Average Rating: 4.5 out of 5 based on 288 user reviews.

One thought on “”

  1. To learn more about the obsession with beauty in code, I would recommend reading Steven Levy’s book _Hackers_. It’s not a technical book at all, but it describes in great detail the hacker’s mindset and the kind of amazing code squeezing that used to be necessary just to get things to work. We don’t currently work under the same restraints as they did back then (if it doesn’t fit in 24kb, we can’t ship it!) but we can learn a lot from their obsession with “bumming” a few LOC here and there.

    You should be proud of your code when it’s as short and it can be and still straightforward. It’s worth going over your code after you’ve gotten it working just to make sure you can’t tighten it up a bit; remove a local variable here, rename a method there.

    The other thing which I’ve recently come to appreciate is the ability to learn from pain. Just like it is with your body, problems in your code base should be painful. When something begins to cause pain, rather than focusing entirely on getting it to work, try to think about why it’s painful and what you could do to make it easy and straightforward. Of course, this applies not only to application development but also things like editors and file management. Pain is your codebase’s way of trying to tell you that something is wrong–don’t “be a man” and ignore the pain.

Comments are closed.