a timocracy of one

Over at Pivotal they recently blogged about the typical wrist problems that plague developers. In one of the comments someone mentioned a solution a number of us have come across at some point, mousing left-handed. When I have wrist problems (and a number of colleagues have confirmed the same) it tends to be in the right wrist. My problems come from mousing too much, rather than typing. This is aggravated by the fact that the numpad on full-sized keyboards is typically on the right side since people 10-key with their dominant hand. This setup pushed the mouse hand even further out of ergonomic alignment, though.

On the other hand, the layout is perfect for mousing left handed: the mouse starts closer to the optimal hand position and you can enter numbers while mousing. It does take some serious adjustment if you have been using computers for your whole life, but that is actually an added bonus – it gives you additional incentive to work on your mouseless operation while you are stuck in the awkward adjustment period. If you stick with it for a while, you will remap your brain enough, though. And, just like learning to brush your teeth with either hand, the flexibility is useful, for now you can flip-flop as needed to even out the wrist strain.

The new Apple flat (wired version) is perfect for that, since it returns to the tradition of a USB port on either side of the keyboard, for plugging in the mouse and/or another device.

As part of learning rspec for blerb, I’m working on better mocking for truer isolation tests. This includes true unit tests for models, controllers, and views, unlike the rails/testunit standard approach. This involves, primarily, mocking out the models and turning rendering off for the controller testing, and figuring out how to test just the rendering without the rest of the stack, for the views. I won’t claim any of this is well organized, or finalized, as we are just figuring out how to do some of it in the first place, but feel free to crib any of this you like off the git-web for blerb.

First a controller

describe "Articles Controller", "index action" do
  before(:each) do
    @article1 = mock("article")
    @article2 = mock("article")
    @articles = [@article1, @article2]
    Article.should_receive(:all).and_return(@articles)
    @controller = Articles.build(fake_request)
    @controller.stub!(:render)
    @controller.dispatch('index')
  end

  it "should get successfully" do
    @controller.status.should == 200
  end

  it "should assign all articles" do
    @controller.instance_variable_get("@articles").should == @articles
  end
end

The one non-intuitive part (for me), was making sure to stub render – otherwise you’ll be calling the view, and getting errors on your mocks because the view is calling methods you didn’t mock/stub out. Thus, it is key to isolate the controller from the model and the view if you want to easily test it, in this style. Oh yeah, and knowing about fake_request as part of the merb testing help.

The slightly trickier part was doing the same for the views. I dug through the merb source, and got most of the way, but hadn’t figured out how to pass in assigned instance variables by creating a dummy ViewContext, when ezra gave me a hand. I would NOT (and will not long term) do it exactly like this, but rather extract some sort of spec_helper to wrap the fake view_context creation and template engine calls, but it’s useful as is for an illustrative example.

class FakeArticleController
  def initialize(articles)
    @articles = articles
  end
end

describe "/articles" do
  before(:each) do
    @article1 = mock("article")
    @article2 = mock("article")
    @article1.should_receive(:title).and_return("Article 1")
    @article2.should_receive(:title).and_return("Article 2")    
    Article.stub!(:all).and_return([@article1,@article2])

    @template = "#{MERB_VIEW_ROOT}/articles/index.html.erb" 
    @engine = Merb::Template.engine_for(@template)
    @fake = Merb::ViewContext.new FakeArticleController.new(Article.all)
    @body = @engine.transform(:file => @template, :view_context => @fake)
  end

  it "should list all articles" do
    @body.should include("<li>Article 1</li>")
    @body.should include("<li>Article 2</li>")
  end
end

• Run tests – command-r runs the current test file
• Run focused unit!!!! – command-shift-r runs the test your cursor is in.
• The TODO bundle – ctrl-shift-t compiles all your #FIXME #TODO and #CHANGED comments into a pretty little list
• goto file – command-t – a smart, easy, and quick way to go to a given file.
• wrapping/unwrapping – a variety of shortcuts and menu items to combine/un-combine lists of items, wrap text in delimeters, etc.

Instead of having to run it through the clipboard first:

def pastie(string=nil)
  pastie_url = Net::HTTP.post_form(URI.parse("http://pastie.caboo.se/pastes/create"),
                                   {"paste_parser" => "ruby",
                                    "paste[authorization]" => "burger",
                                    "paste[body]" => (string || MacClipboard.read)}).body.match(/href="([^\"]+)"/)[1]
  MacClipboard.write(pastie_url)
  system("open #{pastie_url}")
  pastie_url
end

If you are wondering WTF is going on, read the previous post

So Giles Bowkett just released a gem that does most of the tweaks I had been meaning to add to my .irbrc, but had been to lazy. utility_belt is pretty awesome, but there is one tiny tweak I wanted to add to make it optimal, and Giles isn’t known for making himself easy to get a hold of (especially now that comments seem to be perpetually closed on his blog). So instead I just hacked it on the gem myself. I’m not going to bother distributing it as a gem myself, but you are welcome to steal the idea and add it to your copy.

To be able to pass a string (say like the last result, via ”_”, when irb just dumped 500 lines of output on you) to Textmate, edit lib/interactive_editor.rb like so

