Friday, August 28, 2009

Cool memory analysing tool for eclipse

Found a pretty cool tool to analyse heap dump files from within eclipse called Memory Analyzer. You can check for memory allocation and find out about your memory leaks, what processes are taking huge heap memory etc. More info can be found in the following links.

The Perm Gen Exception in JBoss

We sometimes get the PermGen runtime exception thrown from JBoss when running our app. Following in the lines of the exception i stumbled upon two very useful articles explaining the same. This can be found at;

As it states Permanent Generation space is different from the Heap space we set using th -Xms commands as Perm Gen space is used to store class objects / method objects generated using reflection. As we use Hibernate this space is definitely growing with time and as the first post above says we should set the -XX:PermSize and -XX:MaxPermSize when running our app servers in order to minimize the risk of these exceptions occurring. You can also set the -XX:+HeapDumpOnOutOfMemoryError option to tell the VM to generate a heap dump if OutOfMemoryError is thrown.

Wednesday, August 26, 2009

Java EE 6 Is Out

Wow some pretty cool features are out with the new Java EE 6 package. Nice post on the same can be found @

Particularly I believe the Asynchronus type method invocation on Session beans is a pretty useful feature as some times we have to use MDBs to replicate the same kind of behaviour even though what we really need is just a non blocking call.

Saturday, August 22, 2009

Singleton not really singleton ??????

The power of Java reflection is amazing. Check the following post on how you can even access Singleton classes and create new objects . Amazing...

Tuesday, August 18, 2009

Hibernate And Oracle User Defined Types

I came across a situation recently where i had to use hibernate to read an Oracle defined object type which was used as a column type in the database. A friend of mine shared a useful link which explained how to do this using hibernate 2. But as we were using hibernate 3 I had to do a few adjustments to get it working. Following I share the procedures you need to follow in order to get hibernate 3 working with Oracle objects.
First if you look at the Oracle object it self, it will look like something as given below;

TYPE audit_trail as object






Now to map this to a hibernate object first you need to create a DTO type class to hold the variables defined in the Oracle object. For this example i create a class called AuditTrail which represents the Oracle object.

