“暮春三月，江南草长，杂花生树，群莺乱飞……”，又到招人的季节。坊间招人的英雄贴，渐渐地多了起来。以下便是一则。

PtMind是由一群来自中国、日本的年轻人共同组建的互联网数据分析公司；我们长期致力于互联网数据统计、挖掘领域；目前PtMind已在中国北京、日本东京建立起相关的研发机构和市场机构。

我们正在招募 Erlang 好手，欢迎大家推荐，联系方式为：tony@ptmind.com
朋友们如有合适的人才推荐，入职后送ipad一部，略表谢意！[各位同学，这里是亮点哦]

PS. 北京本地的朋友们，公司报销面试来回打车路费(附带打车小票即可)
PPS. 一样欢迎外地工程师联系我们，公司报销外地到北京面试机票以及住宿费用；
[细节虽小，足见诚意呀]

附注：
1、所有的研发职位均在北京，均要求3年以上工作经验；
2、使用erlang开发实际项目最少时间为1年以上；
2、以下所有职位年薪均为20万起；

符合以下条件者优先考虑：
1、有统计产品实际开发经验；
2、有高并发、海量数据处理经验；
3、有系统架构设计能力；
4、有开源社区代码贡献；

—————————————————————–

职位：高级研发经理（erlang）
其余福利：依照国家标准（高级职位另附商业保险）
下属：5～15人
方向：网站数据分析后台部分；
职位描述： 从事海量数据和分布式（或并行计算）环境下的研发工作，同时承担部门
级高级研发经理职位；
岗位要求：
1、熟悉网站用户行为分析、广告类产品开发，36岁以下；
2、具备严谨的思维逻辑，能够独立带领队伍开展某个方面的研发工作；
3、精通erlang，使用过至少两种后端开发语言，如：JAVA，Python，C/C++；
4、熟练掌握linux集群部署，有过大数据量处理经验； 有分布式计算平台(Hadoop,Hive更佳)经验更佳；
5、熟悉HTTP，TCP/IP，面向对象及MVC，RDBMS，缓存技术等相关知识；
7、对产品设计和商业运营有一定了解，有与业务部门合作经验者优先；

—————————————————————–

职位： 资深后端开发工程师（ erlang）
其余福利：依照国家标准（高级职位另附商业保险）
下属：5～15人
方向：网站数据分析后台部分；
职位描述： 从事海量数据和分布式（或并行计算）环境下的研发工作；
岗位要求：
1、36岁以下，计算机或相关专业本科以上学历，三年以上Web后端开发经验。
2、精通erlang，使用过至少两种后端开发语言。（如：JAVA，Python，C/C++等）。
3、熟悉HTTP，TCP/IP，面向对象及MVC，RDBMS，缓存技术等相关知识。
4、熟悉常用算法与数据结构，具有Linux上的开发经验，能够编写常用Shell脚本。
5、掌握XHTML，CSS，JavaScript，Ajax等相关技术。
6、具有大数据量高负载产品/系统的设计或核心开发的经验。
7、热爱互联网技术，有很强的技术钻研精神与学习能力，具有技术创新的热情。

—————————————————————–

职位：高级开发工程师（ erlang）
其余福利：依照国家标准（高级职位另附商业保险）
职位描述：
1、负责网站开发及运维；
2、数据库应用开发及优化；
3、前后端的架构设计和开发；
职位要求：
1、具有良好团队合作精神，有高度的责任心，能带领项目组完成整体工作；
2、精通erlang，且有着多个项目开发经验，掌握对应技术的设计模式以及主流框架，能独立完成相应的扩展开发；
3、精通MYSQL数据库应用系统设计及优化，熟悉存储引擎及存储过程；
4、LINUX操作系统的常用命令操作和应用系统部署、运行维护；
5、了解互联网新技术及发展发向；

—————————————————————–

公司网址：www.ptmind.com
联系方式：tony@ptmind.com

[对了，本着为圈中朋友提供便利之原则，本站“代客猎头”。靠谱的招聘方可以和我联系。何谓靠谱？请参考上面这条。]

先上亮点：

High Productivity

Compact query syntax:

boss_db:find(person, [age > 25])

Elegant controllers:

edit('GET', []) ->
ok;
edit('POST', []) ->
{redirect, "/somewhere"}.


Simple data models:

-module(person, [Id, FirstName, LastName]).

