You’re financing Comcast’s wifi infrastructure.

TL;DR Comcast is selling wifi access through Skype, and you’re paying for it.

Last week the big news on the internet was that Comcast was turning a public wifi signal on 50,000 subscribers.

This has been happening in the Boston area for sometime and honestly its nice to be able to walk around the city and have wifi in many of the locations I visit. If the wifi network were only for other subscribers to use I wouldn’t mind at all, but it looks like there is more to than that. 

I work remotely, so I am always looking for access to wifi while i’m out. I check the xfinity wifi map and I also started to look as the Skype network as an alternative when I can’t find a xfinity signal.

When I was looking at the Skype wifi map I noticed a lot of overlap between the xfinity coverage and the Skype coverage, then I realized why. Comcast is reselling access to their wifi network to Skype users. Access to the Skype wifi network isn’t free, you are required to purchase Skype credit to use the access points. It doesn’t seem fair that I am paying to rent the router, paying for the electricity, and paying for internet service while they piggy back on my resources to build out a wifi network. A wifi network which they are now reselling without offering a discount.

Karma vs The Intern

I have worked hard to make testing part of my regular development workflow. I believe in order for something to become part of your way of getting things done it needs to be easy and fun! You need to set yourself up for success by investing a little bit of time into a system that works for you.

In the past testing any type of JavaScript has been a huge pile of hacks! Normally it would be a single HTML page with a test runner which you refreshed to run your tests. It was better than nothing, but it was far from automated.

When NodeJS showed up and became popular I started to build my modules in a way where there was very little knowledge of the web browser or DOM APIs so that I could run tests quickly from the command line. This was a little better than the single HTML page approach, and also had the side effect of forcing me to create a barrier between the view and the meat of my application logic. But I still needed that single HTML page to run tests against my views.

Then came the JS test runners! These runners basically automate interactions with the browser and collect test results for you. They allow you to run your tests across many different browsers at the same time. All of the runners have their pros and cons. I am setting up a repo to do a side by side comparison of two runners that I am familiar with. The repo is comparing Karma and The Intern. I am familiar with Karma I have been using it daily for well over a year and its pretty awesome! I am still in the evaluation phase with The Intern, but I like the support it has for a more functional style of testing.

You can follow along with the progress here!

VIMRC you’re doing it wrong!

Every few weeks I get the urge to revisit my vimrc file to do some basic house keeping. Normally I will review the plugins i’m using and clean up some of the settings i’m no longer using. The vimrc file seems to quickly become a mess of random settings, most times when I do some house keeping I don’t remember what some of the settings are. Is this setting related to a plugin?  I dunno! Why did I remap this key? Who knows! I decided it might be easier to break the config into logical sections so that every setting has a home. Originally I broke the file into sections using comments. This worked well, I needed to make sure I was diligent with placing settings in the correct section based on the header. I still found sometimes settings where sneaking into areas where they shouldn’t be. Finally this past weekend I thought to myself, why not break the config into separate files. Then I will be less likely to put settings into the wrong area of the vimrc. I decided to break the config up into the following files.

base.vim

This file contains the bare minimum settings that, I feel, should be used for any VIM installation!

plugins.vim

I use vundle to manager the installation of my vim plugins. This file contains all of the plugins I depend on. I also added a comment describing what each plugin does. There have been many times I have reviewed my vimrc only to find a plugin which I don’t remember why I have it installed.

functions.vim

From time to time I find it useful to add utility functions to vim to make working with text easier. For example I have a simple function which pretty prints JSON data. I will place every custom function into the functions file.

theme.vim

Most VIM users I know have taken some time to make their editor pretty. This includes selecting a theme they feel works best for them as well as customizing things like the numbering of lines and how VIM uses the system bell. I keep these settings in my theme file.

settings.vim

Seems like no matter how hard I try almost every dot file I have ever made has a misc section. This is an area where I have a random collection of setting which don’t seem to fit into any major category. The settings file is where I keep these settings.

leader.vim

The leader key is critical for any heavy VIM user. The leader key provides a safe namespace for any custom key combinations you want to add to VIM. The leader file is where I customize my leader key settings.

keymappings.vim

No matter what editor you use there will always be come default behavior which will drive you crazy! Normally I try not to override default behavior but if its annoying or interrupts my workflow its gone. The key mappings file is where I override default key mappings which just seem to get in the way.

