| JezUK Ltd - The Coffee Grounds - October 2001 |
| << September 2001 | November 2001 >> |
The job searching hasn't been going too well. The market's flatter than I've ever seen it, and come last Friday I'd got nothing even vaguely promising going on. The whole business was looking a bit miserable, particularly when it seemed that Chrystal weren't going to pay my last invoice. So I poked away at my code, with the rain splatting on the skylight, drinking coffee and feeling sorry for myself.
Nat's Dad, in his younger days, had been a globetrotting travelling salesman for Max Factor. He's got stories about doing the twist with Miss World, building factories in Vietnam, and fighting off the Mujahideen in the Hindu Kush armed with nothing more than a briefcase full of lippy. No doubt he saw himself working for them until he retired. Unfortunately, corporate something-or-othering saw him made redundant in his mid-forties. I've never spoken to him about it, but Nat and her Mum both describe him as retreating to his study, looking for another job, and working on "projects". This went on for months, seemingly, and ultimately ended in Nat's parents divorcing. I guess he had some kind of breakdown. He never did find another job and has lived off his (obviously pretty shrewd) investments for the last twenty years.
Chewing over the detail of DOM Core Level 3, I became very aware of the shadow of Nat's Dad and how I must look. Unfortunately, my lack of investment prowess doesn't afford me the luxury of a breakdown.
It's all going better this week anyway - I've been put forward for some things, my solicitor friends tell me Chrystal should have to cough up, and I've got a line on a job that's but a 90p bus ride away.
[Add a comment]
Interoperating different DOMs is easy in Java. You just implement the interfaces in the org.w3c.dom package and off you go. I built a DOM on top of the Astoria XML database API, slung it around with the Xerces-J DOM, and it all just worked.
In C++ it's a different story. Because you're more or less forced to implement some form of object reference counting, you can't just define a set of abstract base classes and leave people to derive from that. You have to build a set of classes which know how to reference count, then a parallel set of classes which actually do the work. This is what Xerces-C does for instance. I don't think, though, that I'd be able to build the equivalent of my Astoria DOM in C++ and get it work with Xerces-C. It might, but it would be a load of work and I probably wouldn't be able to benefit from the code that's already there.
My solution is to define a set of concrete classes which do the ref counting, a parallel set of abstract base classes, and then derive a further set of classes which actually do the work. With me so far? An alternative implementation would derive from the set of abstract base classes, but would still use the same set of concrete wrappers. everything should interoperate ok. I think.
Anyway, it's all sitting in CVS. Any comments will be, as ever, gratefully received.
[Add a comment]
Just FYI, this is a fairly common problem; the libxml developers' response to this seems to be along the lines of "entities in libxml sax are hard, either don't use entities or use DOM". Yeah, right.Hmmm. I'm sure it did work correctly with an earlier version of libxml. I don't follow the logic behind entities via SAX being hard either. For a SAX interface, I'd say it was acceptable to just report the entity reference and let the SAX client sort out resolving it.I'm giving up on that library; it's worthless. Hopefully Expat will be better.
When companies are wound up, it's not uncommon for the company assets to be sold off. Chrystal, unsurprisingly, has a number of computers, and some of the soon to be ex-employees enquired about buying them. One employee, let's call him Mr P, offered £300 quid for the laptop he'd been using. You can buy a brand new Dell luggable for £600, so that sounded pretty generous to me. Bear in mind also, that companies can write-off computer expenses complete in the frist year, rather than over three years like normal assets. Consider also that the laptop in question is not one that the main Xerox corporation will support, so it can't go back there. Essentially, therefore, this is a computer with no value at all to Chrystal. The three hundredd quid being offered is, then, money for nothing. Little T said The sale price on these units to our employees will be one-half of current book value or $1150. This is not a negotiable item. Looks like those computers will finish up in a landfill somewhere.
That's a comparatively minor example of corporate fuckwittedness, especially when you look at the way clients are being treated. Some of them have spent a lot of money having Chrystal write software for them, and now find that they may as well have thrown that money down the toilet for all the good it will do them. The letter I've seen, which I'm told is the one going to the clients, runs to about 140 words and essentially says you're shafted. From what I hear (rumours remember), the only piece of software that the vestigial Chrystal organization will support is the latest release of the Astoria database. Run your website using Chrystal's Eclipse? You're fucked. Build your translation workflow using Lingua? You're fucked. Rely on the bridges to connect your XML editor to Astoria? You're fucked. Done almost any kind of useful work with Chrystal products? You're fucked. Chrystal won't help you. And no, you can't have source code access either, so you can't help yourself either. The letter predictably blames increased competition and a soft economy. Bollocks. Remember Mr. Garnett's strong background of successful leadership and innovative strategies will help lead Chrystal Software's continued growth.
I could go on, but you get the picture. I enjoyed working for Chrystal, but the way the company's acting now is arrogant, wrongheaded, and makes the people running it look like a bunch of cunts. When the client companies I've been dealing with get in touch and ask what's going on, I have to tell them I don't know. They trusted me to help solve their problems, and I've let them down. That makes me look like cunt too. Thanks, Xerox!
[Add a comment]
#include <wrapper/saxexpat.h>
...
void myFunc() {
...
SAX::expat_wrapper<std::string> parser;
...
}
expat_wrapper<std::string> parser_returning_UTF8;
expat_wrapper<std::wstring> parser_returning_UTF16;
msxml_wrapper<std::string> validating_parser_returning_UTF8;
msxml_wrapper<std::wstring> validating_parser_returning_UTF16;
It get's more interesting if you're using some custom string type, or you want std::wstrings containing UCS-2 Unicode instead of expat's UTF-8 encoded const char*. In cases like this, the string conversion policy class would need to a little more work (although not too much). The big gain is that you can just drop it straight in, and the expat wrapper will hand out what you want. No second conversion layer on top, no further fiddling. Cool.
Andrei Alexandrescu's fantastic book Modern C++ Design describes this design approach in much more, and more illuminating, detail.
[Add a comment]
I hope this will allow for a number of groovy things to happen, like autowidening/narrowing wrappers which don't need another layer, or the use of basic_string compatible const_strings, etc. It should become clearer in the course of the next week or so.
[Add a comment]
Spent the afternoon updating my CV.
[Add a comment]
Erm, does this mean I'm out of a job?
[Add a comment]
| << September 2001 | November 2001 >> |