Thoughts Heap

Default mutable values in Python functions are WACK!

If you use mutable default values on functions, this will keep it state in recurrent calls:

def myAppend(x, L=[]):
    L.append(x)
    return L

#=============

>>> myAppend(1)
=> [1]
>>> myAppend(2)
=> [1, 2]

That’s seriously messed up o.O

Use form_for from Rails’ console

As a curious developer, I always like to inspect an objects guts on the console, that way I can now as much as I can from the class without reading the documentation. It was the time for the rails form_for view helper. I had no idea how to access that from the terminal whatsoever, so I googled a bit and I found nice tidbits that got me going pretty quickly.

However when you try to use a method like form_for, a NoMethodError is being thrown because you are trying to call url_for for on a nil instance. This is because the default console helper doesn’t have any controller assigned. This can be easily fixed:

helper.controller = ActionController::Integration::Session.new

However, when we try again the form_for method we get a new error.

NoMethodError: undefined method `protect_against_forgery?' for #<ActionController::Integration::Session:0x10608a460>

It seems that for some reason, the ActionController integration session doesn’t support the forgery protection, because this is not a biggie for what we need we are just going to stub the method, and go our own way.

s = ActionController::Integration::Session.new
class << s; def protect_against_forgery?; false; end; end
helper.controller = ActionController::Integration::Session.new

At this point we thought we were going get away with it… well no, it seems it never stops.

NoMethodError: You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.<<
    from /Users/roman/Sites/git/work/noomii/vendor/rails/actionpack/lib/action_view/helpers/text_helper.rb:32:in `concat'
    from /Users/roman/Sites/git/work/noomii/vendor/rails/actionpack/lib/action_view/helpers/form_helper.rb:281:in `form_for_without_haml'
    from /Library/Ruby/Gems/1.8/gems/haml-2.2.9/lib/haml/helpers/action_view_mods.rb:170:in `form_for'
    from (irb):16

The default helper object doesn’t have an initialized output buffer either!… luckily is easy to skip this one as well.

s = ActionController::Integration::Session.new
class << s; def protect_against_forgery?; false; end; end
helper.controller = ActionController::Integration::Session.new
helper.output_buffer = ''
f = nil
u = User.new
helper.form_for { |_f| f = _f }
f
>> #<Forms::ApplicationFormBuilder:0x105d7d330 @proc=#<Proc:0x0000000105d80648@(irb):16gt;

Oh the nice smell of victory!

Randoms and Haskell

Right now I’m on chapter 15 of my RWH book. This one talks about problems that get complicated without the use of a Monad, one of them is the System.Random API of Haskell. I’m going to start by introducing two typeclasses that this module exports for clarity’s sake:

• RandomGen: a RandomGen represents an state that holds the random input, I like to think of it like a stream of some sort (stdin, stdout).

• Random a: This typeclass is the abstraction of a Random value, all the common types of Haskell implement this typeclass (String, Integer, Float, Int, etc.)

What confused me for sometime, and I actually had to analyze throughly was how the interactions between the Random API and the IO Monad worked.

The following code was the one that got me thinking:

import System.Random hiding (next)

randomsIO :: Random a => IO [a]
randomsIO =
    getStdRandom $ \g ->
        let (a, b) = split g
        in (randoms a, b)

Where the IO [a] comes from?, if this anonymous function is returning a type ([a], RandomGen) instead of an IO [a]. This got me really confused, at some point I thought that a StdGen was an instance of an IO, but realized pretty quickly that IO is not a classtype, but an instance of Monad.

The best way to figure this out was checking the types of getStdRandom:

getStdRandom :: (StdGen -> (a, StdGen)) -> IO a

getStdRandom receives as it’s first parameter, a function that receives a StdGen and then return a tuple with the first position being some value of an anonymous type and second position being a (probably altered) StdGen, the return of the getStdRandom is whatever the parameter function returned on the first parameter of the tupple, wrapped in an IO Monad.

So the only way to work with a random function, is with the use of a getStdRandom like interface, why is that?. I’m assuming this is a way to provide “factory functions” for random generated data, a pretty clever choice (yet confusing, at least for me). Another important reason is that this way it will keep things pure, you don’t have to use the IO Monad on the random functions definitions.

Haskell is fun :-).

An implementation of a jQuery plugin using BDD

On Web apps, sometimes we want to avoid unnecessary requests, one of those situations happens when there is a form that represents a record, and the values of this record haven’t changed. On these cases you would like the user to send an update request only when the values of the record’s form actually changed, this technique is called “dirty form”, and is a very common practice.

