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.

This is great; very mature organizational thinking.

The request/response optimization discussed in the first half of this post has been explored quite a bit in the context of Object-Oriented Programming and Actors, where the desired feature is called "Promise Pipelining":

http://www.erights.org/elib/distrib/pipeline.html

Outside of the E programming language and in the realm of language-agnostic tooling, you can find promise pipelining in some RPC frameworks, such as Cap'n Proto:

https://capnproto.org/rpc.html

Generally, this work comes from the Object-Capabilities community.

I was also thinking of promise pipelining, but note that the article proposes communicating A -> {B, C} -> D, never directly communicating from A to D. Cap 'n Proto "level 3" nodes could send promises from B and C to D, but that still needs A to talk to D, i.e. A -> {B, C, D}; {B, C} -> D. Same latency / depth of dependency chain, but still more messages - right?

(In return, note that Cap 'n Proto's A -> D message makes it more obvious how A figures out whether the operation succeeded; I'm not quite sure how that works in the proposed diagram. I suppose the proposed system actually puts all messages in a system-wide database, which does solve the problem.)

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

Nice! Looks like most modern list-comprehension syntaxes.

> iteration and value accumulation are orthogonal problems which should be solved by orthogonal constructs

This is also covered to an extent by "Why Functional Programming Matters" in the discussion of laziness: https://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.p...

For a direct comparison of combining this syntax with "accumulation" into a lazy sequence, see Clojure's `for` macro:

https://clojuredocs.org/clojure.core/for

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

Publicly sharing hashes of video segments as they're created, would validate both the existence of, and unaltered nature of the video.

This is one of the few good use cases for a blockchain outside of crypto

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

Very neat way to do this.

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.

SEEKING FREELANCER | REMOTE | Designer

Looking for a UX designer who has exposure to DevOps/Cloud/Programming.

Building numerous new features for https://exo.deref.io and need someone to help wireframe, flesh out the UX, and design high-fidelity screens for implementation.

The ideal candidate for this project is someone who has dabbled in engineering and devops, but is primarily a designer. Also a good fit would be those who have experience designing cloud/devops/eng products in the past.

CSS/HTML implementation skills a big plus, but not strictly required.

Contact [email protected] with a statement of interest, your rates, and a link to your portfolio or other evidence of relevant experience. Thanks!

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

Pretty much every model/resource has a `token` field, so we just call `invoice.token`, which is always a string.