翼图南

fastai 源码浅析 - LayerGroups

2019-05-18T00:00:00+08:00

fastai 在使用预训练模型进行迁移学习(Transfer Learning)时，有一项很酷的特性: 你可以给模型的不同 layer 设置不同的 learning rate (Discriminative Learning Rates).

然而一些模型如 ResNet 有很多层，要给每一层都设置一个不同的 lr, 既麻烦也没有必要。其解决方法在 Practical Deep Learning for Coders, v3 课上， Jeremy 已经简略地提到过了。 fastai 会把 model 划分成若干个 layer groups, 给每个 group 设置一个不同的 learning rate。

其具体实现是怎样的? 不同结构的模型又是怎么划分 layer groupn 的? 对于新模型我们又应该怎样去设置 layer groups？要解答这些问题，就需要我们自己来阅读源码了。

在通过 cnn_learner() 等方式创建 learner 时，会调用 learn.split() 来对 model layers 分组:

fastai/vision/learner.py

def cnn_learner(data:DataBunch, base_arch:Callable...):
    ...
    model = create_cnn_model(...)
    learn = Learner(data, model, **kwargs)
    learn.split(split_on or meta['split'])

learn.split() 会把分组结果存放在 learner 的 layer_groups 属性里:

fastai/basic_train.py

def split(self, split_on:SplitFuncOrIdxList)->None:
    "Split the model at `split_on`."
    if isinstance(split_on,Callable):
        split_on = split_on(self.model)
    self.layer_groups = split_model(self.model, split_on)
    return self

一个 model 的 layer 分组方案，其实是由 split_on 参数决定的。这个 split_on 参数可以在调用 cnn_learner 创建 learner 时手动传入，缺省使用模型 meta 配置里的的 split参数。

fastai.vision 指定了以下几种 split_on 函数: fastai/vision/learner.py

# By default split models between first and second layer
def _default_split(m: nn.Module):
    return (m[1],)

# Split a resnet style model
def _resnet_split(m: nn.Module):
    return (m[0][6], m[1])

# Split squeezenet model on maxpool layers
def _squeezenet_split(m: nn.Module):
    return (m[0][0][5], m[0][0][8], m[1])

def _densenet_split(m: nn.Module):
    return (m[0][0][7], m[1])

def _vgg_split(m: nn.Module):
    return (m[0][0][22], m[1])

def _alexnet_split(m: nn.Module):
    return (m[0][0][6], m[1])

_default_meta = {'cut': None, 'split': _default_split}
_resnet_meta = {'cut': -2, 'split': _resnet_split}
_squeezenet_meta = {'cut': -1, 'split': _squeezenet_split}
_densenet_meta = {'cut': -1, 'split': _densenet_split}
_vgg_meta = {'cut': -1, 'split': _vgg_split}
_alexnet_meta = {'cut': -1, 'split': _alexnet_split}

然而光看这段代码，我们仍然会一头雾水，m[0][0][6] , m[1] 这些 magic number 到底是怎样来的。

下面让我们以 alenxnet 为例, 深入看下这块的实现:

注: fastai.vision.models 下的很多模型是直接用的的 torchvision 里的模型

torchvision/models/alexnet.py

class AlexNet(nn.Module):
    def __init__(self, num_classes=1000):
        super(AlexNet, self).__init__()
        self.features = nn.Sequential(
            nn.Conv2d(3, 64, kernel_size=11, stride=4, padding=2),
            nn.ReLU(inplace=True),
            nn.MaxPool2d(kernel_size=3, stride=2),
            nn.Conv2d(64, 192, kernel_size=5, padding=2),
            nn.ReLU(inplace=True),
            nn.MaxPool2d(kernel_size=3, stride=2),
            nn.Conv2d(192, 384, kernel_size=3, padding=1),
            nn.ReLU(inplace=True),
            nn.Conv2d(384, 256, kernel_size=3, padding=1),
            nn.ReLU(inplace=True),
            nn.Conv2d(256, 256, kernel_size=3, padding=1),
            nn.ReLU(inplace=True),
            nn.MaxPool2d(kernel_size=3, stride=2),
        )
        self.avgpool = nn.AdaptiveAvgPool2d((6, 6))
        self.classifier = nn.Sequential(
            nn.Dropout(),
            nn.Linear(256 * 6 * 6, 4096),
            nn.ReLU(inplace=True),
            nn.Dropout(),
            nn.Linear(4096, 4096),
            nn.ReLU(inplace=True),
            nn.Linear(4096, num_classes),
        )

    def forward(self, x):
        x = self.features(x)
        x = self.avgpool(x)
        x = x.view(x.size(0), 256 * 6 * 6)
        x = self.classifier(x)
        return x

可以看出 torchvision 的实现里把 AlexNet Model 所有 layers 划分为了 3个 nn.Sequential 串:

features
avgpool
classifier

注: AlexNet 作为一种顺序模型，其实只用一串 nn.Sequential 块就可以实现了。而torchvision 为了代码组织更加清晰和易用，才按照 layer 的功能划分了 3串。

打印出来的模型结构如下:

AlexNet(
  (features): Sequential(
    (0): Conv2d(3, 64, kernel_size=(11, 11), stride=(4, 4), padding=(2, 2))
    (1): ReLU(inplace)
    (2): MaxPool2d(kernel_size=3, stride=2, padding=0, dilation=1, ceil_mode=False)
    ...
    (5): MaxPool2d(kernel_size=3, stride=2, padding=0, dilation=1, ceil_mode=False)
    (6): Conv2d(192, 384, kernel_size=(3, 3), stride=(1, 1), padding=(1, 1))
    ...
    (10): Conv2d(256, 256, kernel_size=(3, 3), stride=(1, 1), padding=(1, 1))
    (11): ReLU(inplace)
    (12): MaxPool2d(kernel_size=3, stride=2, padding=0, dilation=1, ceil_mode=False)
  )
  (avgpool): AdaptiveAvgPool2d(output_size=(6, 6))
  (classifier): Sequential(
    (0): Dropout(p=0.5)
    (1): Linear(in_features=9216, out_features=4096, bias=True)
    ...
    (6): Linear(in_features=4096, out_features=1000, bias=True)
  )
)

这里的AlexNet模型并不是我们最终使用的模型，它的结构是针对 ImageNet 数据集设计的，解决的是 1000个类别图片的分类问题，因此我们还会对它进行改造:

cnn_learner() 通过调用 create_cnn_model() 来创建实际使用的模型:

fastai/vision/learner.py

def create_cnn_model(base_arch, nc, cut, 。。。):
    "Create custom convnet architecture"
    body = create_body(base_arch, pretrained, cut)
    ...
    head = create_head(...)
    return nn.Sequential(body, head)

可见 fastai 创建出来的模型是由 body 和 head 两块拼接而成:

body 是在预训练模型(e.g. AlexNet) 上丢弃若干层网络得到的 create_body() 具体会丢弃哪些层，是由 model 的 meta['cut'] 参数决定的。在上文的代码里，我们可以看到 _alexnet_meta['cut'] 的值为 -1. 这意味着丢弃 AlexNet 的最后一串 layer，即前文提到的 classifier Sequential.
head 的结构只和我们的数据有多少类别有关，和body 用的是alexnet, 还是 vgg 或 resnet 没有关系。其具体结构，下文会讲。

最终的模型结构课简化如下:

(
    (body): (
        (features)
        (avgpool)
    )
    (head)
)

现在再回过头看 alexnet 的 split_on 函数就比较好理解了:

def _alexnet_split(m: nn.Module):
    return (m[0][0][6], m[1])

m[0] 为 body, m[0][0] 即 features， m[1] 即 head

(m[0][0][6], m[1]) 意味着 features 的前6层划为第一个 layer group, 第7层到 head 划分为第而个 layer group， head 作为第三个 layer group。

由于 head 层是我们自己添加的，是预训练模型里不存在的, 它的 learning rate 显然应该和预训练模型不同，这也是所有的 split_on 函数都包含 m[1] 这一项的原因。

至于 AlexNet 为什么选择在 m[0][0][6] 处切一下， vgg 在 m[0][0][22]切一下， resnet 在 m[0][6] 切一下，经过分析这些模型的结构，可发现这些切割垫都是卷积层中间的位置。

总结

meta['split'] 决定了 model 怎样划分 layer groups
meta['cut'] 决定了预训练模型会丢弃哪些层
绝大部分 CNN 模型会被划分为 3 个 layer group，预训练模型的卷积层会从中间划分为 2 个 group, 分类器1个 group

Tensorflow 和 PyTorch 如何快速切换使用的 CPU/GPU 设备

2018-10-07T00:00:00+08:00

在做机器学习时，常遇到这样的场景: 模型有时要跑在 CPU 上，有时要跑在 GPU 上，有时又要跑在某块指定的 GPU 上。

对于开源项目，我们更是无法确定用户要使用怎样的设备，要是换个设备，就要大改代码，就很糟糕了。

本文就简要介绍下 Tensorflow 和 PyTorch 这两个最常用的深度学习框架下，怎样来最便捷地切换使用的设备。

Tensorflow

在 Tensorflow 里的实现很简单，我们把相应的代码放到一个 tf.device 块里就行了。

with tf.device('/cpu:0'):
    a = tf.constant([1.0, 2.0, 3.0,], shape=[2, 3])
    b = tf.constant([1.0, 2.0, 3.0,], shape=[3, 2])
    c.append(tf.matmul(a, b))

也可以指定一个 session 所能使用的设备:

config = tf.ConfigProto()
config.gpu_options.visible_device_list= '1' # GPU 的序号
config.device_count={'GPU': 1}) # 1： 只用 GPU, 0: 只用CPU
session = tf.Session(config=config, ...)

如果想把设备和代码完全分离，我们还可以通过设置CUDA_VISIBLE_DEVICES环境变量来实现:

CUDA_VISIBLE_DEVICES="0,2,3" python model.py # 使用 GPU 0, 2,3
CUDA_VISIBLE_DEVICES="" python model.py # 使用 CPU

以上 3 种实现方式的作用范围，由小而大。 with block 只会影响其代码块，而环境变量会影响整个程序。

