I’m expanding my company. I’m looking to hire a polyglot programmer that is comfortable in C#, JavaScript, Ruby, the best tool for the job.

We’re a mix of consulting and software products (just starting our first) and you’ll work with a good group of guys offshore as well. You’ll be setting the architecture for ours and our clients applications, defining user stories and acceptance criteria and making sure quality stays at an extremely high level. TDD and Agile are required.

Compensation will be salary+equity. Chances are, if you’re sr. .Net developer, salary will be lower than what you’re making now. But you’ll have a lot responsibility, and a life (40 hour work weeks). You’ll need to be more excited about owning part of the company and making it into something exceptional.

You can contact me through the website, on twitter at @john_teague, or at john at avenidasoftware.com if you are interested.

Why define anonymous function and pass it jQuery as the argument?

This is the original question title, but it doesn’t really show the nuances of the question’s content. The StackOverflow user really wants to know the difference between an immediately-invoked function expression, and the jQuery DOMReady event:

(function($) {
  // Backbone code in here
})(jQuery);

vs

$(function(){
  // Backbone code in here
});

At a high level, the two blocks of code shown are dramatically different in when and why they execute. They do not serve the same purpose. But they are not exclusive of each other. In fact, you can nest them in to each other if you want – although this can have some odd effects if you’re not careful.

jQuery’s “DOMReady” function

$(function(){
  // Backbone code in here
});

This is an alias to jQuery’s “DOMReady” function which executes when the DOM is ready to be manipulated by your JavaScript code. This allows you to write code that needs the DOM, knowing that the DOM is available and ready to be read, written to, and otherwise modified by your application. 

This is not a module, though. This is only a callback function passed in to the DOMReady alias. The major difference between a module and a callback, in this case, is that jQuery waits for the DOM to be ready and then calls the callback function at the appropriate time – all from the context of jQuery – while a module pattern or immediately invoking function executes immediately after it’s defined. In the above examples, the module is receiving jQuery as a parameter, but this is not the same as using jQuery’s DOMReady event because the module function is called, passing in jQuery as a parameter, immediately. It does not wait for the DOM to be ready. It executes as soon as the function has been parsed.

JavaScript Modules

(function($) {
  // Backbone code in here
})(jQuery);

This is an immediately-invoking function expression (FKA “anonymous function”, “self-invoking function”, etc).

The implementation of this is a function that is immediately invoked by the calling (jQuery) parenthesis. The purpose of passing jQuery in to the parenthesis is to provide local scoping to the global variable. This helps reduce the amount of overhead of looking up the $ variable, and allows better compression / optimization for minifiers in some cases.

In this case, the function is being used as the JavaScript “module” pattern. Modules in the currently implemented version of JavaScript in most browsers, are not specific constructs like functions. Rather, they are a pattern of implementation that use an immediately invoking function to provide scope and privacy around a “module” of related functionality. It’s common for modules to expose a public API – the “revealing module” pattern – by returning an object from the module’s function. But at times, modules are entirely self-contained and don’t provide any external methods to call. 

For more information on modules, see the following resources:

• WatchMeCode Episode 2: Variable Scope (covering modules, which provide scope)
• Ben Alman’s Immediately Invoking Function Expressions Post
• Addy Osmani’s Essential Design Patterns in JavaScript book – the module pattern. 
• Adequately Good: JavaScript Module Pattern In-Depth
• Stoyan Stefanov’s JavaScript Patterns book

Modules vs DOMReady In Backbone Apps

It’s bad form to define your Backbone code inside of jQuery’s DOMReady function, and potentially damaging to your application performance. This function does not get called until the DOM has loaded and is ready to be manipulated. That means you’re waiting until the browser has parsed the DOM at least once before you are defining your objects.

It’s a better idea to define your Backbone objects outside of a DOMReady function. I, among many others, prefer to do this inside of a JavaScript Module pattern so that I can provide encapsulation and privacy for my code. I tend to use the “Revealing Module” pattern (see the links above) to provide access to the bits that I need outside of my module.

Modules And DOMReady In Backbone Apps

You’re likely going to use a DOMReady function even if you define your Backbone objects somewhere else. The reason is that many Backbone apps need to manipulate the DOM in some manner. To do this, you need to wait until the DOM is ready, therefore you need to use the DOMReady function to start your application after it has been defined.

Here’s a very basic example that uses both a Module and the DOMReady function in a Backbone application.

// Define "MyApp" as a revealing module

MyApp = (function(Backbone, $){

  var View = Backbone.View.extend({
    // do stuff here  
  });

  return {
    init: function(){
      var view = new View();
      $("#some-div").html(view.render().el);
    }
  };

})(Backbone, jQuery);



// Run "MyApp" in DOMReady

$(function(){
  MyApp.init();
});

Note that we’re defining the module well before the jQuery DOMReady function is called. We’re also calling the API that our module defined and returned from the module definition, within the DOMReady callback. This is an important point to understand, too. We’re not defining our objects and our application flow inside of the DOMReady callback. We’re defining it elsewhere. We’re letting the application definition live on it’s own. Then after the application has been defined, and when the DOM is ready, the application is started.

By defining your objects outside of the DOMReady function, and providing some way to reference them, you are allowing the browser to get a head start on processing your JavaScript, potentially speeding up the user experience. It also makes the code more flexible as you can move things around without having to worry about creating more DOMREady functions when you do move things.

