The Ruby/Rails Life – My Rails 3 Stack – Part 1

As some of you might know, About a month ago I left my almost 10 year career as a Microsoft developer to become
an independent Ruby/Rails developer (a term I’m deeming “pulling a Gunderloy”).
It was long overdue for me and I couldn’t be happier to be free from the shackles of Microsoft.
It seems lately there are more and more folks coming to the
same realization as I have and are making the jump to work with more open technologies and platforms on the web.
But I’ll leave that conversation to the twitterverse.

Big Fat Disclaimer

As noted above, I’ve only been doing full-time professional Ruby/Rails development now for about a month.
So what you see below is the outcome of my past month of both struggles and successes. I don’t claim to
be anywhere near a Rails expert yet, so please feel free to leave nice and helpful comments about any misconceptions
I may convey below. :D

My Rails Stack

I’ve been given a pretty great opportunity to build a large greenfield product from the ground up using any
technology stack I want. Here is a brief overview of the technologies I’ve chosen to use for my current project,
which I’m loving so far. I’m not going to go into too much detail, but will provide a few useful links for the
relevant projects where you can read up on how to get rolling with them. I’m purposefully not including links
to everything I’m going to talk about because Google is your friend.

RVM (Ruby Version Manager)

This is such an awesome tool. This not only allows you to run completely different Ruby versions
side by side in isolation, but also the entire environment include gems are isolated from each other.
So you can set up different Ruby environments to test out different versions, and the gems you install
in a particular environment don’t affect anything else. This is a must have if you’re experimenting
with different Ruby versions, which I am not yet.

Ruby 1.8.7 (for now)

I decided to stick with Ruby 1.8.7 for now since it seems to work just fine with Rails 3 and plays
nice with all of the gem dependencies I’ve taken on so far, some of which may not be up to par yet
with Ruby 1.9.x. I suspect at some point I’ll make the switch over to Ruby 1.9 and see how it does.
And most certainly once Rails 3 finally drops.

Rails 3 (Beta 3/Edge)

I decided to go with Rails 3 for this new project, mainly because Rails 3 is quite a huge update over
2.3.5 2.3.8, the current “offical” version of Rails. And because Rails 3 comes with some
really awesome new features and improvements. I started with just running Beta 3, which is pretty solid,
but decided to switch over to Edge Rails for a while to get some of the benefits of some of the dependencies
I’m using that take advantage of Edge Rails. There have been a few minor hiccups along the way,
but nothing major so far.

There are many great resources out there for Rails 3, but if you’re interested in really nice detailed
posts and screencasts on new Rails 3 features, check out the Rails Dispatch blog
where Yehuda himself and other great guys are posting some really great content. The excellent
Rails Guides are also being updated pretty rapidly to cover the changes in Rails 3.
Or if you want to dig directly into the API documentation check out one of my favorite Ruby API sites,
RailsAPI. RailsAPI is pretty cool in that it lets
you create a customized API documentation package for Ruby, Rails and popular gems that you can either
browse online or even download.

Haml

A lot of folks might already know my LOVE for Haml. I’ve been using Haml for about a year
and half already in the ASP.NET MVC world using NHaml. So it was a no brainer for me to choose it for this Rails
project. Not sure there is really much more I can say about it except you must try it. :) No, seriously, just do it.
Your hands will thank you!

Sass

The lovely sister to Haml, allowing you to create DRY stylesheets with the use of variables, mixins and all kinds
of other goodness. This is the first time I’ve used Sass on a real project and even though I’m not leveraging
all of its capabilities yet, I love the simplicity of the language. Hopefully I can dig in a bit more soon to
further improve my stylesheets.

Compass/Blueprint

Taking styles and page layout to a whole new level. Compass is a really nifty “framework of frameworks” that sits
on top of Sass and a handful of grid-based CSS frameworks such as Blueprint or 960.gs to name a couple. I chose to
go with the default of Blueprint and it’s been pretty good so far. The out of the box CSS resets, browser-specific
fixes and typography make it really easy to get a decent looking site up and running fast.

