knock.on_wood

CoWork: The First Month

2010-11-29T14:04:41-05:00

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.

In August 2009, I was informed that my “job” would be ending as all software development would be moving to the home office in Houston, TX. I was given three months notice. It was November 1st before I knew it and I was no longer employed. While searching for another job, I decided to ramp up Sourcescape, my then part-time consulting business. The economy had other plans. I couldn’t find much work and there were no full-time jobs on the horizon.

Fast forward 10 months. It’s September 2010, Sourcescape is gaining some momentum. I’m working in various places. Some days I’m at home, others are in coffee shops, and others are in my good friend’s office who graciously offered me some office space. I see through Twitter that CoWork Greenville is expanding and taking applications for full and part-time spots. This got the wheels turning and I decided to learn more.

Figuring it Out

Was it just a place where people who were fed up with coffee shops go to work? What was the benefit? After all, I have some space to work at Amy Adele for free. However, I was isolated and really missed working with other intelligent people in my field. Maybe I should check out CoWork and see about coming down there a day or two a week.

It just so happened that the CoWork Greenville open house for their new location was around the corner, so I decided to go and check it out.

What I found was some of what I expected and something that I didn’t. It was a group of “web people” work worked in the same building, some working together, some independently, all growing their businesses. That, I expected. The surprise came when I realized that this was more than just a common work place. One of the overarching goals was to build a community of independents that could make an impact on each other and the greater Greenville community.

It’s hard to nail down what that means or how it will play out, but it was something that I wanted to be a part of. It seemed clear that joining the community would be tough to do once or twice a week. Even though Sourcescape wasn’t exactly in the place financially to justify the move, I felt like it was clearly where I needed to be. I took a leap of faith and signed a 1-year lease to become a CoWorker once the new location opened on November 1, 2010.

The First Month

The first week was a tough adjustment. Not only did I move to a new office, but I has just taken on a new client working with the great team at Rails Dog. It has been a long time since I’ve been one of the the new kid on the block. It was clear that many in this group had been working together for a while. The recent move brought a few of us new guys to bring the CoWorker count up to 16.

It’s always tricky navigating a new environment. So far, though, it’s been well worth it. As providence would have it, I’m fortunate to sit next to the super talented Matthew Smith of Squared Eye fame. As I get to know each of the guys (and girl) at CoWork, I continue to be amazed at the graciousness, talent and depth that this group brings together. I count myself blessed to be a part of it.

I have little idea of the the future holds for CoWork, or for Sourcescape for that matter, but I’m convinced that it is a journey worth taking and one that will continue to surprise me and bring a smile to my face.

If you’re interested in seeing how things unfold, please join us on the journey. You can follow us @cowork on Twitter or check out the CoWork photo stream on Flickr.

As always, I’ll occasionally blog right here.

When will this project be done?

2010-09-29T23:25:00-04:00

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!

Git Workflow: Merge or Rebase

2010-03-14T12:09:13-05:00

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.

Webbynode Review

2010-03-01T08:04:00-05:00

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.

Fat Free CRM on Heroku

2010-01-21T23:34:00-05:00

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://github.com/ryanwood/fat_free_crm.git
$ heroku create
$ git push heroku master
$ heroku rake crm:setup USERNAME=myusername PASSWORD=mypass EMAIL=my@email.com

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

Remove all of the stylesheet and javascript caching directives
Fix a minor issue in the config/config.ru 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.

Bye bye Vlad

2010-01-21T23:23:00-05:00

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.

Ubuntu Hardy LTS Slice with Nginx, Passenger, Git, Vlad and more!

2010-01-15T23:41:00-05:00

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

http://articles.slicehost.com/2008/4/25/ubuntu-hardy-setup-page-1 http://articles.slicehost.com/2008/4/25/ubuntu-hardy-setup-page-2

Ruby Enterprise Edition, Nginx, Passenger

I followed this great guide:

http://antoniocangiano.com/2009/11/20/setup-ruby-enterprise-edition-nginx-and-passenger-aka-mod_rails-on-ubuntu/

Gems

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

http://docs.rubygems.org/read/chapter/11

Git

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

http://serengetisunset.wordpress.com/2009/02/28/installing-git-1613-on-ubuntu-804/

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

sudo apt-get remove git-core
wget http://kernel.org/pub/software/scm/git/git-1.6.6.tar.gz
sudo apt-get build-dep git-core
tar xvzf git-1.6.6.tar.gz
cd git-1.6.6/
./configure --with-tcltk
make
sudo make install

Source: http://brunomiranda.com/past/2008/5/12/deploying_github_repository_with_vlad

MySQL

http://articles.slicehost.com/mysql

sudo gem install mysql

Migrate existing datbase from Heroku

sudo gem install taps
Copy your existing .heroku directory from your dev box to the deploy server.
Create your production db
rake db:migrate to get all the struct created

Pull that db down. For the prayerthread app:

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

http://adamblog.heroku.com/past/2009/2/11/taps_for_easy_database_transfers/

Mail

http://articles.slicehost.com/email

http://articles.slicehost.com/2008/7/28/email-preparing-the-slice http://articles.slicehost.com/2008/7/29/postfix-installation http://articles.slicehost.com/2008/7/31/postfix-basic-settings-in-main-cf

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

http://articles.slicehost.com/2008/9/2/mail-server-slice-setup

Deployment

Cobbled deploy recipe using:

http://dennisbloete.de/blog/rails-deployment-with-vlad-git-and-passenger http://snippets.aktagon.com/snippets/264-Vlad-deployment-recipe-for-Phusion-Passenger

Deployment Issues

There were 3 of them:

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.
Cloning from a remote git repo

This is an issue when cloning from unfuddle.com (or github.com). 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.
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:
```
Host sourcescape.unfuddle.com
  Port 22
  Hostname sourcescape.unfuddle.com
  IdentityFile ~/.ssh/unfuddle_rsa
  TCPKeepAlive yes
  IdentitiesOnly yes
```

Why I left Heroku

2010-01-15T18:46:00-05:00

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.

The Brave New World

2009-11-18T22:39:00-05:00

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.

Learning Erlang

2009-09-26T10:55:53-04:00

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.