the corner office

This blog has always trodden a bit of a tenuous path between being a tech blog and a personal blog, and despite it being around for 6 years I don't know if I've ever gotten the mix right. These days I definitely don't. I don't write as much technical stuff as I'd like because I'm mindful of scaring off or boring friends and family who regularly (or occasionally) pop by. Ditto in the other direction.

What I really want is one thing which is personal and non-technical and conversational, and then something else where I can indulge in uninhibited geekery, and be as free-form and self-indulgent as I like.

So I think it's time for me to split things up.

I'm not sure how yet. The Corner Office will either be a tech blog with another personal diary-style blog somewhere else, or else this'll be the diary and a new tech blog started up elsewhere. Perhaps I'll tweak my link blog, which has occasionally threated to become a tech blog anyway.

Watch this space.

Update: here it is.

My blog was down for a bit this weekend... I finally got around to getting the VM it runs on reinstalled. From unsupported old sitting-duck version of Debian to Ubuntu latest, I'm hoping that'll see me done on the system maintenance front for another year or two. I've realised I'm getting too old to get my jollies from fiddling with config files.

So I was sitting around on the weekend, taking a break from doing anything important, and I thought to myself 'hey, I needs me a link blog'. So I fired up a MySQL client and ran some scripts and copied a .war file and tweaked some XML, and hey presto, I had a link blog.

Basically, I just wanted a place to dump all the links I pick up as I'm doing my daily thing, or researching particular topics. By publishing the links, I can add to the list wherever I am, linkees get some search engine luvvins and I can use search engines to go back and search through my own link collection when I need to. It's all good.

I've always battled a bit with this blog, because it's always been a bit schitzophrenic - technical, political, and personal. The link blog is also a hodge-podge, but it's really a tool for me, with no real designs of being useful to anyone else. Nonetheless, you might find it interesting to follow, just as likely you won't. I'm just writing this waffle 'cause it seems a bit silly not to mention that it's there.

