The guys at Codehaus are moving the continuous integration servers. I must say that I had a WTF-moment when this build failure notification dropped in my inbox: I find it amusing that the build failed because “all the tests passed”. The real reason was that it was unable to find Maven on the build server…

Last week I wrote a short anecdote about getting big, upfront design wrong. The next chapter is on quick and dirty fixes. You know, those hacks we do to “make something work”. These often come about after frenetic debugging session, where we debug a system into existence. Smacking a piece of drywall on top of the existing drywall is a real-world example.

Quick and dirty fixes often have side-effects and so does this. Notice that a drawer is missing? Its because it won’t fit when the wall is 1 centimeter, or about half an inch, thicker.

Fixes like these need to be done over, taking (almost) twice as long as doing it right the first time around.

OK, I know I'm late to the party here, but I've started to upgrade from Web 1.0 to Web 2.0. I've even got myself a Twitter profile. You guys can keep an eye on what I'm wasting time on at http://twitter.com/anoras.

Before .NET 3.5 was released the choice of whether you should choose Visual Basic or C# as your programming language was more or less a matter of taste. With the first incarnations of these languages, you could do virtually the same things with both. Visual Basic 9.0 introduced quite a few new interesting features, and the support for XML literals is my favorite. For those unfamiliar with Visual Basic, XML literals allows you to work with XML DOMs using the all so familiar markup syntax. For instance you this code will build a DOM.

Dim myDOM = <SomeElement> _
                <SomeOtherElement withAnAttribute="42"> _
                    The time is <%= DateTime.Now %> _
                </SomeOtherElement> _
            </SomeElement>

Notice that you can have inline code similar to what you’re familiar with from ASP.NET. You can also use XML literals as a replacement for DOM methods to reference elements within the DOM.

Dim someDocument = XDocument.Load("somedocument.xml")
XElement someOtherElement = someDocument.<SomeElement>.<SomeOtherElement>

XML literals can be used in combination with LINQ and other Visual Basic features, and is a powerful tool when working with XML.

A couple of weeks ago I had a discussion with a team who were planning to use IBM’s Process Server and ESB to produce direct marketing campaigns from Excel documents with assorted information like customer names, addresses, key account managers and so forth. Their idea was to write an adapter for the ESB to be able to consume Excel spreadsheets as data sources, convert these into Service Data Objects and use the Process Server’s mapping abilities to transform the Excel documents into XML that can be passed on to our document production service. Can you imagine how loud my “YANGI”-scream was? This was the perfect moment to exploit Visual Basic’s XML literals to fight enterpriceyness, so I decided to spend a few hours to build a light-weight solution for this. The application accepts an Excel spreadsheet and row template, and produces an XML document with the result. The row template is written using Visual Basic’s XML literals and looks similar to this:

<Letter>
    <FirstName><%= row("First Name") %></FirstName>
    <LastName><%= row("Last Name") %></LastName>
    <HasSameLastNameAsSpouse>
        <=% IIf (row("Last Name") = row("Spouse's Last Name"),"Yes","No") %>
    </HasSameLastNameAsSpouse><
    <!-- And so on... -->
</Letter>

I took me about 45 minutes to write the application, but there was one small problem. The row templates wouldn’t compile using Visual Basic’s CodeDomProvider - even if the generated code built perfectly using the Visual Basic compiler. It turned out that the reason for this was that even when using .NET 3.5, the CodeDomProviders default to using version 2.0 of the compilers. If you’re targeting Visual Basic 9.0, you’ll have to specify this when you create a new CodeDomProvider. The MSDN documentation does not mention this at all, and the many ways of getting hold of a CodeDomProvider makes this even more confusing.

CodeDomProvider vbProvider = CodeDomProvider.CreateProvider("vb");

When you use the factory, you can only specify which language you’re targeting, so we’ll have to instantiate the provider via its constructor. The constructors for the VBCodeProvider and the CSCodeProvider accept an undocumented IDictionary as its argument. It turns out that you can pass configuration options in this dictionary. So to create a .NET 3.5 VBCodeProvider you’ll need to this:

CodeDomProvider provider = new VBCodeProvider(
    new Dictionary<string, string>{{"CompilerVersion","v3.5"}});

This is also the case if you’re looking to use the CodeDOM with C# 3.0 code. The only difference is that you’ll need to create a CSCodeProvider rather than the Visual Basic one. Below is the complete code for my super simple “template engine”.

var className = Guid.NewGuid().ToString("n");
var src = GetTemplate(className);            
CodeDomProvider provider = new VBCodeProvider(
    new Dictionary<string, string>{{"CompilerVersion","v3.5"}});
    var compilerParameters=new CompilerParameters {GenerateInMemory = true};
    var compilerResults = provider.CompileAssemblyFromSource(compilerParameters, src);
    if (compilerResults.Errors.HasErrors)
    {
        throw new CompilationException(compilerResults, src);
    }
return Activator.CreateInstance(compilerResults.CompiledAssembly.GetType(className));

Even if it is confusing, it’s still very easy to compile code using these new language features. Just remember that you’ll need to specify some magic strings to get the compiler to apply it’s magic.

Last November my family and I move into a brand new apartment. Since we’ve moved in, we’ve had builders coming in to fix things over and over again. Today they started to “refactor” the wiring in our kitchen. Maybe I should get this picture framed as a reminder of not to trust Big Design Upfront (which is the way they build stuff).

The carpenter has a rather agile aporach to his work, and he’ll be tearing down parts of the kitchen to replace the entire wall tomorrow. Luckily, I’m not paying for this.

My last post on Java generics and the Repository pattern got a bit of interest. Judging from the feedback I got, I feel the need to elaborate on the Inversion of Control part of this. As some readers pointed out, Google’s Guice container employes super type tokens to support generics to some extent. The IoC example I gave in my previous post can be implemented with Guice by binding a TypeLiteral of the interface to a concrete implementation of that interface.

public class RepositoriesModule implements Module {
   public void configure(Binder binder) {
       binder.bind(new TypeLiteral<Repository<Product>>() {}).to(ProductRepository.class);
   }
}

You can resolve an implementation of a Repository by asking the injector for an instance of the same TypeLiteral that instance is bound to.

Injector injector = Guice.createInjector(new RepositoriesModule());
Repository<Product> repository = injector.getInstance(Key.get(new TypeLiteral<Repository<Product>>() {}));

However, this does provide a solution similar to how we can inject generic repositories using something like the Windsor container for .NET. With Windsor, you can bind a generic interface, say IRepository, to a generic implementation of that interface such as ConcreteRepository : IRepository. This allows us to resolve a useable repository instance like this:

WindsorContainer container = new WindsorContainer();
IRepository<Product> repository = container.Resolve<IRepository<Product>>();

One thing to note here is that there is no need to have concrete implementations for every domain object (Product, Order, Customer and similar), a generic implementation of the ConcreteRepository is sufficient because .NET has bona fide generics implemented in the Common Language Runtime (CLR) and the CLR will create a new bound type of the generic class at runtime. This is even the case if we use reflection to create the instance.

The Guice container allows us to specify providers to which the creation of a dependency will be delegated. However, this provider is bound to the type arguments for the TypeLiteral and wild card type arguments cannot be used because the compiler is unable to infer the runtime type of such an argument. As a result we would need to bind all the TypeLiterals to different concrete implementations or different providers to support this pattern with Guice. This is a show stopper because it takes away the pattern’s flexibility. To exemplify the concept, I changed my naïve IoC container from my previous post to support this pattern using Guice’s TypeLiterals. Here is an example of binding the Repository interface to a provider which will create the typed instances via the RepositoryFactory shown in my previous post. (If you haven’t read that post, now is a good time.)

