Edd on Mono

Good article on mono by Edd Dumbill. Mono is a from-left-field but increasingly interesting candidate for default-linux-development-stack. Add in IronPython and ... oh dear, I'm drooling like Homer Simpson.

Generating documentation from W3C XML schemas - xs3p

XSDs are, um, challenging to read in source form. Thats one of the reasons why I prefer to keep all my schemas in RelaxNG compact syntax notation and use trang to create XSDs. xs3p is a wonderful (although equally challenging to read!) XSLT stlyesheet that does a good job of generating a human readable version.
The ingenuity, tenacity and sang-froid required to (a) grok W3C XML schemas sufficiently well and *then* (b) process instances of the stuff into a human readable form; all within the confines of XSLT, is breath taking.

XML Namespaces - thought required

"The lesson is not to use XML namespaces as a reflex. Think carefully about why and how you plan to use any namespaces you introduce." [Uche Ogbuji

Amen.

Security through acccountability

A conversation with Dan Geer is available in audio and text formats. Well worth a read/listen.

Rapid application development and the art of throwing things away

Rapid application development and the art of throwing things away is an ITWorld article on the powerful but financially counter-intuitive notion that developing something, then throwing it away, makes absolute businesss sense.

The real web services model

"Bruce Eckel: The way I see web services, it's almost like you're saying the machine is the object. I can call methods on the machine, which can be anything. And the machine can be implemented in anything.
Eric Gunnerson: Yeah, exactly. That's really the web services model.
[http://www.artima.com/intv/dotnet2.html]

I normally find myself in agreement with Bruce but not on this one. The way I see web services, its almost like your saying the machine doesn't matter. What matters is the abstraction of the machines behaviour - a "service". You send it messages (in XML typically), it responds to messages (in XML typically). The service has a URI. That URI "understands" a number of standard "methods" (if you wish to call them that). These standard methods, shared by all services, allow you to build systems in terms of "objects" (if you want to use that word) that do not move. They live at URIs and are exposed through a standard interface. With this abstraction, you build systems in terms of sending/receiving object representations using an application protocol - HTTP.
HTTP comes out of the box with a well proven set of standard "methods" GET, POST, PUT, DELETE. This goes a long way to providing what you need to do real web services. Add semantic XML, crafted to the specific business requirements and your are off and running.
The level of indirection that the standard interface+payload gives you makes it much easier to evolve back end systems. Systems spend most of their lives in "maintenace mode". Thats where you really blow some serious money and great wads of it can be traced to tight binding of service-specific APIs.
The trick, if you really want to make a leap forward with Web Services is to jettison the notion that per-object interfaces are the way to build distributed, multi-owner systems. We know enough about the behavior of real world systems to know that this model has problems. We also know that we see the same set of subtextual semantics over and over again in object APIS. "Get me this", "update this", "overwrite this with this", "zap this". The genius of HTTP is that it provides a way of factoring out this common sub-textual semantics of all distributed applications and provides it for you out of the box. Allowing you to concentrate on the specifics of your services and their value-added functionality.

Packing for Pycon? Use a Zython.

The perfectly pythonic laptop backpack.

12 men or 13?

A cute trick : 12 or 13 men? . Wait for the redraw.

Blogging conference in Dublin?

Karlin Lillington has a great idea for a blogging conference in Dublin. I wouldn't be attending if it went ahead (obviously) but wish the idea well on its memetic circumnavigation of the noosphere.

More on duck typing from Carlos Perez

Carlos writes some interesting stuff on the problems with rigid, top down data modelling. Of particular interest is Conway's Law - an example of a human issue which must be taken on board in any EAI strategy.