(PS setting up a fresh instance of my blog app meant I uncovered a bug or two, and I've placed an updated version of the tco-blog app on my website.)

And so it came to pass that I finally decided that enough tinkering was enough, made a few last tweaks to the meagre documentation, and rolled the project folders into a zip file and put it up on my server. My goal was to get this baby done before moving on to the next thing, and it's done: tco-blog is as good-enough ready as it'll ever be, and downloadable.

If you're vaguely interested in taking a peek at this blog's innards, now you can do it. Enjoy.

Anyone who reads my blog via Bloglines caught me with m'trousers down last night. I don't feel right about editing posts long after the fact, no matter how bad or cringe-worthy they are, but I do sometimes tweak posts as I do my 'final' preview on the live post. I figure that if nobody's had a chance to read the post yet, no harm done. Of course...

Last night I decided to tweak my CAPS Lock post, but instead of doing it the proper way, I just selected the edit page in my browser history and re-published. Only then did I realise that I'd created a brand new entry instead of editing the existing one. As luck would have it, Bloglines read my RSS feed while I was hurriedly faffing around in mysql trying to delete the extra post. My editorial process laid bare to the world. The shame!

Ironically, the feature I'd been adding to the blog admin app last night was... yeeess: deleting and/or retiring entries. Apart from little bugger-ups like last night, I've never needed to remove posts from the blog, so it wasn't a feature I'd ever missed, which is why I'd forgotten about it. Once I've deployed the new version to this server, it'll probably be yonks before I need it again. But I'll sleep soundly knowing that next time I'll beat Bloglines to the draw.

Having posted photies the last few days, I realised that the way I handled file serving, meant the app was re-serving the files each time, which clearly wasn't optimal, nooosirree. This prompted a tweak to the app and a visit to HttpServlet's getLastModified() method. I don't think this method gets used too often in web apps because there's so little static content in 'em, but it's exactly what's needed when you want to send an HTTP 304 / Not Modified response to a client who's sent you a If-modified-since header. I'd never come across the method before, hadn't even realised that servlets could handle this so easily.

You just override getLastModified() (which gets called before service()) and return the resource's age if you have it, and the web container takes care of the comparison with the client's header, and sending the proper response back. If the resource hasn't changed, service() doesn't get called. Nifty.

Now to be virtuous I ought to getLastModified-rinse some of the other static resources. I could go ahead and even handle this for plinks and summary pages, since I know when last anything got updated, and for a quiet site like mine, it might be a good idea. I think I might be fscking the cat if I did that, though.

Cool. I was looking at the blog app's version history, and the last version I'd uploaded to this server was from April last year. So I'm rather pleased that the upgrade went OK: the blog should look no different to what it did half an hour ago, but it's served by the new version, which means it's a huuuge new chunk of code and hanging off of a brand new config system and seems to have made its way through table changes, the lot, without breaking (much).

I picked up a few niggles that need attending to, but they won't take long. Thereafter, I'll get to see how easy this thing is to set up from scratch, because Ronwen wants her own blog, dammit, and I'd best get cracking. She's been waiting patiently for quite some time, poor lass. Once Ronwen's blog is up and running, it'll be time to sling together a download page, sling up some zip files, and wash my hands of this whole blog app thing for a very long time.

The weekend wasn't as studious as it should have been, and the coming week will be hectic and guilt-ridden as I cram for my next exam. On the upside, the blog app's TODO list emptied out, and there's very little left to do.

Something I've been giving some thought to, is a license for my little project. I'm very conscious of how pretentious it might sound... 'oh, I'm licensing my blog app, y'know...' - it suggests that I have greater ambitions for my piss-willy web app than the piss-willy web app merits.

That's not what it's about though... it's just that I do believe that it's prudent and helpful for shared code to come with some indication of how it may be used. Given that the blog app is a fair-sized chunk of code, I think that's even more important. I could just make it all public domain, but I like the idea, even if it's a purely symbolic gesture, of associating the code with some form of open-source license.

I decided that if I'm going to do that, it's got to be the GPL. So I figured all I'd need to do is what this GNU document advises: put a blurb at the top of each source file, and a copy of the license in the project's root directory.

I thought that would be easy enough, but it's easy to get bogged down in pedantry, and I am painfully prone to getting bogged down by pedantry. For example, the page I linked to gives two sample blurbs. The first says 'This program is free software' and is meant for single-source-file programs (not that common, anymore) and the second form, which says 'This file is part of MyProject...' is recommended for multi-file programs.

I've noticed after looking around sourceforge.net and koders.com, that most people just use the single-file version, which says 'this program'. It's not what the FSF says you should do, dammit, but I can understand why it's done. But what about a web app? That's hardly a program? Also, what about a re-usable utility library that doesn't really have a name of its own? Isn't it just lazy to bang a 'this program' notice into something that's not even part of a program? It seems wrong. OTOH, isn't re-wording the recommended GPL blurb to suit one's requirements just a bit fucking OTT? It also feels wrong (and sad) to actually be worrying about this stuff, but still.

I think perhaps it's time to set the blog project aside until exams are over...

In between all the studying and being a doting husband, I still sneak away now and then and tinker on the blog app. At first I'd tackle something on the TODO list and as I got stuck in, I'd end up adding another 5 items that needed looking at. Thankfully the list has slowly been whittled down to LATERs and DONEs.

I've spent quite a bit of time generalising the app. The blog wasn't initially intended for anything other than The Corner Office, but soon Ronwen was asking about setting up her own blog, and I wanted to keep a quick-and-dirty private diary / tech scribble blog. Some parts, like headings and link bars and the like were easy to do, but others got a bit tricky: the dynamic CSS styles functionality was partly hard-coded, ditto for RSS feeds mapped to blog categories and so on, and these needed some fancy footwork to be fully configurable.

Most of that is done. I've been going through a lot of the old code (the app was initially my learn-JSP project, and somewhat uh, dated), and cleaning up the bits that are too ugly for posterity. One problem I picked up yesterday, is how the blog handles some images. Most dynamic files and images are stored as BLOBs in the back-end database, but the front-end logos and whatnot were actual images in the web directory in the .war file. This made good sense performance-wise, because every page hit requiring a BLOB to be hauled out of the back-end database is not what I'd call desirable. Problem is, if the app is going to be virtuously generalised, then having to personalise the app by shovelling different images into the .war file isn't the way to go either.

I see two possible solutions. The first is to push more images back into the database, but cache the most used ones in memory. For small things like a logo or background images, which are going to be required for nearly every page hit, this is probably the best approach. The second alternative is to dump the images to a temp directory, and then stream the files from there. I think both solutions are better than BLOB-streaming, but I'm starting with the former approach for now, and in particular, want to be able to specify which images / files are cached or not. I'll keep this extensible so dumping to the file system is an option, eventually, too (more thoughts on that another time). So that's the next chunk of work to do.

Into 2007, just like that. Quite a bit has changed since my 2006 New Year entry. Living in another country, married, and expecting our first child. It's been a crazy ride, but I think I can safely say that 2006 has been a Good Year.

For us, 2007 is going to be a year of opportunity and new experiences. In whatever way, I hope yours is the same... Happy New Year!