June 23 rd
TabsOnRails is a simple Rails plugin for creating and managing Tabs in Rails projects. It provides helpers for creating tabs, and virtually any type of navigation menu, with a flexible interface.
The release 0.8.0 is now available. This is the first beta release, even though this plugin has been publically available for quite a while. It is now part of the standard set for the most part of my Rails projects and it turned up to be really helpful.
Continue Reading
June 17 th
One of my biggest deal when approaching new features in Rails is the correct answer to the question “how should I test this?“.
Someone would probably assert that everything you code can be tested and, even though I perfectly agree with that, I would probably be more interested in how that shiny piece of code can be tested. Rails made the creation of tests a piece of cake, but it’s not always so easy.
Have you ever tried to test the correct creation of a cookie in Rails 2.2? Have you ever written an helper test that involves routing rules in Rails 2.0? Have you ever created a test to ensure your caching strategy works as expected?
If you answered yes to at least to one of those questions, you probably know what I mean.
The first requirement to write effective tests is to know what you are playing with. You can’t really know how to test an ActiveRecord callback unless you don’t know how callbacks works in ActiveRecord and, off course, what your hook is supposed to do.
The second suggestion if you get stuck writing a test is to start reading how that feature or the underlying implementation has been tested in the original framework. So, if you need to write a test for your custom Rails foo_tag helper, you probably want to start reading how the Rails team tested the helpers available with the Rails framework. Believe me, you’ll discover tons of new features just reading the tests.
I don’t want to go deep further on how to write effective tests, I’m already writing something special about that topic. This time, let me show you how to test one of the most recent ActiveRecord features: named_scope.
Continue Reading
June 15 th
Like many other Rails developers, the most part of my Rails applications run on production with Apache, mod_rails and Ruby Enterprise Edition. In fact, this environment has proved to be one of the most successful under many aspects.
Ruby Enterprise Edition is a server-oriented friendly branch of Ruby which includes various enhancements. Although it should share more or less the same Ruby 1.8.6 behavior and be 100% compatible, you should never rely on assumptions when debugging your application.
Debugging an application running on Ruby Enterprise Edition can be a little tricky unless you don’t install Ruby Enterprise Edition on your local machine. However, this means you should either replace your favorite Ruby version or create a kind of switch to choose the Ruby interpreter you might want to use for that specific development session.
Taking this problem to an other level, many programmers started to have the same need as soon as they wanted to test their application against Ruby 1.8.x and Ruby 1.9. Fortunately, the solution already exists and it’s called multiruby.
Continue Reading
June 3 rd
Last week, an user asked the Capistrano mailing list about database password best practices. This reminded me that I never posted here a Capistrano recipe I created almost one year ago to solve exactly this problem.
Which problem?
Imagine you need to deploy a new Rails application. As you probably know, Rails stores all the database configurations in a single file called config/database.yml, including database authentication credentials.
This file usually lives in your repository along with all your application code base. However, exposing real world passwords to all developers with read access to the repository can lead to major security problems. It’s likely you don’t want to store sensitive data in your repository, thus you need to automatically generate the config.yml file somehow on deploy or on setup.
If you are using Capistrano to deploy your Rails application, you can ask Capistrano to generate and upload the file for you. Let me show you how.
Continue Reading
May 20 th
This morning I sent an email to a friend of mine from my Gmail account. This is permanent failure error message I received in response.
This is an automatically generated Delivery Status Notification
Delivery to the following recipient failed permanently:
...@virgilio.it
Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550 mail not accepted from blacklisted IP address [209.85.218.165] (state 13).
