Ryan's Scraps

I was talking with a friend of mine last week about the new Rails deprecation warnings that you’ll see when you do naughty things like access @cookies from your controller or use deprecated methods like ActiveRecord’s find_all. Sometimes it’s useful to turn off those warnings – especially when they’re coming from a part of your application you don’t control (i.e. a third-party library).

To turn off all deprecation warnings, just do the following:

ActiveSupport::Deprecation.silenced = true

Or, if you want to perform something other than spit out deprecation warnings you can re-route them however you want within a block:

ActiveSupport::Deprecation.behavior = Proc.new { |msg, stack| MyLogger.warn(msg) }

Or, if you want to be more granular, you can silence specific parts of your code that you know reference deprecated code:

def bad_action
  ActiveSupport::Deprecation.silence { p "Referencing #{@cookies} is bad" }
end

Hopefully this will get you past any annoying deprecations you can’t do much about (without giving you an easy out for those that you can do something about).

Much of the beauty of ActiveRecord associations is in the collection methods that are provided for you when you define has_many relationships.

For instance, when we say:

class Organization < ActiveRecord::Base
  has_many :people
end

We now have an organization.people method that returns the collection of associated people within the organization. Easy enough. We also get nice little methods on the collection of people like organization.people<<, organization.people.build, organization.people.create and organization.people.find (among others). Well what if you wanted to define your own method on this auto-magically provided collection method? You do this through Association Extensions which let you define methods to add to the collection. You can define an association extension either with a block or a module – we’ll use a block provided to the has_many call here as it’s the most common way to do so:

class Organization < ActiveRecord::Base
  has_many :people do
    def find_active
      find(:all, :conditions => ["active = ?", true])
    end
  end
end

I’ve defined a find_active method which will retrieve all people in the organization that have the active column set to true. This can be invoked very intuitively with:

organization.people.find_active

This is a great way to provide convenience finder methods for common retrievals on the associated collection.

If you want to define an extension as a module just provide the :extend option in your has_many definition:

module FindActiveExtension
  def find_active
    find(:all, :conditions => ["active = ?", true])
  end
end

class Organization < ActiveRecord::Base
  has_many :people, :extend => FindActiveExtension
end

You can customize to your heart’s content – these are just some simplistic examples of how to plug into this nifty feature. I just recently stumbled upon it and thought it might be worth spreading the word since I found myself smitten by it.

Resources

• Josh Susser’s New association goodness in Rails 1.1, part 2
• Association Extension API docs

tags: rails, activerecord, rubyonrails

It’s pretty obvious what phase I’m at with my app given my recent postings: that’s right, figuring out an appropriate caching strategy.

It seems as though I’ve run across another nuance with caching – if you use the “caches_page” method in your controller for an action that is invoked via XMLHttpRequest (i.e. via AJAX), it won’t get cached. For instance, building on my last issue:

class UsersController < ApplicationController

  caches_page :find, <b>find_simple</b>

  def find
    @user = User.find(params[:id)
  end

  <b>def find_simple
    @user = User.find(params[:id])
    render(:action => 'find', :layout => false)    
  end</b>

end

The “find_simple” method is the action that will be invoked via AJAX and, despite the caches_page directive, it does not get cached. A look at the logs reveals this, as does a look at the cache directory on your filesystem (there will be no users/find_simple/id.html).

The solution is pretty simple, use “caches_action” instead of “caches_page”:

class UsersController < ApplicationController

  caches_page :find
  <b>caches_action :find_simple</b>

  def find
    @user = User.find(params[:id)
  end

  def find_simple
    @user = User.find(params[:id])
    render(:action => 'find', :layout => false)    
  end

end

The ramification of this switch is that now all your action filters will get executed for every request. However, as AJAX calls are usually pretty lightweight, action caching should be quite sufficient.

I know the “caches_page” method adds an ‘after’ filter to the controller for each of its actions – this issue seems to imply that the filter is bypassed when a request comes in via XMLHttpRequest. It would also imply that the app server/RoR knows the difference between a ‘normal’ request and an XMLHttpRequest one – which is not what I would have expected. Anyway, no skin off my back as the solution is quite reasonable.

See Luke’s official announcement of the initiative

This isn’t something that’s new to Rails, the framework, but since it’s living within the official Rails repository, I feel compelled to represent.

Looks like there’s an official Rails plugins repository in the works. Judging from comments on one of my previous posts, the community definitely recognizes this as a need. (What, the plugins wiki not good enough?) It’s good to see some effort being placed into the organization of the larger Rails eco-system, and not just Rails itself.

On a side note, what’s that other little ditty in the application path of the repository? Molecule, a RESTful blogging app?

Do tell, David, do tell…

tags: rails, rubyonrails, rails plugins

I’m sitting in the middle of the Relevance guys’ presentation on the Streamlined Framework for the Raleigh Ruby Brigade right now – and I’m intrigued.

Most people have caught wind of Streamlined’s recent release but, if you’re anything like me, you haven’t really had a chance to dig into it or really understand what it’s about. Just so you hear it from another angle, here’s my take: Streamlined provides generation of domain administration views with strong support for the recognition of intra-model relationships. Tada.

Running script/generate streamlined user roles permissions gets you a rich administration portal that lets you browse/edit/query your user, roles and permissions models – and does so in a way that recognizes your domain model’s associations. If your appetite has been appropriately wetted (is that a word?), check out their screencast.

If you have visions of wading through streamlined’s generated views to customize and update options, fear not. Streamlined represents rendered views as a model class – i.e. UserUI for the User model etc.. This means that this code:

class UserUI < Streamlined::UI
  # Don't display the user's password in the view, but do
  # display their id
  user_columns :excludes => [:password], :includes => [:id]
end

Is all you have to do to adjust how Streamlined renders the user management view. (Obviously, there are several more options available…) The beauty in this is that this UI model is much less fragile to future upgrades, is very concise and just feels right. This is the part of Streamlined that excites me most.

Streamlined is an impressive solution to the problem of CRUD-based domain administration.

Streamlined, check it out.

And there’s an open call for designers to help out with the styling of the app – it’s a definite need so pitch in if you can

tags: rubyonrails, rails, streamlined, streamlinedframework

Rails v1.1.4 is now out, fast on the heels of the Rails v1.1.3 security fix.

official announcement

tags: rails, rubyonrails

An intern of mine took it upon himself to build this very complete Rails Engines guide. On behalf of everybody who has struggled to find good engines documentation, I say ‘Thanks Joe!’.

From the “I didn’t know this existed but now that I’ve found it I will use it more often file” – did’cha know you can actually unit test your routes using the assert_routing assertion?

Assuming a vanilla people_controller and this routes.rb:

map.connect '/:id', :controller => 'people', :action => 'show', :nother => 'woohoo'

You can test routing in your people_controller_test functional test with:

assert_routing "/#{model.id}", :action => 'show', :id => model.id, :nother => 'woohoo'

Good to know…

It was pretty clear after my last post that there are some good options when it comes to Rails hosting (and there are some having a few issues – hopefully all temporary). So after checking it all out, I’m going to start out with Planet Argon, which makes me an argonaut, er planetonian, er planaliscious argoharrian? Anyway, if you can get past their very 1995-ish sign-up process (snail mail or fax the hosting agreement and no way to enter a credit card into a web form), it’s all good. Great personal service and you can always find help on their IRC channel. Their startup documentation is still very much a work in progress (i.e. I can’t find any) which forces you to be somewhat intelligent and figure stuff out on your own. But when Robby (the techie-owner) is always a stone’s throw away on IRC, that’s not an issue. Thanks to all those who commented on the original post, it turned out to be quite an active discussion.

If you sign up yourself and want to throw me a bone, put me down as your referrer. It will make me happy, which makes me happy.

I’ve been waiting for the fictitious Rails App Hosting to get off the ground for awhile now and have come to the realization that, in the name of expediency, I may need to look at some other options. Gauging by the amount of chatter and the “I just think your website looks legit” factor it certainly seems that Textdrive is the big daddy in town while Planet Argon is the smaller but still quite active player in the Rails hosting space.

So the question becomes, does anybody have any strong opinions between the two services, or even more ideally, has anybody hosted on both and can give their overall opinion? My main priorities are ease of setup and configuration, tech support and scaleability…

Like most people that have recently jumped on the Ruby on Rails bandwagon (or at least given it a try), one of the first things I did was read the Ruby on Rails book and jump into developing my own web app. Well, here I am a few months later looking at my initial version of the app – and I am completely disappointed. The code is crap – it’s inelegant, somewhat procedural and completely un Ruby-like. And I blame it all on Ruby on Rails.

You see, in my rush to stay with the hype I’ve jumped into Ruby on Rails without spending due time learning Ruby. I suspect many people have done the same thing and what you will begin to see is a dilution of the talent in the Ruby community as more people come into the language the wrong way – through RoR.

It’s not a bad thing that Ruby on Rails has brought exposure to Ruby, but it’s obscuring the language itself which is unfortunate. In an attempt to rectify my mis-education I have taken a step back and am starting to explore the language before proceeding on with more RoR. Until developing with Ruby becomes intuitive to me I shouldn’t be working w/ RoR. I mean how many people successfully learn Java by learning Struts first?

My hope is that I am amongst the minority, but I suspect there are others who have made the same mistake as I have.

I’m posting this more as a personal reminder than anything else – so go elsewhere if you’re looking for true wisdom:

How to reload my controllers and model while running in Rails’ handy script/console utility:

reload!

or

Dispatcher.reset_application!

The differences between the two I do not yet know (and now I do – thanks to Curt’s comment – reload! just calls Dispatcher.reset_application!)

References:

• courtenay: script/console reload models
• RailsWiki: Console
• Stuart: The Rails Console
• console source (thanks, Curt)

Caveats:

• Robby Russell: Where did my observer go?

tags: rubyonrails,rails

RubyCorner has come along and provided a great service to the Ruby and Rails community by essentially taking over where PlanetRubyOnRails.org has stalled – providing Ruby related feed aggregation. I think this is great and RubyCorner is doing a great job with good functionality lilke favorites, blacklists etc..

However, does this mean that PlanetRubyOnRails is essentially dead? I can’t find anywhere to add or suggest a feed (that works). Maybe you have to be one of the Ruby elite to have a spot on the planet… It would be nice to see the service propped up a little better though – there’s got to be space for two such sites.

rubyonrails,rails,rubycorner,planetrubyonrails

Apparently, our friends over at Slingshot have super-secret access to that elusive worm-hole and have procured Rails v1.2!! Last I checked, 1.2 wasn’t quite ready for prime-time yet.

They tell me the acts_as_desired_application plugin is superb!

(Can’t be too hard on them though – they look like a nice replacement for the vapor-company RailsBase, are RailsDay sponsors AND have nice plans!)

tags: rubyonrails,rails,slingshot hosting

Smokin’ hot, that is (in the non-visual sense).

Joe puts his money where his mouth is and throws his hat into the Rails Engines ring with the new Help Engine.

In other news, the creation of a ‘HelpHelper’ rips a hole in the fabric of the cosmos, endangering millions.