为了避免开发生产环境不一致,我一直用虚拟环境的。以前是虚拟机,现在是 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
这里有几个问题:
你还是先说说用户场景是什么?
PS: X-Y Problem http://coolshell.cn/articles/10804.html
两个问题:
已经在做了~
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 的。
IDE 可以读 schema.rb。
这样塑料小人会不会化掉……
这几家公司都是有人在核心维护组的,没有的话还是建议用稳定版。
自己鼓捣就 ssh forward agent 咯。