Explore Posterous

Avoiding some of the negative trade-offs in the template pattern with ruby's dynamicism?

So my buddy Tammer's recent post about the Gang of Four's Template Pattern reminded me of some code I saw recently. A start-up's greenfield project had it's authorization done in a pretty clean way using the template pattern. Basically every object determined what could be done to it, something like this:

After continuing this approach to fully cover CRUD you make a straight-forward set of accessors that can be used to easily enforce permissions in the controller in a programmatic way (this project was using on of the inherited resourceful-controller plugins, so that was a big plus). The developer who implemented this commented that the trade-off for this simplicity was having to look in each individual model file to figure out what a user can do overall.

I figured I liked everything about this scheme except that trade-off, and since ruby is so dynamic, why settle for almost. Why not just reopen each class in the authorization file and add the methods. You still get the simplicity and encapsulation of having the model able to determine it's own permissions, based on it's state and methods, and there is still one place to look to review/change the permissions for the whole project:

Thoughts?

Loading mentions Retweet

Comment (2) »

Reminder - Switch your environment.rb gems to Gemcutter

GitHub just announced that since their move to Rackspace, they’ve completely disabled gem building (and it isn’t coming back). They’re hosting existing gems for about a year, but it’s probably a good idea to update your Rails apps before you forget.

Gemcutter is the new hotness in gem repositories, and is the new GitHub-recommended source for gems.

Here’s what you need to do:

Before:

After:

Note that on GitHub, the gems were prefixed with the GitHub username. On Gemcutter, the ‘canonical’ versions of gems often drop the prefix. Be sure to do a quick search on Gemcutter if you’re not sure.

Don’t forget to run rake moonshine:gems afterward if you’re deploying with Moonshine.

On a side note, Gemcutter is hosted on Heroku. I checked out Heroku when it first came out, and it has made an amazing transition from a gimmicky in-browser Rails editor to a full-fledged Amazon EC2-backed power hosting provider with unbelievably simple Rack app deployment. If you are still in the dark like I was up until recently, I highly recommend checking them out.

Do this before you forget, and remind your Ruby / Rails / Sinatra / Merb / etc. pals to do the same by retweeting this post! Or like, Google Wave it or something.

Loading mentions Retweet

Comment (0) »

Thoughts on the Aloha on Rails Conference (Part 2 of 2)

• Jim introduced a term called connascense, which for software design purposes means the way two pieces of code are coupled, or two things that have to change together when one of them changes, in order to preserve correctness. There are different degrees of connascence:
  • Connascence of Name (CoN): where two components use the same name to couple, such as passing named parameters within a hash, or using  the name of a method or variable to refer to the same thing.
  • Connascence of Position (CoP): where the order matters, such as the order of parameters in a method call, or where positions in arrays are hardcoded. The coupling can be made more robust by converting this down to CoN.
  • Connascence of Meaning (CoM): using values to mean something for the two components. (Like "404" error code means page not found). These can be assigned to constants to somewhat reduce to CoN, but even in the assignment of values to constants, there needs to be contranascence (where two components have to be different, in order to preserve correctness) between the values to that the same value isn't assigned to different constants that are supposed to be different.
  • Connascence of Algorithm (CoA): the two components depend on the same algorithm to work right. For example if there is a method that creates a checksum (add_check_digit) and a check method to verify that a checksum matches. Can DRY (don't repeat yourself) it out by having a separate method that does the algorithm, and having both these methods call that method. (CoA->CoN)

Loading mentions Retweet

Comment (0) »

Rails in a Nutshell

Loading mentions Retweet

Comment (0) »

Ryan Bates' re-make of the Rails blog app demo

An oldie but a goodie. Ryan Bates' (of Railscasts.com fame) excellent remake of David Heinemeier Hansson's original 15 minute Ruby on Rails blogging app demo.

Loading mentions Retweet

Comment (0) »

Revealing intent in your controllers with named_scope

I have been thinking lately about how many Rails controller actions I run into that are hard to read and do not reveal the actual intent of the person that wrote the software. This can be extremely frustrating for a developer working with code that they did not originally write.

Consider the following example:

We have an Article model that has an Article Type and belongs to a User. Any time a User creates/updates an Article, a Boolean "approved" attribute is set to false.

The Article migration file might look something like this:

class CreateArticles < ActiveRecord::Migration
  def self.up
    create_table :articles do |t|
      t.string  :title, :limit => 155, :null => false
      t.text :content, :null => false
      t.integer :user_id, :null => false
      t.integer :article_type_id, :null => true
      t.boolean :approved, :default => false, :null => false
      t.timestamps
    end
  end

  def self.down
    drop_table :articles
  end
end

So a simple requirement in this case might be for the site Administrator to be able to "approve" articles. The business refers to unapproved articles as "pending". To do this, we would need to find all of the Articles that have an "approved" value of false. We would also need to order the results by date to return the most recent article changes first.

Here is an example of how one could accomplish this query in the controller:

class PendingArticlesController <  ApplicationController
    def index
        @articles = Article.find(:all, :include => [:user, :article_type], :conditions => ["approved = ?", false], :order => 'updated_at DESC')
    end
end

There is nothing really wrong with the above find but there are a few things we can do to improve the code by revealing more intent and using the Projects Ubiquitous Language.

Enter named_scope:
From the Rails documentation, named_scope "Adds a class method for retrieving and querying objects. A scope represents a narrowing of a database query"

By using named_scope, we can refactor the controller code as follows:

Introduce named_scope into the Article model

class Article < ActiveRecord::Base
    named_scope :pending, :include => [:user, :article_type], :conditions => ["approved = ?", false], :order => 'updated_at DESC'
end

We can now update our controller code to use our new named_scope

class PendingArticlesController <  ApplicationController
    def index
        @pending_articles = Article.pending
    end

end

This is much better! Now we have a very simple controller action which is easy to read and understand at a glance. We have also moved the find logic into the Article, which is where it belongs.

While this is a very simple example, consider a controller action with many lines and very large find statements. These can become very difficult to understand and hard to maintain.

Loading mentions Retweet

Comment (0) »

Thoughts on the Aloha on Rails conference (Part 1 of 2)

Loading mentions Retweet

Comment (0) »

Case-Insensitive LIKE with ActiveRecord

Loading mentions Retweet

Comment (0) »

SD Ruby talk - Deploying Rails apps with Moonshine

Here are the slides from my Moonshine talk at SD Ruby. I’ll update it with video of the presentation once it goes up on the SD Ruby Podcast.

Loading mentions Retweet

Comment (0) »

Encrypting Data in your Ruby on Rails Application

Whilst searching for a gem/plug-in to help with storing encrypted notes in a Rails app, I found strongbox. It uses public key encryption to encrypt and store data on a ActiveRecord attribute - Spike has a great writeup on his blog. One limitation I encountered was that it only uses one key to encrypt the data, which wasn't going to work when I have multiple users, all storing private information.

So I wrote a wrapper around strongbox that I am releasing called Safe - a Rails engine for storing encrypted data. Safe handles the generating of the public and private keys and uses strongbox to encrypt and decrypt the data. It's still in early stages, and it doesn't support all of the options that strongbox does, but it is on the TODO list.

So let me know if you find it useful and don't forget to symlink the keys directory in your deployment scripts!

Bit Zesty - Ruby on Rails developers in London.
 

Loading mentions Retweet

Comment (1) »