该讲逻辑的场合不要讲感情，例如技术和项目。
该讲感情的时候不要讲逻辑，例如哄老婆生气。

给他指定一个特殊的 shell 吧。。。

你就先说你有什么是可信的吧。。。
然后回帖们才或许能帮你设计出一条可信信道来。例如#9 的 @hefish 同学。
人家真没开玩笑，毕竟你 AB 都不可信了，一切常见的工具、算法、证书、设备都不能用，只能关机下线了。

https 只保护传输不被监听、窃取、篡改。
也就是客户端和服务器之间不会蹲有一个未知的“中间人”。
但客户端本身就是一个攻击面。如果客户端不安全，相当于一个逆向工程师蹲在浏览器里，所有输入、输出、渲染过程、前端交互逻辑、渲染数据都失密。
好在以上大部分都不怎么值钱，值钱的都服务端计算/渲染了。
唯一值钱的是当前账号个人数据，系统风险可控，法律风险更好甩，反倒是防护成本巨高效果不好，就这样吧。

@yulon 我不认为是浪费时间。
一来他爱玩，这是前提。
二来编程也只是众多逻辑思维和开放性思维并重的头脑锻炼方式之一，既然想锻炼这方面，选编程和选下棋和选桌游和选破案故事都是大同小异殊途同归。事实上我们也都选了都在玩。
打个比方，带他去打篮球，7 号的小球，动作也做不到正规，走步那是家常便饭，但也不等于说“长大了好好学正经打篮球就行了，小时候瞎打反而浪费时间”。运动的目的达到了，玩的目的也达到了，竞技对抗的意识也成长了，就是好活动，专不专业倒是其次了。
也许长大再也对篮球没兴趣，7 岁就是巅峰也没关系。也许长大吃了这碗饭，再学就是了。

@stimw 不是，怎么上来就身边统计学呢。每天 4 点半放学，周末两天，你觉得安排点啥？
要么自己带着玩，要么让他去尝试各种班，要么。。。放羊？
我从孩子很小就开始让他尝试各种方向了，有的没兴趣就弃，弃了三四个了。有的有兴趣就玩，摆你这就“必须会”，就“养宝可梦”？
人生并不止学校+放羊吧？学习我也不限制，他有兴趣学的我都教，数学我敢教到五年级；他没兴趣的我都不教，跟着学校进度走就可以了；他学不动的我也不教，正儿八经的游戏编程等再大点吧；他有兴趣我和妈妈两个理工宅又不会的就扔出去，外面班那么多每天玩十个都玩不过来。

如果不折腾点好玩的，人生还有什么乐趣？

@markgor 喜欢。孩子已经在畅想长大要做游戏设计师了。我只能在他适合的时间范围内带他多体验几个游戏，多玩玩几个智力型逻辑型的桌游。家里有一柜子桌游，寒假玩了一半，哪都没去天天窝家宅着了。

楼上都活在真空里吗？
现在城市里的小朋友编个程就太正常了。我家菜小都有编程相关的课外活动小组。
别说现在，就 20 多年前我小时候，我都清晰记得《电脑爱好者》上刊载的一个北京初中生写的系列《你好，游戏世界》对我的冲击。
我家娃现在一年级，学习乐高编程，钢琴，唱歌，街舞，击剑（上完退学了），篮球（暂时上完了），轮滑（下学期开始）。
睡觉时间也没觉得变少。

编程接触过乐高编程，和 codecombat 里的一点点 python 。
语言选择来说，各年龄段各领域可选项太多，凹语言我可能不太会选，但我并不排斥其他人选择任何语言，更不排斥孩子学编程。
怎么一上来就霍霍儿童呢。。。

想当年 google 被逼出中国的时候，也是这样逐步劣化的。
让很多人误以为不是网络问题，是这家服务不行。
gayhub 不顺畅已经好几年了。

所以 internet 服务挂梯子是默认态度。

"一段需要保存的文本"

我发现一段文本用变量来存比用磁盘来存快上万倍哎！

我用 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 的要求。