FaceQuiz

I went into the API Hack Day thinking that I’d probably end up taking a run at the FaceQuiz application (a brief domain search proves that the name would have to change to become a real product) Instead I ended up joining a large team, and then spending the day learning the hard way that using APIs from client-side Javascript is impossible without explicit cooperation from some server.

FaceQuiz is a personal itch. I barely remember people the second or third time I see them. Often times this occurs at meetup.com events. It occurred to me that I could intersect attendees at the next event with attendees at previous events to figure out who I might know. Of course, I didn’t meet everyone there, so I really want a way to mark the people I did meet and then review the people who said they’ed be at the next one.

The API keeps on turning

I did a few api-access experiments many months ago. Meetup had a pretty easy to use API with a simple Javascript wrapper to set things up right. I went to check for an updated version, only to find it had been removed. They appear to be moving to an OAuth centered API, so the older one is implicitly depreciated. Fortunately, I still had a copy of the wrapper library from before, and the API is still operational. OAuth probably would more appropriate for this application. The older API cooperated to the extent that it did JSONP wrapping, but OAuth requires a callback point, which generally means having my own server.

Facerize

While searching for the missing JS library, I found a reference to Facerize, which almost obviates the need the write it myself. However, if it has support filtering by event, it doesn’t advertise it. They’ve also been in invite-only beta for over six months, so I can’t try it out.

Client frameworks

I’ve been thinking that Siggnal will ultimately be an API with an example Javascript client. This requires choosing a framework (assuming I don’t want to write everything from scratch) FaceQuiz gives me a chance to try something out in a hopefully limited engagement. I started with JavascriptMVC, since I know the developers through the Chicago Javascript Meetup Group.

JavascriptMVC

MVC is of course Model, View, Controller. Models are fairly lightweight. There is a provision to specify only the URLs, but this assumes that you have Rails-esq RESTfull endpoints. Fortunately, doing more creative things, such as using the meetup wrapper or localStorage, just means implementing a conventional set of methods like findAll, findOne, create, destroy, etc.

Views are just ‘ejs’ templates using the defacto <%%> tags. Controllers render views and then set up event bindings on their elements. There is also a generalized event framework which really forms the core of tying programs together. As one example, models will generate events (a service you have to provide yourself if you are overriding the model methods) so that controllers can keep up on lifecycle events like created, updated, and destroyed to update the page. Event binding on controllers is streamlined by interpreting the object keys as psuedo selectors, rather than calling some sort of bind method.

It’s a completely generic mechanism however, and the real art comes in choosing sufficiently ‘domain’ events for each controller. As an example, I set up FaceQuiz as a three-tab interface with Quiz, Events, and Meet. The event list triggers an event.selected er, event. This gets picked up by the meet controller to look-up the appropriate list of attendees and the quiz controller to filter the pool to quiz over. It also gets picked up by the current-event control, which displays the selected event while in the other tabs, and also allows one to clear the selected event in order to go back to quizzing over all connections. Clearing happens by trigging the same event.selected with a null value.

The javascript module problem

Probably my only concern with JavascriptMVC is it’s module loader, Steal. It works well enough, but after using RequireJS (e.g AMD style), there is just something grating about big.long.namepsaces.of.doom. I also assume it’s using XHR underneath since Chrome won’t load the app from the filesystem. I’m trying not to be bigoted about it.

Could I just not use Steal? I could probably get away with it for developing my application, but JMVC itself uses Steal internally. It’s not clear that it would be possible to generate a combined and minified file with two packaging systems involved, and it would neither improve the loading situation nor remove all long namespaces (without writing an adapter layer)

Posted Monday, June 6th, 2011 under Devlog.

Comments are closed.