full_name() ->
FirstName ++ " " ++ LastName.


Rails-y records:

Person = person:new(id, "Joe", "Blow"),
Person:save()


Django templates:

{% for person in people %}
- {{ person.full_name }}
{% endfor %}


Easy Comet – New in 0.4.5

BossMQ introduces a simple API for sending and receiving messages. Here is a complete long-polling chat backend:

send_chat('POST', [Channel]) ->
boss_mq:push(Channel, Req:post_param("msg")).

receive_chat('GET', [Channel]) ->
{ok, Time, Messages} = boss_mq:pull(Channel),
{json, [{time, Time}, {messages, Messages}]}.


With BossMQ, any controller action is a potential Comet endpoint. Thus, Comet endpoints have complete access to your entire application — databases, templates, the whole stack.

High Reliability

100% asynchronous network I/O

• Under load, uses less RAM than synchronous apps (PHP, Rails, Django)
• Comet long-polls won’t block the app server
• Single-process model keeps CPU context switches to a minimum

Supports both SQL and schema-less databases

• MySQL
• PostgreSQL
• MongoDB (NEW)
• Tokyo Tyrant
• Mnesia
• Or write your own adapter — usually ~300 lines of code

Operational simplicity

• Zero downtime code upgrades in production (NEW)
• Standalone server does not require Apache, Nginx, etc.
• Direct SMTP mail delivery does not require Postfix

Unique testing framework

• Closure-based tests reduce test code size
• Run functional tests in-memory — no network I/O
• Integrated web and email testing

Future plans (not yet implemented!)

• Full OTP compliance
• Full test coverage
• See the Roadmap

好吧我得承认，其中的一些亮点其实是来自 Erlang 语言本身的。

毫无疑问，这个项目提供了 Erlang 和 ruby on rails’ way 的跨界组合优势。比如说，在采用高生产力的 rails 方式来构建项目时，如果心存疑虑，担心某一天会被可能的性能问题跳出来反咬一口的话，那么现在又多了一个具有 FP 风格的选择了。

有必要表扬一句的是：chicago boss 的文档整理得相当靠谱，单就这一点而言，在众多的 Erlang Web 项目中，就很有走红潜质。此外，开发过程似乎也可圈可点，按照 roadmad 的特性持续升级，很让人看好。不过也有的地方让人感觉有点奇怪，比如说，源代码竟然是要下载的，而没有用“开源工业标准”的 github ，这多少有点让我不适应。

顺便 blah 一下，如今这世道， web 开发似乎已经渐渐地在更多转变为前端以 jquery 为基础的 ajax 开发了，换句话说，前端正在静态页面化。而所谓的后端系统也已经相对标准——更像是 restful 的 CRUD 接口再加上薄薄的一层业务逻辑。前端与后端之间的接口方式与约定已经相当之稳定。那么，比如说，有了 chicago boss 这么有生产力的架构，在后端性能开始吃紧的情况下，趁着系统升级的机会，简单地整一把，平滑地将后端系统“迁移”到更高效的平台上，未尝也不是一个不错的升级方向嘛。

先说被震出“内伤”的地方：成本。Arduino 的核心，是一块 Atmel 公司 AVR 核心的芯片。比较 NB 的是整个核心系统就只有这么一块芯片和不超过十个的外围元件而已。芯片本身只要 20 元左右 RMB 就可以从淘宝拍回来了。在我这个外行看来，这确实是一块神奇的芯片——几乎所有你能想到的“一台电脑”应该具有的东西：CPU，RAM，IO，FLASH，它都已经给你做到芯片里了，那些外围元件基本都是打酱油的。基本上，一个芯片上就是一台“全功能”的超微型电脑。而且，功耗非常低，几节电池都能带起来，还能跑很久。再而且，这个玩意儿已经量产了很多年，成熟得不得了(再次觉得自己 OUT 了)。还而且，作为一个软件工程师，最重要的当然是，它是可以编程的，而且配合了 Arduino 的开发工具之后，可以用类似于 C 的高级语言来编程，然后一键“装”到芯片里去，变得非常简单。

说回上面提到的电饭煲——从成本角度，如果说电饭煲里加一个 x86 的 CPU 确实有点儿痴人说梦，那么在电饭煲里加这么一个 20 元左右的 AVR CPU 就完全没有什么不可以的了，不是吗。

