Michaël a écrit 2929 commentaires

Je ne sais pas si tu es familier de la fréquentation des lieux de types comptoir de bistrot ou de PMU, mais twitter c'est exactement ça, mais à l'échelle de la planète.

Sinon j'aime bien aussi “le tout-à-l'égoût de la liberté d'expression” mais ça ne tient pas non plus compte du service rendu et du modèle financier de Twitter/Facebook. (Le service rendu c'est la manipulation, pour ceux qui dorment au fond de la classe.)

Oui, et Xfce est 25% (23%) plus léger que Gnome. Vu l'expression de départ (Gnome n'est pas plus lourd) ce qu'on attend c'est une phrase dont le sujet est Gnome plutôt qu'une dont le sujet est Xfce.

[…] entre 1.3g (gnome) et 1g (xfce) […]
"[Gnome] pese […] plus lourd", c'est quand meme une bonne difference, 25%

À vue d'œil j'irai même jusqu'à dire que Gnome est 30% plus lourd que Xfce. ;-)

Mon point n'est pas qu'il y a un bug (ça arrive), mais que la communauté autour des BSD me semble trop petite car sinon, les bugs auraient été trouvé plus tôt.

C'est la communauté des utilisateurs d'Ansible et BSD qui est trop petite… perso ça fait depuis longtemps que j'ai arrêté d'utiliser Ansible et je ne m'en porte que mieux… (terraform, shell scripts).

Outre les références généralistes que propose Bilbo une bonne idée est de lire des scripts utilisés dans des projets open-source. Par exemple:

• Scripts dans FreeBSD
• Scripts d'installation pour TeXlive, Anaconda, et autres grogiciels
• Scripts de configuration Dockerfile

À mon avis un des grands défauts de beaucoup de scripts, tutoriels et références, dont le Advanced Bash Scripting est qu'ils approchent le Shell comme un langage de programmation de type C, Python et essaient de répondre à des questions de type “comment utiliser des tableaux en shell". Je recommande plutôt d'aborder le shell comme un langage à part qui a ses idiomes propres.

Un des poncifs de la programmation est l'expression ”qu'il ne faut pas réinventer la roue” — négligeant que celui qui sait réinventer la roue est au passage tout sauf un potiron. C'est en suivant un peu aveuglément ce poncif mille fois ressassé qu'on se retrouve avec des milliers de dépendances banales et parfois un peu triviales, or comme tu le dis

Il est de bon ton de nos jours pour chaque langage de programmation qui se respecte de débarquer avec un système intégré de dépendances

et c'est justement difficile d'écrire un bon système de dépendances! Or là tout le monde réinvente la roue, encore et encore! Il faut aussi souligner que le problème de la résolution de dépendances des paquets n'est pas facile, c'est même un problème NP-complet et avec un peu de soin on peut montrer que le problème de l'installation est équivalent au problème de la satisfaisabilité d'un polynôme booléen. Autrement dit, c'est exactement le type de problèmes où la réinvention de la roue.

Pour le problème concret qui pousse à cela c'est qu'on voit malheureusement que la distribution de logiciels sous Linux est un cauchemar et qu'il n'y a pas de solution satisfaisante offerte par les gestionnaires de paquets “traditionnels”. (Au passage les systèmes de ports à la BSD ou MacPorts eux tirent assez bien leur épingle du jeu pour la distribution de logiciels “maison”.)

Une solution pragmatique est celle d'utiliser un environnement de type docker pour distribuer “le python officiel” de l'équipe pour le projet mais cela ajoute un petit peu de complexité dans le cycle de développement.

d'un point de vue marketing il était plus opportun de patienter sagement et de se voir considéré forcés par l'EU plutôt que de faire un changement unilatéral et voir des clients gueuler.

Sans parler de clients gueuler à qui force à faire quoi, si on sort un produit qui doit respecter une norme légale, c'est plutôt bien de connaître la norme en question.

Le gros avantage que je vois ici, c'est surtout que la Région peut agir comme gardien d'un niveau de qualité de service minimum à respecter.

