2015 年 Ruby 大盘点

时间:2022-01-06 15:36:20

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 GirlsRailsBridge 都专注于鼓励 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 官方技术博客

本文转自 OneAPM 官方博客