traffic comments edit

Coming out of the grocery store yesterday, I swore I heard an ice cream truck.

It started quiet, sort of peaceful, like that background music you hear sitting outside a decent coffee shop.  Second by second, it got louder.  And louder.

Looking around, I saw this car come tearing into the parking lot.  Tires squealing, careening around other cars, totally unsafe style, and coming this way.

At this point, the music was so loud it was like I was listening to my own headphones.  It had changed, though, from ice cream truck music a la The Entertainer to something more lilting, bringing visions of castles and ponies and princesses to mind.  Like Zamfir, but with more birds chirping and crap.

The car screeched into a parking spot and the driver stepped out, the music immediately silenced as the car turned off.  The driver, acting far more important than I’m sure he’ll ever be, strutted into the store.

I’m not a big fan of those cars that crank their music up to share with the neighborhood, but I mind it a little less if it’s at least halfway decent music.  I’d even take some ridiculous hardcore gangster rap over this fluffy-pink-clouds garbage.  If you’re gonna blare music, at least make sure you’re blaring good music.

media, music, home, cats comments edit

Jack and Xev are friends, aren't
they?I love my two cats, but the little Siamese-tabby mix Jack is pretty aggressive and he’s been chasing my other cat Xev around a lot, particularly in the last, oh, month or so.

Yeah, you’d never guess that from the picture, right?

Okay, so a couple of weeks back, it’s business as usual - Xev is yowling because Jack is riding her back around the house.  (Yes, he’s fixed.  They both are.  He’s just being an asshole.)  They make a mad dash out from behind the couch and…

SLAM!

I turn to see that one of the stands with one of my Bose Acoustimass 16 cubes has been knocked over and the two cubes that make up the speaker have come apart from each other at the part where they swivel.

The cubes are broken apart where they
swivel.

Looking at the mechanism that was exposed, it looks like the thing literally just snaps together.  Unfortunately, the way it snaps together is so tight and fits together in just such a way that there’s really no way you can just snap it back together.  I can see that the assembly of the two cubes actually happens pretty early in the manufacturing process because it looks like the two cubes would need to be snapped together before the speaker bits got inserted.  The speakers proper still work, the cubes just aren’t attached anymore.

I tried everything short of actually disassembling the damn thing, but it was no use.  I ended up taking it to a repair shop who specializes in this sort of thing and it turns out the speakers aren’t field serviceable.  Of course they’re not.  Instead, they have to order me a replacement, and that’s going to cost me - wait for it - $151.  That’s one-hundred-and-fifty-one American dollars.  That’s in addition to the $25 I already paid them to look at the thing for me (some of that is credited toward the total cost of the speaker, bringing it down to $151).

Travis == Over A Barrel.  ARGH.

GeekSpeak, net, vs comments edit

I started working on converting CR_Documentor over to use XSLT for its documentation transformations this morning and soon realized that it may not be that easy.  The goal was to be able to just take the XSLT from the various documentation generation engines (NDoc, Sandcastle) and as fixes or changes happened, “plug in” the new XSLT and have the preview ready to go.

Not so much.

I tried a simple test using the NDoc XSLT and it turns out that I have a few stumbling blocks.

  • The input XML is complex.  The format NDoc expects the XML to be in prior to executing the transformation is pretty complex.  That’s not really a problem in a post-build timeframe where you’re not looking for real-time changes, but just creating the correct XML hierarchy is a pretty big task, let alone then getting it through the transform engine.
  • Everything is relational.  There are a lot of things in the NDoc XSLT that assume, for example, that you’ve got everything you need to document all in one file, so there are relational things going on.  For example, when you generate the documentation for a method, any cross-reference links you have are also generated… which runs through connecting actual URLs to HTML files and setting up links and everything.  To avoid setting up bad links, the XML that’s generated gets heavily pre-processed.  Again, not something that can readily happen real-time.
  • Much is assumed to be in the filesystem.  Temporary files, the XSLT, images, script… there’s a lot that the XSLT assumes is in specific spots in the filesystem, which means that I couldn’t use the stylesheets as-is anyway; I’d have to heavily massage it to get it where I want it to be.

Unfortunately, a lot of this sort of means using XSLT directly is a non-starter.  Even if I could get past the fact that I’d be doing almost as much work creating the input XML as I’m doing right now to generate the whole preview, the requirement for all the relational things and the fact there’s so much in the filesystem anyway means I’m probably better off just hard-coding the transformation the way I’ve been doing, as lame as that is.

I won’t lie; it doesn’t increase my desire to work on the project.  I like it, and I really wish I could just release it to the community open-source style, but since I can’t, I’m sort of stuck.  Motivationally challenged, shall we say.

Well, I guess my next step is to look for opportunities to refactor it and make the code at least a little easier to maintain and update.  Maybe that will make it easier to implement new rendering views.