Blog

[2010-08-12 10:42:57]: stak has been having lots of nested dreams since watching Inception.

Schneier's post on self-enforcing protocols reminded me of a similar scheme I thought of a while ago for negotiating the price of something when there's a single buyer and seller. In order to get the best price for both parties, the buyer should write down the maximum price he is willing to pay. The seller should write down the minimum price he is willing to accept. If the buyer's number is greater than or equal to the seller's number, then the price is the average of the two numbers. If the buyer's number is smaller, then there's no deal. The key is that this process happens only once, so neither side has a chance to cheat and adjust their number later. If they want the deal to actually happen then they should be honest about their max/min bids, and that automatically results in the fairest price for both parties.

[ 1 Comment... ]

Item the first: Google pushes Apps out of beta
Item the second: Security expert blesses Google Native Client.
Item the third: Google announces the Google Chrome OS.

I had pretty much given up hope on GoOSe ever becoming a reality, but it looks like it's here at last. Now that it's here, though, I'm not all that sure it's such a good thing. I believe this OS will be the next Windows - Google didn't come up with Google Native Client for no reason. Add that to the mix and you have the perfect OS. Unfortunately, everybody using this gives a lot of power to Google. Far more power than Microsoft ever had, because Google will have all your data.

And I'm still waiting for those kiosks.

[ 0 Comments... ]

I was thinking about a conversation I had the other day where somebody was considering using XML for marshalling/transferring data between two networked hosts. I felt, and still feel, that using XML for something like that is a poor choice. After thinking about it more, I realized that XML sucks when used in communication protocols, but is still useful when used as a data storage format.

The key difference, I think, is the fact that communication protocols are only used while there are entities communicating. If all of those entities cease to operate, then the protocol is effectively dead and/or useless. The communication protocol, therefore, is transient in nature. With data storage, though, it is the opposite. If you save a file, that file is going to stay around as long as you want it to, even if all the apps used to manipulate that file no longer exist.

This difference means that the data storage format must be self-documenting, whereas the communication protocol does not need to be. If you want to recover the data even after all the manipulating apps are gone, you need to be able to look into the file and figure out what is what without being able to look at any source code - that's what XML is great at. With the communication protocol... who cares? If all the communicating entities are gone, just invent a new protocol and be on your merry.

The other thing XML claims to be good at is extensibility. The claim is that XML is a well-defined, structured format, and it is easy to create schemas and extend files with more tags/attributes as necessary. While that is true, it is not a property specific to XML. Binary formats can be just as extensible as XML; they're just not as human-readable. You can reserve bytes and bake in room for backwards-compatible expansion into any well-designed binary protocol. And in both cases (XML and binary formats) any expansion to the protocol will require updates to the implementations that read/write the protocol, so there's no magical advantage to XML on that respect either.

The advantage with binary protocols is that they're more efficient - both in terms of bandwidth and processing time. A switch(read()) loop will outperform a SAX parser by multiple orders of magnitude, and so they make far more sense to use in a communication protocol. With data formats, you could at least argue that self-documentation is important for data persistence and recovery, and therefore conclude that XML would be a better choice.

I don't recall anybody ever really making the distinction between these two categories in which XML is commonly used. At first XML was new and cool and people used it for everything. Then there was a wave (as with all new technologies) where some people decided XML was no longer cool and denounced it as bloated and useless. Now its use is split between people who think it is awesome and people who disagree, rather than using it where it is appropriate and where it is not. An unfortunate state of affairs indeed.

[ 4 Comments... ]

So, since there was such a rabid response to my Facebook proclamation that I would determine the best cereal once and for all, I have decided to blog my cereal battles for everybody to follow along (and also for myself to keep track). I've spawned off another sub-blog for it. The first battle is here and in general you can see all the cereal battles at this URL (also has it's own RSS feed). Enjoy!

[ 0 Comments... ]

There's a documentary in 4 parts on Youtube about the philosophy of parkour. It's the best one I've come across at explaining parkour to beginners/non-practitioners, and is well worth the time to watch, even if you care nothing about parkour. It's a bit long (each part is just under 10 minutes), so feel free to watch it in pieces.

The Nature of Challenge - Part 1, Part 2, Part 3, and Part 4.

[ 3 Comments... ]

It's not who you know, it's who knows you. Which is a function of what you know (among other things). So there!

I always hated people who went around saying "it's not what you know, it's who you know". Nepotism is self-propagating right up until it implodes.

[ 0 Comments... ]

Part 1: method invocations

The rules

• Arguments in favor or against any of the options must not be based on subjective viewpoints (e.g. "it looks prettier").
• Mention of languages that do not follow a C-style syntax is strictly prohibited (to avoid flame wars).

The options

optionA(foo, bar, func(baz));
optionB( foo, bar, func( baz ) );
optionC (foo, bar, func (baz));

The arguments
Option A is the shortest, requiring the least amount of typing, and fastest compilation time.

Options A and B have no whitespace before the opening parenthesis, therefore requiring a shorter search string when looking for instances of the method invocations (i.e. grep "optionA(" instead of grep "optionA (").

Option B is most convenient for manipulation via a tool (such as a naive code preprocessor), since useful tokens can be obtained by splitting the code on whitespace. Option A would return things like "optionA(foo," which are less useful than "optionB(" and "foo," separately.

