quacker

And if I'm using GitHub/Gitlab, I have pull requests that I can look back on which basically retain everything I want from a feature branch and more (like peer review discussion, links to passing CI tests, etc). Using the Github squash merge approach, every commit in the main branch refers back to a pull request, which makes this super nice.

e.g. When clicking the big green "Merge pull request" button, it will automatically squash and merge the PR branch in.

So then I don't need to remind or wait for contributors to do a squash merge before merging in their changes. (Or worse, forget to squash merge and then I need to fix up main).

The article discusses why contributors should rebase their feature branches (pull request).

The reason they give is for clean git history on main.

The more important reason is ensure the PR branch actually works if merged into current main. If I add my change onto main, does it then build, pass all tests, etc? What if my PR branch is old, and new commits have been added onto main that I don't have in my PR branch? Then I can merge and break main. That's why you need to update your PR branch to include the newer commits from main (and the "update" could be a rebase or a merge from main or possibly something else).

The downside of requiring contributors to rebase their PR branch is (1) people are confused about rebase and (2) if your repository has many contributors and frequent merges into main, then contributors will need to frequently rebase their PR branch, and each rebase their PR checks need to re-run, which can be time consuming.

My preference with Github is to squash merge into main[1] to keep clean git history on main. And to use merge queue[2], which effectively creates a temp branch of main+PR, runs your CI checks, and then the PR merge succeeds into main only if checks pass on the temp branch. This approach keeps super clean history on main, where every commit includes a specific PR number, and more importantly minimizes friction for contributors by reducing frequent PR rebases on large/busy repos. And it ensures main is never broken (as far as your CI checks can catch issues). There's also basically no downside for very small repos either.

1. https://docs.github.com/en/repositories/configuring-branches...

2. https://docs.github.com/en/repositories/configuring-branches...

Sure, I can deterministically resolve the same X.Y.Z versions of packages according to whatever algorithm I like.

But literally everything is mutable (read: can be compromised). Package managers, bytes flying over the network, build servers - all mutable. A published version of a package can be overwritten. Some package managers allow authors to overwrite existing versions.

That means no guarantee of reproducibility. I build again the next day, and I may not download the same code for the same X.Y.Z version of a package. Or my local cached packages may have changed.

So I need checksums on packages. Then I can prove I have the exact same code in those packages. And if I have checksums on packages, I have a lock file.

> lockfiles are an absolutely unnecessary concept that complicates things without a good reason

What is even the complication? The lock file is autogenerated on a successful build and I commit it. It's trivial to use. It's literally all benefit and no downside.

It's not the exact same issue because Gradle and Maven have different conflict resolution:

Maven dependency conflict resolution works with a shortest path, which is impacted by declaration ordering. Gradle does full conflict resolution, selecting the highest version of a dependency found in the graph.

from https://gradle.org/maven-and-gradle/

If I open a product catalog, I do that to purposefully look at products.

What compile-time validation do I actually lose by using struct tags for CLI arg parsing?

1. I can deselect some pre-defined categories that Spotlight searches

2. I can click the "Spotlight Privacy..." button (at the very bottom right). Then I can add folders for it to ignore.

