Teri RadichelLast night I just moved the menus to a new project and started over on that code. At some point the two project agents were fighting to use their own code instead of using shared. Kind of like some developers I have worked with. Ok I’ve done it. 😆
I want to take this further but more on that later. Now I have XML driven menus. Yes intentionally chose that. Wrote explicit instructions how the menus should be implemented with file names in the README.
This smaller focused context helps the agent work better on a smaller scope. And yet it didn’t use the same construct for all the menus so I had to have it rewrite some unmanageable. Now all the code is structured the same way, it’s easy to insert new menu items and what actions should be taken when a number is selected.
Also, I added the ability to add and remove organizations, because I plan to create a test organization and my live organization.
In addition the environments and their resource menu. Each environment type is in an XML file. Easier to add and remove new environment types and define what is deployed in them be defining the menu for each environment and pointing to the correct deployment file for each menu item.
I had to be very explicit about defining for the model how to reduce and reuse code. It cannot seem to figure out the construct using sourced files and individual actions in individual files to keep the code easy to follow and reduce breakage. If the program is updating the file for one action it won’t break another.
So I’m getting closer to being able to completely configure an organization and the environments I want to deploy in a way that is adaptable to any organization.
The thing the agents were fighting over was how to create and parse XML files. I also figured out one was using xmllint shell. I removed that but need to evaluate that more later.
I also explained in the fixed notes why I’m restructuring the organization a bit to make it easier to restrict different environments to limited regions and lock regions down when not making changes. The AWS services will still work but no user actions are allowed when an environment is locked.
Last night included a fair amount of thinking time so the resource needle didn’t move too much. I’ve used 50% of my $200 plan since the begin of the month but with smaller code base and locking down some code from incorrect changes hopefully will spin less and figure things out more easily.
The benefit of doing this is that I could start over and redo the menus without messing up my old code. The other issue is that if I revise all the environments before I remove things in the existing environments that aren’t supposed to be there I won’t be able to delete them.
Right now I can simultaneously test both menus until I am sure the new ones work and I can work on creating new environments the way I want and cleaning up resources. I should probably make sure I can clean up any resources that shouldn’t be in an environment anyway.
Managing these things is not simple! Using a flexible approach is key.
