the corner office

August is drawing to a close, and the end of August was the deadline I had given myself for tinkering with Eclipse RCP. It's taken longer than I'd expected - being a new parent means coming to terms with a little less 'me-time' - but it has started coming together. I'm by no means well-versed, but I find myself feeling a lot less confused and frustrated than I was back in April and May and June. So I'm not quite sure whether I'll be packing it in just yet.

My motivation for getting to grips with Eclipse was mainly due to me not wanting to resort to web development every time I wanted to whip up a new application at home. Swing was an alternative, but since Eclipse has been my primary IDE for a good few years now, I figured it'd be quite useful to actually get under the hood a bit. My initial goal had been to get to grips with the basics of Eclipse RCP development, finish off one application which I could bang up on my site as a nice 'deliverable' and then move on to something else.

The main pet project I've been tinkering on has been a simple budgeting application, as I've mentioned before. While it's turning out to be pretty useful (living with another currency took some adjusting), and I keep adding new features, it's fairly specific to our own needs and nowhere near being in any state for sharing. Chances are, it never will be, and I'm not sure that the effort required to make it usable to anyone else is worthwhile. As for 'deliverables', I have been jotting down a few notes about how to go about doing things in an ever-growing page [link since gone] on this site, and a fair number of interesting things make it onto my link blog. That will have to do.

Next: reflections on Eclipse RCP development.

I haven't run into it too often in the past, because I'm normally not too big on nested classes, but since I've been playing with Eclipse RCP and doing GUI stuff, it comes up all the time. I'm talking about the Eclipse compiler warning that gives you this:

Read access to enclosing field Foo.bar is emulated by a synthetic accessor method. Increasing its visibility will improve your performance

It happens when you're accessing a private instance variable of an outer class, from within a nested class. Oer. Performance affecting... can't have that. I'm firmly in the 'fix all compiler warnings' camp, and if my Problems view isn't empty, warnings or otherwise, then I'm not happy. I wasn't really liking the sorts of workarounds needed to silence the warning though, and I wondered how bad it could be, so I decided to do some homework.

There are a great many references to the problem, but the two most enlightening discussions are one from the ADVANCED-JAVA mailing list archives, and one from the Eclipse jdt-dev newsgroup.

Since the referenced variable is actually private, and since nested classes are actually compiled to be separate classes, there's no way for the nested class to directly access the variable. Eclipse is warning you that the compiler has to work around the visibility problem by creating a synthetic accessor (ie. add a getter method) to the outer class, which the nested class then calls.

... and that's all it is. An extra method call is needed to reference the instance variable, and since method calls are more expensive than directly accessing a field, not having the accessor method will 'improve your performance'. OK technically true, but this isn't 1970 anymore, so a method call is somewhat unlikely to be high on your list of things to worry about when it comes to performance. In other words, pffffff.

There is one other potential issue: this special accessor method, albeit obscurely named, means that the private variable is no longer truly private. Yet again, in most, as in most to the power of a bazillion cases, it's simply not an issue.

In other words, the 'synthetic accessor' warning is now one of the handful of Eclipse compiler warnings that I disable and don't feel guilty about.

This is one of those 'I fixed a problem but I'll be damned if I can do it again' posts. I wanted to get my favouritist monospaced font for Linux, Schumacher Clean. It's installed by default on Ubuntu, to a bunch of /usr/share/fonts/X11/misc/clR*.pcf.gz files. Linux and X and fonts is a world I've always remained gleefully ignorant of, probably to my own detriment a great many times. Perhaps reading another article or paragraph would lead me to enlightenment, but alternatively, it could just be that X11 font management is a confusing glob of software that hangs together by faith and a bit of wizardry by the 3 people on this planet who really grok it all. Who knows? Anyway, I have no idea what PCF fonts are exactly, but I gather they're basically just bitmap fonts, and Ubuntu, by default, seems to not list these bitmap fonts in the font dialog.

