CN-Erlounge IV 圆满结束，各路英豪流出宝藏一大堆。经四处放狗，收刮如下：
0. 各位演讲者帅锅精心准备的演讲 slide
2. 由方块帅锅和莫帅锅 “以某种说不清楚的方式合作” 的 现场剧照
update: 对了，还有 zq 同学的 腐败前哨战实录
3. cn-erlounge-iv 现场抢到了 wifi 的幸运星们联袂演出的华丽 推推乐(请自备工具，以翻墙行动纪念柏林20年前那堵同样“伟大”的墙)
4. ZoomQueit 帅锅整理的 现场原声
5. 同样是由 ZoomQueit 从会场第一线发回的 “现场文字报导”(内容太长，放到后面了，点击 more 展开阅读)
6. yufeng 帅锅言简意赅的总结
7. litaocheng 帅锅同样言简意赅的总结
InfoQ 又为我们带来了新的访谈！感谢 InfoQ 的编辑们。
这次记者在 Erlang Factory 上逮到了 Joe Armstrong 和 Simon Peyton Jones 这两头大猛人，一起抓来做了一个 Interview 。众所周知，这两人分别在 Erlang 和 Haskell 语言中都是的大神级的人物，此番聚首实在是难得的机缘。
这次在 Erlang Factory 上的会面，两人大聊 Erlang 和 Haskell 在并发方面的特性，从技术角度而言，含金量颇高。当 Programmer 界两个脾气火爆的老头碰到一起，各位 IT 八卦爱好者同样也很好奇，他们究竟会冒出怎样火花呢？请移步 [这里] 观看。
Erlang-Web 并不是一个“新”项目，它的出现已经有一阵子了(第一次的公布是在 2008 年的 11 月)。一直以来，因为并没有太多的机会去实际使用 Erlang 来写“传统” MVC 的 Web 程序(了解我的人都知道，我一直在鼓吹采用激进的纯客户端的 JavaScript 的 MVC 来做 Web 开发)，所以并没有去真正了解它的特性。这种状况一直持续到最近，一个偶然的原因，需要做一点传统的 Web 开发，这才有机会回头再来审视众多的服务端 MVC Web 开发技术，并有机会认识 Erlang-Web 的强大。
对于一个全新的传统 Web 项目而言(通常这意味着内容要对搜索引擎友好、URL Friendly、有节制的使用 Ajax 等等需求)，对于服务端开发框架的考察无非就是需要关注如下这么几个方面：
首要考虑的是编码的“效率”，在这个坐标上，通常都是认为 Ruby On Rails 和 Python Django 之类的“Full Stack Web Framework”具有较高的得分。大量的默认习惯性配置，代码模版，等等，借助这些设施，通常较少的实际编码就能得到相当不错的成果。
然而，这类 Full Stack 框架通常“水比较深”，也就是说，它什么都提供了，但是有点“过了头”。稍微有点“另类”的想法通常容易导致痛苦。在这个坐标上，反而会希望框架再“谦逊一点”，毕竟只是一个 MVC 设施，简洁明了和可裁减也很重要。越简单的越好改，对熟手而言，用起来更能随心所欲。
再然后就是省时省力上的考量，和美工的流程配合、上传下载、URL Mapping、拦截设施、Email模块、与其他系统的接口，等等，该有的都要有，不该有的有了也好，不强买强卖就行。简而言之，能用较少的“脑力”来完成任务，就是上上大吉。
于是，我惊讶的发现自己在越来越多的关注 PHP 之类的技术(其中的一些确实是很不错的选择)。但要知道，对我个人而言，使用这门语言大约是在 9 年以前。这时我才想起曾经听过 Erlang-Web 的大名。没准怎么样呢，大不了回去再用 PHP ，先看看再说。我们了解一下它的特性：
配上 Erlang 内置的分布式和高并发特性，再加上 Mnesia 的诸多优势，看起来还是有一些亮点吧。当然了，特性并不完美，而且学习曲线很可能还有一点“陡峭”。但对于一个处于活跃开发周期中的项目而言，这应该不是什么大问题。长久以来流行在 Erlang 社区的这个说法——“Erlang 并不适合开发 Web 项目”——现在是不是时候改变了呢？ 
Call for CN Erlounge IV !
“Erlounge”是国外 Erlanger 对聚会的特定称谓，而“CN Erlounge”这一名称则是从 2007 年珠海的第二次会议开始，一直沿用至今。在 2008 年致力于 CN Erlounge 会务召集与组织的官方网站 ECUG.org 开通，并成功组织了精彩纷呈的 CN Erlounge III 上海站会议。如今，保持着一贯的热情与高效的 ECUG 会务组又在为我们忙碌的准备着今年的盛会 —— CN Erlounge IV 。让我们感谢他们的辛勤付出，也感谢会议历届的赞助商们。
去年 CN Erlounge III 的内容让人印象深刻，而今年 Erlang 的世界又格外精彩，不知不觉间，已经让人对于此次盛会内容又有了更高的期待。
ECUG 成立于 2007-10-14 日的 CN Erlounge II。全称为 Erlang China User Group（Erlang中国用户组）。它是一个民间团体，致力于促进 Erlang 中文社区的交流，以发展和壮大 Erlang 中国社区（了解 “Erlang 中国社区的发展历程”）。
按照 ECUG 的计划，预计每年我们都会举行一次全国性的Erlang开发者大会。这个会议我们简称为 CN Erlounge。下面是历届的 CN Erlang 大会资料：
1. 2007年9月8日，CN Erlounge I，珠三角Erlang爱好者小聚。无会议资料，但酝酿了之后具有里程碑意义的CN Erlounge II。
2. 2007年10月13~14日，CN Erlounge II 在珠海召开。金山为大会主要赞助方。
3. 2008年12月20~21日，CN Erlounge III 在上海召开。盛大网络为大会主要赞助方。今年 Erlang 中国社区人气有了明显的提高，也陆陆续续有互联网公司使用 Erlang 到他们的产品中。也有很多人开始用 Erlang 风格的并发模型（Erlang Style Concurrency）在自己熟悉的语言（如 C/C++、Java 等）中做事情，一些语言更号称自己已经实现 Erlang Style Concurrency 模型。另外，也踊跃出一批基于 Erlang Style Concurrency 模型的新语言（比如Scala）。在我们看来，Erlang是否会最终非常成功，目前言之过早，但是 Erlang 风格的并发模型（Erlang Style Concurrency）的成功，却是已经不容置疑的事实。
今年将于10月24~25日举行的 Erlang 开发者大会属于第四次 Erlang 开发者大会，简称 CN Erlounge IV。
CN Erlounge 的官方支持站点：ECUG.ORG。
CN Erlounge IV – 发起
1. 时间：2009-10-24 ~ 2008-10-25，为期2天
2. 地点：杭州（详细待定）
3. 议题： 研究、探讨、关注Erlang风格的并发模型（Erlang Style Concurrency）的技术及最新进展（不局限于Erlang语言）
4. 面向人群：对Erlang风格的并发模型有一定了解并有兴趣应用于实际工程的人。
5. 会议主持：ECUG 会务组会议形式
1. 多数时间由交流会讲师针对某个 Topic 进行论述，其他人提问（Q&A）方式交流。
2. 留出一小段时间，安排沙龙式的对等交流机会。会议规则
1. 会议的讲师报销来回路费和住宿（申请成为讲师）。点击这里可以查看已经确定的讲师名单。
2. 任何人可报名免费参与听讲（注册并申请参加本会议）。注：由于场地限制，我们可能没法接受所有的与会申请，请谅解。如果名额已满，我们会回信说明。
重要时间点
1. 讲师注册及Topic征集截止日期：2009-9-15
2. 普通参会者报名截止日期： 2009-10-1
3. 讲师投稿截止日期：2009-10-10
4. 详细会议议程安排公布：2009-10-15
5. 会议日期：2009-10-24 ~ 2009-10-25CN Erlounge IV – Topic征集
Topic范围
讲师的议题是否必须限定和 Erlang 相关呢？答案是否定的。我们需要Focus的是我们的问题域：如何高效地（包括性能和开发效率）进行分布式编程。我们都关注 Erlang 在这个方向上取得的成就，但不能也不想限制自己的眼界，Erlang 决不是我们唯一。只要你的议题和 Erlang 关注的问题域相关，和分布式、和多核时代面临的挑战相关，就没有“跑题”。Erlang 社区应该是睿智的、包容的。
投稿请发往 ECUG 会务组。
讲稿建议
1. 内容有深度，而不是泛泛而谈。忌局限于一个事实或者一个实践，但是没有任何结论。
2. 内容有一个Focus的问题域。告诉大家你要解决什么问题，它又是如何被解决的。
3. 如果能够结合一个实际的应用实践，那是最棒不过了。
Joel Raymond 最近搞了一个“悬赏”，看[这里]——如果能在1秒钟以内完成对20K客户端的广播(包含网络通讯，当然，为了排除网络速度的影响，是在本机做的测试)，那么就能得到 $1000 。
Joel Raymond 是一个富有经验的 Erlang 开发者，连他都搞不定的问题，可以想象，应该简单不了。但这的确是个有趣的问题，虽说咱没想拿奖金，但这个有趣的题目，不拿来做个山寨测试，岂不可惜？
咱们就从这个很简单的测试程序开始。(注意，相当之初级，高手请闭眼，哈哈)
Read more…
伦敦的 Benjamin Nortier 最近在他的博客上贴了一篇 《Erlang Factory 2009 – New Kids on the Erlang Block》(原文在这里，位于“伟大”的那堵墙外，浏览请自备溃坝/翻墙工具，或，看后面的原贴照转) ，在这篇博文中，他历数了 Erlang Factory 2009 上见到的几个有趣的新 Erlang 项目，其中的一些本站此前已有关注，另外一些则相当有新意。
另外，在这里喊一嗓子《Erlang Programming》（另外一本）的英文 PDF 已经全文流出，有人贴出了全本下载的链接，大家有兴趣的，可自行 Google 之。
翻墙辛苦，为方便大家，以下原贴照转，并非蓄意盗版。
Read more…
软件开发的奥义就是：分而治之。
代码世界从来都是一个充斥着耦合的世界，在这个世界里有着各种各样的耦合：静态耦合，动态耦合，类型耦合，逻辑耦合，空间耦合，时间耦合……。可以说，通常而言，一个良好的软件开发，最重要的一个步骤就是使用各种各样的工具来解耦目标系统，使其变成更小，更简单，更易于理解，更便于测试，更……的逻辑单元。完成这一阶段之后，剩下来的，差不多就都是体力活了。
然而，需要强调的一点是，我们要追求的绝对不是一个没有耦合的系统(我很怀疑，可能存在这样的系统么？)。实际上，一些耦合正是业务逻辑的表达，无法去除。我的意思是，或许我们致力于去除的，只是一部分“实现层面的耦合”。话说到这个分上，已经有点 “as simple as possible but not simpler” 的味道，赶紧打住了。
为了解耦系统，我们发展出了种种工具：接口、代理、设计模式……。在所有这些解耦工具之中，最为强悍的恐怕就是消息系统，它的解耦效果，不仅仅体现在概念维度上(接口的使用者和实现者)，而且也体现在空间维度上(分布式消息)时间维度上(异步消息)。关于这一点，我这里推荐的这本书，讲得比较清楚。
我们很幸运 Apress 在 2006 年推出的《Event-based programming: taking events to the limit》现在已经可以在 Google Book 上全文读到。而相应的豆瓣页面也正等着大家去丰富。
这里需要强调的一点是：解耦从来都是有代价的，更为彻底的解耦通常就意味着更难把握。对于广大 Erlangor 来说，这本书中的代码和实例，可能不是那么有参考价值，但我们使用的语言正是完全建立在“基于消息编程的架构”之上的，多读一点参考资料，至少是第一章，当然也是很有必要的。
感谢 Jeffry Zhao 在 Twitter 上的投递。
Erlang 的编译检查相当宽松，有时候，会让人觉得宽松得过了头。比如说，在一个模块中调用另外一个模块的函数，如果被调用的函数还没有定义(比如说，忘了写或者拼写有误)，编译器是不会给出任何警告的。如果你看编译没有错误就冒冒失失地运行的话，得到一堆莫名其妙的错误。这通常会搞的人很挫折，而检查这种问题也要浪费不少时间。下面这个脚本是解决这种烦恼的最简陋形式。
需要说明的是，未对输出进行任何处理，能看，好懂，但是相当之简陋，有兴趣的同学，可以自己动手美化之。
警告：本文纯属六一吹水，看客童鞋小心忽悠。
认识我有一段时间的朋友，肯定都在不同的场合分别听到过我对 “实时 Web 应用” 的鼓吹。有兴趣可以翻看去年 “CN Erlounge III” 上的《Realtime Web Application》，今年“Ajax 群英会”上的《实时 Web 应用》以及“BeijingOpenParty ——晚春夜曲”上的《实时 Web 应用中间件》。
虽说俺对于实时 Web 应用的爆发早有心理准备，但在5月31日，第一眼看到 Google Wave 的时候，还是和大家一样，被震到了。一是没有想到，实时 Web 应用还可以这么玩，太 TM 有创意了；二是没有想到，在这个“还没看清怎么玩”的领域 Google 竟然这么快就现身了，太 TM 神速了。(我很好奇，是怎样的公司文化和人才机制才能孕育这么恐怖的创新能力呢?)。
好吧，惊叹就到这里了(拍 Google 的马屁，那是众 G 粉的乐子，哪轮得着我呀)。下面照例，进入咱们的 “超强脱水” 上干货环节。
创新——Google Wave 创造性的解决了“实时”与“非实时”之间的无缝连接
非实时就是 Email ，实时就是 IM ，这两者的用户体验是如此的迥异，以至于此前试图将这两者统一起来的努力均告失败。而 Google Wave 所采用的方式则是老调重弹却又谱出新章的 Version Control —— 一个 Wave 就象是 Wiki 上的一篇文章，是一个有着版本控制的信息实体，被多个 participants (也就是用户)所共享。在这个隐喻下，非实时的访问就变成了“获取当前版本”，而实时的访问则符合“跟踪当前版本的所有更新”(所有的更新都通过实时消息广播给所有的 participants)。至此，让人目瞪口呆的 Replay 功能，也变得极其简单，只不过是版本控制的酷眩呈现而已。
现在看到很多说法，从“将会一统天下”到“未来互联网的基础应用”，等等，溢美之词不一而足。姑且认为这些都是 G 粉丝美好的 YY 吧。无须过渡诠释，咱们抛开 Google 的明星气质和强大的号召力不谈(借助这些， Google Wave 真的有成为 THE ONE 潜质也说不定)。单从“请下神坛”的“低俗化”角度， Google Wave 最本质的创新其实就是 Realtime ＋ Wiki 并在此基础上进行各种扩充而已。有心山寨的各位山大王，从这里开始抄就对了。
技术——基于 Web 的 Realtime 技术，以及有 Google 特色的开发框架
在创新面前，任何实现层面的技术都会显得黯然失色。虽然目前还无缘得见 Google Wave 的 Realtime 实现技术，但大致可以猜出肯定是 Web Socket 或者 Ajax Long Poll 中的一种(很有可能是前者)。从技术层面而言，早已经算不上是新鲜事物了。然而有 Google 特色的开发框架(这个句式怎么听来这么耳熟呢)，仍让人感到新奇。展现层的扩展直接使用了 Gadgets 模式。逻辑层的扩展则直接使用了 App Engine 的 Web 模型。
应该说，这一整套扩展方案充满了 “Google 的味道”，而且，这个模型肯定是能用的。除了 Google 系扩展一贯的稍嫌“重型”之外，唯一让人感到担心的，恐怕是这种逻辑扩展模型的抗压性。虽说使用了批量发送作为两个层次之间的阻抗匹配，但这种方法实际上仍然是将实时性更高的 Realtime 通讯构建在了实时性较低的 HTTP 通讯之上，不知道这会不会带来潜在的问题。
战略——Browser Platform/OpenSocial/OpenStand阳谋的最新尝试
Google 对 M$ 的阳谋就是 Browser Platform 战略，浏览器即平台——管你什么设备，也不关心什么 OS ，只要有一个符合 HTML5 标准的浏览器，走到哪里都是一样的用。无论是 gOS 也好，Chrome 也罢，还有 Google 对 Firefox 的大力支持，所有东西全都围绕这个核心展开。利益攸关嘛，所以，在 HTML5 上 Google 的心急和 Microsoft 的拖沓，也就显得很好理解。而这次的 Google Wave 也没有例外。以超眩的用户体验为“ HTML5 兼容浏览器”阵营奉上自己的 Killer App。民心向背是革命成败的关键，Google 的革命理论学得不错。
M$ 之外，另外一些会让 Google 这样的巨头感到巨头疼的恐怕也就只有 Facebook/Twitter 这一票跟在屁股后面猛追不舍的 SNS 了。OpenSocial 战略就是分化瓦解 SNS 集团的阳谋，但似乎不大奏效。第二梯队的 SNS 始终各怀鬼胎，最起码的 Open Platform 尚且无法贯彻，更进一步的 OpenSocial 缺乏动力也就见怪不怪了(从国内 SNS 对“开放平台”的暧昧态度就可窥见一斑)。因为无法摆平各方利益，技术相当领先的 OpenSocial 几乎快到了要沦为鸡肋的境地。而第一梯队的 Facebook 之辈用户基数则继续保持爆炸性增长，搞得 Google 很是窝心的说。如果说之前的 OpenSocial 是“跟在后面搞破坏”，那么此番祭出的 Wave 则是“抢在前面打埋伏”，而且还摆明了车马，将要彻底开源，欢迎大家山寨。用心可谓良苦，但效果目前还说不好。用户到底是会被 Network 粘得死死的，还是会被 Wave 勾得心痒痒进而纷至沓来，仍然还需要时间的检验。但，计以至此却已然到了尽头，再没有回转的余地；如若不售，后续的手段恐怕只剩下收购一条了。
OpenStand 对于 Google 来说，乃是性命之根本。试想，如果某个“封闭标准”的公司独占互联网哪怕是十分之一的内容，而且不开放内容给 Google 的爬虫(考虑一个充血版的 Facebook)，那么搜索结果的质量会因此受到多大的影响？在这个普通网民都开始谈论“实时搜索”的时代，在底层(也就是通讯协议层)占据一个有利的位置(推出自己的开放标准，或者保证标准的开放性)，对于 Google 这样的公司来说是一件多么重要的事？从这个角度来看，被事先高调宣布的 Google Wave 的 Open Source Product 和 Open Protocol 路线图，无论怎么看都是必须的一步棋。
Google Wave 不是实时 Web 应用的银弹
其实这是一句屁话——哪怕是在某个犄角旮旯的小不点儿领域，这个世界上也都从来就没有过什么银弹。我得承认，说“Google Wave 不是实时 Web 应用的银弹”，完完全全就是为了寻开心。一个软件老民工装出一副思想很深邃的样子，恶心一把装腔作势的软件砖家们，没办法，就是这么低级趣味。
首先，我也承认 Google Wave 眩得要命，客户方的代表看了也会喜欢得不得了，但它完完全全是基于 HTML5 标准的——你的意思是想去说服公司领导，让他们完全抛弃占据市场份额超过 80％ 的广大 IE 浏览器用户么？XD，脑子笨一点不要紧，关键是不要进水就好了。
其次，我知道 Google Wave 提供了 Robots API 很多东西都可以“引入”到系统中，而利用 Gadgets API 又可以“展现”很多东西，况且 Google Wave 本身还会开源，哎呀，简直太好了，我们可以在 Google Wave 上架构我们的系统，既省钱来又省时间，这下终于有时间去泡妞了……。喂，醒一醒，XD。我们真的需要把我们的应用嵌入(接入) Google Wave 以获得 Realtime 特性，而不是相反？尤其是，当我们的应用并不像个 SNS 或者“协作系统”的时候也要如此？好吧，算你牛，非得这样，那，咱们项目组要不先回家待岗，等它出来了咱们再回来上班？
再还有，协作隐喻能够覆盖所有的 Realtime App 需求么？这是一个根本性问题，要不，咱再想想……？
干货上完，现在上水货。地址在[这里]，各路水神水仙纷纷出动，精彩得紧。不要问我这水到底有多深，你自己下去探探不就知道了。;)
Recent Comments