The conclusion
To be determined once y'all weigh in with additional options and arguments.

[ 15 Comments... ]

So I came across the "girl named Florida" problem today on somebody's blog. (Part 1, 2, 3). The problem is taken from the book "The Drunkard's Walk" by Leonard Mlodinow and is easily googleable. Here's the problem:

Suppose that a family have two children.
1. What is the probability that both of them are girls?
2. Suppose you know that at least one of the children is a girl. Now what is the probability that both children are girls?
3. Suppose you know that at least one of the children is a girl, and her name is Florida. Now what is the probability that both children are girls?

The answers provided are 1/4, 1/3, and 1/2, respectively (I'm not sure if these answers are actually in the book, but I assume they are based on what everybody is parroting). You can follow the supposed logic in the part 2 link above, or in question 3 here.

The thing is, the solutions given make no sense intuitively. And therefore, I don't think they're right. Knowing the name of one of the girls shouldn't change a thing, because you can assume that the girl is named "x" and the exact same reasoning would apply. Therefore the answers to question 2 and question 3 must be the same.

My answers are 1/4, 1/2, and 1/2. For the second question, there are really four possibilities with equal probability: BG, GB, GG, and GG. And half of them have two girls. Another way of looking it is to simply discount the child you know is a girl. Since the two children are independent events, the second child has a 50% chance of being a girl, and therefore there is a 50% chance that they are both girls.

I'm convinced my solution is right. As a consequence I'm also convinced that everybody else must be stupid, starting with the author of the book (assuming the book says 1/3). Somebody please prove me wrong.

[ 14 Comments... ]

So the other day I was looking for one of my older posts and instead I would up reading a bunch of them and realized just how wrong I am when I predict stuff. So I went back two years in posts and here's a mish-mash of forward-looking statements I made:

• Post #269 - Froogle. I said that in a couple of years Google Product Search would be considered a viable contender to Amazon. Well, they've got a couple of months before the deadline is up, but I'm not holding out any hope of that one happening. FAIL.
• Post #276 - Google Gears. Well, this one's a mixed bag. At this point, Gears is really only used by Google products, and very few people have Gears installed in their browsers. Although they're still moving in the direction I talked about in that post, they're not going very fast. Need more time to see where this ends up.
• Post #287 - Parakey. Not only does parakey.com seem to have been wiped of the face of the earth, so does blakeross.com. And whatever their stuff might have looked like, I don't see it in Facebook. At all. I didn't have any predictions on this one, but looks like my "hope" was squashed pretty flat.
• Post #292 - Javascript. I can barely believe I wrote this post. It's amazing how much working as a browser developer has changed my views of the web. I hate Javascript more than I ever have in my life, and I hate the web developers who abuse it so much more. I'm amused when I realize that the "dom.appendChild" problem I mentioned with Safari in that post was actually correct behavior on Safari's part and incorrect behavior by everybody else. Javascript 2.0/Ecmascript 4.0 has since been killed, to be replaced with Ecmascript Harmony. Firebug is waay better than Opera's new Dragonfly debugger. Really I just take back everything I said in that post.
• Post #300 - The 700Mhz spectrum. Well that's come and gone, with Verizon the winner. 'Nuff said.
• Post #316 - Micro-hoo. Seeing as how this never actually happened my predictions are irrelevant. But I'm wondering if the whole ordeal succeeded in shaking up both Yahoo! and Microsoft somewhat from their complacency. I don't really know, but if it did I don't think it was enough.
• Post #322 - IE8. It's been a year and a day since they announced their intention to ship IE8 with standards mode as default. They haven't flip-flopped on that decision. Keepin' my fingers crossed...

I'm sure if I dig deeper into my post archives I can find lots more examples of outrageous prediction failures but really that would just be depressing. I remember lots of google-related predictions for pie-in-the-sky ideas that never went anywhere. It also seems like I've significantly reduced my frequency of prediction posts, which is probably for the best anyway. And of course, this post wouldn't be complete without at least one more prediction: I predict I will post even fewer predictions in the upcoming year than I did last year. Ha!

[ 0 Comments... ]

*drumroll* eMusic! And by winner, I really mean LOSER.

So for over a year now, I've been setting up unique forwarding emails for each online account I sign up for, so as to better track incoming spam. To my surprise, the only spam I got (until today) was from the email addresses I used for mailing lists. I subscribe to a handful of W3C mailing lists, and the email addresses are publicly visible, so spam there is expected and normal.

But today, I received the first piece of spam from an actual account email address, and it was the one I gave to eMusic. The piece of spam I got was for some get-rich-quick scheme, complete with Bayesian-filter-busting keywords glued to the bottom.

I suppose I should also mention that I got some junk (newsletters and the like) from some of the other accounts (Aeroplan comes to mind) that I didn't sign up for, but was able to opt-out from. None of those were misleading in any way; it was obvious who sent it. The eMusic spam I got today was the first that was completely unrelated, and proves that they allowed spammers to get their grubby hands on my email address in violation of their privacy policy.

Also, I should also mention that I terminated my eMusic account a couple of months ago (24th November 2008, to be exact), so it might be that they only sell your email address after you're no longer a customer of theirs. But they're still a rotten egg in my book. And their music selection sucks.

[ 5 Comments... ]