has_many :developers

I must confess a I am completely new to Gentoo, but a customer of us is a control freak and feels better when he can watch all the output of the compilers working on a emerge command ;-)

The thing was supposed to be easy, Postfix was setup as a relay in this Gentoo EC2 instance, and Google was supposed to take care of mail delivery and such. It should just required SMTP to localhost, but...

The Rails application didn't responded, in the end it was blocked trying to send the mail, and finally timed out with a Timeout::Error (execution expired): /usr/lib/ruby/1.8/timeout.rb:60:in `rbuf_fill'

Back to basics, I went to the command line to check if evrything was properly set up, and according to mutt, sending mail was no problem. Ok, mail relaying is fine.

Using a simple Ruby script, I got the same Timeout::Error (execution expired): /usr/lib/ruby/1.8/timeout.rb:60:in `rbuf_fill'

Where could I get more information? In the Postfix logs of course! Those logs were supposed to be in something like /var/logs/mail/postfix.log or something like that. But I found noting around...

Fortunately I found that Postfix logs end in /var/messages by default in Gentoo (Getting postfix to log properly in Gentoo) where finally I found, the following errors:

Apr 30 15:37:11 localhost postfix/local[13107]: fatal: open database /etc/mail/aliases.db: No such file or directory
Apr 30 15:37:12 localhost postfix/master[7178]: warning: process /usr/lib/postfix/local pid 13107 exit status 1
Apr 30 15:37:12 localhost postfix/master[7178]: warning: /usr/lib/postfix/local: bad command startup -- throttling

Google came to my rescue, and that the problem was associated to a missing configuration step in the Postfix setup and running the newaliases command allowed me to send mail from my simple Ruby script.

Mail was being delivered, but there was a still a 501 5.1.3 Bad recipient address syntax around, that basically was Postfix asking for the mail address to be enclosed
in < >

Back to Rails I got a 501 Syntax: HELO hostname, that was simple to get rid of as the :domain => "yourshere.com" was missing from the config/mail.yml

For a new rails (v2.2.2) project I upgraded my gems of RSpec (v1.1.12) and ZenTest (v3.11.0) but when I try to run autotest, it stalls out:

$ autotest
loading autotest/rails

Digging in google I found a solution, just do:

$ RSPEC=true autotest

Then autotest runs normally.
If you want, you can export the RSPEC variable in your ~/.bashrc file (this file determines the behavior of interactive shells):

$ export RSPEC=true

Start a new shell or just run:

$ ~/.bashrc

After that you can just run:

$ autotest

rdiff-backup is a great and simple tool to create remote incremental backups, this classic program is a must if you live in the command line and you like taking advantage of the unused disk space in your different drives.

Recently I had a problem installing it in a Ubuntu 7.10 box, from which I wanted to backup to Ubuntu 8.04:

Warning: Local version 1.1.14 does not match remote version 1.1.15.
Exception 'backup_set_globals() takes exactly 2 arguments (1 given)' raised of class '<type 'exceptions.TypeError'>':
  File "/var/lib/python-support/python2.5/rdiff_backup/Main.py", line 302, in error_check_Main
    try: Main(arglist)

It looks like it is a known bug when backing up. The packaged version seem quite old, so I decided to uninstall the packages in both machines, and commit a major sin: install from sources.

The lates version is 1.2.5, it is a very simple Python script, and here it is its instalation process:

$ wget http://savannah.nongnu.org/download/rdiff-backup/rdiff-backup-1.2.5.tar.gz
$ tar -xvzf rdiff-backup-1.2.5.tar.gz
$ cd rdiff-backup-1.2.5/
$ sudo aptitude install python2.5-dev
$ sudo aptitude install librsync-dev
$ sudo python ./setup.py build
$ sudo python ./setup.py install
$ rdiff-backup --version

In just a matter of minutes you will find yourself having the same version of rdiff-backup installed and both machines and working flawlessly.

If you find your Rails application behaving a little bit "schizophrenic" regarding HTTP and HTTPS, and you are using Nginx as proxy in front of your Mongrel or Thin servers,  then is possible that you are suffering a lack of headers.

This disease is easily cured by the administration of a single dosis of:


To your nginx.conf. Off course this treatment is only recommended for SSL enabled configurations.

Basically the problem is that if the header is not set, the Rails application doesn't know that the request is HTTPS, and responds with a regular HTTP response. Depending on your configuration and what are you doing with your application the problem can not arise until you get a somethinbg like a HTTP redirect from your application hitting the wrong port (443)

Lately here @ the office, we have been working with the not so new kid on the block of the Ruby Web Frameworks, Merb.

At first sight, it seems like a Rails fork, but when you start to see the code behind the curtains, you realize the is more readable and it has pretty awesome code design implementation. There also have been said that is faster than the Rails framework, so it seems like an interesting beast to attack, giving the always criticized defects of Rails about speed.

The project we are working right now is developed with Merb 0.9.4, so it has been kind of a pain because it is not as good and complete as the latest version of the framework, nevertheless we have been also "playing" with the newest version and we have learned a LOT from the code.

One of the things that was actually missing, was the Cucumber extension for the Merb framework, seeing the benefits of working with it, I looked for a developer partner on #merb  to develop one as soon as possible, David and I are almost there for a stable version of this gem.

If you want to check it out, please look at the must updated repo and clone it out.

Here is another post to help you get started more quickly.

Enjoy.

Yesterday, a co-worker had some growing pains when updating a Rails 1.2.3 application to Rails 2.1. I gladly came to the rescue (he actually saved me from a boring job) and we analyzed together what was the error we were getting on the app.

The thing happened to be on the form_helper method

datetime_select

<% form_for :mode do |f| -%> <!-- some html code --> <%= f.datetime_select :recent_called_at, :order => [:year, :month, :day] %> <% end -%>

A chunk of code (just like the one above) was throwing an exception that said:

ArgumentError: wrong number of arguments (1 for 2)

The exception was getting threw inside a method called

date_or_time_select

that was being invoked; inside the

datetime_select

method.

We checked out the plugins that could overwrite this method, and

attr_locked

was doing it via

alias_method_chain

. The problem was that, this overwrite didn't provide the correct number of parameters for the Rails 2.1 version (the Rails 2.1 version of

datetime_select

accepts an extra hash parameter called html_options). We made some little changes to the current implementation and it worked as expected.

Hope you can get some benefits from this patch

Recently, one of our customers wanted to have a mockup of an application. We thought at first to use Rails to make this mockup, but suddenly we realize that it was overkilling to create models and controllers when the requirements are not clear enough.

Once we decided not to use Rails to do this task, we did study some Ruby CMS around the Web. The different options we came around were:

• StaticMatic

  Pro

  It offers a lot of neat features like partials, layouts, host configurations and the most outstanding: custom view helpers.

  Con

  It just limited to Haml & Sass templates, so you will need to know this template system in order to use it.

• Nanoc

  Pro

  Is one of the biggest Ruby CMS around on the Web, it offers a lot of features like partials, layouts, templates, filters, tasks, etc.

  Con

  IMHO, is just to big for the average mockup site, if you will use this to make a mockup, you probably would like to stick with rails.

• Webgen

  Pro

  It offers the same options as many other CMS (partials, layouts, filters).

  Con

  The configuration is not as comfortable as in other CMS.

• Webby

  Pro

  It offers the same options as many other CMS (partials, layouts, filters), but also, it provides helpers for rendering LaTeX and Graphviz content, offers the chance to make custom rake tasks, offers CodeRay and Ultraviolet support for code highlighting on the mockup. The configuration is pretty easy, and it offers auto generation on file changes.

  Con

  It does not offer the custom view helpers feature and the docs are not as big as you would like.

As you may guess, I went to the option of Webby, it seems the more middle-size CMS made in Ruby that offers a lot of options and is easy to configure.

If you want to provide more observations on the comments section, is highly appreciated, I did not make a deep study on the others CMS, so maybe I'm missing some pros on each of them.

Recently I'm testing in Firefox 3 the "admin" section - implemented using ActiveScaffold - of a Rails application we made.

I'm getting RJS Errors when trying to update a record:

• TypeError: $$("#admin__operator_details-update-151-form a.cancel").first().link is undefined
• $$("#admin__operator_details-update-151-form a.cancel").first().link.close_with_refresh();

The issues is already reported as #553

The summary is that the problem lies within the deprecated getElementsByClassName function in the active_scaffold.js.

To fix (thanks to Eric Bjorkvall) just replace in files:

• /public/javascripts/active_scaffold/default/active_scaffold.js
• /vendor/plugins/active_scaffold/frontends/default/javascripts/active_scaffold.js

the line: this.adapter.getElementsByClassName('cancel').each(function(elem) { with: this.adapter.select('.cancel').each(function(elem) {

Instead of replacing the original assets of ActiveScaffold I skipped the change on /vendor/plugins/active_scaffold/frontends/default/javascripts/active_scaffold.js and just comment the /vendor/plugins/active_scaffold/init.rb in order to avoid the copy assets on plugin initialization.

Finally it comes the time when (even if you avoided at all costs) you must develop the view part of the project. Here I'll summarize some of my experiences in Tips that you should keep in mind before start coding like a monkey.

Reorganize your view structure if the project doesn't follow the Rails golden path

A lot of people tries at all costs to adapt their code to the Rails organization, that shouldn't be always the case.

There will be times when you will have a same partial, shared in more than one controller. This normally causes some questions about why the partial is in this controller and not in the other, the simple answer to that question would be: "the partial is in the controller X because it was the first one who used it".

In this cases, you should keep a shared folder inside the views folder, this way you'll know that the partial doesn't belong to any controller at all, is just a shared view between lot's of controllers. If you notice that your shared folder is starting to get fat, organize partials that have common purposes in sub-folders, this way you won't be lost when looking for a shared partial with a particular purpose.

Then, when rendering a partial, you would do something like

render :partial => 'shared/header/month'

Here we have shared partials that are being used in the header sections of lot's of controllers. This way you keep an order in your views that is more comfortable and more understandable.

In your partials, use helpers as much as you can

When you have partials, is probably because you repeat the same view in a lot of places. The thing is that you normally would like the partials to behave differently in some cases, say you want the URL's of the partials of a profile to point somewhere else or not to point anywhere at all (when you have a public profile for example). In this cases the best thing you can do is use helpers for returning the URL's.

You shouldn't bother with lots of if's and else's when the sweet polymorphism can do the job quite easy, just overwrite the method in the controller's helper and the partial will behave differently on each controller it is called¹.

So for example, Imagine we have a profile section, and you have 2 versions of this profile, the public version, and the private version. This versions have a lot of things in common in the view side, but when we are in public profile, all the links points to a link of a public section, while when on private profile, the links point to private sections.

The view on the partial (shared/header/month.html.erb) would be something like

<ul id="month-header"> <li><%= last_month_link(current_month) %></li> <li><%= verbose_format_of_month(current_month) %></li> <li><%= next_month_link(current_month) %></li> </ul>

Now, when we are on the public controller, the helper should behave like

module PublicHelper def last_month_link(current_month) link_to('Last Month', public_profile_path(:month => 1.month.ago(current_month))) end def next_month_link(current_month) link_to('Next Month', public_profile_path(:month => 1.month.from_now(current_month))) end end

And on the private controller, the helper should behave like

module PublicHelper def last_month_link(current_month) link_to('Last Month', profile_path(:month => 1.month.ago(current_month))) end def next_month_link(current_month) link_to('Next Month', profile_path(:month => 1.month.from_now(current_month))) end end

Here we are letting the polymorphism of the helpers solve the view repetition, by just providing a method that behaves differently depending on where we are standing.

Parametrize... ALWAYS

Programmers are lazy, and there is nothing wrong with that, but sometimes this laziness can give us some nasty moments, it all starts with: "why pass it as a parameter? Just access it via the current_user, or the @instance_variable and you won't have to pass parameters every time you invoke this helper/partial".

This will give you more problems than benefits at the end, just imagine what would happen if the helper method/partial would work for every user we would like to, but it only calls the current_user?. This is when refactoring comes along and we change the current_user for a parametrized user, the thing is that you call this refactored method like 150 times. There is when you say... "damn, it would be easier if I just passed the user as a parameter from the beginning". Always keep in mind that the more you use your global environment, the less reusable is your code.

Don't to use instance variables in the partials (change them with the :locals option), nor to use instance variables on the helper modules if they are not being used only in the module for private logic (pass the objects as parameters to the functions).

I hope this 3 tips can help you get a better start when coding views.

---

1. You have to keep in mind that this probably won't work in recent versions of Rails unless you comment the inclusion of all the helpers in all the views (I wouldn't recommend this feature if you want your views to be scalable).

Well, finally a blog. We decided (flip of coin, you know) that having a few paragraphs of static content and call it "the company web site" was so boring, and useless that we were going to completly drop it, and focus in the blog.

Anyway, there is "page" called Everything you wanted to know before hiring us just in case you have heard about us and you are considering to do so.

We are supposed to keep this site updated with great content, so please feel to bookmark it or better add the feed to