Topic exchanges are similar to direct exchanges in that they use a routing key to determine which queue a message should be delivered to, but they differ in that they provide the ability to match on portions of a routing key.  When publishing to a topic exchange, a routing key consisting of multiple words separated by periods (e.g. “word1.word2.word3”) will be matched against a pattern supplied by the binding queue.  Patterns may contain an asterisk (“*”) to match a word in a specific segment or a hash (“#”) to match zero or more words.  As discussed earlier in the series, the topic exchange type can be useful for directing messages based on multiple categories or for routing messages originating from multiple sources.

To demonstrate topic exchanges, we’ll return to our logging example, but this time we’ll subscribe to a subset of the messages being published to demonstrate the flexibility of how routing keys are used by topic exchanges.  For this example, we’ll be modeling a scenario where a company may have multiple client installations, each of which may be used to service different sectors of a company’s business model (e.g. Business or Personal sectors).  We’ll use a routing key that specifies the sector and subscribe to messages published for the Personal sector only.

As with our previous examples, we’ll keep things simple by creating console applications for a Producer and a Consumer.  Let’s start by creating the Producer app and establishing a connection using the default settings:

using RabbitMQ.Client;

namespace Producer
{
  class Program
  {
    const long ClientId = 10843;

    static void Main(string[] args)
    {
      var connectionFactory = new ConnectionFactory();
      IConnection connection = connectionFactory.CreateConnection();
    }
  }
}

Rather than just publishing messages directly from the Main() method as with our first logging example, let’s create a separate logger object this time.  Here the logger interface and implementation we’ll be using:

  interface ILogger
  {
    void Write(Sector sector, string entry, TraceEventType traceEventType);
  }

  class RabbitLogger : ILogger, IDisposable
  {
    readonly long _clientId;
    readonly IModel _channel;
    bool _disposed;

    public RabbitLogger(IConnection connection, long clientId)
    {
      _clientId = clientId;
      _channel = connection.CreateModel();
      _channel.ExchangeDeclare("direct-exchange-example", ExchangeType.Topic, false, true, null);
    }

    public void Dispose()
    {
      if (!_disposed)
      {
        if (_channel != null && _channel.IsOpen)
        {
          _channel.Close();
        }
      }
      GC.SuppressFinalize(this);
    }

    public void Write(Sector sector, string entry, TraceEventType traceEventType)
    {
      byte[] message = Encoding.UTF8.GetBytes(entry);
      string routingKey = string.Format("{0}.{1}.{2}", _clientId, sector.ToString(), traceEventType.ToString());
      _channel.BasicPublish("topic-exchange-example", routingKey, null, message);
    }

    ~RabbitLogger()
    {
      Dispose();
    }
  }

In addition to an open IConnection, our RabbitLogger class is instantiated with a client Id.  We use this as part of the routing key.  Since each log can vary by sector, we pass a Sector enum as part of the Write() method.  Here’s our Sector enum:

  public enum Sector
  {
    Personal,
    Business
  }

Returning to our Main() method, we now need to instantiate our RabbitLogger and log messages with differing sectors.  As as way to ensure our client has an opportunity to subscribe to our messages and to help emulate a continual stream of log messages being published, let’s use the logger to publish a series of log messages every second for 10 seconds:

      TimeSpan time = TimeSpan.FromSeconds(10);
      var stopwatch = new Stopwatch();
      Console.WriteLine("Running for {0} seconds", time.ToString("ss"));
      stopwatch.Start();

      while (stopwatch.Elapsed < time)
      {
        using (var logger = new RabbitLogger(connection, ClientId))
        {
          Console.Write("Time to complete: {0} seconds\r", (time - stopwatch.Elapsed).ToString("ss"));
          logger.Write(Sector.Personal, "This is an information message", TraceEventType.Information);
          logger.Write(Sector.Business, "This is an warning message", TraceEventType.Warning);
          logger.Write(Sector.Business, "This is an error message", TraceEventType.Error);
          Thread.Sleep(1000);
        }
      }

This code prints out the time remaining just to give us a little feedback on the publishing progress.  Finally, we’ll close our our connection and prompt the user to exit the console application:

      connection.Close();
      Console.Write("                             \r");
      Console.WriteLine("Press any key to exit");
      Console.ReadKey();

Here’s the full Producer listing:

using System;
using System.Diagnostics;
using System.Text;
using System.Threading;
using RabbitMQ.Client;

namespace Producer
{
  public enum Sector
  {
    Personal,
    Business
  }

  interface ILogger
  {
    void Write(Sector sector, string entry, TraceEventType traceEventType);
  }

  class RabbitLogger : ILogger, IDisposable
  {
    readonly long _clientId;
    readonly IModel _channel;
    bool _disposed;

    public RabbitLogger(IConnection connection, long clientId)
    {
      _clientId = clientId;
      _channel = connection.CreateModel();
      _channel.ExchangeDeclare("direct-exchange-example", ExchangeType.Topic, false, true, null);
    }

    public void Dispose()
    {
      if (!_disposed)
      {
        if (_channel != null && _channel.IsOpen)
        {
          _channel.Close();
        }
      }
      GC.SuppressFinalize(this);
    }

    public void Write(Sector sector, string entry, TraceEventType traceEventType)
    {
      byte[] message = Encoding.UTF8.GetBytes(entry);
      string routingKey = string.Format("{0}.{1}.{2}", _clientId, sector.ToString(), traceEventType.ToString());
      _channel.BasicPublish("topic-exchange-example", routingKey, null, message);
    }

    ~RabbitLogger()
    {
      Dispose();
    }
  }

  class Program
  {
    const long ClientId = 10843;

    static void Main(string[] args)
    {
      var connectionFactory = new ConnectionFactory();
      IConnection connection = connectionFactory.CreateConnection();

      TimeSpan time = TimeSpan.FromSeconds(10);
      var stopwatch = new Stopwatch();
      Console.WriteLine("Running for {0} seconds", time.ToString("ss"));
      stopwatch.Start();

      while (stopwatch.Elapsed < time)
      {
        using (var logger = new RabbitLogger(connection, ClientId))
        {
          Console.Write("Time to complete: {0} seconds\r", (time - stopwatch.Elapsed).ToString("ss"));
          logger.Write(Sector.Personal, "This is an information message", TraceEventType.Information);
          logger.Write(Sector.Business, "This is an warning message", TraceEventType.Warning);
          logger.Write(Sector.Business, "This is an error message", TraceEventType.Error);
          Thread.Sleep(1000);
        }
      }

      connection.Close();
      Console.Write("                             \r");
      Console.WriteLine("Press any key to exit");
      Console.ReadKey();
    }
  }
}

For our Consumer app, we’ll pretty much be using the same code as with our fanout exchange example, but we’ll need to change the exchange type along with the exchange and queue names.  Additionally, we also need to provide a routing key that registers for logs in the Personal sector only.  The messages published by the Producer will be in the form: [client Id].[sector].[log severity], so we can use a routing key of “*.Personal.*” (or alternately “*.Personal.#”).  Here’s the full Consumer listing:

using System;
using System.IO;
using System.Text;
using RabbitMQ.Client;
using RabbitMQ.Client.Events;

namespace Consumer
{
  class Program
  {
    static void Main(string[] args)
    {
      var connectionFactory = new ConnectionFactory();
      IConnection connection = connectionFactory.CreateConnection();
      IModel channel = connection.CreateModel();

      channel.ExchangeDeclare("topic-exchange-example", ExchangeType.Topic, false, true, null);
      channel.QueueDeclare("log", false, false, true, null);
      channel.QueueBind("log", "topic-exchange-example", "*.Personal.*");

      var consumer = new QueueingBasicConsumer(channel);
      channel.BasicConsume("log", true, consumer);

      while (true)
      {
        try
        {
          var eventArgs = (BasicDeliverEventArgs) consumer.Queue.Dequeue();
          string message = Encoding.UTF8.GetString(eventArgs.Body);
          Console.WriteLine(string.Format("{0} - {1}", eventArgs.RoutingKey, message));
        }
        catch (EndOfStreamException)
        {
          // The consumer was cancelled, the model closed, or the connection went away.
          break;
        }
      }

      channel.Close();
      connection.Close();
    }
  }
}

Setting the solution to run both the Producer and Consumer on startup, we should see similar output to the following listings:

Producer

Running for 10 seconds
Time to complete: 06 seconds

Consumer

10843.Personal.Information - This is an information message
10843.Personal.Information - This is an information message
10843.Personal.Information - This is an information message
10843.Personal.Information - This is an information message
10843.Personal.Information - This is an information message
10843.Personal.Information - This is an information message
10843.Personal.Information - This is an information message

This concludes our topic exchange example.  Next time, we’ll walk through an example using the final exchange type: Header Exchanges.

jQuery

The most basic option in serializing a form’s elements in to use jQuery’s serialize or serializeArray methods. These methods work well and make it easy to get data out of your form. But they have limitations that I don’t like:

The serialize method encodes the values in to a URL encoding. This works well if you plan on using the data as URL parameters in an HTTP GET or other similar manner. But if you want to use the data in your JavaScript code, it’s a bit of a pain to work with.

The serializeArray method return a JavaScript array that contains objects each with a name and value key. So, a text input with a “name” of “foo” would return [{name: "foo", value: "bar"}]. This works much better for dealing with the data in your JavaScript code, but is still severely constrained. You don’t have direct access to the key/value pairs based on the name of the input element. Instead, you have to search through the array of objects and find the one you want. 

What I want, instead, is a way to serialize a form into a plain JavaScript object where the object’s attributes (or keys) are the input element ids, with the key’s value set to the value of the input element.

Backbone.Syphon

Backbone.Syphon aims to make it easy to serialize the form inputs of a Backbone.View in to a simple JSON object that contains all of the values from the form. All you need to do is call `Backbone.Syphon.serialize(view)` and it will return a JavaScript object to you with key / value pairs that match the input element ids and values.

For example, with this underscore template:

<script id="my-form-template" type="text/html">
  <form>
    <input type="text" id="foo" value="bar">
    <input type="checkbox" id="chk" checked>
  </form>
</script>

And this Backbone.View setup:

Backbone.View.extend({
  events: {
    "submit form": "formSubmitted"
  },

  formSubmitted: function(e){
    e.preventDefault();

    var data = Backbone.Syphon.serialize(this);
    this.model.set(data);

    this.model.save();
  },

  render: function(){
    // build the view's form, here
  }
});

When you click the “save” button, the handler for the click calls `Backbone.Syphon.serialize(this)`. This returns an object that looks like this:

{
  foo: "bar",
  chk: true
}

The large benefit of this output is that you can immediately pass it to a Backbone.Model instance via the `set` method. There’s no need to sift through it and pull out the bits you need, like the jQuery serialize methods. Of course you can use it for more than just Backbone models, too. Anywhere that you need the data from your form, you can get it with Syphon and use it right away.

I use this plugin in several of my projects already – well, precursors that were poorly written and not tested thoroughly, at least. But I plan on continuing to use this plugin in scenarios where I need to get data out of my forms. Data-binding plugins just don’t interest me anymore, as I’ve gone down that path and abandoned it. 

Serializes By Element Id

There are a handful of limitations in this first release. One of the largest is that all of the input elements will be serialized by the `id` attribute of the element. Look at the example above again, and you’ll notice that the text input with an id of “foo” was serialized in to a `{foo: “bar”}` attribute on the resulting object. I’m sure this will change over time, and become something more configurable. But for now, this was all I needed as I tend to use the id of a field as the key for my object’s data.

For more information on the current limitations, see the documentation.

Some-what Pluggable Serialization

I’ve built this plugin more than a few times at this point, starting with direct client needs and eventually turning in to the plugin that it is now. One of the lessons that I learned in rebuilding it a few times is that the process of serializing the input elements needs to be pluggable. I can’t limit how it reads the data from the input elements, because there are different needs for different situations. 

With that in mind, I built in the idea of “Input Readers“. An Input Reader is a callback function that is registered against a particular input type, and is used to read the data from that type of input. 

At the moment, there are only two built in input readers: the default, which handles nearly everything, and the checkbox reader. The default reader uses jQuery’s `val()` function to get the value out of the input. This works for nearly every type of input. But there are some cases where this isn’t what you want to do. For example, I generally use checkboxes as boolean values instead of an actual text value. To handle this, then, I created the built in checkbox input reader. It uses jQuery’s `prop()` function to read the state of the checkbox and tell me whether or not the checkbox is checked. If you look at the previous example again, you’ll see that the “chk” checkbox is returning a boolean value.

Initial Build And Release As A Screencast

There are several reasons that this initial release is so small and limited in scope and functionality. The largest of which is that it covers the majority of my needs, and like all of my plugins and add-ons, I figure out what I need and the common things that I do across projects first. Then when I have the majority of my cases covered, I start looking at what others need in order to get their projects up and running.

Another reason that this release is limited, is because I decided to record the creation of the plugin as a live screencast – a “prequel” of sorts, to the first “Refactoring JavaScript” screencast that I released last year. In this case, the end product of the Backbone.Syphon plugin is more of a side effect than the purpose of the screencast. The real focus of the screencast is the tools and processes that I use to get a plugin like this off the ground, built and delivered. 

If you’re an audio/video learner and you want to see my process for creating something from nothing more than the ideas in my head, then you should check out Episode 7 of WatchMeCode: Building A Backbone Plugin (Live). And if you’re looking for a way to get up to speed with test-driven JavaScript, including a basic introduction to Jasmine and refactoring an existing application that is covered by Jasmine tests, then you might be interested in the Jasmine Live! multi-pack of screencasts.

Documentation, Downloads, And Moving Forward

If you’d like to get your hands on Syphon, head over to the Github repository. There are links to the the downloads and a little bit of documentation to show how to use it (the same as what I showed here), as well as some discussion on the current limitations of the plugin.

I’m hoping to get some input and assistance from others that could use a plugin like this, moving forward. I’d like to see this project fleshed out so that it can be used in a broader set of scenarios, with more options for how the data is serialized from the input elements. At the same time, though, I’m going to be rather picky about how the implementation moves forward. I don’t want to end up with another 1,000 line blob of unmaintainable garbage, like my ModelBinding plugin. As it stands now, though, Syphon’s code is starting out on the right foot. I just need to keep it heading down a clean path as it moves forward.

As discussed earlier in the series, the fanout exchange type is useful for facilitating the publish-subscribe pattern. When we publish a message to a fanout exchange, the message is delivered indiscriminately to all bound queues. With the Direct, Topic, and Headers exchange types, a criteria is used by a routing algorithm taking the form of a routing key or a collection of message headers depending on the exchange type in question. A routing key or a collection of message headers may also be specified with the fanout exchange which will be delivered as part of the message’s metadata, but they will not be used as a filter in determining which queue receives a published message.

To demonstrate the fanout exchange, we’ll use a stock ticker example. In the previous example, logs were routed to queues based upon a matching routing key (an empty string in the logging example’s case). In this example, we’d like our messages to be delivered to all bound queues regardless of qualification.

Similar to the previous example, we’ll create a Producer console application which periodically publishes stock quote messages and a Consumer console application which displays the message to the console.

We’ll start our Producer app as before by establishing a connection using the default settings, creating the connection, and creating a channel:

namespace Producer
{
  class Program
  {
    static volatile bool _cancelling;

    static void Main(string[] args)
    {
      var connectionFactory = new ConnectionFactory();
      IConnection connection = connectionFactory.CreateConnection();
      IModel channel = connection.CreateModel();
    }
  }
}

Next, we need to declare an exchange of type “fanout”. We’ll name our new exchange “fanout-exchange-example”:

channel.ExchangeDeclare("direct-exchange-example", ExchangeType.Fanout, false, true, null);

To publish the stock messages periodically, we’ll call a PublishQuotes() method with the provided channel and run it on a background thread:

var thread = new Thread(() => PublishQuotes(channel));
thread.Start();

Next, we’ll provide a way to exit the application by prompting the user to enter ‘x’ and use a simple Boolean to signal the background thread when to exit:

Console.WriteLine("Press 'x' to exit");
var input = (char) Console.Read();
_cancelling = true;

Lastly, we need to close the channel and connection:

channel.Close();
connection.Close();

For our PublishQuotes() method, well iterate over a set of stock symbols, retrieve the stock information for each symbol, and publish a simple string-based message in the form [symbol]:[price]:

static void PublishQuotes(IModel channel)
{
  while (true)
  {
    if (_cancelling) return;
    IEnumerable quotes = FetchStockQuotes(new[] {"GOOG", "HD", "MCD"});
    foreach (string quote in quotes)
    {
      byte[] message = Encoding.UTF8.GetBytes(quote);
      channel.BasicPublish("direct-exchange-example", "", null, message);
    }
    Thread.Sleep(5000);
  }
}

To implement the FetchStockQuotes() method, we’ll use the Yahoo Finance API which entails retrieving an XML-based list of stock quotes and parsing out the bit of information we’re interested in for our example:

static IEnumerable<string> FetchStockQuotes(string[] symbols)
{
  var quotes = new List<string>();

  string url = string.Format("http://query.yahooapis.com/v1/public/yql?q=select%20*%20from%20yahoo.finance.quotes%20where%20symbol%20in%20({0})&env=store://datatables.org/alltableswithkeys",
      String.Join("%2C", symbols.Select(s => "%22" + s + "%22")));
  var wc = new WebClient {Proxy = WebRequest.DefaultWebProxy};
  var ms = new MemoryStream(wc.DownloadData(url));
  var reader = new XmlTextReader(ms);
  XDocument doc = XDocument.Load(reader);
  XElement results = doc.Root.Element("results");

  foreach (string symbol in symbols)
  {
    XElement q = results.Elements("quote").First(w => w.Attribute("symbol").Value == symbol);
    quotes.Add(symbol + ":" + q.Element("AskRealtime").Value);
  }

  return quotes;
}

Here is the complete Producer listing:

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.IO;
using System.Linq;
using System.Net;
using System.Text;
using System.Threading;
using System.Xml;
using System.Xml.Linq;
using RabbitMQ.Client;

namespace Producer
{
  class Program
  {
    static volatile bool _cancelling;

    static void Main(string[] args)
    {
      var connectionFactory = new ConnectionFactory();
      IConnection connection = connectionFactory.CreateConnection();
      IModel channel = connection.CreateModel();
      channel.ExchangeDeclare("direct-exchange-example", ExchangeType.Fanout, false, true, null);

      var thread = new Thread(() => PublishQuotes(channel));
      thread.Start();

      Console.WriteLine("Press 'x' to exit");
      var input = (char) Console.Read();
      _cancelling = true;

      channel.Close();
      connection.Close();
    }

    static void PublishQuotes(IModel channel)
    {
      while (true)
      {
        if (_cancelling) return;
        IEnumerable quotes = FetchStockQuotes(new[] {"GOOG", "HD", "MCD"});
        foreach (string quote in quotes)
        {
          byte[] message = Encoding.UTF8.GetBytes(quote);
          channel.BasicPublish("direct-exchange-example", "", null, message);
        }
        Thread.Sleep(5000);
      }
    }

    static IEnumerable<string> FetchStockQuotes(string[] symbols)
    {
      var quotes = new List<string>();

      string url = string.Format("http://query.yahooapis.com/v1/public/yql?q=select%20*%20from%20yahoo.finance.quotes%20where%20symbol%20in%20({0})&env=store://datatables.org/alltableswithkeys",
          String.Join("%2C", symbols.Select(s => "%22" + s + "%22")));
      var wc = new WebClient {Proxy = WebRequest.DefaultWebProxy};
      var ms = new MemoryStream(wc.DownloadData(url));
      var reader = new XmlTextReader(ms);
      XDocument doc = XDocument.Load(reader);
      XElement results = doc.Root.Element("results");

      foreach (string symbol in symbols)
      {
        XElement q = results.Elements("quote").First(w => w.Attribute("symbol").Value == symbol);
        quotes.Add(symbol + ":" + q.Element("AskRealtime").Value);
      }

      return quotes;
    }
  }
}

Our Consumer application will be similar to the one used in our logging example, but we’ll change the exchange name, queue name, and exchange type and put the processing of the messages within a while loop to continually display our any updates to our stock prices. Here’s the full listing for our Consumer app:

using System;
using System.IO;
using System.Text;
using RabbitMQ.Client;
using RabbitMQ.Client.Events;

namespace Consumer
{
  class Program
  {
    static void Main(string[] args)
    {
      var connectionFactory = new ConnectionFactory();
      IConnection connection = connectionFactory.CreateConnection();
      IModel channel = connection.CreateModel();

      channel.ExchangeDeclare("direct-exchange-example", ExchangeType.Fanout, false, true, null);
      channel.QueueDeclare("quotes", false, false, true, null);
      channel.QueueBind("quotes", "direct-exchange-example", "");

      var consumer = new QueueingBasicConsumer(channel);
      channel.BasicConsume("quotes", true, consumer);

      while (true)
      {
        try
        {
          var eventArgs = (BasicDeliverEventArgs) consumer.Queue.Dequeue();
          string message = Encoding.UTF8.GetString(eventArgs.Body);
          Console.WriteLine(message);
        }
        catch (EndOfStreamException)
        {
          // The consumer was cancelled, the model closed, or the connection went away.
          break;
        }
      }

      channel.Close();
      connection.Close();
    }
  }
}

Setting our solution startup projects to run both the Producer and Consumer apps together, we should see messages similar to the following for the Consumer output:

GOOG:611.62
HD:48.66
MCD:91.06
GOOG:611.58
HD:48.66
MCD:91.06

To show our queue would receive messages published to the fanout exchange regardless of the routing key value, we can change the value of the routing key to “anything”:

channel.QueueBind("quotes", "direct-exchange-example", "anything");

Running the application again shows the same values:

GOOG:611.62
HD:48.66
MCD:91.06
GOOG:611.58
HD:48.66
MCD:91.06

That concludes our fanout exchange example. Next time, we’ll take a look at the topic exchange type.

The problem really exacerbates itself when too much was happening at once, and the need to break things out to improve throughput requires a different protocol for integration.

Consider going to the grocery store. When you place an item in your basket, it’s inherently a synchronous operation. Either the jar of pickles makes it into your cart, or it doesn’t, there is no middle ground there. If you drop the jar of pickles onto the ground, you don’t wait for some async process to come by and let you know by email, “sorry, it seems there was a problem with your request to add the item to your shopping cart.”

Blending async in

Consider another system that requires to you to register with the site, using a local database for “who is registered” and a web service for downstream email communication:

In this system, we block the registration of the user against both the local database and the 3rd party web service. We need to check the local database to make sure the username/email is not already used, but what about that web service? What happens when that web service is slow, or unavailable?

We’ve coupled the availability of our system with a system we don’t own, which is potentially disastrous. In the real-world system that the above diagram is based on, when that 3rd party system goes into scheduled maintenance, the web application is brought down for maintenance too! Not a good user experience by any means. Are we really going to turn users away based on the availability of a downstream service?

But there’s another way – shifting the protocol of how this system is built. Let’s make sure what needs to be synchronous is, what what doesn’t need to be, isn’t. Instead of coupling the web service and local database calls together, let’s separate the two out with messaging:

Instead of performing the web service call in the same thread of the UI request, we instead send an asynchronous command as a message to perform the downstream operation. We’ve now decoupled the operation of calling the web service (what doesn’t need to be synchronous) with what does need (registering the user). The downstream operations of registering the user in the 3rd party email provider doesn’t need to happen at the same time.

To put it another way – does it affect the user’s registration if the email service provider rejects the message? No! Instead, that’s likely an administrative operation to figure out what happened, but the user is still successfully registered.

Defining the boundaries

When it comes time to figure out what should be synchronous and what shouldn’t, the key is to figure out what information, operations and behaviors your system owns versus are owned by someone else. If you own the UI and the database, then synchronous is a good possibility. If you don’t own the system (like our web service above), then async is a good possibility.

Next time: sync, async and CQRS.

Here’s the gist of that again:

orgChart = {

  addNewEmployee: function(){
    var that = this;

    var employeeDetail = this.getEmployeeDetail();
    employeeDetail.on("complete", function(employee){

      var managerSelector = that.selectManager(employee);
      managerSelector.on("save", function(employee){
        employee.save();
      });

    });
  },

  getEmployeeDetail: function(){
    var form = new EmployeeDetailForm();
    form.render();
    $("#wizard").html(form.el);
    return form;
  },

  selectManager: function(employee){
    var form = new SelectManagerForm({
      model: employee
    });
    form.render();
    $("#wizard").html(form.el);
    return form;
  }
}

// implementation details for EmployeeDetailForm go here

// implementation details for SelectManagerForm go here

// implementation details for Employee model go here

I’ve implemented various views and objects in various manners, in order to facilitate that workflow, but what it always comes down to is that the objects facilitating the workflow need to trigger events. 

A Basic Implementation

The most common way of triggering an event from a Backbone.View is to have some DOM events handled, and from the event handler/callback method for that, trigger the event you want:

SomeView = Backbone.View.extend({

  events: {
    "click .next": "nextClicked",
    "click .previous": "previousClicked"
  },

  nextClicked: function(e){
    e.preventDefault();
    this.trigger("next")
  },

  previousClicked: function(e){
    e.preventDefault();
    this.trigger("previous");
  }

});

This works well. I’ve done this more times than I can count. But there’s a lot of redundancy here. You can see that both of the DOM events that I’m handling have a callback method, and both of the callback methods do nothing more than trigger an event from the view itself so that the workflow can move forward.

We can do better than that… enter Marionette’s new “triggers”.

Reducing Event Triggering To Configuration

With the v0.8.2 release of Marionette, I’ve introduced the idea of view triggers – a way to configure a DOM event to trigger a view event. So instead of having to write all of that redundant code, where the only real difference is the name of the callback method and the name of the event that’s triggered, we can write this:

SomeView = Backbone.Marionette.ItemView.extend({

  // ...

  triggers: {
    "click .next": "next",
    "click .previous": "previous"
  }

});

Must shorter. Much cleaner.

You can see that the left side of the hash is a standard Backbone.View events setup where you specify the DOM event and element selector. Then on the right hand side, specify the name of the event that you want the view to trigger when that DOM event fires. Then, when I click on the “.next” element, the view will trigger a “next” event for me. Similarly, clicking the “.previous” element will trigger a “previous” event.

Trigger From Any Marionette View

Triggers can be used from any Marionette view. You’re not limited to the ItemView type that I showed. In fact, the trigger functionality is built in to the base Backbone.Marionette.View, so even if you are creating your own specialized view type, you only need to extend from that in order to get this functionality.

Limitations

Of course this isn’t a “complete” solution for handling events in your views, by any means. If you need to do anything more than trigger the event by itself, you should still use a standard event handler and callback method. At this point, there’s no way for you to configure any kind of data or objects to be passed through the event itself. But this may be added at some point in the future. I wrote this fairy quickly last night, and it suits my needs right now. 

For simple scenarios where you just need to trigger an event from the view, though, this works well. I’m using it in several places where my workflow is just to display a button or a link, and have that clickable item move on to another part of the application.

I want to hear what you have to say.

If you know a developer who ought to be presenting at conferences or writing blog posts and isn’t, deploy that phrase. Say to him or her, “I wish you would submit a talk to [conference|user group] on [subject of expertise] because you have good ideas, and I want to hear your thoughts on the subject.”

You feel exasperated about your powerlessness to change the lack of diversity in our profession? To the point that you feel antagonized just hearing about it? Me, too. This is something you can do. A personal appeal, delivered one-on-one, can do so much good. Do it.

I resisted Twitter forever because, every time I asked someone why I should sign up, they answered with something irrelevant about all the funny things you could read, or whatever. No one ever said, “I wish you’d join Twitter, Sharon, because I want to hear what you have to say.”

How many of us dismiss those calls for speakers, thinking “What would I talk about? I’m not doing anything cutting-edge”? Imagine if someone encouraged you, reminded you of a skill you’ve forgotten is interesting and valuable, simply asked you to share your knowledge and ideas. Would that feel empowering? Do that for someone.

A lot of you wish our industry were more diverse. You’d welcome it if it could somehow happen. But it feels like a problem far bigger than the reach of one person. Scarily so, if you want my take on it. This, however, we can do, one person, by one person, by one person:

I want to hear what you have to say.

A Poorly Constructed Workflow

It seems to be common in the JavaScript applications world, to have very poorly defined and constructed workflow in applications. We take one object and build some functionality. Then when the next part of the app needs to fire up, we call the object that runs it directly from the first object. Then when the next part of the app is requested, we call that object from the second one. And we continue on down this path ad-infinitum, creating a mess of tightly coupled concerns, tightly coupled concepts, tightly coupled objects, and a brittle and fragile system that is dependent entirely on the implementation details to understand the higher level concept.

For example, might have a human resources application that allows you to add a new employee and select a manager for the employee. After entering a name and email address, we would show the form to select the manager. When the user clicks save, we create the employee. A crude, but all too common implementation of this workflow might look something like this:

EmployeeInfoForm = Backbone.View.extend({
  events: {
    "click .next": "nextClicked"
  },

  nextClicked: function(e){
    e.preventDefault();

    var data = {
      name: this.$(".name").val(),
      email: this.$(".email").val()
    };

    var employee = new Employee(data);

    this.selectManager(employee);
  },

  selectManager: function(employee){
    var view = new SelectManagerForm({
      model: employee
    });
    view.render();
    $(".wizard").show(view.el);
  },

  // ...
  render: function(){ ... }
  // ... etc
});

SelectManagerForm = Backbone.View.extend({
  events: {
    "click .save": "saveClicked"
  },

  saveClicked: function(e){
    e.preventDefault();

    var managerId = this.$(".manager").val();
    this.model.set({managerId: managerId});

    this.model.save();
    // do something to close the wizard and move on  
  },

  // ...
  render: function() { ... }
  // ... etc
});

Can you quickly and easily describe the workflow in this example? If you can, then you’re a better person than I am. I have to spend time looking at the implementation details of both views in order to see what’s going on and why. I have to piece together the bits from multiple places and form a more coherent high level overview in my head. It’s not easy for me to see what’s going on because every time I look at another part of the code, I have to put together the pieces again to make sure I am not breaking someone from the other parts.

Too Many Concerns

We’ve mixed two different concerns in to very few objects, and we’ve taken those concerns and split them apart in some rather un-natural ways at that.

The first concern is the high level workflow:

1. enter employee info
2. select manager
3. create employee

The second concern is the implementation detail:

1. Show the EmployeeInfoForm 
2. Allow the user to enter a name and email address
3. When “next” is clicked, gather the name and email address of the employee. 
4. Then show the SelectManagerForm with a list of possible managers to select from. 
5. When “save” is clicked, grab the selected manager
6. Then take all of the employee information and create a new employee record on the server

And I haven’t even gone through any of the secondary and third level workflow in this. What happens when the user hits cancel on the first screen? Or on the second? What about invalid email address validation? If we start adding in all of those steps to the list of implementation details, this list of steps to follow is going to get out of hand very quickly.

By implementing both the high level workflow and the implementation detail in the views – the details and implementation – we’ve destroyed our ability to see the high level workflow at a glance. That will cause problems for us as developers, because we will forget some of those details when changing the system, and we will break things.

Modeling An Explicit Workflow In Code

What we want to do, instead, is get back to that high level workflow with fewer bullet points and very little text in each point. But we don’t want to have to dig through all of the implementation details in order to get to it. We want to see the high level workflow in our code, separated from the implementation details. This makes it easier to change the workflow and to change any specific implementation detail without having to rework the entire workflow.

Wouldn’t it be nice if we could write this code, for example:

orgChart = {

  addNewEmployee: function(){
    var employeeDetail = this.getEmployeeDetail();
    employeeDetail.on("complete", function(employee){

      var managerSelector = this.selectManager(employee);
      managerSelector.on("save", function(employee){
        employee.save();
      });

    });
  },

  // ...
}

In this pseudo-code example, we can more clearly see the high level workflow. When we complete the employee info, we move on to the selecting a manager. When that completes, we save the employee with the data that we had entered. It all looks very clean and simple. We could even add in some of the secondary and third level workflow without creating too much mess. And more importantly, we could get rid of some of the nested callbacks with better patterns and function separation.

But let’s see what this would really look like in code that we could execute:

orgChart = {

  addNewEmployee: function(){
    var employeeDetail = this.getEmployeeDetail();
    employeeDetail.on("complete", function(employee){

      var managerSelector = this.selectManager(employee);
      managerSelector.on("save", function(employee){
        employee.save();
      });

    });
  },

  // ...
}

Yeah – turns out this is code that we can actually run, and it can be implemented fairly easily with a couple of Backbone views and a model for the details:

orgChart = {

  addNewEmployee: function(){
    var that = this;

    var employeeDetail = this.getEmployeeDetail();
    employeeDetail.on("complete", function(employee){

      var managerSelector = that.selectManager(employee);
      managerSelector.on("save", function(employee){
        employee.save();
      });

    });
  },

  getEmployeeDetail: function(){
    var form = new EmployeeDetailForm();
    form.render();
    $("#wizard").html(form.el);
    return form;
  },

  selectManager: function(employee){
    var form = new SelectManagerForm({
      model: employee
    });
    form.render();
    $("#wizard").html(form.el);
    return form;
  }
}

// implementation details for EmployeeDetailForm go here

// implementation details for SelectManagerForm go here

// implementation details for Employee model go here

I’ve obviously omitted some of the details of the views and model, but you get the idea.

The Benefits

There are a number of benefits to writing code like this. It’s easy to see the high level workflow. We don’t have to worry about all of the implementation details for each of the views or the model when dealing with the workflow. We can change any of the individual view implementations when we need to, without affecting the rest of the workflow (as long as the view conforms to the protocol that the workflow defines). And there’s probably a handful of other benefits, as well. 

But the largest single benefit of all these, in my experience, is being able to see the workflow at a glance. 6 months from now – or if you’re like me, 6 hours from now – you won’t remember that you have to trace through 5 different Views and three different custom objects and models, in order to piece together the workflow that you spun together in the sample at the very top of this post. But if you have a workflow as simple as the one that we just saw, where the workflow is more explicit within a higher level method, separated from the implementation details… well, then you’re more likely to pick up the code and understand the workflow quickly. 

The Drawbacks

Everything has a price, right? But the price for this is fairly small. You will end up with a few more objects and a few more methods to keep track of. There’s a mild overhead associated with this in the world of browser based JavaScript, but that’s likely to be so small that you won’t notice.

The real cost, though, is that you’re going to have to learn new implementation patterns and styles of development in order to get this working, and that takes time. Sure, looking at an example like this is easy. But it’s a simple example and a simple implementation. When you get down to actually trying to write this style of code for yourself, in your project, with your 20 variations on the flow through the application, it will get more complicated, quickly. And there’s no simple answer for this complication in design, other than to say that you need to learn to break down the larger workflow in to smaller pieces that can look as simple as this one.

But It’s Worth It

In the end, in spite of potential drawbacks and learning curves, making an effort to explicitly model your workflow in your application is important. And it really doesn’t matter what language your writing your code in. I’ve shown these examples in JavaScript and Backbone because that’s what I’m using on a daily basis at this point. But I’ve been applying these same rules to C#/.NET, Ruby and other languages for years. The principles are the same, it’s just the implementation specifics that change.

And I need your help to answer these questions and improve the documentation and wiki.

The Marionette Wiki

In addition to the technical documentation in the project’s readme, I’ve started up the wiki on the github project page. I’ve begun with two simple pages: an overview on the different view types, and page to let Marionette users show of their projects and websites that are using it.

Help me and the rest of the community of Marionette users improve the documentation for this project by providing examples, best practices, answers to frequently asked questions, and more. 

Head over to the wiki and start helping! 

https://github.com/derickbailey/backbone.marionette/wiki

Topics To Cover

Example topics that should be covered in the wiki:

• Using Marionette with RequireJS
• Using JST templates with Marionette views
• Using Handlebars templates with Marionette views
• Using jQuery plugins and visual controls with Marionette
• and much, much more

I realize that some of these are items that I’ve blogged about here. One of my hopes and goals is to have many of the Marionette blog posts from this blog, copied in to the Wiki in a manner that makes sense for the wiki. I will try to do some of this myself, but it would also be wonderfully helpful if other members of the Marionette community could assist in doing this.

I Need Your Help. Yes. YOU.

I know I’m asking a lot – but I believe the community of Marionette users is up to it. It only takes a few minutes of time to improve one page or create a new one with some very basic information. Then another person can come along and make another improvement. Then another, and another. 

Lastly: don’t think “oh, someone else will do it”. They won’t. Believe me. The distribution of responsibility is the single largest reason that people won’t take responsibility or put effort in to something. Everyone assumes that someone else will do it, and no one actually does it.

The list of proposed sessions are available on the web site http://austincodecamp2012.com. Please look at the sessions and vote for the ones you find most interesting.  We use this information to place the presenations in an appropriately sized room (though some will be cancelled I’m sure)

It’s going to be a great conference!

Also if your company would like to sponsor, please contact us.

Really the notion of versions for a bunch of scripts on which noone depends seems a bit silly…if a feature seems to be missing, get latest from master. If it’s still missing, send me a pull request (or log an issue). But I suppose it’s good to check in periodically to document what we’ve been up to.

New in this release:

• Git 1.7.2 or better is required
  • And I fixed a bug that prevented it from working with 1.7.10.
• Prompt status now plays nicely with posh-hg without extra hacks
• Functions are now provided for using ssh-agent to save credentials
  • If you get a warning that ssh-agent could not be found, either add an ssh-agent PowerShell alias or add the path to Git\bin in your PATH environment variable
• Branch in prompt status is now colored according to being ahead of or behind a tracked reference (see readme for an explanation of default colors)
• Added tab expansion for a bunch of new commands and options (remote refs, revert, tfs, bisect, submodule, and more!)
• Tab expansion works for aliases of git (I recommend g)
  Contributed by Mark Borcherding
• The list of commands expanded by default now covers most porcelain commands.
  • You can always get all commands to expand by setting $GitTabSettings.AllCommands = $true
• Values of $LASTERRORCODE for the last real command are preserved through the prompt
• If prompt performance for a repository is not acceptable, that repo’s path can be added to $GitPromptSettings.RepositoriesInWhichToDisableFileStatus
  Contributed by Eric Lee
• posh-git should work in the Nuget Package Manager Console, though you’ll probably want to change the colors
• The GIT_DIR environment variable is used if defined
  Contributed by Daniel Dabrowski

Several others have contributed bug fixes as well—thanks everyone! It’s pretty awesome to work on something that someone else cares enough about to help improve.

If all goes according to plan, the next time you hear from me (about posh-git) will be to announce that migration to LibGit2Sharp is complete. I’m optimistic that the move will address the persistent performance concerns for large repositories. If you have a particularly troublesome repo, feel free to try my libgit2 branch and let me know if it’s better (or worse).

Non-CRUD-y Apps

Now I don’t think that there’s anything wrong with Backbone’s “save”, “fetch” and “destroy” methods. They’re quite handy, and very well done. The deciding factor in using them is whether or not my application is CRUD-y or not. That is to say, many of my recent apps are taking more of a command approach to user interaction and data updates. Instead of just having simple Create, Read, Update and Delete forms on my apps, I tend to have smaller and more focused commands that are called.

For example, signing a terms of service agreement is a command to sign the agreement, not just a “create” on a resource. Sure, the implementation of that may be a “POST” on a resource location. But that doesn’t mean I need a full Backbone model, or need to think about the signature as a RESTful resource from my JavaScript code.

Executing Commands vs Making AJAX Calls

As a result of all this, I end up using $.ajax a lot… and it’s getting really ugly and obnoxious seeing this all over my code:

var signForm = $.ajax({
  type: "POST",
  url: "/some/form",
  dataType: "JSON",
  data: myData
});

signForm.done(function(response){
  // handle success here
});

signForm.fail(function(response){
  // handle failure here
});

Not only is this ugly when you repeat the $.ajax calls all over the code, but it doesn’t really give the semantic benefit of knowing what the code is really doing. I’m not just making a call across an AJAX connection. I’m trying to execute a command – I’m trying to do something important, and I want my code to reflect that.

So I wrapped up my $.ajax calls in a thin “command” wrapper for my current client app (built with Backbone of course), and ended up with this instead:

// Register a command to use
// -------------------------

Backbone.AjaxCommands.register("signForm", {
  url: "/some/form",
  type: "POST"
});


// somewhere else in the application, use the command
// --------------------------------------------------

var signForm = Backbone.AjaxCommands.get("signForm");

signForm.on("success", function(response){
  // handle success here
});

signForm.on("error", function(response){
  // handle failure here
});

// execute the command and send this data with it
signForm.execute(myData);

Looking at this in comparison to the original $.ajax calls, there are a few less lines of code. Since I have a thin wrapper around the ajax calls and setup, I can make a few assumptions about the calls and provide a little bit of default configuration. 

I can also move the registration of commands somewhere other than the execution of the commands, which is a huge win for readability and organization of the code when it comes time to execute a command.

Of course the handling of events for success, error and completed doesn’t give me any advantage over $.ajax and deferred objects. But the big benefit here and why I don’t mind the thin wraper around the done/fail/always deferred methods, is the semantic value of executing a named command vs configuring an ajax call.

And before you go in to a “semantics are not important” lapse of sanity, just think a little about this line that I once heard from Sharon Cichelli:

“Semantics will continue to be important until we learn to communicate in something other than language.“

Implementing The Command Structure

This implementation relies on Backbone, Underscore and jQuery, so it’s really only useful in Backbone applications at this point. It’s also important to note that this code is not unit tested at all. I’m using it in my current client application and it is functional for me, but I don’t recommend taking this code as a great implementation, yet. I have plans on turning this into a real plugin, with full testing around it. But like most of my plugins and libraries, it started out as a quick hack in order to get something cleaned up in one of my applications.

// Backbone.AjaxCommands
// ---------------------

Backbone.AjaxCommands = (function (Backbone, $, _) {
    var Commands = {};

    // Private data
    // ------------

    var commandList = {};

    // Public API
    // ----------

    Commands.register = function (commandName, options) {
        commandList[commandName] = options;
    }

    Commands.get = function (commandName) {
        var options = commandList[commandName];
        options = options || {};
        options = _.clone(options);
        var command = new Commands.Command(commandName, options);
        return command;
    };

    // Command Type
    // -------------------

    Commands.Command = function (name, options) {
        this.name = name;
        this.options = options
    };

    _.extend(Commands.Command.prototype, Backbone.Events, {
        execute: function (data) {
            var that = this;

            var config = this.getAjaxConfig(this.options, data);

            this.trigger("before:execute");

            var request = $.ajax(config);
            request.done(function (response) {
                that.trigger("success", response);
            });

            request.fail(function (response) {
                that.trigger("error", response);
            });

            request.always(function (response) {
                that.trigger("complete", response);
            });
        },

        getAjaxConfig: function (options, data) {
            var url = this.getUrl(options, data);

            var ajaxConfig = {
                type: "GET",
                dataType: "JSON",
                url: url
            };

            _.extend(ajaxConfig, options);
            ajaxConfig.data = data;

            return ajaxConfig;
        },

        getUrl: function (options, data) {
            return options.url;
        }
    });

    return Commands;
})(Backbone, $, _);

There ar ea couple of things you’ll want to note in this code:

The call to “register” a command stores the configuration that you provide. The call to “get” a command creates a new command instance and hands it back to you. This is done so that you can have single-use command objects and not have to worry about unbinding events from the command after it has completed. If I held on to a single command instance and just handed that back to you, you would be responsible for unbinding the event handlers after executing the command. 

The wrapper events for “success”, “error”, and “complete” also don’t guarantee to fire if you subscribe to them after the command has been executed. So, it’s important to set up your event handlers before calling .execute on the command object.

I’ve also extracted the “getUrl” method specifically because I need to provide a very custom implementation of this method in my client’s application. I have another plugin that I’m looking at writing, which handles storage and retrieval of URLs in my Backbone apps, including :token replacement in the urls … but that’s another blog post and another plugin to write.

A Timed Polling Mechanism

One of the more interesting things I’m doing with this is using it as a timed polling mechanism. I set up a command and then I wrap the commands “execute” function in another method that I can call from a setTimeout. When the command executes, I check the response. If I find the data I need, I move on. If I don’t find the data I need, I call the wrapper function again, inside of a setTimeout.

var myCommand = Backbone.AjaxCommands.get("myCommand");

var executeCommand = function(){
  myCommand.execute(someData);
};

myCommand.on("success", function(response){
  if (response.someValueImChecking){
    // move on to the next thing, here
  } else {
    // poll again, 1 second from now
    setTimeout(executeCommand, 1000);
  }
});

There’s lot of fun little tricks you can do with a simple object wrapper like this, that would be a little more cumbersome and awkward when directly using $.ajax. 

In microcontrollers, onboard memory is a huge limiting factor. Modern devices have lots of available memory, but for embedded devices, your ROM pretty much decides how complicated your program can be.

As part of the course, we were graded on how compact our code was, rather than merely how correct it was. And this makes sense, since compactness can allow for more features/decisions etc.

So we all made reasonable efforts to compact our code using common tricks like shift-operators for multiplication and so on. However, what we didn’t know is that our professor had spent 20-30 years optimizing assembly code for compactness, and our efforts were being graded against his. Any deviation from his solution was a deduction in our grade.

After receiving poor marks, and seeing why, we all as a class reviewed the (his) solution. And wouldn’t you know that while compact, code optimized to its maximum is nearly impossible to understand or maintain. No one in the class, viewing the code for the first time, would be able to decipher what it actually did.

Long-term maintainability

Since we change code far more often than we write code, optimizing solely for performance can make it difficult or impossible to change that code in the future. In the case of our college course, we were being held to standards that were nearly impossible to reach, let alone understand. Performance isn’t an accomplishment, it’s a feature.

It’s a feature that needs to be balanced against all other constraints, like the ability to maintain the code in the future. Highly optimized code often becomes more difficult to understand or comprehend, making it difficult to tweak or refactor in the future.

So when looking at performance optimization, which is many times a necessary endeavor, always keep an eye on the true goal of the performance optimization. How much more optimized does it need to be? What is the threshold for success?

Performance optimization without a clear definition of success just leads down the path of obfuscation and unmaintainability. Optimization does have an upper limit, not only in terms of gains, but of losses in maintainability.

But what I leave out of a talk, I can certainly blog about! Suppose we have one of our enumeration classes (available here on NuGet):

public class Color : Enumeration<Color>
{
    private Color(int value, string displayName) 
        : base(value, displayName)
    {
    }

    public static readonly Color Red 
        = new Color(1, "Red");
    public static readonly Color Blue 
        = new Color(2, "Blue");
}

When it comes time to persisting this enumeration class, we want to make sure that the database schema uses the integer value as what gets persisted. When it writes, we want the value to persist, and when it reads, we want the correct enumeration value (Red/Blue) to be hydrated.

To do this in NHibernate, we’ll first need a custom type:

public class EnumerationType<T> : PrimitiveType where T : Enumeration<T>
{
    public EnumerationType()
        : base(new SqlType(DbType.Int32))
    {
    }

    public override object Get(IDataReader rs, int index)
    {
        var o = rs[index];
        var value = Convert.ToInt32(o);
        return Enumeration<T>.FromInt32(value);
    }

    public override object Get(IDataReader rs, string name)
    {
        var ordinal = rs.GetOrdinal(name);
        return Get(rs, ordinal);
    }

    public override Type ReturnedClass
    {
        get { return typeof(T); }
    }

    public override object FromStringValue(string xml)
    {
        return int.Parse(xml);
    }

    public override string Name
    {
        get { return "enumeration"; }
    }

    public override void Set(IDbCommand cmd, object value, int index)
    {
        var parameter = (IDataParameter)cmd.Parameters[index];

        var val = (Enumeration<T>)value;

        parameter.Value = val.Value;
    }

    public override string ObjectToSQLString(object value, Dialect dialect)
    {
        return value.ToString();
    }

    public override Type PrimitiveClass
    {
        get { return typeof(int); }
    }

    public override object DefaultValue
    {
        get { return 0; }
    }
}

This class is the bridge between our ORM (NHibernate) and our enumeration class. NHibernate is fantastic in its ability to provide easy ways to bridge to value objects. Value objects help avoid primitive obsession, but is only useful if you can actually use them when you’re mapping to your persistence layer.

To instruct NHibernate to use our custom types when reading/writing, the easiest way to do so is with a Fluent NHibernate convention:

public class EnumerationTypeConvention : IPropertyConvention, IPropertyConventionAcceptance
{
    private static readonly Type OpenType = typeof(EnumerationType<>);

    public void Apply(IPropertyInstance instance)
    {
        var closedType = OpenType.MakeGenericType(instance.Property.PropertyType);

        instance.CustomType(closedType);
    }

    public void Accept(IAcceptanceCriteria<IPropertyInspector> criteria)
    {
        criteria.Expect(x => IsEnumerationType(x.Property.PropertyType));
    }

    private bool IsEnumerationType(Type type)
    {
        return GetTypeHierarchy(type)
            .Where(t => t.IsGenericType)
            .Select(t => t.GetGenericTypeDefinition())
            .Any(t => t == typeof(Enumeration<>));
    }

    private IEnumerable<Type> GetTypeHierarchy(Type type)
    {
        while (type != null)
        {
            yield return type;
            type = type.BaseType;
        }
    }
}

This convention walks the type hierarchy for each property type given, and checks to see if the property type’s type hierarchy is a generic type that closes the open generic type of our enumeration class. Finally, we just need to hook our convention up to Fluent NHibernate, but that really depends on how we have Fluent NHibernate hooked up. We don’t have to use Fluent NHibernate to hook up our custom user type, but it’s much easier this way.

With NHibernate, we get the benefits of using Java-style enumeration classes, and have it seamlessly plug in to our persistence layer, which is the whole point of ORMs, right?

I’ve been working one a few new features in my side project huboard
and they are pretty awesome.

Since the start I’ve always prioritized features by what adds the most value to github issues. That means features github already provides are much lower in priority, which is why you still can’t add issues from huboard. Eventually I will add it, but github already provides that functionality or you could use other tools gem install ghi. Even more importantly huboard is open source, I would love it if someone would fork it and add those features.

So what’s new in huboard that github doesn’t provide?

Milestone ordering

Huboard provides the ability to prioritize your milestones using a more macro oriented manager pants view.

From here you can happily drag your milestones into the desired order

Issue ordering

Huboard provides the same ordering ability for issues.

Notice how issue #23 is between #31 and #35

Aggregate issues from multiple repositories

Huboard can now aggregate issues from multiple repositories into one singular overview of all your repositories

Simple as adding a label to your repo name Link <=> rauhryan/ghee

Huboard shows issues from both repositories!

Github issues just got a little more awesome!

-Ryan

Fortunately, it’s easy to build helper methods for Underscore templates (and they end up looking a lot like Rails view helpers).

Logic In Templates: A Bad Idea

On a client project recently, I had a JavaScript object that needed to be bound to my template. The object looked somewhat like this:

var data = {
  type: "something",
  name: "whatever",
  addresses: [
    {
      type: "read_address",
      address: "1/2/3",
      value: "10"
    },
    {
      type: "write_address",
      address: "1/2/4"
    }
  ]
}

I needed to take all of the “addresses” and find each specific address within the array, by name, so that I could get the right information in place at the right time in my template.

The first pass of code that I wrote to do this, looked like this:

<script id="my-template" type="text/template">
  <p>type: <%= type %></p>
  <p>name: <%= name %></p>
  <p>read address: <%= _.find(this.addresses, function(addr){ return addr.type == "read_address" }).address %> </p>
  <p>read address value: <%= _.find(this.addresses, function(addr){ return addr.type == "read_address" }).value %> </p>
  <p>write address: <%= _.find(this.addresses, function(addr){ return addr.type == "write_address" }).address %> </p>
</script>

And this worked, but it’s a bad idea. I have a lot of duplication in this template and I have a lot of logic and processing of data in the template, too. This is going to make for a very painful setup when it comes to maintenance – especially if / when I have to change how the address is looked up.

View Helper Methods: A Better Idea

In asking around on twitter for some suggestions on how to clean this up, I received several responses. Out of everything that everyone said, though, I liked the response I got from DaveTheNinja because of it’s simplicity.

The basic idea is to recognize that the data I send to my template is a JavaScript object. Since this is an object, it can have methods. If I can have methods on my object, why not put methods on it as view helper methods?

var viewHelpers = {
  getAddress: function(type){
    var address = _.find(this.addresses, function(addr) { 
      return addr.type == type 
    });
    return address;
  }
}


_.extend(data, viewHelpers);

_.template(myTemplate, data);

The helper method – “getAddress” – is pretty much the same code. But now it’s consolidated in to a single location and I’m able to give better formatting for it which makes it easier to read and understand.

You can also see that I’ve kept the data separate from the objects until just before rendering the template. I’m using Underscore’s “extend” method to copy all of the methods from my “viewHelpers” object on to my data object.

Then when I pass the data object to my template, I can call my “getAddress” method like this:

<script id="my-template" type="text/template">
  <p>type: <%= type %></p>
  <p>name: <%= name %></p>
  <p>read address: <%= getAddress("read_address").address %> </p>
  <p>read address value: <%= getAddress("read_address").value %> </p>
  <p>write address: <%= getAddress("write_address").address %> </p>
</script>

And we’re done! I now have view helper methods that I can call from within my templates.

Using This With Backbone

I use this technique with Backbone a lot. The code that I showed above is really no different than what I do with my Backbone views, either. When you get to the point where you need to render your template, just extend the view helper methods on to your data before doing the actual rendering:

Backbone.View.extend({
  template: "#my-template",

  render: function(){

    var data = this.model.toJSON();
    _.extend(data, viewHelpers);

    var html = _.template($(this.template), data);
    this.$el.html(html);

  }
});

Using This With Backbone.Marionette

I’ve added this functionality in to Backbone.Marionette as well. ItemView, CompositeView and Layout will all look for a `templateHelpers` attribute on a view definition. If it finds it, it will mix that object in to the data that is used to render the template: 

Backbone.Marionette.ItemView.extend({

  template: "#my-template",
  templateHelpers: viewHelpers

});

You can specify a reference to the viewHelpers object as shown in this example, provide an object literal as the templateHelpers directly, or specify a function that returns an object with the helper methods that you want. For more information see the documentation for Marionette.

Other Template Engines

This basic technique will probably work with other template engines, too. Some engines like Handlebars, though, have this idea baked in to them directly. But if you’re using Underscore’s templates, then this is a good way to keep your templates clean while still providing the logic you need.

If I run “npm install express” from within a folder, the “express” package will be installed in to my ./node_modules folder.

But I can’t say “express foo” on the command line at this point, to run express. And I can’t say “npm express foo” or “npm exec express foo” or anything like that. This ability is sadly missing from NPM. There are a few ways to get around this, though.

Global Modules

When you install a Node module with the `-g` option, it installs in to the global module list. Global modules can have their bin files run from the command line just like any other command. So if you install the “express” module, for example, with the global flag then you’ll be able to say “express foo” from the command line and watch it build a fresh new project for you in the “foo” folder.

This is nice for packages that you want to have available for any application you’re building. I use global packages a lot because some of the tools that you can find in node packages are quite useful, even outside the context of a node project. But not every package should be installed in the global package repository for your computer.

Run Bin From Relative Path

You can also run bin files from node modules by using the relative path of ./node_modules/.bin/ to find the command.

This is a bit tedious, though it is functional. I’ve build a few simple command / shell scripts to execute some of my installed modules this way, for some of my projects. That makes it a bit easier overall, but you have to set up a shell script for each package you want.

Run Bin From Generic Shell Script

Since all of the bin files for all of the node packages are installed in to ./node_modules/.bin/ for a given project, why not build a generic “npm_exec” shell script and just forward all the parameters?

Easy enough:

./node_modules/.bin/$@

Just “chmod +x npm_exec” to make this file executable, and away we go.

Now I can run any arbitrary package binary I want. I could even put this little shell script in my /usr/local/bin folder and it would be available for all of my node projects, anywhere on my box.

This is a nice little solution, even if it’s a work around for something that should be built in to npm.

NPM Scripts In package.json

This last option is one that I’m using more and more often for project specific, recurring needs.

When you create an express app, it builds a package.json file for you. One of the pieces that it sticks in there is the “scripts” setting which contains a “start” setting, by default.

{
  "name": "application-name",
  "version": "0.0.1",
  "private": true,
  "scripts": {
    "start": "start app"
  },
  "dependencies": {
    "express": "3.0.0alpha1",
    "jade": "*"
  }
}

It turns out you can use these “scripts” from the npm command line. When you call “npm start”, npm will execute the “scripts”/”start” configuration for you. By default, this is just a call to “node app” which runs the app.js file in node and gets your express.js app up and running.

You can do more with “scripts”, too. You can add your own named script, in fact.

{
  ...

  "scripts": {
    "start": "node app",
    "foo": "node -e 'console.log(1+2)'"
  }

  ...
}

But you can’t just “npm foo”. The “start” script is recognized by npm explicitly. For other non-standard script names, you have to use the “run-script” command from node: npm run-script foo

The other thing that this does for us, is give us direct access to all of the bin files that our node packages have installed. So within a “script” configuration, we can call any arbitrary package’s bin file.

For example, if I want to use the node-supervisor package to restart my app whenever any files change, I can set up my package.json file to look like this:

{
  "name": "application-name",
  "version": "0.0.1",
  "private": true,
  "scripts": {
    "start": "supervisor app"
  },
  "dependencies": {
    "express": "3.0.0alpha1",
    "jade": "*"
  },
  "devDependencies": {
    "supervisor": "*"
  }
}

This will install the “supervisor” package for development only, and set up the “start” script to run “supervisor app”. Now from the command line, I can’t run “supervisor app” directly:

But I can run “node start” and node will pick up the ./node_modules/.bin/ folder for me, allowing supervisor to be executed:

This works well for recurring / repetitive tasks within a project. But if you want ad-hoc package commands, you’re going to be in for a little more work and will likely have to fall back to one of the other solutions I’ve mentioned.

Other Options?

I really do miss the “bundle exec” feature of bundler. I honestly don’t know why npm doesn’t have an equivalent built in to it. Maybe it just needs someone to come along and contribute this feature. Maybe this feature was rejected. I don’t know. I haven’t looked in to it. But I wanted to get something in place now, so that I don’t have to install all of my project specific packages in the global package list.

There might be better option than the ones I’ve listed, as well. So, what am I missing? Is there something built in to npm to make this easier? Are there other ways that you’ve worked around this? Or am I going to stick with my “npm_exec” script and using npm “scripts” in my package.json fil?

So a couple weeks ago I finally decided to learn how to use bash functions. I knew they existed but I decided to ignore them for the longest time.

Often times you find yourself typing the same things over and over again into the shell. In our app we deploy 3 windows services and managing them can get really tedious.

~/lecode>sc query DovetailEmail-default
~/lecode>sc stop DovetailEmail-default
~/lecode>sc delete DovetailEmail-default

~/lecode>sc query DovetailRulesEngine-default
~/lecode>sc stop DovetailRulesEngine-default
~/lecode>sc delete DovetailRulesEngine-default

~/lecode>sc query DovetailMessaging-default
~/lecode>sc stop DovetailMessaging-default
~/lecode>sc delete DovetailMessaging-default

That’s a lot of typing, granted its not that bad when you use your bash history. But you end up hitting the up arrow and changing one word a lot.

Functions!

So when you keep repeating yourself over and over again you can quickly write a function that can save you precious keystrokes

~/lecode>function fsc() {
for name in Email RulesEngine Messaging
do
sc $1 Dovetail$name-$2
done
}


Now I can happily type
~/lecode>fsc query default
~/lecode>fsc stop default
~/lecode>fsc start default

It works for other repetitive tasks as well, ie the steps to deploy our app is as follows

~/lecode>rm -rf mydefault
~/lecode>bottles create-all
~/lecode>bottles bundle mydefault -profile default
~/lecode>mydefault/BottleRunner.exe deploy -profile default

Again… pretty easy to just use my bash history and hit the up arrow to run all the commands
but its really easy to make a function

~/lecode>function fdeploy() {
rm -rf my$1
bottles create-all
bottles bundle my$1 -profile $1
my$1/BottleRunner.exe deploy -profile $1
}


Then bam!

~/lecode>fdeploy default
~/lecode>fdeploy storyteller
~/lecode>fdeploy hrdemo

See thats way mo ‘betta than creating a .bat file cause then you have run in cmd.exe, you have to ignore it in git repository, clean up after yourself later….

And I just don’t like that, not one bit.

-Ryan

What tool do you use to refresh your browser when you change a file in your editor?

It’s LiveReload, and I’ve put together a 10 minute introduction that shows how to get up and running with the GUI application and the Guard plugin, how to use it to compile your assets such as SASS or CoffeeScript, and more.

Personally, I can’t live without this tool anymore. It takes the “refresh” button out of my development effort and greatly simplifies my workflow.

Be sure to checkout my other screencasts (paid and free) at WatchMeCode.net as well.