Steven Yong's Weblog

A friend raised me a very interesting question just now after he's read my previous post. He asked me if I'll be willing to help others before I've got my part done assuming I got enough buffer to come back to my part.
The short answer to him was: I won't.
The longer one is: In fact I will never know if I have enough buffer. Initially I allocated exactly one hour for myself doesn't mean that I could still get the task done in another half an hour after I've started it for half an hour and interrupted by something else not relevant.
I promised him for an article which can elaborate much better than I do and here is it.

To be honest, I'm not a good team player, I get blamed for not being helpful in the team pretty often. But I don't really feel upset, as I know that my definition of helpful is somewhat, different from theirs.

This is my definition of "helpful" (in the context of a workgroup in any industry):
High willingness of helping others after (repeat AFTER) you've got your part done.

This applies only on the workgroups which require high level of teamwork (will define teamwork in future post) such as software development team and football team. For example, in a football team, you should only offer help on attacking if and  only if you've played your role well as a defender. Imagine a defender is too busy on attacking while the opponent is in the progress of planning for counter attack.
If you are being too helpful while you are still having tasks on hand, in other words you are just swapping out one problem for another and expecting others to be helpful in later time, trust me.

The Serendipity Team announced the final release version of Serendipity 1.0 two weeks ago, you probably know that my weblog is currently running on Serendipity 0.9.1. So it means that in order to benefit from the new features and more importantly - reliability, an upgrade is essential. Let me see when will be the appropriate timeslot for this.

Only when configuring Apache Web Server Plug-In for WebLogic, I happened to know that the API getRemoteAddr in Servlet Spec by design is not necessarily return the source client IP, as stated in the SDK:

String getRemoteAddr()

Returns the Internet Protocol (IP) address of the client or last proxy that sent the request. For HTTP servlets, same as the value of the CGI variable REMOTE_ADDR.

Returns:
a String containing the IP address of the client that sent the request

Beware of the "last proxy", which in this context it is the Apache Web server, so should we assume we could always obtain the source client IP address by calling getRemoteAddr? Should we assume there is always configuration we can make on the App server so that there will be additional parameter (like WL-Proxy-Client-IP for this case) added into the HTTP header?
If we should not, what would be the better way to get the client IP address? Or, should we get the client IP after all?

Something else about the getRemoteAddr puzzled me when I was studying the API doc: since it states that it will always return the IP (Internet Protocol) address, why would it return String instead of InetAddress object?

When we're watching World Cup match last night, my sister asked me a silly question "you always claim that Owen is damn good, actually is he really as good?"
She doesn't deserve a blame on this as she was indeed just a little girl in year 1998.

PS: As of this writing, the goal you're watching now is still honored as the second best goal ever in the history of FIFA World Cup.

In Bruce Eckel two parts of Are Web Services Real? (part1 and part2), he pointed out the necessity of focusing on the simplicity and abstraction of any useful technology.

Find it a good clarification on the confusion of WinFX and .NET Framework 3.0.

Struggling with wide variety of persistence approaches? It's time to know more about Java Persistence API which introduced in Java EE 5.

More Persistence for Client-Side Developers by Joshua Marinacci -- Continuing his introduction to the EJB 3 Java Persistence API as seen by the desktop developer, Joshua Marinacci shows how to put together a complete and fairly sophisticatedaddress book program, with one-to-many relationships, useful inheritance approaches, and other powerful techniques.