说那么多，犹豫就是想买，我建议都买了

其实很多事连 kotlin 都没听过的，也就今天看到全世界都在谈论 kotlin，百度一下就说 Java 已死，kotlin 永生。我是认为啊，只要 Java 一天跟 JVM 密不可分，那么 Java 就不会死。google 推 kotlin 压根就是为了跟 oracle 谈价钱，你信不信 oracle 开价 5 亿，Google 就给钱了？
说 Java 已死的，Google 是不是已经将内部的 Java 语言换成了 Kotlin ？不是的话你敢信 Java 已死？

这个怎么给你简历啊？

前后端分离跟 session 有什么关系？看看京东，前端也很好啊，session 也做得很好，登陆页面还要搞 token?OAuth2 ？登陆页面用平常的登陆->后端校验->建立 session->设置 cookie，并返回服务端渲染页面一套流程是最好的了，其他页面的话，你问你们组长就可以了。不知道你们团队的情况，无法给出合理的建议。

@mokeyjay 讲道理，外卖一顿有菜有肉，就是油多了点。外卖也是包括全部人体所需的营养。本来这个就是一个伪命题，快餐店的营养不可能不够，当然你偏要说只吃 5 块那当我没说。
不过你的确可以试一套，反正也就几百块吧，当出去吃一顿好的罗，虽然这大厨烂爆了。

钱多没关系。你说当早午饭，我更建议你先去买一桶蛋白粉，当零食，一天就一顿。你能坚持蛋白粉，大概坚持那代餐也是可以的。
那代餐一点脂肪都没有，没有口感，没有香味，糊状。这样的东西能好吃到哪里去？时间真的能省很多吗？还不如去楼下买一顿吃，只是那营养只可能更好，不可能更坏。

@zhy0216 然而大家使用的 mysql 并没有 CTE

@panda1001 找运维，叫他们编译打一个包上去

@NaVient 按你说的 xx 那个用 @app.task 装饰的函数是需要在其他机器部署的。

@julyclyde 上面说错了， requests 是根据 http 头部的 Content-Encoding 或者 Transfer-Encoding 来决定是否启用 gzip 。但是楼主现在不是这个情况，他是发送请求给服务器，服务器不支持 gzip 压缩，但是 requests 发出 POST 请求的时候却会自动启用 gzip 。

@julyclyde http 头部中的 Accept-Encoding 不带 gzip

@julyclyde 楼上几位都没有错，你理解错了。客户端就是在这里就是指 requests 这个库， http 报文没有说用 gzip 那么 requests 就不会用 gzip 解压，会使用原始报文。上面几楼解释得相当浅白了。
至于 post 不接受 gzip, 此为一个解决方法可以参考 https://github.com/kennethreitz/requests/issues/1753

后端打好基础看 paper 吧， paper 营养大着呢，你看 google 三篇分布式论文就可以搞出一个大数据生态圈，最近一批 google manglev 又提供负载均衡的新思路。每看一篇论文都实现一次，还不碉堡啊？

纵观各家的解决方案，我认为还是硬件狗最实际，而且最好是要求客户签 EULA ， EULA 里面写明不允许逆向否则走法律途径。

@nlimpid 看了知乎专栏，专栏作者也是说入门了可以不买了，现在的话我觉得 Python 的书要不是解析器源码分析，要不是脑洞打开的设计思路，其他的基本或多或少自己都用过，标准库的文档也看得差不多。大概也是复习一次罢了了。__slots__这东西我第一次看到的时候是在 http://lucumr.pocoo.org/2014/8/16/the-python-i-would-like-to-see/这里看到的。主要是觉得就是这样的东西太多了，又不纳入语言标准。记得 PyPy 也是因为要模拟这个特性而速度会变慢，我个人是觉得能不用就尽量不用，甚至我觉得如果我要写 C 扩展的话，我都会尽量使用 cffi 。

自从工作之后，代码看多了，我都觉得很多东西都没什么。比如我们生产环境就有自己实现的模块热更新，使用了 Python 的动态特性，诠释何为 metaprogramming 。感觉要多了解 Python 还是得自己多动手啊。

有没有人能给我说一下《 Fluent Python 》的优点，因为现在知乎上面都是爬虫教程，没见到有人推荐这书。不过看了一下目录，感觉还是有点东西

外币多的请使用中行，中行是专门负责外汇业务的，它家的汇率也是比较好的，而且 4 大行之一，还是很可以的。

@neoblackcap 这是因为本身 CPython 代码质量高，二来 C API 暴露的底层细节太多了，很多东西都得在 runtime 时候才能知道，没法优化，知乎上面的 R 大曾经发过多篇文章说这方面。

然后就是 GC 的问题了，既然 tracing GC 能回收垃圾，那么为什么还要用引用计数？要知道引用计数其实是将每次回收的成本摊分，有人做过比较，除非是内存很紧张，否则朴素 mark-swap 的效率都比引用计数好。毕竟在两个回收周期里面不管 heap 上的对象怎么变化， GC 只管开头结果两个状态。还有就是这个 GC 由引起 GIL 的问题，如果不是引用计数的话， GIL 压根可以不存在，多线程提高多核利用率也可以做。而且社区还是很抵制这些改变，这也是一个问题。 Pycon 2016 US 就有人做演讲在做移除 GIL 的事情， Guido 对他的工作要求是，移除是可以的，但是不要降低单进程下的效率。真是要求很高啊。