https://i.imgur.com/GHgi4du.png 目前长这个样子

https://imgur.com/a/jEi4tK1
自己写了一个工具，感觉再完善些可以放出来，目前支持多窗口切换以及快捷键

https://darkof.me/2014/11/23/python-float/
贴一个之前写的博文

找了一些资料显示，先有的 cmd-shift-1 和 cmd-shift-2 ，用来弹出 floppy disk 1 和 floppy disk 2 。
1985 年发布的 Mac System 2 将 cmd-shift-3 设定为桌面截图快捷键。
1997 年发布的 Mac OS 7.6 引入了可以选定区域截图，猜测就是顺着往下轮到了 cmd-shift-4

Ref
[This subreddit is now for discussing keyboard shortcuts]( https://www.reddit.com/r/shortcuts/comments/b818l9/comment/ejvc5g3/?utm_source=share&utm_medium=web2x&context=3)
[Screenshots]( https://apple.fandom.com/wiki/Screenshots)
[Classic Mac OS]( https://en.wikipedia.org/wiki/Classic_Mac_OS#System_1.2C_2.2C_3.2C_and_4)

@nsynet57 newsletter 目前走邮件是方便大家获取的渠道之一（确实国内邮箱使用率不高，但是工程师群体会好一些），我们也有 Telegram Channel 可以订阅。不过微信公众号对内容有一个很大的限制：正文无法支持超链接。这个限制对 newsletter 的阅读体验伤害比较大，推荐的文章与项目，都无法点击查看。我们也会和平台 check 下，支持下 RSS 和微信，不过应该不是微信公众号的形式来做

赞同 @binux 的观点

其实是有可能有的，Python Core Developer Łukasz Langa 最近写的 [Blog]( https://lukasz.langa.pl/5d044f91-49c1-4170-aed1-62b6763e6ad0/) 中记录了 Python 核心开发团队和 nogil 的作者 Sam Gross 沟通的一些内容，其中就有提到
> **Q: Is runtime enabling of nogil a long-term viable option or a transitional feature?**
> Ideally the end game is CPython without the GIL, period. However, there will be an expected long period of community adaptation. We want to avoid a rift similar to the Python 2 to Python 3 transition. Rather, we want the transition to be easier, even if that means stretching it over a longer period of time.

如果未来 nogil 能够 merge 进主干代码里，那么一开始势必会有一个 option 来让用户选择开关 GIL
至于为什么现在没有，其实可以看 Sam Gross 的那个文档，以及上面提到的 Blog ，去掉 GIL 不是简单的直接删掉 GIL 对象，涉及到 GC ，内存分配，以及不少基础库的改造

@littlecowherd
@jaredyam
哇 感谢收听！我们也尝试在播客之外，用文字推荐一些好的内容

可以看下这个 David Beazley 的 [Python Concurrency From the Ground Up]( https://www.youtube.com/watch?v=MCs5OvhV9S4)，跟着写一遍就能理解了

可能大家都没错，只是大家都不太走运。
「在意代码质量，而且有空闲的时间不是去摸鱼，而是重构不漂亮的代码」这是你的个人追求，通过重视标准，来做一些高标准的事情提升你自己的能力与经验，也能帮助公司的项目更好的迭代和更稳定的运行，当你未来有机会做 scope 更大的事情的时候（也许是也许是带人，也许负责某个项目，也许是创业）都会有更好的经验与技术

可能公司评估这个项目投入的成本，未来投入与收益，最后收益不够高所以放弃了。即使是 Google 不也 shutdown 了一堆服务么，关停的原因主要原因肯定不是工程考量，还是产品的目标，收益与成本的考量。

如果这件事情有什么可以提升的话，就是提升自己对产品的 sense ？工作选自己认可并且判断产品有价值的公司，以及再业务开发中通过一些业务 sense 和产品经理做 trade off 来让投入产出比更好

@laike9m 主要矛盾不在 Type Hints 与可维护性上，Golang 的性能带来的低成本是不能拒绝的优势。各种上 C
扩展的组件，Cython 的逻辑，Cache 什么的都上了之后，CPU 成本开销还是很大外加机房受限什么的，选择 Golang 来解决

微服务，调用链分析，服务发现，限流，熔断，负载均衡了解下。
先尝试解耦你的 monolith 项目，如果 monolith 里的各个模块做不好单一职责，微服务照样也设计不好单一职责。
先搞定单一职责，然后根据业务分组部署，快速部署，然后垂直拆分，最后再考虑服务化。

「团队的技术水平不一样」问题，靠修订招人标准来解决，小团队除非是大牛，否则尽量招技术栈接近的人然后在一个技术栈上快速跑起来
「现在的单一系统，修改一个问题，可能会涉及到很多模块的应用，数据库之间的关联性又特别强，有时候修改完后，测试员不够的情况下，没检查仔细，部署上去，就出问题了。」
单一职责解耦，Code Review，自己写测试，灰度发布，蓝绿部署，多靠可具体执行的系统方案来解决问题，不要依靠人来解决稳定性。（测试员是什么鬼。。。。

@Hazgut 方便反馈下您使用的浏览器版本么，我们看下是不是 BadCase

是的。。。他们的爬虫就像 cc 攻击一样，超级烦

好了

在修复中。。。

当年买过一只小白给妹子，没多久就坏了，所以我当然是选择飞利浦。。。。。

@haopic 04 年还没有小米吧。。。

知乎这样也能躺枪，23333
比起你这样等待，google 下可能查到很多资料
https://www.google.co.jp/search?q=%E9%99%A4%E8%8D%89+site:zhihu.com&ei=MVZ0WY1ngsrSBN_NofAI&start=20&sa=N&biw=1080&bih=574