paffdragon (u/paffdragon)

paffdragon commented on Waymo granted permit to begin testing in New York City cnbc.com/2025/08/22/waymo... · Posted by u/achristmascarl

whyenot · 2 days ago

Yes it could potentially be very dystopian for human drivers. That doesn't mean it won't happen. Police departments could make a lot of extra money from the additional traffic tickets; there is a financial incentive for them to do this.

paffdragon · a day ago

Making money from tickets is supporting the wrong behavior of trying to find excuses to ticket you for anything to get extra money - this is often leading to cops looking for cheap ways to get the extra cash where they can get it easily, instead of doing more important work where their chance to ticket you is lower even if more important for safety.

paffdragon commented on Waymo granted permit to begin testing in New York City cnbc.com/2025/08/22/waymo... · Posted by u/achristmascarl

whyenot · 2 days ago

Each Waymo is equipped with multiple cameras (potentially LPR), LIDAR, etc. The car knows when the vehicles around it are breaking traffic laws and can provide photographic/video evidence of it. Imagine if Waymo cars started reporting violators to the police, and if the police started accepting those reports. Someday they might.

paffdragon · 2 days ago

Isn't it too dystopian to have cars follow you around and report you to authorities? I can easily imagine some bad scenarios.

paffdragon commented on End well, this won't: UK commissioner suggests govt stops kids from using VPNs theregister.com/2025/08/1... · Posted by u/rntn

GeoAtreides · 5 days ago

sure they can, the gov only has to ban payments processing from uk clients

paffdragon · 5 days ago

some providers accept crypto or even cash in an envelope

paffdragon commented on OpenMower – An open source lawn mower github.com/ClemensElflein... · Posted by u/rickcarlino

paffdragon · 5 days ago

When I read the title I remembered how people in the 90s at my place built their lawn mowers. It was a new thing. My father welded the frame from scrap metal with the motor from a washing machine and some tiny wheels from an old baby stroller lol. It was kind of open source, many people copied or he helped build one. Haha, served us surprisingly well for a time :)

paffdragon commented on VictoriaLogs Practical Ingestion Guide for Message, Time and Streams victoriametrics.com/blog/... · Posted by u/func25

paffdragon · 7 days ago

I use it in docker on a NAS - VictoriaMetrics, VictoriaLogs, Grafana - low resource usage, fast, so far zero issues.

paffdragon commented on Dev Compass – Programming Philosophy Quiz treeform.github.io/devcom... · Posted by u/todsacerdoti

paffdragon · 7 days ago

This isn't a good quiz. An example question (and there are many similar ones):

> When refactoring code, I prioritize:

> - Reducing complexity and coupling

> - Improving readability and maintainability

> - Optimizing performance and resource usage

> - Extracting reusable abstractions

Each refactoring has some goal, some driver behind it. It could be slow performance, unmaintenable mess, high coupling, too much duplication etc... Choosing a single answers makes no sense from a programming point of view. And this is the case most questions I have seen so far on the site.

EDIT: After finishing and seeing, I think I understand it a little better why was it structured like this. If you are open to do things differently, your answers probably won't weigh in any one direction in aggregate. But if you have certain biases, you might be leaning towards choosing similar answers that shows up in the end.

paffdragon · 7 days ago

I finished it anyway:

Your Programming Philosophy

You value clarity and directness in code. You prefer explicit, step-by-step solutions that are easy to understand and debug, even if they require more lines of code. Abstract ↔ Concrete: 0 Neutral Human ↔ Computer Friendly: +6 Human-Friendly

The compass is almost in the middle, just a little up from center towards human friendly. That's fine, since most code you write is for other humans to read, the compiler is writing for the machine, only in critical perf sensitive paths you write for computer-first... The rest was mostly neutral, because what I wrote in the parent, it depends on the situation and it can go either way depending on the project.

paffdragon commented on Dev Compass – Programming Philosophy Quiz treeform.github.io/devcom... · Posted by u/todsacerdoti

paffdragon · 7 days ago

This isn't a good quiz. An example question (and there are many similar ones):

> When refactoring code, I prioritize:

> - Reducing complexity and coupling

> - Improving readability and maintainability

> - Optimizing performance and resource usage

> - Extracting reusable abstractions

Each refactoring has some goal, some driver behind it. It could be slow performance, unmaintenable mess, high coupling, too much duplication etc... Choosing a single answers makes no sense from a programming point of view. And this is the case most questions I have seen so far on the site.

EDIT: After finishing and seeing, I think I understand it a little better why was it structured like this. If you are open to do things differently, your answers probably won't weigh in any one direction in aggregate. But if you have certain biases, you might be leaning towards choosing similar answers that shows up in the end.

paffdragon commented on Good system design seangoedecke.com/good-sys... · Posted by u/dondraper36

hamandcheese · 8 days ago

> In fact, it will add more constraints to your design, because now you have different consumers and potentially writers all competing for the same resource with potentially different access patterns. Plus the maintenance overhead that migrations of such shared tables come with. And eventually you might have data in this table that are only needed for some of the services, so you now need to implement views and access controls at the DB level.

PostgreSQL, to name one example, can handle every one of these challenges.

paffdragon · 8 days ago

It's not that it is not possible, but whether it's a good idea.

The usual problem is that some team exposes one of their internal tables and they don't have control over what type of queries are run against it that could impact their service when the access patterns differ. Or when the external team is asking for extra fields that do not make sense for the owning team's model. Or adding some externally sourced information. Or the team moving from PostgreSQL to S3 or DynamoDB. And this is not an exhaustive list. An API layer is more flexible and can remain stable over a longer time than exposing internal implementation depending on a particular technology implemented in a particular way at the time they agreed on sharing.

This is, of course, not a concern inside the same team or very closely working teams. They can handle the necessary coordination. So, there are always exceptions and simple use cases where DB access works just fine. Especially, if you don't already have an API, which could be a bigger investment to set up for something simple if it's not even known yet the idea will work etc.

paffdragon commented on Good system design seangoedecke.com/good-sys... · Posted by u/dondraper36

zbentley · 8 days ago

I think most of the discussion in this thread assumes that “customers” of the interface are other groups in the same organization using the database for a shared overarching business/goal, not external end user customers.

For external end users, absolutely provide an API, no argument here. The internal service interactions behind that API are a less simple answer, though.

paffdragon · 8 days ago

It's definitely worse for external customers, of course. But it's still not that easy even for internal customers. The main problem is that usually the tables exposed are not meant to be public interfaces, so the team takes on an external dependency to their internal schema. And that other team could have completely different goals and priorities, speed and size, management and end users with different requirements. At some point the other team might start to ask the first team for adding some innocent looking fields to their internal table for them. Also first team might need to make changes to support their own service that might not be compatible with the other team. The other team making queries that are not in control of the team owning the DB, which could impact performance. If possible, it is better to agree on an API and avoid depending on internal implementations directly even for internal customers. There are always some exceptions, e.g. very close or subteams under same management and same customers could be fine. Or if the table in question was explicitly designed as a public interface, it is rare, but possible.

paffdragon commented on Good system design seangoedecke.com/good-sys... · Posted by u/dondraper36

wahnfrieden · 8 days ago

A reused code library for DB use is an alternative there

paffdragon · 8 days ago

That moves your API layer to the client library you need to distribute and build for your customers in programming languages they support. There are some cases where a thick client makes sense, but usually easier to do it server side and let customers consume the API from their env, it is easier to patch the server than to ship library updates to all users.