Graduate Courses

  • Appointment: University Lecturer (part-time) at IHEC Sfax (September 2024 – May 2026), teaching on-site on the M.Sc. Data Science programme.
  • Course Structure & Workload (32 h per course):
    • Lectures (20 h): 5 modules (4 hours each) covering theoretical foundations, architecture principles, and guided exercises.
    • Labs (8 h): 1 hands-on lab per module (1.5–2 hours) covering practical assignments and collaborative solution reviews.
    • Final Project (4 h): Dedicated workshop session for end-to-end pipeline implementation and project guidance.
  • Language & Tooling: Instruction delivered in French and English; all slides, code repositories, assignments, and exams in English.
  • Assessment Scheme: Final Exam (50%), Module Homework Assignments (20%), Final Project (15%), Attendance & Active Participation (15%).
  • Data Engineering 2

    Fall 2025 – 2026

    • Master’s Year 2
    • 32 h · 20 lecture + 8 lab + 4 project
    • 12 students

    The second-year sequel, moving from building a pipeline to running one that survives contact with production.

    Module 1 — Synchronous & Asynchronous Data Flows

    • The two flow models set side by side, and the different failure modes each one hands the engineer downstream.
    • Choosing between them from the coupling and latency a system can actually tolerate.
    • Lab: the same ingestion written twice, once as a blocking request-response call and once decoupled behind a queue, then stalled on purpose to see which one loses records and which one only loses time.

    Module 2 — Resilient Pipeline Design

    • Retry management and recovery paths, designed on the assumption that failure is the normal case rather than the exception.
    • Orchestration, scheduling and backfills with Apache Airflow.
    • Lab: a multi-task Airflow DAG authored with task-level retries, exponential backoff and idempotent writes, then made to fail mid-run and repaired with a dated backfill over the missing window.

    Module 3 — Processing at Volume

    • Distributed processing with Apache Spark over PostgreSQL sources.
    • Lab: a join-and-aggregate transformation written in Spark against tables read from PostgreSQL, then reworked once the query plan showed where the shuffle was, and the two runs compared.

    Module 4 — Logging & Monitoring

    • Structured logging and error tracking with Loguru.
    • Monitoring, dashboards and alerting in Datadog.
    • Lab: the pipeline instrumented with structured Loguru records carrying run and task identifiers, shipped into a Datadog dashboard, with an alert wired to the failure rate and proved by triggering it.

    Module 5 — Packaging & Delivery

    • Pipelines containerised with Docker; datasets and models versioned with DVC.
    • Automated build and publish through GitHub Actions into the GitHub Container Registry.
    • Lab: a pipeline packaged into a Docker image with its dataset placed under DVC, and a GitHub Actions workflow that builds, tags and pushes to the GitHub Container Registry on every commit to the main branch.

    Final Project — Fault-Tolerant Ingestion Pipeline

    • The four-hour project session: one pipeline carrying data from a PostgreSQL source through a Spark transformation into an analytical target, scheduled as an Airflow DAG with retries and a working backfill path.
    • Operability was graded alongside the data flow: structured Loguru logging surfaced on a Datadog dashboard, the whole pipeline containerised with Docker, and the input dataset reproducible from DVC.
    • Delivered as a repository that runs from a single command, with an architecture diagram and a short written defence of where each retry, timeout and alert threshold was set, and why.
  • Data Engineering 1

    Spring 2024 – 2025

    • Master’s Year 1
    • 32 h · 20 lecture + 8 lab + 4 project
    • 16 students

    The first-year data engineering course: how analytical data is stored, moved, and processed at a volume that no longer fits one machine.

    Module 1 — Big Data Fundamentals

    • What changes once data outgrows a single machine, and why that reshapes the tooling around it.
    • Lab: the same aggregation run over a dataset held whole in memory and then over one read and partitioned in chunks, timed on both, to find the point where the single-machine habit stops working.

    Module 2 — Data Warehousing

    • Why analytical storage is shaped differently from the transactional systems it draws from.
    • Warehouse modelling worked against PostgreSQL.
    • Lab: a star schema designed from a normalised operational source — one fact table, conformed dimensions, explicit grain — and created in PostgreSQL, then queried to show what the denormalisation bought.

    Module 3 — ETL Architectures

    • Extract, transform and load followed from source system through to warehouse.
    • Transformations written in Python.
    • Lab: a Python ETL job extracting from the operational database, cleaning and conforming the records, and loading them into the star schema from the previous lab so the job can be re-run without duplicating rows.

    Module 4 — Processing at Volume

    • Distributed data processing with Apache Spark.
    • Lab: the same transformation rewritten as Spark DataFrame operations and run against a larger extract, set beside the single-machine Python version to see where the distributed one starts paying for itself.

    Module 5 — Analytics & Reporting

    • Closing the loop: warehouse data out into a Power BI report.
    • Lab: Power BI connected to the warehouse and a report built over the star schema, with the measures defined in the model rather than hard-coded into each visual.

    Final Project — Source-to-Dashboard Warehouse

    • The four-hour project session: the whole path in one piece, from a raw operational source to a published Power BI dashboard, built on the schema each team had modelled themselves.
    • Extraction and loading in Python, the heavier transformation step in Apache Spark, and the modelled tables served from PostgreSQL.
    • Delivered as the schema definition, the ETL code and the report, and defended on the modelling decisions — grain, keys, what was left out — rather than on the appearance of the dashboard.
  • Machine Learning

    Fall 2024 – 2025

    • Master’s Year 2
    • 32 h · 20 lecture + 8 lab + 4 project
    • 12 students

    The programme’s applied machine learning course, taken from fitting a model to deciding whether the fit means anything.

    Module 1 — Supervised Learning

    • Learning from labelled data, and what fitting a model to it actually optimises.
    • Models built with Scikit-learn over data prepared in Pandas.
    • Lab: a Scikit-learn pipeline assembled over a Pandas frame — imputation, encoding, scaling, estimator — so that every preprocessing step is fitted on the training split alone and no leakage can survive the refactor.

    Module 2 — Gradient Descent & Optimisation

    • Gradient descent taught as the mechanism underneath model fitting rather than as a library call.
    • The parameters that decide whether it converges at all.
    • Lab: gradient descent implemented from the derivative upward in NumPy, with the loss traced across learning rates until it stalled at one end and diverged at the other.

    Module 3 — Unsupervised Learning & Clustering

    • Finding structure without labels, and where that is the honest framing of a problem.
    • K-Means end to end: assignment, centroid update, and the choice of k.
    • Lab: K-Means written by hand — assignment step, centroid update, convergence test — checked against the Scikit-learn implementation, with k argued from inertia and silhouette rather than picked.

    Module 4 — Model Evaluation

    • The techniques that separate a model fitting its training data from one that generalises.
    • Results inspected as Matplotlib plots, not only as a single score.
    • Lab: a classifier cross-validated and then read properly: confusion matrix, precision and recall against a deliberately imbalanced target, and a Matplotlib learning curve used to tell underfitting from overfitting.

    Module 5 — The Practical Workflow

    • The whole path in one piece: data pulled from PostgreSQL, prepared in Pandas, fitted in Scikit-learn, evaluated and plotted.
    • Lab: that path written as one reproducible script — query, preparation, fitted pipeline, evaluation — with the model and its metrics persisted together so a result can be traced back to the run that produced it.

    Final Project — Applied Prediction Study

    • The four-hour project session: a supervised problem carried from a PostgreSQL extract to a defended conclusion, with the model choice argued from the evaluation rather than asserted.
    • A Scikit-learn pipeline over Pandas preparation, tuned by cross-validated search and measured against a trivial baseline that had to be beaten for the result to count.
    • Delivered as a notebook with the Matplotlib figures the claims rest on, and graded on whether the evaluation actually supports what the report concludes.