Sunday, May 24, 2009

How to be a better software developer

This post lists some techniques that will help you become a better programmer.
  • Read code written by other developers. Preferably, code written by exceptional developers. There is tons of good quality code available online (eg. Linux, Google Web Toolkit, and many other open source projects).
  • Have your code reviewed by peers. This ensures that your code can be easily understood by someone other than you. Your code reviewer is also very likely to point out bugs, and may point out how to simplify code using unfamiliar language constructs or API libraries. Finally, this reduces the likelihood of "shortcuts" and hacks in your code.
  • Submit small CLs. When your CL is over 500 lines, it's difficult to review and it's difficult to defend it's correctness.
That's it for now. More in future posts.

Tuesday, May 22, 2007

Outputing to console every command of a bash script

To make bash output every executed command of a script to console, prefix the script with the following line:

#!/bin/bash -v

Tuesday, April 10, 2007

Prompting user for password in a shell script

echo "Enter Password"

# disable standard output
stty -echo

#prompt for password.
read password

#enable standard output
stty echo

echo $password

Wednesday, April 04, 2007

Redirecting standard output to file and console at the same time

Command Name: tee
Sample Usage: ls 2>&1 | tee ~/ls_output

Note: 2>&1 redirects standard error to standard output

Monday, February 26, 2007

MySQL Foreign Key Constraint Failure

When deleting a row from a table, MySQL might give a foreign key constraint failure. To find out what is the problem one can execute the following command:

SHOW INNODB STATUS;

Friday, February 23, 2007

Useful UNIX Commands

I will continuously update this posting with useful UNIX commands.

"tac" - reverses a list or a file.
"strace" - traces system calls of a process. Example: "strace -t -T -v -o OUTPUT java".

Thursday, January 25, 2007

Java fully qualified import

In Java, one can import all the classes in package using "import a.b.c*" form of import statement. It is also possible to import classes individually using "import a.b.c.ClassName" form of import statement.

Typically, the latter method is preferred, since it improves readability: in order to determine the package that a class belongs to, the reader just needs to look at the import statements at the top of the file.

However there is another important reason to always choose latter method. Let's say you use import a.b.* form to import all classes from packages X and Y, and package Y contains class Z that is used by your class. Time passes, and class with name Z is added to package X as well. Suddenly, your class doesn't compile because the compiler is unable to determine which package class Z comes from.

Thus, it is always preferable to import every class individually rather than all classes in a package.