Community Server

WTF: Build Failed: No Failed Tests Found

andersnoras — Wed, 16 Apr 2008 20:47:02 GMT

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…

Reminder: Quick and Dirty Fixes Are Expensive

andersnoras — Tue, 15 Apr 2008 21:35:00 GMT

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.

I'm on Twitter

andersnoras — Tue, 15 Apr 2008 13:58:00 GMT

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.

CodeDomProviders and Compiler Magic

andersnoras — Mon, 14 Apr 2008 12:05:34 GMT

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.

Reminder: Getting BDUF Wrong Is Expensive

andersnoras — Wed, 09 Apr 2008 22:39:40 GMT

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.

More on generics and Inversion of Control

andersnoras — Mon, 07 Apr 2008 13:29:54 GMT

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.

Generics, Inversion of Control and Repository

andersnoras — Thu, 03 Apr 2008 23:32:00 GMT

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.)

A framework for cross platform DSL development

andersnoras — Tue, 01 Apr 2008 10:42:00 GMT

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.


<?xml version="1.0" encoding="utf-8" ?>
<script>
  <statement>
    <when>
      <expression>
        <lhs>
          <reference>
            <to>
              <instance>
                <of_type>
                  <xmlns>http://andersnoras.com/customtypes/customer</xmlns>
                </of_type>
              </instance>
              <named>customer</named>
              <reference>
                <to>
                  <property>
                    <of_type>
                      <xmlns>http://andersnoras.com/primitivetypes/number</xmlns>
                    </of_type>
                  </property>
                  <named>age</named>
                </to>
              </reference>
            </to>
          </reference>
        </lhs>
        <op>&lt;</op>
        <rhs>
          <constant>
            <value>
              <of_type>
                <xmlns>http://andersnoras.com/primitivetypes/number</xmlns>
              </of_type>
              <with_value>25</with_value>
            </value>
          </constant>
        </rhs>
      </expression>
    </when>
    <then>
      <statement>
        <increase>
          <reference>
            <to>
              <instance>
                <of_type>
                  <xmlns>http://andersnoras.com/customtypes/policy</xmlns>
                </of_type>
              </instance>
              <named>policy</named>
              <reference>
                <to>
                  <property>
                    <of_type>
                      <xmlns>http://andersnoras.com/primitivetypes/number</xmlns>
                    </of_type>
                  </property>
                  <named>premium</named>
                </to>
              </reference>
            </to>
          </reference>
          <by>
            <statement>
              <eval>
                <expression>
                  <lhs>
                    <reference>
                      <to>
                        <instance>
                          <of_type>
                            <xmlns>http://andersnoras.com/customtypes/policy</xmlns>
                          </of_type>
                        </instance>
                        <named>policy</named>
                        <reference>
                          <to>
                            <property>
                              <of_type>
                                <xmlns>http://andersnoras.com/primitivetypes/number</xmlns>
                              </of_type>
                            </property>
                            <named>premium</named>
                          </to>
                        </reference>
                      </to>
                    </reference>
                  </lhs>
                  <op>%</op>
                  <rhs>
                    <constant>
                      <value>
                        <of_type>
                          <xmlns>http://andersnoras.com/primitivetypes/number</xmlns>
                        </of_type>
                        <with_value>25</with_value>
                      </value>
                    </constant>
                  </rhs>
                </expression>
              </eval>
            </statement>            
          </by>
        </increase>
      </statement>
    </then>
  </statement>
</script>

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>  </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!

Vibrant Ink for IDEA

andersnoras — Tue, 25 Mar 2008 20:50:24 GMT

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

English as a DSL

andersnoras — Thu, 13 Mar 2008 22:25:10 GMT

“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.”

-Donald Knuth, Literate Programming

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.

Videos from Heroes happen {here}

andersnoras — Wed, 12 Mar 2008 19:57:00 GMT

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.

Notebook Fetish

andersnoras — Mon, 10 Mar 2008 22:22:00 GMT

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

Babysteps in Scala

andersnoras — Mon, 10 Mar 2008 21:11:09 GMT

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…

Hero happend {there}

andersnoras — Sun, 09 Mar 2008 22:26:49 GMT

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!

Thank you Google!

andersnoras — Fri, 29 Feb 2008 07:39:03 GMT

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!

Next Week's Speaking Schedule

andersnoras — Fri, 22 Feb 2008 21:24:59 GMT

Fredrik Kalseth posted a notice about his talk for the Norwegian .NET User Group’s (NNUG) Vestfold’s chapter, so I thought I’d follow in his footsteps to inform the world about my speaking engagements next week. On Tuesday February 26th I’m giving a talk on language oriented programming with .NET for the Oslo chapter of NNUG. Topics to watch out for include fluent interfaces, internal and external DSLs, scripting and Microsoft’s Dynamic Language Runtime. If you show up, be prepared for examples in a variety of languages. Admission is free and we’re serving pizza, beer and non-alcoholic beverages. For more information visit: http://www.nnug.no/Avdelinger/Oslo/Moter/Brukergruppemote-februar-2008/ (in Norwegian). The user group meeting starts at 18:00 and will be held at The Norwegian School of Information Technology (NITH), Schweigaardsgate 14 (At the Oslo central bus station).

On Wednesday 27th I’ll give the same talk in Bergen, but this time around it won’t have the strict .NET focus as I’m speaking for NNUG Bergen and the Norwegian Java User Group’s Bergen chapter. I’ll also give a talk on building internal DSLs with Java, with particular attention on who we’ve built Quaere. This one is free as well, and pizza and beverages will be served. I’ll be having some spare time before catching the night train home, so we’re planning a trip to a local pub for some geek talk afterwards. The meeting will be held at The Norwegian School of Management (BI) in Lars Hilles gt. 15.

Hope to see you either in Oslo or Bergen!

Save Java, Dead or Alive!

andersnoras — Mon, 18 Feb 2008 20:11:59 GMT

Whatever language you write in, your task as a programmer is to do the best you can with the tools at hand. A good programmer can overcome a poor language or a clumsy operating system, but even a great programming environment will not rescue a bad programmer.

Kernighan and Pike

When I attended Richard Öberg’s talk on Qi4J at the Oslo JUG last week, I started thinking about “Rädda Joppe”, a Swedish children’s show that aired in the eighties. The plot was simple, the young Ola manages to lose his favorite teddy bear, Joppe, and has to learn one or two things about the world he lives in to get him back. Whenever Ola loses his precious bear, saving it is the only thing on his mind and he regularly screams “rädda Joppe, död eller levanda” which translates to “save Joppe, dead or alive”.

The ideas behind Qi4J are quite mind boggling, and I strongly believe that composite oriented programming has a bright future amongst domain driven design practitioners. However, I feel that we’re jumping through too many hoops to achieve paradigm shifts with Java. Richard employs a truckload of black belt dynamic proxy and AOP tricks to achieve a sense of dynamically composable objects in Qi4J, JMock achieves elegance through a programming model that is quite different from your textbook Java and my own Quaere project “misuses” static imports and other language features to achieve its goals. Its fun to push a programming language to its limits, but at the same time we could probably achieve the same more elegantly with other languages running atop the JVM - so I got thinking are we trying to save our favorite programming language the same way Ola tries to save Joppe - without any regard to the world outside?

