Introducing Rails Rescues


Today I’m happy to introduce Rails Rescues.

Rails Rescues is a service representing years of Ruby on Rails experience organized to help companies who have a Rails application but may be having some problems.

Rails Rescues aren’t limited to a fixed set of services but can include:

  • Scaling your website
  • Resolving site stability problems
  • Upgrading from an old version of Rails to current versions
  • Fixing Broken Code
  • Simplifying an out-of-control code base.
  • Finishing up after your contractor or employee left the project.
  • ….we’ll fix anything holding you back from a successful Rails web site.

I’m happy to offer a $500 finders fee for any referral sent that results in a sign Rails Rescues contract.  Please spread the word and visit the site. I will make myself available via live chat to answer any questions.



Minitest Not Running My Unit Tests

I have started using minitest for Rails 3.x unit testing and since it comes with Ruby 1.9.x by default, it seems like a good direction to take my testing.

I am using the great gem by Mike Moore called minitest-rails which has a minitest dependency so I can easily have the latest version of minitest.  This gem helps to more cleanly integrate and use minitest in our Rails 3.x projects.

As part of my setup I use Autotest so my tests run automatically when files change.  I noticed none of my unit tests were running and upon further inspection, minitest was looking in test/unit and test/unit test directories but not in the test/models folder, which seems to be the minitest default.  

Opening up my .autotest configuration file and adding the following:

Autotest.add_hook :initialize do |at|
 at.add_mapping(/test\/models\/.*\.rb/) do |_, m|
  at.files_matching %r%^test/(models)/.*\.rb$%

After restarting autotest, my unit tests are now being tested.  I hope this saves someone some time.

Rails Views and Backbone.js with David Heinemeier Hansson

This is a great discussion with DHH about the Basecamp rewrite, not going crazy using Backbone.js, like so many developers are doing these days, for everything.  One technology used is PJAX, for updating small bits of a view to give small, fast updates.  PJAX combines HTML5 pushState and AJAX to make the fast magic happen.

PJAX is a great example how to use the views we know and the fast updates we need instead of completely changing the way Rails developers approach views using tools like Backbone.js, Knockout and others.

The discussion is about 1 hr 40 min long but well worth it.  You get some good views of new Basecamp Rails code and the usual colorful dialog.  

David had a great post on the 37Signals blog that serves as some background to the above talk titled How Basecamp Next got to be so damn fast without using much client-side UI.

Mixing Secure and Non-Secure Assets in Your Web Application

The life of the web developer never seems to be easy, always a new problem cropping up.

The Problem

One such issue surfaced when a client wanted to begin accepting credit cards.  As most Internet users assume, they land on a web page asking for credit card information and it’s secure, I wouldn’t enter my credit card information without seeing the friendly little lock.  Another telltale sign is seeing the https: in the browser address bar.

Many sites today make use of outside CSS and JavaScript files host on a content delivery network (CDN) somewhere on the interwebs.  This has tremendous benefit for web developers and users alike, giving applications better performance.  The problem arises when we have a secure page (https) which pulls in assets from non-secure CDNs, where requesting assets securely will fail to return successfully and ruins the user’s experience.

This application happens to be a Ruby on Rails application but that fact is irrelevant.  The scenario is likely common today; we have a secure checkout page but our site contains menus and links to pages which are not sure but just plain http.  When the users visit the site with their browser of choice they are presented with various messages or maybe none.

  1. Firefox 6/7, no message..just no indication the page is using SSL.
  2. Chrome, no message but a red line through the “https:” in the browser address bar.  This does not give confidence to the user, I would not put my credit card information in this page.
  3. Safari, no messages and everything looks good with the exception of the missing tiny lock icon indicating a secure page.
  4. Internet Explorer, well this is the least friendly of the browsers telling the user there is mixed content and prompted with how to proceed.

The problem was mainly centered-around the Yahoo YUI JavaScript and CSS assets and how they were included.  This application uses the Yahoo content delivery network (CDN) to serve the assets, which is a great way to serve the assets.

The Solution

I decided to do what every self-respected web developer does when facing a problem, Google for someone else who had the same problem and successfully solved it.  I ran into one very insightful post from Dan over at CollectiveIdea.  The post lays out a very similar problem with some good ideas for the solution.

Dan points out a URL like this:

<script src="" type="text/javascript"></script>

Will cause Mixed Content warnings when included from a secure page.  Some of the suggested solutions include downloading all of the assets locally and the problem goes away.  Although this is true, we lose the benefits of using a CDN.

What works is both elegant and simple; two qualities that make my day.  Referencing your CDN-based assets this way is only a slight change:

<script src="//" type="text/javascript"></script>

Notice how we are referencing the GoogleAPI URL, we leave off the http: and the https:.  By using two forward slashes only the request will resolve itself and work brilliantly.

Maybe I am the last web developer to find out this tidbit of information but I wanted to document it so the next one faced with this could find the answer here.

The Simplicity that is Pow

Logo pow

Simplicity is a beautiful thing.  I love a simple tool which makes my life as a developer easier.

Ruby on Rails has made the life of the web developer much more pleasurable over the years but even so there are some things which could be made better.  One such thing is running your Rails applications locally when developing.  Every Rails developer is familiar with the script/server command if you are in Rails 2.3 and earlier or the rails server command if you are using Rails 3.  The next step would be to fire up the browser and enter localhost:3000 into the address bar.  Most of the time this works fine, but a bit tedious.  The real problems appear when your application supports subdomains like, which has been hard to do up until this point.

Enter Pow

Pow is a Rack server developed by the folks at 37Signals to help alleviate the pain of serving local Rails applications.  Using Pow allows the developer to go from accessing their local Rails application using localhost:3000 to something like  For example, my expense tracking software, Expens’d uses subdomains quite a bit, so we get URLs like and when using Pow I can simply use the URL  This is perfect and simplifies the process.

Setting Up Pow for Serving Rails Applications

Installing Pow is pretty easy and shown on the Pow web site but for those not interested in heading over there you can open up a terminal session and enter the following:

$ curl | sh

Each application has to have a symlink defined.  The Pow web site says to:

$ cd ~/.pow$ ln -s /path/to/my/app

When I setup Expens’d to use Pow setting up the symlink this way didn’t work for me.  I had to add the application name after the path, like this:

$ ln -s ~/rails_apps/expensd expensd

Since Expens’d is currently a Rails 2.3 application, a file is needed and placed in the application root folder.  The file should contain the following:

require "config/environment"
use Rails::Rack::LogTailer
use Rails::Rack::Static

If Expens’d was a Rails 3.x application, I would not have had to create the file.

Your mileage may vary.  Once the symlink is done heading to the browser you can just enter the domain for the application with the .dev extension, like  This works just perfectly.

Restarting Your Application

One of the first things I wondered about when using Pow was a need to restart the “server” when I make changes to a routes.rb file.  It turns out we treat this the same way we restart Passenger.

$ [APP_ROOT]/touch tmp/restart.txt

Log File Monitoring

Using Pow provides us with the typical development.log file in the [APP_ROOT]/log directory.  Keeping an eye on the log can be done from a terminal window.

$ [APP_ROOT]/tail -f log/development.log

This provides  a nice way to see what’s going on.  There is also a raw log file produced from Pow that gives some additional details.

$ tail -f ~/Library/Logs/Pow/access.log

Potential Issue

When I setup Pow on my Mac Pro it all worked perfectly from the get-go but on my MacBook Pro I ran into a problem when I tried to browse a URL served by Pow such as  DNS seemed to think I wanted to go to the Internet to find the site and I received a 404 error when I tried.    The problem was known and is outlined on Rob Conery’s site.  The first part of the solution involved running the scutil to see if .dev resolver was being used:

$ scutil --dns

You should see a bunch of entries and one should look something like this:

resolver #8
  domain : dev
  nameserver[0] :
  port    : 20560

I don’t know if Pow uses the same port all the time, so that may change.  The key here is the domain, indicating dev.  If this resolver is missing the solution is pretty simple, open the file /etc/resolver/dev and simply save it.  Worked like a charm for me.  Run the scutil –dns command from above and see if the resolver is now listed.

A Better Pow?

I think Pow is pretty awe some just as it is but it seems someone has stepped up to make it even better with a gem named Powder.  I haven’t had the chance to play around with this tool yet but a blog post by one of it’s creators says they wanted to make Pow “ridiculously easy”.  The commands supported help make Pow that much easier:

