Monday, January 31, 2005


Sagar and me had a glider building competition here at ThoughtWorks. :) We are planning to fly it (if these things fly) and the Winner gets a "Death by Chocolate" .. Yumm Yumm .. I can almost taste it :-)

We just finished gluing all the parts after spending 4 finger-breaking hours sandpapering the balsa wood to give it the required aero Dynamics.

Snaps here

Sunday, January 30, 2005

Knots and Crosses.

Hari was recently showing me some Knots-and-Crosses implementation he had coded. He talked about how his players had a Strategy injected into them while they were created, so that the game playing logic was kind of pluggable.

Sounded damn interesting.

So I decided to code my own implementation of Knots-and-Crosses. And its been a pretty interesting so far. Its nice to see how simple problems like this can throw a zillion design decisions at you. Very interesting to see how an Object model comes out of such an exercise.

After 3-4 stabs at this and with some design changes, I have come at this object model.

The objects that I have are


Game: basically you can register 2 players and a board with the game. And the game will alternate the players and inform the players that they can make their move.
Board: is pretty dumb. You can mark a location on the board. But the board can also return the consequence of a particular move.
Consequence: copied this Term from Haris Object model, cause it sounded sooo interesting :), but I think the behaviour is different. Basically after a move you can get the consequence of that move from the board and you can perform various queries on it.
Player: As of now I dont have any interesting behaviour here. Like Hari's model, I want to be able to plug in a Strategy that the player can use to play an intelligent game.

Looks a little bloated. Have to see if I can fine tune this.
Tomorrow Hari and me will be swapping notes on how we are proceeding with our implementations.

Saturday, January 29, 2005

my set of Links

Never had the time to checkout what this was all about. And it looked to silly to do all this just for maintaining Book marks.

You can install an awesome extension for FireFox after which its damn easy to work with

Friday, January 28, 2005

Beautiful !

Nice article. Check it out.

Library Management Tool <-> Avyakta

Avyakta - According to Suresh it means "Formless" which is a very apt name for our Library management Project as of now :-)

So along with the code-name of Avyakta we also made some kind of progress today.

Finally got the project onto CVS !!! .. Yaaaaaaaaaayy... turned out to be damn easy once you knew exactly what has to be done :) . Gabbar was walking along when I pulled him to help me out and in 15 mins Avyakta was sitting on Jhakkas (our server with the CVS repository).

So CVS is ready.

Figured out a lil but more about WebWorks. Pretty interesting. Have to try out stuff this weekend and maybe blog on it on monday.

Also stumbled onto two other Open Source tools - Site Mesh and Lucene that i want to try out on this project.

Site Mesh is an Open Source tool which uses the decorator pattern to make managing web content easier. Nice concept looks pretty simple to use.
Lucene is another Open Source tool that provides search capability. Havent read much about it, but whatever little I have read about it sounds good.

So two more tools to check out.

Thursday, January 27, 2005

Library Management Project update.

Not much progress on this front.
We havent had time to sit down and do/read/try out what we want/have/supposed to do.

Am doing some general reading up on WebWork. Picked up a book "Java Open Source Programming" that was lying around in office. Must say the section on WebWork has been written pretty well. Past few days I have been trying to get some good tutorials off the net that explain a lil bit more about WebWorks than just saying that its THE most amazing tool to use. But this book talks about XWork first and then builds on it to explain about WebWork. Pretty neat !!

Bugged Ajey and got access to a CVS repository here on Jakkhas. Tried setting up a CVS for our project. Failed miserably !!! ... arrggggghh

I always wondered how big projects (like the one that Im in currently) actually started out. How were all the initial decisions made ? How were the first few lines of code written ? how did things go from there ? ... this experiment of ours is giving me an insight into that process albeit on a very small scale. But interesting all the same.

Im waiting for the day when we will have cards to play and are actually doing some development work. Rather than have just a few guys/gals do this. I want to try something different. Like check in all the cards that we want to play into CVS and anyone who wants to contribute can pitch in, sign up for a card, and check in that funcitonality. So suppose some one is feeling like he has not coded much on a particular day and wants to code, refactor, bitch about code .. well they are welcome to contribute. :-)

But before that we have tons of stuff to do

- Jayanthan has actually written some amazing stories. But they are too course grained to be called Story cards. So we have to get some kind hearted BA here to write actual story cards. Maybe we can push it as practise cards on to some unsuspecting soul ;-)
- Familiarize ourselves with stuff that were planning to use - hibernate, WebWork and Velocity I think (as of now)
- Set up the CVS for the project
- Set up Continuous Integration. Chris suggested Damage Control as it was much easier to use.

Thats all I can think of.
This is going to be one helluva learning experience. (if we actually get around to doing something !!)

Thought For the Day !!!

"One more hack and were done !!! " - hehe

Tuesday, January 25, 2005

Statics ? Bad

Ohhhh .. I get it ..
Statics kind of reduce the object orientedness of an Object oriented design.

"static object references and methods are not elements of pure object-orientation, but they are often required for practical, convenience and speed reasons"

a nice article on Statics and Singletons. Somethings I had never thought of before
- A Static is not a reusable entity. Hence it is not garbage collected. So we have to make sure our static classes are not Resource Hogs !!!
- Static variable are lost when they are serialized

Monday, January 24, 2005

Library Management System

A few of us at ThoughtWorks have decided to bite more than what we can chew.
We decided to put together a Library Management System for our library here.
Basically to figure out how a web based application works. I have never worked in a project from its inception. So I am waiting to see how different parts of a project all fit together. As of now the project that Im working on is too big for me to figure out how all the parts fit together.

We had no idea about how to start this damn thing. So we spoke to Chris and he gave us some directions. We decided to use Hibernate as the O/R Mapping layer. WebWorks and Velocity to handle the Web part of the application and Java of course. Database not yet sure. But I guess MySQL would be a good choice.

We also spoke to Naresh and got info on how to set up a project on a local CVS at ThoughtWorks.

Things are moving at a painfully slow pace. But i guess thats the norm than the exception.

Maturity ??

some time back adding code excited me
now removing code excites me


Embarrassing !!!!

public class TestingPassByValue {

public static void main(String[] args) {
String object1 = "Hello";

private static void changeAndDisplay(String object1) {
object1 = "Changed Hello";

private static void display(String object1) {

Changed Hello

Had to think why this was the case. I mean In Java Objects are passed around by Reference right !!!! and primitives are passed by Value.

Well the Culprit lies in that sentence. In Java Objects are passed by Reference, but the problem is that the Objects themselves are not passed around, rather its the reference thats passed around. And the reference variables (primitives themselves) are passed by value.

So basically everything in Java is passed by Value, and objects being passed by reference is just a side effect ;-) ... Basics .. tch tch

Sunday, January 23, 2005

JUnit recipes

Was reading this book. Read a few chapters and came up with some weirdly interesting stuff.

The JUnit framework uses Errors to indicate if the Asserts Fail !! .. Not exceptions but Errors. An AssertionFailedError to be precise. For 2 reasons
- Errors are Unchecked
- We could have also used a unchecked exception, but then these are also thrown by the program that we are testing. So to differentiate who (the program or the test code) is actually throwing the unchecked exception JUnit throws an Error.

So basically there are 2 scenarios. We have an Assertion that has Failed and we have a program Error. The first is indicated by an Error being thrown by the JUnit framework and the second the program throwing an Exception.

Now the weird part is
the failing Assertion throws an Error but this is a Failure scenario from JUnits perspective
and Program Error throws an Exception but is a Error scenario from JUnits perspective

Striving to confuse :-)

Wiproed or Infoscised !!!!

The Last staff meeting here kind of made me think of 2 new words. Wiproed and Infoscised. ;-)

Saturday, January 22, 2005

Office Interviews

Recently I started taking office interviews. I have paired with some 6-7 people on office interviews and its been on helluva experience. Each office interview has been an awesome learning experience. PeopleWise as well as Technically.

Recently Gabbar a.k.a Shreekanth (spl ?) and me were interviewing this guy and we were generally talking about JUnit and suddenly Gabbar asked this dude to write a JUnit framework. Brilliant.

JUnit has a simple concept, powerful but simple. At the same time most people never look or think what goes on behind the running of a JUnit test. Before this interview I had never looked at the code, so as this dude was thinking about it I was also kinda thinking how JUnit might have done things internally and it was a pretty interesting experience. The candidate was kind of stumped though :). But I felt this was a nice question to ask at interviews as you actually get some code out of the other person, you could evaluate how a person could think thru a new problem, a problem that he/she was familiar with so you don't have to waste your time explaining things. And at the same time its an interesting problem.

