November 12, 2012

Setting Backbone View Element Properties

When you create Views in Backbone, you often use the "tagName" and "className" attributes, like so:

var itemView = new ItemView({
  model: item,
  tagName: "li",
  className: "item"
});

A Collection of these will look like:

  • Beer
  • Wine
  • Chips

  • One of the things we do all the time in Backbone is set classes on a View's DOM element reflecting properties of its model. For example, say each item on the list has one or both of the classes "inStock" and "purchased" in addition to the class "item", so you'd want your markup to look like:

  • Beer
  • Wine
  • Chips

  • In the past I've often set these classes in the View's render method, like so:

    var ItemView = Backbone.View.extend({
      render: function(){
        var itemData = this.model.toJSON()
            itemEl = $(this.el);
    
        // render the template
        itemEl.html($.mustache($("#item-tpl").html(),itemData));
    
        // set the element classes
        if(itemData.inStock){
          itemEl.addClass("inStock");
        }
        if(itemData.purchased){
          itemEl.addClass("purchased");
        }      
      }
    });
    

    While his works fine, those render methods get big fast, and the more you can do to keep them clean, the better. One thing you can do is remove the setting of those classes to the instantiation method:

    var itemClasses = "item"  // all items get this class
                    + (item.get("inStock") ? " inStock" : "")
                    + (item.get("purchased") ? " purchased" : "");
    var itemView = new ItemView({
      model: item,
      tagName: "li",
      className: itemClasses
    });
    

    ...which leaves you with a much simpler View:

    var ItemView = Backbone.View.extend({
      render: function(){
        var itemData = this.model.toJSON()
            itemEl = $(this.el);
    
        // render the template
        itemEl.html($.mustache($("#item-tpl").html(),itemData));
    
      }
    });
    

    March 30, 2012

    Management and the Hubble

    There's an interesting article making the rounds today:

    http://www.techworld.com.au/article/420036/what_went_wrong_hubble_space_telescope_what_managers_can_learn_from_it_/

    It's about the former head of NASA's Astrophysics division, Charlie Pellerin, and his experiences surrounding the development and subsequent repair of the flawed mirror in the Hubble Space Telescope. It's not a great piece--it devolves into fluff at the end--but the lessons Pellerin's story imply are universal.

    The actual cause of the problem was actually something very simple: a worker at the contractor who was building the main mirror used a shortcut to install a calibration mirror (he cut a hole in a piece of tape and introduced a burr in the mount), leading to a 1.3mm error in the location of the mirror's mount. Because the calibration mirror was used to determine the correctness of the main mirror, the main mirror eventually included that error.

    It turns out everyone knew about the error in the main mirror as soon as they put it in its mount, but came to a rationalization that the way the mirror was mounted allowed gravity to introduce errors--exactly the thing the mount was designed to prevent.

    This type of problem crops up all the time--Pellerin brings up the Challenger launch decision and KAL's famous accident rate in the early 1990's--and the list of ingredients look like every software project I've worked on for the last 15 years:
    1. Teams of smart people, who are
    2. working under pressure,
    3. to deliver something complex
    The key insight the article brings (and the reason I'm writing this) is that the social context in which people do their work is the most important determinant (Pellerin claims about 80%) of the outcome, and this is because of a simple fact:

    Smart, motivated people tend to think that individual abilities determine outcomes, but this is almost never true.

    When smart people encounter problems in project, the first place they look for solutions is inward--"how can I fix this?". Given that the social context is so important, this is actually the last place we should look. We all make this mistake.

    But more importantly, for you and me this has a profound meaning which can be hard to accept:


    Some problems are not fixable.

    As individuals, we can and often do work within the social context to solve a problem, but we've all been faced with situations where the context is out of our control for any number of reasons. And if you can't change that context, 80% of the time you can't fix the problem.

    January 4, 2012

    Flipstatus Born!

    Today I pushed out the project I worked on over my holiday break: v1.0 of flipstatus.com. It's a user-friendly, web-based version of the split-flap display project I've been working on periodically over the last few months, showing a realtime feed of social content. It's got a configuration screen so you don't have to edit any code or run it locally, and I've provided configurations for a few popular monitor resolutions (but the best way to see it is to plug it into your HTDV at 1080i over an HDMI cable).

    The idea started when I went to work on a Twitter plugin for the split-flap project and realized that a general-purpose realtime social display would be a cool tool for more than just developers. What if a restaurant owner could hang a display on his office wall which would show realtime tweets, foursquare checkins, yelp reviews, etc? Or how about a project manager seeing Trac commits on a status board?

    At the moment, I've only hooked it up to Twitter's search API, but since it uses the same plugin architecture as the split-flap project it should be relatively straightforward to write plugins for other APIs. One issue with those oAuth based APIs is that requests are normally rate-limited by the application key, which means that if a bunch of people hit the app at the same time you're going to get cut off. Not sure how to handle that.

    The next step will probably be to write an RSS plugin, since just about everything has an RSS feed. After that I'll need to build the oAuth flow handler to hook up Yelp, Foursquare, Facebook, etc. Eventually I'd like to build plugins for Twilio (SMS) and email handling, but that will require some backend architecture changes.

    For now, hook it up to your TV, put in some twitter usernames, hashtags and/or search terms, and watch it crank away.

    The app is at flipstatus.com, and as usual, this is an open-source project. Feel free to grab the code, play with it and contribute here:

    https://github.com/baspete/flipstatus

    [edit - changed github repo]