DSQ#1 - miniWeather

Contexte

miniWeather est une petite application de bureau qui permet de rechercher la météo d’une ville, afficher les conditions actuelles et quelques jours de prévisions, tout en gardant une liste de villes favorites.

Le but de cette quête n’était pas de “sur-architecturer”, mais de produire un projet propre : API → parsing → UI → persistance + un devlog pour documenter les choix.

Dev Side Quest : mini-projet réalisé en temps limité pour apprendre vite, livrer quelque chose de fonctionnel, puis itérer.

Objectifs

• Rechercher la météo d’une ville
• Afficher les conditions actuelles (température, humidité, description…)
• Consulter les prévisions (implémenté : 3 jours)
• Sauvegarder une liste de villes favorites (implémenté : jusqu’à 5 villes)

Stack

• Python 3.8+
• Poetry (gestion des dépendances / environnement)
• OpenWeatherMap API (clé stockée via .env : API_KEY=...)
• Persistance simple en JSON (favorites)

Ce qui est implémenté

• Recherche de ville
• Affichage : température, humidité, description
• Prévisions sur 3 jours
• Sauvegarde de 5 villes favorites

Architecture rapide

L’idée est de garder une structure lisible, même sur un petit projet :

• src/api/weather_api.py : client API (requêtes, validation, mapping)
• src/cache/cache_manager.py : cache léger (évite de spam l’API + améliore la réactivité)
• src/data/favorites.json : stockage simple des favoris
• src/ui/ : composants UI (barre de recherche + affichage météo)

Ce que j’ai appris

• Packager vite un projet Python avec Poetry (setup propre + exécution reproductible)
• Gérer une API externe : erreurs, parsing, cases “ville introuvable”, et limites
• Garder une UI simple mais modulaire (séparer “data layer” vs “presentation”)
• Documenter le process via un devlog pour mieux itérer

Roadmap (améliorations possibles)

• Graphiques de température / tendances (sur plusieurs jours)
• Alertes météo (ex. pluie/orage) + notifications
• Géolocalisation
• Mode sombre / clair

Run local

poetry install
# ajouter .env à la racine
# API_KEY=<votre_clé_api>
poetry run python3 main.py

Vue d’ensemble

miniWeather est organisé comme un mini-produit :

• UI (interaction utilisateur)
• API client (requêtes, parsing)
• Cache (réactivité + limiter les appels)
• Persistance (favorites)

Flux “recherche de ville”

1. L’utilisateur saisit une ville dans la search bar
2. Le programme vérifie si une réponse récente existe en cache
3. Sinon, appel à l’API météo, puis normalisation des données
4. La UI affiche : météo actuelle + prévisions
5. Optionnel : ajout/suppression dans les favoris (persistés en JSON)

Découpage des responsabilités

• Data layer : API + cache + persistence
• Presentation layer : composants UI

Ce découpage garde le projet extensible (ajout de graphiques, d’alertes, de géoloc…) sans casser le core.

Structure du repo

miniWeather/
├── main.py
└── src/
    ├── api/weather_api.py
    ├── cache/cache_manager.py
    ├── data/favorites.json
    └── ui/
        ├── search_bar.py
        └── weather_display.py

API layer — weather_api.py

• Centralise la communication avec l’API météo
• Gère : requêtes HTTP, erreurs (ville inconnue, clé invalide, etc.), et mapping vers un format exploitable par la UI

Cache — cache_manager.py

• Ajoute une couche de cache simple pour :

• éviter de spam l’API

• rendre l’UI plus réactive
• Permet d’expérimenter un vrai pattern “product” (et pas juste un script)

UI — search_bar.py et weather_display.py

• Search bar : capture input, déclenche la requête, propose la logique “favorite”
• Display : affiche météo actuelle + prévisions sur plusieurs jours

Persistance — favorites.json

• Stockage volontairement simple : JSON (pas besoin de DB pour un DSQ)
• Contraintes : limiter le nombre de favoris (ex. 5) et garder un format stable

Points clés de robustesse

• .env à la racine : API_KEY=...
• Gestion d’erreurs lisibles (fail fast + message clair)
• Séparation UI / data pour faciliter le debug et les futures features