One Man’s Walk in work

Of course that’s how you do it…

user.instance_eval("@password")

Every now and then you really do need to access a private variable and don’t particularly want to change the class. Especially in test code. Maybe it’s a smell, but I’d resorted to reopening classes and adding attr_accessor’s.

Moral issues aside, this is definitely a more elegant way of doing it.

Ruby is awesome…

  def test_on_weekday
    today_is "May 3, 2006" do
      calendar.add("a call").at(4.pm).on(:saturday)
 
      assert_equal(Time.local(2006, 5, 6, 16),
                 calendar.appointments.first.start)
    end
  end

…playing with code examples for our book.

It’s about freekin’ time!

It looks like sourceforge isn’t far behind, either.

I’ve been torn on every new project I’ve started on either of these sites between self hosting, and getting tons of svn happiness, or being a good oss citizen and getting out of the box standards and integration. Now I don’t have to make that decision anymore.

Go team.

*Pro tip:

*

require 'irb/completion'

irb -r irb/completion

require 'irb/completion'

"foo".rev<tab>  -->  "foo".reverse

"foo".<tab><tab>

I was totally amazed that this was already there when charles lowell showed it to me

Ever been editing a ruby script that talks to a C library and the whole damn thing crashes saying “Illegal instruction” or “Bus error” or some other such nonhelpful message, with of course, no line number.

At this point, to figure out what the hell happened, you could break out your trusty “debug by printf’ing” strategy from your C days – OR - you could cheat.

What I do is put this line in my program at any point that I know for sure still executes :

    require 'Debugger'

turning on debugger
in ./chizzle/FileTreeView.rb:
return:29
in ./chizzle/Debugger.rb:
end:1
in ./chizzle/FileTreeView.rb:
line:30
call:157
line:158
c-call:158
c-call:158

the last line that my program was at before the seg fault is the culprit, simple as that.
——The Script——
What’s really cool is how simple this was to do in ruby. I think it took me about 10 minutes to write, and has since saved me countless hours. Let’s take a look at Debugger.rb :

    class Debugger
        def Debugger.turn_on
            puts 'turning on debugger'
 
            old_filename = ''
            set_trace_func(proc {|event_name, filename, line_number, object_id, binding, class_name|
                if filename != old_filename
                    puts "in #{filename}:"
                    old_filename = filename
                end
                puts "\t#{event_name}:#{line_number}"
            })
        end
    end
 
    Debugger.turn_on

This is a pattern I first started using while working on rublog w/ Brian Marick et al. Dave Thomas gave it a better name when he checked it in, and I’ve renamed it since then. I think I like temp files. A second ago, I was working in nfit, and found myself writing it in c#. So I guess I like it.

Problem:

You want to test something that accesses files. Something that you want to do all the time for some apps.

Solution:

Create a class called !TempFiles, use it like this (for ruby):

def test_load
	files = TempFiles.new
	files.add('wiki/captions/2003_11-November_captions.txt', CONTENTS)
 
	files.create do |dir|
		captions = Captions.new(Wiki.new(dir, '/2003/11-November'), '/2003/11-November')
 
		assert_equal('Jilian', captions['apPle.JPG'])
		assert_equal('from the top', captions['bitter.jpg'])
	end
end

It can be used from any test, and makes creating a file easy. From ruby the blocks make it really nice. I often add files in the setup code, but always have the block in the actual test. The nice thing about this is it’s easy to add files in your test right before creating them.

I’ll add the c# usage tomorrow

• UPDATE *

this is now a gem called file_sandbox – sudo gem install file_sandbox – enjoy…