好吧，这是一个便宜到可以放到电饭煲里的电脑。那么，用途？可以拿他来干什么用？自己翻墙到 Youtube 上用 Arduino 做关键词搜搜看吧。从无人驾驶飞机到 Segway 再到激光吉他还有电子快门等等，简直应有尽有，就差战斧式自动巡航导弹了(现在都有 GPS 模块了，估计这个做起来也没多难)。查了一下，国内的玩家们似乎大多都是将 Arduino 当做是“机器人”的开发平台，搞得好像“很学院，很高科技”的样子。在我看来，这似乎还是太装了。比如说，我现在住在村里，成天都要和“全手动控制”的上古太阳能热水器费劲，用 Arduino 来做一个“很农村，很低科技”的控制系统，也未尝不可嘛(有人已经做了一个，俺来晚了，哈哈)。

这一次是意大利的哥们用 Atmel 的 Atmega328 捣鼓出了 Arduino 形成了一个解决通用问题的计算平台。其实类似的事，在计算机的历史上，也曾经华丽地发生过。比如，当 Jobs 和他的哥们在车库里用 Motorola 的 Z80 捣鼓出 Apple I 的时候。又或者 IBM 的哥们用 Intel 的 8088 捣鼓出 PC 的时候。这类事情的实质就是通用系统作为“平台”解决了计算机应用的“门槛”问题，因而，在此之上，各种语言、库、解决方案被陆续发明出来，一旦到了这个阶段，它的广泛被应用也就可以预期了。

这一波计算机领域的 DIY 潮流，被冠以 physical computing 的新名词。想想也是，当 CPU 被装在电饭煲、台灯、玩具，这些东西里时，你确实会觉得这些物品也开始学会计算了。好吧，既然是从 Erlang 完全跑题了，那么，还是在结尾的部分拐回来一点点吧。

这是 Arduino 的 Hello World (让某个 LED 闪烁)

如何？这种 setup – loop 的程序结构，是不是让你想起了 gen_fsm 呢？

有兴趣的硬件 hacker 们可以点[这里]扩充阅读。

[ slides videos ]

上次在上海办的，没有去成，这次在北京，无论如何，抛下一大堆事情还是去了。感觉很好，非常之好，但是你又很难跟人讲清楚到底好在哪儿，组织、演讲、提问、茶歇、闲聊……，样样都好，但似乎让人感觉超好的又还不止是这些而已……，具体是什么，我说不上来，还是得大家亲身去感受才行。

这次大家的 Topic 密度都很大，就好像你还没站稳，对方就势大力沉地给你一个降龙十八掌，如果没被砸晕的话，你至少也得腾腾腾地退个十步八步才能站得住。而且，每个人讲的东西都很不好消化，以至于，我这里趁着每日清晨思路最为敏捷之时，勇猛精进地消化了这许多天，也只能大概其地理出一个思路，还得赶紧动笔写下来，以免一会儿又犯糊涂了。

下面开始 Blah …

个人觉得，此次会议 xushiwei 同学关于“不局限于 Erlang 语言”的设想，已经完全实现了，大家的视线已经纷纷“超越了语言”，开始关注更高的目标。然而，很难得的，这样的关注也没有流于泛泛而谈。几乎每个演讲者都在从自己独有的视角，带领大家一起探寻神秘的“程序设计之道”(延伸阅读：[ zh en ])。两天高强度的听下来，让我几乎有了一种错觉——虽然还没有能够亲身体会到“程序设计之道”的深邃，但至少近距离地目击到了在它周围如意流转的五彩祥云。

所谓“程序设计”，就是用写程序的方式让计算机来帮我们解决现实问题。程序设计的“道”，在我看来，就是关于如何漂亮地干好这件事的诀窍。“漂亮”是个很见仁见智的形容词，不仅关乎代码审美，而且也包含了运行高效，简洁流畅，团队和谐……等等，诸多意思，如果不做一下哲学思考恐怕是说不清楚的，而这个思考我还没有做，那么就点到为止吧，反正我的意思你懂的。“程序设计”的目标是“要解决的问题”，而其支点则在于“人+机器”，既然我们这里讨论的核心是“程序设计”，那么对于这个命题，不妨分别从“人”和“机器”两个方面来说事儿。

