University of Moratuwa tops GSOC 2008

I just got to know that my University tops the charts of participants at the Google Summer of Code 2008. Thought I have never been a GSoCer (that’s ow they call the participants), I have always been a great admirer of this competition. The best part this year is a lot of my batch mates are participating, and I wish all of them ‘Good Luck’.

By the way, guys we can decide on the day for your treats after you receive your first payments ;)

For more details read: Google Open Source Blog: This Week’s Top 10′s: Universities for Google Summer of Code 2008

Also I hope we could expect more guys coming in for next year as well…!

Posted in Tech Notes | 2 Comments

Luntbuild : Introduction

This is going to be another short series (2-3 posts) about a build automation tool. I got using this during my internship at WaveNET. I don’t this this is going to be a very useful post to many ( I here some one saying when I write useful posts :) ), but it could be at least a reference for some one out there or to me some day.

Introduction

Luntbuild is a powerful build automation and management tool. Continuous Integration or nightly builds can be easily set using a clean web interface. Executed builds are well managed using functions such as search, categorization, promotion, patching, deletion, etc. It also acts as a central build artifacts repository and download area for your whole team.

Why Luntbuild?

You may ask why Luntbuild, while there are already many good build automation tools such as Cruise Control, Anthill, and others. Our answer is:

  • Luntbuild aims at not only being build automation, but also build management system. Executed builds can be categorized, promoted, searched, patched, deleted, etc. This is very important for a nightly builds or Continuous Integration builds, which generate many builds over time.
  • Luntbuild utilizes the project/schedule concept to easily provide build support for parallel development.
  • No configuration files, all jobs are done using web interface. You can set your Luntbuild system in less than thirty minutes.

Luntbuild makes advantage of quite a few open source libraries and frameworks listed here.

Luntbuild homepage http://luntbuild.javaforge.com/

What Luntbuild does?

Basic unit of work in Luntbuild is a build. Build execution is triggered either by a schedule or it can be started manually. A build in Luntbuild performs following steps:

  1. Checks out source code from the Version Control System(s) (VCS).
  2. Labels the current source code based on the current build version.
  3. Runs an Ant/Maven/Command/Rake build script in the source tree.
  4. Runs an Ant/Maven/Command/Rake post build script in the source tree.
  5. Publishes the build log and other build artifacts.

Build configuration, monitoring, and access to the build artifacts are all done using an intuitive web interface. Development and testing teams will have a central area to access the build information.

We shall see basic installation steps in the next post.

Posted in Tech Notes | Tagged , , | Comments Off

A leader should know how to manage failure

(Former  President of India APJ Abdul Kalam at Wharton India Economic Forum, Philadelphia, March 22, 2008)

Question: Could you give an example, from your own experience, of how leaders should  manage failure?

Kalam: Let me tell you about my experience. In 1973 I became the project director  of India's satellite launch vehicle program, commonly called the SLV-3.  Our goal was to put India's "Rohini" satellite into orbit by 1980. I was  given funds and human resources — but was told clearly that by 1980 we  had to launch the satellite into space. Thousands of people worked  together in scientific and technical teams towards that goal.  

By 1979 — I think the month  was August — we thought we were ready. As the project director, I went to  the control center for the launch. At four minutes before the satellite  launch, the computer began to go through the checklist of items that  needed to be checked. One minute later, the computer program put the  launch on hold; the display showed that some control components were not  in order. My experts — I had four or five of them with me — told me not  to worry; they had done their calculations and there was enough reserve  fuel.

So I bypassed the computer, switched to manual mode, and launched  the rocket. In the first stage, everything worked fine. In the second stage, a problem developed. Instead of the satellite going into orbit, the  whole rocket system plunged into the Bay of Bengal. It was a big failure.  

That day, the chairman of  the Indian Space Research Organization, Prof. Satish Dhawan, had called a  press conference. The launch was at 7:00 am, and the press conference —  where journalists from around the world were present — was at 7:45 am at  ISRO's satellite launch range in Sriharikota [in Andhra Pradesh in  southern India].

Prof. Dhawan, the leader of the organization, conducted  the press conference himself. He took responsibility for the failure — he  said that the team had worked very hard, but that it needed more  technological support. He assured the media that in another year, the team would definitely succeed. Now, I was the project director, and it was my  failure, but instead, he took responsibility for the failure as chairman  of the organization.

The next year, in July 1980,  we tried again to launch the satellite — and this time we succeeded. The  whole nation was jubilant. Again, there was a press conference. Prof.  Dhawan called me aside and told me, "You conduct the press conference  today."

I learned a very important lesson that day. When failure  occurred, the leader of the organization owned that failure. When success  came, he gave it to his team. The best management lesson I have learned  did not come to me from reading a book; it came from that  experience

 

Posted in Random Thoughts | Comments Off

Kulfi – A Short Film

I found this interesting short film, when I was randomly searching on YouTube. This is by some film college students, and seems very promising.

The description on the YouTube page says “‘KULFI’ awarded for The Best Music Score and The Best Cinematography. Directed by Tanmay Shanware. Music by Pankaj – Pushkar.“.

I should try to do something like this soon… :)

Have a look…

Part 1:

Part 2:

Posted in Media | Tagged , | Comments Off

JUnit

Ref:

What is JUnit?

JUnit is a simple, open source framework to write and run repeatable tests. It is an instance of the xUnit architecture for unit testing frameworks. JUnit features include:

  • Assertions for testing expected results
  • Test fixtures for sharing common test data
  • Test runners for running tests

When should tests be written?

Tests should be written before the code. Test-first programming is practiced by only writing new code when an automated test is failing.

