Slashdot | Ruby on Rails 1.0 Released
pre>> http://www.rubyist.net/~slagell/ruby/examples.html
http://www.rubyonrails.org/applications
versus http://catalyst.perl.org/
http://www.webwareforpython.org/
http://redhanded.hobix.com/
http://tryruby.hobix.com/
Slashdot | Ruby on Rails 1.0 Released: "AJAX quality is suspect
(Score:4, Interesting)
by brundlefly (189430) Alter Relationship on Wednesday December 14, @12:17AM (#14253944)
It's great that Ruby is 1.0.
But it's unfortunate that the preferred Ruby AJAX design pattern still includes prototype.js, because that library as written is fundamentally dangerous. It's written in a fashion which demonstrates that the author is very adept with JavaScript and functional programming in general; but it also does some unpardonably cute tricks in extending core objects, thereby changing the overall JavaScript environment and making the core AJAX library not play nicely with others. (And if ever there was an environment where you need to have good manners and not piss in the pool, it's the browser JavaScript environment.)
The sad thing is that there's nothing about the functionality of prototype.js which requires all that object and syntax wizardry to function correctly. It could easily be re-written to be perfectly safe. But at this point, the bell has been rung; other libs such as Rico now rely on those same insidious tricks, and 1.0 is out the door.
Sigh. So close, so close."
================
So far, I love Rails, because I have done the following, with these initial costs:
Installed Rails Apps (open source): (sorry, no links to my domain, must avoid /. effect):
How is this different? I only worry about one Terms of Service, imposed by the web host. I control all aspects of the deployment of the Rails apps. So the blog is not just my blog, its a blog at my domain (or sub-domain if I perfer), and I control the databases that store its content. In fact, I control every aspect of the blog. For instance, I could make the blog appear and disappear based upon phases of the moon. Can you do that with any blog host, just by changing two links at a shell prompt?
The same goes for every other Rails app I have deployed on my server account. The Rails principles of "don't repeat yourself" (DRY) and convention over configuration, meant that once I installed one Rails app, the experience was immediately applicable to installing the rest. They all have the same directory structure, and the same configuration file for database connection, which is the only configuration file you must edit.
The rest just works, usually. You have to check your versions, and make sure your app and Rails work at the current version. I admit I have experience building server side web projects using VB6 DLL and ASP.NET, along with equally strong UNIX background, so I was able to tweak a few things and proceed when they didn't work the first time. Don't dispair, I was able to make it work after a few hours of checking on-line forums, and trying some suggestions.
- new domain name, $5/year
- Rails host acct, $12/year
- my time spent, about 6 to 10 hours a week for last 2 months
Installed Rails Apps (open source): (sorry, no links to my domain, must avoid
- blog at my own domain using typo [leetsoft.com]
- agile, extreme programming management tool using eXPlainPMT [explainpmt.com]
- a to do list using Tracks [rousette.org.uk]
- content management system using MuraveyWeb [muravey.net] CMS
How is this different? I only worry about one Terms of Service, imposed by the web host. I control all aspects of the deployment of the Rails apps. So the blog is not just my blog, its a blog at my domain (or sub-domain if I perfer), and I control the databases that store its content. In fact, I control every aspect of the blog. For instance, I could make the blog appear and disappear based upon phases of the moon. Can you do that with any blog host, just by changing two links at a shell prompt?
The same goes for every other Rails app I have deployed on my server account. The Rails principles of "don't repeat yourself" (DRY) and convention over configuration, meant that once I installed one Rails app, the experience was immediately applicable to installing the rest. They all have the same directory structure, and the same configuration file for database connection, which is the only configuration file you must edit.
The rest just works, usually. You have to check your versions, and make sure your app and Rails work at the current version. I admit I have experience building server side web projects using VB6 DLL and ASP.NET, along with equally strong UNIX background, so I was able to tweak a few things and proceed when they didn't work the first time. Don't dispair, I was able to make it work after a few hours of checking on-line forums, and trying some suggestions.
--
Software freedom...I love it!
-------------------------------------
For a window platform, download Instant Rails [rubyforge.org]
Or for linux, install mod_scgi [mems-exchange.org] and follow the instructions here [rubyonrails.com]
It's stinkin' easy, I can do it in about 5 minutes. Any hosting admin worth their salt can even script it in about 10 minutes.
---------------------
Ruby on Rails is to mod_ruby what Fusebox is to Coldfusion.
Coldfusion is a language of itself [albeit a simple one] that runs on top of a J2EE engine called Jrun... /me = coldfusion person (I also know and use ruby a lot, and am working on learning RoR)
------------
You're trying to be funny, but you've got the only comment so far that mentions what I consider to be the most significant thing about Rails - convention over configuration. One reason why Rails development is so fast and often enjoyable is that you don't have to muck about with a lot of XML config files. If you just follow the path of least resistance, things just work out right.
The MVC triad in Rails uses the ActiveRecord class for the model part. ActiveRecord is an ORM (Object Relational Mapping) class that follows a few clever rules about doing the mapping, so most of the time you don't have to repeat your mapping multiple times. If you have a "User" class, it knows to look for a table in the db called "users", and assumes the primary key is an integer named "id". A foreign key to an account record is assumed to be called "account_id". The creation time of a record is assumed to be a datetime named "created_at". All common elements have reasonable defaults, so when you are working on your app, you don't need to spend a lot of time mucking about with config files to specify stuff that is just so fracking obvious that it is a waste of your time to type it.
Rails is not all things to all programmers, but it has certainly hit the sweet spot for a huge class of web applications - database backed interactive sites. The Rails design is good for probably 90% of the sites that I use most.
As for coder jollies, well, it's been a while since I enjoyed programming. With Rails I've regained my enjoyment for programming enough that I'm considering doing that for the main part of my work again.
-----------------------
Software freedom...I love it!
-------------------------------------
Easy installation
(Score:5, Informative)
Or for linux, install mod_scgi [mems-exchange.org] and follow the instructions here [rubyonrails.com]
It's stinkin' easy, I can do it in about 5 minutes. Any hosting admin worth their salt can even script it in about 10 minutes.
---------------------
Re:Commercial equivalent is...?
(Score:5, Informative)Coldfusion is a language of itself [albeit a simple one] that runs on top of a J2EE engine called Jrun...
------------
convention over configuration
(Score:5, Interesting)The MVC triad in Rails uses the ActiveRecord class for the model part. ActiveRecord is an ORM (Object Relational Mapping) class that follows a few clever rules about doing the mapping, so most of the time you don't have to repeat your mapping multiple times. If you have a "User" class, it knows to look for a table in the db called "users", and assumes the primary key is an integer named "id". A foreign key to an account record is assumed to be called "account_id". The creation time of a record is assumed to be a datetime named "created_at". All common elements have reasonable defaults, so when you are working on your app, you don't need to spend a lot of time mucking about with config files to specify stuff that is just so fracking obvious that it is a waste of your time to type it.
Rails is not all things to all programmers, but it has certainly hit the sweet spot for a huge class of web applications - database backed interactive sites. The Rails design is good for probably 90% of the sites that I use most.
As for coder jollies, well, it's been a while since I enjoyed programming. With Rails I've regained my enjoyment for programming enough that I'm considering doing that for the main part of my work again.
-----------------------
posted by USSSlavebation @ 12/18/2005 09:54:00 pm
0 comments
Rails cost/benefit results
(Score:5, Informative)(http://blueskytech.blogspot.com/)