Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Advanced Rails

samzenpus posted more than 6 years ago | from the read-all-about-it dept.

170

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

cancel ×

170 comments

Sorry! There are no comments related to the filter you selected.

I'd recommend the Rails Cookbox instead (4, Informative)

Anonymous Coward | more than 6 years ago | (#22776974)

If you are looking to O'Reilly for Rails info, I'd rather recommend their Rails Cookbox [amazon.com] , 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 (2, Informative)

Anonymous Coward | more than 6 years ago | (#22777082)

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

advanced rails? practicle php? (0)

Anonymous Coward | more than 6 years ago | (#22776980)

slashdot, these reviews are ASKING for flames, harharhar

Re:advanced rails? practicle php? (1, Funny)

Anonymous Coward | more than 6 years ago | (#22777100)

Java is for pussies. Fortran 4 life!

Re:advanced rails? practicle php? (-1)

Anonymous Coward | more than 6 years ago | (#22777172)

They're actually asking for a Rick Rolling [yougotrickrolled.com]

Good old RubyOnRails (4, Funny)

realmolo (574068) | more than 6 years ago | (#22776982)

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

Re:Good old RubyOnRails (4, Interesting)

Peter Cooper (660482) | more than 6 years ago | (#22777038)

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 (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#22777262)

Yawn. Humorless idiot.

Re:Good old RubyOnRails (2, Insightful)

Anonymous Coward | more than 6 years ago | (#22778068)

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 (2, Insightful)

Sancho (17056) | more than 6 years ago | (#22777708)

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

Re:Good old RubyOnRails (1)

misleb (129952) | more than 6 years ago | (#22777046)

Pays my bills.

Re:Good old RubyOnRails (2, Interesting)

Lysol (11150) | more than 6 years ago | (#22777074)

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 [pivotallabs.com] from a company doing more than just paying the bills.

Re:Good old RubyOnRails (3, Interesting)

e4g4 (533831) | more than 6 years ago | (#22777142)

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

Re:Good old RubyOnRails (2, Insightful)

DJ Jones (997846) | more than 6 years ago | (#22777164)

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 (4, Interesting)

e4g4 (533831) | more than 6 years ago | (#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.

Re:Good old RubyOnRails (1, Interesting)

Anonymous Coward | more than 6 years ago | (#22777426)

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 (3, Insightful)

devjj (956776) | more than 6 years ago | (#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:Good old RubyOnRails (1, Insightful)

Anonymous Coward | more than 6 years ago | (#22778212)

There's a simpler reason for bashing Rails: it's a threat. It's just that simple.

There's an element of truth here, just not the one you think there is. I don't want to lose work because some naive client buys into the unfounded bullshit surrounding RAILS. My apps will take twice as long to develop but will be cleaner, tighter, scale better and I probably won't be that much more expensive either. I can't go insulting clients by saying that straight out, not after they swallowed the horseshit you and other RAILS fanbois manage to spout at every possible opportunity!

So the threat is that we (established freelance developers) may be forced to learn this cookie-cutter, paint-by-numbers framework to keep clients happy. That hurts when we understand full well that the better engineered solution would have been courtesy of Java, ASP.NET or even PHP.

Small shops offering RAD are not the sole preserve of RoR fans and honestly if the community cut the hype and bullshit they wouldn't be getting called on it. Oh and fuck DH too, initial programming work is a more or less sunk cost but hardware, connectivity, and power [iht.com] are not (AKA: DH, meet inflation you fool!).

Re:Good old RubyOnRails (2, Insightful)

devjj (956776) | more than 6 years ago | (#22778412)

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 (1)

Sancho (17056) | more than 6 years ago | (#22778496)

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 (4, Insightful)

devjj (956776) | more than 6 years ago | (#22778610)

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 (0)

Anonymous Coward | more than 6 years ago | (#22778722)

You honestly think that any app you write is going to be better than its analog built in Rails?

I said "cleaner" by which I'd mean no indirection thru active record and no relying on a framework specific dispatch handler. I said "tighter", by which I mean that there's little to no interpreted framework baggage. I said "scale better" which is undeniable for any interpretation of the word "better". Throwing hardware at a problem isn't a sensible solution and plenty of businesses that have taken this route are going to pay dearly -- read the link from my last post.

That you are a better developer in your chosen language/framework than every other Rails developer on the planet?

My chosen framework is called "the right tool for the job", you should try it! Seriously, I don't have a chosen language or framework and I never claimed I was a "better developer". My case was made via self evident truths and widely made observations about RoR.

And you call Rails guys arrogant?

No I didn't, I accused them of constantly spouting horseshit.

But yeah the rails guys are arrogant, they promote the framework as a solution well above its station and deal with criticism by saying "that's not the Rails way". The more clueful developers who use RoR are quite openly saying that "the Rails way" often sucks.


Re:Good old RubyOnRails (3, Informative)

Dhalka226 (559740) | more than 6 years ago | (#22779190)

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 5 or 10 years. If you're building a site for a client who expects to be able to plop it down and not touch it for the next 5 years, well, great, maybe they reach the tipping point. Heck, even 1-2 years is a long time in the web world. However, the reality is that the web doesn't work that way most of the time; that sites either die off or development on them continues and is an ongoing cost. In almost all cases, being able to significantly reduce development cost is going to be a net gain for the client and Rails is a tremendous tool in being able to do that.

Re:Good old RubyOnRails (3, Informative)

SanityInAnarchy (655584) | more than 6 years ago | (#22777504)

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 [rubyhitsquad.com] examples [robbyonrails.com] 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 (2, Interesting)

devjj (956776) | more than 6 years ago | (#22777586)

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 (2, Interesting)

SanityInAnarchy (655584) | more than 6 years ago | (#22778250)

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 [redhillonrails.org] for that, and another [redhillonrails.org] 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 [merbivore.com] , 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 (1)

Sancho (17056) | more than 6 years ago | (#22778554)

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 (1)

cbart387 (1192883) | more than 6 years ago | (#22779204)

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 (1)

glwtta (532858) | more than 6 years ago | (#22777508)

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 (2, Informative)

realmolo (574068) | more than 6 years ago | (#22777598)

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 (1)

fartrader (323244) | more than 6 years ago | (#22778376)

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 (1)

devjj (956776) | more than 6 years ago | (#22778702)

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 (5, Insightful)

Standard User 79 (1209050) | more than 6 years ago | (#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.

Re:Good old RubyOnRails (0)

Anonymous Coward | more than 6 years ago | (#22777576)

Ruby is a nice clean language, although the official runtime is a little slow. The problem is purely with the limiting RAILS framework and the unfounded hype surrounding it.

It outdoes PHP as the AOL of web development tools and it's "me too" proponents (despite many of them being obviously incapable of engineering a decent ground-up web app) are hyping it as the solution to everything. It's a crap half-baked solution (dispatch.rb) that manages the enviable task of making servlets and mod_php look elegant, so half-baked in fact that most RoR sites are reverse proxied.

I don't know why we're still having this discussion, web development frameworks are available for many languages -- and IMO useless for any major bespoke development. Framework, Painflurt!!! Kids, get off my damn lawn and save it for your MySpace pages!

Re:Good old RubyOnRails (1)

Doug Neal (195160) | more than 6 years ago | (#22779030)

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 (2, Informative)

kbob88 (951258) | more than 6 years ago | (#22777804)

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 (2, Informative)

CoughDropAddict (40792) | more than 6 years ago | (#22778184)

My resume [reverberate.org] 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.

Not So! (1)

MyDixieWrecked (548719) | more than 6 years ago | (#22778326)

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.

Re:Good old RubyOnRails (1)

ehrichweiss (706417) | more than 6 years ago | (#22778564)

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

Re:Good old RubyOnRails (1)

carlivar (119811) | more than 6 years ago | (#22778602)

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

Re:Good old RubyOnRails (2, Funny)

bigtrouble77 (715075) | more than 6 years ago | (#22778774)

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.

Chapter 10 - Large Projects (3, Insightful)

moore.dustin (942289) | more than 6 years ago | (#22777034)

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 (0)

Anonymous Coward | more than 6 years ago | (#22777190)

Selecting RoR for anything other than cookie-cutter, me too web apps is a sure sign that the wrong person/team* were tasked with the job.

* Yes they are also quite evidently "a tool"/"a bunch of tools"!

Re:Chapter 10 - Large Projects (0)

Anonymous Coward | more than 6 years ago | (#22777208)

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 (1)

h4ter (717700) | more than 6 years ago | (#22777246)

yellowpages.com [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 (1)

howdoesth (1132949) | more than 6 years ago | (#22777334)

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 (1)

h4ter (717700) | more than 6 years ago | (#22777522)

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 (1)

mdipierro (1163129) | more than 6 years ago | (#22777264)

Rails is old news. Try something really new and mind blowing. [web2py.com]

Re:Chapter 10 - Large Projects (0)

Anonymous Coward | more than 6 years ago | (#22778098)

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 (1)

rfunk (765049) | more than 6 years ago | (#22777312)

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 (2, Interesting)

glwtta (532858) | more than 6 years ago | (#22777452)

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 (0)

Anonymous Coward | more than 6 years ago | (#22777954)

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 (0)

Anonymous Coward | more than 6 years ago | (#22777342)

I haven't read the book but for large project I heard Ruby doesn't scale so well. Everything is so black magic. I believe most large project are mostly written in PHP.

Re:Chapter 10 - Large Projects (1)

glwtta (532858) | more than 6 years ago | (#22777406)

I believe most large project are mostly written in PHP.

Heh, nice one.

Re:Chapter 10 - Large Projects (1)

Frosty Piss (770223) | more than 6 years ago | (#22777428)

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 (1)

glwtta (532858) | more than 6 years ago | (#22777634)

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 (1)

Sancho (17056) | more than 6 years ago | (#22778650)

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 (1)

glwtta (532858) | more than 6 years ago | (#22778872)

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 (3, Funny)

misleb (129952) | more than 6 years ago | (#22777478)

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 (0)

Anonymous Coward | more than 6 years ago | (#22777456)

I really liked what Curt Hibbs said a while ago on a mailing list:

The important question is do programmers scale? Can ten programmers do ten times the work of one programmer?

DHH made it quite clear that if you need less programmers, but spend more with hosting you'll still end up paying less by using Rails.
As a plus, I think that the code is easily maintainable and can be improved with a relative ease by coders that weren't the original applications designers.

Re:Chapter 10 - Large Projects (3, Interesting)

tcopeland (32225) | more than 6 years ago | (#22777532)

> 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 (0)

Anonymous Coward | more than 6 years ago | (#22777616)

Isn't there a famous saying about optimization?

A naive application written in Rails on stock PC hardware won't scale to a billion hits a day. There, I said it.

But 99.99% of apps don't *need* to scale to that level. The traffic of the Nth most popular website is roughly proportional to 1/N. Unless you're a Google or a Yahoo, you don't need their kind of scaling. And even if you are the next Google, you don't need that kind of scaling *today*.

What you need today is to be able to build something that works. That's what Rails is pretty decent at. Then as you grow, you identify the bottlenecks, and eliminate them. Profile your queries, and get your resident SQL guru to tweak the expensive ones. Turn on the page cache and fragment cache and go tweak them. Add a few more web servers, and a few more db servers. (If you're running on S3/EC2 like us, this is *really* easy to do.)

You could build everything in assembly from day 1. It would go like a bat out of hell, but you'd run out of funding before it shipped. Rails is the opposite approach: make something that works, and we'll tune it later.

I suppose if you needed to, you could even start porting parts of your program to a lower-level language for performance. But 37signals hasn't had to do that, and I don't anticipate growing bigger than 37signals any time soon.

Come to think of it, the last 2 jobs I've had both had the strategy "build version 1 in (python|ruby) as a proof-of-concept, and then build a shipping version in Java", and both shipped the proof-of-concept because it was plenty fast already.

If you *really* want to scale big, you could write your own non-SQL database. This is exactly what Google did. I don't think you'll find many companies that did this and succeeded, and I don't think you'll find any "enterprise" operating that would be willing to do this. So the question is not "can Rails scale to the enterprise?", but "are my programmers good enough to get it to scale?". It really comes down to people.

Re:Chapter 10 - Large Projects (0)

Anonymous Coward | more than 6 years ago | (#22777946)

I wouldn't call them "horror stories". They're more like brutally honest, real-world analysis of how well (or poorly, to be more correct) Ruby on Rails tends to fare for larger projects.

Two insightful articles I've seen about this topic are:
7 reasons I switched back to PHP after 2 years on Rails [oreillynet.com]
Others are leaving Ruby on Rails, as well. And its not going well. [blogsavy.com]

Re:Chapter 10 - Large Projects (1)

FooBarWidget (556006) | more than 6 years ago | (#22778012)

"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 (1)

kbob88 (951258) | more than 6 years ago | (#22777966)

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 (1)

tcopeland (32225) | more than 6 years ago | (#22778140)

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

"Advanced" for RoR is routine for everyone else. (5, Insightful)

Anonymous Coward | more than 6 years ago | (#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:"Advanced" for RoR is routine for everyone else (2, Insightful)

SanityInAnarchy (655584) | more than 6 years ago | (#22777530)

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.

Re:"Advanced" for RoR is routine for everyone else (0)

Anonymous Coward | more than 6 years ago | (#22778028)

I do try to keep abreast of new technologies.
heheheheeheh "breast"

Please O PLEASE stop the Ruby hype (1, Interesting)

gatkinso (15975) | more than 6 years ago | (#22777080)

Just a simple request.

Re:Please O PLEASE stop the Ruby hype (2, Funny)

e4g4 (533831) | more than 6 years ago | (#22777184)

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

Re:Please O PLEASE stop the Ruby hype (0)

Anonymous Coward | more than 6 years ago | (#22777458)

I think that would be FORTRAN

Re:Please O PLEASE stop the Ruby hype (1)

navyjeff (900138) | more than 6 years ago | (#22777840)

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 (1)

TheRealMindChild (743925) | more than 6 years ago | (#22777416)

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

Probably.

Re:Please O PLEASE stop the Ruby hype (0)

Anonymous Coward | more than 6 years ago | (#22777892)

The sad fact is that most rubyists say performance isn't important, but if you go to any Rails talk or Rails shop, most of the time is spent on performance. Sure their program worked for 10 users and has been for the past week but the performance is utter crap that they invested man-months into improving it so it could scale.

Stop pretending that performance isn't an issue! It is! You spend 60% of your maintenance time on it, it is obviously important otherwise you wouldn't waste this time.

Grow up Rails!

Re:Please O PLEASE stop the Ruby hype (2, Insightful)

SanityInAnarchy (655584) | more than 6 years ago | (#22777564)

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?

Please O PLEASE stop equating Ruby and Rails (1)

vjoel (945280) | more than 6 years ago | (#22777642)

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 [codeforpeople.com]

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

Re:Please O PLEASE stop the Ruby hype (2, Insightful)

TimHunter (174406) | more than 6 years ago | (#22779166)

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? (5, Funny)

AKAImBatman (238306) | more than 6 years ago | (#22777110)

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? (2, Funny)

PPH (736903) | more than 6 years ago | (#22779528)

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

FIXED (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#22777118)

As Ruby on Rails rocketed into the development community's hearts and minds a few years ago

and then plumetted and was quietly forgotten.

Flamewar in 5..4..3..2..1.. (You can label me troll, but I'm sure this review will lead to the necessary flame wars anyway)

sex wi7h a cum (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#22777150)

Trouble. It recent article put BSD has always I sse the same but now they're

Slashdot Special Alert : (0)

Anonymous Coward | more than 6 years ago | (#22777160)


Slashdot is DEAD. You want proof? The Rail bullshits.

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

Wake up and smell the cocaine. The United Gulags of America has collapsed. The criminals-in-Congress just don't want to announce it and start The American Revolution: Part 2.

Get a life.

Re:Slashdot Special Alert : (1)

Tablizer (95088) | more than 6 years ago | (#22777602)

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

Re:Slashdot Special Alert : (0)

Anonymous Coward | more than 6 years ago | (#22777626)


users. Big deal.

I'm glad your comment got modded up . Mine ( of course) are permanently negative.

Slashdot will be sold to the Chinese this June. More specifically, June 15.

One meain problem with Ruby on Rails (0)

Anonymous Coward | more than 6 years ago | (#22777278)

Ruby on Rails is an internet developers dream. Unfortunately it flamin' bitch to get running in anything but a development environment. I love tinkering with my Linux box but getting Ruby on Rails to work properly with Apache pushed me to the limits of my patience. Fortunately I played around with it enough with its built in server to appreciate how good it was. If I hadn't I would have given up and carried on with PHP. That is a pretty big problem or people with idiot system admins who baulk at installing MySQL let alone anything 'tricky'.

Not to mention the book I purchased to get started just 6 months ago is so out of date now it is practically useless.

Review Source (0)

Anonymous Coward | more than 6 years ago | (#22777286)

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.

Advanced Rails? (0, Flamebait)

Anonymous Coward | more than 6 years ago | (#22777298)

Isn't that an oxymoron?

Up there with Advanced Train Wrecks (0)

Anonymous Coward | more than 6 years ago | (#22777326)

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 (2, Interesting)

tcopeland (32225) | more than 6 years ago | (#22777340)

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

What's a budding Rails-head to do... (0)

Anonymous Coward | more than 6 years ago | (#22777410)

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

Move on to a real language and learn how to program like a big boy? :)

Referencing? I smell a rat (1)

Billly Gates (198444) | more than 6 years ago | (#22777474)

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 (2, Insightful)

glwtta (532858) | more than 6 years ago | (#22777554)

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 (1)

chromatic (9471) | more than 6 years ago | (#22778312)

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

Few 'Advanced' rails books? (0, Flamebait)

weopenlatest (748393) | more than 6 years ago | (#22777560)

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? (0)

Anonymous Coward | more than 6 years ago | (#22778188)

Perhaps it's because Rails is not an 'Advanced' language.

Uh, Rails isn't any sort of language.

Re:Few 'Advanced' rails books? (1)

felipekk (1007591) | more than 6 years ago | (#22779312)

Rails ?! (0, Offtopic)

Zeraw08 (1218090) | more than 6 years ago | (#22777720)

Who needs them ? PHP forever !

has anyone really gotten RoR to scale? (1, Interesting)

GoldTeamRules (639624) | more than 6 years ago | (#22779242)

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

Can some kind soul explain REST? (2, Interesting)

daviddennis (10926) | more than 6 years ago | (#22779664)

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

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>