all data is live and searchable
|
Basic Assignments
|
Options & Settings
|
Main Time Information
|
||||||||||||||||||||||
|
|
|
Blue
|
|
|||
|
|||
|
|
|
Notes:
|
|
-Idea from my dad while we were out walking… “Play at the wall.” – This deals with how we will allow outside developers to interact with adilas code and database. They will virtually play at the wall. This deals with API (application programming interface) sockets. -Other ideas from my dad… Treat the application like an electric wiring or circuit. All of the major wiring is done by the master electrician (programmer in our world). Once it is setup, a normal Joe is able to plug into the wall or power outlet. -When my dad and I were talking about electric circuits and playing at the wall, a couple other topics were: blue print reading or print reading (does the person understand the design or default flow). What standards are used? How does one read or interpret existing logic and wiring? Are there standard procedures or processes? If so, what are they and how can I get to them? -It is very tough to code to moving targets… Help out our future clients and developers by defining existing flow, wiring, output, and even code. -We need to fix the forgot password section. It should run great over our new API sockets. Currently it is built on older technology. Remember the glove analogy by an intern for handling custom code: - Same glove or page name - Any hand could go in the glove – any code could go into the page - I’d like to take this analogy to the next level… What is that level? I have needs to allow custom code, processes, and even custom output… - The glove thing, or whatever we come up with, will be used over and over again… Figure out a good solution! -On custom code includes... maybe define areas or sections and then allow those spots (places in the code) to be changed. This could be full page, navigation, headers, footers, body, sub body, etc. Basically, define the points where we allow custom. |