Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Mongrel Shortcuts

Posted by samzenpus on Mon Dec 18, 2006 03:33 PM
from the serve-it-up dept.
Simon P. Chappell writes "I'm not normally much of a one for reading and learning out of eBooks, but after a little gentle persuading from my regular contact at the publisher, I agreed to take a look at their Mongrel Shortcut eBook. Mongrel is a pure Ruby web server, and while it is normally associated in most people's minds with Ruby on Rails, it is actually possible to run it standalone, anywhere that you have Ruby. As one who is very firmly in the "dead tree" camp for my choice of reading media, I was surprised to find myself impressed with Addison Wesley's range of Shortcut ebooks; they really are close to the readability of regular books." Read the rest of Simon's review.


The obvious market segment for this book is the Ruby on Rails developer who wants to understand more about the server that their application is running on and who would like to take more responsibility for it's installation and ongoing maintenance. A second target audience would be those who are looking for a small, efficient and robust web server. Mongrel, through strict adherence to the HTTP 1.1 specification has stayed small and very resistant to many forms of Internet attacks. There is a demand for that kind of server and this book will help those who need it.

Interestingly, these shortcut books are not available through the normal online bookstores. They are currently only available through www.awprofessional.com/ruby or www.informit.com/shortcuts. I'm not sure of the logic behind this and I wonder if that isn't going to hamper sales efforts.

At the risk of pointing out the obvious, this is an eBook and as such is supplied as a Portable Document Format (PDF) file. There are two big positives for me with this book. The first is that the file has no Digital Rights Management technology. This means that you are free to copy it to your computer, but you cannot share the file with anyone else. This is very reasonable approach for Addison Wesley to take and I applaud them for this. Now that they've shown their trust in us, I just hope that those who purchase this book will abide by those conditions. (Apparently, they don't trust me as much as they trust you, because my copy has "Review Copy Only" on the top of each page! :-)

The second positive with this book is that it's formatted with landscape orientation. This means that the long side of the page runs horizontally and thereby allows the whole page to fit nicely on a standard laptop screen with a very readable text size. Landscape orientation makes for very a clean page layout, a matter of vital importance if you're expecting folks to read it from a computer screen.

As far as the structure of the content, this book eschews chapters in favor of sections. Of course, with no section more than twenty pages long, calling them chapters would have been stretching a point. The nine sections cover about every aspect of using Mongrel that you could hope for in a short book.

The first section introduces the book and explains the formatting used as well as the special little sidebars called "Zed Sez". These are highly opinionated, but very insightful, asides on aspects of Mongrel; they cover reasons for writing it and why it was written the way it was. Section two is an introduction to Mongrel itself, the benefits of using it and the license that it is made available under. Section three works through everything you need to know to get started with Mongrel. Naturally, this includes installing it and basic usage.

Section four covers configuration and the array of command-line options available to the developer or administrator running Mongrel. Section five looks at production deployment and examines a typical deployment. Now, production deployments are an art in themselves, so not every aspect can be covered in a section like this, but it does get you started and presents a not unreasonable approach. Section six explores the options for extending Mongrel. Write your own commands, handlers and plugins; this section will show you how.

Section seven shows how to debug your Mongrel configuration and applications. Section eight looks at performance, another thing that's hard to generalize. Here the emphasis is mostly on gathering data so that you can make meaningful decisions for your own situation. Finally, there is a collection of resources; links for Mongrel, and frameworks that run on it.

In addition to the reasons to like the book that I mentioned back at the start of the review, the book is very authoritative. Having Zed Shaw, the primary author of Mongrel, as the co-author is a powerful help of course. Speaking of Zed, I very much enjoyed his little "Zed Sez" sidebars. To describe his style as "pithy" might be an understatement, but they are certainly very informative and they give interesting insight into the writing of a rising star open-source software package.

For all of the positives, there is no hiding the fact that this Shortcut eBook is only 106 pages long. One of the consequences of this is that there is reduced depth. The material that is in the book is very good, but I know that there were a couple of places where more material would have been very useful. So, if you normally look for vast tomes of ultimate completeness, this might not be a good selection for you.

