Mon CV / portfolio

17 minute read

Un projet personnel pour améliorer mon CV et Portfolio…

Le principal outil mobilisé pour créer un CV est le traitement de texte, un outil quasi incontournable pour la mise en forme de texte pour structurer, produire et diffuser de l’information. On peut inclure également les outils de présentations, tels que PowerPoint, qui peuvent s’avérer utiles pour mettre avant divers documents et constituer ainsi un portfolio pour illustrer plus concrètement ses compétences. Le CV reste un document plutôt cloisonné, qui se construit selon “la tradition”, avec notamment le fameux “pas plus d’une page, bon éventuellement 2, mais pas plus !”… Cela nécessite de faire des choix, de sélectionner les informations. Mais un CV peut être énormément fourni (de nombreuses expériences, compétences, un certain nombre de projets personnels…). Tout ceci tend à rendre la mise en forme complexe si on souhaite respecter les codes… Enfin ces outils demandent un travail manuel (rébarbatif) de mise en page… les changemens, ajouts détruisent tout simplement la mise en forme de votre document ! Cela m’est souvent arrivé lors de la mise à jour de mon CV ou encore de mon portfolio :

  • on ajoute de nouveaux évènements, compétences…
  • les années d’expérience augmentent et il faut les calculer à chaque fois (évitons de se tromper)…
  • on a réalisé de nouvelles choses et l’on souhaite les présenter… mais nous sommes contraints par ce format statique qui ne se prête pas à toutes les productions, surtout dans le développement…
  • on prend également le temps d’harmonise l’aspect graphique…

Et on finit par toujours être dessus 4 heures plus tard ! Bref, c’est la galère !

Ainsi, pourquoi ne pas proposer un autre moyen de diffusion, un nouveau format de son CV/portfolio ? La version papier/pdf subsistera et pourra embrasser pleinement la tradition. Paralèlement on aurait une version web complémentaire, dynamique, évolutive et probablement bien plus apte à illustrer, en détails, les facettes de son parcours. L’environnement web nous offre ainsi beaucoup plus de liberté pour :

  • proposer un contenu exhaustif, mais interactif et pouvant ainsi adapter la quantité de contenu ;
  • proposer d’autres représentations du parcours pour mettre en avant son parcours/orientation professionnelle (mise en valeur de la dimension spatio-temporelle) ;
  • intégrer au plus proche des expériences des productions/réalisations, interactives ou non ;
  • faciliter l’intégration des nouveaux éléments sans devoir de fond en comble la mise en forme ; Et plus en bonus, rien n’empèchera d’automatiser la création du CV “classique” !

Ce projet consiste donc de proposer mon CV-Portfolio sous la forme d’un site web en utilisant du Python, du code HTML/CSS et du JavaScript (puis TypeScript) ! Les paragraphes suivants tenteront de présenter son développement, ses multiples versions, les dififcultés et les limites rencontrées. Le développement sera progressif, du plus simple au plus complexe notamment sur les technologies utilisées.

Nous commencerons par une première solution développée principalement développée en Python avec Flask et ses templates HTML. Flask prendra en charge à la fois du backend et du front-end. Toutefois, nous devrons développer utiliser du JavaScript pour apporter de l’interactivité à nos pages. La seconde solution s’articulera autour de l’utilisation d’un framework web, Angular (avec TypeScript), pour la prise en charge du front-end. L’objectif sera de d’apporter une plus grande robustesse et simplicité dans le code du front. Flask, quant à lui, sera uniquement dédié au back-end et donc utilisé comme une API.

L’objectif n’est pas de rentrer en détails sur les aspects techniques, mais de présenter l’évolution de ce projet, chronologiquement, afin de déterminer les avantages, les inconvénients et les enjeux qui en découlent pour tenter d’apporter des solutions (et en profiter pour jouer avec divers technologies !). Le ressenti personnel, le retour d’expérience sur les technologies utilisées sera également présenté, on tentera de mettre en évidence les difficultés et leurs résolutions. Je sais… Vous vous dites probablement que je tente de tondre une pelouse avec un tank… Il est vrai que les technologie mobilisées peuvent être percues comme trop complexes pour l’objectif. On aurait pu être raisonable en utilisant Jekyll (par exemple) qui propose des templates relativement bien adaptés (TODO). Mais, cela ne répond pas totalement aux objectifs fixés, qui consistent à mettre en place des fonctionnalités très spécifiques. Et puis c’est plutôt intéressant de se lancer des défis !

