For all the toil that went into developing the pipeline and deep learning model for my ML baby monitor project, I discovered that my model didn't actually solve the problem at hand. This kind of gap exists in the real world of ML development as well, and there's a critical insight from the field of User-Centered Design that could be the key to bridging it.

Over a year ago, I wrote a couple of blog posts about how I trained a TensorFlow model on audio clips of my crying baby so I could get some insights into his sleep patterns and behavior. I distilled this experience into a PyGotham talk titled "Can Neural Networks Make Me a Better Parent?" and it reflects some extra maturity in my machine learning knowledge, as well as some hard-won parenting wisdom and experience.

It's been several years since I've come off of my former role as an engineering manager, and with enough humble introspection I've had several insights into the mistakes I've made, and how I'm integrating those learnings into my teams nowadays.

A discussion about why I enjoy working in the XP-school of Agile. (tl;dr: I enjoy working in a pull-based work stream. I like that pair programming, TDD and other best-practice batteries are all included.)

In which we train an TensorFlow model with the tears of my little one, then deploy it on a Raspberry Pi.

How do you deal with the travails of colic and new parenthood? You plunge yourself into an ML project, of course. Here, we discuss a naive solution to detecting baby cries via an onboard microphone on a Raspberry Pi.

While it’s been pretty quiet around these parts, I’ve kept the technical blogging up over on my employer’s blog. I’ve got quite a few posts around Elixir:

I posted an article on Medium titled “Wejoinin at Ten” describing our experience developing Wejoinin over the past ten years as a long-running passion project - and talk about the directions we hope to be taking it in the next ten.

I recently published a post on the Carbon Five blog titled “Evented Rails: Decoupling complex domains in Rails with Domain Events” that takes some of my thoughts about moving a Rails app to use Domain Events - leveraging the power of Sidekiq (or your job runner of choice) to send async messages between different domains of your app.

The first question you may be asking is - why would I want to go from Rails to Java?

You’ve resolved to build your company’s Next Big Thing in Phoenix and Elixir. That’s great! You’re facing a problem though - all user authentication and access concerns are performed on your Rails system, and the work to reimplement this in Phoenix is significant.

One common pattern in Domain-Driven Design is the use of publish/subscribe messaging to communicate between domains. When Domain Events are created from within a domain, other domains are able to subscribe to these events and take action within their own domains, respectively.

I want to discuss a topic near and dear to my heart, and what I believe is at the crux of effective software design. It’s not a new functional language, it’s not a fancy new framework, a how-to guide to do microservices, nor a quantum leap in the field of machine learning.

As follows are some code snippets for using Knex.js for executing Postgres and PostGIS queries.

Much of RxJS involves working with backpressure - how to reconcile streams that emit/process data at different rates, without overloading the system. Much of that model is built with lossy handling in mind - it makes sense that when your system is under duress, that you design your streams to degrade gracefully (e.g. drop certain events, or rate limit them by chunking into windows, etc).

One of the confusing aspects about working with streams is diving into Rx operators that take a stream and fan out into multiple streams.

Going to Strange Loop was a huge check off my conference bucket list (lanyard?). I’d always heard about this slightly-weird, highly academic collision between academia and industry, skewing toward programming languages you haven’t heard of (or, at the very least, you’ve never used in production). I anticipated sitting at the feet of gray-haired wizards and bright-eyed hipsters with Ph.Ds.

A couple of months ago, I was tuning a Rails app for one of our clients. This client wanted to know how performant their app would be under load.

The following are some notes I’m compiling as I’m beginning a journey down the rabbit hole, writing an app in Swift utilizing the VIPER app development methodology

With my current fascination with tracking workouts and location-based-activities, I have been interested in how I might be able to rewrite some of my stats logic with FRP principles.