博客园_止于至善

周鸿袆：从程序员创业谈起

2011-11-21T04:54:00Z

离开雅虎中国后的周鸿袆现在的身份是IDG公司的投资合伙人，手中拿着五亿美金用来做风投的他自然对创业有着说不完的话题。由于周鸿袆出身程序员，也一直是本刊的忠实读者，他希望一方面站在投资商的角度，同时以一种过来人的身份来探讨“程序员创业”这个话题。

一个周五的傍晚，在北京光华路的一个酒吧中，本刊约到周鸿袆进行这次对话。从昌平远道赶来的周鸿袆由于塞车而晚到了半个小时。由于开会讲了一天的话，他的声音有些嘶哑。不过在草草的吃了晚饭后，周鸿袆仍然用其快速的语调表达了自己的观点。

记者：我已经看到您在其它的媒体上接受了一些采访，也谈到了很多关于创业的话题。面对程序员这个群体，讲创业有什么特别的地方呢？

周鸿袆：的确如此，最近由于我的身份，只接受创业方面的话题。关于程序员创业，我之所以愿意谈我的观点，是因为我是程序员出身，也是从小公司做起来的，我自认为对待很多程序员个人包括共享软件作者和一些小网站还是很好的。我希望和他们分享一些经验和体会。

首先，我想说的是聪明人不一定能成功，很多程序员很聪明，但我一看就知道他们不会成功。因为我看到了一些问题，而且现在太多程序员存在很多误解。因此，我希望把我的观点告诉程序员。或许有一些程序员能够清醒，某个人可能因为我的某一句话有了感觉，对他以后的成长产生了帮助，这就足够了。

要知道，程序员总是以为自己优秀所以就能成功，其实不是。中国的程序员大部分是盲目的：看看CSDN的论坛就能够感觉到，要么有一群人自我感觉极端的良好，以专家自居，要么就是一群蓝领埋怨公司和社会环境不行，待遇不好。

应该说，中国程序员创业的成功率也是很低的。放眼望去，中国互联网成功的人士有几个是真正写过十年软件的。事实上，现状和我们所能听到的媒体宣传的故事很不一样。

很多程序员的最高理想就是写一个共享软件，一年可以挣几百万。但我希望谈的不是告诉程序员如何挣钱，挣钱很容易，而是要告诉程序员如何去创业。比如虽然FlashGet的作者收入很高，衣食无忧，但从创业的角度看，它并没有以商业公司的方式创业成功。

记者：那根据您的观察，中国的程序员在创业方面欠缺哪些？

周鸿袆：首先，我看到中国程序员的合作心态非常缺乏，我认为这是中国程序员最大的问题，当然这是有很多原因的。

大家经常说这句话：态度决定一切。但事实上好程序员基本上都比较傲气，因为程序员往往会觉得自己在做世界上一件十分伟大的事情，这就是驱动机器，修改一行代码，机器就能够工作，可以产生各种不同的行为。这很容易会让程序员产生一种错觉，认为自己可以Control Everything。程序员的自信在编程上是非常需要的，但不是适合一切场合。如果我们不说这些，可能很多程序员到现在还不知道自己错在哪里，仍然认为自己是King of the World。

事实上，程序员的能力只是控制了一个机器。但创业仅仅具备了和机器打交道这一种能力是绝对不够的，他还需要和合作伙伴、竞争对手、投资人、员工甚至整个社会环境打交道。很多程序员因为已经习惯了和机器打交道，不善于也不愿意其它的工作。很多程序员会内心认为“营销不是很简单嘛，市场很简单啊，管理也很简单啊，”我认为这种心态是非常害人的。

程序员还是一个很固执的人群，他觉得自己是机器的统帅，因此不会灵活，不会妥协。我当时也喜欢写程序，但我知道如果自己沉迷于写程序，肯定没戏，所以是逼着自己改变角色。

记者：在做公司的过程中，您应该也经常和不同层次的程序员打交道吧？有什么深刻的故事和印象？

周鸿袆：这两天，我收到几封程序员的来信。有一封信中大意说“我是个如此优秀的程序员，为什么我就不能成功呢，请你指点。这里有我的blog地址，看完你就会了解我了。”我想说的是：如果真的希望别人帮忙，就要把情况真实的说出来，而不是上来就说自己很优秀，这种语言就会让别人觉得很不舒服，不是很好的交流方式。我还真看了那个blog，但看完之后，觉得这个程序员就是一个空想狂。

可以说，很多程序员实际上是优秀带来了自负，这种自负使得其不要说创业，可能在在公司中工作也会遇到问题。所以，我甚至认为程序员在创业方面遇到的困难比其它类型的人员更大。如果程序员希望主导一个创业，可能首先就要逼自己不是一个程序员。

记者：所以我们不能只单纯谈程序员创业，而是要从程序员创业谈起。为了避免这些问题，要做哪些转变呢？

周鸿袆：是的，要从创业谈起。程序员首先要学会和别人合作。提到这点，很多程序员都会说“我正在带着其他程序员写程序啊，我会合作啊。”但这种合作是片面的，我所谈的不仅仅是程序员和程序员之间的合作，而是包括了程序员和其它各种角色之间的合作。程序员相亲，他们的语言比较能够容易理解。但作为一个程序员，你能不能商业人员、销售人员很好的合作呢。

我这些年还看到很多这样的例子：程序员动不动就把目标定为比尔·盖茨。其实，比尔盖茨不应该成为程序员崇拜的目标对象，这会让程序员迷失方向，因为微软另外一个创始人保罗·艾伦才是真正的程序员。再看其它一些例子，Google的第20名程序员都可以获得五亿美元。Adobe公司两个创始人也是一个精通技术，一个对商业精通，这样的搭配才能够更好的成功。因此，对于很多程序员来说，一定要找准真正的榜样，不要被外界的故事迷惑了头脑。如果剖开一些故事的外表，你会发现国外很多成功的程序员，背后一定有一个很强大的商业感觉的人或者一个团队。

记者：那也就是说，程序员应该作为一种创业的参与者，而不一定要做主导者了？

周鸿袆：程序员的商业感觉其实并不是很好。即便有商业感觉，其实这只是一个灵感，一个创意，但要要做成、做大还需要一系列的管理、市场、运营，这些对于程序员是不可想象的。程序员要明白，在自己不擅长的领域，找到一个可以弥补自己缺陷的合作团队才是出路。加入一个创业团队，可能个人占10%，但因为更容易成功，而且团队可以做100分的事情。而如果只是一个人做，很可能就失败了。

这方面，国外的程序员对自己的长短比较清楚。在硅谷，很多程序员技术上都很牛，但他们都非常知道自己只是在技术这个领域水平比较高，出了这个领域，自己什么都不是。正因为有了这种心态，他们特别懂得与人合作。我认为国外的程序员已经普遍意识到了这点，他们很愿意成为创业团队中的一员而并非自己创业。

因此，程序员需要调整心态，不要把自己当作精英人物，要承认自己在编程方面是优秀的，但永远有人比自己更优秀，对于其它的领域，很可能自己很无知。要知道，其实程序员的选择其实是最少的，因此抱有开放的心态是最重要的。

记者：你认为国内的程序员在哪些地方还与创业的要求存在一定差距？

周鸿袆：我认为现在的很多程序员经验过于不足，他没有认真踏实做过很多工作就奢谈创业。如果一个程序员没有在编程方面深入过，没有积累，也就是半瓶子醋。这样的程序员我接触过很多，他们自己也不清楚问题出在哪里，让人感觉又爱又恨。我认为程序员既然要凭借自己的技术，那就一定要踏实，要能够实现任何创意。

但现在一些程序员自己没有商业意识，却又很自负，不相信别人，不理解的事情就不做。我遇到过很多程序员，他们对公司做什么方向都质疑。他们希望自己先想清楚，可是一想就浪费了很长时间。很多程序员就可悲在这里，积累的不多，看不到方向，但他也不相信自己的公司和老板，这是一个悖论，需要程序员深刻反省。要知道，每个公司都有懂商业的人。

就这样，一些程序员极端自负，另外有一些程序员碰了很多钉子之后，感觉很自卑，于是便认为国内软件业不行，最后出国或者打工，很少有程序员能对自己能做公正的评价。

记者：您是否认为国内的环境是造成程序员浮躁的因素呢？

