capn_duck

I agree that this would work, and be ideal. I think it only scales to a certain size organization though. At my company, I'd guess we have over a thousand developers across hundreds of teams, and more supporting staff. There's no possibility of getting everyone in at once.

The 16 pings a minute. The 6 hours of meetings a day because people aren't getting the information they need organically each day. The "hey, can I call?"'s during what I thought would be my free half hour in the afternoon. This is definitely not what it was like in the office.

Unfortunately, I recognize this doesn't change unless an org goes 100% back onsite.

The JS examples don't seem too demonstrative to me. Especially for someone not very familiar with RxJS. Any time you're wrapping something with `from` or `of`, I raise an eyebrow

  export function pipeline(in$: Observable<Product>): 
  Observable<string> {
      return in$.pipe(
          mergeMap(product => from(product.Images)),
      );
  }

Why use mergeMap at all here? Why not not just

  return in$.pipe(
    map(product => product.Images),
  );

I get that this is a toy example, not trying to be pedantic.

Thank you. I guess I was imagining that the flags lived in your source code repo, and required a commit and push to update, thus triggering some CD build and redeploying your app anyways.

This is my question. If your flags are in your repo, what is functionally the difference from just having them be variables in your code somewhere.

"Feature Flags that live inside your code" - That's just variables, no?

This is peak Hacker News response

I interpreted the parent comment in the inverse. A poor economy means people will stay in unhappy situations longer than otherwise.

I've always been unsure where this stuff fits in. Do you make it before your system is built, when its unclear how where all the cards will fall? Or after your system is made and in production and all the warts of reality are present and your graph is not so nice and neat anymore. This seems like an architects picture of things. Close enough to give people the false confidence to think they understand things, but not close enough to be of use to anyone actually working in the salt mines.

This is the second comment I've seen in this thread comparing "Gitflow" to what was typical in SVN. Having been there when SVN was in vogue, I can assure you that our process looked nothing like Gitflow. SVN encourages what we now refer to as "trunk based development". The default branch was even called "trunk".

My experience was that older VCS's (SVN in my case) leaned in heavily to the trunk based paradigm. I don't know what you're talking about with prod branches. The default branch in SVN was called - trunk.

This one blog post resulted in so much pain for so many. I'm glad it has been addended, but the damage was done.

For the record, I don't think it's the authors fault.

doesn't is suffice to say that functions meet all the prerequisites of a vector space?

f + g = g + f

f + (g + h) = (f + g) + h

f + -f = 0

(a * b) * f = a * bf

a (f + g) = af + ag

(a + b) * f = af + bf

I read this book too and it really drove things home. I remember after feeling a little bit unsure about the relevance of orthogonal systems, feeling the thrill of beginning to see and anticipate where the argument was going. It felt like I was discovering it for myself. I think there are lot of good math and physics books from the Soviet era.

If they are limited to 1, then they are not appropriate to use as a deployment mechanism. Do you only have one change being worked at a time? On my team, there's typically at least have a dozen different stories being worked in parallel.