Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

Mike Barinek

Posts By

American Thrombosis and Hemostasis Network (ATHN) is looking for a Web Application Developer

At Pivotal Labs, one of the services we provide our clients is helping them interview and hire. Pivotal Labs and our clients place a strong emphasis on Agile development and its many aspects: Pair Programming, Test-Driven Development, rapid iterations, and frequent refactoring.

Rails and Mobile Developer

The American Thrombosis and Hemostasis Network (ATHN) is the coordinating body for a not for profit network of a 100+ blood disorder treatment centers. ATHN provides centralized technology solutions to support the research into and management of rare blood disorders. ATHN is building web and mobile management and research applications designed to improve the health and treatment of these rare blood disorders.

We are looking for a developer to create cutting edge mobile and web tools to collect, organize and analyze Big Data (ATHN has treatment data for hemophilia going back more than 30 years). Responsibilities include interpreting requirements to identify, evaluate and implement technical solutions. ATHN’s technical team is close-knit unit, lead by ATHN’s Director of Operations. All team members work remotely from their homes. We rely heavily on Skype, Pivotal Tracker and other collaboration tools to stay in touch. If working with a dedicated group of technology professionals and helping improve the lives of tens of thousands of patients appeals to you, we urge to you apply.

Job Requirements

  • Self motivation and the capability to operate independently
  • Excellent oral and written communication skills
  • 1+ years experience building with the Ruby language and the Rails framework, be proficient with the entire Ruby on Rails stack
  • 1+ years experience building native iPhone applications, be proficient with Objective-C and Cocoa Touch
  • Published 1 or more apps to the App Store
  • 2+ years of hands-on web development experience demonstrating:
  • Proficiency with HTML/XHTML, JavaScript, CSS and JQuery
  • Sound object oriented design skills and knowledge of application architecture patterns
  • Competency in Cocoa design patterns and API design
  • Passionate about end-to-end and user experience design
  • Proficiency with relational databases, included design and development
  • Ability and desire to thrive in an Extreme Programming environment, including pair programming Desired Skills In addition to the required skills, the ideal candidate will have the following skills:
  • Working knowledge and comfort developing UI and UX using Photoshop
  • Working knowledge of test-driven development and related frameworks(preferably RSpec)
  • Working knowledge of Backbone.js
  • Experience developing mobile web applications using JavaScript, HTML 5 and CSS, JQuery Mobile
  • Experience with mobile development frameworks and environment ex. PhoneGap and Monotouch
  • Experience building native Android Applications
  • Qualifications B.A or B.S or relevant experience

Inquires can be submitted to

Portico is looking for a Web Application Developer

At Pivotal Labs, one of the services we provide our clients is helping them interview and hire. Pivotal Labs and our clients place a strong emphasis on Agile development and its many aspects: Pair Programming, Test-Driven Development, rapid iterations, and frequent refactoring.


Portico by Exclusive Resorts® is a new private club that provides access to a growing portfolio of incredible luxury vacation homes in the world’s best destinations, combined with personalized pre-trip planning and expert concierge service. Portico leverages the unmatched track record and expertise of Exclusive Resorts®, the company that has set a new standard for luxury travel and has provided more than 150,000 exceptional vacations for tens of thousands of its members and their family and friends.

We are looking for a developer to help create an exceptional, custom-built luxury travel solution for our rapidly growing member base and portfolio of homes. Responsibilities include interpreting requirements to identify and evaluate solution alternatives, developing and deploying high-quality applications. You are expected to consistently produce reliable, scalable, high-performance technology solutions using modern design and development patterns. You will be an integral component of strong, tightly-knit, collaborative development team working with a product owner and other key internal business stakeholders.


  • Proven experience in development of flexible and scalable web-based applications
  • Passion for technology, specifically software development
  • 1+ years of experience with Ruby language and the Rails framework, be proficient with the entire Ruby on Rails stack
  • 3+ years of hands-on web development, demonstrating:
  • Proficiency with HTML/XHTML, CSS, JavaScript and JQuery
  • Sound object oriented design skills and knowledge of application architecture patterns
  • Proficiency with relational databases, including design and development
  • Working knowledge in development of MVC-based web solutions
  • Ability and desire to thrive in an Extreme Programming environment, including pair programming
  • Competency managing source control and automated build processes
  • Excellent analytical and problem solving skills
  • Strong communication and interpersonal skills


  • Experience with agile software development methodologies such as SCRUM and/or XP
  • Working knowledge with test-driven development and related frameworks (preferably with RSpec and/or Test::Unit)
  • Working knowledge of associated platforms and technologies, including Linux and Apache

