coverage + diff_cover 解决不了你的问题？
coverage 生成全量覆盖率报告 xml 文件，

coverage run --source=. manage.py runserver --noreload
coverage xml

然后 diff-cover 是能够生成增量覆盖率

diff-cover coverage.xml --html-report report.html

看了下 HTTPX，确实在异步这块做了不少改进

女儿刚上小学，迎来第一个教师节，帮她在想祝福语的时候，想起了他。小学三年级的时候，班主任叫张德全，有一次放学回家看我一人，就顺路用 28 大车载了我一段。中间的一段对话印象深刻：老师问我为什么不转学去更好的学校。当时我沉默不语，那个时候也没太多想法。后来老师说 “是金子总会发光”，意思是告诫我既然选择了，努力朝目标往前赶就是了，哪怕当前环境不是那么好，但是付出终会有回报。多年后看，虽然自己只是一粒沙，但是那个场景却一直在激励着自己。他就像那夜空中的北斗星，迷茫时指引着我的方向。衷心祝愿曾经给予教诲的老师和朋友们，节日快乐！

有些三分屏的意思了

按 docker 的最佳实践，一般是不推荐把 mysql 也做到镜像里面的，尤其是线上系统。国内有很多社区比如 dockerone.io。获取镜像通常有两种方式：通过 docker hub 等获取，一般开源项目的官方都在里面有维护镜像。另外一个是自制：比如通过 dockerfile 来生成，如果觉得学习成本，也是支持手工 commit 的。

没赶上，来 down 份 PPT 看看

docker 最早是基于 linux 的 LXC 实现的，0.9 以后是 libcontainer。

打卡

3 楼说的 nmon 重点推荐，但是 nmon 原来内存那块数据是有 bug，好久不用了，不知道最新版本是不是修复。推荐几个简单的命令吧，nmon 都省了，比如 vmstat、iostat、netstat、sar、top 这些都可以，简单压测基本就够了。

如果想全面些，建议从以下几个方面着手准备：

1. 校验数据库表结构的变化，默认填充，约束等等；
2. 有些主外键，建表及插数据可能需要前后关系；
3. 考虑一些映射，尤其是分表的情况；
4. 查看各字段转换是否正确，尤其重要，比如长度或精度，字符运算、空值判断、日期转化、字符集；
5. 不同数据库的 SQL 标准差异，比如聚集运算等等，可能涉及到代码的修改；

迁移过程也比较重要：

1. 是否停服，数据怎么截断并验证是否都迁移了；
2. 对一些特殊语言的主键要关注，比如 python 的 django 默认是分配一个 id 做主键的；
3. 要做大数据量的测试；全量数据测试；

建议写个迁移的方案。另外个人认为 1 是要业务覆盖上要尽可能全，二是前移后的数据完整性，这个跟迁移规则有重大关系。