Today we took the boys to Blue’s Clues Live. I continue to be impressed with that show. It’s not perfect, of course, and some of the marketing and paraphernalia is too much. But they find creative ways to teach interesting stuff, they teach morals and ethics without being preachy, and the kids love it.

I’ve always thought that, in particular, the music on Blue’s Clues stands out. They incorporate music from every genre you can imagine, mostly cleverly adapted versions of the various themes from the show. And nearly all of it is much better than the usual music from children’s TV. Today, believe it or not, the stage show included a distinctly Koyaanisqatsi-ish minimalist Philip Glass-style piece. But to the kids, it was all just music, which is the way it should be.

I think Ruby is a much better language than Perl, but it’s definitely true that the libraries aren’t as mature. Here’s a problem that has just annoyed me for the second time.

All of the creation methods for the Time class take similar arguments, exemplified here by the Time.local method:

Time.local(year [, month, day, hour, min, sec, usec])

But the ParseDate::parsedate method that does a good job of parsing date information out of human-readable strings returns this array:

[year, mon, mday, hour, min, sec, zone, wday]

You really should be able to type Time.local(*ParseDate::parsedate(timeString)) but you can’t. You’ve got to chop the last two elements off the array first. That’s not hard in Ruby, but still …

So far as I know, there may already be a remedy for this in CVS. But there really ought to be a Time.parsedate(aString) method that does the right thing.

… and complicated things should be possible. And, for that matter, not unnecessarily complicated.

I don’t know how many years it’s been since Alan Kay said that, and people still don’t listen.

I’m working on an application now that uses a Swing-based client, deployed using JNLP (i.e., Java Web Start). The client talks to a SOAP-based web service. It’s written using Apache SOAP, which has worked out pretty well, but for various reasons I’ve been looking into reimplementing the web service part using Sun’s JAX-RPC.

Some background: JNLP-based apps are deployed from a web server, and launched (the first time, at least) from a web page. But they’re full-fledged Java apps that get downloaded as JAR files and run on the client machine. So the best way to package it is to put the whole client—the JAR files, the HTML pages, and the JNLP file—in the WAR file with the server-side stuff. And that’s the way our build system works. We compile the whole thing, build the client JAR, and then build the WAR that includes the client.

In JAX-RPC (at least, in Sun’s implementation of it) they’ve tried to make the process easy. The service is defined as an RMI interface, and the implementation also fits RMI conventions. So far, so good. Then you compile the service definition and the implementation class. Then things get bad. In an effort to make this all simple, they’ve gone too far. The next step is that you package your server and a SOAP mapping file into a WAR file, and pass that WAR to a tool called “wsdeploy”. That tool reads your WAR, generates stub and tie classes that are used to hook the client and server code into the SOAP infrastructure, and then repackages your server, along with the tie classes and the server-side SOAP support, into a brand new WAR file.

All of that has to be done before you have the stub files that you need to properly compile your client code. So our nice, clean, 3-step build process (compile, package client, package server) turns into this:

1. Compile server
2. Package server into WAR
3. Run wsdeploy, which does these things:
   • reads the WAR
   • generates stubs and ties
   • rebuilds the WAR with ties and SOAP infrastructure included
4. Compile client
5. Package client
6. Add the client to the WAR file.

That’ll sure shorten the edit/compile/debug cycle and keep my ant scripts clean.

It turns out that there is another tool, xrpcc, that generates the stubs and ties in a more conventional way. But I haven’t been able to find any documentation for that tool. It, too, uses an XML-based config file to define the SOAP mapping, but it’s a different flavor of XML, with no documentation that I can find.

I’m all in favor of a good out-of-the-box experience. But it’s frustrating to hit a brick wall when you try to move beyond that to real work.

I’d like my entire blog to be self-contained. That is to say, I’d like to be able to move it to a different URL someday, if necessary, and have everything still work. (Permalinks that others had saved wouldn’t work, but that can’t be helped in this case.)

Right now I don’t see a way to link to another blog entry without including the full URL, like this. It would be nice if blosxom supported a special tag for this, or at least applied the $url template variable to the body of the entry. (Of course, then it would need to provide an easy way to escape dollar signs in entries, so perhaps the special tag would be best.)

Here’s another idea for Blapp. Not often, but occasionally, blog ideas occur to me faster than I can write them. Right now I’m recording the ideas in a sticky until I get time to write a proper blog entry, but it would be nice if Blapp would maintain a little list for me to dribble those half-baked thoughts into.