Manumission

What do you do for a living?

2011-12-25T20:16:00.000+08:00

One of the most common questions I have ever been asked and one of the most offensive.

However, I have to get a point across - it largely depends on the context. Such a question is very rude if asked by a person you just got to know 10 minutes ago, or by someone that hasn't been keeping in touch for a long time. It is perfectly fine, if asked by someone closer, like a parent, one of your mates, your dog, if it could talk, and so forth. The reason for that double standard is because the intention of such a question by someone close to you is clear - it is usually of concern of your well being. Unfortunately, the same can't be said for the former group of people.

To ask someone who you don't know so well about what he does for a living is like asking him which car he is driving. Some people are slightly embarrassed about the car they own. Some people might be selling their cars tomorrow. Some might have really nice cars but do not want to draw any attention to themselves. Some may actually be environmentalists. There are more reasons why people might find it tricky to tell what car they drive. The bottom line is, asking someone you just know about his occupation puts someone in an uncomfortable position. It's invasive and therefore, rude.

Whenever I put forward this idea to people around me, the argument usually goes around the claim that people ask such questions because, as strangers, they do not know what to ask to start a conversation.

Well, my response to that is - what a intolerable pathetic excuse. Such an argument is telling me that it is acceptable to act like a complete arse just so because the chimpanzee that the person is doesn't know what to say next because he ran out of words from his hooting and panting vocabulary.

To have a question that can be asked to any stranger is like having one screwdriver to screw everything up.

A conversation isn't a script. It has to be made up of genuine curiosity and interest. Failing either one, you can't have a meaningful conversation.

"I wouldn't go there if I were you"

2011-12-24T14:19:00.001+08:00

A phrase most of us are, perhaps, familiar with. Certainly to me, it is. Whenever I suggested to go to a place, or in a broader sense, to do something that is perceived to be risky, people generally paint a bleak picture in response. To say, "I wouldn't go there if I were you" suggests to me that I should consider the person's recommendation, who have just heard of an plan of mine that I have been thinking about for a significant amount of time, and cease it.

It could be a logical thing to consider if such a recommendation is backed by actual experience. Unfortunately, most of the time, a response like that comes from people who haven't actually been or done what was initially suggested. I believe, sincerely, that they did not respond in that way to hinder my dreams, and actually, I quite appreciate the concern. What I'm upset about, is that such a comment can be made with utter lack of responsibility. Whatever that gave them the credentials to make a recommendation like that is well beyond me. However, when given enough thought, a negative opinion, purely, can become the prime cause of a given up aspiration.

This happens more with the topic of traveling destinations. Try telling your family that you'd like to travel to Africa and stay there for a few months. Try telling your family that you're planning to do a massive cross-country road trip.

An experience that was shared with me explains this a little better. A friend of mine, recently, spoke to a family member of hers at a grand family dinner. Such dinners are joined by family members, wherever they may be and willing to come. It could be imagined as if it was a Chinese wedding dinner - maybe more meaningful and consequently slightly less wasteful.

Travelling, is one of the popular topics for small talk in such an occasion. So a relative of my friend, was conversing with her about her travels. In just 3 months, my friend had travelled to Indonesia twice - to Bali and Lake Toba. Those are popular destinations. So popular in fact, they could even be said as touristy. However, in the mention of Indonesia, my friend told me her relative was surprised. It was as if Indonesia was place where they put travelers into giant pots of boiling water.

Surprised by such reaction, my friend asked her relative if he has been there before. It was, I guess, interesting to know, what could've caused someone to have an opinion like that. My friend's experience with Bali and Lake Toba was very pleasant. In fact, she is hoping to travel there again soon. When the relative was asked by my friend if he has been there before, the answer was "no".

So, what if it is true, backed by experience, that the place is indeed dangerous? How would a comment like that help? To demonstrate this point, I'd use a road trip as an example.

Nobody plans a road trip to the park just down the road from their homes - familiar and safe. Road trips are adventures. A road trip is a way to experience the elements and spirits of the places that are travelled through. People don't take road trips because it is the fastest way to get to another place. A road trip is mainly about the journey itself, not what would be happening in the end. In that sense, the risks and the struggle would, in the end, be the most memorable parts of the journey. If any of those components are taken out, the journey becomes pointless.

So if you're planning a road trip, it's really hard to understand the purpose of a remark by someone else, not on the trip, saying he or she wouldn't do it if he or she was you, especially if that someone hasn't actually done one before. The comment is complete rubbish. Nonsense. If it proves anything, it's the inept of the person who made the remark at understanding an adventure.

I'd believe in every conversation, there is something to be gained. Even if it was an exchange of utterly vulgar, non-sensical jokes, there is a good laugh to have at the end of it. However, with a negative, demoralizing, baseless remark, it's hard to see what it is there to be gained.

Instead, being positive, or encouraging, is the least that could be done. If there is experience to be shared, share it in the form of things that needs to be considered before taking on a risky activity.

Help, don't hinder.

Chinese Wedding Dinner

2011-12-20T04:04:00.001+08:00

The last button of a perfectly ironed shirt fastened. It has been a long time since it was last worn. So last checks on the shirt for unwanted marks and stains are performed. Everything looks good. It's 6pm, an hour away from the banquet which the invite to was accepted more than 9 months ago. Yes, it's a Chinese wedding dinner. Yes, it will be quite grand. There will be more than 300 people attending. Everyone will be at their best. It should be quite fun.

After a 40 minutes drive, the restaurant, which is, by the way, very famous for traditional Chinese cuisine, was in sight. It must've been booked by the new couple a year or more ago. There's a car park beside it. Unfortunately, there wasn't any space left. While searching for a lot, ladies could been seen in high heels galloping slightly to try to make it before the appointed time - 7pm.

The tension building up. It's getting late. 10 minutes into the search, there still isn't a lot yet. On the 13th minute - fortune smiled. There was just enough space between two cars that were not parked squarely in the box. The space taken without hesitation. The rush is over. The party starting. Perfect, apart from one problem.

I don't know the newly weds. Not bride, not the groom, not even their families. Why am I there?

Well, I did know the groom, but I don't know him now. He was in the same class as I was when I was 12 years old. Since we graduated from elementary school, we haven't been keeping in touch. In essence, it's almost 2 decades since I last spoke to him. How could I say I know the groom?

This is one of problems, amongst many, that I see in Chinese wedding dinners. If Facebook was designed as a database linking a person to everyone he ever knew, the inspiration must have had come from Chinese wedding dinners.

A Chinese wedding dinner is like a party that you're invited to crash into. It's a party that lasts 9 courses long, where you are seated with a whole bunch of strangers, eating the same food that you had in some other wedding dinners. Each course in a Chinese 9-course dinner is shared. It is served on an enormous plate, placed on a rotating platform at the center of the round table. While the setup works for most courses, it simply is a unsightly inconvenience with some. For instance, fish.

Most restaurants just serve fish as it comes out of the kitchen - cooked, but uncut, unopened and with a sizable spoon (yes, spoon) for guests to gore the fish with. After half a round on the table, the fish could only be described as having exploded and vultures had their turns to gnaw at it.

Between the courses, a seemingly friendly stranger, guaranteed, would try to have a conversation with you. I think that is nice. Unfortunately, most conversations start with "What do work as?". It might be way I was brought up, but if my upbringing was in order, that is the rudest question that a stranger could ask. Fortunately, it's easy to shrug off questions like that but at the cost of avoiding the person the entire evening.

One of the common courses in a 9-course meal is an enormous plate of giant prawns. Now, that sounds like a real delicacy, doesn't it? Probably, if the prawns' shell are not intact. There are two parts to the reason why that is a problem. First, chopsticks are used. Using chopsticks to peel a prawn is like wearing boxing gloves perform surgery. Second, since Chinese wedding dinners are usually very grand, people dress up to it. So naturally, especially the ladies, would not peel the prawns themselves. Not a problem because there are gentlemen at the table, correct? Rightfully so. However, because the gentlemen get so busy peeling the prawns for the ladies, they don't get enough time to do it for themselves. By the time they're finished with the peeling for the ladies, the next course would've been served.

I haven't yet written the biggest problem with Chinese wedding dinners. The biggest problem, in my opinion, with Chinese wedding dinners (or dinners in general) is shark's fin. Most Chinese wedding dinners include shark's fin as one of the courses. While Chinese see shark's fin as a representation of status (because they are expensive), in reality, it is really a bowl of animal cruelty.

Some might argue that the fins served in Chinese wedding dinners these days are not real fins. So shark's fin in wedding dinners isn't really a bowl of cruelty. However, I think it's still a problem when the notion of enjoying the end result of finning is demonstrated.

To me, a Chinese wedding dinner is an awkward, offending, inconvenient waste of food and part of animal cruelty.

I think Chinese wedding dinner has lost its meaning to commercialization. I don't know the way to restore it. I'm not historian. Even then, I don't know being historically or traditionally correct would restore the meaning. However, the immediate thing that we could do is to first tell restaurants that we do not want shark's fin served. Along with that, we should ask them to reduce the portions. Food that get wasted because of inconvenience should be substituted by something more convenient.

Finally, to couples that are getting wedded, please invite only people who you know and truly care about.

"You're so different at work"

2011-12-19T23:36:00.003+08:00

I like having conversations. I do. Sincerely. Really.

At work, I enjoy having brief chats with people whenever I could afford it. It helps me to understand the people who work in the same office space as I do. I find most of the conversations quite interesting.

At work, I would get into this zone that sits in my mind where I am completely by myself and there is nothing other than a task to get done. It's great state to be in because locking out everything other than just the task at hand increases productivity massively. The only bad thing about this zone is that if done so frequent and long enough, you would end up alienating yourself from the people in the office. In other words, you'd experience a disconnect from the rest of the organization.

So I find the need and the interest to have casual chats with people in the office. It's just as simple and pure as that. However, casual chats in the office do come at a high price.

Whenever a chat takes place, it takes time as well. Every work day is assumed to be 8 hours worth of work. Ideally, you'd finish the 8 hours sharp on the clock and you would have done 8 hours worth of productivity. When a chat takes time, it cuts the productivity output. Of course, the loss of productivity could be made up. There are two ways - compress the workload or to expand the time initially allocated for the same amount of output.

In other words, casual chatting in the office isn't free. It takes time and energy, amongst many other things.

So you can imagine, how tiring it could be at the end of a work day if the same amount of productivity has been produced and time spent on just having conversations. If what I've written so far sounds familiar to you, someone, at some point, would've made the remark below about you.

"You're so different at work"

I go home exhausted. The last thing I want is another conversation or another thing to do. I don't suppose everyone feels the same way that I do, but I don't think what I'm writing about now is something unfamiliar to most people. When I get home, I just want to sit in front of my tele with a pack of crisps and just mindlessly crunch it all away to some television program that I completely disregard. It's a fun, maybe slightly eccentric, way to unwind.

But unfortunately, nothing ideal ever happens. My tele would most of the time be occupied by someone else in the family. My crisps would've been wolfed down and I would probably have a few more tasks to do. In the worst days, some of those tasks may include having conversations.

I'm not talking about a scenario where someone puts you in - like someone telling you to have a conversation with some other person. It's a task you get when you sit in a room that is filled with at least one other person. I've tried just ignoring that person, hoping that I wouldn't somehow get into a conversation, but from experience, it doesn't work. The other person is probably thinking the same thing. It then becomes an endurance race - how long before someone feels the need to break the silence with a stupid question.

And then, someone does. If that someone isn't you, you'd probably get a question like "have you had your dinner?"

"No, I haven't. What are you going to do about it?"

A fight entails, I'm sure of it. Congratulations, you've just created a sucky day for two people.

The thing is, I don't think that we, as individuals, are prepared to converse any minute of the day. I think we all need our space. We all need our time alone. Well, at least, I do.

So I'm really excited that I'm about to go on short a trip, accompanied only by a book. Where I am going is probably 6-8 hours drive away, based on the route I'm taking. It will take quite some effort, even just to stay on the road! It's going to totally boring, utterly uninteractive. But it's precisely what I need and I know I will enjoy it a lot.

Proper software maintenance and communicating about it

2011-12-14T22:54:00.001+08:00

I bought a TV about week ago. It's been a number of years since my last. For a geek wannabe (me), going through the features of a standard modern TV surprised me. The software in it is actually quite comprehensive, though to others, bloated. It's quite impressive, but naturally, I knew there would be bugs. I just hoped I don't get affected by it.

Along with a new TV, I also bought a media player. The TV wouldn't play all the movies in my computer.

So I have a TV and a media player connected via a HDMI cable. Quite a simple setup, really. What could go wrong?

A few days after the TV was delivered to my apartment, I found a problem with it. The sound would drop for 1-5 seconds at random - I'd get a few drops in every 15 minutes. A TV setup with a bug - the thing that I hoped I wouldn't come across. I never did, actually, until this new set.

After some basic troubleshooting and not finding the fix, I went to Google. In the first 10 minutes of my search, I found something related. Some people in a forum were talking about the same problem. It was an old thread - so there was a lot to go through. At the end of it, I knew I needed to find firmware updates for both my media player and TV. So I started with my media player first.

Like most product web sites, new stuff and promotions always get the strongest emphasis. If it wasn't for my experience building web applications, it would've been tricky to find where the firmware updates. Eventually, though, I found them, for both my media player and TV.

I went through the release notes to see if they've fixed my problem. Unfortunately, no mention. However, they did mention several improvements. So I decided that it was worth it to upgrade. Like most firmware upgrades, the instructions are pretty complex and intimidating (I'll explain). It goes something like:

Download xxx_yyy_zzz.zip and extract it.
Copy install.yyy to the root of your USB drive.
Turn off your media player - unplug from the power socket it if you have to.
Plug the USB stick to your media player
Hold the power button on your media player and then turn it on.
Release the button and the media player will update itself. When it is updating - do not turn it off under any circumstances, not even if the sun is going to explode (well, more or less).

Can you imagine your grandmother who's staying 6 time zones away trying to fix a sound problem with her TV? Just the warning alone might scare her off!

Eventually, the media player firmware was updated. So I tested to see if the firmware did fix the problem. I knew the release notes didn't say anything about that, but from experience, most release notes are not 100% accurate, for many reasons. Anyways, problem was still there.

It was the TV's turn to get its firmware updated. I went through the same process as I did with the media player. There was mention of the problem being fixed! Hooray! Unfortunately, it was for a firmware version older whatever that's in the TV.

However, knowing release notes are not 100%, I thought it may contain unmentioned regression fixes. That's how I decided that the firmware upgrade was worth a try. The steps were similar, and with similar warnings. So after 10 minutes, the update was complete.

I tested for the problem again and it seemed fixed! I didn't get any sound drops 60 minutes into my movie!

Then I thought for a while - what if I'm someone much less familiar with these "technical" things. Would I have fixed my own problem? The answer, to me, is an obvious "no".

The problem isn't with the products' testing. It isn't with the firmware development. Bugs (software problems) will occur. As long as they get fixed in a timely manner, it's fine.

The problem is with the fixes not being emphasized enough. You see, it was so easy to find people talking about the problems with the TV setup. Unfortunately, it was not as easy to find the right hint to fixing the problem (the firmware update). It was actually quite easy to miss, as the forum thread contains many responses (old thread).

When I followed the hint, product web sites made it hard for me to find their fixes. When I found their fixes, their release notes weren't accurate. The upgrade procedure felt like a surgery.

When people can't get their problems fixed, they talk about it. Either on Facebook, with their friends over beer, emails, etc. Word just get around. That can't be good for the product manufacturer, can it?

Worse still, to a careful shopper, hearing people talking about the problems of the product without fixes could just turn him or her around. Lost sales!

I just think product manufacturers should be more proactive with their fixes. For instance, maybe notifying customers of updates when they are released. Tell them what has been fixed, even regressions - keep accurate release notes.

Hopefully, that will make people talk about the problems with the products and the solutions rather than just the problems themselves. Things like that give potential customers the confidence in the products.

Bon Voyage

2011-11-20T21:18:00.001+08:00

For a long time now, I've been talking about doing a road trip, maybe going north to neighboring countries or something. The thought of going on a journey was seeded much earlier than the road trip. Even before I got my driver's license, I have always been fascinated by going to places that I haven't been before.

I'm not talking about taking a flight to some place, take some pictures then mark that place off from the list of places to visit. I'm talking about a journey - through unfamiliar roads and places.

When I was younger, I had a bicycle that I rode to anywhere. I would ride it to get some breakfast, or just to have a morning ride around the areas near my place, or just bumbling along down some back alleys. At that age, as a kid who just got a bike, there were many paths and roads that I came across that I didn't normally notice when seated at the back of a car. Whenever I came across a peculiar path like that, I took a detour and explored it.

The explorations paid off - I found great hideouts spots (though, not that I need them) and shortcuts, amongst many things, although a lot of them were some kind of abandoned path that led to nowhere.

What were at the end of the paths I explored weren't that important. At least, not as important as the journey themselves. Y'know, being scared and still exploring and then finally relieved that the path has ended and knowing exactly where I am. It's like going into a haunted house and coming out alright.

Then I got bored of exploring the same surroundings. I've gotten to know my area like the back of my hand. So I progressed to wanting to use another form of transport for my "explorations". And then, I got my driver's license.

The car worked really well. It allowed me to explore much further. And I did. Every now and then, I'd mark a spot on the map and see what are the routes I could take to get to it. It's easy, nowadays, with Google Maps. I'd skip all the highways and get on the longest trunk roads.

Maybe it's because of the city boy I am, but trunk roads that I haven't been on always look like roads that go nowhere. They're a lot more dangerous - narrow, curvy, blind corners, no overtake lanes, etc. However, they are usually more exciting. For one, the scenery is almost always better - water dams, really close to the hills and scattered empty (void of customers) restaurants serving Tom Yam rice (usually).

I really like the spontaneous feeling of driving along a road that I haven't been on before and coming across a restaurant. If it looks alright, I'll just pull up right in front of the restaurant. Then, I'll choose a table close to my car and just chill out for an hour or two before moving on to the destination.

If I'm hungry while driving on a trunk road, I'd look for an empty enough restaurant. It's weird, but I really enjoy that. Maybe it's because of the feeling of timelessness - the spontaneous nature of it, with time to spend, maybe, that's what's really in it for me... but I never bothered to find out.

So after a few years of indulging myself in this weird "hobby", I thought to myself, why not make it a really long journey - across countries, cultures, food and climate that I'm not familiar with. It would be the ultimate (for now ;)) exploration for me. It would be the mother of all bike rides, it would the mother of all drives on trunk roads.

It would be simply fantastic.

Back to 1984

2011-10-12T20:26:00.001+08:00

"You are defined by what you do" - an idea that most of us have no problems accepting. It should be so, because it is right, isn't it? A hero by actions, a saint by deeds. There is no other way.

But really?

I think a person is defined by what they think, not really by what they do. For instance, a person thinking about committing a crime is already a bad person. Sure enough, as long as he does not commit the crime itself, he is still as innocent as a newborn... but what kind of a person is he if he just thinks about things that hurt people?

How can a person be considered a good person if the only thing that prevents him from doing the bad things is the impending punishment once convicted?

I think good, if it exists, is something that is pure and simple. The debates of what is acceptable by society at a particular period is not relevant. Public perspective changes all the time, but not conscience. I think it works on a very simple logic - good is something that we welcome and bad is something we want to stay away from.

Thus, I don't believe anyone sane would want to be a victim of a criminal act. I don't believe anyone sane would want to be a victim in a criminal plot, no matter how distant it is. If that is granted, how could it not be wrong to think about doing things to others the things we wouldn't want happen to ourselves?

"Don't do unto others what you don't want others do unto you"

No one needs to be watching.

Engineering Team Calendars for Confluence

2011-08-13T13:33:00.002+08:00

It's been about two months since our launch and I'm really thankful for all the interest in it so far! It's great!

We've started developing Team Calendars a year plus ago. The team was primarily made up of a product manager, a designer, and myself, the developer. There were people helping out occasionally - on QA, documentation and of course, marketing. Since 1.0, we've had a couple of rotations due to people going on leave and work load, but the roles that made up the primary team haven't changed too much since 1.0.

We're still a very nimble team!

Having spent the time that I've spent with Team Calendars, I thought it would only be less selfish of me if I shared some of the techinical things I've learnt. So I'm going to share the things I've learnt in a series of posts.

The two main components of Team Calendars are:

The UI, built with FullCalendar.
The business logic manipulating calendar data via ical4j.

In this post, I'm going to talk about why we went ahead with FullCalendar.

