James Bach recently blogged about something I've been saying in conversations with friends and conference attendees: there ain't no such thing as a "best practice".

He lays out his points in a letter to his blog readers, and I want to comment on a few of them.

First, "There are no best practices. By this I mean there is no practice that is better than all other possible practices, regardless of the context. In other words, no matter what the practice and how valuable it may be in one context, I can destroy it by altering things about the situation surrounding the practice." James hits the nail on the head with this one: any practice, taken out of context, can easily be turned from "best practice" to a "worst practice" without too much difficulty. The patterns guys had it down: A Pattern, or let's call it practice, so that we can talk more about concrete things, is a Solution to a Problem within a given Context that yields certain Consequences. You cannot avoid this basic relationship. (The patterns guys then wanted to take practices, examine them across domains, and find the commonality and elevate it so that we could apply them in a domain-independent manner; hence the reasoning behind the Rule of Three, which so many pattern "writers" seem to miss.) It makes sense, even on an intuitive level: I walk into a doctor's office, and say, "I have a cough". What's the Best Practice here? Meds? Diet and exercise? Immediate surgery? It clearly depends on the context--other symptoms, the pervasiveness of the cough, the reasons behind the cough, and so on. Doctors who fail to establish the Context before offering a Solution are often called Quacks... or sued for malpractice.

He goes on to say, "Although some things that don't exist can be useful as rhetorical signposts, "best practice" is not one of them. There is nothing honorable you get from pretending that a practice is best that you can't also get from suggesting that a practice may be good in a specified context, and making a case for that. Sure, there are dishonorable things you can get from "best practice" rhetoric-- say, causing a dull-witted client to give you money. If that has tempted you in the past, I urge you to reform." Unfortunately, the temptation is too strong, particularly for those who are pushing a new platform upon the world. Java got tremendous success from pushing patterns rather than canned solutions (and I think we pushed too many patterns, not enough practices, to be honest), and so now it seems a requirement for any new platform that in addition to the platform, you need to have an established set of practices with it to help guide the newbies to the platform. After all, how comforting does it sound when somebody seeking to sell you on a new platform, when asked "So how do I use this thing best?" turns to you and says, "We really don't know yet since there's not a critical mass of people using it yet"?

"It has a chilling effect on our progress as an intellectual craft when people pretend that a best practice exists. Best practice blather becomes a substitute for the more difficult, less glamorous, but ultimately more powerful idea of learning how to do your job. By "learning" I mean practicing the skills of identifying and solving patterns of problems we encounter as testers. Of course, that will involve patterns of behavior that we call "practices". I'm not against the idea of practices, I'm against pretense. Only through pretense can a practice that is interesting in a particular context becomes a "best practice" to which we all must bow down." Again, I'm fond of the patterns terminology here, because it clearly highlights the problem he's stating here: if we think we have a "Best Practice" to a particular problem, in other words, making it a two-part tuple, it becomes a deceptively simple list: we only need state all the Problems, and the Solutions will be apparent, since when would you choose not to use a "Best Practice"? When you list it out as a four-part tuple: Problem, Context, Solution and Consequences, it becomes more clear that a particular Problem doesn't have one "Best Practice", but depends entirely on Context and desired Consequences.

I would challenge anyone to name a "best practice" for which there is no situation which makes the "best practice" a "worst practice". To use James' example:

"A doctor who prescribes a drug without examining the patient is committing malpractice. Isn't that obvious? Would you respect such a doctor? Why should we respect people who prescribe practices without regard for the problems faced in a project? The answer comes back, "What if the doctor tells you to eat right and exercise?"

People often cite EJB as a terrible technology. Bullsh*t. People who do that are missing the point. (Even Rod Johnson agrees with this point, or at least he did in a private conversation at The ServerSide Symposium in 2004.) The problem with EJB was that it was highly oversold: another case of "best practices" gone awry--most projects don't need EJB, despite the advice from EJB vendors. (Hmm....) EJB offers a much simpler programming model when dealing with two-phase commit programming against transactional resource managers, particularly given the context of seeking something industry-standard (for fears of new programmers having to burn all kinds of ramp-up time when they're hired). That's not really the problem space that Spring seeks to solve. (Leaving the reader to perhaps realize that maybe there's a place for both Spring and EJB in the world?)

Why the frenzy to use the term, if it has so many things wrong with it? Easy: "Best Practices" are easy to sell. Who wouldn't want to hire somebody who practices only "Best Practices"? Who would want to hire somebody who doesn't? It's an easy term for managers and HR practitioners to latch onto, and this is why most of the time you see unsophisticated speakers and tech leaders climbing all over themselves to use the term. Come on, admit it, which title sounds better and more "bang for your buck" at a conference? "J2EE Best Practices" or "Patterns of J2EE"? Most developers will pick the first, every time. And, worse yet, not realize they're being sold a bill of goods.

If you find yourself tempted to use the term, stop and examine your rationale for doing so. Are you really asking somebody what the best way to use something is, without regard to context? Or are you implicitly seeking to push your own agenda? As a speaker, I routinely get questions like, "Is it a best practice to ... ?" that are followed up by, "But what about when ....?", in essence seeking to know if I change my advice when the Context is different than what they think I'm thinking about. And usually, yes, it does.

