Further along with Spring

Probably, it should not surprise anyone (it surprised me, but then I'm novice), the fact that Spring almost anticipates what I would want of it next. No, not really. Well, for the most part it does, but one thing more I wanted was: when several threads make a call to transactional service, and the transaction isolation is set to be readonly, I was expecting that Spring will reuse same DB connection in both threads (like most grown-up EJB servers would). It wouldn't. Sigh. Maybe it's just me, I admit to reading at most 5 pages of Spring documentation so far :)

// import java.util.Iterator;

Generics, here I come! Strange, for how long I've been a (silent) opponent of Java 5 new features. This came to pass, as I'm converting a huge body of code to use Generics. Find that experience strangely satisfying. Oh, yeah, I remember now why I've been in opposition: I was afraid that tool vendors will not keep up with this syntax change, and/or that our favourite IDEs will be slower due to extra burden on parser... Yep, this is a price to pay. Need to submit a bit of code to JetBrains: IntelliJ will not parse properly a small bit of code with parameterized Collections (maybe this bug has already been filed, though; need to check first).

Update: found a caveat in how immutable instances of empty parameterized collections are to be handled when they are created. The usual Collections.EMPTY_SET will generate a warning. While an example in JavaDocs is working fine when there is assignment: Set<String> s = Collections.emptySet();, it does not in a context like this: callSomeMethod(Collections.emptySet());, if method signature is callSomeMethod(Set<String> input);. Unfortunately, the following contraption is needed then: callSomeMethod((Set<String>) Collections.emptySet()). Now compiler is happy, it has enough information to derive type of the collection.

Update: it was not a bug really, just some cache staleness occured. Restarting IntelliJ has resolved the issue. But while IDEA was restarting, I took a look at JetBrains' bug database. The list of bugs is quite long... Which got me thinking, how sad that each software company, no matter how bright, ends up drowned in bugs allowing competition a chance to hold some proving ground. No, JetBrains is nowhere near "drowning" in bugs yet, but I think it's inevitable, someday they will.

The Inquirer.net sellout?

I could be paranoid, or I could be right. For a few weeks after theinquirer.net was acquired by VNU network, I was wondering when will the new owner start milking this well-respected online publication. I could be that it started recently. A bunch of articles, distinctively subtitled as "First Inqpressions" (witnessed by reviews of wireless router, big budget game, and appliance for small business) and penned by "INQUIRER staff" offer something that looks like paid-for reviews to me. Now, they don't offer reviews for atrocious things. And about things mediocre they vailedly manage to say how it is. But these are paid-for pieces to me. I could be wrong, don't hesitate to tell me if I do.

Update: it was silly of me to have any doubt. The link to parent company is quite overt. These pieces are likning to http://www.pcw.co.uk/, which proudly boasts VNUnetwork logo at the top. So, the question now is, how diluted will theinquirer get. I personally valued this site not for their stance on AMD vs Intel (myself being a modest investor in AMD), but for highly caustic commentary on all things High Tech.

Refactoring (so hard to let go)

Did you happen to come across a utility method that returns Collection, but which can return null as well? What do you do then, if this method is being used in half a hundred of places across entire code base? What do you do if in some places people have actually started relying on this method returning null in those cases when it does? Naturally, as you work through the uses of this method, you find that as many places do not perform check for null... How does that make you feel? Do you enter 50 bugs and fire it off in the general direction of QA to let them dispatch? Or do you do it all yourself, taking risk of broken build? Who else do you tell this about? Does your manager have to know (it's hard to justify, you know.... what's the big deal with this code being broken anyway)? Hard to let go.

Update: the result, in two places code was broken after the refactoring. In one place, regression tests caught my mis-deed. Another was caught and corrected by a collegue (my heartiest thanks to him). Companies bigger than average have this robustness to them :) Not redundancy, no.

Project Darkstar (Sun Gaming Server)

This piece of technology must become a good learning experience for many aspiring game developers. But, honestly, what's up with their promised performance of each "slice"? They say, it is going to support 200 to 500 players. I wonder if that's a workable scale... Sun wants some service providers to load up racks of servers and to rent them out, but is it possible to make any money after all cost is factored in? If game clieants are programs running on mobiles, for any decently big game one would need a server farm on order of tens of hundreds of servers. I just hope that number of concurrent clients supported by a slice can be streched further depending on number of parameters, like how interactive a game is, how many objects is the world populated with, etc. For instance, turn-based games are much less interactive. Does it mean such games are not supposed to be run on this server? Need to look around it a bit more. But I did like this in the introduction: "single stack of software running in a single process space". I've been advocating this approach at work, without success for now, since I set foot on campus.

Google Calendar: why did it take so long?

