Emails and getting ready for the day.

Zoom meeting with Russell. See my notes below.

After meeting with Russell, I was on a phone call with John for about 30 minutes. Talking about what is going on with Adilas and Adilas Lite. Going over possible work options. He is going to reach out to Steve and Cory and we'll go from there.

Some of my notes from meeting with Russell:

- Working with Russell on his tool and homemade framework project. He has learned a lot by building it. He can then take that information and know how and apply it to his other projects. Interesting learning method.

- We talked about project bloat - and how using outside libraries and themes are faster, but it tends to bloat the project (you get more than you want or need - code wise).

- Instruction heavy vs automated

- A framework sets a standard. You can then start expecting certain things. Almost like a miniature set of rules and expectations.

- Starter kits vs the end all, be all - You have to start somewhere. Things will keep morphing over time.

- Tools tend to be built as a box (sort of rigid). Often, people and companies want to add on to the box (customize or add custom code or custom work flow). You then have to ask yourself, does your (my) code fit in the box? Yes/No - then trying to match up tools with company structure and needs. Russell was drawing a standard code set and then a non-standard code set. Imagine one being like a box and the other looking like a blob or a flower with different peddles. We were talking about what fits in the box and what has to be custom. We had some good conversations about that. What is the core? What are the plugins? What is custom? What is allowed? What tools or tooling is being used? Etc.

- API's and API sockets - Allowing outside parties to virtually play at the wall - The backend code could be whatever. The frontend is more structured, meaning the API interface needs to be open to outside traffic (permissioned and approved) and a standard that could be used over and over again. Basically, how it is presented back to the user or developer, needs to be well documented and as standard as possible. The true backend has more flexibility. The backend creates the content that is given back. It also interprets the inbound requests.

- The system and it's architecture and code are all based on trade-offs. You then have to accept those trade-offs. Speed, flexibility, rigidity, rules, scale, custom, standard, hardcoded, dynamic, etc. You have to look and balance the trade-offs.

- If you are doing the full API socket thing, you could actually do a headless CMS (content management system). Basically, if you are going the API route for quick and dirty stuff, it (the new application) doesn't have to look like or follow the same rules (thus becoming headless). You separate the content from the layout or view of that content. Imagine a WordPress type app that is built better and interacts with our internal pieces. We talked about the flexibility of the API. It would be so cool if you could mix and match API calls (quickness) and the whole power of the adilas backend. Inbound and outbound requests could return simple JSON. Lots of potential here. For fracture and adilas lite, we want to run the whole thing off of API socket calls. Our own internal headless CMS, in a way.

- Doing everything on your own (one man show or lone wolf) requires you to know too many topics and subjects. Jack of many trades, master of none. You can gain a lot by allowing for specialists and teams. Correctly done, they can make some amazing things happen.

- Setting up rules and then enforcing those rules. Firm, fair, consistent.

- When pushing API content back, sometimes it is helpful if you can add in helpful stuff to help out the users - For example: Pagination values and page links. Ideally, it is all done through settings, requests, and options. Only return what they want, but make it available if needed. Try to think - what would help the user and/or developer on the other side of the API request?

- Building out basic functions that could be plug and play (self-documenting, self-validating, etc.)

- Russell is trying to build an auto generating REST API for his stuff. The auto generating portion is based on the database (data dictionary). Virtually a set of interpreted rules, assignments, and instruction.

- There is a database level and a service level. Each needs to be built separately. In our terms, we are trying to do DAO's (data or database access objects) and services (things that do something including connecting to the DAO's).

- Build the super complex stuff once, and then use it many.

- We talked about the analogy of a set of railroad tracks. If you build out the known railroad tracks and have proven the methods, you can use it over and over again. Railroad tracks are great for that. If you have to keep building out new ones, and you don't get to use them over and over again, why make railroad tracks, make a simple road instead.

- Figuring out your own testing strategy

- Helping the users use things correctly based on validation and/or information or feedback to the users. Basically, force them down the path and don't give them too much wiggle room (helps the devs manage things). Sometimes too many choices cause more problems.

- Usability and error handling and error messages (good communication back to the client or end-user or even back to the developers).

- From Russell - When your code structure or architecture is bad, your testing will scream at you. If you have a good structure or architecture, your tests should be easy or easier.

- The value of training

- If the servers are down, you don't build tests, you just fix. If you have the time, you build the tests and get the whole thing done.

- Having a good system helps you go faster.

- Dealing with testing, you are going to test anyways, may as well write it in a test. This enables you to be able to go back and rerun those tests. If you have good tests, it should help you in finding those error and bugs faster. Progress moves at the speed of trust. If it's your mess (code), you know how to clean it up and fix it, you also know what it affects (touches or reaches out to - dependencies). What about the other guy (someone who comes in and works on your code)? How do you pass on the notes and instructions? You really have to think about looking out for the other guys/gals that will be coming along later.