另外我不知道你英语不好，你我完全不相识，而是当我看到你完全误读了 Linus 的话，让我知道你可能英文不是很好。

本来我是不想说啥的，但既然你崇拜 Linus，我就把 Linus 的观点分享给你，并且，我告诉你 Linus 恰好批评你的观点，我不知道你会怎么想。

如果你说我欺负你英文不好，那你大可亲自去了解清楚我刚发的截图的讨论过程，然后用实证说出来：我欺负你了，我不友善。

无论怎样，我还是要引用我引用的知乎某个回答的一段话：

她一方面强迫他人去理解和接受她的"世界“，一方面又关闭了交流的门，想想看她应该把“己所不欲，勿施于人”理解为单方面让别人去适应自己，而并没有尊重别人的想法，反而认为别人如果想法跟她不一样，就是别人的不对。

我就是把截图里的 linus 的回复，直接翻译成中文而已，不信你自己敲到 google translate 里看看

你自己把截图里那段话，放到翻译软件里看看他在批评什么。

何况你这样说是伤害到很多一直热心社区人的心的，我们解答问题，分析知识，封装 gem，现在有个人跳出来，我觉得你们对新手不友好。

你说一直在做这件事的人什么感受？我们在做这事的时候，你在做什么？你凭什么这么说？

何况 Linus 另一句经典名言了：Talk is cheap, show me the code.

与其指挥大伙你们应该怎样，不妨身体力行，用自己的行动鼓舞大家加入到你的事业，亲自帮助到一些人，让别人在其他人面前说出：这个人，感谢他。

你帮助到的人有几个捡起你的衣钵，薪火就传下去了，这是一笔投资。你可以看到，慈善的逻辑，就是这样。

你的英语不太过关，linus 说的跟代码没有关系

他吐槽的是 default m 那一句啊，意思是提交者希望默认启动他的驱动。

直接翻译 Linus 的话：

每个开发者都认为他们的代码是特别的、精巧的以致于应该被默认启用。

但抱有这想法的大多数人都是完全的彻底的错了。

我想引申一下：

每个人都觉得自己的想法或者建议是有益的、可行的以致于大家应该听从。

但抱有这想法的大多数人都是完全的彻底的错了。

然而 linus 大神刚怼了楼主的想法...

和知乎这个问题性质很像 https://www.zhihu.com/question/61965164/answer/194639348?utm_medium=social&utm_source=wechat_session&from=groupmessage&isappinstalled=1

yarn 可以替代过去把前端的依赖放到 vendor 的作用

支持一下！

一般包含进来，另外包不包含，也要合理的在 Gemfile 里约束好依赖的版本

完全可以理解这种想法。

在我的立场上，这些年我在编程上有了一点心得，也渴望交流，我愿意帮助新人们成长，加入到我们这些所谓的”老炮“行列中，我想大家认为的”高手“也是这个态度。

我不知道你会不会有这个想法：我是新人，很多东西不知道，需要高手手把手教教我，这样我进步才会快。

但是”高手“的想法是：教给你方法，点到为止，你进步才能快。

首先，冲突就产生了，这帖子里的一些讨论就是例子。

其次，新手成长的速度也拉开了，看一下知乎那边 叛逆者 回答的一个问题的答案 如何评价空明流转？

至于语言不友善，这个其实在 提问的智慧 里，有阐述，如果让我总结：

如果希望别人伸出援手，最好的方法是表现出”我尽力了，但我还是失败了“，文字上说”我找了百度，看了文档“并不有力，而是要通过 "我在做什么 -> 我怎么理解这个问题的 -> 我在哪搜索了哪些关键字 -> 我考察了哪些方案（但不奏效）-> 以上是我所尝试过的，请帮忙看看我是不是漏掉了什么？" 这是解决一个问题你的思考路径的整理，这是你真诚想解决问题顺便帮助他人的证据，这是值得得到一个优秀回答的请帖，这个帖子和讨论会成为其他后人的范本（就是 wiki）。

至于成立社区管理委员、明确社区发展导向，其实这个东西现在就有，很多老的会员还在坚持参与讨论的人，都承担了这个角色，他们的言行（无论好的坏的），都引导了发展导向。即使我们真的要成立一个委员会，那么，哪些人可以加入呢？他们加入能否服众？这又是个问题。

不加 Gemfile 的话，可以质疑你这个同事关于依赖管理的基本素养了，不夸张。

为了更好的协同开发，要求同事间的开发环境尽可能的一致这个也是强烈建议项（甚至强烈建议开发环境跟生产环境一致），某些 Gem 会在 Gemfile.lock 里标记一些平台要求的信息，这会在某些情况下，你的同事有混杂使用不同 OS，bundle 失败，所以包不包含 Gemfile.lock 倒是一个没有结论的问题，看需要。

另外，对于某个 Gem 的卡住安装这种，显然的，这位同事应该自己解决自己的环境问题（写 Rails 项目不想装 Rails 这个怎么讲都说不过去的），但是，实际上 bundler 还真可以做到不安装某些 Gem 的。

这个功能在我不知道该去哪读那该死的文档呢？

看一段 Capistrano 的输出：

00:15 bundler:install
      01 ~/.rvm/bin/rvm default do bundle install --path /home/jasl/sites/lab/shared/bundle --jobs 3 --without development test --deployment --quiet

注意 --without 后边的两个实参是 development test，对应 Rails 的 Gemfile 里的 development 和 test group，所以，你只需要吧 spring 单独放到一个 group 里

group :spring do
  gem 'spring'
end

然后

bundle install --without spring 即可了，这个手法 Redmine 就在用 https://github.com/redmine/redmine/blob/master/Gemfile#L42-L45 用来解决一些对环境有依赖的可选功能，另外他们那边也有讨论（我现搜的） http://www.redmine.org/boards/2/topics/29070。

PS，spring 会 wrap 一些 gem 的 binstub（就是项目目录 bin 下的那些命令），不安装 spring 的话使用某些命令调用会失败。

没权限就给他权限不就行了么。。。

马上，这周有点工作调度，忙得焦头烂额，下周~

这是一个近距离接触大牛的机会，内容其实国内的会议更偏工程，实用性强的。

不知道...开始没认真读正文。

我也不太能理解一个可以很直觉的解决的问题为啥要用这么深奥的算法来解决...

如果你只想判断结尾的扩展名，并且通过字符串操作而不是构造个 File 对象啥的

[1] pry(main)> "yooo.erl".end_with?(".erl")
=> true
[2] pry(main)> "yooo.erl".end_with?(".rb")
=> false

最后调用下一 to_h 试试

走之前就偶尔充不上电了... 到日本我发现玩 wow 的时候电脑会充电（好奇怪的设定...），然后充电只能靠猛玩 wow... 结果有一天没注意电量，搞到强制关机了... 回天乏术，回北京后苹果店直接给换了主板...

Migration 就是迁移的意思，这个机制在很多 web 程序和框架上很常见了。

一个朴素的 Migration 可以这样做：

• 为了功能 A，你需要为数据库增加新的表，于是将创建表格的 SQL 保存在 create_table_for_a.sql （文件名我随意取的）中，当 A 上线时，在数据库执行这个脚本
• 接着功能 B 也要做对数据库做改动，仿照做功能 A 时候的方法，创建了文件 sql_for_b.sql，并且在上线时，在数据库执行
• 继续同理...故略

随着项目的迭代，可以得到一组 SQL 文件，需要部署到新的环境的时候，只需要按照文件的顺序，依次执行即可。

以上就是最原始的做法，你可以在著名的基于 Java 技术的工作流引擎 Activiti 中看到 https://github.com/Activiti/Activiti/tree/master/activiti-engine/src/main/resources/org/activiti/db/upgrade 。

Rails 的 Migration 更先进，额外实现了如下特性：

• 实现了一组 Ruby 的 DSL，意味着你可以通过 Ruby 代码做 SQL 做的事情（主要是创建、修改、删除表和索引），这样使得（通常情况下）迁移脚本和具体数据库软件解耦，对比上文举的 Activiti 的例子，它为每一种它支持的数据库分别实现一遍 Migration SQL
• 可以调用项目中的模型，更方便的进行数据的更改。
• 标准化了数据迁移脚本的格式，使得不仅可以正向的迁移，程序发版有问题需要回滚的时候，可以回滚数据迁移
• 在数据库中增加了额外的迁移记录表，方便追踪迁移的执行，保证迁移不会重复执行，不是全新的数据库时 Rails 可以知道应当从哪条迁移脚本开始继续
• 约束了迁移脚本的格式（默认格式 时间戳_文件名.rb）解决了数据迁移的先后顺序问题
• 自动生成当前版本数据库表结构的快照（即“schema.rb"），于是可以实现快速部署到全新环境的数据库而无需依次执行迁移脚本，对比上文举的 Activiti 的例子，他（为每种它支持的数据库）单独提供一份最新版本的数据库的 SQL 用作全新环境的安装
• 提供了便捷的 rake task 去执行迁移、回滚、复位、创建、删除等迁移操作

你发的应该过时了，那篇文章的发布时间是 09 年，文中的命令行还是 Rails 2 的风格，现在几个在维护的 Redmine 版本在使用 Rails 4.2

厉害了 word 哥...

homeland 的历史包袱也挺多的，比如关注用户这块还是 mongodb 的设计（现在重构没有不道）

redmine 完全没用 assets pipeline、strong parameter 这些已经出现四五年的成熟技术，attr_accessible 都还是自己造的轮子，毕竟是从 rails 2.x 时代发展上来的

怎么样写成好的代码大概就是经验吧，不过即使明白怎么写好，工作时候因为进度压力、重要性不足，也胡搞了...

代码差不代表你不能了解他的思路，要是你好奇某个软件/库的某个功能是如何实现的，就读读看嘛，闭源的一样可以逆向的。

好看的代码大多存在于没什么人用的程序里吧。

Gitlab 和 Redmine 不是一种东西嘛...

从页面入手吧，先确定你的工作涉及到哪个（些）页面，简单的办法是浏览器打开到对应功能的页面去，看 URL，利用 Rails 的 Convention（这个算必须清楚的）看看能不能定位到对应的控制器和 action 上去，如果不能就去路由定义里找。

然后看 action 和相关的过滤器的实现，找到相关的模型，关注好模型间的联系（has_many、belongs_to 那些）还有各种钩子（before_save 那些，关注这个是留意在 hook 里的数据操作，避免踩坑）

然后搞你的功能就是了，上边的调研告诉了你要把新功能放到哪个控制器（或者是需要新建一个新的，但是控制器里的很多代码可以复制相关的控制器里的）。以及需要扩展哪些模型，模型里放业务逻辑和对字段的改动都是围绕数据来进行的，所以你只要保证你新的代码执行后对数据造成的改动是你在设计时预期的的就可以了

接手一个系统的时候，在不熟悉这套系统的时候，尽量不要对已有的业务逻辑进行改动，就是说，在适当的位置插入新的逻辑，尽可能避免修改已有的代码的执行逻辑，把对系统的改动的范围控制在你的新代码里，这样出问题你也更能解决（毕竟出问题肯定是你的新业务逻辑）。另外，小步走，多提交，每次提交的改动尽量小。

Redmine 总体来讲，还是上世纪的 Ruby 代码风格，尽量不要学他的写法。