option_assesment.md

DFB match predictions

assignment

We were tasked with creating a "simple" application to make predictions for the next/any given DFB match. The assignment was broken up into 3 parts for us:

1. data acquisition
   • gather the data required for this task
2. data processing
   • actually make the predictions using 2 different algorithms
3. data visualisation
   • present the data/results in a UI (no cheezy excel export sadly...)

option assessment

As a first step we have to assess our options for each part of the project, for this purpose I have collected multiple options for each major part. All the library choices are related to our language of choice for this project: python3.

meta-project stuff

1. env managment
   • virtualenv
   • pipenv
2. IDE/editor
   • pycharm
   • vscode
   • mu
   • sublime text
3. test automation
   • tox
   • pytest
   • some system in gitlab?
4. linters (not necessarily mutually exclusive)
   • flake8 (docs)
   • pylint
   • pydocstyle
   • mypy

acquisition

1. published dataset
   • university of Bayreuth
2. scrape the net
   • fussballdaten.de
   • rand.de
   • bulibox.de
   • liga-statistik.de
   • statista.com
3. open api:
   • openligadb.de (docs)

storage

1. db
   • sqlalchemy
2. file based
   • csv
   • json
   • xml
   • pickle (+ dill)

processing

1. neural networks
   • not to sure what types would be applicable for this problem
2. stochastics
   • Monte Carlo algorithm
   • Atlantic City algorithm
   • Las Vegas algorithm
   • Poisson regression model
   • Dixon-Coles model
   • True Skill

visualisation

1. native ui
   • tkinter (+ ttk)
   • appJar
   • pyglet
   • qt
2. browser based
   • django
   • flask
   • reahl

final choices

1. meta-project stuff:
   • env management: pipenv
   • IDE/editor: ...
   • test automation: pytest
   • linters
     • flake8 (docs)
     • pydocstyle
     • mypy
2. acqusition: open api via openligadb.de (docs)
3. storage: database via sqlalchemy
4. processing:
   • algorithm 1: Poisson regression model
   • algorithm 2: ...
5. visualisation: native ui via tkinter (+ ttk)

proposed planing

As a start, in my opinion, it would very nice to split this whole project up into 4 epics:

1. aquisition
2. storage
3. processing
4. visualisation

Additionally it might be a good idea to start out simple and just create tickets as needed. But later on, when we get a grip on the project, we should have meeting to write all of the tickets needed.

For each step we would extend a cli, to make testing and commandline use possible before we have a UI ready.