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

时间太久了我都忘了是怎么坑掉的，好像是因为编辑意见不统一后来我不干了，我不懂管理 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 环境就能用了。

奥，我看漏眼了，顶楼有写 Shopify 的开源库 https://github.com/Shopify/ess

意思是你有 Shopify 源码？

完善公司信息是招聘板块的要求。

完美！

首先 ScriptCore 是 ESS 的 fork

是不是应该说 clone? fork 是基于别人的源码再开发。