周鸿袆：这个倒问住我了，我以前没有仔细考虑过这点。但我想，不管怎样，程序员需要先从自身找问题，因为大环境就是这样了。我承认一个现实：程序员生存状态并不是很好，但程序员很多报怨其实是一种不切实际的期望值和自身的缺陷产生的反差。

首先，产品没有大小，只有市场的大小。很多人总是觉得这也小，那也看不上。认为公司做的产品很无聊，要做就要像CSDN论坛中某些人宣扬那样：做游戏一定要做3D引擎，好像只有这样才够牛。这其实就是一种浮躁。很多程序员写软件总是很多bug，基础知识也不牢固，没有参加几个项目，没有写过十万行代码，就奢谈做大项目，这有价值吗？

而且我还发现有些程序员特别愤青，骂环境，骂老板，其实这只能把自己的心态搞的很坏。很多人刚进公司时做的很差，虽然工资少，但他没有想到给公司增加了很多bug，公司实际上是在给他出学费。论坛上大家都在讨论哪里活干得少钱拿的多。甚至还有人列了一些黑名单。这种做法的结果就是程序员自己将周围环境搞的乌烟瘴气了。

有的程序员还非常喜欢指点江山，指点公司。我个人觉得这不是不可以，但指责别的公司对个人没有什么好处，因为存在就是合理的。如果看不到，恰恰证明是自己看不到。我看到很多程序员也写blog，技术交流的我认为非常好，但有些人是写评论。我是觉得程序员不要做评论家，中国不缺评论家，最缺的是实干家。

总之，程序员一般过于自我。总生活在自我的世界中，就不可能真正了解世界是什么。我很早就意识到了这些问题，也努力的去客服。我的经验就是看别人如何做的好，为什么能够做的好，什么是我所不能理解。程序员要学会慢慢站在别人立场上看问题。

记者：您对希望创业的程序员有哪些建议呢？

周鸿袆：对程序员来说，现在要做的也很简单，这就是需要大量的实践，要慢慢培养对产品，对商业的感觉。我的建议说出来可能有些忠言逆耳。对绝大多数程序员来说，自己一个人成功的机率是很小的，所以我认为加入一个创业的团队可能更为合适。现在有很多初期创业的公司，也需要很多优秀的程序员加盟。如果有理想，可以选择加入一个团队，也有相应的股份，这方面我可以充当一个桥梁。

本文链接

什么是XCode

2011-10-30T08:47:00Z

Xcode 是用于构建 Mac OS X 及 iOS 应用程序的完整工具集 - Xcode 4 的工具经过重新设计，它们的性能更优秀、使用更容易，能带给用户前所未有的助益。Xcode IDE 能够理解所有的工程细节，可以识别代码中的语法及逻辑错误，甚至能够帮助您修正代码中的错误。简言之，Xcode 4 能够帮助您编写更好的代码。

Xcode 4 具有全新的用户界面，而且它赖以构建的技术也得到了充分的验证。一方面，苹果公司自身就是通过这些技术构建 Mac OS X 以及 iOS；再者，开发者利用这些技术已生产出超过 25 万个 Mac OS X 及 iOS 应用程序。

Xcode 4的新特性

● 单窗口

如果是有经验的 Xcode 用户，则首先会注意到 Xcode 4 把以前执行日常开发任务的多个窗口合并成一个。Xcode 4 的工作区含有数个极具特色的 UI 元素。有了它们，操作多个不同任务，甚至多个工程就变得非常容易，再也不会把工作区弄得凌乱不堪。在使用 Xcode 4 的过程中，编辑器总是位于屏幕前方中心处。
导航器
Xcode 4 的左边是一些导航器，包括一个工程文件列表、已排序的符号、一个居中的搜索界面、正在跟踪的问题、带有可压缩栈纪录的调试数据、激活及未及激活的断点以及一些可以长期保存的日志。通过这些导航 UI 联合在一起，用户便可对工程的内容以及搜索结果进行实时过滤，这样就可以把精力集中于当前的任务。
跳转栏
编辑面板上方是路径栏，它显示当前文件的相对位置。点击路径中的某一位置就可立刻跳转到对应路径层次的其他文件。这一功能即所谓的跳转栏，当您将整个桌面用于显示编辑源代码，跳转栏可有效应用于不同文件的快速跳转。

● 内置的 Interface Builder

在 Xcode 4 中，Interface Builde 已彻底整合至 Xcode IDE - 不再是独立的应用程序。
选取一份工程中的界面文件（具有 .nib/.xib 后缀的文件）就能打开 Xcode 的 IB 编辑器。打开右手边的工具区，就可以看到整个界面观察器、控件库以及 UI 对象。在开发 Mac OS X 或者 iOS 应用程序的时候，您可以从控件库拖出控件，将之放置在程序的画布上，并可设定它的位置，从而实现程序的布局。
最好的功能：您可以直接把连接从 UI 设计区域拖到源代码区域。Xcode 4 新型的分隔式编辑器布局大大简化动作和插座变量的编写。只要把连接拖到现有的代码即可-一个手势即可搞定。如果还没有编写连接所需要的代码呢？在这种情况下，Xcode 将会为您创建一个新的插座变量或动作。只要将连接拖动至源文件的空白区域，Xcode 就能生成相应代码。

● Assistant

不管是编写代码还是设计界面，任何修改都不可能孤立变化。哪怕是一个最小的编辑动作，都可能在工程中产生级联效应。通常情况下，您不仅需要看到当前文件，还需要看到与之相关的文档。
Xcode 4 的双面板编辑器布局搭配上 Xcode Assistant 之后，其功能强大得让人惊讶。当您在工作的时候打开 Assistant，IDE 会预测您需要查看那些其他的文件。如果您正在编辑一个新的派生类，Assistant 将会为您显示父类代码。如果您正在编写新的实现代码，Assistant 会自动为您显示头文件。如果您正在设计一个界面，Assistant 会自动为您显示恰当的控制器，这样可以让拖放代码连接变得极其简单。如果您正在设计数据模型，Assistant 又会把一些可支持模型的类显示在您眼前 - 一切都自动进行。

● Apple LLVM 编译器 2.0

Apple LLVM 是下一代编译器技术，它是 Xcode 4 如此强大的力量之源。Apple LLVM 以 LLVM.org 项目为基础，该项目是苹果的工程师领导的优秀的开源项目。此外，Apple LLVM 编译器采纳最新的思想，并针对 iPhone、 iPad 以及多核 Mac 进行优化。
Apple LLVM 执行速度很快，其编译代码的速度比 GCC 快两倍，生成应用程序运行速度也更快（相比 GCC 生成的应用程序）。整个编译器被构建成为一组高度优化的库，使用方便且易于优化，并专门针对当前最新的芯片架构进行设计。在 Xcode 4 当中，整个 Apple LLVM 编译器栈—从千对解析器到后端代码优化器—都对 C、 Objective-C 以及 C++ 有极佳的支持。
Xcode 4 的语法高亮、代码补全以及其他所有的索引驱动的功能都通过 LLVM 解析器进行处理。编译器知道的符号， Xcode IDE 都知道。它在代码编辑期间就对于 C、 Objective-C 以及 C++ 有很好的理解。其精确程度不逊于链编期编译器对它们的理解。

● Fix-it 和 Live Issues

Apple LLVM 引擎会在后台不断地分析您写的代码，理解其含义。在您输入代码的时候，编辑器新增的 Live Issues 功能可以利用引擎对代码的理解，向您报告编码错误。其工作方式与文字处理工具高亮拼写错误类似，不需要先点击 ‘build’命令，便可高亮出常见的编码错误。
自动修正错误
IDE 非常聪明，不仅能够报告错误，甚至可以修改错误。在许多情况下， Xcode 除了报告错误，还向您提供解决方案。只要点击其报告的错误，就可以看到它提供的解决办法，例如把赋值符号修改为比较操作，修正某个拼写有误的符号或者添加一个缺失的分号。只需按一个键盘快捷键就可立即修正错误，然后继续编码。
Fix-it 指 Analyze 会在您输入代码的同时执行严格检测，这是一种极其有用的功能。 Xcode 静态分析器将会遍历成千上万条代码路径，查找不具有预期行为的代码（在代码合乎语法规则的前提下），例如查找代码是否有内存分配错误，是否存在永远不会被运行的声明，是否有未正确构造的循环。
只要把 Fix-it 和 Xcode Analyze 的功能结合起来，您发现程序错误的时间将远远早于用户。

