Eclipse Package Explorer: Hide part of long package names

Really nice tip on eclipse. 
Eclipse Package Explorer: Hide part of long package names?

when logger crashed the application

Ever heard a logging statement causing out of memory crashes in an application.

Some technical details: (Though most of the folks stopping by should already know, but I talked to few techi folks who weren't aware about it)

When you write

logger.debug("got a request to execute"); // We are good.

But when you write

logger.debug(heavyObject.toString());       // or
logger.debug("some string" + "some string" + someHeavyObject);

your application (and common sense) goes down the hill. 

One will argue that heavy operation will happen only if log level is debug. 

But that's wrong. Because, even before the flow reaches inside 'logger.debug', the object transformation is done. No, this is not because your logging library is bad, but because that's how Java is, and even most of the other languages. That's the way its suppose to be.

So please guard the heavy logging statements with log level check.

if (logger.level==debug) {
       logSomeHeavyStuff();
}

Yes that's ugly but that will save your application some precious CPU and memory.

Recently the project I was working on, was getting OutOfMemory crashes. That's what happen when you try to convert a 60,000 object array into a string for a trace level debugging. :)

Why that object grew to 60K, is another story to be told some other day. 

Blaming the wrong guy

I remember a Dilbert strip regarding pointy hair boss solving a wrong problem.

Saw this the other day - https://tedvinke.wordpress.com/2014/02/13/mockito-why-you-should-not-use-injectmocks-annotation-to-autowire-fields/

Though the problem regarding not using constructor is right, as it ends up giving a partially created class object in the test, but putting the blame on InjectMocks is totally wrong.

Injectmocks does what it suppose to do, if the developer is not following good programming practices, and is not aware which dependencies will get used in the unit test flow, then you cant blame the framework.

Just to go bit off topic, I had problem with InjectMocks, even after providing all the autowired beans, it jumbled them up. Reason - There were couple of prototype beans and I was injecting the Provider interface in the constructor. Here mockito was getting confused in mapping the correct providers . There I was forced to use the manual initialising of SUT using constructor. Not sure if the problem exists in the newer versions also.

Working out of one's functional boundary...

In recent years, rather more than a decade now, QE has emerged as a strong entity in overall SDLC cycle. Not saying it was not previously, but companies realizing the cost of fixing bugs in production, moved emphasis on having a disconnected test team, giving them more power.

But one side effect of this is - Misuse of power. 
Many times I observed QE team stepping out of their boundary and doing things like suggesting functional changes at the time of delivery (not at the time of backlog grooming, which actually is a good thing). 

I remember once multiple QE's huddled around me and were trying to arm twist me in changing a UI flow which 'they thought' was right. I didn't negate, but requested them to check with Product Owner. To my surprise they wanted the change to happen then and their !!!!

Thankfully I held my position.

But many developers are not like that. Recently something similar happened, where QA reported a UI error message appearing in unexpected flow. On analysis found that it was not required at the first place.
Dug further and was surprised by the reason -
A recent guideline was given to QAs to ensure unit test code coverage for the functional areas marked as critical. (Not sure how QAs can track unit test coverage)
Blindly following that policy they asked for the code coverage for a negative scenario in a method, which was not present as per the functional flow. And hence an error message was specifically added, to ensure what QA called a proper coverage !!!!
ahem... !!!

Obviously the developer should have stood his/her ground, but to make things worse even the team architect approved the approach.

Not sure if a single person can be blamed here, but overall teams should always take a firm stance when someone is trying to encroach out of their permissible limits. Not because of pride issues, but because of the scenarios like the one mentioned above.

As usual, happy coding...

Debug driven developer…

I love TDD (test driven development), only problem is I don’t think that way. And also feel that it makes you write more unit test than required. Anyways … (web is filled with holy wars on to do TDD or not, so let’s not get into it)

But the other end of TDD is (what I call) “Debug Driven Development” or DDD.

Basically developers tend to write a line of code then test it using a run time debug after putting breakpoint, to see if everything is working fine till that point.

I am not totally against this technique, scenarios when there is complicated peace of logic or data structure which is difficult to visualize using static code analysis. But doing it too much is criminal, especially in the cases where

• debug environment is complicated
• time to reach the debug point is too far in the flow or is slow otherwise

Writing a complicated piece of code and testing if you are on right path, is so easy using a unit test (even without TDD). I have saved hours doing so.

And then not just time, using too much debug just tells that:

• you just want to make the code work without thinking if it’s a good design,
• no thoughts on if it’s maintainable,
• no thoughts on if there is a better way of doing it,
• and most of the time there was no design to start with.

So take a small piece of advice – please don’t use runtime debugging just to write code.