Ça peut-finir en “round-robin” à la fin de chaque exercice… comme ça l'usager a un service pourri, qui circule entre trois entreprises moisies qui perdent le marché chaque année mais le retrouveront dans deux ans lorsque les deux autres l'auront aussi perdu. (Entre-temps elles auront fignolé un petit powerpoint de chez mamie pour dire qu'elles ont amélioré la stratégie, pris un nouveau CEO, etc.)

j'avoue je ne sais pas si c'est une référence précise. mais c'est à prononcer "qwalitaye" et je trouve ça rigolo.

Moi aussi je trouve ça rigolo sans avoir de référence précise. Je suis toujours parti du principe que c'était une petite moquerie contre le franglais d'entreprise grand-gagnante.

Je ne pense pas qu'il soit nécessaire que chacun connaisse parfaitement la cli de docker. Seulement, ton exemple sur Git est juste. Oui, avoir une GUI permet à des profanes de s'en servir. Mais d'un autre côté, ça empêche aussi les gens d'en découvrir plus sur l'outil.

On utilise un outil pour faire quelque chose de précis: pour mon travail de développement je suis plutôt du genre “power-user/scripteur” qui va préférer les interfaces textuelles et les outils CLI pour à peu près tout: git, sql, docker… mais pour des tâches spécifiques comme par exemple faire une validation des critères d'acceptation, discuter un patch, faire une code review, explorer une BDD avec un collègue, et d'autres… les outils graphiques permettent une approche différente de la CLI.

Je trouve que la CLI est assez impitoyable avec la baisse de concentration qui est inéluctable si on n'est pas la personne qui manipule le système, les interfaces graphiques vont au contraire aider à se raccrocher en affichant plus de contexte et en montrant visuellement qu'on change de sujet, pour donner des exemples. Pour la productivité et l'automatisation, c'est bien-sûr la CLI qui garde souvent la main haute, mais ce n'est pas toujours le critère principal!

[…] le codage classique des entiers naturels […]

Je suppose que tu fais référence à la construction de Von Neumann mais il est aussi très commun de partir de l'axiome de l'infini. En bref la méthode fonctionne en énonçant l'axiome de l'infini comme suit:

Il existe un ensemble X qui n'est pas l'ensemble vide et
une application injective qui n'est pas surjective.

Puis on choisit un un point qui n'est pas dans l'image de et on prend l'intersection de toutes les parties -stables de qui contiennent , ce qui nous permet ensuite de suivre la méthode de Peano.

Pour les lexers simples l’approche typique est d’utiliser des fonctions mutuellement récursives, type read_whitespace, read_identifier, read_immediate_string , read_expression, etc. Comme Python ne sait pas faire l’optimisation de récursion terminale, on s’en sort en faisant comme l’OP. Bon courage!

Je cherche à mettre en place des environnements test et production pour créer un site web avec django mais je n'ai jamais travaillé en situation réelle de "production" dans une boite informatique.

Pour avancer dans cette direction je recommande une approche par petit pas.

Avant de commencer il faut faire quelques choix techniques, ma proposition serait la suivante:

1. Faire du développement sans branches, cela élague la complexité. (trunk-based development) Cela a des conséquences sur la façon dont travaille l'équipe mais si l'équipe c'est toi, on peut sauter cette partie. :-)

2. Faire du déploiement continu. Un commit poussé est un commit déployé.

Avant de te lancer en production, si tu n'es pas familier de la technique, c'est plus facile de créer un environnement de laboratoire et une technologie comme docker permet de faire cela assez facilement.

Tu crées 3 environnements (docker compose) un pour la chaîne de livraison (pipeline), un pour le bac à sable (sandbox) et un pour la production (production). Dans la pipeline il ya un logiciel de CICD qui tourne, comme Jenkins ou GoCD par exemple. Dans tes environnements sandbox et production il y a le classique TIER3: Jango, BDD, et HAPROXY ou APISIX. Une fois que ton laboratoire est opérationnel tu peux le modifier pour le faire marcher ailleurs.

-est ce que je fais un github action qui déploie ma branche production automatiquement sur un serveur production et un github action qui déploie ma branche "test" automatiquement sur un autre serveur ou est ce que je met mes deux environnement test et prod sur le meme serveur?

Test et prod sont sur des serveurs différents: est-ce que ton environnement de production a le droit de planter ou de fonctionner en performance dégradée si tes tests mettent la machine ko? Est-ce que la bdd de test a le droit d'arriver en production suite à une erreur de configuration? Si tu veux rendre ces erreurs aussi peu plausibles que possible, utilise des serveurs différents et des droits d'accès différents. (Par exemple sur Gandi ou AWS: des comptes différents).

-comment faire référence à la meme base de données dans django pour le test et la production?

Tes environnements sont séparés, donc cela n'a pas le droit d'arriver. Maintenant, tu peux vouloir utiliser un snapshot de la BDD en production dans les tests. Ta pipeline doit pouvoir initialiser la BDD avec un snapshot arbitraire. Ensuite il faut s'équiper pour éliminer plein de choses des snapshots: artefacts cryptographique et tokens d'authentification, données personnelles, données business. (C'est en principe plus facile de créer des données synthétiques que d'adapter les données de production pour les tests.)

-Dois je avoir 3 bdd ? (une test, une production et une de sauvegarde) ?

En général deux (si tu travailles sans redondance), des snapshots si possible et des sauvegardes fichier.

-je comprend comment pousser du code sur des branches distinctes, mais j'ai du mal à comprendre comment git gere les branches en local : est ce que je peux configurer git pour que quand je modifie mon code dans un repertoire ca ne le modifie que sur une des branches? ou dois je distinguer un repertoire prod et un repertoire test ?

Quand tu modifies, du point de vue de git (commit) cela se fait toujours sur la branche en cours. Tu n'as pas forcément besoin de travailler avec des branches, et surtout pas pour distinguer "test" et "prod": cela se fait via un fichier de configuration ou des variables d'environnement.

Pour démarrer, fait des petits pas, un environnement de laboratoire. Ton premier test est de faire un cURL qui marche sur ton site déployé. Bonne chance!

J'explique l'exemple de Gil Cot. :-)

