For this sprint, I worked on several different tasks to improve the project. Firstly, we needed to get the project hosted onto Heroku, so I added some of the dependencies that Joshua Farrar had created in order to allow it to be deployed directly from GitHub. There were also some minor bugs that needed to be fixed such as typos, missing new line characters, etc. Next I worked on adding build instructions to the readme by working through installing the project on a clean windows install on a virtual machine in order to figure out every dependency needed to be installed. Then I added a landing page to the project which contained a list of all of the available endpoints, however this was a very bare bones solution as it was just a list of the endpoints with no further information. We decided to integrate Swagger 2 and Swagger UI to automatically create more description documentation containing endpoint descriptions as well as a UI to test the endpoints. There was also a minor issue where the example model of the object returned by the endpoint was showing up as empty. This was due to the way the endpoints were returning objects (showing the model of the “Object” class rather than the actual classes being returned).
From what I understand, Swagger gathers the endpoint data in the same way that I did, however, it’s far more detailed and robust. I think if I were to do something differently in this situation I think definitely I would do more research into the possible alternatives to solving each task in order to figure out what the best solution would be before starting to work on it. Had I initially looked into Swagger prior to starting to work on the landing page, I would have saved a lot of time. This is something that I should take into account for the future as it will be important to avoid wasted time whenever possible.
When making the build instructions, I think using a virtual machine to start from a clean slate was definitely the best course of action, as it’s important to see what it’s like for someone who potentially started from that state to get the project up and running. By doing this, even people who already have some of the dependencies installed will be able to follow through the build instructions by skipping steps that they’ve already installed. Although, I hadn’t considered the difference in the installation process between Windows devices and Mac/Linux devices. This project in particular doesn’t require many dependencies to get started, so it’s not difficult to create combined installation instructions, but I think for larger projects it would be smart to separate them. One of the differences I ran into was including the installation of Git Bash while Mac/Linux devices would be able to just use command line.
For the next sprint I’m hoping to automatically update the version number whenever necessary, as it’s definitely bad practice to have to update it in 4 different locations every time. Also, it would probably be a good idea to add an endpoint that gives you a products maximum shelf life and best storage method, given what the data would probably be used for.