Oct 222011

I want to cover a basic but essential part of what you might expect in an introduction to JavaScript. This post is only Part I of fuller explanation of JavaScript function scoping, “lexical scoping,” and Javascript’s hoisting behavior.

Although it may seem tedious to review fundamental elements of JavaScript, these are the building blocks for a comprehensive understanding of the language’s functional style, which I will get to in Parts 2 and 3 of this introduction.

In Part 1 I will cover two basic concepts that are the first things you should learn about JavaScript: “the JavaScript interpreter,” what an identifier is, and the var keyword. Although seemingly unrelated, these two pieces are the foundation of the next parts so I’ve chosen to cover both here.

First, let’s discuss what we mean when we say “the JavaScript interpreter.” This is a standard programming concept, particularly in an interpreted language like Perl, Ruby, PHP, etc, but it is essential to know what the interpreter is to discuss some advanced concepts in JS.

First, consider an extremely simple set of lines of code:

a = 5;
b = 3;
alert(“a plus b is ” + (a+b));

ECMAScript defines a specific standard for the language, and we can expect its syntax to follow a logical relationship to its functioning. However, that’s only part of the story. In the code above we are setting the variable a to 5, the variable b to 3, and then putting up an alert dialog with the sum of the two variables.

The interpreter is the part of the browser’s execution of our code that reads the code we’ve written before it is executed. It parses what we’ve written, figuring out the delimitations between our lines of code and blocks defined with curly braces { and }. Note that it parses our code first, before it actually executes it, and if it can’t parse it correctly we see a Syntax Error in the browser’s console log.

What the interpreter does next is something akin to re-writing certain parts of our code. It doesn’t actually rewrite our code, it just interprets it in a certain way what makes it behave as if it has been re-written. During interpretation, it use what it is interpreting to reserve namespaces for variables and functions, even if it might not actually execute that line of code.

Finally, the code is executed.

Let’s start with a definition of a JavaScript identifier is. An identifier is a string of characters seen by the JS interpreter that will be used as a name something such as a variable or a function.

The term ‘identifier’ just means a string of characters, without spaces. A valid identifer can only contain the letters and numbers (uppercase or lowercase), underscore character _ or dollar-sign $ character. Identifiers must begin with a letter, underscore, or dollar sign. (Digits are not allowed as the first character so that the JavaScript interpreter can recognize number literals quickly.)

These are examples of valid identifiers in Javascript

 Posted by at 5:38 pm
Oct 192011

There is an IE 6 / IE 7 (only) bug that causes the content that should be scrolling to spill out over the rest of the page. (The scroll bar appears, but the part of the scrolling content that should be “hidden” is spilling out onto the rest of the page where it shouldn’t be visible. Other than the overflow of the scrolled area being visible, the scroll works correctly.)

For example:

<div id=”xyz”>
 … lots of content here …

In your scripts (probably inside a $(document).ready() call):


This is because overflow: hidden has a known issue with IE6/IE7 if the block (div) that is supposed to be overflow: hidden (as is the case with the scrolling div) but isn’t position: relative. The fix for this is to give position: relative to the div you are trying to make scroll

<div id=”xyz” style=”position: relative”>
 … lots of content here …

See these links related to the overflow: hidden issue in IE6/IE7:



Oct 182011

The jPlayer library for playing videos is very good and well documented here http://jplayer.org/latest/developer-guide/#jPlayer-option-errorAlerts, so I won’t repeat what it has to say. jPlayer is an excellent tool for creating a video player – what you need is one of each kind of format, flash and non-flash, for full multi-platform support. (Essentially, a flash file and a mp4 file.)

However, I would like to point out the invaluable setting for errorAlerts (link is below) which will alert you as to what is wrong if your video fails to play.


 Posted by at 12:41 pm
Oct 152011

When a website that is running locally tries to access a remote web service.


To disable this security restriction in Mac Chrome

