Looking forward to change

最后还是选择了去参加ThinkInLamp的活动，平稳顺利的完成了Sam交待给我的任务，主持了整场会议，没有出现什么大得纰漏，过关，呵呵

今天得收获，以及会议中引发得思考很多，感悟也不少，首先是安居客的公司好强大，会议室也很强大，不愧是沪上最大最牛的房地产行业网站。而且今天的听众，有三分之一都是安居客的软件工程师。另外就是原来锅巴哥哥是我的老乡啊，他是阿克苏长大的，也是知青的下一代。其他相关内容，列个表在这里：

• 麦包包的RongRong友情赞助了很多小礼品，还有现场宣传小册子，发现它们的包包很不错，价格还不贵，只不过我好像不是他们得目标消费人群。
• 这次活动得所有主题是之前在网上6选4票选出来得，结果很洗具，2个技术话题被淘汰，4个非技术话题入选，这也反应了IT技术人员得普遍诉求，每天都在玩技术得人，其实对非技术领域得一些东西，往往更加有兴趣，呵呵。
• 第一个分享嘉宾Sting是一个非常睿智得人，很善于独立思考，而且总结能力很强。我在不同得场合听过他讲过不同得东西，有web2.0创新，创业公司发展，技术人员自我提升，以及产品研发，项目管理等等。我理解Sting得核心思想始终围绕以人为本，这次讲技术团队得发展路径和陷阱也是如此。一个团队从组建到成熟到成功，是一个漫长得过程，会经过几个典型得阶段，不过在QA环节，大家最感兴趣得，仍然是第一个环节，如何招聘以及面试，呵呵。
• 第二个分享嘉宾板子，25岁，工作三年，给大家讲得主要是职场感悟。我发现板子同学非常有潜力，PPT做的可圈可点，内容丰富，而且风格诙谐幽默，演讲过程中得发挥也很出彩，属于那种非常有潜力得类型，如果板子也加入我所在得TMC组织的话，只需很短得时日，他得演讲水平，功力一定会在我之上。
• 锅巴哥哥太神了，这位哥哥在Oracle/MySQL两种数据库领域颇有建树，他走得是底层路线，拨开数据库引擎盖，直接解剖底层实现，研究数据库内核得结构和算法，并以此为基础进行针对性得调优，强啊。另外锅巴哥哥准备在ThinkInLamp得活动基础上开辟一个MySQL分支，专场讲解MySQL方面得内容，预计会在9月底10月得时候举办，我打算在自己得shanghaionrails社区推广下，因为这个太靠谱了。
• 演讲嘉宾张博超和腾振宇两人来自同一家公司，而且讲得内容都跟敏捷开发有关，一个是理论，一个是实战，于是他们两个人合计了一下，就把两个演讲二合一了。于是乎这场演讲就变成了大家群体玩一个叫做《Innovation Game》得游戏，而且这个集体游戏让大家玩得很high，之后大家一起进行分析，总结。我很欣赏这种演讲教学方式，获益匪浅。
• 腾振宇不愧是国内第一个注册敏捷教练，站在讲台上很有范，语言抑扬顿挫，停顿，肢体语言等演讲技巧运用得炉火纯青，牢牢抓住了大家得注意力。敏捷开发相关得理论以及方法学，涉及范围很广，而且偏理论，偏抽象。腾振宇非常善于利用生活中一些实例来隐喻敏捷理论，浅显易懂，赞！
• 最大得收获是通过游戏，深刻理解了Queue理论，特别是在团队中，如何切分/拆分任务到一个合理得粒度，才能得到最优工作效率，如何优化才能帮助客户创造最大价值等等，敏捷是一门讲究实惠得艺术啊～
• 当然了，会后得饭醉活动是另外一个亮点
• Sam一直跟我讨论创业话题，看来他是义无反顾要走上这条路了，身边得朋友一个一个都去创业，或者正在准备去创业了…

缘起：Ruby Tuesday是一家著名得美食餐厅，Ruby Tuesday是The Rolling Stones得一首歌曲，Ruby Tuesday是台湾得 @ihower 举办得一个技术活动，是一个非常不错得活动，而且@ihower从2007年就开始一直坚持把这个活动办到今天。上次RubyConf上，跟@ihower聊起这个，当下就决定要在上海也把这个活动搞起来，结果这事穷喊了一个多月，直到今天

事情还有另外一个起因，吴江同学（网上id @masterwujiang，又名花花）将出席8月底在日本举行的Ruby kaigi大会（全世界最大的Ruby大会），并作一个三十分钟的主题演讲，题目是《Rails to Sinatra》。本次活动是吴江的一次Preview，吴江将为大家作一个预讲，并现场收集大家的意见，并继续改进。

这次得活动名为RubyTuesday，但却是在周四举行，时间是晚上7点到9点，地点是我熟悉得一家咖啡厅，布那咖啡，地点在上海图书馆对面。

因为是第一次筹办这次活动，没有指望有太多人出席，结果铁杆朋友都到了，甚慰。这次出席会议得人有：

• 吴江（@masterwujiang）本次得主题分享嘉宾，三年的Rails程序员，当第一次遇见Sinatra之后就深深爱上了Sinatra，并提出了Off Rails得概念，至于到底Off Rails灵不灵，拭目以待。
• 黄智敏（@flyerhzm Richard Huang）资深Rails程序员，现在就职于易空海，关于Richard本人都不需要介绍了，在上海得Rails圈子已经是无人不知，无人不晓，而且Richard最近作了一个叫做Rails Best Practices网站，非常赞。
• 李飞雄（feixiongli@gmail.com）跟Richard是同事，一年陈得Rails程序员
• 罗小能（@lxneng）前在合家网程序员，专攻Python。现在开始作Rails开发，并把很多Rails Best Practices翻译成中文。
• 郑伟（@miclle）罗小能得同事，工作三年，专攻前端开发，帮助Richard得Rails Best Practices项目开发了前台。
• 黄孜扬（ngty77@gmail.com）来自新加坡，因为女友在中国，所以到中国来工作，主要作一些ruby和rails远程工作，Linux大牛，也是老大哥级得人物（大我5岁），帮助Richard得Rails Best Practices项目提交了很多测试
• 蕲春人（@qichunren）来自赵勇在线得Rails程序员。
• 梁文科（@liangwenke）来自赵勇在线得Rails程序员。
• 郑炳南（femtowin@gmail.com）原来供职于淘宝，现在创业作ruby/java培训。
• 还有我…..

收获最大得应该是吴江。其实本次活动得宗旨就是拍吴江，越是板砖横飞，把吴江拍的越狼狈，对他越有好处，不过好像除了我，其他人提出意见时都非常照顾吴江得面子，特别委婉，呵呵。来自新加坡得黄孜杨，非常善于拿捏把握吴江演讲中不足得地方，提出得意见非常有价值，而且还特别善于运用隐喻。我呢，因为长期混迹于TMC，所以小小显摆了一下，特别针对演讲技巧层面提出一些建议，希望吴江能从中有所收获，到时候代表中国Ruby程序员，更代表他自己作一个出色得演讲。

这次活动不仅仅只有吴江一个人获益，大家通过这次活动结交朋友，联络感情，并商讨互相感兴趣得话题，每个人都献计献策，讨论出一套继续举办RubyTuesday得方针策略，呵呵，毫无疑问这个活动就必须继续坚持下去，而且一定会更好。

Shanghaionrails第七次线下活动于3月20日，也就是上周六如期成功举行。

这周二才拿到会议照片（感谢Terry拍照），加上本周工作非常繁忙，一直到现在才有空闲记录一下活动后记，因为想要记录下来的东西很多，所以我打算写两篇，第一篇主要记录一下整场活动，下一篇我会着重介绍一下活动的筹备过程，花絮，特别剪辑以及导演评论音轨等…

这次活动跟往期活动不同，这次活动我们没有去租用昂贵的专业会议室，而是把活动场地安排在了5173公司的一楼咖啡厅，这里我想特别感谢为我联系活动场地的dlee，以及5173方的负责人尚贤琨和段萌，还有5173对这次活动的大力支持。

