Michaël a écrit 2935 commentaires

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. :-)

Ce genre d’application existe depuis 3 milliards d’années en Allemagne (Wahl o’mat: automate de vote), ne récolte aucune donnée et utilise une calibration et un système de pondération. (C’est le théorème fondamental de la décision rationnelle qui dit que ce modèle marche.) Utiliser des techniques d’ia pour parler de ça c’est un peu du ripolinage à deux francs six sous.

et aucun besoin d’un backend ou de sauver aucune donnée…

J'ai passé 12 ans dans le privé et j'ai vu de très grosses entreprises qui marchent bien mieux. L'én est sur n'importe quel critère pris séparément le pire des employeurs que j'ai jamais eu. Même l'utilité sociale du métier est en pratique plus que douteuse (à cause des conditions dans lesquelles le métier s'exerce).

En résumé, je te souhaite sincèrement bon courage, j’espère de tout cœur que la classe dirigeante en France comprendra que l’enseignement est un investissement à long terme pour l’avenir d’un pays, pas une charge.

C'est gentil mais de mon côté c'est tout vu j'ai rdv mercredi avec les RH pour parler de ma démission.

Plus qu'un problème de moyens – même si c'est évidemment un point à améliorer je vois les problèmes suivants:

• Absence d'ambition ou de mission claire; rien de ce que j'ai vu ne me permet de contredire l'idée que l'ÉN sert à mettre des profs devant les élèves, point barre … c'est à pleurer.

• Absence de tissu social, groupes d'intérêts, etc. l'institution ne considère pas sa mission de construire et alimenter ceux-cis, ils existent donc de façon sporadique et confidentielle, disparaissent lorsque les personnes qui les animent se désinvestissent. Il n'y a aucun lieu à l'échelle de l'institution pour échanger des idées, convaincre, chercher des conseils… (tout se fait de façon locale, confidentielle et au petit bonheur la chance)

• Institution dysfonctionnelle typique: si un agent a un problème il devient vite le problème, on prviliégie le mail à toute forme de communication plus humaine (“moi j'ai fait mon travail, c'est les autres qui ont du merder”), peu de communication entre les corps de métiers… bien-sûr il y a sûrement des endroits où les choses se passent mieux, mais il y a des endroits où tout cela se passe mal et ça ne dérange pas l'institution.

• Hiérarchie qui préfère convaincre que les problèmes qu'on lui décrit n'en sont pas…

• Aucune structures d'auto-amélioration continue

• ad lib

Heu ben, je suis prof depuis le mois de septembre et je suis atterré et attristé par presque tout ce que j'ai pu voir: le seul visage que l'éducation nationale m'a montré c'est celui d'une institution absolument dysfonctionnelle avec des ambitions nulles, sur absolument tous les sujets. Je parle bien de l'institution, pas des gens qui y travaillent, et notamment pas des professeurs.

Merci, c'est détaillé et très intéressant. Est-ce qu'une solution hybride, avec de la “petite intégration continue” qui utilise le simulateur après chaque push et une “grande intégration continue” sur une base périodique qui se fait sur le matériel, pourrait te sembler pertinente?

Donc le "je teste tout à chaque push", ça me parait difficile.

Oui dans ce genre de situation cela paraît difficile. Est-ce que tu as envie d'expliquer les particularités qui font que les tests prennent si longtemps? Ce que tu écris c'est le logiciel de la puce?

Est-ce qu'une approche qui consisterait à avoir un sous-ensemble de tests qui tourneraient le plus souvent possible (plusieurs fois par jour, quitte à avoir des “trains” qui partent à heure fixe par exemple) apporterait quelque chose? Pas grand chose? Serait contre-productive? Cela rend curieux :-)

Dans ton premier donc ce n'est plus ce que tu fais ?

Non je suis allé prendre mon poste d'agrégé au lycée en septembre après avoir épuisé tous les congés possibles mais je ne pense pas y rester très longtemps … (c'est une autre discussion cependant!)

Une vingtaine je trouve ça énorme par contre,

Oui c'est assez grand mais c'est transitoire: il y a une période de transfert de compétence avec 4-5 nouveaux collègues qui ont commencé dans les tous derniers mois puis un partage de l'équipe en deux. C'est aussi des équipes pluridisciplinaires, quasi des mini-entreprises autonomes dont on parle. Sur tout le projet il y a quelques centaines de personnes qui travaillent, avec deux très gros tiers de développeurs, répartis sur une dizaine de sites, dans quatre pays! La plupart sont dans de groupes entre 8 et 20, mais quand ça monte au dessus de 13 c'est souvent pour préparer une “scission.”

