Unfortunately for the fellow at RailsMachine, this talk is an area that I’m really trying to stay abreast of. I historically have had very little money to spend on architecture, and the concept of virtualization has had a huge impact on my professional development. As such, I thought that I would give some time to a practitioner in this space that wasn’t Joyent

Applying the concept of virtualization to Rails deployment is something I’ve already done, and his presentation was more about his offerings than how he engineered them. Any development shop that is concerned with how they will run their product when it becomes successful should have had both ears open. I have been spending a lot of time on this, though, so it wasn’t so useful for me. I’m sure others had a different experience.

This talk was a bit of a stretch for me, having never written an application that was even close to needing Memcached. I had a great seat, though, and really enjoyed meeting Chris at the “Joyent Happy Hour”. I also had just sat through a talk where all the concepts were familiar. What was the worst that could happen?

I ended up really enjoying the presentation for multiple reasons. You can access his presentation here and be sure to look around for the download option. And get the version with notes!!!

I loved the introduction which definitely made me feel like I might have been sitting there in that GameSpot booth with the same challenges. (Although odds are good that I would have been watching the braniacs do the real work.) He also didn’t set himself up as an expert, which I normally respond well to, especially if the speaker is obviously lying because he is in the middle of presenting at RailsConf. I also really appreciated that he shared a mistake he made that brought down GameSpot. Learning from others’ mistakes is the best.

The introduction to memcached couldn’t have been better, from my perspective. I knew almost nothing about it, and learning very quickly about the basics was nice. Everyone knows what a hash is like, and the presentation built appropriately from there.

It takes balls to put a YAGNI slide 25 slides into your presentation… about your presentation itself!

The cache_fu plugin appears to be one of my favorite sort of plugins, the sort that does a lot of assembly and simplifying of other work. The code was never that hard to grasp and his presentation is still available as a starting place.

This presentation also sounded another note about using mocks and stubs. Gotta look into getting more hands-on experience there. Check out slide 70 for goodness sakes, although that’s not a result of mocha or stubba.

The biggest take home for me is it’s OK to make mistakes. It happens all the time. The problem is not being able to react because you don’t know what you’re doing. That’s why you can listen to the front-runners and make sure that you do it as right as you can the first time out.

This presentation was one of the highlights of the conference to me. For me, it was a perfectly structured talk. It joins the V is for Vexing, Joyent Happy Hour, and the make_resourceful talk as the overall highlights of the conference for me. (make_resourceful link coming soon!)

In my experience, there are a lot of developers who are learning Ruby by programming in Rails. Most of us know that Rails takes a lot of advantage of the advanced metaprogramming techniques in Ruby, but how many of us take the time to learn all the mechanics of how it works? What made this talk so effective was that James was able to take a part of Rails that a lot of developers have to interact with (plugins) and explaining some of the Ruby magic behind how it all comes together.

You’re left with a very solid understanding of how everything works behind the scenes. As a result, you’re in a much better position to be able to write your own plugins, but also how to be a good plugin consumer. Don’t waste any more time listening to me, download the talk and check it out.

Friday was the first “real day” of the conference, with DHH’s opening keynote (well summarized by Patrick Reagan here) and the first day of sessions. You’ll have to wait for my own summary post on the entire conference to get my impressions of the keynote speakers.

My day included

• Bob Martin’s Clean Code
• Jay Field’s presentation on Taking Rails Tests to the Next Level
• Building and Working with Static Sites in Ruby on Rails from Ben Scofield
• Standing on the Shoulders of Giants from Adam Keys
• A trip to Joyent Happy Hour
• Getting back in time for Ze Frank’s keynote

After that, Jon, Patrick and I had a horrible dinner at American Cowgirls which I will now erase from my memory forever. After that, we walked to some bar whose name I can’t remember where I fell asleep in a chair on the back patio. We took a cab back to the hotel, and I relished my good fortune.

If you’ve never been to a talk by Bob Martin before, one picture really does equal a thousand words. (Make sure to check out the link in the third comment.) He is a very passionate, very intense speaker. He challenges the listener to rise to a higher level of code-fu. This was the first time I had heard him talk, and I won’t be likely to forget it anytime soon.

