https://www.whitehouse.gov/presiden [...] -agencies/
 
Oh bordel, mais comment c'est possible?
 
Tl,dr: les agences indépendantes aux USA sont placées sous le contrôle de la maison blanche.
 
Les agences doivent suivre l'interprétation de la loi du président,
 
Les crédits peuvent êtres gelés si une agence ne suit pas les priorités de la maison blanche,
 
Aucune réglementation ne peut être émise sans accord du président  
 
Un "agent de liaison" va être mis en place dans toutes les agences indépendantes.
 
C'est le moment d'acheter du tesla, la SEC va être aux ordres

https://www.whitehouse.gov/presiden [...] -agencies/
 
Oh bordel, mais comment c'est possible?
 
Tl,dr: les agences indépendantes aux USA sont placées sous le contrôle de la maison blanche.
 
Les agences doivent suivre l'interprétation de la loi du président,
 
Les crédits peuvent êtres gelés si une agence ne suit pas les priorités de la maison blanche,
 
Aucune réglementation ne peut être émise sans accord du président  
 
Un "agent de liaison" va être mis en place dans toutes les agences indépendantes.
 
C'est le moment d'acheter du tesla, la SEC va être aux ordres

bordel c'est grave  

Mais non, cela sera challengé. Au niveau judiciaire la cour suprême de Roberts rendra une décision impartiale qui ne laissera pas de place au doute. Et au niveau politique Mike Johnson, Chuck Grassley et John Thune montreront de quoi le congrès est capable !
 

Mais non, cela sera challengé. Au niveau judiciaire la cour suprême de Roberts rendra une décision impartiale qui ne laissera pas de place au doute. Et au niveau politique Mike Johnson, Chuck Grassley et John Thune montreront de quoi le congrès est capable !
 

 
pays finito, bien capté  

Relevant : https://www.reddit.com/r/LeopardsAt [...] _whatever/

Il n'y a que moi que ça débecte cette espace en trop au début d'un paragraphe sur trois ?  
 
(Le contenu aussi j'entends, mais bon je me concentre sur mon domaine d'expertise...)

 
pays finito, bien capté  

Allez donc voir le sub /r/leopardsatemyface, qui répertorie des articles concernant des personnes qui se plaignent de subir des situations qu'elles ont souhaitées et contre lesquelles elles se croyaient à l'abri, les croyant réservées "aux autres". Le nombre de gens qui ont voté pour Trump et qui le regrettent amèrement car elles en subissent les effets négatifs est affligeant.
 
Exemple : https://www.reddit.com/r/LeopardsAt [...] ck_kamala/

Project 2025

Qui se résume donc à considérer que la Constitution américaine, qui est sensée définir très précisément les responsabilités des 3 branches du gouvernement, n'est qu'un bout de torche-cul.
Parce que son executive order n'aurait vraisemblablement aucune valeur juridique si la Cour Suprême faisait son boulot.

Après le fight sur le RegEx, je vous en propose un autre...
 
Est-ce que ça vaut le coup d'utiliser des ORMs en 2025 (en dehors de case scenario où le framework utilisé comprend déjà l'ORM, comme par exemple Django).
 
En ce moment, je continue de m'auto-former sur Rust, Python (avec flask), PostgreSQL et aussi React et d'autres trucs...  
Il y a tellement de langages informatiques et tellement de possibilité... Est-ce que c'est pas mieux de réellement continuer avec SQL (on est pas obligé de passer du SQL dans le code directement, on peut utiliser aussi des prepared statements.)
Quels sont les plus gros avantages objectifs d'utiliser des ORMs ?
Quand on passe d'un langage à l'autre, même si les ORMs se ressemblent bcp, n'est pas une perte de temps ?
Je sais que bcp vantent les ORMs parce que la couche d'abstraction rend l'architecture des projets plus lisibles et ça évite d'avoir du SQL qui se balade dans le code... Mais est-ce que c'est fondamentalement si différent que cela des prepared statements ?

Après le fight sur le RegEx, je vous en propose un autre...

Est-ce que ça vaut le coup d'utiliser des ORMs en 2025 (en dehors de case scenario où le framework utilisé comprend déjà l'ORM, comme par exemple Django).

En ce moment, je continue de m'auto-former sur Rust, Python (avec flask), PostgreSQL et aussi React et d'autres trucs...
Il y a tellement de langages informatiques et tellement de possibilités... Est-ce que c'est pas mieux de réellement continuer avec SQL (on est pas obligé de passer du SQL dans le code directement, on peut utiliser aussi des prepared statements.)
Quels sont les plus gros avantages objectifs d'utiliser des ORMs ?
Quand on passe d'un langage à l'autre, même si les ORMs se ressemblent bcp, n'est pas une perte de temps ?
Je sais que bcp vantent les ORMs parce que la couche d'abstraction rend l'architecture des projets plus lisibles et ça évite d'avoir du SQL qui se balade dans le code... Mais est-ce que c'est fondamentalement si différent que cela des prepared statements ?

 
Je ne comprends pas cette partie, tu peux l'expliciter ?
 
