When I was at Mailchimp, one of the hardest parts of making meaningful contributions was the total lack of type-safety; after all, it’s a decades-old monolith that predates things like scalar type-hints, enums, union & intersection types, etc. However, things broke more than once as a result of trying to add type-hints to even the […]
Just about four years ago, I joined Mailchimp, the Atlanta tech darling focused on providing small businesses the tools they need to compete with the bigger players.
Mailchimp itself had been acquired a few months prior by FinTech giant Intuit, makers of software like TurboTax and QuickBooks for a whopping 13 billion dollars.
Last week, Intuit announced a Reduction in Force (RIF) of approximately 17% of the workforce—roughly 3000 employees. As you may have guessed from the title of this post, I was among the impacted.
Whether you’re auditing third-party libraries or trying to toughen up your own test suites, you’ve likely come across a project boasting “100% code coverage”. It just sounds so official, right? 100% of this code is covered by automated tests, so it must be good!
I have good news and bad news. The good news is that a high percentage of code coverage does generally reflect an above-average effort to test the code—I’d much rather use a library with 60% code coverage than 15% (or zero!), wouldn’t you?
The bad news is that a high percentage of code coverage doesn’t mean that the code is necessarily working the way it’s supposed to!
In this post, we’re going to look at what code coverage really means as a metric (specifically within the context of PHP, but these lessons should be broadly applicable), as well as several ways that code coverage can give you a false sense of confidence.
If you’ve worked in a lot of codebases, this scenario will be familiar: somewhere in the app, we’re JSON-decoding a string, then using that to pass arguments to a method (such as a constructor). It may look something like this:
$json = '{"first": "Steve", "last": "Grunwell"}';
$data = json_decode($json);
$person = new Person($data->first, $data->last);
I’d like to humbly ask that you stop doing this. Instead, this post is going to show you how to accomplish the same result with a static, factory method and explain why the latter approach will save you all sorts of headaches.
Lately, I’ve been thinking a lot about helping smaller teams—especially those working with “legacy applications”—modernize their workflows. Working for a Fortune 500 company on an “enterprise-scale” application every day can cause you to take things like Continuous Integration and Delivery (CI/CD) for granted.
With that in mind, I’m going to try to turn my attention to simplifying some of these concepts. If you’ve ever been told “you should be using continuous integration” and been left wondering “okay, but how?” this post is for you!
Today we say goodbye to Shelby Marie Grunwell, a.k.a. the Greatest Dog to Ever Live.
She came to our family by way of Canine Collective, a wonderful organization out of Plain City, OH that rescues dogs from high-kill shelters and puts them with loving homes. While we had originally visited the group’s weekly event at a local Petsmart in order to start the process for a chocolate lab named Cocoa, Shelby picked me out, stood on her hind legs, and perched on my arm as if to say “hey there, Steve, I’m the one you want!”
That was just shy of fourteen years ago.
Let’s acknowledge something right out of the gate: working with dates and times can be a slog. Not a year goes by without some app breaking due to Daylight Saving Time or an assistant not realizing that March 31st exists.
For those of us working in PHP—especially more recent versions of the language—dates and times don’t need to be a source of pain. Instead of strtotime() this and date() that, we have functionality baked into PHP that dramatically simplifies the work of parsing, converting, and formatting dates and times.
A major focus of my day job right now is cleaning up the PHP in a decades-old monolith, which includes tests written for two different test runners by hundreds of engineers over the years.
I could write a book on the horrors I’ve seen (and currently have at least half a dozen blog posts in draft state), but I’m not interested in raking anyone over the coals for past engineering decisions—honestly, it’s to be expected with any project this size and age. Instead, I wanted to take a moment to talk about one of the most prevalent oversights made by engineers of all levels: strict equality.
The last few months at work I’ve been deep in a refactoring project, cleaning up over twenty years of technical debt. It’s been a massive undertaking, but it’s rewarding work when I’m finally able to remove code that’s been hanging out well-past its expiration date.
One of the patterns that’s come in extremely handy is the Adapter Pattern, which lets me decouple application code from the underlying libraries that we use. This post will discuss how the Adapter Pattern works (with coffee-themed examples, as I tend to do), then demonstrate how it can help with refactoring.
At last year’s php[tek], one of my biggest “holy cow, why haven’t I been doing this?!” moments came from my friend Andrew Cassell when he explained PHP Value Objects in the context of Domain-Driven Design.
Put simply, a Value Object is an immutable object that encapsulates some data and will always be in a valid state.
