El Titi a écrit 3952 commentaires

c'est ton credo … Non ?

TCE, democratie représentative, …

Il reste Java Webstart… Quelqu'un s'en sert ?

Oui.
Ils essaient de nous refiler ça dans ma boîte.
http://www.xqual.fr/
Outre que c'est moche, que ça ressemble à un clickodrome des années 80, ça se lance en Webstart.
T'imagines un peu ?

Au hasard:

WindwOS

Pour les détails de l'architecture et tous les détails techniques, ça viendra. Ce n'est pas ma priorité,

Ceci entre en contradiction avec cela:

Mais pas forcément quand vous devez construire une grosse application. Vous devez avoir un coup d’avance sur ce que vous allez peut-être avoir besoin, et le prévoir en amont.

L'architecture ça se résume à ca: Réfléchir … un peu… avant de te lancer. Les mauvais choix d'aujourd'hui sont le temps perdu de demain. La fameuse dette technique que tu évoques.

Je vais à nouveau essayer de t'illustrer en quoi il est utile d'apprendre contrairement à que tu as écrit en gros:

Pas de temps à perdre à apprendre

Prenons déjà le framework Play.
Tu écris:

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.

Play était-il le bon choix pour ton besoin ? Il semble que non. A présent que devras tu casser pour réécrire les fonctionnalités équivalentes ?
Déjà certains de tes contrôleurs embarquent de la logique de persistance. Play par simplicité encourage à embarquer toute ta logique de persistance en même temps que ta logique métier (le comme ici :

    public static CrudOrmEngine<UserProfile> getORMEngine(String key) throws Exception {
        UserProfile userprofile = new UserProfile();
        CrudOrmEngine<UserProfile> engine = new CrudOrmEngine<UserProfile>(userprofile);
        if (engine.exists(key)) {
            userprofile = engine.read(key);
        } else {
            userprofile = engine.create();
            userprofile.key = key;
            engine.saveInternalElement();
        }
        return engine;
    }

N'eut t'il pas été préférable de les séparer ces 2 aspects (par exemple en utilisant des DAOs) et de les isoler dans 2 couches sans tout disséminer y compris dans les contrôleurs. Car à présent le passage vers un autre framework va t'obliger a tout réécrire ou à créer une couche d'abstraction pour rediriger tous tes appels aux méthodes CRUD de Play. Comment cela se passera t'il si finalement Cassandra ne fait plus l'affaire et que tu veuilles partir sur du Mongo ? Comment t'assureras tu que tu fonctionnes correctement alors que tu n'as aucun test ?
Imagine que le départ tu aies conçu ton architecture avec juste des classes métiers (celles qui traiteraient de Médias, de répertoires et de métadata pas d'ACLs) de simples POJO et que tu aies séparé la persistence.
Le travail ne serait-il pas plus simple. Au départ tu te concentres que sur ça et comme tu ne peux pas tester ton appli dans son ensemble que tu n'as pas de GUI ou de CLI, tu écris quelques tests pour valider tes "itérations" comme tu les appelles. Bienvenu dans le monde du TDD.
De plus de ce que je vois de Play, il s'agit d'un framework basé sur l'héritage ("extends Model"). Il t'oblige à surcharger ou à utiliser ses méthodes par héritage. Tu es donc fortement couplé à lui et il me parait intrusif.
Pour des problématiques techniques transverses tel que la persistence (ou même le logging que tu réécrit from scratch) il existe la programmation par aspect qui vient en complément et un framework comme Spring MVC me parait plus adapté.

Toujours pas convaincu du fait que l'architecture (qui inclue la testabilité) et la conception se concoivent au fil de l'eau et pas après ?

Prenons cette fois-ci cette classe MetadataCenter que tu m'a explicitée.

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.

Lorsque je vois des switchs partout ou des bouts de code de ce genre:
```java
try {
addProvider(new ImageMagickAnalyser());

        addProvider(new FFprobeAnalyser());
        addProvider(new FFmpegInterlacingDetection());
        addProvider(new FFmpegSnapshot());
        addProvider(new FFmpegAlbumartwork());

        addProvider(new ImageMagickThumbnailer(FullDisplay.class, PreviewType.full_size_thumbnail, FullDisplay.profile_name));
        addProvider(new ImageMagickThumbnailer(Cartridge.class, PreviewType.cartridge_thumbnail, Cartridge.profile_name));
        addProvider(new ImageMagickThumbnailer(Icon.class, PreviewType.icon_thumbnail, Icon.profile_name));
        addProvider(new ImageMagickFFmpegThumbnailer(FullDisplay.class, PreviewType.full_size_thumbnail, FullDisplay.profile_name));
        addProvider(new ImageMagickFFmpegThumbnailer(Cartridge.class, PreviewType.cartridge_thumbnail, Cartridge.profile_name));
        addProvider(new ImageMagickFFmpegThumbnailer(Icon.class, PreviewType.icon_thumbnail, Icon.profile_name));

        addProvider(new FFmpegLowresRenderer(JobContextFFmpegLowresRendererLQ.class, PreviewType.video_lq_pvw, false));
        addProvider(new FFmpegLowresRenderer(JobContextFFmpegLowresRendererSD.class, PreviewType.video_sd_pvw, false));
        addProvider(new FFmpegLowresRenderer(JobContextFFmpegLowresRendererHD.class, PreviewType.video_hd_pvw, false));
        addProvider(new FFmpegLowresRenderer(JobContextFFmpegLowresRendererAudio.class, PreviewType.audio_pvw, true));
    } catch (Exception e) {
        Loggers.Metadata.error("Can't instanciate Providers", e);
    }
}

Ca m'évoque ce qu'on  appelle un "code smell" et j'ai envie de sortir tout ça pour en faire quelque chose de plus souple qui évitera de modifier mon code à chaque fois que je veux rajouter un provider  et faire en sorte que cette classe ne "change" pas au cours du temps comme ici:
https://github.com/hdsdi3g/MyDMAM/commit/bb024c2f1aa8f7f994be38ea740c7bf7feae3534#diff-dbab17a2baa241511ef42fd413ac083c
J'imagine que tout ces providers sont appellés par un comportement quelquepart, peut-être déjà regroupés dans un interface ou alors peut-être que tu es obligé de modifier ton code à plein d'endroits.
Je soupçonne que ceci se prêterait bien à une Factory: http://www.jmdoudoux.fr/java/dej/chap-design-patterns.htm

Revoici encore l'intérêt principal du paradigme objet. En réunissant code et données au même endroit, en usant du polymorphisme, tu n'as besoin de le changer qu'à un endroit.

Apprendre la technique est très bien mais la théorie aussi a du bon.

Ne prends pas ombrage de ses remarques. Toi même tu demandes un feedback. Je souscris à pas mal de ses remarques sauf une:
celle qui semble insinuer qu'un autodidacte ne saurait fournir du code de qualité. Et je ne vais pas m'embarquer dans ce débat.

Tu appelle à un retour, tu sembles attaché à la qualité de la documentation. Je te cite:

Pas de tutoriel ? Pas d’exemple ? Next !

Bien nommer
Si vous ne savez pas noter une variable, une classe, une fonction, c’est qu’elle n’a pas a exister de la façon d’où vous la pensez.

Pourtant lorsqu'on t'objecte certains point tu sembles mal le prendre. Je suis d'accord que la forme importe mais il me semble que ton contradicteur est resté courtois.

Je me suis aussi un peu penché sur ton code et je m'exprime peut-être à tort, je ne connais pas le framework Play donc je peux raconter des bêtises.
Tu appelles aux contributions et pourtant tu ne documentes pas ton architecture, tes conventions de codage… Tu ne laisses rien qui puisse permettre de l'appréhender. Qu'à cela ne tienne, en lisant ton journal, on pourrait se dire que l'on a affaire à un adepte du "Clean code" (Je t'invite vraiment à lire http://www.amazon.fr/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882) et que la lumière se fera au travers lui. Comme évoqué par quelqu'un plus haut, un des avantages à disposer de tests est que ceux-ci représentent un forme de spécifications et aident à mieux comprendre le code de production (le Sytem under Test). Tu n'en disposes pas. Soit …

Mon habitude, personnellement dans ce genre de cas, pour comprendre de quoi ça parle, c'est de découvrir le domaine: les classes métiers.
Si j'en juge par la description de Play! On a bien affaire un framework MVC (https://www.playframework.com/documentation/1.4.x/main#mvc). A priori, tu l'as adopté entre autre parce qu'il est bien documenté.
Lorsque je me penche sur tes modèles voici ce que j'y découvre:
https://github.com/hdsdi3g/MyDMAM/tree/master/app/models
Des profils utilisateur, des ACLs.
Que fait ton appli ? Je me renseigne donc sur ce qu'est un DMAM …
Je m'attendais à trouver des entités "Média", "Utilisateurs" et bien d'autres … et il faut fouiller dans ce fourre-tout que tu as nommé "hd3gtv" pour trouver un semblant de classe métier comme ce qui aurait pu s'appeler "MetaData": https://github.com/hdsdi3g/MyDMAM/blob/master/app/hd3gtv/mydmam/metadata/MetadataCenter.java

Si on se penche sur un de tes rares modèles https://github.com/hdsdi3g/MyDMAM/blob/master/app/models/UserProfile.java
J'ai l'impression qu'on se trouve devant un problème d'affectation des responsabilités.
Par exemple, que vient faire une méthode comme celle-ci là au milieu ?

private static String cleanFileName(String value)
A t'elle un sens métier ?
Si elle n'est utile que pour d'autre méthodes de la classe pourquoi n'est elle pas privée ?
Si tu la rends publique, c'est donc que tu considères que c'est la responsabilité d'autres classes de formater correctement l'email d'un profil utilisateur ?
Sinon pourquoi ne pas l'isoler dans une classe utilitaire si tu considère qu'elle pourrait être réutilisable ?

Je n'évoquerai pas ces contrôleurs à qui (me semble t'il) tu confies la tâche de persister certaines de tes données.

Je ne te parlerai même pas d'injection des dépendances dont je ne trouve pas trace et qui hormis la testabilité t'apporte une vraie liberté pour "refactorer" ton code, comme tu l'évoques si bien en te permettant de changer d'implémentation de manière très souple.

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).
J'ai l'impression que tu n'as pas saisi certains des concepts fondamentaux du paradigme de programmation orientée objet.
Je t'encourage à approfondir ces concepts et le plus important d'entre eux l'encapsulation qui veut que les données et les traitement et les données sont regroupées et qui confère un avantage sur le procédural. Avant de partir sur les design patterns du Gof comme tu l'évoquais, tu devrais peut-être faire un petit détour par les patterns de responsabilité, les fameux GRASP: https://en.wikipedia.org/wiki/GRASP_(object-oriented_design)

Et pour finir je te reparlerai de ce "modèle de domaine anémique" qu'on rencontre parfois et que j'ai déjà évoqué plus haut.
En général, on le reconnait à des entités qui ne disposent d'aucune logique métier et ne sont que des passe plat à base getter et setter.
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). Mais tu n'es pas obligé de me croire.
C'est pourquoi je t'invite une nouvelle fois à te pencher sur la documentation du framework que tu as adopté.
Il y est fait une mention explicite au lien sur Martin Fowler que je t'ai pointé plus haut:
https://www.playframework.com/documentation/1.2/model

A common Java anti-pattern is to keep the model as a set of simple Java Beans and put the application logic back into a “service” layer which operates on the model objects.

Martin fowler again has named this anti-pattern Anemic object model

Si j'ai pris la peine de rédiger cette longue bafouille ce n'est pas pour te faire la leçon mais au contraire pour t'encourager à poursuivre ton cheminement dans une direction peut-être trop consensuelle pour toi mais qui permettrait vraiment d'ouvrir ton code aux contributions autrement que par la licence. Tu as déjà fait une belle partie du chemin seul, ne t'arrête pas au milieu du gué.

Et pour appuyer tes dires, j'invite notre interlocuteur à lire ce grand classique:
"12 raisons d'écrire des tests unitaires"
http://www.onjava.com/pub/a/onjava/2003/04/02/javaxpckbk.html
La documentation arrive en 3ème.

Je n’écris pas de tests unitaires. Je comprends le principe, mais je n’y adhère pas. J’ai 0 tests,

Prioriser le static, le plus possible. Si quelque chose est polyvalent pour tout le code, et n’a pas besoin d’être libéré/détruit alors il sera static.

Eviter les get/set de vos variables privés (sauf dans le cas ou vous avez besoin de faire un check en entrée ou une transformation en sortie) et remplacez les get/set par un accès direct à la variable.

Design pattern : c’est indispensable d’en connaître quelqu’uns ou au moins de connaître quelques principes.

Avancer pas à pas sur de bonnes bases mais abstraire ce qu’il faut
…
C’est notamment ça le travail « d’architecte logiciel » que je parlais plus tôt.

Et un jour tu découvriras le TDD, tu feras en sorte d'écrire du code testable depuis le début, tu deviendras test infected et les notions d'emergent design tu embrasseras et le surdesign tu éviteras … naturellement

Petit florilège de liens:
Le singleton c'est le mal:
http://stackoverflow.com/questions/137975/what-is-so-bad-about-singletons
Les methodes static sont un antipattern:
http://misko.hevery.com/2008/12/15/static-methods-are-death-to-testability/
du bon usage du privé avec les tests:
http://programmers.stackexchange.com/questions/100959/how-do-you-unit-test-private-methods

Tu découvriras d'abord Powermock et tu comprendras que plus on dépend de framework plus on se rajoute de la dette technique.
Et tu concevras ton code pour éviter ces pièges et tu atteindras le level "Classic TDDist" en utilisant les bons types de doublures dans ton code et en n'utilisant le petit frère Mockito qu'à bon escient:
http://martinfowler.com/articles/mocksArentStubs.html
http://coding-is-like-cooking.info/2013/04/the-london-school-of-test-driven-development/

Puis tu accéderas au nirvana en t'imprégnant de l'emergent design:
http://www.ibm.com/developerworks/library/j-eaed2/
http://www.aniche.com.br/wp-content/uploads/2013/04/asq-tdd.pdf

Puis dans le DDD (http://www.infoq.com/articles/ddd-in-practice) tu flotteras et l'anemic domain model (inhérent à cretain frameworks) tu exécreras (http://www.martinfowler.com/bliki/AnemicDomainModel.html)

Bon cheminement
Et pour conclure ton billet était intéressant

Vooouuus a-vez pefectly reason

Moi ce que ça m'évoque, c'est que ledit Azer, outre sa susceptibilité plus ou moins mal placée, serait bien inspiré de lire ceci:
http://www.amazon.fr/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

La Russie … No comment !

Gerhard depardyou sort de ce corps !

Ceci n'est-il pas un argument (un de plus) en faveur de la liberté de choisir son assurance chômage ?

Ma thérapie inclus des contributions écrites régulières dans les commentaires linuxfr.

Un petit traitement pour la route:
http://leconjugueur.lefigaro.fr/conjugaison/verbe/inclure.html

Je ne vous compte pas de frais pour cette ordonnance ;-)

Non !
Sur DLFP:
On torD le français à torT et à travers.
On tourne en rond comme un torE
et on se met des torRs de pression.

Et dans l'idéal, il y a encore d'autres raisons: politesse, respect.

Et ca marche dans les 2 sens. Des fois lorsque le chef de projet est un trouduc, il mériterait son petit fork.

Exemple:
Prenez "Git pour Windows". Tout le monde n'a pas envie de se coltiner le man de Vi pour éditer un commentaire de commit ou faire un rebase interactive.
Il n'apparaitrait pas saugrenu pour attirer des newbies git sous Windows, de proposer autre chose qu'un notepad détaché et de pouvoir utiliser un éditeur de terminal compatible avec le cerveau un être humain correctement formaté ("Vi has two modes and you're in the wrong one" joke inside), par exemple "nano", qui a le bon goût d'être dispo sous MacOSX en plus.
Et bien, quand on voit le prétexte foireux du dev qui ne veut pas juste rajouter un package à son mSys2 et qui fait la leçon, on se dit que des fois un petit fork hostile ça pourrait faire du bien à certains:
https://github.com/git-for-windows/git/issues/587

Parce que bon hé jusqu'à preuve du contraire, Vi ce n'est pas du git non plus.
Pis tant qu'à faire si vous regardez sous le /bin local vous y retrouverez
plein d'outils qui n'ont rien à voir avec git comme du curl par exemple.
Et comme ni cygwin et mSys2 n'ont le bon goût de permettre d'installer des packages depuis rawgit, on se dit qu'on pourrait contourner par exemple avec un petit script bien comme il faut:
https://github.com/transcode-open/apt-cyg
Et là, manque de bol ca marche avec du wget ou du lynx mais pas du curl. Faut-y proposer une pull request à ce dernier pour voir s'il sera plus avenant ?
Ou alors se coltiner tout à la mimine et gagner des XPs en postant son tip (un de plus sur Git) sous StackOveflow ?

Ma bonne dame , un utilisateur de base, qui trouve que git ca ressemble à la grosse Bertha pour écraser une mouche, il a pas que ça à foutre.

Mais après faut surtout pas aller raconter que windows est un citoyen de seconde zone pour git.

Mais, je sais: même pas cap de forker

Pour les test E2E avec Angular, la recommandation est protractor qui permet de tester directement les directives d'Angular et surtout qui gère l'asynchrone. Il faut coupler ça avec Karma.

Il m'avait semblé que c'était dans les pipes en touts cas:
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Language_bindings/PyXPCOM

La belle époque de XulRunner.

C'est pas mort tout ça ?

Au hasard… pour rendre le truc aussi imbitable que du Perl avec des contextes dans tous les sens et des rustines avec tout les symboles cabalistiques de l'ASCCI pour que le parser puisse encore passer. A quand l'usage obligatoire de l'UTF8 pour disposer de l'alphabet du Mordor (http://freetengwar.sourceforge.net/keylayouts.html)

Ce truc, tout comme le HTTP qui a fait des contorsions monumentales pour faire passer ce qui n'aurait jamais du exister pour un protocole en mode non connecté … et aboutir à réinventer la roue … J'ai nommé WebSocket. Que de temps perdu!

Quand je pense que Firefox supportait du scripting python un temps. Nostalgie !!!

aussi je te renvoie vers la langage dans lequel les monades sont reines.

J'ai lu tout le thread et c'est une mine d'or, mais en lisant certains posts, j'ai un peu l'impression que certains veulent nous montrer leurs mgonades

Ok => []

le chant du signe

Oui c'est le cygne de la fin

Voilà Zenitram dans toute sa splendeur.

Cet art d'assimiler les idées des autres à leur propos et par effet de bord à leur personne, montrant son mépris, tout en veillant de à ne pas franchir la limite de l'attaque hominem.

Car tout un chacun aura compris:
Tes idées sont de la merde, donc tu es de la merde. Mais comme je ne l'ai pas dit, viens prouver que c'est ce que je pense.
A coup de mots bien clairsemés;

Petit florilègegrep:

pomper ce qu'ils peuvent
le populisme dans toute se splendeur.
populisme mélenchonsite
un combo xénophobe raciste homophobe capitalophobe considérant que le blanc hétéro doit être supérieur au reste "comme avant"?
c'est exactement le genre de réaction bourrin
_
On note la manière dont les idées des autres sont percues.

Je vous laisse le soin d'éplucher les autres discussions pour bien comprendre la rhétorique du sieur

Je pense que sa phrase voulait plutôt signifier:

ressasse les poncifs vis à vis de l’extrême gauche

Tu voulais sans doute répondre sur commentaire précédent ? Ou peut-être le second du fil, non ?
Ou alors ta perception d'un ton méprisant passe à travers un prisme, peut-être ?

Vu que tu lis toujours les trucs en travers, je suppose que tu n'as pas pris le temps de cliquer sur le "petit" lien qui illustrait ses propos.

Peu importe !
Ce qui me fait réagir, c'est ça:

Ce qui est fout, c'est toute cette haine de l'Europe, quand on a des millions de personnes qui ne rêvent que d'une chose, c'est de pouvoir y rentrer

Hormis ta petite entorse à l'orthographe qui s'est pourtant plus qu'assouplie, j'ai juste envie de te répondre ça :
#Brexit

Tu verras, c'est instructif sur l'appréciation par des millions de personnes vis à vis de l'Europe aujourd'hui et qui ne s'enfuient pas d'un pays en guerre ou en crise

Pas que je les cautionne hein … mais te connaissant tu vas réussir à me démontrer que si, je ne m'inquiètes pas.

Oui enfin pour un gars qui critique l'aliénation par le travail, avoir un président qui s'appelle "Cage", ça a un petit coté hérétique

Perso, ce que je trouve vraiment bizarre, c'est de faire "ça" à 15 mois des présidentielles.
- Ca merde, ça sera la faute de Hollande.
- Ca marche, le successeur en tirera les lauriers.
Dans tous les cas, le gouvernement actuel perd. en plus de se faire tiré dessus (à raison) par son aile gauche pour l'élection. En gestion quand on est dans la majorité, ils sont vraiment pas au point. C'était à faire il y a 3

Au contraire, c'est machiavélique.
La droite est dépassée par son extrême et ne pourra pas chasser sur ses terres et il pourra lui couper l'herbe au centre.
Quand à l'extrême gauche, elle restera toujours en marge