Year: 2009

爱做菜,爱生活

凡事皆有学问,好恶与否,基本取决于兴趣。若没有兴趣(也就是“趣味感”),便成了负担,相反,则乐在其中。我以为,做菜就是很有意思的事情,尤其是,每每在外面饭馆尝到好吃的菜,就有兴趣做“逆向工程”,回来悉心揣摩,竭力仿制,“仿到位”的一瞬间,成就感是无与伦比的。
可是自己埋头尝试,苦闷太多,终究不如“仙人点拨”。所以做菜本事了得的曹哥答应带我去餐馆后厨转转,就非常让我高兴。清明假期,去后厨看了半天,羡慕人家通明透亮的环境,琳琅满目的辅料,得心应手的工具;除了知道一些菜的详细做法,最重要的收获,还是悟道一些做菜的原则。道术相比,还是“道”更为重要,下面就列出我认为重要的几条原则吧:

做菜应当有想法。

做菜不是条件反射,要做好,心里必须有想法。好的摄影家在按下快门之前,必得有构思:这是一张怎样的照片,要表达怎样的含义。好的厨师也是如此,一道菜,在做之前,必须能想象,这道菜出锅之后的样子,是何种色泽,何种质感,何种香味——一句话,这道菜“到底是个什么意思”。把这一点想明白了,菜做起来就有了大的方向,其它各步、各细节,都以此为标准,为这个方向服务。
譬如,湖南菜里有一道“剁椒蒸芋头”,蒸出来,小小的芋头应当是晶莹粉嫩,具备独特的清香,配上剁椒,主要是为了冲淡颜色的单调,剁椒的味道其实不很重要。

做菜应当了解物性。
食料五花八门,各有各的物性。厨师要能够驾驭各味食料,实现自己内心的想法,就必须充分了解食料的物性,然后才能选择、搭配。举个简单的例子吧:同是常用的加香料,葱、姜、蒜却各有不同,若不了解它们的特质,它们对菜品的影响,不管三七二十一,都拿来直接下锅,就会破坏菜品本身的感觉(主要是味觉和嗅觉)。再举个例子:萝卜丝多见炖汤而少见清炒,土豆丝多见清炒而少见炖汤,这是由菜品的物性所决定的。更细致一点说,同是茄子,南方茄子软,北方茄子硬,大棚茄子水分多,所以有的适合煎,有的适合炒,有的适合蒸。如果对此毫无了解,不问出处,以不变应万变,结果必然就是败坏了菜品的口味。

做菜的火候很重要。
如今我国已经成为“食品添加剂大国”,超市里,各种调味料玲琅满目,让人目不暇接。然而要把菜真正做好,依靠调味料是绝对不行的——调味料确实能“提鲜”,但各种菜品都“提”出同一种“鲜味”,更不用说令人担心的健康问题了。相反,菜品本身是复杂的综合体,包括味觉、色觉、嗅觉、触觉等多方面的因素,要把握好这些,重要的就是火候。
所谓火候,主要指两个方面,一是火力的大小,还有就是加工的时间。两者互相关联,但不可互相代替。大体来说,火力决定菜的质感、形状,加工时间决定菜的生熟。
餐馆的肉菜做得鲜嫩可口,除了事先腌制的因素之外,也与火候有关:餐馆的灶台,火力大多很猛,下锅之后就可以让肉表面的蛋白质凝固,既能保持肉片的形状,又可以锁紧内部的结构和水分,翻炒几下便可出锅。而家里做菜火力大多不够猛烈,即便放了很多调味料,鲜美可口,终究缺乏质感,原因就在于此。要在家解决这个问题,切肉的时候就得有讲究,而且,一次绝不可下锅太多——这样,才能真正把握住火候。

还是那句话,凡事皆有学问,做菜也不例外。虽然它只是日常生活的一部分,但讲究也很多:我们去不同的人家吃饭,会觉得有些人家的饭菜很可口,有些人家的饭菜就很乏味,其实,这也是一种生活态度的表现。对此,曹哥有句名言:喜欢做菜的,都是热爱生活的人。

P.S.
曹哥跟人合伙开的新店,名叫“痴心不改”,英文注解是:Once & Always,我在厨房研习的时候,忽然想到另一条:Flavor, Forever,大家觉得如何?:)

老高之野望

本期beta技术沙龙的主题是“手机之家新系统介绍及架构分享 ”。手机之家是老高(高春辉)一手创办的网站,在我的印象里,上一次记得高春晖还是他的“高春辉的个人主页”,之后,好像就一直在折腾手机之家。现在的手机之家,每天PV超过700万,作为一个手机专业网站,相当了得(从我看到的数据,远远超过友人网)。

