The following is a guest post from Dan Simard

Sometimes, you have to reinvent the wheel. It’s really sad to say and you will probably hate me for saying that (and I know that you’ll do because I hate myself for it). I’ve written a new globalization plugin for Rails.

Why did I reinvented the wheel?

I searched and tried a lot of other globalisation plugins… and I really tried them. I spent hours with Globalize. It was just too much. I tried the gettext_Localize that works with the good ol’ gettext command. Fuck it. Too complicated. It just didn’t fit my needs at all.

All I wanted was a wheel that you can put a wood-pole in the middle and then it could start spinning. I made one.

You can go on the simplyglobal project homepage to learn on to install it and use it.

In fact, this is not really a globalization plugin because there’s no localization handling or anything that can look like it. The name should have been simplytranslated but I already created the project with the name simplyglobal and it was an hassle to change it.

How to install

1. Execute ./script/plugin install http://simplyglobal.googlecode.com/svn/trunk/simplyglobal
2. Create a file named simplyglobal.rb in the config/initializers directory
3. In simplyglobal.rb, create hashes of language
Add the language hashes to the objectYou will end up with a file named simplyglobal.rb that looks like this :

In development, this file will be loaded every request. In production, it is loaded once.

How to use it with strings

After you installed it, you can use it in these various ways.

SimplyGlobal adds a t() method to all string objects that will return the translated string. Example, if you have defined a language hash that looks like this (note : normally, the languages hash are defined in config/initializers/simplyglobal.rb but I put it inline for the sake of the example) :

As simple as that!

You can use it like the % method of the String class.

You can also return all translations for a word. That is a special feature developed only for Frank.

Using it with views

Just create a view ending with _fr and simplyglobal will use it.

It also works for the partial.

will try to render _info_fr.html.erb rather than _info.html.erb.

Georges Brassens
- Les filles quand ça dit “je t’aime”, c’est comme un second baptême
- Aucune idée sur terre n’est digne d’un trépas

Billie Holiday
- Don’t threaten me with love, baby. Let’s just go walking in the rain.
- I never hurt nobody but myself and that’s nobody’s business but my own.

Assuming your recordset is ordered by author, you do something like this (remember, we’re in 1999) :

Ok welcome back in 2008. ASP is dead. You are coding in rails and you want to do the same thing. How will you do it? Storing the author name in a buffer variable like in 1999? Not too sure about it.

This is a job for Enumerable#group_by (Enumerable is a module that is mixed in the Array class)

Enumerable#group_by will create different sets of quotes based on the “author” values. Why the “&” sign? It’s because group_by expects a block. I could have done it this way : @authors = all_quotes.group_by{|quote| quote.author}

So @authors is now a hash that will look like this:

{”George Brassens” => [#<Quote id:131 …>, #<Quote id:331 …>], “Billie Holiday” => [#<Quote id:111 …>, #<Quote id:911 …>] }

Now you can iterate over it like this :

One more thing to note : @authors is a hash, and hashes cannot be ordered. If you want to display quotes by sorted author name, you could do this :

Note : Enumerable#group_by does not exist in ruby 1.8, it only exists in Rails. The method will be in ruby 1.9 however.

Fortunately, version 0.4 has been released on August 5th 2008. We’re going to try this new version internally and eventually use it for TimmyOnTime. I am personnally hoping for less memory consumption, more speed and more stability. This new version highlights are :

1. The beginning of ruby 1.9 support
2. Refactoring of error classes (I’m really looking forward to this)

Here is the full changelog :

XMPP4R 0.4 (05/08/2008)
=======================
* Initial support for Ruby 1.9 (see README_ruby19.txt)
* Complete PubSub API Change - more logical and better for
childclasses, support for collection node creation
* a Helper to assist with XEP-0115 Entity Capabilities
* SASL anonymous support
* File transfer fixes
* MUC room configuration fixes
* initial support for XEP-0118 User Tune
* fix for an xmlrpc exception-during-serialisation bug, which would cause
a hang
* Support auto-gem generation on GitHub with improved and DRY’er RakeFile and
gemspec.
* Add support for the old SSL protocol (needed to connect to GTalk)
* Changed API for Client, Component, Connection, Stream to remove
need for antiquated ‘threaded’ param in the initializer.
* Use a Logger instance instead of directly writing to stdout
* Re-factored & consolidated Error classes. See xmpp4r/errors.rb for all
custom errors that can be caught. All inherit from Jabber::Error which
itself inherits from Ruby’s StandardError. This is a first step in
re-factoring errors. The next step will be to convert all ‘raise’ calls to
raise a custom Jabber::Error or one of its children instead of anonymous
RuntimeErrors. This allows much more granularity in catching and handling
errors later.
If you were catching Jabber::ErrorException before you should probably
change that in your code to now catch Jabber::Error if you want to
catch everything or one of the custom children of Jabber::Error defined in
‘lib/xmpp4r/errors.rb’. Additionally, the Error class which encapsulated
the xmpp error response, has been renamed to ErrorResponse to reflect its
real usage. This free’s up ‘Jabber::Error’ for use as our base Error class.

Say I have these 2 arrays :

Now what if I want a new array that contains only the elements present in both arrays?

Have a nice weekend!

Cart model (as in : shopping cart)

Bill model

User

Basically, because the “through” table links the destination table with a has_one relationship, ActiveRecord complains with : Invalid source reflection macro :has_one for has_many :bills, :through => :carts. Use :source to specify the source reflection.

Someone on Rails Trac already created a ticket about this issue 2 years ago. Can we expect this feature to be officially supported in the future? Let’s hope so.

Note : Those who don’t know what this plugin is all about should stop reading right there or risk being completely lost.

One thing that seems impossible to do with the plugin is to have variable “initial states” for an object. Say for example that you have a User model that needs to act as a state machine. New users have to fill up a signup form to gain access to the application. These new users will be “pending” until an administrator approve them (enabled) or refuse them (disabled)

So far so good. But what if an administrator can also create a new user? In this case we would’nt want the user to be “pending”, we want him to be “enabled” right away.

I experimented a similar scenario, so I tried a few things to bypass the initial state :

Too bad, so I tried this :

Of course, the following worked :

Yuk… there had to be something better.

Finally, I learned that initial_state was an inheritable attribute. I didn’t know what those were all about so I did some googling. The only good explanation I found is this one.

Anyway, I was able to override the initial state of my user object by doing this :

It’s not pretty I know, but at least it gets the job done. I wonder if the fact that you cannot “easily” change the initial state programmatically is a missing feature that should be added in a future version… or if it’s only my understanding of a “state machine” that sucks. Any thoughts?

Now with Rails 2.1, this functionnality is built-in so you don’t need to install the gem.

The named_scope method allows you to add finders to any model. A code snippet is worth 10000 words :

Doing this you can chain expressions like this :

Maybe you knew it, maybe you didn’t. If you didn’t, now you know it. (I feel very smart about this last sentence. I think I am going to put this in my room somewhere)

gedit is great… but it is rather limited features-wise. Recently I have tried Komodo Edit and I can say that this is the best RubyOnRails editor available on Linux. It has a lot of features (autocomplete, tons of supported languages, macros, color schemes, etc) but somehow it is still light and minimalist.

Komodo Edit is also available on Mac and Windows

I think it is something related to Rails that makes me so excited. I just tried deploying a rails application with Phusion Passenger (aka mod_rails)… and I am still shocked. Rails deployment has finally becomes a breeze! At the time I am writing this, I still have this exaggerated dumb smile in my face expressing my satisfaction… and I am alone in my house.

#UPDATE : I removed the smiling pig image that was put here to “express my satisfaction”. I removed it because it was not funny and it made me look like someone who is not funny… which is something I am not comfortable with. Now that I have removed the image of the smiling pig, I expect to receive my first comment (and tons of others) for this blog post. For those who liked the smiling pig, you can find it here and pretend it is funny.

Ok enough stupidities, Phusion Passenger is great. It is built to work with the Apache web server. No port configuration, no complicated vhost configuration, you upload your stuff and guess what? It works. Well, almost… to restart your rails application you just have to touch tmp/restart.txt. If you’re using capistrano, it means that you only have to do something like that :

And what about the vhost configuration?

<VirtualHost *:80>
ServerName yourdomain.com
ServerAlias www.yourdomain.com
DocumentRoot /home/you/apps/yourapp/current/public
</VirtualHost>

I didn’t have time to play with all the settings and read the documentation… but I have the feeling that this thing is the light, try it!


gem install passenger
passenger-install-apache2-module


Our hate towards the SQL language and databases is not a valid excuse to not assume our responsabilities as application developers. Recently I was working on a Rails plugin when the sentiment of being incompetent struck my body exactly like the lightning strikes an adventurous golfer who happily plays golf during a thunderstorm.

It all happened when I had a query that was generating a lot of results… and was slow as hell to process… even though I was using the :include option for Eager Loading.

@stuff = ParentStuff.find(:all, :include => :child_stuff, :order => “created_at DESC”)

Then, in my view, I had something like :

It was awfully slow! I started looking at the logs and saw this typical monstruous sql query. Look at it… you have to look at it. I know you don’t want to… but it won’t go away :

SELECT parent_stuff.`id` AS t0_r0, parent_stuff.`field1` AS t0_r1, parent_stuff.`field2` AS t0_r2, parent_stuff.`field3` AS t0_r3, parent_stuff.`field4` AS t0_r4, child_stuff.`id` AS t1_r0, child_stuff.`field5` AS t1_r1, child_stuff.`field6` AS t1_r2, child_stuff.`field7` AS t1_r3, child_stuff.`field8` AS t1_r4, child_stuff.`field9` AS t1_r5, child_stuff.`field10` AS t1_r6, child_stuff.`field11` AS t1_r7 FROM parent_stuff LEFT OUTER JOIN child_stuff ON child_stuff.the_foreign_key = parent_stuff.id WHERE (parent_stuff.created_at >= ‘2008-04-24 00:00:00′ AND parent_stuff.created_at <= '2008-04-24 09:44:56') ORDER BY parent_stuff.created_at

What's the problem with this? It's just one query... cannot take that much time. I thought it was a "Rails problem" until I ran the query directly in a MySql web interface. It took the same amount of time, meaning that the problem was within the query itself. Oh sh**... it was a database problem! Like many Rails Developers, my database skills are, while not inexistant, inadequate.

I tried to figure out what could be the problem with this query. I replaced every LEFT OUTER JOIN with INNER JOIN and Boom! the query executed in less than half a second.

My urgent desire of leaving the MySql web interface made me go back to my Rails code. I then tried some stupid random stuff like :

@stuff = ParentStuff.find(:all, :include => :child_stuff, :joins => “INNER JOIN child_stuff ON child_stuff.parent_stuff_id=id” :order => “created_at DESC”) but the slow LEFT OUTER JOINs remain in the query instead of being replace by the faster INNER JOIN. Then, I learned that in Rails 2.0, you could do Eager Loading with INNER JOIN by passing an association name to the :joins option, like that :

@stuff = ParentStuff.find(:all, :joins => :child_stuff, :order => “created_at DESC”)

Problem is I was working on a plugin… and I’d like it to be compatible with older versions of Rails. So I did what I was scared of doing since the beginning : Going to some MySql forums to read the advice of some DBA’s …

Then I found the answer to my problem… and this answer proved me that I needed to stop playing blindly with ActiveRecord like if the backend database was none of my business…. because it is. The answer is so obvious… but given the fact that I never wanted to care about databases since Rails exists, I didn’t think about it :

Answer : Add an index to the foreign key in the child table!

This is just one case that shows the dangers of not being aware of what’s going on in the database. It’s sad, but you cannot blindly let ActiveRecord manage everything that is Database related for you. It’s only a question of being in control of the entire application… and the relational database is a part of it.

UPDATE
This post has kind of turned against me. The only thing I wanted to say with this article is that ActiveRecord needs our supervision… not that I am a moron who can’t understand databases. I know what joins are, I know what indexes are… but in most situations I don’t have to “care” about them with ActiveRecord. Sorry but I felt the need to defend myself about this issue