If you haven’t tried Git or GitHub yet, this would be a great excuse. Visit the GitHub Guides for a collection of resources that will help get you started.

Here’s what you’ll need to do to contribute:

1. Create a GitHub account for yourself.
2. Fork our repository by clicking its Fork button.
3. Clone your fork so you can work on it locally.
4. Make changes, commit them locally, then push your changes to GitHub.
5. Send us a Pull Request by clicking that button on your GitHub repository.

That’s all there is to it. Please do not send us pull requests until you’ve checked the changes or additions you’ve made and they are ready to be merged. We’ll periodically review your contributions and update the website.

Finally, if you haven’t picked up the Rails for PHP Developers book yet, it’s available in paper and PDF format. The back of the book includes about 120 pages of additional reference material not found online.

One of the more confusing differences between Ruby and PHP is the different way in which the languages treat empty variables when evaluating statements.

The chart below shows the most common scenarios you may encounter. We have several similar charts in the Rails for PHP Developers book with other handy information.

While PHP evaluates all empty variable as false, Ruby only evaluates nil and false to be false. Some Ruby objects have an empty? method, but this is not always as useful as you might expect. The method is only available on some objects, and calling nil.empty? or false.empty? will result in NoMethodError.

The Rails framework adds a consistent method named blank? that exists on all objects as a single way to check if a variable contains a blank object. Rails has also very recently added a corresponding present? method, which is equivalent of !blank?

Handling Zero

Handling zero values often trips up beginning Ruby programmers. This cause of this confusion is best demonstrated by the following two code snippets.

PHP

$num = 0;
if ($num) {
  // This not evaluated.
}

Ruby

num = 0
if num
  # This is evaluated!
end

Refer to the chart above as you read the snippets. While this may seem counter intuitive coming from PHP, for the most part it’s not a problem.

In Ruby code, we typically know when we’re working with numbers, or we can cast to them. We can then simply do something like these examples:

Ruby

num = User.count
 
if num > 0
  puts "there are some users"
end
 
if num.zero?
  puts "no users here"
end

Similarly, it is important to note that zero (0 and "0") evaluates to true using 0.blank?.

Object Conversion Methods

Methods such as to_s and to_i are very commonly used to translate between different objects.

Kernel Module Conversion Methods

This isn’t the only way to convert object types in Ruby. We can use Kernel module conversion methods as well. These methods include Array, Float, Integer, and String.

The Differences

These methods perform similar actions to the instance conversion methods, but have some subtle differences.

Integer will honor base indicators such as (0, 0x, and 0b), but String#to_i will not. If Integer cannot convert an object it will throw an ArgumentError.

Ruby

"0x12".to_i    # => 0
Integer("0x12")  # => 18
 
"a".to_i       # => 0
Integer("a")   # => ArgumentError: invalid value for Integer: "a"

Float will throw a TypeError if you attempt to convert nil to a float. If it cannot convert an object it will throw an ArgumentError.

Ruby

nil.to_f    # => 0.0
Float(nil)  # => TypeError: can't convert nil into Float
 
"a".to_i     # => 0.0
Float("a")   # => ArgumentError: invalid value for Float(): "a"

String works pretty much the same as the to_s method, and is basically just calling the object’s to_s method.

Array will attempt to call object.to_ary, and then object.to_a. If the object doesn’t respond to either, it will create a single element array with the object.

Tips

The great thing about any Ruby errors we might get while attempting to convert types is that they’re exceptions. This means that we can easily handle them, and set a default value if any conversion doesn’t work as expected.

Ruby

my_var = ["hello"]
my_var.to_i rescue 0
# => 0
 
my_var = "a"
Float(my_var) rescue 0.0
# => 0.0

In this example, we’ve used an inline rescue along with a value that we want to assign when an exception is raised during the conversion.

Here’s a few examples of applying Ruby’s blocks to everyday problems.

Handling Timeouts

Ruby’s Timeout library is used to ensure that a block of code doesn’t execute longer than a certain amount of time. This is a handy feature since the block can wrap many operations which might not otherwise support a configurable timeout.

Ruby

require 'timeout'
 
Timeout::timeout(20) do
  # Potentially long-running code
end

The Timeout::timeout method takes a timeout value in seconds. If the block takes longer to execute than the timeout value, it will be interrupted.

Working with Files

In PHP, file_get_contents() and file_put_contents() provide convenient ways to quickly read and write files. Often, we need to do a bit more. It’s common to open a file, perform some operations on it, and then close the file.

PHP

$f = fopen('/path/to/foo', 'w') ;
fwrite($f, 'foo') ;
fclose($f);

Ruby’s File.open can be used like above but it can also be passed a block.

