甲醛测试药剂，检测颜色达标后入住。

现在读计算机的都是为了考公务员。
工科专业除了计算机，别的基本不能考公务员，除非考那些不限专业的，但岗位少。

说实话吃米饭米饭等同吃糖，会短时间内快速提升血糖，
反倒是肯德基鸡肉蛋白质不容易马上被消化血糖升的慢，

说回来不管是米饭还是汉堡吃得太多都不健康。

不能，还不如直接 win 下开虚拟机玩 linux，
或者继续 linux 下开虚拟机玩 win

我选择后者。

前端大佬！

看情况吧，普通业务 php 后端有 sonataadmin 这种 crud 生成器框架，搞完实体类直接生成页面，再稍微修改下，就搞定了，优点是快速且能定制。

碰到搞不定的复杂业务再上前后端分离。

前端钱多。

所以要有好的设计，
NetBeans 这些开源项目的源码都很容易上手。

我不信 java 没有，
java 有甚至很丰富，看看 java 的相应式编程中 Reactive Streams

base64_decode 不是解码吗？
难道不是应该 base64_encode 来编码吗？

rust 就算了，威胁不了 cpp 的，

rust 不适合做 GUI，前有 qt c++的庞大的历史生态各种组件都有，（且 rust 的 ffi 使用 qt 的方式不稳定 bug 多，根本不能用于实际），后来者又有 js mvvm 新浪。

rust 也不适合写服务后端这种需求量大的业务，因为 crud boy 们写业务讲究的就是快，rust 这种没有运行时依赖注入容器辅助的，要玩黑魔法修改或者替换，运行时某些符合某种规则的 struct 方法 func 的行为都做不到，只能手动人肉修改每个 struct 源代码，会被写业务的 crud boy 们嫌弃的。

rust 也不适合写小工具，小工具用 python 、php 、js 等脚本不是更方便，即使是性能需求或者有保护源代码版权不泄露的小工具，也都会倾向于用 go 写，vagrant 都从 ruby 改成用 go 重写了，esbuild 选择了 go 而不是 rust，因为更多是开发效率上、人力成本上的考虑。

而 jpg 、mp4 这种套了容器压缩算法的本身就很复杂了，diff 很难

二进制文件怎么 diff，怎么 merge 解决冲突，
每种二进制文件都有自己的格式标准哦，
除非指定二进制文件类型，比如 office 文件的版本管理，比如 bmp 文件的版本管理，

而 jpg 、mp4 这种套了容器压缩的本事就很