I checked out some of the plugins out there to solve this problem, however, the functionality was sometimes sketchy. That’s why I started to implement my own solution, with a BDD approach using Screw.Unit.

In this post we will be covering some BDD practices, and at the same time I will be explaining what this plugins may offer to your plugin toolbox. Let’s start by pointing out the structure of a jQuery plugins project:

jquery-plugins/
|-- lib/
|-- spec/
`-- vendor/

In the lib/ folder we will have all the plugins we would like to develop, the spec/ folder will have all the test-related files and the vendor/ folder we will store all the frameworks needed in order to run the specs. In this project we will be using the livequery plugin, the Screw.Unit test framework and the Smoke mocking framework.

The spec/ folder will be composed (at least) by this two core files:

spec/
  |-- suite.html
  `-- spec_helper.js

The suite.html file will contain all the HTML scenarios needed for the jQuery plugins to work. This will look something like this (read the HTML comments):

<html>
  <head>
    <!-- first we import the jQuery framework -->
    <script src="../vendor/screw-unit/lib/jquery-1.3.2.js"></script>

    <!-- All vendor/ js files go here -->
    <script src="../vendor/jquery.livequery.js"></script>

    <!-- We import all the files needed by Screw.Unit -->
    <script src="../vendor/screw-unit/lib/jquery.fn.js"></script>
    <script src="../vendor/screw-unit/lib/jquery.print.js"></script>
    <script src="../vendor/screw-unit/lib/screw.builder.js"></script>
    <script src="../vendor/screw-unit/lib/screw.matchers.js"></script>
    <script src="../vendor/screw-unit/lib/screw.events.js"></script>
    <script src="../vendor/screw-unit/lib/screw.behaviors.js"></script>

    <!-- We import all the files needed by Smoke -->
    <script src="../vendor/smoke/lib/smoke.core.js"></script>
    <script src="../vendor/smoke/lib/smoke.mock.js"></script>
    <script src="../vendor/smoke/lib/smoke.stub.js"></script>
    <script src="../vendor/smoke/plugins/screw.mocking.js"></script>

    <!-- Here we include all our plugins from the lib/ folder -->
    <script src="../lib/jquery.when_changed.js"></script>

    <!-- We import all the spec files from the spec/ folder -->
    <script src="spec_helper.js"></script>
    <script src="jquery.when_changed_spec.js"></script>

    <!-- We include the stylesheet from Screw.Unit to have nice looking test results -->
    <link rel="stylesheet" href="../vendor/screw-unit/lib/screw.css">

    <!-- 
    We create a class scenario that will hold all the DOM needed for a test suite to work, but hides it from the 
    test HTML 
    -->
    <style>
      .scenario {
        position: absolute; 
        left: -9999
      }
    </style>
  </head>
  <body>
    <!-- This will be the place were all the test will grab the elements -->
    <div id="sandbox" class="scenario"></div>

    <!-- 
      We will have clean states (fixtures) for the plugins, all of them will
      have the postfix "-clean-state" to specify that this is a virgin state of a test environment
      In this example, for each test case we execute, the  "when-changed-clean-state" contents will be assigned to the 
      "sandbox" content.
    -->
    <div id="when-changed-clean-state" class="scenario">
      <form method="GET">
        <input type="text" name="text" value="some value">
        <textarea name="textarea">some value</textarea>
        <input type="checkbox" name="checkbox" value="1" checked>
        <input type="radio" name="radio" class="first" value="one" checked>
        <input type="radio" name="radio" class="second" value="two">
        <select name="select">
          <option value="1" class="one" selected>One</option>
          <option value="2" class="two">Two</option>
        </select>
      </form>
    </div>

  </body>
</html>

The spec_helper.js file will have all the common setup for the test environment.

// This function well put the HTML contents of the clean-state we are working on to the sandbox
function resetDOM(id) {
  $("#sandbox").html($("#" + id  + "-clean-state").html());
}

// If we want to put some global setup and teardown code, here is the place to put it
// for setup, inside the before block
// for teardown, inside the after block
Screw.Unit(function() {

  before(function() { 
  });

  after(function(){
  });

});

So, now that we have established our test environment, its time to do the implementation of the plugin, we start by defining the specs for it on the spec/jquery.when_changed_spec.js file, this file will represent the tests made to the lib/jquery.when_changed.js file.

