Social infrastructure services

Submitted by Larry on 17 August 2020 - 4:22pm

In all of the various debates around the systematic assault on the US Postal Service (USPS) of late by the Trump administration, one statement crops up now and again. It takes various forms, but boils down to something like this:

The post office is great and all, but shouldn't it be self-sustaining? Things that aren't self-sustaining in the free market don't last, so if something can't be self-sustaining then it probably should get replaced by something that is (like a private company).

There's a whole lot to unpack here, so I will try to be brief, but knowing me I will fail miserably.

Byte-sized functional programming: Composition over inheritance for functions, too

Submitted by Larry on 15 August 2020 - 10:07am

A popular refrain in object-oriented code is to favor object composition over inheritance. It offers more flexibility, less overhead, and ends up being easier to reason about. The same concept applies to functions, too!

A common pattern is to have a function that does some work and then calls another function, which does some work and calls another function, and so on. The problem is that the first function then cannot be used or tested without the entire chain of other functions it calls. This is the function equivalent of "inheritance."

Instead, we can compose functions, that is, pipe them together. Instead, take the output of the first function and pass it to the second, then take the second's output and pass it to the third, etc. That way, each of the functions can be reused, tested, and understood in isolation, then we can stick them together like LEGO blocks to build whatever series of steps we want.

That is, instead of this:

Byte-sized functional programming: Filter first

Submitted by Larry on 3 August 2020 - 1:47pm

Often when working with a list, we only want to work with a subset of a list that meets some criteria. All non-zero values, for example, or all users that have a given role. The procedural way to do that is to stick an if statement inside a foreach loop:

foreach ($list as $value) {
    If (!meets_criteria($value)) {
        continue;
    }
    // ...
}

That mixes up the filtering with the iteration, though. It also doesn't work if we're using array_map().

Instead, we can make stripping down the list a separate operation called "filter." PHP offers the array_filter() function for that purpose.

Byte-sized functional programming: Mapping out your data

Submitted by Larry on 27 July 2020 - 3:42pm

Procedural code tends to think in terms of writing out steps, and so the usual way to work with a list is to iterate it using a `for` or `foreach` loop.

Functional code tends to think in terms of the relationships and transformations between data, where those relationships and transformations are defined as functions. That means the natural way to work with a list is to define a function that is the relationship between one list and another. The most common way of doing that is with a "map," which in PHP usually means the `array_map()` function.

Byte-sized functional programming: Immutable variables are easier to understand

Submitted by Larry on 21 July 2020 - 7:30am

An immutable variable is one whose value doesn't change after it has been first set. PHP doesn't natively support that, but we can write our classes in such a way to simulate it. For example, rather than this:

class Point
{
   private int $x;
   private int $y;
  
   public function __construct(int $x, int $y)
   {
       $this->x = $x;
       $this->y = $y;
   }
  
   public function moveUp(int $by): void
   {
       $this->y += $by;
   }
}

We can write this:

Advice for new speakers

Submitted by Larry on 18 July 2020 - 5:18pm

Someone messaged me recently to say he had just been selected for his first-ever conference talk, and since the talks of mine he'd seen in the past were so inspiring he wanted to know if I had any advice for new speakers. Since flattery will often get you somewhere, I offered the following advice. I figure it's generic enough that I should share it more widely. :-)

Byte-sized functional programming: Pure functions make testing easy

Submitted by Larry on 14 July 2020 - 9:28am

When testing stateful code, you have to first set up all of the explicit and implicit state that a given piece of code depends on. If the object you're testing has many dependencies that could be complex, or references global variables, or calls many other routines with their own dependencies, you may be looking at a lot of complex setup that makes testing hard to do effectively.

Pure functions greatly reduce that problem.

A pure function is a function that:

  • has no inputs other than those explicitly specified;
  • has no effect on any value other than the value it returns.

That means there is, by definition, only one place to inject dependencies: the call itself. And there's only one effect to validate: the return value of the function. No need to call a function and check what the effect was on some other value or piece of code: by definition, the only effect is the return value.

Byte-sized functional programming: Pure functions encourage small code

Submitted by Larry on 6 July 2020 - 5:13pm

One of the many pieces of advice for a long-term sustainable code base is to keep code small. The larger a code base is, the more effort it takes to understand all the moving parts. Your brain can only keep so much mental model of your code in it at once, and if the code you're looking at is too large then what you can fit in your own "active memory" at once then you will have an increasingly hard time understanding it.

Most useful applications tend to grow larger than what the typical human can fit in their active memory, however, so you need a way to break up your code so you can load a relevant piece into your brain at once to understand and debug it. Usually that takes the form of encapsulation, coupling, cohesion, and other common object-oriented vernacular.

But what about just a pure function?

A pure function is a function that:

A Major Event in PHP ebook now available

Submitted by Larry on 6 July 2020 - 5:12pm

In early 2019, the PHP Framework Interoperability Group (PHP-FIG) released PSR-14, the Event Dispatcher specification. At the time I posted a long series of blog posts detailing PSR-14 in all its glory.

After discussing with a few other FIG folks, I've decided to release that blog series as a small ebook. Mainly that is to provide an easy single-point-of-reference for those who want to really understand PSR-14. Also, it serves as a simple fundraiser.

How political corruption works

Submitted by Larry on 4 July 2020 - 4:31pm

(I originally wrote this with the hopes of getting it published in a more politically-targeted publication, but none of them got back to me. I guess if it's not COVID-related they're not interested. So I'm posting it here instead. Please share far and wide.)

I would like to tell you a story. It is a story about politics. About how politics works, and how it doesn't work. It's a case study in how, across the country, the very nature of our political system undermines democracy and keeps those in power, in power. But it's a story that also reveals the steps that can be taken to help fix it.

It's also, for me, a very personal story.