cryingwhilecoding

drip drop drip..

git bisect is awesome

March 9th, 2009

I’d heard git bisect was a fun thing to play with, and after having an opportunity to play with it last week, I have to agree!

I’ve been tracking edge rails as a submodule on a current project. It’d been a couple weeks since I last updated rails and after a friend told me they fixed a bug with using :having in a named scope I decided to sync up and refactor some code. This is usually an uneventful operation.
1
2
3
cd vendor/rails
git checkout master
git pull
Run my specs and make sure everything appears to be ok.. and commit the update. Only, this time I experienced about a dozen failing specs following the update. I wanted to quickly find out why the specs were suddenly failing and there were a couple dozen commits I had pulled in. So I used git bisect to figure it out. Since my specs were passing before the update, I use the SHA I was tracking before, 92a30b0, as a good reference point.
1
2
3
4
5
6
# still in the vendor/rails dir, and my specs are failing
git bisect start
# tell git, the current state is bad
git bisect bad 
# tell git, when the state was good
git bisect good 92a30b0
git then finds a commit between the known good and bad, and I re-run my specs. If the specs fail, I tell git bisect it’s bad, if the specs pass, I tell git bisect good. Either way, it grabs another commit and I repeat the process until we’ve narrowed down the exact commit that causes the specs to fail. Awesome. You can save yourself the manual labor of telling git if it’s good or bad by telling git to run a script/command
1
git bisect run ~/test.sh
where test.sh runs the test/spec suite and returns good (0) / bad (>0) error codes

git help bisect for fun and profit

About a month ago I ran into a pitfall in my git work flow. I had a topic branch where I was radically changing the schema and needed to flip back to another branch to fix some issue and found I had some new bizarre issues that had me scratching my head until I realized my db had changed from under me. Hmm.. I discussed the issue with some friends on irc and after a short while one of them came back with a quick solution he and his buddies at SevenWire whipped up and pushed out to github.

db_branch, is a simple plugin that will load an alternate database file for the current branch if it exists and some rake tasks to initialize the config file and databases.

Earlier today I worked on making it even better and added some tasks to clone an existing db and purge the branch dbs.

Git it on github, http://github.com/agile/db_branch/tree/master

1
2
git submodule add git://github.com/agile/db_branch.git vendor/plugins/db_branch
rake db:branch

So now my work flow when messing up the db, is something like..

1
2
3
4
5
6
7
8
9
10
11
git co -b messy_branch
rake db:branch
./script generate migration making_a_mess
# look at me, messing up my db, but it's ok because only this branch uses this db
rake db:migrate
git add db/migrate && git  ci "committing the business"

# and while I'm on that branch, I'll be using my awesomeapp_messy_branch db
git co master

#and I'm back to using my old awesomeapp db

nice!

Taking it to eleven..?

I think I’d like to figure out how to tie it into git’s hooks so that it just automatically creates a db branch and clones when a new branch is created, then purges when the branch is deleted. That’d be hot.

Since I can never seem to recall how to update rubygems when there is a new rubygems update but it refuses to work..

1
2
3
4
5
6
7
8
9
10
11
12
13
14

mike@cryingwhilecoding:~$ gem -v
1.2.0
mike@cryingwhilecoding:~$ gem list rubygems

*** LOCAL GEMS ***

rubygems-update (1.3.0, 1.2.0, 1.1.1, 1.1.0, 1.0.1, 0.9.5, 0.9.4, 0.9.3, 0.9.2)
mike@cryingwhilecoding:~$ sudo gem up --system
Updating RubyGems
Nothing to update
mike@cryingwhilecoding:~$ gem -v
1.2.0
mike@cryingwhilecoding:~$ 

The trick is to just call update_rubygems

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

mike@cryingwhilecoding:~$ sudo update_rubygems
Installing RubyGems 1.3.0
mkdir -p /usr/local/lib/site_ruby/1.8
mkdir -p /usr/bin

...blah blah...hey look! a note about how to do this! :)

If you have an older version of RubyGems installed, then you can still
do it in two steps:

  $ gem install rubygems-update  (again, might need to be admin/root)
  $ update_rubygems              (... here too)

...blah blah...