Screw.Unit(function(){

  describe("$.fn.whenChanged", function(){
    
    // We establish a new clean state for each test case
    // with a resetDOM invocation before each spec.
    before(function(){
      resetDOM("when-changed");
    });

    describe("invoked on an input:text", function(){
      it("should invoke the given function when value has changed on keyup");
      it("should not invoke the given function when value has not changed on keyup");
      it("should not consider new blank text on the edges as a new text");
      it("should call the reverse callback when the value returns to the same");
    });

  });

});  

So, in the given spec file we specified (for now) the behavior of the plugin when we are interacting with an input text field. we expand this definitions by giving actual test code to each spec.

describe("invoked on an input:text", function(){
  
  // first we define the setup for each spec, assign the plugin behavior to an input
  before(function(){
    // When the value of the input:text change it's original value, an alert will be called.
    $("#sandbox input:text").whenChanged(function(){
      window.alert("The input text has changed it's value");
    });
  });
  
  it("should invoke the given function when value has changed on keyup", function(){
    mock(window).should_receive("alert").exactly(1).with_arguments("The input text has changed it's value");
    // the event checking will be raised by a keyup event
    $("#sandbox input:text").val("some random value different than the original").trigger("keyup");
  });
});

On the previous code, we are using the Smock’s method mock, this will do a temporary replacement of the window.alert function, and will check that this is being called exactly 1 time, and with the argument “The input text has changed it’s value”. This way we can check that the callback assigned on the whenChanged invocation was actually being called when necessary. Next step is to implement a whenChanged function that is simple enough to make the spec pass.

(function($){
  
  $.fn.whenChanged = function(callback) {
    // we store the old values on each element
    $(this).each(function(){
      $(this).data("jquery.whenChanged.oldValue", $(this).val());
    });
    
    // we assign a keyup event binding using livequery
    $(this).livequery("keyup", function(){
      var oldValue = $(this).data("jquery.whenChanged.oldValue");
      var newValue = $(this).val();
      if (oldValue !== newValue) {
        callback.apply(this);
      }
    });
    
    return this;
  };
  
})(jQuery);

So we implemented the most simple solution possible that makes our specs run (Just check the suite.html file on a browser and you should have the feedback right away), now we continue developing adding more specs and changing the code as we go.

it("should not invoke the given function when value has not changed on keyup", function(){
  mock(window).should_receive("alert").exactly(0);
  $(this).trigger("keyup");
});

We added other method that didn’t need any code to be changed, in this case we are checking that window.alert is not being called at all. Awesome let’s continue with the next spec.

it("should not consider new blank text on the edges as a new text", function(){
  mock(window).should_receive("alert").exactly(0);
  $(this).val("  some value   ").keyup();
});

At this point, this specs fails with our current implementation, we are not stripping the spaces on the border, this can be fixed easily.

$.fn.whenChanged = function(callback) {

  $(this).each(function(){
    // NOTICE: Invoking $.trim here!
    $(this).data("jquery.whenChanged.oldValue", $.trim($(this).val()));
  });
  
  $(this).livequery("keyup", function(){
    var oldValue = $(this).data("jquery.whenChanged.oldValue");
    // NOTICE: Invoking $.trim here!
    var newValue = $.trim($(this).val());
    if (oldValue !== newValue) {
      callback.apply(this);
    }
  });
  
  return this;
};

Now that we have stripped the spaces on the old value storage, when we check the stripped new value, it will still be the same as the old value and the callback won’t be called. Finally we have to add the reverse callback functionality.

before(function(){
  // When the value of the input:text change it's original value, an alert will be called.
  $("#sandbox input:text").whenChanged(
    function(){
      window.alert("The input text has changed it's value");
    },
    function(){
      window.alert("The input returned to the same value");
    }
  );
})

it("should call the reverse callback when the value returns to the same", function(){
  mock(window).should_receive("alert").exactly(1).with_arguments("The input text has changed it's value");
  $(this).val("Changing input value").keyup();
  mock(window).should_receive("alert").exactly(1).with_arguments("The input returned to the same value");
  $(this).val("some value").keyup();
});

So at this point, this spec will break previous specs, this is because the alert function is being called, even when the value is not changed, so mock(window).should_receive("alert").exactly(0) won’t work.

// NOTICE: we change this to alert with an specific argument.

it("should not invoke the given function when value has not changed on keyup", function(){
  mock(window).should_receive("alert").exactly(0).with_arguments("The input text has changed it's value");
  $(this).trigger("keyup");
});

