夜夜哭闹的混世小魔王在她满月的这天好像突然换了个人，一觉又一觉地睡。这可苦了我，一个月来建立的夜间作息倾刻间紊乱，她没有闹觉的时间里，我却丢了魂一样，怎么也睡不着。于是起身想折腾点什么，无意间看到了derbyjs的 blog 是github pages支持的，遂产生了兴趣，挽起袖子就开始折腾一个自己的。虽然 [octopress][1]的文档写得很清晰，但对于第一次接触这个博客系统的人来讲，还是有一些拦路虎的。2012年12月16日凌晨4:15，当我的第一篇空的博客展现在 tyrchen.github.com 时，我终于累瘫在床上。
Meteor的官网( http://meteor.com )这样介绍这个框架：
Meteor is an open-source platform for building top-quality web apps in a fraction of the time, whether you're an expert developer or just getting started.
top-quality web apps 我们放下不表，fraction of the time 的提法很新颖，看来这个框架的目标是解放程序猿，少花时间多办事。虽然具体的演化路径我不得而知，但从网络上的各种蛛丝马迹来看，Meteor吸收了google wave, asana等平台背后的开发工具的精髓，逐渐演进出了目前的版本。Meteor的幕后团队相当强悍：他们大多毕业于MIT，是成功的创业家，也是一流的工程师，其中一个开发者还是神器 etherpad 的作者。
可以通过brew install nodejs 或 sudo apt-get install nodejs 安装。不过版本也许不是最新的，所以建议到 http://nodejs.org/download/ 直接下载对应系统下的安装包。如果你是windows的用户，我想说，接下来的旅程对你而言将是无尽的折腾，我要是你，要么合上笔记本，远离这篇文章；要么咬咬牙，卖半个肾，去搞台mbp回来。
reveal.js是一个NB的HTML presention framework，可以使用一些简单地HTML标签撰写出效果很赞的演示稿，并通过互联网传播。具体效果可以看这里。本文不是介绍如何使用或者撰写使用reveal.js的演示稿，这些可以通过reveal.js的文档很快速地掌握。作者比较好奇的是，既然octopress能够生成静态Html，那么如何很方便地将reveal.js集成到octopress中，让blog和presentation能够更好地结合起来？？
互联网产品永远都处在不断更迭的beta阶段。我们常常会在生产环境外，建立一套与生产环境共享数据的lab环境，以便验证一些即将用于真实世界的想法。问题是，每次提交改动后都需要手工运行部署脚本（前后大概花去30s左右时间），很不高效，每天运行那么几次，对惜时如金的程序员来说是种磨难。于是忙中偷闲的时候，就会想：有没有一种方法在代码提交后能够自动部署，身躯手工的麻烦？
当然是有的。Github的 Post receive hooks 就是用来干这个滴。作者花了小半天时间（对nodejs不熟啊），实现了一个很简单的自动部署方案，趁着记忆还未散去，将其记录在案，和大家分享交流。
使用octopress已经有一段时间，用这套framework构架博客，写作和部署感觉相当地爽。然而，就我个人的网站而言，我希望它不仅仅是一个博客系统，不光能产生固定格式的post/page，更应该是一个完整的CMS，能根据我个人的需要定制更多的内容展现方式。在使用octopress的这段时间，我尝试为其添加了对演示文档的支持，对更多模版的支持，但感觉还是有点别扭，就好像你让守门员去踢自由人，能干，但干不好。
我希望我的个人网站能够有以下特点：
markdown 来撰写文章于是上周起，断断续续，我开启了对个人网站的升级之旅。
我终于厚着脸皮把Teamspark开源了。
Teamspark是我做的一个协作软件。有关Teamspark的功能和使用方式见：http://tchen.me/teamspark/。或者你也可以直接clone或fork Teamspark的github项目。如果你想了解些关于Teamspark和Meteor的八卦，请继续阅读。
在 前文 中，我尝试了 docpad 做为新的建站工具。docpad 有很多优点，但最大的缺点是效率。在我看来，一个好的静态网站生成工具最好能在秒级处理成千上万文档，这样才能真正满足个人博客外的中等规模网站的需求。要做到这一点，工具必须将full build和incremental build区别开来。这样，即使一个full build要花几十秒甚至几分钟，incremental build还能控制在秒级。当用户修改某个文件时，incremental build能够保证用户有良好的体验 —— 无需等待，改动立即可见。而这一点，则恰恰是 docpad 所欠缺的。本文讲述的 hatch 项目将尝试在保留 docpad 的诸多优点外，通过更智能的build过程将编译速度尽最大可能提高。
继续 前文 。熬到了周末，正式开始了 hatch 项目的开发。首先是一个关键问题：如果每个文件的生成由一个单一的shell脚本完成，那么数据库打开/关闭的损耗会不会成为瓶颈？做了个简单的实验，发现每次打开都要花费0.2s，一个不小的数字。
➜ hatch git:(master) ✗ cat test.coffee
db = require('mongojs')('hatch')
col = db.collection('documents')
col.findOne {}, (err, doc) ->
db.close()➜ hatch git:(master) ✗ time ./test.coffee
./test.coffee 0.20s user 0.03s system 99% cpu 0.226 total如果你不知道docker是什么，请参考 这个slides。
在 ubuntu 下安装 docker 请参考 官方教程 。注意，由于 docker 的核心技术是 Linux container，所以如果想在 osx 下安装 docker 请使用 vagrant。