PyTorch

在 PyTorch 的早期版本里，官方没有提供一个切换设备的方法，各种第三方实现也比较 ugly。 PyTorch 创建的 tensor 默认是跑在CPU 上的, 我们如果要创建一个在 GPU 上运行的 tensor 需要调用 .cuda() 方法。 e.g. torch.rand(3,3).cuda()。

因此在早期 PyTorch 代码里，常用下面的模式，去做兼容：

x = x.new_ones(5, 3, dtype=torch.float)
y = torch.rand(5, 3)
if use_cuda:
    x = x.cuda()
    y = y.cuda()

直到 2018年4月底， PyTorch 0.4.0 发布后， PyTorch 才有了一种更优雅的写法: 使用to() 方法。 to() 可接受一个 device 参数，而不像 .cuda() 是写死了的。

device = torch.device("cuda:0" if torch.cuda.is_available() else "cpu")
...
x = x.to(device)
model = MyModule(...).to(device)

一言以蔽之，将以前 Pytorch 代码里 .cuda() 替换成 .to(device) 就行了。

这种写法相比于 Tensorflow 仍略欠优雅, 但根据 github issue 里的反馈，官方也不打算在这方面再做优化了。 PyTorch 官方文档里也已经基本改成 .to(device) 这种写法。大家可以撸起袖子改代码啦！

显卡不够云来凑 - 如何选择用于深度学习的云主机

2018-02-16T00:00:00+08:00

自从前两年 AlphaGO 先后战胜李世石和柯杰，。

在本文的开头，我觉得有必要强调一点: 目前个人用户使用带显卡的云主机在做深度学习，从性价比上来说，通常没有自己买显卡合算。

相信很多读者会有疑问，既然如此，那本文的目的何在？这不是在坑大家吗。答案是。首先不是所有品牌的显卡能用来跑深度学习。其次，显卡的配置不能太低。不建议用6G 显存。笔记本用户，要换显卡的话，难度要比PC大很多。 PC 用户的话，一些。有这么多因素制约，很多同学一上来学习热情很高涨，结果在搭建环境上，就打了退堂鼓。

尽管云主机在性价比上没有多少优势，他有人立即上手机器学习。有些人的机器可能显卡配置不高，有些人的笔记本可能升级显卡比较困难，有些人机器的显卡可能在高负载下散热很差，不要让这些事阻碍你去尝试深度学习。

加速 NLTK 数据包 (NLTK Data) 的下载速度的几种方法

2017-05-06T17:27:00+08:00

NLTK 是一个在 Python 自然语言处理领域里非常流行的的一个包。NLTK 本身的安装比较简单 (如果是缺少编译环境的 Windows 系统，推荐用 conda 安装 )，教程也比较多，这里不再赘述。

然而要让 NLTK 真正工作起来，我们还需要去网上下载各种语料库、语法库和训练模型。由于网络原因，这个下载过程可能比较耗时，或经常失败。下面就简要介绍几个小技巧来加速这一过程。

只下载你需要的数据包

NLTK 提供了十分丰富的自然语言数据包，其中大多数体积都比较小，也有少数体积比较大, 会有几个G。通常你并不需要所有的数据包，只下载那些你需要的，显然可以快很多。

完整的 NLTK Data 列表可以访问 http://www.nltk.org/nltk_data/ 得到。

通过 Python shell 下载:

import nltk
# nltk.download() 不指定数据包的名字时， 默认下载全部数据
nltk.download('stopwords')

或者在命令行里运行 python -m nltk.downloader <数据包名>

如果是在桌面环境下执行上述命令的话, NLTK 会弹出一个用 Tkinter 写的图形化窗口，可以更加方便地选择要下载的数据包。

通过代理下载

现在 NLTK 的数据是托管在 Github 上的。由于一些众做周知的原因， Github 在天朝的网络下时常不太稳定。考虑到很多程序员都会自备梯子，我们可以让 NLTK 通过代理来下载软件包。一个稳定的代理不仅能避免连接被重置而导致的下载失败，往往也能提高下载速度。

在 Python shell 里指定代理：

nltk.set_proxy('http://proxy', ('USERNAME', 'PASSWORD'))
nltk.download()

