Release It is now shipping!  People who ordered directly from The Pragmatic Programmers are receiving their hardcopies now.  It will take Amazon and Barnes and Noble a few days or a week to work the inventory through their supply chain, but they should be shipping soon, too!  

In Release It, I talk about users and the harm they do to our systems.  One of the toughest types of user to deal with is the flash mob.  A flash mob often results from Attacks of Self-Denial, like when you suddenly offer a $3000 laptop for $300 by mistake. When a flash mob starts to arrive, you will suddenly see a surge of TCP/IP connection requests at your load-distribution layer.

"Release It!" has been officially announced in this press release.  Andy Hunt, my editor, also posted announcements to several mailing lists. It's been a long road, so I'm thrilled to see this release. When you release a new software system, that's not the end of the process, but just the beginning of the system's life.  It is the same thing here.  Though it's taken me two years to get this book done and on the market, this is not the end of the book's creation, but the beginning of it's life.

My friend and colleague Paul Lord said, "Good marketing can kill you at any time." He was describing a failure mode that I discuss in "Release It!: Design and Deploy Production-Ready Software" as "Attacks of Self-Denial". These have all the characteristics of a distributed denial-of-service attack (DDoS), except that a company asks for it. No, I'm not blaming the victim for electronic vandalism... I mean, they actually ask for the attack.

I've seen walking cliches before.  There was this one time in the Skyway that I actually saw a guy with a white cane being led by a woman with huge dark sunglasses and a guide dog.  Today, though, I realized I was watching a design pattern played out with people instead of objects. I've used the Reactor pattern in my software before.  It's particularly helpful when you combine it with non-blocking multiplexed I/O, such as Java's NIO package.

Give individuals powers once reserved for masses Here's a common trajectory: 1. Something is so expensive that groups (or even an entire government) have to share them.  Think about mainframe computers in the Sixties. 2. The price comes down until a committed individual can own one.  Think homebrew computers in the Seventies.  The "average" person  wouldn't own one, but the dedicated geek-hobbyist would. 3. The price comes down until the average individual can own one.

I work in information technology, but my first love is science.  Particularly the hard sciences of physics and cosmology. There've been a series of experiments over the last few years that have demonstrated quantum manipulations of light and matter that approach the macroscopic realm. A recent result from Harvard (HT to Dion Stewart for the link) has gotten a lot of (incorrect) play.  It involves absorbing photons with a Bose-Einstein condensate, then reproducing identical photons at some distance in time and space.

Here's a "can't lose" way to identify a new product: Enable people to plan ahead less.  Take cell phones.  In the old days, you had to know where you were going before you left.  You had to make reservations from home.  You had to arrange a time and place to meet your kids at Disney World. Now, you can call "information" to get the number of a restaurant, so you don't have to decide where you're going until the last possible minute.

Over at The Server Side, there's a discussion about how to become an "architect".  Though TSS comments often turn into a cesspool, I couldn't resist adding my own two cents. I should also add that the title "architect" is vastly overused.  It's tossed around like a job grade on the technical ladder: associate developer, developer, senior developer, architect.  If you talk to a consulting firm, it goes more like: senior consultant (1 - 2 years experience), architect (3 - 5 years experience), senior technical architect (5+ years experience).

In 2005, I was on a team doing application development for a system that would be deployed to 600 locations. About half of those locations would not have network connections. We knew right away that deploying our application would be key, particularly since it is a "rich-client" application. (What we used to call a "fat client", before they became cool again.) Deployment had to be done by store associates, not IT.