This is lovely work.

Via ffffound.

[_why] is a fledgling freelance professor, one who will die young and make no lasting impression. except there was that time when i vacuumed all of Greenland for them.
bio from the blog that formerly lived at whytheluckystiff.net

Unit testing, in particular, is designed to reel in spontaneous hacking. It is like framing a picture before it has been painted. Hacking, at heart, will continue to be something of spontaneous order, something of anarchy, and the landscape of hacking is something which comes from human action but is not of human design.
From “This Hack was not properly planned,” quoted on Anarchaia

No, let’s not have rules. I don’t feel comfortable with having coding standards or any protocol on Camping. The point of Camping is to have very ugly, tricky code that goes against all the rules that people make for “beautiful” code these days. To show that ugly code can do beautiful things, maybe.

I don’t want to demonize anyone here, I just want to express the ideas that make Camping different. Camping’s personality is 80×50. It is like the little gears of a watch that are all meshed together into a tight little mind-bending machine. The challenge of Camping isn’t to figure out how to automate obfuscation. The challenge is to bring new tricks into the code that push Ruby’s parser and make everyone look twice. Not all code needs to be a factory, some of it can just be origami.

_why

From Kyle Neath’s tumblr.

Why the lucky stiff

John Resig’s eulogy to _why

I was going to wait until I had finished this book to review it, but since you only have until August 28th to buy the ebook for $9.00 from http://lulu.com, I thought I’d plug it now.

Despite having not finished the book yet, I recommend it highly, based in part upon the parts I have read so far, and in part on reviews and recommendations from folks on RailsBridge of whom I think rather highly, among others. Noel’s stated aim is to answer all test-related questions within this volume; a tall order, but it sounds like it will make for a very complete topic guide.

I have to be honest; I’m not sure how being published in a more permanent form will affect the goal of answering any and all testing questions. From Noel’s RailsRx Book page:

If you have a question about Rails testing that starts with “How do I?” or “How does that work?”, I want you to be able to find the answer in this book. If you are relatively new to testing Rails programs, and want to get placed on the right track, I want you to find help in this book. If you are a more advanced Rails programmer looking to find best practice for more specific topics, guess what — I want the answer to be in this book.

The self-publishing ebook format seems perfectly suited to this goal. If you need to change or update a chapter, you can just do it and update the PDF that will be downloaded, while also allowing those who’ve already purchased the ebook to update also. I’m not sure this is going to be possible with a traditional paper-artifact style book; you could allow free ebook updates to any who have purchased the book, but that’s not the usual model for Pragmatic (as far as I know), let alone any other publishers.

That aside–I’m sure Noel and the Pragmatic team are creative enough to find a way to keep this book fulfilling Noel’s original vision for it. As someone who has fuzzy aspirations of publishing himself, I’m very happy for Noel; all the best!

As an aside, the other ebooks I’ve been reading, for which I also hope to post a review when I’m finished, are Mike Gunderloy’s Rails Freelancing Handbook, and Rails Rescue Handbook, which are also both excellent so far.

Also, it is not my intention to start a Darth Vader image theme on the site. I just stumbled across the above image on Flickr and couldn’t resist.

The article is interesting, but I guess I’m a total geek and was a lot more interested in this 9-year old image of the dark lord of the Sith taking a Brita to the Black Sea. Go, Darth.

I wanted to add a method to a plugin we were using on a Rails app, and for the sake of keeping things separate, I didn’t want to add it directly to the plugin itself. That way, if we upgrade the plugin at some point, my additional method won’t disappear.

My solution is normally to add an initializer, like config/initializers/the_plugin.rb; so I did, and tried the following:

1
2
3
4
5
6
7

module ThePlugin
  class Base
    def my_nifty_new_method
      puts "nifty"
    end
  end
end

This is wrong! What I did (which I learned, when the application exploded after a local server restart), was open up the module for extension, and replace the Base class with a class that only had one method in it. Not what I had in mind at all.

What you should do instead is:

1
2
3
4
5

class ThePlugin::Base
  def my_nifty_new_method
    puts "nifty"
  end
end

There we go. That feels better. For those of you following along and nodding, yes, this time we just opened the class that we wanted to extend, and added a method, leaving all the other methods alone so that everything keeps working as it should.

I’ve recently started digging into script/console a little deeper. As a tool for Rails development, I think it’s safe to say that words like “indispensable” come to mind when the topic of the console arises. That said, I’ve yet to see a really complete guide to using script/console — lots and lots of collections of tips and tricks, but never a good solid guide to what’s going on with script/console.

This is the first of what will hopefully be several posts about what’s really going on when you open the rails console.

