Rails有自己的哲学（Rails Way），其一是 “约定优于配置”。——无规矩不成方圆，无原则乱作一团。
作为程序员，也作为理性人，写文章时也应该遵循一套自己的哲学吧。
以下是本站的“Railser Way”：
- 极简主义，重视效率和实用性：
遵循Rails的DRY（Don’t Repeat Yourself）理念，尽量复用代码，以及使用现成的、热门的第三方插件，而不是重新造轮子或设计新款轮子；配置也是越少越好。专心把时间精力花在最重要的事情——快乐地实现最大化产出这件上。 - 对同一主题提供3种深度的内容单元，重视阶段性、合理性：
文章配合以下3种典型的学习状态进行整理
①入门：新手入门用
②进阶：深入学习用
③重点整理：开发过程中回顾复习/作为速查手册用
为何要做③： 因为人通过阅读将信息编码成概念记入脑中，变成“反射”而“掌握”知识。如果之后缺少重复训练，则会随着时间流逝细节容易被遗忘，仅留下部分抽象概念融入潜意识。当需要重新使用这个知识时，如果再通过重新学习①与②就会显得低效，此时更高效的做法应该是避免再次从头学习，而是通过整理后的要点、常用命令、常用工具等经过整理的简洁内容③进行高效的记忆唤醒/重构。另外，开发时身旁若有速查手册则能大大缓解不安，增强自信，故做③以期提高效率。 - 1-3,3,10,30,30,300量化标准：
1主3副：
描述一件事物时，尽可能整理成/压缩到3个大要点/大分类/大部分。
３个方案：
实现某功能给出的可选方案最多3种。
心智资源很重要，人脑的缓存小，多数人很难在同一事物上记住3个以上的选择。
10条细节：
详细的叙述尽量控制在10条以内。再多就是反人类了。
３０分钟：
每个单元的预期作业量控制在30分钟以内。节奏很重要，人脑易疲劳，多数人很难坚持集中精力30分钟。（番茄工作法）
３０行代码：
实现一个小型功能的代码量尽量控制在30行以内，方便理解。
３００字描述：
单个内容单元（不是 页面）的文字量（不含代码，符号）尽量控制在300字以内。避免劝退很重要，大家都不喜欢读论文。 - 将文章的结论与重要参考资料置于文首，之后详细阐述逻辑。重视表达效率和易读性：
小学2年级时学的“总-分-总结构“的信息传递效率高，逻辑易整理，适合多数人的学习习惯。考虑本站性质，故以此为行文的标准流程。 - 优先GUI。重视易用性：
如果能熟练掌握命令行，确实能在许多操作上提高效率，但非计算机专业的普通人对GUI（图形化操作界面）更易上手。作为入门用资料，非必要时尽可能用GUI而少用命令行进行说明。 - 对比/区别事物时尽量将比较内容表格化：
避免长篇大论。若用表格能一目了然，则理所当然表格化之。
如“COOKIE和SESSION有什么区别？”的文章中应该先罗列出两者区别的表格，而非先用几千字描述。 - 生动举例：
好的故事能帮助理解和记忆。 - 割爱自动测试环节与文本日志（Log）:
Rails的自动测试与服务器运行日志固然对团队开发极其重要，但在新手入门阶段并非绝对必须，而是一种为符合标准的完善。
毕竟单人开发时需要一人掌握全局，此时自己手动测试才是更现实的方法；而Rails服务器的文本日志有些事无巨细，变得庞大后也较难管理，且本站推荐的PaaS对于文件的操作写入并不友好，故我推荐用DB做业务Log更合理。
所以就让我们把测试留到团队开发时，把文本日志留给Rails的默认功能吧。