相信在同一机器上部署多个应用并不是什么罕见的需求，特别是像我这样很小的个人网站来说更是如此。但在我部署子站的时候发现一个问题，那就是 Github 并不允许多个仓库使用相同的 Deploy Key。如果你尝试这样做的话，会得到如下提示：

但我又需要 Deploy Key 来简化项目的部署，其他方式（包括每次更新时手工输入，或者用明文记录 Github 登录信息）都是不可接受的。那应该怎么办呢？稍加检索，找到了如下的方法，记此备考。

CSV 这么简单的格式，需要单独一篇文章来说明吗？其实细节隐藏在魔鬼之中，我们过去的团队在生成 CSV 内容的时候，由于兼容性问题也是吃过苦头的。因此，我觉得还是有必要写一篇文章，从各个方面把这个格式彻底讲透。

本文将介绍：

• CSV 格式的来源、历史背景和规范化情况；
• 规范化的 CSV 格式要求与实际支持情况；
• Python 内置库与第三方库处理 CSV 的接口与细节；
• 处理 CSV 格式应该注意的常见问题和注意事项。

Flask 框架提供了蓝图（Blueprint）的概念，作为划分大型网站的主要工具。但对于地址较为复杂的网站，仅靠 Blueprint 仍然是不够的。以个人博客为例，如果我们把它规划为个人网站的一个子分区，那么很自然地会设置一个 url_prefix='/blog' 的蓝图。但 blog 下面可能不只是一个简单的平面结构，还会有更多的层次，类似这样：

• /blog/post/
• /blog/post//edit
• /blog/post//comments
• /blog/category
• /blog/category/
• ...

当然，我们仍然可以逐项在路由中添加必要的前缀，但是这样显然违反了 DIY 原则。有没有办法将 Blueprint 再进行细分呢？

概述

信号（Signal）是 Flask 中一个比较鲜为人知的功能，在官方文档中也对此着墨不多。的确，Signal 并不是 Flask 的核心功能————你完全可以在不使用 Signal 的前提下写出完整的 Flask 应用。但在某些场景下，使用 Signal 有助于避免代码中不必要的耦合，提高可维护性；并且，部分工程化实践，比如针对特定逻辑进行的测试，需要借助 Signal 的帮助才能完成（后面我们会看到一个具体的例子）。因此，本文将帮助你了解什么是 Signal，它的原理、使用方法，以及它在 Flask 中有哪些实际应用。

这两天用闲暇时间写了一个小工具：Tidy Explorer，其实就是控制资源管理器上边那一排快捷方式的显示或隐藏。这些东西对我来说是根本用不着的，特别是那个 3D 对象，而 Win10 却固执地把它们设置成默认视图，相当讨厌。

我们都知道，测试是有层次的。一般来说，测试的组织应该形成类似下图那样金字塔型的结构：在底层有数量很大、短小而快速的单元测试，在开发过程中提供实时反馈；中间层是集成测试，验证各个组件组合在一起是否正常工作；再往上则有所分化，依照不同的侧重点与表现形式、有系统测试、UI 测试、用户验收测试（UAT）、接口测试、端到端测试等多种不同的称呼。从自底向上的角度看，它们应该在数量上逐层递减，但测试覆盖的范围则更大（相应的执行速度也会变慢），在损失代码局部细节的同时，也获得了更广泛的全局视角。

前言：本文是 James O Coplien 的文章《为什么大多数单元测试是浪费》第二部分的中文翻译。原文地址：Segue。关于该翻译的介绍与背景，请参考 索引 部分。对于其中部分可能不太容易理解的地方，我尝试自己加入一些说明，您可以参考最后部分的脚注。

前言：本文是 James O Coplien 的文章《为什么大多数单元测试是浪费》第一部分的中文翻译，原文地址: Why Most Unit Testing is Waste。关于该翻译的介绍与背景，请参考 索引 部分。对于其中部分可能不太容易理解的地方，我尝试自己加入一些说明，您可以参考最后部分的脚注。

TDD （测试驱动开发）是敏捷开发、特别是极限编程（XP）的核心实践之一，也是我长期以来一直坚持采用的方法。因此，当我最近偶然从一个链接发现这篇文章时，它带给我的震动是可想而知的。虽然在之前我也模糊地感觉到单元测试可能存在的一些问题，但一直相信是自己水平不够、认识有限的原因，没有更深入地思考过。也曾听说过 DHH（Ruby on Rails 框架的作者）对 TDD 的反对意见，但也只是想那可能是 RoR 框架本身的局限，不一定是广泛适用的结论。

最近，Go 语言社区一件让人比较挫败的事情是，为了简化错误处理而提出的 try 提案，几经变更，又经过社区的反复讨论，最后还是黄了。关于该问题的一些讨论线索可以在 Github 专题讨论页面 Proposal: A built-in Go error check function, "try" #32437 上看到。

一个语法提案没有通过本来在开源社区不算什么大事，本来通过民主讨论决定语言的发展方向，也是集思广益的正常之举。但我以为在这个问题之后，折射出 Go 语言本身、以及社区目前存在的一些问题，这还是值得玩味的。