IFormattable

Create an XML Schema Enumeration of Supported .NET CultureInfo with Powershell

noreply@blogger.com (Christopher) — Tue, 10 Nov 2009 18:44:00 +0000

Here’s a Powershell script to generate the enumeration elements of an XML Schema simpleType restriction. The first command loads the .NET Assembly you’ll need, sysglobl.dll.

PS>  [System.Reflection.Assembly]::Load("sysglobl, Version=2.0.0.0, Culture=neutral, PublicKeyToken= b03f5f7f11d50a3a, processorArchitecture=MSIL")

PS> [System.Globalization.CultureInfo]::GetCultures([System.Globalization.CultureTypes]::FrameworkCultures)    
| ? {$_.Name.Trim().Length -eq 5} | % { "<xs:enumeration value=`"$_`"/>"} | Out-File cultures.txt

See my earlier post on locale identifiers for more background.

Whoa!!! HP Software Sucks!

noreply@blogger.com (Christopher) — Sat, 31 Oct 2009 00:17:00 +0000

This is the error that was reported after the HP installer forced me to restart my computer to continue installation…

TFS: Locked for Check-out

noreply@blogger.com (Christopher) — Thu, 15 Oct 2009 14:12:00 +0000

Today a co-worker was attempting to edit a file, and TFS reported that it was “locked for check-out by [me] in workspace …”.

I didn’t have it checked out. I tried to use “tf lock /lock:none” on the file in question, but it would simply report:

TF10152: The item … must remain locked because its file type prevents multiple check-outs.

We don’t allow multiple checkouts for this Team Project. Unfortunately, this meant that not only didn’t I intend to lock the file, I couldn’t unlock it.

My solution was to just check-in some dummy changes, comments full of expletives if you must know, since TFS will not perform a check-in unless there are actually changes to the files.

So yeah, not TFS’ most shining moment.

Cloud Morphology

noreply@blogger.com (Christopher) — Thu, 06 Aug 2009 04:01:00 +0000

Spent some time this evening tracking down the various component technologies of the myriad cloud offerings out there. Here’s the result. This will be updated over time.

NASA’s Cloud Platform: NEBULA, and Amorphous Morphology

noreply@blogger.com (Christopher) — Tue, 04 Aug 2009 21:45:00 +0000

NEBULA is a Cloud Computing environment developed at NASA Ames Research Center, integrating a set of open-source components into a seamless, self-service platform. It provides high-capacity computing, storage and network connectivity, and uses a virtualized, scalable approach to achieve cost and energy efficiencies.

They always write it in all caps, though it doesn’t appear to be an acronym. My guess is that it’s easier to search for “NEBULA” and find what you want at NASA. And, what better name for a cloud computing platform?

To be frank, I didn’t recognize any of the technologies other than RabbitMQ and Apache. So I set out to find out what each piece does, and it’s these times that really make me envious of the LAMP folks. There is so much going on in the OSS world!

In fact, it’s that sheer volume of innovation that makes it such a nightmare. Here’s where having NASA or Amazon or Elastra or EngineYard or Rackspace or Google AppEngine discuss their respective cloud infrastructures is so beneficial. If you look at their technology choices as a Venn diagram, you might find an optimal set of technologies in the overlap. Beyond that, you can begin to form a generalized blueprint of a cloud platform, identifying the core components.

In this way the cloud begins to take shape. Were we to sit all the big industry players down and say, define the cloud al a the OSI model, no one would have gotten around to building one. If we find the clouds in the wild, we can dissect them and find out what makes them tick. We can reverse engineer our blueprint.

There’s a few major players missing here, of course, most notably Salesforce.com (SFDC) and Microsoft’s Azure platform. SFDC doesn’t have an infrastructure that you can replicate, per se, because it is inseparable from their proprietary technologies. In fact, Stu Charlton and others have noted that this is their biggest failing. Similarly, Microsoft’s Azure is also a monolithic platform play, with the major difference that the platform can be deployed on premises, a so-called private cloud.

Still though, we can include SFDC and Azure in our analysis. We can develop our morphology of the cloud platforms that have published their constituent technologies. With the language of this morphology in hand, we can classify the facilities of other cloud platforms. Perhaps a taxonomy will evolve that allows us to identify Platform-as-a-Service, Infrastructure-as-a-Service, Software-as-a-Service, hybrids, and perhaps some novel species.

Despite the amorphous character implied by the term cloud computing, these platforms have well-defined structure. Moreover, unlike the traditional use of clouds in architecture diagrams, the details of this structure are important.

Powershell: Get Size of Child Directories

noreply@blogger.com (Christopher) — Mon, 03 Aug 2009 03:33:00 +0000

gci -recurse -force |
? { $_.GetType() -like 'System.IO.DirectoryInfo'} |
     select-object Name,@{Name="size"; Expression = {
    ($_.GetFiles() |
    Measure-Object -Property Length -Sum |
     Measure-Object -Property Sum -Sum).Sum}} | sort-object -Property size

Three Common Fallacies Concerning REST

noreply@blogger.com (Christopher) — Wed, 08 Jul 2009 18:09:00 +0000

Better to light a candle than to curse the darkness. -Chinese Proverb

I purposely did not title this post “The 3 Fallacies of RESTful Computing” as I am certainly not an expert in either REST or fallacy. :) I am, however, quite well-versed in auto-didacticism, and over the past week I’ve been boning up on REST. Along the way I’ve had one of my early notions of REST disabused (it is neither an architecture nor a protocol) and noticed a few other common misconceptions in the blogosphere and tweet stream. If you are new to REST, or even if you aren’t, you might very well find a few edifying points in this post; I hope to light a candle or two out there.

Without further ado, here are three common fallacies concerning REST.

Fallacy #1 REST is CRUD

Perhaps the most common fallacy of RESTful computing is that REST is simply CRUD (Create, Read, Update, and Delete) over HTTP. Microsoft’s ADO.NET Data Services endeavors to provide developers a “data service being surfaced to the web as a REST-style resource collection[…]”; this would seem to further the notion that REST is another way of doing CRUD.

However, REST is not CRUD as Stu Charlton states in a blog post about REST design guidelines; Arnon Rotem-Gal-Oz says CRUD is bad for REST, too. If we are going to attempt to abridge RESTful architecture with an innocuous statement of the form “REST is X over HTTP” let us say that REST is using URLs to facilitate application state changes over HTTP.

Fallacy #2 POST is not RESTful

First, it is very important to note that REST is not tied to a specific protocol. As an architectural style, it is protocol agnostic; though to be sure HTTP is a natural fit for many reasons. As Fielding said in It is okay to use POST:

Search my dissertation and you won’t find any mention of CRUD or POST. The only mention of PUT is in regard to HTTP’s lack of write-back caching. The main reason for my lack of specificity is because the methods defined by HTTP are part of the Web’s architecture definition, not the REST architectural style.

Since the nominal use of POST is orthogonal to RESTfulness, by definition, it cannot be the case that POST is antithetical to REST. Nevertheless, it is important to understand the reasoning that generally goes into this fallacy, because it speaks directly to a core principle of REST. Most architectures expose an API that allows consumers to affect the state of the application only indirectly. To understand the implications of your actions as a consumer, you then have—at best—to be very familiar with the application architecture and be aware that you are making a lot of assumptions. The state mechanics are hidden from you. You cannot explicitly move the application from one state to another, nor can you directly observe the transition(s) that have taken place.

A primary goal of Representational State Transfer is to make the application’s state machine unambiguous by exposing representations of application resources that have embedded within them URIs pertinent to the resource. In this way a consumer of a RESTful service can discover the current state of the resource, the mechanisms to affect change in the resource, and other resources related to the current resource in the application’s state. This is what is known as Hypertext as the Engine of Application State (HatEoAS).

HatEoAS implies a model where all of your important resources are represented by unique URIs and all important state changes are done by interacting with representations sent to or retrieved from those URIs. Most people first approaching REST view it in terms of opposing other architectural “styles” such as SOA or get mired in implementation immediately and begin contrasting their understanding of REST over HTTP against WS-*. Another common problem is reducing the ethos of REST to “RPC is bad” and “we don’t need all that complexity, we have HTTP” (see REST is better than WS-*). These views are commonplace because REST is being promulgated as a better solution for many types of applications on the Web.

The specifics of how REST works over HTTP are beyond the scope of this article, and the subject of a lot of debate, but, since a lot of uses of POST seem very much like RPC-style invocations, people have a knee-jerk reaction that POST is not RESTful. By now you know this is not the case, but let’s hear from the experts.

From Fielding:

POST only becomes an issue when it is used in a situation for which some other method is ideally suited: e.g., retrieval of information that should be a representation of some resource (GET), complete replacement of a representation (PUT) […]

Stu Charlton’s design guidelines say nearly the same thing:

The problem with POST is when we abuse it by having it perform things that are more expressive in one of the other methods. GET being the obvious one that needs no hypermedia description. For the other methods, a good design guideline is that you MUST not break the general contract of the HTTP method you choose -- but you SHOULD describe the specific intent of that method in hypermedia.

Fallacy #3 REST is better than WS-*

In fact, Fielding’s thesis does address many of the problems and advantages of various network-based architectural styles, but no where does he claim REST is the one ring to rule them all. In his aforementioned blog post Fielding says (emphasis my own),

[…]there are plenty of information systems that can be designed using the REST architectural style and gain the associated benefits. Managing cloud instances is certainly one of those applications for which REST is a good fit[…]

From his thesis, here is the definition of the REST architectural style.

REST consists of a set of architectural constraints chosen for the properties they induce on candidate architectures. […] [It] is an abstraction of the architectural elements within a distributed hypermedia system. […] It encompasses the fundamental constraints upon components, connectors, and data that define the basis of the Web architecture, and thus the essence of its behavior as a network-based application.

So, the associated benefits are induced by constraints that collectively are referred to as the REST architectural style. The benefits are myriad, and many of the constraints are are recognizable in how the web works. Section #5 of the thesis is concise and readable, and I encourage the reader to internalize it.

The salient point here is that REST is not a protocol; it’s not even an architecture. REST is an architectural style! By understanding its constraints and benefits, we can make informed decisions about its applicability to our problem domain and appropriation of technologies. Comparing REST to the WS-* suite of protocols is comparing apples to oranges, though there are those who strongly argue the benefits of REST and HTTP over SOAP.

What, Not How & Why, Not When

noreply@blogger.com (Christopher) — Sat, 27 Jun 2009 15:28:00 +0000

It occurred to me this morning that many software development principles seem to emerge from the rigorous application of the following principle:

Your architecture and code should make What & Why explicit without specifying How & When.

What, Not How
It is well known that we should prefer declarative over imperative code. By observing the Law of Demeter, we are in fact forced to create declarative, What, semantics in our interfaces since we can't get at the How, the imperative constructs. The Single-Responsibility Principle tends to force us to factor out the How into other classes, leaving us to consume other classes with What semantics. Further, the Interface Segregation Principle requires us to explicity segregate the interfaces our clients consume based on What they are trying to accomplish; if our focus was How, such segregation would be less of a concern. Event-Driven Architectures (EDA) are another example of What, Not How. Whereas the SOLID principles operate at the class design level of abstraction, EDA is concerned with system-level architecture. In an Event-Drive Architecture, we explicitly model happenings in the domain. Rather than coupling the site of the happening to a specific party designating for dealing with that happening, we create an Event and use reliabile messaging and subscription schemes to allow one or many services to handle it. In other words, instead of specifying How to deal with a happening at the site that generates it, we explicitly model What happened and let other parties worry about How to deal with it.
Why, Not When

Pareto, Zipf, Heap: The 80-20 Rule, Language, and Diminishing Returns

noreply@blogger.com (Christopher) — Fri, 26 Jun 2009 18:33:00 +0000

Please consider this a sort of layman’s disambiguation page.

The classic “80-20 rule” refers to a Pareto distribution. The thin distribution of the 20% is the subject of Chris Anderson’s “The Long Tail”. Originally, the Pareto distribution referred to the fact that 20% of the people control 80% of the wealth, but it has turned up in many other contexts.

A Zipf’s Law is about rankings and frequency. The second item’s frequency will be half of the first; the third’s frequency will be half the second, and so on. The “half” may be some other factor, but it remains constant in the distribution; the rank is inversely proportional to the frequency. The item in Zipf’s Law is a word and its frequency is its appearance in a corpus of English text. However, Zipf’s Law holds for texts generated from a fixed alphabet by picking letters randomly with a uniform distribution.

Heaps’ Law is about diminishing returns. It has an exact formula, but generally it says that the more you look into a text, the fewer new discoveries of words you’ll find. So, as you read through the text it takes longer and longer to find new words in the text. Heaps’ Law applied to the general case where the “words” are just classifiers of some collection of things. So, it could be applied to the nationality of a collection of people; you’d have to gather more and more people from a random sampling to get a representative from all countries.

The implications of these laws in various contexts are the subject of much interesting study and postulation.

Value Objects and Value Domains

noreply@blogger.com (Christopher) — Wed, 17 Jun 2009 01:29:00 +0000

I’ve written relatively extensively on the topic of replacing enum constructs with classes, so I won’t rehash the topic. Instead, I’d like to introduce you to some code I’ve written that enables you to create finite domains of Value Objects in C#. Please see my two previous posts on the subject to learn more about the benefits of this approach. To see how the Value Object semantics and making a finite domain a first class concept in the pattern improves the approach, read on.

First, we need some definitions. We are taking the concept of a Value Object from Eric Evans’ book “Domain Driven Design” p.99:

When you care only about the attributes of an element of the model, classify it as a Value Object. Make it express the meaning of the attributes it conveys and give it related functionality. Treat the Value Object as immutable. Don’t give it any identity […] The attributes that make up a Value Object should form a conceptual whole.

An example here is useful. Consider modeling the domain of a book publisher. At some point you need to capture all the different formats of books: A4, B, Pinched Crown, etc. The attributes of width, height, unit of measure, and name would go into your model. But, any instance of your A4 Value Object should be completely interchangeable from any other A4. And, it goes without saying that you can’t change the width or height or any other attribute of A4.

All of the different formats of books belong to a Value Domain. According to WordNet, a domain (we are using the mathematical notion) is:

the set of values of the independent variable for which a function is defined

The functional complement of a domain is the range of the function; i.e. domain is what you can put in, the range is what you can expect to get out. I like calling this concept in my approach a domain instead of a set, because it neatly captures a key benefit. When we are writing code. We want to declare our parameters as being a proper member of domain of values, instead of just primitive types or strings.

Now we’re ready to dive into the implementation. Let’s begin with the end in mind. I want to write a function, say, that let’s me search for a document with a particular format about an arbitrary topic.

void SearchDocs(DocFormat docFormat, string topic)

Ok, so we could create a base class or an interface called DocFormat and create Word doc, PDF, etc. that inherit from or implement DocFormat. Easy. But, SearchDocs has to be able to handle all current and future implementations of DocFormat; it must not violate the Liskov substitution principle. What if the repository or search algorithm depends on the what the doc format actually is? Also, we’d have a subclass of DocFormat to write for every document type, and we’d have to do a lot of work to remove object identity, since your instance of PDF is not the same as my instance of PDF. And, don’t forget to make the whole thing immutable. [Note: I know this is a contrived example with well-established OOP solutions that don’t require LSP violation. Work with me here. :)]

Clearly we have a lot of work to do to make our Value Objects a reality. It’s not impossible, though, and a quick ~~Bing~~ Google turns up a couple of investigations and approaches. Jimmy Bogard’s approach gave me a clue that I needed to get it working. What I wanted was a base type, ValueObject, that I could inherit from and get the Value Object semantics described in Evans.

Jimmy’s approach used a self-referencing open constructed type to allow the ValueObject base class to do all the work of providing Value Object semantics. This base class uses dynamic reflection to determine what properties to use in the derived class to do equality comparisons (an approach nominally improved upon here). He saw his approach as having a single fundamental flaw; it only worked for the first level of inheritance, i.e. the first descendent from ValueObject.

For my purposes—creating a bounded, finite domain of Value Objects to replace enum-type classes--this is not a flaw. Substantively, all that remains to do is introduce the concept of the the Value Domain into Jimmy’s approach and put the Value Objects in it. Because I wanted to use these Value Domains throughout the enterprise, I baked WCF support into my approach. Further, because the Value Domain is defined a priori, I didn’t have to play with object identity; I could simply look the value up in the domain. (It took a little out-of-the-box thinking to get that to work transparently.) Finally, I wanted it to be trivially easy to create these Value Domains, so I created a snippet for use in Visual Studio.

Here’s an example of Value Domain and Value Objects implementation:

[DataContract]
public sealed class DocFormats : ValueObject<DocFormats.DocFormat, string, DocFormats>.Values<DocFormats>
{
    private DocFormats()
    {
        Word = Add("Word");
        PDF = Add("PDF");
    }

    [DataMember]
    public readonly BindingType Word, PDF;

    [Serializable]
    public sealed class DocFormat : ValueObject<DocFormat, string, DocFormats>
    {
        private DocFormat(string v) : base(v) { }
    }
}

DocFormats is the Value Domain. DocFormat is the type of the Value Object. String is the underlying type of the values, but the pattern supports anything that implements IEquatable and IComparable. Methods can accept DocFormats.DocFormat as a parameter and only Word and PDF will be valid. Code can specify those values through a Singleton accessor: DocFormats.Instance.PDF. You’ll notice that the only constructor is private; the Singleton implementation is in the base value domain base class (ValueObject<…>.Values<…>).

// our new method interface
void SearchDocs(DocFormats.DocFormat docFormat, string topic)
{
    // referencing an individual value
    if(DocFormats.Instance.Word == docFormat)
    {
        //...
    }
}

Above you’ll note that the Value Object type definition (subclass of ValueObject<…>) is nested inside of the Value Domain. Doing that groups the two together syntactically in a very natural way (FooTypes.FooType); the entire domain of values is contained in one place. That locality makes the snippet to produce them cohesive too. [Note: I’ve included the snippet XML at the end of this post.]

Interestingly, the underlying implementation necessarily inverts this nesting; the Value Domain base class is nested in the Value Object base class. That allows the Value Domain Singleton to create instances of Value Objects. I only had to resort to reflection in order to allow the Value Domain base class to provide the Singleton implementation. Inversion of Control containers like Unity and Castle Windsor do this kind of reflection all the time, and it’s cheap since .NET 2.0.

Without further ado, here’s the base classes implementation.

using System;
using System.Collections.Generic;
using System.Reflection;

[Serializable]
public abstract class ValueObject<T, TValue, TValues> : IEquatable<T>, IComparable, IComparable<T>
    where T : ValueObject<T, TValue, TValues>
    where TValue : IEquatable<TValue>, IComparable<TValue>
    where TValues : ValueObject<T, TValue, TValues>.Values<TValues>
{
    /// <summary>
    /// This is the encapsulated value.
    /// </summary>
    public readonly TValue Value;
    protected ValueObject(TValue value)
    {
        Value = value;
    }

    #region equality
    public override bool Equals(object other)
    {
        return other != null && other is T && Equals(other as T);
    }

    public override int GetHashCode()
    {
        // TODO provide an efficient implementation
        // http://www.dotnetjunkies.com/weblog/tim.weaver/archive/2005/04/04/62285.aspx
        return Value.GetHashCode();
    }

    public bool Equals(T other)
    {
        return other != null && Value.Equals(other.Value);
    }

    public static bool operator ==(ValueObject<T, TValue, TValues> x, ValueObject<T, TValue, TValues> y)
    {
        // pointing to same heap location
        if (ReferenceEquals(x, y)) return true;

        // both references are null
        if (null == (object)(x ?? y)) return true;

        // auto-boxed LHS is not null
        if ((object)x != null)
            return x.Equals(y);

        return false;
    }

    public static bool operator !=(ValueObject<T, TValue, TValues> x, ValueObject<T, TValue, TValues> y)
    {
        return !(x == y);
    }
    #endregion

    public static implicit operator TValue(ValueObject<T, TValue, TValues> obj)
    {
        return obj.Value;
    }

    public static implicit operator ValueObject<T, TValue, TValues>(TValue val)
    {
        T valueObject;
        if (Values<TValues>.Instance.TryGetValue(val, out valueObject))
            return valueObject;

        throw new InvalidCastException(String.Format("{0} cannot be converted", val));
    }

    public override string ToString()
    {
        return Value.ToString();
    }

    #region comparison

    public int CompareTo(T other)
    {
        return Value.CompareTo(other);
    }

    public int CompareTo(object obj)
    {
        if (null == obj)
            throw new ArgumentNullException();

        if (obj is T)
            return Value.CompareTo((obj as T).Value);

        throw new ArgumentException(String.Format("Must be of type {0}", typeof(T)));
    }

    #endregion

    [Serializable]
    public abstract class Values<TDomain> where TDomain : Values<TDomain>
    {
        [NonSerialized]
        protected readonly Dictionary<TValue, T> _values = new Dictionary<TValue, T>();

        private void Add(T valueObject)
        {
            _values.Add(valueObject.Value, valueObject);
        }

        protected T Add(TValue val)
        {
            var valueObject = typeof(T).InvokeMember(typeof(T).Name,
                           BindingFlags.CreateInstance | BindingFlags.Instance |
                           BindingFlags.NonPublic, null, null, new object[] { val }) as T;
            Add(valueObject);
            return valueObject;
        }

        public bool TryGetValue(TValue value, out T valueObject)
        {
            return _values.TryGetValue(value, out valueObject);
        }

        public bool Contains(T valueObject)
        {
            return _values.ContainsValue(valueObject);
        }

        static volatile TDomain _instance;
        static readonly object Lock = new object();
        public static TDomain Instance
        {
            get
            {
                if (_instance == null)
                    lock (Lock)
                    {
                        if (_instance == null)
                            _instance = typeof(TDomain)
                                .InvokeMember(typeof(TDomain).Name,
                                                  BindingFlags.CreateInstance |
                                                  BindingFlags.Instance |
                                                  BindingFlags.NonPublic, null, null, null) as TDomain;
                    }
                return _instance;
            }
        }
    }
}

I’d love to hear your feedback. This is approach is not intended to support unbounded Value Domains, such as the canonical example of Address. It is meant for the enums-as-classes problem, i.e. finite, bounded Value Domains.

ValueObject.snippet

<?xml version="1.0" encoding="utf-8" ?>
<CodeSnippets  xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
    <CodeSnippet Format="1.0.0">
        <Header>
            <Title>ValueOjbect</Title>
            <Shortcut>vo</Shortcut>
            <Description>Code snippet for ValueObject and domain</Description>
            <Author>Christopher Atkins</Author>
            <SnippetTypes>
                <SnippetType>Expansion</SnippetType>
            </SnippetTypes>
        </Header>
        <Snippet>
            <Declarations>
                <Literal>
                    <ID>domain</ID>
                    <ToolTip>Value domain name</ToolTip>
                    <Default>MyValues</Default>
                </Literal>
        <Literal>
          <ID>value</ID>
          <ToolTip>ValueObject Class name</ToolTip>
          <Default>MyValueObject</Default>
        </Literal>
        <Literal>
          <ID>type</ID>
          <ToolTip>Value Type</ToolTip>
          <Default>string</Default>
        </Literal>
            </Declarations>
            <Code Language="csharp">
        <![CDATA[    
    [DataContract]
    public sealed class $domain$ : ValueObject<$domain$.$value$, $type$, $domain$>.Values<$domain$>
    {
        private $domain$()
        {
            Value1 = Add(String.Empty);
        }

        [DataMember]
        public readonly $value$ Value1;

        [Serializable]
        public sealed class $value$ : ValueObject<$value$, $type$, $domain$>
        {
            private $value$($type$ v) : base(v) { }
        }
    }
]]>
            </Code>
        </Snippet>
    </CodeSnippet>
</CodeSnippets>

Google Wave

noreply@blogger.com (Christopher) — Thu, 28 May 2009 20:57:00 +0000

Upon the day mankind's children ask
Who it was made their world intelligible,
Those who set about the grand task
of creating the Wave will be eligible.

For never will they have occasion to think
how to create discourse, share knowledge,
Wonder about the universe and link
Without the this wonderful prodigy.

Like hieroglyphs in the tombs of Kings,
eee-may-uhls voy-s'-may-uhls eye-ems and tweets
will serious study to the curious bring,
to be shared in Waves while ancestors sleep.

How is it the first step of a journey
Can put the past so far behind thee?

Connascence: The Underlying Principle of OO Design?

noreply@blogger.com (Christopher) — Mon, 25 May 2009 17:34:00 +0000

This is a great talk at a Ruby conference by Jim Weirich about his attempt to frame all object-oriented design (OOD) principles as special cases of an underlying principle called “connascence”. Connascence is a term co-opted by Meilir Page-Jones in the ‘90s for use in OOD; below is the definition from his book with Larry Constantine entitled, “Fundamentals of Object-Oriented Design in UML” (page 214):

Connascence between two software elements A and B means either

that you can postulate some change to A that would require B to be changed (or at least carefully checked) in order to perserve overall correctness, or

that you can postulate some change that would require both A and B to be changed together in order to preserve overall correctness.

WolframAlpha: A New Kind of Site

noreply@blogger.com (Christopher) — Thu, 21 May 2009 15:24:00 +0000

TechCrunch called Google Squared the imminent Cain to WolframAlpha’s Abel. Dare Obsanajo warns Wikipedia to beware the ides of March, casting WolframAlpha as Brutus. But, I would cast WolframAlpha in quite a different role: Hamlet.

If you’ve not used WolframAlpha, head over there come back once you’ve exhausted its novelty. Go ahead, I’ll wait.

So, now you know why they call it a “computational knowledge engine” whose mission it is to “make the world’s knowledge computable”. Ignoring, for the present, the interesting epistemological discussion viz. the validity of that mission, let’s instead talk about why you might use it.

If you are looking for something, go to Google. This is not a search engine.

If you are looking to mine the web for hard data, be patient, Google Squared will be your guide (when it is baked).

If you would like to learn about a particular topic, Wikipedia stands ready to help you begin.

If you want to apply your existing domain knowledge to posing interesting questions about a wide variety of topics, if you can phrase such questions as nominal computations, then go to WolframAlpha, though your attempts might be frustrated, e.g. it fails to compute the following “annual energy consumption of the average American * projected worldwide population in 2020.”

In other words for 98% of the world, WolframAlpha is simply a curiosity. For the other 2%, it’s only useful as a way to experiment with such questions, since the rigor required of formal academia is not satisfied by simply saying, “WolframAlpha said so.”

To understand WolframAlpha’s raison d'être, you have to understand NKS: Stephen Wolfram’s “New Kind of Science”. To understand NKS you can either go read the book or trust what I’m about to say. At its core, the claim it makes to novelty is based on the notion that all phenomena can be viewed as computations, and thus real science can be done by exploring the “universe” of possible computations. Of course the only apparatus sufficient for doing this “new” science is Wolfram’s own Mathematica program, a program originally created by Dr. Wolfram in a single summer. Twenty or so years later after leaving academia to build the company that develops and sells Mathematica, Wolfram brought forth the the 1,200+ page tome that is NKS.

Wolfram is no lightweight; we’re talking about one of those few people in the world with the intellectual capacity and training to do modern quantum mechanics at age 17—when it comes to mathematics he is the real McCoy. But, very few seriously look at NKS as being fundamentally new, and no few academics treat Wolfram with vitriol and ire due to his claim of novelty. We all—it is universally agreed—stand upon the shoulders of giants. Further, many argue that NKS contributes nothing new to the existing corpus of mathematics or science. Here are some notes for the dramaturg:

The NKS book was self-published by Wolfram-Media
Wolfram opens the book with a statement of his childhood dream to “know everything”
NKS is the culmination of twenty years of work outside of academia
The precipitating event that put him on that path was his not being able to understand the pattern generated by a cellular automata (simple computer program) he’d written

My personal belief is that the cognitive dissonance created by having not contributed to science in any recognized, significant way over twenty years, in the face of soaring hubris born out of his prodigious intellect and early summiting of some of the highest peaks of academia, forces Dr. Wolfram to eschew—even denigrate—the trappings of mainstream academia and embrace his self-created role of the father of a new kind of science. But, hey, I don’t know the guy; and it goes without saying that I’m criticizing Michael Jordan’s cross-over. Maybe it will take twenty years for everyone else to get it; if it is new, it's nascent, and you have to walk before you can crawl.

He may be an egoist, but he has excellent taste. I think he’d make Edward Tufte proud.

What WolframAlpha owes its life to is the attempt to make NKS immediately relevant in a roundabout way. Remember, everything—everything—is simply a computation. Another concept that is critical to understanding WolframAlpha from NKS is “computational equivalence”; essentially this is the reason why NKS doesn’t permit predicting the future: to do that you would need a computer the equivalent of our universe. Reality, you see, is simply the current result of the continuous computation being performed by the fabric of our universe. (As strange as that may sound, it is not dissimilar from the beliefs of proponents of the much vaunted string theories of the universe.)

Since we don’t have a computer the size of the world, we can’t calculate everything in reality. What we can do, though, is examine the current results of the computation, in the form of data that can be collected and mined and extruded by domain experts into an symbolic ontology that is computable by Mathematica. We can then run computations with these synthetic ontologies, because they can be related via formal ontology of units we have created throughout human history. To what end? Well, I suppose that depends on the answers you get.

I hope by now you understand why it is called WolframAlpha. And, for those lovers of the theater who haven’t yet guessed, here is the cast of characters.

Hamlet: WolframAlpha
Fortinbras: Google Squared
Gertrude: Capitalism
Ophelia: Wikipedia
Claudius: Academia

I think it is obvious who plays the role of the murdered king. Ok, I've surely stretched the metaphor a bit too thin, but I really like the notion that these kinds of current events are manifestations of the same archetypes described in our great literature. I think Wolfram would like it too, but I have no doubt his protagonist wouldn't be from one of Shakespeare's tragedies.

Microsoft TechEd: Day 0

noreply@blogger.com (Christopher) — Mon, 11 May 2009 05:05:00 +0000

It’s the evening before the official start of the Microsoft’s annual IT conference, TechEd. In 2009 we find ourselves in sunny, yet cool, Los Angeles. I couldn’t be happier with the weather and the hotel, but so far the conference sucks.

Why—or, more appropriately, how can I say it sucks when the conference hasn’t begun? Easy, go to msteched.com and attempt to build a schedule. Well, you have to be signed in with Windows Live and a registered attendee I believe, but if you could and did you would quickly discover a rather pathetic fail on the part of the conference planners. The session builder is garbage. You’ll spend the majority time watching this animation, since they’ve not seemed to master the partial page update without updating the entire 670K+ page weight. Seriously, I’d rather look at the source and see and XML Data Island than wait for the entire page to reload every time I updated my schedule.

Aesthetically, it isn’t bad, the site I mean, but the session builder is garbage. The session builder for Web 2.0 Expo at least displayed all the tracks and timeslots in a calendar-like fashion, so you could make your decision by sight and rather quickly.

But, you know, if the content is there, if the sessions are just awesome, who cares about some clunky, hacked-together conference website? Don’t judge a book by its cover, right? So, what are my options for tomorrow’s 11am timeslot? Well, the first keynote is this one.

KEY01 Moving Forward Together: The Potential of IT Innovation

Presenter: Bill Veghte

Mon 5/11 | 10:00 AM-11:30 AM | West Hall A

In today's economic environment, your company is faced with unprecedented pressures to reduce costs and drive operating efficiencies. At the same time, the demands on IT to deliver more connected services and greater flexibility continue to grow. With the upcoming release of Windows 7, Windows Server 2008 R2, and Exchange "14," Microsoft helps IT organizations better meet these competing demands. Join Bill Veghte, Senior Vice President of Windows Business, as we explore how these technologies combine to give you the tools and resources to better manage your infrastructure--from back-end services through client-side experiences, and the network in between.

Doesn’t exactly inspire. But, never fear, there is an alternative!

PAN59 Agile: A Process or an Excuse?

Presenters: Richard Campbell, Stephen Forte, Chris Menegay, Joel Semeniuk

Mon 5/11 | 11:00 AM-12:00 PM | 501C

Over the last few years, the community at large has created a number of agile development styles; Scrum, XP, and more are there for you and your team to choose. However, is agile really a process? On the other hand, is it an excuse to avoid accountability and proper development techniques? Come to this interactive session to see what Chris, Steve, and Joel have to say, and, if you are up for it, share your opinion.

Seriously, I’m not making this up. I came to Los Angeles for this?

The Coming Apocalypse of your "Friends"

noreply@blogger.com (Christopher) — Thu, 09 Apr 2009 17:52:00 +0000

What's a friend on MySpace, Facebook, and Orkut? If you have five hundred friends, are they really friends? These are the main reasons why I have not, to this point, joined any of those sites. I don't have many friends, because I just can't give a lot of people the energy needed to maintain a true, lasting friendship.

What does this have to do with technology? Well, Facebook Connect and Google FriendConnect are two apis, with many more to come, that allow you to take your social graph with you. So now, instead of just being a bunch of people that post something they copy and pasted onto your "wall" at major holidays, they are now people who are going to affect recommendations you get on other websites.

Tell me, do you want five hundred of your "closest" friends opinions, tastes, and web surfing habits to have a direct effect on your web experience?

Web 2.0 Expo Day 2

noreply@blogger.com (Christopher) — Fri, 03 Apr 2009 19:10:00 +0000

This morning started with keynotes, though there didn't seem to be a theme beyond "here is who we could get to come and talk." The sole exception was the very first speaker, Douglas Rushkoff, was fantastic. I'm really excited about his new book, Life Inc. His main theses were that corporations were not created to allow competition and artificial currency was not

Nokia's CEO showed us his vision for ten years from now. Wearable computers? Wow, now that's innovative. He got off on some weird metaphysical rant about projecting our consciousness into the 'net. What he really means is a constant data stream of my location, mood, and random thoughts. The only interesting thing he mentioned was geolocation through photography. I really feel like that is an idea whose time has come.

Next I attended a session that discussed the relative merits of building directly for the iPhone or the web, and the conclusion was use PhoneGap to do both. it had some interesting points in making the case to stay web-based, but none of them were very convincing. He attacked the following five arguments for going native:

Performance--the recent "fast javascript" movement combined with paring down the page bloat that has occurred in recent years
Offline Usage--there is HTML 5 (and thus embedded mySQL support) in iPhone since v2.0
Findability--there are now 25K+ apps in the AppStore
Device Capabilities (GPS, camera, accelerometer, etc.)--the GPS capabilities are "opening up", and PhoneGap let's you go native
Monetization--4% of devices get turned down, people use iPhone apps like tissue paper, you have to sell your app for $0.99 to get any traction

Some valid points there, but it's ironic that the solution proffered is to start web-based and enhance to native.

Microsoft Bizspark were the underwriters for Launch Pad at Web 2.0 Expo. There were five companies who presented:

PhoneGap
80legs
zeaLOG
Dub (at DubMeNow)
Bantam (Bantam Networks)

Honestly, I wish I had gone to a different session. I already knew about PhoneGap from the ten other times it was mentioned this week. What they are doing at 80legs is really cool, but I'm not sure about its applicability. They've made something that is really hard to do really cheap, but they've not made it easy. That is, you still have to write Java code. I'm more excited about what people are doing with it, a sure sign of a platform play. I hope they get acquired and rewarded for their hard work. One last thing, there was maybe a hundred people in the room. Maybe.

I went to a talk from the guys at EngineYard. Pretty good talk, but really centered on the implications of systems management in the could-era. I really enjoyed the talk, pretty fun. The gave it in this paired presenter style where one would pick up where the other left off. Nothing terrible prescient or relevant to me, but they host a lot of really awesome new companies, like github.

Werner Vogels

noreply@blogger.com (Christopher) — Thu, 02 Apr 2009 01:17:00 +0000

Super cool guy. He's one of those super geeks that's past the point where he feels it necessary to get dragged into details but is totally upbeat. It's good to be the king, right? Perhaps my biggest surprise was to learn just how much Amazon views itself as a technology company. Amazon's retail experience is just a customer of AWS. Riiiight. I find that hard to believe, but he claims that Amazon.com the retail site is not even the biggest customer of AWS. Whoa.

My big takeaway from his talk and comments afterward is that only companies that really, really must scale to incredible extremes should build their applications for AWS, i.e. bake in use of SimpleDB, SQS, etc. What he said to me was, "run your Linux infrastructure on EC2 so you can leave if you don't like us." So, really, build great SOA systems and use AWS as a virtualization provider. He had a lot of great principles in his talk for building scalable systems, including:

Autonomy: individual components make decisions only based on local information
Asynchrony: Make progress under all circumstances
Controlled Concurrency: operations are designed such that limmited or no concurrency control is required
Controlled Parallelism: use fully decentralized (p2p) techniques to remove bottlenecks
Decentralize: Remove dependencies
Decompose: Break up into more granular services
Failure Tolerant: Failure is a normal part of operation
Local Responsibility for Consistency: Similar to Autonomy, don't look elsewhere for consistent state
Simplicity: pare away functionality until you cannot
Symmetry: all nodes can do any function in the system

Some other interesting bits were that the Amazon Homepage is produced by 200-300 services. Every service at Amazon is developed and operated by the same team. There are about 500-600 services/teams. Elasticity is both shrinking AND growing on demand.

Geolocation: The new W3C API

noreply@blogger.com (Christopher) — Thu, 02 Apr 2009 01:04:00 +0000

A thought leader in geolocation from the company that created Loki gave a talk about geolocation on the web. His first recommendation was to build your applications to adopt latitude and longitude as the basic unit of location. He then went on to talk about all the other ways location can be represented. For example, the names of business, location descriptions, planar areas (rather than points) on a map, etc. These are generally much more welcome in the UX than map coordinates.

Some ways of getting local businesses are:

Yahoo! Local Search API
Yelp
Localeze

The skinny on geolocation for the web right now is that it relies on browser plug-ins or extensions. The nice thing is that a W3C working group put together a standard for accessing the geolocation capabilities of the browser from Javascript. It's quite easy to use, if not widely available.

One interesting stat is the precision one can expect from the various means of geolocation.

GPS can be accurate to within 10m for commercial applications
Wifi (database lookup and triangulation from SSIDs and signal strength) can be as good as 20m up to 80m
Cell towers are up around 1000m
IP address based schemes are wildly inaccurate and limited to city/region precision

Loki.com/how and Google Gears utilize hybrid approaches to do geolocation, obviously, to balance speed of acquisition, device capability, desire precision, etc.

Web Developer Tools from Web 2.0

noreply@blogger.com (Christopher) — Thu, 02 Apr 2009 00:49:00 +0000

This was by far the best presentation I saw today. A couple of Mozilla guys gave this great talk really about the past, present, and future of the web developer experience. I'm really buzzed about the near future of HTML 5, "fast javascript", and the "web worker" model, enabling the kind of interactivity available on desktop applications.

The introduced a lot of tools, mostly around Firebug and its extensions. I wasn't familiar with the unit testing stuff in that space: Code Coverage and FireUnit. Some of the more interesting tools were the CSS tools: YUI CSS Grid Builder, blueprint, and the recently announced Microsoft SuperPreview.

They also mentioned some "future" tools like Bespin and Thunderhead. Bespin is wonderful, a source code editor on the web, with concurrent-versioning system support (git now and later SVN?). I really feel like this is boostrapping the web, you can begin to think of creating the web ON the web. Avi Bryant has already plugged Seaside into Bespin. Thunderhead is a prototype for marrying grid-layouts with the HTML 5 canvas. They are talking about doing an "Open Tools Directory".

One thing they mentioned that was only tagentially related to their talk was PhoneGap. This let's HTML/Javascript developers create native mobile phone applications (iPhone, Android, and Blackberrry are supported to different extents at this time). Atlas, which let's you write native Cocoa (Mac OS) applications in Javascript (their Objective J) was given an excited nod, too.

Why Scala?

noreply@blogger.com (Christopher) — Thu, 02 Apr 2009 00:32:00 +0000

I'm trying to catch up with blogging about the sessions I've attended this first day of the Web 2.0 Expo. The second session I attended today was entitled, "Why Scala?" Presented by a fellow from Twitter, it was essentially a discussion on their adoption of Scala from their initial appraisal of the technology landscape through the pilot project successes to their company-wide embrace of Scala.

Despite not having any major investment in Java code, the JVM platform gave them access to the myriad Java libraries already out there, as well as the ability to do things like hydrate JSON as a JVM object and reason about it naturally within Scala. Given that they were looking for a language with a great concurrency story, this appears to be the number one reason for choosing Scala, that it is a JVM language written by people who really understand the JVM internals. Some of the other reasons put forth were:

Actor model--like Erlang the primary programming paradigm of Scala is independent workers that share no state and pass messages
Immutability--with built-in immutable data structures and the Actor model, Scala heavily encourages immutability, but doesn't force it, meaning you can take advantage of mutability when it is more expressive or performant
Type inference--yay, strong typing AND pretty code
First-class functions
Traits--not real clear on what this is, I think the Erlang/OTP equivalent would be behaviors
Pattern matching--this is similar to what Erlang does, but isn't limited to tuples or other terms, i.e. you can match objects
XML Literals & Query methods baked into the language
Case Classes--these sound like structs, maybe message types?

The "bad" thing about Scala is that it forces you to learn a bit more about the JVM than perhaps you were inclined to learn, and it is very complex. There seems to be quite a community evolving around Scala, and the mainstreaam web framework is called Lift.

Identity Wars and Joseph Smarr

noreply@blogger.com (Christopher) — Wed, 01 Apr 2009 23:49:00 +0000

I remember Mr. Smarr's talk about OpenID and OAuth from a couple of years ago. I got the impression that his biggest fear was that Facebook would always be a walled garden. For reasons I don't quite understand, perhaps a sort of social consciousness (no pun intended), Facebook has opened their platform up, albeit in a limited and proprietary way.

Fortunately, there are companies like Google and JanRain who are hiding the differences between the Open Stack and Facebook's APIs. First, let's have a look at the Open Stack proper.

OpenID for authentication
OAuth for authorization
XRD a service discovery protocol
Portable Contacts (self-explanatory)
Open Social

JanRain has RPX, and Google has FriendConnect, so using the OpenID/OAuth stuff is easy without really knowing a lot. What is needed is a way to marry the existing authentication stacks of all the common web platforms (ASP.NET, PHP, etc.) with the Open Stack, I think.

For more information, here are some blogs:

TheSocialWeb.tv
JosephSmarr.com
TheRealMcCrea.com

SEO: From Soup to Nuts--Web 2.0 Expo Workshop

noreply@blogger.com (Christopher) — Wed, 01 Apr 2009 16:22:00 +0000

It's workshop day in the first and only pre-conference day of Web 2.0 Expo San Francisco. Among the first sessions of the day, I opted to attend the presentation given by Stephan Spencer of Netconcepts: "SEO: From Soup to Nuts."

His presentation was organized around his "three pillars of SEO": Content, Architecture, and Links. His SEO practice is very data driven as evidenced by his egregious use of statistics. Among the highlights of those statistics:

1.25 to 1.5 times more conversions to PPC versus "natural" (normal search result click-through)
86% of search engine clicks are natural
47% click-through on first Google result falls to 10% on second, and half of the first natural for the first paid
Double click through rate for short URLs according to Marketing Sherpa

It definitely isn't all about statistics in the SEO game, though. In fact, it seemed as if getting hard data about efficacy was the biggest and enduring challenge. There are some hard-and-fast techniques to employ, thankfully. Page titles, using 301s, nofollow links, canonical tags, there should be only one url for any given content, etc., as well as some great tools (both free and pay) including:

SEOmoz.org's LinkScape
SEObrowser.com
Google Web Optimizer
SIFR
Adobe Search Engine SDK
Yahoo! Site Explorer

There were also a lot of surprises, at least to me:

Search result rankings can vary from city to city (of searcher)
Underscores do not count as word separators to Google
YouTube doesn't give link juice (nofollow)
Digg users do not buy anything
User generated content can get you so-called "long tail terms"

One thing I wondered, looking at this image that shows the distribution of eye movement on the Google results page, is what are people actually looking for one Google. They aren't looking for knowledge, but information, a gateway to knowledge, perhaps.

Web 2.0 Expo travel

noreply@blogger.com (Christopher) — Sun, 29 Mar 2009 16:48:00 +0000

We have just been incredibly fortunate this far. I last flew commercial soon after 9/11, and the experience was harsh to say the least. Anotinio Gramsci once wrote that the downfall of a secular democracy was the continuous surrendering of freedoms in exchange for protection from our fellow citizens. Our travel experience to SF this weekend has taught me how much the human spirit can shine despite and perhaps paradoxically because of difficult circumstance. We have been graced by the goodwill of so many of our fellow citizens that I am tacitly aware of Gramsci's error if unable to put words to it.

Today has been incredible, but I must save my emotive prose for another time.

Sex-Software Simile

noreply@blogger.com (Christopher) — Thu, 19 Mar 2009 02:35:00 +0000

Using software vendors' technology demos as the metric for your software development is like measuring your sexual prowess by watching porn films: accurate for edge cases but ultimately not relevant.

Why ORM? Why Cloud Computing?

noreply@blogger.com (Christopher) — Fri, 13 Mar 2009 17:51:00 +0000

I think it was Fred Brooks that once wrote that someone will inevitably look at any software system and ask, "how did we get here?" And, the answer is invariably, "one logical choice at a time." Rather than answer the questions, "Why ORM?" and "Why Cloud Computing?", I will endeavor to elucidate those logical choices.

The monolithic database model (MDM) has served the IT sector very well for about fifty years. I will explicitly define it as a model of software development where myriad applications are integrated through a shared database, or--more accurately--more than one user interface is provided to a database. In this model the database itself is where business processes and domain modeling exist. Enterprises often expanded these databases to include all aspects of the business, or perhaps a few databases integrated via ETL, until the number of objects exceeded any one person's capacity to understand the system. EDI, data warehousing, and data marts are all extensions of the (MDM) for dealing with M&A, e-biz partners, etc. Given a large number of well-trained database professionals with rigorous communication and documentation requirements, the monolithic database model is efficacious and expedient.

As object-oriented programming techniques became more well-known, developers began modeling the domain and business process using advanced general purpose programming languages like Lisp, Smalltalk, C++, etc. They used object databases to persist these models and all was good and productive. Unfortunately, few developers grok those technologies, and even fewer have a mastery of the techniques needed to use them well, so it didn't catch on. Perhaps the biggest impediment to adoption was the success of the MDM. The MDM was working and understood. The deficiencies of the model were insufficient to move IT development en masse to the object crowd.

Still, a lot of software was being written outside of IT. Embedded developers loved object programming and had no need to store loads of data. So, the hardcore programmers--those that relish writing life support systems, flight control systems, nuclear power plant control systems, etc.--were exclusively "object guys". Meanwhile, Sun Microsystems was building a runtime for embedded systems to simplify programming across hardware--Java. A 4GL, Java had all the object-oriented bells and whistles, and Sun had written runtimes for Unix, Solaris, and even Windows! These runtimes came bundled with AWT, allowing developers to nominally "write once, run anywhere."

Suddenly there was the WWW. I say suddenly because even Bill Gates once purportedly remarked that it was irrelevant. As IT understood the implications of Metcalfe's Law for the Internet, it became the elephant in every boardroom. No single company in the world wanted to be a loser in the new, connected economy. All IT decisions were tempered by the Internet revolution.

Now the cohesive, insular world of the MDM was really looking problematic. Still, that's where the data was, and ultimately the Internet was about access to information. So, every IT vendor that wanted to compete was pitching platforms that claimed to do one central task better than anyone else: turn relational data into web pages. These platforms were either backed by scripting or 4GL, and DBI, JDBC, ODBC, ADO, etc., in all their versions and iterations were simply libraries used by the object guys to get at the data.

Concurrently, universities had been turning out software developers who started writing C++ or Java in their freshman year, graduating to "real" object languages in subsequent years. The worldwide demand for IT developers skyrocketed, and technical colleges met the challenge with programs designed to get people into the market with the minimal set of skills to create web applications. At this point the technologies for building web applications were infantile relative to RDBMS technologies. The result was a lot of really bad developers developing really bad applications, slowly.

The good developers, the object guys with strong Lisp kung fu, really resented having to interface with databases--to go from their object model to a data model. IT programmers oft complained of the inordinate amount of time they spent move data in and out of databases. Architects started designing systems built around messaging again, calling them web services this time, and the canon said that these messages were serialization of object state. So smart people started writing libraries for interfacing with databases in a tacit fashion, attempting to abstract away the "implementation details" of data storage and retrieval: object-relational mappers (ORM). The "real" model of business entities and processes, after all, were their objects.

Now, the old IT systems in DB2 and Cobol were "legacy" systems to be tolerated until they could eventually be re-written. New IT initiatives would set out in their own silo (usually an application server), with their own persistence engines that utilized ORM, and integrate with the legacy systems via message-oriented middleware (MOM): Biztalk, SOA, ESB, etc. Vendors were happy because MOM was expensive; object-guys were happy because their jobs now matched up with their education; and business owners were hopefully optimistic because mainframe vendors all operate on an annuity model, and the owners' hope was to escape from a world of multi-million dollar support contracts.

Lo, the MDM guys sneered, since the whole enterprise--the business itself--was still built upon their systems, and every attempt to re-write their systems was an incredibly expensive failure.

Business owners were getting pretty angry, too. All these application servers needed lots of new hardware, and the new servers needed to be partitioned by firewalls, and they needed new database servers too, since RDBMS was still the persistence engine of choice, and of course all of this needed fail-over and clustering. Meanwhile, what the developers were producing wasn't sufficient to run the entire business on, so they now had to maintain two systems in parallel, putting increased strain on the middleware servers. Further, the developer's velocity was slow, since everything had to be integrated, and years and years of process refinements implicit in the MDM had to be re-imagined and re-discovered. This integration stuff was expensive.

Again, though, not all software was being written in IT shops. There were companies building applications hosted on web servers that were available on-demand, so called Application Service Providers (ASP). These companies didn't have any legacy systems and drew the smartest object guys. Many of them were wildly successful, but when the dot-com bubble burst, the idea that a company that you relied upon for mission critical systems could just disappear caused many IT shops to reject the idea out-of-hand. The ASPs that survived were those companies that offered important but not "mission-critical" (like email, production data management, etc.) services, such as sales force automation or marketing support. Another class of ASPs that won were those that offered hosted services to SME customers who could not or chose not to afford the sunk costs of providing their own infrastructure.

In the U.S., capital was king; the financial markets were providing great returns and due to foreign investment and interest rate cuts the cost of capital was low. Businesses were now faced with enormous capital expenditures from their IT operations during a time when capital investments were the most prudent choice, but no one was willing to give up the very real productivity gains that had been made steadily in the last decade. The solution to the dilemma was to defer expenditures, to lease.

At the same time, the business owner's frustration with the lack of agility of their IT operations peaked. The costs were high, the pace of development was slow, the requirements gathering and definition process was pain-staking, and the failure rate was abominable. The maintenance costs alone for all the manifold servers, languages, and platforms was choking the life out of new business opportunities before they could be explored.

So, the market itself demanded cloud-computing. Rather than buying the infrastructure and paying to provision it, they wanted to "pay as you go." Elastic demand on IT systems meant provisioning for the worst-possible scenario; cloud-computing meant scaling-up (and down) on demand. Rather than having to pay for and maintain application servers, database servers, load-balancers, etc., they could just write the app and see if it sticks.

Yea, though I walk through the valley of the shadow of integration, I shall fear no SQL.

The problem of integration remains. No cloud platform fits any enterprise's IT needs completely, so now the challenge is how to integrate a world where the web application server platform is considered a legacy. Microsoft's solution is to position all ASP.NET development as "cloud" development, making it easy to keep the application on-premise or move it to the cloud (Azure). Ironically, the major impediment to this approach is the persistence engine: the database.

Moving a database that fully exploits the RDBMS platform to the cloud is non-trivial. In other words, developers that wrote stored procedures, utilized event brokers or extended stored procedures, created ETL jobs, made it unlikely that they can move their applications to Azure. If they instead had only used pure ORM (LINQ2SQL), this could be done mechanically.

This property of not violating the ORM abstraction, namely the ease with which the backing data store can be mechanically replaced, is the key reason why ORM advocates promulgate the principle that the application should never accept a dependency on the data store. In other words, no stored procedures allowed. The Entity Data Model is an attempt to abstract the universality of the data model--arguably the best feature of MDM--away from the persistent storage engine(s), in order to ensure the portability of the data model in the enterprise and beyond, i.e. to the cloud.