Slashdot Mirror
Ruby On Rails 1.2 Released
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."
I code web apps in rails for work. I come home and play in Django. There is my renewed joy...
If you'd RTFA instead of rushing to get first post, you would have seen this:
It's too bad Rails 1.2 wasn't released with mongrel (a very nice app server designed to run Rails apps, among other things). Currently deploying a production-ready server capable of running Rails is a uncomfortably unrails-like experience. Mongrel makes things a bit nicer, but even with that running under virtual hosts and/or with SSL requires some seriously heavy lifting (think Mongrel running behind Apache acting as a reverse proxy).
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.
For all guys currently using engines, you might want a look at this:
a re-dead-long-live-engines/
http://rails-engines.org/news/2007/01/03/engines-
http://jesusphreak.infogami.com/blog/why_django
It's getting installed at a furious rate... we're doing around a gem a second now.
The Army reading list
> All it seems to do is offer a way to do very similar
> and simplistic web apps without any real-world functionality.
You may want to look closer; it offers ways to do very complex web apps with lots of real-world functionality.
> I also wonder about the performance and memory profile; seems
> that the way it handles databases is exactly what DBA's hate to see.
In practice, ActiveRecord works out very well.
> none of the websites it can create is worthwhile.
To the contrary, the websites a programmer can create with Rails are very worthwhile.
The Army reading list
I really didn't understand either before I decided to invest some time and try tutorials. :), Basic, C++, Fortran, Caml, Java, Ruby ...) and I now have the impression that I never really understood programming before having known rails.
It's already been 15 years I've been programming (Logo
So please, try it at least 2 hours, and you'll be amazed by how fun, efficient and beautiful it is.
Everytime I heard someone talking about REST, migrations, rake, capistrano, scaffolding, ActiveRecord, AJAX, routes & nice URL's, I just thought "Whatever! Those are just buzz/hype words without any meaning, and it won't change my programming life".
But it sure did, and I think noone can ever understand it before giving it a fair chance.
Thanks a lot DHH and keep up the good work!
PS: You might want to check http://backpackit.com/ if you look for a "real-world functionality".
While it is very simple to build applications via scaffold (automatic screens base on database schema), it is only *one* feature in Rails. Try it for a week. *Then* you'll see the real power of Rails. Sustainable development speed*, a very nice language (Ruby), nice documentation (it could be better, but it is ok) and so on. seems that the way it handles databases is exactly what DBA's hate to see DBA's may hate the way Rails uses databases. The framework isn't focused on "computer ease of computing", but on "developer ease of developing". So, it may not fit for a huge company, w/ hundreds of offshore developers, SA's and DBA's. It is specially useful for small companies/teams, where speed of innovation is their key to get into the market. Example: to start building Rails applications, one just needs to download the ruby interpreter (port install ruby), rubygems (port install rb-rubygems), install rails (gem install rails), and start the application (rails MyApplication). Try that
So, instead of seeing the presentations, try to put your hands on it w/ rose-colored glasses** . If you don't like it, at least you'll learn new way to do things, which can help you in your next project
* try to keep a sustainable development speed w/ one of the standards in the market: struts/spring + hibernate. It is almost impossible to achieve.
** sorry, I'm not a native english speaker... I hope it was used in the right context
ilex paraguariensis for all
Now that we've just calmed down the Rails bunch they'll be all over us again with foam aroung their mouths. "RAILS! RUBY! RAAAAH!". ...
Here's a list of very good/better alternatives:
Zope - What Rails want's to be when it grows up. Ancient but still ahead of anything else with classic persistance. (www.zope.org)
django - Drinking buddies of the rails people. And they have unicode support. (www.djangoproject.com)
cakephp - YaWebframework. In PHP. Largest community out there. Impressive piece of code (www.cakephp.org). Some De-Normalisation and Relational Trails built in. Very neat.
symfony - PHP 5 Framework. Very good. (www.symfony-project.com)
The biggest suprise for me was reading right here that Rails, as of version 1.2, doesn't have unicode support - and apparently never had. Now that's showstopper imo.
We suffer more in our imagination than in reality. - Seneca
Thanks for the vote of confidence. You might be surprised to know that we thought about all this before we started working on AR:Multibyte.
AR:Multibyte is currently mostly used internally in Rails to make methods multibyte safe. It will be really easy to phase it out when internal support arrives.
Ruby is getting more multibyte support 'in a year', which means that it's at least going to take a few years for everyone to actually get the new version in their OS.
The last time I used Rails (0.9ish), it wouldn't let you connect to more than one database per application. This is unacceptable in my environment, so I had to throw it out as a prospective tool.
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. Even medium size applications can suffer from this.
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. The more information in your table (i.e. large text fields), the bigger problem that is.
There are other problems as well, but it's 7am here and I need desperately need my morning caffeine fix.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
I'm especially surprised because the creator is Japanese and Ruby apparently has a big following there.
I would have thought that multi-byte languages would have been a big deal from the start.
> I would have thought that multi-byte languages
> would have been a big deal from the start.
Yup, they are. Ruby supports UTF-8, JIS, and various other multi-byte encodings. It just doesn't have support for all the Unicode encodings.
Keep in mind that other languages have to change as Unicode changes as well. For example, Java's char primitive is 16 bits, which for a while was enough to store all the Unicode characters. But with Unicode 3.1, supplementary characters can be 21 bits. That's why Java 1.5 introduced a bunch of new Character methods that accept an int, not a char.
The Army reading list
Django doesn't use SQLObject. You can, as a programmer, use it of course, since everything in Django is nicely decoupled, but Django uses it's own ORM. The main advantage of using this ORM is of course the production ready administration interface that you get for free, but if you don't need that, there is nothing stoping you from using SQLObject or even better, SQLAlchemy. In fact, there is even a branch in Django to have SQLAlchemy support in the framework.
Using a different ORM, template engine, etc in Django is just a import statement away.
The problem is, the Rails team has created a module that, by their own admission, will be obsolete within a year.
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.
Rails provides so much more than just MVC. It *is* built on solid OO design, and the ActiveRecord framework is pretty solid, and would take a lot of time to recreate by hand. Why reinvent the wheel? The point of rails is to free you from having to do that stuff all over again. "Don't Repeat Yourself" is the motto, and I find that to be the biggest reason to use rails. As I have grown in my own programming abilities, I've discovered the greatest frustration is when I repeat code (or worse, copy and paste).
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.
One of the great things with Rails is that it is so easy to update. There's three easy steps: Step 1: gem update rails --include-dependencies Step 2: Press return Step 3: There's no step 3
If I remember correctly, there is a cultural issue here in that Unicode is apparently considered with some disdain in Japan and local multi-byte encodings are used, one of which Ruby supports. If you do some searches, you can probably find the full background story.
All of frameworks I've used allow you to drop down to straight SQL for database work, ignore their models and templating (or substitute others), and completely mess up the MVC pattern, if you want. Django goes the farthest towards restricting your options in the latter respect, but it's still possible.
I know you're somewhat kidding, but I just wanted to note that the reason for a framework is above all to have a starting point. Some frameworks do a much better job at that than others, but that's the purpose. If the only purpose was to restrict, they'd be more annoying than not, and people wouldn't use them by choice at all.
I [may] disapprove of what you say, but I will defend to the death your right to say it.
DBA's may hate the way Rails uses databases.
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).
Social scientists are inspired by theories; scientists are humbled by facts.
There was a good AC post about it in the "Ruby as a Lisp" posting a few days ago:
It basically has to do with the fact that Unicode uses Han Unification to cause Chinese and Japanese ideograms to share codepoints, and Japanese aren't down with that, so they use Shift-JIS. Check the postings that reply to it for a big digression on the issue ;)
Don't blame me, I voted for Baltar.
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.
"The last time I used Rails (0.9ish), it wouldn't let you connect to more than one database per application. This is unacceptable in my environment, so I had to throw it out as a prospective tool."
:select => "title,body") -- :select was added in 1.12.0, about 14 months ago.
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,
Thanks to the Rails developers!
Ruby on Rails is certainly a giant step forward in increasing programmer productivity. The new REST support is great, but I must say that the web based SOAP debugging interface made using SOAP with Rails painless.
A little off topic, but for my customer I integrate Rails with back end Common Lisp code - so far just using home grown REST support at both ends. Eventually, I would like to get the time to generate compiled Lisp libraries directly linked to Ruby when everything is runnng on a single server.
BTW, I created a simply Ruby and Ruby Rails news clipping web site, mostly for my own use, but it might be useful for you: http://rubyplanet.net/
As someone who works at a software company in Japan, I've never seen any resistance to Unicode here or from any of our partners. In fact we use it all the time.
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.