languages.vim

One of the best parts about vim is the ability to override behavior based on the filetype. I have different settings depending on the file type being edited. The languages file is where I keep all of the customizations I do per file type.

I got some feedback from some people on the vim sub reddit. I  should be using ftplugin for language specific settings!

plugin_settings

Each plugin I have installed might have the ability to customize it’s bahavior. I have created a .vim file for each plugin and put them into their own sub directory. The plugin settings directory has all of my plugin specific customizations.

Pulling it all together.

Now that I have a home for each portion of my configuration mapped out into separate files. I need a way to pull everything together from the main vimrc file. Thats where this handy little bit of vimscript comes in.

let s:vim_home = '~/.vim/'

let config_list = [
  \ 'base.vim',
  \ 'plugins.vim',
  \ 'functions.vim',
  \ 'theme.vim',
  \ 'settings.vim',
  \ 'leader.vim',
  \ 'keymappings.vim',
  \ 'languages.vim',
  \ 'plugin_settings/*.vim'
\]

for files in config_list
  for f in split(glob(s:vim_home.files), '\n')
    exec 'source '.f
  endfor
endfor

This code basically just loops over all of the files in my configs list. Then I run glob all of the strings, split the results and source every file. In effect its including every file into my main vimrc.

What does all this organization buy me? Now I have the ability to experiment with my configurations and keep the changes to one particular file. For example, I will experiment with a new plugin from time to time. During the evaluation period I could include the settings and the bundle statement for the plugin in a “temp_plugin.vim” file and add it to the config_list. If the plugin proves to be useful then I can later integrate it into my standard configuration. I also have the ability to swap entire portions of my config based on the environment! For example I could swap my functions.vim file for a customized version used at work. I could also add custom config if I am pairing with someone to make them feel more at home in my environment.

I’m sure as time goes on this organization will change and evolve. If you are interested in keeping up with changes to any of my dot files. You can find them on github!

IFrames, A TARDIS, and the Multiverse

Exploring iframes through a whovian’s eyes.

Over the past couple of years I have been working on a third-party JavaScript (3pjs) framework. I have come to know and love the iFrame element! Before working in the 3pjs world, I never appreciated the power and isolation that iFrames provide. I use to think of them as just an easy way to include content from another web page.

You may be asking yourself, “what do you mean third-party JavaScript (3pjs)”? When I say 3pjs I am talking about authoring a JavaScript application which will be included on pages you have no control over. Services such as disqus and olark are popular examples of 3pjs applications. When authoring an application that will be included and expected to run in a wide range of web pages it presents unique challenges. If you have ever written a script which must run in a range of browsers you are already familiar with compatibility challenges. 3pjs takes this challenge to the next level!

In the following series of posts I am going to describe how a 3pjs developer can defend against some of the common problems he’ll encounter when writing 3pjs. I will provide real world examples of problems I have run into while developing the 3pjs framework used by swoop. So lets get started!

WARNING: the posts that follow will include many references to Doctor Who. If you are not familiar with the series you should still be able to get the gist of what is being explained, but this series posts will be much more entertaining for those of us who enjoy watching the series.

Lets imagine that we want to create a script which records the current time on a web page. Getting the local time isn’t a very interesting script. A simple example like this will help illustrate some of the problems a 3pjs developer might face. Since the script will record the time we will call it Timelord. A simple example of the timelord script may look something like this.

var timelord = {
  setTime: function(ts) {
    timelordTech.send(ts);
  }
};

The details of the example are not important. We assume that the timelordTech object has a send utility for recoding a timestamp. Now we want to record the current time on every web page across the internet that will embed our script tag. Lets follow our timelord script on a little adventure across the web.

The web is like a Multiverse.

To the eyes of the Timelord (a 3pjs script) the web is like a multiverse. Web sites are like their own little universes, from the script’s perspective all look relatively equal. But they aren’t! Each universe can have subtle differences in its laws of physics (APIs) which have been modified by the Master (developer of the site) who has created the universe. The Master may decide that modification of these laws improve the lives of the creatures (JS, HTML, and CSS) who inhabit the universe. But to a visitor from another universe, the Timelord, these rules might seem strange or even dangerous!

The timelord arrives in a new universe via a gateway (script tag) that links all of the universes in the multiverse together.

