Addison-Wesley Professional Ruby Series: Obie Fernandez, Series Editor
The Addison-Wesley Professional Ruby Series provides readers with practical, people-oriented, and in-depth information about applying the Ruby platform to create dynamic technology solutions. The series is based on the premise that the need for expert reference books, written by experienced practitioners, will never be satisfied solely by blogs and the Internet.
The Merb Way
Upper Saddle River, NJ • Boston • Indianapolis • San Francisco
New York • Toronto • Montreal • London • Munich • Paris • Madrid
Capetown • Sydney • Tokyo • Singapore • Mexico City
Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals.
The author and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein.
The publisher offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales, which may include electronic versions and/or custom covers and content particular to your business, training goals, marketing focus, and branding interests. For more information, please contact:
U.S. Corporate and Government Sales
(800) 382-3419
[email protected]
For sales outside the United States please contact:
International Sales
[email protected]
Visit us on the Web: informit.com/aw
Editor-in-Chief
Mark Taub
Acquisitions Editor
Debra Williams Cauley
Development Editor
Michael Thurston
Managing Editor
John Fuller
Project Editor
Anna Popick
Copy Editor
Barbara Wood
Indexer
Richard Evans
Proofreader
Barbara Wood
Technical Reviewers
Matthew Knox
Jen Lindner
Editorial Assistant
Kim Boedigheimer
Cover Designer
Chuti Prasertsith
Compositor
ITC
Library of Congress Cataloging-in-Publication Data
Savas, Foy.
The Merb way / Foy Savas.
p. cm.
ISBN 978-0-321-60638-9 (pbk. : alk. paper)
1. Web site development. 2. Merb (Electronic resource) I. Title.
TK5105.888.S2775 2009
006.7’6—dc22
2009013263
Copyright © 2009 Pearson Education, Inc.
All rights reserved. Printed in the United States of America. This publication is protected by copyright, and permission must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise. For information regarding permissions, write to:
Pearson Education, Inc.
Rights and Contracts Department
501 Boylston Street, Suite 900
Boston, MA 02116
Fax: (617) 671-3447
The code in this book may be distributed only subject to the terms and conditions set forth in the MIT License.
The MIT License reads:
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation to the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
ISBN-13: 978-0-321-60638-9
ISBN-10: 0-321-60638-8
Text printed in the United States on recycled paper at Donnelley in Crawfordsville, Indiana.
First printing, June 2009
Contents
1.1 Generating a new application
1.2 The layout of a Merb application
1.5 Understanding the Merb stack
1.6 An overview of Merb internals
1.6.1.2 BootLoader::DropPidFile
1.6.1.4 BootLoader::BuildFramework
1.6.1.5 BootLoader::Dependencies
1.6.1.6 BootLoader::MixinSession
1.6.1.7 BootLoader::BeforeAppHooks
1.6.1.8 BootLoader::LoadClasses
1.6.1.10 BootLoader::MimeTypes
1.6.1.12 BootLoader::SetupSession
1.6.1.13 BootLoader::AfterAppLoads
1.6.1.14 BootLoader::SetupStubClasses
1.6.1.15 BootLoader::ChooseAdapter
1.6.1.16 BootLoader::StartWorkerThread
1.6.1.17 BootLoader::RackUpApplication
1.6.1.18 BootLoader::ReloadClasses
1.6.1.19 BootLoader::ReloadTemplates
2.3.1.1 Using interactive Merb
2.3.1.2 Using the audit routes rake task
2.4.2.3 Segment-specific regular expressions
2.4.4 Full regular expressions
2.7.1 Standard resources routing
2.7.2 Singular resource routing
3.1 From request to controller
3.1.2 How requests get dispatched
3.1.3 The controller’s perspective
3.2.3 The application controller
3.2.4 The exceptions controller
3.3.3 Organizing controller methods
3.3.3.1 Sharing a nonaction method
3.3.3.2 Making methods available to subclasses
3.3.3.3 Increasing readability of an action
3.3.4 Setting callable actions
3.5.2 Redirects after POST requests
3.5.3 Redirecting in before filters
3.6.3 The exceptions controller
3.7.1 How templates are compiled
4.1.4 Merb’s block-aware enhancer
5.3.1.1 Automigrating the DB schema
5.5.2.1 Special query parameters
5.5.2.2 Lazy loading of collections
5.5.2.3 Lazy loading of properties
5.5.2.4 Strategic eager loading
5.5.3.1 Using update_attributes
5.5.3.2 Original and dirty attribute values
8.3.2 Session store containers
8.3.3 Session storage mechanisms
10.1.4 Custom delivery methods
Foreword
I viewed the Merb project with a big dollop of suspicion almost from the very start. First of all, it started out as a really simple concept, but got a lot more complicated as additional contributors got involved. And whether my suspicion was misplaced or not, I couldn’t shake the feeling that the Merb people were insisting on reinventing Ruby on Rails simply to be difficult.
Merb isn’t that different from Rails, nor is it a major improvement as far as I was concerned. It was only slightly better (in some regards), and only slightly different from Ruby on Rails. Sure there were some benchmarks showing big performance gains for using Merb, but I was not convinced enough to switch. And I couldn’t bear to use Merb and Rails concurrently. You see, they were very similar, yet different in subtle ways. The last thing I want to do when I’m programming on hard deadlines is to slow down to remember the differences between Merb’s render method and the one in Rails, etc.
Life continued, and while I was very happy and making a ton of money working with and writing about Rails, I still occasionally looked at Merb, if only to see what they were up to. Sure enough, by 2008 my perception of Merb had started to change. I met Foy Savas and he gave me the gist of why it would make sense to write The Merb Way. I concurred and Foy got busy writing.
As Merb approached a 1.0 release, it appeared that Yehuda Katz and his band of merry discontents were actually achieving a viable platform, one that would attain permanent status as an alternative to Rails. I started hearing about significant production projects running on Merb, such as yellowpages.com. My appreciation for Merb grew, as I got familiar with the project goals and noticed how the competition was acting as a healthy stimulus for Rails to not rest on its laurels. I wasn’t ready to switch to Merb myself, since my key criterion is maturity, which Rails has in spades, but no longer was I suspicious.
In November of 2008 I was extremely happy about Foy being almost finished writing the first manuscript of this book, knowing that it would be a good complement to the Professional Ruby Series and a good companion for The Rails Way. Foy delivered an awesome conference presentation in Boston where he covered some of the key concepts from the book in an engaging and entertaining manner—the crowd ate it up and I knew The Merb Way would be a winner.
It wasn’t too many weeks later that the unthinkable happened. After an eruption of feuding between members of the Rails and Merb teams, some secret meetings occurred and shocking news was unveiled right before Christmas: DHH and Yehuda happily proclaimed that the core teams of both frameworks were merging and that within a year, the Merb codebase would be merged with Rails in order to produce Rails Version 3, after which development of Merb would discontinue.
The million-dollar question (okay, not quite that much) for Foy and myself as the Series Editor was whether to continue with the publication of The Merb Way. After all, if the Merb framework was going away, then what was the point?
After letting the matter settle for a while, we arrived at our answer, which you already know since you are holding this book. It turns out that learning about Merb is valuable in a number of important ways. First, Merb is still used rather widely and we suspect that its lifetime will exceed what the current core team has in mind. Second, Foy is a gifted writer and his descriptions of the philosophies that impacted the design and implementation of Merb are definitely useful to everyone who will be affected by the changes that will happen in Rails 3.
It’s with great pleasure that I welcome the incomparable Foy Savas and publish The Merb Way as a full-fledged and proud installment of the Professional Ruby Series. I sincerely hope you get as much out of this book as I have.
Obie Fernandez
March 31, 2009
Acknowledgments
First off, thanks go to all the Merb and DataMapper contributors. Obviously, no Merb would mean no Merb Way, but that’s certainly not all I want to thank them for. The elegance of both Merb and DataMapper, especially within their implementations, profoundly sets off my passion for holding code to an even higher standard of clarity. Consequently, throughout this book I have highlighted and included extensive amounts of Merb and DataMapper source code, truly making the contributors to both projects contributors to this book as well. I would like to thank those individuals with whom I have personally interacted the most: Matt Aimonetti, Ben Burkert, Dirkjan Bussink, Lori Holden, Michael D. Ivey, Michael Klishin, Dan Kubb, Carl Lerche, Daniel Neighman, Sam Smoot, Ezra Zygmuntowics, and especially Yehuda Katz.
Completing this book against a backdrop of changing technology demanded the help of numerous friends and editors. Without their advice, analysis, and sharp eyes, I don’t know how it would ever have gotten done. To Sophia Chou, Andrew Guay, Kieran Huggins, Matt Knox, Jennifer Lindner, Bryan Ray, and Michael Thurston—thank you for each and every note and correction you made.
A huge thank you goes to both Obie Fernandez and Debra Williams Cauley. You two are truly the driving force behind the Addison-Wesley Professional Ruby Series and the reason why it produces such high-quality books. Obie, had you not spotted the importance of Merb at such an early stage, inspired me with your own book on Rails, and pushed me to write one on Merb even after the frameworks merged, who knows if such a topic would have received the treatment it deserved? And Debra, simply wow. I know coordinating this book was no easy job, but you did so with such a seemingly paradoxical mix of patience and drive that I will remain thankful forever.
Finally, my warmest thanks and love go to all the members of my family who undeniably play a strong part in all that I do. Without your support, encouragement, perspective, and insight, I don’t know where, or more important who, I would be—thank you, all.
Merb pastie
Anything that starts off with pure code is good in my book. Pun intended, here is Ezra Zygmuntowicz’s original Merb pastie, as found at http://pastie.org/14416, here formatted for the pages of this book.
Introduction
A way that can be taken rarely stays the way. A name that can be given rarely stays the name.
—Laozi
(translated by your author)
The first two lines of the Dao De Jing capture truths so fundamental that we find them everywhere—including, without exception, in this book. Originally entitled the The Merb Companion, it was intended to be the advanced practitioner’s bible. But the little framework named Merb grew quickly, so much so that the Rails world took notice, and before long, the core teams came together and decided to merge the two. Yet despite Merb’s fundamentals being seen as the basis for the features of the future, Rails conventions needed to be maintained long-term. Incidentally, this book’s content was left in an awkward limbo. Should we wait for the completion of the merge or perhaps publish immediately? Should we preserve the chapters we had written so far or produce them anew after the merge? Soon, however, an epiphany came. Though the book had material highly relevant to the Merb developers of the day and was equally suitable for bringing foresight to the Rails developers of tomorrow, its greatest and lasting potential was in shedding light on how Merb, the framework that even Rails envied, had been designed. Thus, we arrive here, at the introduction of The Merb Way.
Born a pastie
Zoom back to September 9, 2006. If you were using Rails, it was version 1.1. As for Git, it was still just something the Linux kernel used. So naturally, when Ezra Zygmuntowicz needed to publicly distribute the then only 120-line source code for Merb, a pastie made the most sense. Turn back a few pages and you’ll find that pastie, prepended to this book in all of its glory. Look it over once and you’ll realize Ezra had an itch to scratch: fast Ruby template rendering with the smallest possible memory footprint. To do this he used only two gems, Mongrel and ERB, which, for those keen on etymology, also serve as the roots of the name Merb itself. But like any project that starts off both small and practical, it grew. A few months later a gem was put up on RubyForge. For a while it came with an example app that touted Merb’s ability to handle file uploads while not locking out other requests. This became the most popular use of Merb, often appearing coupled with Rails applications in the wild.
Created by rebels
But Merb has moved far beyond the stage when its application generator could produce the uploader application. This may have been because it quickly became a breeding ground in which Rails concepts could be rethought. Eventually, this led to a shared vision among developers that Merb would be Rails done right. Thankfully, the openly opinionated nature of Rails actually kept them away from simply adopting alternative opinions. Instead, they chose as one of their maxims agnosticism, in the form of opt-in modularity. This allowed Merb application developers to work with whatever tools they needed for their projects. Merb’s versatility meant that it would become the underlying framework for numerous customized stacks that otherwise did not easily fit within the opinions of Rails. Its developers, consequently, have often been thought of as rebels from the Rails mentality, since many of them maintain strong opposing views on particular Rails opinions.
However, that’s not all there is to the Merb development story. The crowd of developers also had an arguably more scientific bent, aiming to make the best selection of the methods they employed through microbenchmarks. Ruby is often cited as one of the world’s slowest programming languages from a computational perspective, but to the developers of Merb, this didn’t mean that microseconds didn’t matter. After all, web development frameworks are often tested in terms of responses per second. So when it came to Merb internals, whether it was in route matching or filter chaining, only the fastest Ruby constructs were used. The end result was Merb blazing past Rails in response time benchmarks. More profoundly, Merb raised the bar for Ruby web framework performance in general, finally allowing Ruby to win when pitted against other frameworks from different languages.
Interestingly enough, this combination of performance and modularity is also indicative of another Merb development character trait: its desire to solve higher-level problems. Whereas Rails features have nearly consistently been born of necessity, Merb’s focus has been on abstract goals like versatility and design. This has pushed the limits of what can be done with Merb, resulting in advancements like the abstract controller class, code slices, and arbitrary application layout. In sum, Merb in many ways conceptually broke the “frame” in framework by thinking of itself less as a way to produce Model-View-Controller (MVC) web apps and more as a highly modular platform upon which nearly all Ruby web development, no matter how unusual, can occur.
The future of Rails
Put all this goodness together, and you’re bound to attract the attention of most developers. Not surprisingly, teams large and small began using Merb as a full application framework in production environments for their most demanding applications. This finally put Merb to the test, and the results were completely in line with its benchmarks: more responses per second with a solidly smaller memory footprint. All of this occurred at the cusp of its reaching its 1.0 release on November 7, 2008.
Quickly the Merb development team oriented itself toward larger goals through what would have been a 2.0 release. Objectives included, among other things, an abstracted Object Relational Mapper (ORM) that could be used to create an agnostic admin panel and convenient direct routing to templates. But with the stable release already out, developers at large began taking Merb much more seriously, and soon online comment wars fanned flames between the Rails and Merb core teams. Thus prompted to confront each other, the core development teams began to talk it over. However, soon they began earnestly asking themselves whether the large amount of duplication between the two frameworks was warranted. At the end they concluded two things: first, that each side had aspects that would be beneficial to the other, and second, that yes, they could work together. Announced officially on December 23, 2008, the Rails and Merb development effort would be merged, with a promise of a smooth transition from both Merb 1 and Rails 2 to the combined Rails 3.
So what can we expect from this merger? Well, above all will be the fusion of attitudes and objectives from both sides. The Rails of the future will undoubtedly appeal to developers in both pragmatic and idealistic ways. Merb will bring speed, performance, and modularity along with a tempering of the preestablished Rails opinions. We will see a flowering of custom Rails stacks, some of which may eventually push the limits of the Rails framework itself. Toward what—who knows? But with the possibility of such a greatly expanded domain, two things are certain. The first is that anyone in software who needs to build an agile and sophisticated web application upon a high-performance framework should definitely get on this train. The second, which applies more to developers themselves, is that a firm understanding of the design decisions behind Merb’s development will not only prepare them for the future of Rails but can also open up their own talents through the elegance of its code.
This book is thus focused on giving developers the deepest possible understanding of Merb itself. While you may use it as a reference guide in the development of Merb applications (which we strongly recommend without hesitance until the release of Rails 3), you may also appreciate its guided exploration of the Merb source. That said, for those afraid of code, it may perhaps be a good time to put this book back on the shelf. Everyone else, be warned; we’re going to cut deep into the framework itself, revealing not only what was done, but what can be learned from it. As you move forward, do not lose focus. After all, they say that one should always aim to learn from the best, and through Merb, the framework that without exaggeration brought the Rails monoculture to its knees, you are doing just that.
About the author
Foy Savas runs Assembly, a Boston-based web consultancy focused on innovative technology. In the past, he has acted as CTO of a large health and fitness site and as a lead consultant for several white-labeled web applications. Foy is also one of the earliest adopters of Merb and over the past year has taken several Merb applications, both small and large, into production. Actively involved in the Merb open-source ecosystem, he has also been a core contributor to both Merb and DataMapper.