C'est con, mais à chaque fois qu'un truc comme ça arrive, et que je tombe sur le commentaire après la modération, je peux pas m'empêcher de me demander "mais qu'est-ce qu'il y avait dans ce commentaire pour déclencher la suppression ?".
Un peu comme si je ressentais le besoin d'aller voir tous les jours ma boîte à SPAM pour regarder "qu'est-ce que j'ai encore ramassé comme merdes aujourd'hui".
Et le pire, c'est que je pense que ça fait de moi quelqu'un de normal.
'tain ! Je connaissais pas, j'écoute 3 morceaux sur YouTube, je me dis "génial, bon son, bons textes, tout y est". Et là je regarde les commentaires : le chanteur est mort y a eux mois :-(.
Bon, 17 ans de discographie à découvrir quand même, mais a priori y'en aura pas plus…
Bon, je suis à court à "Ah merde" ; mieux vaut arrêter là. En tout cas merci pour ton post, qui à défaut d'ébranler des convictions permet encore un peu plus de savoir dans quel monde on vit…
Moui, mais dans les faits, quand les données d'une ligne dépassent une certaine taille, Postgre crée à côté une table "TOAST", et ne stocke dans l'enregistrement de la table de données que le pointeur vers le bon enregistrement dans la table TOAST.
Du coup, garder un bon contrôle de la taille maximum d'un enregistrement reste utile. Et c'est plus facile avec varchar(n) qu'avec varchar.
Par ailleurs, quand tu bosses chez un éditeur, Postgre n'est peut-être qu'un des SGBDR que tu dois supporter. Et donc, tu veux pas nécessairement t'amuser à dire "alors, je fais un varchar(30) sur MSSQL, MySql, mais un varchar tout court sur Postgre".
Les esprits chagrins me diront "oui, mais sur Oracle de toute façon tu vas faire un varchar2(30)", mais il me semble que même Oracle a fini par prendre une bonne décision et dire que "OK, varchar et varchar2, c'est finalement pareil". Avec le bémol que ça fait 15 ans qu'ils disent "faites gaffe, on va finir par s'en servir pour faire autre chose".
Concernant la limite à 4000 caractères sur Oracle, a priori on peut la pousser (via un paramètre d'init) à 32767 d'après la doc, mais j'ai jamais essayé.
En tout cas, j'ai été vraiment très surpris de ce paragraphe sur varchar vs varchar(n), et ça me donne à réfléchir. Notamment sur le point qu'ils lèvent sur "potentielle non utilisation d'index si le paramètre a été reçu sous forme de varchar alors que la colonne est un char(n)". A mon sens c'est un bug qu'ils devraient corriger.
Egalement, j'avais pas conscience que "SERIAL" ne devrait plus être utilisé.
Au final, une très bonne lecture, même si je suis pas d'accord avec tout.
Avec la recharge rapide et une pause environ toutes les deux heures (ce qui est une obligation légale, certains semblent l'oublier)
S’arrêter toutes les deux heures c’est une recommandation, pas une obligation légale. Par ailleurs avec deux détenteurs du permis à bord (le cas le plus courant lors des grands départs en vacances) changer de conducteur n’implique pas un arrêt de plus de quelques secondes ou alors il est lié à un autre motif (pour manger, dérouler les jambes ou attacher mamie à un arbre).
J'ai commencé par GWBasic (parce que c'était livré en standard avec MS/DOS) et j'ai adoré le passage au Pascal. D'abord sans un vrai IDE avec Turbo Pascal 3, puis l'arrivée d'un vrai IDE avec Turbo Pascal 5.5. Et tout ce que je vois aujourd'hui (dans Eclipse/Netbeans/Intellij/VisualStudio/…) reste totalement basé sur les mêmes principes qui sont apparus à cette époque là.
Le passage au C puis au C++ s'est fait sur les outils Borland, et ça m'a bien facilité la vie. Le passage au Java a été plus douloureux.
Le pascal était une bonne transition entre le Basic et le C. On commence à voir un peu plus ce qui se passe sous le capot, sans pour autant y passer sa vie.
Je regrette surtout la gestion des chaînes de caractères, et la longueur stockée au début du tableau - au lieu de l'infâme "\0" à scanner…
Bien sûr il y a des contre exemples et GIT est un très bon cas. C’est pour ça que j’ai dit “souvent” et pas “toujours” :-).
Dans les trucs qui n’ont fait que grimper progressivement sans suivre cette fameuse courbe : Python et d’autres langages, SQL justement, …
Et il y a un autre point : quand on est dans la vague, on ne s’en rend pas forcément compte, aveuglé par l’enthousiasme. J’ai vu beaucoup d’égarement “de bonne foi”. Les routes de l’enfer sont pavées de bonnes intentions. Personne ne peut se targuer de n’avoir jamais été du mauvais côté.
Quand le DLT (Distributed Ledger Technology) avait le vent en poupe, les évangélistes étaient très nombreux, et on pouvait se sentir limite con de ne pas en être.
Ce qui sauve, c’est de se poser les bonnes questions. Mais on passe, comme toi, pour le rabat-joie de service (au mieux) ou pour le vieux con (au pire).
Le sujet pour lequel je me fais beaucoup de soucis et je suis ultra-perplexe, c’est les LLM. J’ai été le vieux con jusqu’à l’an dernier, et là je ne sais plus sur quel pied danser. Les phénomènes d’hallucination sont encore là, empêchant les scénarios les plus interessants d’être réalisables sans intervention/validation humaine, mais y a un vrai potentiel et c’est difficile de tempérer les ardeurs.
OK, OK. Je vais pas répondre à tout, mais dans le désordre…
Je n'ai pas parlé d'absence de schéma, mais d'absence de structure. Par structure, j'entends notamment voire surtout l'intégrité référentielle. Clé primaire, clé étrangère. Des concepts qui sont effectivement absents très souvent (je ne les ai pas toutes utilisées) des bases NoSQL. Et c'est bien le problème que je levais dans mon message initial, puisque c'est bien cette lacune qui fait qu'on s'est retrouvé avec beaucoup d'applications bien pourries.
Or, si il y a bien des cas particuliers où on peut s'en affranchir, c'est loin d'être un cas général. Ce qui n'a pas empêché bien des personnes de se précipiter.
Dans les orientées colonnes, les times series et les bases de données graphes, tu as un travail de modélisation de tes données au moins aussi important qu'en SQL parce que les techno t'y obligent
Si le fait de devoir déclarer les colonnes tu trouves que ça implique "un travail de modélisation au moins aussi important", je suis en total désaccord. Un modèle entité/relation c'est pas que les tables et les colonnes, leur type et basta. Bis repetitum : clé primaire, clé secondaire, mais aussi contraintes d'unicité, clauses de contrôles, gestion des suppressions en cascade, etc.
Les outils NoSQL que j'ai utilisé sont effectivement très orientés montée à l'échelle horizontale. Ils sont pensés pour répondre à une problématique de volumétrie. Problématique qui est extrêmement rare en dehors de cas d'usages peu courants.
Petit partage d'expérience : dans le domaine bancaire, entre grosso modo 2010 et 2018, tout le monde a été vers les distributions Hadoop, et tout particulièrement MapR et HortonWorks. A partir de 2018, elles ont réalisées que "ah ben oups mais en fait on a pas besoin de ces monstres". Aujourd'hui, on décommissionne à tour de bras pour :
- remettre de la base relationnelle classique
- compléter avec du stockage brut (compatible S3)
C'est un mouvement général, et d'ailleurs ces deux sociétés ont connu des difficultés financières majeures et ont été rachetées par des spécialistes du "cimetière logiciel", qui consiste surtout à récupérer la base client et non pas le produit.
Avant cette mort lente, on a investi des dizaines de millions d'euros, on a pondu des monstres (et je pèse mes mots) où pour gérer quelques millions d'enregistrement qui auraient fait l'objet d'un pauvre SELECT/UPDATE, il fallait écrire des traitements à base de Spark ou de Map/Reduce. Et par dessus tout ça, on disait "oui, mais regarde : on peut quand même faire du SQL avec Drill". Sauf que sous le capot, c'était une usine à gaz sans nom, et on a vu revenir les batchs qui prennent 8 heures (véridique). Une fois remigré sur du Oracle ou du Postgre, pif paf on revenait à quelques secondes voire minutes au pire. En 10 fois moins de lignes de code.
J'ai entendu dire plein de fois : "c'est parce qu'on a pas les bonnes ressources". Mais on a JAMAIS réussi à avoir les bonnes ressources, la plateforme n'a jamais été stabilisée, et aujourd'hui, c'est encore un nid à bug. Dès que quelque chose déconne, on a de fortes chances de devoir s'en remettre à l'éditeur, seul à pouvoir nous débloquer. Le genre de situation qu'on croisait une fois tous les 5 ans sur les bases relationnelles, avec pourtant une base applicative 100 fois supérieure.
Tu mélange beaucoup de choses… NoSQL c'est des technologies de base de données, BigData c'est mot-valise qui a était bien trop marketé pour garder encore sont sens de jeu de données trop gros pour entrer dans les bases de données standards
Cet amalgame, il est le résultat de la stratégie de communication des sociétés qui ont poussé les moteurs NoSQL. Pour avoir eu pas mal d'interactions avec des commerciaux (notamment MongoDB), c'était un peu le premier truc qui sortait de leur bouche.
D'ailleurs petite anecdote : à l'époque de mes premières rencontres (vers 2017 je pense), j'ai naïvement demandé : "mais comment on fait pour pouvoir utiliser nos outils existants de reporting/dataviz ?". Réponse : "facile : il suffit de créer une base PostgreSQL en frontal et de définir des foreign tables". Véridique… Aujourd'hui, y'a un peu plus de connecteurs natifs, mais c'est pas encore la joie.
(depuis 20 l'évolution étant ce qu'elle est les bases de données classiques ont considérablement augmentée leur capacité et une partie des techniques BigData sont devenues classiques comme le partitionnement).
Alors, là, je m'étouffe. Le partitionnement, c'est un concept qui existait déjà sur Mainframe IBM dans les années 70. Sur Oracle, j'arrive même pas à me souvenir depuis quand ça existe. Sur PostgreSQL, c'est effectivement récent, mais il y avait déjà des solutions de contournement.
Par contre, ce n'est pas le même partitionnement. C'est uniquement orienté stockage, et pas répartition de l'exécution des requêtes. Mais encore une fois… quand est-ce que c'est vraiment nécessaire ? Et quand ça l'est, je suis le premier à promouvoir d'autres solutions que de la base relationnelle.
C'est très discuté parce que relativement peu de techno suivent véritablement cette courbe et quand elles le suivent on parle de période allant de quelques années à 10 ans. Relancer continuellement dessus 20 ans après n'a pas de sens.
Là désolé, je comprends pas. "Relancer continuellement dessus 20 ans après n'a pas de ses" ? De quoi parles-tu ? "Peu de techno suivent véritablement cette courbe" ? On vit pas dans le même monde. Blockchain et Smartcontracts, ça te parle ? Microservices ? On peut lister les frameworks Web ?
Cette manière de tout amalgamer pour rejeter c'est un peu comme si je disais que SQL c'était vraiment nul parce que les ORM c'est de la merde.
Tiens, juste histoire de prendre le contre pied. Les ORMs j'ai beaucoup lutté (avec moi-même autant qu'avec les autres) pour en obtenir un usage raisonné. Très bien pour le CRUD, très dangereux pour des process complexes où une gestion de la transaction "à la main" s'avère moins casse-gueule.
Et bien c'est la même chose pour le NoSQL. Aujourd'hui je lutte contre le réflexe "on va tout mettre dans MongoDB / Cassandra / ". Mais j'hésite pas une seconde si je pense que c'est le bon outil. Mais je vais y réfléchir vraiment longtemps. Parce que souvent les équipes se trompent sur leur besoin en terme volumétries.
On pourrait parler aussi de dette/avoir, en plus du classique passif/actif. C'est également dans le sens comptable cela dit.
Dette dans le sens où le fait d'avoir mis en place de l'IA dans une voiture rend la compagnie (potentiellement) redevable auprès de ses clients, dès lors qu'il faut procéder régulièrement à des campagnes de rappel coûteuses, ou faire face à des procès.
Tu remarqueras que je n'ai pas "disqualifié" la technologie. Mais le fait est que durant plusieurs années, ça a été utilisé par défaut juste parce que c'était neuf, c'était beau, c'était forcément bien. Et oui, ça correspond parfaitement au "Hype Cycle" décrit par Gartner ou Forrester. Mais c'est bien à ça qu'on pense quand on parle d'effet de mode en informatique.
Pour ceux qui ne connaissent pas, c'est une théorie (souvent vérifiée par la réalité) qui dit que pour toute nouvelle technologie, il y a d'abord une phase ascendante (dans l'usage/engouement) très importante (l'effet "hype") puis une phase de descente ("la désillusion") tout aussi raide, puis à nouveau une courbe ascendante beaucoup plus douce - l'âge de raison pourrait-on dire.
C'est exactement ce qu'on a observé avec NoSQL. Pour une raison simple : ça correspond à la psychologie humaine et l'effet boule de neige. Y'a un gars qui a une bonne idée (on va dire un mec chez Google qui pond une lib). Ca se répand assez rapidement ("si Google utilise ça, il faut faire pareil !"). Ensuite, les gens se rendent compte que "ben non, en fait j'ai pas besoin de ça, c'est juste ultra compliqué pour rien dans mon cas". Puis finalement les personnes qui en ont vraiment l'usage rendent la techno pérenne.
Et oui aussi, je mélange NoSQL et BigData. C'est vrai que ce sont deux technos bien différentes, et avec des objectifs différents, mais avec la même approche "fuck the structure, on verra plus tard".
en éliminant la rigidité des bases de données relationnelles, permettant de livrer plus rapidement en s'économisant des contraintes liées aux bases relationnelles
Les bases relationnelles et leurs "contraintes", leur "rigidité", ont fait suite au stockage fichier simple (type VSAM), pour répondre à une problématique récurrente : on se retrouvait systématiquement dans des situations d'incohérence, parce que le code au-dessus des données ne gérait pas bien l'intégrité.
Donc, pouf, on crée les bases relationnelles et le SQL.
Et 20/30 ans plus tard, des p'tits malins se disent "ouais, trop pénible les contraintes de structure, nous on va tout péter, pas de règle, liberté totale".
Alors, c'est venu de vrais besoins dans des situations bien particulières. Mais comme tout effet de mode, on s'est retrouvé à voir du MongoDB ou du Cassandra ou du Hadoop pour gérer des bases ultra classiques, bien structurées. Mais au lieu que cette structure soit garantie par le moteur de stockage, tout s'est retrouvé déporté dans le code applicatif, qui évidemment ne fait pas le taf, laisse passer plein de merdes, et on se retrouve avec des données vérolées jusqu'à l'os.
"Ouiiiii, mais c'est pour faire du prototypage". Mais bien sûr. Et le prototype, y'a toujours un gars qui va dire qu'il fait le taf, donc faut le pousser jusqu'à la prod. Pourquoi réécrire quelque chose qui marche après tout ? Et hop, une appli moisie en production. Le stagiaire est content, mais le mainteneur qui reprend l'appli 4 ans plus tard pleure toutes les larmes de son corps.
Bref : NoSQL <==> Prudence, et bien y réfléchir à 2 fois, à 3 fois, à 4 fois.
Et comme dit plus haut, les serveurs SQL ont bien évolué. Ils permettent de gérer le meilleur des 2 mondes, ont une connectivité largement supérieure (merci odbc/jdbc/…), ne sont jamais limités à "JSON only".
C'est rigolo, dans son README.md, à la question "est-ce que ça facilite la migration de Linux vers Windows ?", il répond par la négative parce que "ça reste Linux en dessous".
Je pense que ça facilite quand même la transition en rendant l'interface plus familière.
Par contre, le fait que ce soit une vieille interface (celle de Windows 7 donc), ça doit sonner comme un retour arrière, et peut-être renvoyer une mauvaise image de notre OS favori.
Posté par Dring .
En réponse au journal J'ai une idée de cadeau....
Évalué à 2.
Dernière modification le 19 décembre 2023 à 07:09.
Ok le smartphone c’est trop petit. Mais une tablette ? Si le destinataire n’arrive pas à lire dessus même paramétrée avec des gros caractères, elle arrivera quand même à distinguer l’image de la photo, et ce quel que soit le support ?
Sinon j’aime bien le truc e-ink mentionné au dessous mais j’ai jamais trop regardé le côté écologique de l’e-ink. Peu de conso électrique à l’usage, donc a priori c’est cool ; quid de la fabrication et du recyclage ?
Quand c’était la mode des cadres photo numérique, j’en ai vu fleurir un peu partout.
Aujourd’hui ils sont tous dans des placards :-(. Voire à la benne.
Le mieux à mon avis c’est d’envoyer une photo par mail/whatsapp. Et les destinataires la regarde sur leur mobile/tablette/PC. Ça marche très bien avec les grands parents.
Il y a 20 ans (déjà !) quand le promoteur avec lequel j'avais signé sur plan pour un appartement a livré l'immeuble avec plusieurs mois de retard, il a invoqué la force majeure liée aux intempéries.
J'avais galéré pour retrouver des données prouvant que "non, il n'y a pas eu d'intempéries imprévisibles justifiant un tel retard", et j'avais dû payer pour avoir le nécessaire.
Là j'ai l'impression qu'avec ce que Météo France publie j'aurai pu me débrouiller sans monnaie débourser. Donc c'est déjà un pas.
Après, j'ai quand même l'impression de financer Météo France avec mes impôts et donc je ne comprends pas que les données de prévision ne soient pas également disponibles via API sans coût, mais je dois passer à côté de quelque chose quand j'entends parler de "business model" dans d'autres commentaires.
Donc, avec un jeu de données aléatoire, on voit que la courbe d’auto-évaluation est pratiquement plate.
Ce qui est normal, et est induit par l’algo de génération des valeurs aléatoires qui va chercher à faire une répartition statistique équilibrée. C’est le but de la plupart de ces algos.
Du coup le graphique se lit comme suit : quel que soit leur résultat réel, pour chaque quartile on va se retrouver à la même auto-évaluation moyenne.
Ce qui en soit dans la vraie vie serait une découverte incroyable. La courbe de l’étude initiale elle dit autre chose : elle suit la courbe initiale en s’en éloignant aux deux extrémités.
Bref à mon sens c’est la critique qui est à côté de la plaque, pas l’étude initiale à qui on peut seulement reprocher de s’appuyer sur un graphique peu lisible.
L’erreur principale étant de penser que des données « aléatoires » (qui donc ne le sont jamais vraiment) étaient forcément neutres en terme de signification.
Je me demande si je suis le seul à aller encore plus loin dans le détournement de raclette :
inclusion de fromages non réglementaires (camembert, voire une larme de chèvre sur le fromage à raclette)
inclusion de légumes (bon, de fruits si vous préférez), là aussi directement dans le poêlon (tomate, courgette)
crème fraîche powa! Bien épaisse, genre d'Isigny
La seule règle étant : si ça fait plaisir, pourquoi pas ? On essaye de pas tout faire en même temps, sinon on a plus l'impression de manger une raclette, mais ça fait partie des variations qu'on s'autorise.
J'ai un oncle qui mange du pain avec sa raclette (et non, sans salade). Ca fait bizarre, mais là encore si il aime, pourquoi pas ? Il est devenu savoyard il y a près de 40 ans - et malgré cet écart il semble s'être bien fait accepté par les autochtones ; je n'ai vu personne lui jeter des cailloux dans son petit village de montagne.
[^] # Re: New
Posté par Dring . En réponse à la dépêche Transformer une photo en BD avec le filtre Comicbook de G'MIC. Évalué à 3.
C'est con, mais à chaque fois qu'un truc comme ça arrive, et que je tombe sur le commentaire après la modération, je peux pas m'empêcher de me demander "mais qu'est-ce qu'il y avait dans ce commentaire pour déclencher la suppression ?".
Un peu comme si je ressentais le besoin d'aller voir tous les jours ma boîte à SPAM pour regarder "qu'est-ce que j'ai encore ramassé comme merdes aujourd'hui".
Et le pire, c'est que je pense que ça fait de moi quelqu'un de normal.
[^] # Re: Bonne musique Zaktuelle ?
Posté par Dring . En réponse au journal Tiendrons-nous jusqu’à demain ?. Évalué à 3. Dernière modification le 14 janvier 2024 à 18:34.
'tain ! Je connaissais pas, j'écoute 3 morceaux sur YouTube, je me dis "génial, bon son, bons textes, tout y est". Et là je regarde les commentaires : le chanteur est mort y a eux mois :-(.
Bon, 17 ans de discographie à découvrir quand même, mais a priori y'en aura pas plus…
(à propos des Cowboys Fringuants)
# Heureusement qu'en France...
Posté par Dring . En réponse au journal Où il est question de données personnelles. Évalué à 10.
…la poste nationale ne ferait jamais rien de ce type…
Ah merde : https://www.francetvinfo.fr/economie/cash-investigation-quand-la-poste-vend-vos-donnees-personnelles_1109993.html.
…bon, mais au moins nos amis Européens sont mieux lotis que nous…
Ah merde : https://www.rfi.fr/fr/emission/20190111-autriche-scandale-poste
Bon, je suis à court à "Ah merde" ; mieux vaut arrêter là. En tout cas merci pour ton post, qui à défaut d'ébranler des convictions permet encore un peu plus de savoir dans quel monde on vit…
[^] # Re: varchar(n)
Posté par Dring . En réponse au journal PostgreSQL : ne faites pas ça !. Évalué à 3.
Merde, trop long à modifier. L'histoire d'index, c'est pour char vs char(n).
[^] # Re: varchar(n)
Posté par Dring . En réponse au journal PostgreSQL : ne faites pas ça !. Évalué à 6.
Moui, mais dans les faits, quand les données d'une ligne dépassent une certaine taille, Postgre crée à côté une table "TOAST", et ne stocke dans l'enregistrement de la table de données que le pointeur vers le bon enregistrement dans la table TOAST.
Du coup, garder un bon contrôle de la taille maximum d'un enregistrement reste utile. Et c'est plus facile avec varchar(n) qu'avec varchar.
Par ailleurs, quand tu bosses chez un éditeur, Postgre n'est peut-être qu'un des SGBDR que tu dois supporter. Et donc, tu veux pas nécessairement t'amuser à dire "alors, je fais un varchar(30) sur MSSQL, MySql, mais un varchar tout court sur Postgre".
Les esprits chagrins me diront "oui, mais sur Oracle de toute façon tu vas faire un varchar2(30)", mais il me semble que même Oracle a fini par prendre une bonne décision et dire que "OK, varchar et varchar2, c'est finalement pareil". Avec le bémol que ça fait 15 ans qu'ils disent "faites gaffe, on va finir par s'en servir pour faire autre chose".
Concernant la limite à 4000 caractères sur Oracle, a priori on peut la pousser (via un paramètre d'init) à 32767 d'après la doc, mais j'ai jamais essayé.
En tout cas, j'ai été vraiment très surpris de ce paragraphe sur varchar vs varchar(n), et ça me donne à réfléchir. Notamment sur le point qu'ils lèvent sur "potentielle non utilisation d'index si le paramètre a été reçu sous forme de varchar alors que la colonne est un char(n)". A mon sens c'est un bug qu'ils devraient corriger.
Egalement, j'avais pas conscience que "SERIAL" ne devrait plus être utilisé.
Au final, une très bonne lecture, même si je suis pas d'accord avec tout.
[^] # Re: Évolution de l'aviation
Posté par Dring . En réponse au journal L'aviation a-t-elle un avenir ?. Évalué à 8.
S’arrêter toutes les deux heures c’est une recommandation, pas une obligation légale. Par ailleurs avec deux détenteurs du permis à bord (le cas le plus courant lors des grands départs en vacances) changer de conducteur n’implique pas un arrêt de plus de quelques secondes ou alors il est lié à un autre motif (pour manger, dérouler les jambes ou attacher mamie à un arbre).
[^] # Re: prends soin de toi.
Posté par Dring . En réponse au journal J’ai fait fuir les voleurs (trop forte !?). Évalué à 3.
<mode mauvais_gout="on">
Ah oui, je vois le genre : "oh tu as l'air traumatisée ; pas de soucis je vais dormir dans ton lit cette nuit si ça peut te rassurer".
Et quand ça finit par passer, tu réenfiles ta cagoule de cambrioleur ?
[^] # Re: Un petit hommage mastonodique (en anglais)
Posté par Dring . En réponse à la dépêche Décès de Niklaus Wirth, auteur de nombreux langages de programmation. Évalué à 4.
J'ai commencé par GWBasic (parce que c'était livré en standard avec MS/DOS) et j'ai adoré le passage au Pascal. D'abord sans un vrai IDE avec Turbo Pascal 3, puis l'arrivée d'un vrai IDE avec Turbo Pascal 5.5. Et tout ce que je vois aujourd'hui (dans Eclipse/Netbeans/Intellij/VisualStudio/…) reste totalement basé sur les mêmes principes qui sont apparus à cette époque là.
Le passage au C puis au C++ s'est fait sur les outils Borland, et ça m'a bien facilité la vie. Le passage au Java a été plus douloureux.
Le pascal était une bonne transition entre le Basic et le C. On commence à voir un peu plus ce qui se passe sous le capot, sans pour autant y passer sa vie.
Je regrette surtout la gestion des chaînes de caractères, et la longueur stockée au début du tableau - au lieu de l'infâme "\0" à scanner…
[^] # Re: Tout se paye un jour ou l'autre
Posté par Dring . En réponse au journal Tour d'horizon de l'état des bases NoSQL. Évalué à 6.
Bien sûr il y a des contre exemples et GIT est un très bon cas. C’est pour ça que j’ai dit “souvent” et pas “toujours” :-).
Dans les trucs qui n’ont fait que grimper progressivement sans suivre cette fameuse courbe : Python et d’autres langages, SQL justement, …
Et il y a un autre point : quand on est dans la vague, on ne s’en rend pas forcément compte, aveuglé par l’enthousiasme. J’ai vu beaucoup d’égarement “de bonne foi”. Les routes de l’enfer sont pavées de bonnes intentions. Personne ne peut se targuer de n’avoir jamais été du mauvais côté.
Quand le DLT (Distributed Ledger Technology) avait le vent en poupe, les évangélistes étaient très nombreux, et on pouvait se sentir limite con de ne pas en être.
Ce qui sauve, c’est de se poser les bonnes questions. Mais on passe, comme toi, pour le rabat-joie de service (au mieux) ou pour le vieux con (au pire).
Le sujet pour lequel je me fais beaucoup de soucis et je suis ultra-perplexe, c’est les LLM. J’ai été le vieux con jusqu’à l’an dernier, et là je ne sais plus sur quel pied danser. Les phénomènes d’hallucination sont encore là, empêchant les scénarios les plus interessants d’être réalisables sans intervention/validation humaine, mais y a un vrai potentiel et c’est difficile de tempérer les ardeurs.
[^] # Re: Tout se paye un jour ou l'autre
Posté par Dring . En réponse au journal Tour d'horizon de l'état des bases NoSQL. Évalué à 5.
OK, OK. Je vais pas répondre à tout, mais dans le désordre…
Je n'ai pas parlé d'absence de schéma, mais d'absence de structure. Par structure, j'entends notamment voire surtout l'intégrité référentielle. Clé primaire, clé étrangère. Des concepts qui sont effectivement absents très souvent (je ne les ai pas toutes utilisées) des bases NoSQL. Et c'est bien le problème que je levais dans mon message initial, puisque c'est bien cette lacune qui fait qu'on s'est retrouvé avec beaucoup d'applications bien pourries.
Or, si il y a bien des cas particuliers où on peut s'en affranchir, c'est loin d'être un cas général. Ce qui n'a pas empêché bien des personnes de se précipiter.
Si le fait de devoir déclarer les colonnes tu trouves que ça implique "un travail de modélisation au moins aussi important", je suis en total désaccord. Un modèle entité/relation c'est pas que les tables et les colonnes, leur type et basta. Bis repetitum : clé primaire, clé secondaire, mais aussi contraintes d'unicité, clauses de contrôles, gestion des suppressions en cascade, etc.
Les outils NoSQL que j'ai utilisé sont effectivement très orientés montée à l'échelle horizontale. Ils sont pensés pour répondre à une problématique de volumétrie. Problématique qui est extrêmement rare en dehors de cas d'usages peu courants.
Petit partage d'expérience : dans le domaine bancaire, entre grosso modo 2010 et 2018, tout le monde a été vers les distributions Hadoop, et tout particulièrement MapR et HortonWorks. A partir de 2018, elles ont réalisées que "ah ben oups mais en fait on a pas besoin de ces monstres". Aujourd'hui, on décommissionne à tour de bras pour :
- remettre de la base relationnelle classique
- compléter avec du stockage brut (compatible S3)
C'est un mouvement général, et d'ailleurs ces deux sociétés ont connu des difficultés financières majeures et ont été rachetées par des spécialistes du "cimetière logiciel", qui consiste surtout à récupérer la base client et non pas le produit.
Avant cette mort lente, on a investi des dizaines de millions d'euros, on a pondu des monstres (et je pèse mes mots) où pour gérer quelques millions d'enregistrement qui auraient fait l'objet d'un pauvre SELECT/UPDATE, il fallait écrire des traitements à base de Spark ou de Map/Reduce. Et par dessus tout ça, on disait "oui, mais regarde : on peut quand même faire du SQL avec Drill". Sauf que sous le capot, c'était une usine à gaz sans nom, et on a vu revenir les batchs qui prennent 8 heures (véridique). Une fois remigré sur du Oracle ou du Postgre, pif paf on revenait à quelques secondes voire minutes au pire. En 10 fois moins de lignes de code.
J'ai entendu dire plein de fois : "c'est parce qu'on a pas les bonnes ressources". Mais on a JAMAIS réussi à avoir les bonnes ressources, la plateforme n'a jamais été stabilisée, et aujourd'hui, c'est encore un nid à bug. Dès que quelque chose déconne, on a de fortes chances de devoir s'en remettre à l'éditeur, seul à pouvoir nous débloquer. Le genre de situation qu'on croisait une fois tous les 5 ans sur les bases relationnelles, avec pourtant une base applicative 100 fois supérieure.
Cet amalgame, il est le résultat de la stratégie de communication des sociétés qui ont poussé les moteurs NoSQL. Pour avoir eu pas mal d'interactions avec des commerciaux (notamment MongoDB), c'était un peu le premier truc qui sortait de leur bouche.
D'ailleurs petite anecdote : à l'époque de mes premières rencontres (vers 2017 je pense), j'ai naïvement demandé : "mais comment on fait pour pouvoir utiliser nos outils existants de reporting/dataviz ?". Réponse : "facile : il suffit de créer une base PostgreSQL en frontal et de définir des foreign tables". Véridique… Aujourd'hui, y'a un peu plus de connecteurs natifs, mais c'est pas encore la joie.
Alors, là, je m'étouffe. Le partitionnement, c'est un concept qui existait déjà sur Mainframe IBM dans les années 70. Sur Oracle, j'arrive même pas à me souvenir depuis quand ça existe. Sur PostgreSQL, c'est effectivement récent, mais il y avait déjà des solutions de contournement.
Par contre, ce n'est pas le même partitionnement. C'est uniquement orienté stockage, et pas répartition de l'exécution des requêtes. Mais encore une fois… quand est-ce que c'est vraiment nécessaire ? Et quand ça l'est, je suis le premier à promouvoir d'autres solutions que de la base relationnelle.
Là désolé, je comprends pas. "Relancer continuellement dessus 20 ans après n'a pas de ses" ? De quoi parles-tu ? "Peu de techno suivent véritablement cette courbe" ? On vit pas dans le même monde. Blockchain et Smartcontracts, ça te parle ? Microservices ? On peut lister les frameworks Web ?
Tiens, juste histoire de prendre le contre pied. Les ORMs j'ai beaucoup lutté (avec moi-même autant qu'avec les autres) pour en obtenir un usage raisonné. Très bien pour le CRUD, très dangereux pour des process complexes où une gestion de la transaction "à la main" s'avère moins casse-gueule.
Et bien c'est la même chose pour le NoSQL. Aujourd'hui je lutte contre le réflexe "on va tout mettre dans MongoDB / Cassandra / ". Mais j'hésite pas une seconde si je pense que c'est le bon outil. Mais je vais y réfléchir vraiment longtemps. Parce que souvent les équipes se trompent sur leur besoin en terme volumétries.
[^] # Re: Mauvaise traduction
Posté par Dring . En réponse au lien L'intelligence artificielle est un passif. Évalué à 2.
On pourrait parler aussi de dette/avoir, en plus du classique passif/actif. C'est également dans le sens comptable cela dit.
Dette dans le sens où le fait d'avoir mis en place de l'IA dans une voiture rend la compagnie (potentiellement) redevable auprès de ses clients, dès lors qu'il faut procéder régulièrement à des campagnes de rappel coûteuses, ou faire face à des procès.
[^] # Re: Tout se paye un jour ou l'autre
Posté par Dring . En réponse au journal Tour d'horizon de l'état des bases NoSQL. Évalué à 4.
Tu remarqueras que je n'ai pas "disqualifié" la technologie. Mais le fait est que durant plusieurs années, ça a été utilisé par défaut juste parce que c'était neuf, c'était beau, c'était forcément bien. Et oui, ça correspond parfaitement au "Hype Cycle" décrit par Gartner ou Forrester. Mais c'est bien à ça qu'on pense quand on parle d'effet de mode en informatique.
Pour ceux qui ne connaissent pas, c'est une théorie (souvent vérifiée par la réalité) qui dit que pour toute nouvelle technologie, il y a d'abord une phase ascendante (dans l'usage/engouement) très importante (l'effet "hype") puis une phase de descente ("la désillusion") tout aussi raide, puis à nouveau une courbe ascendante beaucoup plus douce - l'âge de raison pourrait-on dire.
C'est exactement ce qu'on a observé avec NoSQL. Pour une raison simple : ça correspond à la psychologie humaine et l'effet boule de neige. Y'a un gars qui a une bonne idée (on va dire un mec chez Google qui pond une lib). Ca se répand assez rapidement ("si Google utilise ça, il faut faire pareil !"). Ensuite, les gens se rendent compte que "ben non, en fait j'ai pas besoin de ça, c'est juste ultra compliqué pour rien dans mon cas". Puis finalement les personnes qui en ont vraiment l'usage rendent la techno pérenne.
Et oui aussi, je mélange NoSQL et BigData. C'est vrai que ce sont deux technos bien différentes, et avec des objectifs différents, mais avec la même approche "fuck the structure, on verra plus tard".
# Tout se paye un jour ou l'autre
Posté par Dring . En réponse au journal Tour d'horizon de l'état des bases NoSQL. Évalué à 10.
Les bases relationnelles et leurs "contraintes", leur "rigidité", ont fait suite au stockage fichier simple (type VSAM), pour répondre à une problématique récurrente : on se retrouvait systématiquement dans des situations d'incohérence, parce que le code au-dessus des données ne gérait pas bien l'intégrité.
Donc, pouf, on crée les bases relationnelles et le SQL.
Et 20/30 ans plus tard, des p'tits malins se disent "ouais, trop pénible les contraintes de structure, nous on va tout péter, pas de règle, liberté totale".
Alors, c'est venu de vrais besoins dans des situations bien particulières. Mais comme tout effet de mode, on s'est retrouvé à voir du MongoDB ou du Cassandra ou du Hadoop pour gérer des bases ultra classiques, bien structurées. Mais au lieu que cette structure soit garantie par le moteur de stockage, tout s'est retrouvé déporté dans le code applicatif, qui évidemment ne fait pas le taf, laisse passer plein de merdes, et on se retrouve avec des données vérolées jusqu'à l'os.
"Ouiiiii, mais c'est pour faire du prototypage". Mais bien sûr. Et le prototype, y'a toujours un gars qui va dire qu'il fait le taf, donc faut le pousser jusqu'à la prod. Pourquoi réécrire quelque chose qui marche après tout ? Et hop, une appli moisie en production. Le stagiaire est content, mais le mainteneur qui reprend l'appli 4 ans plus tard pleure toutes les larmes de son corps.
Bref : NoSQL <==> Prudence, et bien y réfléchir à 2 fois, à 3 fois, à 4 fois.
Et comme dit plus haut, les serveurs SQL ont bien évolué. Ils permettent de gérer le meilleur des 2 mondes, ont une connectivité largement supérieure (merci odbc/jdbc/…), ne sont jamais limités à "JSON only".
[^] # Re: Facilite la transition
Posté par Dring . En réponse au lien Thème pour KDE Plasma pour reproduire look et feel de Windows 7. Évalué à 3.
Mea maxima culpa ! Windows vers Linux biens sûr.
# Facilite la transition
Posté par Dring . En réponse au lien Thème pour KDE Plasma pour reproduire look et feel de Windows 7. Évalué à 5.
C'est rigolo, dans son README.md, à la question "est-ce que ça facilite la migration de Linux vers Windows ?", il répond par la négative parce que "ça reste Linux en dessous".
Je pense que ça facilite quand même la transition en rendant l'interface plus familière.
Par contre, le fait que ce soit une vieille interface (celle de Windows 7 donc), ça doit sonner comme un retour arrière, et peut-être renvoyer une mauvaise image de notre OS favori.
[^] # Re: Pas pérenne…
Posté par Dring . En réponse au journal J'ai une idée de cadeau.... Évalué à 2. Dernière modification le 19 décembre 2023 à 07:09.
Ok le smartphone c’est trop petit. Mais une tablette ? Si le destinataire n’arrive pas à lire dessus même paramétrée avec des gros caractères, elle arrivera quand même à distinguer l’image de la photo, et ce quel que soit le support ?
Sinon j’aime bien le truc e-ink mentionné au dessous mais j’ai jamais trop regardé le côté écologique de l’e-ink. Peu de conso électrique à l’usage, donc a priori c’est cool ; quid de la fabrication et du recyclage ?
[^] # Re: Lol
Posté par Dring . En réponse au journal le plus grand scandale sanitaire de tous les temps, c'est maintenant !. Évalué à 10.
Donc…
- tu ne donnes pas les sources pour les protéger
- mais tout le monde peut les trouver en cherchant
Euh…
# Pas pérenne…
Posté par Dring . En réponse au journal J'ai une idée de cadeau.... Évalué à 3.
Quand c’était la mode des cadres photo numérique, j’en ai vu fleurir un peu partout.
Aujourd’hui ils sont tous dans des placards :-(. Voire à la benne.
Le mieux à mon avis c’est d’envoyer une photo par mail/whatsapp. Et les destinataires la regarde sur leur mobile/tablette/PC. Ça marche très bien avec les grands parents.
[^] # Re: Cette recette est naze !
Posté par Dring . En réponse au journal recette de mousse au chocolat. Évalué à 2.
Il va me falloir un cobaye. Tu es volontaire ? :-)
# C'est déjà utile
Posté par Dring . En réponse au lien La météo de Méteo France en open data !. Évalué à 7.
Il y a 20 ans (déjà !) quand le promoteur avec lequel j'avais signé sur plan pour un appartement a livré l'immeuble avec plusieurs mois de retard, il a invoqué la force majeure liée aux intempéries.
J'avais galéré pour retrouver des données prouvant que "non, il n'y a pas eu d'intempéries imprévisibles justifiant un tel retard", et j'avais dû payer pour avoir le nécessaire.
Là j'ai l'impression qu'avec ce que Météo France publie j'aurai pu me débrouiller sans monnaie débourser. Donc c'est déjà un pas.
Après, j'ai quand même l'impression de financer Météo France avec mes impôts et donc je ne comprends pas que les données de prévision ne soient pas également disponibles via API sans coût, mais je dois passer à côté de quelque chose quand j'entends parler de "business model" dans d'autres commentaires.
# Cette recette est naze !
Posté par Dring . En réponse au journal recette de mousse au chocolat. Évalué à 3.
Il n'y a ni fromage, ni pommes de terre, ni charcuterie ! LinuxFR, ça devient vraiment n'importe quoi !
[^] # Re: La malédiction des JO
Posté par Dring . En réponse au journal Non mais MERDE !. Évalué à 10.
Ils ont eu lieu quand les JOs en Palestine ?
[^] # Re: Total manque de respect
Posté par Dring . En réponse au journal Il est temps que la communauté internationale fasse un choix. Évalué à 2.
Belle découverte ; merci !
# Interessant mais ne remet pas en cause le papier initial
Posté par Dring . En réponse au lien The Dunning-Kruger Effect is Autocorrelation. Évalué à 2.
Donc, avec un jeu de données aléatoire, on voit que la courbe d’auto-évaluation est pratiquement plate.
Ce qui est normal, et est induit par l’algo de génération des valeurs aléatoires qui va chercher à faire une répartition statistique équilibrée. C’est le but de la plupart de ces algos.
Du coup le graphique se lit comme suit : quel que soit leur résultat réel, pour chaque quartile on va se retrouver à la même auto-évaluation moyenne.
Ce qui en soit dans la vraie vie serait une découverte incroyable. La courbe de l’étude initiale elle dit autre chose : elle suit la courbe initiale en s’en éloignant aux deux extrémités.
Bref à mon sens c’est la critique qui est à côté de la plaque, pas l’étude initiale à qui on peut seulement reprocher de s’appuyer sur un graphique peu lisible.
L’erreur principale étant de penser que des données « aléatoires » (qui donc ne le sont jamais vraiment) étaient forcément neutres en terme de signification.
# Total manque de respect
Posté par Dring . En réponse au journal Il est temps que la communauté internationale fasse un choix. Évalué à 4.
Je me demande si je suis le seul à aller encore plus loin dans le détournement de raclette :
La seule règle étant : si ça fait plaisir, pourquoi pas ? On essaye de pas tout faire en même temps, sinon on a plus l'impression de manger une raclette, mais ça fait partie des variations qu'on s'autorise.
J'ai un oncle qui mange du pain avec sa raclette (et non, sans salade). Ca fait bizarre, mais là encore si il aime, pourquoi pas ? Il est devenu savoyard il y a près de 40 ans - et malgré cet écart il semble s'être bien fait accepté par les autochtones ; je n'ai vu personne lui jeter des cailloux dans son petit village de montagne.