0.9.5 customer presentation 3.1 : Dockerfile and annotation server IP update

What is new since 0.9.0 ?

• Annotation server IP has changed and a static Elastic IP is associated to the annotation server.
• Some packages we used in frontend has deprecated and npm install command requires --force flag to be able to install them. This nuance has been added to dockerfiles.

0.9.0 : Group 2 Cmpe451 2022 Fall Final Release

Group 2 Cmpe451 2022 Fall Final Release
Release: 0.9.0 Customer presentation 3

What has changed?

• Event functionality has added to our application. Users can create and participate in events using mobile app or the learnify webpage.
• Annoration back-end is moved to its seperate server using new annotations microservice and now working completely independent of monolithic back-end server.
• Profile functionality has been added, users can search and see each others profiles, change their bios and profile pictures.
• Semantic recomendations are added, using semantic encoding of learningspaces, semantic engine finds the most suitable learningspaces to recomend to a particular user.
• Comment functionality is added, users now can comment on posts under learning spaces.
• Users now can upvote and downwote posts to show their opinion about posts.
• Multi-language feature addded to the mobile app.
• About us sections are added to the web and mobile apps.
• Our mobile app now supports dark mode to improve accesability.

What is fixed?

• Web application is connected to the new annotation server using W3 annotation model.
• Annotation service is seperated from the back-end and now serves an API to allow other services to access our annotations.

What will be fixed in next releases?

• Semantic search treshold will be fine tuned.
• Authentication will be improved with a new auth middleware.
• Learning space creators will be able to select learningspace header pictures and icons.
• Notes functionality will be added.

customer-presentation-2

Note: C stands for Complated, I stands for In Progress, N stands for Not Started. First term is status of Frontend team, the second term is the status of the backend team, and the third term is the status of the mobile team.

For example, C/N/I means that the frontend team completed, the backend team is not started and the mobile team is still working on it.

1. Functional Requirements

1.1. 🧍 User Requirements

1.1.1. 🔑 Authentication

1.1.1.1. Signup

• 1.1.1.1.1. Guests shall enter an unused username, an unregistered email address, and a strong password to signup. C/C/C
• 1.1.1.1.2. Guests shall agree to the privacy policy and terms&conditions to signup.C/C/C

1.1.1.2. Login

• 1.1.1.2.1. Users shall provide their usernames and passwords to log in.C/C/C

1.1.1.3. Email Verification

• 1.1.1.3.1. Users shall enter the received verification codes (via their registered email addresses) to complete the email verification process.C/C/C

1.1.1.4. Forgot Password

• 1.1.1.4.1. Users shall first enter the email addresses they signed up with and then the verification code they received.C/C/C
• 1.1.1.4.2. Users shall be authenticated after verification and be logged in.C/C/C

1.1.1.5. Logout

• 1.1.1.5.1. Users shall be able to log out.N/C/C

1.1.1.6. Change Password

• 1.1.1.6.1. Users shall be able to change their passwords from the settings screen.C/N/N

1.1.2. 🗿 Profile Page

• 1.1.2.1. Users shall have a profile page.N/N/I
• 1.1.2.2. Users shall be able to edit their profile page.N/N/I
• 1.1.2.3. Users shall be able to display their full name on their profile pages.N/N
• 1.1.2.4. Users shall have an avatar.N/N
• 1.1.2.5. Users shall be able to change their avatars.N/N
• 1.1.2.6. Users shall have a bio in their profile pages.N/N
• 1.1.2.7. Users shall have a "My Events" section on their profile pages.N/N
• 1.1.2.8. Users shall be able to determine their profile page visibility as public or private.N/N
• 1.1.2.9. Followers, Follows, My Events, Interest Areas, Achievements, Progress, Notes, and Annotations sections shall be hidden on private profiles.N/N

1.1.2.10. Interests and Knowledge

• 1.1.2.10.1 Users shall identify their interest areas.N/N/N
• 1.1.2.10.2 Users shall display their interest areas in their profile pages.N/N/N

1.1.2.11. Achievements

• 1.1.2.11.1. Users shall be able to earn achievements via the completion of a specific amount of Learning Spaces with related topics.N/N/N
• 1.1.2.11.2. Users shall view their achievements from the achievements section of their profile pages.N/N/N

