They might however "nod off" in consequence of losing control during risk-taking activities and being subjected to high Gs.

Whether "medical event" was prior to or resulted from risk-taking adventure,

and hence culpability, will await forensics I imagine. If those are possible.

That determination aside however,

risk-taking that puts others at risk (e.g., flying over other people) is morally and in many jurisdictions legally prohibited for obvious reasons.

I'm sorry, I don't get the point. Perhaps I'm missing something.

If I open a single port to my home server, then anybody can send any traffic to my server on that port. The attack surface is exactly the process running on my home server, listening on that port.

If I use the cloudflare tunnel, anybody using my web service connects to some cloudflare server which transparantly forwards, through the tunnel, everything to the process running at home. The attack surface is ... exactly the process running on my home server, receiving everything coming into the tunnel, effectively listening on the port opened on the cloudflare server.

Where is the difference? Any security issue in the process running on my server that can be exploited by sending traffic to it is attackable in either case.

Does cloudflare filter the traffic in any way? How does it know what's good and what's bad traffic?

What's the objection to the name? I don't get it.

> My opinion is, _my unit tests_ are to protect my code against unwanted changes.

This is just about the most bizarre take on unit testing I've seen in my 25-year career.

> If I have to rewrite a method, usually I rewrite all of its unit tests.

If you have to rewrite your tests every time you rewrite a method, you are entirely defeating the point of testing. What value you get from tests that only assert that the current implementation is equal to the current implementation?

The mocking thing actually touches on another point of frustration for me. I think the design of Rails ends up causing people to reach for mocking way too often in order to test things. At a glance I think Brut should avoid a lot of this by having things just be plain old Ruby objects.

I have dealt with countless Rails projects where testing things conventionally was difficult or impossible so mocks/stubs had to be used everywhere (controllers are the worst offenders here). When you start digging in to what's actually being tested, you find that the tests express little more than "this method is written the way it's currently written" rather than actually testing behavior.

Good tests should do three important things: catch bugs early in development, prevent regressions, and allow refactoring. Overly-mocked tests not only end up doing none of these but often actively work against these goals. They can't catch bugs because they reaffirm the current implementation rather than testing behavior. They can't catch regressions because any change to the code necessitates a change to the test. And they actively inhibit refactoring for both of those reasons.

All that is to say that maybe having a less-convenient mocking system is maybe a good thing :)

Also, since you're here, I want to say it also looks like your design encourages avoiding one of my other huge issues with Rails. I hate that ActiveRecord conflates the ORM layer with domain logic. This causes an antipattern where consumers of records (usually controller methods) pierce all the way down into the database layer by using AR methods and attributes directly. While convenient, this makes doing database-layer changes excruciating since your table layout is implicitly depended upon by pieces everywhere throughout the stack.

Better is to do what it looks like you suggest here: there should be an ORM layer that just exposes the database structure, and then you should layer domain objects on top of that which expose higher-level methods for interacting with persisted objects. If you change the database, you only need to change the mid-level layer. None of its consumers need to care that the underlying table layout changed.

From what I can tell so far I am very excited about Brut.

Is this ai generated?

I am only an amateur go developer, but I have some questions:

* what is the sense of this project? NATS is quite the standard for this use case in Go and you can also embed it in a golang binary

* the code seems a bit "strange" to me: why not using existing libraries for structured logging? No unit tests, no usage of interfaces (i.e. persistence can implement writer interface), etc.

I‘ve checked the repo and this looks a litte AI generated to me.