Shanghaionrails技术社区风风雨雨已经走过了两年半，自己也是从社区一步一步成长起来的，这次活动对我来说也有特别的意义。因为另外两个社区创世人元一和Stephen忙于自己的事业，这次活动的筹划落到我一个人身上，所以我最大的心愿就是一切都能顺利，能带给大家一次记忆深刻的活动。后来活动结束后，我收到了来自很多朋友的好评，感谢，鼓励的消息，非常欣慰。为什么大家认为这次活动很成功，我认为有下面几点：

场地好

这次活动的场地非常赞，筹备阶段5173的段萌就不停问我，还有什么不满意的地方，以及需要改进的地方，你跟我说，我帮你想办法，我回复到没有什么不满意的地方，其实心里却在想，这可是shanghaionrails线下会议有史以来场地最棒的第一次！

参与人数多

我统计了一下，这次活动有超过70人参加，超过了我开始的预计，40～50人规模。远的有来自杭州，无锡，南京的朋友，更有来自成都专程坐飞机过来的Terry，不过最远的要数来自美国的Vinnie，呵呵。中间大概三分之一的人以前参与过我们的线下活动，其他的都是新朋友，这意味着社区的规模在不断发展，不断壮大，欣喜。

来自USA，Factual的Vinnie

主题演讲好：

这次演讲的主题是经过精心安排，质量很高，四个演讲全部来自一线Rails公司，特约演讲嘉宾全部是项目一线的资深程序员，因为身处项目中，自然有东西讲出来，含金量自然非常足啦。

第一个演讲来自Factual，主题是JS2以及JSAPI。Factual是我的前雇主，所以我敢说自己对Factual的技术有一定的理解。Factual是一家成立于美国硅谷的技术创新公司，致力于开发下一代互联网底层数据服务平台，在技术上，Factual有自己非常独到之处，而且有非常宏大的前景。演讲分为上下两个部分，分别由我的好友加前同事Leon和吴江带给大家。Leon的演讲从JS2对JavaScript的语法特性扩展开始，深入解释了JS2的运行机制，这里的JS2，是Factual为了解决JavaScript在繁复的前端开发时效率低下，自行开发出的一套语言，编程框架，JS2是集Ruby，Perl，JQuery，Haml等等流行语言，框架的优点于一身，帮助程序员快速高效的编写JavaScript应用，具体细节可以看这里http://code.google.com/p/js2lang/，Leon的演讲引出了下半场Wujiang的主题：JSAPI，吴江解释了Factual的核心数据服务理念，并向大家演示了基于Factual的JSAPI如何能简单，快速的创建可高度定制的在线widget，以及如何跟强大的后台数据服务层交互，同时也展示了Factual基于JS2开发的一系列非常Cool，非常炫的东西。Leon和WuJiang的演讲引起了大家对JS2和Factual的极大兴趣。（这里我很想插一句，这次Factual仅仅介绍了JS2对JS的扩展，他们没有介绍的，还有一整套基于MVC的前端开发框架，以及完整的开发方法学，还有Factual后端的核心并极具野心的数据服务，不过没有关系，期待他们下次给大家带来更精彩的演讲）

演讲PPT连接：http://www.slideshare.net/jiang.wu/js2

来自Factual的Leon

来自Factual的WuJiang

第二个演讲来自南京赛威，主题是”When ERP fell in love with rails”，演讲者是Jason。Jason的演讲风格非常幽默风趣，他们是最早，也是一直坚持作Ruby&Rails培训的一家公司，这次演讲源自他们马上就要上线的一个ERP开发项目，Jason的演讲不是那种一开始就深入技术底层细节，而是就Rails的ERP和企业开发的宏观层面，大局观着眼。最先上来就给我们揭示了成功项目开发的真谛，就是如何跟客户“调情”。这里的调情其实就是指如何跟客户沟通，掌握一定的沟通技巧是项目成功的关键，Rails开发过程最适合引入敏捷开发方法学，而敏捷开发中最最关键的其实就是沟通。之后，Jason给大家介绍了基于Rails的开发中如何划分项目工时，如何将任务目标细分，比如按照日，甚至到细分小时，如果解决时间安排中的各种冲突问题，如何培养和凝聚团队士气，并捎带介绍了一下他们在ERP开发中运用的工作流管理技术，大家一致认为Jason的演讲最好玩，并富有创意。

来自南京赛威的Jason

第三个演讲是来自Intridea的叶玎玎，带给大家的是“NoSQL: Re-think about the world”，玎玎来自杭州，是intridea的资深程序员，我最近加入了intridea公司，也是基于这个缘由，我特意争取到了玎玎来作这次演讲。NoSQL是最近技术社区的热点，玎玎在这个领域有研究非常深入，但是这次玎玎给大家介绍的，并不是“不SQL”，而是Not Only SQL。玎玎给大家揭示了传统SQL在面对大规模应用时的一些问题，缺点，引出了NoSQL的解决方案，并详细介绍了现在开源Schemaless的数据库的分类，流派，发展趋势和在具体场景下，我们应该怎么选择开源的SchemaLess数据库，并介绍了数据库选型策略，即CAP原理。最后玎玎用Twitter作为真实的例子来给大家解释说明。玎玎的演讲，让大家对NoSQL产生了极大的兴趣，NoSQL也成了会议之后QA环节上被问及最多的主题。

演讲PPT连接：http://www.slideshare.net/sishen/no-sql-introduction

来自Intridea的叶玎玎

最后一个演讲是来自Ekohe的Richard，主题是“Static code analysis for ruby”。在介绍Richard时，我就提到，听演讲有三种态度，第一种是听了跟没有听一样，第二种是听了以后感觉这些自己都知道，所以感觉无所谓，嗯，至少你算是听了。第三种是听完后认真思考，并有所行动。第三种我最推崇，也最为佩服。Richard就是第三种人，他的演讲主题基于自己开发的一个ruby插件“rails_best_practices”，而这个插件的灵感，正是来自于去年10月份在首届kungfurails大会上，台湾的张文钿给大家带来的同名演讲。Richard的演讲前半部分把Ruby的静态语法分析原理解释的浅显易懂，并用非常直观的方式为大家演示了基于抽象语法树的静态语法分析技术。演讲后半段则是就具体rails最佳实践跟大家互动，Richard在介绍每个最佳实践前，会先行问大家，如果是你，你会怎么作？然后Richard在给大家揭示答案，每一轮下来，总能引起在场很多人的会心一笑，并博得阵阵掌声。Richard的演讲给我的收获最多。

演讲PPT连接：http://www.slideshare.net/flyerhzm/static-code-analysis-for-ruby

来自Ekohe的Richard

互动环节好：

两场演讲之后有个特别环节，就是给每个人一个机会，介绍一下自己，介绍一下自己所从事的工作。这个环节我最喜欢，也特别有意义，因为这个环节之后就是自由活动休息时间，如果你先行介绍了你自己，那么休息间隙，很可能就会有人主动来找你聊天，你也可以去找你感兴趣的人打招呼。这是一个双赢的环节，而且在这个环节中，我认识到了很多原来从来不认识，却一直奋斗在Rails开发一线的朋友。在休息的间隙，5173的朋友特意安排带领大家参观了5173的办公室。

在四个演讲结束后，开始头脑风暴，我作为主持人，提出很多比较有趣的话题，也让在场所有的朋友提出自己的问题，并且将解答问题的机会也留给了现场的朋友，话题从对之前的四个演讲的QA答疑开始，慢慢引向了Rails的发展新动向，Rails3等话题，现场讨论非常热烈。其中我印象最深的是如何吸引学生朋友投入Rails阵营，如何招聘，招聘大学毕业生的利弊，还有对Ruby语言的质疑，以及对社区发展的建议等等，我也顺便提出了自己对社区发展的愿景。在今年10月份，我们将迎来shanghaionrails的三周年庆典，届时我们一定要作的比现在更好，所以我需要社区的每个人的支持！原计划最晚不超过5点就结束的活动，因为讨论积极热烈，直到5点半才结束，之后大家集体合影留念。

意义深远

这次活动无疑非常成功，我不敢说我们的shanghaionrails社区组织已经跻身于一流的技术社区，相反，我们还差的很远很远。但是我们摆脱了相比Java，.Net等成熟社区，Rails社区总是徘徊在二流社区的形象，我们近乎成为上海的开源社区活动的马达，把开源社区的爱好者的心联系到了一起。关于这次活动的前前后后还有一些值得书写记录的东西，我留待下篇继续

