Using SMTP Settings in Squash

Recently, we started using Squash to monitor exceptions from our company’s internal applications.

We soon discovered, however, that we were not receiving emails from Squash to notify us of errors. It turns out that by default Squash’s email setting use a localhost email configuration. For security reasons our servers do not have these services enabled on servers that do not require it. Therefore, we had to update Squash to send via our internal Exchange system. This is how we did it.

Add additional Gem requirements

We needed to use NTLM authentication so we added ruby-ntlm to the Gemfile and tell it to only require the SMTP settings.

gem 'ruby-ntlm', require: 'ntlm/smtp'

ActionMailer Settings

Squash uses Configoro to manage configurations which is not complicated to use but we needed a quick fix to get things operating as we needed. As such we added a new initializer with our settings:

# config/initializers/mail.rb

ActionMailer::Base.smtp_settings = {
  :address  => "",
  :port  => 25,
  :domain  => '',
  :user_name => 'USER',
  :password => 'PASS',
  :authentication => :ntlm,
  :enable_starttls_auto => true

A quick app restart and email was back in business.

We have forked Squash and are working on a ‘proper’ solution for this that we will submit back to the project as a Pull Request. I will try to update this post when that patch is available and/or merged in.

Experimentation as a Win/Win

In the tech circles I follow online I have seen a lot of pixels dedicated to the release of 37signals new book Remote – Jason Fried & David Heinemeier Hansson. I have distinct interest in this as I have worked with a remote team, but have never been a remote worker myself. I have also spent most of the past few years leading a development team and wanted to see what observations this book may have from that perspective.

Then I noticed this tweet from Joel Spolsky of Fog Creek Software,

I was immediately interested. Mr. Berkun was not only talking about his personal experiences on a distributed team, but also leading said team. I hoped it would provide the perspective I was looking for and I have not been disappointed.

After completing the book, one paragraph has really stuck with me.

[..] Every benefit granted can be used to perform better work, or it can be abused. The benefit itself rarely has much to do with it. If someone who works for you wants to work remotely or use a new e-mail tool or brainstorming method, little is lost in letting him or her try it out. If his or her performance stays the same or improves, you win. If it goes poorly, you still win, as you’ve demonstrated your willingness to experiment, encouraging everyone who works for you to continue looking for ways to improve their performance. They become allies in making you look good, because you’re simply willing to try. If someone suggests thirty-minute instead of sixty-minute meetings, what is there to lose? If the experiment fails, you end it and try another.

Mr. Berkun’s description of why experimentation by your employees/team is a win/win scenario really struck a chord. I like to think that I am a leader that encourages my team to experiment, but I can see now that I have stifled experimentation in the past due to potential to ‘lose’. I didn’t have a win/win attitude.

I intend to keep this attitude at front in my mind when talking about experimentation with my team in the future. I want to ensure that I keep the benefits of these experiments, both in success and failure, in a more positive perspective. Using this positive perspective I hope perform my own experiments to accomplish my goal of becoming a stronger leader for my team.

If you’re curious, I would recommend this book to anyone is looking to become stronger leader or looking to get a better understanding of distributed teams and, what I agree, is the future of work.

Dealing with Rails 4 Deprecations

At my place of employment we have a very large Rails application that runs many parts of the business. The app was started on Rails 2.0 and went into production under Rails 2.3. It was only recently that we were able to get it updated to Rails 3.2 and Ruby 2.0. We the took a shot at getting it running under Rails 4. It took a few hours to get the site to load and the tests to run. We triggered a build in Jenkins proceeded to watch the console drown in DEPRECATION warnings.

Most of these deprecations were directly related to the eventual removal of the old ActiveRecord finder syntax to the newer Arel syntax initially adopted in Rails 3. Here are some examples,

DEPRECATION WARNING: Calling #find(:all) is deprecated. Please call #all directly instead. ...
DEPRECATION WARNING: Calling #find(:first) is deprecated. Please call #first directly instead.
DEPRECATION WARNING: Calling #scope or #default_scope with a hash is deprecated. Please use a lambda containing a scope.
DEPRECATION WARNING: Passing options to #find is deprecated. Please build a scope and then call #find on it
DEPRECATION WARNING: Relation#all is deprecated. If you want to eager-load a relation, you can call #load
DEPRECATION WARNING: Relation#first with finder options is deprecated. Please build a scope and then call #first on it instead.
DEPRECATION WARNING: The following options in your Model.has_many :notes declaration are deprecated: ...

Enter Arel Converter

The arel_converter gem is a simple command line utility that uses parses Ruby files to find code whose syntax will be deprecated under Rails 4 and converts it to be Rails 4 compatible. The converters use Ruby2Ruby and RubyParser to convert to and translate s-expressions. This ensures the code is converter back into valid Ruby code. Fancy regex and string parsing just doesn’t work as well.

Presently, there are 3 converters,


Converts ‘scope’ statements into the updated Rails 4 syntax, i.e. wrapped in a lambda, with pre-Arel options converted to Arel

scope :active, :conditions => {:active => true}, :order => 'created_at'
# becomes
scope :active, -> { where(active: true).order('created_at') }


Updates associations to use the updated Rails 4 syntax, i.e. wrapped in lambdas where necessary. Association types handled are,

  • belongs_to
  • has_one
  • has_many
  • has_and_belongs_to_many
has_many :articles, :class_name => "Post", :order => 'updated_at DESC'
# becomes
has_many :articles, -> { order('updated_at DESC') }, class_name: "Post"


Updates old ActiveRecord (pre Rails 3) syntax into Arel syntax of chained Relations. This handles the following, including chained calls,

  • Object.find(:all
  • Object.find(:first
  • Object.find.*:conditions
  • Object.all(
  • Object.first(
Model.find(:all, :conditions => ['name = ?', params[:term]], :limit => 5)
# becomes
Model.where('name = ?', params[:term]).limit(5)

Fortunately our application has a wide variety of calls to each of the above possibilities. Many of these variations ended up in the translator tests.


As with any software that could potentially update a wide swath of your codebase in one (terrible) moment, it is recommended that you are operating under some form of source control or have a reliable backup BEFORE running the script.

The converters don’t play well with multiline code blocks. This means that the parser will encounter a Exception (likely SyntaxError) when processing the first line. This is because the matching code is a simple grep of the file. Therefore, it would only grab the first line of a multiline statement. The good news is that these exceptions will show up in the results.

Check it out!

The gem is available at and the source is available on Github. Hopefully, it can save you or your team some time and pain of trolling through thousands of lines of code to get ready for Rails 4.1.a

Chiliproject to Redmine Converter

My company has been using Redmine as a basic project management tool for many years. A couple of years ago Redmine was forked by many of the developers to a parallel project known as Chiliproject. At the time we studied the roadmaps and goals of each fork and decided to move to Chiliproject. As the two projects has just separated the transition was fairly easy.

Fast forward two years, Redmine has a thriving community, has upgraded to Rails 3, releases regular updates and has a plethora of plugins. Chiliproject as floundered in comparison. The only updates that have been released in the past year have been to fix security issues in Rails or Ruby.

It was because of this we made the fateful decision to switch back to Redmine. Unfortunately, the projects are much farther apart in terms of the codebase and database structure. Add to this, Chiliproject has truly engrained itself in our company. We needed a way to convert back to Redmine without impacting the users.

After some research we came up with this script to do the job. It has fairly detailed comments, but if you notice any problems or have any comments feel free to add them to the gist.

Special thanks to my employer,, for allowing me to post this work back to the community.

Brew, git 1.8.0 & “-bash: __git_ps1: command not found”

I updated my machine this past weekend. This included everything from Mountain Lion to Homebrew (including all formulas).

As part of this update I moved from git 1.7.2.x to 1.8.0. After I did so and launched a new terminal I started seeing this fun error

-bash: __git_ps1: command not found

I checked the git 1.8.0 release notes but could not see any mention of a change to the prompt scripts. After much research (and gnashing of teeth) I discovered that the git shell commands that were responsible for making that nice prompt were moved from contrib/completion/git-completion.bash into a separate file contrib/completion/

To fix it I added the following line to my ~/.bash_profile above where I defined my prompt

source /usr/local/etc/bash_completion.d/

Where /usr/local/etc/bash_completion.d is where brew puts the completion scripts it installs.

I am no bash guru so I will not advocate that this is the best way to fix this problem.If you are a bash guru and know a better way please comment so we can all learn something.

Prefix Git Commit Message using Hooks

My team uses Chiliproject to manage our user stories. We have a team agreement to ensure that each commit message into our git repository is prefixed with the issue ID that the commit is related to. In addition to this we have a branch naming convention that also identifies the issue that branch is supposed to address. For example, a branch name could be, “rm-3454-customer-defect” and (hopefully) all commit messages will be prefixed with “RM #3454”. Chiliproject has some nice little features with linking and styling when the “#4233” pattern is found. However, it can be fickle. If you forget to put in a space, for example, “RM#3432” none of it will work.

Making sure this formatting is correct can be a real pain in the a**. Therefore, I took it upon myself to simplify things. The script below uses our branch naming convention to automatically prefix any commit message using the git “commit-msg” hook. You can see the code is this gist.

Put this code in the “.git/hooks/commit-msg” file at the root of your repository, make it executable and you are ready to rumble (of course, this will only work if using ruby).

ActiveRecord 3 based Rubygem

At our company we had to integrate with a legacy database system. To manage it we created a nice little gem to handle it. Basically the gem was just a collection of ActiveRecord models, nicely namespaced, so that we could include it in any application that made have needed access to that db. Code using the gem set it up as you would expect (in a Rails app we used a custom db connection in the database.yml):

require 'legacy_database'

This functioned great for many years and versions of ActiveRecord.

Jump forward to today, we have another separate database we need to connect to. Naturally, after the success of the previous gem we decided to create a new gem using the existing pattern, but this time we are going to use the new and fancy ActiveRecord 3 and its nice new Arel syntax.

We started building the gem and immediately ran into a blocker. Using the same code as above, as soon as the require was executed we get an ActiveRecord::ConnectionNotEstablished error. Nuts!

require 'special_database' # <= raises ActiveRecord::ConnectionNotEstablished

The backtrace showed us that when the gem was being loaded when it hits the first scope call Arel attempts to connect to the database. Why? I am not sure and I haven’t had time to dig around to find out if it is even possible to fix. Its a classic chicken/egg situation. You can’t initialize the connection until you load the gem and you can’t load the gem without initializing the connection.

In our situation we aren’t using the gem in concert with any other ActiveRecord connections so we are able to use ActiveRecord::Base to establish the connection.

require 'activerecord'

require 'special_database'
SpecialDatabase::Foo.find(1)  # It work's

I really don’t like it, but so far its our only option. Got a better solutions I’d be happy to hear it.