Tuesday, March 31, 2009


Atwood was talking about how English is a lingua franca of sorts in the programming world, and now there's this rebuttal making rounds.

I remember seeing a fairly similar discussion in Orkut once. Orkut is a social networking site that is popular mostly in Brazil, and the discussion was about whether people should make an effort to speak in English anyways, since it's been (arguably) the lingua franca of the Internet.

It sorta boiled down to this: lazy people would stay in their comfort zone. Smart people could recognize the value of using english.

I'm not saying all Brazilians are lazy, just that there are a significant number of Brazilians who are not that comfortable with English and are not as willing to make an effort to learn it.

What's a bit funny is that, with Jeff's example, things are a bit reversed from mine: in Orkut, you're more likely to get unexpectedly different perspectives when talking in English with an Indian or Japanese or Russian person, than talking to someone from the same city you were born in. The programming example speaks in a scale that is an order of magnitude larger: In the real world, you are more likely to see unexpectedly different perspectives when you get out of the English speaking bubble that is the Internet.

And with all these talks of recessions and the need for entrepreneurship, and (if you follow Seth Godin anyways) the idea that focusing on tribes is the road to success, maybe we should be considering the possibility that we've spent way too much time shielding ourselves from the scary, weird world, and that we've been losing out on a lot of opportunities.

Monday, March 30, 2009

I know, I'll use a library! Now you have two problems

I just helped a co-worker from another dept debug one of those fun bugs that make absolutely no sense when you first see it (syntax error in IE6, no line number, if you're wondering). The codebase is for an internal app and it's fairly old and not very well written. It uses an older version of prototype and uses Adobe's js library to get around that Eolas thing.

So, just like the adobe code docs suggested, we had code like this:

<script type="text/javascript">
var bla = "some config for flash player version"

Yeah, we know inline javascript is not a great idea, but people working with 3rd party flash graph components (especially when these people are full-time back-enders) are not particularly keen on iterating over little javascript boilerplates that are just there to get the flash up and running.

Anyways, the code above looks fairly harmless. It's just a variable assignment.

Or is it? Turns out that if we ajax that code with older versions of prototype, the Ajax.Updater call will internally parse all the script tags and eval() their innerHTMLs via the String.evalScripts function. The catch: it doesn't filter out the HTML comments out!

So, since IE6 doesn't have support for E4X, you'll get a big fat syntax error popup on your face.

Yes, I admit, our internal code is fairly ugly and could be improved a lot, but that's another rant. The issue here, though, is that, by themselves, both Prototype and the Adobe library worked just fine - it's only when the two appeared in the same codebase that hell broke loose.

Now that I've described the problem, it may even seem fairly silly and easy to identify, but tell that to the guy that was pulling his hair out a few hours ago. In all honesty, we only managed to find out that was the issue because:

  1. I've played a lot with writing libraries on my spare time and I know about many browser limitations and quirks that you can only know if you actually do a ton of cross-browser debugging (rather than just staying inside the comfort zone of a tested js library)
  2. I read a whole lot more open source code than a lot of my co-workers and, as such, I'm fairly well versed with Prototype's finicky hacks.
  3. We had already tried a bunch of other things and I suggested to try something unintuitive, because I was stumped and the old school HTML comment in the script tag was about the only thing left that looked even remotely unusual.

Not understanding enough about what's hidden by a library's layer of abstraction can be dangerous. It makes it hard to troubleshoot a problem, even when you can see the faulty code right in front of your eyes.

So do yourself a favor and read the code for the libraries you use. You'll likely learn a bunch of stuff you didn't know before, and sooner or later, instead of burning yourself out over some inexplicable bug, you'll have a moment of enlightenment and say "hey, I know what's the problem here!".

At least for me, whenever it did happen, the second option has been great.

Games, bias and statistics

Otaku Cedric posted this in his blog: Do you want to play a game?

People are apparently fascinated by these mathematical mind games. Count the comments here if you don't believe me.

What's common about these puzzles is there's usually one answer that is more attractive than the others. Reaching the attractive conclusion often requires a bit of logical reasoning, but that's not always the rule.

Considering that mind games (especially the statistical varieties) would not be very interesting if the correct answer was the obvious one, would it be safe to read their intentions and always assume that the attractive answer is wrong?

If you are a Bayesian filter only looking for the numeric/boolean solution, probably yes. People, on the other hand, work differently: the naive gamers will take the bait of the attractive answer and lose the game; the keen gamer will still be drawn into each individual game's rule set, rather than considering that a generic probabilistic approach based on the question's bias will win most of these games, regardless of their rule sets.

The devil is, of course, in the details. Even though these types of games never explicitly ask for the reasoning behind answers, merely knowing the correct answer is not as desirable as knowing why that is so (for us humans, anyways).

Friday, March 27, 2009

Email standards

Email standards. HTML emails usually don't get a whole lot of love from developers. I wonder why.

Wednesday, March 25, 2009

Fast Polling w/ C, Memcached, Libevent and Nginx

The author claims 2400 requests per second. That seems to a whole lot more than Jetty's 1000 rps. To be fair, Jetty's results are 2 years old.

Note to self: I should try and hammer my architecture with messages one of these days to see how well it does.

Monday, March 23, 2009

What trap?

This seems to making a splash on most techie news aggregation sites today. I don't get the fixation with javascript though. It doesn't make a whole lot of sense to talk about non-trivial web applications if we disregard server-side code.

Can anyone actually point me to some javascript code that is GPL'ed and has no unobfuscated source code available?

On x86

Saw it on Reddit, looks interesting, I'll read when I get some time.

Thursday, March 12, 2009

Fossil SCM

Fossil sounds nice: version control with integrated wiki and bug tracking. I'll give it a whirl when I get some time.

Apples are the end of oranges

Sometimes it feels like some people don't actually know the APIs they are talking about. Case in point: webcams and sockets.

Monday, March 9, 2009


I think I'm starting to understand why economists were saying that now it's a good time to be a house buyer. I like reading about people's experiences when the subject is economy, it makes things much easier to grasp than articles about macro economics published by large new outlets.

Friday, March 6, 2009

PPK on mobile browsers

This is why I love PPK: he does all the heavy lifting for us.