幻燈文件介於幻燈片組和文件之間。其概念是您可以使用單一幻燈片組，既可在簡報時作為幻燈片，又可在簡報後作為講義供人閱讀。問題在於這兩種需求會對幻燈片產生截然不同的要求，因此您無法同時滿足這兩種需求。結果是幻燈文件通常兩者都做不好。

我們提供一小時的持續交付概觀。主題包括持續交付的理由、部署管線、持續整合、DevOps 和部署策略。亮點是 Jez 將候選版本擬人化為希臘神話中的英雄。

幾個月前，我收到了一台新的公司筆電 - 一台配備 Thunderbolt 連接埠的 Macbook Pro。當我開始使用時，便開始考慮要購買 Thunderbolt 顯示器。儘管價格昂貴，但我聽說 Apple 顯示器評價不錯，而且能當作擴充基座的顯示器這個概念也很吸引人。

2006 年，我的同事尼爾·福特創造了術語 多語程式設計，表達應用程式應以多種語言撰寫，以充分利用不同語言適合解決不同問題的事實。複雜的應用程式結合了不同類型的問題，因此針對工作挑選正確的語言可能會比嘗試將所有面向都塞進單一語言中更有生產力。

在過去幾年中，對新語言（特別是函數式語言）的興趣激增，我經常很想花時間深入探討 Clojure、Scala、Erlang 或類似的語言。但我的時間有限，我更優先考慮另一個更重大的轉變，即 資料庫解凍。第一批客戶和其他聯絡人的訊息已經傳來，前景誘人。我很有信心地說，如果你要開始一個新的策略性企業應用程式，你就不應該再假設你的持久性應該是關聯式的。關聯式選項可能是正確的選項，但你應該認真考慮其他替代方案。

軟體的一大好處是人們似乎想要它，而且很快就要。組織通常會要求團隊加快軟體的生產，而且組織時不時會尋求以真正展現其承諾的方式提供協助，即花錢為團隊增加更多人手。

從我開始談論和撰寫重構以來，人們一直詢問我如何將其納入更廣泛的軟體開發流程中。軟體開發生命週期中是否應該有重構階段、應該將多少比例的迭代專用於重構任務、我們應該如何找出誰應該被指派重構任務？儘管有些預定的重構工作有其適當的位置，但我比較喜歡鼓勵將重構視為一項機會主義活動，由任何人、在任何時間和地點，只要程式碼需要清理時進行。

goto（以前稱為 JAOO）一直是我最喜歡的會議。多年來，他們在維持高水準內容的同時，還結合了高效且友善的組織，做得很好。因此，儘管我對會議的過度參與通常會導致會議恐懼症，但我仍然對前往奧胡斯這趟有點複雜的旅程感到一絲愉快的期待。

製作和編輯影片過去是一項昂貴的活動，但現在相機和編輯軟體都很便宜。因此，像我這樣的大嘴巴紛紛投入製作影片，以協助傳播自己的想法。這樣做的原因有很多，這是一種可能性豐富的媒介，它適合像我這樣在台上侃侃而談的人，而且有充分的證據表明人們會付費購買影片，這對個人的收入和人們認真看待它的證據都有好處。儘管有這些原因，到目前為止我還沒有採取行動。

不久前，我和辛蒂以及幾個鄰居開始了一項漫長的探索，不知道我們是否能完成。這項探索是觀看莎士比亞的每一齣戲劇，使用所有合理的影片版本。這很有趣，儘管我們無法涵蓋我們想要的內容，因為我經常出差。我們按照大致的年代順序進行，並剛剛完成仲夏夜之夢。

當人們啟動企業應用程式時，最早的問題之一是「我們如何與資料庫對話」。如今，他們可能會問一個稍微不同的問題「我們應該使用哪種類型的資料庫，關係資料庫還是其中一個 NOSQL 資料庫？」。但還有另一個問題需要考慮：「我們應該使用資料庫嗎？」

在我們撰寫敏捷宣言的 10 年後，我們這些作者在 Agile 2011 會議期間受邀參加一場特別活動，以慶祝這個紀念日。17 位作者中有 15 位出席，我們在公園長椅上舉行座談會，回答觀眾的問題和評論。我想我們都很驚訝，再次見面是多麼美好，以及我們多麼容易地回到舒適的合作和討論中。我們的討論包括撰寫宣言的一些背景，回顧過去十年我們滿意和不滿意的事情、敏捷的未來發展，以及敏捷與精實的關係。

