8th Light Blog

Did I say I was tired yesterday? That wasn’t tired, this is tired. I’m currently training for the marathon, and today I was scheduled for a 13 mile run. Sadly marathon training does not wait for RailsConf so I was up at five this morning, viewing the fair city of Portland. Say what you will about running, but it’s a great way to see a new city.

It’s also a great way to get lost. I used the great website at USA track and field where people post their runs in order to find a place to go and promptly wrote down a street name incorrectly. I ended up wandering around Portland’s lovely Willamette river, which fortunately provides a great landmark for a poor lost tourist. This led to running, and running, and running…and finally a Runners High.

Runners High is a phenomenon cause by your brain releasing endorphins, as a defense mechanism against the way your body feels. When I run my brain feels extremely active, and jumps from topic to topic making associations, breaking down problems, etc. It’s not unheard of for me to fix a bug I’d been struggling with while on a run, in a sudden burst of insight. Today, when I wasn’t wondering where the hell I was, I started thinking about quite a few things one of which is related to the new IDE’s being developed and the barrier to entry on Rails. Bear with me because this is a little out there, and I haven’t quite figured out how to articulate the concepts.

Right now Ruby and Rails are still strange and unusual things to most developers. When introduced to the language they want an IDE, and upon hearing there is no visual debugger or that they have to use Textmate, Eclipse or god-forbid emacs they turn away. They stick with Java or C++ and wizards and comfortable development, and will wait until they need to use Ruby.

Then one day their boss hears about Rails. They tell the developer, ‘you should be using this!’ and so he goes and he gets an IDE, real slick one with lot’s of bells and whistles. He goes to generate a model - only he doesn’t use script/generate. He uses a wizard, he sees he can add his methods and data members right there, so he does. Test? What test? Then he goes to the controller and has his controller manipulate the data all day, and develops a view in a WYSIWYG editor. He spends all day in the debugger, and his methods get bigger and bigger. Of course that’s no big deal, because he uses cold folding to hide their size. Then testers write Test::Unit code to test his code, and he’s done, because developers don’t test. Meanwhile we’ve all left Ruby because, “so much of the code is crap.” Haven’t we done this cycle before?

Chad Fowler described us as arrogant in the introduction, and clearly if you look above we are. I say we because nobody reading this had a problem with my rant, so you’re just as arrogant as I am. Caught you. We think we’re smarter than everybody else don’t we? Actually I don’t and most of you probably don’t either. I just know that there is a right and wrong way to do things, and so does Rails. That’s why it’s so opinionated. An attendee, Jack Canty, put it better than I can by saying “Rails is opinionated, and this takes away those opinions.”

So how do we fix it? Well let me steal some of Micah’s DSL thunder by using an analogy I thought of while running. It’s morning, and you want a coffee. So you go to a certain ubiquitous chain and say, “I’d like a big coffee please,” only said ubiquitous chain doesn’t have big. They have Tall, Grande and Venti. If you do this there will be a noticeable pause while the guy behind the counter takes a second to think about what you just said. He’s not a moron, take off his green smock and he knows what a big coffee is, but he’s got to translate it. What’s big - is it grande? Venti? That’s because you’re not speaking his language. You eventually do get your coffee, because he can figure out what you mean, but it takes just a little bit longer. While you wait in line you hear other people say, “I’ll have a grande half-caf no-foam latte,” and the guy behind the counter immediately repeats it. Eventually you learn the language they speak, and you get your coffee just a little bit faster. You’ve adapted to the idioms of the coffee shop, and you’ve been rewarded for it.

So what the heck does that have to do with code? I kind of gave it away by using the phrase idioms, didn’t I? Well let’s say you’re a C++ programmer and you start on Ruby. You don’t write Unit Tests, which despite what we sometimes think most developers do NOT do, and you sit down to iterate through an array. So you write:

index = 0
while index < array.length do
  puts index
end

Much like ordering a big coffee at the Green Angel, that will work, but it’s completely incorrect. It’s not speaking Ruby even if it’s in the Ruby language, and unfortunately I believe that if we do not work hard to enforce and teach the best practices of the Rails and Ruby ways, we will witness this kind of thing propagated. I’ve done the C++ without test thing and lived in the debugger, and it drove me nuts. Unfortunately many developers don’t think anything is wrong with that. If they did they’d be here already. That’s what programming is to them. The good news is that we are the early adopters, and when they come around they will adapt to our rules but only if we make them. Remember what I said about the pause at Starbucks? Well the code above won’t pause. Ruby will execute it just as nicely as anything else, and maybe it shouldn’t, I’m not sure. What I do know is that the IDE’s now being created should not be catering to the developer that wants to do the things the way they’ve always done them. Instead of opening ‘choices’ up and making things ‘easier’, our IDEs should enforce the opinions of Rails. You see the late adopters aren’t lazy, or stupid, they’re just being rewarded improperly. If it’s easy to make a model without tests, they’ll make one, even if they are hurt by it later on. They’ll even stay until 1 AM to debug it, and their boss will think ‘gosh this Rails thing isn’t so great after all, thank God my programmers are so dedicated.’ Fortunately we control this. There’s a reason the IDE makers are here, and that’s because they know that late adopters ask the early adopters what they use. Tell the IDE makers that you want an IDE that does not allow bad habits. I want an IDE that is integrated with subversion, but I also want it to yell at me if I have untested code, and run ZenTest. If it gives me a wizard the first question it should ask is “what is the name of the test?.” Instead of code folding to hide bad code, it should identify refactoring opportunities. Finally, I’m not sure I even want a debugger. Debugging sucks, and it’s a crutch. I can test behavior rather than step through it and look at it. I realize people do want debuggers, I just worry for the day when Rails code can’t be properly understood without stepping through it.