@Test
public void canRegisterAnOpenGenericInterfaceAndResolveItsImplementationViaABoundInterface()
{
    // Register the open generic interface and bind it to a provider.
    IoC.register(new TypeLiteral<Repository>() {},new Provider<Repository>() {
        @SuppressWarnings({"unchecked"})
        public Repository get(TypeLiteral<? extends Repository> type) {
            ParameterizedType pt = (ParameterizedType) type.getType();
            return RepositoryFactory.create((Class<?>) pt.getActualTypeArguments()[0]);
        }
    });
    // Resolve an instance of a bound interface.
    Repository<Order> repository = IoC.resolve(new TypeLiteral<Repository<Order>>() {});
    Assert.assertTrue(repository instanceof AbstractRepository);
    Assert.assertSame(Order.class,repository.getEntityClass());
}

In this example we first register the open generic interface, akin to IRepository<> in .NET, to a provider for that interface. The provider implementation has to perform some unchecked operations to allow this to work, but this is not really something to worry about. When we resolve the instance, we pass a fully bound TypeLiteral to the container. The provider is passed this TypeLiteral as an argument, and the type argument is extracted from it. In this example this will be a TypeLiteral>. Since the provider is bound to the open generic type Repository, the extracted type argument will be Order. This provides us with enough type information to create a strongly type instance of the AbstractRepository via the RepositoryFactory class.

We also need to be able to distinguish between generic implementations and concrete ones. So lets bring in the ProductRepository class from my previous post.

@Test
public void boundServicesHavePrecedenceOverOpenGenericServices()
{
    IoC.register(new TypeLiteral<Repository>() {},new Provider<Repository>() {
        @SuppressWarnings({"unchecked"})
        public Repository get(TypeLiteral<? extends Repository> type) {
            ParameterizedType pt = (ParameterizedType) type.getType();
            return RepositoryFactory.create((Class<?>) pt.getActualTypeArguments()[0]);
        }
    });
    IoC.register(new TypeLiteral<Repository<Product>>() {},ProductRepository.class);

    Repository<Product> repository = IoC.resolve(new TypeLiteral<Repository<Product>>() {});
    Assert.assertTrue(repository instanceof ProductRepository);
    Assert.assertSame(Product.class, repository.getEntityClass());
}

This is basically the same test case over, but with one important difference. In this example two services are registered in the container. First the provider for the open generic Repository interface is registered, and then the concrete implementation for the bound Repository is registered. When we resolve the service for TypeLiteral> we expect to get an instance of ProductRepository back, rather than a runtime generated instance of the AbstractRepository.

Below is the entire implementation of the “container” used in these tests.

public class IoC {
    static Map<TypeLiteral, Provider> registry = new HashMap<TypeLiteral, Provider>();
    public static <T> void register(TypeLiteral<T> service, Provider<T> provider) {
        registry.put(service, provider);
    }
    public static <T> void register(TypeLiteral<T> service, Class<? extends T> impl) {
        registry.put(service, new ConcreteProvider(impl));
    }
    @SuppressWarnings({"unchecked"})
    public static <T> T resolve(TypeLiteral<T> type) {
        if (registry.containsKey(type)) {
            return (T) registry.get(type).get(type);
        } else {
            Type c = type.getRawType();
            while (c != Object.class) {
                ManualTypeLiteral<T> manualTypeLiteral = new ManualTypeLiteral<T>(c);
                if (registry.containsKey(manualTypeLiteral)) {
                    return (T) registry.get(manualTypeLiteral).get(type);
                }
                c = c.getClass().getSuperclass();
            }
            throw new RuntimeException("Not found");
        }
    }
    private static class ManualTypeLiteral<T> extends TypeLiteral<T> {
        private ManualTypeLiteral(Type type) {
            super(type);
        }
    }
    private static class ConcreteProvider<T> implements Provider {
        private final Class<? extends T> impl;
        public ConcreteProvider(Class<? extends T> impl) {
            this.impl = impl;
        }
        public T get(TypeLiteral type) {
            try {
                return impl.getConstructor().newInstance();
            } catch (Exception e) {
                throw new RuntimeException(e);
            }
        }
    }
}

