Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

15 years later, Microsoft morged my diagram

nvie.com

Post reply on HN
Print view View original

231–240 of 427 posts

Re: 15 years later, Microsoft morged my diagram

#231

Post by carlob »

g947o wrote: post #227
marginalia_nu wrote: post #215

Earlier quoted context omitted.

Yeah I've been collecting some of the weirdest ones I've seen floating by. It's really the only thing that has me visiting linkedin. https://www.marginalia.nu/junk/linked/games.jpeg https://www.marginalia.nu/junk/linked/json.png https://www.marginalia.nu/junk/linked/syntax.png (and before anyone tells me to charge my phone, I have one of those construction worker phones with 2 weeks battery. 14% is like good for a co…

Care to explain the last one? The presentation is weird and stupid, but I don't see any obvious (technical) issue other than the missing bracket on the left, unlike the first two

The 'long' code for checking apples is shorter, but it's missing the external for loop. So I guess you could say it's not (ahem) an apples to apples comparison.

Re: 15 years later, Microsoft morged my diagram

#232

Post by globular-toast »

m12k wrote: post #137

Regarding the original git-flow model: I've never had anyone able to explain to me why it's worth the hassle to do all the integration work on the "develop" branch, while relegating the master/main branch to just being a place to park the tag from the latest release. Why not just use the master/main branch for integration instead of the develop branch - like the git gods intended - and then not have the develop branc…

Yeah, I actually think that diagram and "git-flow" has caused a lot of harm. It shows a complete misunderstanding of both continuous integration and what tags are for. I've successfully purged git-flow and dragged developers, kicking and screaming, to a simple master branch, tags and maintenance branch model a few times now.

Re: 15 years later, Microsoft morged my diagram

#233

Post by raphman »

g947o wrote: post #227
marginalia_nu wrote: post #215

Earlier quoted context omitted.

Yeah I've been collecting some of the weirdest ones I've seen floating by. It's really the only thing that has me visiting linkedin. https://www.marginalia.nu/junk/linked/games.jpeg https://www.marginalia.nu/junk/linked/json.png https://www.marginalia.nu/junk/linked/syntax.png (and before anyone tells me to charge my phone, I have one of those construction worker phones with 2 weeks battery. 14% is like good for a co…

Care to explain the last one? The presentation is weird and stupid, but I don't see any obvious (technical) issue other than the missing bracket on the left, unlike the first two

I'm not OP but:

- missing ")" on the left side

- extra "}" on the right side

- the apples example on the right side ("Short code") ist significantly longer than the equivalent "Long code" example on the left side (which might also be because that code example omits the necessary for loop).

- The headings don't provide structure. "Checking Each Apple" and "Only Red Apples!" sounds like opposites, but the code does more or less the same in both cases.

Re: 15 years later, Microsoft morged my diagram

#234

Post by flir »

nicbou wrote: post #190

> Is there even a goal here beyond "generating content"? This is the part that hurts. It's all so pointless, so perfunctory. A web of incentives run amok. Systems too slick to stop moving. Is this what living inside the paperclip maximizer feels like? Words we didn't write, thoughts we didn't have, for engagement, for a media presence, for an audience you can peddle yourself to when your bullshit job gets automated.…

Acceleranco is looking rather prescient right now.

Re: 15 years later, Microsoft morged my diagram

#235

Post by globular-toast »

choeger wrote: post #144
m12k wrote: post #137

Regarding the original git-flow model: I've never had anyone able to explain to me why it's worth the hassle to do all the integration work on the "develop" branch, while relegating the master/main branch to just being a place to park the tag from the latest release. Why not just use the master/main branch for integration instead of the develop branch - like the git gods intended - and then not have the develop branc…

I am working with main/master for years now, and there's one problem you don't have with develop: Whenever you merge something into master, it kind of blocks the next release until its (non-continuous) QA is done. If your changes are somewhat independent, you can cherry-pick them from develop into master in an arbitrary order and call that a release whenever you want to.

Yes, you have to include QA in the continuous integration process for it to work. That means at any time you can just tag the top of the master branch to cut a release, or do continuous delivery if it makes sense (so no tags at all).

It sounds like you are doing a monorepo type thing. Git does work best and was designed for multiple/independent repos.

Re: 15 years later, Microsoft morged my diagram

#236

Post by raphman »

aftergibson wrote: post #82