先从“人”的角度说。曾有智者说过，任何事，归根结底，都是人的问题。不得不说，这真是一句很好用的大废话，屡试不爽。“程序设计”，换而言之，采用什么“技术”(咱们中文的用词还真是虚无飘渺)，毫无疑问，首先要取决于你都有什么“人”。

• 0，因为预算有限，所以要采用“适合于团队”的技术(语言，模型，方案)才能玩得转。
• 1，因为人脑不善于处理复杂的东西，所以要采用尽量简单的技术(理解，表述，模型，方案，实施，接口，惯例)以免犯糊涂。
• 2，因为是人都会犯错，所以要采用“可测试”的技术，“尽早发现”这些不可避免的错误。而且，最好还“可以自动化测试”，这样你就可以让机器来帮你做测试(嵌套到梦的第二层里了吧)。
• 3，因为人的想法总是在变，所以技术要与这些变化隔离(开闭原则，问题域的业务原语)，否则 boss 的想法一变你就完蛋了。
• 4，因为多人协作容易出问题，所以要采用版本管理系统，让机器来帮助你合并每个人的更新(谁来 kick off 一下)。
• ……

说完了“人”，再来说“机器”。对于 CPU 而言，除了“计算”神马都是浮云，计算的输入和输出全部都是“IO”，无论这些数据是在 cache/ram/disk/network 中的哪里，说白了，只是不同速度的 IO 而已。对于现代的计算机而言，计算已经到了多核加速的阶段，相对成熟，而 IO 因为需要处理的数据量仍在急剧膨胀，所以提高其速度仍然还是难题。相对于它的运算能力而言，IO 已经成为系统性能的实际瓶颈。

• 0，你要解决的问题，是 IO 密集型的还是运算密集型的？分布式的网络存储、数据库、Web服务……，不用瞎琢磨，我们常见的大部分应用，对于现代计算机而言，大多都属于前者。
• 1，对于机器而言，唯有计算能力与 IO 能力达到良好的匹配才能发挥出最大的效率。数据离 CPU 越近，效率越高。对现代 CPU 而言，对磁盘 IO 先压缩再读写也已经是一个现实的选择。
• 2，无阻塞 IO，这意味着系统负责 IO 的代码可以一直处于最优运行状态。很多时候，消除系统中的 IO 阻塞比优化算法更为重要。
• 3，在多核系统中，存储的 CPU 亲缘性严重影响性能，运算在多个核之间的迁移意味着大量的低效 IO ，代价很高。
• 4，现代计算机的很多设备标准 OS 的默认设置无法发挥出完全的性能，需要不断调优。
• ……

前面已经提及，程序设计的道，就是用程序设计“漂亮地”让计算机来帮我们解决现实问题。然而，参与其中的人和机器对于“漂亮”的标准却是截然不同的。对“CPU”而言，“漂亮”的方案必然意味着针对硬件的高度优化，具体来说，在现在这个发展阶段，也就是如何实现 IO 与运算的“和谐匹配”，尽量让指令时钟别浪费在“数据的搬运”上。对“人”而言，“漂亮”的方案则意味着简洁与精巧，简洁会涉及各个层面：抽象、接口、代码、实施，精巧则意味着对业务领域的深入的分析与思考。从这个意义上说，我现在所能想到的各种编程套路，“DSL+Compiler”、“BussinessLogic+FrameWork”、“Script+Component”，它们似乎全都分布在以上述两个“美学标准”为坐标轴两端的区间之内。

如何取舍，最终仍然要归结到“人的问题”上。找到一个编译器大拿，不妨华丽地整一套业务 DSL 出来。如果只有几个经验值归零的码工在手，那就还是老老实实地码 Script 就好了。当然了，在管理上，关于质量控制，也就是对“人会犯错误”和“多人协作”的涉及也不可或缺，而且同样重要，只是我们这里不多探讨就是了。

最后，但并非最不重要的是“切蛋糕的技巧”。一个好的切法，亦即所谓的“正交”切分，可以做出“简单”而且“高效”的神奇系统。我们偶尔也见到过这样的系统，比如 Unix 的神奇 Shell ，又比如 Nginx 上的新兴 WebApp 框架(NonBlock IO + UpStream + SubRequest + Computing)。与之相对地，每一个问题都有一千个我们把它叫做陷阱的糟糕切法，每一个都可以让你痛不欲生，靠山山倒，靠人人跑。这样的系统我们每个人都能想起一堆，痛苦的记忆我们已经看了太多，不忍再看。可惜的是，“切蛋糕中的独孤九剑”仍然还只是神技，它的传承，仍然不为我们所知，似乎仍然还是密宗而不是显学。

