Playlog is a social platform designed for gamers, offering a range of features to enrich the gaming experience and foster community interaction. Serving as a centralized hub, Playlog allows users to explore, catalog, and engage with their favorite video games. Whether you're a casual player or a dedicated enthusiast, Playlog provides an immersive environment with an extensive library of games to discover and connect with fellow gamers.

A standout feature of Playlog is its semantic browsing, allowing users to explore games based on properties like genre, platform, and developer. This approach enhances game exploration by providing deeper insights into the gaming landscape. Additionally, users can participate in the gaming community through features like reviews, ratings, and personalized lists, fostering social interaction and engagement.

Playlog focuses on making gaming easy, safe, and enjoyable for everyone. We follow industry standards to keep your data secure and the platform running smoothly, even during busy times. With Playlog, you get a complete gaming experience that's easy to use, lets you connect with others, and lets you explore games that match your interests.

Our current implemented, tested, and deployed version of Verilog satisfies most of the core requirements of Playlog we started with. Here are the requirements that are 100% implemented:

• 1.1. User
  • 1.1.1. Registration and Login
    • 1.1.1.1. Guests shall be able to register to the application by providing their email, username, and password.
      • 1.1.1.1.1. Provided email and username shall be unique. (Fully implemented)
      • 1.1.1.1.2. Provided email shall be valid (i.e., of the form [email protected], [email protected], etc.) (Fully implemented)
      • 1.1.1.1.3. Provided username shall be at least 8, at most 16 characters. (Fully implemented)
      • 1.1.1.1.4. Provided username shall only include letters, digits, and underscore. (Fully implemented)
      • 1.1.1.1.5. Provided username shall start with a letter. (Fully implemented)
      • 1.1.1.1.6. Provided password shall be at least 8, at most 32 characters. (Fully implemented)
      • 1.1.1.1.7. Provided password shall include at least 1 lowercase letter, 1 uppercase letter, and 1 digit. (Fully implemented)
      • 1.1.1.1.8. Guests shall receive a confirmation email after they enter their email, username, and password for registration. (Not implemented)
      • 1.1.1.1.9. Guests shall click the confirmation link inside the confirmation email they receive to confirm their registration. (Not implemented)
      • 1.1.1.1.10. Guests shall manually log in from the login page after they confirm their registration. (Not implemented)
    • 1.1.1.2. Guests shall be able to log in to the application by providing their email and password. (Fully implemented)
    • 1.1.1.3. Logged in users shall be able to log out from the application. (Fully implemented)
    • 1.1.1.4. Logged in users shall be able to change their password. (Not implemented)
    • 1.1.1.5. Guests shall be able to reset their password if they are registered and forget their password. (Not implemented)
    • 1.1.1.6. Logged in users shall be able to delete their accounts. (Not implemented)
      • 1.1.1.6.1. The profile page of a deleted account shall not be visible in the application.
      • 1.1.1.6.2. The reviews made from a deleted account shall be visible in the application, but should not be associated with any user.
      • 1.1.1.6.3. A guest shall not be able to log in to a deleted account.
      • 1.1.1.6.4. The username and email of a deleted account shall be freed for another registration.
  • 1.1.2. User Interaction
    • 1.1.2.1. Users shall be able to navigate between pages.
      • 1.1.2.1.1. Users shall be able to navigate to the links (such as popular games, new games, etc.) (Fully implemented)
      • 1.1.2.1.2. Users shall be able to navigate to the lists page. (Partially implemented)
      • 1.1.2.1.3. Users shall be able to navigate to the games' pages. (Fully implemented)
    • 1.1.2.2. Users shall be able to view the lists. (Not implemented)
      • 1.1.2.2.1. Users shall be able to view popular lists made by logged in users and view the number of items in each list.
    • 1.1.2.3. Users shall be able to view a game. (Fully implemented)
      • 1.1.2.3.1. Users shall be able to view reviews made by logged in users ordered by overall likes and filter it by rating. (Partially implemented)
    • 1.1.2.4. Users shall be able to view registered users’ profile pages. (Fully implemented)
      • 1.1.2.4.1. Users shall be able to view registered users’ username, profile picture, favorite games, favorite game properties (genre, platform, developer, etc.) selected by the registered user, recent games, recent reviews, popular reviews, and friends. (Fully implemented)
      • 1.1.2.4.2. Users shall be able to view registered users’ stats which includes the number of games they own, played, currently playing, reviews, and lists. (Fully implemented)
  • 1.1.3. Logged in User Interaction
    • 1.1.3.2. Game Interactions
      • 1.1.3.2.1. Logged in users shall be able to like a game while it is not liked. (Fully implemented)
      • 1.1.3.2.2. Logged in users shall be able to unlike a game while it is liked. (Not implemented)
      • 1.1.3.2.3. Logged in users shall be able to add a game to their playlist while it is not added. (Not implemented)
      • 1.1.3.2.4. Logged in users shall be able to remove a game from their playlist while it is added. (Not implemented)
      • 1.1.3.2.5. Logged in users shall be able to add a game to one of their custom lists. (Not implemented)
      • 1.1.3.2.6. Logged in users shall be able to remove a game from their custom lists. (Not implemented)
      • 1.1.3.2.7. Logged in users shall be able to review a game. (Fully implemented)
    • 1.1.3.3. List Interactions
      • 1.1.3.3.1. Logged in users shall be able to change one of their lists from public to private or vice versa. (Not implemented)
      • 1.1.3.3.2. Logged in users shall be able to create custom lists. (Not implemented)
      • 1.1.3.3.3. Logged in users shall be able to change the name of one of their lists. (Not implemented)
      • 1.1.3.3.4. Logged in users shall be able to delete one of their lists. (Not implemented)
    • 1.1.3.4. Registered Users’ Profile Page
      • 1.1.3.4.1. Logged in users shall be able to report other users for hate, toxicity, discrimination, violence, etc. (Not implemented)
      • 1.1.3.4.2. Logged in users shall be able to block other users because of hate, toxicity, discrimination, violence, etc. (Not implemented)
    • 1.1.3.5. Profile Settings
      • 1.1.3.5.1. Logged in users shall be able to change their profile picture. (Not implemented)
      • 1.1.3.5.2. Logged in users shall be able to select up to a certain number of favorite games. (Partially implemented)
      • 1.1.3.5.3. Logged in users shall be able to select up to a certain number of favorites from each class of game properties (genre, platform, developer, etc.). (Partially implemented)
    • 1.1.3.6. Friends and Followers
      • 1.1.3.6.1. Logged in users shall be able to follow other registered users. (Fully implemented)
      • 1.1.3.6.2. Logged in users should be able to befriend other registered users. (Not implemented)
      • 1.1.3.6.3. Logged in users shall be able to unfollow other registered users they follow. (Not implemented)
    • 1.1.3.7. Review Interactions
      • 1.1.3.7.1. Logged in users shall be able to view the reviews of users they follow in the main page. (Not implemented)
      • 1.1.3.7.2. Logged in users should be able to view the reviews of their friends in the main page. (Not implemented)
      • 1.1.3.7.3. Logged in users shall be able to delete their reviews. (Fully implemented)
      • 1.1.3.7.4. Logged in users shall be able to edit their reviews. (Fully implemented)
  • 1.1.4. Admin Interaction
    • 1.1.4.1. The admin shall be able to delete user accounts. (Not implemented)
    • 1.1.4.2. The admin shall be able to delete reviews. (Not implemented)
    • 1.1.4.3. The admin shall be able to edit public list names. (Not implemented)
    • 1.1.4.4. The admin shall be able to edit reviews. (Not implemented)
    • 1.1.4.5. The admin shall be able to change users’ profile pictures. (Not implemented)
    • 1.1.4.6. The admin shall be able to ban a registered user for a certain period of time. (Not implemented)
