Matt Sears

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.