Hi, I've just been browsing to learn more about php frameworks and my interest sidetracked to ruby and since i already heard so much good of it and it's framework ruby on rails.
But is this a good time to go for ruby? Because i see only two threads in the ruby section and i heard not many hosts support ruby.
If you are using it; what are your experiences? And what would you say are the cons and pros of switching from php to ruby?
You posted to the Perl forum. This thread should be moved to the Ruby forum but maybe you posted here b/c you said there are only 2 threads on the Ruby forum (though why not the PHP forum?). Ruby is a nice language and Rails is a decent framework. Here are some thoughts: The current Hotness: Ruby and Rails are currently very popular. For that reason, you may want to check them out to form an opinion as with any other currently hot technology. If you become decent at Rails you can also get decent jobs because Rails developers are in demand. PHP frameworks vs Ruby frameworks: The main thing about Rails is that it is a MVC framework (http://en.wikipedia.org/wiki/Model-view-controller) that includes an ORM (Object-Relational Mapper) (though DHH claims ActiveRecord is NOT a mapper), a templating system (ERb) and AJAX helpers (so you don't have to write JS to get AJAX). If you know and like PHP, you can check out PHP frameworks that do the same thing, including CakePHP (http://www.cakephp.org/) and Symfony (http://www.symfony-project.com/). Hosting: Rails is harder to support on shared hosting but it is supported. You can get a Rails set up on DreamHost (http://www.dreamhost.com/) or TextDrive (http://www.textdrive.com/). People I've talked to have said you really want a VPS if you're going to do a decent amount of Rails work and not shared hosting but I don't have experience with that. Convention over Configuration: Rails achieves some of it's development speed and acclaim by having one way of doing things. This means that if you want to build a website that is very similar to other Rails websites, it will be very easy. However, if you want to build a site that's different, you have your work cut out for you.I think MVC is great and Rails is pretty good. MVC with PHP would be great for PHP apps IMO. A few things that bother me about Rails:
ActiveRecord: does not have native support for composite (multi-value) primary keys (http://www.dev411.com/blog/2006/06/04/activerecord-achilles-heel-of-ruby-on-rails) but there's a third-party solution. I've also heard character-based primary keys have been a problem but people have added third-party solutions to create support for GUIDs. Also, ActiveRecord will create foreign key type relationships but not create the relationship in the underlying database so you have to do that manually (people have created scripts to do this). I'd prefer these things to be built right into ActiveRecord and not remain external add-ons. Other ORMs, like the Perl-based DBIx::Class, do have support for these built-in so I think ActiveRecord should as well. DBIx::Class is used with the Perl Catalyst framework (http://www.catalystframework.org). Liberal Mixins: While Rails is an OO framework, it makes liberal use of mixins to make many methods available in the "global" namespace (which may be more comfortable for people coming from PHP). I've found that when you move on to someone else's already established project, this can make finding where the actual methods reside pretty difficult. I have to resort to grepping all the files to see where it lives. This is less of a problem if you are only working on your own apps where you know where you've put the methods but I think it can become a maintenance problem, or at least annoyance, for very large apps.I think Ruby and Rails are worth checking because they are very popular now so you can form your own opinion. If you already know OO PHP, it should be pretty easy to pick up the basics of Ruby and Rails. Personally, I think Rails has a sweetspot for the types of web apps that fit it's assumptions and is a good place to get framework ideas, however, I find it a bit too confining for the large scale apps I like to work on.
My $.02. Forgive the stream-of-consciousness nature.
I like Rails a lot. The biggest things that bug me about it are:
1) The community doesn't take the database seriously, and treat it like a glorified flat-file storage engine. I blame the fact that most Rails folks seem enamored with all the crappiness that is MySQL, and emulate stuff in code that Postgres has done for almost a decade. Fortunately you can ignore this idiocy and use Postgres (and triggers, functions, views, foreign keys, constraints, etc.) to your hearts content, even in the new and very cool "migrations" stuff.
2) gems != CPAN. Not even close. :(
3) ActiveRecord doesn't prepare statements. It just throws together strings of SQL and executes them. It does make surprisingly good SQL, though.
4) There seems to be a dearth of strong engineers in the Rails community, probably because it's young in all senses of the word. There are MANY fanbois to be ignored.
5) The scaffolding suxors. Hugely. But the generators are quite cool.
But I really dig it - the benefits far outweigh the drawbacks, in my mind. It makes many best practices easy to just do right: testing, caching, different needs at different stages of development, logical separation of code, logic and presentation, and ruby is a quick learn with good documentation.
You can use composite primary key models in Rails in some cases - "linker" tables for has_and_belongs_to_many relationships are one example. But generally - yes, tables should have a single primary key. You can still throw in column-spanning unique keys at the database level to enforce integrity.
I'm at the end stages of a pretty complicated Rails project I started early September, and I've not found that I've been fighting with it too much. I'd say that the "sweet spot" is larger than one might think at first.
And a good database schema is a good database schema no matter what language you're using to manipulate it. Centralize your logic/checks/triggers in your database like you should and you can easily use Perl to do stuff Rails lacks. The assumptions you need to make modeling your data with Rails apps aren't THAT limiting.
I really dig the apache 2.2/mongrel backend deployment- lightweight apache servers host static files and proxy back dynamic content to mongrel servers. And these mongrel servers can run as any user, so you've got an easy way to separate virtual hosts by user accounts WITHOUT suexec. Very nice. If/when Rails gets threadsafe, it'll be even cooler.
If only Rails had been built by developers with a solid Postgres background. . .
Learn Rails. You won't regret it. It's not a cureall, but it's an excellent tool in your toolbox.
I'd say that the "sweet spot" is larger than one might think at first.For my purposes, I'd like a framework to be able to scale to an Alexa top 100 site, after all you never know if your hobby site will become the next Digg. ActiveRecord's not using prepared statements would put it outside the sweet spot I want for scalability. When considering sites of that scale, you probably also don't want to design your db schema around limitations of the ORM. Of course not all sites need that scalability but nice to not be limited.
37 Signals, the corporate backer of Rails, has an interesting blog post called Growing In vs. Growing Out (http://www.37signals.com/svn/archives2/growing_in_vs_growing_out.php) where they say they prefer their Basecamp customers to grow out of their products and move on to other solutions as opposed to adding features for their more sophisiticated customers and thus making their products more complicated. I've been wondering if this philosophy also applies to Rails and ActiveRecord.
Rails is a nice framework but I'm not convinced that the sweet spot is as large as I want. I do agree it's a good tool to have in the toolbox and as always, use the right tool for the job.
Thread moved to ruby forum (I know the orig. poster posted two threads), because this thread really has some top notch pertinent info.
For my purposes, I'd like a framework to be able to scale to an Alexa top 100 site, after all you never know if your hobby site will become the next Digg. ActiveRecord's not using prepared statements would put it outside the sweet spot I want for scalability. When considering sites of that scale, you probably also don't want to design your db schema around limitations of the ORM. Of course not all sites need that scalability but nice to not be limited.
37 Signals, the corporate backer of Rails, has an interesting blog post called Growing In vs. Growing Out (http://www.37signals.com/svn/archives2/growing_in_vs_growing_out.php) where they say they prefer their Basecamp customers to grow out of their products and move on to other solutions as opposed to adding features for their more sophisiticated customers and thus making their products more complicated. I've been wondering if this philosophy also applies to Rails and ActiveRecord.
Rails has an architecture that can scale quite nicely, given that you can front it with apache boxes and sessioning can be done in the DB. I can't see that scaling a rails app would be all that different than scaling any other app. Given clever sysadmins, it should be easy to throw more iron at the problem. I'm really not worried about it scaling to whatever I need it for.
The 37 Signals post is about growing out of the feature set provided by a third-party web app, not the framework. I don't think you can extrapolate "We'll only let Rails get *this* good, and no better" from that posting. They want to build Basecamp around a core of features. Makes sense to me. Besides, 37 signals isn't the only set of interests here - Rails is OSS.
On prepared statements - it's being worked on, like many other things.
Is rails perfect? No. It's young. But it's maturing quickly.
Is it productive? Yes. Can it scale? Yes. Is it intuitive? More than I thought it would be. Is it "well designed?" Mostly, besides the application-level data integrity checks/triggers forced by MySQL's idiocy.
Can it [Rails] scale? Yes.I haven't seen evidence of this but I'd be more willing to give it the benefit of doubt if I didn't hear so many problems concerning ActiveRecord. On very large scale sites, database schema becomes very important and designing the schema around AR isn't very attractive. As I mentioned you need to use third-party add-ons to get many features that come built in with other ORMs. My schemas have composite, character-based PKs. My impression of AR is I'd need one hack to do character-based PKs and another hack to do composite PKs. Am I mistaken or is this no longer the case? As for using column-spanning unique keys, on large scale databases, I don't want extra keys that don't need to be there.
I'd say scaling is an unknown. I've been looking at presentations for MySQL Alexa top 100 sites (http://www.dev411.com/blog/2006/10/05/mysql-deployment-presentations) and wondering if they can be done with AR. LJ runs a multi-master MySQL setup with composite PKs. Mixi runs 100+ MySQL servers. I don't feel comfortable with potential artificial schema limitations in scenarios like those but maybe there's nothing to worry about? When you say Rails can scale, are you saying AR is known to work in these scenarios? I'm actually not even sure PostgreSQL is a good alternative for Alexa 100 sites as I haven't run across one that runs on Pg yet. As an aside, do you know of any? I've also used Oracle to build sites when scalability and Oracle features were needed but ActiveRecord's not handling of prepared statements, more than just being an inconvenience, seems to make using Oracle a non-starter (http://uncommentedbytes.blogspot.com/2006/07/major-enterprise-ruby-on-rails-issues.html).
I don't think you can extrapolate "We'll only let Rails get *this* good, and no better" from that posting.What if we add some more references? How about these about AR directly from DHH:
AR is not a Data Mapper, so you have to be within a reasonable vicinity of its assumptions to enjoy it. (reference (http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/140320))
No, you don't get the full offer of opportunities that straight OO with a data mapper holds. I'd like to think, though, that Active Record gives you 80% of the features for 20% of the effort. (reference (http://www.loudthinking.com/arc/000209.html))Although it's convenient to think of AR as an ORM/Mapper and the Rails site even calls it that, DHH is quite specific in saying AR is not a mapper. DHH's view seems to be AR is designed to be optimized in a certain way for certain types of apps. If you use his 80%/20% analogy, once you start needing features in that 20% that AR is not designed to handle, you've grown out of it. It's probably for highly scalable sites where you can't bend the schema to AR where you'll run into problems.
I agree that Rails is still very young and features are being worked on. I also think Rails is a huge improvement over traditional ways web apps are created. However, I really want AR to handle the things I've dicussed natively. I'd prefer AR to handle any schema I can come up with. It seems that our main difference of opinion is that I'd like to wait a little longer. I'm also more skeptical of AR's ability to scale but you don't seem to have any doubts.