如果真是抱着 大家都应该按照某人设想中的最优解去做事 的想法, 那么可能就是人民公社的初衷了. 我们都做好, 然后一起努力, 建设好公社, 大家都更好.

但事实证明, 那行不通.

我不知道为什么你们认为抖音快手不好, 我只是没有那么多时间了. 如果在有限的时间内进行选择, 我觉得 B 站的无广告我更喜欢. 我觉得玩儿 PS5 更开心.

同样是社区工作人员, 有的人选择这样, 有的人选择那样. 作为工作人员, 符合了上级的要求, 剩下的无可厚非. 但作为路人, 如果自己上下班路上的雪被优先处理, 会觉得更好. 我这样自私吗? 是, 但我也不觉得我错太多. 自私是人的天性, 所有人在一定约束下自私, 社会就稳定发展.

人和人, 差别是挺大的. 我就描述一下, 但有些人就会认为, 这是在差评.

---

不过, 工作中我会更加喜欢做得更好的人. 谁会喜欢更差的代码呢?

君子爱财, 取之有道.

@lexa 现在是没有做评论隐私保护的, 可以看到 @lexa 现在的所有评论都是在 "捧" Agile Query, 而没有参加任何社区的其他讨论. 因此, 我认为 @lexa 是一名水军或小号.

我认为这是一种错误的营销方式.

刚签发 Let's Encrypt DV 证书, 显示 ocsp_url 为 http://r3.o.lencr.org.

通过 nslookup r3.o.lencr.org 223.5.5.5 查看 IPv4 是 23.44.51.35 和 23.44.51.8.

以 23.44.51.35 为例, IP 归属为东京. ping 的结果也的确是东京 1ms 左右. 国内访问延迟大多 100ms 以内, 个别会到 200ms.

@bequt 之前在飞书开发者互助群问过, 也问过销售, 说暂时没有计划. 按照飞书那种收费标准, 已经按人头 (相当于按需了), 再 API 调用收费就不应该了吧.

钉钉这样按照 API 收费是因为无论人多人少一口价, 所以各项细分功能 (API 调用) 再额外收费.

而企业微信的收费策略是外部联系人, 也算是另一种 "按人头" 了. 是根据自身特点 (微信融合) 给的定价策略.

https://open.dingtalk.com/document/orgapp/webhook-stream-free-to-commercialization-announcement

收费的: 专业版 5 万次/自然月.

大概每天不超过 1700. 如果算上自定义机器人, 就比较抓襟见肘了. 我们在不同项目, 不同目的上用了各种消息机器人, 只算机器人, 每天 200 到 1000 条左右.

解决办法是购买应用开发与酷化增购包, 19800 元/年. 对于普通公司来说, 应该基本满足需求.

---

不是钉钉股东, 不需要给钉钉出主意. 但作为用户 (尤其是人数少的公司), 可以了解下竞品, 企业微信和飞书还未开始对 API 调用等收费.

@levelworm https://www.businessinsider.com/anna-brockman-cried-asked-ilya-sutskever-change-openai-report-2023-11

最近我们在用其他库的时候也有关于 z-index 的问题. 一会儿默认 1000, 一会儿固化 1050.

如果那个库 "提供了 z-index 的 prop 和 css 变量" 该有多好.

官方说法 ( https://support.apple.com/kb/SP898?viewlocale=zh_CN&locale=zh_CN):

1. 150 GB/s, M3 Pro
2. 300 GB/s, M3 Max 16 核
3. 400 GB/s, M3 Max 14 核

@kokutou 主要考虑降低运维成本, 快速替换硬件.

目前已经成功安装 Ubuntu 在 RAID 上并引导, 只要按照 HighPoint 文档做, 基本没有坑.

硬件的快速替换还是很重要的, 上次语雀事故就是因为之前机器太老, 需要重新配置.

对于小厂来说, 除了更好的运维规范外, 准备些备用硬件, 到时候只需要更换硬件会非常方便, 不至于 8 小时才恢复.

免费的 CI 应该不满足团队开发的需求 (我们现在部分 CI 在为 GitHub 付费).

我们最近也在处理相关工作, 放在办公室的话, 目前最省心的是 Mac mini.

> 导致华东地区生产环境存储服务器被误下线
> 升级硬件版本和机型，实现离线后的快速上线。该措施在本次故障修复中已完成

"下线" 这个词应该就是下线, 没有数据丢失. 不能再次上线正是因为自动化工具不支持, 才导致的. 自动化工具应该之前做过升级, 后续就只支持新机器了.

语雀做的就是找了新机器, 备份了老机器上的数据, 在新机器上重新部署了老机器上的数据服务.

我觉得问题核心应该是 "及时升级" (无论是软件依赖还是底层硬件).

@lqs

> 2012：页面结构与样式要分离，会更容易维护
> 2022：页面结构和样式本来就是耦合的，写在一起才更容易维护

中间少了许多:

1. 页面结构与样式要分离.
2. 页面结构 -> 组件, 分离的样式.
3. 页面结构 -> 业务组件 -> 通用组件, 分离的样式.
4. 页面结构 -> 业务组件(自带样式) -> 通用组件(自带样式).

样式和页面结构还是分离的, 不过和组件耦合了.

就事论事, 签名只能防止数据被修改, 不能防止中间人看数据. 和 HTTPS 解决的部分问题是一样, 但 HTTPS 做了更多.

那么强调签名必要性的愿意就只有一个了, 不信任 HTTPS.

不信任 HTTPS 机制, 那就真是大牛.

如果信任 HTTPS 机制但还是不信任 HTTPS, 那就是不信任 CA.

CA 被攻破的概率不是没有, 但我觉得绝大多数人应该是信任 CA 的.

建议学点前端, 做一点对自己有用的小工具.

如果看不起 JS, 可以 TS. 如果看不起 Web, 可以 Swift + SwiftUI.

如果考虑将来会上 Web 前端, 建议 TypeScript 配合 Deno 运行时.

如果不考虑 Web 前端, 那么如果接纳 Serverless 则用 Python, 如果不接纳则建议 Go.

上述技术我们都在生产环境中使用.

Linux 会被大写, 但是 Web UI 就成了 webui.