(My preference is for Spotlight to ignore almost everything, so that it isn't indexing stuff and eating CPU on this old Macbook Air. I only have it scan Applications, Calculator, and System Settings. I have it specifically ignore my entire home directory which is where all my git repos are.)

IMO, it doesn’t belong here.

I’m still figuring out if/how it can make me more productive. First impression is it’s more a drain on productivity than not.

That’s more than enough for a cheap android phone.

1. https://travel.state.gov/content/travel/en/passports/how-app...

Envy apples are my favorite. They tend to be more expensive than Fuji, but are about the same price now.

We see the LLM sometimes do sort of well at a whole bunch of tasks. But it makes silly mistakes that seem obvious to us. We say, “Ah ha! So it can’t reason after all”.

Say LLMs get a bit better, to the point they can beat chess grandmasters 55% of the time. This is quite good. Low level chess players rarely ever beat grandmasters, after all. But, the LLM spits out illegal moves sometimes and sometimes blunders nonsensically. So we say, “Ah ha! So it can’t reason after all”.

But what would it matter if it can reason? Beating grandmasters 55% of the time would make it among the best chess players in the world.

For now, LLMs just aren’t that good. They are too error prone and inconsistent and nonsensical. But they are also sort weirdly capable at lots of things in strange inconsistent ways, and assuming they continue to improve, I think they will tend to defy our typical notions of human intelligence.

There's a linter which I like[1] that checks variable name length based on the scope of its usage.

The idea is a variable name can be short if it is used in a small lexical scope (e.g. a function parameter in a one-line function) because it won't affect readability much. But names should be descriptive if used in a larger scope (e.g. a constant used across a file).

1. https://github.com/blizzy78/varnamelen

I know if I like the taste of a new dish without being a great chef. And so can people know if they (and their friends) will buy and use a $3k - or $1.5k - VR headset.

I’d sympathize more with this if college was not so expensive. If you have the means, by all means spend the credit hours on whatever you like. But covering tuition is difficult for many students, and graduating even one semester early is a significant cost savings, and more so if you can start working and making money.

Instead of “random humanities” requirements, maybe actually prepare me for a job. Provide industry relevant courses, or apprenticeship / internship opportunities. Or leave me time to do school and a job concurrently to help cover tuition.

Let me be done with school, and afterward I’ll learn a language or philosophy or whatever I like in my free time.

If Reddit wants to serve ads to users in the EU and store their info (email, ip, post content, etc), then the GDPR absolutely applies.

Enforcement is another question, but several US companies have been fined due to GDPR violations.

- It is not known that that the Romans used knitted clothing. Knitting was invented later.

- Knitting can be done with cheaper, easier to craft tools that are just as effective. Knitting doesn’t explain the cost and skill required to craft the dodecahedrons.

- There is no wear on these dodecahedrons that we’d normally expect from a well-used tool.

Out of curiosity, I setup two directories where the second has a new file, a modified file, and a removed file compared to the first:

    $ tree dir1/ dir2/
    dir1/
    ├── empty.txt
    ├── modified.txt
    ├── remove-this.txt
    └── unchanged.txt
    dir2/
    ├── empty.txt
    ├── modified.txt
    ├── new-file.txt
    └── unchanged.txt

    $ git diff --name-status dir1 dir2
    M       dir1/modified.txt
    A       dir2/new-file.txt
    D       dir1/remove-this.txt

I have Delta Dental through my employer’s benefits and it covers all the types of operations that I’d expect: preventive, endodontic, periodontic, orthodontic, prosthodontic, etc.

If I need a root canal, it’s covered by Delta Dental (up to a point, given the deductible). If I chip a tooth, and get an inlay or onlay, that is covered. Is this not insurance? Why not?

- A rice cooker frees up a burner on the stove, which is useful for those with small apartments or other situations where there are few or no burners available.

- Rice cookers are very consistent and virtually foolproof, even the cheap ones. Add water and rice, set it, and forget it. I can say I’ve over or under cooked rice on the stove at least a few times, but not once in a rice cooker.

- Decent rice cookers make far better rice than I’ve personally ever made on the stove (and I have cooked rice on the stove plenty).

- More expensive models keep rice hot (at a food-safe temperature) for hours, so you can prep well in advance of a meal. I put rice on to cook and can leave the house for hours without worrying about it, and have rice for the whole day in one batch, if needed.

- Rice cookers also cook other things and some handle different kinds of rice. Brown rice needs to be cooked significantly differently than white rice, for example.

Yes, there are ten other buttons I never use. Yes, they could conceivably be “better” in small ways. Yes, modern ones can break like every other appliance does, but the ones from the 80s and 90s broke, too.

However, the approach of few/no code reviews doesn’t work for large open source projects that accept external contributions (the author of the post is mitchellh who is a founder of HashiCorp, which has/had several large open source projects).

Try this:

    STR.”x=\{x} y=\{y} z=\{z}.”

    “x=“ + x + “ y=“ + y + “ z=“ + z + “.”

The concatenation example is less readable as well. Have I included whitespace to exactly match the string template example? It’s a little hard to tell at a glance because I have to distinguish what is code whitespace and what’s included in the string.