Project Time at Carbon Five

It has been two weeks so it is time for another Hack Night at Carbon Five. Before our space fills up with hungry hackers, we like to set aside 4 hours of project time for employees to work on their own projects and pair with others to cross pollinate teams.
Continue reading

Posted in Everything Else | Tagged | Leave a comment

Designing mobile APIs – basic behaviors

As Rails developers we design APIs on a regular basis: routes for browsers to interact with a web app, JSON apis and routes for client side javascript to build dynamic pages, payloads queued for background processing on a server, and so on. As we move into mobile development we can benefit from many of the lessons we have learned about good API design, but also face some new problems and changing demands.
Continue reading

Posted in Mobile | Tagged , , , | Leave a comment

Think Globally, Stage Locally

Or: how to create and deploy to a staging environment running locally!

Staging: an environment that duplicates production as closely as possible to find any lingering bugs before you update production. Most of the Rails community develops on OSX but deploys to Linux; this can be fragile since it is common to forget Linux-specific environment changes necessary for your app. At Carbon Five, most of our customers can afford to maintain a dedicated staging environment but for smaller projects, I wanted to have my own Linux staging environment without the cost of a real slice or EC2 instance.

In this post, I will show you how to create a Linux VM with Vagrant and use capistrano to deploy to your vagrant VM. My coworker Jared recently posted an nice intro to Vagrant, a great project by Mitchell Hashimoto to simplify and automate the use of virtual machines during development. You should read his post first as I’m not going to cover Chef, which I highly recommend for automating the provisioning of your VM. Using Chef means that your staging and production boxes can be virtually identical by using the exact same recipes to build them.

Let’s assume you have a Rails 3 app for which you want to create a staging VM. We’ll install Vagrant and configure it in the project like so:

  cd myapp
  # NOTE: Make sure you've installed VirtualBox first!
  gem install vagrant
  # Downloads a blank Ubuntu 11.04 64-bit image
  # Or find your own box on http://vagrantbox.es
  vagrant box add ubuntu-1104-server-amd64 http://dl.dropbox.com/u/7490647/talifun-ubuntu-11.04-server-amd64.box
  # Adds a Vagrantfile to your Rails app which talks to the new image
  vagrant init ubuntu-1104-server-amd64
  # Starts the new VM
  vagrant up
  # Adds SSH details to your SSH config so Capistrano can deploy directly to your VM
  vagrant ssh-config >> ~/.ssh/config
  # Logs into your new VM
  vagrant ssh
  # Perform a lot of Chef recipe work
  # ...Left as an exercise to the reader...

This whole process, minus the box download, should take a minute or two. Remember that you will need to do a bunch of Chef work to install the stack your application needs (e.g. Unicorn, JRuby, etc). Once that that is done, let’s work on the Capistrano configuration. In this case, I’m using the capistrano-ext gem to add multiple environment support so we can deploy to production or our new staging VM:

# config/deploy.rb
set :stages, %w(staging production)
set :default_stage, "staging"
require 'capistrano/ext/multistage'
require "bundler/capistrano"

set :user, 'vagrant'
set :application, "myapp"
set :deploy_to, "/home/#{user}/#{application}"
set :repository,  "git@github.com:acmeco/#{application}"

set :scm, :git
set :branch, "master"
set :deploy_via, :remote_cache
ssh_options[:forward_agent] = true

And in config/deploy/staging.rb:

# 'vagrant' = the hostname of the new VM
role :web, "vagrant"
role :app, "vagrant"
role :db,  "vagrant", :primary => true
set :rails_env, 'staging'

The secret sauce was in the vagrant ssh-config command, which configured ssh so it knows how to log into your new Vagrant VM. Now all we need to do is a simple cap staging deploy and Capistrano will use ssh to connect to the VM and have the VM pull your latest changes from your github repo.

Once deployed, you can tell Vagrant to forward your application’s port in the VM to a localhost port. In my case, I have Unicorn running on port 5000 in the VM, forwarded to port 8080 on localhost in OSX. With this configuration in my Vagrantfile, I can browse to http://localhost:8080 to hit my Rails app running in the VM.

  config.vm.forward_port "unicorn", 5000, 8080

Final note: if you have trouble contacting github, make sure you are running ssh-agent to handle key requests from the VM. This will allow the vagrant user in the VM to act as you when contacting github: run ssh-agent && ssh-add on your local machine (NOT in the VM).

Most of this post is typical Vagrant and capistrano configuration. With just a few simple tricks, we can tie the two together for great victory and hopefully more stability for your site. Good luck!

Posted in Ops | 2 Comments

Getting “Test”-y in iOS Apps: Test-Driven Development and Automated Deployment

View more presentations from rudyjahchan

Recently, Jonah and I have been exploring test-driven development and automated deployment on the iOS platform. As we were both attending iOSDevCamp 2011, we decided to give a lightning talk summarizing our discoveries and to generate excitement within others in the community to start their project on the right foot by testing right from the start. While it wasn’t recorded, here is some of the ground we covered in the brief time we had.

Continue reading

Posted in Mobile, Process | 7 Comments