Good tests tell you how to best design the system for its intended use. They effectively communicate in an executable format how to use the software. They also prevent tendencies to over-build the system based on speculation. When all the tests pass, you know you're done!

Whenever a customer test fails or a bug is reported, first write the necessary unit test(s) to expose the bug(s), then fix them. This makes it almost impossible for that particular bug to resurface later.

Test-driven development is a lot more fun than writing tests after the code seems to be working. Give it a try!

Basic test template

import org.junit.*;import static org.junit.Assert.*;

public class SampleTest {

    private java.util.List emptyList;

    /**     * Sets up the test fixture.      * (Called before every test case method.)        */    @Before    public void setUp() {        emptyList = new java.util.ArrayList();    }

    /**     * Tears down the test fixture.      * (Called after every test case method.)     */       @After    public void tearDown() {        emptyList = null;    }

    @Test    public void testSomeBehavior() {        assertEquals("Empty list should have 0 elements", 0, emptyList.size());       }

    @Test(expected=IndexOutOfBoundsException.class)    public void testForException() {        Object o = emptyList.get(0);    }}

Handling Exception

* How test that passes when an expected exception is thrown?

Add the optional expected attribute to the @Test annotation. The following is an example test that passes when the expected IndexOutOfBoundsException is raised:

    @Test(expected=IndexOutOfBoundsException.class)    public void testIndexOutOfBoundsException() {        ArrayList emptyList = new ArrayList();	Object o = emptyList.get(0);    }

* How test that fails when an unexpected exception is thrown?

Declare the exception in the throws clause of the test method and don't catch the exception within the test method. Uncaught exceptions will cause the test to fail with an error.

The following is an example test that fails when the IndexOutOfBoundsException is raised:

    @Test    public void testIndexOutOfBoundsExceptionNotRaised()         throws IndexOutOfBoundsException {

        ArrayList emptyList = new ArrayList();        Object o = emptyList.get(0);       }

Assertion Statement Reference

This is a list of the different types of assertion statements that are used to test your code. Any Java data type or object can be used in the statement. These assertions are taken from the JUnit API.

  • assertEquals(expected, actual)
  • assertEquals(message, expected, actual)
  • assertEquals(expected, actual, delta) – used on doubles or floats, where delta is the difference in precision
  • assertEquals(message, expected, actual, delta) – used on doubles or floats, where delta is the difference in precision
  • assertFalse(condition)
  • assertFalse(message, condition)
  • assertNotNull(object)
  • assertNotNull(message, object)
  • assertNotSame(expected, actual)
  • assertNotSame(message, expected, actual)
  • assertNull(object)
  • assertNull(message, object)
  • assertSame(expected, actual)
  • assertSame(message, expected, actual)
  • assertTrue(condition)
  • assertTrue(message, condition)
  • fail()
  • fail(message)
  • failNotEquals(message, expected, actual)
  • failNotSame(message, expected, actual)
  • failSame(message)

Ref:

Pre and Post condition

  • A pre-condition is an expression of type Boolean that should always hold before the execution of the body of the method,conditions for each function that must be true for it to behave correctly
  • A post-condition is an expression of type Boolean that should always hold after the execution of the body of the method,conditional expressions that must be true when a method returns
  • The strategy is to construct a JUnit test case for each accessible method in the class under test, where each test case verifies both the preconditions and postconditions of the method. Example
    public class RangeTest extends TestCase {    private Range mRange;  public RangeTest(String name) {      super(name);    }
    
      protected void setUp() throws Exception {    super.setUp();       mRange = new Range(1, 5);   }
    
      public void testConstructor() {     // pre: aLower < aUpper    try {        new Range(6, 4);      fail("[6,4] should be precluded");    }        catch (AssertionError e) {    }    // pre: aLower == aUpper    new Range(-3, -3);    // post: aLower == getLower()    Assert.assertEquals("[1,5].getLower() should be 1", 1,       mRange.getLower());       // post: aUpper == getUpper()    Assert.assertEquals("[1,5].getUpper() should be 5", 5,       mRange.getUpper());  }
    
      public void testGetLower() {    // pre: object constructed    Assert.assertNotNull("[1,5] could not be constructed", mRange);       // post: getLower() == aLower provided to c'tor     Assert.assertEquals("[1,5].getLower() should be 1", 1,      mRange.getLower());  }
    
      public void testGetUpper() {     // pre: object constructed       Assert.assertNotNull("[1,5] could not be constructed",      mRange);    // post: getUpper() == aUpper provided to c'tor     Assert.assertEquals("[1,5].getUpper() should be 5", 5,         mRange.getUpper());  }
    
      public void testIntersects() {    // pre: anOther !=  null     try {      mRange.intersects(null);      fail("intersects(null) should be precluded");       }    catch (AssertionError e) {    }       // post: true if two ranges have an integer in common      Assert.assertTrue(!mRange.intersects(new Range(-3, -1)));      Assert.assertTrue(!mRange.intersects(new Range(6, 7)));         Assert.assertTrue(!mRange.intersects(new Range(-2, 1)));      Assert.assertTrue(!mRange.intersects(new Range(5, 7)));      Assert.assertTrue(mRange.intersects(new Range(0, 2)));      Assert.assertTrue(mRange.intersects(new Range(3, 4)));         Assert.assertTrue(mRange.intersects(new Range(4, 8)));}}
    
  • If these test cases pass, then we can be confident that all methods in Range are:
  • Checking for violation of their preconditions (and objecting by throwing a Runtime exception of some sort)
  • Adhering to their postconditions.

Ref: http://www.hacknot.info/hacknot/action/showEntry?eid=17

Posted in Tech Notes | Tagged | Comments Off