我用 Microsoft Remote Desktop ，和 Jump Desktop ，没有发现卡顿。
偶尔卡顿都是网络问题。

@kuanat 不懂就问，包依赖的计算确实是一个无法快的计算，那么有没有人考虑过由中央包管理服务器来做这部分计算结果的缓存？这样在固定条件下，大部分包的使用者就会受益。
我不太会估算这个缓存的存储成本，但感觉查询成本会快于本地计算哎。
谢谢解惑。

@roundgis 有没有一种可能，国内用户绝对数量多，但捐助意愿低，捐助总额低。国外用户占比低，绝对数量也有那么一群，但开源社区文化影响下捐助意愿高，捐助总额叠加汇率因素反而挺高？
我没有数据，我单凭刻板印象瞎掰的，只是觉得你的逻辑推论有漏洞而已。

谢谢分享，收藏了。
其中有一些已经开始用了，例如 沉浸式翻译。
还有一些需要立刻升级，例如 mac 下的有道，作为词典都非常糟糕。
打算尝试一下 Bob 。
另外还在用系统自带的词典（为了三指翻译，需自己加词典），以及 DeepL 客户端，作为补充手段也不错。

闹开猿节流，降本增笑。

我们上一次的 SLA 补偿还没谈呢。。。最近心里慌得厉害。

我解析过一个公司的学习任务。
头尾记录什么的都是常规操作，核心逻辑是每分钟打个点到服务器，记录视频播放状态。
分析到这我就放弃了。打点到服务器，服务器掌控物理时间，用什么作弊判断模型又不知道，试错成本又高。
不如老老实实后台播放时不时瞄一眼。

按规范做，是一种良好编程实践。
你可以指望你和你们的合作公司互相约好了“当你表面上说'不要'的时候，实际上你说的是'要'”。这时候不按规范是可接受的，沟通成本和开发成本都可控。
但你不能指望 github 开放它的 API 的时候和所有的潜在调用者做这样的沟通。于是使用现有共同认可的标准是最经济的做法。

但各种头本身就是一种“协商”机制。包括 content-type 协商，包括缓存协商。
它可以实现为“我期望最好是 xxxxx”，而不是“我要求一定是 xxxxx”。

例如，客户端可以写他请求 text/plain, application/json ，服务端可以实现为我尊重你的选择，尽可能匹配你的需求，如果找不到，fallback 到默认值 json 并返回。
这也为未来“可能”的扩展开放。
例如，昨天客户端说我需要 text/plain, application/xml ，服务端说对不起我只有 json 。
今天服务端进化了，提供了 json 和 xml 两种序列化方法，同样的请求今天就可以按用户需求提供 xml 响应。

至于这样的“扩展”会不会发生，也许这辈子都不会有。但至少它今天既满足了标准拥抱了变化，又满足了你 leader 的要求。

都不知道你要干嘛。。。

https://pythonwheels.com/
What is this list?
This site shows the top 360 most-downloaded packages on PyPI showing which have been uploaded as wheel archives.

反证法：
握手四要素：源 IP 、源端口、目标 IP 、目标端口。
client：什么？目标 IP 是个局域网地址？连不上，卒。
server：什么？源 IP 是个外网 IP ？没有外网出口，卒。

综上，握手是 client-ng 和 ng-server 之间分别进行的。

啊不，S3 的带宽费用。。。用个几天够买一台电脑了吧？

给你开 console 算产品复杂、有维护需求了。
足够简单的产品恨不得定制化完成后就焊死在 ROM 里。

用前端同学写前端。/doge

可以以一些深入人心的象棋词语命名，也不用必须带着“象棋”二字。
楚汉
马后炮、过河卒、双车错
炮八平五，最熟悉的起手式
将军
神机、梅花谱

盲猜，大概是集成了多个应用，每个应用都带了一套自己的运行时框架。/doge

ForkLift 很多年。唯一苦恼的问题只在于怎么把 finder 从程序坞里清出去。

多租户，每进一个体验者分配单独的账号、单独的库、单独的容器、单独的环境等。具体在哪一层隔离看方便程度。

@zhaol #55
我不是说正常程序员应该不出 bug ，我也不是说团队里每个程序员都水平非常高。
但我想在软件工程里，开发测试产品都应该以逻辑严谨思维缜密作为目标，而开发在这一点上应该是最骄傲的才对。
做错了，就是做错了，就是水平不够。每个人有每个人的能力瓶颈，认识自我接受自我也是一种结论。但这不代表我鼓励因此对错误麻木。犯错，至少应该愧疚。

而且 bug 不仅仅和能力有关，还和性格有关（这个比较难改），还和工作方法有关（这个非常容易改进），还和思维方式有关（经过训练也可以改进）。工作方法和思维模式，我觉得也算软技能的一种。
团队里有粗线条的爱钻研的同学，写出 bug 连冒烟都过不了，气得测试叫呱呱。于是后来强调自测，强制给开发设底线，同时尽量让该同学做技术调研，少写业务代码。
有细腻的妹子，技术很一般，就 CRUD girl ，但真的很少 bug 。这大概归功于性格，很难学。
还有个奇葩男子，水平中上，产出率中，特技是不管写什么代码，永远零 bug 。月度总结报表里永远是零，偶尔才出个位数 bug 。。。后来他的工作方法和思考模式总结出来全组推广，都学学，都提升提升软技能。

谁说写 bug 就合理就不值得努力提高水平？

1 ，测试测 bug 是本职工作。能被测试测出 bug 的开发，只能说活该水平不够。
2 ，开发应该带着感恩的心。我司线上生产事故测试必背大锅，比开发比例还大。测试是开发的守门员，没有测试，那只好开发自己背锅。让开发自己选。
3 ，需求层面打不过测试的，只能说开发不熟悉业务。开发天然是既了解业务又洞悉本质的岗位，正常公司是产品引导、测试守门，但没有任何人能在宏观或微观层面打得过开发。
4 ，如果由于理解偏差导致的“bug”，请修改项目组 bug 定义和分类。开发常见几种觉得委屈的需求 bug：
一种是讲的不够细，每个人有每个人的理解方式。大锅扣给产品，请描述好需求。开发的责任在于：讲得不够细就多问，又闷又自作聪明的开发太多，又谨慎又多嘴好问的开发太少。
另一种是开发犯了一些常识性的错误。例如产品说这里要有个密码框，开发直接文本框明文显示了，测试认为应该掩码不能明示。如果一个 bug 是公认的常识，那不理解常识的一般是经验不足，请补。
5 ，开发不私接小需求。小需求、小变更要同步，大变更要重走完整流程。这个也是很常见的委屈“bug”来源。
6 ，某些测试可以担当 QA 角色，对于设计、体验、技术方案都能提出见解。挺合理。团队就应该人人可发言，只要有道理，即可采纳。人家水平高啊。但在一些 UI/UX 、运营等非技术角度，开发缺位是常态。太钻技术了，太少抬头看宏观。我是期望团队内所有人都应该专精本职工作的基础上具有一定跨界能力，尤其产品本身的理解，和用户角度的理解。这方面产品容易缺的是技术理解，开发容易缺的是产品思路，反而测试较容易做到期望的“一专多能”。

总之，综合来说，开发真的是天然最强势角色，至少是最容易达到。被打压出普遍委屈和不满，只能说明。。。项目经理 /团队 Leader 的锅最大。。。