外刊IT评论今天抽风，发了很久以前的一篇博文的译文出来：《为什么我们不要.NET程序员》。本文一发，各种口水接踵而至。这篇文章实际上是《CEO Friday: Why we don’t hire .NET programmers》的译文，原文作者在发文后的两天的时间里不断的根据读者反馈对文章进行了更新和补充。但是遗憾的是外刊IT评论却未能翻译完整（不，不，你们不要指望我会翻译剩下的部分，我对此毫无兴趣。），这使得这篇很有闪光点的文章立刻变成了“孰优孰劣”的口水文章了。

看看中文翻译后的评论吧：

有一种人，自己写不出东西，就怪能写出东西的人使用的工具太先进

弱智文章

SB文章，还以为有什么高深的见解，完全是个自以为是的家伙。至多不过是了解了.net之外某一些东西，对自己完全不了解的东西大放厥词还放出优越感来了。

俺作为一名.NET程序员，鉴定结果为，“此文纯属标题党”，一笑而过~~~

我对留下这些评论的程序员感到悲哀……

我们的团队也有着大量的.NET工程师，我每天与他们共处。他们中间有聪明的、优秀的、稳重的工程师；也有躁动的、浮夸的、随意的编码人员。他们能够产生符合设计规范和要求的代码和系统；也会在不经意之间向系统引入致命 bug 而导致生产环境的崩溃。他们其实与依赖其他技术架构的程序员并无多大的不同。

早上，我看到那篇中文翻译的时候，在公司的讨论组里向大家分享了译文和原文。特别提示了，重点看看原文后面的评论。发出去后，我本以为会有人回应支持或者反对。但是没有任何一个人对那些内容进行赞扬或者批评。后来，一个比较了解我的同事私下跟我说“估计一大部分人心里不是滋味”，“一下看到标题，还有你的身份”。好吧，可能许多人心里十分不悦，但是碍于我的“身份”不便表露？我毫不介意的跟大家分享一下，我在国家正式的定义中的身份是“群众”。

我不知道会有多少团队的成员看到本文，我也无从知道他们真实的想法。不过，我可以谈谈什么样的.NET程序员是我们需要.的。

当然为了避免在我的博客上有人指责我由于“根本不了解.NET技术，也不懂windows平台，没有资格来说三道四”。我简要介绍一下我对windows平台和.NET的了解情况。

跟大部分人一样，我对计算机和IT的认识是从windows开始的。win32.hlp 这个帮助文件我想大部分年轻的.NET程序员从来没看过，甚至从来没听过。COM/COM+对于.NET平台就像战国时代的二轮马车一样遥远。PE文件结构就是放在博物馆里的竹简一般，除了历史学家会感兴趣之外毫无用处……我能举的例子还有很多，而这些在我被开源和 Linux 这个魔鬼抓去之前，是每日在学习和探索的东西。哦，忘记说了，.NET 我也不算是毫无认知。至少，在有史可查的范围内，我开源了国内第一个用C#编写的针对性SQL Injection自动化注入工具，如果没记错，那是01还是02年左右的时间。好吧，现在我是否有资格来跟大家探讨这个事情了呢？

事情还是从如何做出一个1.7盎司的汉堡说起……

作为一个.NET程序员，或者特指正在进行互联网开发的.NET程序员，你是否知道我们面对的不仅仅是1.6盎司、1.7盎司的汉堡这么简单的事情？你是否知道互联网这场盛宴不仅仅是做一两个汉堡这么简单？思考的方式有许多种，你是否陷入了做汉堡需要在哪里获得合适的面包、肉饼、洗好的蔬菜、酱料的迷题中，而忘记了手边就有面粉、烤炉，冰箱里有冷藏的鲜肉（你看，已经无需自己杀猪宰牛了），放在窗台的蔬菜上面的泥土和青虫说明菜叶相当的新鲜。

换句话说：你们是否陷入过疯狂的在.NET库中寻找一个合适的类，而忘记去看看开源社区或者第三方是否有提供更好的服务？是否执意要在微软提供的架构体系下实现一些特别的需求，其实那些需求只要一些跳出框架的小小的技巧？是否在看到业内的某些关于技术创新的一句话新闻时，就在心中暗想“这有什么先进的，.NET早有了”，而没有深入的研究为什么这一创新能够成为业内的新闻？

当然，如果对于这些你都有自己可以解释的答案，那么你或许是我们所需要的那种.NET程序员！

