Les "tableaux automatiques" d'Excel ont pour eux des belles qualités (la ligne de titre qui vient remplacer les A, B, C, … dans l'entête pour gratter une ligne, le formattage automatique notamment pour l'alternance des lignes, …), mais aussi des défauts très chiants.
Tu perds énormément en souplesse, et sur les tableaux très larges (genre > 30 colonnes) où tu mets plusieurs niveaux d'entêtes pour t'y retrouver, ben c'est impossible de faire un truc qui tienne la route.
Pareil si tu fais des sous-totaux sans passer par un tableau croisé dynamique. Ou alors je m'y prends très mal ?
Donc parfois ça me manque, souvent ça m'évite de faire un tableau automatique qui ensuite va me pourrir la vie. 50/50.
Moi le truc qui me ferait rêver, c'est de sortir de "un tableau posé sous un autre tableau dans la même page doit absolument avoir les mêmes largeurs de colonnes, à moins de faire des bidouilles dégueulasses". Ce que Excel ne sait pas faire non plus.
Quand on voit certaines opérations esthétiques, on comprend que tout le monde n’a pas la même lecture du serment d’Hypocrate.
Et filer à l’étranger pour te faire charcuter parce que chez toi c’est pas possible…
Bref tout ça pour éviter de sombrer dans la naïveté excessive : il y a eu, il y a et il y aura encore des cas de grand portenawak.
Perso j’ai du mal à trancher par exemple sur l’autorisation de changement de sexe sur des mineurs. D’un côté c’est le risque de concrétiser un choix immature aux conséquences dramatiques. De l’autre c’est laisser une personne dans la souffrance. Et se dire “si un médecin a accepté de le faire, il avait forcément blindé le truc avant” ben moi j’y arrive pas.
Ben c’est un peu la somme des composants, et de chaque licence applicable, qui va permettre de se prononcer.
Si je parle d’un système libre, on s’attend bien à ce que le kernel ET les logiciels rajoutés par dessus soient libres.
Si je parle d’un ordiphone libre je vais aussi regarder si les plans du matériel sont libres, si le microcode est libre.
La réponse n’est pas toujours évidente et peut évidemment être débattue, mais je pense qu’on a depuis longtemps collectivement décidé que si, on peut parler de libre pour un écosystème, une plateforme ou n’importe quoi d’autre qui est composé de plusieurs choses.
Après il faut s’entendre sur les frontières, sur ce qu’on inclus ou pas dans cet écosystème.
Posté par Dring .
En réponse au journal snap : de pire en pire..
Évalué à 3.
Dernière modification le 02 février 2024 à 15:03.
J'ai l'impression que comme souvent, y'a un point de vocabulaire.
Quand on parle de Snap, on parle de l'écosystème, ou du client ?
Si on parle de l'écosystème, il n'est pas libre, puisque le serveur ne l'est pas et qu'il n'y a pas aujourd'hui d'alternative sérieuse (le repo GitHub indiqué ça et là n'a vu aucun commit sur 3 ans, et je n'ai entendu personne dire qu'il s'en servait).
Si on parle du client, il est libre puisqu'on a le code, et que la licence permet de le forker.
Maintenant, même si on avait le code source du pilote JDBC de Oracle, est-ce que pour autant on qualifierait "Oracle" de libre ? Même si Oracle publiait l'intégralité du protocole de sa base de données, avec une licence permissive autorisant les réimplémentations, commerciales ou non, est-ce qu'on qualifierait "Oracle" de libre ?
Ou on dirait "ben si c'est libre, il ne tient qu'à nous de réimplémenter la partie serveur ; on est juste des gros branleurs fainéants" ? J'ai un gros doute.
Ce qui est chiant avec la formulation "Compose Key", c'est que quand tu parles à un être humain normal, ben ça l'aide pas à savoir ce qu'il doit faire. La touche "Compose", moi je l'ai jamais vue sur un clavier - d'ailleurs à moins d'avoir été sous Solaris en '87 avec une vraie station Unix, personne l'a jamais vue.
Je sais que c'est une formule justement pour s'affranchir d'avoir à préciser sur quelles touches appuyer puisque c'est variable selon la configuration de l'utilisateur, son type de clavier, etc. Mais ça rend vraiment le truc imbitable.
Et puis tu fais 15 photos du même truc "pour être sûr", et l'iPhone te fait la photo "Live" (donc photo + vidéo de 2 secondes). C'est sympa sur le coup, mais à la fin, c'est du travail (inutile) en plus. Tu dois classer toute cette merde, sélectionner, etc.
C'est une autre forme de surconsommation ; l'abondance fait qu'on ne réfléchit plus à ce qui est utile, et on s'emprisonne dans des nouvelles tâches qui servent à rien.
Dans une entreprise, on qualifierait ça de "bullshit job". Dans la vie perso, on accepte ça comme si c'était inévitable et utile. Ce n'est rien de tout ça.
Y'a 25 ans, j'ai acheté un camescope. J'ai fait quelques films - très peu. C'était encore sur bande. Et puis j'ai oublié le camescope dans le garage, et je suis tombé dessus il y a 4/5 ans. Y'avait les cassettes, et tout.
Et là, tout à coup, de façon aussi soudaine que violente, dans un éclair, que dis-je, une foudroyance de lucidité, je me suis rendu compte que…
…j'en avais absolument rien à foutre.
En fait, autant ça m'arrive de retourner sur un album photo d'il y a 15 ans, autant ça ne m'arrive JAMAIS avec les vidéos. Les vidéos personnelles, à regarder, je trouve ça juste chiant. Je dis pas : la vidéo des premiers pas de bébé, sa première descente en ski, j'ai été très content de pouvoir les montrer à Papy et Mamy qui n'étaient pas là. Mais une fois qu'ils l'ont vue, elle ne sert plus à rien.
Mais ma vérité (rien qu') à moi, c'est qu'après, je peux les supprimer, ça changera rien à ma vie.
J'ai regardé : actuellement, je sauvegarde tout ce qui traîne sur mon ordiphone ou sur mon appareil photo, que ce soit vidéo ou photo (en passant, j'utilise "<Année>/<Date & Lieu ou Evènement>" ; le mois en plus ça m'apporte rien). Mais je ne m'occupe jamais des vidéos. Et en toute logique, il va falloir que je fasse le ménage, pas en les réencodant/optimisant. Non non. Juste un gros "rm -rf *.avi" des familles.
D'un point de vue énergétique/écologique, c'est imbattable. D'un point de vue gain de temps, c'est presque imbattable (il faudrait que j'arrête de faire des vidéos que je ne regarde pas après). Et toutes les questions annexes disparaissent.
C'est évidemment très personnel, mais j'encourage tout le monde à se poser la question : à quoi servent toutes ces vidéos ? Est-ce que quelqu'un va vraiment les regarder ?
Y'a un autre truc qui me travaille : depuis 150 ans, toute personne partant dans l'autre monde laisse une dizaine d'albums photos. J'ai déjà observé ça : après l'enterrement, on se retrouve à "faire le tri", et là, c'est l'enfer. La progéniture tourne autour du pot, mais se rend compte que 90% des photos concernent des gens ou des évènements dont ils ne savent rien. Certes, y'a Pépé et Mémé quand ils étaient petits, c'est émouvant, mais… qu'est-ce qu'on va faire de ça ? On ajoute à nos propres albums photos, et nos arrière-petits-enfants se reposeront la question ?
Je trouve que ça ajoute au traumatisme de la disparition : devoir sacrifier tous ces trucs inutiles, en culpabilisant parce que "c'était à Pépé et Mémé, quand même".
Pour les vivants, on a toujours envie de se dire "mon rejeton sera content de voir cette vidéo et de la montrer à ses enfants". Ou "ah ah, je la diffuserai le jour de son mariage". Mais en fait, c'est rarement vrai ; c'est rarement mis en pratique. Et quand ça l'est, c'est 1 minute facilement oubliable. Donc pour moi, tout ça, c'est juste de l'utilisation d'énergie, de temps et d'espace pour rien. Je pense que je vais prendre le pli de supprimer purement et simplement toute vidéo de plus d'un an, et être beaucoup plus sélectif sur les photos.
Pendant très longtemps, j'ai utilisé jEdit. Niveau dépendance, le paradis : une seule, la JVM…
A l'époque, pour coder en Java, c'était juste idéal. La concurrence, c'était JBuilder de Borland, qui était monstrueux, d'une lenteur à mourir. On pouvait ouvrir indifféremment du code ou des fichiers XML de 50 MB sans frémir. Y'avait des plugins pour tout ce dont j'avais besoin : accès FTP, navigation base de donnnées, lancement de mon script ant de build (maven n'existait pas encore), …
Faudrait que je le réessaye aujourd'hui ; le projet est très calme, mais je vois encore des updates en 2022. Et il doit faire vraiment très léger désormais.
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".
[^] # Re: LibreOffice Calc - Créer et mettre en forme des tableaux
Posté par Dring . En réponse à la dépêche LibreOffice 24.2 : nouvelle année, nouvelle numérotation, nouvelle version. Évalué à 3 (+1/-0).
Les "tableaux automatiques" d'Excel ont pour eux des belles qualités (la ligne de titre qui vient remplacer les A, B, C, … dans l'entête pour gratter une ligne, le formattage automatique notamment pour l'alternance des lignes, …), mais aussi des défauts très chiants.
Tu perds énormément en souplesse, et sur les tableaux très larges (genre > 30 colonnes) où tu mets plusieurs niveaux d'entêtes pour t'y retrouver, ben c'est impossible de faire un truc qui tienne la route.
Pareil si tu fais des sous-totaux sans passer par un tableau croisé dynamique. Ou alors je m'y prends très mal ?
Donc parfois ça me manque, souvent ça m'évite de faire un tableau automatique qui ensuite va me pourrir la vie. 50/50.
Moi le truc qui me ferait rêver, c'est de sortir de "un tableau posé sous un autre tableau dans la même page doit absolument avoir les mêmes largeurs de colonnes, à moins de faire des bidouilles dégueulasses". Ce que Excel ne sait pas faire non plus.
[^] # Re: conclusion
Posté par Dring . En réponse au lien Making a PDF that’s larger than Germany. Évalué à 5 (+3/-0).
Faut l’imprimer vers un PDF !
De rien…
[^] # Re: On s'en tape (mais c'est pertinent d'en parler).
Posté par Dring . En réponse au journal La France crée un fichier des personnes trans. Évalué à 2.
Quand on voit certaines opérations esthétiques, on comprend que tout le monde n’a pas la même lecture du serment d’Hypocrate.
Et filer à l’étranger pour te faire charcuter parce que chez toi c’est pas possible…
Bref tout ça pour éviter de sombrer dans la naïveté excessive : il y a eu, il y a et il y aura encore des cas de grand portenawak.
Perso j’ai du mal à trancher par exemple sur l’autorisation de changement de sexe sur des mineurs. D’un côté c’est le risque de concrétiser un choix immature aux conséquences dramatiques. De l’autre c’est laisser une personne dans la souffrance. Et se dire “si un médecin a accepté de le faire, il avait forcément blindé le truc avant” ben moi j’y arrive pas.
[^] # Re: Pas tous libre
Posté par Dring . En réponse au journal snap : de pire en pire.. Évalué à 2.
Ben c’est un peu la somme des composants, et de chaque licence applicable, qui va permettre de se prononcer.
Si je parle d’un système libre, on s’attend bien à ce que le kernel ET les logiciels rajoutés par dessus soient libres.
Si je parle d’un ordiphone libre je vais aussi regarder si les plans du matériel sont libres, si le microcode est libre.
La réponse n’est pas toujours évidente et peut évidemment être débattue, mais je pense qu’on a depuis longtemps collectivement décidé que si, on peut parler de libre pour un écosystème, une plateforme ou n’importe quoi d’autre qui est composé de plusieurs choses.
Après il faut s’entendre sur les frontières, sur ce qu’on inclus ou pas dans cet écosystème.
[^] # Re: Pas tous libre
Posté par Dring . En réponse au journal snap : de pire en pire.. Évalué à 3. Dernière modification le 02 février 2024 à 15:03.
J'ai l'impression que comme souvent, y'a un point de vocabulaire.
Quand on parle de Snap, on parle de l'écosystème, ou du client ?
Si on parle de l'écosystème, il n'est pas libre, puisque le serveur ne l'est pas et qu'il n'y a pas aujourd'hui d'alternative sérieuse (le repo GitHub indiqué ça et là n'a vu aucun commit sur 3 ans, et je n'ai entendu personne dire qu'il s'en servait).
Si on parle du client, il est libre puisqu'on a le code, et que la licence permet de le forker.
Maintenant, même si on avait le code source du pilote JDBC de Oracle, est-ce que pour autant on qualifierait "Oracle" de libre ? Même si Oracle publiait l'intégralité du protocole de sa base de données, avec une licence permissive autorisant les réimplémentations, commerciales ou non, est-ce qu'on qualifierait "Oracle" de libre ?
Ou on dirait "ben si c'est libre, il ne tient qu'à nous de réimplémenter la partie serveur ; on est juste des gros branleurs fainéants" ? J'ai un gros doute.
[^] # Re: Source alternatives ?
Posté par Dring . En réponse à la dépêche Sortie de la version 2 d’æneria, l’application web pour analyser sa consommation d’énergie. Évalué à 3.
Ce qui est chiant avec la formulation "Compose Key", c'est que quand tu parles à un être humain normal, ben ça l'aide pas à savoir ce qu'il doit faire. La touche "Compose", moi je l'ai jamais vue sur un clavier - d'ailleurs à moins d'avoir été sous Solaris en '87 avec une vraie station Unix, personne l'a jamais vue.
Je sais que c'est une formule justement pour s'affranchir d'avoir à préciser sur quelles touches appuyer puisque c'est variable selon la configuration de l'utilisateur, son type de clavier, etc. Mais ça rend vraiment le truc imbitable.
(et ça reste quand même mieux que sous Windows)
[^] # Re: pluzun
Posté par Dring . En réponse au lien In Loving Memory of Square Checkbox (via OSnews) - Nikita Prokopov. Évalué à 3.
Pire : quand j’active le mode nuit, c’est texte noir sur fond noir…
[^] # Re: #mavie
Posté par Dring . En réponse à la dépêche Archiver ses vidéos : retour d’expérience. Évalué à 4.
Et puis tu fais 15 photos du même truc "pour être sûr", et l'iPhone te fait la photo "Live" (donc photo + vidéo de 2 secondes). C'est sympa sur le coup, mais à la fin, c'est du travail (inutile) en plus. Tu dois classer toute cette merde, sélectionner, etc.
C'est une autre forme de surconsommation ; l'abondance fait qu'on ne réfléchit plus à ce qui est utile, et on s'emprisonne dans des nouvelles tâches qui servent à rien.
Dans une entreprise, on qualifierait ça de "bullshit job". Dans la vie perso, on accepte ça comme si c'était inévitable et utile. Ce n'est rien de tout ça.
# #mavie
Posté par Dring . En réponse à la dépêche Archiver ses vidéos : retour d’expérience. Évalué à 6.
Y'a 25 ans, j'ai acheté un camescope. J'ai fait quelques films - très peu. C'était encore sur bande. Et puis j'ai oublié le camescope dans le garage, et je suis tombé dessus il y a 4/5 ans. Y'avait les cassettes, et tout.
Et là, tout à coup, de façon aussi soudaine que violente, dans un éclair, que dis-je, une foudroyance de lucidité, je me suis rendu compte que…
…j'en avais absolument rien à foutre.
En fait, autant ça m'arrive de retourner sur un album photo d'il y a 15 ans, autant ça ne m'arrive JAMAIS avec les vidéos. Les vidéos personnelles, à regarder, je trouve ça juste chiant. Je dis pas : la vidéo des premiers pas de bébé, sa première descente en ski, j'ai été très content de pouvoir les montrer à Papy et Mamy qui n'étaient pas là. Mais une fois qu'ils l'ont vue, elle ne sert plus à rien.
Mais ma vérité (rien qu') à moi, c'est qu'après, je peux les supprimer, ça changera rien à ma vie.
J'ai regardé : actuellement, je sauvegarde tout ce qui traîne sur mon ordiphone ou sur mon appareil photo, que ce soit vidéo ou photo (en passant, j'utilise "<Année>/<Date & Lieu ou Evènement>" ; le mois en plus ça m'apporte rien). Mais je ne m'occupe jamais des vidéos. Et en toute logique, il va falloir que je fasse le ménage, pas en les réencodant/optimisant. Non non. Juste un gros "rm -rf *.avi" des familles.
D'un point de vue énergétique/écologique, c'est imbattable. D'un point de vue gain de temps, c'est presque imbattable (il faudrait que j'arrête de faire des vidéos que je ne regarde pas après). Et toutes les questions annexes disparaissent.
C'est évidemment très personnel, mais j'encourage tout le monde à se poser la question : à quoi servent toutes ces vidéos ? Est-ce que quelqu'un va vraiment les regarder ?
Y'a un autre truc qui me travaille : depuis 150 ans, toute personne partant dans l'autre monde laisse une dizaine d'albums photos. J'ai déjà observé ça : après l'enterrement, on se retrouve à "faire le tri", et là, c'est l'enfer. La progéniture tourne autour du pot, mais se rend compte que 90% des photos concernent des gens ou des évènements dont ils ne savent rien. Certes, y'a Pépé et Mémé quand ils étaient petits, c'est émouvant, mais… qu'est-ce qu'on va faire de ça ? On ajoute à nos propres albums photos, et nos arrière-petits-enfants se reposeront la question ?
Je trouve que ça ajoute au traumatisme de la disparition : devoir sacrifier tous ces trucs inutiles, en culpabilisant parce que "c'était à Pépé et Mémé, quand même".
Pour les vivants, on a toujours envie de se dire "mon rejeton sera content de voir cette vidéo et de la montrer à ses enfants". Ou "ah ah, je la diffuserai le jour de son mariage". Mais en fait, c'est rarement vrai ; c'est rarement mis en pratique. Et quand ça l'est, c'est 1 minute facilement oubliable. Donc pour moi, tout ça, c'est juste de l'utilisation d'énergie, de temps et d'espace pour rien. Je pense que je vais prendre le pli de supprimer purement et simplement toute vidéo de plus d'un an, et être beaucoup plus sélectif sur les photos.
[^] # 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é à 2.
Merci !
[^] # Re: oui mais si on veut éditer un texte ?
Posté par Dring . En réponse au journal Emacs, le dinosaure fait de la résistance. Évalué à 3.
Pendant très longtemps, j'ai utilisé jEdit. Niveau dépendance, le paradis : une seule, la JVM…
A l'époque, pour coder en Java, c'était juste idéal. La concurrence, c'était JBuilder de Borland, qui était monstrueux, d'une lenteur à mourir. On pouvait ouvrir indifféremment du code ou des fichiers XML de 50 MB sans frémir. Y'avait des plugins pour tout ce dont j'avais besoin : accès FTP, navigation base de donnnées, lancement de mon script ant de build (maven n'existait pas encore), …
Faudrait que je le réessaye aujourd'hui ; le projet est très calme, mais je vois encore des updates en 2022. Et il doit faire vraiment très léger désormais.
[^] # Re: vim
Posté par Dring . En réponse au journal Emacs, le dinosaure fait de la résistance. Évalué à 2.
Hum… Noemacs existe depuis avant emacs, et c'est vi, justement :-).
[^] # 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".