Python 101

Put it simply, it is about learning python and producing good quality software products
- not only writing code, but also
  1. understanding the requirements,
  2. designing the product,
  3. testing it,
  4. deploying it,
  5. and maintaining it
In particular, nowadays, software engineering must also deal with:
- distribution, i.e. multiple software components interconnected over the Internet
- artificial intelligence (not in this course), i.e. software components that may exhibit human-like capabilities to some extent
  - e.g. understanding natural language, recognizing objects, making decisions, learning from data, etc.

What is Python 101 about? (pt. 2)

At the end of the course…
- … you shall have a clear understanding on the whole process of software engineering
- … you should be able to set up and design a python software project
- … you should be able to reason about the quality of a software project
- … you should have a clear understanding of brings cost or value in a software project
To reach that goal, we shall follow a learn-by-doing approach

The exam consists of a project work to be produced and presented by students
The project work consists of
1. the source code of a software artifact and
2. a textual report describing the design and development processes of the artifact itself
The report is more important than the source code
The project work can be done individually or in groups of up to 3 students – 4 students in exceptional and wee-motivated cases

Students are encouraged to propose project works themes/topics/concepts
- we may help in refining initial proposals
- usually students propose project works that are too ambitious (e.g., too many features for the time available)
- considering that the course is 6 CFU, we suggest to propose project works that can be completed in about 90 hours of work (per student)
We incentivise students to complete their project work as soon as possible
- better if within the next exam session (i.e., we will positively consider early submissions until the beginning of the next semester)
- possibly within the same academic year (i.e., next year that could be different rules, maybe more strict)

Proposal: students propose a project theme/topic/concept on Project forum
- in case of group project, the group members should be declared here
Approval: the teacher will provide feedback and possibly suggest changes/strategies or set requirements
Repository creation: students create a GitHub repository and share it with the teacher
- granting admin access to the teachers’ GitHub accounts (username: gciatto, MatteoMagnini)
Development: students develop the software artifact and write the report
- the report should be written in Latex
- the report should be written in English
- you can use the Latex template

Submission: students submit the final pdf version of the report on Project forum and ask an appointment for the discussion
- submission is not retractable
- at this point we will read the report and evaluate the project work
- in very few scenarios we can ask for changes to the report or the software artifact
- or immediately approve the project for the discussion
Discussion: students present and discuss their project work with the teacher
- appointments may be scheduled in any moment of the academic year taking the teachers’ availability into account
- the discussion will be held either in English or in Italian
- remote discussion may be possible via Microsoft Teams, in case of well-justified needs
- the discussion will include all the members of the group

The software artifact must be a working piece of software
- it must be runnable and testable on the teacher’s machine
“it works on my machine” is not a valid excuse
- it must be documented in the report
The software artifact can be developed in any programming language of choice
- we recommend using Python
The software artifact is mostly aimed at demonstrating students’ understanding of the many aspects of Distributed Systems, so that’s what we will mostly evaluate
- e.g., analysing requirements, modelling a solution, designing interfaces, working features, corner cases, failures handling, writing tests, managing dependencies, automating builds, tracking development, versioning, etc.
Exploitation of Git, GitHub, and version control is important to facilitate your own work

The report is more important than the software artifact

The report must be a document describing the design and development processes of the software artifact
- must speculate on the aspects related to Distributed Systems
The report is the entry point for evaluating the project work
- it should detail what has been done and what has not been done (and why) …
- … w.r.t. some aspects of Distributed Systems presented in the course
Templates and guidelines for the report will be provided on Virtuale

An account on GitHub (create one if missing)
- possibly, based on your university email address
  - if you already have a GitHub account, please add it as the secondary email address
- optionally, with a profile picture showing your face or a recognizable avatar
- possibly, with a professional username (e.g., john-doe instead of johnny-the-king)
A working installation of Python
- possibly version 3.11.x
A working installation of Git
- if you need a GUI, you may choose
A working installation of Visual Studio Code
[Recommended] A working installation of PyCharm
- the community edition is free, and it’s enough

Lectures are recorded by default
- recordings will be available on Virtuale
- access to recordings is by-request only (email the teacher)
Slides and other materials are available on Virtuale
- they are produced along the way, so they may not be available in advance
- also, please re-download / re-load them before each class