R.I.P 救救乌干达的孩子们。

git + [mark][] + confluence

mark: https://github.com/kovetskiy/mark

看搏增量还是存量

@xiyiailoli 你好，校招已结束，不再接受新的申请

少碳水，多蛋白。调节一下饮食结构试试。

同意部分观点。
雪地效果太棒了。
Boss 设计太顶了，我觉得这就是非常好的文化输出。
故事偏向于西游新解，挺好奇游戏科学如何解读的。
受身无论是敌人还是主角自己，都略显僵硬。作为对比战神的受身动画会随着进攻方式不同而不同。当然这个也需要大量时间调校。

作为玩家始终是兴奋的，能够有这样一款带着我们自己文化烙印的作品，我会持续关注并耐心等待。

加油，我认识的朋友也有过类似的经历，不过是灯塔国。大龄+低学历+网络慕课，然后报考学校就读。她的经历让我相信世上真的无难事，只是需要付出等额的努力。

想到啥说啥
DevOPS 或者 SRE 之类，我统称非产品功能需求开发，做质量、敏捷响应等等。在这个定义下，哪怕你写一行重复执行的 shell 都可以算作 DevOPS （地铁_老人_手机.jpg ）
DevOPS 越推崇的公司，越以员工数量少却维护海量集群为荣，鄙司收购的一个小公司的运维团队之前就两个人，对应后来我们直接拆成五六人的工作量，戏称之为 Dev & OPSize，再发展一段时间，估计这两个词会完全拆分。所以人少和是否贯彻 DevOPS 没有必然联系
使用项目管理工具是否就是 DevOPS ？工程效能是一个更大的话题，DevOPS 只是其中的开发环节一个方法论。虽然 Jira 母公司 Atlassian 一直标榜使用了自家产品的公司“很”有可能是敏捷的，自动化的和高效的，但每家使用问题追踪的公司不一定会上市。Atlassian 股价自 2015 年上市以来，兑现了几乎十倍的回报率，每家公司依旧要么在使用 Jira，或者即将使用 Jira 的路上。
Thoughtworks 的 Tech Radar 很实用的记录了哪些技术是“未被验证的”，https://www.thoughtworks.com/cn/radar/techniques/devops DevOps 2010 年很新颖，2012 年已经是成熟的被采纳的技术

@song135711 就是你搜到的，因为资源往往不是无限的，所有的方案都会考虑一个实际投入产出比。

可行，问题是从哪里开始，由 Golang serve HTTP listen 还是 Python?
如果是前者可以考虑 Python embedded Golang 的实现，参考 https://github.com/a-tal/httpy
如果是后者，可以在标准的 Python Webservice 之后将 request/response 的 fd 转给 golang 参考 https://github.com/vladimirvivien/go-cshared-examples

但是无论如何，就你提到的都是 IO 密集型任务，最终都会被转嫁成为 IO 更密集型任务。
你这个问题背后可能是对于 GIL 的不满，或者是觉得 Complied language 的灵活度的抱怨。这些都可以拆分成更细的领域去解决。当然直接混合两个运行时环境除了 ROI 不高，也没有什么问题。

先用 `variable is None` 判断。`dict.get` default 填 None 是坑。Python2 不同类型比较按照类型名称字符大小比较，'i'nt 总是小于 'S'tr 。其中 `None` 是最小的类型，比任何类型都小。

https://stackoverflow.com/questions/8961005/comparing-none-with-built-in-types-using-arithmetic-operators

branching 是为了比对、合并。部署环境属于一种配置，应该是放到同一 branch 。

https://softwareengineering.stackexchange.com/questions/186889/why-was-python-written-with-the-gil

> Benefits of the GIL
> - Increased speed of single-threaded programs.
> - Easy integration of C libraries that usually are not thread-safe.
> ... This lock(GIL) is necessary mainly because CPython's memory management is not thread-safe.

triple kill

永远不缺李逵李鬼
github.com/utfave/cli ⚠️
github.com/urfave/cli

github.com/siruspen/logrus ⚠️
github.com/sirupsen/logrus/

其中 github.com/urfave/cli 会采集信息并发送到某云，并且存在后门的可能。我想看看怎么实现的后门，可惜已经被删除。刚想利用社工通过 https://sourcegraph.com/github.com/utfave/cli 看看缓存数据，第一次还能看到提交历史，一刷新，就 not found ……

挺好的。作为沉默的大多数，我不会因为诱导分享而举报。但是数量一旦泛滥，我就会丧失继续留在这检索有价值的信息的耐心。