1.1.2.12. Progress Tracking

• 1.1.2.12.1. Users shall be able to track their progress.N/N/N

1.1.2.13. Notes

• 1.1.2.13.1. Users shall view their notes taken on a learning space in the notes section of their profile pages.N/N/N

1.1.2.14. Annotations

• 1.1.2.14.1. Users shall be able to annotate post images and texts in learning spaces.I/I/C
• 1.1.2.14.2. Users shall be able to view annotations made by other users.I/I/C
• 1.1.2.14.3. Users shall be able to browse annotations by category, by course, by history, and by upvotes they have received.I/I/I
• 1.1.2.14.4. Users shall access the annotations they have added for course material from the annotations section of their profile pages.I/I/I

1.1.2.15. Learning Spaces and Reputation

• 1.1.2.15.1. Users shall be able to see all learning spaces they created or enrolled in.N/C/C

1.1.2.16. Recommendation

• 1.1.2.16.1. Users shall be able to see the feedback they have received for their learning content contributions in the recommendations section. N/N/N

1.1.3 👩🏼‍💻 User Interaction

1.1.3.1. User-User Interaction

• 1.1.3.1.1. Users shall see each other's profiles. N/N/N
• 1.1.3.1.2. Users shall be able to follow each other. N/N/N
• 1.1.3.1.3. Users shall see the information of people they follow; their achievements and activities. N/N/N
• 1.1.3.1.4. Users shall be able to share notes with each other. N/N/N
• 1.1.3.1.5. Users shall be able to block other users. N/N/N
• 1.1.3.1.6. Users could prevent other users to see their profile by blocking them. N/N/N

1.1.3.2. User-Learning Space Interaction

1.1.3.2.1. Creating Learning Space & Content

• 1.1.3.2.1.1. Users shall enter a title and description and choose an icon and categories to create a learning space. C/C/C
• 1.1.3.2.1.2 Participants shall be able to add polls and notes as learning material. I/I/I
• 1.1.3.2.1.3 Participants shall organize learning material in chapters. N/N/N

1.1.3.2.2. Editing Learning Spaces

• 1.1.3.2.2.1. Users shall be able to edit all material they provided. C/C/C
• 1.1.3.2.2.2. Users shall be able to delete learning spaces they created. N/N/N

1.1.3.2.3. Enrolling to Learning Spaces

• 1.1.3.2.3.1. Users shall see the content within sections. N/N/C
• 1.1.3.2.3.2. Users shall be able to navigate learning material in the order they desire. I/I/C
• 1.1.3.2.3.3. Users shall know the type of poll they are participating in beforehand. N/N/N
• 1.1.3.2.3.4. Users shall receive confirmation of their expertise on the topic upon completion of a lecture. N/N/N
• 1.1.3.2.3.5. Users shall be able to review other users in terms of providing learning material by giving stars and optionally providing feedback. N/N/N
• 1.1.3.2.3.6. Users shall be able to report inappropriate comments in the discussion forum of the lecture. N/N/N

1.1.3.2.4. Notes and Annotation

• 1.1.3.2.4.1. Each user shall have his/her notes section under each lecture. I/I/I
• 1.1.3.2.4.2. Users shall create and edit notes under the notes section via typing. N/N/N
• 1.1.3.2.4.3. Users shall be able to mention other notes from other learning spaces or/and other users in his/her. N/N/N
• 1.1.3.2.4.4. Users shall connect, annotate and tag notes. N/N/N

1.1.3.2.5. Community Events

• 1.1.3.2.5.1. Participants shall be able to create community events for that learning space. N/N/I
• 1.1.3.2.5.2. Created events shall only be available to currently enrolled learners. N/N/I
• 1.1.3.2.5.3. Created events should have a specific date, duration, location and limit for the number of participants. N/N/I
• 1.1.3.2.5.4. The event creator can give a brief description of the topics of discussion for the event. N/N/I
• 1.1.3.2.5.5. Event creators shall be able to cancel events that they have created. N/N/I
• 1.1.3.2.5.6. Created events should be visible on the learning space info page along with the date, duration, location and number of participants. N/N/I
• 1.1.3.2.5.7. The number of learners who will join the event will be visible on the event information. N/N/I

1.1.3.2.6. Creating Polls

