wsl 下面 idea 整合也不够好。idea 社区版不支持 wsl 下面的运行。收费版本，启动也要额外配置。 最后发现可以用 jb 的 gateway，然后 wsl 里面装 idea 的 server 端，然后用 本地云桌面的方式运行，这样还简单点

解耦的开发挺好的。单纯后端，各模块还要解耦呢。那前后端解耦也挺好。工作量方面，虽然分开后总体工作量高一些。但是未必人力要多很多。也依然可以全栈，一个人负责全部。另外从招聘角度，招聘个优秀的全栈，不如单独招聘容易。

补充下，公司性质非外包。假如用“外包”性质的词去定义，可以称之为“内包”。类似华为 OD，不过数字马力侧重于在郑州，长沙（23 年才开始）这种二线城市，用独立的业务线来切分工作职责。 郑州当前的软件开发市场，优秀公司不多。数字马力在郑州的基本待遇等方面还是不错的。

单侧和集侧的价值都是发现问题，保证质量。单侧更多是在开发阶段，各种 case 都能验证。你偏向的集侧更能保证交付质量。但是集侧你把所有 case 都覆盖，那难度就更大了。你的立场很明确了，你是以最终交付质量来评判的测试代码的作用，那么你的结果却是是要集成测试。

单侧就是要屏蔽所有的外部依赖。 集成测试其实也可以分好几层，看集成的程度。比如集成所有的内部可控组建，但是一般外部服务还是集成不了，必须 mock 的。 单侧有必要，TDD/BDD 就是靠的单侧。 集成测试也有必要，因为是更完整的产品质量的保证。 但是团队咋选择？领导说了算。

我也时隔 5 年没有碰过 rails，已经转到 java 了。中间有想过跳槽继续 rails，可惜没有把握住机会。马上去新公司了，继续 java～

歪个楼，关于 iPad 和 android pad 的问题。android pad 可以设置应用锁，将应用商店加个密码，孩子就不能随意下载 app 了。iPad 假如你下载过 xx 游戏，卸载了，但是可以免密码重新下载了。iPad 有避免孩子主动下载游戏的设置吗？

• Relingo: 浏览器插件，自动识别陌生英文单词并标识，并且可以导出生词到其他工具，强化学习
• Saladict：翻译类浏览器插件，主动搜索式的，不会自动识别陌生字，但是可以和扇贝/anki 联动，自动添加生词

只要触发了索引外的字段，就需要回表来显示数据的吧

深入理解 Java 虚拟机：JVM 高级特性与最佳实践（第 3 版）这个书讲 java 的，一些原理类似

取代 Charlic 这个我觉得很有价值，但是"请求跟 postman 一模一样，但是返回死活报错！“这个我感触不深，似乎基于 openapi，共用一套接口准则，不太会发生。另外一点，openapi diff 我觉得还是有价值的，不过这个有开源的方案，我们也落地使用了

比较简单的方法，也适用于 zsh 之类的，把 bash 命名的文件存到本地，然后执行本地的，用于替换curl -sSL https://get.rvm.io这块

和语音无关，针对这个场景，该考虑到多线程的并行执行

酷的要死～

无论如何，先把屁放了，别憋着。 等舒畅了，优美的代码才有会来～

求个 credentials 的实践方案。

多人协作版的 swagger editer?

能够被热议，那么前后端分离的普及就更近一步了。

空库执行下 migrate，然后把 schema.rb 覆盖到最后一个 version 中，然后把其他的 migrate 删掉，这样就合并了，还是比较轻松的

我现在有个观点：1：要保证 migrate 的连续性，保证其可以顺序执行。2：定期或者大版本更新后，清理一次 migrate 文件目录，将多个 migrate 文件合并到一个，为 migrate 文件夹瘦身（需要注意不能创建新的 migrate，而是用老的已有的 version，否则会视为新的 migrate 而清表重建）。 这样是不是一种更好的代码维护方式？

schema 文件会在 rails db:migrate 后重写的。只要不基于 master 执行 rails db:schema:load 那么 master 滞后的问题可以忽略。既然你们团队对 schema.rb 文件也不重视，很多人为了避免冲突而选择不提交它，那么变成一个团队内的约定，都不提交，也未尝不可。你单独为了一个老旧的约定，而做一些对团队其他人意义不大的事情，我觉得没必要～

为什么需要手动维护这个文件？

是的，重跑下就解决了。有一个场景：我们借助 coding.net，多人提交合并请求，都携带了 schema.rb，那么前一个合并后，后面的全部都会提示合并冲突。另外多人协作，大多数情况下，我不需要关心别人的 schema 改动，那么这种冲突解决就对我们来说浪费时间。

谢谢，这样优缺点已经很明确了。希望这个也能给别的愿意思考与质疑的人一些参考。

看 productimage 的模型，不应该是复数的 images 吗？

谢谢提醒。重新认识了下，我是有了答案，希望找到一个有说服力的反方观点，感觉还是没找到~

找到了一些额外的文章：

• Always Check In Schema.Rb
• What is the right approach to deal with Rails db/schema.rb file in GIT?
• What is the preferred way to manage schema.rb in git? 英语水平有限，并未完全看懂。中间也见到一些人未将其放入版本控制。

我再重新梳理下我的思考：

• schema.rb 是一个自动生成的文件，rails db:migrate等命名执行后，此文件会重新生成。
• schema.rb 表述本地当前的数据库结构，migration 外手动修改数据库后，执行rails db:migrate会反应到 schema.rb 上
• schema.rb 究竟应该被谁版本控制？我的观点是 migrate 文件，而不是版本控制工具。只有 migrate 文件才能表述程序的迭代。上面提到的那个点，很容易破坏 schema.rb，信任这样的 schema.rb 然后向下迭代是危险的。而空库 migrate 后的 schema 才是唯一表述迭代后数据库该有的结构。
• 大多观点在 2011 年就已经加入，schema.rb 中的注释是 07 年加入的。我不认为在当前的计算机配置下，rails db:migrate会比'rails db:schema:load慢多少，所以我不认为这一点它可以快速迁移数据库到你期望的状态` 还依然会是优点。另外 rails 项目一般也不庞大~
• 多人协作时，大部分都负责不同的模块，同时修改某个表导致的冲突不多。git 的不智能，导致的 version 冲突的问题，让其发生并且去花费时间解决，并没有意义。
• 合并到主分支，一定是顺序执行的。假如同时修改一个表，那么最后一个提交到主分支的人在提交前就应该发现到了 migrate 冲突并解决。理论上存在可能性，同时删除了一个字段，但是概率很低。并且现在的开发理念中，都会有各种测试手段与流程。取舍之间，我选择舍弃会造成冲突的 schema.rb 跟踪，换来存在小概率 migrate 定义冲突情况的发生，并通过测试等手段解决掉这个副作用问题。
• 它加入到版本控制确实也不会对团队造成太大的生产力浪费，但是频次还是比较高的。基于上面的一些观点，我还是觉得加入到版本控制没有大的优点，那么把它移出版本跟踪，对团队还是会减少一些此文件冲突烦恼的。
• 再次强调下，我认为 schema.rb 应该被 migrate 文件控制，而不是版本工具。

我自测了一下，数据库里面直接删除一个字段，然后执行一个空的 migrate，接着 schema.rb 会更新为当前数据库的结构。而不和 migrate 文件定义的一致。似乎 schema.rb 只是rails db:migrate执行后，rails 根据数据库结构重建的结果，只反应本地数据库的状态。

重跑 migrate 之后和线上数据库 schema 不一致的一定是手动修改过数据库，那么把 schema.rb 加到文件跟踪也不会根本性解决问题。因为 migrate 文件会影响数据库结构，除了rails db:schema:load外，schema.rb 并不会反影响到数据库结构。

如上成立的话，还是感觉 schema.rb 在版本跟踪中没有意义。