oh, yeah, data is hard.

security vs. usability: deleting a file might not kill it off, so i might be able to undelete it, which can be really handy at times. however, it sucks if that data isn't something i want to escape, and it is deleted but left on the disk when somebody buys it on ebay or finds the laptop left behind on the london tube. so rather than always cryptographically secure-rming the data, what if the data were scrambled upon deletion via a passphrase of my own choosing? of course, you'd want that passphrase to itself never be stored on the disk. so the idea doesn't work out because i don't want to have to enter a password every time i go to delete something.

forcibly taking null out back the parking lot and shooting it in the head.

i hate java. pretty much. although maybe if java didn't exist the alternative world we'd be in would be even worse? horror.

i think that the flash sub-section of the photographic industry is a huge looze for customers. as if it is all designed by a nefarious oligopoly to make your life as a purchaser of photographic flash equipment as much of a pain in the ass as possible.

security is hard. usability is hard. distinguishing the two is hard. thus, verily, let us go forth and shop.

complexity will kill us all.

get your free digital kanban tool.

ok, i am starting to hate Amazon ever more. things like: how they require me to re-enter my password a zillion times, probably because they refuse to have a "logout" button; how they don't show the cost of other shipping options all the time; how they say "Estimated ship date" and i don't know if that means the day it will leave from Amazon, or the day it will arrive; etc.

[update: oh if i switch from the free super saver shipping to standard i pay for it shipping, then it changes to "Estimated delivery date", emphasis added.]

it is surprising to me that Amazon manages to screw up the check-out process so badly in the case of adding new things to your cart after you've already gotten to the last stage of the buying steps. now i have to re-enter all the gift notes. so that's utter genius.

a problem with "we can fix it, or figure it out, later" in the sense of things like "oh don't worry about overflow yet" is that by the time later comes around and you have to face the problem, it is couched in a system of more code that probably also sucks, and you might well be scared of mucking with the thing for fear of introducing more problems in a fragile system.

just sayin'.

will somebody please solve the problem that we can't see and control the dynamic runtime state well enough? how many more deaths have to happen?!?!

i don't do as much TDD as i'd like, even though there are people who these days are saying TDD isn't even as ideal an approach as previously thought. in particular, even if TDD isn't the best way to do all parts of design (go figure), i think that code which was written to be testable from the get-go is a lot better (for anything other than a teeny tiny project) than the alternative. i've lived through the alternative too many times, and through trying to rework it to be tested, and just hate that life.

it drives me utterly freaking batty when people have the attitude, when presented with a problem by somebody else, of "frankly, i don't see a problem here." i mean, shit, those people might as well go work for the government, or the airline customer support, or the irs, or whatever other brick wall institutions we have and i thought all recognized are bad?

raising kids in the usa is probably weird: violence is OK! but sex ain't. i mean, what?!

if your programming language has "features" which make IDEs unable to supply their full complement of features, something might be wrong with that programming language. (javascript!)

how to fight the good fight for understanding typing.

"Recently, members of the community who are prominent in Lean and Kanban such as Liz Keogh, Chris Matts and others have been pointing out that TDD represents a fairly slow way to evolve the information arrival process and they have been exploring ways of accelerating information arrival to reduce the number of iterations required to reach a good enough level. Ironically, this is (re-)introducing some old ideas like domain or data modeling and encouraging partitioned requirements and partitioned architectures that separate out variability and reduce the need for iteration on needlessly coupled requirements."

"To steal a bit of thunder from Covey: It's about compasses, not clocks. Are we headed in the right direction? Then keep going. Don't spend time trying to decide if it's going to take 2 days or 4 days to cross the mountains. Do you need to cross the mountains? Yes. If it takes 2 days was it worth it? Yes. If it takes 5 days was it worth it? Yes. So start crossing."

i hate it when an app (gmail) adds a feature (re-ordering messages with drag and drop) that i don't want, that gets in the way, and that apparently i can't turn off?