mike@cryingwhilecoding:~$ gem -v
1.3.0
mike@cryingwhilecoding:~$ 

Hoorah, success. It’s too bad you don’t get that helpful note in there until after you figure out how to do it.

Burning the midnight oil is a programmer’s CRACK!

If you’ve ever continued working on something, sort of like beating your head against the wall hoping to get rid of a headache, late into the night/early morning only to come back the next morning exhausted AND seeing your code has her panties on her half shaven head. Well, you know JUST what I’m talking about then.

PUT THE CODES AWAY, my friend. Put the codes away for another day.

Hello sobering Monday.

Eager to jump back into the fray of a suite of specs I left half baked Friday, I spent a little time first trying to figure out why I was getting a particular error when attempting to run the spec suite.

1
2
3
/usr/lib/ruby/gems/1.8/gems/activesupport-2.0.2/lib/active_support/dependencies.rb:249:
  in `load_missing_constant':
  Expected /sekrat/awesomeproject/app/models/awesome.rb to define Awesome (LoadError)

Nice, eh? I’ve seen it before but I can never remember what causes it. Actually, I there are probably a number of ways you might run into this error message, such as the load order for plugins being incorrect. The way I encountered it today was by injecting a typo into an AR method, set_inheritance_column lacking the final ‘n’ in this case. So if you are shedding some tears over this, double check the spelling on your AR methods (has_many, belongs_to, etc..)

props to lifo

I’ve been using rspec for a while now and as soon as the excitement surrounding the plain text stories development manifested itself into a real feature I was dying to try it out. While tinkering with it I created some scripts in vim to try and bump the experience up a notch.

I’ve put them up on github so that maybe some others will find them useful and make ‘m better. :) I name my stories with a .story extension to make them easy to identify, others seem to like making them extension-less which I guess would be ok too if they could be found in a predictable path.

Included are ftdetection, ftplugin, syntax, and an indentation scripts.

obligatory screen shots… screenshot screenshot

If like me you’ve tried to update the rmagick gem on a gutsy (or older) release of ubuntu, the outdated nature of your imagemagick installation has been brought to your attention. Kind of amusing how out of date this particular package has been. shrug

Luckily the version in Hardy Heron will suffice our needs, so this is how I went about backporting it for anyone wishing to do the same.

Prepare..

1
2
3
4

  sudo apt-get update 
  sudo apt-get build-dep imagemagick
  sudo aptitude install libdjvulibre-dev libgraphviz3-dev

Aquire..

Grab the imagemagick source package from the heron release..

  1. Go to the imagemagick page in launchpad, https://launchpad.net/ubuntu/hardy/i386/imagemagick
  2. Click the published version link on the right which at this time will take you to: https://launchpad.net/ubuntu/hardy/i386/imagemagick/7:6.3.7.9.dfsg1-2ubuntu1
  3. Download the tar and diff links near the top of that page.
  4. unpack the tar somewhere and apply the patch
1
2
3

  tar zxvf imagemagick_6.3.7.9.dfsg1.orig.tar.gz 
  zcat imagemagick_6.3.7.9.dfsg1-2ubuntu1.diff.gz |patch -p0
Note.. Alternatively, if you have a hardy heron installation available, the above aquisition steps could be replaced by an apt-get source imagemagick from your hardy installation and copy the resulting directory to your machine, this is what I actually did.

 apt-get source imagemagick 

I suppose you could probably also update your sources to hardy, update and do the apt-get source, put your sources back to gutsy and update again.. whatever works for you, don’t go blaming me if you accidentally find yourself checking out how awesome the hardy heron release is though.

Carress..

Before we can build it for our gutsy machine, we need to fix one thing. It currently expects libgraphviz-dev, we’re going to change that to libgraphviz3-dev
1
2
3

  cd imagemagick-6.3.7.9.dfsg1
  sed -i 's/libgraphviz-dev/libgraphviz3-dev/' debian/control

Build..

1
2

  sudo dpkg-buildpackage && cd .. && ls -l *deb 

Install..

1
2

  sudo dpkg -i l*deb i*deb p*deb

Enjoy..

And so it begins

February 18th, 2008

crying.. while coding.