I got my copy of Practical Cryptography yesterday, and so far my expectations have been met. It's what you'd expect if several of the world's foremeost cryptographers walked down out of their ivory math towers and started talking about the dirty details of how to make a crypto system really work. They don't pull any punches, and they call a spade a spade (which even too few security people are willing to do).
Neat stuff. I'm sure I'll write more about it.
I've been away a long time. Sorry all.
So I've come to a new conclusion: I don't give a crap about XML. Really, I don't. All I want to do is get my work done, and as often as not these days I'm finding that XML is just getting in my way. Let me step back and explain a bit.
Part of my contractual obligations with the people funding my current work on netWindows is the production of comprehensive documentation. This is a Good Thing. My choosen method for the documentation is a mildly clever melding of DocBook and JavaScript. While DocBook has a reasonable vocabulary for doing almost everything I need (and tools aplenty for getting from here to there), I find myself defining a slew of entities simply to cut down on the ammount of repetative, easily fungable stuff I have to retype. XML lets me do this without too much trouble, but the fact that I have to think about it in the first place and/or that it requires me to do something for the computer, bugs the hell out of me.
XML is a nice tool for some things, but overall I guess I've been recently reinforcing my feeling that it's being over-used, wrongly prescribed as the answer for everything from config files to word processing, and in general missunderstood. XML fails every time it's exposed to a user directly. It doesn't do enough for us. We need something better (or better tools around what we've already got).
My little contribution to Mark Pilgrim's CSS tab discussion.
I've kind of been sitting on this technique for some time now (4 or 5 months?), but Marks blog entry finally spurred me into doing something with it. Hopefully it'll be useful.
I just spent upwards of 3 hours attempting to get a functioning Python XSLT processor installed on my box so I can continue brainFeed development. What a fucking mess.
To start with, the latest versions of PyXML supposedly provides an xslt module (derived from 4XSLT) with a sane programatic interface. Unfortunantly, when it does decide to compile, it segfaults whenver you try to create an XSLT Processor object, and if there's some implicit dependency on 4XSLT, the docs ain't talkin. Worthless.
As for 4Suite proper, it DOES compile and install without problems, only it's programatic interface is a steaming pile. Instead of:
from xml.xslt.Processor import Processor
ssText = open('styleSheet.xsl').read()
datText = open('myData.xml').read()
xslt_proc = Processor()
xslt_proc.appendStylesheetString(ssText)
result = xslt_proc.runString(datText)
4XSLT makes you do this:
from Ft.Xml.Xslt import Processor
ssText = open('styleSheet.xsl').read()
datText = open('myData.xml').read()
xslt_proc = Processor.Processor()
xslt_proc.appendStylesheet(
Ft.Xml.InputSource.DefaultFactory.fromString(ssText)
)
result = xslt_proc.run(
Ft.Xml.InputSource.DefaultFactory.fromString(datText)
)
And no, those much longer interfaces don't appear to be documented. It took me an hour of reading source just to figure this much out. What a cluster.
Nothing left to do now but pray for our men and women in uniform.
And try to keep my mind off the queasy feeling that this could have -should have- somehow been avoided.