In this chapter, we’re going to look at some advanced Ruby techniques that have not been covered in prior chapters. This chapter is the last instructional chapter in the second part of the book, and although we’ll be covering useful libraries, frameworks, and Ruby-related technologies in Part 3, this chapter rounds off the mandatory knowledge that any proficient Ruby programmer should have. This means that although this chapter will jump between several different topics, each is essential to becoming a professional Ruby developer.
The myriad topics covered in this chapter include how to create Ruby code dynamically on the fly, methods to make your Ruby code safe, how to issue commands to the operating system, how to integrate with Microsoft Windows, and how to create libraries for Ruby using other programming languages. Essentially, this chapter is designed to cover a range of discrete, important topics that you might find you need to use, but that fall outside the immediate scope of other chapters.
Dynamic Code Execution
The eval method simply executes (or evaluates) the code passed to it and returns the result. The first example made eval execute puts 2 + 2, whereas the second used string interpolation to build an expression of 15 * 2, which was then evaluated and printed to the screen using puts.
Bindings
In Ruby, a binding is a reference to a context, scope, or state of execution. A binding includes things such as the current value of variables and other details of the execution environment.
It’s possible to pass a binding to eval and to have eval execute the supplied code under that binding rather than the current one. In this way, you can keep things that happen with eval separate from the main execution context of your code.
This code demonstrates that eval accepts an optional second parameter, a binding, which in this case is returned from the binding_elsewhere method . The variable remote_binding contains a reference to the execution context within the binding_elsewhere method rather than in the main code. Therefore, when you print x, 20 is shown, as x is defined as equal to 20 in binding_elsewhere!
You can obtain the binding of the current scope at any point with the Kernel module’s binding method.
In this example, two bindings are in play: the default binding and the remote_binding (from the binding_elsewhere method).
Therefore, even though you set x first to 10, and then to 50, you’re not dealing with the same x in each case. One x is a local variable in the current context, and the other x is a variable in the context of binding_elsewhere.
Other Forms of eval
Although eval executes code within the current context (or the context supplied with a binding), class_eval, module_eval, and instance_eval can evaluate code within the context of classes, modules, and object instances, respectively.
In this example, you use the add_accessor_to_person method to add accessors dynamically to the Person class. Prior to using the add_accessor_to_person method, neither the name nor gender accessors exist within Person.
String interpolation makes the eval methods powerful tools for generating different features on the fly. This ability is a power unseen in the majority of programming languages, and is one that’s used to great effect in systems such as Ruby on Rails (covered in Chapter 13).
In this example, you add the add_accessor method to the Class class, thereby adding it to every other class defined within your program. This makes it possible to add accessors to any class dynamically, by calling add_accessor. (If the logic of this approach isn’t clear, make sure to try this code yourself, step through each process, and establish what is occurring at each step of execution.)
Because add_accessor is being used within a class, the method call will work its way up to the add_accessor method defined in class Class.
Creating Your Own Version of attr_accessor
This version of the class is more concise and has exactly the same functionality as the longhand version. Now it’s time to ask the question, how does attr_accessor work?
At first, this code looks complex, but it’s very similar to the add_accessor code you created in the previous section. You use class_eval to define getter and setter methods dynamically for the attribute within the current class.
Thus, you have duplicated the functionality of attr_accessor.
You can use this technique to create a multitude of different “code generators” and methods that can act as a “macro” language to perform things in Ruby that are otherwise lengthy to type out.
Running Other Programs from Ruby
Often, it’s useful to be able to run other programs on the system from your own programs. In this way, you can reduce the amount of features your program needs to implement, as you can pass off work to other programs that are already written. It can also be useful to hook up several of your own programs so that functionality is spread among them. Rather than using the RPC systems covered in the previous chapter, you can simply run other programs from your own with one of a few different methods made available by Ruby.
Getting Results from Other Programs
There are three simple ways to run another program from within Ruby: the system method (defined in the Kernel module), backtick syntax (``), and delimited input literals (%x{}). Using system is ideal when you want to run another program and aren’t concerned with its output, whereas you should use backticks when you want the output of the remote program returned.
These lines demonstrate two ways of running the system’s directory list program:
For the first line, the list program output displays in the console and x equals true. For the second line, x contains the output of the list command. Which method you use depends on what you’re trying to achieve. If you don’t want the output of the other program to show on the same screen as that of your Ruby script, then use backticks (or a literal, %x{}).
%x{} is functionally equivalent to using backticks, for example, %x{ls} or %x{dir}.
Transferring Execution to Another Program
In this example, execution is transferred to a different program, and the current program ceases immediately—the second line is never executed.
Running Two Programs at the Same Time
Forking is where an instance of a program (a process) duplicates itself, resulting in two processes of that program running concurrently. You can run other programs from this second process by using exec, and the first (parent) process will continue running the original program.
Don’t run the preceding code from irb. If irb forks, you’ll end up with two copies of irb running simultaneously, and the result will be unpredictable.
Forking is not possible with the Windows version of Ruby, as POSIX-style forking is not natively supported on that platform. You will use the spawn() method instead. More information at https://ruby-doc.org/core/Kernel.html#method-i-spawn.
Interacting with Another Program
The previous methods are fine for simple situations where you just want to get basic results from a remote program and don’t need to interact directly with it in any way while it’s running. However, sometimes you might want to pass data back and forth between two separate programs.
Ruby’s IO module has a popen method that allows you to run another program and have an I/O stream between it and the current program. The I/O stream between programs works like the other types of I/O streams we looked at in Chapter 9, but instead of reading and writing to a file, you’re reading and writing to another program. Obviously, this technique only works successfully with programs that accept direct input and produce direct output at a command prompt level (so not GUI applications).
In this example, you open an I/O stream with ls (the UNIX command to list the contents of the current directory—try it with dir if you’re using Microsoft Windows). You read the lines one by one, as with other forms of I/O streams, and close the stream when you’re done.
The reason for handle.close_write is to close the I/O stream’s writing stream, thereby sending any data waiting to be written out to the remote program. IO also has a flush method that can be used if the write stream needs to remain open.
Threads
Thread is short for thread of execution. You use threads to split the execution of a program into multiple parts that can be run concurrently. For example, a program designed to email thousands of people at once might split the task between 20 different threads that all send email at once. Such parallelism is faster than processing one item after another, especially on systems with more than one CPU, because different threads of execution can be run on different processors. It can also be faster because rather than wasting time waiting for a response from a remote machine, you can continue with other operations.
Ruby 1.8 didn’t support threads in the traditional sense. Typically, threading capabilities are provided by the operating system and vary from one system to another. However, Ruby 1.8 provided Ruby’s threading capabilities directly which meant they lacked some of the power of traditional system-level threads. In Ruby 1.9, Ruby began to use system-based threads, and this is now the default expectation among Rubyists.
While Ruby 1.9 and 2.x’s threads are system (native) threads, in order to remain compatible with 1.8 code, a global interpreter lock (GIL) has been left in place so that threads do not truly run simultaneously. This means that all of what is covered in this section is relevant to all of 1.8, 1.9, 2.0, and beyond. A Ruby 1.9-and-beyond–only alternative, fibers, is covered in the next primary section of this chapter which now supports non-blocking concurrency.
Basic Ruby Threads in Action
You create an array to hold your Thread objects so that you can easily keep track of them. Then you create ten threads, sending the block of code to be executed in each thread to Thread.new, and add each generated thread to the array.
When you create a thread, it can access any variables that are within scope at that point. However, any local variables that are then created within the thread are entirely local to that thread. This is similar to the behavior of other types of code blocks.
Once you’ve created the threads, you wait for all of them to complete before the program finishes. You wait by looping through all the thread objects in threads and calling each thread’s join method. The join method makes the main program wait until a thread’s execution is complete before continuing. In this way, you make sure all the threads are complete before exiting.
The example has created ten Ruby threads whose sole job is to count and sleep randomly. This results in the preceding pseudo-random output.
Rather than sleeping, the threads could have been fetching web pages, performing math operations, or sending emails. In fact, Ruby threads are ideal for almost every situation where concurrency within a single Ruby program is desired.
In Chapter 15, you’ll be using threads to create a server that creates new threads of execution for each client that connects to it, so that you can develop a simple chat system.
Advanced Thread Operations
As you’ve seen, creating and running basic threads is fairly simple, but threads also offer a number of advanced features. These are discussed in the following subsections.
Waiting for Threads to Finish Redux
Getting a List of All Threads
However, keeping your own list of threads is essential if you’re likely to have more than one group of threads working within an application and you want to keep them separate from one another when it comes to using join or other features.
The list of threads also includes the main thread representing the main program’s thread of execution, which is why we explicitly do not join it in the prior code.
Thread Operations from Within Threads Themselves
In this example, execution flip-flops between the two threads, causing the pattern shown in the results.
Fibers
Fibers offer an alternative to threads in Ruby 1.9 and beyond. In Ruby 3, Fiber was rewritten, so it no longer blocks on IO operations and supports non-blocking fibers. Fibers are lightweight units of execution that control their own scheduling (often referred to as cooperative scheduling). Whereas threads will typically run continually, fibers hand over control once they have performed certain tasks. Unlike regular methods, however, once a fiber hands over control, it continues to exist and can be resumed at will.
In short, fibers are pragmatically similar to threads, but fibers aren’t scheduled to all run together. You have to manually control the scheduling.
A Fiber in Action
In this example, we create a fiber using a block, much in the same style as we created threads earlier. The difference, however, is that the fiber will run solely on its own until the Fiber.yield method is used to yield control back to whatever last told the fiber to run (which, in this case, is the sg.resume method call). Alternatively, if the fiber “ends,” the value of the last executed expression is returned.
In this example, it’s worth noting that you don’t have to use the fiber forever, although since the fiber contains an infinite loop, it would certainly be possible to do so. Even though the fiber contains an infinite loop, however, the fiber is not continually running, so it results in no performance issues.
If you do develop a fiber that has a natural ending point, calling its resume method once it has concluded will result in an exception (which, of course, you can catch—refer to Chapter 8’s “Handling Exceptions” section) that states you are trying to resume a dead fiber.
Passing Data to a Fiber
In this case, we start out by getting back square numbers one at a time as before. On the fifth attempt, however, we pass back the number 40, which is then assigned to the fiber’s s variable and used to generate square numbers. After a couple of iterations, we then reset the counter to 0. The number is received by the fiber as the result of calling Fiber.yield.
It is not possible to send data into the fiber in this way with the first resume, however, since the first resume call does not follow on from the fiber yielding or concluding in any way. In that case, any data you passed is passed into the fiber block, much as if it were a method.
Non-blocking Fiber
When used correctly, non-blocking fibers will increase performance since multiple operations are performed at once. Since non-blocking fibers are opt-in, Ruby 3 will not break existing code. By default, all I/O operations in fiber are non-blocking with Ruby 3.
Why Fibers?
A motivation to use fibers over threads in some situations is efficiency. Creating hundreds of fibers is a lot faster than creating the equivalent threads, since threads are created at the operating system level. There are also significant memory efficiency benefits.
One of the greatest benefits of fibers is in implementing lightweight I/O management routines within other libraries, so even if you don’t use fibers directly, you might still end up benefiting from their use elsewhere.
Unicode, Character Encodings, and UTF-8 Support
Unicode is the industry standard way of representing characters from every writing system (character set) in the world. It’s the only viable way to be able to manage multiple different alphabets and character sets in a reasonably standard context.
One of Ruby 1.8’s most cited flaws was in the way it dealt with character encodings—namely, hardly at all. There were some workarounds, but they were hackish. Ruby 1.8 treated strings as simple collections of bytes rather than true characters, which is just fine if you’re using a standard English character set, but if you wanted to work with, say, Arabic or Japanese, you have problems!
Ruby 1.9 and beyond, on the other hand, support Unicode, alternative character sets, and encodings out of the box. In this chapter, we’ll focus on the direct support in Ruby 1.9 and up.
For a full rundown of Unicode and how it works and relates to software development, read www.joelonsoftware.com/articles/Unicode.html. The official Unicode site, at http://unicode.org/, also has specifications and further details.
Ruby 1.9 and Beyond’s Character Encoding Support
Unlike with Ruby 1.8, no hacks or workarounds are necessary to work with multiple character sets and encodings in Ruby 1.9 and above. Ruby 1.9 supports a large number of encodings out of the box (over 100 at the time of writing), and the interface is seamless. You not only get character encoding support for strings within your programs, but for your source code itself too.
Encoding.list returns an array of Encoding objects that represent the different character encodings that your Ruby interpreter supports.
Strings
I would personally suggest that, where possible, you try and use the UTF-8 encoding exclusively in any apps that are likely to accept input from people typing in many different languages. UTF-8 is an excellent “global” encoding that can represent any character in the Unicode standard, so using it globally throughout your projects will ensure that everything works as expected.
Make sure to refer to Chapter 9 to see how to open files and read data that is in different character encodings.
Source Code
As well as supporting character encodings out of the box for strings and files, Ruby 1.9 and beyond also allow you to use any of the supported character sets for your actual source code files.
The primary reason for doing this is so that you can use UTF-8 (or whichever encoding you choose to specify) within literal strings defined with your source files without running into snags with String#length, regular expressions, and the like.
Another fun (but not endorsed by me!) option is to use alternate non-ASCII characters in method names, variable names, and so forth. The danger of this, of course, is that you reduce the usability of your code with developers who might prefer to use other encodings.
Summary
In this chapter, we looked at an array of advanced Ruby topics, from dynamic code execution to writing high-performance functions in the C programming language. This is the last chapter that covers general Ruby-related knowledge that any intermediate Ruby programmer should be familiar with. In Chapter 12, we’ll be taking a different approach and will develop an entire Ruby application, much as we did in Chapter 4.
Binding: A representation of a scope (execution) context as an object.
Forking: When an instance of a program duplicates itself into two processes, one as a parent and one as a child, both continuing execution.
Threads: Separate “strands” of execution that run concurrently with each other. Ruby’s threads in 1.8 were implemented entirely by the Ruby interpreter, but since Ruby 1.9 use system-based threads, and are a commonly used tool in application development.
Fibers: Lightweight cooperative alternatives to threads. They must yield execution in order to be scheduled.
Character encoding: This describes a system and code that pair characters (whether they’re Roman letters, Chinese symbols, Arabic letters, etc.) to a set of numbers that a computer can use to represent those characters.
UTF-8 (Unicode Transformation Format-8): This is a character encoding that can support any character in the Unicode standard. It supports variable-length characters, and is designed to support ASCII coding natively, while also providing the ability to use up to four bytes to represent characters from other character sets.
Now you can move on to Chapter 12, where you’ll develop an entire Ruby application using much of the knowledge obtained in this book so far.