Si tu ajoutes 1 mois au 31 janvier, il y a plusieurs façons d'interpréter le résultat, et on les trouve toutes en pratique.

• Comme c'est le dernier jour du mois, on dit que le bon résultat est le dernier jour de février.
• On dit qu'un mois c'est trente jours, donc on arrive le 1 ou 2 mars.

Si on se limite aux premiers jours du mois, il n'y a pas de difficultés à ajouter un mois ou une année, mais dès qu'on s'approche de la fin du mois il faut convenir d'une convention pour résoudre les cas peu clairs. Quel jour est désigné par:

• 12 mois après le 29 février
• 1 an après le 29 février
• 1 mois après 31 janvier
• 2 mois après le 30 décembre

etc.

Les difficultés résident dans ce que les conventions ne sont pas additives (ajouter 12 fois un mois et une fois 12 mois ce n'est pas forcément pareil) et que l'ordre dans lequel on ajoute respectivement des années, des mois, des semaines et des jours à une date (p.ex. dans 2 ans, 3 mois et 6 jours) change parfois considérablement le résultat.

J'ai grâce à toi un compte gitlab maintenant!

Quand-même je ne peux pas m'empêcher de faire la remarque qu'avant le : ce n'est pas une espace mais une espace insécable et qu'en ce qui me concerne j'ai toujours considéré que c'est le travail du logiciel que j'utilise de l'insérer:

https://github.com/foretspaisibles/cadet/blob/master/locale/punctuation/fr.tex#L14

Tu devrais formaliser cette réponse et l'ajouter à la base de données.

Ah que ça fait du bien de lire ton commentaire, les pieds bien sur Terre! :-)

J'aimerais que mon genre soit réellement une donnée accessoire, sans aucun intérêt dans la majorité des situations.

Ce souhait n'est pas à l'agenda du néoféminisme et une des raisons qui a poussé Annie Le Brun à écrire “Lâchez tout!” à la fin des années 70, un ouvrage ravissant! (Comme “Le trop de réalité”.)

Le problème est bien en amont de ça. Il faut permettre à chacun de trouver comment exprimer ses limites et de trouver comment les respecter collectivement. Tout cela est propre à chaque communauté, doit être reconstruit et ré-interrogé sans cesse.

Une difficulté est que dans beaucoup de ces communautés persistent des structures de pouvoir archaïques, c'est encore fréquent dans le milieu universitaire, hospitalier, les orchestres, les entreprises anciennes, qui semblent faire plutôt moins bien que le reste de la société.

Pour l'informatique, j'ai pu entendre Brigitta Böckler retracer l'historique de la “masculinisation” du milieu aux USA et je me souviens des deux faits saillants suivants:

1. La première communauté de grande importance, recrutée rapidement par IBM qui avait remporté un contrat d'état, était constituée de gens ayant un profil un peu particulier (en gros l'annonce disait “Are you playing chess? Bridge? You are the man to ride tomorrow's giants!” FR ”Jouez-vous aux échecs? Au bridge? Vous êtes homme à diriger les géants de demain!”.

2. Dans l'apparition de la micro-informatique personnelle, le matériel publicitaire est ciblé sur les petits garçons et leurs papas.

Ah ah c'est effectivement le titre de l'image! :-)

Le livre est vraiment très intéressant, au fait!

