The Data Science Toolbox was a cloud computing course project organized around a simple idea: provide one launcher for a collection of data science tools. The archived project source contains a Dockerfile, a Docker Compose configuration, a Python application, setup instructions, and a demo link. It is also listed on my projects page.

The project is best understood as a course prototype rather than a production platform. Its README says it was tested on Windows and requires Docker Desktop plus X11 forwarding software such as XLauncher. A user updates the DISPLAY value, runs docker-compose up, and uses a Tkinter window to open the available tools.

What was assembled

The Compose file defines services for RStudio, Spyder, Gitea with MariaDB, Jupyter Notebook, Orange, code-server, Apache Spark, Tableau, TensorFlow, and a Markdown editor. The Tkinter application presents buttons for those services and also links to external IBM SAS and Tableau pages. Hadoop and SonarQube are explicitly listed as unsupported in the README, which is an important boundary on the project's scope.

The resulting workflow is straightforward:

docker-compose up
        |
        +-> local tool containers on dedicated ports
        +-> Gitea -> MariaDB
        \-> Tkinter launcher -> local or external tool URL

This is not a reverse-proxy architecture, and the source does not demonstrate health checks, GPU switching, or independently built images for every tool. Most services use existing public images and expose their own ports. Describing the checked-in topology accurately is more useful than presenting later architectural ideas as completed work.

What Docker Compose contributed

Compose provided a single place to name services, images, ports, environment variables, volumes, and the Gitea database dependency. That makes the collection easier to inspect and start than a list of unrelated manual installations. The launcher then acted as a menu rather than trying to reproduce each application's interface.

There are limits to the reproducibility claim. Several images use floating tags, including latest, while others are pinned to specific versions. Some buttons open hosted external services, so their availability and login behavior remain outside the Compose stack. The Windows and X11 setup also means that docker-compose up was not completely environment-independent.

Security and maintenance retrospective

The archived configuration favors demonstration convenience. It includes example passwords and tokens, disables authentication for some services, exposes several ports, and runs notebook commands with permissive options. Those choices should not be copied into an internet-accessible deployment.

A safer rebuild would move secrets out of the Compose file, bind development services only where needed, restore authentication, and document which data is persisted through volumes. It would also pin image versions or digests and add health checks before the launcher offers a service. These are design goals for a future version, not claims about the archived submission.

The service list could also be smaller. A focused default profile might include Jupyter, one IDE, and one visualization tool, with optional Compose profiles for heavier services. That would reduce startup cost and make failures easier to diagnose. A browser-based landing page could replace the X11-dependent Tkinter window, but the original launcher still demonstrates the useful pattern of giving many tools one entry point.

Lessons retained

The project made orchestration concrete: a container image alone does not explain service relationships, ports, persistence, authentication, or startup expectations. Compose exposed those decisions in one readable file. It also showed that a unified menu can reduce navigation friction even when the underlying tools remain independent.

The honest takeaway is narrower than “one command guarantees an identical data science environment.” The source shows a working direction for collecting heterogeneous tools and documenting their access paths. Reproducibility, security, and cross-platform behavior would require another iteration.

For another course-project retrospective, see EasyTrip. The portfolio architecture notes describe how projects and posts are presented on this site without conflating the portfolio's implementation with the projects it documents.