今天又一次车祸，虽然没有央及他人和我自己，但也算是又一次比较严重的事故了。今天早晨起的较早，出门时还很放松，特意把昨晚刚刚刻录的那张Declan Galbraith的Tell Me Why放入CD，在美妙的音乐里开出了家门，但很快就撞了。
和上次事故一样，在追尾之前没有看到前面近距离的车刹车，事后无法回忆起在发生的那一刹那我在做什么，为什么什么都每看见。上次是10月25日，这次是10月22日，也许个时间段我真的不适合开车。
2007年9月12日星期三
2007年9月4日星期二
《创新的迷失》
几个月前闲逛时买了这本《创新的迷失》，觉得观点不错，可惜翻译不好，所以一直被我放在书架上到现在才翻看完。觉得不仅是在技术领域发展的一些指导，也是以后投资或者理财方面的一些指导。
高科技商业化失败率之高臭名昭著
科技发明者认为他们是主导，但事实上，用户才是主导
你可以创造出十分出色的产品，但是你也必须让它不那么让人生畏
其实大多数消费者、用户对科技产品有抵抗和不接受心理
只有人们觉得维持现有习惯比接受一个新东西更痛苦时才会去尝试接受新玩意
“第二系统综合证”：
在第一系统中，建立者很乐意找到一条路径将“系统”建立起来。这是个很简洁明了的系统，它能简洁出色的到达它该完成的功能。这有点让我想起我在这个工作8年的公司中参与实现的第一个产品，它用最短的时间对目标移动通讯市场实现了应有的功能，实现了巨大的商业价值，也为公司赚足了钱。可随着公司的发展，市场的拓展，“第二系统”出现了，问题也出现了。从四面八方传来各种古怪的需求和以前产品建立之初所排斥的观点和想法，于是在没有有力控制的情况下，甚至在某些人为政治因素推动下，“第二系统”出现了，它几乎包括了第一系统中所排斥的很多观点和想法，也将很多销售人员和不成熟的客户梦想的新创意包含其中，它是一个充满“各种功能”的、“全面完整”的、“更好”的系统。其结果可相而知，甚至到目前为止，仍然在持续这种状况的蔓延，但却怎么也无法赢得更多客户。最终创造出来的是个bloatware。
现在，检验过去失败的原因，才是一个正确的方向。
让科技更容易，让科技更简单。这句话是我最欣赏的。
在电信行业工作多年，感触很多，电信行业一直有一种心理情愫，认为自己才是这个行业的“正统”，甚至一些知名的制造公司和运营公司以及他们的员工都有这种情愫， 而这种情愫的后果是使这个行业很难适应当前的创造和经济发展形式。他们会把很多很简单的事情搞的非常“正统”，其实是复杂，想想我们经历的ISDN、智能电话、可视电话、NGN、复杂的PDA手机等等。简单的SIP协议在电信领域会变得如此复杂，我想这不是建立者的初衷。还有业界正在热烈讨论的iMS，虽然我对其细节了解很少，但持反对态度，觉得这是电信界自己在给自己找麻烦。即便是新兴的IPTV和IP监控领域，一旦到了电信行业，也会被搞的过于复杂，标准多而繁琐，让人无所适从。电信行业总想创造或者制定一个全面的、革命性的、下一代的大系统，做件大事，从而保证未来数十年都在这个革命性的成果上舒舒服服地过日子。其实所谓“下一代”的说法我本身就觉得很荒唐，想想从上世纪90年代到现在走过的路，还是先着眼现在吧。其实我们中的很多人已经意识到电信这个行业必须要改变了，已经开始“反正统”了，我们不能再沿着既有的思路思考了。
看看我们的电脑上装了多少IM软件，MSN、GoogleTalk、YahooMessager、ICQ、QQ，也许还有更多，每个产品提供者提供一个软件、一套协议，而我们又有喜好不同工具的朋友，怎么办？何不试试免费软件Pidjin，它可以让你不用关心你的某个朋友使用的是哪个IM，一个软件把所有的都包含进去了。这就是让我方便了。Google的Gtalk2VoIP，也在做这个事情，它已经可以让GoogleTalk、MSN、YahooMessager互相通信了。其实Google所做的很多事情都是在让用户感到方便、简单，你想了解任何东西只要在只有一个输入框的干干净净的google首页上搜索一下就可以了。
同时我也想起了互动电视、IPTV的发展也可能不尽如人意，也想起了从网络游戏中赚了大钱的盛大后来雄心勃勃要做机顶盒和复杂的遥控器想把互动娱乐带到每个人面前的失败。这些东西给普通人的生活带来的只有辛苦。
新技术、创新本身仍然相当有用，只是用户不感兴趣或者商业模式存在缺陷。
“更快的失败速度对于科技生态系统是有利的”。这句话让我想起我所工作过的公司的经历。
投资者的危机在于对坐失良机的恐慌，害怕错过的担心远远超过对投资损失的预期痛苦。我们需要通过对商业模式的怀疑，来调整对科技创造天堂的一厢情愿。另外不能低估人们对于变化的恐惧。人们得有需求危机才会接纳新技术带来得变化。
书中“白痴点”的论述很有意思。在某项新产品的市场占有达到10％-15％时，人们会为没有拥有该产品而感到压力。从而该产品的市场占有率会迅速大幅提高。
作者认为近期会取得成功的技术和产业：
1. 平板显示器: 平面电视、个人电脑显示器、笔记本电脑的普及
2. 商用移动Email系统: Blackberry
3. 商业只能软件: 海量数据挖掘
4. 卫星广播
学习Salesforce.com的经验，我之所以对书中介绍的Salesforce.com的案例印象深刻是因为这和我最近两年想的一些创业想法符合。记得接触几个在一些国有企业和行政事业单位从事非技术工作的朋友后发现，他们正在使用的管理信息和分析处理信息的方式太辛苦，其实有完全简单的技术方式解决这个问题。例如有个做HR的朋友，公司有200来人，却只有她一个HR和一个助手，每天处理的事情很多很辛苦，但她向我自豪地说她几乎记住了所有人的电话号码和工号甚至身份证号码。其实一个简单的Web数据库工具就可以使用浏览器管理了，随时可以查询和修改。于是我想到了提供在线的企业和个人信息管理和分析系统，也可以为企业安装在企业内部共享的在那个有限范围内的在线系统。Salesforce.com的CRM也是如此，只是他们做的很专注和很牛。另外Saleforce.com的开发方式也很不错，他们不断在线改进自己的系统，不断收到用户的投诉和反馈，并将这些转变成新的功能，他们分析用户的行为，从而了解用户最需要什么，因此他建立了一个社区，用户都变得很踊跃提出意见和投诉，并享用在线软件的改进。这种开发方式具备某些开源社区的优点，用户都在参与其中，并担当了测试工程师的角色。Saleforce.com是以一些列不断的小进步前进的，并且很少有大场面，也很少有大失败，从而也避免了传统软件开发和发布方式带来的心理因素造成的团体和文化创伤。
要想了解一个组织的内部文化，最好就是了解其处理失败的方式。如果失败没有处理好，其内部文化就象监狱一样。如果一个组织，特别是技术组织变化缓慢，就要小心了。当一个人形成了一种理论，以后不管什么事情，他脑海里只会浮现出与那种理论相符的观点。我们一定要提防这种情况。
没有真正意义上的产品，事实上每种产品都是解决某些问题的服务。
要做的事：
1.快速建立产品原型，持续重复试验，和协同设计，建立这样的氛围
2. 研究人类的行为，发现并引导需求危机，然后填补缺口
高科技商业化失败率之高臭名昭著
科技发明者认为他们是主导，但事实上，用户才是主导
你可以创造出十分出色的产品，但是你也必须让它不那么让人生畏
其实大多数消费者、用户对科技产品有抵抗和不接受心理
只有人们觉得维持现有习惯比接受一个新东西更痛苦时才会去尝试接受新玩意
“第二系统综合证”：
在第一系统中，建立者很乐意找到一条路径将“系统”建立起来。这是个很简洁明了的系统，它能简洁出色的到达它该完成的功能。这有点让我想起我在这个工作8年的公司中参与实现的第一个产品，它用最短的时间对目标移动通讯市场实现了应有的功能，实现了巨大的商业价值，也为公司赚足了钱。可随着公司的发展，市场的拓展，“第二系统”出现了，问题也出现了。从四面八方传来各种古怪的需求和以前产品建立之初所排斥的观点和想法，于是在没有有力控制的情况下，甚至在某些人为政治因素推动下，“第二系统”出现了，它几乎包括了第一系统中所排斥的很多观点和想法，也将很多销售人员和不成熟的客户梦想的新创意包含其中，它是一个充满“各种功能”的、“全面完整”的、“更好”的系统。其结果可相而知，甚至到目前为止，仍然在持续这种状况的蔓延，但却怎么也无法赢得更多客户。最终创造出来的是个bloatware。
现在，检验过去失败的原因，才是一个正确的方向。
让科技更容易，让科技更简单。这句话是我最欣赏的。
在电信行业工作多年，感触很多，电信行业一直有一种心理情愫，认为自己才是这个行业的“正统”，甚至一些知名的制造公司和运营公司以及他们的员工都有这种情愫， 而这种情愫的后果是使这个行业很难适应当前的创造和经济发展形式。他们会把很多很简单的事情搞的非常“正统”，其实是复杂，想想我们经历的ISDN、智能电话、可视电话、NGN、复杂的PDA手机等等。简单的SIP协议在电信领域会变得如此复杂，我想这不是建立者的初衷。还有业界正在热烈讨论的iMS，虽然我对其细节了解很少，但持反对态度，觉得这是电信界自己在给自己找麻烦。即便是新兴的IPTV和IP监控领域，一旦到了电信行业，也会被搞的过于复杂，标准多而繁琐，让人无所适从。电信行业总想创造或者制定一个全面的、革命性的、下一代的大系统，做件大事，从而保证未来数十年都在这个革命性的成果上舒舒服服地过日子。其实所谓“下一代”的说法我本身就觉得很荒唐，想想从上世纪90年代到现在走过的路，还是先着眼现在吧。其实我们中的很多人已经意识到电信这个行业必须要改变了，已经开始“反正统”了，我们不能再沿着既有的思路思考了。
看看我们的电脑上装了多少IM软件，MSN、GoogleTalk、YahooMessager、ICQ、QQ，也许还有更多，每个产品提供者提供一个软件、一套协议，而我们又有喜好不同工具的朋友，怎么办？何不试试免费软件Pidjin，它可以让你不用关心你的某个朋友使用的是哪个IM，一个软件把所有的都包含进去了。这就是让我方便了。Google的Gtalk2VoIP，也在做这个事情，它已经可以让GoogleTalk、MSN、YahooMessager互相通信了。其实Google所做的很多事情都是在让用户感到方便、简单，你想了解任何东西只要在只有一个输入框的干干净净的google首页上搜索一下就可以了。
同时我也想起了互动电视、IPTV的发展也可能不尽如人意，也想起了从网络游戏中赚了大钱的盛大后来雄心勃勃要做机顶盒和复杂的遥控器想把互动娱乐带到每个人面前的失败。这些东西给普通人的生活带来的只有辛苦。
新技术、创新本身仍然相当有用，只是用户不感兴趣或者商业模式存在缺陷。
“更快的失败速度对于科技生态系统是有利的”。这句话让我想起我所工作过的公司的经历。
投资者的危机在于对坐失良机的恐慌，害怕错过的担心远远超过对投资损失的预期痛苦。我们需要通过对商业模式的怀疑，来调整对科技创造天堂的一厢情愿。另外不能低估人们对于变化的恐惧。人们得有需求危机才会接纳新技术带来得变化。
书中“白痴点”的论述很有意思。在某项新产品的市场占有达到10％-15％时，人们会为没有拥有该产品而感到压力。从而该产品的市场占有率会迅速大幅提高。
作者认为近期会取得成功的技术和产业：
1. 平板显示器: 平面电视、个人电脑显示器、笔记本电脑的普及
2. 商用移动Email系统: Blackberry
3. 商业只能软件: 海量数据挖掘
4. 卫星广播
学习Salesforce.com的经验，我之所以对书中介绍的Salesforce.com的案例印象深刻是因为这和我最近两年想的一些创业想法符合。记得接触几个在一些国有企业和行政事业单位从事非技术工作的朋友后发现，他们正在使用的管理信息和分析处理信息的方式太辛苦，其实有完全简单的技术方式解决这个问题。例如有个做HR的朋友，公司有200来人，却只有她一个HR和一个助手，每天处理的事情很多很辛苦，但她向我自豪地说她几乎记住了所有人的电话号码和工号甚至身份证号码。其实一个简单的Web数据库工具就可以使用浏览器管理了，随时可以查询和修改。于是我想到了提供在线的企业和个人信息管理和分析系统，也可以为企业安装在企业内部共享的在那个有限范围内的在线系统。Salesforce.com的CRM也是如此，只是他们做的很专注和很牛。另外Saleforce.com的开发方式也很不错，他们不断在线改进自己的系统，不断收到用户的投诉和反馈，并将这些转变成新的功能，他们分析用户的行为，从而了解用户最需要什么，因此他建立了一个社区，用户都变得很踊跃提出意见和投诉，并享用在线软件的改进。这种开发方式具备某些开源社区的优点，用户都在参与其中，并担当了测试工程师的角色。Saleforce.com是以一些列不断的小进步前进的，并且很少有大场面，也很少有大失败，从而也避免了传统软件开发和发布方式带来的心理因素造成的团体和文化创伤。
要想了解一个组织的内部文化，最好就是了解其处理失败的方式。如果失败没有处理好，其内部文化就象监狱一样。如果一个组织，特别是技术组织变化缓慢，就要小心了。当一个人形成了一种理论，以后不管什么事情，他脑海里只会浮现出与那种理论相符的观点。我们一定要提防这种情况。
没有真正意义上的产品，事实上每种产品都是解决某些问题的服务。
要做的事：
1.快速建立产品原型，持续重复试验，和协同设计，建立这样的氛围
2. 研究人类的行为，发现并引导需求危机，然后填补缺口
2007年8月11日星期六
刘大才子的诗词
刘大才子吧Blog关了，今天在整理硬盘的时候发现我还存着Copy下来的几首诗词，放在这里以免弄丢了。
行香子
次韵宋张先词
长空一碧，晴色均匀。云淡淡，相映罗裙。
燕归新社，又是好春。随折嫩柳，踏青色，游洛神。
雾雨来时，烟波到处。有佳人，轻叩吾门。
人生几回，噩噩昏昏。念往昔事，昨日语，曾经人。
（刘生丙戌春于洛阳）
减字木兰花
斜倚残阳，黄昏左近风初凉。
独上楼头，怅意愁绪理不休。
忍故归路，那堪昔日断魂处。
但闻风吼，欲凭当年独遨游。
（刘生于癸未三月）
怀青莲
李白把酒将诗吟，
文笔天成不留痕。
卧看天际风云起，
哀叹繁华无复存。
（刘生于丙戌二月）
西江月
滴滴娇红洒泪，
点点杨花纷飞。
春去春来心已碎，
举头不见雁归。
水清山亦苍翠，
草绿花也葳蕤。
花开花谢人憔悴，
回首无怨无悔。
蝶恋花
四月二十七日观雨
天雷滚滚震九霄，珠帘散落，爽气侵人脑。
寒蝉噤口鸡不晓，落花昨夜谁曾料。
天公不待与人谋，不期而至，浇的人头透。
若果能浇碎离愁，又何必未雨绸缪。
（刘生丙戌四月末）
风入松
用宋刘克庄韵
山高水远非路长，心中凄凉。
酒不醉人人自醉，滴入愁肠具已亡。
垂首独坐达旦，明室不闻暗香。
寒秋始至初降霜，不眠在床。
口占旧句无新语，只漫叹世事茫茫。
忽而青衫泪湿，奈何愁又断肠。
（作于乙酉十月）
西江月
用东坡平山堂韵
遇仙蓬莱山下，随入画阁楼中。
仙人之语不曾闻，但见唇翕齿动。
穹顶半盘玉色，帘外一缕清风，
吹入画阁转头空，原是南柯一梦。
（作于甲申三月为高考所迷时）
用宋刘克庄韵
山高水远非路长，心中凄凉。
酒不醉人人自醉，滴入愁肠具已亡。
垂首独坐达旦，明室不闻暗香。
寒秋始至初降霜，不眠在床。
口占旧句无新语，只漫叹世事茫茫。
忽而青衫泪湿，奈何愁又断肠。
（作于乙酉十月）
西江月
用东坡平山堂韵
遇仙蓬莱山下，随入画阁楼中。
仙人之语不曾闻，但见唇翕齿动。
穹顶半盘玉色，帘外一缕清风，
吹入画阁转头空，原是南柯一梦。
（作于甲申三月为高考所迷时）
行香子
次韵宋张先词
长空一碧，晴色均匀。云淡淡，相映罗裙。
燕归新社，又是好春。随折嫩柳，踏青色，游洛神。
雾雨来时，烟波到处。有佳人，轻叩吾门。
人生几回，噩噩昏昏。念往昔事，昨日语，曾经人。
（刘生丙戌春于洛阳）
减字木兰花
斜倚残阳，黄昏左近风初凉。
独上楼头，怅意愁绪理不休。
忍故归路，那堪昔日断魂处。
但闻风吼，欲凭当年独遨游。
（刘生于癸未三月）
怀青莲
李白把酒将诗吟，
文笔天成不留痕。
卧看天际风云起，
哀叹繁华无复存。
（刘生于丙戌二月）
西江月
滴滴娇红洒泪，
点点杨花纷飞。
春去春来心已碎，
举头不见雁归。
水清山亦苍翠，
草绿花也葳蕤。
花开花谢人憔悴，
回首无怨无悔。
蝶恋花
四月二十七日观雨
天雷滚滚震九霄，珠帘散落，爽气侵人脑。
寒蝉噤口鸡不晓，落花昨夜谁曾料。
天公不待与人谋，不期而至，浇的人头透。
若果能浇碎离愁，又何必未雨绸缪。
（刘生丙戌四月末）
2007年8月7日星期二
The secret to a happy life
下班后没有急着回家，坐在办公室读了曼昆的“My Rules of Thumb”，虽然肚子有点饿，但觉得文章写的很好。文中把他工作的“经验原则”总结为六点：
- 1. Learn from the Right Mentors;
- 2. Work With Good Co-Workers;
- 3. Have Broad Interests;
- 4. Allocate Time and Crew;
- 5. Write Well;
- 6. Have Fun.
2007年7月29日星期日
2007年7月15日星期日
2007年7月11日星期三
2007年7月8日星期日
2007年7月4日星期三
2007年6月2日星期六
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. 对他们成长不好（在习惯了几年广州的繁华，回去后他们还能适应藏区的清苦么）。
很理解将这些孤儿带到广州来的初衷和希望他们受到更好的教育后，再回藏区帮助其他人的深意。希望他们考虑，因为这次的活动不可能是一次性的（不是在考虑如何救助更多还在藏区的孩子么），一旦开始就注定是一个长远、艰苦的过程。让我们一起想想怎样把这事情做得更好，走得更远吧。
2007年5月2日星期三
2007年4月30日星期一
四月结束，迎接五一
出差回来后一直把自己搞的很忙，一是项目的事情的确千头万绪，另一是自己也让自己静下来做点应该做的事情。感觉自己在最要好的几个哥们之间是个小辈，也许是自己年龄最小，读的书也最少，所以向我最钦佩的Simon博士学习，多读些书，慢慢积累。
这段时间值得庆祝的事情挺多的，最钦佩的Simon博士自己搞的两个新产品都有了形状，也许能成为公司产品的未来，老罗说Simon再次证明了“不需要很多人也能做好很多事”。今天下午老杨说这段时间餐厅的状况有些好转了，质量不稳定的问题已经解决，收入开始慢慢增加，希望在下个月开始盈利。乘着牛市的东风，从来不懂这一套的我也依靠基金赚了一点小钱儿，这下镜头有着落了，现在老杨亲自操刀帮俺们折腾，省心。
没时间收拾房子，前天晚上终于决定得收拾了，在下班后到山姆买粮食的时候，顺便还买了一个花瓶和一束花，我也不知道什么花，好像是康乃馨吧。
这段时间值得庆祝的事情挺多的，最钦佩的Simon博士自己搞的两个新产品都有了形状，也许能成为公司产品的未来，老罗说Simon再次证明了“不需要很多人也能做好很多事”。今天下午老杨说这段时间餐厅的状况有些好转了，质量不稳定的问题已经解决，收入开始慢慢增加，希望在下个月开始盈利。乘着牛市的东风，从来不懂这一套的我也依靠基金赚了一点小钱儿，这下镜头有着落了，现在老杨亲自操刀帮俺们折腾，省心。
没时间收拾房子，前天晚上终于决定得收拾了，在下班后到山姆买粮食的时候，顺便还买了一个花瓶和一束花，我也不知道什么花，好像是康乃馨吧。
2007年4月16日星期一
2007年4月14日星期六
选择镜头的四要点
一、焦距
选择镜头第一个要注意的是镜头的焦距，焦距实际上就是视角问题，焦距不同视角也不同。另外用户自己要明确，我购买镜头的主要目的是什么？是为拍风景还是拍人物等等。众所周知，拍风景宜用广角镜头，而拍人物则宜用望远镜头，所以首先要根据摄影目的来决定自己所要选购的镜头焦距。
拍摄风景最佳焦段是广角焦段24mm、望远焦段200mm（均以35mm规格为标准，下同）。当标准变焦镜头广角焦段从28mm进化到24mm后视角变大，可收纳的景物范围大大拓宽。一般来说拍摄风景对镜头最大光圈要求不太高。如果主要是拍风景的话，选择变焦镜头时广角焦段是24mm基本就够用了。至于望远焦段，起码得是200mm，如果望远焦段是300mm或400mm就更理想了，自由度会大大提高。传统变焦镜头的望远焦段多是300mm，用在数码单反上就是450mm，焦距扩大了1.5倍，用起来会令人感到更加痛快，这一点正是数码单反的价值所在。现在出品的数码专用超广角镜头的广角焦段一般到12mm，相当于35mm规格的18mm，比起35mm规格的28mm焦段将近扩大了1.5倍，从而使所拍摄的风景场面左右范围大大加宽。
拍摄人物最佳焦段是85mm。以35mm规格标准来说，拍摄人物基本以85mm焦距为标准来选择镜头。85mm焦段所拍的人像基本接近中画幅照相机所拍的画面效果，不仅远近感合适，而且人物脸部显得非常自然，照相机与被摄人物之间的距离基本也能保持在平时说话的距离。85mm焦段还能很好地虚化背景突出人物。为获得良好的虚化效果，宜选择最大光圈大的镜头。85mm焦段在数码单反上约是135mm，虽然所拍画面远近感显得稍微弱了一点，但基本无大碍，所以拍摄人物镜头的焦距起码要在85mm左右。
拍花卉对传统单反来说有一款100mm微距镜头就足够了。100mm微距镜头可等倍摄影，能把花朵拍得很大，但是，当等倍摄影或接近等倍摄影时，由于焦距长景深浅，容易产生抖动，所以拍摄时要考虑防抖措施。从这一点来看，50mm微距镜头用在数码单反上更容易使用。
二、最大光圈
最大光圈的真正价值表现在提高弱光情况下的进光量，从而达到最佳曝光组合。拍摄风景一般不太要求镜头的虚化能力，另外，除特别暗的场所外一般也不太苛求镜头口径。但是，当70－200mm变焦镜头加装2倍增距镜而使望远焦段变成400mm并用AF自动聚焦时，最好选择最大光圈是F2.8的镜头。大光圈有利于在较暗条件下准确聚焦。用大口径镜头拍摄人物即便在光线较弱的地方也能手持机利用自然光拍摄。另外，最大光圈大的镜头能带来较快的快门速度，所以体育摄影也需要大口径镜头。
要求镜头光圈大的另一个理由是能自由自在地虚化背景，而且保证虚化品质。最大光圈F1.4的镜头当光圈缩小到F2时，无论是成像品质还是对背景的虚化品质都要强于最大光圈是F2的镜头。所以说，大口径镜头缩小一档光圈具有相当大的价值，任何摄影者都要善于利用镜头这一特性。
三、近摄能力
镜头的近摄能力是仅次于焦距、最大光圈的另一个选择重点。这一点无论是对广角镜头、标准镜头还是望远镜头都一样。那么，近摄能力到底多大才算合适呢？首先说拍摄风景用的广角镜头，近摄能力对广角镜头来说几乎没什么关系，但是当拍摄以广阔风景为背景的花卉景色时，常常要把花卉拍得大一点，在类似情况下广角镜头的近摄能力就显得很重要。现有的50mm标准镜头近摄能力都在45cm左右，基本满足使用。但是，大口径标准镜头在使用最短摄影距离时，由于镜头伸出，往往存在较大像差，从而引起画质低下，购买和使用时对这一点要有思想准备。
望远镜头如果用于拍摄风景的话，对近摄能力也没有什么太大要求。但是，如果用于拍摄人物或花卉等，镜头的近摄能力则非常重要。
四、表现力
选择镜头时很多人首先注意的是这款镜头的成像锐度如何。照片的用途决定了需要什么样锐度的镜头。高价优质镜头主要供专业摄影师使用，如果只是一般摄影，就没必要花很多钱购买高价优质镜头。另外，镜头的成像锐度还和光圈大小有直接关系，当一款镜头从最大光圈缩小一两档之后成像锐度会大幅度提高。
畸变是由镜头光学性能引起的一种光学现象，每款镜头都不可能不存在畸变，厂家在生产镜头时都对畸变进行了修正，力求把畸变控制在最低程度。一般来说镜头畸变主要有三种：变焦镜头广角端容易产生的桶型畸变、望远端容易出现的枕型畸变和对广角端桶型畸变进行修正后所产生的斗笠型畸变。就目前的镜头现状来说，最突出的问题是广角端的桶型畸变，选购时要尽可能选择桶型畸变小的款式。摄影上的虚化超出了人眼的能力范围，所以引起人们的极大兴趣。虚化本身存在一个品质问题，有干净和污浊的差别。对背景虚化得漂亮，图像显得柔和；虚化得污浊，光线就会向画面四角分散，而且虚化的部分不是呈美丽的圆形，严重的则形成双重虚化状态。理想的镜头，光线会均匀分散，形成非常自然的虚化状态。
镜头对背景的虚化能力还和镜头口径有关系。很多镜头从最大光圈缩小一两档后图像立刻变得锐利，但虚化能力相对降低。理想的镜头用最大光圈拍的图像也很锐利，而且虚化效果也很好。
逆光摄影时由于强烈的阳光或其他强光源在镜面反复反射会在画面上形成光晕和耀斑。形成光晕和耀斑的这一小部分光线不仅不会在画面上成像，而且还会在镜内形成乱反射而降低画质。为防止这种现象，逆光摄影时必须使用遮光罩。优秀的镜头在生产制造过程中采取了彻底防止光晕和耀斑的工艺，即便在逆光拍摄时反差也很好。
选择镜头第一个要注意的是镜头的焦距，焦距实际上就是视角问题，焦距不同视角也不同。另外用户自己要明确，我购买镜头的主要目的是什么？是为拍风景还是拍人物等等。众所周知，拍风景宜用广角镜头，而拍人物则宜用望远镜头，所以首先要根据摄影目的来决定自己所要选购的镜头焦距。
拍摄风景最佳焦段是广角焦段24mm、望远焦段200mm（均以35mm规格为标准，下同）。当标准变焦镜头广角焦段从28mm进化到24mm后视角变大，可收纳的景物范围大大拓宽。一般来说拍摄风景对镜头最大光圈要求不太高。如果主要是拍风景的话，选择变焦镜头时广角焦段是24mm基本就够用了。至于望远焦段，起码得是200mm，如果望远焦段是300mm或400mm就更理想了，自由度会大大提高。传统变焦镜头的望远焦段多是300mm，用在数码单反上就是450mm，焦距扩大了1.5倍，用起来会令人感到更加痛快，这一点正是数码单反的价值所在。现在出品的数码专用超广角镜头的广角焦段一般到12mm，相当于35mm规格的18mm，比起35mm规格的28mm焦段将近扩大了1.5倍，从而使所拍摄的风景场面左右范围大大加宽。
拍摄人物最佳焦段是85mm。以35mm规格标准来说，拍摄人物基本以85mm焦距为标准来选择镜头。85mm焦段所拍的人像基本接近中画幅照相机所拍的画面效果，不仅远近感合适，而且人物脸部显得非常自然，照相机与被摄人物之间的距离基本也能保持在平时说话的距离。85mm焦段还能很好地虚化背景突出人物。为获得良好的虚化效果，宜选择最大光圈大的镜头。85mm焦段在数码单反上约是135mm，虽然所拍画面远近感显得稍微弱了一点，但基本无大碍，所以拍摄人物镜头的焦距起码要在85mm左右。
拍花卉对传统单反来说有一款100mm微距镜头就足够了。100mm微距镜头可等倍摄影，能把花朵拍得很大，但是，当等倍摄影或接近等倍摄影时，由于焦距长景深浅，容易产生抖动，所以拍摄时要考虑防抖措施。从这一点来看，50mm微距镜头用在数码单反上更容易使用。
二、最大光圈
最大光圈的真正价值表现在提高弱光情况下的进光量，从而达到最佳曝光组合。拍摄风景一般不太要求镜头的虚化能力，另外，除特别暗的场所外一般也不太苛求镜头口径。但是，当70－200mm变焦镜头加装2倍增距镜而使望远焦段变成400mm并用AF自动聚焦时，最好选择最大光圈是F2.8的镜头。大光圈有利于在较暗条件下准确聚焦。用大口径镜头拍摄人物即便在光线较弱的地方也能手持机利用自然光拍摄。另外，最大光圈大的镜头能带来较快的快门速度，所以体育摄影也需要大口径镜头。
要求镜头光圈大的另一个理由是能自由自在地虚化背景，而且保证虚化品质。最大光圈F1.4的镜头当光圈缩小到F2时，无论是成像品质还是对背景的虚化品质都要强于最大光圈是F2的镜头。所以说，大口径镜头缩小一档光圈具有相当大的价值，任何摄影者都要善于利用镜头这一特性。
三、近摄能力
镜头的近摄能力是仅次于焦距、最大光圈的另一个选择重点。这一点无论是对广角镜头、标准镜头还是望远镜头都一样。那么，近摄能力到底多大才算合适呢？首先说拍摄风景用的广角镜头，近摄能力对广角镜头来说几乎没什么关系，但是当拍摄以广阔风景为背景的花卉景色时，常常要把花卉拍得大一点，在类似情况下广角镜头的近摄能力就显得很重要。现有的50mm标准镜头近摄能力都在45cm左右，基本满足使用。但是，大口径标准镜头在使用最短摄影距离时，由于镜头伸出，往往存在较大像差，从而引起画质低下，购买和使用时对这一点要有思想准备。
望远镜头如果用于拍摄风景的话，对近摄能力也没有什么太大要求。但是，如果用于拍摄人物或花卉等，镜头的近摄能力则非常重要。
四、表现力
选择镜头时很多人首先注意的是这款镜头的成像锐度如何。照片的用途决定了需要什么样锐度的镜头。高价优质镜头主要供专业摄影师使用，如果只是一般摄影，就没必要花很多钱购买高价优质镜头。另外，镜头的成像锐度还和光圈大小有直接关系，当一款镜头从最大光圈缩小一两档之后成像锐度会大幅度提高。
畸变是由镜头光学性能引起的一种光学现象，每款镜头都不可能不存在畸变，厂家在生产镜头时都对畸变进行了修正，力求把畸变控制在最低程度。一般来说镜头畸变主要有三种：变焦镜头广角端容易产生的桶型畸变、望远端容易出现的枕型畸变和对广角端桶型畸变进行修正后所产生的斗笠型畸变。就目前的镜头现状来说，最突出的问题是广角端的桶型畸变，选购时要尽可能选择桶型畸变小的款式。摄影上的虚化超出了人眼的能力范围，所以引起人们的极大兴趣。虚化本身存在一个品质问题，有干净和污浊的差别。对背景虚化得漂亮，图像显得柔和；虚化得污浊，光线就会向画面四角分散，而且虚化的部分不是呈美丽的圆形，严重的则形成双重虚化状态。理想的镜头，光线会均匀分散，形成非常自然的虚化状态。
镜头对背景的虚化能力还和镜头口径有关系。很多镜头从最大光圈缩小一两档后图像立刻变得锐利，但虚化能力相对降低。理想的镜头用最大光圈拍的图像也很锐利，而且虚化效果也很好。
逆光摄影时由于强烈的阳光或其他强光源在镜面反复反射会在画面上形成光晕和耀斑。形成光晕和耀斑的这一小部分光线不仅不会在画面上成像，而且还会在镜内形成乱反射而降低画质。为防止这种现象，逆光摄影时必须使用遮光罩。优秀的镜头在生产制造过程中采取了彻底防止光晕和耀斑的工艺，即便在逆光拍摄时反差也很好。
2007年4月4日星期三
订阅：
博文 (Atom)