As of today I am working on three projects. This wasn't intentional but it's very hard to avoid due to the ease of thinking things into existence within the software world.

To tell you the truth, I do not expect to finish them. Progress is slow and each is significant enough to require me to backtrack and re-envision the concepts over and over again.

That is why I have been drawing sketches.

---

Observe

Functional programming in JavaScript is difficult to debug because it is difficult to observe.

JavaScript's dynamic typing means it is possible to write code that calls a function with the wrong data, and if this happens within a lengthy or complex functional pipeline it can be very hard to infer which function or construction is to blame for an error.

A solution to this might be the usage of a library that can add type definitions to the language such as TypeScript or Flow. However this seems against the spirit of the original language, and I believe a more fitting approach lies in ideas discussed in Bret Victor's Learnable Programming.

With that in mind, I wrote an early prototype, ramda-debug, to visualise the runtime states of a functional pipeline.

I like to imagine future versions of this library will not concern themselves with logging, but instead emit events that can be handled by clients such as Atom's Hydrogen (perhaps through interfacing with Jupyter, or by working directly with a debugger).

These runtime-produced events could eventually help to afford the creation of new kinds of visual debugging experiences that break-free from established debugging norms - for example, visually highlighting a failed call stack, within a directed graph of function calls.

Orient

Back in December 2013, I wrote that "the majority of software interfaces are broken". I speculated that while there is an explicit mapping between a URI and a request handler, the one-to-many mappings between responses and response handlers necessitate the usage of broad, multi-purpose server responses, the result of a one-size-fits-all approach to client's needs.

My final thought was:

"A man walks towards a door to a building which has a hole instead of a door handle. The man removes a door handle from his pocket which he screws in. The door opens. [By analogy] a response should encode a response handler's method signature."

A few months passed and a few of these ideas birthed jstruct.

Jstruct allows quick and easy JSON transformations through the use of a declarative JSON DSL.

This does not itself provide a solution, however it does provide the first piece of one.

In the future I believe that a small middleware could be implemented that would pass the response expected by a client from within req.body to a transformation function. This would ensure that clients could explicitly define what they wish to receive from a server.

Recently Facebook created a project with a very similar goal called GraphQL. My approach differs in that (1) I probably won't have the time to finish it, (2) it would be JSON-first and therefore easy to parse, (3) when calling the data transformation function, I would separate the definition of the request from the definition of the expected response, and (4) by default, I have a preference towards not using custom libraries for each data store that must be supported.

Decide

Despite my intent to keep each of the projects small, I probably only have energy and resources to complete just one.

The benefit of small projects is that you are able to very quickly release initial versions. On the other hand, with bigger and often more rewarding projects the cost of the first version could be months of full-time work.

Last year I worked on such a project. I decided to take a break from it towards the end of the year, and the smaller projects of early 2015 were ultimately attempts to keep myself ticking until I regained perspective and focus with which to return to it.

I now plan to redevelop the ideas and work that composed the larger project. If last year is anything to go by, it will be all consuming.

Act

Over the past few years, I have become very interested in modern social technology and in particular the ways it can make interactions vastly cheaper and therefore easier to game.

I believe that it can be argued that cheap connection isn't always quality connection, and that anything that tends towards creating social atomisation is harmful.

My hope, however, is that it might be possible to create technology to afford good peopling.

That is, I believe it's very important that we think about what tools that could help people form bottom-up communities for mutually beneficial intellectual, emotional or economic trade would look like. And so this is what I've been doing.

Last year I began work on a prototype of a tool to help form small, helpful communities of well-differentiated people. The sentiment behind this was somewhat echoed by a piece that later appeared in VentureBeat and its aim was to create small communities of less than 150 people.

When I last worked on the project it was on an alpha of the iOS app. Since then some APIs that I was using have been revoked, however despite this a decent amount of work has already been achieved.

Tomorrow I start work on it again. I'm happy for anybody interested in creating tools like this to get involved. I'm interested in taking all of the ideas apart to see them with a fresh perspective.

After all, these projects might all be sketches, but they are sketches that I care deeply about.