Week 3

This week, more than anything else, I realized that never procrastinate. Though, once in a while, every week I do take this resolution of finishing my things (assignments, and projects, etc.) before time, but then... :(

This week most of my focus, outside the class, was on the project 3. The project was about implementing the Gregorian Calendar, and developing a class that supports Date operations such as finding the date after a given number of days, or number of days between two given dates, and similarly related operations. As Professor Downing advised, the initial plan was to just develop a modest code that would pass the basic test cases. But, even the algorithm for converting the date to number of days would fail. Oh, and on Friday was the first exam.

Nevertheless, I would say, the best part of the project was the algorithm and the mathematics behind it to convert days to date and vice-versa, so as to suffice the condition of O(1) time and space requirements. Having figured out the mathematics, we now were facing the not-so-understandable concepts of templates, and references to carry out the operations. While compiling, I came across an error like "no matching function to the call..." and it was quite interesting that the keyword "const" fixed it all. Consequently, the result of all the procrastination + the subtleties of C++ was the extra hours that we had to put to have the code working.

In essence, however, the project was interesting and I learned a lot.

Pair Programming

This blog entry summarizes the key points of the paper by Laurie A. Williams and Robert R. Kessler which is about Pair Programming. "Pair programming is a style of programming in which two programmers work side-by-side at one computer, continuously collaborating on the same design, algorithm, code or test." It is one of the core practices of eXtreme Progamming (XP).

We as programmers are conditioned to work alone, as we are too much under the impression that thinking independently will allow us to formulate our deeply-concentrated thoughts better. Studies, however, show that pair programming allows us to become more efficient programmers.

The key importance lies in the below mentioned attributes:
1) Continuous code review by person watching over the shoulders
2) Exchange of ideas which could disclose possible flaws, and bring about improvements
3) Efficient, and a greater confidence in the solution
4) High level of code quality which is nearly bug free
5) Enjoyable experience

The paper then talks about the important principles of pair programming. Here are some of those:

SHARE EVERYTHING and PLAY FAIR
Two programmers are assigned to produce one artifact - design, algorithm, or program, etc. Both partners are working actively, even though one is putting the ideas together whether in a code, or in a design on the paper; the other partner on the other hand is continuously reviewing the work. Both are equally creditable or liable.

BEING LESS OF A SLACKER
I realized that I check my Facebook account, and dozens of email accounts quite frequently even though I know I am expecting nothing but tonnes of spams. And when I am saying frequently, I mean it... I mean at least once in every 15-20 minutes. While, working over the past two projects, I realized that I barely check my accounts while I am working with my partner, unless we are taking a break. In essence, I am much more focused and dedicated, and being less of a slacker :).

EXCHANGE OF IDEAS
Honestly, I have learned a lot over the past 3 weeks. The way my partner thinks, motivates me to think differently, allows me to think out of my own little box of ideology. Continuous discussion, and constructive arguments are the best training, I believe.

DON'T TAKE THINGS TOO SERIOUSLY
"Ego-less programming" as the mentioned in the paper, is the key to fully take the advantage of the pair programming. The arguments should be taken as a resource to further hone an individual's programming skills.

WASH YOUR HANDS OFF SKEPTICISM BEFORE YOU START
There should be no scope of skepticism with pair programming; if something looks confusing or non-understandable clarify the doubts. But, trust your partner. Engage in constructive arguments if need be so. One idea is that the outcome of a union of team members is more than the disjoint sets of members, contrary to traditional set theory. As experiences have shown, a pair produces more than twice as many solutions than the two working independently.

FLUSH/REVIEW WORK DONE INDEPENDENTLY
We have other commitments of time and we need to be working on some tasks independently, or just for some deep-concentration thinking. However, it is the best practice to review the work done independently together with your partner; it could possibly disclose a plethora of subtleties.

And finally,
ALL WORK and NO PLAY MAKES everyone dull... so take breaks occasionally.

For cost/benefit analysis of the Pair Programming methodology, I came across a paper by Alistair Cockburn, and Laurie Williams.

Week 2

This week, I witnessed a plethora of interesting subtleties of C++:
i) the pointers, and the references;
ii) types of variables
iii) templates

It's interesting how placement of '&' and '*' can give a whole different meaning to variables. For example,


int i = 2;
int* p = j; // does not compile
int* p = &j; /* initializes a pointer 'p' pointing to integer 'j' */


/*increments the memory address which could lead to illegal memory access */
++p;

//increments j
++*p;


Now consider,

int k = 4;
int& r = k; /* r serves as an alias of k */

//same as ++k
++r;


Using '&' for references frees the programmer from de-referencing the variable like in pointers. However, once the reference is defined, it is glued to the variable it references; while the pointer can be changed to point to other variable (if not declared as constant).

Things become interesting when using '&' and '*' together. While, int&* x isn't valid, but


int i = 2;
int* p = i;
int*& r = p; //alias for pointer 'p'


Next, we studied about different types of variables, and compared their scopes, lifetimes, and time-line when they are allocated, and initialized. "non-static local variable" and "static local variable" both differ except in terms of their scope. Contrarily, "non-static global variable" and "static global variable" differ only in their scopes. "Non-static global variable" has the scope of whole program, while "static global variable" has the file scope. The program will compile even if a static variable is used in other file using extern, but will fail during the linkage.


C++ has a powerful feature of creating templates. But with power, comes the responsibility; and here the responsibility is of the programmer to fully understand how to create classes considering the types of variables and their instances to be created. For example,


template <typename T>
struct A {
static T sv0; // creates one sv0 per T
static int sv1; // still creates one sv1 per T
T v0; // create 1 v0 per instance of A
}

Finally, we studied how different function declaration give or don't give access to the original data.

For example,
void f(int v) {++v;} // creates a local copy of the argument
void g(int* p) {++*p;} // changes the original data
void h(int& r) {++r;} // changes the original data

Week 1 - CS378

Aah haa, the class had just started and the first week is already over. Oh! And what a class strength, quite contrary to what I expected. The time I was registering for the course, I along with other students was skeptic if we'll have the privilege of continuing with the class. And now, the class is full of inquisitive students, and the interesting interaction with so much to learn. As Professor Downing mentioned, learning is a continuous process.

I have had few programming classes before, but the concepts that I have started to learn from the day 1 of class I had no idea of those before. The fundamentals of l-value and r-value, the return types, and return values are now much more clear. The quizzes that started from the second class helped me a lot to understand the material that was taught in the previous class.

During the first week, we got our first project which was to be done collaboratively with other partner. The first project itself prooved to be an excellent source of learning a whole new paradigm of programming aspects, and software management. It was the first time, I was exposed to Google Projects, and working with subversion and issue tracking. As a part of the project, we were to build the unit test cases as well. I was quite surprised as how assertion and unit cases can disclose some obscure bugs that would otherwise have been so difficult to track and debug.

In the last classes, we learned about formatting, and other subtleties of C++. We started with a topic on throwing exceptions, and we’ll be continuing with it the coming week. I definitely look forward to the following weeks.