bl.ogtastic - Home

Nashville Hi-Lites for the Ruby Hoedown

2009-07-17T18:58:00Z

Seeing as how Nashvegas is the venue for this year’s Ruby Hoedown, and it’s OGC’s hometown, we thought we’d jot down some notes to help our Hoedown homies make the best of their time in NV. So, without further ado, here’s the cream of the crop:

UPDATED: No list is complete without coffee shops! Also added a couple other random bits.

Greenways

The Nashville Greenways system provides walkable and bikeable paved trails connecting many parts of downtown. There are greenways that pass near the Opryland Hotel and connect with downtown Nashville. Greenways map

Entertainment / Events

Pair Programming w/ NashDL & OGC – if you’re in town during the pre-Hoedown week and want to get together to do some pair programming with peeps from the Nashville’s Dynamic Languages Group and/or OG Consulting, drop a line to ogc@ogtastic.com or sign on to #nashdl on freenode. There may even be the possibility of during-the-week accommodations for a person or few.
Thursday night, if history is any guide, a monthly free-beer mixer at Centre{source}, a local web shop, prime for conversion to the Ruby Way. Details as they emerge.
Friday night Hoedown party: Jeremy will have details forthcoming…
Saturday night OGC-hosted party: Free beer, live music, dead music, yard games, rubyists, anarchists, etc. Details forthcoming.
Cheatham County Fair demolition derby - tentatively, Thursday night, $6 fair admission unless they’ve changed ticket prices
Wilson County Fair demolition derby - Friday and Saturday night
Wednesday night Old Time Jam at the 5 Spot . If you are a musician and are in town on Wednesday night, you MUST be here with your instrument(s).
The Belcourt Theater - good independent theater down in Hillsboro Village; everything from art films to independent films to classic westerns; have a beer at your seat.

Music

The Station Inn - bad-ass bluegrass, all shows.
The Wildhorse Saloon - Charlie Daniels Band (thur.), 38 Special (fri.). I’m just sayin’.
The Grand Ol’ Opry - near the hotel; shows every Friday and Saturday night
3rd and Lindsley - Some great acts turn up here quite frequently.
The End - one of Nashville’s many non-Country venues. Everyone and their punk-rock grandma has played here.
The Exit/In - Another storied (and even famous) non-Country venue, check their calendar.
The Bluebird Cafe - Famous for breaking in new stars. Always good music.
Be sure to check the Nashville Scene calendar and the Nashville Metromix calendar
honky tonkin’. (You probably won’t be sad if you start at Robert’s.)

Food

The Loveless Cafe - them’s some good-ass biscuits.
Woodland’s Vegetarian Indian Cuisine
Eastside Fish - aka, “The Crunkest Fish in Town”. Brave “the King Fish”.
Rotier’s - classic Meat & 3.
Las Paletas - excellent Mexican popsicles… you might also find them at Bongo Java, Fido’s and a few other random locales.
Monell’s - sit-down-pass-the-biscuits Southern style dining.
Mary’s Open Pit BBQ - mmmmmm. Open way late, cures what ails ya: like eatin’ a smoked rack of ‘tussin.
Jack’s BBQ - the Trinity Lane location is the bomb, but the lower Broadway location is prime.
The Hermitage Cafe - Wow, you must be out late drinking.
Southstreet - Parking may be tight but the pulled pork is solid. Front page of lunch menu changes daily, set nightly menu. Open air seating in nice weather, upstairs and downstairs bar.
Jamaica Way - good Jamaican food in the Farmer’s Market (see also Bicentennial Mall)
Princes Hot Chicken Shack / 123 Ewing Drive / Nashville, TN 37027 / 615-226-9442
Bolton’s Spicy Chicken & Fish / 624 Main Street / Nashville, TN 37206 / 615-254-8015

Boozing

lower Broadway
The Broadway Brewhouse - great selection of beers, multiple locations, good jukebox, wifi; the midtown location is considered by some to be the best bar in Nashville
The Flying Saucer - huge beer selection, wifi, worth a visit
The Villager Pub - great bar, great jukebox, great darts bar, so smoky you will throw away your clothes. Free dog bowl of beer on your birthday. You’re in luck if Kevin is tending bar.
The Springwater - the consummate dive bar
The Family Wash - East Nashville. Donald Ball recommends the “Pint & Pie”
Bosco’s - high octane local microbrews in Hillsboro Village. Start here and stumble to the Villager.
Blackstone - another local brewpub with pretty good food to boot.
Yazoo - Nashville’s answer to Sierra Nevada? Regardless, hanging out in their tap room is a good time. Limited hours.
12 South Taproom - Good beer selection, great front patio, good food, great live music. Within walking distance of the 12th South Portland Brew and Frothy Monkey.
3 Crow Bar - Great East Nashville bar, food, pints, open air, convenient to many of the “5 points” attractions. See also the 5 Spot.

Coffee Shops

Fido - High-traffic Hillsboro Village coffee shop (see also, Bosco’s and the Villager). Great food for a coffee shop, part of the Bongo Java empire, hence pretty good coffee. A few beer selections, but for real beer walk across the street. Good wifi, but power outlets are very scarce (laptop row up front and a couple near the back entrance).
Frothy Monkey - Great 12 South coffee shop, good food, good coffee, good wifi, nice atmosphere, nice deck.
J-J’s Market and Cafe - A NashDL favorite. Good coffee, great tea selection, impressive beer selection. Wifi is good but can get slow if there are a lot of college students hanging out. Within crawling distance of the Broadway Brewhouse and a bevy of decent Vanderbilt-area restaurants.
Bongo Java - Decent food, good coffee, ok wifi, a popular place to hang out. NashDL does Saturday morning brunches here (when there’s no Hoedown to compete with).
Portland Brew - 3 locations:
- 12th South - Had been under some renovations, but worth checking out – very popular, good coffee, good wifi, may have some food these days. Convenient to various attractions on 12 South.
- Murphy Road/West End - Small, good coffee, good wifi, not much in the way of food. A good pre- (or post-) Woodland’s stop.
- East Nashville - this is a two-story affair, fairly new, across the street from Ugly Mugs, and near some decent East Nashville eats.
Ugly Mugs - close to the Portland Brew East Nashville location, good wifi, good coffee.
Cafe Coco - 24 hours, also has a front deck and back room. Coffee, teas, beer on tap, food. Wifi has been known to be spotty, but a lively locale with a diverse crowd. Your best late night bet.
Crema - Small, but the coffee is excellent, decent snacks, and great wifi.
Dunn Brothers - Downtown, limited hours, but great food, coffee, and wifi. A really good environment if you can catch them when they’re open.

Attractions

The Frist Center for the Visual Arts - Nashville’s art museum.
The Parthenon - if you’ve never seen this, you must. Significant contributor to Nashville’s high national “WTF” ranking.
The Country Music Hall of Fame and Museum - Twang.
The Ryman Auditorium - Historic venue, and a great, if expensive, place to see a show.
Bicentennial Mall - outdoor craziness including fountains, capitol, railroad bridge, a Tennessee you can walk on, push the big stone globe, Art Bell-era “spaceship landing zone”, etc.; near the Farmer’s Market
Dragon Park - aka “Fannie Mae Dees Park”, a nice park near Hillsboro Village (aka coffee, beer, food, fun) with an awesome dragon covered in mosaic tile.
Dagohir weirdos in Elmington Park on saturday morning.

Outdoors

Two Rivers Park (frisbee golf, skate/bmx park, wave pool), not far from the hotel
Natchez Trace Parkway - 444 mile road, starting at the Loveless Cafe and ending in deep Mississippi. Nice drive, bicycling (you can rent a bike at the Loveless Cafe), hiking, views off a gorge bridge, etc.
Radnor Lake - great hiking, you will probably need a car
Warner Parks - great hiking, near Loveless Cafe, you will need a car
Beaman Park - great hiking, you will need a car
Bells Bend - great hiking/walking, you will need a car

Can Has: Better Mirroring to the Git Hubs?

2009-04-09T23:35:00Z

Some time ago, Rick worked out this slightly wacky scheme to handle our git repos, with backups and mirrors and suchlike. After much prodding from me, he posted about it, accompanied by just one quite-wacky picture and a lot of code-like content.

He’s no Giles Bowkett.

To help people out, we keep pushing this kind of mirroring scheme upon them when they even come close to asking about handling git repos, and we do it for their own good. We went through some headaches, we suffered from reliability and stability issues, and we wrote down some simple steps to follow and get your mirroring up and running. The problem was that each new repository created required some manual work to get the mirroring set up.

But no more! Mr. Damien Lebrun (dinoboff on github) left a comment on that old post telling us he had come to save the day with his Python skills and desire to scratch an itch.

Now all you have to do put something like this in your gitosis.conf:

[repo freshtrack]
mirrors = git@github.com:flogic/freshtrack.git

If you do that, it Just Works™. Well, it Just Works™ if you let Damien’s new gitosis create the repo using its fancy template with its special post-receive hook. If the repository already exists on your gitosis host, you’ll have to handle any hook placement yourself. Damien said as much in his comment, and it’s really obvious anyway, but that didn’t stop me from spending ten minutes trying to figure out why the mirroring wasn’t working.

And it gets even better! Prompted by a question from me (or quite possibly something he was going to do anyway), he made it simple to set the mirror on multiple repositories at once. Check this out from my own gitosis.conf:

[mirror ymendel-github]
repos = dugdale flac2mp3 fsevents graphtunes markov music_conversion_observer one_inch_punch pj punch_widget truthy pj_talk truthy_talk
uri = git@github.com:ymendel/%s.git

It’s really that simple. No more logging in to the gitosis host and futzing with repositories. (At least not once you futz with the ones that are already there. Deal with it.)

To Damien Lebrun, a git-mirroring hero. Check out his fork of gitosis for more information, and especially check out the example configuration.