如果：你不但能够使用服务器端控件，还能说出其封装的底层原理；不但能够在IIS里建立应用，还能弄明白从客户在浏览器输入你的应用的地址，到他得到满意的结果，这中间每个环节隐含的细节；不但会用WCF来实现功能，也清晰的理解其中的缘由，尤其的，清晰的了解SOA应用于互联网的利弊；不但会在MSDN中查询疑难问题，也会在Google中参考出现在Mono中的类似的解决办法。

那么你应该是我们所需要的那种.NET程序员！

当然，更为优秀的，是那些能够在.NET框架下开发，却从不自称为.NET程序员的家伙们。他们不会将自己限定在某种技术、某种平台；他们热爱技术，热爱生活；他们有着像猫一样的好奇心，即便是这好奇心可能杀死他们也从不畏惧，他们同样有九条命；他们乐于钻研.NET技术，但是也会吸取其他平台的精华……

对于这样的人，我知道是可遇不可求的……

.NET、JAVA、PHP、Python……这些技术难道就没有一点贯通的地方？难道我们在自我介绍的时候不能换个说法：

我，是程序员，在现在这个阶段我对.NET的使用积累的经验更多一些。

是的，我正是这个意思，程序员可以有各种标签，但是别让标签左右了工程师的灵魂。做技术的主人还是奴隶，只是个人的选择而已。

这或许能够阐述我们要什么样的.NET程序员了吧？

我们需要的是熟悉.NET的程序员，我们真得不要“.NET程序员”。

我从来都不是 SOAP 的拥护着。甚至，我对 xml 都会有一种天生的恐惧。别问我为啥，我也不知道。性情如此吧。
这个故事是我看过的最搞笑，也最命中 SOAP 的要害的段子。看完之后，我突然明白我为啥不那么喜欢 SOAP、WSDL、UDDI之类的了。

翻译至此，大家一起乐乐。

原文在此：http://harmful.cat-v.org/software/xml/soap/simple

———-翻译分割线———-

S意味着Simple

Pete Lacey 编撰

在 Burton 团体的应用平台服务组内，支持 REST 的人和支持 SOAP 的人已经进行了很久的论战。在大多数情况下这只是外部论战的一个缩影。在最近的一次交锋中，当讨论到 SOAP 和 web 服务的复杂性时，SOAP 的一方这样说到“在之前的 WS 情形下，SOAP 确实是简单的。这也就是 S 所代表的东西。”

那么现在是历史课时间。这是 2000 年，一个倍受折磨的开发者遇到了一个问题……

开发者：好吧，我的老板这个周末正在打高尔夫，而现在我必须“括起，闭合”这个 SOAP 驱动的企业，但是我不知道 SOAP 是什么。你们能帮助我吗，SOAP 达人？

SOAP 达人：没问题。首先，SOAP 表示 Simple Object Access Protocol（简单对象访问协议）。

开：那么它简单吗？

S达：就像星期天一样简单，我的朋友。

开：太好了，跟我讲讲。

S达: 那么，就像它的名字说的那样，SOAP 用于访问远程对象。

开：就像 CORBA？

S达：跟 CORBA 像极了，只是更简单。为了代替那些不能穿过防火墙的复杂的传输协议，我们使用 HTTP。同时使用 XML 来代替二进制消息格式。

开：我很有兴趣。给我展示一下它是如何工作的。

S达：没问题。首先是 SOAP 封装。它非常简单。只是由头部和内容组成的 XML 文档。而在内容里可以构造你的 RPC 调用。

开：那么这些全部都是关于 RPC 的？

S达：当然。就像我说过的，你通过在内容中设定方法名和其参数来构造 RPC。方法名是外部元素，而每个子元素作为参数。而所有的参数可以由格式说明书第 5 章定义的类型来定义。

开：（阅读了第 5 章）好吧，这并不太糟。

S达：现在，当你的服务部署了以后，你定义这个端点。

开：端点？

S达：端点，服务的地址。你 POST SOAP 封装到端点的 URL。

开：那么如果我 GET 端点的 URL 会发生什么？

S达：不知道。GET 的使用是没有定义的。

开：呃。那么如果我将服务移到不同的端点会发生什么？我会收到 301 返回吗？

S达：不。SOAP 并不使用 HTTP 返回码。

开：那么，当你说 SOAP 使用 HTTP，就是说 SOAP 通过 HTTP 隧道传出。

