最好还有 IDE 支持……

我觉得后台界面就很适合 Rails 开发自己做，前端人力一般不会用在后台上。不知道别人系统怎么样，我遇到的后台交互都比较简单，但是简不简单可能在不同人眼里不一样。

像 @jasl 一直问我有没有兴趣用 stimulus 做个后台 UI 库，我觉得用不着，按具体场景自己写就好了。然后他给了个例子，支持 nested field 的交互——一个 nested form 表单，点击一个按钮增加一列子级表单的内容。这个交互还有人做成了 gem（https://github.com/nathanvda/cocoon），但用 stimulus 写，核心 js 代码其实就十几行（https://www.driftingruby.com/episodes/nested-forms-from-scratch-with-stimulusjs）。当然写成 gem 的附加功能多很多，例如很多钩子方法，但是自己写根本不用实现这么多附加功能。

总的来说，我觉得简单和复杂在很多人眼里不一样，很多人高估了复杂度。

stimulus 和 turbolinks 本身都是轻量的框架，但是组合起来实现了 SPA 类似的体验，并且可以重用服务端渲染的很多优点。为了可能的复杂性直接上 react 这类框架，相对需求本身往往增加了巨大的复杂度，在我看来很多应用都过度工程化了。

Stimulus 刚出没多久的时候做了一次线下分享，讲完之后场面冷冷清清，然后我问还有人写前端么，结果没人举手。

Stiumlus 是 Rails 前端最后一块拼图：以服务端渲染为底，轻型交互用 Stimulus，重型交互用 Webpakcer + 任何前端框架，可以满足大部分的需求。

around_action :lock_shelf
before_action :check_shelf_availability

private

def lock_shelf
  @shelf = ...
  @shelf.with_lock do
    yield
  end
end

创建 book 的时候 lock shelf

https://api.rubyonrails.org/classes/ActiveRecord/Locking/Pessimistic.html

很不错。

要实现阻塞轮询，那么根本不用 worker：

def run_jenkins
  white !jenkins_ready
    sleep 60
  end
  render
end

这里有几个问题：

1. 用户执行这个操作后，页面就挂住了，好像服务器失去响应一样。
2. app server 通常会有超时设置，例如超过 30 秒没完成就强制退出。
3. 基于进程或线程的 app server 并发数减一，并会最终卡死。

你还是先说说用户场景是什么？

PS: X-Y Problem http://coolshell.cn/articles/10804.html

两个问题：

1. worker 是阻塞操作吗？
2. 不返回前端页面用户端也一直阻塞吗？

已经在做了～

sidekiq

ActiveJob 用 wait 参数延时执行，任务末尾需要轮询的时候 enqueue 自己。

这种不一致的数据迁移我会单独写一个脚本，migration 只管模式迁移。

我习惯一个迁移包含一个任务，顶楼情况，增加 user 表和添加 user_id 是一个任务（增加 User Model），去掉 default value 是另一个任务（这跟 User 有关吗？）。

楼主不会真的贴了密码出来吧？赶紧改密码。

不要依赖 turbolinks:load 了，https://stimulusjs.org/ 是最适合 Turbolinks 的做法。

https://github.com/turbolinks/turbolinks#attaching-behavior-with-stimulus

看了下源码 MiniMagick::Image.open 用的是 open-uri 实现，可以在终端自己试试用 open-uri 打开链接看看。

另外代码效率比较低啊，每次渲染都要下载图片解析，activestorage 本身保存了图片 metadata 的。

1. 有多少性能损失得测过才知道。
2. 用 Rails 默认栈不应该成为思想负担。
3. 人力资源比服务器更贵。

IDE 可以读 schema.rb。

用 config_for https://guides.rubyonrails.org/configuring.html#custom-configuration

这样塑料小人会不会化掉……

这几家公司都是有人在核心维护组的，没有的话还是建议用稳定版。

自己鼓捣就 ssh forward agent 咯。

另外几个项目可能配置了 deploy key，同事机子可能配置了 ssh forward agent，不能排除服务器访问不到 repo 的问题。

话说这问题不应该问同事吗？

cap 部署需要部署时服务器可以访问 git repo，可以选择在服务器上配置一个专门的 deploy key，或者通过 ssh forward agent 使用本地的 key。

对我来说依然不觉得类型检查有什么必要，过去遇到的 Bug 几乎都跟类型没什么关系，只是可选的那就留待观察好了。（真香警告）

为了一个字体增加首页几 M 下载量，说不定用户还是手机流量，真的值得吗？不如跟客户沟通一下，设定几个字体 fallback 到本地字体。