Now that you’re expecting a scope puzzle, what will the following JavaScript print? (Ignoring the line numbers, of course, which are here to aid in discussion.)

 1:  var foo = 1;
 2:
 3:  function bar1() {
 4:   print("A: " + foo );
 5:  }
 6:
 7:  function bar2() {
 8:   print("B: " + foo );
 9:   var foo = 2;
10:   print("C: " + foo );
11:  }
12:
13:  function bar3() {
14:    print("D: " + foo );
15:    eval("var foo = 2;")
16:    print("E: " + foo );
17:  }
18:
19:  bar1();
20:  bar2();
21:  bar3();

No peeking…

A: 1
B: undefined
C: 2
D: 1
E: 2

“A” is easy. Since foo is a “free variable” (i.e., not defined within function bar1), the interpreter goes up the scope chain, and finds the global foo, defined on line 1.

For bar2, “C: 2″ is obvious — it’s “B: undefined” that lets you in on the magic under the hood. You sort of expect to see “B: 1″ (or a compiler error.) However, JavaScript interpreters scan-ahead, searching for variable definitions (e.g., var statements) when parsing a code block. The interpreter sees/re-writes bar2 like this:

 1:  function bar2() {
 2:    var foo;
 3:    print("B: " + foo );
 4:    foo = 2;
 5:    print("C: " + foo );
 6:  }

With that definition, “B: undefined” makes perfect sense.

To short-circuit the magic, bar3 uses eval() to do it’s trickery. At line 14, foo still points to the global foo, much like in bar1; However, the eval statement on line 15 modifies the local scope, introducing a new, local foo. By line 16, “E: 2″ is using the newly introduced foo.

The lesson: Even though JavaScript allows you to declare variables at any point within a block, putting your var statements at the beginning of the block can help eliminate scope confusion around whether an inner- or outer-closure contains the correct value.

Is JavaScript’s var a let or let*? It’s easy to find out using the following:

 1:  var x = 2, y = 3, z = x + y;
 2:  print(z);

Is this legal? Will it print ’5′?

//@ifdef IE6_BUILD
 ...custom IE6 code here
//@else
 ...code for other browsers here
//@end

Of course, this goes against the idea that your JavaScript would remain usable for development without needing to be processed, but it’s just an example. Longer term, I hope to have a different approach available that will allow conditional code substitution so that browser specific optimizations won’t get in the way of an easy development/test/debug process.

Other new additions:

• Test files are now picked-up automatically when named correctly. This makes it painless to add more tests.
• Added support for setting DEFINE flags from the command-line. Handy if you automate builds for different environments (like IE6 vs. the rest of the world.)
• Added support for #ifdef and #ifndef

The next big hurdles will be how to handle else statements, and coming up with a reason to implement some type of #inline capability.

[Note that before writing this I did seek out existing implementations, and found js-preprocess to be the most interesting; However, I needed something that would work as part of an existing build chain, so authoring the tool in Python instead of JavaScript made more sense.]

Currently, jsmacro is poorly named, as I didn’t write the macro system that was in my head. Instead, it’s currently a basic preprocessor supporting only DEFINE and IF statements, which happened to be all I needed at the time. Usage works like this:

Input JavaScript

  //@define DEBUG 0

  var foo = function() {
    //@if DEBUG
    alert('This.');
    alert('That.');
    //@end

    print "Hi";
  };

Pass the above JavaScript through jsmacro from the command line like this: ./jsmacro.py -f infile.js > outfile.js (assuming the files are all in the same directory), and you get the following:

Output JavaScript

  var foo = function() {

    print "Hi";
  };

The tool has registered the variable ‘DEBUG’as 0 (i.e., false), so the conditional include statements omit the alert() calls. If DEBUG had been set to 1 (i.e., true), the alert() statements would remain (though all jsmacro instructions would be removed either way.)

One of the tricky things about doing macros or preprocessing in JavaScript is that I wanted the code to be valid JavaScript before the tool is run (which is why C-preprocessors won’t work.) The idea is that you develop as you normally would, but wrap your debug and testing code in conditional jsmacro statements so that they are automatically removed as part of your build process.

There’s nothing fancy about the current implementation (it’s a crude state machine that scans line-by-line, top-to-bottom looking for regex patterns and deciding whether to output the line of not.) Crude as it may be though, it completely solved a problem for me, and hopefully it will help you out as well.

Take a look at this sample:

import os

try:
  is_dev = os.environ['SERVER_SOFTWARE'].startswith('Dev')
except:
  is_dev = False

is_prod = not(is_dev)

If the is_dev and is_prod variables are exposed to your templates, you can do something like this:

