你到底想表达什么?先说国内没大流量 Ruby 站点,被科普之后又来了一段 开放 API 没 Ruby 支持?你懂什么叫开放?
Ruby 是蛋,你是苍蝇吗?
eval 这块可以扩展看看 DSL 风格配置的实现(比如 Puma 的配置文件),还有 AR AM 如何使用 eval 构建字段的 accessor 的
都是 Ruby
另外,港铁的控制系统里也有 Ruby
项目全局搜 active_mailbox 删了就好了
AJ 是个标准,接口和实践分离是个很提倡的工程实践
好像被另一个人接盘了,不过 DJ 连 AJ 的协议都没支持全的...
让我们来看看你这个坑能不能填完
炮哥不介绍下一 delayed_job 和你这个的对比吗?
似乎 Rails 6 的 ClassLoader 抽成接口所以可以替换了。
扯个题外的,我之前和 @dsh0416 讨论利用这个和 Bootsnap 的原理做 Ruby 代码的预编译,甚至加上简单的 AES 加密,用来保护外包之类项目的源码
你这里调的 test
是什么。。。你的贴图里一点跟他有关的都没
其次,你要想理解代码,如果不会用调试器,最简单的方式就是你把要研究的那个函数里的每行代码都贴进你的控制台,一行一行执行看返回值,返会 nil
哪步 nil 的?这一步在做什么?调用的库的函数的文档怎么解释的?一步步分析
控制台就是 irb,你用 Rubymine 应该也是这个吧
我不是都给你一种可行做法了么。。。你用我的就行了吧。。。
如果你真的想抠你贴的代码,那也容易,一个是查文档,搞明白这里面调用的每个函数的用途和用法,然后,这段代码在控制台里一步步执行,观察他们的返回值
你能 which 出结果就说明 nmap 存在了,然后你记录下返回值(就是真实路径)然后再去掉他的命令就行了吧
你要不考虑 win 的话,直接
[1] pry(main)> `which ruby`
=> "/Users/jasl/.rvm/rubies/ruby-2.6.2/bin/ruby\n"
[2] pry(main)> path = `which ruby`.gsub("\n", "")
=> "/Users/jasl/.rvm/rubies/ruby-2.6.2/bin/ruby"
[3] pry(main)> path
=> "/Users/jasl/.rvm/rubies/ruby-2.6.2/bin/ruby"
用系统的 which
不就能获得真实路径了吗?
没用过这个 Rex
,理论上不考虑跨平台,你直接 which nmap
就可以了
他函数名已经把这段代码的含义说清楚了吧,定位 nmap 这程序的真实路径
也就是说假如有一天,我们的 secret_key_base 改变了(这个是很有可能发生的),那么就算图片 URL 没有效期,插入到 HTML 里面的图片地址依然会失效。然后这个问题可能还会在你的系统跑了一段时间以后出现。
这个好办,可以在 config/application.rb
里添加这样一段,让 ActiveStorage 使用不同的 secret
来做签名
initializer "app.active_storage.verifier", after: "active_storage.verifier" do
config.after_initialize do |app|
storage_key_base =
if Rails.env.development? || Rails.env.test?
app.secrets.secret_key_base
else
validate_secret_key_base(
ENV["STORAGE_KEY_BASE"] || app.credentials.storage_key_base || app.secrets.storage_key_base
)
end
key_generator = ActiveSupport::KeyGenerator.new(storage_key_base, iterations: 1000)
secret = key_generator.generate_key("ActiveStorage")
ActiveStorage.verifier = ActiveSupport::MessageVerifier.new(secret)
end
end
你说的变量指?如果是 Ruby 的变量最好还是别用 Webpacker,那个 erb-loader 性能不佳。
新项目可以考虑下,老项目迁移还是要考虑成本的,另外 sass 的 ruby 实现这个版本终止维护了,要迁移到 sassc-rails 去
对嘛... 所以除非有啥特殊要求,还是直接 Webpacker 方便
Webpacker 也可以设置 CDN。
如果你要在后端渲染的视图里引入 Webpack 管理的资源的话,要引入带 digest 的文件名,这个独立使用 Webpack 会不会有问题?
不希望用户使用两套系统:选定一边为主系统,另一套提供 API 或者 RPC
不需要用户再两套系统间重复登录:做 SSO
Gitlab 也是这样做的
其实这帖子的事情,前年我已经在 Webpacker 2 上走一遍了,但是犯懒没发,代码也没公开,然后 3 出了,又重新踩了一遍,Webpacker 2 to 3 的踩坑经历还有引入一些库时候的无聊研究真的是血泪史...
最后更新一下集成前端库时候的坑,我前端水平比较菜,如果有什么建议请提出
最后就是我在这里提的是示例,那个 repo 里我自己也列了一些 todo 需要我自己做或者有人来帮忙,我一般每一个大 Rails 版本都会维护这么一套架子,方便开新坑,是个长期的事情
另外缺失一些有用插件的问题,我觉得既然开源了,完全可以群众贡献,或者我自己项目里需要用集成好的会同步过来
一个是 CoreUI 是去年的项目比较新,另一个,Boostrap 3 包括一干老式的 jQuery 插件很多不能直接集成进 Webpack 中,这跟那些维护不周的项目仍在使用老式 JS 模块加载方式有关。
所以这里我做出这个选择,我希望保持传统 Web MVC 的开发体验,同时甩掉过去的包袱,不然大可直接用 Sprockets,没必要迁移到 Webpacker 去了
另外不用 AdminLTE 的原因是他还停留在 Bootstrap 3,我还是希望尽量用最新版本的组件的,包括将来 Bootstrap 5 要去掉 jQuery 依赖,就算是传统风格的前端架构,也还是要跟上潮流,不然就很难补上了,这才是我标题提到的渐进式迁移到现代前端
这些插件都开源的你可以自己集成啊,无非就是记得用他们提供 bootstrap 的 css 而已,这就是用 Bootstrap 的好处了,直接换 bootstrap 标准版本的,通常显示效果就是正确的了。
CoreUI 收费就是把他们帮你预先集成好,外加微调了一下样式
其实我现场还分享了一些别的观点,我认为 GraphQL 流行后,我就会转换到前后端分离方式去了,并且我会认为在那个时候,Rails 就可以进入历史书了。不过我个人对 GQL 的研究还很初级,暂时就不分享这部分了,现场我也只是说这是我的一部分私货