Les objectifs

D’un point de vue général, nous souhaitons :

  • un CV orienté sur le thème de la cartographie (étant cartographe…), mais qui reste suffisamment neutre ;
  • mettre en valeur l’aspect spatio-temporel des informations ;
  • présenter les expériences professionnelles mais aussi personnelles accompagnées de toutes leurs illustrations (au sens large) ;
  • L’application doit être structurée et dynamique afin de faciliter l’intégration de nouvelles informations (nouvelles expériences, compétences, formations, réalisations…) sans apporter de modifier dans le code.

TODO : schema

Les différentes pages de l’application :

  • une page d’accueil pointant vers les autres pages ;
  • une page “profil” contenant le CV et les rubriques de bases (formations, expériences, projets personnels, compétences) ;
    • Une sous-page avec le CV simplifié et pouvant être aisément imprimé ;
    • une sous-page “carte” pour localiser chaque expérience / établissement de formation, et les symboliser en utilisant la variable taille en fonction de leur durée ; également la mise en valeur des déplacements domicile-travail en animant ces déplacements ;
  • une page “galerie” dynamique organisée par type d’activité (professionnelles, personnelles) par expérience, par type de médias ;
  • une page “notes” ou plutôt blog qui contiendra différents articles pouvant être lié au contenu de la page “profil”.

La page “profil” doit être le coeur de l’application, c’est-à-dire :

  • proposer des liens avec les autres pages, du moins chaque expérience pourra liée aux différentes pages (cartographiquement, avec les réalisations présentes dans la galerie, le blog) ;
  • mettre en place un graphe d’activité interactif illustrant le parcours professionnel et les compétences pour :
    • mettre en évidence les orientations du parcours ;
    • les relations entre les différentes expériences/projets personnels ;
    • filtrer thématiquement et temporellement le contenu de la page “profil” afin de proposer un CV “à la carte”
  • le contenu doit pouvoir être facilement accessible.

Nous évoquerons la problématique de l’hébergement de l’application progressivement ; cette dernière pourrait fortement évoluer au cours du développement. L’idée globale est d’utiliser Heroku ainsi que Github Pages.

Les données

Les premières questions qui se posent, au début du projet, se concentrent autour des données. On a plusieurs impératifs… Les données doivent :

  1. être facilement modifiable, en dehors de l’applications ;
  2. respecter un schema de données suffisamment précis pour éviter les erreurs de données ;
  3. couvrir l’ensemble des points composants un CV ;
  4. Suffisamment robuste pour éviter d’apporter des complications pour le développement de certains mécanismes (le graphe d’activité).

Ainsi nous avons choisi de répondre à ces enjeux de la manière suivante:

  1. utilisation d’un fichier YAML pour stocker les données:
    • simple à lire et à modifier
    • facilement manipulable en Python (dictionnaire)
    • stockable sur Github Gist, il suffira juste de récupérer son url, et seule cette dernière pourra changer
  2. définition d’un JsonSchema pour s’assurer de la validité de la structure du fichier YAML avant tout utilisation des données
  3. malheureusement, il est toujours difficile de tout couvrir au départ. En développant, de nouveaux élements sont nécessaires et doivent être ajoutés dans le fichier YAML (et JsonSchema)
  4. par expérience, il faut rester simple, pragmatique dès le départ ; et éventuellement complexifier uniquement si nécessaire. Le choix a été de garder une structure assez classique, très lisible à l’image d’un CV. Cela facilitera la mise à jour des informations et de l’application. TODO exemple

On utilisera également des fichiers GeoJson, lié au fichier YAML, pour stocker les données qui seront affichées sur la carte (les déplacements domicile-travail).

1ère version: Utilisation de Flask comme application web

Avant propos

Le développement de cette première version utilisant uniquement Flask a débuté en juillet 2020 pour aboutir à une version finale au mois de Janvier 2021.

Voici le résultat du portofolio développé unique avec Flask : Accès au portfolio

Technologies utilisées

  • Python:
    • Flask: API + gestion des templates HTML ;
    • Pandas & Geopandas: pour le traitement des données.
  • JavaScript:
    • JQuery: pour manipuler les élements des pages web ;
    • Leaflet: pour le fond cartographique et l’intégration d’objets SVG ;
    • D3js: pour la génération des données sur la carte et la génération du graphe sur la page “profil”.
  • HTML/CSS:
    • Bootstrap
  • Intégration & déploiement:
    • Testé (pytest + Selenium) avec Github Actions ;
    • Déploiement avec Gituhb Action sur un serveur Heroku.