• 1.2. System
  • 1.2.1 Notifications
    • 1.2.1.1. System should send notifications to users. (Not implemented)
      • 1.2.1.1.1. System should send a notification when a user receives a follow. (Not implemented)
      • 1.2.1.1.2. System should send a notification when a user gets banned. (Not implemented)
  • 1.2.2. Search
    • 1.2.2.1 System shall provide close-match search for usernames and lists. (Partially implemented)
    • 1.2.2.2 System shall provide exact-match search for games and property values (genre, director, developer, etc.) available in Wikidata API. (Fully implemented)
  • 1.2.3. Game Exploration
    • 1.2.3.1. System should retrieve popular and expected games from IGDB API. (Partially implemented)
    • 1.2.3.2. System shall randomly select “Property of the day” features. (Fully implemented)
    • 1.2.3.3. System shall retrieve games that were published that day from Wikidata API and display them in the “On this day” section. (Not implemented)
  • 1.2.4 Game Browsing
    • 1.2.4.1. Games shall have a game logo from IGDB API. (Partially implemented)
    • 1.2.4.2. Games shall have a game name, (if exists) one or two alternative names and a short description from Wikidata API. (Fully implemented)
    • 1.2.4.3. Games should have longer description, (if available) in-game photos and videos from IGDB API. (Not implemented)
    • 1.2.4.4. System shall calculate the overall rating of the game and display. (Fully implemented)
    • 1.2.4.5. Games shall have available platforms and e-shop links from Wikidata API. (Partially implemented)
    • 1.2.4.6. System shall query properties, retrieve existing ones and display them. (Fully implemented)
      • 1.2.4.6.1. Games shall have a subpage for in-game characters including their trivial information. (Fully implemented)
      • 1.2.4.6.2. Games shall have a subpage for people worked on the game. (Fully implemented)
      • 1.2.4.6.3. Games shall have a sidebar for other available information including genres, critic ratings, developer, publisher, country of origin, Can You Run It link, etc. (Partially implemented)
  • 1.2.5. Lists
    • 1.2.5.1. System shall display popular lists created by registered users. (Not implemented)
  • 1.2.6. Semantic Browsing
    • 1.2.6.1.System shall support semantic browsing by navigating through game properties. (Fully implemented)
    • 1.2.6.2 System shall create (if exists) a short information section for the property and retrieve and list the games that hold that property when the user clicks on the property. (Fully implemented)

Scenario 1 Paul Andreas (24) is a Master's student studying industrial engineering. He loves playing strategy games. He heard from a friend that there is a website name Playlog that enables him to navigate through games, like them, write reviews and read other people's reviews.

1. Paul enters the website and the login page of the website welcomes him. He directly clicks the sign up button.

2. He enters his password, and mail address. He logs in from the login page.

3. He searched from the search box Deltarune, which he heard about from a friend. He clicked the name of the game and He is directed to the page of the game.

4. He have read some popular reviews and recent reviews about Deltarune.

5. Then he clicked the platformof the game which is PlayStation 4.Among some top rated games in this genre, he've seen The Last Guardian, which is one of his favorite games.

6. He clicked the name of the game, then he wrote a review about the game and gave a rating.

7. Before leaving the website, he returned to main page and looked at some popular games.

8. Satisfied with the website, he logged out and quit the website.

Scenario 2 Sara is a 22-year-old student currently enrolled in the Economics department at Texas Tech University. She plays video games when she has time and is passionate about them. She spends much of her free time exploring different gaming genres and immersing herself in captivating virtual worlds. As a gamer, Sara often finds herself engaged in conversations with her friends about their favorite games and seeking recommendations for new ones to try. With a growing list of games she enjoys, Sara decides it's time to organize her favorites and create a curated list that she can easily share with her friends whenever they ask for recommendations. So she decides to use the application she likes and has used before.

1. Sara opens the application and logs into her account using her email and password. After logging in, she is directed to the main page.

2. Sara opens her user page and sees see has a new follower.

3. Sara checks out who is the new follower by clicking follows tab.

We have directories named ./frontend, ./backend, and ./app/mobile/Playlog (which will later be changed to ./mobile), each containing the respective codebase for the frontend, backend, and mobile applications. Each codebase has its own readme file explaining setup, running the application, and making changes based on the codebase. We use docker-compose for building and deploying the application. Additionally, we have our API specification, with a Swagger UI instance available in our docker-compose setup at localhost:8000/swagger.

When working with Docker, the initial setup might take a while as it fetches and sets up the required components. This could take tens of minutes or more, depending on your internet speed and system capabilities. Don't worry if it seems to be taking a long time. Just be patient and let it finish. As long as the build moves forward smoothly without any errors, you're on the right track. It's usually just a waiting game until it's done.

1. Clone the Repository:

   • Open your terminal or command prompt.
   • Navigate to the directory where you want to clone the repository.
   • Use the following command to clone the repository:

     git clone -b dev <repository_url>
     

   Replace <repository_url> with the URL of the repository you want to clone.

2. Navigate to the Repository:

   • Once the cloning process is complete, navigate to the cloned repository directory using the cd command:

     cd <repository_name>
     

   -cReplace <repository_name> with the name of the cloned repository.

   • In the repository create .env file with "nano .env" command.
   • Inside the .env write the following (You can set <text> parts arbitrarily):

   # MySQL settings
   MYSQL_ROOT_PASSWORD=<password>
   MYSQL_DATABASE=playlog_db
   MYSQL_USER=admin
   MYSQL_PASSWORD=<password>
   MYSQL_HOST=db
   MYSQL_PORT=3306
   DJANGO_SECRET_KEY=<django_secret_key>
   
   DEPLOYMENT_URL=127.0.0.1
   FRONTEND_PORT=3000
   BACKEND_PORT=8000
   

   • After saving and exiting (ctrl x followed by y) create the same file in backend folder.
   • Create .env file in frontend folder with following:

   REACT_APP_ENDPOINT=http://127.0.0.1:8000/
   

3. Build and Run Docker Compose:

   • Make sure you have Docker and Docker Compose installed on your system.
   • Run the following command to build and start Docker Compose:

     docker-compose up --build
     

   This command will build the Docker images and start the containers defined in your docker-compose.yaml file.

4. Access the Frontend and Backend:

   • Once Docker Compose has successfully started the containers, you can access the frontend at localhost:3000 and the backend at localhost:8000 in your web browser.

To deploy our application on DigitalOcean follow these instructions:

1. Sign up to Digital Ocean and create a project.
2. From left menu click on "Droplets" and click on "Create Droplets".
3. Choose region, datacenter and a machine. Increase machine capabilities if you have errors. For image click on marketplace and select Docker.
4. Write down a password and save it for later. Click on create droplet.
5. Wait until droplet is created and copy IP address from Droplets page.
6. Open up the terminal and connect to droplet by "ssh root@<ip_address>" command.
7. Once connected to machine install docker-compose with "apt install docker-compose"
8. Clone the repository by typing "git clone https://github.com/bounswe/bounswe2024group12.git".
9. Enter into repository by typing "cd bounswe2024group12/"
10. In the repository create .env file with "nano .env" command.
11. Inside the .env write the following (You can set <text> parts arbitrarily):

# MySQL settings
MYSQL_ROOT_PASSWORD=<password>
MYSQL_DATABASE=playlog_db
MYSQL_USER=admin
MYSQL_PASSWORD=<password>
MYSQL_HOST=db
MYSQL_PORT=3306
DJANGO_SECRET_KEY=<django_secret_key>

DEPLOYMENT_URL=127.0.0.1 (use your own deployment url)
FRONTEND_PORT=3000
BACKEND_PORT=8000

12. After saving and exiting (ctrl x followed by y) create the same file in backend folder.
13. Create .env file in frontend folder with following:

REACT_APP_ENDPOINT=http://127.0.0.1:8000/ (again use your deployment url)

14. To be safe run docker-compose down first then run "docker-compose up --build" command.
15. Make sure frontend and backend were able to be successfully built (ignore the warnings). After that you can access the website by typing <ip_address>:3000 to your browser.

The greatest challenge for our team was trying to accomplish a lot of thing in a very short time. We hadn't implemented most of the features by Milestone 2 and we had only 2 weeks to finish all the work. At that point we partitioned our remaining tasks and sacrificed some of them in order to obtain an incomplete but consistantly operating project.

Another challenge we faced was the time period we implemented most of our features was the busiest time of the terms for all of our team members. Everyone had other responsibilities, therefore most of the work was done at the last minutes. As a result, lack of communications detriment our workflow and some task are done by people other than the original ones that is assigned to task.

The prime lesson we learned is that communication and organization is the heart of the teamwork and collaborative projects. We suffer the most from the lack of organization, which leaded to reluctance in some of our teammates. Therefore the most important part of such projects which involves many people requires prior plan and organization.

Effective communication channels between teammates and teams are also a key factor in achieving successful results in such projects. When there is lack of communication between teammates, the tension and unproductivity starts to emerge. Therefore we learned that in projects with such number of teammates, communication is fundamental.