In conclusion, this seems like a very useful guide for anyone who is starting out to configure and use the Mongrel web server for their Ruby projects.


Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.

  • Slashdotter writes eBook giving opinion of eBooks.

  • by tcopeland (32225) <[tom] [at] [infoether.com]> on Monday December 18 2006, @03:41PM (#17291358) Homepage
    They are indeed one of the nicer parts of the book. One of them says, more or less, "if you're SSH'ing into your server more than once a week, you haven't automated things well enough." So true!
  • Positive Reviews (Score:3, Interesting)

    by Anonymous Coward on Monday December 18 2006, @03:42PM (#17291364)
    If you take a look at the reviews Simon has done at http://techbook.info/ [techbook.info] you will see there isn't a negative review among them. So take whatever you read with a grain of salt. This is probably why the publishers keep bugging him to review their books.
    • Quite a few unfortunately if the experience of TheServerSide.com is anything to go by. Also you can expect to see rails enthusiasts injecting comments like 'This is so much easier in Rails, I only had to think about it and the scaffolding automatically provided an implementation using only two variables, a semi colon and 3 whitespaces.' in any discussion of web development technology.
      • Re: (Score:1, Informative)

        by Anonymous Coward
        Yeah, because anyone that uses Rails framework professional relies solely on its scaffolding features.

        I think you're confusing Ruby with Python regarding the white-spacing.. no semi-colons either. (though you can use them if you _really_ want.)

        You aren't Joel Spolsky are you?

        If you don't like reading book reviews you can make the stories not show up in the preferences of your Slashdot account.
    • Re: (Score:3, Interesting)

      Have you ever actually used Rails? Just try Rails with the Goldberg generator once and you'll never go back. I've neverseen a site that one could customize so easily just by using it, including access permissions, view configuration, content, you name it. This is just one of very many powerful generators available for Rails.

      Aside from all its technical merit, the fact that it's open source alone should tell you there's probably not much (if any) commercial backing to it. Businessmen, not generally (and
      • "people" is a plural noun, and thus it's correctly "people's" rather than your "peoples'" when using the possessive. i'd respect your intelligence more if your grammar was correct.
        • The noun "people" takes an irregular plural form. This makes it an exception to general grammar rules. I'd respect your integrity more if you didn't make the petty move of intentionally ignoring the fact that grammar mistakes on irregular plural possessives are something people do quite commonly and are often even typos. You're clearly using that intentional denial of reason as an ad-hominem attack to discredit my reason and believe what you want to.

          Oh, and I'd respect your intelligence more if you real
          • the ad-hominem attack was not used to discredit your argument (such a claim is nowhere in my post, explicitly or implicitly), it was used to personally discredit you by way of illuminating the irony of your debasing the intelligence of others based upon poor grammar while making a grammatical error yourself.

            i stand by the personal attack while fully respecting your argument. goldberg looks neat.
            • I see where the misunderstanding is, then. The direct quote from me is "most of the time I respect the intelligence of a person more when their spelling and grammar is correct". This only states that I get a positive impression of people with correct grammar. You implicitly assumed the inverse, which is a reasonable thing to do most of the time, but this time it wasn't correct. To me, correct grammar is evidence of intelligence, but I don't believe incorrect grammar is evidence against it: it's no evide
              • point taken. there's an annoying culture of "grammar nazi-ism" here on slashdot, and while your post content was informative enough, it then seemed as though you took the opportunity of your writing to affiliate yourself therewith.

                but you're right, i can't assume that poor grammer is met with a poor impression on your part just because you claim to gain a positive impression from good grammer (& capitalization), and my error in this assumption is awknowledged.

                sorry for the trouble...the zeal with which
        • That's what I thought too. I was VERY skeptical of all the hype. Until I tried it, and found that I like it. Not necessarily Rails specifically (ActiveRecord rocks though!), but the whole idea of quick-to-implement best-practice MVC web apps that are flexible enough to build anything you want with. I'm going to try Django now too. One cannot deny that Rails is an inspiration for a whole new genre of tools in many languages (Catalyst, Django, Grails, Trails, Seaside, etc). I believe that Rails is a disruptiv [wikipedia.org]
  • Its HTTP request parser is C, generated by the Ragel state machine compiler.
    • Maybe thats why they called it Mongrel.
    • Nothing can be _pure_ Ruby. Ruby binds itself to the lowest level architecture it can through C. Hey - it's better than assembler. That'd just create maintenance headaches up the yin-yang: they'd have to write their own implementation on every hardware platform rather than using the standard C ones, and every time the C implementations got an update they'd have to update their stuff by hand.

      C is a language that is low enough level that I see no significant performance hits in abstracting to it over as
      • Mongrel does the ruby equivalent of "dropping down to assembly for the speed critical parts". This makes a difference for some people. For instance it means you need a C compiler or pre-compiled binary for your architechture to install mongrel. This is in contrast to a "pure" ruby lib in which all the lib's source files are in ruby.
    • That's because any sentence that includes the words "ruby interpreter" and "performance" by law must also include the words "dog slow".

      Maybe that's why it's called "Mongrel".
  • by tcopeland (32225) <[tom] [at] [infoether.com]> on Monday December 18 2006, @03:46PM (#17291420) Homepage
    It's supplanted Apache+FastCGI as the preferred way of deploying Rails apps in a very short time and seems to be a much better solution all around. "gem install mongrel mongrel_cluster" sure beats the steps necessary to get FCGI running.

    I wonder how many people have upgraded to Apache 2.2 [blogs.com] in order to get mod_proxy_balancer to balance between Mongrel instances... that's why I did it for indi [getindi.com].
    • I wonder how many people have upgraded to Apache 2.2 in order to get mod_proxy_balancer to balance between Mongrel instances... that's why I did it for indi.

      You might want to have your site check for the availability of javascript, otherwise, you get a rather uninformative code dump in the screen.
    • Don't forget lighttpd+fcgi if you deploy ROR on linux. For a single ROR app it's trivial to set up, didn't try running more. I don't know how it compares to mongrel.
      • Nginx gets my vote for a http server facing onto Mongrel. http://nginx.net/ [nginx.net]

        I'm a .NET dev so having to set up web servers on a Linux box aint my favourite passtime... leave the politics outside, it's my paycheck not yours... but I had a need to test a RoR app I'm working on for both Windows and Linux, which quickly became a decision to make it Linux only... anyhow, pretty much all the options I was chewing my way through were driving me nuts, with nginx being last on the list before saying "screw it".

        Took m
        • >I'm a .NET dev so having to set up web servers on a Linux box aint my favourite passtime... leave the politics outside, it's my paycheck not yours... but I had a need to test a RoR app I'm working on for both Windows and Linux, which quickly became a decision to make it Linux only...

          see, it's not a matter of politics :D
          Thanks for the comment, I hope i'll have never to discuss ror+mongrel+nginx vs lighttpd-fcgi: the tongue's gonna end all knotted up.
      • Indeed, if you're interested in the lighttpd+fcgi approach you might want to check out this article on my blog [wilf.me.uk] which covers virtual hosting multiple Rails apps with lighttpd and also how to make it co-exist with Apache on the same server by using 2 IP addresses.
      • I ended up using Pound as the load balancer in front of Mongrel. Directions for OS X are http://www.jaredrichardson.net/blog/2006/11/21/#in stalling-pound/ [jaredrichardson.net] but it's fairly close to doing the same on Linux.
  • by Doc Ruby (173196) on Monday December 18 2006, @04:17PM (#17291916) Homepage Journal
    There's a difference between a mere httpd (HTTP protocol server) and a "Web Server" that must include one. I wish there were a truly minimal httpd written in very portable code like Ruby, Perl or Java, that could use existing webserver plugins like Apache's and, say, WebSphere's, without modification. Just install (perhaps recompile cross-platform), and get the incremental features. With the same data formats, APIs and even typical bug behavior.

    Why do we have to reinvent the wheel every time we reinvent the car?
    • A "truly minimal" httpd that can use Apache modules is hardly going to be minimal. In fact it would pretty much be Apache.

      > Why do we have to reinvent the wheel every time we reinvent the car?

      Because they're web servers, not cars, and frankly the existing standards are either too dinky to provide a common base, or the bigger standards are confined to some other language (like Java) or just are too bureacratic for most uses (virtually anything SOA-related). But I don't see anyone reinventing HTTP, Javas
      • Can you back that up? Is the current Apache without modules (but with interfaces) truly factored to nothing but the required HTTP/1.1 responder? I haven't looked at the code since I distributed one of the early patches (before it was even called "Apache"), but I think it includes more than just the minimum.

        The point of a minimal HTTP server would be to factor out all standards support except TCP/IP (if that) - even HTTP could be a module. I didn't say people are reinventing HTTP/Javascript/HTML, though they
      • In fact, I'm asking for an httpd built on an archtecture like a microkernel OS. Just enough code to offer "plugin" (subprocess) interfaces, and access HW properly.

        The fact is, mongrel does not run any existing modules that make HTTP worth running, which is the whole point.
        • (this is the same AC as above) the core apache server is pretty small, and most things are modules that are loaded in. there is also lighttpd, which doesn't load apache modules, but is a pretty lean & mean webserver h
  • I first I thought that it was some kind of platform (written in ruby) for reading ebooks!
  • In conclusion, this seems like a very useful guide for anyone who is starting out to configure and use the Mongrel web server for their Ruby projects.

    Intriguingly, though, the book doesn't appear to cover using Mongrel as a library from Ruby at all. The closest it gets is in "Handlers" in Section 6, but this is still working with the regular Mongrel application rather than Mongrel as a library. Admittedly, many people don't want to use Mongrel as a library, but it makes a great replacement for the slow WEB
  • I wonder how this one compares to its O'Reilly equivalent: http://www.oreilly.com/catalog/mongrelpdf/ [oreilly.com]
  • From http://rubyforge.org/projects/mongrel/ [rubyforge.org]
    A small fast HTTP server written in (mostly) Ruby that can be used to host web frameworks directly with HTTP rather than FastCGI or SCGI.
    • Whilst I'm sure it may break at least three or four contrived grammar "rules" that someone made up at some point in history, it's a common usage that has existed for probably longer than any of those rules.
  • Mongrel --> Ruby (Rails)

    Medusa --> Python (Zope)