Dans notre release de cette semaine : PHP Unit, modules PHAR, coding style PSR 12 et un serveur applicatif. Nos invités sont Stéphanie Trumtel et Romain Moro, de l'AFUP Toulouse.
Cette émission est la suite de la précédente CPU Ex0145 : 25 ans de PHP
Podcast, max de liens et commentaires : http://cpu.pm/0146
Chapitres :
La semaine prochaine : Les codecs du son
# Bravo
Posté par xulops (site web personnel) . Évalué à 4.
Merci Da Scritch pour cette émission.
Pourquoi ai-je l'impression que tu maîtrises mieux le sujet que tes invités ? Tu vas sans doute me dire que tu as potassé le truc en vue de l'émission, mais eux sont supposément toujours le nez dedans… bref.
Question : pourquoi l'enregistrement fait début septembre sort plus d'un mois après ? Qu'est-ce qui bloque une sortie plus rapide ?
[^] # Re: Bravo
Posté par Da Scritch (site web personnel, Mastodon) . Évalué à 5. Dernière modification le 20 octobre 2020 à 13:50.
La première est vile flatterie, je n'y répondrais pas :P
Mais je réponds à la deuxième :
La production de chaque émission me prend beaucoup de temps. Certaines largement plus que d'autres, et je pense notamment à la série vers la radio numérique en ce moment, sur laquelle j'ai justement une dead line : le lancement des bouquets DAB+ locaux à Toulouse le jeudi 5 novembre à 10h. Un CPU était prévu exceptionnellement en direct dans le Salon de la Radio de Toulouse qui était programmé le même jour, avec des représentants de législateurs (CSA, ANFR), mais finalement, l'orga de ce salon a complètement changé, pour des raisons évidentes. Finalement, on fera autrement, et j'ai une surprise pour les habitués de linuxfr à ce sujet.
Quand je produis un sujet complètement écrit, comme celui sur les petites histoires de la cryptographie, l'écriture de chaque émission m'a pris 6 mois, avec beaucoup de vérifications derrière (je dois avouer que la première a été écrite en mode “yolo”, à partir d'une de mes conférences humoristiques).
Et oui, tu as bien compris que je dois “sentir” le sujet, au sens que je me documente, je demande aux autres animateurs d'en faire pareil voire qu'on expérimente (on n’en est qu'à notre deuxième brassin, néanmoins). J'avance un peu sur Elixir, et je dois me remettre à Rust.
D'autres sujets sont donc produits en avance, parfois parce qu'il y a une disponibilité des invités, de l'équipe et que le sujet est “facile” à pré-produire.
Avoir des émissions d'avance est devenu très critique pour que CPU n'aie pas de gros trous pour n'importe quelle raison. Faire une émission hebdomadaire, et n'avoir que des rediffs pendant 4 semaines en Mai me désole à chaque fois. Cette année, on a tourné sur notre réserve dès début avril, résultat : Mai et juin, on n'avait rien sous la main car j'étais complètement saturé de travail (celui qui me sustente).
La première saison a été produite en flux tendu : enregistrée en extérieur, en public, deux jours avant diffusion. C'était excitant, mais littéralement épuisant, intenable. Notamment l'immense difficulté de trouver un lieu et de mobiliser suffisamment de personnes.
Autre problème, la qualité de son n'était pas satisfaisante pour moi, et donc plus le temps de remonter, corriger, équilibrer.
On est donc passé à des enregistrements groupés, par 2 ou 3 émissions en public, ce qui permet accessoirement que des invités fassent découvrir des sujets à un public venu pour un autre.
J'essaie d'avoir au moins 4 semaines d'avance, pour préparer les émissions sans stress, voire me prendre un bon gros week-end rien que pour moi.
Il y a des fois où on casse le plan prévu pour suivre l'actualité… Voire qu'on se fait dépasser involontairement. L'émission The mother of all demos a été diffusée un an trop tard, parce que j'ai cherché un invité francophone pendant 18 mois, et que 8 se sont désistés : « Tu as mieux potassé le sujet que moi ». Celle sur Vilém Flusser, Élise me signale l'avant-veille qu'on était le centenaire de l'anniversaire de Vilém Flusser. J'aurais pu pousser pour que la diff se face la bonne semaine, et pas 8 jours après, mais à la ré-écoute, il y avait un élément sonore que j'ai voulu recorriger, et à raison.
Donc, oui, on enregistre un mois à l'avance. Et si en radio, c'est rare, sachez que les docus en TV sont enregistrés encore plus tôt.
[^] # Re: Bravo
Posté par xulops (site web personnel) . Évalué à 3.
Merci, c'est très clair et on comprends bien que ce ne sont pas des émissions faites à la va-vite.
Vu le travail de préparation, il y a un vrai boulot de fond qui fait que tu es sans doute souvent plus au courant des dernières évolutions que tes invités. Ca permet de poser les bonnes questions ; et puis pour l'auditeur, qu'une bonne info vienne de l'interviewer ou des invités, peu importe, tout est bon à prendre.
En ayant un travail alimentaire, c'est vraiment pas mal, donc re-bravo.
[^] # Re: Bravo
Posté par Da Scritch (site web personnel, Mastodon) . Évalué à 2.
Ah ben, y'a pas marqué “The Shift Project” ici.
[^] # Re: Bravo
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
Au lieu de faire plusieurs émissions dans le présent pour le futur, tu devrais plutôt chaque semaine prendre ta machine temporelle et aller chercher l'émission suivante dans le futur et la diffuser dans le présent !
Seul problème: le da scritch de la semaine N+1 se retrouve alors sans émission, mais il suffit qu'il aille chercher l'émission N+2 et dire au prochain da scritch d'aller chercher la sienne en N+3 et ainsi de suite.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Descente dans le terrier du lapin
Posté par fx80a . Évalué à 1.
Les interpréteurs de PHP 2 et 3 sont des interpréteurs pures. C'est-à-dire qu'ils interprètent le programme pendant la phase d'analyse. Et tout ça écrit en Yacc. La grammaire de PHP 2 est claire mais buggée. Celle de PHP 3 est correcte mais pas facilement lisible. Implémenter un compilateur récursif descendant aurait été tellement plus simple et moins sujet à erreur.
Merci pour vos émission qui, bien souvent, attisent ma curiosité.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.