Advanced Rails

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 Proc.new? The answer is that, if you *return* a value from the block passed to Proc.new, 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 amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

I'd recommend the Rails Cookbox instead

[Anonymous Coward]

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:I'd recommend the Rails Cookbox instead

[Anonymous Coward]

Uff, I can't believe I made the same spelling error twice. That should read "Rails Cookbook". Sorry.

Good old RubyOnRails

[realmolo]

When you feel like learning a language/framework that won't EVER pay the bills.

Re:Good old RubyOnRails

[Peter Cooper]

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:Good old RubyOnRails

[misleb]

Pays my bills.

Re:Good old RubyOnRails

[Lysol]

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.

Re:Good old RubyOnRails

[e4g4]

As a full time (read: salaried) Rails developer, I call bullshit.

Re:Good old RubyOnRails

[DJ Jones]

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?

Re:Good old RubyOnRails

[e4g4]

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.

Re:Good old RubyOnRails

[Anonymous Coward]

the best community support of *any* open source web development framework out there

I have to say that the community is by far the biggest thing that makes me run away screaming from Rails. The clue:ego ratio is dire compared with Django or TurboGears. It's like the Rails hype siphoned off all the immature assholes from surrounding platforms. Every time I read anything about Rails, I subconsciously hear it in the tone of voice teenager gamers use when flaming each other about which console is best. Other communities, on the other hand, just shut up and get it done, for the most part.

Re:Good old RubyOnRails

[Standard User 79]

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.

Re:Good old RubyOnRails

[devjj]

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:Good old RubyOnRails

[SanityInAnarchy]

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:Good old RubyOnRails

[glwtta]

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.

In short: its fan-boys, like all fan-boys, are annoying.

Re:Good old RubyOnRails

[devjj]

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 do things "The Rails Way" you're free to use whatever works for you. If you don't want to use ERB write your own template system. Don't like AR? Don't use it. Sure, it's harder to go without, but if you've got a good reason for doing things a certain way you're free to do things as you wish. It's not like DHH is going to come pounding on your door because you didn't do things his way. He's an opinionated guy -- most of us (Rails devs or not) are.

The only reason to bitch about "The Rails Way" is if you're too lazy to figure out how to do it your way.

Re:Good old RubyOnRails

[realmolo]

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 ASP.net or PHP. Or, hell, even Perl. Those are all more widely used, and better supported.

Re:Good old RubyOnRails

[Sancho]

Never underestimate the power of buzzwords and glitzy technology? Managers love shiny things!

Re:Good old RubyOnRails

[kbob88]

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:Good old RubyOnRails

[Anonymous Coward]

Yawn. Humorless idiot.

There was nothing whatsoever in the original post to suggest that it was supposed to be humorous. Being funny is more than just saying something false and flaming anyone who calls you out on it.

Re:Good old RubyOnRails

[CoughDropAddict]

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.

Re:Good old RubyOnRails

[SanityInAnarchy]

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 the database schema, some can, and arguably, it is a Good Thing for stuff to be validated by Rails before it hits the database. You should never have an error coming back from the database about exceeding a VARCHAR(255), but do you really want "validates_length_of :foo, 255" everywhere?

It gets even worse when your database supports real foreign keys. Sure, they'll break down with polymorphism, but won't you still have a large number of relationships for which foreign keys would make sense?

Fortunately, there's a plugin for that, and another if you use real foreign keys.

Sure, it's harder to go without, but if you've got a good reason for doing things a certain way you're free to do things as you wish.

But this, combined with "Convention over Configuration", means that it is very often not possible to do what you want without either performing deep surgery on Rails (not always possible in a plugin, so expect to maintain it yourself if your patch is rejected), or, as in your example, scrapping a chunk of the framework altogether.

And if you have to scrap a large chunk of the framework, or the entire framework, is there really any point in claiming to be a Rails developer anymore? Maybe at that point, you'd be better off with a framework like Merb, which, I'm told, is much more hackable than Rails. In fact, the very concept of Rails itself (stay on the rails) goes against software reusability, to some extent.

All that said, I don't have anything particularly painful right now -- I'm developing a Rails app, full-time, and I'd be lying if I said I didn't like it. But the point is, it's not always laziness -- sometimes it is the framework making a particular way of doing something as hard as possible, on purpose. (Example: Google "syntactic vinegar.") Sometimes, it's not on purpose, but it is there -- these don't bother me so much, because I can always try sending a patch. (Example: Ever try extending an AssociationProxy after it's been created? Don't. But believe it or not, there is a use for that.)

Re:Good old RubyOnRails

[fartrader]

I think the best thing that it has offered is insight. Rails is innovative and it has had a significant impact on other languages and their approach to web development: from Grails using Groovy, to Seam which uses the J2EE 5 stack - all to some degree have been influenced by the simplicity that rails offers - all with the benefit of not having to learn another language.

Re:Good old RubyOnRails

[devjj]

You honestly think that any app you write is going to be better than its analog built in Rails? That you are a better developer in your chosen language/framework than every other Rails developer on the planet?

And you call Rails guys arrogant?

Re:Good old RubyOnRails

[Sancho]

Not the original poster.

I think that just about any application can be better written in PHP than in Rails (and I really dislike PHP, too.) But it probably can't be written faster. As for the coward's skills, I really can't say.

Re:Good old RubyOnRails

[Sancho]

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.)

Re:Good old RubyOnRails

[ehrichweiss]

Yeah, I can barely survive on the $150/hr, or more, that I make for my Ruby skills.

Re:Good old RubyOnRails

[carlivar]

Huh, funny, since I start at my new job using Rails in a couple weeks.

Re:Good old RubyOnRails

[devjj]

And upon what do you base this claim? The fact you're directly comparing Rails (a framework) to PHP (a language) is telling. It'd make a lot more sense to say "I think any app written in Rails could be written better in CakePHP" although that claim is obviously rather dubious, as well. To be truly appropriate, you ought to talk Ruby vs PHP. And if you get to that point you're going to have to justify what "better" actually means. What it means to you isn't what it's going to mean to anybody else and vice versa.