More than any of the lessons about Ruby that we went through, what stuck with me the most was the attitude he shared with his listeners about rewriting and redesigning the system you’re working with. In his view, the “main build” never ceases forward motion. Requirements will be added and the code base will change in response. Thus, any redesign is still aiming at a moving target. His warning was to be very careful about pinning all your hopes as a developer on the Once and Future Rewrite.

He would recommend that when you work with a certain piece of code, check it back in a little cleaner, and a little nicer. Eventually, those habits will accrete and really start to add up in terms of code quality.

You can get a lot of the benefits of this talk (without Bob’s inimitable style) by reading his presentation files. Those files use Java as the language, but feel free to skip those bits to get the flavor of his message. It’s definitely worthwhile.

I originally found Jay Fields’ blog from a reference in the back of Rails For Java Developers from Stu Halloway. Reading his blog was really interesting and dealt with a lot of unfamiliar topics. As a result, I was eager to hear him speak.

Jay had one slide for his entire presentation, but a lot of ideas. Visiting Jay’s blog particularly the posts that he has tagged Testing Refactorings would be an excellent start.

Jay’s session started one of the ongoing themes of the weekend for me, which was rethinking my approach to testing. Just because tests deal with models does not make them unit tests. Just because tests deal with controllers does not make them functional tests. That determination depends on the context, and what precisely it is that you are testing. To that end, during the presentation it was revealed that Rails plans at a later date to begin structuring the test hierarchy to include model/ and controller/ directories under test/ instead of unit/ and functional/.

Less than ten minutes into the presentation, Jay mentioned that one of his development goals was test each test case should fail in isolation. In other words, if you make a change to your code-base and run the tests, there should be no cascading failures. I found this to be an outlandish idea at first, but when I started to think about it, it made a lot more sense in certain ways. My first question for him was if that led to an explosion in the number of his test cases, which he answered in the affirmative. It makes sense to me, though, that a fuller explication of every bit of behavior that you expect will lead to healthier code-bases in the long term.

One reason that Jay is able to have goals like these is that he is comfortable with Ruby metaprogramming and the various mock libraries for Ruby. As in Martin Fowler’s Mocks Aren’t Stubs article, I have been a classicist for a long time. Like Mr. Fowler, I find the mockist dependence on implementation troubling. Unlike Mr. Fowler, I have not worked with mocks nearly enough to have formed my own opinion of their benefits. It’s an exciting area of inquiry for me.

My summary is that Jay is a very thought provoking thinker who is very serious about his testing. I really appreciated the conversational tone of his talk, and I wouldn’t hesitate to ask him a question if I come up with one while looking into the area.

Ben Scofield, who I had not met, works with Patrick Reagan, who I have. Combined with the fact that almost every Rails site that I have written has some amount of static content, I was interested to see the talk.

In the style of Bob Martin’s talk early in the day, Ben’s presentation dealt with a progression of potential solutions to the problem of handling static material within Rails. The first solutions were very greasy! Check out this potential security hole:

def show
  page_path = params[:path].join('/')
  if File.exists?("#{RAILS_ROOT}/app/views/static/#{page_path}.rhtml")
    render :template => "static/#{page_path}" 
  end
end

Obviously, that was from phase one. In the end, they end up with a solution of some elegance!

I don’t want to short-change Ben here, but I would like to give a better writeup when he comes to speak at CVREG in the coming months.

Their plugin is available, as are the presentation slides.

Adam Keys made a big splash last year with his presentation AC/DC, Stravinsky, and Rails. Reading open-source code is one of my primary methods of learning, particularly languages in which I’m not that experienced. So I was pretty pumped for this session.

Despite Adam’s entertaining style, I thought this presentation was pretty slow apart from the rapid-fire, laugh a second intro. (Check slide 8 for the “hottest thing he could think of.”) I would have much preferred to see a few more examples of real code that he thought were particularly enlightening, although he has promised to write more about that in his own blog post.