Challenge to the reader: the next time you see somebody use the term, "Best Practice", ask yourself (or them) if you can come up with a situation (a Context) where it would be a "Worst Practice" instead. If you can't, or if they can't, it's probably indicative that you--or they--don't quite "get it" yet. Or, more likely, that they've just never seen a situation where it wouldn't be applicable... which then makes me question exactly how much this particular practice has been used. Think it's a silly exercise? Almost all of the great technology books in our industry have either explicitly or implicitly brought this point to the forefront of the book, even to the point where the contradict themselves sometimes. Still not convinced? Then how about this: after you can begin to see the separation between Problem, Solution, Context, and Consequences, you may be able to stop listening to "experts" and start making up your own mind.

Context matters.

Elliotte Rusty Harold blogged about the WS-Addressing specifications reaching Candidate Recommendation status, and did a bit of editorializing along the way:

These specs are seeing some serious pushback within the W3C. The problem is that there already is an addressing system for the Web. It's called the URI, and it's not at all clear that web services addressing does anything beyond URIs do except add complexity. In fact, it's pretty clear that it doesn't do anything except add complexity.

Here's the problem. Web Services Addressing "defines two constructs, message addressing properties and endpoint references, that normalize the information typically provided by transport protocols and messaging systems in a way that is independent of any particular transport or messaging system." In other words this is another example of the excessive genericity problem, just like DOM, and remember how well that worked. One of the big fundamental problems with DOM was that they tried to develop an architecture that could work for all conceivable programming languages; but developers don't want and don't need an API for all programming languages. they want an API that's tailored to their own programming language. This is why language-specific libraries like XOM and Amara are so much easier to use and more productive than DOM.

Web Services Addressing is trying to define an addressing scheme that can work over HTTP, SMTP, FTP, and any other protocol you can imagine. However, each of these protocols already have their own addressing systems. Developers working with these protocols don't want and don't need a different addressing system that's marginally more compatible with some protocol they're not using in exchange for substantially less compatibility with the protocol they are using. Besides nobody's actually doing web services over anything except HTTP anyway. Doesn't it just make more sense to use the well understood, already implemented debugged HTTP architecture for this instead of inventing something new?

For example, consider your canonical "push" model; as it stands right now, there is no way to do the virtual equivalent of a classroom environment: multiple clients (students) all passively receiving content distributed in packets from the server (instructor). What's more, that distribution model is essentially a broadcast scenario with zero guarantees of delivery--if a student nods off in class, does the instructor care? Not normally, no, and certainly not to the expense of the other students in class. Broadcast scenarios are a powerful argument against HTTP, since to try and replicate this either

• the clients have to poll continuously for updates, or
• the server has to become the client, and constantly "push" the various elements out to the clients... er, servers... whatever, taking whatever firewall/security issues might be in between them into account (which is why the client-polling scneario is usually the way people go)

Look, at the end of the day, the WS-Addressing spec only requires the Action header, which serves the exact same role as the HTTP verb does: it simply provides a way to describe what the intended action for the message should be. Everything else is optional in the specification, including the To, From, ReplyTo or FaultTo headers (which use the EndpointReferences, the "virtual addresses" ERH is railing about)--which enable flexibility in message responses that HTTP simply cannot provide, highly useful in a workflow situation--or the MessageId/CorrelatesTo headers--which provide the ability to "thread" messages together, something that HTTP could only do with the introduction of cookies, something that Fielding argues against in a major way as it destroys the basic principles of a REST-based system.

In particular, I take issue with the idea that "nobody's actually doing web services over anything except HTTP anyway". If that's the case, somebody had better tell the messaging vendors, like IBM or Sonic or TIBCO or Fiorano, because they seem to be investing a lot into the XML services standards in an effort to help build that exact integration infrastructure that CxOs have been pursuing with all the zeal of the Holy Grail for about forty years now. I can think of four consulting clients off the top of my head that are using XML services over something other than HTTP, and will probably continue to do so for a long time to come. Guess they must just be trying to overcomplicate their lives, even though SOAP-over-TCP and SOAP-over-FTP actually cut the lines of code they had to maintain because they no longer had to build a complicated polling process. And as for "Doesn't it just make more sense to use the well understood, already implemented debugged HTTP architecture for this instead of inventing something new?", shortly, no, it doesn't. There's no sense in trying to take bits that were designed for a distributed hypermedia system (Fielding's words, not mine) and trying to bend it to fit a problem space that isn't distributed hypermedia. Can we learn from the REST architectural style? Absolutely--and the new WS-* specs, including SOAP, do exactly that, favoring self-descriptive messages over RPC calls as the principal abstraction to deal with. But does that mean we tie ourselves solely to HTTP? Oh, hell no.

Barely hidden between the lines in Elliotte's post is a general accusation that the WS-* guys are deliberately overcomplicating things. Frankly, I think that's an unfair categorization of what's been going on. SOAP 1.1 was complex, oh, Lord yes. SOAP 1.2 is actually fairly simple, all things considered, despite the perception you might get when you look at the spec and see three parts and a hundred or so pages instead of a single 30-page document (as SOAP 1.1 was). SOAP 1.2 standardizes a basic message format, with room for extensions (where the rest of the WS-* stack goes, for the most part), and provides a standard fault structure so that not everybody needs to define their own custom fault formats. (This is important if the fault is at the infrastructural level, not at the application level.) Everything else layers directly on top of SOAP, and frankly, if you don't need it, don't use it--the WS-* specs try very hard to be composable, meaning if you don't need a particular element, you don't use it and you don't pay for it. In fact, some of these specs (WS-Eventing, for example) are simple enough that you could implement it by hand without any help (Axis, BEA, etc) whatsoever.

