1. stackoverflow 的回答不是挺好的，用 joins。
2. 先看看有没有人提过，如果没有可以提，GitHub 提交 issue 的时候有模版。

从侧栏删掉链接了。

工具那里我指的是语言。

GitLab 对于他们的文档要怎么写，他们是有决定权的。但是例如“Rails 要怎么部署”，这属于个人观点，没有人有决定权的（除了自己）。

Cargo 的核心团队里有 Yehuda Katz（前 Ruby on Rails 核心团队成员），吸收了 Ruby 社区依赖管理的成功经验，所以依赖管理是同类语言里最好的。反面例子就是 Go 了，最近才由官方推出 Dep 终结混乱。

能高效的解决问题的工具就是好工具，不用太在意用的人多不多，有时用的人少反而是自己的秘密武器。

太粗暴了，我犹豫要不要屏蔽。

时间太久了我都忘了是怎么坑掉的，好像是因为编辑意见不统一后来我不干了，我不懂管理 wiki。现在觉得 wiki 适合定义“什么是什么”这类内容，而“怎么完成某件事”，各人有各人的看法，适合各写各的，根据点赞和时间排序。

理想是做成这样 https://www.digitalocean.com/community/tutorials

话说回来，现在没时间做……

后台任务通过某种消息机制（例如 Redis pubsub）通知管理 websockets 的进程，再由管理 websockets 的进程通知用户。

Rails 里的 ActionCable 实现了这个机制 https://guides.rubyonrails.org/action_cable_overview.html

服务器上 curl 一下本地端口能不能访问？云服务有没有安全组设置？

那个是 hash 而不是时间戳，前端可以把文件名和打包后的静态文件路径写到一个 json 文件里，然后在 Rails 加个 helper 方法读取 json 内的路径，就可以做到类似 stylesheet_link_tag 的效果。

https://github.com/rails/webpacker 已经做了这件事情，并且 Rails 6.0 会成为默认，如果你们前端团队本来就是用 Webpack 而且不介意源码放在同一个项目里，那么可以试试 Webpacker。

stylesheet_link_tag 的作用就是找 asset pipeline 处理过后的资源，如果不走 pipeline 直接用 <style> 标签即可。

确实有网站是用 Turbolinks 实现不间断播放器的

Why We Chose Turbolinks https://changelog.com/posts/why-we-chose-turbolinks

我更正一下，6 楼意思是依赖 turbolinks:load 绑定事件不是好实践。边栏可能大部分情况需要每次载入都执行，但到了没有边栏的页面就是无谓的消耗了。如果习惯这种写法的话，个别页面的事件也这样绑，那么挂在 turbolinks:load 上面的逻辑就会越来越多，并且很多是不必要执行的。

$(document).ready(function() {                                                                                      
  jQuery(function ($) {

这里两层 document load 有问题，导致外层改了时间里面还是在等 DOMContentLoaded。

外层改成 $(document).on('turbolinks:load', function() { 再把里层 jQuery(function ($) { 去掉。

另外全局绑定事件不是好实践，有时间的建议看 Stimulus，和 Turbolinks 绝配。

1. 如果要看一个教程，我推荐 https://gorails.com/deploy/ubuntu/ ，这是我所知唯一能持续更新维护良好的教程。
2. gemset 已经被 bundler 替代，可以弃用。我认为安装系统源里的 ruby 比用 rvm/rbenv 的更好管理，后两者经常要处理不同环境和工具的 PATH 的问题。

完事了就可以把组件去掉了

https://medium.com/@coorasse/goodbye-sprockets-welcome-webpacker-3-0-ff877fb8fa79

看 DHH 什么时候改口去掉 Assets Pipeline 了，装了 Webpacker 之后看到两个 asset 类目录感觉很分裂。

@heroyct @jasl docker-sync 完美解决 docker for mac 性能问题！

向 Webpakcer 低头！

看了源码和调试 demo，发现两个有趣的地方：

1. Rich text 是独立一个 model，关联到原有 model 上面，类似 ActiveStorage 的设计。这是为了表很大时加速查询做的设计。
2. html 内容 post 到后端时，ActionText 会对 attachment 做处理，替换为元信息的 element，这样就可以调整渲染时的模版。

这是全栈框架才能提供的功能，有助于新建项目时快速实现富文本编辑。

准备加入 Rails 全家桶 https://weblog.rubyonrails.org/2018/10/30/introducing-action-text-for-rails-6/

我了解到的 node 是前端用的多，用来做前后端分离的中间层，负责前端构建和请求转发（其实我认为就是 JavaScript 全栈）。

用 Rails 做全栈的少了，退到后端做纯 API，有一次线下分享讲了个前端话题，问在场的人有还写前端的吗，结果没人响应。

额，我是指在开发环境，整个项目目录都作为 volume mount 进去的，但是文件太多了导致执行缓慢。

不懂，在 docker compose 里面配置：

volumes:
  - .:/app

不是 volume 了么？

官方文档关于性能部分 https://docs.docker.com/docker-for-mac/osxfs/#performance-issues-solutions-and-roadmap ，看完还是不知道怎么解决。

不想现在处理 Webpacker 另一个原因是怕正式版前还有变动，想想被砍的 Turbolinks partial replacement。

建议去掉这个 gem。

是 docker 的问题，如果有限度的用 yarn 让 node_modules 维持在比较小的体积可以缓解这个问题（Webpakcer 默认依赖 700+）。所以我还在用 assets pipeline，等 Rails 6 出了，各个组件的协调不用自己摸索了再去想怎么解决这个问题。

我遇到个 docker 的问题，docker 共享目录的性能遇上庞大的 node_modules 简直爆炸，执行 bin/rails test 先要卡 30 秒。https://github.com/docker/for-mac/issues/77

Webpack is now the default JavaScript compiler for the upcoming Rails 6 🎉 https://twitter.com/dhh/status/1046634277985611776

目前自己搞还是不少麻烦事的，我等 Rails 6 发布再上。

这是个纯前端库，把构建好的 js 放到 vendor，通过 assets pipeline 引入，cofferscript 写就行（ES5 也行）。

这几个前端组件在 Rails 4 环境就能用了。