我是个懒人，记性还差。写了两篇博客后，隔了一天再写，就忘了新建博文的命令，是 rake new_post 还是 rake new_posts 来着？另外，每次写完之余，都要敲 rake gen_deploy 部署也总让我抓狂。平心而论，我还是非常喜欢octopress这个产品，简洁的设计，独特的思想，优雅的撰写方式和美妙的历史记录，这些都让我沉浸在其中，乐不思WP，但如果再能好那么一点点，再让我少干些重复性的劳动，一切就完美了。
同事见了我的博客也想搭一个，我说这不适合你，octopress只适合程序猿。回过头来我想，为什么自己的视界这么狭小？程序猿是干什么的？不就是把复杂繁重的工作交给计算机，让计算机前的人能够悠然自得么？
SDN（Software Defined Network）是个有意思的概念。ONF（Open Network Foundation）这样定义SDN：
In the SDN architecture, the control and data planes are decoupled, network intelligence and state are logically centralized, and the underlying network infrastructure is abstracted from the applications.
用普通话说就是软件独立于硬件，让硬件标准化，软件平台化，信息中心化。
上一篇文章简单介绍了SDN及其应用场景，臆测的成分大些。本文谈谈SDN的基石：openflow。
我们知道，SDN的核心是将control plane（下文统称controller）和data plane（下文统称oSwitch，openflow switch）分离，由一个中央集权的controller（好比一个军团的将领）指挥成百上千的oSwitch（好比千千万万的士兵），共同完成网络中数据的传输。而openflow，as a protocol，是这套体系正常运作的基石。
本文难度稍大，可能不适合没有网络设备基础知识的读者阅读。我会在下节中稍微讲一些基础概念，如果无法理解，则不建议读下去。
有很久没有写文章了。为google I/O在airbnb寻找硅谷附近的住所时无意间遇到了Paul，lockitron 的创始人。于是lockitron便吸引了我的注意力。他们的video很酷（需翻墙）：
根据这个video及其主页的介绍，我用lean canvas大概总结了一下其要解决的问题和商业思路：Locitron lean canvas。接下来的问题是：如果要做这样一个产品，需要什么样的技术架构？
于是，我花了些时间，深入了解lockitron，思考其特性，及特性背后的feature。我会从硬件——门锁控制器（下称controller），软件——功能与服务（下称service）两个方面来看lockitron面临的技术挑战及解决方案。由于我手头没有一个lockitron供我测试和reverse engineering，所以接下来你看到的内容，臆想的成分很大。
这两天无意翻到几个月前的Evernote笔记，看到了当时对团队开发环境的一些想法。可惜后来种种，这一想法未能得到实践，只能将其完善后公诸于众，立此存照，日后有空可以一试。
考虑这套开发环境是因为我们遇到了这些问题：
当时正好看到一篇关于 vagrant 的文章，感觉这正是我想要的救命稻草。
这是一篇即兴的短文，主要是为了记录我用 scrapyd 的心得。
之前做数据抓取，总是一个scrapy project做一个deploy，很不方便，一个一个更新起来也很麻烦，总觉得能有更好的方法去处理。今早看了看scrapyd，觉得这就是我想要的东西。
有时候，写个小app，部署是件麻烦的事情 —— 你需要登录到服务器上，手工编辑nginx，supervisor等配置文件，然后重启相关的服务。这些配置都不在版本库中，所以也无法记录历史修订。puppet 是个不错的解决方案，但对于小项目来说，使用puppet是个负担。
本文讨论如何通过写个简单的 makefile 来达到自动化部署的目的。
Recently I did a web application to make easy GNATS report for my team. I use scrapy to crawl the GNATS web pages for people's issues every 4 hours, then add the crawled data into mongodb. A set of simple-to-use RESTful APIs written with nodejs can provide easy access to the data (try it out, but only viewable internally in Juniper). Then a django application consumes the APIs and wraps them into a not-so-bad user interface, thanks to twitter bootstrap and a set of javascript frameworks and libraries. You can look at the ultimate application here: GNATS report system.
看了berkeley网站上的文章Who Says C is Simple?，顿感汗流浃背。如果招聘官按照这个题目去面试，我也就将将五十分。不过话说回来，这里所列的case都太偏门，走的是圣火令的武功路数，真正做工程的这么写代码就是欠揍。
但是抱着学语言的态度，这里的题目如果你不懂都值得深究。我研究了下第四题 —— 这是让我比较困惑的一题。
// Functions and function pointers are implicitly converted to each other.
int (*pf)(void);
int f(void) {
pf = &f; // This looks ok
pf = ***f; // Dereference a function?
pf(); // Invoke a function pointer?
(****pf)(); // Looks strange but Ok
(***************f)(); // Also Ok
}If somebody says X language is better than Y language, usually there will be a fierce quarrel between two sides. If you're using certain language for a long time, you will be the evangelist of that language, and try to protect it unconsciously. Admitted or not, you have been trapped in a tunnel, that what you can see is constraint greatly. "The Shawshank Redemption" gives a good footnote on it:
[Red] These walls are funny. First you hate 'em, then you get used to 'em. Enough time passes, you get so you depend on them. That's institutionalized.
So before we're institutionalized too deep, let's learn something completely different - a language that not derived from C family, a language that leads you to a totally different mindset.
Erlang seems to be a good candidate.
很久没有更新博客了。最近几个月写了三篇文章：
因为种种原因都烂尾，没有继续下去，所以也就没有发表出来。绵绵不断的工作压力和为人父的家庭责任让我心力交瘁，眼一睁一闭，一睁一闭的，一天天就过去了。
这两天闲逛hn时，无意中发现了 docpad，又一个静态网站生成器。由于我目前使用的 wintersmith 是一个hack版，将其升级到2.x太麻烦，而且随着我文章的增多，分页，标签管理等都成为麻烦事。在尝试了 docpad 后，我发现这是个好东西，干脆心一横，就把整个博客的底层系统升级过去了。
在 前文 中，我尝试了 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如今随着网上交易规模不断扩大及API驱动的互联网的出现（如 https://strip.com ），互联网的安全性越来越受到重视。本文简单讲述如何将你的nginx配置成支持https的web server。当然，理论上一个合格的https server需要从CA那里获得正式的SSL certificate，但如何购买SSL certificate不在本文讨论之列。本文仅从技术上讨论如何在你的服务器上使能https。
如果你不知道docker是什么，请参考 这个slides。
在 ubuntu 下安装 docker 请参考 官方教程 。注意，由于 docker 的核心技术是 Linux container，所以如果想在 osx 下安装 docker 请使用 vagrant。
最近vagrant 1.5升级力度空前，增加了很多新功能，其中最令人瞩目的当属 vagrant share。啥子意思呢？就是把你的虚拟机share给地球另一端的人。这功能很高大上啊，简直是居家旅行，远程办公的必备武器。你正在做的web app出bug了，需要帮忙？没问题，亲，把虚拟机share一下。