Précisons que l’application est contenu dans un dépôt unique. Elle est automatiquement déployé (avec Github Actions) sur le serveur Heroku dédié, à chaque changement de la branche “master” du dépôt, sous réserve que les tests unitaires (Pytest) aient été tous validés. Selenium est également mobilisé pour tester quelques éléments de l’interface web (un aspect qui aurait pu être largement plus dévelopé).

Structuration

L’application ici forme un tout capable de supporter à la fois des composants du back-end et du front-end, et l’ensemble s’articule sur plusieurs éléments :

  • des processus de transformation de données appelés par …
  • …des routes qui vont permettre les diffuser dans des contenus prenant la forme de …
  • … template HTML (Jinja)
  • et des fichiers Javascript assurant le dynamisme du contenu et répondant aux objectifs (graphe, cartes, contenu dynamique…)
Architecture du Portfolio sous Flask (v1.6).

L’ensemble des différentes rubriques du site web se base donc sur le contenu du fichier YAML, en y apportant (en Python avec principalement Pandas, geGeopandas) un certain nombre de retraitements et calculs, par exemple :

Pour la page “Profil”:

  • aggrégation de l’ensemble des compétences thématiques, techniques, logiciels de chaque activités (professionnelles et personnelles) pour générer une <div> “compétences” dédiée ;
  • calcule la durée d’expérience de chaque mission et son total (pour l’entête) ;
  • génère un CV classique aisément imprimable, avec les éléments essentiels du parcours. Cette page dispose d’une sous-page “Carte” qui permet de mettre en valeur l’aspect géographique au CV au travers d’une carte interactive (avec Leaflet et D3js). Cela offre une vision de ma mobilité, et puis étant géomaticien je n’ai pas pu m’en empêcher de proposer une carte !

On trouve également le graphe interactif. Celui-ci a été développé avec D3Js et intégré dans la sous-rubrique “Navigation”. Cet élément doit être perçu comme un outil de navigation. Il propose une approche plus visuelle du CV en mettant en évidence les relations entre les expériences et les compétences acquises. Son interactivité permet à l’utilisateur de filtrer le contenu du CV pour évaluer au mieux le parcours et ses différents aspects. Techniquement, ici on injecte des templates HTML pré-calculés (en python), qui contiennent uniquement les données à afficher, au sein du template de la page “profil”. Nous avons deux routes (INDIQUER NOMS), une pour chaque <div> à remplir (Compétences, Expériences + Projets personnels), qui sont apelées par le code JavaScript du graphe selon les actions de l’utilisateur. TODO : add code example ? Ceci nous permet ainsi :

  • d’injecter uniquement les données nécessaires: on réduit la masse des données, mais on multiplie les appels aux routes ;
  • d’éviter de créer des mécanismes complexes, voir des bricolages (évite de jouer avec le CSS par exemple), en JavaScript ;

La page “Cartes” joue le rôle de portfolio: On y trouve toutes les productions (tous médias confondus) de chaque expérience/projet.

Limites et conclusion

Voici quelques observations générales qui pourraient faire l’objet d’amélioration:

  • la carte de localisation des expériences pourrait devenir une rubrique à part entière, même si elle est étroitement lié à la page profil. Cela aurait l’avantage de simplifier le mécanisme d’affichage ;
  • la galerie n’est pas très pratique à parcourir et visuellement trop lourde ;
  • l’interface de la carte et de la galerie qui reste grossière.