In the end, this debate ends up being Mac vs PC vs Linux vs Whatever. Everyone's got their opinions. What works for you is the right solution for you.

Re:Good old RubyOnRails

[devjj]

As a developer, learning another language is a good exercise, and most competent developers can become competent in new languages fairly quickly.

Re:Good old RubyOnRails

[bigtrouble77]

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 position at a very reputable comapany. After 8 months of work I was offered a full time position and a very nice salary. I'm eternally grateful for the opportunity that Rails has given me and also the incredible support I got from railsforum.com, especially Ryan Bates.

Re:Good old RubyOnRails

[Doug Neal]

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.

Re:Good old RubyOnRails

[Dhalka226]

I said "cleaner" by which I'd mean no indirection thru active record and no relying on a framework specific dispatch handler.

Yeah. Those few lines of code that load the actual framework really muddy the waters. The fact that you're talking about "framework specific handlers" as an attempt to criticize a framework is a good indication to me that you've never tried Rails at all and just assume you're right about everything. If you never use any framework in any language, congratulations. On the other hand there are those of us who think a couple hundred K of memory used by persistent processes is worth significantly (by your own admission, perhaps 50%) reduced development time and thus cost.

As far as "indirection" via AR, if you don't want it you're free to not use it. It's one of the truly magnificent things about Rails. On the other hand if there's a particularly cumbersome query you're quite free to write it in raw SQL. There's a performance boost to be had there, yes. To the vast majority of web applications it's negligible, and that means that its benefits again outweigh its drawbacks. Rails isn't the perfect solution for EVERY project, but a handful of exceptions doesn't make it a bad rule.

I said "scale better" which is undeniable for any interpretation of the word "better".

Yet another irrefutable clue you made up your mind without ever bothering to try anything yourself. Or that you're a pompous ass, either way. Comparisons of scalability are ABSOLUTELY MEANINGLESS if you only provide one of the two items to be compared. Thus your statement is absolutely meaningless. Given the rest of your post, and your previous ones, that seems to be par for the course.

Rails handles scaling well. It probably handles less before it NEEDS to scale in MOST cases, particularly when it is (unfairly) compared to languages rather than other frameworks. If you really are on the border where Rails means you need an extra machine and (say) PHP doesn't, then maybe this is one of those areas where Rails isn't your solution. If you're already into the realm of needing to add hardware to handle load, Rails provides a lot of great solutions for doing that. And once again, it's going to be simple to implement.

I'm not simply talking out of my ass. I've worked on some projects for major clients including ESPN that were done in Rails and are humming along beautifully. Worse yet, some of these projects were extremely time-sensitive, by which I mean that most of the day they do very little work but when the work comes it comes in a huge swarm in a short time window. IE, the worst-case scenario as far as loading servers. It's still working fine, and we got to charge ESPN half as much as we would have for development of a PHP solution. They're already sending us more business, so I guess evil, evil Rails didn't destroy their company too badly. There are obviously many similar stories of huge sites working just fine on Rails, such as yellowpages.com.

To sum it up: Yes, a framework has some additional overhead compared to a simple language such as PHP. An interpreted language won't run as fast as a compiled language like Java or .NET (to bytecode). These are facts. What's in dispute is whether this makes a significant difference, and my experience with popular projects for major clients is that a well-coded Rails solution holds up fine.

You're right that development cost is sunk and electricity (and similar) costs are ongoing, but before that matters you have to be talking about MAJOR projects that are very probably billed minimum in the tens of thousands of dollars range and, realistically, probably over the hundred thousand dollar threshhold. At this point, your 100% more development time is a significant cost that is likely to take many years to balance. Even a $5,000 a year difference in marginal cost if you're talking a $25,000 or $50,000 difference in developemnt cost is

Re:Good old RubyOnRails

[cbart387]

Example: Google "syntactic vinegar." Could you explain this? I understand what you mean by 'syntactic vinegar' but I'm curious how Google does this?

Re:Good old RubyOnRails

[symbolic]

As far as "indirection" via AR, if you don't want it you're free to not use it. It's one of the truly magnificent things about Rails.

This is one thing that really impressed me. They made it just as functional for people who aren't publishing/managing their own database schema, as they did for those who are. The UI components are completely decoupled from the from whatever mechanism is used to access a data store, so there's a LOT of flexibility.

Re:Good old RubyOnRails

[Anonymous Coward]