• 1.1.3.2.6.1 Users shall be able to create anonymous polls, multiple answer polls, and quiz polls as part of learning space material. N/N/N

1.1.3.2.7. Discussions Forum

• 1.1.3.2.7.1. Participants of a learning space shall be able to create discussion posts. I/I/I
• 1.1.3.2.7.2. The discussion's theme should be detectable during the creation of a discussion also chapter-specific and lecture-specific options for context should be available. N/N/N

1.1.4 📝 Learning Space Structure

• 1.1.4.1. Participants shall deliver learning material in form of posts which contain text and images. C/C/C
• 1.1.4.4. Learning Space shall have the main page where users can see introduction, events, sections, notes, annotations, and polls. I/I/I
• 1.1.4.5. The creator of a learning space shall be able to add additional admins to the learning space. N/N/N
• 1.1.4.6. Every learning space shall have a general discussion forum. I/I/I
• 1.1.4.7. Every learning space shall have a discussion forum per chapter. N/N/N

1.1.5 🛂 Administration

• 1.1.5.1. Admin shall evaluate reports and takes action accordingly. N/N/N
• 1.1.5.2. Admin shall be able to ban users permanently and temporarily. N/N/N
• 1.1.5.3. Admin shall be able to view all contents. N/N/N
• 1.1.5.4. Admin shall be able to remove any content. N/N/N

1.2. 💻 System Requirements

1.2.1. 💡 Recommendations

• 1.2.1.1. Users will get various learning spaces as recommendations. N/N/N
• 1.2.1.2. These recommendations will be based on users' preferences about the topics of learning space. Learning spaces that have similar topics will be chosen to recommend. N/N/N
• 1.2.1.3. The recommendations will be displayed on the home page. N/N/I

1.2.2. 🔔 Notifications

• 1.2.2.1 Users shall get notifications from the system. N/N/N
• 1.2.2.2 The system shall notify users who did not complete almos...

0.1.0-alpha

"Learnify" is an online learning platform. We have implemented authentication-related requirements in this pre-release. Users are able to sign up, log in, verify their email addresses, login when they forgot their passwords, see their basic profile info (static), update their profile image (temporary), and see a home screen with lists of courses. Here are the requirements captured in this pre-release:
Sign up
1.1.1.1.1. Guests shall enter an unused username, an unregistered email address, and a strong password to signup.
1.1.1.1.2. Guests shall agree to the privacy policy and terms&conditions to signup.

Log in and Log out
1.1.1.2.1. Users shall provide their usernames and passwords to log in.
1.1.1.5.1. Users shall be able to log out.

Email Verification
1.1.1.3.1. Users shall enter the received verification codes (via their registered email addresses) to complete the email verification

Availability
2.1.1. System should have a Website interface that provides an web specific user experience.
2.1.2. System should have a Android application interface that provides an mobile specific user experience.
2.1.3. System should support UTF-8 character encoding.
2.1.4. System should support English language.

Forgot Password
1.1.1.4.1. Users shall first enter the email addresses they signed up with and then the verification code they received.

Security
2.3.1 All sensitive data shall be encrypted before storing.

Privacy
2.2.1. Ethical concerns must be considered, so system must follow the rules defined by GDPR/KVKK.

What's Changed

