We’ve said all along that Ruby helps you do more with less code. This principle is built right into the language. One example of this is inline conditionals.

You’ve already seen the regular forms of if and unless, of course:

if true
  puts "I'll be printed!"
end

unless true
  puts "I won't!"
end

But if the code within your conditional is only one line long, you have the option to move the conditional to the end of that line. These expressions work just like the ones above:

puts "I'll be printed!" if true

puts "I won't!" unless true

When you first create a class, you’ll probably be the only one using it. But that (hopefully) won’t always be the case. Other developers will find your class and realize it solves their problems, too. But their problems are not always the same as your problems, and perhaps they will use your class in ways you didn’t foresee. That’s fine, until you need to make changes to your class.

Suppose you need to add a 15% surcharge on any amount your customers are billed for. You could create an Invoice class that allows you to set a subtotal attribute. You could have a total method that calculates the total amount for the bill. And to keep the total method from getting too complex, you might break the calculation of fees out into a separate fees method, which total calls.

But then you learn that your department intends to add a flat $25 fee to all invoices as well. So you add a flat_rate parameter to your fees method to account for that...

This works great, until you get a call from another department, who want to know why your class broke their code. Evidently they started using your fees method to calculate their own 8% surcharge. But their code is still written with the assumption that fees requires two parameters, even though it’s been updated to require three!

The problem here is that other developers are calling your fees method from outside your class, when you really only intended for it to be called inside your class. Now you have a choice: figure out how to make the fees method work for both you and the other developers who are using it, or change it back and then never modify it again.

There’s a way to avoid this situation, though. If you know a method will only be used from inside your class, you can mark it as private. Private methods can only be called from within the class on which they’re defined. Here’s an updated version of the Invoice class, with the fees method marked private:

Now, code that tries to call the fees method from outside the Invoice class will receive an error indicating that the method being called is private.

But your total method (which is an instance method on the same class as fees) can still call it.

The other department will have to find a different way to calculate their fees, it’s true. But future misunderstandings of this sort will be averted. And you’ll be free to make any changes to the fees method you need! Private methods can help keep your code clean and easy to update.

We like to “quote” emails that we reply to by marking them with a > character before each line of text. That way, the recipient will know what we’re talking about.

Here’s a quick script that will read in the contents of a text file and insert “>” before each line:

We have to go into the script and change the filename every time we want to use a new input file, though. It would be nice if we had a way to specify the filename outside of our script.

And we can! We just need to use command-line arguments. Programs that run in your terminal often allow you to specify arguments after the program name, much like arguments to a method call, and Ruby scripts are no exception. You can access the arguments your script was called with through the ARGV array, which is set up every time a Ruby program runs. The first argument is at ARGV[0], the second at ARGV[1], and so forth.

The two-line args_test.rb script below demonstrates this. If we run it in a terminal, whatever we type in the terminal after the script name will be printed when the script runs.

We can use ARGV in quote.rb to allow us to specify any input file we want, each time we run it. We just need to replace the hardcoded filename with ARGV[0]. From then on, when we run quote.rb in the terminal, we can simply specify an input filename after the script name!

Regular expressions are a way of looking for patterns within text. Many programming languages offer regular expressions, but they’re especially easy to work with in Ruby.

If you’re looking for an email address within some text, you can use a regular expression to say, “Find me some letters, followed by an @ symbol, then more letters, then a period, then more letters.”

If you’re looking for the end of a sentence, you can use a regular expression to say, “Find me a period, question mark, or exclamation point, followed by a space.”

Regular expressions are insanely powerful, but they can also be complex and hard to read. Even if you only learn their most basic features, though, you’ll still find them quite useful. Our goal here is to give you a sample of what they can do for you, and give you a couple of resources where you can learn more on your own.

Suppose you have a string, and you need to find a phone number within it:

"Tel: 555-0199"

You can create a regular expression to find it for you. Regular expression literals start and end with a forward slash (/) character.

A regular expression by itself doesn’t do anything, though. You can use the =~ operator in a conditional to test whether the regular expression matches your string:

