Recently, I had to integrate VCR with MiniTest::Spec. MiniTest by default runs tests in random order. Additionally, there is no after(:all) hook available in MiniTest. When integrating MiniTest with VCR, tests which would have otherwise been unaffected by order may now produce false failures due to VCR.

This is when I came up with a rather simple solution to have each test run in isolation and have their own specific cassette. At my top level describe block for each test file, I have a before block that sets up a VCR cassette for each expectation. Here’s the code for this solution (and a gist):

describe "Something" do
  before do
    # __name__ defined in MiniTest::Unit::TestCase
    VCR.insert_cassette __name__
  end

  after do
    VCR.eject_cassette
  end
end

Now every single it or specify block that makes one or more HTTP requests will generate and use it’s own cassette. Granted, this solution is somewhat verbose in the amount of cassettes that are generated. I feel however, this is a reasonable trade off for its sheer simplicity!

Update: I added this solution and some more general information about MiniTest to VCR’s wiki.

Below is the configuration for our maintenance page:

error_page 502 =200 @maintenance;
location @maintenance {
    root /path/to/maintenance;
    try_files $uri $uri/ /index.html =503;
}

There are a lot of things going on in this configuration. First off, we are using a named location with an error_page directive to “catch” the 502 error. Secondly, the =200 in this directive is used to set the response code to 200. This is done so browsers properly render the page as well as any CSS or images that are included.

Finally, we use the try_files directive in order to first try and serve the requested file (for CSS and images). If these files are not found, it will then try and serve an index.html file. If for some reason index.html is not available, we fallback to the default 503 error page which is more appropriate than the 502 page.

While working on BreakBase, I can across a bit of an issue with creating data attributes using Pylons’ Webhelper tags. Attributes are generally assigned in Webhelper tags using Python kwargs. This is an issue since data attributes require a dash character, which results in invalid Python code. Additionally, we use Mako templates so using an inline dict object is not an option since it will clash with the Mako delimiters.

Thus, I created a really simple helper that we can use in the meanwhile until data attribute support is added to Webhelpers directly. Here the helper method definition (and a github gist):

def data_attrs(**kwargs):
    attrs = {}
    for suffix in kwargs:
        key = "data-%s" % suffix
        attrs[key] = kwargs[suffix]

    return attrs

To use this helper, simply do the following:

${ h.link_to("link text", "/some/url", **h.data_attrs(some="data", available="here")) }

Which will produce the following valid markup:

<a href="/some/url" data-some="data" data-available="here">link text</a>

$('#id').text('new text');

And wondered why the code wasn’t working only to find out the selector was wrong. jQuery.whiny.js attempts to solve this problem by altering the jQuery library so the jQuery() method will create a console warning if an empty jQuery object returned.

In the above example, if ‘#id’ returned an empty jQuery object you’d see the following console warning:

jQuery was called with a selector of '#id' and returned an empty object

Please note, this is only for dev purposes. To get the jQuery.whiny.js, head over to the github project. Additionally, the name of this script was inspired by “whiny nil” from Ruby on Rails.

jQuery allows you create HTML elements on the fly via the jQuery() method. Creating new HTML elements using this technique is common in the jQuery world since it results in more readable, jQuery-esque code.

Potential client-side code injection issues can arise if malicious input is passed to this method. Consider the following example:

$("<img src='/' onerror=alert('xss');>");

This will result in client-side code execution (mainly an alert displaying the string ‘xss’). Nevertheless, it is possible to execute arbitrary client-side code via this vector. To see this in action, check my overly contrived demo\proof-of-concept available here.

Now you should be asking yourself, what does this mean for me as a jQuery developer? In reality, not a whole lot. The main point here is that developers should always be mindful of what input is passed to the jQuery() method. Much like how developers need to be mindful of user-input in order to prevent other XSS issues and DB-level injections.

The bottom-line: never trust user-input.

Update: This issue has now been partly addressed by jQuery 1.6.3. Refer to bug #9521 for details on the fix. In short, #id are prioritized over <tag> selectors.

The issue in general however, is still possible with selectors that are not #id based. Take a look at my second overly contrived proof-of-concept here which uses a .class selector instead of an #id one.

The idea behind BreakBase is simple: play your favorite board games with anyone you’d like. It’s totally free to use and you don’t even an account to start playing! So, head on over to BreakBase and start playing.

PS: There a lot more in store for BreakBase, including a ton of other games!

After a little poking around on Facebook, I realized it’s pretty easy to add the same functionality into Facebook chat. I decided to write a simple Chrome extension to prototype the idea. You need to enable experimental extensions for any of the following code to work.

experimental.webInspector.resources.onFinished.addListener(function(resource){
  if (resource.request.url.match(/channel\.facebook\.com/)) {
    resource.getContent(function(content, encoding){
      if (content == null) return;

      if (content.match(/"type":"typ"/) && content.match(/"st":1/)) {
        var from = content.match(/"from":\d+/);

        experimental.webInspector.log('You sense a disturbance in the force from... ' + /\d+/.exec(from)[0]));

      }
    });
  }
});

When someone is typing a message to you, their browser will make a POST to ‘ajax/messaging/typ.php’. Facebook will then send your browser a message that contains an object with a ‘type’ property of ‘typ’ and ‘st’ property of 1. This extension simply looks for requests made to Facebook and attempts to find responses that meet said criteria.

This idea could perhaps be further flushed out via Firefox extensions. Chrome’s extension design and APIs make such a thing difficult (actively viewing requests and responses made by the browser). Such things are easier with Firefox where less restrictions and sandboxing for extensions are in place. Such an extension should likely even open the the chat tab with the target user (and of course display the ‘You sense a disturbance in the force from…’ message).

Makes sense, but it took me a while to figure this one out since it is does not seem to be documented anywhere.

This plugin functioned as expected and something can certainly be said for sheer simplicity that this particular tree structure employs.  The complication arose when my application called for a full select of all the descendants from a given node.  This particular tree structure doesn’t support an efficient way to grab all of the corresponding descendant records.

So I decided to implement a Materialized Path on top of my simple tree structure by adding a path column to the table. Here is a sample of what my tree table would look like.  For the sake of the example, we’ll call this table Nodes:

Each path is constructed by taking a given node’s parent path and concatenating it with the parent ID.  I like to prefix each ID number with the first letter of the models name, hence the “N” from “Nodes”.  Keep in mind that any piece of unique data can be used, it doesn’t need to be the ID number. My analytics system uses an alternative string of unique data for the materialized path.

Now grabbing all of the descendants for node 2 is quite simple really; here’s a sample SQL query:

SELECT * FROM nodes WHERE path LIKE "N2%";

The Rails code for adding this functionality is equally simple.  A before_create callback in the given model will do the trick.  Here is a quick sample:

before_create do |n|
  self.path = "#{n.parent.path}N#{n.parent.id}"
end

Also note, that depending on the data type used for the path column, you maybe limited on how deep the descendants can go.  For instances, a varchar(255) column only allows 255 characters, so if each node takes up an average 5 characters we’re limited to 51 nodes.  While this may seem like a lot, it’s something to just keep in mind when implementing this solution.