Using Google Voice in Australia

Here is an easy way to use Google Voice for voicemail transcription in Australia, with a bit of help from Skype:

  1. Sign up for a new Skype account (it’s best you don’t use your primary one, since you won’t be able to receive calls on it anymore)
  2. Add an Australian Online Number to this account through the Skype website
  3. Add some Skype Out credit to the account, or sign up for a subscription that includes calls to the US
  4. Open the Skype application and turn on call forwarding for unanswered calls for this account. Set your Google Voice number as the number to forward to, and set it to forward after 0 seconds (this just tells Skype to forward right away)
  5. Open Google Voice in your browser, click Settings in the top right, then click the Calls tab. From here, turn on Do Not Disturb mode. This is a crucial step, as it makes Google instantly pick up your call for voicemail
  6. Set your Australian phone to forward unanswered calls to your Skype Online Number. The online number will then forward to Google Voice which will pick up the call for voicemail.

Skype occasionally messes up the called ID on forwarded calls, but it get’s it right 99% of the time. With this method you can now get free voicemail transcription to your email, or use the built-in Google Voice application on Android phones. If you have a Google Voice invite but don’t know how to activate it from outside the US, the easiest way is to get a US Skype Online Number and give that to Google in order to activate your account.

Javascript/CSS Minification Script

I’ve been using a little bash script I wrote that will automatically minify any Javascript and CSS files recursively in a directory with the YUI Compressor, and I thought I’d share it with the world. With the script, you can chose to minify just Javascript (with the -j option), just CSS (with the -c option), delete any existing minifed files (with the -d option), or any combination of the three. Files will be saved with a .min.js or .min.css extension (for example, test.js will become test.min.js). All you need to do is put the YUI Compressor JAR file somewhere within the current working directory, and the script will find it.

Usage is simple:

$ ./minify.sh -dcj Deleting existing minified files... Minifying JavaScript... Processing: ./test.js Minifying CSS... Processing: ./test.css Done.

You can download the latest version of the script from my GitHub repository.

Limit App Engine to Minified JS and CSS

Call me paranoid or call me efficient, but I don’t like non-minified CSS and Javascript accessible in a production environment. It’s one thing setting up your web application to use minified files when it’s rolled out , but I’d prefer that the originals aren’t available at all – and yes, part of that is me not wanting to make it too easy for people to snoop through my code (though I do release a lot as open source anyway).

In any event, this proved a little tricky when using Google App Engine for LocationFu. Google’s deploy process has the option of excluding certain application files from being sent up, but it can’t exclude any files that sit within a directory marked as a static path. The solution is simple, but took me a while to figure out. Previously, I had my static path set up like so in my app.yaml file (note that this is for Python App Engine):

- url: /static
static_dir: static

That will map any file starting with /static into the static directory in the app tree. Instead, you can map individual files, and limit the extensions you want to serve:

- url: /static/(.*?)
static_files: static/\1
upload: static/(.*\.(gif|png|jpg|min\.css|min\.js))

That tells App Engine to grab the file name requested and map it into the static directory, while the upload parameter includes a regex to match only selected file extensions (.min.js, but not just .js, for example). This won’t stop your app from serving any file while running on the local development server, but when pushed to production, your JS and CSS files will only be accessible in minified form.

MooTools Idle Tracker Class

In web applications, there are times when you may want to track activity of a user within your page – perhaps your project includes a realtime component that you want to pause when the user isn’t actually working with the page, for example. This is pretty easy to take care of, but there are a few little quirks, so to simplify it all I’ve released a MooTools class to take care of it for you.

The class is super simple to use, all that is required is for it to be instantiated and it’ll get on with it. You can specify how many seconds of no activity on your page before the user is classed as idle, as well as a couple of more technical options, then just attach a function to the onIdle and onIdleReturn events of the class. For example:

  1. var tracker = new IdleTracker({
  2.     idleTime: 2,
  3.     onIdle: function() {
  4.         // User is idle
  5.     },
  6.     onIdleReturn: function() {
  7.         // User has returned
  8.     }
  9. });

You can get full details and download the class from my GitHub account.

Chrome OS Booting on my Original eeePC

Booting and running the Google Chrome OS (which I compiled from the open source Chromium OS source code) on my ancient original Asus eeePC. The 404s are because it takes a while to connect to my wireless internet. Note the awesome graphics bugs, which thankfully don’t happen too often.

Facebook’s New Photo Uploader – a Plugin Fail

I have the utmost respect for the engineers at Facebook. They are a very talented bunch, and the few of them I’ve had the pleasure to meet in person have even been nice folks to boot. Generally, they come up with very innovative and progressive engineering solutions to the huge problems they face, but their new photo uploader is one decision I completely disagree with.

The new Facebook in-browser photo uploader  is detailed well in a post from their engineering blog (along with a slightly more detailed look at security), but in a nutshell, it involves installing a browser plugin to handle file uploads in a separate thread. This plugin also creates Javascript APIs to gain full filesystem access to your computer, and sets up a small web server to allow Facebook to ping back to your local machine to check the status of your uploads. The primary reason to use this plugin-based approach is to allow a user to begin uploading photos and have them continue in the background while continuing to browse around the site.

This is a noble thought, but I really think it’s just engineering for engineering sake. The multitude of issues surrounding creating and maintaining a plugin of this nature far outweigh the advantage of allowing background uploads. And if background uploads are really that important to them, they could have come up with a smart solution to make use of their current AJAX page loading process. This process, currently in place, allows certain browsers like Firefox to surf around Facebook without re-loading the whole page, so technically a simple Flash uploader could continue as part of the original parent page. It’s called progressive enhancement folks – the browsers that don’t support Facebook’s AJAX page loads can just use a normal uploading process.

