2015 年 Ruby 圈發生了不少有趣的事,讓咱們跟隨 Glenn Goodrich 來回顧一下 15 年 Ruby 的年度標誌性事件。javascript
2015 將要結束,這一年對於 Ruby 來講很是重要。若是回顧一下本年度的標誌性事件及其相關故事,必定會妙不可言。有點相似敏捷型開發流程的回顧,筆者將把 2015 年分爲一系列的短跑衝刺,從中查看咱們的收穫。html
爲順利完成這一構想,首先須要定義什麼是「標誌性事件」。其實,幾乎每一年,Ruby 都在如下主要領域/標誌性事件中要求社區有所突破,從而在該衝刺階段/年份取得成果:前端
以上即是筆者定義的「標誌性事件」。爲了衡量 Ruby 社區的成果,筆者將再次瀏覽涉及以上主題的博客、文章以及視頻。確定會有遺漏,但若是十全十美,那還要評論作什麼呢?java
最後,要寫出一篇真正有價值的回顧,也須要探討一下不足,所以本文也會涉及這一點,力臻完美。不過估計一些機敏的讀者會想補充更多內容。react
Ruby 2.2早在一年前就已發佈,不過本文會將其劃爲本年度的積壓任務。該版本添加了許多新內容,具體以下:git
Ruby 2.3.0 於聖誕節發佈,其中包括如下「好禮」:github
有時,改善語言意味着告別舊版本。所以Ruby中止支持1.9.3 版本了。晚安,1.9.3,咱們會記住你的。web
Ruby解釋器中最受期待的同時也是最大改進的是JRuby 9000:spring
另外一個改善語言的方法就是,多多學習新鮮且有用的東西。好比下面這些:docker
關於這一點,2015 年對於 Ruby 來講,充滿了有關性能提高的深度好文:
最後,若是一種語言向其使用者提供多種選項,那麼它就上升了一個臺階。RSpec 與 Minitest 的競爭即是絕好的例證。
好吧,或許「年度大戰」的說法有點誇張,但筆者確實認爲本年度 Minitest 和 RSpec 的對決頗有看點。
和 Ruby 2.2 相同,Rails 4.2 也是在去年12月底左右發佈的。筆者也將其劃爲 2015 年的積壓任務,由於直到今年,才收到針對該版本的反饋。如下是該版本的新變化:
隨着後端 Web 佈局的變化,Rails 也隨之變化。下面幾篇文章可以使變化過程變得更易理解:
安全一直都是致使 Rails 出現問題的主要因素。對此,也有一些改進:
固然,還有大量與Rails性能相關的文章:
Ruby 的主要變化並未出如今 Rails 4.2.x 中,但筆者認爲,5.0 在 4.2 的基礎上會有很是明顯的變化。
理所固然的是,全新的基於 Ruby 的非 Rails 開發框架和代碼庫可以改善 Ruby語言。如下是 2015 年出現的一些新內容:
###壯大用戶社區
任何一門想要發展壯大的語言都須要使愈來愈多的人知道這門語言。聽起來很難吧?下面的文章可幫助那些不瞭解 Ruby 的人入門:
技術多樣性已然成爲很是熱門的話題,這也合情合理。Rails Girls 和 RailsBridge 都專一於鼓勵 Ruby 多樣性。本年度圍繞多樣性的故事有:
總之,Ruby 的多樣性發展在 2015 年可謂可圈可點。但願這一主題在 2016 年能得到更多積極的支持。
###跟上科技新寵的步伐
任何一門語言要想在當前形勢中保持活躍,都必須跟隨語言以外的技術不斷變化,甚至實現整合。從根本上來講,Ruby 知足這一點,由於它默認將兩個大的解釋程序(MRI和JRuby)接入外部運行。如下爲 2015 年一些重要的科技話題,並就 Ruby 如何融入技術進行了解釋。
集裝箱化在2015年底風行一時,如下是有關 Ruby 和 Docker 的一些文章:
真的,在2015年,一不留神就能看見10篇關於Docker的文章。若是尚未學習 Docker,那就趕忙學吧,它名副其實。
####Slack
你在使用 Slack 嗎?固然!由於每一個人都在用。Slack 很好用,其價值能趕得上大多數發達國家的 GDP。Ruby 和 Slack 相結合很是好用,看看下面的文章就知道:
####其餘語言
Ruby 開發者總在尋找能夠利用或學習的其餘語言,以期讓開發過程變得更加愉悅。下面是一些關於尋找編程架構的小故事:
最後,其餘引發躁動的 Ruby 相關文章:
###缺點
每篇回顧都應花一點篇幅講講不足。作一個消極者是很是容易的,因此這一部分本能夠很長,不過筆者只會列出如下幾條:
本文確定遺漏了 Ruby 領域中比較不起眼的一些內容,請在評論區告知。
原文地址:http://www.sitepoint.com/a-retrospective-on-ruby-in-2015/
Cloud Insight 集監控、管理、計算、協做、可視化於一身,幫助全部 IT 公司,減小在系統監控上的人力和時間成本投入,讓運維工做更加高效、簡單。 本文系國內 ITOM 行業領軍企業 OneAPM 工程師編譯整理。想閱讀更多技術文章,請訪問 OneAPM 官方技術博客。
本文轉自 OneAPM 官方博客