Friday, July 11, 2008

"Me Too Moment" -> "Build tool choices should not be transitive" (by Steve L)

I usually try to avoid wasting others time by "+1" and "me too" posts. But here's something I feel strongly about: I really really agree in that "Build tool choices should not be transitive". Same can be said about many related issues (should your library dictate logging system choice?), but it's most urgently problematic with build systems. It is also related to "Principle of Concervatism for Foundational Libraries", that is, trying to be cautious about baseline JDK requirements imposed by low-level libraries ("why does JDOM not just require JDK 1.7-pre-alpha so we could use this thingamagic that looks reeeally cool?!?"), to allow applications choose their own upgrade cycles.

Minor update for StaxMate in making: 1.2 with Sjsxp compatibility

It will be a while until StaxMate 2.0 is done, mostly since I have decided that it should offer full support for the new (and still work-in-progress...) Typed Access API. Since this beast will be included in Woodstox 4.0 (as part of Stax2 Extension API, curiously versioned at 3.0), it will be a while until all pieces are in place.

But in the meantime there are smaller (but tasty) fish to fry. For example, while it has been implied that StaxMate ought to work with any old Stax implementation, it really has only been tested on Woodstox. Of other implementations, there is just one that actually matters, Sun Streaming Java Xml Parser (Sjsxp), which is bundled with JDK 6 (and 7, I assume). After some testing, turns out that StaxMate 1.1 almost works with Sjsxp. But not quite. 2 particular fixes were needed to get all unit tests to pass. Given that this was relatively easy to do, and that results are useful (one can test StaxMate using, say, Sjsxp, and upgrade to Woodstox as necessary), I think this might just be the main new thing for StaxMate 1.2 maintenance release; and if other low-hanging fruit are found, there's always possibility of cutting 1.3.

Friday, June 20, 2008

On Rock Star Coders: thanks Dan!

Getting compliments is always nice, and never more so when they come from someone who you respect professionally. As such, I was delighted to see this interview, which talks about various things, including performance of xml processing with web services. But more importantly, I was mentioned. :-D

It also reminded me of why I should write a short essay on "6 Java XML processing tools You Should Know About". Stay tuned.

ps. Dan, your 30 yr old Macallan bottle will be delivered shortly.

Tuesday, May 20, 2008

Sisu Principle: Simple, Sensible, Useful

For a while I have tried to think of a concise but general definition of kinds of tools I like. Being a pragmatic person, I like things that "just work", the highest accolade any software library or application can get. I also eschew unnecessary complexity -- complexity is enemy of robustness; and while it is always possible to easily add more complexity, it is generally very hard to remove added complexity. And finally, the thing has to be useful to be of practical interest.

And then it occured to me: condensed to essentials, these are the 3 main properties that I like:

  • Simple ("as simple as possible, but not simpler")
  • Sensible (or, Smart)
  • Useful

Taken together, it leads to acronym SISU (or, SiSU), which also happens to be a useful term in Finnish language (roughly translating to "have guts", the trait of a person who never gives up).

So let's hear it for "Sisu Principle": best tools are Simple, Sensible and Useful. They got Sisu, and form the backbone of good software systems. They are also things that can carry overhead of other of kinds of sisu-less components.

Thursday, April 24, 2008

Progress of Servlet 3.0 specs, pluggability

I have not really been following progress towards Servlet 3.0 specs (beyond observing some discussion regarding "asynchronous"/non-blocking servlets). But this blog entry by Greg the Jetty Author (a very smart and talented individual, and thankfully, a leader within Open Source Java community) caught my eye. It is good to know that there will be more pluggability -- monolithic nature of web.xml has actually been one of my pet peeves lately. But perhaps the most interesting "new" thing was the reference to things that already exist within Servlet 2.5 specs. I guess this should teach me to pay closer attention to new developments... while 2.5 annotations seem limited, they are existing extension points nonetheless.

Anyway, who'd have thunk: after years of trusty service by mostly basic vanilla Servlet API specification there seems to be actual useful improvements to be had from the latest revision.

Friday, April 11, 2008

Let's hear it for the "51 Unsung Heroes of Woodstox"

One thing that has amazed me throughout the development cycle of Woodstox has been amount of invaluable, free and extensive (and sporadic, unexpected and chaotic as well) support from the user community. Most communication has been very helpful, especially when a user has both reported a problem and pointed out a reasonable solution for it. And quite often even contributed a unit test to verify the fix. That's kind of support you just can't buy.

Extensiveness of support is evident from the simple fact that there has been no fewer than 51 individual contributors to Woodstox. And while some have provided more than their share of useful feedback, each and every one of them has been integral part of success of Woodstox. Implementation quality would be nowhere as good as it is now without these individuals, and scope of functionality would likewise be less, and not directed as well to reflect actual user needs. And their help should be appreciated by the huge group of developers who use Woodstox even without realizing they do this: given that Woodstox is the de facto standard Stax implementation within J2EE world (being the default that ships with JBoss, Geronimo, possibly with Glassfish; being recommended by CXF, Axis 2 etc. etc.). I guess it could be called a virtuous cycle, "take a penny, leave a penny". Whatever it is, it works and does wonders.

