Architectural Tragedy of the Commons

Wednesday, October 12, 2011 by K. Scott Allen

From Wikipedia:

The tragedy of the commons is a dilemma arising from the situation in which multiple individuals, acting independently and rationally consulting their own self-interest, will ultimately deplete a shared limited resource, even when it is clear that it is not in anyone's long-term interest for this to happen.

Some rights reserved by heyjoewhereyougoinwiththatguninyourhandIt might seem odd to take a term related to environmental issues and apply the term to software, but please allow some poetic license around the meaning of "shared limited resource".

The architecture and design of an existing application is a resource providing a benefit to the developers and operational people who have to build features in an application and keep it running in production. It's a limited resource since misuse will reduce the benefit for everyone.

"Architectural tragedy of the commons" is a term that jumped into my mind a few years ago as something that can happen (not always, but sometimes) when:

- developers build new features into a  product without talking to each other (individuals act in their own self interest.

- teams build new features for a product without coordinating (teams can act in their own self interest).

- companies go through developers like Netflix goes through business plans (in a body shop, nearly everyone acts in their own self interest).

You've probably worked on applications where shortcuts and hacks make a codebase fragile and inconsistent. Maybe you've even worked on products where the developers took shortcuts that made the application more difficult to deploy and operate (thus making the IT department's life miserable).  This are examples of what I'd call an architectural tragedy of the commons.

Tree-iconCommunication and leadership can commonly prevent an architectural tragedy of the commons, and often leads to sustainable design.

Modernizr.js : Feature Detection

Tuesday, October 11, 2011 by K. Scott Allen

As we saw in a previous post, Modernizr allows you to work with the new HTML 5 elements, like nav, and still support browsers that don't know anything about a nav, or HTML 5.

However, HTML 5 is more than just a few dozen semantically meaningful elements. There are WebSockets, WebWorkers, WebStorage, and a number of other features that are interesting from a programmability perspective (not to mention all new CSS3 capabilities). The questions is: how do you know if a specific user's browser supports a particular feature?

For years we've relied on browser sniffing (user agent sniffing) to determine browser capabilities, but user agent string are often manipulated, sometimes misleading, and constantly mutating. If you truly want to know if a browser supports a particular feature, like local storage, then the most honest answer you'll receive is by interrogating the browser directly with script.

In other words - if you truly want to know if a browser is a duck, then ask it to quack.

The Tests

When Modernizr loads, it executes a series of tests to see what features the environment supports. For example, here is the test for canvas capabilities:

tests['canvas'] = function() {
    var elem = document.createElement('canvas');
    return !!(elem.getContext && elem.getContext('2d'));

There are presently over 40 tests, from applicationcache to webworkers. The result of each test is made available on the Modernizr object for easy access from script. If you want to know if canvas is available, for example, you can just ask Modernizr.

if (Modernizr.canvas) {
    // do something canvasy

If you want to see all the available test results, try out my featureDump. This uses underscore and jQuery templates, excerpt below, to grab all the Modernizr test results.

$(function () {

    var featureMap =

    function noFunctionsOrPrivates(key) {
          return typeof Modernizr[key] !== "function" &&
                 key.substring(0, 1) !== "_";

    function toNameAndResult(key) {
        return {
            "name": key,
            "result": Modernizr[key]

    function name(feature) {

    $("#mainTable").tmpl({ "feature": featureMap })

The code should produce a table like the following:


CSS, Too

In addition to adding test results as properties to the Modernizr object, Modernizr also adds the test results as classes to the root html element. This is a technique used by several libraries to write CSS rules that apply to specific environments. In a live DOM explorer (what you get with Inspect Element in Chrome), you can see these classes. 


Notice that if a test passes, you get the test name (canvas). If a test fails, you get a "no-" prefix (as in no-touch). These classes are useful if you want to write CSS style rules that will only apply themselves to browsers that implement (or don't implement) a specific feature.

.no-cssgradients body {
    /* styles */

.cssgradients body {
    /* styles */

But – What If The Answer Is No?

If a browser does not implement a particular feature – you don't always have to give up. In a future post we'll look at how Modernizr's script loading capabilities can combine with polyfills to bring some old browsers up to speed.

ParallelLoopState and Parallel.ForEach

Monday, October 10, 2011 by K. Scott Allen

The Task Parallel Library is a joy to work with – it's easy to use and thorough. Recently I was using Parallel.ForEach to process a large collection, but wanted to stop processing early, across all threads, if an individual item met specific criteria. It's as easy as adding a ParallelLoopState parameter to the action body.

var result = Parallel.ForEach(messages, (message, loopState) =>
    if (message.IsOneThatStopsProcessing)

    // ...
    // other processing
    // ...


You can halt processing early by calling either Break or Stop on the loop state parameter. Break is for ordered collection where you want to halt at a specific location.


Thursday, October 6, 2011 by K. Scott Allen

modernizrModernizr.js is a little library that will help "modernize" old browsers.

As an example, let's say you create a new ASP.NET MVC 3 application with the "Use HTML 5 semantic markup" checkbox selected. If you peek into the layout view for the app, you'll find the following markup:

    <ul id="menu">
        <li>@Html.ActionLink("Home", "Index", "Home")</li>
        <li>@Html.ActionLink("About", "About", "Home")</li>

The nav element represents a section with navigation links, and is a new element in the HTML 5 spec. The idea is that using nav gives more meaning to the page, and allows user agents like screen readers to identify navigation information (contrast nav against using a regular div element as the container  - a div carries relatively no semantic value by itself).

There is a problem, however. Older versions of Internet Explorer (anything before version 9) do not recognize the nav element. IE refuses to apply style rules to unidentified elements, and will also not allow unidentified elements to have children in the DOM. If you have to support older versions of IE this will sound like a dire situation, but it turns out there is an easy solution.

HTML5 Shiv

You can "register" elements in IE using document.createElement. For example…


... is all you need to do for IE to apply style rules to <foo> elements, and construct them appropriately in the DOM. Years ago Remy Sharp created the html5shiv project, which was the first library to essentially execute createElement for all of the new HTML 5 elements, including nav, article, footer, header, etc. html5shiv then allows IE to recognize all HTML 5 elements. 

Modernizr also "registers" all HTML 5 elements, meaning the HTML 5 MVC web application you build will work just fine on older versions of IE (as long as you leave Modernizer in your layout view). One note: you'll want to keep the script tag for Modernizr inside the <head> element. All the calls to createElement for new elements must happen before IE reaches the <body> tag.

Enabling HTML 5 elements is just one of the features Modernizr provides. In future posts we'll look at Modernizr's ability to detect features, and inject fallback scripts.

Rise and Fall of Classic OOP

Wednesday, October 5, 2011 by K. Scott Allen

When I was making the switch from C and assembly to C++ I did quite a bit of reading on object oriented programming. It's hard to find material on OOP that doesn't praise the classical pillars of encapsulation, inheritance, and polymorphism. In the early years these three pillars were advertised as solution to all the ills of software development. Object oriented programming was my first "silver bullet" experience in the software industry.

Dr. Brumble's OOP Elixir!

OOP has been successful. The majority of the today's most popular programming languages support classical OOP techniques as first class language features. The techniques have even pushed their way into languages like Perl and PHP, and developers including myself have used OOP to build frameworks, applications, and libraries for desktops, devices, and the web.

So then, why did I recently debate an old friend about the decline of OOP?

The Application Framework Mirage

My friend is die hard OOP proponent. He recognizes some of the flaws in the classical OOP principle of inheritance, but for him OOP is the hammer for every nail. He proposed that the most successful UI frameworks he's ever used are all built using classic OOP principles, and therefore objects afford the most modular, reusable, and extensible software possible.

I had some time to think about this argument on a recent flight to Norway, and I think holding up frameworks like Swing and Silverlight (or to go back in time, MFC and OWL) isn't fair. You can always find places where a certain paradigm is the best solution, and for application frameworks in general, and UI frameworks in particular, OOP might have found a sweet spot. A sweet spot because UI frameworks represent an alternate reality. The architects and developers get to make the rules of the reality, and implement the code. Where else but in a UI framework can you find a workable inheritance hierarchy 9 layers deep?

It's not that UI frameworks don't face constraints. There are performance constraints, memory constraints, video constraints. Still, UI frameworks are far away from the messy (and sometimes absurd) realities of the physical world. It is the application code where IS-A relationships are difficult to find and break down quickly. It is application code where roles and responsibilities are difficult to classify and harden into code because domain knowledge can span decades and domain experts will evolve the rules with every passing fiscal quarter.

It's in application code where I've found, over the last few years, that modularization and reuse come about easier by going very big, or going very small. Big in the form of web services, where you can hide an entire platform behind well defined interfaces and standards. Small in the form of functions with well defined meanings, clean inputs and outputs, and nothing but a black box in-between.

Services, classes, functions!

Classes? They get stuck in the middle. There is no generally accepted standard even within a single programming language like C# on how to approach class design, or how to consume a class. Do I inherit from it? Create it with the constructor? Use a factory methods? Use a factory object? Call into the base class method override before I do my work? Or After? Too many choices make simple chores complicated.

To You, My Friend

Look again at the list of the most popular programming languages and see how many languages support more than a single paradigm. It's not that OOP has failed, or is failing. It's just easy to see the other choices now that the silver has worn off the bullet.

Execute&lt;T&gt; With IronRuby

Tuesday, October 4, 2011 by K. Scott Allen

Imagine (or dream) that you have some IronRuby code to execute.

require 'net/telnet'

host = => 'localhost')


return data

One way to execute the code and capture the result is to use Execute<T> on the ScriptEngine object.

public T Execute<T>(string fileName)
    var script = File.ReadAllText(fileName);
    var engine = IronRuby.Ruby.CreateEngine();
        SearchPaths // will contain paths like: 
        // @"C:\Program Files (x86)\IronRuby 1.1\Lib\ironruby" and
        // @"C:\Program Files (x86)\IronRuby 1.1\Lib\ruby\1.9.1"        
    var result = engine.Execute<T>(script);
    return result;

However, if you want syntax checks and error messages with line numbers, you'll need to take a couple additional steps. First, define a class that derives from the abstract ErrorListener class in Microsoft.Scripting.Hosting. The ErrorReported method can provide details about errors.

public class ReportingErrorListener  : ErrorListener
    private readonly TextWriter _writer;

    public ReportingErrorListener(TextWriter writer)
        _writer = writer;

    public override void ErrorReported(
        ScriptSource source, string message, 
        SourceSpan span, int errorCode, 
        Severity severity)
        _writer.WriteLine("Error starting at line {0} column {1}",
                           span.Start.Line, span.Start.Column);

Now you can create a ScriptSource from the Ruby file, and use the ScriptSource object to Compile and Execute the result.

public T Execute<T>(string fileName)
    var engine = IronRuby.Ruby.CreateEngine();
    var source = engine.CreateScriptSourceFromFile(fileName);
    source.Compile(new ReportingErrorListener(Console.Out));
    var result = source.Execute<T>();
    return result;

C# Fundamentals Part II &amp; 10 Rules for Better C# Code

Monday, October 3, 2011 by K. Scott Allen

The second part of my C# fundamentals course is available for subscribers on

Part 2 introduces you to the variety of programming styles supported by the C# language. At its core, C# is an object-oriented, statically-typed language that lends itself to procedural and object-oriented programming, but recent additions to the language have made it much easier to develop using other programming paradigms, most notably, dynamic. This course covers object-oriented programming, functional programming, the dynamic language runtime, LINQ programming, and software craftsmanship.

The section on crafting C# code includes my current top 10 rules for writing better C# code, which was fun to record.