个人认为入职两周就走，总比入职半年再走要强。

黑客才不是这个样子呢

@123s 按劳动法规定，即使员工违纪，也只能批评警告或者开除，却不能扣发员工工资；但是公司可以不发或者少发奖金。

那个 make bug great again 居然没有

@hellwys1 鼠标贵不是应该省着用么？

evernote 的 web 版做的最好，APP 很难用； onenote 的 APP 做得不错，web 很难用。

首先，你得有一波 mac mini

4k 只能上 30Hz，等下一次电脑升级再考虑

FF 用户表示欢迎

原则上 20 个工作日内备案完毕，我第一次备案花了 3 天，当时比较简单，直接去自治区通信管理局交表即可。第二次备案用阿里云的系统备的，从提交完材料开始计算花了三个星期。

我当年从 SVN 转到 git 的时候，特别想找到一张 cheat sheet，能把我日常使用的 SVN 版本管理任务找到 git 上的对应方法。后来静下心来看了两个小时文档，发现 git 和 SVN 的设计理念完全不同，很难一一对应起来。SVN 上的常见用法在 git 上不常见，git 上的常见用法 SVN 可能根本没有。

从一个工具换到另一个同类工具，自己突然变成了小学生，啥都不懂特别慌，就希望赶紧找到原来习惯操作的等价方法，却无视这些同类工具本不相同，方法理念也不一样。

我认为 PHP 容器化的最大问题有两个，一个是性能问题，一个是错误处理问题。

本地函数几毫秒处理完的问题，过一遍 rpc 协议层就无端端多了十几毫秒。PHP 又不像 node 或者 go 那样可以把 API 调用丢到后台运行，只能傻傻等待 rpc 返回再往下执行。如果一个 PHP 服务接口里面集成调用七八个微服务 API，单次请求处理耗时可以到数五六百毫秒。

错误处理的问题也是 PHP 微服务化上的拦路虎。一般 PHP 开发时，接口业务流会捕获异常然后判断，在业务处理范围内的向用户输出错误提示，不在常规业务处理范围内的记录异常日志和调用栈，向用户输出未知错误。微服务化之后，可能出现异常的情况增加了许多，包括 rpc 封装异常、内部网络异常、微服务远程异常等等。考虑内部 API 的重试，限流，熔断等机制，需要处理的异常情况更多了。而且不来则已，一来就是洪水一般，非常考验业务开发人员的心理素质。

设想一下你的系统运行在一个物理隔离的内部网络中，然后所有客户端都是 Windows xp

tag 本来就是人类可读的 commit id 别名

const (

GCP 花光了钱会锁住你的机器，只有手动再把它启动，才会从卡里扣钱

你们谁用过 Visual J++？

为啥要在服务器上 go get ？

我都是在未来的版本开发里面捎带重构的事情。很多时候向前不懂技术的管理者提出重构要求就会陷入无止境的扯皮中，所以我都是直接在评估时间的时候把重构工作算进去。