it("should not consider new blank text on the edges as a new text", function(){
  mock(window).should_receive("alert").exactly(0).with_arguments("The input text has changed it's value");
  $(this).val("  some value   ").keyup();
});

At the same time we need to add a new callback parameter to the whenChanged method.

$.fn.whenChanged = function(callback, reverseCallback) {
  $(this).each(function(){
    $(this).data("jquery.whenChanged.oldValue", $.trim($(this).val()));
  });

  // we assign a keyup event binding using livequery
  $(this).livequery("keyup", function(){
    var oldValue = $(this).data("jquery.whenChanged.oldValue");
    var newValue = $.trim($(this).val());
    if (oldValue !== newValue) {
      callback.apply(this);
    }
    else {
      reverseCallback.apply(this);
    }
  });

  return this;
};  

Now this code should run successfully and we now have covered our bases with input:text selectors, I could talk about how added support to other form input types, but I rather not in order to keep this short. Some thoughts I can share though is that the whenChanged method changed A LOT, after realizing that each type of input has it’s own gotchas, I created an specific whenChange method for each kind of form element. All in all… I was always sure that nothing broke on this process because the specs always told me if anything I was doing added any bug. Uhmmm the smell of good test code on late nights is incredible.

I hope this post can help you get some guidelines on how to get started with development of Javascript code using BDD, one word of caution though: testing effects in Javascript is a nasty challenge, you may like to pass an option to your method specifying if you want effects or not. check your code doesn’t depend on setTimeout invocations, take my word, is a BIG PAIN to test that.

Good luck with your BDD sessions.

“Object is not missing <ClassName>!” + Amazon::S3

Today at the office, we had one of the weirdest Rails errors I have ever encountered

rails-project/vendor/rails/activesupport/lib/active_support/dependencies.rb:417:in `load_missing_constant’: Object is not missing constant Photo! (ArgumentError)

We looked up into the stack trace and we found the problem was being caused by this line:

vendor/rails/activerecord/lib/active_record/base.rb:2195:in `compute_type’

When we checked the code, we found a dead-end with a class_eval invocation (oh meta-programming damn you on debugging times)

# Returns the class type of the record using the current module as a prefix. So descendants of
# MyApp::Business::Account would appear as MyApp::Business::AccountSubclass.
def compute_type(type_name)
  modularized_name = type_name_with_module(type_name)
  silence_warnings do
    begin
      class_eval(modularized_name, __FILE__, __LINE__)
    rescue NameError
      class_eval(type_name, __FILE__, __LINE__)
    end
  end
end

This error was caused in the first place because we created a new environment for running the app, we checked the files on config/environments/ to see the differences between them; we didn’t find that many, commenting the few lines that were different didn’t make any change.

A (very long) while later, we noticed that the config/amazon_s3.yml file didn’t have a set of keys for the environment we were trying to run, after adding them everything went by pretty smoothly.

What pissed me off (and probably this guy as well) is that the error displayed didn’t make any sense at all, wtf is “Object is not missing constant Photo!”?, seriously? I investigated a bit further and it seems to be related with the autoload feature of the Rails framework, geez thanks for the cryptic error message ¬¬

I hope this info helps some unfortunate developer out there.

The jQuery DSL

For the last 4 months I’ve been using jQuery for Javascript development. To be honest, I didn’t got started before with jQuery because it didn’t seem too practical to me (no Class approach), but after looking carefully at the plugin model, it was truly a revelation of a good API for development.

So I started to accommodate to the jQuery’s way of things, and one of the API’s that got my interest in the past 2 months was the traversal one. I mean, what were those methods .find(), .end() and .endSelf(). Why I would go and use those methods when my standard code was always like:

$("#container .sub-container .items").click(..);
$("#container .sub-container .other-items").hover(..);
$("#container form.create-item").ajaxForm(..);

and never needed them. I guessed that the way I was doing things wasn’t the jQuery’s way; I mean, I could rewrite the previous code like this instead:

$("#container").
  find(".subcontainer").
    
    find(".items").
      click(..).
    end().
    
    find(".other-items").
      hover(..).
    end().
    
  end().
  
  find("form.create-item").
    ajaxForm().
  end().
end();

Of course at first sight it didn’t look that good, but I was not too sure that it didn’t look bad either, it was just different. So I just let time tell me if it was good enough. I left that implementation and came back a month later, the WTF/min were almost none, I did still understand the code right away, it actually looked like a CSS funky syntax to me.

