238 lines
12 KiB
Plaintext
238 lines
12 KiB
Plaintext
# TODO original todo docs
|
|
|
|
This was my original todo doc which I've pared down to only what I want to work on a few steps ahead.
|
|
Keeping this for reference as it has a lot of ideas about core services etc that will be useful
|
|
|
|
|
|
|
|
|
|
|
|
A NEW START
|
|
|
|
|
|
|
|
Get shit done:
|
|
|
|
Use an agile like process and start coding ASAP with the lowest level pre-requisite stuff.
|
|
|
|
I get stuff done faster when I see results and coding isn't bad to start early as long as it's done in the correct order and is iterated agilely
|
|
|
|
Code tests and then code against them, don't get crazy about unit testing every little thing, just what is necessary to validate
|
|
Using an agile-like process re-iterate and continually add new stuff while testing.
|
|
|
|
|
|
I want an installable, testable product ready to deploy even if it only has one feature and no front end yet.
|
|
|
|
Then starting from that base, add in all the common, shared, features first.
|
|
|
|
Ideally we have a real product that can be installed and run as soon as possible and then build onto that and iterate, adding feature by feature.
|
|
|
|
|
|
1) Determine the first things to implement, ideally everything that isn't a business object requirement, bootstrap process, configuration etc.
|
|
2) Implement the core with sysop stuff, generator equivalent, db, maybe not even any user accounts yet, just the framework
|
|
- Want to be able to install as in production, start the sever, configure, view the sysop stuff make an online account and test there etc
|
|
3) Add a single simple business feature, maybe login and user creation, license etc
|
|
- Code the front end for that feature, at this point need shell and etc.
|
|
|
|
4) Test all the above be sure about it, make sure it follows the guidelines for coding standards etc, then get into the actual features
|
|
5) Code AyaNova business features
|
|
- ** DO NOT WASTE TIME PLANNING AND DOCUMENTING EXISTING UNCHANGING FEATURES, LET AYANOVA SOURCE BE THE GUIDE FOR THAT **
|
|
- Just document changes or new stuff only
|
|
- This is where we get into the stuff below and the biz object cases etc
|
|
- Code in order from the simplest most fundamental objects towards the most esoteric and complex multi object items
|
|
- Save the most complex objects for last so as to save time as no doubt changes will come up in other coding
|
|
- For example, there are no doubt objects that are mostly standalone and don't involve a lot of other objects, start there
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
******************************************************************************************************************
|
|
******************************************************************************************************************
|
|
OLD PLAN BELOW HERE KEPT FOR REF BUT NEW PLAN SUPERSEDES
|
|
******************************************************************************************************************
|
|
******************************************************************************************************************
|
|
|
|
|
|
|
|
|
|
|
|
## FEATURE PLANNING / RE-ORG / AUDIT CASES
|
|
|
|
- PLANNING STEP 1: Go through all AyaNova 7.x, 8.x cases and any other places there is feature stuff
|
|
- Move to RAVEN the ones that are worth keeping / looking into (snap judgements)
|
|
- Set all cases moved to Raven to priority 3 indicating unprioritized
|
|
- Stuff that will never be done for sure just close.
|
|
- Stuff that won't be done in RAVEN but might be worth keeping until the release of RAVEN before closing drop priority down to 5
|
|
- When done there should be no more cases above priority 5 in 7.x unless they will be fixed in 7.x
|
|
|
|
- PLANNING STEP 2: Examine RAVEN cases and re-prioritize and categorize them:
|
|
- SET THE CATEGORY COLON DENOMINATED i.e. (CLIENT, REGION, WORKORDER:TASKS:CR:NEW, UI, SECURITY etc) by prepending the title with the category.
|
|
- If it's completely new feature then the last tag should be ":NEW"
|
|
- IF it's customer requested put a :CR tag in the title
|
|
- UNPRIORITIZED
|
|
- default for items until I categorize them
|
|
- PRIORITY 3
|
|
- MUST HAVE IN INITIAL RELEASE
|
|
- PRIORITY 1 and 2
|
|
- flag as highest priority 1 for work on first and 2 for work on secondly
|
|
- SHOULD HAVE IN FUTURE RELEASE
|
|
- PRIORITY 4 and 5
|
|
- flag below highest as priority 4 or 5 depending on urgency
|
|
|
|
- PLANNING STEP 3 THE WORKORDER LAYOUT
|
|
- This is tricky so needs a whole step
|
|
- Determine new workorder layout and structure
|
|
- Don't need exact features, rough is ok
|
|
- Step 4 will get into the details of the workorder
|
|
|
|
******************************************************************************************************************
|
|
******************************************************************************************************************
|
|
NOT DONE BELOW HERE
|
|
******************************************************************************************************************
|
|
******************************************************************************************************************
|
|
|
|
|
|
|
|
|
|
- PLANNING STEP 4 FEATURES DOCUMENTS
|
|
- Read through my own notes in CODING-STANDARDS doc and REASEARCH.TXT and SOLUTIONS.TXT
|
|
- VERY IMPORTANT stuff in there, a lot of sysops stuff and practical decision stuff
|
|
- Review it all and update any related cases / make new cases as appropriate.
|
|
|
|
|
|
- Find common features that are shared with objects so they can be "Interfaced" and planned for
|
|
- Tag handling, UI preferences and MRU's and user settings
|
|
- Localization stuff
|
|
- Notification
|
|
- Common menu options that are shared by objects
|
|
- Need a set of sections that deal with just this kind of thing as it will be coded FIRST.
|
|
- Common UI widgets Document every common UI widget needed and where.
|
|
- The RAVEN ui will be made up of a lot of tiny widgets that are re-used here and there, that's what I will be making so need to document that
|
|
- Essentially everything in the UI will be a bunch of widgets housed in a bunch of modules housed in a shell
|
|
- Identifying them all up front will save tremendous time in development
|
|
- For example: in lots of places we need to show a filterable list of workorders tied to the object being viewed
|
|
- Like on the client form you need to see a list of workorders for that client
|
|
- On the unit form a list of workorders for that unit
|
|
- So a WORKORDER LIST widget is one that will be re-used time and again so document that and it's features
|
|
- Then it's just a matter of snapping it into any area it's needed
|
|
- this will translate to a business object and probably a route in the api etc etc
|
|
- Search widget and results display, that kind of thing
|
|
- Identify the first object to code, ideally it should have the most common features and the least of it's own features so I can focus on the shared stuff.
|
|
|
|
|
|
- What I want to end up with is a set of documents one for each major feature
|
|
- In each document I want to list what is kept, what is changed and what is new
|
|
- Add points of what each feature currently does and needs
|
|
- Then go through the cases and note new and changes relevant to that object
|
|
- Consider and make decisions and rank as priority 1 (in first release) and priority 2 - subsequent release
|
|
- iterate until there is at the end what I'm after
|
|
|
|
- This is the list I will work from to ensure everything gets done
|
|
- I want each documents items in the best order of implementation as much as possible
|
|
- THIS IS IMPORTANT: I don't want to code a feature then see that I should have done something different later
|
|
- Then I can go through it while coding as my todo list basically
|
|
- Ideally then can test as each object is ported, kind of like each object is a new feature in quick release cycle
|
|
|
|
|
|
|
|
- PLANNING STEP 5 USER INTERFACE
|
|
- Design the user interface for each section above, I want to see visual design that I can work from instead of winging it.
|
|
- ?? Need a design for at least two views, desktop / tablet and phone but need to research this a bit I guess
|
|
- Doesn't need to be perfect, a rough sketch and placement is fine.
|
|
- Need to design the widgets essentially
|
|
- Need to account for each view depending on ROLE viewing it.
|
|
- Find the commonalities for the roles so there is a pre-defined levels of access for each widget that match roles
|
|
- Like a Read only limited view, a full control view, a whatever view, each type named and replicate concept to all widgets
|
|
- Widget should be aware of roles and what to allow for each of them
|
|
|
|
- STEP 6 CODING
|
|
- Code the NFR / SHELL and fundamental / common features like tag handling etc.
|
|
- Since a widget is kind of standalone ready, maybe a widget playground to test out widgets on a blank canvas without worrying about shell stuff at first.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- HOSTING planning
|
|
- Just a light initial assesment will not be super important at first, only interested in big picture stuff that might affect coding
|
|
- What will we need for hosting?
|
|
- What is the unit of software that each customer would use
|
|
- I.E. do we have one container per customer and spin them up as required
|
|
- Apply to design
|
|
|
|
|
|
|
|
|
|
## INITIAL CODING: FRAMEWORK SKELETON ALL NON FUNCTIONAL REQUIREMENTS
|
|
|
|
- Make a list of all the things that it should do for front and back end
|
|
- This is really the foundational skeleton of everything and is the most important step, if it takes a while so be it, it will save a fortune in time later
|
|
- The design should be frozen once this skeleton satisfies NFR
|
|
- Once this is in place then can just fill in functionally required code and objects from design
|
|
- It's also a reference point for any other new projects going forward so keep a snapshot / Subversion tag that THIS IS IT!!
|
|
- There should be no research or figuring out required after the skeleton is completed (ideally)
|
|
- Build initial framework first with all the "non functional requirement" (everything but the actual business classes) specific features in it. Take a snapshot so it can be the basis for other projects in future.
|
|
- All tools should be in place
|
|
- Development tools
|
|
- Testing tools
|
|
- Once we have something to test look into something like: https://jenkins.io/solutions/docker/ containerized?
|
|
- Unit
|
|
- Integration
|
|
- Load
|
|
- Building tools
|
|
- Once we have something to build look into something like: https://jenkins.io/solutions/docker/ containerized?
|
|
- Releasing
|
|
- versioning
|
|
- updating
|
|
- containerization
|
|
- All database types
|
|
- Installer / installation
|
|
- Management interfaces or tools
|
|
- BACK END API
|
|
- Sample routes with two api versions (0 and 1.0)
|
|
- ideally a small sample of code showing all the layers of code involved with all the NFR features desired like circuit breakers you name it
|
|
- Users and Client for starters with a list of clients, a client entry and edit and delete
|
|
|
|
- dependency injection / loose coupling
|
|
- https://joonasw.net/view/aspnet-core-di-deep-dive
|
|
|
|
|
|
- Upgradeable
|
|
- Versionable
|
|
- Circuit breakers
|
|
- Performance and other metrics and logging
|
|
- All the NFR in the PROCESS and BEST PRACTICES section of my coding-standards doc
|
|
- UI Skeleton to support this backend skeleton
|
|
- All NFR that are UI level (a SPA web application)
|
|
- UI concerns that may affect back end stuff should be in the skeleton
|
|
- The guts of the UI presentation host whatever it's called without the actual specific bits to the app
|
|
- Loading
|
|
- Upgrading
|
|
- Handling errors
|
|
- talking to the api
|
|
|
|
- TESTING
|
|
-
|
|
- Smoke test first in a limited test VM that simulates a droplet of 512mb ram, 1cpu, docker container with db etc
|
|
- Test in a DO droplet under load with lots of data and see what memory and cpu and disk resources are required and how it performs
|
|
|
|
|
|
|
|
|
|
## FR CODING
|
|
- After the above move on to functional requirements coding
|
|
- Test and deploy daily at least
|
|
|
|
|