Search This Blog

Thursday, September 22, 2011

IKEA's Chinese Product Names are Meaningless for Chinese

IKEA itself has a great Chinese name: 宜家, but while their Chinese names for goods are terrible.

For example, this is my desk brought from IKEA:

Its Chinese name is 格兰特 ( Glant ), I could bet that most Chinese will never remember names like that.

This naming style ( to name a product directly by English pronunciation ) is everywhere, a desk named 诺顿 (Norton) -- for Chinese it heard like a anti-virus software from Symantec, or a lamp named 巴西斯克 (Basisk) ...

IKEA should pay more attention on how to name a really Chinese name.

Thursday, March 17, 2011

The IM Should Be ...

As I have written, I don't like Skype. Then someone may ask: what do you think a perfect IM should be? I think there are two key points:

1. An Unique ID

People on line need an ID, in nowadays each website assigned an separate ID for each user. To a single user, in theory, using thousands websites, he/she needs to remember each different ID for each websites. Fortunately, in practice, many users are used to choose a unique ID, then using it everywhere. But this habit often conflict with the fact: it is hard to choose a real unique ID on net, and the ID preferred may be chosen by others on specified websites.

But wen do have an unique ID already: an email address! Why we can't use it as our other services, for example, IMs?

In fact, nowadays, more and more websites do use email address instead of assigning separate 'user name'. Why not so for IMs?

2. Communicate with people, but not with people using specified IM!

Current IMs all set walls for people not using same IM client. Yahoo messager users can't communicate with Skype users; Skype users can't talk with Gmail users ... IF AT&T set a rule that AT&T users could only call to another AT&T user, but could not to T-Mobile users or ... Do you think that is acceptable?

We need right to choose IM freely, and using any of IM to communicate with any of other IMs the receiver chosen. And here 'communicate' is not limited to text, but also audio, video and any future forms.

And the perfect way of going with IM

The email address is the only thing, needs to be written on contact cards, just like the old way of telephone number goes.

By the way, I also don't like fashion SNS logo: a name goes with tens of logos of SNS websites.

People with an email address could find the one on email, IMs, SNS websites ... And when they are communicating, the only thing need to consider is: To go with a talk, with a mail, with a photo, or with other type of contents, but not the software by which we could talk!

Wednesday, March 16, 2011

I Don't Think Skype has a Bright Future

Years ago, while other IMs could only provide text messages, or few of them add really poor quality voice services, Skype brought phone-quality Voice over IP to us.

So, I registered an account and using it till today. But I don't think the company has a bright future.

First, the advantage of technique is not reliable. Voice-quality is the only advantage of Skype, the disappearing advantage -- others company like Google, their techniques are improving fast, and now high-quality VoIP are provided everywhere. (i.e. Even in web games like World of Warcraft ... )

Second, people do not like their basic IDs be controlled by commercial company. As I have noted before, Why I Don't Like Google Wave ( Written by Chinese ), people always prefer to control their IDs by their own, and remain the right of choices. For example, why email is so popular and is the base of internet? Not because it cool, fashion technique, but people with a email could:
  • Own their own email address by their own domain
  • Changing their email host / software freely, but remain the address no changed
  • Sending / Receiving mails from different email providers
So email is people's own ID, and go cross all-platform.

But Skype is operated by a company, it could only communicate between Skype users, and if you want to change to other service you have to rewrite all your contacts.

In the years of lacking high-quality VoIP services, I could bear that, but now there are so many choices.

Google's talk / voice is another commercial one, it opener than Skype, to allow 3nd-part clients.

And the real open-structure is provided by Linux community, like Ubuntu One, Ekiga ... their goal is to provide cross-platform IM ( whatever software you using, could send/receive message from any IM software ), and also including voice messages. For me, one problem is still, user can't have a real own ID, like domain / email.

Third, for Chinese people, the Skype forcing them to use a spyware-edition of Skype called Tom-Skype, I hate this, details may be read at Wiki.

So I don't like Skype, but I still using it, just because changing contacts is very boring. Good news is for me, every important contacts is given as email -- I never treat Skype as a formal contact method.

Thursday, March 10, 2011

A suggestion for Google Reader: To Sort by My Likes, Please!

I'm sure there are many people like me: the reader seems to have 1000+ unread forever! And I think the fact is: this is a world, that you just can't read over!

Comparing have to unsubscribe something, I prefer to subscribe all seems to be interested, with no care of the quantity.

We all know that Google has the best codes to determine the order of search results, why not to use that for sorting unreads in Reader?

Change the mind to forcing users to read all, but to smart sort the unreads according to their likes. I think this is a better way of reading.

Sunday, February 6, 2011

Include / Require in PHP 5.3 with Namespace

Chinese edition of this article

PHP 5.3 introduces a new feature: Namespace, which brings some trouble with Include / Require statement.

Before Namespace, we use Include / Require like this:
  1. Set proper include_path
  2. Each class per file with same file name as 'classname.php'
  3. Require_once 'filename.php' (simply without absolute path)
  4. Additionally, use __autoload function, also without absolute path
So the system will work and without relying specified path.

But namespace breaks the rule.

If you did as old way under namespace system, this may happen:
  1. \namespace1\class
  2. \namespace2\class
Statement require_once 'class.php' would not work.

Now in __autoload function, class / interface names are brings as format: namespace\classname (interface name), and if you simply put all include files into one folder, and follow the old naming rule: classname.php, naming collision will happen ( Same class name in different namespace ).

So, new way should be introduced:
  1. Put your class / interface files into folders according to its namespace, the file tree may like:
    • include
      • namespace 1
        • sub-namespace A
      • namespace 2
      • ...
  2. Use absolute path, if include / require files manually. Because relative path depends on order of include_path, and may cause same name class file in different namespace be included. Magic constant __DIR__ or __FILE__ may be useful to form the path.
  3. In __autoload function, form the path according to namespace respectively, also __DIR__ and __FILE__ may be help, if the file contains __autoload function is in proper folder too.
By this way, the include / require should work well with namespaces.


I think the new feature brings too complex include / require / __autoload function into PHP, hoping the designers of PHP could do something to simplify it.

Friday, January 21, 2011

Friday, January 14, 2011

A Bug related to 'Recursive Reference' in Regular Expression PHP 5.3

  • Ubuntu 11.04
  • PHP 5.3
Domain name validation follows RFC 1034 - 3.5.

My project need a domain name validation function, so I coded one, using this Perl-style regular expression:

View at here.

But it can't work! I don't know why.

I've rewritten another one without the feature 'recursive reference':

View at here.

The two are exactly same, except the second replace all recursive references with characters.

The second one works!

So I think this is a bug of PHP PCRE and I've reported it at Bug 53728