programming

OBS Task List Overlay for livestream TODO / Checklist

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:

NASASpaceflight Live stream overlay task list for Flight Test

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.

Did breaking backwards compatibility kill Drupal?

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:

Usage Statistics for Drupal Core from 2013 to 2020

Meetings and Introverts

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

From the Server Check.in Blog: Keeping a Lid on Technical Debt

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.

The Drupal Way™

The Drupal Way

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!

Why does Drupal have So Many Database Tables?

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.

Time Refines Code

Smooth stone

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.

The Story of the PING Program

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.

Don't Wait, Delegate! Proper use of threading and queueing

There are hundreds of ways you can improve your app or website's performance, but few have the potential to improve your app or website's responsiveness as much as queueing or using background processes. There are so many complex operations that can be improved by looking at them in a new way. For example:

Not-so-Instant Oil Change

I like changing the oil in my car, but it often takes a bit of time (definitely not an 'instant!'), and involves the following:

  • Drive to auto parts store, pick up oil and oil wrench, and drive back (30 minutes).
  • Jack up front of car on stands (5 minutes).
  • Drain oil into oil pan, remove old filter, prep new filter (5 minutes).
  • Install new filter, refill oil reservoir (2 minutes).
  • Remove jack stands, clean up mess (5 minutes).
  • Drive to oil disposal center with old oil in pan, and drive back (20 minutes).

Total elapsed time: Over 1 hour! Maybe it's worth spending a few extra bucks on an 'instant' oil change to get back 45 minutes of my life.

Dreaming in Drupal

How do you know you've been thinking about work too much? When your wife relates a conversation she had with you in the morning, and you don't remember a word, but can definitely see how what you said relates to what you're working on:

Saith my wife: "Jeff, how do you set your alarm?"

My (groggy) reply: "Hit field, the arrow, then default."

Now, this could possibly have something to do with alarm clocks. There are often arrows on them, and you hit buttons... but I know better. I was referring to:

$this->addFieldMapping('field', 'source')->defaultValue(0);

...which I have probably typed about 100 times in the past week, and maybe 20 or so last night during a late-night debugging session with the Migration process of flockNote v2 to v3 (from a proprietary WAMP-based system to a new Drupal 7 LAMP-based system).