Cette première version de l’application montre que l’usage de Flask impose une forte imbrication de chaque briques: python, HTML/CSS et JavaScript. Ceci peut avoir des impacts assez lourds en terme de maintenance et de mises à jours, car il n’y a pas réellement de séparation du SoC (LINK TODO). Pour des projets avec peu de pages web à afficher ou peu complexes, voir pour une unique page, l’usage de Flask est jouable ; sinon il vaut mieux préférer Django (si l’on souhaite rester en python). Concernant le code Python, il n’y a pas réellement de limitations, contraintes dans la mesure où elle est plutôt bien maitrisée. Les données à traiter restent très simples, peu volumineuses. Les libraries Pandas et GeoPandas permettent d’être très efficace. Les limites sont plutôt du côté des briques JavaScript, en effet elles manquent de structuration, ce qui rend leur lecture et leur maintien plutôt difficile. De nombreuses fonctions produisant des évènements ont été développés sur les élements des pages web. Il manque un liant, une cohérence entre tous toutes ces fonctions qui permettrait de s’y retrouver plus aisément. Cette multiplicité a pour effet de masquer la logique développée (malgré les commentaires), de nous la faire oublier : la maintenance, les mises à jours deviennent vite laborieuses. A noter que l’on reste ouvert sur la question : cette observation est peut-être dûe à un manque d’expérience en JS. L’utilisation de librairie D3js a été également piquante (pour la timeline de la carte, l’affichage des objets cartographique, le graphe…). La documentation est plutôt difificle à appréhender, de plus on apprend surtout grâce aux exemples, en expérimentant et parfois ce n’est pas très intuitif. Mais son usage paraît pourtant essentiel pour obtenir un rendu vivant ; aussi bien pour le graphe que pour la cartographie. Pour cette dernière, la librairie Leaflet seule ne permet pas vraiment de donner cette vivacité. C’est un peu douloureux, mais on s’en sort, surtout que le résultat en vaux la peine.

Pour arriver à une solution plus aisément maintenable et robuste, il faudrait peut-être se diriger vers l’utilisation d’un framework web. Celui-ci pourrait offrir un front-end plus sain. Toutefois, une refonte sera nécessaire dans la mesure où un framework tel qu’Angular, par exemple, prône une tout autre approche. Une refonte qui s’imposerait aussi du côté back-end où il ne serait plus question d’utiliser les templates HTML ; le back-end devra se limiter à une “simple” API.

2ème version: utilisation du framework Angular pour le front-end

Avant propos

Le développement de cette deuxième version a débuté en février 2021 juqu’au au mois de mars 2021 où une première version stable a été achevée. Le développement continu depuis !

Voici le résultat du portofolio développé avec un back-end Flask et un front-end sous Angular : Accès au portfolio

Technologies utilisées

Back-end:

  • Python:
    • Flask: API ;
    • Pandas & Geopandas: pour le traitement des données.
  • Intégration & déploiement:
    • Testé (pytest) avec Github Actions ;

Front-end:

  • Angular (avec TypeScript):
    • Leaflet: pour le fond cartographique et l’intégration d’objets SVG ;
    • D3js: pour la génération des données sur la carte et la génération du graphe sur la page “profil”.
  • HTML/CSS:
    • Bootstrap
  • Intégration & déploiement:
    • pas encore testé, juste déployé avec Github Actions ;

A présent l’application se compose de 2 dépots :

  1. dédié au back-end, uniquement en python avec l’API Flask ;
  2. dédié au front-end sous Angular

Structuration

TODO : présentation Angular

Architecture du Portfolio avec Flask et Angular (v2).

Ce passage vers Angular s’apparente plutôt à une refonte totale du portfolio dans la mesure où cela nous oblige (et pour la bonne cause) à compartimenter le backend et le front-end. Précédemment, ces derniers restaient étroitement liés, le back-end s’occupant de la génération des pages. Avec Angular, tout change…

  • le back-end doit se limiter à fournir des données, donc à l’aide d’une API
  • le front-end avec Angular :
    • doit communiquer directement avec les différentes routes de l’API développée avec Flask ;
    • s’occupe du rendu des différentes pages web, ceci offrant une plus grande souplesse que les template Flask ;
    • offre un environnement structuré pour intégrer et améliorer la logique JavaScript développée précédemment. Celle-ci devra être convertie en TypeScript ;
    • est capable de gérer plus simplement certains mécanismes précédemment développés en Python (par exemple la gestion des images avec les assets d’Angular qui nous permet de supprimer la route Flask dédiée, ou encore s’affranchir de certains “bricolages” côté back-end).

Nous avons ainsi clairement 2 environnements utilisant des technologies bien spécifiques pour des objectifs différents, et qui peuvent donc suivre leur propre vie de développement et de mise à jour. Ceci est un avantage non négligeable, car nous réduisons drastiquement l’interdépendance des composants de nos applis et ainsi sa complexité. Il est à présent possible de suivre plus aisément l’évolution des librairies mobilisées aussi bien du côté du back-end avec ses librairies en python que du côté du front-end avec npm. Les mises à jour sont plus rassurantes et les potentielles erreurs moins catastrophiques et plus facilement localisables.

