Journal Présentation de mon projet perso de DMAM libre : MyDMAM

32
27
oct.
2015

Bonjour à tous et à toutes !

Mon premier journal pour vous parler de mon projet libre que j'écris en solo depuis bientôt trois ans. J'ai toujours attendu d'avoir "quelque chose à montrer" pour le présenter, et je pense qu'il est maintenant temps de l'exposer.

MyDMAM est une tentative, encore expérimentale, d'avoir un DMAM libre qui laisse le plus de liberté de fonctions, de possibilités d'installations, de bidouilles que la grande majorité des outils actuels dit "pro". J'ai évité le parti pris de choisir un métier/environnement professionnel pour proposer quelque chose de polyvalent.

MyDMAM est écrit en Java, repose sur Cassandra, Elasticsearch, Play Framework v1, React, et utilise ffmpeg et ImageMagick pour ses besoins actuels.
Le code est structuré comme un ensemble d'éléments qui peuvent avoir une certaine indépendance entre eux, en tout cas j'ai écrit le code avec cette idée en tête. Par exemple, il y pas mal d'accès statiques pour les bases de données et la configuration, et il n'y a pas d'objet global bien gras que s'échange tout le code. Bref j'ai essayé de faire mon mieux.

Ce projet est sans grande ambition. Je ne compte pas en faire un commerce, ni même une promotion vers le public qui peut en avoir besoin. Pour le moment, je le présente, c'est déjà ça. Il s'agit surtout un passe temps pour moi qui avance gentiment, avec une roadmap très chargée. Mais je ne me donne pas de but de publication régulière. Je préfère me concentrer sur mon code.

Pour l'outil lui même, il répond d'abord à mes propres besoins, pro pour certains, et perso pour d'autres. Toutes les fonctionnalités techniques qui sont présentes, plus celles que je compte mettre sont le résultat d'une réflexion de plusieurs années, plus de 10 ans pour certaines, et j'ai vraiment cherché un compromis entre l'usine à gaz tout en un et le script qui dépanne. C'est un vrai challenge car toute approche de traitement/gestion média de ce type peut se résumer à coups de crons et de scripts bash et se retrouver avec un bricolage dont on ne comprends plus rien, ou alors en signant des dizaines de k€ pour une boite noire qui contient plus de restrictions que de fonctions, elles même plus vraiment en phase avec le besoin initial après quelques années.
Bref, c'est une tentative de faire mieux, en 40k lignes de Java et 8k de JS. En constante augmentation bien sur.

Pour ma part, j'ai presque 31 ans, je vis sur Paris et je suis responsable technique dans la partie médias/archives/post-production/antenne d'une petite chaine de TV française. C'est, entre autre, mon boulot de gérer, comprendre et proposer des outils comme MyDMAM.

Bref, si vous voulez donner un coup de main, le plus simple : faites le tourner (dans VM par exemple). Si vous n’y arrivez pas, ou s'il y a quelque chose de pas clair et que vous me le remontiez, ça sera pour moi une belle occasion d'améliorer mon ouvrage. Et si vous voulez proposer des patchs, de la doc, de la trad, ou autre, pourquoi pas !

Pour en savoir plus :
- le message de présentation sur mon blog
- le site du projet que j'ai créé (dans un anglais de qualité variable et en français) avec quelques explications sur ce que ça fait (actuellement), et une FAQ.
- la page github, avec toutes les issues ouvertes

Et toutes les questions sont bien évidement les bienvenues.

