So I finally wrote a proper Cocoa app to accomplish a specific task! Here it is:

Ok, so its lack of actual UI makes it somewhat unimpressive. The "specific task" part is true, though. After running across a bunch of old AIM chat logs from various sources in my recent hard-drive-trawling, I decided to put them all in a DB for no discernable benefit, because that's the sort of thing I do in my spare time.

The AIM+ and two styles of gaim chats were easy, and I expect the Adium ones to be not too bad, but iChat gave me a little trouble. It's apparently used two formats over time, both of white are Apple-proprietary formats. I decided to focus on the older format, since most of the chat logs were circa-2002/2003.

After doing a little digging, I found that the files are in the format used by NSArchiver and NSUnarchiver, which appear to be the Cocoa method of object serialization. I pointed an NSUnarchiver at one of the chats and... it complained about not having the InstantMessage class. Fair enough.  After finding that Apple's InstantMessage framework is just meant for looking at your buddy list and doing AV stuff and not parsing logs, I grabbed the source of the horrifically-named chat browser Logorrhea. After I plunked its iChat data type classes into my project, all was well.

I found that the files consist of an NSArray (well, NSCFArray) with a mix of children representing chat attributes and the chat lines itself. I looped through that, checked the class of each one, and dealt with each appropriately. "Appropriately" in this case meant "converting to XML", so the agents in my database could read it back in properly. I haven't yet taken a whack at converting the body text from an NSAttributedString to HTML, so for now it's just the plain-text version.

It's rickety and I'm sure I did tons of stuff wrong, but it works! I ended up with a folder full of XML versions of the chats, ready to be imported next to the other logs. There's not much better to get your feet wet with a new environment than a clearly-defined basic task, I say.

For the morbidly curious, the pertinent code is here:

UnarchiverAppDelegate.h

UnarchiverAppDelegate.m

A couple months ago, I set out to cut down as many expenses as I could, and my Comcast bill stuck out like a sore thumb. Thanks to a couple weeks of daily five-minute outages, I had already been switching over to (similarly-priced) FiOS service, but my TV service remained. Not only is cable service with a DVR, reasonable channels, and good HD coverage an expensive proposition regardless, what really gnawed at me was how ludicrously out of proportion the cost was to the actual use I got from it. TV service was about twice as much as my Internet service, but, whereas I use the Internet just about 100% of the time, I only watch a couple hours of TV a week... most of which is available from those channels for free online.

One option was to switch from Comcast TV over to Verizon. It'd be cheaper for a while, but I have no illusions that Verizon wouldn't creep up the price over time as new-customer deals start to wear off, and even if they didn't, the price/usage mismatch would remain.

So I set out to tackle the nigh-insurmountable problem of successfully replacing cable service with a computer with a good net connection. I had a circa-2007 Mac mini laying around that fit the bill nicely, so I cleaned off the old Leopard Server installation and got to setting it up. There are a couple things that make replicating a good TV setup such a sticky wicket:

1. Many shows have their own, usually-crappy delivery mechanism. Some of them, conveniently, use Hulu, but some aren't even readily available at all.
2. Even when shows ARE available, the image quality is pretty much universally far inferior to real HD TV shows.
3. Much like replacing radio with an iPod, it's tougher to discover new shows without seeking them out. Fortunately, this isn't a huge problem.
4. Media center apps, while impressive, tend to have at least one crucial flaw that undermines their utility.

The first two problems have necessitated a step into questionable morality and technical complexity. Namely, I set up an RSS reader to pull torrent files for new TV shows in pretty-much-HD quality, then a torrent client to download them, categorize them by name, seed to 200%, and then stop the torrent. I still don't have EVERY show we used to watch, but I have the big ones, and they're in pretty solid quality.

The last one is an ongoing project. I started out using Plex, which is pretty great and edges out the competition with some Mac-specific support. However, its YouTube plugin is pretty lacking and I'd rather not resort (yet) to learning Python and writing my own. I've switched over to its progenitor XBMC for now, which has a pretty solid YouTube plugin, but took a step back on other video sources. I'm considering setting up a Windows partition on the thing to see how the options are on the other side (like MediaPortal), but I'd rather avoid having to do that.

Overall, my TV experiment has worked out pretty well, but it's primarily due to my specific situation. If normal TV was a bigger deal in the apartment (say, if we had kids), this would be a woefully inadequate replacement. Similarly, if I didn't enjoy doing crap like setting up RSS feeds for torrent processing or manually managing TV-show libraries and video-output settings, it'd be too much hassle to be worth it. And I certainly don't miss the Comcast bills.

Thanks to The Brads, I ran across Dribbble the other day, and it's the new coolest thing ever. The two main things that struck me were "man, modern web designs use a LOT of soft gradients" and "hmm, I really want to make some more web sites now." The latter is pretty much the point.

I've never been a web designer. With enough effort, I can sort of emulate one, but the results are expectedly mediocre. That's mainly because that's a natural extension of being a web developer - the stuff I program has to look like something, and CSS is essentially a programmer's design tool anyway. However, visual design isn't my gig, so I don't feel the least bit squeamish about cobbling together something reasonably clean and aesthetically pleasing from various sources of "inspiration" and calling it a day.

Fortunately, looking at nice, clean designs (like this WordPress admin site, actually, which I kind of like) is good inspiration nonetheless, since it makes me want to write something cool enough to rise to the occasion. A minimalist design with exaggerated tabs, labels, and such implies that the stuff you're looking at is organized logically enough to match, and that's the kind of thing I can do.

Now that GCD is a reasonable 1.0, Dribbble has me itching to move on to what's next. Far and away the best candidates for fancy new UIs are my various projects for work, but that's only ever so exciting. Maybe I'll take another pass at my Minecraft server to see if I can take advantage of its database-attached-ness. Probably better would be really diving into Cocoa programming - that'd be fun AND potentially directly useful for future job prospects. Heck, it'd even be good for my CURRENT job, since having a proper iPhone UI is on our list of big to-dos. Hmm, yep, that's what I'll do.

I'm not sure if "mixed-type" is the right term for what I mean, but it should do.

A couple months ago, I ran into a problem where I wanted to display the posts in a forum topic on an XPage, which isn't a terribly complicated thing to do. However, I ran into a bit of trouble in how, specifically, to go from the <xp:dominoView/>  data source to proper rendering of the rich text for each post, in part because some posts were MIME data and some were the native Notes rich text format. The rich text naturally wasn't in a column value, so I couldn't just refer to the column by name using the var name int he <xp:repeat/>.

I wrangled with this for a little while, writing JavaScript code to check if it's in MIME or native format, but I kept running into problems with how to convert the rich text data on the fly. I didn't want to just lose all the rich text formatting by using NotesItem.getUnformatetdText() or an equivalent, but I couldn't just return a NotesItem object to the <xp:text/> control. I knew that XPages know how to convert it, since they do it just fine if you're working with a NotesXspDocument, so I wanted some way to access that functionality.

<xp:panel/> came to my rescue. Within the <xp:repeat/>, I created an <xp:panel/> with its own data section containing an <xp:dominoDocument/> with its documentId property set to the UNID of the view entry I was currently working with. Then, I could just create an <xp:text value="#{doc.Body}"/> and let the renderer take care of all the details.

For all I know, that was an extraordinarily inefficient way to do it, server-wise, but it may be the cleanest way to do it from the programmer's perspective.

Getting Crap Done checklist:

• iCalendar feed? Check.
• Email reminders? Check.
• Basic mobile support? Check.

I have a couple more little things I'd like to add and some UI changes I'll no doubt make, but I'd call the quick development of GCD a success. Which is good, since the idea is to get me to do stuff, and quickly.

So what's next?

The big thing is to get Raidomatic, my new guild forums and raid composition tool, released and into use. It's mostly there, but there are little problems to take care of and a couple small features I should add before release. The vital thing will be to get it out there - I can add any other big features (like sorting loot rollers by how proper the item is for their spec) in later revisions.

After that, I want to make a Mac client for GCD. It's not like the site is screaming out for native clients, but I want to learn Cocoa programming and nothing helps learning a new environment more than having a very explicit and attainable goal to reach.

In addition, I've got a family-company web site to work on. Between that and the other couple things I have to do, I should be able to keep myself pretty busy for a while.

If you spend enough time working with XPages, you're eventually going to want to access some SQL data, either because of an integration project or because you just want to. It's pretty well-trodden ground, but, in one of my recent projects, I came up with an approach I rather like.

