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

This post over at Codestore hit me as one of those "oh huh... why aren't I doing that?" things. My current computer setup is blessedly homogenous, consisting of a handful of Macs. Since pretty much everything on the Mac, including Chrome, stores saved passwords in the Keychain, which is then synced across my computers via iTools .Mac MobileMe, I don't even need to use 1Password to assist me (though I have a license around somewhere). Keychain Access has a nice random-password generator when you go to change the Keychain password, and I've also found the results of @HashPassword(@Unique) in Formula language to be quite suitable.

XPages are a tough nut to crack. Thanks to IBM's apparent disinterest in people using their software (which is a big topic in itself), it's an uphill battle to figure out what to do with them. For simple applications, they're overkill - loading a Java framework stack that seems to go on for miles has some noticeable performance penalties. But for larger applications, how are you supposed to write them? The main tutorials I've run across usually involve replicating basic form/view functionality or porting an example Notes application over. That's great, but I already know how to make apps with forms and views.

A couple sources, such as the excellent Mindoo blog and the well-produced Notes in 9 give hints at the "other" way to do XPages development, the way involving pure Java classes and scoped beans. From what I've gathered in my development, this is the "Right" way to do it, but, unfortunately, those blog posts and videos are about the extent of what I've found. I imagine that I could learn more if I hired consultants or attended LUGs in various parts of the world, but those seem like pretty ridiculous solutions to the problem.

Since XPages are an application of JSF, I could run off in that direction, but there are severe problems with that plan, not the least of which is that the XPage tag library is very distinct from other JSF applications and so reading any of those books would be analogous to learning MFC by reading a book about Qt. Same language and same general concepts, sure, but it's not the same environment.

This ambiguity manifests in practical problems. I'm writing a forum at the moment, and I'm wondering what the best way to do it is. On a topic page, for example, I have a topic ID and I want to display a paginated view of the posts in that topic. The straightforward and functional way to do it is to use a <xp:dominoView/> data source with a categoryFilter and feed that to a <xp:repeat/> control. That works and initially is pretty clean - showing data from a view is easy. But then I want to show the author's preferred alias instead of their username, so I put in a custom control with code to look that up. Oh, and some code to determine and show the author's current avatar image. And some code to determine if the current user can edit or delete the post. And some code to look for previous versions of the post to show an edit history. And some code to add or remove the topic from the list of the user's favorite topics. And so on and so on.

None of that code is particularly crazy, and I've moved a lot of it into custom controls to keep it nice and clean, but, at this point, I've got all kinds of business logic performing actions and converting <xp:dominoView>s and <xp:dominoDocument/>s into topic lists and posts. The actual XPage itself is supposed to be the View part of a MVC setup, right? Instead, now I have this View/Controller hybrid with a dash of Model when I have to make a secondary data source to get the rich text of the post. That can't be right. Instead, I should probably write some Java classes called Topic, Post, and Author and get all that crap out of the XPage.

And therein lies the problem. I started clean with a fancy new framework, but I've been largely left to my own devices when it comes to figuring out how to use it. Plus, I've not even totally convinced that Java-ifying everything is actually the right way. Once I step away from the pre-provided Data Sources, I'm suddenly on the hook for handling efficient pagination and cacheing myself, plus "smaller" things like getting the rich text data out of the documents and to the web browser. Should I try to read the MIME entity in Java? Should I punt and provide a .getDocument() method on the Post to let the <xp:dominoDocument/> source do the work? It's not clear. Should I read in all of the pertinent data from the document as soon as I instantiate a Post, or should I leave the Document object sitting around and only pull it in on-demand? I guess I'll have to try both and find out if one is much slower.

Eventually, I expect to find a smooth way of accomplishing everything I want to do and all this will be like second nature. But that "eventually" is quite a while, and a far cry from more opinionated software like Rails (which is written in a better language, to boot). Maybe Mastering XPages will help, but it seems I'll have to content myself with muddling through until at least the end of January.

XPages are a huge divergence from classic Notes development. Aside from a few token UI controls such as View Panels and some support for Domino data on the back end, they may as well be completely unrelated to Notes.

Now, while IBM didn't take many strides to make the transition from old-style to new-style development easy, they DID make sure to keep the most important part of the Notes experience intact: horrifyingly frustrating bugs! Case in point:

All I wanted to do was delete the attribute value, but every time I did, the XML editor decided to eat a couple extra lines of code. The "select all" effect you see is from hitting ctrl-Z, which is supposed to only select the text that was un-deleted, but, since the editor has no idea what's going on, it throws up its hands and selects all kinds of crap.

Between this kind of thing and all the random crashes, it's comforting to know it's still the same level of Lotus quality we've come to expect.