In Part 1, I reviewed the gory details of the foundation required to run synthetic browser testing at scale. Now that we have a framework for building out our tests, we can move forward with wrapping our test runner in a web application so that the metrics we care about can be gathered and viewed through a decent UI. For this example, I’m going to use the Alexa top 12 news sites and execute a test over each one with the latest Chrome web browser.
Docker Swarm and Selenium Both Docker and Selenium are pretty much household names these days in the world of software engineering. I’ve been fascinated with Docker since its inception and have been using it for side projects and in my day job for a few years now. I recently came across the need to test a Chrome extension and load a web page while that extension is installed. This test would load the page, wait for it to load, check some JS variables and APIs and then spit out a screenshot and any needed metrics.
As a creator and overseer of an Open Source project, we must make tough decisions on when to pull the plug and move on. In 2012, I started a web based, real-time feedback project called Onslyde. To me the project was a huge success with many measurable results: Massive amount of research with WebSockets and mobile devices. Based on the code and research I was able to craft many talks for speaking engagements at conferences around the globe.
Today, many companies are synthetically measuring web performance with various scripts and services. Now that everyone is able to measure those performance numbers and visualize the problem areas, it’s time to raise the bar in terms of scalability, portability and the use of newer DOM APIs. The following charts show a snapshot of data collected over the period of one year (2012-2013) from the CNN.com home page using Loadreport.js.
This year, at Devnexus 2014, I wanted to take Onslyde a bit further by offering a way for sponsors to ask questions throughout the day between sessions. Since this was a trial/experiment I went old school and didn’t create a web interface for reserving sponsored slots. I simply created a spreadsheet with speaker name, session title, and time. Sponsors could then choose a time and I would reserve it on a first-come-first-serve basis.
For those interested: Usergrid, a Backend as a Service, was acquired by Apigee in early 2012 and has served as the core tool of all Apigee trainings and developer outreach efforts. Developers use it to create a backend for their mobile apps amongst many other things like managing users, roles and permissions. The Mobile Analytics product is something I was partial to since I created the original UI - before it was acquired by Apigee.
So, I was on Apple’s home page the other day and noticed some jank in their main carousel animation. It wasn’t anything huge, but the animation seemed to stagger a bit as the transitions were beginning and ending. There are five transitions that occur to display different Apple products. You can see this in the Frame analysis below. Each green line shooting to 0 FPS is a paint within chrome.
Both approaches require the use of $scope.$apply, which is completely normal. It forces the page/bindings to update when a change is made outside of the AngularJS lifecycle (like inside a setInterval or setTimeout). If you want to read more about $scope.$apply check out this article. For this particular case, I need a countdown timer on the page. Basically it sits in the upper right hand corner of the page and lets the user know when it’s about to refresh the data.
The manual workflow goes something like this: Now, with a little scripting we can have: Most preprocessor tools do have some kind of built in function for this workflow, but when you need to take it to a finer grained level and leverage services on the CI server, then this is what must be done. With our new workflow, we let Travis CI do the work for us in a bash script.