When first venturing out into the multiverse of the web the timelord will need to protect herself and provide some form of isolation. At first the answer may seem obvious the timelord shall employ the use of a TARDIS. The TARDIS provides a level of protection from the universe it is visiting. The initial version of the TARDIS will most likely be a simple IIFE JavaScript expression.

//TARDIS shell
//timelordTech is not visible outside of the shell.
(function(g) {
  var timelord = {};
  var timelordTech = {};
}(this));

Anything defined within the TARDIS shall stay within the TARDIS. We don’t want to leak timelord technology all over the multiverse!

As the timelord travels she encounters many universes and interacts with the creatures in each. Being a timelord the first thing she wants to do when she arrives is check the local time. In all of the multiverse there is a standard way the timelord can use to find local time. Its known as the Date creature. The Date creature can do many things related to time. But the timelord is interested in only one thing. She wants to get the current timestamp when she arrives.

The timelord arrives in a new universe and encounters the Date creature. And strikes up a conversion:

(function(g) {
  var d = new Date();
  console.log(d.getTime()));
}(this));

Response:

1384248447189

In every universe the timelord has visited so far the Date creature always provides a valid timestamp, which consists of the number of milliseconds since the beginning of the mulitverse.

One day when arriving in a new universe she asks the Date creature for the current time. In this universe instead of receiving a valid timestamp she receives the string

'friday'

The master of this universe is truly an evil one! The unexpected value of “friday” from the Date creature throws our timelord into utter confusion. She no longer knows how to deal with the laws in this universe. She must give up her adventure in this universe and come back prepared to deal with some of the strangenesses she sees.

Modifications to APIs

We have found that our timelord script is failing to operate in one of the host pages. We investigate the issue and find that the API for the Date object has been modified. The “getTime” function is returning a string value instead of the expected timestamp.

Further investigation reveals that someone has decided that the API for retrieving the timestamp from the Date object should be “getTimestamp”. I’m sure the author of this page has a good reason for renaming the function. We are not here to judge its not our website, they can do with it what they want. But we need to make our timelord script more defensive against this sort of problem.

Great news now we know how to deal with the problem. But we must now test the Date object. Getting a timestamp from has become a little more tricky.

(function(g) {
  var d = new Date();
  var ts = d.getTime();
  if(!timelordTechisValidTS(ts)) {
    d = d.getTimestamp();
  }
  timelord.setTime(d);
}(this))

We update our timelord script with the new defensive code and send it on its way across the internet.

Timelord vocabulary is improved.

The timelord travels from universe to universe with her new date creature knowledge. A long time passes without any problems.

Again the timelord arrives in a universe where the Date creature is a little different then the others she has encountered. This time when she asks the Date creature about the current time, it goes into a rage and starts to throw errors. She has somehow enraged this creature by speaking to it in terms that it doesn’t understand!

var ts = d.getTime();
if(!timelordTechisValidTS(ts)) {
  d = d.getTimestamp();
}
timelord.setTime(d);

the Date creature replies:

TypeError: Object [Object Date] has no method 'getTime'

Our timelord script has been killed by the errors thrown by the date creature. Even with the isolation from the TARDIS it isnt enough to defend against an aggressive attack from the Date creature.

Even more complication

We have found another case where the API for the Date object has been changed. This time someone removed the “getTime” function completely so when we try to invoke getTime it throws an exception. In this case there is now no way to get a timestamp from the modified Date object. We cannot get a valid timestamp from this website.

What do we do in this case? We can’t just include our own Date object in our timelord script. Its impossible to include the Date object, because it depends on native code in the browser to get the timestamp. What we need is a way to get a Date object which has not been modified.

The only way to get a Date object which has not been modified is to setup an iframe and execute our timelord script in the iframe. The iframe will provide a clean JavaScript context where we can depend on the API of the objects to be stable and unmodified.

The isolation we used for out initial implementation of the TARDIS is not enough. An IIFE does not provide our script with a clean JavaScript context. We will need to improve the TARDIS and have it construct a same domain iFrame and initialize our timelord script within the iFrame. Then our interaction with the Date object becomes straight forward no matter what site we are running on.

Coming soon…

In the next post I will walk through the setup of a same domain iframe. The various ways a script can be bootstrapped within the iframe. Finally I will describe the differences between the same domain iframe and the cross domain iframe.

%d bloggers like this: