­

Adieu for-loops

Using many callbacks without embracing a functional style of coding can lead to mistakes that are very difficult to spot.
Consider this example: we have an array of user object and for each of them we need to fetch the first and last name using Facebook Graph API.

Using a procedural style:

for (idx = 0; idx < users.length; idx++) {
  $.api.FB('/'+users[idx].FacebookId)
    .done(function(fb) {
      users[idx].first_name = fb.first_name;
      users[idx].last_name = fb.last_name;
    });
}

This is just a pseudo code, suppose the method $.api.FB() fetches information from Graph API.
At the end of the cycle, each record has the fields first_name and last_name filled in with values from Facebook.
That in theory.

The problem with this piece of code is that it launches several asynchronous operations and you cannot tell which one is going to end first, likely the entire loop will end even before the first asynchronous operation is complete.
In a cloud environment, where every request could hit a different physical server, is not assured that the first call will end before the next one.

To avoid this error, just turn the code in a functional style:

  $(user).each(function(idx) {
    $.api.FB('/'+users[idx].FacebookId)
      .done(function(fb) {
        users[idx].first_name = fb.first_name;
        users[idx].last_name = fb.last_name;
      });
    }
  });

Here it works because the idx var it’s local to the anonymous function inside the each and, thanks to the closures, it will live until the functions defined inside the scope (the callback) are complete.
Every time we create an anonymous function we have a brand new context in which we can mess around without worrying about what is happening before and after: less side effects and less errors, adieu for loops.

October 1st, 2012|0 Comments

Get rid of WP-Admin redirects

Have you ever tried to work on your local code base of WordPress using a shared database (for example the database on staging/development server) with the rest of the team?
Normally it’s not possible since WordPress stores the URL of the blog in the database and immediately redirects if the current host name doesn’t match the stored value.

Using a centralized version of the database might be useful, in particular if more developers are working on the same blog and they don’t want to replicate locally all the settings of the database in staging/dev.

Here is a plugin for that:

<?php
/*
Plugin Name: Disable Canonical/WP-Admin URL Redirection
Description: Disables the "Canonical URL Redirect" and "WP-Admin Redirectr" features of WordPress .
Version: 1.0
Author: Guido Bellomo
Author URI: http://javascript-jedi.com/
*/

function fake_siteurl() {
  return 'http://'.$_SERVER['HTTP_HOST'];
  }
add_filter('pre_option_siteurl', 'fake_siteurl');
add_filter('pre_option_home', 'fake_siteurl');
?>

Just copy and paste this in a file inside the plugin directory (for example /wp-content/plugins/disable-redirect.php).

P.S. There are similar plug that works on the redirect_canonical filter, which works for the home page, but it doesn’t for the administration panel. This plugin cheats WordPress faking the option “siteurl” and “home”.

Works nice for blogs hosted in the root directory of the domain, for blogs hosted in subdirectory additional PHP might be required in the fake_siteurl() function.
Pay attention on disable the plugin in a production environment since it could compromise the blog security.

July 26th, 2012|0 Comments

CORS, get over it!

We’ve been growing up with the dogma: “AJAX cannot make cross site calls”.
Then CORS happened: with some configuration on HTTP server headers it’s possibile to make cross site AJAX calls, it’s widely adopted by modern browsers but it was not love at first sight: I’m not particulary happy with people calling my APIs from a different domain and when I have to, JSONP is just fine.

Eventually came the day when I cannot pretend CORS doesn’t exist.
I’m using Heroku for my projects and I usually keep all my static resources on Amazon S3 or Google Cloud Storage. During the last deploy I noticed that Firefox stopped loading a font with CSS @font-face rule on productions servers. It took me hours to realize that was a security restriction: Firefox will not load any font file from a different domain unless CORS is enabled.

Unfortunately Amazon S3 doesn’t support CORS (and it won’t support any sooner, there’s a two years old thread about this topic in the support forum, still unresolved), Google Cloud Storage does and it’s quite easy:

Install the tool gsutils and create this file cors.xml:

<?xml version="1.0" encoding="UTF-8"?>
<CorsConfig>
  <Cors>
    <Origins>
      <Origin>http://mydomain</Origin>
    </Origins>
    <Methods>
      <Method>GET</Method>
      <Method>HEAD</Method>
    </Methods>
    <ResponseHeaders>
      <ResponseHeader>x-goog-meta-foo1</ResponseHeader>
    </ResponseHeaders>
    <MaxAgeSec>1800</MaxAgeSec>
  </Cors>
</CorsConfig>

And then cast the command

gsutil setcors cors.xml gs://my_bucket

It will enable CORS for the whole bucket (be sure to match exactly the domain in the Origin tag, with protocol and host port).

Update: Amazon S3 started supporting CORS!

July 25th, 2012|0 Comments