Ruby on Rails Planet

..and on the seventh day, Science created zsh »

Created at: 31.08.2009 04:08, source: Robby on Rails, tagged: programming terminal osx linux console bash zsh git github commandline

Inspired by some recent posts from Tom on zsh, I decided that I’d do my part to help people give it a whirl. I’ve been using zsh for a few years now and haven’t found myself missing bash.

If you’re interested in taking a few minutes to give zsh a while, you’re in luck. I recently reorganized all of my zsh config into a package and tossed it on github to share. My goal was to create a reusable tool that would allow people to get up and running quickly with some of the fun configuration that I’ve come to rely on on a daily basis.

For example:

Auto-complete rake and capistrano tasks
Git branch names when you’re in a git project directory structure
Tons of color highlighting (grep, git, etc.)
Sexy prompts.. (so say me)
much much more…

I invite you to give Oh My Zsh a whirl, which should take you less than a minute. Just follow the instructions.

Also, Oh My Zsh is Snow Leopard compatible. ;-)

So long and thanks for all the hoodwinks »

Created at: 20.08.2009 08:24, source: Robby on Rails, tagged: Ruby on Rails ruby programming _why hoodwinkd nostalgia

_why,

If you’re out there and come across this… know that one of my fondest memories on the internet was with you. Hoodink.d was one of the greatest things on the internet four years ago and I suspect that a very tiny fraction of the Ruby community has even heard of it.

Fortunately for me, I have a copy of the hoodwink git repository and was able to get it running tonight in hopes that I might find you lurking in the mousehole. I’m convinced that you are in a parallel internetverse. Perhaps you might send me an invite.

I miss hoodwink… and if you stay missing, I’ll just miss hoodwink more.

In the meantime, I wonder how hard it’ll be to get hoodwink to run on rack.

Wink you on the other side, Robby

p.s. you can find me in my own mousehole… should you want to send me an invite and/or feed me cheese.

Thank you hoodwink.d

ActiveRecord refererential integrity is broken. Let's fix it! »

Created at: 19.08.2009 03:21, source: Rail Spikes - Home, tagged: programming activerecord

ActiveRecord supports cascading deletes to preserve referential integrity:

123	class User has_many :posts, :dependent => :destroyend

But you really only want cascading deletes about half the time. The other half, you want to actually restrict deletion of a record with dependencies. ActiveRecord doesn’t support this.

Think of an e-commerce system where a user has many orders. Once an order has gone through, you shouldn’t be able to delete the user who placed the order. You need a record of the order and the user who placed it.

Or even more obvious, think of a lookup table. An Order might have several of these dependencies; OrderStatus, Currency, DiscountLevel, etc. In all of these cases, you want ON DELETE restrict, not ON DELETE cascade. But Rails doesn’t support this. That’s dumb.

If you agree, head on over to the Rails UserVoice site and make your opinion known! There is a ticket for this already. Vote it up if you think Rails should implement this.

The solution to the problem is really pretty simple. ActiveRecord just needs something like this:

123	class User has_many :posts, :dependent => :restrictend

In this case, if you try to destroy a user that has one or more posts, Rails should complain. You’ve told the app: “Don’t let me delete users who have posts!” The easiest way to do this is to have Rails throw an exception, and have your controller capture the exception and print a flash message. Other approaches could work too.

So why is this important?

1. It’s common. Every project should maintain referential integrity in some way, and :dependent => :destroy isn’t always appropriate. Who wants to do a cascading delete from roles to users, or manufacturers to products, or order_statuses to orders? I don’t think I’ve ever worked on a project where cascading deletes were always appropriate. Any lookup table, at minimum, needs this feature. (I personally prefer to maintain referential integrity with foreign keys, but even still, I’d love to have an application-level check first, which would be easier to rescue. And some projects don’t use foreign keys.)

2. It fits with the Rails philosophy. Rails says “Let your application handle referential integrity, not the database”. But without :dependent => :restrict, one of the most important pieces of referential integrity is missing.

3. It’s easy. 9 lines of code to add this to has_many. Check out this gist: http://gist.github.com/170059.

Someone wrote a plugin for this, but it has the distinct disadvantage of not working anymore. This should really be a core feature anyway, at least as long as :dependent => :destroy is a core feature.

The UserVoice suggestion for this is at http://rails.uservoice.com/pages/10012-rails/suggestions/103508-support-dependent-restrict-and-dependent-nullify.

Rails 2.3.3 upgrade notes: rack, mocha, and _ids »

Created at: 29.07.2009 20:38, source: Rail Spikes - Home, tagged: programming rails2.3.3

I upgraded two apps to Rails 2.3.3 today. It’s a minor release, and there’s not much to report. But I did run into three minor problems.

Mocha

Mocha 0.9.5 started throwing an exception:

NameError: uninitialized constant Mocha::Mockery::ImpersonatingAnyInstanceName

A quick update to Mocha 0.9.7 cleared this up.

Array parameters in tests

In functional tests with Test::Unit, passing an array to a parameter stopped working. Previously, I had something like this:

post :create, :user => {:role_ids => [1,2,3]}

This would post the following parameters:

"role_ids"=>["1", "2", "3"]

But after the 2.3.3 update, I started seeing an error:

NoMethodError: undefined method `each' for 1:Fixnum

I’m not sure why this stopped working. (Anyone know?) Changing the integers to strings clears up the error:

post :create, :user => {:role_ids => ["1","2","3"]}

post :create, :user => {:role_ids => [1.to_s,2.to_s,3.to_s]}

Rack

Rack apparently no longer comes bundled with Rails. Or at least deployment failed on cap deploy: RubyGem version error: rack(0.4.0 not ~> 1.0.0).

The solution was simple: install (or vendor) Rack 1.0.0.

config.gem 'rack', :version => '>= 1.0.0'

Launching Rails projects, an open call for lessons learned »

Created at: 23.06.2009 20:33, source: Robby on Rails, tagged: Ruby on Rails ruby programming launching rubyonrails tips conference rails lessons

I’m working on my presentation for Rails Underground and was hoping to solicit a few tips from other people in the industry.

Have you launched a Ruby on Rails application recently? Are there some things that you wish you had known beforehand?

Mind sharing? You can email me with your story at robby+launchstory@planetargon.com. I’ll let you know if your tip gets used in the presentation and please indicate if you’d be okay with me posting your tip in a future blog post.