Pragmatic JavaScript Testing with Jasmine

As more and more parts of our applications are written in JavaScript, its important to have them covered with automated tests. Fortunately, there are numerous JavaScript testing tools available. As a BDD fan, the RSpec inspired Jasmine is currently my go-to.

Continue reading

Posted in Process, Web | 21 Comments

Virtual Environments with Vagrant

After a recent run-in with an irate local sysadmin, I was convinced to try out developing on a virtual machine. His argument was that developing on one platform, such as OS X, when you are deploying to another, such as Linux, was just asking for trouble. Specifically he was referring to using Ruby gems with native extensions requiring C libraries that may not be installed on the deployment server or they are installed but the version is different than your local environment. While I haven’t ran into too many of those issues, I could see his point.

Similar problems can happen even when using the same platform. I recently had issues on a team related to some developers using brew vs MacPorts and their default install locations. If everyone was using the same package manager these problems could have been avoided. It was also taking basically a whole day to get a new developer’s environment up and running. Some automated provisioning tools could of really sped this process up.

Fortunately the Ruby community has an excellent gem that allows us to both create and provision virtual development environments: Vagrant. I decided to give it a try. After a few months of using it, I’m hooked.

Continue reading

Posted in Process, Web | 1 Comment

Managing iOS Configurations per Environment in Xcode 4

At Carbon Five we usually have 3 – 4 environments our iOS applications will run against: development, acceptance, staging and production. Often, the property values that are unique across environments are URLs to APIs that we are integrating with. There have been several approaches for managing different configurations per environment. Some have included conditional compilation or build-time file substitution. While all are valid approaches, I opted to use Xcode’s build configurationsĀ to manage configurations per environment. Here is how I did it:

Step 1: Modify Your Default PList File

Your default plist file is usually named ${PRODUCT_NAME}-Info.plist and is located beneath the “Supporting Files” group of your Xcode project. Add a new row/item of type String to the plist file and name it Configuration. Set the value to be ${CONFIGURATION}, the Xcode provided environment variable for the current build configuration.

Continue reading

Posted in Mobile | Tagged , , , | 6 Comments

Debug logging with Xcode 4 breakpoints

NSLog calls do not belong in release builds. Logging is slow and the performance impact of log statements on a device can be considerable. Logging is also noisy, it can obscure useful debugging information and may leak information you would rather not expose in a release build. Looking at my device’s system log I see output full of content urls, api keys, massive log messages, and data only valuable while debugging an app.

: Succeeded! Received 18977 bytes of data for url http://www…
: fetched comments: ( …<74k of JSON>
: *** …GetData: http://…/query?id=1001&sc=17&fields=…&apiKey=
: applicationDidBecomeActive completed
: JSON parsing finished in 24 ms. String alloc took 2 ms. Comment stripping took 1 ms.
: CallbackHandler registered delegate,, instance=0×263650

There are a number of examples of using precompiler macros to eliminate log output on non-debug builds but I recently started using Xcode 4′s breakpoints and find them to be my favorite mechanism. Breakpoints can be configured to log arbitrary output and automatically continue to avoid stopping program execution. They can be dragged from one line to another, added, disabled, and removed while your app is running. You can even check them in as part of your project to share them with other developers.
Continue reading

Posted in Mobile | Tagged , , , , | 10 Comments

Instagram Realtime Demo with Node.js, Redis and Web Sockets

To promote and showcase the API they released in February, the folks at Instagram built and released the source for the demo app that runs http://demo.instagram.com. The app subscribes to the Instagram realtime API to be notified of new photos posted in specific geographic locations. It updates the display of the photos as they come in.

It’s a fairly simple app that’s a fun playground for a bunch of new technologies including Node.js, Redis and HTML5 Web Sockets. You can play with Node and Express, the Sinatra-like web frameworks for Node. You can play with the basic Redis commands using both the data storage and publish/subscribe models. And with Node and the socket.io library, you have a great platform for playing with pushing data to the browser with Web Sockets.

Unfortunately, when I sat down to install and run the app the other day, I ran in to a number of issues due to new versions of many of the dependent libraries being incompatible with the implementation available on GitHub.

So I forked the project and fixed it so you can play with it too. The steps below will help you get the demo running on your local development machine. Once you’re there, the fun really starts. How would you add the ability to follow a user-entered tag or send me an SMS when someone posts a photo near my house?

Continue reading

Posted in Web | 7 Comments

Organizing User Stories and Code by Activity

Recently I was introduced to a tool developed by my co-workers called Story Mapper. Story Mapper was inspired by an agile design technique outlined in this post; it involves a way of organizing user stories around activities. During the story writing process each story is given an activity such as “registering” or “administrating” so instead of a flat backlog you have groups of stories allowing you to more effectively explain and plan your system.

Here at Carbon Five we use Pivotal Tracker for story writing and its story labels to specify each story’s activity. Story Mapper then uses the Pivotal Tracker API to pull in stories and organize them by that activity/label. This provides a great way to see at a high level your progress implementing each of the system’s activities. Could this activity focused view be applied to the code-base itself?

Continue reading

Posted in Process, Web | 3 Comments