Testing Ruby Services without Mocks

There seems to be a tendency to stub or mock classes when writing integration tests for basic http services. I'm actually not a big fan of this approach. By definition, the integration test should truly integrate with another subsystem. In the case of a http service, the tests should probably integrate over http, agreed?

Here's one approach for testing services without stub or mocks...

Imagine a reservation booking system that integrates with a 3rd party API. By default, you might create a Rails model that extends ActiveModel, ActiveRecord or even ActiveResource. Although you stop, after reading this blog post, and create an unbuilt Gem that reaches out to the 3rd party service. Your service might look something like this...

require "rack"
require "nokogiri"

class ReservationService
  def create_reservation(reservation)
    url = URI.parse('http://localhost:9393/')
    http =, url.port)
    response, body =, reservation.to_xml, {'Content-type' => 'text/xml; charset=utf-8'})
    reservation = Reservation.from_xml(body)

More important, your immutable model might look something like this. (Note: I'm not inheriting from a Active* base class, although I'll save the inheritance discussion for another blog post)

class Reservation
  attr_reader :name, :date, :duration, :booked

  def initialize(name, date, duration, booked = false)
    @name = name
    @date = date
    @duration = duration
    @booked = booked

  def to_xml
    doc = <<XML
<?xml version="1.0" encoding="UTF-8"?>

  def self.from_xml(xml)
    doc = Nokogiri::HTML(xml)
    doc.xpath("//reservation").each do |reservation|
      reservation.children.each do |child|
          when "name"
            @name = child.text
          when "date"
            @date = Date.parse(child.text)
          when "duration"
            @duration = child.text.to_i
          when "booked"
            @booked = eval(child.text)
    end, @date, @duration, @booked)

Then you start writing tests. You stub the service, then you stub Typhoeus. You might pull Typhoeus and use Artifice or rack-test. Sure the approach works, although are you really testing the full integration (they do stub at the lowest level)?

You could argue a more complete integration test might include the http layer. One approach might be to fire up a simple rack handler that matches the API specification.

Here's an example...

require "test/unit"
require "date"

require File.expand_path(File.join(File.dirname(__FILE__), "reservation_service"))

class TestServer
  def initialize(response_code, response_body, response_headers = {})
    @response_code = response_code
    @response_body = response_body
    @response_headers = response_headers

  def start
    @thread = do, :Port => "9393", :Host => "localhost")
    sleep 1
    puts "started server."

  def stop
    puts "stopped server."

  def call(env)
    [@response_code, @response_headers, [@response_body]]

class TestService < Test::Unit::TestCase
  def test_create_reservation
    expected_reservation ="John Brown",, 3, true)

    server =, expected_reservation.to_xml, {})

    service =
    actual_reservation = service.create_reservation("John Brown",, 3))

    assert_equal(expected_reservation.duration, actual_reservation.duration)
    assert_equal(expected_reservation.booked, actual_reservation.booked)


(Typhoeus actually uses a similar approach via TyphoeusLocalhostServer.rb within their own test suite)

You might ask why not just integrate with the 3rd party's API sandbox environment. Because doing so could impact test performance as well as your ability to run tests - you become too dependent on their service's availability.

A similar approach might be to VCR, although VCR might not work without an actual sandbox environment.

Rails Contained: A Container for Web Application Development and Deployment

You might call this post Part 2 in a component based architecture series. The first post describes a solution for better organizing loosely-coupled, highly-cohesive components within a singe Rails application.

This post describes a component based solution that aims to support vastly different user experiences and client side strategies across multiple web applications that share a common domain while allowing developers to work independently within individual web applications or components.

Here's the scenario...

You're tasked with building a fairly large web application, several user roles each packed with handfuls of high-level activities. The larger application could clearly be broken apart into smaller web applications. It's a clear win to break things down. The smaller applications would have unique responsibilities and developers could work within the context of one application without worrying about introducing breaking changes across applications. However, the smaller applications, although independent, share a common domain or database.

You start thinking about how you'd expose subsets of the domain as RESTful services and maybe introduce a single sign-on approach, although you're concerned about managing, versioning, and deploying multiple web applications and services, not to mention how this might impact the early development rhythm. There's no clear path to success, so you write the classic uber app.

The tide could be changing in your direction. Here's a solution that's shown early success for developing and deploying large Rails applications: move loosely-coupled, highly-cohesive web applications and components to a components directory within a container Rails project.

Until recently such an approach might be difficult to imagine. Although, with the addition of mountable engines in the latest versions of Rails, the approach is now possible. Here's an example that describes the project structure...


