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 Access-Control-Allow-Origin header.
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.
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.
I participated on a fascinating panel yesterday at the (still ongoing and live-streamed) nucl.ai 2015 conference. One question asked by Richard Kogelnig, the moderator, was why have new input devices like Kinect and Leap Motion have failed to really penetrate the consumer market, and what sort of a device would really have a chance at making a difference.
I don’t think it’s a technical problem. I think it’s a message problem.
A recurrent question about UnitySteer is how to implement behavior like that of a flock of starlings (seems that Mr. Reynolds was right on the money when he chose flocking for his paper).
Usually the person who writes mentions that their implementation is “getting there”, but they’re not quite happy with the result yet. The main issue with the question is that if the results are right or not are all about perception - it’s not a problem where there is a single, provably optimal solution.
With that in mind, I’ll detail some of the aspects of the starlings from the video above, and mention how you can mimic them in UnitySteer.