我演講很多，跟任何演講者一樣，我總是會被要求提供投影片副本。也跟許多演講者一樣，尤其是那些花心思製作投影片的人，我討厭提供投影片副本作為講義。當我使用投影片時，我會設計成 視覺頻道：搭配我的話語，而不是獨立的「投影片文件」。這種投影片文件在演講時非常令人分心，因為閱讀要點會讓聽眾的注意力從演講話語上移開。因此我的投影片是圖形的、簡約的，而且經常涉及與我的演講同步的動畫。沒有我的演講，這些投影片就毫無意義。

在過去幾個月裡，有一些文章提到 技術負債，這引發了一個問題，即哪些類型的設計缺陷應該或不應該歸類為技術負債。

跟許多極客一樣，我喜歡攝影。我們這些極客喜歡攝影，因為它提供了藝術追求的表象，同時讓我們沉迷於大量的技術細節，並花錢購買昂貴的玩具。最近一位朋友問我相機購買決策，這個問題促使我寫下這些決策。

使用 測試替身 的經典案例之一是在呼叫遠端服務時。遠端服務通常很慢，而且經常不可靠，因此使用替身是一種讓測試更快速、更穩定的好方法。

巴拉克·歐巴馬在 2008 年總統競選中的勝利，軟體做出了顯著的貢獻，特別是使用網際網路。但或許最有趣的一面，是軟體進展與競選中人類組織發展之間的交互作用。

撰寫可維護程式碼最有效的工具之一，就是將大型方法分解成命名良好的小型方法，這是 Kent Beck 所稱的組合式方法模式。

電腦科學中只有兩件難事：快取失效和命名。

-- Phil Karlton

我最近用 Mercurial 壓縮了一些提交，所以想說如果有人想這麼做，這篇貼文或許會有幫助。我不知道這是不是最好的程序，但對我來說似乎滿好用的。

上個月在 Google IO 大會演講的附帶好處之一，就是我得到了一支新手機，是 Google 送給所有與會者的 HTC Magic Android 手機。我原本就有打算換一支像這樣的電話，所以這真是時候。以下是我帶著它一個月左右的心得。

如果你在 Thoughtworks 和我的同事們相處，你很快就會覺得，唯一好的企業服務匯流排 (ESB) 就是死掉的 ESB。Jim Webber 稱它們為錯誤的義大利麵盒。所以聽到有人試圖把不需要的 ESB 從系統中移除，並不稀奇。

世界上最常見的程式語言是什麼？

AMP，一家澳洲金融服務公司，舉辦了一場名為 Amplify 的內部會議。他們邀請我談論敏捷軟體開發。我思考如何讓這場演講最符合會議的整體流程，特別是因為我預期有相當一部分的聽眾並非 IT 領域的人員。我決定談論 IT 專案如何成為基礎架構或策略。此分類會改變你處理專案的方式，特別是在 IT 和業務人員應如何合作的方式上。

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

敏捷軟體開發宣言 最引人注目的事情之一，就是其價值觀的格式「我們偏好 x 勝過 y」。我不記得是誰想出這個點子，或它是如何產生的。它可能只是在我們拋出各種想法時自然而然產生的。但它獨特的格式已讓一些人嘗試再次使用該格式。

最近，我們的一些開發人員遇到了這樣的指控：使用像 ruby 這樣的動態語言，你會使用這麼多動態類型檢查，以至於你最終會實際撰寫自己的類型系統。因此他們想，由於我們已經撰寫了很多真正的 ruby 程式碼，我們有多常進行動態類型檢查？Michael Schubert 收集了資料。

Rebecca Parsons 和我談論 Google App Engine 和雲端的整體世界。在第一部分，我談論 ThoughtWorkers 從 App Engine 實驗中學到的各種事物，重點說明測試、持久性和並發性的問題。在第二部分，Rebecca 談論企業在轉移到雲端時將面臨的更廣泛問題。

幾個星期前，舊金山舉辦了一場名為 GoGaRuCo（金門大橋 Ruby 大會）的 Ruby 大會。這場大會因一場演講而備受矚目，演講者在討論 CouchDB 時，使用了暗示性很強的女性圖片。不出所料，這場演講引發了不少激烈的，偶爾還會冒犯到人的辯論。

幾年前，我的同事馬特·福默爾對我們用來建構軟體的工具感到不滿意，設法聯繫了查爾斯·西蒙尼，以進一步了解神秘的 Intentional Software。他所看到的讓他印象深刻，並說服我和其他 ThoughtWorker 也參與其中。我們所看到的是一個具有驚人潛力的工具，但我們仍然對保密和缺乏發布的緊迫感感到沮喪。這種沮喪在上週結束了。

我使用「外行程式設計師」一詞，是指那些在沒有將自己視為程式設計師的情況下進行程式設計的人。每天花大量時間處理試算表的人就是在進行程式設計，通常是非常密集的程式設計。然而，她通常不會稱自己為程式設計師，也不會考慮花很多時間學習如何更好地進行程式設計。

在電影《不可饒恕》的結尾，克林特·伊斯特伍德飾演的角色需要逃離小鎮。他宣布，如果有人試圖射殺他，他就會殺死他，然後殺死他的家人，再燒毀他們的房子。

當我參加 DSL DevCon 時，微軟的 Channel 9 將我拉走，接受克里斯·塞爾斯的採訪。

這是我的常用 DSL 簡介演講，但由於我對 DSL 了解更深入的聽眾，因此我進行了一些調整。所以我基本上將演講調整為我如何向人們介紹 DSL。

許多電腦系統建構的目的是儲存資料，並將資料轉換成對人類有用的資訊。當我們這麼做時，自然會希望這些資訊是一致的。畢竟，一個對事情猶豫不決的電腦系統有什麼用處？

我的同事 Zack Exley 和我討論 2008 年歐巴馬總統競選活動中使用的軟體。我發現特別有趣的一個面向是，該軟體如何啟用並與競選活動的組織方法互動。

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

最近我花了一些時間參與我最喜歡的 Thoughtworks 專案之一。這是一個始於 1998 年的專案，當時使用的是當時新的 J2EE 技術。多年來，它有著一段引人入勝的歷史：從 EJB 開始，將它們移除，外包到班加羅爾，再回到芝加哥。許多人進出這個專案，而專案的人數在 6 到 60 之間變化。總體而言，這個專案投入了超過 300 個員工年，規模約為 100 KLOC。

我在 QCon San Francisco 參加了一場有趣的演講，由 Greg Young 針對他最近在一個系統上使用的特定架構所做的一場演講。Greg 是 領域驅動設計 的忠實粉絲，在這個案例中，它必須用於一個必須處理高交易率並提供資料給許多使用者的系統。我發現他的設計有許多有趣的地方，特別是他使用 事件溯源，但對於這篇文章，我只想探討一個面向，也就是我所稱的熱切讀取衍生。

DSL 倡導者需要防範的一個危險觀念是，你首先設計一個 DSL，然後人們使用它。就像任何其他軟體設備一樣，一個成功的 DSL 會演進。這表示使用 DSL 早期版本編寫的指令碼，在使用後續版本執行時可能會失敗。

我最近聽說許多專案都有個問題。情況如下

• 他們想要使用敏捷流程，並選擇 Scrum
• 他們採用 Scrum 實務，甚至可能是原則
• 過了一段時間，進度變慢，因為程式碼庫一團糟

我應該使用規則引擎嗎？