Caffeinated Coder

What’s the difference between a spectator and a Newb?

In order to achieve spectatorhood, you really just need to run through a few samples in books and tutorials. If you want to be diligent spectator, you can even go as far as tweaking a few of the samples before passing judgement, but that is not strictly necessary and most certainly is not the norm.

When I wrote my initial impressions about Ruby on Rails post a while ago, I was definitely spectator.

I don’t think I graduated to a full fledged Newbie in Ruby on Rails until I started working on a code base that was destined for production and had someone other than myself making decisions about the functionality. This forced me to quickly abandon the safety net provided by the samples and start hacking away based on my initial, oftentimes faulty, assumptions.

Lest there be any confusion, I am not using the word ‘hacking’ in the technically artistic way, but rather in the brutish, blindly destructive, massively messy way that ends in stuff working, but only just barely and probably not for long.

In the spirit of full disclosure, I also must confess that this alleged code that is destined for production is really only a rather small and simple e-commerce app for my wife’s new side business of selling jewelry. Furthermore, I am not actually getting paid for my toil unless you consider the absence of persistent, not-so-subtle hints from the spousal unit a form of payment.

Despite these marks against me, I’m still claiming my status as Rails Newbie (not to be confused with n00b) and doing so with pride.

In honor of the occasion, I thought I would share a few thoughts that are, of course, heavily colored by my .NET centric developer background.

So far I’ve enjoyed…

• Writing Less Code - While I am always suspicious about claims of drastic code reduction, especially since these numbers are often confused with the total time it will take to deliver a project by misguided CIO types, I have noticed that my code files are pleasantly sparse compared to what I am used to as a .NET developer. While much of the code reduction can be achieved on the .NET side by using an implementation of an ORM and ActiveRecord framework (i.e. NHibernate and Castle’s Active Record), some of the niceties, such as the lack of redundant type names, curly braces, and keywords are unique to either dynamic languages as a whole or Ruby specifically. Some of my fellow developers who voted against including the new C# var keyword in our coding standards would hate the loss of explicitness, but I find it refreshing.
• Having Code Be Organized More Logically – My attitude towards the MVC (Model-View-Controller) approach to doing things has dramatically changed over the past year. I went from initial annoyance at not being able to map a url directly to a file name, to delight once I  got used to it and eventually realized that finding code was actually easier once it was split across three files according to function instead of all crammed into one file. I also like that I am immediately familiar with the directory structure whenever I open a new Rails project because it is mandated by convention and created automatically for each new project. This avoids the initial period of disorientation that I always feel whenever I open up an unfamiliar .NET project.
• Rapid Feedback – I have to admit that I like being able to pop open a file instantly in SciTE (think notepad with syntax highlighting) and then immediately seeing the results by simply saving and hitting refresh on the browser. It actually made me nostalgic for the good ole’ days of classic ASP when I didn’t have to suffer through 10-25 second compile times each time I wanted to verify whether a change would work or not.
• Managing Database Changes with Migrations – Being able to express database changes (both shema and data) in code rather than SQL and then roll the versions forward or backward in an automated and controlled way is definitely one of my favorite features of this new landscape. It’s such an obvious requirement for such a common pain-in-the ass task that I can’t believe that it isn’t built into the .NET development experience. My top TO DO item at work after our next release is to steal some time to integrate one of the .NET open source MIgrations clones that I’ve recently read about.

…but I have NOT enjoyed…

• Discoverability – While working on Rails, I’ve gained a new appreciation for how discoverable the functionality within the .NET framework is. When I want to figure out how to do something, I can usually find the functionality without ever having to leave the IDE. I simply use intellisense to start navigating through the namespaces until I find a good candidate and then simply glance at the tool tip popups to find out information about the parameters. The Microsoft framework is not only huge and comprehensive in the functionality it provides, but the designers have invested ungodly amounts of time into making the API well named, consistent, and logically organized according to namespace. I’ve been relying heavily on Google with all the Rails work I’ve done and it feels like I’ve wasted a lot of cycles just finding how to do stuff. While I often like the answer I get better when it comes to Rails, it still annoys me that it takes so much more effort to find the answers in the first place.  The main documentation site, http://api.rubyonrails.org/, contains good information if you can arrive at it via google, but simply trying to browse the site for information is a nightmare.
• Rails 2.0 breaking changes – This is also something that you just don’t see in the .NET world since Microsoft is so fanatical about maintaining backwards compatibility. It wouldn’t seem like this would be a big deal unless you had a big legacy app to worry about, but this actually made the whole discoverability and learning process all the more frustrating because there are so many stale nuggets of information out there. Although the main book I have been reading, Agile Web Development with Rails, was tremendously helpful for what I was trying to do, I still had to spend a decent amount of time figuring out why several of the code sample didn’t work because method calls that were renamed or simply stripped out of Rails 2.0.
• Hosting Site Support for Rails – I really like my hosting site, precisioneffect, because it has an awesome support staff that answers questions and solves problems extremely quickly. However, I was disappointed to learn that they were no longer going to offer Rails support on their newer servers because of some troubles they’ve had trying to support it. I was also dismayed that some of the reliance on command line tools in Rails didn’t always translate nicely into a web hosting environment. For example, I wasn’t able to execute my Migrations files to create my database so I had search around to figure out a way to generate a traditional sql file from my migrations script so that I could deploy it. I’m sure there are advanced tools to help in deployment situations, but I’m just barely a Newb so I haven’t gotten that far yet.
• Debugging -  Having easy access to an advanced visual debugger is such a central part of the out of the box experience in .NET that it is not uncommon for a .NET newb to be stepping through hello world example code in the debugger. Although Rails does have a command line debugger that allows you to step through code,  it is definitely no where near as accessible or usable as I’m used to with Visual Studio. I’ve seen several IDE’s mentioned that offer visual debugging for Rails, but so far I’ve only tried Aptana, which is so far most notable because it actually took longer to load than Visual Studio which I mistakenly thought was one of the more bloated pieces of software out there.

All in all, I have really enjoyed the last month of late night Rails development and feel pretty motivated to dig deeper into a few more books once I launch version one of my first Rails site. Who knows, perhaps someday I may even graduate to whatever level comes after the Newb stage.

Popularity: 9% [?]

 Subscribe in a reader