The container application simply mounts dependent web applications as Engines, exposing each with their own context or url. Engines in turn reference in any Engines or Gems they depend on.

However, there is one twist, we keep everything in a single Git repository.

Engines are organized as prescribed within their corresponding directories, although they're not built nor do they have their own Git repository. They're referenced directly from the containers Gemfile.

As database migrations trigger sweeping changes, the refactorings become simpler and you don't need to worry about deploying updates to multiple applications/services as all your code is in one place, versioned together.

As important, each Engine or Gem has it's own Gemfile, test_helper, test suite, and continuous integration environment. As mentioned in the first post, the unique Gemfile and test helper allows you to remove unnecessary dependencies while the individual test suite and continuous integration environment helps to avoid circular dependencies.

Unbuilt Rails Dependencies: How to design for loosely-coupled, highly-cohesive components within a Rails application

I'm sure a few of you have encountered this scenario...

You're a year in and your Rails application is growing in size as well as complexity. It's becoming increasingly difficult to navigate through a sea of models, not to mention that your test suite is grinding to a screeching halt.

You have a handful of 3rd-party services you integrate with so you start thinking about extracting Gems. Although you're nervous, as you'll now need to manage and version multiple Gems. You're looking at a mountain of work with little feature development.

Here's a solution that has worked on several projects that might help to avoid this scenario: move loosely-coupled, highly-cohesive components to unbuilt gems within your lib directory while maintaining a single Git repository.

Sounds strange? Here are a few important facts that might help clarify the solution...

There's only one Git repository and dependent gems are never "built", their gemspec is simply referenced via your Rails Gemfile. This defers the need for a Gem versioning strategy as you Rails application moves forward with multiple dependent components all under the same umbrella.

From within your Gemfile...

gem 'component_1', path: "lib/component_1"

All your source is in one place. This allows you to continue to develop within a single environment with cross-component refactorings, which is now supported by tools like RubyMine.

Components have their own Gemfile, test_helper, test suite, and continuous integration environment. The unique Gemfile and test helper allows you to remove any unnecessary dependencies (Rails for example). The test suite and continuous integration environment helps to ensure downward dependencies and avoid circular dependencies.

As a result, you tend to end up with loosely-coupled, highly-cohesive components and avoid accidental design. In addition, test suites tend to run faster as they're loading far fewer Gems and you've honored the timeless way of building large applications.

Here's an example that describes the project structure...


Probably the most compelling argument is prematurely trying to identify and extract components. 3rd-party service integrations seem like a reasonable place to start, however, more recently we've been teasing out a variety of components very early within the development lifecycle with much success.

Jasmine Workshop 9/8 & 9/9

Cory Flanigan and Justin Searls are hosting a two day Jasmine workshop very soon in Denver on 9/8 & 9/9 at Uncubed. Details here:

The event is non-profit. There's a fee of $120, but it is intended to only cover costs. If proceeds manage to exceed our costs, they'll be donated to charity.

Their objectives are to introduce people to Jasmine, pair on a basic kata, pair on spec'ing some behavior that would involve DOM interactions/jQuery, illustrate patterns for using spies on dependencies and callbacks (like AJAX), and also to spend time working through methods for rigging up Jasmine specs in CI.

In addition, they're inviting everyone who attends to bring some of their own existing JavaScript (especially if it's untested). As time permits on the second day they'd like to mob program on these real-world examples by characterizing legacy JavaScript code with Jasmine and then refactoring with our tests as a safety net.

Orbotix is looking for a Senior Rails developer to join their team in Boulder

At Pivotal Labs, one of the services we provide our clients is helping them interview and hire. Pivotal Labs and our clients place a strong emphasis on Agile development and its many aspects: Pair Programming, Test-Driven Development, rapid iterations, and frequent refactoring.


We're looking for a brilliant Rails developer to join our star team in Boulder, CO and take the lead on all web development projects. If you want to share your knowledge while learning from others, work smart, and contribute to some awesome projects, we think you'll have a blast with us. As a bonus you'll get to play with robots, games and mobile devices all day long.

Job Description:

  • 2+ year experience with the Ruby language and the Rails framework, must have a proficiency with the entire Ruby on Rails stack.
  • 4+ years of standards compliant HTML/XHTML, CSS, JavaScript, and JQuery.
  • 4+ years of Java, PHP or equivalent platform experience (including related DB experience such as MySQL, PostgreSQL, etc).
  • Awesome attitude and fun personality.
  • Ability to communicate with both technical and non-technical team members

About Orbotix

