Design Patterns

Patterns are just capture of the common behavior of designs. One of the good things about patterns is that once identified and given a terminology then it will be easy to for developers to communicate. Another advantage is that if you cannot think of any good way for improving the design then you can start by going through the patterns that might be relevant. Of course in the good days you will be creative and come up with great ideas - some of these could be just a variation of a pattern - or maybe some could constitute a new pattern if you could identify it out in the first place.
I don't believe we should use patterns for the sake of using patterns (i.e. leave by pattern which I think some developers are being - bindly just using patterns), patterns should be something we go back to (like the rule of thumb) when we have trouble with finding a good solution.

At the end of Kent Beck's TDD book, Martin Fowler have a comment that says that patterns are half -baked, and the rest needs to be customized to your use - thus don't use patterns blindly.

Test Driven Development

Read this book from Kent Beck recently, called Test Driven Development (TDD). There has been a lot of interest in the so called Unit Testing, where the developer are responsible for creating the test for the "unit" they are implementing. What a unit is is arguable but the general rule seems to be per class object for OOP development. TDD is an approach for developers to implement such unit test based on a "test first" philosophy. Create the test, get the test to work, then refactor to generalize the software and the test itself. Thus the programmer will be interleaving between development of the software and the test.
Kent's TDD approach is red bar, green bar, refactor. Red bar is when the test is not passing through thus the programmer should do whatever (dirty fix) to get the test to pass - that is getting to the green bar. Once the test is working then you have to refactor your code to work for the generalize cases (removing "duplication" is his term). I was amazed that this approach resembles my own natural approach to programming. The difference is that Kent is formalizing it into a discipline (habit) while I do this informally and without reusable test cases. Thus my testing effort during my programming was wasted. The hardest thing abut TDD is that you have to spend a lot of time thinking about the testes and also the need to refactor it as the program is refactored. I still have not tried the TDD but I have plans to try it out to see for myself how whether the effort to create the test is high and whether it is worth the effort.
Another of Kent's arguement is that TDD can help drive the design of your software (Object classes in particular) -- this is because you are getting your hands dirty and playing around with the object -- trial and error like style. Sometimes that is very true as there are times when you just cannot think of a good way to start thus the best way is just to start whatever - even if it is a bad design. This helps you to start thinking and find out the details of the problem. If the result happens to be bad then throw the code away - at least now you know what is better!
Software engineer is a discipline so it makes sense to discipline your habit of development - only if it suits your approach to programming. Everyone is different so do what you will but just make sure it improves the quality of your software.

Web Technologies - AJAX

To date I am pretty outdated with what is going on in the web programming world where there are just a mixed of too many languages doing the same thing......same thing? Well, that was the wrong perception I have and reading up on AJAX gave me an insight of where the current direction of web technologies are heading.
The old world of web technology (web 1.0) I lived in was more about thin client - fat server approach where every change requires rendering a new page from the server. To improve on the features of websites, java applets or javascripts, was introduced that provided more work to be done on the client side (browser). All these technologies was to make the page feel more fancy and a better GUI. The current advance in web technology is to using the client-side script as a proxy that communicates with the server. This proxy will retrieve/send data from/to the server and minimize the effect of the change of data from the client's perspective i.e. client will not see a new page when only some data on the page needs to be changed. The objective is to make the page more like a desktop application - more responsive and smoother.
This all makes a lot of sense considering that there are huge computation power on the client's machine and that most of the time a web-page only need minor modifications to display a small change in data resulting from client activities. A great example is the popular Google maps where the page is pretty much the same except the maps change from user interaction.

If web service companies are to provide more diverse and powerful application services in the future, they will need more flexibilities and bridge the gap between desktop applications and web service applications. With Internet speed getting faster and faster, it is highly possible that server will only become a source of data and all the extra work done on the client side scripts.

I wonder if there will be a time when Internet is so fast and reliable that the browser will do nothing but redirect mouse activities and display images from the server. Thus the whole page is just an image that the server will understand. This is an extreme of thin-client and super fat-servers. This might be the way to go for mobile devices where the processing compatibility is limited. I don't think the responsiveness will ever be as good as client-side processing though.

Prepaid VS Contract

Looking now for a new cell phone number. The choices are either a new contract plan or a prepaid account. The good thing about contract is that you get a new phone and good amount of calls per month ($40 ~ 300 minutes) - but you might not use that much at all AND you are tied up for 24 months. Prepaid on the other hand gives you flexibility as you can average out your use over months + you paid only as much as you call. But the disadv of course is that you will need your own phone + the call costs are higher (~25c per minute).

I am not a big cell phone user and don't talk much over the cell, so I guess I might be better off with a prepaid account and using my existing cell phone. The new phones that are out at the moment is not terribly attractive so I am quite happy with the current phone I have. I can always jump to a contract when my cell calls increase or I see a nice phone I really want.

The new Samsung from T-mobile is pretty good - thinner than motorola's but it doesn't have any cool features that interest me. Razor is always a good phone, it reminds me of the Startec X that I used to have (my very first mobile phone). That X phone was just great in terms of built quality but the interface sux as well as the features. At the moment there are too many people holding a razor........I see so many people holding one in HK, London, and even in Seattle. Looking for something that is less common......Sony's W600i has wonderful features but it is a bit too thick for my pocket......still looking.

Decisions

Decisions Decisions Decisions. What differentiates people are the decisions they make and how they come to making the decisions. Lately I am forced to make some much decisions, big and small, simple and complex, easy and hard. Even small things like shopping for food can take a toll unless you know exactly what to buy and at what price. But if you narrow your choice to make a decision easy then you are missing out the world of things (e.g. the different type of food and the specials). To make a good decision, you need to gather information, compare the choices, and determine what is best at the point (e.g. what you feel like eating, the price of the items). Taking decisions to another scope, when you look for a new apartment, how will you decide? First gather information - suburbs, quality of apa, price, proximity to shops/buses/downtown/water etc. Then you fix your price range and preference list. Then you go around looking and comparing. Next you making the final choice -- IF it is still available. All this takes a lot of effort and time. I guess if your requirement is low and will just do with anything to avoid the hassle then yes EVERYTHING can be easy. But if you have requirements and want a optimial choice (well realistically a good choice) then there is a price to pay - especially when you don't want to regret on your decisions - regret is a mental toll in itself.
Even when you settled on the apartment, then you have to think about whether to get a land line, what internet package to get, what furniture or houseware do you need? And so on...........
What about decisions you have to make at work? Decision about your career? Decision about your financial investments? Decision about your 401k?

Everyday we have to make decisions, the more we have to make the more mental effort that goes into it. Sometimes I just come home and not what to "think" or use my brain -- turn on the TV and away the brain goes.

Decisions are just all around us, especially when you start growing up and become more independent. That is why childhood can be so sweet, my decisions to make, and no regrets!

Perl and Object-Oriented

Lately at work I have been doing quite a lot of Perl coding (and reading other people's code). One thing I find is that Perl is a very expressive language, there is a lot of ways of doing the same thing, and rightly so because Perl is a scripting language design to be just that. Now when OO design has started to heat up (years ago) people have started to incorporate OO into the language. All these advantages of OO (encapulation, inheritance) require a lot of constrains which is kind of contradiction with Perl which is designed with very few contraint on the programmer and things are allowed to fail in run-time (a lot do!).
My current conclusion is that Perl should be left as a powerful scripting language and leave the OO stuff out to other languages which are much better at it. I feel that OO is best at the lower level than where Perl is at -- trying to pull OO up will just pull Perl down.

There are probably a lot of people that will go against me on this but at the moment, I am just not convinced of OO Perl.

Fedex weird tracking messages

Having blogged for a while lately, was busy at work and my intended move to a new apartment. The topic of this post is about Fedex tracking system. I managed to get a good deal for an external HDD from compUSA, they regularly have some manufacturer rebate and discounts that make an item very cheap for its spec. Anyway, the first round I forgot to put in my apartment number on the address so it got bounced back to the near by Fedex facility (another city). Now after I told them the apa# yesterday, they were suppose to deliver it today and the status on the tracking system indicated: Delivered - signature not requested. But I didn't get any notice from my apartment's management so it is starting to get scary. I called my apa's management and they told me that this message could have meant that the parcel is with the driver (or city's local storage) but might be delivered to us yet.
I am not sure what Fedex is doing but I think this status message is plain misleading and creates a lot of concerns about your package going missing. If I find that a package is missing I don't wait a few days to see what happens, I ACT NOW, straightaway as the earlier you act the more chance you have of finding out what happened (the trial is still warm!).

I really hoped that the parcel will come by tomorrow, it will ease my concern and also ease my storage problem............coincidentally my other external HDD (2.5in) case's USB connector fell apart, guess you get what you pay for (cheap case)!