Skip to main content

Posts

Showing posts from February, 2014

PhantomJS and JavascriptExecutor

My main project at TheStreet is a web scraper, and it relies on PhantomJS browser to run user interactions, make DOM adjustments and take screenshots. Taking screenshots is an area where PhantomJS excels over the other Selenium WebDriver implementations. The thing that works so well for PhantomJS is that the viewport is not constrained to a screen, so it takes screen captures that are as long as the page content is. I just set the viewport to 1366x1 and let the content extend the height of the screen. One thing that doesn't work well is rendering fonts. Running on AWS the rendering of fonts is extremely unstable. The same site can render as a serif or sans-serif font, and it's not clear why. The problem with this is that it makes the screenshots very different even if the site isn't changed. I'm using pixel-level analysis of the screenshot to detect changes, so this sets off lots of false positives. PhantomJS uses the JavascriptExecutor interface to allow arbitrar

Backbone.js / Marionette.js Complex Defaults

I just worked through an interesting bug in a front-end single page application. The system has the ability to create new items, and one of the attributes of the item is an array of ids. When I created a new item after working with an existing one, ids from the older item were showing up in the new one. Similar issues were happening in several places in the codebase for that interface. What I eventually realized is that the default attributes are passed into instantiated objects directly -- they are not deep copies. So my code was simply modifying the existing array rather than overwriting it, and as a result my old and new instances were both using the same attribute array of ids. The takeaway lesson is that complex defaults, such as arrays or objects, should be set in the instantiation method so they are distinct in distinct instances.