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

Let us know how we can contact you.

Thank you!

We'll respond shortly.

LABS
Four fancy little apps for a more visual workflow

As it turns out, I’m a person. And like many persons, I too am a visual creature. Technology isn’t naturally built for people or to be visual. Here are four apps I’m using to help bring less clicks and more imagery into my daily flow.

Read more »

LABS
Xcode 5 First Impressions

It’s best best best.

Amidst all the excitement around the thumbprint scanner and plastic bling of the new iPhones, no one’s paying much attention to the newly minted Gold Standard release of Xcode 5.0. This release brings a whole suite of changes that we here at Xtreme Labs have been tinkering with all summer and we would like to share with you some of the more interesting features that jump out at us.

Read more »

DATA SCIENCE
Chorus In Action at Data Science London

Over the past few years, organizations like Data Science London have sprung up in major metropolitan cities all over the world. Greenplum feels privileged to be invited from time to time to present information about our products and learnings, and to participate in collaborative discussion with a group representative of the markets we serve. Recently, I had the opportunity to present a workshop on Greenplum Chorus at Data Science London, where I introduced the three primary concepts of Chorus.

LABS
LLVM, XCode's Super Secret Bug Detector

So if you’re anything like me you get a lump in your throat and a cold sweat every time you are about to hit the “SUBMIT” button in iTunes Connect and release your latest creation upon the world.

Usually about five minutes later the voice in the back of my head starts whining “What if we missed something?

Read more »

LABS
Using Pivotal Tracker to Help Manage API Development

Pivotal Tracker is a web-based task management system used by Xtreme Labs engineers as part of our agile development process. This blog gives an example of a common situation where Pivotal Tracker can help overcome project roadblocks.

The Problem

Ever been on a project where the client is in the process of building their server API and you need to coordinate these dependencies with your development?

Read more »

LABS
Level up your development workflow with GitHub & Pivotal Tracker

I've been working with my client, Unpakt, for a while now. One of their core values is making people's lives easier. They're specifically focused on making it easy for people moving to a new home or office to find a mover, compare prices and book their move online.

As a development team, we've taken that same core value of making things easier and applied it to our software development & deployment workflow. Over time, we've progressively improved our process. We're now at the point where we're happy with it, and I wanted to share what we've been up to.

The Typical Flow

Let's assume I'm using GitHub and Pivotal Tracker and I've just completed a story. What's next? Push my changes up to GitHub, click Finish on my story, wait for the build to go green, deploy to staging. Then, click Deliver on all the stories that have just been deployed. Other stories were most likely ready to be delivered as well, so I'll check that they were actually included in the deployment, and then Deliver them in Tracker.

The typical flow goes like this:

  1. Commit the changes to my story
  2. Push to GitHub
  3. Click Finish on story in tracker
  4. Wait for green build
  5. Deploy to staging
  6. Click Deliver in Tracker

That's not really that bad. I'm lazy though. If something can be automated, I want it to be automated. For instance, the deployment process should be automatically handled by my Continuous Integration server.

If we take this to the next step and automate our build and deployments as described in Robbie Clutton's Building Confidence post, we can reduce that flow to this:

  1. Commit the changes to my story
  2. Push to GitHub
  3. Click Finish on story in tracker
  4. Wait for green build
  5. Click Deliver in Tracker

Let's assume we've done that. That's a nice improvement, as deploys will happen automatically whenever there's a green build. That in itself is amazing.

But, what if we could reduce the steps in my everyday flow to this?

  1. Commit the changes to my story
  2. Push to GitHub

I want that!

POINT OF VIEW
Hadoop and Disparate Data Stores

Through our experiences in working with customers on Big Data platforms, we’ve come to notice that there are fundamentally two types of Hadoop users out there; the first type being “Hadoop-centric” users, and the second type being users who are leveraging Hadoop as an augmentation to existing systems. In this article, we focus on one of the most prominent challenges these “Hadoop-centric” users face.

LABS
Deploy strategies for HerokuSan

Deploy Strategies

If you look at the network graphs of heroku_san on github, you'll see a number of branches where the only change is the deletion of the following line from the deploy task:

  • stage.migrate

If more than a few people are willing to take the effort to fork a gem just so they can delete 1 line, something smells. The reason is that these forkers were using something other than Rails+ActiveRecord+SQL in their project. Some were using Sinatra, others were using Rails, but with CouchDB.

The raison d'être for the heroku_san gem is to make Heroku deploys dirt simple. So, if people are making whole forks to customize the deploy task, we should make it less painful.

LABS
From customer requirements to releasable gem

One of the many pleasures of working at Pivotal Labs is that we are encouraged to release some of our work as open source. Often during the course of our engagements, we write code that might have wide-spread use. Due to the nature of our contracts, we can not unilaterally release such code. Those rights belong to the client. And rightly so. So, it is an even greater pleasure when one of our clients believes in "giving back" to the community, as well.

One such example is this modest gem, attribute_access_controllable which allows you to set read-only access at the attribute level, on a per-instance basis. For example, let's say that you have a model Person with an attribute birthday, which, for security purposes, cannot be changed once this attribute is set (except, perhaps, by an administrator with extraordinary privileges). Any future attempts to change this attribute will result in a validation error.

e.g.

> alice = Person.new(:birthday => '12/12/12')
=> #<Person id: nil, attr1: nil, created_at: nil, updated_at: nil, read_only_attributes: nil, birthday: "0012-12-12">
> alice.attr_read_only(:birthday)
=> #<Set: {"birthday"}>
> alice.save!
=> true
> alice.birthday = "2012-12-12"
=> "2012-12-12"
> alice.save!
ActiveRecord::RecordInvalid: Validation failed: Birthday is invalid, Birthday is read_only
> alice.save!(:skip_read_only => true)
=> true

Setting this up is trivial, thanks to a Rails generator which does most of the heavy lifting for you.

rails generate attribute_access Person

After that, you need only know about one new method added to your class:

#attr_read_only(*attributes) # Marks attributes as read-only

There are a few others, but this one, plus the new functionality added to #save and #save! will get you quite far.

And if that's all that you were looking for when you stumbled across this article, then there's no need to read any further. Go install the gem and have fun (and may your tests be green when you expect them to be).

LABS
Dry DevOps with heroku_san

Quiz time!

  1. How many times (each day) have you typed this at your console? git push heroku master and then forgotten to run heroku run rake db:migrate --app yellow-snow-3141 or heroku ps:restart
  2. Does your script support a multi-stage environments?
  3. Do you remember how to get to the application's console process?
  4. Is your application's configuration consistent across all stages?
  5. Are you deploy scripts tested?