If we look at just the console script, we’ll find just these three lines:

1
2
3

#!/usr/bin/env ruby
require File.dirname(__FILE__) + '/../config/boot'
require 'commands/plugin'

The first line is simply the shebang line that lets the file be an executable ruby script. The second line requires the file config/boot. This file is a little over a hundred lines by default, so we won’t reproduce it here; you can read it quickly (if you want to) in one of your own rails projects. It basically sets some load paths and some constants, and ends by booting rails with Rails.boot!.

The third line requires commands/console… and that’s it. So to see what’s actually happening, we’ll have to look there.

You can find commands/console.rb in railties/lib in your rails directory, in vendor if you have frozen rails to a specific version, or otherwise under your rails gem in the lib directory.

(e.g., on this machine it’s in
/usr/local/lib/ruby/gems/1.8/gems/rails/lib/commands/console.rb).

console.rb looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

irb = RUBY_PLATFORM =~ /(:?mswin|mingw)/ ? 'irb.bat' : 'irb'
 
require 'optparse'
 
options = { :sandbox => false, :irb => irb }
OptionParser.new do |opt|
  opt.banner = "Usage: console [environment] [options]"
  opt.on('-s', '--sandbox', 'Rollback database modifications on exit.') { |v| options[:sandbox] = v }
  opt.on("--irb=[#{irb}]", 'Invoke a different irb.') { |v| options[:irb] = v }
  opt.on("--debugger", 'Enable ruby-debugging for the console.') { |v| options[:debugger] = v }
  opt.parse!(ARGV)
end
 
libs =  " -r irb/completion"
libs < < %( -r "#{RAILS_ROOT}/config/environment")
libs << " -r console_app"
libs << " -r console_sandbox" if options[:sandbox]
libs << " -r console_with_helpers"
 
if options[:debugger]
  begin
    require 'ruby-debug'
    libs << " -r ruby-debug"
    puts "=> Debugger enabled"
  rescue Exception
    puts "You need to install ruby-debug to run the console in debugging mode. With gems, use 'gem install ruby-debug'"
    exit
  end
end
 
ENV['RAILS_ENV'] = case ARGV.first
  when "p"; "production"
  when "d"; "development"
  when "t"; "test"
  else
    ARGV.first || ENV['RAILS_ENV'] || 'development'
end
 
if options[:sandbox]
  puts "Loading #{ENV['RAILS_ENV']} environment in sandbox (Rails #{Rails.version})"
  puts "Any modifications you make will be rolled back on exit"
else
  puts "Loading #{ENV['RAILS_ENV']} environment (Rails #{Rails.version})"
end
exec "#{options[:irb]} #{libs} --simple-prompt"

There’s a fair bit in there, so let’s look at what it’s doing in detail.

Line 1 is setting a local variable named irb. It checks to see if the constant RAILS_PLATFORM matches a value that would indicate we’re using some flavor of Microsoft Windows; if we are, it sets irb to irb.bat, which is what irb will be named for a Windows build of ruby; otherwise it’s set to simply irb, which is the commands name on *nix systems, including Mac OS X.

Next it requires ‘optparse’. optparse is a Ruby library for parsing options (I imagine you guessed that).

Then a local variable named options is created, and is given a few default parameters: :sandbox is set to false (more on this in a moment), and :irb is set to the local variable irb (in other words, to either ‘irb.bat’ or ‘irb’, depending on the result of the expression on line 1).

An OptionsParser object is created next. We won’t dive into the details of this, but you’ll note a striking similarity to what you see in this block and what you’ll see if you type script/console -h in your rails root.

So if we follow along, we’ll read about the three standard command line arguments we can use when firing up the console:

--sandbox, which just adds the feature that any changes you make to the database will be undone at the end of your console session
--irb, which allows you to choose a different version of irb if applicable; so, if you have Ruby 1.9 installed, but not set as your default ruby version, you could start up the console with script/console --irb=irb1.9, and see how your console experiments work with Ruby 1.9.
--debugger, which enables ruby debugging.

Next a local variable named libs is created; it’s a string, and a number of lines are concatenated to it, each in the form ” -r [some library or module]“. The libs variable is eventually going to be passed to irb when the console starts it; the -r switch to irb simple requires whatever the next argument is. So this is simply building a list of the modules and libraries which are going to be present when the console is fired up.

The next section handles the case where you have actually typed script/console --debugger; it tries to require ruby-debug, and if an exception is raised, it will helpfully suggest that you run gem install ruby-debug.

On line 31, console sets the environment; it looks at your first argument to see if you tried to specify an environment, and if not, sets it to either ARGV.first (the first argument, if applicable), ENV['RAILS_ENV'] (whatever the environment is already set to), or as a last resort to ‘development‘ (which is probably what you want, most of the time, hence why you may only rarely use this feature).

