How the economy works

Posted on Thursday, April 17, 2014 by Anuj Mehta


SVP Gulmohar Residency, Indirapuram Buyers Group

Posted on Monday, November 26, 2012 by Anuj Mehta



A Google group has been created for the people who had bought flats in SVP's Gulmohur Residency in Indirapuram has been created to create a common platform to interact and share updates and news with other buyers. Requesting the buyers to kindly join this group

GulmohurResidencyGroup

Leaving VNL

Posted on Friday, September 14, 2012 by Anuj Mehta



Today is my last day in VNL. I had mixed feelings about leaving VNL. I was looking forward for working in a company that is nearby to my place of residence but I feel sad as I leave a good organization and a great team with whom I had lot of memories in past 2.5 years. My experience here have been both memorable and unique. Memorable in terms like I did lot of coding, developed a number of features and tried my best to improve the quality of product, Unique in terms like each day was a roller coaster ride for me as I have to cross 3 states (UP, Delhi and Haryana) to reach my work place. Every day was a new challenge, as if I am getting ready for a battle. My typical day looks like following - Wake up at 5:30 in morning, quickly get ready and leave home on bike, ride the bike for 30 kms, then board a metro for Gurgaon, and finally walk a km and reach office. In office complete the day's work in limited time as I need to rush to home bit early so as to avoid traffic. Rush to home and now is time to play with my sweetheart Aarvi. Finally have a late night food and sleep when my daughter permits me to do so! Phew! I had been religiously following this schedule for more than 2 years when one day I said Enough is enough! I need to quit.

During my stay in VNL I had learnt a lot of things. On a personal front my learning has been tremendous. I would like share some of learning

Patience

It is said "Patience is a virtue". I feel that my stint at VNL helped me imbibe this trait.
There were a number of instances like when you get stuck in massive traffic jams, commute in over-crowded metro, deal with tough people in office. A number of instances like this helped me in developing patience over a period of time. In all tough scenarios I kept myself inspired with following lines of Agneepath :)
“Tu na thamega kabhi tu na mudega kabhi tu na rukega Kabhi. Kar shapath, Kar shapath, Kar shapath. Agnipath, Agnipath, Agnipath”

Learn from everyone




I feel that you can learn from every person whom you meet in office, be it a junior or senior. There was a time when I was loosing my interest in work as I was getting very trivial type of work, but then I observed how my juniors are working very enthusiastically or a similar type of work and I realized that irrespective of the nature of work I need to work with the same dedication as if I am new to this project and there is always something to learn from it. I really feel lucky that in VNL I got to work with some good people from whom I could learn a lot.


Be Humble

My stint here taught me about being humble. Since my office was very far my place of residence and I can't bring my vehicle there, I need to daily travel in highly crowded metro and sometimes I do need to travel in overly crowded shared auto's of Gurgaon. See the pic below to see the pathetic condition of people travelling in a shared auto :)




On the Lighter Side 


Enhanced driving skills 




On the lighter side I had greatly improved my driving skills as I daily travel 50-60 kms via bike and had never been fined by a cop. I rode bike in every kind of weather be it on a chilly morning with blinding fog or in a daunting rainy day or in blistering summer. I feel that I had now mastered the art of sailing through congested roads and reach my destiny in time irrespective of traffic or weather.

Closing remarks! 

 After all these years of working I still love coding, I am still hungry for doing great work, for building a great product! Whenever I join a new company or start working a new product I still have butterflies in my stomach and I always compare my situation with this picture


 In every new project I start from being an ape and evolve to become a human being. The idea is how quickly I can evolve in a project is the key to success.

My Daughter Aarvi

Posted on Friday, September 16, 2011 by Anuj Mehta
















Peace

Posted on Tuesday, August 02, 2011 by Anuj Mehta

FindBugs

Posted on Tuesday, July 19, 2011 by Anuj Mehta



Recently as part of code improvement exercise in my project a used a static code analysis tool called FindBugs. I find the tool very easy to use and its really helpful in detecting potential bugs in the code.

FindBugs is an open source static analysis tool for defect detection. It analyzes code without running it.


Installation
FindBugs can be installed in either of two ways

Downloading standalone FindBugs application
1. Go to http://findbugs.sourceforge.net/downloads.html and download the zip file under the heading FindBugs tool.
2. Now unzip the downloaded file and go to the bin folder and double click on “findbugs.bat” batch file to open the standalone FindBugs UI interface





