Add Ruff configuration from course-materials Lab 6

[Copilot]

Adds the standard Ruff linting configuration from advanced-computing/course-materials Lab 6 guidance to this repo.

Changes

• New pyproject.toml — created with the Lab 6 Ruff config:
  • line-length = 100, E501 suppressed
  • Rule sets enabled: B, C90, E, F, I, N, PD, PLR, SIM, UP, W

Original prompt

Add the Ruff configuration from the course materials to the repository advanced-computing/bouncing-penguin.

Context:

• The course instructions in advanced-computing/course-materials say to add the Ruff configuration from that repository's pyproject.toml.
• The relevant source is advanced-computing/course-materials/blob/main/pyproject.toml.
• Please add the Ruff configuration to this repo in the appropriate project configuration file.

Required Ruff configuration to add:

[tool.ruff]
line-length = 100

[tool.ruff.lint]
extend-ignore = [
  "E501", # line too long
]
extend-select = [
  "B",   # flake8-bugbear (common bugs)
  "C90", # McCabe complexity
  "E",   # pycodestyle errors
  "F",   # Pyflakes (basic errors)
  "I",   # isort (import sorting)
  "N",   # pep8-naming
  "PD",  # pandas-vet
  "PLR", # Pylint refactor (function/module length, complexity)
  "SIM", # flake8-simplify
  "UP",  # pyupgrade (modern Python)
  "W",   # pycodestyle warnings
]

Notes:

• Use the repository's existing Python project configuration conventions.
• If there is no existing pyproject.toml, create one and add the Ruff configuration there.
• Keep the change minimal and focused on adding the Ruff configuration.
• Create a pull request against main.
• In the PR description, mention that this follows the Lab 6 course-materials Ruff configuration guidance.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: Give feedback on the code quality in this repository

Assistant: The repository is pretty solid for a student project, with clear structure, useful tests, and good separation between app UI, data loading, and validation. The biggest code-quality issues are an oversized main app file, some duplicated schema/column-mapping logic, and a few maintainability risks around query construction and testing depth.

What’s good

• Clear project organization. The repo separates the Streamlit app, helpers, validation, ETL script, and tests in a sensible way:
  • streamlit_app.py
  • utils.py
  • validation.py
  • load_data_to_bq.py
  • tests/
• Good use of helper functions. streamlit_app.py is long, but much of it is broken into focused rendering functions like render_kpis, render_recovery_chart, and render_covid_context, which is a good sign of decomposition.
• Useful automated validation. The Pandera schema in validation.py is a strong quality signal; it shows the team is thinking about data contracts, not just visualization.
• Tests exist and cover core utility behavior. There are tests for data cleaning, validation, and ETL sanity checks, which is better than many small dashboard repos.
• Reasonable defensive coding. The BigQuery loader checks for missing columns, low row counts, API truncation risk, and bad date ranges before replacing tables. That’s a strong reliability practice.

Main code-quality concerns

1. streamlit_app.py is too large

At ~900 lines, streamlit_app.py is doing too much: page setup, sidebar config, filtering logic, KPI computation orchestration, chart construction, explanatory copy, and top-level control flow. That makes it harder to review, test, and evolve.

Examples:

• UI setup and CSS injection near the top
• data filtering and loading in main()
• many chart/render functions all in one file

Recommendation: split this into modules like:

• ui/layout.py
• ui/overview.py
• ui/comparison.py
• ui/events.py
• services/data_access.py
• services/metrics.py

That would improve readability and make unit testing easier.

2. Some logic is duplicated across files

The legacy/current MTA column rename mapping appears in both utils.py and validation.py, and a related rename map also exists in load_data_to_bq.py. That creates drift risk if the upstream schema changes again.

Examples:

• MTA_LEGACY_COLUMN_MAP in utils.py
• MTA_RENAME_MAP in validation.py
• MTA_RENAME_MAP in load_data_to_bq.py

Recommendation: centralize schema/column-name normalization in one module and import it everywhere.

3. Tests are good but still somewhat narrow

The tests cover important helpers, but they mostly target:

• basic happy paths
• a few error conditions
• schema validation checks

What’s missing:

• tests for streamlit_app.py logic
• tests for query-building behavior in _load_table
• tests for edge cases in rolling averages, empty selections, missing columns in visualizations
• tests for BigQuery access code via mocks

Recommendation: add unit tests around:

• _build_select_expressions
• _resolve_mta_columns
• get_recovery_with_delta
• get_weekday_weekend_comparison
• build_covid_context_frame

4. Query construction is serviceable but not very elegant

_load_table() in utils.py builds SQL via string interpolation. Because dates and columns are internally controlled, this is not immediately dangerous, but it’s less robust than using...

This pull request was created from Copilot chat.

[afeld]

Missed this step in Lab 6.