总感觉这篇有洗稿的嫌疑。

苹果啥都好，就是产品定价太贪婪太贵了。（当然，这点也可以说是我自己的错。）

新项目其实建议用 pundit，更可控，user.admin? 一般都是 users 数据表里面又个 boolean 字段，叫 admin，?是 ruby 惯用法，返回 true/false 的方法或者属性（这个在 ruby 里面也不区分）。

Rails 6.1 form_with 的默认行为变成 local 了，remote form 需要指定 local: false。 https://twitter.com/chloerei/status/1338048528006844417

感觉这个有点坑。

Capistrano 和 systemd 并不冲突，现在看来 Docker 和 capistrano 各有所长，小项目快发布，还是 capistrano 好。

代码的可读性，可维护性，可重构性，快速查重能力，这些都被你们忽视？

我一直不是很理解 Javaer 为啥那么喜欢说重构，快速查重。代码不是应该没有重的么。。。代码不是应该一次写对，不需要重构的么？Rails 就写了 2～3 行，为啥 Javaer 那么喜欢说可读性和可维护行？你写了 1000 行，有啥可读性，从头看到尾就是要花时间，就是要维护时间多，这不是常识么。。。

说 Java 生产率高，Rails 写两行的速度难道还比不上 Java 写 100 行？就算你有了自动生成器（其实 15 年前我.NET 的 Code Smith 也玩的很转的），但代码 95% 的时间都是在被人读的呀！写的少才难好嘛？！

java 生态圈的 scale out 能力更强，但会有初期的入门曲线陡峭的问题。

老实说我第一次知道 Java 还有入门曲线陡峭的问题，毕竟我也看过 Think in Java 快 20 年了。。

能腾出来 30% 的精力思考代码就已经是良心码农了，所以 IDE + JAVA 这一套更适合打工人。

这句倒是没错，写的越多就越可能重写，打工人不要为难打工人，都有活，坑死一家公司是一家吧。。

刚看到一篇文章，值得一读：https://blog.cloud66.com/rails-configuration-in-kubernetes/

开发用 Docker 感觉没啥用，影响续航，本来可以在星巴克坐一下午，结果 2 小时就得走。。

All problems in computer science can be solved by another level of indirection —— David Wheeler

其实人人都有资本，只是 90% 的人都拿资本买了房。

PUA 你说明对你有兴趣，难道你想国家像保护农民工一样，保护码农吗？

还有两个没出现在照片上，昨晚 JB 兑换码只有三个人要，最后黑白配胜者兑换了 goland，我觉得 JB 和 Ruby 都被黑了。。

不用了吧，那个咖啡馆其实也没多大。。

Ruby 元编程能力还是比较独特的

Fastify最近还上了播客。

很有启发，厉害厉害！

&:func 这种用法叫：Conversion of other objects to procs

我觉得既然用了那么 Fashion 的 Sinatra，不如再上个falcon？

太对了，补充一下，买 SICP，CSAPP 就可以了，三本高度太高了，现在显示器的大小也大了。

join 的例子，直接把部门代码和部门名称都入库就没这问题了

哪有那么容易，业务部门在 8 月告诉你，从 6 月起，某个部门名字换掉，难道你还能全部更新之前跑出来的报表数据不成？

统计类查询使用从库就可以减轻主库的负担，阿里云上点几下就可以的事

没错，但是如果适当针对 OLAP 倾斜，是不需要点这几下的，而且点了这几下也要钱啊！

其实软件开发之所以困难，是因为预测未来的需求是困难的，如果知道未来的需求，设计反倒容易了，这也是我比较喜欢 Rails 的原因，至少人家写的少，未来改起来比较容易，PG 这几年不错，但是 MySQL 8.0.22 以后，查询优化也是做的越来越接近于 Oracle。

回到这个主题上，PostGraphile 可能的确很好，但是我觉得这方案最大问题在于采用后，会减少未来的方案选择余地，我说的那个 Apollo 在这点好很多，它甚至允许你聚合后端的 RestAPI，更不要说多种数据库连接了。