I’ve always been the kind of guy who explores different programming languages, and during the last couple of years I’ve found my self using different languages from my default choice (which is C# if anyone should wonder) more often. Even if you can write FORTRAN in any language, I find that I get the most out of these programming languages when I take the time to learn the ways of the language. Often I find myself using tricks I’ve learned from Ruby in C#, I was unaware that Visual Basic .NET had static imports until I had learned how to exploit it Java and similar. This is my way to avoid stumbling into “the trap of the Sapir-Whorf thesis”. Applied to programming, the Sapir-Whorf thesis postulates that programmers who are skilled in a particular language or paradigm may not have the same skills with another language or paradigm. One trick ponies still only do one trick.

While pushing a language to its limits paves way for refreshing ideas like composite oriented programming, other attempts to “save Java” fall short in my humble opinion. “Angry” Bill Burke’s rant on dynamic languages was a sad read. Most of the arguments aren’t generally applicable, because there is no such thing as “the dynamic language”. Even for those who believe that Ruby might be a good candidate there are lots of different varieties. Speaking of Ruby, it was Cedric Beust’s little Ruby refactoring challenge, which Bill refers to in his rant, that led me to write this post. Cedric is a clever guy, but I wonder if he’s fallen into the Sapir-Whorf trap with this one. Cedric’s question was what to do with f1(o) and f2(o) while renaming C.init! in this Ruby snippet:

def f1(o)
  o.init!
end

def f2(o)
  o.init!
end

class C
  def init!
    puts "Init C"
  end
end

class D
  def init!
    puts "Init D"
  end
end

Cedric is right that there is no way for an automated refactoring tool to determine whether these still should be o.init! or o.init2!, but this isn’t a problem caused by Ruby - it is caused by applying the exact same solution to Ruby as one would do with Java - the core of the Sapir-Whorf thesis. Ruby code can be ambiguous, but this is one of the things that makes the language so powerful. Still we need to take this into account when refactoring Ruby code. A simple solution for Cedric’s problem could be to extract a method for the o.init! call, and let this method make the decision on whether init! or init2! should be invoked.

def f1(o)
  invoke_init(o)
end

def f2(o)
  invoke_init(o)
end

def invoke_init(o)
  if o.is_a? C
    o.init2!
  else
    o.init!
  end
end

This refactoring could actually be done confidently by an IDE and it is only one of many possible solutions to Cedric’s problem.

Java is a great language, and it runs on an even better JVM. In my opinion, this JVM and the broad selection of top notch frameworks is the Java community’s most valuable assets. But the Java language is falling short of some of it’s peers - just compare the development from C# 1.0 to C# 3.0 to Java 1.4 to Java 1.6. Repairing generics, adding closures and so forth will improve Java, but it isn’t the answer to everything. For instance, it won’t make Java a better option for language oriented programming like Bill claims. C# has got almost everything Bill wants to see added to make Java the ultimate language and C# still is too rigid to be a good foundation to build a DSL atop. Ruby or Python are better choices, not to mention Python’s cousin, Boo, which is statically typed and still behaves like a dynamic language. But do remember; When in Rome, do as the romans. These languages aren’t exactly like Java - the have their own cultures, conventions and style.

When Java saw the light of day, talented developers flocked around because it was refreshing and new. The same thing happened with C#, greatly improving the overall quality of applications developed on Microsoft’s platform. Today you’ll find tons of mediocre code written in both Java and C#. The same thing is happening with Ruby, Python and any other dynamic plate de jour. In the end, talented programmers will have come up with new, refreshing ways to design software and I believe that lessons learned through by getting new impulses from other languages and “programming cultures” is a great way to do so.

Le ${favoriteProgrammingLanguage} est mort. Vive le ${favoriteProgrammingLanguage}!

A Jerk in the Land of a Hundred Languages

andersnoras — Mon, 04 Feb 2008 00:00:25 GMT

There is an article in this week’s Economist referring to a paper by Dr. Mark Pagel et al published in the latest edition of Science on (spoken) languages evolving in punctuational bursts. The key point in Dr. Pagel’s research is that evolutionary change happens in sudden jumps separated by long periods of creeping evolution. The article uses the huge differences in the written language of the English writers Geoffery Chaucer and William Shakespeare who lived two centuries apart. You’ve probably read, and understood, Mr. Shakespeare’s writing, but how about Mr. Chaucer?

This frere bosteth that he knoweth helle, And God it woot, that it is litel wonder; Freres and feendes been but lyte asonder. For, pardee, ye han ofte tyme herd telle How that a frere ravyshed was to helle In spirit ones by a visioun

The article got me thinking about DSLs and our hundred language future. Grady Booch once said that “They [programming languages] tell us about the state of software practice, the minds of their inventors and the technical, social, and economic forces that shaped history at the time. They’ll provide the raw material for software archaeologists, historians, and developers to learn what worked, what was brilliant, and what was utter failure.” Through-out my entire career as a software professional C/C++, Java, Visual Basic and C# have been dominant within the industry. Some undercurrents, such as Python, have always been there, and recently these undercurrents have become many and grown stronger. One of the driving forces behind this is the growing interest in domain specific languages, not only custom languages built by developers to tackle narrow business problems, but also more general purpose languages that are suited to address different programming problems. Today’s, and not to mention tomorrow’s, programming profession some what seems to resemble the scene in the 1980s. At this time I was programming BASIC, Pascal and assembly language. Other people I knew where into C or ADA, while most professional programmers did COBOL or Fortran. Anyone working with legacy applications know that it can be rather cumbersome to integrate and evolve applications written in this plethora of languages, so why do I welcome a future of “a hundred languages”? First, todays flurry of languages build on a different fundament than in the eighties. At that time different languages where different platforms, while today most of the languages are available in some form for both Microsoft’s CLR and the Java VM so we won’t be experiencing the same challenges with getting something written in Python to play nice with something written in C#. In fact, I believe that this is a key reason for more and more developers becoming polyglots, having a common platform allows you to use your knowledge of that platform and its frameworks and at the same time choosing the language that is best suited for the task at hand.

So what about the sudden jerks in language evolution? If you look at the two dominant programming languages for the last decade, they are really just different dialects of the C language which has had a strong presence since the mid 70’s. Using Dr. Pagel’s terms, this has been a creeping evolution. If we look at the new kids on the block; languages such as Boo, Groovy or Scala we see languages that absorb the abilities of quite different languages. Both Boo and Groovy have similarities to Python, but at the same time they also have elements of C# or Java in them. Scala builds on Java, but at the same time it brings a little Objective Caml into the mix. Even if it’s not a particularly “new” language, Ruby needs to be mentioned as well. This language has similarities to Python, Perl, Smalltalk and quite a few other languages. These languages abilities to absorb the good from other, well established languages is what makes them interesting choices when the CLR or VM allows us to do so. A common theme for all of these “new” languages is that they are more flexible than their predecessors and this appeals to many programmers. The features that make them so flexible feed back into their ancestors and is fueling change in these as well. Just look at the huge leap C# made in its latest incarnation and the number of proposals for new features in the next version of Java. I think this can very well be a jerk in language evolution.

Will future programs be as hard to read using todays skills as the excerpt from Chaucer’s Summoner’s Tale? I think it depends on what you’ve experienced before. As Steve Yegge put it, one-trick ponies only know one trick. If you’ve only written Java or C# code, you would be searching desperately for if, switch, for and while statements in Erlang.

% This could be a for(int i = 1; i <= 10; i++)
% in Erlang...
f(m,m,F) -> [F(m)]
f(I,m,F) -> [F(I)|f(I+1,m,F)]
f(1,10,F)

On the other hand, you could find developers choosing to use Simula to write a fitting room simulator it might be easier to grasp than the same thing in C#.

Simulation Begin
   Class FittingRoom; Begin
      Ref (Head) door;
      Boolean inUse;
      Procedure request; Begin
         If inUse Then Begin
             Wait (door);
             door.First.Out;
         End;
         inUse:= True;
      End;
      Procedure leave; Begin
         inUse:= False;
         Activate door.First;
      End;
      door:- New Head;
   End;

   Procedure report (message); Text message; Begin
      OutFix (Time, 2, 0); OutText (": " & message); OutImage;
   End;

   Process Class Person (pname); Text pname; Begin
      While True Do Begin
         Hold (Normal (12, 4, u));
         report  (pname & " is requesting the fitting room");
         fittingroom1.request;
         report (pname & " has entered the fitting room");
         Hold (Normal (3, 1, u));
         fittingroom1.leave;
         report (pname & " has left the fitting room");
      End;
   End;

   Integer u;
   Ref (FittingRoom) fittingRoom1;

   fittingRoom1:- New FittingRoom;
   Activate New Person ("Sam");
   Activate New Person ("Sally");
   Activate New Person ("Andy");
   Hold (100);
End;

Even if this is just plain old Simula, it resembles many of the examples you find of domain specific languages - but then again, Kristen Nygaard wrote Simula to make it easier to simulate the operations of systems, so in a sense it was a DSL. DSLs written by developers to tackle narrow business problems are likely to be built on top of general purpose languages such as Ruby or Boo who lend themselves easily to this, or using a common language workbench infrastructure such as Microsoft’s Dynamic Language Runtime. If you’re proficient with these, you’ll probably be able to maintain our futures polyglot applications - it won’t be much different from maintaining an application that uses a variety of frameworks written in a single language. The most noticeable difference might be that you won’t feel like your forcing the square peg trough the star shaped hole as often as you do today, at least if you’ve chosen the right language for the job.

Now Playing: Chris Kenner - Land of a Thousand Dances

Happy Birthday, Blog

andersnoras — Wed, 30 Jan 2008 20:51:00 GMT

Today it is exactly one year since I pick up on blogging after a long break. To celebrate, I’ll go grab a brew and share some of my highs and lows from my year as a resurrected blogger.First of all, I’d like to give a big thank to you. Without you reading, it wouldn’t make much sense to maintain this blog - except for the (rather frequent) occasions I Google for something I vaguely recall having written.

The year in numbers

The Economist, which is my favorite weekly news magazine, releases a paperback “the world in numbers” book every year. My new blog turning one is a great opportunity for me to share some facts and stats about this blog.If you’re reading this in an RSS reader, you are one of my 691 subscribers - thank you! If you’re not, chances are that you’re one of the 75,778 unique visitors to andersnoras.com during the last 12 months - thank you for stopping by!

The top ten most popular posts were:1. Introducing Quaere - Language integrated queryies for Java - The announcement for my Quaere project, which has gotten much attention since I unveiled it at JavaZone in September2. Behind the scenes of the planning DSL - A deepdive into the code that made the examples in the third most popular post possible.3. I’m coming down with a serious case of the DSLs! - This post showcased a fluent interface based DSL I wrote.4. Software Factories - Another Unlearned EJB Lesson - I’m glad to see that this post has made it so far up the ranks, even with a somewhat misleading title. This post is about achieving agility through maintainable code. 5. NHibernate: Mapping a Class to Several Tables - The name says it all, still people should read about the joined table pattern instead of reading this one.6. Is it a bird? Is it a plane? It’s a DSL! - This post offers my views on the old fluent interface, internal or external DSL discussion.7. Look Mom, No Checked Exception - This post was intentionally ironic, and it stirred up a lengthy discussion around checked exceptions. AFIK, this is the only time I’ve gotten a negative rating at DZone.8. Bare naked LINQ - This post explains some of the mechanics behind LINQ and how they relate to Quaere.9. DSL Tools: A Complex Solution for a Simple Problem - This one is a rant about the applicability of the examples used in the DSL Tools book. It’s not important, and it doesn’t deserve to be on the top ten list. 10. Mean Fiddler: REST-style query service - This was a follow up to Ayende’s Bumbler stunt.

The tree least popular posts were:90. Scheduled Maintenance89. Reignite the browser wars88. Podcast of my JavaZone talk

Surprise, Be Novel, Be Nice

For the readers of my previous blog, the biggest surprise this year was probably that I suddenly stared writing about Java. There were a number of reasons for doing so. First and foremost, I started a working for a new employer in March and Java is the most widely used development platform there. Another reason was that I saw Quaere as a great opportunity to learn the mechanics of LINQ through experimentation while contributing to the Java community. This has been very awarding, and even if there the project has been a little quiet lately, I intend to keep working on this for the year to come.Readers who care more about .NET should also look forward to the next year as I intend to get busy with some ground breaking .NET-experimentation. (We’ll at least, I will write more about .NET stuff…)

With a few exceptions, the top ten list above is close to what I would have guessed. There is a common theme for the posts on that list, they provide information that is not easily found other places, they bring refreshing views on popular topics and similar. The ones on the bottom are dead right boring. I hope to write more novel blog post in the year to come.

Some of my posts this year have been a little edgy, and even if these bring value, I hope to write with a calmer and less aggressive tone next year.

Last but not least, I need to say thank you again. Hope you’ll stay for another year!

Got My Keys Sorted for Windows

andersnoras — Fri, 25 Jan 2008 20:55:58 GMT

One of the biggest annoyances with using a Mac for Visual Studio development is that the Windows keyboard layout is different from the Mac layout. On a Norwegian Mac keyboard, you’ll find much used characters such as { and } by pressing option + shift + 8 or 9 respectively. On Windows you’ll need to hit altgr and 7 or 0. It is the same story with other characters such as < and >, @ or \ to name a few. Since the Mac keyboard hasn’t got an altgr key, you’ll need to press both ctrl and option to simulate this key with Windows running on a Mac. This isn’t a big deal, but it is a little annoying. The constant mental context switches you need to do to relocate your keys is a bigger issue. To mitigate these annoyances, I decided to create a custom keyboard layout for Windows which puts every key in the right place.

I had to make some compromises while remapping the keys with regards to modifier keys. On Windows you cannot remap keys with the alt modifier, so I had to swap it for ctrl. This implies that to get to the curly braces on Windows you’ll need to press ctrl + shift + 8 or 9 rather than the strokes described above. Another minor issue is that most Windows applications use the ctrl modifier for keyboard shortcuts, so hitting ctrl + s will probably bring up the Save dialog rather than printing ß. I reckon I can work my way around this by remapping Visual Studio’s keyboard shortcuts, but until this becomes a real problem I won’t bother.

If you’re interested in trying my Mac-friendly keyboard layout, you’ll find the installer here: Mac Keyboard Layout for Windows (Norsk, Bokmål)

My ¢2 on Java Extension Methods

andersnoras — Thu, 06 Dec 2007 10:38:00 GMT

A while a go Neil Gafter proposed extension methods as a new feature in Java 7. This is an interesting proposal and if it is implemented, it would make Quaere even better. I'll skip the tired list sorting example from the discussions and think out loud about how Quaere would benefit from extension methods.

First lets look at some simple features. Today, you can union two sequences using the union static import:

    List<Integer> numbersA = Arrays.asList(0, 2, 4, 5, 6, 8, 9);
    List<Integer> numbersB = Arrays.asList(1, 3, 5, 7, 8);
    Iterable<Integer> uniqueNumbers = union(numbersA, numbersB);

If we can introduce the union method as an extension method on the List interface, the example could be written like this:

    List<Integer> numbersA = Arrays.asList(0, 2, 4, 5, 6, 8, 9); 
    List<Integer> numbersB = Arrays.asList(1, 3, 5, 7, 8);     
    Iterable<Integer> uniqueNumbers = numbersA.union(numbersB);

It's not a huge thing, but it makes the queries a little nicer because it now read entirely from left to right. We could also use extensions to make queries a little more compact. Instead of writing:

    List<Integer> numbers = 
        Arrays.asList(5, 4, 1, 3, 9, 8, 6, 7, 2, 0); 
    Iterable<Integer> lowNums =
            from("n").in(numbers).
            where(lt("n", 5)).
            select("n");

...we could do something like this...

    List<Integer> numbers = 
        Arrays.asList(5, 4, 1, 3, 9, 8, 6, 7, 2, 0);
    Iterable<Integer> lowNums =
            numbers.where(lt("n", 5));

However, I think we'd have to keep the more verbose query syntax as it is today, because it is a little cumbersome to write advanced queries without any language support.

The biggest potential lies in how predicates are expressed. Today, we have to write the n < 5 predicate as lt("n",5). Both Thomas Mueller and Faraz Amhed are working on some interesting alternatives that would enable us to write predicates like this in a more straight forward manner, but none of these have made it into Quaere yet. With extension methods we could improve today's implementation by extending java.lang.String. If we did, the predicate could look like this n.lt(5). Extending a common class like String has its issues and .NET developers have experienced this with C# extension methods.

While we're at C#, I'd like to contribute my own suggestion on how extension methods could be implemented in Java. I really like the C# take on this. Below is an example of how we could extend .NET's IList interface with the union method from earlier. This is of course for example only as LINQ already does this.

public static IEnumerable<T> union(this IList<T> sourceA, IList<T> sourceB) {
    List<T> result = new List<T>();
    result.add(sourceA);
    foreach (T b in sourceB) {
        if (!result.Contains(b)) {
            result.Add(b); 
        }
    }
}

Notice the this keyword on the first argument, this indicates that the C# compiler should treat this method as an extension. Read my Bare Naked LINQ post for more on .NET extension methods.

I'd like to see a similar approach if extensions are added to Java. This preserves a familiar syntax and uses familiar concepts to achieve it. After all, extension methods only need to be compile time magic - there is no need to change the JVM.

Technorati tags: Java, .NET, Quaere