2007年5月29日星期二
Vacation, Day 5
今天纯粹休息，睡了个对时。雾都宾馆就在大礼堂附近，走过一条街就是上清寺了，在这条路上吃了石磨豆花饭：一荤一素两个菜，一碗豆花，米饭随便吃，21块钱，吃了很久，吃的很饱。步行到上清寺坐车去机场回家了。
2007年5月28日星期一
Vacation, Day 4
今天没有任何计划，所以睡到9点才醒来，外面竟然蓝天白云。因为昨天的天气拍照郁闷，于是又有了进沟的冲动。昨天没办二次进沟的手续，售票员说只能再次买全票了，很郁闷，但犹豫再三还是准备买票了，钱已经放在柜台上了，那个售票员突然问我相机里面有没有昨天在沟里拍的照片，我说有两张，她说给你省点钱吧，于是拿着我的相机进去请示他们头去了，然后很高兴地告诉我不用再买门票了。
今天的天气真的很不错，“晴九寨，雨黄龙”，没有蓝天白云九寨就没意思了。不想再走路了，所以几乎都是坐车再次扫了一遍。
拍了些照片，大部分放在Flickr上了: http://www.flickr.com/photos/schubertzhang/
对自己的拍摄越来越不满意了.......
今天的天气真的很不错，“晴九寨，雨黄龙”，没有蓝天白云九寨就没意思了。不想再走路了，所以几乎都是坐车再次扫了一遍。
拍了些照片，大部分放在Flickr上了: http://www.flickr.com/photos/schubertzhang/
对自己的拍摄越来越不满意了.......
这才是长海
则查洼沟的山峰
镜海一隅
树正瀑布
在树正寨
下午去机场前，到售票厅跟那位售票员道谢和说了再见。乘出租到机场要1个半小时，正要出镇子的时候，路边一排放学的藏族小学生，我还没反应过来，发现他们中有的孩子竟向我乘坐的车子行少先队礼，于是我跟他们挥手再见，他们中也就有更多的孩子举起了手。车子一直飞快地向上爬，被满眼的绿树、蓝天、白云包围，我把车窗开的很大，任由凉风吹着，司机很配合地在我想让他停下来欣赏美丽的风景的时候就停在路边等我。
路边的村寨，也许是度假村
2007年5月27日星期日
Vacation, Day 3
在五花海子老虎嘴拍摄的那张照片
早上7点多就醒来，看看窗外似乎阴沉沉的，于是不急着出去，慢慢整理背包，下楼吃饭，因为不打算在沟里吃午餐，所以吃的特别多，临走还偷了几个馒头塞在包里。星宇国际酒店离沟口只有1500米，买票的时候被一妇女拉住说是买多了一张票要买给我，于是就买了她的票进了沟，想轻松些，没有办理第二天二次进沟的手续。
6年后又一次来到九寨沟，却是另一种心境。同样是夏天，并不是九寨沟景色最好的秋天，只是在这个时间想来了就来了。有时候我出去旅行并不是去看风景，而是想去某个地方的时候就去，比较随便。
顺日则沟到顶原始森林，开始往下走，因为早晨，而且大部分游客坐车，所以栈道上和公路上人很少，虽然阴天，但也难得这么清净，空气里弥漫着清香和凉爽。走到芳草海和天鹅海（藏人喜欢把湖叫做海子，其实译成英文还是lake），10点了，天空才有一点白云，但依然灰白，游人不多，我可以独自坐在天鹅海边的长凳上看湖里的红嘴鸭游来游去，放眼看不到什么人，只有鸟叫声和流水声。从公路旁的一个入口闯入一段禁止进入的栈道，前后没有一个人，不时看到落石横在栈道上，砸出一个个大坑，看了这段栈道真的很危险，于是更加注意下一个上公路的出口。走了很久才上了公路，看到先前在公路上遇到的两个人，想帮那老太太提提包，她看看我背上鼓鼓的大包说等提不动的时候再让我帮忙。这时才发现帽子不知什么时候不见了，可能在栈道上休息时丢在那里了，记得上次来的时候也把帽子丢了，不过那次是丢在了车上。遇到一个也从那个栈道下来的宜宾的哥们，说在栈道上看到一个帽子但没有捡，我说那一定是我的。我们一起走到箭竹海，我让他先走，自己找了个不错的地方休息，坐在水边的木台上，不想拍照只想坐着，享受这份安静，微风吹过，湖面上飘着很多柳絮。抬头看看雪山，仰头喝口啤酒，不想离开。
从熊猫海瀑布开始很长一段是枯水，很乏味，不知道刚才那些水都到哪里去了，也许到了地下？正在乱拍，一个mm让我帮忙给她拍照，于是就攀谈起来，大三的学生，一个人跑出来玩，偷偷借住在沟里的寨子里。两个人一路走一路聊，也就不怎么觉得乏味了。快到五花海的时候发现通向高处老虎嘴的栈道又被封闭了，那可是拍摄五花海最好的地点啊。于是我们钻过了篱笆，上到老虎嘴时才发现还有一个封死的门，门口还有一个工作人员不让我们上去，还好小mm几句话就把那伙计搞定了，这才大功告成。就是在这里几乎不拍自己的我，在小mm的帮忙下也拍了两张留在相机里，正是这两张照片第二天派上了大用场，省去了220块钱。走过孔雀河道、金铃海、珍珠滩瀑布（据说是西游记片尾的拍摄地），一直到诺日朗，已经累的不行了，小mm更是说一天没吃的，快崩溃了，还好我包里有包饼干才算帮了她点忙。而我的左膝关节也痛的厉害，看来今天真的是路走多了，从早上到现在一直在走，已经6、7个小时了。
看着阴沉的天，猜想也许明天也是这样吧，在小mm的建议下坐车走则查洼沟去看看长海，明天也许就不用再来了，不坐车不行了，走不动了。则查洼沟基本上都枯竭了，只有到顶才看到长海有点水，没有蓝天和白云映衬下的长海和远处的雪山没有一点生气。冷风呼呼地，此时此刻这个景点竟然没有了一个人，很是冷清，和我第二天看到的情景天壤之别。
那个学生mm在树正寨下车，我就出沟了，今天走的路真的多了，左膝盖很痛，已经没有心思再逛，直接回到酒店吃方便面睡觉。
拍了些照片，大部分都放在Flickr上了：http://www.flickr.com/photos/schubertzhang/，这里随便上几张今天拍的：
6年后又一次来到九寨沟，却是另一种心境。同样是夏天，并不是九寨沟景色最好的秋天，只是在这个时间想来了就来了。有时候我出去旅行并不是去看风景，而是想去某个地方的时候就去，比较随便。
顺日则沟到顶原始森林，开始往下走，因为早晨，而且大部分游客坐车，所以栈道上和公路上人很少，虽然阴天，但也难得这么清净，空气里弥漫着清香和凉爽。走到芳草海和天鹅海（藏人喜欢把湖叫做海子，其实译成英文还是lake），10点了，天空才有一点白云，但依然灰白，游人不多，我可以独自坐在天鹅海边的长凳上看湖里的红嘴鸭游来游去，放眼看不到什么人，只有鸟叫声和流水声。从公路旁的一个入口闯入一段禁止进入的栈道，前后没有一个人，不时看到落石横在栈道上，砸出一个个大坑，看了这段栈道真的很危险，于是更加注意下一个上公路的出口。走了很久才上了公路，看到先前在公路上遇到的两个人，想帮那老太太提提包，她看看我背上鼓鼓的大包说等提不动的时候再让我帮忙。这时才发现帽子不知什么时候不见了，可能在栈道上休息时丢在那里了，记得上次来的时候也把帽子丢了，不过那次是丢在了车上。遇到一个也从那个栈道下来的宜宾的哥们，说在栈道上看到一个帽子但没有捡，我说那一定是我的。我们一起走到箭竹海，我让他先走，自己找了个不错的地方休息，坐在水边的木台上，不想拍照只想坐着，享受这份安静，微风吹过，湖面上飘着很多柳絮。抬头看看雪山，仰头喝口啤酒，不想离开。
从熊猫海瀑布开始很长一段是枯水，很乏味，不知道刚才那些水都到哪里去了，也许到了地下？正在乱拍，一个mm让我帮忙给她拍照，于是就攀谈起来，大三的学生，一个人跑出来玩，偷偷借住在沟里的寨子里。两个人一路走一路聊，也就不怎么觉得乏味了。快到五花海的时候发现通向高处老虎嘴的栈道又被封闭了，那可是拍摄五花海最好的地点啊。于是我们钻过了篱笆，上到老虎嘴时才发现还有一个封死的门，门口还有一个工作人员不让我们上去，还好小mm几句话就把那伙计搞定了，这才大功告成。就是在这里几乎不拍自己的我，在小mm的帮忙下也拍了两张留在相机里，正是这两张照片第二天派上了大用场，省去了220块钱。走过孔雀河道、金铃海、珍珠滩瀑布（据说是西游记片尾的拍摄地），一直到诺日朗，已经累的不行了，小mm更是说一天没吃的，快崩溃了，还好我包里有包饼干才算帮了她点忙。而我的左膝关节也痛的厉害，看来今天真的是路走多了，从早上到现在一直在走，已经6、7个小时了。
看着阴沉的天，猜想也许明天也是这样吧，在小mm的建议下坐车走则查洼沟去看看长海，明天也许就不用再来了，不坐车不行了，走不动了。则查洼沟基本上都枯竭了，只有到顶才看到长海有点水，没有蓝天和白云映衬下的长海和远处的雪山没有一点生气。冷风呼呼地，此时此刻这个景点竟然没有了一个人，很是冷清，和我第二天看到的情景天壤之别。
那个学生mm在树正寨下车，我就出沟了，今天走的路真的多了，左膝盖很痛，已经没有心思再逛，直接回到酒店吃方便面睡觉。拍了些照片，大部分都放在Flickr上了：http://www.flickr.com/photos/schubertzhang/，这里随便上几张今天拍的：
芳草海子
在箭竹海休息
五花海子一隅
2007年5月26日星期六
Vacation, Day 2
熟悉的大礼堂－－人民广场
因为下午要赶飞机，4点就得动身去机场，今天不能去较远的地方，比如大足、晋云山等等。只能找近点的地方去，其实我自己倒更想在这个城市的犄角旮旯走走，吃吃那些路边小店，比如石磨豆花、泉水鸡什么的，逛逛那些小巷子。天气很凉爽，走起来也不会累。确定去歌乐山，不远，但山里很幽静，一个人坐一个缆车，身边都是雾气腾腾的，很安静，很绿色。山上也没几个人，大多悠闲地打麻将，很安逸的样子。歌乐山上没什么好玩的，早点回去，于是中午就下山了，在沙坪坝又吃火锅--刘一手，感觉一样，肚子依然很争气。下午我把他们带到博物馆－－我去过的三峡博物馆，我就一个人到别处溜达了。
昨天晚上到今天的收获是：吃了几次火锅肚子都很争气，看到若干美女，研究若干地图，很享受这里难得的凉爽天气。
昨天晚上到今天的收获是：吃了几次火锅肚子都很争气，看到若干美女，研究若干地图，很享受这里难得的凉爽天气。
本来携程是不送俺到机场的，因为俺没有买送机服务，但司机开那么大一个车也不多我一个，所以就心安理得坐了个免费车。乘傍晚的飞机飞往九寨沟，路程很短，不久就看到窗外的雪山山峰，没有感觉到降落飞机就停在了海拔3千多米的建在天上的机场。乘务员播报仓外温度是7度，第一次听到还以为听错了，心里想着是17度才对呀，其实不止我一个这么认为，直到第二次乘务员特别强调7度，大家才开始唏嘘。没有带外套，不禁担心自己一件衬衫是否能扛的住，于是把挽起的袖子放下来扣严实，把帽子戴上。下了飞机，虽然有些凉，但还算受的了，环顾四周，很多人竟然穿上了羽绒服。
乘携程安排的接机大巴一路下山，等到酒店的时候已经是9点了，一身的倦意，哪里也不想去，于是就在附近的超市买了一大包食品，够这几天在这里吃了，晚上就吃了碗方便面打发了。
建在天上的机场
2007年5月25日星期五
Vacation, Day 1
从南滨路的过江索道俯看江面和对面的解放碑商业中心
人们爱逛解放碑
下午从公司溜了出来，奔机场，开始了休假的第一天。有携程的专车到机场接，所以认识了很多一起从深圳来的陌生的朋友，整个面包车上只有我们三个男的，其他都是女士。先到一个酒店卸下了其他两个，就剩下我一个男的了，于是就成了她们起轰的对象，等车到达酒店已经是吃晚饭的时间了。又一次来到这个熟悉而又陌生的城市，说不出的滋味。而天气是我从来没有感受过的凉爽，和深圳真是天壤之别，不能相信是从海滨城市来到了大火炉，反而相反。Check In的时候两个mm让我晚上带她们去吃火锅，说真的虽然多次来到这个火锅之都，还真对这里的火锅没有什么印象。只知道据说南滨路上有很多，每天晚上有很多人在那里吃，于是就去了那里。虽然我们吃的是德庄火锅，比较有名的店了，但这里的下锅菜看起来都不怎么样，没有一个看起来很舒服的，比起深圳的视觉效果差了很多，但煮了吃起来还是很香的，好吃。其实已经很久不吃火锅了--为了俺的胃，今天不打算照顾胃了，放开了吃，居然整个晚上都很舒服。原来南滨路就在朝天门对面，吃完火锅就乘过江索道到了对面，步行逛了解放碑，因为酒店就在不远处，所以了就很闲散地逛回去。
因为明天还在这里呆一整天，两个mm还要定明天的行程，看来我本来计划独自去自己想去的地方走走的计划要泡汤了，只能等回来的时候了。
回了酒店，洗洗早早就睡了，希望这次旅行不要太累，按照自己自由的行程安排。
2007年5月22日星期二
我的酷包NG5162
我的NG5162
终于还是没有抵挡住National Geographic的诱惑，整了回来。寻找即可以装器材，也可以装些衣服等其他东西的包好久了，看到的都不够满意，有的设计不合理，有的太大，装满了也背不动，有的质量不够好。NG够酷，款式也很多，最后选择了5162，可以装：
1. 下装摄影器材：可以装1-2个机身，3-4个镜头，其他配件等;
2. 上装衣物：一两天的衣服等物品；
3. 背部装笔记本
4. 外挂角架
5. 侧袋装雨伞、水瓶等
6. 各小袋装小件物品
7. 捆绑其他外挂物品
其实东西装多了背起来多累啊，还是只装1个机身，2-3个镜头，然后带几件衣服就可以了。如果远行，只这一个小包当然也是不够用的，最好还是两个人，一个人背器材包，一个人背衣物包比较合适。大后天我将背着他去旅行。
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年5月19日星期六
资助藏区孤儿
这两天很累，各方面的事情都要俺做，脖子都疼了，再好说话也得学着拒绝了，呵呵。
昨天送DD和AA同学回家路上跟我说的资助西部儿童的事情，今天就定下来了，我资助了1千块。虽然对他们搞的这个资助项目存在一些疑问和担忧，但毕竟这是我第一次资助藏区的孤儿，能帮助他们我感到很高兴，虽然不是什么大事。我想等这个资助年度过去了，我会去认真选择一个长期的资助的对象。下午我在MSN上跟老罗说了，老罗说“对，要做一个高尚的人”。其实这帮好朋友都经常帮助一些需要帮助的人，比如DD和义气的老杨。
这个资助项目的对象是川藏地区的藏族孤儿，目前一共有几十个，原来是由一个活佛收养在寺院里的，一些好心的人看到他们可怜，想让他们受到更好的教育，而且还有很多寺院不能收养的女童，他们想培养这些孩子，让他们以后也能帮助当地的其他孩子。于是，这些人就把这些孩子接到了广州，编制成一个班接受教育。
我觉得这次的捐助活动存在以下几个担忧：
1. 捐助成本高（一个孩子的生活费用，完全可以够好几个孩子在当地上学了）；
2. 成本高就救助孩子少；
3. 对他们成长不好（在习惯了几年广州的繁华，回去后他们还能适应藏区的清苦么）。
很理解将这些孤儿带到广州来的初衷和希望他们受到更好的教育后，再回藏区帮助其他人的深意。希望他们考虑，因为这次的活动不可能是一次性的（不是在考虑如何救助更多还在藏区的孩子么），一旦开始就注定是一个长远、艰苦的过程。让我们一起想想怎样把这事情做得更好，走得更远吧。
昨天送DD和AA同学回家路上跟我说的资助西部儿童的事情，今天就定下来了，我资助了1千块。虽然对他们搞的这个资助项目存在一些疑问和担忧，但毕竟这是我第一次资助藏区的孤儿，能帮助他们我感到很高兴，虽然不是什么大事。我想等这个资助年度过去了，我会去认真选择一个长期的资助的对象。下午我在MSN上跟老罗说了，老罗说“对，要做一个高尚的人”。其实这帮好朋友都经常帮助一些需要帮助的人，比如DD和义气的老杨。
这个资助项目的对象是川藏地区的藏族孤儿，目前一共有几十个，原来是由一个活佛收养在寺院里的，一些好心的人看到他们可怜，想让他们受到更好的教育，而且还有很多寺院不能收养的女童，他们想培养这些孩子，让他们以后也能帮助当地的其他孩子。于是，这些人就把这些孩子接到了广州，编制成一个班接受教育。
我觉得这次的捐助活动存在以下几个担忧：
1. 捐助成本高（一个孩子的生活费用，完全可以够好几个孩子在当地上学了）；
2. 成本高就救助孩子少；
3. 对他们成长不好（在习惯了几年广州的繁华，回去后他们还能适应藏区的清苦么）。
很理解将这些孤儿带到广州来的初衷和希望他们受到更好的教育后，再回藏区帮助其他人的深意。希望他们考虑，因为这次的活动不可能是一次性的（不是在考虑如何救助更多还在藏区的孩子么），一旦开始就注定是一个长远、艰苦的过程。让我们一起想想怎样把这事情做得更好，走得更远吧。
订阅：
博文 (Atom)