Sunday 29 March 2009

How to safeguard your career in recession

A couple of strategies for making sure that your job is safe in the recession-hit corporate world.

Be a money-spinner
Share client leads or ideas to generate revenue even if that's not part of your responsibilities. The most important resources for any organization are the people who bring/generate business.

Stand out and step up
Make sure people know you, by solving problems and taking on high-profile and critical projects.

Move around in safe zone
Dont keep the company of the people who are not rated very highly by your bosses. Hang out with the people, the boss respects most. The aura of their good reputation may extend to you.

Go beyond your job scope
Look for problem spots that you can help fix and step in whenever extra hands are needed.

Make a sacrifice
Volunteering to take a salary cut during an industrywide downturn can make you look like a hero. This one is a little bit risky but may put you in the good books of your higher management very quickly.

Increase your market value
Enroll for some certification course to add value to your resume. Its really great if you can manage your organization to sponsor otherwise spend out of your pocket. Don't think of it as an expenditure, it is an investment.

Monday 23 March 2009

KISS, DRY and YAGNI

I am mentioning a few programming philosophies, which seem so obvious yet so difficult to follow. Only after spending a few years in software industry I could realize that the beginners write the complicated code and experts write the simple code and not the vice versa. I believe all these strategies can never be mastered; they can just be bettered.

KISS - Keep It Simple Stupid
I am sure all of us have heard this advice quite often and it still holds its ground. A lot of times we over complicate the solution to make our, otherwise boring, life a little fun. This happens a lot of times in the corporate software development world, where the boredom of routine jobs can be relieved by implementing an intellectual but not required solution. It feels great when we do it but if someone needs to fix, maintain or modify it, I am sure we would be up for a few cuss words. It is quite possible that when even we ourselves go back to our code, we start scratching our heads to figure out what exactly the code is doing. I am sure none of us would want to feel stupid looking at our own code. So just follow the words of the wise - KISS.

DRY - Don’t Repeat Yourself
Try not to repeat your code at a lot of places. Repetition is always a maintenance nightmare. If you need to repeat your code probably its time to refactor your code down to one use. You can refer it from multiple places. If you know your code is going to be used only once, then you are better off with the cut-and-paste approach rather than looking for a more general and thoughtful DRY solution. But if thats not the case, be more thoughtful before you commit the sin of duplication.

YAGNI - You Ain’t Gonna Need It
Don’t build something now because you think you might need it later on. Don’t over plan things. Don’t try to look too far. You might not need to travel that far at all. Try being a minimalist. Don’t try to gold plate things when its not needed. A time might come when the new functionality would not fit in the current code and a redesign would be needed but don’t factor that in too early.

Thursday 19 March 2009

How to view Hibernate query?

If you want to see the Hibernate generated SQL statements on console, what should you do?

In Hibernate configuration file set as follows:
<session-factory >
...
<property name="show_sql">true</property>
...
</session-factory >

Is little knowledge really harmful?

knowledge is always good, and certainly always better than ignorance. - Sergey Brin (CoFounder, Google)

Method overloading in Java 1.5

This post discusses the behaviour of method overloading in Java 1.5.

Suppose you have a class, which has a method void print(Integer x) and you call print(5) then Autoboxing will come into play and print will be called.

Another case is, if you have a method void print(long x) and you call print(5) then the primitive integer 5 will be widened to long and method print will be called.

Now suppose you have overloaded print method in your class

public class OverLoaded
{
public static void print(Integer i)
{
System.out.println("Integer");
}
public static void print(long l)
{
System.out.println("long")
}
public static void main(String args[])
{
int i = 10;
print(i)
}
}

There can be two possible outputs:
If you think "Autoboxing" will be done, then "Ineger" would be printed.
If you think "Widening" will be done, then "long" would be printed

Since both the method exists, which one will be used? Autoboxing or Widening?
In such situtations compiler uses the following order of priority:
  • Widening
  • Autoboxing
  • Var-args
Next question is what if there is a combination of these operations required.
When there is a combination of the above operations exists, the compiler will perform BoxingAndWidening but it will not perform WideningAndBoxing.

Class WidenNBox
{
static void print(Long x)
{
System.out.println("This is from long");
}
public static void main(String args[])
{
byte b = 10;
print(10);
}
}

In the above case, Compiler needs to widen byte to long first and then it should be boxed to Long which is not allowed.

Now consider this class

Class BoxNWiden
{
static void print(Object x)
{
System.out.println("This is from Object");
}
public static void main(String args[])
{
byte b = 10;
print(10);
}
}

Here compiler would autobox it to Byte first and then it can be widened to an Object.
 
Technology