Create RPM For Your Rails Application
April 29th, 2007
Now you can create RPM package for your Rails application fairly easily. Here are the instructions:
- Install and config rpmbuild. (You may wanna read an RPM Tutorial.)
- Install rpmpackager plugin:
ruby script/plugin install \ http://rubyworks.googlecode.com/svn/trunk/rpmpackager/
- Config rpmpackager plugin. Edit vendor/plugins/rpmpackager/config.yml as following:
configuration: # name of your application app_name: rubyworks-dogfood description: This is dogfood of RubyWorks. license: Apache version: 1.2.1 release: 1 # RPM dependencies. separated with commas dependencies: openssl, mysql >= 5.0 # gem dependencies and installation indecies # 0 for gems don't need selection gems: redcloth: 0 rcov: 1 - Create RPM package:
- rake rpm_package
- (By default the generated RPM will install your application to ”/usr/local/lib/rails-apps/#{app_name}”.)
That’s it. Package your application and throw it to deployment :>
（不愿被代表的）我们在做开源
April 29th, 2007
轻量级AJAX框架Buffalo 2.0:性能提升30%
Buffalo在经历了两年之久的考验后，近日正式发布2.0版本。Buffalo是一个J2EE轻量级AJAX框架，也是国内著名的开源项目。它与DWR 和JSON-RPC一样，着眼于Web远程调用(Web Remoting)，其简洁而实用的特性一直以来深受开发者喜爱。在国内，对JavaScript技术深入研究的人可谓凤毛麟角，Buffalo的作者陈金洲 (Michael Chen) 就是其中之一。
采访XRuby开发者
郑晔说：“XRuby本身起步时，考虑得更多的是乐趣，参与者都是因为乐趣加入其中的。所以，我想说，XRuby的一个很大的优点就是它还年轻，其中有很多可以做的有趣事情。短时间之内，我们不敢奢望有人可以把XRuby用于实际的项目。现阶段，我们只是希望赢得更多的关注，吸引更多的人加入到XRuby的开发中来，这样，可以尽快实现XRuby的目标。”
还有CruiseControl。
还有CruiseControl.rb。
还有Selenium。
我们不是什么“开源人士”，也不愿被谁代表。我们还在做开源。因为我们相信，千里之行积于跬步。
知识库｜只言片语｜互联网式写作
April 28th, 2007
ChinaonRails果然与众不同：别的地方发帖子攒积分，这里发帖和回帖要付出积分的。
认真想了一下这个事情。望勤说是要建立活的Rails知识库。既然是知识库，和论坛本就不同，更鼓励贡献知识而不是参与讨论。只要把有趣的东西给出来，看的人自然会有收获，不需要更多讨论——至少我猜望勤是这么想的。而且按照积分规则，字数越多需要付出积分越多，所以王大力发的都是只言片语，简单两句话加上链接。无疑这是被规则所鼓励的风格。
只管说，不管解释。
只言片语。
不啻是麦克卢汉的风格。问问麦克卢汉的风格从哪里来，他说来自詹姆斯·乔伊斯。乔伊斯的文字素以信息量巨大、链接丰富、难以解读而著称。《尤利西斯》如此，更不用说《芬尼根的守灵》。最近时常在想，也许乔伊斯的文字原本就不是为印刷时代而写的。放在超文本的互联网上，《尤利西斯》是否能逃脱“晦涩难懂”的评语？在互联网的写作中，链接就是内容。拼凑链接的写作，反而比精心堆砌的文字更有意义。）
（所以顺便请求互联网上的剽窃者们，在照搬别人文字时至少真正做到“照搬”。链接不那么重要吗？也许，当文字被印在纸张上时。但在互联网的写作中，链接就是内容。）
中国上铁道
April 28th, 2007
蔡望勤重开了中国上铁道。ChinaonRails是一个关于Rails的论坛，各种元素都相当的2.0。望勤有了自己的老窝，就不在其他地方回答Rails问题了。
还有一个讨论：聊聊Rails在国内的现状。有一些著名的网站（例如铁道播客）关闭了，有更多的网站冒出来。今年的铁道中文报告会是什么样呢？铁道之路，任重而道远。
HAProxy -> Mongrel -> Rails
April 24th, 2007
这是一个高性能、高伸缩性的Rails部署方案。有一组性能数据可供参考。
首先接收到HTTP请求的是HAProxy。HAProxy会把请求反向代理给其后的多个Mongrel实例。每个Mongrel实例同一时间只处理一个请求。只要Rails应用本身贯彻无共享架构，就可以直接通过增加服务器和改变HAProxy配置得到线性的性能提升。另外可以用Monit来管理Mongrel实例的开启和关闭，并且在异常状况发生时及时采取措施。这样一来，企业级超复杂所暗含的性能、伸缩性、可管理性等等要求都满足了。
“HAProxy is a free, very fast and reliable solution offering
high availability,
load balancing, and
proxying for TCP and HTTP-based applications.”
“Mongrel is a fast HTTP library and server for Ruby that is intended for hosting
Ruby web applications of any kind using plain HTTP rather than FastCGI or SCGI.”
“monit is a utility for managing and monitoring,
processes, files, directories and devices on a UNIX
system.”
（今天下午和George讨论的主题：我们已经听厌了“企业级”这样的大帽子。我们需要做的是弄明白所谓“企业级”究竟代表什么，然后把解决方案拿出来。基本上——如果真的喜欢“企业级”的话——这就是所谓的“企业级Rails”了。）
教育大众还不如看看电影
April 22nd, 2007
孟岩永远是那么忧国忧民，动不动就要把工作赚钱的事情上升到教育大众的高度。不过我真想问问孟岩，你到底要跟“大众”去沟通什么呢？猛禽把自己对开源的理解简明扼要地整理出来，孟岩你自己睁开眼睛去看看，开动脑筋去想想，你想沟通的“大众”，他们能看懂、想看懂这样的一个blog吗？你就别再骗自己了，这些“大众”连在苏宁电器买台电视机都不知道自己究竟接受了什么合同，你还跟他们说得上什么开源协议？
但是专业人士一直在和大众沟通，一直在教育大众。对自己的工作缺乏自信吗？我会建议你去看梅里尔·斯特里普《穿普拉达的女王》，好好倾听剧中米兰达的下列台词：
“你 身上这件松垮的蓝色绒线衫，不仅仅是蓝色。它不是宝蓝色，也不是湖蓝色，而是天蓝色。2002年，奥斯卡设计过一系列天蓝色的晚礼服，然后——我猜——是圣罗兰设计 出天蓝色的军式夹克衫，之后天蓝色就成了其他8位不同设计师的最爱，然后放入其名下的商店，最后慢慢渗入可悲的Casual Corner，才让你从她们的打折货中淘到。简而言之，那蓝色值几千万和数不尽的心血。滑稽的是，你以为是你选择了这个颜色，让自己远离时尚界，事实却是这屋 子里的人帮你从一堆衣服里选了这件绒线衫。”
所以这是给孟岩以及给我自己和所有ThoughtWorkers的忠告：如果你仍然认为自己是最优秀的专业人士，就不要再徒劳地去谋求与“大众”的对话。你应该做的是影响那些站在经济体系金字塔顶端的人，然后社会的自发力量——感谢资本主义——会在适当的时机以适当的方式将你的意见散布给所有的大众，让他们无知无觉、自觉自愿地接受你、跟随你。
当然，撒泼骂街、声嘶力竭地与大众对话，这样的角色自有其存在的价值。但，如果你能够做一个最优秀的专业人士，还请你珍惜资源，别放低自己的身段和该有的专业形象。
信号：Erlang正在靠近中
April 21st, 2007
很早就有朋友在研究Erlang，但一直认为这只是一场茶杯里的风暴，没有投入精力去关注。
最近的信号是，PragmaticProgrammers出了一本《Programming Erlang》，同时还有一篇文章介绍。照以往的经验，PragmaticProgrammers从来不做曲高和寡的书。因为这个信号，我决定花一点工夫去了解一下。找到了Erlang China这个讨论组，另一个网站Erlang-China.org不知何故不能访问了。
Ruby on Rails走向企业
April 21st, 2007
我的标题不是一个问句。因为我已经相当确定，Ruby on Rails走向企业是早晚的事情。
已经有太多的讨论围绕着“用Rails要快多少多少倍”展开。但是，对于企业级超复杂来说，开发的效率只是一方面。至少还有其他几个方面是必须关注的。
- 非功能性需求，也就是软件的-ilities：性能，并发吞吐量，伸缩性，安全，等等。
- 完整的生命周期支持：需求，设计，开发，配置管理，质量保证，部署，维护，升级。软件生命周期的各个环节是否有适当的工具和/或最佳实践来覆盖。
- 系统整合。与遗留系统是否能够协同工作。这主要体现在两个方面：（1）消息系统；（2）遗留数据库。
实际上动态语言早已在各种企业IT系统中扮演胶水的角色，一些成熟的组织早已认识到它们并不止是急就章拼凑软件的法宝。动态语言本身的特点使得它们能够相当漂亮地描述各种领域，这正是为何Rails只会在Ruby上出现的原因。
至于前面提到的、企业级超复杂所看重的三个方面。结合Apache、Mongrel和HAProxy的部署方案已经被证明具有轻松超过任何J2EE应用服务器的性能和吞吐量，无共享架构使其具有完全线性的水平伸缩能力；至于安全性，Unix本身就已经构造了完备而可靠的安全体系。在今年的RailsConf上，我们将看到关于“如何部署高性能企业级Rails应用环境”的产品和最佳实践。
在生命周期方面，我们已经有了CruiseControl.rb和Capistrano；我们即将看到Mingle的正式亮相，以及基于这些工具的最佳实践。系统整合或许是目前最不明朗的一个领域：我们有ActiveMessaging，我们有复合主键支持，但是很明显这离着“方便的遗留系统整合”还有相当距离。在未来的一年中，这可能是“企业级Rails”最有看头的一个领域。
总而言之，不难看到，即便是对于企业级超复杂的要求，Ruby和Rails也已经做好了——至少是大部分的——准备。即便客气一点不说“Rails比J2EE还要适合企业使用”这样的话，对于那些愿意承担一定风险来提升IT效率的企业而言，是的，Ruby和Rails整装待发。
Performance Review再次开始，以及相关随想
April 19th, 2007
一年两度的performance review，现在开始的是2007年第一次。这是我在ThoughtWorks最喜欢的事情之一，因为有那么多人给我提意见，告诉我什么地方做得不够好。
关于ThoughtWorks的performance review，敏捷中国有一个讨论串值得一看：敏捷开发中的绩效管理。摘录我自己的一段话：
“大家都明白，指出别人的不足之处是为了帮助别人成长和自我完善，而不是互相打击。就我个人而言，溢美之辞我听得太多了，但除了ThoughtWorkers之外没有别的人能如此直接而准确地指出我的缺点，这些对我帮助非常大——我把上次review收到的批评意见打印出来，过去的半年里一直放在书包里，随时提醒自己。就像我经常说的，一个好的批评者是一笔宝贵的财富。”
那一次的批评意见，确实是前所未见的尖锐，刚才和Michael（Robbinson，我的sponsor）聊天也说到这件事。另外还说到的是“craftsmanship”和“journeyman”——在《软件工艺》整本书里，我最喜欢的两个词就是“reputation”和“journeyman”。我自己想做的，就是这样一个journeyman，旅行，学习，成长。我最想要的，是和那些master们一道工作，并在那之前做好准备向他们学习。
每次的performance review，总让我看看自己是不是还在这条路上。迄今为止，走得还算稳。
歪理斜说：放弃的才是拥有的
April 15th, 2007
我用上Ubuntu以后，经常劝别人也装。别人经常会说：“那我以前硬盘上积累的那么多东西不是都……”黄亮也拿这个当借口，拒不升级到7.04。而我是一直保持更新的，即使会冒着有时候突然不能启动的风险。
因为在前后几次重装系统之后，就得出了一个理论：只有放弃过的，才是真正拥有的。
比如硬盘上那么多东西，似乎觉得总有什么时候用得上，其实只是堆在那里白白占着空间。只有整理过以后，才知道哪些是应该刻盘的，哪些是应该放到网上去的，哪些是应该印出来的，哪些是应该删掉的，以及哪些是真正应该留在硬盘上的。
还有书。多年前压箱子底的书，搬几次家以后也许还在压箱子底，却还是一次一次不辞辛劳的搬来搬去，心里暗想“说不定哪天就用得上”。其实以这样的概率，需要用的时候再买一本，也比来回搬的力气划算。（当然，书还有装饰房间的作用，所以上述评论只适用于“压箱子底”的书。）
还有工作经验。还有别的很多。
总而言之，舍不得放弃就不知道自己拥有，就只是杂乱的一大堆；放弃过，才会拥有真正有价值的。
歪理斜说：不存在的体系
April 15th, 2007
InfoQ中文站：统一过程之父叫停新过程
“作为解决方案，Ivar Jacobson认为我们应该交流实践，而不是过程，来自团队自己的软件过程的构造块是可以装配的。实践的描述是可以独立描述的，描述可以在过程中共享，因此这个团队与别人的过程上的异同就很容易看出来。”
以前关注语言学的时候，我有一个理论（这句话将被作为“歪理斜说”系列的标志_）：所谓“语言的体系”是不存在的，存在的只是词汇、以及词汇的用法。譬如说，可能很难找出“英语的语法”这种东西，它是融入到词汇当中的。同样，对于——至少某些——计算机语言，语法本身是不重要的，重要的是其中的词汇可以如何使用。LISP、Smalltalk和Ruby都是这方面的例子。
还有别的例子。例如Martin Fowler说“业务逻辑就是业务没有逻辑”。所谓“业务逻辑的体系”，大抵就是一个你希望套用但基本上一定会套用错的体系。还有敏捷。开大会说“我们要实施敏捷”或者“我们已经实施了敏捷”都是没有意义的，相比之下迭代的周期和有没有持续集成显得更有参考价值。这就是Ivar Jacobson说的，“过程已经讨论够了，多说点实践吧。”
* * *
关于“歪理斜说”的补充说明
人的眼睛都是会选择性失明的。我们看见我们想要看见的。换句话说，当你有一个理论时，你总能找到论据来支持它。
但即便如此，如果你每周都能冒出两三个理论，其中总会有一些比较好玩的。
这就是“歪理斜说”的由来了。好玩的理论，就算是歪理谬论，扔掉了也怪可惜的，不如就收集起来吧。
（本来还想说“如果相信，责任自负”之类的话，不过细想想，其实别的文字又何尝不是一样呢？）
Create A Yum Repository
April 12th, 2007
- Build your RPM packages. Refer to “Maximum RPM”. Assume you put your RPM packages in /path/to/RPMS/i386/*.rpm
- Create a yum repository.
- cd /path/to/RPMS/..
- createrepo RPMS
- (Now there should be a /path/to/RPMS/repodata directory.)
- Publish your repository. I wanna publish it via Apache, so I do following:
- ln -s /path/to/RPMS /var/www/RPMS
- (Browse http://localhost/RPMS, there should be “repodata” and “i386” directories.)
- Enable your repository in client machine. Edit /etc/yum.conf file as following:
[main] cachedir=/var/cache/yum debuglevel=2 logfile=/var/log/yum.log [my-repository] name = My Repository baseurl=http://localhost/RPMS gpgcheck=0
Here we go! Invoke “yum list” and you should able to see all RPM packages you built.
歪理斜说：优秀的都是病态的
April 12th, 2007
我有一个理论——好吧，我有很多个理论，其中之一是：一切优秀的，都是病态的。
实际上这只是同语反复，因为按照定义我们把“与大多数人相同的”称为“正常的”，而出类拔萃的，就像先天不足的一样，是“异常的”，因此是病态的。（ThoughtWorks给应试者所写的代码的最高评价就是“exceptional”。）和白痴一样，天才也是病，只不过表现的形式不同。
就好像，最优秀的企业对于产品质量有病态的偏执。
就好像，最优秀的团队对于自己的文化和工作方式有强迫症，一旦偏离就会表现出躁狂症状。
就好像，最优秀的人会坚持自己的习惯和要做的事情，几年不变。
一切优秀的，都是病态的。就好像我太太说的，“你们公司的人都不太正常。”
不稳定，才伟大
April 9th, 2007
博弈论告诉我们，一群优秀的员工，在公司没有严格监管的情况下自觉地为公司尽力，这是对双方都最有利的一种局面。问题在于，第一，这是一个信任博弈；第二，这是一个非常容易搭便车的博弈。所以，博弈论指出，这样的情景虽然好，但它是不稳定的，因为懈怠的搭便车者会从中获益，并最终导致所有人懈怠，迫使公司不得不严格监管。
不过，不稳定并不等价于不可能存在。
广义来说，系统趋于稳定的过程即是熵增加的过程。所以，只要能够不断注入足够多的能量，就可以对抗熵增加，使不稳定的状态得以保持。Google，趋势，腾讯，ThoughtWorks……所有拥有精彩文化的团队，都是因为其中的每一个人不断地注入能量：拒绝懈怠，为团队做多一分贡献，装扮自己的办公室，参与招聘流程以免懈怠者混入……精彩的文化不是从天而降的，是靠一张张贴纸、一个个玩具积累起来、维护起来的。
精彩的文化总是不稳定的，博弈论的原理已经证明了这一点。所以，更应该珍惜，更应该用心去维护它。
几种常见的博弈形式
April 9th, 2007
协调博弈：在这种博弈情景下，局中人都希望别人知道自己将要做什么，最大限度的合作与信息分享将为所有人带来最大利益。典型的例子如交通灯博弈。
信任博弈：局中人如果互相信任，则会双双获得最大利益；任何一方的怀疑会使双方都遭受损失；就连怀疑对方可能怀疑自己也会招致损失。
猜硬币博弈：只要猜出对方的意图就会赢（并且让对方输）的博弈，其要点在于隐藏信息。
斗鸡博弈：比较非理性的人会赢的博弈，如果你不能证明自己比对方更加非理性，可以考虑切断自己的退路。斗鸡博弈中的玩家应该欢迎对手打探自己的情况。
固定和博弈（或者零和博弈）：一方的收获意味着另一方的损失。在某些时候甚至会成为负和博弈，因为赢的一方也因为不断压迫对方而感到心理不快。
迈向敏捷的第一步
April 7th, 2007
［以下内容来自一封私人邮件］
从最容易实践的技术层面上，我推荐你依序做以下事情：
0. 源代码配置管理（CVS或者SVN，很可能你们已经有了）。
1. 严格的签入／签出管理制度：做任何任务之前必须checkout/update到最新版本，完成任务之后必须立即checkin到代码库。
2. 自动化构建：用Ant/Maven/NAnt/Rake/Make……编写项目构建脚本，并把构建脚本也checkin到代码库。自动化构建的目标：在一 台新的机器（安装了一些基本的平台例如Java）上checkout完整的源代码之后，能够用一条命令完成编译、链接、打包、部署等所有步骤，得到一个可 工作的软件。
3. 持续集成：安装持续集成服务器（推荐CruiseControl.rb），让它监视你的项目，在每次checkin发生之后立即执行自动化构建脚本，确保项目能够完整构建。如果构建失败，所有工作必须停止，修复之后才能继续checkout/checkin。
4. 加入测试：在发现bug时，首先编写测试来重现这个bug；修复bug之后应该保证测试通过。把测试代码也放进代码库，并在构建脚本中执行所有测试。此时你的持续集成环境应该也开始执行测试。
5. 测试驱动：开始实现任何新功能之前，首先编写测试来描述自己要做的事情，然后编写代码让测试通过。
如果你能够成功做到以上5个（或者说，6个）步骤，你就迈出了成功的第一步，软件的质量会有效提升，响应需求变化的能力也会有效提升。那时我们可以继续探讨以后的步骤。
英雄汇，会英雄
April 6th, 2007
在2007软件技术英雄会上，见到很多老朋友和新朋友。CSDN，尽管对它有种种意见和挑剔，但仍然认为是一个伟大的事业。蒋涛最令我佩服的，便是这份坚持。自己相信正确的事，就一直坚持去做，不断地去影响别人。多年的坚持终于有了今天的成就。
五年前的情景就像还在昨天。那时侯老师表扬唐琦，说台湾二十五六岁的年轻人往往没有这份干练。转眼间我自己都已经走向二十七岁，唐琦还是那么活跃。扪心自 问，虽然没有做成什么事，至少还是坚持了自己，没有做亏心事，算是对得起自己吧？但毕竟还是没有做成什么事，也是因为不够坚持自己的想法，只白白浪费了那 些好点子。
终于见到了仰慕已久的李日贵（Jini）。周老师说他和我长得像，没料到果然有几分神似——表情都够SUI。听他描述台湾的种种，动心想去旅游一番了。
明天一早去爬长城。上次去八达岭是十多年前的事了，该去充充好汉，和众多英雄一道。
给Typo装上Rich Editor
April 3rd, 2007
找到一个rich editor，给我的Typo装上，现在编辑文章方便多了。
还是自己做blog比较好，需要什么可以自己动手。别了，BlogDriver，我想这次是真的搬迁了，因为完全可以自己控制。
（说实话，希望不需要我再修改什么。如果还需要的话，就得架一个svn才行。）
第八号当铺
April 3rd, 2007
某人说，如果真有第八号当铺，一定会去典当。
幸亏没有。
因为有边际效用递减律。多多的幸福，因为边际效用递减，会想要拿去换别的东西。用爱情去换钱，用身体去换事业成功。因为没有一般等价物也没有市场参考价，交换的时候根本不知道自己到底有没有亏、亏了多少。
更糟糕的是还有永远无法战胜的熵增加定律。交换得来的东西渐渐的变得没有价值了，想要换回去的时候，已经不能再换，或者只能狠狠地折个价。
所以，这样的当铺，大概只能让绝大多数人感到更遗憾、更后悔、更不幸福吧。就像改变历史的能力一样。
只有当下才是值得珍惜的。日日是好日。CruiseControl.rb 1.1 Released
April 3rd, 2007
CruiseControl.rb发布了1.1版本。主要的特性包括：
- 如果Builder出错，项目会继续轮询build。
- Build页面上左边的历史列表只显示最近30个，更多的build放进下拉列表框。
- 可以用daemon模式运行（不支持Windows）。
- 升级到Rails 1.2.3。
还有，我的名字出现在“核心团队”名单里 :>
