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.

Writing multi-threaded code is hard. If you've ever done concurrent programming, you'll probably agree. Clojure offers a compelling alternative to traditional object-oriented approaches to programming and has garnered much attention from the Ruby community because of it's elegant design that lets you get right to the essence of a problem.

What is Clojure?

Simply put, Clojure is a functional programming language for the Java Virtual Machine with several powerful features for building concurrent applications. In addition, Clojure is fast, robust, and a powerful general-purpose programming language. A dialect of Lisp, Clojure embraces traditional code-as-data philosophy and a powerful macro system, plus some syntactic sugar tailored to Java.

Now that version 1.0 is out and Stuart Halloway's new book Programming Clojure just dropped, I've rounded up some of the best articles and tutorials on Clojure to you get you up to speed quickly.

Tutorials and Links

• A Clojure Tutorial by R. Mark Volkmann

• Programming Clojure book by Stuart Halloway

• Practical Common Lisp to Clojure by Stuart Halloway

• Clojure Series: Table of Contents by Eric Rochester

• Learning Clojure via Wikibooks

• Clojure Programming/Examples/API Examples via Wikibooks

• Clojure Programming/Tutorials and Tips via Wikibooks

Screencasts, Videos, and Presentations

• Functional Programming with Clojure by Phil Hagelberg (PeepCode)

• Clojure Series on Blip.tv by Rich Hickey

• Intro to Clojure by Brian Will (YouTube)

• Emacs with Clojure, Slime and Swank by Seth Buntin (Vimeo)

Tools and Setup

• Basic Clojure Setup by Telman Yusupov

• Setting Up Clojure for Mac OS X Leopard by Mark Reid

• Getting Emacs setup to write Clojure code by Phil Hagelberg

• Textmate Bundle for Clojure code by Scott Fleckenstein

• VimClojure, a Vim plugin for Clojure

Documentation

• Official Clojure site

• Official Clojure API

• Clojure Docs

• Clojure Coding Guidelines by Mark Volkmann

Over the last few years, I have grown tired of maintaining, migrating, and upgrading blog software, so I've decided to roll my own with Ruby code. In doing so, I wanted to keep things as simple as possible with a basic set of features: articles, pages, comments, rss, etc. What I didn't want is a SQL database or an administration tool. I wanted to write articles in my text editor of choice (Emacs), in Markdown format, and versioned with Git. So I've ported this site from Mephisto to my own custom creation. I call it Aerial.

Much inspiration for Aerial has come from Marley, a minimal flat-file blog engine written in Sinatra. Like Marley, Aerial is built with Sinatra and uses plain text files. Unlike Marley, Aerial doesn't use a SQL database and uses Grit to retrieve article and comment files from a Git repository.

So how does it work?

Articles and comments are stored as plain text files in a local Git directory. Aerial parses each file and converts them the Article and Comment objects with their own set of attributes such as title, body, tags, and author. For example, this article looks something like this:

Title      : Git blogging with Aerial
Tags       : projects, ruby, git, sinatra
Published  : 03/28/2009
Author     : Matt Sears

Over the last few years...

Since Aerial reads the articles from the Git repository, the contents of article won't display in the browser unless the changes are committed to Git. Same goes for comments.

Working with remote repositories

Aerial uses local and remote Git repositories to sync data between the production web server and your local environment. For example, when comments are submitted on the production web server, they are checked for Spam via Akismet and saved to the same directory as the article. Then, the new comment file is added to the production web server's repository and pushed to the remote repository (Github in my case). To pull in user comments to our local environment, simply use the pull command:

git pull

Now we have all the comments that users have submitted.

Getting Started

For Aerial to work, you'll need Git installed and the following RubyGems:

sudo gem install sinatra grit rdiscount haml

Grab the source code from Github.

A small configuration file in config/config.yml is used to store information about your blog. You can add your info now or leave it as is and it will still work. To setup and run Aerial, we need to run the boostrap Rake task:

rake bootstrap

