Media ex Machina a écrit 47 commentaires

  • # Optional<T>

    Posté par  (site web personnel, Mastodon) . En réponse au journal La plus belle ligne de code. Évalué à 3. Dernière modification le 14 octobre 2023 à 11:53.

    Sinon, en java tu as la classe Optional, qui va gérer les cas des null, sans rajouter d’if…

  • [^] # Re: C'est bien

    Posté par  (site web personnel, Mastodon) . En réponse au journal Spring Boot vers RPM (un bricolage). Évalué à 3.

    J’ai hâte de lire ta future News.
    Et merci pour ton soutien.

    Oui j’ai bien gardé en tête la lisibilité maximale, car c’est vite fait en bash de s’embrouiller… même si j’ai un peu de rouge encore dans shellcheck.

    Après pour la portabilité, je vise bash et seulement lui. Ce code est sensé tourner sur une machine proche du dev, je m’autorise alors « quelques » dépendances !
    L’idée est aussi de pouvoir forker et modifier facilement mon code pour des besoins annexes, comme changer le fichier de service fourni par défaut : d’où l’importance que les choses soient les plus claires possible. Pas envie de me reprendre la tête dans 6 mois (quand je ferait le deb 😄), surtout au vu du temps qu’il m’a fallu pour écrire tout ça  !

  • [^] # Re: rpm-maven-plugin ?

    Posté par  (site web personnel, Mastodon) . En réponse au journal Spring Boot vers RPM (un bricolage). Évalué à 5.

    Déjà parce que c’est un peu galère le dev de plugins maven, surtout pour tester ça bien.
    Je sais qu’il existe deja des choses de ce côté, mais rien d’assez pratique pour mes besoins.

    Mon code produit une page man, un service systemd, adduser pour le service, une conf quasi prête pour le lancer juste après l’install. J’ai même prévu l’appel à liquibase pour mettre à jour la BDD si besoin.

    Ensuite parce que je bricole ce code/concept depuis longtemps, ce qui est récent ici, c’est le RPM produit.
    Et un jour le deb.

    Le dev d’installeurs, c’est ingrat.

  • [^] # Re: Je m’auto promo, c’est mal

    Posté par  (site web personnel, Mastodon) . En réponse au journal Vulgarisation scientifique en vidéo et en français. Évalué à 1.

    Merci pour ton soutien gUI !

    Si tu as des besoins, des questions ou des idées, n’hésite pas à me les remonter.

  • [^] # Re: Mes deux centimes

    Posté par  (site web personnel, Mastodon) . En réponse au journal Vulgarisation scientifique en vidéo et en français. Évalué à 2.

    Merci !
    Et n’hésite pas à me faire un retour.

  • # Je m’auto promo, c’est mal

    Posté par  (site web personnel, Mastodon) . En réponse au journal Vulgarisation scientifique en vidéo et en français. Évalué à 7.

    Ma contribution 😅 :

    Media ex Machina principalement de la vulgarisation technique sur les médias (image, son, transcodage, codecs…)

  • [^] # Re: Proxmox gratuit

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche Proxmox VE 6.2 est disponible. Évalué à 1.

    Tout est dans la documentation, voir la page « Package Repositories » sur le Wiki PVE.

    C'est l'info qu'il me fallait : ça semble résoudre le pb de l'update et du warning.
    Merci

    Tu utilises un produit dédier aux professionnels (mais qui est totalement libre et gratuit pour tout le monde) et tu te pleins qu’il soit dédier aux professionnels, si ça c’est pas de la mauvaise foi.

    Certaines boites ont tendance à faire du "OSS washing" en prétendant faire du libre (et gratuit) mais en ayant une politique qui te force à payer un service ou une licence.
    Après la notion de "professionnel" ne joue que sur le support et une forme de garantie de service.

    Plot twist : les quelques fois ou j'ai croisé Proxmox, c'était dans un cadre associatif (et gratuit).

  • # Proxmox gratuit

    Posté par  (site web personnel, Mastodon) . En réponse à la dépêche Proxmox VE 6.2 est disponible. Évalué à -3. Dernière modification le 14 mai 2020 à 16:13.

    Il m'avait semblé qu'il était dispo gratuitement, modulo le support bien sur.

    J'ai fait très récemment un essai, et entre le popup qui me balance (trop) régulièrement un message du genre "vous n'avez pas de licence !", la déconnexion auto de session trop rapide qui tombe n'importe quand, et la mise à jour auto qui te balance en erreur qu'il n'arrive pas a se connecter à un dépôt qui semble t'il demande une licence, j'ai bien pensé avoir à faire à un shareware proprio.

    Je suis surement stupidement passé à coté de quelque chose, mais à ce prix et en tant que particulier/non-pro, c'est vraiment trop cher pour avoir la paix. A moins qu'il existe une version community quelque part !

    Désolé d'avoir pousser une gueulante ici, ce n'est surement pas le bon endroit :/

  • [^] # Re: choix d'architecture logiciel

    Posté par  (site web personnel, Mastodon) . En réponse au journal Évolution et maturation de MyDMAM. Évalué à 1.

    Oui, et le cache disque, c'est bien, mais ça a ses limites. Quand on pelte des Go de fichiers, vient vite le moment ou c'est depuis les disques que viennent les données. L'idée du cksum ici est surtout une façon absolue de dire que la copie est intégrale plus de dire que le fichier source n'est pas altéré. Si un cksum n'a pas été calculé au moment d'écrire la première fois, on ne peut plus savoir (enfin être certain) que le fichier est toujours intègre au moment de son archivage.

  • [^] # Re: choix d'architecture logiciel

    Posté par  (site web personnel, Mastodon) . En réponse au journal Évolution et maturation de MyDMAM. Évalué à 3.

    Pourquoi est-ce piégeux ?

  • [^] # Re: choix d'architecture logiciel

    Posté par  (site web personnel, Mastodon) . En réponse au journal Évolution et maturation de MyDMAM. Évalué à 3.

    En fait, pour mieux comprendre le pourquoi, il faut comprendre le besoin :
    T'a des To de fichiers (qq Mo à 100 Go) étalés dans des stockages hétérogènes, dans des stations de travail spécialisées, dans des vieux stockages, dans des SAN/NAS à protocoles et clients proprios.
    Tu doit bricoler des montages de montages, rebondir de machines en machines. Via des vieux linux, des vieux macs.
    Et le but c'est de tout réunir pour l'envoyer dans un stockage "sur" qui est parfois le sas d'entrée vers un système d'archive vers LTO.

    Et la copie est lancée, t'a 150000 fichiers, la copie va prendre une 30aine d'heures. Tu voudrait enlever certains types de fichiers, et donc tu voudrait faire un tri préalable avant de tout lancer. Et parfois la copie rate en cours. Un montage saute. Les perfs s'effondrent. Pire, un file system saute et bloque net le transfert. Obligé de reboot.
    Et tu ne veux pas tout recommencer, le scan, le tri, les copies, etc…
    Le calcul du débit moyen et instantané pour détecter les pb avec le FS, c'est redoutable quand il que dit que tu fait du 2 MB/sec en moyenne et du 100 MB/sec en instantané.

    ExtendCopy est fait pour cela. Surtout pour cela.

    Ensuite, ce n'est peut-être pas clair, mais il calcul un MD5 (ou autre) pendant la copie, le note, et il y a une fonction qui fait un replay sur les fichiers copiés et qui vérifie les mesures.
    Le fichier produit en sorti (un txt tabulé) est la preuve de ce qui a été copié, et que c'est bien copié. Quand on parle client/fournisseur/prestation/assurance/facturation, c'est important.

    J'ai fait ce dev car… j'ai rien trouvé pour faire cela facilement. Les scripts bash, c'est bien quand t'est chez toi a ton bureau, c'est chaud quand t'est en clientèle, dans leur nodal, à 4 pattes par terre devant le seul écran trouvé, le nez sur un XSAN bardé de bad-blocs.

  • [^] # Re: choix d'architecture logiciel

    Posté par  (site web personnel, Mastodon) . En réponse au journal Évolution et maturation de MyDMAM. Évalué à 2.

    Pourquoi un problème avec Java ? Les perfs ne sont pas ridicules du tout ! et c'est parfois plus simple à déployer quand on doit jouer avec des OS un peu anciens ou exotiques.

    Pour les dates et les droits, c'est une volonté.

    En archivage de média, la date d'archivage (ici de copie) est importante car elle marque le début du stockage sur un nouveau support d'archives des éléments de travail. Ensuite, ça arrive d'avoir des gros systèmes qui ne sont pas du tout à l'heure (ou qui ne la gère pas) et de se retrouver avec une date qui ne correspond à rien.

    Pour les droits, ça n'a pas beaucoup d’intérêt en archivage car c'est très rare que cela serve, sans compter les potentiels problèmes avec des montages de FS réseau qui gèrent ça très mal (ou qui mentent, c'est pareil).

    Pour les histoires de dates et de droits, rsync fait ça très bien ! Et il y a toujours moyen de modifier ExtendCopy pour le prendre en charge.

  • [^] # Re: choix d'architecture logiciel

    Posté par  (site web personnel, Mastodon) . En réponse au journal Évolution et maturation de MyDMAM. Évalué à 1.

    Wow ! ExtendCopy, ça marche toujours ?! C'est super vieux dev ! Il mériterai peut-être rafraîchissement avec NIO2.

    Et… ça va ? Pas de problèmes ou de manques en particulier ?

    Oui, le LL arrive là où le proprio atteins ses limites (notamment en terme de tarifs). Le monde des médias évolue énormément, et des gens comme Netflix font leurs petites révolutions, y compris dans le LL.

  • [^] # Re: choix d'architecture logiciel

    Posté par  (site web personnel, Mastodon) . En réponse au journal Évolution et maturation de MyDMAM. Évalué à 1.

    Je n'ai pas encore de documentation écrite "pointue". Je pense que cela va venir au fur et a mesure.

    Pour les choix de ES et de Cassandra, se sont le résultat de grosses réflexions car le besoin est très varié. j'aimerai me passer de l'un ou de l'autre, voir des deux, mais ce n'est pas encore possible.

    J'ai notamment besoin :

    • De tenir la charge en terme de quantité d'éléments sans pénaliser la vitesse
    • De TTL dans les enregistrements
    • De faire des locks centralisées en DB
    • De gérer des files d'attente de taches en DB
    • D'un moteur de recherche rapide et souple
    • D'une installation la plus simplifiée au possible (donc éviter d'avoir plus de 2 moteurs de DB différents et d'avoir un process d'init de base le plus simple possible)
    • De multiplateforme aussi bien pour l'applicatif que pour les bases. Et ça doit tourner sur des OS qui ont 5 ans.
    • De pérennité, d'assurance comme quoi cela a déjà fait ces preuves.

    Et tout cela depuis 2011, au moment ou j'ai commencer les travaux sur MyDMAM.

    Pleins de technos peuvent répondre à ces besoins. Mais il n'y en a que peut qui sont facilement accessibles de 0, libres, sans avoir une courbe d’apprentissage très raide.

  • [^] # Re: Et les logs ? Dockers ?

    Posté par  (site web personnel, Mastodon) . En réponse au journal Évolution et maturation de MyDMAM. Évalué à 1.

    Non, car je préfère garder un fonctionnement hors Docker. Il n'est pas disponible partout, demande des prérequis d'admin que tout le monde n'a pas, je ne connais pas son comportement sur des FS exotiques et lors de gros IO et enfin je manque de visibilité sur du long terme. En tout cas c'est mon avis. Si quelqu'un propose une config Docker et un how-to, je l’intégrerai !

  • [^] # Re: Et les logs ? Dockers ?

    Posté par  (site web personnel, Mastodon) . En réponse au journal Évolution et maturation de MyDMAM. Évalué à 2.

    Merci Mimoza !

    Oui, je ne l'ai pas mentionné ici, mais j'ai basculé sur log4j. Mon ancien système de log m'a beaucoup appris, mais log4j est aussi puissant que simple et pratique. La marche a passer est un peu haute au début, et après cela va tout seul.

    Le déploiement n'est pas vraiment "automatique". C'est un script ant qui mache le travail, et un script bash (un pour linux, un pour macOS) pour la pose de chemins absolus dans les déclarations de services (de fait, ils sont produits pas le bash).

    Pour windows, j'utilise WinRun4J (64). Il n'y a même pas besoin de scripts pour lui.

    Docker… je suis pas trop fan car je n'ai pas encore touché ses avantages par rapport aux inconvénients. Notamment par le fait que ça fait un truc de plus à gérer et tester car je suis obligé de garder un déploiement traditionnel. Et je n'aime pas les modes. Techniquement, il n'y a aucune contre-indication à Docker.

  • [^] # Re: des pistes

    Posté par  (site web personnel, Mastodon) . En réponse au message Publication d'une application libre : comment faire avec des bibliothèques et des dépendances ?. Évalué à 1.

    Ma question n'est pas tant technique que légale. Puis-je redistribuer comme ça des binaires libres ?! Et sous quelles conditions ?

  • [^] # Re: JAXB

    Posté par  (site web personnel, Mastodon) . En réponse au journal Mes dernières publications libres. Évalué à 1.

    Je n'utilise pas Maven. Mais j'imagine en effet la puissance de la chose.

    Après certains imports ont mal fonctionné, comme ffprobe.xsl qui bug par défaut (j'imagine que ça doit être plus chaud à scripter), et je montre ici plus une demo/exemple fonctionnelle qu'une vraie implémentation.

    Alors les différences fonctionnelles entre JAXWS et JAXB, j'avoue, je n'ai pas poussé la science aussi loin ! Peut importe qui fait quoi, du moment que cela marche. Je n'ai surtout pas la prétention de faire un cours sur cela ici.

    Pour Vantage, quel interet d'utiliser l'API REST quand on a le SOAP ? Je veux dire, d'un coté j'ai toute une structure Java déjà faite et fonctionnelle (avec SOAP/JAXWS donc), et de l'autre, je doit la fabriquer moi même en regardant la doc, vu que j'imagine qu'il n'est pas capable de produire les classes tout seul ?

    Par contre, j'ai d'autres systèmes à piloter qui sont eux, en REST & Json seul. Peut-être que l'une de tes 3 propositions vont m'y aider !

  • [^] # Re: Show me the code

    Posté par  (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  (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  (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  (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.

    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 !

  • [^] # Re: Show me the code

    Posté par  (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  (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  (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.