open -b com.google.chrome --args --disable-web-security

See also:


 Posted by at 3:32 pm
Oct 032011

Ran into an annoying chicken/egg involving deploying to Heroku with a shared database. It seems that Heroku isn’t happy unless you have gem ‘pg’ in your Gemfile. If you are using the shared database and fail to have gem ‘pg’ in your Gemfile, you app actually deploys OK on Heroku but then generates an Application Error when you call a page. If you check the heroku logs you see something like this:

Continue reading »

Oct 012011

cd ~/Library/Application Support/TextMate/Bundles


In Textmate, Bundles > Bundle Editor > Reload bundles


Also install Node.js


Oct 012011

A bit today about setting up and debugging Capybara with truncated fixtures. Capybara comes with an array of choices for a driver, the thing that actually runs your tests. You can emulate a user using a real browser (Firefox or Sarari), or you can emulate a headless browser.

Today I’m going to be focusing on setting this up with Selenium to have Firefox run your tests.

First, there is a special consideration about using a transactional or truncated database strategy. Also I ran into a hiccup debugging properly, so there are some notes below about how to setup the configuration files to be able to drop into the debugger in a Capybara-run test.

A transactional fixture strategy is on in which each test is wrapped in a database transaction, held in memory but not really committed to the database, and rolled back at the end of each test. This means that the test database starts the same way (with the same content) each time a new tests runs.

A truncated strategy, on the other hand, just flushes out the database after each test load. A truncated strategy uses a gem call database_cleaner to clean up the database after each run. The examples below show how to set up an app for a truncate strategy.

In typical old-style Rails tests, you created fixture data in YML files inside of test/fixtures/. This won’t work in a truncated strategy, because database_cleaner will clean out the database on each test run.

Basic configuration
Assuming you have created a new app, be sure that these gems are installed

sudo gem install capybara libffi factory_girl_rails launchy redgreen cucumber-rails cucumber database_cleaner

Now create the cucumber setup:

rails generate cucumber:install -capybara

Basic template of a Gemfile

source ‘http://rubygems.org’

gem ‘rails’, ‘3.1.0’
gem ‘rake’
gem ‘rack’
gem ‘authlogic’
gem ‘haml’
gem ‘sass’
gem ‘mysql’

group :production do
 gem ‘hoptoad_notifier’

group :test do 
 gem ‘factory_girl_rails’
 gem ‘launchy’
 gem ‘redgreen’
 gem ‘cucumber-rails’
 gem ‘cucumber’
 gem ‘capybara’
 gem ‘database_cleaner’
 # for use with Ruby 1.8.7…
 gem ‘ruby-debug’
 # for use with Ruby 1.9…
 #gem ‘ruby-debug19’

Be sure to run bundle install after editing your Gemfile.

Now go to features/support/ and create a new file capybara_config.rb in this folder with the following contents.

Capybara.default_selector = :css
Capybara.default_driver = :selenium
DatabaseCleaner.strategy = :truncation
Cucumber::Rails::World.use_transactional_fixtures = true
require ‘rubygems’
require ‘ruby-debug’

There’s an explanation of this, along with three possible fixes, by jnicklas here. I got his suggestion #3 to work using the configuration above. (The last line is from his advice.) The key thing here is that when you switch Capybara to use Selenium (or webkit driver), your tests are no longer running in the same thread that your rails app is being tested against. This is critical because if you create a user

@user = User.create()

that database record will be wrapped in a transaction that will be not be recognized by the thread that is actually running your app. That means you might create a user and try to log-in with that user and won’t be able to because there will be no record in the DB. (There is actually a record, but Ruby sees the other thread as not sharing the transactions, so you can’t use, access, or test against it.)

I found that I need the requires for ‘rubygems’ and ‘ruby-debug’ in my Capybara config file (above) to get capybara to actually drop into the debugger (without it seemed to ignore the debugger command).

 Posted by at 3:15 pm  Tagged with: