Sunday, April 08, 2007


HKSARG is planning to provide free wireless Internet connection to the general public. However, the government will not allow user to be online anonymously. One can take such facilities to do illegal activities, such as launching an attack against a corporate network. So, identity is a concern. How can we manage the identity of the user who uses the network? Also, should it be opened only to Hong Kong people? Should a visitor allow to use the facilities?

... to be continued.

Wednesday, January 31, 2007

To be better manage the schedule and tasks

My target for this year is to focus on managing better schedule and target.

Tuesday, September 26, 2006

Installing vmware on Ubuntu

to compile the vmware kernel module, we need to get the

apt-get install linux-headers-`uname -r`

to continue

Tuesday, September 19, 2006

First theme for my mobile

Just learnt how to make a theme for my mobile N71.

It is unique. MySky

Monday, June 19, 2006


Just to blog what I read:


2006年6月14日 上午 10:15:00
发表者:王忻,Google 工程师

最近三年作为 Google(谷歌)的软件工程师,我每周会帮人事部门审查简历,决定要不要给他们面试。Google 这几年的发展让很多许多优秀的工程师都前来申请。到目前为止,我已经看了上千份简历,有些简历留下的印象比别的好很多。尤其是最近亲戚朋友常常问我如何修改他们的简历,所以我积累了一些常见的错误避免的提议,在此跟大家交流一下。



• 在三人小组里,为电子邮件软件写了些 features。


• 用 C++ 语言写了网络电子邮件的自动 backups。在三人小组里,专门负责设计和写储存服务器。从设计开始, 一年后把这个功能 feature 的用户推到了三千。

2.多讲事实, 少用形容词。

看简历的人读你的简历时,需要做判断,所以在简历里需要事实和数目。如果你写“迅速的提高了软件的操作效率”,看简历的人很难判断你成就的难度。但如果你写“在3个星期内,把软件的操作效率提高了40%” 就好多了。



我有位朋友在硅谷一个著名的硬件公司做了六年,她设计的 IP phone(网络电话)为公司赚了上亿的收入,被公司与商业报道多次评了奖。我有一次在旧金山的高速公路上驾车时,看到路边有她产品的广告牌;还有一次我去上海度假时,竟然发现上海公路边上也有!

不久,这位朋友决定换工作,请我看看她的简历。我惊讶的发现,她居然轻描淡写的写了一句-- "1998 – 2004:网络电话产品的硬件工程师组长" 和她的职责。

"产品赢的奖呢?它为公司赚的钱呢?" 我追问到。

"那些也该写吗?" 她说。





* 改善电子游戏的数值分类算法, 减少了内存要求 10%。
* 用 Java 写了 3000 行用户界面程序。
* 每周做两小时的人工测试。


写一份简历不容易,但写好了也会带来成就感 (和好工作!)。 Google (谷歌)在中国广召各方面的人才,你不妨可以给我们投个简历!我们不但在信息检索方面招雇工程师,还有计算机图形、用户界面、硬件、Windows、质量保证员和系统管理员等方面。更多信息,请您访问这里。


Thursday, May 18, 2006

To be technical~

After next week, I will start to be more technical. As this blog is supposed to be as technical as it should be. It should be sharing the state-of-the-art stuff.

Tuesday, February 07, 2006

## What application I need ##

- a program to keep track of tasks [a TODO list]
= allow me to add / modify the list, which might be an article, a webpage, a book etc
= allow me to prioritize them
= set a deadline
= somehow a reminder
= can sync with sunbird

- Photo album
= similar to sony's imagestation, yahoo! photo album


Blog What I read: talking about design

Luis Villa wrote:
> On 2/7/06, JP Rosevear wrote:
>> The changes that were implemented were not as radical as the
>> mockups. Basically what Nat F. showed in Paris is what was
>> implemented. The code will be released to the community soon.
> To ask the obvious question, why not now, and why not discussed
> publicly earlier?

So here's my (ie, not Novell's) answer.

