📗 Lecture & PS Notes

[umitcan07]

We will be discussing the notes we take from lectures and PS's under this discussion.

[umitcan07]

February 17 Lecture

• Descriptions should not posses subjective language on issues.
• Fixing 1 typo : Not A good example of an issue. Fixing many typos in a document, or revising in general: Better one
• We should have a clear "definition of done" for the issues. One should identify whether an issue is done or not.

[umitcan07]

March 5 Lecture

• Discussed the correct and incorrect form for requirements:
  For user requirements:
  "User should be able to": correct pov
  "System should allow": incorrect pov

[umitcan07]

Requirements Early Draft:

1.1. Users shall be able to semantically search and browse information related to chess

1.3. Users shall be able to make a short post

1.4. Users shall be able to bookmark a content

1.5. Users shall be able to like a content

1.6. Users shall be able to see the details of a post (e.g. who posted, when posted, is edited, who is liked)

1.7. Users shall be able to follow others

[hks1444]

March 18 PS

• Mobile first design will be explained in the report
• You should add links and estimated time to personal efforts page
• We are free to write personal efforts for the past weeks
• We should discuss about researches even though a single or a few people did the research (ex semantic search)
• Project plan will grouped by feature not implementation

[umitcan07]

March 25 PS

• Midterm: Everything we have seen so far is included, no diagrams to be drawn in the exam.
• Created a few requirements for a note-taking app.
• Drew a Class Diagram with mermaid
• Glossary should be rich, and inclusive of the even seemingly basic definitions.
• Make sure not to have circular definitions.

[MucahitErdoganUnlu]

April 1 PS

• Created Sequence diagrams for the last week's Note taking example
• mermaid has a documentation page

[MucahitErdoganUnlu]

April 2 Lecture

• A good product has

  • documentation
  • testing
    • unit tests: only one function is tested; integration tests etc

• 30 April is a milestone and it includes the design part, the project plan, and some implementations which are:

  • API and its specification, Web, Mobile, Database. but not all functionalities would be working. maybe implementing registration and login would be a good idea

• specification of API is important because it enables the backend and frontend to work simultaneously.

• The frontend shall not wait for the backend.

• we are going to use docker.

• github has actions

• She covered some part of configuration management on the slides

  • system building
    • reqirements.txt contains the list of versions of the packages, libraries
    • .gitignore excludes files from push. these should be excluded:
      • secrets, OS config, executables, virtual environment, IDE related, DB, cache, .env
  • before pushing, make a pull request. "how do you handle PR" can be good in RAM. DO NOT close every PR with "Good Job!" etc. Do that if there is something extraordinary.
    • what is worth to make a pull request if:
      • it has a dependent
      • it completed an issue

[MucahitErdoganUnlu]

April 22 PS

• make deployment on digitalocean

  • create droplet
  • ssh root@ip to enter the machine which is on the digitalocean on the local terminal
  • Host digitalocean
    • Hostname IP
    • User root
    • host, hostname, user -> .ssh/config file
    • on vscode, type remote to see digitalocean

• install docker ubuntu.

  • install-docker.sh to the digitalocean machine on vscode
  • docker-compose enables execution of multiple dockers.

• Suzan Hoca will try each group's app.

• The second milestone will have a demo.

• Provide a good readme to run the app

[yunuskaydin]

April 30 Lecture

Point of Reflection In Milestone

What went well:

• collaboration of 10 people
• creating a great design
• learning how git works by working on the project

Final Milestone:
Work will depend on our progress until Milestone 2.

Requirements can be modified.

If it's small it doesn't matter. If it's a significant change we should change the version with a new number.

Quality Assurance

The sooner you see a bug on your project the easier it becomes to fix it.
Assure that the project achieves some quality level by the whole team. QA team can verify it.

Validation

You build the right thing by meeting expectation of customers.

Verification

Meeting requirements and design.

Testing Activity

• The activities to test the quality of the software. Can't yield bug free products.
• Goal is to continuously testing the software.
• Unit test must be done by the person who implemented the function.

Program Testing

• Discovers program defects.
• Runs with artificial data.
• Checks for functional and non-functional behavior.

Bug Reports

• Bug reports must be specific to one issue.
• Bug reports must be assigned to a person.

Testing Approaches

• Black Box Testing

• • Does it do what its meant to do

• White Box Testing

• • Is the solution a good solution