预定个主题大会上说好了

所有的 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 文档里有的

对的

两天 54 回复了... 很多都不是长出来发帖的同学... 所以... 没有衰退...

我用过蓝牙版有一年时间，没有问题，不过蓝牙版的手感和有线的不一样，不太喜欢。

蓝牙键鼠不稳定应该是 macOS 的锅，除了官方那一系列，其他牌子的都会一定程度有问题，另外 W1 芯片的蓝牙耳机也有很影响使用的问题... 在 Mac 上装 Win 都没那些事的

个人习惯嘛... 我喜欢的 Tactile Pro 跟静电容的手感基本相反的... 而且 Matias 一把不到 700，超便宜呀，87U 1799... 我还有一把 104UG-HiPro 2400 多...

有把 87u 纯看造型复古入的，比 hhkb 看着正常点，1700 多，用一阵觉得不喜欢静电容的手感

然后还要去掉 Null...

一种可能性而已... 心理素质不佳也算减分项呀

噗 楼上有位去人多的聚会就会😂

环境不同，紧张，临场发挥失常

和求职者心理素质也有关系

不知道要怎么说了。。。 @kgen 对这种事怎么交涉有啥经验么...