Google
 
Web nishgoel.blogspot.com

Tuesday, September 05, 2006

State of Indian IT companies

In last few years there is a concerted effort from Indian IT companies to project themselves as a high end consulting player. Instead of just doing low end maintenance/support work, they are trying to move up in the value chain.

They are hiring students from US universities. But is hiring from US universities enough to become a global player?

Some of problematic areas I see are:

1. Global Delivery Model as touted by these companies is a big failure. There is a lot of communication gap between onsite and offsite teams and usually it’s a big mess. Most of the time offshore team doesn't have any idea about the client requirements.

2.Most of the projects are done using waterfall methodology. Since these projects run for at least year or so, I think iterative development is a must for it. Usually project deliverables are of very bad quality. This in turn forces client to sign up a multi-million support contract :-)

3. Work culture is pretty bad in these companies. You are supposed to work 24/7. More of a bonded labor.

4. No concept of time management. Managers will have ad hoc meetings at 5-6 in the evening.


Given the above issues, I am not sure how can these companies attract best talent from around the world and become a global player.

Wednesday, August 23, 2006

Scoped beans in Spring 2.0

Recently, we built a swing based applet communicating to server side services using Spring Http remoting.

While working on remote communication, we had a need to persist some data in user http session. HttpInvoker by default is stateless.

After doing some research, we figured out new concept of Scoped beans in Spring 2.0. Till now, spring beans could either be singleton or prototype. With the introduction of scoped beans, beans can be sourced from any arbitrary storage. "Session" and "Request" based sourcing is provided out of the box for typical web applications which may like to persist some data in Http Session.

Configuration will look like:
<bean id="helloWorld" class="com.test.hello.spring.HelloWorld" 
scope="session">
<aop:scoped-proxy/>
</bean>

Here "scope" attribute can take values - singleton, prototype, session, request or globalSession.

globalSession scope is applicable for Portlets.

Sunday, March 19, 2006

DHMTL -- Big Time sink

Last few days I have been trying to integrate AutoCompleter using scriptaculous and DWR.

Even though Java script has come a long way with all these libraries, but DHTML is still a big time sink.

These are the few issues I found:

1. Dynamic div for autocompleter not aligining properly with the text box on IE. It happens only when dynamic div is contained in relative div.
2. IE over lapping problems with div and select.

There may be similar problems with other java script libraries too. Also, I am sure there must be some work around to get past these problems, but look at the time spent to solve them. Is it really worth spending so much of time? I know everybody is trying to jump on Web 2.0 bandwagon but I don't think we are ready yet to build some real business applications ...

Thursday, January 12, 2006

Interview experience

Recently, we interviewed a candidate for Senior Java Developer position.

I was surprised to find that person couldn't even answer few fundamental questions like:

1. How do HashMap works? Why do we have to implement hashcode and equals method of an object?

2. Parallel garabage collector in Java 1.4 onwards.

3. Pros and cons of adding index to a database column

At a Senior Developer position, I expect people to answer these basic questions.

Wednesday, November 16, 2005

JBoss classloading

From 4.0.2 Jboss has started using Tomcat classloader. (http://www.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration)

Does anybody know if I still have to specify isolation in jboss-app.xml to achieve scoped classloading? IMO, if Tomcat classloader is used then different ear will be isolated from each other. Can someone verify this?

Friday, November 11, 2005

Spring AOP usage for logging purposes

Today we had some interesting discussion about Spring AOP usage.

In our project, we had a need for logging all the SQL statements executed in DAO’s.
We already had some custom logging framework built. Now we had to tie this framework to DAO’s.

Now since all the spring based DAO’s makes use of JDBCTemplate, all CRUD operation goes through JDBC template. So the first idea to popup was to define a point cut for JDBC template (field level interception) and then hook up our logging interceptor to it.

(Note: Spring doesn’t support it and we have to use AspectJ for it)

Whenever this field was accessed, we fired logging interceptor. In the interceptor, we iterate over method arguments. One of the arguments was of type SqlProvider. This provided sql statement being executed.

But here was a problem with above approach (apart from field interception). Let’s say we have DAO like this:


public class ProfileDaoImpl extends JDBCDaoSupport implements ProfileDao
{
private ProfileSQLquery profileSQLQuery = null;

public void initDao()
{
profileSQLQuery = new ProfileSQLQuery(getDataSource());
}

public Profile getProfile(String userId)
{
return profileSQLQuery.getProfile(userId);
}
class ProfileSQLQuery extends MappingSQLQuery
{
....
public Profile getProfile(String userId)
{
return (Profile)findObject(new Object[]{userId});
}
}

}

Point cut was defined for JDBC template field defined in ProfileDaoImpl.

But the query was executed on JDBC template field of ProfileSQLQuery object. So interceptor was never fired.

Until unless we externalize (as a separate spring bean) query objects like ProfileSQLQuery from DAO’s and then define point cut for JDBC template field in it, it will not work.

So field level interception didn’t help to keep these sql objects as inner classes. If we have to externalize, we can very well use method level interception. Just define point cut for execute* and update* methods of SQLQuery/SqlUpdate objects.


Not sure if we can do away with externalizing query objects.

Saturday, October 29, 2005

Message Driven POJO's

I read few blog entries about how Lingo can be used to write Message Driven POJO’s.

But doesn’t Lingo require having java and spring on both sender and receiver side for it to work.

This constraint is understandable for Spring HTTP since it’s just better version of RMI which anyway assumes a Java Interface at server side.

But for most real-world messaging solutions, usually we don’t have any control over who is putting the message. Message may come from some legacy application, external vendor etc. In these scenarios, I am not sure if Lingo approach can even be used.

Am I missing something here?