The implementation of the container has been simplified to make the example more clear, and is by no means a real container ready for production use. However, I think it should be fairly easy to add this kind of behavior to Guice, and I also believe that it should be well worth while because this kind of flexiblity opens the doors for a whole lot of usage patterns that we are just starting to understand the power of within the .NET community.

Whenever I stray off the beaten path of Java generics, I instantly miss C#’s generics implementation. Earlier today, Java’s type erasure erased a few good hours of productivity whilst I was doing a spike on bringing the IRepository<T> experience to Java. In C# you can get the class of any generic type argument in a straight forward manner.

public void DoStuff(T thing) 
{    
    Type thingsType = typeof(T);
}

Because of Java’s type erasure, things aren’t as simple. The Java equivalent of this C# example won’t compile.

public <T> void doStuff(T thing) {
    Class thingsType = T.class;
}

Still, all is not lost. Even if you’ve been told otherwise, some information about generic type arguments is available at runtime. While the JVM doesn’t track the type arguments for an instance of a generic class, it actually does this for subclasses of that generic class. To work around this limitation you can add the required behavior to infer a class’ type arguments to an abstract base class. Ian Robertson has a good write up about this at Artima.Since many of the features of any repository are common, regardless of its final implementation, my initial design already had an abstract repository class and a repository interface, so using the “extend and infer” technique described in Ian’s post was OK. Basically, this allows you to do this:

public abstract class AbstractRepository<T> implements Repository<T> {
    private Class entityClass;
    public final Class getEntityClass() {
        if (entityClass == null) {
            ReflectionHelper reflectionHelper = new ReflectionHelper();
            entityClass = reflectionHelper.getTypeArguments(
                            AbstractRepository.class,getClass()
                          ).get(0);
        }
        return entityClass;
    }
    void setEntityClass(Class entityClass) {
        this.entityClass = entityClass;
    }
    // Implementations of common repository features like
    // load, save, delete and so on go here...
}

public class ProductRepository extends AbstractRepository<Product> {}

Since ProductRepository specifically extends the AbstractRepository, the type information will be available at runtime and the following test will pass.

Repository<Product> repository = new ProductRepository();
Class inferredEntityClass = repository.getEntityClass();
Assert.assertSame(Product.class,inferredEntityClass);

But apart form implementing an abstract class, the ProductRepository serves no real purpose. In a real-life scenario, you would probably add some operations specific to Product entities to the repository, but there is no need to do this. So, I’d really like to have a way to create instances of a repository for any entity without creating a separate implementation of the repository for each entity class.Because of the trick we’re using to infer type arguments, we cannot turn the AbstractRepository into a concrete class, but we can extend it with a concrete generic class.

public class ConcreteRepository<T> extends AbstractRepository<T> {  }

Ayende uses this approach to support different object relational mappers in his implementation of this pattern for .NET. However, if we try to use this approach with Java, type erasure comes in and screw things up again.

Repository<Product> repository = new ConcreteRepository<Product>();
Class inferredEntityClass = repository.getEntityClass();
// This assertion fails because the type argument (Product) has been
// erased and replaced with java.lang.Object...
Assert.assertSame(Product.class,inferredEntityClass);

To work around this, we can stick with our abstract repository and employ Neil Gafter’s “gadget” aka Super Type Tokens.

Repository<Product> repository = new AbstractRepository<Product>() {};
// Did you notice this method in the AbstractRepository<T> class?
repository.setEntityClass(Product.class);
Class inferredEntityClass = repository.getEntityClass();
Assert.assertSame(Product.class,inferredEntityClass);

This works, but it makes the client code ugly. So you probably should cover the ugliness with some factory “makeup”.

public static <T> Repository<T> create(Class<? extends T> entityClass) {
    AbstractRepository<T> repository = new AbstractRepository<T>() {};
    repository.setEntityClass(entityClass);
    return repository;
}

