Recently I was learning ANTLR, trying to decide whether this was a right technology to pursue a particular project which involved parsing a preexisting message format. After a week of a spike, we decided that it was worth pursuing and started on earnest on the grammar for our project. However a week into this process, I had an epiphany … I was doing some things wrong with the ANTLR grammar which were now slowing progress in adding the new characteristics it needed to be complete. Many developers know this feeling; the features of my grammar that I had built over the first week were naive and now hampering it from expanding into the new requirements. I took it on myself to kill the entire grammar and start again. It took less than a day and half to replicate that week’s worth of work (i.e. pass the test suite which had built up around it).  I’ve done this before; scrap the first attempt at building a domain and try again. Here my domain was the same (it was after all defined in both a standards specification and in the many hundreds of thousands of sample messages we captured from an existing system), but its implementation needed refinement.

So I think that the rule about throwing away spikes can in fact be made a general axiom of programming:

When you are learning a new technology, make sure you throw away the first thing you build that works – to avoid accumulating your mistakes.

Thanks to Robert for the important qualifier “that works”.

N.B. my views about system rewrites have not changed regardless.

There is a web service inside a component, let’s call that component a ‘Node’, that receives something like (but not identical to!) an Event on its interface. Inside the Event is some data that the Node does not particularly care about (and actually has no access to – it’s just a byte[] as far as the Node can tell). However, the Node contains a Registry which enables components, lets call them Event Handlers, to register themselves with the Node, as available to process certain Events (i.e. decode that byte[] and do something with it) according to criteria which the EventHandler injects into the Node’s Registry.  EventHandler is an interface with a handful of simple methods related to handling the Event, and also registration with the Registry.

So, the process flow looks something like this: The Node first records the reception of the Event at the interface in a log. Then it tells the Registry about the Event, and the Registry produces the EventHandler(s) it needs to use.  The Registry gives the Node back the instances of the EventHandler interface. The Node then hands off the Event to the EventHandler, which does whatever it does unbeknownst to the Node, and returns a fairly simple EventResponse object. The Node records the EventResponse object in its log (i.e. a database) and returns it as the response to the web service call.

Consider the Node service method as looking something like this (you’ll have to excuse the Java 1.4-ness of this code, the WordPress code highlighting plugin apparently hates Java 5) :

  public List receive(Event event) {
    List responses = new ArrayList();
    for (EventHandler handler : this.registry.lookup(event.getMetadata())) {
      Response response = handler.handle(event);
      saveResponse(response, event, handler);
      responses.add(response);
    }
    return responses;
  }

To enable the wiring, the Registry has a method:

  void register(EventMetadata metadata, EventHandler handler)

and among other methods the EventHandler interface defines:

  void setRegistry(Registry registry)

Currently the WAR file imports the Node.JAR and a group of EventHandler.JAR files which are specific implementations for handling different kinds of Events. We configure it in Spring currently so that the specific EventHandler is injected with the Registry object (from the Node.JAR). The EventHandler implementation then registers itself with the Registry in a call-back operation, telling it what sort of Events it will handle.

This all works just fine at the moment. The problem with what we have is that it is all currently statically compiled into the WAR file.The WAR file specifies a Spring application context XML file which in turn loads the Spring configuration for the Node and Registry component, and every Spring application context for each Handler JAR included inside the WAR file’s WEB-INF/lib directory.

Now, we now don’t want every deployed instance of every Node to handle every possible Event. Currently we’ve got a small .properties file that actually tells another Spring component which EventHandlers are be to be instantiated or not. This is working fine when we only desire some Nodes to handle maybe one or two of a larger group of related Events. That is, where we currently don’t mind that the WAR file is identical in every respect on every Node — it’s just that each node contains a .properties file in its classpath that tells it which EventHandlers it is allowed to load and use (and therefore what Events it is capable of receiving, bearing in mind that when I say ‘Events’ there is really only one concrete type of Event, I mean the encrypted data which is held within the Event which is actually consumed by the Handler).