{% if is_prod %}
 {% include "analytics.html" %}
{% endif %}

Hope this helps!

Basic authentication is often added to sites (or directories) using a .htaccess file and something like this:

AuthUserFile /home/foo/.htpasswd
AuthName "Private Area"
AuthType Basic

<Limit GET>
require valid-user
</Limit>

…but you can also do basic authentication on-the-fly by reading/writing HTTP Headers. To ask the browser for a user/password, you can raise a 401 error, and write a “www-Authenticate” header containing something like ‘Basic realm=”Secure Area”‘. To read the user/password, look for an Authorization header, grab it’s value, Base 64 decode it, and you should have a string in the form of “user:password”.

Here’s how you might handle it with Google App Engine. (Well, really you might use a decorator.. but this example is easier to explain.)

class AuthTest(webapp.RequestHandler):
  def get(self):

    # Wrapping in a huge try/except isn't the best approach. This is just
    # an example for how you might do this.
    try:
      # Parse the header to extract a user/password combo.
      # We're expecting something like "Basic XZxgZRTpbjpvcGVuIHYlc4FkZQ=="
      auth_header = self.request.headers['Authorization']

      # Isolate the encoded user/passwd and decode it
      auth_parts = auth_header.split(' ')
      user_pass_parts = base64.b64decode(auth_parts[1]).split(':')
      user_arg = user_pass_parts[0]
      pass_arg = user_pass_parts[1]

      checkAuth(user_arg, pass_arg) # have this call raise an exception if it fails

      self.response.out.write(template.render('templates/foo.html', {}))

    except Exception, e:
      logging.debug("AuthTest Exception: %s" % (e))

      # Here's how you set the headers requesting the browser to prompt
      # for a user/password:
      self.response.set_status(401, message="Authorization Required")
      self.response.headers['WWW-Authenticate'] = 'Basic realm="Secure Area"'

      # Rendering a 401 Error page is a good way to go...
      self.response.out.write(template.render('templates/error/401.html', {}))

That’s all there is to it.

If you want to programatically write an Authorization header (as in, sending authentication credentials to another site, like the Twitter API’s, for example) you’ll do something like this:

request = urllib2.Request(url)
request.add_header('Authorization', "Basic %s" % (base64.b64encode("%s:%s" % (user, password))))

Enjoy!

Here it is: conway-life.py

There’s not much to it, but it does show a software pattern I’ve been using frequently with NodeBox. Many of the NodeBox examples make heavy use of non-namespaced, global variables. I suppose it makes simple code easy to read for those new to programming, but it’s a habit you’ll want to break before your code starts getting more complex.

What I’ve found helpful is to create a World/Universe/Controller/Stage object that drives the rendering. Instead of using multiple globals in draw(), the controller object keeps the main parameters as local properties, and instantiates any needed objects in it’s __init__(). This approach prevents global variables names from clashing, and allows for creative reuse of rendering components.

Enjoy!

For those unfamiliar with NodeBox,

“NodeBox is a Mac OS X application that lets you create 2D visuals (static, animated or interactive) using Python programming code and export them as a PDF or a QuickTime movie.”

It uses PyObjC to embed a Python runtime into an OS X native application, and fits into the same toolbox as Processing and openFrameworks. It’s a bit slower to run complex animations in, but you’re coding in Python, you get the gorgeous fonts and anti-aliasing you’d expect on OS X, and it provides easy access to some OS X native libraries, like Core Image. For a quick look at what it can do, check out the NodeBox gallery.

NodeBox includes it’s own Python build, which is nice for portability and reliability, but it uses a custom sys.path that doesn’t look for Python packages you might already have installed on your system. There are a few ways to deal with this:

1. You can install your packages into NodeBox’s path, ie., ~/Library/Application\ Support/NodeBox/ — meaning that you can use them from NodeBox, but not from other scripts…
2. You can import sys in your NodeBox code and manually modify the sys.path value to add your existing packages…
3. You can install packages into your system site-packages directory, and sym-link them from NodeBox’s directory…
4. You can make NodeBox use your system packages instead of it’s own by sym-linking ~/Library/Application\ Support/NodeBox to your site-packages directory of choice (ex., /Library/Python/2.5/site-packages)

For this exercise, I’ll be adding pymunk (Python bindings for the Chipmonk physics library) to NodeBox using option #3: Installing pymunk globally, and sym-linking from NodeBox’s package directory. This allows me to run the pymunk examples from the command-line (which use PyGame and Pyglet), but still use pymunk from NodeBox. This may not always be the best solution, so you’ll have to pick what’s right for your needs.

Let’s get started.