Ceci dit, je suis souvent dans un contexte maîtrisé et le seul cas où ça peut mal se passer à ma connaissance est quand on a trop de valeurs (raison d'être de commandes comme xargs par exemple)

Oui je chipote un peu mais c'est mon grain de sel moins pertinent. ;-) Il y a en fait deux problèmes en fait avec le for whatever in $(…); do Le premier et le plus important est que si il y a beaucoup de résultats ça casse le script, le second est que ça utilise l'IFS pour couper la ligne en mots. (En général quand on touche à IFS on est prudent, cependant. :-) )

En général xargs est mieux que la boucle while mais on ne peut pas l'utiliser tout le temps: cela ne marche qu'avec des programmes externes. Si on veut itérer avec une commande complexe ou une fonction on est obligé de passer par une boucle while.

Pour le cat, parfois l'usage légitime dans un pipe est si on a filtre configurable:

datasource()
{
   case "$1" in
     ''|everything)
       cat FILE
       ;;
     sample)
       head -n 20 FILE
       ;;
  esac
}

datasource sample | grep …

Les règles de de calcul c'est récent, longtemps on a utilisé des tables de calcul (qui sous une forme ou une autre semblent avoir été utilisées partout où on faisait des calculs dans le monde).

Table comme “surface de travail”, pas comme “tableau”. En bref le principe est similaire à celui du boulier, mais avec un dispositif matériel plus simple, qui peut éventuellement s'improviser.

La couverture du livre Oystein Øre ci-dessus montre une telle table de calcul (d), dont l'usage était courant en Europe avant la propagation des nouvelles méthodes de calcul (g).

Et comment est-ce que ça résout l'associativité? Ou alors il faut explicitement mettre les parenthèses? P.ex

( n1 * n2) * duration vs n1 * n2 * duration vs n1 * (n2 * duration)

(Qu'est-ce qu'on doit dire au compilateur pour pouvoir écrire l'expression du milieu?)

Salut, merci pour ton travail!

J'ai deux petits grains de sel à mettre. Le plus pertinent est que certains des sujets dont tu parles sont abordés dans le TeXbook. Ce livre se trouve ici

https://ctan.org/pkg/texbook?lang=en

la distribution sous forme de PDF n'est pas autorisée mais celle du source bel et bien.

La méthode de justification de TeX est décrite au chapitre 14 “How TeX breaks paragraphs into lines.” En très bref, l'idée est de trouver tous les points de césure possible, de leur associer une mesure de laideur (par exemple c'est moins laid de casser sur une espace que dans l'intérieur d'un mot) puis quand on a un candidat de paragraphe, ajouter à ce score de laideur une valeur qui dépend de la dilatation ou compression des espaces sur les lignes consécutives (c'est horrible d'avoir une ligne très compressée suivie d'une ligne très dilatée).

La méthode qu'utilise TeX pour trouver les points de césure est décrite dans l'appendice H. Elle est basée sur un modèle un peu compliqué basé sur des n-grammes et des valeurs numériques qui indiquent les bons ou mauvais points de césures… par exemple u1pe et 2id Quoiqu'il en soit Liang, dont parle Knuth dans son livre, arrive à construire 4447 de ces n-grammes qui permettent de couper correctement 89.3% des 115000 mots de la langue anglaise de son dictionnaire des césures, c'est à dire trouver 89,3% de tous les points de césure du dictionnaire, sans en créer de faux. On peut ensuite parfaire l'algorithme en ajoutant un petit dictionnaire d'exceptions. L'avantage de cette méthode (par rapport au dictionnaire) est qu'elle s'adapte bien aux évolutions de langue comme les néologismes ou les emprunts, surtout si la langue de l'emprunt est proche de l'anglais (comme le français par exemple). Il y a des dictionnaires de ngrammes pour beaucoup de langues, et ils sont tous dans TeXlive.

Mon grain de sel un peu moins dans le sujet est que le shell n'aime pas trop les boucles du genre

for letter in $(print_many_letters); do
  …
done

alors que

print_many_letters | {
  while read letter; do
    …
  done
}

est plus robuste.

Il y a aussi les petits cat … | grep par exemple qui s'écrivent mieux grep < …. (Oui j'ai déjà eu le message d'erreur ssh: fork failed, cannot create process :-) )

Je trouve ça dommage de ne pas l’avoir, fidèle à l’esprit DC, fait sur un canvas! ;-)

C'est dommage que même sur linuxfr on entende surtout parler de la copie promis-c'est-bientôt-libre que de l'original…

Certainement parceque l'étudiant qui a écrit ça a opté pour le successful startup package avec incubateur et agence de com qui dit des mots d'amour aux oreilles des journalistes en recherche de sujet pour leurs chroniques. :-)