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

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

  • over at 2023年04月08日

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

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

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

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

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

    • Relingo: 浏览器插件,自动识别陌生英文单词并标识,并且可以导出生词到其他工具,强化学习
    • Saladict:翻译类浏览器插件,主动搜索式的,不会自动识别陌生字,但是可以和扇贝/anki 联动,自动添加生词
  • 只要触发了索引外的字段,就需要回表来显示数据的吧

  • 垃圾回收原理浅析 at 2022年04月26日

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

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

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

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

  • 「吐槽」关于酷站节点 at 2019年01月17日

    酷的要死~

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

  • 郑州 Rubyist 还有多少? at 2018年05月28日

    😍 😘 😚 😋 😊 😎

  • 求个 credentials 的实践方案。

  • 多人协作版的 swagger editer?

  • 👍

  • 前后端分裂 at 2018年01月12日

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

  • 空库执行下 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 吗?

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

  • 找到了一些额外的文章:

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

    • 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 在版本跟踪中没有意义。