In this hour-long episode, I switch from integration testing to unit testing in order to drive out some more features for the Sinatra-based web service I’ve been building. You’ll see me:

• Use the “hub” gem to interact with GitHub.
• Talk about the decision point to drop from integration to unit testing.
• Use IO.popen to pipe text through an external process.
• Isolate tests for filesystem interaction using simple dependency injection.
• Use Enumerable#each_cons and enumerators to identify a sub-sequence in an Array.
• Use the Pathname standard library.
• …and more!

Did you miss part 1? Get it now:

Only nerds even know what an underscore is. What’s the first thing I have to teach people who are brand new to programming? What the hell an underscore is, and where to find it on the keyboard. No, not that line. The other line. Hold down shift. There you go.

Underscores require me to hit the Shift key. When writing prose, I only hit the shift once or twice per sentence.  In Ruby, I have to hit the shift key every few letters. Awkward. Inefficient.

I’ve been thinking about rebinding the dash key to underscore in Emacs ruby-mode. It’s stupid that I’m even considering such a thing.

Underscores are visually ambiguous. When the font is underlined for some reason, the underscores get muddled up with the underlining. In badly-rendered text boxes it’s not always clear where the underscore leaves off and the bottom border begins.

CamelCase is no better. I still have to hit Shift all the time. Plus it relies on a peculiarity of the Latin family of languages.

Lisp gets it right. Lisp S-expressions have one basic rule that vastly simplifies the syntax: whitespace separates tokens. Always.

This means that “foo - bar” parses out to the three tokens “foo”, “-”, “bar”. Whereas “foo-bar” is a single token that happens to have a dash in the middle. That’s right, your tokens can have dashes in the middle. Ordinary, easy-to-type, recognizable, visually unambiguous dashes. Lisp functions have names like:

find-file

All you have give up for this is tightly-packed arithmetic statements, like this:

5*5-3

Instead, you have to give your tokens some breathing room:

5 * 5 - 3

That’s a trade-off I’ll gladly make if it means using dashed identifiers instead of underscores.

I mostly code in Ruby these days, and I love almost every aspect of its very rich syntax. But I hate all the snake_casing. I want a Ruby that lets me use dashes in identifiers. If I never type another underscore, it will be too soon.

UPDATE: The Recursive blog points out that Japanese keyboards may be more comfortable for typing Ruby.

And of course you can do this entirely by convention, by simply being careful to interact only with the methods you’ve explicitly exposed. But it’s easy to forget these conventions in the heat of implementation, gradually coupling the rest of the program to more and more framework-provided methods until one day you discover that your object’s interface surface area has become quite large indeed.

As an exercise in mindfully limiting the interface exposed by objects and classes, in Objects on Rails I demonstrated a tool called “FigLeaf“. FigLeaf gives you something akin to the “private inheritance” found in some other OO languages. While it doesn’t actually hide the fact that a class is derived from a framework class, it enables you to selectively privatize some, most, or all methods derived from ancestor classes and modules.

Here’s an example from the readme

class Post < ActiveRecord::Base
  include FigLeaf
  hide ActiveRecord::Base, ancestors: true,
       except: [Object, :init_with, :new_record?, 
                :errors, :valid?, :save]
  hide_singletons ActiveRecord::Calculations, 
                  ActiveRecord::FinderMethods,
                  ActiveRecord::Relation
  # ...

And here’s what happens when we try to send class or instance-level messages which have been hidden by FigLeaf

ruby-1.9.2-p0 > Post.find(1)
NoMethodError: private method `find' called for #<Class:0xa1a4a50>

ruby-1.9.2-p0 > Post.new.destroy
NoMethodError: Attempt to call private method

Today I’m happy to announce that thanks to the dilligent efforts of Sammy Larbi, FigLeaf is now available as a RubyGem. You can install it with:

gem install fig_leaf

The project is also available on GitHub.

It’s important to note that FigLeaf is not intended as a hammer to keep your coworkers or your library clients in line. It’s not as if that would work, anyway; the strictures that it adds are easy enough to circumvent. Instead, it’s intended role is more along the lines of the “rumble strips” along highways which give you a jolt when you veer off into the shoulder. It provides a sharp reminder when you’ve unthinkingly introduced a new bit of coupling to an interface you are trying to keep isolated from the rest of the codebase. Then, you can consciously make the decision whether to make that method public, or find a different way of going about what you were doing.

Got questions or suggestions about FigLeaf or about OO practices in general? Please join us on the Objects on Rails discussion list!

[do you know of] a Ruby idiom for converting an object to a type if it isn’t already that type. For example, if you want to only store an attribute of type Foo, you could write an accessor method that would pass any non-Foo object to Foo’s constructor.

There is a de facto idiom among Ruby built-ins to define a method with the same name as a class for doing conversions to that class. My favorite is Kernel#Array:

Array("foo")                    # => ["foo"]
Array([1,2,3])                  # => [1, 2, 3]
Array(nil)                      # => []
Array({:a => 1, :b => 2})       # => [[:a, 1], [:b, 2]]

But there are others. Kernel#Integer provides a stricter form of integer conversion than does #to_i:

"42".to_i                       # => 42
Integer("42")                   # => 42
"30 seconds".to_i               # => 30
Integer("30 seconds")           # =>
# ~> -:4:in `Integer': invalid value for Integer(): "30 seconds" (ArgumentError)
# ~> from -:4:in `<main>'

And there are also Kernel#String, Kernel#Float, Kernel#Complex, and Kernel#Rational:

String(123)                     # => "123"
Float("123")                    # => 123.0
Rational(4,5)                   # => (4/5)
Complex(1,3)                    # => (1+3i)

You can also find this in standard libraries. The URI library defines an idempotent conversion method for URIs:

require 'uri'

u = URI("http://example.com")   # => #<URI::HTTP:0x000000030cac80 URL:http://example.com>
URI(u)                          # => #<URI::HTTP:0x000000030cac80 URL:http://example.com>

There’s also Pathname:

require 'pathname'

p = Pathname("~/.emacs.d")      # => #<Pathname:~/.emacs.d>
Pathname(p)                     # => #<Pathname:~/.emacs.d>

I like to extend this idiom into my own code for idempotent conversions into commonly-used value objects. I did this in Objects on Rails for TagList objects.

module Conversions
  private
  def TagList(value)
    return value if value.is_a?(TagList)
    TagList.new(value)
  end
end

The TagList method is shorter than calling TagList.new(...). And in addition, it’s safe to call on inputs which might or might not already be TagList objects.

Although they may look a little odd at first, capitalized conversion methods are a well-established Ruby idiom for methods which “do the right thing” to convery any reasonable input value into a desired class. And because unlike #to_x methods they are outside of the objects being converted, they incur none of the maintenance danger of a monkey-patch. I don’t define them for every class in my program; but for oft-used value object types they can be quite convenient.

All of these offer a pretty similar service: you download a command-line tool (often in the form of a Ruby gem), start up your server, run the command, and hey presto, your local pages served on localhost:3000 are now being served at http://yoursubdomain.example.com. Most, if not all, use SSH tunneling as the underlying technology.

• Showoff.io: 5m free, $1 for a day pass, otherwise $5/mo unlimited.
• Pagekite: Features transparent SSL support and unlimited subdomains. $5/mo for a basic plan. EDIT: Looks like they also provide a Debian/Ubuntu package source, nice touch! EDIT2: PageKite informs me that their service is as low as $3/mo for an individual, and that they do not use SSH as their underlying tunnel in order to be friendlier to Windows users.
• Localtunnel: Free, sponsored by Twilio. Looks similar to Showoff.io.
• Tunnlr: Explicitly marketed to FB developers. $5/mo for a single subdomain (notice a trend?)
• ProxyLocal: Free, appears very similar to Showoff.io, LocalTunnel, etc.

Since then I’ve been working on editing the video in my spare time, and I’m happy to announce that today part 1, (“Zero to Heroku”), is ready and available.

This video series is a raw, over-the-shoulder look at my solo development process. I narrate what I’m doing and thinking as I work, and occasionally I digress to explain why I’m making a particular decision. I’ve tried to edit out the really long pauses. But you’ll still hear a lot of “hm, what next?”.

In this first hour-long video I take the app from an empty directory up through a successful “tracer bullet” deployed to Heroku. Along the way, you’ll watch me:

• Start with nothing but a failing integration test.
• Use IO.popen to call out to Perl from Ruby.
• Set up Guard to automate my tests and Bundler updates.
• Use Hub and Magit to simplify working with Git and GitHub.
• TDD a simple Sinatra service using RSpec and rack-test.
• Create a Heroku app.
• Create a Rackup file and deploy to Heroku.

Sound interesting? It’s yours for $5.

$5.00

Over the coming weeks I’ll be releasing the rest of the series. I have all the video, I just need to edit it. In upcoming episodes you can expect to see:

• Refactoring the Sinatra app from a “classic” app to a “modular” style app.
• Switching to Unit Tests as method logic increases in complexity.
• Adding more cowsay features.
• Smoothly migrating from a Sinatra app to a Rails app that mounts the Sinatra app as a service.
• Using Datamapper for persistence.
• Using Erector for object-oriented views.
• Using Coffeescript and jQuery to liven up the UI.

Myron Marston has done a stellar job shepherding it through the Rails 3 transition, but he’s busy with other awesome projects now and has asked me to look for a new maintainer. So: If you’re interested in helping keep NullDB up to date with the latest changes to ActiveRecord, please get in touch!

• Part 1: Backticks and system()
• Part 2: Opening pipes to processes
• Part 3: Open3, PTY, and Shell standard libraries

However, those were all written for Ruby 1.8, and are a little out of date.

Ruby 1.9 substantially expanded and revamped the Ruby process API. Many of the tasks which once required third-party gems like Open4 can now be easily accomplished using the built-in calls. Particularly notable is that Process.spawn was added with a comprehensive set of options for customizing how the process is started, and the other standard process-starting calls were updated to accept the same set of arguments as Process.spawn.

Here’s how www.cowsays.com starts a Perl process in order to generate ASCII-art cows:

cowsay_path = Pathname(__FILE__).dirname + "../bin/cowsay"
perl_path   = "/usr/bin/perl"
cows_path   = Pathname(__FILE__).dirname + "cowsay/cows"
env         = {
  'COWPATH' => cows_path.to_s
}
args        = %W[-f #{@cowfile}]
@io.popen([env, perl_path, cowsay_path.to_s, *args], 'r+') do
  |process|
  process.write(message)
  process.close_write
  process.read
end

Notes:

• Since I know where Perl is found on Heroku boxes, I hardcode the path to it. Unless you have a specific reason for allowing program paths to be overridden, it’s always safer to hardcode the path to executables. That’s one less vector for attacks.
• @io simply points to the IO class in production. It’s an instance variable so I can write isolated unit tests verifying how my code interacts with the system.
• IO.popen starts a process and creates a pipe to that process, which your program can use to send data into that process’ STDIN, and read data from its STDOUT.
• I pass an array instead of a string to IO.popen. If you pass a string, Ruby will start up a shell process and pass the string to the shell for interpretation. This is handy for commands like ls -l *.rb where you want standard shell-expansion to be performed. It’s also very dangerous when dealing with user-supplied data; it opens up a door for shell-injection attacks similar to SQL injection exploits. Only shell-injection is even more dangerous, since a shell injection can potentially execute any command that your server process has the rights to execute.
• The array version, by contrast, skips the shell. The arguments are passed directly to the process as strings in it the ARGV variable. This version is always my preference unless I have a specific reason to want to do shell expansion. This is also why I avoid backticks (`some-command ...`) or %x() except in little personal-use scripts.
• I make use of another feature of IO.popen, Process.spawn and friends: I customize the environment variables the process will see by passing a hash as the first argument. I want more Ruby programmers to know about this feature; I sometimes see code which accomplishes this effect by setting ENV['somevar'] before spawning a process and then re-setting it afterwards. Passing a hash is much cleaner.
• Note that by default, only the hash keys specified in the environment hash will be changed for the subprocess; the rest will be copied from the current environment. There’s an option, however, to use the hash as a complete replacement for the current environment. See the IO.spawn documentation for details.
• I pass r+ as the “file mode” argument. This tells Ruby I want to read from and write to the child process. The default is read-only.
• Note the line where I call process.close_write. This is very important, and something which bites a lot of first-time users of popen (it sure used to bite me!). With many programs, if you don’t explicitly close the pipe for writing after finishing your write, you’ll wait forever trying to read the program’s output. This is because the program being executed as a subprocess was written to read its input up to EOF before outputting and exiting. And it won’t get that EOF until you close the pipe for writing. In addition, the operating system may buffer the data flowing from your program to the subprocess, and calling .close_write forces that buffer to be flushed.

I hope you’ve learned something new about starting processes in Ruby from this post. If you have any process tips of your own, or any burning questions about spawning processes, feel free to bring them up in the comments!

By the way, if you’re interested in finding out more about working with UNIX processes in Ruby, the Ruby Rogues book club is currently reading Jesse Storimer’s book on the subject.

cowsay "Quack"

 _______
< Quack >
 -------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

In fact, I like it so much I wanted to share it with people who might not have had a chance to try it yet. So I put it on the web.

Enjoy it for all of your ASCII-animal speech-bubble needs. The source code is on GitHub if you’re curious. Interesting implementation notes:

• It was written from scratch starting last Saturday night and then over part of last Sunday.
• The original Cowsay program, written in Perl, is included in the app. I use IO.popen to open a Perl process and generate the ASCII art.
• I started with a simple Sinatra service. Then I added Rails in, and mounted the Sinatra service in the routes file.
• I use Erector for views, and DataMapper for persistence (what little there is).