Yusuf Aygun

During this milestone, I faced several challenges that impacted my ability to contribute effectively. Due to the heavy workload from exams and assignments, I struggled to find enough time to learn frontend development, which limited my ability to assist with frontend tasks. Additionally, a significant amount of my time in both this milestone and in the milestone 2 was spent researching and learning DevOps tools such as Docker, DigitalOcean, and Jenkins. Our team decided to discontinue using Jenkins, considering it unnecessary, which required me to refocus my efforts on backend or frontend tasks. However, the time constraints and energy depletion made it difficult to support my team adequately. To address these challenges, I saw that I need to improve my time management skills, prioritize critical tasks, and communicate with my team to redistribute workloads. I also adopted an incremental learning approach for new tools. Despite these efforts, my contributions during this milestone were limited. Moving forward, I learned that I must work on my own and catch up with my team members on software development experience, additionally I plan to enhance my time management and focus on key areas to support my team more effectively in next semester.

• Mehmet Batuhan Çok

I did not implement any APIs

I didn't write unit tests

During the implementation of our project, the primary challenge I faced was my initial unfamiliarity with Django and the general concepts of software projects, which limited my ability to contribute effectively from the start. As the project progressed and became increasingly complex, my lack of experience compounded the difficulty, leaving me unsure of how to proceed. Compounding this challenge was the extremely tight two-week deadline, coinciding with the busiest period of my term, making it nearly impossible to simultaneously learn Django and implement the project. To address these challenges, I attended all meetings to stay informed and proactively communicated my situation to my team, ensuring they were aware of my situation that prevent potential issues related to last-minute rushes.

Ahmet Firat Gamsiz

signup : Registers user to our user database.

request={
    "username": "oguzkagnici", 
    "email": "[email protected]", 
    "password": "sAfepass1234"
}

response={
    "success": true,
    "message": "User created successfully",
    "username": "oguzkagnici",
    "email": "[email protected]",
    "password": "pbkdf2_sha256$720000$XWKglPdO3agRwhJqcmfnMU$d+h67irsU2E9mCYsVbqAOsCrc1mLA61sDSGbuZfKTTk="
}

login : Checks user exists and given password is correct.

request={
  "email": "[email protected]",
  "password": "sAfepass1234"
}

response={
  "success": true,
  "message": "Login successful",
  "username": "oguzkagnici",
  "token": "dummy-token"
}

follow_user : Saves follower, followee pair in database.

request={
    "username": "oguzkagnici", 
    "followed_user": "ahmetfirat"
}

response={
    "message": "User followed successfully", 
    "success": true
}

unfollow_user : Removes follower, followee pair from database

request={
    "username": "oguzkagnici", 
    "followed_user": "ahmetfirat"
}

response={
    "message": "User unfollowed successfully", 
    "success": true
}

user-followers-list : Returns follower list of given user

request={
    "username": "ahmetfirat"
}

response={
    "followers": ["sonersoner", "ceyoceyo", "oguzkagnici"]
}

user-following-list : Returns followee list of given user

request={
    "username": "ahmetfirat"
}

response={
    "following": ["sonersoner"]
}

is-following : Checks a follower, followee pair exists in database

request={
    "username": "oguzkagnici", 
    "followed_user": "ahmetfirat"
}

response={
    "is_following": false
}

user-check : Checks an user exists in user database

request={
    "username": "ahmetfirat"
}

response={
    "exists": true
}

user-details : Returns user's number of games liked, reviews, followers and followees (liking games is not implemented so it always returns 2)

request={
    "username": "sonersoner"
}

response={
    "gamesLiked": 2, 
    "reviewCount": 4, 
    "followers": 1, 
    "following": 1
}

recent-reviews-game : Returns recent reviews (7 days) for a game

request={
    "game": "rocket-league"
}

response={
  "reviews": [
    {
      "id": 3,
      "game_slug": "rocket-league",
      "user_id": 2,
      "rating": 5,
      "text": "This is a very interesting game. I recommend.",
      "likes": 9,
      "creationDate": "2024-05-17T02:50:47.569Z",
      "lastEditDate": "2024-05-17T07:07:37.491Z",
      "user": "sonersoner"
    },
    {
      "id": 18,
      "game_slug": "rocket-league",
      "user_id": 4,
      "rating": 0,
      "text": "Great game!",
      "likes": 0,
      "creationDate": "2024-05-17T06:16:13.353Z",
      "lastEditDate": "2024-05-17T06:16:13.353Z",
      "user": "ardayalcindag"
    },
    {
      "id": 19,
      "game_slug": "rocket-league",
      "user_id": 5,
      "rating": 2,
      "text": "I have been playing for three hundred hours and and it is kinda boring.",
      "likes": 4,
      "creationDate": "2024-05-17T06:42:47.489Z",
      "lastEditDate": "2024-05-17T18:39:23.213Z",
      "user": "destroyer33"
    },
    {
      "id": 21,
      "game_slug": "rocket-league",
      "user_id": 1,
      "rating": 3,
      "text": "i made my mind",
      "likes": 18,
      "creationDate": "2024-05-17T07:01:40.267Z",
      "lastEditDate": "2024-05-17T19:47:50.337Z",
      "user": "ahmetfirat"
    }
  ]
}

popular_reviews_game : Returns popular reviews (liked more than 5 times) for a game

request={
  "game": "rocket-league"
}

