longchamp
tory burch outlet
tory burch outlet
ray ban australia
Babyliss
nike air max
Michael Kors outlet
toms outlet
nike air max
louis vuitton outlet
nike air max
coach outlet
nike air max
ray ban uk
oakley sunglasses
Michael Kors outlet
Aspiring Craftsman

Skills Cloud Résumé

On March 30, 2012, in Uncategorized, by derekgreer

 

For some time I’ve presented a list of technical skills on the front page of my CV/résumé.  I’ve had some varied experience which I believe is valuable to present to prospective employers as a way of reflecting versatility and exposure to different paradigms, but listing everything tends to solicit undesired offers when my résumé makes it into the wild.  For instance, I’m not really interested in ever working in C/C++ or Java ever again, but I don’t want to remove it from my résumé either.  Another issue I’ve had is determining how to highlight which skills best reflect who I am today out of everything I have listed.  What I’ve typically done is break things down into categories of languages, platforms, application types, DI containers, ORM frameworks, etc. with the most recent experience at the front of the list.  While this provides a way of showing what I’ve done most recently, it didn’t provide a way to express how well I felt I knew a particular technology.

After thinking about this recently, I decided to try out something new for awhile.  Rather than just showing a list of categorized skills, why not express them as a tag cloud?  This allows  more emphasis to be placed on those technologies someone feels best represents who they are today while also including things they’ve done in the past or things they may only have moderate exposure to.

 

Here’s what the first page of my résumé looks like now:

 

SkillCloudResume

 

 

Thoughts?

Tagged with:  

RabbitMQ for Windows: Exchange Types

On March 29, 2012, in Uncategorized, by derekgreer

This is the fourth installment to the series: RabbitMQ for Windows.  In the last installment, we reviewed our Hello World example and introduced the concept of Exchanges.  In this installment, we’ll discuss the four basic types of RabbitMQ exchanges.

Exchange Types

Exchanges control the routing of messages to queues.  Each exchange type defines a specific routing algorithm which the server uses to determine which bound queues a published message should be routed to.

RabbitMQ provides four types of exchanges: Direct, Fanout, Topic, and Headers.

Direct Exchanges

The Direct exchange type routes messages with a routing key equal to the routing key declared by the binding queue.  The following illustrates how the direct exchange type works:

  DirectExchange_thumb37

 

The Direct exchange type is useful when you would like to distinguish messages published to the same exchange using a simple string identifier.  This is the type of exchange that was used in our Hello World example.  As discussed in part 3 of our series, every queue is automatically bound to a default exchange using a routing key equal to the queue name.  This default exchange is declared as a Direct exchange.  In our example, the queue named “hello-world-queue” was bound to the default exchange with a routing key of “hello-world-queue”, so publishing a message to the default exchange (identified with an empty string) routed the message to the queue named “hello-world-queue”.

Fanout Exchanges

The Fanout exchange type routes messages to all bound queues indiscriminately.  If a routing key is provided, it will simply be ignored.  The following illustrates how the fanout exchange type works:

 

FanoutExchange_thumb[2]

 

The Fanout exchange type is useful for facilitating the publish-subscribe pattern.  When using the fanout exchange type, different queues can be declared to handle messages in different ways.  For instance, a message indicating a customer order has been placed might be received by one queue whose consumers fulfill the order, another whose consumers update a read-only history of orders, and yet another whose consumers record the order for reporting purposes.

Topic Exchanges

