关于 Git 工作流，我之前只知道有个 Git Flow。工具我没有用过，不过思路我很赞同。类似 Git 这样的分布式版本控制，不再强调代码在提交时的整合，而是强调中心库向私有库的分裂和各个私有库各自的合并。分支越细致，合并代码的成本就越低。以 Feature、Bugfix 为单位整理分支，合并的时候就会非常清晰。如果代码耦合度低的话，几乎所有合并都可以自动完成。

这次在学校和同学一起开了一个 Web 项目，代码用 Git 来管理。参与的同学之前只用过 SVN，对 Git 也是初次接触。我考虑要不要尝试一下 Git Flow 这个工具，所以在豆瓣发了一条广播，结果几位同学回复让我看到更多类似 Git Flow 的工具或者思路，所以写篇文章记录下。本文纯属记录，没有主题。

最近比较忙，奇怪的是越忙的时候就越会有一些很无聊的胡思乱想。想到了一个初学面向对象时被问到烂了的问题：封装到底是什么。这个问题课本有标准答案式的解答，什么隐藏内部实现保留外部接口，但我并不满意这个回答。今天上课的时候又被老师的关联话题提起，于是想记录一下我现在的想法。

这个标题有点不太准确，其实应该说：慎用异步 WSGI Server 运行基于 Werkzeug 的应用。或者更宽泛一点——慎用异步 WSGI Server 运行使用 Thread Local 的应用。 Flask 是基于 Werkzeug 的故也在此列。貌似使用 Werkzeug 作为底层 WSGI 库的框架还有国内 limodou 老师的 Uliweb 。而其他使用 Thread Local 的 WSGI Application 不计其数，Bottle、web.py 都在此列。但我没有测试过其他的，仅仅掉下过 Flask 的坑。

前几天在邮件列表看到大家在说有没有好用的权限管理工具，有人说 Zend_Acl 不错。我看了下官网文档，貌似是挺不错的，用起来很方便。可惜 Zend_Acl 是 PHP 的，我于是兴起模仿它的用法，写了一个 Python 版的。

本文转载自 该文集 。

用过 Bottle [0] 的同学应该不会忘记它的流式响应 [1] ——在视图函数中使用 yield 关键字，让调用结果成为一个迭代器，那么 HTTP 客户端将会得到这个迭代器每次迭代的结果一部分，迭代器产生多少客户端收到多少，就像流一样。用这种方法在产生一些大的响应对象时（比如大文件下载），能有效地节约服务器内存。

运行以下代码并在浏览器访问 http://localhost:5000/stream

说来惭愧，听说 控制反转（Inversion of Control） 和 依赖注入（Dependency Injection） 这两个名词已经是大二的事情了，时至今日才想明白了具体的含义。我之前知道依赖注入的用法，一直将控制反转将其等同化，现在看来二者其实还是存在差别的。于是今天就此也顺便查阅了一些资料，将一些思考记录下来。

这里的“Web 控制器”指的的确是 MVC 中的 Controller，在 Django 等 Python Web 框架中也被称为“视图”。

说到本文，源起 Python Web 框架中对于“控制器”有两种不同的表达方法。其中一种是类似于 Rails 的 class-based，另一种是 类似于 Sinatra 的 function-based（当然 Sinatra 的实际是 block-based）。tornado、web.py 采取了前者，而 Flask、Bottle、Django 采取了后者。

在组织简单代码的时候，两种方式仅仅是风格上的区别，这时候往往 function-based 会显得更加简洁。但对于更加复杂一点的情况，class-based 的控制器有一些代码组织上的优势，可能 function-based 的需要花一些脑筋才能达到相同效果。

@wolf1990: 为什么要分的那么清楚呢？

为什么要分的那么清楚呢？丰顺三汤片本来就是客家地区和潮汕地区的交接处，是客家是潮汕又怎样，我们是客家人，喜欢潮汕文化……不行么？本来我们就是一群认同潮汕风俗的客家人，有什么好讨论的……

构思文章中……

让我想起了《悲惨世界》中的对话，花匠准备参加巷战，请求修道院的院长嬷嬷祈福。

院长嬷嬷：我会为你感到遗憾的，也就是说，没有人能强迫你参加这场战争，一场内战。

花匠：所有的战争都是内战，因为所有的人都是兄弟。