Making life easier after your organization requires two-step authentication

Friday, January 25, 2013

My normal workflow at home used to be that I would use one session of Chrome for normal internet browsing with my personal accounts, and I would simultaneously use an incognito session for work email and other work-related accounts. However, since Pivotal Labs is now requiring two-step authentication for our Google Accounts, this would mean that every time I open an incognito window to check my work email from home, I would have to wait for a text message on my phone and enter the code.

The first step in making this easier is to install the Google Authenticator app, available for iOS, Android, and Blackberry (don’t forget to follow the setup directions in that post too). Now, instead of waiting for a text message, and then having to delete that message from my inbox (for some reason the message frequently comes from a different phone number), you can just launch the app on your phone and transcribe a 6-digit code into the second authentication step.

The other step is to configure Chrome for multiple users. This lets you have multiple, isolated Chrome windows at the same time. So now I can still use one session for my personal accounts while simultaneously having an open session for my work accounts, and I can choose “remember this computer for 30 days” because the session won’t get blown away when I close the last window. Here’s the screen where you can configure a user’s name and icon:

Example of other Chrome user icons

If you have used incognito mode, then you’ve most likely noticed that the incognito session windows have a spy-looking icon in one of the top corners:

Once you have set up multiple users in Chrome, then your normal windows will have an icon of your choosing in the same corner, so you can quickly identify which session that a window belongs to. Clicking on that icon will display a menu where you can choose to open a window belonging to another user.

I hope this helps make living with two-step authentication easier for you. If you have any other tips, let’s hear them in the comments!

Make Jasmine run at (near) full-speed in a background tab

Mark Rushakoff

Friday, March 2, 2012

Jasmine environments have a default updateInterval value of 250 that determines how often, in milliseconds, execution of the next spec will be deferred so that the screen can be updated.

    var now = new Date().getTime();
    if (self.env.updateInterval && now - self.env.lastUpdate > self.env.updateInterval) {
      self.env.lastUpdate = now;
      self.env.setTimeout(function() {
        self.next_();
      }, 0);
    } else {
      if (jasmine.Queue.LOOP_DONT_RECURSE && completedSynchronously) {
        goAgain = true;
      } else {
        self.next_();
      }
    }

Both Chrome and Firefox now require a minimum value of one second for setTimeout in a background tab. This basically means that for every 250ms of work that we do, we end up sleeping for 1000ms.

This gist shows one way to tell Jasmine to not even bother trying to update the screen when running in the background.

var foregroundScreenRefreshRate = 1500;
var backgroundScreenRefreshRate = 9000;

jasmine.getEnv().updateInterval = foregroundScreenRefreshRate;

$(window).focus(function() {
    jasmine.getEnv().updateInterval = foregroundScreenRefreshRate;
});

$(window).blur(function() {
    jasmine.getEnv().updateInterval = backgroundScreenRefreshRate;
});

(Please refer to the gist for the most up-to-date code.)

This code makes Jasmine run at full-speed in a background tab in Chrome, but continue to be updated about once every 2.5 seconds when in a foreground tab. However, using this as-is in Firefox will result in a warning about an unresponsive script, if the tab is inactive. Luckily, you can continue to run Firefox in the foreground fine with this script (good for CI perhaps), or you can just override the dom.max_script_run_time variable to never get that warning, or you can set updateInterval to something less than the default 10 second max script run time.

Chrome and Firefox throttle setTimeout/setInterval in inactive tabs

Mark Rushakoff

Wednesday, February 29, 2012

Do your Jasmine tests (or anything else) seem to lock up when they aren’t the active tab in your browser?

Unfortunately, your new and modern browser is to blame. There are a few workarounds, but none of them are ideal in my opinion.

The cause of the problem

In early 2011, both Firefox and Chrome clamped the minimum wait time for setTimeout and setInterval to one second when running in a tab that is not the active tab for its window.

You might also be surprised to find out that HTML5 specifies a minimum of 4ms delay for setTimeout.

Workarounds

Workaround 1: Run that tab in its own window

This is the easiest solution, but it’s often less convenient to switch between browser windows when you want to just switch between tabs in the same window.

Workaround 2: Compensate for the fact that your callbacks will happen at most once per second

The accepted answer at this StackOverflow question demonstrates how you can figure out “where your animation is supposed to be” and just jump ahead. This workaround probably doesn’t apply if you have logic beyond visuals that depend on somewhat accurate timing.

Workaround 3: Use another, newer (and not necessarily standardized) API

window.postMessage

Mozilla suggests that you use window.postMessage to achieve sub-4ms delays.

window.setImmediate

Microsoft recommends using the setImmediate function as a replacement for setTimeout with a delay of 0.

But Mozilla has this to say about setImmediate:

This method is currently only proposed, is not expected to become standard, and is only implemented by recent builds of Internet Explorer.

On a side note, the Microsoft page has a lovely visualization of quicksort.

window.requestAnimationFrame

Another not-yet-standardized function, requestAnimationFrame seems best suited for animations, not for precise timing.

Workaround 4: Build your browser from modified source

I’m being somewhat facetious here, but Chrome and Firefox both have hardcoded constants for the interval limit. Without looking through the rest of the source code, I can’t conclusively say for either browser that there is no simple way to add support for overriding the inactive tab’s clamp value.

I saw one or two mentions about Firefox having an option to overwrite the minimum timeout limit, but since I’m not able to find those links again or any further information about those options, I’m led to believe that Firefox also does not let you override that one second minimum limit.

Standup 4/1/2010: “update_attribute is almost never the right thing to use”

Pivotal Labs

Thursday, April 1, 2010

Ask for Help

“mp4s do not play during download in chrome”

Talks at Pivotal are recorded and published in various formats. Our talks page has an embedded viewer so that people can watch the video without downloading. We also offer a downloadable version in mp4. Most browsers will play the video as it is downloading. Google Chrome does not. Are we doing something wrong?

Pivotal Talks

Interesting Things

Beware: has_many associated objects are saved before has_one associated objects.
update_attribute of foreign_key value on belongs_to association does not save…when object was created by factory girl?

This is pretty specific, but perhaps not enough to be useful. The team tried to do an update_attribute on an object generated by factory girl, changing the belongs_to column value. However, no database update would occur. They later resolved this by doing a reload on the object before the update_attribute.

“Update_attribute is almost never the right thing to do” –anon