However, we are now in a situation where we want to use this same architecture for a completely different group of Events. We definitely don’t want to have to compile and assemble a new WAR file for different Nodes based on the Event cluster. We want to deploy a standardized Node.WAR which has available on its classpath a dynamic set of XxxEventHandler.JAR which can dynamically register themselves with the Node’s registry. There may be also a requirement for some related custom extension points in the future.

Initially we considered OSGi as the technology to enable this. After some discussion yesterday with people who know better about OSGi, this approach was rejected as impractical for the moment. Therefore last night I set out tooling about with the Spring 2.5.6 ApplicationContext and its related objects to see what could be done to enable dynamically-loaded JAR files within a parent Spring application context. Here is what I’ve discovered we can do, with only some small restrictions on developers writing the individual EventHandler implementations.

The first issue is, we need to locate a set of Spring application context XML file which should be on the classpath but not yet instantiated into any live Spring context.

Assuming we’re in a bean that’s ContextAware or otherwise has access to the Spring application context which is loading it, after the parent context has loaded and initialized (there are method hooks for this sort of thing) we can use the org.springframework.core.io.support.PathMatchingResourcePatternResolver class to search the classpath for a resource:

  PathMatchingResourcePatternResolver pmrl = new PathMatchingResourcePatternResolver(context.getClassLoader());
  Resource[] resources = pmrl.getResources(
    "classpath*:/net/crazymcphee/dynamiccontext/*/Crazy*DynamicContext.xml"
  );

Looking at the Spring 2.5.6 source code we found that the String passed to the getResources() method isn’t a proper regular expression, which is a pity. So you can’t do something like look for **/Crazy*DynamicContext.xml and expect to match a file Crazy*DynamicContext.xml in any package. Also we found that it had to prefixed with that classpath*: … yes, the asterix, literally … else it wouldn’t search the classpath, as opposed to the file path. So we’re restricted in the above example to a file called Crazy<something>DynamicContext.xml in a package exactly one deep from net.crazymcphee.dynamiccontext … e.g. net.crazymcphee.dynamiccontext.package.CrazyMcpheeDynamicPackage.xml matches but net.crazymcphee.dynamiccontext.package.sub.CrazySubDynamicPackage.xml and net.crazymcphee.dynamiccontext.CrazySuperDynamicPackage.xml do not. Therefore we will have a restriction on what package the dynamic context can be in and what it’s name will be. I don’t think that’s too onerous on our developers – we just have to pick a sensible standard.

The next part of the problem is that we have to load the ‘Resource’ thus found into a Spring context. This is pretty easy:

 for (Resource r : resources) {
   GenericApplicationContext createdContext = new GenericApplicationContext(context);
   XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(createdContext);
   int i = reader.loadBeanDefinitions(r);
 }

The int i will be set to the number of beans found in the createdContext. The createdContext will have the original context as its parent context, so it can gain access to any beans defined there (and also, although we are yet to test this (!), it should also be intercepted by the AOP-based transaction interceptors in the parent, and so forth).

The only other part of the puzzle may be to query the createdContext to see if it has any target beans within it, luckily for us an ApplicationContext has a method getBeansOfType(Class clazz) which will load all the beans of a particular type:

  for (Resource r : resources) {
    GenericApplicationContext createdContext = new GenericApplicationContext(context);
    XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(createdContext);
    int i = reader.loadBeanDefinitions(r);
    Map map = createdContext.getBeansOfType(EventHandler.class);
    for (Object o : map.keySet()) {
      EventHandler handler = (EventHandler) createdContext.getBean((String) o);
      // do some programmatic manipulation with the EventHandler that we found here
    }
  }

Using these three Spring features will enable us to be able to place a JAR file containing an interface implementation, and a Spring context XML file matching a particular pattern, into the classpath of our WAR, and on restart, we can dynamically pick up the newly inserted features into our application installation. I’ll report back when we get an actual production prototype together that can do this. Hopefully it will be OK to put the code in the blog too (if we make it generic enough).

If you have any further ideas or refinements to this idea, please leave them in the comments!