And apart from all of that, what is stopping users from opening a new tab or window to continue browsing? Seems to work well for every other site out there.

Yes Facebook, your current photo uploader is awful, but let’s not create a huge security hole by exposing filesystem access to Javascript and running a little web server on everyone’s machine. I really don’t want to have to trust you to maintain security on your plugin (on three platforms, even), just so I can upload a photo.

Use Firefox Betas on the Mac without Overriding Other Versions

On Windows, the Firefox installer (quite considerately) won’t override existing non-beta versions of the browser with a beta version (like the recently released Firefox 3.6 betas). Though it doesn’t explicitly say so, Mac OS X users can have a similar behavior, which by the surprised faces I see when  I tell people this, many people don’t know about.

It’s simple:

  1. Grab a Firefox beta download, then mount the disk image
  2. Instead of dragging the Firefox app to your Applications folder, drag it to your desktop temporarily
  3. Highlight the app on your desktop, hit the return key, and give it a new name (like “Firefox 3.6 Beta”)
  4. Drag the newly renamed app to your Applications folder

You can then run these two Firefox versions with little interaction between the two. I say ‘little’ because they will share the same profile (where your bookmarks, extensions and the like are kept), and so cannot be run at the same time. This has the plus side of meaning you won’t have to re-import bookmarks and such, but you will have to sit through a harmless extension compatibility check whenever you start a different version of Firefox than was last run.

Should You Show a Useless Page?

Zizhuang Yang, an engineering intern at Facebook this last summer, recently put up a very interesting and detailed post on the company’s engineering blog describing extensive user testing of various loading styles and times for Facebook he conducted as part of his internship. While the whole post is worth a read, one point really piqued my interest:

Another debate within Facebook pitted two loading schemes against each other. The debate was over whether or not we render the page as soon as possible … [running] the risk of showing users links and content that they won’t get a response from until the interaction scripts load.

His testing concluded that keeping the page blank until the Javascript has loaded resulted in lower usage statistics, and thus it was better to render the page even though nothing would actually work. This is a very interesting problem faced by many developers making Javascript-rich user interfaces, and while Yang’s conclusion might be right in this circumstance, it certainly isn’t valid everywhere, maybe even across Facebook itself.

While I can completely understand that it would be best to render out the Facebook logged-in homepage as quickly as possible, since presumably most people hitting it are there to read their status feed, I think it would not be so great for something like the photo album page. On the photo album page, people are expecting things to happen quickly – selecting a photo from the thumbnails, paging through photos – and all of this happens through Javascript on Facebook.

There is definitely no boiler-plate solution for load order, developers need to assess the situation on a case-by-case basis, but at the very least it provides a great argument for progressive enhancement (starting with a page that works, adding Javascript to make it nicer), since everything on a page would work regardless of whether Javascript has initialized or not.

Sync Google Calendar/Contacts to Everywhere with Exchange

I see it all the time – some new blog post detailing how to sync your Google calendar and contacts to somewhere, usually to the iPhone, using some new 3rd party service or crazy trick. Many people suggest NuevaSync to sync directly to the iPhone, or using CalDAV to get your calendars to iCal so they can be synced through iTunes.

Fact is, they are missing a key feature of Google apps that lets you sync to a lot of places, including the iPhone, directly and with push updates – Google supports Microsoft Exchange for both contacts and calendars.

With the Exchange support, you can get push updates to any device or application that supports Exchange, including Outlook on the desktop and the iPhone with v3.0 software and above. It doesn’t get around syncing to iCal (unless you’re already on Snow Leopard, which supports Exchange out of the box), but it’s damn good for mobile devices.

Here are the instructions for setting it up on the iPhone, and you can use the server settings from there to set up any other device/app that supports Exchange.

MooTools Pager Class

Recently, I had the need to do custom paging on an element with Javascript, and after hacking it together in a hurry, I realized that this might come in handy in other situations. So I cleaned it up a little and rewrote it as a MooTools class, and thus I present to you the MooTools Pager class.

Basic usage is simple, and the requirements are limited to MooTools (tested with version 1.2.3) with the Selectors and Fx plugins. The plugin takes a wide element wrapped within an element with a smaller fixed width and creates a clickable list of pages and previous/next links – think carousel, but more content focused. If you set the overflow-x on your element to scroll, the class will override it when it’s instantiated and users will still be able to use your site with Javascript disabled.

The class sets up basic HTML, with fancy styling left to the CSS. Actuators (the list of pages) get the class pager-actuator, previous and next links get the class paging-prev and paging-next respectively, and each gets the class active when they are active (or available, in the case of previous and next).

Basic Usage:

  1. pager = new Pager(wrapper_el, paging_el, options);

Options, defaults are in brackets:

  • innerElement: Selector for the element to be shifted for scrolling ['.scroller']
  • actuatorFormat: The format for page links, can be ‘number’ (1, 2, 3…), ‘alpha’ (A, B, C….), or ‘none’ ['number']
  • showPrevNext: Whether to show the previous and next elements [true]
  • prevSymbol: Symbol to use for the previous element ['<']
  • nextSymbol: Symbol to use for the next element ['>']
  • pageLimit: Maximum number of pages, 0 is unlimited [0]
  • actuatorType: DOM Element type to use for actuators ['span']
  • transition: Transition to use when scrolling [Fx.Transitions.Cubic.easeOut]
  • duration: Duration for scrolling animation in milliseconds [500]

See an example of the class in use, or head to GitHub for more details, example usage, and to download.