amir-h | 7 months ago | on: Enough AI copilots, we need AI HUDs
amir-h's comments
amir-h | 3 years ago | on: Show HN: Devbox – Easy, predictable shells and containers
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
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: Stacked changes: how FB and Google engineers stay unblocked and ship faster
amir-h | 4 years ago | on: Show HN: ChangeSets – group PRs across multiple Git repos
amir-h | 4 years ago | on: Pants 2.8 adds Go support: Build Go, Python, Shell, Docker with less boilerplate
I'm curious which big companies are using Pants v2 these days?
amir-h | 4 years ago | on: Ask HN: How is Netflix able to prevent screenshots on Chrome?
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.
amir-h | 4 years ago | on: Ask HN: What did you build this week?
https://medium.com/@amir_h/what-would-an-optimal-monorepo-lo...
amir-h | 4 years ago | on: Why Trader Joe's won't be offering an online store (2020)
amir-h | 4 years ago | on: Send small PRs (Google eng-practices)
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
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
[I'm also getting server error trying to submit this comment]
amir-h | 4 years ago | on: Facebook-owned sites were down
amir-h | 4 years ago | on: What’s in a package
A more direct link for other interested readers: https://bootstrapping.miraheze.org/wiki/Stage0
amir-h | 4 years ago | on: What’s in a package
amir-h | 4 years ago | on: What’s in a package
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.
amir-h | 4 years ago | on: Waydroid – Run Android containers on Ubuntu
amir-h | 4 years ago | on: I started SaaS companies in 2013 and 2021 – how things have changed
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