Hacker Newsnew | past | comments | ask | show | jobs | submit | shaftway's commentslogin

The way I look at it, the longer you stay in a high risk investment, the more opportunities there are four your investment to go sideways (aka you lose your investment).

I see it as similar to flaky tests. Let's say you work on a codebase with ~100,000 tests. About 1% are flaky, where the average flaky test fails 0.1% of the time. On the surface that sounds like it's pretty low risk, but once you do out the math your unit tests will only pass about 36% of the time. Maybe a 0.1% flaky rate is acceptable, but not at that scale.

Long term investing plays the same numbers game. Let's say you invest in a risky stock for ~3 years, where "risky" means it has a 0.1% chance of failing in any given day. There's a ~36% chance you win, but you'll probably lose.


I had the same experience being in downtown SF (near Market) for the first time in a few years, but I attributed it to the number of electric cars.

The whole visit felt weird, and eerie, and off somehow, but I couldn't figure out what it was. And then I was standing waiting for a crossing light and heard the clicking of a scooter's turn signal ~20 feet away. It stood out because it took a few seconds to realize that I shouldn't be hearing it because of other noise.


FWIW, I think this is an adult vs. kid thing. I used to be the kind who would build my own stuff, and my kids definitely prefer to design and build their own things. But at some point I transitioned, and it's more about having a built model, not about the creating process. And I think I'm starting to see the same changes in my older kid, where things tend to stay built for longer.

For me I think the change came when I was able to build more real things. I learned how to solder, and then I learned woodworking, and all of a sudden I could make something that's the exact shape I wanted. Once you have those abilities it's a lot harder to go back.


I don't know about builder's keys from that era, but modern builder's keys aren't vulnerable to this problem. The builder's key uses a deeper cut on one or more pins, but the owner's key can and should be pretty unique. The only real requirement is that there be at least one cut to a high enough number to allow for a builder's key. There's a good video here: https://www.youtube.com/watch?v=GUCW4OnE6Mc

Maybe they used a master key system instead.


Um, that’s the exact system I was able to defeat. Do a bit more analysis. You’ll figure it out.


This flow can work with jj also. It would probably be exactly the same. You'd do `jj new` and have Claude set the description and make its changes. When you're ready for the next round, you'd repeat and do `jj new` again for the next revision.

I think jj's mutable revisions are best thought of as automation around `git commit --amend && rebase_everything_after_this_commit`. If you're not using that kind of flow with Claude, you wouldn't use that kind of flow with jj either.


> > You just switch to that commit, fix the typo, and switch back to where you were. Or fix the typo where you were and squash the fix, and only the fix, into the commit that introduced it.

> That sounds the same in Git?

I've always struggled with this myself, and would like to update my git knowledge. Can you walk me through the commands to do this? Let's say the commit id is `abcd1234` and it's 5 commits ago.

In JJ I'd do this:

    vim file/with/typo.txt
    jj squash -into abcd1234 file/with/typo.txt
Or if I was feeling more pedantic I'd do:

    jj edit abcd1234
    vim file/with/typo.txt
    jj edit <<my latest commit ID>>


You have the same two options in Git:

    vim file/with/typo.txt
    git add file/with/typo.txt
    git commit --fixup=abcd1234
    git rebase --autosquash -i
For some reason I need to pass --interactive/-i, even if I don't actually want it to be interactive. I am not sure if this is just a bug in my Git version or if this is intended.

The git commit step can also be replaced with git-absorb, if you have this installed and abcd1234 was the last time you modified these lines.

The second approach is this:

    git rebase -i abcd1234~
    # do 's/pick abcd1234/edit abcd1234/' in your editor
    vim file/with/typo.txt
    git rebase --continue


I believe this only works when there are no other uncommitted changes.

So you would need to stash after the fixup commit and pop the stash after rebase. Or use autostash.


Sure, but I don't see that as a big deal. It comes down to the fact that git does (interactive) rebases and some merges in the working tree and not in memory. If it is able to do it in memory, then you also don't need to squash, but it needs a point where it could checkout conflicts, without altering data. If you like it to be automatic, you can always set rebase.autoStash or merge.autoStash.

As for effect on the workflow, you can just continue to work and commit and then call autosquash in two weeks, when your about to merge. This also has the benefit, that Git (by default) only alters commits nobody has used yet.


s/squash/stash/ <<< "then you also don't need to squash"


Ok. JJ wins this round. Go to commit, fix, go to commit is superior to this bunch of commands in every possible way.


That's your opinion.

The second approach has the exact same amount of commands. The first has 2 more. The add is necessary, because Git separates committing into two steps, which has other benefits. If you would want the JJ behaviour you can call commit -a. The autosquash is necessary, because you don't need to use fixup with autosquash, you can also do it alone, which is recommended if this fixes something, that is already in an older release.


I agree. I'm also not familiar with Bob Dylan in more than an abstract "he's a musician" sort of way. The second flowed effortlessy, conveying tone, intention, and imagery.


I have a friend who is having twins. I'm using some new woodworking techniques to make a pair of baby rattles for her. The real challenge is trying to make two shapes with organic curves and precise cuts that are as close to identical or mirror-image as possible, while also hiding the joints.

It's very low-tech. No screens, no CNC, the most technically advanced tool is the digital RPM readout on the lathe. It's nice to disconnect from my screens once in a while.


Around 1991 I remember having a book that was a cross between Choose Your Own Adventure and D&D. It was about the same physical size, but it was a full (albeit small) D&D campaign. There was a character sheet at the back of the book you could copy, and then as you went through the game you would roll for yourself and for your foes, tracking hits and HP on your sheet until you won all the loot or you died.

I've tried looking for these, but I've always run up against a brick wall. There's a good chance it was a European thing (I was there that year, and can't remember if I brought it or acquired it).

Any chance the HN hive mind has heard of something like this?


Could it be Steve Jackson's Sorcery! perhaps?

https://en.m.wikipedia.org/wiki/Steve_Jackson's_Sorcery!


Steve Jackson and Ian livingstone Fighting Fantasy books, mentioned in the article.

PDFs may be found online…


A long list of the books in the series can be found here: https://en.wikipedia.org/wiki/List_of_Fighting_Fantasy_gameb...

Some feature a branching storyline while in others the paragraphs are arranged in a 2D grid-like fashion and you can visit an earlier place multiple times.

(One thing that has stuck with me is a bad ending in one of them, where you are captured and the last choice you make is whether you want to sit in a small cage or stand in a tall and narrow cage for the rest of your life. I mean come on)


There were dozens of such series in the late '80s and early '90s. My first guess is the "Lone Wolf" series mentioned above (launched 1984). It has a grimdark flavor; if you remember creepy illustrations, I'd look there first.

Other options on my bookshelf include "Fighting Fantasy" (including the famous "Creature of Havoc") — https://laurencetennant.com/bonds/creatureofhavoc.html

Or "Middle-Earth Quest" (1985-ish) — https://gamebooks.org/Series/270/Show

Or "SwordQuest" (1985) — https://gamebooks.org/Series/333/Show

Or "Fabled Lands" (1996) — https://en.wikipedia.org/wiki/Fabled_Lands


> The CI system picks it up, gets a cache hit from the developer’s build, and produces a release artifact.

Why would you cache developer builds on CI?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: