java.util.Scanner

Why haven't I known about java.util.Scanner? Well, now I know.

OSGi to eliminate app server restarts?

As I've been pondering ways to improve the configurability of my work project across multiple deployments, OSGi has suggested itself as a potential solution. Primarily, I would like to allow other deployments to select the set of modules, and the implementations of these modules, that are placed into use in various production environments. Though I soon realized that our current Spring-based configuration mechanism is probably sufficient for managing this level of configurability; one merely needs to change the implementation classes that are defined in a XML file. And so OSGi might be too heavy weight of a solution. The main benefit of an OSGi solution, as I see it, is the ability to dynamically swap in and out these subsystems. But this dynamicism is not really necessary for my project, since deployments are fairly static once configured.

But then I thought to myself, how nice would it be to be able to replace modules during development without having to restart the application server? This is one of the larger time sinks developers face while developing web apps. In fact, it's enough of a problem that it spawned a commercial solution, JRebel (why I haven't tried this out already, is beyond me!). Shouldn't an OSGI app, if designed properly, be able to address this problem as well? If only a minimal skeleton of code is needed to bootstrap the app, and the majority of the code is comprised of OSGi bundles, then shouldn't we be able to dynamically update pieces of our running web app? I need to look into this further.

One other benefit of OSGi is the "runtime enforcement of module boundaries" [ref]. That's a very appealing feature, as well.

Since the Spring application framework now has OSGi support, it may not take too much to move to an OSGi-based design.

My Tags

With nearly every content-management social networking site providing some sort of tagging feature, one finds themselves with many site-specific tag "vocabularies". I feel that an individual should have a single tag vocabulary that is accessible from each site, so that the tag "suggestion" feature on each site can draw from a single vocabulary. I'm also finding simple tags to be somewhat too simplistic, in that I would like to maintain a tag hierarchy so that a given tag implies its parent(s). And possibly other meta data about my tags (comments, term disambiguation, composite tags, etc.). Having a dedicated tag vocabulary system would allow an individual to maintain such structure and meta data for his tags. "Consumer" sites of these tags would not have to each implement their own versions of advanced tagging features. Such a system might also facilitate more interesting cross-site analyses of content, for a given user.

Google Reader "sort by magic"

Just ran across the "sort by magic" feature on Google Reader. I always thought a news reader app should help you find the articles you're interested in, and now it seems Google has delivered on that idea. I look forward to seeing how well this works. All it requires, apparently, is that your mark articles as "liked". Arguably, it should also take into account starred and shared items as well, right? For now, I'm marking my starred items as "liked" (recent ones anyway). Fortunately, you can apply this option to individual feeds, and I only intend to use it on the high volume, heterogeneous feeds (e.g., ServerSide, InfoQ, etc.).

Hibernate Hawthorne Effect

I really enjoy how the act of debugging Hibernate LazyInitializationExceptions is often subject to the Hawthorne Effect. While using a debugger, the very act of inspecting an entity can cause Hibernate to fetch the entity relationships that would otherwise remain uninitialized (the code must be executed within the scope of an active Hibernate session). The fact that extra relationships are being fetched in response to debugging, can cause LazyInitializationExceptions to disappear.

Scala string reversal gotcha

Be careful when invoking Scala's RichString methods on a java.lang.String (via implicit conversion):

scala> "8008".reverse == "8008"
res0: Boolean = false
scala> "8008".reverse
res1: scala.runtime.RichString = 8008
scala> "8008"
res2: java.lang.String = 8008
"8008".reverse == "8008".toSeq
res3: Boolean = true

That toSeq call is unfortunate, but necessary.  I suppose this is the price we pay for having Scala String literals be typed as Java Strings.

apgdiff

I encountered a defect yesterday that was caused by our production database schema being out-of-sync with the domain model. Our schema has undergone numerous migrations over the course of a few years. Each migration involves applying manually-written SQL scripts that update the schema while migrating the extant data to the new schema. It was inevitable that some schema change was going to be omitted from a migration script, and that's in fact what happened. So I decided it was time to perform a full schema diff (actual versus expected) to see if we had any other hidden time bombs. I exported the schema from both a newly created database (schema only) and the production database. But one cannot perform a straightforward diff on these schema SQL representations, since ordering of objects (tables, triggers, etc.) and nested items (table fields) may be different. So I found apgdiff, which performs the necessary "intelligent" diff. Instead of standard diff output, it outputs the SQL needed to bring the old schema up-to-date with the newer one. After tracking a NPE in its source code (caused by a missing create table statement and an associated alter table statement), it worked. It's a nice, straightforward tool that I will integrate into my development process. In particular it will save me time when the next schema migration script needs to be written.