EDIT : Ha, tu ne mets pas les deux en opposition, j'ai eu peur.

Après le fight sur le RegEx, je vous en propose un autre...
 
Est-ce que ça vaut le coup d'utiliser des ORMs en 2025 (en dehors de case scenario où le framework utilisé comprend déjà l'ORM, comme par exemple Django).
 
En ce moment, je continue de m'auto-former sur Rust, Python (avec flask), PostgreSQL et aussi React et d'autres trucs...  
Il y a tellement de langages informatiques et tellement de possibilités... Est-ce que c'est pas mieux de réellement continuer avec SQL (on est pas obligé de passer du SQL dans le code directement, on peut utiliser aussi des prepared statements.)
Quels sont les plus gros avantages objectifs d'utiliser des ORMs ?
Quand on passe d'un langage à l'autre, même si les ORMs se ressemblent bcp, n'est pas une perte de temps ?
Je sais que bcp vantent les ORMs parce que la couche d'abstraction rend l'architecture des projets plus lisibles et ça évite d'avoir du SQL qui se balade dans le code... Mais est-ce que c'est fondamentalement si différent que cela des prepared statements ?

 
C'est un style typographique (C'était une option assez proéminente dans genre Word et Publisher 95, donc ça me parait assez old school)

idéalement je choisirai un ORM qui est debrayable, pour pouvoir faire les requêtes  
avancées

Bah par exemple :

https://www.postgresql.org/docs/cur [...] 0executed.

Tu prépares toutes tes queries que tu nommes à l'avance et tu appelles les queries plus tard au lieu de passer du SQL dans le code.  

Est-ce que ça vaut le coup d'utiliser des ORMs en 2025 (en dehors de case scenario où le framework utilisé comprend déjà l'ORM, comme par exemple Django).
 
En ce moment, je continue de m'auto-former sur Rust, Python (avec flask), PostgreSQL et aussi React et d'autres trucs...  
Il y a tellement de langages informatiques et tellement de possibilités... Est-ce que c'est pas mieux de réellement continuer avec SQL (on est pas obligé de passer du SQL dans le code directement, on peut utiliser aussi des prepared statements.)
Quels sont les plus gros avantages objectifs d'utiliser des ORMs ?
Quand on passe d'un langage à l'autre, même si les ORMs se ressemblent bcp, n'est pas une perte de temps ?
Je sais que bcp vantent les ORMs parce que la couche d'abstraction rend l'architecture des projets plus lisibles et ça évite d'avoir du SQL qui se balade dans le code... Mais est-ce que c'est fondamentalement si différent que cela des prepared statements ?

 
Opinion du département marketing :  
- comme toute abstraction, c'est bien quand ça fuit pas. Si tu fais du CRUD c'est génial, si t'as un truc poilu tu vas te battre contre les limites du truc, et finir par faire du SQL. Donc ça dépend du ratio de trucs poilus / tous les trucs que tu dois faire avec une BD. Ça dépend aussi du temps que tu as
- le SQL reste un des meilleur investissement de formation qu'un dev puisse faire : ça bouge peu, c'est utile dans toutes les branches de l'IT. Je gère une équipe de ML, on fait du SQL tous les jours, toutes mes sources de données sont consultables en SQL

 
Non mais en 2025 c'est la seule manière correcte d'exécuter une requête depuis ton code, en fait.
 
[edit]
 
...mais tu as toujours le sql dans ton code, tu t'en sers pour créer un prepared statement au lieu de l'exécuter direct, c'est tout.

 
Clairement ça sert à rien SQL, le mieux c'est de mettre toutes tes données dans un gros fichier texte et quand tu as besoin de récupérer quelque chose tu écris une regex. En plus tu as des outils pour les rendre plus lisible, mais franchement moi je trouve que mes regex sont toujours hyper lisible, et tellement plus faciles à maintenir qu'une requête SQL ou un appel à un ORM...

 
Bah par exemple :
 
https://www.postgresql.org/docs/cur [...] 0executed.
 
Tu prépares toutes tes queries que tu nommes à l'avance et tu appelles les queries plus tard au lieu de passer du SQL dans le code.  

Bordel de merde... Je vieillis ou quoi ??    
 
Je voulais parler des stored procedures, pas des prepared statements.    

 
Les ORMs c'est très bien si tu peux tirer parti de libs qui s'appuient dessus pour te mâcher le boulot.
Si c'est juste comme couche d'abstraction, ça sert à rien.

 
Merci    
 
Je ne comprends pas cette partie, tu peux l'expliciter ?
 
