techblog 

These are my notes from the second day of the JAOO conference in Århus in Denmark. They follow on from my notes from day one. I didn’t think this day was as good as the first, but then it never looked as interesting on paper, so I wasn’t surprised. Once again, since this is a long post, I will give a quote or summary from each session and you can click through if you want to read more

• Erik Meijer - Democratizing the Cloud - “Can we take an ordinary 1 tier app and stretch it over 3 tiers?”
• Jean Bezivin - Models that work - “MDE, MDA, MDSD, DSM, ADM…”
• Eric Evans - Strategic Design - “In software there are no pleasant surprises”
• Trygve Reenskaug - Things your mother didn’t tell you… - “A computer amplifies your brain like the soundbox of a guitar”
• Glenn Vanderburg - The Overlooked Power of JavaScript - “Ajax is a gateway drug for JavaScript”

Erik Meijer - Democratizing the Cloud

I didn’t really get what this guy was driving at with this talk. He talked about solving the difficulty of creating multi-tier applications. The simplest approach would be to try to stretch 1-tier client apps over 3 tiers. Could we do this?

He went on to talk about a book “The Change Function - Why some things take off and others crash and burn”. The essence of this was that success of a product is a function of Perceived Crisis / Perceived Pain Of Adoption. So if you can solve a big problem with almost no pain of adoption you will definitely succeed. So he wants to solve the multi tier application problem without making people learn new languages. He would like to write code and then decide later using a declarative style which tier the code runs on.

I didn’t really buy it. People have been talking for decades about coding distributed applications as if they were local. No-one has managed to do it.

Jean Bezivin - Models that work

This French academic began by talking about the movement of software from Procedural to Object Oriented and on to a Model Driven Style.

He said that Model Driven Architecture is not UML, but more about DSLs. It then went into a long list of acronyms. I’m afraid I dozed off.

Eric Evans - Strategic Design

This talk was mostly taken from Eric’s book ‘Domain Driven Design’. I’ve read this book (which is very good if a little long) and seen him present other parts of it. This time around he was talking about how to do this modelling with large systems.

The story which motivated the talk was about a company he consulted for that wanted to rewrite a legacy system to allow them to do new things that were currently not possible. They decided to do this in three parts (over three years):

1. Write some new infrastructure code.
2. Implement all the functionality of the legacy system on top of that infrastructure
3. Add the exciting new features

He said that he had stopped them doing it this way because he believed it was a strategic mistake, but didn’t say why, leaving that for later.

He then moved on to talking about how systems are composed together. He used an example he is fond of, which is a system to route containers around the world. This system contains a routing service that calculates an itinerary for a given cargo. The people developing the routing service itself use a different model to those developing the main application. They think in terms of graph algorithms, nodes and arcs and so on. This isn’t a bad thing, because as Eric says:

A model is just a system of abstractions that describes selected aspects that can be used to solve some problems.

So we expect there to be multiple models, each suitable for describing and helping solve problems in a particular area. The search for some enterprise-wide single model is a waste of time. The only question remains, how do these different models fit together? The answer according to Eric Evans is to first draw ‘context maps’ which show the connections between the different models. The actual code-level interaction depends on the relationship between the people who control the models. He has (at least) six different ways that models can work together. The two that he explained in the context of this example were a partnership model with the two teams working together and an ‘anti-corruption layer’ where you have to translate a model you have no influence on to suit your own model.

Resolving the way these different models fit together avoids some of the problems of different people using different terminology. He gave an example of a misunderstanding of the word “Pudding” between US and British English. In this case he got a nicer dessert than he expected, but “In software development there are no pleasant surprises”.

He then went on to talk about distilling the core domain, which means splitting off generic subdomains (problems that have been solved many times before) and supporting subdomains (those parts which don’t set you apart from your competitors). This should leave a small core domain which is absolutely key to your business. This is also where you should be spending as much of your development time as possible. Note that this is entirely down to the nature of the business and that the same list of features would split up different ways depending on the organisation, how it fits into the market and so on.

So that brought the presentation back to the original story. As you can see, it is only in the third year that you get to work on the core domain (assuming all the other work runs to plan). What you need to do instead is to come up with a plan that allows as much work on the core as soon as possible. I assume that this would involve applying a more incremental approach to the changes.

To finish, Eric summarized his strategic quick wins as:

1. Draw a context map of the system as it is and push conversion between models to the boundaries.
2. Declare where you will not apply Domain Driven Design
3. Focus on the core domain.

Trygve Reenskaug - Things your mother didn’t tell you about architecture and GUI

This guy is a Norwegian professor who has been involved in computing since the 50’s. Apparently he is the ‘father of MVC‘. His talk was peppered with interesting ideas and thoughts, but I didn’t really follow his main point. I have a feeling that there were many other people struggling to understand too.

He said that the user is key to everything - a computer amplifies your brain like the soundbox of a guitar. He said that the main program is in the user’s brain and it calls subroutines in the computer.

He then went on to discuss MVC and contrast with a new architectural pattern of his called DCA (Data, Collaborations, Algorithms). While MVC is about presentation, DCA is about structuring the data and its interactions like the user’s mental model. He said that structuring things this way makes it clearer which objects will actually be in play when the system is running, which is not something you can see easily by looking at the classes.

I think all of this would have been easier to understand with a better example.

Glenn Vanderburg - The Overlooked Power of JavaScript

In the final session I went to, Glenn Vanderburg discussed JavaScript. He first ran through some history. Originally, it was just a 10 day hack put together by someone with a bright idea at Netscape. The prototype was so good they put it live. Originally named LiveScript, its name got changed to try to follow on the coat tails of the much hyped new language, Java.

Glenn said that this naming was a mistake. Java programmers looked at it and dismissed it as a toy. This meant that designers and those without a programming background ended up doing most work with it. As a result it got a bad reputation amongst programmers.

As a language it is descended from Lisp and is Prototype Oriented rather than Object Oriented. This was news to me. Since it was so different from Java, that’s where the misunderstanding occurred.

However, around the year 2000, people started to look at it again and saw that it was in fact a powerful language. Later, with the rise of Ajax, it suddenly became the hot new thing. He gave a great quote on this: “Ajax is a gateway drug for JavaScript”.

Glenn then went on to discuss what is meant by ‘powerful’ with regard to a programming language. If it is Succinctness or Extensibility, then JavaScript scores quite highly. If it is Control (things such as private methods, closed classes and so on) then JavaScript doesn’t score highly. The latter was of course what Java programmers in the 90’s considered to be powerful.

JavaScript has its flaws and Glenn showed a few, but it seems that library writers have been able to paper over these cracks rather well. He listed the following as things it lacks:

• Proper Hashes
• Syntactic Sugar
• Something like Ruby’s method_missing

To sum up, he said that new great powerful things won’t always look like what we already understand.