The Topic exchange type routes messages to queues whose routing key matches all, or a portion of a routing key.  With topic exchanges, messages are published with routing keys containing a series of words separated by a dot (e.g. “word1.word2.word3”).  Queues binding to a topic exchange supply a matching pattern for the server to use when routing the message.  Patterns may contain an asterisk (“*”) to match a word in a specific position of the routing key, or a hash (“#”) to match zero or more words.  For example, a message published with a routing key of “honda.civic.navy” would match queues bound with “honda.civic.navy”, “*.civic.*”, “honda.#”, or “#”, but would not match “honda.accord.navy”, “honda.accord.silver”, “*.accord.*”, or “ford.#”.  The following illustrates how the fanout exchange type works:

 

TopicExchange_thumb[2]

 

The Topic exchange type is useful for directing messages based on multiple categories (e.g. product type and shipping preference ), or for routing messages originating from multiple sources (e.g. logs containing an application name and severity level).

Headers Exchanges

The Headers exchange type routes messages based upon a matching of message headers to the expected headers specified by the binding queue.  The headers exchange type is similar to the topic exchange type in that more than one criteria can be specified as a filter, but the headers exchange differs in that its criteria is expressed in the message headers as opposed to the routing key, may occur in any order, and may be specified as matching any or all of the specified headers.  The following illustrates how the headers exchange type works:

 

HeadersExchange_thumb[2]

 

The Headers exchange type is useful for directing messages which may contain a subset of known criteria where the order is not established and provides a more convenient way of matching based upon the use of complex types as the matching criteria (i.e. a serialized object).

Conclusion

That wraps up our introduction to each of the exchange types.  Next time, we’ll walk through an example which demonstrates declaring a direct exchange explicitly and take a look at the the push API.

Tagged with:  

RabbitMQ for Windows: Hello World Review

On March 18, 2012, in Uncategorized, by derekgreer

This is the third installment to the series: RabbitMQ for Windows.  In the last installment, we discussed some basic messaging concepts and created our first RabbitMQ application.  In this installment, we’ll be taking a closer look at our Hello World application to help round out our understanding of the basic concepts involved.

Hello World Review

In the previous installment, we walked through creating a Hello World example.  Let’s review the Producer and Consumer code again:

Producer

class Program
{
  static void Main(string[] args)
  {
    var connectionFactory = new ConnectionFactory();
    IConnection connection = connectionFactory.CreateConnection();
    IModel channel = connection.CreateModel();
    channel.QueueDeclare("hello-world-queue", false, false, false, null);
    byte[] message = Encoding.UTF8.GetBytes("Hello, World!");
    channel.BasicPublish(string.Empty, "hello-world-queue", null, message);
    Console.WriteLine("Press any key to exit");
    Console.ReadKey();
    channel.Close();
    connection.Close();
  }
}

Consumer

class Program
{
  static void Main(string[] args)
  {
    var connectionFactory = new ConnectionFactory();
    IConnection connection = connectionFactory.CreateConnection();
    IModel channel = connection.CreateModel();
    channel.QueueDeclare("hello-world-queue", false, false, false, null);
    BasicGetResult result = channel.BasicGet("hello-world-queue", true);
    if (result != null)
    {
      string message = Encoding.UTF8.GetString(result.Body);
      Console.WriteLine(message);
    }
    Console.WriteLine("Press any key to exit");
    Console.ReadKey();
    channel.Close();
    connection.Close();
  }
}

In both the Producer and Consumer projects, we started our Main() method by establishing a Connection to the RabbitMQ server.  We then created a Channel to establish a line of communication with the server and declared a Queue to send and receive our messages.  In our Producer, we called BasicPublish() to place a message on the queue.  In our Consumer, we called BasicGet() to retrieve a message from the queue and print the message to the console.  In both the Producer and Consumer projects, we ended the Main() method by closing the channel and connection to the server.

Establishing the Connection

Let’s first discuss how our example connects to the RabbitMQ server.  In our example, we’re establishing a connection using the default connection settings.

var connectionFactory = new ConnectionFactory();

This assumes we have a RabbitMQ server running on our local development machine.  To connect to this instance, the ConnectionFactory uses a default host name of “localhost” and a default port of 5672.  A user name and password must also be provided to connect to the server.  When not specified, the ConnectionFactory uses a default user name and password of “guest”.  The “guest” user was pre-configured with full administrator rights when we first installed our  instance of RabbitMQ.  The final parameter of interest is the Virtual Host.  RabbitMQ utilizes virtual hosts (i.e. virtual instances of RabbitMQ) to allow multiple projects or teams to manage and secure their own set of queues from within a single RabbitMQ installation. 

When we first installed RabbitMQ, a default virtual host named “/” was created.  The ConnectionFactory uses this virtual host when one is not specified.

Specified explicitly, we might have configured these default values as follows:

var connectionFactory = new ConnectionFactory
                          {
                            HostName = "localhost",
                            Port = 5672,
                            UserName = "guest",
                            Password = "guest",
                            VirtualHost = "/"
                          };
IConnection connection = connectionFactory.CreateConnection();

RabbitMQ also supports the AMQP URI Specification which allows these parameters to be specified as a single URI.  Using the URI option, we need to percent-encode the virtual host as “%2f”.  The following is how me might have established our connection using the amqp URI:

var connectionFactory = new ConnectionFactory {Uri = "amqp://guest:guest@localhost:5672/%2f"};
IConnection connection = connectionFactory.CreateConnection();

Creating a Channel

After establishing a connection with the server, the next step we take in both the Producer and Consumer projects is to create a Channel.

IModel channel = connection.CreateModel();

A channel is a light-weight connection used by RabbitMQ to enable multiple communication sessions through a single TCP/IP connection.  Operating systems have a limit to the number of TCP/IP connections that can be opened simultaneously, and creating these connections can be relatively expensive.  Through the use of channels, we are free to create as many virtual connections with the server as we want without incurring this overhead or being limited by the number of available TCP/IP connections.

Channels are intended to be used for sequencing communication with the server such as declaring queues or the sending and receiving of messages.  A single channels should not be used by multiple threads simultaneously. For this reason, it is recommended that channels simply not be shared across threads.

Declaring the Queue

After opening a channel within our connection, the next step we take is to declare a Queue. 

channel.QueueDeclare("hello-world-queue", false, false, false, null);

A queue can be thought of as a sort of “mailbox”.  Messages put in the mailbox sit there until a recipient retrieves the mail.

In our example, we named our queue “hello-world-queue”.  The queue name (along with the RabbitMQ host name and port number) serves as a sort of “mailbox address”.  When we publish the encoded string “Hello, World!”, it is placed in the queue named “hello-world-queue’ and awaits until a consumer retrieves and acknowledges the message.

Before discussing the parameters used in our call to QueueDeclare, it will be helpful to take a short detour and discuss how our message actually gets routed from the Producer to the Consumer.

Message Routing

When looking at our example, it appears as though the Producer sends our message directly to the “hello-world-queue”.  What actually occurs, however, is that the message is routed to the “hello-world-queue” through an Exchange.

When using RabbitMQ, messages aren’t actually published to a queue, but rather are published to an exchange which then routes messages to queues.  An exchange can be thought as a “post office”.  Just as we don’t generally put mail directly in a recipient’s mailbox, in RabbitMQ we don’t publish messages directly to a queue.

To receive messages, a queue must first have an exchange binding established.  Part of establishing the binding includes specifying which messages should be routed to the queue.  In most cases, this is achieved by specifying a routing key which serves as a filter for which messages are delivered to which queues.

The following diagram depicts how messages are published in RabbitMQ:

The reason our code looks like it sends messages directly to the queue is due to the fact that we’re taking advantage of a convenience provided by the RabbitMQ server.  Whenever a queue is declared, it is automatically bound to a default exchange with a routing key equal to the queue name.  Messages published to the default exchange with a routing key equal to the value of a declared queue name are routed to the associated queue.

In addition to being implicitly bound to all queues, the default exchange also cannot be unbound, deleted, or explicitly declared through code.  The only operation that is allowed is the publishing of messages.

Queue Parameters

Returning to our discussion of queue declaration, the parameters used in our call to QueueDeclare() creates our queue as a non-durable, non-exclusive, non-auto-deleted queue. 

The durability flag pertains to what happens to our queue if the server is restarted.  Queues marked as durable will be recreated upon a server restart, while non-durable queues will not be.

The exclusive flag pertains to whether a queue can be declared by more than one channel.  Since messages are actually published to exchanges, not queues, there may be cases where you only want a single client instance to be capable of declaring a queue bound to a particular exchange (for example, when using queues to facilitate an RPC call). 

Lastly, the auto-delete flag pertains to whether the queue is automatically deleted once all consumers are removed.  This flag can be a little misleading since we might suppose setting this to true would cause our “hello-world-queue” to be automatically deleted after our application exists.  In fact, it wouldn’t be.

There are two different approaches to receiving messages: pulling and pushing.  With the pull API, messages are retrieved on demand through a call to BasicGet().  This is the method used in our example.  With the pull API, available messages are delivered to a local queue when a Consumer is bound to the channel.  When setting the auto-delete flag to true, a queue will be deleted once it detects that all consumers have been removed.  While we named the project which receives messages from our queue “Consumer”, the pull API doesn’t actually declare a consumer to retrieve messages.  Therefore, the server is never alerted to the fact that the queue is no longer being used.

Publishing the Message

The last noteworthy point in our Producer project is the parameters to our call to BasicPublish().

channel.BasicPublish(string.Empty, "hello-world-queue", null, message);

The first parameter is the name of the exchange to publish the message to.  An empty string is the designation for the default exchange discussed earlier in the section on message routing.  The second parameter is the routing key.  As previously discussed, all queues are bound to the default exchange using a routing key equal to the value of the bound queue name.  The third parameter is an instance of IBasicProperties.  This class is used to associate a number of properties with the message, such as the message encoding, content-type, and durability.  We’ll take a look at some of the uses of this class further in our series.  Lastly, the fourth parameter is the byte array representing the message body.

Getting the Message

The last noteworthy point in our Consumer project is the parameters to our call to BasicGet().

BasicGetResult result = channel.BasicGet("hello-world-queue", true);

The first parameter is the queue to pull a message from which should be self-explanatory.  The second parameter is a flag which controls the auto-acknowledgement of the message. 

When a message is retrieved from a queue with an auto-acknowledge flag set to false, the server holds the message in an unacknowledged state until an acknowledgement or rejection of the message is received on the open channel (note that messages must be accepted or rejected on the same channel they were received on).  This is useful when a consumer needs to ensure the message is processed successfully before it’s fully removed from the server.  If the channel is closed without receiving an acknowledgment, the message will be requeued and delivered to the next consumer (using pull or get).  In the event that a consumer determines it can’t process the message, it can reject the message with a flag indicating whether to requeue the message or not.

Conclusion

That’s it for our Hello World example review.  Next time, we’ll take a look at the four basic exchange types.

 

Today I stumbled upon Scott Haselman’s post: How to access NuGet when NuGet.org is down (or you’re on a plane) in which Scott discusses how he recovered from an issue with the nuget.org site being down during his demo at the Dallas Day of .Net.   As it turns out, while NuGet stores packages it downloads in a local Cache folder within your AppData folder, it doesn’t actually use this cache by default.  Scott was able to remedy the situation by adding his local cache as a source through the the Visual Studio Package Manager plugin.

Last year, I wrote about my philosophy for dependency management and  how I use NuGet to facilitate dependency management without using the Visual Studio plugin wherein I discuss using the NuGet.exe command line tool to manage .Net dependencies as part of my rake build.  After reading Scott’s post, I got to wondering whether the NuGet.exe command line tool also had the same caching issue and after a bit of testing I discovered that it does.  Since I, with the help of a former colleague, Josh Bush, have evolved the solution I wrote about previously a bit, I thought I’d provide an update to my approach which includes the caching fix.

As discussed in my previous article, I maintain a packages.rb file which serves as a central manifest of all the dependencies used project wide.  Here’s one from a recent project:

packages = [
[ "Machine.Specifications", "0.5.3.0" ],
[ "ExpectedObjects", "1.0.0.2" ],
[ "Moq", "4.0.10827" ],
[ "RabbitMQ.Client", "2.7.1" ],
[ "log4net", "1.2.11" ]
]

configatron.packages = packages

 

This is sourced by a rakefile which which is used by a task which installs any packages not already installed.

The basic template I use for my rakefile is as follows:

require 'rubygems'
require 'configatron'
 
...

NUGET_CACHE= File.join(ENV['LOCALAPPDATA'], '/NuGet/Cache/') 
FEEDS = ["http://[corporate NuGet Server]:8000", "https://go.microsoft.com/fwlink/?LinkID=206669" ]
require './packages.rb'
 
task :default => ["build:all"]
 
namespace :build do
 
  task :all => [:clean, :dependencies, :compile, :specs, :package] 

  ...

  task :dependencies do
    feeds = FEEDS.map {|x|"-Source " + x }.join(' ')
    configatron.packages.each do | name,version |
      feeds = "-Source #{NUGET_CACHE} " + feeds unless !version
        packageExists = File.directory?("#{LIB_PATH}/#{name}")
        versionInfo="#{LIB_PATH}/#{name}/version.info"
        currentVersion=IO.read(versionInfo) if File.exists?(versionInfo)
        if(!packageExists or !version or !versionInfo or currentVersion != version) then
          versionArg = "-Version #{version}" unless !version
          sh "nuget Install #{name} #{versionArg} -o #{LIB_PATH} #{feeds} -ExcludeVersion" do | ok, results |
            File.open(versionInfo, 'w') {|f| f.write(version) } unless !ok
        end
      end
    end
  end
end

 

This version defines a NUGET_CACHE variable which points to the local cache.  In the dependencies task, I join all the feeds into a list of Sources for NuGet to check.  I leave out the NUGET_CACHE until I know whether or not a particular package specifies a version number. Otherwise, NuGet would simply check for the latest version which exists within the local cache.

To avoid having to change Visual Studio project references every time I update to a later version of a dependency, I use the –ExcludeVersion option.  This means I can’t rely upon the folder name to determine whether the latest version is already installed, so I’ve introduced a version.info file.  I imagine this is quite a bit faster than allowing NuGet to determine whether the latest version is installed, but I actually do this for a different reason.  If you tell NuGet to install a package into a folder without including the version number as part of the folder and you already have the specified version, it uninstalls and reinstalls the package.  Without checking the presence of the correct version beforehand, NuGet would simply reinstall everything every time.

Granted, this rake task is far nastier than it needs to be.  It should really only have to be this:

  task :dependencies do
    nuget.exe install depedencyManifest.txt –o lib
  end

 

Where the dependencyManifest file might look a little more like this:

Machine.Specifications 0.5.3.0
ExpectedObjects 1.0.0.2
Moq 4.0.10827
RabbitMQ.Client 2.7.1
log4net 1.2.11

 

Nevertheless, I’ve been able to coerce the tool into doing what I want for the most part and it all works swimmingly once you get it set up.

Tagged with:  

This is the second installment to the RabbitMQ for Windows series.  In our first installment, we walked through getting RabbitMQ installed on a Microsoft Windows machine. In this installment, we’ll discuss a few high-level concepts and walk through creating our first RabbitMQ application.

Basic Concepts

To being, let’s discuss a few basic concepts. Each of the examples we’ll be working through will have two roles represented: a Producer and a Consumer. A Producer sends messages and a Consumer receives messages.

Messages are basically any blob of bytes you’d like to send. This could be a simple ASCII string, JavaScript Object Notation (JSON), or a binary-serialized object.

Messages are sent to Queues.  A Queue is a First-In-First-Out (FIFO) data structure. You can think of a queue as a sort of pipe where you put messages in one side of the pipe and the messages arrive at the other end of the pipe. 

The following diagram depicts these concepts:

 

ProducerQueueConsumer_thumb5

 

We’ll introduce other concepts further into the series, but that’s the basics. Let’s move on to creating our first example.

Hello, World!

Our first application will be an obligatory “Hello World” example.  We’ll create a Publisher application which sends the string “Hello, World!” to a RabbitMQ queue and a Consumer application which receives the message from the queue and displays it to the console.

For all of our examples, we’ll be using the official RabbitMQ .Net client available here.  This library is also available via NuGet, so if you have the NuGet Package Manager installed you can retrieve it through the “Tools->Library Package Manager” menu item, or if you have the NuGet.exe command line utility then you can issue the following command in the directory you’d like it installed to:

nuget install RabbitMQ.Client

 

Create the Producer

To start, let’s create a new empty solution named HelloWorldExample (File->New->Project->Other Project Types->Visual Studio Solutions->Blank Solution). Once you have that created, add a new project of type “Console Application” to the solution and name it “Producer”.

Next, add a reference to the RabbitMQ.Client.dll assembly.

The first thing we’ll need to do for our producer is to establish a connection to the RabbitMQ server using a ConnectionFactory:

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

 

The ConnectionFactory has a number of properties that can be set for our connection. In this example, we’re establishing a connection using the default connection settings which assumes you have the RabbitMQ Windows service running on your local development machine. If you’ve installed it on a different machine then you’ll need to set the Host property of the connectionFactory instance to the DNS name where you’ve installed RabbitMQ.

Next, we need to create a Channel:

IModel channel = connection.CreateModel();

 

A channel is a light-weight connection which RabbitMQ uses to enable multiple threads of communication over a single TCP/IP socket. Note that the actual type created is RabbitMQ.Client.IModel. In most RabbitMQ client libraries the term channel is used, but for some reason the authors of the .Net client library chose to use the term “Model”. Descriptive, eh? We’ll use the instance name of “channel” to be more descriptive.

Next, we need to create a queue:

channel.QueueDeclare(“hello-world-queue”, false, false, false, null);

 

This creates a queue on the server named “hello-world-queue” which is non-durable (won’t survive a server restart), is non- exclusive (other channels can connect to the same queue), and is not auto-deleted once it’s no longer being used.  We’ll discuss these parameters in more detail further in our series.

Next, we’ll declare a byte array containing a UTF8-encoded array of bytes from the string “Hello, World!” and use the BasicPublish() method to publish the message to the queue:

byte[] message = Encoding.UTF8.GetBytes("Hello, World!");
channel.BasicPublish(string.Empty, “hello-world-queue”, null, message);

 

Again, don’t worry about understanding the parameters just yet. We’ll get to that soon enough.

Finally, we’ll prompt the user to press a key to exit the application and close our channel and connection:

Console.WriteLine("Press any key to exit");
Console.ReadKey();
channel.Close();
connection.Close();

 

Here’s the full Producer listing:

using System.Text;
using RabbitMQ.Client;

namespace Producer
{
  class Program
  {
    static void Main(string[] args)
    {
      var connectionFactory = new ConnectionFactory();
      IConnection connection = connectionFactory.CreateConnection();
      IModel channel = connection.CreateModel();
      channel.QueueDeclare("hello-world-queue", false, false, false, null);
      byte[] message = Encoding.UTF8.GetBytes("Hello, World!");
      channel.BasicPublish(string.Empty, "hello-world-queue", null, message);
      Console.WriteLine("Press any key to exit");
      Console.ReadKey();
      channel.Close();
      connection.Close();
    }
  }
}

 

Create the Consumer

Next, let’s create our Consumer application. Add a new Console Application to the solution named “Consumer” and add a reference to the RabbitMQ.Client assembly. We’ll start our consumer with the same connection, channel, and queue declarations:

var connectionFactory = new ConnectionFactory();
IConnection connection = connectionFactory.CreateConnection();
IModel channel = connection.CreateModel();
channel.QueueDeclare("hello-world-queue", false, false, false, null);

 

Next, we’ll use the BasicGet() method to consume the message from the queue “hello-world-queue”:

BasicGetResult result = channel.BasicGet("hello-world-queue", true);

 

Next, we’ll check to ensure we received a result. If so, we’ll convert the byte array contained within the Body property to a string and display it to the console:

if (result != null)
{
  string message = Encoding.UTF8.GetString(result.Body);
  Console.WriteLine(message);
}

 

Lastly, we’ll prompt the user to press a key to exit the application and close our channel and connection:

Console.WriteLine("Press any key to exit");
Console.ReadKey();
channel.Close();
connection.Close();

 

Here’s the full Consumer listing:

using System;
using System.Text;
using RabbitMQ.Client;

namespace Consumer
{
  class Program
  {
    static void Main(string[] args)
    {
      var connectionFactory = new ConnectionFactory();
      IConnection connection = connectionFactory.CreateConnection();
      IModel channel = connection.CreateModel();
      channel.QueueDeclare("hello-world-queue", false, false, false, null);
      BasicGetResult result = channel.BasicGet("hello-world-queue", true);
      if (result != null)
      {
        string message = Encoding.UTF8.GetString(result.Body);
        Console.WriteLine(message);
      }
      Console.WriteLine("Press any key to exit");
      Console.ReadKey();
      channel.Close();
      connection.Close();
    }
  }
}

 

To see the application in action, start the Publisher application first and then start the Consumer application. If all goes well, you should see the Consumer application print the following:

Hello, World!
Press any key to exit

 

Congratulations! You’ve just completed your first RabbitMQ application.  Next time, we’ll take a closer look at the concepts used within our Hello World example.

						
Tagged with:  

RabbitMQ for Windows: Introduction

On March 5, 2012, in Uncategorized, by derekgreer

If you’re interested in getting started with distributed programming and you develop on the Microsoft Windows platform, RabbitMQ may be what you’re looking for.  RabbitMQ is an open source, standards-based, multi-platform message broker with client libraries available for a host of development platforms including .Net.  

This series will provide a gentle introduction to getting started with RabbitMQ for .Net developers, including a Windows environment installation guide along with an introduction to basic concepts and features through the use of examples in C#.  In this first installment, we’ll cover installation and basic configuration.

Installation

The first thing to know about RabbitMQ installation is that RabbitMQ runs on the Erlang virtual runtime.  “What is Erlang”, you ask, and “Why should I ask our admins to install yet another runtime engine on our servers”?  Erlang is a functional language which places a large emphasis on concurrency and high reliability.  Developed by  Joe Armstrong, Mike Williams, and Robert Virding to support telephony applications at Ericsson, Erlang’s flagship product, the Ericsson AXD301 switch, is purported to have achieved a reliability of nine "9"s.

A popular quote among Erlang adherents is Verding’s “First Rule of Programming”:

“Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang.” – Robert Verding

Sound like the perfect platform to write a message broker in?  The authors of RabbitMQ thought so too.

With that, let’s get started with the installation.

 

Step 1: Install Erlang

The first step will be to download and install Erlang for Windows.  You can obtain the latest installer from here (version R15B at the time of this writing) .

After downloading and completing the Erlang installation wizard, you should have a new ERLANG_HOME environment variable set.  If not, you’ll want to set this now so RabbitMQ will be able to locate your installation of Erlang.

ErlangEnv

 

 

Step 2: Install RabbitMQ

Next, download and install the latest version of RabbitMQ for Windows from here (version 2.7.1 at the time of this writing).

 

Step 3: Install the RabbitMQ Management Plugin

By default, the RabbitMQ Windows installer registers RabbitMQ as a Windows service, so technically we’re all ready to go.  In addition to the command line utilities provided for managing and monitoring our RabbitMQ instance, a Web-based management plugin is also provided with the standard Windows distribution.  The following steps detail how to get the management plugin up and going.

First, from an elevated command prompt, change directory to the sbin folder within the RabbitMQ Server installation directory (e.g. %PROGRAMFILES%\RabbitMQ Server\rabbitmq_server_2.7.1\sbin\).

Next, run the following command to enable the rabbitmq management plugin:

rabbitmq-plugins.bat enable rabbitmq_management 

 

Lastly, to enable the management plugin we need to reinstall the RabbitMQ service.  Execute the following sequence of commands to reinstall the service:

 
rabbitmq-service.bat stop 
rabbitmq-service.bat install 
rabbitmq-service.bat start 

 

To verify management plugin is up and running, start your favorite browser and navigate to http://localhost:55672/mgmt/.  If everything went ok, you should see a screen similar to the following:

 

 RabbitManagement

From here, you’ll be able to configure and monitor your RabbitMQ instance.

That concludes our installation guide.  Next time, we’ll walk through writing our first RabbitMQ C# application.

Tagged with:  

TDD Best Practices: Write Assertions First

On March 5, 2012, in Uncategorized, by derekgreer

When practicing Test-Driven Development, developers often organize their tests following a style first described by Bill Wake as Arrange, Act, Assert.  This division between the setup, the exercising the System Under Test, and the assertions are also reflected in the Context/Specification and Given/When/Then (GWT) styles of Behavior-Driven Development (with the GWT style often containing multiple “Act” steps).  This division is generally a Good Thing, as it guides the developer toward the authoring of well-organized and readable tests which provide a good template for modeling most specifications.  Unfortunately, developers are often lead to implement tests in the order of Arrange, Act, Assert which serves to undermine the purpose of practicing TDD: to allow the needs of the test to guide the design of the system.

When transforming a requirement into an executable specification, after establishing the logical class or object which will contain the test implementation, the first step should be to determine how the specification (i.e. the test) is to be validated.  That is to say, the first step is to write an assertion.

The goal of Test-Driven Development is to produce clean code that works.  By ‘clean’, we mean code that’s free of unnecessary behavior or abstractions.  The TDD techniques of first doing the simplest thing that could possibly work, refactoring to remove duplication, and using triangulation for identifying the need for generalizations are set forth to restrain developers from writing code that isn’t actually needed.  This leads to simpler, more maintainable code.  Starting with the setup implementation before determining how you’re going to verify the desired outcome is putting the cart before the horse.  How do you know a particular setup implementation will be needed to test the desired outcome before you’ve established what that is?  Perhaps you’ll be building upon the existing type you’re jumping ahead to setup, but perhaps it should be a new type altogether.  Figure out how you’re going to verify the desired outcome first and then determine what components make sense to fulfill the desired outcome.

To help illustrate this flow, let’s consider the following example.  Let’s say we’re writing an application which allows employee’s at a company to register for a training class.  When an employee registers for a class, they should be provided with a registration receipt.  Let’s start by establishing the shell of our specification:

public class when_registering_for_a_class
{
  Establish context;

  Because of;

  It should_return_a_registration_receipt;
}

Next, we need to determine how we want to verify that the logical condition “It should return a registration receipt” will be fulfilled.  Let’s assert that a variable named _registrationReceipt is not null:

public class when_registering_for_a_class
{
  Establish context;

  Because of;

  It should_return_a_registration_receipt = () => _registrationReceipt.ShouldNotBeNull();
}

It’s at this point some may have an objection to typing out an assertion without the aid of auto-completion (i.e. Intellisense).  Some are so dependent upon auto-completion that they’ll actually stop after typing _registrationReceipt, and go declare a variable just so their auto-completion will be there.  Resist that urge.  Assertions shouldn’t be difficult and this will actually force you to keep it simple.

Next, we need to decide how we are going to assign our variable, so we’ll move to our Because delegate.  At this point, we’ll also determine what component and usage API we’d like to use to retrieve our receipt:

public class when_registering_for_a_class
{
  Establish context;

  Because of = () => _registrationReceipt = _registrar.Register(EmployeeId, ClassId);

  It should_return_a_registration_receipt = () => _registrationReceipt.ShouldNotBeNull();
}

Next, we need to establish our context.  We’ll initialize the _registrar to a non-existent type named Registrar:

public class when_registering_for_a_class
{
  Establish context = () => { _registrar = new Registrar(); };

  Because of = () => _registrationReceipt = _registrar.Register(EmployeeId, ClassId);

  It should_return_a_registration_receipt = () => _registrationReceipt.ShouldNotBeNull();
}

At this point, we can use ReSharper to generate a field name _registrar, generate the Registrar class, and generate the Registrar.Register() method.  Once the Register() method is generated, we need to choose the type we’ll use for the return value and parameters and then replace the throw statement with a return of null so our assertion will fail for the right reason later.  Let’s make the receipt be a RegistrationReceipt type and use integers for our Ids:

public class when_registering_for_a_class
{
  static Registrar _registrar;

  Establish context = () => { _registrar = new Registrar(); };

  Because of = () => _registrationReceipt = _registrar.Register(EmployeeId, ClassId);

  It should_return_a_registration_receipt = () => _registrationReceipt.ShouldNotBeNull();
}

class Registrar
{
  public RegistrationReceipt Register(int employeeId, int classId)
  {
  }
}

Continuing, we generate the RegistrationReceipt type, _registrationReceipt field, and create some constants for our Ids:

public class when_registering_for_a_class
{
  const int EmployeeId = 1;
  const int ClassId = 2;
  static Registrar _registrar;
  static RegistrationReceipt _registrationReceipt;

  Establish context = () => { _registrar = new Registrar(); };
  
  Because of = () => _registrationReceipt = _registrar.Register(EmployeeId, ClassId);

  It should_return_a_registration_receipt = () => _registrationReceipt.ShouldNotBeNull();
}

class Registrar
{
  public RegistrationReceipt Register(int employeeId, int classId)
  {
    return null;
  }
}

class RegistrationReceipt
{
}

 

At this point everything compiles cleanly.  Running our test with the ReSharper test runner produces the following:

should return a registration receipt : Failed
Should be [not null] but is [null]

We’re now ready to make our test pass (which we can do by just returning a new RegistrationReceipt from our Register method), factor out any duplication, and move on to our next assertion or specification either to flesh out this design or to move on to our next feature.

By starting with our assertion first, moving to the execution of our System Under Test, and ending with our context setup, we’ve allowed our test to guide our design rather than allowing an existing design (coded or in our heads) to guide the implementation of our test.

In summary, organize your tests using Arrange, Act, Assert, but implement them in the order of Assert, Act, Arrange.

Tagged with:  

Hosting a Git Repository in Windows

On February 20, 2012, in Uncategorized, by derekgreer

If you’re working in a Windows-only environment and you’d like to host a git repository, this article will walk you through three different approaches: Shared File System Hosting, Git Protocol Hosting, and SSH Hosting.

Setting Up Your Repository

Before choosing which hosting strategy you’d like to use, you’ll first need a git repository to share.  The following steps will walk you through setting up an empty git repository.

Step 1 – Install Git

The most popular way to install git on Windows is by installing msysGit.  The msysGit distribution of git includes a minimalist set of GNU utilities along with the git binaries.  Download the msysGit installer and execute it.  When prompted to select components on the forth dialog, enable the Windows Explorer Integration components: ‘Git Bash Here’ and ‘Git GUI Here’.  When prompted to configure the line-ending conversions, select ‘checkout as-is, commit as-is’ if your team will only ever be working on projects from a Windows machine.

For reference, here are the dialogs presented by the wizard:

msysgit-install-1-3_thumb2

msysgit-install-4-6_thumb2

msysgit-install-7-9_thumb3

 

Step 2 – Create a Bare Repository

With this step, we’ll be creating an empty repository for a sample project named ‘sample’.  Since we’ll only be using this repository remotely, we’ll be initializing a folder as a ‘bare’ repository, which means that git will place all the files git needs to manage the repository directly within the initialized folder rather than in a ‘.git’ sub-folder.  To create the repository, follow these steps:

  • Using Windows Explorer, create a folder somewhere on the server where you plan to store all of your repositories (e.g. C:\git\).
  • Within the chosen repositories parent folder, create a sub-folder named ‘example.git’.
  • From the folder pane of Windows Explorer, right click on the ‘example’ folder and select ‘Git Bash Here’.  This will open up a bash shell.
  • At the command prompt, issue the following command:
$> git init --bare

Note

The ‘example’ repository can be created using your own credentials, but if you’d like to use the ‘Single User’ strategy presented in the SSH Hosting section, I’d recommend creating a ‘git’ Windows account and creating the repository with that user.

 

You now have a git repository for the ‘example’ project and are ready to select a strategy for sharing this repository with your team.

Shared File System Hosting

Hosting a git repository via a shared file system is by far the easiest way to get started sharing a git repository.  Simply share the main git folder where you created the ‘example.git’ repository and grant full control of the contents.  Once you’ve set up the desired level of access, users can clone the shared repository using the following command:

$> git clone \\[repository server name]\[share name]\example.git

Git Protocol Hosting

Git supplies its own ‘git’ protocol for simple hosting purposes.  To host an existing repository using the git protocol, you can simply issue the following command from the hosting server:

$> git daemon --base-path=C:/git --export-all

This will host all repositories located in the folder C:/git as read-only.  To allow push access, add –enable=receive-pack:

$> git daemon --base-path=C:/git --export-all --enable=receive-pack

This is fine for situations where you want to temporarily share a repository with a co-worker (e.g. when working on a feature branch together), but if you want to permanently share remote repositories then you’ll need to start the git daemon as a Windows service.

Unfortunately, it doesn’t seem Microsoft makes installing an arbitrary command as a service very easy.  Windows does provide the Service Control utility (e.g. sc.exe), but this only allows you to work with Windows service applications.  To resolve this problem, a simple .Net Windows Service application can be created which performs a Process.Start() on a supplied service argument. 

For the purposes of this guide, I’ve created just such a service which you can obtain from https://github.com/derekgreer/serviceRunner.  Once you have the service compiled, create a batch file named ‘gitd.bat’ with the following contents:

"C:\Program Files (x86)\Git\bin\git.exe" daemon --reuseaddr --base-path=C:\git --export-all --verbose --enable=receive-pack

You can then register the gitd.bat file as a service using the Service Control utility by issuing the following command (from an elevated prompt):

sc.exe create "Git Daemon" binpath= "C:\Utils\ServiceRunner.exe C:\Utils\git-daemon.bat" start= auto

To start the service, issue the following command:

sc.exe start "Git Daemon"

After successfully starting the Git Daemon service, you should be able to issue the following command:

git clone git://localhost/example.git

Registering Git Daemon With Cygwin


As an alternative to using the Service Control utility, you can also install any application as a service using Cygwin’s cygrunsrv command.  If you already have Cygwin installed or you’re planning on using Cygwin to host git via SSH then this is the option I’d recommend.  After installing Cygwin with the cygrunsrv package, follow these steps to register the git daemon command as a service:


Step 1: Open a bash shell


Step 2: In a directory where you want to store your daemon scripts (e.g. /cygdrive/c/Cygwin/usr/bin/), create a file named “gitd” with the following content:

#!/bin/bash

c:/Program \Files/Git/git daemon --reuseaddr                 \
                                 --base-path=/cygdrive/c/git \
                                 --export-all                \
                                 --verbose                   \
                                 --enable=receive-pack

Step 3: Run the following cygrunsrv command to install the script as a service (Note: assumes Cygwin is installed at C:\Cygwin):

cygrunsrv   --install gitd                          \
            --path c:/cygwin/bin/bash.exe           \
            --args c:/cygwin/usr/bin/gitd           \
            --desc "Git Daemon"                     \
            --neverexits                            \
            --shutdown

Step 4: Run the following command to start the service:

cygrunsrv --start gitd

SSH Hosting

Our final approach to be discussed is the hosting of git repositories via SSH.  SSH (which stands for Secure Shell) is a protocol commonly used by Unix-like systems for transporting information securely between networked systems.  To host git repositories via SSH, you’ll need to run an SSH server process on the machine hosting your git repositories.  To start, install Cygwin with the openssh package selected. 

Once you have Cygwin installed, follow these steps:

Step 1 – Open a bash shell

Step 2 – Run the following command to configure ssh:

ssh-host-config -y

For later versions of Windows, this script may require that a privileged user be created in order to run with elevated privileges.  By default, this user will be named cyg_server.  When prompted, enter a password for the cyg_server user which meets the password policies for your server.

Step 3 – Run the following command to start the sshd service:

net start sshd

You should see the following output:

The CYGWIN sshd service is starting.
The CYGWIN sshd service was started successfully.

The sshd service should now be up and running on your server.  The next step is to choose a strategy for allowing users to connect via SSH.

User Management Strategy

There are two primary strategies for managing how users connect to the SSH server.  The first is to configure each user individually.  The second is to use a single user for your entire team.  Let’s look at each.

Individual User Management

SSH allows users configured in the /etc/passwd file to connect via SSH.  Cygwin automatically creates this file when it first installs.  To add additional users (e.g. the user ‘bob’), you can append new records to the passwd file by issuing the following command from a bash shell:

mkpasswd -l | grep ‘^bob’ >> /etc/passwd

This command adds an entry for a user ‘bob’ by doing the following:

  • run the mkpasswd command for all local users
  • select only entries starting with the string ‘bob’
  • append the entry to the /etc/passwd file

To see the new entry, you can ‘cat’ the contents of the file to the screen by issuing the following command:

cat /etc/passwd

This should show entries that look like the following:

SYSTEM:*:18:544:,S-1-5-18::
LocalService:*:19:544:U-NT AUTHORITY\LocalService,S-1-5-19::
NetworkService:*:20:544:U-NT AUTHORITY\NetworkService,S-1-5-20::
Administrators:*:544:544:,S-1-5-32-544::
Administrator:unused:500:513:DevMachine\Administrator,S-1-5-21-2747539007-3005349326-118100678-500:/home/Administrator:/bin/bash
Guest:unused:501:513:DevMachine\Guest,S-1-5-21-2747539007-3005349326-118100678-501:/home/Guest:/bin/bash
bob:unused:1026:513:git,DevMachine\bob,S-1-5-21-2747539007-3005349326-118100678-1026:/home/git:/bin/bash

By adding the new entry to the /etc/password file, the user ‘bob’ will now have access to access git repositories via SSH.  To clone a repository, Bob would simply need to issue the following command:

git clone ssh://DevMachine/git/example.git

At this point, Bob would have to enter his password as it is set on the server.  I’ll show you how to avoid typing the password a little later.

One downside of this setup, however, is that the user ‘bob’ will also have access to shell into the machine by entering the following command:

ssh DevMachine

If the user bob already has an account on the machine, this probably isn’t an issue.  However, not all users in the /etc/password file are necessarily accounts on the local server.  You can also add network users by issuing the following command:

mkpasswd -d [domain name] -u [user name] >> /etc/passwd

In this case, you may want to restrict what the user ‘bob’ can do to just issuing git commands.  You can do this by changing bob’s default shell entry in the /etc/passwd file from /bin/bash to /usr/bin/git-shell.  The git-shell is a special shell which restricts access to just a few git commands.  Trying to ssh into a server where the shell is set to git-shell will print an error message.

Single User

Another strategy that is a bit easier to manage is to use a single user for all team members.  At first, this might seem like you’re just throwing up your hands and opening up access to everyone, but this isn’t actually the case as we’ll see shortly.

To use this strategy, follow these steps:

Step 1 – Global User Creation

First create a new user to be used for git access.  I’ll call the user ‘git’ for our example. 

Step 2 – Configure SSH Access

Now, configure the ‘git’ user to have access to shell into the server:

mkpasswd -l | grep ‘^git’ >> /etc/passwd

Step 3 – Change Shell

Optional, but it’s a good idea to set the git user’s shell to the git-shell.

You should now be able to use the git user to access any git repositories on the server.  If you test that out at this point, you’ll be prompted for the ‘git’ user’s password.

What we want to do at this point is configure users to have access to ssh as the ‘git’ account without having to use the password.  To do this, we’ll need to set up an ssh public/private key pair for each user.  Let’s use bob as our example.  I’ll be using Cygwin’s openssh as our example, but the concepts are the same if using Putty as your SSH client.

To setup bob’s ssh keys, he’ll need to run the following command:

ssh-keygen

This will prompt the user bob for the location to store the ssh keys.  Hitting enter will accept the defaults. The command will further prompt him for a passphrase.  A passphrase is recommended because it keeps anyone who has access to bob’s machine from getting his private key and impersonating him, but for now let’s just have him hit enter when prompted.  Entering an empty passphrase will cause ssh to bypass asking for anything.  I’ll talk about ways of using a passphrase without having to enter it every time in a bit.

Here’s the kind of output you’ll see:

Generating public/private rsa key pair.
Enter file in which to save the key (/home/bob/.ssh/id_rsa):
Created directory '/home/bob/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/bob/.ssh/id_rsa.
Your public key has been saved in /home/bob/.ssh/id_rsa.pub.
The key fingerprint is:
53:6c:19:ec:c7:96:c5:ee:1d:b0:93:84:b6:8c:a5:2d bob@bobsMachine
The key's randomart image is:
+--[ RSA 2048]----+
|         .. ..   |
|         ..* oo  |
|         .%.o++  |
|         E.+=+.. |
|        S .o ....|
|         .    . .|
|                 |
|                 |
|                 |
+-----------------+

From here, Bob will have a newly created .ssh directory in his home directory:

.ssh $> ls

id_rsa  id_rsa.pub

What we as the admin of the git server need from Bob is the contents of his id_rsa.pub file.  That should look something like the following:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDRVsZqNvQNc9YBcLCrm2pZotUiFsyZsQtdhWdtVF3u3PHR1ZNcGvWqSSI+hrb7HP/mTFBzyciO1nWRfbERXjexLd5uBf+ou5ZHDs51JIGQs61Lb+Kq/Q8P2/77bqGIIF5cZPfewZM/wQYHiR/JhIWHCRRmVOwPgPkfI7cqKOpbFRqyRYuV0pglsQEYrjm4FCM2MJ4iWnLKdgqj6vCJbNT6ydx4LqqNH9fCcbOphueoETgiBeUQ9U64OsEhlek9trKAQ0pBSNkJzbslbqzLgcJIitX4OYTxau3l74W/kamWeLe5+6M2CUUO826R9j4XuGQ2qqo5A5GrdVSZffuqRtX1 bob@bobMachine

Next, we want to add this key to a special file named authorized_users in the remote ‘git’ user’s .ssh folder.

[DevMachine]: .ssh > $ cat authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC36qnox4nlTInc1fyOlaUC3hJhEdVM4/qKeEKPBJ520sOzJG+cRvRGNSdbtLNKD9xZs0dpiql9Vtgy9Yc2XI+lWjBGUmPbqWUuP8IZdFGx3QwPSIx9YzakuUBqYE5+9JKcBuHIhIlilqCCzDtXop6Bi1lN0ffV5r6PyqyFIv0L7MJb8jDsHX7GRl4IGu8ScxfY4G0PS3ZrMGfQBr2fm8KFzg7XWVaP/HTT4XKcf5Jp6oHvLz8FvEfdZdajyFUXRzrE0Kt9KAbeIBJV8+usiTAVpsmMY1yfrsuBUdOlhpvL/pU2o5B6K8VlJeXSF4IYEgS+v6JBAlyaWQkXupQr+lIL bob@BobMachine

That’s it.  The user ‘bob’ will now be able to ssh without providing a password.

SSH Without Passphrases

Remember, it’s recommended that everyone use a passphrase.  This prevents someone who’s gained access to your machine from tricking out the remote server to letting them have access as you.  To use a passphrase, repeat the above steps with a a passphrase set.  To keep us from having to always type in the passphrase, we can use ssh-agent (or the Pageant process for Putty users).  The basic premise is that you type your passphrase once per session and the ssh-agent will keep track of the passphrase for you. 

To use the ssh-agent to track your passphrase, add the following to your ~/.bash_profile:

SSHAGENT=/usr/bin/ssh-agent
SSHAGENTARGS="-s"
if [ -z "$SSH_AUTH_SOCK" -a -x "$SSHAGENT" ]; then
	eval `$SSHAGENT $SSHAGENTARGS`
	trap "kill $SSH_AGENT_PID" 0
fi

Close your bash shell and reopen it.  You should see an agent pid output when you open your shell again.

Agent pid 1480
[DevMachine]: >

Now, issue the following command:

ssh-add ~/.ssh/id_rsa

Type your passphrase when prompted.  Thereafter, you will be able to ssh without providing a passphrase.

That concludes the guide.  Enjoy!

						
Tagged with:  

JavaScript Closures Explained

On February 17, 2012, in Uncategorized, by derekgreer

If you write any code in JavaScript then you’ve probably used closures, but do you actually understand what they are and how they work?  Taking the time to understand closures and how they’re implemented can add a deeper dimension to your understanding of the JavaScript language.  In this article, I’ll discuss what closures are and how they’re specified for the JavaScript language.

What Are Closures?

A closure is a pairing of a function along with its referencing environment such that identifiers within the function may refer to variables declared within the referencing environment.

Let’s consider the following example:

var createGreeting = function(greeting) {
    return function(name) {
        document.write(greeting + ', ' + name + '.');
    };
};


helloGreeting = createGreeting("Hello");
howdyGreeting = createGreeting("Howdy");

helloGreeting("John");  // Hello, John.
helloGreeting("Sally"); // Hello, Sally.
howdyGreeting("John");  // Howdy, John.
howdyGreeting("Sally"); // Howdy, Sally.

In this code, a function named createGreeting is defined which returns an anonymous function.  When the anonymous function is executed, it prints a greeting which consists of the outer function’s greeting parameter along with the inner function’s name parameter.  While the greeting parameter is neither a formal parameter  nor a local variable of the inner function (which is to say it is a free variable), it is still resolved when the function executes.  Moreover, the createGreeting function object is no longer in scope and may have even been garbage collected at the point the function executes.  How then does this work?

The inner function is capable of resolving the greeting identifier due to a closure which has been formed for the inner function.  That is to say, the inner function has been paired with its referencing (as opposed to its calling) environment.

Conceptually, we can think of our closure as the marriage between a function and the environment in which it was declared within:

closure2

 

Exactly what this marriage looks like at an implementation level differs depending on the language.  In C# for instance, closures are implemented by the instantiation of a compiler-generated class which encapsulates a delegate and the variables referenced by the delegate from its declaring scope. In JavaScript, the function object itself contains a non-accessible property pointing to an object containing the variables from its declaring scope.  While each implementation differs, both render a function that has access to what its environment looked like at the point it was created.

Let’s move on to examining how JavaScript closures work from a specification perspective.

JavaScript Closures

To understand how closures work in JavaScript, it helps to have a grasp of the underlying concepts set forth within the ECMAScript Language Specification.  I’ll be using Edition 5.1 (ECMA-262) of the specification as the basis for the following discussion.

Execution Contexts

When a JavaScript function is executed, a construct referred to as an Execution Context is created.  The Execution Context is an abstract concept prescribed by the specification to track the execution progress of its associated code.  As an application runs, an initial Global Execution Context is created.  As each new function is created, new Execution Contexts are created which form an Execution Context stack.

There are three primary components prescribed for the Execution Context:

    1. The LexicalEnvironment

    2. The VariableEnvironment

    3. The ThisBinding

Only the LexicalEnvironment and VariableEnvironment components are relevant to the topic of closures, so I’ll exclude discussion of the ThisBinding.  (For information about how the ThisBinding is used, see sections 10.4.1.1, 10.4.2, and 10.4.3 of the ECMAScript Lanauage Specification.)

LexicalEnvironment

The LexicalEnvironment is used to resolve identifier references made by code associated with the execution context.  Conceptually, we can think of the LexicalEnvironment as an object containing the variables and formal parameters declared within the code associated by the current Execution Context.

A LexicalEnvironement itself is comprised of two components: An Environment Record, which is used to store identifier bindings for the Execution Context, and an outer reference which points to a LexicalEnvironment of the declaring Execution Context (which is null in the case of the Global Execution Context’s LexicalEnvironment outer reference).  This forms a chain of LexicalEnvironments, each maintaining a reference to the outer scope’s environment:

 

LexicalEnvironmentChain

 

VariableEnvironment

The VariableEnvironment is used to record the bindings created by  variables and function declarations within an execution context.  Upon reading that description, you may be thinking: “but I thought the LexicalEnvironment held the bindings for the current execution context”.  Technically, the VariableEnvironment contains the bindings of the variables and function declarations defined within an Execution Context and the LexicalEnvironment is used to resolve the bindings within the Execution Context.  Confused?  The answer to this seemingly incongruous approach is that, in most cases, the LexicalEnvironment and VariableEnvironment are references to the same entity.

The LexicalEnvironment and VariableEnvironment components are actually references to a LexicalEnvironment type.  When the JavaScript interpreter enters the code for a function, a new LexicalEnvironment instance is created and is assigned to both the LexicalEnvironment and VariableEnvironment references.  The variables and function declarations are then recorded to the VariableEnvironment reference.  When the LexicalEnvironment is used to resolve an identifier, any bindings created through the VariableEnvironment reference are available for resolution.

Identifier Resolution

As previously discussed, LexicalEnvironments have an outer reference which, except for the Global Execution Context’s LexicalEnvironment, points to a LexicalEnvironment record of the declaring Execution Context (i.e. a function block’s “parent” scope).  Functions contain an internal scope property (denoted as [[Scope]] by the ECMAScript specification) which is assigned a LexicalEnvironment from the declaring context.  In the case of function expressions (e.g. var doStuff = function() { …}), the [[Scope]] property is assigned to the declaring context’s LexicalEnvironment.  In the case of function declarations (e.g. function doStuff() { … }), the [[Scope]] property is assigned to the declaring context’s VariableEnvironment.  We’ll discuss the reasons for this disparity shortly, but for now let’s just focus on the fact that the function has a [[Scope]] which points to the environment in which is was created.  This is our pairing of a function with its referencing environment, which is to say, this is our closure. 

If we recall our previous conceptualization of a function paired with its environment, the JavaScript version of this conceptualization would look a little like this:

 

closure3

When resolving an identifier, the current LexicalEnvironment is passed to an abstract operation named GetIdentiferReference which checks the current LexicalEnvironment’s Environment Record for the requested identifier and if not found calls itself recursively with the LexicalEnvironment’s outer reference.  Each link of the chain is checked until the top of the chain is reached (the LexicalEnvironment of the Global Context) in which case the binding is resolved or a reference of undefined is returned.

A Distinction Without a Difference … Usually

As mentioned, the LexicalEnvironment and the VariableEnvironement references point to the same LexicalEnvironment instance in most cases.  The reason for maintaining these as separate references is to support the with statement.

The with statement facilitates block scope by using a supplied object as the Environment Record for a newly created LexicalEnvironment.  Consider the following example:

var x = {
    a: 1
};

var doSomething = function() {
    var a = 2;
    
    with(x) {
        console.log(a);
    };
};
doSomething(); // 1

In this code, while the doSomething function assigns the variable a the value of 2, the console.log function logs the value of 1 instead of 2.  What is happening here is that, for the enclosing block of code, the with statement is inserting a new LexicalEnvironment at the front of the chain with an Environment Record set to the object x.  When the code within the with statement executes, the first LexicalEnvironment to be checked will be the one created by the with statement whose Environment Record contains a binding of x with the value of 1.  Once the with statement exits, the LexicalEnvironment of the current Execution Context is restored to its previous state.

According to the ECMAScript specification, function expressions may be declared within a with statement, but not function declarations (though most implementations allow it with varied behavior).  Since function expressions may be declared, their declaration should form a closure based upon the declaring environment’s LexicalEnvironment because it is the LexicalEnvironement which might be changed by a with statement.  This is the reason why Execution Contexts are prescribed  two different LexicalEnvironment references and why function declarations and function expressions differ in which reference their [[Scope]] property is assigned upon function creation.

Conclusion

This concludes our exploration of closures in JavaScript.  While understanding the ECMAScript Language Specification in detail certainly isn’t necessary to have a working knowledge of closures, I find taking a peek under the covers now and again helps to broaden one’s understanding about a language and its concepts.

Tagged with:  

This is the fifth and final installment in the SOLID JavaScript series which explores the SOLID design principles within the context of the JavaScript language.  In this final installment, we’ll examine the Dependency Inversion Principle.

 

The Dependency Inversion Principle

The Dependency Inversion Principle relates to the stability and reusability of higher-level components within an application.  The principle states:

A. High-level modules should not depend on low-level modules.  Both should depend on abstractions.

B. Abstractions should not depend upon details.  Details should depend upon abstractions.

The primary concern of the Dependency Inversion Principle is to ensure that the main components of an application or framework remain decoupled from the ancillary components providing low-level implementation details.  This ensures that the important parts of an application or framework aren’t affected when the low level components need to change.

The first part of the principle concerns the method of coupling between high level modules and low level modules.  With traditional layered architecture, high level modules (components encapsulating the core business logic of the application) take dependencies upon low level modules (components providing infrastructure concerns).  When adhering to the Dependency Inversion Principle, this relationship is reversed (i.e. inverted).  Rather than high level modules being coupled to low level modules, low level modules are coupled to interfaces declared by the high level modules.  For example, given an application with persistence concerns, a traditional design might contain a core module which relies upon the API defined by a persistence module.  Refactoring toward the Dependency Inversion Principle, the persistence module would be modified to conform to an interface defined by the core module.

The second part of the Dependency Inversion Principle concerns the proper relationship between abstractions and details.  To understand this portion of the principle, it helps to consider its applicability to the language from whence the principle was conceived: the C++ language.

Unlike some statically typed languages, C++ doesn’t provide a language level construct for defining interfaces.  What it does provide is the separation of class definition from class implementation.  In C++, classes are defined using a header file which lists the member methods and variables of a class along with a source file which contains the implementation of any member methods.  Since any member variables and private methods are declared within the header file, it’s possible for classes intended to be used as abstractions to become dependent upon the implementation details of the class.  This is overcome by defining classes which only contain abstract methods (known in C++ as pure abstract base classes) to serve as interfaces for implementing classes.

DIP and JavaScript

As a dynamic language, JavaScript doesn’t require the use of abstractions to facilitate decoupling.  Therefore, the stipulation that abstractions shouldn’t depend upon details isn’t particularly relevant to JavaScript applications.  The stipulation that high level modules shouldn’t depend upon low level modules is, however, relevant.

When discussing the Dependency Inversion Principle in the context of statically-typed languages, the concern of coupling is both semantic and physical.  That is to say, if a high level module is coupled to a low level module, it is coupled both to the semantic interface as well as the physical definition of the interface defined within the low level module.  The implication is that high level module dependencies should be inverted both for dependencies upon 3rd party libraries as well as native low level modules.

To explain, consider a .Net application which might encapsulate useful high level modules which have a dependency upon a low level module providing persistence concerns. While the author is likely to have expressed a similar API for the persistence interface whether the DIP was adhered to or not, the high level module would not be capable of being reused in another application without bringing along the dependency upon the low level module where the persistence interface is defined.

In JavaScript, the applicability of the Dependency Inversion Principle is relevant only to the semantic coupling of high level modules to low level modules.  As such, adherence to the DIP can be achieved simply by expressing the semantic interface in terms of the application’s needs as opposed to coupling to the implicit interface defined by whatever implementation is chosen for a low level module.

To illustrate, consider the following example:

$.fn.trackMap = function(options) {
    var defaults = { 
        /* defaults */
    };
    options = $.extend({}, defaults, options);

    var mapOptions = {
        center: new google.maps.LatLng(options.latitude,options.longitude),
        zoom: 12,
        mapTypeId: google.maps.MapTypeId.ROADMAP
    },
        map = new google.maps.Map(this[0], mapOptions),
        pos = new google.maps.LatLng(options.latitude,options.longitude);

    var marker = new google.maps.Marker({
        position: pos,
        title: options.title,
        icon: options.icon
    });

    marker.setMap(map);

    options.feed.update(function(latitude, longitude) {
        marker.setMap(null);
        var newLatLng = new google.maps.LatLng(latitude, longitude);
        marker.position = newLatLng;
        marker.setMap(map);
        map.setCenter(newLatLng);
    });

    return this;
};

var updater = (function() {    
    // private properties

    return {
        update: function(callback) {
            updateMap = callback;
        }
    };
})();

$("#map_canvas").trackMap({
    latitude: 35.044640193770725,
    longitude: -89.98193264007568,
    icon: 'http://bit.ly/zjnGDe',
    title: 'Tracking Number: 12345',
    feed: updater
});

In this listing, we have a small library which converts a div target into an map used to show the current location of a item being tracked.  The trackMap function has two dependencies: the 3rd party Google Maps API and a location feed.  The responsibility of the feed object is to simply invoke a callback (supplied during the initialization process) with a new latitude and longitude position when the icon location should be updated.  The Google Maps API is used to do the actual rending of the map to the screen.

While the interface of the feed object may or may not have been designed in terms of the trackMap function, the fact that its role is simple and focused makes it easy to substitute different implementations.  Not so with the Google Maps dependency.  Since the trackMap function is semantically coupled to the Google Maps API, switching to a different mapping provider would require the trackMap function to be rewritten or an adapter to be written to adapt another mapping provider to Google’s specific interface.

To invert the semantic coupling to the Google Maps library, we need to redesign the trackMap function to have a semantic coupling to an implicit interface which abstractly represents the functionality needed by a mapping provider.  We would then need to implement an object which adapts this interface to the Google Maps API.  The following shows this alternate version of the trackMap function:

$.fn.trackMap = function(options) {
    var defaults = { 
        /* defaults */
    };

    options = $.extend({}, defaults, options);

    options.provider.showMap(
        this[0],
        options.latitude,
        options.longitude,
        options.icon,
        options.title);

    options.feed.update(function(latitude, longitude) {
        options.provider.updateMap(latitude, longitude);
    });

    return this;
};


$("#map_canvas").trackMap({
    latitude: 35.044640193770725,
    longitude: -89.98193264007568,
    icon: 'http://bit.ly/zjnGDe',
    title: 'Tracking Number: 12345',
    feed: updater,
    provider: trackMap.googleMapsProvider
});

In this version, we’ve redesigned the trackMap function to express its needs in terms of a generic mapping provider interface and have moved the implementation details out into a separate googleMapsProvider component which can be bundled as a separate JavaScript module.  Here’s our googleMapsProvider implementation:

trackMap.googleMapsProvider = (function() {
    var marker, map;

    return {
        showMap: function(element, latitude, longitude, icon, title) {
            var mapOptions = {
                center: new google.maps.LatLng(latitude, longitude),
                zoom: 12,
                mapTypeId: google.maps.MapTypeId.ROADMAP
            },
                pos = new google.maps.LatLng(latitude, longitude);

            map = new google.maps.Map(element, mapOptions);

            marker = new google.maps.Marker({
                position: pos,
                title: title,
                icon: icon
            });

            marker.setMap(map);
        },
        updateMap: function(latitude, longitude) {
            marker.setMap(null);
            var newLatLng = new google.maps.LatLng(latitude,longitude);
            marker.position = newLatLng;
            marker.setMap(map);
            map.setCenter(newLatLng);
        }
    };
})();

With these changes, our trackMap function is now more resilient to the changes that might occur to the Google Maps API and is capable of being reused with another mapping provider.  That is, as long as it’s API can be adapted to the needs of our application.

Whither Dependency Injection?

While not particularly related, the concept of Dependency Injection is often confused with the Dependency Inversion Principle due to a similarity in terminology.  For this reason, a discussion of the differences between the two concepts may prove helpful for some.

Dependency Injection is a specific form of Inversion of Control in which the concern being inverted is how a component obtains its dependencies.  When using Dependency Injection, dependencies are supplied to a component rather than the component obtaining the dependency by means of creating an instance of the dependency, requesting the dependency through a factory, requesting the dependency from a Service Locator, or any other means of initiation by the component itself.  Both the Dependency Inversion Principle and Dependency Injection are concerned with dependencies and both use the notion of inversion to contrast an alternate approach to a presumed standard approach.  However, the Dependency Inversion Principle isn’t concerned with how components obtains their dependencies, but with the decoupling of high level components from low level components.  In a sense, the Dependency Inversion Principle might be said to be another form of Inversion of Control where the concern being inverted is which module defines the interface.

Conclusion

This brings us to the end of our series.  While in the course of our examination we saw variations in how the SOLID design principles apply to JavaScript over other languages, each of the principles were shown to have some degree of applicability within JavaScript development.

Tagged with: