XX 过多导致视觉模糊。

我用 atom，配合 docker-sync 目前还能接受。

共享文件性能只有本地磁盘的 30% 以下，小文件多的时候简直无法用。remote 编辑是个好方法。

没看懂标题。

不错不错

怎么部署的？用了 puma 还是什么？

App server 的设置？用了多进程或多线程吗？

那行改成 STDIN.gets.chomp() ，因为 gets 实际上是 Kernal.gets，它俩行为不一样：

1. 当 ARGV 为空时，Kernal.gets 从 STDIN 读取内容，行为类似 STDIN.gets。
2. 当 ARGV 不为空时，kernals.gets 把 ARGV 的内容当作文件名，读取文件的下一行。

你的执行命令触发了第二条，把 19 当作了文件名，然后报错文件不存在。

参考 https://stackoverflow.com/questions/27453569/using-gets-gives-no-such-file-or-directory-error-when-i-pass-arguments-to-my/27453657

顶楼代码还有其他问题，考虑到楼主正在练习，我先不指出。

那用微信支付宝更好查 😅

其实跟 heroku 提供的功能比起来它并不贵，并且可以立即体验到领先业界五年、现在一个专业运维团队用现有开源工具都不一定搭得出来的自动化容器管理系统的样子。它对个人用户不好的地方是没有开放亚洲节点，访问比较慢。

国外的服务商大都能满足楼主的功能需求，除了信用卡。轻量级适合入门的有 linode，digitalocean，这两个我觉得 digitalocean 功能上稍微占有，因为提供了虚拟网络、托管 DB 等更接近生产需求的服务，相比之下 linode 太裸机了。

更专业的选择是 AWS，Google Cloud。AWS 在占有率上最高，Gcloud 某些方面更先进，例如 storage 自带 CDN。用这些云平台可以更好理解生产环境的部署需求，只是对于部署博客来说一上来要学习云平台的权限配置等等有些过重。

至于 Vultr，我经常听到它跟低价联系在一起，我一般不会选这样的服务商。

为了避免开发生产环境不一致，我一直用虚拟环境的。以前是虚拟机，现在是 docker。把本地模拟到跟生产环境一致。

这里提示的是 nokogiri 安装失败。

net/http

觉得现有的不够好不是可以开心的开发轮子吗？

最好还有 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 有关吗？）。