I think we should remove all bibtex entries and just use links or put the reference into Further reading.

I believe that in Chapter 1 it is possible to add a description and link to kaggle.com
Kaggle offers a no-setup, customizable, Jupyter Notebooks environment. Access free GPUs and a huge repository of community published data and code.
Add description under 1.8 Further reading and references

# Use an official Ubuntu runtime as a parent image
FROM ubuntu:18.04

# Set the current working directory to /work
WORKDIR /work

# Copy the current directory contents into the container at /work
ADD ./ .

# Install and configure your environment
RUN apt-get update \
    && apt-get install -y python3 python3-pip \
    && pip3 install flask

# Make port 8787 available to the world outside this container (i.e. docker world)
EXPOSE 8787

# Run server.py when the container launches
ENTRYPOINT python3 server.py

This Dockerfile is not written according to good practices:

• if you copy project files as a first step, this invalidates Docker cache and causes all others step to execute again. Here this means that it will install ALL the requirements and this causes a significant delay as it has to fetch and install them all from internet. In Dockerfiles, a proper ordering of commands in very important. Code, as it changes frequently, has to be copied into the container as late as possible.
• For Python, it is a good practice to use virtualenv even in the container. But using virtualenv in the container has many gotchas (e.g. see https://pythonspeed.com/articles/activate-virtualenv-dockerfile/)
• python modules in the official Ubuntu repository are old. It is better to teach students to use and install dependencies via standard requirements.txt.
• it is a good practice (a must in production environments!) to lock dependency versions (again, teach them to lock versions in requirements.txt). If you don't lock the versions, the build is NOT DETERMINISTIC (as it can brake later when a new version of a package is introduced)
• a new recommended way to define requirements is to use pipenv, but for small projects requirements.txt is OK

As a properly written Dockerfile impacts a good user experience a lot, I would suggest to add this exercise into a course:

• first, let them use an original variation of the Dockerfile so they can see for themselves that a small change in Python code causes a significant delay in building a new version of the container as they wait for dependencies to install.
• Then introduce changes in Dockerfile (and explain what they do) and show them that now a change in code causes a MUCH quicker build for all subsequent versions of app's Docker image, as Docker reuses cached layers. This is VERY important If you use big dependencies (e.g. Tensorflow, Keras, ..)!

A better example (adapted from upper link, but not tested with your example code!)

• needs flask in requirements.txt

FROM ubuntu:18.04

# Install Python
RUN apt-get update && \ 
    apt-get install -y --no-install-recommends python3 python3-virtualenv

# Create virtualenv
ENV VIRTUAL_ENV=/opt/venv
RUN python3 -m virtualenv --python=/usr/bin/python3 $VIRTUAL_ENV
ENV PATH="$VIRTUAL_ENV/bin:$PATH"

# Install dependencies:
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Make port 8787 available to the world outside this container (i.e. docker world)
EXPOSE 8787

# Copy the application:
COPY ./ .

# Run the application
CMD ["python3", "server.py"]

One possible addition that can be made at the end of the 2 chapter is a short list of all the git commands mentioned in this chapter (like a cheatsheet). This will help the newbies not search for the git commands in the script as they will have them in the end.

I think Chapter 1 could be enriched with a dedicated Pandas section, which could cover at least the basics along with a toy dataset for students to experiment, as it is a very useful library in the domain of Data Science.