Merci !

  • # DAM, DMAM

    Posté par . Évalué à 5.

    Dommage que tu te limite au «media», ta plate forme me semble assez robuste pour faire un DAM générique.

    D’ailleurs tu aurais pu dire ce que signifie l’abréviation (Digital Media Asset Management), il faut lire quelques ligne du lien vers Wikipedia pour comprendre, on trouve MAM mais pas DMAM.

    Pour avoir fait quelque chose du genre mais bien moins complexe (pas d'Elastic Search ni Cassendra) ton système semble plutôt bien foutu.

    À la question «Pourquoi avoir réinventé un nouveau système de log, Log2 ?» je trouve ta réponse pas recevable. Un SLF4J est quand même très standard et pas des plus lourd. Idem pour «J’ai préféré développer un système de gestion de tâche parce que je ne voulais pas rajouter un serveur de plus dans les dépendances, […]». Tu as déjà un ES et Cassandra ! Ajouter un ActiveMQ ou faire plus simplement du SpringBatch ne t'aurait pris moins de temps.

    Bref tu as réinventé la roue pour des trucs pas forcément indispensable … mais le taff accompli a coté est assez conséquent je dois le reconnaître.

    PS : Pour la détection de contenue je me suis tourné vers Apache Tika qui foisonne de possibilités.

    • [^] # Re: DAM, DMAM

      Posté par (page perso) . Évalué à 6.

      Merci pour ton retour.

      Alors:

      • ma spécialité, c'est les médias. C'est là ou je suis le plus à l'aise pour proposer un outil adapté. C'est surtout que ma roadmap est orientée média (audio, vidéo, cinéma, radio, photo). Je n'ai pas prévu par exemple de traiter du texte. Mais pourquoi pas, oui. Qui peut le plus, peut le moins.

      • en fait, je me suis dit que balancer "Digital Media Asset Management" n'allait pas beaucoup aider. Il aurai fallu faire une explication de ce que c'est. Et comme c'est un terme tellement générique j'ai préféré me dire celui qui n'a jamais entendu ce terme ne sera pas spécialement interessé par ce projet. Un peu comme le terme "SEO" pour ceux qui dev. sur de l'embarqué.

      • c'est surtout grace à ES et a Cassandra. C'est vraiment de bonnes technos, surtout pour moi qui n'aime pas m'engager dans des schémas et des requettes SQL. Pour la robustesse, c'est une obligation ici. Il existe tellement d'outils "moyens" sur ce point que je me devais de faire quelque chose qui tienne, vraiment. Par exemple, combien de systèmes partent en vrille quand il y a des time-out sur des mount ? En utilisant mount le moins possible je suis capable de mieux catcher le time-out proprement quand j'ai besoin d'une ressource distante.

      • Je suis en train de retirer Log2 de mon code. Cette petite aventure m'aura permis d'apprendre plein de choses, car je ne suis pas dev. de métier, mais l'herbe est vraiment plus verte du coté de log4j !

      • Pour la gestion de taches (Broker/Worker/Job), il existe plein d'outils. Bien complexes. Mon besoin est au final assez limité, et ça devait être un système distribué. Mon driver Cassandra, Astyanax propose quelque chose qui m'a permis de l'écrire et de garder un code bien intégré. Au final, ici la gestion de tache, c'est "que" quelques classes Java.
        Et enfin, je ne connait pas SpringBatch.

      • Oui, j'ai réinventé la roue. Tout ce que fait MyDMAM peut être un tas de scripts dans un tas de langage avec un tas de gros machins autour. Il existe tellement de chose aujourd'hui. J'ai pas mal expérimenté des trucs à coup de PHP, de Delphi, de Tomcat… A chaque fois c'est pareil, ça fait boom quand on se dit "mais comment je vais faire ça sans tout casser". Après MyDMAM ne fait rien de très incroyable. C'est surtout "un tout en un" qui donne l'accès à pas mal d'outils en quelques lignes de Java.

      • Oui le taff est conséquent, loin d'être terminé, mais ce que je suis fier, c'est que ça marche bien, je le fait bien évoluer comme je veux, et je me perds pas dans mon code, même si parfois je me fait du mal.

      • Apache Tika, oui j'ai vu passer. Il faudrait que j'y mette les pieds un jour. Pour tout ce qui est extraction, je pense avoir ce qu'il me faut pour le moment (tout n'est pas implémenté bien sur).

      • [^] # Re: DAM, DMAM

        Posté par . Évalué à 5. Dernière modification le 27/10/15 à 22:09.

        l'herbe est vraiment plus verte du coté de log4j

        NON !!! log4j a été le standard durant pas mal d'année mais SLF4J/Logback est vraiment mieux de ce coté.
        SLF4J est une abstaction de système de logging, tu peut mettre l'implémentation que tu souhaite en dessous (commonsLogging, Log4J, …). LogBack est l'implémentation par défaut qui vaut largement Log4J avec quelques finesse en plus.

        Sinon regarde ce que fait lombok, une fois mis en place tu ne peut plus t'en passer :-)

        Raaaaa j'ai vraiment pas le temps en ce moment mais j'aurais bien fait un tour dans ton code pour voir tout cela en détail

        • [^] # Re: DAM, DMAM

          Posté par (page perso) . Évalué à 4.

          Pour log4j, Play, Cassandra et ES l'utilisent. Alors moi bêtement, j'ai pris ce qui me semblait le mieux ! Surtout que j'ai pu trouver toute la doc (et les tutos, surtout les tutos) que j'avais besoin. Et parce que je préfère passer du temps sur ffmpeg ou Cassandra qu'avec… mon système de log. Bref, ça me convient pour le moment !
          Et je comprends bien ta remarque.

          Lombok, je connaissait pas cette sorcellerie. Entre ce que fait Play (le Rails de Java) et Gson, j'ai déjà pas mal de tours de magie dans mon classpath ! D'ailleurs, React et Gson, quelle claque !

          Au passage, je me suis fabriqué :

          • une prise en charge transparente de React à travers les controleurs de Play, avec (de) sérialisation automatique des messages Json entre les objets Java et JS. Tous les éléments React sont compilés en JS par Play, via Moz. Rhino, et si besoin YUI compiled pour avoir un gros blob qui se cache bien "en prod". Tout ça de façon transparente.
          • j'ai fait fonctionner le système de modules de Play avec React ; et en dehors de Play.
          • un ORM très simple avec Cassandra (un Object = une ColumnFamily)
          • une passerelle pour faire tourner ffmpeg ET récupérer la progression du traitement et l'afficher dans le site coté utilisateur.
          • un parseur/analyser pour le retour de ffprobe en Json (par exemple, pour une vidéo, je peut te dire si c'est du PAL, NTSC, Cinema 48p, 4K), et idem pour ImageMagick Identify.
          • je sais transformer une image transparente en un jpg où la transparence est remplacée par un beau damier gris.
          • une API très simple de configuration en Yaml, avec prise en charge des modules de Play hors Play.
          • un Service Java, avec prise en charge de la fermeture propre de l'instance, et remontée régulière de l'état de l'instance dans Cassandra (Thread list, uptime, version Git…).
          • j'ai adapté le multilingue de Play dans React (facile)
          • j'ai adapté un système de http partial download pour Play afin de pouvoir se balader dans une vidéo dans le site
          • j'ai adapté une gestion de white/black list d'IP et une protection de brute force login
          • j'ai fabriqué un navigateur de fichier avec ElasticSearch et React avec une recherche intégré dans la liste des fichiers, plus une recherche libre sur tous les dossiers indexés

          Ça n'empêche que je me suis plusieurs fois planté aussi, et j'ai déjà, a plusieurs reprises jeté quelques mois de travail quand j'ai fini par constater que ça n'allait pas. Je ne supporte pas le "defective by design". Certaines portions de code on été ré-écrites plusieurs fois (4x pour certaines).

          Raaaaa j'ai vraiment pas le temps en ce moment mais j'aurais bien fait un tour dans ton code pour voir tout cela en détail

          Tu sais, le code est là depuis deux ans, et il ne peut que s'améliorer ! Il n'y a pas d'urgence… Et sinon, prends plutôt la branche la plus fraiche, dvl.

          • [^] # Re: DAM, DMAM

            Posté par . Évalué à 4.

            Ha oui tu n'as pas chômé ! Si en plus tu arrive a lier Play! & ReactJS c'est un gros boulot, chapeau !

            C'est presque dommage de ne pas exploiter ta plate forme commercialement. Mais bon c'est vrai que c'est aussi un gros boulot.

            • [^] # Re: DAM, DMAM

              Posté par (page perso) . Évalué à 3.

              Ce qui est chouette avec le lien React, c'est qu'il est transparent pour le dev et pour l'admin. Si les fichiers sont aux bons endroits, ça marche sans rien faire d'autre. L'objectif, c'est d'avoir une interface 100% React 100% REST (donc qui puisse servir aussi d'API) et 0% Groovy pour me permettre de passer à Play 2.

              Pour la commercialisation, il faut déjà que ça ressemble à quelque chose de complet, et que ça propose quelque chose de différent que l'on ne trouve pas ailleurs. MyDMAM est fonctionnel mais encore expérimental. En terme de nouvelles fonctions, la progression est lente. Je suis toujours en alpha, et la beta n'est pas pour tout de suite.

              Enfin, vendre est un métier et demande une énergie que je ne dispose pas pour le moment. Je le sais d'autant plus que je ne suis pas tendre avec mes fournisseurs !

  • # Kudos

    Posté par (page perso) . Évalué à 1.

    Très impressionnant, bravo. Ça ressemble très fort à un projet dont je m'occupe exclusivement la nuit, pendant mon sommeil (ce qui me pose de gros PBs de timesheet) et mes félicitations s'étendent à ce journal concis et jubilatoire, qui ressemble lui-même à une pop-song bien balancée.

    Personnellement, dépêche direct.

    • [^] # Re: Kudos

      Posté par (page perso) . Évalué à 4.

      Dépêche, pas trop vite non plus. Là je suis en train de finir une nouvelle fonctionnalité, qui elle sera jubilatoire : un système de transcodage par watchfolders distribué (#115). Cette nouveauté méritera, je pense, une dépêche. Simplement parce que ce nouveau truc est un fantasme qui a plus de 10 ans.

      Pourquoi ? Parce que ça permet :

      • d'avoir plusieurs instances qui surveillent en même temps les mêmes dossiers. Donc tolérance aux pannes si une instance tombe.
      • d'avoir plusieurs traitements pour chaque fichier déposé qui peuvent être exécutés par des instances différentes.
      • un traitement, c'est une commande exécutée quelconque, du moment où elle sort un seul fichier (dont le nom est donné à l'avance par MyDMAM). Si c'est ffmpeg vous aurez droit à avoir une barre de progression qui s'affiche sur le site, tant qu'à faire. Une API existe pour faire soit même la progression d'un exécutable quelconque, ici j'ai juste implémenté ffmpeg.
      • on peut gérer pour chaque instance le nombre et le type de slots de conversion, suivant ce que vous voulez/pouvez faire sur chaque serveur. Ça permet d'avoir plein de slots qui ne font que les petits traitements et quelques slots qui ne font que les gros, afin que les gros traitements ne bloquent pas les petits.
      • en bonus : vous pouvez demander à ce que l'arborescence des fichiers déposés soit respecté en sortie. C'est parfois plus simple de ranger avant les traitements qu'après !

      Ça ressemble très fort à un projet dont je m'occupe exclusivement la nuit, pendant mon sommeil

      Je tente parfois de coder dans mon sommeil, mais je n'arrive pas à push… Il suffit de pas grand-chose parfois.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.