● 版本编辑器

通过使用 Xcode 4 的版本编辑器，在一个实时编辑器同时查看任意两个版本的源代码变得易如反掌。更重要是，版本编辑器是在 IDE 中对源代码进行控制管理的新方式，因为比较视图同时也是一条时间轴，拖动视图中间的滑动条，您就可以按时间回溯工程，比较任意两个版本的源代码。
版本编辑器也可以向您显示已发生事件的详细日志，可以对 check-in 责任进行追踪。很多复杂的 SCM 命令都由它在幕后管理，不需要您操心。它甚至可以在一个 Xcode 4 工作空间中管理多个工程（例如，它可以管理两个分别由不同版本控制系统管理的工程，一个由 Subversion 管理，另一个则由 Git 管理），并且所有的工程能够自动更新。

● 新调试器

Xcode 4 引入 LLDB，这是一个全新的调试引擎，由苹果公司捐献给 LLVM.org 开源项目。和 LLVM 类似，LLDB 引擎从一开始就被设计成为消耗内存非常少且具有极佳性能的应用。
新的 LLDB 调试引擎可以和 Xcode 4 的调试界面完美结合。在程序运行的时候，导航器会向您显示栈纪录。在调试的时候，您可以对栈纪录进行扩展或压缩，以此来显示或隐藏栈帧。在单步运行的时候，您甚至可以锁定某个线程，然后再点击“continue”，这样可以跟踪特定线程的执行。在 Xcode 4 里面，多核调试和具有代码块以及 Grand Central Dispatch 的多核编码同样简单。

● Xcode 4 的仪器

仪器、跳转栏以及 Xcode 4 UI 中的栈压缩都具有最新式的界面。通过 Xcode4 的新启动方案，开发者很容易就能为运行在仪器中的程序创建一套健全测试装置。新的启动方案包括以“延时模式”启动仪器，不让收集数据的界面显示在屏幕上，把系统资源节省下来留给运行和计量应用程序所需。
Xcode 4 新增了一些数据收集仪器，包括用于跟踪 iPhone 图形性能的 OpenGL ES 仪器，可发现非预期内存增长的内存分配监视仪器，只需要很低消耗便可收集数据样本的 iOS 系统 Time Profiler，用于了解所有系统进程如何交互的 System Trace。
不同功能的仪器正在增多，而且它们耗费的系统资源越来越少，因而，能够带给用户前所未有的助益。

本文链接

携云而来的iOS 5

2011-10-30T08:43:00Z

昨日，就在iPhone 4S面世后的一周，Apple 为开发者和用户正式发布了iOS 5，该版本适用于iPhone 3Gs之后的iPhone以及iPod系列产品。本次升级主要带来了原生的Twitter支持、使用iCloud为应用和用户创建的文档提供备份服务、在无需PC的情况下，通过无线来更新操作系统等特性。

以开发者的角度来看，借助iCloud和iMessage提供的API，可以进行数据保存以及同其他用户进行通信，包含在应用中进行群组聊天（例如提供了即时反馈的机制）。既可通过单独应用发布Twitter消息，也可使用Twitter提供的短URL服务来进行发送。同时还为开发者提供了模拟 GPS定位导航服务的工具，以及检测泄漏的工具。

在图像支持的方面，主要包括OpenGl ES 2.0版本的升级以及新增的GLKit，GLKit API主要被用来开发图形类游戏。开发工具升级到了Xcode 4.2版本，此版本中带来了大量的改进，包含自动引用计数（ARC，Automatic Reference Counting），ARC 提供了类似于codebase的一种垃圾回收器，但不同的是，出于性能的考虑，现在常用的retain，release操作将不允许开发者使用。AV Foundation框架允许应用将流媒体输出到Apple TV或其他支持AirPlay的设备上。

iOS 5已经可以下载，面向开发者的开发文档及下载地址可通过开发者网站进行下载。

查看英文原文：iOS 5 Brings Cloud to All

本文链接

WPF与Silverlight的关键区别？

2011-10-30T08:39:00Z

当WPF和Silverlight越来越受到.NET开发人员重视的时候，两者间的界限也越来越模糊。回顾六月，Wintellect发布了鲜为人知但极其重要的“微软WPF和Silverlight之异同白皮书”。我们建议GUI开发人员要通读全部69页，我们会列出主要的观点及其对相关业务范围开发人员的影响。

依赖关系属性是两个平台的重要组成部分，使用PropertyMetadata可代替普通字段来保存属性。Silverlight仅提供了该类，而WPF却有若干子类型可用。

UIPropertyMetadata添加了一个标识符，用于决定“在使用了元数据实例的地方，是否应该禁播依赖关系属性的动画”
FrameworkPropertyMetadata添加一个标识符来指示影响管道的那些属性，包括控制管理、测量和呈现。它也可用于指示属性是否允许数据绑定以及默认的类型。由于Silverlight不支持该类，因此所有的数据绑定在默认情况下都是单向的。

Silverlight不支持隧道事件。两个平台都支持Direct事件和Bubbling事件。

WPF支持多种类型的触发器。一个简单的触发器附加到依赖关系属性后，当触发器条件满足的时候便会自动修改样式。除了简单触发器以外，WPF也支持可响应路由事件或使用数据绑定的触发器。

Silverlight使用视觉状态管理器代替触发器。WPF当前并不提供该技术，但会在WPF 4.0中添加。

Silverlight仅支持若干标记扩展。除了通用的StaticResource、Binding和TemplateBinding扩展以外，WPF还添加了DynamicResource、RelativeSource、x:Type、x:Static和x:Array。

有很多键盘和鼠标事件仅在WPF中可用。由于为数众多的关系，我们稍后会列出完整列表。

关于UIElement类和IInputElement接口。当某个控件被禁用的时候，WPF使用它们来禁用所有的子控件。Silverlight不提供这种功能，所以开发人员不得不手动遍历控件树。

在通信方面，Silverlight仅限于BasicHttpBinding和PollingDuplexHttpBinding。当然，WPF支持所有的绑定。

最后，打印功能在两者之间也完全不同。WPF可直接打印可视化树而Silverlight则依赖浏览器实现。

查看英文原文：WPF vs. Silverlight – What Really is the Difference?

本文链接

顶级脚本语言：PHP、Ruby、Python

2011-10-30T08:38:00Z

Evans Data发布了脚本语言调查结果。在500多名开发者和IT专家心目中，PHP、Ruby、Python是他们最爱的语言。随着时间推移，企业中脚本语言的应用也发生着变化，这份调查列举出了每种语言的优缺点。Richard Dice（Perl基金会主席）在近期的采访中表示，脚本语言在企业里面正在呈现上升趋势，不仅仅用于简单任务或是原型构建。它们的应用范围更加广阔。
在调查中，用户要根据以下种种特性（源自调查问卷）给语言评分：

易于使用
异常处理
扩展
可维护/可读
跨平台移植
社区
可用的工具
工具质量
性能
内存管理
客户端脚本
安全

所调查的语言包括：Actionscript、Flex、Javascript、Microsoft F#、Microsoft Powershell、Perl、PHP、Python、Ruby、VB Script。最终根据用户的意见生成调查报告。

综合评分（包括权重）将PHP、Ruby 、Python推到了首位。

在这次调查中，最优秀的语言是那些开源语言，它们以符合自然发展规律的方式进化。而那种私有的Microsoft语言，虽然背后有着软件巨头的强力支持，也有众多资源，但并未像开源语言一样受到用户好评。

在用户眼中，Ruby和PHP的易用性最好，Python的扩展性则评分最高。在这三种语言中，Ruby的社区力量尤为显著：

Ruby社区相当小，但每个人都积极参与，勇于表达自己观点。

报告中也提到了一个常见的争论：Ruby的性能。

即便是最热衷于Ruby的用户也会对Ruby应用的性能有所怀疑，而且有些广为人知的用Ruby编写的Web 2.0应用，性能和扩展性方面已经暴露出了很严重的问题。

报告中也突出了另一个问题：开发者对安全的关注还是一如既往的低。

最后来看，Ruby的评分从高到低分别是：易于使用、社区、跨平台移植、可维护/可读、异常处理。

Antonio Cangiano和Peter Cooper对09年中Ruby面对的挑战持有异议，他们认为，Ruby面对的真正挑战来自于技术或是传道。EDC调查报告显示，Ruby平台需要在客户端脚本（这方面JavaScript的得分最高）和工具（质量和可用性）。

