wuetender-junger-mann.de

This post is to announce the publishing of “Divine Code – Practices of the Proper Christian Programmer”.

Whilst more or less appropriate commandments have a long standing tradition in software development – one of the first examples being Dijkstra’s famous “Goto Considered Harmful”, little has so far been written about sound practices in God fearing development, that acknowledge the necessity of a strong faith and recur to the spiritual experience of two millenia.

The authors provide us with a step by step introduction to the practices that could very well be used as a maturity model.

They start out with the practice of Prayer. Praying has a long standing tradition in software development – the steps pray and deploy are part of every serious continuous integration effort. It is now well understood that the power of the prayer is – not unlike TDD – twofold. There is a direct effect when the spirit enters the code base as well as an indirect effect through the changed mind-set of the developer. Some pagan processes do rely on daily standups as a substitute for prayer. These efforts might be well-intended but do nonetheless amount to heresy!

Further practices include Christening, which involves getting your system properly soaked, the Holy Communion formerly known as team drinks, Exorcism which comes in different degrees ranging from the casual refactoring to a full blown rewrite. When all that could be done has been done the Annointing of the Sick Code Base could be your last resort.

Another practice that has recently been falling into misuse by heathen folks is the Sacrament of Reconciliation aka Confession. The godless call it retrospective though.

Peace of mind is essential for the productive programmer and can easily be achieved with the firm believe in the Project Everlasting. Everything else failing there is always the option of applying the time honored practices of Crucifixion or Stoning to the incompetent manager or customer, though the authors concede that in most cases generous amounts of Holy Water and Incense will do.

In the true spirit of inclusiveness and diversity there is a contributed chapter on Halal coding Habits, that provide an even more elaborate mental frame work for the aspiring programmer, vividly illustrating that Christianity is not the only hope for the industry. Halal actually meaning lawful or permitted our knowledgeable co-author makes a good point that doing the bad stuff makes the project go haram – unlawful. Another interesting point is his elaboration on the importance of a prophet between the mere mortals and the divine, incomprehensible supreme being. This indirection has indeed come to us in the form of asynchronous messaging with a certain BizTalk combining these virtues with the agile virtue of talking to the biz.

The book is available as of today, April 1st 2010 – let the lord in to your heart. Buy a copy. And become a truly superior programmer.

I was somewhat shocked to learn that a lot of my colleagues are not even aware of the existence of jetty. I have been using it for quite a while. It is the best thing you can do during development – and no jboss is not a good thing it is after all quite similar to websphere. Arguably jetty is also the best thing in production.

As I will die one day, I can’t be bothered to use anything else, because there are no insights to be gained and no problems to be solved by using anything more “elaborate”.

Lautstand bezeichnet in einer diachronen oder diatopischen Betrachtungsweise das gesamte System von Lauten einer Sprache. Wenn sich der Lautstand, meistens über einen längeren Zeiträume hinweg, verändert, so spricht man von Lautwandel. Oftmals unterscheiden sich Dialekte einer Sprache durch den Lautstand.

-Wikipedia

I have just finished reading Michael Feathers’ Working Effectively with Legacy Code. The book gives a lot of very concrete examples of how to improve code and make it testable. To my tastes he is exaggerating the whole code without test is legacy code thing, which in the naïve reader might lead to the impression that a test is all it needs for code to be good.

As I am going to sell my copy at favourable rate to one of my colleagues, I’ll just list a few things I found intersting:

• Chapter 15 – My application is all API calls. He uses a very good example of a mailing list server to illustrate how to get around problems with external API dependencies. He distinguishes to approaches “Skin and wrap the API” and “Responsibility-based extraction”. I am strongly favouring the second approach as I find it leads to more relevant abstractions and not wrapping for the sake of wrapping…
• Another theme in the book is understanding code. He mentions a few nice techniques:
  • Effect analysis (dataflow analysis) using pen and paper
  • Mapping out your way through the code base while reading on a piece of paper
  • Printing the code and doing listing markup using marker pens.
  • Scratch refactorings while reading code, that are thrown away and whose sole purpose is helping to understand the codebase and on a similar note delete unused code you find while reading
  • Telling the story of the system. This is done at several levels starting with a high level description that has a lot of generalisations. This practice helps people to develop a shared vision and also highlights discrepancies between the system and the story.
  • Naked CRC-Cards – somewhat poorly named as actually it’s naked object cards. Use white index cards on a table to represent objects. Tell story as you place and rearrange them.

There is a nice example for separation of concerns (he uses the term SRP, which I don’t like) on page 247 describing an expression evaluator.

Adapt parameter refactoring. If the parameter type is too complicated for stubbing etc, look at the use of the parameter and introduce a wrapper around the original object that just exposes what the current method needs. Example HttpServletRequest gets wrapped in ServlatParameterSource which implements a new ParameterSource interface.

On a similar note primitivise parameter. Instead of passing in our wrapping an expensive abstraction just pass in the required “values”. This of course very dangerous as it breaks encapsulation. On the other hand it could lead to the extraction of roll based primitive interfaces (a bit like the adapt parameter pattern)

Before I forget it completely, I have to post a link to Nick Williams’ Unconditional Success. This book is outrageously funny. We kept a copy on our desk and would open it at random pages to reinvigorate the team spirit.

Today Arne and I ventured out to explore rural England. We did the Gog Magog Walk from Arne’s “Walks around Cambridge” guide.

The first thing that caught my attention was this chair:

Another typical feature of the English landscape is the open fuse box:

Also we learnt what a copse is:

And more importantly that it actually deserves a name (we just saw Anne’s Copse):

And of course we need a picture of our heroes in the winter idyll. As you can clearly see there as about half an inch of snow. This amounts to adverse weather conditions and hence treacherous roads. We felt like invading Russia…

Dan Haywood will be coming to the ThoughtWorks London Office to talk about his new book Domain Driven Design using Naked Objects. I have been excited about the idea of NO for quite a while, though the actual implementations have been controversial. So I hope for interesting discussions.

Here the details:

Thursday December 10, 2009 from 7:00pm – 10:00pm
ThoughtWorks UK Office
Berkshire House, 168-173 High Holborn
London, United Kingdom, England WC1V 7AA

If you are keen on the free pizza sign up on our
Upcoming Page.

Some interesting links:
Naked Objects Home of the original implementation.
JMatter A more beautiful implementation

Hope to see you there.

Today whilst researching how to implement a proper brainfuck interpreter, I stumbled across Babbage. I would say it’s love at first sight.

I came up with the following extensions method in C#:

public static class NeatExtensions{
    public static bool In<T>(this T element, params T[] elements){
        return new HashSet<T>(elements).Contains(element);
    }
}

It actually yields a nice syntax for checking enum values and the likes:

enumValue.In(Enum.X, Enum.Z)

I am wondering whether there is actually a de-factor standard library in the C# world that has extensions like this.

Earlier this year I wrote a build tool in java. The core idea at the time was to express the build in terms of functions and function composition. This is not exactly a good fit with java. So last week I had some spare time and came up with this way of defining a function (application) in java:

 public static class FancyFunction extends FunctionBase {
        @In
        public final Str a;
        @In
        public final Str b;
 
        @Out
        public final Str c = null;
        @Out
        public final Str d = null;
 
        public FancyFunction(Str a, Str b) {
            this.a = a;
            this.b = b;
            super.reflect();
        }
 
        protected void evaluate() {
            setResult(c, new StrImpl(a.getValue() + "-" + b.getValue()));
            setResult(d, new StrImpl("XX"));
        }
    }

There is obviously a lot of magic going on and I do feel a bit bad abou setting final fields using reflection.

What it actually does is defining two functions. In a friendlier syntax somwhat like this:

fancy.c(a, b) = a + "-" + b;
fancy.d(a, b) = "XX";

But back to the java example, you can now compose applications like this:

FancyFunction fun = new FancyFunction(new StrImpl("x"), new StrImpl("y"));
FancyFunction fun2 = new FancyFunction(fun.c, new StrImpl("z"));
assertEquals("x-y-z", fun2.c.getValue());

As this is all very reflective I could actually traverse the metadata and get dot to render this:

There is no code, as it is all very dirty. But to me it looks like a viable syntax for specifying tasks and wrapping imperative code into a functional style. The current implementation relies heavily on interfaces, because it generates a lot of proxies that allow for lazy evaluation.