Revelation Labs

scrollHeight, scrollTop, and outerHeight: Making sense of JavaScript scrolling geometry with JQuery

2010-02-04T00:00:00-08:00

Intro

This article is written for those who find themselves working on two problems:

Getting information about the scrolling state of an html element.
Using JavaScript to do so.

Your main foe here is history, as years and years of cruft and backwards compatibility support have all been patiently building up to the tangle that is this moment. Your enemies have gathered, and they will take great strength to overcome.

My methods will require JQuery (1.4 is the current release, but this should apply to many versions). Take a moment to go get it and include it in your project.

Info

To conquer scrolling, learn the difference between these three different scroll state values (see illustration below):

element.scrollHeight:
a plain javascript attribute, note the lack of parenthesis. The entire scrollable height of the element (in pixels, floating point)
JQuery.outerHeight():
JQuery method of a scrollable element. The height of the visible portion of the scrollable element (in pixels, floating point)
JQuery.scrollTop():
JQuery method of a scrollable element. The height of the invisible portion of the element above the current scrolled area. Effectively, this is the offset of the scrollbar from top. (in pixels, floating point)
bq.

Examples …

Unicorn, I18n and it's Thread

2009-11-13T00:00:00-08:00

We’re in the process of switching over to Unicorn here at Revelation and yesterday we started to notice some strange behavior with I18n. The I18n locale we set in a previous request was persisting to the next. Digging into I18n we found out why: I18n holds the current locale on a thread-local variable, and unicorn does not start a new thread for each new request, so the current locale or any other thread-local variable will persist across requests. Here’s a quick example to show the different behavior of Mongrel vs. Unicorn with thread-local variables.

Here’s a really basic Sinatra app:

If we start this app up with Mongrel and go to /portland we get: "Portland: ". The value of our thread-local variable is nil, because mongrel creates a new thread for each request.

If we start this app up with Unicorn and go to /portland we get: “Portland: is awesome”. Unicorn has kept the same thread across both requests so the thread-local variable is still set to “is awesome”.

Since I18n stores locale in a thread-locale variable you have to be very cautious to reset locale for each request or the last requests locale will persist and your users will get some strange behavior.

Cheers,

James

Mongrel vs. Passenger vs. Unicorn

2009-10-06T00:00:00-07:00

A quick word of caution before reading: everyone should do their own performance testing. Depending on your system/your stack/your code your result my vary.

We tested mongrel, passenger and the new kid on the block: unicorn. Our goal in testing wasn’t to test a simple rack or rails app. Our app is complex. We wanted to see what each of these servers could do with a very complicated action in our app. One that has before_filters, nested partials, big sql lookups, and so on. We also wanted to test this in an environment that was as close to our production stack as possible. So all of our testing was against our staging server, under ssl with a full stack and a copy of our production database.

Here’s our setup:
Linux version 2.6.22-xen (Gentoo 4.1.2 p1.0.2)
1 2.5ghz dedicated xen virtual CPU
768MB memory
For each test we booted up 3 workers of each server.

We used siege to test each of the server candidates. The actual command looked something like this:

The results were surprising. Below is a graph of the average response times for each server. As you can see passenger and mongrel are almost identical. Both have a slope of around 1 second per 5 concurrent requests. Which means for a given second, each 5 concurrent requests you add will make the average response time of all requests go up by a full second. Unicorn on the other hand destroyed each an every request sent to it. It has a slope close to 1 second per 14 concurrent requests! Crazzzy fassssttttt.

We also measured the max response time (the longest response) for each test. The results are also on unicorn’s side. After around 9 concurrent requests, passenger shoots through the roof. Having response times around 16 seconds! Mongrel isn’t as bad, but still got response times around 8 seconds once you get into the double digits of concurrent requests. Unicorn is flat. 2.17 seconds is maximum time it ever took to complete the request.