查看英文原文： Top Scripting Languages: PHP, Ruby, Python

本文链接

观点：Rails还是PHP？适合才是最好

2011-10-30T08:37:00Z

随着大举进军Rails号角的吹响，Rails成为Web 2.0中小型站点开发的框架新宠。一夜间rails与敏捷开发的思想逐步深入人心，在这个技术浪潮中涌现出的成功站点也不在少数。然而，Derek Sivers最近在O’Reilly站点上发表的一篇名为两年RoR开发付之东流，重返PHP的七大理由的文章，激起了rails开发者们强烈的反响。

Derek Sivers是CD Baby以及HostBaby的创建者，自CD Baby站点于1998年创建以来，经历了数次代码重写，从最初的HTML到之后的PHP，两年前Derek又将站点用rails重写，而如今又重新回归到PHP语言上来。缘何如此？Derek在文中写道：

2005年1月份，我在O’Reilly的Blog上撰文宣布，将放弃cdbaby.com站点原先十万行杂乱的PHP代码，并准备从头开始使用 Rails将站点的代码重写。于是我雇用了当时最好的Rails程序员，开始着手这个庞大的计划...最初的几个月进展非常顺利，但是在后续的开发过程中，需求开始与Rails实现显得有些冲突，并且使项目陷入窘境，有时我不得不问自己放弃原先的计划而使用Rails是否真是值得的...两年之后，我们在rails开发上经历了各种挫折，最终发现总共才完成了期望工作量的一半。

Derek一直在思考这个问题“有没有什么是Rails能做而PHP做不到的？”答案是否定的，于是Derek决定摒弃两年来使用Rails编写的代码，重新使用一直熟悉的PHP来将网站全部重写。Derek在文中写道：

仅仅用了两个月，只有我一人进行开发，并且没有使用任何框架，仅是在vi编辑器之下，使用PHP重新编写了CD Baby整站的代码，而且效果出乎意料的好。这应该是我写出过最好的PHP代码，完全遵循MVC和DRY（Don't Repeat Yourself）的准则，这些获益应归功于使用Rails开发过程中得到的经验和智慧。

Derek进而总结了从Rails转回到PHP的七个原因：

有什么是Rails能做而PHP做不到的？...没有；
我们整个公司的Web代码都是用PHP写成的，请别忽视应用间的整合问题；
别要你不需要的额外功能；
PHP小巧而快速；
PHP代码完全按照我自己的方式运作；
我喜欢直接使用SQL；
语言就像女朋友：你觉得新的更好那是因为你有了进步。

当然，Derek并没有否定Rails框架的好处，并总结了Rails为开发者带来的益处，当然更重要的是Rails经验为开发者带来的对问题看法的转变和技术的提高等。这些Rails的益处包括：

通过Active Record将数据封装在模型类中，通过接口向Web应用提供数据，符合Martin Fowler提出的Active Record模式思想；
具备自动加载（__autoload）机制；
真正的MVC分层设计；
所有的HTML代码来自于抢有力的模板机制；
极度简化的代码量。

Rails与PHP是面向敏捷Web开发的两种主要语言。针对两者在Web开发领域中的关系，JavaEye的站长robbin也曾做出过这样的评价：

根据我的观察，其实现在互联网应用，PHP仍然是当仁不让的第一开发语言，占据了最大的市场份额。这是有内在的原因的，因为PHP超级简单易用，是当前 web开发技术当中，学习起来最快的了。有点编程基础的人，学习一天，第二天就可以干活了。对于互联网开发来说，速度是第一重要的事情，拖拖拉拉做不出来网站，机会就永远丧失掉了，对于熟练的开发人员来说，RoR可以提供比PHP还要快的开发速度，这就注定RoR肯定会流行。

在一篇名为“漫谈rails与php”的帖子中，从框架和语言、MVC、ORM以及各自优缺点等各方面都做了评论，axgle在结尾处这样写道：

我想说的是php将继续发展下去，已经发布了的php5以及正在发展中的php6也将有一些新的特性加入。而rails也在不断发展中。我相信rails和php一道，都有各自的一席之地。

其实，语言或开发框架相关的争论并不鲜见，然而争论的最终结果往往是选择合适的语言或框架才是最正确的。在接触新技术的初期，不能仅靠对技术的热情而对不熟悉的领域主观臆断，因事先估计不足而使得结果事与愿违。程序的编写不仅要靠设计良好的语言和框架，靠经验的积累和技巧的沉淀有时才是最重要的。

高昂是IEEE-CS、CCF会员，博士研究生，关注开源软件发展与进步。

本文链接

ASP.NET vs. PHP，哪个更快？

2011-10-30T08:36:00Z

上个月Joe Stagner在博客上发表了一系列文章比较了PHP和ASP.NET的执行性能，引起了来自双方程序员的大量回应。Joe表示，他会将这样的测试持续下去，并寻求更为合适的方式，以获得对实际项目来说尽可能有参考价值的结论。

Joe表示：

一般来说，作性能测试的目的是要尝试证明一方比令一方要快。我受雇于微软，同时编写PHP和ASP.NET代码。我在.NET出现之前就在使用PHP，两个东西我都很喜欢。

所以，我很难说出哪个更好。当我说PHP好话时，我的微软同事们会写信来批评我，而当我发表倾向于ASP.NET的言论时，我的PHP朋友们会说我是微软的托。

我进行这个测试是因为每个人都对PHP的性能有自己的看法（Windows vs. Linux & 5.2 vs. 5.3），却没人能给出明确的数据。

根据Joe的描述，测试环境如下：

所有的测试都在同一台机器上运行（拥有4G内存和60G 7200转硬盘的Toshiba Tecra M5）。
Ubuntu 9和Windows Server 2008标准版分别安装于独立（但相同）的硬盘中。
Linux使用Apache2，Windows使用IIS 7作为各自的Web服务器。
双方的操作系统都进行了完整的patch或升级。
双方的系统和运行时都没有进行额外的性能增强。

从实验结果上看，PHP在Linux和Windows的执行性能各有千秋：

纯粹的语句执行在Windows上表现更好。
函数调用在Windows上更快。
对象的创建和访问，对于PHP 5.2来说在Linux上更快，但是对于PHP 5.3来说则是Windows更快。
类库调用在Linux上快得多（如在Ubuntu上进行加密要比Windows要快3到5倍）。
在Linux上访问文件性能略高于Windows，不过Windows上文件复制的性能要比Linux慢60%，可能是ACL高级安全的缘故。
在Linux上访问MySQL要比Windows快不少，而且在Windows上运行PHP 5.3的情况则更为恶劣（不过从下面PostgreSQL的情况上来看，这应该是糟糕实现的缘故）。
PostgreSQL在两个平台上的性能非常接近（1000个操作的差距在0.06秒之内）——无论是PHP 5.3还是PHP 5.2，Windows上表现都略胜一筹。
Windows上PHP 5.2访问MS SQL Server的性能稍逊于在Linux上访问MySQL（此时还没有面向PHP 5.3的SQL Server支持）。

Joe认为，这表示：

我们可以这么认为，对于纯粹的PHP执行性能来说，Linux和Windows相差无几，这不会成为选择Linux或Windows作为部署平台的决定性因素。
如果你在构建一个应用程序，那么PostgreSQL可能是更好的选择。因为它在两个平台上的表现都很优秀。
如果你的应用程序必须使用MySQL，那么选择Windows就需要早些计划扩展性问题了（个人认为Sun不太可能为Windows优化MySQL的性能）。
PHP的第一个版本的SQL Server驱动程序要比MySQL或PostpreSQL要慢一些，但这应该不会成为问题。第二个版本的驱动器正在开发之中，它会带来性能提升。

在Joe看来，全面来看，PHP和IIS团队在执行性能上已经做的非常成功，接下来就需要各开源程序的团队（Drupal、WordPress、Joomla等等）为各平台进行性能优化了。

不过，除了文件复制操作之外，ASP.NET在性能方面全面领先于PHP（无论部署在Linux还是Windows上面）：

Linux上访问MySQL的性能稍稍优于Windows上访问SQL Server的性能（使用普通的数据类型和SELECT语句）。但是这里的差距几乎可以忽略不计。
ASP.NET（C#）操作，如对象使用，类库调用等等，其性能都远高于PHP。

对于这个测试结果，Joe补充道：

