Ruby On Rails 1.2 Released 97
Scooter[AMMO] writes "David Heinemeier Hansson sent a post to the Rails 1.2. This new version adds a slew of buff and polish to the rest of the system, as well several new features like RESTful interfaces, response formats, improved multi-byte support, and more. If you haven't checked out the web application framework that aims to renew joy within its users, give it a look. You may be amazed at how easy it makes things without sacrificing power or functionality."
No Mongrel (Score:4, Insightful)
Until we get a quick and easy way of deploying Rails apps -- especially at the shared hosting level for ISPs (along the lines of PHP hosting, which is now standard), Rails will continue to have a difficult time finding a niche. The only place where Rails really belongs right now, and the only place where I'm using it (and loving it) is the corporate intranet, where putting up dedicated mongrel servers for internal web-based apps is not an issue.
Re:Improved multi-byte support? (Score:2, Insightful)
This alone is a bad engineering practice, but there's also the possibility that the two multibyte systems are incompatible. What if one uses UTF-8 and the other UCS-2? Or UTF-32? All of those are multi-byte. All of them are Unicode. None of them use the same encoding.
Since Rails is commonly used with a database backend, any incompatibilies will cause major upgrade headaches in the future.
This is the sort of thing that gives developers a bad name.
Re:Improved multi-byte support? (Score:3, Insightful)
Let me guess - you're one of those that would have waited for jet powered air travel to be invented instead of taking the luxurious ocean liner?
Developers need to choose the tools they feel will best help them get the job done in the time allotted and in their estimation will also allow them an upgrade path at an acceptable level of pain as things (inevitably) change.
Re:Frameworks are for sissies... (Score:3, Insightful)
With the rails framework, you also get(besides MVC and AR): Built in data validation, error reporting from the validation(model) immediately available to the view, session flash (temporary message carried through to next page view), the new RESTful approach (try it!), different responses based on request type, all sorts of view helpers, easy to integrate ajax.... man I just can't list it all.
Re:Heaven help! (Score:3, Insightful)
'€2.99'.first # => '€'
truncate('2.99', 2) # => '€2'
Even tho this isn't totally like Java's i18n support, it's getting there..
As for Ajax support, yah, it's a first class citizen in Rails. While a lot of people are sick of the term, I think it's for real and here to stay. It is the next step in web applications. While most of the examples in the world so far have been for 'social' .com apps, the fact that Ajax is now allowing (or putting a face on things that already existed but not termed in a way the masses could digest) for rich net apps that regular web pages couldn't deliver. Coupled with the various tool kits like Yahoo UI or GWT, the net and browser really are becoming the operating system. And Rails was the first framework who really made the whole Ajax thing easy to use. They're going to be ahead of everyone else in this category for some time.
Anyway, I'm very excited about 1.2. :)
Re:I never quite understood the benefit of Rails (Score:4, Insightful)
This is true, but it's understandable also. Rails uses databases as persistent object storage, and nothing more.
The benefits of relational databases are that they can enforce constraints with simple declarations, and abstract the logical from the physical storage. You can try to do some basic checking before you put something into a database, but it's very hard to do constraints on the application side.
I understand why developers at smaller companies don't like using relational databases as relational databases. For a long time relational databases weren't really meeting the needs of smaller shops, and they have their own learning curve. But now with good databases like PostgreSQL that have proper constraints and can do powerful relational manipulations, it's a great time to get involved in relational databases. I encourage you to try them out, they can be a godsend when it comes to application development speed.
It's a wonderful thing when you get an error from your database, and you know exactly which part of the application tried to do something wrong. The alternative is waiting until the bad data gets in, and finding out a week later when you try to do a report (try to find the bug now that you have no idea how the data got that way).
Re:Heaven help! (Score:3, Insightful)
I agree with you in general that AJAX is only going to become more common, and done right, AJAX has many benefits. However, stop saying things like this:
Because it's akin to suggesting that we replace the engine of a car with a GPS receiver or an iPod.
Re:I never quite understood the benefit of Rails (Score:3, Insightful)
Please cite some examples. A lot of Rails' technical sacrifices are in the name of speed of development and maintainable code. Obviously I haven't used all web frameworks, so I don't know. Maybe you're right. But I'm suspicious you're just pulling that out of your ass.
Yes, Ruby is slow, has fewer libraries, and no unicode support. However these issues don't really speak to Rails itself. Yes, they may showstoppers in some instances, but Ruby was chosen for other reasons which greatly affect the usability and development performance of the framework. Yeah, you could do most of the same in Python or SmallTalk, but certainly not in most popular languages.
The opinionatedness of Rails is what makes it so powerful. There is plenty of support for dealing with legacy schemas. Of course Rails encourages database constraints in the application code, which is distasteful to some, and definitely precludes the use of outside applications directly writing to the database safely. However, if you have the means to use Rails conventions then you get an awful lot for free, and I don't really see how you can have it both ways (ie. faster to develop, more maintainable, and more flexible) unless of course the Rails architecture is just garbage and it can easily be replaced by a more powerful architecture which is better in all ways.
See Rails is more focused on the complexity side and maintainability side. Sure there's a computational cost there. For one thing you're on Ruby which is fairly slow to begin with, then you provide all the request hooks to keep the application organized, finally you add a basic ORM layer that is great for 95% of queries, but is maybe a bit naive. However if you need to optimize those things, by all means write your own queries and do your fragment caching. At some point, yes, you should be looking at other languages and frameworks.
However, Rails does what it does very well, and what it does is a huge market niche. Anyone using Rails should be aware of its philosophy and shortcomings, but it's not poorly designed from a technical standpoint. Maybe its design goals don't go over well with you (it pretty much pisses all over the idea of database-level data integrity, which is a pretty controversial idea at best), but don't mistake that for poor technology.
Re:I never quite understood the benefit of Rails (Score:3, Insightful)
That's an ActiveRecord thing.. use a different ORM (Og looks quite nice), or no ORM; convention isn't a gun to your head, and it's not really a lot of effort to keep most of the benefits without actually using AR (my last Rails app used descript.ion files, heh). It's also not been true for a long, long time; each model can have it's own seperate connection, a feature added for ActiveRecord 1.0 (it's at 1.15.1 right now; 1.0 is 90% of the way down the changelog, sometime in 2004).
"Rails (or rather ActiveRecord) has all the same problems that all ORMs do. The first of which is optimizing for ease of development, not memory footprint."
Er, right. Can't say I've noticed ActiveRecord's memory footprint being much of a problem; if I'm loading huge result sets, it's generally enough of a problem that I just use a cursor, no matter what library I'm getting them via -- removing the few additional objects AR throws in doesn't really make much of a dent. Besides, developers generally cost more than memory.
"A second problem is the "more information than I asked for" problem. SELECT * should be used sparingly in favor of just grabbing the information that you need. ORMs have no idea of what information you want, so they just grab everything."
Bla.find(:all,
Re:Improved multi-byte support? (Score:3, Insightful)
What if one uses UTF-8 and the other UCS-2? Or UTF-32? All of those are multi-byte.
No, they're not. UCS-2 and UTF-32 are fixed width encodings, not multi-byte. And if UTF-8 is not eventually supported natively by Ruby, then the Rails implementation will still be needed. The rest of the internet is not going to drop UTF-8 just because Ruby does not support it.