Originally posted to LiveJournal on July 4, 2008

Since getting my new MacBook, I’ve been trying to pull off the pure Mac play - sticking with the stock applications, choosing integration over individual features, trying to work with what I’m given. It’s mostly worked out pretty well, but it’s taken a bit of tweaking. At this point, I’m working on a combined Mac/Google solution.

The ingredients are: MacBook at home, Ubuntu Linux at work, iPod, cellphone, old Palm Vx. Of the last three, I figured I should be able to at least ditch the Palm. It’s a workhorse, but it’s old and doesn’t play well with the Mac. I could go for the iPhone 3G in a few days. That would kill off all three, plus my digital camera. Tempting at $199, but the $100 $60 a month service plan is nuts for the amount I’d use it. It would take some sort of radical lifestyle or professional change to justify that. I’m not above throwing money at problems, but that’s just profligate.

Getting all my info off the Palm was pretty straightforward. Jpilot let me save all the calendar and to-do info as .ics files. After a small but annoying bit of tweaking to DOS-format and rename them, they uploaded smoothly into iCal. Similarly for the contacts and Address Book. That was one of the big wins - having all of my addresses, phone numbers, email and IM in the same place. Once that was all done, it all synched seamlessly to my iPod. Nice. The only snag (Apple developers, listen up!) is that the To Do list displays on the iPod in alphabetical order, not by priority. Come on guys; what are you thinking? Notes were also a bit awkward. You have to mount the iPod as a drive and save them as files in a “Notes” folder. No application integration there. Still, it might make sense to start storing To Do lists as Notes. If I work with them regularly, I may get used to them. So that’s awkward, but not a killer.

The killer turned out to be that I can only sync the iPod to one machine. The whole philosophy of the Palm is that you can go from home to work and keep your core info in sync. Even on Linux, there was a decent client that I could run either at home or at work. The iPod will really only talk to my home machine. That’s kinda control-freakish. It means that when I’m away from my MacBook, I would need to write down appointments on paper or something, and enter them in when I got back. That’s annoying enough that it got me playing with Google Calendars.

Google Calendars are pretty slick. You can have multiple calendars, set up different access constraints for them, and view them in a single display. My girlfriend and I each have personal calendars that we share with each other, and then I have an “events” calendar that’s open to the public. There’s probably also a middle ground for friends: Stuff that isn’t really private, but I don’t care to have strangers knowing, like who I’m having dinner with tomorrow.

iCal lets you set up read-only calendar “subscriptions”. So I re-exported my calendars, uploaded them to Google, deleted them from iCal, and slurped them back down as subscriptions. From there, they synched to my iPod just like before. I was also able to set up a subscription to our calendaring software at work (Zimbra). That’s gravy. Normally, I only have to worry about meetings and such when I’m in the office and have access to the calendar directly. But it is nice to have them on the iPod with audible alarms and all.

While I was at it, I discovered that Google Calendars has a handy text messaging (SMS) interface. You register your phone with them, and then you just send messages to “GVENT” (48368). Sending “day” gets a response with today’s events. “happy hour at 5pm tomorrow” creates a new event. You can set up events (individually or by default) to send you a text message alert. So if I’m going out without my iPod, I can have my cell phone remind me when it’s time to move on to the next round of fun. I don’t actually see myself using that a lot, but it’s nice to have as backup.

I watched Merlin Mann’s “Inbox Zero” Google Tech Talk video the other weekend, and I’ve gotten all fired up on that. I’d been letting stuff just pile up in my Gmail inbox because I don’t actually get much mail there. Gmail doesn’t use the normal folder setup, but it has Labels, which let you do much the same thing, and a bit more besides. So I got everything tagged and archived in short order. Set up a few basic filters to handle list mail that I only need to check every day or two. They’re not super sophisticated, but they do the trick. An empty inbox is a nice feeling.

I also started playing with Google Docs. I haven’t done spreadsheets or presentations yet, but the documents are nice. They strike a good balance between features and simplicity. I’m a little paranoid about storing all this stuff on a free “beta” service, so it was nice to find that you can easily export them as HTML (and relatively clean HTML at that).

So I think that may be the winning combination. I could also look at the iPod Touch option, which would give me a way to enter data on the go. Right now, the only problem situation on the horizon is DragonCon, where I have to track a whole lot of events, and I’m not planning on lugging my MacBook along. It could be handy if they would publish an ics file with the complete schedule before we got down there. Maybe a separate one for each programming track or room. Hmm…

Spent half the day fighting with Tomcat 5.5, trying to get log messages out of my application. I need to rant a bit here.

I’m deploying a vanilla webapp with its own log4j.xml in WEB-INF/classes. Why does this not just work out of the box? Because, hey, maybe you’d want to use some other logging library. Not that there are any out there that don’t suck, but y’know, maybe someday. So we need to leave this all open-ended and configurable.

You see, once upon a time, we had Log4J. It was good. In fact, it was perfectly sufficient. It solved the problem. It did just about everything you could want.

Unfortunately, Sun was also developing their java.util.logging (JUL) around that time. They went through the whole JSR community process, so they started earlier and finished later. It sucked, but Sun owns Java in a very literal sense, so we were pretty much stuck with it. Not in the sense of actually having to use it, thank god, but any poor bastard writing logging tools had to accommodate it.

So then we got Apache Commons Logging. It’s a diplomatic facade that stands in front of either of them so your code can be agnostic about whether you’re using Log4J or JUL under the hood. In practice, anyone who doesn’t have a paycheck from Sun and a gun to their head uses Log4J. Java Developer’s Journal did a comparison of the two. They tried to give a “fair and balanced” report, as in, “there are situations in which JUL might be the better choice.” If you read between the lines, those situations were essentially if you’re writing a toy application that would probably be fine with System.out.println().

There’s something of the paradox of choice here. Trying to leave all your options open is ultimately less effective. Your code has to be way more complex to support everything, and you almost always have some sort of mismatch that forces you into a limited-functionality common denominator. It’s not worth it. Pick something that works and go with it.

So today’s pain came about because rather than doing that, Tomcat 5.5 seems to have slapped yet another layer of indirection and indecision on things. It seems that one of the ways in which java.util.logging sucks is that you can’t have multiple configurations within an application. Why on earth would you want to do that? Well, if your application is a web application server, it needs to run a bunch of java libraries as if they were standalone applications. Kinda killer flaw there, huh? But who can pass up the challenge of hacking around something that thoroughly broken? And hey, it’ll make it standards-compliant.

So you end up with these gems from the Tomcat 5.5 logging page:

the default Tomcat configuration will use java.util.logging.

And a bit later on:

The default implementation of java.util.logging provided in the JDK is too limited to be useful.

How can you say that and still build in support for it? Grow a spine, people! How much simpler would this world be if you just followed that up with, “…so Tomcat uses Log4J exclusively. Don’t like it? Write your own app server.”

But no, what did they do? They hacked together their own implementation of the java.util.logging API. Apparently, it’s not “too limited to be useful,” but it “is not intended to be a fully-featured logging library.” Why bother? You’ve had a fully-featured logging library for the last 6 years. Why would you make the default logging configuration one which by your own admission is really not adequate? Why not make Log4J the default? If you really have to, then you can provide instructions on how to plug in your half-assed substitute.