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

按规范做，是一种良好编程实践。
你可以指望你和你们的合作公司互相约好了“当你表面上说'不要'的时候，实际上你说的是'要'”。这时候不按规范是可接受的，沟通成本和开发成本都可控。
但你不能指望 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 的锅最大。。。

cmd 窗口点击黑框区域后获取焦点会导致进程卡住。
我一直没明白这个 bug/feature 的设计意图是什么。

进页展示一个透明 1s 后渐入 100%的动画 loading 。

我在另一个思路上有所感悟。

相比于前端、移动端，盘子小，稍微折腾下就遇到了盘子的天花板。于是多余的心智怎么办？
放在业务领域上，十有八九码农不喜，而且领域之间也缺乏共性缺乏沟通基调，你放了也没法和别人讲。
放在通用知识上，加解密、音视频、算法、安全等等都算，但说实话确实机会确实少。
放在内卷和求新求变上。来了！各种语言各种框架它来了！

而后端，盘子太大，一入后端深似海。抛开毫无探索心智可言的 CRUDboy 不谈，一个后端真的是要深挖的东西太多太多。
后端语言和框架，这是个好的开始。
网络，包括 HTTP 以及其他，任何一个网络话题都可以深挖。扩展开来可以从 DNS 开始到服务器网络性能到传输层链路优化，挖都挖不完。
数据库，CRUDboy 分分钟遇到各种性能墙。尤其是大数据情况下。
常用基础中间件，项目里随手用个三五种不稀奇，都得懂。
容器化、DevOps 、云服务、监控报警，大部分知识都和服务器各个环节有关。
安全，后端的安全要求比前端更高更全面。
性能挖掘，以上每个环节都有性能优化的空间，涉及了从算法到架构从服务配置到奇技淫巧大大小小各种东西。

更别忘了还有那该死的业务领域知识。

以上每个话题的子话题，分分钟埋进去一个专家。

所以自从我从移动端开发转型技术架构以来，每个领域我最多学一种语言，还得按需排优先级排学习深度和广度。

既然我已经学了 Java ，对不起，Kotlin 真的没空了。

买❎，我得付钱
社区版❎，我功能受限
开源❎，我累

学生版✅，享受不该享受的是我，遭受不该遭受的不是我