jQuery

The fact that Rails 3 still ships with Prototype out of the box still kinda boggles my mind. Nevertheless
with the increased modularity of Rails 3, it’s really easy to swap out a lot of the parts of Rails with
alternatives. For example, you can pretty easily swap out Prototype for jQuery as the default javascript in
Rails 3.

/app/views/layouts/application.html.haml

= javascript_include_tag :defaults

/config/initializers/jquery.rb

if ActionView::Helpers::AssetTagHelper.const_defined?(:JAVASCRIPT_DEFAULT_SOURCES)
  ActionView::Helpers::AssetTagHelper.send(:remove_const, "JAVASCRIPT_DEFAULT_SOURCES")
end
ActionView::Helpers::AssetTagHelper::JAVASCRIPT_DEFAULT_SOURCES = ['jquery-1.4.2.min.js', 'rails.js']
ActionView::Helpers::AssetTagHelper::reset_javascript_include_default

MongoDB

After watching the rise of document-oriented databases for a while and some of my own learning/experimentation,
I decided to make the move to MongoDB as my primary database platform. I say “primary” because I’m a firm believer
in choosing the right tool for the job. So if there are some models that are, for instance, heavily relational
or need strict transactions then MySQL might be a good fit for those particular pieces. If I have a set of simple data, say,
lookup data, perhaps throwing it in a wicked fast key/value store like Reddis might be better for that particular data.
However, most of my models so far in this project are well suited for a schema-less document store given their
hierarchical nature and need to be flexible with possible custom attributes.

MongoDB has been an absolute joy to use so far. It just simple stores whatever you give without complaining.
Don’t have a database named mycoolapp yet? No problem, just attempt to write to a non-existent database and it’ll create it for you.
Don’t have a collection named codemonkeys yet? No problem, just send off a new collection to MongoDB and it’ll
create a new collection (aka table) for you. No migrations, no fuss. I hardly even notice the database is there sometimes.

Mongoid

There are quite a few mappers out there now for Ruby and MongoDB. MongoMapper, MongoDoc, Mongoid, Candy and a bunch
of others (sorry if I left your favorite one out). At the time when I was starting my Rails 3 project Mongoid seemed
to be the most “Rails 3 friendly” one since it supports the new ActiveModel abstraction and Rails Validations out of the box. I
believe some of the others are getting up to speed now as well, but I’m really liking Mongoid so far. Each MongoDB mapper
takes a slightly different approach. Some try to mimic Active Record, while others just give you the bare bones for
you to handle your persistence and querying any way you’d like. Right now I like Mongoid because it seems to strike a
pretty good balance. You get some Active-Record like querying methods, but it also has a very powerful Criteria API.
But like most OSS projects, Mongoid has its own opinions about how you should be persisting your objects. Specifically,
Mongoid leads you down the path of using embedded documents as much as possible, which is the ideal way to store documents
in MongoDB. Oh and did I mention that Mongoid heavily favors composition over inheritance, which is a big win for me.
Another interesting tidbit is that Mongoid is the brainchild of Durran Jordan, of Hashrocket fame. I continue
to be amazed at the number of awesome OSS contributions that come out of the guys at Hashrocket.

Devise

One of the first things I needed to tackle in this new Rails 3 project was authentication. I knew there were a few
good Ruby authentication frameworks out there. Authlogic is the “big guy” in the room here. But Devise is gaining
quite a bit of traction and after I spiked with it for a bit, I really liked it. It really takes advantage of Rails 3
and is extremely flexible and extensible. Devise is one of the few frameworks I’ve used that has managed to achieve
a high degree of flexibility while maintaining its simplicity. Then again, I’m starting to see that characteristic in
a lot of Ruby-based frameworks. Some of the things that Devise will do for you is database authentication, new user
registration, confirmation, password recovery, “remember me” functionality, user login tracking, session timeouts,
validations and account lockout to name a few. There also a growing number of plugins for Devise for things like
Facebook, LDAP and OpenID authentication.