blah 了很多，累死我了。

上述内容中的很多观点，在这次会议上，多位演讲者都已经谈到，我这里只是“复述+跑题”，被“引用来源”的各位，也没有严谨地一一对号入座，在此一并致谢。

其他
Erlang 的工作机会慢慢多了起来，比如，参会的“唯一”两个老外都提到他们在中国的 office 正在招人。还比如，某同学的庞大 Erlang 游戏开发团队也在迅猛扩充中。还比如我忘了做发布的这个英雄帖：

寻找一些在北京的特别是想换个工作的erlang程序员
联系方式：huangqbbs@yahoo.com.cn

然后，有人说了：
> ……社区09年上半年比较活跃吧，主要是因为zhao 翻译完《erlang语言编程》出版了，大家热情都很高。现在那些人估计都有点牛屎了，都在忙着怎办把erlang用到项目里去吧，因此也在社区里消失了……

汗~~！作为“牛屎”之一，特地从“牛屎海”的深处浮起来冒个泡，回应一下。

我确实正是在埋头把 Erlang 用到小小的项目里。而，我们搞技术的都知道，一旦深入项目的具体细节，就“不怎么好玩了”。需要面对大量“乏味的业务问题”，大多数问题也不会指向“技术的发现”。在项目这锅汤里泡上一圈出来，可能会得到一堆“解决业务问题”的小窍门，但肯定不会收获多少“解决特定技术问题”的深入思考。尤其是，如果一切以“多快好省地解决问题”为优先考虑的话，那么，用到的技术很可能大多都会是浅浅的，以体力活居多，没什么技术含量。这大概是难免的，说到底了，技术毕竟还是要服务于业务的。这次的 ECUG 没有什么“技术营养”可以和大家分享，很有些不甘心啊。不过，肯定还是会去参加的，又有一年没见了。大家，很是有些想念。

社区的活跃，或许是铺开来广泛应用的一个前奏吧，后面肯定会有一个潜水期的。还记得 2000 年左右，那会儿我在搞 PHP 也碰见过这种情况，论坛活跃了一阵子，也不知道怎么地，突然就沉寂下来。之后，过了好多年，PHP 似乎才慢慢地“火”起来。我个人从经验角度来看，一个语言社区，无论它活跃也好，不活跃也罢，其实始终也都是“一小撮”，大家其实也不用太在意的。当然了，如果聚光灯到处乱闪，还有一大票粉丝摇旗呐喊，那当然很“带劲”，自我感觉很时尚。但是，如果没有这些光环的话，那其实也没关系，因为大家毕竟不是混时尚界的，让人“掉到这口深坑里”的，仍然是那些些费解而有趣的技术问题，而不是计算机程序设计语言的今冬流行时尚风向标。借用某位同学之前在讨论到 Erlang 能不能火的时候说过过的话——最好的境界是“悄悄地进村，打枪地不要”，大家都低调地闷声发大财，那就挺好。

明天见了，各位。

各位 Erlang 的粉丝，赶紧行动起来吧。

[提交Topic]

[注册参会]

PS. 翻墙是所有技术人员必知必会的基本技能，上述在线报名表格乃是基于 google 的 spreadsheets 服务构建，如果无法顺利访问，请自行翻墙。

看戏点[这里]，推荐[订阅]此邮件列表。

以下为 BLAH，没时间的同学自行跳过。

就话题本身来说，这就和“中国到底是不是*敏感词*”一样，其实是“没有办法达成一致的话题”，因为从把这个句子拆成每一个单词开始，大家的理解就已经各不相同了。俗话说，一百个程序员中，可能会有一百零六种对于 OO 的看法(因为据说在程序员人群中人格分裂的比例高达百分之三)。就算是同一个人，在不同的时期，对于 OO 的看法，也会不同。