$ powder applog
=> tail the log of the current app
$ powder config
=> Get Pow's current configuration information
$ powder list
=> List all the current apps linked in ~/.pow
# aliased as powder -l
$ powder log
=> Tails the pow log.
# Not the application log, but the pow log, available at
# ~/Library/Logs/Pow/apps/#{app-directory}.log
$ powder open
=> Opens the pow link in a browser
# aliased as powder -o
$ powder open bacon
=> Opens in a browser
# if you have set up alternative top level domains in .powconfig,
# then the first listed domain will be opened.
$ powder restart
=> Restart the current app
# aliased as powder -r
$ powder status
=> Get Pow's current status information
$ powder version
=> Returns the current powder version
# aliased as powder -v

More Than Rails Applications

Since Pow is serves up Rack apps the possibilities are pretty endless.  I found one bit to share where someone is using Pow to serve his PHP apps, pretty clever.  I would imagine this technique could be used in many applications like this.


The only thing I can say is I love Pow.  It has made my life so much easier.  Thank you 37Signals.

2010 Year in Review and Looking Ahead

I don’t always do these types of posts and I almost didn’t this year but I figured it would help keep my thoughts together to reflect on later.

2010 was a really busy year and there was very little rest.


It has been just over a year since I acquired Expens’d from Atlantic Dominion Solutions.  The past year has really been about understanding the application, how people are using it and fixing some obvious bugs that plagued my users.  We added several new features requested by users but did not add the features I am dying to tell you about.  Unfortunately, I can’t say just yet what is being added but it will be great for our users.

Subscribers are continuing to increase, both paid and free accounts.  Advertising consisted of Bing, Google Ads and Facebook Ads.  I was surprised to find Bing brought in the most new users.  I don’t have exact numbers just yet.

Running a Software-as-a-service (SaaS) project is interesting and exciting, I have learned a lot in the past year and plan to share the details as we move forward.

Ruby on Rails

My complete move to Ruby on Rails and especially Rails 3 is almost complete.  I have one client remaining who I still provide consulting services to who is a .NET shop.  Once this project completes in 2011, my .NET career will come to a final end.

Rails 3 has really been a joy to work with, not in a single aspect but in the areas the team improved.  The areas which annoyed me in Rails 2.x are mostly rewritten and the pleasure continues.

I think Rails 3 is going to be a huge turning point for the Rails community.  This version could lead to better adoption in the enterprise and other organizations unsure of the platform.

An Epiphany

I would say about halfway through the year I came to realization that no matter how great it was to work with Ruby on Rails or any programming language and framework is, client work is not the joy it once was to me.

Since that time in the summer, I have been diligently working toward becoming 100% reliant on products.  These products include both web applications and mobile applications mainly targeting small businesses.  I continue to look for products to acquire which fit in with my plans.  If you know someone looking to sell, send them my way.

The transitions to 100% products is not as simple as flipping a switch, it takes time and planning.  My goal is transition complete by the end of the year.

All of my current products and projects are now Rails, future products will also Rails.  As consulting work winds down I will set some time aside to work on selected consulting projects that are particularly interesting.

Mobile Exploration

After purchasing a Motorola Droid X earlier this year and hearing how Android is gaining such market share I had to see what the hype was about.  I rejoined the Apple iPhone developer program and the Android Marketplace to make sure I had the latest information and tools.

Spending several weeks with both platforms to expose myself to iOS 4 and Android development I came back with an initial gut feel where my tolerance for risk versus the state of each platform and determined Android was not ready for prime time yet.  It is not as polished, tools are weak and making a reasonable living is a lot harder than with iOS.

This set my course from a mobile standpoint that I would focus on Objective-C on iOS and leave Android for another time, a more mature time.

The Year Ahead

I attended only one conference in 2010, which was RailsConf in the first half of the year.  I hope to change that in 2011.  I will be attending RailsConf again but want to take in some smaller, regional technical conferences as well as some business-related ones as well.  Maybe the Business of Software Conference this year.

2011 will be a year of transition from consulting to a products company.  I plan to blog more here about running a software company, some technical stuff but mainly about the factors behind technical decisions.  Some will be code, some will be me blathering on.

I have some ideas for other products to develop this year and some significant plans for Expens’d.  The journey will likely not be taken alone as one person cannot do it all, cannot know it all.

I am looking forward to this journey, things will certainly get exciting.