S达：好吧，‘隧道’是个丑陋的词汇。我们更喜欢说 SOAP 是传输层透明的。

开：但是 HTTP 不是传输层的。它是应用层协议。不管怎么样，SOAP 支持其他什么“传输层”？

S达：好吧，官方来说没有。不过理论上支持任何方法。而有许多平台已经支持 JMS、FTP 和 SMTP。

开：有任何人实际在使用其他这些传输层吗？

S达：唔，不。不过关键是你可以这么做。

开: 当然。SOAPAction HTTP 头又如何，它代表什么？

S达：诚实来说，没有人真正确定。

开：还有这些‘actor’和‘mustUnderstand’属性，有人使用吗？

S达：不。这些没准备好。忽略它们吧。

开：好的，让我浏览一下。

（时间飞逝……）

开：好吧，这个基本上能够工作起来了，不过仅仅是一个点调用一个 SOAP 栈。同时，我不能说我喜欢这个远程过程调用和序列化对象的主意。

S达：远程过程调用！序列化对象！你从哪里得到的印象说 SOAP 是关于 RPC 的？SOAP 全部是关于基于文档的消息传递，我的朋友。

开：但是你刚才说——

S达：忘掉我说过的吧。从这里开始我们将围绕粗粒度消息——你喜欢那个名词“粗粒度”吗？消息匹配一个 XML Schema。我们将新的叫做 Document/Literal 模式，而旧的是 RPC/Encoded 模式。

开：XML Schema？

S达：哦，如今这个很流行。下一个爆发。看看吧。

开：（阅读了 XML Schema 说明书）我的天啊！亚历山大大帝也不能弄明白这个。

S达：别担心。你的工具会为你创建 schema。真的，全部都是关于工具化的。

开：那么这些工具会如何做呢？

S达：好吧，它们会反射你的代码（如果可能）并且自动生成一个兼容的 schema。

开：对我的代码进行反射？我之前认为它是关于文档的，而不是序列化对象。

S达：你没听我说吗？这全部都是工具的工作。不管怎么样，我们并没有期望你能够手写 XML Schema 和 WSDL。 除此之外，这都是底层建筑。你无需关注它。

开：哇哦，等等，那个词是什么？胃死兜？

S达：哦，我没有提过 WSDL？W-S-D-L。Web Services Description Language（Web 服务描述语言）。它是关于你如何定义数据类型、参数列表、操作名称、传输绑定和端点 URI 的，这样客户端开发者就可一访问你的服务。了解一下吧。

开：（阅读 WSDL 说明书）我相信编写这个的那个家伙已经被干掉了。这个甚至在内部都不一致。而且 HTTP GET 绑定做了什么。我想 GET 并没有定义。

S达：别担心那个。没人用那个。无论如何，你的工具会生成 WSDL，而在 WSDL 里会有 schema。

开：但是没有其他办法绕过去吗？难道不应该是我先设计好约束条件，然后生成代码吗？

S达: 好吧，当然，我想这听起来在原则上是对的。但这并不容易做到，而几乎没有 SOAP 栈支持先进行 WSDL 的开发。只让工具来承担这些好了。

开：还有一个问题。如果现在传递一个 XML Schema 兼容的消息，在哪可以指定操作名称？

S达：好吧，还记得 SOAPAction HTTP 头部吗？大多数人将其放到了这里。

开：大多数人？

S达：好吧，这个新模式实际上还没有在任何地方使用。

开：我同时注意到你们整个行业都建立在模棱两可之上的，有时有错误，还有一些定义的说明不是那么标准。事实上，SOAP 和 WSDL 说明书都还只是 W3C 记录，连工作草案都算不上。

S达：我们正在为此努力。

开：这能给我提供我之前所承诺过的互通性吗？

S达：当然。

开：我尝试一下。

（时间飞逝……）

开：现在变得丑陋了。我搭档的工具不能处理我的工具生成的 WSDL。不仅如此，它生成的 schema 是令人费解而且不可重用的。并且看起来没有工具认同如何处理 SOAPAction 头部是最佳的。

S达：听到这个真遗憾，伙计。从好的地方着想，没人再用 Doc/Lit 模式了。为了让无依赖传输回来，现在我们全都使用了 wrapped-doc/lit。这听起来很酷吧：wrapped-doc/lit？

开：这是什么？

S达：好吧，这和 Doc/Lit 类似，只是你取得整个消息并且将其包裹到有着相同名字的元素中作为操作。这样操作名称就回到消息中它应该在的地方。

开：好的，关于这些的说明在哪里？

S达：哦，这个没有说明。只是微软这么做而已。看起来是个不错的主意，所以现在所有酷毙了的小子们都这么做。然而，有一个关于此的新东西。我想你可能会喜欢它。称为 Web 服务互通性小组，或者叫做 WS-I。他们要做的工作就是从 SOAP 和 WSDL 说明书中移除那些模凌两可的东西。我知道你相当中意说明书。

开：所以，换句话说，这个说明书糟糕到你们需要一个标准化实体来对标准进行标准化。天啊。好吧，这能解决我的互通性问题吗？

S达：哦，当然。只要你使用 WS-I 兼容的 SOAP 栈，避免使用 8/10ths 的 XML Schema，不要使用任何不寻常的数据类型，并且不要按照 WebSphere 和 Apache Axis 来工作。

开：那么就使用 wrapped-doc/lit 来解释它？

S达：呃，不。不过也没问题。你的工具明白它（有些心虚）。大多数情况下，不管怎么说。

开：让我总结一下。SOAP 的定义总是在不断变化，不管怎么样 SOAP 是简单的，并且不再意味着对象访问——虽然这是工具仍然在做的事情。

S达：差不多是这样，但是我们总是带领着你在这条路上前进。我们已经抨击过 SOAP 缩写的含义了。

开：真的！那么它现在到底什么意思啊？

S达：什么意思都没有。

开： （眨巴着大眼睛）

S达：让我告诉你关于 UDDI 吧。

———-翻译分割线———-

现在知道 REST 和 json 的魅力了吧？那些坚持使用 SOAP 的同学们，得有一种什么样的探索精神啊！

原文来自：http://www.wired.com/wiredenterprise/2011/10/thedennisritchieeffect/。

Jobs 和 dmr 老爹前后离开，让很多人不能不将其放在一起谈论。无论如何，他们都是伟大的人。有的时候在很短的时间里，这个世界同时失去两个伟大的人，是一件很难言语的事情。

“If I have seen further it is only by standing on the shoulders of giants.”- Isaac Newton.

仅以此向 dmr 老爹致敬。

———————翻译分割线———————

Dennis Ritchie：Steve Jobs 的巨人肩膀

Cade Metz撰写 2011十月13日 7:14 pm

对 Dennis Ritchie 的悼念完全不能同 Steve Jobs 去世后在 Web 上纷飞的如潮水般的赞美相提并论。但是他们确实如此。

甚至更夸张一些。

“当 Steve Jobs 上周去世后，产生了声势浩大的哀悼活动，而这是另人感动和恰当的。虽然 Dennis 有着更大的成就，但是公众甚至不知道他是谁。”另一个程序界的传奇，现在是一名 Google 人，在著名的贝尔实验室工作的20年里同 Ritchie 每日穿过同一个门廊的 Rob Pike 这样说到。

在周三的晚上，Pike 通过 Google+ 上的一篇留言公布了 Ritchie 与疾病进行了长久的斗争之后，在他新泽西的家中病逝的消息，尽管来自铁杆技术人的响应非常强烈，但整体上来自 web 的悼念与 Ritchie 对现代社会广泛的影响并不匹配。Dennis Ritchie 是 C 语言之父，并且协同贝尔实验室科学家 Ken Thompson 一起，使用 C 构建了 UNIX，基于这个操作系统的构建是如此之多——包括 Steve Jobs 建立的 Apple 帝国。

“在 web 上几乎所有的事情都用到了这两个东西：C 和 UNIX，”Pike 告诉网友。“浏览器是用 C 编写的。UNIX 内核——几乎整个互联网都运行在其上——也是 C 编写的。web 服务器是 C 编写的，而如果不是用 C 编写的话，那就是用 Java 或者 C++，这些是 C 的衍生，或者 Python 或 Ruby，这些是用 C 实现的。以及所有运行这些程序的网络硬件，我几乎都可以断定是用 C 编写的。”

“现代信息经济是构建在 Dennis 之前所做的工作上，这一点也不夸张。”

他补充到，甚至 Windows 曾经也是用 C 编写的，以及 UNIX 的后继者包括 Apple 的桌面操作系统 Mac OS X，和运行在 iPhone 和 iPad 上的 iOS。“Jobs 是看得见的王，而 Ritchie 是无法看到的万王之王，”MIT 电器工程和计算机科学教授，计算机科学与人工智能实验室成员，Martin Rinard 这样说到。

