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 of people were subscribed to. The reasons are pretty simple, when you look at it:

1. A vocal, anonymous collection(?) of people complained about the fact that I was talking about .NET issues and people, yet the blog was subscribed to JavaBlogs. While I find it a short-sighted view, I realized that I really should have category support so as to be able to allow readers to "screen out" the postings they didn't want, which brings me to my next reason.
2. I'm really tired of my own weblog engine. To put it bluntly, I never really wanted to be in the business of being a blogging provider, yet writing my own engine sort of put me into that space, and I found that, like the proverbial shoemaker's children, I wasn't really spending any energy on bringing it up to speed in feature terms, and, more importantly, I didn't really want to, either. I like writing prose and writing code, but blogging to me was an infrastructure I wanted "to just work", not something I wanted to tinker with. So I decided that I wanted to switch engines.
3. I've also found myself periodically hestitating from posting something super-personal (such as a spin on politics or history) because so many had subscribed to my blog for its technical content. Since blogs are supposed to be a personal channel, yet since my blog was clearly also serving as a professional/technical channel, it seemed prudent to split my blogging into a professional channel (here), and a personal one (there). (Actually, I'm going to eventually migrate those entries over to this blog, set up redirects, and do all of my personal blogging from the family blog instead.)
4. The blogging engine had served its original intended purpose--to see if Servlet filters could stand in as Controllers instead of servlets in an MVC scenario--and it was time to close the experiment down and let somebody else handle blogging engine featuritis.

In this case, the engine is dasBlog, which has some righteous features that I already love and some of the best technical support in the world. What's more, I'm hoping that the mail-to-weblog and/or the w.Bloggar or Blogjet support will help me blog more often, since I've often found myself on an airplane without an Internet connection and wanting to blog something. In particular, some of the topics I want to blog on in the coming months:

• The Vietnam of Computer Science
• Distributed objects and why "good distributed object model" is a contradiction-in-terms
• Why the term "Web services" should be deprecated in favor of "XML Services" instead
• Weighing in on the duck typing vs. strong typing debate

And a few more, besides. As always, I'm reachable via email, and so long as the comment spam doesn't get too bad, via comments here. Thanks for listening, and here's to many more years of interesting blogging commentary.