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

Let us know how we can contact you.

Thank you!

We'll respond shortly.

Onsi Fakhouri

Posts By

LABS
In Defense of CodeBabes

Nope. Got nothing.

Go read these two instead.



Read more »

LABS
Stand back! I'm going to try science.

For your entertainment. A vignette from my pre-pivotal days.

I wake up, bleary-eyed, and roll out of bed. Squinting I look at the time: 11:27. Perfect. I slide into a pair of jeans and make a pot of coffee. I drink it black; it pairs well with a nutritious breakfast of two heavily-toasted frosted strawberry pop tarts.

Read more »

LABS
Learning Well

One of the benefits of pairing that we emphasize at Pivotal is the learning environment that it provides. We find that one of the best ways to teach a new technology or codebase is to pair up novices with experts. It’s important to understand however that effective learning doesn’t happen automatically – even when pairing; it takes intentional thoughtful effort from both the teacher and the student (or master/apprentice if you prefer) to transform a mediocre learning experience into an effective one.

Read more »

LABS
Crunch Time

It comes up on almost every consulting project I’ve worked on as a pivot, but this particular conversation was memorable. I was surreptitiously ushered into a room by the product manager (PM). Once inside, he shut the door:

So, I know you guys don’t do crunch time… but we really need to ship by Monday.

Read more »

LABS
Listening Well

Julie Ann Horvath’s public departure from GitHub has, once again, brought the question of gender equality in the tech world – and the San Francisco tech world, in particular – to the forefront of the blogosphere’s fickle zeitgeist.

Sadly, important and difficult conversations rarely take hold amidst the ebb and flow of the trending and the interesting and – all-too-often – the blogosphere moves on, having merely scratched the surface of a topic with deep systemic roots.

Read more »

PIVOTAL CLOUD FOUNDRY
Diego Phase 1: Staging in a multiplatform world

The first phase of Diego’s development has focused on offloading the staging workflow – the task of converting uploaded app bits to compiled droplets ready for running in Cloud Foundry – from the existing DEAs to Diego. From the outset one of Diego’s mandates has been to make it relatively easy to support multiple platforms (e.g.

Read more »

PIVOTAL CLOUD FOUNDRY
HM9000: Ready for Launch

Cloud Foundry (CF) is a platform-as-a-service that, once deployed, makes it easy for developers to deploy, run and scale web applications. Powering this elegant PAAS is a complex distributed system comprised of several interoperating components: the Cloud Controller (CC) accepts user input and directs Droplet Execution Agents (DEAs) to stage and run web applications.

Read more »

LABS
Announcing Ginkgo and Gomega: BDD-Style Testing for Golang

I’m happy to announce that Ginkgo, a BDD-style testing framework for Go, and its preferred matcher library Gomega are ready for public release. There’s a comprehensive feature list, on the GitHub READMEs and both projects have extensive documentation written up (Ginkgo and Gomega).

Read more »

LABS
Cocktail: DRY up your backbone code with mixins

I've continued to enjoy using Backbone.js to build single page apps. As I've seen more and more real world backbone I've started to develop opinions to augment the blissfully unopinionated little framework that could.

One of these opinions has turned into a mini-library: Cocktail adds functionality to Backbone's extend to facilitate breaking up reusable code into mixins. It's pretty straightforward:

  1. Define your mixin. Mixins are just plain vanilla JavaScript objects with methods and properties hanging off of them. Here's a slightly contrived mixin that makes a view selectable:

    window.MyMixins = {};
    MyMixins.SelectMixin = {
      initialize: function() {
        this.model.on('change:selected', this.refreshSelect, this);
      },
    
    
      events: {
        click: 'toggleSelect'
      },
    
    
      render: function() {
        this.refreshSelect();
      },
    
    
      refreshSelect: function() {
        this.$el.toggleClass('selected', this.model.get('selected'));
      },
    
    
      toggleSelect: function() {
        this.model.set('selected', !this.model.get('selected'));
      }
    }
    
  2. Mix your mixin into your views. It's a one-liner:

    var MyView = Backbone.View.extend({
      mixins: [MyMixins.SelectMixin, MyMixins.SomeOtherMixin],
    
    
      events: {
        'click .myChild': 'myCustomHandler'
      }
    
    
      initialize: function() { ... },
      render: function() { ... },
      etc...
    });
    
  3. That's it! Instances of MyView will automatically inherit the behaviors and methods defined in SelectMixin.

Cocktail brings two simple things to the table:

  • it adds the special mixins:[...] notation to Backbone's extend.
  • it automatically detects and handles method collisions. In the example above Cocktail will wrap MyView's and SelectMixin's implementations of initialize into one method and assign that method to the new, composite, class. The return value of this composite method is the last non-undefined value returned by the methods it wraps. All colliding methods are handled this way, as is the events hash (the events hashes all get merged together).

There are more details and examples at the repo. In particular, there's an example for testing mixins with Jasmine -- it goes over a pattern for writing shared behaviors in Jasmine.

LABS
Coccyx: plug up those backbone leaks

A number of projects at Pivotal have been using Backbone.js to build single page web apps. I've enjoyed using Backbone: it's lightweight, unopinionated, helps encourage good separation of concerns between models and views, and reduces a fair bit of JavaScript boilerplate by bringing just enough framework to the table.

Unfortunately, it's very easy to write Backbone code that leaks - especially in the view layer. A common backbone pattern is to set up some event bindings for a view:

var MyView = Backbone.View.extend({
    initialize: function() {
        this.model.on('change', this.update, this);
        this.someOtherModel.on('change', this.update, this);
        this.boundResizeHandler = _.bind(this.resizeHandler, this);
        $(window).on('resize', this.boundResizeHandler);
    },
    ...etc..
});

If your app needs to switch between several such views it is not enough to simply remove the view's DOM and null out any references to the view. You must also unbind these event bindings in order for the view to be garbage collected. Moreover, if this view contains any subviews, you must also tear down all event bindings for all its subviews. If you do not succesfully clear out all bindings the view (and/or its subviews) will leak.

What's worse: while there are some great tools out there to identify leaking objects, Backbone's default constructor lists all objects as type child. This makes finding the leaky Backbone objects that are instances of MyView nearly impossible in Chrome's heap propfiler.

Coccyx attempts to adress these problems by doing two things:

  1. Coccyx adds named constructors to Backbone. You no longer need to wonder which child is yours. By adding constructorName when you extend a Backbone class you'll be able to easily tell which object is which in the console and the heap profiler.

  2. Coccyx implements teardown-able view hierarchies. You can easily build view hierarchies in which parents are aware of their children and can tear the entire structure down by calling tearDown() on a root node. tearDown() automatically unbinds any Backbone event bindings, cleans up DOM events and gives your view a chance to perform any custom teardown via a callback.

There are many more details at https://github.com/onsi/coccyx. Bug reports and pull requests are encouraged!