analysis and reflection - LassiHeikkila/taskey GitHub Wiki

Important information for final deadline

‼️  This chapter should be completed by final deadline (see course information at Lovelace)


πŸ“‘  Chapter summary In this section we would like that you reflect about the work you have done during the course.

SECTION GOALS:

  • Reflect about own learning
  • Feedback on course instruction
In this section we are going to evaluate also the project management


βœ”οΈ     Chapter evaluation (max 4.5 points) You can get a maximum of 4.5 points after completing the Analysis and Reflection section.

Analysis and reflection

Future Work


πŸ“‘  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

As noted in the meeting with course staff, the API is not entirely following RESTful hierarchy, with endpoints being under .../{organization_id}/... rather than .../organizations/{organization_id}/.... That would be a good to make the API follow the principle of least surprise. In general, things should be done in a standard way when possible so its easier for others (and original implementer after some period of time) to follow the train of thought that was driving the original implementation.

There are a few missing or unimplemented features in the API, like changing passwords or inviting new users to an organization, so those should be added if this were ever put into real use.

The API could be a really good fit for incorporating a real-time communication mechanism, e.g. for signaling information about changed schedules or task definitions from server to machine, and for server to notify human users about events such as failed tasks.

Webhooks would also fit in well, e.g. for alerting on failed tasks or non-communicative machines, but it is not exactly API related, just generally related to the project.

Lessons learnt


πŸ“‘  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

Working on a large-ish project by myself was fun, but scope of the project was probably a bit too much for one developer.

Documentation should also be written while developing or even starting it before implementation, rather than tacking it on at the end.

Comments about the project


πŸ“‘  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

Single most challenging task was to make CORS requests work via a browser. Even with plenty of documentation to read, it just seems like some magic that the browser is doing sometimes and I didn't really manage to get a grasp of how it all is supposed to work. Luckily StackOverflow exists and I was able to proceed.

Other challenging aspects were designing HTTP middleware and other requests handlers in a way that using them felt natural or didn't get in the way. I did a couple of re-writes of the first few before getting a hang of how they should looks like.

Comments about the course


πŸ“‘  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

I really enjoyed this course. Huge thumbs up πŸ‘β­πŸ‘β­πŸ‘

Probably having more than one person running the course would be better in the long run to avoid burning out. Hard to say from my perspective what the workload was like, but I can't imagine it being too easy.

Lovelace code checker test cases would also be nice to be able to view, rather than having to guess what went wrong when the checker crashes and doesn't print any errors.

Resources allocation

Task Student Estimated time
Filling in wiki for DL6 Lassi HeikkilΓ€ 0.5h
⚠️ **GitHub.com Fallback** ⚠️