The Clojure learning curve

I love Clojure.

Once you have tried it and enjoyed its advantages, you just don’t want to go back. But those same qualities that make you love it can make it easy to forget that, for someone who’s first encountering it, Clojure can be a threatening, scary area far outside their comfort zone.

A few weeks ago I gave a talk at the Bucharest Functional Programming Meet Up. The title was Clojure All The Way Down, since my initial plan was to focus on how to program web applications completely in Clojure (both the browser client and back end), and what it brings to the table.

Two things happened as I prepared the talk.

Relevance - Preview release

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.

Respecting early adopters

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?

Using devcards for testing a ClojureScript Chrome extension

Introduction

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?

Enter devcards.

Getting HTTP 405 from a Chrome extension?

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?

Kinect and the mystery of the floating torso

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.

What gives?

ClojureScript and Chrome extensions

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.

Yes, you can of course build Chrome extensions with ClojureScript, as other articles have pointed out. It’s, after all, just Javascript underneath. There’s some set up involved, and the example given hew closely to the Javascript-way of doing things.

Below are some tools that can help you with a more idiomatic way of doing things in Clojure.

Open source project details

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.

Prediction - Kinect will fade into the background

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.

Too bad the Kinect failed

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.