We aren’t going to be jumping to unicorn in the near future. ~~Still a couple bugs to knock out~~. Our configuration still needs a little work. We don’t have a monit recipe to monitor the unicorn workers, and our nginx configuration needs some work. But we thought the results were interesting. If you’ve run some performance tests on your system we’d love to hear about them. Please email us at labs@revelationglobal.com.

Cheers,

James

YUI uploader testing with Blue-ridge

2009-08-17T00:00:00-07:00

The Revelation development team has been working hard to bring video uploading and encoding to Revelation. Whenever we do anything around here we always think ‘TEST TEST TEST’! We decided to use YUI’s uploader, which means that much of our uploading functionality was going to be in JavaScript. In the past we’ve toyed around with tools like Screw-Unit or just basic Selenium tests to make sure our JavaScript is tested. For video uploading, however, we really needed to find robust full-featured and CI compatible JavaScript testing framework. We landed on Blue-ridge. The best thing about Blue-ridge is you can do some pretty powerful JavaScript testing without a browser. Blue-ridge achieves this feat by running in Rhino. Rhino is a Java-based JavaScript interpreter written by the guys over at Mozilla. Rhino is capable of rendering a full DOM implementation that runs completely in JavaScript by loading a special version of Env.js, which results in a pure JavaScript browser. Pretty crazy!

To fully test our new video uploader we needed to test private functions that were being called by a listener. This added another level of complexity. To get around this we pulled all the functionality of the methods called by the listener into our own custom name spaced object. The only functionality that we left in the methods directly called by the listener was to call the new methods in our custom name spaced object. This allowed us to have the maximum level of testability of our custom functionality and left the methods that the listener called as a bridge between the private functions and our custom object. I think this is best explained by looking at some code:

In this example we’re using YUI’s uploader for video and a JQuery plugin we wrote to create a video uploader. That video upload will call ‘onUploadError(event)’ if the uploader has an error. That method in turn calls ‘display_error’ under the ‘Revelation.video’ name space. This allows us to easily test the functionality of displaying an error and leave the event calling to the YUI uploader. Below a simple test to make sure ‘display_video’ acts correctly.

This is a very simplified example but shows how to test something that otherwise is very hard to test. Because of Blue-ridge the test can run under our CI server so we always know this functionality is working fine.

Everything you never wanted to know about nginx

2009-07-31T00:00:00-07:00

This is the end of a very long week indeed. We’ve been working hard adding video to our application, and learned quite a few things about Javascript’s foibles and other equally impossible things to do with nginx.

First off, tracking upload_progress with more than one nginx server in a load balanced environment. The moral that we have from our story is: don’t try this at work. We had a problem where the initial upload would be uploading to one of our nginx servers, and then subsequent requests to other nginx servers for upload_progress would fail, because they weren’t being buffered there. You can do things with good load balancers and ‘sticky’ sessions, but in our experience, it’s just a bad idea altogether.

Next: trying to turn off buffered uploads. We were attempting to get nginx to act as a straight TCP proxy to a remote nginx server that would handle uploads and track their status with the upload progress module to get around the problem we just described. This doesn’t work. As of this moment, there doesn’t seem to be a way to configure nginx to not buffer an upload.

It just turns out that this is a bad idea altogether. We decided at last to have the client measure the state of their own uploads with the YUI flash uploader widget. If you don’t care for the flash requirement and don’t care about upload progress, I can also recommend that you try the Yahoo connection manager for asynchronous uploads. We’ve used it with great success here.

Welcome to Revelation Labs!

2009-07-06T00:00:00-07:00

First, let me introduce the development and design culture we’ve started here at Revelation. We practice eXtreme Programming or XP. We believe in short iterations and continually delivering business value in the form of working software. We believe in testing, or more specifically, in writing tests first. We believe in the tremendous value that interaction design brings to a product.

In short, we are very proud of our work, our process, and our people, and the community that has inspired us.

This is our effort to share what we have learned, and to contribute back to the larger community of developers and thinkers that make our work an expression of the joy of creation.