The interactive ruby (irb) interpreter allows ruby coders to try things out in trial ‘sandbox’. It is great for typing in a few ruby commands and get a result. For example you can just type in:

> 2 + 3
=> 5

and it gives you the result right away!

Each time you enter irb, the slate is clean. So, if you have to enter several ‘require’ commands, for example, they have to be typed in each and every time.

Fortunately, irb has a configuration file to makes things easier for you! Let’s say you are testing a new Class that you are writing. And, every time you enter irb you need to type “require ‘./my_new_class'”. You can add that line to your .irbrc file and the file will be read by irb each time you start up irb!

But the fun doesn’t stop there. You can colorize your irb! Try out the following commands in your irb. Or, better yet, just add them to your .irbrc file:

require 'rubygems'
require 'wirble'
Wirble.init
Wirble.colorize

You can also create some quick use commands by creating an alias. Here we add the following line to our .irbrc file so we can just type ‘q’ to leave irb, rather than having to type ‘exit':

alias q exit

Another cool trick you can do is to customize new methods for irb. Most rubyists already know that in irb you can ask for a list of all the methods that can be used on an object. For example, here we ask for all the methods that can be performed on a text string:

> “some text”.methods

This, of course, list ALL the methods that can be used against a string INCLUDING all the methods string inherited from object. Usually we don’t care about all those extra methods that were inherited. So we can add a method to the object class to give us methods, but not the methods from the object class. Try adding this to your .irbrc file…

class Object
  # Return only the methods not present on basic objects
  def m?
    methods = (self.methods - Object.instance_methods).sort
  end
end

Now, whenever we are in irb, we can just type:

> “some text”.m?

and we will bet back a list of methods that can be used on a string, and they will be sorted.

I hope you enjoy these tricks!

Special thanks go out to the Jeffrey Matthais at Boulder Ruby Group meeting who taught these great tricks!

On Saturday (2/8/2014), we learned about Git (http://git-scm.com/).  Git is a distributed version control system (http://en.wikipedia.org/wiki/Revision_control).

Git works with three levels of files in the process of modifying one’s files.  These three are:

1. The Working Directory
2. The Staging Area, and
3. The Respository

The Working Directory

This is where you work with your files as you are updating them.  This is on your local machine.

The Staging Area

As you work on your files (and modify them), you will eventually get to a point that you believe you have a version of the file you will want to save in the repository.  In Git, you use the ‘git add’ command to move a particular file into the Staging Area.

Normally, though, you will have a group of files that interact together.  So, you will not want to put individual files into the repository.  Rather, you will want to move the group of files that mean something together, all at once, to the repository.  An example of this would be a program module that has several objects included in the module.

Anyhow, as you ‘git add’ various files, to the Staging Area, you are getting ready to commit the group of files (or the single file, if you have only one) to the repository.

The Repository

The Repository is where all the files for your system (or whatever collection you have) are kept.  When you have your files at a point where you want to save them all you will do a ‘git commit’.  This will move the group of files (all the ones moved to the Staging Area) into the repository.  You will also give a textual label to this update to the repository so you can know what this version was all about!

There are , of course,  many more aspects of the Git system.  This article is only talking about the three levels of working files in the Git system.

I started an Advanced Ruby on Rails (RoR) class on Monday, February 3rd.  Part of our class was to create a blog so that we could share our technical knowledge.  This is the start of that.

I hope you enjoy our ride on the Rails!

Tom