所谓“持续重构”是吧，能有这样的环境自然是好的，能沉淀下去东西。

可能是我的就业环境太低端了，主要做些边缘化的 gov 项目，不是没等上线就黄摊子了，就是上线了就晾在那没人在意了，说需求可能有点埋汰需求这个词了，全凭领导一句话，问题是 gov 内部的人也不知道什么需求不需求的，反正就是“我有个想法”。也不知道这算不算一种幸运，没有维护烦恼，因为领导一换，想法也换了，新摊子就要支起来，还真没有重构这一说……

自己的项目当然是另说了。

非常赞同，在需求逻辑不成型的时候，重构弊大于利。

学到了……

不会痒，会痛，胀痛，头皮绷得非常紧，据说是神经性头痛，用脑过度的时候会发作。

module M
  def self.included(base)
    base.extend(ClassMethods)
  end
  module ClassMethods
    def say_hi
      p "This is the default say hi method, overwirte it in the included Class if necessary."
    end 
  end

  def method_test
    self.class.say_hi
  end
end



class A
  include M
end



class B < A
  def self.say_hi
    p "This is the say hi method defined in Class B."
  end
end



b = B.new
b.method_test

a = A.new
a.method_test

这几年为了前端 Rails 更新很多啊，国内现状还是比较适合 bundling 方案，各种国产 APP 的套壳浏览器还跟不太上 importmap，折腾不起。

比较恶心人的场景是 —— 资源又要写又要读，且都跟用户权限相关，且用户量又比较大……Umm，那不就类似网盘了？感觉不是小厂搞得起的哦，所以好奇找了点资料，蹭楼搬运一下。

coffee 文件后缀名加上.erb试试？

建议 JD 分条排下版哦～看起来密密麻麻滴～

https://ruby-china.org/markdown

Umm...我是凭感觉，感觉描述的场景可能是需要做类似 LBS 类的应用，具体你再权衡权衡 GeoHash 是不是适合～

理论上如果需要在二维空间上计算物体间远近，都可以试试 GeoHash，坐标不一定非得是经纬度，从 0 到 10，从 0 到 1 这样的自定义坐标也可以的，原理上都是做分区编码，然后找最近或最远编码。

咦～你需要的是不是 GeoHash 算法呀～这个算法可以用来求二维空间物体远近。

仁者见仁智者见智，把复杂度留给用户自行选择和内部抽象好再吐出来是个设计权衡。不过 React 写起来还是挺罗嗦的，使用体验比较差，欣赏不太了它的设计哲学。

def 定义方法的作用域是在 Class 里吧，所以调用 method_one 时，实际上还是在 Class 作用域下定义的 method_two。

哇～一天有 280 块饭钱，好羡慕呀～

数据库三值逻辑与编程语言二值逻辑的矛盾，记得一本书里好像说过有一种主义叫做数据库无NULL主义……

啊～找到了

https://www.ituring.com.cn/book/tupubarticle/16419?bookID=1880&type=tubook&subject=%E7%AC%AC%202%20%E7%AB%A0%E3%80%80%E6%9F%A5%E8%AF%A2%E5%9F%BA%E7%A1%80

考虑 NULL 时的条件判断也会变得异常复杂，这与我们希望的结果大相径庭。因此，数据库领域的有识之士们达成了“尽量不使用 NULL”的共识。

DHH 换发型了 ～

大部分都听过，大部分都不会。哈哈哈哈～

刚刚到 rebuilding-rails 上看了一下，英文版貌似 2020 年又更新了一版。

哇～在 dev.to 划水竟然偶遇楼主～莫名赶脚小缘分滴小神奇呀～

https://dev.to/hooopo/getting-started-with-rails-tidb-4pni

开始招人了，不知道老铁们怎么看～

https://www.v2ex.com/t/764060

哈哈哈～那他就得多做点工作了，毕竟分离以后前端的工作量多出来不少。也是挺纠结的，用 Rails 的人少呀。

前辈好，其实我是做了一回 Rails 信条的搬运工～

https://rubyonrails.org/doctrine/#integrated-systems

吼吼吼吼～被坑多了，就变保守了。

不管是什么，个人都觉得没什么好期待的。我的经验是前端能做多薄做多薄，一定要分离的话，那就把在前端的模型层抽离出来，视图层能多薄就多薄。因为模型是王道，视图只是容器，随时要做好把 vue 替换成 react，或者把 react 替换成 vue，或者把 x 替换成 y 的准备。。。

Value integrated systems 的理念适用于绝大多数系统（用实践体会投 DHH 一票），微服务也好，微前端也好，都只是不得不的架构方式，而不是一定要，这种技术复杂度的攀升所消耗的成本和产生的收益性价比远低于 monolith 系统。只有在团队架构不得不拆分的时候考虑拆分系统才有必要，而大厂之外的大多数团队还是达不到这种程度的。

哈哈～刚好前阵子用 thor 做过一个小小的脚手架命令行，thor 那种基于 Class 的编写方式，体验挺不错。

难道就是江湖中传说的传道而非授技之境？

论生态的绝对规模肯定是比不了 react 的，自己玩儿主要还是看个人偏好吧。

对我来说，在预置了较完整架构的基础上，自己从头实现部分插件或组件也是可接受的，还能多实践一些技术细节。

体验上挺顺滑，毕竟是框架级的，分层上的设计考量的比较周全，省得自己各种拼包做分层的过程了，脚手架也挺便利，有些瞬间会有在用 Rails 的错觉～

这位大哥@nightire分享了挺多 ember 相关的内容，我就不班门弄斧了，哈哈～ https://ruby-china.org/topics/32634#reply-319002

大兄弟写得很传神～棒棒！

说到和团队的相处，我也有嘈要吐，斗胆借此宝地小抒郁结了。

以前我喜欢把自己知道的东西耐心地分享出来，觉得有助于和伙伴们达成共识，一起成长。但渐渐发现很多情况下并没什么卵用。

哈珀·李在《杀死一只知更鸟》中这样说到：

人们不喜欢他们身边有人比他们懂得更多。那会让他们很恼火。你说得再正确，也改变不了这些人。除非他们自己想学，否则一点办法也没有。

初次看到这句话的时候，其实挺抵触的，因为我相信沟通和共生的力量。只是现实状况的背逆，又常常让我陷入对这种价值观的质疑挣扎。直到幸运地看到某一期《十三邀》采访贾樟柯，他说：

每个人都希望有自己的观点，能形成共识吗？我对这个过程一点兴趣都没有。

看到之后，有种顿悟释怀的感觉——达成共识，真是一个要耗费巨大精力的过程！就像是做技术架构，因着前期糟糕的设计，往往要付出几倍甚至十几倍的精力去修补。于是我刻意让自己沉默下来，把更多希望寄托在，招揽做事风格和技术品味上癖气相投的小伙伴。相比之下，反倒更容易获得一起玩耍的快感。

说到底，我做了逃兵，对改变自身以外的任何点滴都不抱希望。放过了别人，也放过了自己。