这是我们的纪念日

周一的早上，一边看着刚刚经历五卅惨案的股市慢慢从菜色中醒转，一边听着范玮琪的《我们的纪念日》。六月四日，就这样悄悄地过去了。完美主义的我，总是会暗示自己忘记那些不喜欢的事。

但，没有注意到是什么时候开始，Blog上引用Flickr的照片，都成了空白。

忙碌的一周过去以后，今天才有空找找原因。当然，和以往一样，Google知道答案。

于是，被尘封、被隐藏在心底的记忆，突然又鲜活起来。想起了大学篮球场上闪烁的烛光。想起了孤单的吉他声。想起了旅居德国和澳洲的朋友们。以及更久远的、早已无人提及的事情，都想起来了。

所以，感谢你们，感谢你们默默的辛勤工作，感谢你们总是适时地提醒善忘的我，感谢你们教我不要忘却。

所以，再听一遍《我们的纪念日》：

这是我们的纪念日纪念我们开始对自己诚实

所以，为了不辜负你们的劳动成果，我决定：

继续把空白的相册放在Blog的边栏上
继续把不能显示的图片链接在Blog里
继续把新的照片上传到Flickr
继续告诉朋友到Flickr去看我的照片

为了忘却的纪念，这是你们无声的教益。我受教了。谢谢你们。
这是我们的纪念日，我会一直记得。谢谢你们。

Convention Equals Knowledge

Convention Over Configuration为什么重要？

因为一个称手的约定俗成就是知识：关于“如何做某件事”的知识。

Struts只是给你无数种组织URL的可能性。换句话说，它没有告诉你“应该”如何组织URL。

Convention Over Configuration是在提供“可能性”的基础上，提供了“如何做”的知识，因此它简化使用者的工作。

和Rails一起成长——AWDWR II译者序

（原文请看：http://book.csdn.net/bookfiles/380/10038014231.shtml）

“如果说有什么事情比翻译一本厚达554页的书更费神的话，那就是这本书的第2版被它的作者们——不幸地——写到了720页，并且其中70%的内容与前一版不同，而译者还是你。”

林芷薰如此评价自己的翻译工作。原本无意再碰任何翻译工作的芷薰，终于完成了这本大书，原因也是想和Rails一起成长。

“当Agile Web Development with Rails（简称AWDWR）的第1版还在帮助全世界的Rails开发者和爱好者学习和使用Rails的时候，为什么这个第2版会以近乎崭新的面貌如此迅速地登场？答案显而易见：因为Rails本身发生了——并且仍在继续发生着——翻天覆地的变化。……这本AWDWR的第1版仍然有用，但已经错过了Rails太多令人兴奋的新特性，还有太多内容处于过时或即将过时的境地，这就是你会看到这个第2版的原因。”

“在这篇译序的最后，我要感谢ThoughtWorks公司对我翻译工作的大力支持。ThoughtWorks公司在全球范围内已经进行了为数不少的Rails项目，其中包括开源项目和客户定制项目。通过对这些项目——尤其是他们在中国进行的Rails项目——的学习研究，我获得了大量宝贵的第一手经验，也愈发增进了对Rails的信心。正是因为像ThoughtWorks这样拥有雄厚技术实力和丰富项目经验的企业不断开拓，Rails才能更快、更好地成长。”

两年过去。我们都在和Rails一起成长。我们大家都是。

Agile Web Development with Rails II：中文版出版在即

CSDN已经放出了样章试读。目前开放了第4章、第16章和第23章。如果要问这个第二版比起第一版的变化有多大，从这几个样章就能看出来：第4章基本上没有大变化，第16章“数据迁移”是全新的；第23章“Web2.0”虽然标题在第一版里有，内容也是全新的：Prototype、Script.aculo.us和RJS模板。

目前第二书店已经开始预订。

不过，我仍然觉得“xx之道”这种名字真是很土……这次的书是铁道，也就罢了。

系统监控工具：monit和runit的比较

关于Rails的部署：Rails部署艺术

