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.
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?
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.
Tropology is an experiment in visualizing conceptual networks from TVTropes. The initial idea was that, starting from a chosen concept, we could visualize the list of tropes and articles it referenced, along with the relationships between them.
Experimenting with the data, which even after some judicious pruning includes over 220 thousand nodes and 11 million relationships, led me to quickly conclude that the model was too widely connected. We couldn’t just visualize the raw data and needed to apply some sort of direction in order to make the visualizations sensible.
Let’s see how to go about that.
Or, apples vs. papaya salad.
Short version: I’ve moved Tropology to PostgreSQL for performance reasons, and because after some evaluation, Neo4j wasn’t as good a fit as it seemed at first blush.
You may want to start by catching up with the other Tropology articles.
All done?
We got better performance with the last changes I made to the import process, at the cost of parallelization and a significantly less clean Clojure codebase.
As I was going about wrapping them up, I got a recommendation from Michael Hunger. Summarized:
Well then. So much for that feature branch.