lol u mean the mac and yac, beer and studio apt? Rails is for script kiddies. Certainly doesn't qualify as a full programming language, and I'd be hesitant to call it a scripting language. I certainly wouldn't pay any of my programmer 100/hr, and we pay much more than that for real java enterprise programmer types due to the real experience they have had with real enterprise projects, not some web scriptie hack site with spaghetti code that can't be maintained by someone else (yes harkens to the days of yet another dynamic language, perl-cgi, that in the late 90's was all the rage, what a mess that code was). These scripting dynamic languages are good for quick text parsing, quick demos or munging text around for transient projects, but it doesn't belong in an enterprise application.

Re:Good old RubyOnRails

[devjj]

You make some good points about Rails's flaws, although I'd argue that many of them are related to ORM in general and have less to do with ActiveRecord's implementation than the concept as a whole. Your mention of "interpreted" gives me pause, as it almost sounds like you're arguing that interpreted languages are inherently flawed. I'm not say that's what you're saying, but I think you can see how that could be, well, interpreted.

Of the things you pointed out, I'll candidly say that Rails deployment is perhaps the area where it is most apparent that in the grand scheme of things Rails is still something of a baby. It has (arguably) matured fairly rapidly, but there are certainly areas where there is still room for improvement. Given the sheer bullishness of the core team I'd like to think we're going to continue to make significant progress in this regard. One of the biggest problems Rails faces today is deployment in shared hosting environments, but to say it can't scale is simply false.

As I've noted in prior comments, your problem with Rails has far more to do with some of the people who use it and less with the code itself.

Re:Good old RubyOnRails

[mini me]

It gets even worse when your database supports real foreign keys.

The root of the problem here is that using an RDBMS for most web applications is a hack, no matter what language or framework you are using. Unfortunately at the time Rails was created there were no suitable, generally available, alternatives to the SQL server. As such, Rails had to do what it could to make SQL act like the right tool for the job. Not pretty, like hitting the nail with the handle of a screwdriver, but it got the job done.

But then came along the DBAs who failed to see why SQL is the wrong tool for the job and expected ActiveRecord to support every esoteric feature the RDBMS has to offer. When they found out it didn't the comments about how terrible ActiveRecord and Rails are started flooding in. They couldn't see the forest for the trees.

The plugins you mentioned are a great testament to Rails on how easy is to extend to do exactly what you want. But I think it's unfortunate how many people missed the point on why features such as foreign keys are not described in the database as far as ActiveRecord is concerned. On the bright side, I foresee Rails moving completely away from ActiveRecord as the default data access layer in the not so distant future.

Re:Good old RubyOnRails

[chromatic]

Unfortunately at the time Rails was created there were no suitable, generally available, alternatives to the SQL server.

Gemstone, for one example, was 14 years old at that point.

Re:Good old RubyOnRails

[bryanthompson]

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 waste of energy.

Re:Good old RubyOnRails

[bryanthompson]

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 hard to scale. I can't imagine being as lazy as a lot of the "developers" i hear that claim without any real knowledge that Rails is hard to scale.

Here's exactly where the naysayers come from. They watch the screencasts that show a functioning blog being created in 5 minutes and give it a half-assed try. They create something functional, then run into problems deploying. Then they get a little bit of traffic and their crap crashes because they thought they could get away with, say, using scaffolding in a production environment. There are a lot of flashy things in Rails that make it easy to use, but those things aren't really efficient. So, once they get past the shiny parts, they don't get into the actual optimization and they give up. To be a good Rails developer, one has to balance the two and not expect everything to be automatic.

/Just the opinion of a full-time rails developer.

Re:Good old RubyOnRails

[Standard User 79]

I'd say the chances are pretty good for both. Not that java will be pleasant but that the virtual machine will become more workable to dynamic languages. Sun now has jruby and jpython developers on their payroll..

Re:Good old RubyOnRails

[Standard User 79]

What makes the rails world different from other application frameworks is the developers as a whole seem to prefer to sweep their issues under the rug rather than deal with them in the open. Engineers resent that. Saying threading is not a big deal is silly. DRb is not a solution to threading. I remember someone sending me a link from zed shaw saying that before fastthread 37signals had to restart their servers 400 times a day. lol, i am really, lets get real here.

Re:Good old RubyOnRails

[oliderid]

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 are still better when you code by hand...But if a guy can make a layout in one hour and you still need two hours to carefully adjust your code and they both pass the Internet Explorer and Firefox (netscape in those days) tests...And if you still ask higher fees: you are screwed.

RoR not as fast as (whatever)? Who cares, I've got plenty of web services with less than 100 visitors per day.

I've played with ruby in my spare-time. Technically it looks clean, well balanced and easy to maintain. Pragmatically there are plenty of "new" languages (Python and others) with good potential. Financially I will consider it as an opportunity once I will see my competitors using it or it will be part of a project's requirements. I don't see Ruby becoming really mainstream (like PHP) in the following years.

Re:Good old RubyOnRails

[fartrader]

All very true - but who wants to support 'em all? Especially when your Ruby guys move on, or the next big thing comes along.

Re:Good old RubyOnRails

[FooBarWidget]

Zed Shaw did say that, but we don't know whether that claim was taken out of context. Maybe 37signals had a hardware problem. Or maybe an OS update b0rked their kernel. Or whatever. I've been running a business Rails app for 1.5 years now, and it's been stable ever since. I've never had to restart it. I've studied the internals of Rails and I don't see any fundamental flaws which prevents it from being stable.

Your claims are similar to that of a lot of other naysayers. There's obviously a lot of misinformation around. But come on, 400 restarts day: that's ridiculously unacceptable for even the biggest Rails zealot, isn't it? Think about it for a moment: if it was true then 37signals would be out of business now. The fact that they aren't, proves that something about that claim isn't entirely right. I'm not asking you to believe the hype, but the least you should do is to be critical to all Rails information, whether positive or negative. It seems that, right now, you're accepting all negative information without thinking about whether they're really true or whether they're relevant to you.

Is (the absense of) fastthread related to the 400 restarts a day? Maybe, maybe not. I doubt it, because Rails has never used threads.

That said: nothing prevents one from running threads in a Rails application server. You just have to be careful about what you do in your threads and make sure you don't run into racing conditions. And this is - guess what - no different than any language/framework! The developers must know what they're doing.

You do have one legitimate complaint: administration. There are too many steps involved right now. Although I don't think deployment and administration is too hard (I learned it in a week), it seems that people have the perception that it is hard and don't want to/can't learn how to do it properly. An upcoming Rails deployment/administration system will solve just that. It'll turn Rails deployment and administration into a nearly zero-maintenance effort.

Re:Good old RubyOnRails

[BVis]

and we got to charge ESPN half as much as we would have for development of a PHP solution.

You say that like it's a GOOD thing. Did the hours you didn't charge to ESPN get filled with other work? Did ESPN guarantee future work?

If the answer to either question is 'no', then it's a negative.

IMHO rapid development isn't always a good thing. Once your clients start to expect this level of rapidity, if you run into a problem on a project (such as feature creep or changing specs) they're less tolerant of delays and become more difficult to manage. Unless you have a client that understands these kinds of issues (and these are hunted to extinction) it causes problems. You end up rushing through the additional requirements and end up with buggy code.

Pad your hours, people. If everyone does it then we all make more money. We can follow the lead of the oil industry; it works for those greedy bastards, why can't it work for us?

Re:Good old RubyOnRails

[hal2814]

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. Is running in a Windows environment still an issue for RoR? I like the language and I like the framework but until we can getting it running reliably (in a light-to-medium production capacity) in our MS-centric environment, it's not even an option. Until then, we build the lightweight stuff in .NET and the heavyweight stuff in Java.

Re:Good old RubyOnRails

[SanityInAnarchy]

I'm not sure if you were being sarcastic, but I was using Google as a verb.

Re:Good old RubyOnRails

[filterban]

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 show. Everyone was really excited about it.

It's amazing how two small things - making it syntactically similar to Java and making it use existing J2EE infrastructure - all of the sudden makes Java developers think it's the greatest thing in the world.

Re:Good old RubyOnRails

[SanityInAnarchy]

The root of the problem here is that using an RDBMS for most web applications is a hack, no matter what language or framework you are using.

What alternative would you suggest?

But then came along the DBAs who failed to see why SQL is the wrong tool for the job and expected ActiveRecord to support every esoteric feature the RDBMS has to offer.

I like to think that the plugins I mention are a good idea regardless. For example, "validates_uniqueness_of" is never going to be thread-safe without taking a pretty massive performance hit (locking an entire table on every save). It's the perfect candidate for something which should be enforced at the database level (or storage level), so that multiple Rails processes won't trip over each other. But as soon as I'm creating a unique index, I certainly like not-repeating-myself by having the "validates_uniqueness_of" generated from that index.

But I think it's unfortunate how many people missed the point on why features such as foreign keys are not described in the database as far as ActiveRecord is concerned.

The only reason I see is that ActiveRecord supports multi-table polymorphism, and I honestly don't know how I would go about creating a foreign key relationship for that. Even single table inheritance would seem to be a problem.

I do know what you mean by "hitting the nail with the handle of a screwdriver" -- it's painful to see all those VARCHARS used to specify the class of a particular row or association. But I simply don't know of a better alternative, other than a SQL database extended to support AR-specific features. That is, I see AR wanting more features, not less, than a standard SQL database. (Why shouldn't foreign keys be supported, other than that they aren't flexible enough?)

Oh, and there is at least one thing that still pisses me off about ActiveRecord, mostly because it has been known about (and not resolved) for so long -- forget stored procedures, what about simple prepared statements? Especially when ActiveRecord does support syntax that looks like it was meant for a prepared statement, but is really doing its own escaping under the hood? I understand AR was meant for things like MySQL and SQLite, but it's still taking a performance hit for no good reason on things like PostgreSQL and Oracle.

On the bright side, I foresee Rails moving completely away from ActiveRecord as the default data access layer in the not so distant future.

I'm not too hopeful. The current default is SQLite.

Re:Good old RubyOnRails

[cbart387]

No :(. I subconsciously added an 's to make it Google's Syntactic vinegar. I thought maybe google's map API (or something else) punished you for not doing it their way.

Re:Good old RubyOnRails

[Standard User 79]

dhh confirmed the 400 restarts as they were running out of memory. You can find the nugget somewhere in zed's rant (http://www.zedshaw.com/rants/rails_is_a_ghetto.html). Since you say you've studied the rails internals, reading zed's rant might help you see some of the issues. It's not something you should take personally - rails does a lot of innovative things. But it is in need of more critical engineers.

btw. Rails is not thread safe. Nor does ruby have native threads. That is *very* different than other languages/frameworks.

Re:Good old RubyOnRails

[misleb]

On the flipside, I do often get a laugh when I read some of the overcomplicated "Enterprisey" code the is all too often featured on sites like http://thedailywtf.com/. It is amazing what some "enterprise" programmers will write to justify their overly inflated hourly rates (and egos). Not that I haven't see my share of Ruby WTFs. But it gets taken to a whole new level once you get "enterprise" programmers involved.

Working in the "enterprise" sucks. Partially because large corporations are soulless hells, but mostly because of arrogant pricks like you. I'm sure you'd have to pay someone more than $100 an hour just to put up with your shit.

Re:Good old RubyOnRails

[FooBarWidget]

"dhh confirmed the 400 restarts as they were running out of memory."

Yes I read that. Someone commented that the quote was taken out of context, and that there was some system problem involved.

We can argue about what *really* happened all day long, but let's take a look at the facts: Rubyonrails.org is online. The 37signals website is online. Basecamp is online. All *my* Rails apps are online. None of them are showing symptoms of 400 restarts per day, or even multiple restarts per day. 37signals is still in business. Empirical evidence clearly shows that, whatever problem it was, it's either been solved, or it isn't as bad as Zed claims it to be. If all Rails app need multiple restarts per day, why do you think so many people are still eager to learn Rails?

"btw. Rails is not thread safe."

Correct. Though so far I haven't felt the need for it to be.

"Nor does ruby have native threads."

Correct. It implements green threads aka userspace threads.

"That is *very* different than other languages/frameworks."

Not so. PHP has no threads *at all*, but I don't see anybody complaining that PHP doesn't scale because it has no threads. I have no idea why people don't complain about that, and asking them why yields no useful answers, but my guess is that because mod_php hides concurrent request handling from the administrators, they've never felt the need to spread FUD.

Perl has native threads, but it's quite laughable. Thread creation takes 15 seconds (!) on a moderately large Perl app, and it crashes straight after. Python has native threads, but it uses a Giant Interpreter Lock, so only 1 Python thread can be run concurrently. Ruby 1.9 also supports native threads, and like Python it has a Giant Interpreter Lock. Are Perl and Python useless because they don't support truly concurrent native threads? Many people would say no, and evidence can be found in the fact that those two languages are widely used.

So let's see: Rails naysayers claim that native threading support in Ruby is what prevents Rails from scaling. Nobody complains that Django doesn't scale, yet Python has a Global Interpreter Lock. Coincidence? I don't think so. To me, this proves that a lot of people are blindly buying negative information, and once they have, they refuse to change their mind even when presented with new information.

Java has great threading support, I'll give you that. If you really need native threads, you can use JRuby. It's built on Java and provides the same great support for threads. JRuby can even run Ruby on Rails.

Re:Good old RubyOnRails

[Standard User 79]

heh my friend reading this thread pointed me a link at 37signals saying they 98% reliability is okay with them. http://www.37signals.com/svn/archives2/dont_scale_99999_uptime_is_for_walmart.php. lol. I think it's fair to say zed is correct.

Now look, I didn't come to bash rails and I hope your applications run great. But you rails guys like to pretend your shit doesn't stink when any half ass engineer can see some seriously problems. I swear one mention of threads to you rails guys are like bees thinking their hive is under attack. In any case, real world beckons. best of luck.

Re:Good old RubyOnRails

[johnnyb]

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) doing better caching. ActiveRecord can lull people to sleep as far as database access goes, and it is not uncommon for people to forget the underlying database costs of what they are doing. However, ActiveRecord has a lot of nice things (like :include) which can make advanced queries fairly painless, and speed up your app a lot. In addition, having a database that works well with advanced SQL features like subselects (for instance, Postgres) can make many of Rails's supposed scalability issues go away.

Re:Good old RubyOnRails

[FooBarWidget]

Relax man, you sound like we're some kind of zombies that you're obligated to kill.

Did you miss my sentence in which I said JRuby has great threading support? You had a legit complaint about threads, and it's been solved in one of the Ruby implementations. What is the problem? You suddenly started calling us "shit" and "stink"?

Re:Good old RubyOnRails

[magus_melchior]

The difference between a good-natured jab and a trollish slap? The word "EVER".

Re:Good old RubyOnRails

[Peter Cooper]

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 :)

