So, I’ve never really liked writing code in xml. It’s normally verbose, akward, and counter-intuitive. There, I’ve said it.

It’s a very unpopular point of view, and has caused a number of arguments in the past (techies are very passionate, and entrenched, in certain design choices).

Xml is a great as a way of describing data (and is indeed the reason it was made) and is thus rightly applied to web services, web pages, and some levels of configuration, but not for writing code.
Incidentally, this is why I’d always prefer a code solution if I was applying the dependency injection pattern, say guice or picocontainer.

Build scripts (the active word there being ‘scripts’) are a strange beast; normally procedural with calls to modules, which, actually, you’d like to be more object oriented if possible. You also would want minimal if/else, foreach support, despite what old school build folks tell you.
For example, I recently wanted to generate a bunch of war files that had very similar web.xml’s but had a few values different. I eventually went with a CSV file, fmpp template merging, and using the for task in antcontrib which called out to a macrodef on ANT.
That was fairly involved, and required more modifications to my basic ANT install than I’d like. I’m also kinda wondering how I’d achieve that with something like MVN… This could’ve been done in 5 lines of code if it was easy enough to stitch together in code.

This made me really think about what do I actually want from a build system.

My Wish List For An Ideal Build System

• Convention over configuration is great if the convention is one that I can understand. I’d like the default to be conventional with overrides. When using ANT I always write coarse grain targets in the build file; make, test, save, and my default ‘ant’ master target has these three as dependencies
• Easily configurable for different environments.
• Dependencies dealt with. Something MVN is good at, but not excellent at. I normally have 2 build scripts; one for the module/project only, and another to also build dependencies, so I can explicitly choose.
  Ideally, I’d like to run one build, and it would work out if it had to re-build the dependencies or not.
• Not to write code in xml. The best solution I know of for a primarily procedural, with some object oriented / pseudo OO thrown in if needed, is JavaScript (sorry python). Its also has a bonus in that its the most popular coding language in the world. It’s also the language that brought me back to coding when I was in my early 20s (so I’ve got a soft spot for it)
• Re-use all the plugins already made for other build solutions
• Consistent through all the languages I choose to write in
• Concise, and understandable.

This is all very fine waffling about this, but here’s perhaps an example of what this would look like. I’m going to use a recent ANT example, only because I haven’t used a MVN example to hand – last time I used it was about a year ago. A MVN example, after dependencies, would run at about the same amount of lines:

<project name="module" default="module">
 <property file="../Commons/environments/${env.COMPUTERNAME}.properties" />
 <property file="../Commons/build.properties" />
 <property file="build.properties" />
 <import file="../Commons/common.xml" />

<target name="module" depends="make.module,test.module,save.module"/>
<target name="make.module" depends="clean.module">
 <make module="${module.directory}" jarname="${module.jar}" source="src" targetdir="made">
    <make.classpath><classpath><path refid="module.classpath"/></classpath></make.classpath>
 </make>
 <make module="${module.directory}" jarname="${module.test.jar}" source="test" targetdir="made">
    <make.classpath><classpath><pathelement location="${module.made.directory}/${module.jar}"/><path refid="module.classpath"/><pathelement location="${junit.jar}" /><pathelement location="${mockito.jar}" /></classpath></make.classpath>
 </make>
</target>

<target name="test.module">
    <test jarname="${module.made.directory}/${module.test.jar}"  basedir="${module.directory}">
       <test.classpath>
           <classpath><pathelement location="${module.made.directory}/${module.test.jar}"/><pathelement location="${module.made.directory}/${module.jar}"/><path refid="module.classpath"/><pathelement location="${junit.jar}" /><pathelement location="${mockito.jar}" /></classpath>
       </test.classpath>
 </test>
</target>

 <target name="save.module">
 <save targetdir="${module.dist.directory}">
    <save.fileset><fileset dir="${module.made.directory}" includes="${module.jar}"/></save.fileset>
 </save>
 </target>

 <target name="clean.module">
    <init.dir dir="${module.made.directory}"/>
    <init.dir dir="${module.dist.directory}"/>
 </target>

 <path id="module.classpath">
    <pathelement location="${website.dist.directory}/${website.jar}"/>
    <pathelement location="${website.model.dist.directory}/${website.model.jar}"/>
    <pathelement location="${servlet-api.jar}" />
    <pathelement location="${neodatis.jar}" />
 </path>
</project>

flavour=java
name='module'
load('common_properties.js')
depends=[website, website_model, servlet_api, neodatis]
tests_also_depend_on=[mockito]

flavour=java
name='module'
load('common_properties.js')
depends=[website, website_model, servlet_api, neodatis]
tests_also_depend_on=[mockito]
master=[make, test, save]

How would I handle that multiple wars example previously?

flavour=java
name='module'
load('common_properties.js')
depends=[website, website_model, servlet_api, neodatis]
tests_also_depend_on=[mockito]
wars = function() {
   var csv = csv('wars.csv')
   for (var line in csv.lines) {
      var template=merge_template('web.xml.ftl', map(csv.headers, line))
      war(line['name'], template)
   }
}
after_master=[wars]

The other bits that aren’t really talked about in the example, and that you don’t need to mention in every build:

• There would be a harness that would run the master array of functions
• Why should I always add my testing libraries to the classpath? I’ll normally always use one lib for this (TestNG or JUnit for Java) and typically never mix and match
• There would also be an included file that would declare all the dependency variables. This would be added to for project/other module dependencies
• The war, map, and csv functions would be globally declared
• There would be one convention file which would allow you to say what your own convention would be for, say, file structure (i.e. source folders, where you want to generate the built code to, where the distribution folder is etc)

How this could be implemented? As a proposal, you could use rhino in order to expose all the stuff written for ANT and MVN, and write a thin wrapper function to ‘de-uglyify’ it. I wouldn’t make the same mistake as some other build scripting solutions and would tidy up / map some of the counter-intuitive calls to MVN/ ANT

The idea is that I’ll stick up some titles of potential blog postings, and people can comment on what one they’d like to see first, or indeed can comment on titles in this space they’d like to see  (if no-one votes I’ll simply start working my way down the list).

Here goes:

• How could Tests possibly lighten the load?
• How can you remain Agile and govern a SOA strategy (what’s good enough)?
• The gaps are catching us out.  What are the potential gaps when using Agile and SOA?
• How could a team work together when SOA is in play in an organisation? (cross-functional / functional teams)

I’m bothered whether I can eat, but that’s about it.  I actually care more about being cerebrally challenged. It’s also fair to say that I won the birth lottery and come from a country where I don’t really need to care about starving; though I have lived in and visited a few where that is a distinct possibility.

It is, however, very heartwarming to read the following article http://www.bbc.co.uk/news/world-us-canada-10870361 where these guys, who have made a big chunk of money (> 1 Billion), have decided they want to give away more than 50% of their cash to charity.

Some might say ‘well, boohoo, they only have 500m instead of 1bn’ but not me.

Today is a day where I’ve left my cynical/practical (delete as appropriate) head on the bench and take this act of giving on face value.

Well done Bill Gates.

p.s. He’s also on track to eradicate malaria in 5 years.  That is absolutely mind-boggingly astounding.

I was really miffed that my app using prototype / scriptaculous didn’t dragdrop out of the box.

I looked around to see if anyone else had fixed the lib, to no avail, so I finally spent some of my wee small hours time hacking the library to support this.

The subtle differences in the API:

• its “touchstart”, “touchend”, “touchmove” not “mousedown”, “mouseup”, “mousemove”

• To work out if touch is supported use (just found out this isn’t supported in android):
  

  var supports = ('createTouch' in document)

• There is no concept of a current pointer when your finger isn’t on the screen, so when you drop, you have to use the previous pointer (luckily already tracked in the dragdrop lib)
• There is an array of touches on the iPad (for different fingers etc), so event.pageX is event.touches[0].pageX

dragdrop.js and prototype.js files attached

prototype.js
dragdrop.js

The bits that don’t work yet: the drag seems to be greedy right now, so I can’t activate links in the draggable.  Need to look at the webkitdragdrop.js lib to see how they handled that.

Thanks Thomas Fuchs, for scriptaculous in the first place, and secondly for the iPad demo which i ripped to bits to work out how it was put together.

It appears that the link to the epicenter session is now down.

The excerpt for the session was as follows:

How A Little Bit of Philosophy Can Affect The Products You Build

more to follow as part of the session…

The PDF version of the slides from the session HowALittleBitOfPhilosophyCanAffectTheProductsYouBuild doesn’t include speaker notes, so please let me know if you need any more details around the session.

http://epicenter.ie/2010.html?zone_id=20&mode=agenda&session=193#session

I love some aspects of simplicity in http://www.concordion.org/

One of which is the way the test fixtures are not subservient to the spec.
Fitnesse totally does the reverse of that; and it makes it very complex (remember complex = bad) with classpath setups etc.

So, as an illustration, we had a bunch of different channels (telephony jargon for web, mobile web, SMS, voice, mobile apps etc) to test recently, but they fundamentally all had the same spec (i.e. settle my balance, view call log etc).

Sure they all had different implementations, but the behaviour of the channels were fundamentally the same.

We were able to setup a project in eclipse with only the specification which was written (basically html files with some concordion markup) and then inherit this in all the other channel fixtures we were using to test.

The beauty of concordion is that it uses a JUnit runner to load the html descriptor and execute the fixtures.
This means we were able to write different implementations of the fixtures behind the scenes, and write only one description of behaviour.
Try doing that in another framework…

It’s a strange thing to do; after the fact you remember what you did (and it seems strange in retrospect).  However, when you’re doing it, everything seems perfectly normal.
The strangeness of your perception of the situation seems to be naturally, and nonchalantly, accepted by your brain.

I once cost my sister £150 because I thought I was going for a walk in the woods, stopping by a picnic area for a drink with friends.
In reality I had walked downstairs from the bar she was managing, broken through a locked door (of which I didn’t have the key) and poured myself a drink.  Where did the cost come in? Weeeell, when I got through the door the alarm went off, and it cost £75 to reset this with alarm company.  And I went walking in the woods with friends twice that evening.

I’ve since been able to train my brain, and wake myself up whenever I notice the signs (is that really a tree, or a door I’ve just broken through?).

However, what I’ve realised is that my brain (and possibly others too) is very good at telling stories to fill in the blanks well enough to actually alter the perception of what I see in front of me.  And I don’t think I’m alone.  It really fascinates me that the brain does this, and does this quite regularly.

I’ve been actively trying to lessen this effect, but I’ve also seen this happen with people in a communication starved environment; people make stuff up based on fleeting observation.  How do I know?  I’ve seen it happen a bunch of times.

And I’ve just done it in the last 3 days…