Je pense que ce n'est pas démesuré de dire la voiture se débrouille hors agglomération sauf quand elle demande l'aide du conducteur (dans un tel cas elle s'arrête d'elle-même comme le font déjà certaines voitures).
Après moi je m'en fou je conduit pas mais je minerai vachement plus sur ce que font les autres constructeurs, c'est à dire d'automatiser des bouts (l'arrêt automatique, la régulation de la vitesse, le parking,…) et d'en faire de plus en plus.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Ah mais je ne dis pas que ça n'a pas d'intérêt, je suis juste que même si on y arrive pas encore, ça peut déjà être très utile.
Pour ton second point c'est ce qui est pointé du doigt plus haut. Si sur un trajet de 2h, la voiture conduit 1h30 et tu conduit 30 minutes, tu sera moins fatigué, plus alerte et ta capacité de concentration plus grande.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Je connais très mal la fondation Eclipse mais pour devenir un top project Apache (sortir de l'incubateur), il faut (entre autre) que le projet soit assez vivace.
Et puis reprocher à la fondation Apache de recevoir des projets morts alors que, pour sûr ce n'est pas sur github qu'on y trouve des projets morts.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Tu pars du principe qu'un service va emerger. Mais ça, c'est si github fait tellement de la merde que quelqu'un décide de refaire des trucs.
Parce que ça a toujours était le cas pour tous les services qui ont de la valeur. Si ça ferme, un concurrent prend là main ou un nouveau service arrive pour combler le vide.
Pour tout ce que tu décris, il y a déjà des alternatives. Si tu veux vraiment quelque chose de neuf et de solide va regarder du coté des fondations comme Apache ou Eclipse. Ces fondations ont des règles claires et précises et fournissent certains nombre de garanties. Ce ne sont pas des projets communautaires mais la gestions par de multiples entreprises améliore leur solidité.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
La création du piston hydraulique n'a pas détruit les compétitions de bras de fer. La création de la voiture n'a pas supprimé les courses et le fait de créer des ordinateurs capable de battre n'importe quel humain aux échecs n'a pas supprimé les compétitions et classement d'échecs.
Ce serait un peu comme si le fait que Teddy Rinner bat tout le monde au judo auvait empêché les gens de faire des compétitions de judo. Beaucoup de gens aiment la compétition sans pour autant avoir des ambitions ubuesque.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Oui, je suis d'accord. 90% du temps, on est en pilotage automatique et on peut penser a autre chose en conduisant.
et
La google car, non. Elle s’arrête et il faut qu'un humain la prenne en main.
Tu ne trouve pas ça sympa ? Une voiture qui fait 90% du travail et qui te laisse la main quand ça devient trop complexe pour elle. Elle fait ton boulot mieux que toi parce qu'elle reste vigilante quand tu l'es moins et te laisse la main quand c'est compliqué et que toi tu es frais.
Il y a une obligation à ce que ce soit entièrement automatisé ou c'est juste le plaisir de mettre au défit les industriels ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Gtk+ (Qt vu que c'est du C++ c'est déjà une autre paire de manches)
Je ne crois pas que ce soit le fait que l'un soit en C et l'autre en C++ qui ai eu un impact sur le nombre de binding de l'un et de l'autre, mais plutôt toute la tambouille autour de GObject qui permet de générer les bindings dans chaque langage.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Pourquoi, de la nature de la procédure (native ou stockée) dépend le type de test (unitaire ou d'intégration) ?
Je ne sais pas tester unitairement une procédure stocker (donc exécution uniquement en mémoire et uniquement de la procédure en question). Si tu sais faire c'est cool. Ça fait juste 2 jours que je demande comment on fait.
Tu m'as dit qu'un client pouvait souhaiter utiliser un autre SGBD, pas que j'avais besoin de changé de base ;
Je t'ai montré un exemple de quelqu'un qui aimerait bien ne pas avoir une base en fin de vie sur sa plateforme.
De part le couplage fort, oui, changer de base de données nécessite une révolution. Est-ce que j'ai dit que je préférais tout réécrire ? Non. Relis bien.
Idem relis bien, je n'ai pas dis que tu préférerais. J'ai dis que tu préférerais peut être, je ne vois pas en quoi j'ai dénaturé ton propos.
S'il n'y a pas besoin de pouvoir changer de BD, pourquoi se contraindre à le faire et à se limiter aux opérations supportés par toutes bases (CRUD) ? Parce qu'hypothétiquement, dans 5 ans il y en aura besoin ?
Parce que c'est évitable dans la majorité des cas, que c'est débraillable (tu peut toujours te rendre compte plus tard que c'est pas assez performant et réécrire ton code en procédure stockée) et que ça te coûte chère (en test, en couplage fort, etc). Qu'il y a à mon avis peu de cas où c'est la seule solution. Le couplage fort (en soit) c'est une dette technique (il y en a qui sont inévitables comme le langage (et encore tu peux faire de la génération de code à partir de modèle et d'automate), ça ne se mesure pas (la seule approximation c'est la qualité du code) et quand on te demande de l'encaisser tu déguste. J'ai vus trop de projet souffrir à cause de ça pour le plébisciter comme c'est le cas de beaucoup de monde.
Je réponds à ta remarque (trollesque qui plus est) : "Quelque soit le SGBDR, le mec qui me dit qu'il faut faire de la procédure stockée, mérite d'être pendu haut et court."
Je suis convaincu de ce que je dis. Je le dis de manière un peu abrupte pour susciter le débat. C'est peut être disruptif et ça remet en question des façon de travailler. Je trouve dommage d'apprécier aussi peu la remise en question par certains d'ailleurs, personnellement je considère que si on fait quelque chose plus par habitude qu'autre chose c'est qu'il y a un grave problème (c'est ce qui amène à choisir exchange comme tout le monde, à utiliser Word parce qu'on connaît, à prendre SAP pour pas prendre de risque, etc).
Il y a forcément des gens qui se sentent égratignés, j'explique que ce qu'ils font n'est, à mon avis, pas une bonne façon de travailler. Il y a de l'humain et c'est pour ça que je me fais moinsser. Je le comprends, je peux être un peu plus doux, mais je pense que si j'avais dis :
AMHA les procédures stockées sont rarement la bonne solution
Personne n'aurait réagis, car personne se ne sentirait concerné.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Ça impose de créer des tests d'intégration pour quelque chose que je préfère très largement tester de manière unitaire (avoir une boucle de feedback courte et tester tous les cas les plus bizarre sans que ça ne me prenne trop de temps). Même pour un test d'intégration c'est particulièrement lourd parce qu'il faut manager la base de données (créer des bases à la volée ou les nettoyer à la volée).
Est-ce plus clair ainsi ?
Je te dis que tu peux avoir un besoin de changer de base
Tu me dis que c'est une révolution qui n'est valable qu'avec un « GROS GROS chèque » (et que tu préférerais peut être même tout réécrire - pour un choix de base de données… -)
Je t'explique que c'est une révolution parce que tu as un couplage fort avec ta base
Tu m'explique que c'est ton choix
Que veux-tu que j'y réponde ? Oui c'est ton choix, j'explique juste qu'utiliser des procédures stockées ça te crée un couplage fort qui peut t'être dommageable. Je vois pas où tu peux vouloir en venir.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Je troll ;) Je me fou de la complétude lors de mes tests. (Je n'ai pas le temps de le faire et ce n'est pas ma philosophie de faire des tests en connaissant l'implémentation des algos )
J'ai volontairement parlé de complétude et non de couverture pour ne pas emmener le débat sur la couverture de code. La complétude c'est le fait d'avoir tester tous les cas ou du moins les cas aux limites de ton bloc logique. La couverture de code est un outil qui permet d'approximer cette complétude, mais ce n'est pas la seule (l'évaluation de test par mutant en est une autre par exemple).
Non. C'est un choix qui a été fait dès la conception. C'est quand on remet en cause un tel choix que cela devient une révolution.
? Tu dis « non » juste par plaisir ? Tu as choisi à la conception (ou après hein on s'en fout) d'avoir un couplage fort avec ta base.
Le choix de la BD, c'est pareil. C'est un choix (celui de se limiter à une seule BD, celui d'en supporter un maximum, etc…).
Donc ça n'est pas forcément une révolution tel que tu le disais un commentaire plus haut.
Je crois qu'il manque la fin de la phrase ;)
Il semble en effet, mais vu que tu semble plus intéressé à troller qu'à débattre je laisse ton imagination continuer la phrase dans le sens que tu souhaite.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Lorsque je disais que souvent on pouvait se contenter d'opération ensembliste en SQL, on peut se passer dans beaucoup de cas des boucles, des conditionnel etc… Au final, il ne reste qu'une seule branche ! Et donc avec un test, tu as ta complétude ;)
Tu y crois ou le smiley est là pour préciser que tu troll ? C'est toi qui disait 2 messages plus haut que tu test une interface ? Le fait de ne pas pouvoir mesurer la complétude avec la couverture de code n'indique pas que ta couverture est complète (et c'est le cas avec n'importe quelle paradigme d'ailleurs).
Faire des changements profond pour que cela devienne non plus une "évolution" mais une "révolution" non.
Une révolution ? Ce que redmine fait de base par exemple ? C'est ton couplage fort qui en fait une révolution.
Ou alors il faut faire un GROS GROS chèque.
Juste le besoin de vivre ça peut arriver. Tu parle plus haut de l'éditeur qui a sa solution déjà prête type informatique sur étagère. Ça ne se fait pas tout seul et le développement de ta solution peut être soutenu par des clients qui ont des besoins différents.
Mais dès qu'on part sur une "révolution" et non sur une "évolution", il faut se demander si le choix est pertinent (développer une nouvelle solution peut être moins cher et plus adaptée que d'utiliser des solutions existantes que l'on adapte).
Ce sont des choix d'architecte. Mais tu va vouloir factoriser ton code (via des bibliothèques ou un framework) et… tu va peut être te rendre compte que ce serait cool de factoriser ce qui est dans tes
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Ensuite, cela n'aurait que peu de sens de toutes façons, car là où en programmation séquentielle on va être obligée de faire des boucles, des if, etc… on peut souvent se contenter d'opération ensembliste en SQL (je ne dis pas que c'est toujours le cas hein !).
Il n'y a pas de rapport :) Tu as un traitement, tu test ce traitement que ce soit du fonctionnel, du séquentiel, de l'objet, de la machine de turing ou autre.
Là, je vois deux cas possible :
- ou bien ils achètent une solution existante, et dans ce cas là, c'est à eux de s'adapter (sinon, c'est que la solution ne leur convient pas)
- ou bien c'est un développement sur mesure, et dans ce cas, le choix du SGBD est à prendre en compte dès le départ.
Il y a beaucoup d'entreprises qui sont entre les deux. Tu achète une solution que tu fais adapter à tes besoins soit par l'éditeur soit par un intégrateur.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Éventuellement, tu charges un dump de ta BD pour connaître précisément ton état de départ et faire les vérifications qui vont bien ensuite. Mais il n'y a aucune difficulté majeure.
Tu mesure comment la complétude de ton test ? Ça impose de créer des tests d'intégration pour quelque chose que je préfère très largement tester de manière unitaire (avoir une boucle de feedback courte et tester tous les cas les plus bizarre sans que ça ne me prenne trop de temps). Même pour un test d'intégration c'est particulièrement lourd parce qu'il faut manager la base de données (créer des bases à la volée ou les nettoyer à la volée).
C'est très loin de sa priorité. Elles veulent généralement quelque chose qui marche, qui est rapide, stable et pas cher (donc forcément, il y a des compromis à faire :) )
Ça peut aussi avoir son importance en fonction de qui c'est qui fait l'administration du projet. Tu peut avoir une entreprise qui t'explique que leur compétence interne (ou leur presta) c'est la base X, qu'ils ont déjà un cluster et qu'ils maîtrisent parfaitement ça (voir qu'ils ont un partenariat avec l'éditeur de cette base) et que si tu leur impose d'utiliser ta base ça va probablement pas coller. C'est ultra relou (c'est pas à eux de t'imposer la conception normalement), mais ça existe (pas dans tous les contextes bienheureusement).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Windows mobile et PalmOS étaient là bien avant iOS et Android.
Comme je ne sais pas le quel est arrivé avant et pour éviter les remarques du style « il est pas arrivé premier il y avait X », j'ai voulu en citer un second.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Je comprends tu remplace surtout du SQL par des procédures stockées. La comparaison que je fais est différente. J'ai probablement perdu un peu l'habitude de travailler avec du sql et c'est vrai qu'il faut savoir utiliser ses outils à bon escient (suivre la philosophie de ses outils). Néanmoins je pense qu'il faut tout de même faire attention à la charge que l'on ajoute sur ces serveurs :
ils sont taillés pour du stockage et du débit pas du calcul
il y a certains calculs qui vont être particulièrement optimisables, mais pas forcément tous (la complexité de ton algo ne change pas magiquement parce que tu l'excute sur la bas de données)
Merci en tout cas pour ton exemple très pertinent
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Quand il s'agit de faire un choix sur le placement d'une fonctionnalité je réfléchi toujours en terme de métier.
De métier dans la conception de logiciels ? :-) On est loin des développeurs fullstack ou du devops.
Mais en quoi est-ce le boulot de ton dba de savoir ce qu'est un modèle linéaire ? De faire des régressions statistiques ? Ou tout un tas d'autres choses encore plus intéressantes les unes que les autres ?
Je suis content, j'ai fait émerger des questions que je trouvais intéressantes et des cas où oui les procédures stockées peuvent être utiles. Je reste sur mon idée de limiter ça autant que possible parce que personne n'a encore su me répondre sur les tests (ça me paraît grave), que l'on voit plus bas que ça peut être limitant, parce que ça crée une dépendance forte sur la base de données,…
Je pense être arrivé au bout du débat et qu'il n'est pas possible de continuer de manière intéressante (sans tourner en rond et sans partir sur des cas précis sans être en mesure de connaître leur représentativité).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Et dans le monde mobile, il est arrivé trop tard pour pouvoir verrouiller le marché.
C'est le premier sur le marché avec PalmOS…
Non ce n'est pas une question de timing (pour une fois chez ms), mais de capacité à sentir le marché (et dans le cas présent à comprendre qu'il fallait s'intéresser au grand public et pas uniquement aux professionnels.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Si je ne m'abuse la JVM n'a jamais était ouverte, c'est une ré-implémentation (OpenJDK) qui a finie par être utilisée comme référence (mais la JVM de sun est toujours fermé je crois, tout comme jrockit).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Moi j'aime bien le tweet qui expliquais que le big data ce n'est pas une question de volume de données, mais une architecture qui met la données au centre de ta problématique.
Comme quoi…
Toujours est-il que m'expliquer que c'est intenable question performances alors que beaucoup de monde s'en servent c'est rigolo.
C'est une autre manière de penser et de nouvelles architectures qui ont émergées avec la volonté de réduire la complexité des bases de données avec les bases NoSQL.
Ça s'utilise très bien même à petite échelle. Ce n'est pas parce qu'on te parle d'un processus en plus que t'a besoin d'un nouveau serveur ou d'un serveur en plus.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Le mec qui me dit que le mec qui lui dit qu'il faut faire des proc stockées doit être pendu, je le prends pas sur un projet.
C'est une approche dogmatique. Comme d'habitude, il n'y a pas d'approche miracle qui répond à tout.
Hé hé ! Comme je l'ai dit après je vais surtout t'obliger à affûter tes arguments autant que possible pour la moindre ligne de ce genre de code.
Par exemple personne ne m'a encore expliqué comment tu teste ce code (avec une certaine complétude tout de même donc mesurable).
C'est assez drôle l'histoire de la DMZ. Si tu penses pouvoir te permettre d'avoir un mauvais débit entre ta base et ton application, c'est que tu te fous des performances.
Par contre ça peut être sympa d'aller voir des gens qui ont ce genre de problèmes mais avec une charge plusieurs magnitudes de fois supérieure à ce qu'on trouve généralement. Les Google, Facebook, Netflix, etc sont très prolixes sur ce genre de sujets et ils ne cherchent pas à vendre du cloud, une appli ou une techno, juste ils partagent leur expérience.
Je ne doute pas qu'il y en a qui sont contents avec des procédures stockées. Mais il faut les tester et maintenir les tests et leur qualité tout au long de la vie du logiciel. C'est très coûteux parce que tu n'a pas framework de test et très long parce que du coup ce sont des tests d'intégration. Et ça ne se vend pas. Alors que la performance si, donc on a facilement tendance a ajouter des choses en procédure stockée parce que c'est plus rapide, avec une tendance a faire moins de tests parce que c'est plus long et compliqué tout ça avec potentiellement plus de bugs parce que c'est un mode d'exécution différents du reste de l'application. Ok tu arrive à gérer tout ça… Aujourd'hui, mais dans un ou deux ans ?
Puis un jour tu as de nouvelles contraintes qui te poussent à changer de base (l'arrêt du support de ta base actuelle par exemple ?) et là tu pleure tout ce que tu peux.
Ce n'est pas de la théorie, j'ai déjà eu plusieurs expérience de ce genre.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
GNI ? L'exemple que je donne c'est la réponse à un besoin exprimé par la direction au niveau base de données. La base de données elle même a probablement été créé pour répondre à un besoin exprimé par la direction (ou autre). Ça revient à dire que toute base de données qui sert à quelque chose au niveau fonctionnel serait en fait de la logique métier…
Tes utilisateurs se foutent de ta base. Si ta base consiste à écrire sur du papier tes données, c'est pas leur problème (tant que ça répond aux contrainte que l'on te donne).
Le code métier c'est celui qui répond à une problématique métier. C'est pointé directement par une User Storie. Le code non métier c'est celui qui consiste à traduire tes dates en timestamp parce que tu préfère les stocker comme ça.
Ici le fait que tu calcul tes projections dans une direction ou dans une autre ça impact directement tes utilisateurs. C'est donc quelque chose que tu dois valider avec les utilisateurs ça concerne leur métier.
Si tu décide de passer à du stockage en fichier XML. Cette traduction en XML ce n'est pas métier, l'utilisateur se fout de savoir si tu stocke du XML ou autre chose ça ne va pas changer sa façon de travailler.
C'est plus clair ?
Pourquoi j'irai compliquer mon architecture, rajouter des scripts ou des datastore à droite à gauche si je n'en ai pas besoin ? Tu te plains plus haut de la dispersion des éléments logiques entre plusieurs endroits et ta solution consiste à disperser les éléments data à la place ?
Ça ne demande rien de tout ça. Ça demande à créer des classes/fonctions en plus oui. Le reste est uniquement dépendant de ton besoin. Ce n'est pas parce que tu organise ton code pour qu'il soit distribuable qu'il faut le distribuer.
La tenue de charge en cas de forte demande/grosse quantité de données : Ce sera la même que celle de la base SQL ou NoSQL sous-jacente. Peut importe que ce soit via fonction, vue ou cube OLAP virtuel, si la base de données ne peut pas encaisser la charge d'une façon il y a peu de chance qu'elle puisse l'encaisser d'une autre. Et encore les fonctions et procédures seront plus performantes que les deux autres méthodes.
Ton code s'exécute sans demander de temps CPU ? Le faire exécuter l'algo sur un autre service, ça permet de réduire la charge CPU consommée par ta base (et donc de lui laisser faire ce qu'elle fait de mieux : les IO) et du peux lisser la charge que tu impose à ta base via de la backpressure.
Une fois de plus les fonctions et procédures ne peuvent qu'améliorer l'existant sans rien bloquer autour. En plus on peut parfaitement faire une base dédiée reporting (donc sans impact sur la prod) et utiliser des procédures quand même sur cette base.
Quel est l'intérêt ? Tu peux calculer tes projections lors de l'alimentation de cette base. Si un changement de besoin interviens, tu peut détruire ta base de reporting et la reconstruire avec tes nouvelles projections.
C'est un problème de design de base de données et de placement des index - l'utilisation ou non des procedures stockées n'a pas grande influence sur le résultat final.
Elles sont juste une misère à tester :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Cela manque de précision, je le concède ;) Le plus simple est de prendre un exemple. Actuellement, je suis sur une application qui évolue tout le temps (car les besoins changent, le cadre d'application, la loi, etc…). Il m'arrive de devoir faire des modifications au niveau du schéma de la BD afin justement de pouvoir prendre en compte ces besoins futurs (qui ne vont pas tarder à arriver), mais qui ne sont pas encore développés. Je peux ainsi mettre à jour petit à petit l'application, souvent, et sans difficulté. C'est très pratique pour pouvoir la tester en condition réelle (je fais bien entendu des tests avant ! Mais les meilleurs testeurs restent les utilisateurs).
C'est la couche métier qui fait ce boulot chez moi (la DAO si tu préfère).
Quant aux triggers, je suis étonné de te le voir mentionner. Car si pour toi l'utilisation des procédures stockées mérite d'être pendu haut et court, que dire de l'utilisation des triggers ? C'est le truc le plus discret qui soit ! Discret dans le sens où ce sont des actions qui sont faite de manière implicite en réponse à un événement, contrairement aux procédures stockées qui sont appelées explicitement.
Tout est dans la parenthèse « en se limitant à coder des invariants ». Il s'agit uniquement de faire péter une erreur en cas de modification foireuse de tes données. Tu ne fais que valider la cohérence de tes données rien de plus.
Ce qui a un impact sur l'architecture en place (je pense à la configuration du serveur notamment).
Pas forcément autant que tu ne semble le croire. Je suis entrain de m'amuser avec vertx. Pour faire de l'event sourcing. Pour le moment c'est juste une application java multithreadé avec un mongodb et un hazelcast (embarqué). Donc le tout avec un seul serveur. Puis gérer une distribution du système uniquement par configuration et ainsi être capable de monter en charge via la multiplication de serveur spécifique et utiliser le bus d'événement que j'utilise déjà pour faire le job.
C'est peut être la volumétrie qui augmente si tu as beaucoup d'événements qui modifie des données existante. Tu peut optimiser ça par un batch qui va agréger tes données (il suffit que ça fréquence soit inférieure au temps que tu métrais pour détecter le bug).
Dans l'autre sens, tu as beaucoup de cas où tu cherche une traçabilité totale de tes données, là tu l'a de base. :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: cppfix ?
Posté par barmic . En réponse au journal C++17 est sur les rails. Évalué à 9.
Quel intérêt ? Si tu as besoin d'un autre langage prends un autre langage. Ce n'est pas ce qui manque.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Machine Learning
Posté par barmic . En réponse au journal AlphaGo remporte le premier match contre Lee Sedol. Évalué à 3.
Je pense que ce n'est pas démesuré de dire la voiture se débrouille hors agglomération sauf quand elle demande l'aide du conducteur (dans un tel cas elle s'arrête d'elle-même comme le font déjà certaines voitures).
Après moi je m'en fou je conduit pas mais je minerai vachement plus sur ce que font les autres constructeurs, c'est à dire d'automatiser des bouts (l'arrêt automatique, la régulation de la vitesse, le parking,…) et d'en faire de plus en plus.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Machine Learning
Posté par barmic . En réponse au journal AlphaGo remporte le premier match contre Lee Sedol. Évalué à 2.
Ah mais je ne dis pas que ça n'a pas d'intérêt, je suis juste que même si on y arrive pas encore, ça peut déjà être très utile.
Pour ton second point c'est ce qui est pointé du doigt plus haut. Si sur un trajet de 2h, la voiture conduit 1h30 et tu conduit 30 minutes, tu sera moins fatigué, plus alerte et ta capacité de concentration plus grande.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Backup
Posté par barmic . En réponse au journal Comment Github a ressuscité mon logiciel libre. Évalué à 5.
Eclipse (l'IDE) ? Apache (le serveur web) ? Groovy ? Ant ? Spark ? Subversion ? Kafka ? Hadoop ? Tomcat ? Maven ? Spamassassin ? Cordova ? Cassandra ? Zookeeper ?….
Je connais très mal la fondation Eclipse mais pour devenir un top project Apache (sortir de l'incubateur), il faut (entre autre) que le projet soit assez vivace.
Et puis reprocher à la fondation Apache de recevoir des projets morts alors que, pour sûr ce n'est pas sur github qu'on y trouve des projets morts.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Backup
Posté par barmic . En réponse au journal Comment Github a ressuscité mon logiciel libre. Évalué à 4.
Parce que ça a toujours était le cas pour tous les services qui ont de la valeur. Si ça ferme, un concurrent prend là main ou un nouveau service arrive pour combler le vide.
Pour tout ce que tu décris, il y a déjà des alternatives. Si tu veux vraiment quelque chose de neuf et de solide va regarder du coté des fondations comme Apache ou Eclipse. Ces fondations ont des règles claires et précises et fournissent certains nombre de garanties. Ce ne sont pas des projets communautaires mais la gestions par de multiples entreprises améliore leur solidité.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: La joie de vivre
Posté par barmic . En réponse au journal AlphaGo remporte le premier match contre Lee Sedol. Évalué à 6.
La création du piston hydraulique n'a pas détruit les compétitions de bras de fer. La création de la voiture n'a pas supprimé les courses et le fait de créer des ordinateurs capable de battre n'importe quel humain aux échecs n'a pas supprimé les compétitions et classement d'échecs.
Ce serait un peu comme si le fait que Teddy Rinner bat tout le monde au judo auvait empêché les gens de faire des compétitions de judo. Beaucoup de gens aiment la compétition sans pour autant avoir des ambitions ubuesque.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Machine Learning
Posté par barmic . En réponse au journal AlphaGo remporte le premier match contre Lee Sedol. Évalué à 1.
C'est un faux problème à mon avis, les avions sont partiellement automatisés depuis très longtemps.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Machine Learning
Posté par barmic . En réponse au journal AlphaGo remporte le premier match contre Lee Sedol. Évalué à 5.
et
Tu ne trouve pas ça sympa ? Une voiture qui fait 90% du travail et qui te laisse la main quand ça devient trop complexe pour elle. Elle fait ton boulot mieux que toi parce qu'elle reste vigilante quand tu l'es moins et te laisse la main quand c'est compliqué et que toi tu es frais.
Il y a une obligation à ce que ce soit entièrement automatisé ou c'est juste le plaisir de mettre au défit les industriels ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi pas ? Parce queeeeeee !
Posté par barmic . En réponse à la dépêche Swift sous GNU/Linux - Introduction. Évalué à 3.
Je ne crois pas que ce soit le fait que l'un soit en C et l'autre en C++ qui ai eu un impact sur le nombre de binding de l'un et de l'autre, mais plutôt toute la tambouille autour de GObject qui permet de générer les bindings dans chaque langage.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Facile!
Posté par barmic . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 4.
Je ne sais pas tester unitairement une procédure stocker (donc exécution uniquement en mémoire et uniquement de la procédure en question). Si tu sais faire c'est cool. Ça fait juste 2 jours que je demande comment on fait.
Je t'ai montré un exemple de quelqu'un qui aimerait bien ne pas avoir une base en fin de vie sur sa plateforme.
Idem relis bien, je n'ai pas dis que tu préférerais. J'ai dis que tu préférerais peut être, je ne vois pas en quoi j'ai dénaturé ton propos.
Parce que c'est évitable dans la majorité des cas, que c'est débraillable (tu peut toujours te rendre compte plus tard que c'est pas assez performant et réécrire ton code en procédure stockée) et que ça te coûte chère (en test, en couplage fort, etc). Qu'il y a à mon avis peu de cas où c'est la seule solution. Le couplage fort (en soit) c'est une dette technique (il y en a qui sont inévitables comme le langage (et encore tu peux faire de la génération de code à partir de modèle et d'automate), ça ne se mesure pas (la seule approximation c'est la qualité du code) et quand on te demande de l'encaisser tu déguste. J'ai vus trop de projet souffrir à cause de ça pour le plébisciter comme c'est le cas de beaucoup de monde.
Je suis convaincu de ce que je dis. Je le dis de manière un peu abrupte pour susciter le débat. C'est peut être disruptif et ça remet en question des façon de travailler. Je trouve dommage d'apprécier aussi peu la remise en question par certains d'ailleurs, personnellement je considère que si on fait quelque chose plus par habitude qu'autre chose c'est qu'il y a un grave problème (c'est ce qui amène à choisir exchange comme tout le monde, à utiliser Word parce qu'on connaît, à prendre SAP pour pas prendre de risque, etc).
Il y a forcément des gens qui se sentent égratignés, j'explique que ce qu'ils font n'est, à mon avis, pas une bonne façon de travailler. Il y a de l'humain et c'est pour ça que je me fais moinsser. Je le comprends, je peux être un peu plus doux, mais je pense que si j'avais dis :
Personne n'aurait réagis, car personne se ne sentirait concerné.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Facile!
Posté par barmic . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 3.
https://linuxfr.org/users/msusa/journaux/microsoft-va-porter-sql-server-sur-linux#comment-1647412
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Facile!
Posté par barmic . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 3.
J'ai volontairement parlé de complétude et non de couverture pour ne pas emmener le débat sur la couverture de code. La complétude c'est le fait d'avoir tester tous les cas ou du moins les cas aux limites de ton bloc logique. La couverture de code est un outil qui permet d'approximer cette complétude, mais ce n'est pas la seule (l'évaluation de test par mutant en est une autre par exemple).
? Tu dis « non » juste par plaisir ? Tu as choisi à la conception (ou après hein on s'en fout) d'avoir un couplage fort avec ta base.
Donc ça n'est pas forcément une révolution tel que tu le disais un commentaire plus haut.
Il semble en effet, mais vu que tu semble plus intéressé à troller qu'à débattre je laisse ton imagination continuer la phrase dans le sens que tu souhaite.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Facile!
Posté par barmic . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 3.
Tu y crois ou le smiley est là pour préciser que tu troll ? C'est toi qui disait 2 messages plus haut que tu test une interface ? Le fait de ne pas pouvoir mesurer la complétude avec la couverture de code n'indique pas que ta couverture est complète (et c'est le cas avec n'importe quelle paradigme d'ailleurs).
Une révolution ? Ce que redmine fait de base par exemple ? C'est ton couplage fort qui en fait une révolution.
Juste le besoin de vivre ça peut arriver. Tu parle plus haut de l'éditeur qui a sa solution déjà prête type informatique sur étagère. Ça ne se fait pas tout seul et le développement de ta solution peut être soutenu par des clients qui ont des besoins différents.
Ce sont des choix d'architecte. Mais tu va vouloir factoriser ton code (via des bibliothèques ou un framework) et… tu va peut être te rendre compte que ce serait cool de factoriser ce qui est dans tes
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Facile!
Posté par barmic . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 4.
Il n'y a pas de rapport :) Tu as un traitement, tu test ce traitement que ce soit du fonctionnel, du séquentiel, de l'objet, de la machine de turing ou autre.
Il y a beaucoup d'entreprises qui sont entre les deux. Tu achète une solution que tu fais adapter à tes besoins soit par l'éditeur soit par un intégrateur.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Facile!
Posté par barmic . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 3.
Tu mesure comment la complétude de ton test ? Ça impose de créer des tests d'intégration pour quelque chose que je préfère très largement tester de manière unitaire (avoir une boucle de feedback courte et tester tous les cas les plus bizarre sans que ça ne me prenne trop de temps). Même pour un test d'intégration c'est particulièrement lourd parce qu'il faut manager la base de données (créer des bases à la volée ou les nettoyer à la volée).
Tout à fait, l'implémentation elle s'en fout, mais tu obtiens des retours d'expérience comme ça : https://linuxfr.org/users/msusa/journaux/microsoft-va-porter-sql-server-sur-linux#comment-1647122
Ça peut aussi avoir son importance en fonction de qui c'est qui fait l'administration du projet. Tu peut avoir une entreprise qui t'explique que leur compétence interne (ou leur presta) c'est la base X, qu'ils ont déjà un cluster et qu'ils maîtrisent parfaitement ça (voir qu'ils ont un partenariat avec l'éditeur de cette base) et que si tu leur impose d'utiliser ta base ça va probablement pas coller. C'est ultra relou (c'est pas à eux de t'imposer la conception normalement), mais ça existe (pas dans tous les contextes bienheureusement).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ce que Bill Gates en pense…
Posté par barmic . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 5.
Windows mobile et PalmOS étaient là bien avant iOS et Android.
Comme je ne sais pas le quel est arrivé avant et pour éviter les remarques du style « il est pas arrivé premier il y avait X », j'ai voulu en citer un second.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Facile!
Posté par barmic . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 4.
Je comprends tu remplace surtout du SQL par des procédures stockées. La comparaison que je fais est différente. J'ai probablement perdu un peu l'habitude de travailler avec du sql et c'est vrai qu'il faut savoir utiliser ses outils à bon escient (suivre la philosophie de ses outils). Néanmoins je pense qu'il faut tout de même faire attention à la charge que l'on ajoute sur ces serveurs :
Merci en tout cas pour ton exemple très pertinent
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Facile!
Posté par barmic . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 3.
De métier dans la conception de logiciels ? :-) On est loin des développeurs fullstack ou du devops.
Mais en quoi est-ce le boulot de ton dba de savoir ce qu'est un modèle linéaire ? De faire des régressions statistiques ? Ou tout un tas d'autres choses encore plus intéressantes les unes que les autres ?
Je suis content, j'ai fait émerger des questions que je trouvais intéressantes et des cas où oui les procédures stockées peuvent être utiles. Je reste sur mon idée de limiter ça autant que possible parce que personne n'a encore su me répondre sur les tests (ça me paraît grave), que l'on voit plus bas que ça peut être limitant, parce que ça crée une dépendance forte sur la base de données,…
Je pense être arrivé au bout du débat et qu'il n'est pas possible de continuer de manière intéressante (sans tourner en rond et sans partir sur des cas précis sans être en mesure de connaître leur représentativité).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ce que Bill Gates en pense…
Posté par barmic . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 4.
C'est le premier sur le marché avec PalmOS…
Non ce n'est pas une question de timing (pour une fois chez ms), mais de capacité à sentir le marché (et dans le cas présent à comprendre qu'il fallait s'intéresser au grand public et pas uniquement aux professionnels.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: C'est la mode de porter sur linux
Posté par barmic . En réponse à la dépêche Swift sous GNU/Linux - Introduction. Évalué à 6.
Si je ne m'abuse la JVM n'a jamais était ouverte, c'est une ré-implémentation (OpenJDK) qui a finie par être utilisée comme référence (mais la JVM de sun est toujours fermé je crois, tout comme jrockit).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Facile!
Posté par barmic . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 2.
Tu l'a testé ça ? Parce que selon ton profile d'utilisation tu augmente juste la pression sur ce cache et tu réduis les perf de ta production.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Facile!
Posté par barmic . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 5.
Moi j'aime bien le tweet qui expliquais que le big data ce n'est pas une question de volume de données, mais une architecture qui met la données au centre de ta problématique.
Comme quoi…
Toujours est-il que m'expliquer que c'est intenable question performances alors que beaucoup de monde s'en servent c'est rigolo.
C'est une autre manière de penser et de nouvelles architectures qui ont émergées avec la volonté de réduire la complexité des bases de données avec les bases NoSQL.
Ça s'utilise très bien même à petite échelle. Ce n'est pas parce qu'on te parle d'un processus en plus que t'a besoin d'un nouveau serveur ou d'un serveur en plus.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Facile!
Posté par barmic . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 0.
Hé hé ! Comme je l'ai dit après je vais surtout t'obliger à affûter tes arguments autant que possible pour la moindre ligne de ce genre de code.
Par exemple personne ne m'a encore expliqué comment tu teste ce code (avec une certaine complétude tout de même donc mesurable).
C'est assez drôle l'histoire de la DMZ. Si tu penses pouvoir te permettre d'avoir un mauvais débit entre ta base et ton application, c'est que tu te fous des performances.
Par contre ça peut être sympa d'aller voir des gens qui ont ce genre de problèmes mais avec une charge plusieurs magnitudes de fois supérieure à ce qu'on trouve généralement. Les Google, Facebook, Netflix, etc sont très prolixes sur ce genre de sujets et ils ne cherchent pas à vendre du cloud, une appli ou une techno, juste ils partagent leur expérience.
Je ne doute pas qu'il y en a qui sont contents avec des procédures stockées. Mais il faut les tester et maintenir les tests et leur qualité tout au long de la vie du logiciel. C'est très coûteux parce que tu n'a pas framework de test et très long parce que du coup ce sont des tests d'intégration. Et ça ne se vend pas. Alors que la performance si, donc on a facilement tendance a ajouter des choses en procédure stockée parce que c'est plus rapide, avec une tendance a faire moins de tests parce que c'est plus long et compliqué tout ça avec potentiellement plus de bugs parce que c'est un mode d'exécution différents du reste de l'application. Ok tu arrive à gérer tout ça… Aujourd'hui, mais dans un ou deux ans ?
Puis un jour tu as de nouvelles contraintes qui te poussent à changer de base (l'arrêt du support de ta base actuelle par exemple ?) et là tu pleure tout ce que tu peux.
Ce n'est pas de la théorie, j'ai déjà eu plusieurs expérience de ce genre.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Facile!
Posté par barmic . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 3.
Tes utilisateurs se foutent de ta base. Si ta base consiste à écrire sur du papier tes données, c'est pas leur problème (tant que ça répond aux contrainte que l'on te donne).
Le code métier c'est celui qui répond à une problématique métier. C'est pointé directement par une User Storie. Le code non métier c'est celui qui consiste à traduire tes dates en timestamp parce que tu préfère les stocker comme ça.
Ici le fait que tu calcul tes projections dans une direction ou dans une autre ça impact directement tes utilisateurs. C'est donc quelque chose que tu dois valider avec les utilisateurs ça concerne leur métier.
Si tu décide de passer à du stockage en fichier XML. Cette traduction en XML ce n'est pas métier, l'utilisateur se fout de savoir si tu stocke du XML ou autre chose ça ne va pas changer sa façon de travailler.
C'est plus clair ?
Ça ne demande rien de tout ça. Ça demande à créer des classes/fonctions en plus oui. Le reste est uniquement dépendant de ton besoin. Ce n'est pas parce que tu organise ton code pour qu'il soit distribuable qu'il faut le distribuer.
Ton code s'exécute sans demander de temps CPU ? Le faire exécuter l'algo sur un autre service, ça permet de réduire la charge CPU consommée par ta base (et donc de lui laisser faire ce qu'elle fait de mieux : les IO) et du peux lisser la charge que tu impose à ta base via de la backpressure.
Quel est l'intérêt ? Tu peux calculer tes projections lors de l'alimentation de cette base. Si un changement de besoin interviens, tu peut détruire ta base de reporting et la reconstruire avec tes nouvelles projections.
Elles sont juste une misère à tester :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Facile!
Posté par barmic . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 2.
C'est la couche métier qui fait ce boulot chez moi (la DAO si tu préfère).
Tout est dans la parenthèse « en se limitant à coder des invariants ». Il s'agit uniquement de faire péter une erreur en cas de modification foireuse de tes données. Tu ne fais que valider la cohérence de tes données rien de plus.
Pas forcément autant que tu ne semble le croire. Je suis entrain de m'amuser avec vertx. Pour faire de l'event sourcing. Pour le moment c'est juste une application java multithreadé avec un mongodb et un hazelcast (embarqué). Donc le tout avec un seul serveur. Puis gérer une distribution du système uniquement par configuration et ainsi être capable de monter en charge via la multiplication de serveur spécifique et utiliser le bus d'événement que j'utilise déjà pour faire le job.
C'est peut être la volumétrie qui augmente si tu as beaucoup d'événements qui modifie des données existante. Tu peut optimiser ça par un batch qui va agréger tes données (il suffit que ça fréquence soit inférieure au temps que tu métrais pour détecter le bug).
Dans l'autre sens, tu as beaucoup de cas où tu cherche une traçabilité totale de tes données, là tu l'a de base. :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)