CanCan

Of course authorization usually goes hand in hand with authentication. Don’t get them confused! There are quite a
few players solving this problem as well. Declarative Authorization was the first one I looked at and, while it looked
great, I didn’t need quite that many features yet. I found a simpler solution called CanCan by none other than Ryan
Bates of RailsCasts fame. CanCan is very easy to sit on top of Devise and all authorization rules are set up in single
model class you define named Ability. CanCan makes no assumptions about how you want to handle authorization. Whether
it’s role-based or custom or both, it’s pretty easy to write a few simple rules to get things going. Also very easy to
check your authorization rules in your controllers and views with simple methods like can? and cannot?.

To Be Continued…

That’s enough for this post I think. In Part 2, I’ll talk about the deployment and testing tools I’m currently using.

Related Articles:

    Post Footer automatically generated by Add Post Footer Plugin for wordpress.

    This entry was posted in blueprint, cancan, compass, devise, haml, jquery, mongodb, mongoid, rails, ruby, rvm, sass. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

    11 Responses to The Ruby/Rails Life – My Rails 3 Stack – Part 1

    1. hi, my name is Derick. you must be new here at LosTechies… :)

      FYI… RVM == Ruby Version Manager, not virtual machine. other than that… JEALOUS…. i’d love to get paid for ruby development and that looks like an awesome stack to be developing with.

      keep the information flowing!!! i want to know more and more about what you’re doing and how.

    2. Haha, yeah yeah. I know my blogging frequency has been quite shameful the past couple years. But I’m hoping to pick it back up a little now.

      Oh, and thanks for catching that RVM typo! Fixed! :)

    3. Dusty says:

      Are you developing on windows? I ask because I have been having trouble with rails3, ruby 1.9.1 on win7. I think I might downgrade ruby and give that a try. Great post, looking forward to part two, thx.

    4. John Teague says:

      Great post. keep ‘em coming. I think I’m going to start a new project (someday) on Rails 3. Hope I can learn from your mistakes,err, I mean experience.

    5. Awesome post, I’m thinking to incorporate some of these elements into my Rails app as well.

      Also make sure to check out the JQuery UJS driver that plugs right into Rails 3. This lets you use some of the neat built in stuff (like :confirm parameter), but have it plug in with JQuery very easily. Helps save you a lot of boiler plate JQuery code and leverage some the built in stuff within Rails 3.

    6. joeyDotNet says:

      @Karthik,
      Awesome, thanks man. Yeah, @fredrikhenne pointed out to me on twitter that I forgot to mention the need to download the Rails UJS for jQuery to make that jQuery stuff work in my sample code.

      So folks, if you’re having trouble getting the jQuery stuff going based on this post, make sure you grabbed the rails.js file from here: http://github.com/rails/jquery-ujs

    7. huey says:

      Great post, thanks.

      I’ve recently made a move to allow more time to work with ruby (C# still paying the bills though) so love seeing posts from .NET guys on working with ruby/rails.

    8. Jim says:

      Thanks for the post. I’ve often thought of ‘pulling a Gunderloy’, but as Huey wrote, .Net is paying the bills. I look forward to the rest of this series.

    9. Ruprict says:

      Great article, man. I wish I had more ruby time….

    10. RhysC says:

      Iknow your post will be less and less about .Net but i sure hope you keep these posts coming. Its good to hear from people like yourslef, as i guess, i can relate better to a former .netter better ;)

    11. Daniel Kehoe says:

      Nice summary of the state-of-the-art Rails stack. It’s a little tricky getting all of this working on Rails 3. I created an example app that demonstrates Mongoid and Devise working together on Rails 3. It’s on GitHub: rails3-mongoid-devise with a step-by-step walkthrough on the wiki that shows how to build it. There are options to use Haml and Heroku as well.