更多活动照片，请访问这里：
http://www.flickr.com/photos/35439352@N04/sets/72157623554042647/

【时间】: 3月20号 下午1:00

【地点】: 普陀区云岭东路599弄汇银铭尊20号一楼咖啡厅（光复西路与丹巴路路口）

【交通】

• 地铁：2号线威宁路站下，4号口出，沿威宁路步行通过泸定路桥，到光复西路。
• 公交：推荐使用谷歌地图搜寻乘车路线。（ditu.google.com)

活动演讲者及主题

Jeff Su
CTO Factual.com
演讲主题: JS2应用

Jason Chen
架构师 南京赛威
演讲主题：When ERP fell in love with rails

叶玎玎
架构师 Intridea.com
演讲主题: NoSQL: Re-think about the world

Richard Huang
架构师 Ekohe.com
演讲主题: Static code analysis for ruby

报名方式

不设报名环节，到时候您人过来就可以了，free style!
注意: 40人场地，座位先到先坐，迟了就没了，不设贵宾席！！！

P.S.
另外，会议还增设一个自由讨论环节，将由主持人（就是我 ）来引领大家来一次2009年Rails发展点评，2010年Rails得展望以及Rails3前瞻，Rails社区得发展等方面得自由讨论/头脑风暴环节。

现在每个演讲嘉宾已经确定，各项组织筹备，推广活动已经开始，请大家奔走相告，说给身边作Rails得人，对Rails有兴趣得人，我们3月20日不见不散！

Shanghaionrails 线下活动每个季度举办一次，去年成功举办了一次线下活动以及两次大型活动（首届RubyChina conf以及首届KungfuRails China），杭州两次线下活动。Shanghaionrails是个小圈子，我们就是这样一种活动组织，定期聚会碰头，交流心得… 我已经等不及了，你还等什么？

-EOF-

第一次知道Joel，是在《程序员》杂志上。大概是2005年，《Joel说软件》 2005年9月出版，那个时候我在杭州，第一时间购得此书，赶上十一过节回家，来回飞机上8个小时，打发无聊时间，读的就是这本书。很少有哪一本书给印象我这么深，甚至连读书的场景都记忆这么深刻。那个时候，我的心态正矛盾在是否尝试一下转行投身软件开发。当时的我，对到底什么是软件开发，一点概念都没有，有的就只有刚刚萌芽的一个想法，给自己一个机会试一下，看看自己是否能转得过来。为了走这一步，每天埋头于各种技术书籍资料中，这本《Joel说软件》是唯一一本非技术书籍。

时间过的好快，弹指一挥间，2010年了，等到了今年4月20日，我作软件开发以满三年。照例会在那一天点评自己一年的工作，收获，所以今天不写，因为还有两个月，我仍然还有机会继续尝试一点不一样的东西，现在就写为时尚早。从上一版《Joel说软件》到第二版《软件随想录——程序部落酋长Joel谈软件》，5年过去了，我已经走在软件开发的道路上了，从当初的茫然到现在有了些许从业经验，开始从自己的角度看待整个行业趋势，有了一点自己的想法思考之后，这本书我读出了不少东西。

在1月初拿到，大概用了两周，每天上下班用断断续续的时间在地铁上读完的。地铁上一个人抱着书在哪里，看得正起劲，冒着随时会坐过站的风险的人也许不多了吧。因为内容太过吸引我了，于是每天上下班都成了一段短暂而美妙的旅程。我在豆瓣上看到很多人对这本书的评论，褒贬不一，不过整体看来基本符合正态分布曲线。大概80%左右的人，赞成其中80%左右的观点，少量反对以及驳斥，且不说我是否认同大家一致认为这本书不足的地方，单说大家普遍认同好的地方，我的看法也不尽相同，不过有一点是一样的，就是这本书读起来有一种阅读的快感。经常遇到这样一种情况，普遍得基本论调很难被大众认同，反而是那些阴谋论者的声音，哪怕那么微小得一点点，哪怕绝对数量少得可怜，但是却更容易被大众所关注，并更容易获得广泛得认同，比如那些内幕，独家披露，小道消息之流… 比如前些日子一条消息，大意是“淘宝关闭两家三钻专营手机得店铺，因为淘宝要推自己得淘宝商城”。八竿子打不着，经不起推敲分析得小道消息，至少在我的同事中获得了广泛一致的认同，呵呵。

读Joel得书，最好你应该先了解Joel是谁，他干过什么，他一贯抱持得观点是什么，这样，你就会更加容易并清晰理解书中得论点，而不会犯断章取义得错误。看到那些不知所谓得评论，就可以一笑了之了。Joel得网站和书中开篇就介绍自己，而且从各个方面多角度介绍得相当清楚。Joel的公司开发了一款叫做FogBugz的项目管理软件，书中很多提及开发与组织管理方面的内容都拿这个项目作为论据，刚巧在我目前就职的公司Factual.com的项目管理工具就是FogBugz。说实话第一次看到FogBugz，给我的印象就是UI界面好土，真的好土，让用惯了Mac，对软件交互界面以及UI的taste被惯坏了的人有点难以忍受，而且市面上那么多项目管理工具，开源，免费，任何一个都比FogBugz要强。当看过Joel在书中解释了非常多关于FogBugz背后的方法学，以及产品理念之后，加上三个月实践下来，我对这款产品真得非常满意，他很符合技术人员对项目管理工具的直觉和认知，功能设计相当体贴，虽然UI界面不那么惊艳，却符合最小惊讶原则，是最不容易让你产生视觉审美疲劳，是最耐看的一种UI设计策略。每天的日常工作，围绕着FogBugz，也帮助我更深体会到了Joel在书中提及的那些软件设计方法论以及如何去指导实践。

Joel是在说道理么？这个世界上聪明人这么多，想要找寻对事物洞悉，拿捏把握比你更透彻的人，太容易了。从前辈哪里获得人生智慧，从来都不是难事。再加上那些数不尽的历史上哲人，也许所有人类哲理，早在公元前就被古希腊哲学家之流给整理全面了，后人只是不断重复，反复，颠倒，然后拨乱反正而已。相信已经没有什么空间可以让你去挖掘新得道理了，所以Joel明显不是在发明新道理，他只是在用自己的方式，自己的声音来解释道理而已。能站在高层面将问题看得很全面透彻的人难得，乐于分享自己的思想，观点的人更难得，但是非常善于表达，用自己的语言文字将道理用风趣幽默的方式阐述得简单浅显易懂得人是极端得少数。Joel讲故事得方法特别容易让人信服，难以反驳，除了所表达得内容，他得表达方式，文笔修辞也让我收益匪浅。当然这离不开译者阮一峰得努力。稍后在写关于阮一峰和他翻译得故事。

Joel都说了些什么？Joel说得事情都是软件开发得事情，不管你是程序员，项目经理，软件公司老板，或者是打算投入这个行业得外行人，这本书都适合你。每篇文字都是Joel最近几年得Blog文章，按照管理，设计，经营，市场以及人得角度提炼整理而成。站在我自己得角度，我更原意从人性和历史两个方面来看这本书。

人性角度，即通过理解Joel得性格特点，从他得角度来理解他得文字，从而能更深理解他得思想。网络上那么多得文章教你如何作一个程序员，以及如何管理项目，如何取得市场成功，但是鲜有从性格角度看待问题，以及帮助你理解性格特点是如何在软件开发过程中，对组织管理产生影响的，虽然Joel没有标榜自己的性格特点，但是整本书每一行文字，其实都是如此，Joel个性鲜明，大舌头，喜欢发表言论，但是他不忽悠，字里行间完全不是站在制高点指点江山，而是站在一个非常非常低的角度，以一种低姿态，甚至市井的角度讲事情的发展，根源，以及各种缘由娓娓道来，读起来完全不会有任何心理压力。

历史角度，因为是Blog摘编，所以每篇文章你都能看到一个确切得发布日期，问题是在文章发布的那个时间点上，你看待正在发生的问题是站在什么角度，而Joel又站在了什么角度？Joel看问题角度很多样，从高层抽象到细腻得底层细节，都可圈可点，这也让他有资本对未来作一些预期猜测。但是Joel往往都是猜得中结局得那个人。我一直在思考这个问题，从作软件开发之前，就一直保持着对整个行业得关注，特别重视培养自己得眼光，看清趋势发展和把握将来机会，这个初衷从高中时代就开始酝酿，但是现在我依然不敢说自己已经有了这样得能力，看问题依然局限，缺乏大局观。最困扰得是，你可以很清晰得将过去得事情发展脉络看得清清楚楚，往回看，一切事物得发展总是相互关联互相影响的，事后诸葛亮人人都能作。困难的是你无法准确看清楚将来的趋势，无法准确拿捏和把握将来的产业事态发展，总是看到一片乱象，而且是空前的乱… Joel很大胆，他点评时事，却不仅仅局限于已经发生过的事情，还包含大量对事情发展预期的暗示，现在回看都变成了现实。他真的这么神？其实看他如何解释自己是怎么做出判断的过程，往往会让你会心一笑，其实道理都不难，历史发展总是惊人得相似，尽管历史上每个伟大的人物都相信自己可以改变历史，但是结局往往仍然回到原点，所以如果你不知道事态会如何发展，就把宝押在跟历史吻合的那一面。除此之外学习Joel这种大局观，分析把握事物发展脉络的能力很有价值，你一定会有所收获，相信我，从书中收获到的知识一定会值回这本书的价格。

写到这里发现自己写的好空洞，需要我举几个例子嘛？我就举几个例子吧。有几篇文章给我留下的印象极深刻。

• 寻找优秀的程序员 + 寻找优秀的程序员之实战指南——其实招聘是一个很大的话题，关于招聘我也思考了很久，其实问题就是人才总是稀缺，在这个情况下你怎么作才能吸引到更多优秀的人呢？从Joel这篇文章，Joel其实是在作活广告，他给他潜在的读者一个信息，他的公司处处体现人性，处处关心人，信任人，所以，如果你希望变成一个很棒的程序员，希望跟Joel共事，你就应知道导怎么做了。

• 在耶鲁大学的演讲——这是对自己软件生涯的一次精彩浓缩点评，其实这哪里是浓缩，简直是经过语言艺术的加工之后，将自己的经历渲染到如此的激情澎湃，这最符合大学毕业生的胃口，于是，那些有抱负，想要做出一番事业的人，请把你的简历寄给 jobs@fogcreek.com
• 别给用户太多选择——拿MS的Vista开涮，拿MS的界面设计师，程序员，测试人员开涮，事实证明，Vista的最后结局是晚景凄凉。
• 易用性是不够的——Joel预言下一个十年，软件公司回雇佣人类学家，而事实是，现在的软件UI设计人员，开始纷纷投入心理学，人类学领域去进修。
• 火星人的打火机——点评了Web浏览器领域的乱象，以及在IE8发布之初，MS的IE团队面临的两难，自己给自己挖了个坑，然后自己把自己推下去的典型。IE8最终也改变不了什么，因为理想主意者的大原则和实用主义者现实的选择，这样的论战将持续到永远。
• 徇证式日程规划——这篇文章我看后心有戚戚嫣，自己在个人事务管理尝试经过一轮又一轮，几个阶段之后，得出的结论跟Joel基类似，Joel的建议更值得采纳。
• 关于战略问题的通信之六——昔日DOS平台上的困境在今日的Ajax应用上继续上演，甚至预言了Google和Gmail将来的困境，因为现在所有影响市场的因素和背后的动力同当年完全一样，我们唯一不知道的就是，它到底发生在何时，何地，何人身上，所以我乐得等发生的那一天。
• 你的编程语言做得到么——看起来是在力挺函数式语言，以及那些将来会非常红火的JavaScript，暗合了之前一篇文章，学校只教Java的危险性，呵呵，这篇2006年的文章现在看来，JavaScript成为下一代主流语言已经成为事实了。
• 飚高音——是我最喜欢的一篇文章，因为它准确点评出了为什么我如此喜欢Apple的产品，apple的设计，风格。
• ……（还有其他未提及的文章，不是因为没有给我留下深刻印象，而是文章太精彩，我的组织表达能力难以归纳出来…）

阮一峰，我很欣赏得一个程序员，我并不确定他本人是否是一个程序员，因为我从来不把他当作一个程序员来看待，因为从他得blog上，关于技术方面得文章，我只记得我曾经花费半天时间仔细阅读并实践他得制作GMail式按钮，我更乐意用见微知著来形容从这篇教程文章中，我看到一个技术细腻，严谨，并追求卓越得程序员高手风范。但我更喜欢他得blog上那些非技术文章，尽管在某些方面我有自己的观点，但这丝毫不影响我透过他文字交流思想（单向 ）。他得文风流畅，严谨，而且洗净浮华，毫不造作，虽然同在上海，却不曾有机会见面，但是我相信一定是见文如见其人的。

下面是阮一峰先生翻译这本书相关的一些博文，我认为非常有价值，帮你从一个译者角度理解Joel的思想，以及翻译过程中的点点滴滴，强烈建议阅读，顺便说一句，这本说的作译和出版商是如此的慷慨，公开了前7章的内容，谢谢他们！

• 我要翻译《Joel On Software》了！
• 《Joel谈软件》出版了
• 关于《Joel On Software》副书名的翻译
• More Joel on Software 中文版主页

缘起：这是Uncle Bob大叔昨天写的一篇文章，Software on the Cheap. 因为最近在shanghaionrails社区干了不少招聘的事，也一直想发表一点自己的看法，先贴上我全文翻译（不经常翻东西，不足之处还望多多指教）：

＝＝＝＝＝＝＝＝＝＝ 华丽的分割线：全文翻译开始 ＝＝＝＝＝＝＝＝＝＝

当涉及到软件，你花的每一分钱，到底买到的是什么？你是否曾经想过，你的一行代码到底值多少钱？其实，想要算出来并不难。

过去的14个月，我为FitNesse项目写了大概2万行代码，当然，这都是在业余时间完成的。我的主要工作是运作Object Mentor公司，咨询，授课，指导，写作以及一大堆其他事情。编程活动大概只占据我15%左右的时间。

另一方面，程序员总是有其他很多事情要做，他们要开会，然后他们继续开更多的会。当他们正在开会时，他们还要参加后面的会议。以及后面还有更多的会议等着他们。当然，不要忘记还有各种个样繁琐的统计工具以及晦涩难用的源码控制工具来谋杀程序员的时间，感觉就好像蝾螈在冰冻的泥土上缓慢往前爬。

所以15%这个比例不太理想。

一个典型程序员的全部收入（工资加上其他各种收入）大概在20万美刀（我知道这样听上去好像很高，但是你可以姑且这么计算）。所以 20万美刀 / （2万行代码 / 14个月 * 12月）＝ 11.66美刀/每行代码。

让我们看一看下面这行代码：

StringBugger nameBuffer = new StringBuffer();

这行代码看起来值11.66美刀么？你会为这行代码支付11.66美刀么？请先不要急着回答，因为在每行这样的代码之前，你需要先声明这样一行代码（并且是完全免费的）：

import java.lang.StringBuffer;

一些工厂按照“计件工资”方式支付员工薪水。那么你会接受每行代码11.66美刀来算薪水么？当然前提是每行代码都经过了充分测试。

我敢打赌，只要我真的出钱，那么每个程序员都一定会开始严格遵循TDD的方式开发啦（测试驱动开发）。

言归正传

刚才这个薪资计算方式虽然不靠谱，但是他揭露了一个事实，软件不便宜。即便一个最愚蠢得小程序，也可能超过1000行代码，也就意味着这个软件得成本接近1.2万美刀。

想象一下，如果你不是一个程序员，但是关于建立网站你有一个很好得点子，如果作成了会给你带来巨额收入。你把用户用例故事，以及所有细节都准备得非常充分。现在，你是不是准备要找一个高中生来帮你，就像解压缩zip文件一样轻松把网站给做出来？得了吧，你可以支付最低限度的工资，但只有笨蛋程序员才会乐于为你工作。

其实，这样得杯洗具随处可见。很多人不惜提前预支了他老爹的退休金，就为了实现一个很棒得想法，但实现过程却糟糕至极。更耸人听闻得还有那些知名得大公司，花费着每小时100美刀（甚至更多）的成本，却仅仅为了去找一个廉价的解决方案。

“毕竟，作软件不难”，或者他们会说：“这不是要把火箭送上月球，而且那些要价昂贵的家伙其实一直是在骗我们的钱，软件开发没有那么难”。啊哈！

所以这个可怜得家伙到学校找了一个菜鸟，或者招募了一个去年刚刚读了一本关于HTML的书，作出了一个看起来蛮可爱，用来炫耀自己的宠物小猫的网页，而其人却是一个让人讨厌的家庭主妇来作他的程序员，他们听说过TDD么？他们听说过设计模式么？还有设计原则？他们知道源码控制么？

他们当然没有。他们能作的仅仅是将那些恐怖的代码打包到一起，而且没有测试，更没有版本控制，糟糕至极。也许项目起初看起来还不错，挺激动人心的，但是好景不长，很快项目进度就慢下来了，甚至停顿下来，而你的开销却有增无减。

结局是，网站无法正常运转（这个可怜的家伙的老爸也无法早早退休了）。项目最终成为一场灾难，要么被终止，要么花费两倍甚至三倍的钱，才能让项目回到正轨。

底线

关于底线，那就是：只要涉及到软件，你得到什么取决于你到底花了多少钱。如果你想要高质量的软件，那么你必须支付高昂的费用，甚至成本很可能超过12美刀/行。但是请相信我，这可能是得到正确软件最实惠得方法了。

如果你一心只想寻找最廉价的解决方案，那么最终结果只会让你付出更多，并且损失大量的时间。软件就是这样一种东西，好的软件很花钱，一半的钱只能得到糟糕软件，如果你想要更便宜，那么你实际付出的，可能是两倍，甚至超过三倍。

＝＝＝＝＝＝＝＝＝＝ 华丽的分割线：全文翻译结束 ＝＝＝＝＝＝＝＝＝＝

后记：Shanghaionrails成立发展至今，形成了一个特别有意思的小圈子。一直在社区里面为大家发布各种招聘信息，也有一些心得。

总体来所，Rails的社区人才难找，供不应求是常态。经常跟招聘方负责人闲聊，问及招聘情况，得到得反馈都差不多。这两年下来，能亲手促成朋友找到自己心仪的公司的情况，少之又少，很惭愧。不过从另外一方面说，招聘方都希望找到合适自己公司的人才，而且每家公司的用人策略也不尽相同。个中充满了时机，选择，变数，非我个人所能掌控。

从人才角度来说，社区规模，注册人数接近500人了，相信潜在会员还有更多，活跃的会员，保守估计大概在10%，于是乎，就感觉圈子好小，因为经常冒泡说话的就那么些人，而这他们在什么地方，作什么事情，我大抵一清二楚，招聘广告一般都不是针对他们的。

我用class A级来形容而那些低调且华丽的高手们，牛人们，我知道一些这样的人，这些人通常早早就为自己安排好了一切，有非常好的工作，很高的薪水，稳定且前途光明，一般得招聘广告对他们的吸引力不大。

那些有一定水平的，并有一定经验的人，我称之为class B级人才，这也包括我自己。这群人有潜力，加以时日会成为大牛，或者已经成为大牛却不自知。但是自己目前所处环境，限制自己的能力无法充分发挥，更想要寻求更好的发展，更好的薪资。可喜可贺，招聘信息是为这些人准备的。比如最近我代Factual.com发布招聘信息，很幸运吸引到一些来自世界顶级公司，有着非常雄厚的背景，学历极高的人才，请原谅我在这里隐去他们的具体信息，我只是想说社区里面卧虎藏龙，潜伏着牛人无数，可是平时讨论，以及一些社区活动，你不参加，怎么会让别人认识到你，让招聘方了解到你，让朋友们关注到你，当好得机会来了你才不会被错过。所以请积极参与社区活动。

以招聘毫无经验，技能，尤其以学生为主的公司，我认为Uncle Bob的文章用最浅显的例子把道理说的很明白了：好软件不便宜。如果公司是以外包和客户项目为主，那么寻求最廉价的劳动力本质没错，可是综合计算成本，尤其是以智力作为劳动生产资料的软件开发行业，一个没有经验技能的人能产生多少价值，刨去必须支付得哪怕相当低廉的工资，还有多少利润剩余？我不否认学生中有出类拔萃的顶尖人才，也无意冒犯在校读书或者刚刚毕业的年轻人，学生是一个很特殊得群体，他们还没有定性，对发展，对机会得诉求更高，却对未知得将来充满恐惧，请不要利用学生的这种心态，这样得心态无法长期持续为公司创造价值。软件从业门槛是有的，而且软件行业也是商业，也要从商业角度考虑问题。（其实很想说的在透一点，招聘中最好不要涉及对中国的开源环境的点评，像中日软件社区对比以及差距这种敏感话题，也最好避免讨论，只要涉及到我都不会参与其中，对社区发展无益。）

对于没有经验，刚刚进入这个行业得人，尤其是学生朋友，其实我不想说教，也轮不到我。我只想说，一定不要灰心丧气，每个人都是从0经验入行这么过来的，开始的时候都茫然不知所措，找不到方向。关键是你是能看清楚目标，是不是每天都在进步，是否真的想好了要投身这IT行业并打算长期坚持，如果仅仅想要赚钱，建议趁早赶快转行吧，作程序员不能保证你赚大钱。如果你喜欢技术，喜欢钻研，只要你每天作的都是靠谱的事情，成为Class B级别，迈入Class A级别只是一个时间问题。

如何像天才一样思考，这个问题早已经被无数前人研究过，并提出各种思维策略模型，比如Productive Thinking，Creative Thinking，以及Critical Thinking等等… 不管深入任何一种，都可以挖掘出很多极富有价值得研究成果。

缩小范围，这里我要说得天才是这样一群人，他们得代表人物有亚里士多德，莱昂纳多，达芬奇，以及爱因斯坦等。这些人有个共同特点，他们得智商都高得出奇，并同时拥有极高得创造力。高智商得人都能成为天才么？是不是上帝总是将创造力作为礼物打包奉送给了每个高智商的人？当然不是。

起初，科学家和统计学家们试图寻找能够产生高IQ天才得一些线索，经过大量历史资料文献研究，他们得出了样得结论：大多数天才都是在父亲年纪超过30岁，而母亲年纪低于25岁时出生的，而且天才们小时候大多体弱多病。还有一些证据表明，很多天才来自单亲家庭，或者他们终身不娶（不嫁）。结论就是，这些研究结果相当荒诞，没有任何意义。

也许天才们得IQ很高，可是通过IQ来判断这个人是否是天才也是毫无意义的，我个人绝对赞同这个观点，因为它让我产生了自己仍然可以成为天才得幻想，呵呵。其实有个浅而易见得例子，历数每一届诺贝尔文学奖得主，他们的IQ恐怕都不及一个普通大学的物理学教授。当理查德·费曼获得诺贝尔物理学奖时，人们都认为他才是一个真正得天才，是他把量子物理学引入了一个新的时代，其实，理查德·费曼得IQ也才仅仅只有122而已，所以一个人完全可以拥有比自己智商高的多得创造力。(这里推荐关于量子物理学非常有趣得故事：上帝掷骰子吗)

像天才一样思考，其实就是创造性思考，而不是重复式思考。我们从小被训练以Reproductively得方式思考，本能得从过去得经验和实践中寻找解决问题得途径。不停得问自己“关于这个问题，学校是怎么教的，我是怎么被培训的？”。我们基于过去或者他人的经验，来选择前进得道路，倾向于一条目标明确，又能取得最大价值得人生规划。越是依靠以前得经验，其实越容易让自己变得不自知，变成井底之蛙。而且还是特别傲慢得那一只。

像天才一样思考，就是从不同角度考量问题本身，不停问自己“解决这个问题得方法又多少种”以及“我如何才能从另外一个角度看待这个问题”，而不是“我接受培训时，对于这个问题，那个培训我得人当时时怎么说得？”。天才得这种思考方式，更倾向于认为解决问题得方法就应该时多种多样的，即使大家都知道有一种最佳解决方案，也不妨碍天才思考其他得可能性。自觉得去寻找其他可能的解决方案非常重要，甚至在其他人已经找到了方案之后。

