From 324314c6280f9bb3e1359fd33745b096ef594bfd Mon Sep 17 00:00:00 2001 From: Gal Szkolnik Date: Fri, 21 Jul 2023 05:05:13 +0000 Subject: [PATCH] Adding detail to docs --- ASSIGNMENT-01.md | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/ASSIGNMENT-01.md b/ASSIGNMENT-01.md index d0ed864..3d622e7 100644 --- a/ASSIGNMENT-01.md +++ b/ASSIGNMENT-01.md @@ -45,3 +45,32 @@ These classes allow me to easily manage logs in a consistent pattern. + If the user doesn't exist, it will create the user. + If the user isn't a member of the above mentioned group, add it to it. 4. Display the report. + +## Explaining my decisions/code structure + +I really dislike retyping commands again and again, so I create +"templates" within the code that I can reuse. + +In this instance, each operation/action is stored in a hash table along +with it's identifying Log details. + +This way, I can focus on creating sequences of these Actions, and have +my script just load each action until something either fails, or the +run completes. + +That's the purpose of `$Automation`. + +### Why not `$Automation` all the way? + +I had an option here to populate the $Automation list, and then just +run the sequence. I decided against it. + +The sequence is supposed to be a success-only sequence. If something +breaks, exit. Adding users might fail, it should continue to the next +user. + +Becasue there is a non zero time action involved in testing whether the +user already exists, or is already a member of the group, I decided to +run each user action, including evaluating it's state individually. +This reduces the risk of caching an incorrect state, as well as the time +involved to reach an error state, should one arise.