amir-h

I love this analogy.

I've been particularly feeling like this regarding AI code reviewers recently - I don't want a copilot that will do their own review, I want a hud that will make it easier for me to understand the change.

I've been toying with crafting such a code review tool as a side project recently: https://useglide.ai

Looks really nice! I'm wondering though whether this is luring me into a dangerous complexity cliff.

It seems easy to start using, but will I run into some issues a few months down the line like a package that's not available through Nix, or some Nix issue, and then I'm back to dealing with Nix's complexity only that I got there while staying clueless about Nix.

Seems like each source file has a comment saying:

Primary Author : *** Review Status: Reviewed

I wonder what was their process for version control and code review back in the day?

GitHub allows stacking PRs you send PR1 to master and PR2 is a pull request to PR1's branch, the diffs look good, and when PR1 is merged GitHub automatically changes its target branch to master.

Nice (: Gerrit has been offering this for some time now, nice to have it for GitHub as well: https://gerrit-review.googlesource.com/Documentation/cross-r...

Great to see that Pants is moving forward even after Twitter migrated to Bazel!

I'm curious which big companies are using Pants v2 these days?

That's probably DRM protected content, it's not Javascript hack but a mecahnism that's built in deeper. A high level overview of how it works on Android is here(the secure texture part):

https://source.android.com/devices/graphics/arch-st#st_vid_p...

I'm not sure what the implementation is on Chrome/Desktop; probably something similar.

I'm building a monorepo, trying to set it up to be as productive as I can:

https://medium.com/@amir_h/what-would-an-optimal-monorepo-lo...

"Well, at Trader Joe's, the reality is that over the last couple of decades we've invested those resources in our people rather than build an infrastructure that eliminates the need for people,"

CL stands for change list.

It's the unit of change that goes through code review (so for the context of that document I think the best translation to the git world is PR).

Though it's not exactly a PR, a CL is also a single change in the change history (so you could also say that a CL is equivalent to a commit)

I like how the giant monorepos (like Google's) serve as a forcing function against these problems.

When all of your dependencies are developed on the same repo and are part of the same CI they just won't break you (at least not your tests). And when you'll come back to the project 6 months later you'll find it building and passing tests against the latest versions of all dependencies.

This forces you to have a decent test coverage (otherwise they'll break you).

It makes library authors feel the pain of their downstream dependents and carefully consider breaking changes (otherwise they will need to spend time fixing downstream).

It makes people hesitant to bring in third party libraries that aren't very stable compatibility-wise (as the "internal owner" of the third party becomes responsible for updating it and unbreaking the world).

Hacker News also got so much slower, is it the load from people hoarding here after not being able to reach FB?

[I'm also getting server error trying to submit this comment]

Hacker News also got so much slower, is it the load from people hoarding here after not being able to reach FB?

Wow that Stage0 project is amazing, didn't realize anyone went that far, thanks for the reference!

A more direct link for other interested readers: https://bootstrapping.miraheze.org/wiki/Stage0

A person that had at some point control of a widely distributed toolchain binary (say a compiler, linker, or even a build tool) can trick an entire comnunity.

Fascinating write-up!

Reproducible builds are highly important indeed, though from security perspective we shouldn't assume we're secure because we can reproduce the build.

As Ken Thompson shows us in Reflections on Trusting Trust: backdoors can live in binary form only and the source code may not be telling the full story.

What we need to trust are the entities writing and distributing the packages, of everything. Sadly today there is no way to answer: what is the set of entities I'm trusting by using this package.

It will be interesting to see how these kind of solutions compare with emulators for e2e testing of Android apps locally and on CI.

Do you feel like VCs in general are now more open to funding close to 1 year of runway just to get an MVP out and test product market fit? or is it your background as a 2nd time founder that drives VCs to trust you with less PMF proof?