如果是在命令行里通过 `python -m 的方式下载的话，可以通过设置 HTTP_PROXY 环境变量来指定代理。

通过其他工具下载

当你确实需要某些体积很大的数据包时, 光靠 NLTK 自己提供的下载功能可能就捉襟见肘了(仅针对国内网络而言)。这种情况下，我们可以借助于 wget/aria2c 这类支持多线程，断点续传的下载工具。相关数据包的下载链接可以在上文中提到 http://www.nltk.org/nltk_data/ 里找到。

例如 Brown Corpus 这个数据包就可以通过 wget https://raw.githubusercontent.com/nltk/nltk_data/gh-pages/packages/corpora/brown.zip 的方式下载下来。下载下来 zip 包需要解压到 NLTK 指定的 data 目录的某个子目录下。如果是桌面环境，下载窗口上就会显示 data 目录的路径。

如果是命令行环境,可通过下面的代码查看:

import nltk
nltk.data.path

在我的机器为例，NLTK 的 data 目录是 ~/nltk_data 。注意刚才的下载 url 是以 corpora/brown.zip 结尾的，暗示这是一个 corpora (语料)，因此这个 zip 文件就要解药到 ~/nltk_data/corpora 目录下。同理， Grammars from NLTK Book(https://raw.githubusercontent.com/nltk/nltk_data/gh-pages/packages/grammars/book_grammars.zip) 就要解压到 ~/nltk_data/grammars 目录下。

有少数包的下载地址不符合上述规则，如 PanLex Lite Corpus(https://db.panlex.org/panlex_lite-20170401.zip)，这类数据包一般都是体积较大，不能托管在 Github 上的，这类包一般都属于 corpora。

利用 Travis CI + Github 给静态博客加上草稿和编辑预览功能

2016-12-25T14:36:00+08:00

最近几年，静态博客超越 wordpress。在程序员社区，利用 Github Pages 来托管静态博客更是风靡一时。其中不少人也开始使用持续集成工具 Travis CI 来自动构建和发布博客。

本文介绍了一种使用持续集成工具 Travis CI 来实现自动化发布 Pelican 静态博客到 Github Page.s 的方法。在完成本文所述的配置后，你可以抛开 Python、命令行, 只通过 Github 就能编辑，发布自己的博客。通过 git branch 和 Pull request还能实现传统动态博客的草稿和预览功能。

想不予，如今静态博客。 dao到。

Travis CI 是什么？ Travis CI 是一款和 Github 紧密结合的持续集成(CI) 工具。当你的代码被提交到 Github 后，会触发 Travis CI 的 webhook, Travis CI 就会自动去执行一些操作，通常是运行单元测试。当然这种操作并不仅限于单元测试，实际上你可以用它来执行几乎任何命令。由于很多静态博客的源文件(例如 markdown) 就是托管在 Github 上，并使用 Github Pages 发布的，利用 Travis CI 来自动生成静态博客文件并上传到 Github Pages 就成了一件很自然的事情。通过搜索引擎，我们可以搜到这方面大量的使用案例。本文碍于篇幅，这里就不介绍从头搭建一个 Travis CI+ Github 博客的步骤了。下面推荐的几篇教程都还不错不错，可以参考: 手把手教你使用Travis CI自动部署你的Hexo博客到Github上、用 Travis CI 自動化發佈 Pelican blog 到 GitHub Pages 上、Publish your Pelican blog on Github pages via Travis-CI。不同的静态博客工具的配置过程会略有不同，你也可以用。

然而我还是觉得有必要要强调下网上这类教程普遍存在的一个问题: 忽视安全!!! 把博客发布到 Github Page 上的过程说白了就是把 html 文件提交到某个 Github repo 的 gh-page 分支。要让 Travis CI 能提交文件 - 不加密。 - 把使用

在线预览

实在有些鸡肋。如果你的本机已经有了 Pelican 的构建环境的话，构建静态博客并上传到 Github 应该会非常容易。只要运行 make github 就行了，速度也比去 Travis CI 绕一圈快的多。，这种情况下

这种情况下，你无法。虽然 Markdown 格式，语法十分简单。

由于每个 Github repo 只能拥有一个 Github Pages 分支(gh-pages), 我们需要新建一个新的 repo 来存放预览分支。

REST Client 拾遗

2015-02-27T20:15:00+08:00

Restful Service 早已不是什么新鲜玩意。国内很多公司都提供基于 REST 的服务，其中不少还有官方提供的多语言 SDK。先不论这些 REST API 的设计，那些SDK/REST Client 往往并不好用，在 github 上也能找到大量改良的 fork。这里就分享一些我关于写好 REST Client 的愚见。

REST Client 不是 url 拼接器

相当多的 REST Client 说简单了，就做一件事:

import request
class Client(object):
    def post(self, url, data):
        r = request.post(url, data)
        return r.json()

REST Client 返回给用户的应该是解析好的，有意义的对象，而不是原始的 JSON。这些对象应该提供一些数据操作接口，可以方便地修改对象所对应的数据。

以新浪微博 API 为例，官方推荐的 Python SDK 只是把 HTTP GET： statuses/user_timeline 这个请求包装成了 client.statuses.user_timeline.get() 这样的函数调用。这样的 Client 写起来很简单，单个文件就可以搞定，但对用户却不友好。譬如收藏评论这样简单的操作，用户也要不断去翻新浪微博 API 文档，并手动拼接出正确的 API URL。

相比之下，另一个微博 Client，只对 API 返回的实体做了简单的抽象，就已经极大提高 Client 的易用性。扫一眼下面的代码，不看文档，我也知道怎样用代码刷微博了。 Anyway， REST API 是给机器用的， REST Client 是给人用的。

e.g.

# https://github.com/wuyuntao/weibopy
class Comments(Model):
    def destroy(self):
        return self._api.destroy_status(self.id)

    def retweet(self):
        return self._api.retweet(self.id)

    def retweets(self):
        return self._api.retweets(self.id)

    def favorite(self):
        return self._api.create_favorite(self.id)

class User(Model):

    def timeline(self, **kargs):
        return self._api.user_timeline(user_id=self.id, **kargs)

    def friends(self, **kargs):
        return self._api.friends(user_id=self.id, **kargs)

    def followers(self, **kargs):
        return self._api.followers(user_id=self.id, **kargs)

    def follow(self):
        self._api.create_friendship(user_id=self.id)
        self.following = True

    def unfollow(self):
        self._api.destroy_friendship(user_id=self.id)
        self.following = False

    def lists_memberships(self, *args, **kargs):
        return self._api.lists_memberships(user=self.screen_name, *args, **kargs)

    def lists_subscriptions(self, *args, **kargs):
        return self._api.lists_subscriptions(user=self.screen_name, *args, **kargs)

    def lists(self, *args, **kargs):
        return self._api.lists(user=self.screen_name, *args, **kargs)

没有充分利用缓存

成熟的 REST 服务往往会利用缓存来提高响应速度。许多多 REST 服务（例如 github， heroku, 阿里云 OSS）使用 If-Modified-Since(Last-Modified) 和 If-None-Match(ETag) 这两个 HTTP 头来标示缓存信息。一个好的 REST Client 应当在请求时向 Server 端提供这些 HTTP 头。

e.g

# https://github.com/sigmavirus24/github3.py
def refresh(self, conditional=False):
    headers = {}
    if conditional:
        if self.last_modified:
            headers['If-Modified-Since'] = self.last_modified
        elif self.etag:
            headers['If-None-Match'] = self.etag

跨域问题

出于安全考虑，浏览器会限制脚本中发起的跨站请求。绕过这个限制的方法也不少，比如 iframe, JSONP, CORS... 其中跨源资源共享（Cross-Origin Resource Sharing / CORS) 是比较主流的，也是 W3C 推荐的一种做法。本文篇幅有限，其细节可以参考前文所给的链接，接下来让我们专心黑 IE。其他浏览器都是在 XMLHttpRequest 对象上实现了 CORS。唯独微软在 IE8-IE9 里引入了一个新的对象 XDomainRequest，专门处理CORS 请求。这还是个小坑，前端可以很容易绕过。最要命的是在 IE10 以前，XDomainRequest 只支持 GET 和 POST 方法, 而且无法自定义 HTTP Header。于是 PUT， DELETE 方法是不能用了，要设置 Content-type 为 application/json 也不行了。当然解决办法是有的，比如使用 XDomain。但这些方法都需要对 Server 端做一定的更改，无法完全在 Client 端加以解决。

值得一提的是， Django REST Framework 为此原生提供了一种很简单的 workaround。只要设置了 X-HTTP-Method-Override 头，DRF 就会将那些本来是 POST 的请求，当作指定的方法处理。

e.g.

$.ajax({
    url: '/myresource/',
    method: 'POST',
    headers: {'X-HTTP-Method-Override': 'PATCH'},
    ...
});

尽管跨域问题只存在浏览器端，但所有的 Client 也会面临类似的问题：一些企业内部网络由于代理，防火墙的限制，无法使用某些特定的 HTTP 方法。因此 REST Client 在这方面下点功夫还是很有必要。

Finally

在写 REST Client 时会遇到的那些痛点, 很多时候是无法光靠 Client 自身去解决的, 需要服务器端的配合。换个角度看的话，那么Server 端的实现可只能称之为失败。因此我建议那些负责 REST 服务端程序员也去亲自写一下对应 Client 端的代码。对于后端程序员来说，这并不需要多少前端知识，你完全可以使用和 Server 端相同的编程语言，我信心这会带来不少启发。

用 Travis CI 定制多样化的 Python 测试环境

2014-11-13T20:06:00+08:00

Travis CI 是一项面向 GitHub 用户的持续集成即测试服务。只要是在 GitHub 上开源的项目，经过简单配置，便可以利用 Travis CI 来进行自动化测试。

做过 Python 开源项目开发的大概都曾被和特定 Python 版本相关的 bug 叮过。现在比较主流的 Python 运行环境就有: Python 2.6, Python 2.7, Python 3.3 和 Python 3.4 这四种。此外由于 CPython 有GIL 的限制, 近两年来，pypy 也得到了越来越多的关注。尽管目前 Python 3， pypy 在实际产品中还用得比较少，但对 Python3 的支持已经成为大家在选择第三方库时需要考量的一个相当重要指标。

如果是做 Django 开发的话，测试环境多样化的问题就更加严重了。现在大部分 Django 第三方库都会支持 Django 1.4 -1.7 这 4个版本。和上面提到的 4个 Python 版本组合起来，就有 16种之多( 由于 Django 1.5 以上才支持 Python3, 实际有效的组合会略少）。对于某些项目，甚至要考虑不同数据库（MySQL, PostgreSQL, SQLite) 的差异，那么总的测试环境数又要 X3。

尽管通过 pyenv 和 tox 这些工具, 在本地安装和测试多版本的 Python 的流程已经被简化了很多。但光是在十几个环境里把测试一一跑一遍就要花费不少时间。从而导致了我们在平时的开发过程中不会经常去运行这些测试。缺乏测试又会让我们无法尽早发现bug。像 unicode/string 相关 bug，常常是牵一发而动全身，后期修复的代价比较高。

Travis CI 使用 GitHub 项目根目录下的 .travis.yml 作为其配置文件。从后缀名就可以看出，其配置文件是 YAML 格式的。

一个简单的例子：

language: python
python:
- '2.7'
- '2.6'
- '3.3'
- '3.4'
# command to install dependencies
install: "pip install -r requirements.txt"
# command to run tests
script: py.test

上面的 .travis.yml 会创建 Python 2.6 - Python 3.4 这 4 个独立的 Python 测试环境。在每个环境里，通过 pip install -r requirements.txt 安装项目所依赖的 Python Package。

script 用于指定用来执行单元测试的命令。这里我们使用的是 py.test，根据个人喜好，你也可以选择 nosetest, make test, python setup.py tetst ... 对于 Python 项目， Travis CI 会自动安装 nose, pytest, mock 这几个常用的测试库。

对于更加复杂的项目，我们也可以指定多个 install 命令。例如：

install:
- pip install django==$DJANGO_VERSION
- pip install -r requirements.txt
- pip install -e .
env： DJANGO_VERSION=1.7 SECRET_KEY="XXXXXXX" FOO="foo"

上面的配置除了安装 requirements.txt 所罗列的 Python Package 外，还会以 develop 模式安装项目根目录下的 setup.py，并根据 DJANGO_VERSION 这个环境变量，安装指定版本的 Django 。

如果， env 指定了多组环境变量， Travis CI 会将各个版本的 Python 和环境变量组一一组合。下面的配置就会生成 4X3，共12个测试环境。

python:
- '2.7'
- '2.6'
- '3.3'
- '3.4'
install:
- pip install -r requirements.txt
- pip install django==$DJANGO_VERSION
- pip install -e .
env:
 - DJANGO_VERSION=1.7
 - DJANGO_VERSION=1.6
 - DJANGO_VERSION=1.5

注：在 env 列表里，每一行代表一组环境变量。多个环境变量间用空格隔开。

当我们想在每个测试环境中都设置一些环境变量时，我们就要把 env 列表显式地拆分成 matrix 和 global 两个子列表。 global 子列表里的环境变量不参与测试环境的组合。例：

env:
  matrix:
  - DJANGO_VERSION=1.7
  - DJANGO_VERSION=1.6
  - DJANGO_VERSION=1.5
  global:
  - SECRET_KEY="XXXXXXX"

有时，难免会遇到一些无效的测试环境组合，比如 Django 1.7 就不支持 Python 2.6。这种情况下，可以用 matrix.exclude 来排除某些特殊的组合：

matrix:
  exclude:
  - python: '2.6'
    env: DJANGO_VERSION=1.7

总的来说，.travis.yml 的配置还是简明又不失灵活的，用的也是标准的 YAML 语法。如果对 YAML 不熟，建议上手Travis CI前，可以先找一份简明的 YAML 语法说明学习一下，会起到事半功倍的效果。如果你的 .travis.yml 存在语法错误，可以用 Travis WebLint 来作调试和语法检查。

最后，附上我在 django-qiniu-storage 项目中所使用 .travis.yml 以资参考。

language: python
python:
- '2.7'
- '2.6'
- '3.3'
- '3.4'
install:
- pip install -r requirements.txt
- pip install django==$DJANGO_VERSION
- pip install -e .
script: py.test tests/test_storage.py
env:
  matrix:
  - DJANGO_VERSION=1.7
  - DJANGO_VERSION=1.6
  - DJANGO_VERSION=1.5
  global:
  - USING_TRAVIS=YES
  - QINIU_BUCKET_NAME=django-qiniu-storage
  - QINIU_BUCKET_DOMAIN=django-qiniu-storage.qiniudn.com
  - secure: QVYe9vITrCQw924X7h0vYfHwSDGs6QTaHitM2M31hVkYdBWnYMQZcyW1b5DUcXIOot/Z9+1av77tHgh2nXPA34uR7OIzO+LTtmByEE4fOQwJPDkWvJmF63z6B3eRwH20RPg7sBhzQqEK8KPApTiVjRxw5qsf8yp3+V5aozrKAOg=
matrix:
  exclude:
  - python: '2.6'
    env: DJANGO_VERSION=1.7

闲话 Django Raw SQL

2014-09-17T21:33:00+08:00

在 Web 开发中，是否使用和怎样使用 ORM 一直是比较容易引起争议的话题。在 Django 社区里，相关的讨论也有很多。一方面， Django 自带的 ORM 十分简明易学，处理起简单的查询来得心应手，相比与 Raw SQL，代码的可读性好很多。另一方面，面对较为复杂的查询，受限于其表达能力，Django ORM 写起来就有点力不从心了。即使最终能用 ORM 语句搞定，代码的可读性可能还不及 Raw SQL，也比较容易出现性能问题。

Raw SQL or not raw SQL， that is the question。

题外话：尽管，本文的主旨是想探讨下 Django 里 raw SQL 的应用。但笔者仍然强烈建议在使用 raw SQL 之前，应尽量尝试一些常规的 ORM 手段。select_related() 和 prefetch_related() 往往可以大幅减少 SQL 查询的数量。一些性能问题往往可通过 cache 缓解。 django-debug-toolbar 和 django-devserver 对找出存在性能问题的 ORM 查询很有帮助。 Django 官方文档中的这篇 Database access optimization 也是份不错的参考资料。

Manager.raw

Django 的官方文档 Performing raw SQL queries 主要推荐使用 Manager.raw(raw_query, params=None, translations=None) 来执行 raw SQL。而且 Manager.raw 这个API 并不是单纯执行 SQL 语句那么简单，它还提供了不少很有用的功能。

Manager.raw 依然能抵御 SQL 注入攻击。对于接受参数的 SQL 语句，我们不应该手动去填充 SQL 字符串，而是应该在 SQL 语句里加上 %s, %(key)s之类的占位符，然后把实际的值传给 params 参数：

lname = 'Doe'
# Wrong:
Person.objects.raw('SELECT * FROM myapp_person WHERE last_name = %s' % lname)

# Right：
Person.objects.raw('SELECT * FROM myapp_person WHERE last_name = %s', [lname])

通过 Manager.raw ，我们还可以给 Model 加上原来数据库表结构里不存在的字段：

people = Person.objects.raw('SELECT *, age(birth_date) AS age FROM myapp_person')
for p in people:
    print("%s is %s." % (p.first_name, p.age))

raw SQL 可以只包含 Model 的部分字段。当访问那些 raw SQL 没有覆盖到的字段时，Django 会自动触发一条新的 SQL，去查询对应字段的值：

for p in Person.objects.raw('SELECT id, first_name FROM myapp_person'):
    print(p.first_name, # This will be retrieved by the original query
        p.last_name) # This will be retrieved on demand

Manager.raw 虽然很强大，然而它返回的是一个 RawQuerySet 。不同与于正常的 QuerySet ，我们不能在 RawQuerySet 上执行 filter 和 order_by 等常见操作。 RawQuerySet 仍然然支持 Python 的 index 和 slice 操作(query_set[0], query_set[0:5])，但不像QuerySet 是在数据库层面通过 LIMIT 语句完成， RawQuerySet 是将数据集全部取出后，在 Python 代码里做的 index 和 slice, 其实现比较低效。

这些缺陷导致了 raw SQL 很难在不同场合复用。所以，总体上 Manager.raw 给我的感觉是：食之无味，弃之可惜。

Model ↔ 视图

实际上， Django Models 不仅可以映射成数据库里的 Table，也可以映射成View(视图)。

以 MySQL 官方样例数据库 Sakila 里的 sales_by_film_category 视图为例：

# View sales_by_film_category
CREATE VIEW sales_by_film_category AS
SELECT c.name AS category,
    sum(p.amount) AS total_sales
   FROM payment p
     JOIN rental r ON p.rental_id = r.rental_id
     JOIN inventory i ON r.inventory_id = i.inventory_id
     JOIN film f ON i.film_id = f.film_id
     JOIN film_category fc ON f.film_id = fc.film_id
     JOIN category c ON fc.category_id = c.category_id
  GROUP BY c.name
  ORDER BY sum(p.amount) DESC;

注： Sakila 数据库里各表的结构和关系可以参考这篇文档，本文限于篇幅，就不详细解释了。

这样一个数据库视图，通过 Django inspectdb command 解析后，就可以得到如下的 Django Model :

class SalesByFilmCategory(Model):
    category = models.IntegerField(primary_key=True)
    total_sales = models.IntegerField()

    class Meta:
        managed = False
        db_table = 'sales_by_film_category'

这个 Model 除了是只读（不可写）之外，相比于一般的 Model 并无二致。由于 Manager 返回的是普通的 QuerySet, 我们可以链式地调用 filter， order_by 等操作。

e.g:

SalesByFilmCategory.objects.filter(category__in=xxx).filter(total_sales__gt==xxxxx).order_by('total_sales')

相比于 View(此处是指MVC 里的View，而非 DB 的View) 和 Template， Model 往往更加容易和第三方应用进行集成。譬如，通过 django admin 的 ModelAdmin，我们只需几行代码就可以给上面的的视图加上一个漂亮的查询报表界面（尽管是只读的）。类似的，通过 Django REST framework 的 ListModelMixin， RetrieveModelMixin, 给视图加上一个只读的 REST API 也非常简单。 Django 社区会推崇 "Fat Models, Helper Modules, Thin Views, Stupid Templates." 的设计理念的道理正在于此。

我们还可以通过自定义 Model 的 Manager， Meta Class 来进一步定制 ORM，以达到在多个地方重用同一个 Model (View) 的目的。

MATERIALIZED VIEWS

对 View 的查询，从本质上来说和一般的表查询并没有什么不同，因此也不会有性能上的提升。很多情况下，正是因为ORM 生成的查询过于复杂，缓慢，我们才会转投 raw SQL。尽管 raw SQL 给予了我们在最大程度上优化 SQL 查询自由，但有时候优化效果还是不能尽如人意。如果对于查询结果的实时性要求不高的话，将耗时查询的结果 cache 住，会是更合理的解决方案。

Django 自带的 Cache 框架设计十分优秀, 扩展性也很好，这里不再赘述。其实，除了传统的 cache 技术外，在数据库层面也是有文章可做的。 PostgreSQL 9.3 添加了对 materialised views 的支持。Materialised View 是一种特殊的视图。不同与一般的视图， Materialised View 会将第一次查询所得到结果会被缓存到磁盘。再次查询时， Materialised View 将直接返回缓存后的数据，速度自然会很快。

到目前为止，PostgreSQL 的materialised views 还无法像 Oracle 那样做到自动更新 (auto-refreshed)。所以要通过 cron 或 celery 之类的工具去定时刷新 (REFRESH MATERIALIZED VIEW name )。传统的 cache 解决方案( memcached, redis) 支持对每个 key 设定不同的 timeout，相比之下， materialised views 在这方面不够灵活，我们无法对行(Row) 级数据更新。但 materialised views 也有自己的一些优势：

Materialised Views 被配置好后，对最终用户而言，他们就是普通的 Django Model，不需要在代码里对 cache 是否存在/是否需要更新做额外的处理。
memcached/redis 比较适合用来缓存单个 Model 对象，但对于包含多个对象的 QuerySet，其处理能力就比较弱了，无法实现 Django Model.filter 之类的操作。当应用程序代码里有多处使用到相似的 QuerySet，每个QuerySet有所不同，但彼此又存在一定的交集时， cache 就无法得到有效利用。而 Materialised Views 就可以把这些 QuerySet 的合集缓存起来，每个 View 就是一个普通的 Django Model。各个 QuerySet 就只是在 Model 上调用不同的 filtet 方法而已。 PostgreSQL 支持在 Materialised Views 上建立索引，查询速度也不会成为瓶颈。

devpi —— 架设私有 pypi 的最佳选择

2014-05-03T22:31:00+08:00

引言

PyPI 可以说是 Python 程序员几乎每天都要用到的工具（当然由于众所周知的原因，在国内使用豆瓣，阿里云等公司/组织提供的 PyPI 镜像会更加快捷，稳定）。但是在每个公司内部都会有一些的闭源的，私有的 Python Package 。为了让这些私有的 Python Package 的安装流程能和 PyPI 一致，架设一个私有的 PyPI 就很有必要了。

寻寻觅觅

目前，在各大搜索引擎上，无论是去搜索 “how to build a private pypi” 还是 “怎样搭建私有的pypi”，都能找到大量的解决方法和工具。其中比较常见的 "类 PyPI Server" 就有： DjangoPyPI， chishop， pypiserver， Cheese Shop， localshop, mypypi, proxypypi, Flask-PyPi-Proxy ... 就算不是你“选择困难症患者”, 面对如此众多的选择，心里恐怕也要发毛了。

其实在搭建私有 pypi 这个问题上，Python 官方是有一个推荐工具的： devpi。我在试用过上述工具后，也觉得无论是在功能上，还是代码质量上 devpi 都遥遥领先于其他候选工具。可惜的是，由于devpi 是一个在2013 年才起步的新项目，目前 Python 中文圈里还没有人对 devpi 做过详细的介绍，希望本文能起到个抛砖引玉的作用，让更多 Pythonista 知道这个工具。

为什么选择 devpi ?

我以表格的形式对做了常见的 PyPI Server 做了一个对比，总结：

PyPI Server	PyPI代理镜像	本地缓存	单元测试	系统测试	搜索	项目最后更新时间
devpi	支持	支持	★★★★	★★★★★	支持 Web + XML RPC	2014-05-03(本文截稿时)
DjangoPyPI	支持	不支持	★	无	支持 Web + XML RPC	2012-04-19
chishop	不支持	不支持	无	无	不支持	2011-04-02
pypiserver	支持	不支持	★★★★★	无	不支持	2014-04-21
Cheese Shop	不支持	不支持	★★	无	支持Web + XML RPC	已终止开发
localshop	支持	支持	★★★★	无	只支持XML RPC	2014-03-12
mypypi	不支持	不支持	★★	无	不支持	2013-05-31
proxypypi	支持	支持	无	无	不支持	2013-12-06
Flask-Pypi-Proxy	支持	支持	无	无	不支持	2014-01-08

对上表中各列的详细解释：

PyPI 代理镜像

一些比较“古老”的 PyPI Server 只实现了官方PyPI 上已有功能，即允许用户上传, 下载，搜索 Python Packages。换而言之，对于每个 Python Package，都要先上传到私有的 PyPI，然后才能下载。可是在实际开发中，要安装的各种公共的 Python Package 的数量往往要远远多余自己公司内部的私有 Package 的数量，一一手动上传显然并不是及。所以，大部分“现代”的 PyPI Server 无法在本地找到一个 Python Package 时，会自动去官方PYPI 查找一次，并从官方PYPI 下载对应版本的 Python Package。

本地缓存

这项功能是以 “PyPI 代理镜像” 为前提的。对于公开的的 Python Package，从 PyPI上下载回来后。如果能在本地做一个缓存，下次请求就不必再去访问外网了。这不仅提高了下载速度，也保证了 PyPI Down掉后不会影响你网站/软件的部署。此外在某些生产环境下可能要禁止访问外网，再者现在不少程序员带着笔记本去喜欢去星巴克，公园之类的场合码代码, 这些地方的网速往往不是很稳定，这项功能就更加实用了。

单元测试

单元测试的数量和覆盖率显然是衡量软件质量的指标。 devpi 的单元测试非常完善，其测试用例多达 200 多个。值得一提的是， Python 社区里两大著名测试工具 pytest 和 tox 也是出自 devpi 的作者 holger krekel 笔下。因此，对于 devpi 的代码质量，我们大可打五星好评。

系统测试

除了完善的单元测试外， devpi 还有着一个看似疯狂的系统测试。 devpi/server/extra/compare_pypi_devpi.py 这个脚本会去抓取 PyPI 上所有 3 万多个 package 的链接，并和 devpi 的本地缓存比较，从而保证了所有 PyPI 上的 Python Package 都是能被 devpi 处理的。据 devpi 的作者透露，他用这个测试脚本发现了不少古怪的，需要特殊处理的 package。可见这个看似变态的系统测试还是很有必要的。由于其他 PyPI Server 都没有做过这类测试，其可靠性不由让人怀疑。

搜索这块没有多少可讲的，略过不谈。

项目的开发活跃度

如果项目长期得不到更新，不仅用户渴望的新功能不会被实现，那些困扰用户的 bug 也不会被修复。1-2年的不到得不到更新对一个开源项目往往是致命的。 devpi 的开发十分活跃，几乎每天都有提交。考虑到，再过不久， Warehouse 就要取代现有的基于 Cheese Shop 的 PYPI了。届时新的 PyPI 会新增一些功能和API, 我们自然也希望私有的 PyPI Server 能实现这些功能。我在 twitter 上同时 fololow 了 pip 和 PYPI 的主要维护者 @dstufft 和 devpi 的作者 @hpk42，常见到两人讨论如何在 devpi 上实现 warehouse 的新功能。

不难看出，对于每一指标， devpi 在同类竞争者中都是最优秀的。

devpi 特有的功能

Index 继承

这是前面提到的 “PyPI 代理镜像” 功能的加强版。像 pypiserver， proxypypi 等实现只支持两个Index：私有的和共有的。在私有 Index 上找不到用户请求的 Python Package时，就会 fallback 去 Public PyPI。 devpi 对这一功能做了扩展， devpi可以支持多个 Index，这些Index可以像面向对象编程里的类一样，存在继承关系。

举个实际一点的使用例子。在我司还有少量系统是运行在老旧的 FreeBSD 和 Pythohn 2.5 上。，不少 library 是无法直接工作的，要打 patch。所以我司会维护两个 Index，一个放公司内部开发的库(Internal Index)，一个放专门为老系统适配修改的后的 Package(Legacy Patched Index), 继承关系如下：

Public PyPI --> Internal Index --> Legacy Patched Index

这样老系统使用 Legacy Patched Index ，新系统使用 Internal Index，互不干扰。那些同时兼容新老系统的 Package 就上传到 Internal Index， Legacy Patched Index 因为继承的原因，也可以使用。

集成 Jenkins

数据导入/导出

用户上传到 devpi 的 package 是可以被统一导出和导入的。这项功能除了用于数据备份外，也被用于 devpi 升级时的数据迁移。

replication

devpi 原生支持 replication 和 failover，保证高可用。

Python Packaging 编年史

2014-04-16T20:57:00+08:00

distutils-sig 工作组成立

最初，Python 并没有自带的包管理器。纯 Python 的模块（module）往往是通过直接拷贝源代码到相应目录来安装的。如果要发布的模块包含 C extension ，那么还要写一个冗长的 Makefile。导致程序员之间想要共享模块很不方便。

在 1998年的 Pycon 上，终于有人 hold 不住了， Greg Ward 作了一场名为 "Building Extensions Considered Painful" 的演讲，引起了很多与会者的共鸣。于是会后他们建立了 distutils-sig 工作组和同名的邮件列表，专门用来讨论开发 Python 包管理系统的相关事宜。

1998年

disutils 被纳入 Python 标准库

历时2年的开发后，distutils 终于修成正果，被添加到 Python 1.6 的标准库中。从此 Python 社区有了自己的包管理库。

Disutils 使用 setup.py 作为模块的配置文件，并通过 python setup.py CMD 的形式，提供了一套用于编译 C extension, 打包 ... 的命令

尽管用今天的眼光来看，Disutils 有很多不足。但在当时 Disutils 确实是一个十分出色的包管理系统。由于吸取了Perl 社区1在Makefile.PL 上的教训，且为了更好地跨平台， Disutils 没有基于当时盛行的 Makefile。Disutils 充分运用了 Python 简明而又强大的特性，没有为了 Packaging 去单独研发一套 DSL， setup.py 就是一个普通的 Python 文件。

2000年

catalog-sig 工作组成立

当时 Perl 社区的 CPAN 运营的非常成功。眼红的 Pythonista 们也开始着手创建 Python 的公共第三方模块库

2000年

PEP 241 Metadata for Python Software Packages

A.M. Kuchling 起草了 PEP 241,用于规范 Python Package 的元信息

2001年

PEP 301 Package Index and Metadata for Distutils

PEP 301 是 PEP 241 的补充。约定了元信息该以怎样的格式被存储在 setup.py 中，来让 disutils 和 PyPI 识别。

2002年

PyPI 正式上线

Python Package Index(PyPI) 最初也被叫做 Cheeseshop。时至今日， PyPI 已经收录近 5万个第三方开源模块。 Disutils 也做了相应的升级，以支持元数据和上传 Python Package 到 PyPI。

2003年

setuptools 发布

setuptools 是由 Phillip Eby 开发的。

2004年

virtualenv 发布

最初，所有的 Python Package 都是安装在系统的全局 site-packages 目录下。开发者要安装第三方库，常常要有 root 权限。不同项目安装的第三方库也容易导致版本冲突。Ian Bicking 开发了 virtualenv 用于创建独立的 Python 运行环境。virtualenv 和 pip 应该是每个 Python 程序员熟知的工具，这里就不再赘述了。

2007年

pip 发布

pip 同样是由 Ian Bicking 开发。

2008年

distribute

setuptools 很快就成为 Python 社区中首选的包管理库。但是正当 setuptools 如日中天的时候，它的开发却嘎然而止。明明有一大堆 pull request 在等待 merge, 开发者却杳无音信。Python 3 的支持也迟迟不加。最终 Tarek Ziade 从 setuptools fork 出了 distribute。

虽然 distribute 在各方面都优于 setuptools，但 setuptools 毕竟盛名在外，Python 社区从 setuptools 转移到 distribute 上话了很长时间，并造成了一定的社区分裂。

2008年

PyPA 成立

2011年 2月 28日

Distutils2 的开发被终止

曾被寄予厚望的 disutils2，没能按原计划在随 Python 3.3. 发布。

disutils2 项目失败的原因有很多。 disutils2 的开发者人数只有 1-2 名，而且都是在用业余时间开发, 由于开发者没有足够的精力，开发经常陷入停滞。项目也十分缺少 beta 用户，也很少得到用户的反馈。

2011年 2月 28日

Pycon 2013 - Directions for Packaging

由于 disutils2 项目被放弃，对开发者而言，未来的 Python Packaing 会是怎么样是个未知数。

于是趁着 Python 程序员的年度盛会 Pycon 的召开，PyPA 设法让 distributue, virtualenv, pip, wheel, PyPI, zc.buildout 等项目的开发者们齐聚一堂, 共同讨论和规划 Python Packaging 未来的开发路线。 Youtube 视频

2013年 3月 15日

PyPI 有了 CDN 加速

Fastly 公司很慷慨地为 PyPI 提供了免费的 CDN 加速。

天朝用户应该对此印象十分深刻，这倒不是因为有了 CDN 之后访问速度变快了。2014年上半年有一段时间 PyPI无法正常访问就是拜某墙所赐。

2013年 5月 26日

Distribute 项目被 merge 回了 setuptools

2013年 6月 9日

pip 成为 Python 3.4 自带的包管理库

让我们看个冷笑话吧：

甲： Python 的包管理工具是什么？

乙：pip

甲：pip` 是 Python 自带的吗？