Right now, our regular expression can only match one phone number: 555–0199. To match other numbers as well, we can use the d character class, which will match any digit from 0 through 9. (Other character classes include w for characters from words, and s for whitespace.)

Instead of typing d repeatedly like the code above, we can use a single d followed by +, which looks for one or more of the preceding match.

Better yet, we can use a number inside of curly braces, which indicates you expect the preceding match to occur that number of times.

You can record the text that your regular expression matched by using a capture group. If you place parentheses around part of your regular expression, then that part of the match will be recorded in a special variable named $1. You can print the value in $1 to see what was matched.

A regular expression is just another object in Ruby, so you can pass them as arguments to methods. Strings have a sub method that will look for a regular expression within a string, and substitute a new string in place of the match. This call to sub will blank out any phone numbers within the string:

This has been just a tiny taste of what regular expressions can do. There’s lots more functionality that we don’t have room to cover here, and you could go your entire programming career without ever fully mastering regular expressions. But if you learn the basics, they can save you a lot of time and coding!

If you want to learn more, check out the chapter on regular expressions in Programming Ruby by Dave Thomas, Chad Fowler, and Andy Hunt. (We’ll talk about that book more in a bit.) Or look up the

Most object-oriented languages let you define instance methods that are available on all instances of a class. But Ruby is one of the few that let you define instance methods on a single instance. Such methods are known as singleton methods.

Here we have a Person class, with one instance method, speak. When you first create an instance of Person, it only has the speak instance method available.

But in Ruby, it’s possible to define an instance method that is available on one single object. Following the def keyword, you include a reference to the object, a dot operator, and the name of the singleton method you want to define.

This code will define a fly method on the object in the superhero variable. The fly method can be called like any other instance method, but it will be available only on superhero.

It’s also possible to override methods defined by the class with singleton methods. This code overrides the speak instance method from the Person class with a version unique to the superhero:

This ability can be quite useful in unit tests, where you sometimes need an object’s method not to behave the way it usually does. For example, if an object always creates files to store output, and you don’t want it littering your hard drive with files each time you run a test, you can override the file creation method on the instance in your tests.

Singleton methods are surprisingly handy, and just one more example of Ruby’s flexibility!

When you call an instance method that hasn’t been defined on an object, Ruby calls a method named method_missing on that object. The version of method_missing that all objects inherit from the Object class simply raises an exception:

But if you override method_missing in a class, you can create instances of it and call undefined methods on them, and you won’t get an exception. Not only that, you can do interesting things with these “phantom methods”...

Ruby always passes at least one argument to method_missing: the name of the method that was called, in the form of a symbol. Also, whatever method_missing returns will be treated as the return value of the phantom method. So here’s a class that will return a string with the name of any undefined method you call on it.

Any arguments passed to the undefined method get forwarded on to method_missing, so we can return arguments to the phantom method as well...

Here’s a Politician class whose instances will promise to do anything you ask them to. You can call any undefined method and pass it an argument, and method_missing will print both the method name and argument.

It gets even better, though... Remember our dRuby code from a few pages ago, which created a proxy object that called methods on another object over the network?

Proxy objects in dRuby allow you to call any method on them. Since the proxy defines almost no methods of its own, those calls get forwarded to the proxy’s method_missing method. There, the name of the method you called and any arguments you provided are passed over the network to the server.

The server then calls the method on the actual object and sends any return value back over the network, where it’s returned from the proxy object’s method_missing.

The process is complex, but method_missing makes it as easy as calling a method on the proxy!

Remember back in Chapter 13, when we wanted to run unit tests on classes in our lib subdirectory, we had to add -I lib to the command line? We also had to specify the file containing the tests we wanted to run...

It’s a bit of a pain now, but what if our project grew and we had dozens of test files? Running them one at a time would get pretty unmanageable. And testing is just one of the tasks we have to perform on a regular basis. Eventually, we’ll need the ability to build documentation, package our project as a gem, and more.

Ruby comes with a tool called Rake that can simplify all of this for us. You can run the rake command from your terminal, and it will look for a file called “Rakefile” (with no filename extension) in your project directory. This file should contain Ruby code that sets up one or more tasks that Rake can perform for us.