Now, before I get into it, fair warning: this is not scalable, efficient, or good programming practice. This is for when you just want to do a quick query and get back data in a usable fashion. It doesn't handle paging properly and it can easily stomp all over separation of concerns. But if your needs are simple, it may do the job perfectly.

Basically, the problem I had was this: I want to do a couple quick SQL "select" queries on an XPage, but I got tired of writing out similar "stmt = conn.prepareStatement(...); stmt.setString(...)" stuff over and over. Ideally, the solution would be to abstract it all away, but it was a small page deserving of a small fix, so I wrote myself a function:

SQLTools = {}
SQLTools.fetchQuery = function(query, args) {
args = args == null ? [] : args


var stmt = SQL.getConnection().prepareStatement(query)
for(var i = 0; i < args.length; i++) {
    stmt.setObject(i+1, args[i])
}
var rs = stmt.executeQuery()

var cols = []
var meta = rs.getMetaData()
for(var i = 0; i < meta.getColumnCount(); i++) {
    cols.push({
        name: meta.getColumnName(i+1),
        type: meta.getColumnType(i+1)
    })
}

var result = []
while(rs.next()) {
    var row = {}
    for(var i = 0; i < cols.length; i++) {
        row[cols[i].name] = rs.getObject(cols[i].name)

    }
    result.push(row)
}
return result

}

The actual job of connecting to the SQL DB with the right driver is handled by a Java bean called SQL - the aforementioned link covers that part pretty well. What makes this code different is how easy it makes a quick query with some interleaved parameters and how useful the resultant value is for standard XPage controls. For example, you could do a search like this...

SQLTools.fetchQuery("select firstname,lastname,degree from people where age > ? and lastname like ?", [30, "%son"])

...and you'd get back an array containing column-keyed hashes. Your XPage doesn't have to care about ResultSets or ".getString()"s or anything. You could end up with relatively clean code like:

<xp:repeat var="person">
<xp:this.value><![CDATA[#{javascript:
SQLTools.fetchQuery("select firstname,lastname,degree from people where age > ? and lastname like ?", [30, "%son"])
}]]></xp:this.value>

<xp:div><xp:text value="#{person.firstname}"/> <xp:text value="#{person.lastname}"/>, <xp:text value="#{person.degree}"/></xp:div>
</xp:repeat>

That's probably not a final product for displaying the information, but it gets the point across - it's a pretty clean traversal from "I want to query the database" to having XPages-friendly Server JavaScript objects.

Well, Project One is down: I set up a first draft of my new Getting Crap Done database. I did indeed set it up on Domino, so I didn't have to worry about user authentication, and that helped quite a bit. It's very quick and dirty, using some basic controls and a certain old style I had sitting around:

It really does just what I need: keeps tracks of item names, the date or range (now, short, medium, long), and allows for repeating items, plug a big ol' rich text field for generic notes:

Since it's Domino, multi-user functions were a cinch and it was easy to add in some items for making items available for viewing or editing by others, and those fields also handled showing only your items with no chance of stumbling across anyone else's illicitly.

I also added a feed to my home page to keep it in my face at all times. In later phases, I'll add in stuff like RSS feeds and email reminders. More importantly, though, this should help me hold my own feet to the fire on on the other things I need to get done.

So I think my first project should be a quick little app to keep track of the things I need to do. This is well-trodden ground and I could easily just pick up a free app to do it, but it should provide a good exercise, and I'll get to do it like I want.

Basically, the way I want to do it is pretty similar to the project-tracking database I wrote for work, or at least the sidebar view I made for it. The basic UI is just a list of things to do with short summaries, categorized by their due date, and icon- and color-coded for status and rushness. In a non-work setting, The former could translate to vague timeframes of "now", "soon", "long-term", etc. and the latter could translate to "importance". I'll also have to work in some support for recurring events, like "pay the non-automatic bills." I don't think I'd need all the categorization I have at work - my personal projects are much looser than the client-driven work ones, so maybe just a tag or two would do the job.