Tell the IDE developers that you want an IDE that helps create good code, not easy code. If they don’t do that, then when developers ask you what you use say emacs. If the developer still turns away, we probably aren’t losing much.

Of course if you’re reading this you’re probably at RailsConf so hello from here. I’m right next to you actually, to your right. Yep that’s me, hi. There’s a coffee stain on your shirt.

I plan to blog as much as possible from here, and hopefully bring a little of the experience back home to those of you that couldn’t make it. I just came out of my first tutorial, “your first day on JRuby on Rails”, and found it quite enjoyable. Admittedly we’ve been playing with JRuby for a little while know here at 8th Light, so much of it was stuff I already knew, but it was great to talk to Charles Nutter and get some of my questions answered directly. Some highlights:

• Deployment with JRuby on Rails is a snap, assuming you’ve already got some sort of existing Java Enterprise setup. Using the GoldSpike plug-in creates a deployable WAR file. While I don’t see a reason for doing this on any current projects, for those of you out there using servers that might be resistant to setting up Apache/Mongrel this was a nice alternative. Install plug-in, run rake task and you have a deployable WAR file.

• NetBeans for Ruby fairly stole the show. I’m a big TextMate fan, especially because I no longer debug with anything other than puts statements, so I don’t need a fully fledged IDE for Rails. That said the features they demonstrated for Ruby were great, including code completion, jumping to methods, and my personal favorite clicking a method call and jumping to it’s source code even if it was in a Gem. I’ve done a lot of hunting in Gems and this would be enormously helpful. Rudimentary refactoring support is expected as well, including support for rename method. I asked how this would work in Ruby and the plan is to show places where the rename could take place and leave the ultimate decision up to the user. I didn’t get to see this in action, and I’d like to because I fail to see how that is better than just using find. I’d be hard-pressed to switch from TextMate, I’m writing this post in it, but I could be convinced if NetBeans could be the “editor you live in.”

In other news the Portland Conference center is really nice, with pretty good wireless network connections. One thing I’d ask for would be more tables outside the ballrooms, as there are only about 6 and a lot of people have their Macs open on the floor. Speaking of which I’ve never been anywhere that the Mac so dominated. 80-90% of the people here are carrying MacBooks.

Now if you’ll excuse me, I’m hungry.

In my younger days I was a Line Cook at the Olive Garden. In case you’ve never worked in the food industry, Line Cooks are the guys putting meals together as fast as customers order them. At times, it’s nearly impossible to keep up.

Among the most fundamental of the Line Cook’s principles was Clean as you go. I can remember clearly the manager walking regally down the line chanting, “Clean as you go Javier. Clean as you go Micah. Clean as you go Brian.” Cooks would remind each other from time to time too, “Clean as you go!”.

As you’re realizing, it’s import to keep your station clean when you’re a cook. Keeping things clean is not easy. Food gets EVERYWHERE when you’re putting together hundreds of meals an hour. Why is it important to keep it clean? Simple. When your station is dirty, the system breaks down and it slows you down. Utensils are dirty or missing, ingredients get mixed together, cooking surfaces are soiled… Combine this with all the fire, boiling water, and sharp knives, it’s dangerous too! Worse, other cooks are not able to help out. Uncleanliness on the line is a vicious cycle with positive feedback. Every experienced cook keeps their station spotless at all times and unexperienced cooks learn fast.

Dirtiness is a sign of trouble too. Let’s say that it’s the middle of a dinner rush. You look down the line and notice that Javier’s station is becoming cluttered. It’s near certainty that in five minutes Javier’s system will break down. Food will be burnt, orders will get lost, and servers will get vocal. Don’t get servers mad! Line Cooks work as a team though. So when you see that Javier’s station is getting cluttered, you jump over and give Javier a hand every moment you can spare.

This principle, “Clean as you go”, is well applied to software, “Clean as you code”. The analogy is fairly straight forward. Although I’ve applied the principle to software for years, it was only recently that I recalled the mantra “Clean as you go”. I’m sure my teammates will soon grow tired of hearing me chant… “Clean as you code!”