不喜欢暗色主题

没有测试保证就不要轻易搞大的重构

懷念剛剛升級到 H+時候的速度，當時 42Mbps 真心覺得夠用了

@nigelvon 也许只是一万并发连接，不是 10000rps

MacBook 用户表示不知道什么是风扇音

dd 全盘备份

比尔盖茨儿，乔布斯儿

@codermagefox A 卡体验如何？

@litmxs pwa 并没有全平台兼容。Google 搞出来的东西，Apple 没兴趣支持，用 pwa 基本就得放弃 iOS 用户。

检查一下 content encoding 是否 gzip 了

看是什么日志了，app.log 平时都躺着没人看，出 bug 时才看看

1. 你域名解析出来是哪个 ip 就是哪个 ip，和你公司有几个公网 ip 没关系。除非你自己把六个公网 ip 全加进去了。

2. 你的字段是一次 http 请求中提交的还是多次分部分提交的？如果是后者，你有做提交失败重新发起的处理吗？

3. 只要你是 http 请求里提交数据，就不存在绕一圈会丢失的问题。http 底层的 tcp 协议保证了数据包丢了也会自动重传，重传失败多次会断开连接。上层程序只需要处理成功和失败的情况，不会出现缺少字段的情况。

自从听到微软 edge 改用 Chromium 内核，就把电脑和手机都换成 Firefox 了

给你几个建议

1. 常见的外包合同付款方式是 343 或者 442，首付款在合同签定后支付，中期款在项目验收后支付，尾款在维护期结束后支付。对于不需要乙方维护的项目，可以约定 451 的付款比例，1 在项目验收后一段时间（一般是一个月到三个月）支付，以防乙方埋雷。千万别以为一开始只给 10%，你就占据了主动，如果首付款非常少，事情还非常多，乙方撂挑子的概率很大。

2. 项目开始后双方应该尽可能多沟通，建议至少每周一次。外包项目扯皮最多的是对需求理解的差异，甲方的需求变更，还有乙方的拖延症（实习生多的外包公司尤其如此）。多沟通能够及早发现问题，统一思想和调整方案，虽然也需要耗费精力，但总比全都攒在最后验收时爆发强。

3. 如果有条件的话，甲方提供场地，要求乙方派遣项目组来开发也不错。一方面做到专人专用，而且你也可以随时了解项目进度。你现在的状况可以考虑这种方式，你们支付一笔钱，比如 40%的项目款，让乙方有信心，同时要求乙方派项目组进场开发，以免对方拿了钱不办事。如果没有足够的场地条件，你们甲方派一个人去乙方进驻，随时回答需求疑虑，督查进度也可以。

一楼正解

你先别想着怼人，你觉得写合同不是程序员的职责，你想想起草运维合同是不是技术部门的职责。你们公司有运维部吗？如果有你就告诉老板他们更适合干这个事儿。如果没有，那程序员可能就是你们公司里最接近运维的岗位了。

合同是约定权利义务的文书，运维合同自然得写清楚服务内容和事故赔偿责任。领导也好行政也好他们谁能确切分清楚哪种问题是运维问题，哪种是研发的问题？他们能知道相关技术标准和行业惯例吗？可能你也不知道，但你至少还能上网查问朋友，他们上网查到了都看不懂啊。

我待过手工作坊也待过跨国大厂，可以很负责任地告诉你，所有合同都是具体职能部门起草的，领导负责大方向定性把关提意见，法务负责排查合同中对己方不利的漏洞和套路，至于行政，他们只负责打印、盖章、邮寄、存档这些事儿。大厂程序员不必自己写合同，因为他们有 CTO、事业部负责人、运维部经理等懂技术的领导给做了。

@R18 一般合同都是业务部门自己起草，然后领导修改律师审核

我直接在 typecho 上安装了一个 oss 插件就把它当简易图床了