public class AuditTrail implements Serializable{

private String updatedBy;

private Date updatedOn;

private String dmlAction;

public AuditTrail(){



* @param updatedBy the updatedBy to set


public void setUpdatedBy(String updatedBy) {

this.updatedBy = updatedBy;



* @return the updatedBy


public String getUpdatedBy() {

return updatedBy;



* @param updatedOn the updatedOn to set


public void setUpdatedOn(Date updatedOn) {

this.updatedOn = updatedOn;



* @return the updatedOn


public Date getUpdatedOn() {

return updatedOn;



* @param dmlAction the dmlAction to set


public void setDmlAction(String dmlAction) {

this.dmlAction = dmlAction;



* @return the dmlAction


public String getDmlAction() {

return dmlAction;



Then moving on you need to tell hibernate how to map the following class to the Oracle user defined type. We do this by implementing the interafce UserType which is provided by Hibernate.

package com.test;

public class AuditTrailUserType implements UserType {

private static final int SQL_TYPE = Types.STRUCT;

private static final String DB_OBJECT_TYPE = "AUDIT_TRAIL";

public int[] sqlTypes() {

return new int[] { SQL_TYPE };


public Class returnedClass() {

return AuditTrail.class;


public boolean equals(Object o1, Object o2) throws HibernateException {

if (o1 == o2) {

return true;


if (o1 == null || o2 == null) {

return false;


return true;


private boolean equals(final String str1, final String str2) {

return true;


private boolean equals(final Date date1, final Date date2) {

if (date1 == date2) {

return true;


if (date1 != null && date2 != null) {

return date1.equals(date2);


return false;


public Object nullSafeGet(ResultSet resultSet, String[] names, Object owner)

throws HibernateException, SQLException {

//assert names.length == 1;

final Struct struct = (Struct) resultSet.getObject(names[0]);

if (resultSet.wasNull()) {

return null;


final AuditTrail user = new AuditTrail();

user.setUpdatedBy((String) struct.getAttributes()[0]);

user.setUpdatedOn((Date) struct.getAttributes()[1]);

user.setDmlAction((String) struct.getAttributes()[2]);

return user;


public void nullSafeSet(PreparedStatement statement, Object value, int index)

throws HibernateException, SQLException {

if (value == null) {

statement.setNull(index, SQL_TYPE, DB_OBJECT_TYPE);

} else {

final AuditTrail user = (AuditTrail) value;

final Object[] values = new Object[] { user.getUpdatedOn(),

convertDate(user.getUpdatedOn()), user.getDmlAction()};

final Connection connection = statement.getConnection();

final STRUCT struct = new STRUCT(StructDescriptor.createDescriptor(DB_OBJECT_TYPE,

connection), connection, values);

statement.setObject(index, struct, SQL_TYPE);



public java.sql.Date convertDate(Date date) {

return date == null ? null : new java.sql.Date(date.getTime());


public Object deepCopy(Object value) throws HibernateException {

if (value == null) {

return null;


final AuditTrail user = (AuditTrail) value;

final AuditTrail clone = new AuditTrail();




return clone;


public boolean isMutable() {

return true;



public Object assemble(Serializable arg0, Object arg1) throws HibernateException {

return null;



public Serializable disassemble(Object arg0) throws HibernateException {

return null;



public int hashCode(Object arg0) throws HibernateException {

return 0;



public Object replace(Object arg0, Object arg1, Object arg2) throws HibernateException {

return null;



Then you need to define in your entity class how to map this class. You do this by using the columnDefinition tag in the @Column annotation. Following shows how you should map the Oracle user Defined type in your entity class.



private AuditTrail auditTrail;

Well thats about it. You can seamlessly integrate Oracle object handling with hibernate by following the few simple steps described above.

Sunday, August 16, 2009

Time for some realistic planning

Ok so we have talked about iterative development, how to implements it then we got on to estimation and this post continues in that path to make it possible for you to provide reasonably realistic estimations and also talks about how to handle the customer when it comes to tight situations.

So you and your team come up with an estimate for the whole project and guess what, the customer thinks its way too long. If you think of it in the customer's perspective what he/she wants is to get that competitive advantage that they perceive the software you are developing will produce in the market before any of their competitors do. We all know what kind of a competitive world we all live in so your customer is no exception. Of course there are few things you can do at this moment.

First of all if you look back on how we made our previous estimation you could see we didnt take into account other overhead such as time spent on installations, updgrades, vacations, sick leaves, paper work etc. These all take considerable amount of time and you need to account for this in to your project estimation. Ok so now you will be asking how the **beep** are we gonna do that. Based on what? Ok chill chill. Variation to the rescue. Variation takes into account all the things that were stated before and counts for that. What is recommended is to have a Variation of 0.7 for a new project team. So how do you calculate the actualy number of days a developer will take to complete work within an iteration with the variation taken into account. Following is the calculation on how to do that;

1(the number of developers) x 20(project iteration size) * 0.7 = 14 days(The actual amount of time to complete the work within one iteration)

Multiply this by the number of iterations required for your first milestone and then you will get a realistic value on how many days are needed to complete the work. So now you have a realistic amount of days which your team feels confident about. Then you go to the customer and negotiate on what to do if this value is greater than the one he/she specified.

What you can do in this instance is lay down your user stories and ask the customer to first of all prioratize them according as they deem appropriate from high to low. You can give them a variation of values to base them such as 10-50 where 10 being the highest priority and 50 being the lowest.

After this is done you get this priority list and try to assign it to your iterations and see if you can get it everything in for the time specified. Something to note here is to assign the user stories according to the highest priority to the lowest. And one more thing is while doing this you should focus on only keeping your baseline functionality intact. Baseline functionality are the smallest amount of features that are needed to give a working solution to the customer.

With this amount still if the estimation is higher than what the customer expects then you have to sacrifise some of the user stories and push them back on to the next mile stone. And sadly you will have to notify the customer of the reality of the situation. One thing to note is to specify to the customer on what basis you came into this estimation. Then they will in most cases understand where your coming from. But thing to note is to always be upfront and honest to your customers because customer loyality once lost can never even be regained as i see it. What you have to specify to the customer is that the other features are not scrapped out completely, its just that they will only be available for the next milestone. If the customer still wants all that functionality then the only possible way to do that is by extending the number of iterations in your project which will eventually bring up the project deadline. But it is always the case where the customer will agree on scrapping some of the fuctionality until the next milestone.

In the end you have a realistically possible project due date that you feel confident about. And after all its better to under promise and over deliever and the vise versa. Hence you should be truthful about your estimation rather than building the project plan according to what the customer wants it to be which would only pave you a nice big path to failure :) .......

Well happy estimating and keep your projects in line.... In line of success ;)

Tuesday, August 11, 2009

The Dreadful Estimates

Well the title of this post it self is self explanatory aint it ;) ... We all know how hard it is to estimate something in our own lives. Moms will always ask how long will it take to clean your room, wife will ask how long will it take for you to get home, if you ask your dad for something he will ask how much does it cost.. So as the pattern goes on you can see all of us live in a world revolving around estimates. The same comes into play when estimates need to be made when an IT project is taken into consideration. Ofcourse all of us know how much of a dreaded task estimations can be mostly due to the fact of uncertainity that is filled with making some or most of the estimates. Aim of this post is to help all you poor souls and to take you out of your misery of doing estimates and doing them right:D ..

First of all what needs to be done is basically jot down all the user requirements and break them up into user storys which refelect all the functionality which needs to be provided by the software we are doing to build. A user story can be just a short 3-4 line description of what the functionality is all about with a title preceding. For example a typically user story will look like the following;

Title - Log-in users to the system
Description - Provide authentication capabilities to users loggin in to the system via a login menu.

That of course is one simple user story but you get what im trying to imply here yea ;) ... Ok so moving on, the next thing to do is to get together with your team with all the user storys you have come up with after many initial discussions with the customers and to decide an appropriate estimate for each user story you have defined.

One fun way of doing this would be by putting the user story on the table, explaining to your team what is exactly required by the user story and ask each one to provide an estimate of how long it will take to finish that specif story. Then you look at the spread of values taking everything into consideration. You then ask each developer based on what assumptions each of them came up with the estimates. What you do then is clarify each assumption with the customer that your team has come up which even you cant provide an accurate answer. Note that this is a pretty important step because if you go ahead with many assumptions to the coding stage that runs a high risk factor of the resulting software not being what the customer really wanted. Hence it is always advisable to talk to the customer up front with any assumptions you have and to get it clarified at that point of time so as to minimise the risk factor.

But of course at times even the customer would not know the correct answer to an assumption in which case what you should be doing is noting it down so that you have a track of any risk factors associated with each user story.

Then after going through the cycle of estimation and assumption clarification you ask your team to make another estimate now that most of the assumptions are resolved. Then you take the spread of estimated values which in this case would not be as much dispersed as before and take an average value from those values and come to an agreement with your team members of that value. Ofcourse one thing to note is this time should include not only the coding time but also the design, testing, integration, documentation(if needed) and deployment time.

If for some reason the estimated number of days for a user story is more than or equal to 15 days that usually means still there is something wrong somewhere. So what do you do in this situations? Well you got two options;

  1. Break down the user story into smaller functionalities, thereby spreading the number of days among the sub functionalities.
  2. There still might be unanswered assumptions that might fact for this estimate hence it is time to go back to the customer again and to further clarify those assumptions which would eventually lead you to re estimate the number of days.
Hence any of the following two ways can be used. After that what you do is add up all the estimated values you have come up with for all the user storys which would then make it possible for you to give the customer an estimated for the whole project which you feel confident about because you and your team have nailed down almost all of the assumptions and are pretty confident with the estimate.

So you come up with the estimate for the whole project. What if the customer says that the number you came up with is too much???? Yikes, didnt think of that now did ya? Well that my friend is a topic of its own. So stay tuned for the next post to see what you can do to overcome/handle such situations.

Sunday, August 9, 2009

Iterative Software Development Cont.....

My last post gave an introduction to what iterative development is all about and what kind productivity and value addition it brings to the table. In this post i want to address the questions unanswered in my last post. Cant keep the readers in suspense now can i ;) ... But hey everybody likes a little thriller every now and them right? :) .... So what were the questioned that were unanswered in my last post? Ok ok if your bored to go back to it and check it out let me list it down here again :D....

  • How to approach iterative development
  • How to project your iteration size
  • How to incorporate new customer changes half way through an iteration
Taking first thing first, the way you should ideally approach an iterative development process is by first analysing the initial customer requirements you gather and breaking down those features with respect to the application scope. Then what you should do is to weight every feature according to the priority level (High/Low) as perceived by the Customer and estimate the number of development days each feature will take to complete.

This process includes the asnwere to our second question which is how to project your iteration size. So you can see them both as interelated questions. Iteration size normally is recommended to be best kept at 20 working days(i.e one calendar month). But ofcourse this is definitely a varying factor depending on the complexity and the size of the project.

What you do after you decide on your iteration size is to try to calculate what features can be included in the first iteration which keeps in track with the iteration size you specify. But also you should keep in mind to put in most of the high priority tasks to each iteration as possible. Sometimes there maybe some low priority features that need to be provided before you can continue with a high prioratized feature in which case it is acceptable to include low priority features into an iteration.

Going on to my last question which is what you do if the customer comes up with a new set of features while you are in the middle of one of your iteration. Again you should go in the normal flow as explained before and weight new features accordingly and then try to see how it best fits the current iteration. If it is possible you could always push back some of the planned features of the current iteration to the next iteration and incoporate the new features whilst keeping the iteration size intact. Then you could ask the question what if its the last iteration and the customer comes up with a new set of features. Well in this instance you have to come into an agreement with the customer as to what is realisticaly possible to achieve for the given deadline and either try to move the dead line or add more developers or ask the current team to work long hours to make the current deadline. But in my perpective i do not believe adding more developers or making the existing ones work long hours will do the project any good as overworking burns out developers which in turn will lessen their productivity in the long run. And adding new developers in the last iteration is or for that matter in the middle of the project is a very decisive decision to make because according to what is stated in the book The Mythical Man Month by adding new developers you are adding n(n-1) / 2 communications channles within the project where "n" is the number of people in the development team.

Hence it is always best to try to negotiate with the customer on the current situation and try to shift the deadline to a latter date or to come to an agreement and compromise some features as deemed appropriate by the customer that can be included in later versions after the deadline.

Well thats about it for now about iterative development. Two pretty long posts on iterative development huh?... :) .. Guess you guys are now getting sick of reading about iterative development. So ill try to blend in something different in my future posts to come.

Until then its adios from my side and happy development (hopefully iteratively :D )

Iterative Software Development

Ive been wondering why sometimes we in our projects face tight dead lines and if there is any way we could overcome such situations. In my current project we are kind of facing a tight deadline situation as well and this led me to investigate on this topic of how the development process should be organised so that these kind of issues can be resolved before hand as much as possible.

My eyes caught up on a process known as iterative development. For some this definitely is not a new concept, if so please do ignore this post :) . Iterative development as i see it is not necessarily a process by itself but we can incorporate it to any of our current processes in order to maximise efficiency and throughput.

If we look at a project at a very basic level what needs to be done in order to complete it successfully is to develop a product/application which meets all/most of the user's needs within the time line given by the user and within the budget specified. How some people approach this kind of problem is by trying to figure out all of the customer requirements before even writing a single line of code or design document and spend a considerable amount of time in that process. But what they later find out is that customer requirements never stay static because of the fact that even the customer would not know what he wants as the project is initiated. What this kind of process results in is developing a product/applications which does not meet most of the user's needs because of the fact that we lose contact with the customer after the intial rigorous requirement gathering phace and only come into contact once we go through the full cycle of the the development process.

But what we need to do is to break up whole project into smaller iterations and thereby do repetitive requirement,design,development,testing cycles in each iteration. What this kind of approach gives is the ability to get customer feed back after each iteration where the user can say if we are on track according to his/her needs or not and we can then refine our next iteration incorporating these changes. By following an iterative development process we surely are able to stay on track in most cases and meet the project deadlines without out burning the development team.

More on how to approach iterative development and how to incorporate new customer changes half way through an iteration and how to project your iteration size can be seen in the coming articles... So stay tuned ;)

Thursday, August 6, 2009

JavaScript instance methods vs Class methods

Javascript instance methods are those that start with the "this" keyword where as class methods start with the prototype keyword. The difference between the two is that given an object instance methods are created per object whereas class methods are only one per class and not per instance so you will avoid creating duplicate object methods. Examples of the two are as follows;
1. Instance method example
    this.getName = function(){return;}
2. Class method example
    //ObjName is the name of your object
    ObjName.prototype.getName = function(){return;}
There is another method which is a class only method. The only difference with that is that it cannot access instance variables like the class method above but can only access class only variable. Example is as follows;
//this is a class only variable = 'test';
/*Note that to get the class variable you have to drill down to the prototype object and you cannot access instance variables in class only methods. Only difference between this and the previous method as you can see is that it does not include prototype keyword.*/
ObjName.getName = function(){return;}
But one thing to keep in mind is that the fact that the prototype keyword is not sometimes supported by older browsers.

Wednesday, August 5, 2009

Java Script Date Object

Java script consist of a Date object which is kind of similar to the Java Date object where as it uses the time since the epoch but some utility method available in the Java language are not available in the JS Date object version. Some of the utility method which i cared to share are as follows;

getDate() - Get the day of month e.g 1-31
getMonth() - Gets the month of the year. Note that it starts with 0-11 So Jan is basically 0.
getFullYear() - Gets the current year as a four digit character

Also we can pass the date as a string literal to the date object as new Date("08/09/2007") which it will convert to the intended date time. It also consists of a toString method which is a bit too cryptic and should not be used when showing specific date objects. The above in-built methods should be used instead to show the user a properly formatted date.

How do you get teh number of days between two days;

This can be done as follows;

//Assuming that date 2 is after date 1

return Math.round( (date2-date1)/(1000*60*60*24));


Java Script Array Sorting

Java scripts have intrigued me!!!As so far as me going to the book store and selecting java script books to learn it the old fashioned "Off the shelf" way ;) ... So some of my posts from here onwards will contain a mix and match of java scirpt/java so any anti javascript ppl please dnt take it personally :D.... I never knew java script had array sorting like whats available for us java developers. Two ways this can be accomplished..

Method 1:

//Sorts values in descending order
function compare(val1,val2){
return val2-val1;

var myarray = new Array([1,3,7,10,32,45]);

Thats about it to do sorting using arrays. Of course you could have just used myarray.sort() which would have used the default sorting mechanism and sorted the array in ascending order. You could debate here saying why do we need to define a new method just to get the sorting done. Bit too much code to do a single sorting function. Well look no further method 2 below shows how to do the same thing as above with just one line of code using the function literal capability of Javascript.

Behold Method 2!!!!!!! (Drum roll please)
Method 2:

Thats about it for now. But more to come very soon guys. So stay on the look out for all those Java script newbies like myself :).


Sunday, August 2, 2009

String concatenation and String builder confusions resolved

There was a very hot debate going on about String vs String builder and doing string concatenation within the append method of the String builder. I then researched this topic on the net because i had to prove a point in my work area ;) ... Then i stumbled upon this great blog post which i thought i should share with all of you which clearly explains when and how to use these String concatenation methodologies. And thankfully i was right in my assumptions :D.... The blog post can be found at