Geekystuffdot net

Which is “better” for developing web apps – Ruby or PHP? I recently saw a question on LinkedIn which inspired me to add my two cents to the discussion…

The key difference in the languages (Ruby vs. PHP) are the level of “object-orientation,” and (obviously) syntax. Ruby was designed from the start (~1993) to be an object-oriented language (EVERYTHING is an object) while PHP was, until recently (v5.0 – 2004), a procedural language (an example would be PHP v4.x’s use of the class name as a method for initialization vs. PHP 5.x’s use of __construct). As a long-time PHP programmer who migrated to Ruby in 2006, I prefer Ruby’s implementation of OO over PHP’s. I also prefer Ruby’s syntax AND coding best-practices over PHP’s.

There are many good Model, View, Controller (MVC) web frameworks for both languages. PHP has CakePHP, Code Igniter, Akelos, Symfony, Zend, etc… Here is an excellent list of web frameworks for PHP: http://www.phpwact.org/php/mvc_frameworks. Ruby’s MVC frameworks include: Rails, Merb, Sinatra, Ramaze, Nitro, etc… Here is an excellent list of Ruby web frameworks: http://accidentaltechnologist.com/ruby/10-alternative-ruby-web-frameworks/.

In my opinion, there are two keys to selecting a web framework. First is the Object Relational Mapper (ORM) – how the data is abstracted, and testing. In my early days writing PHP code, I found myself writing a lot of (repetitive) SQL queries to access data. With an ORM, it is easier because the queries are abstracted out. While this may be “slower” than directly accessing the data with SQL queries, it saves a LOT of programming time. The bonus to using an ORM is one can ALWAYS write a custom query if needed. Testing is also HIGHLY recommended and attractive… before I became a test-aware, I cannot tell you how many times my code would break after I made (what I thought) was a small fix… this can be avoided by testing the public-facing code. Do not commit (version control) or deploy unless all tests pass!

My specific recommendation for a PHP-based web framework would be Symfony (http://www.symfony-project.org/) because it uses Doctrine ORM (http://www.doctrine-project.org/), is packaged to be used as a library (ala PEAR) – meaning one code base can natively support many instances, and has a decent test suite. For a Ruby web framework, I prefer Merb (http://merbivore.com) because it is “lighter” than Rails, is ORM agnostic (you can choose from Datamapper (http://datamapper.org), Sequel (http://sequel.rubyforge.org/), or ActiveRecord (http://ar.rubyonrails.org/)), supports threading (concurrent processing), and natively supports testing (Rspec – http://rspec.info/).

If you are a PHP programmer, I would recommend you start learning Ruby and use Merb as your web framework. While it seems there is a relatively steep learning curve, you will find your development time will dramatically drop in the long-term using Ruby / Merb / Datamapper.

I noticed a lot of people searching for a way to delete all installed ruby gems and finding my Painless Cleanup of Ruby Gems With Similar Names page. I added this page for those of you who want to delete all installed gems instead of just cleaning them up.

Listing all gems is easy: ‘gem list’.

abstract (1.0.0)
actionmailer (2.2.2, 2.1.2, 2.1.1, 2.1.0, 2.0.2, 1.3.6)
actionpack (2.2.2, 2.1.2, 2.1.1, 2.1.0, 2.0.2, 1.13.6)
actionwebservice (1.2.6, 1.2.5, 1.2.3, 1.2.2, 1.2.1, 1.1.6)
activerecord (2.2.2, 2.1.2, 2.1.1, 2.1.0, 2.0.2, 1.15.6)
[...]
will_paginate (2.2.2)
ZenTest (3.11.0)

Now that we have a list, we need to get rid of the version info. We do this with the shell command ‘cut’. ‘cut’ removes sections from each line of files or STDOUT. We remove sections by setting a delimiter ‘-d" "’ and a field ‘-f N’ (N is the section we want to keep). In this case, we want to cut out everything to the right of the gem name. There is a space between the gem name and the version info so we will use the [space] as a delimiter. Field 1 will be everything to the left of the delimiter (our gem name) so we will insert ‘1’ as the field number.

abstract
actionmailer
actionpack
actionwebservice
activerecord
[...]
will_paginate
ZenTest

The command to uninstall all versions of a gem is: ‘gem uninstall -Iax STRING’... so uninstalling all versions of merb-helpers is: ‘gem uninstall -Iax merb-helpers’. That only uninstalls all versions of one gem and we have a list which we want to iterate through to delete all versions of all gems. We do this with the ‘xargs’ command which builds and executes command lines from STDIN or the list we generated with the command ‘gem list merb | cut -d" " -f1’.

You probably noticed there are three flags (I, a, x) in the uninstall command. The flags do the following: -I Ignore dependency requirements while uninstalling, -a Uninstall all matching versions, -x Uninstall applicable executables without confirmation. So the command ‘gem uninstall -Iax’ uninstalls all matching gems and its associated executable without regard to dependencies.

Our ‘xargs’ command to run the uninstall ALL gems is ‘xargs gem uninstall -aIx’. ‘xargs’ iterates through each line of our list and uninstalls each gem. The gem name will be appended (but not visible). Again, we ‘pipe’ or chain the cleanup command to our previous command.

'gem list | cut -d" " -f1 | xargs gem uninstall -aIx' deletes all installed ruby gems!

Successfully uninstalled abstract-1.0.0
Successfully uninstalled actionmailer-1.3.6
Successfully uninstalled actionmailer-2.0.2
[...]
Successfully uninstalled will_paginate-2.2.2
Successfully uninstalled ZenTest-3.11.0

You now have the tools to list all versions of installed gems, remove the version number leaving only the list of gems, and then executing the ‘xargs’ command to delete all installed gems.