Enocre une ressource sur l'archi hexa, ça fait pas de mal !
Je viens de mettre à jour cet article que j'avais écrit il y a quelques temps.
Je garderais les mêmes questions !
Et toi ?
Quelles questions poses-tu en entretien ?
Derniers commentaires :
Benoit GANTAUME
il y a presque 5 ans
Merci Maxime pour ton retour. Clairement si tu sens que ça met mal à l'aise, il vaut mieux lever le pied et appuyer un peu moins.
Après, la question que je me pose est la suivante : est-ce que tu as envie de bosser dans ce genre de contexte ?
Au moins si tu dis oui, tu sais à quoi t'attendre...
Après, la question que je me pose est la suivante : est-ce que tu as envie de bosser dans ce genre de contexte ?
Au moins si tu dis oui, tu sais à quoi t'attendre...
Bruno Raby
il y a presque 5 ans
Oui, effectivement ces questions sont techniques et appuient là où cela "pourrait faire mal" pour l'entreprise dans laquelle vous postulez. Elles sont destinées à vous rendre compte avec le plus de justesse possible dans "quoi vous mettez les pieds". A mon avis, il ne faut pas les poser toutes les unes à la suite mais vous devez vous adapter en fonctions des réponses données.
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
Aujourd'hui, je vais te montrer les pires bouts de code que j’ai jamais vus. Des sataneries qu'il ne faut surtout pas produire !
Derniers commentaires :
Benoit GANTAUME
il y a presque 5 ans
Salut,
Par personnellement, mais j'ai vu ça en coaching d'équipes.
Fuir est une option rapide.
Défendre sa cause est plus long et plus impactant sur à terme. Mais il faut en avoir la patience et l'envie.
Si tu aimes le côté évangéliste, c'est intéressant à faire. Si tu veux juste coder dans de bonnes conditions, tu as probablement plus vite fait de changer d'environnement.
Par personnellement, mais j'ai vu ça en coaching d'équipes.
Fuir est une option rapide.
Défendre sa cause est plus long et plus impactant sur à terme. Mais il faut en avoir la patience et l'envie.
Si tu aimes le côté évangéliste, c'est intéressant à faire. Si tu veux juste coder dans de bonnes conditions, tu as probablement plus vite fait de changer d'environnement.
Marc Tourneux
il y a presque 5 ans
Salut,
Je n'ai pas pris la peine de défendre mon point de vue car je suis le principal développeur. Les personnes opposées étaient les chefs de projet, qui ne touchent que très ponctuellement au code... et qui étaient beaucoup intéressées à définir la place de l'accolade pour le "if" (retour à la ligne ou pas ?! ça c'est un grand débat !)
Je n'ai pas pris la peine de défendre mon point de vue car je suis le principal développeur. Les personnes opposées étaient les chefs de projet, qui ne touchent que très ponctuellement au code... et qui étaient beaucoup intéressées à définir la place de l'accolade pour le "if" (retour à la ligne ou pas ?! ça c'est un grand débat !)
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
C'est quoi la modélisation d'une architecture logicielle à l'aide du modèle C4 ? Je connaissais bien UML et l'outil qui va avec Enterprise ...
Derniers commentaires :
Florian Luce
il y a presque 5 ans
Merci pour ce partage je ne connaissais pas cette "methodo". Forcé de constater avec le temps que peut importe le projet et sa taille à partir du moment où tu as besoin de communiquer c'est un formidable outil. Et je rejoins Bruno sur la nécessité d'adapter la méthode et le cadre aux spécificités et besoins réels du projet, c'est là où UML et son mécanisme de profil est très intéressant pour créer un metamodel aligné sur les besoins du projet.
Emmanuel Ernest
il y a presque 5 ans
Ce que j'aime dans le modèle C4, c'est la simplicité avec laquelle on peut transmettre une intention.
Cela permet d'avoir une méthode de communication claire et lisible, facile à lire même pour les développeurs débutants !
UML est un outil qui peut se révéler complexe, mal maitrisé cela peu apporter de la confusion.
Rien n'empêche de mixer les deux par ex: utiliser C4 Model et réserver UML aux cas les plus avancés :)
Cela permet d'avoir une méthode de communication claire et lisible, facile à lire même pour les développeurs débutants !
UML est un outil qui peut se révéler complexe, mal maitrisé cela peu apporter de la confusion.
Rien n'empêche de mixer les deux par ex: utiliser C4 Model et réserver UML aux cas les plus avancés :)
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
Cette série de trois articles présente des solutions pour optimiser la taille des images Docker. Dans cette première partie, on parle surtout de *multi-stage build*, parce que dans la démarche de réduction de taille des images, ça devrait presque toujours être notre première étape. On va également expliquer les différences entre les bibliothèques statiques et dynamiques, et on expliquera pourquoi c'est important. Ce sera l'occasion de présenter la fameuse distribution Alpine Linux.
Derniers commentaires :
Thibaud Duthoit
il y a environ 5 ans
Le devops sur mon projet actuel utilise du docker partout. Il créé un container pour chaque partie du projet : front/back/oauth2/services data science. Mais pour le front, je préfère généralement m'en passer au quotidien.
C'est parfois utile pour récupérer en local le reste des services et s'y brancher sans avoir à installer tous les environnements.
Ce sont aussi les dockers qui sont déployés sur les services amazon, sauf pour le front qui joue le village gaulois et qui upload directement les fichiers statiques sur S3 😇
C'est parfois utile pour récupérer en local le reste des services et s'y brancher sans avoir à installer tous les environnements.
Ce sont aussi les dockers qui sont déployés sur les services amazon, sauf pour le front qui joue le village gaulois et qui upload directement les fichiers statiques sur S3 😇
Benoit GANTAUME
il y a environ 5 ans
Je m'interroge encore parfois. Sur certains projets, je vois des stacks avec 7 ou 8 dockers, dont certains pour faire une opération ultra-basique.
Couplé avec des micro-services, ça peut faire des stacks franchement lourdes pour pas grand chose...
Je me demande comment fixer la limite de l'over-engineering...
Couplé avec des micro-services, ça peut faire des stacks franchement lourdes pour pas grand chose...
Je me demande comment fixer la limite de l'over-engineering...
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
Les développeurs passent beaucoup de temps devant un écran, parfois au détriment de leur santé oculaire. Une des solutions serait la lecture sur un support papier.
Derniers commentaires :
Jean-Baptiste Baillet
il y a environ 5 ans
La bibliothèque est une bonne idée. Certains des livres sont en cours de lecture. Je tacherais d'en faire un résumé lorsque je les aurais finis. Merci pour vos retours.
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
Lorsque l’on utilise Git, surtout quand on est débutant, on ne sait pas toujours comment nommer correctement ses branches ou ses messages de commits. Pourtant il est primordial pour s’y retrouver dans un projet, de respecter une convention de nommage.
Derniers commentaires :
Axel Shaita
il y a environ 5 ans
@Corentin Leffy J'ai pas mal utilisé cette convention que je trouve, comme tu dis, très visuelle. J'en fais d'ailleurs mention très brièvement dans mon article.
@Marc Bouvier C'est exactement cette convention ! Effectivement elle est de plus en plus suivie car pas mal d'outils se basent sur celle-ci pour automatiser la génération des changelogs ou le versionning (en se basant sur semver.org/lang/fr/)
@Marc Bouvier C'est exactement cette convention ! Effectivement elle est de plus en plus suivie car pas mal d'outils se basent sur celle-ci pour automatiser la génération des changelogs ou le versionning (en se basant sur semver.org/lang/fr/)
Baptiste Pottier
il y a environ 5 ans - modifié il y a environ 5 ans
@benoit Oui, nous l'utilisons depuis une année en mode "souple", c'est à dire que nous gardons une branch develop en plus de la master, là ou certain "extremistes" ne gardent que la master (et franchement on s'interroge à ne pas pousser jusque là tellement c'est pratique).
Les gains sont :
- l'obligation de travailler propre (il faut penser au copain)
- obligation de faire de petit commit
- incitation forte au feature flag
- Jamais de gros diff, jamais de branch qui se meurent ou qui durent des jours et des jours voir plus (sympa à merger ...)
On peut très bien savoir faire cela avec des branches, mais alors elles n'ont plus d’intérêt (si on merge toutes les heures, autant faire dans develop).
A chaque onboarding, le nouvel arrivant est dérangé mais très vite il adore (et on utilise les tags!) c'est queque chose qu'il faut pratiquer pour véritablement en comprendre l'avantage (comme le TDD sur ce point)
Les gains sont :
- l'obligation de travailler propre (il faut penser au copain)
- obligation de faire de petit commit
- incitation forte au feature flag
- Jamais de gros diff, jamais de branch qui se meurent ou qui durent des jours et des jours voir plus (sympa à merger ...)
On peut très bien savoir faire cela avec des branches, mais alors elles n'ont plus d’intérêt (si on merge toutes les heures, autant faire dans develop).
A chaque onboarding, le nouvel arrivant est dérangé mais très vite il adore (et on utilise les tags!) c'est queque chose qu'il faut pratiquer pour véritablement en comprendre l'avantage (comme le TDD sur ce point)
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
Cet article propose des pistes pour concevoir une API REST dans le cas où CRUD ne suffit plus.
Derniers commentaires :
Ludovic Dine
il y a environ 5 ans
Ton article m'intéresse beaucoup ! J'avais fait une API Rest complète avec Node.js pour un projet il y a 3 ans, et j'envisageais de me rafraîchir les idées sur le sujet.
Marc Bouvier
il y a environ 5 ans - modifié il y a environ 5 ans
Il y a aussi les articles d'octo que je trouve bien faits et en français.
- Designer une API REST : blog.octo.com/...
- Sécuriser une API REST : blog.octo.com/...
- Concevoir une API REST conforme au RGPD : blog.octo.com/...
- Designer une API REST : blog.octo.com/...
- Sécuriser une API REST : blog.octo.com/...
- Concevoir une API REST conforme au RGPD : blog.octo.com/...
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
Depuis quelques mois, José Paumard diffuse des cours en ligne sous forme de petits chapitres très courts (en moyenne 5 min par vidéo) et d'une poignées de live codings plus longs.
Derniers commentaires :
Marc Bouvier
il y a environ 5 ans
Mise à jour toute récente avec une playlist supplémentaire (www.youtube.com/... pour l'introduction à Java avec en invité Jean Michel Doudoux, bien connu pour son cours "développons en java" (jmdoudoux.developpez.com/...
Sébastien Macé
il y a environ 5 ans
Quelle qualité ces cours ! Si j'avais eu ce contenu lorsque je me suis reconverti à Java il y a 7 ans, le temps que j'aurais gagné ! En prenant le temps de suivre ces cours je découvre une à une les petites lacunes que j'avais par-ci par-là. C'est là qu'on voit qu'être autodidacte avec juste des bouquins dont la plupart sont en anglais c'est tout de même difficile. Rien ne vaut un cours de qualité comme celui de José Paumard.
Merci encore pour ce partage.
Pour les cast codeurs je connais mais je n'écoute plus trop leur podcast que je trouve trop technique, axé sur les nouveautés... tu m'as quand même donné envie de m'y remettre.
Merci encore pour ce partage.
Pour les cast codeurs je connais mais je n'écoute plus trop leur podcast que je trouve trop technique, axé sur les nouveautés... tu m'as quand même donné envie de m'y remettre.
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
On a tous un jour bossé sur du code mal écrit, tellement mal écrit que nos yeux se sont subitement mis à crier.
Derniers commentaires :
Elise Patrikainen
il y a environ 5 ans
Hello @Axel Shaita, juste pour te remercier pour la qualité du contenu de tes articles: je trouve qu'il fait partie des meilleurs blogs JS français actuels.
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
Mais je manque d'arguments et de ressources pour détailler cette nuance :/
Ca te permettra de faire peut etre apparaitre mieux dans ton code un concept métier (si méthode compliqué c'est bien que c'est un point sensible métier normalement)
En le mettant dans une classe dédié, tu pourras aussi le remplacer plus simplement (par exemple ca devient facile de remplacer l'appel de cette classe dédié par une interface et ca ouvre la porte à la possibilité de switcher facilement d'implémentation, imagine que tu as une idée pour améliorer l'algo en question ou améliorer sa vitesse, bim ca devient possible facilement par le fait que tu ai extrait l'algo dans une classe dédié)