只能说薄荷的团队氛围适合快速成长，不太适合养老，没有必要放大其管理上的不足。我于 15 年从薄荷离职，谈谈我的体验，不水也不黑。

加班

当时在薄荷的时候有项制度是绩效考核的时候会参考根据打卡记录得来的在司时长，一般这种事情老板私底下看看没啥，拿出来说确实让人很不爽。我的做法是下班没啥事的时候，就在公司刷刷时长，借加班的时间提升自己的技术。相信大多数技术 leader 对于你的自我提升是持鼓励态度的。#15 楼的观点，公司故意用加班消耗你的时间让你无法成长，我认为是有点阴谋论的。就算公司高层有这种出发点，你想提升自己是没有人能够阻拦你的。

技术氛围

薄荷的优点是技术部门会鼓励大家的成长，有两件事，我是从薄荷得到了很大受益的。

1. 每周要求大家一篇技术博客；
2. 每周二会组织大家做内部技术分享；

这两个举措，我在后面的每个团队都在照搬，效果很不错。会把不愿意成长的队员淘汰出去。不知道现在的薄荷还在执行这两个事情没。

技术 leader 的担当

有段时间我没事干了，我就自发的把薄荷的应用进行了 Rails 的大版本升级。在 dev 环境测试啥毛病没有，上了生产环境就把系统整挂了，薄荷的用户量很大，这个是个很大的事故，这个事故也超出了我当时的能力范围，不过 @vincent 没有半个怨字，还让我早早下班了，自己和运维的同事整了一整个通宵才恢复。这种不苛责的文化，我认为对于技术人员的成长是至关重要的，会让员工大胆的去干，不至于畏首畏尾。

综上，我觉得对于主动追求成长的程序员来说，不在意一些小节的话，去薄荷仍不失是个不错的选择。

ruby 中有很多语法糖，在不同的场景下会让可读性大幅提升，后缀条件表达式，在某些场景下可读性很高。如：

class CacheList < ApplicationRecord
  include RailsCom::CacheList
end unless defined? CacheList

题主的示例，太长了，就有点乱用了

最近在深圳出差

靠谱，为数不多的坚持四五年都在招人的团队。

比较随机，看有没有人组织了。

Action 系和 core 系～

我们的愿望是能够在 ruby 圈子外形成一波影响力

之前是我个人顺带着积累，现在属于 @dao42 旗下，接下来的发展速度会比较快，会补上文档和测试方面的缺口。

def say(obj = self)
  obj.to_s
end

期待你们的开源。 我们也一直在基于 Engine 的组件化方面做积极探索：https://github.com/work-design 希望可以交流交流。

申请加精

不过 404 Subscribe/notification 处理不到，在路由解析那里就抛出错了。

不过我这个 gem 里也对 404 做了专门处理。

if RailsLog.config.intercept_not_found
  Rails.application.routes.append do
    match '*path' => 'log/rails_log#not_found', via: :all
  end
end

把所有的 404 都指向 一个 controller/action ,

参见我的 gem https://github.com/work-design/rails_log

具体代码在： https://github.com/work-design/rails_log/blob/master/lib/rails_log/controller_subscriber.rb

上不了就换 DNS

从 3.2 的 custom 版本直接干到 6.0，让人感动，终于团结起来了~

这个不通用，只适合你本地环境

最大的难点是对 yml 文件的解析和写入，YAML 库的文档和接口都不太友好，为了整这个把 Psych 的源码翻了一遍。 除了备注和空行不支持，各种格式的 yml 格式都可以兼容了～

关于 engine 与 webpacker 的使用，我最近实践出了一个比较好的方案。https://ruby-china.org/topics/39025

目前 webpacker 最大的缺陷就是 不能像 assets pipeline 那样便捷使用 engine 里的 js/css 文件，官方给的方案也麻烦的很。

https://github.com/rails/webpacker/blob/master/docs/engines.md

用代码不全，而不依赖代码不全~

远程 + 工作 6 天，我觉得还是可以接受。 每年都来招人的成长型企业还是比较靠谱。

建议加上引用链接。

不得不说还是薄荷的招聘写的比较有水平~

webpacker 目前最大的问题 是 对于 engine 里的 assets 处理起来不方便，这方便有好的实践么？

降级按钮在页面最下面，找了半天。

我觉得没必要杠，并非都是套路，程序员水平确实是有高低不齐不是。作为一名常换工作的 ruby 程序员表示，基本都是可以争取到范围的中位数往上的。

ruby 3.0 x 3

https://github.com/ianstormtaylor/slate 认为 slate 才是心目中的完美的富文本编辑器

我调试的时候明确看了请求是不会重复提交之前的 xhr 的。

1. bug 比它少，不过我写的可能也挺多 bug，毕竟测试代码几乎没有，但是确切的修复了几个彩程这个 gem 现存的 bug。
2. 支持 QiniuHelper 独立的简单使用；
3. 支持同步静态资源文件到七牛，扩展了Sprockets；
4. 支持 直传（direct_upload）到七牛服务器，彩程设计的 就不支持；

本来我是写这个 gem 比彩程早的，后来准备上传到 gems 服务器，发现彩程已经先我一步了就改名为 qiniu_rails 了。

彩程毕竟是个公司，可能让人觉得更可信赖一些。我写的这个也依然在公司生产环境使用稳定。