October 26, 2010

Speed

Your speed determines, in addition to how soon you will be done, the problem space you're going to be working in.

(cross-posted on Twitter)

Living on the cloud


This is why I'm excited about Chrome OS.  Right now on my computer, 11 out of 13 open windows are browser windows.  5 out of 8 quick launch shortcuts are to web apps, 2 out of the remaining 3 shortcuts are to web browsers.  A big chunk of my life is already on the web :)

October 17, 2010

Time

Lack of time is hardly a problem for most of us.  On the contrary, abundance of time is a real problem.

October 16, 2010

Type to switch windows on KDE

Two primary reasons why I use a Linux computer: 1. command line shell, and 2. KDE.  KDE has so many neat features and so customizable, I just can't go back to Windows or OS X's GUI.

A couple days back I stumbled upon a KDE 4 feature.  Looks like KDE would let us use the Run dialog box (which is activated by pressing Alt+F2 from any application) to switch between open windows.  I am the kind that has a lot of windows open all the time.  Sometimes it might be easier/faster to type few letters of a window title to switch to it, and this feature does exactly the same.


I type "mail" on the Run dialog box and the options I have include commands available on the system (the "mail" command), apps like KMail, my quick launch shortcuts (Gmail, manki.in and Mail), and currently open Gmail Inbox.  While this feature really is super cool, it would be even better if individual Chrome tabs are searchable like this.  Well, that will also happen some day :)

October 11, 2010

Truths and myths

Only those who once believed that 100 was the largest possible number later grew up to understand infinity.

(cross posted on Twitter)

Uncertainties

There are few things we know we certainly want.  A few other things we know we certainly don't want.  The few things that we partially want can be a real pain.  Thinking about it, probably these uncertain things usually make us go through immense pain.  If we can figure out a way to handle those uncertainties better, life would be a lot easier.

Context

Context is everything.  You can be a happy person or an unhappy person depending on where you position yourself.  And also, like they say, be careful what you wish for.

October 02, 2010

Code coverage


If you have written automated tests for computer programs, you are very likely to be familiar with code coverage.  Almost everyone agrees that 100% code coverage from your tests doesn't mean that your code doesn't have any bugs.  I have been told this by experts, and I accepted it as such all this while.  Suddenly a few days back I could come up with an example where the test coverage is indeed 100%, and yet one bug goes unnoticed.

This example is an extremely simple case (you can even call it stupid) and the bug is on your face.  But in real systems bugs may not be so apparent.  Here is the code we are testing:

package in.manki.samples;

public class Coverage {
  public long factorial(int n) {
    long f = 0L;
    if (n > 3) {
      f = 1L;
    }
    for (int i = 1; i <= n; ++i) {
      f *= i;
    }
    return f;
  }
}

And here is the first version of the automated test:

package in.manki.samples;

import junit.framework.TestCase;

public class CoverageTest extends TestCase {
  public void testFactorial() {
    assertEquals(120L, new Coverage().factorial(5));
  }
}

The test passes and Emma says I have 100% code coverage:

[class, %] [method, %] [block, %] [line, %] [name]
100% (2/2) 36%  (12/33)! 17%  (91/549)! 23%  (34/150)! junit.runner
71%  (5/7)! 40%  (41/102)! 35%  (442/1272)! 38%  (123.8/324)! junit.framework
100% (2/2) 56%  (20/36)! 47%  (247/530)! 48%  (63.2/131)! junit.textui
100% (2/2) 100% (4/4) 100% (35/35) 100% (10/10) in.manki.samples

Adding the following test would expose the bug, but if we simply go by coverage numbers we would deceive ourselves that the code is thoroughly tested.

package in.manki.samples;

import junit.framework.TestCase;

public class CoverageTest extends TestCase {
  public void testFactorial() {
    assertEquals(120L, new Coverage().factorial(5));
  }
  public void test2Factorial() {
    assertEquals(2L, new Coverage().factorial(2));
  }
}

Google's Testing Blog has a very good post on code coverage; it's worth reading it if you haven't already.

Why social?

I was 12 or 13 when Badsha was released.  A few weeks after the movie release, I went to Tirunelveli with my father.  We were there for some work, which got over by afternoon.  Before returning to Kovilpatti (where we were living then) my father and I went to watch a movie.

"Shall we go watch Sadhi Leelavathi?" my father asked me.  But I wanted to watch Badsha.  Not because I liked Rajini Kanth.  In fact, I have never liked him.  Even as a kid I liked Kamal Hassan more than Rajini Kanth.  My father of course knew better and we went to Sadhi Leelavathi.  The movie was hilarious, but I was probably the only person who didn't laugh in the theater.  When I saw Sadhi Leelavathi later on, after I was over with being pissed with my father for not taking me to Badsha, I really loved it.  But on that day, I wanted to watch Badsha first because all my friends had seen that movie and they were all talking about it in the class.

Likewise, I haven't seen many movies in IMDB's top 250 list.  But today I watched Loins of Punjab because my friend Chenthil suggested it (and loved the movie, by the way).  Only now I understand why "social" is such a buzzword and every company wants to make their products more social.  Earlier maybe social wasn't possible, or no one thought about it.  Now, we don't care much what Experts Opinions are, but we want to what our Friends Opinions are.  I must say I am liking this change.