Je suis certain de manquer d'expérience pour juger de l'employabilité des regex, notamment par mes besoins limités.
J'ai toujours évité de me trouver dans une situation de parsing de texte ou il faut en effet sortir les grands moyens.
Pour les détails de l'architecture et tous les détails techniques, ça viendra. Ce n'est pas ma priorité, car ce n'est pas un outil pour dev, mais pour un "utilisateur final", et c'est un outil très spécialisé qui ne s'utilise pas sur un coup de tête.
Pour la partie ACLs/Utilisateurs, le code que tu montre est un code écrit juste pour que ça marche. C'est un vieux code qui sera refait totalement. Je n'utiliserais plus le moteur de Play pour accéder aux données, et donc plus besoin du Model de Play.
J'abandonnerai aussi progressivement les vues en Groovy pour du 100% React.
Play n'est pas le centre technique. Et il va l'être de moins en moins. C'est juste la partie interface web. Il y une partie service système (Probe) et un CLI. Il y a aussi maintenant un serveur FTP.
Si tu cherche du code métier, tu va en avoir dans transcode, dans metadata. Le centre technique, tu le trouvera plutôt dans manager.
Quand a MetadataCenter, c'est un point de départ pour instancier les moteurs d'analyse et de génération de bas débits. Le nom n'est peut-être pas le meilleur, j'avoue, mais cette classe à beaucoup changée au cours du temps.
Et n'oublie pas qu'il s'agit d'une alpha et il manque encore pas mal de chose, notamment la partie action utilisateur.
Les controleurs Play sont un peu anciens. C'est possible que j'y ai laissé par simplicité de la persistance. Pour les controleurs AsyncJS (mon API qui me permet d'abstraire coté JS et coté Play des échanges de Json entre les deux qui sont dé/sérialisés automatiquement via Google Gson), c'est autement probable vue que le Controleur n'a plus grand chose à faire et me sert juste à passer les plats.
L' "injection des dépendances", j'en ai déjà entendu parlé. J'ai un système de module (une extension de celui de Play) et de surcharge d'une API qui détecte via le classpath des éléments externes, mais je pense pas que tu parle de ça. Et je me sens déjà très libre quand je refactorise.
Encore une fois ne prends pas ombrage, mais cette profusion de méthodes statiques sont le signe d'une conception très procédurale (qu'un autre l'a appelé de l'an 2000). […]
Pense tu avoir fait suffisamment le tour de mon code pour penser ça ? J'ai une masse de classes, d'API, et d'interfaces pas du tout statiques ! Je souhaite plus que tout éviter le coté script de coin de table. Et j'ai commencer le Java en apprenant le 0 statique. Puis j'ai évolué avec l'expérience. Et plus généralement, ou est le problème, je veux dire, fondamentalement ? Qu'est ce que je risque ? De me perdre dans mon code ? De me retrouver bloqué ? Au final, je m'en suis toujours sorti, avec assez peu de bugs. A chaque fois que j'ai du dégager du code, c'était pour remplacer une approche trop limitée ou trop simpliste pour quelque chose de plus élégant et évolutif. Par exemple, pour changer mon système de log (plus de 1000 messages), ça m'a pris au total une bonne journée. Le plus long à été de repenser certain messages écrits un peu vite (et ultra verbeux).
J'ai l'impression que tu n'as pas saisi certains des concepts fondamentaux du paradigme de programmation orientée objet.
Peut-être, oui ! Mais j'évolue en permanence. React, par exemple, m'a beaucoup appris.
[…] Le tien, je ne sais pas comment le qualifier à part que j'ai l'impression qu'il est inexistant ou dilué (encore une fois je peux me tromper). […]
Cette partie de code va surtout dégager !
J'ai un peu mal à te suivre sur ce qui est du Java anti-pattern. Je comprends que j'ai l'air de faire quelque chose de mal, mais je ne vois pas trop de quelle façon !
[…] qui permettrait vraiment d'ouvrir ton code aux contributions autrement que par la licence. […]
Pour le moment, mon code est publique, ainsi que et mon activité lié (Issues, site, historique Git). Je n'ai pas encore de politique de projets à plusieurs, pour différences raisons, mais surtout par ce qu'il me manque encore des socles techniques indispensables pour que le tout soit cohérent (comme les actions utilisateurs). Mon dev est pour le moment dirigé vers des fonctions métiers pointues comme l'analyse de médias et leurs transformation automatique.
Quand tout ceci aura décanté, et que ma base sera plus propre qu'elle n'est, notamment au niveau de la dete technique, je m'attaquerai à de la vrai doc, et ferai le nécessaire pour inciter à mettre dans les mains dans le moteur. Et là j'écrirai un README à la racine du Git !
Je suis d'accord avec toi dans le sens ou je manque de retour précis sur mon travail. En en parlant ici, je fait un début de chemin, et je sais à quoi je m'expose.
Les static, les regex, les Threads et les try sont un parti pris volontaire, fait après réflexion et amené par l'expérience. Et c'est cette expérience que je montre ici. Qu'elle soit bonne ou mauvaise.
Je me suis permis d'émettre un avis sur le travail d'autres surtout parce que dans ces cas, il y avais vraiment un je-m'en-fout dans l'approche du travail du dev. Et ceci avait une vraie répercussion sur la suite.
Pour les regex : je vais être clair : ça me saoule, c'est vite compliqué et illisible. Je sais que c'est sacré et que cela ne ce fait pas d'en dire du mal, mais écrire une déclaration de magie noire ne me motive pas plus que ça.
Je voulais juste dire que l'on est pas forcément obligé de s'infliger cette peine quand on a de petits besoins simples.
Un code très très très moyen, mais un code qui marche H24 et qui évolue depuis 3 ans sur 5 nodes maintenant ! Ecrit par un mec dont c'est pas le métier, qui n'est pas payé pour cela, qui fait ça sur du temps libre, qui ne prétend pas être un pro ni même un formateur.
Pour moi un code très très moyen, c'est un code qui juste marche et que l'on ose plus toucher car ça ferai boom. Je pense pas que ce soit mon cas ici.
Log2 est ancien et abandonné. Ça m'a bien aidé, mais je n'en suis plus satisfait. J'ai pas mal progressé depuis.
De même qu'il y a un vrai gap de progression entre différentes parties de MyDMAM.
Le static partout (plutôt souvent que partout) est un choix qui c'est fait progressivement. Ça m'a permis de simplifier beaucoup la structure. Et de me permettre des phases de dev plus simples et plus légères.
Le synchonized partout (pas partout non plus) me permet de me protéger de désagréments potentiels. Malgré ça je n'ai pas de problèmes de lock, de perfs ou même de mémoire.
Les pb de bases de données sont parfois catchés dans les logs… quand cela n'a pas de vrai impact dans l'activité, du genre "si il n'y est pas arrivé, ce n'est pas grave".
Les accès Bdd ne sont pas forcément une priorité ! Et de fait, en prod j'ai déjà perdu le réseau pendant quelques heures, mon code à gueuler, mais a survécu et a repris le travail quand le réseau est revenu. J'ai vu trop d'applis partir en vrille lors d'une perte temporaire de la bdd.
Tu as très certainement raison et moi tord, mais mon code marche très bien et évolue beaucoup. Pour moi, c'est le deal.
Attention à ne pas me prêter des attentions qui ne sont pas les miennes !
Jamais je dit que je détiens et suit des méthodes de travail idéales, mais juste ce que j'ai le plus constaté, à force. C'est plus un retour d'expérience qu'un cours de code, et je sais très bien qu'un pro de métier saura facilement me dire que j'ai tord et pourquoi.
Quand je parle de bien nommer, bien sûr, ça peut toujours être mieux.
En fait je faisais allusion au fait que c'est l'un des trucs les plus compliqués qui soit quand on code. Et que j'ai vu trop de code ou visiblement ce travail saoulait le dev et était bâclé.
L'audiovisuel.
Dans lequel on écrit du code quand on a pas le choix, quand on y est obligé, donc on va vite car on a pas le temps et les moyens de le faire.
Un monde où l'on préfère payer quelqu'un se taper une tache fastidieuse à la main plutôt que de faire faire écrire un bout de code qui fera ça plus vite.
En 10 ans j'ai quasiment jamais été confronté à un travail de dev. propre. Ce que je fait (un MAM libre et gratuit) c'est un OVNI dans nos métiers.
Oui, je suis assez d'accord. Surtout sur le coté sans pitié de l'approche.
Ecrire du code, c'est se construire un monde, dans lequel on se rapproche du contrôle absolu de tout ce qui s'y passe.
Bien sur !
Je pensais plutôt à un vomis de code dans main() avec des variables sans vrais noms que l'on écrit pour vérifier une théorie ou tester un truc.
Ce que tu soulève est interessant. Je n'ai pas le niveau pour comprendre l'implication que les points que tu soulève ont dans mon code.
C'est surement mal. Mais je m'en passe. Aujourd'hui, je refactore sans problème, j'évolue facilement. Quand je doit casser du code, c'est parce qu'il est mal écrit ou mal pensé. Je doute que des TDD peuvent m'éviter d'écrire du caca. En tout cas le TDD, ça m'embrouille plus qu'autre chose.
N'oublie pas que je ne suis pas pro, ni même payé pour écrire du code. Et je suis seul a mètre la main à la tache sur mon projet. Change ces paramètres, et tu aura de fait totalement raison, je pense.
Le singleton et le static m'ont permis de simplifier et d'alléger grandement mon implémentation et l'approche de la structure de mon application. C'est surement pas bien, mais pour le moment, et surtout depuis que je fait comme ça, ça n'a que des avantages à mes yeux.
L'avantage d'une variable exposée à l'air libre, c'est que l'on suppose rien. Celui qui veut s'en servir sait qu'il devra la tester avant de faire quoi que ce soit.
Je m'en sert bcp quand j'ai un object qui est désérialisé depuis l'extérieur : on est jamais sur de ce qu'il contient. A chacun de faire ses vérifications au besoin.
Après, l'exemple en warning que tu donne valide le fait que ce n'est pas applicable tout le temps, bien sur.
Pour ce qui est d'utiliser des Threads pour faire des calculs, je n'ai pas été assez clair : mon avis est de ne pas le faire directement, mais via une lib spécialisée.
J'utilise bcp les Threads pour faire des sous-services : un while(true) avec un sleep (enfin quelque chose du genre) afin de pouvoir executer quelque chose très régulièrement, comme un get de db ou un scan de dossier.
Mon exemple de regex foireux était, pour un regex instancié en static, de chercher et de remplacer des caractères par d'autres et rechercher quelques séquences pour les remplacer (genre supprimer deux espaces par un seul). J'ai galéré pour y arriver a en faire un regex, lent. Mais un for sur chaque caractère l'a éclaté en terme vitesse d'execution et de lisiblité de code. Autre exemple de code ou j'ai dit non a un regex.
L'industrie de la production et de diffusion des médias, si on peut dire ça comme ça, est très vaste, parcellée de différents métiers, pratiques, cultures, de différents modèles de business, etc…
On a commencé il y a bien longtemps par des silos en béton armés : le cinéma, la radio, le théâtre, la presse écrite.
Puis est arrivée la télévision qui a commencé à mélanger les genres : mettre un tournage type cinéma dans un théatre, demander aux pros de la radio de prendre le son, et hop émettre un signal aux quelques riches qui pouvaient ce payer un poste de réception. Tout ceci était très expérimental : comment imaginer de faire de la télévision avant même l'invention du transistor…
Et puis on a évolué, au rythme des lois, des idées, des normes, des technologies.
Les métiers ont commencer à évoluer, les pratiques aussi. Depuis ça ne c'est jamais arrêté.
Quand je suis né, la télévision était tout juste en couleur, produite et diffusé en analogique sur des tubes, le cinéma en pellicule, la radio tout juste en FM stéréo. Les transmissions satellites devenaient réalité pour la télé. La presse écrite était la référence pour l'information dans les radios et les télés.
Quand j'ai eu ma formation pro, la télévision était produite et tout juste diffusée en numérique, on commençait à parler de HD. La radio travaillait depuis longtemps en numérique et on commençais à parler de sa diffusion en numérique. Le cinéma post-produisait de plus en plus en numérique. La presse écrite étudiait le modèle du gratuit payé par la pub.
Aujourd'hui, on parle 4K, on grignote des fréquences TV pour de la téléphonie 4G, le cinéma est quasiment totalement en numérique, la radio installe des caméras pour faire des vidéo sur Youtube, la presse écrite à une "unité vidéo" dans chaque rédaction, on va au cinéma pour regarder de l'opéra…
Et aujourd'hui on a tous l'équivalent d'une chaine de production et de diffusion de télé/cinéma/radio/presse écrite. dans sa poche.
Alors oui, il y a de la casse. Comment imaginer que tout cela puisse ce produire, et aussi vite ? Un exemple : Sony. Ils ont fabriqué la télévision (1"C, Beta SP, Digital Betacam, et nombre de leurs moniteurs). Aujourd'hui, ils ont quasiment disparus. Merde ! J'ai été formé sur des équipements Sony, puis j'ai bossé après sur ces mêmes équipements. Et cette année j'ai du gérer deux grosses refontes dans une chaine de TV : Sony à totalement disparu. Il y a 10 ans, il aurai été omniprésent.
Autre exemple : les formations. En 10 ans on est passé d'un profil électronique à un profil informatique réseau. Dans les métiers technique de la télévision il est aujourd'hui plus utile de savoir faire un ping qu'une soudure (surtout quand on cherche du boulot).
Et d'un point de vue finances : si je dit Netflix ou Youtube, qui aurait plus penser qu'ils auraient existé sérieusement dans le paysage audiovisuel. Il y a 10 ans, l'un louait des DVD par correspondance et l'autre montrait des vidéos du singe qui se renifles les fesses. Et maintenant ? L'un produit de plus en plus de contenus "originaux" de qualité, et l'autre c'est imposé comme un acteur très sérieux et alternatif aux silos d'origine.
Bref, on pourrait donner plein d'exemples, mais en conclusion, je dirais que l'évolution que l'on vit depuis les débuts de cette industrie n'est pas prêt de ralentir, et tout ceux qui ne s'y adaptent pas vont souffrir. Les exemples ne manque pas.
Dans "tous", je parle coté projet perso, ou de fait, tout ce qui n'est pas industriel, cadré, prévu.
Et mon but n'est pas de fournir du code qui servira de référence aux génération futures, mais juste un outil que j'espère pas trop mal pensé et qui peut rendre service.
Point important à ne pas oublier : mon projet est en alpha, je ne prétends pas qu'il soit utilisable actuellement out-of-the-box et j'ai pas mal de doc à faire (c'est très long à écrire). Je ne souhaite pas pour le moment écrire des choses qui vont s'avérer obsolète assez vite.
Quand je dit que tout le monde se fiche de savoir comment c'est histoire de dire qu'en prenant la totalité des utilisateurs d'un logiciel libre, combien iront voire dans le code ? Et combien même comprennent quoi que se doit au code ?
Les questions que tu poses sont légitimes, j'en réponds à certaines, d'autres pas encore, et d'autres volontairement non pour éviter que l'on se méprenne sur ce projet et sur ce que l'on peut en faire actuellement.
C'est bien mon approche. MyDMAM est une plateforme qui est composée de pleins de petites API (et de leurs implémentations) pensées pour travailler ensemble mais aussi en certaine autonomie.
Mon but final, en fait, c'est ça : penser une structure fiable et bien pensée qui arrivera à supporter toutes les petites idées qui vont venir au fur et à mesure. Et ça, c'est fait, ça fonctionne. Il ne reste "plus" qu'a ajouter les petites idées.
Je doit en effet mélanger l'approche pas à pas / bidouille et l'approche papier/crayon/plan. "Tenter quelque chose" versus "voir loin et grand".
Et n'oublie pas que je suis pour le moment seul sur mon ouvrage et n'ayant aucune formation ni expérience dans les exemples industriels que tu a cité. Fort heureusement, ce n'est qu'un outil pour manipuler des médias, pas déplacer des humains !
Oui, tout est bardé de normes et de convention, mais ça ne suffit pas pour changer les esprits et les pratiques au quotidien. Et chacun va a son rythme.
Quand toute une industrie se transforme en 10 ans, il y a de la casse. Sans compter que l'économie autour a beaucoup changé.
Mon terme de "Contrôle qualité" est peut être mal choisi ici.
Tu parle du vrai "Contrôle qualité", en tant que process industriel, et disons-le, lourd.
Je parle plutôt du compromis entre ce qui vient d'être implémenté et qui à l'air de marcher, et ce que l'utilisateur peut tolérer de dysfonctionnement. Et de fait, quand on est aussi bien dev. que user, ce compromis est très dur à obtenir.
La plupart des questions que tu soulève, j'y répondrai par du "surement… bof… j'espère…" car je n'ai pas la prétention d'arriver à ce niveau de qualité de travail, et encore moins seul.
Mais c'est bien sur un idéal que je me dirige vers.
Pour les femmes dans l'info, c'est juste culturel. Les femmes ont toujours existé dans ces métiers, c'est juste qu'elles sont très peu présentes et très peu visibles.
Avec la transformation des métiers et de leurs diversifications, la prochaine et nouvelle génération résoudra le problème de lui même car il y aura bcp plus de jobs aussi bien en quantité qu'en nature.
En fait, il y a autant de définitions que d'implémentations.
Pour faire court, les "professionnels de l'audiovisuel" sont un peu bordélique. Ils aiment avoir pleins d'outils et des machins avec des fils, et ils adoraient avoir de belles bandes vidéos qu'ils mettaient dans leurs beaux magnétoscopes couteux et rutilants.
Ils confiaient les bandes à des archivistes pour les trier et les ranger, mais ça c'est chiant à faire, donc on y faisait pas vraiment gaffe.
Quand nos métiers ont lâché les bandes vidéo au profits de fichiers, ça été la panique. Ça c'est fait très vite et on c'est tous trouvé cons avec nos NAS pleins à craquer. Evidement, quand on a lachés les bandes, on a aussi largué les archivistes qui allaient avec. On a fait de super économies de m2 et de salaires.
Et donc depuis plusieurs années on rame pour ranger, traiter, retrouver nos fichiers. La demande à créer l'offre, et on c'est retrouvé avec pleins de marchants de boites noires tout-en-un-qui-fait-tour pour ça.
Ça m'a toujours gonflé de voir mes employeurs/confrères signer des gros, très gros cheques à ces gens là, qui n'ont même pas de honte à vendre des technos proprio très fermés et souvent bardé de brevets.
Quand dans le monde de l'IT pense de plus en plus "ouverture, interopérabilité, normes, bigdata…", le monde de l'audiovisuel pro n'en n'est qu'a la pré-histoire de tout ça.
[^] # Re: Show me the code
Posté par Media ex Machina (site web personnel, Mastodon) . En réponse au journal L’homme orchestre, partie 2 : écrire du code (en Java). Évalué à -1.
oui, d'une certaine façon, c'est pour cela que j'ai fait ce journal…
[^] # Re: Show me the code
Posté par Media ex Machina (site web personnel, Mastodon) . En réponse au journal L’homme orchestre, partie 2 : écrire du code (en Java). Évalué à 1.
Je suis certain de manquer d'expérience pour juger de l'employabilité des regex, notamment par mes besoins limités.
J'ai toujours évité de me trouver dans une situation de parsing de texte ou il faut en effet sortir les grands moyens.
[^] # Re: Show me the code
Posté par Media ex Machina (site web personnel, Mastodon) . En réponse au journal L’homme orchestre, partie 2 : écrire du code (en Java). Évalué à 1.
Je crois que mes besoins de regex se limitent à ça !
[^] # Re: Show me the code
Posté par Media ex Machina (site web personnel, Mastodon) . En réponse au journal L’homme orchestre, partie 2 : écrire du code (en Java). Évalué à 1.
Merci pour ce retour détaillé.
Pour les détails de l'architecture et tous les détails techniques, ça viendra. Ce n'est pas ma priorité, car ce n'est pas un outil pour dev, mais pour un "utilisateur final", et c'est un outil très spécialisé qui ne s'utilise pas sur un coup de tête.
Pour la partie ACLs/Utilisateurs, le code que tu montre est un code écrit juste pour que ça marche. C'est un vieux code qui sera refait totalement. Je n'utiliserais plus le moteur de Play pour accéder aux données, et donc plus besoin du Model de Play.
J'abandonnerai aussi progressivement les vues en Groovy pour du 100% React.
Play n'est pas le centre technique. Et il va l'être de moins en moins. C'est juste la partie interface web. Il y une partie service système (Probe) et un CLI. Il y a aussi maintenant un serveur FTP.
Si tu cherche du code métier, tu va en avoir dans transcode, dans metadata. Le centre technique, tu le trouvera plutôt dans manager.
Quand a MetadataCenter, c'est un point de départ pour instancier les moteurs d'analyse et de génération de bas débits. Le nom n'est peut-être pas le meilleur, j'avoue, mais cette classe à beaucoup changée au cours du temps.
Et n'oublie pas qu'il s'agit d'une alpha et il manque encore pas mal de chose, notamment la partie action utilisateur.
Les controleurs Play sont un peu anciens. C'est possible que j'y ai laissé par simplicité de la persistance. Pour les controleurs AsyncJS (mon API qui me permet d'abstraire coté JS et coté Play des échanges de Json entre les deux qui sont dé/sérialisés automatiquement via Google Gson), c'est autement probable vue que le Controleur n'a plus grand chose à faire et me sert juste à passer les plats.
L' "injection des dépendances", j'en ai déjà entendu parlé. J'ai un système de module (une extension de celui de Play) et de surcharge d'une API qui détecte via le classpath des éléments externes, mais je pense pas que tu parle de ça. Et je me sens déjà très libre quand je refactorise.
Pense tu avoir fait suffisamment le tour de mon code pour penser ça ? J'ai une masse de classes, d'API, et d'interfaces pas du tout statiques ! Je souhaite plus que tout éviter le coté script de coin de table. Et j'ai commencer le Java en apprenant le 0 statique. Puis j'ai évolué avec l'expérience. Et plus généralement, ou est le problème, je veux dire, fondamentalement ? Qu'est ce que je risque ? De me perdre dans mon code ? De me retrouver bloqué ? Au final, je m'en suis toujours sorti, avec assez peu de bugs. A chaque fois que j'ai du dégager du code, c'était pour remplacer une approche trop limitée ou trop simpliste pour quelque chose de plus élégant et évolutif. Par exemple, pour changer mon système de log (plus de 1000 messages), ça m'a pris au total une bonne journée. Le plus long à été de repenser certain messages écrits un peu vite (et ultra verbeux).
Peut-être, oui ! Mais j'évolue en permanence. React, par exemple, m'a beaucoup appris.
Cette partie de code va surtout dégager !
J'ai un peu mal à te suivre sur ce qui est du Java anti-pattern. Je comprends que j'ai l'air de faire quelque chose de mal, mais je ne vois pas trop de quelle façon !
Pour le moment, mon code est publique, ainsi que et mon activité lié (Issues, site, historique Git). Je n'ai pas encore de politique de projets à plusieurs, pour différences raisons, mais surtout par ce qu'il me manque encore des socles techniques indispensables pour que le tout soit cohérent (comme les actions utilisateurs). Mon dev est pour le moment dirigé vers des fonctions métiers pointues comme l'analyse de médias et leurs transformation automatique.
Quand tout ceci aura décanté, et que ma base sera plus propre qu'elle n'est, notamment au niveau de la dete technique, je m'attaquerai à de la vrai doc, et ferai le nécessaire pour inciter à mettre dans les mains dans le moteur. Et là j'écrirai un README à la racine du Git !
[^] # Re: Show me the code
Posté par Media ex Machina (site web personnel, Mastodon) . En réponse au journal L’homme orchestre, partie 2 : écrire du code (en Java). Évalué à 0.
Je suis d'accord avec toi dans le sens ou je manque de retour précis sur mon travail. En en parlant ici, je fait un début de chemin, et je sais à quoi je m'expose.
Les static, les regex, les Threads et les try sont un parti pris volontaire, fait après réflexion et amené par l'expérience. Et c'est cette expérience que je montre ici. Qu'elle soit bonne ou mauvaise.
Je me suis permis d'émettre un avis sur le travail d'autres surtout parce que dans ces cas, il y avais vraiment un je-m'en-fout dans l'approche du travail du dev. Et ceci avait une vraie répercussion sur la suite.
[^] # Re: Show me the code
Posté par Media ex Machina (site web personnel, Mastodon) . En réponse au journal L’homme orchestre, partie 2 : écrire du code (en Java). Évalué à -1.
Pour les regex : je vais être clair : ça me saoule, c'est vite compliqué et illisible. Je sais que c'est sacré et que cela ne ce fait pas d'en dire du mal, mais écrire une déclaration de magie noire ne me motive pas plus que ça.
Je voulais juste dire que l'on est pas forcément obligé de s'infliger cette peine quand on a de petits besoins simples.
[^] # Re: Show me the code
Posté par Media ex Machina (site web personnel, Mastodon) . En réponse au journal L’homme orchestre, partie 2 : écrire du code (en Java). Évalué à 4.
Un code très très très moyen, mais un code qui marche H24 et qui évolue depuis 3 ans sur 5 nodes maintenant ! Ecrit par un mec dont c'est pas le métier, qui n'est pas payé pour cela, qui fait ça sur du temps libre, qui ne prétend pas être un pro ni même un formateur.
Pour moi un code très très moyen, c'est un code qui juste marche et que l'on ose plus toucher car ça ferai boom. Je pense pas que ce soit mon cas ici.
Log2 est ancien et abandonné. Ça m'a bien aidé, mais je n'en suis plus satisfait. J'ai pas mal progressé depuis.
De même qu'il y a un vrai gap de progression entre différentes parties de MyDMAM.
Le static partout (plutôt souvent que partout) est un choix qui c'est fait progressivement. Ça m'a permis de simplifier beaucoup la structure. Et de me permettre des phases de dev plus simples et plus légères.
Le synchonized partout (pas partout non plus) me permet de me protéger de désagréments potentiels. Malgré ça je n'ai pas de problèmes de lock, de perfs ou même de mémoire.
Les pb de bases de données sont parfois catchés dans les logs… quand cela n'a pas de vrai impact dans l'activité, du genre "si il n'y est pas arrivé, ce n'est pas grave".
Les accès Bdd ne sont pas forcément une priorité ! Et de fait, en prod j'ai déjà perdu le réseau pendant quelques heures, mon code à gueuler, mais a survécu et a repris le travail quand le réseau est revenu. J'ai vu trop d'applis partir en vrille lors d'une perte temporaire de la bdd.
Tu as très certainement raison et moi tord, mais mon code marche très bien et évolue beaucoup. Pour moi, c'est le deal.
[^] # Re: Show me the code
Posté par Media ex Machina (site web personnel, Mastodon) . En réponse au journal L’homme orchestre, partie 2 : écrire du code (en Java). Évalué à 1.
Attention à ne pas me prêter des attentions qui ne sont pas les miennes !
Jamais je dit que je détiens et suit des méthodes de travail idéales, mais juste ce que j'ai le plus constaté, à force. C'est plus un retour d'expérience qu'un cours de code, et je sais très bien qu'un pro de métier saura facilement me dire que j'ai tord et pourquoi.
Quand je parle de bien nommer, bien sûr, ça peut toujours être mieux.
En fait je faisais allusion au fait que c'est l'un des trucs les plus compliqués qui soit quand on code. Et que j'ai vu trop de code ou visiblement ce travail saoulait le dev et était bâclé.
[^] # Re: Barbecue
Posté par Media ex Machina (site web personnel, Mastodon) . En réponse au journal L’homme orchestre, partie 2 : écrire du code (en Java). Évalué à 3.
L'audiovisuel.
Dans lequel on écrit du code quand on a pas le choix, quand on y est obligé, donc on va vite car on a pas le temps et les moyens de le faire.
Un monde où l'on préfère payer quelqu'un se taper une tache fastidieuse à la main plutôt que de faire faire écrire un bout de code qui fera ça plus vite.
En 10 ans j'ai quasiment jamais été confronté à un travail de dev. propre. Ce que je fait (un MAM libre et gratuit) c'est un OVNI dans nos métiers.
[^] # Re: Stalin programming
Posté par Media ex Machina (site web personnel, Mastodon) . En réponse au journal L’homme orchestre, partie 2 : écrire du code (en Java). Évalué à -1.
Oui, je suis assez d'accord. Surtout sur le coté sans pitié de l'approche.
Ecrire du code, c'est se construire un monde, dans lequel on se rapproche du contrôle absolu de tout ce qui s'y passe.
[^] # Re: Barbecue
Posté par Media ex Machina (site web personnel, Mastodon) . En réponse au journal L’homme orchestre, partie 2 : écrire du code (en Java). Évalué à 0.
Bien sur !
Je pensais plutôt à un vomis de code dans main() avec des variables sans vrais noms que l'on écrit pour vérifier une théorie ou tester un truc.
[^] # Re: Les tests
Posté par Media ex Machina (site web personnel, Mastodon) . En réponse au journal L’homme orchestre, partie 2 : écrire du code (en Java). Évalué à 0.
Merci pour ton compliment.
Ce que tu soulève est interessant. Je n'ai pas le niveau pour comprendre l'implication que les points que tu soulève ont dans mon code.
C'est surement mal. Mais je m'en passe. Aujourd'hui, je refactore sans problème, j'évolue facilement. Quand je doit casser du code, c'est parce qu'il est mal écrit ou mal pensé. Je doute que des TDD peuvent m'éviter d'écrire du caca. En tout cas le TDD, ça m'embrouille plus qu'autre chose.
N'oublie pas que je ne suis pas pro, ni même payé pour écrire du code. Et je suis seul a mètre la main à la tache sur mon projet. Change ces paramètres, et tu aura de fait totalement raison, je pense.
Le singleton et le static m'ont permis de simplifier et d'alléger grandement mon implémentation et l'approche de la structure de mon application. C'est surement pas bien, mais pour le moment, et surtout depuis que je fait comme ça, ça n'a que des avantages à mes yeux.
[^] # Re: Merci
Posté par Media ex Machina (site web personnel, Mastodon) . En réponse au journal L’homme orchestre, partie 2 : écrire du code (en Java). Évalué à 2.
L'avantage d'une variable exposée à l'air libre, c'est que l'on suppose rien. Celui qui veut s'en servir sait qu'il devra la tester avant de faire quoi que ce soit.
Je m'en sert bcp quand j'ai un object qui est désérialisé depuis l'extérieur : on est jamais sur de ce qu'il contient. A chacun de faire ses vérifications au besoin.
Après, l'exemple en warning que tu donne valide le fait que ce n'est pas applicable tout le temps, bien sur.
Pour ce qui est d'utiliser des Threads pour faire des calculs, je n'ai pas été assez clair : mon avis est de ne pas le faire directement, mais via une lib spécialisée.
J'utilise bcp les Threads pour faire des sous-services : un while(true) avec un sleep (enfin quelque chose du genre) afin de pouvoir executer quelque chose très régulièrement, comme un get de db ou un scan de dossier.
Mon exemple de regex foireux était, pour un regex instancié en static, de chercher et de remplacer des caractères par d'autres et rechercher quelques séquences pour les remplacer (genre supprimer deux espaces par un seul). J'ai galéré pour y arriver a en faire un regex, lent. Mais un for sur chaque caractère l'a éclaté en terme vitesse d'execution et de lisiblité de code. Autre exemple de code ou j'ai dit non a un regex.
[^] # Re: Chouette recul
Posté par Media ex Machina (site web personnel, Mastodon) . En réponse au journal L’homme orchestre, partie 2 : écrire du code (en Java). Évalué à 1.
Merci pour le compliment ! Je tricote du code depuis 15 ans, j'ai encore à découvrir.
Mes idées sont de simples constatations naturelles que j'ai pu faire, en dehors de toute théorie.
[^] # Re: oui, mais c'est quoi un MAM ?
Posté par Media ex Machina (site web personnel, Mastodon) . En réponse au journal L'homme orchestre, partie 1 : les casquettes. Évalué à 2.
L'industrie de la production et de diffusion des médias, si on peut dire ça comme ça, est très vaste, parcellée de différents métiers, pratiques, cultures, de différents modèles de business, etc…
On a commencé il y a bien longtemps par des silos en béton armés : le cinéma, la radio, le théâtre, la presse écrite.
Puis est arrivée la télévision qui a commencé à mélanger les genres : mettre un tournage type cinéma dans un théatre, demander aux pros de la radio de prendre le son, et hop émettre un signal aux quelques riches qui pouvaient ce payer un poste de réception. Tout ceci était très expérimental : comment imaginer de faire de la télévision avant même l'invention du transistor…
Et puis on a évolué, au rythme des lois, des idées, des normes, des technologies.
Les métiers ont commencer à évoluer, les pratiques aussi. Depuis ça ne c'est jamais arrêté.
Quand je suis né, la télévision était tout juste en couleur, produite et diffusé en analogique sur des tubes, le cinéma en pellicule, la radio tout juste en FM stéréo. Les transmissions satellites devenaient réalité pour la télé. La presse écrite était la référence pour l'information dans les radios et les télés.
Quand j'ai eu ma formation pro, la télévision était produite et tout juste diffusée en numérique, on commençait à parler de HD. La radio travaillait depuis longtemps en numérique et on commençais à parler de sa diffusion en numérique. Le cinéma post-produisait de plus en plus en numérique. La presse écrite étudiait le modèle du gratuit payé par la pub.
Aujourd'hui, on parle 4K, on grignote des fréquences TV pour de la téléphonie 4G, le cinéma est quasiment totalement en numérique, la radio installe des caméras pour faire des vidéo sur Youtube, la presse écrite à une "unité vidéo" dans chaque rédaction, on va au cinéma pour regarder de l'opéra…
Et aujourd'hui on a tous l'équivalent d'une chaine de production et de diffusion de télé/cinéma/radio/presse écrite. dans sa poche.
Alors oui, il y a de la casse. Comment imaginer que tout cela puisse ce produire, et aussi vite ? Un exemple : Sony. Ils ont fabriqué la télévision (1"C, Beta SP, Digital Betacam, et nombre de leurs moniteurs). Aujourd'hui, ils ont quasiment disparus. Merde ! J'ai été formé sur des équipements Sony, puis j'ai bossé après sur ces mêmes équipements. Et cette année j'ai du gérer deux grosses refontes dans une chaine de TV : Sony à totalement disparu. Il y a 10 ans, il aurai été omniprésent.
Autre exemple : les formations. En 10 ans on est passé d'un profil électronique à un profil informatique réseau. Dans les métiers technique de la télévision il est aujourd'hui plus utile de savoir faire un ping qu'une soudure (surtout quand on cherche du boulot).
Et d'un point de vue finances : si je dit Netflix ou Youtube, qui aurait plus penser qu'ils auraient existé sérieusement dans le paysage audiovisuel. Il y a 10 ans, l'un louait des DVD par correspondance et l'autre montrait des vidéos du singe qui se renifles les fesses. Et maintenant ? L'un produit de plus en plus de contenus "originaux" de qualité, et l'autre c'est imposé comme un acteur très sérieux et alternatif aux silos d'origine.
Bref, on pourrait donner plein d'exemples, mais en conclusion, je dirais que l'évolution que l'on vit depuis les débuts de cette industrie n'est pas prêt de ralentir, et tout ceux qui ne s'y adaptent pas vont souffrir. Les exemples ne manque pas.
[^] # Re: Hacker news driven development
Posté par Media ex Machina (site web personnel, Mastodon) . En réponse au journal L'homme orchestre, partie 1 : les casquettes. Évalué à 1.
Dans "tous", je parle coté projet perso, ou de fait, tout ce qui n'est pas industriel, cadré, prévu.
Et mon but n'est pas de fournir du code qui servira de référence aux génération futures, mais juste un outil que j'espère pas trop mal pensé et qui peut rendre service.
[^] # Re: Méthodes de conception
Posté par Media ex Machina (site web personnel, Mastodon) . En réponse au journal L'homme orchestre, partie 1 : les casquettes. Évalué à 0.
Des nouveautés arrivent… Je repasserai ici monter tout cela.
[^] # Re: Pourquoi et comment
Posté par Media ex Machina (site web personnel, Mastodon) . En réponse au journal L'homme orchestre, partie 1 : les casquettes. Évalué à 2.
Point important à ne pas oublier : mon projet est en alpha, je ne prétends pas qu'il soit utilisable actuellement out-of-the-box et j'ai pas mal de doc à faire (c'est très long à écrire). Je ne souhaite pas pour le moment écrire des choses qui vont s'avérer obsolète assez vite.
Quand je dit que tout le monde se fiche de savoir comment c'est histoire de dire qu'en prenant la totalité des utilisateurs d'un logiciel libre, combien iront voire dans le code ? Et combien même comprennent quoi que se doit au code ?
Les questions que tu poses sont légitimes, j'en réponds à certaines, d'autres pas encore, et d'autres volontairement non pour éviter que l'on se méprenne sur ce projet et sur ce que l'on peut en faire actuellement.
[^] # Re: Méthodes de conception
Posté par Media ex Machina (site web personnel, Mastodon) . En réponse au journal L'homme orchestre, partie 1 : les casquettes. Évalué à 1.
C'est bien mon approche. MyDMAM est une plateforme qui est composée de pleins de petites API (et de leurs implémentations) pensées pour travailler ensemble mais aussi en certaine autonomie.
Mon but final, en fait, c'est ça : penser une structure fiable et bien pensée qui arrivera à supporter toutes les petites idées qui vont venir au fur et à mesure. Et ça, c'est fait, ça fonctionne. Il ne reste "plus" qu'a ajouter les petites idées.
Je doit en effet mélanger l'approche pas à pas / bidouille et l'approche papier/crayon/plan. "Tenter quelque chose" versus "voir loin et grand".
Et n'oublie pas que je suis pour le moment seul sur mon ouvrage et n'ayant aucune formation ni expérience dans les exemples industriels que tu a cité. Fort heureusement, ce n'est qu'un outil pour manipuler des médias, pas déplacer des humains !
[^] # Re: oui, mais c'est quoi un MAM ?
Posté par Media ex Machina (site web personnel, Mastodon) . En réponse au journal L'homme orchestre, partie 1 : les casquettes. Évalué à 2.
Oui, tout est bardé de normes et de convention, mais ça ne suffit pas pour changer les esprits et les pratiques au quotidien. Et chacun va a son rythme.
Quand toute une industrie se transforme en 10 ans, il y a de la casse. Sans compter que l'économie autour a beaucoup changé.
[^] # Re: oui, mais c'est quoi un MAM ?
Posté par Media ex Machina (site web personnel, Mastodon) . En réponse au journal L'homme orchestre, partie 1 : les casquettes. Évalué à 1.
Rien pour l'instant.
Et je m'interdit de faire un choix fermé.
[^] # Re: J'aime bien ton article
Posté par Media ex Machina (site web personnel, Mastodon) . En réponse au journal L'homme orchestre, partie 1 : les casquettes. Évalué à 1.
C'est déjà fait : http://hd3g.tv/b/2016/03/lhomme-orchestre-partie-1-les-casquettes/
[^] # Re: Les métiers du test
Posté par Media ex Machina (site web personnel, Mastodon) . En réponse au journal L'homme orchestre, partie 1 : les casquettes. Évalué à 1.
Mon terme de "Contrôle qualité" est peut être mal choisi ici.
Tu parle du vrai "Contrôle qualité", en tant que process industriel, et disons-le, lourd.
Je parle plutôt du compromis entre ce qui vient d'être implémenté et qui à l'air de marcher, et ce que l'utilisateur peut tolérer de dysfonctionnement. Et de fait, quand on est aussi bien dev. que user, ce compromis est très dur à obtenir.
La plupart des questions que tu soulève, j'y répondrai par du "surement… bof… j'espère…" car je n'ai pas la prétention d'arriver à ce niveau de qualité de travail, et encore moins seul.
Mais c'est bien sur un idéal que je me dirige vers.
[^] # Re: Didactique
Posté par Media ex Machina (site web personnel, Mastodon) . En réponse au journal L'homme orchestre, partie 1 : les casquettes. Évalué à 2.
Pour les femmes dans l'info, c'est juste culturel. Les femmes ont toujours existé dans ces métiers, c'est juste qu'elles sont très peu présentes et très peu visibles.
Avec la transformation des métiers et de leurs diversifications, la prochaine et nouvelle génération résoudra le problème de lui même car il y aura bcp plus de jobs aussi bien en quantité qu'en nature.
[^] # Re: oui, mais c'est quoi un MAM ?
Posté par Media ex Machina (site web personnel, Mastodon) . En réponse au journal L'homme orchestre, partie 1 : les casquettes. Évalué à 7.
En fait, il y a autant de définitions que d'implémentations.
Pour faire court, les "professionnels de l'audiovisuel" sont un peu bordélique. Ils aiment avoir pleins d'outils et des machins avec des fils, et ils adoraient avoir de belles bandes vidéos qu'ils mettaient dans leurs beaux magnétoscopes couteux et rutilants.
Ils confiaient les bandes à des archivistes pour les trier et les ranger, mais ça c'est chiant à faire, donc on y faisait pas vraiment gaffe.
Quand nos métiers ont lâché les bandes vidéo au profits de fichiers, ça été la panique. Ça c'est fait très vite et on c'est tous trouvé cons avec nos NAS pleins à craquer. Evidement, quand on a lachés les bandes, on a aussi largué les archivistes qui allaient avec. On a fait de super économies de m2 et de salaires.
Et donc depuis plusieurs années on rame pour ranger, traiter, retrouver nos fichiers. La demande à créer l'offre, et on c'est retrouvé avec pleins de marchants de boites noires tout-en-un-qui-fait-tour pour ça.
Ça m'a toujours gonflé de voir mes employeurs/confrères signer des gros, très gros cheques à ces gens là, qui n'ont même pas de honte à vendre des technos proprio très fermés et souvent bardé de brevets.
Quand dans le monde de l'IT pense de plus en plus "ouverture, interopérabilité, normes, bigdata…", le monde de l'audiovisuel pro n'en n'est qu'a la pré-histoire de tout ça.