Je ne sais pas trop comment on peut annoncer ça.

Ça demande aux parties prenantes de se mettre d'accord sur la façon de travailler, en choisissant des méthodes qui minimisent l'inventaire (développement non livré). Ensuite on avait le confort énorme de travailler en “back office” ce qui fait qu'on a une “feedback loop” très courte, pas comme si on devait faire des enquêtes de satisfaction de l'utilisateur avec une société de communication par exemple, puisqu'on est à quelques mètres des utilisateurs.

Il faut aussi se mettre d'accord sur la façon de mesurer le “time to market.” Dans les contextes où j'ai exercé le bon signal de fin semble être “la première fois que la fonction entre en production” même si après il faut remettre son ouvrage sur le métier, c'est normal c'est la nature du logiciel de ne jamais être terminé. Pour une agence de développement qui dit à ses clients “on aura fini dans trois mois” je suppose qu'un point de vue légèrement différent s'impose. Il y a certainement plein d'autres environnements qui vont tirer vers d'autres équilibres.

Les tests d'intégration je trouve ça compliqué.

C'est effectivement ce qui nous demandait le plus de travail. Notre démarche était pre 1. d'avoir un environnement “stage” pour les tests et 2. d'avoir un test d'intégration dès les premières itérations du développement, même s'il s'agit de faire un simple curl sur le “health dashboard” de notre application tier3.

Pour le 1, même si cela semble assez basique il y a toujours des voix pour s'opposer (parceque c'est “cher”) mais j'ai toujours pensé que c'était important d'avoir ce genre d'environnement à disposition, notamment pour pouvoir faire du ”disaster recovery” et pouvoir garantir à son client qu'on peut recréer toute l'infra en temps fini si besoin.

