不是特定语言的死忠，不想加入混战，不过还是想说一句，语言本身也是有优劣的。
比如我就认为
Swift 就比 Objective-C 要优秀很多。
Python 比 Perl 要优秀很多。
Rust 应当会比 C++优秀很多（这个没有真正用过，所以是应当）。

拒绝承认开发语言的优劣就是拒绝承认技术的进步。

@chaleaoch
对 1s 很正常，和 ORM 没关系。
如果有 100w 条数据，你 list(qs)就不是慢的问题，内存会直接爆掉。
你执行 SQL ，实际上只是拿到一个游标，并没有立即将所有数据全部取出来。
你的 list(qs)实际上是一次性将数据全部取出丢到 list 里，不慢才怪。

@chaleaoch
你可以再测试一下，<model>.objects.all().values() 绝对花不了 1 秒。
Django 的 QuerySet 是 Lazy 的，只有在你用的时候才会发生查询。
单纯执行上面的语句不会执行 SQL 。
如果你的写法是
>>> qs = <model>.objects.all().values()
>>> list(qs)
超过 1s 是很正常的，因为你要把所有数据一次性取出来。你可以用调试工具看一下，生成的 SQL 就是`select * from <table name>`，查询速度本身是非常快的，但单 2w 条数据，别的不说，单网络传输都要费不少时间。

使用 Django 的 ORM ，如果慢的不正常，用调试工具看一下生成的 SQL ，通常都可以解决。所谓必须写 SQL 的地方极少。注：
- 部分复杂报表，查询速度慢，用 ORM 性能优化有些难做。
- 需要用到数据库专有特性， Django 不支持，需要用 extra 内嵌少量 SQL 。

没用过 SQLAlchemy ，不是很了解。
很早之前简单的了解过 SQLAlchemy ，从 API 的友好度上看 Django 的 ORM 比 SQLAlchemy 好很多（个人看法）。
Django 的 ORM 调优其实并不是很难，很多时候慢是因为用的不对（糟糕的 SQL 一样慢）。
当然，在极少数情况下还是会出现 ORM 无能为力的情况，这时候可以直接写 SQL 。 ORM 和 SQL 并不冲突。为了这 0.x%的情况而放弃使用 ORM 很没必要。
@chaleaoch
1. Django 的查询可以嵌入 SQL ，也可以把自己手写的 SQL 绑定到对象上。
不知道你遇到的具体情况是怎么样的，不过在我看来第一条应当是可以实现。
2. 有些表连接写出来是子查询，这个需要结合具体案例，不是很确定是否是写法问题。
3. 2w 条数据查询用时 3 秒，这个非常不正常，需要结合具体代码进行分析。从我主观角度看是代码写的有问题。

首先保证自己该拿的拿到手。年终奖拿到前别提，离职必然是影响年终奖的。
如果是钱的问题，可以谈谈。
如果不是钱的问题，拿到该拿的就提了吧。
换个角度说，既然决定要走，早点提出来对大家都好。

事实证明还真是我想多了。
今天 10 点 40 分的时候刷出一大堆的票，立马用手机登陆进去，连个票的影子都没看到。
应当是全自动抢票软件太多，出票后第一时间就全部买走了。

从生态环境上来看 Vue 同 React 差的还是有点远

手机里有部分空气。热胀冷缩，等里面温度降下来了，应当会有进水的潜在风险吧。

3M 的眼镜布非常好用，其他的眼镜布都无法擦掉油光。

不挂 VPN 经常同步不了。
如果不考虑墙的问题，挺好用的。
将照片都传到服务器上，本地只保留缩略图，绝对是小容量 iPhone 的救星。
即使大容量的 iPhone ，考虑到手机意外丢失等情况，买个 iCloud 也是很有必要的。

不知道 “抽象类” 这个名字从哪里听来的，似乎没听过这个叫法，而且这个叫法不但不形象还很误导。
metaclass 有点黑魔法的味道，知道 metaclass 做什么的，能看到 metaclass 的代码就可以。实际应用中自己写 metaclass 实现的机会非常少（你可以简单的认为用不到）。

metaclass 简单的说就是以一个类为模板，生成一个全新的类。
实在想详细了解还是老老实实的看文档
http://stackoverflow.com/questions/100003/what-is-a-metaclass-in-python

前一段时间对接携程的商旅接口。
感觉完全不像一个大公司提供的接口。
接口的一致性很糟糕，文档也不怎么样。

有钱才有动力做出更好的东西，不过还是觉得有点小贵。
BBC Leaning English 一些 podcast 也还不错。
我挺喜欢 BBC 的 Dramma ，就是经常不更新然后放老的 podcast 。

@leotso 并不是自动转完就可以一遍过的，很多地方还是需要自己做些调整的。
就新项目而言，真没啥必要继续用 py2 了。
如果你用到的哪个库不支持 python3 ，很可能是有了新的替代品。

看来以后的项目都得优先支持 python3 了。

从 2 迁移到 3 的工作量其实还好。
只是如果之前测试用例写的不完整，测试是个麻烦事。
另外一些项目代码量已经很大了也是头痛。

要从 SVN 迁移到 Git 肯定会有很大的阻力大。
建议先把系统搭起来，然后在小范围内推，让大家看到 Git 的好处。
除非你是领导，有能力强推，不然别想了。
人都是有惰性的。

http://www.discourse.org/
Stack Overflow 的联合创始人的项目