我想我認識的幾乎所有軟體開發領域的人，都對專利及其在我們領域中的使用方式深惡痛絕。我在待辦事項清單上已經有一段時間的貼文，而且在 This American Life 的一篇特別好的調查報導之後，我終於被感動寫下這篇文章。我這篇文章的簡短形式是，雖然專利（甚至是軟體專利）在原則上是一個好主意，但實際上它們已經變成一場徹底的災難，最好還是廢除。

幾個星期前，一位朋友詢問推薦的播客。我花了一段時間才回答，但我認為這是一個建議我喜歡聽什麼的好機會。

那些聽過我和同事談論FeatureBranch的人都知道，我們不是那個模式的忠實粉絲。我們反對的一個重要部分是觀察到分支很容易，但合併很難。我們時不時聽到的論點是，現代版本控制工具讓合併變得足夠容易，以至於功能分支是值得的。

我最近一直在研究 JavaScript，其中一件讓我印象深刻的事情就是使用相同的函數名稱作為 getter 和 setter 的習慣。因此，如果你想在 jQuery 中找出橫幅的高度，你會使用 $("#banner").height()，如果你想更改高度，你會使用 $("#banner").height(100)。

這個慣例對我來說很熟悉，因為 Smalltalk 使用過它。你可以使用 banner height 取得一個值，並使用 banner height: 100 來更改它。知道它是 Smalltalk 的慣例就足以讓我喜歡它，因為我對那門語言有著遙遠但持久的愛。但即使是最好的東西也有缺點，我無法隱藏我對這種程式碼風格的不喜歡。

我最喜歡的格言之一是：如果它很痛，就更常做。它有一個令人愉快的特性，表面上看起來很荒謬，但當你深入探討時，它會產生一些有價值的意義

CQRS 代表命令查詢責任分離。這是我第一次聽 Greg Young 描述的一個模式。它的核心概念是你可以使用一個與用於讀取資訊的模型不同的模型來更新資訊。對於某些情況，這種分離可能很有價值，但要注意，對於大多數系統，CQRS 會增加風險複雜性。

最近，透過某個部落格、推文或網際網路串流中的其他漣漪，我遇到了 簡報 - Andrew Abela 撰寫的關於 極致簡報 的一本免費電子書。這是一本簡短且輕鬆的書，概述了一種特定的簡報風格。我喜歡他概述的方法。如果你對簡報技巧感興趣，特別是如果你要進行簡報以說服小組採取行動，那麼這本書值得一看。

LMAX 是新的零售金融交易平台。因此，它必須處理許多低延遲交易。此系統建構在 JVM 平台上，並以業務邏輯處理器為中心，單一執行緒即可處理每秒 600 萬筆訂單。業務邏輯處理器完全在記憶體中執行，並使用事件來源。業務邏輯處理器周圍環繞著 Disruptors，這是一個並行元件，實作無需鎖定的佇列網路。在設計過程中，團隊得出結論：使用佇列的高效能並行模型的最新方向，與現代 CPU 設計基本上不一致。

一段時間以來，我一直很滿意我的 數位單眼相機 鏡頭設定：Sigma 18-200 作為一般相機鏡頭，Canon 10-22 作為廣角鏡頭，Canon 50 f1.8 和 100 f2 作為低光源人像和窄景深。這是個好設定，幫助我拍了很多我喜歡的相片。

但是，就像我這樣的多數強迫症患者所知，總是有想獲得更好設備的渴望。我聽說像 18-200 這樣的消費級鏡頭不可能像稍好一點的鏡頭一樣銳利，我可以買到自動對焦更快、更安靜的鏡頭，也許我的長距離遠攝鏡頭比我認為的還要柔和一點？

我沒有酷到可以獲得第一波邀請，但我現在已經進入 Google+，社群網路中也許是下一個大熱門。透過撰寫一些關於我到目前為止如何使用社群網路，以及一些關於 Google+ 影響力的未經證實的推測，來紀念這個重大事件似乎有點恰當

