Friday, March 18, 2005
Python wins Jolt productivity award 2005
Python wins Jolt productivity award 2005.
Oh ye, who do not use Python yet. What part of "increase productivity" don't you understand :-)
. . .
Thursday, March 17, 2005
Goopy see, Goopy do
A collection of Python code for functional programming. Open Sourced by some crowd called Google, whoever they are.
. . .
Wednesday, March 16, 2005
Interested in the future of programming (otherwise known as Dynamic Languages?)
IF so, read this, then install this while reading this piece of Native American lore.
. . .
Tuesday, March 15, 2005
For St. Patrick's Day
Originally published here but reproduced for the week thats in it.
In a dramatic development, scholars working in Newgrange, Ireland, have deciphered an Ogham stone thought to have been carved by St. Patrick himself. The text on the stone predicts, with incredible accuracy, the trials-and-tribulations of IT professionals in the early 21st century. Calls are mounting for St. Patrick to be named the patron saint of Markup Technologists.
The full transcription of the Ogham stone is presented here for the first time:
Go placidly amid the noise and haste and remember what peace there may be in silence.
As far as possible, without surrender, accommodate the bizarre tag names and strange attribute naming conventions of others.
Speak your truth quietly and clearly, making liberal use of UML diagrams.
Listen to others, even the dull and ignorant, they too have their story and won't shut up until you have heard it.
Avoid loud style sheets and aggressive time scales, they are vexations to the spirit. If you compare your schemas with others, you will become vain and bitter for there will always be schemas greater and lesser than yours -- even if yours are auto-generated.
Enjoy the systems you ship as well as your plans for new ones.
Keep interested in your own career, however humble. It's a real possession in the changing fortunes of time and Cobol may yet make a comeback.
Exercise caution in your use of namespaces for the world is full of namespace semantic trickery. Let this not blind you to what virtue there is in namespace-free markup. Many applications live quite happily without them.
Be yourself. Especially do not feign a working knowledge of RDF where no such knowledge exists. Neither be cynical about Relax NG; for in the face of all aridity and disenchantment in the world of markup, James Clark is as perennial as the grass.
Take kindly the counsel of the years, gracefully surrendering the things of youth such as control over the authoring subsystems and any notion that you can dictate a directory structure for use by others.
Nurture strength of spirit to nourish you in sudden misfortune but do not distress yourself with dark imaginings of wholesale code re-writes.
Many fears are born of fatigue and loneliness. If you cannot make that XML document parse, go get a pizza and come back to it.
Beyond a wholesome discipline, be gentle with yourself.
Loosen your content models to help your code on its way, your boss will probably never notice.
You are a child of the universe no less than the trees and all other acyclic graphs; you have a right to be here.
And whether or not it is clear to you, no doubt the universe is unfolding as it should.
Therefore be at peace with your code, however knotted it may be. And whatever your labors and aspirations, in the noisy confusion of life, keep peace with your shelf of manuals. With all its sham, drudgery, and broken dreams, software development is a pretty cool thing to do with your head.
Be cheerful. Strive to be happy.
. . .
APIs, outsourcing and Open Source
This weeks ITWorld e-Business in the Enterprise article : APIs, outsourcing and Open Source.
. . .
Sunday, March 13, 2005
Behind the firewall, nobody can hear you scream.
In the recent blogstorm about SOAP/REST a theme is emerging. SOAP
proponents point out that SOAP is a great success behind firewalls -
enterprise applications and all that. Therefore SOAP is a great
Hmmm. I do not doubt for one second that SOAP is being used
extensively behind firewalls but my personal experience has been
1. Behind firewalls, SOAP is the bright shiny new RMI/CORBA/DCOM. It
is used as an Object Invocation/RPC mechanism. SOAP proponents keep
pointing out that you do not have to use SOAP that way. True, but 99
times out of 100, that is how I see it being used behind firewalls. If
it walks like a duck, etc.
2. Behind firewalls, network-related "ilities" can be swept under the
carpet given enough money and end-to-end control. Given given that you
have end-to-end ownership of the system, you can control network
latency and control network availability. Given enough money, you can
"upgrade" applications with super-duper fast processors and disks and
bandwidth to be able to survive in the temporally coupled, distributed
systems world that comes with Object Invocation/RPC-style SOAP.
3. Behind firewalls, you can get around interoperability problems by
the simple expedient of putting the same SOAP stack on all end-points.
4. Behind firewalls, IT folk quite rightly and quite understandably
keep their SOAP problems to themselves and they keep Cap Exp and TCO
to themselves. "Success" stories are the only type of stories the
private sector admits to. This is totally understandable but can skew
the perceptions of what is really going on.
So, how does all this relate to my opposition to SOAP and the
particular spin on SOA that is so prevalent at the moment?
1. SOAP is not being used the way its advocates now say it can and
should be used e.g. one-way, asynch, unreliable messaging with stuff
like reliablility etc. layered on top with WS-*. Is this a retrievable
situation? Will it be possible to move the perception of the "brand"
to one way, asynchronous, message-centric thinking which is necessary
for SOAP to be of any real benefit in this world? I don't
know. Personally I think there is too much history, too many "oh but
you don't have to do it that way" turnarounds, too much cruft, too
little help for non-specialists to guide them to a good design.
2-4. On the Internet, or on Intranets, you cannot control the
"ilities" and you cannot dictate technology stacks to the
end-points. Consequently, the Internet/Intranet is a great environment
for developing distributed systems technology that is both cost
effective and highly interoperable. Is it coincidental that CORBA was
a great success behind firewalls and DOA on the internet? I don't
We keep hearing the SOAP is a great success behind firewalls in
"enterprise class" applications. Maybe, just maybe, "Enterprise
class", in this context, means folk with money to throw at the
problem. Folk with end-to-end control who can design away the network,
the latency, unreliability, all that stuff through money, diktat and
It is no great surprise to me that SOAP can be made to work - for a
given definition of "work" - in that sort of Enterprise Class
Behind the firewall, nobody can hear you scream and nobody can see
your wallet bleed.
. . .
. . .