Ruby

File.open('/path/to/foobar', 'w') do |f|
  f.write 'chars'
end

When the block exits, the file will automatically be closed. This is a best practice for working with files in Rails applications and is noted in the reference page for fopen().

The block version is nice from a maintenance perspective. It’s easy to accidentally remove the call to fclose() and doing so won’t produce an obvious error. However, removing the block’s end will cause a parse error. In PHP, this is not so much of an issue because PHP will close any file handles left open at the end of each request.

Performing Benchmarks

Within the context of the Rails framework, you can call the benchmark method within a controller action. Given this action:

Rails

def show
  @user = User.find(params[:id], :include => [:preferences])
  # ...
end

Just put a block around a piece of code to measure it:

Rails

def show
  benchmark {
    @user = User.find(params[:id], :include => [:preferences])
  }
  # ...
end

The result of the benchmark will be output to the log, such as log/development.rb. There is also a benchmark helper method available in all views that does the same.
The Ruby Standard Library also has a Benchmark library you can use outside of Rails.

Changing the Directory

If you’ve ever written a command line script that had to temporarily change the working directory to perform some operations, it might have looked something like this:

PHP

$here = getcwd();
chdir('/path/to/somewhere/else');
// perform some operations
chdir($here);

You can do the above almost verbatim in Ruby also. However, a better way to temporarily change the directory is to pass a block to Dir.chdir.

Ruby

Dir.chdir('/path/to/somewhere/else') do
  # perform some operations
end

The working directory will be changed before entering the block, and automatically changed back when the block closes. Not only is it cleaner, it makes your scripts easier to maintain since you can’t accidentally remove the returning Dir.chdir.

Deployment, or moving your application to production for use by real customers, is largely an afterthought for these small PHP applications. In many cases, decent PHP code can just be installed on the server and it runs without much trouble.

One of the points we stress towards the back of our book is that deploying Rails applications can be more difficult than deploying their PHP counterparts. There are more moving parts and things to you’ll need to learn. Until you get the hang of it, deploying even small Rails applications can be frustrating.

A recent development has greatly improved this situation.

Introducing Phusion Passenger

PHP can be deployed using a variety of server configurations. Some of these can be just as frustrating as traditional Rails deployments. However, the majority of PHP applications are still deployed on Apache using mod_php. PHP’s tight integration with Apache is simple, proven, and just works for many needs.

Phusion is a small company in the Netherlands that recently released an open source product called Passenger (mod_rails). Passenger aims to take the complexity out of deploying Rails applications by also integrating with Apache.

Installing Passenger on the average Linux or Mac server is usually simple. It is installed as a gem and contains an automated installer program that compiles and installs the necessary components. Once installed, many Rails applications can be deployed under Apache simply by configuring a VirtualHost for each application. The installer even outputs an example for you to copy and paste.

Passenger gives a deployment experience closer to what we’ve come to appreciate with PHP. In the background, there’s still more moving parts, but Passenger automatically manages them. It spawns Rails application server processes, proxies to them, and largely eliminates the configuration and glue that other Rails deployment options leave up to you. Passenger has nice documentation for when some configuration is necessary.

At Maintainable Software, we develop applications in both PHP and Ruby. We’ve been testing Passenger for a few weeks on a dedicated server and recently deployed an application on it. We have been very impressed with its reliability, performance, and easy-of-use compared to previous Rails deployment options. You should give Passenger strong consideration, especially if you’re just starting out.

Finally, Rails on Shared Hosting

Traditionally, deploying Rails applications on shared hosts (usually with FastCGI) has been difficult and unreliable. Due to this, many Rails applications are deployed on small VPS plans from providers like Rimuhosting and Slicehost. These run well, typically using small Mongrel cluster behind a frontend proxy balancer. However, VPS plans are usually more expensive and more work to set up and maintain than shared hosting.

Passenger makes running Rails applications on shared hosting much better. Dreamhost, a major shared hosting provider, recently announced full support for Passenger. We tested a small Rails application on Dreamhost using it and we were impressed. It seemed to run without issues and with reasonable performance.

Deploying some Rails applications on shared hosting may soon become commonplace.

Thinking Ahead

Will better Rails deployment options or Rails on shared hosting mean it’s time to switch from PHP? No. It’s unlikely this blog will switch from WordPress anytime soon and Phusion’s own blog even runs on WordPress. There are many great PHP applications out there. More importantly, sometimes PHP will simply be a more appropriate solution.

PHP, Ruby, and Rails are all great tools you can choose from. You’ll still need to learn these tools, their relative strengths, and when it’s appropriate to apply each.

