Church Turing reduction - the vendor way

I'm sitting at QCon today getting some work done and I've overheard a bunch of vendors brilliantly apply the Church Turing Thesis to their products. The bit they use is the "any solvable problem can be reduced to a previously solved problem" and the conversation goes a bit like this

Vendor: So what are you looking at?
Customer: We are currently trying to solve the grand unified theory of everything/build a web-site/integrate our ERPs
Vendor: Well of course the most complex part of that challenge is the clustering/framework/distribution/deployment/management and its that bit which everything else relies on to work.
Customer: Well isn't that just a technology piece of the puzzle?
Vendor: Oh no, its what everything relies on, its basically the central part of everything.
Customer: Why is it so important?
Vendor: Well without clustering/framework/flying monkeys/deployment/management then nothing else will work and you will have complete chaos
Customer: But my last project worked and I didn't have your product
Vendor: But did you have problems?
Customer: Of course there are always problems
Vendor: This would remove all of those problems
Customer: But the problems had nothing to do with what your product does
Vendor: Well how you see the problems isn't where our product works, but not having our product is what manifested itself in the issues you saw
Customer: Errr sure.... give me a leaflet then.... errr I don't have any business cards on me at the moment....

Its amazing how so many things are the "central" part of IT, hell the centre of IT appears to be so big its where everything is, like a great big black hole that sucks in all the light. Sure I know they are just trying to make a living, but do they really think that claiming to be the cause of the big bang is really going to help their sale?

Technorati Tags: SOA, Service Architecture

If I can't test my app, you don't have a product

One thing that is really beginning to irritate me with the pace of "progress" in Service Oriented Development technologies is how much is made of the new bell or whistle, and how little time is dedicated to making that facility actually operational. So we see a new tool that can only be deployed with an IDE, or a process engine with no async testing tool or a deployment process that has no audit trail.

What this leads to is great demos, bad projects and woeful operation. There really is no excuse these days to not have the basics done this means

1) Scripting of deployment, ideally with a supplied ant task
2) Test generation "answer", ideally as part of the suite, again this must be executable outside the IDE (e.g. from ant)
3) Security on deployment and logging

Having a "partnership" with someone who does these bits is fine, as long as its bundled and I don't have to pay more money for it. Having a "user" testing product isn't acceptable as that is UAT (the most expensive form of testing) and I'm after unit and system test.

If I can't professionally build, test and deploy my application on your product, then your product isn't professional.

Technorati Tags: product

Why trusting the consumer is dumb...

I've seen some pretty dumb things in my time but today, crossing into San Francisco over the Bay Bridge I saw what ranks right up there with the dumbest things I've ever seen. Its also an object lesson in why expecting consumers to behave in the way you want and not doing something different (whether good or bad) is a strategy that is doomed to fail. Any strategy that expects consumers to "remember" information correctly and not prat about with it is going to fail, any strategy that assumes that consumers will always do only what you want is going to fail.

Watch this video and remember... this is an object lesson in why your service (or resource) won't be used in the way you expect.

I decided not to embed the vid into the post as that seemed a bit anti social. So One car, one seat, one phone, one woman and her dog is best watched over at you-tube. Apologies for the swearing but it was a very big truck.

Technorati Tags: SOA, Service Architecture

The Blog based, RSS using, Yahoo pipe executed Carbon footprint calculator

I've had an idea for a while which started when I did the Geo ripping Wikipedia thing that created a web service. The idea was to have an easy way for me to calculate my carbon footprint, not the one for the house and those things but one that actually took into account how much I travel.

I also set myself another task and that was to achieve this end using communication technologies I hadn't used in that way before. So this ruled out using WS, and led me straight towards the world of POX... or is it REST, I'm not sure I can tell :)

