Monday, December 7, 2009

Reset memory configuration due to PostgreSQL installation

Simply delete /etc/sysctl.conf and reboot.

A team means on the same boat

When I say "we are on the same boat" to my team members, do them really appreciate what I just said? Or do they really understand what this phrase entails. Maybe they have seen too many instances of "we are on the same boat until I jump ship and you remain on duty" type of real life stories.

If one drills a hole in the boat for whatever reason, the first thing one should do is to raise the alert. As much as being scared, the first thing the team should do is to blame the guy and kick him off the boat. Nuh, the team should work together to get the hole filled before the boat capsizes. That is why raising the alert early in a project is much more crucial than hiding it to the last min when every one has to jump ship to survive. That is why no one in the team would uselessly care about why you drill the hole but to work together to fill it.

When working with your team, make sure you explain to them the boat story to encourage them for disclosing the holes early.

A team lead or a work delegator -- Lessons learned from my three-year tenure at a great company

Does a team need a manager or merely a "delegator"?

One expresses in software design patterns, a delegation pattern should not carry any functionality other than simply delegating the call outwardly to an underlying entity. If the call failed, the underlying entity is to be "blamed", not the delegator class. You will pass the interview if you answer a question about delegation patten in this form. But passing the interview doesn't rate you an excellency at what you do with this pattern in real life.

The same verdict of the pattern can be said for managing a team of any, be it a team of engineers and consultants in a technology company. It will make you a manager, not a very bad one in a big corporation, if you just delegate, monitor and readily hold someone responsible if anything goes south. But let me tell you what, in a young startup company, your boss (possibly the company founders) will hate you for your way of team managing. Your way of delegation pattern will have no sustainability for your team and thus for your company. Your team members will feel helpless and learn how to make up stories to cover up their mistakes because they know you would not do anything for them. Your talking straight of "accountability" in modern management will doing nothing but make people fear of and retreat away from responsibilities and hence the opportunities to grow. They will leave the company and bring away valuable knowledge.

When delegating, to the right methods, make sure the inputs are validated, exceptions are checked and handled if necessary, return values are properly wrapped. That is my delegation pattern in team management. Furthermore, I would rigorously ensure there exists right foundation before my boys commence work, a clear direction is provided so that they know what outcome they will be focusing on. Bad fish shall be removed before they fully rot. When exception happens, sincerely becalm your team members that exceptions will be handled and the right outcome will be produced after corrective actions.

Instead of being a report collator and a number cruncher, a team lead shall spend their time making sure the right context is provided at right time to the right people when delegating. A team lead role to a promoted engineer doesn't mean less work with better pay check. Rather it means more work at planning and communicating. In other words, you should be more mentally exhausted than pumping out code.

Friday, November 27, 2009

JPA vs Hibernate

What is difference between JPA and Hibernate as they both cater for DB persistence work in Java? Well again this is the "fight" between official and de facto standard. Long before those so-called industry experts wake up to note down a standard addressing a well-known enterprise application development issue, several groups of smart doers already raised up to invent their own "proprietary" solution to the problem. The issue is known as ORM while the groups of smart doers included Hiberate creators, Oracle's TopLink as well as the team of bringing live iBatis. The standard is JPA.

The primary reason to embrace JPA is driven by the thirst of having a standard in Object-Relational mapping - paint the door once, changing the lock often doesn't hurt (one interface with many implementation alternatives. Ideally one can be replaced by another if one doesn't suit the course anymore). However, the reality that Hiberate 3 implements JPA enables early Hibernate adopters to stay on their course while having a standard architecture in front of their governance board. In case of Red Hat deciding to discontinue open sourcing Hibernate, JPA users can switch to another implementation like OpenJPA.

On practical side of story, I would rather recommend to use Hibernate for a JPA implementation. For things that JPA can't resolve easily, use Hibernate "proprietary" features (e.g. hibernate-specific annotations). One's chance to replace a backend implementation is as uncommon as a major Open Source project getting killed. Here I said major. If you really sense the uncertainty of Hibernate and thus want to fully stick to JPA, still use Hibernate, just keep no hibernate-specific stuff.

Composition vs. Aggregation

They both are within the context of OO design and both refer to a form of object ownership - one object contains one or many other objects.

The difference lays in the strictness of the ownership. For composition, it implies an ownership of lifetime. From implementation aspect, the compositor manages the lifetime of its containing objects. If the parent gets GCed, its composed objects are all gone away with it. Composition is thus of owning by value (does pass-by-value sound familiar?)

On the other hand, aggregation is a weaker form of ownership. In other words, if aggregator is dead (GCed), its aggregated objects will still happily live in the heap (memory heap). Under this context, aggregation is of owning by reference (Pass-by-reference as oppose to pass-by-value).

A code snippet for composition would look like this
class Compositor
{
Object obj1;
Object obj2;

public Compositor ()
{
this.obj1 = new Object();
this.obj2 = new Object();
}

}

Here is an example of aggregator
class Aggregator
{
Object obj1;
Object obj2;

public Aggregator (Object obj1, Object obj2)
{
this.obj1 = obj1;
this.obj2 = obj2;
}

Wednesday, November 18, 2009

How to set up JAVA_HOME on Mac

locate your .profile file and
put in export JAVA_HOME='/usr/libexec/java_home'

This will automatically pick up whichever java home variable set via Java Preference on Mac.

Tuesday, November 17, 2009

Thanks for my friend Rob sharing on this

Watch your thoughts; they become words.
Watch your words; they become actions.
Watch your actions; they become habits.
Watch your habits they become character.
Watch your character; it becomes your destiny.

In other words, success can be made if not born with.