因为堵车的缘故,我赶到活动现场,演讲已经过去了大半,只抓住个尾巴。不过,手机之家有7年的发展经验,浓缩到这小小的讲座,即便只窥到一鳞半爪,也是很有启发的。

印象比较深刻的一点是Cache的结构。通常,Cache都被“扁平化”为单层的key-value对,这样的好处是,Cache的用户都可以方便地使用,没有太多的限制;而坏处在于,数据的结构被完全拆散了,同一个对象可能会按照不同的key来存储,而且各个对象之间的关联完全不存在了。
对这个问题,手机之家的解决办法是,在Cache和应用程序之间增加一个管理层,将程序员与Cache隔离开来,程序员可以不关心Cache的机制,只需要按照namespace(也就是划分层级的规范)来开发就可以。这个管理层,可以实现对Cache中对象的批量操作,也可以在某个对象发生变化之后,更新相关联的对象(直接更新父节点)。
这种办法的效果不错,而且演讲结束之后,还有朋友专门提出关于namespace的问题,看来,大家都觉得这思路很巧妙。

另一点印象就是老高他们重点介绍的DAL,也就是Data Access Layer,它把存储和缓存整个装到一起,与业务逻辑层完全隔离——业务逻辑单元完全只需要按照DAL设定的“增、删、改、查”四个接口操作数据就可以了。虽然普通的DBMS(譬如最常见的MySQL)也提供了这四种操作的接口,但相比DAL,一方面缺乏高效的缓存管理,另一方面,在大负载量、大容量下应用,还需要做许多工作;而有了DAL,前端程序不但不需要关心表的设计和结构,甚至连表的切分都不需要关心,相当省心。目前的DAL可以应付手机之家的现状,但PPT中也介绍了DAL 2.0的若干构想,包括提供类似Lucene(也就是全文检索)的查询功能,以及拆分核心功能、兼容插件的架构。
看得出来,DAL好像要从一个为手机之家打造的模块,变成“通吃(兼容)各家网站”的工具,在过去,有手机之家的经验做积累,对于未来的走向,也有明确的规划。我觉得,这是一条有风险、也有前途的路:一方面,对于通用组件的开发,我时常感到头痛,也许是经验不够的缘故,事先定义好的接口,往往(必然)被新冒出的需求所困扰,或者修改接口,或者眼睁睁把新需求踢出自己的“一亩三分地”,承认自己干不了;另一方面,之前固然有LiveJournal造出memcached的例子,但这样的几率实在是不高,况且,国内开源软件的氛围也与国外大不相同。
不过,无论如何,我都很佩服老高的这种“野心”:敢想才能敢干,而且,如果DAL真的能成功,成为“现成”的解决方案,就能省下大量的资源,投入到更有意义更有价值的地方,这绝对是一件功德无量的事情。

有兴趣的朋友,可以参考活动的PPT🙂

手机之家的架构分享
beta沙龙-手机之家架构的发展和变化
与”手机之家新系统介绍及架构分享”有关

P.S.手机之家还在招聘 PHP/Java 人手,有意者给老高发邮件: gaochunhui (AT) gmail.com

上帝的归上帝,程序的归程序

程序员,就是整天与机器打交道的那群人。
在计算机并不普及的年代,这样的描述毫无疑问;然而,这些年来,得益于计算机成本的不断下降,软件使用门槛的不断降低,如今,昔日昂贵而又神秘不可莫测电脑,已经成了随处可见、人人能用的办公器材。一句话:人机交互不再是程序员的专利。大家都可以用电脑干活,只不过,程序员用电脑写程序,其他人用电脑干其它事。
结果,普通人抱怨的问题,程序员也在抱怨:电脑不够聪明,不够智能,效率太低……

可是,电脑真的进化到了对程序员和普通用户“一视同仁”的地步吗?

我不由得想起,上个世纪80年代,温伯格在《技术领导之路》中提出的疑问:

(开办技术领导力学习班)也让我们产生怀疑,技术在当今社会扮演了重要的角色,我们的学习班,是否赋予了某些人太多的力量?

细细想来,那个时候IT是高深的技术,只有少数人能够接触,因而程序员“理所当然”地借助了IT的东风,具有超常的力量。可是如今呢?与常人无异的程序员(或者说,IT技术人员),他们身上让人担心的“太大的”力量,到底是被淘汰了,还是没有发挥出来?

对这个问题,不同的人或许有不同的看法。不过,读过The Productive Programmer(中文版《卓有成效的程序员》)的人,多半会选择后一个答案。

