I won't be able to make it to OLS so I'm trying to give my ticket away. Interested parties should drop me a line at pvg at triptonite.com. Just to clarify, I'm not expecting payment, proof of worthiness, etc - simply trying to find someone who is definitely interested and can make it there, first come, first etc, etc, you get the idea.

-pvg

[A more verbose, pretentious 'me too, I think' on graydon's sentiment]

If you write software (be it free, proprietary, good, bad, useful or utterly pointless), why do you do it? Do you do it to pay the rent, to get rich, to make the world a better place, to give something of utility to others, to gain the respect and recognition of your peers, to be virtuous? Surely some or all of these are important parts of the motivation but I hope that, in the end, many of you do it for the art, for the fun, to scratch an itch to create, because you have a passion and because you simply must. You do it for that moment around 3am when, amidst the hum of machines and glow of symbols, your mind and heart come in touch with beauty. A beauty that may be significant or even universal (should you be so smart and lucky) or simply (and more commonly) a satisfying glimmer in a corner of your brain, invisible, unknowable by all but you.

If that is why you write, then you and I have met. We can't and don't meet like that while shouting ourselves hoarse from the tops of moral spires, not even if we happen to stand on the same one.

I stole his title so I'll let the man say his whole bit.

In my Craft or Sullent Art

 
 In my craft or sullen art
Exercised in the still of night
When only the moon rages
And the lovers lie abed
With all their griefs in their arms,
I labour by singing light
Not for ambition or bread
Or for the strut and trade of charms
On the ivory stages
But for the common wages
Of their most secret heart.

 
 Not for the proud man apart
From the raging moon I write
On these spindrift pages
Nor for the towering dead
With their nightingales and psalms
But for the lovers, their arms
Round the griefs of the ages,
Who pay no praise or wages
Nor heed my craft or art

 
 Dylan Thomas

I spent several hours this evening beating my head against a wall of IDL-Java ignorance. Ive been trying to generate Java stubs for Berlin's main library and all idl-java compilers I tried either choked on the idl or generated non- compilable code. At some point it became clear to me that a) I won't find a compiler/ORB that 'just works' b) I won't be able to understand IDL well just by reading generated Java code and trying to work backwards. I sat myself down with the IDL spec and the IDL-Java mapping spec, learned both by heart, generated a bunch of IDL test cases, fed them through the closest-to-working idl compiler (jacORB's), stared at the compiler's source code, picked a class for closer inspection and almost immediately found the problem. It wasn't hard, what I was doing earlier was hard - searching for solutions in the places that I was comfortable with instead of the places most likely to contain the problem. This is a general pitfall, worth looking out for. Practical example - suppose you're walking home at night, somewhat inebriated. You reach the entrance of your house, only to realize you've lost your keys. You may feel the urge to start looking for them on the ground under nearby streetlights - you can see better there. Resist it. At the very least, try the door.

I've been putzing about with Berlin over the last couple of weeks, trying to get a Java client to talk to a Berlin server. I've been hitting bumps of various sizes all the way from installing Debian to building the bits and pieces Berlin depends on, building Berlin, finding a Java IDL compiler that doesn't choke on Berlin's IDL files, finding a Java ORB that works, building the build tool used to build the ORB, building the ORB, hand-slapping generated client stubs into shape, looking under the couch for an IOR to omniORB's name service... None of these is rocket science but they are all essentially 'configuration' work, activation energy you expend before anything interesting can be attempted. It's hard to motivate yourself to sit down and concentrate on swatting away at swarms of annoying little problems, all slightly different. But enough whining. A few minutes ago, I compiled a simple test client and tried to talk to the server.

He just smiled and gave me a vegemite sandwitch

I was rewarded with a remote reference to the NamingService. All-singing, all-dancing, bytecodespawned, once-written, almosteverywhererun, alphablended, rotated pixels are but a few steps away. 5:46 AM though, bedtime.

I briefly scanned my bookshelves for a book meeting schoen's criteria. I think I might have one, A Theory of Objects, M. Abadi, L. Cardelli (contributor).

Staring at the spines also reminded be of a strange 'standard' that I do not know the origin of. All English books (i.e. books published in English) have titles printed _down_ the spine - you tilt your head to the right to see the text 'right side up'. All Russian, German and Bulgarian books have titles printed going _up_ the spine. Bizarre.

ACID flames

There's a minor inferno on slashdot about MySQL and transactional support (and MySQL's lack thereof). The article that people are responding are to is not, for the most part, factually inaccurate but it sets the wrong tone by calling the MySQL developers 'clueless'. In any event, much of the subsequent discussion revolves around whether most applications need transactionallly safe storage. It's hard to argue about 'need' but transactions certainly make most multi-user, concurrent apps much easier to program. A more interesting question is 'do most applications need a relational store?' and by extension 'do most applications need generalized ad-hoc query support?'. I think the answer to the last two questions is 'no' for a many more apps than those that do not need transactionally safe storage. Unfortunately, the most widely available and accepted way to get transactional support is through a relational database. As a consequence an unreasonable amount of time and effort during application development is often spent on RDBMS integration, particularly in cases where the application middle tier is implemented in an object oriented language. Various object-relational mapping products can make this somewhat but not significantly easier. A possible hybrid approach is to use a transactionally-capable, non-relational store (e.g. something built on top of sleepycat) for the apps 'live' data set and periodically extract a relevant subset of the data into an offline RDBMS for 'ad-hoc-query-required' uses - reporting, analysis, decision support, etc. I haven't had a chance to try this approach in a non-trivial, realistic situation yet.