Development Team Best Practices


I wanted to put together some thoughts on high level best practices for your dev shop.  These practices will skew towards larger dev shops inside of big corporations but can also be applied to 1-2 man teams.  These thoughts are inspired by a combination of The Pragmatic Programmer and The Joel Test.  I read both of these sources early in my career and they have continuously provided inspiration on what kinds of practices highly effective dev team should follow.  Futhermore I’ve found it surprising how many shops I’ve worked with that break these practices.  Following these practices will increase your dev team’s effectiveness, making for happy developers and manager.  Breaking these practices will result in a slower development velocity and frustrated developers and managers.

  • Streamline your local build process.  

Do you think your build process is pretty fast?  It could be faster.  If it takes more than a few seconds to redeploy your code you lose your train of thought – and there is a cost to putting that train back on the rails.  As someone who has spent a lot of time doing Enterprise Java development, it often amazes me what developers will put up with in their build processes.   Here are a couple of tips to decrease build time:

    • Your environment probably supports some sort of hot swap method where you don’t need to do a full build after every change.  Java’s JVM Hot Swap feature allows this for some cases.  I’ve also heard very good things about JRebel.
    • If you have a medium to large sized application, you probably don’t need to rebuild the whole thing all of the time.  Make sure you’re not rebuilding more components than necessary.  Here are some kinds of things I’ve seen automatically included in a full build that could be excluded from a “fast” version of your build: code generated from wsdl/xsd, database migrations, unit test suite execution, minification/obsfucation of js/css.  In Java, the war/ear step will package all of your files into a war/ear.  When you deploy that war/ear to your application server it will unpackage all of the files.  You can eliminate a step by just copying your war/ear directory directly into your application server.
  • Use a debugger.  

Do you test your application by inserting new log statements and redeploying?  Stop it!  One of the best ways to cut down on redeploy time is to not have to redeploy.  Every single commercially used language supports debugging.  Here are a few links to get you started using a debugger with your language

  • Automate your QA builds and minimize QA downtime

Your QA build process should be quick and painless.  I would shoot for a combination of automated QA builds (2 or more times per day) and one-click, on-demand deployments.  The outage to a QA environment needs to be small – 5 minutes or less – to keep the deployments painless enough to not disrupt the workflow of the QA staff.

Doing frequent, automatic QA builds does a couple of great things for your IT organization- it sets a precedent that your team has the ability to quickly turn around fixes.  It also minimizes the impact of bugs in your QA process;  After all, if your team finds a bug, it’s not a huge deal since the bug might be resolved in a few hours.

Contrast this approach with an organization I recently worked with that only did two QA builds per week because their build process took so painfully long to complete.  Every bug became a news headline.  The management team would often choose not to fix bugs because of the huge turnaround time and the risk of additional lost time in case a bug fix was not successful.

  • Treat database schema updates like source control

 SQL is code, and your database structure is the product of that code.  In the same way that every developer working on a project needs to be able to run the software on their local system, those developers also need to be able to run their own copies of the database.  Database changes should be part of your normal build process, and like your code, your database schema needs a version so you know which changes have been applied.  This helps keep your development, test, and production environments all in a sane state.

It’s easy to fall into the trap where a database is very difficult to create so you end up running one development database for all of your developers to share.  The problem comes when you need to support multiple work streams at the same time – this means you need to simultaneously run multiple versions of the schema at the same time.  You can work around this problem by adding more schemas and more hardware, but the overhead involved may make it really difficult for developers to do the kind of risk taking and rapid iteration required to reach a high velocity.

I recommend using flyway or liquibase to manage database changes for most technology stacks.  Rails has built in support with Active Record Migrations.

 That’s all for now.  Please send feedback in the comments if this post has helped provide value for your team, or even if it seems too rudimentary.  I’d be happy to do a deeper dive on any one of these topics if there is interest.

BeerDogging: a cross-platform mobile app with Phonegap and AngularJS, disected

Beer Dogging is a member organization committed to the promotion of Craft Beer.  Recently the owner of Beer Dogging, Don DiBrita, asked me to build him an app to his members deals to local bars and other Craft Beer related venues.   I wanted to share the process that went into building it since the results turned out pretty decent and within a short timeframe.

Overall Goals
-Give users quick access to beer dogging deals, sorted by proximity
-Keep Costs Low

App concept



As you can tell from the tile of this post, the technology stack includes Phonegap and AngularJS, but we also have a server components using Rails.  I believe that this stack gives you the maximum amount of exposure for the lowest cost, at least for small to medium sized apps.

Mobile Client: Phonegap, AngularJS, Topcoat, Google Analytics

The app is built in Phonegap, so that it can work on both Android and IOS platforms without much trouble.  The latest version at the time was Phonegap/Cordova 3.3.0.  Cordova as a platform has gained a lot of maturity over the last couple of years but still has a ways to go.  I’m pleasantly surprised at how well their new command line tools help you manage your project across multiple platforms, but still find some gaps in the workflow, and cases where plugins just stop working unexpectedly and need to be re-installed.  I stayed away from Phonegap Build on this project, opting instead to use the native SDKs on my OSX environment – it’s just faster IMO.  I also wanted to share my phonegap development workflow; hopefully it will help someone out there since it took me a while to figure out myself.

  1. Create the project with command line tools
  2. Add the android and IOS ‘platforms’ with command line tools
  3. Start a Ripple Emulator for your android platform.
  4. Setup a grunt task to automatically sync your web resources to the android platform
  5. Modify web resources in the www/ folder.  After they sync to to your android platform, refresh your ripple emulator to test the changes.
  6. Repeat until you’re ready to test on a physical device or a platform emulator
  7. Build & test on a native SDK (XCode or Anroid SDK)

I chose AngularJS as the main javascript framework.  I find that Angular provides the structure, REST support, and databinding for the sort of thick client we require in a mobile app.  Since Angular is backed by Google I expect it to continue to mature into a great client side javascript framework for many years to come, especially for mobile.

I’m using the Google Analytics Phonegap plugin (GAPlugin) for metrics gathering, and was happy about the amount and quality of metrics it gives you for not a lot of work.  This plugin allows GA to recognize your phonegap application as a real ‘mobile app’ instead of web app.

To polish off the UI and give the app that ‘mobile’ feel I used Topcoat .

Server Side : Rails, Heroku, Postres, Geocoder, RABL

On the server side we’re using a low-frills Ruby on Rails web application, who’s sole purpose is to serve JSON data about places and deals to the mobile application.  It also has an admin web interface where an admin creates/updates/deletes places and deals.  I used the RABL gem to format the JSON responses.

Geocoder is a ruby gem that helps you do geolocation queries (find all places within a 10 mile radius of me).  It is a must if your Rails app has any kind of location data.  I also use it in

I used Heroku for application hosting both for ease of use and cost.  We are using the single free instance today and have the ability to scale up to meet demand.  On the database side I’m using the free instance of postgreSQL that heroku provides.  It works for me and supposedly has pretty good geo query performance.

End Result:

featured deals page
iOS Simulator Screen shot Feb 9, 2014, 11.16.55 AM
deal detail page
iOS Simulator Screen shot Feb 9, 2014, 10.55.58 AM
places near me with search
iOS Simulator Screen shot Feb 9, 2014, 10.56.05 AM
About page
admin web interface
admin web interface

I want to talk for a minute about some of the design choices we made during the creation of this app.  Unlike a lot of sites with a membership component, you are not required to login or verify your membership status on the app in order to view or try to redeem deals.  We purposely decided to take a low-tech approach to this problem for now; Beer Dogging members already have physical wallet sized member cards, so in order to redeem an ‘Alpha Dog’ deal you have to show your member card in addition to showing your server/bartender the deal within the app.  This choice aligns with our Lean product development philosophy, and allowed the client to keep the cost down during initial development.  It is something we can add in the future when this app starts to take off.

Sprite Club

UPDATE: Sprite Club’s code has been open-sourced :


I have been working on a Facebook application in my spare time for quite a while now and I think that it is finally interesting enough to start telling people about.

Sprite Club banner

The application is a game called Sprite Club; it is a place where you can judge kids (sprites) on the basis of cuteness, and upload a photo of your own sprite to have them compete for internet fame.  The application is accessible from

or from the friendly url:

The idea was conceived by my uncle, Matthew Deutch, while looking for an outlet to prove that his daughter is the cutest kid on the internet (We think she’s pretty great).  I am in the project to learn how to do Facebook and social media development.  The application is written in Rails and uses the Facebooker library to interface with Facebook.


Facebooker – converting from FBML to iFrame

In my free time I dabble in Ruby on Rails development and Facebook application development.   Last year I picked up Mike Mangino’s book, Developing Facebook Platform Applications with Rails, which gives great step-by-step instructions for creating a facebook FBML application using the facebooker gem.

FBML is not the only type of Facebook application, however.  There is also the iframe method, which Lead Facebook Engineer Charlie Cheever has been endorsing for a while.  His blog post gives a good comparison of the two methods: .  In addition to this, the Facebook developer roadmap ( ) shows that soon you will not be able to create new FBML applications, and is recommending that existing FBML applications be migrated to iframe.  The message is clear: time to switch to iframe people!

Unfortunately the tutorials performing this kind of switch are hard to come by.  Mike Mangino has created a new RoR gem named facebooker2 to support iframe and facebook connect development but documentation is limited.

This blog post includes some documentation on how to convert a facebooker FBML app to a facebooker2 iframe app.  Read Charlie Cheever’s blog post to understand the architectural differences between the FBML and iframe approach, especially the bit about server-side FBML.  More details here:

Remove the facebooker gem

Get Facebooker2 and mogli

$gem install facebooker2
$gem install mogli

Reccomended: unpack gems to /vendor (

Update environment.rb, set


Create an initializers/load_facebook_yaml.rb file to read from facebook.yml.  It should include a single line:


Inside your facebook.yml file add the following two parameters to each environment config:
app_id: 131336175362
secret: f7b15a925058e7be60f0a4d56294e938

Application controller

Rename application.rb to application_controller.rb. Add the following command to your application_controller.rb

Include Facebooker2::Rails::Controller

Comment out the set_current_user method

Paste in this method:

def current_user
if session[:user_id]
@current_user ||= User.find(session[:user_id])
elsif current_facebook_user and @current_user.nil?
@current_user = User.find_by_facebook_id(
session[:user_id] =

Add a ‘ensure_authenticated_to_facebook’ method to keep making sure that the user has a facebook session when accessing your site.  In my case my sessions/login page just displays “please login to facebook”, and since we’re in an iframe in the context of, there is a facebook login prompt displayed immediately above my page.

before_filter :ensure_authenticated_to_facebook
def ensure_authenticated_to_facebook
if current_user == nil "current user is nil"
redirect_to :controller=>'sessions', :action=>'login'

With Facebook Connect it is not required that your application runs inside the context of  Your login page could technically detect if it is running in and only display “please login”, otherwise if you are running it as a standalone page present the user with a facebook connect login button.

Enable oauth 2.0.  This will facebook cause to send a “signed_request” request parameter to your application once the user has authenticated.  Mogli will use this token to authenticate the user and create the current_facebook_user object.

Copy/Rename your .rhtml.erb files to .html.erb.  You will no longer have a canvas and will never render rhtml files again.

Remove  <%= facebook_messages %> in your erb files or replace them with <%= flash[:error]  %> or <%= flash[:error]  %>

Put the facebook connect javascript initializer in your layouts file so that it gets executed during each page load

<% fb_connect_async_js do %>
<%= yield :fb_connect%>
<% end %>

This should always be the first snippet of javascript to be executed as it will instantiate the FB global variable that the rest of your page will probably use.

Start going through your erb files and replace FBML code with <fb:serverFBML /> and their javascript SDK equivalents. This is pretty much the final step and will require the most effort. Use the documentation and test console found here:

-facebooker2 reference project:

-images for stream publisher popups need to be accessible by facebook servers.  You used to use a reverse tunnel so facebook could read them directly from your local server.  If you have images that fall into this category you may still need to use a reverse tunnel.

Rails 2.0 killed my site

My website has been down for the last 2+ days. The reason: Dreamhost upgraded to Rails 2.0 without any warning. Since some of my code was not 2.0 compliant – BAM! down goes my site.

In case I can help anyone else out of a bind, or avoid this horrible fate, here are the steps I had to take to get my website back up and running with Rails 2.0:

  1. Add a config.actioncontroller.session entry to my environments.rb file. I added it within the Rails::Initializer block. This was in response to the following error I found in my production.log file:
    A secret is required to generate an integrity hash for cookie session data. Use config.action_controller.session = { :session_key => “_myapp_session”, :secret => “some secret phrase of at least 30 characters” } in config/environment.rb
    Luckily the error tells you exactly what to do
  1. Next, I had to fix this error:
    undefined method ‘paginate’
    I fixed it by installing the plugin ‘classic_pagination’. To do this you simply have to run
    “script/plugin install svn://” from your project root.
    Apparently they took out built-in pagination support from Rails 2.0. This will_paginate plugin is supposed to be better, but I didn’t care to figure out how to work it right now.
  1. Finally, I had to fix all of my start_form_tag entries.

There was a good demo of how to do this in the what’s new in Rails2? slideshow

ClickOnChris is Web 2.0!

 have implemented AJAX style comments system. If you click on the ‘Add Comment’ button below you can see it. The difference is that now you are presented with a comments form appears within the existing page instead of a comments form being on a new page, as was the previous behavior. This is AJAX, and it is the technology that people are calling Web 2.0. 
What’s the big deal you ask? By having the ability to only update parts of a web page instead of updating the whole page every time you invoke some function, it makes the browser act more like a desktop application than a web page. The end result is more robust applications served over the web. Think google maps or facebook.

Implementing reCaptcha in Your Rails Application

Recently I started noticing a lot of spam posts on my website. It must be those internet hacker bots! I wondered if I could put one of those fancy image verification things into my site to stave them off. They’re called ‘captchas’ and it turns out that its simple and easy to implement such a thing in Ruby on Rails using the reCaptcha plugin. Here are the instructions I wish I had when I started:

  1. install the reCaptcha gem. I’m using Aptana/RadRails IDE which has a nice interface to install gems, but I hear you can install it via the command line with something like ‘gem install reCaptcha’
  1. Register for public and private keys at .This is also a good tutorial of how a captchas and reCaptcha works. You will have to add your public and private keys to your config/environment.rb file.
  1. insert the reCaptcha function calls into your code:
    recaptcha_tags() – put this into your®html form to generate the challenge image.
    verify_recaptcha() – when inserted into the controller, checks the data passed from the form to make sure that the correct ‘answer’ was given. returns boolean

Thats it! Add a comment to test it out!

Web host switch

 have switched web hosts as of today from Axishost to Dreamhost. Axishost was very good, but their spamassasin has been broken for about a month and I couldn’t take it anymore!

I’ve also lowered my yearly hosting costs from $72 to $23(Dreamhost promo code: DOIT). We shall see how Dreamhost measures up.
Update: The switch went pretty smooth, although this was the most complicated one yet due to the fact that I’m using Ruby on Rails and running a photo gallery. The procedure was basically:

  1. Copy Data
  2. spoof new DNS by modifying ‘hosts’ file. This was required to access phpmysql and to test out the site.
  3. Export/Import Mysql databases.
  4. redeploy website.

I can tell the difference with Dreamhost using fastCGI. The site usually loads a lot faster. My only complaint so far is that Dreamhosts spam filtering solution isn’t as good as axishosts. Supposedly I can install a better one but I haven’t gotten around to it yet.

Axishost lackluster Rails support

As I get more comfortable with Ruby on Rails development, I have been looking to take advantage of Subversion and FastCGI – tools that are vitally important to any halfway decent rails environment. Subversion (with Capistrano) helps automate deployment, while FastCGI helps your rails web pages load quickly. At the moment, my website seems sluggish at best.

My hosting provider, Axishost , does not seem concerned about providing either of these tools to its customers. When I asked about subversion support, I got the following response:

Thanks but no thanks guys. I picked this host specifically because it advertised that it supports Ruby on Rails (and its 99.9% uptime guarantee is pretty nice). The reality seems that Axishost only partially supports Ruby on Rails. This environment is not good enough for any Rails application worth a damn.

Hi Chris, At this point there are no plans to add subversion to the servers, nor is it on schedule for the near future. If the demand increases it may become a more viable option, but at this point it is not.

Please let us know if there is anything else we can do for you!

It was the same story regarding FastCGI

FastCGI is not installed.

Get it together Axishost