sorry 我也没仔细去看 SO 的答案，这个我之前也没注意过的

你的 Ruby 版本是多少？是否方便试试升级到 2.4.1 （对正则引擎有了一些改动）

我用你的样本（MRI 2.4.1）没有复现出来的。

[1] pry(main)> foo = '你好'
=> "你好"
[2] pry(main)> regex = /#{foo}/
=> /你好/
[3] pry(main)> Regexp.new foo
=> /你好/

http://stackoverflow.com/questions/28630936/what-is-mix-in-a-ruby-regular-expression/34026971

给你和 @huacnlee 预定好今年的大会的主题分享了啊！

其实我也是觉得自己什么都能干（最近学了个名词叫面向工资编程...），也自我感觉基础知识不扎实。

但我属于运气好的，没有为工作发愁过。我觉得关键因素（不谦虚的讲）是有能够证明自己的东西，比如给 Rails 贡献点代码，（前）Doorkeeper 项目成员，组织 RubyConf 和一些线下活动...在各种社区刷脸、在公司同事面前树立威望等等...

当然，既然评估自己基础知识不扎实，那想办法补足也是跨越的一个必须过程啦

所以之前我有回复薪资真的是运气问题，据我所知很多大牛的收入并不匹配他们的能力的，知足就好~

本科啥都不会还能找到 10k 美金的（Amazon，而且面试难度还不如国内培训班的水平），国内我面试过的啥都不会的找到 12k、15k 的也有几个...

这个是 macOS 的系统控件吧...改不了

薪资问题也是行业挺广泛的问题了，听过程序员薪资高报班培训出来找到工作薪水上万确实是有的，应届生张嘴就要 15k 但水平很差却最后要到理想薪水的也很多，就算是这圈子里，私下吐槽 xxx 很水的其实不值那么多钱的八卦讨论也很多的。

只谈现状，薪资有一定运气成分的，看开一些。

和 https://github.com/diaspora/diaspora 有啥差别？

说到这个... 引申一下 如果想从字典里取值，如果没有值则使用默认值，千万不要用 hash[:key] || 'yoooo~' 的写法，如果 hash[:key] 有值且为 false，那么表达式的结果则为 yoooo~，要用 hash.fetch(:key, 'yoooo~') 的方式来做

预定个主题大会上说好了

所有的 helper 包括前端 gem，最终的目标都是生成 HTML，显示成什么样子是由最终生成的 HTML 是什么样子决定的

虽然这里可以说确实是你 bootstrap 版本高了，但这个结论不需要通过经验，通过页面 HTML 源码对照 Bootstrap 的文档就可以得出来

H1B 新规则出来之后，知乎上有很多科普，提到美国定义的 Programmer 就是外包公司的那种照文档翻译成代码的基层码农...

这个问题你要换个思路 你提到 pc 端可以正常下载，说明你用对了的，但是移动端不 OK（看你提供的文件名是要在 Android 下搞）。 通过文档可以知道，send_file 其实是会为响应头增加 Content-Disposition 段，attachment 其实就是字段的值（其实这也算是 HTTP 方向的基础知识啦）。

那么问题就要转化成，Android 的浏览器对于Content-Disposition 为 attachment 的处理是否有坑？ 于是 Google 的关键词就有了：android browser Content-Disposition attachment 没错，只是把一堆关键字罗列一下

可以看到很多相关结果，如：

• http://www.digiblog.de/2011/04/android-and-the-download-file-headers/
• https://code.google.com/p/android/issues/detail?id=11422
• http://stackoverflow.com/questions/3992981/android-browser-webview-bug-content-disposition-attachment-filename-xyz-txt
• 等等等等

于是....

其实关键就是

def devise_mail(record, action, opts = {}, &block)
  initialize_from_record(record)
  mail headers_for(action, opts), &block
end