But the bigger headache was the Java libraries for handling WebDAV. There is the now-abandoned Apache Slide, the based-on-Slide webdavclient4j, and the way-more-complex-than-it-needs-to-be Jackrabbit. Slide and webdavclient4J have the appearance and feel of crusty, molten code from 2004. Jackrabbit is a full-featured server product … to quote, it is a “hierarchical content store with support for structured and unstructured content, full text search, versioning, transactions, observation” … and I’m sure that’s real nice if that’s what you want, but I just need to automate push a file onto an Apache HTTPD instance and tell another service what URL it now lives at. It’s not rocket science. Jackrabbit has too many features, and too little simple documentation, to be truly useful for what I need.

Enter the easy to use WebDAV client, Sardine. Here is the author’s post announcing it.  It’s very simple to use:

Sardine sardine = SardineFactory.begin();
List<DavResource> resources = sardine.getResources("http://yourdavserver.com/adirectory/");
for (DavResource res : resources)
{
     System.out.println(res);
}

Anyway, simplicity … just the sort of thing I was looking for. Recommended.

Lost in the shuffle is something basic: Programmer productivity. Friends who are hands-on with such matters tell me the available SOA development environments are less than half as productive as products like PowerBuilder and Delphi were, back when they were viable.

Putting aside the Powerbuilder and Delphi love for just one minute, this is something I’ve been banging on about now for the past year … the programming tooling that is foisted onto programmers by the choice of the deployment architecture. It’s just all wrong.

In my view, what makes a programming language really productive is notepad. Or vi, or emacs, or gvim, or textmate, take your pick. What I mean is … the programming language has to be able to be programmed with a simple editor. Yes, an advanced IDE will make things more productive, but the basics must also apply. Now a lot of SOA environments are simply not programmable without the specific IDE tied to it. Even worse, the IDEs are often completely custom jobs that require a developer to be re-trained … losing years and years of productive speed with muscle-memory style automatic ability to navigate the programmer’s usual editing tool. Seriously. This stuff is whack. A program language or an environment needs to be IDE-neutral. If you got a plumber around, would you insist that he only use the tools you supply from your home handyman kit? Or would you expect the plumber to have mastered a set of his own tools already? And making matters worse, it’s rarely programmers that choose these tools which are foisted on them. The server/deployment environment and the language used to implement need to be decoupled from the tools used to build it.

But an even worse failing of many of these SOA tool suites, is that they all strongly and irrevocably coupled to the deployment/runtime environment. Generally they totally lack the ability to keep up with modern programming practice. Like for instance, automated testing. Or even unit tests, let alone advanced and productive techniques such as Test-First approaches or Test Driven Design. The tools often lack refactoring support. All of these things are in my opinion, and in the opinion of many leading developers, absolutely essential to quality engineering practice and agile development outcomes like “delivery of working software”. Both the “delivering” and the “working” part means the whole process needs to be repeatable. That’s why automated integration testing, to name just one thing, is essential in modern development. But often the fancy custom development tooling is a complete barrier to achieving this.

But you won’t hear any of this from the big vendors. One big vendor recently announced their new version of their middleware product suite had a ‘focus on testability’, but you ask any of their presales guys to demonstrate this in an actual development environment. Ask them about continuous integration support, for example. Witness their blank looks. Their development product is completely orientated to “one button push from the IDE to production” modes of thinking the idea of continuous integration builds is almost totally antithetical to the very concepts of operation the product is organised around. They think that finally adding support for Subversion version control system, at least five years too late, is a wondrous achievement.

They are aiming for ‘programmerless programming’: of course in process just creating a new type of programmer. Every new generation of programmers simply have to learn the same hard-fought lessons of software engineering over and over again because each generation of tooling apparently scraps the paradigm over and over again in a vain attempt to create push-button, wizard-driven programming models. They nearly all suffer from ‘hello world’ programming – the simple examples that sell them to IT management are trivial to conquer using the wizards, but more complex problems (i.e. real world ones) are flat-out impossible. Thus these tools are always mirages which look great at a huge distance on the horizon but are flat lifeless salt pans of bleached skulls and bones on closer examination (or, maybe they are more like tar pits that look like a nice waterhole but one step into it and you are sucked down  to your doom).

