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

API 不應具有著作權，以便程式設計人員可以重新實作介面以支援測試、互通性和鼓勵競爭。

如果您正在驗證某些資料，通常不應使用例外來表示驗證失敗。在此，我將說明如何將此類程式碼重構成使用通知模式。

我是否在專用的手持式 GPS 裝置中找到任何價值？

在 goto Aarhus 2014 中，我和 Erik Dörnenburg 以及 Tim Bray 的主題演講花了很多時間考慮網際網路上的隱私權問題。之後，Ola Bini 與我們一起討論這個問題、目前的狀況以及我們開發人員應該如何處理它。

在過去幾年中，服務導向架構已轉向較小、更專注的「微」服務。這種方法有許多好處，例如能夠獨立部署、擴充和維護每個元件，以及在多個團隊間並行開發。然而，一旦引入這些額外的網路分割，就需要重新考慮適用於單一處理序應用程式的測試策略。在此，我們計畫討論多種方法，用於管理多個獨立可部署元件的額外測試複雜性，以及如何讓測試和應用程式保持正確，儘管有多個團隊各自擔任不同服務的守護者。

搭配 Sony-Zeiss 16-70mm 鏡頭的 Sony a6000 無反光鏡相機的非正式評測。

Morrisons OrderPad 是一款平板電腦網路應用程式，可協助超市員工在賣場走動時訂購新庫存。最終應用程式可為由輕量級 Java 伺服器應用程式支援的平板電腦網路應用程式打造良好的說明性架構。我們強調在客戶端分離應用程式控制和 DOM 互動，在伺服器上使用小型、專注的架構，廣泛的堆疊測試環境，以及使用試點專案來了解需要哪些功能。

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

你坐在會議中，思考你的團隊在過去幾年來一直處理的程式碼。你已經決定，現在你能做的最好的事情就是丟棄所有那些程式碼，並在全新的架構上重新建構。這讓你對那些註定的程式碼、你花在處理它上的時間、你當時做出的決定有什麼感覺？

在 goto 2014 的主題演講中，Erik 和我考量軟體專業人員如何為我們的軟體對社會的影響負責。目前主要的考量之一是隱私，而隱私正受到大規模監控的破壞。電子郵件目前是有問題的，因為電子郵件轉移到服務，導致電子郵件供應商的集中，這使得監控更容易。我們需要透過努力擴大電子郵件加密的使用來改善隱私，讓大規模監控的成本變得高昂。這方面的挑戰主要是使用者體驗和軟體封裝的挑戰，而不是需要對密碼學有深入了解。

我們使用熱門的內容管理系統 (CMS) 建立許多內容豐富的網站。最近的一個專案涉及全球製造商的市場行銷網站，需要複雜的互動內容，並具備高可用性和流量需求。我們的回應是應用編輯與發布分離模式，並為內容建立和傳遞建立兩個不同的軟體堆疊。在這個簡報中，您可以看到此架構的概觀，以及我們對堆疊之間整合問題的回應，提供即時網站的安全預覽，以及處理系統的演進和擴充。

我在設定 Vagrant VM 以幫助協作者使用我的網路發布工具鏈的經驗中的一些筆記。我使用 Chef 來提供 VM，並使用 rbenv 來安裝和控制正確版本的 ruby。

我最近在我的 Apple 筆記型電腦上的備忘錄應用程式中刪除了一則備忘錄。身為一個偏執的備份保管者，而且通常會將我的所有工作提交到像 git 這樣的儲存庫，所以我不會太擔心意外刪除。但是 Apple 的備忘錄應用程式沒有任何形式的版本控制，而且很容易意外刪除某些東西。我有一個每日 rsync 備份和執行時間機器，但 Google 無法找出一個簡單的方法來取回備忘錄。因此，如果其他人需要執行此操作，請參閱以下步驟。

當我與人討論使用 微服務架構樣式 時，我聽到了許多樂觀的意見。開發人員喜歡使用較小的單元，並期望比單體架構具有更好的模組化。但與任何架構決策一樣，都有取捨。特別是微服務對運作有嚴重的後果，因為運作現在必須處理小型服務的生態系統，而不是單一、定義良好的單體架構。因此，如果您沒有某些基準能力，就不應該考慮使用微服務樣式。

成熟度模型是一種工具，可幫助人們評估個人或群體的當前效能，並協助找出他們需要進一步獲得哪些能力以提升其績效。在許多圈子中，成熟度模型已獲得惡名，但儘管它們很容易被濫用，但在適當的手中，它們可能會有幫助。

守破離是一種思考方式，說明您如何學習一項技術。這個名稱來自日本武術（特別是合氣道），Alistair Cockburn 將其引入作為思考軟體開發技術和方法論的一種方式。

在 EAA 的 P 中，我說「不要分散您的物件」。這個建議是否與我對微服務的興趣相矛盾？

金絲雀釋出 是一種降低在生產中引入新軟體版本的風險的技術，方法是在將變更逐步推廣到一小部分使用者之前，先將其推廣到整個基礎架構並讓所有人都可以使用。

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

2014 年初發現了兩個電腦安全漏洞：Apple 的「goto fail」漏洞和 OpenSSL 的「Heartbleed」漏洞。這兩個漏洞都可能造成廣泛且嚴重的安全失敗，我們可能永遠不知道其全部範圍。鑑於其嚴重性，軟體開發專業人員必須反思如何才能偵測到這些漏洞，以便我們提高未來預防此類缺陷的能力。本文探討單元測試可能扮演的角色，說明單元測試，更重要的是單元測試文化，如何找出這些特定漏洞。本文接著探討這種文化的成本和好處，並說明 Google 如何灌輸這種文化。

變更會影響所有使用者的介面時，需要兩種思考模式：實作變更本身，然後更新所有用法。如果您嘗試同時執行這兩項工作，這可能會很困難，特別是如果變更在具有多個或外部用戶端的 PublishedInterface 上。

平行變更，也稱為擴充和收縮，是一種模式，可透過將變更分成三個不同的階段（擴充、遷移和收縮）來安全地實作與向後不相容的介面變更。

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

單元測試在軟體開發中經常被提及，而且在我撰寫程式碼的這段時間裡，我也很熟悉這個術語。然而，就像大多數軟體開發術語一樣，它的定義非常不明確，而且我發現人們常常會誤以為它的定義比實際上更嚴謹，這時就會產生混淆。

在 重構 中，我使用「自測程式碼」這個名稱來指稱與功能性軟體結合撰寫全面自動化測試的做法。如果執行得當，這將允許你呼叫執行測試的單一指令，而且你可以確信這些測試會找出隱藏在程式碼中的任何錯誤。

我的許多演講都可以在 YouTube 上找到。以下是我的 YouTube 演講播放清單，我會盡力保持最新。

大多數 企業應用程式 都會使用資料庫儲存持續性資料。此資料庫支援應用程式狀態的運作更新，以及用於決策支援和分析的各種報告。然而，運作需求和報告需求通常截然不同，對架構和資料存取模式有不同的需求。發生這種情況時，通常明智的做法是將報告需求分隔到報告資料庫中，它會複製必要的運作資料，但以不同的架構表示。

「微服務架構」一詞在過去幾年中興起，用來描述一種特定方式，將軟體應用程式設計為獨立部署服務的套件。雖然沒有對這種架構風格的精確定義，但圍繞業務功能組織、自動部署、端點中的智慧，以及語言和資料的分散式控制，存在某些共同特徵。

本世紀初，我撰寫了《企業應用程式架構模式》一書。在撰寫本書時，我遇到的問題之一是如何為其命名，或者更確切地說，如何稱呼我所撰寫的軟體系統類型。我始終意識到，我的軟體開發經驗一直專注於一種特定的軟體形式，例如醫療保健記錄、外匯交易、薪資和租賃會計。這些與印表機、遊戲、飛航控制軟體或電話交換機中的嵌入式軟體有很大的不同。我需要一個名稱來描述這些類型的系統，最後決定使用「企業應用程式」一詞。

到目前為止，我已經寫了相當多的書，偶爾會有人問我使用什麼工具來寫書。多年來，我已經開發了一個相當靈巧的工具鏈，至少對我來說是如此，因此以下是我對其運作方式的概念。

軟體系統通常會對執行於不同程序中的軟體進行遠端呼叫，這些軟體可能位於網路中的不同機器上。記憶體內呼叫和遠端呼叫之間的一個重大差異在於，遠端呼叫可能會失敗或掛起，直到達到某個逾時限制而沒有回應。更糟糕的是，如果您在一個沒有回應的供應商上有許多呼叫者，那麼您可能會耗盡關鍵資源，導致多個系統發生連鎖故障。Michael Nygard 在他出色的著作《釋放它》中推廣了斷路器模式，以防止這種災難性的連鎖反應。

斷路器的基本概念非常簡單。您將受保護的函式呼叫封裝在斷路器物件中，該物件會監控故障。一旦故障達到某個閾值，斷路器就會跳閘，並且對斷路器的所有進一步呼叫都會返回錯誤，而不會執行受保護的呼叫。通常，您還希望在斷路器跳閘時收到某種監控警示。

導致我們在軟體社群中發現令人不安的 DiversityImbalance 的因素有很多。其中一些因素，像是青少年教育中會讓女孩對 STEM 科目 卻步的問題，是一個長期性的問題，我們的專業無法扮演核心角色來解決。但有一個因素直接歸咎於我們，那就是籠罩在科技社群中的疏離氣氛。

這是我在慕尼黑舉辦的 OOP 2014 大會主題演講的第二部分，也是一個很難描述的演講。我通常喜歡用標題和摘要來描述演講的內容，但這場演講是一趟旅程，我不想告訴你我要去哪裡，而是要和你一起探索這片土地。我要說的是，這場演講從我對大多數敏捷軟體開發採用方式最大的問題開始，也就是使用者、分析師和程式設計師之間互動的本質。它繼續探討這些角色，提出程式設計師與使用者之間的關係、我們對他們的責任，以及最後我想程式設計師需要面對的兩大挑戰。

在過去十年左右的時間，重構已成為廣泛使用的技術，用於維持程式碼庫的高內部品質。然而，大多數團隊並未充分利用重構，因為他們不知道可以在各種工作流程中使用它。在慕尼黑舉行的 OOP 2014 主題演講中，我探討了其中一些工作流程：例如拾取垃圾重構、理解重構和準備性重構。我也提醒大家，為什麼重構的常見理由會破壞你的最大努力。（這場演講也有作為 資訊卡 的處理方式。）

單頁式網路應用程式經常變成 jQuery 雜燴，其中應用程式邏輯、DOM 處理和伺服器存取全部混在一起。這種關注點的混雜讓此類應用程式比它們應有的更難理解和測試。分離的 DOM 是一種模組化策略，它將所有 DOM 處理分隔到專用的 JavaScript 物件中。

受限上下文是領域驅動設計中的核心模式。它是 DDD 策略設計區段的重點，該區段完全關於處理大型模型和團隊。DDD 透過將大型模型分割成不同的受限上下文並明確說明它們的相互關係，來處理大型模型。

重構已發展成一種眾所周知的技術，而且大多數軟體開發團隊至少聲稱定期進行重構。然而，許多團隊並未了解重構可以在其中使用的不同工作流程，因此錯失了有效將重構納入其開發活動的機會。在此簡報中，我探討了各種不同的工作流程。我希望它能鼓勵團隊更深入地將重構整合到其工作中，進而產生設計更佳的程式碼庫，讓加入新功能變得更快速、更輕鬆。

「抽象分支」是一種技術，用於以漸進的方式對軟體系統進行大規模變更，讓您可以在變更仍在進行時定期發布系統。