Live #40 : Les bonnes pratiques et ma découverte de golang

[@eroman2006]

Ma bonne pratique c'est de suivre Jonathan Boyer :) merci pour tout ton travail

[@Cashandrick]

Débarquer dans une équipe de 4 et imposer ses 4 espaces alors que les 3 autres utilisent la tabulation, c'est comme jouer à Teamfight tactics et péter le bonus des 4 pistoleros en remplaçant un pistolero par un sauvage :D Merci pour ton live toujours enrichissant :)

[@arthurjacquemin2212]

Je viens de découvrir Voyager pour Laravel et je trouve qu'il serai intéressant de faire une vidéo dessus.

[@toupieornottoupie516]

l'histoire des tabulations vs espaces ça me rappelle la série "Silicon Valley' :-)

[@grafikart]

Ah la bonne référence ;) Il m'a beaucoup fait marré cet épisode ^^

[@dongitechofficiel64]

@@grafikart HIHIHI moi aussi super cool la vidéo

[@Cyborgs1718]

De mon point de vu les bonnes pratiques s'apprennent avec la régle du RTFD (read the fucking doc), regarder des tutos videos c'est bien , lire des livres aussi mais ca ne vaudra jamais une doc d'outils bien fichue avec des examples, les normes , les concepts expliqués par les barbus qui ont eux même codés l'outil que vous utilisez. Et effectivement le travail d'équipe, confronter les points de vues, ça fait avancer ! C'est aussi conceptualiser ses outils, faire du refactoring de code, l'encadrer de test unitaires, de tests d'intégrations et de tests fonctionnels pour une interface.

[@Ryu53898]

Pour WordPress, Php 7.3, CDN, Varnish, Redis, plugin auto optimize et un plugin de cache au choix WP rocket ou Breeze. C’est une fusée 🚀

[@simweraybahatielvis1612]

cool pour moi aussi

[@ggousier]

La meilleure bonne pratique c'est l'adaptabilité. :)

[@julienboyer]

La "bonne pratique" la plus importante c'est surtout d'être cohérent et homogène avec avec le reste du code, et que tous les participants du projet utilisent les mêmes conventions.

[@arthurjacquemin2212]

Go compile tout statiquement, ce qui à la fin abouti à des executables très lourds (genre 2.7 Mo pour un "hello world"). Après ça permet de compiler pour plusieurs OS différent sans avoir besoin de les posséder.

[@lionelsalabartan9210]

Faux. Ce n'est pas parce que c'est compilé statiquement que c'est lourd, le c est compilé statiquement et pourtant l'exécutable est très léger. Pour Go, c'est parce qu'il embarque sa propre runtime (façon de fonctionner = garbage collector) qui donne un gros exécutable. Et la encore il suffit d'utiliser strip pour enlever les infos non-essentielles (genre symbole de débogage) afin de réduire le poids.

[@hamza201183]

Salut Jonathan, tu utilises toujours Antergos? (Malgré que le projet soit arrêté)

[@grafikart]

Oui

[@kevinluche8778]