Passenger just means Rails deployment is getting simpler and more mature. It also means deploying PHP and Rails applications together on the same Apache instance is now much easier. These are more reasons to consider adding Rails to your toolbox. It’s certainly a great time to be building web applications.

The word public/ is perfectly descriptive, and acts as a cognitive warning when serving content. Anything in the public/ directory is free and open for users to download.

It’s a great idea to use this same idea in PHP applications. PHP should interpret files with certain file extensions (such as files ending in .php), but mistakes happen. When you name the web accessible directory of your applications public/, it is immediately obvious as to the accessibility of the content. This raises a red flag when you’re uploading sensitive documents or information into a publicly accessible directory.

Most of the PHP frameworks follow this idea, and keep their application logic in a directory that is not publicly accessible from the web.

When you’re starting out with Ruby and Rails, often times you’ll know how to do something in PHP and need a way to map that knowledge into the Ruby world. For example, you might ask yourself, “What’s the equivalent of fopen in Ruby?”

Now, you can get the answer just like you would on php.net — http://railsforphp.com/fopen

You can also enter a PHP function name into the search box at the top of every page. If we have a reference page for that function, you’ll be taken directly there.

PHP and Ruby are great complementary tools. You might find that you like Ruby for other tasks like command line scripts. With this in mind, our reference differentiates between Ruby and Rails. Solutions that only work in Rails, such as the one for http_build_query, are clearly marked as such.

To start out, we’ve seeded the reference with many of the more common functions for working with strings, regular expressions, and the filesystem. In the coming weeks, we’ll continue to expand it.

Like most utility functions, generating these hashes is not part of the core Ruby objects. Instead, the Ruby Standard Library includes the Digest library. Let’s take a look at the equivalents to PHP’s common cryptographic hash functions in the Ruby universe.

Comparing Functions/Methods

md5 vs. Digest::MD5

In PHP, we use the md5 function to calculate an MD5 hash. In Ruby, we use Digest::MD5.

PHP

print md5("my string");
// => 2ba81a47c5512d9e23c435c1f29373cb

Ruby

require "digest"
 
print Digest::MD5.hexdigest("my string")
# => 2ba81a47c5512d9e23c435c1f29373cb

Above, we first required the Digest library using require "digest". This is similar to using require_once to include a class in PHP. To get the equivalent of the hash we’d generate using md5(), we use the hexdigest method.

md5_file vs. Digest::MD5

There are generally two different ways in Ruby to generate a cryptographic hash of a file. The first and easiest way is to use File.read to read the entire file contents into memory. We can then use the same MD5.hexdigest method on the contents to generate the hash.

PHP

print md5_file("my_file.jpg");
// => 14b6a00b1a4eb40542cfecdc4d64940d

Ruby

require "digest"
 
print Digest::MD5.hexdigest(File.read("my_file.jpg"))
# => 14b6a00b1a4eb40542cfecdc4d64940d

The code above works for many cases but for larger files, there’s a risk of consuming large amounts of memory. For these cases, we can initialize a new digest with Digest::MD5.new and then read the file in smaller chunks, incrementally building the digest with MD5#update.

Ruby

require "digest"
 
digest = Digest::MD5.new
File.open("my_file.jpg", "r") do |f|
  digest.update f.read(8192) until f.eof
end
 
print digest.hexdigest
# => 14b6a00b1a4eb40542cfecdc4d64940d

sha1 vs. Digest::SHA1

We use the Digest::SHA1 class to build the equivalent cryptographic hash to PHP’s sha1 function. This works the same as the Digest::MD5 class mentioned above, and needs to require the Digest library using require "digest".

PHP

print sha1("my string");
// => e19343e6c6c76f8f634a685eba7c0880648b1389

Ruby

require "digest"
 
print Digest::SHA1.hexdigest("my string")
# => e19343e6c6c76f8f634a685eba7c0880648b1389

sha1_file vs. Digest::SHA1

Just like with MD5, we can generate the SHA1 hash of a file in a couple different ways. We can generate the hash of the entire entire file with File.read

PHP

print sha1_file("my_file.jpg");
// => 5de1a26c24b0d176c6cafd11bf1f03017bcc767b

Ruby

require "digest"
 
print Digest::SHA1.hexdigest(File.read("my_file.jpg"))
# => 5de1a26c24b0d176c6cafd11bf1f03017bcc767b

We can take the same chunked approach we used for MD5 to generate a hash for larger files.

Ruby

require "digest"
 
digest = Digest::SHA1.new
File.open("my_file.jpg", "r") do |f|
  digest.update f.read(8192) until f.eof
end
 
print digest.hexdigest
# => 5de1a26c24b0d176c6cafd11bf1f03017bcc767b

crypt vs. String#crypt