• Adding milestone 2 report by @mbatuhancelik in #308
• Update README.md by @ezgy in #319
• Update group_issue_template.yml by @Koraytkn in #318
• Update issue templates by @bahricanyesil in #340
• Create base folder structure, readme, gitignore and analysis options files by @bahricanyesil in #342
• Initial app, MVVM design pattern and other helper functions by @bahricanyesil in #354
• Implementation of the Navigation Manager by @bahricanyesil in #360
• Base Setup for Multi Language and Multi Theme Support by @bahricanyesil in #361
• 351 initialization of the backend project by @mbatuhancelik in #352
• 355 dockerization of the api by @mbatuhancelik in #367
• Mobile: Implementation of Sign Up Screen by @bahricanyesil in #368
• Mobile: Tests of the Sign Up Screen by @bahricanyesil in #373
• Frontend: Initial pages created to present as an example by @gokayyildiz in #378
• Frontend: Sign up page implementation by @xltvy in #387
• 365 sign up endpoint by @mbatuhancelik in #366
• Mobile: Back-end Connection of the Sign Up Screen and Tests by @bahricanyesil in #389
• Mobile: Bottom Navigation and App Bar Widgets by @bahricanyesil in #394
• Mobile: Integrate the Logo as App Icon by @bahricanyesil in #402
• Mobile: Static Profile Screen by @bahricanyesil in #400
• Frontend: Email Verification Page Implementation by @surmelienes1 in #392
• Mobile: Profil Screen Tests by @bahricanyesil in #404
• Mobile/forget password screen 375 by @ezgy in #382
• Verify email endpoint by @codingAku in #374
• 365 sign up endpoint by @mbatuhancelik in #391
• Milestone1: Preparing Deliverables by @bahricanyesil in #410
• Login page modifications by @Koraytkn in #399
• 380 implementation of login api by @codingAku in #381
• Dockerization of Frontend by @xltvy in #413
• Backend: Implementing Tests for Verify Email Endpoint by @codingAku in #420
• Resend The Verification Code by @hasancan-code in #411
• Mobile/verification screen 395 by @egemenatikk in #416
• Sendmail edit by @mbatuhancelik in #428
• Frontend/forget password by @gokayyildiz in #419
• Frontend: Sign Up Form Validation by @xltvy in #426
• Mobile: forget password backend 384 by @ezgy in #433
• Mobile/verification screen tests 417 by @egemenatikk in #432
• hotfix: usermodel update by @mbatuhancelik in #436
• Frontend: Email Verification Form Validation by @surmelienes1 in #431
• Frontend: Backend connection for sign up page by @xltvy in #438
• Backend connection for Login Page and Form fields format validation by @Koraytkn in #446
• Frontend: Backend connection to forget password by @gokayyildiz in #445
• Bugfix: Return error message for not verified users on log in by @codingAku in #440
• Frontend: Backend Connection for Email Verification Page by @surmelienes1 in #450
• Mobile: implement tests for forget password by @ezgy in #442
• Mobile: Back-End Connection of Verification Screen/434 by @egemenatikk in #435
• return mock course data by @mbatuhancelik in #443
• Mobile: Verification screen network tests by @egemenatikk in #455
• Mobile: course preview widget by @ezgy in #430
• Mobile: Implementation of Login Screen Including Backend Connection by @onurkomurcu in #398
• Backend: Implementing Unit Tests for Login endpoint by @codingAku in #422
• Frontend: Unit tests for sign up page by @xltvy in #456
• Frontend: Unit Tests for Email Verification Page by @surmelienes1 in #458
• Frontend: Frontend/dev to dev by @gokayyildiz in #452
• Frontend: Home page mock by @gokayyildiz in #461
• Frontend/dev forget password unit tests by @gokayyildiz in #463
• Test cases for Login Page has been implemented and tested. by @Koraytkn in #467
• Mobile: Scrollable horizontal course list widget for home screen / 457 by @egemenatikk in #462
• Dev to Master by @gokayyildiz in #469

New Contributors

• @Koraytkn made their first contribution in #318
• @gokayyildiz made their first contribution in #378

Full Changelog: Group-2-Practice-App-Deliverable...customer-presentation-1

Group 2 Practice App Deliverable

Executive Summary

1.1 Introduction/Project Description

As group 2 of CMPE 352 course, our task is to design a learning platform where people can freely give courses and become a learner. For this purpose, we have lecturers and learners as users of our application. Additionally, many other features such as organizing events, filtering, searching courses, and rating lessons exist. We ought to implement a web application for this platform.
Before actual implementation of our project, we have a task to design a practice app to test our frontend and backend skills. We designed this application to have similar features and requirements. Each team member has a task to create at least two, GET and POST endpoints based on our needs, and implement a UI. In our application, we can view lessons, create events where learners of a lesson can get together in real life, search and filter lessons based on categories and ratings, rate a lesson. Our last task is to deploy the application using Docker and AWS systems.

1.2 Project Status