Now we can instantiate generic repositories this way…

Repository<Product> repository = RepositoryFactory.create(Product.class);
Class inferredEntityClass = repository.getEntityClass();
Assert.assertSame(Product.class,inferredEntityClass);

…and IMHO, that looks quite alright.

Having a good implementation of a generic repository in place opens the doors to creating adaptive domain models using the patterns and design techniques Ayende and Udi have been writing quite a lot about lately. The missing piece to the puzzle is better generics support from the dependency injection containers available for Java. I’m a bit surprised that there aren’t (AFIK) any containers available that support generics in a similar fashion to what Spring.NET or Windsor do. To get this piece in place, I actually started something I promised myself that I’d never do again - I started to build my own inversion of control framework. Nothing is ready to be made public yet, but I’ll provide you with some examples of its very limited features.You can register components by specifying its interface and implementation like this (No XML configuration for me, baby!)…

IoC.register(Repository.class, ProductRepository.class);

…and you can resolve a dependency at a later stage by specifying the interface and its generic type argument(s).

Repository<Product> repository = IoC.resolve(Repository.class,Product.class);
Assert.assertTrue(repository instanceof ProductRepository);

Before you start screaming about the static methods, I’ll inform you that the IoC class is just an accessor that makes the IoC framework readily available. This is an approach I’ve been using for quite some time, and I recommend trying it for yourself. Its very convenient.

So what do you guys think? Do we need another dependency injection framework? (No worries, I’m just doing this to support some demo code I’m writing and I have no intentions making it a fully fledged framework at the time being.)

One of the challenges I have experienced when giving talks or blogging about domain specific languages is that developers are a little reluctant to writing code in languages they are unfamiliar with. This holds true even if the DSL in question is an external DSL based on commonly available languages such as Boo, Ruby, Groovy or Scala.

Since I also develop using both .NET and Java, another common challenge is that these languages aren’t generally available on all platforms. This is a concern because you can easily lock your self to a platform based on how you choose to implement your DSLs. After having many discussions around this topic with luminaries in both the Java and .NET communities, I have concluded that unless we can address the challenges with making our DSLs true cross platform tools, we are introducing more complexity than we’re doing good.

One of the reasons I’ve been a bit quite for the last few weeks is that I’ve started a new project which will be available under the Apache 2.0 license to address these issues and I’m very glad to introduce the Adaptive Platform Runtime for Interoperable DSLs – April!

To enable true interoperability and at the same time make it easy to understand for all developers April is based on familiar XML concepts. Below is an example of one of the business rule example from my recent talks on external DSLs expressed with April.

One key thing to notice is that April uses its own XSD based type system. This allows us to achieve platform portability and interoperability by abstracting away the individual languages own type systems. To allow customized DSLs, April also lets you redefine and extend the language using common XML representations. This is how the “When” keyword has been introduced into the language used above:

 <keyword>
  <name>when</name>
  <is_alias_for>
    <keyword>
      <name>
        <xmlns>urn:apl/core/language/keywords/conditional/if</xmlns>
      </name>
    </keyword>
  </is_alias_for>
  <semantics>
    <ast>
      <keyword>
        <name>when</name>
        <expression>
          <consisting_of>
            <parts>
              <part>
                <order>0</order>
                <expression>
                  <allow_any>true</allow_any>
                </expression>
              </part>
              <part>
                <order>1</order>
                <operators>
                  <operator>
                    <name>
                      <xmlns>urn:apl/core/language/operator/equals</xmlns>
                    </name>
                  </operator>
                  <operator>
                    <name>
                      <xmlns>urn:apl/core/language/operator/greater_than</xmlns>
                    </name>
                  </operator>
                  <operator>
                    <name>
                      <xmlns>urn:apl/core/language/operator/less_than</xmlns>
                    </name>
                  </operator>
                </operators>
              </part>
              <part>
                <order>2</order>
                <expression>
                  <allow_any>true</allow_any>
                </expression>
              </part>
            </parts>
          </consisting_of>
        </expression>
      </keyword>
      <keyword>
        <name>then</name>
        <!-- Eluded for brevety -->
      </keyword>
    </ast>
  </semantics>
