What does eval do? Quite simply, you pass in some Ruby code in a string, and it’ll evaluate it. Observe:

eval "puts 2+2" # => 4
eval "'hello world!'.upcase # => HELLO WORLD

Clearly, this is useful stuff–you can pass in arbitrary code, even assemble your strings on the fly for truly complicated code.

But, eval is a dangerous tool–because it can execute arbitrary code. For example, if you have some code like this:

input = # ... read from some form
eval input
# ...

Some clever script kiddie will send the input system 'rm -rf *', you can kiss your application goodbye. And your family photo-collection. And your MP3 collection. And your hard-drive.

Some people brand eval as an “evil,” “insidious,” “destructive” function. Which is true–it has destructive potential. That’s why you need to sanitize your input. Don’t just send it as-is. Don’t risk it.

On the other hand, eval has a lot of tricky uses for things you might not otherwise be able to do. For example, how would you create a generic “shutdown hook” system for your Ruby application? other programming languages have pointers–in .NET, for example, you can accumulate a collection of pointers, and run those. What can you do in Ruby? You can accumulate a collection of strings to eval!

shutdown_hooks = ["Logger.write 'normal termination'", "Logger.close", "DatabaseConnector.close"]

Voila! You can iterate through them and execute them, just like any set of pointers in other languages.

To recap:

• eval is merely a tool. It can be used, and abused, like any tool.
• Use eval as necessary, but avoid it if possible.
• Sanitize your input! Don’t risk it! Script kiddies abound!

In other programming languages, one of the concerns raised with reflection is that it’s a “heavy” process. How does Ruby stack up? If you know, share it in the comments!

/*
This is a block comment. You can put whatever you want here.
Even ASCII art! For REAL! o[+++]XXXXXXXXXXXX>
*/
// ...

But what about Ruby?

Ruby has two special tags that you use: =begin and =end. So your Ruby comment would look like this:

=begin
This function returns the minimum of A or B.
For example, if A is 3 and B is 7, it'll return 3.
=end
def self.min(a, b)
# ...
end

Yes, yes! It’s easy!

Wait! What’s that, you say? You say it doesn’t work? Well, that’s tragic–and in fact, it happened to me, too. The key is that these tokens cannot be preceded by whitespace. If they are, it won’t work.

What? Ghetto, you say? Well, tough luck, my friend–this is how Ruby deals with block comments. Just use it, OK? It’s easier than commenting out 130+ lines of code one by one. (Or if you have an IDE that does it in one-shot, great, even better!)

And that’s Ruby comment blocks! Simple!

If you’re wondering how Rails (and, consequentially, Ruby) deals with Regular Expressions, you’ve come to the right place.

Syntax

Regular expressions in Rails are bracketed by forward-slash, so a regular expression looks like this: /[0-9]*/. You can put all your usual modifiers after the second slash (such as i for case-insensitivity). Gone are other programming languages’ ways of dealing with regular expressions as a string!

Matching Expressions

As you’d expect, you match expressions against string. Hence the String class has a match function that takes a regular expression, and returns the partially-matched string.

"Hello".match(/l/) => "l"

Great stuff! You can do all your usual complex matching. And if nothing is matched, you get nil:

"Hello".match(/x/) => nil

This allows you to easily write validation code (in Ruby, since Rails has its own Validation framework) like so:

if credit_card.match(/[0-9]{16}/).nil?
puts "Please enter a valid 16-digit credit-card number!"
else
# process order
end

Replacing Matched Groups

As mentioned above, you can check for matches by checking if match returns nil. But what if you want to replace a matched piece of text with something else?

For example, with credit-card storage, it’s a common thing that you want to cross out the first 12 digits, and only print the last four. In Regular Expression parlance, these groups are called “backreferences,” because they refer back to what you match.

Check this example out, where we have four groups:

VALID_CREDIT_CARD = /([0-9]{4})-([0-9]{4})-([0-9]{4})-([0-9]{4})/

If you wanted to access the first group of four digits, you write \1 (or, in a string, \\1, to back-quote the slash). The second set is \2, and so on.

How can you use this? Say you want to replace the middle two groups with “XXXX”; you can use string.gsub, which takes a regular expression, and performs a replacement, like so:

"1234-5678-9012-3456".gsub(VALID_CREDIT_CARD, "\\1-XXXX-XXXX-\\2") => 1234-XXXX-XXXX-3456

Needless to say, the possibilities are endless. You can create almost anything you can imagine with this simple tool–everything from credit-card hiding to a notation language like RedCloth to an HTML cleanup tool. Stretch your imagination!

And in fact, this is the core functionality in WebWrench, our Ruby static website generation tool. Check it out, and see what you learn.

And that’s regular expressions … the Ruby/Rails way!

They reply back: it’s printing some temporary variables. Oops.

It’s printing out other credit-card numbers.

Identity theft ensues.

Double-oops.

Their email makes it clear: their lawyer will be in touch with you. You throw everything in a suitcase and bolt out the door.

Mexico, here I come!

…

There’s a common problem in software–how do you write code that only runs only in “debug” mode? We’re all used to that style of peppering our code with puts statements and temporary output. Learn how to use a debugger!

But there’s a deeper problem, one that large companies commonly face, too; how can you write debug-only code? For example, you might want to throw some functions in your class that print out extra functions, or bypass certain lengthy steps–just for debugging.

Ruby provides a surprisingly simple but powerful solution to this:

if statements.

Observe the code below:

class DataCruncher
def crunch_current_task
current_task = Tasks.find(:first, conditions => ['owner_id = ?', current_user.id])
current_task.start
# ...
end
end

Say we wanted to print out the task ID and title in debug mode. Assuming you have DEBUG_MODE defined in your environment.rb file in your Rails application (or in a global constant somewhere, in Ruby), you can do this:

class DataCruncher
def crunch_current_task
current_task = # ...
if DEBUG_MODE
Logger.log("Starting task #{current_task.id}: #{current_task.name}")
end
# ...
end
end

Let’s take it a step further. Say you wanted to create a short_circuit method, in debug mode ONLY, that makes sure the task finishes in five seconds. You can (surprisingly) do this:

class DataCruncher
if DEBUG_MODE
def short_circuit
current_task = # ...
current_task.time_to_process = 5
end

def crunch_current_task
# as above
end
end

The key here is that the if-statement is inside the class declaration, not inside a method declaration.

What will this do? If you try to access some_task.short_circuit, in debug mode, it’ll work; but in non-debug mode, Rails will tell you the method doesn’t exist!

You can even take this a step further (although the design decision might not be great) in a multi-user system, and define different/specific functions that users can use, based on their current role. For example, administrative users might have access to methods like flush_data, delete_user, and fun things like that. Non-admin users not only don’t have access to those methods, but they don’t even know they exist! The down side, of course, is rather than getting an “access denied” message, you get a “method not found” error. Annoying to try and handle, considering it could pop up in any part of your code.

Still, this is a powerful and useful feature of Ruby that you can use to make your life a little easier.

And of course, printing debug statements is as easy as:


class Debug
def print(message)
puts message unless System.DEBUG_MODE == false
end
end