Pour le 2, même si les premiers tests ne semblent pas spectaculaires ça aide d'avoir un véhicule pour ajouter les nouveaux tests d'intégration au fur et à mesure que l'application s'étoffe. Selon l'avancement du projet et les besoins de l'équipe les tests d'intégration peuvent être sophistiqués ou très basiques, par exemple se concentrer sur une ou deux fonctions cruciales dans le cas favorable (sans trop regarder les conditions d'erreur), et tout de même avoir leur utilité, surtout du côté infra (connectivité réseau, droits d'accès, etc.)

Même si il y a apparemment de bonnes raisons de ne pas forcément vouloir déployer à chaque push, l'argument les plus important pour cette pratique, à mes yeux, suit le plan suivant:

Il faut toujours être en capacité de déployer car on peut avoir besoin de corriger un problème grave.

Plus rarement on déploie, moins on a confiance dans sa procédure de déploiement et la peur du déploiement commence à s'installer dans l'équipe.

Plus rarement on déploie, moins les développeurs attachent de l'importance à la procédure de déploiement, car celle-ci prend moins de place dans leur travail et qu'ils ont normalement bien assez de problèmes pour occuper leur temps.

Plus rarement on déploie, plus la procédure de déploiement diverge de l'application, et plus les effets sont imprévisibles au prochain déploiement… ce qui accentue la peur du déploiement.

Plus rarement on déploie, plus la procédure de déploiement introduit une incertitude difficile à évaluer sur la livraison. On croit avoir fini, à entendre les développeurs, mais en réalité il reste beaucoup de travail à faire parcequ'on a privilégié les “features” au déploiement sans tenir compte du fait que non déployée une “feature” est un investissement sans gain.

On peut étoffer cette liste à l'envi. Cependant même si on déploie tout tout de suite, on a à sa disposition plein de techniques qui permettent de faire cela sans pour autant introduire des incompatibilités ou dégrader le ressenti et le travail des utilisateurs.

Pour des arguments d'une toute autre nature, les auteurs du petit livre “Accelerate” expliquent en se basant sur leur large observation empirique que les entreprises technologiques qui ont les meilleures résultats sont celles qui optimisent quatre métriques particulières (“4 key metrics”) et que l'adoption de la livraison continue est un changement organisationnel qui par essence optimise ces quatre métriques.

C'est parcqu'on est esclaves de nos vieilles habitudes.

C'est surtout pas trop compatible avec le fameux time-to-market qui se réduit de jour en jour.

C'est effrayant de lire ça!

On peut faire du continuous delivery et tester automatiquement. Dans mon dernier projet (pas exactement “petit”) on avait une chaîne de livraison continue et chaque “push” menait à une exécutions de toute la chaîne de tests (unitaires, intégration, et tout ce qu'on veut). Dans mon équipe (une petite vingtaine) on déployait peut-être des dizaines de fois par jour. Tout toujours testé et un time to market de quelques jours à peine (il faut quand-même concevoir et programmer.)

Si des gens ont besoin de cours particuliers et d'assistance pour monter ce genre d'infra, je suis joignable, encore environ 2j libres par semaine. :-)

Regarder le nutriscore d'un aliment n'est en général pas pertinent: ce qui compte c'est les habitudes alimentaires pas la consommation de tel ou tel aliment. Après il peut théoriquement servir à comparer des produits de la même catégorie mais pas sûr qu'il soit très utile pour ça non plus.

arrêter d'utiliser le système pour éviter de réécrire aux emplacements de l'ancien fichier

Idéalement le remonter en read-only.

Comme cet article continue de me mettre de bon humeur cinq jours en y repensant, je pensais utiliser les arguments de langage suivants:

“Et bien si ça ne va pas, vous pouvez passer au prochain candidat dans votre pile de CV qui sait faire plop plop fizz fizz et moi je passe au prochain recruteur. Bonne journée à vous et merci pour cet échange!”

La TapTempo fédération c'est une petite blagounette et aussi une collection de repos qui mettent ensemble les différentes versions du programme TapTempo.

Je viens de prendre mon poste d'agrégé à la rentrée après 12 ans dans le privé (en IT: développement, R&D, conseil…).

L'Éducation Nationale est à tout égard le pire des employeurs que j'aie jamais eu (et pourtant… xD) même les collègues sont dans leur majorité insupportables… mais c'est l'institution qui le rend comme ça.

Égards: carrière, support RH, adéquation mission/moyens, feedback, adéquation personnel/mission, formation continue… et bien évidemment le salaire, abyssal. Rien ne se négocie, rien ne se discute: c'est dans gueule, point final … avec un salaire qui ne le prends pas compte, travailler à ce prix là vu la qualification exigée c'est de l'humanitaire, même en faisant abstraction des conditions en question. Le contexte humain dans lequel le travail s'exerce est terrible.

Comme tout bon débutant je me retrouve sur les postes que personne ne veut, et à peine après une semaine de demi-service je me demande déjà combien de temps je vais rester…

Ç'aurait pu être pire tu aurais pu être prof dans l'éducation nationale. xD

C'est légal en France, ça ? Dans les pays civilisés on ne peut pas t'empêcher de discuter de ton salaire normalement.

Je ne pense pas que ce soit légal, même en Allemagne où je travaillais et avait pourtant cette clause inscrite. Des gens disent que la plupart des contrats de travail ont des clauses invalides… souvent sur des points mineurs. (Un cas important de clause invalide qu'il faut connaître est sur la non-concurrence: ce n'est possible que tant que l'entreprise indemnise son salarié après la fin du contrat.)

Je suis sûr que ni lui ni ses clients ne râlent quand le chômage est élevé et que les chercheurs d'emploi acceptent tout et n'importe quoi.

C'est quand même rigolo ces gens qui font mine de découvrir le libéralisme économique quand ça les met dans une situation inconfortable.

Heu… En essayant d'éviter de braquer (pas facile pour moi, mais en tous cas pas l'objectif), je dirai que c'est l'offre et la demande, suivant ton niveau de compétences (y compris la compétence de te vendre ou la compétence à accepter de travailler à Paris).

Et aussi ton capital social.

Moi je suis agrégé et docteur en maths et après plusieurs années d'expérience comme développeur dans des domaines plus ou moins R&D j'avais 65k€ par an. Une montagne d'argent impensable pour moi: entre mon père chomiste et son épouse fonctionnaire catégorie C en 80% je pense qu'on devait bien vivre à 5 avec que dalle de revenu par mois… j'ai fait une drôle de tête quand j'ai appris que mon voisin de bureau faisait 120k€ et que la différence principale entre nous c'est que lui a grandi dans un monde de possibilités où on peut se représenter de gagner 120k€ tandis que j'avais encore des obstacles psychologiques à franchir pour l'atteindre.

Ceci dit dans toutes les entreprises où j'ai travaillées j'avais des clauses de confidentialité sur les salaires, qui sont le signe que les salaires sont injustes. (Contraposée: si les salaires sont justes, il n'y a aucun inconvénient à ce qu'ils soient publics.)