没有Ruby就没有Rails，所以第一个理论支柱直接从创建Ruby的核心动机出发是合适的。
Ruby最初的异端邪说实际上是把程序员的幸福放在一个基座上。除此之外，还有许多其他相互竞争且有效的问题，这些问题在它出现之前就已经驱动了编程语言和生态系统。
Python可能会吹嘘“有一种方法，而且最好只有一种方法可以做某事”，Ruby喜欢表现力和微妙性。Java大力倡导保护程序员免受自身伤害，Ruby在欢迎工具包中包括了一套锋利的刀具。Smalltalk训练了纯粹的消息传递，Ruby以近乎贪婪的胃口积累了关键词和结构。
Ruby之所以不同，是因为它重视不同的东西。这些东西大多是为了满足这种对幸福的渴望。这一追求不仅使它与大多数其他编程环境产生了矛盾，而且也使人们对程序员是什么以及他们应该如何行事的主流看法产生了矛盾。
Ruby不仅认识到了程序员的感受，还适应和提升了程序员的感受。无论他们是不称职的、异想天开的还是快乐的。Matz跨越了极其复杂的实施障碍，使机器看起来对人类同谋者微笑并奉承。红宝石充满了视觉错觉，在我们看来，简单、清晰、美丽的东西实际上是机罩下的一堆杂乱无章的电线。这些选择并不是免费的（问问JRuby的工作人员如何尝试对这个神奇的音乐盒进行反向工程！），这正是他们如此值得称赞的原因。
正是这种对编程和程序员的另一种愿景的奉献，使我对Ruby产生了浓厚的兴趣。这不仅仅是简单易用，也不仅仅是积木的美学，它不是单一的技术成就。这是一个愿景。反文化。这是一个让现有专业编程模式中的不适应者归属并与同类思维联系在一起的地方。
我过去曾把Ruby的发现描述为找到了一只完全适合我大脑的神奇手套。比我想象的任何手套都合适。但它甚至不止于此。这一事件标志着我个人从“因为我需要程序而做编程”转变为“因为我爱上了它作为一种智力锻炼和表达方式而做编程”。它找到了一个流动的喷泉，并能随意打开它。对任何熟悉Csikszentmihalyi工作的人来说，这项工作的影响都很难被夸大。
当我说Ruby改变了我，为我一生的工作设定了方向时，我一点也不夸张。这个启示是如此深刻。它赋予了我一种使命，那就是为马茨的创造做传教工作。帮助传播这一深刻的创造及其益处。
现在我可以想象你们大多数人都不相信地摇头。我不怪你。如果有人在我仍然生活在“编程只是工具”的范式下时向我描述了上述经历，我也会摇头。然后我可能会嘲笑宗教语言的过度使用。但为了让这篇报道真实，它也必须诚实，即使这让一些人甚至大多数人感到不快。
无论如何，这对Rails意味着什么？这一原则如何继续指导其发展？为了回答这个问题，我认为看看另一个在早期经常用来描述Ruby的原则是很有启发性的：最小惊喜原则。Ruby应该表现出你期望的样子。与Python相比，这很容易描述：
Ruby接受exit和quit，以满足程序员退出其交互控制台的明显愿望。另一方面，Python迂腐地指导程序员如何正确地执行所请求的操作，尽管它显然知道这意味着什么（因为它正在显示错误消息）。这是一个非常明确的例子，尽管规模很小。
POL不受Ruby社区欢迎的原因是这个原则本身就是主观的。对谁来说最不奇怪？好吧，给马茨。还有那些和他一样惊讶的人。随着Ruby社区的发展，对与Matz不同的事情感到惊讶的人的比例也随之增加，这成为邮件列表上毫无结果的自行车脱落的来源。因此，这一原则逐渐淡出了人们的视野，以免引发更多关于X是否对Y的行为感到惊讶的争论。
再说一遍，这和Rails有什么关系？嗯，Rails的设计原则与最小意外原则（Matz）类似。更大的微笑（DHH）的原则，这正是它在tin上所说的：API的设计非常关注任何能让我笑得更多、更广的东西。当我这样写出来的时候，这听起来几乎是滑稽的自恋，甚至我也很难反驳这种第一印象。
但创造Ruby或Rails这样的东西至少在一开始是一种深深的自恋。这两个项目都出自一位独特的创造者之手。但也许我在这里把我自己的动机投射到Matz上，所以让我把我的声明的范围缩小到我知道的范围：我为自己创建了Rails。首先，让我微笑。它的效用在很大程度上取决于它让我更享受生活的能力。为了丰富我每天为网络信息系统的需求和要求而进行的争论。
和马茨一样，我有时也会不择手段地为自己的原则服务。其中一个例子是屈折词，这个类对英语的模式和不规则性的理解刚好足以将一个人类映射到一个人表，从分析到分析，从评论到评论。这种行为现在被认为是Rails的一个无可置疑的元素，但在早期，当我们仍在整合该学说及其重要性时，争议之火以极大的强度肆虐。
另一个需要较少实施工作，但却引发了几乎同样多的恐慌的例子是：数组#秒到#五（以及#四十二表示良好的控制措施）。这些别名访问者对一个非常直言不讳的选民非常反感，他们谴责某种东西的膨胀（以及文明的接近尾声，这是一个很好的衡量标准），这种东西可以写成数组#[1]、数组#[2]（和数组[41]）。
但直到今天，这两个决定仍然让我微笑。我喜欢给人写信。第三，在测试用例或控制台中。不，这不符合逻辑。效率不高。它甚至可能是病理性的。但它继续让我微笑，从而实现了原则，丰富了我的生活，帮助我证明了我在服务12年后继续参与Rails的合理性。
与优化绩效不同，很难衡量优化幸福感。这使得它几乎本质上是一种不科学的努力，对一些人来说，这使它变得不那么重要，如果不是彻底令人沮丧的话。程序员被教导去争论和征服可测量的事物。有明确结论，并且A可以明确地被证明比B好。
但是，尽管在微观层面上很难衡量对幸福的追求，但在宏观层面上观察则要清晰得多。Ruby on Rails社区充满了正是因为这种追求才来到这里的人。他们夸耀自己拥有更好、更充实的工作生活。正是在这一系列情绪中，胜利才是显而易见的。
因此，我们得出结论：为幸福而优化可能是Ruby on Rails最具形成性的关键。它将继续这样向前发展。