Whuffie is a general measurement of the overall reputation, and Whuffie is lost and gained according to one's favorable or unfavorable actions.

In the enterprise context, Whuffie is also an indicator of the Social Capital of an enterprise and how an enterprise gains a favorable advantage through the direct or indirect use of social connections. For our concern, we are looking at digital social connections (facebook, myspace,  linkedin, blogs etc)

As enterprises move towards the social computing era and embrace social networks and Web 2.0 components (blogs, wikis, discussion forums, twitter etc), need for managing your relationship with the social computing environment is becoming a necessity.

As Enterprises start embracing the Social Networks (myspace, linkedin, facebook or orkut) and integrate with thier corporate web sites, enterprises start need to be aware of the following -

Google has announced that they will be launching Chrome OS soon. All the analysts are predicting how it will be competing against Microsoft's Windows or how it will power the netbooks with more features available off the web + secure environment.

What I am visualising is the advent of Chrome OS with a small kernel and Chrome browser kind of inteface.

Singleton is a design pattern means allowing only one instance of the class. (Check out more on singleton’s here) Singleton works well till the point you have single JVM.

In a multiple JVM’s environment, each of them will have their own copy of the singleton object which can lead to multiple issues specially in a clustered environment where the access to the resource needs to be restricted and synchronized.

To achieve clustering across JVM’s, one can use multiple techniques (JMS, DB, Custom API, 3rd party tools), but each of them have an impact on the business logic. If the requirement for JVM clustering is realized later in the game, then change to business logic will be huge.

• In case, the requirement to have singleton across JVM’s is realized later, then tools like Terracotta, Oracle Coherence are good options. These work on the concept of providing an in memory replication of objects across JVMs in effect providing you singleton view  or making use of any of the cluster-aware cache provider’s like SwarmCache or JBoss TreeCache should work as cache entries are singletons and clustering is built in.
• Also, there is product called JGroups – which uses multi-cast comm. (TCP/UDP).  It allows to form a group and Applications (JVM’s) can participate and JGroups will send messages to everyone in the group so that they can be in sync. 
• Application server’s also provide some level of custom API’s to circumvent this problem. 

1. JBoss has HASingleton Service ( based on MBeans) which is meant to solve this problem. Check here and here
2. Weblogic has the concept of Singleton Service – where only instance runs within the cluster and all clients will look up to the same instance. 
3. WebSphere supports the concept of singleton across cluster in the WebSphere XD version of the application server as the partition facility – ObjectGrid 

How many times I have heard the statement “Code should be maintainable” from clients, Delivery Managers or Project Managers. I always ask them, how you quantify maintainability. I am listing down some of the factors that can be measured and help make the code maintainability quantifiable.

• Code Coverage– describes the degree to which the source code of a program has been (unit) tested. Popular tools to measure code coverage in Java is Emma. You can find more code coverage tools list here
• Code Complexity - is another measure that can used to identify and quantify the code maintainability. Factors like Cylometric Complexity, Halstead's software science metrics and Lines of code metrics are some of the factors. Infact, there is a measure called Maintainability Index that can be calculated by using the factors. Check out tools to calculate MI here.
• Documentation - is another factor that be used to quantify code maintainability. Documentation can be your normal JavaDocs or the inline source code commenting. You have tools like JavaNCSS where NCSS ( non commeting source statements) that can be applied at class, method/function level
• Code Format - is not really a measure but is an indicator of the readibility of the code.Tools like CheckStyle can help identify the code formatiing problems (from non standard class headers, identation issues to spacing, variable naming convention and so on). Any issues reported by the tool can be used an indicator of the maintainability of the code