Re:Good old RubyOnRails

[Raenex]

Pad your hours, people. If everyone does it then we all make more money. Remind me not to hire you.

Re:Good old RubyOnRails

[BVis]

As a client or as an employer?

Re:Good old RubyOnRails

[mini me]

What alternative would you suggest?

ThruDB seems to be the favourite in the Rails world at the moment. But any high performance hash store will do. There are a lot of very interesting projects happening in this space right now.

But I simply don't know of a better alternative

As mentioned above, for most web applications you need a database that is built to stores hashes, not structured table data and relationships. ActiveRecord turns SQL into a rudimentary hash database. It's a hack, but it was the best option available at the time. A great example of embracing constraints, really.

Putting any more information in the SQL database than absolutely necessary is putting it in the wrong place. That logic belongs in the model, as ActiveRecord has done. As we start to move away from SQL in the future you'll be glad it is not in your database.

I'm not too hopeful. The current default is SQLite.

I think SQLite is the ideal default. It works out of the box and is good enough for the development of a lot of applications. Much better than the old MySQL default. But I was referring to ActiveDocument over ActiveRecord.

Re:Good old RubyOnRails

[Anonymous Coward]

When that last time we've seen enterprise apps written in a dynamic language? New Microsoft Excel written in Ruby on Rails! It occasionaly has some sloppy data type conversions (this helps you so you can write less code), but don't worry about that, it's being more tolerant!

