the corner office

Leo has arrived. Cutest little thing, ever.

The Eclipse tinkering has continued, although not without its frustrations, and not just because life is a pain with dial-up and minimal Google time (no ADSL until next week, pfff). I've focused on simple views and interacting with them, and things come together, bit by bit.

As I'd said, there are two things to get one's head around: how SWT works, and the Way of the Plugin. The SWT stuff isn't bad, it's just another API to learn. How to create a table, how to create columns, what properties they have and how you interact with them. It's a bit of a change moving from the web, and the Java Way of eschewing visual editors isn't always pain-free. I'm normally far happier wading through Java than HTML or JavaScript, but I must say that the usual Java paradigm of constructing UIs by code gets a bit frustrating. I know I'm still green enough to not have a fully-informed opinion yet, though.

The plugin malarkey has been the real headache. I suppose it boils down to sacrificing some dev-time convenience for run-time architectural robustness, or something. That's what I tell myself. At present I find myself spending too much time resolving classpath and NoClassDefFoundErrors, and not enough time writing code that does stuff. I hope it gets easier once I'm more comfortable with everything, but I can't help but feel that the tools should be able to take away even more of the drudgery.

What is nice about coding up applications, is that the plugin libraries are associated with their source code, and so it's easy to step into the code, and on the higher levels at least, peek under Eclipse's hood, and actually understand what's going on.

Between the moving and packing/unpacking, I've managed to squeeze in a very wee bit of Eclipse tinkering. As I mentioned before, I saw two things to get my head around: SWT/JFace development, and the Way of the Plugin. I figured I'd be as dumb as possible about plugins to start off with, and focus on putting together GUIs.

That wasn't so easy. I could have sidestepped the plugin/RCP thing completely and just fired up some windows from a main() method. I didn't want to do that, but I was wrong in thinking that you don't need to give thought to plugin management from the get-go.

The first problem I ran into was trying to use my tco.util projects as dependencies like I normally do for standalone and web apps. No go. You can refer to another project at compile time, but not at run time. I read a forum post explaining that I'd need to turn my depended-upon projects into plugin projects of their own, and then specify the dependencies in my plugin.xml.

Not happy with that idea... much like my gripes about Eclipse WTP wanting to stomp over utility projects, I don't want to have to plugin-ify utility projects which aren't going to be used only in a plugin environment. The alternative is to roll the util projects into separate jar files. You then have two choices: you can either include the jar file directly into your plugin, in the usual lib/ directory style, or else you can create a separate plugin which uses the jar file.

If you include the jar file in a lib directory, then presumably it loads within the plugin's own classloader. You need to explicitly add the jar file to the classpath entry on the plugin.xml's 'Runtime' tab. Unfortunately, you can only specify locations within the current project directory.

Alternatively, if you want to use the jar as a separate plugin, then Eclipse has a tool which allows you to create a plugin project from a jar file.

Either way is a pain, because rolling these jar files is a chore. It is possible to hook in custom Ant scripts which do it automatically when code changes, but that's not my idea of pretty, and it's frustrating when I just want to crank out something easy to play around with.

I understand why plugins needs to so rigidly separate: that's the whole point of the design, but for development and testing it would be nice to have a third way: specify a POJO-esque project as a dependency on a project's build path, as normal, and allow the IDE to either virtually or physically include the depended-upon project's class files and exported jar files in the current project's class path.

We got our flat on a short lease, not sure if we'd want to - or be able to - stay in this neck of the woods. We're moving this coming week, and things are getting a little rushed. Thankfully our move entails lugging stuff down one stair case and up another... yep, we couldn't keep this flat for longer, but we like where we are, so we're moving to another flat in the same block. Even a simple move like this entails a lot of missioning, and we'll be rather glad to get settled in the new flat, and just chill the hell out until Junior arrives.

The impending move upped the pace of the book cataloguing. I have a few more boxes to do, but I'm nearly done. The catalogue spreadsheet is currently sitting at 989 books, in 47 boxes. Much to Ronwen and everyone else's amusement (or pity or exasperation, I'm not sure which), I decided to weigh each box on the bathroom scales before I sealed it. I don't know why people think I'm nuts - if you're going to put boxes in storage, piled 4 or 5 high, it makes sense to have the 20kg boxes at the bottom and the 5kg ones at the top. The easiest way to decide which boxes go where is to know how much each box weighs. Plus it really gets the accountant in me all juiced up.

Anyway. I can report that these 47 boxes weigh over 450 kgs. The books still to be packed and those that won't be packed will come close to another 50kgs. So when people say 'gee, you must have a ton of books', I can honestly say 'no, only half a ton.'

What's up with some people and spitting? You have to keep your eyes down when walking around town; the pavements are peppered with oysters. I was walking to work this morning and a dude with his chunky jewellery and tracksuit hocked up this beast right in the doorway to a shop. I wasn't the only person who saw him do it, and he just didn't care. As always, part of me wanted to chirp the dude, but the chickenshit part of me reckoned it was best not to.

Oh well. I remember in my cycling days that it was a rite of passage to master the high-velocity, high-pressure nose blow. Sometimes you couldn't afford to rummage around in your jersey pocket to find a handkerchief, so onto the country road it went. Finger blocking one nostril, and let rip down the other. If you did it right, it was poetry in motion. If you did it wrong, people behind you in the pack would get mighty antsy.

At least people don't go around blasting snot onto the streets. Small mercies.

What's the big deal about Eclipse? Plugins and GUI.

Plugins first. What's the big deal about plugins? I don't fully have my head around it, but it's about modularity. When I first started doing Java development, I was a complete stranger to the concept of introspection. The idea that you could write code that not only did stuff, but loaded and changed and knew how to understand the code itself. Cool. The idea that you could write a bit of XML and a program could make sense of that XML and load up and execute separate chunks of code, code that wasn't compiled into the application up-front, code that might only be written months or years later. Cooool. That's how J2EE applications work, and it's not arcane knowledge, but it's still pretty damned powerful.

Each Eclipse plugin is just a piece of code that gets pointed to by a bit of XML, and there are lots of rules which say how a plugin should play with other plugins. The interface between a plugin and its parent code is called an extension point. The parent knows how to talk to an interface, and if the plugin implements the interface, then the parent can load the plugin code, and call methods on that interface. The head-bending bit is that not only can you build an app horizontally by having lots of plugins working side by side, but you can modularise vertically, too. A plugin, or module, or bundle in OSGI terminology, can define its own extension points, and other plugins can then hook into those extension points, and they can in turn publish extension points, which other plugins talk to, and so on...

So basically, Eclipse takes the concept of modularity and redlines it. It's about writing small bits of code, wrapping them up as plugins, and then stringing them all together using (mostly) XML configuration files. The Eclipse platform is, at its core, a simple kernel-like runtime which reads these config files and is smart enough to load up the bits of code, as and when (and if) they're needed.

The second unique thing about Eclipse is its GUI. Java's standard GUI toolkits, the primitive AWT and the newer Swing, are meant to be truly cross-platform toolkits. The intended upside was that the Java GUIs would always look the same, regardless of platform, and the unexpected downside was that Java GUIs tended to look a little, well... crap. The toolkit might be nice in its own right, but never quite fits in, because it doesn't feel truly "native". Eclipse's answer to AWT is SWT. Unlike AWT, which tries to be truly cross-platform, SWT tries to look exactly like the OS it's running on. It provides a standard API, much like AWT, but the API is just a thin layer over the underlying platform's GUI toolkit. JFace is a higher-level extension to SWT, much like Swing is a higher-level extension to AWT.

Starting to learn how to do Eclipse development means getting comfortable with two new things. First, resisting the temptation to hard-wire your entire application together; getting to grips with the Way of the Plugin instead, and secondly, mastering a new GUI toolkit.

Right. Eclipse. I'm not sure if the Eve market app is really such a good candidate (but I'm letting the idea stew), but there a few other desktop apps I could tinker on. Eclipse RCP, here I come!

I've been dipping my toes in the water the past few weeks, but again, not getting far. The reason is that I'll sit down, starting reading the introductory help docs, and after a page or two I'm starting to wonder about what obscure bands I could find on Youtube. The Eclipse help documents are comprehensive, but they make for dry reading. Playing with real code is a far better way to learn, and so that's what I've started doing now. As with any new API or platform, it's frustrating when you don't know what you're doing and you're battling to see the wood for the trees and obscure classes. I'll get there, but it's all still a bit confusing.

I'd said that I would talk about my progress, and even though I don't have much to report right now, it will be an interesting milestone to jot down some notes about where I am now, and what I know and don't know. That'll come tomorrow.

A nice Easter weekend. We spent a lot of it visiting and eating. That was fun. We drove around the local countryside a bit, and that too was fun. My poor beleaguered missus got roped into helping me catalogue our books before the freshly re-packed boxes get sealed. I heave, number and rifle through boxes and reminisce, she types. Ronwen might not agree, but it's a great trip down memory lane going through your books and remembering who and where they're from, when you read them, and so on. We're only a fifth of the way through the boxes, so I may change my mind towards the end, but for now, it too has been fun.

I also spent a lot of it playing computer games. That was also fun. As I mentioned, I've had a renewed interest in Eve Online. I dusted off my old Eve market analysis app this weekend, thinking that I'd spend some time extending it. It's just too much like spaghetti, and designing it as a fancy web app is just a pain. Is this perhaps a candidate to play around with an Eclipse RCP app? Even if it isn't, I think it would be an interesting exercise to whip up a little someting and get a measure of how different it is.

I've been packing books for the most, this week, and the few spare moments haven't been spent doing anything productive, either. I revisited Eve Online after a long hiatus, and a colleague at work introduced me to the Lord of the Rings Online beta. Now I have a long weekend to try catch up the sleep I've lost the past week.

Apparently it's a bit pawsh to go shopping at Waitrose, so I'd best point out that I wasn't name-dropping in my book post from the weekend. Apart from the fact that our dorpie only has a Waitrose and it's on the way to the bus stop, there's another reason why I can't go shopping for resealable plastic bags at the ornery-folks supermarkets. I'd bought a box or two of plastic bags 2 weeks ago at the nearest Sainsburys in Oxford, but as luck would have it, this past week has seen Sainsburys move from good old fashioned outlive-the-cockroaches polythene plastic bags to the degradable type, which is no good for storage. I've now visited three Sainsburys between here and Oxford, and they're all starting to stock degradable plastics. Just my luck. So Waitrose it is.

At the risk of slipping into real resealable plastic bag arcana, it's frustrating as hell that in supermarkets, you basically have two options. Crappy bags made by a crowd called Baco and the supermarket's home brand. Dear American globalist corporate imperialist overlords, please bring your wonderful Ziploc goodness to our supermarkets. Pretty please.

Something I noticed is that Sainsburys and Waitrose obviously have the same producer in China: the labels and blurbs on the bags are exactly the same. The only difference is that Waitrose bags cost about 30% more size-for-size and their large bags are a bit bigger than their Sainsburys counterparts. Which probably means that it's only a matter of time before Waitrose moves to degradable bags as well.

Environmentalists. The whole of the North American and Asian continents will be sinking into the rising oceans under piles of rubbish and black ooze and sludge, but the UK will still have hap-hap-happy landfills. Lucky for us!