Forgot your password?

Advanced Rails 170

Posted by samzenpus
from the read-all-about-it dept.
yukster writes "As Ruby on Rails rocketed into the development community's hearts and minds a few years ago, the number of books on the subject climbed with it. However, a lot of these books were introductory in nature (Agile Web Development with Rails, Beginning Rails, Build Your Own Rails Applications, etc.). What's a budding Rails-head to do once they've gotten the basics down? Books like Advanced Rails, which was released late last year by O'Reilly, aim to fill this void." Keep reading below for the rest of Ben's review.
Advanced Rails
author Brad Ediger
pages 357
publisher O'Reilly
rating 10
reviewer Ben Munat
ISBN 0596510322
summary Extensive reference for advanced topics in Ruby on Rails development
Author Brad Ediger has been kicking around the Rails scene since the pre-1.0 days. Though not a Rails "luminary" necessarily, he certainly qualifies as an advanced user. He is CTO for a Real Estate tech company called Tasman Labs and runs a web design (and Rails consulting) firm called Madriska Media Group. He seems like a sharp cookie and a decent writer.

Advanced Rails covers quite a bit of territory, going for breadth rather than depth most of the time. Each chapter covers a classic, pivotal development concern... well, at least most of them do. The chapters are as follows:

1. Foundational Techniques
2. ActiveSupport and RailTies
3. Rails Plugins
4. Database
5. Security
6. Performance
7. REST, Resources, and Web Services
8. i18n and L10n
9. Incorporating and Extending Rails
10. Large Projects

By "Foundational Techniques", Ediger is referring to Ruby and Rails techniques, principals and patterns like Metaprogramming, Don't Repeat Yourself, and Functional Programming techniques. The chapter also goes into a fair amount detail about the Object/Class/Module relationship. A bunch of this may not be particularly new material for most Rails users who've been at it for at least a few months. However, it's still nice to have all this stuff in one forty page chapter... good to have handy to refer to. Also, there are some nice nuggets in there that could save you some head-scratching. For example, what's the difference between Kernel#lambda and The answer is that, if you *return* a value from the block passed to, the calling method is exited as well, abandoning any code that you might have after it.

If the first chapter feels like it's leaning towards a reference work, the second chapter — which digs into all the goodies offered by ActiveSupport and RailTies — pretty much falls over right into reference-land, complete with a method-by-method listing of features added to standard library classes. This may seem even more like just putting api docs available online into print, but Eidger definitely adds a bit more explanation. And, I haven't really seen anyone give a rundown of just what the heck RailTies does. That's the library that provides the glue to pull together the more famous Rails libraries to make it all work together as rails: generators, initializers, etc. There is definitely some interesting and not necessarily readily available information here.

Chapter three covers Rails Plugins, and is quick and painless. It explains the common files and directory structure in a plugin and talks about how Rails loads them. It also talks about using Piston instead of svn:externals to manage plugins and show some example plugins.

The following three chapters cover more of the classic eternal problems faced in running high-traffic sites: databases, security, and performance. These really make the most sense in an "advanced" book; they are the "brass tacks" that everyone must get down too if they go beyond the "toy app" stage. Ediger talks about the strengths and weaknesses of the various popular database systems. He also goes into the benefits of using the filesystem to store data, which is largely because web servers can make use of fast system calls to dump files straight into the TCP socket. He also covers some advanced db features like composite keys, stored procedures and clustering.

The security chapter isn't all that long and a lot of the info it covers can be found in beginner Rails books... SQL injection, cross-site scripting etc. However, the book would be remiss to not include this material and it is presented in a concise and complete manner. This would be good to refer back to now and then to make sure you haven't slipped in your security awareness. Ediger also doesn't hesitate to make specific recommendations, like "whitelist rather than blacklist".

