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

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

如果你只想判断结尾的扩展名，并且通过字符串操作而不是构造个 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 代码风格，尽量不要学他的写法。

http://guides.rubyonrails.org/active_record_validations.html#on

validate 可以传递 context

没参与 tower 项目，理论上就是个异步任务指定时间检查状态，然后执行一些逻辑而已

嗯，有道理，搞个这东西来...

RM 跳源码比较准了...阅读代码的神器，另外，构建类和模型的关系图也很好用，其他的功能我到都觉得鸡肋了...重构啥的预览看漏很容易搞出问题来

就是 public/uploads 目录存在？

现在 GoRails 继承了衣钵，不过感觉更初级一些，有一些视频其实有更好的做法

你确定 uploads 存在于那个路径？

@darkbaby123 有个问题...你们是怎么给表单里每项做标识的？就是字段名怎么取？

我是支持那文作者观点的...不过写 Current 的人大有人在，官方提供个版本防止他们写不好出出错吧

Rails 的 Session 还可以以 JSON 形式存在的 http://blog.bigbinary.com/2014/12/23/migrating-existing-session-cookies-while-upgrading-to-rails-4-1-and-above.html Rails 4.1 后这样是默认了

好东西。。。能正确写出线程安全的 Current 也不容易...

他们也是最近才有沙箱的。。。过去别无选择的

Matias

nnd 出去玩电脑报废了，回到家台机键盘报废了...

这个需要的话...我一般的做法两种，一种 puts 'yoooo' 另一种，下个断点，执行到了卡住，需要继续执行 continue 就可以了...

和微信互操作的部分肉测吧（直接放线上环境测，有条件开个测试用的站点和公众号、开放平台 etc），效率反而高...

我估计是说在 rails 里 raise 后，调出的 500 错误页面上的调试器吧...

欢迎投稿分享～

cc @danielglh