Every ops team has some manual procedures that they haven’t gotten around to automating yet. Toil can never be totally eliminated. Very often, the biggest toil center for a team at a growing …
Yeah, I’m really wondering why they thought this was a good idea. My best guess is that they want to keep everything within one file, since it makes the script easier to deal with. But when automation actually starts being implemented, they want the functions for each task to be grouped (and I believe, Python doesn’t support inline modules), so they abuse classes for that…?
Well, and I guess, it allows them to have pseudo-constants within each task, which don’t need to be explicitly passed around between functions.
But yeah, really not a fan of needing this much boilerplate to start out with. In my opinion, the activation energy required to use this pattern instead of slapping down documentation needs to be as minimal as possible, otherwise folks will slap down documentation instead.
I have nothing to add except: man’s really wrote like 7 classes to just have 1 function each
That is what makes it Enterprise-grade!
Honestly, if they want to go full enterprise at least use the javabeanfactoryfactoryfactory pattern
Yeah, I’m really wondering why they thought this was a good idea. My best guess is that they want to keep everything within one file, since it makes the script easier to deal with. But when automation actually starts being implemented, they want the functions for each task to be grouped (and I believe, Python doesn’t support inline modules), so they
abuse classes for that…?Well, and I guess, it allows them to have pseudo-constants within each task, which don’t need to be explicitly passed around between functions.
But yeah, really not a fan of needing this much boilerplate to start out with. In my opinion, the activation energy required to use this pattern instead of slapping down documentation needs to be as minimal as possible, otherwise folks will slap down documentation instead.