Reprise du message précédent :

 
Il est typesafe le SQL généré à la compilation (il vérifie par rapport à un modele donné et/ou une vrai DB comme https://github.com/launchbadge/sqlx par exemple) ?

C’est vrai pour tous les jobs à L7 et au delà : tes actions se voient (ou se voient pas) a des horizons bien plus long. Après quand je dis “rien faire” c’est en gros quand même aller aux meetings, faire mes devoirs de manager, etc… mais c’est en gros pas forcer le soir et surtout rien foutre du vendredi
 
Mais oui c’est assez dingue j’aurais jamais pensé ne serait-ce que 5 ans en arrière avoir ce type de revenus

 
Vous pouvez faire des procédures stockées, les requêtes sont stockées en base au lieu d'être générées coté client. La base présente alors une API de requêtes possibles que le client appelle. Cette manière de faire est assez élégante, je touve, mais le déploiement est plus compliqué puisqu'il faut le faire dans la base de données et bien sûr s'assurer de la compatibilité entre le code client et la base.

En faisant pas de C++

Je présume que EF est un ORM, donc ça a l'avantage d'être très haut niveau et naturel (s'il est bon en tout cas) mais ça demande beaucoup d'infra en dessous, et ça tend à être inflexible et inefficace (genre il est difficile d'optimiser tes requêtes au maximum ou de tirer un maximum des spécificités de la DB).

Je suis pas sûr qu'un ORM se trouve pour du C++, et pour les raisons au dessus plus les langages sont bas niveau plus les ORMs ont tendance à donner des boutons (et généralement les ORMs marchent par réflection, ou alors il faut des montagnes de codegen, c'est d'autant plus difficile en C++).

Faut probablement plus regarder du côté des DAO (pour l'organisation) et des query builders (pense linq for sql).

Ou bien le projet a démarré petit et personne a remis le problème en question.

C'est une approche qui ne vaut vraiment le couop que si tu as plusieurs clients qui tapent dans la base et que tu veux contrôler les accès, ou plus généralement que tu fais pas confiance aux clients mais que tu veux / peux pas avoir de broker (tes stored procs te servent d'API), mais pour une relation 1:1 c'est ultra chiant, la moindre interrogation de db impose d'aller mettre à jour le schéma pour ajouter ou éditer une procédure stockée habituellement codée dans un langage bancal que t'as pas envie de toucher. Et au final t'y gagnes rien: ta proc stockée pourrait être une fonction / méthode, t'aurais moins d'overhead à l'appel, moins de chances de te planquer, et plus de vérifications.

Édit, j'avais pas bien lu le message. Non.

Commencer dans le web à 47 ans ?
https://forum.hardware.fr/hfr/Progr [...] 8268_1.htm

Spanner supporte pas les procédures stockées.
Même pas les générateurs de séquences.

Ca rend le code client plus propre car il n'a pas à construire les requêtes, il se contente d'appeler les méthodes exposées par l'API. Du coté base, c'est du SQL tout ce qu'il y a de plus standard.
Il n'y a pas de leak de SQL dans le code C++ via une meilleure séparation des couches. Mais oui, c'est plus chiant coté déploiement, ça ne fait aucun doute.

On n'utilise pas de bases de données relationnelles. Nos requêtes se limitent à getByKey sur une base NoSQL.

Ça n'aide pas je sais

 
Ah, toi aussi tu bosses à PlamCorps.

Bah si c'est juste qu'elle est construite dans la PS, et qu'en plus tu dois faire une traduction supplémentaire.
Version PS:

cr.callproc('get_thing', [id])
result = cr.fetchall()

CREATE FUNCTION get_thing(id integer)
  returns setof sometable
AS
$$
SELECT * 
FROM sometable 
WHERE id = id;
$$
LANGUAGE sql;

Version pas PS:

result = get_thing(id)

def get_thing(id):
    cr.execute("select * from sometable where id = ?", [id])
    return cr.fetchall()

La version PS est juste plus chiante à maintenir avec encore plus de points d'erreur possibles, pour un gain intrinsèque plus ou moins absent (si tu utilises une DB qui typecheck les stored proc de manière extensive ça peut voir des erreurs de codage à l'installation mais je crois pas que ce soit le cas de postgres)
 

Si c'est du SQL "tout ce qu'il y a de plus standard" (pas de construction dynamique, pas de processing procédural) c'est trivial à faire côté client.

Si c'est du SQL pas trivial, c'est tout aussi dégueulasse dans la stored proc (voire pire, parce que t'as pas de query builder dont c'est le job).

Tu peux faire ça en imposant que le SQL soit dans des modules d'interaction DB, dédiés.

Calomnie, on a des générateurs de séquences ! ( Ou alors je comprends pas à quoi tu fais référence)

Et oui il n'y a pas de procédures stockées, qui pour être honnête ne me manquent pas franchement. Même si effectivement ça permettrait de découpler un peu et de forcer à avoir des requêtes bien foutues avec une interface commode, et relue séparément. Mais je ne demande pas seulement pour trouver des alternatives, plutôt pour savoir ce que vous tolérée de votre côté, si je suis déraisonnable de demander de ne pas utiliser ça autant que possible.

Non mais évidemment mais ça reste du C++, quoi. C'est déjà pénible de lire du SQL ou du C++ indépendamment, quand faut comprendre le SQL généré par le C++, perso je renonce...

Mais bon, compris, le C++ c'est un langage de bonhommes en gros, fait que j'arrête de chouiner...

(Je crois qu'on a un ORM qu'en java et j'en ai entendu plutôt du mal...)

Ça a radicalement changé pour depuis que je bosse à Google. Tu dis toi même que tu ne corps professionnellement que des mauvais ; c'était plus ou moins mon cas. J'ai croisé quelques bons avant mais c'étaient des exceptions.

Dans une boîte comme Google, le niveau global est bon, et ça donne une pleine opportunité de connaître son propre niveau par rapport aux autres. Je côtoie de nombreux cadors, et je suis vision de bureau de pointures mondiales. À côté de ça, il y a beaucoup de bons, et pas mal de médiocres. Peu de mauvais mais on en a. Bref, avoir un gros échantillon pertinent à portée ça m'a aidé à été serein par rapport à mon niveau technique. Je ne me fais pas d'illusion, mais le syndrome de l'imposteur est aussi assez loin derrière. En corollaire, il y a pas mal de moments où je femme ma gueule parce que j'ai simplement pas le niveau ; mais quand je l'ouvre, c'est dans complexes.

 
Je suis devenu officiellement développeur (c'est à dire avec un vrai job title dans un boite) à 43 ans. Les deux ans qui ont précédé, j'étais dev mais mon job title c'était support engineer. Rien n'est jamais perdu... On peut même devenir CTO.
 
Mais bon, on va pas se mentir non plus, l'info était ma seconde passion après la musique et j'en ai toujours plus ou moins fait et avec des bases de prog dès l'age de 14 ans.
 
Ça semble quand même difficile à 47 ans de s'y mettre... Maintenant, je dirais que tout est affaire de motivation. Si le mec a une vie de famille, des amis, une maison à entretenir etc... Je dirais que c'est mort. Ce genre d'exploit n'est possible qu'en bossant de manière passionnée toute la journée, WE compris.
 
Quant au fait d'être recruté par une boite sans exp à on va dire 50 ans (vu que si le mec s'y met à fond comme un malade, 3 ans ne seront pas de trop), c'est pas gagné. Ceci dit, on manque tellement cruellement de devs ici par exemple que c'est possible.  
 
Le meilleur espoir à cet age là sans exp, c'est de se mettre en freelance, mais sans exp, le freelance, c'est un très gros piège car tu essuies les plâtres avec tes premiers clients (voire même tous tes clients pendant un bon moment   )
 

34 ans ici, mais j'ai pris la décision à 25. Ça me semble chaud de commencer de rien à 47 ans...

 
ça me parait tout à fait faisable au contraire. Tout le monde va pas bosser chez Gougueul hein
 
Quelqu'un de motivé et qui a de bon soft skills y arrivera de toute façon

Ouais, c'est pas faux. Puis de toutes façons c'est un peu con ce que j'ai dit, parce que j'ai pris la décision à 25 ans mais j'ai tout de suite aimé programmé dans mon travail et à côté, même si j'avais pas le titre de développeur. Je retire.

 
Avec enfant et vie de famille "normale" participative, ça doit être très très dur. Surtout si madame travaille et que monsieur est dans une config où c'est lui qui s'occupe des enfants. Quand je vois le temps qui me reste (c'est à dire 0,00 seconde) tous les jours... Et je n'ai même plus de loisirs...  
 
Bon là madame et les enfants sont sur le continent et je suis seul encore 2 semaines... (avec plein de missions à faire pour la maison etc...) Ben du coup, j'ai pu me remettre à jouer un peu aux jeux vidéos. Je me suis pris le dernier tomb raider et surtout Disco Elysium.

Vive la France.  
 
https://twitter.com/m_ou_se/status/1553322611903447042
 
https://twitter.com/windowscpp/stat [...] 3368312832
 

Balade toi sur son compte et enjoy.

 
J’ai pas trop accroché, c’est très space comme jeu

Non je vais pas faire ça, j'ai vu deux messages et... ew

 
Yikes  

 
Je suis mort d'une crise cardiaque, faut que je recommence.  
 
Effectivement, c'est un jeu vraiment atypique, un mélange de RPG et de point and click genre les chevaliers de Baphomet. Mais j'ai pas mal accroché. ça me rappelle aussi vaguement Machinarium bien que l'esthétique soit différente et que c'était une autre époque. Il y a énormément de paroles, c'est tentant de zapper, mais si on le fait, on passe à côté du jeu.  
 
Concernant le dernier tomb raider, on est trop guidé comme sur un rail. Les interactions avec les autres personnages sont trop limitées... Pour le moment plutôt déçu. Les énigmes sont téléphonées... Bref, pas terrible, mais c'est distrayant.

Joue au jeu du Bayou ! (et pour ceux qui disent qu'il est mort, le graph va plutôt vers le haut : https://steamcharts.com/app/594650 )

Je suis resté à ce que la doc raconte:
https://cloud.google.com/spanner/do [...] #sequences
https://cloud.google.com/solutions/ [...] ud-spanner
 
Perso je fais pas trop de relationnel, mais j'ai un langage qui a des macros puissantes donc on peut soit:
- Typer du SQL quasiment brut (des chaînes interpolées). C'est ce qu'on fait. Ça me semble raisonnable, si je débarque sur du code que j'ai pas écrit, je prends la requête comme une boîte noire, la signature devrait me suffire. À moins qu'il y ait un problème avec celle-ci et de toute manière je vais devoir la reprendre en dehors de mon IDE.
- Dans l'autre sens, construire des requêtes avec une API fonctionnelle et dériver des codecs à partir d'objets. C'est l'approche plus lisible et naturelle mais évidemment plus contraignante.
 
Y a très longtemps j'ai utilisé myBatis en Java (je sais pas ce que mon équipe avait contre Hibernate/JPA) et ça me semblait pas trop mal comme concept si tu veux pas un ORM.

On les a dans le vrai spanner en interne, ça devrait arriver

J'ai pas compris, tu peux élaborer...

Du coup vous devez supporter une chiasserie pas vraiment webscale en interne avant de la proposer aux clients externes, qui eux ont au moins l'excuse de devoir migrer des vieilleries vers GCP.
Marrant.
 

https://getquill.io par exemple.
 
Je connais pas Entity Framework mais j'imagine que ça use et abuse de réflexion.
Si tu veux pas ça, il te faut de la génération de code, ou mieux, des macros.

Il fait du SQL, son problème n'est clairement pas webscale

La chiasserie pas webscale c'est spanner ? Je comprend rien, là...

Non mais je m'en fous, allez lui répondre à lui, pas à moi.

cr.callproc('get_thing', [id])
result = cr.fetchall()

CREATE FUNCTION get_thing(id integer)
  returns setof sometable
AS
$$
SELECT * 
FROM sometable 
WHERE id = id;
$$
LANGUAGE sql;

result = get_thing(id)

def get_thing(id):
    cr.execute("select * from sometable where id = ?", [id])
    return cr.fetchall()

Tu prends l'exemple le plus simple, là, et en Python en plus. Dès que tu as des requêtes un peu complexes, on est content de ne pas avoir ce mix de C++ et de SQL.

[

Oui MyBatis a le bon niveau d'abstraction, je trouve.

Non Pour les requêtes complexes t'as le même overhead, et en plus t'as du SQL dans du PL et c'est encore plus merdique, parce que ton meta est un tas de boue.

Le seul scénario où je suis content des procs (encore une fois en dehors du scénario où des projets indépendants vont taper dans la db) c'est si quelqu'un d'autre se tape le SQL, au quel cas effectivement RAB de s'ils vont ça d'un côté ou de l'autre c'est plus mon problème.

les procédures stockées c'est un putain d'enfer.
Y'a très peu de raisons pour que ce soit un bon choix.
Mis à part le partage comme évoqué par le mask ou bien une grosse intelligence pour faire du reporting sinon je ne vois pas.
et c'est la merde à tester, déployer etc

C'est parfois significativement plus rapide sur certains traitements lourds, comparé à la même chose avec la techno "cliente". Et anciennement c'était un moyen de factoriser les traitements métier pour plusieurs clients de la base - ce que tu fais de nos jours avec une API.

Mais d'autres fois c'est notablement moins rapide parce-que ça taxe ton serveur de DB alors que t'as des app serveurs à pas savoir quoi foutre, donc même là ça reste du gros cas par cas.

J'ai pas dit que c'était une bonne solution dans tous les cas...mais parfois ça se tient

Bisous aux grenoblois depuis l’A49, direction Fontvieille. En espérant que ça bouchonne pas trop.