Really, the goal is to just get a list of things that I have to do in my face at all times (or, at least, in a place I will actually check regularly, so maybe I'll have it send me email). I've historically had a nasty tendency to let things drift out of mind, but I'm putting an end to it, and I'll make this app reflect that. I'll use my natural aversion to red "past due" text to keep me going.

I'll have to pick a medium. My default lately is XPages, which is my work development environment, but I'm always itching to try something else. Nonetheless, XPages may win out - if nothing else, I don't want to bother writing a user authentication and DB access system or any of the other "structural" elements that would stand in between me and getting it started. The whole point is to make sure I actually get crap done, after all, not spin my wheels with abandoned drafts.

So I think I need a project to work on.

Back during my education, when I had weeks of time on my hands, I had projects going all the time, the most prominent of which was my old blogging site. Aside from that, though, I had lots of little things - server admin stuff like setting up mail access, getting Gaim to work on OS X back when that meant using the non-Apple XFree86 build, and my on-again-off-again relationship with building pseudo-filesystems with MySQL in Java, Objective-C, or Ruby.

Then, I started working and actually doing  things with my time, and my beloved projects have gone by the wayside. For a while, even when I had free time, I'd be too tired and annoyed from work to do much other than play WoW or watch TV. I've still finished a couple small-time projects here and there, like my new home page when I finally got fed up with my ancient My Yahoo home page, my AIM log parser DB, and a little runeword-tracking app for Diablo II. My big project lately, which has been taking longer than it realistically should have, has been the new forums/raid comp utility for my guild. That's finally just about good to go, which means my spare programming time will be free.

So: what's next? A couple candidates come to mine:

• Another blogging platform. I've already done this, but I'd love to take a whack at it in Ruby or another modern language, not PHP. I have to admit, though, that (NIH flareups aside) WordPress is doing a fine job.
• Some just-for-fun apps in Cocoa. I have only a cursory knowledge of Cocoa, and it'd serve me very well to learn how to write Mac and iOS apps.
• Some stuff in Cappuccino. This would have much the same effect as learning Cocoa, but would keep within my usual web-dev domain (which could be either a plus or a minus).
• More Minecraft Server work. This could be fun, but I'm getting pretty tired of looking at Java all day.
• Plugins for Plex. I've recently switched to using my Mac mini in lieu of a proper cable TV subscription, but there are some rough edges. Namely, Plex's YouTube app is pretty feature-light, but XBMC doesn't support Hulu or Netflix. Plex plugins are just Python, though, which is like Ruby if you squint, so maybe I could fix it myself.
• More WoW stuff. I'm not sure what specifically I'd do next, but there are plenty of places I can improve the forums and raid comp tool.

The important thing, though, is that, now that I've written it down in a public forum, I'll have to do something. All I have to do is decide what, and the rest is an implementation detail.

A couple months back, I started getting into the wonderful game Minecraft, which I heartily recommend. Since I really just wanted to play the multiplayer one, I decided to try setting up my own server. The actual setup is very easy - drop the minecraft_server.jar file from their download page somewhere on your computer and launch it. The tough part was making sure it'd do real server stuff like, primarily, launching automatically at startup.

I looked around a bit for ways to create normal Windows services ro run a Java app, but the process I found looked painful. Then, I realized that I already HAVE a server capable of running Java-based tasks with aplomb - Domino. After not a lot of searching, I found the perfect starting point: http://nsftools.com/tips/JavaAddinTest.java.

Now, I had a couple choices for how I could implement this: I could extract the JAR and figure out how to run the server from the raw classes, essentially writing my own server; I could include the JAR in my project and run the main(...) method of the server class; or I could go the "easy" route and just run the Java task externally. Though the first two would be interesting and are potentially something I'll look into down the line, I went with the final option and it's been serving me pretty well.

Basically, the Java task, when loaded, does a system call to run java.exe to load the server and attaches a couple stream readers to that to read in the standard and error output from the task (error-out from Minecraft appears to include tons of non-error information).

That was sufficient to get it up and running, but I decided to be a little tricker. I set up a database to house reports and config parameters (yes, yes, I know you're not supposed to put database file paths in code, but meh). That way, I can keep a log of all the messages in a searchable format, keep track of the users that have logged in and their last login times, and store parameters like the memory sizes and Java and JAR paths without having to re-edit the server task code for every change.

It's been working out pretty well! I've been working on an XPages UI along side it for viewing the information and sending along server messages, and I'll eventually put in an editor for the .properties file the server uses for its startup preferences.

Here's the (likely bug-ridden) code I'm using:

MinecraftServer.java