The house I was selling is finally gone and whilst it’s nice to have some cash the topic of inflation is getting a lot of attention in the current media cycle so it could be argued that I’ve actually lost an asset whilst gaining a liability. Wealth preservation There are no guarantees when it comes to investing and speculating but it is a certainty that cash sitting in a bank will steadily lose it’s purchasing power over time.
During the summer I built a web application to visualise the Bitcoin futures curve which proved very useful in informing my trading decisions. As useful as it was however, each time I viewed it I had to wait for the application to first boot on Heroku and then to perform a sequence of API calls to Deribit before the chart could finally be rendered in the browser. Impatience as the mother of invention I’d no other major projects that needed attention so building a more responsive native application seemed like a reasonable task to take on.
I’ve previously written some thoughts on service oriented architectures and since then I’ve wanted to explore beyond the currently accepted standard of sending and receiving JSON data over web APIs. Protocol Buffers With JSON there’s an overhead of transmitting plain-text over the wire coupled with parsing that text in your application once received. For many cases this is probably acceptable but for a large-scale distributed system this can represent a not insignificant cost in terms of bandwidth and computing resources.
One of the most bandied about buzzwords at the moment has got to be Docker. So many people I’ve spoken to claim to be moving their application environments to it and some even have it running in production with varying degrees of success. Fine in theory The theory of isolating groups of related processes into containers which then themselves can be further orchestrated to build out an environment is very appealing.
Some common pain points seem to keep cropping up time and time again as applications grow in size and complexity: tests get longer to run deployments become a much more involved process making a small fix to one area of code can often break something in another it can be much harder to reason about the system as a whole These large, monolithic applications are affectionately known as monorails in the Rails world and the common wisdom is to start splitting up the codebase into services: to extract areas of functionality out into self-contained, independent applications which work in unison to deliver the original capability.
Like a lot of people in technology a portion of my time is spent wondering what will be the next programming language, framework or whatever to take off and become popular. Of greater personal importance is the matter of which one of them will get added to my toolboox next and press-ganged into productive use. For years now Ruby has been my goto for a lot things and I’ve been doing more and more OS X and iOS development but it had been some time since I last picked up something new and I had a hankering for some shinyness.