Hey, this is something every ruby guy should know. If you're a contract worker you'll walk into a project sometimes and you'll find a management team that wants something more effective, and a staff that's stuck on what they know, just because they already know it. While people have a valid point that learning something new is hard, Ruby on Rails provides so many benefits to the development of a project that the learning curve is an acceptable loss of time. These are the things that stopped my dead in my tracks about ruby on rails development.

1. MVC - If you're a PHP guy sitting there going "What does 'MVC' mean?" i don't blame you. The fact of the matter is, PHP is a fucking mess. Even highly touted web frameworks in PHP aren't really MVC based. MVC means Model-view-controller - and really it's the best way to construct a web application and keep the views separated from the logic code. Models in Ruby on Rails typically represent tables in the database, and lets you extend special properties to the objects if you want, while controllers use these model objects and organize them to put into the Views, which are the templetes.
   
   
2. ActiveRecord - if you know a PHP guy and you want to convert them into a rails evangelist - show them ActiveRecord!! Since ruby is so object-based, ActiveRecord objects are directly related to the tables in the database. This means that you can completely avoid writing sql. Now, if you're sitting there thinking "But I already know how to write SQL, why would I do that?" The answer is simple. What if you develop a site using MySQL and find out that your client's host is on Postgre? Well, in PHP you're fucked, and in ruby you have to change like one word, and everything works. Also, consider your site gets really popular and you find you'd like to switch to a different database for scalability reasons. Once again, on PHP you're fucked, and in Rails it's done for you. The real power here is being able to treat your DB tables like real objects. This means that if you have a table with geographic locations in latitude and longitude, you can easily extend that table's class with a 'country' method which returns what country the lat/longitute are in, and calling it is as simple as
   
   

   GeoCodes.find(id).country

   
   Which will find the object with the proper ID in the database and return the result of the find_country method. The php equivalent to this is MUCH more messy. Also, everything about the DB layer is handled by rails. This means that really complicated things are handled for you. What if you have two tables that are related? The type of tables you would do an INNER JOIN on in sql. In rails, if you've got one object and it's related to more objects in another table, getting to these other objects is as simple as a method call. Lets say that you have a people table in your DB and each person has many cakes, which are referenced from the cakes table. So, you need to get the person object:
   
   

   person = Person.find id

   
   Easy, right? Now you want to get their cakes:
   
   

   person.cakes

   
   Wow! ONE word?? Yes indeed. Now lets say you only want the cakes from this person with chocolate on them:
   
   

   person.cakes.select{|cake| cake.icing == "chocolate"}

   
   How about only chocolate cakes with less than 4 candles?
   
   

   person.cakes.select{|c| c.icing == "chololate" and c.candles < 4}

   
   ...I believe I've made my point. In php (to say the least) ll this kind of stuff is painful and shitty to write, either because you're writing it in pure SQL and using PHP string operations to modify that sql, OR because you're doing it all on the PHP side with loops. Either way, it's messy and it's not as clean as this.
   
   
3. Complete Ajax Integration - Haven't you ever wished you could write client-side JS code from the server side, so you could consolidate all your logic code into one place? Well, I've often wished this using PHP, and what it comes down to is that you have to include JS into your templates and then carefully try to use the server output and the templates together to make some hoppin' AJAX goodies. You can also output ajax from php using strings and string manipulation techniques. Hooray.. In Rails, all of this is fully integrated. For example. You want to make an ajax call in rails that updates an element (let's say a news ticker) with a new random entry:
   
   

   def update_ticker
    news_array = NewsItems.find :all
    rand_news = news_array[rand(news_array.length) ]
    render :update do |page|
     page['id_update'].replace_html rand_news.body
    end
   end
    

   
   which will actually output the necessary cross-browser compatible javascript code to replace the html in the div with id="id_update" with the body of the new random news item. All this without ever actually writing javascript. Pretty cool huh?
   
   
4. Convention over Configuration - This is important. Rails always assumes that whatever you're doing, you're trying to do it in the most common way that it's usually done. This means that it will assume that you're doing it in that common way, but if you'd like to change something about that (i.e. configuration) then you're free to do so. In PHP this is *not* the case. In php you're generally forced to point out every stupid detail of something before you use it, even if you're using it in the most common way it could be used. Examples? Lets say you have an action in your controller named hello_world. Rails will automatically look for your template for this action in views/controller_name/hello_world.rhtml, meaning that you don't have to write ANY code for it to understand that this is where that template is located, and try to use it when someone navigates to "yoursite.com/controller_name/hello_world". However if you'd like to use a different template for your action you could always call
   
   

   render "controller_name/different_template"

   
   ...or what if you want to render the hello_world template, but you want to render it in a different page layout than your site's default layout? No problem:
   
   

   render "controller_name/hello_world", :layout=>"different_layout"

   
   Basically everything in rails acts like this: by default everything just works in the most common way possible, and if you'd like to add to it, you're free to. In php, nothing works until you make it work.
   
   
5. Plugins - Since rails is so well structured it's a very friendly framework to write plugins for. Say you've got users, and your users need to upload image attachments. Well, in php you have to write the image uploader, then you have to write the code that takes it from the tmp folder and stores it somewhere userful, and renames it, and checks that it's the right filetype, etc. In other words, in PHP there's 1,000,000 things you have to be aware of and configure so that your users can upload images. In Rails it's as simple as
   
   

   script/plugin install http://svn.techno-weenie.net/projects/plugins/attachment_fu/
   

   
   After which you just specify that Users have attachments associated with them by putting this in the User.rb class:
   
   

     has_attachment :content_type => :image, 
                    :storage => :file_system, 
                    :max_size => 500.kilobytes,
                    :resize_to => '320x200>',
                    :thumbnails => { :thumb => '100x100>' }
   

   
   WOAH! look at that! We just killed like 200 birds with one big line! You specify the max size (note also how sexy '.kilobytes' is), and even what size to resize the image to (and built-in thumbnail support!), just right there! If this could be easier, I'm not sure how. All of your image upload needs are basically taken care of for you by a 3rd party plugin for the framework, and it's fully customizable. You could attribute associated image information with any of your existing models (DB tables) in your app, in just about one line.
   

Alright.. So there are really a WHOLE lot more items i could go off about, like blocks and passing blocks, gems and the incredible power they provide, database migrations, or the built-in testing framework, or the power of clean and easy URLs with routes.rb, but I think the really core differences are the ones up there. Anyway, have a nice day! If you know any die-hard PHP people, feel free to make the web coding world a better place for everyone and show them this list!!