The new project will be a triptych. I’m planning to show it at a gallery If you own or know a gallery which might be interested, let me know! in spring 2018, if all goes well. I’ve spent the past couple of months working on the first piece, which will be turning the lens of perception back at Facebook.
The social graph is Facebook’s ticking heart, powering its entire business. Constantly evolving, fed by Facebook’s relentless algorithmic perceptrons, it is one of the largest data structures ever created. Yet, access to this graph is limited and traversing it requires permission from the gatekeeper.
Luckily, the web is still an open place and Nmap is still the kickass tool it always was. Back in 2008, I worked on adding the network topology mode to Zenmap and I loved it. Mapping the network paths is a wonderful way to begin visualizing the hidden world of networked machines. It is also a way for us, the people, to make a graph of our own.
I’m currently working on managing the complexity of the graph and keeping it somewhat “recognizable”, while heavily iterating the visual style. I’m posting images more regularly on my Twitter profile.
In parallel, I’ve been improving the set of Clojure tools I started writing way back with the logo project. I’m currently focusing on the compute graph library, which I wrote from scratch using Clojure’s core.async primitives.
For very simple computations, the common “load code, compute geometry, tweak parameters, repeat” workflow is sufficient, and the REPL is a wonderful tool of the Gods. However, I want to push the envelope when it comes to the amount of data being ingested and the amount of geometry being produced by my algorithms. Reloading everything, every time is a very wasteful operation and the iteration time prolongs drastically, to the point where the REPL-based workflow is almost as slow as the C++ save-recompile-rerun model.
The aforementioned compute graph library keeps track of the entire computation graph, and when you change one input parameter the changes are pushed (using core.async channels) only to subgraphs which need to be recomputed, without touching anything else Think Rx, but heavily parallelized. . This means that any heavy lifting performed before the stage you’re tweaking remains intact, reusing data and greatly improving iteration time.
I’m still contemplating whether I should release the compute graph library on its own, or as part of a bigger set of tools. My internal tool library – Beton – is slowly growing into a more openFrameworks-like form, encompassing windowing, OpenGL, mesh operations, scene traversal, etc. At this point I’m not sure if the community would benefit from it since I started rewriting and simplifying a lot of thi.ng code, but ultimately I’d like to release it as a collaborative open-source framework which will be both easy to use and contribute to.
More to come.