2024-2025

1 General instructions

For this course, the grading consists of long-term project.

You will need to work all along the semester to master it. Please start to work on it as soon as possible. You need to use your GitHub account (see Git lecture) as the expected outputs for this course are GitHub repositories.

2 Team project: bikes and bike-sharing in Montpellier

2.1 Setting and objectives

The group composition is available on Moodle.

No free-rider tolerated

The project repository must show a balanced contribution between group members and intra-group grade variation could be made to reflect issues on the intra-group workload balance. Group issues must be reported early to the teaching team.

The project consists of an investigation of bike traffic in Montpellier, through the analysis of the following datasets (at least):

It will be mostly a visualization project, hopefully an interactive one, with the creation of a website (as for the personal project), helping to navigate your work. The study could focus at least on the following time resolution: last month, last year and all years. Among the output expected is

  1. a video such as this one NYC CitiBike:
  2. an interactive map of Montpellier predicting the traffic of bikes in the city for the next day, say à la Bison futé, with a color code for the traffic intensity:

2.2 Timing

  • Mid-term project snapshot: This part consists of starting the group project, explaining the main question of interest chosen to investigate. You should show preliminary work and organization of the workload, git first steps for the group project, etc. See details below Section 2.2.1. This part corresponds to 25% of the final grade. The due date is October 25 (23:59).

  • The GitHub repository with the presentations slides should be completed before Tuesday 10 December (23:59). This part corresponds to 35% of the final grade. Nothing pushed after the deadline will be taken into account.

  • The oral presentation (15mn + 5mn questions) December 13 (8:00) (room: SC36.01). This part corresponds to 35% of the final grade.

2.2.1 Mid-term project snapshot

Please provide the URL of the group repository and the group composition (do not forget your student number) in the following survey TODO_TODO_TODO_TODO_TODO_TODO_TODO_TODO_TODO_TODO_TODO_TODO_..

The main point for this step is to create a README.qmd (maximum length: approximately 4 pages) in a roadmap directory at the root of your project. We will provide you feedback in the form of GitHub issues on your project repository. Your file should give the outline of the project with the following ingredients:

    gantt
        title Preparing Polyglot Notebooks Talk for Stir Trek 2023
        axisFormat %m-%d
        section Proposal <br> and <br> Evaluation
            Submit Abstract         :done,                2023-01-15, 2023-02-18
            Session Evaluation      :done, EVAL,          2023-02-18, 2023-03-05
            Talk Accepted           :milestone, done,     after EVAL,
        section Talk <br> Preparation
            Research & Outlining    :done, OUTLINE,       2023-03-12, 9d
            Create Mermaid Examples :done, MER_EXAMPLE,   after OUTLINE, 5d
            Write Mermaid Articles  :active, MER_ART,     after MER_EXAMPLE, 7d
            Write Jupyter Articles  :                     after MER_ART, 3d
        section Delivery
            Final Notebook          :crit, NOTEBOOK,      2023-04-19, 7d
            Rehearsal               :crit,                after NOTEBOOK, 2023-05-04
            Stir Trek 2023          :milestone, crit,     2023-05-05, 1d

2.2.1.1 Elements expected for the mid-term project

General Details Points (out of 20)
Mid-term Git / branches 4
Task affectation / Gantt chart 4
Dataset choices / Download / Description 4
Packages/software description for the project 4
Figure of interest/narration 4
Total 20

2.2.2 Final project

2.2.2.1 General guidelines

  • The ultimate goal is to provide a Python project that builds a website with quarto or with sphinx and presents your project. This website should be deployed automatically through GitHub actions. A description of the procedure will be needed (imagine you are addressing a user not aware of your package). An example of a project made in 2020, is available at https://github.com/tanglef/chaoseverywhere.

  • It should contain all the aspects described below.

2.2.2.2 Website

  • You have to create a simple website using GitHub pages and a GitHub action with quarto or sphix for displaying your results,

  • At least one of the pages should contain an interactive element (maps, widgets, etc.)

2.2.2.3 Project structure

  • All the code will be placed in a subdirectory called /my_module_name (choosing your module name accordingly).

  • A slide deck in quarto will be put in a /slide directory of the repository. The latter will be a short presentation of the work that will be orally presented during 15mn in front of a jury, at the end of the project.

2.2.2.4 Git aspects

  • A .gitignore that prevents garbage files from being included in your project.

  • Equilibrated commits in two branches should be done (e.g., in the development branch and the master one), and merged for the milestone day.

  • Your repository should contain a README.md:

    • containing the title and a short description of the project
    • the link to the website
    • a code snippet to build the website
    • authors list and a license description. See this website. A default choice could be MIT Licence.

2.2.2.5 Object programming aspects

  • You should code at least one Python class.

  • Your python project should contain submodules. Each submodule will be devoted to a specific sub-task of your project.

2.2.2.6 Dataset(s)

  • The data used should be available in a way that the end user does not need to perform a manual download of any kind (use the pooch package or variants for instance).

2.2.2.7 Time/memory evaluation

  • A full study of the time and memory footprint of the code produced will be provided for the whole pipeline used. Elements showing speed-up / memory savings you could find along the way would be also appreciated.

2.2.2.8 Documentation

  • Docstrings should be populated for every python class and function.

  • Bonus points will be given if you create an API documentation using sphinx for instance.

2.2.2.9 Test and CI

  • Provide unitary tests to check that the function you proposed satisfies the requirement you target.
  • Implement a Continuous Integration solution with GitHub that runs your unitary test at each commit.

Here’s a recap for the final project (code, website):

General Details Points (/20)
Code Problem Resolution 8
General code quality / readability 2
Readme/Comments/Pep8 1
Unit Tests/CI/Deploy: wheel 1
Class (create at least 1 class) 1
Reproducibility/Dataset loading 1
Graphical aspects: Widgets, clickable map, etc. 2
Time/Memory efficiency 1
Documentation 3
Total· 20

Here’s also a recap for the presentation part (slides, oral presentation):

General Details Points (/20)
Oral Slides quality and structure 10
Clarity / lively presentation / Rhythm / Show 10
Total· 20
Back to top