A lot of the technical decisions made for Team Calendars were based what we've learnt about the older Open Source Calendar Plugin for Confluence. It certainly has some issues, however, it (still) is one of the most popular plugins for Confluence. So, being popular, there is a lot of feedback on it. So what we did, was the use some of the feedback when we were building Team Calendars.

One of the main issues with the Open Source Calendar Plugin was that its UI is pretty archaic by standards today. For instance, multi-day events do not span across appropriate time slots. The main challenge with changing that, to what I understand, is that the whole calendar was rendered by the server (Confluence).

The easiest way to render an event across several time slots in a view (e.g a day cell in the month view) for the browser is to position the event element absolutely on a relatively positioned container. To position an element absolutely means to position an element with x-y coords, generally. To be able to calculate those coordinates, the dimensions of the calendar (including the events) need to known.

Unfortunately, it's very tricky to calculate HTML element dimensions in the server. The dimension depends on many things - line height, font size, border width, padding, margin and even how it overflows. Even if the dimensions are known, it's still pretty tricky to position all those elements correctly in the HTML being generated.

Why? Imagine yourself as the calendar renderer. You're going through a list of events to calculate positions of, and after calculation, you append it to the HTML markup (text). What if, half way down the list, you need to adjust some of the positions in some of the events that have already been rendered to HTML?

Of course, you could retrieve all the events you need to render so you could calculate all their positions before appending them to the final HTML. However, that creates another problem. Events can come from an external source, and for those events, Team Calendars need to go to that site, with certain network timeouts, to retrieve them.

The problem is when we're retrieving events, internal or external, and generating a view of them in one HTTP request. That's a lot to do. The risk in that is that the problems aren't being solved in a divide by conquer fashion, so it will take time. The end result could possibly be the perception by the users that the calendar isn't responsive at all. And if it does come to that, y'know, they'd be right.

The inefficiency of rendering a calendar in the server is obvious. The implications of the problem would be further amplified by the fact that we need to allow users to toggle events on and off of a sub-calendar. If we rendered everything in the server, each toggle would mean a repeat of the expensive operation.

So clearly, rendering a calendar in the server is not the right way to go. We'd solve a lot of problems by just doing it in the browser.

But of all JS calendars, why FullCalendar? Well, FullCalendar supports the model that we want with Team Calendars. It looks sexy and it's quite mature, and what I mean by mature is that during the whole development of Team Calendars till present, I haven't encountered a major bug that stops me from adding features to Team Calendars.

Furthermore, if you look at its documentation, all the integration hooks that I think a developer would need to implement any generic calendar with it are provided.

I take my hat off for Adam Shaw, who authored FullCalendar. Fantastic work!

Lessons learned building Team Calendars for Confluence

2011-06-10T10:24:00.001+08:00

The lack of updates to this blog is justified this time - I cannot be blamed :)

For quite a while now, I have been busy building the first version of Team Calendars for Confluence.

We launched Team Calendars officially on June 7th, the second day of Atlassian Summit 2011. Since then, we've received a lot of positive feedback and ideas for improvements, and boy, am I glad we're seeing such good responses! It's probably the best validation for the work we've done yet :)

The development of Team Calendars started a long time ago. In that period, we've built about 50 milestones, about 3 different models and many major UI revisions. What the hell? So many versions? Yes :)

So I thought I'd share 3 things I've learned from the process.

1. When building a new product, specifications are a guideline, feedback is the mandate
What's funny was that we've started off with a spec. The first major milestones were developed according to it. At the end of that, I thought we had a product. We could ship! Yay!

However, we felt that it didn't have the pizazz we were looking for. Although specifications were met within reasonable timeline (and I think it is fair to say that the experience that we had developing the first prototypes is probably a consultant's wet dream), we had felt like we didn't have a product with "soul".

Some of us started to ask how we could add more value to what we already have. There wasn't an obvious all-agreeing answer then. It was as if we were dumbfounded... but then we got some feedback internally.

The responses we received were encouraging (although scary, because it looked like we were heading towards a different approach altogether!).

However, it was interesting to hear the feedback. As I went through the collated feedback, I kept on thinking "How did I never thought about that? Man, that's a great idea!".

I guess the lesson is pretty simple - the users know more than us, who built the product according to the specifications.

Although the specifications were built based on feedback, there are a lot of differences between initial feedback and feedback that we got when we had a working prototype.

Feedback is not something that only needs to be asked for once (for specs). Feedback is something that needs to be asked for throughout.

2. Build prototypes frequently
With Team Calendars, we went with a weekly frequency. Every week, we would have a new version to play around with. It's easy to argue that in one week, not much could change, and that is largely true, if I look at it from the development perspective (y'know, changes to about 20 source files, 200 lines of code change, etc).

However, my experience with weekly builds completely surprised me. The usual small changes in the code generated a lot of feedback. For instance, turning off a flag that enables event adding/editing in the Team Calendars macro confused/annoyed many users.

We thought the macro would be usually used to show events on a page, so we disabled event adding/editing. However, we were proven wrong when many of our early-users asked how to add/edit events on a page. When we learned from them why they'd like that, it all made sense :)

After we allowed event adding/editing in one of the following weeks, we received some good feedback how the UI should look like to make it easier, and we did :) And we're glad we did.

The bottomline is that if it wasn't for prototypes, we probably wouldn't have ended up giving the ability to add/edit events from the macro. I thought it was reasonable for the macro to be read only, and I would think that many would agree when that's only on the specifications.

Feedback generated by playing around with the prototypes are more realistic.

3. Do not over-engineer
When building a product from scratch, for a technical person, it is very tempting to add more flexibility to the product that what is actually required. For instance, giving the product extension points when it is still being built.

Adding flexibility or fanciness when I haven't had a product, to me, is a bit like designing my first car that can be mounted with any type of engine. Sure enough, it would be quite an engineering accomplishment (can you imagine if the car can be mounted with gravity propelled engine with just 4 bolting points?). :)

Over-engineering increases costs for almost no immediate benefit. When pushing a product out the the market, what is most important is for it to catch on to users/customers and to minimize the time to market of it. That isn't to say quality can be compromised for those reasons, it should never. Over-engineering usually doesn't increase quality. In fact, in my experience, over-engineering has negative impact to the quality due to the complexity it adds.

Not over-engineering is especially important when developing 1.0 of a product. When moving towards 1.0, there are a lot of unknowns. To reiterate, we built about 3 different models of Team Calendars. When we moved from one model to another, we had to scrap and rebuild a lot of its code.

Keep focused and keep it simple. I think that will give it the ultimate flexibility of becoming something that users would find useful.

I'm selling my MacBook Pro

2011-03-07T22:02:00.001+08:00

I have a MacBook Pro 15" (2.4Ghz Core 2 Duo) that I'd like to sell for RM 3200. In addition to the standard package, I will include:

Snow Leopard install disc
4GB RAM
AppleCare lasting for another 1+ years

The original box is still with me. If you're interested, please contact me at david dot cwy at gmail dot com or call me at my cell at +60 (17) 2946423 (David Chui).

Related post at lowyat.net

Update: I've sold my Mac

Click event not fired if background is transparent (Internet Explorer 7)

2010-10-24T19:08:00.000+08:00

I think this needs some mention - I could find related topics with Google, but I couldn't find posts that mention about the problem I had to recently deal with in IE7 specifically - clicking the inside of an empty box with a transparent background doesn't actually fire the click event.

For some requirement, I had to make an empty link (a tag) look like a box. The element looks like this:

<a class="colored-box" href="#"></a>

It has two modes - enabled and disabled. In the enabled mode, it's just a box with a specific opaque background color. In the disabled mode, it will not have any background color, but its border color will be of the background color of the enabled mode.

Simple?

This is how the CSS looks like:

.colored-box {
  background-color: #cc3333;
  border: 1px solid #cc3333;
  /* More styles */
}

.foo .bar .colored-box-disabled {
  background-color: transparent;
}

So, in jQuery speak, this is how my code looks like:

jQuery(function($) {
  $(".colored-box").click(function() {
     var $coloredBox = $(this);
     if ($coloredBox.hasClass("colored-box-disabled")) {
        $coloredBox.removeClass("colored-box-disabled"); // Enabled mode
     } else {
        $coloredBox.addClass("colored-box-disabled"); // Disabled mode
     }
     return false;
  });
});

Everything was fine and dandy with Safari, FireFox, IE8... and a strange thing happened when I tested with IE7 - I couldn't click the inside of the box to toggle the box's mode when it is in the disabled mode! I could toggle the mode from enabled to disabled, but not the other way around.

However, in pure Microsoft humor perhaps, I could toggle from disabled mode to enabled by clicking any of the colored borders...

What did I do to fix the problem? Well, I found two ways

Set the background color of the disabled mode to "white" or whatever that matches the background color of the whole page in general.
Or, use a 1x1 transparent spacer gif inside the link (a tag) and stretch it to fill the entire space.

The latter approach suits me better - I don't need to define the background color.

Yeah, it probably would work if the "colored-box" doesn't specify the background color and I introduce a class that does that (so I'll use both of them if I want the box in the enabled state). However, not only does that complicate my stylesheet, it also changes the meaning of "colored-box". So if I need to make sense of it, I need to rename the class and as a result of that, update my JS.

So, no.

An ear is worth a thousand words

2010-10-17T17:28:00.000+08:00

A familiar scenario perhaps - you're having lunch with the people who work for you. For some reasons, in one lunch, a conversation is deviating away from the casual topics. Suddenly, you sensed that the person you're talking to is trying to say something about work that relates to you... something that you don't want to hear, because if he is right, you have a problem.

Usually, at that point, the person in the receiving end of the conversation would probably suit up - a helm, chainmail, a shield and probably even a mace, the knee-jerk reaction to battle the uncomfortable thought - to discredit it and to neutralize it. Whatever the means.

This is the problem. Anything before isn't. In fact, anything that led up to the conversation is positive. It's great that team members escalate their concerns to their leader. It's very flattering, in one way - when team members tell their leader about the problems they are seeing, they may be asking for help from someone who they think could - the leader.

Therefore, the last thing that leaders should do is to prove concerns that were raised as false or incorrect thoughts.

Denied thoughts could turn into a perception. At the moment when a team member realizes or assumes that the leader isn't going to do anything about his concerns, he may change his perception of the leader. The leader, in the team member's perception, may be reduced to a very small person with a big voice but an empty head - someone incapable of looking after the team.

.. and from there, it's just going to go worse. For instance, team members may lose interest communicating their problems to their leader. Instead, they go sideways. The vent their frustration at their peers... and that's when it becomes cancer - a disease that may go unnoticed until at a very serious or threatening stage.

I think, sometimes, the knee jerk reaction of leaders who try to fight potential problems by denial backfires.

Instead, most of the time, it helps to listen. Yes, just listen - until the concern makes sense, or how it makes sense in the team member's point of view. It's surprising what could come out at the end of it.

For instance, I know of a team member who was talking about a problem in the team structure or skills-work distribution where people are not being assigned to do the things they are good at. That's a pretty big issue for the leader to fix if that is a problem.

At this point, I think, some leaders may interrupt and tell the team member that the team is structured that way for the benefit of team flexibility and growing opportunities for everyone in it... and that may not be bullshit. It could be true. However, such interruptions have almost zero value. Why?

The team member wasn't really talking about the structure. He just didn't like some of the things he had to do.

Proving the team structure is right in that case, wouldn't have solved the problem. The actual problem could only be fixed if the leader knows what it is - and to find that out, listening may be required.

AtlasCamp 2010 agenda live!

2010-09-08T10:56:00.000+08:00

Atlassian, the company that gave us JIRA, Confluence, FishEye, Crucible, Bamboo (and more) has just made their AtlasCamp 2010 event agenda live. If you don't know about it already, AtlasCamp is their annual event for developers (plugins).

Developers around the world would gather at a particular venue where they would discuss and share their experience and the products they are working on. It's also a great event to learn more about Atlassian, the technology - generally a lot of geeky porn goodness!

This year, their 3rd AtlasCamp, they've introduced a pre-event game for the participants! Looks like the fun has already started!

Showing a delayed tooltip with jQuery.hover()

2010-07-21T18:50:00.001+08:00

I wanted a tooltip to only show if it has remained inside an element after a fixed amount of time. Sounds simple? Not to me - I nearly banged my head on the table for this one.

At first, my approach was crude:

$(".mylement").hover(
  function(evt) {
    // show tooltip at evt.pageX and evt.pageY, without any delay
  },
  function(evt) {
    // hide tooltip
  }
);

It worked, but a bit funny. My absolutely positioned tooltip seems to randomly pick a coord near where my mouse cursor is. The effect is more pronounced if I swiftly move my mouse cursor into the element and then to the other end. In other words, quickly get from [0, 0] of the element to [0, last pixel of element ].

Grand testicles! I had no idea what went wrong. Ignoring that random positioning, I added a delay before showing my tooltip... and the problem became worse. The code, then, looked like the below.

$(".myelement").hover(
  function(evt) {
    setTimeout(function() {
      // show tooltip at evt.pageX and evt.pageY
    }, 5000);
  },
  function(evt) {
    // hide tooltip
  }
);

With the code above, if I were to move the mouse to enter the element, pause for about 2 seconds and in the 3 seconds before the popup shows, move my mouse cursor to the other end of the element, when the popup shows, it would be at the position where my mouse was 3 seconds ago.

Fantastic? I think we know where the problem is.

To fix that, my approach had to be changed to the following.

$(".myelement").mousemove(function(evt) {
  $(this).data("coords", { pageX: evt.pageX, pageY: evt.pageY });
}).hover(
  function(evt) {
    setTimeout(function() {
      var coords = $(this).data("coords");
      // Show tooltip at coords.pageX, coords.pageY
    }, 5000);
  },
  function(evt) {
    $(this).removeData("coords");
  }
);

What a simple tooltip huh?

Through the window

2010-05-31T11:29:00.001+08:00

I like to gaze at things on the other side of a window, from some height above ground. If I have the time, I could do it for hours. Really. Being able to take my time doing that, sometimes, people come into the same room and ask what I am looking at.

Despite the number of times I heard the question, it's something that has remained difficult to answer. If I have to blurt an honest response now, it would be... nothing.

It's perfectly fine if in the view is a lush, green, majestic mountain or streets bustling with traffic or a drizzle with people dashing for shelter in the background. It doesn't matter that much.

I just find it enjoyable to be alone with my thoughts, where in my view are things working without my presence. There's nothing depending on me. It's a place where I can retreat momentarily to acceptable solitude. Perhaps, the simplest way to describe what I am getting from looking at nothing is - peacefulness.

There is all there is - it just needs to be granted.

Of course, I do prefer certain views than others. For one, I love the view of the streets in the evening when it's drizzling, through a window slightly occupied by water droplets, accompanied by the clang and clatter of a cozy restaurant, almost drowned in the conversations the other patrons are enjoying.

Turning my head from the window, would be a smile of a companion sharing the same interest, a clink of glasses and a sip from some other part of the world.

Dealing with blame mails

2010-03-23T20:33:00.000+08:00

Blame mails - they come in at odd times and they always put the finger on you. We all get them. The difference is just with the frequency. From what I've observed, many of us respond to blame mails with very defensive replies. Worse still, some of us create more blame to divert the attention away.

Assuming the problem is not your fault, and you have your innocence to protect (otherwise, it's a very different thing that we're talking about here). The knee-jerk response to this kind of situation is usually aggressive, often containing words or phrases that are regrettable a short while after the mail is sent. In the simplest analogy, getting a blame mail is like getting slapped for something you didn't do. The immediate response would probably be a punch, a kick or some sort of verbal assault.

Introducing delay before the response, or a "cool-off" period, helps to reduce regrettable responses. After 30 minutes, you'll be calmer. You'll see things in the mail that you didn't see before. For instance, it may not even be a blame mail. It may be a cry for help, and if you could lend a hand, you'll earn a lot of respect.

I once received a mail from a really upset sender, of a missing generate-report button in a system that I've helped developed. About half of the content is made up of hostile adjectives. Needless to say, the mail was copied to many recipients, some of them he reported to, directly and indirectly.

Unsurprisingly, the button was there. It's just that there was a bit business logic that would hide the button. Rather than replying to all, with simplistic instructions that he could follow to find the button (in essence, make him look like a complete fool in front of his bosses), I waited and cooled off. Then I went to his desk to demonstrate how he could find the button… and then there was the magic. He was delighted, although slightly embarrassed.

The guy was just desperate. He needed the report to be able to do something else. He needed an excuse if he couldn't. Whatever it was, he never wanted to create enemies.

With the problem resolved, he was able to do what he needed to. He replied to his own mail mentioning us having worked together to resolve the problem and confirmed there was nothing wrong with the system.

Since that day, I noticed more than a few times the gentleman was explaining the system to his peers. What was even better was that, if my ears had not failed me then, I overheard him defending the system. Of course, he had noticed me too, but even if we couldn't talk, we would exchange smiles.

Now, if I had slapped him back, I think the story would be quite different.

Used computer parts for sale

2010-03-21T21:15:00.001+08:00

Spring cleaning fever hit me. I was going through my stuff and found more than a few computer parts that are in good condition, just sitting there, locked up in storage. So I thought I'd sell them cheap.

Interested? Read on!

Macbook Pro Unibody accessories (all with boxes)- RM 80
- Screen protector
- Keyboard protector
- Palm rest protector
MSI Starforce Geforce2 GTS (with box) - RM20
Sapphire ATI Radeon X800 Pro (with box) - RM50
Kingmax 256MB DDR PC2400 - RM10
2x1GB Samsung DDR2-5300 SO-DIMM - RM85 for both, RM45 each. These actually came from my early 2008 Macbook Pro. I upgraded its RAM 1 month after I got it.

As you'd expect, there's no guarantee. Why do I have so many computer parts? Upgrades.

If you wish to know more, please write to me at david dot cwy at gmail dot com. If you take a bundle of the items above, I'd be more than glad to give you a discount.

Hope to hear from you soon!

How to order a delivery from McDonald's

2010-02-28T14:59:00.001+08:00

For those that are not familiar with the process.

Make the call (1300-13-1300). Place the order.
Wait 40 minutes for a call from them telling you its on the way.
Wait 20 minutes before calling them again asking about the order.
The delivery arrives for you to find a missing item and Coke spilled all over.
Call them again to tell them about the missing item.
Call them again, 20 minutes later to tell them the item is still missing.
Continue waiting.

Traveling around the world

2010-02-14T12:53:00.000+08:00

It's a pretty festive period this month. There are Chinese New Year, Valentine's and Chap Goh Mei. It's also the shortest month in the year.

Friends and family would take advantage of those special occasions to meet up and celebrate. Venues would be chosen, drinks will be poured, the kitchen would be bustling - all for the fragments of memories that we would bring back as souvenirs. I love it! It's fantastic!

Every celebration is an experience that I could relate to a few countries. Sound strange? I thought so. For a while, I couldn't really put to words how it felt like... Maybe it's the lack of effort, or maybe I haven't really thought about it. However, on this hot, lazy day of the first day of Chinese New Year in 2010, it feels appropriate to try.

Accomplishment
I'd call moments like this self-recognition of success. It's when I know things will work. It's when I know the pieces will fall into places. Reaching home is usually New Zealand - cool, calm and thin. There will be the majestic beauty of nature, one which the appreciation is widely common but deeply individual. The feeling is almost victorious, but yet, in its own way, subtle. Reminiscence is the perfect companionship.

Success
It's when hard labor is validated. For instance, when sales figures go up, customer satisfaction rises, new deals signed. There's no doubt. Things are better. Cheers, if not already present, is imminent in the seconds to come. Faces light up, knowing what to expect in the turn of the following months. It's all good. Well done. Success is mine and everyone else's.

Moments like that usually remind me of small bars with images of Marilyn Munroe seated in the center of some men smoking cigars, having a great time. Everyone is making statements to each other, highly noticeable, almost pretentious, but at the same time, really enjoyable. Chemical, but strangely necessary.

Gatherings
They always start awkward to me. Distant, acidic and when multiplied by the number of people showing up, intoxicating. People dress up. The make up is heavy. The suits are well ironed. A casual outing dressed formally, decorated with smiles and grins. There are people being bold in every recognizable sense - particularly in smell and sight. Very very heavy.

Fortunately, with a bit of air, it gets better. The experience usually betters when the initial conversations are left a bit cold, when people start to tune and balance with the group's interest of the night. Eventually, the cosmetics will blend, the suits make sense. If it isn't heavy, it's probably too light.

In some ways, I could attribute the experience to Australia. Strong at first, but followed by understanding and balance. It probably wouldn't work any other way.

5 easy steps to quickly make a decision

2010-02-11T18:20:00.001+08:00

Most of our lives are hectic, be it personal or work. We need to make decisions all the time and we want to make the best ones... and we want to make them the quickest we can.

I've seen some pretty comprehensive decision making processes. While I think they do help decision makers to work towards the best decisions possible, they are usually too complex, too heavy that they get forgotten with time or just practiced incorrectly.

I'm a fan of making quick decisions. It helps to push things forward. It minimizes bottlenecks. I go home happy. Here's how I do it.

1. Try to understand the problem
Notice the word "try". The goal here isn't to fire every neuron I have to understand the problem (although that would be ideal). The goal is to decide whether I am the best person to make the decision, or if there is someone else who is. If there is someone more suitable to make the call, I'll just pass it over. This is not incompetence, as some would probably take it. This is efficiency.

2. Define what the critical outcome is
Imagine you're driving to a meeting scheduled to start at 9:30 a.m. At 9:15, you reached a crossroad that gives you three options that could lead you to the venue. You know each option has its disadvantages. Let's say:

The left turn would take 30 minutes. It's your usual way.
Straight is a road you have never taken before, but you've heard that 15 minutes is quite possible.
The right turn is a really difficult drive, but with care, it will just take 10 minutes.

While it is tempting, this isn't when I'd decide. This is when I'd define my critical goal, the goal that must be achieved with the decision I make. In this case, it would to be able to attend the meeting. I'd categorize other factors (like punctuality) as important, but not critical.

3. Discard options that can fail your critical goal
With a critical goal defined, it's pretty easy to rule out the bad options.

Option 3 is not acceptable because there's a chance I'd be unable to attend the meeting at all. Imagine if I get into an accident.
Option 2 is not acceptable because it can completely fail my critical goal. Imagine if I get lost.
Option 1 is acceptable because in the worst case scenario, I'd just be 15 minutes late. I'd definitely be able to attend the meeting.

Some may say it's faster to choose the option that fits the ideal outcome the best. I have to say I don't entirely agree with that. Choosing the best available option does not tell me if it is worth taking at all. For instance, the best option may be an option that would fail the critical outcome. If I happen to decide on something that would fail the critical outcome, I really have chosen to fail.

But what happens where there is not one option that can be taken? Well, it's not all bad. If we can assert that we're bound to fail, it shifts the mindset from 'me' to 'us'. Instead of me attending the meeting, I'd think of someone who can do that on my behalf. When your mindset shifts, you can see more options. But to do that, you really need to know if you're screwed.

4. Optimize your options
Ok. So option 1 is acceptable… but can it be better? Actually, it can be. It'd be great to be on time.

So if I take the left turn, I'll be 15 minutes late. To be on time, I need to be there at 9:30, or the meeting has to start 15 minutes later. It's obvious that being there at 9:30 would be the best. The question is, how can that be done? Is there a way?

Yes, there is. Teleconference. You could dial into the meeting for the first 15 minutes.

If teleconferencing is not available, I'd probably call the organizers and ask if they could postpone the meeting by 15 minutes.

5. Stick with your decision
Don't be an ass. When you've decided on something, you've set things in motion. Sine then, people would've made decisions based on that. When you recall your decision, you're asking people to revert the things they've started, and that cascades to every level involved. It's a lot of unnecessary work, especially if the gains are minor.

But what if the decision is wrong? Well, I don't believe in wrong decisions. At worst, there are only misinformed decisions - decisions that were made based on inadequate input or experience. If you've followed similar steps to reach to a decision, you couldn't make a better one if you could rewind time.

Recalling a decision doesn't make things right. If you think you've made a mistake, you try to think of recovery steps or damage control. There is nothing that I know of that can prevent us from making mistakes in our decisions. It happens all the time. What matters most then is that we take lesson of it and use it to make a better decision next time.

Why you should stay away from Amantra Resort & Spa, Ko Lanta

2010-01-17T22:27:00.001+08:00

After much browsing online, me and my girfriend finally decided to book Amantra Resort & Spa for a 5 days 4 nights stay over the new year's eve. It looked nice and we really liked what we saw. So we confirmed it via Agoda.

Everything was great at first. We even asked the resort to arrange the transfer service (from Krabi airport to the resort). Email responses were prompt and we got what we wanted - we would have a taxi waiting for us at the airport, arranged by the resort.

When we arrived at the airport that day, at about 2pm, there was no sign of the driver that the resort promised us. To be sure, we waited for about 30 minutes. Still no sign.

As it was getting late, we had to hire a taxi ourselves, from the airport.

The taxi brought us to the resort. The journey was almost 2 hours. So we reached the resort's reception at about 4pm. When we presented our Agoda coupon, the receptionist told us that the resort was overbooked. We had to be transferred to another resort. That was really disappointing, and I must say, I was quite upset. The trip was planned way in advanced, and we booked the resort more than a month earlier! It was quite unacceptable, really.

I thought it was pure bad luck‚ until another couple tried to check in after us. Apparently, they had the same problem. Also, they faced the same problem with the transfer service (or lack of) the resort provided.

Eventually, all of us (including the couple) agreed to be transferred. There was no other choice, really. The resort that we got transferred to was Dream Team. It looked good and the service was excellent. However, we travelled to Ko Lanta with certain expectations‚ and I certainly expected a beach that I could walk to from the resort and swim. That expectation could not be met by Dream Team, unfortunately. Its beach was very rocky.

In all, we spent the 4 nights at Dream Team. While my vacation wasn't entirely destroyed, and the assistant manager of Amantra Resort & Spa did offer tokens of apology to us, I have to say, it wasn't pleasant at all to get so upset on the first day of the vacation. I wanted to go to Ko Lanta to have a great time. It started miserably‚ and if I say that didn't affect my vacation at all, I'd be lying.

Testing Confluence plugins with Selenium

2009-12-15T23:43:00.000+08:00

JavaScript testing has always been a blind spot in the Confluence Plugin Test Library. All the tests that were written with the test library until now has been based on JWebUnit.

As JavaScript becomes more popular in applications, the need to get them tested automatically also becomes more important. So that's why I've integrated Selenium support in the latest beta (v. 2.2-beta4) of the test library.

At the moment, the implementation is minimalistic. In 2.2-beta4, you get a "tester" that extends DefaultSelenium to provide functionality consistent with the JWebUnit tester in the current versions of the test library. Yes, that means you can upload any files to any URL in Confluence. You're not confined, in that aspect, to the capabilities of Selenium RC.

To show how Selenium testing can be done, I've added Selenium tests for the Confluence Page History Plugin (Codegeist 2009 Most elegant use of JavaScript category winner). This changeset shows:

The base test class you need to extend.
The project dependencies and other POM setups related to Selenium testing.
A build script suitable for use in CI servers (usually headless)

I hope you'll find the new Selenium support useful. If you come across issues, please file it here.

Cheers!

Want a pony - Google death notification

2009-11-22T13:31:00.000+08:00

Google, when I die, could you please send this email/wave to people in my contacts?

From: David Chui

Sent: <Date of death>

To: <Name of recipient>

CC: <Family members>, <Neighbors>

Subject: RIP David Chui 1983 - <Year of death>

Hi <Name of recipient>,

Apparently, I have died (see date in the subject). Obviously, I didn't have the time to write you a personalized message of my death, but depending on your relationship with me, could you please click on one of the actions below?

[Mark sender as spammer] - You have always hated me and you don't want to hear from me anymore. However, I doubt I'll be sending you more emails after this.
[Update my birthday calendar] - When you click this, my birthday would not recur after the year of death. Optionally, you could create a new recurring event of my death for your annual celebration pleasure.
[Tweet about David's death] - When you click this, you'll post a new update on your Twitter that says "w00t! @davidchui is finally dead".
[Post a message on David's Facebook wall] - When you click this, you'll post a message on my Facebook wall that says "Let me know if it's hot down there!"
[WTF?] - If you don't know what to do, I'll take care of the Rickrolling for you.

Thanks and have a nice life! By the way, how's the dog?

Deciphering the work-speak

2009-11-19T20:14:00.001+08:00

It's close to the end of the year. To be specific, it's November now. The year will officially end with the month. Between then and January is a period of time used mostly for reminding ourselves why we could last the 11 months.. and also one of the best times to reflect and think, maybe for a better year ahead.

The year has been full of lingo to me. No, not the terms that people tend to use to sound really smart, but the type of lingo used throughout organizations to get things done. It's work-speak and it's funny when you think about what it could mean. Here's a collection of some of the more memorable ones that I've heard.

"Hi" - I've got a problem for you, kiddo.
"I'd like to have a catch up with you soon" - I smell you and I will find out where it smells and I'm going to make sure that stench stays until I get hounds on your ass.
"So… where are we now?" - Why the fuck are things taking so fucking long?
"We need a plan" - I have no idea how to solve this shit. Now it's your problem too.
"We need leave planning" - You're not allowed to be away for too long.
"We need day planning" - Do let me know how you plan to fuck yourself differently everyday.
"I can give you code snippets" - I've got a bunch of useless code pretending to solve a problem in the worst way possible.
"The build is green" - The Maven problems are fixed.
"This sucks" - Ah, fuck it.
"I'm going lunch" - The finger.
"X is moving on" - Another one bites the dust.
"Would you like to step up" - Would you like a turn in the electric chair?
"Great job!" - Finally, you've done something right.
"You're the employee of the month" - Congratulations on getting yourself hated by everyone.
"Version 1.0 released" - We've finally decided to ship a SNAPSHOT.

Got more?

I won the 'Most elegant use of Javascript' category in Atlassian Codegeist 2009

2009-10-25T13:49:00.001+08:00

Codegeist is an annual plugin development competition held by Atlassian to inspire developers worldwide to write fantastic plugins for their products. 2009 is the fourth time around and I've submitted two entries for it. They are:

The plugins were submitted a few weeks ago. Since then, I waited quite anxiously for the results. Today, the wait is over. Atlassian has announced the results publicly in this blog post.

… and I won the 'Most elegant use of Javascript' category! What sweet news to receive!

In this post, I'd also like to congratulate the other winners! You guys rock! Keep the awesome plugins coming!

Simple sign-up forms win

2009-09-22T17:00:00.000+08:00

So you've built an amazing web application. You've gone through months of research and development to come up with a formula that you think will win. You got the feedback that gives you the warm feeling that the application is going to be a hit. Everything is ready. You just need to wait for the masses of users.

But then, there's the sign-up.

Sign-up is a problem because it is a hurdle that users need to jump over before they can start benefitting from our applications. Although it is a one-time process, the hassle can be too much. Sometimes, the hassle makes people lose interest… and that's really the worst thing that can happen - lose, lose.

If a big user base is vital for the application's success, sign-up must be as little hassle as possible. One of the biggest hassle with sign-up is the complexity of the sign-up forms. Have you seen sign-up forms that span multiple pages? Or how about sign-up forms that ask too much about you that it becomes uncomfortable?

I think most of us have.

The ideal sign-up form should be smart and asks as little as possible. The objective is to get the user in to experience the key features of the application as quickly and as easy as possible. So, what are the fields that should be there in the sign-up form? I think most sign-up forms can be simplified to only contain these fields:

Email address.
An optional, non-repeating password field.

How does it work? For the non-imaginative, after the form is submitted, an email will be sent to the user at the email address specified, letting him or her know of the first-time-only-instant-login link. When that link is clicked, the authenticity of the email account is verified and the user is logged in immediately.

The content of the email can be customized to contain helpful hints for the new user. But that's not what this post is about.

If the user did not specify a password in the optional password field, a server-generated password should be included in the email. In this scenario, the application should prompt the user to change the password after he or she logs in the first time.

Sign up forms like this save users some hassle. They include:

Choosing a handle/nick that is unique in the system (usually required if such field is present)
Type Captcha words.
Repeat the password for confirmation.
Filling up too much details.

Some may ask, will error handling and application features accessibility be harmed? Well, not really.

The most obvious thing that can go wrong during sign up is when the user forgets the password. But if the application records the user's email address, all it needs to do is to allow the user to ask for the link to reset his/her password. That link will only be sent via email (to the user's inbox).

If there are other parts of the application that need data that is not captured during sign-up, don't worry. The related parts just need to ask for the data when the user wants to use them. This provides context to the user why he or she is providing the details. If the user finds that it is ok to provide those details, he or she will do it. The rule is simple, let them know why the system needs to know so much about them and only ask for the data when there is a need to.

For instance, let's say you're building a social networking site and the application has the ability to find your old school mates. Instead of providing a few text fields during sign-up that ask for education history, it would be better to defer that until the user wants to find his/her old school mates.

Sign-ups should be easy. Features should be discoverable.

Get rid of the clutter

2009-07-19T23:54:00.004+08:00

Let's face it. Most of our desks look like they were hit by a tornado. I believe most of us know the disadvantages of messy desks, the reasons (excuses) for them and why it is good to clear the clutter. But how about the "how"?

My workstation consists of only my desk, my chair, my notebook, input devices and my coffee mug/cup. That's all. Despite its simplicity, it does not inhibit good productivity. In fact, it helps me to focus.

So, I thought I'd share some of the things I've thought of and done to clear the clutter.

1. Replace physical tools with virtual ones

In tray — With my (gulp) email client and task lists. I use an issue tracker as a helper to this.
Calendar — With Google Calendar. It's sharing features, (SMS) reminders, and interoperability (iCalendar) rock.
Notes — With Google Notebook. Yes, it's a service that will no longer get maintenance time, but it's one of the best tools I know that allows me to quickly make notes and have them accessible anywhere. It has the advantage of being searchable too.
Files/folders — My computer's file system or my company's file storage servers with references to them from my company's wiki. I generally prefer storing information that has a long validity period in file servers, as they get backed up automatically. However, I do keep recent documents in my computer, where they are searchable anywhere (thanks, Spotlight).

Replacing physical tools with virtual ones did require changes in my working style. There's a bit of a learning curve as well. However, after I got used to the virtual tools, reaching to them is really just as easy as with physical ones. It's almost muscle memory. You'd be surprised by the amount of space you'll free up by moving to virtual tools.

2. Put away the things you don't need (frequently)

Photo frames — I'm at my work desk to work. Having pictures of my personal life at work is just as awkward as having a picture of my work at home.
Complete stationary — I don't use stuff like scissors, knifes, letter openers, erasers, pencils and tapes all that often. So they had to go.
Own name cards — I'd expect people who is in the range of giving cards to would either a) have one already or b) know me.
Other name cards — Contact details of people I know should either be in a) my brain or b) my virtual address book.
Receipts — Bin them or file them (if they are reimbursable).
Money — It should be in my wallet or my bank account.
Food/snacks — If it can't be finished in the day it was taken, it should go back to the source.
Magazines — If I can make use of them there, something is odd. Magazines or other non-work related reading materials should be in the leisure rack.

3. Optimization

Reduce the number of cables — Cables make work desks look like snake pits. Invest in wireless networking and input devices (e.g. the mouse and keyboard) to help clear the clutter.
Stop using a mouse pad — If you're using a laser based mouse and a non—glossy work desk, you don't need a mouse pad.
Reduce the number of devices — If you have two monitors, it's good to think if it would be better to have a big one rather than two smaller ones. Two monitors mean two sets of cables for them. One big one will give you the same virtual space, but with significantly fewer cables.
Keep keys in lockers or drawers. If neither is available, ask for one.

And once you've gotten rid of the clutter, remember to keep it that way.

Upload files without refreshing the page with just JavaScript

2009-06-27T13:09:00.004+08:00

So you want a simple way to dynamically upload a file? Using JavaScript and nothing more? I may have the solution for you... well no, Google has. But I'll just add some details here.

But first, we need to know our limitations:

XHR cannot be used to upload files.
Even if it can be (which I'm 99% sure it can't), our code will look like shit.

Next, we need to know what we really mean by "simple".

Don't want to use Java Applets.
Don't want to use Flash.
Simple so that it works with FireFox, Safari and IE.
Although desirable, simple means there will be no progress bar. However, the file will get uploaded without the page refreshed.

The best way I know that can do the above is with the iframe hack. There are probably several trillion examples out there. However, those that appeared in the first page of my Google search results are either incomplete, hard to follow or they didn't point out the caveats in an obvious manner.

So, here's my attempt using jQuery.

Typically, file uploads are done with a form and a file input. When the form is submitted, the file gets uploaded and the page refreshes with the results. The iframe hack uses that. Except, there is another component. The iframe, of course.

With the iframe hack, you will have your normal form, but the HTML returned by its submission will be 'sent' to the iframe. The iframe is invisible. So users will not see the page refreshed.

So, let's start with an example:

The form

<form id="topsecretuploadform" method="POST" action="/path/to/file/upload/handler" enctype="multipart/form-data">
 <input type="file" name="topsecret">
 <input type="submit" value="Let the world see it">
 <iframe id="topsecretiframe" name="youcannnotseeme" src="" style="display: none;"></iframe>
</form>

You will need some JavaScript to set the target of the form.

You need to set the target to the name of the iframe. If you do that, the HTML generated by the server after it has processed the upload will be sent to the invisible iframe.


jQuery(function($) {
 var iframe = $("#topsecretiframe");

 $("#topsecretuploadform").submit(function() {
   this.target = iframe.attr("name");
   iframe.get(0).processContent = true; // The use of this flag will be explained
 });
})

You will need some JavaScript to tell the user that the upload is complete

jQuery(function($) {
 $("#topsecretiframe").load(function() {
   if (!this.processContent)
     return;

   var iframeDocument = this.contentWindow || this.contentDocument;
   iframeDocument = iframeDocument.document ? iframeDocument.document : iframeDocument;
   var iframeBodyElement = iframeDocument.body;
   // The 3 lines above is a really easy and cross browser way of getting the body of the document object of the iframe

   // Assuming that we know certain elements will be present in the returned HTML after a successful upload,
   // the code below shows how you can know from the script.

   var someHtml = $(iframeBodyElement);
   if (iframeBodyElement.find("div.successfulupload").length > 0)
     alert('Upload done successfully.');
   else
     alert('Oh shit. Upload went fubar. Look at your logs.');
 });
});

Caveats

The reason for the processContent flag.

Some browsers will call the iframe onload function the first time it loads (with empty content). Some don't. If that flag didn't exists, using our example, some users will be alerted of something that haven't even started doing.

Iframe names must be set statically.

Don't do this:

jQuery("iframe.thosehackyiframes").each(function(index) {
 this.name = "wahooga_" + index;
});

From my testing, that does not work. Set them in a static way.

So

So, you get dynamically uploaded files without XHR. In between the form submission and the iframe load function call, you can insert all the bells and whistles. You may actually want some sort of animated waiting gif. But that's something I'm not going to talk about.

Hope this helps.

Paying the Price of Ignorance

2009-06-23T18:48:00.004+08:00

Once upon a time, there lived a community in a small town by a river. There were not many of them. The whole community was about 60 persons. Everyone lived in harmony with each other. There was little to fight about.

As good as it sounds, the town was not without its problems. It had a poor drainage system. Couple that with how close it was to the river, they had major flood problems whenever the rain kept pouring.

For generations, the people were taught that the flood could not be avoided. The only thing they could ever do was to prevent as much water as possible from going into their houses. And so it was, for many generations. And it worked. At least, before it reached the size of 60 persons.

When there were more people, the deficiency of the poor drainage was even more obvious. There were more trash and houses. The drainage system couldn't keep up. Although raised as a problem every now and then by the community, there were never actions taken to address the drainage system problem. To those who ran the town, revamping the drainage system was too much cost. The flood never happened often enough to justify and every time it happened, the people were able to prevent too much damage.

To some of them, the ever growing population was enough to keep the damages low. People just needed to help each other when there was a flood. Also, the post-flood town rebuilding works really kept them too busy to do anything else.

And that remained for many many years. If there was one thing constant about the town, it would be the way they recovered from the floods. The total damages rose higher and higher as the population grew. The recovery time took longer and longer. Year by year, they got busier and busier.

In short, everyone in the town was minimizing the burn, but never took time to take out the flames. In the end, they got incinerated.

I think, things would've turned out better if:

The mayor had admitted the deficiency...
and invested early on for a better drainage system, before it became a huge undertaking.
The people didn't believe that orchestrated water scooping activities as a testaments to their unbelievable team work..
and put their efforts to innovative solutions to the root cause of the problem, not its symptoms.

Live and die by decisions

2009-06-11T23:15:00.002+08:00

To some of us, making decisions is probably one of the hardest things we have to do. I guess it's fair to say that we often want to make the best decisions, and if possible, to not be accountable for the undesired consequences. But I find it ironic, because I see decisions as creating consequences. When a decision is made, the one who made it is accountable for the consequences, be it good or bad. That's because he asked for a change the moment he decided, and it's his change, really.

