2012 年吧，从运营想转码，开始学的 java php 和前端，后来觉得 ruby 和 python 不错，也是那时 ruby-china 网站出来了，在论坛自学了两周 ruby on rails。在广州 ruby 聚会认识了一帮好老师 @leondu @adevadeh ，哇都是多年了，怀念。现在在厂里啥都用，就是 ruby 比较少...

当晚听了，获益良多。前几年从 ruby 转到其他语言，进了厂，也一直关注着 ruby 社区，目前见到远程工作逐渐增多的确是好事。最近看到 hn 上的讨论，挺有意思的，也分享过来

远程工作的问题

招聘依然继续

RUN bundler install => CMD ["bundle", "install"]，还有既然是用了 compose, 命令可以写在外面

command:
- /biin/sh
- c
- |
  bundle install
  bundle exec rails db:migrate
  bundle exec rails assets:precompile
  bundle exec puma -C config/puma.rb

一般用 compose，就没必要 nginx 跑在一起了，外部配一个反向代理到暴露的端口就行

brew 更新国内镜像源 第一步，替换 brew.git cd "$(brew --repo)" git remote set-url origin https://mirrors.ustc.edu.cn/brew.git

第二步：替换 homebrew-core.git cd "$(brew --repo)/Library/Taps/homebrew/homebrew-core" git remote set-url origin https://mirrors.ustc.edu.cn/homebrew-core.git

最后使用 brew update 第一次 update 会几分钟，后面安装飞快

复原 cd "$(brew --repo)" git remote set-url origin https://github.com/Homebrew/brew.git

cd "$(brew --repo)/Library/Taps/homebrew/homebrew-core" git remote set-url origin https://github.com/Homebrew/homebrew-core

brew update

感觉挺清爽的，但是比 dash 和 zeal 的优势在哪里呢，他们都可以离线查询并且还蛮快的

多年 mbp 用户最近换电脑到雷蛇，硬件配置强大，性价比不用说

vscode remote + wsl2 + docker + windows terminal, 开发体验良好，管理正式环境上的服务器群也没问题。

Windows 下例如查文档的有 zeal 之类也一点不比 mac os 下的体验差。后续如果 jetbrains 全家桶也加入像 vscode remote 的类似功能就更理想了。

招聘仍在继续

一般都要，正常的入职面试流程来的。

另外楼主自己要保护好自己利益。

这话看起来怎么这么熟悉

https://github.com/YMFE/yapi

加完班了吗

虽然工作一直没离开 ruby，但这几年的感觉下来，ruby 进化得比较慢。但是楼主说是否 ruby 太难，本人感觉不是。

自己主力机是 mbp15，之前在 WSL 刚出来时在 surface pro 上折腾过，遇到基本楼上遇到过的所有问题（docker io 慢之类），后来一气之下换了一台 new macbook 出差用。

但还是觉得微软这个方向很不错，希望后续能把体验做得更无缝，毕竟使用 windows 的硬件更便宜。

@geniousli 可以的

不过目前在实际项目中，我们项目管理上还是使用完全的前后分离较为多。即前端分离出去，并没有继续使用 webpacker。

赞，刚好项目上用到，先研究参考一下炮哥的思路。已打赏~

感谢楼主，之前 Rails 3.2 的时候也是用的 Capistrano。后来随着部署的任务越来越复杂，多台机，处理更多其他语言的模块，还有其他服务任务的启停通知，进而转向了 mina，因为 mina 的源码非常简洁，实现自定义功能很简单。

@mz2test 这个报错是 webpack 相关，scss 找不到变量的定义，建议检查下 loader 的加载有无问题

看业务，看团队的体量。如果业务和团队是从小开始做大，这样可以逐步拆分业务。微服务是个好东西，但要看是否适合，如果带来的结果是维护成本大导致开发效率影响业务发展，这就得不偿失了。

Awesome job! 荣幸文章能被收录，一直觉得 Ruby-China 是技术讨论氛围最好的中文技术社区！

喜欢楼主很久了，投份简历试试

还有一个名额

@ruomu 可以的，我们同时也在招聘 NodeJS 的职位，我们主要看的是自学能力和态度，当前能力和经验都可以提高的。当然也希望在考虑应聘前，要对 Ruby/ Rails 和 web 开发的基础都有个熟悉。请投简历

炮哥帮忙推荐下！

这是一个例子，注意目录结构，外部的 calendar.js 里的这句话，会引用calendar/目录下 index.js 文件

@huacnlee 反向查询 count 时，如果之前没有请求一下 Origin Object，会导致 Target Object xxx_by_users method undefined, 例如：

#User Model
action_store :star, :article, counter_cache: true, user_counter_cache: true

#但是在测试里
@article = create(:article)
@article.star_by_users  #method missing error
User #随便读一下user class
@article.star_by_users # => []

觉得 CtrlP 已经够用了，代码片段一边用 ack-grep

真要对比出来，可能要新开篇去说了。只能说下对于小公司来说，webpacker 有点给我们带来这些好处: （1）以前前端同学写完后推代码，等运维同学拉代码部署到运行容器，接上数据查看有没出错，出错了还要重来一遍。现在直接本地可以同步效果，在同一个环境下不会再存在一些额外需要去把 API 服务器调跨域之类的问题。 (2) precompile 后的工作和 assets pipeline 差不多，原来的部署脚本也一步到位了 (3) 像基本我们百分百对外项目静态文件都用到 CDN 的，用手动分离的方式中间要做很多的整合工作。 (4) 和 assets pipeline 对比的优点就更不用说啦，yarn 对比 gem，babel es6 es7 特性对比 coffee，webpacker 自带处理的各种 vue-loader 啊，portcss 之类的，assets pipeline 都会很别扭。

综合地来说，就是对前端用得比较深的，都知道现在 webpacker 是大一统，前端最前沿的技术都在这里可以体验。assets pipeline 和 turbolinks 是能顶大部分的需求，还是看项目情况使用吧。

这种处理方式也是可行的。实际上我们现在一个在做的项目，已经会有多个分离出来的 App 入口，还有后台的前端部分也分离出来了，对于我们来说在 webpack 配置文件里做好入口判断会清晰点。

Rails 里的 webpack 默认配置文件 shared.js，是会把 packs 文件夹下根目录 js 文件都当作 entry 打包，会导致不必要的 entry 重复打包的问题。这里可以手动指定一下自己的 entry，这样会大幅减少文件体积和提高打包速度。

example:

module.exports = {
  //手动指定两个入口
  entry: {
    'main': ["./app/javascript/packs/main"],
    'operate/main': ["./app/javascript/packs/operate/main"]
  },
  //下面是原来的配置
  //packPaths.reduce( 
    //(map, entry) => {
      //const localMap = map
      //const namespace = relative(join(paths.source, paths.entry), dirname(entry))
      //localMap[join(namespace, basename(entry, extname(entry)))] = resolve(entry)
      //return localMap
    //}, {}
  //),

  output: {
    filename: '[name].js',
    path: resolve(paths.output, paths.entry),
    publicPath
  },
........
}