In Part One of this series on the oclif testing library, we used a test-driven development approach to building our time-tracker CLI. We talked about the oclif framework, which helps developers dispense with the setup and boilerplate so that they can get to writing the meat of their CLI applications. We also talked about @oclif/test and @oclif/fancy-test, which take care of the repetitive setup and teardown so that developers can focus on writing their Mocha tests.

Photo by Kevin Ku on Unsplash While writing a CLI tool can be a lot of fun, the initial setup and boilerplate — parsing arguments and flags, validation, subcommands — is generally the same for every CLI, and it’s a drag. That’s where the oclif framework saves the day. The boilerplate for writing a single-command or multi-command CLI melts away, and you can quickly get into the code that you actually want to write.

Introduction In this article I’d like to touch on async, await, and Promise.all in JavaScript. First, I’ll talk about concurrency vs parallelism and why we will be targeting parallelism in this article. Then, I’ll talk about how to use async and await to implement a parallel algorithm in serial and how to make it work in parallel by using Promise.all. Finally, I’ll create an example project using Salesforce’s Lightning Web Components where I will build an art gallery using Harvard’s Art Gallery API.

Photo by Denis Agati on Unsplash Best Practices for Logging In part one I discussed why monitoring matters and some ways to implement that. Now let’s talk about some best practices we can implement to make monitoring easier. Let’s start with some best practices for logging — formatting, context, and level. First, be sure you “log a lot and then log some more.” Log everything you might need in both the happy path and error path since you’ll only be armed with these logs when another error occurs in the future.

Photo by Luke Chesser on Unsplash Introduction What do you do when your application is down? Better yet: How can you *predict *when your application may go down? How do you begin an investigation in the most efficient way possible and resolve issues quickly? Understanding the difference between logging and monitoring is critical, and can make all the difference in your ability to trace issues back to their root cause.

In part one I discussed the first version/Bluetooth version of my desk upgrade. In this article, I’ll discuss upgrading the desk to use Google Smart Home so I can control my desk with my voice. WiFi and Google Smart Home Adding WiFi to the desk was actually pretty simple. I swapped out the microcontroller from the Nordic NRF52 to an ESP32 since the ESP32 has WiFi built in. Most of the control software was portable since it was written in C++, and both devices could be programmed with Platform.

Introduction In this article, I will show you how I converted my manual hand crank desk into an automated IoT connected desk. I’ll be talking about how to size and pick motors, and how to connect your custom IoT devices to Google using Heroku as a public interface. In short, there are two sides of this tech project: the first is to get from Google to Heroku using voice commands, and the second is to get from Heroku to the desk using MQTT.

Photo by Jason Pofahl on Unsplash Let me tell you a story I have been playing with Kubernetes for a while now. I run a three-node cluster as VM’s on a server in a basement somewhere. I’ve only been hosting my father’s website and various other experiments on this cluster, none of this receives very much traffic and (don’t tell my dad this) but I take his website down all the time by experimenting with the server, Kubernetes, and his website.