02.07.10
Posted in General at 12:15 pm by Steven
This article from ‘MicroISV on a shoestring’ (which is a blog worth keeping up with, if you ask me) has an interesting insight. Patrick says that ad-supported sites are less likely to craft a good user experience, because if the site is better than the ads, the site doesn’t make money. Oversimplified, sure, but it does point out one of the forces at play in the overall dynamic.
I guess that’s a variation on something I’ve been thinking about, that I should get paid for the value I bring, rather than for the value that my advertisers bring. Or my ability to get people to look at little come-ons that give them the perception that there is some value elsewhere, to be more precise.
‘course, setting aside the absurd logic and perverse incentives, I’m glad that somehow ads occasionally work out such that people make good content and also make money from it.
Permalink
02.06.10
Posted in General at 9:52 pm by Steven
Y’ever get worked up about how much you ought to get worked up about something? And then at some point you have to evaluate the inequality about whether the effort of evaluating how much to get worked up, plus the effort of getting worked up itself, is greater or less than the effort of just getting maximally worked up about the original thing from the start. If you know what I mean.
Permalink
02.04.10
Posted in General at 1:16 am by Steven
Huh, I thought shopping for computer-telephony interfaces or scalable web-hosting infrastructure was hard. A little research lately has convinced me that shopping for any sort of insurance must be at least as difficult and probably more.
There is one inherent fact about insurance that seeds the complexity: you’re trying to predict complicated and rare events. The more predictable an event is, actually, the less likely it’s going to be insurable, or insurable at a rate you’re willing to pay. I mean, if you can predict an event with some certainty, you should be using a bank account instead of an insurance policy.
There’s also the psychological twist that these are events that you just plain don’t want to happen. That probably tends to make you undervalue the little information you do have that helps you make your predictions, and causes you to want to just hurry up and get done making the decisions.
On top of all that is, I’m pretty sure, a general tendency for insurance companies to purposely make it harder to buy their products. A great tension exists between the generally communal idea of insurance (we all pool our money together to help whoever needs it) and the capitalist imperative to profit. Basically, insurance companies can only profit to the degree that they hide their actuarial knowledge from their customers.
I was looking at health insurance tonight and was presented with a painful interface to choose a policy. I specified a few parameters in very general terms, and they presented me with dozens of possible policies to choose from, with a ‘comparison’ feature that did little to enlighten me about the differences. It kind of reminds me of that game Black Box where you’re trying to discern what’s in the box by shooting a tiny number of rays into the darkness, though this particular game of black box is probably 80-dimensional instead of 2D. My choices would still not be easy even if I had a full view of the model(s) they use to design these policies, but…
Permalink
01.26.10
Posted in General at 5:53 pm by Steven
Ya know, for all the conceptual elegance of the idea of branching/merging in software revision control, it sure can be a pain in practice. Just in the last while, I’ve run across the following situations:
- someone mismerged my code because they merged based on files rather than revisions
- had to decide whether to merge someone else’s code because mine was dependent on it, but they hadn’t merged theirs
- had to decide when to merge my code, which was part of a larger feature and was not a complete feature in itself: do it now and possibly introduce instability, do it later and possibly have it get delayed in the shuffle
- stuff I’d merged disappeared because the branch was remade after I merged
- conflict while merging my code because the branch was based on a way older revision than I was informed (so other changes I’d made previously were not there to merge against)
- not knowing whether my changes were to be merged because it wasn’t decided when the feature was to be released
- a special case of the previous situation, when it was first decided the feature was for later, then it was moved earlier
- work for a future feature ended up causing a conflict when trying to merge a current feature because the two changes were made in the other order on the same code
Permalink
01.14.10
Posted in General at 4:31 pm by Steven
I wonder what the current status of Java < -> .Net Web Services interop is. A year-n-somethin’ ago, it was a bit of a mess, and for the project I was working on we had to create a proxy running on a Windows box to make the calls. Ugh.
Actually, I don’t really wonder. I don’t care, because I’m not having to deal with such right now. Java/Python/Flex interop, yeah. Passin’ them AMF packets around like a wild man…
Permalink
01.12.10
Posted in General at 10:13 pm by Steven
Here’s a simple thing I did today that will save me some annoyance when dealing with new mail.
I manage my mail in Thunderbird by the simple rule of: if it’s something I need to respond to or reread soon, it stays in the inbox. If it’s junk, junk it, if it’s totally ephemeral, trash it, otherwise it goes to the ‘old’ folder. There are already keyboard shortcuts for junk and trash, but I was still dragging and dropping to put stuff in the old folder. Until I installed keyconfig (and yeah, that link is as close as there is to a project page for the thing, unless you count the author’s homepage). I then installed a script on O that says
MsgMoveMessage(“mailbox://nobody@Local%20Folders/old”)
No more drag-n-drop to manage my email. Nice.
Permalink
01.09.10
Posted in General at 5:38 pm by Steven
It’s fascinating to me sometimes to describe a problem that comes up in software development, outside its full context, just to remind myself of how weird and deep it sounds in isolation. Makes me feel a little better about how long it takes me to solve said problem, maybe.
In this case, in the full context we just call it the ’slicer’, but that one word hides a lot of complexity. What the slicer does is: given a document in XML format A and a set of start points and offsets of selected regions of formatted text (both specified by character counts as the user sees the document), extract the given regions from the document in XML format C, rebuilding any necessary start/end tags and preserving internal formatting. Another process does the translation from format A to B to C. (These translation layers can add extra characters that are not part of the document as the user sees it.)
Permalink
01.08.10
Posted in General at 11:27 am by Steven
One thing I’ve been learning over the last few months is that if your app is pretty beefy, you might well need more than one cloud provider to deploy it. With the major differences in approach between Amazon EC2 and Google AppEngine, they each have a variety of strengths and weaknesses with respect to a given application, and the weaknesses are such that you can’t really just live with them. So you partition the app into pieces and spread ‘em around…
I’d like to be able to claim that that gives you a more robust solution, but of course, if you require two clouds to be operational in order for your app to work, you’re less robust. Both EC2 and GAE have been OK, but not great, in terms of uptime. I expect both to get better over time, though.
Permalink
12.18.09
Posted in General at 2:26 pm by Steven
If you work with Google AppEngine and use task queues much, you know it can be annoying to have to press the ‘Run’ button on each task to make it actually run. Here’s a Greasemonkey script to push the button for you. It mindlessly pushes the first Run button it finds immediately on page load. Since the page reloads, that should eventually press them all away.
Have fun, but there are no guarantees that this won’t run tasks you didn’t really want to run or somesuch.
Dumb script
Permalink
12.13.09
Posted in General at 2:14 pm by Steven
Hmmm, pi is a little bumpier than I thought. (It could just be that my statistical intuition is off, though.)
Each bar plot below represents the number of occurrences of a digit in the decimal expansion of pi. The y-axis is an index, and the frequency x is counted over the range of digits y*20 to y*20+400. I thought 400 would be a long enough length to make these graphs pretty flat. Higher lengths make it flatter, of course, but still not to the degree that seems ‘right’ to me.
I guess I could calibrate my perception by using a uniformly distributed sequence of digits…
Pi digit frequencies
Update: huh. I guess it is just me. Here’s the same sort of graph but with uniformly random digits (at least, assuming that RAND’s book, which I lazily selected as my source, is indeed uniform). Looks equally bumpy to me. Ah well, I’ll leave the post up as a reminder of my folly…
Random digit frequencies
Permalink
12.10.09
Posted in General at 11:30 am by Steven
Scott Stafford was nice enough to post code for asc-gzip/.xfd decompression to go with my asc-gzip/.xfd compression code. See this comment. I’m also reposting it here because the comment formatting is a little more bad than the main-post formatting.
Thanks for your post. Of course, I needed the opposite, I had one I needed to decompress. So I backwarded your algorithm and here is the result:
def decompress(fc):
fc2 = fc.splitlines(True)
fc3 = "".join(fc2[1:]) # could verify that it's asc-gzip here if we wanted to...
unb64 = base64.standard_b64decode(fc3)
ctr = 0
ret = []
while 1:
if ctr == len(unb64): break
ccltop = ord(unb64[ctr])
ctr += 1
cclbottom = ord(unb64[ctr])
ctr += 1
compressedchunklen = ccltop * 256 + cclbottom
cltop = ord(unb64[ctr])
ctr += 1
clbottom = ord(unb64[ctr])
ctr += 1
chunklen = cltop * 256 + clbottom
#~ print compressedchunklen, chunklen
compressedchunk = unb64[ctr:ctr+compressedchunklen]
ctr += compressedchunklen
chunk = zlib.decompress(compressedchunk)
assert(len(chunk) == chunklen)
ret.append(chunk)
return "".join(ret)
Permalink
12.09.09
Posted in General at 3:45 pm by Steven
It’s always interesting for me to dig into XSLT. I don’t use it a whole lot, so when I do it’s all fun and new. This time around, I’m using 2.0, which wasn’t really implemented the last time I was doing anything much with the language. Loving the new features; so far I’ve used several to good effect.
It occurred to me today that document conversion is an interesting niche wherein a ‘pure functional’ paradigm is useful. I still can’t see myself using a pure functional approach in many other areas, but I do have to deal with document conversion often enough that I’m glad XSLT exists.
I find the tree-transformation model of computation is an interesting mind-bender, though when I think about it, it’s really only mind-bending in combination with the functional approach. And thinking further, I’d suppose that a functional program of any size would tend toward the nature of a tree transformation… Hmmm, something to ponder some more.
Permalink
11.19.09
Posted in General at 12:36 pm by Steven
Here’s a bizarre way to lose some files:
rm foo.x `
(didn’t notice I’d accidentally hit backtick)
ls
(always do this after file operations, it’s a weird little habit)
(oops, didn’t work. Oh, there’s a backtick in operation.)
`
(a bunch of errors about some files and directories that can’t be removed.)
(CRAP!)
Running a Bacula restore job as I type this…
Permalink
« Previous entries Next Page » Next Page »
