Information Technology

In the days of Entity beans in 2.1 ways, the existence of beans required the need of a container or a run time environment to manage those beans. This made it impossible to transfer those beans across wire or across contexts as it was not possible for the new environment to always understand those beans. This prompted the need of patterns like Value object and Data Transfer object.

In the good old world of IT development, we have the software development done as per the waterfall model. It was sort of a logical transition from the construction or mechanical world to the newly found software world. The big phases were defined as Requirements, Design, Coding, Testing and Production. It was more or less across the wall model in theory but was a big spaghetti of people and processes. Features went into production which were not part of Requirements and the intended requirements never made to the Production.

log4j works by reading the logging level from log4j.properties. However normally we put the system in such a way that the log4j.properties is read while the application is loaded initially. There are at times, we need to make the logging in such a way that we can change the logging level dynamically. This is especially useful when we want to debug a running system in certain state and we can see more elaborate bahaviour by turning the log levels to more finer levels.

To do that, it's very easy.

In IT world, if the most debated topic is anything, it's about why projects fail? There is for sure more failures than successes. Many successes which are there, at times are forced successes on end users. The end users are provided with no alternatives, and they are convinced or threatened to use the product, the way they are, the way they work.

Recently I had a chance to attend the Indian Product Management Association (IPMA). It was a fresh and encouraging thing for Pune ecosystem. I have been involved in the building of Products in the past and in present but more from the angle of technical executor. However this role has provided an opportunity to work closely with Product owners and Product managers.

I think any product building and managing process has to be looked into four different perspectives. Each perspective has to work in tandem with each other for the success. The perspectives are as follows:
 

We are using Google visualisation api for making interactive charts. However one of the condition of using Visualisation api is quite strange. The api is restricted in using in offline mode. This means the api cannot be used in intranet, which is not connected to internet. The legal words can be seen here

Sometime back I spoke in Silicon India conference. I talked about JAXB and JAX-WS and how can they make web service development easier. Attaching the code samples and slides that I presented.

The code is as per eclipse IDE.

The conference details link is at
http://www.siliconindia.com/events/siliconindia_events/index.php?eid=JavaConf2010

I was searching for some Google details and apparently thought of trying in Bing to get a more neutral view. And the picture below is what I got

Though I was searching for why Google spreadsheet is fast, it told me why it is slow and that too from Mac forums to give it extra authenticity.

Interesting competitions

This is somehow getting stuck in me for sometime now that the number one reason for a software project or for that matter any projects fail when they fail to listen to the users. In context of software projects, when the projects are done by the developers for the developers there is a high chance that it's doomed to fail. It might have adopted best of the breed of technologies and frameworks but it failed to do the thing it was supposed to do for the end user. Put the greatest framework, best of processes and the ultra smart developer and you will get a super masterpiece.

Human mind has a tendency to simplify everything, which is a good thing. But than there is a tendency to oversimplify by wrapping it up in such a manner that it just looks simple on the face. At present, there are many frameworks which has come up promising the paradigm of rapid application development. They are useful, in many sense that they do remove a lot of drudgery out of the development work. Especially drudgery related to repeated task. The problem comes up when these frameworks promise the panacea for all the issues related to application development.