Basic Assignments
 
Options & Settings
 
Main Time Information
Color Code: Yellow
Assigned To: Brandon Moore
Created By: Cory Warden
Created Date/Time: 7/12/2022 10:57 am
 
Action Status: Blank (new)
Show On The Web: Yes - (public)
Priority: 0
 
Time Id: 9183
Template/Type: Brandon Time
Title/Caption: Weekly server meeting
Start Date/Time: 7/19/2022 10:00 am
End Date/Time: 7/19/2022 11:30 am
Main Status: Active

Sorry, no photos available for this element of time.


Notes:

Reporting on the new AFB services and settings. Wayne has been working on a number of big setting projects dealing with corp-wide settings, AFB (adilas for business) settings, and other big database tables. Cory has been very grateful for other servers and being able to stage and work through the deployment processes on these new changes. Basically, getting a staging and testing server type approach in place and working.

Another big thing that Cory was happy about was the ability to include some of our customers and clients in the testing process. This is great for custom code and special usage on certain pages (logic and flow). It does take a little bit longer, but we get good results and less tech support and client care issues.

As part of the server meeting, Wayne, Cory, John, and I were talking about different things that are going on with the servers. For the most part, things are going quite well. That is awesome. We talked about memory management, backend garbage collection routines, code management, and other server related things.

Wayne reported on his DAO (data or database access objects) project and using the on application start functionality for global variables and fixed data structures. Wayne requested that we send him a list of developers and their email addresses. He wants to create an email group for us to use for internal communications. We also talked about making sure that all of the instructions and information is listed in the adilas docs.

Developer's make tools - that is what they do. Being able to harness some of those tools to help each other. We also talked a bunch about standardizing flow and code. We talked about security issues and who has access to what and where things (data and info) are stored. We actually have two sets of docs - the server docs (major backend stuff) and the normal adilas docs (open to all of our developers). Right now, only certain persons have access to the server docs, for security purposes.

We talked about new corp-wide server settings and getting that info into the docs. Wayne has revised that process and created new database tables to help with future expansion. As a side note, there are multiple different levels for settings. We are currently seeing corp-wide settings (way up at the world level), group-wide settings (setting for all of the 12 main player groups), page level settings (mostly custom JSON objects and settings), and user level settings (settings on a per person or per user basis).

Our next major topic was manual testing vs automated testing. Talking about bug tracking and moving into a more standardized way of tracking and doing things. Every team goes through different phases and levels. They are forming, storming, norming, and performing. I can feel a big push to help normalize and standardize things. It feels like our team is going through that part of the team development cycle. The environment keeps changing and we feel like we are never getting to the performing (well-oiled machine) level. Kinda interesting.

More topics of discussion: What are our processes? The true costs of testing? Should we make a more rigid code sign-off process? and What about running automated testing and requirements there? Some good topics and good discussions. Who gets to merge things into master? Who is going to enforce and teach the different things (requirements and best practices)? Lots of questions.

Along with the discussions on testing, we talked about making and spending the time to help teach our guys and gals how to write good tests. The real value of testing comes in the form of virtual insurance... if things change, does it still work in multiple different situations. We tend to test quite well for the basic conditions and scenarios. It's those darn edge cases and variations (one-off's). Implementing automated testing has an upfront cost but pays out over time. Wayne would like us to look at the broader picture and bigger scope vs just the projects that are before us.

Towards the end of the meeting, Cory was pushing other projects forward and trying to nail down some scheduling and key steppingstones. She is doing a great job trying to organize and help us all out. Along the way, Wayne was suggesting that we take some of what is working really well and make it into our standard default. Whether it was dealing with testing, deployment, staging, or timing of new rollouts and releases.

One of our biggest variables is how many variables there are to look at and take into consideration. We have different people, different companies, different industries, and all of them run and do things slightly different. That is both a pro and a con. We also need to look at user data - some is small, minimal, or tons, full, and even bulging at the seams. That too creates more variables. Settings and permissions are how we manage these parts, pieces, processes, and logic.

Wayne and John are going to be working together to get some training accomplished on doing automated tests and what we want all of the other developers to do. Trying to get on the same page for testing and other processes and standards. Making progress. Good meeting.