Filtering ExtJs Grid

ExtJs Grid provides a nice, quick way to build a UI that can handle a lot of tabular data and support the operations you’d typically like to perform on that data (sorting, filtering). It can be hard to style, but is great for whipping up admin CRUD functionality.

One thing that seems hard to do with it out of the box, however, is trigger filtering directly from your javascript, rather than via the UI.

Ext.grid.Panel does in fact expose the requisite properties and methods to accomplish this, but they’re a bit hard to track down, and not part of the official public API. This gist, GridFilteringExtensions.js, adds some methods to Ext.grid.Panel that make this easier. It probably won’t accomplish everything you want to do, and hasn’t been tested in a wide variety of situations, but it was exactly what I needed, and may be a good base from which to build.

Note that before manually setting a filter for the first time, you’ll need to call `createFilters`.

I give you wings

A beautiful and bitter poem by Theognis, addressed to his beleaguered young lover Kurnos.

I give you wings. You’ll soon be lifted up
Across the land, across the boundless crests
Of ocean; where men dine and pass the cup,
You’ll light there, on the lips of all the guests,
Where lithe, appealing lads will praise you, swelling
Their song to match the piper’s sweet, shrill tone.
At length, my boy, you’ll enter Hades’ dwelling,
That black hole where departed spirits moan,
But even then your glory will not cease,
Your well-loved name will stay alive, unworn;
You’ll skim across the mainland, over Greece,
Over the islands and the sea, not borne
By horses, Kurnos; you’ll be whirled along
By violet-crowned maids, the Muses; yours
Will be each practiced singer’s finest song,
As long as light exists and earth endures.
I give you this, for what? To be reviled–
To be betrayed and lied to, like a child.

Simulate typekit FOUT on OSX with IPFW

A downside of using Typekit’s async javascript snippet is FOUT (Flash of Unstyled Text).

In order to reproduce what this will look like in your app/website it can be helpful to artificially slow down your connection to Typekit. This can be accomplished via ipfw (no guarantee that these commands will work exactly as below for other unix variants).

First get the IP address of by pinging it (for me it is currently Then:

sudo ipfw add pipe 1 ip from to any

sudo ipfw pipe 1 config bw 80kbit/s plr 0.05 delay 50ms

Play with the values 80 to change bandwidth, 0.05 to change packet loss ratio (you can just remove this as well), and 50 to change latency.

When you’re done (note that this will flush all existing ipfw rules):

sudo ipfw flush

Graphing changes in file size across git commits

Both as an excuse to try to learn gnuplot and as a way to track the growth of compiled javascript and css assets files, I was looking for a way to grab the size of a given file across a series of git commits, and end up with output like this:

# size commit                                   date
439323 d4d09e047d50388180a1e317efc61af5d8961275 20130201
439323 fd30e151e35efba1bda65488e621c7338895542e 20130130
439241 6ce650d7e97add955b7cd07150732890c0edaf49 20130129
439241 3c1d2aec69f874926965843800163be71ec5f376 20130128

If the name of the file stays the same, it turn out this is pretty simple. The following git command will show the size of the file for the commit in question:

git ls-tree -r -l <COMMIT> <PATH>

So we can do something like

git ls-tree -r -l HEAD~$COUNTER compiledjs.min.js

in a bash script and increment $COUNTER as much as we want, grabbing the file size with some ugly use of tr and cut, e.g:

git ls-tree -r -l HEAD~39 compiledjs.min.js | tr -s ' ' | tr '\t' ' ' | cut -d ' ' -f 4

But if the name of the file changes across commits, as it will if you are tagging it with a date or SHA1 for cache-busting, this approach won’t work. The approach I came up with, which is hacky, involves creating and deleting temporary branches based on HEAD~1, HEAD~2, etc., and getting the requisite date, file size, and commit info by pattern-matching on the name of the file in question.

Shell script to accomplish this, along with some basic gnuplot commands to plot the output, here:

closure compiler externs for underscore 1.4.4

Closure Compiler externs for underscore 1.4.4 are now available.

Underscore 1.4.4 adds two new functions, _.findWhere, and _.partial.

Also pushed some fixes to 1.4.3 externs:

  • typo in `properties` param for _.where
  • a bunch of methods should be able to operate on Arguments objects as well as Arrays. Previously, only Arrays were noted as valid params by the externs.

Simplify QAing the js popup windows in your web app

QAing js popup windows in your web app is a pain in the ass. It’s easy to miss windows in obscure corners of your UI and can be hard to recreate the circumstances under which they’re shown, and the various states that determine how and when they appear. Automated js tests with a library like Qunit or Jasmine, while great, don’t really help when you need to make sure things look a certain way.

Fortunately, if you make a couple assumptions that I think hold true for a majority of web apps, we can simplify this testing process substantially.

Closure Compiler externs updates

Just pushed fixes and updates to my Closer Compiler externs for underscore, and created a repo for Qunit externs (which is probably not of any use to anyone, but is used by for testing accuracy/completeness of underscore externs).


  • Externs for latest underscore (1.4.3).
  • Some fixes to 1.3.3 externs, indicating that more methods may return wrapped objects (this is still incomplete).
  • Tests for externs file completeness/accuracy by running underscore’s own qunit tests through closure compiler. The output (using advanced compilation) is nasty and contains a lot of errors, but most of them are irrelevant. Some do point to legitimate issues, mostly related to uncommon ways of passing arguments to various methods.


  • Externs missing for `throws`, callbacks, and configuration. Mostly complete.