“Jobs 的天赋在于他构建了那些人们真正喜欢使用的产品，因为他有品味并且可以让事情变得引人注目。Ritchie 构建的东西是技术方面的，可以用于构建核心的基础设施，人们几乎无法接触到，但是每天都在使用的东西。”

从 B 到 C

Dennis Ritchie 构建了 C，因为他和 Ken Thompson 需要一个更好的方法来构建 UNIX。最初的 UNIX 内核是用汇编语言编写的，但是很快他们决定他们需要一个“高级”语言，某些对数据来说可以提供更多的控制能力并且跨操作系统的东西。在整个1970年，他们尝试构建了第二代 Fortran，但是这个并不十分适合，然后 Ritchie 提议基于 Thompson 创造的叫做 B 的语言开发一个新的语言。

不论你相信哪个版本的传说，B 的命名来自 Thompson 的妻子 Bonnie 或者一个由剑桥在六十年代中期开发的语言 BCPL。在任何情况下，从 B 产生了 C。

B 是一种解释型语言——也就意味着它是运行在 CPU 上的软件的一种中间形态——但是 C 是编译型语言。它被翻译为机器码，然后这些机器码直接运行于 CPU 上。不过在那个时候，C 被认为是一个高级语言。它可以为 Ritchie 和 Thompson 提供所需的灵活性，与此同时它很快。

C 语言的第一个版本与现在我们知道的版本并不完全一样——不过还是有些类似的C 语言的第一个版本和我们今天知道的并没有多少不同——尽管它当时还不成熟（thx @ye_hq）。它提供了完整的数据结构和“类型”用于定义变量，而这就是 Ritchie 和 Thompson 用于构建新的 UNIX 内核所使用的。“他们构建了 C 来编写程序，”在 10 年后加入贝尔实验室的 Pike 说到。“而他们要写的程序就是 UNIX 内核。”

Ritchie 的一个玩笑是 C 有着“汇编语言的力量和汇编语言的便利。”换句话说，他承认 C 不是一个绚丽夺目的发明，它仍然非常贴近硬件在运行。今天，它被认为是一个低级语言，而不是高级的。 然而 Ritchie 的玩笑对于这个新语言并不公平。通过提供真正的数据结构，它操作的层面已经足够高了。

“当你编写一个大程序的时候——而 UNIX 正是这种类型——就必须管理各种不同组件之间的相互影响：所有的用户，文件系统，磁盘，程序执行，以及使其能够有效的管理，你就需要能够对正在处理的信息有一个良好的表达。也就是我们所说的数据结构。”Pike 说到。

“在没有数据结构的情况下编写内核，并且使其向 UNIX 一样的保持一致和优雅是一个相当相当难的挑战。需要有一个方法将数据成组的放在一起，而在 Fortran 里是没有办法做到的。”

就当时而言，这样编写操作系统是非同寻常的，而这也使得 Ritchie 和 Thompson 最终设想移植操作系统到其他平台，他们在七十年代末期进行了这个工作。“这开启了 UNIX 运行在任何地方的水闸，”Pike 说到。“这全部都是 C 使其成为现实的。”

Apple，Microsoft，和其超越者

与此同时，C 在它自己的道路上越走越远，从贝尔实验室到世界上其他大学，以及 Microsoft，在二十世纪80年代爆发的软件公司。“使用 C 语言进行开发是一个巨大的进步，且和时宜… C 提供了正确的平衡性，使得可以在更高层面编写并更加产品化，但是当需要的时候，仍然可以控制到底如何处理，”NVIDIA 首席科学家和斯坦福的贝尔工程教授 Bill Dally 这样说到。“（它）加快了程序开发的步伐至少数十年。”

就像 Pike 指出的，Richie 在 C 中构建的数据结构甚至影响产生了现代语言如 C++ 和 Java 所使用的面向对象范型。

革命开始于 1973 年，Ritchie 发表了对语言的研究的论文，五年之后，他和同事 Brian Kernighan 发布了决定性的 C 书籍：C 程序设计语言。Kernighan 编写了这个语言初步的一些指南，然后同时他“扭着 Dennis 的胳膊”一起编写了一本书。

