According to its release date, Architecture of the World Wide Web, First Edition shipped on the 5th of November, last month. I’m somewhat surprised that it didn’t gather more of a ripple in the blogosphere, but I’ll also freely admit that it may have and I just missed it. In any event, it seems (from an early reading) that this is must-read material for anybody who wants to grok what REST systems are like and how the Web grew to scale the way it did. Of probably the most importance is the "List of Principles, Constraints and Good Practice Notes" right after the table of contents; if ever there was an "Effective REST", this might be it.
A group of .NET consultants, including yours truly, have volunteered hours of their time for bid on eBay, with all of the proceeds to go to AcehAID.org, an organization working to help the tsunami victims in Southeast Asia. It’s an awesome opportunity for people looking for just some short advice-type consulting (or short project work, though that’s probably harder to pull off in this short a time period) to get both the attention of a world-class consultant (c’mon, when else are you going to get a chance to chat one-on-one with Jeff Richter, Clemens Vasters or Kimberly Tripp?) and help out some victims of Fate’s fickle hand all at the same time. Details are on the eBay page; if this works, we already have some tentative plans to extend it into the Java space, as well–if you’re a Java "celebrity" (their term, not mine), drop me an email if you’d be interested in helping out.
Last week I was getting ready to write up a memorial entry on December 7th, commemorating the Americans who died at Pearl Harbor, when a flashback carried me back to visiting Hawaii earlier this year, and looking around at Pearl Harbor itself at all of the Japanese tourists there and how the memorial must mean something entirely different to them. What, I can’t say, but I was struck by how many there were, almost all of them Japanese and American–very few Europeans, it seemed.
Which led me to an interesting spot; what would the reaction be, I wonder, if I were to have posted this:
I post this blog entry (on December 7th) in commemoration of the most successful surprise attack in the history of modern warfare. Never before and never since has one nation so utterly struck out of nowhere as did the brave Japanese warriors who decimated the American Pacific Fleet as it lay sleeping in its berth at Pearl Harbor. Banzai, brave warriors!
It’s just as valid a perspective on the date as any other, more "American" commemoration might be, yet clearly, because history is written by the victors, it will be in the significant minority.
The flashback carried me into an interesting line of thinking: to truly understand something, you must see from a different perspective. For example, for a Spring advocate to truly understand the foibles of EJB, I believe you must use it enough to argue its strengths, and for the EJB advocate to do the same to Spring, must do the same. For the Java developer to be able to criticize .NET, or vice versa, you have to argue for it (and implicitly against your favored position) in order to see how they see the world, and understand how the world looks to people from that perspective. What triggered the rant in the first place was the recent "Architecture of the World Wide Web" document–the Web services crowd, with its WSDL-first and (generally) RPC-oriented way of viewing the world (with all apologies to the brave few who are advocating the messaging-oriented religion), is going to essentially pooh-pooh the document as something that "may have worked then but won’t work now". And yet, I wonder, how many of those people out there building Web services ever gave REST a try?
Am I arguing that REST is "the way to go"? Perhaps, for some systems. Is the WS-* stack then the "right choice"? Again, perhaps, for some systems. But there’s clearly architectural principles in each that deserve recognition, and you’re never going to recognize them unless you try each approach and see what works and what doesn’t. Go on, give it a shot: use the other thing (be it REST, WS-*, .NET, Spring, EJB, Java, whatever) for a while. You might find you actually like it. 😉
A while back, on the advice of friends I both deeply respect and care about, I decided to take the plunge, swallow the red pill, and develop as a non-admin on my laptop. For the most part, it’s been a pretty smooth experience, thanks to the tips that Keith Brown offers up in his latest book and online wiki, except for the odd program that just doesn’t like to play by the rules. (Interestingly enough, I can’t think of a Java tool I use that’s been affected by this change–most of the headaches have come from tools that have more to do with the .NET space than the Java space. This I attribute to the fact that Unix-y folks have a rich tradition of not developing as root, so they’re accustomed to the idea and build their systems accordingly.)
One such utility that shocks me in its noncompliance is Altova’s XML Spy; when attempting to install as non-admin, it claims that the .exe is corrupted and needs to be downloaded. After installation, when you run it as non-admin and attempt to fill in the keycode, it tries to write the license file to the Program Files directory, which of course a non-admin doesn’t have access to. (Fortunately, filling out the keycode as admin and then re-running solves the problem.)
Bad Altova! No biscuit!
Particularly since this is such a simple thing–just write the license file to (a) the Registry, or (b) the user’s home directory (C:\Documents and Settings\Ted\xmlspy.lic, for example); there’s really zero need to put this into Program Files given the other options.
(And by the way, Java folks, just keep doing what you’re doing. 🙂 (Now if only we had a bit stronger configuration story, but that’s another story for another day; in fact, the strong .NET configuration story that I’ve been preaching may have a pretty huge flaw in it for precisely this same reason–you can’t write back to the .config file if it’s stored in Program Files, either. So in some respects, at least for user-configuration settings, .NET is in the same boat as Java, except it’s worse, because they lack a Preferences API equivalent. *sigh*)