我知道我的一些PHP朋友和Linux伙计们要跳出来驳斥我的测试和结果了。:)

我一直在思考，这样的性能比较是否需要加入一些高级的优化选项。不过.NET方面也有例如多线程，异步请求，和各种缓存方式可以使用

请注意——我并没有说“ASP.NET更快，所以你不应该使用PHP！”，我使用认为，PHP过于简单导致对某些高级应用来说有些举步维艰，就像ASP.NET在项目早期会有学习方面的复杂性。

对我来说，PHP最令人兴奋的地方不是它的语言/平台，而是成千上万聪明的PHP开发人员，以及各种优秀的项目（如Drupal、Joomla、WordPress、PHPBB、Nuke等等）。

可以这么认为，PHP在Windows和Linux上的性能处于同一个水平上，我现在终于可以为Windows编写那些我盼望着许多年的PHP类库了。

Joe还公开了测试代码。他表示，如果你对这个测试的结果有疑义，可以亲自进行这个实验，或是编写你自己的测试代码进行试验。

文章发布之后，许多网友对这一测试结果发表了看法。Joe基本上逐一回复了其中的主要观点：

“我使用ASP.NET只是因为我喜欢Visual Studio IDE”——我个人认为Visual Studio是最有生产力的开发工具。但是，PHP的有不错的选择。我使用Zend Studio，PHPEd，Komodo，Delphi for PHP，这些都很不错。我讨厌Eclipse，不过Zend也在这方面为PHP开发做了不少扩展。

应该比较ASP的性能——不用了，谢谢。旧式的ASP与目前的PHP与ASP.NET差距太大了。做这种比较，似乎是在建议使用ASP开发新项目，我强烈不建议你这么做。

32位与64位系统之间的比较——这些测试的目的并不是为了体现64位系统上的性能差距。今后的测试我会增加64位的场景。

“PHP丑陋至极”——哦，我不同意。旧式ASP要丑陋多了。你可以写出非常可怕而丑陋的PHP代码，也可以写出丑陋而可怕的C#或VB代码。同样，你也可以写出优雅的C++样式的PHP。这完全只和开发人员的技能有关。

应该使用Windows上的Apache进行测试——Apache是Linux上的服务器，不过我认为如果你在Windows上不使用IIS 7则会损失太多太多东西了。

“有办法在Win2K8中，在不损失安全性的前提下加快文件复制性能吗？”——似乎不行。我认为这涉及到Windows服务器上的ACL系统。我以后可能会测试通过数据流读取文件的性能，有些东西的性能可能会有所改善。不过，Web应用程序一般不会编程来复制大量文件。

“PHP一直是，也永远只是一个半专业性质的环境”——这种说法狗屁不通。PHP平台上有许多专业的，高质量的应用程序，也有很多我非常尊敬的开发人员。是否专业是开发人员的问题，不是PHP或ASP.NET的问题。

“我认为比较没有opcode缓存的PHP很不公平，.NET是编译执行的，而PHP需要每次都解释并‘编译’页面”——我同意这个测试可能不够完整，但是我不认同这个逻辑。我测试PHP的方式，就和下载安装的方式一样。我的虚拟主机也没有安装op-code缓存。而事实上，ASP.NET自带这个特性也并不意味着测试是不公平的，这是因为PHP缺少这个特性——不过这个要求很合理，我正在准备新的测试。

“说PHP不是一个‘专业的’语言很没道理，因为几乎所有最大的站点都是用PHP构建的”——这种说法是没道理，不过说那些站点“几乎都是”用PHP构建的也是错误的。有些是，有些不是。

Joe补充道：

如果你们看到这一数据之后对ASP.NET信心倍增我自然很高兴。如果我不认为.NET是开发Web应用程序来说是一种更好的选择——至少不属于其它平台，那么我也不会在微软工作了。

但是……如果你因为这些数据而忽视PHP，也是错误且幼稚的行为。

从纯技术角度来说，我认为.NET远比PHP强大，但这并不意味着PHP不够强大。在我看来，PHP的力量体现在众多的应用程序以及可用的框架。

大约一周以后，Joe公开了第二次测试的结果。与前一个测试相比，第二个测试主要有以下两个改变：

为Linux和Windows上安装了op-code缓存，并重新运行了大部分测试。
由于一些依赖项的问题，PHP 5.3 + APC的测试平台变成了Debain 5操作系统。

对于第二次测试及其结果，Joe解释到：

从结果上看，Ubuntu和Debian上运行PHP的性能差距可以忽略不计。部分条目的性能有些细小的改进，有些则有25%的提高，但是总体来说其效果比我想象中要来得低。

使用APC之后，一些条目的运行反而变慢了，不过我认为这只是机器所造成的误差。请注意，表格中显示的不是第一次的结果，都是经过两次刷新，确认是在缓存命中时得到的结果。

我认为现在的测试非常公平。

空的循环测试和空的函数执行非常重要，因为这反映了语言或平台的基础消耗。这是处页面传输等性能开销外的性能消耗，是一个重要的考虑方面。

我的一些PHP朋友也认可这个测试的准确性，不过给出了非常有见解的补充：

ASP.NET在性能上的领先不会对我有什么影响。PHP是我的最爱，我的应用程序已经足够快了。
没错，ASP.NET在基础性能上是比较快，但是我的应用程序可以通过优秀的页面实现和JavaScript实践把这部分性能补回来。
我在进行Drupal开发，我对PHP最熟悉，因此我宁愿多花一些硬件来保持更好的开发效率。

这些都是很不错的评论！

此外，根据上一次实验的结果，在Windows平台上运行PHP时，在MySQL和文件的访问上有一些性能问题，微软许多团队都向我获取了相关信息。希望这些数据都够转变为切实的改进。

Joe表示，他将收集大家认为更公平，更有意义的测试场景。以下是他所计划的测试项目：

实际页面测试：循环，寒暑调用和对象操作是一类测试，不过页面的整体呈现则是另一种有意义的测试。
负载测试：哪一个环境可以同时处理更大量的请求。
在负载测试中，哪一方的性能会下降地更快。
在各种情况下，64位平台的表现如何。

国内也曾经进行过PHP在Linux和Windows平台上的性能测试。InfoQ曾经报道过微软在WordCamp China 2009大会上公开了之前与康盛创想合作进行的性能评估结果：在Windows Server 2008 + IIS上运行PHP，从平均相应时间，每秒处理的请求数，以及数据吞吐量等多方便均优于Linux + Apache的托管方式。

您的看法如何？您希望看到什么样的测试呢？

本文链接

企业级开发，PHP准备好了吗？

2011-10-30T08:35:00Z

虽然PHP是Web应用开发中最广泛使用的环境，但它还是一度被认为无缘企业级开发。InfoQ组织了一个虚拟座谈小组来讨论语言/平台的演变及PHP在企业环境下的适用性。

相关厂商内容

Flash Builder 4.5高级版试用版免费高速下载

参加此次虚拟座谈小组的人有：

Zeev Suraski，Zend Technologies公司创始人，该公司主要关注PHP的进展，
Rob Nicholson，高级技术研员, 曾为IBM编写过程序设计语言运行时，
Derick Rethans，PHP开发小组成员，eZ组件的项目负责人

InfoQ：企业软件的一个关键元素就是互操作性，它可以让软件与其他平台交换信息。大家都认为PHP在这方面表现欠佳，因为它的WS-*支持相对来说比较新且功能较少，成熟度不高。关于这点你们是怎么考虑的？它会不会有所改变？

Zeev：我觉得相比WS-*而言，互操作性涉及的要更加多些。事实上，我们只看到了很少的基于SOAP的Web服务请求，而更多的则来自于其他标准，这主要是因为部署SOAP的过程较为复杂。PHP极好地支持了互操作，并且为此提供了很多不同的接口（REST，优秀的XML支持，SOAP，以及为web服务提供的 ZF组件等等）。据说PHP从2004年开始就为SOAP提供了非常好的基础支持，从2006年开始就通过Axis2扩展为WS-*提供了广泛的支持。我只能说我还从没有碰到过用户抱怨缺乏互操作性的情况，如果真的有，那也一定是赞美吧。