EDIT : Ha, tu ne mets pas les deux en opposition, j'ai eu peur.

déjà  ne pas utiliser un prepared statement est interdit en 2025, par contre le SQL n'est pas sale, on a tout a fait le droit de l'utiliser.

avantage des orm : ça précable les fonctions de base pour récuperer un objet, ou une série d'objets avec des filtres basiques. Ca câble aussi les récupérations de type, l'introspection et les migrations de schéma données. Rien d'infaisable à la main, mais ça peut quand même être tricky
 
 
inconvenient : le jour ou l'orm est abandonné, tu meurs, ou plutôt tu fais avec l'existant ou tu migres. Les requetes un peu complexes d'aggregations peuvent ête compliquées a faire dans un ORM
 
idéalement je choisirai un ORM qui est debrayable, pour pouvoir faire les requêtes  
avancées

 
Opinion du département marketing :  
- comme toute abstraction, c'est bien quand ça fuit pas. Si tu fais du CRUD c'est génial, si t'as un truc poilu tu vas te battre contre les limites du truc, et finir par faire du SQL. Donc ça dépend du ratio de trucs poilus / tous les trucs que tu dois faire avec une BD. Ça dépend aussi du temps que tu as
- le SQL reste un des meilleur investissement de formation qu'un dev puisse faire : ça bouge peu, c'est utile dans toutes les branches de l'IT. Je gère une équipe de ML, on fait du SQL tous les jours, toutes mes sources de données sont consultables en SQL
 
Je garde un souvenir cuisant d'ORM de merde qui ont failli nous torpiller notre project (SAP Hybris, I'm looking at you), ça peut etre une énorme trappe à performance (j'ai souvenir de notre product list page, avec genre 200 produits (Nespresso n'a pas un gros catalogue), et l'ORM allait récursivement chercher toutes les infos de tous les produits juste pour afficher la PLP, la base Oracle faisait la gueule (on parle d'IT on premise, mais de nos jours ce serait la facture cloud qui ferait la gueule)

 
Clairement ça sert à rien SQL, le mieux c'est de mettre toutes tes données dans un gros fichier texte et quand tu as besoin de récupérer quelque chose tu écris une regex. En plus tu as des outils pour les rendre plus lisible, mais franchement moi je trouve que mes regex sont toujours hyper lisible, et tellement plus faciles à maintenir qu'une requête SQL ou un appel à un ORM...

 
C'est une chose de faire du SQL tous les jours, c'en est une autre de foutre des requêtes dégueulasses et impossible à maintenir au milieu du code métier. Un gros intérêt de l'ORM c'est d'éviter les changement de contexte, et de proposer les même garanties que le reste du code notamment en terme de types. En tant que dev C++, c'est tellement agaçant de se retrouver avec des failles béantes parce qu'on a eu la flemme d'intégrer nos requêtes à un ORM, alors que tout le reste du code est blindé par le compilateur.

Est-ce que ça vaut le coup d'utiliser des ORMs en 2025

Je garde un souvenir cuisant d'ORM de merde qui ont failli nous torpiller notre project (SAP Hybris, I'm looking at you), ça peut etre une énorme trappe à performance (j'ai souvenir de notre product list page, avec genre 200 produits (Nespresso n'a pas un gros catalogue), et l'ORM allait récursivement chercher toutes les infos de tous les produits juste pour afficher la PLP, la base Oracle faisait la gueule (on parle d'IT on premise, mais de nos jours ce serait la facture cloud qui ferait la gueule)

Bordel de merde... Je vieillis ou quoi ??  

Je voulais parler des stored procedures, pas des prepared statements.    

 
Bordel de merde... Je vieillis ou quoi ??    
 
Je voulais parler des stored procedures, pas des prepared statements.    

Fear : https://www.politico.com/news/magaz [...] s-00201552
Le seul point positif de cette interview c'est qu'il n'est pas optimiste sur leurs chances de réussir en quatre ans...

Bordel de merde... Je vieillis ou quoi ??  

Je voulais parler des stored procedures, pas des prepared statements.    

L'un des arguments des ORM, c'est que le jour où tu changes de base de données, c'est transparent au niveau de ton code, parce qu'il n'y a pas deux bases qui ont le même dialecte de SQL, même si c'est sensé être standardisé.
Et les procédures stockées, ce n'est pas standardisé du tout. Donc il faudra les réécrire complètement le jour où tu changes de base de données.
En réalité, migrer d'une base à une autre, ça n'arrive quasiment jamais. Je dis "quasiment", parce que ça m'est quand même arrivé une fois.

C'est avantageux pour tout ce qui concerne les formulaires complexes

Ca n'est pas adapté pour les requêtes qui nécessitent des performances et les gros traitements.

 
effectivement, c'est pas pareil.
Tout stored procedures c'est très années 80/90 comme approche, je sais pas qui fait encore ça...