The post Did we git pair? appeared first on Pivotal Labs.

I'm a big fan of David Dollar's foreman for starting up everything you need to run an app. These days were seeing a number of projects that rely on multiple ruby apps with seperate gemfiles to have a usuable development environment.

On one project recently we had three external services which we did not want to depend on for development. We wrote a tiny rails app for each, which had json endpoints, models for fake data, and used Rails Admin almost exclusively for the UI. This was great, but starting each one by hand was a chore, and foreman didn't want to respect the individual gemfiles.

The first thing that makes this dificult is bundler, which attempts to be helpful and make sure your gemset is still in effect when you shell out. How it does this is an ugly or beautiful hack, depending on your point of view.

    1.9.3p194 :001 > ENV['RUBYOPT']
    => nil
    1.9.3p194 :002 > require 'bundler'
    => true
    1.9.3p194 :003 > Bundler.require
    => [...]
    1.9.3p194 :004 > ENV['RUBYOPT']
    => "-I/Users/mkocher/.rvm/gems/ruby-1.9.3-p194@soloist/gems/bundler-1.2.0.rc.2/lib -rbundler/setup"

As you can see, Bundler has set RUBYOPT to load itself every time you shell out. We can prevent this from happening by using Bundler.with_clean_env.

    1.9.3p194 :005 > Bundler.with_clean_env { ENV['RUBYOPT'] }
    => nil

Better! But we're not out of the woods yet.

RVM has recently started including rubygems-bundler in the global gemset. I with they hadn't, but I also don't want to tell people to uninstall it every time they get a new workstation.

To prevent rubygems-bundler from trying to keep you in your gemset, you'll want to add a NOEXEC=skip to your environment.

With ruby, the cleanest way to do this is to include the env hash in your call to system:

  system({'NOEXEC'=>'skip'}, "rake -T")

Putting this all together, we made a script called run_app which looks like

    #!/usr/bin/env ruby
    require 'bundler'

    cmd = %Q{bash -lc "cd ../#{ARGV[0]} && source #{ENV['rvm_path']}/scripts/rvm && exec rackup config.ru -p #{ARGV[1]}"}

    Bundler.with_clean_env do
      system({'NOEXEC'=>'skip'}, cmd)
    end

We call this from our main project, and can pass it a directory and the port we want it to run on. foreman start now gives us an entire development environment nicely logging to one terminal.

The post Service Oriented Foreman appeared first on Pivotal Labs.

Helps

• Using resque-scheduler with resque-status

We're attempting to use both of these together, and encountered problems getting it to work.

Another project had found the answer. Resque scheduler only calls the correct method if you provide a custom_job_class in your yaml file:

This code from resque scheduler is the smoking gun:

if (job_klass = job_config['custom_job_class']) && (job_klass != 'Resque::Job')
    constantize(job_klass).scheduled(queue, klass_name, *params)
end

The post 05/30/2012: Resque Me appeared first on Pivotal Labs.

There's a growing movement for testing chef cookbooks, which is great to see. I haven't gotten to play with them all, but some that I've come across are the minitest chef handler, chefspec, and cucumber-chef.

The lowest hanging fruit however is linting, which is where foodcritic comes in. Foodcritic parses your cookbook, and warns you about many common errors.

Food critic will yell at you about all sorts of things - if you are accessing node attributes inconsistently, if you're passing valid ruby as a not_if string, if you're using /tmp instead of file_cache_path, and many more. For a full list, see the github pages

Automatically running foodcritic on your public cookbooks is easy with Travis CI. Just add a .travis.yml to your repo that looks like this:

script: "gem install foodcritic -v 1.1.0 && foodcritic -f any ."
rvm:
  - 1.9.3

And follow the travis getting started guide. You'll then get an email if you commit something that isn't quite up to par.

You can see a pivotal_workstation run on travis. We've still got a little ways to go to get to green, but everything it's telling us are things we'd like to do. (pull requests welcome!)

The post Chef cookbook linting with foodcritic appeared first on Pivotal Labs.

Ask for Help

"Is there a good JS/HTML code editor that will expand to fix the contents?"

A team is just getting started with putting in a code editor and is currently using ACE. It doesn't seem like there's a way to tell it to take up as much height as it needs. Many suggestions were thrown out, FCK and TinyMCE being two, but none was known to auto size itself. There is one that no one can remember the name of, but they had fond memories of from the past.

Interesting Things

• Super Market Street Sweep is coming up this weekend. Ride your bike around SF for a good cause.

Movember Update

• Webstash passed the $20k mark that Davis & Sean had been shooting for--congratulations everyone! (This does not include Rob's generous Mohawk donation). SF has raised $323.36 per stash, NY $163.40 and Boulder $210.50. There's still time to donate.

The post [SF] 11/30/2011: 30 Days has Movember appeared first on Pivotal Labs.

Ask for Help

Why does my md5 change when the timezone changes?

A pivot found that the tests of MD5 generation fail if the machine is in a different time zone. While one of the inputs to the hash is the time, he swears up and down that it's integer seconds since the epoch, and is the same on both boxes.

Interesting Things

• Tomorrow is Mo'hawk day at the Pivotal SF Office. It will be live streamed, with color commentary by our own Davis Frank. The live stream may be a PPV event, please have a major credit card available.

The post [Standup][SF] – 11/28/2011 – Post Turkey Edition appeared first on Pivotal Labs.

Last week Brian Cunnie posted a great writeup of what we've been working on for building OSX Lion workstations. Today, I'd like to introduce Apple Orchard - how we transform those chef recipes into ready to use OSX Lion images.

The story starts a few months ago, one morning after Standup while putting our dishes from breakfast away. Over the past few days we'd been discussing how our ops group would take chef recipes (generated for the most part by developers) and turn them into machine images that they could deploy on a moments notice. I approached Sean Beckett, our Director of Operations, and told him of my vision:

no manual steps

He looked at me like I was crazy, and he was obviously trying to figure out how to talk me down off the ledge. I told him how Jenkins could run a job after every checkin (a fact he was well aware of) and how all it had to do was...... He backed away slowly.

A few weeks later, Brian Cunnie had gotten past the Minimum Viable Image release marker in Tracker, and I told him of my vision:

no manual steps

He also looked at me like I was crazy, which he often does. The next week I had the afternoon to pair with him, and we got to work. We already had Jenkins building our recipes on a mac mini with Deep Freeze (software which allows you to reboot to a clean state), so we copied that Jenkins job at got to work. We got an iMac, and partitioned the disk into two.

Step 1

We boot the image to the persistent side, and image the dynamic side with a "mostly pristine" image that has X Code preinstalled, and has SSH turned on. We then set the machine to boot from that partition, and reboot.

Step 2

When it comes up, we SSH in, upload an SSH key, clone our public and private cookbooks (our private cookbook is used for our site licenses) and run soloist. If it succeeds, we move on to step 3.

Step 3

Reboot the machine to the persistent partition, and wait for it to come up. This isn't part of Step 2 because we want to leave the machine in the dirty state for troubleshooting if the chef run failed, and only trigger this if it succeeds.

Step 4

Put a script in place that will automatically rename the machine when it first boots, take an image of the partition using diskutils, scan it for restore, and move it over to our Deploy Studio server, and create a symlink so the 'lion HEAD' build points to the newly generated image.

That's it. We occasionally promote a 'lion HEAD' build to 'lion STABLE', so that we've always got an image on hand that we're confident in. But the overhead of cutting a new image is now simply changing a symlink.

There are a lot of moving parts, and sometimes it breaks. With time, it's become more reliable, but still has a lot of external dependencies. We've recently been trying out a strategy of pre-populating the chef and homebrew caches, which seem to be helping. Another caveat we've run into is that so far with Lion we've been unable to produce a universal image that will boot both MacBook Airs and iMacs, but we hope this may have changed with the latest 10.7.2 update.

Many thanks to Brian Cunnie - while I was the reason for this madness, he's done most of the heavy lifting with my occasional help.

It's all open source on github, at https://github.com/pivotalexperimental/apple_orchard. Values for our infrastructure are hard coded, but if you'd like to generalize it and use it, fork and make a pull request.

The post Apple Orchard – Turning Chef Recipes into OSX Images appeared first on Pivotal Labs.

Interesting

1. The the Riak Client gem uses nethttp by default. While it allows you to specify a timeout for a map reduce job, it doesn't set the nethttp timeout for the connection to riak. This means that all requests are effectively limited to 60 seconds. The project that discovered this is switching to curb.

2. The Mac App Store is actively hostile to business users. There is no way for us to buy software through the app store without setting up a separate account for every three computers, and then you can only reuse a credit card for three accounts. We won't be purchasing any software through the app store that isn't absolutely necessary until there's a way to purchase N licenses and use those on N machines. Pixelmator is the first app to lose our business.

The post Standup 6/28/2011 – At least it’s pretty inside the walled garden appeared first on Pivotal Labs.

I spent a large part of this week at Velocity and Devopsdays. I met a lot of great people and heard way more interesting things than I could absorb. Here's a collection of things (in no particular order) I found interesting.

• Get a #&%*&#$##%#% SSD Already

• JSFiddle is a gist-list site for sharing HTML/CSS/JS snippets. Looks to be a great way to share useful examples and problems. jQuery uses it for bug reports.

• Dyn's DynECT seemed to be the standard answer for how to distribute load to different datacenters for load balancing and geo-targetting. There is no standard answer to defeating the CAP theorem.

• There's a huge movement to rebuild Splunk in various open source projects. Logstash is an open source project which is piecing together various open source components to get something similar, but is doing index time extraction instead of search time extraction and hasn't gotten to graphing or analysis yet. Etsy is using Graphite extensively for metrics collection and say that developers prefer it to Splunk. Various other companies are building app-level only metrics collection/reporting solutions. The consensus in the devops community is that Splunk's pricing does work for the web. As a fan of Splunk, I hope they can figure this out as it's still better than anything I've seen.

• Etsy's work with metrics collection is interesting - they've written statsD for aggregating things before sending to graphite and Logster for tailing logs and making graphite events out of them.

• Joshua Timberman of Opscode has some great slides on how to write a Chef cookbook and I wish I'd gotten to see the talk at Devopsdays. I tend to think they error on the side of premature extraction for reusability, but I see their point of view. I'll definitely be using the remote_file resource and the file_cache_path.

• 2011 is shaping up to be the year of the Zookeeper alternatives. If you're not familiar, Zookeeper is a reimplementation of Google's Chubby - a highly available and reliable system designed to be the system of record for where services are currently available. Netflix has their own internal solution. Heroku has Doozer, and Noah is the new kid on the block with a simple rest interface and http callbacks(aka: webhooks). Opscode is also trying to answer this need by querying the Chef server at runtime for the identities of other hosts on the network. As environments and servers becoming ephemeral, telling every server about every server gets to be a tedious liability. It'll be interesting to see where this goes.

• Run Deck (aside from having a great logo) seems to be an interesting way to give users limitable, auditable, and repeatable access to server shells. It's a web interface that lets you execute commands on various configurable subsets of your infrastructure. It's got plugins so it can grab the current instances out of EC2, and a jenkins plugin so a Jenkins build can trigger a job in Run Deck. I'll definitely be checking it out when I get a chance.

• Pipe Viewer - (pv) Looks awesome. You can put it in a series of pipes in a shell, and it'll print out a nice status bar about the amount of data passing through the pipe. 'brew install pv'

• Opscode has a "fat" installer of chef coming out. It goes in /opt/opscode and includes all the dependencies in the package. This should answer a common complaint about having to install ruby to install ruby. (Yo, dawg, I heard you like Ruby)

• CSS Lint - Nicole Sullivan and Nicholas Zakas teamed up and introduced CSSLint at Velocity, which looks like it'll a good addition to a lot of test suites. Nicole also mentioned some cool pure CSS buttons that work on dark and light backgrounds. Lea Verou's pure css backgrounds were mentioned, which went around the office a while ago but are worth a link. It was also news to me that CSS selectors are run left to right by a browser - "ul.foo span.special *" will match all tags on the page, then narrow it down.

• Blue/Green Deployment is all the rage the days, and for good reason. Netflix and Amazon are both using it. You'll have to decide how it fits with your data storage layer, but it's worked well for me in the past and I'm glad to see it gaining popularity.

The post Velocity and Devopsdays Roundup appeared first on Pivotal Labs.

One of our goals for the first day a project starts at Pivotal is to deliver something the customer can see working. One of the ways we accomplish this is making sure getting up and running with all of our (more) reasonable defaults only takes a few minutes. We've been using guiderails for this internally for a while now, and soft launched it last week. I'm happy to give a full introduction today.

Currently Guiderails supports choosing:

• Mysql or Postgres
• RR or Mocha
• Webrat with Saucelabs support
• Cucumber with Capybara (no suacelabs support)
• SASS (with HAML)

And includes by default:

• A ci_build.sh script for running your project in CI.
• A local git repo
• An rvmrc
• Bundler, auto-tagger, JSON, Heroku, rspec-rails, Jasmine, and Headless gems (in the global or development groups)
• Jasmine initialized for JavaScript testing
• Respec installed
• Some testing related rake tasks

For more details, check it out on github at https://github.com/pivotal/guiderails.

Guiderails is a great way to get going quickly on a project. Many thanks to the Pivots that contributed.

The post Guiderails: our Rails 3 templates appeared first on Pivotal Labs.