It’s been an interesting few months and I’ll catch up with some of the things I’ve been tinkering with in a few future posts, but I wanted to give a primer on the technology layout for Hoist.
I’ve been a developer for most of my life, I remember my mum (who had the foresight to see that computers were not going away) buying computing magazines and helping my eldest brother type in code to display a christmas tree on the screen of our BBC model B. I remember assembling my first 386 PC from parts.
But it’s been a long time since I’ve been a tinkerer. Software development as a profession tends to put you on a single track, a single set of languages/frameworks/tools. You become a specialist through no fault of your own.
I’ve previously spoken of my efforts to not fall into this mould, learning a language a year, attending different user groups to my own, setting up WDCNZ as a cross language conference.
All of this has led to this point of trying to pick the best technologies for the goal of creating a really easy platform to use.
Early on our decision was that JSON would be the language of choice for communications. Our target market for our first BETA (front end developers) would be comfortable with it as a language for data and it’s becoming ubiquitous across all kinds of development teams.
As such I quickly dived into learning all I could about what store would be best to back our data service (one of the cornerstone offerings for Hoist) quickly settling on CouchDB as being one of the most robust choices to use.
Hoist currently consists of
Azure for VMs running linux,
Chef for VM provisioning and maintenance,
Capistrano for deployment,
MongoDB (don’t kill me Koz),
and a couple of other little bits and pieces.
I’ll aim to go into each of these in a bit more detail (probably starting with Chef and Capistrano as those were the hardest for me to get my head round/setup)
Needless to say it’s been an enjoyable experience so far, and we’re only just getting started.