SXSWi Why the Lucky Stiff – Ruby on Rails Podcast


This post is by Ruby on Rails Podcast from Ruby on Rails Podcast


Click here to view on the original site: Original Post




A bootleg of the Why the Lucky Stiff concert at the South by Southwest Interactive Festival.

SXSWi Why the Lucky Stiff – Ruby on Rails Podcast


This post is by Ruby on Rails Podcast from Ruby on Rails Podcast


Click here to view on the original site: Original Post




A bootleg of the Why the Lucky Stiff concert at the South by Southwest Interactive Festival.

SXSWi Shaun Inman – Ruby on Rails Podcast


This post is by Ruby on Rails Podcast from Ruby on Rails Podcast


Click here to view on the original site: Original Post




Popular designer and PHP developer Shaun Inman tries Ruby and talks about developing Mint.
See him in Boston next month at a Carson Workshops seminar on developing extensible PHP web apps.

SXSWi Shaun Inman – Ruby on Rails Podcast


This post is by Ruby on Rails Podcast from Ruby on Rails Podcast


Click here to view on the original site: Original Post




Popular designer and PHP developer Shaun Inman tries Ruby and talks about developing Mint.
See him in Boston next month at a Carson Workshops seminar on developing extensible PHP web apps.

Bruce Tate – Ruby on Rails Podcast


This post is by Ruby on Rails Podcast from Ruby on Rails Podcast


Click here to view on the original site: Original Post




Bruce Tate has created a stir in the Java community by promoting Ruby.
His books include Beyond Java and the upcoming Ruby on Rails, Up and Running.

Bruce Tate – Ruby on Rails Podcast


This post is by Ruby on Rails Podcast from Ruby on Rails Podcast


Click here to view on the original site: Original Post




Bruce Tate has created a stir in the Java community by promoting Ruby.
His books include Beyond Java and the upcoming Ruby on Rails, Up and Running.

Managing Rails Plugins dependencies


This post is by Daniel Wanja from onrails.org


Click here to view on the original site: Original Post




Rails has a nice plugin system allowing to add common code to a project. A plugin should really be independent from any other plugins. But we also use plugins to share code among different projects we are working on and our code depends on existing plugins. The Rails development team want’s to keep the plugin system simple and didn’t provide an explicit way to handle these dependencies, which I believe is a good decision. There is a solution. Simply name the plugins in order off the dependencies you have. Let’s assume you want to add “my_very_own_plugin” plugin that depends on the enumation_mixin, then simply organize the /vendor/plugins folder as follows, et Voila!:.

/myrailsapp
    /vendor
        /plugins
            /01_acts_as_taggable
            /01_enumations_mixin 
            /01_acts_as_versioned
            /02_my_very_own_plugin

If we look at the Rails::Initializer we can see why this works. Note, this is only an extract of the full class that Rails provides to bootstrap your rails applicaton. The sort on line 4 here after allows this trick.

module Rails
class Initializer
def load_plugins
find_plugins(configuration.plugin_paths).sort.each { |path| load_plugin path }
$LOAD_PATH.uniq!
end
end
end