A foreign key constraint is defined by Wikipedia as follows…
A field (or collection of fields) in one table that uniquely identifies a row of another table or the same table.
Sounds pretty technical, right? Frequently, a developer uses his or her judgement when planning the architecture of some feature to decide when a foreign key is appropriate. However, I had an experience today where I learned that often, foreign key constraint enforcement is a business decision rather than a technical one.
How should I log a PHP array?
If you work as a PHP developer this is probably a question you’ve asked yourself before. There are quite a few guides you’ll find online in regards to this subject.
print_rto gracefully debug PHP
Typically, they point to PHP’s
Unfortunately, they’re wrong
PSA: print_r() for logs sucks...— Max Chadwick (@maxpchadwick) November 30, 2016
So why, exactly, does
print_r suck for logging? Allow me to elaborate.
Recently, I caught wind of an issue which was reported by the client as follows…
Customers are getting error screens stating that their request was blocked.
At first glance, it smelled like an issue at the WAF (web application firewall).
A quick call with our hosting provider later, we confirmed that requests were, indeed, violating the WAF’s “max header size” policy. Let’s take a look at the what and the why.
The plugin was spurred by my own contemplation about removing the
/blog prefix from the URLs on this blog, an action which, at the time of writing this, I still haven’t taken. If you just up and change URLs, you’ll wind up with a bunch of backlinks that 404.
jekyll-redirect-from can help with creating redirects, however it requires updating the front matter on all existing posts with a
redirect_from element referencing the old URL. Doing this manually is a lot of work, and error prone. So
jekyll-migrate-permalink was born as an attempt to make this process less painful.
While Ruby isn’t my most comfortable language, I decided to build it as a custom command Jekyll plugin (rather than e.g. writing in PHP, which I work with every day). The benefit of writing the tool as a Jekyll plugin is that it allows access to the same primitives Jekyll uses when it compiles a site.
In the process I hit quite a few stumbling blocks. While other types of plugins just allow you to drop an
.rb file into a
_plugins folder in the root of the site, with commands, your plugin needs to be turned into a Gem. Maybe I just don’t know the right terms to Google, but I had a lot of trouble finding resources to help me through the process. Now that I’ve released the plugin, I decided to publish a guide for creating a simple custom command Jekyll plugin, putting everything I learned into one place.
After reading through the beginning of Andrew Blum’s, Tubes last night, I decided to spend some time today playing with
traceroute. I was initially exposed to the tool via Pingdom’s root cause analysis feature, which captures a
traceroute when it detects a downtime incident for diagnostic purposes. In the past, I’ve always been a bit confused about how to actually interpret the
traceroute results. But, as of today, I feel pretty good about my understanding. In this post, I’ll share what I’ve learned for anyone else struggling to make sense of
The majority of what I do in my day job involves maintaining inherited software. As a result, I spend a lot of time debugging. If you program for a living, there’s a pretty high chance you’re in the same camp.
To get to the bottom of some of the nastiest issues, one practice that has, time and time again, proven itself invaluable is keeping detailed notes throughout a debugging session. In this post, I’ll explain to you how this has helped me, and then offer some note-keeping tips.