Reprise du message précédent :

Ok donc tu crées des classes finalement, that's too bad. Ton raisonnement tombe à l'eau.
 
Je vois pas le concept d'avoir un repository trans entity, tu as entendu parler de single responsibility ? Ca doit être chiant à gérer maintenir et tester.

Spring data te permet d'avoir un base repository pour ça donc.

Repository trans entity, c'est red flag  

Je laisse le job de leader à Shinu, il a une Rocket je crois?
 
Perso j'avais tout revendu pour un Feldgrind et une Flair.  

Je crée les classes dont j'ai besoin, pas des classes que le framework m'impose de créer parce qu'il est pensé avec les pieds.

Et ensuite, de mon point de vue il n'y a pas de problème vis à vis du SRP : j'ai une classe dont la responsabilité est de gérer le CRUD sur les entités, et d'autres classes dont la responsabilité est de gérer des requêtes complexes sur des entités.

c'est juste un choix de périmètre : dans la stratégie "une entité = un repo", tu as un périmètre "fonctionnel", dans la seconde stratégie le périmètre est défini par les opérations.

Ce que je vois en simplification, c'est que si j'ajoute une entité sur laquelle je ne ferais que du CRUD (soit l'énorme majorité des cas pour les entités simples, puisque les cas complexes sont généralement "délégués" aux repo des entités de plus haut niveau via la modélisation des relations & co), ben j'ai rien de plus à ajouter. Pas de nouveau service, pas de nouveau test (oui, parce que l'enjeu de mes TUs, c'est pas de tester que l'implémentation de EntityManager sait lire dans plusieurs classes, ça fait partie des acquis, de la même manière que tu t'amuses pas à tester une méthode du JDK.

(et j'aime PAS DU TOUT lombok BTW Dans le genre truc à la con pour s'éviter des choses que l'IDE fait très bien pour toi, ça se pose là, je trouve.)

ben dans la mesure où l'interface Repository est généricisée avec <T, ID>, où T et ID sont respectivement la classe de l'entité et la classe de son ID, je vois pas comment, mais j'ai peut etre une version de Spring de retard pour le coup.

(mon "TheRepository" n'est pas paramétré, c'est les méthodes qui le sont. Et en fait cette implémentation est très proche de la couche en dessous (l'EntityManager, qui marche exactement comme ça) : je sais pas si tu irais dire que l'EntityManager a un problème de Single Responsability?

 
C'est ça un "gros" modèle chez vous?

Je voulais profiter de l'offre free tier de GCP pour développer une petite app qui tourne une fois par jour pour scraper mon nombre de messages sur HFR et le stocker en base.
 
Malheureusement pas de SQL disponible dans le free tier, uniquement du NoSQL. Je n'ai jamais joué avec mais pour stocker ce genre de données ça me semble une mauvaise idée. Vous confirmez ?
 
L'autre solution serait d'utiliser l'instance de compute engine pour installer PostgreSQL mais j'ai pas vraiment envie de m'embête avec ça ?
 
Vous voyez une autre solution ? Je migre chez AWS ?

Tu donnes pas assez d'info pour te guider dans ton choix.
Que vas tu faire de cette donnée ?

 
Afficher le nombre de messages par jour dans un beau graphique à barres.

Pourquoi ? Vu ton besoin, un simple fichier JSON ferait l'affaire, donc NoSQL c'est presque royal.

En fait ton TheRepository sert à rien à part un layer d'indirection au dessus de l'entity manager.
 
 je vois pas le problème que tu as si ce n'est une question de goût, OK t'aimes pas Spring Data car tu préfères utiliser l'entity manager directement, perso je préfère bosser avec un repository tailored à mon domain, bien séparé qu'un truc foure tout.
 
Oui tu peux le faire aussi avec spring check @EnableJpaRepositories.
 
Concernant les tests, bien sûr qu'il faut tester le repository layer.

 
non.
 
Après on a parfois des champions du monde même sur des petits modèles.
 
Là j'ai un truc qui représente un workflow, il y a~45 types d'étapes pour le modèle avec juste une petite dizaine d'attributs en commun et le reste spécifique (on en a où il n'y a aucun attribut spécifique)
 
Je sais pas pourquoi, le mec a pas voulu mettre de discriminant dans la table "Etape". Tout est piloté par le type Java.
 
Du coup, tu as des tas de tables "EtapeMachin", avec juste une colonne ID (0 champ spécifique).
 
Et quand on a eu à chercher "les Brols dont la dernière étape est de type X", ben...C'est amusant à faire.
 
(et en vrai il a encore une couche de merde, parce qu'il y a N workflows, pour N types de Brols, donc Etape -> EtapeN -> [les étapes du workflow N]
 
Dans la table Etape on a l'ID, la date, et les données d'audit (la personne qui a créé l'étape)
Dans EtapeN, on a l'ID du BrolN et l'ID de l'étape
Dans EtapeNMachin, on a parfois que l'ID de l'étape.
 
JE comprends pas.

Sqlite dans un fichier tout simplement, ou même un json.

 
Je sais pas, si demain je veux pouvoir afficher le nombre de messages sur période glissante ou faire des stats plus poussée, ça ne m'a pas l'air pratique ?
 

 
Ah mais oui, SQLite stocké sur Cloud Storage ça devrait le faire !

Du boilerplate que tu dois donc voir dans l'IDE, et maintenir, pas oublier de mettre à jour.
 
Bof, lombok largement winner.

Plus simple encore, un fichier plat en csv ou json sur Storage.
Tu le mets à jour à chaque fois.
C'est le plus économique et le plus résilient.

Si tu en fais ensuite une appli Web, ouais effectivement, mais si c'est pour faire un graph localement..

Will it scale?

Ben à toi de nous donner les infos, combien d'user tu vises, combien d'accès à la seconde, etc ?
Appli Web ou appli locale ?

Sqlite prends pas bcp de place, tu peux filtrer aisément par requetage, ensuite un endpoint qui renvoie une image du graph rappelant les temps glorieux des compteurs xiti.
 
Par contre je crois pas que tu puisses mettre des images dans la signature HFR

 
Avec un datapoint par jour et peut être un jour éventuellement faire une moyenne je pense que t’es OK, mais si tu veux faire ton cake t’écris ça dans un CSV (vu que t’as une colonne, ou deux si tu veux faire ça bien, ça devrait pas être trop difficile) et tu peux faire tes stats en chargeant ça dans un tableur comme tous les winners.

Après t’as aussi l’option de te faire un job d’import / publication datasette, d’ailleurs il y a un workflow cloudrun built-in. Et il y a des articles sur la partie publication / mises à jour (je pense que le workflow cloudrun c’est juste la publication)
 
Genre https://simonwillison.net/2020/Jan/ [...] cloud-run/

Sinon OCI a un tier gratuit qui est large si tu veux du SQL.

Principalement moi pour le nombre d'utilisateurs mais ce sera public, application web donc.

Pas bête l'idée de l'image générée une fois par jour

Je vais y jeter un oeil

oui alors évidemment, la query est lente parce que je join une table avec 3.5 x 10^15 lignes avec une autre de 1.5 x 10^15, tout ça pour juste une journée de logs (note : le join est obligatoire, c'est la conséquence d'une décision qui évite de casser l'internet sous des torrents de bits de vidéos de potichats ^^)
Je crois que j'ai explosé mon quota perso, et celui de mon groupe
 

la Belgique tu l'aimes ou tu la quittes
 

quand je lis ça je lis "merde, on a peut etre un peu tarder pour empecher chaque dev d'amener son langage préféré
et encore je suis surpris, y'a pas JS/Typescript
 

 
tu lis "Clean code", et tu appliques strictement :  
- pas de fonction de plus 3 lignes
- si t'as besoin de moins de 6 indirections pour faire un truc tu t'y prends mal
- ne pas oublier d'abstraire, et de bien respecter l'encapsulation. Si un grep sur ton projet avec "AbstractFactory" renvoit rien, faut repartir depuis le début
 

 
J'ai un peu évolué sur Lombok avec le temps, mon problème au fond c'était pas l'outil, c'est l'absence de pratique délibérée.
Genre de mettre des equals/hashcode et des palanquées de getter/setters/constructeurs absolument partout parce que c'est rapide sans se poser de question.
Tu peux avoir le même genre de problème avec la génération dans l'IDE, ça arrive un poil moins souvent à cause de la friction supplémentaire, mais pareil ça empêche pas des gens d'en foutre partout sans questionner la pratique.
 
Notamment un point de friction que j'aime délibérément avoir dans une classe, c'est devoir écrire/mettre à jour le constructeur à la mano, parce qu'un grand nombre de paramètres de constructeur c'est un smell et que c'est mieux d'avoir le nez dedans que d'avoir un outil qui te permet de l'ignorer royalement et d'empiler les paramètres jusqu'à ce que mort s'ensuive.
 
Bon après avec les versions récentes de Java, c'est moins utile, mais comme béquille quand t'es bloqué en Java 8 why not.

tu veux pas mettre un truc genre sonar là-dessus ?

 
+1
 
Et si tu utilises Lombok sur des projets avec des devs juju pas trop bons (ou des vieux pas bons), tu peux vite avoir des emmerdes avec le equals / hashCode mutable quand on colle les trucs dans des set,
le toString qui prend tous les champs d'une entité, y compris les collections en lazy-loading
ou autre joyeusetés.
 
Toutes ces méthodes "techniques" que pas mal de devs utilisent avec une "vision métier" (genre toString pour construire la "vision log" complète, ou equals() pour une éqalité métier), mais qui ont un impact sur le comportement d'autres outils ou qui sont appelées de manière transparente, j'aime pas l'idée de ne pas les maîtriser (ok, avec Lombok tu les maîtrises SI tu mets toutes les annotations qui vont bien au bon endroit, etc.. Ce qui réduit considérablement la simplification apportée par le fait de ne pas écrire le code.
 
Et après y'a aussi la question de bidouiller l'AST : pourquoi pas, mais pour debug ce qui se passe ça deviet vite casse-couilles.

Shinu il a le rôle de Christian Bale alors que toi c'est plutôt Dwayne Johnson    
 

Avec une telle charge je crains que tu t'approches des limites du service mais peut être que BigQuery peut faire l'affaire.. Faut tester.
Sinon il te reste google sheets mais je ne souhaite cela à personne

Nan mais tu vas pas non plus faire ça comme un shlag, on se mets d'accord sur le contrats d'interface, et si le dev back fait une évol il me prévient ou mets à jour une doc ou me dit de voir le swagger car il a mis à jour son bordel.
Il m'arrive de n'avoir rien à manger au niveau de l'api du mec, mais on s'est mis d'accord sur lesgrandes lignes et au pire les noms des champs s'ils changes je change dans l'app et je relances les tests et yolo.
 
il m'est même arrivé de faire un document et définir une partie de l'API que moi j'attendais en disants au dev, voilà à peu près ce que je voudrais, mais on peu discuter de tout.

Ça reste pourtant moins de langages que chez google
 
Et je serais pas surpris si c'était justifié, juste le repo principal actuellement c'est 90kloc de C++ et 90 de python, avec une archi comme ça:

d'ailleurs tu regardes un peu le tracker les mecs te disent cash que c'est super puissant et flexible et que tu peux faire du multi-modal et de l'international et tout, mais que c'est une plaie à déployer et si t'as pas besoin mieux vaut aller ailleurs (ils proposent même des alternatives dans le readme).
 
On peut facilement imaginer:

• qu'ils ont des services en python qui scalent pas, mais ils veulent pas les descendre en C++ parce-que C++, go est un bon candidat pour ça
• ils ont des problèmes de fiabilité / sécurité avec le C++, et ils veulent pas le remonter parce que C++ (cf point précédent), rust est un bon candidat pour migrer l'existant ou pour les nouveaux services qui ont des perfs un peu trop critiques

Et vous aimez faire des classes Compare en Java

Mais comme précisé dans mon message ce qu'ils cherchent c'est un dév C++  

C'est une succursale d'une succursale de la SNCF, s'pas dit que les RH acceptent autre chose comme titre officiel
 
D'ailleurs j'avais pas regardé leur org, mais je viens de trouver ça: https://github.com/hove-io/transit_model

C'est techniquement faux, tu nous avais habitué à mieux
 
Tout ça à cause de cet abruti de Louis XV
Le Québec c'est la France

 
Oui c'est possible et c'est d'ailleurs un peu le rôle de ces outils.
 

 
Le cœur du problème il est là ouais.

 
Ca ou alors on est des vieux cons aigris

 
1/ au final si tu sors de C++ / Java on edt deja sur la long tail
 
2/ is that a lot ?
 

ah ! puisque tu abordes le sujet ...

 
Je crois que je le suis de moins en moins, au sens ou je suis de moins en moins intransigeant sur les détails que je ne l'étais avant.

le truc que je déteste le plus c'est les jeunes qui se comportent comme moi quand j'étais plus jeune.