I’m no code metrics freak, but it’s good to check that stuff every once in a while. Cucumber steps tend to get kind of
nasty after a while (at least for me), so I’m trying an experiment where I run flay
on the steps after a successful run, just to make sure I’m not duplicating too much between step definitions.

Save this to features/support/flay.rb and tweak flay_level to a sane number. 0 is probably not the right setting
if you want to keep your sanity.

# run flay on your cucumber steps after a successful run. prevent bloat and
# promote reusability!
flay_exception = nil
flay_level = 32 # set me to a minimum sane level. don't go nuts refactoring!
# code should be cleaner when you're done, not become spaghetti.
After do |s|
flay_exception ||= s.exception
end
at_exit do
system %{flay -m #{flay_level} features/step_definitions/**/*.rb} if !flay_exception
end

Stealing an idea from Backbone.js, I decided to try using a collection
class with an ActiveResource model I was working on. The use case was for creating a tree of objects
based on an acts_as_tree storage method, where child objects have a parent_id set the same as the
parent’s id. Here’s what I originally had:

# simple skeleton to hang more on laterclassActiveResource::Collection<::Arraydefinitialize(models)replace(models)endendclassCategory<ActiveResource::Basedefself.treeCategories.new(all).treeenddeftop_node?parent_id==nilendendclassCategories<ActiveResource::Collectiondeftop_nodesfind_all(&:top_node?).sortenddeftreetop_nodes.collectdo|node|node.tap{|n|n.children=models.find_all{|model|model.parent_id==node.id}.sort}end.sortendend

More lines of code, but no mess in the model itself. I’ll play with the idea and see how well it scales to other situations.

I’ve switched to tmux and wanted to simplify my life as best as I can when using it, so I tried a few tmux gems to manage configs
and decided on teamocil. However, like anything involving
a terminal multiplexer, it needs massaging (Teamocil may cause numbness of the extremities.):

Solarized Dark for iTerm2 is weird in that the grey used by Cucumber to show where
a snippet comes from is nearly invisible. You can either increase the contrast (I set it to about 20%), or export a CUCUMBER_COLORS environment variable so
you don’t have to worry about it:

Here’s one that was biting my bum: rack-livereload started generating a bunch
of thread deadlock errors left and right for users. One commenter on the bug thread mentioned that middleware need to close the
body, which I had never heard of before. Turns out it’s not as well-documented a practice that I would have hoped.

It boils down to trying to close the body that you get after you call your app, in case for some reason it passes you an
open file handle (which I guess is a thing?)

classMyMiddlewaredefinitialize(app)@app=appenddefcall(env)dup._call(env)# <= the thing I thought would fix the deadlocksenddef_call(env)[status,headers,body]=@app.call(env)new_body=[]body.each{|line|new_body<<line}body.closeifbody.respond_to?(:close)# <= the thing I really had to do# ...process stuff...[status,headers,new_body]endend

So this is mainly so I remember to do this from now on, and for anyone else who runs into thread deadlock issues with Rack middleware.

Upon building Ruby 1.9.3-p125 on my Snow Leopard Mac and getting ready to take it for a spin, trying to run anything of note in a Rails app brought the following cryptic error:

[BUG] cross-thread violation on rb_gc()
(null)
Abort trap

Digging into Console.app, the backtrace indicated that the system libruby.1.dylib was being accessed from the C parser in the json gem living in the @global
RVM gemset. otool -L confirmed that the parser in the @global gemset was linked against system ruby, not RVM ruby. Installing a new json gem into the current gemset didn’t work, as RVM prefers to use the @global version of the gem over the one in the current gemset,
it seems. Deleting the gems from the @global gemset and reinstalling the json gem in the current gemset worked, and I’m sure I could have reinstalled the
json gem globally too.

A particular dependent API request wasn’t making it back to the app under test nor the browser. The
request was actually being proxied through the app, pretty much raw from the API and not re-run
through Active Resource before being sent to the browser.

The issue:

An expires_in in the controller method was sending along cache information, causing the stale data to
be cached somewhere.

Running commands in a Bundler-enabled app that has a Git repo attached to it makes running Bundler in subshells a pain.
Bundler.with_clean_env gets close, but still leaves enough of Bundler around to be unpleasant. This kills it dead
in subshells:

OK, I got the super-cool falcon patch (as it’s known in rvm) working on my Snow Leopard Macs, but had a few
issues with it, and not because of the patch itself:

For some reason, building any 1.9.3 in rvm on my machines screws up the Makefile and sticks in a circular reference to
building the ruby executable (as in, dependency ruby => ruby). Have to always rip out that last line in the Makefile
and make ; make install.

As rvm so succinctly warned me (I had no idea rvm requirements existed!), GCC & associated bits in the default Snow
Leopard XCode release are broken. I was getting segfaults on garbage collection within the cached load path part of
the patch, which is where the real speed came from. I installed osx-gcc-installer
and removed the rest of XCode, then recompiled and everything worked fine.

How much of an improvement for me? 3 RSpec runs of a big app went from 2:40.742s (1.9.2-p290 with load patch) to 1:48.104s (1.9.3-p0 with falcon patch).
A 33% speed increase. Sweet.

is the most basic form of an Object. Objects have two things: properties
and methods. When you attach other things to an object, like the String 300px
or the Number 0.75, you’re creating properties.

Methods are Functions attached to an object. When you extend jQuery.fn with your
own jQuery actions, you’re creating a new method:

$.fn.makeAllTranslucent=function(){$(this).animate({height:'300px',opacity:0.75});returnthis;};// now you have a shortcut!$('div').makeAllTranslucent();

You can add and change properties on an object after-the-fact, too:

varproperties={height:"300px"};ifconfirm("Want them translucent?"){properties.opacity=0.75;}// pass the object in as the first parameter$('div').animate(properties);

Because of the way JavaScript is designed, everything is an object: the
one you created with {curly: 'brackets'}, $.fn, standalone Functions,
everything. This lets developers do some very clever things with JavaScript.

// create a class constructorfunctionCat(name){this.name=name;}// add a method to the objectCat.prototype.hiss=function(){returnthis.name+" is hissing at you!";}// instantiate a CatvarmyCat=newCat("Fluffy");// work with our catconsole.log(myCat.name);// => Fluffyconsole.log(myCat.hiss());// => Fluffy is hissing at you!

But JavaScript lets you change this to whatever object you want using Function#apply:

functionDog(name){this.name=name;}vardog=newDog("Bruiser");// Cat.prototype.hiss is an object of type Functionconsole.log(Cat.prototype.hiss.apply(dog));// => Bruiser is hissing at you!

jQuery does this with the jQuery.fn#each method when looping over things like DOM elements. this
becomes a jQuery object for each DOM node in turn: