Afterword

If DHH ain’t doing it, you don’t do it.
(Seems every time some clever fellow gets into trouble it’s because of that.)

—Zed Shaw

This tactfully derisive quote got the last word in Obie Fernandez’s The Rails Way, and for the many who had reached the opinionated limits of the Rails framework it seemed all too true. Aiming to rectify the dilemma with a framework that realistically was built to be as similar as possible, the Merb team pushed the limits of modularity and stack agnosticism. In doing so, they succeeded in proving that the implementation behind Rails could conceptually be cleaned up, and that such a pursuit was ultimately worthwhile because it provided the foundation of a richer, more versatile web framework.

Now that the frameworks are merging, we are left to wonder if any truth in Zed’s quote will persist. My advice is that the jury remain out, not simply because a more modular Rails may fall prey once again to too-limiting opinions, but because software inherently demands strongly coherent vision, and such vision naturally conflicts with the changing demands and use cases of the future.

Thus, and in general, in order to achieve fluidity and the long-term success of our projects, we must want to experiment and always stay curious with regard to implementation. This especially applies within the realm of open-source software, where hacking forms the cornerstone of all advancement. With that in mind, it’s hard to deny that a deep understanding of the Merb framework has been my principal concern throughout this book. Too many technical books shallowly target only interfaces, but true appreciation demands at least some knowledge of internals. I hope, therefore, that wherever coding may lead you, you don’t forget that all software is within your grasp if only you possess the interest and time. All this said, may the future of Ruby be bright, but our minds ever brighter.