Recently we were taking a phone screen and we were talking about Strings and String Buffers. Suresh asked when would we conciously use Strings in our applications ? Consider we have a Financial Application which passes around the Account Number. Now if this is a String then we are assured of its immutability, hence we can prevent hackers from modifying the Account number and performing operations with the Application using the compromised account number. I hadent thought of this use of Immutable objects. :-) .. like I said Phone screens and Office interviews have been pretty interesting.

At a time when ThoughtWorks India is growing at the rate it is, I feel its imperative that we hire the best so that it can hopefully balance out the problems that sudden growth brings to a small company. Till a few days back I used to feel that we can get people who "will-get-there" and hope that they do, but I no longer subscribe to that. Let us grow, but with the best.

Home Brewed Iterator !!!

Somehow I seem to be fascinated by an Iterator ;-)
So I decided to google for it and these were the phrases I gathered from the web

- is an extremely powerful interface for accessing items from a collection one item at a time.
- it is a looping construct where you don't need to know the data structure in order to loop over it.
- it is separate from the collection itself (side benefit - allows more than 1 iterator to exist at a time !!)

humm ... What the heck. I already knew all this. Decided that I needed another approach to know it better.
So fired up my trusty IntelliJ IDE and decided to make my own iterator for my own collection object.

I decided that "MyContainer" would somehow return a "MyContainerIterator" when I asked for an iterator. MyContainer would implement the collection using an ArrayList internally. MyContainerIterator would implement the Iterator interface.

This was my Test Class

