Sam Gentile says:

[W]hen people bitch about WS-*, I don't get how its not obvious that "the main characteristics of Web services is communication over unreliable communication channels such as the Internet employing unreliable data transfer protocols such as HTTP, SMTP and FTP" and many of us need things like WS-RM and other standards to build real service-oriented systems that actually do something.

Since I've stopped being polite about WS-*, I'll bite:

It's just not the case that "real service-oriented systems that actually do something" require the WS-* stack. Very reliable, very scalable, very large systems accomplish transactions over Internet protocols without using WS-RM. iTunes has now executed over a billion transactions without using WS-RM. And, subjectively, while Internet protocols are technically unreliable, they are reliable enough for me to order books from Amazon, track packages via FedEx, send my articles and invoices via email, etc. Professionally, they're reliable enough for a POX system I architected to transact ~$100M a year in airline tickets.

WS-* advocates will probably say that the transactions involved in the examples cited above are relatively simple -- high volume, perhaps, but simple. "Financial services! Trading partners! Supply chains!" they will say. It is to these which, for years, I gave a "To be sure..." exemption. "REST works in most situations," I would say, "Although, to be sure..." and then I would capitulate. Perhaps with a high-enough volume, or a large-enough amount of money, or a time-sensitive enough clock, or a complex-enough transaction, one needed WS-*.

I no longer concede that. I say that, six or seven years into the Web Services era, the onus is on the WS-* advocates to prove the need, because the advocates of KISS approaches have, I think, amply demonstrated the viability of their approaches.

Further, let's posit for the sake of argument that reliability and re-ordering may be problems. I say that, in both those cases, the solution lies in higher, not lower, abstraction levels. If reliability is a problem, implement some form of visible ACK/NACK functionality (if you think about it, the idiom of "shopping cart checkout" that has evolved involves just such a higher-level ACK/NACK: "Press submit to finalize," "Here is the page acknowledging your order; an email has been sent to you acknowledging the order as well."). If reordering is a problem, first check for excessive conversational state, and second, put a frackin' messageOrder element in your XML. Visible, visible, visible.

Would it be better to have such functionality "for free" in a library or tool? Would such functionality be burdensome and error-prone? Sure, why not? All programming is burdensome and error-prone. But I assert that the odds of being stumped by a problem are lower in a Keep It Simple Stupid, highly-visible, higher-abstraction-level solution than they are in a WS-* architecture involving more than one vendors' service stack.

Further, I would argue that WS-* is unlikely to ultimately triumph for the very reason that it's attempting to inject a low-abstraction-level layer between a (posited-for-the-sake-of-argument) insufficient infrastructure and the business-programming domain. That may work for a single vendor, with a unified analysis of the supposed shortcomings of the infrastructure and the business-programming domain. But with multiple vendors, who not only don't share a single view, but whose view of the business-programming domain is inherently biased by their commercial interests, the confusion and slow progress that has characterized WS-* is more likely than not to continue.

Jim Gray, who did fundamental work on transaction processing and won theTuring Award, is missing off California's Farallon Islands. The good news is that weather has been good and he was sailing in a 40' yacht, which ought to provide ample shelter for a few days. The bad news is that he was sailing alone and the ocean there can be nasty (cold, choppy, etc.)

I lag behind in this brave new era.

I've been running Vista in VMWare virtual machines and having an acceptable, but not good, experience. No glass, no NUMA (one of the few interesting APIs targetting concurrency), performance less than stellar.

However, with the time at hand to install Vista to the actual boot disk, I am stymied. I have a Tyan K8W S2885, an uncommon-to-rare motherboard with an SSI EEB 3.0 form (12" x 13") that is pretty dang tight once heatsinks and cables are attached.

Vista informs me that I need to get a driver for the "Primary AMD IDE Channel" which confuses even my friends at AMD.

In order to provide Intellisense for Ruby, a language that does not have explicit typing, Ruby In Steel turns to type inference. The built-in inferencing can be aided by adding type assertions to a function, for instance:

#:return: => nil
#:arg: c => String
def Bar(c)
   @field = c
   puts @field
