Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
kiitos
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
8 ms
·
61.
▲
by
kiitos
1y ago
i think you would benefit from some time in an organization that was not shitty
62.
▲
by
kiitos
1y ago
more or less the entire point of code review is to ensure that the reviewer fully understands the code that they review i know that lots of orgs don't do it this way, but it's really important to make this point very clear: those
63.
▲
by
kiitos
1y ago
stacked PRs are wildly reviewer-hostile, please do not do them
64.
▲
by
kiitos
1y ago
the entire repo lives only on github as well, there is no meaningful difference between git commits and PR comments in a github-hosted repo
65.
▲
by
kiitos
1y ago
yeah, for sure -- avoid stacking changes in the first place! the purpose of PRs and code review is to establish a single unified shared context between multiple stakeholders. it's the author's responsibility to propose changes tha
66.
▲
by
kiitos
1y ago
holy moly absolutely not git is a means, not an end code review is about the code as a unit whole, not the steps along the way!
67.
▲
by
kiitos
1y ago
> But yes, not everyone can or will write good commits. some people treat commits as meaningful units of independent review, and some people treat them as savepoints and the PR as the only meaningful unit of review, it's a distincti
68.
▲
by
kiitos
1y ago
code review isn't about diffs, it's about holistic changes to the project the point is not queue progression, it is about dissemination of knowledge one holistic change to a project = one PR simple stuff really
69.
▲
by
kiitos
1y ago
minimizing reviewer context is one thing a PR can try to do, but it's not like that's any kind of universal most-important metric that every PR needs to optimize for, in fact very often minimizing reviewer context is in direct ten
70.
▲
by
kiitos
1y ago
git is a means, not an end commits mean precisely what their author intend them to mean, nothing more if you squash-merge every PR then history is clean where it matters
71.
▲
by
kiitos
1y ago
> Why RPC? (And what is RPC anyway?) RPC is an ambiguous and abstract umbrella-term for any request-response communication between two nodes that don't share the same memory space, usually over a network connection, and always via s
72.
▲
by
kiitos
1y ago
I am not really sure what you're talking about RPC is "remote procedure call", emphasis on "remote", meaning you always necessarily gonna be serializing/deserializing the information over some kind of wire, bet
73.
▲
by
kiitos
1y ago
> But it's not exactly rewarding to add one more CRUD endpoint. It's a shit-ton of typing in multiple layers. i don't disagree with you but if "adding one more CRUD endpoint" and similar rote tasks represent any
74.
▲
by
kiitos
1y ago
mm, i think you're describing corba, not rpc in general
75.
▲
by
kiitos
1y ago
my mistake I think in using the term "language" as KSON isn't really a language in any normal definition of "language", it's really I guess a data serialization format, which is fully defined in terms of its (s
76.
▲
by
kiitos
1y ago
mmm, no, that's an explicitly incomplete list of informally-described observable behaviors that qualify as undefined -- which is fine and good! but quite far from a specification!
77.
▲
by
kiitos
1y ago
> and so I read the YAML specification but there isn't a single YAML spec, there are at least 2 in common use: yaml 1.1, and 1.2, which have discrete specs and feature-sets. re: anchor stuff specifically, 1.1 supports merge keys whe
78.
▲
by
kiitos
1y ago
the time spent literally typing code into an editor is never the bottleneck in any competently-run project if the act of writing code is something you consider a burden rather than a joy then my friend you are in the wrong profession
79.
▲
by
kiitos
1y ago
curious, where is the definition of "undefined behavior" for rust specified?
80.
▲
by
kiitos
1y ago
yup, he's also got a consistent history of aggressively disparaging and misinformed comments about go, fwiw
81.
▲
by
kiitos
1y ago
> So how would the Decompress Reader be implemented correctly? Should it use its own buffer that is guaranteed to be large enough? yes > If so, how would it allocate that buffer? as it sees fit. or, it can offer mechanisms for the cal
82.
▲
by
kiitos
1y ago
fun! name: 'Leonardo Bonacci' favorite_books: - title: Metaphysics author: Aristotle. favorite_numbers: - 1 - 2 delete that `.` at the end of Aristotle and you get a totally structura
83.
▲
by
kiitos
1y ago
KSON is a language defined by a grammar/spec, not any specific tool that implements that language, afaict? assuming so, where in that language spec do you define and control "warnings", in a way that other spec-compliant impl
84.
▲
by
kiitos
1y ago
those formats aren't bijective with each other, right? so there's no way for you to say that foo.cue can be equivalently transformed to any foo.json or any foo.nginx or whatever representation, because those transformations are ne
85.
▲
by
kiitos
1y ago
cool post, what are you trying to communicate with it? everything is the same, all positions are equivalent, there is no right or wrong?
86.
▲
by
kiitos
1y ago
Backwards-compatible means the new thing can handle the old things. Here JSON5 is backwards-compatible with JSON. Forwards-compatible means the old thing can handle the new things. Here JSON is not forwards-compatible with JSON5.
87.
▲
by
kiitos
1y ago
if you're writing bash inside of yaml then something has gone wrong well before yaml entered the picture, this is a problem with e.g. azure not with the yaml format
88.
▲
by
kiitos
1y ago
two huge thumbs down for KSON
89.
▲
by
kiitos
1y ago
i was responding to something else, 100% my bad
90.
▲
by
kiitos
1y ago
sorry, yes, i think we are in agreement
More ›