就拿我自己来说，在上学学 Pascal 的时候 OO 是“程序员吃饱了就开始追求美感”；后来工作用 ASP 的时候 OO 是“与完活没啥关系”；在 PHP 里 OO 则是“某些 OpenSource 项目怪人的做作”；后来改用 Java 了 OO 则变成了“精致与高效的完美统一”，而且毫无疑问是“编程世界里唯一的真理”；再后来接触 Javascript 后 OO 就被撞下神坛，成为“冗长与僵化”的路人甲(一起“路人化”的还有设计模式)；学了 Erlang 后 OO 又成了“没它地球转得更好”；到了现在，叛逆期过去了，再到另一个层面上看， OO 仍然是个“不错的抽象”。其实，或许 OO 一直没变，不断在变的，只是我对它的看法(我看到了它的哪一个侧面)，而且我不敢保证，再过一段时间，这个看法是否还能保持不变。

再说讨论这件事。很多人一起讨论某个问题，不要小看这件事，要做好了，这其实是一件技术难度很高的事，有人甚至为此特地发明了《罗伯特议事规则》，有兴趣的同学不妨看看，当领导的时候要用的哦。

从学习的角度来说，探讨问题，规则、素养乃至逻辑都在其次，我们更需要的或许是开放的视野与胸襟。如果一味站在自己原有的视角，固执地沿用熟悉的视角来 rule 这个世界的一切，这会是一个“永远正确”的人，但与此同时，这个人也一定会因为“永远正确”而显得非常乏味。勇于去学习并了解自己并不熟悉的背景知识，再站在对方的角度来理解对方的感受和逻辑，也许没有看起来的那么难。

对于讨论而言，唯有这样建立起来共识，参与各方才谈得上真正意义上的沟通，否则只能是“鸡同鸭讲”。不过，这对于“时间宝贵”的现代人来说，实在是太强人所难了。话说回来，如果我们每个人都这样，那么这个世界的绝大部分的对立与冲突或许就都解决了，那多没劲？ BLAH 完毕。

Erlang 在游戏业素有盛名，国内和国外有一些游戏或多或少的采用了 Erlang 系的技术方案。这是有原因的，一方面，这个行业在整个计算机领域中处于并发与分布问题的最前线，他们是最有动力去尝试用其他的语言来解决手头碰到难题的一群人。另一方面 Erlang 本身消息驱动的要素，与游戏这一特定的开发领域在抽象模型上又有着高度的重合。

五年前，DevMaster 上 Joel Raymont 的那篇《Writing Low-Pain Massively Scalable Multiplayer Servers》(中文版《轻松实现可伸缩性，容错性，和负载平衡的大规模多人在线系统》)，在整个技术领域引起了非常大的反响，某种程度上，起到了大大推广 Erlang 语言的效果。但是，由此而诞生的 OpenPoker 项目，从纯粹的开源软件视角上看，却不幸成为了一个“犹抱琵琶半遮面”的半吊子项目——没有社区、没有交流、没有文档，源码没有完全公开——作者本人还要靠着这个项目的咨询费来养家糊口，一个纯粹的单人开源项目。这实在是一件非常可惜的事。作为一条事后的章鱼预言家，我敢说，如果一开始就打定主意去做一个开源的软件，比如说，就象 CouchDB 的 Damien Katz 和 MochiMedia 的 Bob Ippolito 一样，把全副身家都押宝在 OpenSource 的商业模式上， OpenPoker 完全可能走得更远。

开源软件搞了这么多年，从一开始的 SourceForge 到现在的 GitHub 和 BitBucket 我们终于有了“开源并不只是把源码放出去就可以了”的共识。开源软件其实是一套软件价值观——以软件本身的质量为核心价值。同时也是一套开发组织管理的哲学——当最初的项目创始人耗尽了他的热情，软件可以轻松的移交到新的开发者手上，通过这种热情的接力，软件能够日渐完善和历久常青。它是围绕着软件本身，以程序员的诉求为重点的开发方式，有着一套完整的依托于互联网的方法和设施。开源最终会导向可进化的，更高质量的软件产品。在开源软件这团热气腾腾的五彩祥云之中，热情是其原动力，灵活的团队是其灵魂，充分而高效的交流和协作则是这种开发方式的固有特色，至于社区、文档、特性管理乃至源码本身，这些我们所能见到的“特色”都只是交流协作的某种“外在形式”而已。

对于 Erlang + OpenSource + Game 而言，五年以前的 OpenPoker 错失了一次绝好的机会，如果上天再给一个重来一次的机会呢？现在看起来，这个机会已经来了，那就是 PEMMOX (Project Erlang Massively Multiplayer Online eXperience)项目。

各位童鞋请自备梯子墙头围观