Rob：我觉得这只是部分人的观点。PHP源于其简单性。它是一门只需必要的复杂度，就能“解决web问题”的语言。因此PHP程序员会更多的选择REST 而不是SOAP。传统的企业软件正逐步向位于中间的PHP靠拢。比方说，IBM的许多企业级软件产品在去年都提供了RESTful交互支持，包括Atom 发布协议，这样的话就多了一个选择。在该用WS-*的地方使用它，而在开发的简单性和速度至关重要时，应使用REST。我们也饶有兴趣的看到了PHP被用来直接加强企业连通性。IBM的Message Broker可以当作一个“万能转换器”，它能够将一个东西连接到另外一个东西，而现在它的消息转化流中也提供了对PHP计算节点的支持。所以现在是可以在企业软件内部中使用PHP语言简单而又强大的语法和语句的。我们最近为IBM的CISC事务处理器发布了一个SupportPac，用以支持PHP语言。CISC正如软件一样，具有“企业级“的性质。它运行于主机上，可以由一些像银行，政府和医疗保健部门的组织来使用，用以处理一些最重要的可能影响到日常生活的事务。

Derick：我觉得这里没什么太大问题。PHP已经为所有的WS技术如SOAP，XML-RPC和JSON提供了支持。

InfoQ：过去的几年里，将脚本语言移植到JVM中并以利用它丰富的监控，安全等功能已经成为了一种趋势。这对于PHP开发而言并不陌生，因为现实世界中存在好些个运行在JVM中的PHP应用。制造商们对于提升性能的话题各抒己见。你们是怎么看待这种趋势的？

Zeev：我们在.Net中也看到了类似的趋势，但是这些脚本语言并没有很远地脱离原始的实现。我想对于JVM上的PHP也是同样的道理。事实上我们可以看到原生实现的PHP相比综合改造后的PHP所拥有的性能优势——尤其是对内存的需要以及在现实世界中长期运行的表现。尽管如此，标准实现最大的优势是在于它所拥有的强大社区支持（包括在代码贡献和使用上），这是其他实现所缺少的一个东西。

Rob：它的一切都令人如此兴奋，我相信它会有很好的未来。在数以千计的已经被实现的语言中，只有少量语言在自然选择过程中幸存下来，原因是它们特别适合于某个用途。因此开发者改进创新某种语言的实现是一个很自然的事情。如果我们看看Ruby社区就会发现，这门语言的成功归因于至少半打以上的实现，还有这些实现中的共享测试和性能调整，它们帮助明确了语言的规范，而相互间”最快Ruby“头衔的竞争也功不可没。我想我们正在PHP上见证同样的事情发生。我们已经看到了PHP实现间协作所带来的巨大好处，例如在过去两年里由社区产生了大量的全新测试用例以及为改善某些API而作的努力，我相信这种现象在未来会持续下去。我现在正工作于PHP在JVM上的一个实现，它已经用在了IBM的ProjectZero孵化器（incubator ）中，WebSphere sMush产品，以及我前面提到的CISC PHP SupportPac和MessageBroker计算节点中。我认为对于某些类型的问题，在JVM上运行PHP会非常有意义。我们看到我们的合作伙伴和客户正在使用它来耦合现有的基于Java的系统，这样做他们可以在轻松重用Java库和API的同时，享受PHP所带来的便捷。

Derick：尽管性能方面“可能”会有所提高，但是可扩展性却始终是个问题。PHP的整体思想是在无共享架构的情况下轻松实现可扩展性。在JVM上跑PHP会移除掉它的无共享架构。不幸的是PHP社区中只有一个叫做PHP-on-JVM的项目在尽可能的贡献着测试用例。

InfoQ：从PHP 4到PHP 5的升级不是一个简单的迁移过程。关于那些犹豫是否对即将发布的PHP 6进行投资的公司，你们想说些什么？

Zeev: 实际上我并不同意关于4->5迁移是个非常困难过程的说法。整个过程并没有太多的兼容性破坏问题，而只是相对简单地修补应用程序。事实上想要利用新的功能，多花一点工作是在所难免的，也是意料之中的。在6的版本中我们实际上更多的考虑了兼容性破坏问题——目前这个问题在6中要比在5中更具实质性。这就是我们需要花时间去做的事情。

Rob：我认为PHP5在今后很长一段时间都会存在。即将发布的5.3版本已经尽可能的设计为无痛升级，且增加了原本定在 PHP6.0中的几乎全部的功能，只差移除掉一些不用的功能和增加PHP 6.0中的unicode了。我非常渴望看到unicode版本的的PHP，因为它可以让基于PHP的JVM具有更加直接的兼容性，之所以更加直接是因为 JVM原生地采用了unicode来表示字符串，但是我怀疑采纳过程在PHP 5和PHP 6中都将会非常缓慢且持续许多年。

Derick：虽然大家对此总是怀疑，但是我们会努力减少这些问题，通过引入向前兼容的功能来转移到PHP 6。如果大家能够向我们反馈一下自己在当前开发版本中碰到的问题的话，那么可以帮助我们将迁移过程变得更加简单。

InfoQ：在所有的建立的语言中，社区中的人们都推动增加了许多高级的功能。而另一方面PHP一直被认为易学的功能较少。你们认为这种情况需要改变吗？

Zeevv：我绝对不认为它应该改变，因为它是PHP成功的一个关键因素。希伯来语中有句谚语大致这么说“给的越多，拿的越多”，我坚信这句话对于 PHP是适用的，至少在语言结构与语法上如此。通过使用扩展和框架，PHP可以无止境的扩展，在我来看，这些扩展和框架正是PHP最佳和最有趣的“最后前沿”。我觉得完全使用PHP的大型复杂网站（Facebook，Yahoo，Flickr），完全基于PHP的复杂现有应用（SugarCRM，OpenPro，CMS's），以及公司网站或内部系统依赖于PHP的企业证明了这样一个事实：PHP的功能集已经成熟，并且我们应该朝着这个方向走下去。

Rob：在我们着手为IBM的脚本产品WebSphere sSmash选择脚本语言时，就因为PHP如此广泛的使用面而特别选择了它。我们希望能够让数以百万的PHP程序员们能与企业或者企业软件紧密联系在一起，并且我们希望支持一种能够让新人程序员快速上手的语言。PHP的强大在于它的简单性。一门语言如果不想灭亡的话就一定需要不断的演变。如果PHP 5没有支持面向对象编程的话，肯定会丧失很多吸引力。伴随着PHP 5.3的发布，PHP肯定可以在这些新的特性上潜在的增加其复杂性。我想未来更多的工作是去了解怎样使用它们和在此之上形成的语句。鉴于新版本被采纳的滞后性，因此在大部分主流应用程序转移到使用5.3功能之前，还需要等上若干年，我想在这段时间里PHP程序员将会用大量实例来掌握这些新功能，并将它们用在简化常见的编程任务上。

Derick：不，它不需要改变，这两类开发人员都存在。增加新功能并不一定需要提高入门的门槛。

InfoQ：PHP作为一门语言，在这些年里一直追随优秀的范型而演变，并从一个简单的预处理器演变成了一个强大的OO语言。随着函数式编程风格崭露头角，你们觉得这种这种范式是否会走进未来PHP的世界？

Zeev：不会。PHP仍然支持过程式开发，并且不太可能会消失；我们早在启动PHP（PHP 3）中就增加了OO的支持，虽然它现在跨越到了PHP 5中。lambda大概是最接近函数式范式的东西了，而这正是我们需要完成的。这也映衬了我前面回答的一个问题——我们不想要一个一劳永逸的语言，只是想要一个能够完成工作的简单语言。

Rob：这在一定程度上已经发生了。PHP 5.3中闭包的概念就是来源于函数式编程的世界里。PHP社区混杂了大量经过“经典训练”的计算机科学专业人员以及一些业余自我训练的程序员。看到这个多样的社区中闭包的诞生和常用语句的演化其实是一件很有趣的事。我相信我们最终会完成一套被广泛接受的模式和语句，它可以很优雅的解决web开发中的常见问题，而程序员在使用时都不会想到其实这一切都源于函数式编程。

Derick：我不确定，我认为它不会特别合适。但是如果它对PHP应用程序有意义的话，也许可以找到进入PHP的出路。PHP在集成其他语言中有趣和有用的理念方面一直做得很优秀。

你是怎么认为的呢，选择PHP是企业的明智之举吗？

查看英文原文：Is PHP Ready for the Enterprise?

感谢霍泰稳对本文的审校。

本文链接

MVC框架Fuel PHP

2011-10-30T08:34:00Z

