这样有一个问题，你把每个方法都返回整个对象正常情况下是很畅快的。
但是遇到一些特殊的验证，比如我需要对返回的 body 做一定的处理再进行 equals 的断言，这样就需要一个中间变量来转移。
或者你再增加一种 assert 的方法。
使用中间变量会打破你这种链式的书写方式，让代码变得非常凌乱。增加一种 assert 到后期你会有巨多的 assert 方法，语法提示选择的时候也是很灾难的。
另外，为了维持这种链式对象，你每个方法返回都受到了限制，扩展起来是不可能的。
就等同于一个 json 对象。

没有动手的人永远在找缺点，你说它无厘头也好，骗骗没动手的人总是能有奇效，并且引发舆论也有独树一帜的快感。
真真实实动手完成了的人，又确实解决了团队的诸多问题，可能不完美，但是全方位收获颇多。
回头看看那些打嘴炮的人，还是保持安静偷偷发育比较好。

您是说您不知道用例怎么写还是不知道平台用例模块怎么设计？

月经贴
围观 Python Java 之争

'on_delete'只能加载外键（ForeignKey）的 model 上面，其他 model 字段不要乱加

django2.0 开始，需要对所有外键 models 添加 on_delete 的参数，已确保当该 model 删除时其关联的外键如何处理。
你使用的 xadmin 版本应该是 django1.0+ 的，所以你需要检索对其 model 层中所有外键是否添加了这个参数。

那个 USB Hub 卖吗，我想给我的 mac 搞一个

都可以，看你们小组熟悉哪块技术栈，性能测试做到最后肯定会向服务靠拢。
单独的一个工具 jmeter 和 locust 相差不大，搭服务那就要考虑本身语言熟悉程度，web 框架的熟悉程度，这里有一个学习成本问题。

python3.4 后已经引入了 asyncio 协程，3.5 引入了 Async/Await 语法糖
某些大牛在几年前就说了 Async/Await 是最完美的异步编程解决方案
Locust 性能框架底层用的也是 asyncio，我觉得 Python 应该不成问题
进程还是算了，进程通信是灾难的

概率对于个人来说都是没有意义的，特别是深圳上海人口基数这么大的城市
奔着全额公积金，专业化团队去的话，深圳肯定有不让你失望的公司，并且我个人来看，这两点并不是大痛点
即便在公积金上并不能让能满意，你也可以通过其他福利进行权衡，面试终究是博弈后罢了
这个问题应该是公司为单位，而不是城市为单位的

个人发展置于一个城市更加是一个伪命题了

户口的话深圳确实很简单，不影响你小孩升学和买房
如果你是考虑买房投资的话，深圳户口容易进入并不影响其房价的飙升

提一下，py3 建议用 f''

居然是软件测试专业的

噢，所以 appium-espresso-driver 是可以访问 Android 的内部的是么？

根据您的思路我现在找到的方法是，创建一个 WebChromeClient 的实例，或许已经被创建，这个我不清楚
WebChromeClient 有一个 onConsoleMessage 的回调 api 提供给我，获取到控制台输出以后再通过 webview 传回给 appium？或者直接重写 onConsoleMessage 的时候把日志输出到文件？

先邀 appium 大佬
@cmlanche-github

不是说学习一门知识的最有效方法就是，重复清晰的教给别人吗？其实很多基础的东西可以利用这个机会巩固一次，哈哈。

哪个重要不重要，重要的是在别人眼里不能有短板罢了。

感觉自己真的见识少，这个居然能出一本书

何不利用 “大不了离职” 的心态，好好锻炼一下自己的沟通能力。其实只要工作有掌控感以后，很多计划都能遂自己愿的。

Python model？django 吧
django 不会实际在数据库中设置 on_delete 的值，在你删除一个引用对象的时候，django 回去模拟 on_delete 的行为。
django 其实也不推荐你直接使用 sql 去操作数据库，已经提供了完备的 filter 等函数，如果你非要这样的话，自己写一个批量脚本吧。

django 文档原文：https://docs.djangoproject.com/en/1.9/ref/models/fields/#django.db.models.ForeignKey.on_delete
ForeignKey.on_delete¶
When an object referenced by a ForeignKey is deleted, Django will emulate the behavior of the SQL constraint specified by the on_delete argument.

做啥事不都是唯手熟尔么
入门难，进阶难，理解难，实操难
全方位的壁垒也侧面的证明这件事情值得去做
但是现在这种壁垒已经逐步降低了

很简单的问题，人家的设计就是在 teardown 周期阶段的时候生成报告，猜测是因为生成结果需要依赖到一些 teardown 阶段的参数，例如时间统计等。
解决无非两个方向
一是魔改 allure，在你指定的生命周期内生成不完整的报告。
二就是自己生成 json 文件，其实获得了 module 对象就能够自己生成一个 allure 的 json 文件了。

嵌套装饰器在使用的时候调用顺序很容易混乱，很少会使用到

6.4

6 月不要科学上网

是否开了代理