What I learned in 2016

8 January 2017

Last year was a real year of learning code for me. I hadn’t quite realised how much so until I went to write a list of the major new things I learned in 2016 and realised they’re nearly all related to coding. That’s not to say I spent the whole year coding full time - I have a full time job on the other side of the city, and it doesn’t involve writing any code or scripts. I’m sure I learned lots of other stuff too (I spent three weeks in Japan, after all), but these are the things that stick out:


I started learning JavaScript and nodejs in 2015, but it was really last year that I started to understand how to do more complicated things and make actual programs, as small as they are. Mostly this has been in the form of Twitter bots. I challenged myself to make twelve bots in twelve months. I didn’t quite make it (as of the end of December I’d launched eight), but I’m not going to beat myself up about that. The point wasn’t so much to make bots as to use bot-making as a series of projects that would help me to learn more about coding.

I’ve learned more about the twit package, for example, and now know how to programatically include images in tweets. I’ve learned to modularise my code more, enabling me to move data around, keep my code DRY, and re-use code in other projects. Very late in the year (between Christmas and New Year) I learned about Graphics Magick and the gm package on npm. This allows you to edit images programatically. This enabled me to make a new, really stupid bot I called Rijks Teen Press. It takes the RSS feed from Teen Vogue (in the news for their suprising-to-some direct reporting on Donald Trump), and pairs a random title with an image from the RijksMuseum image API to make a weird kind of book cover. It was great fun to make because I was working with the gorgeous images from the Rijksmuseum, and learned a little about what can be done with Graphics Magick - definitely something I’ll be going back to.

Mylar for Meteor

Last year I finally finished the project that in some ways was the trigger for me to finally learn to code - Tinfoil. This is a demo of how a Library Management System could work if it used client-side encryption to store and use loan history in a way that is only readable by each borrower. The key technology is Mylar - a Meteor package that enables client-side encryption of data but also enables a system to search over encrypted data without decrypting it. Sounds ...surprising when put like that, but it really is pretty cool. Unfortunately for me, the documentation was definitely not written for programmers who barely know JavaScript (and understandably so!). I got there in the end, and was really proud of the result, though I’m sure it’s not 100% secure the way I implemented it.

Docker (a bit)

I spent the first three quarters of 2016 cursing Docker and all those who use it. If you’re using software that has been ‘dockerised’, it becomes rather opaque and difficult to debug if you don’t know how to use Docker. This is essentially what happened to me when I was trying to deploy Meteor apps via mupx (see more below). But Docker is becoming more and more popular, and eventually I realised I probably needed to understand it at least a bit.

I was finally forced to prioritise this when I wanted to save money by moving Tinfoil from its own VPS onto a second one I was using for all my Twitter bots. The problem was that the bots, and the GLAMblogs Meteor app, that were running on the second VPS all used different version of nodejs to Tinfoil. Because Mylar hasn’t been updated for a while, and both Meteor and nodejs development has been racing along, there was no way to deploy Tinfoil, GLAMblogs and the twitter bots all on the same nodejs version. Suddenly I understood why Docker has become so popular.

I wouldn’t say I “understand” Docker, but I’ve now learned to deploy Ghost blogs, Meteor apps and nodejs Twitter bots using Docker - allowing each to run with its own dependencies and the necessary versions of each.

How to deploy a Meteorjs app directly

As Meteor development sped up during 2016, deploying Meteor apps on the latest version became increasingly difficult for those using mup. As you can see from that link, there are two completely new versions since the original, and mid-year mup was very unstable because of the need to keep up with architecture changes in Meteor.

After a major fail trying to deploy Tinfoil, I decided to seek alternatives, and eventually worked out how to deploy to production without using mup, Galaxy or any other ‘simple’ systems. Native deployment is reasonably straightforward, but understanding exactly how to do it involved a lot of Googling and a great deal of swearing before I got it right (Meteor development is a lot easier than Meteor deployment!). I really do want to thank the Meteor community for the many blog posts and Stack Exchange answers that allowed me to work it out. I still haven’t blogged about my solution, but I’ve got something in draft that I might put up eventually.

ES6 (mostly)

JavaScript has been changing in the last year as well. I read Ethan Brown’s Learning JavaScript and it was super helpful for understanding things like the differences between const/let/var declarations, using back-ticks, exception handling, and what the hell Gulp and Babel actually do. I’m certainly still a long way from being confident, but I’m comfortable with the basics and much better at finding what’s causing errors and understanding why.

Upstart and systemd

For quite a while I was using Forever to keep apps running, but a major bummer about Forever is that it doesn’t restart when the server is rebooted. Once I made Pictures of New York I was more concerned about ensuring apps were always on line, and started looking for alternatives. This led my to Upstart, and on Ubuntu 16, systemd.

Upstart and systemd both use a lot of words on their websites to explain what they are, but for my purposes they allow you to rerun scripts automatically if the script fails or the machine is restarted - exactly what I wanted. The syntax for Upstart is much easier to understand than systemd, and I’m a little disappointed the Ubuntu developers decided to ditch Upstart for systemd, but I don’t know enough about either of them to appreciate the arguments.

D3js (a teeny bit)

Something I’d like to go back to this year is a project I started for a simple Meteor app that tracks the twitter conversation for an event (I was thinking of conferences). Whilst I’m sure there are lots of existing products, the aim here was as much to learn new technologies as use the finished product.

The main new thing I was learning is d3js and it’s both extremely powerful and, for me, exceedingly difficult to comprehend. Lacking any background in either computer graphics or complex mathematics, I certainly have been a slow learner on d3js, but it is such an amazing tool I’m keen to keep learning.

A bit more about MARC

At my job I have been doing a lot of work on a semi-secret project I’ll no doubt be talking a lot about in 2017. Whilst I’ve never let it stop me shooting my big mouth off about it, I have never actually had a great deal of knowledge of MARC. But this year I’ve learned a bit more, due to my work project. This has actually been interesting, though it hasn’t changed my views on MARC - it’s still bad and needs to die in a fire.

The Melbourne GLAM community is amazing

In 2015 I started newCardigan with some other ne’er-do-wells, and in 2016 Melbourne’s GLAM community really embraced it. I’ve heard amazing Cardi Party speakers, had fascinating conversations over drinks, and met some great people who are doing extraordinary things. I was pretty sure a constituency existed for what we were trying to do with newCardigan, but I’ve honestly been surprised by how quickly and energetically GLAM professionals have embraced newCardigan and how generous so many of them have been with their time and energy. I’ve also learned a tonne of stuff about archives and museums and all the careful thinking that goes into how they are run. You’re all amazing!

So, those are the big things I learned in 2016. In the coming year I’m hoping to learn a stack of new stuff - about coding, about libraries, about people, and about life. I might even blog about them more than once a year...