This will install the necessary directories (specified in the config.yml file), javascript files, and insert a sample article to get you started. If every goes smoothly, Aerial should be up and running at:

http://localhost:4567

Keeping in spirit with minimalism, all the pages use Haml for the templating engine. Of course, you may change this to the templating engine of your choice.

Creating new articles

Create a new folder in the app/articles directory. You can name this folder anything you want, but it may be helpful to number them so they display in the order you want them to. For example, the folder for this articles looks like this:

app/articles/011-introducing-aerial

Next, create a text file with the extension '.article' and save it to the new folder. The '.article' file extension let's Aerial know that this file should be converted to an Article object. The name of the article will be the article's permalink. Remember, the article will not display on the site until it's committed to the git repository. When the article is completed, we can push it to the remote repository with the push command:

git push

Now, we're ready to deploy it.

Deployment

Deployment tasks are handled with Vlad the Deployer. A simple deployment script is located at config/deploy.rb. It assumes your running Apache and Phusions Passenger, but you can edit this file with your own settings. Future enhancements may include auto-syncing with post-receive hooks so that 'git push' will make Aerial update itself, but for now we can deploy with a simple rake task:

rake deploy

This is by no means a comprehensive introduction. If you have any questions or run into any problems, please drop me a line.

This month I headed down to Orlando, Florida for RubyConf 2008. It kicked off with a delightful (and touching) keynote by Matz. He walked through his own programming history with languages including the language he got started with BASIC (the same language I started with). Matz talked about the growing community and a statistic from Gartner that says there are over a million Ruby developers and will grow to 4 million by 2012, which is amazing. He finished up by saying that Ruby is all about love, and included a slide that said "I love you all". Below are couple highlights from each day.

Photo credit: Dan BenJamin

Day 1:

Gregg Pollack's talk on Scaling Ruby (without Rails) was really good. He touched on green and native threads, EventMachine, message queues, and profiling code with ruby-prof. My favorite part of the presentation was the performance tips and tricks of optimizing Ruby code. His talk is up at EnvyCast and I definitely recommend it.

Jamis Buck - "Recovering from the Enterprise" was probably my favorite presentation at the conference. The main theme of his talk was that working in the enterprise solves problems differently than those solutions in Ruby. Jamis worked in Java (like me) before Ruby and he told a story of how he written a library for dependency injection for Ruby but realized that he was trying to use Java solutions in a Ruby world that didn't need it. He said Java is like Legos and Ruby is like Play-doh and delivered the best quote of the conference "Just in time, not just in case"

Photo credit: Dan BenJamin

Day 2:

Effective and Creative Code by Eric Ivancich was awesome. He discussed how our minds work while programming - the differences between fascination and direct attention, the mental fatique and long periods of direct attention can have on you. Fascinating stuff.

Yehuda Katz taught us how to write code that doesn't suck with Interface Oriented Design. But first, he announced that Merb 1.0 was released just minutes before his presentation. Then he went on to say that unit tests are not regression tests and that writing regression tests should make sure that the API we are exposing to the world doesn't break while work is being done under the covers.

Photo credit: Dan BenJamin

Day 3:

I saw Neal Ford's talk on Advanced DSLs in Ruby - one of my favorite topics. This presentation was really good because Neal was very specific on how to build DSLs in Ruby and not just the basics. He covered various techniques on writing DSLs and provided a nice summary of his talk on his website.

I sat down next to Dave Thomas to listen to Gregory Brown's talk about Prawn, a pure Ruby PDF generation library. Prawn is cool, but how Prawn was born was the most interesting part of the talk. A community funded project called The Ruby Mendicant Project allowed Gregory to quit his job and work on Prawn full time - A Ruby community employee.

Overall it was an amazing conference. It was great to see and talk to people that I only get to see online. Looking forward to next year.

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.

Last week I made a short drive to Columbus for the erubycon conference presented by the EdgeCase crew. The three day conference, hosted by Microsoft, was an event to demonstrate Ruby's role in the enterprise. Having worked in the Enterprise for six years, I was very excited to learn more about how Ruby can change the Enterprise.