As you might be able to tell, I am utterly contemptuous of many of these SOA tool paradigms. I have nothing against SOA itself, per se. But there is nothing more productive than a programmer who understands the importance of simple and repeatable build and deployment automation using command line tools and who knows his programming editor inside out after ten years of use. Give that programmer a better language by all means, add incremental features to that IDE, allow the programmers to continuously improve their techniques, promote professional craftsmanship, yes, yes and a thousand times yes. But no amount of drag and drop wizards, push-button deployments, and “object inspector” property editors will ever usurp that deep knowledge a good programmer brings to both his language and his personal tooling choices.

Collection mapping is one of those “hello world” problems. (The “hello world” example in the doco looks totally trivial and completely ideal [which is the problem], but suck-in-the-galaxy-greet-it-and-then-map-all-the-stars problem, which is more like what your real app looks like, is far less than trivial and not so easily achieved with the demonstrated toolkit). In my experience, collection mapping is the cause of all sorts of pain and performance perfidy.

Here’s a further situation where I find that they really get in the way. Consider integration with existing systems that use highly-normalised database schemas (designed by advanced SQL programmers who know what they are doing in that language).

This is not an uncommon scenario – we have this system ‘A’ which (let’s say) has all our customer shipping, product, warehousing data in it. We don’t want to replace it. But we need to extend it so that e.g. available to web systems. Or maybe it needs to be integrated into the big fancy off-the-shelf CRM we’re installing. Something like that. We need to build some sort of service layer around this system ‘A’ so that other systems can access its data and/or functions. It’s common to think that an ORM around that big complex database schema is going to help, but in my experience, it doesn’t for many of the reasons Stephan and Aldo list. That sort of highly-normal database schema in my experiences completely kills ORM object representations stone cold. You end up with so many LazyInitialisationExceptions and various other problems it sucks productivity out the developers and performance out of the system.

Also, I get a bit annoyed about ORM abstractions leaking into the web tier, this is especially prevalent with using annotations rather than ORM mapping files.

Different sorts of approaches are sometimes needed to be applied with careful thought in that scenario. Perhaps you need to model the “intermediate” domain you need directly, and then use, for example, simple DAO layers which operate directly on the domain you’ve defined. These DAO layers then might call functions (stored procs) in the database that do the problematic mapping in an efficent relational language (after all it’s the direct representation of the target data format).

I’m not saying that you have to do the above in every case, or that an ORM is always wrong, but anyway the point is, ORM isn’t a magic bullet like any other technology you have to consider carefully. Your application doesn’t always need one by default.

I was off the client site so I couldn’t rely on a fast connection to their development databases. I just wrote a dummy function that was called the same as the real function with the same input and output parameters and instead of the complex function body it just wrapped a simple mock table of test data. Problem solved, Oracle XE to the rescue. But first you have get Oracle XE running on your Mac, this is what the rest of this article is about, because you can’t just download an Oracle XE edition for the Macintosh.

Virtualisation is great – use a Linux VM

However modern Virtualisation is your saviour. Put simply, you can use a virtualisation tool like Parallels, or my choice, VMWare Fusion, to run a virtualised version of Linux that contains the Oracle XE instance.

Because VMs can waste a bit of your local resources, luckily there is a specialised version of Ubuntu designed for running as a virtualised machine of this type. Its called JeOS (pron. Juice, apparently). It doesn’t have an X-window environment, just the shell, so it’s pretty lightweight and can run, with Oracle XE, in less than 512MB of memory. Perfect for getting a copy of Oracle XE onto your Macbook Pro.

It will however, eat up a couple of gigabytes of disk space, up to the maximum limit you choose for your disk size in the VMWare configuration. However it will only use the current amount of disk needed, as VMWare will expand the size of the image as needed (I’ll just assume that Parallels does something similar).

Setting it up – basic instructions

This page here – has a great set of instructions for getting JeOS installed and configured with Oracle XE on it. Follow the instructions there exactly – but only to the point where you install and configure Oracle XE – don’t go further than that.

Make sure you configure plenty of swap space as outlined in the instructions.

Setting it up on standard Ubuntu/Debian

If you are running a full Ubuntu or other Debian based instance, the instructions are somewhat simpler. Install it as per normal in your VM. But make sure your swap space is twice the memory you have assigned to the VM! Oracle XE demands things to be like that.

