HackerTrans
TopNewTrendsCommentsPastAskShowJobs

capn_duck

no profile record

comments

capn_duck
·2 anni fa·discuss
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.
capn_duck
·2 anni fa·discuss
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.
capn_duck
·2 anni fa·discuss
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.
capn_duck
·2 anni fa·discuss
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.
capn_duck
·2 anni fa·discuss
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?
capn_duck
·3 anni fa·discuss
This is peak Hacker News response
capn_duck
·3 anni fa·discuss
I interpreted the parent comment in the inverse. A poor economy means people will stay in unhappy situations longer than otherwise.
capn_duck
·3 anni fa·discuss
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.
capn_duck
·3 anni fa·discuss
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".
capn_duck
·3 anni fa·discuss
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.
capn_duck
·3 anni fa·discuss
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.