Alex Chaffee's blog



Alex ChaffeeAlex Chaffee
Code Monkey
edit Posted by Alex Chaffee on Friday May 20, 2011 at 10:56AM

So I didn't go to whatever was going on in Baltimore this week, but I did do a whole bunch of open source coding over the past week or two:

  • TestFirst has a totally revamped design, including the downloadable (or cloneable) student exercises, and Learn JavaScript is now a first-class citizen
  • Wrong's expect alias now plays nicer with RSpec's expect
  • Rerun got a few new command-line options, including --clear and --exit so you can now easily rerun regular scripts (like rerun -cx rake test) when their files change
  • I submitted a patch to RubyGems to make the warningitis less ZOMG and more KTHXBY
  • Fonzie is a bookmarklet that tells you what font you're looking at
  • Twitter RSS is a bookmarklet that brings back the RSS link to the New Twitter UI
  • Showoff works better with nested bullets and missing showoff.json files -- so go nag Scott if you want him to accept my patches ;-)
  • I also finally got my git pre-commit hook correctly stripping whitespace, and

A lot of these projects, especially TestFirst, are aching for improvement, so if you feel like contributing code or courseware, or even just feature requests, please get in touch!

Alex ChaffeeAlex Chaffee
RubyGems Warningitis Outbreak
edit Posted by Alex Chaffee on Thursday May 12, 2011 at 11:20AM

Have you upgraded RubyGems lately? Is your console suddenly filled with warnings like this?

NOTE: Gem::Specification#default_executable= is deprecated with no replacement. It will be removed on or after 2011-10-01.
Gem::Specification#default_executable= called from /Users/chaffee/.rvm/gems/ruby-1.9.2-p0/specifications/thin-1.2.7.gemspec:10.

You may be showing signs of a new malady known as Warningitis! So far there is no cure, but doing the following will temporarily cure your symptoms:

gem update --system 1.7.2

Several experimental treatments are being hastily developed as well, but these have not yet been approved by the FDA. Check the "scary warnings are scary" bug thread for more details.

This has been a public health alert. Please do not panic. SARS masks and iodine pills are not recommended at this time.

Alex ChaffeeAlex Chaffee
Upgrading your Rakefile from RSpec 1.3 to RSpec 2
edit Posted by Alex Chaffee on Tuesday October 26, 2010 at 11:12AM

I'm updating Erector to RSpec 2 and came across two problems for which solutions were surprisingly difficult to Google. Here are my (finally successful) results.


Problem:

no such file to load -- spec/rake/spectask

Before:

require "spec/rake/spectask"  # RSpec 1.3

After:

require "rspec/core/rake_task" # RSpec 2.0

Problem:

undefined method `spec_files=' for #<RSpec::Core::RakeTask:0x00000101550aa8>

Before:

# RSpec 1.3
Spec::Rake::SpecTask.new(:core) do |spec|
  spec.spec_files = FileList['spec/erector/*_spec.rb']
  spec.spec_opts = ['--backtrace']
end

After:

# RSpec 2.0
RSpec::Core::RakeTask.new(:core) do |spec|
  spec.pattern = 'spec/erector/*_spec.rb'
  spec.rspec_opts = ['--backtrace']
end

See also http://github.com/rspec/rspec-core/blob/master/Upgrade.markdown (curiously cloaked from Google searches for the above problem strings).

Alex ChaffeeAlex Chaffee
Where, oh where has my gem server gone?
edit Posted by Alex Chaffee on Sunday August 08, 2010 at 06:01PM

Uh-oh!

ERROR:  While executing gem ... (Gem::RemoteFetcher::FetchError)
    bad response Moved Permanently 301 (http://gems.rubyforge.org/latest_specs.4.8)

Whew!

gem sources -a http://rubygems.org/
gem sources -r http://gems.rubyforge.org/

Looks like they weren't kidding when they said to switch from rubyforge to rubygems.org (née gemcutter)!

[Edited to change "http://production.s3.rubygems.org/" to "http://rubygems.org/". Note that the trailing slash is significant!]

Alex ChaffeeAlex Chaffee
monkey patch of the day - activesupport vs. json_pure vs. Ruby 1.8
edit Posted by Alex Chaffee on Sunday July 25, 2010 at 12:13PM

The error:

/Library/Ruby/Gems/1.8/gems/json_pure-1.4.3/lib/json/pure/generator.rb:232:in `__send__': undefined method `except' for #<JSON::Pure::Generator::State:0x102f245b0> (NoMethodError)

The environment: Ruby 1.8.7, DataMapper, dm-types, ActiveSupport, or just

require 'json/pure'
require 'active_support'

(as seen in http://gist.github.com/339528)

My solution:

# workaround for activesupport vs. json_pure vs. Ruby 1.8 glitch
if JSON.const_defined?(:Pure)
  class JSON::Pure::Generator::State
    include ActiveSupport::CoreExtensions::Hash::Except
  end
end

Alex ChaffeeAlex Chaffee
Windowed String Comparison for RSpec
edit Posted by Alex Chaffee on Friday July 16, 2010 at 10:55AM

When two strings fail to match, if the difference is somewhere in the middle of the strings, it can be annoying/impossible to track down the actual difference. I've written a little Comparison object that overrides the failure message for .should == like this:

Strings differ at position 12: 
expected: ..."efghijklmnopqrst"... 
  actual: ..."efghijklXXopqrst"...

It shows a "prelude" of a few characters, then the difference, lined up on successive lines so they're easy to visually scan. It also does the right thing (or tries to) if the difference is near the beginning or end of the string (i.e. does or doesn't show ellipses).

