Alors je vais peut-être mettre les pieds dans le plat, mais je vois un frein à l’évolution du JDH : la modération trop stricte. Je vois passer assez régulièrement dans le journal de modération des articles dont le sujet me semble intéressant, plus intéressant que certains qui restent sans vote dans la page des récents.
Ce n’est que mon avis, mais je pense qu’on gagnerait à avoir le pied moins lourd sur le contenu. Par ailleurs, les contributeurs concernés sont invités à se rendre sur la page “à propos”, où je ne vois pas de règles claires sur la ligne éditoriale.
Mais néanmoins, merci pour le travail fourni et la motivation pas évidente à garder.
Le métier de dev est devenu tellement large (et ce n’est pas près de s’arrêter) qu’il est de plus en plus important de relativiser la notion de “bonnes pratiques”. On ne peut parler de “bonnes pratiques” sans le contexte/domaine d’application.
Il y a quelques bonnes pratiques de base (e.g. rendre lisible son code), mais dès qu’on rentre sur des questions de complexité, il est difficile d’avoir des solutions uniques.
La réciproque étant que tu peux juger de l’expérience et du recul d’un dev sur sa capacité à expliquer la relation entre le problème qu’il cherche à résoudre et sa solution.
Depuis le temps que je lis que Vim permet d’augmenter la productivité… Mais comme l’auteur de l’article, à chaque fois que je l’ai démarré j’ai pris un mur dans la gueule.
Quels sont les raccourcis ? Pourquoi ceux-là ? J’ai pris peur… et je suis retourné sur mon IDE préféré.
Je ne suis pourtant pas réfractaire au changement, seulement quand il m’est impossible d’y trouver de la valeur ajoutée, j’ai du mal.
C’est une certitude : j’ai besoin de réapprendre à marcher. J’ai besoin de courage pour affronter cette courbe d’apprentissage, rien d’autre.
Si tu as un projet en php5 qui fonctionnait avec par exemple nixos 18.03, alors tu peux installer nixos 20.09 et utiliser les paquets de nixos 18.03 juste pour ce projet. En gros, dans le fichier default.nix, au lieu de mettre “pkgs = import {};” il faudra mettre “pkgs = import (fetchTarball “https://github.com/NixOS/nixpkgs/archive/18.03.tar.gz”) {};” Ou sinon, tu peux packager ta propre version de php, ou même forker le dépot de paquets de nix et y faire tes propres modifs.
Concernant le fonctionnement interne de nix, tous les paquets sont stockés dans le dossier /nix/store, avec un hash spécifique. Donc tu peux installer différentes versions ou même compilations d’un même logiciel. Nix utilise juste des liens symboliques vers les bons dossiers pour les différents environnements demandés, et ainsi éviter les conflits.
J’espère que ça répond mieux à ta question.
Je suis nul en PHP mais a priori ça veut dire que la version 7.2 n’est pas dans nixpkgs 20.09. Cependant je pense que tu peux quand même l’utiliser en spécifiant un ancien commit de nixpkgs qui la contient encore. Tu dois même pouvoir spécifier des versions différentes selon tes différents projets. Perso, je fais ça souvent, pour utiliser différentes versions de Python ou de gcc/clang, ou pour fixer différents jeux de versions.
J’ai codé mes premiers programmes Visual Basic puis C dans la petite salle info de mon lycée, et je n’étais pas le seul. J’ai vu des gens coder/modifier Half Life avec un truc que je ne connaissais pas à l’époque et qui s’appelait Visual Studio. On s’échangeait des programmes, de la documentation trouvée sur le net, le tout sur CD (parce qu’il y avait un graveur unique sur place). On discutait un peu technique, on s’ouvrait à tout ce qu’on pouvait faire.
La salle était en partie autogérée (on avait un créneau horaire pour discuter de ce qu’on souhaitait installer, car on n’avait pas les droits et on devait en faire la demande).
Je pense qu’avoir accès à l’outil informatique jeune est vraiment quelque chose qui transforme la société, d’où l’importance de telles salles partout dans le monde.
C’est cool que tu sois passé, j’attendais ton passage pour poser une question ^^
J’ai parcouru le changelog : “PHP 7.2 is no longer supported due to upstream not supporting this version for the entire lifecycle of the 20.09 release”. Concrètement ça veut dire qu’il n’est pas possible de construire php 7.2 ou juste que ce n’est pas “maintenu” ?
Merci pour les retours. L’installation et la configuration du système initial est effectivement un peu longue mais ensuite on gagne généralement du temps, à l’usage. Quant à Docker, ça ne résoud pas vraiment les mêmes problèmes. Nix peut construire facilement des images Docker (et souvent de façon plus efficace) mais il permet également de faire beaucoup d’autres choses. Par exemple, rien que la gestion des environnements virtuels Python, c’est très pratique au quotidien.
Pour les commentaires, je suis tombé sur un code où CHAQUE ligne était précédée d’un commentaire. Avec ma ligne préférée :
// Incrémente i
i++;
Après lui avoir demandé pourquoi il le faisait, le développeur m’a dit “les profs m’ont dit de tout commenter”. C’est donc ce qu’il faisait.
Lorsque je code, j’applique le principe suivant :
Ce que le code est sensé faire : c’est le nom de la méthode/fonction
Ce que le code fait : ce sont les tests (mais normalement, le code est devrait faire ce qu’il est … sensé faire)
Comment le code le fait : c’est le code justement. Soit il est clair ou classique et il y a pas besoin de le commenter (au développeur qui lit de se former), soit il est “compliqué” et il y vaut mieux trouver moyen de faire autrement et sinon, voir suivant.
Pourquoi le code le fait comme ça : seule raison pourquoi je commente (pourquoi j’utilise telle constante, tel patron, telle répartition de responsabilité, …)
Merci !
C’est sûr qu’il n’est pas simple pour un junior de savoir quand le commentaire est pertinent. C’est pourquoi il faut toujours se demander, quand on écrit un commentaire, si le code ne pourrait pas être simplifié. Après je suis assez d’accord avec toi qu’il vaut mieux écrire un commentaire inutile que d’en omettre un important mais cela doit, selon moi, être vu lors revue de code pour justement nettoyer les commentaires inutiles.
Sympa ta liste ! Je ne suis pas forcément d’accord avec certaines abréviations (hrchy ou cnt par exemple) mais de définir une liste blanche de termes ce n’est pas bête même si dans l’idéal il faut les éviter.
Sinon pour s’améliorer, rien de tel que le pair programming et la revue de code avec la personne concernée.
Je ne suis personnellement jamais tombé sur du code qui abuse de commentaires. Il n’est pas simple, pour un junior/nouvel arrivant de savoir quand il est pertinent de commenter ou non. En cas de doute, j’aurais tendance à dire qu’il vaut mieux risquer d’écrire un commentaire inutile que d’en omettre un important.
Concernant les abréviations. Je suis d’accord qu’il faut les éviter par défaut, mais il peut être intéressant de faire une liste blanche de termes quand ils sont très souvent utilisés. Cette liste doit être discutée. Le but n’est pas d’en mettre partout, mais sur les noms de variable les plus utilisés, suivant le domaine.
Une technique pour qu’une personne s’améliore est de combiner la maintenance de ses propres outils, avec le débogage d’outils bien codé. Ça permet à la personne de se rendre compte par elle-même de l’intérêt d’avoir des choses propres.
Je vais faire une petite précision. Le Jdh a assez de monde pour que le système de vote soit pertinent, il y a actuellement 1124 utilisateurs/comptes sur le Jdh. En revanche très peu de personnes participent et votent.
https://lobste.rs/ actuellement plus de 13000 comptes/utilisateurs le plus gros vote que j’ai vu tournait autour de 350 et à vue de nez la moyenne haute est à 80 votes.
Il est dommage que le seul exemple français de ce billet soit JdH.
Le problème que posent les annuaires est l’agrégation des contenus. Tous ne se valent pas, et même JdH n’a pas assez de monde pour que le système de vote soit pertinent.
De même que “naviguer” sur internet au sens où l’auteur l’entends était une activité enrichissante, elle l’est toujours, et toujours pratiqué, mais le nombre de personne utilisant le réseau ayant augmenté, le nombre de personne navigant est devenu minoritaire, d’où l’impression de l’auteur qu’il s’agit d’une activité délaissée.
Alors je vais peut-être mettre les pieds dans le plat, mais je vois un frein à l’évolution du JDH : la modération trop stricte. Je vois passer assez régulièrement dans le journal de modération des articles dont le sujet me semble intéressant, plus intéressant que certains qui restent sans vote dans la page des récents.
Ce n’est que mon avis, mais je pense qu’on gagnerait à avoir le pied moins lourd sur le contenu. Par ailleurs, les contributeurs concernés sont invités à se rendre sur la page “à propos”, où je ne vois pas de règles claires sur la ligne éditoriale.
Mais néanmoins, merci pour le travail fourni et la motivation pas évidente à garder.
terminé le temps des reconversions de vilaines avec ce qui arrive remplissez la cave, achetez des nouilles et des douilles :p
Le métier de dev est devenu tellement large (et ce n’est pas près de s’arrêter) qu’il est de plus en plus important de relativiser la notion de “bonnes pratiques”. On ne peut parler de “bonnes pratiques” sans le contexte/domaine d’application.
Il y a quelques bonnes pratiques de base (e.g. rendre lisible son code), mais dès qu’on rentre sur des questions de complexité, il est difficile d’avoir des solutions uniques.
La réciproque étant que tu peux juger de l’expérience et du recul d’un dev sur sa capacité à expliquer la relation entre le problème qu’il cherche à résoudre et sa solution.
Je m’excuse, je parle tout de même de systemd dans l’article ^^
Tcho !
Quand j’ai vu brightnessctl j’ai cru à un utilitaire de systemd ! Ouf, heureusement c’est pas une commande systemd :-)
Depuis le temps que je lis que Vim permet d’augmenter la productivité… Mais comme l’auteur de l’article, à chaque fois que je l’ai démarré j’ai pris un mur dans la gueule.
Quels sont les raccourcis ? Pourquoi ceux-là ? J’ai pris peur… et je suis retourné sur mon IDE préféré.
Je ne suis pourtant pas réfractaire au changement, seulement quand il m’est impossible d’y trouver de la valeur ajoutée, j’ai du mal.
C’est une certitude : j’ai besoin de réapprendre à marcher. J’ai besoin de courage pour affronter cette courbe d’apprentissage, rien d’autre.
Je pense qu’à un moment seul mettre les mains dedans permet de répondre aux questions, merci en tout cas ^^
Tcho !
Si tu as un projet en php5 qui fonctionnait avec par exemple nixos 18.03, alors tu peux installer nixos 20.09 et utiliser les paquets de nixos 18.03 juste pour ce projet. En gros, dans le fichier default.nix, au lieu de mettre “pkgs = import {};” il faudra mettre “pkgs = import (fetchTarball “https://github.com/NixOS/nixpkgs/archive/18.03.tar.gz”) {};” Ou sinon, tu peux packager ta propre version de php, ou même forker le dépot de paquets de nix et y faire tes propres modifs.
Concernant le fonctionnement interne de nix, tous les paquets sont stockés dans le dossier /nix/store, avec un hash spécifique. Donc tu peux installer différentes versions ou même compilations d’un même logiciel. Nix utilise juste des liens symboliques vers les bons dossiers pour les différents environnements demandés, et ainsi éviter les conflits. J’espère que ça répond mieux à ta question.
Ouais ma question de fond était de savoir comment Nix gérait les “vieux” programmes genre si je veux construire php 5.4.45. Je creuserai à l’occasion.
Merci !
Je suis nul en PHP mais a priori ça veut dire que la version 7.2 n’est pas dans nixpkgs 20.09. Cependant je pense que tu peux quand même l’utiliser en spécifiant un ancien commit de nixpkgs qui la contient encore. Tu dois même pouvoir spécifier des versions différentes selon tes différents projets. Perso, je fais ça souvent, pour utiliser différentes versions de Python ou de gcc/clang, ou pour fixer différents jeux de versions.
J’ai codé mes premiers programmes Visual Basic puis C dans la petite salle info de mon lycée, et je n’étais pas le seul. J’ai vu des gens coder/modifier Half Life avec un truc que je ne connaissais pas à l’époque et qui s’appelait Visual Studio. On s’échangeait des programmes, de la documentation trouvée sur le net, le tout sur CD (parce qu’il y avait un graveur unique sur place). On discutait un peu technique, on s’ouvrait à tout ce qu’on pouvait faire.
La salle était en partie autogérée (on avait un créneau horaire pour discuter de ce qu’on souhaitait installer, car on n’avait pas les droits et on devait en faire la demande).
Je pense qu’avoir accès à l’outil informatique jeune est vraiment quelque chose qui transforme la société, d’où l’importance de telles salles partout dans le monde.
C’est cool que tu sois passé, j’attendais ton passage pour poser une question ^^
J’ai parcouru le changelog : “PHP 7.2 is no longer supported due to upstream not supporting this version for the entire lifecycle of the 20.09 release”. Concrètement ça veut dire qu’il n’est pas possible de construire php 7.2 ou juste que ce n’est pas “maintenu” ?
Merci, Tcho !
Merci pour les retours. L’installation et la configuration du système initial est effectivement un peu longue mais ensuite on gagne généralement du temps, à l’usage. Quant à Docker, ça ne résoud pas vraiment les mêmes problèmes. Nix peut construire facilement des images Docker (et souvent de façon plus efficace) mais il permet également de faire beaucoup d’autres choses. Par exemple, rien que la gestion des environnements virtuels Python, c’est très pratique au quotidien.
Pour les commentaires, je suis tombé sur un code où CHAQUE ligne était précédée d’un commentaire. Avec ma ligne préférée :
Après lui avoir demandé pourquoi il le faisait, le développeur m’a dit “les profs m’ont dit de tout commenter”. C’est donc ce qu’il faisait.
Lorsque je code, j’applique le principe suivant :
Merci ! C’est sûr qu’il n’est pas simple pour un junior de savoir quand le commentaire est pertinent. C’est pourquoi il faut toujours se demander, quand on écrit un commentaire, si le code ne pourrait pas être simplifié. Après je suis assez d’accord avec toi qu’il vaut mieux écrire un commentaire inutile que d’en omettre un important mais cela doit, selon moi, être vu lors revue de code pour justement nettoyer les commentaires inutiles.
Sympa ta liste ! Je ne suis pas forcément d’accord avec certaines abréviations (hrchy ou cnt par exemple) mais de définir une liste blanche de termes ce n’est pas bête même si dans l’idéal il faut les éviter.
Sinon pour s’améliorer, rien de tel que le pair programming et la revue de code avec la personne concernée.
Merci pour l’article. Il est très bien écrit.
Je ne suis personnellement jamais tombé sur du code qui abuse de commentaires. Il n’est pas simple, pour un junior/nouvel arrivant de savoir quand il est pertinent de commenter ou non. En cas de doute, j’aurais tendance à dire qu’il vaut mieux risquer d’écrire un commentaire inutile que d’en omettre un important.
Concernant les abréviations. Je suis d’accord qu’il faut les éviter par défaut, mais il peut être intéressant de faire une liste blanche de termes quand ils sont très souvent utilisés. Cette liste doit être discutée. Le but n’est pas d’en mettre partout, mais sur les noms de variable les plus utilisés, suivant le domaine.
J’ai une petite liste de termes qui reviennent.
Une technique pour qu’une personne s’améliore est de combiner la maintenance de ses propres outils, avec le débogage d’outils bien codé. Ça permet à la personne de se rendre compte par elle-même de l’intérêt d’avoir des choses propres.
Yo,
Je vais faire une petite précision. Le Jdh a assez de monde pour que le système de vote soit pertinent, il y a actuellement 1124 utilisateurs/comptes sur le Jdh. En revanche très peu de personnes participent et votent.
Perso je trouve ça évidemment dommage mais en réalité c’est le cas pour toutes les communautés et projets, j’aime citer la règle du 1% https://fr.wikipedia.org/wiki/R%C3%A8gle_du_1_%25
https://lobste.rs/ actuellement plus de 13000 comptes/utilisateurs le plus gros vote que j’ai vu tournait autour de 350 et à vue de nez la moyenne haute est à 80 votes.
Tcho !
Il est dommage que le seul exemple français de ce billet soit JdH.
Le problème que posent les annuaires est l’agrégation des contenus. Tous ne se valent pas, et même JdH n’a pas assez de monde pour que le système de vote soit pertinent.
De même que “naviguer” sur internet au sens où l’auteur l’entends était une activité enrichissante, elle l’est toujours, et toujours pratiqué, mais le nombre de personne utilisant le réseau ayant augmenté, le nombre de personne navigant est devenu minoritaire, d’où l’impression de l’auteur qu’il s’agit d’une activité délaissée.
Ouais ça nous rajeunit pas ha ha
Tcho !
Le certificat a été mis à jour, la page est de nouveau disponible. Encore désolé.