Don't let a tempting political quantity (the basic desire to mistrust the big vendors and think they're just out the screw the little guy) cloud your vision over what's going on in the industry. The big vendors may very well be out to screw the little guy, but that doens't mean that everything they do isn't useful. If you build a REST-like XML service, you're actually following right into the "new" XML service model, and if you slap a SOAP:Body around your message and a SOAP:Envelope around that, you'll be wire-compatible with other SOAP 1.2 endpoints. Even better, if and when you need reliability, workflow capabilities, or integration with somebody else's WS-* stack, you're already primed to go. And wasn't that the point of all this stuff in the first place?

Although I've known for a bit, I couldn't say anything until now, when I just received the official welcoming letter: I'm a part of the JSR-277 Expert Group, the so-called "Java Module System" JSR. Although you can read the full spiel on the JCP website, the nuts-and-bolts part of this story is simple: we (or at least, I) want to fix the horribly busted component model in Java. Or, rather, the lack of any such thing, beyond what the J2EE world offers (which isn't much).

To put it into EG Lead Stanley Ho's words from the JSR-277 home page,

The specification of the Java Module System should define an infrastructure that addresses the above issues. Its components are likely to include:

1. A distribution format (i.e., a Java module) and its metadata as a unit of delivery for packaging collections of Java code and related resources. The metadata would contain information about a module, the resources within the module, and its dependencies upon other modules. The metadata would also include an export list to restrict resources from being exposed outside the module unintentionally. The metadata may allow subset of exposed resources to be used by other modules selectively.
2. A versioning scheme that defines how a module declares its own version as well its versioned dependencies upon other modules.
3. A repository for storing and retrieving modules on the machine with versioning and namespaces isolation support.
4. Runtime support in the application launcher and class loaders for the discovery, loading, and integrity checking of modules.
5. A set of support tools, including packaging tools as well as repository tools to support module installation and removal.

We also expect the Java Module System to expose the public J2SE APIs as a virtual module in order to prevent unwanted usage of the private APIs in the implementation.

There's some high-powered folks on this JSR, as there was on my last EG, such as Stu Halloway, David Bock, Doug Lea, Sam Pullara and Hani Suleiman (gotta be careful about emails to Hani, though, or I might find myself the subject of a weblog entry and I dunno if my fragile ego could handle that...). I'm looking forward to working on a JSR with Stu, with whom I've not closely worked since Stu left DevelopMentor to go his own path, particularly since I've been... err... disagreeable, shall we say?... with his business partner. Not only that, Stu appears to have taken a deep hit of the dynamically-typed languages Kool-Ade, and I always welcome reasoned debate with somebody who's perspective wildly differs from mine.

Once again, I think my major contribution will be the experience of the .NET world, and their experiences with assemblies. It will be particularly interesting to see how Java Modules will or won't closely emulate assemblies, and to be 100% honest with you I'm not sure if it would be a Good Thing or not if they did. I think there's definitely some goodness to how assemblies work, but there's also some interesting feedback filtering through the collective .NET unconscious that seems to disagree with my own perceptions.

All in all, it's going to be an interesting ride. Wish us luck--this is probably one of the more influential JSRs in the JCP for Dolphin, as it'll change the packaging and deployment models for both J2SE and J2EE (and beyond), so if we screw this up.... *shudder*

BTW, if you know of a good component model beyond Eclipse, NetBeans, .NET or OSGi, please drop me email and tell me why you think it's something I should look into. I won't promise anything, but obviously the more experience we can draw upon, the better the chance we have of the final results not... well, not sucking.

Duane Gran emailed me with his thoughts on adopting Ruby-and-Rails into his shop, only his thoughts on the matter are a bit different from the usual rant; he's looking at it from the management perspective, and has some good ideas on when and why to adopt... or not to adopt... a new programming language. Specifically, he spells out: The decision to change programming languages, databases and operating systems shouldn't be taken lightly, but when the issue comes up the approach should be analytic. Be wary of resume-driven development initiatives, architectural advice from vendors, marketing hype and buzzword compliance. That your development team is more productive with the new technology is all that matters. ... I suggest changing architectures only when the following factors align:

1. The technology is proven in your development environment
2. The installed user base is small for your application
3. You are still in a development or prototype stage that won't endanger a production system
4. Your developers want to learn the technology for the right reasons and they have a firm grasp of the code base

