TuneSage Devlog: Week 1 Day 1

Daniel Paquin
May 2
3 min read

“Engage”

Today marks the successful completion of Week 1 Day 1 for TuneSage’s Data Analyst phase. I began by initializing my GitHub repository and scaffolding a clear, logical project structure. This setup ensures any future collaborator—or interviewer reviewing my portfolio can instantly understand where code, data, and documentation live. I chose a public repo with an MIT license to maximize visibility and encourage reuse, demonstrating transparency and open‑source best practices.

# Phase 1: Repo scaffold
git init TuneSage
mkdir -p src data/{external,raw,processed} notebooks reports figures tests
touch README.md .gitignore requirements/{base.in,dev.in}
git add .
git commit -m "chore: initial project scaffold"

“Red Alert!”

Next, I encountered common onboarding hurdles: pushing directly to main was blocked by branch‑protection rules, and my first attempt to import pandas failed due to missing dependencies. I addressed these proactively—creating a dedicated dev branch to enforce pull‑request workflows, and adopting pip‑tools to manage and lock my Python dependencies—so that my environments remain consistent across machines and CI pipelines.

# Create and protect dev branch
git switch -c dev
git push -u origin dev
# Fix missing pandas
cat > requirements/base.in <<EOF
pandas>=2.2
numpy>=1.26
EOF
pip-compile requirements/base.in -o requirements.txt
pip-sync requirements.txt

Why: Enforcing pull requests with branch protection mirrors professional team workflows and prevents accidental pushes; locking dependencies guarantees reproducibility and eliminates “works‑on‑my‑machine” issues.

“Tea, Earl Grey, Hot”

With the foundations secure, I elevated my code quality by integrating pre‑commit hooks. I selected Black for formatting, isort for import sorting, and Flake8 for linting, all orchestrated via a single .pre-commit-config.yaml. This automated style enforcement saves review time and maintains consistency, signaling to hiring managers that I prioritize clean, maintainable code.

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/psf/black
    rev: 24.3.0
    hooks:
      - id: black
        language_version: python3.12

  - repo: https://github.com/PyCQA/isort
    rev: 5.13.0
    hooks:
      - id: isort

  - repo: https://github.com/pycqa/flake8
    rev: 7.0.0
    hooks:
      - id: flake8

  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.5.0
    hooks:
      - id: end-of-file-fixer
      - id: trailing-whitespace

# Install and run hooks
pip install pre-commit
pre-commit install
pre-commit run --all-files

Why: Automating formatting and linting at commit time preserves code quality without manual effort, reflecting mature engineering practices.

“Make it So”

Finally, I put in place my CI pipeline using GitHub Actions. My single lint-and-hooks workflow checks out the code, installs pinned dev dependencies, and runs pre‑commit hooks on every push or pull request. This protects main against regressions and demonstrates my ability to integrate DevOps principles into analytic projects.

# .github/workflows/ci.yml
name: CI

on:
  push:
  pull_request:

jobs:
  lint-and-hooks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.12'
      - name: Install dev dependencies
        run: |
          pip install pip-tools
          pip-sync dev-requirements.txt
      - name: Run pre-commit hooks
        run: pre-commit run --all-files --show-diff-on-failure

git add .github/workflows/ci.yml
 git commit -m "ci: add lint-and-hooks workflow"
 git push

Why: Continuous integration ensures every change meets my style and quality gates before merging, a non‑negotiable standard for a production‑grade codebase.

“Plot a course”

Tomorrow’s objectives (Week 1 Day 2):

Branch off: git switch -c feature/02-import-dataset
Data ingestion: Retrieve the first external dataset into data/external/.
Quality assurance: Execute null‑value counts, schema validation, and range checks with pandas.
Initial EDA: Document findings in reports/eda.md and export summary visuals to figures/.
Pull request: Push the feature branch, open a PR to main, and merge once CI passes.

With my Day 1 scaffold complete—public repo, clear structure, locked dependencies, automated style enforcement, and CI in place—I’m ready to boldly analyze where no analyst has gone before.