cameronyule.com

For anyone working on a Rails application which deals with countries or languages, the official source of data is the International Standards Association, specifically ISO 3166 for countries and ISO 639 for languages.

To make it easier to get this data into your Rails application, I’ve created two generators which automatically create the models, migrations and data you’ll need and bundled them up in a handy Rails plug-in.

Usage couldn’t be simpler…

script/plugin install git://github.com/cameronyule/isodata.git

If you want country data…

script/generate countries
rake db:migrate
rake isodata:db:countries

…and for languages…

script/generate languages
rake db:migrate
rake isodata:db:languages

Check out the isodata project on Github.

There’s been a few posts lately on getting SWFUpload working with Rails 2.1, attachment_fu and the restful-authentication plugins.

To try and make things easier, I’ve made a sample - albeit basic - Rails application to show other people how I managed it.

I’ve created a project on Github to host it, feel free to check it out and let me know how you get on. The only instructions you should need are in the README file, but feel free to leave comments here if you do need a hand.

I’m pleased to announce the release of the first version of my Mailbuild API interface, which I’m distributing as a Rubygem.

To make it easier to figure out how to use it, I’ve also created a fully functional Rails application which demonstrates all the API calls available.

To use it all you have to do is grab a copy from subversion…

svn co http://mailbuild.rubyforge.org/svn/rails_mailbuild_example/

… make sure you have the mailbuild gem installed …

cd rails_mailbuild_example
# OS X/Linux users may have to prefix this with sudo
rake gems:install

… and edit config/initializers/mailbuild.rb, adding your own API key, List ID and sub-domain.

# You can get this information from your Mailbuild admin
Mailbuild.api_key = ''
Mailbuild.list_id = ''
Mailbuild.subdomain = ''

Hopefully that’s all there is to it, but if you run into any problems feel free to add a support request or bug report on Rubyforge.

UPDATE: I’ve since stopped using this method. While it did allow for everything short of library files to be reloaded between requests, making the development process far less painful, I ran into a problem with ActiveRecord where deeply-nested (3 associations) models were behaving strangely on reload (they’d work fine first time, but not afterwards).

Since moving to Rails/Engines 2.1, I’ve been irritated with having to restart Mongrel each time I make a change to a controller or model in my engine. This wasn’t an issue in Engines 1.2 as it had a load of custom initialisation code, but with 2.x moving closer to the way Rails itself works - see this post on the rails plugin initialization process by Rick Olson for more details - it’s become a problem.

Unfortunately the solution Rick proposed in his post wasn’t working for me, but a thread on the Engines development mailing list has provided a solution - add the following to the init.rb file of your engine and you’ll no longer have to restart your web server to see changes in your files.

I’ve wrapped the code in a check to see if we’re running in the development environment, as in the majority of cases you’ll want things to work as normal in production.

if Rails.env == 'development'
  Rails::Plugin.class_eval do
     def reloadable!
       load_paths.each { |p| Dependencies.load_once_paths.delete(p) }
     end
  end
 
  reloadable!
end

After the announcement yesterday that Rails 2.2 will have support for internationalisation (i18n) in the core, I read the linked articles and was slightly surprised that rather than unifying/replacing the i18n plugins currently available, it will actually provide an API which makes creating a back-end for handling your locales easier.

I’ve been using Globalite in the Rails project I’m working on and while it’s the best solution I’ve tried, I was always frustrated by the use of YAML for it’s locale files. Thankfully the changes in Rails 2.2 will likely mean a move to pure Ruby locale files, introducing the benefits of namespaces and the ability to override/extend generic files with site-specific ones.

Now we just have to wait a few months for the release and see what plugins adapt/appear to take advantage of it.