This week, I presented my idea for detecting shared judge logins to Dr Shawn, revised it based on the feedback, and submitted a final proposal. At the end of the week, I also helped at an event at Da Men Mall, which was the first event to use the code I have developed for the admin app.

Rethinking My First Approach

My first idea was to create a backend API endpoint that gets device or session IDs from another project, so the system could tell when the same judge role is logged in on two devices. When I discussed it with Dr Shawn, I learned that this approach was not realistic, as connecting the two projects this way would be difficult. Dr Shawn encouraged me to study the project’s current technology more deeply before proposing another solution.

I then researched CouchDB, the database used by our project. Unlike a traditional database that stores data in tables, CouchDB is a NoSQL database that stores each record as a JSON document and provides a built-in HTTP API for reading and updating those documents. This helped me understand what data was already available in our system and how it could support a warning, even if it could not prove for certain that a judge role was being shared.

Finding a Practical Solution

With a better understanding of CouchDB, I focused on a solution that could be built within the current codebase at a reasonable cost. Instead of trying to identify which device a judge is using, the system will look at a document’s revision count. In CouchDB, every time a document is updated, its revision number increases. If a judge’s mark has been saved more times than a set limit, it may be a sign that the judge role is being shared, so the app will flag it and show a warning.

I submitted the final proposal as a GitHub issue in the Sayembara admin app. Dr Shawn reviewed it and said the idea is feasible, while noting that it could still be improved as we build it.

However, it was later replaced by a better approach, which I implemented the following week.

Event Day at Da Men Mall

At the end of the week, I worked as an event assistant at Da Men Mall and helped set up the devices. While preparing the judge and emcee laptops, we found that our app kept showing a blank page in Microsoft Edge’s kiosk mode, a locked full-screen mode. We fixed it quickly by exiting kiosk mode and opening the app in Chrome instead, and the rest of the event ran smoothly.

This event meant a lot to me because it was the first one to use the code I have developed for the admin app over the past eight weeks. Seeing my work used at a real event was very rewarding. It also reminded me how a small setup detail can cause trouble, and how important it is to stay calm and find a quick workaround.

Next Week’s Plan

Next week, I plan to start implementing the warning system based on the approved proposal. As the feature takes shape, I will keep refining the approach based on Dr Shawn’s feedback, so that the final solution protects judges’ marks as effectively as possible.


Categories: Experiential

0 Comments

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.