I first saw “cowork” as a concept on a Twitter post a year or so ago. Not knowing what it was, it forced me to create a new mental category about work environments. I come from a pretty traditional work environment. For the past 10 years, I’ve worked in a fairly typical office space. It was owned (or leased) by the company by which I was employed. I had a private office with door. It was certainly better than the cubicles of my youth, but I never thought much about it. It was just the office that you had to go to each day as a part of the job.

Read on →

I’m in the process of figuring out the best way to estimate time and cost on a proposal for an agile project. It’s always a tricky thing. Agile, by nature, is constantly embracing change and harnessing it for the good of the product and the client. So how do you communicate when it will be done or for that matter estimate how much it will cost?

I came across this quote from Ron Jeffries. It was so well put, I developed a giddy little grin and shouted out “AMEN”!

So here’s an example of how he answers the question, “So when will this project be done?”.

Right now, this appears to be a 200-point project. Based on our performance on other projects (or a random guess), with N programmers on it, and your intimate involvement in the project, a project of this size will take between 4 and 6 months. However, we will be shipping software to you every two weeks, and we’ll be ticking off these feature stories to your satisfaction. The good news is that if you’re not satisfied, you can stop. The better news is that if you become satisfied before all the features are done, you can stop. The bad news is that you need to work with us to make it clear just what your satisfaction means. The best news is that whenever there are enough features working to make the program useful, you can ask us to prepare it for deployment, and we’ll do that. As we go forward, we’ll all see how fast we’re progressing, and our estimate of the time needed will improve. In every case, you’ll see what is going on, you’ll see concrete evidence of useful software running the tests that you specify, and you’ll know everything as soon as I know it. (emphasis mine)

Ron Jeffries, as quoted in Mike Cohn’s book ”Agile Estimating and Planning”, Upper Saddle River, N.J.: Prentice Hall PTR – 2006

Now that is well put!


One of the things that I’m passionate about is the development process. So much of the battle is won or lost by the type of development process you have. Leaning on a couple smart guys, I’ve established a very clean workflow in git. If you haven’t read these posts, please do so before continuing. Both are excellent and will help clarify my question.

The only discrepancy between them is how to handle feature branches. Should you interactively rebase (git rebase -i) your feature branch to one commit (or possibly a couple)? Rein takes this approach. Vincent on the other hand prefers to leave the feature branch intact and do a non-fast forward merge (git merge --no-ff feature) to merge the feature back into the develop branch.

I’ve tried it both ways. Neither is right or wrong and both have their advantages.

Both go into the develop branch as a single commit, one as a normal commit and one as a merge commit. With the interactive rebase, you lose the granular commit history and potentially have a significantly larger commit. But you have a clear comment (with summary bullets if you follow Rein’s suggestion) as to what the commit it.

With a forced merge commit, you maintain the feature branch history which is nice to track down where some error entered the code, but the merge commit is auto-commented with something like ’Merge branch 'feature-x'’. It’s less clear when looking down the commit list of develop what is represented. Another downside of this approach is that you create a lot of unnecessary merge commits in the tree.

At this point, I think I lean more toward the interactive rebase over the merge, but I’m still not thoroughly convince. Have an opinion, please let me know in the comments.


For the past few years, I’ve used Slicehost for all my production hosting needs. I have been very happy with them. Recently I had a need for a new staging server. It takes a good amount of time to set up a site from scratch on Slicehost, which is fine for production servers, but I needed a site up quickly.

I’ve been using Heroku’s incredible service recently for staging sites. This site however had a ton of uploaded images and I really did want to go through the hassle of setting up S3 for use with Heroku. So I started looking for other options and found Webbynode.

Their ReadyStack concept made it really easy to get a VPS server up and running quickly, yet you still have full access to the server as root (same as Slicehost). Their web user interface was clean and enjoyable to use. For my situation, it was the best of both worlds. I wasn’t limited by a read-only file system like Heroku and didn’t take nearly the time to set up and configure as Slicehost.

I ran into one bug where you couldn’t use certain special characters in your root password, but got a prompt reply that they would look into it. Overall, I was very pleased. Good work guys.


I created a fork on github to ease deployment of Fat Free CRM to Heroku. I found this great post about doing this very thing, but I wanted something a little simpler.

For the impatient, here’s the quick Heroku install:

$ git clone git://
$ heroku create
$ git push heroku master
$ heroku rake crm:setup USERNAME=myusername PASSWORD=mypass

Essentially, all I’ve done in this fork (as of this writing) is:

  1. Remove all of the stylesheet and javascript caching directives
  2. Fix a minor issue in the config/ file

You can always check it out at the wiki.

UPDATE: Sept 20, 2010

I’ve updated my heroku-friendly fork on github to use version 10.1 of FFC. Let me know if you have any issues. Thanks.


I was initially enamored with the capistrano like features, yet simplicity of Vlad the Deployer. I spent 2 days getting the “simplifed deploy” working. Well, I thought it was anyway. Turns out that it wasn’t deploying the correct version from git.

I found a bug in Vlad which was fixed in master, but wasn’t in the gem. Then I found another bug in the vlad-git. It turns out ktheory had forks of each with the bugs fixed, but with different gems. I tried to use those, but still wasn’t getting the expected results.

This is simplicity?!?!

I never had any issue with capistrano. So I went back to old faithful. In 10 minutes, I was back to the beauty that is:

cap deploy

Here are a coupleparting thoughts on Vlad:

  • I understand why they broke out all the plugins, but it was a hassle to deal with
  • There was virtually no feedback as to what Vlad was doing during a deploy. I much prefer capistrano’s output on deploy.

I finally did it. I took notes as I built a server and am posting it (mainly so I don’t forget). In case someone wants to print this, I left most of the URLs in text so you’d be able to read them. So here it goes.

I am doing this on Slicehost and decided to user Ubuntu Hardy 8.04.2 as the OS maily for the long term support.

Core Setup

Initial Config

Ruby Enterprise Edition, Nginx, Passenger

I followed this great guide:


The latest version of rubygems was install after install REE.

sudo gem update --system
sudo gem update

Install all the gems I normally use. Just too many to list.

Create/edit ~/.gemrc with

gem --no-ri --no-rdoc


If you use aptitude, you get an old version 1.5.4.x

I did this to get the newest version installed. You need the build dependencies for it to work.

sudo apt-get remove git-core
sudo apt-get build-dep git-core
tar xvzf git-1.6.6.tar.gz
cd git-1.6.6/
./configure --with-tcltk
sudo make install



sudo gem install mysql

Migrate existing datbase from Heroku

  1. sudo gem install taps
  2. Copy your existing .heroku directory from your dev box to the deploy server.
  3. Create your production db
  4. rake db:migrate to get all the struct created
  5. Pull that db down. For the prayerthread app:

    heroku db:pull --app prayerthread mysql://root:pass@localhost/prayerthread_production


Good reference if you’re setting up a full scale mail server:


Cobbled deploy recipe using:

Deployment Issues

There were 3 of them:

  1. Vlad error

     Usage: /usr/bin/git-submodule [--quiet] [--cached] [add [-b branch]|status|init|update|summary [-n|--summary-limit ] []] [--] [...]
     rake aborted!

    The issue is because Hardy has an older version of git 1.5.x. Once I upgrade to 1.6, it is fine.

    There was a commit to fix this but it wasn’t yet in the gem. I manually patched the gem file. to address the issue.

  2. Cloning from a remote git repo

    This is an issue when cloning from (or You need an ssh key to run vlad from the local box to the deploy server, but then vlad executes the clone from the deploy server so an additional key pair is needed. I looked at setting up ssh forwarding, but these directions weren’t clear enough for me. couldn’t find clear enough directions.

    Instead, I just created a deploy key pair and uploaded the pub key to unfuddle. That authenticated me but since I am connecting over a non-standard port, I still had an issue.

  3. SSH Config for non-standard port

    On the deploy box, I needed to tell SSH to use the standard port to connect to unfuddle. Add the following to ~/.ssh/config as noted here, under theSSH Config section:

      Port 22
      IdentityFile ~/.ssh/unfuddle_rsa
      TCPKeepAlive yes
      IdentitiesOnly yes

I love Heroku, I really do. They have eliminated nearly all of the hassle surrounding deployment and server management in the Ruby/Rails world. Here’s the rub…

They are simply not affordable for the little guy.

“But Ryan”, you say, “what about the free plan?” The Blossom-1 plan is great and you do get a lot of value (including some really great free add ons). The problem come when the site starts to grow.

The free plan is basically loss leader – “a product sold at a low price (at cost or below cost) to stimulate other, profitable sales.” It is how they draw you in, and draw you in they do. It is an awesome service.

As soon as you need to grow the site just a bit, the price jumps significantly. It’s a great value at the entry level and, as best I can tell, for larger scale sites as well. It’s the smaller site with little to no revenue that feels the punch.

Let’s get specific. I’m starting a new project and my choice was Heroku at $0/mo or Slicehost (who completely rocks as well) at $20/mo for 256MB VPS. A no-brainer. I chose Heroku. It was easier, simpler, and far less work.

A couple weeks later, I have some beta users and want to roll out a new notification feature that will require some background processing. To get 2 application processes (dynos) and run a background job, the price jumps from $0 to ~$72/mo (2 dynos + 1 worker = Blossom-3). If the database grow beyond 5MB, the I would need to move to Koi-3 at ~$87/mo.

Pretty soon I need to send more than 200 emails per month so I need to add the SendGrid Premium add-on for $20/mo bringing the total up to ~$107/mo. On the Slicehost side, I have to do all the work of setting up, configuring, and maintaning the server, BUT I am still paying $20/mo. I may need to ramp up to the the 512MB slice but I’m still at only $38/mo.

That’s an estimated ~$69/mo savings. When you are bootstrapping a small project, that it significant.

Let me reiterate, I love heroku. I wish there was a plan that was more reasonable at the lower end. Since there is no comparable path on the Heroku side, I’ve decided to migrate the project back to Slicehost.

Stay tuned for my notes on building an Ubuntu slice. I’m going to document it this time. Really. I will.


My employer called me this summer while I was on vacation at the beach with my family to let me know that the doors to our office would be closed upon my return. Not the best news to get when you’re trying to get refreshed and renew the mind.

Thankfully they gave us a three month window to work from home. That window ended October 31, 2009. I have been toying with the idea of making a living as a consultant for, say, about 10 years now but never had the courage to pull the trigger. I guess I can thank First Data for pulling that trigger for me.

I’m not sure what the road ahead has in store for me, but my “spare time” consulting company Sourcescape is now getting pushed to center stage. I’m looking forward to the adventure.


I was out on a date with my wife last week and in usual fashion, we popped into a Barnes & Noble. She grabbed the lastest edition of People magazine and I wandered over the the “geek” section to browse what’s new. I picked up Programming Erlang: Software for a Concurrent World. I figured I would just skim through it put is back but I got hooked.

I’m not sure why, but I really I got hooked. I bought the book. Being primarily a web developer, I have no idea what I’d even use Erlang for, but I haven’t really learned a different paradigm of programming a number of years. So the journey begins. Maybe I’ll burn out with it or maybe I’ll build a bridge and be able to see where I could use it in the future or maybe it will just help be to be a more well rounded developer. Time will tell.