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 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 !