Add

deb http://oss.oracle.com/debian unstable main non-free

to /etc/apt/sources.list and then:

$ wget http://oss.oracle.com/el4/RPM-GPG-KEY-oracle  -O- | sudo apt-key add -
$ sudo apt-get update
$ sudo apt-get install oracle-xe

These instructions were cribbed from here.

After installing and configuring Oracle XE

After you run the XE configuration (‘$’ represents the Unix shell prompt and should not be typed);

$ sudo /etc/init.d/oracle-xe configure

If you’re running on JeOS don’t yet make the machine “headless”! Or you might find there are issues with the “Apex” application. The problem is that the Apex application, which is a useful web-based administration program for Oracle XE (especially for developers who don’t want to be forced to use sqlplus for all their database administration), will only allow connections from localhost – and you don’t have X-window, or a browser, to access it (I don’t know if lynx will work with Apex and I wasn’t going to try).

Get SSH installed

First get SSH installed in JeOS so you can get to the command prompt remotely:

$ sudo apt-get install ssh

Find out the VM’s IP address

Now, if you type ifconfig (/sbin/ifconfig if that’s not found on your path) you will be able to determine the IP address of your VM running on your Macintosh. At this point you can connect to the VM using ssh from a Macintosh terminal window:

$ ssh username@ip_address

Actually, at this point you can go ahead and make the machine headless, if you want. I would recommend not to do that until you’re sure of everything you’ve configured.

Configure environment to run sqlplus

After you’ve logged back into the running Linux VM using ssh from the Mac Terminal, the next thing is you’ve got to get sqlplus access working to the XE instance you installed. Funnily enough, although the .deb file that is installed off the Oracle site creates an oracle user, it doesn’t in any way set that user up so you can use the command line tools. SO you can’t just su – oracle and get a functional environment.

Anyway, you will need to do two things to your environment; add the ORACLE_HOME environment variable and set up your PATH so it can find sqlplus.

$ export ORACLE_HOME=/usr/lib/oracle/xe/app/oracle/product/10.2.0/server
$ export PATH=${PATH}:${ORACLE_HOME}/bin

You should add these two lines to your .profile or .bash_profile file – probably best for the ‘oracle’ user that the installation will have created. But you can actually set this up for any regular user that you configure in this VM. You can also just type them at the command line to get them in your current environment, if you have to.

Configure Apex to accept non-localhost connections

The web-based administration software for XE, called “APEX”, only binds to localhost. This is a big hassle if your VM copy of Linux (like JeOS) doesn’t have a GUI, because you don’t have a browser (lynx/links excluded, I did not try those!).  However, you can make Apex bind to the “external” IP address for your VM, but you’ll need to use sqlplus.

To run sqlplus, do the following:

$ sqlplus system@XE
  Enter password:

Enter the password you specified at the ‘oracle-xe configure’ step above.

At the SQL prompt, enter the following command:

SQL> EXEC DBMS_XDB.SETLISTENERLOCALACCESS(FALSE);

Now you’ll have to stop and start Oracle to make the configuration active:

$ sudo /etc/init.d/oracle-xe restart

After which, if you type

$ netstat -tna

You should find a line

tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN

This indicates a process is listening to the port 8080 on all IP addresses for connections coming from any other IP address. Assuming you specified port 8080 at the ‘oracle-xe configure’ step. Sometimes I use 8888 especially if I have a Tomcat instance in the same VM, as Tomcat will also like to run on 8080 and I’d prefer it if it did.

Test and use Apex

Test this connection in your browser, in my case, the address was 10.1.2.17, but you will have to substitute your own VM’s IP address – http://10.1.2.17:8080/apex. I like to make an /etc/hosts entry that points to this address as ‘oracleXE’. That way I can use a symbolic name in my jdbc connection strings and actually switch which instance of XE I am using depending which VM I’ve fired up without editing the jdbc configuration of the application under development – I just change the /etc/hosts entry instead.

Anyway once you connect to apex you can login using the user name and password you set up during your XE install and configuration process (same as you used for sqlplus). The users will be sys and system, you can use them to create new users to contain your databases for development.

