久闻 Ruby on Rails scales from HELLO WORLD to IPO，虽然今天的互联网爆款应用出现得越来越少， 听说 Ruby 程序员不好找工作（以前在 社区 上看的），技术栈杂而不精的我很有兴趣学习 Rails 这个 古老 却拥有 蓬勃生命力 的 MVC Web 框架。
昨天分两口气看完 Meta Discourse 社区上的 主题初学者指南 [1] 和 插件开发初学者教程 [2]。
Discourse 实际上在 Rails 框架和 Ember.js 之上，又把很多功能包装了一下，提供 ruby 和 js 两侧的 API；页面布局采用结构化设计，分割和包装成 outlet 和 widget 供插件和主题开发者灵活运用。
但光学开发 Discourse 插件不能替代 Rails 的学习（听说有 Qt 写多了的人反倒不会常规 C++ 编码）。今天看了 Rails doctrine（ Rails 信条），感受到什么是为开发者着想的高质量软件设计，对于一个 04 年释出源码的框架这非常难能可贵。（相比之下，Unity 的软件使用起来容易让人抓狂，比如每次改完源码切回 Editor 和进入 play mode 前及秒钟的 reloading domain、界面缩放、包管理器，给人的感觉就是 Unity 的开发者自己不用Unity；而 Rails 的主要开发者 DHH 不仅是赛车手，自己用 Rails 做了 Basecamp & HEY；这就有点像 GTK 最初是 GIMP 的专用开发库（GIMP Toolkit），后来发展为 Unix-like 系统下开发 图形界面 的应用程序的主流开发工具之一）。
（我高度怀疑自己有 ADHD，所以经常 blabbering。）
闲话少说，下面就来摘抄一些 Rails Doctrine：
程序员的幸福最大化
是 Ruby 造就了 Rails，所以第一条信条便是从创造 Ruby 的核心理念所提炼出來。
早期 Ruby 的极端邪说就是把程序员的幸福度放到第一位。还把追求幸福置于驱动编程语言与生态圈前进的考量之上。
Ruby 很看重函数式编程，消除控制流，写出来的代码很优美。学习了这类语言之后，再看在嵌入式领域大量使用的 C 的代码，感觉简丑陋异常、不忍直视。
约定优于配置
早期 Rails 的生产力座右铭是：“你不是独一无二的，大家都一样”。只要放下了自负的个人喜好，便可以跳过无谓的世俗决定，专注在最重要的地方下更快的决定。
有人在乎你的数据库主键命名用什么格式吗？用
id、postID、posts_id或pid真的有差别吗？这真的是值得反复讨论的吗？不！Rails 的部分使命就是，帮助开发者在日渐复杂庞大的 Web 应用程序决策丛林中劈荆斩棘。几千个无谓的决定只需要做一次，而若是别人帮你做这些决定，那就更好了。
…
主厨精选…
所以 Rails 我们根据大局考虑，把选择减少到一套好的工具，让每个工程师可以从中挑选：一套为了大家好的工具。好处如下：
- 分散风险：当大家都用预设的方式来使用 Rails，我们有共同的体验。这个共同基础让我们可以容易指导和帮助新人，大家有讨论的共同基础。就好比大家昨晚七点都看了某个节目，所以明天大家都有共同话题可以谈论。进而培养出更有凝聚力的社区。
- 大家熟练使用相同的工具：身为一个全栈的框架，Rails 有很多可以移动的组件，这些组件之间如何协调工作？如何独立工作？两者同样重要。多数的软件开发者的痛苦不是来自于独立的组件，而是组件之间的互通。当我们用同样的方式来使用这些组件，相同的配置便可以得出相同的错误，则大家受的苦便减少了。
我感觉这是 Rails 能做到from HELLO WORLD to IPO的原因之一，很多应用无非都是 CRUD，很多代码都差不多的。
进步比稳定重要
当一个系统已经存在超过 10 年，比如 Rails，自然会慢慢僵化。每一处的修改，都有百万种理由可能会变成别人的困扰，或是有人仍需要旧的行为。这对他们来说都是合理的理由。
但若我们太仔细听取保守派的意见，我们将永远不知道另一边的声音是什么。我们需要勇敢地做出改变，打破陈规，然后才可以茁壮演化。正是这样的演变，才让 Rails 存活下来，并可能继续繁荣发展（数）十年。
这些理论上都很简单，但实际做起来却很困难。特别是你的应用因为升级大版本的 Rails 时，因为有不兼容的变更而坏掉了。正是此时，我们珍重［进步比稳定更重要］的价值观，这个价值观给我们力量来搞定升级，搞清楚为什么并与时俱进。
但这不代表我们就可以加入不需要的功能，或是胡来把别人的应用搞坏了。Rails 2 升到 3 的迁移噩梦，仍在经历过的人身上阴魂不散。那真的是很艰难的决定。修改太大使得许多人停滞在 Rails 2.x 无法前进，有些人更是讨厌至极。可我们从大局来看，这件事仍然是值得的选择。
…
最终进步的是人，以及人们乐意做出改变。这也是为什么，像 Rails Core 或 Rails Committers 这样的团队里没有终身职位。这两个团队是给活跃的，致力于带动框架进步的那群人而设定。对某些人来说，可能就几年，但我们永远感激他们做出的贡献，这些贡献可能将持续影响我们几十年。
说起进步比稳定重要，我想起了 Arch 发行版的 交流社区（BBS） 至今仍然用 自从 2021 年就停止维护的 FluxBB，迁移到 Discourse 的工作从 May 2023 至今没有看到进展。（RedHat 赞助的发行版就好得多，比如 Fedora 有 Discourse 官方社区：https://discussion.fedoraproject.org/ ）。
作为一个滚动更新的、在软件新版本上最激进的发行版，Arch 的软件基础设施有点太老旧了。即使去年将 bug tracker 从 flyspray 迁移到自建 GitLab，官方软件包的 PKGBUILD 也统一到 GitLab，用户打包的软件包 PKDBUILD 分享平台（AUR）的 aurwebN 多年没什么功能和界面的变化了，bbs 用的软件 fluxbb 3 年前就没人维护了（还是 php 写的，想必有很多漏洞吧），Arch Wiki、AUR、官方软件仓库的 GitLab 这几个的用户系统仍然互相独立，不仅如此，GitLab 更是由于 “influx of spam” 而停止公开注册，要新账号还要发邮件人工审核 
：（好在可以用 GitHub SSO）
然而 Arch Wiki 万年不变地采用
pacman -V|base32|head -1 验证方式都没遭到"influx of spam"而停止公开注册。
（这里再次证明了我是 ADHD 患者 
）
教程太长，看到 decorateWidget 差点放弃了。还是应该有选择性的看，简单的地方看快，重要的和过于复杂的地方用 Textmarker 插件标记出来以后再看。 ↩︎
eviltrout 很贴心的分成了 7 部分，看起来舒服多了；也是因为主题开发涉及到很多 Ember.js，相当的复杂，看来是我以前小瞧了前端开发。（浏览器内核的复杂度不亚于作业系统内核） ↩︎
前几天在上海逛街逛到虚脱了