Working at Metal Toad is all about innovation. It’s why I was drawn to this place—a place that celebrates the unusual, gets excited about new ideas, and constantly seeks out the latest emerging tech.
Dylan Tack's Blog
I've long been curious about the effectiveness of the built-in antennas that are attached to common WiFi modules. Can that tiny, serpentine PCB track really match the performance of a "real" antenna? How does it even work?
I set up a quick test to find out. Using a pair of ESP8266 development modules, I set up a test measuring gateway ping times, and sending the resulting values to AWS IoT Core. Messages are routed to Firehouse, stored in S3, and aggregated with Athena. (AWS has put together an impressively elegant IoT pipeline, but that's a future post!)
Your Serverless function has a secret... maybe it's a password for a remote API, a private key, or signing certificate. These secrets have to be stored somewhere, and in the old days that usually meant just a plaintext config file on your server. Sure, you could encrypt it, but then you have to put the key on the server, and you haven't gained anything except a bit of obfuscation. Or you could use more complex schemes, like Hiera-Eyaml, which is a small improvement, but you've really just moved the threat to a different part of your infrastructure.
“MTBLS”: I first encountered this phrase on a New Relic blog. It's a half-joking reference to a concept used by reliability engineers, Mean Time Between Failures (MTBF). I was intrigued though, and thought it would be an interesting metric to track.
We have high-resolution data about our machines' health – down to the smallest minutia – but precious little about the health of our people.
Bamboo / GitHub integration isn't perfect – perhaps because Atlassian wants to steer you towards Bitbucket (their GitHub competitor). Out of the box, there are several headaches. Below, I'll cover these, and how to solve each one:
We are heavy users of Bamboo for Continuous Integration & Continuous Delivery (CI / CD). It's extremely flexible, integrates well with Jira, and elastic build agents make the most of AWS EC2 (even giving you the option of spot pricing for on-demand instances).
In my last post, I wrote about the cost of tech debt, using a case study of skyrocketing hardware costs. Here's another, subtler effect of poor performance: impatient customers don't stick around when they experience slowdowns. However, choosing to prioritize speed can be hard to justify when the cost isn't quantified.
Years ago, I received a frustrating email from a disappointed client. I was confused – from an engineering perspective, this should have been a model project. It nailed the requirements on time, under budget, with great documentation, full unit test coverage, and even included some cutting-edge original research and upstream open-source contributions.
Here's the email (emphasis added, scare quotes original):
Technical Debt: we all have it. Yet, this phenomenon remains poorly understood by product managers. Unlike financial debt, the costs are often hidden and difficult to measure. But the most dangerous aspect is that "Technical Debt items are contagious, causing other parts of the system to be contaminated with the same problem, which may lead to nonlinear growth of interest." 
Here's a case study of one such event; unmanaged tech debt caused interest costs to spiral catastrophically out of control.
I was dusting off my copy of Ray Kurzweil's The Age of Spiritual Machines today, and found a fascinating chart (adapted below). The book was written in 1998; it's interesting to reflect nearly 20 years later we're more or less on schedule. $1000 will buy you an electronic brain with a "thinking" capacity somewhere between a mouse and human.