After deciding that it was indeed a good way to do things, I just started to look at the pros & cons of this funky syntax vs the normal syntax I used before. This is what I got

Funky syntax Pro’s

• The order of the code is in a hierarchical way, representing the DOM position.
• If the main container is not there (e.g #container) the child selectors will not be called, making the code “more efficient”.
• When multiple elements have the same behavior, a new HTML class that represented the behavior is exposed. For example, if you require 2 out of 3 forms in a container to be an AJAX form, you wouldn’t replicate the same instructions to each selector, instead you will create a common selector for the 2 forms by adding a new HTML class.
• The lookup for elements will be faster on every nesting, that is because the lookup will be done from the parent, not from the main document.

Funky syntax Con’s

• .live() method wouldn’t work, this method only works on un-nested selectors. However, you may use the livequery plugin.
• Initially it is a difficult syntax for other developers, 3 out of 4 developers in my team did say that it was confusing, but as I stated before, probably is more different than confusing.

Classic syntax Pro’s

• Would be the approach used by most of developers.
• .live() can be used without any problems.
• Probably there are other benefits that I’m taking from granted ¬_¬.

Classic syntax Con’s

• A lookup from the HTML document for every element.
• Lookups are being made even when there is no parent element. (This could be easily avoided with an if statement, but still).
• It’s harder to spot the common behavior, different selectors factor.

As you can see, there are some benefits and some pros attached to the use of this jQuery DSL; I don’t know if this is the way to go but I’m certain that I’m not the first one who came up with this (I haven’t read any book of jQuery yet). If you could leave some thoughts about what is the one you prefer and why, it would give much value to this discussion.

Until next time.

(ActiveRecord::Callbacks + acts_as_taggable).gotcha?

Have you ever been in a situation where you have this strange bug, that takes you more time than expected to find out what (tha hell) is  going on? That happened to us (me and my team) last Rails Rumble when we were trying to have some stuff done after the creation of an element that had some tags associated to it.

The code looked something like the following:

## app/models/entry.rb
class Entry < ActiveRecord::Base
  
  ##################
  ### Extensions ###
  ##################
  acts_as_taggable
  
  #################
  ### Callbacks ###
  #################
  after_create :do_something_with_tags
  
  def do_something_with_tags
    self.tags.each do |tag|
      # do something with tag
    end
  end
  
  protected :do_something_with_tags
  
end

## app/controllers/entries_controller.rb
class EntriesController < ApplicationController
  # ...
  def create
    @entry = Entry.new(params[:entry])
    entry.tag_list = params[:tags]
    if entry.save
      # success
    else
      # failure
    end
  end
  # ...
end

The problem was that the do_something_with_tags callback was not doing what it supposed to. At first we thought it was a problem with our implementation, but after some debugger sessions, we found out what the real problem was. The tags array didn’t correspond with the value of the the tag_list that was being assigned on the controller level.

After having some thoughts I decided to go inside the acts_as_taggable_redux source code (the version of acts_as_taggable that we were using), and I found something pretty peculiar related to the tag creation; This tags were being created on an after_save callback. The extract of the acts_as_taggable looked something like this:

def acts_as_taggable(options = {})
  has_many :taggings, :as => :taggable, :dependent => :destroy, :include => :tag
  has_many :tags, :through => :taggings, :order => 'LOWER(name) asc', :select => "DISTINCT tags.*"

  after_save :update_tags

  extend ActiveRecord::Acts::Taggable::SingletonMethods
  include ActiveRecord::Acts::Taggable::InstanceMethods
end

As you can tell, an after_save was invoking this callback update_tags; after looking more closely, this method was the one that created the tag list, (the one we needed for our custom callback do_something_with_tags to work). So I checked in the Rails documentation page the precedence of callbacks just to be sure which one was being invoked first. Our main problem was that our callback was an after_create, and those get executed after the after_save callbacks.

To solve this issue, we simply called the update_tags callback directly on the first line of our callback, making the final do_something_with_tags look something like this:

def do_something_with_tags
  update_tags # invoke callback by hand
  self.tags.each do |tag|
    # do something with tag
  end
end

Because the acts_as_taggable library is so well implemented (at least the redux version, I’m not sure about others), the second time the update_tags method was being invoked simply returned without repeating the process of tag creation again.

Small issues like this are the ones that keep you having debugging fun for hours. I hope this may help you if you are this kind of trouble.