What I learned in 2018
What I learned in 2018
This is inspired from Dan Abromov’s recent blog post on knowing what you don’t know. 2018 was a big year for my career as a developer and I wanted to jot down some highlights about what I did learn.
At the start of the year, I was part of a project that used docker for many different services to be consumed by their UI. There were probably 7 or 8 different container images (the project is long over and I don’t remember) and this was the first foray into the docker and architecture of micro-services. I learned a lot about running images locally, debugging problems with a service, and developing the UI locally against a local docker server. I came away thinking the architecture of micro-services could be very powerful and (probably more importantly) highly maintainable by separating the concerns of different services.
This last year I also took a good solid week to find some solutions to testing our redux-saga functions. If you aren’t familiar with redux-saga yet, you can find more info on their site. This was a fun challenge because I had to question my understanding of how we use redux-saga and be sure that we cover all scenarios. I ended up deciding on a library called redux-saga-test-plan. This library seemed to be flexible enough to cover many different scenarios and usages for our needs. I then helped the team adopt the library and provided support.
Configuring continuous integration pipelines was actually a highlight for me. I have a couple personal projects that use CI (gitlab and buddy) and get some kind of odd pleasure out of setting these up. I had the pleasure of seting up a pipeline for a client project that inevitably deepened my knowledge of configurations, containers, environments, and security. CircleCI has been the go to for my team. Personally, I’ve been really liking a service called Buddy that provides a very clean and intuitive interface for debugging different failures in your build and deploy pipelines.
Prior to 2018 I had only built some express servers with Node but this year I got to dig a lot deeper into node and some other features of it’s API. Most notably would be the file system API and handling buffers. Having started as a purely front-end dev, learning this quite fun and very enlightening. With the help of my team, I was better able to understand the value of using buffers versus holding all information in memory and handling creating, updating, and editing files with the filesystem API. Node seems like a powerful technology and with the newer async/await (via transpiler for time being) it could really be awesome to work with. I’m eager to get some more experience with this. I recently built a GraphQL server with Node for a personal project which was kind of awesome. I’ll continue hacking on it when I have the time.
Learning Unity has been for our company’s investment into the AR/VR landscape. Unity is really a different beast but I’m beginning to realize the potential. The community support is vast and plentiful, and the docs and tutorials are great. I’ve only dabbled a bit but I plan really dive deep as we start developing for the Magic Leap and our in house Oculus projects.
Learning C++ was inspired by my interest in web assembly, the Magic Leap api, and the JUCE Api. I’ve been a musician for most of my life, so JUCE was my first interest. If you’re not familiar, its a C++ library that allows you to create audio applications or plugins. I have dreamed of creating a software synth with it, but for the time being my knowledge of C++ has yet to get me there. Soon though! Web assembly is something I’m very interested in since most of my knowledge is in the domain of the web. I think once it has matured a bit and people have created useful patterns to develop with, it’s really going to improve our experience using the web.
I have to mention Vim! I forced myself to use vim in my VSCode environment and now I love it! After I got used to some key commands, with the help of the internet, I set up my local vim environment to be fairly productive and it is certainly awesome. I know there is some kind of rivalry from within the emacs community regarding which is better, but it’s really a “to each their own” situation. I can’t imagine trying to code without it now.
Fastlane is a service to quickly code sign and deploy your iOS apps to test flight and the app store. I had gone through the process of deploying an app manually last year and discovering the ease of Fastlane was a serious relief. A really great tool! If you haven’t checked it out yet, I highly recommend it.