Archive.org shows this went live last September: https://web.archive.org/web/20250108142456/https://learn.mic... It took ~5 months for anyone to notice and fix something that is obviously wrong at a glance. How many people saw that page, skimmed it, and thought “good enough”? That feels like a pretty honest reflection of the state of knowledge work right now. Everyone is running at a velocity where quality, craft and…

Huh, I thought that the MS tutorial was older. The blurry screenshot in it is from 2023.

And there ist another website with the same content (including the sloppy diagram). I had assumed that they just plagiarized the MS tutorials. Maybe the vendor who did the MS tutorial just plagiarized (or re-published) this one?:

https://techhub.saworks.io/docs/intermediate-github-tutorial...

Re: 15 years later, Microsoft morged my diagram

#237

Post by bandrami »

m12k wrote: post #137

Regarding the original git-flow model: I've never had anyone able to explain to me why it's worth the hassle to do all the integration work on the "develop" branch, while relegating the master/main branch to just being a place to park the tag from the latest release. Why not just use the master/main branch for integration instead of the develop branch - like the git gods intended - and then not have the develop branc…

The model works well if you're developing version 3.2 (which is not ready yet) but also non-trivially maintaining 3.1.

Re: 15 years later, Microsoft morged my diagram

#238

Post by co_king_5 »

pjc50 wrote: post #116
Animats wrote: post #59

This is so out of hand. There's this. There's that video from Los Alamos discussed yesterday on HN, the one with a fake shot of some AI generated machinery. The image was purchased from Alamy Stock Photo. I recently saw a fake documentary about the famous GG-1 locomotive; the video had AI-generated images that looked wrong, despite GG-1 pictures being widely available. YouTube is creating fake images as thumbnails fo…

The war on facts continues. Facts are hard, they require a careful chain of provenance. It's much cheaper to just make up whatever people want to hear, safe in the knowledge that there will never be any negative consequences for you . Only other people, who aren't real anyway.

[dead]

Re: 15 years later, Microsoft morged my diagram

#239

Post by embedding-shape »

dsego wrote: post #229
embedding-shape wrote: post #150

Earlier quoted context omitted.

> Whenever you merge something into master, it kind of blocks the next release until its (non-continuous) QA is done. That's what tags are for, QA tests the tagged release, then that gets released. Master can continue changing up until the next tag, then QA has another thing to test.

Can I tag a bugfix that goes in after a feature was already merged into main? Basically out of order. Or do I need to tag the bugfix branch, in which case the main branch is no longer the release, so we need to ensure the bugfix ends up in the remote main branch as well as the release. Seems like it could cause further conflicts.

I'm not sure what you mean, what does "tag a bugfix", "tag the bugfix branch" or "ensure the bugfix ends up in the remote main branch as well as the release" even mean?

What are you trying to achieve here, or what's the crux? I'm not 100% sure, but it seems you're asking about how to apply a bug fix while QA is testing a tag, that you'd like to be a part of the eventual release, but not on top of other features? Or is about something else?

I think one misconception I can see already, is that tags don't belong to branches, they're on commits. If you have branch A and branch B, with branch B having one extra commit and that commit has tag A, once you merge branch B into branch A, the tag is still pointing to the same commit, and the tag has nothing to do with branches at all. Not that you'd use this workflow for QA/releases, but should at least get the point across.

Re: 15 years later, Microsoft morged my diagram

#240

Post by marginalia_nu »

g947o wrote: post #227
marginalia_nu wrote: post #215

Earlier quoted context omitted.

Yeah I've been collecting some of the weirdest ones I've seen floating by. It's really the only thing that has me visiting linkedin. https://www.marginalia.nu/junk/linked/games.jpeg https://www.marginalia.nu/junk/linked/json.png https://www.marginalia.nu/junk/linked/syntax.png (and before anyone tells me to charge my phone, I have one of those construction worker phones with 2 weeks battery. 14% is like good for a co…

Care to explain the last one? The presentation is weird and stupid, but I don't see any obvious (technical) issue other than the missing bracket on the left, unlike the first two

Iterative example doesn't iterate, mismatches parentheses and brackets. Because of this, the iterative example is shorter and simpler than the "short & simple" lambda example.

Lambda example is to the best of my parsing ability this:

  apples.stream()
    .filter(a -λ a.isRed());  //
Should be

  apples.stream()
    .filter(a -> a.isRed()) // or Apple::isRed
    .forEach(a -> giveApple(a)); // or this::giveApple
It's also somewhat implied that lambdas are faster, when they're generally about twice as slow as the same code written without lambdas.
Post reply on HN