Isolationism

It’s finally the weekend and none too soon: My week hasn’t been especially bad (but not especially good either. Kind of so-so) but today could have gone better—Squeaker wanted to be entertained at 4 in the morning, I had a fun visit at the bank with my financial advisor (I think I’ve decided I prefer going to the dentist), and I’m dog-tired well before my usual bedtime.

I’ve been slaving away this week at lots of Python code, too—it’s the worst kind, to boot; I’m refactoring my own old code, which is a thankless job if ever there were one (although I am adding a number of extra little switches and things for efficiency, better error handling, output verification, etc.). When you’re already pressed for time on a product release schedule, trying to explain to your manager that you’re trying to leave maintainable code that could mean literally hours of saved time per week from those that employ it regularly is pretty awkward when he knows the old version worked (no matter how old and busted you think it is).

You know you did a sloppy job when you look at your own work from only six months ago—And it’s Python, to boot, which isn’t exactly like reading someone else’s uncommented Perl code (*shudder*)—and you have no idea what the heck it is you’re looking at. All I need now is to print out the module using a my-handwriting-circa-grade-six typeface, and my baffled incomprehension will be complete.

Still, it’s not all bad news. I wouldn’t be working on refactoring the module at all (nor would I have written a line of Python in the first place) if I didn’t find myself enjoying writing it immensely. There’s just something magical about executing a piece of code that a simple drawing lacks; it’s that powerful transformation from a few words of seeming nonsense text on a screen to something else completely (or not, in my case, as I am using Python predominantly to write CSS—so it is in fact merely different nonsense text than that which Python understands) that the process of design or illustration can’t equal. The closest visual analogy I can conjure is a 3D rendering, but I haven’t done any of that in years now and I can’t say I’m especially sorry to see the back of it—at least for another little while longer, anyway.

The news at work isn’t all roses, though; We depend on a CSS compressor (or ‘parser and optimizer’, as it is described by the author) I discovered named CSSTidy written by Florian Schmitz, who is incidentally quite nice and very responsive to questions as I had to ask her a few earlier on in the week regarding some performance issues I was experiencing with the software.

The software is great and the price can’t be beat (free, under the GPL), but we’re doing so much volume that we need something faster; For some reason, the CSSTidy binary compiles to around 3.7 MB in size (!) which seems unusual for software doing little more than string manipulation. It screams on dual Opteron processors but chugs along on everything else I’ve tried it on; It would be no big deal with one file to compress but when you’ve got well over a hundred …

The good news is I’m starting to get the hang of writing relatively good Python OO code after a shaky function-centric, spaghetti-code start—So far there isn’t much I’d want to share with the world (and largely I couldn’t do if I wanted to anyway, since the company I work for owns the code, not me), but maybe my next pet project will change that: I’d like to write an equivalent program to CSSTidy in Python. If I do end up undertaking the task, I’m going to try to do it all on my own time if I can so that I can release the source code under a GPL licence of one shape or another and maybe at least get my name out a bit since I’m certain nobody would want to pay money for something of the kind (especially when it’s already been done many times over now, although predominantly in PHP since most people want to offer it as something of a web service for whatever reason).

I somehow doubt I’m going to write anything that’s faster than Florian’s C++ native code, but then my work implementation of the script won’t have to do all the same things that CSSTidy does either (since our code is in fact quite clean and doesn’t use any shorthand at all, so that conversion process need only go in one direction) so for work purposes it might just execute faster.

There’s also a distinct advantage to not having to distribute binaries for all the various architectures we could potentially deploy on, too, although honestly I can’t say I saw much difference in execution times with or without the -march attribute specified (whereas the -O3 flag worked wonders compared to the unoptimised default build string; I strongly recommend its use if you’re going to compile CSSTidy for yourself).

Those points aside, though, I think the biggest advantage of writing a program like this in Python is the code’s reusability: someone will be able to import the module and use as many (or as few) methods as they please to achieve their own ends, including modifying and extending my own code as they see fit.

Anyway, it’s all a bit of a dream right now. My plans may yet fall through for lack of time (or energy, or sleep)—but I think it’s something I’d like to work on eventually, if not in the next couple months. If you have any personal or professional interest, either in using or contributing to such a program, feel free to leave a comment or drop me a line.