像天才一样思考，就是鼓励并促进我们的大脑思维更加灵活。基于教条式的思考方式，很容易导致细想变得僵化，上一篇我已经提到这一点。死板的思维方式总是我们面对新问题时感觉受挫，消极，失败。新的问题往往在表面上看起来跟过去的问题非常相近，但是深入下去却各有不同，仍然以原有的思维方式考虑问题，非常容易让人迷失在问题当中。Reproductive thinking会倾向于引导我们得到通用性思维，却阻碍我们进行原始思考，如果总是以通用性的方式思考，那么得到的结果也总是同样的。

关于如何像天才一样思考，能举出的例子太多，一条好得途径改变自己就是先从学习习惯开始，然后尝试应用一些更好得思维策略，关于这一点又是一个不小得话题，但是牵扯到行动指南，都是一些见仁见智得话题，没有一种放之四海而皆准得方法，所以只能是经过自己实践后，找出最适合自己得那一套，关于这个，我仍然在实践中，思考也仍然会继续，也许过些日子，我会写一篇“像天才一样思考，实战篇”，呵呵。

推荐下面两篇文章，一定会对你有所启发：

• 8 ways that anyone can use to think like a genius
• How to Learn Without Memorizing

如何才能像天才一样思考？最近总是在思考这个问题。

之所以要抛出这个问题，是因为我发现自己是个天才，所以我就简单给大家介绍一下我是怎么思考得，呵呵，开个玩笑。

经历过好几个软件公司，非常有幸跟很多有天赋，绝顶聪明得人一起工作，比如像是脑袋里面装了双核处理器得 @hozaka，浙大少年班毕业得@masterwujiang，去年刚毕业却在JS编程上经验丰富硕果累累的@agate，他们都年纪很小却在编程上造诣颇深。还有自己在ELC的一年多时间里，合作过得国外优秀工程师，他们有来自伊朗，塞尔维亚，阿根廷，德国等等。更不用说那些功成名就得前辈，长者们，这里省略若干人名….. （无法在这里一一例举，也担心自己不小心把谁给漏了:D）

跟才华横溢得天才工程师合作总是非常愉快，不过我自己经常思考自己跟优秀工程师得差距到底有多大？总有这样一种感觉，随着从业经历的延续，自己的经验积累越来越丰富，可是我很怀疑这些经验对职业发展带来得好处十分很有限，有时甚至成了牵绊，阻碍。比如在面对具体问题时，我得思路总是从自己得经历，经验出发，寻找最优解，一般情况下这样作很凑效，但是如果你面对得是特别复杂得，高级别得问题时，又或者第一次遇到得新问题，这个时候既有经验可能一点帮助都没有，在苦苦思索而不得时，我就去请教团队中最厉害得那个家伙… 于是，电光火石般的，那个家伙很快就把解决方案呈现在你得面前，漂亮，优雅，简洁，并容易理解…… 仿佛条件反射一般，他好像没有花什么功夫就把难题搞定了，这种事经常让我觉得不可思议。

为了想要变得更加靠谱，变得更牛，我对“天才时如何思考”这个问题产生强烈得兴趣。好吧，我承认，我不是天才，而且看起来也不太有可能成为天才了，甚至，在接触过得所有人中，我还真没有发现一个比自己更笨得人。所以，如果你认为Daniel是个聪明人，哈哈，你被骗了，因为Daniel伪装得太好了。但是，即使自己不是天才，研究天才得思考方式仍然是有价值得，仍然会对你得职业规划产生深远影响。

因为自我自省得机制，我首先开始从自身找原因，找来找去，我发现这一切可以从自己得性格特点中找到一点线索。简单得说，我是一个善于自省，且原则性很强得人。自省是指以一种谦卑得态度分析自己，积极总结自己的得失。而原则性强，说得难听一点，就是固执。虽然从外表来说，不管再怎么对人谦恭有礼，温润如玉，其实内心非常坚持，不会轻易改变自己得看法，想法。且不说这种性格特点是好是坏，既然自己就是这个德性了，就扬长避短，把这德性当作人性以及个人魅力得闪光点得了。这让我在处理人际关系，利益得失时，反而变得没有什么心理负担，结果往往也还靠谱，不算太坏。可是，用它来解决技术问题时，就比较麻烦了。

固执的性格，很容易让你的思维变得僵化，看问题的眼光变得保守，随着年纪的增长，这种情况反而更加厉害，不管你信不信，这是真的。观察高手的解决方案，发现并不是人家有多聪明，掌握你所不了解得知识，而是人家得思路比你更加灵活，想问题得角度更加多样，或者更加全面。所以回过头来看自己的问题，我可以这样总结：缺乏想象力，缺乏创造力，在上面提到得那个case中，自己能找到的解决方案，往往过分依赖自己过去的经验和所掌握的技能水平。超出自己能力范围之外的，自己无法触及。

既然大家都不是生下来就会折腾计算机的，都是0经验入行，都需要经过学习才能掌握语言以及编程机巧，甚至人家在这个领域花费的时间比你少得多，经验比你浅得多，确在分析问题，解决问题的能力上远远超过你，人和人得差别怎么就这么大呢？既然大家都是学出来得，那么一定时学习方法出了问题。学习得过程就是一个不断总结并积累经验得过程，我积累得这些经验有问题么？答案时有，而且很大。自我评价，我不算高手，也不是菜鸟，所以我是一个中等水平的程序员。我的学习经历分为初级和中级两个阶段。在初级阶段，我最主要得学习行为其实就是两个字：“填塞”。即不断得背诵，记忆。这个阶段，你对编程得理解始终有限，所以看资料，看文章，看Blog，可以就把自己得大脑想象成一块硬盘，不管眼前得知识现在有用没用，能记住总没有坏处，最好能顺便增进一点理解能力就更好了。到了中级阶段，记忆得学习方法就不那么有效了，大脑得容量总是有限，你必须通过自己已经掌握得知识，思考并推演出问题得解决方案，这个时候，以往过去得经验就变得非常有价值。因为大家都不把我当作菜鸟看待，所以我想我现在承认自己就是中级程序员没什么大不了得吧？呵呵。

问题就出在这些既有得经验上，回顾之前得经历，为了加速自己得成长，我总是倾向于寻求最佳问题解决方案，而这些方案往往并不是来自于自己，而是通过跟有经验得人学习，向水平更高得人求教，或者在网上直接搜索。这些解决问题得方式，就像你在森林中，你想要看得更远更清楚，关键取决于你是否能找到那棵最高得树，如果你找到了，爬上去，自然就能看得最远。可是，高级的问题不是你一上来就能找到对应得方案的，必须先分析问题和理解问题，理解问题本身得能力甚至比提出解决方案更加重要，因为当你真正理解了问题本身，解决方案会很快跃然纸上，这是关键所在。可是想要提升分析理解问题得能力，就像是在造金字塔。爬树你可以直上直下，一蹴而就。造金字塔，能把塔尖造得多高，取决于塔尖下一层积累有多广，以及思考有多深。

从来不吝啬在技术上投入大量时间钻研，所以我积累得足够广了，可是思考也有那么深么？因为有了互联网，身边有特别牛X得同事，聪明得你发现得到更好得方案不那么难，也许你很勤奋，解决问题之余，你还会花额外得时间理解这些方案，试图掌握它们，这样你再次遇到类似得问题时，触类旁通般得就能灵活运用它们，呵呵，其实这里有个很大得陷阱。从别处得到得解决方案和自己折腾出来得解决方案，有一个非常本质得区别，就是在形成方案得过程中，由谁来通过思考做出各种个样得权衡和决定？是你还是别人，这点真得很重要。因为每个决定背后，你都需要考虑它得具体需求，所产生得积极效果以及负面影响，这些效果得积累，最终会体现在方案得实施过程中。但是如果这些决定都是别人替你做出来得，你除了丧失第一次思考得机会以外，也不会有第二次思考机会，即方案实施结果对第一次思考的反馈。这些思考以及反馈，会帮你更加深入理解问题本身，这也就是你总拿来方案，积累广了，思考未必一定很深得原因。我现在就非常怀疑追随天才得脚步来积累经验，对自己而言，到底是好事？还是坏事呢？

除了增加自己思考的机会之外，对于同样的问题，一般人和天才的思考行为和思考习惯也不相同。不过今天已经扯了这么多，关于天才的思考方式和习惯，明天继续扯吧…

卢浮宫

是世界上最古老、最大、最著名的博物馆之一。位于法国巴黎市中心的塞纳河北岸（右岸），始建于1204年，历经800多年扩建、重修达到今天的规模。 如今博物馆收藏目录上记载的艺术品数量已达400，000件，分为许多的门类品种，从古代埃及、希腊、埃特鲁里亚、罗马的艺术品，到东方各国的艺术品；有从中世纪到现代的雕塑作品；还有数量惊人的王室珍玩以及绘画精品等等。迄今为止，卢浮宫已成为世界著名的艺术殿堂。

－－摘自百度百科

乔治·蓬皮杜国家艺术文化中心

坐落在巴黎拉丁区北侧、塞纳河右岸的博堡大街，当地人常也简称为“博堡”。文化中心的外部钢架林立、管道纵横，并且根据不同功能分别漆上红、黄、蓝、绿、白等颜色。因这座现代化的建筑外观极像一座工厂，故又有“炼油厂”和“文化工厂”之称。大厦的支架由两排间距为48米的钢管柱构成，楼板可上下移动，楼梯及所有设备完全暴露。东立面的管道和西立面的走廊均为有机玻璃圆形长罩所覆盖。大厦内部设有现代艺术博物馆、图书馆和工业设计中心。它南面小广场的地下有音乐和声学研究所。中心打破了文化建筑所应有的设计常规，突出强调现代科学技术同文化艺术的密切关系，是现代建筑中重技派的最典型的代表作。

－－摘自百度百科

缘起：

我不想介绍法国的艺术中心，图片和wiki摘录是为了更加直观的对比。之所以把他们放在一起，是源于前些日子跟Forrest聊天中，将这两座建筑放在一起，作为隐喻，用来比喻开发中的两种软件设计风格。这个话题引发了我的深度思考，多日过去，我并没有想出一个可以接受的结论，甚至怀疑压根就不可能有结论。把一些思考的点点滴滴记录在这里，也许日后回顾起来也是一种价值。

不可否认，我的软件设计偏好受到Rails的影响，倾向于将复杂的细节小心封装在表面之下，并尽量以一种优雅，简洁，略带一点Magic得方式在上层编码，组织业务逻辑。就好像卢浮宫，从外表看，极尽奢华，但其内部的细节构造呢？至少从表面，不会轻易让你一窥究竟。

与卢浮宫成为鲜明对比的是蓬皮杜艺术中心，这座建筑曾经引起极大的争议，由于一反巴黎的传统建筑风格，一度让很多人无法接受。其实蓬皮杜艺术中心暴露在外面的复杂管线是有规则可寻的，空调管线是蓝色，水管是绿色，电力管线是黄色，自动扶梯是红色… 将所有管线排布在室外则换取了更大的室内空间，使用极为方便，而且管线维护容易，成本更低。

这次讨论得核心是，我应该采用哪一种设计编码风格？如果放在具体环境中，比如我现在工作的公司Factual.com，答案是第二种。在Factual，要求实现设计尽量简单，在满足需求得情况下，更多得考虑性能。代码表现力，代码美感，都不是首要的考量标准。这的确是一种讲究实效，工程师文化主导得选择结果，对此我非常理解并欣然接受。

可是到底哪种软件设计方式是更好，我个人得建议是，最好不要试图完整全面回答这个问题，哪怕在一个具体得环境中，每种设计方法学都有其长处和短板。所以深刻理解用需求和用例故事，以性能指标作为尺度来权衡是最佳实践，尽管看起来这是一种中庸得方式，不过得到的结果不会差到哪里去。

刚刚开始探讨这两种设计思路的利弊时，我内心深处竖起一道坚实的壁垒，不可否认卢浮宫是我的追求，这种先入为主的意识占了上风，至少，如果蓬皮杜得做事方式是正确的，那么不就是对自己之前的一种否认？因为Ruby得关系，以及长期浸淫在Rails得世界，不敢说自己写得代码算得上优雅，或多或少却知道一点什么样的代码才是具有审美意境，以及如何编码，才算得上是干净。或者说一切都不能违背DRY（Don’t Repeat Youself）原则。后来立即明白，并不是要自我否认，而是在原来得基础上接受另外一种风格，让自己更加灵活，不要被与目标无关得这些taste层面得东西给牵绊，套上心理枷锁，先把事情作对，再把事情做好。想到此处，问题就变成了如何做才能两者兼顾，写出干净得代码，清晰表现自己得意图得同时，兼顾高效快速完成工作？答案是：唯有在项目中有不断打磨，锻炼，总结，慢慢就会有心得了……

做软件开发得人，几乎人人都知道GOF，都知道设计模式，很多人能将23种经典设计模式倒背如流，甚至肌肉反射式得将模式定义以及UML图表画出。说实话，这种事情我也干过，而且不止一次，设计模式原版是基于C的，后来有了Java版本，再后来Ruby版本得也出了。这些书我通通都看过，对我来说，在设计模式上耗费得心血，都以失败告终。于是我得出一条重要得结论：学习设计模式不难，难在知道什么时候用，以及用哪一个。这需要长期实践，总结并积累。这跟上一段得出的结论貌似如出一辙，不是么？

其实谈理论总显得有些空洞，我之所以偏好卢浮宫，偏好敏捷设计实践，跟我个人在软件开发学习成长得经历有关，这里我最先想到得是一个例子：年初我用Rails开发了一款web game，最开始时一切都进展得很好，不过我们想法太多，想要在游戏之上构建一个web game engine，并通过这个engine生成最终游戏。于是乎走了一条很长的弯路，陷入一种过度设计得状态。追求最灵活得设计方案，往往会导致实现变得复杂晦涩难懂，迫于项目进度压力，为了快速迭代，我们同时做了一些很疯狂得事情。打个比方，就好像你有了一个优雅得原型设计，然后把它弄乱，让它腐败，代码种开始充斥着各种臭味道。开发过程变得越来越笨重，修改变得越来越困难，另人沮丧得是对于这一切感到有心无力… 听起来是不是很熟悉?这种状况其实是司空见惯，且不停得被一遍一遍重演。

好的设计是修改出来得，修改代码有修改代码得“道”，我个人比较推崇Bob大叔在《Agile Software Development Principles, Patterns, and Practices》中提出得那些建议，似乎Bob大叔得这本书整本都在讨论如何解决这个问题。那么是不是看完这本书，就知道如何搞定一切了？答案仍然是否定的，这本书我粗看过一遍，发现很多东西我看不懂，看懂得部分没有悟透，仍然需要一遍接着一遍得看下去，直到永远～

这里到底我想要说什么？没有银弹（我不懂如何证明为什么没有银弹，至少我相信没有）。好几年前我跟南京一个快印店老板聊天时，谈到这样一种情景，我不记得是他还是我说的：那些一心只朝一个方向前进得人，未必能走得很远，有时心中装着截然不同，甚至相互矛盾观点得人，往往走得更远。因为他会不断停下来重新审视自己，不断思考并修正自己，就会越来越接近成功。回到最初得问题，到底是卢浮宫还是蓬皮杜？没有答案，也不需要，心理装着这两种思路，不断尝试，不断思考，不断总结，坚持下去，这就靠谱了。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
后记，这篇文章是通过Ecto写得，发现用Ecto真不错，让写Blog变得轻松，效率高了不少

比较奇怪，Rails小兵级别的人物如我，居然经常在Blog上被人问起Rails初学者如何上手这样的问题。今天在Shanghaionrails的Group上，Barry也问了同样的问题，于是我仔细回复了Barry，我回复同时也是为了给所有初学Rails的人一点点建议。

——————– 分割线，Barry的问题 ——————–
各位好，

在 Daniel 的介绍下，第一次在shanghai rails group上发帖子，虽然我已经认识其中的一些成员。有感于组员的热心讨论和rails相关的问题，想请教各位如何才能尽快的掌握rails。

目的: 希望能够学习一些rails的知识，开发一些自己感兴趣的网站。

背景: 几乎没有任何计算机的背景知识。大学的时候没有怎么学过计算机编程课。目前从事的是和知识产权相关的律师工作，包括open source, web2.0什么的。

