This week, as a mentor, I kept up with slides and attendance, which is good practice for talking in front of an audience since I’ll have to do that for the workshop. I made sure to ask plenty of questions about what to do in certain situations as a mentor, and some of them came up, like how I should still grade status updates even if they’re over the 2 day limit. I’ve gotten more familiar with the project leaders in my room, including a new one from the IBM Quarkus group, which is great because now it’s easier for me to keep in mind if I need to talk to someone in their group, even if that person hasn’t shown up, since I can ask the group leader to pass a message along. This came in handy when I graded a status update that came with a technical blocker, so I talked to the Elara group leader Jackie even though the particular student wasn’t in on Tuesday. As a student, however, This week I got to know the code base better and started working on my first issue, where shuttles would become unlabeled in certain areas along their routes. I started working on figuring out how to replicate it, but soon found out that the test servers were too limited to be able to recreate the bug, so I had to study the live server extensively in order to find examples happen in real time. It wasn’t long before I decided that it was too difficult and time consuming to use the live server to debug because not only would it take 10 minutes between possible instances of the bug occuring, but with no debug log, I couldn’t know why certain things were happening.

Next week, as a mentor, I plan on continuing to present slides and handle attendance of course, not just because it’s good practice, but because I might need to ask one of the other mentors to cover for me, which will be fine because they know I handle it for the most part. I also will be keeping a close eye out for future technical blockers that students may have, as it’s important that I find out what problems they may be having before the next class with them. Even if I don’t have time to grade all of the status updates, it’s simple enough to just cycle through all the submissions and see if any of them had blockers that I should address. As a student, I plan to expand the test server’s capabilities by creating an admin site for shubble that will allow for developers to take real shuttle data and import it into the test servers. There will be many other features for the admin site, but for next week I will focus on making the dockerfile for it, as well as implementing password authentication for 3 different roles. I’m not entirely sure how I’ll handle the different roles having different privileges, but it’ll probably be either I take a role and password, where the backend will handle sorting out which is which, or I’ll make separate login pages for each role and that’ll be easier.