Tuesday, November 25, 2003

Belkin Voice Recorder for iPod Yep, it's a voice recorder. It's an elegant design, and the integration with the iPod OS is seamless. However it's a pretty mediocre device otherwise. The speaker is not very loud, nor is the microphone effective beyond a couple feet. If you're looking for a way to record your voice, it's just fine. If you want to record meetings (or anything other than yourself), look elsewhere. One minor gripe: after you sync with your desktop, the voice recordings are added in with your other "songs". If you put your iPod on shuffle, don't be surprised if you inadvertantly end up a featured artist. Disconcerting... 1:08:30 PM    comment []

Monday, November 24, 2003

Another Axion Bug One of my co-workers was working with Axion this week, and the database was mangling all the non-ascii characters in her insert statements. Axion was only set up to accept unicode correctly via bind variables; regular statements did not work. I changed the javaCC parser to use character streams instead of byte streams, and everything seems fine now. If you've had Unicode problems in the past, the HEAD branch of Axion should be an improvement. 2:48:24 PM    comment []

Thursday, November 06, 2003

De nada I was browsing through some referers, and I happened across this blog entry. Yes, the Latka software is very polite, but I wonder if Kurt realized the REAL reason for that particular phrase. 9:28:16 AM    comment []

Monday, November 03, 2003

naviPod'n it I finally took the plunge and picked up an IPod. Very nice. I also picked up the naviPod, which adds an extremely simple IR remote to the IPod. The naviPod's IR sensor is much more sensitive than I was expecting. I have no trouble controlling the IPod from 35+ feet away with my universal remote control (but slightly more trouble with the included remote). However the integrated line out, which is probably just a pass-through to the headphone jack, is noticeably lower quality than the line out on a standard IPod dock. I highly recommend using a standard IPod dock with your stereo hookup. The naviPod's remote control has pretty good range but requires a completely unobstructed line-of-sight to work reliably. Also, the volume control will only operate the integrated line-out, not the line-out of my IPod dock. I trained my universal remote from the naviPod remote so that I could control track navigation and volume from the same device. However, the naviPod remote is one of the tiniest I've ever seen, so it's still convenient to use in addition to a universal remote. It's a little pricey, but I plan on trying the Belkin voice recorder when it's available. I'll post some info on it later on. 12:03:42 PM    comment []

Wednesday, October 22, 2003

Gamefly I got an offer to try Gamefly free for 21 days, so I've been giving it a look. I must say, it's pretty convenient and economical. The cost is $21.95 per month, which is pretty low considering that most games retail for $40-$50. The only two drawback are a) there is no manual (only controller instructions), and b) they don't carry PC games. Surprisingly, they DO carry GBA games. So far I've rented four games, and I'm still working on two of them. Here are my capsule reviews. BloodRayne (XBox version): bad. Otogi: Myth of Demons (XBox version): OK. Freedom Fighters (XBox version): great. Viewtiful Joe: great. I'm also playing Battlefield: 1942, which is still a blast a year later. If you like multiplayer PC games, I wholeheartedly recommend buying it and the latest expansion. Good fun. 12:07:55 PM    comment []

Tuesday, October 21, 2003

Categories added I finally added categories to my 'blog. My entries have actually been categorized for a while, but there were no links to them on the page. Now there's a "Code" category for programming-related stuff and a "Fun" category for the, well, fun stuff. And there will still be the homepage feed, which will contain all entries including those that don't fit into the other two categories (like this one). Feel free to subscribe to the "Code" or "Fun" feeds if this feed is too noisy for you. You won't hurt my feelings. :) 5:10:02 PM    comment []

Dipping into Axion I did some Axion debugging this week. Rod and I discovered that only SQL inserts are utilizing indices. Deletes and updates are performing table scans every time. Today I checked in a fix for simple delete statements, which produced a significant boost. A series of SQL deletes which took 638 seconds to execute before now takes less than 4 seconds. We're working on more complete index support for updates and deletes, so if you use Axion you may want to keep an eye on the repository activity for a while. 5:03:41 PM    comment []

Friday, May 02, 2003

Continuous integration Rod has started a series on our Continuous Integration environment [1] [2]. I've also jotted down notes on our CI process for my weblog, but Rod is doing a superlative job, so I'll leave it to the master. Just one comment on the series so far. When putting together a Continuous Integration environment, you want build failures to evoke one of two feelings: 1. guilt [...] 3 : a feeling of culpability for offenses 2. shame [...] 2 : a condition of humiliating disgrace or disrepute : IGNOMINY Source: http://www.m-w.com For most people, shame works better. 2:04:01 PM    comment []

JDK 1.4, now including the kitchen sink James: Be careful of JDK 1.4 No doubt.  However, James left out my favorite JDK 1.4 "feature", the built-in XML parser.  How convenient!  Unless of course, you want to upgrade or modify it in any way.  Then you have to resort to the incredibly awkward Endorsed Standards Override Mechanism, which is the least hosting-friendly addition to Java in recent memory.  While the Servlet APIs have in recent years made substantial improvements to the organization of their classloaders, the JDK seems to want to unravel this by providing the least amount of modularity possible. After making the very painful transition to JDK 1.4 a few months ago, I found myself wishing for an LE version of that JDK.  As far as I am concerned, the less APIs the better.  I could do without JAXP, without SAX (and thanks very much for grabbing other organization's APIs as well as your own), without Xerces, and even without JDBC.  I am capable of putting jars in the classpath on my own; I don't need Sun's help for that.  Or at the very least, repackage the classes that don't belong to you! Throw me a bone here, Scott! Making all those APIs modular does limit Sun's ability to intermingle them, but I think it's worth the tradeoff.  Otherwise, I dread all the new APIs I'll have to work around for 1.5. 1:43:14 PM    comment []

Encoding, schmencoding I was writing a character encoding FAQ for our company's Wiki when I came across something in the JAXP javadocs that has always puzzled me: StreamResult Javadocs:  Normally, a stream should be used rather than a reader, so that the transformer may use instructions contained in the transformation instructions to control the encoding. JAXP has a similar warning for StreamSource as well. Why is using character streams so ill-advised? The character encoding behaviour that XSL parsers should use seems pretty straightforward to me; everything should be keyed off of the output format specified in the XSLT template. If a character produced by the transformation is allowed by the desired encoding, output it (based on the user's preference) either as a single Java character or as a numeric entity. If the character is unsupported by the encoding, output it as a numeric entity. Isn't this is reasonable way to implement encoding? I guess the point of the warning in the JAXP docs is that if you are given an arbitrary Writer, you can't be sure if it is backed by a StringBuffer or an underlying OutputStream. If it's a stream, it's certainly possible that the Writer will receive characters that the character-to-byte conversion of the OutputStream does not support. However, it seems just as likely that, if you give the transformation an arbitrary OutputStream, the bytes produced will be subsequently misinterpreted by any code that converts them back into characters. In the simple case of performing an XSL transformation to a file, an OutputStream would definitely be safer. However if you were, for example, chaining the result of one transformation to another, using an OutputStream seems like an unncessary point of potential misconfiguration. I think JAXP's documentation is very poorly worded in this regard; the implication that OutputStreams are somehow safer seems false. And on the topic of encoding, there is nothing convenient about the "convenience" classes java.io.FileReader and java.io.FileWriter. If a principal goal of Java's is platform-independence, then those two classes are failures. They really should have made those classes use UTF-8 encoding rather than the platform's default encoding. At work I see lots of encoding problems that are caused by developers who use those classes. 1:15:59 PM    comment []