Laurent J a écrit 2951 commentaires

mais c'est en aucun cas une excuse pour que la base avale sans broncher derrière.

La base a fait ce que l'application et le développeur lui ont indiqué de faire. (mauvais choix du type de stockage etc). Elle a avalé sans broncher parce qu'on lui a dit de ne pas broncher. Dans mysql, ce n'est pas un bug, c'est une fonctionnalité (bah oui, on a besoin parfois qu'il n'y ait pas de contrainte d'intégrité, pour diverses raisons, comme la performance, et donc avec mysql, on peut choisir un moteur de stockage qui ne bronche pas)

Si il y avait des tests, le problème aurait été détecté immédiatement, que l'origine du problème ait été la base ou le code.

c'est quand même plus léger et lisible.

Ouai, alors, ou tu es un super admin de la mort qui tue, et que des millions de lignes de CSV ne te font pas peur. Ou alors tu n'as jamais administré de vrais serveurs.

Parce que CSV ou XML, dans un vrai contexte de production (un serveur relativement chargé, ou pas d'ailleurs), les logs sont de toutes manières illisibles, tellement il y a d'enregistrement, et nécessite donc des outils pour analyser et chercher quelque chose.

effectivement, à y regarder de plus près une clé étrangère fait référence à une clé primaire inexistante.

Donc quelque part, ton code est pourri.

mais encore quelques heures plus tard, je me retrouve avec des données corrompues. [..] MySQL ne retourne pas d'erreur quand on insère une valeur incorrecte dans un champ

Donc quelque part, ton code est pourri.

Et ils sont où tes test unitaires et fonctionnels ?

Parce que tout ça, même si la base de donnée ne te renvoi pas les erreurs ou autre, tes tests unitaires te l'auraient montré, avant même que tu passes en prod.

Sans parler que, comme il a été indiqué plus haut, tu n'as pas cherché à te renseigner sur l'utilisation de Mysql et ses particularités SQL (qu'ont toutes les bases de données, y compris SQLite, qui a quand même la syntaxe SQL la plus pauvre que je n'ai jamais vu).

Bref, pour moi, le problème se situe surtout entre la chaise et le clavier.

Mauvaise méthode de dev, changer méthode de dev.

PS: je ne cherche pas à défendre MySql, qui, il est vrai, a quelques "particularités" parfois désagréables. Mais il en a d'autres qui facilitent tellement la vie…

Euh non, on n'utilise pas SQLITE sur un serveur web, ce n'est absolument pas fait pour. Concurrence d'accés et cie, bonjour les fichiers corrompus après.

Le web par ci le web par là, chez Mozilla Internet ça se résume par le web,

bah oui, c'est leur truc.

C'est comme si tu te plaignais qu'un restaurant, spécialisé dans la cuisine du sud ouest et se lançant dans la vente à emporter, fournisse ses plats dans des barquettes plutôt que sous forme de sandwich. Bah oui mais non, eux, c'est la cuisine du sud ouest qu'ils savent faire, pas les sandwichs. ni les pizzas.

maintenant en voulant "libérer" les smartphones tels des chevaliers blancs, ils vont niveler nos terminaux par le bas

Mozilla ne pretend pas être des chevaliers blancs. Si le fait de faire tout en html/js ne plait pas, de projets comme Meego et cie n'ont qu'à se bouger. Et si ils ne peuvent pas se bouger (faute de moyen ou autre), ce serait la faute de Mozilla ? N'importe quoi n'est-ce pas…

Si QT est meilleur sur smartphone (chose que je suis incapable de juger), bah monte ta boite, ou prend le lead de Meego ou je ne sais quel projet, tu as à priori des chances si html/js c'est si merdique que ça ;-)

Mozilla n'a pas vocation (ni les moyens) de sauver tous les projets libres moribons, hein..

ok, on a compris que tu n'aimes pas les technos web pour faire des applis. Pas la peine d'en rajouter 3 couches.

Et pas la peine de taper sur Mozilla parce que Meego est plus ou moins à l'abandon. Prends-en toi plutôt à ceux qui l'ont abandonné.

Et je ne vois pas pourquoi Mozilla devrait reprendre Meego. Ce qu'ils maitrisent, ce sont les technos web, ils essayent d'améliorer ces technos. Leur domaine, c'est le web, c'est la défense d'un web ouvert etc.

Donc bref, meego, ça ne correspond pas vraiment à ce qu'ils savent faire, à ce qu'ils maitrisent. Et donc à priori, il n'y a pas vraiment de raison qu'ils réussiraient mieux que les autres à populariser Meego.

Et comme ils savent très bien que le web n'est pas fait pour faire comme les apps natives

Ouai, enfin, tu sais, le XUL, c'est pas éloigné de la stack des technos web (s/html/xul). Et ils utilisent ces technos depuis près de 15 ans pour faire des applis (dont une qui s'appelle Firefox..).

Reprendre Meego qui fait déjà tout ça et est conçu pour

ah ouai, c'est sûr, reprendre des millions de lignes de codes qu'on ne connait pas, ça se fait en un claquement de doigt.

Non non, mysqlnd n'est pas écrite en PHP, mais bien en C. http://svn.php.net/viewvc/php/php-src/trunk/ext/mysqlnd/

Non, les boites postales n'ont certainement pas été créés pour remplacer l'adresse d'un siège sociale d'une société (aussi petite soit-elle comme celle d'un autoentrepreneur). C'est même carrément interdit. (un coup de google pour t'en convaincre : http://www.juritravail.com/Question/domicilier-son-siege-social/Dossier/Id/5811 )

quand tu es autoentrepreneur, en général, tu n'as pas vraiment d'autres locaux que le domicile familial..

Je confirme, après avoir eu mon statut d'auto-entrepreneur (que je n'ai désormais plus), j'ai commencé à recevoir les offres de Google.

Mais pire, si vous recevez ce genre de courrier, il y a de fortes chances que votre adresse soit publique, et récupérable via une recherche de votre nom, sur google map par exemple. Et pour les entrepreneurs, l'adresse est souvent une adresse privée, qu'on ne veut pas forcément rendre publique (bon, ça dépend de l'activité après..). Le souci est que pour la faire retirer, y a moyen (il faut faire la demande via le site, ils envoient un courrier avec un code qu'il faut indiquer sur le site pour confirmer la suppression), mais il y a des chances que cette suppression ne soit pas effective sur le moyen terme. Vous êtes à nouveau référencé au bout d'un moment, même si vous n'êtes plus en activité (ça m'est arrivé)

il semble que ce soit la meilleure lib qui existe

c'est bien dommage. Parce qu'à priori, son algorithme est tout pourri (désolé pour ce vilain mot, mais je n'arrive pas à trouver d'autres termes).

J'utilise personnellement une lib de diff en PHP, qui est plutôt efficace https://github.com/jelix/jelix/tree/master/lib/diff

Je sais que le site est en ruby, mais peut-être pourriez-vous vous inspirer de l'algo...

C'est pas en soit déjà un problème ? Pourquoi le fait de l'avoir donné pour accéder à tes sites les a rendu disponibles à toutes les extensions ?

Parce que le fait que j'ai donné mon mot de passe a débloqué le gestionnaire de mot de passe.

Il est très difficile voir impossible pour un composant (donc ici le gestionnaire de mot de passe), de distinguer qui l'appel (c'est l'extension A? B?).

Bon maintenant, je n'ai pas une connaissance assez approfondi du gestionnaire de mot de passe pour te dire ce qui est faisable ou pourquoi ça le fait exactement.

Il faudrait que chacune redemandent le mot de passe

Oui, c'est ce qu'il faut. Mais apparemment, c'est à l'extension de le faire.

Ainsi pour cette extension, il faudrait que quand tu clique sur l’icône, il te demande ton mot de passe. Ça limite déjà pas mal la possibilité pour quelqu'un de voir tes mots de passes via cette extension.

C'est que j'ai expliqué : c'est ce qu'il faudrait qu'elle fasse ! (au moins par elle-même)

J'ai du mal à comprendre ce que tu veux faire exactement. Tu veux faire une interface utilisateur avec canvas ?

Parce que si c'est le cas, canvas n'est pas fait pour ça.

ce trou existe avec l'extension.

Elle devrait redemander le mot de passe principal pour afficher les mots de passe. Actuellement, elle peut récupérer les mots de passe parce que j'ai déjà tapé mon mot de passe principal. Mais elle devrait redemander ce mot de passe pour afficher. Comme le fait le gestionnaire de mot de passe. Que tu ais déjà tapé ou non le mot de passe principal en début de session, le gestionnaire te redemande le mot de passe principal, pour s'assurer que c'est bien toi qui veut voir TES mots de passe (et pas un gars qui squate ton PC pendant une absence de quelques minutes par exemple).

Aie aie aie.. Pour ceux qui ont un mot de passe principal, je vous recommande de désinstaller l'extension password reuse visualizer. Cette extension ne demande même pas le master password avant d'afficher les mots de passes, comme le fait le gestionnaire de mot de passe.

Pour moi, ça craint...

de peur de se prendre une soufflante du père Glazman

pas du tout. Daniel n'a que peu d'influence sur les décisions de Mozilla depuis quelques années. Mozilla ne laisse pas mourrir XulRunner, pour la simple raison que Firefox est basé dessus. Mais Mozilla ne met plus en avant XulRunner, parce qu'ils ne veulent pas dépenser leur énergie sur ce projet en terme de dev, marketing et autre. S'occuper d'un produit de la nature de XulRunner, c'est s'occuper à essayer de résoudre toutes les problématiques des développeurs utilisant cette plateforme, problématiques qui ne rentreraient pas dans les objectifs actuels de Mozilla. Ils préfèrent se concentrer sur la plateforme purement web. Ils bossent ainsi sur la plateforme XUL, uniquement pour répondre à leurs besoins (à ceux de Firefox, TB et autres), et non aux besoins des autres.

Maintenant il y a pas mal de "cinglés" comme moi qui utilisent XulRunner et gecko pour leurs projets, parce qu'ils trouvent cette plateforme géniale malgré ses défauts.

De plus, vu que XulRunner n'est qu'un main() un poil différent de celui de firefox, et ne contient pas les fichiers XUL/JS/CSS de firefox (en gros), refaire un XulRunner ne serait pas compliqué. Le seul moyen pour Mozilla de tuer XulRunner, serait de tuer XUL et tout ce qui va avec (système d'overlay etc). Ce qui n'est pas près d'arriver...

Je ne vois en quoi le fait que ce ne soit pas le but devrait m'empêcher de le faire...

Certes. Mais tu t'embarques dans un truc pas adapté, donc qui te prend 10 fois plus de temps à réaliser que si tu utilisais des outils plus adaptés. C'est comme si tu utilisais un rateau pour faire un trou, alors que si tu utilisais une pelle, tu serais plus efficace.

En prenant un toolkit 100% C++ (puisqu'il semble que ce soit ton langage de prédilection), comme Qt, tu pourrais te concentrer plus sur les éléments de ton framework plutôt que sur des contournements de la plateforme...

d'autant plus si l'on n'a aucune affinité avec JavaScript...

Oui donc tu t'es trompé de plateforme à mon sens...

Si j'ai choisi XUL pour de nombreux développements (depuis des années), c'est bien pour le coté "web" de la plateforme (donc XML/XUL/CSS ET Javascript). Si je voulais faire une appli entièrement en C++, je ne choisirais certainement pas XULRunner...

Toute la partie description de l'interface reste en XUL...

le fait que tu n'utilises plus JS enlève une grande partie de l'intérêt de la plateforme selon moi (dev rapide, maintenance et evolution plus aisées etc..)

On code l'application exactement comme on le ferait en JavaScript, sauf qu'on utilise C++

Donc tu passes 10 fois plus de temps à implémenter un truc (des listeners et autres trucs d'interface), pour un résultat qui n'apporte au final rien en terme de perf (au niveau de l'UI).

disclamer : je fais du xpcom c++ depuis des années...

Lorsque l'on code une application en JavaScript, on accède en fait à des composants écrits en C++ à travers leur interface JavaScript. L'idée c'est d’accéder à ces composants directement en C++, sans passer par JavaScript. On a donc, au contraire, une couche logicielle en moins...

moui ok, je comprend mieux le principe de ton truc. Mais quand même, comme je dis, ça n'apporte rien en terme de perf, au niveau de l'interface utilisateur, sauf si tu manipules à tour de bras des centaines d’éléments XUL. En tout cas le rapport (productivité, facilité de dev, de maintenance etc)/performance est très très faible.

Mais elle ne détaille pas comment manipuler un élément XUL en C++. Par exemple, je n'ai trouvé aucune documentation qui indique qu'un élément 'tree' en XUL correspond, en C++, à l'objet 'nsIDOMXULTreeElement'

Pourtant, tout est indiqué sur la doc de la balise tree, https://developer.mozilla.org/en/XUL/tree , en particulier les interfaces qu'elle utilise, et donc ses propriétés dont la view etc. Etant donné que les objets DOM accessibles en JS sont simplement un accés XPCom aux objets C++ correspondant... Et par le passé, XulPlanet.org était encore mieux documenté au niveau des interfaces etc..

Ça fait plus de 11 ans que j'utilise le CVS de savannah.gnu.org. Pourquoi changer quelque chose qui fonctionne ?

Pour être plus productif ? Pour faciliter les contributions ? Pour avoir un outil plus performant ? pour avoir une interface web agréable à utiliser ? (le browser CVS est juste horrible).

M'enfin chacun utilise ce qu'il veut :-)

Je ne parles pas de QuickTime, mais de QT : http://en.wikipedia.org/wiki/Qt_%28framework%29

Cela rend le développement d'une application XULRunner entièrement en C++ très compliqué,

Le but de XulRunner n'est pas un framework/une plateforme pour écrire une appli entièrement en C++.

Pourquoi ne pas utiliser QT ou autre toolkit graphique ?? Parce que si dans ton projet, l'utilisation du JS est à proscrire, tu t'es, à mon avis, trompé de framework.

oui, je me pose exactement la même question. D'après ce que j'ai compris, on n'a plus à utiliser de gestionnaire d'évènement ou autres trucs "webesque" de XulRunner. Et en gros, tout le code de l'appli est dans des libs externes en C/C++.

Et au final aussi, un truc à la XPCom à été recodé en passant par XPCom. Au final on a donc une couche qui transmet des appels vers les libs externe, donc comme XPCom. -> double couche logicielle pour accéder à la lib externe. à moins d'avoir rien compris au bidule :-)

Bon, sinon, de la doc sur XPCOM C++, elle existe quand même https://developer.mozilla.org/en/XPCOM. Et il y a aussi une alternative, pour accéder directement aux fonctions d'une lib : js-ctypes.

(hors sujet: CVS, c'est vraiment pénible, je recommande d'utiliser un gestionnaire de source récent :-p)

et pour continuer dans le #fail, quietty.com n'est pas accessible depuis un navigateur web, alors que www.quietty.com, si. Une petite mise à jour DNS et config apache/nginx/autre s'impose ;-)

Bon sinon, l'idée du produit est intéressante. Par contre, il ne faudrait pas que le blog connaisse un succès fou, vu le peu de bande passante en upload qu'on a en ADSL en général.

Un jour peut être, les fournisseurs d’accès nous fournirons des débits symétriques...

Oui il y a cette différence d'ouverture de source et de spec.

Mais il n'y a aucune différence quant à la situation et aux conséquences. Le problème se situe dans l'utilisation de propriété non standards ou experimentales. Tout comme avec IE6, les développeurs utilisent des fonctionnalités qui ne sont implémentées que dans un seul moteur de navigateur (ou qui ne sont interprétables que par un seul moteur de navigateur). Cela conduit donc à un web "optimisé pour", tout comme avec IE6. Le fait que lesdites fonctionnalités soient implémentées sous licence libre ou proprio ne change rien au problème, et encore moins à une éventuel solution. On assiste à nouveau à une balkanisation du web.

indice. à 00:09, on était vendredi. Et vendredi, c'est le jour des ...