</keyword>


Since everything is XML based you can use your experiences from writing everything form web.config files to Spring configurations to extend, customize and develop using April.

April’s core audience is the domain experts who’ll use the DSLs you develop to customize the business rules of any April enabled application. To reduce the probability of bugs occurring within these DSLs, you can easily turn of language features in the DSL context configuration.

 <dsl_context>
  <language_features>
    <keyword>
      <name>new</name>
      <enabled>false</enabled>
    </keyword>
    <keyword>
      <name>print</name>
      <enabled>true</enabled>
    </keyword>
    <keyword>
      <name>for</name>
      <enabled>false</enabled>
    </keyword>
  </language_features>
</dsl_context>

Because of its simplicity and the use of common XML knowledge, my vision is that April will be the killer app that will enable developers to DSL enabling their applications today.

The source code will be made available at The Codehaus later today. I encourage everyone interested in DSLs to start playing around with it, provide feedback or join the project. Let the DSL revolution begin!

I’m not sure if its because Java developers have a flurry of good IDEs to choose from, but IDE pimping is a rare hobby among Java developers. However, since I’m a polyglot developing stuff in a range of languages I enjoy having a familiar, nice look and feel across all the tools I use. When I swapped my Windows for a Mac, I instantly fell in love with TextMate’s celebrated Vibrant Ink theme. (Fun fact: This blog post is written in TextMate, using Vibrant Ink). I use John Lam’s port of the theme with Visual Studio, but whenever I wrote Java code I was left out in the cold with IntelliJ IDEAs plain old black, blue, red and green on white theme. As you can imagine, this was unbearable for someone used to using tricked out OSes and development tools, so I had to create a port myself.

Volia! Here is the Vibrant Ink theme for IDEA in glorious technicolor. The above screenshot showcases the various features, and (luckily) regular code seldom gets this colorful.

If you fancy pimping your IDEA with a touch of cool, you can grab a jar file with my color scheme from “Is your IDE Hot or Not?” or directly from here.

Gansta! Yo’ve gots ta git this themizzle, it tha real shiznits.
Snoop Doggy Dog

“Programming is best regarded as the process of creating works of literature, which are meant to be read… so we ought to address them to people, not to machines.”

The last few days there has been a vibrant discussion on which computer science books that deserve its place on the top 10 bookshelf over at The Norwegian JUG. A title that quickly sprung to mind was Pragmatic Programmer: From Journeyman to Master by Dave Thomas and Andy Hunt. This is one of the few books that you can read from cover to cover, over and over again and pick up new things every time. Because I love this book, it feels a little scary to pick a discussion with one of the authors, but Dave’s latest blog post on domains specific languages provoked me to do this.

In his blog post, Dave makes the point that something isn’t necessarily a DSL just because it reads like English. I agree with him on this, but this does not imply that English can’t be used to describe business rules. In my talk on developing domain specific languages with .NET, I used an example from the insurance industry as a foundation for the alternative approaches for implementing a DSL. Insurance is a business I know well since I work for one of the largest insurance companies in the Nordic region. Just like Dave points out, our domain specialists have a common understanding of the meaning of the different terms in their jargon. In Domain Driven Design, Eric Evans describes this as the ubiquitous language. In my experience, having a shared understanding of the jargon between business and technical team members and using this jargon to model the software is crucial before on can introduce domain specific languages into the development process.

My example is a very narrow slice of the business rules for adjusting the risk of a car insurance quote. Still it is very representative for this kind of application. We begin our tale with a simple user story;

If we write our requirements in this manner, a natural progression is to write our functional tests in a behavior driven style.

