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.

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.

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.

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

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 jobs@deref.io 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.

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.

Competing standard for CLICOLOR and CLICOLOR_FORCE variables that have some support: https://bixense.com/clicolors/

Deref | Software Engineer | Remote USA | Full-Time

Looking for engineers with a passion for Developer Experience.

You'd be working on this thing: https://exo.deref.io/

We're a pre-seed funded startup on a mission to build a better DevEx for DevOps.

Two open engineering roles:

UI Specialist: https://circular-raclette-f11.notion.site/Lead-Frontend-Engi...

Generalist: https://circular-raclette-f11.notion.site/Dev-Tools-Engineer...

Primary tech stack is Go + TypeScript/Svelte.

Contact jobs@deref.io

We're working on something like this at Deref: https://exo.deref.io/ - The version of our Exo tool that is out there now is a local process & docker container orchestrator with log viewer etc. We're working on adding support for a rich set of component types like functions, queues, workflows, cron jobs, etc. Everything would have a nice console GUI, so you don't need to be an expert at infrastructure-as-code, yet you'd get a version-controlled manifest file that you can use for reproducible deployments. We plan to support deployment to your own infrastructure or an eventual PaaS platform.

If folks are interested in working on something like this, my email address is in my profile. Don't hesitate to reach out.

Deref | Software Engineer | Remote USA | Full-Time

Looking for engineers with Cloud experience and a passion for UX/DexEx.

You'd be working on this thing: https://exo.deref.io/

We're a pre-seed funded startup on a mission to help developers build better services.

Two open engineering roles:

UI Specialist: https://circular-raclette-f11.notion.site/Lead-Frontend-Engi...

Generalist: https://circular-raclette-f11.notion.site/Dev-Tools-Engineer...

Primary tech stack is Go + TypeScript/Svelte.

Contact jobs@deref.io

Deref | Software Engineer | Remote USA | Full-Time

Looking for engineers with Cloud experience and a passion for UX/DexEx.

You'd be working on this thing: https://exo.deref.io/

We're a pre-seed funded startup on a mission to help developers build better services.

Competitive salary, generous equity.

Contact jobs@deref.io

Hi there, I'm the lead on this project. We're trying to improve the dev experience for service development. Lots of folks who have workflows on top of docker-compose, but there is still a big gap between what compose can offer and what real projects and organizations need. This release of our tool, exo, adds compose compatibility and provides a nice graphical log viewer, some UX for starting/stopping containers, etc. We've got big plans, but would love to hear from you about what would improve your den env.

Also, if you have compose projects that don't work, please do file an issue on github! Exo is open source: https://github.com/deref/exo - We're aiming for extremely robust compose compatibility, but aren't 100% there yet.

Hi, author here.

My writing backlog includes a post defining what "good" looks like for a web service. I don't think most organizations are doing it well, or have their priorities straight.

Rumor has it that there is a 30+ page checklist if you work at AWS and want to launch a new service. Meanwhile, CloudFormation support still trails most new service launches and remains completely unavailable for many old services. These things suggest strongly that they are coding the area, not the perimeter.

Overmind is a favorite of a friend of mine. Are you a tmux power user? Any particular pros/cons to overmind worth mentioning?

Of course: https://github.com/deref/exo/blob/main/doc/uninstall.md

For what it's worth, the only telemetry right now is occasional polling for new versions (which are not automatically installed) and you can turn this off with a config setting. Also documented in the README.

Hi there, I'm the tech lead for this project.

In the course of working on another project, the team and I were comparing notes with friends our various multi-process dev environment setups. Everything from a bunch of terminal tabs open, to typical Procfile runners, to advanced tmux usage, to systemd, and supervisord, and more.

There are a handful of process supervisors specifically targeting dev out there, but none that met our requirements.

Exo is our first step towards building a robust solution to this problem. Once we started hacking, the ideas started flowing, but we had to draw a cutline somewhere, so this MVP is just a Foreman-style Procfile runner. Next-up is Docker Compose compatibility, but there is so much more beyond that planned too.

If you give it a try and have thoughts, please file an issue or open a discussion at https://github.com/deref/exo - or email me at brandon@deref.io

If you like it, please give us a star :)

Cheers, Brandon

Related: https://www.youtube.com/watch?v=3Ea3pkTCYx4

Key insight can be summarized as "code the perimeter"

Deref | Head of Product | REMOTE | Full Time

Deref is a pre-seed stage funded startup with a globally distributed team.

DevOps is being reborn as Platform Engineering. We empower platform teams to do more with less. Our services provide leverage to improve operational excellence and accelerate developer velocity, even as businesses grow faster than platform teams can keep up supporting the rest of the engineering team.

We're hiring a Head of Product to take the reins of product discovery and drive the go-to-market roadmap.

Job Description: https://www.notion.so/Head-of-Product-cc0f2b9f127a4d4d803d16...

Contact: jobs@deref.io

Experienced something similar to with my previous home's HOA in south Seattle. New chairperson took over the HOA and found out that the rainy day accounts were woefully underfunded and several shared roofs were in need of repairs, so dues had to be increased pretty dramatically.

The frustrating part for me as a homeowner was that dues were assessed based on square footage, but out of 200+ homes, ours was one of the only 15 or so that were fully detached. We had use of a communal driveway we shared with 5 neighbors as well as a small private park 2/3rds of a mile down the road, but other than that, we were fully responsible for all of our unshared infrastructure. If our roof had a problem we had to fix it at our own expense, even though we paid in to the roof repair fund.

There were were many more homes (ie. a city or a country instead of a neighborhood) or if there was a greater variety of homes (ie. a larger percentage of detached homes) or if there was some obvious wealth disparity (ie. our detached home wasn't smaller than many of the attached homes) or some other mitigating factors, I'd have been happy to pay in on the assumption that "what goes around comes around" and "rising tide raises all ships", but in this case, my partner and I felt pretty cheated. That said, we didn't make a stink. We just paid the damn dues (...and then later moved somewhere without an HOA).

if I had a tool that would generate Terraform based on the summary page of an AWS construct

This is definitely something we've considered. Our primary platform over at https://www.deref.io/ (still in closed beta) can export resources to Terraform or Pulumi. Video from a few months ago available here: https://youtu.be/DsZsYs_N4NU – If that's interesting to you, drop us a note at hello@deref.io and we can talk about your needs.

Thanks for the perspective!

I'm most interested in this:

too much power to get not that much utility

Is there something that pains you enough that if you had a fix for it, you'd overlook your security concerns?

It's pretty easy to install from source, if that's your preference. We'll get some build/install instructions in to the readme.

We're in closed beta now and will have more to share publicly soon. Would be happy to chat though, so I'll reach out if you sign up for the beta invite list on our site or shoot a note to hello@deref.io