amir-h's comments

amir-h | 7 months ago | on: Enough AI copilots, we need AI HUDs

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

amir-h | 3 years ago | on: Show HN: Devbox – Easy, predictable shells and containers

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.

amir-h | 3 years ago | on: Microsoft 3D Movie Maker Source Code

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?

amir-h | 4 years ago | on: Send small PRs (Google eng-practices)

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)

amir-h | 4 years ago | on: The JavaScript ecosystem is a hot mess and so is software development

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).

amir-h | 4 years ago | on: Facebook-owned sites were down

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]

amir-h | 4 years ago | on: What’s in a package

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.

amir-h | 4 years ago | on: What’s in a package

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.

page 1