Pymunk (at the time of writing) includes it’s own copy of the Chipmunk source code, making this whole process rather easy. Once you’ve downloaded and uncompressed the pymunk source, cd into it’s directory and build chipmunk using:

> python setup.py build_chipmunk

Now you can build and install pymunk:

> python setup.py install

This will install an egg (which I normally hate dealing with, but that’s another story.) If you don’t want the egg, just copy the pymunk directory into your site-packages.

Now we’ll add pymunk to NodeBox’s path. My pymunk is in /Library/Python/2.5/site-packages/, so I’ll:

> cd ~/Library/Application\ Support/NodeBox

> ln -s /Library/Python/2.5/site-packages/pymunk-0.8.1-py2.5.egg/pymunk .

Finally, NodeBox needs access to libchipmunk. I used this approach:

> cd /Applications/NodeBox/NodeBox.app/Contents/MacOS/

> ln -s ~/Library/Application\ Support/NodeBox/pymunk/libchipmunk.dylib .

We should be done! Fire up NodeBox and try an include pymunk to see if it loads. If you don’t see any error messages, you’re good to go.

If you’re new to pymunk (as I was until this week), head over to the Slide and Pin Joint tutorial to see how it works. The example is written for PyGame, so you’ll be doing a little rewriting to bring it into NodeBox.

The following screenshot shows the Slide and Pin Joint demo within NodeBox using my take on porting it. I’m having a little trouble with the slide joint, but you can check out my code if you’re curious: slide_and_pinjoint_example.py

CmdUtils.CreateCommand({
  name: "expandlinks",
  homepage: "http://eriksmartt.com/blog/",
  author: { name: "Erik Smartt"},
  license: "MPL",
  preview: "Expands all hyperlinks, showing link locations.",
  execute: function() {
    var doc =  Application.activeWindow.activeTab.document;
    jQuery(doc.body).find("a").each(function(i) {
        jQuery(this).after(" &lt;<a href='" + this.href + "'>" + this.href + "</a>&gt;");
    });
  }
})

And yes, it will be much easier to subscribe to these commands once I gather them into a JS file for Ubiquity. For now, you can copy/paste into the command editor if you’re interested in trying it out.

CmdUtils.CreateCommand({
  name: "charcount",
  takes: {"text to count chars in": noun_arb_text},
  preview: function( pblock, argText ) {
    pblock.innerHTML = argText.text.length;
  }
})

Update: See comments below for Ubiquity 0.5 compatibility updates

Extending Ubiquity’s vocabulary is done via JavaScript, and the developer docs are pretty straight forward.

The docs cover Hello World, so I figured that the next best intro test would be a way to lookup stock charts and quotes. Here’s the result of a few minutes hacking on it:

CmdUtils.CreateCommand({
  name: "tik",
  takes: {"stock ticker symbol": noun_arb_text},
  preview: function( pblock, argText ) {
    var charturl = "http://chart.finance.yahoo.com/c/1y/a/" + argText.text;
    pblock.innerHTML = "";
  },
  execute: function( argText ) {
    var windowManager = Components.classes["@mozilla.org/appshell/window-mediator;1"]
                      .getService(Components.interfaces.nsIWindowMediator);
    var browserWindow = windowManager.getMostRecentWindow("navigator:browser");
    var browser = browserWindow.getBrowser();
    var url = "http://finance.google.com/finance?q=" + argText.text;
    browser.loadOneTab(url, null, null, null, false, false);
  }
})

This command introduces a ‘tik’keyword, which loads 1-year stock symbol charts (from Yahoo) into the preview pane, and allows click-through to open a new tab for the Google Finance page of said symbol. Note that the preview-pane doesn’t always resize correctly for the chart to fit (though you can generally make it happen by typing a space after the stock symbol.) I guess there’s still some work to do there.

function weather {
  zipcode=$1
  if [ -n "$zipcode" ]; then
    lynx -dump "http://weather.yahooapis.com/forecastrss?p=$zipcode" | grep -i condition | awk -F' ' '{print $4 $5 $6}' | awk -F'< ' '{print $1}' | sed 's/,/ /'
  else
    echo 'USAGE: weather <zipcode>'
  fi
}

The script uses lynx to grab the Yahoo RSS feed, piping the output to grep, which extracts the line containing the word ‘condition’. awk then pulls out some specific fields (delimited by spaces, then later by ‘<’), and sed converts the commas to spaces for prettier output. Obviously, the whole thing is fairly fragile, and changes to the RSS format (which happened maybe a month back) break the code. Checking the weather in Austin with the command: `weather 78701`, currently outputs: “Fair 67F”.