He also jumps right into recommendations while writing about performance optimization in the next chapter: "Algorithmic improvements always beat code tweaks", "As a general rule, maintainability beats performance", "Only optimize what matters", "Measure twice, cut once". He then goes on to cover specific tools and techniques for uncovering your bottlenecks, from a quick explanation of basic statistics to using httpperf, benchmark, and Rails Analyzer Tools, improving database calls (using indexes and "include" on finders), and the various caching solutions. There is plenty of good information in this chapter; also a good bit of reference next time you need to track down a logjam.

Chapter seven covers RESTful Rails, from the very basic theory as outlined by Roy Fielding to exactly how Rails has chosen to use these concepts, and is the longest chapter in the book. The amount of coverage REST gets seems questionable since Rails has been very heavily into the RESTful approach for over a year and embraced the philosophy so thoroughly that it's hard to imagine anyone using Rails today without being exposed to the concepts.

On the other hand, one can still wire up verb-oriented actions in routes.rb and might be able to get away with ignoring all the RESTful goodness. So maybe there are some out there that can benefit from this chapter. Plus, having such thorough, theory-to-practice coverage allows the chapter to stand on its own as a solid reference to the whys and hows of RESTful Rails. It also has one of the better sections on RESTful routing that I have seen (routes being one of the more mysterious and sometimes frustrating pieces of Rails).

Rails has gotten plenty of grief for its lack of official support for Internationalization and Localization, but in Chapter eight, Ediger lays out the options, such as gettext, Gibberish, and Globalize. He is most enthusiastic about this last library and it does appear to be quite powerful, including support for translating strings, translating model fields, localizing numbers and dates, and even recording what needs to be translated by saving them in the database. Creating multi-lingual websites is a hard problem in any web-development framework and most other frameworks have plenty of head start. However, Ruby and Rails certainly isn't without options and it will only get better.

The next to last chapter of Advanced Rails runs through a number of alternatives to the standard components of the Rails framework. On the database end, it covers DataMapper, Ambition, and Og, giving this last one the most attention. For alternatives to ERB templates, Ediger talks about Markaby, Liquid and Haml, all in a very brisk fashion. He also talks about using traditional Rails components — like ActiveRecord and ActionMailer — outside of Rails applications. The chapter closes with a discussion of how to contribute to Rails (hint: submit a patch... don't just bitch!).

The last chapter is called "Large Projects" and covers some useful information about working on a Rails project with a team, beginning with version control (though anyone who is writing code that covers more than a single file and *not* using version control is just plain insane). This starts with a quick overview of Subversion, however this feels like it is really a set up for making a case for "decentralized version control". Ediger does a good job of explaining these concepts, using Mercurial for his examples. This seems a bit unfortunate, since many people on the Rails core team have embraced Git and it is looking like Rails will eventually move its repository to Git. However, Mercurial has a reputation of being more user-friendly, so that may have influenced his decision. And it's useful information regardless.

Chapter ten continues on to discuss avoiding migration numbering collisions, issue tracking, keeping Rails and required gems within a project, web servers, load balancers, production architecture and deployment tools like Capistrano. This is all covered in a fairly quick fashion so don't expect a lot of depth.

That last sentiment came up often while reading this book. It often felt like Ediger was trying to get every possible Rails-related topic into the book that he could, but didn't want to come out with some 1000-page behemoth. Plenty of the topics mentioned don't have much more coverage than you could get with a quick "googling". However, there is something to be said for being exposed to a lot of tools, projects and concepts in one go, even if the exposure is sometimes superficial. I definitely found reading this book worthwhile and will keep it around to refer back to now and then. I don't know if I'd go so far as to label it required reading, but then again books on web frameworks rarely are.

You can purchase Advanced Rails from Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

Advanced Rails

Comments Filter:
  • by Anonymous Coward on Monday March 17, 2008 @04:23PM (#22776974)
    If you are looking to O'Reilly for Rails info, I'd rather recommend their Rails Cookbox [] , where you can immediately apply what you've learnt to real-world projects. Advanced Rails was just too abstract for me.
    • Re: (Score:2, Informative)

      by Anonymous Coward
      Uff, I can't believe I made the same spelling error twice. That should read "Rails Cookbook". Sorry.
  • by realmolo (574068) on Monday March 17, 2008 @04:24PM (#22776982)
    When you feel like learning a language/framework that won't EVER pay the bills.

    • by Peter Cooper (660482) on Monday March 17, 2008 @04:28PM (#22777038) Homepage Journal
      Yawn, troll. The numbers of people making money are way smaller than with other technologies, that's for sure, but top Rails developers make pretty serious money ($100 an hour is the typical rate I see amongst the Rails developers I'm working with - and a rate I've earned myself for a few months when I was contracting.) Okay, it's not going to blow Java's top, but you can make money in the Rails community. The real money, however, is in developing your own stuff and then selling it on as a going concern. Rails can make this process a lot quicker if you're a developer.
      • Re: (Score:3, Insightful)

        by Sancho (17056)
        Never underestimate the power of buzzwords and glitzy technology? Managers love shiny things!
        • I've found that to be incredibly untrue in the larger corporations I've been involved with. Typically they have overly bureaucratic lists of rules and regulations and while individual managers are keen on various buzzwords and bits of glitzy technology, they typically have to present this to even more higher-ups who will then typically do the thumbs down since their COBOL system (or whatever) is already working okay, supposedly :)
      • by patio11 (857072) on Tuesday March 18, 2008 @07:04AM (#22781424) [] sells a Java application that I wrote. The site itself, while it doesn't look like it, is written in Rails. Nothing really fancy -- it is essentially a purpose-built CMS which allows me to scale one very niche form of content writing horizontally. More content written more efficiently means more visitors, more prospects to sell my product to, and more money for me. Previously, it was just a static HTML site, which was harder to expand and extraordinarily difficult to make efficient sitewide tests and changes to (e.g. does moving the menu around on all the pages cause conversion to the free trial to increase).

        Could I have written it in PHP? Sure. Could I have done it as quickly? Probably not. The problem screams Rails Me -- little application, not all that much complexity (probably under 500 LOC outside of the view templates, which are 99% HTML), and its performance requirements are quite modest. (It typically deals with about a thousand visitors a day, although the application could chug through that in about 10 seconds in my tests, with caching turned off.) As for the exhorbitant hardware costs of the system, I was forced to move up from $7 shared hosting to a $20 VPS so that I could continue doing $1,500 in sales every month. Oh noes.

        Anyhow, like I said, pretty boring. I anticipate, on the basis of the increase in traffic and trial downloads that I've had since launching, that the rewrite will be worth about $100 in additional profits for every hour I worked within the first two months. I keep adding new little features, too -- spent an hour yesterday adding Javascript graphs on the back end -- and it is some of the easiest web programming I've ever done. (I do Big Freaking Enterprise Apps in Java by day.)

        Incidentally, a big "Heck yes" to parent when they said "The real money, however, is in developing your own stuff and then selling it on as a going concern." Why take a fraction of the revenue of your client's website once when you can operate the website yourself and take all of it on an ongoing basis. (And if it gets to be too much work, you hire out the boring stuff to folks who think $10, $50, or $100 an hour is a lot of money.)
    • by misleb (129952)
      Pays my bills.
    • Re: (Score:3, Interesting)

      by Lysol (11150)
      Funny, I know plenty of people paying the bills. In fact, I just got done consulting on a Rails project charging an equivalent rate to what I bill on Java projects.

      Also, a friend's company now has more Rails projects coming through the door than Java ones.

      Here's a nice post [] from a company doing more than just paying the bills.
    • by e4g4 (533831) on Monday March 17, 2008 @04:38PM (#22777142)
      As a full time (read: salaried) Rails developer, I call bullshit.
      • I've noticed that a lot of the crappy Rails developers have gone back to their previous languages. I wondered when it would happen, but there seems to be a pretty big shift... I think that as this happens, we're going to get more trolls that couldn't make it posting about how much (they think) rails sucks.

        I'm a full-time rails dev, have been for the last 2 years. The interwebs are big, lots of room (and money) to go around, so I'm not sure why people feel the need to bash rails so much. Seems like a wast
    • Re: (Score:2, Insightful)

      by DJ Jones (997846)
      Everyone is always quick to bash RoR but I have honestly never heard a well crafted explanation as to why it's an inferior language / framework. I personally use Java, but that's only because I was raised on it.

      So I ask: Why the bashing?
      • by e4g4 (533831) on Monday March 17, 2008 @05:02PM (#22777348)

        So I ask: Why the bashing?
        It's new and different from the J2EE frameworks the many web developers on Slashdot have been developing with for so many years. As such it's wide open to criticism by said developers (in most cases the people bashing it haven't actually taken the time to build anything with it and are simply spouting the criticisms others have leveled at it since it entered the scene). As a Rails developer myself, I can tell you that while Rails is not the holy grail (that some claim it to be),but it's a great framework, with a lot to offer (including the best community support of *any* open source web development framework out there). At any rate, take all the bashing with a grain of salt, if you want a real opinion on what rails has to offer - hack something together with it yourself. I'd offer the same advice to all the bashers out there.
        • by devjj (956776) on Monday March 17, 2008 @05:18PM (#22777500)

          There's a simpler reason for bashing Rails: it's a threat. It's just that simple. Any time something comes along that can feasibly put market pressure on existing technologies, there's going to be bashing.

          Rails pays my bills. I honestly don't give a damn what anyone else thinks if it's meeting my clients' needs. Simple as that.

          • Re: (Score:3, Interesting)

            by filterban (916724)
            Honestly, as a J2EE developer who is using Rails to develop an application for personal use, I think you're totally right. Rails isn't perfect but it has some serious advantages. The scary part for businesses is that they can't use it in conjunction with their existing J2EE developers and infrastructure (e.g. App server).

            This is where Groovy and Grails comes in. I just attended a conference with a bunch of Java developers and the Groovy/Grails sessions were all packed, and they were the talk of the sh
            • by Black Perl (12686)
              Honestly, as a J2EE developer who is using Rails to develop an application for personal use, I think you're totally right. Rails isn't perfect but it has some serious advantages. The scary part for businesses is that they can't use it in conjunction with their existing J2EE developers and infrastructure (e.g. App server).

              Um, JRuby on Rails can do that. I've packaged up Rails apps in a war file and deployed it to app servers.

              In fact, the IDE I'm using (NetBeans) uses JRuby by default and automatically create
              • by filterban (916724)
                Yeah, JRuby does that, but you still have to learn Ruby. That means your existing development staff needs significant training. So it's still a big change.

                On a side note - you're using NetBeans?! Everyone I know uses Eclipse and/or IntelliJ.
        • by SanityInAnarchy (655584) <> on Monday March 17, 2008 @05:19PM (#22777504) Journal
          Community all depends on whether you're doing things The Rails Way or not. (In fact, one of two books I've read to teach myself Rails was called "The Rails Way.")

          But just look at a couple [] examples [] of why people run away from the community. (For those who don't know, the second example is DHH, creator of Rails.)
          • Re: (Score:3, Interesting)

            by devjj (956776)

            I find this argument amusing every time I hear it. Those in the Rails community are often called arrogant for insisting on things being done "The Rails Way", when it's often your own arrogance that won't allow you to do something any other way. In either case, it's the people you have a problem with. There are far fewer legitimate complaints about the Rails Framework than there are about Rails people. You can dissociate yourself from the people and still have a capable framework.

            If you don't want to d

            • Re: (Score:3, Interesting)

              In either case, it's the people you have a problem with. There are far fewer legitimate complaints about the Rails Framework than there are about Rails people.

              I agree entirely, although occasionally some of the more arrogant things that I don't agree with make it into the Rails Framework.

              So far, enough people think like me that it hasn't been a problem -- there's always a plugin or set of scripts somewhere to help me out. A recent example: Schema Validations. While not all validations can be reflected in

              • by Sancho (17056)
                You've summed up my own issues with Rails.

                Ultimately, what it boils down to is that Rails is a framework. Frameworks are never as flexible as the languages in which they're written. Because most of the paradigms which Rails was built for are well-understood and already have open-source projects available for them, Rails isn't much use to me (I don't want to write yet another CMS, I want to extend an already-written one.)
        • by glwtta (532858)
          It's new and different from the J2EE frameworks the many web developers on Slashdot have been developing with for so many years.

          Alternative theory: it's a nice framework, but its adherents insist that it's a marvel of engineering the likes of which have never been seen before, nor will ever grace us again, and that it completely obsoletes all other methods of developing web applications. They base this on the fact that you can pick up a Rails book and bang out a trivial application really quickly.

          • Re: (Score:3, Informative)

            by realmolo (574068)
            That's basically what I meant.

            Rails is *nice*. I like it. I just don't get the obsession with it. And, let's be honest, it's not in widespread use. From a purely *financial* perspective, you're much better of learning the in-and-outs of something like or PHP. Or, hell, even Perl. Those are all more widely used, and better supported.
      • by Standard User 79 (1209050) on Monday March 17, 2008 @05:17PM (#22777492)
        Not a well crafted explanation but: 1. Can't use threads, framework is not thread safe. This opens up all sorts of problems. i.e. uploading,persistent connections,complex webservices, etc.. 2. Difficult to administrate. Compared to other frameworks, Rails requires a lot more work to set up/administer and seems to crash a lot. 3. Per #1 and #2: Doesn't scale well. It's still a nice solution for a lot of things. But I imagine most of the bashers are developers who got burned when they found out rails develops well but administrates poorly.
        • Threads workaround (Score:3, Informative)

          by metalhed77 (250273)
          It aint pretty, but you can work around the lack of multi-threading with file uploads just fine using merb as a companion to rails. You can share all ORM stuff with Merb and you'll be fine. Not as pretty, but doable. Also, I don't see why a multi-process model is harder to administrate than a multi-threaded one.

          Yes, it takes more effort to set up, but that also makes it really easy to scale since the component parts of a Rails deployment (Load Balancer / Web Server / App Server / DB Server) are each very sc
        • The threading thing has been covered in a lot of places. Do a google and read about it... it's really not that big of an issue. For the super heavy tasks, we use DRb. It works very well. The administrative part of things is easily covered with capistrano or with custom scripts. I use the same pattern when I deploy and update sites... I'd hate to think a simple update process is too much work for a developer, but I guess some people are just extremely lazy. That brings me to this idea that Rails is har
        • by johnnyb (4816)
          I haven't found thread safety to be too much of an issue. Sure, it would be nice for some things, but generally it is not an issue.

          As for administration, I know a lot of people like things like Mongrel and the sorts, but I've found that admin'ing busy websites is fairly simple using Apache + mod_fcgid (NOT mod_fastcgi). I think few people are aware of this option, but it works quite well.

          As for scalability, most of the issues I've had with scaling were solved by either (a) writing better queries, or (b) d
          • I haven't used mod_fcgid, but I am definitely going to look into it now. Thanks for the tip. Right now we are using mongrel clusters & mod_proxy_balancer, which does a pretty good job. Proper scripts make it easy to update & start/stop, and I haven't had manually to kill any dead mongrels in a long time (at least 6 months). Better queries and caching is totally the key. Zed had a really interesting writeup, or maybe he was talking about it on someone's podcast, but he talked about using Nginx a
      • by Doug Neal (195160)

        Everyone is always quick to bash RoR but I have honestly never heard a well crafted explanation as to why it's an inferior language / framework. I personally use Java, but that's only because I was raised on it.

        So I ask: Why the bashing?

        Generally because Rails seems to attract a lot of zealotry, and wild claims of it being the best at everything imaginable and how everything else sucks compared to it.

        It's a very nifty framework and it definitely has its place. But it's not the be-all-and-end-all of web development that some people claim it is. I see the bashing as mostly a backlash against the zealots.

      • by oliderid (710055)
        So I ask: Why the bashing?

        It looks like they bash it because it is a threat to their current state of knowledge, IMHO. When things become too simple, you loose your "guru" status. I've experienced that (at another level) when WYSIWYG web editors such as dreamweave allowed non-technical guy to code a "relatively" clean code . Suddently those folks (i was part of them) lost their HTML king status and they were forced to migrate to a higher level (perl and then java/c# web developer in my case). Sure things ar
    • Re: (Score:3, Informative)

      by kbob88 (951258)
      Easy, uncreative troll. Try a little harder next time, please.

      Rails has paid my bills since 9/2005. And I'm a lot happier than I was coding Java.

      It would pay the bills for two other people too, but we can't find anyone to take a full-time job in it. It seems that anyone who knows Rails right now in SF is contracting at $125/hr.

      Not to say Rails doesn't have its problems as a technology and a community...
    • Re: (Score:3, Informative)

      My resume [] says right at the top that I'm not currently looking for work. Still I get a steady flow of emails soliciting me for Rails jobs.

      Also, I was a full-time rails developer for nine months.
    • We've started using Rails for our internal applications at my job. Frontends to more complex systems and systems management (inventory/snmp) are some examples of what I've been involved in.

      I've found that although you probably wouldn't want to make slashdot in Rails, it's very, very handy for blogs, portfolios, resume sites, intranet applications and proof of concept applications.
    • Yeah, I can barely survive on the $150/hr, or more, that I make for my Ruby skills.
    • by carlivar (119811)
      Huh, funny, since I start at my new job using Rails in a couple weeks.
    • Re: (Score:3, Funny)

      by bigtrouble77 (715075)
      I know this was just a joke, but I need to respond. Rails saved my career. After being in a dead end it job for 3 years, I found myself suddenly unemployed. I then took it upon myself to learn RoR in 3 months because it was the only way I thought I could get a break as a developer- I'd be the only Ruby developer when it really hit big. After building 2 projects to show off (a blog and a business lead generation site) I sent out my resume. It took two months, but I ended up getting a contracting positio
    • by hal2814 (725639)
      To feed the jokester/troll, get real! If I'm going to spend time learning a language that has no shot at making me any money, it's going to be functional. F# and OCAML for me, thank you very much.

      On a more serious note, we outsourced our website to a company that built it on Rails. We were going to host it internally but at the time Rails had a few issues running on a Windows server and we didn't want to invest in the time and money to get a Linux server running in our environment so we let them host it.
    • The difference between a good-natured jab and a trollish slap? The word "EVER".
  • by moore.dustin (942289) on Monday March 17, 2008 @04:28PM (#22777034) Homepage
    The summary of the last chapter titled 'Large Projects' only adds to my worry about using RoR for a large project. Horror stories, these are the only stories I have heard from anyone trying anything close to what I would consider 'large' projects. Glancing over the Contents I was hoping that the last chapter would provide some insight into overcoming the pitfalls RoR has with larger project. It does not really sound like the author recognizes what many others have already found; RoR is not the right tool for many significant sized project, especially in the enterprise environment.

    Perhaps the fellow readers can give some more insight into this?
    • by h4ter (717700) [] runs on Rails, and that's a large, enterprisey project.

      All of 37signals' products are Rails sites, too, and they're handling data for plenty of enterprises.

      There are a lot of "horror stories" precisely because they're horror-inducing. No one retells a story about how someone's website got built with the same number of uninteresting issues as usual.

      When I was coming up, all I heard was that Perl was read-only, and that anyone with a large Perl codebase was in big trouble as soon as anyone

    • Rails is old news. Try something really new and mind blowing. []
    • by rfunk (765049)
      I don't think it's a question of large vs small projects; Rails actually makes the programmer's life better in large projects. But enterprise deployment can be a hassle with Rails. There are a lot of people working on solving the problem in various ways. I think the most interesting and promising of these right now is to run the Rails app on JRuby, as a Java servlet.
      • Re: (Score:3, Interesting)

        by glwtta (532858)
        Rails actually makes the programmer's life better in large projects.

        Is there any sort of evidence for this? All I'm hearing is that RoR is having a lot of trouble scaling with complexity.

        Which makes sense, since it's designed to make really trivial applications really easy to write - nothing wrong with that, really, it's a useful niche.

        Rails and its ilk really emphasize the start-up cost, those first couple of days that are essentially irrelevant in a large project.
    • > Horror stories, these are the only stories I have heard from anyone
      > trying anything close to what I would consider 'large' projects.

      I've found that Ruby has a way of making large projects into small ones. Going from 250 KLOC in Java to 10 KLOC in Ruby would not surprise me.

      > RoR is not the right tool for many significant sized project, especially in the enterprise environment.

      Most enterprise environments are a morass of battling departments, entrenched legacy technologies, and outdated, inefficient processes. While that significant-sized 30 person project is bogged down for two months negotiating more app server licenses, the 3 person Rails team can knock out a fully tested application that does the job.
      • by cyberon22 (456844)
        Defining large in terms of the size of the code base is not appropriate - that's more a question about the compactness and expressivity of the underlying language.

        I'd imagine "large" is being used here to mean an ability to tolerate enterprise load level. I'd be curious to hear stories about this myself. Our rails application is slower than something coded in PHP, largely (I think) because the framework encourages development without much concern for database speed. Writing your own SQL commands is one solu
        • by tcopeland (32225)
          > Defining large in terms of the size of the code base is not appropriate

          Hm, at least, KLOC is a contributing factor. Maybe cyclomatic complexity would be a better measurement?

          > I'd imagine "large" is being used here to mean an
          > ability to tolerate enterprise load level.

          Yup, but an enterprise load level usually means a server farm with a web/app/db breakdown and some caching servers. At that level, the Ruby interpreter and the framework method calls usually aren't the bottleneck - there's s DB to
    • by kbob88 (951258)
      What's a large project? We have a Rails app that has about 60K LOC, with 64 controllers, 109 models, and 424 views (screen pages). That's pretty big in my book. To be fair, about 20K LOC is used to data import/export and reporting, and so aren't really in the regular part of the webapp. It's enterprisey -- it runs most of the company.

      However, it's not serving zillions of requests per second (it's an internal application). Our public-facing Rails apps are much smaller, and don't face huge traffic either. The
      • by tcopeland (32225)
        > Production architecture, webserver integration, and
        > deployment were all huge pains two years ago.

        Yup. Judicious Capistrano + mongrel_cluster + monit usage make a difference these days, but it would still be nice to have fewer moving parts. Maybe Rubinious will get us there.

        Incidentally, "cap deploy:check" totally rocks.

    • by mosch (204)
      Personally, I know of more than a dozen "large projects" that run primarily or completely on RoR without any significant issues. (Or anything that advertises their Rails-ness to the public).

      As far as I can tell, the only common theme among them is that they're run by professional software engineers, not kids who read one Rails book. I mean, the fact of the matter is that if you want to run a high quality, large database-backed web application, you need some people who really understand databases, and some
  • by Anonymous Coward on Monday March 17, 2008 @04:28PM (#22777044)
    I picked up this book a couple of months ago when it was first released. Although a J2EE and .NET developer by trade, I do try to keep abreast of new technologies. I must say, I was quite disappointed by this book.

    The book isn't poorly written, and the information it conveys is useful to some people, I'm sure. But I don't consider the topics it covers to be "advanced" by any means.

    Using triggers and rules, for instance, are not really advanced concepts. Nor are plugin-based architectures. REST techniques are pretty basic, as well.

    I was hoping for this book to really discuss pushing RoR to the max, allowing us to do what we can't currently do easily with J2EE or .NET. But that didn't happen, thus leaving me disappointed.

    • Re: (Score:3, Insightful)

      I was hoping for this book to really discuss pushing RoR to the max, allowing us to do what we can't currently do easily with J2EE or .NET.

      From what I can say, there's still some things that RoR routinely does more easily than J2EE or .NET -- it's just that good ideas tend to propagate, so I suspect it's not as dramatic a difference anymore.

  • Just a simple request.
    • Re: (Score:3, Funny)

      by e4g4 (533831)
      You're right. Fortran should be good enough for anyone.
    • What do you think is better... PHP and MySQL?

    • Re: (Score:3, Insightful)

      This is one book review. In what way is it hype?

      I'm seeing more Anti-Ruby/Rails FUD here than pro-Ruby/Rails hype.

      Would you say the same thing if it was a .NET book being reviewed?
    • Re: (Score:3, Insightful)

      by TimHunter (174406)
      Here's a thought: Don't like what other people are submitting? Take the time to review a book about your favorite tech and submit it.
  • What to do? (Score:5, Funny)

    by AKAImBatman (238306) <> on Monday March 17, 2008 @04:36PM (#22777110) Homepage Journal

    What's a budding Rails-head to do once they've gotten the basics down?

    Move to Java?

    I kid, I kid! Ow, ow, ow!
    • Re: (Score:3, Funny)

      by PPH (736903)
      Switch to VB. There's a new implementation "Visual Basic on the Skids" coming out soon.
  • Required reading (Score:3, Interesting)

    by tcopeland (32225) <tom@[ ] ['tho' in gap]> on Monday March 17, 2008 @05:01PM (#22777340) Homepage
    > I don't know if I'd go so far
    > as to label it required reading

    I've been doing Rails for about two years and still found this book to be very helpful. It should be called "Rails For Real Projects" or something, because he covers stuff you _will_ run into. The nice thing about this book is that he doesn't waste time explaining what 'puts' does and such; he gets right down to business. The section on modifications that Rails makes to the Ruby standard library is worth the price alone.
  • It looks like the poster just linked to *recommend this book to a friend* reference and will be getting a cut depending on how many people will but it.

    Its spamming and should be banned from slashdot.
    • Re: (Score:3, Insightful)

      by glwtta (532858)
      Why is that spamming, really? I mean, he did make a detailed recommendation, if people choose to buy it based on that recommendation, isn't that the point of the system?

      The price is the same for those buying it. I don't see what the problem is.
  • by daviddennis (10926) <> on Monday March 17, 2008 @10:18PM (#22779664) Homepage
    I think I understand what it is - a way to standardize information retrieval and posting via URLs.

    But what's the excitement all about? I would think that for most site owners, this would be a disaster, not a boon.

    It sounds like a graven invitation for others to do stuff with your site ... which means they take your site's functionality, put their ads around it and suck out all the revenue.

    Furthermore, it seems like something that makes trying to break your site much easier since crack efforts can be done using standard methods for which the weaknesses are well known. So some smart guy can find a weakness in the REST code and all of a sudden everyone who's followed the rules can be automatically exploited.

    Google encourages you to use their maps, because it builds loyalty to them, and you are probably using their ad network anyway so they don't lose much revenue. But for most sites, mashups are going to virtually eliminate revenue, cost bandwidth and overall make your life miserable. They are the modern equivalent of linking to images on someone else's site ... and we are supposed to encourage this? Are we nuts?

    So tell me, what does REST do for me, as a site owner and developer, as opposed to what it does for others, such as people creating mashups and the like?

    Are there any ways in which mashups can be made profitable or worth encouraging, for people who don't own their own ad networks?


  • Ruby on Fails [epic]

Nothing is rich but the inexhaustible wealth of nature. She shows us only surfaces, but she is a million fathoms deep. -- Ralph Waldo Emerson