Staying local

Sometimes I don’t feel like going all around the world on the Internet to accomplish something I can do on my local laptop. Somehow it can feel… slow, or wasteful (although it’s rarely either) to send my bits out into the great pandemonium of planetary data centres, only to have them come right back to where they started – while equivalent functionality sits unused on my rarely-breaks-a-sweat computer.

I’ve been playing with Dart and Flutter lately, and wanted a simple way to evaluate basic Dart code – so I recently made a little REPL that’s available in my tmux environment. The left pane is a Vim window with a main() entry point open, which is evaluated in the right pane whenever the file is saved. That’s it!

Uh, wait, you say – couldn’t you just use DartPad?.. Yes! Absolutely. Or for that matter, which is pretty great too. And neither of those options requires any setup or mucking with config files.

But sometimes I’d rather keep it local.

Counting down the time

The Tail End is a popular post on Wait But Why, the charming and eclectic long-form “content website” written by Tim Urban. The post provides a unique view on the time we have left in various contexts, from the number of times we’ll enjoy pizza to the precious hours remaining with aging family. Since reading it years ago, it’s stuck with me – and resonates with many of us that are more and more aware of the vanishing time we have left with those of whom we care the most.

Filip Hráček has created a Flutter Web app called the Human Life Counter, that allows us to enter some morbid-feeling time expectations and see a visual representation of our own remaining weeks. It’s the sort of thing you wish Future You had gone back in time and showed to Past You That Felt Invincible And Immortal (along with explaining the value of savings). 😬

Kirk’s remaining weeks if he ever wants to retire.

TIL: auto-input yes/no/anything to command prompts

Have you ever been running a script or command, and just want to easily pass “yes” to all prompts? It turns out there’s a simple command for that: yes.

Piping yes to a script will provide every script prompt with a y response. In fact, yes can take a single argument, allowing us to customize the text we want returned (eg. yes n will return n to every script prompt). According to the man page, yes was written with a specific use-case in mind:

Screen Shot 2018-08-15 at 1.29.40 PM

My own use-case is much less aggressive: pruning stopped containers.

Screen Shot 2018-08-15 at 1.39.27 PM.png

How Facebook is killing [insert creative income here], and why I give money to Amanda Palmer

It’s a depressing day when people yearn for the old days of website traffic driving ad income, yet… here we are. This article rings true in so many ways – not just for comedy, but any independent creation hoping to leverage the internet for compensation.

On a positive note, I did not come across this article through a Facebook algorithm, but rather my Patreon support for Amanda Palmer. I’ve been paying attention to her for a few years now, believing the way she manages her career to now be the most sustainable model possible for earning a living by independent creation.

I’m not even a big fan of her music – yet here I am happily giving her money on a regular basis. I believe she and other like-minded creators are carving out a blueprint for income generation that will become more popular, if not outright necessary, in the coming years.

If you want to know how anyone producing anything on their own can hope to make a living on the internet outside of the media meat-grinder, follow Amanda Palmer’s lead. Facebook isn’t doing you any concrete good anyways.

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).

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)

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.


Sebastian Markbåge: Minimal API Surface Area

This talk is a detailed explanation of why I spend my time learning core WordPress rather than frameworks – even though I’ve never fully understood why myself. It also explains why Underscores has been so hugely successful, and why I’m finally managing to learn JavaScript by working with React (and having a great time doing it). Highly recommended.

Theming in the Future

This past Thursday, I gave a talk to the Vancouver WordPress Developer Meetup called “Theming in the Future”. We covered the joys and challenges of working with the coming core REST API and the React UI library, all in the context of an Underscores-based starter theme called Tango.

The talk took the form of mostly discussion, code tours, and demos; below are links to the examples, code, tools, and resources that were mentioned or came up in chats afterwards.

One point I should make is that, even with all of this talk of full JS interfaces, build tools, APIs and such, PHP theming is not going anywhere. Thanks to core’s dedication to backwards compatibility, PHP themes will remain strong for a very long time to come, and a theme developer’s current skills will not by any means become obsolete. We’ve simply been given opportunities to expand our thinking of what WordPress themes can be and do, while growing our toolkit to include all the best modern web development has to offer. These are very exciting times for WordPress theme development 🙂

Thanks to everyone who came out for a fun night, with plenty of questions, crystal-ball-gazing, and food for thought. I’m still very new to all of this myself, and the ways forward are nowhere near determined, so please feel free to hit me up in the comments or on Twitter with questions. Talk to you soon!



Tools and Workflow