all data is live and searchable
|
Basic Assignments
|
Options & Settings
|
Main Time Information
|
||||||||||||||||||||||||||||
|
|
|
Yellow
|
|
|
Sorry, no photos available for this element of time.
|
|
|
|
Notes:
|
|
On the morning meeting with Steve, Alan, Wayne, and I. We started out talking about needs on servers and database stuff. We then touched base on some other projects and just chatting here and there. - Wayne has been spending some time thinking about options and such. - What are the goals and what are we trying to accomplish? 1. a better, cleaner, more modern type interface. 2. a more efficient and faster database model. 3. simplifying the code and doing some clean-up to make things easier and more efficient. Think more along the one-to-many type model. 4. present a full featured API socket set - Lego type building blocks and ability to mix and bled to make custom solutions. - Currently we have business logic, database code, and look and feel all mixed together in the same page. Some pages and sections really mix things - almost to an unrecognizable level of what is what. - CSS is a very easy way to change the look and feel. This could be even set more per corporation than it already is. - Model View Control (MVC) standard. This has three different pieces. You have the model, the view, and the backend controller type functions. The model is an object of some kind. Often the model is related to the database structure. The view is what you see (HTML, CSS, JavaScript, graphics, etc.). Keep this as simple as possible. The controller piece takes the action and/or data and does something with it. These are the rules, the logic, and the decision making pieces. Basically, somewhat of the traffic cop helping to control flow, decisions, and traffic. - Helpers that help with the views... visual displays that show the users what things will look like. Virtually, they see what they will get and help with the sorting, show/hiding, verbage, aliases, data types, rules, etc. We would love to create custom tags to help build the forms and report output. Maybe think along the lines of cf_some_custom_tag. - If we build these custom tags (for building HTML and other visual displays) but we still want the final output to be customizable. - We use the black box customization options all the time. We want to maintain that ability. We could have multiple different builders and/or helpers. In the end, we really need to allow for the dynamics and customization. - How do we go from custom one-off number 1 to a base class or standard feature. This will happen over and over. Someone will have a great idea and build it out as custom. We then get other requests and eventually we want to make it a standard feature and/or option. - On the class models... we start out very broad and then start branching out as we get lower and lower in the structure. The deeper we go, the more specialized we need to get. - Usually there is a main controller and then smaller sub controllers. These could be the different actions and/or functions that could take place per model and/or object. The controller level is where you put the input validation. The controller helps validate the basic requirements. Does this data fit what is needed (super basic and/or generic validation). The model needs to control the details of that transaction. - We need to make lists of what is required and what is optional per model (per object - say each of the main 12 players). - We need to document the database, the data types, the field names, what they need, and what they require. We have started this, but it really needs to be pushed. This will help all parties. - In order to start this... you first start with a goal and then you start building the smaller pieces that will be required. Look at individual pieces and then start applying things as soon as possible. It is not recommended that you globally take over everything. Log and pick your battles... Maybe even take an inventory of what we have and then figure out where the hottest pieces are and work there. - Consistent automated testing... We keep running the tests until everything passes. As new changes happen, we rerun all of the consistent automated testing. This will help with consistency and debugging. Wayne was saying write the tests and then code to the tests. Slowly put test coverage that keeps testing other pieces as it goes out and expands. Basically, instead of testing individually, we test as a general coverage or more of a blanket type feel. This increases confidence and stability. - Taking the version control programs and such even further. Taking it clear to the test, build, test, and deploy to production. We are over writing each others code... who has the last cookie. Some of the developers have too much access to the system (FTPing files). - We could also code in teams and do some peer reviews. Currently we are still in the wild west and shooting from the hip. - This is all part of the growing process. - Setup the models based off of the database data per model. Basically, we document the model in data that could be given to all developers. That helps us have a standard piece that becomes the master plan and/or design. There are all kinds of layers within these pieces and objects. We have data layer, service layer, logic layer, etc. - This is kinda funny and silly... but Steve back on 6/22/17 said we should call our company "Fracture". Everything keeps unrolling and going deeper and deeper into subs and sub functions. - Currently we have methods that we use internally, methods that we use through API sockets, and methods that we use for custom code. We then have to maintain multiple sets of code which may or may not get updated. That flows back into the consistent automated testing and making sure that everything still works and runs correctly. It is amazing to see how everything is truly a system and integrated model. - The software maturity level. Eric would like to see things work towards a higher level. We don't want to get this high, but a level 5 maturity level is what NASA runs at. Jumping up those levels takes time and a good team. The higher the level, the more the cost and the slower things go and flow. Eric was saying that maybe we should check things out and then shoot for a level that looks good for our company (say level 2 - just off the hip number as an example). - We may be able to do some performance changes and then all of our servers are doing so much better. Currently, we keep adding more and more servers to get the performance we need. We need to find the balance between database optimization, code, and hardware/server technology. We will need to mix and blend as needed. We may need to get to a clustered server model and/or look into other options. |