It could not have been technical issues that had this project delayed for so long... How long exactly, I'm not even sure. Year and a half ago, when I actively interviewed for a new job, I had a contact with Google's GMail hiring person and in that conversation I was trying to sell my experience in building an online calendaring application (can be checked out by anybody willing to, web registration was always free), and (although not immediately visible) providing APIs for mobile calendaring client. Nothing extremely fancy or unusual, but a working, scaleable web app with proper backend and covering over 90% of types of recurring (or reoccurring, for those who like this spelling more) events as compared to MS Outlook. At that time, I suggested that GMail needs a tight integration with Calendaring application (since your contacts are already there), and also needs to integrate with freshly acquired Google Earth to have addresses mapped easiliy. Now, it would be silly to think that this suggestion was a revelation and that it affected Google's PIM (for Personal Information Manager) product roadmap... These ideas are pretty much laying on the surface.

Anyway, recognition of addresses in emails was implemented much sooner than Calendaring application, even though work on Calendaring application was already ongoing at the time my phone screen interview has occured (which I did not pass, by the way, failing question on algorythms; Google's hiring process is sometimes as rigid and as random as the one I'm participating in at my current place: good people get turned down frequently). At Xpherix, we had Calendaring app working (and integrated with synchronization software) in around 6 months. What took Big G 2 years? I'd guess, the so-called "due diligence" big corporations have to pay respect to. See, the PIM territory is a minefield of patents. All underlying technologies involving data storage, transmission, representation, and synchronization are claimed as somebody's IP. If RIM's troubles seem not directly linked, recent motion by Visto to sue an estabilished data synchronization company are much closer to home. And all this aqcuisition activity: Intellisync, etc.

Problem is, there are only so many ways to solve those kinds of issues (not counting stupid ways, which BTW live in products by big names; say, Sun's calendaring sever, AFAIK, stores regular instances of recurring calendar events as separate records, which forces them to cap the "event horizon" at few tens of yesrs from start date. Ours was smarter: one record for all recurring events, plus two records for each exception, coupled with a scary-ugly SQL to do initial filtering. That was good stuff actually. Should we have patented this? :) ). I should stop here to not to launch into the usual software patents debate. No point, it's all business as usual. But if it took Big G, speculatively, one full extra year to clarify issues, what chance does a smaller company have? There's just one chance: do it and hope your company is small enough to slide under a radar of litigious types, yet just big enough to make a living off of your products. Afraid this means only one-person-strong companies can live in this world. IP carriers, huh?

Update: Big G has taken the same "stupid" route I mentioned above. For recurring events, they put a cap on number of occurrences. To see for yourself, create an event that repeats every weekday and set no end date. Then, navigate into the future: sometime in 2008 your event will no longer register... I don't believe they're just stupid, it must be that a more elegant approach is barred by a patent. I wonder who holds it... Hmm, could be some company that participated in IETF's iCal standard development and so put a stake over there as well? You guessed it right: Microsoft (United States Patent 7016909, and may be others). Still too big for Google to take on, yet.

According to http://googleblog.blogspot.com/2006/04/its-about-time.html, Google Calendar is compliant with iCalendar standard. Hmm, haven't seen anything there saying recurring calendar event definition with no end date should generate events for under 400 instances. BTW, why so many, exactly? And how many, exactly? Is it simply 365? Is it 21 months worth of data? Wonder, how much it costs to license Microsoft's portfolio of patents on Calendaring and Scheduling. Do they even allow anybody to license it, or do they just keep it between them and IBM?

Another update: just double-checked Yahoo's Calendar. It does not have this problem. Apparently, Yahoo has cross-licensing agreement with other "haves" to use this efficient algorythm. So, why hasn't Google?

Recap of recent weeks (Spring framework).

Let's see... When I was laying down with severe stomach flu last week I had a bunch of ideas of what to write about here... Where did it all go?

Had first encounter with Spring. Amazing technology, really. I started looking for some container that will have contextual support for persistent operations, basically. Mostly because I got sick of seeing code passing, from one method into another, some custom construct tying together database connection and current statement and/or result set (Did I mention how twisted are some designs I encounter at my workplace? I'm sure I did :) ). I wanted something akin to how it's done in EJB, but without an EJB container (it's unthinkable to expect us to deploy a full-blown J2EE stack in any foreseeable perspective). Very glad Spring allows for this. It took me two partial weekend days overall to figure out a working XML config file. After I figured it out, it all makes sense:

• configure a DataSource (I'm using embedded Derby; this has a nasty effect that shutting down Derby cleanly is not possible without writing a wrapper DisposableBean, as Derby will not take a single no-arg method call to go down....)
• using this DataSource, create a Hibernate SessionFactory
• using same DataSource, build transaction manager
• take that transaction manager and stuff it into a DAO alongside SessionFactory (make sure DAO implements an interface, and when casting the object acquired from application context aka bean factory, cast the object to that interface; again, result being not unlike EJB or RMI stub compiler would produce)
  

The DAO has very little code. In fact, less than a plain Hibernate solution would have, benefit of famous HibernateTemplate. As an extra bonus, I get declarative transaction support, all worked in by a little AOP magic. Hoping to have significant time savings to result out of this for my project at work. And the project quickly approaches a major crunch... timely discovery, then.