我对rails感兴趣，是看到一个介绍美国的peertopatent.org网站是用rails的技术来做的。这是一个我很关注的和专利有关的网站。因而读了一些文件，说是rails是一个非常方便，快捷的网站开发工具。于是就顿时产生了兴趣。

最近已经看过一些html和asp的书籍。也读了headfirst 系列的深入浅出 rails一书。知道一些rails的基础知识。但是在继续看更多的书的时候，却发现rails，还有ruby，语法真的是非常的灵活，以致于常常摸不着头脑。特别是那些个object的属性，书中的介绍几乎是信手拈来的使用。还有引号，顿号和逗号的使用，看起来非常吃力。

近期目标：之前请人做了用asp做了一个英语的法律问答的网站, www.15minutes4u.com。在shanghai rails group上看到了之前的一个外包消息，于是在接洽请他们用rails改版和升级。

请各位多提宝贵意见，有没有什么外行人的捷径。目的是自己开发一些感兴趣的网站。。。

多谢！

Barry

——————– 分割线，我的回复 ——————–
我来尝试回答一下，关于楼主这一系列问题，我最想说的第一句话就是，“相信我，面对这些问题，你并不孤独…”

先泼冷水吧，我希望楼主先弄明白两个问题，为什么是Rails？以及为什么要自己搞Rails？

关于为什么是Rails，我认为酷学的小星一次在宾馆跟我聊天的时候，总结的最为精辟：”如果你有个好的想法，想要互联网创业，想要快速实现一个原型并马上推到市场上，接受市场检验，这时Rails是最佳选择“

关于为什么要自己搞Rails，需想明白投入产出的关系。因为这意味着长期坚持投入大量时间和资源。我从创业角度理解，一个专精市场或者业务的人和一个技术型的人互为创业合作伙伴的组合，是一个不错的选择，可以互相取长补短。

好，现在说说入门成为一个Rails程序员吧。

我想以自己作例子来说一下，我大概是06年底07年初接触Rails，是看着JavaEye的Robbin的文章受其蛊惑，开始学习的。Robbin写了很多RoR系列文章，适合按照时间顺一篇一篇阅读。

地址 http://robbin.javaeye.com/category/5473 这些文章我深以为然。

关于RoR学习书籍推荐 http://robbin.javaeye.com/blog/58287

不过我有一点不同意见，我认为两本书《Agile Web Development with Rails第二版》和《Programming Ruby》就足够了。

不用担心那些Ruby语法上的细枝末节，其实那些并不重要，RoR最大的好处是，你可以先从Rails框架开始学起，然后顺便学习Ruby基础知识。注意，你的目标是熟悉并理解Rails这个框架，这个才是重点，等过一个阶段，对Ruby基础知识的需求才会凸显出来。

说完了书的选择，我想说说学习过程，我认为想要掌握Rails，制定一个好的，合理的初级目标非常关键，《Agile》那本书中的“书城”的例子，就非常适合作一个初级目标，我可以负责任的告诉你，当你把这本书上的例子烂熟于胸，并对这个实例项目的需求实现的前因后果深刻理解后，你已经掌握了至少80%的Rails知识，足以应付工作中80%的问题，这个过程，如果对自己要求高一点，施加的压力大一点，大概需要三到六个月吧。不用感觉这个时间太长，其实少既是多，慢既是快，如果能用半年时间，将这两本书上的内容学通学透，后面的学习过程将会是突飞猛进，摧枯拉朽的。

说说捷径，我可以负责任的告诉你，如果你真的打算走技术道路，打算自己折腾Rails作web项目，走捷径是不靠谱的，你可以直接放弃走捷径的可能吧。

如果非要头撞南墙找捷径的话，我偷偷告诉你，你不是有项目正在用Rails升级么，将这个项目中一些小模块揽下来，多跟Rails团队沟通，偷师也成，利用项目压力来推进自己的学习进程，是可能压缩总体学习时间的，但是过程会很痛苦，呵呵，我就是这么走过来的。

好了，我就说这么多，其他的楼下补充！

Daniel Lv

——————– 分割线，未结束，新回复会更新在这里 ——————–
Barry,

First all, www.15minutes4u.com is a decent site, nice clean UI. And I
love the fact that you didn’t put any ads. on. It has a great
potential. I can see myself and some of my friends using the site.
Don’t give that up.

about rails, Daniel is right, it is best for rapid prototyping. And
before we can give you any useful suggestions, you need to tell us
what you goals are, what you are trying to achieve with Rails.

in general
http://www.rubycentral.com/book/ is a good free online book to get
started.
http://pragprog.com/titles/rails2/agile-web-development-with-rails is
probably one of the best books for learning rails.

Two should be enough, if you start practice and have any questions,
stackoverflow is a nice place to ask. you can also post questions to
here.

hope that helps.

Eric
—————————————-
如果只谈rails中ruby的语法问题的话，那么可以看看这本书
《Ruby for Rails 中文版》
这本书有380页左右，
对于一个有些编程经验且理解面向对象的人来讲，这本书不错。
能够快速掌握ruby的语法。
相关网址如下：

http://www.douban.com/subject/2123090/

http://www.china-pub.com/209179

还有一本书，《Programming Ruby 第二版 中文版》。
但这本书有800页左右，不适合快速掌握ruby语法。
里面介绍的东西有些和rails没有直接关系。
相关网址如下

http://www.china-pub.com/30059&ref=ps

http://www.douban.com/subject/1422056/

如果想学rails，这两本书都要买。
《Ruby for Rails 中文版》用来快速掌握ruby语法。
学习起来更容易，完全是针对rails而学ruby。
跳过很多不直接相关的技术问题。适合rails的新手。

《Programming Ruby 第二版 中文版》用来做ruby的参考手册，有什么不明白的可以去查查。
不过，如果想真正掌握ruby这门语言，而不仅仅是rails方面，那么还是要多这本书。

这两本书我都有，我也都读过，所以不是空谈。
如果你在上海，我也可以把书…….借给你看看，呵呵呵呵。

希望能真的帮到你。
Ery
—————————————-
我要说的，怕是有点不搭调。
首先很钦佩楼主的学习热情。不过从目标导向来看，我觉得楼主可以走合作这条路。利用你的律师工作经验，将你的idea让rails使用者帮你实现。至于个人要不要通过学习rails进而开发感兴趣的网站，我倒认为其次。
打个比方，一个好的idea，通过合作可以2周实现，如果自己干，从头开始，1个月实现，可能还问题多多，你觉得哪种更划算呢？
当然认同你的idea并且有rails技能的未必那么好找，但是志同道合者未必很少。
术业有专攻。这话应该有它的道理。

– Qi Xiang
—————————————-
没有什么捷径，只是哪种方式更适合你。如果想尽快看到效果，照着书上的例子就可以了，不过以后你会发现基础还是比较重要的东西；如果想真正去了解它，建议从基础学起，在学习过程中尽可以用自己学会的东西去实践，这样会有更大的帮助。

– 马玉潮
—————————————-
呵呵，太喜欢这个讨论主题了。

我的理解这是一个”学习的困境“。
首先，楼主一定会很勤奋，说不定比很多人都更加勤奋。不惜投入时间精力。
其次，楼主花费更多的时间精力寻找”捷径“，因为勤奋的楼主认为时间总是不够，希望加速学习过程。

大家其实总结的已经很棒很全面了，放弃寻找捷径吧，学就对了。一段时间，就会非常清楚目标方向了，但是不尝试，很难明白到底什么方法更合适自己，祝楼主好运。

Best,
Daniel Lv
—————————————-
看标题还以为是Barry想亲自动手作一个rails网站呢。
如果想监督rails工程的质量，那么要看他们用的插件多不多（vendor/plugins目录下）。如果插件用的多，但是对于代码却不清楚，那么说
明他们只是rails的初级用户。
如果对于使用工具的源代码不了解，很有可能会出现意想不到的问题，就是《实用主义程序员》告诫的“不要靠巧合编程”。我刚用rails作项目的时候，也
曾经安装了插件结果造成系统出错。
如果想编程入门的话，其实Ruby语言缺乏这样有趣，引人入胜的入门书。以前我对编程十分惧怕，C代码超过200行就看
不懂了，看了之后，方有“原来编程是如此简单，如此快乐的事情啊”这种感叹。

– Jiang Wu
—————————————-