如今，MVC模式已经基本上占据了面向客户的职业网站设计全部江山。虽然单文件脚本仍然适合个人站点，像ASP.NET Web Form这样的表单构建技术能够提供快速开发能力，对于需要在大型团队中工作，同时仍需对生成的HTML有精密控制的人来说，看起来MVC找到了正确的平衡点。Fuel PHP框架，希望能够借鉴诸如CodeIgniter、Zend Framework、Symphony、Ruby on Rails等早期MVC框架的工作。

像大多数MVC框架一样，文件组织结构有其意义。资源、视图、控制器和模型都对应特定文件夹。此外还有地方可以放置通用的应用代码和框架包。Route可以配置，不过默认有一个URL会映射到控制器类的名字和action方法上。

要做任何事情，都要多写额外的代码，这是对于MVC风格框架常见的反对意见。使用单一文件脚本，人们可以以简单、线性的方式处理一切，从请求处理到 HTML生成。与之相比，MVC至少需要一个控制器和试图，很多时候，还需要模型在互相之间传递数据。因此，脚手架（scaffolding）这种代码生成的方式，变得很普遍。为了达到该目的，在Fuel PHP中，应用被称为“油（oil）”。

在Nettuts+网站上， Philip Sturgeon做的概览也覆盖了表单生成和数据验证。同样，这些都算是标准技术，其他平台的MVC开发人员都很熟悉。Fuel附带一个基本的数据库抽象层，还有一个可选的ORM包，供喜欢这种数据访问方式的人使用。ORM主要基于ActiveRecord，但是也受到其他ORM方式的影响。

Fuel以MIT协议发布，目前处于第一个候选版本，而且未来至少还规划了一个版本。

查看英文原文： InfoQ: Fuel PHP: An MVC Framework

本文链接

缅怀Steve Jobs对软件行业的贡献

2011-10-30T08:32:00Z

我想说这么一个故事。在Steve回Apple之前，我和他在NeXT有一次会面。当时去的还有我们公司的首席科学家。开完会出来，我们两个人在那里复盘刚才的辩论，想找出Steve的漏洞——他肯定不能对嘛。结果没成功。我俩站在停车场说话，让他从办公室瞧见了，又跑过来接着和我们辩。那时候说的是跟 Objective-C编程语言有关的一个技术问题。我也不知道他为什么对这问题那么上心。我从来没见过这种热情劲头。（Eric Schmidt）

很多人会因为Steve Jobs和他的团队推出、推广的杰出产品而记住他：Apple II、Macintosh、激光打印机、NeXT工作站、数字动画电影、iMac、iPod、iPhone、iPad。在过去的35年间，很多人的生活因为Steve的贡献而变得更美好。

从1985年到1997年，Steve在他离开Apple的12年里，参与推广了不少软件技术和编程范式，后来成为当前计算行业、编程语言和软件工程实践的基础要素。可以说，软件成为今天这个样子，也有他的一份功劳，虽然很少有人注意到这一点。我们InfoQ的众人，希望在此回顾他那些比较不为人知，但同样影响深远的贡献，以此作为我们最后的致敬。

就在Mac刚出来的时候，人们还普遍认为编写带有图形用户界面和多任务功能的软件（多任务在1987年面市），比起在Apple II、TRS-80或者IBM PC 5150的BASIC解释器上面编程，要困难得多。到八十年代中期，Borland已经开始普及Turbo Pascal等带有强大类库和灵便编辑器的语言。虽然我们不能确切地肯定Steve Jobs离开Apple之前是否已经着手Mac OS System 5，但最终Mac OS System 5的核心特性完全落入他的构想：多任务和HyperCard。后者是一种革命性的软件建造新方法，采取了“面向对象”和“模型驱动”的开发范式：

HyperCard里面的编程语言叫做HyperTalk，它是面向对象的。对象置身于消息传播的路径所构成的一个层级结构之中，响应由用户或者系统本身产生的各种消息。

HyperCard的基本概念是一“叠”虚拟的“卡片”。卡片上记载着数据，就像真的索引卡片簿一样。它的布局引擎概念上近似于现在快速开发（RAD）环境中所谓的“窗体”[……] 它有一个特殊的“Home”叠（后来网站首页的雏形）用来启动各种应用，有一个代码仓库存放各种共享脚本，还有一个配置各种首选项的设施。

HyperCard不仅仅是一个数据库系统。每张卡片可以有自己的独特布局，好比你在真的索引卡片上面也可以填写规定以外的信息。希望在同一叠的所有卡片上都显示的元素，可以放进一个特殊的背景层里面；也可以把背景相同的卡片归为一组，共享背景层。背景的内容除了图片（背景最开始的用途就是“背景图片”）、对象，还可以包含字段、按钮、（静态）文本、（可编辑的）文本框等等常见的GUI元素。然后每张卡片可以在它的文本字段、图片字段里面容纳各种数据，就像数据库一样。

到了1985年Steve创立NeXT之后，这些概念才算真正羽翼丰满。被昵称为“the cube”的第一款NeXT工作站于1989年推出市场。Tim Berners-Lee对此有这样的评价：

NeXT是一台非凡的机器。NeXT一下子引入了许多（甚至太多）新事物——可替换的光存储、Objective-C、针对音响和电影的DSP、Mach 核心、PC上的unix、Display Postscript显示系统、InterfaceBuilder等等。确实它的价格一直很贵，光盘也被证明不可靠。可到最后，拯救Apple的还是 Steve和NeXTSTEP。这说明认准了好东西就应该坚持，谁知道哪天它就成了主流呢。

他还说道：

在NeXT上面编写WorldWideWeb客户端异常简单。系统本身就带了Text Object模块，这是一个可编辑、多字体的编辑器。我只需要子类化出来一个超文本对象，然后加上互联网相关代码就行了。设计软件菜单什么的完全不费吹灰之力，也就是在 InterfaceBuilder里面拖放几下子。应用程序的代码框架是自动生成的。这就是平台的作用：在平台上面做出来的东西，没了它不是完全做不了，但那可就辛苦多了。

InfoQ的编辑Alex Blewitt在上世纪九十年代初有过一台NeXTStation，他是这么说的：

NeXTSTEP的操作系统功能已经十分完善，它能播放视频、录制声音、内嵌对象。相比之下，NeXTSTEP首发的时候，Windows的第3版还没出来。NeXT的硬件虽然不怎么实惠，但都是高标准的。标配以太网、24位色的显示器、16位声卡、内置麦克风和音箱（别忘了当时SoundBlaster还没变成通用 API，才是一种刚刚发布的产品而已）。它是价超所值没错——可偏偏第一版的HTTP就是在NeXT机器上面写的。

Steve挑选当时能找到的最好的软硬件，打造了一台划时代的万能机器，几乎领先时代十年之多。这台机器的操作系统NeXTSTEP是当时一些革命性组件的结合体：

基于Mach核心的类Unix操作系统，外加来自BSD的源代码
Display PostScript显示系统和窗口引擎
Objective-C语言及其运行时
面向对象（OO）应用层，内含多个“工具套装（kits）”
针对OO层的开发工具（如Interface Builder）
第一个动态HTML服务器（WebObjects）

Mach核心原先是在卡耐基·梅隆大学，为了支持分布式计算和并行计算而发展起来的一个先进的操作系统。虽然Mach保持与Unix兼容，但它的目标之一是绕开Unix“一切都是文件”的概念，因为这个概念被日渐证明不符合实际。从作为Mach前身的Accent项目开始，进程间通信（IPC）就极受重视，最终Mach针对性地提出了我们现在非常熟悉的一套新概念：

“任务”是“线程”运行所需若干系统资源组成的一个对象。
“线程”是单一的执行单元，存在于任务的上下文之中，并且共享任务的资源。
“端口”是用于任务之间通信的受保护的消息队列；任务拥有各自端口的发送和接收权限
“消息”是带类型的数据对象的集合，它们只能被发送到端口，而不能指定发送到具体的任务或线程。

它和UNIX有一个重要的区别，UNIX下的工具处理文件，而Mach下的工具处理“任务”。Mach把更大部分的操作系统代码移出内核，放入用户空间，结果形成一个大大缩小了的内核，术语“微内核”随之兴起。Mach的进程——或者叫“任务”——有别于传统的操作系统，可以由很多的线程组成。虽然对于现在系统来说非常普通，但Mach是第一个这样定义任务和线程的系统。

还有一样根本区别：