Finally we have PHP’s crypt function, which returns an encrypted string using a standard Unix DES-based encryption or an alternate based on the system. This operation has very similar usage in PHP and Ruby. Ruby uses the String#crypt method with a single salt parameter to get the same result.

PHP

print crypt("my string", "salt");
// => saGMxKJ.nmUhU

Ruby

print "my string".crypt("salt")
# => saGMxKJ.nmUhU

In this example, we have an array of fruit. We want to iterate through the array and print the name of each fruit. At the end, we want to print the name of the last fruit again.

PHP

$fruit = array('apple', 'banana', 'orange');
foreach ($fruit as $f) { print "$f, "; }
 
print $f;

As you probably expected, here’s the output of the above program:

apple, banana, orange, orange

This works because PHP has simple scoping rules. Within a function, any variables that get defined are available any time later in the function. Variables defined before constructs like foreach() and while() are available inside those constructs. Variables defined inside those constructs are defined in the same scope and are available outside of those constructs, like $f above.

When you first start writing programs in Ruby, you’ll probably start out by converting bits of your PHP programs over before you get into the swing.

With that in mind, let’s now try directly converting our PHP program to Ruby:

Ruby

fruit = %w[apple banana orange]
fruit.each { |f| print "#{f}, " }
 
print f

If you’re wondering about the %w, that’s a word array (see Useful Perlisms in Ruby for this and other tricks). Otherwise, this looks very similar to the PHP version.

However, you might find the results to be unexpected:

apple, banana, orange, 
NameError: undefined local variable or method 'f'

In Ruby, scoping is lexical. There can be many levels of scope and scope can even be manipulated. When a block is called in Ruby, it is bound to the scope of its caller. This means that within the same method, variables defined above the block are available inside the block. However, variables defined within the block are not normally available outside the block. In the example above, Ruby raised a NameError because f was only defined within the block, not above it.

If you really needed to do the example in Ruby, you could define a variable above the block to store the last value through the iteration.

Ruby

fruit = %w[apple banana orange]
last_fruit = nil
 
fruit.each do |f| 
  print "#{f}, " 
  last_fruit = f
end
 
print last_fruit

Since the last_fruit variable is defined above the block, it is available both inside and below the block. The program now works as you might expect.

While that helps us begin to understand Ruby’s scoping and gets the job done, a much simpler and more idiomatic Ruby solution for this particular problem would be this:

Ruby

fruit = %w[apple banana orange]
fruit.each { |f| print "#{f}, " }
 
print fruit.last

The Array#last method is the equivalent of PHP’s end(). By just using it instead, our code is both more concise and readable.

An an example, we can specify a variable number of attributes when we perform model validation. Take a look at how we validate the presence of both the name and age attributes for a model along with a custom error message as the final argument.

Ruby

class User < ActiveRecord::Base
  validates_presence_of :name, :age, :message => "Can't be empty!"
end

We also see this pattern used in various built-in view helper methods. When we want to include multiple stylesheets in our application, we can specify multiple sources using stylesheet_link_tag.

Ruby

<head>
  <%= stylesheet_link_tag :layout, :colors, :media => "screen" %>
</head>

Using variable arguments is often more convenient than calling a function multiple times, and it is a little nicer than passing an array. This trick can be adapted to PHP development pretty easily. The above example looks quite different from PHP when using the common Ruby style.

However, it does map faithfully to PHP if we add back the syntactic noise that we purposely left out. We also talk about this transliteration in the Beginning Ruby Code chapter of the book.

Ruby

<%= stylesheet_link_tag(:layout, :color, {:media => "screen"}) %>

PHP

<?= stylesheetLinkTag('layout', 'color', array('media' => 'screen')) ?>

In PHP we implement variable arguments using using the func_get_args() function:

PHP

function stylesheetLinkTag($sources)
{
    $sources = func_get_args();
 
    foreach ($sources as $source) {
      // ...
    }
}

Since the $sources come from func_get_args(), no arguments in the function definition are necessary. However, if the function definition has no arguments, PHP will not raise a notice if the function is called with no arguments. Since our function requires at least one argument, it’s useful to have it in the function definition for that reason. It will also get picked up by code documentation tools.

Let’s not forget about the optional list of options that we pass in as the final argument. We can extract this data in our PHP function implementation by simply checking if the last value of the variable arguments is an array.

PHP

function stylesheetLinkTag($sources)
{
  $sources = func_get_args();
  $last    = end($sources);
  $options = is_array($last) ? array_pop($sources) : array();
 
  // find the stylesheet media attribute
  $media = isset($options['media']) ? $options['media'] : '';
 
  foreach ($sources as $source) {
    // ...
  }
}