刚看到一篇文章，值得一读：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。

ruby 不是表示语言

对我来说，Ruby 基本就可以用作表示语言。

我认为 ruby 这语言最核心的一点是，同其他语言相比，非常在意的表达的高层性，或者说越接近人类语言越好。

加引用本身就不是人类语言语法的一部分，所以官方肯定是不可能加的，从 Ruby 3 加的类型检查，都是分文件，而不是用惯常的a: integer这样的其他语言语法就可以看出官方的选择。

Ruby 这边的确在不断优化性能，但是不可能为了优化性能牺牲表达的高层性。

我以前也以为键盘是 HHKB 最好，但最近，我站 MBP 的垃圾蝶式。如果你能在 4 年内敲坏它，苹果官方就给你换电池！

据我所知 element-ui 团队都转岗了（为了工资🐶），慎选吧。。

我现在还在用 capistrano 部署，Docker 的优点很多，但是，capistrano 可以让我改好代码递交后，30 秒内部署生产服务器完毕。

Safari 正常，也可以已经更新了 SSL 证书。

其实都加上也不是不可以，为了吸引下一代程序员，就要从打比赛抓起。。