It's 1500!!!

Page view count on this blog is 1500 at this very minute! Yipeeeee

ORA-01882: timezone region not found

If you get the following error when you try to connect to your Oracle db from SQL developer (or from any other entity)

ORA-01882: timezone region not found

The reason is that time zone is not set in java opts (Obviously!)  You need to set it.

In SQL developer go to

opt/sqldeveloper/sqldeveloper/bin/sqldeveloper.conf 

And add,

AddVMOption -Duser.timezone="+05:30" (Your time zone)

Two types of girls..

There are two types of girls, One type who are toughened by circumstances and hardships, who have been out there in the world alone, who have fought battles and worked their way up in the hard way.

They are independent and strong. They may not care much about uncombed hair or unironed clothes, because they know better than to think that a girl's value is in her looks or in the gold she adorns. They may not be graceful in their ways or poised in their speech since they simply never had time to polish themselves up.

And then there is the type who get everything served to them in a silver platter. Those who are spoiled by been waited upon and their every whim been catered to, who never had to move a hair to get what they want.

They are escorted to wherever they go by doting parents. They get annoyed when their wishes are not fulfilled at the rate they want. They are groomed up to be “feminine” in all their ways.

I've always found that it's the first category that can be true friends. But it's a pity to see that the second is the type that is mostly admired in this country.

Why should being feminine should be synonymous to being fragile?

Dealing with a Legacy Codebase

As software engineers we don't always get to work on clean slates.

At one time or another, we all get to deal with legacy code bases. Eventhough they may look like scary daemons at the first sight, they can be fun and they can teach us a lot of things. 

We all love to see clearly written, easy to read, properly formatted, well maintained code that are well aligned with all design standards imaginable and backed with clear and up-to-date design diagrams, architectural documents, requirement specs etc. But such legacy code exists only in the day dreams of developers. In reality, no matter whether you're in silicon valley or in a outsourcing company in far east, what you get is a soup of technologies, very very lengthy classes with bug fixes creeping in and messing up the original design whatever it was. You'd be lucky to find any documentation. And even the domain knowledge is tuned into software folklore that are passed from developer to developer and lost when people leave.

How do you get to know a legacy code base in practice? 

Bug fixes & Debugging 

One of the best hands-on-approaches to learn a foreign code, is to fix something in it. A bug will give you a purpose and a direction. The more you go wrong, the more you learn. Following the code along with the variables through debugging gives a good idea about the code.

Reverse engineering the design

There are tools that allow you to create design diagrams based on existing code. These diagrams help you to visualize the overall picture.
You can draw class, sequence diagrams by simply dragging and dropping the classes. ObjectAid is a free Eclipse plugin that allows you to do that.

More advanced tools would generate the diagrams when you run the functionality.  MaintainJ is one such tool that gives some of the functionality free. It's a Ecplise plugin again.

Use of profiling tools

Profilers generate the call tree along with the times spent at each step. You get the class/method stack that gets called when you run the program. It's a great way to find out which classes and which methods gets called in a given scenario.

Eg: JVM Monitor

History and folklore

There is a wealth of knowledge floating around that is not included in the code or in any of the documentations. These exists in the memory of the people who had been dealing with the system for some time.
There are pretty interesting stories about why a certain functionality had to be implemented that way and not in a different way etc. "Long time ago when dinosaurs roamed the earth there was this requirement and we did this to cater for that, hmm nobody needs that any more, but we never had the time to remove it", Dead Code?, yeah don't be surprised if you find skeletons and cemeteries in your code base!

Talking to people and getting to know all this background details is critical, and the juicy bits in the stories actually make all the technical nitty gritties stick in your memory.

Eclipse Plugins : JVM Monitor

JVM Monitor (http://www.jvmmonitor.org/)  is an excellent tool for generating a call tree for a functionality. It's an Eclipse plugin and is actually a java profiler.

Install the plugin from the update site
http://www.jvmmonitor.org/updates/3.8

Once you install the plugin you get a new perspective called "Java Monitor". In that, there is a Explorer which lists down all the JVMs. Right click on the JVM you want to monitor and click start monitoring.

In the properties window there are several tabs, select the CPU tab as shown above and click on “select profiles Java packages” which opens up a window that allows you to select the packages that you need to instrument.

Once selected, you can see the “run” button in green which says “Resume CPU Profiling”

Click on that and it will start generating call tree for all the threads in that JVM using the instrumented classes.

You can click on the “pause” button to stop.

What I usually do is have debug points before and after the functionality I want to learn, run a test, start monitoring when it stops at the first break point and stops monitoring when the second break point is reached.

You can save this and it will generate a .cpu file that can be used for later reference. You can easily search through the call tree and see what classes are called.