// job: Understands how myContainer and myContainerIterator work and verifies it
public class IteratorTest extends TestCase {
private MyContainer myContainer;

protected void setUp() throws Exception {
myContainer = new MyContainer();

public void testCreateIteratorReturnsAnIterator() {

public void testAddingToMyContainer() {
assertEquals("Hello", myContainer.get(0));

public void testIteratorWorksWithMultipleAdditions() {
Iterator iterator = myContainer.iterator();


My Collection class

// Job: Understands a collection
public class MyContainer {
private List storage = new ArrayList();

public void add(Object s) {

public Object get(int i) {
return storage.get(i);

Iterator iterator() {
return new MyContainerIterator(storage);


My Iterator

//job: Understands how to traverse over a MyContainer Collection
public class MyContainerIterator implements Iterator {
private List storage;
int index;

public MyContainerIterator(List storage) { = storage;

public boolean hasNext() {
return index < storage.size();

public Object next() {
return storage.get(index++);

public void remove() {

That was a pretty interesting exercise.


a small modification

I just showed this piece of code to Suresh and we talked about quite a few modifications to this code. This was one of them

// Job: Understands a collection
public class MyContainer {
private List storage = new ArrayList();

public void add(Object s) {

public Object get(int i) {
return storage.get(i);

Iterator iterator() {
return new MyContainerIterator(storage);

//job: Understands how to traverse over a MyContainer Collection
private class MyContainerIterator implements Iterator {
private List storage;
int index;

public MyContainerIterator(List storage) { = storage;

public boolean hasNext() {
return index < storage.size();

public Object next() {
return storage.get(index++);

public void remove() {

By Making the Iterator an Inner Class of the collection itself, we felt it exhibhited better encapsulation as this iterator implementation can be optimised for the type of Collection that it supports and just expose an Iterator interface.

The other things that we spoke about mainly revolved around the inefficieny of this whole thing. But then I wrote it to see how iterators worked.

But another interesting case of how pair programming would have worked, had Suresh and myself paired on this exercise. This design would have come out much earlier instead of the code review kind of session after the code was written.

Friday, January 21, 2005

SICP - Overview and Introduction to LISP ( lecture 2A)

Higher Order Procedures

This lecture started out with identifying common stuff between computations.
The professor talked about how we should come up with an abstraction whenever we have a bunch of of things that are identical, so that we can reuse this common stuff. Awesome examples !

I thought this was pretty neat cause this is the second lecture and were already talking about something practical like reuse of code, and I haven't yet seen a print statement nor have I seen any loop structure. My introduction to Computer science was a language and its syntax rather than the concepts like abstraction, reuse etc that are being exposed in these lectures.

Anyways finally saw how a variable was defined in LISP. Same as a method
(define variable_name .00001) and we have a variable named "variable_name"
And both variables and procedures could be passed as parameters to another procedure. Weirdly neat !!

The concept on an Anonymous procedure was brought out. Something like an anonymous inner class in Java. But this was kinda confusing.

Finally figured out what a Higher Order Procedure meant: They are procedures that take procedural arguments and produce procedural values to help abstract and clarify some complex problems !!! That simple .. :-)

The last few programs towards the end of the lecture were kind of OHT (over head transfer) :) ... So sat watching the video with glassy eyes hoping to gather the gist of the lecture rather than try and figure out what the mass of brackets were trying to achieve. Gknee had warned me that the lectures scale up in complexity pretty soon. Looks like that has already started. Initially the lectures are like kids play .. But soon, if your not careful U can get lost in the bunch of brackets that are thrown at you.

Another interesting point that the professor made was the difference between functions and procedures.
Functions are mathematical terms which map a value onto another value.
Procedures are computational terms which compute functions.
We often tend to use functions and procedures to mean the same i.e. procedures.

"Wishful thinking is central to any engineering field, especially computer science" - professor

Thursday, January 20, 2005

SICP - Overview and Introduction to LISP ( lecture 1B)

Well this lecture was pretty interesting.

Initally the professor spoke about the substitution model.

Two very interesting programs for addition of 2 numbers were introduced. Using these programs the concepts of Iterative and Recursive processes were introduced. Was very interesting.

Iterative Process - X
Time Complexity - O(X)
Space Complexity - O(1)

Recursive Process - X
Time Complexity - O(X)
Space Complexity - O(X)
Where X is some parameter that is used in the computation process.

Fibonacci series were introduced.

The last part was on the problem of "The towers of Hanoi". Long time since i have seen this problem. I had seen this last in my third semester of Engineering. We had hurridly hacked together a C programm in a C++ environment and subject :-)) .. Anyways it was interesting how the concept of recursion was introduced here. There were props and the code to solve this was very interesting. Somehow I felt that LISP kind of directly addressed the problem we have on hand with very little emphasis on the structure of code. Ya the code was kinda wierd with tons of parenthesis, but succinct at the same time. We could just think of the problem that we were trying to solve rather than worry about whether the syntax for main() was right.

The solution for the Towers of Hanoi was done using a recursive process, and we were left with an excersise to try and see if we can do this the iterative way !!!

There was an interesting line that the professor said - " The key to solving complicated problems is to know what not to look at".
I thought this was a nice and simple way of saying what abstraction was all about, a very powerful statement at the same time cause this is a very important way of looking at problems.

Things are definitely picking up !!! As far as I can remember I think i remained conciousness thru the lecture :-)

SICP - Overview and Introduction to LISP ( lecture 1A)

Down with Viral Fever.
Decided to check out the SICP (Structure and Intepretations of Computer Programs) lectures. Gknee and Yogi were raving about them, and LISP was supposed to be THE thing to learn. So decided to find out what the big deal was :-)

Here goes !!!
Initially it was pretty boring. Yaaaawn ..

The prof was talking about the very basics of computing. But it was interesting in some ways, cause this was a video shoot of a class room teaching. It was really funny to see these hippie looking students, some of which were looking like zombies. Hehe .. reminded me of some lectures that I have sat thru in Engineering :-)

The thick Yellow piece of Chalk that the professor was using looked really good fun to use :-)

Initially the lecturer spoke about how Computer Science has nothing to do with a Computer. What he meant was Computer science was the essence of this science where as the Computer was basically a tool that we used. Yawn .. .

Learnt about some primitive elements in LISP. like + - < * and some primitive data like numbers etc ... Yawn ...

Learnt means of combination like using if() Yawn ...

also was introduced to the basic means of abstraction, and how to create methods using the define statement.

Yawn .. yawn .. Y.A.W.N !!!!

at the end of this session a slow moving electric impulse moves across my hibernating mind and is carrying the message "Is Gknee out of His mind ??"

practise .. practise .. practise..

I got a Laptop from ThoughtWorks recently and I feel its an awesome inventment for the company.

Well its simple actually. (Before U think im Cucoo or something !!)

Say your learning an musical instrument. Its only when you have the instrument at home, do you actually tend to spend time with that instrument. Every few minutes that you are free you are bound to pick it up and play for sometime And this is when you become good. When you spend time with that instrument.

Same difference ;-)

Ever since i got the laptop i have been able to spend so much more time on it, which kind of gives the same effect as spending more time on the musical instrument.

I feel programmers are not just made. You are not born a master programmer. You have to move from a Journey-man to the Master stage and everyone has to go thru this stage. Just that some might be faster and others slower depending upon the amount of time they spend on this(not the only reason of course). So by giving everyone laptops the company is bound to nurture more to-be-Masters which is awesome for any company.

This was just a thought :-) ..

ThoughtWork is Planing to give everyone a laptop soon, so i guess I can wait and see if there is any grain of truth in what I feel or its allbullshit !!!

ps: Java Programmers arent Born Nice read !!!

Test Driven Development !!!

Test Driven development .. ya ya .. ThoughtWorks does Things the agile way and TDD is one of the hallowed practices that we try and follow. I have heard tons of stuff about TDD .. but only recenty did i have an AhA moment with TDD ..

I was working with this rather difficult piece of code which had lotsa calculations in it and I just was not able to get it right .. I went thru the cycle .. try to fix .. build .. start up application and see if my fix worked .. but for some strange reason it kept failing ..

I thought of adding a test for this, but being the lazy ass that i am .. i decided to just try it the non-test way once more .. and the "once more" kept getting pushed.

Finally my friend Suresh (fed up of seeing me waste my time like this) told me to write a test for this. So I did that .. and trust me in 15 mins I had solved the problem !!! .. 15 mins ..

Going the Test First way I noticed many things

- the cycle of fixing the issue is much faster, as a test is well just a test. U dont have to compile and build the whole app and start it and go thru the GUI to get to the issue. Using the test U get right to the core of the issue. So it makes a huge difference.
- this way I have a test in place. So even if Im damn lazy .. i have tests surrounding my code.
- no way some one can break my code as the tests will prevent that. For example last week I was fixing a bug in some obscure part of the code. The fix was simple ( which kind of triggered alarms ) and I checked in, and promptly broke the build. I had broken a ton of unit tests. When I looked at the tests I figured out that this 'bug' was not a 'bug'. It was a piece of intended funtionality. So there !!
- Cleaner code and better design of my code. This is one thing that I have consistently seen when I use TDD.
- I can express my intent to a certain extent thru the tests.
- I always like the part when i run tests on the code and see the green bar, Gives me a sence of accomplishment and confidence.
- and doing things the TDD way is real fun. No doubt its a lil more difficult. But that only the first test that takes so much time. After that its just adding test .. adding functionality .. adding test .. adding functionality. some where along this process .. u dont like the look of the code .. go on a refactoring spree .. change every god damn thing .. and just make sure u get a green bar at the end of it and we're safe.
Beautiful !!!!! :-)