After a bit of digging around, it seems that running dpkg-reconfigure fontconfig does some magic stuff and enables bitmap fonts. I say 'it seems' because I did a few other obscure things along the way, and one or all of them might have played a wee part in the solution, too. Next time I lose my fonts, though, that's the one I'm trying first. I might even bring myself to read the man page.

Other commands which I'll read up on when I'm bored one day:

fc-cache -f -v
dpkg-reconfigure fontconfig-config

The Ubuntu FontInstallHowto wiki page is somewhat enlightening.

Aug 1, 2007 12:08:15 AM org.apache.catalina.startup.Catalina start
INFO: Server startup in 666 ms

Server of the beast!

I realised last week that if I didn't get cracking, the day's going to come when I'll have spent an entire year with Windows XP as my home OS. Can't have that, what would all the cool kids say, so I decided enough is enough and I'm making a concerted effort to boot into Linux and stay there. The problem was that after shutting down my beloved Gentoo box last year and moving over here, it took so damned long to get everything set up in Windows on the new laptop, that I'm loath to have to start all over again in Linux. I can copy and paste a lot of config stuff from Windows and old Gentoo backups, but there's still a lot of schlep involved. But it had to be done. Frustrations aside, it's nice to be back.

Anyway, the change-over is also chance to do some housekeeping. Tomcat 6 got released a few months ago, so it's upgrade time. It implements the Servlet 2.5 and JSP 2.1 specs. Guess I should read the what's new articles (servlet, jsp).

... and I still haven't had a good look at what's new in Java 6.

It's not often you get to have nice arguments about things. I saw Laurence at Commentary refer to a post by Ian Gilfillan responding to some of Laurence's posts on environmental issues. Much to my surprise, I saw my own name mentioned in Ian's post.

Ian refers to a comment I'd made on an earlier Commentary post, which started out with me saying "I have no time for Luddite environmentalists and I don't buy into the peak oil thing." Ian regards my comments as "utterly idiotic". Well now.

First, a Luddite in a modern sense, is someone opposed to technological change. You know, someone who's anti-technology. You don't have to look too hard to find people who regard abandoning our modern way of life and returning to simpler, if not all-out subsistence lifestyles as a way of dealing with the environmental issues our planet faces, as a good thing. It's pretty hard not to see people espousing these sorts of views on every second BBC environment-related segment, which is yet another reason why I find my mood inversely proportional to the amount of time I spend watching BBC News.

Ian reckons he doesn't know a single person who has an anti-technology approach to environmentalism. Well, jolly good for Ian and his hip mates, but if they're not Luddite environmentalists then I wasn't referring to them. Perhaps the term Luddite doesn't quite apply to Ian's admirable decision to live within walking distance of his job, or his espousal of the 'stop what you're doing' principle. I still think his beliefs are a little flawed, not because I disagree with the principles, but because I disagree with the means by which he believes those principles should be met. More below.