response={
  "reviews": [
    {
      "id": 3,
      "game_slug": "rocket-league",
      "user_id": 2,
      "rating": 5,
      "text": "This is a very interesting game. I recommend.",
      "likes": 9,
      "creationDate": "2024-05-17T02:50:47.569Z",
      "lastEditDate": "2024-05-17T07:07:37.491Z",
      "user": "sonersoner"
    },
    {
      "id": 21,
      "game_slug": "rocket-league",
      "user_id": 1,
      "rating": 3,
      "text": "i made my mind",
      "likes": 18,
      "creationDate": "2024-05-17T07:01:40.267Z",
      "lastEditDate": "2024-05-17T19:47:50.337Z",
      "user": "ahmetfirat"
    }
  ]
}

user-all-review : Returns all reviews of an user

request={
  "username": "sonersoner"
}

response={
  "reviews": [
    {
      "id": 1,
      "game_slug": "celeste",
      "user_id": 2,
      "rating": 4,
      "text": "helo",
      "likes": 4,
      "creationDate": "2024-05-17T02:17:29.033Z",
      "lastEditDate": "2024-05-17T07:41:50.963Z",
      "user": "sonersoner"
    },
    {
      "id": 3,
      "game_slug": "rocket-league",
      "user_id": 2,
      "rating": 5,
      "text": "This is a very interesting game. I recommend.",
      "likes": 9,
      "creationDate": "2024-05-17T02:50:47.569Z",
      "lastEditDate": "2024-05-17T07:07:37.491Z",
      "user": "sonersoner"
    },
    {
      "id": 6,
      "game_slug": "the-password-game",
      "user_id": 2,
      "rating": 3,
      "text": "no bello",
      "likes": 4,
      "creationDate": "2024-05-17T03:15:01.066Z",
      "lastEditDate": "2024-05-17T12:49:21.234Z",
      "user": "sonersoner"
    },
    {
      "id": 9,
      "game_slug": "civilization-ii",
      "user_id": 2,
      "rating": 0,
      "text": "Hello world, I really enjoyed this game! I wanted let you know that I like this game wuhu!",
      "likes": 0,
      "creationDate": "2024-05-17T04:21:49.648Z",
      "lastEditDate": "2024-05-17T04:21:49.648Z",
      "user": "sonersoner"
    }
  ]
}

I have written two sets of unit tests. I didn't write unit tests for some specific cases which I handled at frontend.

Sign up and Login First set is for sign up and login functions.

Test setup: Registers a valid user (test_user) to database.

test_unique_email: Tries to register with unique username but same email as test_user. Expected behavior is response having 400 status code.

test_unique_username: Tries to register with unique email but same username as test_user. Expected behavior is response having 400 status code.

test_successful_signup: Tries to register with unique email and username.Expected behavior is response having 201 status code.

test_login_valid_credentials: Tries to login with test_user's correct information. Expected behavior is response having 200 status code and a token.

test_login_invalid_credentials: Tries to login with test_user's correct email and incorrect password. Expected behavior is response having 401 status code and not having a token.

Follow and Unfollow Second set is for follow functionality.

Test setup: First test uses a setup that has two registered users. Others' setup has three registered user. user_one follows user_two.

test_follow_user_success: Tries to follow user_two as user_one. Expected behavior is response having 200 status code, "User followed successfully" message, and True boolean as success.

test_unfollow_user_success: Tries to unfollow user_one as user_two. Expected behavior is response having 200 status code, "User unfollowed successfully" message, and True boolean as success.

test_get_following_user_success: Tries to retrieve followee list of user_one. Expected behavior is response having 200 status code and {'following': ['user-two']} as json.

