Test Driven Development

I am very much attracted towards test driven development (TDD). A well made TDD makes sure that your code is solid and will pass the regression test. 30% to 40% project time can be saved using TDD.

JUnit philosophy is the key point here.

“At any point of time, when running a JUnit test code, always GREEN BAR should be displayed”

TDD process consists of

  • Write the test code
  • Run the test
  • Test will fail – RED
  • Now add the real code
  • Run the test
  • Test should pass – GREEN
  • Refactor the code.
  • Re-run the test code
  • Test code should pass – GREEN

Always use stubs and mock object in TDD. This helps for development in isolation and removes dependency on other modules for testing. TDD also makes integration easier.

Always try to follow interface depended development. Uphold the famous design principle “Program to interface and not to implementation”. This helps to replace stubs and mock objects during integration time.

This holds JUnit philosophy. The code will be cleaner and will always be working. Consider a project that is running for 1 year. If TDD is followed in such projects, it always make sure that none of the existing functionality is broken.


VTA Bus…

I love VTA ( Valley Transport Authority ) buses a lot… One day, on my way back to office, I took VTA bus no: 55. Time was around 7:00pm. I need get down at Remington so that I can walk to my home. The next major stop after Remington is Fairoaks, where apartments like Fairoaks West, Arbor Terrace are situated. Indian population is very high in these apartments.

When Remington was reached, the bus stopped and I got down. Then the bus started and then suddenly stopped. The driver came out of the bus and asked.. ” You looks to be an Indian. Lots of Indians stay at Fairoaks… Are you staying at Fairoaks. If so this is not the stop. Fairoaks is next stop…”. I was a lot surprised by the humbleness of the driver and said ” Thanks.. I stay near Remington”.. He said, “Good… Have a great evening”… I wished him back and thanked him for his concerns.

What touched me a lot was his concern for the travelers in the bus. Having stopped the bus, coming out and inquiring… A very good customer care and very humble… These activities brings a lot of good will… Hats off that driver….

Something on Java Byte array Streams…

Handling streams used to be one the good java programming practices. Here are some points quick tips…

  • ByteArrayOutputStream is in memory stream.
  • In ByteArrayOutputStream, the buffer automatically grows as data is written to it.
  • Closing ByteArrayOutputStream has no effects.
  • Methods in ByteArrayOutputStream class can be called after the stream has been closed without generating an IOException.

PPTP command to connect MAC OSX VPN Server

From command line, to connect to MAC OSX VPN Server using PPTP, the following command can be used..

sudo pppd serviceid 2 debug logfile /tmp/ppp.log plugin /System/Library/SystemConfiguration/PPPController.bundle/Contents/PlugIns/PPPDialogs.ppp plugin PPTP.ppp remoteaddress xxxx.yyyy.com redialcount 1 redialtimer 5 idle 1800 mru 1500 mtu 1448 receive-all ipparam novj 0:0 noipdefault ipcp-accept-local ipcp-accept-remote noauth refuse-pap refuse-chap-md5 user myusername password mypassword hide-password noaskpassword mppe-stateless mppe-128 looplocal

To view the log for VPN connection
tail -f /tmp/ppp.log

Stress Test Parameters

The following parameters should be known before stress test is run.

  • Machine configuration of each machine where stress test will be run should be obtained.
  • Number of threads that each stress test case spawns.
  • Sleep time of each thread.
  • Number of use cases tested by the stress test case.
  • JVM heap size of the machine to be stressed.
  • Number of transactions tested in each stress test.
  • Design stress test based on number of users going to use the system per second.
  • Stress test the most used use case separately.

Java Programming Best Practices

Never trust the values returned by other exposed services. Always do a check on the values returned based on the scenario

Always check the pre condition. Make sure pre condition is always satisfied. Check for NULL always. like ask a question, if this argument is null what to do?

Understand which exception is a show stopper and which is not a show stopper. Throw back the exceptions that are show stoppers, log the exceptions that are not show stoppers.

Always explain the pre conditions and post conditions and exception scenarios of a method.

Don trust arrays that a are returned by other methods. Those arrays might contain null. So when the array is iterated it is better to check for null for each location.

If you are creating an array, and inserting values into it, check the scenarios for null.

If you want an array as the result of a method, but not sure of the size of the array during the creation array, then use arraylist. Once done create array from the arraylist.

While reading from property file, use propertyfile.getValue( key, default value). This saves us from checking null and spaces.

Don’t use StringBuffer if u r using ‘+’ to concatenate multiple String because Java will always write whatever String formed using + fully.

Try to initialize the StringBuffer with capacity. This will improve performance.

Any method u write, make it very small. use conditional operator to the max. This will make the code look clean.

Use regular expressions for checking some sub string within a string.

Inside a method always use temporary variables. Like for an array, if u r playing with array, use temporary array. This will increase performance.

Classes grow like a tree. Like if u have a main class , and u r calling other classes from main, like helper classes, the methods in main class should just call other methods, where by reading the method name, the functionality of the method should be understood. Helper classes and other classes can grow big. So its like a tree.

Utility class should be very generic. If same functionality to be achieved, but with different method, then use over loading in utility classes.

If u wanted to Convert some wrapper class to String, like to convert Long to String, never user new Long(12233).toString(). Instead user “”+12233 This increases performance

Always make the method names meaningful. Also the input arguments should be meaningful.

JUnit philosophy. When you run Junit test cases, always it should be green, No red. When testing negative conditions, the negative condition should pass. So it should be green.

Make a project in such a way that it should run after checking out from CVS and building it.

Never user kill -9 for stopping servers. use kill command only. Kill -9 is forced. It can leave many transactions open. This will some time cause problen during next start up

If any methods that take more than 2 minutes to understand then it is a tough logic.

Developer should be convinced with the logic and no confusion should be there for him

When you write any method, try to return void or boolean other than cases where you need to return some object and the calling method wants to do some processing with the same.

Void is good because it gives an impression that either the logic has exceuted successfully or and exception has occured.

For any DB calls, check the requirement for connection time out. Test it and implement it.

When to make the methods of class static ? Only if the instances of class has state. If the class only does some functionalities and don have any state then make the methods static

Object oriented programs should have life. See when u can use object orientation and when procedural

In any project, identify the most used use case, amount of time the use case takes to execute and number of transactions in each request send by each use case.

If the application being developed is hitting any other servers ( like data base server, mail server etc), always configure failover URL for these servers.

Always have goals in mind before doing the task. Then identify the steps to reach the goal.

When should a method throw an exception. Depends on what functionality the method implements. Ex: Suppose a user checks what balance is available in his account. If the available balance is zero, no exception needs to be throw.

But if user authentication fails, then exception can be thrown.

Defensive Programming

As Murphy’s Law states, “Whatever can go wrong, will go wrong”.

“If there’s more than one possible outcome of a job or task, and one of those outcomes will result in disaster or an undesirable consequence, then somebody will do it that way”.

So defensive programming is all about guarding one’s code. Never trust any external entities. So all the inputs that comes into one’s method should be scanned.

For example :
Consider this piece of java code.
public void myfun( String a, String b){
int i = a.length();
int j = b.length();

Here ‘a’ and ‘b’ can be null.
So in defensive programming it will be
if( a == null) return; if( b == null ) return;

Always be in safer side is the philosophy of defensive programming. This reduces the log debug statements as one can be sure that he has handled most of the conditions that will break his code.
Code written in this manner can be reused, since it won’t create any unnecessary bugs.

There are various techniques used in defensive programming.
Some are assertion, design by contact, return exceptions etc.