Le projet semble top mais dommage qu’il ne soit pas open source. Pas facile de faire confiance aux phrases du type “Ninja Cookie ne collecte aucune donnée vous concernant dans le but de les analyser, de les utiliser ou de les vendre.”
Bon je pensais qu’il y aurait un peu plus de participants/questions, dommage.
Je voulais revenir sur “la modération trop stricte”. Je pense qu’on ne parle là que des articles supprimés (puisqu’un article modéré où les étiquettes sont corrigées/supprimées/ajoutées ne supprime évidemment pas l’article du Jdh).
Si on prend la première page du Journal de modération (https://www.journalduhacker.net/moderations), on a 40 jours de modération. J’ai regardé les publications, on a eu 300 infos remontées sur le Jdh en 40 jours. Il y a eu 9 suppressions : 4 hors sujet, 2 articles en Anglais, 1 repo GitHub, 1 article recrée suite à un bug, 1 article qui posait problème où j’ai expliqué le souci par message.
Dit autrement il y a très peu de suppressions et à chaque fois un message automatique envoyé à l’utilisateur qui peut évidemment choisir d’en discuter.
Le problème qu’on a : Les gens veulent des règles “strictes”. Ils veulent savoir immédiatement avant même d’avoir posté l’info si ça rentre dans la ligne éditoriale ou pas. Alors que c’est souvent un équilibre à trouver et justement un “dialogue” qui s’ouvre avec la modération.
La suppression d’un article ne donne pas un mauvais point à l’utilisateur qui a remonté l’article, on permet à l’utilisateur de contester ou venir discuter du bien fondé de la modération. Le fonctionnement même du Jdh quand un article est modéré est l’envoi d’un message automatique à l’utilisateur. Peut-on faire mieux qu’ouvrir le dialogue ?
Si on devait résumer les règles plus simplement : 1/ Article (donc pas de homepage ou de repo GitHub) en Français 2/ Dans la ligne éditoriale du Jdh. Le reste est mouvant, il faut en discuter.
À mon sens, il est plus intéressant de prendre un exemple dans le Journal de modération et d’en discuter. Pourquoi il a été modéré comme ça ? Quels sont les arguments ? Qui est d’accord avec ce point de vue ?
Est-ce que ça met en avant “l’activité des hackers francophones, du mouvement du Logiciel Libre et open source “ ? Non mais il est probablement légitime que certains lecteurs/utilisateurs du Jdh veuillent trouver ce genre d’articles sur le Jdh.
On favorise le dialogue ici, il faut pas hésiter à poser des questions, dire pourquoi on n’est pas d’accord.
La ligne éditoriale sur le “À propos” du Jdh : Le Journal du hacker a pour ambition de présenter l’activité des hackers francophones, du mouvement du Logiciel Libre et open source en langue française, mais aussi des startups et du mouvement entrepreunarial de la communauté francophone.
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é, …)
Le projet semble top mais dommage qu’il ne soit pas open source. Pas facile de faire confiance aux phrases du type “Ninja Cookie ne collecte aucune donnée vous concernant dans le but de les analyser, de les utiliser ou de les vendre.”
Tant mieux que le projet Exodus se démocratise et que les médias tradi s’en emparent . je ne résiste pas à coller le lien de leur conf à PasSageEnSeine et que j’avais trouvée à l’époque super intéressante: https://video.passageenseine.fr/videos/watch/c8d73a19-ecb4-4d3e-80ba-62a23b7afca6
Bon je pensais qu’il y aurait un peu plus de participants/questions, dommage.
Je voulais revenir sur “la modération trop stricte”. Je pense qu’on ne parle là que des articles supprimés (puisqu’un article modéré où les étiquettes sont corrigées/supprimées/ajoutées ne supprime évidemment pas l’article du Jdh).
Si on prend la première page du Journal de modération (https://www.journalduhacker.net/moderations), on a 40 jours de modération. J’ai regardé les publications, on a eu 300 infos remontées sur le Jdh en 40 jours. Il y a eu 9 suppressions : 4 hors sujet, 2 articles en Anglais, 1 repo GitHub, 1 article recrée suite à un bug, 1 article qui posait problème où j’ai expliqué le souci par message.
Dit autrement il y a très peu de suppressions et à chaque fois un message automatique envoyé à l’utilisateur qui peut évidemment choisir d’en discuter.
Tcho !
Le problème qu’on a : Les gens veulent des règles “strictes”. Ils veulent savoir immédiatement avant même d’avoir posté l’info si ça rentre dans la ligne éditoriale ou pas. Alors que c’est souvent un équilibre à trouver et justement un “dialogue” qui s’ouvre avec la modération.
La suppression d’un article ne donne pas un mauvais point à l’utilisateur qui a remonté l’article, on permet à l’utilisateur de contester ou venir discuter du bien fondé de la modération. Le fonctionnement même du Jdh quand un article est modéré est l’envoi d’un message automatique à l’utilisateur. Peut-on faire mieux qu’ouvrir le dialogue ?
Si on devait résumer les règles plus simplement : 1/ Article (donc pas de homepage ou de repo GitHub) en Français 2/ Dans la ligne éditoriale du Jdh. Le reste est mouvant, il faut en discuter.
À mon sens, il est plus intéressant de prendre un exemple dans le Journal de modération et d’en discuter. Pourquoi il a été modéré comme ça ? Quels sont les arguments ? Qui est d’accord avec ce point de vue ?
Prenons https://www.journalduhacker.net/s/wa4snk/chaises_de_gaming_mon_classement_des_16 (https://www.geeek.org/chaises-de-gaming/) je l’ai supprimé car j’ai considéré que ça ne rentrait pas dans la ligne éditoriale du Jdh. Qui est d’accord ? Qui n’est pas d’accord et pourquoi ?
Prenons https://www.journalduhacker.net/s/rsnghs/lepape_com_pirat_noms_num_ros_de_carte (https://www.nextinpact.com/article/44688/lepape-com-pirate-noms-numeros-carte-bancaire-dates-dexpiration-et-cryptogrammes-dans-nature) j’ai attendu plusieurs heures pour voir si ça intéressait, l’article est resté à 1, j’ai décidé de le supprimer. Le problème de ce type d’articles est facile à résumer, il concerne très très souvent l’étiquette “sécurité” avec une information très générale qu’on pourrait trouver sur BFM TV.
Est-ce que ça met en avant “l’activité des hackers francophones, du mouvement du Logiciel Libre et open source “ ? Non mais il est probablement légitime que certains lecteurs/utilisateurs du Jdh veuillent trouver ce genre d’articles sur le Jdh.
On favorise le dialogue ici, il faut pas hésiter à poser des questions, dire pourquoi on n’est pas d’accord.
Tcho !
Justement, cette partie me semble peut-être trop floue et mériterait d’être un peu plus détaillée sur ce qui est admis et non admis.
Salute,
La ligne éditoriale sur le “À propos” du Jdh : Le Journal du hacker a pour ambition de présenter l’activité des hackers francophones, du mouvement du Logiciel Libre et open source en langue française, mais aussi des startups et du mouvement entrepreunarial de la communauté francophone.
Tcho !
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 :