3rd of Map2Online sprint completed
In fact it was not a real sprint, as the achieving the next level of functionality, but rather it was the eliminating of the technical debt from the previous sprints, some researches and code refactoring. This sounds terrible and definitely means wasting the time, but i never hesitate to make such delays in the very beginning of the project – to do not let the wrong decisions made on very first phases to hurt the whole project as they will only grow. And the second reason why this brief is necessary is a team building. The developers must have a chance to stop coding and look around: how the others work, why we have made some decisions and assumptions an are they still good or should be changed.
It is not easy time to communicate with the client as well: he just passed the long way of signing contract, discussing, planning, money talks and is urgent to see the result. Moreover he used to see the fast progress of the first week then we were adding the more or less standard and well know features.
But now we are starting to create the framework of the application with lot of the code not producing visible changes, we are inventing the LEGO details to use in the future, but looking like… like nothing to the client and it is very important do not let him become unhappy. We will start moving fast the the LEGO details will be ready but the client will not become as happy as he would be without the drop of the visible performance on the 3-rd week.
And because of that we are building our models around the UI component to show the elements of the travel project: list of projects, routes and placemarks.
This structure reflects ~75% of the functionality and binding the in-memory models to this view we will provide the daily visual feedback as if it would have been the real functionality. In the ideal situation i would have skipped this step and preferred to build the backend and testunits in order to have 80% ready models before the switching back to UI. But in this specific case, in order to get funding, there will be in-memory mock models bound to UI and only then we will start to add the backend functionality.
This will cause ~10% increase of the duration but will get a bonus of high quality code with the models abstracted from the backend apis. This will let me to change the network protocols from the JSON-RPC api to the API build around https://www.arangodb.com/ we are investigating and testign right now.
And in the end the few words about react-sortable-tree – it was used in the previous project and showed as absolutely perfect React Component made the guys who know that the perfect LEGO block is. It is not easy to use, and is not that you can simple drop in the code, but it have lot of necessary hooks and customization that let us not to be stuck some day with the problem we could not predict and are not able to solve.
There’s another good (i’d say perfect) component the we looking at: Atlassian react-beautiful-dnd – as a former Atlassian developer i always prefer to stay with that brand and the component is really beautiful both from the developer’s (although the documentation is a bit misleading when suggest to putt the context around the app component) and user’s point of view but we need nested drad-n-drop and this the reason why Sortable Tree won the game.
