brandonbloom

If you watched the video closely, you'll have noticed that this design parameterizes the code by an `io` interface, which enables pluggable implementations. Correctly written code in this style can work transparently with evented or threaded runtimes.

There is a huge spectrum from no proposal at all to a magic bullet on a silver platter. To some extent, the default and implicit proposal is: "You should something about it!". Which is markedly worse than "_We_ should do something about it.", and worse still than "Let's do something about it, here's how I can help..."

Some other useful intermediate proposals include:

- "Allow me and my team time to investigate a solution."

- "I've organized my complaints into requirements for a solution. Please identify an expert to solve the problem."

- "I've socialized these problems with ${people}, I recommend you speak to ${person} about ${topic} for next steps."

Having said that, I agree that complaints can be counted as "votes" for which problems to solve in the future. The problem is that they are not one complaint = one vote. At the very least, the complainer's role and responsibilities need to be accounted for within the scope of the larger organizational goals.

> that still needs A to talk to D

That should not be the case with promise pipelining. The "Mobile Almost-Code" section of the E page explains this. You mentioned "continuation passing style", which is effectively what promise pipelining does: For the constrained class of continuations that can be serialized as a dataflow graph, pass those along with the message.

Importantly, the system wide constraint is willing participation from each actor, not a shared database. Instead of each actor needing to know how to interact with the shared database, each actor needs to be willing and able to execute these passed continuations.

(disclaimer: I was a software engineer at Axon)

It’s also worth noting that recording can be activated wirelessly by various triggers. The most obvious and common one being that a nearby officer’s camera was activated (either by physically pressing the button or via a chain reaction of wireless activations).

Depending on the available hardware/accessories & configuration, other sources of activation can include unholstering a weapon, aiming or discharging a taser, by computer aided dispatch, unlocking a weapon in the vehicle, activating the light bar, high vehicle speed, running, falling, crashing, and more.

In my opinion, if multiple officers are on the scene at least one axon recording device each: there is either video evidence or willful suppression of evidence. It’s that simple.

It's not exactly what you want, but one mitigating factor is if you're using FaceID, TouchID, or Apple Watch -- Those things will dramatically reduce the frequency that you're prompted for your password.

My preferred idiom is essentially the command pattern:

    type Frob struct {
      SomeFlag bool
      AnotherArg string
    }

    func (args Frob) Do() FrobResult {
      // ...
    }

    // Later:

    res := Frob{SomeFlag: true}.Do()

This saves the stuttering of `Frob(FrobOptions{`, should have identical performance to that, with nicer syntax, and has a smooth upgrade path for all the sorts of things folks do with the command pattern (such as logging, dynamic dispatch, delayed execution, scripting, etc).

In addition to what others have already said, my own random sampling now shows quite a high false positive rate.

This page is great!

If any Pharo folks are reading this, here's a small website feature request: Let me click on the images of this page to get full-resolution, un-cropped versions.

> the fact that you would often find `merchant`, `account`, `invoice`, etc used as method parameters that represented the _ID_ of the resource rather than the resource itself

I've encountered a few Rails projects in the wild that do this. One solution is to make liberal use of the `to_param` method. This method converts objects to strings that are intended for use in URLs. Of particular note, it's the identity function for strings and numbers, but returns `.id.to_s` for ActiveRecord models. Using this within definitions makes your function polymorphic for whether it accepts a model or an id.

If you do this widely, would probably be best to monkey-patch in your own `to_id` method.

> Internet doesn't help.

Just ask anyone who has moved to Seattle, but has conservative family back in their home state. Folks believe we live in an anarchist hellscape. Myself and several friends have had the experience of being called liars by family members who trust Fox News over the word of their blood relatives. It's absolutely maddening.