Week #5 #
Feedback #
Sessions + Analysis #
Meeting With 319
We view the 319 university team as the most likely maintainer (people who will manage and moderate the system) of the university’s instance of EvOps. The meeting was attended by Arsen and Asqar from the EvOps side and Leysan Islamova, Evgenia Dujakova, and Arina Talan from 319. During the session, we presented the idea and discussed these topics:
- General plan of our implementation.
- Preferred features of the app (e.g. tutorials, calendars, etc.).
- Content moderation by maintainers.
- Integration to the ecosystem.
- PR among students.
The team supported the idea and showed their interest. At the end, we decided on our vector of development and discussed potential future meetings after creating the product.
Meeting With the Software Department
One of the most crucial points discussed with 319 was integration into Innopolis University’s ecosystem. To explore this area further, we conducted a meeting with an employee of the Internal Development Department, Timofey Sedov (hello 👋). The session was focused on possibilities of integrating EvOps into the My University service and the IU ecosystem overall from the technical viewpoint. Some discussed topic include:
- Future plans for EvOps and IU ecosystem development.
- Technology stacks.
- Technical support of EvOps in the future.
During the discussion, we agreed that My University already has some functionality we were planning to develop. All in all, we settled on that possibly just part of EvOps’s functionality is going to be integrated into the university, which in turn gave us more freedom and flexibility.
Surveying Students
While we haven’t deliberately conducted any other meetings with potential users, we’ve used some chances to talk about EvOps with people casually. For instance, we’ve listened to opinions of active students and what they would expect from a system like ours. In general, we’ve already thought through most of their ideas.
Iteration & Refinement #
Implemented features based on feedback #
Although we haven’t yet implemented the discussed features, they are waiting their turn in the backlog while we implement the core functionality. Here are relevant issues:
- Moderator service ( issue).
- UI customization by maintainers ( issue).
- Telegram parser for new and existing events’ ( issue).
- Event Calendar ( issue).
- PWA ( issue).
Performance & Stability #
We have no worries about our back end’s performance. It is both highly robust and blazingly fast. Some reasons behind include:
Rust, as the fastest language suitable for back-end development (Zig is too young, C++ is just 💀).
- Its type system and libraries (e.g.,
nutype
) effectively guarantee the absence of runtime bugs for most cases that would need more careful handling in other languages.
- Its type system and libraries (e.g.,
Asynchronous APIs that don’t block while serving requests. Also, our async runtime (Tokio) is multithreaded, which leads to true parallelism.
PostgreSQL, as the fastest mainstream DBMS.
- It is shared between the main server and the ML server to avoid unnecessary data transfers through the network.
Diesel, as the fastest type-safe library to communicate with the database.
A gRPC-based API to avoid the overhead of serializing/deserializing JSONs.
Careful design of our systems, avoiding unnecessary clones and allocations.
The website, written with Next.js, utilizes server-side rendering to avoid increase load times. Soon, we will add request/response caching to avoid unnecessary calls to the back end.
Points of Android app performance efficiency:
- Kotlin: Native performance with smooth animations and quick responses.
- Efficient API calls: Loads data only when needed (first launch or user request), not on every screen switch.
- Image caching: Coil library caches all the network images, so they load instantly after the first load.
- Optimized state management: No reloading on screen rotations, theme changing, or screen switch.
Documentation #
Right now, our repositories have simple README
files with build instructions.
All of our back-end methods are documented with an autogenerated OpenAPI schema + Swagger UI. Additionally, our gRPC API is documented with doc-comments, often respected by code generation utilities.
ML Model Refinement #
To evaluate the recommendation system model and choose the hyperparameter lambda
(profile = good_profile - lambda * bad_profile
) and weights for the user’s
interactions, we have chosen the MovieLens 20M dataset
(
link)
that contains film ratings from users (from 1 to 5 stars). Reviews with a rating
of 3 stars or higher were considered relevant for a user, and the rating itself
was chosen as an interaction. The users were selected based on 99.99
percentile of the total number of reviews (around 76000 entries).
For each user, the good profile was constructed as a weighted sum of the embeddings of films with corresponding ratings of 3 or more stars; on the contrary, the bad profile was constructed from low-rated films.
The lambda parameter was taking values from [0, 2]
with a step of 0.1
, and
the weight for the interaction was being chosen arbitrarily. Metrics such as
NDCG@k
and RR
were increased significantly for the values around 1, and it
was observed that good and bad interactions should have approximately the same
absolute values. Such observations were accounted for in the recommendation
system service class.
In the future, this model may be improved using the actual users’ data from our application.
Weekly Commitments #
Individual Contribution of Each Participant #
Aleksandr Isupov #
- Updated Android data models to match the new backend ( commit).
- Integrated image posting into the Android app
(
commit):
- Added new UI components for image selection and preview.
- Implemented a multipart API method for image uploads.
- Added URI-to-File conversion for the image picker.
- Fixed the unsaved state issue on the Create Event screen ( commit).
Arsen Galiev #
- Updated the logic for fetching images from the back end on the website ( commit).
- Designed a new icon/logo ( commit).
- Found a new color theme for the website.
- Integrated TanStack ( issue).
Asqar Arslanov #
- Fixed gRPC image streaming from the back end ( commit).
- Fixed the website not building due to type errors ( commit).
- Configured the ML server’s build environment ( commit).
- Fixed the interaction between the back-end and ML servers ( commit).
- Updated the structure of
dummy-data
( commit 1, commit 2, commit 3). - Added CORS-preflight requests handling to the back end ( commit).
- Made the back end wait for the ML server ( commit).
- Small contributions:
Egor Pustovoytenko #
- Finished the ML server implementation ( commit).
- Implemented an ML client for the back-end server ( commit).
- Refactored the client extension for backend-to-ML communication ( commit).
Ilya-Linh Nguen #
- Updated the CD file for the new architecture of services ( commit).
- Finally finished with the
dev
andhmr
Dockerfiles for better DX and added new Docker Compose profiles ( commit). - Introduced a small Docker fix in ML and the Compose files ( commit).
Maksim Ilin #
- Implemented the recommendation system service class ( commit).
- Augmented the dummy data with the 1700 posts from the “Opportunities For You” telegram channel ( commit).
Ramil Shakirzyanov #
- Tested and benchmarked VRAM consumption and speed of different tag generation model configurations ( commit).
- Tested and benchmarked VRAM consumption and speed of different RecSys embedding model configurations ( commit).
Plan for Next Week #
DevOps #
- Close issues regarding Dockerfiles (healthcheck).
- Buy and set a domain.
- Refactor CI/CD actions.
Machine Learning #
- Implement the machine translation feature.
- Make the tag output for the auto-tagging model gradual.
Back End #
- Prepare the database for the recommendation system.
- Expose the recommendation system through the ML server.
- Add authentication.
Android #
- Update Create Event screen to include new fields: tags, location, date & time (depends on the back end).
- Integrate new fields to the Event Details screen (depends on the back end).
- Make the search field on the Event List screen functional (depends on the back end).
- Add validation to the Event List screen form.
Website #
- Paginate the event feed.
- Add authentication and guards.
- Create a PWA.
Confirmation of the Code’s Operability #
We confirm that the code in the main
branch:
- Is in working condition.
- Runs via Docker Compose.