Pike 在多伦多大学就读的时候阅读了这本书，在有一天生病回家的下午拿起了它。“这个参考手册与其他手册相比是清晰和可读的典范。它无疑是优秀的。”他说。“我在病床上阅读了它，而它使我忘记了正在生病。”（译注：如果我说我是靠这本书过的 CET4 会不会有人相信？但是这是真的，它确实燃起了我对学习英语的渴望……）

就像许多大学生一样，Pike 已经在使用这个语言了。由于贝尔实验室捐赠了 UNIX 的代码，使得它风靡于大学校园。特别要提到的是，操作系统开始进入现代开源运动中了。 Pike 在讲述的时候，没有也无法夸大 Ritchie 的工作的影响力，因此即使 Ritchie 在 1983 年获得图灵奖，并且在 1998 年获得美国国家技术奖， 他得到的赞誉仍然无法匹及他的贡献。

如同 Kernighan 和 Pike 说得那样，Ritchie 本人是非同寻常的孤僻。“我与他在同一个屋檐下一起工作了超过 20 年，而我感觉我并不全部了解他，”Pike 这样说。但是这并不能解释为他行事低调。Steve Jobs 是一个孤僻的人，但是他在隐私方面的坚持成为了公众对他个人生活探索的动力。

Ritchie 在与众不同的时间生活，并且在与众不同的环境工作，在这点上他超过了任何人，例如 Jobs。他没有获得应得的这绝对没错。但是那些真正在意的人，都能明白他留下的跨时代的标志。“在牛顿关于站在巨人的肩膀上有一个标准，”Kernighan 说到，“我们都站在 Dennis 的肩膀上。”

附加的内容由 Jon Stokes 撰写。

在 Google Plus 上看到这个消息，淡淡的，有一些悲伤。上帝难道要学习C语言，并将天堂的系统换成UNIX的了么？

本想写点什么纪念一下，但是突然觉得对于这位神来说任何文字都显得苍白无力。

虽然他说“I am not now, nor have I ever been, a member of the demigodic party.”但真的神终究是真的神。

R.I.P. dmr! We will miss you, Dennis Ritchie.

ifttt 是 IfThisThenThat 的缩写，中文大体上说就是“如果这个，就那个”。说白了，就是一个消息分发网络，将用户所拥有的若干网上的资源相互整合。有点去中心化的节点通讯通道的味道，又有点SOA的消息总线的味道。

前天在 ifttt 上填写了邮箱申请邀请测试，昨天居然就收到了邀请。于是顺利注册之……现在又有了 4 个邀请，有谁需要的跟 comments 留邮箱吧。

2011-7-7：诸位不用再留邮箱了，邀请码我真得是一个都没有了。

最近发现，Android 翻墙版 Opera越来越难以翻墙了。越来越卡，越来越慢……有时甚至完全打不开。于是乎，得寻其他途径。VPN 我是不想用的，一用，整机翻墙，有时用起来反而还慢。

还好，发现 Connectbot 这个利器。Connectbot 是 Google Code 上的开源项目，在 Android 市场上的原文介绍如下：

ConnectBot is a powerful open-source Secure Shell (SSH) client. It can manage simultaneous SSH sessions, create secure tunnels, and copy/paste between other applications.

This client allows you to connect to Secure Shell servers that typically run on UNIX-based servers.

要知道，SSH Tunneling 是我在桌面翻墙的至爱，Firefox 配合 FoxyProxy 可以选择性翻墙，很是轻松。

使用 Connectbot 翻墙很容易，只需下面四步：

第一步，打开 Connectbot，在下方选框中选择 ssh 方式，并在其后的文本框中输入“用户名@主机名:端口”。如 root@yoursitehere.com:22。输入后，点“完成”，即开始连接 ssh。

第二步，连接过程跟普通ssh过程一致。正常连接，并登录后，点击 menu 按钮，调出菜单。选择“端口转发”。

第三步，根据需要选择端口转发的类型和方式。我习惯上会使用动态的 socket 转发。这其实跟普通的 ssh tunneling 没啥区别。

第四步，设置好了以后，在“设置”里选择“无线和网络”，在“Proxy settings”里设置主机名为 127.0.0.1，端口为刚才设置的源端口即可。

然后，你就可以随意“小鸟”、“脸谱”了。

今天在看《创业家》11年第2期的时候，看到“警钟为谁长鸣”一文，这是熊晓鸽先生为吉姆·柯林斯的新书《再造卓越》（《How The Mighty Fall》）撰写的推荐语。文中提到『王安博士』。

