回首過去，我仍然不敢相信我做到了。
當我從2011年年末開始為Netty做貢獻時，我怎麼也想不到我會寫一本關於Netty的書，並且成為該框架本身的核心開發者之一。
這一切都始於我在2009年參與的Apache James項目，一個在Apache軟件基金會下開發的基於Java的郵件服務器。
像許多應用程序一樣，Apache James需要構建在一個堅實的網絡抽像之上。在考察提供網絡抽像的項目領域時，我偶然地發現了Netty，並且立即就愛上了它。在我從用戶的角度更加地熟悉了Netty之後，我便開始轉向改進它和回饋社區。
儘管我第一次貢獻的範圍有限，但是很快變得明顯的是，進行貢獻以及和社區進行相關問題的討論，尤其是和項目的創始人Trustin Lee，對於我的個人成長非常有益。這樣的經驗牢牢地吸引了我，我喜歡將我的空閒時間更多地投入到社區中。我在郵件列表上提供幫助，並且加入了IRC頻道的討論。致力於Netty開始是一種愛好，但很快就演變成了一種激情。
我對Netty的激情最終導致我在Red Hat就業。這簡直是美夢成真，因為Red Hat僱傭我來致力於我所熱愛的項目。我最終知道了Claus Ibsen在那時正（現在仍然）致力於Apache Camel。Claus和我認識到，雖然Netty擁有堅實的用戶基礎以及良好的JavaDoc，但是它缺乏一個更加高級別的文檔。Claus是《Camel in Action》（Manning，2010）的作者，他給了我為Netty寫一本類似的書的想法。關於這個想法，我考慮了幾個星期，最終接受了。這也就有了本書。
在編寫本書的過程中，我也越來越多地參與到了社區中。伴隨著超過1000次的提交[1]，我最終成為了僅次於Trustin Lee的最活躍的貢獻者。我經常在世界各地的各種會議以及技術聚會上演講Netty。最終Netty開啟了另一個在蘋果公司的就業機會，我目前在雲基礎設施工程團隊（Cloud Infrastructure Engineering Team）擔任資深軟件工程師。我繼續致力於Netty，並且經常貢獻回饋社區，同時也幫助推動該項目。
Norman Maurer
蘋果公司，雲基礎設施工程
我在馬薩諸塞州韋斯頓的Harvard Pilgrim Health Care擔任Dell Services的顧問時，就主要側重於構建可復用的基礎設施組件。我們的目標是找到這樣一種擴展通用代碼庫的方式：它不僅對通常的軟件過程有利，而且還能將應用程序開發者從編寫既麻煩又平凡的管道代碼（plumbing code）的責任中解脫出來。
我一度發現，有兩個相關的項目都在使用一個第三方的理賠處理系統，該系統只支持直接的TCP/IP通信。其中一個項目需要使用Java重新實現一個文檔不太詳細的構建在供應商的專有的基於分隔的格式上的遺留COBOL模塊。這個模塊最終被另一個項目取代了，那個項目將使用較新的基於XML的接口來連接到該相同理賠系統上。（但是使用的仍然是裸套接字，而不是SOAP！）
在我看來，這是一個理想的開發一個通用API的機會，而且也充滿了樂趣。我知道將會有嚴格的吞吐量和可靠性要求，並且設計也仍然在不斷地演進。顯然，為了支持快速的迭代週期，底層的網絡代碼必須完全和業務邏輯解耦。
我對於Java的高性能網絡編程框架的調研把我直接帶到了Netty面前。（在第1章開頭讀者會讀到一個假設的項目，它其實基本上取材自現實生活。）我很快就確信了Netty的方式，使用可動態配置的編碼器和解碼器，能夠完美地滿足我們的需求：兩個項目將可以使用相同的API，並部署所使用的特定數據格式所需的處理器。在我發現該供應商的產品也是基於Netty的之後，我變得更加堅信了！
就在那時，我得知有一本我一直都在期待的叫《Netty實戰》的書正在編寫中。我讀了早期的書稿，並帶著一些問題和建議很快和Norman取得了聯繫。在我們多次的交流過程中，我們常常會談到要記住最終用戶的視角，而且因為我當時正在參與一個實實在在的Netty項目，所以我很高興地擔當了這個（合著者/最終用戶）角色。
我希望，通過這種方式，我們能夠成功地滿足開發者們的需求。如果您有任何關於我們如何能夠使得本書變得更加有用的建議，請在https://forums.manning.com/forums/netty-in-action聯繫我們。
Marvin Allen Wolfthal
Dell Services
[1] 截至中文版出版前，已經超過2000次提交了。——譯者注