Ruby on Rails 的創建者 David Heinemeier Hansson 在 RailsConf 上發表主題演講，宣稱 TDD 已死。這在 Rails 和更廣泛的軟體開發社群中引起了預料中的大量爭議。這也導致 David、Kent 和我之間產生了一些有趣的對話。我們認為這些對話很有趣，其他人可能也會想觀看，因此錄製了一系列影片聚會，討論 TDD 在軟體開發中的角色。

我和同事 Badri 關於六角形架構及其在 Rails 應用程式中的角色的對話影片。在第一部影片中，我們討論六角形架構的意義，以及這如何引導我們在持久化架構中選擇 Active Record 和資料對應器模式。在第二部影片中，我們更廣泛地探討 Rails 在應用程式中應扮演的架構角色 - 你應該將它視為平台還是元件套件。

Rake 是一種建置語言，其用途類似於 make 和 ant。與 make 和 ant 一樣，它是一種特定領域語言，與這兩個不同的是，它是一種使用 Ruby 語言編寫的內部 DSL。在本文中，我介紹了 rake，並描述了我使用 rake 建置此網站時發現的一些有趣事物：相依性模型、綜合任務、自訂建置常式和除錯建置指令碼。

Ruby Rogues 是個熱門的 Podcast，由固定班底討論 Ruby 程式設計社群中的主題。他們有固定的讀書會，最近選了 EAA 的 P 作為特色書籍。因此，他們邀請我以來賓身分參加他們的節目，討論這本書和它所描述的模式，特別是這些模式與 Rails 框架之間的有趣關係。

Ruby Rogues 是個熱門的 Podcast，討論 Ruby 世界中的程式設計。他們邀請我回去討論 Ruby 版本 的 重構。我們談到了重構的定義、為什麼我們發現自己不太常使用除錯器、可以做些什麼來現代化這本書、重構工具的角色、註解是否可以善加利用、重構與重寫之間的權衡、模組化與微服務，以及軟體產業在過去二十年來如何改變。

Thoughtworks 從 2006 年開始在生產專案中使用 Ruby，從那時到 2008 年底，我們已經完成了 41 個 Ruby 專案。為了準備在 QCon 的演講，我調查了這些專案，以檢視我們可以從經驗中汲取哪些教訓。我描述了我們到目前為止對 Ruby 的生產力、速度和可維護性等常見問題的想法。到目前為止，我們的結論是 Ruby 是個可行的平台，應該認真考慮用於許多形式的應用程式，特別是使用 Ruby on Rails 的 Web 應用程式。我也會介紹一些技術教訓，包括一些關於使用 Active Record 進行測試的想法。

在 2009 年倫敦 QCon 的演講中，我調查了 Thoughtworks 在 2006-2008 年間使用 Ruby 的情況，當時我們執行了 41 個專案。我的演講涵蓋了我們對 Ruby 的生產力、速度和可維護性的看法。我的結論是，Ruby 應該被視為一個嚴肅的開發環境。如果你偏好閱讀而非觀看，我還有一篇文章涵蓋了相同的材料。

與我大多數的主題演講一樣，這是一場即席演講。考量到這場會議，這場演講的主題是 Rails 如何影響軟體開發。

集合管線是一種程式設計模式，其中你將某些運算組織成一個運算順序，透過將一個運算的集合輸出作為下一個運算的輸入來組合。 (常見的運算有篩選、映射和簡化。) 這種模式在函數式程式設計中很常見，在具有 lambda 的物件導向語言中也很常見。本文描述了這個模式，並提供了幾個如何形成管線的範例，既可以向不熟悉這個模式的人介紹這個模式，也可以幫助人們理解核心概念，以便他們可以更輕鬆地從一種語言取得想法到另一種語言。

當你學習物件時，你通常會學到它們可以擷取兩種資料：實例和類別。實例變數是最常見的情況，資料會隨著物件的每個實例而有所不同。類別變數，通常稱為靜態變數，在類別的所有實例中共享。每個實例都指向相同的數值，並且所有變更都會被所有人看到。類別變數比實例變數不常見，特別是可變類別變數。