10,13c10,13
<   def edit
<     unless @file
<       @file = Tempfile.new("irb_tempfile")
<     end
---
>   def edit(string)
>     @file = Tempfile.new("irb_tempfile")
>     @file.write string
>     @file.close
17a18
>     @file.unlink
22c23
<   def edit(editor)
---
>   def edit(editor, string)
27c28
<     IRB.conf[:interactive_editors][editor].edit
---
>     IRB.conf[:interactive_editors][editor].edit(string)
30,31c31,32
<   def vi
<     edit(:vim)
---
>   def vi(string=nil)
>     edit(:vim,string)
34,35c35,36
<   def mate
<     edit(:mate)
---
>   def mate(string=nil)
>     edit(:mate,string)
38,39c39,40
<   def emacs
<     edit(:emacs)
---
>   def emacs(string=nil)
>     edit(:emacs,string)

Now glory in “mate _” from irb.

Or best of all: use ruby2ruby and call mate on the result of #to_ruby on a method. You can edit the method in Textmate and save, and wallah, it’s applied. Of course, getting that working correctly in an actual Module/Class hierarchy might be a bit more complicated, and I leave as an exercise for the reader.

hornbeck’s master repo is available at git://42squared.com/git/blerb. Stop by #blerb if you want to hack on it. With the help of mattly and court3nay I’ve put a copy of the repo up at git.caboo.se so now there is web access to blerb source via gitweb, for those who don’t want to brave git, yet, or who already have access to git.caboo.se (I believe it’s wide open for read-only, of course), or just those that like browsing the history/changelogs/ through a webterface. I’ll be pushing up to there every so often.

On another note, we plan on borrowing everything that makes sense to from Ezra’s earlier stab at a similar project: MrBlog

The checkbox helper in rails inserts a zero valued hidden input to simplify the server-side value handling (for example unsetting the checkbox). The problem with this it can mess up your css on fieldWithErrors (say if you have a big red asterisk image on your error fields), because it, by definition, has the same name as the checkbox, and gets assigned the same errors. Personally, I don’t think any hidden field should show errors and thankfully rails lets me take care of that. Just put this in your environment file

#Fix problem with fieldWithErrors and the hidden field generated for a checkbox
ActionView::Base.field_error_proc = Proc.new do |html_tag, instance|
  if html_tag =~ /<(input)[^>]+type=["'](hidden)/
    html_tag
  elsif html_tag =~ /<(input)[^>]+type=["'](checkbox|radio)/
    "<div class=\"fieldWithErrors miniFieldWithErrors\">#{html_tag}</div>" 
  else
    "<div class=\"fieldWithErrors\">#{html_tag}</div>" 
  end
end

This is also where you could fix the whole arbitrarily inserted div messing your layouts, as well, by replacing it with a span, say. ;)

Some useful info on the DH wiki for git and on kernal.org’s guide to setting up git over http. The latter is especially helpful for debugging suggestions (like using curl to check your .netrc access permission). Using the info in these guides:

• Create a repo, or use an existing one
• Enable WebDav access on a DH directory, using their panel. Set-up the username password for the committers, and disable the password protection box for read-only anonymous access (might be easier to keep it on until you have everything set-up right)
• Create a .netrc with the auth info for this webdav
• Test your access using the curl command in the kernal.org guide (you may find it useful to have password protection enabled at this point,).
• Connect to the webdav share using the username and password.
• Copy over the .git folder contents into the root of the webdav share (this is key, because DH’s anonymous access won’t show . files)
• cd into the webdav share from your local machine and run “git-update-server-info”
• profit

You should now have access to http://yourserver/gitfoldername and http://gituser@yourserver/gitfoldername. For example: you can “git clone http://blerb.infosauce.org/git/” for read-only access to the blerb repo. Now, if I can only get gitweb working despite the limited access control imposed by DH webDAV.

Update: Changes the url for blerb to still work right after I changed it around while playing with gitweb. Also, you should use git://42squared.com/git/blerb if you actually want the real blerb repository.

It’s nowhere near being ready yet, but I made my first contributions tonight. I was going to code up one myself, but a couple other caboosers already where planning on it, and since I am somewhat time constrained on personal projects, that was perfect.

Just getting started was quite a bit to bite off, though, as it involved learning git, datamapper, merb, rspec, and how the last three all play together (like how to use rspecs built-in mocking when trying to do controller specs in merb). I got it checked out and my first minor changes specc’ed and made, and pushed back upstream, though, so it should go easier from here out.

I will post more when there is something more to say (like maybe a repo to browse, or a website, or something that is usable as a blog)

Update: The other contributor to blerb so far is John Hornbeck.

Last year, I wrote an article about redefining an instance method from a module via alias_method. I understand better how extend/include work together now (and the ClassMethods include patterns and whatnot) so I am little embarrassed at my earlier confusion, but there is one concrete thing I wanted to add/simplify.

If you are mocking and don’t need to keep a reference to the old method, using define_method might be marginally cleaner.

def self.included(associator_class) 
  associator_class.send(:define_method, :initialize, instance_method(:initialize))
end

This is handier because you can skip the method definition/reference logic and just do it in situ, for instant-stubification

ClassToBeIntercepted.send :define_method, :method_to_be_nuked, proc {return 'nuked'}