Archive for the ‘Technology’ Category

Rails 3: lib directory files now need to be manually required

Tuesday, July 27th, 2010

Today Rails 3 Release Candidate was released. I upgraded the application I’m currently building and to my great displeasure discovered:

active_support/inflector/methods.rb:124:in
`block in constantize':
uninitialized constant [class] (NameError)

Turns out the custom library files you write and store in the ‘lib’ directory of your app are no longer automatically included on application boot. Luckily the fix is simple. In your Application.rb configuration file add the following line to automatically load all ruby files in the ‘lib’ directory:

Dir.glob("./lib/*.{rb}").each { |file| require file }

Hopefully this can save someone time and frustration.

—————–
now playing : Jes – Ghost

Rails 3 howto: restricting named routes to specific http methods

Thursday, June 10th, 2010

Migrating my project’s codebase to Rails 3 beta from Rails 2.3.x was fairly painless except for the changes to the router.

Most files only needed a few changes, but my highly customized routes.rb file was a four hour ordeal that I hope this post can help save someone else time as Rails 3 documentation for declaring methods for named routes is sparse at best right now.

The premise of what my app needs to have happen is the RESTful routes that are automatically created by scaffolding need to be modified to live at my domain’s root without relying on any web server tricks. For the rest of this post let’s focus on just one of these overrides: the “new” verb for the “events” controller.

Default route created via scaffolding is:

http://domain.com/events/new

However, I want the new_event helper to point to:

http://domain.com/new

In Rails 2.3.x this is accomplished via declaring a named route with a conditions statement restricting to only ‘GET’ requests:

map.new_event 'new.:format',

:controller=>"events",

:action=>"new",

:conditions => {:method => :get}

In Rails 3, the new way to do named routes looks like:

match 'new(.:format)' => 'events#new',

:as => 'new_event'

Seems simple, but when the conditions statement restricting to only the ‘GET’ method is added it’s ignored.
The following does NOT work:

match 'new(.:format)' => 'events#new',

:as => 'new_event',

:conditions => {:method => :get}

In Rails 3 the ‘method’ condition is ignored by design because the proper way to limit the named route override to a specific http method is:

get 'new(.:format)' => 'events#new',

:as => 'new_event'

The beginning keyword can be any one of the http methods: get, post, put, or delete

Pretty sexy to say the least!, just wish it was better documented. Hope this helps others out.?

—————–
now playing: Hans Zimmer & James Newton Howard – Molossus

Howto fix mysql gem not working with Rails 3 (OS X Snow Leopard)

Monday, June 7th, 2010

I ran into a problem where the MySQL gem would install properly but when I went to migrate my database it would fail with the following error:

Please install the mysql gem and try again: gem install mysql. rake aborted! no such file to load — mysql

It turns out that database gem requirements should be declared in the project’s Gemfile. Add the following line to the Gemfile:

gem ‘mysql’, :require => ‘mysql’

Then in the top directory of your rails application run:

bundle install

You should now be able to migrate your MySQL databases.

The technical change in Rails 3 that requires this extra step is that the bundler reads the gemfile and then creates links in either the [application directory]/.bundle directory to the system gems, or alternativly downloads and installs them into the [application directory]/.bundle directory.

The concept is to allow gems to be installed per project that do not need to be installed system-wide in the system gem repository. This helps to reduce version collisions and duplications. Both of which are highly important now that rails 3 allows multiple rails applications to live together.

—————–
now playing: TiĆ«sto Feat. Maxi Jazz – Dance4Llife

Howto fix Rails apps not deploying on Glassfish v3 from Netbeans

Thursday, February 11th, 2010

If you are developing Ruby on Rails apps using Netbeans and deploying to Glassfish, and suddenly your apps (& even the demo Depot app) refuse to deploy on Glassfish V3 it may be do to an incompatibility between Rails version 2.3.5 and version 1.1.0 of Rake.

The solution is to maintain using Rails version 2.3.5 but to role back to version 1.0.1 of Rake. In Netbeans you can do this by going to Tools -> Ruby Gems -> Installed and then selecting Rake and clicking uninstall. Do not select the default settings, but rather select 1.1.0 from the drop down menu to only remove that version. If 1.0.1 is not listed in this drop down then go ahead and select to uninstall all versions, and then install version 1.0.1 of Rake or reinstall Rails 2.3.5 as it will install Rake 1.0.1 as a dependency.

I’m hoping this will save others the four hours of my life I wasted trying to figure out what went wrong with my Ruby on Rails development environment.

—————–
now playing: The Doppler Effect – Beauty Hides in the Deep (Envotion Remix)