Slashdot Mirror
Ruby on Rails 2.0 is Done
Jamie noted that ruby on rails 2.0 is done. In addition to upgrade and installation instructions, the article lists a number of the more interesting new features in the release which appears to be quite extensive.
← Back to Stories (view on slashdot.org)
I wonder if they still disallow proper database design by having a requirement of an autoincrementing number for the primary key.... The Rails developers could learn a thing about databases. Start here: http://en.wikipedia.org/wiki/Database_normalization . Yes I know that a serial/autoincrementing key makes it easy for the app... it makes it a lot harder for the DBA in a lot of cases.
Get your PostgreSQL here: http://www.commandprompt.com/
Fresh Meat, full of bugs, for the hackers to hack.
If you desire a secure system, do not place a large, immature body of code in the line of fire on the internet.
Evil people are out to get you.
I don't understand the fuss behind Ruby on Rails. Ruby is a programming language. Rails is a framework. Frameworks are a dime a dozen. Is RoR all that wonderful or are we being marketed-to?
Don't piss off The Angry Economist
I doubt it.. Rails has never been known for actually using the database for more than a flat file... One of the reasons it can't scale.
Get your PostgreSQL here: http://www.commandprompt.com/
Back when I was a young whippersnapper, we called that thing a relative record number!
OmniNerd.com, a site I do hobby development for, is running on Rails 2.0. We switched over from PHP this fall and site maintenance has been a dream since. Our site has even survived a few Slashdottings and Diggs since the switch, which used to murder it before. (Granted, the PHP code wasn't the best.) I've heard the "doesn't scale" debate a million times, but I'm curious if there is anyone out there who has recently moved a project from one language/framework to Ruby/Rails and whether you're glad you did or if it's been a nightmare. We're a medium-to-low traffic site with big surges every few weeks and it's worked well for us.
Mark A. McBride -- OmniNerd.com
While Rails might not be my first framework of choice to implement Digg in, I prefer to build sites which actually, you know, make money by solving problems for paying customers. When you do that, you don't really have to worry about scaling to infinity and beyond, but you do have to worry about expressiveness, maintainability, and time to market. (If you have too many customers relative to servers, heck, easy solution there -- the engineer in me says "just throw up more boxes", but the businessman in me says "pay somebody to worry about it so I can go back to counting my benjamins".)
I have a Rails site, my first (hopefully of many) for my small business, which plugs along at about 20 requests a second in tests. If I could saturate those 20 requests a second, I would quit my day job on the spot. Scaling? Eh, who cares.
(P.S. Day job is writing enterprise level crud apps for Japanese universities on the J2EE stack. They worry a bit about, e.g., getting hit with 8k users signing in simultaneously during class registration. You know what we do? Exactly what I'd do for a Rails app in the same situation ("don't do anything stupid like an n+1 queries loop, cache the important stuff, and buy enough hardware for the job"). Only difference in Rails is I have never wanted to poke my eye out with a spoon while writing it.
Help poke pirates in the eyepatch, arr.
Ever notice how those most "concerned" about scalability tend to have never profiled or benchmarked their own code? ... or understand why you want to scale horizontally, rather than vertically? Whenever I build services that can handle 120,000 requests/sec., they usually just end up being 99% underutilized. Everyone likes to think THEY will be the next MySpace, with no server budget apparently. I highly doubt that any who argue Rails can't scale has ever had to deal with real distributed clusters. The database cluster will have many more scalablity issues than the webservers. This is such a non-issue, I cannot believe it. If you can scale JAVA!!!... You know what I mean.
Okay, all I see on here is negative comments, what ever happened to the concept of "the right tool for the job"? Ruby on Rails is a gem (excuse the pun) in the realm of bioinformatics and chemical informatics. I don't need to be concerned with "scaling" when I am building a site with a maximum of 10 users. For labs and small companies everywhere needing to create and support small or large databases, RoR is fast and easy. It also has major industry backing from the likes of IBM and Apple. It may be a bigger problem for high-volume sites, but I have found it extremely useful. I am using it on the backend (for data management - the data is exported from the database to the legacy perl system daily) for sites like http://www.drugbank.ca/ http://www.hmdb.ca/ and on the frontend for sites like http://hmdb.med.ualberta.ca/foodb/.
Yeah, and thats what I don't really like about frameworks in general. They have all of these awesome cool fast easy to use things built in. But sometimes you discover that your needs are too complex for the framework, and someone instantly replies " you don't have to use feature X". Well sooner or later you aren't using many of the cool features of the framework anymore. So why are you using the framework?
Well.. maybe. Or Maybe not. But Definitely not sort of.
Perhaps a web development framework's web site should be designed in such a way that it can handle a burst of traffic from Slashdot.org and Digg.com.
Otherwise, one might think that RoR doesn't scale.
What language do you use that's more readable and expressive than Ruby?
Exactly. The fact is, Ruby is slow. Rails is slower. This is a very accurate complaint about Rails as a web framework, although in the real world it's generally not much of a problem. Somehow though, people have confused speed with scalability, and start claiming the Rails isn't scalable. In fact Rails tends to encourage or at least make fairly easy a shared-nothing architecture which allows a trivial "throw more servers at it" solution to scaling
That said, because of Rails speed, you will wind up needing to scale it sooner and larger than you would a site written in Django, say. If people want to complain about the hardware costs of running a real-world Rails site, I encourage them to do so and put up real numbers regarding the money they spend on developer time and other company expenses vs. server costs, and how Rails being so CPU-hungry is killing their bottom line. So far I've seen none of that, just uninformed whining
Or rather, since I haven't been keeping up with the development process, perhaps I should ask, is there a viable apache 2.x module for ruby that allows one to run RoR sites without relying on mongrel/other web servers?
Because, frankly, if it can't be run on apache 2.x, I (and the company I work for) won't touch it. We have already seen the scalability nightmare that RoR was, of course, so obviously we're a bit skeptical about performance optimizations. (:
Note: I have nothing against using new technology, even if it requires learning a new language, but when one has a hundreds of sites that require web server A, and a framework requires the shoehorning of web server B, well, the aforementioned framework loses its appeal.
The wise follow a damned path, for to know is to be forsaken.
RoR is just another framework now. Almost everything has caught up to it. The biggest question to ask yourself is "Do I want to program in Ruby?". If the answer is "no" then meh who cares about this.
Every time a RoR article hits Slashdot, there is a scale/speed question that gets raised. Realistically, there are a ton of things you can do to get performance where you want it to be. The first is to dump mongrel and use FastCGI or similar. FastCGI is 3-5x faster than mongrel. Mongrel is great for low traffic sites, and for dev, don't get me wrong.
:update => 'some_div', rather than using the rjs/render :update stuff in the controller. escape_javascript is one of the BIG performance issues in Rails, as it is basically just multiple gsubs. Designing around that is a big win. A native C escape_javascript should be a high priority for the rails/ruby devs, with optimization for the memory allocations (ie. scan the string to see how much it will grow, allocate, and just do one pass to expand).
The upper limit I see with RoR/FCGI is around 2500 requests per sec, for a 'is the server alive' ping, that simply returns 'Yes'. Typical, results are in the ~100 requests per second range with moderate db access, and rendering to xml or html. 100 requests per second was enough to handle a 24 hour media buy on the frontpage of myspace for example (100,000k unique visitors-ish).
Moving your static assets off of your server and on to S3 or another CDN is obviously a big help here, so your server/bandwidth is only taken up with requests that need/affect the db. From the example above, with the MySpace media buy, the total for that day was $20-30 I believe in bandwidth costs, and this was a site with a video mixer that had tons of images/video/mp3 and large flash objects. Obviously, mongrel shouldn't be delivering your assets locally anyway, apache/lighty etc should be.
Ultimately it comes down to design and caching when it comes to getting that top performance out of it. My 100 requests/sec wasn't using MemCached or fragment caching, and the mysql db was local. Caching in Rails is a little less than helpful for highly customized for each user sites, but there are plugins that extend it like extended_fragment_cache(ing?), that allow you to templatize things like ID's, etc. Think of say a forum topic listing, where only the topics change as you paginate. With extended fragment caching, you basically draw the page once, and then pass in a hash of the variables that replace the placeholders each time you draw a new page.
Another big thing with ajax sites, is to use link_to_remote with the
http://blog.slaingod.com
I agree. That's why I build all of my computers by hand with raw transistors and whatnot.
This is my sig. There are many like it, but this one is mine.
You're absolutely right: Rails is just a framework on top of Ruby, and neither are very special. Except in that a lot of people were still using crap coding techniques like mixed PHP and HTML, until frameworks like RoR and Django introduced them to MVC, ORMs, templates, and Unit Testing --- AND the speedups and elegance that go with those things, once you have an actual framework that does the boilerplate for you.
There's nothing special about RoR, no. But compared to tools like PHP, it's a godsend.
that one cannot simply deploy RoR on Apache. That is what remains the big advantage of perl and especially PHP-based solutions and frameworks.
Comment removed based on user account deletion
Stored procedures can improve performance by reducing the amount of data that needs to be returned from the DB. Instead of getting a ton of data from the DB, the application can make a call and only get the data it wants. This simplifies application development and improves performance. You can think of things like MAX, MIN, etc... as stored procedures (I don't know if they are or not)
I have been at places were the DBAs have found very expensive calls to turn into stored procedures and the net result has always been an increase in performance and resulted in a simpler application.
Example:
Get all shoes
for each shoe {
get all skus for that particular shoe type (these would be different sizes/colors)
calculate the minimum and maximum price of the skus that are in stock
}
return shoe name, shoe desc, price range
(This might be a bad example, since good SQL and a good DB might be able to speed this up...but I'm not an expert)
Note: I am an (C/C++/Java) application developer, not a DBA
Seriously.. why does Ruby on Rails get so many people so fired up? If you don't like it, don't use it. If you do like it, feel free. There's no one-size-fits-all solution, but for many people Rails comes pretty close. If you're not one of those people, there are plenty of other frameworks and languages.
Why do people in any kind of IT have such huge egos? It's counterproductive and at the end of the day, if you're making the client happy, and that makes your boss happy, you've done your job.
Yeah, I do too. I think its very worthwhile for anyone in IT to actually build circuits from time to time, just to understand how. I understand the criticism you're making and its somewhat valid. I'm not trying to espouse the Not invented here syndrome. You have to make a real world decision in every non trivial application what existing tools can be used, and which ones will have to be created. I like the idea of libraries, and thats what I think a good "framework" should be. Sort of a scaffolding, where there is a well defined interface between components, allowing you to easily replace part of the "framework" with a different one, without introducing any bad hacks, and allowing all of the logically distinct parts of the "framework" to continue working with your replacement part.
Well.. maybe. Or Maybe not. But Definitely not sort of.
Check out django. As that article mentions MVC efforts can become overly restrictive very easily. If you ask me, Ruby on Rails has already crossed that line. django is mvc as well so someday might go down this path, but it hasn't yet.
django provides all of the ease of Ruby on Rails, it is powerful, it provides even more tools than Ruby on Rails in my opinion specifically for web work. And I don't feel like I have handcuffs on when I'm developing in it.
I started building 2 projects in Ruby on Rails ~8 months ago. These were existing PHP systems which had become overly cumbersome and were in serious need of a redesign/rewrite. Rails seemed to provide everything I needed, began porting... got about 30% done and started running into serious roadblocks that were there by design in Rails.... I aborted the porting, and started looking for another framework, found django... the 2 projects are now 100% ported (took less than 1 month each).
django was also significantly easier to set up for production than my experiences with rails (apache? lighthttpd? mongrel? the recommended web server for rails changes every week...) modpython+apache is dead simple to set up and rock solid (apache+rails requires fastcgi which was constantly crashing, unstable, and basically doesn't work)
obviously I'll get flamed for this as RoR has way too many fanboys, but as far as a concise, powerful, well documented, easy to use, flexible, and enjoyable development experience nothing gets close to the last 2-3 months working with django.
"If you have a scaling problem, you don't have a problem."
Which basically means if you've got 200 000 hits a day and your existing setup is folding under the load, you've found a glory hole on the webbernet. And you're likely to find the funding required to scale the site - even if that means moving to an entirely new technology alltogether.
We suffer more in our imagination than in reality. - Seneca
Ever done a `man` on `top` ?