Re:Good old RubyOnRails

[misleb]

I hear YouTube, Google, and EVE Online make heavy use of Python, and it is a dynamic language.

Re:Good old RubyOnRails

[SanityInAnarchy]

Putting any more information in the SQL database than absolutely necessary is putting it in the wrong place. That logic belongs in the model, as ActiveRecord has done.

Except the database was built for concurrency, and ActiveRecord wasn't. Example: validates_uniqueness_of is a nice thing to have, but it is NOT a substitute for a unique index in the database.

Putting that kind of information in the database helps, because it means I can be scalable without trying; the database has (mostly) solved the concurrency issues for me, and multiple Rails processes don't have to know about each other, or even be on the same machine. There's no reason the model couldn't do all that, but ActiveRecord doesn't, and it means you do have to reinvent the wheel on that part.

From a quick glance, I can't figure out exactly what thrudb is designed to do, or what ActiveDocument will provide in this respect.

Re:Good old RubyOnRails

[bryanthompson]

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 and some crazy caching schemes to make a better type of dynamic partial caching thing. It sounded interesting, but I haven't been able to find anything else on it. I'm currently doing caching with partials with a cron script to periodically remove the old caches, plus scripts to automatically remove the cache when it detects something change in that area. Also, we use javascripts to pull some small non-critical areas that need to update independently.

Re:Good old RubyOnRails

[darthflo]

Hardware v. Development costs differ greatly in different parts of the world.

As a nice little example, consider the following:
A mid-grade colo web server* costs about the same amount of money annualy as an average developer** does in two business days.

*: A dual 3-GHz, 6-8 Gig of RAM, 2x750 GB Hard drive box including a terabyte of traffic. Comes with a clean linux install and full ssh access, software mgmt is left to you. We're talking about commodity hardware and a ~99.5% SLA here, though three to four nines are common. Add a dead-app-server-detecting load balancer in front of a few of these and your Rails app scales effortlessy to your database server's capabilities at negligible cost.
**: The last figure I could recall off the top of my head was the hourly cost per developer in a government office I used to work for. This includes office rent, heating, and office IT infrastructure as well as the dev's actual salary. This figure is probably some 5-15% higher than the national average. Change the example to two years of server per work week to be on the safe side.

Re:Good old RubyOnRails

[Black Perl]

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 creates a war for you. Couldn't be easier.

Re:Good old RubyOnRails

[filterban]

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.

Chapter 10 - Large Projects

[moore.dustin]

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?

Re:Chapter 10 - Large Projects

[Anonymous Coward]

Perhaps the fellow readers can give some more insight into this?

