Ant Docbook Styler Suite Thursday, December 30, 2004

If you do any publishing with Docbook you should take a look at the Ant and Docbook Styler Suite. I recently stumbled across that and have so far been very impressed. Installation is as simple as executing a target in the build file provided with the distribution and using the library is as simple as adding a task in your Ant build file to execute a target in their build file. You have to provide a handful of property values so their task knows where to find your docbook source, what to generate, etc. but it really is a snap to use. Their 3 or 4 page instructions (included in the distribution of course) are very clear and got me up and running within 10 minutes or so.

I have looked at other Ant + Docbook solutions and they are all a wirey mess of dependencies and you have to download Docbook stylesheets separately and plugging in FO support is another twisted mess, and on and on. The Styler Suite was much much simpler and seems to do a very nice job.

If you are a docbook author but not a Java developer, this may turn out being more headache than it is worth but if you already have Ant and Java installed, using this is a cinch.

Thanks to Dawid Weiss for the slick tool!

Code Cracker Lives On

I bought my first Palm Pilot back when the Palm IV series first came out. I think it was 1998. Soon after I bought the device I was interested in writing software to run on the thing. I picked up a copy of OReilly's Palm Programming: The Developer's Guide, and I was on the ground running. I remember spending a weekend just playing around with the API and I built a very simple little game that played like the old MasterMind game that most of us played as a kid. It wasn't that I wanted to write a MasterMind game, that was just something simple that I could use to help learn the PalmOS API. I expected to just throw the thing away when I was done but I found myself enjoying playing the game when I had a minute or 2 to kill (like standing around in front of the microwave at work waiting for my lunch to cook) so I held on to it. I gave the application a proper name, CodeCracker, created a very simple web page that explained a little about the game and I put it on my personal web site and made the game available for download. I remember being surprised at how many people found the page and even more surprised at how many people bothered to take time to send a thank you note to me. A couple of years later I was cleaning up a hard drive and stumbled across the source code. I decided to put the source code on SourceForge for safe keeping and it has been there ever since.

Just today I received an email from a guy in Italy saying thanks for the game and offering some suggestions for how to improve the game.

I spent a weekend 6 or 7 years ago playing around with writing something for the PalmOS and a very simple game evolved. It is sort of interesting how these little things linger on.

CodeCracker Lives On! ;)

Hostility Directed At Prevayler Monday, December 27, 2004

Prevayler seems to be getting a lot of blog attention all of a sudden. I don't know what kicked off the spike in attention, but something seems to have done just that.