Sinon comme langage compilé pour ton appli, il y a Haxe qui est orienté objet (qui a l'air très familier quand on vient de javascript ou php) et qui se compile vers un tas d'autres langages (javascript, php, java, c++...). Tu peux créer un éxecutable en compilant vers du c++ du coup.

[@FranckJousseaume]

avoir l'url du repo dans le code au niveau de l'import, ça me semble entrainer des soucis : si demain je décide de faire un fork du package pour corriger un bug, ou si le package déménage (passage de github à gitlab comme beaucoup de projets l'ont fait suite au rachat par Microsoft par exemple) il faudra mettre à jour tous les fichiers source qui appellent ce package. Alors qu'avec composer en php, il suffirait de modifier un seul fichier pour dire où est le nouveau repo à utiliser.

[@swann91470]

Bien sur les bonnes pratiques s’acquièrent avec le temps et la pratique mais des communautés existent pour nous faciliter la tâche : fr.wikipedia.org/wiki/Software_craftsmanship fr.wikipedia.org/wiki/Extreme_programming#Pratiques Le TDD n'est qu'une technique de développement, si le développeur sait l'utiliser à bon escient, il peut très bien l'utiliser pour faire des PoC ou des MVP qui doivent être produit très rapidement. Il existe aussi des meetup et des conférences pour nous aider, sur paris il y a : www.meetup.com/fr-FR/Craft-your-Skills/ www.meetup.com/paris-software-craftsmanship/?chapter_analytics_code=UA-8465233-3

[@MohimiOthmane]

Cette Erin lindford m'a trop énervé

[@farisonet]

min 41:54 "Si vous avez décidé de faire un peu n'importe quoi au moins documentez le" pour moi ça résume tout le débat sur les bonnes pratiques lol

[@jean-baptistelasselle4562]

Pour commenter le code : Penses à celui qui utilisera ton code, et lira tes commentaires , pour essayer de comprendre comment se servir correctement de ta fonction, ta méthode, ta classe, ton interface, ton module. Doit répondre à la question : "Je fais comment pour me servir de ce truc que machin a fabriqué?" Mode d'emploi. Caution warnings (do not use without gloves)

[@pierrenapoletano3889]

Grafikart tu utilises quel clavier ?

[@grafikart]

Corsair K65 ;)

[@ProuzzerX]

Tu l'as peut-être déjà expliqué, mais en tout cas, je ne t'ai jamais entendu le faire : Aussi succinctement que tu le souhaites, peux-tu m'expliquer ce que tu reproches à jQuery ? J'ai remarqué que cette librairie a une (croissante) mauvaise réputation, et je n'ai jamais compris pourquoi. Mais j'aimerais surtout connaitre ton point de vue personnel sur jQuery, et notamment sur l'avis négatif que tu en as.

[@noquarter9700]

Aujourd'hui, les frameworks comme Angular, React ou Vue sont pensés différemment de jQuery, et sont finalement plus agréable à prendre en main pour certains types de site webs. Tout ce qui est WebApps, c'est pas comparable. Ces frameworks sont presque fait pour. Par ailleurs les communautés sont aujourd'hui plus grandes que celle de jQuery. Donc les nouveaux frameworks évoluent encore quand jQuery ben .... pas vraiment. jQuery fait son taff. C'est un bon moyen d'avoir un framework léger dans ton site pour faire interactions minimalistes et simples en Javascript. Si le projet est plus conséquent, je conseil définitivement de lâcher jQuery.

[@ProuzzerX]

@@noquarter9700 Déjà, merci pour ta réponse. Je suis parfaitement d'accord avec tout ce que tu as dit. Sauf que, comme tu l'as dit, _"jQuery fait son taff [...] pour faire interactions minimalistes et simples en javascript"._ C'est donc bien qu'il existe des contextes dans lesquels jQuery serait parfaitement (voir préférablement) utilisable. Or, à sa façon d'en avoir parlé, Jonathan (Grafikart) semble vraiment estimer que jQuery est *intrinsèquement* mal foutu (techniquement parlant), au point qu'il faille purement et simplement l'abandonner. Et c'est cela qui m'étonne. D'où ma question. Indépendamment du fait que les nouveaux frameworks Javascript supplanteront certainement à terme jQuery (si ce n'est pas *déjà* fait depuis longtemps), ça ne m'explique pas en quoi ce dernier est/était si problématique au point d'avoir (et d'avoir quasiment *toujours* eu) une si mauvaise réputation. Si tu en connais l'explication de sa mauvaise réputation, n'hésite surtout pas à me répondre. J'en serai ravi.

[@AbdeltifBouziane]

C’est le desktop de windows xp la? 😂

[@Otomega1]

a quel moment ça ressemble à XP?

[@BlogNicolasHenry]

Oui quand on revoit son code 1 an on prend peur ! :-) c'est la preuve qu'on progresse ! Ceci dit je laisse parfois du vieux code en prod car il faut avancer sur les features, le contenu, etc ... Je corrige le code le jour ou j'ai du temps.

[@BlogNicolasHenry]

@Dimitri C'est ça :-)

[@TomDERUDDER]

Strapi comme cms open source

[@arnoldngoma2296]

Salut grafkcart vous pouvez faire une formation comment créer un blog, utiliser wamp svp.

[@cedriclocchi5199]

Aucun interet de faire ca, le tuto des blogs a été fait et refait, a un moment donnée suffit de regarder les formations. WAMP c'est pareil que LAMP donc aucun intret de faire un tuto sur ca