Well, there has been this pesky rumour that Ruby on Rails won't scale. Then there is the fact that there are no enterprises stepping forward and loudly proclaiming that they're using it (or they're simply not able to make more noise than the already vocal community itself).

And let's not even get started on the great clash of ego and career suicide, but that has little to do with the language and framework itself.

Re:Chapter 10 - Large Projects

[h4ter]

yellowpages.com 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 who wrote any part of that code left the company, and that no one serious about long-term stability would ever even think about using Perl. And blah blah blah.

And anyway, if Rails was, at any given time, bad for large-scale projects, there would be plenty of people working to fix that.

Disclaimer: I work on enterprisey Rails projects, some of which are large.

Re:Chapter 10 - Large Projects

[mdipierro]

Rails is old news. Try something really new and mind blowing.

Re:Chapter 10 - Large Projects

[rfunk]

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:Chapter 10 - Large Projects

[howdoesth]

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 who wrote any part of that code left the company, and that no one serious about long-term stability would ever even think about using Perl. And blah blah blah.

Were you trying to imply that these facts had changed, or just that people had stopped talking about them?

Re:Chapter 10 - Large Projects

[glwtta]

I believe most large project are mostly written in PHP.

Heh, nice one.

Re:Chapter 10 - Large Projects

[Frosty Piss]

Just because most people writing PHP apps are sloppy armature coders does not mean that powerful well designed apps can not be written in PHP.

Re:Chapter 10 - Large Projects

[glwtta]

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.

Re:Chapter 10 - Large Projects

[misleb]

If you're used to dumbed down languages like PHP, Ruby might seem like black magic, but if you take the time to learn Ruby, you'll probably never watch to touch a line of nasty PHP again.

Large scale projects are usually written in Java or .NET. PHP is merely the "lowest common denominator" language of the web.

Re:Chapter 10 - Large Projects

[h4ter]

Were you trying to imply that these facts had changed, or just that people had stopped talking about them?

Good question. What's changed, I guess, is that I stopped listening to those people. Yes, there's bad Perl out there that's totally opaque. But my experience has been that, for the most part, Perl code is no better and no worse than anything else you're likely to come across.

It all sounded reasonable, and you could find examples that supported the assertions, but the people saying all that were basically trolls, even if they were CTOs.

Re:Chapter 10 - Large Projects

[tcopeland]

> 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.

Re:Chapter 10 - Large Projects

[glwtta]

Just because most people writing PHP apps are sloppy armature coders does not mean that powerful well designed apps can not be written in PHP.

Sure. It's still patently ridiculous to claim that most large projects are written in PHP (even if we are just talking about web projects).

I also happen to think that PHP makes writing "powerful well-designed apps" a bit harder than necessary, but that's just me.

Re:Chapter 10 - Large Projects

[Anonymous Coward]

Rails and its ilk really emphasize the start-up cost, those first couple of days that are essentially irrelevant in a large project.

Not to mention that those basically go away when you use Maven archetypes or something like AppFuse to start the new project out with a well developed/tested skeleton.

Re:Chapter 10 - Large Projects

[kbob88]

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. They appear to do OK. We just throw hardware at any problems. It's a lot cheaper than developer time.

Production architecture, webserver integration, and deployment were all huge pains two years ago. But we've got that all ironed out over time. However, I will say that these 'Chapter 10 issues' have long been the most poorly documented issues in Rails. Looking back, I think that most of our early deployment issues related to lousy or non-existent documentation. And a few bad choices of hosting solutions. But I could say the same thing about numerous other frameworks...

Re:Chapter 10 - Large Projects

[FooBarWidget]

"Brutally honest" huh? Neither articles give a lot of details. Based on the given information in the articles, they might just as well have failed because their developers are incompetent. Oh, and you're posting as AC. That says a lot.

Re:Chapter 10 - Large Projects

[Anonymous Coward]

web2py loves to throw around "enterprise" every other word on its pages.

Nothing about APIs for message queues, distributed transactions, session replication, and so on. What I see is yet another ORM and template engine sort of glommed together and called a framework. Nothing vaguely resembling mind-blowing.

Re:Chapter 10 - Large Projects

[tcopeland]

> 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.

Re:Chapter 10 - Large Projects

[Sancho]

I also happen to think that PHP makes writing "powerful well-designed apps" a bit harder than necessary, but that's just me. I feel this way about Rails and PHP. PHP does pretty well at writing powerful apps, and Rails does pretty well at writing well-designed apps. Neither gets both powerful and well-designed simultaneously.

I think that you'll find this true of most frameworks.

Re:Chapter 10 - Large Projects

[glwtta]

I feel this way about Rails and PHP.

I don't disagree.

I think that you'll find this true of most frameworks.

Yeah, that's kind of the point of frameworks - you trade flexibility for convenience.

Re:Chapter 10 - Large Projects

[cyberon22]

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 solution, but somewhat defeats the point of using a framework.

Anyone with experience?

Re:Chapter 10 - Large Projects

[tcopeland]

> 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 be tuned, stuff that should go in memcached, page and fragment level caching, and so forth; that makes the difference.

> the framework encourages development without much concern for database speed

Very true. But you know what they say about premature optimization... and you can always load a bazillion records into a test db and find the bottlenecks. I just sorted out one of those for a customer a few weeks ago; PostgreSQL's EXPLAIN ANALYZE to the rescue...

Re:Chapter 10 - Large Projects

[mosch]

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 people who really understand web servers.

Rails doesn't change those requirements, it just provides a different language to write the bits in the middle.

Re:Chapter 10 - Large Projects

[rfunk]

My evidence is the last two years that my colleagues and I have been developing in Rails, increasingly realizing we could handle much larger and more complex applications than we could in our PHP days.

This has nothing to do with the startup cost.

PHP, meanwhile, is now relegated to the land of trivial apps, if we use it at all.

As for scaling: Again, my experience is that Rails makes the programmer happy while giving some new challenges to the sysadmin who has to deploy the thing.

Re:Chapter 10 - Large Projects

[glwtta]

increasingly realizing we could handle much larger and more complex applications than we could in our PHP days.

Well, sure, if we are comparing it to PHP. I don't think anyone's ever accused PHP of scaling well with complex projects. Yes, yes, it can be done, but PHP will fight you every step of the way.

"Advanced" for RoR is routine for everyone else.

[Anonymous Coward]

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.

Please O PLEASE stop the Ruby hype

[gatkinso]

Just a simple request.

Re:Please O PLEASE stop the Ruby hype

[e4g4]

You're right. Fortran should be good enough for anyone.

Re:Please O PLEASE stop the Ruby hype

[TheRealMindChild]

What do you think is better... PHP and MySQL?

Probably.

Re:Please O PLEASE stop the Ruby hype

[SanityInAnarchy]

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:Please O PLEASE stop the Ruby hype

[navyjeff]

You're right. Fortran should be good enough for anyone.
Yes! We should start creating FORTRAN on Rails right away.

Re:Please O PLEASE stop the Ruby hype

[TimHunter]

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.

Re:advanced rails? practicle php?

[Anonymous Coward]

Java is for pussies. Fortran 4 life!

What to do?

[AKAImBatman]

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:What to do?

[PPH]

Switch to VB. There's a new implementation "Visual Basic on the Skids" coming out soon.

Review Source

[Anonymous Coward]

Is is just coincidence that all these reviews show up a couple of days after the scene release of the corresponding ebook? Just wondering. BBL released this title last Friday.

The pattern is strong.

Re:Review Source

[MrAngryForNoReason]

Is is just coincidence that all these reviews show up a couple of days after the scene release of the corresponding ebook?

The pattern is strong.

Yes I imagine the pattern goes something like:

1. Ebook released
2. Ebook bought and read
3. Ebook reviewed on Slashdot
4. Profit!

Or are you suggesting that reviews should be posted before the book has been released and read?

Advanced Rails?

[Anonymous Coward]

Isn't that an oxymoron?

Up there with Advanced Train Wrecks

[Anonymous Coward]

Does anyone else here think Ruby on Rails is just horrible? I've looked at it and all I can say is I'm so glad I don't have to develop with it at work. Not intended as flame-bait but a serious question: At what point is a language or development environment so bad that your best advice would be walk away?

Required reading

[tcopeland]

> 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.

Referencing? I smell a rat

[Billly Gates]

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:Referencing? I smell a rat

[glwtta]

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.

Re:Referencing? I smell a rat

[chromatic]

That's Slashdot's own referrer link, and Slashdot's put them on book reviews for years.

Re:"Advanced" for RoR is routine for everyone else

[SanityInAnarchy]

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.

Few 'Advanced' rails books?

[weopenlatest]

Perhaps it's because Rails is not an 'Advanced' language. Rails makes for quick development of cookie cutter apps, but fails to scale or customize properly. Most developers will read the intro book, but by the time they're ready for a second lesson they've already switched to something better.

Re:Few 'Advanced' rails books?

[felipekk]

http://xkcd.com/285/

Re:Slashdot Special Alert :

[Tablizer]

What's next? : "This is a resilient economy". - George W. Bush.

More likely: "The economy is resilientizing itself so that the mericun people cun put food on thr families".

Please O PLEASE stop equating Ruby and Rails

[vjoel]

Ruby's been around for more than 15 years, though it didn't get used much in the US until 2000.

Not only are there a lot of interesting non-web projects[1] in ruby, there are a lot of non-Rails web frameworks[2] in ruby.

[1] http://sciruby.codeforpeople.com/sr.cgi/InterestingProjects

[2] Nitro, Merb, Ramaze, Camping http://ramaze.net/home#other-frameworks

Re:Please O PLEASE stop equating Ruby and Rails

[demallien2]

++ for point #1. I actually learned Ruby as part of using Rails. I've since let my Rails development slide a bit, but I'm using Ruby everywhere else - I have just finished writing a c-parser/automatig glue code generator for a virtual machine, all done in Ruby, and I'm also developing Cocoa apps on Mac OSX using RubyCocoa (the FSM's gift to Mac programmers everywhere).

Rails ?!

[Zeraw08]

Who needs them ? PHP forever !

Re:"Advanced" for RoR is routine for everyone else

[Anonymous Coward]

I do try to keep abreast of new technologies.

heheheheeheh "breast"

Not So!

[MyDixieWrecked]

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.

has anyone really gotten RoR to scale?

[GoldTeamRules]

I ask in all seriousness. We are about to yank our website written in RoR and port it to php for performance reasons.

Re:has anyone really gotten RoR to scale?

[Anonymous Coward]

Sure it can scale--you'll need to invest time in really grokking Rails, Ruby, some supporting technologies and possibly some hardware money will be needed as well, but it can scale just fine. You don't say what your performance problems are, though, and knowing those would help me offer some targeted advice. In lieu of those, 3 common bottlenecks, for whatever they may be worth for you.

1. AR database connections are single-threaded out of the box. Long-running db operations are bad. If you can, look to streamline any of them. If they can't be streamlined, you'll need to pool Rails instances and load balance requests into them. Note: you may come across an Active Record config property, allow_concurrency. Setting it true generally doesn't help and often makes things worse in unpredictable ways--save yourself much time and headache and don't go down that alley.

2. If you are running a site with any material volume Webrick isn't going to cut it for you, on the off-chance you're still using it. Mongrel and Apache are your best friends for supporting the above-mentioned pooling, as well as a wide variety of other performance optimizations. Invest the time necessary to understand how to work with them together to support Mongrel instance pooling and to allow Apache to handle static content.

3. If your app uses sessions, research the various session options Rails supports and chose something other than pstore, as it is not your friend for high-volume systems.

If you've already worked through the above, my apologies for wasting your reading time. If not, hopefully they can help. #1, in particular, is a nasty trap for new Rails developers.

Re:has anyone really gotten RoR to scale?

[filterban]

Twitter uses RoR, so yes, it is possible.

Can some kind soul explain REST?

[daviddennis]

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?

D

Re:Can some kind soul explain REST?

[Anonymous Coward]

REST is just about being object oriented, and using URLs to address objects in an orthogonal matter. It makes you think of your app as a big database of objects instead of a set of actions. The rest of the REST story is largely a bunch of hype-filled zealotry (not all, but most).

Nothing prevents you from requiring authentication for whatever architecture you pick. Flickr and Google both have REST APIs, and both require a key.

If you're still so deathly afraid that someone might "mashup" your site, I suppose you can write the whole thing as an applet. Your competition won't, but of course if you're right, they'll go out of business and you won't.

Re:Can some kind soul explain REST?

[daviddennis]

Maybe the question I really wanted to ask was, what is the benefit of mashups from the point of view of the application being called?

For example, what does Flickr gain from the availability of the Flickr API?

In other words, I'm not saying "Hey, I'm against Mashups", I'm saying "Look, I don't understand Mashups. They seem downright deadly from a business perspective. Why are people eager to create software that can be involved in mashups when the business case looks like I should run and hide?"

I'd like to know what I'm missing, in other words.

Any clues?

D

One more thought: Come to think of it, the myspace worm, which disrupted myspace for weeks and made Samy a hero, albiet a hero with a criminal record, could be thought of as a mashup. It used services made available by myspace in what I think even myspace would consider a highly creative, albiet demented, manner. Is that the future of computing? Should we want it to be?

Threads workaround

[metalhed77]

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 scalable as isolated parts.

Re:Threads workaround

[Standard User 79]

I've seen merb and looks good. I haven't dug too much into ruby threads but it seems like the threading lib has some fundamental problems: http://headius.blogspot.com/2008/02/rubys-threadraise-threadkill-timeoutrb.html

Multi-process model is unforgiving compared to multi-threads. In many heavy duty web application environments memory is your most precious resource (even more precious than i/o) and a process model is not going to handle this very well. Consider a case where your s3 service is slower than normal one day and your processes are waiting 2x longer than normal. Well while these processes wait they are holding up a good amount of memory that can't be used anywhere else .. it's just wasted. This is where scalability and capacity planning issues can hit you in a bad way.

Re:Threads workaround

[FooBarWidget]

The timeout() implementation is a problem, but it's the only reasonable way to implement it, in ANY language. Using it means that the programmer has to be aware of potential issues, like any other use threading. That said, the places in which I use timeout() have been carefully reviewed that no racing conditions can occur. Boring isn't it, to know that all languages have the same issues?

As for processes vs threads: where did you get the idea that a process is more heavyweight than a thread? Modern Unix operating systems allow different processes to share memory, and this has been the case for several decades. Please, go read a good book on operating systems design, in particular about the topics "memory paging" and "copy on write".

For example: suppose your application uses 500 MB memory. If you fork() a new process, then the total memory usage is not 1 GB, but something like 500.01 MB. When used correctly (which isn't a hard things to do), processes can be as lightweight as threads, with the added benefits that they can't crash each other. In fact, an upcoming Ruby on Rails deployment solution will make use of this fact, resulting in dramatically lower memory usage.

Re:Threads workaround

[metalhed77]

One small problem is that ruby is not copy-on-write friendly, forked processes dirty up pages and lose the memory savings, there's a bunch of posts over at: http://izumi.plan99.net/blog/ explaining the issue, he also has a few patched to ruby to fix this. I don't know if YARV or Rubinius are going to fix this in release versions in the future.

Re:Threads workaround

[FooBarWidget]

That's me. You linked to my own blog. :)

Rubinius is already copy-on-write friendly. Yukihiro Matsumoto has shown interest in my patch, and I'm currently trying to get it merged back to upstream.

Re:Threads workaround

[Standard User 79]

no. Each new mongrel instance is a completely new runtime environment. My engineers estimate a cost of 20MB per mongrel process on rails 1.1. You don't know what your talking about.

Re:Threads workaround

[FooBarWidget]

Correct. *Mongrel* uses 20 MB per process. ;)

Not so with the new Rails deployment solution that will soon be released. Tests so far has shown that it reduce memory usage in your Rails apps by 33% on average. It also makes Rails deployment easy as cake - only uploading files is required. No manual port management, no manual cluster management, no manual Rails-specific configuration. Resource usage is automatically adjusted to traffic.

If you're interested, I can provide you with more information.

Ruby on Wings

[rice_burners_suck]

The next step after Ruby on Rails is to go airborne: Ruby on Wings.

Enterprise

[mdipierro]

The word "enterprise" appears twice on the web2py web site. It is part of the name. Many people have complained about it since occasionally "enterprise" has a negative connotation. web2y actually is a free and Open Source MVC framework like rails. For web2py the word "enterprise" represents the fact that it is stable, maintained, always backward compatible, easy to use and deploy, and designed for multiple applications that cooperate with each other (via cas, xmlrpc, xml, rss, databases, etc.).

Really boring example of Rails money $100/hr

[patio11]

http://www.bingocardcreator.com/ 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.)

Widespread use != high paying jobs

[patio11]

I would rather be where the commodity programmers aren't than where they are, all else being equal...

Ruby on Fails

[poor_boi]

Ruby on Fails [epic]

Haml information

[hampton2600]

They briefly mentioned Haml... which has made a big impact in the Rails and Cake PHP development communities. Yes.... I made it and I'm pimping it here.

• Main/Ruby Haml: http://haml.hamptoncatlin.com/
• Cake PHP Haml: http://bakery.cakephp.org/articles/view/haml-markup-haiku

Enjoy, bitchez!

(plug, plug, plug)

Re:Haml information

[bradediger]

Sweet. I just experimented with Haml enough to be able to write it up in the book. I really like it, though my UI designers have all but nixed the idea of moving to it for our large projects, as they want to work in HTML. Such a shame...

Project wise that may be an issue.

[jotaeleemeese]

Where I work sys admins earn as much (or more) than developers, so cost wise it may be damaging to make sys admins life difficult, negating any gains for developers in the great scheme of things.