Installing Xdebug on macOS High Sierra

With a new work computer (my four-year anniversary gift from Automattic – come work with us!), I’ve been lazy lately, falling into old error_log() habits since I didn’t have Xdebug set up yet. I also upgraded to High Sierra yesterday, so I thought this would be as good a time as ever to get Xdebug going again properly.

High Sierra comes with PHP 7.1 pre-installed:

and, it turns out, an Xdebug extension is ready to be activated from /usr/lib/php/extensions/no-debug-non-zts-20160303/. However, upon adding it to a new php.ini, I hit this problem:

It seems the included XDebug module is somehow invalid, inaccessible, or incompatible. So, I backed out my changes to php.ini, ran php -i and used the XDebug installation wizard to see what it would suggest.

A quick which phpize let me know that I had it, so I started following the instructions to compile a new Xdebug extension. My first issue seemed to be a missing autoconf, so I installed that with brew install autoconf. That still left me with this output:

Hm, no good. Following the FAQ implied I had bigger problems with missing PEAR and PECL binaries, and quick searches to see what was involved to get them going were not encouraging. So I tried a different tack, searching on the missing files from the grep output, and hit on this Stack Overflow article. Running xcode-select --install got me back on track with the expected phpize output:

./configure and make left me with a fresh extension to work with.

I started going about adding my extension to the same location as the pre-installed one, but ran into what seemed like odd permission problems that sudo couldn’t fix:

I went back to the SO article where someone had succeeded, and noticed this line: “However macOS System Integrity Protection (SIP) will prevent you from overwriting the under /usr/lib/php/extensions/.” So instead, I created a new directory elsewhere, hooked it all up again in php.ini, and finally got the confirmation I was wanting:

Now to see how I like VS Code debugging compared to vdebug (after a few quick minutes, I think I’ll like it a lot).

Programmers don’t need to be “smart”

I recently overheard someone say that to be a programmer, “you have to be smart”. Putting aside the debate of what it means to “be smart”, I can say with absolute confidence, that this is not the case. A good programmer/developer/webby person will typically flourish with four traits (of which “smart” is not one).

  • an interest in languages or math
  • enjoys problem-solving
  • learns well on their own
  • works well on their own

While these are the four traits that have allowed me to earn a rewarding living as a developer, I’d say 1, 3, and 4 are even optional depending on your work environment.

The best programmers I know are the best because of personalities and traits that match well with the industry, not anything related to IQ. And like most work, human skills are the top of the requirements list to be successful and get things done.

Create React App and MVPs

create-react-app is a great little tool by Facebook that allows the creation of React apps with a single command. It’s extremely simple and very effective: in just one week of work, the authors removed a huge boat anchor to React productivity, being the initial setup of a diverse and ever-changing pile of development tools. I also love how a simple eject command allows the developer to continue down their own path of tool customization without any sort of “lock-in”. It has nowhere near the power of a tool like Ember CLI, but it isn’t trying to at this point; while usable right away, there’s still plenty of room to grow and experiment with improvements in the future.

It immediately reminded me of what I call “the skateboard diagram” by Henrik Kniberg. Rather than building the “complete” version of a product first, build the most basic version that allows you to gather feedback, then improve in further iterations. The end result is a product that’s more stable, available sooner, and solves real problems more so than the traditional method of “build it then ship it” development.

(Photo by Salvio Bhering via Pexels)

TIL: Node app deployment with SSL

I thought SSL certificates with a DigitalOcean VPS were easy; then today I learned to deploy a Node app with Now by Zeit.

Following their basic tutorial, I deployed an example app in seconds. Then after creating a CNAME record for a subdomain, I linked the two together, and had my subdomain live with a valid Let’s Encrypt certificate installed and ready.

Screen Shot 2016-06-25 at 2.05.08 PM.png

Everything about working with Now is very refined and the essence of simplicity – from their CLI, to their password-less logins and modern, minimalist account interface. It feels light-years ahead of any other hosting and deployment tooling I’ve played with. (Note that mapping custom domains is part of their Premium plan, but they also provide a free OSS Plan that allows more human-readable URLs than those generated by default.)

TIL: HTTPS sites are not so hard any more.

Like many, I was curious to see how the Let’s Encrypt project would roll out in the real world. I remember looking at documentation for setting it up when it first came out, and quickly moved on – it seemed complicated and laborious (still, pretty great for a free SSL cert).

Now that it’s been around for a while ( custom domains use Let’s Encrypt certs), I thought I’d check again how difficult it would be to throw it on a random domain of mine. I reactivated my DigitalOcean account, spun up a VPS, did some basic setup, and nabbed a new domain (a 6-letter domain, $8 for 5 years, wut) for fun. After waiting overnight for DNS propagation, I banged through three quick tutorials for Nginx, PHP7, and Let’s Encrypt – and had my cert up and running. Not a bad server setup for ~$5 a month and next to no effort.

(Edit, September 2, 2016: “my cert up and running” link is dead as I’ve deactivated my DigitalOcean account; turns out I only need ZEIT now.)

A tale of two developers

At WordCamp Montreal 2014, I gave a talk on fears. In it, I told of a story from the Drupal community, that compares two approaches of open-source contribution: collaborative and isolated. I was unable to find it at the time to properly credit it, but my coworker Kathryn Presner just happened to mention it today: it’s by Angie Byron, and can be found on her blog: Diaries of a Core Maintainer #6: A tale of two developers.