Although you are encouraged to send a traditional resume, a resume will not alone won't make you stand out. So along with your resume please send a brief explanation about who you are and why you would be a good fit for Orbotix. Include pictures, videos, or screenshots of your previous projects, both professional and personal. We’re just geeks like you so don’t hold back. Email us… jobs [at] orbotix (dot) com.

Orbotix is a venture backed startup with the vision that you shouldn’t be limited to emailing, getting directions, and playing a game of scrabble on your mobile device. You should be able to just as easily download an app to control all of the physical devices around you. No more remotes. No more clunky interfaces. No more keys. Everything is done with the powerful mobile device that you already carry with you. We’re looking for someone great to join our small but hardcore engineering team to help design and implement our products, starting with Sphero, a powerful robotic entertainment device.

Noop Handler – Catching 80K requests per second without breaking a sweat

Sure it's a noop test and running on a iMac i7, but 80K requests per second is pretty impressive for 40 lines of code.

package manual;

import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import org.eclipse.jetty.server.Request;
import org.eclipse.jetty.server.Server;
import org.eclipse.jetty.server.handler.AbstractHandler;
import org.eclipse.jetty.server.nio.SelectChannelConnector;
import org.eclipse.jetty.util.thread.QueuedThreadPool;

public class NoopHandler {
    public static void main(String[] args) throws Exception {
        QueuedThreadPool pool = new QueuedThreadPool();

        Server server = new Server();
        server.setHandler(new AbstractHandler() {
            public void handle(String target, Request baseRequest, HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException {

        SelectChannelConnector connector = new SelectChannelConnector();

Here's the apache benchmark information.

juniper:~ pivotal$ ab -n10000 -c20 -k http://localhost:8080/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd,
Licensed to The Apache Software Foundation,

Benchmarking localhost (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests

Server Software:        Jetty(7.2.2.v20101205)
Server Hostname:        localhost
Server Port:            8080

Document Path:          /
Document Length:        4 bytes

Concurrency Level:      20
Time taken for tests:   0.127 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Keep-Alive requests:    10000
Total transferred:      980392 bytes
HTML transferred:       40016 bytes
Requests per second:    78840.73 [#/sec] (mean)
Time per request:       0.254 [ms] (mean)
Time per request:       0.013 [ms] (mean, across all concurrent requests)
Transfer rate:          7548.32 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:     0    0   0.1      0       3
Waiting:        0    0   0.1      0       3
Total:          0    0   0.1      0       3

Percentage of the requests served within a certain time (ms)
  50%      0
  66%      0
  75%      0
  80%      0
  90%      0
  95%      0
  98%      0
  99%      1
 100%      3 (longest request)

I've also been playing around with Mizuno and jruby-rack quite a bit recently. We're hoping to find a high-performing solution for jruby.

Avro's Reflect Datum Writer

As some of you may know, I've been writing a bit of Java in Boulder recently. Overall, it's pretty exciting and a nice change from Ruby.

That being said, I've somewhat isolated our Java development to server-side components. I still consider Ruby/Rails to be the best solution for web application development, although recently had a need for Java.

Anyway, I've been playing around with Avro and I thought I'd share a small example that marshals a domain object to bytes. The bytes are later passed around several queues within application.

package com.barinek.devourer.avro;

import org.apache.avro.Schema;
import org.apache.avro.file.DataFileWriter;
import org.apache.avro.reflect.ReflectData;
import org.apache.avro.reflect.ReflectDatumWriter;


public class ReflectMarshaller {

    private final Schema schema = ReflectData.get().getSchema(Activity.class);

    public byte[] marshal(Activity activity) throws IOException {
        ByteArrayOutputStream outputStream = new ByteArrayOutputStream();
        ReflectDatumWriter< Activity > reflectDatumWriter = new ReflectDatumWriter< Activity >(schema);
        DataFileWriter< Activity > writer = new DataFileWriter< Activity >(reflectDatumWriter).create(schema, outputStream);
        return outputStream.toByteArray();

The interesting bit is that I don't have a .proto file or .json representation of the type. The Activity class is a Plain Old Java Object.

The above snippet is a candidate to replace some proto files, assuming the MicroBenchmark test suite passes.

Look for more Java posts in the near future.

Pairing in Boulder

Recently, we have been experimenting with a few new pairing configurations in Boulder, I thought I would share an early photo.


These are 27-inch iMac's paired with 27-inch Apple Cinema Displays.

We've experimented with both side-by-side configurations as well as a variety of angles between 15-90 degrees.

I have to admit, I really like the angled configuration. +1 for not always needing to stretch to see opposite corners of the screen.