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?
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.
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?
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.
Yesterday we were discussing our (admittedly) somewhat ghetto, not-quite-batched Neo4j implementation.
The long and short of it is that I was initially attacking the import process as one would on a JDBC client for a relational database. Query for these values here, create those if some don’t exist, insert relationships here, etc.
That seems to be woefully inefficient in Neo4j.
Welcome. You may want to first catch up on Part 1 of this little experiment.
All done? OK then.
This is the first part of a series of articles on a small experiment I’m building. The intent is to crawl TVTropes, to find possible relationships between tropes and the material they appear in, as well as shared concepts.
I want to be able to not only visualize a concept and the tropes that it links to, but also how they relate to each other. A bonus would be being able to query how far away a concept is from another - for instance, how many steps we need to take before we can go from Cowboy Bebop to Macross Missile Massacre.
This one bit me a bit hard and, seeing as I could find only one reference for it in the context of Clojure and Leiningen, I thought a small write-up would help.
After including some ClojureScript code on my project, lein started barfing when I attempted to build an uberjar with any optimization settings other than none.
Exception in thread “main” java.lang.NoSuchMethodError: com.google.common.io.ByteStreams.limit(Ljava/io/InputStream;J)Ljava/io/InputStream;, compiling:(/private/var/folders/64/ckdtdxm14059n9wh8rhf1mvw0000gn/T/form-init527739448955044836.clj:1:123)
There was only one obscure reference I found, from an IRC chat now a couple of years old. My first thought was that something in the ClojureScript code was throwing off the compiler, but it seemed odd that this would trigger a call to a specific non-existent method.
Other searches - outside of the lein context - made me realize it was actually a dependency conflict, and only triggered on uberjar because since there wasn’t any ClojureScript code deployed before the compiler hadn’t had to be invoked.
Calling
lein deps :tree
showed there were multiple versions of com.google.guava being referenced, with the one used by ClojureScript being 18.0 but a much older 11.0.1 being referenced by urly. Seems like lein either doesn’t realize there’s a conflict or defaults to the older library, which was causing the error when ClojureScript attempted to build.