Two words: "bike shed"[1]. Or actually, "stop energy"[2] works too. Your

Although the changes aren't nearly as radical as the original mockups,
they are a big change from the current GNOME panel menu. If we had
proposed the changes on the mailing lists, it would have started a huge
discussion about what people hated about the design ("you can't make the
panel menu depend on beagle!!!") and how it should be different. And
then we could have either (a) completely ignored everyone and done it
ourselves anyway, or (b) had a long conversation about the merits of the
design and then not actually finished the code in time for NLD10.

So we did it ourselves, and now either GNOME will like what we did, in
which case, yay, free code for GNOME, or GNOME won't like what we did,
in which case, no harm no foul for GNOME, and yay, brand differentiation
for Novell. (And anyone who yells "fork" deserves to get one stuck in them.)

An equivalent answer to the question is "because you can't do design by
committee". Everything good in GNOME is good because one person or a
small number of people working closely together made it good. Much of
what is bad in GNOME is bad because lots of people have contributed
without having a single vision of what the end result is supposed to be.
I mean, look at the stuff John Williams has been blogging about the last

* Evolution's UI blocking on I/O SUCKS. Due to lack of design in the
early stages of development

* Evolution's integration with gaim and tomboy RULES. Both of these
happened because specific people (ChipX86, orph) made them happen.

* Multimedia integration SUCKS. No one has ever sat down and tried
to fix the big picture. (Although I think the gstreamer team is in
the process of doing this now?)

* Apps not remembering their window size and position SUCKS. Again,
needs someone to take this problem and make it their own. I
remember xkahn was trying to fix this a few years ago, but never

* Bug-buddy SUCKS. Jacob's original UI was simple and brilliant. But
as more and more people added more and more features without
looking at the big picture, it got unwieldy. (But now a small
team is putting the simplicity back in again.)

* Deskbar applet RULES (kikidonk), dashboard RULES (Nat), and beagle
RULES (trow and joe). None of these was done *exclusively* by
those people, but each of them reflects one person's (or a few
people's) vision, as opposed to the current state of bug buddy,
which just sort of happened.

This is just another aspect of the UI "simplicity" thing. We like UIs
that try to do the right thing (metacity, epiphany/firefox, evince)
rather than UIs that try to make every possible user happy
(enlightenment, mozilla, gpdf/acroread). If you try to design something
by committee, you either have to end up with the latter sort of messy
does-everything UI, or you ignore and hence piss off a large chunk of
the committee.

And that's where we are with NLD. There is no way that everyone in the
GNOME community is going to like the changes we wanted to make. But we
did the user testing, and we believe in it, and we want to make the
changes anyway. So we're doing it. Maybe it will turn out good, and
maybe it will turn out bad. Either way, the GNOME community learns from
it. Think of it like this: wouldn't it have been cool if we could have
tried out spatialus on our users, found out that they hated it, and then
reverted back to browserlus, without ever having to actually piss off
our users? This is essentially what is going to happen with NLD10. If
Novell's customers like the NLD changes, then GNOME can adopt them. If
Novell's customers don't like the changes, then GNOME can stand off to
the side and say "yeah well, we never liked that UI anyway. Not at all
like how we would have done it." :-)

But some people will still say "But couldn't you have discussed it with
the community before doing it?" No, we couldn't. If we had, it would
either not have happened, or it would have sucked. It's inevitable. It's
not a problem with the GNOME community, it's a problem with communities
in general. The wisdom of crowds[4] only works in situations where there
are clear right and wrong answers. If you try to apply it to a design
problem, where there are many entirely different right answers, then you
end up with a wrong answer. Always[5].

So to sum up: design by committee is bad, endless debates that result in
code not actually being written are bad, design by very small teams is
good, software with a unified vision is good, trying out cool new UI
ideas is good, free code at least doesn't suck, and of course, for
Novell, not shipping NLD10 is bad. I don't think there's anything we
could have done to get more of the good without also getting more of the

-- Dan