has_many :thoughts

About 6 months ago now, we decided to switch all our web application development to Ruby on Rails from ASP Classic. At the time, I needed to sell my team (and myself and other business stakeholders) on investing significant company resources on a switch. And so I put together this list which I distributed to our team. At some point in the coming weeks, I plan to update this to why we’re sticking with Rails and I hope to incorporate it as part of the forthcoming commercial section of PhillyOnRails.org.

1. Faster Development
   • The initial tidbits I heard said that rails can help us develop applications faster, with less time spent on repetitive mundane tasks.
   • This is the reason I first started looking into Rails.
2. Model / View / Controller
   • The MVC forces us to separate business logic (models) from presentation code (views) and connect them together with functionality (controllers).
   • This will force us to produce more easily maintained applications, sites that can grow more easily.
   • We can create code that is more easily ported from one application to the next, because presentation code isn’t intermixed with logic.
3. DRY
   • The entire Rails architecture and community is heavily aligned toward the concept of Don’t Repeat Yourself.
   • This will help us stop repeating the same code in so many places. Less repetition means more efficient development.
4. Framework Features
   • As a web framework, Rails already does for us a lot of the little things we spend lots of time doing.
   • Like validation. It’s a couple of lines of code to produce server side validation that works really nicely.
5. Testing
   • The work we’ve been producing lately has been appallingly buggy. Even if the kind of mistakes we make are simple human errors, to the client, it’s a mistake and it causes something not to work.
   • Although we need to take better care to test the things we do, it would become cost prohibitive to test every single line of code on every single page of every site each time a minor little change was made. So…
   • Rails has built in testing functionality:
     • We can define specific results that should appear when specific actions happen.
     • Rails can automatically alert us when something we do in part A of the application breaks something that’s supposed to happen in part B.
   • Less buggy apps = happier clients = more clients.
6. Neat Language
   • The Ruby language itself is pretty different but I like it.
   • There’s certainly a learning curve but the object-orientedness of it is really powerful and makes writing it much more natural than other languages I’ve learned.
7. Source Code Control
   • Right now, most of the development we do is on live sites. When clients do ask us specifically not to do something live we end up having a ton of scripts to rename and change just to post things live.
   • Rails allows us to develop on our machines while the rest of the world isn’t hitting the application.
   • Although we could institute some source code control mechanism with ASP, it’s harder: licensing costs would be expensive to have all the 3rd party components
8. Open Source
   • Rails is open source and is most commonly used with other open source components such as MySQL.
   • Open source = less licensing fees to Microsoft
9. Learning is Never Bad
   • Learning something new is always a pain in the ass, but it will probably help us with our ASP applications, too.
   • Focusing on being DRY and paying more attention to testing in our Rails apps will hopefully have an affect on our ASP development too – which there will surely be plenty of in the coming months and years.
10. ASP Is Dead
    • Standard ASP 3 is going by the wayside – fast.
    • If we are possibly going to stay competitive with other web development shops, we have got to adopt new technologies.

I don’t know why I didn’t learn of this until now. But .rhtml file extensions are now deprecated and will be removed at some point. One is supposed to use .erb instead of .rhtml.

On one hand, it bugs me that a lot of stuff deprecates pretty frequently with Rails. Seems like there’s always some warning that’s popping up in the Mongrel console window.

On the other hand, so far, it’s been pretty trivial to change over to the new conventions and clear up deprecation warnings. And I have yet to see functionality actually drop off so it’s not like I’m not given plenty of notice.

Of course, with the way Gems work, I can have different versions of Rails running on the same machine with is awesome. Because, as a contract development shop, sometimes clients just aren’t going to pay to upgrade an app to the latest version of whatever. And those clients can remain running on old Rails versions as long as they want while the rest of the sites run the latest versions.

I’ve always liked the idea of having URLS that used the names of the resources they accessed rather then cryptic ?id=1234 junk. Mainly for the reason that it looks nicer for humans AND for search engines if there are keywords at not numbers.

The first couple of times I’ve implemented a system for this, I created a callback on the model that stored a “url_name” field for each item. Essentially, it stripped out everything but alpha numerics and made a pretty version with dashes instead of spaces.

But this is a pain to maintain. Mostly because they need to be unique and if you have a lot of repeated item names you end up having to append digits to the url_name’s. And it gets ugly, fast.

So I came across a technique I’m trying out on Version 2.0 of Find Mini Golf. Essentially, using the default :controller/:action/:id Rails routes you can still have prettier URLs by substituting the usual :id => location.id with a string that begins with the ID.

Here’s how I do it:

I extend the string class with a file in /lib like so:

class String
  def url_name
    self.tr("/\',&?.","").tr(" ","-")
  end
end

(I should probably make that more robust to lob out other characters, too.) Then on my model, I add an instance method like this:

def id_url_name
  id.to_s + "-" + name.downcase.url_name
end

Now, in my views, when I want to link to that location with link_to or whatever, I can use :id => location.id_url_name.

The trick here is to how Ruby handles conversions from string to integer. Essentially, it uses all the numeric characters from left to right until it encounters the first non-numeric. So “1234-anytown-miniature-golf” converts to 1234 and therefore, gets plucked from the database as it always would.

I love this technique because:

1. It’s easy. 2. It doesn’t require I maintain another column of unique url_name’s. 3. I wouldn’t need to change the default routes. 4. Extending the Ruby core classes is just freakin’ cool.

Next week, I’ll be attending RailsConf and I’m pretty damn excited.

Dr. Nic recently released a neat tool called MyConfPlan.

It’s a little app that allows one to specify and publish which sessions at a conference they are attending. And so, I give you my RailsConf 2007 picks v1.0.

For the benefit of our other team members who are not attending, I’m going to blog as much as I can throughout the event. So check back for updates May 17-20.

Welcome to our blog.

Kinetic Web Solutions is a small team of developers who are evolving from an ASP website design/development shop into a Ruby on Rails web application development consultancy.

We hope to accomplish several goals by deploying this blog:

1. Establish a wider presence in the RoR community
2. Contribute some of our learnings back to society
3. Develop a stronger team sense amongst our employees
4. Create a central location for team members to share resources

So now I will stop yammering on and we’ll see if this deployment of Typo works.