At Littlelines, we have to write a lot of code under strict time constraints. We work in small teams which means that writing clean and concise code is a necessity. When a Ruby library comes along that makes code easier to grasp in a hurry, test, and maintain - we use it. Here are some gems we have in our toolbox:

Formtastic

If you're developing wep apps, more than likely it will include html forms. Forms can be a time-drain, not to mention very boring to build. Formtastic provides a more concise way of generating form views and includes inline error messages and is semantically rich.

Resource Controller

Resource Controller hides away the RESTful controller boiler plate code and make your controllers skinny. Skinny controllers help you to consolidate your business logic into one place, thus saves time on maintenance and testing.

Search Logic

Finding data can get messy. Sometimes we run into situations where we are concatenating strings to build SQL statements and this can lead to bugs. Searchlogic works by creating a number of named scopes that can be called on any ActiveRecord model. The best part, you can dynamically call scopes on associated classes and Searchlogic will take care of creating the necessary joins for you.

Alchemist

Occasionally, we work on projects dealing with conversions. Alchemist is a Ruby library that does conversions for you and thus making your code more readable and easier to maintain. For example:

Instead of:

miles = 8 * 1609.344 # converting meters to miles

We can write:

8.meters.to.miles

Alchemist includes a staggering array of conversions including distance, mass, volume, and more.

andand

andand is a handy gem that allows allows natural method chaining for methods that can return nil. This saves a lot of boilerplate code and improves readability. For example:

Instead of:

@body = (article = Article.find_by_title('test')) && article.body

We can write this:

@body = Article.find_by_title('test').andand.body

This will call find on the Article class and sends 'body' if the result is not nil. In addition, our methods are guarded from NoMethodErrors is the result is nil.

Update: I thought I should give a little background on how I got started with Rails - when I was attending the SDWest conference in March 2006. I was at the Jolt Awards, and saw @d2h receive the award for the best web development tool for Rails 1.0. I downloaded Rails that night in the hotel room and was hooked.

This week marks the two year anniversary when I delivered my first professional Rails app. Today, I decided to take a look back at the code of that first project and see what's improved over the past two years. The result - not bad, but there were a couple areas that stood out. Here are a few:

1. The controllers in that first project were out of control. Not sure why, maybe coming from the J2EE world, my first instinct was to cram everything into the controller. It was apparent that the concept of REST wasn't completely baked into my brain yet. Not to mention the concept of fat models, skinny controllers.
2. Second, the views and Javascripts were a bit unorganized. I noticed excessive conditional logic and messy Javascript code in a few of the pages. If I was to re-write the app today, most of it could be cleanup with rendering partials with collections and using Low Pro to clean up the Javascript.
3. Finally, the sheer lack of plugins for that first project was surprising. It's true that the amount and quality of plugins have grown in two years, but I believe the lack of awareness was the main cause.

So this made me think of what I would say if I were to advise newcomers writing their first Rails app. I would have to say first, if you find yourself writing code in the controller, then ask yourself "Can I put this logic in the model?". And also be sure to familiarize yourself with the available plugins with sites such as Agile Web Development and Github. They can save you a ton of work.

Sending emails with Rails via Gmail is a snap with Marc Chung's excellent plugin action_mailer_tls. However, sometimes our production environment isn't using Gmail as a mail server and/or we just need an easy way to send email from our development environment for testing or demonstrating purposes.

Instead of installing the action_mailer_tls plugin and configuring each of our Rails apps, we can do a one-time setup of our local Postfix client to relay all SMTP outbound emails to our Gmail account. If your running a Mac OS Leopard or Linux, Postfix should already be installed. With a little configuration, we should be up and running in a couple minutes.

First create /etc/postfix/relay_password file with the server name, email account name and password as shown below. This configuration works with Gmail accounts as well as with Google Apps email accounts. I'm personally using my company's Google Apps with a special email account setup for outbound emails only.

smtp.gmail.com    example@yourdomain.com:yourpassword

Then tell Postfix about our google accounts information so it knows how and where to relay the email to. This can be done with the postmap command:

$ postmap /etc/postfix/relay_password

Since Gmail requires a TLS (Transport Layer Security) connection for certificate-based authentication, we'll need to download a free root certificate from Verisign https://www.verisign.com/support/roots.html to authenticate our remote SMTP client.

$ mkdir /etc/postfix/certs
$ cd /etc/postfix/certs
$ sudo cp roots.zip /etc/postfix/certs
$ sudo unzip -j roots.zip
$ sudo openssl x509 -inform der -in ThawtePremiumServerCA.cer -out  ThawtePremiumServerCA.pem
$ sudo c_rehash /etc/postfix/certs

Now we are ready to configure Postfix. Postfix needs to know what host to relay the email to, the username and password to authenticate the Gmail account, and the path to our certificates for the encrypted session. Add these lines to the bottom of /etc/postfix/main.cf

relayhost = smtp.gmail.com:587
# auth
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/relay_password
smtp_sasl_security_options = noanonymous

# tls
smtp_tls_security_level = may
smtp_tls_CApath = /etc/postfix/certs
smtp_tls_session_cache_database = btree:/etc/postfix/smtp_scache
smtp_tls_session_cache_timeout = 3600s
smtp_tls_loglevel = 1
tls_random_source = dev:/dev/urandom

Restart (or start) Postfix to pick up our new changes.

$ sudo postfix stop
$ sudo postfix start

That's it! Now we don't have to do any special installation or configuration to send email via Gmail for our Rails apps. We just need to set the delivery method to :smtp and we're ready to go.