Now taking my own advice and separating "Service" from invocation using a Facade to enable WS and REST on the same code base I quickly knocked up a servlet that takes in a place name (or a geo coord) and returns it as an RSS encoded entry. It also takes in a transport type (more of that later) which is basically to enable pass through. The Place search Pipe uses the same backend service as the WS service, with information ripped from Wikipedia.

Next up is to then have a source of information that will make this all useful. Welcome to Blogger as a data store: My trip blog is just test data (except the last destination for which I leave today). This gave me an input RSS feed that could then be consumed by another pipe, the next pipe is a bit more complex. Firstly it takes in a feed and then orders by date (the opposite way around to most feeds) and then it uses that information to call the first pipe to obtain a geo-tagged set of information. This Geotagging Pipe turns the blog feed into a set of points.

The final pipe in this stage is then one that is meant for cloning by other people if they want to do the same (thinking of the consumer's view) that one can be found here (NB you need to look at the RSS to get the real info).

Stage two of this exercise was then to have something that would take that RSS feed and do all the calculations. Again a quick bit of development followed by fronting using Rome and the next stage was ready. Using the JCoord library to do the distance calculations and taking the carbon numbers from The National Energy Foundation the next servlet was soon deployed. So back into Yahoo Pipes it was, this time taking the URI of the generated feed which is then passed to the new servlet which then returns its resuts as another RSS feed. The carbon calculation Pipe takes an input (as text because Yahoo pipes kept trying to be clever when I used a URL builder) of the Pipe generated RSS feed and then dumps it to the servlet. A Consumer focused (clonable) implementation for my feed is then available here.

Okay so there you have it a few hours of working and its all working, taking information geo ripped from Wikipedia, a blog feed and a bunch of servlets all done using RSS.

Now there is one slight issue here. I've got the carbon calculations for "train", "plane" and "car" but for some reason when you debug the feeds it shows the categories correctly but the deployed pipe is devoid of any category information, so at the moment this means all journeys are calculated based on flying. Other issues are that the database isn't complete (I need to update my regexp stuff to catch some more entries) and the search is currently "first" rather than "best" so London = London borough of Croydon.

Next step (obviously) is to take that feed and turn it into a GoogleMap.

Now one question I have is... did I "do" REST?

If I have time at the station I might lob up a picture of how it all works.

Technorati Tags: SOA, Yahoo Pipes, RSS

REST isn't about the enterprise.... its about fixing the world (apparently)

Now I've been playing around recently with REST, there are even some projects at work using it (mainly around front end stuff, WS tends to do the heavy lifting) and pretty much its working well for developer to developer constrained domains (i.e. not 3rd party integration) and I'm even thinking of applying for the REST JSR to make sure it doesn't go all fan boy and complex.

But in terms of sheer gobsmacking appeals the paper that Pete Lacey will be presenting at W3C next week surely wins the IT hubris award for the REST crowd. The majority of the abstract reads as a moan that "people don't get it" the three key points for Pete are

* The implied blessing of SOAP, WSDL, and other web service standards, by the W3C, thus leading people to believe that SOAP is the one true way to achieve a world wide web of services.
* Concordant with this, the lack of education, standardization efforts, or general evangelism by the W3C to further promote the proper use of REST.
* The tendency of enterprise software vendors and enterprises themselves to continually reinvent well understood enterprise middleware systems.

I'm loving the last one, particularly as Pete is actually asking W3C to champion REST to the exclusion of enterprise focused work. This to me is exactly what I expected to happen when I was writing REST v WS is pointless, all we have here is another camp claiming that their way of shifting documents between servers is the best and thinking that this technical implementation approach will deliver the benefits to the world. Now explicit in Pete's paper is the idea that Enterprise problems are not worthy of consideration by such an august body as the W3C.

Finally, the W3C should divorce itself from all efforts that further the technological needs of the enterprise at the expense of the world.

This is what really irks me about IT, the perception that "the world" really cares about REST v WS. What Pete means is "cool developers" rather than "employed professionals" and the gripe that Pete's chosen approach just isn't getting the focus it deserves and needs the W3C to stop worrying about all those big companies that actually fund the W3C and concentrate on an idealised view of what will help the world.

What will help the world is fixing the enterprise problems, this is where the money is generated and where the most people are employed. The problems in both the world and the enterprise are not going to be fixed by a different way of exchanging XML documents and to claim otherwise is just silly. REST should survive or die based on its support and its proponents should look to themselves if they feel that it isn't getting the visibility that they think it deserves. Personally I think this argument is just a huge waste of resources that could be better focused on understanding interaction models (which neither REST nor WS does) and on simple modelling approaches for difficult problems.

The final thing I'd like to say on this is that the "world" v "enterprise" argument was exactly the same one used by Mark Reinhold to justify JavaSE 6 and the inclusion of JAX-WS into the basic Java release. Claiming you are addressing the "world" rather than the enterprise is just bollocks, the reality is you are just avoiding the difficult questions to get your personal agenda accepted.

Technorati Tags: SOA, REST

Narcissistic IT, same old challenge, same old idiots

One of the wonders of the web is RSS, its one of those things where people used to say "how do you keep up to date" and the answer was I use a large amount of RSS feeds, but unfortunately they don't have the sophistication of Emacs' newsreader. Well today I saw that brilliant old IT challenge of "If I can do it in less characters, then it must be more effective" now there are only two problems with this argument, firstly its bollocks, and secondly its... bollocks. Now I know that strictly speaking this is only one problem, but its such a big one I thought I'd point it out twice (name that TV programme?).

I came across this challenge in two guises, the first "impressed me" that a library call in Ruby could do lots of things and the second went for the traditional Java sucks angle against scripting languages.

Now these would be wonderfully astute calls if they hadn't been made every year since I entered IT. The only problem is that the ability of the people arguing has gone massively down. When I first got into IT it was the LISP people arguing that they could do anything in less characters than anyone else, and they were right. This was because they used a functional programming language and really understood IT. They never ever thought that a scripting language was the best way, and indeed nobody did because a strongly typed and formal language had much better performance and that meant performance in project teams which is what is important after all.

IT suffers from a massive dumbing down, people make arguments based on out right stupidity, a stupidity based on little or no understanding of the principles of computer science. The complexity of IT is ever increasing but the average intelligence is plunging. Things that were plain dumb 10 years ago are now being promoted as "best practice", not because they have become good ideas but because there is a volume (as in barrel) of people who think that their mickey mouse experience is all that anyone ever needs to know.

This is one of the most depressing things about IT. When the LISP boys used to show off at least you could stare in wonder at what they'd done. Having a library that does time conversion isn't exactly the most impressive thing I've seen, its not even the most impressive thing I've see my dogs do today, and the "I can write code really quick in this scripting language" is a great lesson in the "I don't have a clue about TCO" problem that IT has always suffered from. Just for once it would be nice to see people shout out about "I used this and 5 years later people were still able to make changes" or "I wrote this code and the developer sitting next to me understood it".

Maintenance is the hardest part of IT, writing code that survives for 5, 10 or even 20 years should be an achievement, not writing something 20 seconds quicker than the bloke sitting next to you. It would be nice to see people laud languages because of the features they have that make support easier, facilities that make monitoring easier or just pieces that make deployment easier. There is something seriously wrong in IT when every new generation comes along and makes exactly the same mistakes that the muppets of the previous generation made, but worse than that where previously the muppets were small in number they now appear to be pretty much the majority of IT.

This is a major challenge for IT, and in particular the current challenges of SOA and participation based systems. Sure someone can knock up a glorified FTP site with a GUI (YouTube anyone?) but what about doing real, active, participation and creating real business value on existing systems?

As long as IT is dominated by people whose perspective is I can code in this quicker, like really cool dude then it will continue to be perceived as a profession dominated by an obsession of itself rather than an obsession with improving what it does.

Technorati Tags: PHP, Java, Ruby