Monthly Archives: January 2007

An old php quince

<?php $b='<?php $b=%c%s%c;printf($b,39,$b,39);?>’;printf($b,39,$b,39);?>

Read about the state of the Ruby VMs

The Impending Ruby Fracture is an interesting read on the state of the Ruby virtual machines. The comments are equally interesting, since they complete the perspective.

Missed click

The air conditioner was on, and had frozen my fingers. So when I tried to click a link, I failed to place the mouse correctly, and missed the mark. I jerked my mouse towards the link, and clicked again. The jerky movement misplaced the click, which once more fell on open page. I tried again. And again. I actually succeeded in clicking the link after more than ten tries.

It’s happened to me before. I wonder if it’s a common problem.


I’ve recently read a piece about the JSON vs XML debate on Dare Obasanjo’s blog.

From my readings, I think that many folks are missing the point about why JSON sprang up and became popular. In this I agree with Obasanjo. But I opine that the point goes deeper than the eco system. Let me recap what I understand of the history of JSON till date:

  • First, they discovered that it was easy to deserialize javascript objects in javascript.
  • The good news spread. Before long, the new format gathered enough momentum, and it was named JSON, which standard for Javascript Object Notation.
  • People thought about it, and those using XML were too blinded by it’s inertia to see any use in JSON. Hence,the JSON vs XML format debate.
  • Security conscious folks realized that the advantage of JSON brought with it security risks. So someone went ahead and built a library to parse JSON in Javascript.

And with that, JSONs advantage of deserialization is gone.

JSON is great for deserializing data received by a browser. But we must coldly consider whether serialized javascript objects will help our applications transmit data to eachother. Coldly, because the debate isn’t quite done, it’s easy to get swept into, and for now there’s no need for it.

Update: I do not mean to imply that the JSON advantage is lost. Rather, my argument is that JSONs advantage may not be universal to all platforms, and it should not be considered the default choice for any application.

Why interfaces?

A class has behaviour that conforms to an interface. Behaviour and interface are two different concepts. The methods name, parameters and return type are a part of the concerned classes interface. The methods code is it’s behaviour. Most programming courses do not pay attention to this difference. It results in misunderstandings about the interface.

Contrary to grassroot belief, the purpose of interfaces in Java and .NET is not to achieve multiple inheritance. Rather, they are simply specifications of a contract.

For example, let’s take an interface called IMath:

interface IMath
int add(int a, int b);

The contract states:

“Whoever implements IMath must provide the an add method, that accepts two integers, and returns one integer.”

A class that wishes to provide the services provided by IMath will “sign” this contract by implementing the IMath interface.

So on one side of the interface, there is a client. The client expects that any object that implements IMath will have an add method of the signature int add(int a, int b).

On the other side of the interface lies a provider. The provider takes IMath as a responsibility. It will provide all the services defined in IMath to any client.

The slippery SOAP

When support for a standard needs to be standardized… you know you’ve got a problem.