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'
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:
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.
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
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.
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
Fortunately our application has a wide variety of calls to each of the
above possibilities. Many of these variations ended up in the translator
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 rubygems.org 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
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
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,
CanadaDrugs.com, for allowing me to post
this work back to the community.
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/git-prompt.sh
To fix it I added the following line to my ~/.bash_profile above where I defined my prompt
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).
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):
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!
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'ActiveRecord::Base.establish_connection(...)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.