# 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. - Read through and triage Joyce's notes and docs for her v8 work. - I've re-written them all out sorted by last edited date - This will then be gone over more deeply as input into the later stage of feature development below - Go through AyaNova and all it's add-on's and put major feature areas into a list in features.txt - Then, go through all cases and all of Joyce's v8 docs for that item / area and create a document for each feature area - Fill in with the features and changes to that item in order of implementation - IMPORT: Important that I also document how existing data will be imported for this feature - If a completely new feature is determined then it needs to be in there as well (tags) - 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