2007年9月12日星期三
2007年5月20日星期日
技术、哲学、做人
最近闲下来的时候喜欢看很多书，看来看去发现一些看似很陈旧的技术和概念其实蕴涵着丰富而又浅显的哲学思维和做人原则。新技术新概念层出不穷，令人眼花缭乱，浮躁不安，甚至血压升高。而那些基本的实现原则其实就像我们应该做什么样的人一样。这也是我比较喜欢Gerald Weinbery, Steve Maguie，Richard Stevens等的一些书的原因。不一定要都当成在读技术，有时候多想想，多回顾一下这些年经历的事情也是很有感慨。
比如有空读读70年代80年代90年代的RFC，这些RFC有些已经很陈旧了，有些只是在讲一些原则性的东西，有些只是在讲一个技术历史故事甚至插曲。不一定都当技术文档来读，这样说来，有时候其实也是个从技术出发的“心灵鸡汤”。
下面是前些天我发给同事们的一个邮件。不一定大家都能认同这些，也许有人觉得这些浅显的道理没什么。但我觉得在我们现在这种浮躁的技术实现领域，特别是软件开发领域是应该有这些态度的。其实也是一种做人处世的态度吧。
-----------the email------------
在读RFC1122（Requirements for Internet Hosts）的时候，对下列部分感触很多，希望大家分享学习：
1.2 General Considerations ................................. 12
1.2.1 Continuing Internet Evolution ..................... 12
1.2.2 Robustness Principle .............................. 12
1.2.3 Error Logging ..................................... 13
1.2.4 Configuration ..................................... 14
这个RFC虽然是Internet对主机的要求，更是对主机软件的要求，特别是对我们如何设计和实现软件，在软件开发、协议开发、接口开发中很有指导意义。给出了非常明确的软件设计原则，对软件的可发展性原则，稳健性原则、错误异常统计和Log、可配置性都提出了很好的一般性原则。建议大家好好读读这部分。
1． 可发展性：软件最初设计和实现的时候可能没有那么多功能，但产品和需求是不断发展的，如果不设计好结构和可扩展性，就的不断反工或者最后乱的一团糟；
2． 稳健性原则：特别是"Be liberal in what you accept, and conservative in what you send"这句明言，其实和我们中国的一句老话“宽以待人，严以律己”非常符合，这里介绍的稳健性原则是非常经典的总结；
3． 错误异常统计和Log：任何时候发现问题或bug或和别的设备或模块对接的异常都应该能从软件中提供的统计和log中分析出来，这就需要很好设计这些统计和Log。统计Log＋代码走查应该能查到所有问题，而不是靠测试和现场重现。如果在出现异常的时候必须需要模拟重现该异常才能找到原因，那么这个软件的设计和实现就不能说是成功的。
4． 可配置性：软件用到的任何配置数据和参数都应该是可以加、删、改的，而且这些可配置性应该是稳健的，可以用最方便的方法做到的，不依赖别的软件和设备的。
以下是节选的一段：
1.2 General Considerations
There are two important lessons that vendors of Internet host
software have learned and which a new vendor should consider
seriously.
1.2.1 Continuing Internet Evolution
The enormous growth of the Internet has revealed problems of
management and scaling in a large datagram-based packet
communication system. These problems are being addressed, and
as a result there will be continuing evolution of the
specifications described in this document. These changes will
be carefully planned and controlled, since there is extensive
participation in this planning by the vendors and by the
organizations responsible for operations of the networks.
Development, evolution, and revision are characteristic of
computer network protocols today, and this situation will
persist for some years. A vendor who develops computer
communication software for the Internet protocol suite (or any
other protocol suite!) and then fails to maintain and update
that software for changing specifications is going to leave a
trail of unhappy customers. The Internet is a large
communication network, and the users are in constant contact
through it. Experience has shown that knowledge of
deficiencies in vendor software propagates quickly through the
Internet technical community.
1.2.2 Robustness Principle
At every layer of the protocols, there is a general rule whose
application can lead to enormous benefits in robustness and
interoperability [IP:1]:
"Be liberal in what you accept, and
conservative in what you send"
Software should be written to deal with every conceivable
error, no matter how unlikely; sooner or later a packet will
come in with that particular combination of errors and
attributes, and unless the software is prepared, chaos can
ensue. In general, it is best to assume that the network is
filled with malevolent entities that will send in packets
designed to have the worst possible effect. This assumption
will lead to suitable protective design, although the most
serious problems in the Internet have been caused by
unenvisaged mechanisms triggered by low-probability events;
mere human malice would never have taken so devious a course!
Adaptability to change must be designed into all levels of
Internet host software. As a simple example, consider a
protocol specification that contains an enumeration of values
for a particular header field -- e.g., a type field, a port
number, or an error code; this enumeration must be assumed to
be incomplete. Thus, if a protocol specification defines four
possible error codes, the software must not break when a fifth
code shows up. An undefined code might be logged (see below),
but it must not cause a failure.
The second part of the principle is almost as important:
software on other hosts may contain deficiencies that make it
unwise to exploit legal but obscure protocol features. It is
unwise to stray far from the obvious and simple, lest untoward
effects result elsewhere. A corollary of this is "watch out
for misbehaving hosts"; host software should be prepared, not
just to survive other misbehaving hosts, but also to cooperate
to limit the amount of disruption such hosts can cause to the
shared communication facility.
1.2.3 Error Logging
The Internet includes a great variety of host and gateway
systems, each implementing many protocols and protocol layers,
and some of these contain bugs and mis-features in their
Internet protocol software. As a result of complexity,
diversity, and distribution of function, the diagnosis of
Internet problems is often very difficult.
Problem diagnosis will be aided if host implementations include
a carefully designed facility for logging erroneous or
"strange" protocol events. It is important to include as much
diagnostic information as possible when an error is logged. In
particular, it is often useful to record the header(s) of a
packet that caused an error. However, care must be taken to
ensure that error logging does not consume prohibitive amounts
of resources or otherwise interfere with the operation of the
host.
There is a tendency for abnormal but harmless protocol events
to overflow error logging files; this can be avoided by using a
"circular" log, or by enabling logging only while diagnosing a
known failure. It may be useful to filter and count duplicate
successive messages. One strategy that seems to work well is:
(1) always count abnormalities and make such counts accessible
through the management protocol (see [INTRO:1]); and (2) allow
the logging of a great variety of events to be selectively
enabled. For example, it might useful to be able to "log
everything" or to "log everything for host X".
Note that different managements may have differing policies
about the amount of error logging that they want normally
enabled in a host. Some will say, "if it doesn't hurt me, I
don't want to know about it", while others will want to take a
more watchful and aggressive attitude about detecting and
removing protocol abnormalities.
1.2.4 Configuration
It would be ideal if a host implementation of the Internet
protocol suite could be entirely self-configuring. This would
allow the whole suite to be implemented in ROM or cast into
silicon, it would simplify diskless workstations, and it would
be an immense boon to harried LAN administrators as well as
system vendors. We have not reached this ideal; in fact, we
are not even close.
At many points in this document, you will find a requirement
that a parameter be a configurable option. There are several
different reasons behind such requirements. In a few cases,
there is current uncertainty or disagreement about the best
value, and it may be necessary to update the recommended value
in the future. In other cases, the value really depends on
external factors -- e.g., the size of the host and the
distribution of its communication load, or the speeds and
topology of nearby networks -- and self-tuning algorithms are
unavailable and may be insufficient. In some cases,
configurability is needed because of administrative
requirements.
Finally, some configuration options are required to communicate
with obsolete or incorrect implementations of the protocols,
distributed without sources, that unfortunately persist in many
parts of the Internet. To make correct systems coexist with
these faulty systems, administrators often have to "mis-
configure" the correct systems. This problem will correct
itself gradually as the faulty systems are retired, but it
cannot be ignored by vendors.
When we say that a parameter must be configurable, we do not
intend to require that its value be explicitly read from a
configuration file at every boot time. We recommend that
implementors set up a default for each parameter, so a
configuration file is only necessary to override those defaults
that are inappropriate in a particular installation. Thus, the
configurability requirement is an assurance that it will be
POSSIBLE to override the default when necessary, even in a
binary-only or ROM-based product.
This document requires a particular value for such defaults in
some cases. The choice of default is a sensitive issue when
the configuration item controls the accommodation to existing
faulty systems. If the Internet is to converge successfully to
complete interoperability, the default values built into
implementations must implement the official protocol, not
"mis-configurations" to accommodate faulty implementations.
Although marketing considerations have led some vendors to
choose mis-configuration defaults, we urge vendors to choose
defaults that will conform to the standard.
Finally, we note that a vendor needs to provide adequate
documentation on all configuration parameters, their limits and
effects.
---------------------------
做一个对周遭的事物包容的人，做一个对自己做事严谨的人!
比如有空读读70年代80年代90年代的RFC，这些RFC有些已经很陈旧了，有些只是在讲一些原则性的东西，有些只是在讲一个技术历史故事甚至插曲。不一定都当技术文档来读，这样说来，有时候其实也是个从技术出发的“心灵鸡汤”。
下面是前些天我发给同事们的一个邮件。不一定大家都能认同这些，也许有人觉得这些浅显的道理没什么。但我觉得在我们现在这种浮躁的技术实现领域，特别是软件开发领域是应该有这些态度的。其实也是一种做人处世的态度吧。
-----------the email------------
在读RFC1122（Requirements for Internet Hosts）的时候，对下列部分感触很多，希望大家分享学习：
1.2 General Considerations ................................. 12
1.2.1 Continuing Internet Evolution ..................... 12
1.2.2 Robustness Principle .............................. 12
1.2.3 Error Logging ..................................... 13
1.2.4 Configuration ..................................... 14
这个RFC虽然是Internet对主机的要求，更是对主机软件的要求，特别是对我们如何设计和实现软件，在软件开发、协议开发、接口开发中很有指导意义。给出了非常明确的软件设计原则，对软件的可发展性原则，稳健性原则、错误异常统计和Log、可配置性都提出了很好的一般性原则。建议大家好好读读这部分。
1． 可发展性：软件最初设计和实现的时候可能没有那么多功能，但产品和需求是不断发展的，如果不设计好结构和可扩展性，就的不断反工或者最后乱的一团糟；
2． 稳健性原则：特别是"Be liberal in what you accept, and conservative in what you send"这句明言，其实和我们中国的一句老话“宽以待人，严以律己”非常符合，这里介绍的稳健性原则是非常经典的总结；
3． 错误异常统计和Log：任何时候发现问题或bug或和别的设备或模块对接的异常都应该能从软件中提供的统计和log中分析出来，这就需要很好设计这些统计和Log。统计Log＋代码走查应该能查到所有问题，而不是靠测试和现场重现。如果在出现异常的时候必须需要模拟重现该异常才能找到原因，那么这个软件的设计和实现就不能说是成功的。
4． 可配置性：软件用到的任何配置数据和参数都应该是可以加、删、改的，而且这些可配置性应该是稳健的，可以用最方便的方法做到的，不依赖别的软件和设备的。
以下是节选的一段：
1.2 General Considerations
There are two important lessons that vendors of Internet host
software have learned and which a new vendor should consider
seriously.
1.2.1 Continuing Internet Evolution
The enormous growth of the Internet has revealed problems of
management and scaling in a large datagram-based packet
communication system. These problems are being addressed, and
as a result there will be continuing evolution of the
specifications described in this document. These changes will
be carefully planned and controlled, since there is extensive
participation in this planning by the vendors and by the
organizations responsible for operations of the networks.
Development, evolution, and revision are characteristic of
computer network protocols today, and this situation will
persist for some years. A vendor who develops computer
communication software for the Internet protocol suite (or any
other protocol suite!) and then fails to maintain and update
that software for changing specifications is going to leave a
trail of unhappy customers. The Internet is a large
communication network, and the users are in constant contact
through it. Experience has shown that knowledge of
deficiencies in vendor software propagates quickly through the
Internet technical community.
1.2.2 Robustness Principle
At every layer of the protocols, there is a general rule whose
application can lead to enormous benefits in robustness and
interoperability [IP:1]:
"Be liberal in what you accept, and
conservative in what you send"
Software should be written to deal with every conceivable
error, no matter how unlikely; sooner or later a packet will
come in with that particular combination of errors and
attributes, and unless the software is prepared, chaos can
ensue. In general, it is best to assume that the network is
filled with malevolent entities that will send in packets
designed to have the worst possible effect. This assumption
will lead to suitable protective design, although the most
serious problems in the Internet have been caused by
unenvisaged mechanisms triggered by low-probability events;
mere human malice would never have taken so devious a course!
Adaptability to change must be designed into all levels of
Internet host software. As a simple example, consider a
protocol specification that contains an enumeration of values
for a particular header field -- e.g., a type field, a port
number, or an error code; this enumeration must be assumed to
be incomplete. Thus, if a protocol specification defines four
possible error codes, the software must not break when a fifth
code shows up. An undefined code might be logged (see below),
but it must not cause a failure.
The second part of the principle is almost as important:
software on other hosts may contain deficiencies that make it
unwise to exploit legal but obscure protocol features. It is
unwise to stray far from the obvious and simple, lest untoward
effects result elsewhere. A corollary of this is "watch out
for misbehaving hosts"; host software should be prepared, not
just to survive other misbehaving hosts, but also to cooperate
to limit the amount of disruption such hosts can cause to the
shared communication facility.
1.2.3 Error Logging
The Internet includes a great variety of host and gateway
systems, each implementing many protocols and protocol layers,
and some of these contain bugs and mis-features in their
Internet protocol software. As a result of complexity,
diversity, and distribution of function, the diagnosis of
Internet problems is often very difficult.
Problem diagnosis will be aided if host implementations include
a carefully designed facility for logging erroneous or
"strange" protocol events. It is important to include as much
diagnostic information as possible when an error is logged. In
particular, it is often useful to record the header(s) of a
packet that caused an error. However, care must be taken to
ensure that error logging does not consume prohibitive amounts
of resources or otherwise interfere with the operation of the
host.
There is a tendency for abnormal but harmless protocol events
to overflow error logging files; this can be avoided by using a
"circular" log, or by enabling logging only while diagnosing a
known failure. It may be useful to filter and count duplicate
successive messages. One strategy that seems to work well is:
(1) always count abnormalities and make such counts accessible
through the management protocol (see [INTRO:1]); and (2) allow
the logging of a great variety of events to be selectively
enabled. For example, it might useful to be able to "log
everything" or to "log everything for host X".
Note that different managements may have differing policies
about the amount of error logging that they want normally
enabled in a host. Some will say, "if it doesn't hurt me, I
don't want to know about it", while others will want to take a
more watchful and aggressive attitude about detecting and
removing protocol abnormalities.
1.2.4 Configuration
It would be ideal if a host implementation of the Internet
protocol suite could be entirely self-configuring. This would
allow the whole suite to be implemented in ROM or cast into
silicon, it would simplify diskless workstations, and it would
be an immense boon to harried LAN administrators as well as
system vendors. We have not reached this ideal; in fact, we
are not even close.
At many points in this document, you will find a requirement
that a parameter be a configurable option. There are several
different reasons behind such requirements. In a few cases,
there is current uncertainty or disagreement about the best
value, and it may be necessary to update the recommended value
in the future. In other cases, the value really depends on
external factors -- e.g., the size of the host and the
distribution of its communication load, or the speeds and
topology of nearby networks -- and self-tuning algorithms are
unavailable and may be insufficient. In some cases,
configurability is needed because of administrative
requirements.
Finally, some configuration options are required to communicate
with obsolete or incorrect implementations of the protocols,
distributed without sources, that unfortunately persist in many
parts of the Internet. To make correct systems coexist with
these faulty systems, administrators often have to "mis-
configure" the correct systems. This problem will correct
itself gradually as the faulty systems are retired, but it
cannot be ignored by vendors.
When we say that a parameter must be configurable, we do not
intend to require that its value be explicitly read from a
configuration file at every boot time. We recommend that
implementors set up a default for each parameter, so a
configuration file is only necessary to override those defaults
that are inappropriate in a particular installation. Thus, the
configurability requirement is an assurance that it will be
POSSIBLE to override the default when necessary, even in a
binary-only or ROM-based product.
This document requires a particular value for such defaults in
some cases. The choice of default is a sensitive issue when
the configuration item controls the accommodation to existing
faulty systems. If the Internet is to converge successfully to
complete interoperability, the default values built into
implementations must implement the official protocol, not
"mis-configurations" to accommodate faulty implementations.
Although marketing considerations have led some vendors to
choose mis-configuration defaults, we urge vendors to choose
defaults that will conform to the standard.
Finally, we note that a vendor needs to provide adequate
documentation on all configuration parameters, their limits and
effects.
---------------------------
做一个对周遭的事物包容的人，做一个对自己做事严谨的人!
2007年4月30日星期一
四月结束，迎接五一
出差回来后一直把自己搞的很忙，一是项目的事情的确千头万绪，另一是自己也让自己静下来做点应该做的事情。感觉自己在最要好的几个哥们之间是个小辈，也许是自己年龄最小，读的书也最少，所以向我最钦佩的Simon博士学习，多读些书，慢慢积累。
这段时间值得庆祝的事情挺多的，最钦佩的Simon博士自己搞的两个新产品都有了形状，也许能成为公司产品的未来，老罗说Simon再次证明了“不需要很多人也能做好很多事”。今天下午老杨说这段时间餐厅的状况有些好转了，质量不稳定的问题已经解决，收入开始慢慢增加，希望在下个月开始盈利。乘着牛市的东风，从来不懂这一套的我也依靠基金赚了一点小钱儿，这下镜头有着落了，现在老杨亲自操刀帮俺们折腾，省心。
没时间收拾房子，前天晚上终于决定得收拾了，在下班后到山姆买粮食的时候，顺便还买了一个花瓶和一束花，我也不知道什么花，好像是康乃馨吧。
这段时间值得庆祝的事情挺多的，最钦佩的Simon博士自己搞的两个新产品都有了形状，也许能成为公司产品的未来，老罗说Simon再次证明了“不需要很多人也能做好很多事”。今天下午老杨说这段时间餐厅的状况有些好转了，质量不稳定的问题已经解决，收入开始慢慢增加，希望在下个月开始盈利。乘着牛市的东风，从来不懂这一套的我也依靠基金赚了一点小钱儿，这下镜头有着落了，现在老杨亲自操刀帮俺们折腾，省心。
没时间收拾房子，前天晚上终于决定得收拾了，在下班后到山姆买粮食的时候，顺便还买了一个花瓶和一束花，我也不知道什么花，好像是康乃馨吧。
2007年3月22日星期四
2007年3月17日星期六
在烂和乱中旅行
产品做的太烂，项目做的太乱。到头来还得去菲律宾收拾这个摊子，明明知道不会有好结果，还得硬着头皮上，咱只是个小人物。
不过，权当去旅行了，在这烂和乱中自得其他乐。带上照相机，拍拍照去。买些便宜衣服回来，菲国的衣服很便宜，LEE牛仔裤才150块，买他个十来条的。
＝＝＝＝＝＝
刚才换台看到一电视剧一段巨逗：黑夜房顶，一警察追一歹徒，歹徒前面猛跑，警察后面拿枪猛追，咣放了一枪打歹徒后背上爬下了，歹徒竟然爬起来继续跑，然后咣一枪又打后背了。这回歹徒从地上爬起来不干了，冲那警察就开骂“老子TM不想理你就算了，你丫打起来没完了”。再看那警察傻眼了，虽然没说话但估计在想“靠，今天遇见超人了”。歹徒说完从背后扽出一片儿刀来，镜头特写片儿刀上还有两个弹痕，敢情两枪都打这片儿到上了。这剧情设计的，不仅台词够逗，枪法还那么准。
不过，权当去旅行了，在这烂和乱中自得其他乐。带上照相机，拍拍照去。买些便宜衣服回来，菲国的衣服很便宜，LEE牛仔裤才150块，买他个十来条的。
＝＝＝＝＝＝
刚才换台看到一电视剧一段巨逗：黑夜房顶，一警察追一歹徒，歹徒前面猛跑，警察后面拿枪猛追，咣放了一枪打歹徒后背上爬下了，歹徒竟然爬起来继续跑，然后咣一枪又打后背了。这回歹徒从地上爬起来不干了，冲那警察就开骂“老子TM不想理你就算了，你丫打起来没完了”。再看那警察傻眼了，虽然没说话但估计在想“靠，今天遇见超人了”。歹徒说完从背后扽出一片儿刀来，镜头特写片儿刀上还有两个弹痕，敢情两枪都打这片儿到上了。这剧情设计的，不仅台词够逗，枪法还那么准。
2006年8月17日星期四
当Telecom遇上Internet
在电信行业呆了8年了，自从走出校园就双脚踏进这个曾经也许目前还在令很多年轻人羡慕的行业中，成为一名技术人员，一干就是8年，而且在一个公司的同一个产品线上一干就是7年。这里我说的Telecom其实就是传统的语音通信，只不过后来顺应潮流有了移动和IP的一些东西甚至有那么点点增值业务。记得刚刚工作时拿着组长给自己的通信协议象看天书，苦读三个月，也还是一知半解几乎不解，后来凭着前辈的带领和自己的努力总算有了些长进，并且安安生生兢兢业业地在这个行业中呆了下来。多年过后，经过自己的手的产品也有几代了，有成功的也有失败的，自己写的软件也在服务着国内国外几千万用户。曾几何时，自己也是那么骄傲和自豪，成就感和自信充满着内心，认为我就是这个“高科技”行业中有贡献的一员了，认为我为公司和社会创造了很大的价值了。常常也会在别人面前说“我工作这么多年都在第一线产品的第一线工作”。牛吧，呵呵。
而不知不觉间，却在这样的工作中渐渐迷失着，不知道方向在哪里，不知道是否还能象以前那样富有激情和自信了。在这个Internet的时代，是“头脑风暴”的时代，每天都有人想出新的Idea，每天都有新的技术诞生，就像忽然间大家都谈搜索谈Google，忽然间都谈流媒体，忽然间又都谈P2P一样。自己觉得自己多年来所固守的传统电信领域在着个风暴中不知道应该处于什么样的角落，面对扑面而来的Internet风暴，自己迷失了，自信在慢慢变弱，激情在慢慢变少，于是每日的工作虽然依然忙碌，依然为产品的发展和质量忙碌着，但冥冥间好像失去了什么，而不经意间失去的正是激情、趣味，更重要的是自信。
最近才多一些关注Internet上的一些新的思想、概念和技术。说“关注”就是有点认真地去理解它们，而以前迷失中所看所想的就不叫关注了。经常会感慨技术和思想理念的日新月异，而且抛开能否盈利赚钱不说，这些东西真的很有趣，让我们这些搞技术的赞叹和开心，因为你可以很快地去尝试试验它，比较爽。而且每项技术思想并不是都非常高深没测，高深没测的也觉得有趣而且有触手可及的感觉，很多我们以前认为没有用处的数学在这里都可以发挥简单而有趣的效果。就说最近几年特别是现在比较火的P2P把，适用的领域真的是太广了。联想传统搜索技术如Google和Yahoo的复杂，再试用一下Gnutella，真的是感慨，那么一个小小的客户端软件就可以做成如此完美的一件大事。坐在电脑前面，工作间隙打开PPStream或PPLive等视频直播软件，就可以欣赏丰富多彩的电视节目和影片，我比较喜欢看国家地理，而这些是那么容易。或者上到YouTube或者国内的6rooms等视频点播网站，就可以欣赏幽默搞笑经典的视频短片。忽然觉得，现在的Internet再不是我们以前所理解的互联网，那是一个死死的被动浏览的集中型大网站为中心的网站型的互联网，而现在是每个个体活跃参与而自行组织和分享资源即时通讯的Internet。甚至我们有时会把这些思想联想到管理领域，投资领域。和几个好友聊天时，聊到公司组织的管理，聊到江浙小老板们的资金共享方式等等，其实它们真的很相似，真的是神奇。
于是好像明白了一些什么，我想我的兴趣和事业激情应该就在这Internet里面，期待拨云见日的时刻。我常说我是个比较慢热的人，智商也不够高，但悟性应该还是有的。在Telecom中积累的经验面对的虽几乎是个全新的领域，但做事和思考的方式都是一样的，对软件的实现和理解也是不会变的。因此就让我满心期待吧。
也许这是很多在一个技术里做了多年的人所面临的同样的问题，希望在他们迷失的那些时候你能给予他支持，其实我真的希望在我迷失的那些时候有个人能给我支持和鼓励。
而不知不觉间，却在这样的工作中渐渐迷失着，不知道方向在哪里，不知道是否还能象以前那样富有激情和自信了。在这个Internet的时代，是“头脑风暴”的时代，每天都有人想出新的Idea，每天都有新的技术诞生，就像忽然间大家都谈搜索谈Google，忽然间都谈流媒体，忽然间又都谈P2P一样。自己觉得自己多年来所固守的传统电信领域在着个风暴中不知道应该处于什么样的角落，面对扑面而来的Internet风暴，自己迷失了，自信在慢慢变弱，激情在慢慢变少，于是每日的工作虽然依然忙碌，依然为产品的发展和质量忙碌着，但冥冥间好像失去了什么，而不经意间失去的正是激情、趣味，更重要的是自信。
最近才多一些关注Internet上的一些新的思想、概念和技术。说“关注”就是有点认真地去理解它们，而以前迷失中所看所想的就不叫关注了。经常会感慨技术和思想理念的日新月异，而且抛开能否盈利赚钱不说，这些东西真的很有趣，让我们这些搞技术的赞叹和开心，因为你可以很快地去尝试试验它，比较爽。而且每项技术思想并不是都非常高深没测，高深没测的也觉得有趣而且有触手可及的感觉，很多我们以前认为没有用处的数学在这里都可以发挥简单而有趣的效果。就说最近几年特别是现在比较火的P2P把，适用的领域真的是太广了。联想传统搜索技术如Google和Yahoo的复杂，再试用一下Gnutella，真的是感慨，那么一个小小的客户端软件就可以做成如此完美的一件大事。坐在电脑前面，工作间隙打开PPStream或PPLive等视频直播软件，就可以欣赏丰富多彩的电视节目和影片，我比较喜欢看国家地理，而这些是那么容易。或者上到YouTube或者国内的6rooms等视频点播网站，就可以欣赏幽默搞笑经典的视频短片。忽然觉得，现在的Internet再不是我们以前所理解的互联网，那是一个死死的被动浏览的集中型大网站为中心的网站型的互联网，而现在是每个个体活跃参与而自行组织和分享资源即时通讯的Internet。甚至我们有时会把这些思想联想到管理领域，投资领域。和几个好友聊天时，聊到公司组织的管理，聊到江浙小老板们的资金共享方式等等，其实它们真的很相似，真的是神奇。
于是好像明白了一些什么，我想我的兴趣和事业激情应该就在这Internet里面，期待拨云见日的时刻。我常说我是个比较慢热的人，智商也不够高，但悟性应该还是有的。在Telecom中积累的经验面对的虽几乎是个全新的领域，但做事和思考的方式都是一样的，对软件的实现和理解也是不会变的。因此就让我满心期待吧。
也许这是很多在一个技术里做了多年的人所面临的同样的问题，希望在他们迷失的那些时候你能给予他支持，其实我真的希望在我迷失的那些时候有个人能给我支持和鼓励。
2006年7月18日星期二
夕阳无限好
最近睡的比较晚，因此每次上来都过了零点，今天也不例外。星期一过的不算忙，公司的邮山邮海和会山会海占去了大部分时间，剩下的时间除了NGN的本职工作、帮助Review小组的设计文档外，就是钻研一下IPTV的基础了，IPTV我是外行，了解一下，看下一步能不能出些力了。Adrian的文档写的不错，有六十多页，Review了两次才搞玩，赞一下，不过后面的工作还是很多的，Adrian要再接再厉了。下午开会前，收到Cathy的一封邮件，Cathy的邮件一般都是关于工作的，不是叫我Commit开发进度就是让我安排人支持测试或现场，实在是烦；呵呵，这次却是关于星座的，这mm对星座很着迷。又在帮我分析适合我的mm星座了，真是个热心mm。
晚上回到家，打开电脑看IPTV文档，却六神无主，于是心情不爽，于是打几个电话，于是下楼走走，顺便跟老杨在电话了聊了几句。受台风影响，最近深圳天气很凉爽，小风吹着，心情还算不错，于是返回继续看文档。
照片是上次去南澳海边的时候回来的路上，刚刚走过南澳镇，看到夕阳很美，夕阳下的长堤和轮船的剪影也不错，于是把车停在路边，手持随便摁了一个。想起一件事，当时几个陌生男女也在看风景，看到我拍照，就凑过来看，还看了其他照片，说拍的好，非要我讲如何拍。嗨，我可是连摄影的门还没入的啊，哪里懂得，于是就告诉他们两个网址nphoto和xitek逃走。
此刻恰好听到CD机正在放着《小镇姑娘》，不是陶喆的，而是唐红唱的同一首歌。第一次听到这首歌也不是陶喆，而是收音机里放的唐红。歌词我就不贴了，你要是喜欢就baidu一下吧。
订阅：
博文 (Atom)