乙：不是。甲：那么我应该怎么安装 pip ?

乙： easy_install pip

甲：easy_install 是什么？

乙：一个 Python 包管理工具

甲：...

2013年 8月 10日

在 vagrant shared folder 下运行 python setup.py sdist 会报错的解决方法

2014-03-18T14:05:00+08:00

我 PC 上的开发环境是 Windows + Vagrant ( VirtualBox )。常用的编辑器则是 sublime, pycharm 之类的图形化工具。为了方便在 windows 上编辑 vm 中的文件，代码都是放在 virtual box 的 shared folder 下的。

前不久，在我打包 django-qiniu-storage 并发布到 pypi 时，遇到了点麻烦。

当我运行 python setup.py sdist 时，出现了如下错误：

>>> python setup.py sdist

running sdist
running egg_info
...
hard linking xxx -> xxx
error: Operation not permitted

还好错误信息还算是比较明了的: 因为脚本是在 Ubuntu 虚拟机下运行， Python 假设操作系统支持 hardlink, 于是 setup.py 会尝试在工作目录下建立 hardlink, 但是virtualbox 目前还不支持在 shared folder下建立 hard link, 从而引发了 Operation not permitted。

用 Google 和 stackoverflow 搜索之后，发现这个 bug 已经分别被人反馈给 Python 和 virtualbox 的开发者了，但是在 Python 和 virtualbox 任何一方都不太可能在短时间内被修复。

