Post de Innomind AI

Améliorer vos prompts dans la console développeur de Claude! 🚀 Cet outil simplifie l'optimisation de nos prompts en les améliorant automatiquement pour des résultats encore plus précis, surtout pour des tâches complexes nécessitant une grande précision. 🎁 Les avantages : 1️⃣ Instructions détaillées pour améliorer les performances de Claude. 2️⃣ Organisation claire grâce aux balises XML. 3️⃣ Exemples formatés pour démontrer un raisonnement étape par étape. 4️⃣ Suggestions stratégiques pour orienter les réponses initiales de Claude J'ai été impressionné par sa capacité à analyser nos instructions et à les structurer de manière claire.

𝗣𝗘𝘇𝗕𝘂𝘀 : Gains de performances sur le bus d’événement Il y a deux semaines, j’ai publié une nouvelle version de PEzBus, et je suis ravi de partager que ses performances ont été significativement améliorées, avec quelques microsecondes de temps de réponse gagnées. PEzBus est une bibliothèque .NET facilitant le développement d’applications pilotées par des événements, inspirée par Guava de Google. Elle permet la gestion d'événements via le pattern Publish/Subscribe, améliorant l’organisation des données et des actions. La version 1.2.0 se concentre sur le refactoring de code et l’amélioration des performances. Pour plus d'informations, visitez [PEzBus sur NuGet](https://lnkd.in/epidf5KY).

J'ai bien fait de l'évoquer au conditionnel… 😬 Quelques semaines après, ce n'est déjà plus d'actualité. Je vous parlais dans ce post de dotenvx, le successeur de dotenv (.𝘦𝘯𝘷), permettant de gérer sa configuration via des variables d'environnement : https://lnkd.in/et-vuw5x L'outil est toujours en cours de développement et ses objectifs restent les mêmes : cross-platform, multi-environment et sécurité accrue. Mais c'est sur ce dernier point qu'il y a du changement ! ⚠ La solution présentée reposait sur la mise en place d'un fichier .𝘦𝘯𝘷.𝘷𝘢𝘶𝘭𝘵, l'équivalent du fichier .𝘦𝘯𝘷, en une version chiffrée. Cette solution technique a été mise de côté, puisqu'il y a 3 problématiques majeures qui ont été soulevées : 1️⃣ La difficulté d'identifier précisément dans le fichier .𝘦𝘯𝘷.𝘷𝘢𝘶𝘭𝘵 les modifications effectuées 2️⃣ L'impossibilité de permettre à une personne de chiffrer des données sans aussi lui permettre de les déchiffrer 3️⃣ L'absence de mécanisme permettant de concaténer plusieurs fichiers .𝘦𝘯𝘷 en un seul fichier chiffré .𝘦𝘯𝘷.𝘷𝘢𝘶𝘭𝘵 L'auteur de la libraire m'a confirmé que de nombreux développeurs lui ont reproché le manque de flexibilité de cette implémentation. Désormais, la solution privilégiée repose sur le chiffrement des variables au sein même du fichier .𝘦𝘯𝘷 ! 🚀 Il contient donc, pour cela, les variables chiffrées + la clé publique (DOTENV_PUBLIC_KEY). La clé privée, à fournir au runtime pour le déchiffrement (DOTENV_PRIVATE_KEY), est toujours générée dans le fichier .𝘦𝘯𝘷.𝘬𝘦𝘺𝘴 et à conserver en lieu sûr. Des commandes utilitaires, tels que "dotenvx get" et "dotenvx set" permettent de chiffrer et déchiffrer aisément ses variables en local. 👌 Les fichiers .𝘦𝘯𝘷 peuvent désormais être versionnés. Attention, malgré tout, puisque des variables chiffrées et non-chiffrées peuvent cohabiter… Des travaux sont en cours afin de mettre à disposition des développeurs des hooks de prebuild et precommit, par l'intermédiaire de gitleaks, pour s'assurer que les fichiers d'environnement que l'on pousse sur nos dépôts distants ne possèdent pas de mots de passe et secrets en clair. Comment percevez-vous ce changement ? 🤔

Question de Gérard J'ai réussi à télécharger T29 Comment fonctionne le logiciel ? Ma réponse Tu vas sur le tableau de bord qui est au centre Puis tu remplaces les valeurs, à savoir les 2 pentes et l'angle de la vue en plan en degrés Avec tes propres valeurs, puis tu click sur valider et l'ensemble des calculs et dessins ont été automatiquement effectués N'hésite pas à poser des questions, je comprends qu'en 1 minute, cela semble confus Je suis à ta disposition pour te guider dans la découverte de l'application

L'Idempotence dans les requêtes HTTP Vous avez sûrement entendu dire que les requêtes POST sont non idempotentes, contrairement aux GET ou PUT. Mais pourquoi est-ce si important, notamment dans les applications critiques comme l’e-commerce et la finance ? Une requête POST crée une nouvelle ressource ou déclenche une action chaque fois qu’elle est envoyée. Imaginons une commande de produit : sans précautions, une double soumission pourrait aboutir à une double commande ! Pour sécuriser les opérations sensibles et éviter les doublons, même en cas de problème réseau ou de délai d’attente, voici les pratiques recommandées : 1️⃣ Idempotency Keys : Générer un identifiant unique pour chaque requête POST. Le serveur stocke cet ID pour empêcher un traitement en double. 2️⃣ Journalisation et Transactions : Enregistrer les requêtes traitées avec leurs statuts en base de données pour renvoyer la réponse correcte en cas de réitération. Ou utiliser tout simplement la notion de Transaction selon votre SGBD) 3️⃣ Pattern Post/Redirect/Get : Rediriger après l’exécution d’une requête POST pour éviter une nouvelle soumission. 4️⃣ Timeouts et Réessais Contrôlés : Utiliser des timeouts et une logique de réessai avec vérification d’état pour garantir que chaque requête POST est exécutée une seule fois (Cela est possible avec Retry par exemple de RxJS ou encore avec Axios ou Fetch).

Voilà la vidéo de la semaine 👇🏼 épisode de code Créer des composants, c’est bien! Mais où mettre sa logique ? Dans son composant? Non. Dans son template? Non 😅 (juré, déjà vu) On va utiliser des services. Dans cette vidéo de 10min (7 en x1.5), je vais te montrer commet ça se configure, comment ça s’utilise et pourquoi on fait ça : https://lnkd.in/eqcFJKNe

 🎃16 choses effrayantes quand on automatises des process: 🎃 1. Voir un matin un bdd vide suite au lancement d'une autom. 2. l'api de moodle. 3. Voir que ton client à renommé toutes les colonnes de la bdd "pour faire jolis". 4. le statut 200 "ceci est une erreur". 5. Les api non documentés. 6. Recevoir un mail disant que toutes les opérations ont été consommées alors que tu en avais 200000. 7. Les tokens d'authentification qui expirent sans avertissement. 8. Les messages d'erreurs vagues : "Something went wrong." 9. Les "bases de données" excel... 10. La documentation necessaire pour faire valider une connexion externe dans un grand groupe. 11. Des formules comparant de variable avec du texte statique dans les autom. 12. Quand un test en production déclenche un envoi massif de notifications. 13. Des fuseaux horaires différents. 14. La limite de requêtes atteinte en pleine journée de lancement. 15. Un fichier "standard" en entré qui change de structure toutes les semaines. 16. Les arrays d'objets dans des arrays d'objets. 17..... Tu rajouterais quoi dans cette liste ? Merci Jordan Chenevier-Truchet pour la découverte du format, et le lol en lisant ta liste !

La doc avant tout La documentation reste le meilleur guide pour mieux appréhender un concept. parfois on veut suivre des vidéos sur youtube et pourtant la doc dit tout et reponds à 90% de nos préoccupations. ça fait un bout de temps que j'utilise express pour mes API, et j'ai l'habitude de placer le middleware de l'authentification au niveau de chaque route comportant les verbes(get, post, delete, put) et pourtant aujourd'hui grace à la doc je me rends compte que c'était une repétition inutile car en utilisant le verbe all qui englobe les autres, nous auront le meme résultat à la simple différence que nous évistons la repétition du code.

🤯 Quel stress 🤯 J'ai publié ma première grosse fonctionnalité en ligne hier ! En réalité, c'était prévu mercredi. Il a fallu être réactif. Mardi, 18h : Tout est prêt, l'extension à été entièrement testée sur l'environnement local. Mercredi, 16h : Je publie les dernières modifications sur l'environnement de test (en préprod pour les intimes) pour les tests finaux en mise en situation réelle. Mercredi, 16h30 : Ça ne fonctionne pas. Un régime de droits empêche les utilisateurs d'accéder à des données essentielles pour le fonctionnement de la nouvelle extension. Mercredi 16h30 aussi : Je fais très vite la relation avec une autre extension (appliquant un restriction dans le code en plus des restrictions configurées par les utilisateurs) qui a été modifiée sur l'environnement local mais pas sûr l'environnement de test, qui, lui, est une copie quasi-conforme de l'environnement réel. Mea-culpa. Mercredi, 17h : On décide de tirer le frein à main, la mise en ligne ne se fera pas aujourd'hui [mercredi]. On décide aussi de revoir le code pour assurer que la fonctionnalité ne puisse pas être (autant) impactée par 2 les modules distincts même s'ils fonctionnent ensemble par essence. Mercredi, 18h : La fonctionnalité est perfectionnée et fonctionne parfaitement en local et sur l'environnement de test. Jeudi, 9h : On réalise de nouveaux les tests finaux (final-v2 pour les graphistes 😜 ) et tout se passe bien cette fois. Jeudi, 10h : Tous est en ligne, les utilisateurs vont pouvoir profiter des nouvelles fonctionnalités 🍾 Jeudi, 12h : Les retours sont positifs ! Quel soulagement !!! --- Tu me découvres ? Je suis Benoît - développeur web - et j'essaie de faire en sorte que le commun des mortels puisse comprendre comment fonctionne ce monde obscur 👻

T’as déjà entendu parler de XML-RPC ? C’est un peu le grand frère de SOAP, mais sans tout le bling-bling. Si SOAP c’était le tank blindé des API, XML-RPC c’était plutôt la moto cross : simple, efficace, mais ça tremblait un peu dans les virages. 🏍️ Début des années 90, on avait un problème simple : comment faire discuter deux machines à distance ? 🖥️📡🖥️ Et c’est là qu’arrive XML-RPC. Le concept est basique : on envoie des instructions à une machine distante via HTTP, et on encode tout ça en XML. La machine à l’autre bout interprète la requête et te renvoie une réponse. Pas de prise de tête, juste un Remote Procedure Call, avec XML comme langue commune. Mais alors, pourquoi on s’en souvient encore ? À l’époque, t’avais pas 36 options pour faire communiquer des systèmes distants. XML-RPC te donnait un moyen léger de le faire, tout en gardant la simplicité des requêtes HTTP. En gros, tu faisais passer une fonction (et ses paramètres) à distance. C’était l’idéal pour des petits échanges, sans se taper la complexité de SOAP. 🚀 Bon, faut avouer, c’était pas non plus la panacée. Déjà, XML, c’est pas connu pour sa légèreté. Ça reste plus simple que SOAP, mais chaque message XML est quand même bien verbeux. Et puis, niveau sécurité, c’était pas fou. Quand t’envoies des appels distants en HTTP sans chiffrement, faut pas être surpris si quelqu’un écoute aux portes. 👂 XML-RPC c’était la solution qui marchait bien tant que tu ne lui demandais pas la lune. Un peu comme cette vieille 206 qui te dépanne pour les trajets maison-boulot, mais que tu hésites à prendre pour partir en vacances à l’autre bout du pays. 🚗💥 Mais voilà, c’est la fin des années 90, les systèmes deviennent de plus en plus gros, les données aussi. On commence à avoir besoin de plus de flexibilité, de sécurité, et… SOAP arrive pour ramasser la mise. XML-RPC devient un peu le geek du lycée qui se fait discret pendant que les gros bras (SOAP) prennent le relais. 🤓 Fun fact : Y a encore quelques dinosaures qui tournent avec XML-RPC aujourd’hui ! Si t’as un vieux projet legacy qui traîne, tu risques d’y tomber dessus. Dans ce cas, bon courage ! Et toi, t’as déjà croisé la route de XML-RPC ? Des souvenirs ou c’est juste un acronyme de plus à oublier ? 👀 #API #TechHistory #XMLRPC #WebDev