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.

Striving for boring software development

For a few years now, I’ve used the word “boring” as a positive yardstick for my own software development: is this code boring? Boring, meaning, does it do what it needs to do, in a predictable manner, in a way that’s easy to understand for others?

Today, I came across a post about “boring code” on Very Good Ventures’ blog:

Having a codebase that is predictable, easy to navigate, well tested and properly automated makes it boring. But pleasantly boring!

Jorge Coca, Very Good Ventures

“Boring” can be applied to the developer experience of a codebase too. At one point, I was part of a small team responsible for upgrading and maintaining a couple of external open-source plugins on; our internal mandate was to make the regular upgrades as “boring and uneventful” as possible.

I hope the software development industry continues to shift in this direction. Users are no longer impressed by new features and rapid growth; it’s been twenty-plus years that we’ve all been using apps of various sorts, and struggling to get things done while companies constantly shift the sands of user experience under us. Moving forward into consumer applications’ “mature” years, the companies that grow and thrive will be those that produce intuitive and solid application experiences over time – through the cultivation of unsurprising, stable, and boring codebases.

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

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