K.L. Method

The most popular statistical method for dimensionality reduction of a large data set is the Karhunen-Loeve (K-L) method, also called Principal Component Analysis.

Principal component analysis is a method of transforming the initial data set represented by vector samples into a new set of vector samples with derived dimensions. The goal of this transformation is to concentrate the information about the differences between samples into a small number of dimensions.

More formally, the basic idea can be described as follows: A set of n-dimensional vector samples X = {x1, x2, x3 …, xm} should be transformed into another set Y = {y1, y2, …, ym} of the same dimensionality, but Y have the property that most of their information content is stored in the first few dimensions. This will allow us to reduce the data set to a smaller number of dimensions with low information loss.

Discovered Friend's Blog

Found a few blog of my friends. Added to the navigation links to the right.

Business Trip in Kerteh - Part Five

Usual day breakfast in resort. Variety of food includes Terengganu's Special, Western, Chinese, Malay, Indian, Cereal, etc.



Almond Rocha Mocha, is just a mixture of mocha with topped cream. Cost me more than RM14.



Giant chess set for play.



This is the place where you can rent golf shoe, golf set, buy the token for golf balls and other sports equipments. Drives by the impulse to try Awana Kijal's driving range, I rent the following:

Half golf set -> RM 25.00
50 golf balls -> RM 5.00

I didn't rent the golf shoe and thus the personnel warned me of the possible risks of getting injured and the shop will not be liable on it. Blah.. blah..



Embrassment occured when I tried to get the golf balls out from the auto-dispenser, I forgot to put in the basket before activating the dispensement. Can you imagine 50 balls flushed out from the machine and scattered around the driving range? Hahahaha, please keep it as secret :p. I spent around 1 hour for swinging out 50 balls. Not a bad driving range, just that some part of it still under renovation.

Business Trip in Kerteh - Part Four

Mr. Ki and Mr. Jal welcome you.



Climb up there and have a nice view.




Obey the guidance please.




A bunche of guy playing beach volley ball. Boring.




Not an extraordinary beach of course, if compared to Redang or Lang Tengah.

Business Trip in Kerteh - Part Three

Walking on the back of the main building towards outdoor facilities and beach.




Overview of what you can expect.



Two tennis courts available. No time to utilize it, though.



Nice pool side cafeteria.



Not a bad swimming pool at all. No, it's not my intention to put that guy in the picture. Girls preferred.



Two jacuzzi pools available for usage.

Business Trip in Kerteh - Part Two

Awana Kijal's lobby, nothing special.







The theme of this resort is towards a more greenish and natural environment. You can see artificial plants around the place.




Night view of lobby.

Business Trip to Kerteh - Part One

Sadly, no plasma tv in the room. Well, 29inch CRT tv would do since most of the time will not be in the hotel.




Weird and freaky placement of bath tube at the corner. Not really know how to enjoy that.




Going to sleep on this bed for the next two to three nights.... alone.




Didn't see any needs to use these small chairs.

Chicken or Egg

A good old riddle, which one comes first? Chicken or Egg? We can spend ages debating on this matter. Similarly, we can ask ourselves: Business or Technology, which one drives the other?

Looking at the history of mankind, we realized that technology exists since the time when we start doing business. From a perspective, we can even argue that it is technology that enables the performance of business activity. In modern day, the dependencies between business and technology are even more inter-twined than ever that the failure of either one causes a disastrous impact on the other. Bad Business Performance can cause reduction in IT budget and ridiculously insufficient IT budget can prevent the business from attaining competitive advantage and thus loss of business opportunities.

To paint a clearer picture of the synergy between business and technology, I would like to introduce "Demand" as a mediator for this relationship. It is Demand that drives both business and technology, whether it is market demand, regulatory demand or even religion demand. Either side of the relationship which responds to Demand will eventually stimulates the evolution of the other to achieve a harmonized balance.

Take one simple example from ITIL IT Service Management chapters, Business Continuity Management or Contingency Planning requires the incorporation of both a business element (Business Continuity Planning) and a technology element (IT Service Continuity Planning) because for any service-oriented organization to continue provide the agreed level of service the business and IT must be aligned. Unless your company is truly independent of any technology, else you must plan for the unexpected, both in terms of business and technology risks.

Is Your Core Business IT System Crucial?

Imagine a large automobile sales, services and supports organization with tons of branches and dealers to manage. Lots of functional IT systems are running concurrently and yet they interacts with each other and to external parties. Suppliers, employees, customers and management are relying on these heterogeneous systems to carry out their daily routine.

In this situation, I need to ask again: Is your core business IT System crucial? Added up to that question, Can your enterprise systems evolve? The reasons for software evolution are varying but they all serve one ultimate purpose: to make sure the business continues to survive.

What you think will happen if one day they need to:

1. Add a new functional module to existing system

2. Customize existing workflow

3. Deploy a feature enhancement

4. Patch a found bug

5. Interface with a new external authority party

6. Optimize runtime performance

.... And so many else.

As many real world examples pointed out, many enterprise projects are unsuccessful due to one main reason: They can't evolve in a way that's effective, efficient and minimized risk.

Enterprise applications are totally different from many other sorts of software. As an enterprise architect, you gotta think in a macroscopic level and execute in microscopic details.

In past one month, I was involved in such a scenario where a team of programmers is assigned the mandate to evolve a business core system, mainly in the area of bug fixing and functionality enhancement.

Some of my findings are summarized as below:

The Good:
1. Architectually, the system is well designed with plenty of design patterns applied and plenty of property files (It might not be good, heard about XML configuration hell?) available for attaching loosely coupled and late bound components.

2. Well known open source frameworks and components were used. Struts, Hibernate, Apache Commons, Log4J, WebDoclet, etc.


3. Presentation tier and business tier are relatively well encapsulated with defined access points.

4. The use of ThreadLocal for managing Hibernate session

5. The use of dynamic proxy to manage DAO method invocations (Though the implementation is less than satisfactory)

(Trying very hard to think out more.... But can't seems to find any other good point)

The Bad:

1. Running on IBM WebSphere 5.1, developers actually mixed the usage of Struts TagLib and JSTL. Personally, I wouldn't do that, as many of JSTL functionalities overlapped with Struts related taglibs and since JSTL is not part of the JSP 1.2 yet, my advice is to stick with Struts only. Putting in JSTL in this case will make the deployment difficult and future upgrade to newer version of J2EE container more troublesome.

2. Unnecessary coupling between the core framework classes with web application related classes. Imagine one of your core engine class actually reference your /WEB-INF/classes's class. Cyclic dependencies cause the original ant script to fail.

3. Existence of two separate mechanisms to obtain database connections. One is using hibernate session, another is direct JNDI lookup. Hey dude, can't you just use one? In the new version of the system, I refactored the codebase to use only the hibernate session because previous JNDI lookup mechanism involved plenty of property configuration files, each for different components (HUH?).

And more....

The Evil: (We got our winners here)

1. Drag and drop deployment mechanism
- I was fainted when first saw this deployment process. To deploy new classes to the production server, you "drag and drop" your classes directly through FTP interface to their respective directories. Imagine you got 10+ updated and new classes in different java package need to be deployed, how inefficient it is to find each of the respective directory, drop the file, cross your finger and hope the container load it properly and continue with the next.

2. Minimal or no documentations
- Well, no need to speak much about this. Even the business process is not properly documented and most of the time you will like "Huh, how come the button still disabled? Do I need to perform anything anywhere else?"

3. Not a single unit test
- Without unit test, how can you confidently perform your integration test? In fact, high latency was resulted from the minor configuration issue like miss out a mapping entry in hibernate configuration file, which is suppose to be discovered during unit testing.

4. Business requirements not properly logged.
- From time to time, developers and analysts asking themselves: Emmmm, this looks familiar, was it implemented before? Oops, I can't really tell, grant me 2 days to trace through the code again.

5. Problematic concurrent transactions
- Lost Updates did happen. E.g. Stock quantity discrepancies

6. Poor Exception Handling
- I don't even want to mention about this

To be continued. Stay Tune. :)