The same IP address as above will be used to connect to your Oracle database from the programs you are developing. The default port should be 1521 and the SID should be XE.

Enjoy!

Today I just want to meditate on a code artifact that often manifests itself in such environments. I speak of the comment //TODO seen frequently in such code. The idea that future “refactoring” goes on the “todo” list in such an environment is completely broken. An environment that allows that to happen means it will never get done. Do it now, or don’t do it. TODO is considered harmful.

I have come around to the view that ‘//TODO’ comments should make a build fail. Either:

1. It is a future story yet to be implemented and placed into the backlog,
2. It is work in progress (and by definition doesn’t need a TODO because everything still needs to be ‘done’), or,
3. It is done, as in DONE-done, and therefore the story is complete and there’s nothing left “TO DO”.

In other words, “//TODO” is a indicator of a process that’s not letting developers get to “done”. Identify the problem, propose a counter-measure and fix the process that stopping you from getting to completion.

Firstly, I found the second day much better than the first. I did see Michael Nygard’s two talks on Monday morning and got a lot a lot of useful information from those. Titled ‘Failure comes in flavours’ the first was a great overview of the types of failure that applications running in production encounter, the second ways to avoid those failure modes. Basically it’s how many of the non-functional requirements can eat your app (and even the entire integration if you let the failure propagate easily) if you don’t give careful consideration to them. He’s got a book so I’m going to check that out next.

The first day for me was severely spoilt by a poor vendor presentation (hint: one that is not Oracle, not that they would have necessarily done any better), which I should have known better to avoid. I already swim in the BPEL/BPM/SOA soup, I fully understand just how broken it is as an actual development concept (e.g. anti-test-first to name just one). I was fooled by the title to thinking maybe it had some insights to avoid the worst of these busted concepts, but no, the vendor’s tooling is all the rage if you drink the poor-tasting conceptual kool-aid. This stuff is marketed at managers and non-coding architects who choose to buy this stuff then dump it from a very great height into the laps of the poor developers who have to mangle it into a deliverable system (half the time with a development budget just a tenth the cost of the licence). Anyway back to the good stuff.

Mike Cannon-Brookes from Atlassian (which makes great development tools, highly recommended) gave a mostly great closing speech on the first day which made me think about a couple of things. It wasn’t until the next morning however that it crystallised in my mind. It’s a bit of a minor criticism.

Mike threw out a minor line, an aside really, talking about Atlassian’s agile development methodology, and basically that said, people who say ‘you must do this’ are wrong, because they miss your context. Here ‘this’ is some type of agile process artefact like maybe, pairing, or estimating in story points, or whatever. Well, it’s wrong and on two counts. The first count I realised just after the talk but couldn’t articulate it correctly in semi-drunken conversation. That first count is very simple. Mike’s timeline on his Atlassian experience has him, if I recall correctly, starting his company and creating the great tool Jira, in his early twenties. Now as he dissed “old people” in his talk I’m going to give some back. In your twenties you’ve got no idea what works, in a general sense. You might know (or think you know) what works for you, but that’s a completely different kettle of fish to what works generally. Why not? The word is experience. Its not until you reach … oh … I’ll say around 35 (and so maybe lose the capacity to build technical innovation, perhaps, as Mike asserted) that you can have real insights into process and people. It’s just because at this point, you just have not got enough practice at it (see Malcolm Gladwell’s recent book for some basic data about the power of practice).

But the bigger point I think is the word context. The phrase ‘my context is different’, is this classic phrase which really means ‘that won’t work here’ and that really means, I don’t want to change. As a consultant , you hear this stuff all the time: … “We’re unique, our company is not like those other companies. We can’t do that here. Detailed estimates are really the most important part of the development process. The budget and the features must be fixed. We have a reporting process that allows the budget and features to be fixed. Pair programming doubles the time it takes to deliver the features. Quality doesn’t matter. Technical quality is a business decision. The business are too busy to talk to you.” … And a whole other other bunch of epic agile fail. Someone’s context is exactly why they aren’t as agile as their competitors and are looking at using ‘agile development’ to help save them … but as long as they insist on my context trumps all, they will only get a fractional improvement and not an order-of-magnitude one. But Atlassian make great products, so it doesn’t mean you have to have ‘scrum’, or ‘XP’ to do that, the greatness I guess, is orthogonal. However if you are looking to ‘do agile’, then do agile. Pick a method like Scrum or XP then do it all. How do you know pair programming will fail in your organisation if you don’t try it first? You don’t. Do it like it says to do it (e.g. the Kent Beck books) and after a few months experience for your team, use the lessons from the retrospectives that the team has discovered to improve the process. Do not cripple the process with your ‘context’ before you even try.