3. Now click on FileNew Project and a new pop-up dialog comes up.



4. In this dialog specify the “Project name”. Now click on “Add” button adjacent to “Class archives and directories to analyze” and browse to the class folder of the files that you that want to analyze. Similarly click on “Add” button adjacent to “Source directories” and browse to src folder of the classes that you want to analyze. As an example refer to below snapshot



5. Now click on “Finish” button. FindBugs will now recursively start analyzing all the class files within the specified folder and present you the list of bugs in your source code as shown below



Installing FindBugs eclipse plug-in
Please refer to instruction on http://findbugs.sourceforge.net/downloads.html for installing FindBugs eclipse plug-in


Coding mistakes to avoid
Based on inputs from FindBugs here are some common coding errors that developers normally make and can be avoided.


Inefficient use of keySet iterator instead of entrySet iterator

Suppose we have following HashMap

Map myMap = new HashMap();


Now we following three scenario’s for iterating over elements of Map
Iterating over the keys of Map
In this case if we normally use “map.keySet” as shown below
Iterator iterator = myMap.keySet().iterator();
while(iterator.hasNext())
{
String key = iterator.next();
}


Iterating over values of Map
In this case we normally use “map.values()” as shown below
Iterator iterator = myMap.values().iterator();
while(iterator.hasNext())
{
String value = iterator.next();
}


Iterating over both key and value
This is the place where we normally make mistakes by doing following
Iterator iterator = myMap.keySet().iterator();
while(iterator.hasNext())
{
//Retrieving key
String key = iterator.next();

//Accessing the map again for retrieving the 'value'
String value = myMap.get(key);
}


A better way is to use “entrySet” instead of “keySet” in this scenario. In this case the “entry” object contains both key and value and we don’t need to access the map twice.

      Iterator<entry<string, string>> iterator = myMap.entrySet().iterator();
while(iterator.hasNext())
{
Entry<string, string> entry = iterator.next();
//Accessing the key
String key = entry.getKey();
//Accessing the value
String value = entry.getValue();
}




Method invokes inefficient Number constructor; use static valueOf instead
Suppose we have a primitive int variable and we need to create an Integer object out of it. Then we normally do following, which unnecessary creates an object of Integer class.
       int val = 10;
Integer intObj = new Integer(val);


A better way would be to use the static valueOf method of Integer class. Integer.valueOf(int) allows caching of values to be done by the compiler, class library, or JVM. Using of cached values avoids object allocation and the code will be faster.
     Integer intObj = Integer.valueOf(val);




Method concatenates strings using + in a loop
Avoid using following
        String str = "";
List nameList = new ArrayList();
Iterator iterator = nameList.iterator();
while(iterator.hasNext())
str += iterator.next();

Instead of this use StringBuffer/StringBuilder

        StringBuffer str = new StringBuffer();
List nameList = new ArrayList();
Iterator iterator = nameList.iterator();
while(iterator.hasNext())
str.append(iterator.next()); //better way




Possible null pointer dereference
Refer to following code. What if “statusData” is null. Here in code we have a null check before printing our log statement but not before actually dereferencing this object. This is a very common error.

        Vector statusData = MyClass.getTableData();
if(statusData != null)
{
System.out.println("Status Data is not null");
}
else
{
System.out.println("Status data is null");
}
//What is statusData is null??
for(int i =0; i < statusData.size(); i++)
System.out.println("Data...." + statusData.elementAt(i));
}



Improper Exception handling
Consider the following method. It throws IOException

      public static void setData(String data) throws IOException
{
if(data == null)
throw new NullPointerException();

//throw IOException for some error condition
if(outStream == null)
throw new IOException();

//otherwise...set data
}


Now here is the code segment where we call this method

 try {
setData(null);
} catch (Exception e) {
System.out.println("got exception");
}


There are two mistakes in the way exception handling has been done here
1. We catch “Exception” instead of “IOException” which the method “setData” actually throws. This way unintentionally we are catching runtime exceptions also which we shouldn’t be doing.
A better way would be to catch only those Exceptions which are thrown by the method
               try {
setData(null);
} catch (IOException e) {
System.out.println("got io");
}

2. Second mistake is that we don’t do anything in the catch block. Exceptions should be propagated to the top level i.e. the initial calling method of the trace so that proper handling can be done and this will avoid execution of part of code which may be dependent on the result of the method throwing an exception.

Code quality metric :)

Posted on Tuesday, February 01, 2011 by Anuj Mehta