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.
Sunday, April 08, 2007
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
apt-get install linux-headers-`uname -r`
to continue
Tuesday, September 19, 2006
Monday, June 19, 2006
"如何写一份好的工程师简历"
Just to blog what I read:
如何写一份好的工程师简历
2006年6月14日 上午 10:15:00
发表者：王忻，Google 工程师
最近三年作为 Google（谷歌）的软件工程师，我每周会帮人事部门审查简历，决定要不要给他们面试。Google 这几年的发展让很多许多优秀的工程师都前来申请。到目前为止，我已经看了上千份简历，有些简历留下的印象比别的好很多。尤其是最近亲戚朋友常常问我如何修改他们的简历，所以我积累了一些常见的错误避免的提议，在此跟大家交流一下。
1．谈到你做过的技术时，应该提到用的程序语言、你的个人贡献和产品细节。
有时我看到有人把过去的经验在简历上一笔带过，比如说：
• 在三人小组里，为电子邮件软件写了些 features。
这是远远不够的，看简历的人希望了解你做的工作的难度和对本公司有多少联系，所以你最好写的具体一些。譬如：
• 用 C++ 语言写了网络电子邮件的自动 backups。在三人小组里，专门负责设计和写储存服务器。从设计开始， 一年后把这个功能 feature 的用户推到了三千。
2．多讲事实, 少用形容词。
看简历的人读你的简历时，需要做判断，所以在简历里需要事实和数目。如果你写“迅速的提高了软件的操作效率”，看简历的人很难判断你成就的难度。但如果你写“在3个星期内，把软件的操作效率提高了40%” 就好多了。
有些谦虚的朋友们不愿意把话说满，所以你也可以用这个办法。你如果说自己“突出”或“在项目上常常被请去救火”，听起来难免会有点骄傲。但你也可以用不能否认的事实来说明你的观点，如“《纽约日报》评这个产品为‘突出’”，或“加入了三个原本已落后于计划的项目小组，但经过努力和组员一起把它们都按时完成了。”
3．你获得的奖、商业的荣誉或表扬、受用户欢迎的产品和你做过的有难度的业余项目都该包括在简历里。
我有位朋友在硅谷一个著名的硬件公司做了六年，她设计的 IP phone（网络电话）为公司赚了上亿的收入，被公司与商业报道多次评了奖。我有一次在旧金山的高速公路上驾车时，看到路边有她产品的广告牌；还有一次我去上海度假时，竟然发现上海公路边上也有！
不久，这位朋友决定换工作，请我看看她的简历。我惊讶的发现，她居然轻描淡写的写了一句-- "1998 – 2004：网络电话产品的硬件工程师组长" 和她的职责。
"产品赢的奖呢？它为公司赚的钱呢？" 我追问到。
"那些也该写吗？" 她说。
当然该写。
有人问，业余时间做的项目可不可以写？我觉得只要你的项目有代表性能说明对你的能力，都该包括。
4．分清主次，删掉相比之下不起眼的成绩，以免冲淡更加突出的成绩。
有朋友问，写简历是不是写的越多越好？譬如：
在甲公司做暑假实习生——
* 改善电子游戏的数值分类算法， 减少了内存要求 10%。
* 用 Java 写了 3000 行用户界面程序。
* 每周做两小时的人工测试。
你在申请软件工程师的职位时，我觉得前两点比较相关，第三点其实就不必写了。有时我看到有的简历里会提到，"按时完成了任务，产品符合原计划规格"。但读简历的人通常会认为这是理所当然的，而你把这些声明出来反而减弱简历的效果。
写一份简历不容易，但写好了也会带来成就感 （和好工作！）。 Google （谷歌）在中国广召各方面的人才，你不妨可以给我们投个简历！我们不但在信息检索方面招雇工程师，还有计算机图形、用户界面、硬件、Windows、质量保证员和系统管理员等方面。更多信息，请您访问这里。
谢谢阅读！大家感兴趣的话，下次我可以介绍“如何预备软件工程师的面试”。
如何写一份好的工程师简历
2006年6月14日 上午 10:15:00
发表者：王忻，Google 工程师
最近三年作为 Google（谷歌）的软件工程师，我每周会帮人事部门审查简历，决定要不要给他们面试。Google 这几年的发展让很多许多优秀的工程师都前来申请。到目前为止，我已经看了上千份简历，有些简历留下的印象比别的好很多。尤其是最近亲戚朋友常常问我如何修改他们的简历，所以我积累了一些常见的错误避免的提议，在此跟大家交流一下。
1．谈到你做过的技术时，应该提到用的程序语言、你的个人贡献和产品细节。
有时我看到有人把过去的经验在简历上一笔带过，比如说：
• 在三人小组里，为电子邮件软件写了些 features。
这是远远不够的，看简历的人希望了解你做的工作的难度和对本公司有多少联系，所以你最好写的具体一些。譬如：
• 用 C++ 语言写了网络电子邮件的自动 backups。在三人小组里，专门负责设计和写储存服务器。从设计开始， 一年后把这个功能 feature 的用户推到了三千。
2．多讲事实, 少用形容词。
看简历的人读你的简历时，需要做判断，所以在简历里需要事实和数目。如果你写“迅速的提高了软件的操作效率”，看简历的人很难判断你成就的难度。但如果你写“在3个星期内，把软件的操作效率提高了40%” 就好多了。
有些谦虚的朋友们不愿意把话说满，所以你也可以用这个办法。你如果说自己“突出”或“在项目上常常被请去救火”，听起来难免会有点骄傲。但你也可以用不能否认的事实来说明你的观点，如“《纽约日报》评这个产品为‘突出’”，或“加入了三个原本已落后于计划的项目小组，但经过努力和组员一起把它们都按时完成了。”
3．你获得的奖、商业的荣誉或表扬、受用户欢迎的产品和你做过的有难度的业余项目都该包括在简历里。
我有位朋友在硅谷一个著名的硬件公司做了六年，她设计的 IP phone（网络电话）为公司赚了上亿的收入，被公司与商业报道多次评了奖。我有一次在旧金山的高速公路上驾车时，看到路边有她产品的广告牌；还有一次我去上海度假时，竟然发现上海公路边上也有！
不久，这位朋友决定换工作，请我看看她的简历。我惊讶的发现，她居然轻描淡写的写了一句-- "1998 – 2004：网络电话产品的硬件工程师组长" 和她的职责。
"产品赢的奖呢？它为公司赚的钱呢？" 我追问到。
"那些也该写吗？" 她说。
当然该写。
有人问，业余时间做的项目可不可以写？我觉得只要你的项目有代表性能说明对你的能力，都该包括。
4．分清主次，删掉相比之下不起眼的成绩，以免冲淡更加突出的成绩。
有朋友问，写简历是不是写的越多越好？譬如：
在甲公司做暑假实习生——
* 改善电子游戏的数值分类算法， 减少了内存要求 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
Reference:
http://www.imagestation.com
http://photos.yahoo.com
= 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
Reference:
http://www.imagestation.com
http://photos.yahoo.com
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
pick.
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
week[3]:
* 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
finished.
* 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
bad.
-- Dan
> On 2/7/06, JP Rosevear
>> 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
pick.
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
week[3]:
* 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
finished.
* 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
bad.
-- Dan
Subscribe to:
Posts (Atom)
