Skip to content

Customer Final Milestone Report

Jump to bottom Edit New page
gumityolcu edited this page Jan 10, 2019 · 21 revisions

Date: 07.01.2019

Executive Summary

This is the final milestone of our project.

Our implementations for this milestone as follows:

Status of Deliverables

Deliverable Status For Final Milestone
Multimedia Usage Completed
Event Location Completed
Event Vote Implemented
Text Annotation Completed
Mobile Version Completed
Searching Completed
Frontend Styling Development Completed

Evaluation of the status of Deliverables

Backend Structure

In backend, we desire to have a concise as well as flexible architecture enabling creating models for abstraction of data and dividing the code into modules via controllers. The current architecture is, for now, sufficient for creating our event share platform, Actopus. Moreover, all the backend deliverables are successfully completed in previous milestones(Milestone #1 and Milestone #2). For this final milestone, we finalized all structure that will help us to extend the code and try to fix all bugs in the backend side.

The whole endpoints have been extensively tested for function and validation. The data structures for all of them have been finalized.

Frontend Structure

User Scenerio

Ümit was already a registered user. One day he wanted to go to a concert and he signed in the Actopus via his account. He thought that this site wass user friendly and whenever he entered Actopus, he could easily reach whatever he wanted. Then he searched the concerts using the search bar at the the top of the page. When he was searching, he used the “Concert” tag. He was supplied all the concert events on the playform, from all over the world. As he lives in Istanbul, he used to map to show the area where he lived. He clicked the “Search this area” button on the right hand side and looked at the events in Istanbul. But there were lots of events. His aim was attending a Jazz concert. Then he found a Jazz concert named “Caz Konseri - Ali Taylan Cemgil ve Olgun Acar” which was created by Murat Ahtapot. He looked at the details of event. The event was in Karaköy/Istanbul, which was convenient for him. He clicked the attend button. Then he remembered that he has a friend Oğuz who currently takes a course from one of the artists of the event. He sent the link of the event via WhatsApp to Oğuz. Oğuz was not a registered user of Actopus platform, but he could see the event. He tried to write a comment in event but he could not. Then he also tried attend the event for clicking the “Attend” button. It failed again. After this, he decided to register. Oğuz saw the home page of Actopus and he thought that the logo of Actopus is very creative, he also thought that the legs of the octopus on the logo, represent the communication between people. Then he clicked registered and signed up on the platform. He navigated to the page of the same event. Then he wrote a comment and also clicked the “Attend” button. Then he followed the his teacher Suzan Üsküdarlı who was also using the Actopus platform. He clicked his feed and saw the events created by Suzan Üsküdarlı. Then he continued to discover the Actopus platform and went to his profile page. He stated his interests by selecting the tags he wanted. Then returned to his feed page again and saw events that were related to his interests. Oğuz liked the platform so much that he decided to create an event for a Lahmacun party that was going to be held in his university. He chose a picture about the event , chose the location via Google Maps using his mouse, wrote the description about the event and supplied the necessary information for event creation. By this time, Ümit had followed Oğuz. After Oğuz’s event creation, Ümit saw the event and looked at its details. Then annotated the work “Lahmacun” in the event description by writing “Beware! The lahmacuns are going to be spicy!”

Summary of Coding Work Done

Person Team Coding Summary
Kemal Tulum Frontend Mobile and desktop design with responsive toolbar. Search and advanced search functionalities with necessary pages added. Event attendance mechanism with new options. Event voting mechanism. Event edit page. Profile page design. Timeline, adjustments in settings, public page new design. Unit test preparation for auth service
Oğuz Kaan Yüksel Frontend Native (Android & iOS) project setup/migration, Native Image/File Services (Web, Android, iOS), Backend Image Server, Frontend Upload Services, Frontend Data API Services, Backend Annotation Data Model, Frontend Routing (guest viewing, auto-redirecting, enable/disable for specific users), Frontend Feed Design (older), Frontend Feed Infinite Scroll, Backend Feed Logic Refactor (ordering, recommendation), Frontend Advanced Search Page (newer), Frontend Fluid Image Component, Frontend Multi-Image Slider Component, Frontend Map Component (auto-complete, location selection etc.), Frontend Authentication Services, Frontend Authentication Interfaces, Frontend & Backend build/deploy scripts, CircleCI CI & CD pipelines
İlyas Demirkıran Frontend
Didem Öngü Frontend Toast messages, specifying user interest options, creating realistic database items, signup page, sign in page, forgot password page, reset password page
Serkan Özel Frontend Feed side menu. Loading Controller and then changed to spinner Validations of user input: sign in, event create, sign up pages. Profile page: complete settings page. initial timeline and public page. General Routing. Data model adjusting. Constantly try to make user and event data models to fit with backend models. Annotation: complete module: a directive that is put on a text to make it annotatable, annotation of text fields with a text, w3c model compatible annotations fetched by event and distributed to event page.When clicked on an annotation, annotation text and user profile link showed.
Gökhan Tekel Backend
Özgür Akaoğlu Backend Authorization using JWT Tokens, Request body validation, vote, getVotes, unvote Endpoints implementation, Event Delete endpoint implementation, Vote implemented using mongoose-vote package, follow and unfollow endpoints fix and getFollowers, getFollowing endpoint implementation
Ümit Yolcu Backend Event data model, Event endpoints, Media data model, Initial media endpoints, CircleCI integration, Annotation data model, Annotation endpoints, Search endpoints(bug fixes and code refactor), JWT authorization structure, attendance endpoints review and refactor
Yusuf Kalaycı Backend User data model,User Endpoints,JWT Token Integration,Sign In,Sign Up functionalities review,Attendance Endpoints Get and Post methods Tests and Fixes,General Bug Fixes,Database backup migration from mLab,Postman Collection Share,General Code Review,Edit User Unowned Events,Search about Express Query Validation,General Documentation of Customer Milestone #2 and Final,Readme.md final version with badges and some functionalities,Final Milestone Presentation preperation.
Nazmican Çalık Backend Express Js Tutorial to Teammates, Initialization and Design of Backend Arhitecture, Authorization with JWT Tokens, Search Functionality, Feed & Recommendations Engine, Initial and Final versions of follow, vote, comment mechanisms, Event and User Data Models, Utility Endpoints, Comment Related Methods, Media Endpoints Review & Refactor, Annotation Data Model Review, Important Bug Fixes on Data Models and Endpoints, Finalization & Fix of All Endpoints, Heroku CD

Requirements

1. Functional Requirements

1.1. User Requirements

    1.1.1. Guests
    • 1.1.1.1. Guests shall be able to see events created by the members.
    • 1.1.1.2. Guests shall not post any comments.
    • 1.1.1.3. Guests shall not create events.
    • 1.1.1.4. Guests shall be able to search for public content.
    • 1.1.1.5. Guests shall not be able to vote on anything.
    • 1.1.1.6. Guests shall see the Trending page instead of Feed page when they open the system.
    • 1.1.1.7. Guests shall not be able to mark attendance information about events.

    1.1.2. Authentication

    • 1.1.2.1. Sign Up

      • 1.1.2.1.1. The users shall sign up by providing an appropriate password, an e-mail address and a unique username to the system.
      • 1.1.2.1.2. Users shall be able to Sign Up via their Facebook accounts.

    • 1.1.2.2. Sign In

      • 1.1.2.2.1. Users shall enter their username and password to login to the system.
      • 1.1.2.2.2. Users shall have the option to Sign in via their Facebook account.
      • 1.1.2.2.3. Users shall have an option to reset their password.

    1.1.3. Profile

    • 1.1.3.1. Personal

      • 1.1.3.1.1. Users shall have a profile page which includes their information. (name, surname, date of birth, nationality)
      • 1.1.3.1.2. Users shall be able edit their activity preferences.
      • 1.1.3.1.3. Users shall have the choice between showing the activities they will attend or that they have attended in their profile page.

    • 1.1.3.2. Settings

      • 1.1.3.2.1. Users should be able to select whether they want to take notification or not.
      • 1.1.3.2.2. Users should be able to configure their privacy settings.

    • 1.1.3.3. Timeline

      • 1.1.3.3.1. Users shall be able to create events by providing necessary inputs(date,description,type,tag etc).
      • 1.1.3.3.2. Users shall be able to see past events that they attended.
      • 1.1.3.3.3. Users shall be able to post comments on events which they attended.
      • 1.1.3.3.4. Users shall be able to share particular events.
      • 1.1.3.3.5. Users shall be able to post photos by tagging certain events.
      • 1.1.3.3.6. Users shall be able to get notifications from certain events.

    1.1.4. Feed
    • 1.1.4.1. Users shall come across first with the feed page when they open the web site or mobile application.
    • 1.1.4.2. Users can see recent created events in the feed section.

    1.1.5. Communication
    • 1.1.5.1. Users shall be able to follow to vote a user and send a personal message to each other.
    • 1.1.5.2. Users shall be able to block other people.
    • 1.1.5.3. Blocked users shall not be able to follow the user who blocks her/him.
    • 1.1.5.4. Blocked users shall not be able to attend any activity organized by the blocker user.

    1.1.6. Events

    • 1.1.6.1. Contribution

      • 1.1.6.1.1. Users shall be able to create pages for already passed events.
      • 1.1.6.1.2. Users shall be able to create pages for future events.

    • 1.1.6.2. Tagging

      • 1.1.6.2.1. Users shall be able to attach a tag to the posts they created.
        • 1.1.6.2.1.1. Some predetermined tags shall be provided by the system.
          • 1.1.6.2.1.1.1 The predetermined tags are art, technology, culture, music, sport and speech.
        • 1.1.6.2.1.2. Users shall be able to create their own tag if they prefer.

    • 1.1.6.3. Attendance

      • 1.1.6.3.1. Users shall be able to mark upcoming events as will attend, may attend or won't attend.
      • 1.1.6.3.2. Multiple people can attend an event using one account by selecting attendance number at event page.

    • 1.1.6.4. Voting

      • 1.1.6.4.1. User shall be able to vote the events with 5 star rating system.

    • 1.1.6.5. Annotation

      • 1.1.6.5.1. Users shall be able to annotate the event information and multimedia that may have been added to an event page.
        • 1.1.6.5.1.1 Users shall be able to annotate text formatted files.
        • 1.1.6.5.1.1 Users shall be able to annotate links.
        • 1.1.6.5.1.2 Users shall be able to annotate geographical references/places.

    • 1.1.6.6. Pricing

      • 1.1.6.6.1 Users shall be able to see the price of every event.

    • 1.1.6.7 Location and Time

      • 1.1.6.7.1 Location supported by the Google Maps API shall be included in every event.
      • 1.1.6.7.2 Time of the event shall be very strict and definite in terms of date, hour and minutes.
      • 1.1.6.7.3 Users can set duration of the event.

    1.1.7. Searching
    • 1.1.7.1. Users shall be able to search with Semantic, Content and Location options.
    • 1.1.7.2. User should be able to filter the events in a city or district.
    • 1.1.7.3. Users should be able to search for other users.

    1.1.8. Verification
    • 1.1.8.1. Famous people,groups or cooperations(teams,communities etc.) should be able to verify their accounts.

    1.1.9. Comments
    • 1.1.9.1 Users shall be able to upvote/downvote the comments.

    1.1.10. Admin Panel
    • 1.1.10.1. The system should provide an admin panel for admins with privileged rights
      • 1.1.10.1.1 An admin should be able to delete or edit events.
        • 1.1.10.1.1.1 An event should be deleted when it contains illegal contents in 1.1.10.1.2.2.
        • 1.1.10.1.1.2 An event should be deleted when it is not an actual event but used for another purpose like advertisement.
        • 1.1.10.1.1.3 An event should be blocked for a day when it contains illegal contents in 1.1.10.1.2.2. This is for user to change the content without removing the event.
      • 1.1.10.1.2 An admin should be able to block a user from logging a specific amount time.
        • 1.1.10.1.2.1 A member user should be blocked for a day when he or she spams messages and disturbs other users.
        • 1.1.10.1.2.2 A member user should be blocked for an appropriate time based on what he or she has done when he or she sends illegal contents like pornography, criminal activities.
      • 1.1.10.1.3 An admin should be able to view emails came from users.
        • 1.1.10.1.4 An admin should be able to respond the emails. The admin shall respond in 2 days.
      • 1.1.10.1.4 Admins should be able to verify celebrities and well known users.

1.2. System Requirements

    1.2.1. Search
    • 1.2.1.1. System will search content based on search type
      • 1.2.1.1.1 If semantic search is selected, system will bring related events depending on tags of events.
      • 1.2.1.1.2 If content search is selected, system will bring exact matches in usernames and event names.
      • 1.2.1.1.3 If location search is selected, system will bring events which are in the location.
      • 1.2.1.1.4 If top search is selected, System will search information that are mixture of the other three options based on their popularity.
    • 1.2.1.2. System should sort search results according to the criteria given in 1.2.3.

    1.2.2. Recommendation

    1.2.2. Recommendation

    • 1.2.2.1. The system shall recommend events to the users, based on the followed users, activity preferences and events attended.

    1.2.3. Ranking
    • 1.2.3.1. The system shall provide a way for the user to see "Trending" events.
    • 1.2.3.2. The ranking procedure shall be calculated according to number of attendees, votes of an event, number of views of an event, and remaining time to an event.
    • 1.2.3.3. The user should be able to filter the process. That is, the user should be able to see the top events ranked according to any non-empty subset of the parameters stated in

    1.2.4. Admin Feature
    • 1.2.4.1 System shall be able to handle all operations stated in 1.1.10.

    1.2.5. Annotations
    • 1.2.5.1 Annotations shall be retrieved by the system when a page with annotations is opened
    • 1.2.5.2 Annotations shall be stored in the system
    • 1.2.5.3 System shall test the annotations to assure validity.
    • 1.2.5.4 System shall allow text formatted annotation.
    • 1.2.5.5 System shall allow image and a description message formatted annotation.
    • 1.2.5.6 System shall geographical references using Google Map API.
    • 1.2.5.7 System shall allow links to other web pages.

    1.2.6. Events
    • 1.2.6.1 System shall store events attendance information
    • 1.2.6.2 System shall store attendance information for passed events, either attended or not.
    • 1.2.6.3 System shall store attendance information for upcoming events.
      • 1.2.6.3.1 It can be "will attend".
      • 1.2.6.3.2 It can be "may attend".
      • 1.2.6.3.3 It can be "won’t attend".
    • 1.2.6.4 System shall store attendance information for already passed events.
      • 1.2.6.4.1 It can be "attended".

    1.2.7. Database
    • 1.2.7.1 System shall be able to store data in the database
      • 1.2.7.1.1. System shall be able to store event tags to sort sematic search results.
      • 1.2.7.1.2 System shall be able to retrieve past event history of a user in events page.
    • 1.2.7.2 System shall be able to update data in the database
    • 1.2.7.3 System should do an integrity check once a week to prevent data loss.

    1.2.8. Voting
    • 1.2.8.1 System shall be able to store voting data.
    • 1.2.8.2 System shall be able to retrieve voting data.
    • 1.2.8.3 Followers/Follows/Blocks Information
      • 1.2.8.3.1 System shall hide user information between the users if one of them blocks the other.
      • 1.2.8.3.2 System should be able to show the number followers and the number of users followed by the user.
      • 1.2.8.3.3 System should show number of followers of a user while searching.
    • 1.2.8.4 Events
      • 1.2.8.4.1 System shall sort searching results according to like numbers of the events.
    • 1.2.8.5 Comments
      • 1.2.8.5.1 System should hide comments which are disliked by more than 10 users.

    1.2.9. Notification
    • 1.2.9.1 In home page there shall be a part for notifications.
    • 1.2.9.2 Notifications is sent under these circumstances
      • 1.2.9.2.1 System should send notification including upcoming event information of the events which a user has indicated that he or she will attend.
      • 1.2.9.2.2 System should send notification to event owner if somebody comments on event page.
      • 1.2.9.2.3 System should send notification to users if somebody comments under their comment.
      • 1.2.9.2.4 System should send notification to users if somebody follows them.
    • 1.2.9.3 Mobile version shall send notifications to users from notifications panel.

    1.2.10. Account
    • 1.2.10.1 A confirmation e-mail shall be send by system to complete the sign up.
    • 1.2.10.2 System shall provide remember me option for username and password.
    • 1.2.10.3 System hides users' information to other users if privacy activated.

    1.2.11. Feed
    • 1.2.11.1 The content of the feed shall depend on the owner account.
      • 1.2.11.1.1 Feed shall include the approaching events created or attended by the users followed by the owner.
      • 1.2.11.1.2 Feed should include the events that the owner might interest. (The details are under Recommendation)
      • 1.2.11.1.3 Feed should include the events that are sponsored by verified users.(Paid advertising business model)
    • 1.2.11.2 Feed shall be updated whenever a new event is ready.
    • 1.2.11.3 Feed should bring new content when user presses a button in the feed page.

2. Nonfunctional Requirements

    2.1. Accessibility
    • 2.1.1. The system shall be accessible on Android and web platforms.
    • 2.1.2. The system shall be compatible with popular Android devices and web browsers.
    • 2.1.3. The web platform shall be responsive to screen sizes with various sizes.
    • 2.1.4. The system's default theme shall be modifiable to night, day and color-blindness themes.

    2.2. Availability
    • 2.2.1. The system will be available to users for 24 hours every day.(Except during maintenance or unexpected errors.)
    • 2.2.2. The system should have a mean time to failure of at least 1 year.
    • 2.2.3. The system shall achieve 99.5% uptime.
    • 2.2.4. Starting of the maintenance hours, the system shall notify present users about the expected termination time of maintenance.
    • 2.2.5. The system should be available to existing Facebook users.

    2.3. Reliability/Survivability
    • 2.3.1. An update process of an item shall start all related updates again if any update fails to commit.
    • 2.3.2. The system storage shall be checked regularly and should be increased whenever necessary in order for the system to continue storing new data without losing any of the old.
    • 2.3.3. The system shall take regular backups of its database every two weeks.
    • 2.3.4. The system shall produce a proper log file in any occurrence of an unexpected error for fixing and recovering purposes.
    • 2.3.5. After each unexpected error, the system should be able to return back at least the latest database backup time.
    • 2.3.6. The system shall produce an occasional log file, once the 70% memory capacity threshold is exceeded.

    2.4. Performance/Efficiency
    • 2.4.1. The system shall respond to requests in 1 second.
    • 2.4.2. The system should support up to 200 requests per second.
    • 2.4.3. System restart cycle shouldn't exceed 5 minutes.
    • 2.4.4. Any interaction between user and interface will be last at most 3 seconds.
    • 2.4.5. At least, %20 of the system's processing capacity will be available during peak load hours.
    • 2.4.6. The Android client should be loaded and ready to use in at most 5 seconds.
    • 2.4.7. The system should be able to serve up to 1000 concurrent users.

    2.5. Integrity
    • 2.5.1. All numeric amounts shall be accurate to two decimal points.
    • 2.5.2. Consistency between latest back-up and system will be checked once in a week.
    • 2.5.3. In case of any inconsistency between incoming requests and database, the operation related to the request should be terminated.
    • 2.5.4. After the termination of a request, state of the database should be restored in case of changes in databases.
    • 2.5.5. An occasional log file should be generated once any inconsistency occurs.
    • 2.5.6. All log files' syntax should be consistent with each other. Thereby not allowing any confusion.

    2.6. Security
    • 2.6.1. Users shall be forced to change their password each year after signing up or latest password change.
    • 2.6.2. After 5 unsuccessful login attempts, another try should be possible after 10 minutes has passed.
    • 2.6.3. The user will be notified via an e-mail about exceedance of 5 unsuccessful login attempts.
    • 2.6.4. User shall be notified about changes of a profile, personal information and password via an e-mail.
    • 2.6.5. The application is web-based, therefore it should have SSL certificate.
    • 2.6.6. The system should deny the requests if the request limit is breached.
    • 2.6.7. The system shall escape any user-supplied input to prevent SQL Injection Attacks and XSS attacks.
    • 2.6.8. Users shall be prevented to construct his/her password with well-known public pieces of information such as his name, birthday.
    • 2.6.9. The system shall throw an inactivity timeout if no action is taken by the user for a specific time.
    • 2.6.10 Passwords shall not be shorter than 8 characters and include both non-numeric characters and numbers.

    2.7. Privacy
    • 2.7.1. The system shall guarantee the security of user data including personal information and passwords.
      • 2.7.1.1 User privacy format can be in one of the two options.
        • 2.7.1.1.1 Profile details can be seen by everyone (public)
        • 2.7.1.1.2 Profile details can only be seen by the followers
    • 2.7.2. The password of a user shall not be visible at any point in time. In case of password loss, the user shall be provided a link which enables construct him/her to a new password.
    • 2.7.3. Against web bots, the system should have reCaptcha human verification tools.
    • 2.7.4. In login page of the web and Android application, the password shall not be visible unless the user chooses otherwise.

    2.8. Database
    • 2.8.1. Any password of personal information about a user shall be encrypted before being put in the database.
    • 2.8.2. Database architecture should allow fast operations to reduce latency.
    • 2.8.3. Periodic backups shall be taken to ensure data is safe and sound.

    2.9. Annotations
    • 2.9.1. The W3C Web Annotation Protocol shall be used to store annotations.
    • 2.9.2. The annotations should be stored and retrieved in accordance with the protocol
    • 2.9.3. Annotations shall be stored and retrieved with an API that is compliant with the standard
    • 2.9.4. The annotations should be tested to assure validity.
    • 2.9.5. JSON-LD should be used for annotation representation as described in the W3C documentation.

    2.10. Robustness
    • 2.10.1. In case of failure, the system should have a recovery time of at most 30 minutes.
    • 2.10.2. Any errors and exceptions encountered will be handled if possible. Proper error message shall be produced for each occurrence of such events.

    2.11. Version
    • 2.11.1. The application should be support XX or higher android version.
    • 2.11.2. The application should be launched XX or higher android version.

    2.12. Localization
    • 2.12.1. The system will be accessible by native Turkish, English and French users.

    2.13. Voting
    • 2.13.1 Number of collected votes shall define the popularity of comments.

    2.14. Location
    • 2.14.1 The location of an event should be provided by Google Maps API.
      • 2.14.1.1 Android application of the system shall provide compatibility with Google Maps application.
      • 2.14.1.2 Web client of the system shall embed a Map in its body.

Design

We already learned from the Cmpe 352 Fundamentals Of Software Engineering that software design is a process to transform user requirements into some suitable form, which helps the programmer in software coding and implementation. We try to use Software Design Levels in our implementation. We already have finished the Architectural Design and High-Level Design. In this part we are trying to de detailed design and implementation. We have a functional and non functional requirements as above. When we are doing implementation our aim are corresponding the requirements. We tried to use agile methodology in our project. We are not a full time worker and we are doing our best in Actopus project as a group.We have a project plan and the milestones for our project.

Project Plan

Actopus-- Culture,adrenalin and friendship project for web and android


1. Meetings
(First Semester) Weekly Meetings
1.0. Milestone 1 - Kickoff Meeting Feb 7, 2018 - Feb 7, 2018
1.1. Meeting Feb 6, 2018 - Feb 6, 2018
1.2. Meeting Feb 12, 2018 - Feb 12, 2018
1.3. Meeting Feb 19, 2018 - Feb 19, 2018
1.3.1. Meeting Feb 23, 2018 - Feb 23, 2018
1.4. Meeting Feb 26, 2018 - Feb 26, 2018
1.5. Meeting Mar 5, 2018 - Mar 5, 2018
1.6. Meeting Mar 12, 2018 - Mar 12, 2018
1.7. Meeting Mar 19, 2018 - Mar 19, 2018
1.8 Meeting Mar 26, 2018 - Mar 26, 2018
1.9 Meeting Apr 2, 2018 - Apr 2, 2018


Sprint Meetings
1.10 Meeting - Warmup
Oct 3, 2018 - Oct 3, 2018

1.11 Meeting #11 - Work Breakdown
Oct 8, 2018-Oct 8, 2018

1.12 Meeting #12 - Sprint #1
Oct 10, 2018-Oct 10, 2018

1.13 Meeting #13 - Sprint #2
Oct 17, 2018-Oct 17, 2018

1.14 Meeting #14 - Sprint #3
Oct 24, 2018-Oct 24, 2018

1.15 Meeting #15 - Sprint #4
Oct 31, 2018-Oct 31, 2018

1.16 Meeting #16 - Sprint #5
Nov 7, 2018-Nov 7, 2018

1.17 Meeting #17 - Sprint #6
Nov 14, 2018-Nov 14, 2018

1.18 Meeting #18 - Sprint #7
Nov 21, 2018-Nov 21, 2018

1.19 Meeting #19 - Sprint #8
Nov 28, 2018-Nov 28, 2018

1.20 Meeting #20 - Sprint #9
Dec 5, 2018-Dec 5, 2018

1.21. Meeting #21 - Sprint #10
Dec 12, 2018-Dec 12, 2018

2. Initialization
2.1. Learning & Research
2.1.1. Repository Research
Feb 6, 2018-Feb 9, 2018
2.1.2. Git Learning
Feb 6, 2018-Feb 10, 2018
2.2. Setup Repository
2.2.1. Labels
Feb 6, 2018-Feb 7, 2018
2.2.2. README.md
Feb 6, 2018-Feb 8, 2018
2.2.3. Issue Formating
Feb 6, 2018-Feb 9, 2018
2.2.4. Wiki Design
Feb 6, 2018-Feb 10, 2018
2.3. Guides
2.3.1. Contribution Guide
Feb 13, 2018-Feb 20, 2018
2.3.2. Git Guide
Mar 5, 2018-Mar 11, 2018
2.4. Milestone 2 - Repository Setup
Feb 11, 2018-Feb 11, 2018
2.5. Warmup
2.5.1. Re-focus on Project
Sep 20, 2018-Oct 7, 2018
2.5.2. Division of Roles
Sep 25, 2018-Oct 9, 2018
2.5.3. Decide Technology Stack
Sep 25, 2018-Oct 9, 2018
2.5.4. Re-form Communication
Oct 1, 2018-Oct 9, 2018

3. Planning
3.1. Initial Plan
3.1.1. Communication Plan
Feb 13, 2018-Feb 18, 2018
3.1.2. High Level Project Plan
Feb 20, 2018-Feb 25, 2018
3.2. Revision
3.2.1. Review Project Flow
Feb 27, 2018-Mar 2, 2018
3.2.2. Prepare Document
Feb 27, 2018-Mar 3, 2018
3.3. Milestone 3 - Planning
Mar 4, 2018-Mar 4, 2018
3.4. Implementation Plan
3.4.1. Work Breakdown
Oct 3, 2018-Oct 8, 2018
3.4.2. High Level Project Plan9
Oct 9, 2018-Oct 13, 2018

4. Analysis
4.1 Requirements Analysis
4.1.1. Requirements Elicitation
4.1.1.1. Glossary
Feb 13, 2018-Feb 15, 2018
4.1.1.2. User Requirements
Feb 13, 2018-Feb 17, 2018
4.1.1.3. System Requirements
Feb 13, 2018-Feb 17, 2018
4.1.1.4. Nonfunctional Requirements
Feb 13, 2018-Feb 17, 2018
4.1.1.5. Customer Meeting #1
Feb 15, 2018-Feb 15, 2018
4.1.1.6. Requirements - First Draft
Feb 18, 2018-Feb 18, 2018
4.1.2. Final Draft
4.1.2.1 Glossary
Feb 20, 2018-Feb 24, 2018
4.1.2.2. User Requirements
Feb 20, 2018-Feb 24, 2018
4.1.2.3. System Requirements
Feb 20, 2018-Feb 24, 2018
4.1.2.4. Nonfunctional Requirements
Feb 20, 2018-Feb 24, 2018
4.1.3. Milestone 4 - Requirements Analysis
Feb 25, 2018-Feb 25, 2018
4.2. User Personas & Scenarios
4.2.1. Personas
4.2.1.1. Determine Personas
Feb 26, 2018-Feb 26, 2018
4.2.1.2. Muhittin - Persona
Feb 27, 2018-Mar 1, 2018
4.2.1.3. Ceyda - Persona
Feb 27, 2018-Mar 1, 2018
4.2.1.4. Şeyda - Persona
Feb 27, 2018-Mar 1, 2018
4.2.2. Scenarios
4.2.2.1. Muhittin - Scenario
Mar 5, 2018-Mar 5, 2018
4.2.2.2. Ceyda - Scenario
Mar 5, 2018-Mar 5, 2018
4.2.2.3. Şeyda - Scenario
Mar 5, 2018-Mar 5, 2018
4.3. Mockups
4.3.1. Web - Draft
4.3.1.1. Home Page
Feb 27, 2018-Mar 2, 2018

4.3.1.2. Profile Page
Feb 27, 2018-Mar 2, 2018

4.3.1.3. Settings Page
Feb 27, 2018-Mar 2, 2018

4.3.1.4. Event Page
Feb 27, 2018-Mar 2, 2018

4.3.1.5. Feed Page
Feb 27, 2018-Mar 2, 2018

4.3.1.6. Search Page
Feb 27, 2018-Mar 2, 2018

4.3.1.7. Web Mockup Draft
Mar 4, 2018-Mar 4, 2018

4.3.2. Mobile - Draft
4.3.2.1. Home Page
Feb 27, 2018-Mar 2, 2018

4.3.2.2. Profile Page
Feb 27, 2018-Mar 2, 2018

4.3.2.3. Settings Page
Feb 27, 2018-Mar 2, 2018

4.3.2.4. Event Page
Feb 27, 2018-Mar 2, 2018

4.3.2.5. Feed Page
Feb 27, 2018-Mar 2, 2018

4.3.2.6. Search Page
Feb 27, 2018-Mar 2, 2018

4.3.2.7. Mobile Mockup Draft
Mar 4, 2018-Mar 4, 2018

4.3.3. Web
4.3.3.1. Home Page
Mar 5, 2018-Mar 10, 2018

4.3.3.2. Profile Page
Mar 5, 2018-Mar 10, 2018

4.3.3.3. Settings Page
Mar 5, 2018-Mar 10, 2018

4.3.3.4. Event Page
Mar 5, 2018-Mar 10, 2018

4.3.3.5. Feed Page
Mar 5, 2018-Mar 10, 2018

4.3.3.6. Search Page
Mar 5, 2018-Mar 10, 2018

4.3.4. Mobile
4.3.4.1. Home Page
Mar 5, 2018-Mar 10, 2018

4.3.4.2. Profile Page
Mar 5, 2018-Mar 10, 2018
Galip Ümit Yolcu
4.3.4.3. Settings Page
Mar 5, 2018-Mar 10, 2018

4.3.4.4. Event Page
Mar 5, 2018-Mar 10, 2018

4.3.4.5. Feed Page
Mar 5, 2018-Mar 10, 2018

4.3.4.6. Search Page
Mar 5, 2018-Mar 10, 2018

4.3.4.7. Messaging Page
Mar 5, 2018-Mar 10, 2018

4.3.4.8. Trending Page
Mar 5, 2018-Mar 10, 2018

4.3.4.9. Create Event Page
Mar 5, 2018-Mar 10, 2018

4.3.4.10. Pick Interests Page
Mar 5, 2018-Mar 10, 2018

4.3.4.11. Sign Up Page
Mar 5, 2018-Mar 10, 2018

4.3.4.12 Sign In Page
Mar 5, 2018-Mar 10, 2018

4.4. Milestone 5 - User - View Analysis
Mar 11, 2018-Mar 11, 2018

4.5. Requirements Specification5
Oct 9, 2018-Oct 16, 2018
,
4.6. Milestone 11 - Project Setup
Oct 17, 2018-Oct 17, 2018

4.7. User Stories9
4.7.1. Auth Stories
Oct 6, 2018-Oct 9, 2018

4.7.2. Event Stories8
Oct 13, 2018-Oct 16, 2018

5. Design

5.1. Architecture
5.1.1. Architecture Outline
Mar 13, 2018-Mar 18, 2018

5.1.2. Class Specifics
Mar 14, 2018-Mar 19, 2018

5.1.3. Use Case Diagram
Mar 15, 2018-Mar 18, 2018

5.1.4. Class Diagram
Mar 20, 2018-Mar 24, 2018

5.2. Sequence Diagrams
5.2.1.1. Sign In
Mar 21, 2018-Mar 25, 2018

5.2.1.2. Sign Up
Mar 21, 2018-Mar 25, 2018

5.2.1.3. Create Event
Mar 21, 2018-Mar 25, 2018

5.2.1.4. Edit Event
Mar 21, 2018-Mar 25, 2018

5.2.1.5. Edit Activity Preferences
Mar 21, 2018-Mar 25, 2018

5.2.1.6. Show/Hide Event
Mar 21, 2018-Mar 25, 2018

5.2.1.7. Post Comment on Event
Mar 21, 2018-Mar 25, 2018

5.2.1.8. Vote Event
Mar 21, 2018-Mar 25, 2018

5.2.1.9. Search
Mar 21, 2018-Mar 25, 2018

5.2.1.10. Trending Page
Mar 21, 2018-Mar 25, 2018

5.3 Milestone 7 - System DesignMar 26, 2018-Mar 26, 2018

5.4. Data Model Design5
Oct 9, 2018-Oct 13, 2018

5.5. Database Design5
Oct 9, 2018-Oct 20, 2018

5.6. System Architecture Design2
Oct 3, 2018-Oct 20, 2018
## Code structure and Group Process **Teams, Workflow and General Overview** In the project we have two main teams. One for frontend and one for backend. We have two types of meetings: - One for sprint meetings (Where all team meets) - The other is for sub-team meetings.(i.e. frontend meeting, backend meeting)

Our root repository holds both backend and frontend stack together. We have one main branch for code development and production, which is master. Each task is solved/carried out under feature branches, and then they are deleted. For example: If authentication is a feature, the developer opens a new branch for the feature and works there. After completing the feature s/he opens a pull request and merges the feature to master if it is accepted.(Rebase strategy is used) We have an automated pr checker (codacy bot) for conventions and better pull requests.

User Stories and Tasks: Each task corresponds to a user story. At the sprint meetings we decide about the main tasks and user stories. After that user stories are created as issues on the github. Then assigned to backend or frontend team leaders. After that team leaders decide about the technical specific tasks and assigns them to team members. This is the main workflow that we follow.

Folder Structure and Deployment: Backend and frontend teams work under their corresponding folders, which are seperated under the repository. .circleci directory, we have the configuration file for our CircleCI jobs. After any pull request to the master branch, CircleCI automatically runs tests on the code and provides feedback. After any successful merge to the master branch, it automatically deploys the last version of the project to our DigitalOcean server which can be reached from 46.101.223.116. The same is done for the staging branch, which is not protected thus CircleCI deploys the code to the server machine on any successful push event. The staging branch runs on port 3000.

Branch Naming Convention: We use the following format for branch naming:

  • [task-type]/[platform]/[name or desc of the task] for example: feature/backend/auth
  • [feature|refactor|bug|test]/[backend|frontend|deployment]/[descriptive-name]

Evaluation of Tools and Managing the Project

Tools

We are using several tools for different areas of our development process from communication to code quality.

  • Communication: We try to use github issues as a platform to distribute the tasks. In order to make it efficient we use labels. Also, for urgent issues we use whatsapp.

Development (Frameworks/Stack)

  1. Frontend
    • Ionic/Angular: Angular is a single page web application developed by google, it has modular structure which makes it having good performance.
    • Jwt Authentication: We use Json Web Token for authentication.
  2. Backend
    • NodeJs: Nodejs is our server side strategy for this application. We use express framework for the backend. Express is very handy for api and basic server development.
    • Mongo Db: We are using mongodb nosql database to hold our models and all kinds of data. After a discussion we decided that using a nosql database would be much better for horizontal scaling.
    • Mongoose: Mongoose is the npm package that we use for database object relation model. Mongoose makes it easy for us to interact with the database collections. (Save,delete,find etc.)
    • Passport Js: We use passport to handle the authentication, passport is a middleware npm package that can be used with different auth strategies (facebook, local, twitter etc), which makes the auth scalable.
    • mLab: Mlab is a cloud database hosting service. We use it to speed up development and also it makes database easily maintainable.

Database Backup

We used mlab cloud database hosting service in our project.It is easily maintainable. And after the final demo we backup our database and migration manual is like this: The terminal commands as follows for our database backup:

  • The password is hiden beacuse of security policy.

For the exporting database binary format is;

  • mongodump -h ds141813.mlab.com:41813 -d actopus2018 -u admin -p ........... -o ActopusDatabase/actopus2018

For the exporting annotation collection json format is;

  • mongoexport -h ds141813.mlab.com:41813 -d actopus2018 -c annotations -u admin -p .......... -o annotations.json

For the exporting user collection json format is;

  • mongoexport -h ds141813.mlab.com:41813 -d actopus2018 -c users -u admin -p .......... -o users.json

For the exporting event collection json format is;

  • mongoexport -h ds141813.mlab.com:41813 -d actopus2018 -c events -u admin -p .......... -o events.json

For the exporting vote collection json format is;

  • mongoexport -h ds141813.mlab.com:41813 -d actopus2018 -c votess -u admin -p .......... -o votes.json

User Manual

1. Sign Up

Upon entering the site, users can sign up by clicking on the link 'Create an account' and by providing name, e-mail and password information.

2. Sign In

From the first page, users can sign in by providing e-mail and password and then by clicking the 'Sign in' button.

3. Profile

3.1. Users can add profile photos; change their name, e-mail and privacy options; report the city they live in, their birth day, their nationality and their interests by clicking on Profile and then on Settings. 3.2. Users can see their timeline from the profile page.

4. Events

4.1. Users can click on events to see their details. From the event details page, they can comment on the event and see other comments. They can click on 'Toggle Annotate' to see the annotatable entities. They can click on the thin lines after clicking Toggle Annotate to reach annotation page in order to annotate texts. In the annotation page, they can choose the fragment they want to annotate. They see the selected text in another box and at the bottom of the page they can enter their annotation and click Save to register it to the database.

4.2. In the annotation page, due to a bug, they need to click on the text and press any button to be able to see the annotations. They can click on the highlighted text to see the annotation afterwards.

4.3. In the feed page, users can click on the '+' button on the bottom-right corner to create an event. They can enter the information necessary for the event and add multiple photos. They can click on 'Share' to share the event on the platform.

4.4. Users can report attendance information by clicking one of the attendance buttons in the event page.

5. Search

Users can search users and events by content by entering the search text to the 'Search' bar at the top. Once a text is entered, the user is directed to the advanced search page. They can search by location, price and tags from this page.

6. Sign Out

Users sign out by clicking the Sign Out button at the top-right corner.

System Manual

Backend Setup

In order to get backend working, you have to install node. You can consult their website for instructions on how to do this for different operating systems.

After this, navigate to the backend folder in terminal and run npm install

Finally, run npm run start:prod to run the server on PORT 80 and npm run start:dev to run it on PORT 3000.

Frontend Setup

Actopus frontend contains the website and cross platform mobile application. The project is mainly dependent on Ionic and Angular.

Quickstart

  1. You should have npm and node installed.

  2. You should change your directory and install dependencies

cd frontend
npm install
  1. You should install Ionic CLI which is an extended version of Angular CLI for easy development
npm install -g ionic@latest
  1. Serve the web application for continuous development
ionic serve
  1. Serve the android application for development
ionic cordova run android

Building

  1. You can build the web development version of the project running
ionic build
  1. You can build the web production version of the project running
ionic build --prod --aot
  1. You can build the android development version of the project running
ionic cordova build android
  1. You can build the android production version of the project running
ionic cordova build android --prod --release

Annotations Document

1. Data Model

Our annotation data model is composed of many data schemas.

1.1. Annotation Data Model Fields:

  1. '@context':
  1. 'type':
  • Type: String
  • Required: True
  • Default: Annotation
  1. 'body':
  • Type: [BodySchema]
  • Required: False
  1. 'target':
  • Type: [SpecificResourceSchema]
  • Required: True

1.2. BodySchema Data Schema Fields:

  1. 'format':
  • Type: String
  • Required: False
  1. 'language':
  • Type: String
  • Required: False
  1. 'textDirection':
  • Type: String
  • Required: False
  • Value: 'rtl' || 'ltr' || 'auto'
  1. 'type':
  • Type: String
  • Required: True

BodySchema schema is discriminated by type field into two different objects for type: 'TextualBody' and type: 'Image'

For type:'TextualBody', we have a required field 'value' of type String. For type:'Image', we have a required field 'id' of type String.

1.3. SpecificResourceSchema Data Schema Fields:

  1. 'source':
  • Type: String
  • Required: True
  1. 'selector':
  • Type: RefinedSelectorSchema
  • Required: True

1.4. RefinedSelectorSchema Data Schema Fields:

  1. 'refinedBy':
  • Type: SelectorSchema
  • Required : False

RefinedSelectorSchema schema is discriminated by type field into two different objects for type: 'TextPositionSelector', type:'XPathSelector and type: 'FragmentSelector'. SelectorSchema is an empty schema which is discriminated by type to these same 3 types.

For types discriminated with type:'TextPositionSelector' we have required fields 'start' and 'end' of type Number.

For types discriminated with type:'XPathSelector' we have required field 'value' of type String.

For types discriminated with type:'FragmentSelector' we have required field 'value' of type String and required field 'conformsTo' of type String with default value "http://www.w3.org/TR/media-frags/".

2. Endpoints

2.1. POST /api/annotations This endpoint is used for creating an annotation. Request body should be in accordance with the data model explained above.

2.2. GET /api/annotations/:id This endpoint is used for reading an annotation with id=:id from the database.

2.3. GET /api/annotations This endpoint is used for getting only the annotations associated with one resouce. A query parameter 'url' is expected, it is the url of the resource we want to get the annotations of.

2.4. PUT /api/annotations/:id This endpoint is used for updating an annotation with id=:id from the database. Request body should be in accordance with the data model explained above.

2.5. DELETE /api/annotations/:id This endpoint is used for deleting an annotation with id=:di from the database.

3. Supported Annotations

3.1. Body We support annotations with no body. If there is a body, it should be an array of TextualBody objects or Image type External Web Resources. These types will be used to annotate objects with text and image respectively in our platform.

Note that even if we will not be using these in our platform, the backend annotation data model supports all External Web Resources with single or no language.

3.2. Target As targets, we only support Specific Resources.

We support Fragment Selectors, XPath Selectors and Text Position Selectors. We also let this selector be refined by one selector. This second selector can be one of the listed types.

Here are extra restrictions on how we plan to use annotations:

  • There will be exactly 1 target per annotation.
  • The target's IRI('source' field) will be the URL to the web page of the object the user is annotating. For an event, for example, it will be http:/..../events/:eventid
  • The target's selector will be of type XPathSelector and will select the annotated part of the object(description, images, artists, location).
  • The selector that refines the target's selector will be a Text Position selector or a Fragment selector that acts on text or image.

Actopus -- Culture, adrenalin and friendship project for web and android

🐙 Actopus Team

Documents

Deliverables

Products

Clone this wiki locally