# Portfolio — Edwin Carin

**[Consulter le portfolio en ligne](https://portfolio.ecarin.com/)**

Mon parcours, mon expérience chez Norauto IT et mes projets personnels et de formation. Ce portfolio accompagne ma formation en architecture logicielle à Epitech et présente mon évolution du développement backend Java vers la data et l’automatisation, tout en gardant une place au web et aux interfaces.

## Intention

Je voulais un site qui permette de comprendre qui je suis avant de parcourir une liste de technologies. Les projets servent à illustrer mon travail : ils ne remplacent ni mon parcours ni mon expérience.

Deux vues permettent d’adapter la lecture :

- **Social**, la vue d’accueil : présentation, expérience, formation et centres d’intérêt, avec peu de vocabulaire technique.
- **Dev** : compétences, projets et dépôts GitHub, puis fonctionnement de mon infrastructure personnelle. Les détails se consultent à la demande pour éviter une longue liste d’informations à lire d’un seul bloc.

Je distingue l’expérience acquise des sujets en approfondissement. Kafka, Debezium, CDC, Transactional Outbox, Terraform et kro ne sont pas présentés comme autant de réalisations en production chez Norauto. Les travaux collectifs, prototypes et projets clients gardent leur contexte.

## Parcours de visite

1. Lire la présentation et le parcours dans **Social** ; essayer les onglets Interfaces, Données et Automatisation.
2. Passer dans **Dev**, explorer les compétences et les étapes du flux événementiel.
3. Rechercher un projet ou une technologie, filtrer par domaine ou contexte, puis ouvrir une fiche. Les dépôts GitHub associés et leurs statistiques figurent dans la même fiche.
4. Consulter la pipeline GitOps, le rôle des dépôts d’infrastructure et les services DEV / PROD.

Les deux vues sont disponibles sur mobile et ordinateur, en thème clair ou sombre. Les circuits animés expliquent un cheminement ; ils ne constituent pas un tableau de surveillance des services.

## Choix de conception

La composition repose sur une typographie lisible, des espaces, des surfaces claires ou sombres et un accent orange. Le langage visuel de ma landing Webstudio a servi de référence, sans donner au portfolio la structure d’une page commerciale.

Les illustrations sont des SVG intégrés au code, pas des captures de sites. Social privilégie une présentation accueillante ; Dev utilise des connexions animées et des étapes interactives pour expliquer les flux techniques. Les animations peuvent être mises en pause, s’arrêtent hors écran et respectent `prefers-reduced-motion`.

La navigation comporte des états sélectionnés et des focus visibles. Les onglets Social et le sélecteur de contexte disposent de commandes clavier ; les panneaux dépliables relient leurs commandes à leur contenu. Ces dispositions ne valent pas certification d’accessibilité.

## Stack et organisation

| Élément | Choix et rôle |
| --- | --- |
| Application | Next.js 16, App Router : accueil prérendu et routes API côté serveur |
| Interface | React 19 et TypeScript : composants, états de navigation et données typées |
| Styles | Tailwind CSS 4 et CSS personnalisé : composition, responsive et animations SVG |
| Thèmes et icônes | `next-themes` et Lucide |
| GitHub | Octokit côté serveur, pour ne pas exposer le token au navigateur |
| Vérifications | ESLint, tests `node:test` exécutés avec `tsx`, build Next.js |
| Exécution | Image Docker avec sortie Next.js `standalone` |

```text
src/app/                      Pages, styles globaux et routes API
src/components/               Vues Social / Dev et composants interactifs
src/context/                  État de la vue choisie
src/data/project-catalogue.ts  Fiches éditoriales des projets
src/lib/project-explorer.ts   Rapprochement du catalogue et de GitHub
src/lib/github.ts             Accès serveur à GitHub et catégorisation
src/lib/cached-loader.ts      Cache et gestion des indisponibilités
tests/                        Tests de données, rendu et comportements serveur
```

### Accueil indépendant de GitHub

Le contenu Social est présent dans le HTML initial. Aucune requête GitHub n’est nécessaire pour afficher la présentation.

À l’ouverture de Dev, le navigateur appelle `GET /api/projects`. Le catalogue éditorial reste immédiatement consultable ; les résultats GitHub le complètent ensuite. Les correspondances connues sont rattachées à leurs fiches, les autres dépôts restent recherchables dans le même explorateur. Les données reçues restent en mémoire pendant les changements de vue.

Les statistiques sont chargées séparément par `GET /api/languages?owner=…&repo=…`, lorsque les cartes correspondantes deviennent visibles. Les langages et commits décrivent les dépôts ; ils ne mesurent pas à eux seuls une contribution personnelle.

### Cache et erreurs

Le cache serveur des projets dure **10 minutes**. Les requêtes concurrentes partagent un rafraîchissement par processus, limité à **8 secondes**. En cas d’échec :

- les dernières données valides sont conservées avec `stale: true` ;
- sans données précédentes, l’API renvoie **503** et l’interface propose de réessayer ;
- un délai de **30 secondes** évite de relancer continuellement GitHub en erreur.

Ce cache n’est ni persistant ni partagé entre plusieurs instances. Un accès après redémarrage peut attendre GitHub, mais ne bloque pas l’accueil ni les fiches éditoriales.

## Exécution locale

Prérequis : Node.js **20.9 minimum** et npm. L’image du projet et la CI utilisent Node.js 20 ; les dépendances sont verrouillées dans `package-lock.json`.

```sh
npm ci
npm run dev
```

Ouvrir ensuite [localhost:3000](http://localhost:3000).

L’accueil et le catalogue éditorial fonctionnent sans token. Pour activer les dépôts GitHub, créer un fichier `.env.local` à la racine :

```dotenv
GITHUB_TOKEN=remplacer_par_un_token_de_lecture
GITHUB_USERNAME=xRezio
GITHUB_ORG=EpitechMScProPromo2026
```

Ces variables sont lues côté serveur. Ne pas utiliser de préfixe `NEXT_PUBLIC_`, ni committer le token ; les fichiers `.env*` sont ignorés par Git. Limiter les accès du token aux données destinées à être présentées : un token serveur ne rend pas privées les métadonnées renvoyées par l’API publique du portfolio.

## Tests et vérifications

```sh
npm test
npm run lint
npm run build
```

Les tests utilisent des données simulées, sans appeler GitHub. Ils couvrent le HTML initial sans requête bloquante, le cache, les appels concurrents, les délais et erreurs, les correspondances de dépôts, les filtres, la pagination et le rendu des composants.

Les contrôles visuels complètent ces tests : Social / Dev, clair / sombre, ordinateur / mobile, fiches ouvertes, sélection du contexte, animation et pause. Les tests de rendu serveur ne remplacent pas un test complet des interactions dans un navigateur.

## Hébergement et livraison

Le portfolio utilise mon infrastructure personnelle : **Hetzner, K3s / Kubernetes, Traefik et Argo CD**. L’adresse publique permet de consulter le résultat sans installation.

La chaîne configurée dans le dépôt est la suivante :

1. GitLab CI lance le lint et les tests sur les merge requests et sur `main`.
2. Sur `main`, la CI construit l’image Docker, ce qui exécute aussi le build Next.js, puis publie l’image dans le registre.
3. Le job `deploy_ops_prod` déclenche `homelab/apps-gitops` pour proposer la mise à jour de l’image de `portfolio` en PROD.
4. Après fusion du changement GitOps, Argo CD réconcilie l’application `portfolio-prod` à partir des déclarations et du chart partagé.

Le token GitHub est fourni **à l’exécution**, jamais intégré à l’image. Le site comprend des routes serveur : cette version n’est pas un simple export statique à copier sur GitHub Pages.

Une version présente sur une branche n’est pas automatiquement celle en ligne. Pour une remise, vérifier que l’adresse publique présente bien les fonctionnalités documentées et fournir aussi un accès au dépôt contenant ce README. Certains projets référencés et services personnels peuvent nécessiter leur propre authentification ; la visite du portfolio ne doit pas en dépendre.