Anonymized Mapping Project X/Y
Thinking about this Project X/Project Y revision with respect to options and constraints over the past couple of hours and came up with this.
First an alternate option not discussed for Project X/Project Y - Create a Universal Windows Application with Xamarin or multi platform application for Android, iOS, mac OS that would display maps and grid. Could do the same thing with React Native, but that would entail more working the application under the limits of web components (much more work in my opinion compared to tested and available Xamarin community).
This option should not be overlooked as a valid option because
- Native applications would offer speed, reliability, and render improvements that web applications are forever trying to reach especially with respect to grids and graphics (in this case maps)
If the requirement by the customer is to continue as a web application then the following were presented
- Considerations are to keep the look of the user interface for Project X and integrate Project Y functionality also there is a set functionality to continue (yes?) and expand upon it in a limited manner? These details were not discussed in detail for me to think about the changes other than take some core functionality of Project Y.
Restrictions are on a set hour time 560 which is 70 person days so this is expected to be done sometime first week of June 2017 if started next week Monday by 1 person.
In this case I actually think that stretching the time on the delivery is good in that it gives more time for consideration of what is essential in Project Y before starting work and gives a longer time to think about a task in an extremely focused manner.
Example I am thinking is that we are trying to write a novel and it is not going to be efficient or productive to write the chapters out of order and by different people especially when the characters and events are not agreed upon (I am saying characters/events are messaging and unit tests in this example)
This is a problem encountered in rewrites before because of the limited test code supporting our current applications as is requires a deep and long process of re-evaluation of what certain things should do versus if a test with input and output is meant to clearly illustrate expected behavior. Alternative I could think of is numerous people could write the full test suite simultaneously, but that would lock in technologies perhaps too soon without spending any time considering and reevaluating and examining what has worked in previous projects and should be retained and what can be implemented better for large increases in maintainability and efficiency.
Clearest example I can think of this Project Y uses MapXtreme single image maps which are not the fastest or responsive, but later we experimented with and learned to use composed slippy tile maps which render a portion of the screen. Items of experimentation and learning like that are where huge improvements can be made versus tiny marginal improvements.
Examples I am thinking of that other companies made monumental improvements with after adopting were
- Unit Tests
- Continuous Integration/Continuous Deployment
- Event Sourcing
- CQRS architecture
- Vector tiling
- Docker containers
- Automating deployments
- Caching, CDNs
Following a plan something like this
- Continue using Dojo/Dijit - Upgrading to React/Redux will consume the entire budget is consistent with other rewrites - Server code is faster and more reliable to write than client. Dojo/Dijit is mature and easiest way to preserve the look and feel is not to mess with it and simply upgrade to Dojo/Dijit system. The Dojo/Dijit web framework is event based and organized well with documentation and can be tested easier than other frameworks because of that.
- Create auto deployment system for application
- Decompose application pieces
- Create auto deployment system for decomposed application
- Write unit tests for Services API of Project Y as separable
- Include unit tests as requirements for application build/deployment must pass tests to deploy
- Write all Project Y data messaging that is being moved forward
- Replace OpenLayers 2.X with Leaflet - This will give the map a current refresh
- Avoid all database changes if possible
- Deliver application with this functionality
In this case this is actually work that could probably be achieved before going over the budget and I think delivers what the customer would like while spending time decomposing the application means unit test code can be written and each piece replaced without worry for functionality.
Example if the application service layer is decomposed and has tests for functionality if there is time remaining that service layer component can be replaced. As all the components are loosely coupled and expected to communicate in expected formats it doesn't matter if the JSON code for the service layer is written in NodeJS, C#, Golang or if it runs on Linux or Windows or both. The message data format, protocols and ports specify the flow of the application and with passing test coverage and automated deployment. The events along the workflow of business logic can be verified and are expected to work, much like if you have a car you can change the motor from say a V6 to Inline 6 or possible a V8 these are all different motors internally but if they fit in the engine space and you hook up the crankshaft right your car will run. Less drastic example is converting to biodiesel, your car still moves even if the explosive liquid it runs on is a different formula.
Event Sourcing - Excellent for locking a legacy application and building new functionality easily
Found IIS authentication options