IDE综合症和攝影
IDE
莫华枫 <[email protected]> reply-to [email protected] to TopLanguage <[email protected]> date Sat, Sep 27, 2008 at 10:53 subject [TopLanguage] {编程}IDE综合症
http://blog.csdn.net/longshanks/archive/2008/09/27/2986548.aspx
前些日子猛然间接到开发POS机的任务。没有完整的IDE，索性就学着用vim，也算是技能锻炼吧。没几天，就看到了两位大牛在blog里展示无鼠标的魅力（这个，这个，这个，和这个，这个，这个，这个）。特别是风云，直接告诉我们不依赖于IDE的方法和好处。令人震撼。从另一个角度来看，不依赖于IDE带来的不光是方便、简洁，以及geeky。更重要的，它将使得我们打下更扎实的基础。而那些离了IDE就活不成的人，总存在着一些缺陷。
- 在开发POS机之前，我正在做web的项目。既然是web，用javascript更加合适。由于行事仓促，没来得及找一个合适的javascript IDE，所以就直接借用vs的编辑器编写js代码。vs IDE的intellisence做的颇为出色。但是这仅限于C#、VB、C++等主要语言。对于javascript（ms叫它JScript），几乎没有任何auto-complete功能。我还比较适应，因为过去在vc5以前没有这类功能。即便vc6，auto-complete也时有时无，至今 vc9依然如此。（拜C++那non-lalr语法所赐，似乎没有希望得到完全的auto-complete了）。但是，我身边的几个程序员则不停地向我抱怨，没有auto-complete太不方便了。一开始，他们甚至有些手足无措。
- 于是，我告诉他们，不要太依赖IDE，特别是auto-complete功能，要学会多看文档...。说完这些话，我开始留意身边程序员的行为。结果发现，他们拥有强烈的，用IDE替代文档的倾向。每当他们需要一个功能，又不知道该用什么函数的时候，便找到相应的对象或类（C#），在后面打上个"."，然后等着。等到成员函数列表显示出来，便在里面搜索，看看有没有符合要求的函数或属性。如果找到一个名字看上去像的，就选中它，看看 intellisence列出的说明。如果有函数的参数不知道，就打上括号，看提示。根据参数类型和参数名猜测参数的含义。
- 这种做法本身并没有什么太大的问题，我自己也经常这么做。但是，根本的差别在于，我一般都用过这些函数或属性，只是时间长了忘记了函数名或参数。 auto-complete起的是助记和辅助的作用。auto-complete原本也应该是这个作用。对于从未用过的，或者不清楚功能的函数或属性，我基本上还是先看文档，了解函数或属性的具体含义和用法后，再使用。但很多在先进的IDE里泡大的程序员们，却并非如此。他们把auto-complete 功能当成了百科全书，反倒是很少看文档。
- 有人会说，既然auto-complete提供了函数的介绍，参数的类型和介绍，对于编程而言已经足够了，没有必要再浪费时间看文档了。但是，这种想法是绝对错误的、危险的，甚至会要命的。对于一个类型、函数、属性、参数而言，文档并非仅仅提供了名称和大致含义。而是提供了完整的说明、注意事项、参数/返回值的详细说明和规约，以及更加重要的异常特性和线程安全性。所有这些都是无法容纳在auto-complete的狭小说明空间里。
有经验的程序员，往往非常关注参数/返回值的规约（契约）、异常特性和线程安全性。这些地方往往是藏污纳垢的地方。对于参数/返回值处理不当，往往引发意想不到的错误。比如一个参数不允许null指针。在通常情况下传入的实参都有效，但在很偶然的情况下，一个null传了进来，于是引发了程序崩溃。如果程序员提前对null作出处理，便可以避免这类问题。有些函数对与null字符串和空字符串的处理是不一样的。比如.net framework中IXPathNavigate的GetAttribute()方法，第二个参数是namespace，如果用null字符串，则不会得到所需的结果；如果用空字符串，则能够得到正确的结果。在复杂程序中这种错误往往非常隐蔽，是最佳bug候选人。
- 异常特性决定了一个函数对于非正常情况的处理方式。很多新手往往忽视异常。实际上，一个函数的异常有时是正常的，比如一个文件不存在的异常抛出时我们可能不认为它是错误，而是一个提示，我们可以据此创建一个文件；而另一些情况下，异常却是错误，比如参数无效。更有甚者，一个异常有时是错误，有时则是正常流程的一部分。这些东西往往需要细心处理，以免在客户面前出洋相。
- 至于并发特性，毋庸置疑是绝对不可忽视的。可以想象，几个线程在一个线程不安全的函数里能制造出多大的混乱。更何况这些混乱很难调试。
- 过度依赖IDE也造成了程序员的"营养不良"。对于程序的调试，他们只知道使用debuger，甚至不知道log也可以用于调试，而且应用范围更广。我曾经问一个C#使用多年的老程序员，.net上有没有log库。他告诉我一个.net内置的，我一看，这不是调试用的log库，而是访问windows系统 log的几个类。他根本就不明白log库是什么东西。
- 至于其他的方面，IDE综合症还有很多症状，我就不多说了。如果细心观察，我们都会发现很多这样的现象，也能发现其中的弊病。
- 客观地讲，IDE是个好东西。但是对于程序员，特别是新手，过度依赖IDE会造成不良的后果。我们永远应该把IDE看作一个辅助的工具，而不是唯一的编程编程平台。而对于一个新手，应当尽可能地减少IDE的使用量。特别在练习的时候，更应当放弃IDE，而更多地锻炼编程时的自主控制能力。
反者道之动，弱者道之用
攝影
莫华枫 <[email protected]> reply-to [email protected] to [email protected] date Sun, Sep 28, 2008 at 09:22 subject [TopLanguage] Re: {编程}IDE综合症
既然扯到了摄影，那么就聊聊摄影吧。:)
可怜的DC
- 假设有一天，你完成了一天的户外摄影，在一家咖啡馆休息。
- 突然发现屋子那头靠窗边的位子上坐着个美人儿，正若有所思地凝神看着窗外，一抹夕阳投射在她脸上，勾勒出美丽的金色剪影。
- "太棒了，"你在想，
- "侧逆光，对比强烈，背景简洁，神态自然。拍下来足够把那帮大小虾米馋死。对了，或许我还可以给她看，说不定还能...。"
- 在发现目标不到一秒钟的时候，你已经在屋子里最阴暗的角落举起了相机。距离远了点，不过没关系，相机上正好装着中长变焦。于是，你随手调到人像档，果断地按下快门。
- 先是两张全身的，紧接着几张半身。最后，最出彩的，是这几张脸部特写。
- 一口气，你拍了20来张，觉得差不多了，足够把每个细节都拍下来了。
然后你就窝进了沙发，乐滋滋地检查刚拍的照片。
- "不好"，你心里咯噔一下。
- 怎么那几张全身的，脸上一片白，五官都不见了。再看半身的，灰毛衣成了黑毛衣，脸侧的金色阳光成了一盏大灯泡。
- 最惨的是那些特写，始终有一只眼睛和半边脸是虚的。
- 你目瞪口呆，不停地在女孩和照片之间扫视。当你再次举起相机准备再做一次尝试的时候，那个女孩突然兴奋起来，朝窗外挥了挥手，然后抓起了身边的提包，蹦蹦跳跳地跑出了咖啡馆——她的男朋友来了。你只能沮丧地看着美人离开了你的射程。
分析
一次绝好的机会，一个绝佳的场景，却被你那蹩脚的摄影技术浪费了。行动彻底失败。
- 为什么会这样呢？让我们回放一下整个狙击过程。
- 首先，请注意场景。你在女孩的前侧方大约10点钟方向，女孩右侧是窗户，室内比较暗。
- 这样，光从户外照入，构成了侧逆光。
此时，整个场景明暗对比强烈，光比很大，差不多会有5-6档（25-26）。
- 再加上投射在脸上的夕阳，最大光比可能在7-8档以上。
实际上这已经超出了大多数民用感光材料的极限（感光材料能够表现的最大的和最小的亮度，称为宽容度）。
- 一般好的黑白胶卷，比如Kodak的TMAX，宽容度有6-7档。
- 彩色胶卷有4-5档。反转片只有不到3档。
- 而现在的数码感光材料，宽容度仅在3档左右。
从这一点来说，DC更难拍。而人眼的宽容度在12档以上。所以尽管你看清了整个场景，包括每一个细节，但相机做不到。特别是你用了DC。
对策
对于这种情况，你只有舍弃一部分细节，保留重要的部分。比如只保留脸部和上身的细节。
- 但是投射在脸上的阳光，尽管不像正午那样强烈，但也已超出了DC的能力。
- 这种情况下，你要么拍下一个白板脸的魔鬼身材，要么拍下一团漆黑中孤零零悬挂着的一张脸。
- 实际上，在这种情况下，根本不要去尝试全身和半身，除非你手里攥着的是哈勃太空望远镜。
- 此时，最好的效果是脸部特写。
- 由于受到来自窗外的充分照明，脸部细节可以容纳在DC的宽容度内。
- 而作为特写，背景细节全部隐藏，只会加强照片的效果。
- 不过，事情还没那么简单。如果就这么拍，会发现整个脸部高光部分非常细致，但中间影调和暗部却是模糊的一坨。
- 这是因为相机的感光材料，无论是DC还是胶片，宽容度是不对称的，一般小于18%中间灰度的宽容度只有1-2档。
- 如果将整个宽容度平均一分为二，便使得暗部会曝光不足。
- 而一般的相机测光系统并没有很好的体现出这个特点。
- 所以，此时比较合理的做法是在相机自动曝光值上增加1档曝光量。
- 更精确的做法是对头部的高光和暗部进行点测光，然后按区域曝光理论换算出曝光量。
- 当然，如果时间不够，有个简便的办法，就是对高光部分点测光，然后加一档半或两档（胶卷的话可以相应地多加些）。
- 而一般的相机测光系统并没有很好的体现出这个特点。
- 最后，还剩下一个问题，为什么只有一只眼睛在焦点上？
- 回想一下，当时距离远，你用了长焦才能拍到特写。
- 但是你却用了人像模式。
- 人像模式实际上就是大光圈。光圈增大，景深变小，从而将背景虚化，突出人物。
- 但是，当你使用150-200的长焦的时候，如果以最大光圈（一般是4.5，高级镜头可以达到2.8）拍摄，那么景深只有2-3厘米。自动对焦往往会对在离你最近的眼睛上，那么另一只眼睛就落在景深之外，模糊了。
- 此时，必须手动光圈（光圈优先自动模式即可），以控制景深。一般须在5.6以上，有时甚至达到8。
- 但光圈小一档，曝光时间就增加一倍。
- 在这样的场景下，为了让女孩的连足够细腻，iso不能超过100，这样的话曝光时间可能达到1/30甚至1/15。
- 除非你有射击运动员的稳定性，否则图像会一脸模糊。必须将相机固定住，搁在桌上，用膝盖支撑，或者使用三脚架。
结论
好了，做好了这些功课，你才能把美人的倩影完美地收入影集。
- 但是，请记住，这些操作都必须在女孩的男朋友到来前的短暂时间内完成，所以平时拍摄的时候最好不断地演练这些要领，以免在激动之余操作失误，贻误战机。
- 不过，请记住一直开着P档，甚至Auto档，人像模式，静物模式...，是永远也练不了这些的。
你瞧，当一次业余摄影师也要牵涉到如此众多的细节，更何况专业的呢？回过头想一想，我们开发软件，使用IDE何尝有不是如此呢？
反馈
创建 by -- ZoomQuiet [2008-09-28 01:36:41]