http://gist.github.com/474363

For people who can't wait for this to get incorporated into RSpec proper, you can grab the code from github and require "comparison" in your spec_helper.rb and it'll override the existing RSpec == matcher. Or wait for Issue 9 to be pulled into version 2.1 (maybe). Or if you want to use it in your favorite testing framework, the object is completely self-contained and should be easy to call from your own assert_equals or whatever.

One open question is whether the exception message should show the full actual string as well as the comparison... On one hand, it adds to screen clutter, but on the other hand, it can be important in tracking down the problem, especially if the prelude is ambiguous.

Alex ChaffeeAlex Chaffee
Basic Ruby Webapp Performance Tuning (Rails or Sinatra)
edit Posted by Alex Chaffee on Wednesday April 28, 2010 at 07:37PM

My company launched our app, Cohuman, a few weeks ago. The rush of finishing features, fixing bugs, and responding to user feedback has subsided a bit, and it's time to go back and give the little baby a tune-up. I find that a good development process will ebb and flow, and as long as you don't let something slide for too long, it's perfectly acceptable to let bugs, or performance issues, or development chores pile up for a bit and then attack them concertedly for an entire day or two. A bug-fest or chore-fest or tuning-fest can actually increase efficiency as you get in a rhythm... and it feels really good at the end of the day when you see all the bugs you slayed or all the milliseconds you shaved.

In this article I'd like to describe some of my techniques. I make no claim of originality or great expertise; I just want to share what I know, and hear (in comments) what other people have learned. I'm using Sinatra and ActiveRecord, but not Rails; hopefully this discussion will help people no matter what framework they're using.

Alex ChaffeeAlex Chaffee
TextMate: The Last Straw
edit Posted by Alex Chaffee on Tuesday March 16, 2010 at 02:36PM

That's it. I'm done with TextMate. It hasn't been updated in over 2 years, either for essential functionality (replace in path) or performance fixes (searching through log files) or UI issues (how many boxes must you click to enable autosave?) or bug fixes. Every few months the author pokes his head up and says "I'm working on TextMate 3.0!" and then disappears again, happily accepting new license fees into his PayPal account.

I've just been bitten twice in two weeks by a bug that caused not just data loss, but data mangling in a way that was very difficult to fix. Here's the rough steps to reproduce:

  1. Edit some files in TextMate
  2. Leave TextMate running in the foreground
  3. Switch to console and "git pull" in the latest code from your workmates
  4. Run a search-and-replace that edits a file that was changed (by someone else) during the merge
  5. Save that edit

You'll see (with "git diff") that your version of the file has your new post-merge changes... but it also has reverted your buddy's changes from the merge. It's like you decided that those changes were no good and reverted them yourself and then added your own.

If you fail to notice this before checking in, you will totally hose your version control... but just for that one file. You can't just revert a whole commit... you'll have to step through change by change to figure out which change was theirs, which change was yours, and which change looks like it was yours but was actually an inadvertent revert of theirs!

I can't work under these conditions. I'm switching to RubyMine today. See http://bjclark.me/2010/03/10/rubymine-a-love-story/ for why.

P.S. I just found a bug report for this dated 2008-04-02. That's just about 2 years ago for a critical data-losing bug. Woot.

Alex ChaffeeAlex Chaffee
UTC vs Ruby, ActiveRecord, Sinatra, Heroku and Postgres
edit Posted by Alex Chaffee on Friday January 22, 2010 at 12:17PM

Now that I'm starting to use DelayedJob to perform jobs in the future in my Heroku Sinatra app, its important that they happen at the scheduled time. But unless you pay attention, you'll find that times get mysteriously changed -- in my case, since I'm in San Francisco in the wintertime, by +/-8 hours -- which means that some conversion to or from UTC is being attempted, but it's only working halfway.

Trying to keep a handle on which libraries are attempting, and which are failing, to convert times is a losing battle, so I'm trying to do the right thing and save all my times in the database in UTC, and convert them to and from the user's local time as close to the UI as possible. Unfortunately, a variety of gotchas in Ruby and ActiveRecord and PostgreSQL makes this trickier than it should be. Here's a little catalog of my workarounds.

Alex ChaffeeAlex Chaffee
annotate 2.4.0 released
edit Posted by Alex Chaffee on Sunday December 13, 2009 at 03:16PM

Remember the annotate_models rake task? Dave Thomas wrote it many years ago and it corrects one of the flaws in ActiveRecord: it describes the schema for a table as a comment inside the Ruby model file that it maps to. Unfortunately Dave hasn't had time to maintain it, so a couple of years ago I cleaned up some bugs and re-published it as a pastie. Then Cuong Tran made it a gem and put it on Github, and since then, there's been a whole lotta forkin' goin' on!

I recently pulled in a bunch of the forks into ctran's master branch, and just pushed it to Gemcutter as version 2.4.0. Just run gem sources and make sure http://gemcutter.org is in your list -- otherwise do gem source -a http://gemcutter.org -- and sudo gem install annotate and it'll install a binary called annotate in /usr/bin. See the README on github for more info and have fun!

One caveat: ImageMagick installs a tool called annotate too (if you're using MacPorts it's in /opt/local/bin/annotate). So if you see

Usage: annotate imagein.jpg imageout.jpg

then put /usr/bin ahead on the path and you'll get ours instead.

Other articles: