Every So Often

Every so often I take a step back and look at some of the things that have been created for v5. I'm generally impressed with what I see, but am consistently disappointed with the fact that I've been putting the day job ahead of this project. Yes, the day job pays the bills, but it's 10C that I truly enjoy working on. This project is just 0.6% of the way towards its goal, but it's foundation is something that has allowed me to learn more about the building blocks of the Internet than anything else.

Twenty years ago, when the web was still very young, I really didn't see the allure of "interactive websites". Forums and whatnot seemed slow and inefficient compared to the more dynamic spaces like IRC. It was around this time that I spent a great deal of my time writing applications for Palm PDAs and Windows. Dedicated applications were far more performant than anything online. Being in Canada also meant that the Internet, no matter how much money you spent, was slow. In 1999 I was paying $130 a month for what should have been a 1.5mbps DSL connection that typically moved at one-third the speed. Nearly 20 years later, Canadian Internet speeds continue to lag far behind what's found across the rest of the planet.

Web services, however, have proven themselves to be incredibly popular. People love the idea of having access to their information everywhere, regardless of device or location. I, too, find this incredibly attractive for most of my data. Where that data resides is just as important as its availability, which is where 10C comes into play.

The Midori API stack, the core technology that most of my web-based applications have been built on, was first created in 2010 while I was working at a startup in Tokyo. I needed a simple system that had an API and could interface with other systems to both send and receive data. The goal of the project was to have various web servers send data to this API which would then collate the data and turn it into statistics. The startup made social applications for flip phones, and we needed information about which services were most used, who used the system the most, the kinds of messages, and other things like that. The first version of the Midori API accomplished all of these goals well enough, though it was inefficient.

Later the company wanted to create an email client that would work with a couple of Japanese webmail providers as well as Microsoft's Hotmail. I was put in charge of making the API for that system while my colleagues built the front-end. One of the core requirements that I put forward was that we never stored a person's email in our databases at any time, even if it was for caching purposes. There was some reluctance to this but, eventually, people agreed that never storing people's email on our servers would be better in the long run. My boss gave me the challenge of ensuring that I could make the response time between the servers fast enough that people never complained about the lag between time time they asked for their mail and when they received it. With a great deal of effort, this goal was reached.

At this point, the Midori API now had deep email integrations as well as statistical endpoints.

The final challenge was put forth in 2011 when the startup wanted to reduce the amount of money it spent on Amazon EC2 instances. The early API that we had was created by my boss to interface between our applications and Twitter. The code had worked well enough, but needed to be better optimised. As the Midroi API was already proving itself to be quite versatile, I spent a weekend to build Twitter integrations that also made use of the current application endpoint structure. The following week we deployed it and saw that more people could use the service while our server load dropped. Another goal met, and now all of the core services offered by the startup were using my API, the Midori API Core.

In the summer of 2011, the startup was sold to Mixi and I turned down the opportunity to work at that company. All of the applications that the startup had released were put into "maintenance mode", and people started focusing on their new jobs. The day I returned the company notebook to my boss I asked if I could keep the code for the API that I had created, and he agreed. Mixi wasn't interested in the technology the startup created, but instead three of the talented programmers who worked there.

A few months later, Noteworthy was released to the world. This Evernote-connected blogging tool was the very first application of its kind and attracted the attention of a few people at Evernote who loved the idea. While the concept of using Evernote as a blogging tool was eventually abandoned, the core idea of having a unified means of publishing our content online remained. I wanted to build a single tool that could be used for all sorts of publishing, not just blogging. So along came podcasting and, with the demise of ADN, social. Other sorts of publishing has also been available to sone degree, such as photos and private files, but these have generally remained niche and hidden.

v5 will, ideally, change this. With this fifth version of the API and associated UIs, I'm hoping to offer something that will give people a great deal of power in a small package. But it needs to be released. It needs to be used. It needs to be maintained.

Which is where I find myself today, wanting to dedicate more time to the platform in order to get it ready for use by a much larger audience. Blogging and podcasting has gone out of fashion for a lot of people, and more are starting to turn away from large social networks. This doesn't mean that publishing platforms are no longer desired. If anything it means that platforms need to evolve to give people what they need, which can likely be boiled down to a single word: respect.

This is what 10C can offer people.