This Week
This week, I continued developing the Rank-Based System, mainly focusing on the Rank Judge module. After testing the drag-and-drop functionality, I confirmed that it works well even when using a laptop touchpad. The list automatically scrolls while dragging, allowing judges to move participants from the top to the bottom of the ranking list smoothly. This works together with the thumbs up/down feature, giving judges multiple ways to rearrange rankings.
During development, I accidentally introduced a new object (rank:<eventId>_<judgeId>) to store ranking submissions. After reviewing my pull request, Dr. Shawn explained that creating a new object was unnecessary because the project already has existing mark and result objects that should be reused. I then refactored my implementation by removing the unnecessary rank_obj and using the existing project structure instead.
I also worked on adapting the existing Mark Page for the new judging workflow. At first, I assumed the scoring slider should simply be removed for rank-based judging. During the weekly meeting, Dr. Shawn explained that the slider is actually controlled by existing judging criteria, and if rank-based judging is configured correctly, it should not appear. He advised me to spend more time understanding the existing codebase instead of making assumptions, especially since I have been working on the project for almost six months.
Another discussion during the meeting focused on improving the ranking interaction. Dr. Shawn suggested adding a swipe gesture that allows judges to temporarily exclude a participant from ranking. This would be useful if a participant is the judge’s own student, helping to reduce bias. When a participant is swiped, the entry becomes greyed out and cannot be ranked or commented on. The backend will then automatically handle the missing ranking appropriately so the final results can still be calculated fairly without affecting other participants.
We also discussed ensuring that judges’ comments are first saved as browser drafts before being submitted to the server in bulk. This allows judges to write comments for multiple participants without immediately sending each change to the server, improving both performance and user experience.
Besides development, I travelled to Miri to support another two-day competition involving drums, guitar, vocal, drama monologue, and storytelling categories. As usual, I handled the technical setup and provided on-site support throughout the event.
During the competition, I encountered a few technical issues. One was that the event logo did not appear correctly, and Dr. Shawn assigned me to investigate the issue after the event. Another issue occurred when judges heavily used the AI comment feature, causing the API quota to be reached. Fortunately, the debounce feature I had previously developed worked as expected by displaying the cooldown timer instead of allowing repeated requests. To better support the event, Dr. Shawn upgraded the model from Gemini 2.5 Flash Lite to Gemini 3.5 Flash Lite, which provides a higher request quota. After the upgrade, the system ran smoothly without crashes or performance issues.
This was also my second-last live event during my internship. It was another memorable experience, and I am truly grateful to Dr. Shawn for giving me the opportunity to learn, contribute, and gain real-world experience throughout these competitions.
Challenge
One challenge this week was understanding the existing project architecture before introducing new implementations. I initially created a new ranking object without realising that the project already provided suitable mark and result objects.
Another challenge was understanding the existing judging workflow, particularly why the scoring slider remains part of the interface in a rank-based system. Instead of removing features immediately, I needed to understand their purpose within the overall judging process.
Solution
After receiving feedback from Dr. Shawn, I refactored my implementation to reuse the existing data models instead of introducing unnecessary new objects. I also spent more time studying the existing codebase before making further modifications so that new features remain consistent with the project’s architecture.
For the AI quota issue during the Trinity event, upgrading to a higher-quota Gemini model successfully resolved the problem while allowing the debounce mechanism to continue protecting the application from excessive API requests.
Reflection
This week reminded me that good software development is not only about implementing new features but also about understanding and extending an existing system correctly. Reusing existing components whenever possible results in a cleaner and more maintainable codebase.
It was also rewarding to see one of my previous implementations; the debounce mechanism—working successfully during a real competition. Watching the feature handle API rate limits as intended gave me confidence that my work can provide practical value in a production environment.
Next Week’s Plan
- Investigate and fix the Trinity event logo issue.
- Continue improving the Rank-Based System based on the latest feedback.
- Complete the remaining tasks before my internship ends.
- Prepare for the upcoming Trinity competition on 8th–9th August at Sunway University Sunway Square.
0 Comments