Live data from Hacker News

Prototool – A Swiss Army Knife for Protocol Buffers

github.com

41–50 of 66 posts

Re: Prototool – A Swiss Army Knife for Protocol Buffers

#41
post #39

Earlier quoted context omitted.

I don't want to deal with that. They are able to create problems artificially just to get power over you (on controversial topics). IMHO people to avoid.

From the position of a contributor, I understand and agree with you. You shouldn't contribute to a project whose terms you do not agree with, and I think that the "CoC" movement helps surface the type of organizational policies that a potential first time contributor would want to know before committing to the project. I am curious to understand how it contributes to your decision not to integrate the tool into your…

I do that for "CoCs" because I find that harmful. It is harmful for everyone and especially for the ones that are claimed to be helped.

My point of view is the one of Morgan Freeman (something like "stop talking about it you make it getting worse").

Re: Prototool – A Swiss Army Knife for Protocol Buffers

#42
post #40

Earlier quoted context omitted.

No: physics, maths, cooking...

Oh please. Things involving more than one human invariably involve politics. Academics are just as susceptible as anything else, probably more so. Cooking, if there is more than one person involved in preparing and eating the food, will involve politics.

No. You're mixing social interactions and politics. Politics is about power (who is the boss).

Re: Prototool – A Swiss Army Knife for Protocol Buffers

#43

In another decade or so the world might replicate half of the very nice internal tools Google has. Suggestion for a project: make a tool that, given a proto description and a file that contains concatenated proto messages stored as binary strings (sort of like RecordIO at Google) lets you run simple SQL queries on the data and extract a subset of the fields from messages matching a predicate, and maybe even do simple…

While not exactly what you are describing, I work for another company that uses protobufs extensively and we have some nice internal tools similar to what you describe. I really wish we could open source those too. I feel like the wheel is reinvented a lot with protobuf in several of the large companies who use it.

Re: Prototool – A Swiss Army Knife for Protocol Buffers

#44
post #40

Earlier quoted context omitted.

Oh please. Things involving more than one human invariably involve politics. Academics are just as susceptible as anything else, probably more so. Cooking, if there is more than one person involved in preparing and eating the food, will involve politics.

No. You're mixing social interactions and politics. Politics is about power (who is the boss).

Alright, I suppose that's one way to frame it.

Why is a document describing the standards for social interaction that contributors pledge to live up to bad? Open source has been and continues to be rife with social interactions that are bad for individual contributors and for the project as a whole. CoCs strive to head that off and document a process for when people seem to violate their pledge.

Re: Prototool – A Swiss Army Knife for Protocol Buffers

#45
post #44

Earlier quoted context omitted.

No. You're mixing social interactions and politics. Politics is about power (who is the boss).

Alright, I suppose that's one way to frame it. Why is a document describing the standards for social interaction that contributors pledge to live up to bad? Open source has been and continues to be rife with social interactions that are bad for individual contributors and for the project as a whole. CoCs strive to head that off and document a process for when people seem to violate their pledge.

You should read it. It includes words that are politically connoted. Those words can easily be leveraged by people who are in that domain.

It's not about common sense. You don't need to tell people to be polite (and you shouldn't). If someone isn't everybody will notice it.

Re: Prototool – A Swiss Army Knife for Protocol Buffers

#47
post #5

In another decade or so the world might replicate half of the very nice internal tools Google has. Suggestion for a project: make a tool that, given a proto description and a file that contains concatenated proto messages stored as binary strings (sort of like RecordIO at Google) lets you run simple SQL queries on the data and extract a subset of the fields from messages matching a predicate, and maybe even do simple…

Other tools and features that don't exist outside: - a tee loadbalancer for gRPC, forwarding the same requests to both A and B backend pools, but only returning results from A. I don't think Envoy has this, but it should. - load balancing dashboards showing traffic between frontends and backends - load balancer support for dynamic sharding - gnubbyd under ChromeOS: https://groups.google.com/a/chromium.org/forum/m/#!m…

> a tee loadbalancer for gRPC, forwarding the same requests to both A and B backend pools, but only returning results from A

I would call that a "(live) traffic replayer" rather than a load balancer. "load balance" implies to me that the upstream traffic is divvied up among the downstream sinks, not that the upstream traffic gets copied to multiple downstreams.

Re: Prototool – A Swiss Army Knife for Protocol Buffers

#49
post #44

Earlier quoted context omitted.

Alright, I suppose that's one way to frame it. Why is a document describing the standards for social interaction that contributors pledge to live up to bad? Open source has been and continues to be rife with social interactions that are bad for individual contributors and for the project as a whole. CoCs strive to head that off and document a process for when people seem to violate their pledge.

You should read it. It includes words that are politically connoted. Those words can easily be leveraged by people who are in that domain. It's not about common sense. You don't need to tell people to be polite (and you shouldn't). If someone isn't everybody will notice it.

> You don't need to tell people to be polite (and you shouldn't). If someone isn't everybody will notice it.

Unless it's done in private. If someone is a jerk to me in private (over email or Slack or whatever), what do I do?

If I'm contributing to a project without a CoC and someone is a jerk to me, I'm much more likely to just contribute to a different project, or start my own fork, or just stop contributing to open source entirely.

Projects with CoCs have a stated procedure in place for dealing with abusive contributors. That's what the whole thing is about. Of course you shouldn't have to tell people to be polite, but that's not how the real world works. There are jerks everywhere, and more often than not they're going to express that in private.

Re: Prototool – A Swiss Army Knife for Protocol Buffers

#50
post #5

Earlier quoted context omitted.

Other tools and features that don't exist outside: - a tee loadbalancer for gRPC, forwarding the same requests to both A and B backend pools, but only returning results from A. I don't think Envoy has this, but it should. - load balancing dashboards showing traffic between frontends and backends - load balancer support for dynamic sharding - gnubbyd under ChromeOS: https://groups.google.com/a/chromium.org/forum/m/#!m…

> a tee loadbalancer for gRPC, forwarding the same requests to both A and B backend pools, but only returning results from A I would call that a "(live) traffic replayer" rather than a load balancer. "load balance" implies to me that the upstream traffic is divvied up among the downstream sinks, not that the upstream traffic gets copied to multiple downstreams.

It's a load balancer, because, typically, there is more traffic than a single server can handle. That's why I mention pools: it sends traffic to one of {A1, A2, ...} and one of {B1, B2, ...}. Using your terminology, that instance of the load balancer will take the upstream traffic and divvy it up twice, among two separate groups of downstream pools. A load balancing tee proxy/LB is also useful where B is a new implementation that is supposed to handle more traffic. You could e.g. bring up 10 A replicas and 5 B replicas and compare their performance metrics. That setup is closer to reality than one instance of A and one of B (if you want to test soft stickiness, for example).

Anything at Google that does not support load balancing is doomed to melt fairly quickly.

Post reply on HN