Say what you want about the English weather, food or even their sense of humour, but they are usually eloquent speaker.

Andrew Watson from OMG demonstrated this with his talk about Application Integration with Model Driven Architecture. Style aside, the topic is quite interesting although still somewhat controversially discussed especially among programmers. "Take the complexity out of programming… - impossible". He countered this argument by describing how the level of abstraction got raised by the advent of new tools in the mainstream such as assemblers, compilers, garbage collection… and of course faster computers.

I’m back in Germany so let me live up to the general sentiment and start with the complaints about OOP day 2:

Frank Buschmann, Tha Man of Patterns in Germany, gave a talk about Patterns and Practices of Building Scalable Software, which he filled with a problem description (at least half) but not much of concrete solutions. Although I did take a new nomenclature out of it – Functional versus Operational Scalability – the problem is widely known and apparently revolutionary inspirations are not in sight. Ok, he did give me a few ideas for further studies, esp. Product Line Architecture and a few architectural patterns, which was more than the Oracle keynote delivered.

Germans love taxonomies and they are also known to live up to their promises. While I still try to organize the virtual world in patterns, underlying commonalities and structures, my track record on Percs has been nothing to speak of or link to for the past 9 month.

Reasons are many, excuses are few - so I will use the opportunity of a visit at the OOP in Munich for a daily blog on PerCs telling you what the German speaking community is up to in the areas mentioned in the title:

Although their have been substantial contributions in the other areas listed above, Agile Development is driven by the American way of doing business, the pressures of the market and the somewhat greater flexibility and risk taking attitude in the U.S. That’s not to say that European development teams haven’t embraced Agile, XP, Scrum et al. but the current group of core experts works in the U.S.

The morning started out with an interesting problem: I need a variable size array of value types (integers in that particular case) ArrayList would be the weapon of choice if you don't need highest performance, or just use int[] and write the array resizing code for the nth time. I didn't have the inclination for either solution so I resorted to an unusual solution - give the problem some thought. As a result, I found a few things that were news to me, and that I would like to share.

First, I wrote a little program to see check out the different assignment mechanisms:

This is a quick follow up to the Grid Computing column of a couple weeks ago.

As suspected, there is a product called videoclix (and probably others) that allows to create hotspots in a video where you can click into a streaming video and – of course – buy stuff. It supports everything Quicktime supports including DV, which means it works on low level formats. It is not a real-time solution though, which is not required for the content creation and marketing customers for whom this product seems to be developed. They say they add about 20K of metadata to each minute of video, which seems to be minimal for the use I envision.

180+ assemblies – that sounds like a large enterprise project. Being in the midst of such a project, it sounds more like the virtual equivalent of urban sprawl: Traffic congestions wherever I want to go. One recent justification to add yet another assembly: “I don’t have the time to check for those circular references…”

Interestingly enough, my past experience shows that agile methodologies actually foster such thinking. Of course, we are “designing all the time”, but we are also just designing only “as far as the eye can see”, and deployment is usually behind our development horizon. When deadlines are approaching we all want our code to live in nice houses of its own instead of sharing an apartment building with the code of other developers. It is just “easier”, and unless a rigid yet enforceable component layout has been established upfront, we always opt for the “easier” solution.

Turned off by another buzzword driven column? Stay with me – I actually want to discuss a quite different topic than the talked up combining of hardware across a network (gridcomputing.com is a good place to find information about distributed computing)

Grids are a favorite mean to layout complex business data, and – combined with other widgets such as tree views – allow the user to analyze processes otherwise not easily comprehensible. A lot of computing goes into the real-time preparation and rendering of those grids, hence I call it “grid computing”.

No, this is not a political column, rather another post on the topic of TDD.

A friend of mine and fellow architect wrote: “What about the loss of objectivity when a developer specifies his own test cases? It must require a conscientious mindset.” What about it? Fortunately, the blog format doesn’t require one to give answers rather one can just post opinions. I am debating this issue myself. How can we ask a developer to provide an all-inclusive set of tests even in the purely hypothetical case of a complete spec?

First of all, if we are following the mantra of TDD – add a test, get it to fail, and write code to pass the test – the initial set will not be complete. We then iterate in small steps to eventually achieve a sufficient level of confidence that the solution just meets the acceptance criteria set forth by the client. Thus, we asymptotically approach the perfect test set reaching it after an infinitesimal long time period or as soon as the system is decommissioned.

I’m here in the trenches fighting for Test Driven Development (TDD), while Rjae is providing us with insight into up and coming technologies. A contradiction? Percs is not the place for discussing issues at the ground level of technical innovation?

We don’t think so! After all, if web services will be our future for defining a contract both metaphorically and soon probably legally speaking, we need a better way to both enforce and verify its implementation and fulfillment.

So start with an interface definition, which can be a wsdl, business spec, interface, or whatever else you have (even a verbal from your client will do) and write a test. Make the test work and then write your implementation, and you will be able to sleep at night while your service services clients in an 24x7 global environment.