Ruby on Rails 2.0 is Done 385
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.
Fresh Meat! (Score:2, Interesting)
If you desire a secure system, do not place a large, immature body of code in the line of fire on the internet.
I don't understand the fuss. (Score:5, Interesting)
Re:Compound Keys (Score:2, Interesting)
Sites Moved to Rails? (Score:5, Interesting)
Re:I don't understand the fuss. (Score:4, Interesting)
Uhm no I don't. I've programmed in Perl far longer than I've programmed in Ruby. I only started with Ruby about 2 years ago. I have experience with mod_perl and stuff like Template Toolkit. I have experience with Python. And Ruby on Rails *still* beats everything else I've used.
It isn't just Ruby, it's also Rails. It's the entire package. Rails is not just any framework, it's an entire design philosophy. It's opinionated software. It's Don't-Repeat-Yourself. It's REST. It's convention-over-configuration. All this stuff together makes me much, much more productive. Ruby on Rails actually makes web application programming more fun than desktop application programming.
Re:ORM still broken? (Score:5, Interesting)
Re:I don't understand the fuss. (Score:5, Interesting)
Re:ORM still broken? (Score:3, Interesting)
Here's the simple, easy-to-comprehend reason why surrogate keys should not be used universally: Your logical model should exactly correspond to the client's conceptual model.
If the client says that "orders have order items, numbered 1,2,3,4..." then your model should have (ORDER#, LINE#) as the compound key for order items. If the client says "customers are identified by an arbitrary customer number", then it's okay to use an artificial ID. If the client says "customers are identified by SSNs" then that's your key.
Pretty simple concept, but completely lost on programmers who think the database is the "backing store" for their code (which will likely be replaced or rewritten in few year anyway, especially stuff like PHP, Ruby, etc). No, the database is the foundation of the business. It should be properly designed.
BUT, it's true, today's SQL databases are pathetic. They don't make this stuff easy. The don't let you create a data type that automatically renumbers the "LINE#" field if entries are deleted or removed. They don't let you create fully updateable views, making it trivial to create alternative key structures on top of your properly designed base tables. They make it hard to refactor and transition schema (views are like methods in OO code.. they let you encapsulate). They make joins expensive. So yes, there's a tradeoff and usually I give up and use surrogate keys most of the time (not ALL of the time though.. depends).
It's not WRONG to be faithful to the conceptual model 100%. It's a limitation of TODAY'S tools. But the programmers continue to spew their nonsense, the database vendors put out products optimized for programmers... it's a vicious circle.
Also, I don't know why you're bringing normalization into this discussion. I suspect your knowledge of "ivory-tower " database theory is limited, thus you incorrectly label all ad-hoc design rules as "normalization". (What exactly do you use to when working with databases, if you don't like theory?) Normalization has to do with key dependencies, not the structure of the keys, and is not required by the relational model because it is a *design* concept.
But since you bring it up, denormalization ALWAYS results in either a loss of data integrity, or a loss of performance. If you denormalize without maintaining integrity (the usual way), then you've fundamentally changed your model (what's allowed in the DB is different now). You better BE DAMN SURE you need it, and you better DOCUMENT IT out the ass. If you denormalize, but add constraints to maintain integrity, then you've killed performance for no reason (however this is useful when transition from denormalized designs back to normalized designs).
Science (Score:3, Interesting)
Re:ORM still broken? (Score:5, Interesting)
Re:I guess they didn't fix the scalability issues (Score:3, Interesting)
At this point...JAF (Score:2, Interesting)
Re:Scaling matters if you're Digg. Are you Digg? (Score:5, Interesting)
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
Re:I guess they didn't fix the scalability issues (Score:2, Interesting)
I think you hit the nail on its head. Django fricken rocks, in my experience, in both speed and usability.
It just doesn't have the hype engine going for it the way RoR does. It's for this reason that I'm hoping the Perl on Rails thing that the BBC wrote gets some momentum - the MCV/MTV approach is a Good Thing, for web-based development. It's not a change in language, so much as a change in how it's laid out. One must note that CGI::Application (found here [cpan.org]) has existed for Perl for quite some time, and yet very few people (even Perl programmers) know about it, in comparison to RoR.
I do have to note that, having had experience with both Perl and Python, Ruby isn't bad at all. It's different in some ways, yeah, but so is Java, or C++, or C#. It's more a matter of taste, for a developer.
And scalability. (:
Re:ORM still broken? (Score:3, Interesting)
"A tad much"? Either you're being facetious, or you have a profound misunderstanding of normalization.
In many cases, a relation in 3NF is in 5NF. In fact, you have to be somewhat creative to think of a practical example of something in 3NF but not in 5NF.
"Normalization" is highly misunderstood. There is no such thing as "extreme normalization". If you see an example of something in 2NF, and then see a 3NF design side by side, you would probably think to yourself "yeah, the 3NF design looks better to me".
It is a pity ... (Score:3, Interesting)
Comment removed (Score:5, Interesting)
Re:ORM still broken? (Score:3, Interesting)
I don't know what you've been reading, but that was my point all along!
And there is nothing wrong with that. Most of the web apps that I make are CRUD-like. I'd still rather choose RoR for its productivity boost over your theoretically-better-and-can-be-used-for-everything-but-totally-pain-in-the-pass-to-work-with $FAVORITE_FRAMEWORK.
Re:Why the hate? (Score:2, Interesting)
RoR is so over hyped by the zealots that use it and make mythical, false claims. Have you ever noticed how they spit back quotes straight from the site or books or whatnot? If I had mormons and jehovah's knocking on my door daily, I'd be pissed off at them too.
Why the backlash? False promises lead to adoption and shift job markets. Hype convinces the non technical to make technical choices. Don't any of you remember all the Java hype of yesterday?
Unfortunately it's not so easy to just ignore and go about your life programming in your language of choice. If you're a perl coder, python coder, php coder, etc and you web develop, then RoR is your enemy. Maybe python should be getting all the attention and hype and the majority of php coders should be moving up not down. Then we'd have better scaling systems anyway. Is python/django so much harder to user than RoR? I'm not convinced that it is. I know for a FACT that it's damn faster.
Re:I guess they didn't fix the scalability issues (Score:4, Interesting)
Enter django. Wow, all the power, none of the "Hansson said this is how it should be, so no other way is possible" handcuffs.
To me django is a much better designed framework, it has in my opinion a much more powerful database abstraction layer, it is more intuitive too. working in Rails for > 4 months I still had to look up the syntax for doing activerecord queries every single time. django's query syntax just makes sense to me, and is much more intuitive. And what can I say, I've never enjoyed making HTML forms more than using the newforms library that builds them for you (oh yeah, and validates them for you, and marshals form input into objects automatically...).
Also, the simplicity of setting up a production django server is so much easier than RoR. Sure, once you start having lots of traffic, building a fully scalable system is probably going to be similar. But to set up a single server for a low traffic site, or a small company intranet, apache+mod_python is great. mod_ruby has huge performance issues, ror+fastcgi in apache is atrocious, mongrel can be ok.. but then you still have to set up apache in front of it, and its not a simple apache set up as you have to configure all the proxy stuff...
Besides the fact that python is ~10 times faster than ruby (just at the interpreter level) and you've got yourself a nice little powerful system with django.
Maybe once django hits version 1.0 they'll get a bit more hype, but I've actually seen more posts on this story saying "check out django" than I've seen people saying they absolutely love rails.
Re:You don't have to use ActiveRecord (Score:1, Interesting)
The only "cool features" is the ability to drop in other stuff you need, and its fantastic dispatcher.
Oh, and built-in server. And easy test harnesses. And support for fastcgi and mod_perl.
I guess it does have cool features, but trying to replace PHP isn't one of them.