起步吃亏在交流（日语）不通，领域优势确立后就很难追赶。

绝大部分开发者只会用别人做好的工具，少部分能参与贡献，极少数程序员能创造一个工具甚至一个生态，这极少数人对语言的推广作用是巨大的。远的有 Rails，近的有 Kimurai。

如果有意为 Ruby 做贡献，尝试从使用者往贡献者进阶，动动手。在 Ruby China 看到好几次抱怨 Ruby 的科学计算工具不完善，但没见一个提过自己有贡献的，这怎么追？

引用《提问的智慧》 https://ruby-china.org/topics/24325

---

RTFM 和 STFW：如何知道你已完全搞砸了

有一个古老而神圣的传统：如果你收到RTFM （Read The Fucking Manual）的回应，回答者认为你应该去读他妈的手册。当然，基本上他是对的，你应该去读一读。

RTFM 有一个年轻的亲戚。如果你收到STFW（Search The Fucking Web）的回应，回答者认为你应该到他妈的网上搜索过了。那人多半也是对的，去搜索一下吧。（更温和一点的说法是 Google 是你的朋友！）

在论坛，你也可能被要求去爬爬论坛的旧文。事实上，有人甚至可能热心地为你提供以前解决此问题的讨论串。但不要依赖这种关照，提问前应该先搜索一下旧文。

通常，用这两句之一回答你的人会给你一份包含你需要内容的手册或者一个网址，而且他们打这些字的时候也正在读着。这些答复意味着回答者认为

• 你需要的信息非常容易获得；
• 你自己去搜索这些信息比灌给你能让你学到更多。

你不应该因此不爽；依照黑客的标准，他已经表示了对你一定程度的关注，而没有对你的要求视而不见。你应该对他祖母般的慈祥表示感谢。

如果还是搞不懂

如果你看不懂回应，别立刻要求对方解释。像你以前试着自己解决问题时那样（利用手册，FAQ，网络，身边的高手），先试着去搞懂他的回应。如果你真的需要对方解释，记得表现出你已经从中学到了点什么。

比方说，如果我回答你：看来似乎是 zentry 卡住了；你应该先清除它。，然后，这是一个很糟的后续问题回应：zentry是什么？ 好的问法应该是这样：哦~~~我看过说明了但是只有 -z 和 -p 两个参数中提到了 zentries，而且还都没有清楚的解释如何清除它。你是指这两个中的哪一个吗？还是我看漏了什么？

处理无礼的回应

很多黑客圈子中看似无礼的行为并不是存心冒犯。相反，它是直接了当，一针见血式的交流风格，这种风格更注重解决问题，而不是使人感觉舒服而却模模糊糊。

如果你觉得被冒犯了，试着平静地反应。如果有人真的做了出格的事，邮件列表、新闻群组或论坛中的前辈多半会招呼他。如果这没有发生而你却发火了，那么你发火对象的言语可能在黑客社区中看起来是正常的，而你将被视为有错的一方，这将伤害到你获取信息或帮助的机会。

另一方面，你偶而真的会碰到无礼和无聊的言行。与上述相反，对真正的冒犯者狠狠地打击，用犀利的语言将其驳得体无完肤都是可以接受的。然而，在行事之前一定要非常非常的有根据。纠正无礼的言论与开始一场毫无意义的口水战仅一线之隔，黑客们自己莽撞地越线的情况并不鲜见。如果你是新手或外人，避开这种莽撞的机会并不高。如果你想得到的是信息而不是消磨时光，这时最好不要把手放在键盘上以免冒险。

（有些人断言很多黑客都有轻度的自闭症或亚斯伯格综合症，缺少用于润滑人类社会正常交往所需的神经。这既可能是真也可能是假的。如果你自己不是黑客，兴许你认为我们脑袋有问题还能帮助你应付我们的古怪行为。只管这么干好了，我们不在乎。我们喜欢我们现在这个样子，并且通常对病患标记都有站得住脚的怀疑。）

在下一节，我们会谈到另一个问题，当你行为不当时所会受到的冒犯。

如何避免扮演失败者

在黑客社区的论坛中有那么几次你可能会搞砸 -- 以本指南所描述到的或类似的方式。而你会在公开场合中被告知你是如何搞砸的，也许攻击的言语中还会带点夹七夹八的颜色。

这种事发生以后，你能做的最糟糕的事莫过于哀嚎你的遭遇、宣称被口头攻击、要求道歉、高声尖叫、憋闷气、威胁诉诸法律、向其雇主报怨、忘了关马桶盖等等。相反地，你该这么做：

熬过去，这很正常。事实上，它是有益健康且合理的。

社区的标准不会自行维持，它们是通过参与者积极而公开地执行来维持的。不要哭嚎所有的批评都应该通过私下的邮件传送，它不是这样运作的。当有人评论你的一个说法有误或者提出不同看法时，坚持声称受到个人攻击也毫无益处，这些都是失败者的态度。

也有其它的黑客论坛，受过高礼节要求的误导，禁止参与者张贴任何对别人帖子挑毛病的消息，并声称如果你不想帮助用户就闭嘴。 结果造成有想法的参与者纷纷离开，这么做只会使它们沦为毫无意义的嘮叨与无用的技术论坛。

夸张的讲法是：你要的是友善（以上述方式）还是有用？两个里面挑一个。

记着：当黑客说你搞砸了，并且（无论多么刺耳）告诉你别再这样做时，他正在为关心你和他的社区而行动。对他而言，不理你并将你从他的生活中滤掉更简单。如果你无法做到感谢，至少要表现地有点尊严，别大声哀嚎，也别因为自己是个有戏剧性超级敏感的灵魂和自以为有资格的新来者，就指望别人像对待脆弱的洋娃娃那样对你。

有时候，即使你没有搞砸（或者只是在他的想像中你搞砸了），有些人也会无缘无故地攻击你本人。在这种情况下，抱怨倒是真的会把问题搞砸。

这些来找麻烦的人要么是毫无办法但自以为是专家的不中用家伙，要么就是测试你是否真会搞砸的心理专家。其它读者要么不理睬，要么用自己的方式对付他们。这些来找麻烦的人在给他们自己找麻烦，这点你不用操心。

也别让自己卷入口水战，最好不要理睬大多数的口水战 -- 当然，是在你检验它们只是口水战，而并未指出你有搞砸的地方，且也没有巧妙地将问题真正的答案藏于其后（这也是有可能的）。

理解底层应该看这个
https://tools.ietf.org/html/rfc821
https://tools.ietf.org/html/rfc5321

https://smacss.com/
http://getbem.com/

参数解析的中间件位置在 routing 前面，还没到达 controller，所以 controller 里捕获不到这个异常。

我知道一个方法是在前面插入中间件，参考 https://robots.thoughtbot.com/catching-json-parse-errors-with-custom-middleware

我每次改都看不懂，已经放弃举不出例子。

我一直不建议用 devise。确实它开箱即用，能快速搭建一个 demo，但是向生产环境迈进的时候就要做大量修改（例如把模版 dump 到项目里修改），修改功能时要了解它非常复杂的内部构造，逐渐修改成本大于自己写的成本。等到发现的时候就已经尾大不掉，只能凑合了。

账号系统是功能核心，一开始就应该自己写。

一次性小文件就 send_data，跨请求就放云储存了。

前面加 CDN。

你要的是

每个客户的数据单独进行管理

而不是

每个客户的数据库单独进行管理

吧。

客户需要数据隔离就单独部署，不在乎就共用数据库。应用层不分单独分数据库有何意义。

要回到前一页有几种方法：

1. 逻辑判断 reportable 类型选择路由（回到顶楼问题)
2. 根据 referer 跳转（有时会有奇怪问题）
3. 既然是 modal，那么用 remote form，提交后关闭 modal 就行。

class Report
  # 安全原因，阻止用户提交预料外的东西
  validates :reportable_type, inclusion: { in: %w(Comment) }
end

new_reports_path(reportable_type: 'Comment', reportable_id: @comment.id)

def new
  @report = Report.new report_params
end

def create
  @report = Reports.new report_params.merge(reporter: current_user)
  if @report.save
    # ...
  else
    # ...
  end
end

private

def report_params
  params.require(:report).permit(:reportable_type, :reportable_id, :content, :radio_content)
end

<%= form_for @report do |f| %>
  <%= f.hidden_field :reportable_type %>
  <%= f.hidden_field :reportable_id %>
<% end %>

<%= form_for [@reportable,@report] do |f| %>

这里有错，根据这个参数 form 会推导两级的路由 comment_reports_path，但是路由里并没有这个路由，需要再加上 @question。

<%= form_for [@question, @reportable, @report] do |f| %>

但是这里可以看到，本来想多态关联 reportable 让 report 跟灵活，却不得不插入不相关的 question，灵活性受阻。

这里不应该用多级路由，而是一级的 report 路由：

resources :reports

把 reportable_type 和 reportable_id 作为参数传。

https://github.com/github/dmca/tree/master/2018

GitHub DMCA 没有记录，应该是作者自己删的。

我靠。

日志贴全。

彩程那个之前大概半年没更新，也有一些 bug 直接用跑不通，后来提交 issue 之后就更新了。

代码上我觉得彩程那个功能更专一，assets 我是通过 CDN 回源处理的，不需要扩展 sprokets。

因为他们前端没用 activestorage.js 而是自己实现，所以 dicret_upload 不能直接用，我想仿照你的实现给他们提个 pr。

有个问题，你的实现是更改了原先的 xhr 还是另外发起一个，原先的 xhr 会重复发送吗？

这个 gem 相比 https://github.com/mycolorway/activestorage_qiniu/ 的优势是什么？

是的，我也试试这个方法。

先把这个语法错误改了：

# wrong
class User < ApplicationRecord
  has_many :microposts
  validates name, presence: true 
  validates email, presence: true 
end

# right
class User < ApplicationRecord
  has_many :microposts
  validates :name, presence: true 
  validates :email, presence: true 
end

can't activate mysql2 (< 0.6.0, >= 0.4.4), already activated mysql2-0.3.21

版本不符合要求，bundle update mysql2 。

然后呢？什么错？

去掉 activerecord-mysql2-adapter 了没。

用这个 gem activerecord-mysql2-adapter 做啥？

https://github.com/kronn/activerecord-mysql2-adapter

6 年没更新了，看来只是 ActiveRecord 没支持 mysql2 之前的过度 gem，应该会产生冲突。

我对这个特性不太感兴趣，一来自己的项目通过命名规范隔离已经足够，二来避免使用污染全局空间的库。ActiveSupport 是个特例，它是 Rails 的依赖不得不用，用起来也感觉良好。Rails 不用每个文件写一堆 import 也是它的优点。

最近用 ActiveStorage 的时候处理 js 端时发现问题，七牛的 js 上传逻辑跟 activestorage.js 里的不一样需要改写，但是这个包经过 ES6 的规范化打包之后，外部完全动不了里面的逻辑。本来只是改写一个方法可以搞定了，结果不得不把整个 js dump 到项目里改写。我还没想好怎么提 pr 让 activestorage.js 提供接口定制不同 service 的上传逻辑。

所以有了包的概念以后又不得不考虑怎么方便的问题了。

艹

用 Protocol Buffer 就上 gRPC https://grpc.io/

是不是个人屏蔽了一些用户。

别管 Gemset，被 Bundler 替代了。