在新浪对王安博士的介绍中写道：

作为华人电脑之王，王安的辉煌与悲剧色彩是成正比的。这位从哈佛下海的华人，于1951年创办王安实验室，八十年代达到事业顶峰，在全球计算机和办公电脑设备领域领衔群雄。个人财富一度达到20亿美元，为全球第五富翁及华人首富。1985年，王安公司首次出现亏损，其后持续下滑。1990年，王安因癌症病逝，此时帝国已摇摇欲坠。1992年，公司宣布破产保护。1998年，终被人购并。因为战略失误，王安也因此与DEC的奥尔森、苹果的乔布斯等成为计算机史中的最大的悲剧英雄之一。

呵，乔大爷东山再起，如日中天。而王安博士却永远的没有了这个机会。正如他的唯一的一本自传的名字是《LESSONS》……

王安博士对于计算机行业的贡献并不只是一个破了产的王安电脑那么简单。从 Wiki 百科上的内容来看，光与他有关的专利就包括了“对数计算装置”、“分布式数据处理系统”、“数据通信系统”、“高密度点阵打印机”、“文档扫描仪定位装置”、“通信终端管理系统”、“手写板”……最有趣的是，王安博士对金山的WPS的普及有莫大的帮助，因为如果没有 WANG 2200 文字处理系统（Word Processor System）可能就不会那么火爆，那么日后的金山WPS……

好了，由衷的敬佩王安博士对计算机产业的贡献，也感叹王安电脑的兴衰。回到我们的主题：为什么是“Core Dump”

Core Dump，有些系统开发经验的人都知道，是内存转储的意思，当然也有人直译为核心转储。但是为什么叫 Core Dump，而不是 Memory Dump 呢？这跟王安博士有莫大的关系，他通过改进了磁芯内存解决了磁芯内存实用问题，否则阿波罗登月的计算机恐怕就要换种内存了。而磁芯内存的英文就是Magnetic Core Memory，内存转储自然就被称作 Core Dump，也正是因为磁芯内存的非易失性，“转储（Dump）”的叫法才有了意义。

就让我们在每一次过底打印（点阵打印）、每一次OCR、每一次 Core Dump 的时候，都向王安博士致敬吧！

PS：突然想起个问题，这些 Pad、触屏手机之类的算不算是手写板的延伸呢？如果算的话，就请诸位再次向王安博士标示由衷的敬意吧！

原文在此：http://torvalds-family.blogspot.com/2011/02/pearls-before-swine.html，觉得内容很好玩，于是就翻译出来了。

Linus 的原文标题是“Pearls Before Swine”，来自圣经中马太福音7章6节中，耶稣给彼德的警告——“也不要把你们的珍珠丢在猪前”。

本想翻译成“对牛弹琴”或“有眼不识泰山”的，但是想了想，还是觉得“九唔搭八”更加贴切一些。关于“九唔搭八”的解释在这里：http://95da8.com/?p=6。毕竟，原文虽然说 Linus 夫妇在派对上见到明星，经常有眼不识泰山，但是我觉得让一个世界顶级 geek 参加一场关于电影、明星、时尚的排队，真得很“九唔搭八”。

————翻译分割线————

九唔搭八

我的生活并不迷人。

我知道接下来的内容会让每个人感到吃惊，由于一般观点认为 Geek 是上层社会的名流，通常直觉认为我们生活在有着摇滚明星以及其他迷人的人的夜间派对中。

并不是这样。

我坐在我的办公室（以前是在地下室，现在是车库上面的房间），通常穿着破烂的睡衣，一整天的读写邮件。为了等待人们报告问题并给出答案，浪费了大量的时间。晚上十点上床，早上七点起床送孩子们去学校。然后重复一切。

所以这并不迷人。当我在实际进行编码的时候（通常是在邮件阅读工具中——经常是告诉人们“像这样做”，而不是编写真正的代码），这是一天中最让人兴奋的时刻。

即便这样，有时我也会尝试高端生活。这个周末，我们被邀请参加奥斯卡前夜派对（感谢 Renée 和 Doug！），我合作的一些企业似乎认为我需要找个晚上出去玩玩。

好吧，我不认为我们可以继续讨论白袜子和凉鞋。