Anyway, the full CREDIT file is the simplest way to browse Woodstox List of Fame. Let's just hope that next 4 years will bring as much as good help as first 4 years of the project!

Wednesday, February 20, 2008

Cowtown Classic Project I: Codebounce Applet

The first "Forgotten Project" (see Forgotten CTC Projects) to be refurbished is a simple applet called CodeBounce. It's one from class of things ("those goddamn useless applets") that many web surfers in late 90s considered a major annoyance. Had it been deployed by hordes of home page designers, it might have been infamous. It was not, for better or worse. :-)

Applet (which can also be run as a command-line application, via "java Bounce") is simple eye candy, displaying hard-coded number of elastic bouncing balls, bumping into each other and so forth.

Now, there is nothing spectacular here, just 600 lines of trivially simple position and velocity calculation code sprinkled with AWT code. But it is kind of amazing that it still works as well (or poorly) as the day it was written, come to think of that. At the time JDK 1.1 was already mature, and that was the platform on which it was tested, although browsers still only or mostly supported 1.0.2. And runs just as expected on JDK 1.6, including adapting to resized main window (well, as I said, as well as it ever did). It was also cool that even when Java still did run slowly back then, as interpreted language, applet was plenty fast on an antiquated Pentium 66 mhz PC and Netscape browser.

At the time I had done at least 3 other apps in Java (NetReaper, Fractalizer/Fractlet and JiveTerm a.k.a SafeTerm, and this is by far the simplest. But I kind of like that -- writing Java apps and applets was refreshing: after having to write thousands of lines of C code to get anything to show on a window, 600 lines of code for this puppy seemed very compact indeed (although not nearly as compact as those 100 line basic programs in C-64, but close enough, and much prettier).

So that's the part explaining "what". But more importantly, why? Why was it written? CodeBounce project page talks a bit about this. Basically, I wrote it as a proof-of-concept, trying to figure out some simple animation, to be used as an Easter Egg for a well-known and widely used commercial application. In the end, things worked bit differently: easter egg(s) were added (go Phoenix team!), but this particular idea wasn't used. It was simpler to use static graphics and straight-forward linear shuffling. But writing the thing did help in many other ways -- I hadn't used Java for almost a year at that point (having had to work on C, C++); but going back felt like home. So I was even more motivated to find a company that did use Java. I did, and got hired there (company's name nowadays even reflects their use of Java; that's the only hint I'll give). But that's another story for another day.

Oh, and as to the Easter Eggs: sad thing is I don't even know how many (or any?!) users know about these particular ones. Many people are familiar with the "martian guy with laser gun". But I doubt many have seen the "shuffling web form components". It was still cool to have added my own "footprint on concrete", so to speak. Besides, there's at least one other cool Easter Egg in there, which adds "eyes that follow mouse pointer" in there, that I didn't write but knew about, and which probably is as little known as ones I worked on.

Forgotten CowtownCoder Projects

While taking a walk down the memory lane last week (see Woodstox Pre-History), I remembered something that had slipped my mind for a while: there are projects that used to have home pages at CowtownCoder, but that basically got orphaned during ISP migration. The idea at the time must have been to focus mostly on active and relevant projects, like boring old xml parsers and such. Fortunately the old project home pages were obviously archived and well preserved, so I figured it would be nice to refurbish ones that have some significance to me: either by maybe being useful, or if not, providing some entertainment value.

Ok, so I will just copy over old home pages, source code packages and such? Well, more important than this, I will not only slightly clean up the pages (and, heh, add some useful decorations that you may notice on the right-hand side of the page -- keep in mind that they are interactive, too, you can like, click on them too, to see even more pertinent information!), but I will also produce a blog entry discussing each and every project. Think of it as preservaction of Geek History by documenting obscure projects that Tatu once worked on for whatever reason it was at the time. Damn I feel good to be such a dedicated preservationist! (is there such a word? now there is!)

So: you may see new links starting to pop up at the Hatchery page. And you should also start seeing short descriptions of the same projects, with some choice "Author's Commentary" entries on this very blog (you will have to wait a bit longer for your picture DVD containing the same: and please, do not hold your breath). Stay tuned!

Monday, February 18, 2008

Release Early, Release Often: Jackson 0.9

After fixing couple of bugs in mapper, I decided to release the next pre-1.0 release of Jackson Json Processor, version 0.9.0. There are no drastic changes, just couple of bug fixes.

As usual, release notes lists changes, and CREDITS file lists kind developers who have helped weed out the bugs fixed.

Wednesday, February 06, 2008

Maintenance releases: Woodstox 3.2.4, Jackson 0.8.2

Public service announcements for 2008

Quick update on state of projects: both Woodstox and Jackson projects released minor bug-patch versions to kick off the new year.

Releases are available from respective home pages, and here are quick links for change lists:


Sponsored By

Related Blogs

(by Author (topics))

Recommended Tools

Powered By