I like that list. I could probably add to it, with concerns whether the technology will be somehow integratable/interoperable from your legacy platforms, but I think that these issues are probably the first hurdle to pass--and, frankly, I think will be the hardest hurdle to pass, particularly given his caution against "resume-driven development initiatives". (I like that phrasology, Duane--don't be too surprised if you hear it on an $NFJS panel sometime.

So I'm flipping through some old weblog entries, and I run across this one:

So when is it a good idea to use XML for your data? The easy answer is that you should use XML when it is likely to be easier (in the long run) than creating your own parser. Using XML carries some cost. XML is verbose, and parsing is guaranteed to be slower than a custom parser. Why is XML such the rage then? Aside from the hype there is one very good reason to use XML. For many types of data, it is easier to just load the data into a DOM and extract the information from that, than it is to write a custom parser. That means less time spent debugging code, more time spent focusing on the problem at hand.

1. He originally chose to use XML as the format for Ant scripts because he didn't want to write a parser, and
2. He really regrets it and apologizes to the Java community at large for it.

The problem, in the case of Ant--and its successors, like MSBuild--in using XML is that it is a strictly-hierarchical format, and not everything follows a strictly hierarchical format (even though it might seem to at first). More importantly, XML is a hideously verbose format, and the "self-descriptive" tags that everybody blathers on about are only self-descriptive to carbon-based life forms (and then only if semantically-rich terms are used for the tag names). For example, does this "self-descriptive" XML have any meaning to you?

<p><a>34</a><s>046604143</s><ph>42049941499<ph></p>

So when is it a good idea to use XML for your data? My criteria are a bit more stringent:

• When your data is naturally hierarchical to begin with
• When exchange with foreign platforms (which is to say, platforms not native to what you're currently authoring in) is important
• When pre-existing tool support (XSLT, XML viewers, import/export utilities, etc) is of paramount importance

By the way, scripting languages (like Ruby, Python or JavaScript) make a terribly convenient way to do data storage/manipulation that still doesn't require writing a parser or custom data format--witness the astounding success of Ruby-on-Rails in this area to see what I mean. Combine this with the ability to embed them in your .NET, Java or C++ code, and you have a really strong argument against using XML to "avoid writing a parser". Look at what Groovy does for Ant scripts, for example (Pragmatic Project Automation).

John Robbins recently blogged about an "amazingly cool" bit of .NET TraceListener magic sent to him in an email:

Josh Einstein sent me a mail about his amazing TerminalTraceListener. If you add TerminalTraceListener to your application, you can telnet into your application and monitor tracing live no matter where it is. How amazingly cool is that!? Josh also added a second TraceListener, SyslogTraceListener, that pumps the traces to Kiwi Syslog Daemon.

What this really underscores, however, is how John's debugging capabilities have been limited (however slightly) by his unawareness of the Java space. John is not a stupid person by any stretch of the imagination--his books on debugging leave me in stunned jaw-dropping silence every time I read them--but it sounds like he thinks could have used these two long before now, and he could have had them (without even having to write them, in fact) had he known about log4j or log4net before now.

Which leads me back to my point: you don't have to be a hard-core Java developer to learn something from the Java community, and vice versa. Take a day or two, learn the platform you don't routinely write code on, and take a day or so every month to look around at the tools and technologies that are out there. I think you'll be amazed at how rich and powerful the "other guys" are, and your own skills will grow immeasurably as a result.

A bit late, but I realized after I posted the Recommended Reading List that I forgot to add Mike Clark's Pragmatic Project Automation, a great resource for ideas on how to automate various parts of your build cycle... and, more importantly, why this is such a necessary step. Although nominally a Java book, there's really nothing in here that couldn't also be adopted to a .NET environment, particularly now that $g(NAnt) and $g(MSBuild) are prevalent in .NET development shops all over the planet.

Most importantly, Mike indirectly points out a great lesson when he uses $g(Groovy) to script $g(Ant) builds: that you don't have to stick with just the tools that are given to you. Automation can take place in a variety of ways, and scripting languages (like Groovy, or Ruby, or Python...) are a great way to drive lower-level tools like Ant. Stu Halloway has begun talking about the same concept when he discusses "Unit Testing with Jython" at the $NFJS shows. Coming from the .NET space? Then think about $g(IronPython), or even the JScript implementation that comes out of the box with Visual Studio.

All in all, a highly-recommended read.

Dion blogged about $g(Parrot) a while back, and it triggered an interesting thought: we already have IKVM, a JVM-running-on-the-CLR, is it possible and/or practical to do a Parrot-running-on-the-CLR or Parrot-running-on-the-JVM? That would do some interesting kinds of interoperability scenarios between Parrot's targeted dynamic languages and the library-rich platforms of Java and .NET....

(Note that this is a reprint, so to speak, of the same entry on the old weblog, but I wanted to kick the Reading category off with a reprise of what I'd written before.)

I've been asked on several occasions (from students, from blog readers, and from a few friends who happen to be in the business) what my recommended reading list is. I've never really put one together formally, instead just sort of relying on impromptu answers that cover some of my absolute favorites and a few that just leap to mind at the time.

Enough is enough. It's time for me to post my recommended reading list, broken out for both Java and .NET programmers. (If you're of one camp, it's still worth reading books on the other camp's list, since the two environments really are Evil Twin Brothers.) And I've left my own books off the list, because I think it's rather forward of me to recommend them as recommended reading--naturally, I think they're all good, but whether or not they make the cut of "recommended reading" is for others to weigh in on, not me (at least not here). (Update: several commenters on the old blog suggested it was not out of line to recommend my own books if I thought they were worth recommending, so I added them.)

Java Recommended Reading list:

• Effective Java by Bloch.
• Java Puzzlers by Bloch and Gafter. You think you know the Java language? Try it. (Makes for great interview question fodder, and for that reason alone practicing Java programmers should have a copy on their shelf.)
• Effective Enterprise Java by Neward. (Had to do it. )
• Concurrent Programming in Java (2nd Ed) by Lea.
• Either Inside Java2 Platform Security by Gong or Java Security (2nd Ed) by Oaks.
• Component Development for the Java Platform by Halloway.
• Inside the Java2 Virtual Machine by Venners.
• Java Development with Ant by Hatcher and Loughran.
• Either Java RMI by Grosso or java.rmi by McNiff and Pitt.
• Server-Based Java Programming by Neward. For obvious reasons. Actually, I still think this book is applicable if you want to understand the reasons why an app server makes some of the restrictions that it does, but I freely admit that I don't think I did a great job of "closing the loop" on that and finishing the book with a good summary that ties everything together. Ah, retrospect....
• Servlets and Java Server Pages by Jones and Falkner, possibly Java Servlet Programming (2nd Ed) by Hunter, if you aren't planning to use JSP. (Jason's legendary bias against JSP, right or wrong, puts him somewhat out of tune with what a majority of Java web-client shops are doing. That said, it's a great servlets resource.)
• AspectJ in Action by Laddad. AspectJ represents the best of the AOP solutions, IMHO, and this book represents the best of the AspectJ books available.

.NET Recommended Reading list:

• C# In a Nutshell (2nd Ed) by Drayton, Albahari, and Neward. For obvious reasons.
• Advanced .NET Remoting by Rammer.
• Essential ADO.NET by Beauchemin.
• Inside Microsoft .NET IL Assembler by Lidin.
• SSCLI Essentials by Stutz, Neward and Shilling. For obvious reasons.
• Debugging Applications by Robbins.
• Inside Windows 2000 by Russinovich and Solomon.
• Essential COM by Box. (Yes, I mean Essential COM and not his more recent Essential .NET book. The first chapter of Essential COM is probably the best well-written technical prose I've ever read in my life, and everybody who ever wanted to write reusable components in C++ needs to read it to understand why C++ failed so miserably at that goal. Once you've seen that, you're ready to understand why components are so powerful and so necessary.)
• Essential ASP.NET by Onion.
• Expert C# Business Objects or Expert VB Business Objects, by Lhotka. Not an intro to business objects, per se, but a great read on how to build a framework. Pay close attention to how Rocky handles distribution; he avoids the canonical problems of "distributed objects" by not distributing objects, but instead making them mobile objects.
• The Common Language Infrastructure Annotated Standard by Miller
• Programming in the .NET Environment by Watkins et al.

C++ Recommended Reading list:
(For the twelve people left in the world still writing C++ code, anyway.)

• The C++ Programming Language (3rd Ed) by Stroustrup.
• Effective C++ (1st, 2nd or 3rd Ed) by Meyers.
• More Effective C++ by Meyers.
• Effective STL by Meyers.
• Inside the C++ Object Model by Lippmann. You don't know how C++ works until you've read this cover to cover. Twice. And peeked at everything under the hood with a debugger, just to make sure Stan's right. Seriously.

Database/Relational Storage Recommended Reading list:

• Introduction to Database Systems (8th Ed) by Date. Heavy on theory, and for that reason alone should be read at least once by any practicing programmer who thinks they understand SQL and the relational world.
• SQL for Smarties (3rd Ed) by Celko. Actually, you need to own just about everything by Celko.
• Principles of Transaction Processing by Bernstein and Newcomer.
• Transaction Processing: Concepts and Techniques by Gray and Reuter. What to read when you're done with the Bernstein and Newcomer book and still want to know more about the Zen of Transactional Processing.

Security-related Recommended Reading list:

• Secrets and Lies by Schneier.
• Either Cryptography Decrypted by (can't remember the name offhand), Practical Cryptography by Schneier and Ferguson, or Applied Cryptography (2nd Ed) by Schneier. The first is a lightweight introduction to the subject, the second is a more detailed introspection, the third required reading for anybody who wants to be a security wonk.
• The Code Book by Singh.
• Hacking Exposed (5th Ed), by McClure, et al.
• Exploting Software, by Hogland and McGraw. The most fun book in the list, if you ask me.
• Reversing by Eilam. Who says unmanaged code is "safe from reverse-engineering"?
• The Art of Deception, by Mitnick

Operating System/Platform Reading list:

• Windows Internals (4th Ed) by Russinovich and Solomon. Actually, any of the last three editions (2nd, 3rd, 4th) is awesome, so look for 3rd Ed in a bargain bin and pick up a great bargain.
• Operating Systems (2nd Ed) by Tanenbaum. The original "Minix" book. Taught me the basics of how an O/S works, and the basic concepts are still applicable to this day.

Platform-agnostic Recommended Reading list:

• Design and Evolution of C++ by Stroustrup. It's fascinating hearing how a language develops over time, and what was behind some of the decisions in the features of the language. For example, why did multiple inheritance come before templates or RTTI? Not because it was more important, but because Stroustrup wanted to tackle MI first because he wasn't sure if or how he could do it. He describes that as a great regret, that he didn't do templates first.
• Component Software (2nd Ed) by Szyperski.
• Rapid Development by McConnell. Read this before you read any of the Extreme Programming books, because this book describes a whole taxonomy of what I think a lot of people are reaching for in agile and other methodologies.
• The Inmates Are Running the Asylum by Cooper.
• The Invisible Computer by Norman.
• Refactoring by Fowler.
• Design Patterns by Gamma, Helm, Johnson and Vlissides.
• Pattern Oriented Software Architecture, Vol 1 by Stal et al.
• Pattern Oriented Software Architecture, Vol 2 by Schmidt et al.
• Patterns of Enterprise Application Architecture by Fowler.
• Enterprise Integration Patterns by Hohpe and Woolf. Excellent discussion of message-based architecture. I personally think the title is something of a misnomer, but it's understandable since message-oriented communication is the easiest means by which to integrate heterogeneous systems.

Note that this list will undergo revision and change as I continue, so I'm putting a link to this item in the links column in the sidepanel to the left for easy reference. For now, I'm just listing them out as they come to mind. Later, if I have time, I'll put paragraphs of detail behind them so you can know why I recommend them. (Updated on 13 Feb 2002) (Moved to this weblog 21 Aug 2005) (Updated 5 Oct 2005)

Look for more book reviews and recommended reading via the "Reading" category on the RSS feeds. There's undoubtedly titles that I'm forgetting, and I'm hoping I'll get around to blogging more about the books I'm reading now, including Ruby (the Pickaxe book and the Rails book), some other titles in the Pragmatic series, as well as some WS-*-related stuff and (of course) the staple C# and Java stuff. And of course I'm always open to suggestions of new and interesting technical titles to peruse....

Update: Steven Rockarts pointed out that Rocky's "Objects" books are missing, as is Fritz's Essential ASP.NET. Added. (He also lists Object Thinking, by West, but I don't care for that book--too Zen, I think, for most readers.)

Well, apparently I've created quite a stir in the blogspace by not immediately rushing to embrace Ruby-on-Rails, and I'm of two minds as to the larger impact.

For starters, allow me to respond, one last time, to what Justin and Dion and Glenn have written:

• "Pretty clearly, Rails' biggest benefit is Ruby itself. ... Dynamic languages like Ruby provide for eloquence of expression and compile-/run-/deploy-time extension of the core framework abstractions. ... extending classes at runtime ... is powerful, and hard to do in a statically typed language." Actually, Justin, as I think some of the feature set listed for C# 3.0 demonstrates, it's not that hard to do at all in a statically typed language, particularly considering that we don't want to do it at runtime, but at compile-time, so to speak. (I've yet to see a Rails demonstration that changes the type at runtime--it's all been done at edit-time, which in Ruby is the logical equivlent of compile-time.)
• "Lots of people have written about Ruby’s suitability for creating DSLs. When it comes down to it, Ruby’s extensibility and flexibility put it in a class with Lisp, Python and Perl and separate from byte-code-language-X for creating custom syntax. For me personally, extending the base constructs of Ruby to support new, app specific capabilities, makes my job 40 times easier." Frankly, this again smacks of Ruby, not Rails, to me, because I don't consider what Justin is creating in his example to be an example of DSLs. Useful, certainly, powerful, certainly, but not really in keeping with the DSL concept, at least not as it's been discussed up until this point.
• "As I said last time, and as Ted agreed, it is high time for web apps to act like web apps. I want my framework to deliver the HTML over HTTP experience as though that’s what I intended all along to deliver. If it gives me nice ways to bridge the server and client that make it feel a little more tightly integrate (AJaX, anybody?), the more the better. What I DON’T want to forget about is that I’m on the web. Rails strikes, for me, the exact right balance between abstraction and transparency." POWA: good. Rails-as-best-expression-of-POWA: arguable, but not something I want to spend a great deal of time arguing, to be blunt about it.
• "Rails’ convention-over-configuration is a startup-enabling technology. By startup, I don’t mean a new company, I mean a new project. Part of the Agile methodology’s premise is that you get the framework of the app up and runnning as fast as possible (during the first iteration). Then, add on the features. Rails’ convention based approach makes this an absolute lead-pipe cinch. I never question any more how long it will take me to get the front-to-back chassis in place. Rails all but guarantees I’ll be finished in the first iteration, often in the first couple of days. Will I keep that chassis as is for the rest of the project? Of course not. The scaffolding is just that — a shell that allows you to visualize the general shape of the application before you’ve put in all the foundation and walls and pretty siding. As you fill that stuff in, the scaffolding comes down, and you are left with real, working code. Yet all along, you’ve been able to demonstrate to your customer what the final thing might look like. Might be a little fuzzy along the way, but the end product won’t be a total surprise." OK, here we get to a nuts-and-bolts point: Rails as a startup-enabling technology is a good thing. But projects will not always be startup projects. And in particular, this is exactly the path that servlets and JSPs took, and this is exactly when and where the complexity kicked in--people discovered that they needed something more complex than startup-enabling technology as their systems scaled up, not in terms of concurrent users, but in terms of complexity to the rest of their back-end systems. Particularly if you've ever had to rewrite an ASP system in Java servlets--and by the way, had to preserve the deep links scattered all across the Internet--you've come to really appreciate the flexibility in URL-to-code configuration that the servlet environment gives you. Let's NOT throw the baby out with the bathwater when we toss away servlets/JSP in exchange for something that helps us get the easiest 80% of the app done more quickly. Remember the Golden Rule of Software Estimation: "The first 80% of the app will take 80% of the time. The next 20% of the app will also take 80% of the time." It's never the first 80% of the app that I worry about; it's the last 20% that concerns me.
• "Lastly, but certainly not least, Rails gives you speed. I simply have never worked in a web app framework that enabled me to move at such a controlled velocity. I may have moved faster in the past (particularly using generated ASP.NET pages) but I never had the tools built in to ensure I was doing a decent job. Not only is Rails a highly productive environment, but it almost forces you to take a test-and-prove approach to development, if through nothing more than guilt. (Hey, look, you just generated a new controller, and I put all these handy tests down here for you to use! What, you aren’t going to use them? What kind of lame-o are you?!?!)" This is the part I can least speak to, as I've not experienced Rails directly yet, not in any form of "production" capacity, anyway. (I plan to, though--my next book, one which I'll announce soon and will be in Dave's Pragmatic series, will have a Ruby/Rails component to it, I'm certain of it.) So I'll have to defer to Justin's experience here, though I will close with the thought that I wonder if we couldn't have the same kind of speed in Java or .NET if we built the surrounding scaffolding to do the same things that Rails does.
• "I think that Ted will end up putting the Rails and Ruby books back on his shelf, if for no other reason than he’s never thrown away a book in his life. However, I believe that Ted really values technologies that offer something new to developers and their customers. Rails is clearly, for me, one of those technologies, and I think that Ted believes it too, really. He just likes to have blog-offs." Well, I won't disagree with Justin's point that I like to see what smart people have to say on topics that I disagree with, and frankly, don't expect the "blog-offs" to stop anytime soon, as I've learned a lot just from this debate. And yes, Justin's right, I've never yet thrown a book away, so the Rails book will end up back on my shelf eventually. But it's really a larger question of how much time I should spend on the subject, and I think there's enough intriguing elements here (mostly dealing with the fact that it's Ruby) to justify spending more time learning it. But don't expect to see me recommending Rails in a production capacity any time soon--my clients tend to be the large-scale enterprise folks that Justin mentions, and as a result I probably won't be using Rails "in anger" any time soon.
• Glenn said, "What’s Rails about?
  • "It’s about Ruby and the things that a scripting language can do that a compiled, statically-typed language can’t." Again, Glenn, I'm concerned with writing off statically-typed languages as being simply "unable" to do some of the things that Ruby is doing--I believe that to make that argument shortchanges the statically-typed language just as much as arguing that the dynamically-typed language "can't perform" does.
  • "It’s about confirming some of the earliest thinking about frameworks: that they should be extracted from well-designed applications, rather than being designed on their own." Amen to that! I've watched thousands of "reusable frameworks" built from scratch, without even a project to build them around, and they showed it. (I'll even admit to building a few myself.) There's a great quote I heard someplace in the C++ days--wish I could remember who said it--that says, "We need to make something usable before we can make it reusable". Learn it, love it, live it. And if that is Rails' greatest contribution to the Java space, then count me in as a fan.
  • "It’s about demonstrating the fundamental importance of the DRY principle for software design. (Bruce Eckel calls it "the most fundamental concept in computing.")" Well, certainly I applaud the idea of DRY and Once-And-Only-Once as core principles, but let's also not forget the power of the Level of Indirection. Bruce Eckel may disagree, but I find THAT to be the most fundamental concept in computing.
  • "Oh … and it’s about bringing the pendulum back away from the layers-upon-layers default approach in Java projects." And, again, hallelujah! Say it loud, say it proud.
• "For some time many frameworks have been going to the JSF extreme, and Rails has come along to give a great balance. Hacking away at JSPs, or PHP files just becomes a mess quickly. We all learned that. Then we started working with simple MVC things which was fine, and it got complicated. Rails is rebalancing things!!!" Sure, but let's not go to the opposite extreme in the rebalancing--there is value in that complexity in the servlet/JSP space: unless you believe that smart people seek to create complexity just for the hell of it, then you have to believe that the complexity that was added to the servlet/JSP space was introduced there for a reason. If, by the way, you choose to believe that the servlet/JSP community added that complexity for no good reason whatsoever, then you and I simply have to agree to disagree on that point. Has the web framework space gotten too complicated? Sure--everybody's trying to put THEIR layer of abstraction on top of servlets/JSP (and JSF quite clearly fits into this category), and that, to me, is a mistake, but again, let's not throw out the baby with the bathwater. Let's not chuck servlets/JSP just because certain people are trying to impose their abstractions on top of it.
• "Come on dood. You really think that you would want to build a web application in pure Servlets?" Dion, I never said that, nor do I believe that. (Although, quite frankly, I think you canget some distance with pure servlets and some good library support, such as $g(Velocity). Hey, if template files are good enough for Rails...) This isn't a black-or-white discussion--it isn't Rails vs. Pure Servlets vs. JSF. It's a continuum, and Rails fits on an end of the continuum that I find to be too naive and simplistic to fit the needs of the companies that I consult for. Your experience may be different, and if it is, wahoo!

My second concern, however, is the larger issue: I can't really recommend or get my heart behind a technology until I've seen it applied to several full-lifecycle projects (not necessarily my own, but others' are acceptable) so that I have something to examine and see where the strong points and weak points are. I know that Rails grew out of a website, then another and another, for a website design company, and that in of itself gives me a good feeling, but until Rails starts to go beyond the simple webapp-on-a-database scenario, I won't really give it much credit beyond something to compete with a ColdFusion or PHP. So, to all you Rails-heads, check back with me in a year, show me the wide variety of sites built with Rails, and then (maybe) I'll be willing to be convinced otherwise. Until then, well.... happy coding.

It appears that a couple of my so-called friends are expressing surprise(?) or condemnation(?) over the fact that I didn't fall under the spell of Ruby-on-Rails at the $NFJS Austin show. As the great comic Steve Martin used to say, "Well excuuuuuuuse me!"

Dion first takes a couple of cheap shots:

Firstly, you can't say much for Ted wrt taste... I mean he is running that .NET blog software now ;)

Secondly, I think Ted hit the nail on the head and didn't even realise it ... I think the Java world took this [greater need for configuration] waaaay to far. Abstractions upon abstractions. We forgot that web frameworks ARE FOR THE WEB!!!

Before you look around we have JavaServer Faces, which "features" that you don't just get to write out HTML. Sounds great on paper. I still hear people talking about how they will be able to just flip on a different Renderer and they will have a mobile application. Of course, in reality a mobile application is very different. You care about different things.

I want a web framework that lets me work with web technology (HTML is one of them ;), but gives me a nice clean way to do this.

In my experience, I like to have simple tools which just work, but if the hardest part of your application is the web framework, you are lucky!

We then turn to Justin's comments:

Ted Neward, a great friend, colleague, and all around smart-guy, just really missed the boat on Rails this last weekend. Dion pretty much hit the nail on the head on the technical response. Rails is a web framework that doesn’t make me think I’m writing a Swing app, or that I’m writing an EJB app. It pretends to be nothing; it is, rather, a powerful framework for writing an app that delivers HTML over HTTP. Hell, what with the ASP.NET/JSF render kit wunderland, I’m starting to wonder if we need a new acronym: POWA (Plain Ol’ Web App).

Regardless, he also whiffed (sorry big guy) in his musings about managed versions. There is, of course, Trails, a mighty attempt to make the Spring/Hibernate/Etc. stack as easy to configure and use as Rails, and MonoRail, an open source .NET equivalent as well. What fascinates me about MonoRail is that it is one of the first attempts to move away from the standard ASP.NET design pattern; the MVC crowd has just not found a great way to own that space. Maybe MonoRail will be the ticket. (By the way, check out the other stuff going on at CastleProject; DynamicProxy is a great little tool for making synthesized proxies a la Java, without all that Reflection.Emit() hassle.)

When I say he whiffed, it isn’t because he couldn’t tick off the various projects off the top of his head. Its because he missed that Rails is already influencing everybody else. The “small” feature he mentions, convention over configuration, is catching on like wildfire, and I don’t think it would have unless Rails had highlighted the fact that the 80% case is to only configure 10% of your app. We’re also seeing some folks revise their commitment to web components; with Rails, parameterized partial templates give you most of what you get with web components, and at a fraction of the compexity.

Look, guys, at the end of the day, if Rails is about Ruby and the things that a scripting language can do that a compiled, statically-typed language can't, then Rails definitely has a place in the world and I'll take the time to learn it. If Rails is about bringing sanity back to the web framework space, then I'll wait for the Java and .NET Rails-influenced projects to ship and stick with something that has BOTH the sanity AND the support of managed platforms.

So Dion, Justin, if you still think I whiffed, tell me why, pray tell. Or else admit that you're just jumping on a "bright shiny new toy" bandwagon and that two years from now, Rails won't be in anybody's lexicon. In other words, it's "put up or shut up" time.

So I'm in the Austin area this weekend, for yet another NFJS show, except this time I actually had time in the schedule to attend the Friday night talks. (Normally I'm too busy traveling to be here on Friday--I typically need the Friday night timeframe to actually get here, which probably explains why my Saturday morning talks are always a crap shoot.)

Part of my reason for wanting to be here early was a desire to see more of Dave Thomas' talks, and in particular, I wanted to get more of the Ruby and Rails Religion that seems to be infesting... er, maybe I should say "spreading like wildfire" instead... my friends in the speaker crowd. I mean, normally they're a pretty sane and sensible bunch, and if these guys are all drinking deeply of the Ruby and Rails Kool-Ade, I want to take a hit from the bong as well and see if it's a good trip, or just a trip.

So I sat through Dave's Rails presentation, and as he was finishing up, I felt strangely disappointed--not so much that Rails isn't a cool little framework, but that there really wasn't anything more there. I mean, I see a bunch of intelligent code-generation and some common-sense defaults, but other than that it's strangely reminiscent of the servlet scene circa 1997--even to the point where Rails will reload modified scripts on-the-fly for you. Hell, if the servlet containers had been smart enough (or crazy enough, depending on your viewpoint) to do the servlet compilation for you on the fly (memory leaks in javac notwithstanding), it would be very much like what we have right now with Rails.

And yet, we didn't stay there in the servlet community once we had that kind of functionality. We found a greater need for configuration, more flexible and powerful execution models, and so on. In essence, as web apps got more complicated, the servlet/JSP space got more complex to match it. "With power, comes complexity; with complexity, comes power." I wonder if Rails will eventually find that same need, or is it always going to target the easiest/easier x% of webapps and leave the harder stuff alone?

In the meantime, am I missing something from Rails? Is there any movement afoot to create a JavaRails ("Jails"? Ew.) project that I'm not aware of? (Come to think of it, in the .NET space too, while we're at it? "Nails", anybody? )

With this entry, I inaugurate a new weblog, this one devoted to technical issues of all walks and shapes, including but not limited to Java, .NET, C/C++, and Web services, but with a smattering of Ruby, Python, SQL, and just about anything else that happens to cross my path.

Some may wonder why the separation, considering I already had a weblog that a lot