L'autoroute vers des applications pérennes
Bootstraping efficace, Type-Driven Development, Test-Driven Development, Architecture Hexagonale : mettez le métier au centre de vos solutions.
200 € ht
Accès permanent, contenu actuel et à venir
Épisode 01 : Sujet et Bootstraping
Pourquoi IHexa ?
IHexa, c'est une formation hands-on qui vous donnera les clés pour construire rapidement des applications faites pour durer. Elle a été pensée pour vous faire gagner du temps dans votre montée en compétences sur l'architecture hexagonale et les pratiques communément admises dans la communauté Software Craftsmanship.
Architecture Hexagonale
Centrez vos solutions sur le métier pour accueillir sereinement les changements et faciliter les interactions avec les parties prenantes.
Software Craftsmanship
TypeDD, TestDD, BDD, DDD : accélérez votre montée en compétences sur ces pratiques plébiscitées par la communauté Craft
Exercices pratiques
Entrainez-vous en suivant les vidéos et mettez directement en pratique dans votre quotidien
Livraison continue
Mettez en place des pipelines de CI/CD et mettez sereinement en production plusieurs fois par jours
Qui sommes-nous ?
Deux devs passionnés, soucieux de partager des approches ayant largement fait leurs preuves, depuis des années et dans des contextes très variés
Colin
Développeur, auteur, speaker, coach
J'accompagne les équipes pour produire rapidement des applications de qualité
Programme
Partie 1 : Un front en prod
Épisode 1 : Sujet et boostraping (3:48)
Présentation du sujet qui sera le fil rouge de la formation et boostraping d'un frontend en Vue.js
Épisode 2 : Des notes avec des types (5:30)
Création d'un premier Domain Model, uniquement avec des types pour noter clairement les informations qui ont été présentées lors du "brief" de lancement
Épisode 3 : Un peu de théorie sur l'archi Hexa (2:33)
Présentation théorique de l'architecture hexagonale dans le front. Une fois n'est pas coutume : pas de code dans cet épisode, juste des slides.
Épisode 4 : Une première page drivée par des tests (4:56)
L'épisode commence avec la mise en place de Cypress pour pouvoir créer des tests de composant. Pas des composants au sens "front" mais des composants au sens : l'application qui va être livrée.
Une fois l'outillage mis en place :
Création d'un premier test pour afficher une "Invoice" ;
Création d'une page et du routing vers cette page.
Épisode 5 : Gestion des chargements (2:01)
Mise en place de l'outillage pour la gestion du chargement des éléments dans les pages.
Épisode 6 : Test du chargement (0:51)
Création d'un test pour s'assurer que la phase de chargement de la page est terminée
Épisode 7 : Chargement d'une facture (8:28)
Récupération des données d'une "Invoice" depuis un adapteur secondaire ce qui implique de passer par toutes les "couches" de l'hexagone et, de fait, la mise en place de la mécanique d'injection
Épisode 8 : Commit et brain dump (1:17)
Commit du travail fait et explication d'une astuce de gestion de la charge mentale
Épisode 9 : Gestion des erreurs (3:26)
Ajout de la gestion de l'affichage d'une Invoice en erreur dans l'interface ce qui implique la capacitèe à avoir une Invoice en erreur dans l'adapter InMemory
Épisode 10 : On ajoute Optional (3:41)
Ajout de Optional en TypeScript ce qui implique de retravailler l'ordre des commits pour garder quelque chose de logique. S'en suit un refactoring pour utiliser cette nouvelle logique
Épisode 11 : Affichage du contenu de la facture (2:46)
Premier affichage très simple du contenu d'une Invoice
Épisode 12 : On découpe en composants (4:01)
Découpage du composant de la page du détail d'une Invoice en trois :
Loader ;
Details ;
Error.
Épisode 13 : On sert le front (3:01)
Mise en place de la mécanique pour servir l'application front. Ici, nous avons fait le choix de servir le front par une application Spring.
Épisode 14 : Suppression de la page home (1:43)
Suppression de la page home qui n'est pas utilisée
Épisode 15 : Partage du travail (3:37)
Création d'un repository et des outils pour organiser le travail
Épisode 16 : Oops... Je n'ai pas supprimé un test ! (2:17)
Suppression d'un test oublié lors de la suppression de la page home
Épisode 17 : Une intégration continue simple (3:46)
Configuration d'une intégration continue pour le projet
Épisode 18 : Déploiement en prod (sur CleverCloud) (4:30)
Mise en place d'un déploiement continu à chaque merge sur main. Vous pouvez, évidemment, utiliser un autre provider, ça n'a pas beaucoup d'impact
Épisode 19 : Wrap up (1:55)
On revient rapidement sur l'ensemble des décisions qui ont amené à l'état actuel : architecture, déploiement et organisation du travail.
Partie 2 : Un back en prod
Épisode 20 : Une intro au TDD (6:40)
Introduction théorique au développement dirigé par les tests : Test-Driven Development
Épisode 21 : On choisit notre école (1:10)
Choix d'une école de TDD : London, Chicago, Inside-Out, Outside-In et autres querelles de clocher
Épisode 22 : Un premier Domain Model (10:01)
Création d'un premier Domain Model pour nos Invoices
Épisode 23 : Arrondi des montants (4:11)
Ajout des règles d'arrondi sur les montants, évidemment : le tout piloté par les tests. On en profite pour faire des tests paramétrés
Épisode 24 : Ajout d'un identifiant (3:22)
On ajoute des identifiants sur les factures. Les tests deviennent peu lisibles : on crée une fixture pour mieux organiser les données de test
Épisode 25 : Création de Recipient (9:16)
Ajout du Recipient dans Invoice
Épisode 26 : Invoice en class (3:38)
Refactoring de Invoice en class et préparations pour la suite : le modèle primaire
Épisode 27 : En fait, le coverage était OK :D (0:41)
Après vérification de l'analyse de coverage : tout vas bien
Épisode 28 : Modèle primaire d'Invoice (15:29)
Création du modèle primaire RestInvoice pour la sérialization de nos Invoice
Épisode 29 : On fait le bilan (4:50)
On regarde où on en est, le temps de faire une self-review et de se noter quelques tâches pour la suite puis on merge
Épisode 30 : Documentation de l'API (6:12)
Ajout de l'outillage nécéssaire pour faire la documentation et documentation de l'API actuelle
Épisode 31 : Montée des versions (4:16)
On a laissé le projet de côté trop longtemps : certaines versions sont incompatibles, on gère tout ça.
Épisode 32 : Documentation des building blocks (5:00)
Ajout d'annotations de documentation dans notre Domain Model, on en profite pour faire une courte introduction à certains building blocks du DDD
Épisode 33 : Organisation du "backlog" (5:23)
On organise un peu les tâches, et on commence à parler du contexte des clients : l'occasion de parler du découpage du travail
Épisode 34 : Test pour la récupération d'une Invoice (7:50)
Création du test Cucumber qui va piloter la création du endpoint de récupération d'une Invoice
Épisode 35 : L'architecture hexagonale dans le back (3:53)
Présentation théorique de l'architecture hexagonale dans le back
Épisode 36 : Endpoint de récupération d'une Invoice (13:36)
Création du endpoint de récupération d'une Invoice, en passant par toutes les couches de l'architecture
Épisode 37 : Appel du Webservice depuis le front (16:57)
Remplacement du repository in-memory du front par un repository qui appelle le WebService exposé par le back
Épisode 38 : Label et déploiement (6:21)
Ajout du label dans les Lines dans le back et déploiement des deux MR en cours
Épisode 39 : Intégration Vue I18next (6:00)
Ajout des traductions avec Vue I18next dans le front
Épisode 40 : Ajout du favicon (2:25)
Ajout du Favicon
Épisode 41 : Les courses dans JHipster Lite (5:59)
On fait nos courses dans JHipster Lite : tests d'architecture et Actuator
Partie 3 : Des paillettes dans le front
Épisode 42 : Initialisation de la pattern library (7:33)
Création d'une pattern library en atomic design avec TikUI et configuration aux couleurs de IHexa
Épisode 43 : Création de l'atom recipient name (5:32)
Création de l'atom "Recipient name" dans la pattern library
Épisode 44 : Remplacement de recipent name... (6:49)
Modification du rendu des placeholder et création d'une alternative au paragraphe qui permet la suppression du composant recipient name
Épisode 45 : Gestion des espacements (7:19)
Intégration du placeholder et gestion des espacements des éléments
Épisode 46 : Des lines et des columns (5:27)
Intégration des espacements et utilisation de line et column pour garder des espacements cohérents
Épisode 47 : Création de l'organism card (10:03)
Création d'une card pour regrouper nos éléments avec des alternatives pour le spacing et pour s'adapter au contenu
Épisode 48 : Suppression des gaps et largeur de placeholder (2:53)
Suppression de gaps oubliés dans les épisodes précédents et ajout d'une largeur sur le placeholder
Épisode 49 : Organism table (10:14)
Création et intégration de l'organism table
Épisode 50 : Mise en forme de la page (3:26)
Mise en forme des blocks dans la page
Épisode 51 : Tuning du tableau (5:05)
Mise en forme de notre tableau avec une colonne qui prend toute la largeur
Épisode 52 : Placeholder du tableau (5:01)
Création du placeholder (pour les chargements) du tableau
Épisode 53 : Error atom (4:11)
Création de l'atom pour afficher le message d'erreur
Épisode 54 : Self review (3:57)
Revue de la MR avec l'ajout du CSS, création de tickets pour la suite et problème de build
Épisode 55 : Correction d'un problème de build (4:24)
Correction du problème de build, vous n'aurez pas à le faire, c’est fixé dans JHipster Lite :)
Épisode 56 : Découpage du composant Invoice (3:08)
Découpage du composant Invoice pour avoir recipient et lines dans des composants dédiés
Partie 4 (à venir) : Un nouveau context front : les clients
Partie 5 (à venir) : Les clients dans le back
Partie 6 (à venir) : On persiste les données
Prêt·e à changer
ta vision du dev ?
Livrer en retard des produits buggés, c'est la norme dans l'industrie du développement. Mais ce n'est pas normal ! Rejoins IHexa et apprends à livrer en avance des produits sans bugs.
200 € ht
Accès permanent, contenu actuel et à venir
Quelques infos
Les exemples sont donnés sur une application en Vue.js/TypeScript pour le front-end et en Spring/Java pour le back-end.
Nous utilisons JHipster Lite pour bootstraper les projets, mais il est tout à fait possible de faire cette configuration manuellement.
Les approches et méthodes présentées sont parfaitement transposables dans d'autres technologies.
Cette formation s'adresse plutôt à des devs expérimenté·e·s et qui ont commencé·e·s à s'intéresser aux approches abordées.
Il est, bien sûr, possible de suivre la formation sans ces prérequis, mais ce sera probablement un vrai challenge !
Il faut nous donner de l'argent :).
Ce sont des vidéos et du code, tu les consommes à ton rythme !
Techlag EURL
96 ter avenue Paul Painleve, 01500 Amberieu en Bugey
Mail : adrien.turpin@hotmail.fr
Tel : +33 6 75 13 13 83
Siret : 982 712275 00014
TVA : FR26982712275
Hébérgé sur systeme.io