"J'aime bien l'expression "outils de rendering HTML". Au passage c'est bien plus que ça, et il le sait, mais bref."
Euh... je comprends pas bien, basiquement c'est ça non? qu'est ce que tu y ajoutes en plus? (ce qui ne veut pas dire qu'un moteur de rendu HTML est trivial à implémenter!).
"A moins qu'il y ait plusieurs façon de structurer le corps du message"
Bingo... et c'est d'ailleurs assez tordu et touffu... (comme la plupart des protocoles/standard du net ayant une historique douloureuse...).
Cependant, GPG, ça vous sert pour de vrai? Vous n'avez pas peur de tomber dans de la "fausse sécurité"... (ex: je me fais une signature à TON nom, j'envoie un mail à qq... wow c'est signé donc ça doit être bien TOI... alors que sans la signature, il aurait pu douter...).
Bien sûr que non, je conseille de se concentrer sur l'ensemble du produit:
- fonctionnalité
- utilisabilité
- sécurité
- etc...
Et si ça salit le code, ton design est à revoir period.
Je préconise de se poser des questions de fond sur les bugs, plutôt qu'un rush sur une faille potentielle de sécurité: Un parseur correct ne doit pas produire ce genre de chose, les corriger à la va vite sans tenir compte de ton design posera des problèmes de régression (toute corrections de bug pose des problèmes de régression entre, dans les meilleurs cas, autour de 5%, autrement dit sur 20 correction 1 introduit un nouveau bug).
En fait, je pense qu'on est d'ailleurs, ce que j'aime pas en fait, c'est l'attitude: on tape le mot "sécurité" et ça devient hyper critique... c'est idiot: c'est un point important, qui n'est pas à négliger, mais ce n'est pas tout... pour l'utilisateur final, qu'il perde son doc à cause d'un virus ou d'un plantage ne change rien: il a perdu son doc, perdu du temps, de l'argent, etc... (y'a un américain pour le moment qui parle pas mal de sécurité nationale :p)
Enfin si tu regardes la pratique, 99% des attaques réussies, réussissent "grâce" (à cause...) à une erreur humaine... et non a une faille du produit utilisé (mes chiffres date un peu, et ça ne tient compte que du monde de l'entreprise). Le social engineering reste la méthode la plus efficace (et crois moi ça fonctionne bien...). Si tu suis ce raisonnement, il serait ptêt plus rentable (niveau taux d'attaque réussies) de coder une fonctionnalité d'assistance à l'utilisateur et de formation que colmater un bug. (ce qui ne veut pas dire qu'il ne faut pas les corriger, au contraire, mais ne pas se faire d'illusion sur le fait que ça empêchera toute attaque).
"un plantage, ce n'est rien à coté d'une page qui ferait au final éxecuter du code en local : ce dernier pourrait être un rm -rf ~ ou un exploit quelconque."
Oui et non, généralement je suis d'accord avec toi évidemment, entre un truc qui plante et un gros virus tout pourri, je préfère le truc qui plante...
Cependant, le problème reste: il faut s'intéresser à l'effet du trou, pas au trou dans l'absolu, à lire certains passages, on se dit presque que peu importe le code, les fonctionnalités du produit, etc... faut que ce soit secure avant tout. Je ne suis pas d'accord. Et c'est d'ailleurs cet aspect "non-feature" de la sécurité qui rend une politque sécuritaire foireuse...
1. cool c'est du concret, et "facile" à tester... on peut espérer améliorer ça...
2. bcp de gens parlent de sécurité: je trouve ça un chtit peu rapide comme vision, perso la sécurité je m'en fous!! si si je vous jure ;) Sérieux, le problème de sécurité est ce qu'on arrive à exploiter, les données qu'on va me "voler", le temps qu'on va me faire perdre, etc... bref: le problème n'est pas la sécurité dans l'absolu, mais les problèmes engendrés par les trous de sécurité... Il est je trouve alors intéressant de réaliser qu'un browser qui plante peut me faire perdre du temps... tout comme une attaque de type DOS...
3. Patch? vous avez dit patch? Un truc m'inquiète un peu, dans les articles anglais, on parle de QA... on est en où dans la QA des browsers libres? quels sont les procédure mise en place? Par exemple, mozilla est bcp plus gourmand en mémoire qu'IE (chargez des pages avec plein d'image, ça bouffe un chtit peu plus qu'IE, surtout ça rame bcp bcp plus vite), faut croire que ça n'a pas fait partie des scénarios de test de mozilla... (ça ne le rend pas mauvais pour autant, c'est juste dommage). Petit problème avec IE cependant: on a aucune idée si ça fait partie de leur test de qualité... mais le résultat est là, coup de bol ou volonté, ça se passe mieux...
Bref, si qq a des infos sur les procédures de test en place pour mozilla (et les autres, même IE ça doit être intéressant), je suis demandeur. J'espère que ces "plantages" seront corrigés, quitte à refaire une partie du design de gecko (et des autres)... et pas violemment patchés à la "si html=truc_qui_fait_planter alors plante_pas". J'ai un peu peur j'avoue quand je vois la nature de certains patch...
Sur ce ... je vais m'occuper de la QA de mon app :p
Marrant, on vient d'implémenter l'envoie dans un thread, ça prenait 5 secondes, bcp trop long. Maintenant c'est mieux... dommage que java (1.3) ne propose pas de pool de thread en standard d'ailleurs.
"l'insertion dans la Bdd ?"
Si tu as la chance d'avoir une bd qui va bien, qui est proche de toi, et que tu es le seul à utiliser... pq la plupart des sites implémente une cache si la bd n'est pas critique? (bien que ce n'est pas la seule raison pour mette une cache)
"l'interface avec les fournisseurs ? "
Soyons moderne, c'est du webservice (ou ce que tu veux d'autre...) le délai commence à se compter en secondes!!
Cependant je comprends ton point de vue: PHP permet de tout faire (comme les CGI en C le permettent aussi d'ailleurs...). Cependant, offrir des solutions à la "t'as qu'à faire ça", alors que J2EE offre un framework "standard" de son côté... ça en fait hésiter plus d'un.
"Les seuls trucs un peu "sioux" sont des bidouilles en PHP pour générer du javascript pour certaines améliorations de l'ergonomie"
C'est perso ce que je reproche le plus à PHP: difficile de se faire des composant *bien* isolé et facile d'emploi... un truc du genre custom tags à la java ou mieux webcontrols ferait du bien à PHP. Surtout vu sa communauté.
Pour ce qui est de maintenir l'application, je suis plus exigeant que toi: 20 minutes pour un bug, tu y rajoutes les test et le temps de mep... ça peut devenir long pour une appli critique. (tiens tu debug comment ton PHP? à l'époque j'avais pas trouvé grand chose, mais j'ai peu cherché et je connais très peu le PHP)
En fait c'est essentiellement niveau abstraction que je reproche des choses à PHP: que faire par exemple si tu veux changer de base de donnée? Changer de mot d'authentification? Changer le layout de tes pages? (boulot que tu vas vouloir refiler à un infographistes... enfin ce sera le cas si t'es aussi bon que moi en design :p).
Concernant ta conclusion je suis plutôt d'accord avec toi: pour une petite ou moyenne appli, il offre de bon service, et est rentable niveau temps investi. Cependant, J2EE et ASP.NET (surtout ce dernier) deviennent de plus en plus accessible... Si tu as l'occasion, le temps et une machine windows, je te conseille de jeter un oeil à Visual Web Developer Express Edition (à télécharger depuis msdn.microsoft.com).
Ton expérience est intéressante, quelques questions:
- c'est du PHP5?
- que penses-tu de la maintenabilité de ton code?
- combien de temps un développeur tiers prendrait pour comprendre ton code/design/modèle/...?
- tu as déjà utiliser J2EE ou .NET?
- comment ton application supporte-t-elle la montée en charge?
- quelle base de donnée? mysql?
"J2EE est un standard en ce sens qu'un certain nombre de gens se rassemblent pour le définir et le faire évoluer et ensuite. "
Alors tous est standard :p
Mal pensé? Parle moi de l'implémentation des generics en java :p ou des évolutions de J2EE offrant la joie de casser du code existant :p... si tu veux des idées générale: problème potentiel de scalability, abstraction parfois abusée, etc... Attention je ne prétends pas que J2EE, c'est nul! au contraire, je l'utilise tous les jours, mais de là à en faire une solution "sans aucune lacune", faut pas pousser...
Je me demande sinon, comment tu définis ce qui doit être ou ne pas être intégré dans la norme? Tu te bases sur quel critère? Perso j'ai tendance, mais c'est un pt de vue de pauvre développeur, à me dire que quand j'en ai besoin et que je l'ai pas, c'est que ça manque... ce qui a pour conséquence directe qu'aucune API n'est vraiment complète... d'un côté heureusement, ça nous fait du boulot, mais d'un autre, ça rend l'API perfectible... (ceci dit, c'est évidemment à relativisé, mais c'est un choix amha trop compliqué que pour être résumé à "c'est complet", "c'est pas complet").
"La portabiltié absolue n'a jamais été promise... juste une portabilité sur les plateformes ou une jvm est dispo. "
Qui est en effet vraie dans un monde utopique, en pratique, tu te retrouves quand même à devoir tester ton appli sur X plateforme, et apporter certains changements... t'as déjà essayer de porter une appli swing sous macosx? :p
Ceci dit mon post n'était qu'une réponse... n'y vois pas une négation de tous ses propos, juste une tentative de relativisation ;)
Ca fait en effet partie de C# 2.0 en beta 1 pour le moment... (en fait toute les fonctionnalité présentée font partie de C# 2.0 et/ou .NET 2.0). J'aurais du le préciser dans mon post.
Concernant l'ajout de méthode, il s'agit juste de partial class, ce n'est pas de l'ajout de méthode, mais le concept n'est pas très très loin: écrire une classe en plusieurs partie. Pratiquement c'est plus "esthétique" qu'autre chose. Cependant, est-ce qu'ajouter des méthodes à une classe n'est pas facilement simulable grâce aux events/delegates et à l'héritage?
La covariance est en effet restreinte, mais bon c'est sympa de se dire qu'on l'aura bientôt en C#.
Le nullable type?... j'ai du mal à voir comment tu veux l'éviter tout en restant performant?
Le yield est cependant, amha, le plus intéressant, il devrait permettre de faire certaines choses sympathique, mais personnelement je me demande la qualité du code généré derrière.
Enfin voilà, ça va viendre, et perso, j'ai plutôt été convaincu par le C# et .NET... surtout le couple des deux en fait... mais bon, on a pas encore le langage idéal, celui qui fait le café! :p
glurps (discuter plus bas, par des gens qui ont plus de compétences que moi...)
"La plateforme Java/J2EE, standart, extrémement compléte, sans aucune lacune."
glurps... J2EE c'est quoi? un amas de techno plus ou moins bien (ou mal) pensée mise ensemble avec un joli nom... standard? ISO? ECMA?... de fait? complète? pourtant on en est toujours à utiliser un paquet de lib qui tourne autour de java... (log4j, junit, struts, hibernate, etc...). Ca ne veut pas dire que c'est mauvais, mais faut pas pousser non plus... T'as touché à quoi d'autre que java...?
"La machine virtuelle : qui, dans un monde utopique, offrirai la portativité absolue"
Dans ton monde idéale, tous les ordinateurs seraient alors les mêmes...
- Des types "valeurs", qui ne pourrait être null... même si ça ressemble à une classe (et au passage faire que le boxing/unboxing soit un peu plus qu'un jeu syntaxique, genre que ça permette d'optimiser le brol...)
Et puisqu'on est gentil, des nullable type quand même, parce qu'on a assez chié en ramant sur les valeurs nulles de notre SGBD favori...
Mouais ce serait pas mal d'avoir un langage avec ça :p
J'ajouterais (puisqu'on est dans un soucis de précision) qu'un md5 d'un mot de passe court se cracke en quelques heures... en dessous de 7 caractères ça se compte même en minutes sur un bête PC...
- sous windows le sous-système graphique fait partie du kernel
- sous linux le sous-système graphique est une application séparé (et qui donc jouit de sa propre priorité).
Cependant, ce qui rend un affichage fluide n'est pas tant les quelques cycles perdu avec un passage en mode kernel en plus ou en moins, mais l'organisation et le scheduling des threads de l'application cliente... (et l'utilisation d'appel non bloquant!!). C'est entre autre pour cela que les "vraies" threads (schédulés en tant que telle) sont apparus avec le 2.6.
Amha, le problème est de définir un "ralentissement", est-ce un accès disque (dans ce cas il n'y a pas de raison que ça rame), un process trop fortement cpu-bound (genre une crasse se tapant en time critical pour simuler du temps réel sur un OS qui n'est pas conçu pour...), l'utilisation d'un autre périphérique, etc...
Il est aussi à noter que concernant la fluidité d'affichage, la mode semble être à la composation "à la macosx", autrement dit: l'os se charge du rendu de l'écran, de façon régulière et fluide, les applications fournissent du contenu afin de pouvoir composer l'affichage... ça devrait supprimer les problèmes de fenêtre partiellement dessinée, etc...
Ce n'est que partiellement vrai, mshtml (mshtml étant l'équivalant de gecko) est plus compliqué que cela, il est possible par exemple de controler tout ce que mshtml télécharge via un APP (asynchronous pluggable protocol)... ça ne veut pas dire qu'il faut utiliser IE... mais le raccourci "utilise IE" -> "trou de sécurité" est un peu rapide!
Posté par tene .
En réponse au journal GMail.
Évalué à 2.
Je le teste depuis quelques jours... et perso, je trouve que ça marche plutôt bien:
- TRES rapide
- interface relativement clean (par rapport à un hotmail, caramail, ...)
- pas d'accès POP ou IMAP :( (mais d'un autre côté, on perdrait pas mal de l'intéret de google)
- chose importante: pas d'ajout de pub dans les messages qu'on envoie.
- Interface relativement évoluée pour un webmail: la liste des contacts apparaissant quand on commence à taper dans le champs HTML m'a bluffé par exemple...
La pub... mouais la pub, bah perso je m'en fous, limite je préfère un truc ciblé, y'a même des chances que ça m'intéresse... Faut pas rêver, un compte mail gratos sans pub, c'est extrèment rare... (voir inexistant).
En bref, je trouve que ça marche pas mal du tout... y'a peu de chance que ça devienne mon adresse mail préféré (développant un client mail, je vais pas me mettre au webmail quand même :p), mais ptêt pour quelques mailing list?
Ah vi, si des gens veulent tester, j'ai 6 invitations dispo... qpouplard@gmail.com (spammez moi!!! histoire de tester le filtre anti-spam :p)
Malheureusement l'activex est largement insuffisant, il simule le controle activex (facile d'emploi) de IE... pas mshtml. Il devient alors difficile d'implémenter un pluggable protocol, d'ajoute un filtre, de contrôler le rendu, etc...
De plus les activex posent certains problèmes de déploiement (puisque ça revient à tenter de remplacer IE par mozilla...) et ne semble pas supporté.
Enfin, merci, je vais regarder du côté de gecko-sharp, peut-être une version windows un jour?
- blogger (pour ceux qui utilise ça)
- highlighting des mots
- recherche de mot
- chaque mot devient un bouton permettant de chercher
- bloquage de popup
- ...
Mozilla fait certaines choses, voir toutes, mais pas de la même façon, celle de google est parfois intéressante je trouve.
Intégrer un composant d'affichage HTML dans une application... mozilla le fait... ah oui? et comment?... j'ai longtemps chercher, jamais trouvé de façon simple et complète, si t'as des liens je suis TRES interessé... (et si c'est en C# je suis encore plus content!).
ActiveScripting? pas fan, oui et non, ça permet d'ajouter un langage de script "connu par les windowsiens" assez facilement dans du code existant. DOM? même prob que pour l'affichage d'HTML, tu m'expliques comment? :p
J'suis un peu déçu là, au début, je m'attendais à un vrai article qui explique les avantages d'IE qui poussent encore certains à l'utiliser...
Par exemple:
- la gestion de la mémoire (essayer des pages avec bcp d'image sous IE et sous mozilla, la différence apparaitra vite)
- le remplissage des formulaires
- la barre de recherche google (quoi qu'il y'a moyen de trouver qqch pour mozilla! cool!)
- l'API mshtml permettant *facilement* d'intégrer un compo HTML dans une application
- Le reste de l'API permettant d'accéder *facilement* à une série de service (DOM par exemple, ActiveScripting, etc...).
Ne vous méprenez, je tape ce message dans firefox, et je l'utilise un maximum... mais il serait amha intéressant de se pencher sur les réels avantages d'IE plutôt que faire une liste allant du pertinent à l'absurde ...
" En calulabilité, la fonction HALT est l'équivalent du mouvement perpétuel pour un mécanicien."
Petite précision pour ceux qui ont pas tout compris, la fonction HALT serait une fonction à laquelle on fournit un programme et elle on aurait le résultat "vrai" si le programme se termine, et "faux" si le programme ne se termine jamais... C'est en effet impossible à faire... (et ça se démontre) mais:
Une approcha bayesienne est originale par le fait qu'elle se base sur des probabilités et non pas des certitudes... dans le même ordre d'idée, bien que HALT soit impossible pour tout les programmes, il est possible de le faire pour certains programmes, c'est ce qui arrive parfois d'ailleurs, le compilo nous crache un beau warning signalant que tel partie ne sera jamais exécuté parce que la boucle est infinie...
Cependant, je ne pense pas que l'idée puisse mener à grand chose, perso je vois 2 trucs:
- détecter des patterns (par exemple l'emploi d'une fonction sprintf qui est souvent source de trou de sécurité par buffer overflow). Ca se fait depuis longtemps, ça donne une appréciation du code... dans certaines boites c'est même spécifié et tester de façon formelle, via un ensembel de règle.
- Appliquer la méthode bayesienne à un code source n'est pas un problème, tout comme pour le spam, c'est une façon de classer des données en deux ensembles (spam ou non, ou "bon programme", "mauvais programme")... le vrai problème c'est de traiter les données en entrée pour avoir un "bon format"... et dans le cas d'un code source, beaucoup (trop) de chose dépendent du programme (nom de variable, etc...).
En bref le vrai problème est celui des patterns: comment les définir, lesquelle choisir, etc... peut-être l'auteur de la news y a déjà réfléchi?
[^] # Re: ne pas baisser la garde
Posté par tene . En réponse à la dépêche Trois déclarations de Microsoft sur les formats, l'interopérabilité. Évalué à 1.
Euh... ECN? (explicit congestion notification)... remarque, ça fait pas vraiment chier, ça fonctionne...
D'accord --> []
[^] # Re: Chat avec Olivier Ezratty
Posté par tene . En réponse à la dépêche Trois déclarations de Microsoft sur les formats, l'interopérabilité. Évalué à 2.
Euh... je comprends pas bien, basiquement c'est ça non? qu'est ce que tu y ajoutes en plus? (ce qui ne veut pas dire qu'un moteur de rendu HTML est trivial à implémenter!).
[^] # Re: A propos de GPG, et PDA
Posté par tene . En réponse à la dépêche Thunderbird 0.9 est sorti. Évalué à 3.
Bingo... et c'est d'ailleurs assez tordu et touffu... (comme la plupart des protocoles/standard du net ayant une historique douloureuse...).
Cependant, GPG, ça vous sert pour de vrai? Vous n'avez pas peur de tomber dans de la "fausse sécurité"... (ex: je me fais une signature à TON nom, j'envoie un mail à qq... wow c'est signé donc ça doit être bien TOI... alors que sans la signature, il aurait pu douter...).
[^] # Re: Sécurité?
Posté par tene . En réponse à la dépêche La robustesse de nombreux navigateurs web mise en cause. Évalué à 1.
- fonctionnalité
- utilisabilité
- sécurité
- etc...
Et si ça salit le code, ton design est à revoir period.
Je préconise de se poser des questions de fond sur les bugs, plutôt qu'un rush sur une faille potentielle de sécurité: Un parseur correct ne doit pas produire ce genre de chose, les corriger à la va vite sans tenir compte de ton design posera des problèmes de régression (toute corrections de bug pose des problèmes de régression entre, dans les meilleurs cas, autour de 5%, autrement dit sur 20 correction 1 introduit un nouveau bug).
En fait, je pense qu'on est d'ailleurs, ce que j'aime pas en fait, c'est l'attitude: on tape le mot "sécurité" et ça devient hyper critique... c'est idiot: c'est un point important, qui n'est pas à négliger, mais ce n'est pas tout... pour l'utilisateur final, qu'il perde son doc à cause d'un virus ou d'un plantage ne change rien: il a perdu son doc, perdu du temps, de l'argent, etc... (y'a un américain pour le moment qui parle pas mal de sécurité nationale :p)
Enfin si tu regardes la pratique, 99% des attaques réussies, réussissent "grâce" (à cause...) à une erreur humaine... et non a une faille du produit utilisé (mes chiffres date un peu, et ça ne tient compte que du monde de l'entreprise). Le social engineering reste la méthode la plus efficace (et crois moi ça fonctionne bien...). Si tu suis ce raisonnement, il serait ptêt plus rentable (niveau taux d'attaque réussies) de coder une fonctionnalité d'assistance à l'utilisateur et de formation que colmater un bug. (ce qui ne veut pas dire qu'il ne faut pas les corriger, au contraire, mais ne pas se faire d'illusion sur le fait que ça empêchera toute attaque).
Enfin bref...
[^] # Re: Sécurité?
Posté par tene . En réponse à la dépêche La robustesse de nombreux navigateurs web mise en cause. Évalué à 1.
NON! on parle de possibiltié de code arbitraire exécuté sur ma machine... par rapport à un plantage qui lui est bien réel.
Tu sais que sans fonctionnalité, tu n'as pas de trous :p
[^] # Re: Sécurité?
Posté par tene . En réponse à la dépêche La robustesse de nombreux navigateurs web mise en cause. Évalué à 2.
Oui et non, généralement je suis d'accord avec toi évidemment, entre un truc qui plante et un gros virus tout pourri, je préfère le truc qui plante...
Cependant, le problème reste: il faut s'intéresser à l'effet du trou, pas au trou dans l'absolu, à lire certains passages, on se dit presque que peu importe le code, les fonctionnalités du produit, etc... faut que ce soit secure avant tout. Je ne suis pas d'accord. Et c'est d'ailleurs cet aspect "non-feature" de la sécurité qui rend une politque sécuritaire foireuse...
# Sécurité?
Posté par tene . En réponse à la dépêche La robustesse de nombreux navigateurs web mise en cause. Évalué à 2.
1. cool c'est du concret, et "facile" à tester... on peut espérer améliorer ça...
2. bcp de gens parlent de sécurité: je trouve ça un chtit peu rapide comme vision, perso la sécurité je m'en fous!! si si je vous jure ;) Sérieux, le problème de sécurité est ce qu'on arrive à exploiter, les données qu'on va me "voler", le temps qu'on va me faire perdre, etc... bref: le problème n'est pas la sécurité dans l'absolu, mais les problèmes engendrés par les trous de sécurité... Il est je trouve alors intéressant de réaliser qu'un browser qui plante peut me faire perdre du temps... tout comme une attaque de type DOS...
3. Patch? vous avez dit patch? Un truc m'inquiète un peu, dans les articles anglais, on parle de QA... on est en où dans la QA des browsers libres? quels sont les procédure mise en place? Par exemple, mozilla est bcp plus gourmand en mémoire qu'IE (chargez des pages avec plein d'image, ça bouffe un chtit peu plus qu'IE, surtout ça rame bcp bcp plus vite), faut croire que ça n'a pas fait partie des scénarios de test de mozilla... (ça ne le rend pas mauvais pour autant, c'est juste dommage). Petit problème avec IE cependant: on a aucune idée si ça fait partie de leur test de qualité... mais le résultat est là, coup de bol ou volonté, ça se passe mieux...
Bref, si qq a des infos sur les procédures de test en place pour mozilla (et les autres, même IE ça doit être intéressant), je suis demandeur. J'espère que ces "plantages" seront corrigés, quitte à refaire une partie du design de gecko (et des autres)... et pas violemment patchés à la "si html=truc_qui_fait_planter alors plante_pas". J'ai un peu peur j'avoue quand je vois la nature de certains patch...
Sur ce ... je vais m'occuper de la QA de mon app :p
[^] # Re: Le php
Posté par tene . En réponse à la dépêche PHP 5 futur concurrent de J2EE et .Net ?. Évalué à 4.
Ca dépend ce qu'il y'a derrière
"l'envoi du mail ?"
Marrant, on vient d'implémenter l'envoie dans un thread, ça prenait 5 secondes, bcp trop long. Maintenant c'est mieux... dommage que java (1.3) ne propose pas de pool de thread en standard d'ailleurs.
"l'insertion dans la Bdd ?"
Si tu as la chance d'avoir une bd qui va bien, qui est proche de toi, et que tu es le seul à utiliser... pq la plupart des sites implémente une cache si la bd n'est pas critique? (bien que ce n'est pas la seule raison pour mette une cache)
"l'interface avec les fournisseurs ? "
Soyons moderne, c'est du webservice (ou ce que tu veux d'autre...) le délai commence à se compter en secondes!!
Cependant je comprends ton point de vue: PHP permet de tout faire (comme les CGI en C le permettent aussi d'ailleurs...). Cependant, offrir des solutions à la "t'as qu'à faire ça", alors que J2EE offre un framework "standard" de son côté... ça en fait hésiter plus d'un.
[^] # Re: Le php
Posté par tene . En réponse à la dépêche PHP 5 futur concurrent de J2EE et .Net ?. Évalué à 2.
C'est perso ce que je reproche le plus à PHP: difficile de se faire des composant *bien* isolé et facile d'emploi... un truc du genre custom tags à la java ou mieux webcontrols ferait du bien à PHP. Surtout vu sa communauté.
Pour ce qui est de maintenir l'application, je suis plus exigeant que toi: 20 minutes pour un bug, tu y rajoutes les test et le temps de mep... ça peut devenir long pour une appli critique. (tiens tu debug comment ton PHP? à l'époque j'avais pas trouvé grand chose, mais j'ai peu cherché et je connais très peu le PHP)
En fait c'est essentiellement niveau abstraction que je reproche des choses à PHP: que faire par exemple si tu veux changer de base de donnée? Changer de mot d'authentification? Changer le layout de tes pages? (boulot que tu vas vouloir refiler à un infographistes... enfin ce sera le cas si t'es aussi bon que moi en design :p).
Concernant ta conclusion je suis plutôt d'accord avec toi: pour une petite ou moyenne appli, il offre de bon service, et est rentable niveau temps investi. Cependant, J2EE et ASP.NET (surtout ce dernier) deviennent de plus en plus accessible... Si tu as l'occasion, le temps et une machine windows, je te conseille de jeter un oeil à Visual Web Developer Express Edition (à télécharger depuis msdn.microsoft.com).
[^] # Re: Le php
Posté par tene . En réponse à la dépêche PHP 5 futur concurrent de J2EE et .Net ?. Évalué à 7.
- c'est du PHP5?
- que penses-tu de la maintenabilité de ton code?
- combien de temps un développeur tiers prendrait pour comprendre ton code/design/modèle/...?
- tu as déjà utiliser J2EE ou .NET?
- comment ton application supporte-t-elle la montée en charge?
- quelle base de donnée? mysql?
[^] # Re: révolutionnaire !
Posté par tene . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 1.
Alors tous est standard :p
Mal pensé? Parle moi de l'implémentation des generics en java :p ou des évolutions de J2EE offrant la joie de casser du code existant :p... si tu veux des idées générale: problème potentiel de scalability, abstraction parfois abusée, etc... Attention je ne prétends pas que J2EE, c'est nul! au contraire, je l'utilise tous les jours, mais de là à en faire une solution "sans aucune lacune", faut pas pousser...
Je me demande sinon, comment tu définis ce qui doit être ou ne pas être intégré dans la norme? Tu te bases sur quel critère? Perso j'ai tendance, mais c'est un pt de vue de pauvre développeur, à me dire que quand j'en ai besoin et que je l'ai pas, c'est que ça manque... ce qui a pour conséquence directe qu'aucune API n'est vraiment complète... d'un côté heureusement, ça nous fait du boulot, mais d'un autre, ça rend l'API perfectible... (ceci dit, c'est évidemment à relativisé, mais c'est un choix amha trop compliqué que pour être résumé à "c'est complet", "c'est pas complet").
"La portabiltié absolue n'a jamais été promise... juste une portabilité sur les plateformes ou une jvm est dispo. "
Qui est en effet vraie dans un monde utopique, en pratique, tu te retrouves quand même à devoir tester ton appli sur X plateforme, et apporter certains changements... t'as déjà essayer de porter une appli swing sous macosx? :p
Ceci dit mon post n'était qu'une réponse... n'y vois pas une négation de tous ses propos, juste une tentative de relativisation ;)
[^] # Re: révolutionnaire !
Posté par tene . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 0.
Concernant l'ajout de méthode, il s'agit juste de partial class, ce n'est pas de l'ajout de méthode, mais le concept n'est pas très très loin: écrire une classe en plusieurs partie. Pratiquement c'est plus "esthétique" qu'autre chose. Cependant, est-ce qu'ajouter des méthodes à une classe n'est pas facilement simulable grâce aux events/delegates et à l'héritage?
La covariance est en effet restreinte, mais bon c'est sympa de se dire qu'on l'aura bientôt en C#.
Le nullable type?... j'ai du mal à voir comment tu veux l'éviter tout en restant performant?
Le yield est cependant, amha, le plus intéressant, il devrait permettre de faire certaines choses sympathique, mais personnelement je me demande la qualité du code généré derrière.
Enfin voilà, ça va viendre, et perso, j'ai plutôt été convaincu par le C# et .NET... surtout le couple des deux en fait... mais bon, on a pas encore le langage idéal, celui qui fait le café! :p
[^] # Re: révolutionnaire !
Posté par tene . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 1.
http://whidbey.msdn.microsoft.com/library/en-us/dv_csref/html/43f40(...)
"De même je n'introduit pas non plus la faculté de définir des méthodes supplémentaires à une classe existante ou mieux à des objets ..."
http://whidbey.msdn.microsoft.com/library/en-us/dv_csref/html/27320(...)
"pas de covariance"
http://whidbey.msdn.microsoft.com/library/en-us/dv_csref/html/284c5(...)
Les autres trucs sympas: http://whidbey.msdn.microsoft.com/library/en-us/dv_csref/html/10891(...)
http://whidbey.msdn.microsoft.com/library/en-us/dv_csref/html/e473c(...)
l'attribut InternalsVisibleTo etc...
Attention, je réalise bien que les solutions proposés ne sont pas toute parfaite!! Mais bon, entre rien et ça... bah vaut mieux ça :p
[^] # Re: révolutionnaire !
Posté par tene . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 2.
glurps (discuter plus bas, par des gens qui ont plus de compétences que moi...)
"La plateforme Java/J2EE, standart, extrémement compléte, sans aucune lacune."
glurps... J2EE c'est quoi? un amas de techno plus ou moins bien (ou mal) pensée mise ensemble avec un joli nom... standard? ISO? ECMA?... de fait? complète? pourtant on en est toujours à utiliser un paquet de lib qui tourne autour de java... (log4j, junit, struts, hibernate, etc...). Ca ne veut pas dire que c'est mauvais, mais faut pas pousser non plus... T'as touché à quoi d'autre que java...?
"La machine virtuelle : qui, dans un monde utopique, offrirai la portativité absolue"
Dans ton monde idéale, tous les ordinateurs seraient alors les mêmes...
[^] # Re: révolutionnaire !
Posté par tene . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 2.
- Des types "valeurs", qui ne pourrait être null... même si ça ressemble à une classe (et au passage faire que le boxing/unboxing soit un peu plus qu'un jeu syntaxique, genre que ça permette d'optimiser le brol...)
Et puisqu'on est gentil, des nullable type quand même, parce qu'on a assez chié en ramant sur les valeurs nulles de notre SGBD favori...
Mouais ce serait pas mal d'avoir un langage avec ça :p
[^] # Re: MD5, un algo de cryptage ?
Posté par tene . En réponse au journal Deux Cryptage cassé ???. Évalué à 2.
[^] # Re: Et la sécurité ...
Posté par tene . En réponse à la dépêche La fondation Mozilla lance un projet pour le support de XForms. Évalué à 2.
Je n'en doute pas, mais ça m'intéresse, quels sont ils?
[^] # Re: Question comparative Windows / Linux
Posté par tene . En réponse au journal Question comparative Windows / Linux. Évalué à 3.
- sous windows le sous-système graphique fait partie du kernel
- sous linux le sous-système graphique est une application séparé (et qui donc jouit de sa propre priorité).
Cependant, ce qui rend un affichage fluide n'est pas tant les quelques cycles perdu avec un passage en mode kernel en plus ou en moins, mais l'organisation et le scheduling des threads de l'application cliente... (et l'utilisation d'appel non bloquant!!). C'est entre autre pour cela que les "vraies" threads (schédulés en tant que telle) sont apparus avec le 2.6.
Amha, le problème est de définir un "ralentissement", est-ce un accès disque (dans ce cas il n'y a pas de raison que ça rame), un process trop fortement cpu-bound (genre une crasse se tapant en time critical pour simuler du temps réel sur un OS qui n'est pas conçu pour...), l'utilisation d'un autre périphérique, etc...
Il est aussi à noter que concernant la fluidité d'affichage, la mode semble être à la composation "à la macosx", autrement dit: l'os se charge du rendu de l'écran, de façon régulière et fluide, les applications fournissent du contenu afin de pouvoir composer l'affichage... ça devrait supprimer les problèmes de fenêtre partiellement dessinée, etc...
[^] # Re: niarf
Posté par tene . En réponse à la dépêche Le gouvernement américain déconseille IE. Évalué à 4.
[^] # Re: Moi j'aime bien...
Posté par tene . En réponse au journal GMail. Évalué à 1.
Parait cependant que ça pose prob avec certains encoding étranger, j'ai pas testé personnellement...
# Moi j'aime bien...
Posté par tene . En réponse au journal GMail. Évalué à 2.
- TRES rapide
- interface relativement clean (par rapport à un hotmail, caramail, ...)
- pas d'accès POP ou IMAP :( (mais d'un autre côté, on perdrait pas mal de l'intéret de google)
- chose importante: pas d'ajout de pub dans les messages qu'on envoie.
- Interface relativement évoluée pour un webmail: la liste des contacts apparaissant quand on commence à taper dans le champs HTML m'a bluffé par exemple...
La pub... mouais la pub, bah perso je m'en fous, limite je préfère un truc ciblé, y'a même des chances que ça m'intéresse... Faut pas rêver, un compte mail gratos sans pub, c'est extrèment rare... (voir inexistant).
En bref, je trouve que ça marche pas mal du tout... y'a peu de chance que ça devienne mon adresse mail préféré (développant un client mail, je vais pas me mettre au webmail quand même :p), mais ptêt pour quelques mailing list?
Ah vi, si des gens veulent tester, j'ai 6 invitations dispo... qpouplard@gmail.com (spammez moi!!! histoire de tester le filtre anti-spam :p)
[^] # Re: Bof...
Posté par tene . En réponse au journal Pourquoi utiliser IE ?. Évalué à 1.
De plus les activex posent certains problèmes de déploiement (puisque ça revient à tenter de remplacer IE par mozilla...) et ne semble pas supporté.
Enfin, merci, je vais regarder du côté de gecko-sharp, peut-être une version windows un jour?
[^] # Re: Bof...
Posté par tene . En réponse au journal Pourquoi utiliser IE ?. Évalué à 0.
- blogger (pour ceux qui utilise ça)
- highlighting des mots
- recherche de mot
- chaque mot devient un bouton permettant de chercher
- bloquage de popup
- ...
Mozilla fait certaines choses, voir toutes, mais pas de la même façon, celle de google est parfois intéressante je trouve.
Intégrer un composant d'affichage HTML dans une application... mozilla le fait... ah oui? et comment?... j'ai longtemps chercher, jamais trouvé de façon simple et complète, si t'as des liens je suis TRES interessé... (et si c'est en C# je suis encore plus content!).
ActiveScripting? pas fan, oui et non, ça permet d'ajouter un langage de script "connu par les windowsiens" assez facilement dans du code existant. DOM? même prob que pour l'affichage d'HTML, tu m'expliques comment? :p
My 2 cents
# Bof...
Posté par tene . En réponse au journal Pourquoi utiliser IE ?. Évalué à 4.
Par exemple:
- la gestion de la mémoire (essayer des pages avec bcp d'image sous IE et sous mozilla, la différence apparaitra vite)
- le remplissage des formulaires
- la barre de recherche google (quoi qu'il y'a moyen de trouver qqch pour mozilla! cool!)
- l'API mshtml permettant *facilement* d'intégrer un compo HTML dans une application
- Le reste de l'API permettant d'accéder *facilement* à une série de service (DOM par exemple, ActiveScripting, etc...).
Ne vous méprenez, je tape ce message dans firefox, et je l'utilise un maximum... mais il serait amha intéressant de se pencher sur les réels avantages d'IE plutôt que faire une liste allant du pertinent à l'absurde ...
Mais bon ce n'est que mon avis...
[^] # Re: Je comprend pas...
Posté par tene . En réponse au journal Bayes appliqué au code ?. Évalué à 5.
Petite précision pour ceux qui ont pas tout compris, la fonction HALT serait une fonction à laquelle on fournit un programme et elle on aurait le résultat "vrai" si le programme se termine, et "faux" si le programme ne se termine jamais... C'est en effet impossible à faire... (et ça se démontre) mais:
Une approcha bayesienne est originale par le fait qu'elle se base sur des probabilités et non pas des certitudes... dans le même ordre d'idée, bien que HALT soit impossible pour tout les programmes, il est possible de le faire pour certains programmes, c'est ce qui arrive parfois d'ailleurs, le compilo nous crache un beau warning signalant que tel partie ne sera jamais exécuté parce que la boucle est infinie...
Cependant, je ne pense pas que l'idée puisse mener à grand chose, perso je vois 2 trucs:
- détecter des patterns (par exemple l'emploi d'une fonction sprintf qui est souvent source de trou de sécurité par buffer overflow). Ca se fait depuis longtemps, ça donne une appréciation du code... dans certaines boites c'est même spécifié et tester de façon formelle, via un ensembel de règle.
- Appliquer la méthode bayesienne à un code source n'est pas un problème, tout comme pour le spam, c'est une façon de classer des données en deux ensembles (spam ou non, ou "bon programme", "mauvais programme")... le vrai problème c'est de traiter les données en entrée pour avoir un "bon format"... et dans le cas d'un code source, beaucoup (trop) de chose dépendent du programme (nom de variable, etc...).
En bref le vrai problème est celui des patterns: comment les définir, lesquelle choisir, etc... peut-être l'auteur de la news y a déjà réfléchi?