Prevayler is yet another framework for POJO persistence. What makes Prevayler unique is the fact that it takes an approach that your entire data model is in memory all of the time. Because it is always reading from RAM, performance benefits are touted as high as 9000 times faster than Oracle and 3000 times faster than MySQL (I won't go into all of the details behind those numbers, see their site for more details). One of the costs of this approach is directly related to RAM limitations. If everything is loaded into RAM all of the time then the amount of RAM is an obvious potential road block.

Some of the blogging rants I have seen go to great lengths to elaborate on the flaws of this approach. This guy rants with some hostility for several pages about Prevayler's shortcomings while this guy seems to take a more calm pragmattic look. Some of the attacks I have read are really pointed at the idea that Prevayler is a ridiculous idea that could never replace our relational databases. I don't think Prevayler is proposing that they are really a threat to Oracle or any other DB vendor. I think they are proposing a solution that makes sense for some systems but not all. I don't know if they are right or not, but I think that is what they are proposing.

I am not a Prevayler proponent and I am not taking a position to defend Prevayler. I have played around with their tool a little and it is interesting but I am really not a Prevayler evangalist. What I find interesting about the attacks on Prevayler is that a lot of them seem to be very passionate and fired up. If Prevayler was really a totally insane ridiculous idea I don't think anyone would even pay attention. Maybe this is just another manifestation of the idea of how emotionally connected Enterprises (that means people) get to their databases and even the idea that it might not be right is enough to launch the missiles.

Naughty Or Nice? Saturday, December 25, 2004

Apparently, this guy sold his kids' Christmas presents on eBay because the kids were naughty. My wife and I sometimes joke about selling our boys on eBay when they misbehave (that is right, the boys... not their toys.). I never considered selling their stuff. ;)

As I type this post I am looking out over a sea of toys and schtuff all wrapped up and spread around our family room. In about 6 hours from now I expect a certain 7 year old boy to be jumping up and down on my bed yelling something about Santa Clause having been in our house. I better get to bed.

Happy Holidays To All!

JDO 2.0 Sunday, December 19, 2004

The Public Draft of JSR-243 is available for download at http://jcp.org/en/jsr/detail?id=243. This JSR is defining the JDO 2.0 spec.

There is a lot of new and cool stuff being proposed for 2.0. One item in particular that I am interested in is the whole detachment idea. The idea is that we would be able to detach a persistent object from the data store, modify the object and then later re-attach that object and commit the changes. The changes could be commited by a different PersistenceManager and could even be committed in an entirely different VM.

Another nicety proposed for 2.0 is the formalization of O/R metadata for defining indexes, foreign keys and constraints. Some JDO implementations already support this sort of thing via vendor extensions in the meta data. ObjectDB uses this approach. Other implementations suggest that you let their tool create the tables and columns and then you go in after the fact and define your indexes, constraints etc. in the database yourself. TJDO takes this approach. It will be nice to have this formalized in the metadata for portability.

J2SE 6.0 Snapshots Available Thursday, December 16, 2004

I just noticed that it looks like J2SE 6.0 snapshot releases are being made available at https://j2se.dev.java.net/. Have I finished upgrading to J2SE 5.0 yet??? ;)

What Is Wrong With Our Web Apps? Friday, December 10, 2004

Last night Rob Smith gave a great presentation on Tapestry at the St. Louis Java SIG. I liked a lot of the things that I learned about Tapestry but as I listened and learned I was thinking about what sorts of problems does Tapestry really solve for me. Then I started thinking about how that relates to many other web app frameworks that are out there. Just off the top of my head without spending too much time thinking about it or Googling or anything like that, I came up with this list of tools that help us build web apps...

• JSP


• Servlet


• Java Server Faces


• Velocity


• Tapestry


• Struts


• Spring


• Tiles

Several of those can be thought of as being direct competitors of each other.

These technologies all try to help improve our web apps by making it easy to do things like separate the presentation layer from the data. Some provide tools to help with state management. Some help with scalability. Those are all important things to address and sometimes are difficult to address. If the tools can help solve those problems that is a good thing of course.

Web apps are hard to build. Few would still entertain fantasies about some magic web tool that solves all of the Enterprise's problems, is easy for everyone in the Enterprise to use and doesn't call for much development time. We all know that can't happen. If we didn't know that in the beginning, we know it now.

I believe that a lot of things are well suited as web apps and for the purposes of this conversation I am using the term "web app" to mean an application that uses a web browser as its primary front end. However, I am wondering if a lot of us are spending a lot of time and effort (that sounds like money to me) building web apps that really shouldn't be web apps. At last year's No Fluff Just Stuff Java Symposium in St. Louis I remember a comment that Bob Lee made during one of the expert panels. Bob said something very close to "Can we all just agree to stop building browser based apps?".

I don't think that web apps are bad. I think a lot of things work very well as web apps. In addition, as a Software Engineer I find working with a lot of the web app frameworks to be a lot of fun. I am just wondering if we are collectively trying to push pegs into the wrong shaped holes too often.

More and more I am feeling like we really need a fundamentally different (and better) way to build distributed systems. I can't exactly put my finger on it, but somewhow I feel like we are solving a lot of the wrong problems and that in 6 months or 6 years or however long it takes us to come up with this next generation of ideas we are going to look back and wonder how we ever managed to operate our businesses any other way.

What do you think about any of that? Let me throw out some specific questions for thought.

What problems do you have in building web apps that are not solved very well by the existing frameworks?

What types of projects have you been involved with that were architected as web apps that should not have been and what made them poor candidates to be built as a web app?

What types of projects have you been involved in that were not architected as web apps that should have been and what made them so well suited to be web apps?

What do you think is next?