2015 年 Ruby 圈发生了很多有趣的事，让我们跟随 Glenn Goodrich 来回顾一下 15 年 Ruby 的年度标志性事件。

2015 年 Ruby 大盘点 技术分享

2015 将要结束，这一年对于 Ruby 来说非常重要。如果回顾一下本年度的标志性事件及其相关故事，一定会妙趣横生。有点类似敏捷型开发流程的回顾，笔者将把 2015 年分为一系列的短跑冲刺，从中查看我们的收获。

为顺利完成这一构想，首先需要定义什么是「标志性事件」。其实，几乎每年，Ruby 都在以下主要领域/标志性事件中要求社区有所突破，从而在该冲刺阶段/年份取得成果：

  • 改善语言
  • 壮大用户社区
  • 紧跟编程界的步伐

以上便是笔者定义的「标志性事件」。为了衡量 Ruby 社区的成果，笔者将再次浏览涉及以上主题的博客、文章以及视频。肯定会有遗漏，但如果十全十美，那还要评论做什么呢？

最后，要写出一篇真正有价值的回顾，也需要探讨一下不足，因此本文也会涉及这一点，力臻完美。不过估计一些机敏的读者会想补充更多内容。

改善语言

Ruby

Ruby 2.2早在一年前就已发布，不过本文会将其划为本年度的积压任务。该版本添加了许多新内容，具体如下：

  • 加入超级方法元数据使得调试过程更加简单。
  • Symbol GC 大大改善了 Ruby 垃圾收集器的性能，可能是多年以来该语言获得的最佳改进。
  • 对了，GC 的另外一项改进是递增GC，这有助于在垃圾收集时保持稳健的性能。
  • 还有一些不得不提的小变化。

Ruby 2.3.0 于圣诞节发布，其中包括以下“好礼”：

有时，改善语言意味着告别旧版本。因此Ruby停止支持1.9.3 版本了。晚安，1.9.3，我们会记住你的。

Ruby解释器中最受期待的同时也是最大改进的是JRuby 9000：

  • 这儿是版本发布公告，其中列举了一些主要的变化。
  • JRuby EU主题视频十分值得一看，从中能了解到 JRuby 9000 有多强大。给 Charles Nutter 和这个团队点赞。

另一个改善语言的方法就是，多多学习新鲜且有用的东西。比如下面这些：

关于这一点，2015 年对于 Ruby 来说，充满了有关性能提升的深度好文：

  • Richard Scheeman （今年的 Ruby 博主 MVP 非他莫属）写了两篇非常好的堆转储系列文章。这是第一篇和第二篇。
  • 这篇文章关于如何运用 Ruby调试内存泄漏。
  • 有没有折腾过 Ruby 垃圾回收器的设置？笔者也没有，或许可以试试。

年度大战

最后，如果一种语言向其使用者提供多种选项，那么它就上升了一个台阶。RSpec 与 Minitest 的竞争便是绝好的例证。

好吧，或许“年度大战”的说法有点夸张，但笔者确实认为本年度 Minitest 和 RSpec 的对决很有看点。

Rails

和 Ruby 2.2 相同，Rails 4.2 也是在去年12月底左右发布的。笔者也将其划为 2015 年的积压任务，因为直到今年，才收到针对该版本的反馈。以下是该版本的新变化：

  • 当然，要想了解其变化，最好的方法是参阅发布说明，你会看到 ActiveJob、异步邮件和充分记录等内容。
  • ActiveJob 非常好用，大大简化了队列系统的使用。
  • 发送异步邮件这一常见任务变得更加易于测试和实现。

随着后端 Web 布局的变化，Rails 也随之变化。下面几篇文章可使变化过程变得更易理解：

安全一直都是导致 Rails 出现问题的主要因素。对此，也有一些改进：

  • 这篇文章阐述了如何确保安全配置 Rails 。
  • 了解最常见的攻击形式，比如 CSRF 和 Rails，能够大大提升工作效率。
  • 当然，4.2 有数次修正发布，大多都是关于安全和漏洞修补的。欲知详情，请参阅各个版本。

当然，还有大量与Rails性能相关的文章：

  • Collective Idea 博客中有关优化 Rails 内存使用的 4 篇系列文章。
  • 不过，在此之前，最好了解一下你的 Rails 性能。
  • 对性能有所了解之后，可以参阅 ActiveRecord 优化，这两篇文章出自另一位 MVP 候选人，Justin Weiss。

Ruby 的主要变化并未出现在 Rails 4.2.x 中，但笔者认为，5.0 在 4.2 的基础上会有非常明显的变化。

Rails 之外

理所当然的是，全新的基于 Ruby 的非 Rails 开发框架和代码库能够改善 Ruby语言。以下是 2015 年出现的一些新内容：

  • 这一年对 Lotus 来说非常重要，如果想尝试 Rails 以外的面向对象的优秀 Web 开发框架，可以试试 Lotus。
  • Opal 也是 2015 年中成绩斐然的一个库，作为从 Ruby 到 Javascript 的编译器，非常受欢迎。
  • Volt 或许是站在 Opal 肩膀上的 Web 开发框架，其利用 Opal 帮助开发者编写前端和后端的 Ruby 程序。
  • 另外一个新的 Web 开发框架 Pakyow 致力于使实时应用更加好用，当然也值得参考。

壮大用户社区

任何一门想要发展壮大的语言都需要使越来越多的人知道这门语言。听起来很难吧?下面的文章可帮助那些不了解 Ruby 的人入门：

技术多样性已然成为非常热门的话题，这也合情合理。Rails Girls 和 RailsBridge 都专注于鼓励 Ruby 多样性。本年度围绕多样性的故事有：

  • Stephanie Burns 描绘了她在 Ruby 代码营（code camp）中的经历。代码营越来越多，其形式也越发符合 Ruby 社区的需求。
  • 类似于 Makers 学院的组织为其女性学员提供奖学金。
  • 笔者觉得 Hello Ruby 非常棒，这是一本儿童书，能引起小孩子对写代码的兴趣。真的，可以考虑买一本送给小朋友。

总之，Ruby 的多样性发展在 2015 年可谓可圈可点。希望这一主题在 2016 年能获得更多积极的支持。

跟上科技新宠的步伐

任何一门语言要想在当前形势中保持活跃，都必须跟随语言之外的技术不断变化，甚至实现整合。从根本上来说，Ruby 满足这一点，因为它默认将两个大的解释程序（MRI和JRuby）接入外部运行。以下为 2015 年一些重要的科技话题，并就 Ruby 如何融入技术进行了解释。

Docker

集装箱化在2015年末风行一时，以下是有关 Ruby 和 Docker 的一些文章：

  • 阅读来自 Travis Reeder 的这篇文章，可为 Ruby 应用创建最小的 Docker 镜像。
  • 使用 Docker 测试 Rails 会非常简单，Marko Locker 的这篇文章写得很清楚。
  • Nick Gauthier 阐述了如何使用 Docker 并行开展 Rails 测试。

真的，在2015年，一不留神就能看见10篇关于Docker的文章。如果还没有学习 Docker，那就赶紧学吧，它名副其实。

Slack

你在使用 Slack 吗？当然！因为每个人都在用。Slack 很好用，其价值能赶得上大多数发达国家的 GDP。Ruby 和 Slack 相结合非常好用，看看下面的文章就知道：

其他语言

Ruby 开发者总在寻找可以利用或学习的其他语言，以期让开发过程变得更加愉悦。下面是一些关于寻找编程架构的小故事：

  • Parse 从 Ruby 转为 Go ，变得更加健全了。
  • 今年有关 Rust 的报道可谓不计其数，Robert Qualls 的这篇文章展示了如何通过 Ruby 使用 Rust。
  • 不过，Ruby 开发者的新欢一定是 Elixir。阅读本文，看看为什么有人坚信 Elixir 是未来之星。

最后，其他引起躁动的 Ruby 相关文章：

  • React 是目前的 javascript 开发框架。通过这篇文章学习如何通过 Rails 使用它吧。
  • 如果你用 Ruby 写 Web 应用程序，又不是 David Heinemeier Hansson（Ruby on Rails 创始人），那么微服务对你而言就是全新的概念。这篇文章阐述了如何将 Rails 应用设计打造为微服务。

缺点

每篇回顾都应花一点篇幅讲讲不足。做一个消极者是非常容易的，所以这一部分本可以很长，不过笔者只会列出以下几条：

  • 人们对于 Rails 开发工作流中 Spring 的加入毁誉参半。许多人和这位作者想的一样，完全放弃了 Spring。
  • Adam Hawkins 提到了 Ruby 需要改进的大量问题，并且展示了一幅高要求的产品规划图。
  • 笔者之前也提到过微服务，它受到了大量的反对。Nick Sutterer（许多超棒的程序和Trailblazer 开发框架的开发者）写的这篇文章就说明了如何在被微服务折腾之前做好设计工作。
  • 最后，Refinements 怎么样了？有人用吗？MVP 候选人 Starr Horne 就会用，但是笔者并不觉得很多人在用 Refinements。我们应该用吗？
  • 2015 年，我们了解到，宕机简直是噩梦。的确，宕机真的是太恐怖了。

本文肯定遗漏了 Ruby 领域中比较不起眼的一些内容，请在评论区告知。

原文地址：http://www.sitepoint.com/a-retrospective-on-ruby-in-2015/

Cloud Insight 集监控、管理、计算、协作、可视化于一身，帮助所有 IT 公司，减少在系统监控上的人力和时间成本投入，让运维工作更加高效、简单。 本文系国内 ITOM 行业领军企业 OneAPM 工程师翻译整理。想阅读更多技术文章，请访问 OneAPM 官方技术博客。