Scenario(“Customer is an inexperienced driver”);
    Given(“The policy’s premium is”, 1000, delegate(double premium)
    {
        policy = new Policy();
        policy.Premium = premium; 
    });
    Given(“The customer’s age is”, 24, delegate(int age)
    {
        policy.Holder = new Customer();
        policy.Holder.Age = age; 
    });
    When(“A quote for an insurance is issued”, delegate()
    {
        quote = policy.IssueQuote();
    });
    Then(“The policy’s premium should be increased by percentage”, 5, delegate(double percentage)
    {
        Assert.AreEqual(policy.Premium *= 1 + (5 / 100), quote.Premium);
    });

This code is written using Joe Oscampo’s NUnit.Behave which I claim is an internal DSL, written in C#, for functional testing. Spec frameworks like NUnit.Behave is one of the things Dave “picks on” in his post with a valid argument that the domain experts using this DSL are programmers and that writing a specification using the such a framework is programming. This is true, but I think Dave misses a key value of using this approach; even if the specification is littered with C# enforced dots, brackets and parenthesis it is very similar to the free-form user story the spec is derived from. This helps us follow a thread through from the user story through to the specification. If the framework didn’t enforce a grammatical structure, this would be much harder to achieve. Another thing with Dave’s problem with the host language shining through and hindering him in writing straight forward sentences can be turned into a benefit for fluent interfaces. Obie Fernadez once used the Starbucks jargon to show how to write an internal DSL with Ruby. I’ve used his example to show how one can implement a fluent interface with C#. This example is a variety of the specification pattern, and it is very helpful for object creation. Imagine that you have a number of different coffee drinks such as espresso, latte and capuchino which all extend a common base class. There are different ways to prepare each of these drinks and hence you need to know what to put into them when you make them. Using traditional object oriented programming, you would first have to figure out which drinks are available by looking up the classes extending the Drink base class, and then you would need to identify the specific options for each drink by looking at its constructor overloads. When using an internal DSL to create Drink instance, we can use the language to show the developer which options are available and since almost every IDE has some form of IntelliSense, these options will be very visible to the developer.

The value of using this approach is that it is much more readable than regular code and it gives the users (who are developers) an expressive API. Another thing Dave complains about is the use of noise words, like articles, in such DSLs. In this one I’m using the indefinite article “a”. The only reason this is there is that it serves as a starting point for out sentence, and I agree with Dave that there is no real reason to allow users to insert words like “a” or “the” in the middle of a “sentence” to make it feel more like proper English. Still I’m obsessed with aesthetics and if an definite article was the only thing missing before an API look perfect, I’d probably add it just to make it look better.

Allowing noise words in the language brings us to the extreme variety the DSL implementations I show during the talk - the plain English business rule. When use use user stories for our requirements and behavior driven development for testing, why can’t we just state our business rules like this:

When the policy holder's age is less than 25, increase the policy's premium by 5%.

This is code and it is compiled using Microsoft’s Dynamic Language Runtime and runs on the CLR. On thing to note is that this language is very specific, and has a limited set of operations. There is no way you can write “Hello World” with this language. Mandating a strict, limited grammar is a way to work around the ambiguities of natural language. Of course we can’t be too strict, so we’ll also have to allow things like:

When the policy's exposure has a burglar alarm, decrease the policy's selfrisk by 200.

If we translate this to plain old C#, we’ll end up with this:

// First example...
if (policy.holder.age < 25)
{
    policy.premium *= 1.05;
}

// Second...
if (policy.exposure.has("a burglar alarm"))
{
    policy.selfrisk -= 200;
}

“When” is a keyword, “the policy holder’s age” is a reference, “is less than” is an operator, “25” is a constant and so forth. All that is required is to parse it, emit and AST for the DLR and run it. Nothing is different from how general purpose languages work, which isn’t strange because even if these are true English sentences, writing them is programming.

