erl 的 log4*, bt 以及杂七杂八
etorrent 是最近相当活跃(常能在 maillist 见到 ann )的一个项目，它是用 erlang 实现的一个 bittorrent 客户端。记得刚刚接触 erlang 的时候就觉得它貌似很适合用来写 bittorrent 客户端(分布式/TCP/并发)，深入了解一番了之后，又觉得比起 C 来 erlang 并没有太明显的优势(GUI/CPU Heavy/IO/File)，加之后来见到堪称完美的 uTorrent 横空出世(说实话，除了网上银行，唯一想让我回到 windows 平台的东西就是它了)让人不再有动力作“写 torrent 客户端”之想，没想到时隔一年，还真见到了这样的项目，让人感慨。现在的 etorrent 已经是第二个公开发布的版本了，从它的 change log 看到，特性增强很厉害，以“ 20 个 torrent 占用 50－80M 内存”这样的指标来说，已经相当接近实用水平了。或许日后的 etorrent 再配上一个好用的 frontend 能够打造出像 xmms2 那样强大的软件也说不定呢。
log4erl 是一个 log4* 的 erlang 实现。对于广大习惯了 log4* 的 erlang 使用者来说，确是一个福音。不过，从某种程度上讲，这也可以算是某种“重复建设”—— erlang 自身已经内置了相当强大的日志机制。注意，只是强大，我并没有说易用。因为对于广大 log4* 爱好者们而言，只有能使用 grep/awk/perl 这些标准 unix tool chain 来处理的，格式化的，每条一行的(问题是，以我的经验来说，”每条一行”这种限制常常会逼人多费半天劲，或者多写一大堆)才是易用的日志。而 erlang 自身内置的日志机制说实话也毫不逊色，只是用来颇有一些不同(加之文档组织得别出心裁，让人不易找到)，各自属于不同的风格。既被拔到了“风格”层面，也就参杂了情感因素，无法以简单的方式来区分高下(君不见 csdn 上 x vs y 的口水仗层出不穷无休无止?)。本是见仁见智的事，大家看个人的喜好各取所需就是了。
顺便说说 erlang 自身的日志机制，极简的例子看上去象这样：
[{kernel,
[{error_logger,
{file, "debug.log" }}]}].
这好比是 log 的配置文件，然后，这样用：
1> error_logger:error_report([{tag1,data1},a_term,{tag2,data}]).
ok
2> error_logger:error_report("Serious error in my module").
ok
3> q().
ok
这样，在 debug.log 里面就有了：
=ERROR REPORT==== 17-Jul-2008::11:32:11 ===
tag1: data1
a_term
tag2: data
=ERROR REPORT==== 17-Jul-2008::11:32:31 ===
Serious error in my module
差不多就是这样了，更多配置，相关工具，以及更 “The Erlang Way” 的用法，可以参看文档 SASL 的部分。
btw，升级 wp 时从 incoming link 里发现一个 “默默无闻的领悟Erlang传说” 的中文 blog ToQuick (图快?)，主人 cheng 同学治“程”(程序)态度严谨，细密，文章写得勤也写的好，值得推荐。下面对于 log4erl 的代码观感就转自图快：
log4erl代码非常精简，保持了erlang代码的风格，log4erl包括1个supervisor和2个gen_server和1个gen_event。
log4erl.erl为gen_server和application behaviour的callback，其作为主要的module，
log4erl_sup.erl为supervisor,启动log4erl,初始时将通过log4erl_sup:add_file_logger启动default_logger 日志记录器。
log4erl_sup:add_file_logger/1会动态添加file_logger_guard和file_logger两个child process。
have fun.
[荐]《对“A History of Erlang”的评论》
原文在这里。貌似“功夫网”并未“河蟹”——既然能访问，俺就不盗版了。
这篇文章是 Robert Zubek 对 Joe Armstrong 在 07 年某个会上 show 的 “A History of Erlang” PDF 的评论(更象是写了一个“注”)。基本上，相比著名的 “Joe Thesis 2003” (本站提供了中文翻译，感谢段先德同学)而言，这篇 PDF 中并没有太多的新内容，只能算是一个精编浓缩 remix 版而已。
但对 Joe Thesis 2003 这篇略嫌艰深的博士论文来说， Robert Zubek 的文章提供了很好的“补充视角”。也就是说，从 Joe Thesis 中我们能看到 Erlang 在“一系列问题”上做出了与众不同的选择。但如果没有一定的背景知识，我们或许没怎么觉得这“一系列问题”又有什么大不了的。而这一篇正好(部分地)补充了这些背景知识。
照例，对于这篇文章的干货，还是打捞一下。
But this paper really conveys the feel for what that means: huge collections of loosely coupled finite-state machines, all running in parallel, doing little bits of protocol validation here and there, but mostly staying dormant.
英文的描述，如果写得好了，会有一种准确精妙难以言表的感觉，通常很难原汁原味的译为相对应的中文。不过，这句太经典，我还是想翻来看看。
这篇文档所传达的要义(用 Erlang 构造系统的感觉)是：一大堆并行运行着的有限状态机，各处做一做协议验证，彼此松散耦合，通常大部分的有限状态机都处在休眠状态。
作者提到他对这篇 “A History of Erlang” 中“有感觉”的几点是：
First, there’s strong emphasis on easily tracking and manipulating the flow of control, rather than data. Second, I enjoyed the explanation of one particular detail of Erlang: in the message-passing implementation, individual processes don’t handle messages immediately. Third, Erlang is somewhat infamous for its distributed error handling mechanism.
这只是起头，精妙在于剖析。任何一个设计决策都是有 trade off 的，对这些设计决策正反两面的分析，或许能够部分解释“为什么 Erlang 会这么怪异”，相当值得一读。
顺便说一句，我“有感觉”的一点是 “Erlang 天生就是以消息驱动模型来架构的系统” 而 “消息驱动的编程模型” 如何应用于互联网编程环境，正是值得我们深思的问题。
[荐] “RPC is bad” 续篇 —— joe 老爷爷如是说
继 Steve 大叔的 “RPC is bad” 开腔惊起娃声一片之后，Joe 老爷爷抓当前的大好形势又写了一篇“大字报”，“掀起了Erlang主义建设的新高潮”(第二声部唱：新高潮，新高潮)。不过，Joe 老爷爷的 Blog 建在 BlogSpot ，有“伟大的火墙”“护着”，我们可以免受这些“不良内容”的毒害，为方便大家学习，特将这篇文章盗版如下，供大家批判。(召唤翻译达人)：
[荐]RPC is bad?
偶像 Steve Vinoski 在 maillist 的回帖中一不留神就泄漏了他为 ErlangeXchange 准备的 session ，我们可以先一睹为快。Steve 大拿是 CORBA 界的牛人，对 RPC 是 bad 很有发言权地。这篇文章也写得很漂亮，水分相当少，我就不干“损失味道”的事情了。
为方便阅读，将 mail 内容盗版如下：
Facebook chat 跟踪报导 —— comet with mochiweb
话说 facebook 推出了支持高并发的 web im 引起众“hacker”(与 linux hacker 中的 hacker 相同的那个词)的一片哗然，纷纷出手研究其秘密。互联网上迅速的出现了一批“拆解 facebook webim”的文章。这里就是其中相当有意思的一篇。其中的干货如下：
1 作者放出 firebug 发现，http header 的 server 字段赫然写着 MochiWeb/1.0 的字样。
2 作者开动脑筋，在 mochiweb 基础之上，写了一个“最简单”的 facebook webim 概念模型，mochi loop 的核心代码如下：
'GET' ->
case Path of
"chat" ->
% 1) subscribing
Room ! {self(), subscribe},
% 2) waiting
receive
Message ->
% 3) everything went right
Req:ok({"text/plain", Message})
after 10000
% 4) oOops, too long buddy.
room ! {self(), unsubscribe},
Req:not_found()
end;
...
简而言之就是：在 browser 和 mochiweb 之间保持 10 秒的长连接，这(10s的)期间收到的任何消息都会即时发送给 browser ，然后再由 browser 内的代码再次发起下一个连接。作者提供了完整例子代码的下载。PS.关于这一实现方式的更多说明也可以参考拙作“the google way”。
当然这只是一个“概念模型”，距离“实用价值”仍有一段距离。比如：这个 web 层如何与 ejabberd 接起来，如何识别同一个用户，如何增加更多的“聊天逻辑”。
有兴趣(有时间)深入研究的读者可以移步阅读原文。如果看不到原文，请留言，以便“进行盗版”。
Facebook 的 Erlang 加持
这篇消息的两个要点是：
1. Facebook 总算推出了 developer’s blog，在大家都推出自己的“开发者博”之后。
2. 这个“facebook 开发者博”透出来的第一条消息是——纯正 PHP/LAMP 血统的 Facebook 在高度 realtime 的 Chat 应用中，终于用了 Erlang 来提高性能( ejarbberd backend? 估计是 process-one 的那帮法国人最近一直都在搞的定制项目 )，我知道他迟早都会要用的。
如果觉得“干货”不过瘾，时间充裕的朋友可以移步阅读更“ juicy ”的原文—— 《Real-World Erlang Applications - Scaling Facebook Chat to 70 Million Active Users Almost Overnight》。
PS. 这篇 blog 亦可看作是《challenges of scaling up a realtime application》，所以，如果有人花时间将其 i8n 一下，那将会非常棒。
update 20080516：有人说打不开，那就“被迫盗版”一下吧。[节约版面起见，请点“继续阅读”]
运行Processing代码——在Javascript里
mebeliProcessing是一门为视觉艺术家们设计的程序设计语言。尤其是对我们中国的程序员来说，恐怕是极度的冷门。怎么说呢，因为，这个语言“既不能挣钱，又不能出名”，不过就是“画画图”，“没啥技术含量”，简直具备“一无是处”的所有特质。
早在 Turbo Pascal 的时代(199x年)，我就曾因为”不慎”买了一本《分形艺术程序设计》，而掉到“用程序画图”的大窟窿里，不可自拔。确实是不慎，就因为这本书，在毕业之前耗费掉了我了大量“大脑CPU”以及“昂贵的机时”来调试和运行那些“除了好看之外，对于求职根本一无是处”的程序。当时可没想过，竟然有人会了这么“不靠谱的事情”而专门设计一个“视觉艺术程序设计语言”。后来才明白，除了写程序卖钱之外，还有很多其他的赚钱方法，只不过，我卖的是程序(工具)，而人家卖的是程序的运行结果(用工具做出来的产品)，这就叫做艺术(品)，这也确实是艺术(商业模式)。是的，用程序来画图，将其画成一件艺术品——站在程序员(特指卖程序为生的人)的角度，这确实还是一件理解起来有点困难的事。
第一次听说这个名词，是在首图的艺术阅览室，随手拿起来的一本香港艺术杂志(名字不记得了)用了很多页的彩图来展示这门语言所创造的艺术。当时的感觉是——相当精美，回忆起了那段“掉到窟窿里的时光”，不过和我已经没啥关系。
再次听到 Processing 的名字，是从 Joho Resig 的 Blog 上看到的，这位大神的 JQuery 事关吃饭，乃是“教主宝训，时刻在心，建功克敌，无事不成”级的东西。所以，当我看到这位大神竟然花了 7 个月的时间用 5000 多行的代码将 Processing 语言请到了 JavaScript + Canvas 环境中，可以说是相当的惊讶(不好好的花精力提升吃饭用的 JQuery ，跑去搞什么不务正业的 Processing 嘛)。莫非，人吃饱了饭都会开始追求艺术么？
anyway, 从纯技术的角度来说，Web确实是“艺术最广泛的平台”，最近还看到另外一个 JavaScript Information Visualization(一个动态的六度空间图，让人印象深刻)，再加上这个 Processing in JavaScript。让人被 canvas 标准喷出的炽热气息灼伤，而 web 视觉艺术的春天也正在凶猛来袭。
Javascript 的未来会很精彩。
运行Java代码——在Javascript里
Joho Resig (即 JQuery 之神)，是一位知名的“ JavaScript is the next big things”论者。他最近有机会参加了一个日本的 JavaScript 交流活动，给我们带回了一个有趣 JavaScript 项目 orto 的介绍。
这个名字看起来特别象 orz 的日本项目，可比它的名字看起来可要牛逼不少，它的野心是能让 java 代码运行在 JavaScript 之上，我的意思是 —— 用 JavaScript 做一个 JVM 出来。虽说可能不会全面支持 java 的所有特性，但至少能做一些有意思的东西，比如这个性能还不错的俄罗斯方块。
它的做法相当有意思，乃是将 java 的 byte code 转换为 JavaScript 代码，比如，你会看到这样的代码：
var orto336=orto350(orto333);
if(orto336.orto340!=orto310){orto223("java/lang/IllegalThreadStateException",null);
return ;
}
...
case 117:orto246[orto247-2]={high:(~orto246[orto247-2].high)
&0xffffffff,low:(~orto246[orto247-2].low+1)&0xffffffff};
if(orto246[orto247-2].low==0){orto246[orto247-2].high++;
orto246[orto247-2].high&=0xffffffff;
orto246[orto247-2].low=0;
}break;
...
case "CHECKBOX":orto171=orto188["orto/ui/CheckBox"];
break;
case "IMAGE":orto171=orto188["orto/ui/ImageButton"];
break;
case "RADIO":orto171=orto188["orto/ui/RadioButton"];
break;
显然“不是给人读的程序”(因为是给机器读的嘛)。orto 的特性包括：
* The result is able to handle threaded application code (translating the threads into a series of yields with setTimeout (mentioned in the presentation and demonstrated in the Tetris example).
* The application can use regular Java conventions for designing and constructing the UI (as shown here, as well). User Interface components are translated to, similar, HTML ones. It’s not apparent to what extent functionality is implemented, but it is to a certain degree.
* Keyboard interactions are able to be handled and translated to normal Java callbacks.
说起来，这和 gwt 很有一些“异曲同工”的意思。这让我联想到了 rhino，呵呵，你来实现我，我又来实现你，真是一个互操作的时代。畅想一下，如果在 rhino 的基础用上跑 orto 又或者在 orto 的基础上跑 rhino ，那会是一副什么光景，又有着怎样的意义呢？
也许是我个人食古不化的误解——私下里，个人认为 orto/gwt 这种项目让我有种“狗拿耗子多管闲事”的感觉，JavaScript 这样的脚本语言，不是正好适合于“需求变化迅猛”以及“强调快速原型化开发”的 UI 层么？找两个美工，一个 js 程序员就能做界面，不正是又快又好用么，为啥非要用 java 来写？追求语言上的纯粹？又或者是 js 程序员太难找？从后端的业务逻辑到前端的用户界面，全部都用 java 来包打天下，这是合适的做法么？如果说传统“应用程序”界面的程序，用用 swing/swt 什么的还可以理解，而在 web 一桶糨糊的现如今，这语言的 babel 之塔，就这么难以建立？
呵呵，JavaScript，我支持你。
[荐]如何给你的奶奶解释“云计算”
大道至简，简单是美。在下一直以为，能“把复杂的东西解释得很简单”是件很了不起的事，远比“把简单的东西解释得很复杂”要牛逼很多倍(后面一种事，好像每天有很多人都在做)。
王小波善于通过小说将复杂的社会政治问题给广大长期被洗脑的人民解释得一清二楚(这里)，而 highscalability.com 的 Todd Hoff 则善于通过博客将复杂的软件技术问题给毫无技术背景的奶奶解释得明明白白(这里)。在其中的任何一个领域，要干好这件事都需要相当的智慧，殊为不易，同样都值得推荐。
恩，推荐阅读的文章地址在[这里]。
PS. 不知道为了什么，象 highscalability.com 这样的纯技术站点也被我们“伟大的防火墙”(不知道的自己去google英文版)挡在了外面，国人无缘得见。(科技领域也搞闭关锁国？)各位无法访问的朋友，要么使用“伟大的过墙梯”(不知道的自己去google英文版)自己翻墙去看，要么看下面我“被迫的盗版”。
[blah] REST —— 一个实用主义者的思考
这几天在考虑“虚构ajax 聊天室”的 uri 设计，想用 rest 风格来试试，时髦一下嘛。但对 rest 有很多地方其实都是一知半解，于是去问老朋友—— rest in action 上的 dlee 同学——拽着问了一大堆初级问题(见这里，以及这里)，回头又啃了一些文章，也算是对 rest 进行了一番独立思考吧。想到整个过程对于其它人或许也有用，于是 blah 之。
需要说明的背景是：我是一个实用主义者。也就是说：搞开发不求纯粹但求实用。乃是在“多快好省”实现需求的前提下，顺便向“有风格”的方向靠，能靠上最好，靠不上拉倒。重点不在结果，而是在过程——也就是说，设计决策中，如果我选择了 free mobile phone ringtones | cricket free phone ringtones | 1600 nokia ringtones | madonna ringtones | free ringtones converter | cheap virgin mobile ringtones | free ringtones 3gforfree | mobile phone ringtones virgin | sprint pcs ringtones | free nokia mp3 ringtones | download free ringtones nokia | download free ringtones to cellular phone | free lg ringtones verizon wireless | get ringtones | free composer ringtones | gold mp3 ringtones | motorola ringtones | alltel free music ringtones | cingular free ringtones wireless | free boost mobile ringtones | rest ，那么借鉴的是什么，如果我选择了不遵循它，那么理由又是什么。另外一个需要说明的是，尽管这几天啃了不少 rest 的文章，但“每个人的心中都有一个 xxx”(请自行将 xxx 替换为你喜欢的任何词语)，加之对 rest 可能仍未吃透，所以大家凑合着看，或许某天夜里悟透了，爬起来把这里的思考全都推倒重来亦无不可能(免责声明了啊)。如果发现有错误，那太好了，欢迎之至，请随时指出。
下面就是“虚构 ajax 聊天室”的 rest 设计之旅。
Recent Comments