analysis and reflection - ppouke/PWP GitHub Wiki
📑 Chapter summary
In this section we would like that you reflect about the work you have done during the course.- Reflect about own learning
- Feedback on course instruction
✔️ Chapter evaluation (max 4.5 points)
You can get a maximum of 4.5 points after completing the Analysis and Reflection section.📑 Content that must be included in the section
Explain how you would improve your RESTful API and your client application. Try to develop the ideas, and explain why each improvement is needed✔️ Evaluation criteria(max 1.5 points)
- Future work is provided and carefully thought out: 1.5
To improve the API we would add profiles for users so it would be possible to keep track of your finished games and scores. There could also be high-score list that would show who is the best Blokus-player. There could also be separate block collections so users could choose what kind of blocks are included in each game. We would also add a possibility to spectate a game. This would only need changes in the client as our API already has possibility to just view game state without participating. Some automation could be added. For example when player does not have any possible moves left they would be automatically kicked off from the game or turned into spectator. Adding round timer would make it impossible to stall the game as you would lose if you didn't place a block during certain time frame.
📑 Content that must be included in the section
Discuss in this section the things that you would have done differently if you started the project after this course ends.✔️ Evaluation criteria(max 1.0 points)
- A short reflective description of what was learned while working on the project 1.0
The project subject wasn't necessarily the best choice of application for the RESTful-api. It could be made simpler using some other architecture type, for example RPC. The API design could have been done more thoroughly before starting implementing the database or the the API itself. We had to go back to edit both the design and the database multiple times as we noticed some errors we had made during the design phase.
📑 Content that must be included in the section
Comment where you encountered the main difficulties while doing your project work. Discuss about the easiest/most difficult parts of the project. Provide convincing statements.✔️ Evaluation criteria(max 1.0 points)
- A short reflective description of the easiest/most difficults parts of the projects 1.0
Most time consuming and the hardest part of the project was implementing and testing the RESTful API. Even though we didn't have that many resources the interactions between them were pretty complicated. This resulted into lots of trial and error. Thus testing had to be very meticulous it took lots of time and effort to reach adequate coverage. The relationships in the database also provided some hardships as we changed the design after the initial implementation and we had to restructure almost everything in the database.
Easiest part was creating the client UI and communication with the server as the API was quite straightforward to use.
📑 Content that must be included in the section
Make sincere comments about the course. How this course could be improved? What should be changed? What should not be changed?✔️ Evaluation criteria(max 1.0 points)
- Useful course feedback - what we should change, what we should keep: 1.0
The deadline system of the course was good and should not be changed. It kept the students on track and the workload never became too overwhelming. We felt that the database implementation should have been done only after we had finalized our API-design as we had to do multiple changes on the database afterwards.
| Task | Student | Estimated time |
|---|---|---|
| Juho Kalliokoski | 2h | |
| Elmeri Uotila | 2h | |
| Sakaria Pouke | 2h | |