資訊部門常遇到的問題是，是否要透過建置自訂軟體或購買套件來提供某項功能。在我從事程式設計的這段時間以來，關於如何做出這個選擇的爭論一直很激烈。我對此的基本立場是建立在UtilityVsStrategicDichotomy上。簡而言之，這表示如果你所支援的業務流程是你的競爭優勢的一部分，你應該建置自訂軟體；如果不是，你應該購買套件，並調整你的業務流程以符合套件運作的方式。

儘管我的意見顯然很傑出，但似乎沒有很多公司這麼做。他們常常忽略這個二分法，這是其中一個問題。但我想在此關注的問題是，當他們購買套件時常見的陷阱。

在這部影片 (12 分鐘) 中，Mike Mason 和我談論了功能分支的危險及其替代方案。

我最近決定升級我的家用媒體伺服器，並買了一台HP N36L。到目前為止，我對它很滿意。

旗標引數是一種函式引數，它會告訴函式根據其值執行不同的運算。想像一下我們想要預訂一場演唱會。有兩種方法可以做到這一點：一般和高級。若要在此處使用旗標引數，我們會得到類似以下的函式宣告

三個演講部分：測試中的非決定性、軟體開發經濟學、敏捷宣言 10 週年。

人們在簡報投影片中常見的問題是，他們把文字和圖表做得太小，以至於只有坐在房間前排的人才能清楚看到。以下是我為降低發生這種情況的機率所採取的一個簡單措施 - 在撰寫簡報時，我將檢視大小設定為 50%。如果我在 50% 的大小下無法輕鬆閱讀，那麼觀眾也會遇到同樣的困難。

Thoughtworks 是一家不尋常的公司，這也是像我這樣一個對公司持懷疑態度的人在這裡待了十年的原因。Thoughtworks 的一個重要特點是，我們對自己的目標採取的觀點比單純的商業實體更廣泛。在過去幾年中，我們一直在使用三根支柱模型來描述我們喜歡思考自己的方式。

使用網路服務的其中一個好處是，它有助於你將系統的各個部分解耦。人員可以不同程度地分離地處理不同的程式碼庫。儘管你可以進行一些解耦，但你無法完全消除耦合，因為服務仍然必須透過它們的介面彼此通訊。令人難過的是，許多團隊讓這種耦合比它應該的更糟。

自從我得到第一個電子書閱讀器以來，還不到一年。現在我只有在真的必須時才會購買紙本書。我寫最後一本書時，主要把它當成一本紙本書，但那將是最後一次，在未來，電子形式將在我的腦海中佔據首位。這些改變將徹底改變書籍的格局，但除此之外，後續步驟並不明確。

SD Times 採訪敏捷宣言 10 年

PowerPoint 並非發明於中世紀，當時騎士們身披盔甲在戰場上奔馳。但當今的投影片組與那些古代騎士有一個共同的特徵。兩者都需要能夠從遠處清楚區分符號。我們可能沒有泥土和灰塵，但許多投影機在對比度方面並不是很出色。

隨著這麼多行動裝置平台的興起，每個平台都有不同的使用者介面，許多人都在尋找跨平台工具組。這些工具組允許你一次撰寫行動應用程式，然後將其部署到各種行動裝置。這些工具組值得使用嗎？

昨天我在一個程式碼庫中四處瀏覽，查看程式碼的網域模型部分。在探索程式碼庫時，我喜歡做筆記，以幫助我記住我正在學習的內容。對於某些程式碼庫，特別是網域模型，我發現繪製 UML 類別圖表很方便。

示範出錯的機率與觀眾的重要性成正比。

模組提供的服務應透過統一的符號提供，不會洩漏這些服務是透過儲存或計算來實作的。

-- Bertrand Meyer

Bertrand Meyer 在他極具影響力的著作 物件導向軟體建構 中提出了這個原則。

此原則的重點在於，如果您有一個 person 物件，並詢問它的年齡，您應使用相同的符號，無論年齡是物件的儲存欄位或計算值。這實際上表示 person 的客戶不應知道或關心年齡是儲存還是計算出來的。