幸运的是，在 python 的 bug 讨论列表里，有人给出了一个可行的解决方案:

A dirty hack is to include this line at the top of your setup.py: del os.link

因为 disutils 是通过检查 os.link 是否为 None 来决定是否使用 hardlink, 那么将 os.link monkey patch 为 None 就行了。这么做除了多占用些微不足道的磁盘空间，不会有任何副作用。

我做了个小改动，通过检查环境变量，只有当 setup.py 在 vagrant 下运行时，才会 del os.link.

# put the following code at the beginning of your setup.py
# if you are not using vagrant, just delete os.link directly,
# The hard link only saves a little disk space, so you should not care
if os.environ.get('USER','') == 'vagrant':
    del os.link

A guide to analyzing Python performance

2013-09-18T17:28:11+08:00

链接

一篇 Python 性能分析方面的好文，介绍了分别用 unix time命令和 context manager 来粗略/精细地测试 Python 脚本的运行时间；使用 line_profiler 库精细衡量每行代码的执行时间；使用 memory_profiler 库测试内存使用情况；使用 objgraph 库检测内存泄漏 ...

Appscale——Google App Engine的开源克隆/替代

2013-08-26T14:13:20+08:00

这个项目其实出来以及很久了，只是前几天才在HackerNews引起关注，github上的 star, watch数也随之飙升。我之前苦苦搜寻GAE的替代时，都没发现这个项目。

使用界面:

Appscale 在底层使用了大量知名的开源软件，包括并不限于：

Apache Cassandra,
Apache Hadoop,
Apache HBase,
Apache Thrift,
Apache Zookeeper,
Celery,
ejabberd,
HAProxy,
Hypertable,
Nginx,
RabbitMQ,

Appscale 在这些开源项目之上实现了一套和 Google App Engine 兼容的 API。而且该项目得到了 Google 官方支持，不愁未来 Google App Engine 更新后的兼容性。

无论是编程语言，db, 搜索，map reduce 还是IaaS, 各层都是 pluggable 的，开发者可以自由选择自己最熟悉的 tech stack，目测是一个很灵活的 PaaS.

架构图:

view on Github

Migrating to a Custom User Model in Django

2013-08-26T11:57:00+08:00

链接

这篇 blog 详尽阐述了把现有的 UserModel 迁移到 Django 1.5 的 Custom User Model 所需的十几个步骤和注意事项。

对打算迁移 UserModel 的同学来说，是一份很不错的checklist!

让django-debug-toolbar支持Python2.5

2013-08-22T14:27:00+08:00

django-debug-toolbar 从 0.9.x 开始就放弃对 Python 2.5 的支持了。最简单的做法是将那些仍深陷在 Python 2.5 泥沼里的 Django 项目的 django-debug-toolbar 版本指定为 0.8.x。遗憾的是，作为最受欢迎的 Django 第三方 package, django-debug-toolbar 本身也有不少很有用的第三方 plugin ，而这些 plugin 为了使用 django-debug-toolbar 的 new features 往往就不再支持 0.8.x 版的 django-debug-toolbar 了。比如 django-debug-toolbar-template-timings 这个用来 profile Django templates 渲染时间的插件。

这种情况下，只能手动去给 django-debug-toolbar 的源码打 patch了。好在截至目前的 0.9.4 版本，让 django-debug-toolbar 支持 Python 2.5, 所要做的改动很小。

在8个月前，曾有人提交了的一个支持 Python 2.5 的 patch 到 master 上，但之后由于 Django 1.5 明确放弃 support Python 2.5, 现在的 master 已经再次不支持（而且这次是永久不再支持） Python 2.5了。但对上面的 patch 稍作修改，就能让 pypi 上 django-debug-toolbar 最新的正式版本0.9.4，在 Python 2.5 下工作.

patch( pygments生成的diff highlight html效果不是很好，可以去看 gist):

diff --git a/debug_toolbar/panels/sql.py b/debug_toolbar/panels/sql.py
index 18fffdc..a0bfce8 100644
--- a/debug_toolbar/panels/sql.py
+++ b/debug_toolbar/panels/sql.py
@@ -193,8 +193,14 @@ class SQLDebugPanel(DebugPanel):
                 stacktrace = []
                 for frame in query['stacktrace']:
                     params = map(escape, frame[0].rsplit('/', 1) + list(frame[1:]))
+                    params_dict = dict((unicode(idx), v) for idx, v in enumerate(params))
                     try:
-                        stacktrace.append(u'<span class="path">{0}/</span><span class="file">{1}</span> in <span class="func">{3}</span>(<span class="lineno">{2}</span>)\n  <span class="code">{4}</span>'.format(*params))
+                        stacktrace.append(u'<span class="path">%(0)s/</span>'
+                              u'<span class="file">%(1)s</span>'
+                              u' in <span class="func">%(3)s</span>'
+                              u'(<span class="lineno">%(2)s</span>)\n'
+                              u'  <span class="code">%(4)s</span>'
+                              % params_dict)
                     except IndexError:
                         # This frame doesn't have the expected format, so skip it and move on to the next one
                         continue

Letterpress

2013-08-18T23:17:41+08:00

Letterpress 是墨客的作者 Wang Ling用Python开发的一款静态博客生成器。

Letterpress的风格十分简洁，使用Markdown语法。作者由于习惯用iPad写作，在设计时也特别考虑了在移动平台上的使用体验。

服务器端的Letterpress 后台进程通过 pyinotify,监控服务器指定目录下的Markdown文件的增改删，然后将相同的动作作用于对静态博客文件上。

配合上dropbox,可以轻易得将本地文件变化，推送到服务器端。管理博客也就是用Markdown编辑器里增改删文件的事。

Letterpress还支持使用Pygments高亮Markdown文件里的代码块。

Django 无法在QuerySet中select_related()一个GenericForeignKey的解决方法

2013-08-16T16:20:00+08:00

在Django开发中，用 select_related() 把 item 的 ForeignKey 在同一条SQL中通过 join table 一起取出是很常见的做法。但 select_related 是不支持 GenericForeignKey （主要用于 ContentType）的。

自Django 1.4开始， Django 提供了 prefetch_related 这个方法来解决这个问题。除了 GenericForeignKey. ，prefetch_related 还可以作用在 ManyToManyField 和 'many-to-one' 的 ForeignKey 这些 select_related() 不支持的 field. prefetch_related 的原理是对related field 做一次独立的 query, 将 related field 缓存在内存中，今后去取 queryset 中各个 item 的 related field 时，就直接从缓存中找，而不是每次都做一次 db query. 对 prefetch_related 更详细的解释可以参考官方文档。

对 Django 版本低于1.4的项目，可以参考这篇博客 Django patterns, part 4: forwards generic relations 给出的解决方法. 其思路和 prefetch_related 几乎是一样的，都是缓存 related field 。把 N+M 条SQL （N 是 queryset中item的数量，M是的 related_field 的 Model 的 item 数量）简化成2 条 SQL。

下面是我基于Daniel Roseman 的博客，在Justin Israel的 gist基础上改良的脚本，虽然只支持 content_type 的 GenericForeignKey ，但经过简单的修改，可以很容易支持其他类型的field.

'''
Cache the generic relation field of all the objects 
in the queryset, using larger bulk queries ahead of time.

Improved from original by Daniel Roseman:
http://blog.roseman.org.uk/2010/02/22/django-patterns-part-4-forwards-generic-relations/

and

justinfx's gist cache_generics.py :
https://gist.github.com/justinfx/3095246#file-cache_generics-py

Supports customized object_id_field and GenericForeignKey name.

'''

from operator import attrgetter
from django.contrib.contenttypes.models import ContentType

def cache_generic_content_types(queryset, object_id_field='object_id', content_type_fk='content_object'):
    """
    Django does not support select_related on generic foreign key. Thus some
    ORM actions may trigger N+M querys(N is item number of the queryset and
    M is the item number of the content type). This function will cache content
    and reduce N+M querys to 2 querys.

    object_id_field: see https://docs.djangoproject.com/en/1.3/ref/contrib/contenttypes/#django.contrib.contenttypes.generic.GenericRelation
    content_type_fk: the name of GenericForeignKey which linked to content type
    """
    get_object_id = attrgetter(object_id_field)
    generics = {}
    for item in queryset:
        if get_object_id(item) is not None:
            generics.setdefault(item.content_type_id, set()).add(get_object_id(item))

    content_types = ContentType.objects.in_bulk(generics.keys())

    relations = {}
    for ct, fk_list in generics.iteritems():
        ct_model = content_types[ct].model_class()
        relations[ct] = ct_model.objects.in_bulk(list(fk_list))

    for item in queryset:
        try:
            cached_val = relations[item.content_type_id][get_object_id(item)]
        except KeyError:
            cached_val = None
        setattr(item, '_%s_cache' % content_type_fk, cached_val)
    return queryset

view gist: generic_relations.py

无节操的nude.py识别哔～～～～图评测[NSFW]

2013-08-12T23:15:46+08:00

发个无节操的东东： nude.py

故名思意，nude.py就是一个Python实现的，判断一张图片是否是nude的library.

安装很简单：

pip install nudepy

nude.py的图片识别/处理是依赖于PIL或Pillow的，由于Pillow的安装过程比PIL简单很多，强烈推荐用Pillow。

# 让Pillow支持jpeg
# 若未安装libjpeg,用Pillow处理JPEG 图片，会报 IOError: decoder jpeg not available
# 此时要先pip uninstall Pillow, 安装好 libjpeg,再重新 pip instal  Pillow
sudo apt-get install libjpeg8-dev pip install Pillow

nude的API很简单：

import nude
from nude import Nude

print(nude.is_nude('./nude.rb/spec/images/damita.jpg'))

n = Nude('./nude.rb/spec/images/damita.jpg')
n.parse()
print("damita :", n.result, n.inspect())

实测结果：

先来几张吾王的:

这几张~~玉照~~御照被nude.py毫无异议得判为nude，就连下面这张不怎么犯规的的，也没能幸免

不过下面这种尺度的，就不会被错杀了。

这让我想起了当年让小朋友们闻风丧胆的绿坝娘。坝娘横行马勒戈壁，最后竟是栽在了这几只喵星人头上。

Nude.py表现相当不错，这几只肥猫都没能蒙混过去。

来个2.5次元的，这只吾王的手办，也被判为Nude。

最后二次元的情况不容乐观，不知道是不是现在男孩子太可爱的缘故，这几张都没能识别出来

就下面这两张识别出了：

金闪闪惹不起，也识别出了：