end

The type assertion block can be automatically added by typing "##" in the line above the function/method declaration (it fills in the type with "Object" to start). I'm a proponent of explicit typing in non-trivial projects so this is potentially a big deal to me. What I need, though (consider this a feature request, SapphireSteel) is some form of FxCop-like reporting / enforcement of type assertion "coverage."

That is, I would like to enforce a business rule "Ruby programs longer than 500 lines must have type assertions on all functions." To me, this would be a win-win: you can develop as fast-and-loose as you want, but if you want to check code into a team project, you have to add type information (which, in my mind, is extremely important to the dominant task of understanding code).

To be sure, in my experience the "DocComments" facility in VS/C# (typing "///" triggers a documentation block for the parameters) is widely ignored and FxCop enforcement is resented, but I think documenting parameters in a strongly typed language often seems gratuitous ("string firstName: a string representing the first name" and so forth), while I think everyone admits that type information is helpful for comprehension.

Here's the Ruby In Steel editing / debugging experience. Intellisense works dynamically -- as soon as you define a function, it becomes available to Intellisense. The debugging experience seems to be the standard VS one (that is, pretty darned good).

REPL functionality is provided by IRB in a console window: not ideal, but convenient. There's quick access to Rails, Rake, and Gems (see the second screenshot).

The install silently guessed wrong on my Ruby install location, which caused my very, very first "puts 2+2" to fail, but it was easy enough to guess that the issue could be fixed under Tools | Options...

So far, so good: more to come as experiences develop. I look forward to putting this head-to-head against Komodo.

Joel Spolsky's review of Dreaming in Code makes the point that Chandler is yet another high-quality data point that, contrary to the initial exhortations, Open Source is not a significantly-more-productive development methodology. It turns out that Open Source is an interesting business model (somewhat to my surprise) and that free-as-in-beer is a killer competitive strategy (Eclipse or, for that matter, IE and not surprising to anyone).

This is not to bash Chandler's ultimate deliverable: the Mozilla project would be a similar datapoint and Firefox is a great piece of software (and my choice of browser). OSS can certainly be high-quality (Apache being another exemplar). But at this point it's clear that open-source development is not inherently fast. Joel fingers lack of analysis and design as Chandler's shortcoming, but veterans (should) know that promoting A&D as inherently speedy is laughable.

I'm all for spending vast amounts of energy debating the incremental issues of languages, tools, development methodologies, design paradigms, and so forth, but let's be clear that of all the things we know about software development, there are only two things that we know to be inherently highly productive:

• Well-treated talented programmers; and
• Iterative development incorporating client feedback

I was struck by the statement "the version control system is a first order effect on software, along with two others - the build system and the bugtracker. Those choices impact absolutely everything else. Things like IDEs, by comparison, don't matter at all," in a post by Bill de hÓra. It's not 100% true -- innovations like integrated debugging (Turbo Pascal?), refactoring (IDEA), and the Smalltalk browser -- can be enormous, but there is certainly more than a grain of truth to it.

Alan Zeichick points out the absurdity of the position, touted by Microsoft, that Windows Vista will "generate" $10 billion in new revenue for the California IT industry this year. Alan observes that IT revenue means that "someone else's costs have to go up" and that it's perverse to "celebrate a software update when its creator boasts that it will increase the cost of IT." Good for those who charge for technology per se, but bad for dentists, manufacturers, schools, restaurants, and others in the large majority of business who do not directly profit from work in IT.

There are those who say that American's time is past. That this great country, this bastion of ingenuity, has lost it's spark, it's insight, it's entrepreneurial spirit. To those people, I give molecular biologist Robert Bohannon, who has figured out how to mask the bitterness of caffeine in pastry, opening the way to The Buzz Donut.

I think this is a complete answer to the question of America's greatness in the 21st century.

Hard on the heels of Ruby In Steel's debut, Komodo 4 was released today. This new version supports Ruby and RoR. via Binstock on Software.