test_get_followers_user_success: Tries to retrieve follewer list of user_two. Expected behavior is response having 200 status code and {'followers': ['user-one']} as json. (Note: last two tests' username were switched in the code and empty list was expected but it works this way too.)

test_get_following_user_empty: Tries to retrieve followee list of user_three. Expected behavior is response having 200 status code and {'following': []} as json.

test_get_followers_user_empty: Tries to retrieve follower list of user_three. Expected behavior is response having 200 status code and {'followers': []} as json.

test_is_following_success: Checks user_one follows user_two. Expected behavior is response having 200 status code and {'is_following': True} as json.

test_is_following_failure: Checks user_two follows user_one. Expected behavior is response having 200 status code and {'is_following': False} as json.

test_user_check_success: Checks user_one exists. Expected behavior is response having 200 status code and {'exists': True} as json.

test_user_check_failure: Checks user_four exists. Expected behavior is response having 200 status code and {'exists': False} as json.

test_user_details_success: Tries to retrieve user_one details. Expected behavior is response having 200 status code and {'gamesLiked': 2, 'reviewCount': 3, 'followers': 0, 'following': 1} as json.

test_user_details_empty Tries to retrieve user_three details. Expected behavior is response having 200 status code and {'gamesLiked': 2, 'reviewCount': 3, 'followers': 0, 'following': 0} as json. (Note: last two sets were implemented before review functionality implemented and review count was always returning 3.)

• I didn't write unit tests for my part in review functions. Arda had the main responsibility of those functions.

I was unofficially responsible for team coordination. I spent a great amount of time for this task. I coordinated tasks across team members in many occasions. I helped team members to fix problems they had, clarified their confusions about project and tasks. I reviewed many issues and PRs, gave comment and feedbacks on the work done.

I had two main challenges in this milestone. First one was about not being proficient in Django. Since I was in front-end team and my previous work was more related to that I knew very little about Django (only my experience from milestone 2). When I faced a bug that doesn't have a clear log I had to spent too much time to fix because I didn't know where to look and they were always too simple to fix if I knew where to look first. I didn't had a chance to find a solution but there might be better loggers or debuggers to faciliate the workflow. My second challenge was getting things done by team members. Some of our team members took responsibility for some tasks but they were not able to fully complete them or there were some leftover parts (like connecting backend to front). I don't like things to be incomplete, so as a solution I took over those tasks to get the app properly working. That means I had to allocate much more time than I was supposed to do.

• Add and deploy final swagger
• Implement Main-Page Endpoints
• Implement Game Table in Backend DB

• bugfix: db called before init fixed
• merging backend-dev to dev for testing with front-end
• Finalize Main and Game Page Features

Isil Su Karakuzu

The project extensively uses the SPARQL API provided by Wikidata for querying game-related information. Below are the key functions and descriptions of the interactions with the SPARQL API:

1. get_game_info

   • Description: Fetches detailed information about a specific game using its slug.
   • API Call:
     • Request Body:

       None

     • Response:

       {
           "gameLabel": "Game Name",
           "gameSlug": "game-name",
           "genreLabel": "Action",
           "publisherLabel": "Publisher Name",
           "countryLabel": "Country Name",
           "publication_date": "Publication Date",
           "screenwriterLabel": "Screenwriter Name",
           "composerLabel": "Composer Name",
           "platformLabel": "Platform Name",
           "image": "Image URL",
           "logo": "Logo URL",
           "gameDescription": "Game Description"
       }

   • SPARQL Query: The query filters the game based on its name and retrieves optional properties like genre, publisher, country, etc.

2. search_game

   • Description: Searches for games based on a provided search term.
   • API Call:
     • Request Body:

       {
           "search_term": "Search Term"
       }

     • Response:

       {
           "games": [
               {
                   "gameLabel": "Game 1"
                   "gameSlug": "game-1",
               },
               {
                   "gameLabel": "Game 2"
                   "gameSlug": "game-2",
               },
               ...
           ]
       }

   • SPARQL Query: Filters games by the search term and retrieves up to five matching results.

3. fetch_all_games

   • Description: Fetches all video games and stores them in the database.
   • API Call:
     • Request Body:

       None

     • Response:

       {
           "message": "Games fetched successfully"
       }

   • SPARQL Query: Retrieves all video games with their labels and optional images, filtering labels to English.

4. get_game_of_the_day

   • Description: Fetches a game published on the current date in previous years.
   • API Call:
     • Request Body:

       None

     • Response:

       {
           "gameLabel": "Game Name",
           "game_slug": "game-name",
           "publisherLabel": null,
           "image": "Image URL"
       }

   • SPARQL Query: Filters games by the current day and month, excluding the current year, and retrieves up to three results.

5. get_popular_games

   • Description: Retrieves the most popular games based on the number of statements associated with them.
   • API Call:
     • Request Body:

       None

     • Response:

       {
           "games": [
               {
                   "gameLabel": "Game 1",
                   "gameSlug": "game-1",
                   "image": "Image URL"
               },
               {
                   "gameLabel": "Game 2",
                   "gameSlug": "game-2",
                   "image": "Image URL"
               },
               ...
           ]
       }

   • SPARQL Query: Groups games by their labels and counts statements, ordering the results by the highest count and limiting to 20 results.

6. get_new_games

   • Description: Fetches the most recently published games.
   • API Call:
     • Request Body:

       None

     • Response:

       {
           "games": [
               {
                   "gameLabel": "Game 1",
                   "gameSlug": "game-1",
                   "image": "Image URL"
               },
               {
                   "gameLabel": "Game 2",
                   "gameSlug": "game-2",
                   "image": "Image URL"
               },
               ...
           ]
       }

   • SPARQL Query: Filters games by publication date, orders by the most recent dates, and limits the results to 20.

7. get_game_characters

   • Description: Retrieves characters associated with a specific game.
   • API Call:
     • Request Body:

       None

     • Response:

       {
           "gameLabel": "Game Name",
           "game_slug": "Game Slug",
           "characters": [
               {
                   "characterLabel": "Character 1",
                   "characterDescription": "Character Description",
                   "image": "Image URL"
               },
               {
                   "characterLabel": "Character 2",
                   "characterDescription": "Character Description",
                   "image": "Image URL"
               },
               ...
           ]
       }

   • SPARQL Query: Filters characters by the game name and retrieves optional properties like image and description, limiting the results to 20.

8. get_property_games

   • Description: Fetches games based on a specific property and provides additional information about the property itself.
   • API Call:
     • Request Body:

       {
           "property_name": "Property Name",
           "property_type": "Property Type"
       }

     • Response:

       {
           "property_name": "Property Name",
           "property_type": "Property Type",
           "property_image": "Property Image URL",
           "property_description": "Property Description",
           "games": [
               {
                   "gameLabel": "Game 1",
                   "gameSlug": "game-1",
                   "genreLabel": "Genre",
                   "image": "Image URL",
                   "gameDescription": "Game Description",
                   "rating": 4.5,
                   "logo": "Logo URL"
               },
               {
                   "gameLabel": "Game 2",
                   "gameSlug": "game-2",
                   "genreLabel": "Genre",
                   "image": "Image URL",
                   "gameDescription": "Game Description",
                   "rating": 4.2,
                   "logo": "Logo URL"
               },
               ...
           ]
       }

   • SPARQL Queries:
     • First query retrieves games associated with the property, including optional attributes ``

• test_search_game_success: Successful response with game data when searching for a game.
• test_search_game_no_search_term: Error response (400) when searching without a search term.
• test_search_game_by_genre_success: Successful response when searching for games by genre.
• test_search_game_by_invalid_parameter: Error response (400) when searching with an invalid parameter.
• test_get_game_info_success: Successful retrieval of detailed information about a game.
• test_get_game_info_not_found: Error response (404) when trying to retrieve information for a non-existent game.
• test_get_game_of_the_day_success: Successful retrieval of the game of the day.
• test_get_popular_games_success: Successful retrieval of popular games.
• test_get_new_games_success: Successful retrieval of new games.
• test_get_game_characters_success: Successful retrieval of characters associated with a game.
• test_get_game_characters_not_found: Error response (404) when trying to retrieve characters for a non-existent game.
• test_get_property_games_success: Successful retrieval of games based on a specific property.
• test_get_property_games_no_property_name: Error response (400) when trying to fetch games without a property name.
• test_get_property_games_invalid_property_type: Error response (400) when trying to fetch games with an invalid property type.
• test_fetch_all_games_already_fetched: Message indicating that games are already fetched when attempting to fetch all games again.

Throughout the project, my significant work involved integrating Wikidata's SPARQL querying efficiently, implementing API endpoints, and optimizing database management. I also attended every meeting through the semester, taking detailed notes to ensure alignment among team members. This proactive approach and collaborative effort were pivotal in overcoming obstacles and delivering a robust product.

One of the major challenges encountered during implementation was the prioritization of testing. As testing wasn't initially a priority and was left until the last minute, conducting comprehensive manual tests for each API integration became a significant challenge. To address this, I allocated dedicated time for testing, focusing on thorough manual testing for each API, mine or not mine. Leveraging online resources and collaborating with team members, I managed to identify and address potential issues effectively, ensuring the reliability and functionality of the implemented features.

• #129
• #138
• #115

• #182
• #231
• #156

• Taha Ensar Kukul

I didn't write any API endpoints

I didn't write any unit tests

I was resonsible from the division of labor for mobile side. I mainly fixed important bugs, and implemented most of the fetchings in the app. I also bought a domain name and SSL certificate (It costed 0 dolars) and converted our backend's communication protocol from http to https.

Some of the UI bugs (especially on the scrollview) were so frustrating, and finding a common code writing style was hard, so sometimes understanding the code that someone else wrote was difficult. One time, a little but important change from backend was made about sending a POST request but other teams didn't know that so we searched for a bug for 3 hours. But with swagger, these kind of problems were resolved and by meeting much often, the problems caused by lack of communication were also resolved.

• Issue Link. I got the responsibility of the advanced search in every manner (even if I'm not in the backend team), spent significant amount of time to make it perfect.
• Issue Link. Beside of this Issue from the start to end: I made lots of design desicions about the app(including its font-colors to common component). I also gave feedback to my teammates. Made calls whenever they had a propblem. So this issue from milestone3 is basically summariza my effort on this.
• Issue Link I was not in the backend team after learning djongo wroting the Unit test is also different experience for me. So I think this issue is also important

• Unit Test
• UI Developments
• Advance Search(commit)

search-game-by/str:search_by/ : Returns user's number of games liked, reviews, followers and followees (liking games is not implemented so it always returns 2)

request={
    "search-term": "Shooter"
    # Options are as follows:
    #'genre': 'P136',
    #'developer': 'P178',
    #'publisher': 'P123',
    #'platform': 'P400',
    #'composer': 'P86',
    #'screenwriter': 'P58',
    #'country': 'P495',
    #'director': 'P57',
}

response={
    results: [{'gameLabel': 'First-person Shooter', game-slug:'' }, 
              {'gameLabel': 'Bubble Shooter', game-slug:'' }, ...]
    # naming is only for the unifying with the game search
}

Search Game By

test_search_game_by_missing_search_term: Tries to search for a game by genre without providing a search term. Expected behavior is response having 400 status code and {'error': 'Search term is required'} as JSON.

test_search_game_by_invalid_search_parameter: Tries to search for a game using an invalid search parameter. Expected behavior is response having 400 status code and {'error': 'Invalid search parameter'} as JSON.

test_search_game_by_successful: Mocks a successful response from the SPARQL endpoint and searches for games by genre with the search term 'action'. Expected behavior is response having 200 status code and {'results': [{'gameLabel': 'Action Game', 'game-slug': ''}, {'gameLabel': 'Adventure Game', 'game-slug': ''}]} as JSON.

test_search_game_by_sparql_error: Mocks an error response from the SPARQL endpoint and searches for games by genre with the search term 'action'. Expected behavior is response having 500 status code and {'error': 'Failed to fetch data from SPARQL endpoint'} as JSON.

test_search_game_by_invalid_response_format: Mocks an invalid JSON response from the SPARQL endpoint and searches for games by genre with the search term 'action'. Expected behavior is response having 500 status code and {'error': 'Failed to parse response from SPARQL endpoint'} as JSON.

I've tried to keep the app visually the best we can, even if at the few hours I added loading to data fetch parts, tried to fix orientation aded interactive cards to the all page components, and tried to fix or delete broken css's in most of my commits beside the main descripton of the commit.

I want from frontend to be modular and easy to customize when we want to change it, so I took responsibility to both create-app and set the theme of the app(colors, fonts, common components, etc...). My teammates followed my globals.css and module.css structure but I forgot to give feedback, or respond their concerns time to time. It brings me to put extra effort at the last day of deliverables. And spent too much time to change inline css's(I give up at a point). As a result, I wish I could follow the works through the development much more than that.

At the second milestone even if I've ended up my frontend works one week before. Due to unexpected circumstances at the backend team, I've learned backend and implement some endpoints for the 2nd milestone. This tough situation makes me comfartable at the 3rd milestone in terms of understanding and apllying backend function.

Asya Su Sen

I connected the following API functions to the front-end: game-of-the-day, popular-games, new-games, create-review, like-review, unlike-review, edit-review, delete-review, recent-reviews, popular-reviews, game-info, game-characters.

When we seperated the tasks in between the group, I've got front-end side of things which required me to write a lot of code and focus on React. So I didn't implement new stuff in back end and I didn't need ti write any unit tests.

I had to learn React and implement 2 pages from scracth. I also had to implement everything about reviews: editing, liking, unliking, deleting which required a lot of rerenders of other components. So I've researched a lot about responsive UI. I also talked a lot with my team mates, reviewing and helping them when needed.

• The endpoints were finished the night of the demo so I had to connect all of them without sleeping. We were communicating through out the night and it was very stresful. Since endpoints were being implemented throught the night we all had to work on the dev branch without any choice. So I couldn't create a seperate pull requests. If I were to have time I would have used Github to make discussions, create issues and most importantly create proper pull requests. Now it seems as if I didn't care about proper documentation but that was due to diffult time management.
• Before the template for the endpoints were given to me and I implemented them but during the last 12 hours, most of them changed so I had to reimplement them.
• I was new to front end and I copied the mock ups exactly. Afterwards Soner wanted to make some updates to make them prettier and add some stuff on top of the mock ups. I offered to help but he said that it was easier to implement it himself. I didn't want it to seem as if I was escaping from work.

• #139
• #239
• #189

• #155
• #232
• #234

• Orhan Unuvar

I connected the following API functions to the mobile application:

• create-review
• game-of-the-day
• game-info
• game-characters
• popular-reviews-game
• recent-reviews-game

Since I worked primarily on the mobile application, I did not write any unit tests.

• I presented the mobile application in the last milestone demo.

• I didn't know React Native before, so I learned it from scratch.
• I didn't know how to use Docker before, so I had to learn it.
• I didn't know how to do API calls before, so I had to learn it.

• #200
• #176
• #126

• #225

Arda Yalçındağ

1. create_review

• Description: Create Review.
  • API Call:
    • Request Body:

      {
          "game":"game slug",
          "rating":"rating of the game";
          "text":"review itself";
          "user":"username";
      }

    • Response:

      {
          "201":"description: Review created successfully"
          "400":"description: Bad Request"
      }

2. edit_review

• Description: Edit Review.
  • API Call:
    • Request Body:

      {
          "review": "ID of the review to be edited",
          "rating": "new rating for the review",
          "text": "new text for the review"
      }

    • Response:

      {
          "200": "description: Review updated successfully",
          "400": "description: Bad Request"
      }

3. delete_review

• Description: Delete Review.
  • API Call:
    • Request Body:

      {
          "review": "ID of the review to be deleted"
      }

    • Response:

      {
          "200": "description: Review deleted successfully",
          "400": "description: Bad Request"
      }    

4. like_review

• Description: Like Review.
  • API Call:
    • Request Body:

      {
          "review": "ID of the review to be liked",
          "user": "username of the user liking the review"
      }

    • Response:

      {
          "200": "description: Review liked successfully",
          "400": "description: Bad Request"
      }

5. unlike_review

• Description: Unlike Review.
  • API Call:
    • Request Body:

      {
          "review": "ID of the review to be unliked",
          "user": "username of the user unliking the review"
      }

    • Response:

      {
          "200": "description: Review unliked successfully",
          "400": "description: Bad Request"
      }

6. recent_reviews

• Description: Returns Recent Reviews.
  • API Call:
    • Request Body:

      None

    • Response:

      {
          "200": "description: Returns recent reviews",
          "400": "description: Bad Request"
      }

7. recent_reviews_game

• Description: Returns Recent Reviews of a Game.
  • API Call:
    • Request Body:

      {
          "game": "slug of the game"
      }
      

    • Response:

      {
          "200": "description: Returns recent reviews for the specified game",
          "400": "description: Bad Request"
      }
      

8. recent_reviews_user

• Description: Returns Recent Reviews of a User.
  • API Call:
    • Request Body:

      {
          "username": "username of the user"
      }
      

    • Response:

      {
          "200": "description: Returns recent reviews by the specified user",
          "400": "description: Bad Request"
      }
      

9. popular_reviews

• Description: Returns Popular Reviews.
  • API Call:
    • Request Body:

      {
          None
      }

    • Response:

      {
          "200": "description: Returns popular reviews",
          "400": "description: Bad Request"
      }

10. popular_reviews_game

• Description: Returns Popular Reviews of a Game.
  • API Call:
    • Request Body:

      {
          "game": "slug of the game"
      }

    • Response:

      {
          "200": "description: Returns popular reviews for the specified game",
          "400": "description: Bad Request"
      }

11. popular_reviews_user

• Description: Returns Popular Reviews of a User.
  • API Call:
    • Request Body:

      {
          "username": "username of the user"
      }

    • Response:

      {
          "200": "description: Returns popular reviews by the specified user",
          "400": "description: Bad Request"
      }

I lacked knowledge about testing procedure. Additionally, I couldn't run our container in my local developing environment. Therefore I have skipped the unit testing in enpoints written by me, which were manually tested by my teammates.

Aside from regular meetings, the discussions and communications with other team members during the development process was quite time consuming and exhausting.

The biggest complication I encountered was not being able to run our dockerized project in my computer. Spent nearly 2 days about this issue. The problem was related to the MYSQL server. Although my struggle and my teammates help, I couldn't figure out the source of the problem and decided to write some code nevertheless.

Another challange was the time prediod that we did most of our work was very busy. Aside from this one, I was trying to complete many other projects which prevented me from fully focusing on this project. As a result, I wasn't able to finish my tasks completely and some parts are patched up by my teammates.