回首过去，我仍然不敢相信我做到了。
当我从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次提交了。——译者注