monit作为监控工具有一个缺点：monit会以daemon模式来启动mongrel进程（以及，可能还有，haproxy进程），也就是说每个mongrel需要自己管理PID文件。问题出现在mongrel被意外杀掉的情况：此时PID文件仍然存在，因此monit没办法再用“mongrelstart -d”的命令来启动mongrel。你必须自己想办法清理这些“僵尸PID”文件。

而runit就比较好：它管理的进程都是自己的子进程，这些子进程以阻塞模式运行，所以也没有PID文件。唯一需要注意的是，haproxy缺省是daemon模式，你需要使用“haproxy-db”把haproxy启动在阻塞模式下。

所以，用runit来监控mongrel（和haproxy）进程，monit只是看着这些进程有没有异常状况；如果出现异常状况，monit调用sv来重启有问题的服务进程。这就是RubyWorks目前采用的系统监控策略。

沦落｜堕落｜失落

不管Google是什么，Google中国（我都恶心于说出“那两个字”）基本上已经沦落到民工一级，在西安火车站赫然陈列。

难道中国就有那么糟糕，让所有——不管曾经多么有品味——的外企都必须在这里堕落么？

“sigh……太失落了……”

铁道下的红宝石：点评Ruby畅销书三种

对于Ruby这种语言，很多人都和我一样，是因为一个突然风靡全球的、号称能够极大提升web应用开发效率的、名叫Rails的web框架而顺带了解到的。在为Rails的神奇魔力所折服的同时，我们也常常心生疑惑：这种强大的力量究竟来自何方？如果换成Java、C#或是别的什么语言，一个web框架能否同样高效？除了这多少有些“虚”的思考之外，我们还常常在各大论坛上看到“应该如何学习Ruby”这样的问题——Rails尽管方便易用，但要真正穷其千里目，仍须在Ruby语言这里更上一层楼才行。

好在书中自有黄金屋。不论是要深入探索Ruby语言的奥妙之处，还是只想在工作中遇到问题时查找参考，都有好书可以提供帮助。在Amazon网站上，抛开专讲Rails框架的Agile Web Development with Rails之外，销量排名前三位的Ruby图书分别是Programming Ruby（第二版）、Ruby Cookbook和The Ruby Way（第二版）。

镐头书：Programming Ruby（第二版）

由于封面上赫然画着一柄丁字镐，这本Programming Ruby也被Ruby程序员们亲切地昵称为“镐头书”——和历史上大名鼎鼎的“龙书”、“紫皮书”一样，拥有一个独特的昵称本身就证明了这本书的地位。虽然Ruby语言的作者Matsumoto并没有参与撰写此书，但Dave Thomas和Andy Hunt这两位“用本主义程序员”的大名也足以撑起一部经典教材了。

所以这本书就是Ruby的经典教材。关于Ruby的基本语法和常用工具，书中第一部分和第二部分做了详细的介绍。第三部分“Ruby Crystallized”更加阐述了Ruby语言的一些细节和设计理念，其中第23章“Duck Typing”是刚从Java或者.NET平台走出来的读者不可错过的，因为对于类型与契约的理解、对于类与类型的理解，正是Ruby这种动态语言与Java/C#等静态语言最大的区别之一。随后的第四部分提供了Ruby基础类库的速查手册。

身为“用本主义程序员”的两位作者并非浪得虚名：这本Programming Ruby虽然不是一本称职的参考手册，却足够帮助一个初学者步入Ruby世界而不致误入歧途，并且能够在很少见的一些情况下——譬如说忘了yield的用法——给有经验的Ruby程序员提供帮助。在我看来，这也就足够奠定它作为经典教材的地位了。

不可读，不可不读：Ruby Cookbook

“写作这本书是为了帮你节约时间。人们常说‘时间就是金钱’，没错，不过别忘了，时间还是你的生命。我们有限的生命最好是用于创造有趣的新事物，而不是跟自己的错误较劲，或是试图解决那些早已有人解决过的问题。我们花了不少时间来写这本书，只希望它帮助所有读者节约的时间能够值回票价。”

这段话出自Lucas Carlson和Leonard Richardson两位作者为Ruby Cookbook所写的前言。说得没错。人们把太多的时间浪费在实现通用算法、做别人已经做过的事、调试错误和重复劳动上；在想要避免重复劳动时，他们又把太多的时间浪费在搜索、试用和学习别人提供的库上。就像两位作者所说，这本Ruby Cookbook的问世正是为了帮助人们节省这些时间。

而它也毫无疑问能够兑现自己的承诺。这本Cookbook涵盖的内容从字符串处理到数组与Hash的用法、从代码块到元编程、从文件读写到数据库持久化、从互联网服务到分布式Ruby程序设计……简而言之，Ruby程序设计中的各种常见问题在这里都有所提及。除了编程任务之外，这本书还包括了测试、调试、性能优化、打包发布、日常任务自动化等内容。说得夸张一点，也许Ruby程序员们遇到问题时第一个咨询的对象不应该是Google，而是这本Ruby Cookbook。

但——在我个人看来——它有一个致命的缺点：太过厚重。涵盖如此大量的内容，代价就是两位作者把这本书写到了近千页之厚。当然我们并不是没读过厚达千余页的大书，但Ruby毕竟不是C++，如何期望那些满怀激情的web 2.0创业者捧着一本鸿篇巨著正襟危坐孜孜苦学？所以，也许你应该把这本书放在案头，遇到问题时立即翻查，但你很可能不会有兴趣去细细读它。

解说Ruby之道：The Ruby Way

在Rails变得炙手可热之后，我不止一次地听到这样一种——不无醋意的——论调：只要学习Rails框架的设计思想，用别的语言（譬如Java）也能够做出同样优雅、同样高效的web框架。其实正如维特根斯坦曾说的，语言本身已经为思想划下了界限。选择一种语言远远不止是选择它的语法，还意味着选择其中的模式、惯用法、套路和思维方式。或者说得更玄一点，你不仅要接受它的“器”，更重要的是掌握它的“道”。

但“道”是很难形容的。“我能够感受到它，但未曾尝试过用语言来解释它。这太难了，即使是用我的母语日语。但Hal Fulton这样做了，且第一次就做得很不错。由于得到了Ruby社区许多人的帮助，他的第二次尝试更出色。”Ruby语言的创造者Matsumoto如是说。从篇章选材来说，Fulton所著的这本The Ruby Way与前面介绍的Ruby Cookbook大同小异：无非是各方面的常见问题及其解决方案。不同之处在于：它不仅讲解如何解决这些问题，还揭示出解决方案背后隐藏着的Ruby的思维方式——Ruby之道。这也让这本书——尽管其厚度并不逊于Ruby Cookbook——有了更多的可读性。

作者把“Ruby之道”分为两部分：Ruby设计的哲学，以及“如何使用Ruby”的哲学。Ruby语言具有某种“无名特质”，其中最大的特点就是“简单”：它让程序员们能够以更简单的方式解决问题。但Ruby并不是一种简单的语言——简直可以说它“相当复杂”。那么，这种复杂的语言是如何让使用者的生活反而变得简单的？了解其中的奥妙，不仅有益于快速掌握Ruby语言，对于读者今后的软件设计思路也不无裨益。带着这个问题来阅读这本The Ruby Way，相信读者能够更好地看出作者的良苦用心。

作为“Web 2.0时代”的产物，这本书的第二版相比第一版也加入了很多新鲜内容，例如测试驱动、开发工具、社区介绍等等。此外Rails的作者David Heinemeier Hansson也指出：本书在阐述元编程，很多Rail理念的灵感都来自本书的第一版，尤其是现为第11章的内容。不过如果你恰好是刚开始接触Ruby，我强烈建议你从第14章“脚本编程与系统管理”读起，因为学习一种编程语言的最佳途径就是从现在开始用它，每天都用。

*

诚如Martin Fowler所说，Ruby是一种神奇的语言。不论你是被这种神奇的语言本身所吸引，还是为了赶上Rails的热潮而学习Ruby语言，本文所介绍的三本书应该就能满足你的需要。其实除了Rails之外，Ruby的世界里还有众多的“红宝石”闪烁着迷人的光芒，但愿这几本书能帮你发现更多“铁道下的红宝石”。最后，就祝你阅读愉快、编程愉快吧。

(转载)RubyWorks入门指南

（抄袭Giive Chen的RubyWorks 0.0.1Release，感谢Giive的帮助^_）

如果你覺得安裝所有的 Ruby on Rails 相關套件，並且將 Production Server系統設定好是一件很麻煩的事情嗎？或許你可以試試看RubyWorks。

RubyWorks是一個在 Red Hat Enterprise 或是 CentOS 上面的套件組合，他會幫你把所有 Production 環境下面的相關的Ruby on Rails 套件跟 Server 套件一次安裝完成，並且提供一個馬上可以跑的 defulat configfile，也就是說各位公司的技術長們不需要花時間去看那麼多 Production 設定方式，你已經有一個很堪用的 ProductionRuby on Rails Server了。

So，你還有理由不玩 Ruby on Rails嗎？

我們看看怎麼安裝 RubyWorks，因為我沒有 Red Hat Enterprise Server，所以我只 Test CentOS。

前置作業

RubyWorks 因為好像還沒進去 yum 資料庫，所以我們還是得必須告訴 yum 哪裡有 RubyWorks 的 Package，如果已經進去yum repo了，就好像不需要這個動作了。

如果你像我一樣，是個不求甚解，只求可以 Work 的人，就這樣打就好了。

wget http://rubyworks.rubyforge.org/public_key.txt

sudo rpm—import public_key.txt

wget http://rubyworks.rubyforge.org/RubyWorks.repo

cp RubyWorks.repo /etc/yum.repos.d/

• RubyWorks 網頁
• RubyWorks 0.0.1 Released

不用说（或者随便怎么说）

今天在敏捷西安做了关于RubyWorks的演讲。在准备讲稿的时候，随便乱看，就看到了孟岩以前的一个blog：动态语言，别再说不。

“国外的大气候和国内的小气候都有共同特点，就是站在传统技术立场上的人对于RoR的火爆看不下去了，首先站出来发难，从而引发Ruby支持者们的回击，然后双方厮杀在一起，连带旁边相干不相干的看热闹的、拉架的、含沙射影的、慷慨激昂的，瞬间就浩浩荡荡，横无际涯了。而争论来争论去，无非还是Ruby的性能问题、可用性问题、前景问题，等等等等。”

孟岩的态度——如果我没理解错的话——是在劝解大家，不要随便怀疑新生事物，新生事物旺盛的生命力是能够克服一切困难的，要对新生事物抱有希望。而我（现在）的态度是，我不劝说谁。不是怀疑性能问题吗？我们做出唾手可得的高性能部署环境放在这儿。不是担心跟遗留系统不方便整合吗？我们把遗留数据库和消息系统的问题都解决掉。不是没有看到成熟案例吗？我们就来做成熟案例。

既然对它有信心，那就动手把所有的怀疑都打消掉。人们怀疑什么，我们就解决什么。

至于教育大众的事情么……我很相信，我们只要教育“小众”——多半是“大众”们的老板——就行了，“小众”会帮我们教育大众的。

所以孟岩希望大众“别再说不”，我的态度是，大众随便怎么说，我无所谓。

Rails部署：反向代理优于FastCGI

RubyWorks采用了基于反向代理和Mongrel的部署方案：HAProxy把请求代理给不同的Mongrel实例。在InfoQ中文站的报道中写道：

“RubyWorks项目领导人Alexey Verkhovsky也认为，只有在对节约内存使用非常重视的情况下（例如虚拟共享主机），FastCGI才有其价值；而在普通的企业应用中，可靠性和可管理性重于节约内存，这也是RubyWorks选择基于反向代理和Mongrel的部署方案的原因。”

在《Agile Web Development withRails》的第一版中所推荐的部署方案是基于FastCGI的，而第二版则改为推荐基于反向代理的部署方案。James Duncan Davidson在书中写道：

“ 简而言之，FastCGI确实是一枚火箭，但有时会因为各种奇怪的原因而爆炸在发射台上。使用代理让Rails应用直接与HTTP对话，这是整个社群的发展方向。”

即使在DreamHost这样的shared host上，FastCGI也给人们带来了种种困扰，这也是Mongrel（以及相应的，反向代理的部署方案）流行的原因。另一个Rails服务器Swiftiply号称比Mongrel更高性能，不过伸缩性方面都是线性的。