The Rubyist Historian: Randomness

We’re entering the final leg of our journey. We’ve covered a lot of topics in the last few sections, but I just have a couple of things to touch on before we move on to writing our first full program together.

Constant Variables

A variable that is in all caps cannot be reassigned anywhere in the program. For example, if you were writing a program that used Pi in its calculations, you wouldn’t want the program (or yourself or another programmer) to accidentally override the value of Pi. To prevent this, Ruby allows for constant variables. We would simply write this in all caps:

PI = 3.141592

We can now use the variable anywhere in the program without fear that it will be overridden by another variable. For example, we could use Pi to calculate the area and circumference of a circle:

PI = 3.141592

puts "Enter a radius to calculate: "
radius = gets.chomp.to_f

area = PI * (radius**2)
area = "%.4f" % area
puts "The area of the circle is: #{area}"

circ = 2 * radius * PI
circ = "%.4f" % circ
puts "The circumference of the circle is: #{circ}"

External Libraries

In the last section we talked about modules and the ability to avoid namespace conflicts. The other great thing about modules is there are literally thousands of modules that exist outside the Ruby system, written and (theoretically) tested by other programmers, but available for your use. You probably saw an early version of this when we first talked about modules and the use of Trig.rb and Morals.rb. Libraries operate by prefacing the call with require and then tell Ruby what we want included:

require 'rubygems'

How do we know what’s available to us as programmers? By consulting either RubyForge or the Ruby Application Archive (see for more). To use the libraries, you’ll need to have a copy on your local system. Many Ruby libraries are conveniently packaged under Ruby Gems and provides a standard formate for distributing Ruby programs and libraries. Follow the instructions on on how to download and install Ruby Gems.

Perhaps one of the most useful libraries that Prof. Ramsay pointed our class to was the linguistics library:

# linguistics.rb

require 'rubygems'
require 'linguistics'

# tell linguistics to use English
Linguistics::use( :en )

puts 185934538450.en.numwords
# => one hundred and eighty-five billion, nine hundred and thirty-four million, five hundred and thirty-eight thousand, four hundred and fifty

Or maybe you want to know what the plural of “goose” is:

Linguistics::use( :en )
# => "geese"

Or maybe we have an array of farm animals:

Linguistics::use( :en )
animals = %w{dog cow ox chicken goose goat cow dog rooster llama pig goat dog cat cat dog cow goat goose goose ox alpaca}
puts "The farm has: " + animals.en.conjunction

This will print:

The farm has: four dogs, three cows, three goats, two oxen, two geese, two cats, a chicken, a rooster, a llama, a pig, and an alpaca

You can do a lot with linguistics.

Choose your external libraries carefully, but also don’t reinvent the wheel if you can avoid it. Don’t be afraid of scrapping an entire program or salvaging good code and throwing away the rest. In my experience, programming contains its headaches – there will be failure, but there’s always a learning opportunity in failure.


Comment your code and comment it well. We’ve already seen some of this in Ruby. Commenting a single line in Ruby starts with a #. But we can also write multi-line comments by putting our text between =begin and =end.

# this is a single line comment

Multi-line comment

And another

Yet another

I frequently use single line comments for explaining what chunks of code are doing, while multi-line commenting is often useful for removing parts of code without actually deleting it. This makes debugging much easier. Be sure to use your commenting wisely by explaining what the code doesn’t tell you. When you define functions or classes or variables, it should be fairly clear what’s going on. But commenting on why you made the choices you made that will help you or another programmer better understand the code is worth including. Remember: programming should be as much about readability as it is about its functionality. Comment even if its code only you will be seeing.

Plan Ahead

I read somewhere recently that code is the crystallization of human thought (if I can find the comment, I’ll attribute it). Plan ahead in the programs you write, make sure the intent is clear, explain how you expect the code to work. Diagram! Design mockups! Some of my best tools aren’t digital: I keep a permanent marker and stack of paper handy for sketching out ideas.


Keep backups of multiple versions. Better yet, place your stuff under version control like Subversion or Github.

Additional Resources

Now that you have the basics, you might want to learn more and start creating awesome stuff for the Internet. Here are some additional resources to learn more about Ruby and other languages.

General Resources

Ruby / Ruby on Rails



Mobile App Development

Next up, we’re writing a program together. We’re going to build a word frequency generator and begin working with the web.

Visit the Rubyist Historian Table of Contents for more sections, and check out the Github repository for an archive of all the code examples.

See something that’s wrong? Examples that don’t work? Explanations that are unclear or confusing? Embarrassing typographic errors? Drop me an email at jason.heppler+feedback at gmail and I’ll fix things right up!

Topic structure, examples, and explanations for the Rubyist Historian are inspired by, credited to, and drawn from Stephen Ramsay and his course Electronic Text.

January 08, 2011 @jaheppler