But to use the autocompletion, you have to enable it. To do that, add the following snippet to your ~/.bashrc file (if you are using a Mac, see the aforementioned article):

source /etc/bash_completion.d/git

You can then either reload the .bashrc file with source ~/.bashrc or open a new shell to see the autocompletion in action.

var myArray = [1, 2, 3, 4];

for (var i = 0; i < myArray.length; i++) {
    console.log(myArray[i]);
}

However, with ECMAScript 5 the Array object itself got some methods for iteration purposes. With those methods you often can write cleaner code than by using a for-loop. Let’s have a (short) look at those methods. For details, please follow the provided links.

forEach

The forEach() method calls the provided function for each array element. Using forEach(), we can rewrite the example from above to:

var myArray = [1, 2, 3, 4];

myArray.forEach(function (element) {
    console.log(element);
});

filter

The filter() method applies the provided filter function to each array element and returns a new array with all elements for which the filter function returned a true value.

For example, to get only the even numbers of an array we could write the following code:

var myArray = [1, 2, 3, 4];

var evenNumbers = myArray.filter(function (x) {
    return x % 2 == 0;
});
// evenNumbers is [2, 4]

every & some

The every() and some() methods are similar: whereas the every() method only returns true if the provided testing function returns a true value for each array element, the some() method returns true if there is at least one array element for which the testing function returns a true value. You can see the difference in this example:

var oddNumbers = [1, 3, 5, 7];
var mixedNumbers = [1, 2, 3, 4];
var evenNumbers = [2, 4, 6, 8];

oddNumbers.every(isEven); // returns false
oddNumbers.some(isEven); // returns false

mixedNumbers.every(isEven); // returns false
mixedNumbers.some(isEven); // returns true

evenNumbers.every(isEven); // returns true
evenNumbers.some(isEven); // returns true

function isEven(x) {
    return x % 2 == 0;
}

map

The map() method applies the provided function to each array element and returns an array with the results.

For example, to square all values of an array we can do the following:

var myArray = [1, 2, 3, 4];

var squared = myArray.map(function (x) {
    return x * x;
});
// squared is [1, 4, 9, 16]

reduce & reduceRight

The reduce() and reduceRight() methods reduce an array step-by-step to a single value by using the provided function and an optional initial value. It works in the following way: the first two array elements (or the initial value and the first array element) are passed as parameters to the provided function. The result of this function call plus the next array element are then used as new parameters for the function. And so on, until there are no more array elements left.

The difference between reduce() and reduceRight() is that reduce() iterates over the array from left-to-right whereas reduceRight() iterates in the opposite direction, from right-to-left.

Here is a simple example to calculate the sum of the values of an array:

var myArray = [1, 2, 3, 4];
var initialValue = 10;

myArray.reduce(add); // performs 1 + 2 + 3 + 4 and returns 10
myArray.reduceRight(add); // performs 4 + 3 + 2 + 1 and returns 10

myArray.reduce(add, initialValue); // performs 10 + 1 + 2 + 3 + 4 and returns 20
myArray.reduceRight(add, initialValue); // performs 10 + 4 + 3 + 2 + 1 and returns 20

function add(x, y) {
    return x + y;
}

That’s it. I hope I could give you an overview over the available iteration possibilities in JavaScript. Happy coding!

Update 2011-04-02: I found a site by Microsoft where you can test those methods in your browser: ECMAScript 5 Arrays

In short, they describe two different usage scenarios of OAuth involving two respectively three parties.

3-legged OAuth describes the scenario for which OAuth was originally developed: a resource owner wants to give a client access to a server without sharing his credentials (i.e. username/password). A typical example is a user (resource owner) who wants to give a third-party application (client) access to his Twitter account (server).

On a conceptual level it works in the following way:

• Client has signed up to the server and got his client credentials (also known as “consumer key and secret”) ahead of time
• User wants to give the client access to his protected resources on the server
• Client retrieves the temporary credentials (also known as “request token”) from the server
• Client redirects the resource owner to the server
• Resource owner grants the client access to his protected resources on the server
• Server redirects the user back to the client
• Client uses the temporary credentials to retrieve the token credentials (also known as “access token”) from the server
• Client uses the token credentials to access the protected resources on the server

2-legged OAuth, on the other hand, describes a typical client-server scenario, without any user involvement. An example for such a scenario could be a local Twitter client application accessing your Twitter account.

On a conceptual level 2-legged OAuth simply consists of the first and last steps of 3-legged OAuth:

• Client has signed up to the server and got his client credentials (also known as “consumer key and secret”)
• Client uses his client credentials (and empty token credentials) to access the protected resources on the server

Above I used Twitter as an example, though strictly speaking, they don’t use 2-legged OAuth, but a variant of it. They not only provide the client credentials but also the token credentials (see also Using one access token with OAuth).

As you have seen, 2-legged OAuth is nothing new, it is simply using OAuth in a different scenario than it was designed for. And hence you can use (almost?) all existing OAuth libraries for 2-legged OAuth, too.

This release fixes a bug in the isOpenIDResponse() method. So far this method only recognized OpenID responses from a GET request. But as I had to learn, there are OpenID providers (e.g. Hyves) responding with a POST request… So, if you use the isOpenIDResponse() method, please upgrade to the new version.

However, this bug not only affected the component itself but also the examples and the example application. They contained code that looked like:

if ($this->RequestHandler->isPost()) {
    // make OpenID request
} elseif ($this->Openid->isOpenIDResponse()) {
    // handle OpenID response
}

This snippet will fail if the response from an OpenID provider is a POST request. Instead it should look like:

if ($this->RequestHandler->isPost() && !$this->Openid->isOpenIDResponse()) {
    // make OpenID request
} elseif ($this->Openid->isOpenIDResponse()) {
    // handle OpenID response
}

Please fix this in your code if you followed the examples.

Thanks go to Sam Mousa for reporting this issue.

As I wanted to use the same functionality and didn’t find an existing solution I wrote a simple jQuery plugin for this purpose: jquery-jknavigable. Its usage is pretty simple, to make the posts of a blog navigable with the “j” and “k” keys you would use the following code:

$('.post').jknavigable();

By default the active element is marked with the class “active” so you can style it differently. If necessary, you can specify your own class name:

$('.post').jknavigable({'activeClass': 'someClass'});

That’s it. Feedback is, as always, welcome.

PS: a good starting point for writing your own plugin is jQuery’s Plugin Authoring page.

Before making the switch, I recommend to run your Cucumber tests to ensure all tests pass:

$ cucumber features

As usual when adding new dependencies, you have to modify the Gemfile of your app. Replace the Webrat entry with:

gem "capybara", "0.3.9"

and run:

$ bundle update

With Capybara installed, you have to setup Cucumber to use Capybara by running one of the following commands:

// Rails 2.3.9
$ script/generate cucumber --rspec --capybara

// Rails 3.0.0
$ rails generate cucumber:install --rspec --capybara

Now, you are ready to run the tests again. If you are lucky, all tests pass, which means there is nothing more to do. However, I think it is more likely you will get a bunch of errors and maybe even some failing tests.

The errors I got were “undefined method” errors. They are relatively easy to fix by replacing the no longer existing Webrat methods with their Capybara counterparts. In the following code block I list some examples:

# Webrat
field_with_id('openid_identifier').value.should =~ /invalid OpenID/
# Capybara
find_field('openid_identifier').value.should =~ /invalid OpenID/

# Webrat
response.should contain('Previous')
# Capybara
page.should have_content('Previous')

# Webrat
assert_have_selector('.author', :count => 1)
# Capybara
page.should have_css('.author', :count => 1)

# Webrat
assert_have_xpath("//span[@id='#{id}']", :content => expected_count)
# Capybara
page.should have_xpath("//span[@id='#{id}']", :text => expected_count)

The trickiest part to fix was the failing test. To test some “remember me” functionality I manually set a cookie, and this no longer worked with Capybara:

cookies[:remember_me_id] = remember_me_id

After some searching I found a Gist from Nicholas Rutherford in which he dealt with cookies. Thanks to his code I could set my cookie with the following snippet:

cookies = Capybara.current_session.driver.current_session.instance_variable_get(:@rack_mock_session).cookie_jar
cookies[:remember_me_id] = remember_me_id

And with that, my switch to Capybara was complete. Any questions?

I also got asked whether there is an example application that shows the usage of the OpenID component. As I already use a very simple application to test the component manually, I pushed this application to GitHub (you can see the application in action on http://openid-example.42dh.com/). I hope this will make it easier for some of you to get started with the OpenID component.

class MyConstants {
    const AA = 'value';
    const BB = 'another value';
}

echo MyConstants::AA; // output: value

Now, while experimenting with JavaScript (or more precisely with Node.js) I got some constants in my code I wanted to organize with such a constants class. My first, albeit naive, approach looked like:

var sys = require('sys');

function MyConstants() {
    const AA = 'value';
    const BB = 'another value';
}

sys.puts(MyConstants.AA); // output: undefined

However, as you can see, this doesn’t work. One reason is that const “[c]reates a constant that can be global or local to the function in which it is declared.”. So it isn’t possible to create a constants class like I imagined…

This means we have to emulate a constants class by using static properties and relying on the naming convention that names of constants are uppercased (i.e. the “constants” are technically not constants and their value can be changed):

var sys = require('sys');

function MyConstants() {
}

MyConstants.AA = 'value';
MyConstants.BB = 'another value';

sys.puts(MyConstants.AA); // output: value

If there is a better approach, please let me know.

To update, simply replace the OpenID component and the content of the “vendors/Auth” folder (and its subfolders) with the files from the zip archive.

You can download the new version from Github.

h1
  height: 118px
  margin-top: 1em

.tagline
  font-size: 26px
  text-align: right

However, with the upcoming Sass 3 (it is planned to be released on May 10, 2010) a new format gets introduced: SCSS (Sassy CSS). It is a superset of CSS, i.e. each CSS file is automatically a SCSS file (you simply have to change the file extension from “css” to “scss”). So the example from above in SCSS is just plain CSS:

h1 {
  height: 118px;
  margin-top: 1em;
}

.tagline {
  font-size: 26px;
  text-align: right;
}

Not that exciting, isn’t it?

Where SCSS shines is when it comes to the integration of the Sass features (nesting, variables, and mixins) into this format. The devs did a very good job to make it feel like those features are native CSS.

Let’s have a look at some examples.

Nesting:

#header {
  background: gray;
  a {
    background: white;
    color: black;
  }
}

Variables:

$background_color: gray;

#header {
  background: $background_color;
}

Mixins:

@mixin red_border($border_width) {
  border: $border_width solid red;
}

#box_a {
  @include red_border(5px);
}

#box_b {
  @include red_border(10px);
}

Personally I really like the new SCSS format, and I can only recommend to try it out for yourself.