The Productive Programmer是一本奇特的书,它的Productive(也就是“生产力”),与新的语言、新的框架、新的系统完全无关,而是另辟蹊径:它只是提醒读者,作为程序员,你与普通用户是不同的:其它人只是简单地“启动”程序,而你完全可以动用自己的专业知识,“驱使/调度”那些程序。这样的机会,普通用户想不到,也不愿意抓住,但是抓住它们,你的生产率就会成倍上升。所以,这本书叫做The Productive Programmer,而不是The Productive Computer-User

薄薄的一本书(英文版224页,中文版215页),共分16章,兼顾概念和实践两个方面,既介绍了加速、专注、自动化等等提高生产率的“先进”思维观念(譬如“多用键盘少用鼠标”,“消除干扰集中精力”),也给出了在设计、分析、构造、元编程、多语言编程等等多种任务中贯彻前述思想的若干实例(譬如“用全面测试保证质量”,“选用最省事的方式/语言完成任务”),可以说是“麻雀虽小,五脏俱全”了。

不过,看完整本书,我最深刻的印象还是贯彻全书的思想。说白了,就是尽量让机器做机器该做的事情,让程序和程序打交道,发挥程序员在这方面的先天优势——他人眼中的普通工具,是程序员手里的有利武器。

不信你可以想想,虽然如今人机交互的难度已经大大下降,然而程序终究是程序,“程序跟人打交道”与“程序跟程序打交道”,效率差的不是一星半点:

不用宏,你可能需要一次又一次地重复选择、修改、保存;
不用脚本,你可能需要一次又一次地点击、配置、等待;
不用自动化测试,你可能需要一次又一次地运行、调试;
不用管道,你可能需要一次又一次地生成、删除中间文件;
……

The Productive Programmer则会“教导”你:

多用宏吧,启动它,你就可以迅速完成大量重复的工作;
多用脚本吧,你可以提高运行的效率,避免变数和误差;
多用自动化测试吧,你可以迅速定位问题,保证质量;
多用管道吧,这样多个程序就可以“无缝结合”成一条生产线;
……

没错,学习宏、脚本、自动化测试、管道(Shell),不是“容易”的事情。但别忘了,身为技术人员,了解技术,学习技术,运用技术,正是你的职业、你的优势,也是你的责任、你的生产力(所谓productive)所在。随便举个例子吧,在本书中文版的第196页有这么一段话:

……在我刚才提到的例子中,开发人员用了1小时58分建立正确的语法,然后用了不足两分钟运行。在一些未曾培训过的人眼里,他的大多数时间都没有效率(这就是为什么他们反对使用正则表达式的原因),但最后,他节省的是几天的时间!……

我还要补充的是,解决好这样的问题,“现在”能节省几天的时间,将来,更可以节省无穷无尽的时间!就我的开发经历来说,平时多注重这样的细节,做些“没效率”的事情,积累起来,就可以节省大量的时间和精力——最起码,你不再会抱怨,自己终日被一大堆“简单重复劳动”所困扰。

类似的例子,在书中随处可见,譬如作者讲到,“几乎每个*nix用户,都会有自己的shell alias”,真是于我心有戚戚焉:我自己积累了一大堆alias,喜欢用grep –color把要找的内容标成高亮,也喜欢在统计脚本里用不同的颜色标注不同的状态……在Shell下干活,更加简单、利索,一目了然,这种流畅和效率,也可算专属于程序员的宝贵财富。不厚道地炫耀一下,我还有程序定期自动备份我的blog文件和数据,有程序把下载的有声资料“统一”为广播音质mp3(节省空间,同时更新/修正id3信息,调整音量)方便导入随身听……

当然,也有读者会觉得很烦:作者每讲一个很小的例子,几乎都要强调一遍:“简单重复劳动是低效的(程序员不应该这么干)”。不过,我丝毫没有觉得罗嗦,反而因此喜欢上这本一个下午就能看完的“轻量级”小书:阅读它,你并不需要太多的期望,权当一次愉快的思维体操吧——你会发现,专属于自己的高效率,就来自书中提到的点点滴滴。

Gmail的故事:Founders at Work节译【续完】

欢迎转载,转载请注明出处。

Founders at Work, Chapter 12

Yurii 翻译

Livingston:你提到,Gmail最开始是“有争议的”,能接着说下去吗?

Buchheit:我觉得,一般来说,人们会不太适应不一样的东西。即使是现在,我谈到给Gmail增加新特性,除非是很小的改动,或是不改变现状,只做些调整,否则大家都不会喜欢。人们对“可能”的理解非常狭隘,相比真正的可能性,对于“可能”,我们的思维有许多局限。所以他们会不适应,他们有点喜欢想尽办法来反对。
但是我个人更钟爱新的东西,所以我总是非常愿意看看会发生的事情。这是我加入Google的最大理由。这理由足够强,强到我确信这是一桩好事:我只是觉得这很有意思,看到将要发生的事情,我很激动。
就这样,Gmail之所以让我激动,也是因为想看看大家会是什么反应。我喜欢某些不确定,因为这有点悬念、有点激动,好像是冒险,对吧?即便没有做成,你也可以从中学到很多。但不是每个人都喜欢冒险。许多人好像就是讨厌不确定。在生活的每个方面都讨厌不确定。
我忽然想起来,某段时间我问大家,如果他们在玩俄罗斯轮盘赌,有一把枪,枪有10亿个弹筒(或者非常多的,也就是说,他们被杀的可能性微乎其微),他们愿意花多少钱玩一盘?许多人都觉得这个问题很不礼貌,他们回答,“给我多少钱我也不玩”。但我们其实每天都在玩这个游戏。他们开车来上班,挣工资,其实一路都是在冒险,但是他们不希望知道自己其实在冒险。他们希望自欺欺人,假装一切都与风险无关。

Continue reading Gmail的故事:Founders at Work节译【续完】

Gmail的故事:Founders at Work节译【续三】

欢迎转载,转载请注明出处。

Founders at Work, Chapter 12

Yurii 翻译

Livingston: 那时候Google一门心思关注搜索,你有没有担心过自己的项目被抛弃?

Buchheit:一直都是。我还得说,现在看来Gmail很不错,但我们开发是很早时候的事了。Gmail是第一个真正偏离单纯“web搜索”的产品。Groups其实也依赖搜索——只不过它搜索新闻组里公开的帖子。

Livingston:Gmail还必须要邀请才能加入吗?

Buchheit:不用,你可以用手机申请。

Livingston:也可以通过Blogger,对吗?

Buchheit:我们已经向许多不同的方面开放了。大学生可以申请,我们希望开放给学生。

Livingston:为什么要邀请加入,这背后是怎么想的?

Buchheit:理由有好几个。我又得说一遍,邮件的问题很麻烦,不只是在数据规模那些方面。有个问题很重要,那就是,我不希望数据有任何损失,因为没人愿意弄丢邮件。如果web搜索出了问题,你可以退回去,重抓一遍网页,但是邮件不同,一旦丢了就不可挽回。
我非常关心系统的稳定性。策略之一就是控制用户的规模,这样就不会超出限制。你必须时刻确保当前用户享受到优质的服务。同样,这做法也约束了某些滥用email的行为,举例来说,这样发垃圾邮件的人就很难获得1000万个帐户——那样的后果很糟糕。

Continue reading Gmail的故事:Founders at Work节译【续三】

Gmail的故事:Founders at Work节译【续二】

欢迎转载,转载请注明出处。

Founders at Work, Chapter 12

Yurii 翻译

Livingston:还有哪些新特性是独创的?

Buchheit:对话视图——你打开某个对话,其中的所有邮件会像卡片一样列出来,而不是单独出现。

Livingston:这是你想出来的?

Buchheit:其实有好几个原因。其中之一是,我曾做过Groups,那里同样有归类(threading)。另一个是,我们内部有太多的邮件。
如果没有会话,就会出现这种情况:有人发出了一封邮件,有四个人回复了,五个小时之后还有人在回复,其他人会觉得,“这已经重复谈论过五次了,你还要回复。”
据我们观察,人们费那么大力气管理邮件的原因之一在于,他们尝试把对话归拢到一起。他们把邮件放到同一个文件夹——否则就会忘记,或是放错文件夹,对话就完蛋了,再也没法回复。
大家用各种工具和诀窍来管理会话。为什么不把它们直接归拢到一起呢?后来我们又想到,“我们来把引用他人的邮件内容隐藏起来吧”。因为这样阅读速度更快,而不需要浪费精力。我们同样希望集成IM聊天。做第一版的时候,我们没时间集成那个功能,但是很早的原型中就有聊天功能的,因为我们希望把聊天和email做到一起,这两者是一体的。所以,我们会从聊天的角度来看待email,所以我们给聊天加入email功能,而不是走其他的路。显然,聊天是为谈话服务的——没有人受得了分割成一条条的聊天纪录。所以,谈话视图也是从此而来——有段时间我们甚至把email的格式设定得更像聊天。

Continue reading Gmail的故事:Founders at Work节译【续二】

Gmail的故事:Founders at Work节译【续一】

欢迎转载,转载请注明出处。

Founders at Work, Chapter 12

Yurii 翻译

Livingston:这么说,你花了一天来做Gmail,而你不知道自己在做的事情的意义——之后呢?

Buchheit:很长时间里就只有我一个人,然后Sanjeef Singh加入进来。但是,在Google更换项目,尤其是那时候的Google更换项目,并不容易。不是说,某一天你就忽然去做一个新的项目了。那时候他正在做企业搜索,所以他还得花很多时间在企业搜索上。过了很久,Sanjeef才把大部分时间用在Gmail上。所以有很长的时间,Gmail的进展非常慢。
开始主要是我,然后是我和Sanjeev,之后另一个家伙Jing Lim也来了。团队的增长非常缓慢。做一个email那样迥然不同于Google传统的东西,这想法人们还是不太确定。

Livingston:你宣布:“这是了不起的东西,我们要发布了”。这是什么时候?

Buchheit:是发布几天以后。这项目很大。有些时候,我们似乎根本不可能完成它。

Continue reading Gmail的故事:Founders at Work节译【续一】

Gmail的故事:Founders at Work节译【待续】

Founders at Work是一本有意思的书,讲述了若干有意思的创业故事,我看得兴起,顺手把访谈Gmail创始人Paul Buchheit的一章翻译出来,给有兴趣的朋友看看。

欢迎转载,转载请注明出处。

Founders at Work, Chapter 12

Yurii 翻译

Paul Buchheit是Google第23名员工。他创造并领导开发了Google的Web邮件系统,Gmail,该产品引领了当今所谓“Web2.0”的众多特性。除此之外,Buchheit开发了Adsense的第一版原型,Google依靠这个程序在其它网站显示广告。在2000年一次关于公司价值的一次会议上,他提出了现在众所周知的公司信条:不做恶(Don’t be evil)。

尽管Buchheit算不上创始人,但他对Google的贡献,可能比其他许多创始人在创业时的贡献更大。Gmail其实是在Google内部诞生的——这是一个传奇般的项目,起初,它并不是公司的主要业务,只是由一小群人发起,而且,许多人开始并不看好它。

Livingston:讲讲事情的开头吧。Gmail是非正式项目(side project)还是公司指派的任务?

Buchheit:实际上两种因素都有。我很早就在做Email软件,当时大概是1996年,但只是个小项目。但Gmail的想法从来没有实现过。奇怪的是,大概因为一些别的理由,那时候我似乎就想叫它Gmail。这只是凑巧——它并不必然是Gmail的前身,却是我一直在思考的,因为我长久以来就对email不满意。
那时候我在学校念书,还没有hotmail。要看邮件,你得回宿舍。我想,这可真够傻的,我应该能在任何地方检查邮件。所以就想做基于web的邮件。我真的不知道那时候自己在干嘛,因此也没什么结果。我写了点程序,但一直没什么用处,也从来没投入实用。
中间内容就不提了,直接说最后:我到了Google,为Google Groups工作,groups和email不完全一样,但是有关系。等Google Groups的第一代产品差不多完善之后,他们问我,是否愿意开发某种email或是针对个人的产品。这只是一个粗略的意向。他们只是说:“我们觉得这类东西有点意思”。当然,我很高兴干这个。

Continue reading Gmail的故事:Founders at Work节译【待续】

技术的力量

现实的世界这么复杂,上帝到底起了什么作用?
有人说,上帝就是创生世界的第一因,他是这个因果链条的第一环,然后世界就“自顾自”地出现了;
也有人说,其实因果链条上的每一环,表面看来是逻辑联系,其实都是上帝的意志;

这个问题我们不回答,我们能确定的是,在这个高科技的社会,生活中的各种事务,背后都是技术的“意志”;正因为如此,温伯格在《技术领导之路》中说,在这个时代,技术人员拥有强大的力量,只是需要发掘自己技术(技术知识)的价值,所以他还会花专门篇幅讲到力量转换。

今天写上面的话,是因为今天又看到有朋友在不厌其烦地详细介绍wordpress的维护。我想说的是,作为技术人员,不妨多动些脑筋,想想如何依靠技术解决更广泛的问题。譬如Wordpress的维护,我之前也饱受折磨,某天终于发现,PHP可以直接调shell,shell里面又可以直接调mysqldump——这样,只要简单几个Web页面,就可以完成wordpress的升级、文件备份、数据库备份和恢复,再通过Cron,就实现了blog的定期备份和日常维护,从此高枕无忧。

技术的力量,其实无所不在。