flyingghost

闹开猿节流，降本增笑。

我们上一次的 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

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