最后调用的是 mail 方法，是 ActionMailer 的东西（Devise 啰嗦那么多就是不想和项目的 Mailer 代码绑定），然后提出了 send_devise_notification(notification, *args) 接口，所以核心逻辑就是帮 Devise 去用 ActiveJob 对 Mailer 的强化为发送邮件异步化...

可以试试 bin/spring stop 的 这种情况可能是 spring 搞得鬼

你要有一定编程经验的话，可以读读 CollectionProxy 的源码，大概浏览一下就知道他想干啥了，实现比较复杂，但是意图很明显的

没看懂你说的。。。

简单解释下 Relation 的价值，另外你可能还会看到一个叫做 CollectionProxy 的类型（user.posts 这种类似调用会遇到），他是 Relation 的子类。

Relation 实现了 Enumerable，所以你做遍历之类的集合操作是 OK 的，另外，其实在你真正需要使用数据前，还没有进行查询呢，这种手法叫做 lazy_evolution，就是延迟计算。

想象一条查询 Post.where(author: me).page(2).per_page(10) 我的意图是获取我发表的帖子中位于第二页的，如果没有 Relation 每次调用都会返回结果集，那么就要意味着进行 SQL 查询，这里就有问题，首先明确一点，IO 的代价是极大的，SQL 查询是一个网络 IO 操作，通常是性能的瓶颈所在，其次，这个中间结果我们并不需要。那么，我们就需要一种手段，来避免这种中间过程的产生，这就是 Relation 的价值。

此外，ORM 有一种经典问题要避免，即 N+1，想象 user.posts.map { |post| post.title }，从代码上看，我需要的是每一条 post，于是就产生了 N+1 问题（查询 user 为一次查询，之后发出等同于 posts 数量的查询来获取每条 post 的数据），Relation 来持有 eager_load 的信息，保证绝大情况下避免 N+1 的情况（当然需要你来手动指出）。

另外这里引申一点，Ruby 标准库的集合操作都是不支持延迟计算的，于是会导致大量中间变量的创建，这其实隐含了性能瓶颈。

rvm 管理就好了，系统的不要动，另外 rvm 有个很好玩的命令 rvm disk-usage all 比如我这里，我这里因为项目原因有三个 ruby，2.3.1, 2.4.0, 2.4.1 结果为

  Downloaded Archives Usage: 1.2M
         Repositories Usage: 0B
Extracted Source Code Usage: 5.2M
            Log Files Usage: 12K
             Packages Usage: 0B
               Rubies Usage: 105M
              Gemsets Usage: 4.3G
             Wrappers Usage: 24K
      Temporary Files Usage: 0B
          Other Files Usage: 5.1M
           Total Disk Usage: 4.4G

可见 Ruby 不占什么地方的，真正的大头是 Gem

听说武汉那边上班还有午睡的传统。。。

另外，Ruby 虽然一直没有在类型系统上做太多改进（社区的做法是在 rdoc 里注明），但是对于更明确的函数签名，这是做过改进的，比如常见的边长参数用法 def foo(a, b, options = {})，而后改进支持 named arguments 后，很多方法都可以以更明确的方式定义

鸭子类型这是 Matz 当初的取舍，Matz 选择信任开发者，那就只能靠同事不坑了...

个人观点：各种语言特性都不是必须品，语言的不足最后都会以最佳实践、设计模式的方式弥补。至于现在流行函数式、显式类型，我觉得是个时尚问题

Ruby 自己除了等 Matz 那个 soft type，现在可以通过 dry-types 加编码规范来做到一定的类型约束，但是这个风格跟 Ruby 主流的风格冲突太大了

用 RubyMine 在 Project 导航里找 Libraries 就有了嘛。。。还能临时性的修改下源码

看你干什么了，已经执行到 rack 层就很靠后了，比较普遍的使用 hook 的需求是类似重载 Gemfile、强制 AR 打开、关闭连接等操作，也都是通用需求（涉及热重启还有 CoW 优化），但必须在 Web 容器这层来做

puma 文档里有的

对的