也許我有點天真，但我從未預期過我在HumaneInterface上的貼文會引起這麼多的討論。遺憾的是，大部分的討論最後都變成 Ruby 的陣列和 Java 的清單的相對優點，而不是我試圖提出的基本觀點，但儘管如此，我認為出現了一些不錯的對話支流。

其中一個對話串指出，除了人道/極簡主義的哲學之外，陣列和清單之間還有其他差異的原因。其中一個原因與類似功能在兩種語言中扮演不同角色的方式有關。

最近，我們的一些開發人員遇到了指控，他們說使用 Ruby 等動態語言時，你會使用如此多的動態類型檢查，以至於你最終會有效地編寫自己的類型系統。因此他們認為，由於我們編寫了大量的真實 Ruby 程式碼，我們多久會進行一次動態類型檢查？Michael Schubert 收集了資料。

我一向不願意對程式語言中的靜態和動態類型之間的爭論做出任何貢獻。這是那些情緒化話題之一，人們似乎更傾向於爭論而非傾聽。但由於我被問過幾次，我將貢獻我的個人經驗。我並非試圖說服任何人，但我希望有人能從中找到一些思考的材料。

在最近成立的 Rails 社群中，「企業」一詞正成為一個貶義詞。對許多人來說，Rails 框架及其激進的簡潔性是過於複雜的 「企業」 框架的反面。

如果你正在閱讀這篇文章，我假設你知道 Ruby 程式語言已經引起了很大的轟動，特別是 Rails 框架用於開發 Web 應用程式。有些人認為它是未來的程式設計，而另一些人則認為它是一種危險的轉移。

目前，關於 Groovy 和 JRuby 作為在 Java 虛擬機器上執行的腳本語言的相對優點，正有一場激烈的爭論。好奇的人想知道，這些語言中哪一種將贏得這場即將到來的語言戰爭？人們想知道為專案選擇哪種語言，或承諾學習哪種語言。

如果我想教人們物件導向，我應該使用哪種語言？

我參加的會議沒有以前那麼多了，但這方面的優點是我有時間參加自己喜歡的會議。我一向特別喜歡 Ruby 社群，所以我今年以與會者的身分參加了 RailsConf。

Ruby 最受歡迎的功能之一是它支援 元程式設計，也就是說這些功能的作用就像改變語言本身一樣，引入了新的關鍵字等內容。

在 RailsConf2007，JRuby 引起許多熱烈討論。這個小團隊接手一個瀕臨死亡的專案，並將它轉變成在 JVM 上執行 Ruby 平臺的頂尖實作。他們獲得許多喝采，實至名歸。

因此，隨著 JRuby 逐漸成熟，焦點轉移到另一個常見的受控碼執行時期 - .NET。Microsoft 目前對 Ruby 的意圖仍不明朗。他們宣佈 Ruby 是用於撰寫 Silverlight 腳本的語言 - 但這仍留下許多未解的問題。這是一個 Ruby 語言的完整實作，還是某種形式的 Ruby++ - Ruby 的加強子集？

我的任何一位固定讀者都知道，我已經熱衷於 Ruby 好幾年了。我喜歡 Ruby 語言，因為它豐富但簡潔的語法，以及隨附的設計完善的架構。它已成為我個人專案的常規主力語言，包括這個網站的大部分內容。

在我最近關於 EvaluatingRuby 的文章中，我提到一位同事使用一些精美的數字圖表組合了一個網路應用程式。有人寄電子郵件詢問他是如何做到的。我在原始的 bliki 條目中加入我的簡短答案 ploticus，但這引發了另一個問題：他是如何將 Ruby 與 ploticus 整合的？

幾週前，在舊金山舉辦了一場名為 GoGaRuCo（Golden Gate Ruby Conference）的 Ruby 會議。這場會議因一位主講者在演講中使用女性的性暗示圖片來說明 CouchDB 的討論而引起關注。不出所料，結果引發了不少激烈的，偶爾還會冒犯人的辯論。