Eight new audio recordings of ITWorld articles have been published on McGrath's Musings.

• Moving Mountains with Tweezers
  
• Putters, programs and prarie dogs
  
• Timing is Everything
  
• The Integration Adapter Game
  
• Testing, testing, one two three testing.
  
• Putting the soft into software
  
• In praise of IT multilingualism
  
• The impotence of numbers
  

posted by Sean 9:56 AM

[Link] . . .

I've commented on Stefan's posting.

I was a Dbase/Clipper/Smart programmer for many years.

The drill was as followed : set up you database tables. From there - without doing another *ounce* of work - you could browser the database, add records, generate simple reports.

I know of no application that allows me to do that so easily today with a web front end. Maybe I’m missing something massive.

Sean

posted by Sean 2:41 AM

[Link] . . .

... to make the keyboard beep on my spectrum. I still remember that after all these years. How sad is that?

posted by Sean 2:18 AM

[Link] . . .

"The main characteristic of an SOA is that of a loosely coupled, document-oriented interaction model, according to Hohpe. He didn't think that SOA is a new, life-changing architecture because XML messaging-based services have been around for a while."

and

"Architecture is based on patterns and intent, not technology selection, according to Hohpe. Conversation models, asynchrony, document-orientation, granularity, decoupling and management are more important."

Wisdom in a talk by Gregor Hohpe.

So, the next time somebody says to you "lets just use SOAP", say "Great!" and then ask him/her for a quick run-down of the proposed conversation models, the synch/asynch selections, the granularity, the semantics of the payloads. I'll bet you that nine times out of ten none of the above will have been thought through. SOAP hides all that stuff right?

Yeah, right.

posted by Sean 2:35 AM

[Link] . . .

"The conspicous absence of constraints in SOAP, particularly those that support interoperability is a clear indication of the vacuous nature of the specification." - Carlos Perez

Read the rest in Why REST is Better - Part 4 - Avoiding the Death March.

This is the key problem with SOAP. You can do *anything* with it. Any form of distributed computing you like!

A charitable view would be that it encompasses all philosophies and is better for it. A non-charitable view would be that SOAP is still running around, trying to find out what it itself really is, and has changed its philosophy, radically, at least twice.

When looking at the core ideas that make up REST and asynch messaging, it is absolutely true that you could do all of them in SOAP. But so what? You can do *anything* in SOAP. That is either a great strength or a great weakness, depending on your point of view.

I think it is the latter. Distributed computing is not a problem where Turing Completeness is a compelling argument. This is hard stuff. The network cannot be abstracted away. The only way the world is going to get away from integration hairballs is by latching onto real patterns of distributed computing, not uber-abstractions.

I think those patterns need to be centered around asynchronous, reliable exchange of self-descriptive Unicode messages, between resources that have unique names and standard interactions modelled on speech acts. In short, XML + Reliable HTTP + REST.

[1] http://www.dehora.net/doc/httplr/draft-httplr-00.html

posted by Sean 1:56 AM

[Link] . . .

Why REST is Better - Part 3.

posted by Sean 1:35 AM

[Link] . . .

This review is fairly typical of what I'm hearing/reading.

The new look/feel stuff is nice. The database thrown in is useful, but the XForms stuff, that could change the world. Here is the great irony of the Web. It was vastly easier to create a CRUD application (a database app with Create, Report, Update and Delete functions) in the days of Dbase II than it is today.

Sometime, somehow, we have to get that functionality back. XForms could be the way to get there in a web world. With sufficient implementation experience, profiling and ingenuity, a solution for thick client deployment should double up as a solution for client-side/thin-client deployment.

The pattern of down-translating XForms to DHTML on the server side is a powerful one. If the XSLT experience is anything to go by, server side use will significantly outstrip client side use.

Interesting times.

posted by Sean 12:53 AM

[Link] . . .

Gmail, Technorati, WinFS - cogitating reticulation.

(What?)

posted by Sean 11:59 AM

[Link] . . .

I saw an advert just now on a well known blog. the advert was from the recruitment agency dice.com. It read:

if (threshold = salary_sucks) {
goto = dice.com();
} else {
suck.it.up;
}
}


Note to dice's avertising folk: This code is almost certainly not syntactically valid in any extant programming language. Making the minimum syntactic changes to make it, say, C, leaves you with a nice semantic bug in the conditional. The expression "goto=dice.com()" is scary, as is the layout of the code itself. Not the work of a competent programmer at full throttle.

Now this is an advert not a code review but heck guys, how much effort does it take to at least make the humorous program, a believable program?

Note to programmers: If you are already getting paid to write stuff like that, maybe you should stay put because you are on a winner dude.

Note to those who think I have a somewhat anal rententive, pedantic, borderline manic-obsessive, overly-literal, borderline autistic streak: What makes you think that?

posted by Sean 3:02 AM

[Link] . . .

"I'm beginning to feel that all the disparate web service specs and fragmented standards activities are way out of control...It's either got to be simplified, or radically rethought." -- Jonathan Schwartz

[via Mark Baker]

posted by Sean 8:18 AM

[Link] . . .