赞，最近代码开始有点味道，正好重构用。

好胸

茶

T 恤设计的不错

我们会要求工程师每天必须 merge 到 staging 一次以保证 CI build 是绿的并自动部署，避免过大的 MR。这样有几个好处：

• Review MR 的人不会一脸懵逼。
• staging 环境始终保持在一个有最新代码并且可测试的状态。
• 工程师会在写之前更认真地思考架构，比如一个大的 feature 如何拆分成一个一个小的可以持续 deliver 的功能。

少年，我一年前也是和你一样想法，后来选了 semantic-ui。如果重新选择，会选 bootstrap，并不重，延展性也不错。

#14 楼 @joway 如果有时间我觉得研究下 webpack 是可以的，不过要有心理准备配置起来不那么直接 + 文档比较少，当然配置好之后用起来就很方便了，组件化和自动构建都能做得挺好。如果没有太多工程化经验，可以先学习下模块化，了解下 AMD/CommonJS，browserify/webpack 选一个，构建工具可以学习下 grunt/gulp，或者直接 webpack。这有我一月做的关于 react 的演讲可以参考下：http://www.ruiyeah.com/2016/01/11/React-Introduction/

#21 楼 @x1nyhh 用 webpack 会管理起来方便，但不一定要用。用一个 polyfill 就行了，比如这个 https://github.com/ModuleLoader/es6-module-loader。

我觉得学习 Rails 的架构会对自己代码质量和架构有一个提升，对前端工程化的思想会有帮助。但是如果楼主想继续做前端的话，建议深入学习下前端工程化，比如构建工具 gulp/grunt/webpack，框架 react/vue/angular，然后可以看看 node (比如 koa)，一些公司前后端分离之后 node 中间层也会需要前端来写。

#19 楼 @deng19891006 用 asset_url 也可以，然后在环境配置 (development.rb/production.rb) 里面配置：

config.action_controller.asset_host = "assets.example.com"

#2 楼 @tesla_lee semantic 不错

#1 楼 @peter +1

#2 楼 @frankking :plus1:

vue 确实小而美，我们复杂交互用 react，简单交互（比如后台管理）的就用 vue 了。

赞，按 LZ 教程操作了一遍确实不错。如果是国内下载 docker 镜像慢的话可以跑下面的命令设置：

pinata get daemon | jq -cm '."registry-mirrors" = ["https://XXXXX.mirror.aliyuncs.com"]' | pinata set daemon -

镜像加速可以用阿里云的（https://dev.aliyun.com/search.html），也可以用网易。

cc 攻击啊，前几天我们也遇到了。一般黑客用不同肉机发起的。

#12 楼 @hayate +1

#16 楼 @hxgdzyuyi 嗯，具体看使用场景啦。如果前端比较重，特别用 react 之后，会有一些 stylesheet 和 js 组件绑得很紧。另外因为有些 npm package 里同时有 js 和 css ，引用起来比较方便。

#14 楼 @liyaodonglibin :plus1:

#1 楼 @pathbox 妹子入职就能看到 :p

#2 楼 @ice_col 收到 我们排查下

我们还在招 ruby 实工程师，欢迎报名

赞啊，可惜那 16 号不在深圳

#9 楼 @imwildcat react_on_rails 可以的，用 npm 里的 react-on-rails，后端还是引入 react_on_rails gem。

#6 楼 @u1370743666 如果 asset pipeline 下需要不同页面用不同的 manifest file。

#3 楼 @rubyonlinux 我们 react 组件的服务器渲染有用这个

#1 楼 @rei rails asset pipeline 在某些情况下已经显得封闭，和现在前端生态结合的不是很好，使用 browserify 也好 webpack 也好都只是一种选择。webpack 配置本身就比 browserify 复杂，但功能更多，可以打包 js 的同时也按需打包 css、image 等。至于 webpack 和 browserify 孰优孰劣我觉得本身就没有一个结论，看不同场景和需求。

关于在 Rails 使用 webpack，这一篇会说的更详细一些：https://ruby-china.org/topics/29630

按照 rails best practice 来楼主的坑大都还可以避免，个人遇到比较多的是问题是 model 层太肥了，太肥了，太肥了。安利一下破解之法：http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/