Non on n'est pas Vendredi, et on n'est pas le 1er avril non plus…
https://blogs.microsoft.com/blog/2016/03/07/announcing-sql-server-on-linux/
Today I’m excited to announce our plans to bring SQL Server to Linux as well. This will enable SQL Server to deliver a consistent data platform across Windows Server and Linux, as well as on-premises and cloud. We are bringing the core relational database capabilities to preview today, and are targeting availability in mid-2017.
Maintenant il ne reste plus qu'à attendre quelles critiques certains vont encore réussir à trouver pour se plaindre de MS, il va falloir être de plus en plus imaginatif les gars.
# L'OS n'est pas le problème
Posté par bobbysixkiller . Évalué à 2.
Si déjà ils arrivaient à faire un SGBD qui n'a pas besoin de 4Go de ram pour faire tourner une base vide, ça serait bien.
[^] # Re: L'OS n'est pas le problème
Posté par lca . Évalué à -2.
Tes connaissances de DBA sont bien évidentes. SQL Server prends autant de mémoire que tu lui laisses, pour une raison simple: il cache au maximum les résultats des requêtes. Pour info, Gartner positionne SQL Server dans le carré des leaders, au dessus de Oracle.
[^] # Re: L'OS n'est pas le problème
Posté par georgeswwbush . Évalué à 9.
"MS SQL au dessus de Oracle" -> sources ???
(bonne blague ceci dit…)
[^] # Re: L'OS n'est pas le problème
Posté par barmic . Évalué à 10.
Après il s'agit de Gartner, je suis pas certain d'avoir un jour était intéressé par leurs avis (quelque soit le domaine).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: L'OS n'est pas le problème
Posté par bubar🦥 (Mastodon) . Évalué à 2.
Et c'est surtout qu'il n'y pas les outils statistiques fournis. Donc quelque soit l'orientation voulue/souhaitée donnée aux analyses de résultats de l'étude, ce qui peut se faire en interprétant normalement, il y a un défaut de transparence.
Et plutôt que de se battre sur des pouillèmes je préfèrerai avoir une étude de cas avec des données d'aujourd'hui. Pas du .txt à mettre en base avec 3 méta données qui se battent en duel, merci.
[^] # Re: L'OS n'est pas le problème
Posté par Dr BG . Évalué à 8. Dernière modification le 08 mars 2016 à 10:05.
voir ici : http://www.gartner.com/doc/reprints?id=1-2PO8Z2O&ct=151013&st=sb
Si tu regardes le quadrant, tu vois que Microsoft est tout en haut à droite : c'est la solution qui domine toutes les autres au sens de Pareto.
Je ne me prononce pas sur la qualité de l'analyse, mais c'est qui est dit est factuellement vrai : d'après Gartner, SQL Server est au-dessus d'Oracle.
[^] # Re: L'OS n'est pas le problème
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Comme toujours, il suffit de regarder qui a financé l'étude. Mais noter comme avant-gardiste une base SQL, c'est rigolo.
SQL server est quand même un jouet coincé entre MySQL/mariaDB d'un coté, puis Oracle/MongoDb/Cassandra/redis de l'autre.
"La première sécurité est la liberté"
[^] # Re: L'OS n'est pas le problème
Posté par Kaane . Évalué à 10.
MongoDb ? Franchement, ce truc est encore plus bricolé que MySQL - et Redis comme base de données générique ? Vraiment ?
Restons sérieux trente secondes.
[^] # Re: L'OS n'est pas le problème
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
C'est pourtant des databases du top 5 les plus utilisés (pour tout usage, pas forcément "générique") MongoDb est devant cassandra par exemple.
"La première sécurité est la liberté"
[^] # Re: L'OS n'est pas le problème
Posté par Kaane . Évalué à 3.
C'est pourtant des databases du top 5 les plus utilisés (pour tout usage, pas forcément "générique") MongoDb est devant cassandra par exemple.
Ben comme MySQL en son temps. Mais quand on voit les solutions NoSQL disponibles, y compris en libre - on ne peut définitivement pas classer MongoDB dans la catégorie "Outil sérieux et professionnel".
[^] # Re: L'OS n'est pas le problème
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Je suit de loin riak qui a l'air très bien.
[^] # Re: L'OS n'est pas le problème
Posté par Kaane . Évalué à 3.
Je suit de loin riak qui a l'air très bien.
Très très bien pour le suivi haute resistance, scale moins bien que OpenTSDB sur les logs ceci dit. Par contre les insertions simultanées ou en conflit sont assez pénibles à gérer.
Après dans la catégorie "qu'est qu'il fout là celui-là ?" je recommande vivement PostgreSQL avec le cstore_fdw de citus. Moins puissant en insertion, par contre en WORM il dépote grave. Le truc est d'utiliser row_to_json pour faire des requètes sur des tables hétérogènes - et hop on a une vraie base yeSQL qui peut fonctionner comme une base noSQL si on insiste un peu.
[^] # Re: L'OS n'est pas le problème
Posté par stopspam . Évalué à 8.
Microsoft disait ça de Linux avant, c'est drôle de voir d'anciennes vannes ressurgir. Ce que tu appelles jouet, je l'appelle le meilleur SGBDR du moment. Les dba PostGReSQL vont me dire que SQL Server n'est pas libre, je leur dirais que ça ne rentre pas en ligne de compte pour savoir qui est le meilleur. Les dba Oracle vont me dire que c'est moins puissant que leur usines à gaz, je répondrai que la profession de dba oracle est en train de mourrir au profit de dba tout court.
Oulah… Je pense que SQL Server taquine Oracle depuis quelques années maintenant et qu'avec une pente d'apprentissage bien plus faible ça va continuer. Ça ne veut pas dire qu'on ne peut pas faire de traitements complexes.
[^] # Re: L'OS n'est pas le problème
Posté par barmic . Évalué à 2.
Je sais pas comment ils expliquent de ne pas avoir évaluer ElasticSearch (ou alors je suis bigleux ?).
Par contre, ils indiquent les qualités et défauts qu'ils voient. C'est original. C'est des critères de décideur pressé pas de technicien (c'est un point de vu différent pas pire pas mieux).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: L'OS n'est pas le problème
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 10.
Je leur reproche surtout de ne pas avoir évalué PostgreSQL, qui joue plus dans la même catégorie (en mieux), alors qu'ils le citent plus bas avec ce proposent certains acteurs.
[^] # Re: L'OS n'est pas le problème
Posté par Mimoza . Évalué à 5.
PostgreSQL semble avoir été pris en considération via EntrepriseDB … mais leur analyse reste celle du décideur pressé comme dit plus haut.
[^] # Re: L'OS n'est pas le problème
Posté par Dabowl_75 . Évalué à 2.
en nombre d'instances, je ne serais pas étonné que mssql soit devant oracle.
En revanche, si on regarde les tailles moyennes des bases ou encore leur criticité, Oracle est très certainement devant.
Faut arrêter de chercher des poux à $krosoft gratuitement et puis il faut aussi sortir de sa caverne pour voir ce qu'il se passe en entreprise
[^] # Re: L'OS n'est pas le problème
Posté par fearan . Évalué à 5.
Je me suis abstenu de noter son commentaire, car je n'arrive pas à savoir si c'est une blague suite à "Maintenant il ne reste plus qu'à attendre quelles critiques certains vont encore réussir à trouver pour se plaindre de MS, il va falloir être de plus en plus imaginatif les gars.", ou juste une méconnaissance des usages en DBA.
On pourrait comparer ca vaguement au cache fichier sous linux, sauf que ça ne marche pas pareil et l'OS ne peut pas vraiment réclamer la RAM s'il vient à en manquer (enfin pas à ma connaissance), ce qui fait que ça en fait une cible de choix pour le oom_killer :)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: L'OS n'est pas le problème
Posté par Dabowl_75 . Évalué à 2.
sur Oracle, la SGA est du shared memory segment, donc c'est possible de déplacer les pages vers la zone de pagination si la mémoire vient à manquer.
Ca ne l'est pas en revanche quand on s'alloue de la mémoire "pinnable" ou "pinned".
Sur AIX ça se fait facilement, je ne sais pas pour Linux et n'ai pas envie de chercher :
https://docs.oracle.com/cd/B28359_01/server.111/b32009/tuning.htm
8.6.2 Shared Memory on AIX
[^] # Re: L'OS n'est pas le problème
Posté par Kangs . Évalué à 1.
Sous Linux il faut utiliser les Huge Pages qui ne sont pas paginables.
[^] # Re: L'OS n'est pas le problème
Posté par Dabowl_75 . Évalué à 1.
Sous Linux aussi tu peux locker des pages mémoire sans devoir passer par les huges pages :
https://www.google.fr/search?q=linux+pinnable+memory&ie=utf-8&oe=utf-8&gws_rd=cr&ei=rETgVujUAorxaoqypagL
[^] # Re: L'OS n'est pas le problème
Posté par barmic . Évalué à 8.
C'est précisément ce que fait cassandra. Par défaut son xms et son xmx sont à 4Gio à fin de ne pas perdre de temps avec la gestion de la mémoire et parce que pour limiter les accès disque il a un tas d'index et de cache en mémoire.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: L'OS n'est pas le problème
Posté par groumly . Évalué à 3. Dernière modification le 09 mars 2016 à 04:22.
La jvm gere toujours la memoire, c'est juste que sur une appli dont le profile d'execution est (on l'espere) bien connu a l'avance, et qui tourne (on l'espere) sur un machine/vm dediee, ca sert pas a grand chose d'aggrandir/diminuer la heap. T'as besoin de x go, ils vont toujours etre utilises, tu met xms == xmx, ca t'eviteras que la jvm te joue des tours derriere ton dos.
C'est assez standard comme pratique quand le profil d'execution est connu (je fais la meme chose sur mes webapps)
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
# Facile!
Posté par Maclag . Évalué à 10.
SQL Server ça pue, c'est pas libre!
Ça, c'est fait!
------> [ ]
[^] # Re: Facile!
Posté par gUI (Mastodon) . Évalué à 10.
Bin oui, quel intérêt d'utiliser SQL Server sinon le plaisir d'utiliser un SGBD non libre ? Quels sont ses avantages ?
Vraie question, je suis d'un niveau zéro+ en SGBD.
Autre chose : quel est l'intérêt de passer sous Linux pour ceux qui utilisent déjà une solution Windows/SQLServeur ? (bon, là j'ai une vague idée…)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Facile!
Posté par ɹǝıʌıʃO . Évalué à 4.
En effet, sérieusement, le problème qui reste, c’est la licence (et le tarif). Pour ceux qui ont une base de code serveur en .NET qui compile avec la partie déjà libérée, il est bien possible que la seule raison de rester sous Windows Server soit SQL Server. Maintenant, ils vont pouvoir envisager de quitter cette plaie qu’est Windows Server (quelle galère à administrer, et quels tarifs !) et passer sous Linux. Évidemment ce n’est pas aussi simple que ça, il y a encore plein de composants manquants. Mais ça va clairement ramener du monde du côté MS, ou en garder, et quand ce monde-là aura besoin de services complémentaires, il verra bien vite à quel point c’est plus simple, quand on a commencé avec MS, si on utilise Azure. Enlever des restrictions sur les produits pour vendre plus de services : c’est clairement leur direction actuelle, et à mon avis ils ont raison.
[^] # Re: Facile!
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 5.
C'est tellement leur direction que leur offre cloud est dorénavant leur première source de revenu. Et que Windows n'arrive qu'en 4ième, derrière les jeux (xbox &co), et MS Office.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Facile!
Posté par barmic . Évalué à -8.
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.
Sinon oui SQL Server est pas mal à ce qu'il paraît. Par exemple, il a un bon support de la norme (ah ! ah !) SQL.
Les ETL ne permettent pas ce genre de choses (prendre en entrée une sauvegarde) ?
Windows pourra bientôt tourner dans Docker (oui ça surprend toujours la première fois).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Facile!
Posté par barmic . Évalué à 5.
L'impossibilité de maintenir ce genre de code, le fait de séparer ta logique dans des endroits aussi divers que variés,… J'ai vu trop de projets se mordre les doigts, les mains, les poignets,… après quelques années d'utilisation de ce genre de choses. Cerise sur le gâteau, c'est hyper intrusif dans ton design ! Retirer ce genre de chose est une galère sans nom.
Une base de données c'est un modèle de données et un système de requête cohérent avec un certain nombre de garantie. Déplacer un bout de ta logique dans ta base de données, c'est foncé droit dans un mur.
Alors oui, tu peut avoir de bonne raison (souvent c'est la perf) pour faire des petits traitements coté db, mais je préfère faire le chien de garde pour éviter au maximum de le faire et si c'est fait réduire au maximum la logique que tu y met.
En fait je suis un peu méchant, avec couchdb ça peut avoir du sens parce que selon ce que tu fait tu peut tout mettre dans couch (tu as un reverse proxy http pour le statique et il redirige toutes les requêtes WS vers couchdb). Mais c'est vraiment un cas particulier.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10. Dernière modification le 08 mars 2016 à 11:37.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Facile!
Posté par barmic . Évalué à 1.
Ce qui n'a pas de sens. Enfin… Pas dans le sens que tu l'indique. Soit changer ton modèle a des implications métier (ça arrive forcément), soit ça impact uniquement ta couche persistance (quand tu travail en couche).
Je ne vois pas comment tu peux avoir une opération complexe qui ne fais pas partie de ta logique métier… Tu peux parler d'un code purement technique qui serait de la tambouille de données, par exemple faire une projection ou des statistiques sur tes données, mais ça je ne le ferrais jamais dans une procédure stockée. Le faire dans un code à toi, ça permet de le distribuer, de le lancer en mode batch, de l'envoyer dans un job hadoop/spark/storm,… Mais aussi de le tester avec tes outils de tests unitaires classiques.
AMHA garder le même langage que sur le reste de l'application, ainsi que le même protocole de test est bien plus efficace pour maintenir ce code.
C'est là que je vois que j'ai beaucoup évolué ces dernières années (pas forcément en bien). J'étais aussi de ton avis avant. Aujourd'hui, je ne vois pas l'intérêt d'avoir une « base de données qui se suffit à elle-même ». Ta base de données est faites pour soutenir une application et pas pour la beauté du geste.
Euh… tu as tes contraintes d'intégrité pour ça et si ça ne suffit vraiment pas tu as des triggers qui peuvent faire le boulot. Je suis pas grand fan, mais si vraiment tu veux de la cohérence forte c'est une possibilité (en se limitant à coder des invariants).
Et il est impossible d'avoir de bug dans une procédure stockée ? :)
Si j'en suis vraiment là, je préfère partir sur de l'event sourcing. Mes données sont immutables. Je reçois les données, je les stocke et ensuite je vois comment les organiser pour les rendre utilisable (sans toucher le premier stockage des données). C'est résilient (je peux reconstruire mes projections à tout moment), ça évolue très facilement et c'est facilement distribuable.
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 Kaane . Évalué à 10.
Supposons que tu es une très grosse base, ou pleins de bases, qui contiennent pleins d'éléments différents en fonction des ventes, de la techniques, des investisseurs, des fournisseurs, des clients etc.
Supposons maintenant que quelqu'un veuille faire du reporting avec des données consolidées, parfois par année ou par mois ou encore par produit pour chaque sous ensemble des données précités.
Genre un top ten des clients les plus rentables pour le mois de mars 2015, ou une liste des taux d'incidents par produit en fonction du fournisseur.
Tu as le choix entre trois solutions :
- Choix 1) un super cube OLAP, mais ça ne marche que si les types de données demandés par la direction ne changent pas trop - sinon il faut refaire tous les rapports le jour ou on décide qu'il faut ajouter le respect ou non de ISO-TrucBidule sur tous les déploiements.
Choix 2) 8000+ vues, une pour chaque découpe. C'est la teuf à la maintenance aussi.
Choix 3) Des jeux de procédures stockées et de fonctions (et autres, en postgresql le DO INSTEAD est surpuissant si bien utilisé) qui vont être utilisés comme des vues par le client de reporting - mais qui centralisent le code en un point et simplifient grandement la maintenance.
Par exemple une fonction getStatsBy(< col >) qui fournira toutes les infos consolidées possibles et imaginables avec consolidation sur la colonne spécifiée.
Clairement les procédures stockées ne doivent jamais contenir de logique métier, mais elles peuvent être extrêmement pratiques même sans ça.
[^] # Re: Facile!
Posté par barmic . Évalué à 1.
Le cas d'usage que tu décris c'est de la logique métier pour preuve tu explique que c'est des choses demandé par la direction. Un code pas métier c'est un code qui ne touche pas au besoin fonctionnel de l'application (performance, robustesse, etc).
Il y a d'autres choix que les 3 que tu donne. Par exemple tu peux gérer ça via des batch ou monter une architecture lambda si tu a besoin de temps réelle et tu as tout un tas d'organisation possibles qui vont plus ou moins impacter ton design en fonction des besoins que tu as.
J'aurais vraiment peur de cette solution. Comment ça se comporte avec un million de ligne ? 100 millions ? Si ta base est en cluster (est-ce distribué ? Est-ce que tu perçois clairement ce qui va entraîner une réduction de tes données ? Quelle est la granularité de lock que tu met sur tes données) ? Faire des traitement de plusieurs secondes sur une base (qui doit déjà prendre la charge de la production) ça me semble pas être une excellente idée.
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 Kaane . Évalué à 6.
Le cas d'usage que tu décris c'est de la logique métier pour preuve tu explique que c'est des choses demandé par la direction
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…
Sérieusement, l'exemple que je donne remplace des milliers de vues par une fonction ou procédure stockée. Les vues seraient de la logique métier selon toi ?
Il y a d'autres choix que les 3 que tu donne. Par exemple tu peux gérer ça via des batch ou monter une architecture lambda si tu a besoin de temps réelle et tu as tout un tas d'organisation possibles qui vont plus ou moins impacter ton design en fonction des besoins que tu as.
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 ?
Mon gars qui fait du reporting je préfère grandement qu'il ait une seule connexion via une seule interface plutôt que de le voir ouvrir une connexion à la DB, une autre à l'ETL et une troisième à un datastore quelconque pour pouvoir faire ses rapports.
J'aurais vraiment peur de cette solution. Comment ça se comporte avec un million de ligne ? 100 millions ? Si ta base est en cluster (est-ce distribué ? Est-ce que tu perçois clairement ce qui va entraîner une réduction de tes données ? Quelle est la granularité de lock que tu met sur tes données) ? Faire des traitement de plusieurs secondes sur une base (qui doit déjà prendre la charge de la production) ça me semble pas être une excellente idée.
Alors dans le désordre :
- Le lock : besoin très minime, c'est de la lecture seule. Si vraiment le besoin s'en fait sentir on peut créer un index sur un timestamp pour s'assurer que toutes les données étaient présentes à l'instant X et qu'aucune n'est arrivée en cours de route. Mais sur du reporting financier/marketing je ne pense pas que ce soit nécessaire (les chiffres de la dernière seconde intéressent peu de monde, généralement on fait ce type de reporting sur des données qui ont au moins 24h )
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.
Le partitionnement ou les cluster : Je ne vois pas de cas ou cela pourrait avoir un impact négatif. Une fois de plus un traitement par fonction ou procédure sera nécessairement meilleur qu'un traitement séquentiel par requête ou par vue. ne serait-ce que parce que lors d'un traitement par fonction la BDD peut travailler en format binaire interne tout du long et ne doit faire la conversion format de sortie des données qu'à la toute dernière étape.
La durée des traitement et la saturation des I/O BDD : 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. Pour finir il est nettement plus simple de limiter les I/O et la consomation CPU d'une procédure définie que de tous les accès possibles et imaginables à des vues et des tables.
A titre d'information j'utilise ce type de techniques sur des centaines de millions de lignes (données géométriques, ça va très vite) avec des temps de réponses de l'ordre de la milliseconde. 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.
[^] # Re: Facile!
Posté par barmic . É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 Kaane . Évalué à 7.
Je ne calcule pas mes projections d'une façon ou d'une autre, je créé des vues - il n'y a pas de calcul coté BDD. Une vue SQL par exemple c'est juste un test qui dit "si on te demande les données de TITI, renvoie à la place les données de TATA ". Et comme je n'ai pas envie de créer toutes les vues possibles et imaginables je fais une fonction à la place. Il n'y a aucun calcul spécifique métier qui est fait en base. Ce ne sont que des opérations de consolidation et d'agrégation génériques. Je n'ai rien besoin de valider avec mes utilisateurs si ce n'est l'interface qu'ils doivent utiliser. Plutôt que de leur dire tu fais
SELECT * from (
SELECT …
UNION SELECT …
UNION SELECT …
UNION SELECT …
JOIN
SELECT …
UNION SELECT …
…
ON …
) WHERE month=4 GROUP BY "CLIENT", "PRODUIT" HAVING SUM("CA") > 10000
Je leur dit tu fais
SELECT * FROM fonction_aggregat(['CLIENT','PRODUIT'], '{"month":"=4", "sumca":">10000"}')
Pour la base de données il n'y a aucune différence en terme SQL, il y a un petit surcout lors de la préparation de la procédure fonction_aggregat, mais qui est négligeable et qui se rembourse largement si la procédure est appelée plus d'une fois. Le surcout du parsing est infime, les I/O sont divisés par 10 par rapport à des requêtes classiques ou des vues, je peux forcer le plan d’exécution que je veux, la priorité, le temps CPU etc.
Et une fois de plus ça ne rempli pas d'autres rôle qu'une vue.
Mais pourquoi j'irais créer des fonctions (ou classes) de filtrage et de présentation de données dans mon code, alors que ça va pénaliser la base de données. Si je ressors la table entière, l'impact I/O va être délirant - si je fait une partie du filtrage coté BDD (WHERE ou HAVING) pourquoi j'irais mettre le reste du filtrage dans mon appli ? Filtrer et présenter les données c'est le boulot de la base, et elle va le faire beaucoup mieux, beaucoup plus vite (surtout en BDD relationnel) que mon appli qui voit devoir commencer par tout remapper avant de pouvoir finir le boulot.
OUI ! Le cout CPU des procédures que je cite est nul, voire négatif par rapport à une execution SQL brute de décoffrage. La première exécution va prendre quelques pouillèmes de millisecondes en plus (et encore une très grosse procédure) - toutes les exécutions suivantes seront plus rapide et moins consommatrice de CPU que l'équivalent SQL. La BDD n'aura plus à faire le préscan, à choisir entre le bitmap scan ou le seq scan ou les index, à définir la taille des rows de sortie, à dimensionner les flux etc. Tout ce travail aura été fait lors du premier appel, et les appels suivant seront plus rapides et moins gourmands que le SQL.
Les données sont en flux continue depuis plusieurs sources. C'est pas parce qu'une source change que je vais détruire toute ma base et refaire toutes mes vues.
Par rapport à des milliers de vues, ou des milliers de requètes SQL plus ou moins propres et subtilement différentes dans le code de l'appli ? Mon choix est vite fait…
[^] # Re: Facile!
Posté par barmic . É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)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Facile!
Posté par barmic . É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)
[^] # Re: Facile!
Posté par skeespin (site web personnel) . Évalué à 3.
Eh beh voilà, on a notre architecte java :D
[^] # Re: Facile!
Posté par totof2000 . Évalué à 2.
C'est comme pour les frameworks …
[^] # Re: Facile!
Posté par wilk . Évalué à 2.
Et même solution : les microservices :-)
[^] # Re: Facile!
Posté par Albert_ . Évalué à 2.
Je sais qu'ils bossent sur cela mais j'attend vraiment de voir cela, un docker windows sous linux.
[^] # Re: Facile!
Posté par flan (site web personnel) . Évalué à 5.
j'avais compris le contraire : des conteneurs Docker classiques qui tournent sur du Windows.
[^] # Re: Facile!
Posté par sifu . Évalué à 2.
J'avais compris des containers windows sur windows et des containers linux sous linux.
Après, c'était avec qemu. Non ?
[^] # Re: Facile!
Posté par Tangi Colin . Évalué à 1.
Oui, il n'y a pas de virtualisation dans docker donc le conteneur windows sur linux ou l'inverse c'est pas possible. Ce que les Windows conteneur sont c'est des API Windows (donc pas grand chose à voir avec les namespaces, capabilities, etc…) mais avec comme client "au niveau" Docker.
Donc sur Windows pour lancer un conteneur Windows je fait un
docker run … comme sur mon linux quoi, après entre les deux pas grand chose à voir, c'est juste une compatibilité de l'API docker pour gérer des "conteneurs".
Voir par ici : https://msdn.microsoft.com/en-us/virtualization/windowscontainers/about/about_overview
Et c'est déjà la, sur du windows server 2016, bon tout tourne pas encore avec, ça me parait assez loin d'être production ready mais c'est disponible. Un petit résumé par ici : https://msdn.microsoft.com/en-us/virtualization/windowscontainers/reference/app_compat
[^] # Re: Facile!
Posté par Dring . Évalué à 7.
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.
Tu as déjà eu des traitements de masse à faire sur une base SQL ? Et tu fais ça via ton appli qui charge chaque ligne, fait le calcul, et stocke le résultat ? Tu fais ça 10,000,000 fois, et tu penses que parce que tu as été super fort, en répartissant le travail sur 200 noeuds, tu as obtenu une bonne vitesse de traitement ? Quid des I/Os engendrées entre la machine hébergeant la base, et la machine hébergeant ton application ? Le franchissement de DMZ, la charge sur la baie de stockage, la non-utilisation du cache de la base, et j'en passe ?
Mon dieu…
C'est pas seulement une question de savoir où on met la couche truc et la layer bidule. C'est juste d'avoir un temps d'exécution acceptable pour répondre aux contraintes des utilisateurs.
[^] # Re: Facile!
Posté par barmic . É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 Sufflope (site web personnel) . Évalué à 8.
Ceci dit le monsieur parlait de migration. Tu peux faire du pl/pgsql (par exemple) pour les migrations en documentant que ça marche de telle version à telle version c'est tout. Pas besoin de les maintenir en toute circonstance.
Il faut aussi revenir sur terre et se dégonfler les chevilles. Non seulement tout le monde n'est pas Google, Facebook, Netflix, mais en fait personne n'est Google, Facebook, Netflix. J'avais beaucoup aimé un tweet qui mettait une bonne claque aux mecs qui disent faire du BigData parce qu'ils ont quelques dizaines/centaines de Go de data, qui expliquait en gros qu'un dédié OVH avec 128Go de RAM coûte 120€/mois, alors si ta data tient dans la RAM d'un serveur bas de gamme, faut arrêter de s'exciter.
[^] # Re: Facile!
Posté par barmic . É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 kowalsky . Évalué à 3.
Il n'y a pas que le débit, il y a la latence aussi. Tu peux avoir 20Gbs entre deux éléments, si tu as 100000000 aller retour, ça peut être long et accessoirement ça peut charger un Firewall.
[^] # Re: Facile!
Posté par barmic . É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 Dring . Évalué à 2.
Ce que tu décris, c'est l'exception ; dans la plupart des cas, plus de cache signifie moins d'I/O physiques et plus d'I/O logiques.
Sur une base pouvant tenir entièrement en RAM (i.e. moins de 200 Go pour des machines un peu récentes), j'ai vu une amélioration des performances d'environ 50% sur une machine qui saturait les I/Os entre le dataserver et le SAN.
Donc oui, je l'ai déjà testé. Plusieurs fois.
[^] # Re: Facile!
Posté par Raoul Volfoni (site web personnel) . Évalué à 7.
Ça fait plus de 35 ans que j'en écris et en lisant ce genre d'assertion farfelue je comprends pourquoi l'informatique va si mal.
Vivement la retraite…
[^] # Re: Facile!
Posté par diorcety . Évalué à 3.
J'ai aussi du mal à comprendre… Quand il s'agit de faire un choix sur le placement d'une fonctionnalité je réfléchi toujours en terme de métier. L'ingénieur bases de données s'en fou que derrière il y ai du java ou du brainfuck, il faut qu'il présente des données intelligibles par lui même. Cela peut être plus parlant avec les traductions i18n, cela viendrait à l'esprit de quelqu'un de mettre les traductions dans des fichiers java, car le reste est en java? Bien sur que non, je vois bien la gueule du traducteur si on lui file un fichier java.
Et je ne comprend pas trop l'argument de la testabilité des procédures ? Qu'es ce qui t'empêche de faire des suites de tests? Il manque peut être le framework qui va bien…
Malheureusement dans ma courte expérience et les différents exemples que l'on peut trouver, c'est très fréquent de tout mélanger pour une (pseudo) histoire de simplicité. Définir une base de données à partir du SQL généré par hibernate qui vient de beans java et d'annotation. Ces même beans envoyés directement par le WS au client. Pas grave on génère le wadl et le xsd depuis ces même beans. C'est sûr, c'est rapide à créer… C'est bien le seul point positif.
[^] # Re: Facile!
Posté par barmic . É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)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Facile!
Posté par barmic . É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)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Facile!
Posté par barmic . É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)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Facile!
Posté par barmic . É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)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1. Dernière modification le 10 mars 2016 à 15:34.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Facile!
Posté par barmic . É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)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Facile!
Posté par barmic . É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)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Facile!
Posté par barmic . É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 flan (site web personnel) . Évalué à 3.
Ça va être pareil avec toutes les technos de ta solution. Tu fais du Windows et ils ne connaissent que Linux (ou inversement) ? ça ne va pas coller.
Tu fais du Java et ils ne font que du PHP ? ça ne va pas coller.
Tu ne connais que login/password pour l'authentification et ils ne font que du Kerberos ? ça ne va pas coller.
Ton appli web ne fonctionne que sur Chrome alors qu'ils sont encore sous IE 6 ? ça ne va pas coller.
Bien sûr, dans plein de cas (par exemple Redmine), les accès SQL seront assez simples et ça n'a pas beaucoup d'intérêt d'avoir une forte adhérence à un logiciel en particulier. Pour contre, quand ça a un intérêt, je ne vois pas pourquoi il faudrait s'en passer.
Que dire d'ailleurs de Cassandra, MongoDB, … ? Pour le coup, ils ne sont absolument pas remplaçables.
[^] # Re: Facile!
Posté par Dring . Évalué à 5.
D'abord, je veux te rassurer : tu n'es pas en rupture avec ta philosophie "non aux procédures stockées" ; en fait de mon expérience c'est plutôt la masse qui sort de l'école d'ingénieur qui pense comme toi.
Sur ces individus, je les classifie in fine en deux catégories.
1) Ceux qui n'ont jamais eu à vivre la V2 ou la V3 des projets sur lesquels ils bossaient. Eux continuent de penser que les procédures stockées, c'est une émanation de l'enfer qu'il faut proscrire pour toujours.
2) Les autres, qui ont fini par s'en servir lorsque cela faisait du sens.
J'ai vu des énormes projets (i.e. > 10 mio €, au moins étalés sur 3 ans) partir avec une équipe d'architectes, pleins de bonnes intentions, choisir tous les frameworks, écrire les briques manquantes, faire une V1. Puis se rendre compte que finalement, il leur fallait 4 dataservers Oracle, du Dataguard, et une dizaine de serveurs Weblogic pour intégrer les 300,000 instructions à traiter quotidiennement.
Deux ans plus tard, sur le même projet, au moins un gros traitement sur deux a été écrit (ou réécrit) en procédure stockée.
A l'inverse, j'ai vu des applications gérant les mêmes volumes, s'orienter directement vers de la procédure stockée pour les morceaux impliquant des grands jeux de données, se contenter d'un serveur de données banal, un serveur d'application, et traiter les même volumes sans sourciller.
Par ailleurs, il y a un point important que tu peux considérer. Si tu utilises du Java ou du C# (le grand classique dans les grosses organisations), ton application est en fait un gros package qui contient une grosse quantité de code. Et quand tu dois livrer en production, pas question de livrer juste la classe que tu as touché ; non, tu dois livrer la totalité. Et passer par tout un processus, bien lourd, bien chiant, et bien risqué.
Par contre, toute la couche en base de données, pour livrer un correctif, tu peux relivrer juste ta procédure stockée.
Oui, on peut livrer à chaud une classe dans n'importe quel serveur d'app, ou même un conteneur de servlet à la Tomcat. Mais c'est juste généralement pas autorisé ; ou pas fiable (mon dieu, le nombre de fois où j'ai vu en dev mon jboss merder à la suite d'un changement de classe).
Dans les mêmes organisations, tu peux relivrer une unique procédure stockée sans toute cette lourdeur. Et paf, la procédure stockée te permet une agilité dont tu ne peux même pas rêver sur la couche Java/C#.
[^] # Re: Facile!
Posté par barmic . Évalué à 3.
Si ça t'intéresse, je me permet d'ajouter un lien qui montre que je ne suis pas le seul à avoir rencontré ce genre de problème :
http://blog.xebia.fr/2016/03/16/perennisez-votre-metier-avec-larchitecture-hexagonale/
Sans même aller jusqu'à la description de l'architecture, l'introduction présent exactement les problèmes que j'ai décris plus haut.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Facile!
Posté par barmic . Évalué à 3. Dernière modification le 16 mars 2016 à 14:44.
Tu pars d'une hypothèse « j'ai fais un bon choix dès le départ » et je ne vois pas comment tu peux l'affirmer.
Je peux ajouter d'autres ressources de gens qui affirment la même chose : https://www.thoughtworks.com/talks/agile-architecture-rethink-2014 et qui ne font pas parti d'une SS2I (Martin Fowler c'est déjà un peu plus respectable ?)
Je l'ai déjà dis, l'article redis la même chose presque mot pour mot (je ne travail pas chez Xebia) : t'a boucle de feedback est grande, tes tests sont longs (à écrire comme à exécuter), t'a donc tendance à en faire moins,… Je vais pas redire encore une fois tout le tralala. Les tests d'intégration n'ont pas la même complétude que les tests unitaires.
Une expérience qui peut être intéressante est de faire du DDD. C'est de ce que je connais la manière la plus efficace de tester la logique métier.
Pas forcément. Ton logiciel évolue ces contraintes aussi donc les technologies que tu utilise n'ont plus forcément la même pertinence. Même sans changer de technologie, ta techno sous-jacente peut évoluer et ce que tu faisais d'une manière à une époque peut avoir était déprécié 5 ans plus tard.
Avoir plus de tests et un feedback rapide, ça ralenti ?
C'est le choix de la bonne abstraction. Je serais joueur, je t'expliquerais que tu choisi la bonne abstraction au départ et donc que ça va (c'est comme choisir des techno). Comme je ne le suis pas je te dirais qu'avoir des abstractions dirigés par ton besoin métier est vraiment intéressant, parce que la taille de ton adaptateur va dépendre de la pertinence de ta techno sous-jacente. Ça te donne un élément très utile sur comment choisir tes technologies.
Je suis tout à fait d'accord ce n'est pas une solution miracle, mais c'est une solution intéressante.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Facile!
Posté par barmic . Évalué à 3.
Non, un bon choix à un moment donné n'a pas de raison de le rester.
Oui mais c'est précisément l'inverse dont il est question : tester du fonctionnel via des tests d'intégration. Les tests d'intégrations sont longs par nature, c'est pour cela qu'ils couvrent moins (et aussi parce qu'ils font exploser la combinatoire).
Je ne dis pas qu'il ne faut pas faire de test d'intégration, je dis que c'est dommageable d'essayer de tester le métier par des tests d'intégration.
C'est un bon moyen de se planter. Parce que je doute que tu sois meilleur devint que moi. Ton client non plus, lui refourguer cette responsabilité ne change rien au problème (ça change juste la responsabilité). C'est le principe même de l'over-engenering imaginer beaucoup et surtout beaucoup trop.
Au contraire réduire ton scope de décision au minimum et remettre à plus tard tout ce qui peut l'être jusqu'à être assez mûre pour choisir. Ce que tu propose est typiquement le cycle en V dans le quel les erreurs sont très chères ! (à tous point de vu)
Ça dépend de ce que tu entends par livrer. Si on entend par là, la livraison où l'utilisateur est satisfait de sa fonctionnalité, les tests ne coûtent rien. Ils ne coûtent rien face au temps que te coûte un bug dans la livraison et que la perte de confiance de l'utilisateur envers ton logiciel.
Ça n'a rien avoir. Il s'agit lors de ton développement du temps que tu as entre l'écriture d'une ligne et la vérification qu'elle fait ce que veux. C'est le cycle (dans la majorité des cas) :
Si ton exécution c'est des tests, tu vérifie plus rapide l'ensemble de test cas que. Si tu le fais manuellement, tu n'aura tendance à vérifier que le cas que tu es entrain de traiter (en oubliant éventuellement les cas qui sont impactés) et tu perd du temps à revenir dans l'état qui te correspond. Si tu attends que le client t'envoie un mail, euh… comment dire… :)
Ton métier évolue généralement peu. L'abstraction devrait donc rester pertinente. Cette abstraction n'est pas quelque chose qui est artificiel, elle est dépendante de ton métier. Donc elle ne doit pas être remise en cause par la technologie, mais par le métier (c'est l'idée à travers l'inversion de dépendance). Si ça devient une plaie, c'est soit que tu as mal conçu ton abstraction (ça arrive) soit que tu dois remettre en cause ta techno.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Facile!
Posté par barmic . Évalué à 3.
Explosion est peut être fort, mais je suis même pas sûr. Parce que tu va aussi devoir tester l'intéraction entre un bout de ton code métier (celui de la procédure stockée avec le reste du code métier). Un cas d'usage peu impliquer tes 2 parties par exemple.
L'idée ce n'est pas d'anticiper, c'est de ne pas se fermer des portes (c'est différent). C'est différent. On ne fait pas quelque chose parce qu'on sait que dans 6 mois il y aura X, on le fait parce qu'il y aura X, X', X" ou rien du tout. On présume le moins possible de ce que sera X et de ce qu'il impliquera, parce que les besoins peuvent changer beaucoup trop entre temps.
(Au passage Martin Fowler est l'un des co-auteur du manifeste agile)
Les méthodes agiles expliquent clairement que ton scope correspond à une itération et que tu n'a pas à hésiter à refactorer profondément ton code. Ton scope ce n'est pas un contrat de 18 mois, mais une itération d'un mois par exemple.
Le job ça va être de trouver la techno qui permet de réduire cette glue, mais tu ne fais pas ça rien. As toi de mettre en balance ce que ça va t'apporter par rapport à ce que ça te coûte (mais ça ne te demande pas de revalider le métier c'est déjà pas mal :) ).
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 Dring . Évalué à 2.
Désolé de me (ré)insérer dans cette discussion.
Tu pars du principe (fort louable) que les tests unitaires/d'intégration sont bien faits, bien maintenus, etc.
De tous les projets que j'ai vu, on a cette approche sur les 6 à 12 premiers d'un projet. Puis ça part en sucette. Pas toujours, certes. Mais très souvent. Dès que la pression commence à monter.
Ce qui fait qu'hélas, l'argument "c'est plus facile à tester" perd beaucoup de sa superbe face à "c'est plus facile à livrer en production".
Maintenant, si sur les projets que tu as vu, la couverture de test reste une priorité sans limite de temps, j'applaudis des deux mains et je te souhaite tout le bonheur du monde. Mais vraiment, c'est pas ce que j'ai vu jusqu'ici, et des projets, j'en vois passer beaucoup (environ 30 nouveaux projets par an dans le secteur bancaire, aux alentours de 15 000 jours/homme).
[^] # Re: Facile!
Posté par barmic . Évalué à 4.
Je ne suis pas d'accord et je me battrais avec mon chef de projet pour que ce ne soit pas le cas.
Je ne connais pas de projet qui soit à plus de 80% de couverture, mais ça n'empêche pas que s'empêcher de tester son code ne me semble pas du tout être une bonne idée. Classiquement l'équipe de dev sait quel partie est correctement testée et la quelle ne l'est pas et c'est systématiquement quand il y a des tests que les évolutions sont plus rapide. Je ne fais presque plus de refactoring, sans avoir créer de test de cette partie. D’expérience ça crée beaucoup trop facilement de bug autrement.
Je n'ai pas encore réagi à ça, mais c'est vraiment problème d'organisation plus que d'architecture. Tu bousille tes données aussi bien avec l'un qu'avec l'autre, utiliser cette différence, c'est juste jouer sur l'incompétence de ton client. Il y a des millions de façons pour réduire le temps de mise en production. Il n'y a que la politique comme goulot d'étranglement et pour faire face à ça, je joue sur 2 plans :
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 Dring . Évalué à 2.
Je pense qu'on est effectivement pas dans le même monde, et ce n'est pas du tout péjoratif : en fait je t'envie.
J'ai d'un côté mon "client" (le métier sponsor de l'application et demandeur d'évolutions) qui voudrait que tout aille très vite, donne son accord à tout pourvu que la réactivité soti là, et de l'autre ma production informatique (typiquement une filiale du groupe dédiée à l'exploitation informatique) qui est accrochée à ses procédures, son respect idéologique à ITIL et surtout à son implémentation locale.
Quand j'ai un bug fonctionnel, que je peux corriger rapidement parce qu'il est dans une procédure stockée, je peux faire la modification et ne livrer que cette procédure stockée. Une fois que le fix est testé, je peux faire une demande de livraison pour ce morceau uniquement, pour lequel on va me donner un accès (temporaire) à la base de production. Je livre vite, mon client est content. Ma production informatique, elle, s'en fout : le périmètre du changement est maîtrisé donc le risque est faible.
Si il est dans la couche Java/JSP/Javascript/… je dois relivrer un EAR complet. Là, c'est l'artillerie lourde, je fais une demande, elle sera prise en compte sous une semaine. Je n'ai pas et je n'aurais jamais accès à la machine hébergeant mon serveur d'app, donc je suis totalement dépendant de ma production pour ça. En fonction de la modification, si en plus il y a un changement de structure de base, je suis obligé d'arrêter l'application, et donc le service, en pleine journée ou attendre le week-end (oui, nos applications tournent 24/5). Par défaut, on ne peut pas arrêter nos applications plus de 15 minutes en journée, sinon les pertes financières peuvent être abyssales.
Je peux montrer tous les tests de la terre, un zoli écran Sonar montrant ma couverture de test unitaire (j'essaye d'être au moins à 50%), mes tests automatiques (un automate simulateur de flux d'entrée/sortie), mon respect des règles de codage, etc. Ca ne change rien ; ma production s'en fout, s'en est toujours foutue et continuera ainsi bien après ma retraite.
Le seul cas où je peux accélérer les choses, c'est en cas d'incident majeur, mais auquel cas je dois justifier de la gravité et de l'impact, faire une escalade hiérarchique pour obtenir 2 ou 3 tampons. Autant dire que si je fais ça trop souvent, je peux mettre tout de suite un terme à ma carrière et partir élever des chèvres dans le Larzac. Donc c'est réservé à la résolution d'incident avec impact, pas juste pour faire plaisir à mon client. Et c'est pensé pour être comme ça, ce n'est pas un effet collatéral.
[^] # Re: Facile!
Posté par barmic . Évalué à 4.
Ce genre de découpage (que j'ai connu en moins violent dans un sens parce que ce n'était pas ma boite qui faisait l'IT) est juste une abomination (c'est pas contre toi, hein ?). J'ai passé un temps assez insensé à expliquer à des gens dont le boulot consiste à ne pas faire tourner ton application comment l'installer. Outre les temps de cycles incroyables, ça génère énormément d'erreur de la part des exploitants (je pense que tous les exploitants que j'ai rencontré n'avaient rien à faire de comprendre ce qu'ils faisaient).
(je continue de parler de ceux que j'ai rencontré) ceux qui s'occupent de ça ne veulent aucun changement. Ça se protège derrière l'ITIL, mais l'automatisation à la chef/pupet/ansible ils en veulent pas, alors des concepts comme les infrastructures immutables tu te doute bien que ça les dépasse de plusieurs magnitudes.
Si j'avais à revivre ça ce serait pour 3 mois maximum… Je suis jeune je n'ai pas d'engagement, d'attache ou autre. Le marché du travail est florissant. J'ai pas envie de me fader des gens dont le seul but est de m'empêcher de faire mon boulot. Je ne fais pas assez de yoga/tai chi pour endurer ça sereinement :)
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 Michaël (site web personnel) . Évalué à 2.
Là où un peu de pédagogie est nécessaire est certainement qu'il faut bien expliquer qu'une partie de test et de mise au point est inévitable. Ceci étant quel statut donner à ce travail? Faut-il se contenter des résultats immédiats (ça marche, on livre) et oublier le reste du travail fait ou bien faut-il le sauvegarder, l'incarner, dans des artefacts sous contrôle de version, des tests automatiques? En plus des bénéfices que tu soulignes qui se révèlent payants sur le long terme, souligner que c'est un travail qui va de toute façon être fait et que la vraie question est s'il faut l'organiser pour l'automatiser ou juste l'oublier est un argument qui “touche” parfois.
[^] # Re: Facile!
Posté par windu.2b . Évalué à 3.
Mon optimisme espère que le mot manquant est "mois", mon réalisme tend à croire que c'est en fait "jours"…
[^] # Re: Facile!
Posté par Dring . Évalué à 2.
Je pensais à "mois", mais je suis certain qu'il est déjà arrivé que ce soit "jours". De toute manière, c'est dès que la pression monte et qu'on commence à bosser dans l'urgence.
[^] # Re: Facile!
Posté par Tonton Th (Mastodon) . Évalué à 2.
Là, je pense qu'un bon argumentaire serait le bienvenu, même si on est pas trolldi matin…
[^] # Re: Facile!
Posté par arthurr (site web personnel) . Évalué à 3.
BULLSHIT ! PostgreSQL sait très bien charger un dump d'une version antérieure dans la toute dernière version.
Encore faut-il savoir utiliser correctement PostgreSQL.
Que tu aimes ton SQLServer ; OK, mais merci de ne pas parler de ce que tu ne connais pas.
Salutations,
Un DBA PostgreSQL heureux.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Facile!
Posté par arthurr (site web personnel) . Évalué à 0. Dernière modification le 08 mars 2016 à 17:41.
C'est bien, tu critiques un outil que tu ne maitrises pas, félicitations !
A aucun moment je ne te juge, je dis juste que TU juges un SGBD sur une manip non décrite que tu ne semble pas maitriser pour en sortir une conclusion absurde. Donc, oui, tu dénature MON SGBD.
Et je te confirme, j'utilise PostgreSQL depuis très très longtemps et pas en mode bidouilleur : c'est mon métier.
Pour moi, tes propos sont juste : BULLSHIT !
merci de ton attention et bonne route avec ton choix que tu assumes.
[^] # Re: Facile!
Posté par Thomas Debesse (site web personnel) . Évalué à 0.
On n’est pas obligé d’être grossier. Il y a des gens qui moinssent pour ça, qu’on ait raison ou tord d’ailleurs. :-)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Facile!
Posté par ɹǝıʌıʃO . Évalué à 7.
Sur DLFP, les grossièretés sont moinssées, mais le tord tue.
[^] # Re: Facile!
Posté par Thomas Debesse (site web personnel) . Évalué à 1.
Je t’ai plussé ! /o\
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Facile!
Posté par El Titi . Évalué à 1.
Non !
Sur DLFP:
On torD le français à torT et à travers.
On tourne en rond comme un torE
et on se met des torRs de pression.
[^] # Re: Facile!
Posté par arthurr (site web personnel) . Évalué à -3.
Bullshit c'est grossier ? je ne savais pas : je ne parle pas anglais :)
je présente donc mes excuses à bull et shit …
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Facile!
Posté par arthurr (site web personnel) . Évalué à -1.
OK, pas de problème !
Tu m'expliques juste que les dump de PostgreSQL ne sont pas restaurables et si c'est vrais : c'est un BUG majeur qu'il faut remonter.
Je n'ai jamais vu ce cas et pourtant je passe ma vie à coller des dump d'une version à une autre sans aucun problème.
Bref … je suis heureux que tu sois heureux avec ton nouvel ami, mais je ne peux pas te laisser dire que PostgreSQL ne sait pas restaurer un dump.
En te souhaitant une très bonne journée et une vie plein de bonheur
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Facile!
Posté par arthurr (site web personnel) . Évalué à 4.
Heu, c'est pas une façon de généraliser ça ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Facile!
Posté par Albert_ . Évalué à 2.
Ben il a eu UNE fois le probleme donc forcement c'est la faute a PostgreSQL et cela demontre bien que le logiciel libre c'est de la merde.
[^] # Re: Facile!
Posté par arthurr (site web personnel) . Évalué à 2.
je te plussois en partant du principe que c'est ironique ! :)
[^] # Re: Facile!
Posté par Sufflope (site web personnel) . Évalué à 3.
Là il est ironique mais le souci avec Albert_< c'est qu'en général il dit ça au premier degré mais concernant un produit Microsoft. C'est de l'autodérision involontaire.
[^] # Re: Facile!
Posté par Nico C. . Évalué à 7.
Quand on est coincé pour des raisons historiques/techniques/politiques avec une base MSSQL server, je vois tout de même un certain nombre d'avantages à passer sous linux… l'automatisation, l'administration, stabilité, capacité a utiliser les grands cloud publics, le cout de l'OS, etc
Ou juste pour tenir le temps d'une migration vers une autre techno par exemple ?
Et puis ça fait jamais de mal d'avoir une solution supplémentaire dispo sous linux. Ca renforce sa crédibilité (si il y en avait encore besoin) et sa pénétration.
[^] # Re: Facile!
Posté par pasBill pasGates . Évalué à 2.
On va dire plutôt que tu y vois la possibilité d'utiliser un OS que tu connais plutôt qu'un OS dont tu connais si peu que tu ne sais pas qu'il est stable, totalement automatisable, présent sur tous les clouds grand public …
[^] # Re: Facile!
Posté par groumly . Évalué à 4.
Mouais, c'est un peu comme les mecs qui essayent de te fourguer du freebsd parce que c'est libre, automatisable blablabla.
Le fait est que le gros du boulot dans le monde devops se fait pour linux, et si tu veux pas pleurer en voyant "feature truc, supporte sous linux, experimental sous bsd, windows allez vous faire foutre" ajoute dans ansible/puppet/chef, tu vas pas sous windows.
Et on peut aussi parler de la gestion des licences, que ce soit en dev ou en prod. c'est plus simple de filer une vm linux a tes ingenieurs que de sortir l'artillerie lourd parallels/vmware pour faire tourner windows (parce qe bien evidenment, tes ingenieurs sont sur des macs).
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Facile!
Posté par Psychofox (Mastodon) . Évalué à 4. Dernière modification le 08 mars 2016 à 14:35.
Je crois que ce choix de supporter linux est très orienté cloud étant donné que le choix en terme d'offres dans le nuage est à ma connaissance plus grand et plus économique en terme solutions linux que windows. J''ajouterai qu'il y'a probablement aussi un intérêt marketing à une époque où une solution qui rend un client captif de ses choix passés n'est pas très vendeuse.
# Sybase / SAP ASE
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 5.
MS-SQL Server est issu d’un fork (après rachat) de Sybase, qui est depuis chez SAP, et je crois que leur version tourne toujours sous différents Unix, mais je ne sais pas du tout ce que ça donne. Certains ici connaissent ?
[^] # Re: Sybase / SAP ASE
Posté par Dring . Évalué à 4.
J'utilise ça tous les jours et ça fonctionne plutôt bien.
Par contre, pleins de fonctionnalités sont en option (minimal logging, compression), le transac-sql (langage de procédures stockées) évolue très très très lentement. Bref, je bave devant un postgresql.
L'autre soucis c'est que c'est tellement en perte de vitesse que le support se dégrade : plusieurs semaines pour le correctif d'un bug qui fait crasher le dataserver systématiquement…
# manque plus que office
Posté par Albert_ . Évalué à 3.
J'avais toujours dit que si il n'y avait pas le moindre logiciel Microsoft dispo sur linux cela n'etait ni pour une raison de taille de marche ni une raison technique mais une raison politique.
Voir ce genre d'annonce montre bien que linux est, malgre tous les efforts de MS et des ses afficionados, la et bien la et il ne peut plus etre ignore sous peine de perdre trop de part de marche.
[^] # Re: manque plus que office
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Ça commence à faire un petit bout de temps que MS ne l'ignore plus. Leur offre cloud Azure propose du linux depuis je ne sais combien de temps.
De la bouche même du PDG en 2014 : Microsoft Aime Linux.
[^] # Re: manque plus que office
Posté par Albert_ . Évalué à 3.
Il y a tout de meme une difference entre propose du linux sur un cloud et développer un logiciel pour linux. Maintenant je ne me fait pas trop d'illusions sur la disponibilité de office sous linux.
# Remarque de forme
Posté par Philip Marlowe . Évalué à 9.
C'est ce qui s'appelle renverser le sens de l'information. Pour continuer à exister de manière significative dans le monde numérique en plein chambardement, où sa domination d'antan fait plus que vaciller, Microsoft a intérêt (j'écrirais bien est forcé mais ce serait biaisé) de porter certains de ses outils sous Linux, cloud oblige. On se demande bien par quelles critiques l'accusation de constituer un cancer pourrait être remplacée. Et cette accusation de cancer n'avait pas été lancée par le pair d'un commentateur mal informé ou peu instruit et à l'expression incertaine de DLFP, mais bien par son dirigeant d'alors.
Les choses ont bien changé. Plutôt que s'adonner à ce genre d'activités discutables, les nouveaux dirigeants préfèrent œuvrer dans l'intérêt direct de leur compagnie. Leur monde est devenu plus concurrentiel. Se frapper le torse tel un gorille serait désormais considéré comme incongru.
# C'est génial
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 8.
J'attends impatiemment Internet Explorer sur ChromeOS.
[^] # Re: C'est génial
Posté par Sufflope (site web personnel) . Évalué à 3.
https://github.com/MicrosoftEdge/ tiens tu peux commencer à proposer des pull requests.
[^] # Re: C'est génial
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 2.
Je voulais surtout IE et non pas Edge, c'est pour faire plaisir à Mr Lunardelli : « Pas de support de Safari, d’Internet Explorer, d’Opera et pas même de Firefox. » et au passage gagner quelques paris.
[^] # Re: C'est génial
Posté par procauxfiefs . Évalué à 4.
Oh, oui!
Ça se trouve, ces petits cachottiers de chez Microsoft ont déjà porté ie6 et MSOffice, et donc, enfin GNU/Linux sera prêt pour le bureau.
# Ce que Bill Gates en pense…
Posté par Foutaises . Évalué à 4.
… et qu'il a dévoilé lors de son AMA sur Reddit.
[^] # Re: Ce que Bill Gates en pense…
Posté par steph1978 . Évalué à 0.
J'aime à croire que ça lui fait un tout petit peu mal au cul de constater qu'il n'a pas pu créer aussi un monopole dans le monde serveur et mobile.
Dans le monde serveur, il faut croire qu'on embobine pas un professionnel de l'informatique comme on embobine un utilisateur de bureautique.
Et dans le monde mobile, il est arrivé trop tard pour pouvoir verrouiller le marché.
[^] # Re: Ce que Bill Gates en pense…
Posté par barmic . É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: Ce que Bill Gates en pense…
Posté par Tonton Th (Mastodon) . Évalué à 2.
Gni ? Quel rapport entre Bill Gates et PalmOS ?
[^] # Re: Ce que Bill Gates en pense…
Posté par Frank-N-Furter . Évalué à 2.
À l’instar d’autres fabricants de mobiles (Danger, Nokia, etc.) ils se sont associés à Microsoft, pour en mourir brièvement après.
Il y avait des Treo qui tournaient sous Windows Mobilbleurgh.
Depending on the time of day, the French go either way.
[^] # Re: Ce que Bill Gates en pense…
Posté par Blaise (Mastodon) . Évalué à 3. Dernière modification le 10 mars 2016 à 10:20.
Ils étaient tous les deux présents sur le marché, en concurrence, avant les acteurs actuels. PocketPC vs PalmOS la guerre en ces temps là non ?
[^] # Re: Ce que Bill Gates en pense…
Posté par barmic . É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)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.