Pagination in Meteor

Meteor‘s a nifty “reactive” Javascript framework, and I’ve been plunking away on it with the help of the fantastic Discover Meteor book.  One thing I don’t quite agree with the book, however, is their Pagination Chapter (paywall, sorry) doesn’t actually implement traditional pagination so much as a variation on infinite pagination. That is, rather than show posts 1-10, then 11-20, their example shows 1-10, then 1-20, and so on.

This is potentially less-than-ideal for a couple of reasons. First, it forces the client to keep a growing number of posts in memory. 10-20 posts probably isn’t a big deal, depending on your app, but if you’re displaying hundreds of photographs (or animated GIFs), this could get pretty annoying. Granted, you can minimize the impact by only loading elements that are visible on screen, but it’s a headache that you don’t have to deal with traditional pagination.

The other potential issue is that, because Meteor is a real-time framework, the server needs to constantly monitor changes to the database and pass along those changes to the client. As the number of documents inside a database query grow, the number of updates being passed back increases as well. I haven’t been using Meteor long enough to know how much of an impact this makes in practice, but updating off-screen data is, at least, a sub-optimal use of bandwidth.

So, how do we work around this?

Continue reading “Pagination in Meteor”

(AngularJS) Testing headers with whenGET / expectGET

Jotting this down here in case anyone else stumbles on the same issue(s) in AngularJS.

Suppose you’re mocking out $httpBackend in a unit test and want to test headers, like so:

// Assume $httpBackend and $http have been properly injected above
it('should not send a token if none is set', function() {
 $httpBackend.whenGET('/api-call', function(headers) {
   expect(headers.Authorization).toBeUndefined();
 }).respond(200, {hello: 'world'});
 $http.get('/api-call');
 $httpBackend.flush();
});

This won’t work. If a function is passed to whenGET, it expects a true/false return value to signal whether the headers were correct. Instead, try this:

// Assume $httpBackend and $http have been properly injected above
it('should not send a token if none is set', function() {
 $httpBackend.whenGET('/api-call', function(headers) {
   return !headers.Authorization;
 }).respond(200, {hello: 'world'});
 $http.get('/api-call');
 $httpBackend.flush();
});

Now, however, when the header test fails, you’ll get the following error:

Error: Unexpected request: GET /api-call

This is a bit misleading, since it implies the $http call somehow never hit $httpbackend. However, the issue isn’t that the GET request was unexpected; it’s that the the GET request with that particular header was incorrect. If you swap whenGET with expectGET, you’ll get a much more sensible failure message:

 Error: Expected GET /api-call with different headers

In both cases, returning the correct header should make this failure go away.

Word Wrapper

Many, if not most, programmers leave word wrap off by default when editing code. This is because line-breaks in code can have programmatic implications. Python, for instance, uses line-breaks to indicate the end of a statement. With word wrap enabled, coders may have a difficult time distinguishing between new lines created automatically by word wrap and new lines created intentionally by a carriage return.

That’s all well and fine when you’re working with actual code, but it doesn’t work so well with documentation meant to be written in plain English (or some other traditional language). On one hand, s single long horizontal line of text isn’t very readable — newspapers invented columns for a reason — and horizontal scrolling is a pain. On the other hand, manually inserting line-breaks into text isn’t much better. Adding or removing just one word at the beginning can require deleting and re-typing all of the newlines in a paragraph. And because documentation often lives in the same file as code  (i.e. as comments), most text editors apply the same word-wrapping scheme to both code and documentation.

Some text editors are smart about this and offer ways to automatically re-flow long blocks of text, but it doesn’t seem to be a universal feature in code editors. To help, I’ve put together a simple webpage that uses Javascript to convert long flowing word-wrapped paragraphs to a fixed width text. By default, it uses the industry standard width of 80 characters, but you can change that. You can also use the tool to automatically prepend each line with a characters (e.g. to insert a “#” character to conform to Python’s commenting requirements).

It also doubles as a way to convert fixed width multi-line text back to — e.g. the angle bracket quoted paragraphs in e-mails — back to a traditional word-wrapped single line of text.

You can use the tool here, or check out the source code on Github.

Copyright Assert Truthy

I was poking around in the newly open-sourced Etherpad code, and came across this tidbit.

/**
* Copyright 2009 Google Inc.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS-IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/

function assertTruthy(x) {
  if (!x) {
    throw new Error("assertTruthy failure: "+x);
  }
}

That’s trunk/etherpad/src/etherpad/testing/testutils.js by the way. So anyhow, as much as I appreciate that is licensed under the Apache License, is “assertTruthy” really creative enough to be worthy of a copyright?

Continue reading “Copyright Assert Truthy”

FlasCar: A Ghetto Flash Card Program

I really didn’t want to pay for flash card software to help with studying, so I spent a few hours cobbling together FlasCar — my ghetto flash card program. It’s a Python script that parses a data file and generates an HTML / Javascript (jQuery) page that you can use.

Click here to try out the demo.

If you’re interested, you can download the Python script and make your own Javascript-powered flash cards. The details are in the README file. If you’re running Windows, you’ll need to install Python first. I think OS X and most Linux distros already have it, but if they don’t, go to the previous link  and get it.