Ruby on Rails Planet

Resources for Getting Started with Ruby on Rails »

Created at: 16.11.2010 01:02, source: Engine Yard Blog, tagged: Uncategorized books classes community courses irc rails ruby Tutorials

Ruby on Rails is leaving the early adopter phase and becoming more mainstream. More people want to learn Rails but don't know where to begin. Well, I have come to the rescue. The resource list below is a good starting point. It includes tutorials, books, blogs, podcasts and many other educational resources that have done wonders for me throughout my Rails learning process. I hope others will find them helpful too. I personally enjoy interactive and visual experiences. The interactive tutorials (sometimes with a live person) were very useful to me. However, plenty of other people prefer to learn by reading, so I have included great resources for these folks too. I also recommend attending meetups and conferences. Getting involved in the community is a great way to find mentors who can help you out, and participating at events and user groups is a good way to stay on top of the latest news and cool projects. If I've left out any resources that you've found helpful, I would love to hear about them. Please let me know about them in the comments section.

Mysql2 Error after upgrading an app to Rails 3 »

Created at: 28.09.2010 07:22, source: Hackido, tagged: ruby mysql linux rails mac

Announcing RailsDeveloper »

Created at: 01.09.2010 20:01, source: Robby on Rails, tagged: Ruby on Rails ruby programming PLANET ARGON railsdeveloper rubyonrails rails

Earlier today… our team at Planet Argon launched a new site for the Ruby on Rails community. If you have a few spare minutes, I’d love it if you’d to head over and read the announcement on RailsDeveloper.

Enjoy!

Pragmatic Polyglot Persistence with Rails »

Created at: 23.08.2010 12:50, source: Engine Yard Blog, tagged: Technology rails redis

This post comes from guest community contributor Kent Fenwick. Kent is the tech co-founder of of Viewpointr, a personalized Q&A service that aims to provide an easy way to get and give help. When he isn't programming, he spends time with his family and friends in Toronto. Kent writes here and can be followed on Twitter at @kentf.

It's getting more and more difficult to pick a persistence layer for your web application. When I started in Rails four years ago, there was really only one option, MySQL. Now, there are many more, each with their own pros and cons. Some are new and some are old, some are tested, and others, not so much. What's clear is that when you are building a business around data, you want to make good decisions. That being said, often only the future will tell if you've made the right ones. I want to share with you my persistence story about how I ended up getting the best of both worlds. h2. The Problem There are too many choices and each choice has a loud evangelist of its own. When designing Viewpointr I went go back and forth daily between MongoDB, MySQL, PostgreSQL and Cassandra. Viewpointr is essentially Twitter with a focus on helping people. Therefore, we have some common data elements: a user specific time line, a user specific list of people who they are helping, and a user specific list of people helping them. Because I am ambitious, I would find myself asking questions like: bq. "Hmm... but will MySQL scale to 1,000,000 records?" Looking back on these internal conversations I find them funny; programmers always tend to think big. However, these are real concerns that developers and teams think about. While planning I would constantly consult the blogosphere for help, and to see what others were doing. Kirk Haines of Engine Yard wrote a great series of NoSQL posts highlighting and comparing different key-value stores and explaining their pros and cons. Since then, there has been a flurry of articles each week outlining different NoSQL datastores, NoSQL vs. MySQL debates and flamewars etc. h2. The Opportunity Data is not created equal and this is a good thing. The same way we do not use an array for every "list" type problem when programming, sometimes hashes or linked lists will better suit the needs of the problem. We need to start thinking about data the same way. This was the best decision we made at Viewpointr and it allowed us to move forward at a great pace. I looked at our application and broke it down into components. Viewpointr has many typical CRUD features similar to all Rails apps. These are very well designed for MySQL and a relational database. Being able to pull a list of answers based on a given question using simple and optimized SQL that I understand is a big win. However, there are some things that it doesn't model well. Friendships. The simplest way to model friendship using a relational database is to create a relation that refers to the same table with two different names. Let's say you have a users table and you want to model Twitter-like friendship where User:1 can befriend User:2 without User:2's permission. It's easy enough.

class Friend < ActiveRecord::Base

 belongs_to :user
 belongs_to :contact, :class_name => "User", :foreign_key => "contact_id"

 # user befriends contact
 def self.befriend(user,contact)
    relationship = find_by_user_id_and_contact_id(user.id,friend.id)
    if relationship.nil?
      transaction do
        Friend.create(:user => user, :contact => contact)
      end
    end
 end

end

class User < ActiveRecord::Base

  has_many :friends, :dependent => :destroy
  has_many :contacts, :through => :friends, :order => "created_at DESC", :dependent => :destroy

end

However, I have always felt that it's clumsy. What I really want to say is: "Each user has a list of IDs that represent the people that they are friends with." Sounds like a de-normalized list right? h2. The Solution Enter Redis. Redis is a key-value store similar to memcached but more flexible since lists, sets, ordered sets and strings can all be used as values. Thanks to its simple API, the problem I described is essentially an atomic operation in Redis. Redis has a great "set" implementation and allows you to do all of the things you would imagine a set to do: addition, subtraction, unique insertion, deletion, union, intersection, etc. The operation will ultimately look like this:

SET = Redis.new
SET.set_add key, value

However, since we are working inside a Rails app, we need to make sure we have the right plumbing setup. # Create a redis.rb in your initializers folder. # Create a new Redis database for each of your needs. In our case, we want to have a dataset that keeps track of a User's helpers (other users who are helping them) and a list of a User's friends (other users that the user is helping). Since we are going to be using these Redis objects throughout the codebase, I like to declare them as global variables in the redis.rb initializer file.

HELPERS = Redis.new(:db => 0)
HELPING = Redis.new(:db => 1)

Notice that I pass in the :db key so that we make sure HELPERS and HELPING will hold two different Redis objects. You can use redis-namespace gem if you want, but I find the default syntax from the redis-rb gem works well enough for my purposes. Now that we have these global Redis objects at our disposal throughout the application, we can start using it in our Friend.befriend method.

class Friend < ActiveRecord::Base

 belongs_to :user
 belongs_to :contact, :class_name => "User", :foreign_key => "contact_id"

 # user befriends contact
 def self.befriend(user,contact)
    begin
     HELPERS.set_add contact.id, user.id
     HELPING.set_add user.id, contact.id
    rescue
     RedisLogger.info "Redis Exception"
    end
 end

end

class User < ActiveRecord::Base

  has_many :friends, :dependent => :destroy
  has_many :contacts, :through => :friends, :order => "created_at DESC", :dependent => :destroy

end

However, this isn't the best solution right out of the gate. Using a NoSQL datastore has some drawbacks that aren't apparent in development mode but reveals its ugly face in production. If you are not careful, a simple restart of your Redis server can cause you to loose all your data. Managing your Redis data in production deserves it's own post, (coming soon) but for now, let's create a safer solution that you can gradually roll out as you become more comfortable with storing, backing up and using Redis datafiles.

class Friend < ActiveRecord::Base

 belongs_to :user
 belongs_to :contact, :class_name => "User", :foreign_key => "contact_id"

 # user befriends contact
 def self.befriend(user,contact)
    relationship = find_by_user_id_and_contact_id(user.id,friend.id)
    if relationship.nil?
      transaction do
        Friend.create(:user => user, :contact => contact)
      end
    add_to_denormalized_list(user,contact)
    end
 end

  def self.add_to_denormalized_list(user,contact)
    begin
     HELPERS.set_add contact.id, user.id
     HELPING.set_add user.id, contact.id
    rescue e
      RedisLogger.info "Redis Exception"
    end
  end

end

class User < ActiveRecord::Base

  has_many :friends, :dependent => :destroy
  has_many :contacts, :through => :friends, :order => "created_at DESC", :dependent => :destroy

end

The strategy is simple, mirror the MySQL data in Redis. By adding a call to add_to_denormalized_list, we mirror the ActiveRecord call using the simple and elegant Redis set syntax discussed above. As you and your team get more practice and become more comfortable using Redis in production, you can start writing more to the denormalized list, eventually moving this part of your application away from ActiveRecord and MySQL to Redis. You could do this manually or you can use James Golick's recently released gem called Rollout that uses, you guessed it, Redis, to programatically rollout features to users. Like anything else you code, testing and benchmarking this process in production is crucial to make sure you are saving time and cycles. It might seem like a waste to duplicate your data in Redis, but you are a pragmatic polyglot persistence developer right? You want to explore the NoSQL space while making sure that a little mistake or misunderstanding doesn't sink your ship. Give something like this a try, it doesn't get any more pragmatic. When do you try it or come up with something new, let me and everyone else know about it. Thanks for reading.

Rails 3 Internals: Railtie & Creating Plugins »

Created at: 04.08.2010 19:58, source: igvita.com, tagged: Ruby on Rails plugin rails railtie

With the official Rails 3 release on the horizon, all of the edge features we have been hearing about for over a year are about to become the new standard, and it has definitely been worth the wait. One of the primary goals of the "big refactor" has been to modularize Rails to allow other frameworks to easily extend or entirely replace any of the previously "critical" components (ActiveRecord, ActionMailer, etc). At the centre of all this, is the new Railtie logic, which pieces all of these modules together.

Getting started with Railtie

The documentation for Railtie is a great place to get started, but the interesting observation is that each of the major Rails components (Action Mailer/Controller/View/Record) is itself a Railtie, and Rails as you know it is simply pieced together by requiring all of the independent components. Even better, if your plugin or gem needs to hook into the Rails initialization process, all you need to do is inherit from Railtie and you are ready to go!

So how does Railtie know to call your classes and initializers? Railtie defines a self.inherited method, which is called anytime a subclass of Railtie is created, and stashes a reference to this class in a @subclasses variable. From there, the framework can simply call Railtie.subclasses and perform all the initialization as usual - a clever use of the Ruby object model.

Creating a Rails 3 plugin: 0-60

As a result of the refactor, creating Rails 3 plugins is at least several orders of magnitude simpler. In fact, as a simple exercise, lets create a custom notification plugin to print all of the internal Rails logging by also hooking into the new Rails::Notification API:

> railtie-plugin.rb

module NewPlugin
  # namespace our plugin and inherit from Rails::Railtie
  # to get our plugin into the initialization process
  class Railtie < Rails::Railtie
 
    # configure our plugin on boot. other extension points such
    # as configuration, rake tasks, etc, are also available
    initializer "newplugin.initialize" do |app|
 
      # subscribe to all rails notifications: controllers, AR, etc.
      ActiveSupport::Notifications.subscribe do |*args|
        event = ActiveSupport::Notifications::Event.new(*args)
        puts "Got notification: #{event.inspect}"
      end
 
    end
  end
end

Believe it or not, that is a fully functional Rails 3 plugin, in 10 lines of code. Simply drop this file into your load path and require it in your application. In fact, you can bundle this file into a gem, ship it to Gemcutter and with the help of Bundler, all your users have to do is specify "gem 'ournew-plugin'" in their Gemfile, and the rest is taken care of. With a little more imagination, and fun, we can extend our example above into a 'slowgrowl' plugin, which will - you guessed it - growl at the developer anytime it detects a slow code path in your app! Hat tip to Gavin Stark for the idea.

Getting started with Rails 3

Railtie while an important piece of Rails 3, is hardly the only component worth looking into. Also read up on the changes in ActiveRecord, the new router, watch the summary screencasts on the Rails site, and make sure to check out one of the many great Railscasts on the topic by Ryan Bates. It has been worth the wait, Rails 3 is easily head and shoulders above the competition.