sql 的 sum 不用，改用应用里 select 之后再 sum；join 不用，改用应用程序自己实现 join；

说的正是在下。。其实这两点还是值得一说的，比如在应用里面，有明细和总和，既然已经从数据库拿到了明细，为啥不在显示的时候累加一下，然后直接显示总和呢？

至于为啥要应用程序自己实现 join，因为这样快，比如在报表里面经常需要将部门 code 翻译为部门名字，更变态的是部门的名字还会时不时的改一下，假设部门名字一个月一改的话，如下代码就远远比自己写 SQL join 要好的多了。

@data_dept_short_names = data_deptcode.collect { |d| Bi::OrgReportDeptOrder.department_names(data_last_available_date).fetch(d, Bi::PkCodeName.mapping2deptcode.fetch(d, d)) }

module Bi
  class OrgReportDeptOrder < BiLocalTimeRecord
    self.table_name = 'ORG_REPORT_DEPT_ORDER'

    def self.department_names(available_date)
      Rails.cache.fetch("#{available_date.to_s(:short_month)}/department_names", expires_in: 1.hour) do
        where("是否显示 = '1'")
          .where('开始时间 <= ?', available_date)
          .where('结束时间 IS NULL OR 结束时间 >= ?', available_date)
          .reduce({}) do |h, s|
          h[s.编号] = s.部门
          h
        end
      end
    end
  end
end

其实应用的复杂度是一个总值，schema 设计的让 OLTP 写起来很舒服，往往 OLAP 就很痛苦，当然还可以使用 ETL 工具重新抽取转换，但是，总是少了实时性。

我倒是觉得以 Rails 的表达能力，在做 schema 设计的时候，可以适当对 OLAP 倾斜，这样也就没有 ETL，读写分离啥事了，当然，这样也就变成了扁鹊的大哥，名不出于家了。。。

是有点说的重，我的意思是在选某个方案的时候，了解一下其他声音也好，无论如何，数据库的横向扩展肯定比应用服务器的横向扩展难多了，否则 Rails 6.1 也不会出一堆支持多服务器连接的多数据表的功能了。

如果是 GraphQL 的方案，我其实还是更站redwood.js选的Apollo，没有其他理由，就是觉得阿波罗这个名字听上去很有力量（比如阿波罗男子医院🐶）

但是 Rails 只会发出 SQL，SQL 的执行计划可以很容易的缓存，最终实际上 pg 数据库的 CPU 需要做的工作很少，而PostGraphile 用了 computed-columns，看起来也很鼓励用户在数据库层上加更多的应用逻辑。

Performance note: we inline these function calls into the original SELECT statement, so there's no N+1 issues - it's very efficient.

这会花费数据库更多的 CPU 时间，我的担心是：应用服务器（哪怕 Rails 效率略低）比较容易扩展，但是数据库服务器非常难扩展，所以如果用这套 graphql，很可能过早的碰到 pg 数据库服务器 CPU 跑满的问题，而数据库，你是很难横向扩展的。

他喜欢把 postgres 用尽，尽量不加任何额外的东西，我倒是非常喜欢

除非 pg 彻底解决横向扩展问题，否则第一个 hit 到性能瓶颈的肯定是这样用的 pg，到时候你写的应用就会很尴尬，不像一般的 Rails 应用，至少可以通过加机器再撑一把。

反思为啥就那么轻易的选了这个没人维护的 gem，哦，因为是 996，所以应该离职（逃

写一下 Tailwind CSS，你会重新爱上 Boostrap 的。。

我的《如何使用 TailwindCSS 开发一个 10 万 + 的企业官网》里面讲的 Keynote:

https://www.thape.com/uploads/rubyconf2020-tailwind-css-rails6-alpinejs.key

其实钱到位菜市场也可以编程的。。

楼主谦虚了，我觉得懂 Windows 开发的一般也不懂 IOCP。