Here’s a Rakefile that sets up a task to run all of our tests for us. It uses the class Rake::TestTask, which comes with Rake and is specialized for running tests. This TestTask is set to load files from the lib directory (no more need for -I lib), and to run every test file in the test directory (no need to specify test files one at a time).

Once a Rakefile is saved in your project directory, you can change to that directory in your terminal and run the command rake, followed by the name of the task you want to run. For our example, there’s only one task, test, so we’ll run that.

With that one simple command, Rake will find and run all the files in our test subdirectory!

Rake can help with more than just tests, though. There are also generic tasks that you can use to run any other sort of command you might need. Look up Rake in Ruby’s standard library documentation to learn more.

At the start of Chapter 14, we ran gem install sinatra in the terminal to download and install the Sinatra gem. That was simple enough, since we only needed one gem.

But suppose we also needed the i18n gem to help with internationalization (translation to other written languages), and the erubis gem for better ERB support. Suppose that we need to make sure we’re using an older version of i18n, because our code relies on a method that has been removed in the latest version. Suddenly installing gems doesn’t seem so simple anymore.

But as usual, there’s a tool available that can help: Bundler. Bundler allows each application on your system to have its own set of gems. It also helps you maintain those gems, ensuring the proper version of each is downloaded and installed, and preventing multiple versions of the same gem from conflicting with each other.

Bundler is not installed with Ruby; it’s distributed as a gem itself. So we first need to install it by typing gem install bundler (or sudo gem install bundler, if your system requires it) in the terminal. This will install the Bundler library, as well as a bundle command that you can run from your terminal.

Bundler gets the names of gems to install from a file named “Gemfile” (note the similarity to “Rakefile”) in your project folder. So, we’ll create a Gemfile now.

A Gemfile contains Ruby code just like a Rakefile does, but this file calls methods from the Bundler library. We start with a call to the method source, with the URL of the server we want to download gems from. Unless your company is running its own gem server, you’ll want to use the Ruby community’s server: 'https://rubygems.org'. Next, we call the method gem for each gem we want to install, and provide the gem name and version we want as arguments.

Once your Gemfile has been saved, change to your project directory in your terminal and run bundle install. Bundler will automatically download and install the particular versions of the gems that your Gemfile references.

After Bundler installs the gems in your Gemfile, you can proceed to reference them in your code just as if you’d installed them yourself. You need to make a little change when running your app, though: always be sure to prefix the command in your terminal with the bundle exec command.

Here’s why: if you don’t use the bundle command to run your app, then it’s running outside Bundler’s control. Even then, everything might seem fine. But part of Bundler’s job is to ensure that other gem versions on your system don’t conflict with the gems that Bundler installed. It can’t do that unless it’s running.

So, to be safe, when using Bundler, always type bundle exec when running your app (or read up on other ways to ensure your app runs within the Bundler environment). You’ll save yourself some trouble someday!

You can learn more about Bundler at: http://bundler.io/

This is the end of this Ruby book, but it’s just the start of your Ruby journey. We want to recommend a couple of excellent books that will help you along the road.

Programming Ruby 1.9 & 2.0 (Fourth Edition)

By Dave Thomas, with Chad Fowler and Andy Hunt

The Ruby community has nicknamed this book the “Pickaxe” due to the picture of a pickaxe on its cover. It’s well known and widely used.

There are two kinds of technical books out there: tutorial books (like the one you’re holding) and reference books (like Programming Ruby). And the Pickaxe is a great reference: it covers all the topics we didn’t have room for in this book. At the back, it has documentation on all the important classes and modules from Ruby’s core and the standard library. (So you won’t need the HTML documentation if you have this.)

The Well-Grounded Rubyist (Second Edition)

By David A. Black

If you want insight into the simple elegance of Ruby’s inner workings, this is the place to get it. Did you know there’s actually no such thing as a class method in Ruby? (So-called class methods are actually just singleton methods on a class object.) Did you know classes are just modules that allow instance variables? David A. Black takes language behavior that sometimes seems complex and inconsistent, and reveals the underlying rules that will make it all click.