I need to flash my motherboard BIOS in order to install Vista on my dual-processor desktop (I hope that will do the trick). I don't have a floppy drive anymore, not on any machine. I can't believe what a problem this has turned into. I go through my half-a-dozen rescue CDs -- all of them are either utility-specific or Linux-based. The flash program from Tyan, though, is DOS-based. I started to follow the instructions to make a bootable thumbdrive, but they rely on a bootsect.bin extracted from a floppy! Back to square one. (P.S. Please don't send me a bootsect.bin -- I'm a trusting soul, but I'm not that trusting.)

I wish Microsoft had a "format thumbdrive to boot DOS" utility.

Ooh, this is tough; I've received a couple one-a-day challenges that are on things that I really do need to do. Jimmy Norton invited me into the Flickr Project 365 challenge, which is to post an image a day for a year. I am always dismayed to realize how little I photograph Hawai'i, which is an incredibly beautiful place undergoing profound changes. Plus, if I did more photography, I'd have an excuse to buy a digital SLR.

Worse, Dan Ciruli called me out for his pushup challenge, which is "do 1 pushup and 1 crunch on day 1, 2 on day 2, 3 on day 3, etc." I hurt my back for the first time in my life a few months ago and know that the lesson is that I have to strengthen my core (#1 way to help your back: strengthen your gut). Plus, although I'm pretty fit aerobically, I have very little upper-body strength, so pushups are good for me, too.

I wonder if I should counter-challenge: "On day 1, swim a distance of 1' underwater..."

(Photo is me on the bottom at ~80')

Peter Coffee, who's been providing some of the most insightful, technically-based discussions of the IT and software industries for 18 years, has left eWeekto become Director of Platform Research at Salesforce.com. This is a significant loss to the field (although I am sure a great benefit to Salesforce.com). When I was an editor, especially at AI Expert, Peter used to keep me honest with pointed questions about the depth and accuracy of what we were publishing; one of my major regrets of my tenure as an editor is that I never got Peter to write for me.

In the years since, I've always looked forward to his columns. Peter always provided a great enterprise-level focus to his discussions, even as he stayed grounded in the realities of the programming experience. I think he's the most trustworthy development tool reviewer of the past decade, providing an invaluable service to countless developers at thousands of companies.

Well, so it goes. I wish the best to Peter and his family on this new direction....

Ruby programmers using Windows should definitely give this a look; this is very high on my "IDEs to look out for" list. It should be noted that this is not a CLR / .NET-based Ruby; it's a plug-in to Visual Studio (Standard Edition and above; unfortunately, VS Express users are out of luck) that targets the standard Ruby interpreter.

Although Scite has it's charms (like loading in a fraction of a second), VS is definitely a superior environment for extended development.

Scott Hanselman goes ga-ga for the SideShow API, the Vista functions for auxiliary displays. When I was first told about SideShow quite a while ago, the emphasis was on displays embedded in the outer shell of the notebook, just as clamshell phones often have a little aux display on their surface. I wrote an article back in 2004 in which I was more excited about "REM mode" applications (applications which can be run by a computer that's somewhere between hibernating and fully awake) than by the aux display itself.

Happily, the SideShow APIs seem to be fully decoupled from the physical attachment of the display, so Scott's excitement is primarily about using the SideShow APIs from one's main desktop machine to drive alternate displays.

Wesner Moise points to "generalized regular expression matching" as a moderately hard problem that might serve as the basis for comparing programming languages and approaches. He says "Microsoft's implementation of regular expression matching over strings is spread across 24 files and 14,455 lines of code including comments and whitespace." (I'm not sure how he'd know that -- I assume he's talking about Rotor source code.)

He wonders if a functional approach could be more efficient and points to a 14-line Python program.

No, no, no: they are two incredibly different capabilities.

The Python program implements something like the original definition of a regular expression --restricted to that which can be expressed in a single line of Extended Backus-Naur Form without recursion. "Regular expression support" for today's languages means something very, very different, starting with compatibility with Perl5 and going from there. Backslashes, named groups, etc. are complex features that require, in any language, something in excess of 14 lines.

Having said that, regular expressions are a good fit for functional approaches. But, just to point out the lack of silver bullets, attempting to parse a left-recursive grammar (a grammar with a production of the form A->AB) will hang a simplistic recursive-descent parser.  

Tim O'Reilly posts his always-intriguing quarterly analysis of the tech book sector.

Joe Gregorio interprets the 53% growth in sales of Ruby-based books as evidence that there is no "next Java" or "next framework." I'm sympathetic with his thesis, but I'm not sure that 53% growth counts as any kind of failure...

Andrew Binstock shares the advice he gives when vendors call to ask why they didn't become finalists.

Alan Zeichick's proposal of an organizational Threading Maturity Model is an excellent contribution. As with object-orientation, it does not suffice for a single person to have mastery or near-mastery; the average ability of the team must be fair in order to maintain quality, chaos can be wrought by just one or two who are unaware, and reaching the higher levels requires cultivating talent for long enough for mastery to become part of the culture. However, the TMM isn't very descriptive of individual progress and does not provide guidance. I thought that I'd take a crack at a Personal Thread Maturity Model (PTMM) that might be a complementary effort. Opinions more than welcome.

1. Unaware: Single-threaded, may occasionally use threaded libraries unawares

The first level of concurrent programming is no conscious use of concurrence at all. Since no mainstream language makes threads a first-class concern, threads are only used as, essentially side-effects, in library and infrastructure calls. No useful recommendations can be made for programmers in this category, as by definition they are not part of the conversation.

2. Casual: Conscious use of high-level abstractions (components, libraries) to solve specific problems

Today, the large majority of programmers are in this category. They are aware of threads and their ability to run a lengthy calculation or IO operation while maintaining a responsive UI. They may use a drag-and-drop component or a Thread object that allows a calculation to run to completion. Their experience with threading is generally positive: the UI remains responsive, the network calls back, etc. They may be taken aback by all the dire warnings about multithreading that are so common to discussions.

Recommendations: Continue! "The simplest multithreading that can possibly work" often does! Become comfortable with callbacks and asynchronous patterns (in .NET, the Event-based Asynchronous Pattern). Avoid guaranteed trouble spots: don't update the UI from a worker thread, don't rely on shared data maintaining its state, don't try to roll your own synchronization techniques.

3. Rigid: Significant use of multiple cores, coordination based on locking

In this stage, programmers move from using threading as a pain-relief mechanism to a benefit that can be actively exploited. Asynchronous processing becomes an intentional part of design. They face their first wicked problems and gnarly bugs and become initiates in the "threading is hard" camp. Their designs focus on the use of locking to coordinate their programs; while they may occasionally use other techniques, locking is the hammer with which they pound the nail of concurrency.

Recommendations: The problem for this group is complacency. They've triumphed over problems and may have reached a plateau. They discover that core logic is often non-parallel and, although willing, may have a difficult time seeing places where asynchrony can contribute. At this level of mastery it may not be clear on today's hardware that further learning is necessary. Unfortunately, since manycore machines are not yet available and few of us have access to parallel clusters, moving beyond this level of maturity is driven more by faith and reading than by hands-on experience.

4. Flexible: Attempt to maximize use of cores, use of lock-free algorithms and data structures

This level is characterized by a deeper theoretical understanding of asynchronous processing, mastery of basic techniques, and determination to achieve the best results possible. Programmers at this level seek, not just to exploit their processors, but to saturate them. This stage is additionally characterized by a shift from programming-language-based thinking to hardware-based thinking.

Recommendations: This is a very difficult phase to move through. Popular texts will not guide you past this stage, advancement requires a combination of textbook theory, hardware knowledge, and hands-on experience. (I'm not going to claim to have moved beyond this phase myself.)

5. Optimizing: Optimal use of parallel architecture

Parallelism is fully incorporated into one's mental approach to solving problems via symbols. Specific techniques are considered not along any "better-worse" axis, but for their individual benefits and drawbacks. Multiple approaches may be incorporated into a single design. The world appears as falling strings of glowing numbers, bullets can be dodged, and Agent Smith can be defeated.

My latest in SD Times is up, in which I decide to stop being polite about WS-*.