Angular apporte le concept de composants. Chaque objet (ou ensemble d’objets) d’une page web peut être considéré comme un composant, qui possède sa propre logique fonctionnelle, pouvant interagir avec d’autres composants. Ceci offre une structure idéale (POO) pour redévelopper le code JavaScript existant. JQuery n’a plus lieu d’être utilisé grace aux différents mécanismes d’Angular (binding) qui permettent de changer les états des éléments de notre page (qui se base sur des variables). Le code devient moins brouillon, bien plus structuré, même si la verbosité du framework peut, au premier abord, rebuter.

L’utilisation de D3js reste délicate. En effet cette librairie n’est pas adaptée aux fonctionnalités d’Angular, mais aucune difficulté n’a été rencontrée pour intégrer et convertir le code déjà développé (pour le graphe, la carte) au sein de plusieurs composants.

Intégration des données dans PostgreSQL/PostGIS

Allons encore un peu loin…

Comme évoqué, les données d’entrée sont stockées dans un fichier YAML. Ensuite elles sont :

  • lues sur Github gist;
  • structurées, précaculées et diffusées (Heroku);
  • et enfin affichée au sein d’un ensemble de page web (Github Pages).

Chaque interaction, clic sur le site web enclenche ce processus. Cela a quelques incidences sur le temps de réponse du CV/Portfolio. Elles restent minimes, de l’ordre de quelques millisecondes. En effet, nous sommes dépendant de l’état des serveurs de Github Gist, ou encore d’Heroku qui peuvent être plus ou moins lents. Même si le contenu du YAML n’est pas très volumineux, le retraitement peut éventuellement prendre un peu de temps.

On remarque ainsi une répétitivité inutile des traitements qui peut nous faire perdre un peu de réactivité. On pense notamment au graphe d’activité Les élements nécessitant d’être calculée en temps réels pourront être réalisés par le back-end (calcul de l’expérience totale…). Ainsi, nous avons choisit d’ajouter une phase préparatoire des données afin de pré-traiter nos données et de les stocker dans une base de données (BDD) PostgreSQL/PostGIS (toujours sur Heroku). Le back-end communiquera directement avec cette BDD. Pour cela, un certain nombre d’étapes ont été nécessaires :

  • créer un Modèle Conceptuel de Données (MCD), qui soit apte à gérer plusieurs CV (de plusieurs individus);
  • une nouvelle étape pour intégrer les données dans la base de données ;
  • une importante révision du back-end qui devra interroger la base de données à l’aide de Sql/GeoAlchemy.
Architecture du Portfolio avec Flask couplée à une base de données PostreSQL, Angular (v3).
Structure de la base de données.

On notera que le front-end n’a pas eu besoin de mises à jour majeurs…

L’utilisation d’une BDD offre de nombreux avantages :

  • Un MCD est intrinsèquement contraignant et permet de s’assurer de la validité des données
  • Un MCD permet de structurer simplement nos données: pré-calculs stockés de manière pragmatique, en fonction des besoins ;
  • l’emploi du SQL qui permet d’avoir de très bonnes performances et apporte beaucoup de lisibilité et de confort à mon sens.

Afin de faciliter cette importante mise à jour, une librairie annexe a été développée “Geolib” afin d’apporter des fonctions génériques pour l’intégration des données dans une BDD en lien les DataFrame (Pandas, geopandas). Le traitement qui était réalisé systématiquement à chaque clic de l’utilisateurs ne sera donc fait qu’une seule fois.

Limites et conclusion

TODO Du code… Beaucoup de codes !! Mais quelle souplesse…

Le déploiement, une approche plus large

TODO

  • schema org globale
  • déploiement docker

Conclusion

Une des premières questions qui se posent est sa maintenabilité dans le temps. Un CV doit tenir dans la durée, et n’est mis à jour que ponctuellement et de manière espacée dans le temps. En effet, plusieurs éléments sont à prendre en compte :

  • suivre l’évolution des nouvelles versions de Python et des libraires mobilisée (Flask, Jinja2, pandas, GeoPandas…) ;
  • maintenir les tests unitaires ;
  • l’évolution des libraires JS mobilisées (D3js, Leaflet) et des nouvelles ;
  • profiter des évolutions de Bootstrap.

Il apparait donc évident que le maintien de ce type de CV est beaucoup plus complexe qu’avec des outils de traitements de texte. Néanmoins, le rendu dépasse de très loin celui atteignable avec ces derniers…

TODO

Comments