programming

IBM is buying HashiCorp for $6.4 billion.

That's four months after HashiCorp rugpulled their entire development community and ditched open source for the 'Business Source License.'

As someone on Hacker News pointed out so eloquently:

IBM is like a juicer that takes all the delicious flavor out of a fruit

skywhopper replied:

HashiCorp has done a good job of pre-draining any flavor it once had.

Some people wonder if HashiCorp's decision to drop open source was because they wanted to juice the books for a higher price. I mean, six billion dollars? And they're not even a pointless AI company!

Yesterday, in tandem with Raspberry Pi's announcement of their new $12 Debug Probe, I received one in the mail (pictured above).

The Debug Probe is powered by an RP2040, and lets you connect from USB to UART (serial) or SWD (Serial Wire Debug), perfect for debugging most embedded devices.

UART is useful to connect to a device's console when you don't have a display or other means of controlling it, and you can find UART/serial/console ports on almost any device with a processor or microcontroller.

Today I needed to play back an MP3 or WAV file through a USB audio device on a Raspberry Pi, in a Python script. "Should be easy!" I thought!

Well, a couple hours later I decided to write this blog post to document the easiest way to do it, since I had to take quite a journey to get to the point where sound actually plays through the USB audio output.

The problem is most guides, like this simple one from Raspberry Pi's project site, assume two things:

For a few of my task-oriented livestreams, I wanted to be able to have an easy-to-follow list of tasks present in an OBS scene, with an indication of which task was currently in-progress.

I had seen a similar overlay on NASASpaceflight's livestreams (example), and liked the simplicity:

I started searching for an OBS plugin I could use to replicate that overlay, but was coming up with nothing. There was some plugin that seemed like it fit the bill, but it had been abandoned a while back. Most of the other overlays were a lot more specific to gaming, had few options for customization, or only worked with services other than OBS.

First of all, Drupal is not dead. But I would argue it's not in healthy place relative to competing projects as it was in its heyday, in the early 2010s.

In this blog post, I will explore the problem the Drupal community finds itself in five years after a major release that broke backwards compatibility in almost every subsystem, forcing a laborious upgrade process and process shift that left many users in the dust.

I've written about this in the past, most famously in my post Drupal 8 successes and failures. I'm not going to rehash the details from that post, but I did want to focus on what I think is the primary reason for this graph's downward trajectory since 2016:

Erik Dietrich's blog, Daedtech, contains a lot of great posts concerning programming and workplace dynamics. In today's post, Meetings and Introverts: Strangers in Strange Lands Erik writes about the vexing relationship between introverted people and typical meetings. In a prior post, he wrote about the general problem of social situations and introverts:

Social situations are exhausting for me because of their inherent unpredictability as compared to something like the feedback loop of a program that I’m writing (or even the easily curated, asynchronous interaction of a social media vehicle like Twitter).

I recently wrote a post on the Server Check.in blog titled Improving architecture and adding features by containing technical debt. The post shows how the server checking architecture on Server Check.in was improved so it will expand horizontally and scale with new clients over time, and the main theme of that post was how managing technical debt (keeping it low for a small development team) has helped make sure new features and architecture improvements work reliably and simply.

The two main takeaways in the article are:

• Simplicity and stability trumps features.
• Get the architecture right, or die slowly.

I hope you can take the time to read the whole post, and also this excellent explanation of technical debt by Martin Fowler.

I've worked with a wide variety of developers, designers, content managers, and the other Drupal users in the past few years, and I'm pretty sure I have a handle on most of the reasons people think Drupal is a horrible platform. But before I get to that, I have to set up the rest of this post with the following quote:

There are not a hundred people in America who hate the Catholic Church. There are millions of people who hate what they wrongly believe to be the Catholic Church — which is, of course, quite a different thing.

Forgive me for diverging slightly into my faith, but this quote is from the late Fulton J. Sheen, and is in reference to the fact that so many people pour hatred on the Catholic Church not because of what the Church actually teaches, but because of what they think the Catholic Church teaches. Once someone comes to understand the actual teaching, they are free to agree or disagree with it—but there are comparatively few people who disagree with teachings they actually understand.

Similarly, the problems most people have with Drupal—and with systems like it—are problems not with Drupal, but with their perception of Drupal.

Java Jane: One-off vs. Flexible Design

A Java developer (let's call her Jane) is used to creating a bunch of base object classes and a schema for a database by hand, then deploying an application and managing the database through her own wrapper code. Jane is assigned to a Drupal project, takes one look at the database, and decides that no sane person would ever design a schema with hundreds of tables named field_data_* and field_revision_* for every single data point in the application!

In reality, Drupal is doing this because The Drupal Way dictates that things like field data should be: flexible (able to be used by different kinds of entities (content)), able to be translated, able to be revised with a trackable history, and able to be stored in different storage backends (e.g. MySQL, MariaDB, MongoDB, SQLite, etc.). If the fields were all stored in a per-entity table as separate columns, these different traits would be much more difficult to implement.

Thus, The Drupal Way is actually quite beneficial—if you want a flexible content management system.

I think a lot of developers hate Drupal because they know they could build a more efficient web application that only has the minimal required features they need by simply writing everything from scratch (or using a barebones framework). But what about the next 72 times you have to build the exact same thing, except slightly different each time, with a feature that's different here, translation abilities there, integration with Active Directory for user login here, integration with a dozen APIs there, etc.?

There's a maxim that goes something like: Every seasoned web developer started with plain HTML and CSS, or some hosted platform, then discovered a dynamic scripting language and built his own CMS-like system. Then, after building the CMS into a small system like many others but hopelessly insecure and unmaintainable, the developer realized that thousands of other people went through the same progression and ultimately worked together on systems like Drupal. Then said developer starts using Drupal, and the rest is history.

I know you could build a small system that beats the pants off Drupal performance-wise, and handles the three features you need done now. But why spend hours on a login form (that probably has security holes), session handling (ditto), password storage (ditto) forms in general (ditto), content CRUD interfaces, a translation system, a theme layer, etc., when you can have that out of the box, and just spend a little time making it look and behave like you want it? The shoulders of giants and all that...

.Net Neil: Letting Contrib/Bespoke Code Let You Down

A .Net developer (lets call him Neil) joins a Drupal project team after having worked on a small custom .Net application for a few years. Not only does he not know PHP (so he's learning by seeing the code already in use), he is also used to a tightly-controlled application code structure, which he knows and owns end-to-end.

Legacy code—warts and all—isn't such a bad thing.

If it's built well, and maintained well, it probably takes care of the hundreds/thousands of edge cases with which your beautifully-rewritten new codebase doesn't yet cope.

Unless it's not well-documented (or self-documented), or incompatible with modern systems, it's often a better idea to refactor and clean up old code than to scrap a system entirely and rewrite from scratch.

Image from Thinking Through.

I love finding little gems like this: The Story of the PING Program.

The best ping story I've ever heard was told to me at a USENIX conference, where a network administrator with an intermittent Ethernet had linked the ping program to his vocoder program, in essence writing:

ping goodhost | sed -e 's/.*/ping/' | vocoder

He wired the vocoder's output into his office stereo and turned up the volume as loud as he could stand. The computer sat there shouting "Ping, ping, ping..." once a second, and he wandered through the building wiggling Ethernet connectors until the sound stopped. And that's how he found the intermittent failure.