端口概念和对IPC的运用，可能是Mach与传统内核最根本的区别所在。UNIX下的内核调用由所谓的syscall或者trap操作构成。程序通过库在内存中的规定位置放置数据，然后引发一个fault—— fault是一种错误。系统一开始启动的时候就设置好内核作为所有fault的“负责人”，所以当程序引发fault的时候，内核就会接管过来，首先检查传递给它的信息，然后执行指令。[……]利用IPC来传递消息有利于线程和并发。因为任务由多个线程组成，使用IPC机制的代码又被放在线程内部，所以 Mach可在消息处理前后冻结和解冻线程。这种设计有利于把系统分布到多个处理器之上，既可以像大多数Mach消息那样直接通过共享内存来传递，也可以在必要的时候增加一点代码把消息复制到别的处理器上。传统内核不好实现这样的分布式构造，因为系统要保证不同处理器上的不同程序不会写入同一块内存。 Mach实现起来却很容易而且概念清晰，因为它把“访问消息所在那块内存”的过程，变成了“端口”这个系统基本元素。

Display PostScript（DPS）是一套屏幕显示系统，由Adobe和NeXT在1987年合作开发，同时它也是Adobe的一个正式产品。顾名思义，DPS利用PostScript（PS）图像处理模型和语言来生成屏幕上的图形，不过因应用户交互的需要做了一定的改动。如今在Apple的OS X操作系统里面，中央窗口服务器只把窗口图形缓存为PDF，已经不再执行PostScript代码。而在当时，PostScript提供的高级图形语言给开发者带来极大的好处，很容易就能创建出高质量、带交互能力的文本和图形显示，显示结果还能原样生成PostScript文档并最终打印出来。对于当时正为打印应用程序生成的WYSIWYG文档而困扰的人们来说，这是革命性的创造。

iPhone让Objective-C和NeXTSTEP类库（带NS前缀的那些）焕发了第二春。在1989年的时候，这可是远远超前于时代的一个软件开发环境，直到两年之后才开始遇到像样的竞争对手PowerBuilder。 Objective-C是Brad Cox和Tom Love在上世纪八十年代初期发明的一种反射式、面向对象的编程语言，相当于在C语言上面增加了Smalltalk风格的消息机制。NeXT开发的 AppKit和Foundation Kit类库内含丰富功能，比如非常完善的容器类。Interface Builder这个模型驱动、基于MVC的图形用户界面设计器则堪称NeXT开发环境的基石。

Interface Builder最早于1988年作为NeXTSTEP 0.8的一部分出现。它的创造者是Jean-Marie Hullot，一开始是用Lisp开发的。Interface Builder属于头一批允许通过鼠标来排布按钮、菜单、窗口等界面对象的商品化应用程序。Tim Berners-Lee开发WorldWideWeb网络浏览器算是Interface Builder早期一个著名的使用例子。

Apple Computer公司1996年收购NeXT之后，在其新操作系统Mac OS X中采用了OpenStep环境。其中除了Objective-C，还包括NeXT的Objective-C开发工具Project Builder（后来经过扩展，成为现今的Xcode）和界面设计工具Interface Builder。即便是Cocoa API这个当前最重要、开发最活跃的Objective-C环境，仍然大部分建基于OpenStep的界面对象。

WebObjects同样是相当领先时代的创新。这个史上第一的动态HTML应用服务器由Bruce Ong、Nico Popp、Charles d’Harcourt和François Jouaux四个人用Objective-C开发而成。它在数据库访问方面非常依赖Enterprise Object Framework。作为对比，同样做应用服务器的Kiva公司1995年创立，1997年被Netscape收购；一家名为Weblogic的初创小企业在1997年末向市场上推出Tengah服务器。

有一些现在常见的浏览器特性和快捷键组合可以追溯到NeXTSTEP的惯例。HTML 1.0和2.0的基本布局选项源自NeXT的Text类的特性。Doom游戏的关卡设计器WAD是在NeXT机器上面开发的。先进的电子表格软件Lotus Improv是在NeXT机器上开发的。有个叫Altsys Virtuoso的软件也是在NeXT机器上开发的，它的第2版被移植到Mac OS和Windows，成了Macromedia FreeHand第4版。MCI电信公司的“朋友家庭计划”用NeXTSTEP开发后台的支撑软件。甚至连控制半导体层积这样的工作，也可以找到NeXTSTEP的身影，比如Riber公司的Accessible软件（第2.5节）和休斯实验室的EpiCenter软件。

到NeXTSTEP开发告一段落的时候，它成功地运行在Motorola 68000系列、Intel x86、Sun SPARC和HP PA-RISC等不同体系的处理器上；以它为基础的OS X操作系统也在2001年正式发布。

InfoQ采访了Jack Greenfield，他曾任Rose的总架构师，现任Microsoft的Principal Architect ，于1989到1994年间就职于NeXT，领导Enterprise Object Framework的开发工作。Enterprise Object Framework是最早的的对象-关系映射工具之一。

当InfoQ让我简短总结一下当年在NeXT的经历，当作对Steve的追思，我就知道这是一件吃力不讨好的事情。怎么可能几句话就向不曾躬逢其会的人解释清楚那个地方、那个时候的神奇之处？但在这样的时刻面对这样的请求，哪怕再费劲我也要试试。于是我想了一下，大概像我这样的工程师大概都希望知道给Steve干活是怎么样子吧。

每个人都知道他有极深刻的洞察力，但这么说还不能表达其万一。当Steve走进房间的时候，一切都会变得不一样。我记得有一次，我们在谈持久化对象存储的事情，说来说去都是对象的序列化和访问机制。然后Steve过来呆了几分钟，领着我们遨游天外，想象用那些工具可以创造出什么样的世界。到他嘴里，说的就成了图片、视频、声音怎么联系到一起，怎么搜索，怎么合成文档，怎么跟朋友共享。当他离开房间的时候，我们就好像看完一场电影刚亮灯的时候，你要左右看一会儿，才想起自己在哪里，刚才做了些什么。最后我们的成果是近似于JSON的东西，超前二十年就已经扎根在OpenStep里头，到现在它的衍生产物还在左右着iOS上的用户体验，Steve当时描绘的一切都已经成为现实。

毫无疑问，他的远见极具启迪力量，但这么说还不足以形容和他共事的感觉。NeXT的每一个人都天资聪颖，拿出优秀的成果是理所当然的事情。一般的领导看了会流口水，流眼泪或者两者一起流的的成果，Steve却可能不为所动。在Steve身边，你只能做出前无古人，乃至后无来者的产品。其中的关键是他并不会直接这么告诉你，但只要没达到他认为有可能达到的高度，就会被认为一文不值。他有办法撩动工程师渴望卓越成果的雄心，然后他会一直激励你，暗示你现在努力得还不够，但他对你有信心。当你把东西拿给他看的时候，他说出来的几个字，或者根本不用说，就让你知道自己还能做得更好，也必须做得更好。当他喜欢你拿出来的东西，你会有站立在众山之巅的感觉，不仅因为他喜欢，还因为你知道自己是实现了自我突破才能站上那个高度。

Steve是独一无二的人物。我再没遇过任何环境能跟他在NeXT创造的氛围相比拟。那里不只是公司，有点像实验室，有点像游乐场，有点像兄弟会社，有点像战场，有点像大学图书馆，有点像现代艺术馆，有点像探险基地。我后来在很多地方工作过，不少地方也能激发我的热情和精力，但没有一个地方能达到 NeXT的高度。

Wired如此总结:

Steve Jobs留下的全部遗产还要很长时间才能计算清楚。起初员工们都带着贬义来谈论他的“现实扭曲力场”，指的是他那种凭借说服力和个人魅力令人信奉歪理的特殊技能。但到了某个时刻，Steve Jobs脑中的世界观突然不再是扭曲的，反而成了一种自我实现的预言。Apple公司的新产品一个接一个地破土而出，一个接一个地改变着我们的行为。 Steve Jobs的“力场”变成了真实的世界，而我们都生活在其中。

不少人对Steve有着负面的看法，但不管怎样，他是过去35年间一直不屈不挠地给无数工程师提出新挑战的一个人，这样的人屈指可数。他激励着工程师们去实践那些冒险的创新念头，取得超越想象的成功。如果没有Steve，今天的个人计算机和电话会变成什么样子？

我们将会记住你。

Think Different。

查看英文原文：A Tribute to Steve Jobs' Contribution to Software Engineering

本文链接