Photo credit: EdgeCase, LLC

What is legacy code and how do we avoid it? Stuart Halloway addresses these questions with his talk Ending Legacy Code In Our Lifetime. This was my favorite talk on the first day because the Enterprise is "full of it" and much my time was spent trying to avoid it. It's nice to see somebody calling attention to it.

Photo credit: EdgeCase, LLC

Very interesting talk on JRuby by it's creator Charles Nutter on the second day. I went back to the hotel room that evening and setup JRuby on my laptop. I wrote a quick rails app and with Warbler, had a working war file ready to be deployed to Java application server. Very impressive.

Photo credit: EdgeCase, LLC

Perhaps my favorite session at the conference was Jim Weirich's talk on concurrent software development. Something I don't think is talked about enough and is certainly important in the Enterprise. I've written multi-threaded apps in Java and it can be very difficult especially avoiding deadlocks. Is Ruby the answer? According to Jim, not really. Perhaps a Erlang or Clojure offers a better solution.

Photo credit: EdgeCase, LLC

And Finally, Chris Wanstrath, co-creator of GitHub talks about Git, GitHub, and a little about side projects. Oh, and did I mention I really love GitHub? It's really changing how we develop software.

Photo credit: EdgeCase, LLC

• All the photos above are provided by EdgeCase, LLC and more are available on their Flickr page.

Last week, I was preparing a presentation and found myself doing a lot of quick fixes and deployments to prepare a web application for a demonstration. I thought instead of running the following four commands each time:

git add .
git commit -a -m 'A description of the change'
git push
cap production deploy

It would be nice if I could do all of the above with just one command. So I created this shell script:

push() {

  # Defaults
  MINLEN=25
  DIRTY=false
  DEPLOY="production deploy"
  REMOTE_REPO = "origin master"

  # Check if we have any untracked files
  if git status | grep -q "modified:"
  then
     DIRTY=true
  fi

  # Make sure there is a message with the commit
  if [ -z "$1" ] && (test $DIRTY == true)
  then
    echo "You must specify a message with your commit"
    return
  elif [ ${#1} -lt $MINLEN ] && (test $DIRTY == true)
  then
    echo "Your message must have at least $MINLEN letters."
  return
  fi

  # Commit all the changes by default
  if (test $DIRTY == true)
  then
     echo "Adding new files to Git repository"
     git add .

     echo "Commiting to local Git repository"
     git commit -a -m "$1"

     # Push changes if a remote repository exists
     if git remote | grep -q "origin"
     then
        echo "Pushing changes to remote repository"
        git push $REMOTE_REPO
     fi
  fi

  # Deploy changes via Capistrano
  if ls | grep -q Capfile
  then
     cap $DEPLOY
  fi
}

The 'push' function will first check to make sure you supplied a description if any recent changes were made. Second, it will commit all the code and push it to the remote repository (if one exists).

If none of the code was modified or added, it will skip the Git commands and simply run the Capistrano deploy command and not require a description for the changes.

To use this script, copy and paste the above function to the end of your ~/.bash_profile file. To run it, simply run the 'push' command.

push "The description for the committed changes."

That's it! All the code is added, commited, pushed, and deployed.

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.

Just finished making some major changes to this site. First thing you might noticed are the changes to the design. In effort to simplify things a bit, I modified a Scribbish theme to my own liking. Is it too geeky? The awesome portrait you see at the top right was created by Josh. Nailed it.

Here is a rundown of the changes made:

1. Upgraded to Ubuntu 8.04 Hardy Heron
2. Installed Apache and Phusion Passenger (mod_rails)
3. Change and tweaked Mephisto theme

I'm still in the process of moving my old blog posts over. More big news coming soon.

Josh and I were interviewed by Freshbooks for their "FreshFaces" blog. Freshbooks is a great tool for keeping track of invoices, so we were pretty excited to talk to them.

The article can be seen here.