Update 2009-04-12 Damien just sent word that the repetition in the group and mirror sections can be reduced with the brand-new repo aliases. Check out the example mirror config (and pay attention to the lines involving “public” and “@public”.

A Long Way Around (for little to no gain)

2009-02-24T07:51:00Z

Am I the only one that gets miffed trying to read gists without wordwrap? The answer is probably Yes but that's not the point. Here at OG we opt to use gists instead of the ubiquitous Google Docs for editing everything from our bylaws to t-shirt orders. This is serious stuff. And unfortunately, I don't have a Kindle to better my reading experience.

The point is that I usually click the raw link, cut and paste into TextEdit and proceed to read with wordwrap. Ugh. It feels like someone tossed a bag of frozen peas at my 21st digit...

The first pass of this used appscript to open the contents in TextEdit after automating the downloading of the raw content. But then I found out about qlmanage, the hidden, unsupported Quick Look simulator/debugger in Leopard. So of course, I used it instead! Achtung baby!

To quote "Lonesome" Dave Peverett,

I feel good. I feel alright!

A day with an outsider

2009-01-19T17:11:00Z

We’re kind-hearted people here at OGC. Sometimes we take in strays. Rick can tell you about his dog if you ask, and I’ve fostered more cats than I care to deal with again (3 or thereabouts). So when our neighborly friend Mr. Jeremy McAnally heard that his buddy Ryan wanted to try his hand at a Corey Haines-esque pairing tour, he naturally thought of ~~foisting Ryan off on~~ recommending him to us.

After some e-mail back-and-forth, we settled on a date for Ryan to come up and spend a day in the OGC lair. It kind of sucked because it made me get up and out of the house and seeing my esteemed partners and colleagues earlier than my norm, and it was also the day I finally killed my car, but other than that it was a very good day. Ryan has his take of the day’s events up, but I thought I’d try to put forth my own.

We met at Kevin’s a little early to talk over some final ideas while waiting on Ryan to show up, as he promptly did at our agreed-upon time of 10am. Then we went over the overview of what we’d be working on, including a bit of history of the people involved, where our data model came from, why we’re focusing on one particular part of the app to start it up. From there, we looked at the stories we’d collected, split into two pairs (I got Ryan to start), and got to work.

It may have felt to Ryan like he was slowing me down, but as I explained to him, sometimes being slowed down is a good thing. In my mind, one of the primary benefits of practices like writing stories, BDD, and pairing is that they slow you down and make you think about what you’re doing. They give you the time to design and code better. Paradoxironically, they speed you up by slowing you down.

And all the stuff he said he learned, I told him that our first 3-2-1 taught us much of the same. Just watching someone else with different practices, different knowledge, different ideas — there’s so much you can pick up. Actually getting to work with a person like that? Forget about it. And packing that into an intense day (or few) instead of just making it an every-now-and-then thing? Oh man.

As a three-man team, we have some mathematic disadvantage when it comes to constant and vigilant pairing. We also have other interests and personal lives that have us in a fairly common situation of developing separately but together, off in our own coding worlds with communication through various electronic means. It doesn’t have the same benefits of in-person pairing, as we’re reminded when we do get together and smack down a bunch of stories while talking to each other. It’s nice to carve out time and get into that groove.

Anyone else want a piece of this? Come on up. We’d like to have you. Just keep in mind that Ryan’s set a precedent of the guest paying for lunch.

Update: They say good news travels fast. Two local programmers have contacted us about pairing opportunities. Also, we’re working on a follow-up pairing session with Ryan in the next month or two. That, or he wants to kidnap my dog! –Kevin

RubyConf, with extra Epcot action

2008-11-10T15:51:00Z

Another RubyConf has come and gone, and nothing really makes a conference special like driving over 10 hours in each direction. That wasn’t my specific experience because I had some other engagements that turned the trip into a Houston/Austin/Orlando flying junket, but the other two guys can tell you all about it. The drive back started with breakfast at the most amazing McDonald’s we’ve ever seen, possibly the most amazing in existence. It’s a shame we didn’t think to get proof of the crazy.

But there’s more to a conference than the travel, like staying at a resort hotel with a lazy river. And drinking beer while having testing-related conversations with wonderful members of the community. And racing go karts.

There were also talks, of course. I was on the roster as part of the “Two Turntables and a Git Repo” talk, which went swimmingly. Mr. Ben Bleything and I apparently know how to please a crowd, and I like to think maybe they actually learned something as well. This time I’m not going to bother putting up my slides on slideshare because they don’t make a lot of sense without me and without the music. Confreaks were there, so the video will do the subject more justice.

Anyway, you really want to see the video of Aaron Patterson and John Barnette presenting about Johnson.

Agile Elsewhere: github inline editing

2008-10-23T14:34:00Z

If I recall, this feature was released back in August so I'm a little late in heaping my praise gravy on the Thanksgiving turkey that is the github crew. But this is the first time I had the need to use it. I noticed some formatting for the README.rdoc in my project was b0rked.

I clicked the little edit link. Made my changes. Added a commit message. Hit the Commit button. Voila! And all on one page. Easy as cake!

Talk about agile!

OGC electioneering adds yard signs!

2008-10-21T16:41:00Z

Ready for the election to be over? Enlightened about your once and future disenfranchisement? Need more fun than getting cranked up on Olde English and driving over the McBama signs in your neighbors’ yards?

OGC, as always, is here to help.

Exercise your First Amendment rights as a fifth-year senior in the elecotral college with our brand-spankin’-new “I’ll Vote When I’m Dead” Yard Signs:

Get ‘em now!

And remember: the bottom of the boot always looks the same!

Orlando (or close enough) or bust

2008-10-20T18:05:00Z

The OGs will be out in force at RubyConf 2008 in sunny near-Orlando, Florida. Kevin and Rick will be attending, hacking, heckling, and possibly giving away fabulous prizes. Yossef (that’s me) will be giving a talk along with Mr. Ben Bleything and the inimitable (I’d like to see you try) Giles Bowkett about music generation and manipulation.

Come see us. We’ll chat. Maybe we’ll get you a beer.

non-auto spec

2008-10-09T02:45:00Z

I've been resisting updating a few gems because I either don't want the changes or simply don't know what to think about them. Today, however, I decided to get up-to-date on almost everything, and so I went for RSpec 1.1.8. Before this, I was running 1.1.4, and the change I was unsure about involved the autospec command. From the changelog:

IMPORTANT: use ‘script/autospec’ (or just ‘autospec’ if you have the rspec gem installed) instead of ‘autotest’. We changed the way autotest discovers rspec so the autotest executable won‘t automatically load rspec anymore. This allows rspec to live side by side other spec frameworks without always co-opting autotest through autotest‘s discovery mechanism.

I ignore this at first because that's just the way I am, and no tests are run. So I try autospec, and still no tests are run. I managed to track it down to an addition from Rick that's pretty helpful with large projects. Simply add this to your .autotest file

Autotest.send(:alias_method, :real_find_files, :find_files)
Autotest.send(:define_method, :find_files) do |*args|
  pattern = ENV['AUTOTEST']
  files = real_find_files
  if pattern and !pattern.empty?
    files = files.reject { |k, v|  !Regexp.new(pattern).match(k) }
  end
  files
end

(note the use of Hash#reject because Hash#select is stupid)

and then, to make things even easier, define an alias (or function)

ta() {
  AUTOTEST=${1:-.} autotest
}

It turns out that for some reason, autospec sets ENV['AUTOTEST'] to true. So I changed it to use a different name, and still no tests were running, but this time I see files in the command line.

Then I take a closer look.

/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby -S spec/spec_helper.rb spec/playlist_spec.rb spec/pj_spec.rb spec/track_spec.rb -O spec/spec.opts

spec/spec_helper.rb, you say? That's interesting. Before the upgrade, it was different.

/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby -S /Library/Ruby/Gems/1.8/gems/rspec-1.1.4/bin/spec -O spec/spec.opts spec/playlist_spec.rb

Right now I'm looking at upgrading to a working version of RSpec, like 1.1.4.

Update (22 Oct 2008): RSpec 1.1.9 fixes the problem (by trying to run the specs and not spec/spec_helper.rb). Happy times.

Tests all the way down

2008-08-28T17:00:00Z

UPDATE: An updated gist of the code in this article can be found here.

A recent project had us using ThinkingSphinx for the first time. We've done some with UltraSphinx, but we were open to new ideas. And ReinH was (at least tangentionally) involved, so we bowed to the heavy weight of authority that comes from writing a blog post.

I admit that defining indexes in ThinkingSphinx is nicer than UltraSphinx, but there are method_missing and state-keeping tricks that give me pause. For me, though, it all comes down to writing the spec. Being BDD-infected as we are, writing code without specs hurts. It's simple to say that a column is indexed

class User < ActiveRecord::Base
  define_index do
    indexes email
  end
end

But how to write the failing test that passes when that code is put in?

(As an aside, we know that this sort of test is punting on the real problem. I'd like to see the behavior in action rather than just query the class to see if it has indexes. That's what I do with validations, but with searching it becomes a full-scale integration test involving a search server and too much pain to manage, so we punt. For the record, we asked around and apparently Evan Weaver is the only one who does that kind of integration testing. I figure it's kind of telling that only one person tests it that way, and it's the author of UltraSphinx.)

A spike showed us the way. It was a bit of a pain to traverse the maze of index information, and those method_missing tricks pained me. I don't have that console session to recreate here, but this is the final result:

User.indexes.collect(&:fields).flatten.collect(&:columns).flatten.collect(&:__name).include?(:email)

Now, one could say this convoluted access to indexing information means ThinkingSphinx wasn't written spec-first. I'm here to point out that BDD isn't a panacea. All BDD does is prove that the code matches the spec. As such there's always the looming specter of unspecified behavior, and of course nothing can save you when you've written the wrong specs.

Some time ago, we found a blog post called "If you aren't writing Matchers, you aren't using RSpec", and at the time I discounted it. Mostly I figure if the test looks like butt, I change the code to be easier to test. This situation was different for two reasons: 1) the code wasn't mine to change, and A) it was a severe time-crunch situation. So Rick and I paired on writing a matcher for this thing. And it worked. We referred to the article a few times since it was so informative. There was one glaring omission, though. There was a complete lack of tests.

Remember what I said about being BDD-infected? It's no joke. And I think the things you depend on in your tests need to be tested the best. They're a foundation of your entire testing structure. Would you want to build a house on quicksand? Now, this was test-after because we followed the article to write the matcher, but I still think the tests are nothing to sneeze at.

The matcher code (which went into spec/custom_matchers.rb):

module ThinkingSphinxIndexMatcher
  class HaveIndex
    def initialize(expected)
      @expected = expected
    end

    def matches?(target)
      @target = target
      target.indexes.collect(&:fields).flatten.collect(&:columns).flatten.collect(&:__name).include?(@expected)
    end

    def failure_message
      "expected #{@target} to index #{@expected}"
    end

    def negative_failure_message
      "expected #{@target} not to index #{@expected}, but did"
    end
  end

  def have_index(expected)
    HaveIndex.new(expected)
  end
end

The spec (which was in sanity/have_index_matcher_spec.rb):

require File.dirname(__FILE__) + '/../spec_helper'

describe ThinkingSphinxIndexMatcher::HaveIndex do
  before :each do
    @expected = 'some val'
    @target   = 'some tgt'
    @matcher  = ThinkingSphinxIndexMatcher::HaveIndex.new(@expected)
  end

  describe 'when initialized' do
    it 'should accept an expected value' do
      lambda { ThinkingSphinxIndexMatcher::HaveIndex.new(@expected) }.should_not raise_error(ArgumentError)
    end

    it 'should require an expected value' do
      lambda { ThinkingSphinxIndexMatcher::HaveIndex.new }.should raise_error(ArgumentError)
    end

    it 'should store the expected value' do
      ThinkingSphinxIndexMatcher::HaveIndex.new(@expected).instance_variable_get('@expected').should == @expected
    end
  end

  it 'should have a failure message' do
    @matcher.should respond_to(:failure_message)
  end

  describe 'failure message' do
    before :each do
      @matcher.instance_variable_set('@target', @target)
    end

    it 'should explain the problem, containing the target and expected value' do
      @matcher.failure_message.should == 'expected some tgt to index some val'
    end
  end

  it 'should have a negative failure message' do
    @matcher.should respond_to(:negative_failure_message)
  end

  describe 'negative failure message' do
    before :each do
      @matcher.instance_variable_set('@target', @target)
    end

    it 'should explain the problem, containing the target and expected value' do
      @matcher.negative_failure_message.should == 'expected some tgt not to index some val, but did'
    end
  end

  it 'should tell if a target matches the expectation' do
    @matcher.should respond_to(:matches?)
  end

  describe 'telling if a target matches the expectation' do
    before :each do
      @target.stubs(:indexes).returns([])
    end

    it 'should accept a target' do
      lambda { @matcher.matches?(@target) }.should_not raise_error(ArgumentError)
    end

    it 'should require a target' do
      lambda { @matcher.matches? }.should raise_error(ArgumentError)
    end

    it 'should set the target' do
      @matcher.matches?(@target)
      @matcher.instance_variable_get('@target').should == @target
    end

    it "should go through the target's indexes" do
      @target.expects(:indexes).returns([])
      @matcher.matches?(@target)
    end

    describe 'when the target has no indexes' do
      before :each do
        @target.stubs(:indexes).returns([])
      end

      it 'should return a false value' do
        result = @matcher.matches?(@target)
        (!!result).should == false
      end
    end

    describe 'when the target has indexes' do
      describe 'and an index includes the expected value' do
        before :each do
          indexes = [
            stub('index', :fields => []),
            stub('index', :fields => [stub('field', :columns => [])]),
            stub('index', :fields => [stub('field', :columns => [stub('column', :__name => 'blah')])]),
            stub('index', :fields => [stub('field', :columns => [stub('column', :__name => @expected)])]),
            stub('index', :fields => [stub('field', :columns => [stub('column', :__name => 'other'), stub('column', :__name => 'feh')])])
          ]
          @target.stubs(:indexes).returns(indexes)
        end

        it 'should return a true value' do
          result = @matcher.matches?(@target)
          (!!result).should == true
        end
      end

      describe 'and no index includes the expected value' do
        before :each do
          indexes = [
            stub('index', :fields => []),
            stub('index', :fields => [stub('field', :columns => [])]),
            stub('index', :fields => [stub('field', :columns => [stub('column', :__name => 'blah')])]),
            stub('index', :fields => [stub('field', :columns => [stub('column', :__name => 'other'), stub('column', :__name => 'feh')])])
          ]
          @target.stubs(:indexes).returns(indexes)
        end

        it 'should return a false value' do
          result = @matcher.matches?(@target)
          (!!result).should == false
        end
      end
    end
  end
end

describe ThinkingSphinxIndexMatcher do
  before :each do
    @expected = 'some val'
    @helper = Object.new
    @helper.extend(ThinkingSphinxIndexMatcher)
    @matcher = stub('matcher')
    ThinkingSphinxIndexMatcher::HaveIndex.stubs(:new).returns(@matcher)
  end

  it "should provide a 'have_index' method" do
    @helper.should respond_to(:have_index)
  end

  describe "'have_index' method" do
    it 'should accept an expected value' do
      lambda { @helper.have_index(@expected) }.should_not raise_error(ArgumentError)
    end

    it 'should require an expected value' do
      lambda { @helper.have_index }.should raise_error(ArgumentError)
    end

    it 'should create a matcher for the expected value' do
      ThinkingSphinxIndexMatcher::HaveIndex.expects(:new).with(@expected)
      @helper.have_index(@expected)
    end

    it 'should return the matcher' do
      @helper.have_index(@expected).should == @matcher
    end
  end
end

The addition to spec_helper:

require File.expand_path(File.dirname(__FILE__) + '/custom_matchers')

Spec::Runner.configure do |config|
  config.include ThinkingSphinxIndexMatcher
end

(These are all available at gist #7765)

Note that I never made a spec to test that have_index is available in the specs. Mea culpa, folks. I wasn't sure where those methods go and did I mention the time crunch? I think it would be easier if should returned an object that had methods directly called on it so things like respond_to and include weren't shoved into the wrong place. Remember the good ol' days when RSpec looked like object.should.be_nil? Apparently that was too ugly to keep.

All in all, this was something of an adventure. As I told Rein, when it comes to learning how something works, there's nothing quite like trying to figure out how in the hell to test it.

Oh, and in the end the spec looks like

describe User do
  describe 'as a class' do
    it 'should be searchable' do
      User.should respond_to(:search)
    end

    it 'should allow searching by email address' do
      User.should have_index(:email)
    end
  end
end

Fight on, fight on for ol' Jax State

2008-08-25T20:47:00Z

That’s about a Jacksonville in a different state, but how can you resist any song containing the lyric “We’re proud that we’re from Alabama!”?

Maybe I’d be more impressed if the author bothered to rhyme it.

The boys of OG Consulting have returned to their homeland from another 3-2-1 excursion into Hashrocket territory. Posting about the previous time gave a look into the 3-2-1 experience. This time was similar, yet not exactly; different, yet not hugely so. There were some problems that came up in the post-mortem last time, and those were largely taken care of. Of course, we had different problems this time (isn’t that always the way?), and we tried to address those as quickly as possible in a mid-mortem instead of waiting until the effort was over.

And on top of that we had a big ol’ storm harassing us. I whipped up an image to give a feel for that adventure.

It looked like planning for an extra weekend on the beach and bringing bathing suits was going to end up a waste, but Fay passed us on Friday and we were able to enjoy Saturday outside. Rick and I have the sunburns to show for it.

Shout-outs this time to everyone mentioned in the last post, of course, and also Sandro, Carmelyne, Les, Wes, Esther, Lark, Alex, Corey, and Dan. And of course a special shout-out to Mark for putting us up again in that sweet condo. Three bedrooms, three guest stars, three members of OG Consulting. Maybe a third 3-2-1 is called for.

Ruby 1.9, Shmuby 1.sh9

2008-08-13T16:56:00Z

There’s a lot of buzz about Ruby 1.9, at least if you’re looking in the right places. Sam Ruby gave a presentation about what to expect at OSCON, and I just found the slides today. They have me seeing red.

Before anyone gets the wrong idea, that’s not all aimed at Sam. It’s not even mostly aimed at Sam. I know it’s hard to put a good presentation together, and like anything else, the mistakes that are obvious after the fact were hiding during all the preparations and preliminary run-throughs.

So, some … let’s say “observations” about the slides.

(Note that I don’t have Ruby 1.9 installed and don’t plan to do anything with it or anything else past 1.8.6, not just yet.)

? (used like ?c), like defined?, was something of an annoyance (or it would have been had I ever wanted to use it). The shock of being suddenly shoved into a different world where normal scoping rules don’t apply is too much. And now that ?c will return 'c' instead of 99, what’s the way to get the ASCII value? Is there String#ord? Not that it ever really concerned me since I’m actually trying to write Ruby and not C, but it seems like some people care. For instance, I think Ryan Davis used ? heavily, so I can take some consolation in the fact that 1.9 will break some of his code.

The example given for Array#to_s makes it look like Array#inspect.

Apparently there was a lot of debate about the slide showing [1,2,3].each { |i| ... } vs. for i in [1,2,3]. My humble suggestion is that anyone liking the for i in syntax should go back to PHP.

Fixnum#to_sym presently returns nil? Who knew?

He already has errata for the ‘Hash Keys Now Unordered’ slide.

Okay, the BasicObject slide just hurt my head. This doesn’t even show what I would expect to see, which is that BasicObject has even fewer methods than BlankSlate (a NoneMoreBlankSlate, if you will). Instead, it shows something that looks like constant lookup being hijacked, detoured, and driven into a cliff.

“The biggest obstacle to Ruby 1.9’s adoption is the sheer number of mostly working but essentially unmaintained gems that virtually everybody in the Ruby community depends on.” ahem You know who you are.

Nitpick: For the alternate Hash syntax, the example should have ‘show’ quoted/

Jesus, who doesn’t hate stabby proc? And this also includes one of my pet peeves: defining a arg-taking method without using parentheses.

He implies that 1.8.6 doesn’t allow lambdas to be called with []. And 1.9 allows a lambda to be called like x.(1,2,3)? C’mon, people.

Complex(3,4) == 3 + 4.im. Not 4.i? Painful.

It took me far too long to even read the stabby proc line of the ‘Splat in Middle’ slide. I’ve never read Structure and Interpretation of Computer Programs, but I know that “Programs should be written for people to read, and only incidentally for machines to execute.”

He already has errata for the ‘“Nested” Methods’ slide.

That’s all I have now. I have to go lie down and take some deep breaths.

Down-home Hoedown action

2008-08-11T14:50:00Z

We were in Hunstville for the Ruby Hoedown this past weekend, and let me just say that Jeremy McAnally knows how to put on a hoedown. All you people who didn’t come because of the location or the size or the timing or any other reason, you screwed up.

With two EVDO cards and a nice AP, Confreaks managed to give one of the best conference networks I’ve ever experienced. Granted, I don’t have a lot of conference experience, but I know enough to say Confreaks » O’Reilly. I think in general this was the best conference experience I’ve had, owing in large part to the regional aspects: smaller, more focused (as in there was only one track), less focused (schedule not completely nailed down, good hallway track action).

Obie catches us in a moment, probably thinking of ways to screw with Rein during his talk

Rick, being on the schedule, gave his talk on going through a major refactoring and adding tests to old code, focusing on the experience of turning flog into flame. I was inspired to give a lightning talk on truthy. Kevin managed to squeeze one day of the Hoedown in between other blocks on his busy schedule — legitimizing us with the presence of an iPhone — so this wasn’t the conference to get “the full OG monty”, as it were. Maybe we’ll have to break open the seal on that at something even more local than a regional conference. NashDL OGConf, anyone?

Other highlights:

Hashrocket quoting me in their 3-2-1 ad on the back of the schedule
Obie including our logo among many others, showing the consultancy marketplace in his “Hustle” presentation
Getting a dollar from Joe Kutner for explaining why != isn’t a method
Finally seeing Giles (“Crakahashi Method”) Bowkett present
Being disqualified from the RPSbot competition for cheating

It was a good time. What do you expect when testing, pizza, and bocce come together?

Rick’s talk on flog/flame: (get the code to follow along)

flog << Test.new<object height="355" width="425"><param /><param /><param /><embed src="http://static.slideshare.net/swf/ssplayer2.swf?doc=rubyhoedown2008-1218509498212447-9&stripped_title=flog-testnew-551094" height="355" width="425"></embed></object>

View SlideShare presentation (tags: rubyhoedown2008)

Recorded by Confreaks

Rick giving Gregg Pollack from RailsEnvy the overview

My lightning talk on truthy:

The Nature of Truth<object height="355" width="425"><param /><param /><param /><embed src="http://static.slideshare.net/swf/ssplayer2.swf?doc=truthiness-1218508539826491-9&stripped_title=the-nature-of-truth" height="355" width="425"></embed></object>

View SlideShare presentation (tags: rubyhoedown2008)

Recorded by Confreaks

Me giving Gregg Pollack from RailsEnvy the overview

How Can: Sharing Your Codes to the Git Hubs?

2008-08-02T20:00:00Z

These days it seems that everyone is on the github tip – cloning like a shitty star wars prequel, forking and pulling like a lobster banquet. With github’s success have come a few growing pains – GFS is evidently a rude ho, which means that sometimes you can’t always just take the bus and get there, metaphorically speaking.

Since git doesn’t rely on a centralized repository, github occasionally going pensive like a French actress shouldn’t really cramp one’s style as far as development is concerned. Just commit locally, gitjour with your friends, and when github is back up, git push github master. Badda bing.

It could conceivably be a bit of a headache if you’re hoping to deploy servers with capistrano or vlad and you’re relying on one single service to be up whenever you want to deploy. Since git is so decentralized, however, it seems only natural to just use that decentralization to our advantage and try to eliminate single points of failure. Redundancy, bitches!

So let’s talk about how OGC rolls.

We were hosting our own internal git repos on our own server before github was publicly available (well, to be fair it was Michael’s server, and we eventually broke the lock off the wallet and rented some slicehost action). Once github came along we hopped on and started pushing our open source projects over there as well. We were pushing to both repositories “by hand” for a while, meaning that we’d git push origin master and then git push github master.

First off: ass pain. We could make some aliases or shell scripts, or maybe use git push-all. Meh. Second off, this ain’t DRY – the opportunities for lost or mismatched codez on different servers are too-ubiquitous (“toobiquitous”, in fact) for my liking. Third off, this is clearly an open rabbit hole. Aren’t we obligated to climb into it?

So we made a number of changes. Among them, we started using gitosis to manage our repos (both public and private) on our slicehost. Then we made some configuration changes so that, once a project is setup, pushing to our slicehost repository for a project will automatically force a push to our github repository for the project. Sweet.

So, now, mirroring is easy, though setup on a per-project basis is still a bit cumbersome. We want to document what we’ve done, not because it’s beautiful (yet) but to get it out there and then improve it. Oh, and (to drop the Royal “we”) because ymendel keeps bitching that I need to write this damned blog article. [waves to Yossef.]

Here’s how we’re doing the mirroring… In the discussion that follows there are three machines involved: (1) a local workstation (or laptop, as the case actually is) where I’m doing development work, I’ll refer to it as “local”; (2) a git repository host under our control, which will be running gitosis, to which we push, and which then mirrors to github, called “internal”; and (3) github.com. Suggestions for process improvement are very welcome as there are still a few too many moving parts involved in setting up new projects.

Initial Setup

To get things set up initially, get yourself a unixy/linuxy host where you can set up gitosis for hosting. Slicehost, linode, some dude’s box, whatever.

Set up gitosis on this “internal” machine. We have a user named ‘git’ to run gitosis. The repositories are in ~git/repositories. I followed this article on gitosis.
Make sure the internal repo user has an ssh key that can be used on github:
```
internal:~$ ssh-keygen
```
Add the public key (~/.ssh/id_dsa.pub, for example) to your github account’s key list.

Per-project Setup

Set up a repository for your project on github.com.

Set up a repository for your project on your internal gitosis server:

local:~$ cd ~/git/gitosis-admin
local:~/git/gitosis-admin$ git pull origin master
local:~/git/gitosis-admin$ vim gitosis.conf   ## add the project
local:~/git/gitosis-admin$ git commit -a -v 
local:~/git/gitosis-admin$ git push origin master

Actually make the internal repository by doing a push to it:

    local:~/git/gitosis-admin$ cd ~/git/
    local:~/git$ mkdir foo
    local:~/git$ cd foo
    local:~/git/foo$ git init
    local:~/git/foo$ touch README
    local:~/git/foo$ git commit -a -m "Initial repository push."            
    local:~/git/foo$ git remote add origin git@internal:foo.git
    local:~/git/foo$ git push origin master:refs/heads/master

UPDATE 2009-04-08: This is the start of the no-longer-necessary section. Check out the new hotness.

Set up a remote called “github” on the internal gitosis repo pointing to github (use your username instead of flogic, duh):
```
internal:~git/repositories/foo.git$ git remote add github git@github.com:flogic/foo.git
```
Set up a hook in the internal repository so that when your commits come in to your internal repository they will be pushed out to the corresponding github repository. We used post-update, but post-receive should work as well (discussion of the various hooks git understands). Thanks to Evan Phoenix for the kick-start to get this working:
```
#!/bin/sh
#
# An example hook script to prepare a packed repository for use over
# dumb transports.
#
# To enable this hook, make this file executable by "chmod +x post-update".


git-update-server-info


exec git push --mirror github >> ~/github.log 2>&1
```

Make sure the new hook is runnable:

internal:~git/repositories/foo.git$ chmod +x hooks/post-update

(One question I have is, is there a way to do this with gitosis that doesn’t involve logging in on the server to add the remote and setup the hook?)

UPDATE 2009-04-08: This is the end of the no-longer-necessary section. Check out the new hotness.

We still set two remotes in our git configs, in case we ever want to manually push straight to github – our server could go down too, y’know (again, substitute your github username for “flogic”):

local$ git remote add origin git@ogtastic.com:foo.git
local$ git remote add github git@github.com:flogic/foo.git


local$ git config --list | grep ^remote
remote.origin.url=git@ogtastic.com:foo.git
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
remote.github.url=git@github.com:flogic/foo.git
remote.github.fetch=+refs/heads/*:refs/remotes/origin/*

Push to the internal server … it should just magically show up on github:

local:~/git/foo$ echo "test" > README
local:~/git/foo$ git commit -a -m "testing mirrored push to github"
local:~/git/foo$ git push origin master

For troubleshooting, we adopted Evan’s idea and have a log file in the home directory of our internal server’s git user. The log file will show the output of attempting to git push --mirror to github.

Anyway, happy codes sharings!

The right way to do something you should never do

2008-07-23T17:14:00Z

One project we’re on now involves a dashboard view that has a continually updating list of items. This seemed like a perfect place to use Juggernaut.

Like with anything else, there was the YAGNI discussion. This could happen with polling and regular AJAX, right? It turns out that not only is pushing with something like Juggernaut more lightweight than polling, it’s easier. There’s no need to contact the server and say “hey, give me everything after this” if you can get an update upon creation.

The trouble is that anything involving Juggernaut seems to smack of MVC violation. It’s obvious that updating a list of items as they come in points to an observer with an after_create callback, but using Juggernaut involves creating some JavaScript by hand or using one of the helpful render calls. So I need a controller. In a model. (Or a model-like thing.)

In accordance with my M.O., I dove into the Rails code and promptly started cursing. Rick, on the other hand, did some searching and came up with a blog post from Matt Harvey. Now, while I’m sure that works, it seemed like way too much. I came up with a different solution.


class LogObserver < ActiveRecord::Observer
  def controller
    returning ActionController::Base.new do |controller|
      controller.instance_variable_set('@template', ActionView::Base.new(ActionController::Base.view_paths))
      controller.instance_variable_set('@assigns', {})
    end
  end

  def after_create(log)
    controller.render :juggernaut do |page|
      page.insert_html :after, 'dashboard_logs_top', :partial => 'logs/log', :locals => { :log => log }
    end
  end
end

I’m not especially proud, but it’s small and it works. And it has specs.

Also, Juggernaut is pretty sweet.