I recently upgraded to OSX 10.9 Developer Preview announced at the WWDC 2013. I highly recommend trying it out if you’re enrolled in the Mac Developer program and want to benefit from lots of substantial speed, security and reliability gains.

The most notable changes are around scrolling performance and the support of multiple displays and fullscreen applications. The focus on productivity improvements over eye-candy is not coincidental: iOS is clearly the operating system for day-to-day consumption, and the Mac for professional production and creation.

I came across a few problems trying to make my existing development environment work, and I’ve documented the solutions here.

Making Vagrant work

OSX now comes with an updated ruby:

∴ ~ /usr/bin/ruby --version
ruby 2.0.0p195 (2013-05-14 revision 40734) [universal.x86_64-darwin13]

To make Vagrant work on 10.9 I had to rollback to Ruby 1.9 after finding out gem install vagrant was failing. The easiest and safest way to do this is with brew, since it will install ruby in an isolated location.

∴ ~ brew install ruby

After running this, we need to make sure that the 1.9 version takes precedence over the system one in your path. Edit your profile like so:

export PATH=/usr/local/Cellar/ruby/1.9.3-p286/bin:/usr/local/sbin:/usr/local/bin:$PATH

Notice that in my case the installed version is 1.9.3-p286, it might be slightly different by the time you install it. Make sure the path is correct when you edit your PATH.

Now you can install your favorite ruby gems again without problems:

∴ ~ gem install vagrant

For the particular case of making Vagrant work on 10.9, you’ll also have to re-install VirtualBox.

Making Divvy work

All applications that required enabling support for assistive devices in the Accesibility preferences pane will stop working when you upgrade. Since this setting could be used in malicious ways by installed applications to gain control over the entire system, it’s been reset and now has to be configured in an app-per-app basis:

Make sure to unlock the pane with your administrator password, and re-enable access to your favorite apps.

The Chrome Dev Channel has recently introduced a revamped home screen that features a search box alongside the top sites. In addition, I noticed that the suggestions offered as you type now became part of the body of the page.

I tried to right click and unsurprisingly, it seems Google has decided to “dogfood” more and more of its browser’s chrome.

I headed to the Chromium issue tracker to learn more about the change and its implications[1]. I came across some predictable yet very well-formulated concerns over a potential performance degradation. In the process I learned that Chrome provides a chrome://omnibox URI to query the suggestions manually:

It’s not certain whether this change will stay, but I favor the idea of the browser using its own rendering engine for most of the UI, something that Chrome has been doing for its Settings, extensions management and even the print dialog. And maybe this will further extend the hacking surface of its rich extension ecosystem.

[1] Aside from a few links that seemed to be exclusive to Google employees, I still find it amazing that I can in a matter of minutes learn so much about the internals of a project of this caliber.

Email you receive on a daily basis falls into two primary categories:

• A. Mail written by someone on a Mail User Agent (MUA), like iOS Mail or Gmail.
• B. Mail written by a computer program, normally transactional email.

Almost every web application you use on a regular basis will send you email when different transactions occur. If someone adds you as a friend on Facebook, you’ll likely receive an email about it sent by Facebook’s backend server.

And unlike category A, the information contained in a lot of email from category B also exists in a web application you can access with a web browser. Chances are good you could visit facebook.com and read the notification (and even act on it) before you check your inbox, yet that same message will still be waiting for you in your inbox in an unread state.

You’ve probably found yourself reading chat email digests of messages you’ve already read in the original chat client (ironically, this even happens with Gmail’s own Google Talk). You might have even read emails about “new” pull requests you actually merged on Github hours ago.

The solution is actually a quite simple one: enable applications to dismiss email they’ve sent in the past, once they know that the email is no longer relevant.

A rough implementation could be as follows:

1. Outgoing transactional email would contain a dismissal id in the form of a proprietary SMTP header: X-Read-ID: <hash>
2. Once the information is “read” from the website or application, a new email is emitted with a custom format read({user}, {token})@host.com.

For example, if I’m sending Guillermo (rauchg@gmail.com) a notification email I would include a header like this: X-Read-Id: 55765639d46104a0de.

If Guillermo then goes to the website and reads the notification, I would now send a new empty email to read(rauchg, 55765639d46104a0de)@gmail.com. The email provider can then decide what to do with this amazing information. Gmail could archive those emails for you. Non-compliant email servers will simply bounce the email, making this completely “backwards compatible”.

tl;DR: only 2/3 bugs have an impact, one has a trivial workaround (jQuery snippet included below), the other one is UX related. Socket.IO needs no updates.

In the past 48 hours a lot has been written about the introduction of iOS6. With such a major software release it’s not surprise that a few issues have been introduced. Of particular importance to us web developers, three different bugs have been attributed to Mobile Safari:

• A continuous “spinning loading indicator” reported on TechCrunch
• Broken long-polling due to a connection limit set to 1 explained by Real Software
• The introduction of aggressive caching of POST requests, reported on Stack Overflow

As it turns out, a lot of misinformation is being spread as well. In addition, all of these bugs are of very high importance to the development of the Socket.IO and Engine.IO realtime frameworks. Therefore I took the time to document the actual bugs and their workarounds in this post.

Read more

If MongoDB rs.status() displays the following error:

> rs.status()
{
	"startupStatus" : 4,
	"errmsg" : "all members and seeds must be reachable to initiate set",
	"ok" : 0
}

The first course of action is to look at the MongoDB logs. In my Amazon Linux installation, these are at /var/log/mongo/mongod.log.

$ tail -n 100 /var/log/mongo/mongod.log

You might find an entry like this:

(date) [rsStart] getaddrinfo("ip-10-0-1-94") failed: Name or service not known

Under certain configurations, your machine’s hostname might not actually be reachable. An easy solution is to make it so by adding the an entry to /etc/hosts:

127.0.0.1   ip-10-0-1-94

After restarting mongo, you’ll be able to run rs.config without problems with any IPs you want as members of the replica set.

On Monday I had the pleasure of speaking once again at NodeConf in Portland. On this glorious second edition, several talks were dedicated to the topic of realtime, covering angles such as its inception and future, scalability, backend messaging and more.

Mikeal requested that I talk about the state of Socket.IO, now one of the corner stones of the so-called realtime web and one of the most popular JavaScript projects on GitHub at the time of writing. Those familiar with the project know that stability and reliability are the commanding goals of all the ongoing work towards 1.0.

These goals are largely attained by the introduction of a new library, whose first release was announced at the conference: Engine.IO.

Read more