And right on cue, on the second day along comes Steve Hayes with a great presentation on exactly this topic: “How your choices affect your agility”. Steve is a fantastic speaker, entertaining and pretty insightful too I thought. I rated his talk the best talk of the conference. He said he got lots of red cards (participants could rate each talk as green==good, yellow==ok, red==bad) in his Sydney session – what is the matter with your people? It was a great talk. I loved the part about naivety. To propose a solution from the most naive perspective possible, and what an epic win it is when a customer says “ok”! It means I understand the problem! I even tried this today with my client, I didn’t get the instant “OK” but working from the basis of that incredibly naive solution we did manage to eventually envisage the simplest thing that could possibly work. And I love that. So thanks tons for that insight, Steve!

Another great talk on the second day was Linda Rising’s ‘Deception and Estimation’ talk. Turns out (via psychology and evolutionary biology) we engage not in rational decision making but in emotional choices all the time. All choice is emotional. So we engage ourselves in self-deception all the time. And none of this is bad … it’s good. People who don’t engage in this constant self-deception are generally clinically insane. So get over it, and yourself, and when you’re estimating (and from the sounds of it, doing any sort of major-impact decision making) and get as many perspectives as you can from the most diverse range of people you can manage (to avoid groupthink, which is I guess, the situation where everyone’s self-deceptions all align). Joshua Bloch’s second-day keynote was also highly worthy of praise. Good insight and excellent effective code examples (yes, in a keynote). Also worth the greatly discounted entry ticket price was the many interesting conversations I had with past colleagues and new friends on many different development issues.

In short, JAOO was generally of very high quality and I hope is keeps coming to Brisbane! Will definitely be going next year. Many thanks to all the organisers, presenters and sponsors.

Simply put, using nothing but a /bin/bash script and wget we scrape the latest version of the relevant artefacts from the Artifactory Maven repository. These artefacts are deployed (published) into the repository by the Hudson continuous integration build.

As they say, a picture tells a thousand words and I’ve included a schematic of the environment we have created below (image links to PDF).

In the course of all this testing though I thought it best to use it in something like real anger with the Maven release plugin rather than my rather artificial usage scenario I was building up between my two development machines.

As a result of all that I’ve released a version of my Monetary library, money-is-money. The version is 0.15 and the Maven repository for it can be found at http://modular.autonomous.org:80/artifactory-2.0.5/libs-releases-local

If you want to check the source code out with SVN out the release is at http://crazymcphee.net/svn/money/tags/money-is-money-0.15 and the latest trunk at http://crazymcphee.net/svn/money/trunk (which at the time of writing is the same as the release of course, except it generates 0.16-SNAPSHOT).

To include it into your Maven POM you’ll have to add my respository to a profile in your settings.xml:

<repositories>
  <repository>
    <id>crazy-mcphee</id>
    <url>http://modular.autonomous.org:80/artifactory-2.0.5/libs-releases-local</url>
    <snapshots>
      <enabled>false</enabled>
    </snapshots>
    <releases>
      <enabled>true</enabled>
    </releases>
  </repository>
</repositories>

At which point you can include the dependency in your pom.xml for your project:

<dependency>
  <groupId>org.autonomous</groupId>
  <artifactId>money-is-money</artifactId>
  <version>0.15</version>
</dependency>

After that Maven should fetch the artifact from my repository automatically for you. Money-Is-Money is deliberately designed to void any external dependencies on anything other than Java libs, except for JUnit which only matters if you want to build from source. For more information please see this post.