在节操掉尽前，再多说一句，二次元的图片，如果用的是XXX的话，识别率蹭得就上去了。对看了本文心动手痒的诸位绅士来说，这是好事吧。

为什么在大多数编程语言里，位运算符的优先级(& ^ |)低于比较运算符(== > < !=)

2013-08-12T14:48:06+08:00

当初学C语言的时候，我也曾经思考过这个问题,感觉位运算符的优先级应该在移位运算符(<< >> )的和不等于运算符( < <= >= >)这两类运算符之间更合适。可惜当时没能不求甚解，以为K&R两位大师这么做自有其玄妙，吾等凡人功力商浅不必参悟透彻。多年后，在StackOverflow上碰巧看到这个问题 Why do bitwise operators have lower priority than comparisons?，终于解答了我的疑惑。

Dennis M. Ritchie 大神的解答(The Development of the C Language):

Neonatal C

Rapid changes continued after the language had been named, for example the introduction of the && and || operators. In BCPL and B, the evaluation of expressions depends on context: within if and other conditional statements that compare an expression's value with zero, these languages place a special interpretation on the and (&) and or (|) operators. In ordinary contexts, they operate bitwise, but in the B statement

if (e1 & e2) ...

the compiler must evaluate e1 and if it is non-zero, evaluate e2, and if it too is non-zero, elaborate the statement dependent on the if. The requirement descends recursively on & and | operators within e1 and e2. The short-circuit semantics of the Boolean operators in such `truth-value' context seemed desirable, but the overloading of the operators was difficult to explain and use. At the suggestion of Alan Snyder, I introduced the && and || operators to make the mechanism more explicit. Their tardy introduction explains an infelicity of C's precedence rules. In B one writes

if (a==b & c) ...

to check whether a equals b and c is non-zero; in such a conditional expression it is better that & have lower precedence than ==. In converting from B to C, one wants to replace & by && in such a statement; to make the conversion less painful, we decided to keep the precedence of the & operator the same relative to ==, and merely split the precedence of && slightly from &. Today, it seems that it would have been preferable to move the relative precedences of & and ==, and thereby simplify a common C idiom: to test a masked value against another value, one must write

if ((a&mask) == b) ...

where the inner parentheses are required but easily forgotten.

简而言之，是两位大神掉进了自己挖的坑里了。C语言的前身是B语言。B语言是没有逻辑运算符（&& ||）的，是通过位运算充当逻辑运算的。大神在发明C时，沿用的B语言的一些~~陋习~~传统。由于C的流行，在C之后发明的大多数类C语言也纷纷掉这个坑里了。

Access klipper clipboard on CLI under KDE4

2013-08-07T14:01:21+08:00

链接

一个让KDE的剪贴板工具Klipper可以在命令行中使用的脚本

Chrome Logger

2013-08-07T13:57:00+08:00

安装好Chrome Logger的Chrome扩展，并在服务器端安装对应语言（目前支持Ruby, PHP, Python, Node.js, .NET）的Chrome Logger库后，就可以在服务器端用类似console.(variable)的语句log变量，然后在Chrome Dev Tools上查看变量的实际值。

以Django为例, 配置十分简单：

# django middleware
MIDDLEWARE_CLASSES = (
    'chromelogger.DjangoMiddleware'
)

# views
import chromelogger as console
console.log('Hello console!')
console.get_header()

gif 演示:

Project Homepage

A simple demo for tornado web socket

2013-08-04T17:29:00+08:00

Python Code

JS Code

Subclass WebSocketHandler to create a basic WebSocket handler.

Override on_message to handle incoming messages, and use write_message to send messages to the client. You can also override open and on_close to handle opened and closed connections.

The only communication methods available to you are write_message(), ping(), and close(). Likewise, your request handler class should implement open() method rather than get() or post().

参考: tornado.websocket — Bidirectional communication to the browser

Crate.io 一个更快，更美，更好的 pypi

2013-08-03T23:50:07+08:00

Python 程序员几乎每天都会用到 pypi，但 Pypi 的 web 界面实在称不上好看，好用。于是有一帮 Python 程序员坐不住了，捣鼓出了 crate.io。

Crate.io 托管在上heroku上，访问速度比pypi快。

对比pypi和Crate.io对关键字"secure"的搜索结果，很明显 Crate.io 搜索结果更精准，排名也更合理。搜索结果左侧还提供了很多有用的filter。

通过Package页面里的All Version 和 History，可以很方便得找到package历史版本。

顺便吐槽下python.org的改版，一年都快都过去了，还没改好啊。

Updates:

目前 crate.io 已经无法访问了， Pypi 的团队已经决定，将在 crate.io 的基础上打造一个全新的 pypi 。目前还在开发中，预计在2014年上线。

新版 pypi 的 github 项目地址: warehouse

Python的双层循环可以这么玩

2013-07-15T00:33:00+08:00

把对循环的控制，过滤拆分到一个generator中，在主循环中只存放对循环对象操作的逻辑，不仅是代码更加清晰，也避免了从内层循环退出的麻烦事

参考 Loop like a native: while, for, iterators, generators (PyCon US 2013 Talk)

博客新logo的来历

2013-07-08T12:37:17+08:00

博客新logo的来历:炼金术中代表狮子座(Leo)的符号

------------------------分割线------------------------

本人不是狮子座的，也不是处女座了。

Google Reader 魂兮归开

2013-07-08T11:19:07+08:00

今天是Google Reader 头七，缅怀下遗容

找回Android Gmail客户端的删除邮件按钮

2013-07-01T15:10:00+08:00

著名广告公司 Google Inc. 几个月前在给Android的Gmail客户端加上了实用的通知栏操作，更好的扁平化UI时，也顺便把一直就看不顺眼的删除邮件按钮给隐藏掉了。

当然，以"不作恶"为准则的Google是不会把这个很多用户想要的按钮给直接砍掉的(不过，再过几个小时,Google Reader是铁定要被砍了 R.I.P), 他们只是把它藏得很深很深，以至于不用他们家的搜索服务的话，普通用户是压根找不回来的。

废话了这么多，其实要把删除按钮找回来，就只要进 菜单\>设置\>常规设置 , 选那个言不达意的"归档和删除操作" 就行了。

"2" < 1 == True

2013-06-21T11:45:16+08:00

Python 语言中，不同类型对象之间的比较规则浅析

今天为了捉一个臭虫耗废了近一个小时，最后发现是 if foo > 1:这里的foo实际是字符串，导致foo是"0"时，"0" > 1为真。于是便花了点时间研究了下Python比较运算规则。

在Python2中，比较运算遵循以下规则:

数字和数字按大小排序（数字类型包括 int, float, long, complex, bool）
字符串按字符串按字典序排序(str, unicode)
数字类型和非数字类型比较，除None外,数字类型总是小于非数字类型。
两个非数字不同类型，按其类型名的字典与排序
第4点有一个特例，老式类的实例总是小于新式类
非数字/字符串类型的同一类型的不同实例的比较，如果类定义了__cmp__()方法，则用该方法比较
同上，若类型没定义__cmp__()方法，则按实例在内存中的地址排序
None < None
3，4，5，7 是CPython的实现，不是Python语言自身的标准，参见[CPython implementation detail][]。 Python语言只要求对非数字和字符串类型的不同对象的比较，总是不想等的，比较结果可以是任意的，但必须是一致的（即多次比较，结果恒定）。

Python3终于修了这个bug ( What’s New In Python 3.0 ), 规则如下：

incomparable类型对象比较 \<, \<=, >=, > 会 raise TypeError
incomparable类型对象比较！=, == 仍是合法的，但总为False
cmp()和__cmp__()方法被弃置了，取而代之的是__lt__()，__eq__()，__hash__() ...

Python2 当初会设计这种比较规则，可能是为了便于对包含不同类型对象的容器排序。list.sort()和sorted()都仿照了C/C++里的sort。Python2.4后sort使用key来比较不同对象显然更Pythonic

更多例子，参见Sorting Mini-HOW TO

The ignored decorater

2013-06-14T14:16:00+08:00

@ignored

再介绍一个关于Python的冷知识，可以用 @ignored context manager来显式地声明要忽略的无关紧要的异常

虽然 try except后再pass掉的做法更常见，但其含义比较隐晦。阅读者往往要把代码块读到最后才能知道那些错误是要忽略的。然后再回过来检查这些异常是否该被忽略。

可惜Python3.4+才支持

Upates:

最新的Python3.4 dev 又把这个 decorator 被改名为 @suppress

小硬盘伤不起-将Vagrant移出系统盘的方法

2013-03-02T22:55:00+08:00

最近用上vagrant，叹为神器的同时，它将所有文件全存系统盘的做法，也让我很伤脑筋。很多开发者系统盘用了SSD，相信为此头疼的不只是我一个。

在万能的Google的加持下，最终还是找打了解决办法。

更改VirtualBox虚拟机映像文件的位置

打开 VirtualBox 程序，点击管理/全局设定菜单项(Ctrl+G), 将常规栏里的默认虚拟电脑位置(M)改为其他磁盘下的路径
将原路径 C:\Users\user_name\.VirtualBox\VirtualBox VMs 下的文件移动到新路径下。
重新启动VirtualBox程序，在虚拟机列表里，以前建立的虚拟机虽然都还在，但已经不可用了，将他们全部删除。
双击打开新路径各个文件夹里的vbox文件，将建立的虚拟机重新导入。

VirtualBox虚拟机映像文件是vagrant最多的一块, 上述方法应该能显著减少vagrant对系统盘的空间占用。只是如果添加的vagrant box数量比较多，其占用的空间也是很可观的，可以用下面的方法将其移出系统盘。

更改vagrant配置文件的位置

将 C:\Users\user_name\.vagrant.d 移动到新的位置
新建环境变量VAGRANT_HOME，并指向新路径

最后吐槽一句无关的，我第一次知道 vagrant 居然是在Pycon上，而不是RubyConf上

小内存用户chrome的福音:一键管理所有扩展

2013-02-25T11:54:06+08:00

很多chrome扩展在用户点击它之前，不会干任何正事，却会占用大量内存。(为了解决这个问题，Google推出了根据事件触发的event page来替代一直跑在后台的background page。但目前使用的开发者并不多。大概是国外web开发者的电脑配置都很高吧)

使用One-Click Extensions Manager可以一键（实际上是两键啦）启用或关闭一个扩展。这样，很多使用频率不高的扩展平时都可以关了。在我公司那台跑着XP的老爷机上实测效果很明显。

而且与大多数chrome扩展不同，这个扩展不使用时，是不占用内存的，所以不用担心新加个扩展反而导致内存占用增多的情况。

如果你需要更多功能，下面两个扩展，可能也会有用:

Extension Automation 可以在不同的站点自动启用相关的扩展。

Context 则可以将扩展分组，并一次启用或关闭多个扩展。

当然这两款扩展在提供更多更能时，其界面和配置也更加复杂，占用的资源也更多，还是One-Click Extensions Manager最为灵活。

Golang Weekly Go语言周报

2013-02-22T11:48:26+08:00

Golang Newsletter

介绍最新的Go语言和社区动态，每月大概有1-2封，对Go感兴趣的同学可以关注下

为 Github for Windows 设置代理

2013-01-21T15:02:00+08:00

今天在公司电脑上安装了Github for Windows，但一直无法顺利登陆。由于公司电脑必须通过HTTP代理才能连上外网，而Github for Windows自己又不提供设置代理的界面，就只能求助Google了。

Google github for windows proxy 到的前几个link都说要设置 .gitconfig, 加入下列内容:

[http]

proxy = host:port

[https]

proxy = host:port

很不幸，添加后依旧登陆不上。

之后又排除了Github for Windows 会自动适应IE的代理设置的可能。恰好，今天开始github成为了gfw敏感词，于是又怀疑到了方校长头上。

最后换了搜索关键词github for windows login failed,才在这个链接里发现了正解。

打开命令行，加入

SET HTTPS_PROXY=host:port

SET HTTP_PROXY=host:port

就行了

Updates:

github for windows login failed 可能是由多种原因导致的，本文提到的 bug以被修复，不再适用

为什么有些网址中使用“utf8=✓”而不是“utf8=true”?

2013-01-18T01:11:00+08:00

IE又中枪了。老版本的IE浏览器 (< IE9) 提交 form 数据时，会尽可能地使用Latin-1编码，而不是群众喜闻乐见的 utf-8 编码。

✓这个无法用Latin-1编码的字符会迫使IE使用 utf-8，从而简化了server端的实现。

同理，Ruby on Rails 是在 form 里插入一个值为 ☃ 的 hidden input field。

Stackexchange 上的问答: Is the use of “utf8=✓” preferable to “utf8=true”?

用tmux提高工作效率配置篇

2013-01-16T16:04:00+08:00

本文中很多内容都是摘自《tmux Productive Mouse-Free Development》一书。书的篇幅也不长，只有80多页，感兴趣的话，推荐一读。 豆瓣

tmux配置文件的地址

分两种：

/etc/tmux.conf 存储的是系统中所有用户的全局配置
~/.tmux.conf 存储的时用户个人的配置

自定义快捷键

tmux 一些默认的快捷键并不是很好用，下面罗列一些笔者觉得更人性化的自定义快捷键

set -g prefix C-a 将prefix键设为Ctrl+a
prefix键在tmux中使用十分频繁，几乎所有的都需要先按prefix键，而tmux默认的prefix键是C-b(Ctrl+b), Ctrl键和 b相隔甚远，十分难按，非常坑爹。

很多tmux用户曾使用过GNU screen, screen的prefix键 C-a显然比C-b更加便捷，也减少了screen用户的学习成本

对于prefix键重度使用者，可以用键位映射工具，将CapsLock大小写锁定键映射成Ctrl键，C-a就更加容易按了。

添加了新的的prefix键位后，将C-b与prefix键解绑，留作他用。 unbind C-b

source-file ~/.tmux.conf 之后，更改的配置才会生效

bind C-a send-prefix 由于prefix按键被tmux拦截，Emacs,VIm等软件可能会不能正常工作，这个设置可以让用户连按两次C-a,来向第三方软件发送prefix按键
bind r source-file ~/.tmux.conf 按r可以让更改后的tmux设置生效
bind | split-window -h

bind - split-window -v

纵向和横向切分面板。切分面板本来是tmux的一大杀器，但默认的命令太过繁琐，而且|和-更直观得表明了切割方向
bind h select-pane -L

bind j select-pane -D

bind k select-pane -U

bind l select-pane -R

在不同面板间切换。也是比较常用的，用LDUR表示方向在按键时很不方便，改为vim风格的。
bind -r H resize-pane -L 5

bind -r J resize-pane -D 5

bind -r K resize-pane -U 5

bind -r L resize-pane -R 5

改变面板的大小。四个方向还是使用vim风格的方向键，不过这里用的是大写。

这里-r的作用是，如果要窗口向上扩展一大段空间，按了prefix键后，连着按H就行了。
bind -r C-h select-window -t :- bind -r C-l select-window -t :+ 切换窗口。这里的按键和切换面板的对应。

基本的界面设置

set -sg escape-time 1 tmux，会有一个延时，以方便用户输入按键组合，但默认的有点长，1秒钟足矣
set -g base-index 1 有些用户习惯让窗口的编号从1开始（默认是0）
setw -g pane-base-index 1 类似的可以设置面板的开始编号

鼠标相关的设置

setw -g mode-mouse on
set -g mouse-select-pane on
set -g mouse-resize-pane on
set -g mouse-select-window on

即使在命令行下，鼠标有时也是能提高工作效率的

色彩设置

set -g default-terminal "screen-256color" 让tmux支持256色
设置底部状态条的颜色

set -g status-fg white

set -g status-bg black

setw -g window-status-fg cyan

setw -g window-status-bg default

setw -g window-status-attr dim

setw -g window-status-current-fg white

setw -g window-status-current-bg red

setw -g window-status-current-attr bright
设置面板间分割线的颜色

set -g pane-border-fg green

set -g pane-border-bg black

set -g pane-active-border-fg red

set -g pane-active-border-bg black
设置命令出错后提醒的颜色

set -g message-fg white set -g message-bg black set -g message-attr bright

状态条设置

set -g status-left-length 40

set -g status-left "#[fg=green]Session: #S #[fg=yellow]#I #[fg=cyan]#P" 状态栏左侧的长度和文字颜色
set -g status-right "#[fg=cyan]%d %b %R" 右侧
set -g status-utf8 on
set -g status-interval 60 每60秒更新一次显示的时间。默认是15秒
setw -g monitor-activity on

set -g visual-activity on

非当前窗口中有事件发生时（比如一个耗时的命令跑完了），状态栏上会有高亮提醒

Windows下极简的番茄工作法工具——Tomighty

2013-01-04T11:48:00+08:00

这款软件，除了支持修改番茄工作法的各个流程的时间长度和声音提醒外，会在工具栏的右下角通过一个图标显示当前工作流的剩余时间。相比之下，另一款也还不错的focus booster占据的空间就大得多了。

Tomighty:

focus booster:

Tomighty是一个单可执行文件，比很多基于Adobe Air的promodoro应用要小巧玲珑很多。

值得一提的是Tomighty这个项目是开源的，而且跨平台。官网 http://www.tomighty.org

翼图南

fastai 源码浅析 - LayerGroups

总结

Tensorflow 和 PyTorch 如何快速切换使用的 CPU/GPU 设备

Tensorflow

PyTorch

显卡不够云来凑 - 如何选择用于深度学习的云主机

加速 NLTK 数据包 (NLTK Data) 的下载速度的几种方法

利用 Travis CI + Github 给静态博客加上草稿和编辑预览功能

在线预览

REST Client 拾遗

REST Client 不是 url 拼接器

没有充分利用缓存

跨域问题

Finally

用 Travis CI 定制多样化的 Python 测试环境

闲话 Django Raw SQL

Manager.raw

Model ↔ 视图

MATERIALIZED VIEWS

devpi —— 架设私有 pypi 的最佳选择

引言

寻寻觅觅

为什么选择 devpi ?

PyPI 代理镜像

本地缓存

单元测试

系统测试

项目的开发活跃度

devpi 特有的功能

Index 继承

集成 Jenkins

数据导入/导出

replication

Python Packaging 编年史

distutils-sig 工作组成立

disutils 被纳入 Python 标准库

catalog-sig 工作组成立

PEP 241 Metadata for Python Software Packages

PEP 301 Package Index and Metadata for Distutils

PyPI 正式上线

setuptools 发布

virtualenv 发布

pip 发布

distribute

PyPA 成立

Distutils2 的开发被终止

Pycon 2013 - Directions for Packaging

PyPI 有了 CDN 加速

Distribute 项目被 merge 回了 setuptools

pip 成为 Python 3.4 自带的包管理库

在 vagrant shared folder 下运行 python setup.py sdist 会报错的解决方法

A guide to analyzing Python performance

Appscale——Google App Engine的开源克隆/替代

Migrating to a Custom User Model in Django

让django-debug-toolbar支持Python2.5

Letterpress

Django 无法在QuerySet中select_related()一个GenericForeignKey的解决方法

无节操的nude.py识别哔～～～～图评测[NSFW]

为什么在大多数编程语言里，位运算符的优先级(& ^ |)低于比较运算符(== > < !=)

Access klipper clipboard on CLI under KDE4

Chrome Logger

A simple demo for tornado web socket

Crate.io 一个更快，更美，更好的 pypi

Python的双层循环可以这么玩

博客新logo的来历

Google Reader 魂兮归开

找回Android Gmail客户端的删除邮件按钮

"2" < 1 == True

Python 语言中， 不同类型对象之间的比较规则浅析

The ignored decorater

小硬盘伤不起-将Vagrant移出系统盘的方法

更改VirtualBox虚拟机映像文件的位置

更改vagrant配置文件的位置

小内存用户chrome的福音:一键管理所有扩展

Golang Weekly Go语言周报

为 Github for Windows 设置代理

为什么有些网址中使用“utf8=✓”而不是“utf8=true”?

用tmux提高工作效率 配置篇

tmux配置文件的地址

Python 语言中，不同类型对象之间的比较规则浅析

用tmux提高工作效率配置篇