Over the whole term, we have worked on designing our application as stated in Milestone 1. We first decided on requirements, what features are required for our application and we split them into sections. When questions related to deciding requirements arised, we attended customer meetings to clarify. After that, we created mockups and scenarios for basic actions users are capable to do in our app. For detailing the plan of implementation, we created class-user-sequence diagrams. To observe our work done so far, we created project plans and RAM.
One of the most important research topics for our implementation was becoming skilled in Git and Github since we have many pull requests, issues and merges. As a team we developed our skills on using Git. Next step was determining on technologies we will use in our app. We had meetings and researches about finding the most optimal tools for our app and we choose Vue.js and Node.js frameworks. Finally, after researching Docker and AWS to deploy our app, we started implementing practice app.

As stated in 1.1 we made a job share for implementing required features. Every team member created issues for implementing endpoints first since we started from backend. After a endpoint is completed, we created PR’s for corresponding issues. Next step of finalizing endpoints was coding unit tests for each. After tests and manual tests from Postman all passed, each team member implemented a UI for the endpoints they are responsible. During this process, reviewing of each others work was a integral part. We stated the errors and necessities of each other’s work during implementation. Finally, we documented API and Milestone.

1.3 Basic Functionality of the Project

Our project’s aim was establishing a web application that has functionalities that eclipses with the work we have done until our previous milestone report 1. Since we have aimed to develop an online learning platform according to the project description provided, our practice application is developed to have some of the basic functionalities of the online learning platform we have planned throughout the semester.

Our practice application as mentioned above is a web application and provides a graphical user interface for users. A signup page welcomes users and they can sign up to our database by filling the required fields. Each user has a unique email and a hashed password stored in our database. A signed up user can log in to our application via the login page.

Since our practice application is some sort of a learning platform, there are three main components included alongside the user: lessons, categories, and events. Each user can create a lesson by providing required fields and then search for lessons available throughout the application. Each lesson belongs to a specific category, which can also be added to our application’s database by the users. To add a category, providing a valid category name is enough. Our application connects to Wikipedia’s public API to fetch category description and displays each category alongside its name in the categories page. Users can also filter the categories according to their names. When its category is added in our application, a user can create a lesson. Since each lesson has a category and a lecturer, which is the user who created it, a user can filter lessons by category and lecturers. According to their preferences a user can enroll to a lesson and rate it in the rating page. Rating page also provides users’ the opportunity to filter lessons according to their ratings.

For each lesson, a user can create an event that will occur in a specific location and on a specific date, by providing those fields alongside the title and the lesson ID of the lesson that the event belongs to. Each user can create an event for an existing lesson and upon creation our system assigns them as the host of the event. During creation, the user needs to provide a valid location and our application converts it to a valid full address via an API call to the Google Maps Geocoding API. Each user can view a lesson’s events alongside its specific event details that are specified during the creation and attend to an event. After a user attends an event, they can see the events they are attending in the attended events page.

To sum up, our application is a basic online learning platform that contains lessons under the section of categories and enables users to create and enroll to a lesson alongside creating and attending to an event about the lesson.

1.4 Challenges

First and foremost, all of us faced a big hurdle in learning all of the new ideas required to implement the practice app. Learning and implementing new concepts, libraries, and programming languages in which we had no prior expertise in a relatively short period of time was really tough, time-consuming, and mentally exhausting. Fortunately, we were able to aid and educate each other at all times by effectively employing communication technologies with some productive meetings.

The decision of which framework to utilize was the second big hurdle we faced throughout this milestone. Surprisingly, there was no structure with which we were all accustomed, so we decided to go with Node.js for the backend part. However, Node.js in general, the REST Framework, Dockerizaton, and AWS deployment all required research and practice. Experienced ones gave other members of our group instruction and a demo so they could feel comfortable working with the framework. Fortunately, we had almost no trouble dealing with the git related problems with the help of the Git PS lecture given to us prior to our starting point. Nonetheless, Problems we had faced using external APIs were another issue.

Finally, yet importantly, we had some issues while implementing the frontend part which we designed to present our work and functions in a visually appealing manner with a lot of time spent fixing bugs and learning new concepts of vue.js, the progressive javascript framework. Aside from the technological problems, another challenge for us was the increase in the workload per group member as the number of group members decreased from 11 to 9 as the term proceeded given that we were initially allocated as a group of eleven.

In general, the issues originated from the fact that the subjects and tools were all new to us, and we had to step outside of our comfort zones to learn new things and struggle. We solved all of these issues quickly by working together and tackling the obstacles collectively. The ultimate outcome was very satisfying for all of us, but we had to work very hard to get there.