我們最近花了一個星期在南方城市薩凡納和查爾斯頓度假。我聽說過這兩個城市在美麗和歷史景點方面都很棒，而我也可以證實這些好話。這兩個城市都值得花幾天時間到處走走。

自動化回歸套件可以在軟體專案中扮演至關重要的角色，既可以減少生產中的缺陷，對演化設計來說也至關重要。在與開發團隊交談時，我經常聽說不確定性測試的問題，也就是有時通過，有時失敗的測試。如果不加以控制，不確定性測試可能會完全破壞自動化回歸套件的價值。在本文中，我將概述如何處理不確定性測試。隔離最初有助於減少它們對其他測試的損害，但您仍然必須盡快修復它們。因此，我將討論不確定性的常見原因的處理方法：缺乏隔離、非同步行為、遠端服務、時間和資源外洩。

時不時有人介紹我為「敏捷宣言的簽署人」。他們通常的意思是我是 敏捷軟體開發宣言 的作者之一，因此也是最初的簽署人之一。但實際上，簽署人遠遠超過 17 位作者，我上次查看時，數量已達 10,104 人。如果您有興趣，可以加入該名單。

許多程式需要使用建立和維護成本昂貴的資源。資料庫連線和執行緒就是範例。資源池提供一個管理這些資源的好方法。

我大部分的朋友和同事對軟體開發的認證計畫非常負面，我也很鄙視。這並不代表我認為軟體認證在定義上很糟糕，只是我們看到的幾乎每一個認證都無法通過基本測試。

我最近決定升級我們的家用伺服器設定。我貼了一些關於我計畫要做什麼的想法，現在我已更新此頁面，說明我做了什麼。

當我第一次轉換到 數位單眼相機 時，我故意買了一台較便宜的相機，也就是 Canon Rebel XTi/400D。我這麼做的部分原因是將更多錢花在鏡頭上，但也是因為我知道技術會進步，我幾年後就會想更換機身。

我常常遇到一些開發人員感到沮喪，因為「管理階層想要更多功能，他們不在乎品質」。當我聽到這句話時，我總是感到難過，因為當我聽到這句話時，我知道開發人員、管理階層和他們的客戶已經輸了。他們的失敗是因為用可交易品質假說來構思情境。

我使用皮下測試來表示在應用程式使用者介面下方執行的測試。這在執行應用程式的功能測試時特別有價值：當您想要測試端對端行為，但很難透過使用者介面本身進行測試時。

Daniel Terhorst-North 最近關於軟體工匠精神的部落格文章引發許多部落格討論（如果您有興趣，我將在下方總結）。其中有很多內容，但他的其中一個主題特別引起我的共鳴，因此有了這篇文章。

我經常聽到有人聲稱，某種技術將使用戶能夠自行撰寫軟體，不再需要程式設計師。每當我聽到這種說法時，我都會想起 COBOL 的目標，而我們都知道結果如何。

使用 TestDouble 最常見的情況之一，是當您與外部服務進行通訊時。此類服務通常由不同的團隊維護，它們可能會受到速度慢且不可靠的網路影響，而且它們本身可能也不可靠。這就是測試替身很方便的原因，它可以防止您自己的測試速度慢且不可靠。但是，針對替身進行測試時，總會產生一個問題，即替身是否確實準確代表外部服務，以及如果外部服務變更其合約，會發生什麼情況？

本網站的大部分內容，包括此 wiki，都是使用 XML 轉換為 HTML 的流程所建置的。我使用自己的 XML 字彙撰寫文章和 wiki 條目，然後將這些來源轉換為您閱讀的 HTML。我在 2000 年開始時，是用 XSLT 執行的。雖然我在 XSLT 程式設計方面做得相當不錯，但我得出的結論是，我還不夠受虐狂，不想繼續使用它。在飛往班加羅爾的航班上，我進行了一項簡短的實驗，使用 Ruby 在 wiki 轉換器中撰寫程式，然後我改用 Ruby，使用 REXML 函式庫。現在是時候將核心函式庫變更為 Nokogiri 了

我們在印度期間，在安達曼群島度假了一週，主要是為了從事一些潛水活動。我們大部分時間都待在 Havelock 島，從主要中心布萊爾港搭乘渡輪需時數小時。以下是我們從經驗中分享的一些零碎資訊。