I’m a tab-aholic
I normally do a search, start opening the tabs that seem interesting, and then as I flip through them, I end up opening even more links on tabs as they seem relevant. Next thing I know I have a huge mess of tabs, and it’s hard to remember which one I’ve read or which one is important.
Relevance is a Chrome plugin I wrote to help manage that.
Perhaps the trickiest thing when developing an open source library is figuring out the balance between changes you feel are necessary, and respecting early adopters.
Take the case of khroma, the ClojureScript library for providing idiomatic access to the Chrome extensions API. It’s very much a work in progress, and I’m developing it to use on an extension of my own. The way I go about it is exposing functions and event handlers mostly as I need them, to avoid getting sidetracked into surfacing functionality for which I don’t have a practical use case right away.
However, when developing something organically, the question then becomes: where do you draw the line between unifying the way the APIs behave after adding functionality, and not breaking things for those very early users?
A few weeks ago I wrote a short piece about the available tools for building Chrome extensions in ClojureScript.
Among the tools I reviewed was khroma, a still very much work-in-progress ClojureScript library providing idiomatic access for the Chrome API. One of original comments I had was that khroma was still incomplete, and had some not entirely evident function names.
I have since taken up khroma development and begun extending and refactoring it. However, a question immediately came up: how do we go about testing it? Your first impulse might be to say “why, don’t we have cljs.test?”.
Yes, we do, but we can’t run these tests automatically from the command line: the APIs are only available when you’re running inside Chrome as an extension with the right permissions.
Moreover, I’d like to be able to provide usage samples and data review for the myriad of events you can hook up to, some of which aren’t easily testable because they depend on user input, or asynchronous inter-page communication. How to go about this, then?
I recently spent some time pulling my hair at a Chrome extension problem, and it turned out to be something rather silly.
I was attempting to do AJAX requests from an extension to a test local REST service, which I’d written in Clojure using Liberator. GET requests did get to the server, POST didn’t. In either case, however, the extension did not get a reply, and Chrome just reported that it was returning a method not allowed because the resource didn’t have an
This was very odd. First, why would Liberator not fail on GETs at all? Liberator should only return 405 when the request method is not allowed - when did this change, if ever? And then, even if it was a Liberator configuration issue, why would I be able to successfully make requests to it using HTTPie from a terminal?
Anyone who has worked with Kinect will tell you that the information you get out of the sensor is somewhat noisy. This is particularly problematic if you’re doing avateering, you can’t just apply it directly to a model - you’ll need to do some filtering, such as double Holt exponential smoothing.
We were nearing the deadline for an interactive installation, then we got a very odd report: the client said that while everything was going perfect for 99% of the cases, when a particular QA user tried the application the avatar legs suddenly started wildly kicking around.
This made no sense to us - the algorithms we were using were in no way person-specific. I asked them to send us some video of how the render looked and sure enough, the legs were flailing around as an epileptic octopus.
Intrigued, we moved to the next step in debugging and checked a recording of the raw Kinect data. This immediately showed us what the problem was: Kinect was seeing the user as a floating torso.
There’s not as much documentation on building a Chrome extension with ClojureScript, so I thought I’d document my findings on the current state of libraries.
Below are some tools that can help you with a more idiomatic way of doing things in Clojure.
Up until now whenever someone asked about our open source projects I referred them directly to my Github page. That’s the repository, sure, but might be a bit noisy as it contains a mix of the projects I’ve created and maintain, with repositories I’ve forked (some of which I contribute to, but not all), with older projects.
I decided it was time to clear things up a bit, so I’ve done a brief write up on those that I’m actively maintaining. It has a better introduction to each, including both their application and licensing details.
Head over to the open source page to read more, and let me know if you have any questions.
On a previous post, I was commenting on how the Kinect’s lack of success as a gaming input device could easily be mistaken as a failure of the device itself, if one doesn’t look at the multitude of areas where it’s being used. Its future seems to be up in the air, however - if those other applications are niche, and it hasn’t succeeded in entertainment, then what?
I’m willing to make a prediction about where it’ll go: Kinect (or devices like it) will become ubiquitous and fade into the background.
I had lots of interesting conversations after my talk at the recent nucl.ai conference in Vienna, but one in particular sticks to mind. I was talking to an indie game developer who’s using the Kinect for a project on his college, who remarked:
Yeah, the Kinect is great. Too bad it failed
It’s an interesting sentiment because it’s a gamer or game-development one. On the home, as a game controller, the Kinect was definitely a failure. That is no surprise: I’m on the record as saying that game controlling and avateering are perhaps the two tasks that the Kinect is worst at (even though they are two tasks for which it keeps being pushed).
But there are all the areas where Kinect succeeds that have nothing to do with game development.
If you look at the lein cljs-build sample project, you’ll see that it states:
; The :builds option should be set to a sequence of maps. Each
; map will be treated as a separate, independent, ClojureScript
; compiler configuration.
If you look at the example right below that description, you’ll see that it is actually set as a map of configuration profiles with the configuration name as the key. So what gives?