“.asia” domains – And let the race begin!

Well, here we go again.

Anyone interested in a .asia domain can express their interest on http://www.asiadns.com.

According to EuroDNS, “While this service cannot be a pre-registration until the actual .asia rules are finalised, it is an increased chance for any potential domain registration to be considered and will allow Do.asia and EuroDNS to get a better feel of the market.”

ICANN and Do.asia signed the .asia registry agreement on 6 December 2006 at the ICANN annual meeting in Sao Paulo, Brazil following the ICANN board approving the designation of the .asia sponsored top-level domain on 18 October 2006. Do.asia is the first gTLD registry with a headquarters in the .asia-Pacific region. Do.asia Organisation (http://www.do.asia.org) is a membership-based not-for-profit corporation located in Hong Kong that was created in March of 2004 for the purpose of submitting a proposal to ICANN to operate a new TLD registry for the .asia top-level domain (TLD).

Let us remember that new domains have always been and will continue to be created. We have to therefore ask ourselves where we should draw the line and where this domain acquisition should stop.

Let’s have a quick glance at the long list of available domains:

And this is just a short list. A rough count reveals over a hundred possible domain names. Now, this most certainly puts things in perspective, doesn’t it?

Having said that… I can’t ague against grabbing domains with your company name or brand name to prevent anyone else from owning them, to avoid any future nasty ownership issues. But, which person in the right mind choose to buy all the domain names available? The answer is nobody, except people who collect domains. Yup, these people do exist.

And of course, the only people who will profit from this are the domain registrars. More $$$$$$ for them each time such a frenzy happens…

I found a friend!

Yay, I’m so excited.  I recently found out one of the freelancers I work with is quite “universal accessibility” savvy!  Her name is Divya.  This is a good sign for me as it means there is slowly, but surely, more an more emphasis placed on web usability in Singapore.  Having pushed for it over the past 3 years but not making much progress has been quite depressing.  So now, I have found new inspiration to rekindle my enthusiasm.

Up to now, there is little emphasis on web accessibiltiy in Singapore.  Most sites are still designed and built around tables.  And some done by traditional agencies are in fact neither accessible via non-graphic enabled browsers no are they searchable, as they are basically htmls with a single image plastered within the pages.  Although they look nice, they take ages to load and do not offer search engines any information pertaining to the sites.  This makes the sites simply a waste of time, money and effort.  But this is what you get, if you get the wrong folks to do the task for you.

It would have been good if they were professional about it and turned the job down or leave it to the rest of us who know what we are doing.  Unfortunately, that is not the case.  They get away with it as customers don’t verify the codes and will not find out until it’s too late.  The result? Sites with fantastic creatives that offer nothing else.

Follow-up on coldfusion jrun server problem

Here’s the final update. Sorry it took so long. Having isolated the problem and put in a quick fix through rectification of the database entries, we needed time to run through our codes to locate the point(s) of failure.

Turns out, the error was not caused by Coldfusion after all. We have a piece of code in our application which generates the breadcrumb which flag to users their current location on the site. Unfortunately, the code did not cater for adnormal situations.

An example of such would be when a child page (which exists), is related to a parent page which doesn’t. This is what happened.

During our troubleshooting:

• We walked through the database entries to identify any corrupted or errornous data, and didn’t find any.

• We also checked for possible updates applicable to the web server, application server and jrun, but decided to implement this if all else failed.

• Various server settings were changed to improve the system performance, but this didn’t solve the problem.

There has not been any changes to the application since 2005.

It seemed the application ended up in a loop still looking for a parent which its never able to find. Yup, we didn’t see this coming at all, as each time a child page is added, we would relate it with a parent which exists…

Unfortunately there is a hardcoded value within one of the pages which contributed to this error. That page references a hardcoded url. And although that page exists, it didn’t have a parent associated with it in this particular site. (The page is shared across our sites).

So it’s down to the nitty gritty. Janice helped me to search for the fault and finally able to locate it after sifting through our various .cfc and .cfm codes, doing dry runs based on the faulty data.

durr… So this is ultimately a case of human error. But that is no excuse, so we have added in the check into the application. Well, we live and learn.

The upside is, our application now handles the anomoly, it was a good learning experience for the team as we have never tweaked any of our coldfusion server settings before, and we are all aware of possible problems that can arise from the settings plus our current server capacity.