http://www.trapexit.org/forum/viewtopic.php?p=57004
http://groups.google.com/group/pemmox/topics

众位游戏界的 Erlangor ，请把你们带有中国风的 ID 加到 Authors List 中去吧。

但，从另外一个角度来说，每次这样的辩论，几乎总是能给我们带来一些新鲜的“猛料”。他们在辩论之中的引用、类比、或是提及，就像是一本好书末尾的“引用来源”列表(这个东西我们历来都不重视啊)。我们所要做的只是轻点鼠标按图索骥而已。这样的阅读通常都很让人愉快，因为它们每每都能给我带来“新鲜的空气”。不知其他人是否也有同感，或许是因为国外的治学风气更好(注明引用来源的好习惯)，又也许是语言的隔阂(这些好东西都是英文的)，再不就是我个人的理论基础太薄弱(太不喜欢读论文)，原因不太可考；反正单就我自己而言，每次阅读这些东西都能让我在受益匪浅(长见识啊)的同时又切身体会到与其他科技“发达国家”之间学术水平的遥远差距(人家几十年前的论文，对我来说根本就是闻所未闻)。

这一次，激烈的辩论发生在 Clojure 社区。大家可以点下面的链接围观(也可以当作提高英语水平的好“毒物”)：

• Clojure 辩论主战场
• BlogSpot 上的一篇好文
• Scheme Wiki 上的横向对比

照例，提醒一句，总是有些好东西在墙外，请自备工具。

在 CouchDB 狐狸书 中，作者 Jan Lehnardt 描述了一种全新的 Web 开发模式，有这样一句话来形容这种新的开发方式。

CouchDB has changed the way I think about developing web applications

在有着 10+ 年 Web 开发经验的我看来，尤其是在确实理解了他们心目中的开发方式之后，我觉得，这并不是一句阿谀奉承的面子话。而是，实事求是地说 —— 完全没有夸张的成分。

我在这里极其“概略”的介绍一下这种匪夷所思开发方式的若干基本要素：

1. CouchDB 是一个 NO-SQL 的“文档数据库”，以 B-Tree 提供 Powerful 的数据存储与访问能力
2. CouchDB 是追加型数据库，其内部以 MVCC 机制管理每个文档的不同版本
3. CouchDB 采用了一种没有中心节点的架构设计，数据可以以数据库为单位，在多个 CouchDB 节点之间互相同步，数据同步时，也用 MVCC 来保证数据同步的一致性
4. CouchDB 以 Http Restful 的方式对其中存储的文档提供最基本的 CRUD 接口，也就是说能够直接以 Ajax 方式使用这些接口
5. CouchDB 实现了服务端逻辑的扩展机制，即，可采用 JavaScript (也可以用其他语言)定义 View ，这个 View 会在 Server 端以 Map-Reduce 方式来运行，中间结果也被 B-Tree 保存，当数据变化时，只需重新 Map 此条数据即可保持同步。也就是说，一旦 View 定义好，查询结果就已经准备好了，取用之时，无须计算
6. 上述逻辑扩展机制的“服务端代码”也被储存在一类特殊的文档之中，简而言之，这些“服务端代码”在绝大部分的情况下，都可以被当作“普通数据”来对待，尤其是，同样可以在节点之间同步
7. 文档可以带附件，想带多少带多少，想带什么带什么，随便带，没限制。比方说，Browser 客户端会用到的 HTML、CSS、脚本、图片什么的

PS. 上面描述的这些正处在迅速的进化之中……包括身份验证，同步过滤，URL Mapping 等等，所有需要用到的一切，正在迅速被增加进来。

已经呼之欲出 —— CouchDB 将会进化成为一个 AppServer！虽然还处在非常早期的阶段，仍然缺少拼图的一些重要部分，但我们已经可以大致的窥见这头犀利 AppServer 的一些只鳞片爪。

• 服务端脚本 —— 纯 JavaScript 开发环境
• 特殊文档 —— Web 应用本身就是一个文档
• 程序同步 —— 一键安装 Web 应用
• 数据同步 —— 离线 Web 应用
• ……

基于前面提到要素，不难组合出更多妙不可言的特性来，对于日益得到重视的 JavaScript 程序员们而言(实际上，其他程序员也是一样，只是，稍微没有那么“显而易见”而已)，未来是一件多么值得期待的事？