所以，我和我妻子绝对是超出我们的能力范围，而且一个人也不认识。 我们每个星期都会有一个晚上出去约会，也看了一些电影，但是我们不是影迷——我们看的电影并没有什么影响力。所以，当我们去到派对现场时，成打的明星，既不记得名字，也不记得长什么样子。

就像 Tove（译注：Linus 大神的妻子） 说的那样，好消息是这不会有什么真正的损失。没有人知道我们（译注：显然，这些明星都是技术白痴），也没有人在第二天会想起我们。所以我们可以悠闲的在派对里游荡，并且厚颜无耻的问人们“你看起来非常眼熟，你是谁啊？” 我们确实这么做了。通过 Google 图片搜索，有一些人可以猜出是谁，这么做也仅仅是想验证而已（John Cusack 还是 Paul Rudd？）。

每个人似乎都在享受干杯的乐趣。我们打断了 David Spade 同 Natalie Portman 和 Mila Kunis 的聊天 (就像 Tove 说的，我是非常健忘的——这再次为 Geek 世界增添光彩。我告诉她我能认出 Natalie Portman，并且她不可能在现场，你懂的……）而 Tove 也搞砸了，她问了 Warren Beatty 不止一次他的名字，实际上是两次。

这里要提一下我新的好朋友 Jon Hamm 和 DJ。

我们可能不会被再次邀请。但是我们可以向孩子们讲述这些，证明他们的老爸、老妈是很酷的人。

这是典型的“死Coder责任制”和“QA无用论”合体。大家仁者见仁、智者见智吧。个中道理还是得自己参悟啊！

原文在此：http://blogs.forrester.com/mike_gualtieri/11-02-17-want_better_quality_fire_your_qa_team，原作者是Mike Gualtieri，一位应用开发和部署专家。

————翻译分割线————

严肃的说，我近期和一位客户聊天，他咒骂到，当他们去掉QA团队后软件的自量立刻得到改善。他们让软件的开发人员直接承担质量责任，以代替QA对于质量的责任。这看起来有违对于软件质量和开发者一贯的认知：不要相信开发人员，或者借鉴 Ronald Reagan所说，相信但是要验证。

其实这位客户并无懈怠。他们的应用面向金融市场提供了实时的市场数据，而这位客户每年发布超过40款软件。如果某个应用提供的市场数据不可用或发生错误，那么使用它的金融市场将崩溃。信息必须绝对可用和正确。这个应用不能宕掉，也不能发生错误。

为什么这能运作？

这位用户说，能运作的原因是开发者知道他们要100%的为应用负责。如果应用不能工作，开发者不能说“QA没有找出问题”。这里没有QA团队去推卸责任。在应用开发团队这里皮球就停下了。他们最好让一切都正常，否则就要把脑袋当皮球了。

作为英国作家Samuel Johnson幽默的描述，”上了绞刑台的精神最集中（译注：好吧，我不知道这个是不是准确，意思应该没错。原文是：The prospect of being hanged focuses the mind wonderfully.）”。

这个能为你所用吗？

如果应用开发团队对于软件质量负责，这就能运作。糟糕的质量的后果如此严重，以至于应用 团队没有选择，只有在设计、开发，和测试时集中他们的精神。这些年来我开发的多数软件并无QA团队。当你为大型企业开发关键应用做顾问的时候，要么提供更好的质量，要么掉脑袋，得不到报酬。

责任并不够。要想成功，应用开发团队必须建立测试约束，建立测试计划，以及使用测试工具。由于开发者知道代码中哪里是藏尸地，他们可以集中力量针对应用中脆弱的部分。所付出的努力与软件的类型有关。最终的结果将是更好的质量和更快的发布周期。

原文来自：http://quatermain.tumblr.com/post/3328850553/apples-three-laws-of-developers
这让我想起《冰河世纪3》里面的那位神经质长官……

1. A developer may not injure Apple or, through inaction, allow Apple to come to harm.
2. A developer must obey any orders given to it by Apple, except where such orders would conflict with the First Law.
3. A developer must protect its own existence as long as such protection does not conflict with the First or Second Law.

— I. Developer

这里是我的翻译：

1. 作为开发者不可以伤害 Apple，或者面对伤害不作为，而让 Apple 受到损害。
2. 作为开发者必须遵从 Apple 发布的任何指令，除非这些指令违背了第一条军规。
3. 在不违背第一或者第二条军规的前提下，作为开发者必须尽可能的保护自己。

— I. Developer