Monday, December 20, 2004

Personal Corporate blogs and their effects: Part 2

There seems to be a lot of churnign in the ocean of corporate blogs. Lately Scoble whom I used to respect seems to have strayed from his path. He not only posted a post which seemed mildly out-of-place, given that it was deeply critical of his own company but also using pretty strong language, but it also generated enough emotions among people associated with his own company (MS). It has also generated a post on on corporateblogging.info site. I think this time Scoble deserves all that he gets. I truly believe that if one throws shit up on the fan, shit rains down.

Sadly, increasingly Scoble's blog has been reduced to just a collection of links from other prominent bloggers without much original well thought-out content.

Friday, December 03, 2004

statics and threads in java...

I was asked by someone recently about the evils of static members. I talked about lack of state in these variables, overriding being not possible, etc. But the other person asked me how statics were evil in the context of Threads. I told him that if a static method is synchronized, then only one static synchronized method in the class will be accessible at any point of time to the threads. He was still not convinced though. He told me that if a static synchronized method is accessed by a thread, then even non-static synchronized methods are not available to other threads.

I was surprised. My understanding of threads was that, if a method is synchronized, then the monitor of "this" has to be obtained by the calling thread before it enters that method. However, if the method is static then the monitor of the Class instance (this.class) has to be obtained. So if there were two threads and one of them is accessing a non-static synchronized method, and the other is accessing a static synchronized method, both threads should comfortably have access to those methods.

I tried out a sample. Here's the code for the same. Try out this sample and see for yourself.
Correct me if my understanding of threads is wrong.







public class StaticsAndThreadsTest
{
  public static void main(String[] args)
  {
      class Runner implements Runnable
      {
        TestObject obj = new TestObject("TestObject");
        private int code;
        public Runner(int i)
        {
          this.code = i;
        }

        public void run()
        {
          if(code%!= 0)
          {
            TestObject.staticallyDoingSomething();
            TestObject.staticallyDoingSomething();
          }
          else
          {
            obj.doSomething();
            obj.doSomething();
          }
        }
      };

    for(int i=0; i<10; i++)
    {
      Thread thrd = new Thread(new Runner(i));
      thrd.start();
    }
  }
}

class TestObject
{
  private String name;
  public TestObject(String name)
  {
    this.name = name;
  }

  public synchronized void doSomething()
  {
    System.out.println("Thread " + Thread.currentThread().getName() ": doing something.");
  }

  public static synchronized void staticallyDoingSomething()
  {
    try
    {
      System.out.println("Thread " + Thread.currentThread().getName() ": statically doing something.");
      Thread.sleep(1000);
    }
    catch(InterruptedException iex)
    {
    }

  }
}


Thursday, December 02, 2004

Test Driven Development(TDD) or Test First Development(TFD)

Suresh and I have always been wondering about what is the most practical way of development: TDD or TFD ? We both agree that TDD is the best way theoretically. But in practice how would one go about writing tests for all possible cases, including the negative ones and then write code. The amount of tests written would be phenomenal. Then we took an evolutionary step and agreed that maybe all possible tests need not be written, but only those steps which are relevant to the class under consideration and which we feel are important need to be concentrated on. This leads to the problem of missing out crucial tests which were not apparent to the developers at that time. Therein lies the crux of the matter. How practical should one go before one turns out wrong and how theoretical should one go before one turns unacceptably inefficient.

We did pair programming on a not-so-complicated problem and started out with TDD. Over time with the deadline drawing near we deviated from strict TDD and ended up doing TFD. But at one point, because we had not written the test for a particular side-effect of a method our code passed all tests but failed to give the correct response. That was the time I was truly convinced about the truth behind TDD (Suresh was wise enough to be a believer from the beginning). But I still don't know how practical will TDD be in real life.

Now through Suresh I have heard of a discussion he had with a colleague of his where they concluded that beyond a point when the complexity of the code prevents one from writing proper tests, code should be refactored. This is basically TDD. I totally agree with this thought. This means that we end up molding the code for passing tests rather than developing code and writing tests to check the code. Since this is the basis of TDD (at least as I understand it), I guess what we had an discussion about was for projects which had not undergone several iterations of development. Once the process of development matures TDD is the way to go.

I have become a total convert. Long live TDD !!

Wednesday, December 01, 2004

Patterns of architecture (No its not a enterprise design patterns discussion)

Increasingly buildings which are built in a urban or semi-urban are modeled according to the changing needs of the tenants, both for corporate or individuals. Things like a false ceiling (in India this is not a common thing), modularized work spaces, structurally changeable bay areas, etc are increasingly becoming common. This lead me to a thought. This change is a leap in evolution in the art of architecture (I mean in the civil engineering sense and not in the software engineering sense). This branch of engineering which has been around for centuries (since man/homo sapiens/whatever) has started evolving in this direction only after say 5000 years (assuming the pyramids were built around 3000 BC [A nice article on how and when the pyramids were built]). But in the software engineering discipline with the advent of loosely coupled enterprise applications we can see this evolution happening in just under 50 years (assuming 1955 as the start date of software engineering [wikipedia entry for Software Engineering]). I believe these two evolutions are comparable as the basis of thought behind both the evolutions is flexibility and exntensibility.

Now one could argue that such practices have been in the architecting or civil engineering for quite sometime but then it is only now that they are being manifested in such a popular manner. The same thing could be said for software engineering if we assume that RPCs which have been around for sometime do provide the required loose coupling. But it is only now with webservices (explaining my understanding and thoughts on webservices is a topic for another post) that true loose coupling is being embraced.