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.
Ouais le moteur du Jdh a du mal avec la ponctuation sur les titres notamment, en général il suffit de retenter plusieurs fois en supprimant les virgules, points, points d’exclamation, etc. pour voir.
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é.
Et forcément, la semaine où je mets mon travail à la disposition de tous, c’est la semaine ou mon hébergeur ne met pas à jour le certificat SSL…
Désolé.
Aucune comparaison avec les autres systèmes, aucun exemple concret… pub déguisée?
Vraiment très bon article. Un peu hors propos, mais la phrase sur node m’a arraché un sacré smile !
On en sait plus sur le mode de propagation (plus que ce communiqué laconique) ?
oui, à priori ça venait du “ò”
À noter que ce nom “ESNI” va disparaître au profit d’ECH (“Encrypted Client Hello”), le nouveau nom de la RFC: https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
Ouais le moteur du Jdh a du mal avec la ponctuation sur les titres notamment, en général il suffit de retenter plusieurs fois en supprimant les virgules, points, points d’exclamation, etc. pour voir.
Tcho !
Hello, J’ai galéré à partager ce lien, je ne sais pas si ça venait du “ò” ou du “?” dans le titre .. Mais tout y est au final ! Merci.