⚠️ The deadline for this week’s submissions is Tuesday 23.4. at 23:59. You can do the tasks either by yourself or in the exercise sessions.

Return your work by pushing to the GitHub repository which you registered into Labtool. Remember to push your work before the deadline! Any work pushed after midnight will not be taken into account (or will bring 0 points).

The points and feedback will be available before next week’s deadline. Please check your points and feedback. If you get any questions or concerns about the grading, send a message through LabTool.

This week, you get 3 points for returning the practical work.

GitHub release

One way to publish your program is by creating a release in GitHub. To do this:

  • Click on “Releases”, which is on your repository’s GitHub page
  • Select Create a new release
  • Input any relevant information
    • Put the current week as the tag. For example, for this week’s (week 5) submission, your tag should be viikko5.
  • If installing or running your code requires some extra steps (for example, placing a file somewhere or running a certain command), you can add them here. The instructions must also be in your README.
  • When creating a release, GitHub will automatically zip the currently pushed source code and attach it to the release.

Release

Now, anyone can download your code easily by going to your GitHub repository, clicking on “1 release”, and selecting the zip file. Make sure that a user that downloads your code from the releases tab and follows the instructions in the README can launch your program without any problems.

Allowing issues in GitHub

Make sure that issues are enabled in your repository. That is, your repository settings page should look like this:

Issues are ways for yourself or others to comment on your project. They were originally intended to report issues with a repository’s code, but are also commonly used for to-do lists, feedback, bug reports, and so on.

Practical work

This week, you will implement new functionality to the program and improve its documentation.

There are 3 points available for this submission. You should also take a look at the grading criteria.

Practical work 1: GitHub release

Make a GitHub release for your project using the above instructions (0.25p).

  • The release should have the latest version of your code (so, do this after you have committed all of your project changes for the week)
  • There is a link to the release in the README.

Practical work 2: Preparing for the code review

Next week, there will be a code review session, which is worth 2 course points. So that you can participate, the following things must be in order:

  • After this week’s deadline, there must be a working version of your code in your repository, and it should implement at least a part of the functionality described in your spec document
  • You must get more than 0 points from this week’s submission
  • You must have GitHub issues enabled. See the above instructions for details.

Practical work 3: New functionality

Expand your project from last week (0.75p):

  • You should be able to run your program using poetry run invoke start
  • The program should be bigger than last week’s version and implement some more functionality that’s in your spec document. That is, your program should include more functionality that’s useful for the user.
  • Mark the features that you have implemented as “done” in your spec document.

Implementation instructions can be found here.

Practical work 4: Tests

Expand the tests (0.5p):

  • You must be able to generate a coverage report for your code using poetry run invoke coverage-report
  • There must be a .coveragerc file in your project’s root directory, which defines which directories are included in the report. You must leave out the UI and tests from the coverage report.
  • Remember to include an empty __init__.py file in each subdirectory under src
  • The branch coverage must be at least 40%
  • The tests should test something relevant to the functionality of your program

Practical work 5: Code quality

Pay attention to the following (1p):

  • The program logic is separate from the UI
  • The code must reflect the logical structure of your program and proper naming should be used
  • There are less than 5 pylint errors

Practical work 6: Documentation

Add a sequence diagram for at least one relevant functionality (0.5p):

  • You can see an example in the reference project
  • Add the diagram to arkkitehtuuri.md
  • There must be a link to arkkitehtuuri.md in the README.

Practical work 7: Changelog

Document the significant changes you make during this week in the changelog.md file, which is in the dokumentaatio folder. You can see an example in the reference project.

Note: Forgetting to do the changelog will result in a significant point reduction.

Practical work 8: Point reductions

Forgetting to do the following things will result in points being deducted:

  • Code quality
    • The structure makes sense (e.g. having all of the code under the same directory)
    • The program logic is separate from the UI
  • The time tracking sheet is up-to-date
    • You must sum up your hours and mark the total in your file
    • Do not include the time spent on weekly exercises (before week 4)
  • There is a changelog entry under changelog.md
  • GitHub issues are enabled
  • The README.md file is proper
    • The file must have the same structure as that in the reference project, i.e.:
      • Short description of your project
      • Links to the spec document, architecture document and time tracking sheet
      • Link to your release
      • Instructions on how to run your project (running your code, running tests, generating coverage report, linting)
  • The repository is clean
    • No extra garbage (e.g. output from the pytest or coverage commands)
    • Weekly exercises must be under laskarit
    • There is a relevant .gitignore

Make sure the project works as intended

NOTE: In order to receive weekly points for the assignment, the application must work on the university’s computer and the TAs must be able to run your code on them! You can test this on any Cubbli computer, such as the freshers’ laptop, or on the computers in your institution’s computer classes. You can also test on a virtual workstation using either a browser or the VMWare Horizon client.

In the virtual workstation, testing of your own application can be done using the browser as follows:

  1. Log into virtual workstation and select Cubbli Linux
  2. Start the terminal and check the version of Python in use with the command python3 --version. If the version is below 3.8, update the version using the instructions here
  3. Make sure that Poetry is installed by running poetry --version. If the installation is missing, follow these Linux installation instructions
  4. Clone your repository to the directory of your choice using the git clone command
  5. Go to your project’s directory and install the dependencies using the poetry install command. Note that the command must be run in the directory where the pyproject.toml file is located.

If the connection to the virtual workstation fails, you should try another browser. Users have reported that at least Google Chrome works quite well. Installing VMWare Horizon Client may also help.

Note: If you are running an application which uses an SQLite database on a virtual desktop, you may encounter the error database is locked. You can probably fix the issue by following these instructions.

Plagiarism

The course follows the University of Helsinki’s study policies Plagiarism and academic plagiarism, i.e. copying answers from the internet or from a friend and returning them as your own work is forbidden. A proven case of plagiarism will result in the failure of the course and repeated cases of plagiarism may result in the suspension of the right to study.

What does plagiarism mean in the context of the practical work? Direct copying of code is prohibited, with the exception of short snippets of code and code generated by ChatGPT or similar tools (see below). Direct copying of code structure, e.g. by changing the names of variables and functions, also counts as plagiarism. On the other hand, you may use images found on the web if you have the right to do so (see below), but if you do so, you must include a reference to it in the documentation of the work, i.e. mention where the quotation was made.

The same plagiarism rules apply to the documentation of the work and it is particularly forbidden to copy-paste the documentation of a reference project.

ChatGPT and similar

Representing code or text generated by ChatGPT and similar AI-based tools (such as Bing Chat, Google Bard or GitHub Copilot) as self-plagiarism is also plagiarism. The use of generated code is allowed in the course, but always “surround” such code with the comments # AI-generated code begins and # AI-generated code ends. Do this even if you have made minor changes to the generated code (changing the names of variables and functions, etc.).

Remember that the use of ChatGPT and similar tools for generating tests is prohibited in the course.

Copyright

Please respect copyright and other intellectual property rights. Remember that you may not use anything found online for your own work. This applies to a wide range of material from software code to images and texts. So always check whether use is permitted under the licence under which the material may have been distributed. Remember that your work is public by default on GitHub. It is your own responsibility not to infringe copyright.