If you try this by typing script/console foo, you’ll see that console will try (and fail, unless you’ve created a foo environment) to find the file /config/environments/foo.rb. So as long as the environment you specify exists, the console will use it.

Now, since it’s using ARGV.first, you might ask yourself why, if you type script/console --sandbox, the console does not try to load the “--sandbox” environment. Good question! The answer can be found up in line 11: opt.parse!(ARGV). The parse! method parses destructively; it pulls any valid options out of ARGV, and then returns whatever’s left over. So if ARGV started out as "test --sandbox --irb=irb1.9", after opts.parse!(ARGV) it will just equal "test". If nothing but valid options were supplied (i.e., no attempt to specify an environment), ARGV would be an empty string, and the environment will be set to either ENV['RAILS_ENV'], if it exists, or to 'development' if it doesn't.

So now console's figured out which environment to use, it checks to see if you've specified the sandbox option, and if you have, it prints a friendly message to remind you that anything you do to the database will be undone when you exit the console.

But wait, you might say. Other than print a message, it doesn't do anything; what actually makes the sandbox/database rollback work? Good question. If you look back up at lines 14-18, where the libs variable is set, you'll note that console_sandbox is required, but only if options[:sandbox] returns true. console_sandbox will take care of all that database rollback headache for us; so that's where it will come from.

There's only one line left: an exec expression. exec is going to execute the string you pass to it on the command line. So a plain vanilla run of script/console is actually running:

1

irb -r irb/completion -r ~/your_rails_project_path/config/environment -r console_app -r console_with_helpers --simple_prompt

If you really want to, you could just type all that every time you want to use the console, but I'm guessing you'll stick with script/console.

If you're thinking there must be a little more to it than this, you're right; you'll remember that when libs was created, the modules console_app and console_with_helpers were required. That may be what I write about next, but in the meantime, if you have Rails installed you can always just open those files up and see what's in them.

One of the hallmarks of object oriented programming in most every implementation of it that I know of is the ability to designate certain methods as “private” or “protected”, thus keeping them from being called willy-nilly by any old script that wants to call them. Ruby also has this, of course, but interestingly enough it can be easily circumvented.

I guess there are a few posts floating around about it, but I discovered it by accident playing around in irb this evening. I was reading David A. Black’s The Well Grounded Rubyist, where he mentions that you could send a message to a class either within the class definition itself, or by simply sending it to the class object like you’d send any other message:

1
2
3
4
5
6
7

# The normal way to do it
class Thing
  message :whatever
end
 
# you could also do this
Thing.message(:whatever)

David mention’s attr_accessor in this context, so I thought I’d try that. Open irb:

1
2
3
4

>> class Thing
?> end
>> Thing.attr_accessor :name
NoMethodError: private method 'attr_accessor' called for Thing:Class

Oh. So much for that, then. But, knowing of the existence of the send method, I thought I’d try that.

1
2

Thing.send(:attr_accessor, :name)
=> nil

For the non-irb user, that nil that was returned, and the fact that no error message was returned, indicated that our experiment worked. Now Thing’s have a name attribute.

1
2
3
4
5

>> t = Thing.new
>> t.name = "Larry"
=> "Larry"
>> t.name
=> "Larry"

What’s interesting about all this is that attr_accessor is a private method on Class. Yet we just called it.

send is often introduced as a way to show how everything is an object and that you can do exciting things like 1.send(:+, 1) and get 2 as the result. No one usually mentions that it can be used to call private or protected methods from outside a given class.

To make it clear what you could do here:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

>> class Thing
?>    def hello
?>     puts "Hello, world!"
?>   end
?>   private
?>     def private_hello
?>       puts "Hello, privately."
?>     end
?> end
>> t = Thing.new
>> t.hello
Hello, world!
=> nil
>> t.private_hello
NoMethodError: private method 'private_hello' called for ...
>> t.send(:private_hello)
Hello, privately.
=> nil

So, yes. You can do this, if you so choose. Please use your powers for good, and not for evil.

Now why this works, I can’t yet say, though I’m interested in learning, if there is a reason. Evidently there may have been some debate as to whether ruby 1.9 would still have this behavior, but as of this writing it does.

Note: I did only a brief search, and it seems this functionality is not unknown, though it still seems somewhat odd to me that such an easy way to sidestep the private/protected designation of methods exists.

I’m at http://blip.fm/philcrissman, if you like that sort of thing.

Making the web more delicious: Scripty2

Mark is an old friend of mine; good to see he’s still doing music.