Secondly, Ian doesn't like the fact that I don't buy into the Peak Oil thing, by which I mean the rather popular notion in some circles of an economic and social apocalypse when we run out of oil (and not the notion that oil supplies aren't going to one day run out. I understand the meaning of 'finite'). Laurence was addressing this issue in his post and he said everything far better than I could.

Never thought not buying into the peak oil thing would be so controversial, but I guess Ian sees me as some puppet of the Conservative Corporatist Establishment or something, which is kinda odd given what I said in the rest of my original comment:

At the same time, the thing I don't like about the other side of the spectrum is that the economics of scarcity and finite resources should spark natural, economically efficient price rises and encourage the investment needed in alternative technologies, and I have a sense that a lot of people in high places will gladly pander to vested interests instead of allowing the pain that's needed to really drive the move to alternatives.

Be it finite oil supplies or any other aspect of the world's environmental woes, I think the biggest problem is not aligning the true costs of our environmental footprint with our lifestyles. In a word: the problem is externalities. Hypothetically and empirically speaking, when transactions between people on this planet more accurately reflect the true cost of the environmental impact of those transactions, then you soon find three things happening:

• People choosing to limit their consumption, because certain polluting activities are too expensive.
• People choosing more energy-efficient solutions to common problems, all other things being equal.
• Higher costs driving innovation and uptake of new technologies which are more efficient and less pollutive.

How you mitigate externalities is a separate discussion, and I sure don't have the answers, but if you don't start with the premise that we're not going to effectively solve environmental issues if people are being exhorted to do things which are out of line with what they can afford and not afford to do in their daily lives, then a 'stop consuming or you're gonna die' approach is about as effective and persuasive as 'stop sinning or you're going to hell'.

Ian might not like my idiotic comments, but I suspect that many of our views are not that far apart. Not that I care if they aren't. What it really boils down to Ian's insinuation that I'm some conservative anti-environmentalist authoritarian reactionary, and that's ridiculous, although having read his blog for a while and having crossed subcultural paths in another lifetime a long long time ago, I can see why he'd think that based on what I said. Regardless, he's wrong.

I never once said that there weren't real environmental issues that need resolving, but I don't for one second believe that unrealistic exhortations to austerity or externality-absorbing populist politicians trying to suck up to voters are the solution. My views are decidedly classic liberal, libertarian, call 'em what you like, and I simply don't believe that things work just because politicians or moralists say they should.

PS. I think terraforming other planets is a ridiculous idea, too.

The water level has risen a bit. This is the Boathouse next to the Wallingford bridge:

Again, the lower level was almost permanently under water in winter. Not this badly, though. Still, these aren't the worst floods in the town's history.

That mark in the middle of the picture is the floodline from the town's worst floods, in 1894.

Of all the interesting things I'd thought we'd experience in Oxfordshire, flooding wasn't one of them. Ronwen popped down to the river this evening to take some pictures.

We're cheating a bit, because to be fair, the Thames like this is a normal sight during winter. Wallingford hasn't really been affected by the floods, and is unlikely to be. We're quite high above the river at any rate, and not particularly worried. Elsewhere though, it's rather soggy.

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 (Update: which eventually turned into my tech 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 [link long gone] app on my website.)

I just got bitten by a silly thing: according to the J2EE spec, HttpServletRequest.getCookies() returns an array of cookies, or null if no cookies were sent with the request.

Why return null? It forces client code to explicitly check for null, while boiler plate cookie extraction code requires you to iterate through the list of cookies anyway. You could just as easily communicate 'no cookies' with an empty array, and it results in less crashable code.

True, common convention is to return null when you're unable to find an object that's supposed to be returned by a method - that's an understood and sensible convention. I don't think it follows that the same should be done when returning collections of objects. My preference is almost always to return an empty collection, as opposed to returning null. Why? You can still explicitly check for the existence of returned objects with a length == 0 or size() == 0 check, and iteration generally drops right though, with no NPEs and no NPE-avoidance code required.

The only argument against doing that might be performance - saving the creation of an object when no results were found. Apart from extreme cases - where the reasoning should be documented - empty results aren't the normal case and performance gains are likely to be infinitessimal, if they exist at all.

We've been all touristy the past few weeks. Last weekend, the Henley Regatta, and this weekend, Stonehenge.

The Regatta was an excuse to walk for miles to find a picnic spot under a tree with a lovely view of the booze tents and all the Beautiful People dolled up to the nines. Most people in the 00's trying to look traditionally spiffy don't really manage to pull it off. Maybe looking traditionally spiffy needs trousers and blazers and summer dresses made by tailors or movie costume designers, not M&S or Gap.

Stonehenge was... more inspiring in the documentaries. I mean, it's amazing, seeing this huge structure, and you wonder how the hell, and why the hell, but in the documentaries, it's always filmed at sunrise with atmosphere and dew on the grass and nobody else around. In real life, Stonehenge is an interesting prehistoric site that looks like a movie set, but nicely cordoned off with rope walkways and a million tourists all bumping into each other because they're engrossed listening to the narration on the little radio player jobbies they hand out at the entrance. It is an incredible structure though, and set in a beautiful piece of countryside, and well worth seeing.