Rick being really busy with ActiveReload he didn’t spend too much time maintaining attachment_fu.

On my side of things, I’ve been using attachment_fu on a lot of projects and I’ve been fixing bugs and adding new features.

My first contribution to attachment_fu is a fix for the ImageScience processor.

Attachment_fu is very flexible and let you use your favorite image processor:

• RMagick based on ImageMagick and GraphicsMagick(known to leak memory and being a pain to setup)
• minimagick based on ImageMagick
• ImageScience based on FreeImage.

Like many rubyists, I like ImageScience for its simplicity and efficiency. However, attachment_fu had few problems when being used with ImageScience.

• File sizes for thumbnails were not saved correctly in the database. Fixed
• Thumbnails based on a gif files were not processed properly. So, this was the big problem. FreeImage has issues dealing with resizing gif files because of the gif palette limitation (256 colors). to avoid this problem thumbnails of gif files are converted to png. However the thumbnail content type info in the database was not saved properly. That’s now fixed.
• Because of the gif bug reported above, any thumbnail link was broken since it was trying to link to the thumbnail version with a gif extension instead of a png one. Fixed

I also fixed a small bug related to S3 storage and the fact that a_fu had issues loading the config file. (Fixed)

I’ll also try be able to add some of the S3 features I’ve been working on. As well as maybe enhancing the validation process.

In the mean time, you might want to read this blog post about better validation with attachment_fu.

If you are heavily using attachment_fu or starting using it and think that a google group would be great idea, please let me know in the comment and I’ll try to convince Technoweenie that we need to set that up

Ooohh I almost forgot, if you fixed some bugs you found while using afu, please contact me so we can get afu bug free.

check out the plugin page

File structure will look like that:

I use this plugin to backup my apps running in production. When I need to debug an application, I just need to restore the db locally and debug. The fact that it uses fixtures helps me finding data quickly and I can easily decide to only restore few tables.

I also have a Capistrano recipe to create backups before each deployment.

oohh and the plugin is Sake compatible, give it a try

Enjoy

I have a set of RSpec examples I use all the time on all my projects requiring restful_authentication, obviously I always end up tweaking them because each application has its specific needs.

However, I was recently asked what’s the way of dealing with controllers specs when a controller has a limited access ?

Let’s look at the following controller for instance:

class AssetController < ApplicationController
 before_filter :login_required, :except => [ :index, :show ]

my assets_controller_spec.rb file will have the following code:

describe AssetController, "handling GET /assets/new" do

  before do
    @asset = mock_model(Asset)
    Asset.stub!(:new).and_return(@asset)
  end

  def do_get
    get :new
  end

  it "should be successful" do
    do_get
    response.should be_success
  end

end

and guess what… it will fail! Why? simply because we are trying to access an action requiring login. Right, so what’s the best way of dealing with this issue and get our test to pass?

The best solution I found was to use a simple helper that I put in my spec_helper.rb file

def login_as(user)
  case user
    when :admin
      @current_user = mock_model(User)
      User.should_receive(:find_by_id).any_number_of_times.and_return(@current_user)
      request.session[:user] = @current_user
    else
      request.session[:user] = nil
  end
end

You might wonder why I use when :user, well, in a lot of the application I’m working on, I have different levels of access and I want to tests different accounts so I the case conditional loop.

Anyway, let’s implement our helper in our previous RSpec example:

describe AssetController, "handling GET /assets/new" do

  before do
    login_as :admin
    @asset = mock_model(Asset)
    Asset.stub!(:new).and_return(@asset)
  end

  def do_get
    get :new
  end

  it "should be successful" do
    do_get
    response.should be_success
  end

end

and there you go, now your example passes properly

Have fun

However, it’s a heavy, bloated, hard to setup plugin. I might seem to complain, but I’m actually glad that someone came up with a decent solution. Globalize is quite powerful but I would like to see something simpler, lighter and easier to use.

While I was looking for alternate solutions, Err released Gibberish a simple and nice localization plugin.

Looking at Chris’ code, I found a clean and nice solution but unfortunately too simple. The major problem I had with Giberrish was the lack of support for locales. That means that one cannot create an application supporting British English and American English. I lived in both America and the UK and believe me, I can never spell some words properly. How should I spell the following words: colours or colors, behaviour or behavior, aluminium or aluminum? On top of that, your UI might be slightly different based on the region your visitor is coming from. Localization is more than translation.

Anyway, I decided to come up with my own solution, a breed of the best features from my favorite i18n/l10n projects. This hybrid solution should, hopefully be useful for people not needing all the resources of Globalize. I called my new project Globa_lite_

What’s cool with Globalite?

• Simple UI localization

  • support different locales
  • yml file based
  • simple syntax
  • no setup needed
  • enough for most projects needing localization
  • pass variables to the localization and let the translator deal with it

• Simple Rails Localization

  • support different locales
  • nothing to do, rails comes in your own language (including currency conversion and other helpers)
  • yml file based localization for easy update
  • support for Rails 1.2x
  • simple to maintain
  • simple to add/edit a new locale

• Simple content i18n/l10n (coming soon)

UI localization:

• Create a lang/ui folder at the root of the folder.
• create 2 localization files: fr.yml and en-US.yml
• add localization keys in the files:

fr.yml:

hello: bonjour

welcome: bienvenue

en-US.yml

hello: howdy

welcome: welcome

• Declare the current locale or language

  Globalite.current_language :fr
  

• In your view (or anywhere else) localize a key

  :hello.l
  

or

:hello.localize

you can also do

:unknown_key.l("this is the default text to display if the localization isn't found")

Also you can pass one or many variables to the localization(check the documentation)

Rails Localization

Rails is automatically localized for you (meaning most helpers, including the currency converter are localized for the locale you declared).
You really easily add a new supported rails language/settings by adding a yml file or editing an existing one. (for now, I only create an English and a French localization file, but I’ll add plenty more very soon)

Globalite also saves the locale in the session allowing many users to see a site at the same time in different languages

I believe Globalite is/will be a good solution for most of my international projects. It still lacks the content i18n and l10n as well as support for pluralization but it should be added soon.

Give it a try and let me know what you think:

RubyForge page

svn repository: svn checkout svn://rubyforge.org/var/svn/globalite/trunk globalite

view repository content

ps: The project is still in beta and will change during the next few weeks, feel free to submit patches, ideas, suggestions…

Instead of doing:

create_table :people do |t|
t.column :name, :string
t.column :age, :integer
end
You can now do:
create_table :people do |t|
t.name :string
t.age :integer
end

While this is great, I found out that someone came up with an even nicer way of creating your migration, actually, a sexier way of doing migrations, and we all like sexy, don’t we? Otherwise we would not use Rails, would we?

Anyway thanks to this new plugin, your old Migration:

class UpdateYourFamily < ActiveRecord::Migration
  create_table :updates do |t|
    t.column :user_id,  :integer
    t.column :group_id, :integer
    t.column :body,     :text
    t.column :type,     :string

    t.column :created_at, :datetime
    t.column :updated_at, :datetime
  end

  def self.down
    drop_table :updates
  end
end

can look sexier than ever:
class UpdateYourFamily < ActiveRecord::Migration
create_table :updates do
foreign_key :user
foreign_key :group

    text   :body
    string :type

    timestamps!
  end

  def self.down
    drop_table :updates
  end
end

Note that I didn’t test the code above and the self.up method seems to be missing, for more information, check the official post to give it a try:
./script/plugin install svn://errtheblog.com/svn/plugins/sexy_migrations