Laurent J a écrit 2933 commentaires

Encore une preuve de la merdicité des drivers HP sous windows. Franchement c'est vraiment une horreur HP. Ça t'installe des tonnes de trucs dont tu n'a pas besoin, c'est super lent au démarrage (à cause du démarrage de ces tonnes de trucs merdiques), et ça plante dans tous les sens. Sans parler de ces boites de dialogues qui apparaissent au démarrage, te demandant d'installer la doc, mais sans que tu saches à quoi ça correspond (la doc de quoi ?), d'où ça vient, et ce n'est qu'au bout d'une demi heure de recherche que tu arrives à comprendre qu'il s'agit de cette merde de driver HP qui s'est mal installé (c'est du vécu, lors d'un dépannage d'un PC).

Heureusement, sous linux, c'est moins lourd...

ah mais monsieur ne connait pas la technique du décapeur thermique ?! Avec un décapeur thermique (pour ceux qui connaissent pas, c'est un sèche cheveux amélioré), ton barbecue (au charbon de bois) est prêt en 5 minutes (montre en main) !

Bon c'est sûr que tu consommes quelques watts... Mais bon je suis pas sûr que ce soit plus polluant que ces cubes remplis de produits chimiques ou autres produits allume-feu.

D'un autre coté, si on veut faire un barbecue non polluant, on n'utilisera que du bois secs et non du charbon... (et on l'allume avec une allumette et du petit bois)

Comme dit la réponse précédente, tu ne sembles pas très au courant des évolutions. Pour Cairo en tout cas. Ce n'est pas forcément encore super top mega rapide, mais les performances ont vachement été amélioré et ça devient quand même franchement utilisable par rapport à il y a un an ou deux. C'est pas pour rien que la couche graphique de Firefox 3 repose maintenant entièrement sur cairo.

Tu sais, il existe encore des téléphones fixes, filaires, simple, ne nécessitant pas de transfos. Et en plus ça coûtent kedal (9 euros 50). D'ailleurs j'en ai pris deux pour chez moi il y a 2 ans et ça fonctionnent très bien (j'ai pas fait de dégroupage total, j'aime pas mettre tous les oeufs dans le même panier). Autre avantage : en cas d'urgence et de coupure d'électricité, il y a de forte chance que ça fonctionne ! (alors qu'un téléphone nécessitant un transfo, ou branché sur une box...).

Bon c'est vrai aussi que les agendas incorporés et mémorisation des numéros, je m'en sers jamais. Je préfère le bon vieux agenda papier. au moins pas de risque que ça tombe en panne, et moins de risque que je perde tous les numéros suite à une coupure éléctrique, une pile défaillante ou autre panne. Et comble du bonheur, je peux utiliser mon agenda papier avec n'importe quel téléphone :-D

C'est beau la vieille technologie :-)

Mon boss, qui travaillait avant chez Netscape, a imposé dans sa boite le code vestimentaire de Netscape : "You must be dressed".

Donc voilà, mon style vestimentaire, c'est "habillé".

Bon, le plus souvent polo/t-shirt + jean. Souvent un t-shirt de geek d'ailleurs (Dont des t-shirt mozilla bien entendu). L'été quand il fait chaud, je me met à l'aise : t-shirt + bermuda + sandales.

Quand il arrive que j'aille voir des clients, je met une chemise. Enfin ça dépend du client..

je pensais effectivement que B dérivait de A dans ton explication. Désolé.

C'est vrai que ce que tu décris pourrait paraître un bug par rapport à d'autres langages objets. Pour moi effectivement, $this ne devrait pas avoir d'existence dans une méthode statique, puisque ce n'est pas une méthode d'un objet instancié.

Mais bon, si ils déclarent dans PHP que ça se passe autrement, pourquoi serait-ce un mal ? Surtout si ladite méthode est explicitement déclarée avec "static" ? (et donc le développeur, sachant le comportement de $this, sait à quoi il s'attend puisqu'il s'agit effectivement d'une méthode statique)

par rien. Le safe_mode est grosse daube, le cauchemar des développeurs dés lors que l'on veuille manipuler des fichiers dynamiquement. (y a qu'à lire les notes de releases des projets phares en PHP, qui souvent déconseillent l'utilisation du safe mode parce que ça provoque des problèmes de lectures/ecritures de fichiers, à cause de droits &co).

Bon debarras le safe_mode !

open_basedir reste par contre, et c'est déjà bien pour sécuriser un compte web.

On doit pas avoir les mêmes fichiers man.

- $this qui change quand ça lui plait (dans certains cas, quand on appelle une méthode d'une classe A à partir d'une méthode d'une classe B, $this dans la classe A pointe sur... B)

Tel que tu décris ce processus, c'est tout à fait normal. Ça s'appelle le polymorphisme.

>je ne vois pas l'intérêt de l'objet pour faire la programmation purement "systeme".

L'utilisation ou non de l'objet n'a strictement rien à voir avec le fait de faire de la prog système ou pas. C'est plutôt une histoire de modélisation, d'algorithmie. Il y a eu des OS fait quasiment entièrement en objet (BeOs par ex), cela n'en a pas fait des OS moins bien que ceux programmés en pure C (au contraire même).

exactement, le zend framework se rapproche plus d'une bibliothèque comme pear que d'un véritable framework qui propose normalement un cadre complet de développement, avec des normes de nommage, une structure précise de l'application, tant au niveau des objets que des fichiers.

Cela ne veut pas dire pour autant que le Zend Framework n'est pas intéressant. Mais pour moi il n'a de framework que le nom.

Peut-être devrais tu te pencher un peu plus sur le modèle objet de PHP 5 ? On est loin de celui de PHP3 ou PHP4 hein...

On peut faire des choses très propres en objet avec PHP5.

Certes, il manque peut être quelques trucs par rapport à d'autres langages objets super avancés (namespace par exemple, mais ça viendra dans PHP6), mais le minimum est là et bien là, et suffit déjà largement à faire des trucs convenables. On a pas toujours besoin de l'artillerie lourde des autres langages pour faire un bon soft.

euh... quand mon téléphone est éteint, il est vraiment éteint. J'ai beau appuyer sur toutes les touches, rien n'y fait, il ne réagit pas. Il faut que je l'allume pour téléphoner.

Ce à quoi tu penses, c'est la possibilité d'appeler des secours, quand il est allumé, mais quand tu n'es pas autorisé à accéder au réseau (pour diverses raison, genre tu n'a pas tapé ton code pin, ou que tu es dans un pays étranger mais que tu ne peux utiliser le réseau local parce que tu n'a pas pris un abonnement international :-) etc...)

>C'est bien beau, mais comment on fait pour que tout le monde puisse le voir ?

Bah ils installent un navigateur récent ? Et tant pis pour les autres qui ne peuvent pas.. (l'informatique évolue, il faut peut être un jour arrêter d'utiliser des logiciels obsolètes...)

>l'autre avantage de flash est que c'est compilé en bytecode par la machine flash donc bien plus efficace que js dans un navigateur

Ce ne sera plus un avantage de flash, puisque adobe a libéré sa VM javascript/actionscript (le truc qui lit ce bytecode dont tu parles :-p), et que ce sera intégré dans Mozilla 2/Firefox 4.

Il parait, mais c'est à prendre avec des pincettes, rien n'est sûr, que Firefox 3 implémentera la balise video (il existe déjà une implémentation experimentale, croisons les doigts pour qu'elle soit prête pour la beta de FF3). au pire ce sera dans Firefox 4.

> Quel est l'intérêt pour le consommateur ?

La matière première est certe la même, mais là où les autres fournisseurs peuvent se démarquer, c'est au niveau des services, des offres au niveau abonnement etc..

En toute honneteté (je suis le développeur d'Etna), Etna n'est pas vraiment opérationnel pour être utilisé en production. Il y a des bugs dans le validateur RelaxNg, on ne peut pas utiliser des feuilles XSL etc... En ce moment d'ailleurs je suis en train de refaire from scratch le validateur avec un autre algo.

Bref, not really ready. Mais j'ai bon espoir que d'ici la fin de l'année, je sorte une version qui soit vraiment stable.

>efficace pour se rendre compte de l'activité en temps réel pour un novice

et keskil en nana fout' du temps réel de l'activité, le novice ? surtout pour un super gros projet aussi connu que ubuntu ? franchement ? Je trouve totalement inutile ce rafraichissement toutes les 2 secondes. Encore un truc web 2.0 qui sert à rien quoi... (mais qui pompent des ressources...)

Effectivement, je n'avais pas vu que tu avais mis le namespace XUL sur les balises XUL, dans les exemples. Cependant il y a des attributs non xul qui n'ont pas leurs propres namespaces..

non, dire que c'est du XUL, c'est induire le développeur en erreur, puisque seulement quelques balises de XUL sont utilisées, et que partiellement implémentée. Qui plus est, à ce pseudo XUL, il y est ajouté des balises qui n'ont rien à voir avec le XUL, et qui sont propres à Akrogen.

Ton exemple du C est un mauvais argument. Si tu dis "voici mon programme en C", alors je m'attend à ce que ton programme compile avec n'importe quel compilateur C.

Si je prend un source pour Akrogen, non seulement ça ne va pas s'afficher (ou mal) dans un moteur qui sait interpréter le vrai XUL, mais dans l'autre sens, si je passe du vrai XUL à Akrogen, il y a également de forte chance (vu la faible implémentation de XUL dans Akrogen) que ça ne fonctionne même pas (et pour cause, puisque je n'aurais pas les balises spécifiques à Akrogen).

>Mais Akrogen n'a pas la prétention de ré-implementer Mozilla

Donc ce n'est pas du XUL. Tu ne dois donc pas appeler ça du XUL.

Quand tu veux parler d'une renault megane, tu n'appelle pas ça une 307, bien que ce soit toutes les 2 des automobiles, avec 4 roues, 1 moteur, un volant...

On pourrait dire pareil pour C# ou Java. Ça se ressemble sur certains points, mais on n'a pas appelé ça avec le même nom.

En clair : trouve un autre nom pour ce langage XML.

Cela aurait été bien de ne pas appeler ce langage XML de description d'interface "XUL". Je rappel que XUL est un langage de Mozilla (XUL est d'ailleurs une TM de Mozilla), et le pseudo XUL de Akrogen n'a que quelques similitudes avec le XUL de Mozilla, d'après ce que j'en vois : des attributs et balises propres à akrogen, et une implémentation vraiment très partielle du XUL de mozilla d'après la doc de référence

Bref, cela ne fait qu'apporter confusion chez les développeurs, c'est dommage.

ce que tu décris ressemble fortement à jDao dans le framework Jelix.

Tu as juste un fichier dans lequel tu déclares sur quelle tables et quelles propriétés l'objet dao sera mappé. Tu peux aussi decrire des methodes : nom, type (select, update...), les propriétés à prendre en compte, les conditions etc..

Et jDao te compile tout ça sous une forme de classe PHP, avec toutes les méthodes qu'il faut et que tu as décris, contenant alors les requêtes SQL correspondantes. Cette classe est mise en cache (donc pas de recompilation à chaque appel). le fait que les requêtes soient déjà générée et le code mis en cache apporte des performances respectables pour un orm.

je vois deux gros inconvénients à cette méthode :

1) c'est super lourd. Même pour un petit aquarium comme ça (j'ai presque le même à la maison). Pour le déplacer rempli, c'est galère.

2) changement des pièces /maintenance : faut tout essuyer (l'huile c'est galère à essuyer), surtout les contacts j'imagine, quand on branche/rebranche un truc. Sans parler qu'on s'en fout plein les mains.

une raison pour ne pas prendre une dedibox : ils mettent des semaines en ce moment à livrer. Un ami en a commandé une le 17 avril. On attend toujours. Et bien sûr, impossible d'avoir une date approximative (c'est tellement trop dur de faire date aujourdhui + temps livraison pieces + nombre de serveur commandés * temps de preparation d'un serveur...)