Everyone has to make decisions.

I'm not a decision making guru. I have not made half a billion of decisions. But I've been making some and I've been exchanging a lot of thoughts with people who make a lot of decisions. In all honesty, the methods are crap. Not because they don't work. They probably work very well for those who shared with me their techniques. I think they are crap because everyone makes decisions differently.

Some people make decisions based on a thought process. Some make them based on experience. Some based on hunches. There are probably a lot more... but the methods are not what I'm writing about. I'm writing about what happens after decisions are made.

When you're asked to make a decision, know this:

Most of the time, it does not have to be immediate, but when you make it, it has to be firm. The last thing you want to show your people is that you're an indecisive decision maker. When you make a decision, you set the motion. Everything starts to roll based on what you said. It's a terrible thing to do to tell the motion to stop, rollback so your people could be in for another set back. When you feel that your decision is right and you have justifications to yourself why it is right, stick with it.

Don't doubt yourself every 5 minutes and change the decision every 30. The people who need your decision is not a text editor. You don't type, reread, and backspace all you want. When you have decided, stick with it, and make the best out of it. But of course, you should never be...

A stubborn ass (the animal, but feel free to interpret with the other meaning). Decisions can be wrong. I think it's important to keep an open mind when someone challenges your decision. In fact, I think it's awesome when someone challenges your decision.

I can understand how some of us might feel 'mocked' or disrespected when our decisions are challenged. But think about it in another way. After we have made a decision, can we ever be sure that our justifications for it is the only truth? My take: No. Never.

To me, the only way I can be more confident of my justifications is by them surviving challenges.

But of course, you can't always be wrong. Sure, you've probably made some bad ones, but my observation tells me that if you're smart enough that you're asked to decide on certain things, you will never always make the wrong ones. When your decisions are challenged, communicate properly and let them know your justifications. Feel free to let those who challenge you know why you think they are wrong, if you think they are wrong. Like you and I, they need to make mistakes to learn. If they never make any, they are not smarter than the day they are right.

Of course, if you made a bad decision, the best thing you can do is to admit it. Admitting a wrong decision is not about saying you're incompetent of deciding. Admitting a wrong decision allows its corrections. If you're making a decision for your team, it also sends a stark reminder to your team members that anyone can make mistakes. To some teams, it makes the leader more 'human'.. and being human, that means he's more approachable and also someone they can challenge.

Ultimately, that results in better decisions.

Things to remember when writing dynamic Confluence macros

2009-05-17T11:57:00.007+08:00

When writing macros in Confluence that rely heavily on JavaScript, I think it's good to always have a list of do's and don'ts. At least, I have.

Note: This is a product specific application of Cleaner JavaScript with jQuery.

Here's a part of my list (which exists only in my mind and it's quite long, so I'll just name a few that I think are most important).

1. Use the jQuery alias '$'

Because jQuery is 5 bytes longer than $ and we want to keep our content small. '$' is safe to use if you do it correctly. For instance:

jQuery(function($) {
  // '$' will definitely refer to jQuery anywhere inside this method and
  // you don't have to worry about JS libs like Prototype screwing you 
  // up unexpectedly.
});

2. Don't use element IDs

Because macros can be included in a page more than once and there isn't a reliable mechanism available to a macro that helps to guarantee ID uniqueness. Use CSS classes to pick up instances of your macro. For instance:

In a macro that generates the following HTML:

<div class="mymacro">
  <!-- New functionality -->  
</div>

In a static JS resource required somewhere

jQuery(function($) {
   $("div.mymacro").each(function() {
     // does something
   });
});

If implemented right, you don't have to worry about element ID uniqueness or "unexpected" scenarios that can cause duplicate IDs like the usage of {include}.

With that approach, it's much less likely that instances of your macro will interfere with each other.

3. Avoid the use of inline JS

Because things like this doesn't look so nice.

<a class="worldPieceInAClick" href="#" onclick="javascript:foobarThatReturnsFalse()">Print more money.</a>

In the absence of JavaScript (like when your page is emailed), the link should do nothing. That can be done by doing something like the below (based on the code above).

<a class="worldPieceInAClick" href="#">Print more money.</a>

In a static JS resource somewhere

jQuery(function($) {
  $("a.worldPieceInAClick").click(function() {
    // Do something fun?
    return false;
  });
});

If the static JS resource is not available, clicking the link is a no-op.

4. JavaScript needs i18n love too.

Have we seen hardcoded user-viewable messages like this?

In a static JS resource somewhere

alert('Uh oh, something is wrong. Duck.');

With code like that, the user won't be aware that there is something wrong if he can't read English. But the problem is, static JS resources are not generated using Velocity, so it's impossible to have a localized version of it? Not really.

Tip: JavaScript can read anything in the DOM. So:

The better way is this:

<div class="mymacro">
  <fieldset class="hidden">
    <input type="hidden" name="somethingiswrong" value="$i18n.getText('somethingiswrong')" class="mymacro-i18n">
  </fieldset>
</div>

In a static JS resource somewhere

jQuery(function($) {
  mymacro = {
    getI18nMessages : function(myMacroDiv) {
      var i18nMsg = {};
      myMacroDiv.children("fieldset.hidden").children("input.mymacro-i18n").each(function() {
        i18nMsg[this.name] = this.value;
      });

      return i18nMsg;
    }
  };

  $("div.mymacro").each(function() {
    var myMacroDiv = $(this);
    myMacroDiv.find("a.somethingiswrong").click(function() {
      var i18nMsg = mymacro.getI18nMessages(myMacroDiv);
      alert(i18nMsg["somethingiswrong"]);
    });
  });
})

5. Think about how your macro will look like in PDF, HTML export, Email and RSS

For instance, the hidden loading icon will probably show in RSS.. and in RSS, you don't have CSS (or you have CSS with broken arms and legs).

For trivial macros, I like to have flags that decide whether or not to generate those "active" elements. For more complex ones, I prefer to have a "static" template.

Surviving the resume scan

2009-04-26T10:36:00.016+08:00

While I understand the notion of starting a post with "It has been a while since", I really can't escape from it. I've been looking for something to blame for that, but everywhere I look I just see myself. So rather than to start a post with a similar phrase next time, I'll just say "Read the next paragraph", maybe. Since that's for the next, I'm going to start things off. So, it has been quite a while...

Work is always busy for me. But these recent weeks, hectic would be an understatement. There were surges of meetings and interviews that I had to go to that took a lot of time. It's very typical for a meeting or an interview to take up to an hour or two, depending on the agenda or the position that we're looking to fill.

Before interviews, resumes have to be read. Certainly, that is not a specialized task that one does 8 hours a day. It is most probably an additional responsibility of the interviewer.

Despite the squeeze, resume scanning is crucial. It can determine whether the company gets/misses the correct person for the job or if the interview is going to be a waste of time. Unfortunately, depending on the times, there can be a flood of resumes that have to be scanned. When that happens, your resume will have limited time to tell your potential employer why you're the guy/girl for the job.

In other words, your resume will only get 5 minutes of the interviewer's time. Maybe less.

So, to increase your chances in what I would call the 5-minute window of opportunity, you need to help the interviewer to help you. That's pretty much like what Jerry Maguire said. So you have 5 minutes. What should you do?

Have a proper email address

Email addresses like funboy23 at hotmail dot com, ilovedavidarchuleta at yahoo dot com, darkmayor at gmail dot com, c0d1ingu7r at hotmail dot com (my apologies if any of the mentioned addresses are real) look really bad. Why? Because that's almost like walking into someone's wedding with shorts and holding a bottle of beer smelling like a typical public Malaysian toilet. A proper email address tells your potential employer that you're serious. That's important because your potential employer will certainly be.

Move less relevant details elsewhere (or remove it)

Some examples of less relevant details would be your looks, gender, race, home address and hobby. When an interviewer is scanning resumes, he or she is looking for someone that can do the job. How you look, whether you're a male or a female or what you like to do in your free time doesn't tell the interviewer that. In fact, I think in some countries, it's not recommended to have those details in your resume as it might cause some discrimination.

Recent jobs with achievements

Start with the current employment (if any) and the most recent ones dating as far back as appropriate. Unfortunately, there's no hard and fast rule how many years you should go back. However, from what I've seen so far, three to four years is a good enough limit. Most interviewers look at the employment history to see if you're doing things that are relevant to the position they are hiring for in the recent years.

By the way, if software engineer is the position, my personal take is that anything that you've done over four years ago should be irrelevant by now.

It's also important to highlight your achievements in the list. They don't need to be measurable. But being able to tell your potential employer about your achievements is a good thing because they can gauge how competitive you are in the things that you did that are relevant to the position.

Skills set

Again, only list the things that are relevant. I think most of us have a very long list of skills, but in a resume, you should only list those that are relevant to the position you're applying for. While it may be true that some of us have unbelievable Excel hacking skills or insane Word pretty-fying capabilities, they are not related to the position. It scares me sometimes to see those skills listed in a resume. Whenever I see those skills, two thoughts will usually come across my mind.

1. Is the applicant listing those skills just for the sake of filling up the 10-skills list in a resume template?
2. Does the applicant know what he/she is applying for?

Seriously, having a long list of skills does not mean you are immediately in the impressive list. Often, it's better to have a short list of skills that are relevant. Long lists with irrelevant ones actually look bad.

Referrals

I doubt if referrals are ever contacted in the 5-minute resume scan. The information could be used post-interview, however. But I don't think that happens often at all. Personally, I don't think referrals paint an accurate picture of the applicant.

Most referrals are former supervisors or bosses. They are in one family — people that used to work with you in one of your jobs. While I don't think they'll lie, I believe that they are unlikely to provide the complete picture of you that they have in their minds. For many reasons.

If you have to have referrals, try to get customer referrals.

Having a short and accurate resume increases your chances of being selected. It will save your time and the interviewers'. You get good karma from it.

Happy 1234567890!

2009-02-14T09:21:00.003+08:00

1234567890 seconds since Epoch!

Zune didn't break, this time

David's 3-step weekend train wreck prevention

2009-02-09T14:35:00.003+08:00

If you found yourself having gone through really hectic weekends on some random occasions of retrospection, you'd probably think you'd rather be at work if you have to go through another one. You might also be thinking that you're insane having thought of that, but actually, you're quite sane.

Most of the sane people that I know (yes, fortunately, I do know some insane people — they tell me I'm not) want to have uneventful weekends. Uneventful here doesn't mean that you lie there on a couch waiting for a bum rot. Uneventful means you don't get unexpected events that stress you out in what is supposed to be a "stress recuperation" period.

Here are some events which I categorize as "unexpected".

Breakfast, lunch or dinner invitations that can only be attended if I can manipulate time-space.
Oh-shit-I-forgot-about-X panic scrambles.
Random tasks that I only thought of doing when I look at myself in the mirror in the morning (haircut, etc).

These are the things that will burn your weekends. If you want your weekends to be "uneventful", you have to minimize unexpected events. Here is my 3-step approach to preventing a train wreck weekend.

1. Identify
Before your weekend begins, you need to think about what you want to get out of it. You need to identify your objectives. It doesn't matter if your objectives are too weird to be even thought about (like watching TV in the nude), you really need to identify them. For me, my objective is simple:

Maximize slack time — Means I want to have as much free time as possible in between tasks and the delays on them do not have any significant effects on my next weekend.

With objectives defined, you need to identify what your blockers are. Blockers are the things that prevent you from getting to your objectives. Taking my usual objective above, my blockers are usually:

Appointments — They don't die. They just get postponed.
Chores — These are elephants. They don't forget about you. When the time is right, they'll stomp on your face.

Once your objectives and blockers are identified, you need to...

2. Plan
To me, planning is an overhead that can only be done on future events that you have a good idea of their happening. If you're planning for unexpected events, you need to stop drinking. Period. Planning for unexpected events is a mistake. If you're planning for something that can't be planned, you're screwed.

So, with that in mind, what can we plan for? Well, bring up your calendar and ask yourself these questions:

What are the things that will happen throughout the weekend? Are they plotted on the calendar? If they are not, do so now.
Look at your blockers list. Are they also on the calendar? No? Do it.
Does your calendar now say you have to manipulate space time? It does? Then do either of postponing or victimize, whichever applicable. If you postpone, make sure it's on your calendar.

Now that you have a rough plan for your weekend, it's time to think about its optimization. How I usually go about this is by location. Which events will happen at nearby areas? It's probably better to block a period of time for events that will happen in nearby areas. For instance, if I need to be at the dentist at 11:00 a.m. at a place which is about 5 miles away from where I am going to meet my insurance agent later at about 2:00 p.m. and I need to have lunch in between, it's probably better to group these events. Why not just:

Reschedule the meeting with my insurance agent to lunch time, at the same area where I am going to see my dentist.

At this point, you may be thinking that rescheduling is an anti-plan. Yes, I admit that rescheduling means that the plan is screwed up, but an early reschedule has almost the same meaning as a far-from-release-date-software-refactoring. Good software gets refactored all the time and that allows for better software. For a plan, an early reschedule allows for better time usage (better plan).

When you ask for a reschedule very early on, you give enough time for the affected people to reorganize their plans. When there is enough time for involved parties to change (plan-wise), time will not be wasted and priorities can be met. It saves on the profanity factor as well.

Now, after you have optimized your plan, you can see where you can spend time achieving your objectives. But wait, it seems now that the objectives have the lowest priority?

Well, actually, no. They're still at the highest. In any effort to achieve certain objectives, there will be blockers to overcome. If you ignore your blockers and just go straight for the objectives, your view on your objectives is tainted. The reason behind that is when you have "achieved" your objectives by cutting certain corners or efforts, what you have achieved is a subset of what you have set out to. That's why I don't consider achieving objectives by ignoring everything else is really achieving objectives.

Cool. There's a plan, now what?

3. Stick
I think, this is the hardest part for most of us — To stick to the plan.

It's quite common that unexpected events happen in your weekends and that you actually want to attend to them. For instance, a sudden invitation to go for some drinks on a Saturday night. If you have the buffer for it, I suggest that you go. But if you don't (the time and place of the invitation collides with what you have on in that period), I suggest that you take a rain check on it.

It's a bit harsh, isn't it? Well, no, again. If you really want to be participating in that Saturday night hangover-in-the-making session, and you think that whatever you have at that time can be victimized, the objectives that you've set for that week are wrong. But didn't I say that unexpected things can't be planned? Yes, I did. However, you can have a backup plan.

If you really want attend the Saturday night session, you must anticipate for it. Instead of plotting one concrete thing for the period of time that you anticipate the drinking session will be on, plot two. For me, I'd first plot a period of time on Saturday night for meeting friends up. Then I'd plot one more thing that I have full control of that I know I can do anytime without affecting anyone.

For instance, I can make any of the following a backup plan:

Finish reading XYZ.
Clean my room.
Gather receipts for the coming income tax scramble.

If drinking does not happen, I can do something with that time — it doesn't turn into yet another unexpected period of time available for something else.

Of course, you don't want too many anticipations to be in your plan. Otherwise, it's as good as nothing.

So there you have it, David's 3-step weekend train wreck prevention.

Why infrastructure is gold

2009-01-29T02:24:00.006+08:00

As part of my continuous efforts to settle my imaginary blog debt, I have decided that for the rest of the year, whenever I can, to write blogs about events happening to and around me as soon as they happen.

I returned a call to a friend last night. This friend, who I will call Winston from this point onwards, is one of those friends who you know, that when he looks for you, it is usually of something urgent that requires your assistance.

Winston is now a consultant in his company. It has been long since his last call, but since it's the Chinese New Year holidays now and most of everybody I know would be taking advantage of it, I returned his call with the thought that there must be shit that has happened that I could help with.

So I rang up, and I got to him. His question to me was:

"Can I ask you a Linux question?"

At an instant, I felt a surge of fury. I did not know why then, but now, when I think about it, it must've been caused by one or more of the following factors:

DATAJA
I'm curious why I am suddenly TLDP
I'm already in happy land, it gives me the right to forget everything Linux

Fortunately, I was able to control the anger and didn't manage to shower Winston with much love. So, I listened and the real question was (in more or less exact words):

"Help! My CVS users can't check out files and the error related to it is sufficient disk space. I've freed up some space in all related partitions, but it still doesn't work. Any ideas?"

The processing model I have in my brain for this kind of situations is a two-part:

Do I care?
If I care, ask for more information. If I don't, offer a generic piece of crap advice and look like I do.

And so I told Winston, "My, that's a strange problem. Probably worth to take a backup of it and rebuild the server". Of course, I am quite sure that the box he is using as the CVS server has no meaningful purposes other than the one that doesn't currently work.

As you would imagine, no one is going to take that crap advice immediately. So the conversation prolonged and in my last-ditch effort, I told Winston to transfer the CVS server to another box so that in the duration he rebuilds the server, his users are not completely blocked... and this was where the point of hell fury started - He told me even more stuff that I didn't care.

He told me that investing on another box can't be justified. Then he went on rambling that his company is no longer the Java-only company that relies on the CVS. He can't afford too much time in that too. He'll probably pass this back to his colleague.

So I just told Winston that if I were in his shoes, I'd rebuild the server. End of story.

I would've questioned his generosity in providing me with more information if he wasn't a friend (or someone who I didn't find the relevancy of ending on good terms with).

What would my questions be?

Why on earth is a consultant doing a sysadmin's job?
And being totally clueless about it?
And being defensive for his incompetencies?
And assuming the CVS is only for Java??
And doing the consulting shit on me when I told him to transfer the CVS to another server?
And who said anything about purchasing another box?

It's easy at this point to say that Winston is the problem. But that would be wrong. It's not his fault. If you look at the first question in the list above, the key is the answer to why a consultant is doing a sysadmin's job (and possibly fucking it up).

The answer is simple: The infrastructure provided for cross-team support isn't strong. Winston's company does not have an internal support team. That's why Winston was screwing up.

In contrast, I am now working in a company that has an excellent support team. Man, these guys are awesome! Not only do these guys free us up from internal maintenance, they also constantly upgrade our infrastructure so we are always supported to perform at our best. Without them, I think we'd be miles behind where we are now. My hat's off to them.

So if you're running an IT-based company, especially in services, please please puhleeze setup a crack support team. They'll do your company a lot of good.

Being a good developer

2009-01-26T21:33:00.003+08:00

Every now and then I get this big question. Now, what I'm about to write does not indicate I am the best chest-beating developer ape out there, but it's just that it has come to a state where responding to that question has become unbearably repetitive. Instead of reiterating over and over again, I'll just write a blog post and redirect people here and hopefully, this blog post will be the ground-zero of a ~~flame war~~ discussion.

First, I have to congratulate you that you asked that question. That is, really, the first most important step. If you want to be a good developer, you need to know you want to be... and it's only people who ask that question that will successfully become good developers.

There are many traits that a person should have to become a good developer, but I'll just list down the 5 that I think are most important.

1. Passion
You have to want to do it. More often than not, the most obvious difference between the good and the average developer is the presence of passion in them. Development is a crazy task. When you're developing, you're creating tools that people will use in their work/personal lives. These are the people who have chosen your software after comparing it with others. They chose your software because they think it will help them with what they want to do.

Now, for you, as the engineer, you have to care about your software. When you ship that software to your users, you're basically telling them that you're able to help with their problems. So, you really want the software to work as good as it can. If it doesn't, your users will be be stuck and you would have failed them. While it's true that there will always be bugs with software, it's not an excuse to be careless with it.

Think about it this way. When software doesn't work, it's not immediately fixable. It's not like a spelling mistake which you can bring an eraser to (the root of the problem) and fix it on the spot. When it doesn't work, it usually means that the users will be stuck for a couple of months. If your users are depending on that software for a very important purposes, it will be a painful experience for both parties (one of them you).

So, you really have to have the passion to write software great.

2. You write tests
Testing is a very important part of development. I don't care who you are, but I can assure you that you can't be certain whatever you have written works until you have tested it. Simple as that. A good developer is one who will write tests to validate their own work. For instance, if you're writing a function that calculates the Fibonacci of X, you'll really want to write tests which validate that function (by examining its return value) with various arguments. Only then can you be sure that you're not writing stuff that doesn't work.

But what if you have a dedicated testing team? Believe me, there were times I got so disappointed after hearing developers blaming the testing team for "unit test" kind of bugs in post-production event meetings. His argument implied that the testing team didn't do their jobs well enough. Here's the thing, testing teams are supposed to find tricky or edge-cases bugs. If they have to validate the developers' work at the "unit" level, who's going to cover the tricky bugs?

As a good developer, you want to write tests to make sure that software at least work the way they are supposed to. You have to accept that testing is part of your responsibilities.

3. You have little patience for things that suck
Unfortunately, no application code can be free from suckage. Look closer and you will definitely find code that is functional but dodgy. A good developer will be able to identify that and will remember it until the next engineering meeting. He or she will then bring this up with the hope that the fix will be included in the application's roadmap somewhere not too far down the line.

So why is this important? Well, that's because good code promotes goodness stack-ability. What does that mean?

Good code will have lesser bugs.

That means less time is needed to fix it.

That means there is more time to do something else with the code, like make it better.

That means maintaining the code will be easier.

That means it will be more likely that other developers would want to make it better.

That means it will have even even lesser bugs.

While there could be times when a number of roadmaps will have significant quantities of "refactoring" items, I think that will pay off in the long run.

4. You dumb down the source.
A good developer solves complex problems in very simple ways (or the simplest ways possible). While software complexity can't be avoided (you're building a solution afterall), it can be minimized. From my experience, software complexity has a lot to do with the number of code paths in it - the number of if-else.

A lot of development problems can be solved with minimal changes to the code. That's the easy way and it usually includes adding if-else to the code base at various places. While that might solve the problem at hand, it creates another. Due to that, the software will become more complex, harder to maintain and isn't as self-documenting.

Let's take the problem of processing the 'A' in a set of A-Z and how a good developer might approach in solving it.

Instead of looping through each element in the set and only doing the processing if the element being checked is 'A', it's actually simpler to just sort the set in ascending order and process the first element.

A good developer should always seek to solve problems in the simplest, most elegant ways.

5. A good developer communicates.
If you're in any serious development team, issue trackers, source code management systems, build servers, roadmaps and so forth should be familiar to you. But what do these tools have to do with communication? Well, they are all made for that - to communicate different aspects of development projects to the people involved. Being a good developer, you should make full use of them. For instance:

If you notice someone committing a feature that is suppose to be in the next version, you should talk to the developer in question and figure out what is going on.

If you notice that an issue was resolved without a fix version, you try to find out what it is and populate that information. If you can't, always talk to the issue owner about it.

If you notice stuff (like IDE workspace files) getting checked into the source repository (and you know that they shouldn't exist there), you should go and talk to the other developer about it.

If you find that the roadmap's timeline is impossible, you need to raise the problem/concern to your project manager.

... and the list goes on. The point here is that as a good developer, you don't close your eyes on problems you noticed. You and every one in the team must be at full alert to cover each others' backs. If anyone is going to notice problems with development projects early, they will be the developers and that is when the problems are usually still fixable.

So there you have it, the five things that I think a good developer should have.

Email notifications + static web page resources = fail?

2009-01-25T12:09:00.005+08:00

Aren't non-inline JS and CSS good things? Well, yes, they are. Unfortunately, content with non-inline JS or CSS does not work properly in emails. Take a typical web application that emails users of changes to certain pages that are authored by users themselves. It is very likely that there is an option somewhere that says, "Include the whole page in notification emails"... and sure enough, the whole page, along with all of its links to the required static resources like CSS are included in a (HTML) notification email.

Unfortunately, complex content like that usually break in emails and that's usually due to missing items in linked resources. For instance, CSS classes.

Email (or to some, e-mail), this relic of technology just refuses to die. Perhaps, it is Utopia or perhaps it's just something so integral to us, just like how we like to use our mouths to eat. For whatever reasons keeping it alive, I have ceased to care.

One of the biggest problems with static resources is that they are usually protected. Email clients won't know how to authenticate to the servers hosting those resources in order to download their contents. For instance:

A protected image source --- <img src="/blah/email.gif" />

A protected frame/iframe source --- <iframe src="/blah/must" />

A protected CSS resource --- <link ref="stylesheet" href="/blah/die.css" />

A protected JS resource --- <script src="/blah/horribly.js"></script>

The above are just some of the infinite number of ways how the rendering of web pages can be broken in emails.

So, what can we do about it? Think different. Viewing web pages through email is like studying natural animal behavior from the safety of a zoo. Instead of trying to make it work, let's rethink the whole problem.

Why do we want notifications? We want to know the changes or related mutating events that have happened since the last time we checked. Quickly, that. Does showing a broken web page in email help? Probably, if the viewer knows historically what was broken before and is able to do a manual version comparison in his head each time the page is viewed.

So, to make it obvious, the purpose of notification is to highlight changes quickly.

So, what can we do for complex content?

Well, how about this? In notification emails, in place of the full page being shown (possibly broken):

Show the change comment in an unmissable manner, like make it notoriously big. In case of no change comment, say something like "User has not specified change summary.".

Show the changes in text

Provide a private link that when clicked on, will open the user's default browser up and redirect the user to the changed page. The difference between a private link and a normal link is that a private link does not require authentication, and of course, is private to the email reader. The private link will also expire after a period of time.

While what I'm suggesting might seem to be targeted at certain types of applications, I think this idea can be easily adapted to any system that make use of emails for notification purposes.

Cleaner JavaScript with jQuery

2008-12-14T09:31:00.007+08:00

I've been doing some widget/portal-ish (which I'll call components from this point forward) JavaScript stuff lately. Along the way, I discovered a few common faults to those components in that context and learned how to fix them. Most of them boil down to:

The uniqueness of element IDs in documents are overlooked. When developing components, it is very likely that it could be used more than once in a page. While generating elements with specific element IDs is straightforward, it might cause problems when the component is used multiple times in the same document.
Often, massive JavaScript and CSS are coded inline to the HTML elements. That's not ideal for performance... and to some degrees, even contribute to the problem mentioned earlier.
Internationalization doesn't exist.
Pollution of the global JavaScript namespace. In many circumstances, the objects that we have in the global scope can be reduced. There are components which try to improve that area by creating global JS objects with name space components. (e.g. com.foo.bar.mywidget). However, I believe that the best way is to not have global objects if possible.

So, what can we do about them?

Solving 1

If element IDs are really needed (and that CSS classes for jQuery selection isn't fitting), assign them on DOM ready. For instance:

jQuery(function($) {
jQuery("form.myform").each(function(index) {
jQuery(this).attr("id", index);
});
});

The code above will find all instances of the component (assuming that it generates <form class="myform"> for each usage) and allows you to truly assign unique IDs to each instance of your component.

Solving 2

With the practice above, it is possible to remove JavaScript generation by components. All that is required for that is to generate elements which can be selected (by jQuery). A common technique is to generate elements with CSS classes assigned to them and use jQuery to select them based on the CSS classes. All JS initialization on elements in a document should be done on DOM ready as well, by registering hooks to jQuery.

Event handling can also be initialized on DOM ready. Inline event handlers like the one below can be eliminated.

<input name="foobar" class="testClass" type="button" onclick="doSomething()" />

A better way to do it would be something like this in a static JS linked from the page.

jQuery(function($) {
jQuery("input.testClass").each(function() {
jQuery(this).click(function(event) {
alert('I am clicked.');
});
});
});

Therefore, with hooks like that, it is possible to generate HTML that is completely free of inline JS and CSS (which are not cacheable). It's a big problem when a page is massive, especially with most things redundant. Putting JS and CSS in static resources makes them cacheable. When they are, browsers don't need to download so many bytes.

Solving 3

Have we ever seen something like this?

// When something is clicked, pressed or whatever
alert('Oh hi, I just upgraded your RAM.');

That is not ideal because it prohibits internationalization. It's impossible to have localized messages for those events, even if presentation of the page is localized. Now, don't we all agree that inconsistency doesn't look too good?

But wait, if we are going to internationalize JavaScript messages, don't we need to generate it, which makes static JS impossible? Well, not really. What we can do is this.

Put all our i18n messages in a fieldset, or anywhere we think is suitable that can be addressed by our JavaScript. I like to do this.
```
<fieldset class="hidden">
<input type="hidden" name="i18n-iupgradedyourram" value="Localized message" />
</fieldset>
```

Then, read all of those i18n messages into a JS object like this:

function getI18n() {
var messages = {};
jQuery("fieldset.hidden > input[name^='i18n-']").each(function() {
messages[this.name] = this.value;
});

return messages;
}

Now, whenever I need the localized messages, I'll just call the function defined above and get them from the returned object, like this:
```
// When something is clicked, pressed or whatever
var messages = getI18n();
alert(messages["i18n-iupgradedyourram"]);
```

Solving 4

The idea behind this is that if JavaScript objects do not need to be globally addressable, why put them there? For instance, if you have a component called "ram-upgrader" and it creates a JavaScript object called "ramupgrader" to render itself, it's most likely that the object is only useful for ram-upgrader. Other parts of the page probably don't even need to know the JS object exists.

So, instead of doing this:

var myfunobject = {
doSomething : function() { }
};

jQuery(function($) {
myfunobject.doSomething();
});

It would be better to do:

jQuery(function($) {
var myfunobject = {
doSomething : function() { }
};

myfunobject.doSomething();
});

With those practice in place, it's easier to write JavaScript applications that are both cool and robust... and JavaScript code directly interacts with the user. Getting that right has a direct effect on what users feel about our applications.

The cost of growing your own lightweight library

2008-10-29T22:50:00.004+08:00

So you've spent some time investigating some popular libraries you might want to use in your brand new application . However, you figured that based on the current requirements, you don't need all those functionalities in the libraries. They (the libraries) are, in a sense, overweight. It's like ordering the classic ribs from Tony Romas but only eating the mashed potato.

... And you were right, at that period of time at least. I believe it is fair to say that most of us would come to the same conclusion. However, was what beyond that in our consideration when we concluded that way?

Let me give you an example - JavaScript libraries. Most web applications are built with more static content than dynamic. That basically means JavaScript is a supplement for the user interfaces of those applications, not the core. So when those applications were being built, the authors probably did not need a full fledged JavaScript API like jQuery.

Assuming you are building an application like those mentioned in the previous paragraph, you would probably need ten "lightweight" generic JavaScript functionalities that can be reused throughout the application. With that, you've grown your own JS library. From there, it's easy to see you might want to distribute the library. I mean, afterall, it would be useful for developers who are building similar applications like you.

So, what's wrong with that?

None and something. The answer differs depending on when you ask that question. If you ask that question when the library is still fresh dogfood, nothing is wrong. However, if you ask that question one year later, you'll see the problems.

But before I elaborate, let me state the likely purpose you built the library for. The keywords here are "lightweight" and "fast" (be it application performance or development/testing time). With that, let's move on to the events outlined below.

You had a 1.0 milestone to hit and you built the web pages and the decorating theme.
As the application moved towards 1.0, you got more and more requests for dynamic elements in pages.
You had limited time to investigate in suitable libraries and reached a conclusion that they were too heavy based on the number of functions they had or the number of parameters you needed to pass into the methods you regularly use.
Based on the gathered information, it was logical to grow your own library (JS)... and so you have.
Application reached 1.0.
After 6 months, the application reached 1.5. With that, even more requests for dynamic elements in pages.
To meet the requirements, the home grown library was, well, expanded.
Then came 1.9 with its unimaginable amount of dynamic element requests. Then you took a step back and looked, and you realized:
- The lightweight library you've grown was no longer lightweight. The original purpose of the library became irrelevant.
- The size of it rivals the size of other similar libraries, which have proven to be more mature since you last looked at it.
- The home grown library is not as well structured as you would like (but that's a really nice way of saying "complete mess").
- You've got too many pages in pre-1.9 to refactor if you want everything to be standardized into a new library.

So you're stuck with your own library. Now, if it isn't grim enough, people who adopted your library will be stuck in the same manner, if not already.

All that is just to say that if you need generic functionalities which the core programming language doesn't provide, use a library. Your concern is to build the application. Library builders do not share the same concern. They are mostly concerned with building a well structured API that is useful to many application builders like you. They dedicate their time to do that... and that, is not a luxury that you have as an application builder.

So, leave specialized jobs to specialists.

Flexi Blog Posts Plugin 1.0 released

2008-10-26T14:35:00.003+08:00

Just recently, I've developed a macro for Atlassian's Confluence which renders blog posts in a dynamic table. Dynamic really means:

You can sort the table by clicking on the headers.
You can resize the table by dragging the table edges.
The results shown in the table are generated in an AJAXy like manner -- no page refresh.
... and the results are paged. So you can navigate them page-by-page, saving a lot of space on the screen.

The macro is now offered by my company (CustomWare) as an Open Source Confluence plugin. Interested? Head on to the plugin's home page!

Hope you like it!

Worse than failures, now in a banking app near you!

2008-10-18T12:49:00.001+08:00

See

It is painful to read HTML correctly

2008-08-07T21:54:00.003+08:00

Have you ever tried writing a program that needs to read any HTML and display it correctly? I guess most of us have. However, to those of you who have, have you tried making it work with localized HTML?

Most of us who wrote programs that read HTML programmatically would make them read it from a stream of bytes. For instance.

InputStream htmlContent = httpMethodBase.getResponseBodyAsStream();

That's fair because whatever that comes back should be treated as binary, even if the content type is text. Why? That's because to read the textual content correctly, you need to interpret it using a suitable character set (charset). Hence, the question below:

If the content type is text/*, which charset should I use to interpret the stream?

According to standards, localized HTML should specify the character set it is encoded with as a parameter to the Content-Type header. For instance:

Content-Type: text/html; charset=utf-8

If the parameter is not specified, the program reading the content should interpret it using ISO-8859-1. Sounds simple, so far. At least, until you go to this page. It's filled with Japanese text, and yet, my browser (FF3) seems to interpret it correctly. Is that the magic of the parameter specified with the Content-Type header? You'll be surprised. The answer is no.

This is the output of Live HTTP Headers:

http://www.atlassian.jp/

GET / HTTP/1.1
Host: www.atlassian.jp
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008072820 Firefox/3.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: UTF-8,*
Keep-Alive: 300
Connection: keep-alive

HTTP/1.1 200 OK
Date: Thu, 07 Aug 2008 02:54:02 GMT
Server: Apache
Last-Modified: Fri, 20 Jun 2008 08:23:53 GMT
Etag: "a4006-33a9-45014d069b840"
Accept-Ranges: bytes
Content-Length: 13225
Content-Type: text/html

Note: Cookie removed from request headers.

If you look at the last line in the response captured by Live HTTP Headers, there is no charset parameter. So, how did the browser do it? The magic lies in a meta tag in the response below.

<html lang=ja xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>アトラシアン ジャパン - JIRA：画期的な課題トラッキング! CONFLUENCE：エンタープライズ ウィキ</title>
<meta http-equiv="Content-Type" content="text/html; charset=shift_jis">
<!-- Snip -->

Apparently, this method is preferred because if the HTML is saved as a local file and opened by the web browser again, its representation is intact – you'll still see the page as it is intended to be seen. That's fine.. until you consider how you should read the HTML correctly, programmatically.

Gathering from the pages I've read about this, to read the HTML correctly, you need to.

Check the charset parameter in the Content-Type header.

Note that if the charset parameter exists, you can skip the following step and assume that the charset specified is the correct one to use to decode the data. That's because standards say it is the one "true" value if it doesn't agree with the one in the meta tag.
If it doesn't exist, check the charset specified by the relevant meta tag.

To be able to do step 2, you'll need to read the HTML. Fine? Well, which charset should be used to read it? ISO-8859-1? Seems like you can't. ISO-8859-1 can't decode the HTML correctly. Just try browsing to the example page and view it with the ISO-8859-1 encoding. You'll see gibberish text.

Just before 2, you have two options:

Read it using ISO-8859-1 and hope for the best.
Read it using a user-specified encoding, and still hoping for the best.

Either way can't guarantee that you'll be reading the HTML correctly... and that sucks.

Reading HTML shouldn't be this complex. I really hope it is something that I have missed that is not the usage of a specialized HTML parsing library.

Drowning in worse-than-failures. This time, i18n.

2008-07-31T20:25:00.008+08:00

Have you ever seen code that accomplishes i18n by directly hardcoding the text into the source? Have not? Look at this.

httpServletResponse.getWriter().write("I am your rocking Servlet");

That's bad. It might be fine for exception messages (it's actually better to hard code exception messages in English). However, if you're writing a web front, you really need decent i18n. To those that have realized the importance of i18n, you would know that Java accomplishes this using properties files -- a huge set of key-value files where each localized message can be referred to using a unique key.

An i18n properties file looks like this:

# Snip
property1=Welcome to this web site
property2=I am your rocking Servlet
# Snip

A i18n aware application would load i18n files like the one above and "substitute" the text to be shown to the user with the key to the intended localized message. For instance, instead of doing the below,

httpServletResponse.getWriter().write("I am your rocking Servlet");

you would refer to the same message using its key, "property2".

httpServletResponse.getWriter().write(myResourceBundle.getString("property2"));

So, if your application needs to be translated to Japanese, all you need to do is to create another properties file with the same common bundle name but with the Japanese locale appended to it and translate the values.

So you'll probably end up with an i18n properties file that looks like this:

# Snip
property1=このウェブサイトへの歓迎
property2=私はあなたの動揺のServletである
# Snip

In most cases, the messages will actually display properly. However, the above is bad. Why?

The framework that you are using to build the web application probably is assuming that the i18n file is encoded with a specific character set. If the assumption is correct, you get your messages. If it is not, you will be scratching your head figuring out why your text appear to be gibberish. At that point, you probably know you have some sort of an encoding problem. I wish you all the best in fixing that if that happens to you -- debugging encoding problems is anything but easy.

Sure, maybe the framework you're using allows you to specify the character set to use when interpreting the i18n file, but then again, will you be certain enough to do so? What if someone rewrites the file in a different encoding?

There are just too many ways to fuck yourself when assumptions are involved, particularly in the context of encoding.

So, what's the "good" way? The answer is unicode escapes. You should translate your strings to "ascii-safe" characters that represent the Japanese text. If we take the example above, the properties file will look like this:

# Snip
property1=\u3053\u306e\u30a6\u30a7\u30d6\u30b5\u30a4\u30c8\u3078\u306e\u6b53\u8fce
property2=\u79c1\u306f\u3042\u306a\u305f\u306e\u52d5\u63fa\u306eServlet\u3067\u3042\u308b
# Snip

Localized i18n properties files that are constructed this way will be correctly interpreted by most (if not, all) character sets. However, how does one convert a string to unicode escapes? How about converting unicode escapes back to "normal" text for editing?

The answer is... native2ascii - A tool provided with the JDK specifically for those purposes.

To convert text files to unicode escapes, you just need to issue the following command.

native2ascii raw_japanese_bundle.properties myresourcebundle_jp.properties

To convert the escaped i18n properties file back to its raw form, just specify -reverse to native2ascii. For instance:

native2ascii -reverse myresourcebundle_jp.properties raw_japanese_bundle.properties

And that's it.

Mad streak of worse-than-failures. This round, the singleton.

2008-07-30T15:00:00.009+08:00

Singletons by themselves are evil, but are un-smart when with Spring. They make things very untestable. Code like this makes me cringe in disgust most of the time.

private static final MySingleton SINGLETON = new MySingleton();

public static MySingleton getInstance()
{
return SINGLETON;
}

private MySingleton()
{
/* Init stuff */
readValueFromConfiguredDatabase();
}

Assuming that readConfigurationFromPropertiesFile() makes a connection to a database somewhere, what problem(s) may arise (in unit testing) from that?

Your test will fail when MySingleton's class is initialized. If I recall correctly, you can't even get past the setup stage in your test cases.

Realizing the problem, some might change the code to:

private static MySingleton SINGLETON;

public synchronized static MySingleton getInstance()
{
if (null == SINGLETON)
SINGLETON = new MySingleton();
return SINGLETON;
}

private MySingleton()
{
/* Init stuff */
readValueFromConfiguredDatabase();
}

The above is bad because:

getInstance() is synchronized. This might become a bottle in your application.
If readValueFromConfiguredDatabase() throws some exception in the test because you don't have all the application configuration files in the test class path, you're screwed. Overriding it doesn't help because the getInstance() method still instantiates MySingleton and not a subclass of it.

Then, you might change the code to:

protected static boolean TEST_MODE = false;

private static MySingleton SINGLETON;

public synchronized static MySingleton getInstance()
{
if (null == SINGLETON)
SINGLETON = new MySingleton();
return SINGLETON;
}

private MySingleton()
{
/* Init stuff */
if (!TEST_MODE) readValueFromConfiguredDatabase();
}

Which might work but is just as bad. Other than being butt ugly, it pollutes the meaning of the code.

The good thing about Spring is that it takes care of the object instantiation stuff for you. You implement the beans, you tell Spring how to instantiate them and that's it. Spring makes your code simpler.

Why regex is one of the worst ways to read HTML

2008-07-29T20:46:00.003+08:00

How often do we find ourselves (or others) reading data in HTML using a regex? Have you ever been reading paragraph (<p>) text with regexes? For instance, you might start of with the regex below to capture all text between a <p>.

<p.*?>(.*?)</p>

Then you realize that there might be line breaks. So,

(?s)<p.*?>(.*?)</p>

Then you realize that <p> tags could be a mix of cases. So,

(?si)<p.*?>(.*?)</p>

Then you realize that there might be other tags between <p>... After a couple of iterations at fixing the problem, the regex has become so unbelievably complex, you don't know how you reached to create such a monster in the first place.

Still, you persist.

Then you realize there could be:

<!-- 
<p>Not needed anymore</p> 
-->

and that could be in JavaScript too.

Then you realize it is wrong.

The bottomline is this. Never use regex to read structured (and usually complex) data. It might be a quick way around some problems, but it will come back to haunt you. If you do that, you can count on that.

A more proper way would be to parse the HTML into a DOM. Then, using XML based technologies (XPath?), read the data in a structural way.

Yet another example of poor security in one of TMNet's many poorly written applications

2008-06-21T15:28:00.005+08:00

It took me 5 minutes to craft this "attack". Don't believe me? Click the link below:

http://tinyurl.com/6ayqv2

And you'll get:

User Friendliness At Its Best

2008-05-11T14:23:00.005+08:00

See rule #5 of Top Rules for the Windows Vista User Experience

The screen shot was shameless ripped from Eddie Kua's blog

The Real North Atlantic Treaty

2008-04-17T21:41:00.002+08:00

Picture taken from Terence Yung's photostream.

The Pain Of Writing An Isolated ClassLoader

2008-03-03T21:33:00.006+08:00

I've recently attempted something which I have been procrastinating for years --- to implement a Java isolated ClassLoader which has the ability to load classes from a JAR and the JARs in it.

Specifically, the ClassLoader must be able to:

Load classes from a JAR file

Load classes from JAR files inside the archive at a predefined location (inside of it). This has to be done recursively.

The source of the classes can be from anywhere which a java.net.URL can point to.

Load different versions of classes which have the same fully qualified name. If the containing application has already loaded x.y.Bar, the ClassLoader must be able to load a different version of it (if the zip file contains one). Think of it as a mini web application ClassLoader.

So, where did I start? Extending the ClassLoader, of course. I knew I had to override some methods of java.lang.ClassLoader. Obviously, my options were:

findClass(String):Class

loadClass(String):Class

I mistakenly started off by overriding findClass() (which turned out to be a horrible mistake. More on that later). To load bytes from a range of locations, I needed a URL. So, the ClassLoader contructor will take a URL as an argument. My idea was to call its openStream method to read the content of the resource at the URL, which must be a JAR/ZIP file.

At that point, I asked myself how would I read JAR files in JAR files. I could write the entire resource to the local file system first before reading the individual entries. However, the mess of expanding a bunch of zip files to the local file system didn't appeal to me. I wanted to open the resource on demand --- to open and read only what is necessary, and when it is necessary. After an hour, I finally settled on this approach.


protected byte[] getClassDefinition(
   final String fqcn,
   final ZipInputStream zipInputStream) throws IOException {
 byte[] classDefintion = null;
 ZipEntry zipEntry;

 while (zipInputStreamHasMoreEntries)
 {
   if (zipEntryIsJarFileAtThePredefinedLocation)
   {
     classDefintion = getClassDefinition(
       fqcn,
       new ZipInputStream(zipInputStream));
   }
   else
   {
     if (zipEntryMatchesTheClassWeAreLookingFor)
     {
       classDefinition = readContentsOfZipEntry();
       break;
     }
   }
 }

 return classDefinition;
}

The code basically says:

While we have not found the zip entry we are looking for or went through all zip entries, do:
- If current entry is a zip/JAR file, open a ZipInputStream from the current ZipInputStream and perform a recursive search into it.
- Else, check if the entry is what we are looking for.
  - If the entry matches what we are looking for, load it and break from the loop.

Return the loaded class, if any.

On a side note: if there is a better way than recursion, I really would love to hear about it.

That took care of loading classes from a JAR file or the JAR files in it... and that, from any location which a URL can point to. However, at that point, I wasn't sure if it would load different versions of classes which were already loaded. I need to test it, but how? How could I express the validation as a JUnit test case? Fortunately, my memory was my friend (and still is). I remembered this rule.

Two classes of the same fully qualified name are not equal to each other if they are loaded by different ClassLoaders. They cannot be cast to each other and such operations would result in a ClassCastException

Normally, I feared the above scenario (especially when Commons Logging is one of the libraries used in the concerned application). However, at that time, I needed to simulate that. Oh the irony.

To implement the test scenario, obviously, I needed a zip file which contains classes which will already be loaded during the test's execution. Out of pure randomness, I chose StringUtils from the Commons Lang library. The test class is already using that class to do a variety of things. StringUtils would be one of the most obvious choices to test the ClassLoader with.

This is how my test case look like.


public void testLoadClassesFromZipFileInZipFile() throws Exception {
 final URL dummyZipFile = getClass().getClassLoader().getResource(
     "com/foo/bar/test.jar");
 final Class stringUtilsClass;
 final StringUtils stringUtils;

 myClassLoader = new MyClassLoader(dummyZipFile);
 stringUtilsClass = myClassLoader.loadClass(
     "org.apache.commons.lang.StringUtils");

 assertFalse(stringUtilsClass.equals(StringUtils.class));

 try {
   stringUtils = (StringUtils) stringUtilsClass.newInstance();
   fail("ClassCastException should be raised");
 } catch (final ClassCastException cce) {
   /*
    * Success - two classes with the same fqcn loaded by two
    * different classloaders can't be cast into the other
    */
 }
}

... and of course, the test failed miserably. The expression, stringUtilsClass.equals(StringUtils.class) returned true. Wtf?!? After countless head banging against my indestructable CRT monitor, I tried overriding ClassLoader.loadClass(String):Class. I've overriden it to call getClassDefinition() (the method I have defined earlier) and use its return value as one of the arguments to the ClassLoader.defineClass() method. With my fingers crossed, I executed the test again.

The test failed miserable, again. It is now failing with a NoClassDefFoundError related java.lang.Object. WTF?! Looking through my code again, I was very sure that I called super.loadClass if the ClassLoader couldn't load it. What could be wrong?

Unsurprisingly, turning to my monitor with violence solved the problem. It appeared that I need to pass the call to a parent ClassLoader, which is not done by the super class's version of loadClass. After refactoring the ClassLoader a bit, the loadClass method then calls the loadClass method of the set parent ClassLoader as required.

With a bit of fear and anxienty, I executed the test again.

All green! Whew!

With that, I wrote even more test scenarios. They include:

Test if ClassNotFoundException would be raised if the requested class could not be found.

Test if ClassCastException would be raised if the zip file does not contain the class, but the parent ClassLoader does.

To my relieve, all were green! My heart rate started to drop. I could no longer feel blood rushing to my head. The ClassLoader works!

Looking at my code, I started to review the mistakes which were made... and the hours which I have spent could be summed up by the items below.

If you want to load different versions of classes which are already loaded, you must override loadClass.

If you are overriding loadClass make sure you call the same method of a parent ClassLoader if you can't load it at that level.

If you just want to add more classes (no loading of different versions of a class), overriding findClass is enough.

RTFM, carefully that

I have done similar things for classpath resources. More on that in my next blog.

Can You Spot The Mistakes?

2008-02-11T20:41:00.002+08:00

Some Java nerdery here:

public class Anonymized
{
  private static Logger logger = Logger.getLogger(Anonymized.class.getName());

  private static String sql = null;
  private static PreparedStatement stmt = null;
  private static ResultSet rs = null;

  public static void  getAnonymizedDetail(Connection conn, AnonymizedRequestObject requestObj)
      throws Exception
  {
    sql = "UPDATE anonymized_table" +
        " SET anonymized_field_1 = ?" +
        " anonymized_field_2 = ?" +
        " anonymized_field_3 = ?" +
        " anonymized_field_4 = ?" +
        " anonymized_field_5 = ?" +
        " anonymized_field_6 = ?" +
        " anonymized_field_7 = ?" +
        " anonymized_field_8 = ?" +
        " anonymized_field_9 = ?" +
        " anonymized_field_10 = ?" +
        " anonymized_field_11 = ?" +
        " WHERE anonymized_field_12 = ?";

    stmt = conn.prepareStatement(sql);
    /* Snip */
    
    if (aNormalConditionCheck) /* Edited to improve clarity */
      stmt.setString(9, "F");
    else
      stmt.setString(9, "");

    /* Snip */
  
    logger.debug("Update anonymized_table with primary key anonymized_field_12 = " + requestObj.getPrimaryKey());
  
    if (requestObj.getPrimaryKey()!=0)
    {
      stmt.setLong(12, requestObj.getPrimaryKey());
      rs = stmt.executeQuery();
    }
    else
    { 
      throw new Exception("Cannot save result to DB, because anonymized_field_12 is missing in AnonymizedRequestObject request object!");
    }
  }
}

How many mistakes (minus coding style errors and the nonsensical anonymized names ) are there in the above code? The one with correct answer gets a cookie (I'll mail it to you).

Rethinking Software Development

2008-01-12T14:04:00.001+08:00

I guess it's fair to say that most of us who are in the software delivery field are familiar with the implement->build->review cycle in software development. Regardless of the development methodology practiced, those phases will be there, with similar names or not. To reiterate, typical software development usually goes like this.

Implement - This is where you get a few developers to implement the functional requirements of an application. Additional activities which might happen in this phase are (re)engineering, sub system deprecations and so forth.

Build - Once the functional requirements are implemented, you build your application. The built application could then be used in various testing activities.

Review - This is judgment day for the built application. Implemented functionalities are validated to ensure they meet the requirements' specifications. Existing functionalities are checked to ensure there is no breakage. This is also the point where the stakeholders of the application decide whether to pass the current development iteration or to steer it into another one, possibly with new specifications and directions.

Pretty standard and complete? Yes, I would agree. However, if you look at it from another dimension, a few areas could really use some improvements. At least, that's true from my experience.

Most of the timelines I was fortunate enough to see have a similar pattern.

Time available for development is short.

Time allocated for each build usually has a duration of 1-2 man days.

Time allocated for testing is very significant.

Immediately, a few problems stand out:

Your developers will be racing to a close-to impossible due date. Just to ensure the implementation is delivered on time, the importance of proper design and impact weighing are reduced. That has serious consequences. There is a good chance your testers will be crushed by testing work. There will be significantly more defects with the application.

Even a day of time allocated for application build is a waste. Building an application should not be difficult at all. The complexity of it doesn't justify for the time allocated. While I have been in situations where building the application (in effect, is really integrating the various components in the system) revealed unimaginable amounts of problems, that happened because we did not have a good enough infrastructure. More on that later.

While it is undeniable that testing is the most crucial part of application development, that must not be represented by a huge chunk of time allocated for it. Take a moment to think. Do you foresee that many problems with the application that you need to have this gigantic testing phase? If you do, don't you think that might be a precursor of something bigger that is wrong?

The testing and implementation phases have direct effects on each other. The less time you have for implementation, the more time you need to validate the quality of its outcome. If you follow that and go through each development cycle, there will always be more issues passed to next development cycle for fixing. More time will need to be used to validate the fixes... and then it goes on. The cycle is almost vicious.

At this point, you may ask, what's the revolutionary idea to solve all the problems? Well, there is none. The idea I will be proposing soon is proven. There is nothing revolutionary about it. That's what made me so compelled to share.

I still remember a joke which a friend of mine made about how a country got things done. He said, the idea of the country is.

If you can't do it with a machine, do it with 1000 men.

But what I want to say is that if you need 1000 men to do something, there is a good chance it can be done with a machine. What I'm about to propose will require a lot of changes in the development practice which I have described earlier. The time allocated for the phases in it will be completely different. How different?

Instead of allocating the least time for development, have it to take up the largest amount of time allocated for the application delivery.

Take some of the time allocated for the testing phase and give it to the implementation phase.

Eliminate the time allocated for application build by introducing automated continuous integration. At least, make it really insignificant.

Automate most of the testing.

That model gives us the following benefits.

With more time available for implementation, your developers will be able to take the best implementation path by carefully reviewing designs and analyzing impact. This should allow them to produce better quality work, which will lessen to load on the coming phases.

Your developers, with the time given to them, will be able to write test cases, both unit and functional. These tests I'm talking about are automated tests. Tests which are repeatable anytime to validate the application. There are plenty of technologies which the developer can use to automate the testing. I have a preference for Selenium for functional testing. It is an excellent tool to test web applications using browsers as the test agents. It is very close to human testing and it can be completed with a fraction of the time taken by a human tester.

Since your developers are required to write test cases, application defects will be realized earlier - even before they reach the build phase!

Allows for shorter but more frequent development cycles. Implementation is an overhead. Once the code base is ready, changing it requires dramatically less effort. With the time taken to test the application a constant (or close to), the next development cycle will almost always be shorter than the previous one. More development cycles translate to better application quality and that, in turn, translates to a happy customer in the end - what really matters.

What's your take?

Interface & Abstract Classes

2007-10-16T22:59:00.002+08:00

Oh troll! Oh yes. That's right.

This is another take at this old topic. Only my perceptions differ. I'll be looking at this topic from an architectural point of view. So... when to interface and when to not? Before we head to that, let's take a look at interfaces.

Interfaces are skeletons. They do not contain behavior. They are perfect as specifications. Remember that specifications are really just standards. You can choose to implement those specifications however you wish and it wouldn't matter how you implement them. They are right as long as they conform to the specifications. That's how Java interfaces work. They define standards of services and service providers implement them. This makes sense. All service providers implement their services in very distinctive ways. If the specifications define implementation methods, they would most probably be ignored anyways...

Java interfaces also make it easier to implement applications which are service oriented. Take SOAP services for example. You don't need to know how they are implemented. You just need to know their inputs and outputs (specifications).

Java interfaces help you to decouple your service specifications from implementation. If it were abstract classes which defined service specifications, then any implementation other than the default will have to extend the default implementation. That's clunky, ugly and totally illogical. To make it simple, it doesn't make sense for the next different ruling party of your country to inherit all the corruption of the current ruling party to provide you with the same administrative service.

Generally, it is safe to use Java interface wherever you can observe specifications. Typical areas would be managers, DAOs and loggers.

Unit tests could actually benefit from interfaces as well. Mock object frameworks usually support proxying of Java interfaces at the very least. That will allow you to create and verify mocks easily.

Abstract classes do have their use, of course. In fact, they are equally as priceless. For instance, have you ever find yourself in a situation where you need to have a common sequence of method invocations of two related classes? That's the Template design pattern. That's one example abstract classes is perfect for. Interfaces just wouldn't fit in that scenario.

It doesn't hurt to have interfaces. In fact, it doesn't hurt if you have a lot of them. Of course, there is this thin fine line. If you decide to make your DTOs interfaces, don't define setters. I don't think they make sense of an interface.

How I Would Start Development

2007-10-10T00:24:00.001+08:00

Alright. So you've battled through the user requirements, figured out the time needed for engineering tasks according to their difficulties, hammered out the timelines with the project managers and you finally have that nice little document called the functional requirement specifications signed off. It's now when the most painful part of the software development cycle starts. Yes, the development.

I'm not going to talk about software development methodologies. If I wanted to, I wouldn't have started this blog after the functional requirements are frozen. Development methodologies, much like religions, should be decided way before that.

To fend off unintended readers, this blog will not be talking about the foot-stepping dances of development. This blog post, to be specific, will talk about what are the things which have to be done/acquired to get development rolling.

The way I see it, there are four main components. They are:

* Source control management
* Continuous integration
* Issue tracking
* Knowledge management

Source control management
For most development projects, there aren't many to choose from. The choices are:

* SVN (Subversion)
* CVS (Concurrent Versions System)

The decision will ultimately be decided by a battle of convenience. Setting up both systems are equally as troublesome. Their setups both include the prepping of certain directories which will eventually become the source repositories (and not failing to mention the massive clunk of permission problems following thereafter). However, for the trouble, SVN gains you one thing. The ability to view your sources over HTTP without setting up yet another subsystem. Also, HTTP(s) might be a better option if you work in restrictive environments. For instance, you might be working at your client's office where the only outgoing connections you can make are HTTP or SSL.

SVN does lose out a bit without all that branching and tagging features. However, source directories can be copied along with their histories. That should make up a bit.

Of course, the bad thing about SVN is that it is too easy to screw up your local copy of the source code. Suddenly, you will find yourself losing the ability to commit your code or change attributes of certain files. At that point, the only thing left to do is to check out the code your are working on and reapply the changes. That sucks.. but SVN still sucks lesser compared to CVS.

Continuous Integration
While a lot of a developer's work is done alone, the compatibility of the works of each developer is important. Every now and then, you've got developers trying to wrestle each other out to win the right to put the blame to the other for breaking the build (yes, that shameful monkey). You need a way (or tool) which checks for integration breakage regularly and be able to notify the relevant people about those breakages as soon as possible.

It would be best to implement some enabling technologies which do continuous integration. Builders like Maven definitely help in this area. However, if Maven is used alone in this context, that probably means you have a scheduled build.. and the interval would be fixed to a day (24 hours).

That is too much lag. You don't want to wait a day to find out that someone else broke the code and you have to spend the entire morning fixing the problems when you could have yesterday, if you weren't chattering like a bird then. By the way, that's probably the case if you actually check in the morning if the build broke. That monkey who broke it probably has no idea.

A continuous integration system will help in this context. It will constantly scan for changes in your source repositories and rebuild your applications if there are changes. This means breakages will be detected and fixed with much lesser delay. Of course, that can only happen if the system actually notifies the relevant people. With a continuous integration system, that's not something hard to do.

Issue Management
Unless the application being developed is unbelievably simple, you will have issues. When issues arise, they have to be tracked in a way where:

* People in different roles of your project can utilize the work flow of the system to systematically get things done. For example, a bug raised by a tester will be assigned to the developer. When the developer has fixed the bug, it will be assigned to the tester where he or she can check if there is a need to reopen the bug report.
* You can easily see what issues are open, closed and in progress. This gives you an overall view of the state of the project. Very valuable information.
* You can easily see where are the hot areas of the application. It allows you to make some changes to your project plans to help the hot areas.
* You can easily see how much time is spent versus the time estimated for the issues.
* You can extract certain statistics from the issues tracked to help drive the project.

Knowledge Management
Knowledge will be gained by the people involved in the project as they work on it. Ideally, everyone should have the same knowledge of the project. That's great because someone in your project doesn't end up having to spend unneeded days (or months) to relearn something which someone else already have. That could happen as people come and go in a company. Of course, that might also happen if that someone with the exclusive knowledge is on a long holiday.

To capture knowledge, you must of course, get your people to adopt the culture of documenting what they know. Constant nagging and rewards might help.

Once you have that, you need a tool which allows your people create, edit and search knowledge bases easily. Capturing knowledge doesn't require complex content authoring features. In most cases which I know, systems which allow users to create documents with light formatting using some annotation is sufficient. For instance, wiki markup. WYSIWYG editors might be helpful too.

However, the most important part would be the searching. The problem with 12 dozen MS Word documents in a Windows file share is that they are not searchable. Looking for knowledge immediately becomes a time consuming task. Knowledge searching should be fast and accurate.

To me, once the four components are in place, development can start and one can definitely be assured that the application being developed meets a certain minimal level of quality. You can definitely place other forms of control or assertions. For instance, checkstyle, refactoring and documentation standards. However, those can't happen if the four components are not there.

So how would you start your development?

Test With All Your Might

2007-09-05T20:01:00.001+08:00

I've been creating a lot of test cases these days. It's quite fun and challenging. As with my previous post, I had to understand what the code are trying to do before actually writing the test cases. I believe, in the ideal world, test cases are written first - TDD (Test Driven Development). The idea does make some sense.

When you implement something, you (the developer) know what will (or supposed to) be the input and the output. That's specification. When you have specification (a formal definition of something), you can validate against it. That's when unit test cases come in. They validate the implementation of the specifications. However, the question is, how can you write unit tests when you don't know how the methods look like? The answer to that comes in the form of Java interfaces. Interfaces are really specifications of unit behavior. With support of refactoring tools, I guess it is not so hard to create well designed applications which are thoroughly tested.

The only downside to that would be the increased development time. That's because developers have to write test cases before they can write actual code! In broader perspectives, that practice (TDD) might actually look like bad idea. However, if building products which have to be regressively tested to ensure quality through their lifetimes is important, the practice will save a lot of time in the long run.

While writing test cases today, I came across two interesting things, which I will break them down into two sections to please the tired eyes of Confluence lurkers.

Comparator
Java comparators compare two (left hand side, right hand side) values to determine which one is larger or if they are equal. According to the Java specification, implementations of Java comparators must:

Return a value lesser than 0 if the left hand side value is lesser than the right hand side value

Return {{0}} if the left hand side value is equals to the right hand side value

Return a value larger than 0 if the left hand side value is greater than the right hand side value

Of course, I say this with the awareness that the Comparator actually have to be consistent with equals. If given the left hand side value as lhs and right hand side value as rhs, lhs.equals(rhs) must produce the same result as comparator.compare(lhs, rhs) == 0. But today, I had a revelation:

public class EditCountAuthorRankingComparator 
    implements Comparator {

  public int compare(Object obj1, Object obj2) {
    AuthorRanking ranking1 = (AuthorRanking)obj1;
    AuthorRanking ranking2 = (AuthorRanking)obj2;

    if (ranking1.getEdits() < ranking2.getEdits()) {
      return 1;
    }
  
    if (ranking1.getEdits() > ranking2.getEdits()) {
      return -1;
    }

    // finally order alphabetically
    return ranking1.getFullNameString().compareToIgnoreCase(
        ranking2.getFullNameString());
  }
}

It would be fine if the whole class was renamed to something like ReverseEditCountAuthorRankingComparator, but then again, that would be slapping myself because of the last line in the above method. :)

Of course, the code failed my unit test. For me, I don't really care if the code is working acceptance tests (manual, currently), as long as it doesn't follow unit specifications, it's a red.

Maven Surefire too eager
While building one the plugins with tests, Maven complained and complained about this:

org.apache.maven.surefire.testset.TestSetFailedException: 
Unable to instantiate POJO 
'class com.atlassian.confluence.extra.
impresence2.TestGtalkPresenceReporter$10'

W00t.

That's all folks.

Shut up and encode HTML

2007-08-15T23:50:00.002+08:00

No, I could not say it in a better way. We, web developers, have slapped ourselves with enough security holes which could be avoided by a little bit more effort in thinking before writing our code. If I haven't got your attention yet, I really mean - HTML encode bloody variables when generating HTML.

So what can happen if you do not encode your variables? Well, this clearly describes it. That's XSS. (for those who are wondering, the TMNet web site was the first choice in my list of possible web sites which are vulnerable to XSS. The corporation is high on the suckage factor).

The funniest thing is how easily those security holes can be avoided. All it takes is to encode your string variables. In my experience, the only times when I saw HTML encoding of string variables were the times they were used as hidden input field values in a HTML form.. and unescaped strings just completely borked the sites' layouts. I guess now we don't have a reason to not encode HTML, do we?

Unlike SQL injection, XSS attacks are easier to create because the attackers are not required to have knowledge of the database schema. All they need to know is JS.

Firstborn Get the Brains

2007-06-23T10:25:00.001+08:00

For those who doesn't read /. often, here's a post which I think is quite interesting.

And... here's the part where my two cents comes:

I think the post is a wealthy load of unmistakable garbage. Assuming the statistics are correct, that firstborns are more intelligent than their siblings by a few points, using their social statuses in later stages of their lives as a benchmark relative to the time when their IQ is sampled just simply can't bang any sense into my reluctant mind.

I hear the chants of why. Well, IQ change and how depends on the environment and exposure that a person is subjected to. Education, family, friends, experience, attitude are some of the factors which could have very visible effects on a person's IQ. Using birth order as a coefficient to IQ measurement just doesn't make sense. If that is at all slightly true, then the article must be written by the youngest child.

Having said all that, the eldest child usually have traits that might not be evident in younger children which I believe could contribute to their success in securing a respectable rank in society.

* Independent - Eldest child are usually less dependent on people. Probably that's because they have not many people to depend on
* Leadership - Eldest child are usually asked to look after their younger brothers or sisters.

There are perhaps some more traits. However, the caffeine which I consume hasn't yet trigger the gush of blood into my head. For motoring enthusiasts, that's the "turbo lag". The time lapsed between the pedal to the metal and extra power in acceleration. Anyways, coming back to the topic, there are also several factors which could help the eldest child to achieve success.

Usually, more resources are available to facilitate the first child's growth. Education funds, food, and so forth. While from my observations most parents have some financial planning for their kids, the ratios at which resources are distributed are usually unbalanced. It's not a blame which I am describing about. It's perfectly understandable. A plan is an estimate not a specification.

In all, what we do will shape us. You can crawl from the dumps but you can fly to reach the skies.

Technology, Technology O' Technology Tonight

2007-06-02T12:48:00.001+08:00

I hate to use papers. I seriously do. I have to warn you that this is some sort of an extremist post, however, this is my blog and I write anything I wish to here, as long as my government says I can.

Papers are always not so useful to me. Why?

* They are not indexed. I can't search for data contained in them.
* They are subjected to wear and tear. Ink fade over time.
* They are usually not protected against fires and other mishaps -- you do not have a redundant backup too.
* Their data presentation does not have an adaptable interface -- just one way of representing the data. For example, if they are notes, it contains the information which you understand at that point it time. It becomes useless as your mindset mutates or time goes by.
* There is a higher chance for me to lose the information than to use it.
* They are costly.
* They freaking cut my fingers.
* I hate to shop for them.

Personally, I try to move everything to electronic format. Why? It addresses all of the drawbacks above and more. Here are my sources of information.

* Books - PDF documents
* Mail - Email
* News - RSS feeds
* Knowledge base - My personal content management system (a wiki)
* Notes - PDA
* Contacts - My PDA, synchronized with an Exchange server
* Notes - My PDA, synchronized with an Exchange server
* Calendar - My PDA, synchronized with an Exchange server
* Task tracker - My PDA and issue tracker web application

There are additional stuff which I do online. Some of them are paying bills, banking and so forth.

The other thing which I would love to see "computerized" is signatures. Currently, I still have to have an organic signature, something I had to do with a pen and thin piece of paper. I think it would be great if my bio-signature can be used to link to my OpenPGP profile.

I guess, my enthusiasm for everything to be computerized is fueled by my desire to be accurate and effective. I don't want to lose any information, I want information to be captured and secured, and I want to be able to refine those information to something which I can use to improve myself. Currently, in our system, it is really hard to manage information, even if it is just our own. Ask yourself the questions below.

* Can you track down your spendings down to the last cent accurately and then categorize them?
* Can you track at the minute resolution where you time went?

I don't believe anyone could say yes to those questions. The cause, I would assume, is that the data wasn't even captured correctly, if at all. If we have some sort of a computerized device which can help us to capture those data accurately, that would be great.

Imagine a world where you have debit or credit cards which categorizes your spending. It is the only "cash" you have. Consequently, all your purchases will be recorded, indirectly providing you with an audit trail of your spendings. At any time, you can pull that data out and refine them to a personal financial report, which you can then use a financial analyzer program to help you find out how you can improve your spendings.

I believe the data will also be useful for tax calculation. You don't have to keep your receipts (if they exists then) at all.

How about RF radios? Radios annoy me sometimes. When I travel to other states in my car, I always have to suffer to loss of my favorite radio stations. This could be due to the fact that I do not know the frequency which my favorite stations broadcast at in other states. It could be due to the fact that they are not available in that state as well.

If all radio stations broadcast using the Internet as the backbone, I just need a domain name to locate them. I don't have to remember their frequency. Now, I have to maintain a mapping of frequency numbers to radio stations. With a domain name, I just have to remember a name.. and it doesn't change wherever I am in the world.

Having said all that, I'd like to say that I'm already happy with the current state of the integration of technology in our daily lives. It's just that I dream of Utopia sometimes.

Are You A Good Team Leader?

2007-03-10T11:21:00.001+08:00

Being a team leader involves more than just managing your resources and getting deliverables out. I believe as a team leader, you need to do good in the following items.

Know your team well

Knowing your team well allows you to detect problems and form actions on them before they develop into something that can really wreck the team.

* Do your team members know what are your plans for them?
* Do your team members know what you are doing?
* Do you know what your team members are doing?
* Do you know what are the personal goals of your team members?
* Do you know what kind of problems your team members are having?
** Are they overloaded with work?
** Are they finding it difficult to learn about some aspects of their work?
** Are they cooperative with each other?
** Are they motivated?
** Do they feel appreciated?

A good team leader should always have answers to the above questions. It's not really important what are the answers to the questions above. The important thing is to have answers to those questions.

Good Communication Skills

Open communication is important in a team. As a team leader, you need to ensure that your team members are willing to talk to you about their problems. I have to admit, that it is impossible for team leaders to ask if their team members are having problems all the time. It's just too time consuming and a lot of that effort will be wasted. Therefore, having your team members to tell you of their problems by themselves is important.

A lot of times, team members do not approach their leaders because they feel that their leaders will smash their skulls with a crowbar if they "give" another problem to him or her. Simply said, team members feel that their leaders are not approachable and it could be due to many reasons. Needless to say, the classic reason is "my team leader looks so stressed up. He must be really busy. I'd best not bug him".

Might I add, some team members actually fear that once they report a problem, they will become a problem in the team leader's eye. If this exists in your company, address that immediately! It's pretty severe if your team has something like that going on.

As a team leader, you need to find ways to make yourself approachable! For example, if you really have a scary facial expression when you are stressed up, talk to your team. Ensure them that you are approachable even if you look otherwise. Facial expression is something which is really hard to control and talks will create some understanding between yourself and your team.

Try to make an effort to small talk with your team members. It encourages them to speak to you. Slowly, they will feel more comfortable talking to you and find you much easier to approach when they have problems which they feel that you can help them with. In addition to small talks, occasional outings would be useful as well. However, it is worth to note that team leaders should never force an outing. It leads to really severe counter-effects.

Pro activeness

A good team leader is someone who is pro active. While you can be the most pro active person when it comes to follow ups on external matters, it doesn't really mean you are also someone that is pro active on internal matters.

Your team members might have reported problems to you (kudos to you, you've got your team rollin') and you've taken some actions to correct the problems. However, did you follow up on the actions? Do they really make an improvement? Are your members happy with the situation?

Another area that team leaders should be pro-active in are team updates. From time to time, a good team leader should call for update meetings. Some of the things that should always be included in the agenda of the meetings are:

* Updates of the company, especially information that probably was not relayed through the appropriate channels.
* Your current roles and responsibilities
* The plans for your team members

As a team leader, you need to be pro-active on internal matters such as those mentioned in the previous paragraphs. It helps to create a culture of pro activeness amongst the team members. Utilize your influence on the team!

The first step of learning from mistakes is to actually admit them. All the best, team leaders!

Development Hell And Its Hellknights

2007-03-08T00:01:00.002+08:00

What "inspired" me to write this blog post was a recent nightmare I had about maintaining a system that was written by amateur developers.

The nightmare was about me maintaining a system written in the Java programming language which does inventory provisioning. For some odd reasons, orders could not be created in the system. The users were complaining that they saw error OMA-TX-NOPROC. That was the only clue to the problem, and it was buried in 50MB worth of log files.

After 2 days searching through the log files using a whole lot of log analyzers (and not forgetting antiseptic cream as the clients were trying to strangle me), I finally found the part of the system that was causing the problem. It was indeed a bug. Cool, I thought. All that I needed to do was to open up the source code of the program and correct the mistake. When I asked for the source code, I was told that while they could provide me with it, they couldn't guarantee if that was the version currently in product because they did not keep track of their program codes.

I proceeded by grabbing a copy from production and decompiling it. It allowed me to see the program souce code. I saw a Java class that was composed of more than 6000 lines of code. Still, not a problem, I thought. I just have to seach for the error code in the source code (which was OMA-TX-NOPROC). What happened after was truly amazing. I found an if-else block worth more than 500 lines that could lead up to that error.

The nightmare was too scary. I woke up after that.

You might have come across problems like the one in my nightmare before. You have my sympathy. Really.

The fact is, the maintenance problems in my nightmare are caused by amateur developers. These are developers that care only about getting their work done, and nothing more. Those are the developers that you want to watch out for.

Let's analyze the nightmare, shall we?

50 MB log files
Obviously, the developers have no idea what to log, and at which level. One could probably try to defend himself/herself by saying that he/she have enabled detailed logging (DEBUG level) in production. I find that silly. While detailed logging will give you more data, it will be so deeply buried that the data generated will become useless. Might I add, if you had to enable detailed logging in production, it really means that the system was not thoroughly tested, therefore, not ready for production. If it still ends up in production, somebody is being ethically incorrect.

Lack Of Code Tracking
Really, I couldn't imagine how a development project could kick off with the absence of code tracking. Any developer knows the importance of tracking program codes using tools such as CVS or SVN. If you have a completed project which its source code not tracked, I could imagine only two possibilities:

01) Only one of your developers is working throughout the project. The rest are coffee makers.
02) Your developers are born with unbelievable memorizing capability. All of them remembers how each piece of code looks like and how they changed throughout the project.

Design, Design and Design!
When there is a block of code with over 20 conditions, that is a sure-fire indication that something is wrong with your developers. I remembered quite some time ago in IRC, I asked an author of a piece of code why he has a 200+ line if-else block. I still remember the reason he gave me. He said, it's more maintainable, as the code is visible within one editor tab. That is definitely valid if he has a screen as tall as he is and he likes to change between crouching, sitting and standing positions while coding.

His next argument was code readability. I was relieved a bit because he was aware of code readability. However, I found out that he created a few Java classes which have lines that span over 200 characters wide. Needless to say, his ability to scroll in editor tabs amazed me.

In most cases, complex if-else conditions can be simplified by careful usage of methods and polymorphism.

So what makes a good developer?
A good developer should have the following personal traits:

* Has knowledge of or care about design patterns
* Has knowledge of or care about Object Oriented concepts
* Has knowledge of or care about software maintainability - this includes deployment
* Has knowledge of or care about tracking program code
* Has some ability to think for the people who use their work (users)
* Must not have the attitude of "I know all"
* Has the enthusiasm to improve their technical knowledge
* Knows how to use Unix systems

I'd love to elaborate more on why the above traits are important. However, it's 1:15 am now and I've written quite a long post. So I'll just end here and crash.

10 Things You Don't Know About Me

2007-03-07T22:47:00.001+08:00

Heeerrreee's the list:

01) I don't know how to use call waiting
02) I believe land transport is safer than air transport
03) I think Windows suck (especially Vista as they did not improve the UI of the command prompt. Cleartype! Please! Omfg!)
04) I wonder if my neighbors are alive
05) ... or they have been silently abducted by little green men and replaced with lookalike droids
06) I believe I'm in Malaysia because I'm suffering from the Stockholm syndrome
07) I think I am more likely to die in front of my computer than in a car wreck
08) ... and that I'm writing a blog entry
09) ... and my body will be discovered by my alien neighbors a week after I died
10) I think caffeine injection is a cool idea

The Truth Or Not The Truth

2006-10-09T00:39:00.002+08:00

"If you can't say anything nice, say nothing at all", the voice of the past spoke to me. This is true in most cases, I believe. It's fairly easy to ask people to think before they talk. Something I think that is easier said than done, even to those that requested for such consciousness when people talk to them.

It is true that if we do not think before we speak, misunderstandings could arise between the message sender and receiver. The results of the misunderstandings could be quite severe, might I add. Although I agree to that, I do not agree fully. To me, when communication errors occur, it is never fair to blame just on one end of the conversation(in our case, the sender). In communication, I believe, it has a lot to do with the receiver as well. What I mean, is that the receiver should be aware of the characteristics of the message sender. Having understand those characteristics, there will be less communication errors.

If my friends tell me I look like an ass, I would probably laugh my ass off. I would also tell them to stop coming out from me, and they would laugh their ass off. What's happening here is that I understand that those friends are natural idiots, defects of nature (HAHAHAH... kill me!), and I wouldn't take offence in all those "impolite" words that were thrown at me. Basically, I believe, if you're talking to someone that is not so much of a diplomatic talker and he or she said something you think that is not so appropriate, you should not take ill of it. If you do, you're just as good as a communicator that he or she is.

As human, it is always easy to find faults in everyone besides yourself. I am not saying I do not blame people, in fact, I am saying I do. I have done it in the past, I would probably do it in the future. What's different between me and those people that do not find faults in themselves is that I have an extra person to blame faults at. If you haven't figured it out, that would be myself.

Oh yeah, I didn't think much when I wrote this blog entry.

This is how

2006-10-05T15:18:00.001+08:00


#!/bin/bash

# Script to update dyndns.org of the external
# IP of the network to map to the domain name
# configured below

DYNDNS_USERNAME_PASSWORD="test:test"
DYNDNS_SYSTEM="dyndns"
DYNDNS_HOSTNAME="test.dyndns.org"
DYNDNS_IP=""
DYNDNS_WILDCARD="OFF"
DYNDNS_MX=""
DYNDNS_BACKMX="NO"
DYNDNS_OFFLINE="NO"

IP_OLD=""
IP_NEW=""

wget -O - -q http://checkip.dyndns.com |  sed -e s/\<.*\ // -e s/\<.*\>// > "/tmp/external-ip.new.txt"

if [ $? -ne 0 ]; then
  echo "Error: Unable to obtain external IP."
  exit $?
fi

IP_NEW=`cat "/tmp/external-ip.new.txt"`

if [ -f "/tmp/external-ip.old.txt" ]; then
  IP_OLD=`cat "/tmp/external-ip.old.txt"`
fi

if [ "${IP_NEW}" != "${IP_OLD}" ]; then
  echo "Updating to ${DYNDNS_HOSTNAME} to ${IP_NEW}"

  # This is a one liner. <PRE> fucks up my blog site
  RESULT=`wget -q -O - http://${DYNDNS_USERNAME_PASSWORD}
    @members.dyndns.org/nic/update?
    hostname=${DYNDNS_HOSTNAME}
    &system=${DYNDNS_SYSTEM}
    &myip=${IP_NEW}
    &wildcard=${DYNDNS_WILDCARD}
    &mx=${DYNDNS_MX}
    &backmx=${DYNDNS_BACKMX}
    &offline=${DYNDNS_OFFLINE}`

  echo "Result: ${RESULT}"

  echo ${IP_NEW} > "/tmp/external-ip.old.txt"
fi

exit 0

The Good, The Bad and You

2006-10-02T20:47:00.001+08:00

I am unsure if you have heard of the good cop/bad cop technique of pursuasion. It exist, and it is very effective, even now. But what is the good cop/bad cop technique? Where is it being used? Let me start off with what is it that is called the good cop/bad cop technique.

The good cop/bad cop technique is a psychological tool used by two actors on a victim. Why is it called the good cop/bad cop is because of its origins. The technique was used by police for interrogation. One policeman will play the role of the bad cop while interrogating the suspect. He will be very aggressive, insensitive, rude, brute plus any other aggressive pushy attitude that I can't think of now. He will accuse the suspect, intimidate the suspect and in certain extent, hurt the suspect physically (police brutality might have rooted from here).

The bad cop is most of the time held back by the good cop. The good cop will offer a cup of water to the suspect. Some food perhaps and maybe even a cigarrette. The good cop will attempt to "protect" the violated suspect and tend to be sensitive to the suspect's needs. When the suspect started to accept the "kindness", the good policeman will "advice" the suspect to cooperate.

Of course, all these make up an exaggerated scenario based on fiction. However, having said that, it still exists in our world, but perhaps, in a more subtle way. This technique is so effective, it is almost natural. My guess is, you've already been victimized by this technique since very long ago. Yeap.. That's your parents. It doesn't end there, however.

This technique is used by your tutors, teachers, lecturers, friends, employers and even your country. How? Let me give you an example for the last two. Have you ever had a conflict with your immediate superior and somehow it is "resolved" by someone who has higher authority than your immediate superior? If you pay close enough attention to what they both are trying to achieve, you will find similarities. In most cases, your immediate superior is the bad cop. Needless to say, the good one will be that someone with higher authority. As for your country, the good cop is the political organization that is in power currently. The bad cop, would be the opposing organizations. The opposing organizations are means to make the current political organization look good. If they look good, you will keep them in power.

I don't understand exactly how this mechanism works. However, I see it like this. As an individual, we are very vulnerable. Naturally, we seek protection, especially in numbers. Generally said, for us, numbers exist in the form of allies. So how does this apply to why the technique works?

The enemy would be the bad cop. When the good cop protects you from the bad cop, you will naturally think that he or she is a potential ally. Naturally, we want to "neutralize" the enemy. With an ally, it would be easier. So in order to acquire an ally, there is a give and take. You accept their "protection" and you give your cooperation. After you have given your cooperation, you might even have the impression that you have an ally as the bad cop stops attacking you. However, that is not the case. It is because they have already gotten what they want and do not need you anymore.

Therefore, we need to adjust our thinking. Instead of accepting something better (from the good cop), do not accept anything. Be firm on your wants, and not theirs.

Miles Travelled But Not Moved

2006-09-16T15:26:00.001+08:00

The torn shoes dragged another step before they stopped. The ambience started to spin slower. A dry mouth, an aching back, warm skin and two wrinkled hands resting on a weary knees were his only companions. He had run so fast, for so long.

From a bent position, he slowly moved his exhausted self to sit on the side walk. As he sat on the ground, he let out a sigh of relief. On his left was where he came from, on his right was where he had to go. Catching a breather, he also took time to appreciate the serene environment. Looking to his left, he tried to recall what were the things he had seen.

Strangely, he could not remember, at least, not clearly. All he could remember were ghastly images of people that he had talked to. There were girls, boys, women, men and even children. He recalled that all of them offered him something. Some of them offered water, some of them offered tissues, some of them offered conversations and some of them even offered memories.

He remembered he took all of the offers that he received. However, he never kept them. He was running. He had to track forward. He thought if he was to keep them, he would have no more space to keep what in front had to offer. Although he did not know what in front had to offer, he was so sure it was better than what he got. So he just ran, and he ran.

His thoughts were interrupted. The thirst for water was simply too strong to ignore. With every drop of sweat that runs from his face to his neck, he felt more and more uncomfortable. He had finished his supply of facial tissues. He shook his head. Having ran so far chasing for something better, yet, he did not even have what he initially had.

Suddenly, there was a gentle tap on his shoulder. He turned his head and saw a dark figure, shadowed by the sun behind it, was offering a bottle of water and a pack of facial tissues. He thought generousity could not have better timing, and took the water and tissues from the generous hands of the silent figure. He felt so gratified.

After quenching his thirst and dried his face, he felt a lot of better. He felt energized. He looked at the figure again, and said thanks with his usual smile. The figure was unresponsive. He then took a look at his watch and realize that he had spent a lot of time resting. He then stood up and started to run.

John

2006-06-27T14:22:00.001+08:00

I've read a recent blog post by a friend. Being only able to read the blog, I guess, it is clear that we haven't talked for quite a while. But nevertheless, the blog post was a great read. The post talked about an uninspiring Joe day turning out to be surprisingly heart warming.

It details about herself being moody, expecting a surprise to cheer her up perhaps. She described herself spending the day doing nothing special with her significant other. She wrote that she did not get any surprise which she expects otherwise. However, at the end of her post, I think she actually did. Joe was not Joe, simply put.

The surprises, the places to go, the food to eat doesn't really matter. What truly matters is how the time was spent with someone you care about. It could be really simple things but still end up memorable. It could be just a laugh or two, a nudge, a squeeze, a cooking session, or even just watching a rerun on television. Happiness is quite modest.

Ordinary is a speciality that the common us do not usually see.

My friend's post is here:
Ordinary Satisfying Day

A Sunday That Most Of Us Don't Know

2006-04-23T12:43:00.001+08:00

The weak sunlight is crawling into the room. Sneaking a shine, I know the effort is in vain. No matter what Sunday tried to pretend as, I could more or less see through it. It's hard to be Sunday really. Everyone expects Sunday to be always happy and cheerful. For most of the time, even I expect that.

However, on this gray day, I've come to understand more of what Sunday has been. Beneath its warming smile, lies a decaying heart. Sunday had always been just a display for our happiness. Unknowingly, we have been forsaking Sunday for a very long time now. Sunday has never been itself. We selfish fools.

Sunday is unusually quiet today. Too quiet perhaps. The feeling is tranquil. I'm wondering what Sunday is doing now for others. Is it still putting on that fake smile for others who expects it? Does it work?

Sunday is going away in a while. Hopefully the weekdays and Saturday will treat it better for weeks to come. One day, Sunday will truly shine again.

The Right Turn

2006-02-27T21:20:00.001+08:00

Driving down a faceless highway, my radio was playing lightly. The digital display showed 94.5, the frequency of one of my favourite radio stations. The car felt spacious, as it always has been. It was not because my car was big, but perhaps, it was because of how small I felt most of the time.

Ahead were a pile of cars that stopped before the traffic lights. Gently, I pressed on the brakes to slow the car down to a halt. My car stopped eventually. Resting my right elbow window ledge and my chin lying for support from my right palm, I gazed to my right.

I started to think how things would be different if I had said and done different things today. Wouldn't it be good if you're given a choice everytime you had to say or do something? How about throwing in a pause point everytime that happens? A rewind button on top of that would be great. Then I would be able to say and do all the right things.

But then, what is right and what is wrong? Would it be right to rewind and erase your mistakes and then simply make the right one, without understanding and suffering the consequences? Would it be wrong to try to be right?

The sound of a car horn made me snapped out of my trance. I signal right. Then I made a right turn.

I always have.

The Autumn Graveyard

2006-02-25T16:58:00.001+08:00

The darkness slowly faded. Manifesting from the center of the darkness, a glare was evident. The glare slowly forms a distorted image. As if looking at a picture located at the bottom of a clear rippling lake from a bird's eye view, the image appeared as if the world was shaking.

The rippling started to calm down. What a view. It was a mute image of a clear blue sky accompanied by clusters of white clouds and the sun behind them smiling down proudly. Suddenly, a shadow dropped over the sun. It was a tree leaf, gracefully falling down from the sky, as if to decrease the glare that the sun had always boasting about. The leaf touched the ground and gave birth to the horizon.

The ground was carpeted by millions of leaves just like the one that had just fallen from the sky. Tracing the horizon, there were no mountains, no hills, no trees, no villages. The only animate beings in this strange land are shadows. Even then, the shadows seem more alive that the objects that cast it.

The place looked like a place of nothing. The horizon always keeping a distance. From time to time, the shadows made faces. The effort seemed to be in vain, like how one desperately cracks a joke when no one is listening. What was amazing is that the shadows never stopped.

This is a timeless place liberated from the problems of the day called The Autumn Graveyard.

Emptiness

2006-02-17T22:02:00.001+08:00

Cool Breeze

2006-02-02T12:56:00.001+08:00

The cold winds blew across the vast landscape of rocky mountains. The night had somehow exaggerated the coldness. It seemed that the winds were so cold that it could trim the mountains. The deep ravines between mountains seemed like scars to what was once a warm place filled with life. The air that once smelled like hope was tainted with the smell of death.

In the middle of the landscape, stood a mountain taller than the rest. It dwarfed other mountains that surrounded it. Near the summit, there was one cliff like none. Before the cliff, there was a tunnel. The walls of the tunnel were made up of trees. The trees from both side of the walls curved toward each other, as if needing support, to form the roof of the tunnel.

A sound echoed from the far end of tunnel. It was Jimmy. Somehow, he found his way up there. It was the sound of his footsteps. Jimmy stepped out from the shadows into the dim moon light. Soon, he was at the edge of the mountain.

His face looked expressionless. There was no signs of emotions of any kind. His arms were bleeding from the cuts that he had endured in his journey up the mountains. The blood was fresh, as if he was cut just. Jimmy did not bother with them. He slid his right hand into his back pocket and took out a burnt penny.

Jimmy stared at the penny for a moment and then gazed at the dim stars. For a moment, it seemed that Jimmy gave a faint smile as his eye was affixed to the wonders of the universe. Jimmy then looked at his right palm that held the penny. This time, with a more solid smile.

Jimmy walked one step closer to the edge of the mountain. He pulled his right arm back, with the penny in his fist. He threw the penny over the cliff. Jimmy looked on as the penny flew into the air, giving its last shimmer. As the penny fell from the sky, before it was about to disappear into the darkness below, Jimmy jumped. His right arm stretched outward towards the penny. Jimmy descended into the darkness.

Jimmy finally found happiness.

Garden walk

2006-01-08T19:59:00.001+08:00

It was dark. In the vast night, it seemed to Jimmy that the only source of light came from the stars. It was quiet. So quiet, that craoks of frogs was clearly heard. The wind whispered as Jimmy silent thought about how he ended up in the woods, surrounded by trees that seemed to be crawling closer to him every second. However, he was unafraid. He was too disturbed over an incident that had happened.

He could not grasp the slightest of understanding. Clueless, as if a new born baby, Jimmy turned around. A path was paved by footsteps before him. He knew, at that time, he had the luxury of trailing backwards on the path he had walked. Slowly, guided by the stars, he did just that.

As Jimmy walked, he came to a split in the path. Just ahead, before the split, there were more footsteps. Jimmy could even recognize a few of them. Something shimmered in the corner of Jimmy's eye. He saw a penny. Jimmy went over to pick it up. It was covered with mud. Jimmy squat down and wiped the penny with his shirt. After much cleaning, a part of it was still black in color, as if it was burned. Then he remembered, he had a penny just like this one. That must be his, he must've dropped it.

The memories rushed in as Jimmy gazed at the coin. It was the coin that he did not flip. He remembered that when he reached the split in the path, he was far too proud to have his path decided by a penny and threw it away. Ironically, while he had defined his own path, there he was, trailing back and came to the penny.

Looking from left to right, he saw footsteps deviating from the path he had walked. Those must be of the ones that had flipped their coins, he thought. The deviated paths looked rough, which reminded Jimmy of why he did not take it. Suprisingly, the deviated paths looked to be more popular.

Jimmy was frustrated. Jimmy still could not quite understand what drove the maniacs to walk the rough terrain. To his frustation, it started to drizzle. The tiny drops of rain felt like bullets crushing into Jimmy's skull as he sank deeper into his thoughts. "They took a big risk", Jimmy said to himself. "Do they not understand what they might lose? Oh, your dear life!".

Then suddenly, Jimmy finally understood. He looked at the penny he held in his palm and started to smile. "Why of course," Jimmy said to himself again. "They are saying the same thing." Jimmy then stood up. He flipped the penny into the air and as it fell down from the moon, Jimmy catched it with his palm and closed it. He slid the penny to his back pocket and turned around, facing the direction he just came from and walked forward.

"At least now I have a penny.", said Jimmy as he disappeared into the shadows of the night.

Of A Day's Confession

2005-12-20T11:33:00.001+08:00

2 in the morning again. Having reached home, yet again exhausted. I slid my key into the pad lock of my house door. A loud clang seems to be the only sound in the world when the pad lock was opened. Despite the loudness of the sound, no one was awakened by it. I removed the lock and slid the door to my left with the few ounces of energy I was left with. The opening was just barely enough for my the slide through it. "Yet another one of those days", I thought.

I locked the door behind me. Seems like the house was illuminated only by the oil lamp on the altar at the end of the living room. "Maybe she's the only light.", I thought to myself, chuckling. The deafening silence in the room gave me the impression that everything was asleep. Tic-toc-tic-toc. The sounds of the clock reminded me that I only have a few hours to sleep. "Someday, I'm going to count on you", I thought to myself again.

I walked towards the flight of stairs leading to my bedroom. It seems to have grown. Slowly, I climbed the stairs. Reaching the top, it felt almost victorious. Silly me. It seemed that gravity was pulling stronger with every step I took as I walked towards my bedroom. After a short while, I reached my bedroom door. Looking at my bed, I gave out an inaudible sigh. "The beginning and the end", I thought to myself.

I switch on the air-conditioner. It was loud. It has always been loud. Seemed like I'm not the only one feeling like a thousand years old. I sat a while on my bed. "Tomorrow is another day, but just. I better sleep now so that I can have today tomorrow".

I went to bed shortly after. Indeed, I was right.

Life In An Infinite Loop

2005-12-07T09:20:00.001+08:00

Life is a miraculous gift of unknown cause. Its up and downs blending together in an endless chain of cause and effect which we do not understand, and perhaps never will. Until in a point in time (if there is ever a single unit of time), one can't help but wonder what life is all about. The question of why are we here.

I tried to view it from my daily life. I could not tell from how life is different from yesterday to today, or from last year to this year. It has always been the same. I get up from bed. I then get ready for my tasks. I try to finish my tasks. I exhaust myself. I get a little leisure. I go back to bed, preparing for the same thing to happen again tomorrow.

I can never escape from the thought of what I am going to do tomorrow. It seems strange. Because I already know, at least, what I am suppose to do tomorrow. A sign of hope for a break from the vicious loop? I would guess so.

I feel jaded now. After so many days, so many hours of the same old thing. My nerves tell me I'm too much of a coward to end my suffering. I can't endure the pain prior to the ultimate relief. Therefore I am still here, with a fool's hope, of something good and different that might happen tomorrow.

The Utopian idea exists, but will always just.

Life is just a poison we take everyday.

Off topic: Hanging On A Thread

2005-08-14T15:54:00.001+08:00

This is about Java programming. For those who are not interested in such discussions, I think, this post will not be able to spark any interest in you.

Synchronization has always been a topic of discussion for any level of Java programers. While the construct of synchronization can be easily explain in a sentence or two, exemplary usage are usually rare.

First of all synchronization is not as slow as we think it is. And in any system where there is concurrent access, the system cannot escape from synchronization. The funny thing is, while we most of the time try to escape the usage of the synchronized keyword, we still use it all the time. This can be seen whenever there is usage of synchronized (internally) collections. Some of them are Vectors and Hashtables. And most of the time, we iterate through the collection. For example (typical collection iteration code)


for (int i = 0; i < myVector.size(); ++i) {
  Object o = myVector.get(i);
}

This would result in a lot of synchronized calls. If the collection contains 1000 elements, there will be 2000 synchronized method calls. This is because Vectors are synchronized collections. We are not going to discuss about the usage of Vectors here, but generally, the usage of Vector in my opinion has been deprecated by ArrayLists with proper synchronization. Take a look at the code snipplet below. This will only result in 1 synchronized operation call because ArrayLists are not internally synchronized


synchronized (myArrayList) {
  for (int i = 0; i < myArrayList.size(); ++i) {
    Object o = myArrayList.get(i);
  }
}

Also, despite Vectors are internally synchronzied, they are not suitable for usage in a multithreading system. Refer to the first code snipplet. Imagine if the Vector contains 3 elements. Therefore, the loop will iterate 3 times. However, that is not always the case. Elements can be added or removed from the collection between line 1 and 2. The executing thread can be preempted. Imagine thread 1 (Thread A) is now at the 3rd iteration, where the variable i now has the value of 2, after the first line, we would assume that we would be getting the 3rd element (index 2) in line 2. Wrong. Thread preemption can be done between line 1 and 2. If another Thread (Thread B) removes an element after Thread A has been preempted, when Thread A executes again, an ArrayIndexOutOfBoundsException would be thrown because Thread A is trying to get the third element which doesn't exist (the Vector's size has been reduced by 1 by Thread B). This is just a trivial example.

However, with the second code snipplet, the window of opportunity for the error to occur is impossible with the correct synchronization technique. We have exclusive access to the ArrayList for the duration enclosed by the synchronized block. If another Thread tries to obtain the lock on the ArrayList, the thread will block. However, notice that I've said with the correct synchronization technique. This will only work if both Threads tries to lock on the ArrayList. If Thread B doesn't agree on the protocol, errors or anomalies can happen.

While we are still on the topic of threading in a Java environment, some of us extend Thread to produce the effect of multithreading. While this approach works, this level of inheritance is most of the time simply unneeded. Extending Thread is only needed if we need to change the behavior of Threads. If we are to just execute a task in another Thread, we should implement Runnable. By doing this, it gives us options on how code can be improved. We can reuse Runnable implementations by using the correct pattern, for example, a EmailTaskFactory that returns EmailTasks which implement Runnable where the same instances can be reused 2 or more times. The EmailTaskFactory can be implemented in a variety of ways to accomplish that.

But when should we multithread? Multithreading is especially useful for operations that would most likely block. The most obvious scenario is IO operations which typically refer to disk IO and network IO. With threads, we can maximize the throughput. For instance, we have a bandwidth of 100Mbps from the box running the VM and the FTP server. We are to upload files to the FTP server. In typical approaches, we would be sequentially uploading a file at a time. This can result to unneeded prolongation. FTP is built on TCP. Therefore, it inherits the slow start network IO inherent in TCP. Efficient network bandwidth usage can only be achieved if the file is sufficiently large, when the TCP buffer windows optimize their sizes as packets come in and goes out. If we're transferring a lot of small to medium files sequentially, we would be wasting time.

While most FTP servers only allow one data connection per FTP session, they usually allow multiple sessions. On the Java side, if we're transferring a lot of small to medium files, it would tremendously improve execution time if we spawn threads that will initiate sessions with the FTP servers for file transmission. This is not because we have better algorithm or better memory management (in fact, it would use more memory). This is because we're less affected by blocking operations.

I've written a long post. Until I feel like writing again. Chiaoz.

Off topic: Intrinsic

2005-08-03T21:58:00.001+08:00

There was an interesting discussion, though brief, about stress management with my colleagues today. I sincerely believe that we have our own ways to relax. I argued that sleeping is my way about it and my colleagues believed otherwise. They somehow implied that going out would be the best way. Undeniably, they are right. Then again, so am I.

My way of relaxing is to build up the pressure, regardless of source before ultimately letting it go. It has similarities with the theory of the art of shitting proposed by a friend of mine. Those of you who have heard of that, whether from him directly or from me, will know exactly what I'm talking about. The true value of relaxation is only expressed when the relief comes at the peak of the stress levels. With that, it deprecates temporal reliefs at **any** time before that.

But how does that relate to sleep? Sleep for me is a worthless temporal relief. It does nothing more than to prepare me for acceptance of more pressure, which, is what I need. To build up the pressure. To feel angered, frustrated, confused, depressed and all other negative emotions, in their most purest form, before letting it go, in one night, in a uniform music, in harmonized movements in the name of trance. One night, one life no pressure.

20th is the night. Hopefully, I'm there at the main arena in R3 to feel....

Off Topic: Top 10 Trance

2005-07-25T21:50:00.001+08:00

I love trance. I simply adore it and here are my top 10.

DJ Tiesto - Suburban Train

Jose Amnesia - The Eternal

Veracocha - Carte Blanche

Saltwater - The Legacy

Gouryella - Ligaya

Armin Van Buuren - Communication

Armin Van Buuren - Burned With Desire

Oceanlab - Satellite

Andain - Beautiful Things

Paul Van Dyk - Crush

Propaganda

2005-06-27T21:10:00.001+08:00

The attempt of establishing a propaganda is the very act of denying one of freedom. When practised long enough, the doctrine or set of principles became systemic to our lives, wrapping us in an invisible shield that forbids us from seeing beyond it. Hence, we became oblivious and would accept further propaganda injections without objection.

Propaganda, like the greatness of democracy, in my view, has been overly celebrated. Democracy is hypocritical. The idea of democracy was that people are able to elect individuals like themselves to look after the people's welfare, and the people have power to replace the representative if the objective was not met. To me, it was a deliberate act to divide the power of change, so no individual conscience can ever have enough influence to provoke a rebellion. The idea itself provides a facility to create a delusion to people that choices made are always of the best compromise, when there is absolutely no compromise at all. Think about this. Are you ever convinced that you can make a change? When you made a choice, was it really yours?

Democracy, therefore, is not just an idea. It is just a mean to achive total power.

Propagandas can get into our minds if we're too submissive. Therefore, I like to look at things in different perspectives. Most of the perspectives however, are deemed negative by those around me. Rather than feeling discourage, I am encouraged by the fact that I am able to break from what it is perhaps a propaganda trying to shroud my conscience. Still being to relate to reality, I find myself in the perfect balance.

I desperately urge those gifted with 'eccentric' thoughts like these be shared here.

Mission statement

2005-06-22T10:12:00.001+08:00

"Freedom is the freedom to say 2+2=4. If that is granted, all else follows.". An excerpt from a book written by George Orwell named 1984. The book itself, in my interpretation, doesn't specify what freedom is. However, the book describes what situations could be like without it.

Enslavement in the context of this site is not limited to physical enslavement. It will include any form of enslavement, be it physical or not, submissive or forced, the paradoxy of freedom and perhaps the price of freedom if it is capable of being defined at all.

In this site, I write my thoughts on what freedom is. Here I grimly hope that sympathetic eyes will read my thoughts and share insights with me in a distributed effort to wage a war against enslavement and win it.

First blog!

2005-06-21T21:08:00.001+08:00

First blog! Whee