The great thing about having things that are as readable as these code snippets is that it makes it easier to sit down with domain experts and use actual, running code as the basis for discussion. That said, I’m fully agree that the use of English doesn’t make things a DSL. Focusing on the domain model and developing a language that only takes into account the problems within that domain however does. If it makes sense to model your language around English language constructs, do it! This will make it easier for both developers and business people to understand business related code. It takes a lot of effort to roll your own language as shown above, so from an economical perspective, you are better of piggybacking on another language. The Boo based variety of the same example looks like this.

when policy.holder.age < 25:
    increasePremiumByPercentage 5

It might be broken English, but it serves its purpose and it is most definitely a DSL.

Last week I was awarded the MSDN Guru award at the Heroes happen {here} event in Oslo. The videos from the show have been posted and you can watch me accepting the award, giving the obligatory thank you speech and getting interview below. If you can’t understand what’s being said, it’s because its in Norwegian…

Expect for the interview, which is a little embarrassing to watch, it turned out quite alright IMHO.

After giving my talk on language oriented development with .NET for the Oslo chapter of the Norwegian .NET User Group I was approached by one of the attendants who pointed out that I had excellent taste in notebooks. Most people though he was referring to my shiny MacBook Pro, but he had this slide in mind…

The notebook is an Moleskine notebook, the kind used by great artists like Ernest Hemmingway, Pablo Picasso and computer programmer Anders Norås. I always carry one of these in my pocket and I constantly jot down various thoughts, ideas and similar. Some pearls from the last few days;

I ride the bus to work every day, but I’m not reusing the bus - I’m using it! However, whenever I tip the bus over and set fire to it to build a barricade to keep the IBM sales force at bay, I’m reusing the bus. -Johannes Brodwall during a discussion we had on the myths of “reuse”.

I’ve also got a magic quadrant with the axes Good <-> Evil & Pretty <-> Ugly which I drew while discussing folklore with a friend who works in marketing on the way to work. This one will find its way into one of my talks, because it fits so nicely with the whole behavior driven development story. Wait and see…

The thing is that an old fashioned, analogue notebook is one of the best tools you can carry around. I’ve chosen this make because the quality is unprecedented. There are lots of people with strong feelings for Moleskines. There are numerous hacks for them on the web, the books have their own annual exhibition and there are even blogs dedicated to them.The thing is that there is nothing that can compare with the expressive power of a good notebook. Look at these beautiful notes about agile methodologies by ThoughtWorker Josh Evnin:

For more visit his blog.

Tag you’re it! How do you make notes?

Kjell-Sverre Jerijærvi

Jermemy Miller

Johannes Brodwall

Stephan Scmidt

There are always some Java developers who attend whenever I give my .NET DSL talk. This is super cool, and at it makes for some new challenges. The most common one is “How can we do these things with Java”. Since the JavaZone guys have introduced an emerging languages track and extended their call for papers deadline to next month, I figured “porting” the talk to the Java platform would be cool. The downside* is that, until somebody writes “Boo4J”, I have to learn some more “Java” languages to explore the possibilities. I’ve spent a couple of evenings with Scala, and I’m really pleased with what I’ve got so far…

Being used to mainly using imperative languages, I had to learn a couple of new tricks to get this thing running. The first was how one can pass a first-class function as a by-name parameter. This is used for the predicates. The other was how to use currying to make the when function look like a keyword. The cool thing was that this was super duper simple. All in all, less than 20 (!) lines of code was required. Looks like I’m catching the Scala bug too…

*Well, learning new languages isn’t really a downside…

On Thursday I was award the “MSDN Guru” award during the Norwegian Heroes Happen {here} launch event. This was fun, and I just want to thank the people who nominated me for the award. I feel very humble to be the winner among the other nominees, they where all great candidates. By the way, the picture shows a bottle of the specially brewed Heros happen {here} beer. Just too bad Microsoft run out of it early. Still it was a good party! Thanks!

I got these blog recommendations in Google Reader this morning…

…if you recommend this blog to someone who isn’t writing it, that would be even better!