Sprint 5 Retrospection | Rohan Bojja

• 5 Main Parts over 12 weeks
• Burn Down List and Planning
• Frontend Creation / Fetch Request
• Creation of an API / Postman Testing
  • Using Postman for Raw API Testing

CRUD Implementation / Frontend to Backend Full Stack

Assistant Deployment Admin Role / Deployment Blog Records

5 Main Parts over 12 weeks

1. Burn Down List / Planning / Figma
2. Frontend Creation / Design / Fetch Request
3. Creation of an API / Postman Testing
4. CRUD Implementation / Frontend to Backend Full Stack
5. Assistant Deployment Admin Role / Deployment Blog Records

Burn Down List and Planning

By using this burn down list, I was able to quickly go through multiple tasks and make sure I was on point with everything I did, and progress through the feature effincently.

I was the creator of the FIGMA design at the beggining of the UI deisnging planning. I made sure to make a workflow between all the pages and give a chance for all team members to customize their own page. This is where I learned how to have a cohesive UI design on the frontend.

Frontend Creation / Fetch Request

The CSS for the Frontend was updated finnally to this version. This is vital to the website because it allows for a cohesive UI, which allows for the user to want to interact:

I have also worked on the frotnend fetch request to the abckend API. Before this iteration, I autommaticcly did all the work in the frontend, even with the api sourcing, however, I learnt that using the backend is much more efficent, espically when needing the model file.

Creation of an API / Postman Testing

This is the API code, which I have iterated after the frontend api source, and put it in the backend. As you can see, it shows the sourcing of the API, even with the token, and checks if all the information enccesary is validated.

Here is the Postman testing, where I have tested this all for abckend functionality, before any Full stack completition. This is vital to make sure there are no conflicts with post functions, and making sure it all gets uploaded to the database.

Using Postman for Raw API Testing

URL: http://192.168.1.10:8887/api/flight

• Request: Example of a POST request to create new data:

    {
      "origin": "LAX",
      "destination": "DEN",
      "note": "Buisness Trip"
    }
  

• Response:

    {
        "destination": "DEN",
        "id": 4,
        "notes": "Buisness Trip",
        "origin": "LAX"
    }
  

• Request: Example of a PUT request to update data:

    {
      "id": 4,
      "origin": "LAX",
      "destination": "DEN",
      "note": "Buisness Trip"
    }
  

• Response:

    {
        "destination": "DEN",
        "id": 4,
        "notes": "UPDATED NOTE",
        "origin": "LAX"
    }
  

• Request: Example of a DELETE request to delete data:

    {
      "id": 4
    }
  

• Response:

    {
        "message": "Flight deleted successfully"
    }
  

• Error Responses:
  • 400 Bad Request: If required fields are missing.
  • 404 Not Found: If the endpoint is incorrect.

CRUD Implementation / Frontend to Backend Full Stack

I have implemented CRUD features, create, read, update, and delete, for the user to completely interact with the feature itself, mainly through the posts of flights, and itneracting with the notes made on the flight. Attached are the four functions.

I have also done full stack implementation, as for example, you can see with the notes feature in the frontend code. You can see the post function, update function, and delete function, that all cals the crud functions from the abckend, that were already previously tested with postman.

Assistant Deployment Admin Role / Deployment Blog Records

As the Assitant Deployment Admin, I was in charge of the deployment blog, where I had to keep records on DNHS, ngnix files, docker files, and list out the steps in order to recreate if neccesary. (https://kiruthic-selvakumar.github.io/travel_frontend/2025/02/02/deployment_blog.html)

Category	Max Points	Self Grade	Explanation
DOCSE	5	4.61	My five main things, planning, frontend creation, api creation, crud implementation, and deployment assitant admin roles, were all throughly explained throughout the blog, and supported with images and screenshots of work proof. I beleive this deserves a 4.5 because of the implemntations of the API showing iteration from the very first couple of times they were integrated, from just onto the forntned, into a seperate file in the abckend, to being inputted into model files to create a database.
Full Stack Project Demo	2	1.8	The demo covered all of the required CPT requirments, and showed a functioning CRUD output and input, fetch request to the outsourced API, and unique output of all the listed flights, that eases the user. However, the reason this doesnt earn anymore than a 1.75, is because of its simplicity, not only with the user. It could be improved in terms of complexity with who edits what entry, and although it is mainly meant to be a public feature (e.g. to display delay times), it may be beneficial to add admin roles, when I recently though that wasnt neccesary.
Project Feature Blog	1	0.9	The blog, along with CPT/FRQ lanugage, and while sourcing the Big Ideas, clearly explains the proccess of how to do Full sTakc implementation, testing with postman, backend database inquires, and other methods that college baord requires us to know. I made the blog throughough with adding visuals and screenshots to show proof of concept and functionality.
MCQ Review & N@TM	1	0.9	Although my perofrmance on the MCQ was slightly above par for myself, I would still like to improve in the areas we’ve discussed. I still gave a 0.9 due to the thorough review of the MC, where everys ingle incorrect quesiton was restated and reasoned throguh. For the N@TM, I also went ot three differnt booths and took notes, interacting with the hosts, and showing proof of visiting. I also analyzed our results from our interviewers and people who stopped by, where we scored higher than an average rating, showing the attrativness of the features.
10th Point (Retrospection)	1	0.9	Not only as being an Assistant Deployment Admin, but I also feel I was always consistent with presentations. Whether it be with reviews with Mr. Mortneson, or also helped our scrum master take head of the Kanabn board, I have since been an integral part of the organization of the team. Likewise, I have created the majority of the Figma, which was key to cohesive UI designing. I created records of the deplyoment blog with file reords, important DNS information, and updated it with steps throughout the proccess.
Overall Score	10	9.11	For next steps, when working on this feature in the future, I would like to implement more unqiue CRUd features, such as a calender, etc. I would also like to apply my knowledge ot intenrships, as I am also doing currently with molecular dynamics and python. I would also like to carry forward by deployment skills by attempting to deploy a website creation of my own in the future, which could be beneficial to my own learning, while also putting my skills to use to show future interviewers and even friends.

Strengths:

• intitive with planning
• keeping notes and records during tech talks and dpeloyment
• Presenting my work - able to get the point out

Weaknesses:

• Working until last minute
• Lack of review of other fellow features