Miguel Moquillon a écrit 456 commentaires

Attention, les PC portables ne sont pas des stations de bureaux.
Sur un PC portable, ce ne sont pas les caractéristiques techniques que l'on doit d'abord regarder, mais la qualité d'ensemble. Après, on regarde la SAV et ensuite les caractéristiques techniques.
Mes conseils déjà :
- plateforme Centrino de préférence parque dedans y sont inclus et prouvés tout ce qui nécessaire pour un portable : architecture processeur + WiFi + audio au minimum. Dans le cas d'AMD, ce dernier ne fournit que le processeur, le reste est à la charge du constructeur : on a donc plus de variables sur la qualité d'intégration et donc plus de doutes sont permis.
- la dernière plateforme centrino (Napa) est intéressante: les Duo Core seront pleinement supportés par GNU/Linux dès le noyau 2.6.17 avec, entre autre, l'intégration d'un nouveau ordonnanceur dédié. Toutefois, au vue des besoins de ton frère, la dernière plateforme (Sonoma) suffit largement.
- carte graphique nVidia GeForce 7300 ou 7400 sont suffisants pour l'usage de ton frère AMHA : le dernier pilote propriétaire supporte pleinement ces derniers et, contrairement à ATI, avec qualité. Si ATI, prendre plutôt les X300 pour leur support dans Xorg. A vérifier pour les X600. Au dessus à éviter comme la peste : leur support par les derniers pilotes propriétaires d'ATI est de piètre qualité
- quelque soit la plateforme Centrino, ipw2200 ou ipw3945 sont bien supportés sous GNU/Linux (en tout cas avec la dernière Ubuntu aucun problèmes)
- privilégié les écrans LCD SXGA ou au-dessus (UXGA, etc.) : une résolution supérieure à 1024x768 apporte un confort réel et très appréciable sous les Unix libres,
- attention aux caractéristiques du disque dur : un disque dur à 5400tpm est de facto le minimum sous peine de râler sur son système pour son peu de réactivité.

Maintenant, vis à vis de la qualité mais aussi du SAV :
- ACER à éviter comme la peste : qualité médiocre à moyenne selon les modèles par contre, en France, la SAV est une des pires dans les PC portables,
- DELL : prix chère pour ce que ça vaut vraiment ; la qualité entre les modèles, voir même entre deux portables d'un même modèle, non uniforme,
- Reste, dans l'ordre, vis à vis de la qualité et du SAV :
* les Thinkpad
* Sony (attention au disque dur, car souvent 4200tpm) : par contre, tous les écrans sont du 1024x768 :-(
* HP et Asus
* Toshiba (attention à leurs modèles)

Tous ces modèles fonctionnent à peu près bien sous GNU/Linux.
Maintenant, pour le prix, l'HP nx8220 est peut-être le meilleur en qualité-prix (et ceci depuis pas mal de temps).

Voili, voilou

Je trouve franchement les portables Keynux chers :
- qu'en est il de leur qualité réelle, comparée par exemple à un Asus V6va par exemple ou un Thinkpad Z60m (dont les prix sont similaires à configuration quasi identique) ?
- le prix est proche de celui des portables à moins de 3 Kg (hé oui, l'optimisation du poids ce paye aussi) pour une configuration quasi identique, or le Keynux fait tout de même dans les 3,4Kg en gros !
- de plus, ces portables, par rapport à GNU/Linux, ne sont que compatibles (d'ailleurs comme les Asus ou la plupart des Thinkpad), ce qui signifie qu'ils n'ont pas été testés jusqu'au bout avec cet OS (ci jamais ils l'ont vraiment été).

J'aimerais bien l'avis de *vrais* connaisseurs (en portables) et qui ont eu entre les mains ce genre de portable.

Pour te répondre et à ceux qui ont aussi répondu à ton post :
- la contravariance des arguments d'entrée associée à la covariance simple respectent le typage classique (typage de Liskov),
- la contravariance multiple et la covariance multiple ne respectent pas le typage de Liskov (typage de premier ordre avec polymorphisme)
- la covariance multiple respecte le typage de Cook (typage de second ordre : un typage qui, à mes yeux, est le typage le plus adapté à l'esprit objet puisque la grande partie de ses propriétés, comme le polymorphisme, en découlent naturellement). En fait, la covariance multiple en découle même.

Dire que la contravariance est mieux que la covariance est une erreur, de la même façon que l'inverse, ceci du point de vue du typage de Liskov. Eiffel, permet, par ses constructions, de /simuler/ le typage de Cook. Une proposition avait été faite à Meyer de le supporter complètement mais celui-ci l'a refusé ; les arguments des uns et des autres étaient valables et le choix ne relevait plus que d'un décision subjective.

Ce que je trouve bien dans la gestion des exceptions dans Eiffel est que justement ce sont ... des exceptions !
Une exception est un évènement anormal et pas autre chose. Et c'est ce que propose justement Eiffel ; les évènements anormaux sont le résultat d'une rupture du contrat entre l'appelant et l'appelé (post-conditions, pré-conditions, ou invariants).
Dans les autres langages, les exceptions ont tendance à être utilisées pour traiter même des flots d'exécution normaux ! Ce qui rend les choses difficiles à lire et surtoût à maintenir. Par exemple, les cas d'erreurs dans un programme, lorsqu'ils ont été spécifiés, sont des cas normaux et non des exceptions. Une exception ne devrait traiter que les ... exceptions, c'est à dire des cas qui ne devraient pas arriver, qui n'ont pas été prévus dans la spécification du programme ... que ces cas soient identifiés ou non lors de la conception.
Bien sûr, tout n'est pas rose dans la gestion des exceptions dans Eiffel. Il pourrait être amélioré en ajoutant au langage le support des symboles et donc, il pourrait, par exemple, attacher l'identification d'une exception donnée par un symbole unique.

Tu as oublié des caractéristiques qui sont aussi importantes que sa gestion des exceptions qui est, à mes yeux, la meilleur qui soit actuellement dans les langages objets :
- support de la covariance multiple,
- support de la généricité contrainte,
- support des agents (<=> sélecteurs de méthodes)
Grâce aux deux premières caractéristiques, Eiffel est considéré, comme Smalltalk, comme un langage à classes et non à types. Or le typage de Cook est plus riche et plus propre que le typage de Liskov qui se trouve rapidement limité avec les types récursifs.

Ce qui manque par contre dans Eiffel actuellement :
- l'ajout de méthodes dans une classe d'objet déjà existante et dont on ne veut/peut pas modifier le source,
- l'introspection naturel (donc dans les spécifications du langage),
- les closures.

Quoi qu'il en soit, depuis 1984, apparition du langage sur le marché, il n'a pas réussi sa perçée et ce n'est pas maintenant, avec la libération d'EiffelStudio, que cela va marcher. Et ceci est principalement dû à de mauvais choix stratégiques.
Depuis quelques temps, avec Self, apparaissent les langages objets à prototype plus prometteurs, comme Lisaac par exemple, et à mon avis, pour m'être amusé avec, et au risque de me faire passer pour un oracle, l'avenir des langages objets leur appartient.

Je n'ai pas dis limité mais limite :) ... au niveau présentation et comportement. Il dit s'interfacer au-dessus de Gtk 2.0, mais j'avais l'impression de voir du Gtk 1.2 ! Par exemple des boutons qui sont à demi-cachés, etc. Mais bon, j'ai arrêté de voir les changements d'EiffelStudio depuis la version 5.4.

D'un autre côté, j'ai trouvé le support Gtk d'EiffelStudio assez limite pour trouver l'usage de l'IDE assez rebutant sous GNU/Linux. Ceci plus le fait qu'il n'était pas libre a fait que j'ai longtemps préféré SmallEiffel puis SmartEiffel.

Maintenant, avec l'incohérence qui existe entre le Eiffel de l'ECMA et celui de NICE et les guerres de chapelles entre les partisants de l'un et de l'autre, je me détourne de plus en plus d'Eiffel. Décidemment, Eiffel sera toujours le grand perdant des langages objets à cause d'erreurs politiques ou commerciales à chaque tournant historique du marché des langages objets.

Merci pour le lien.
J'ai fini de mettre les pages générées par PHP en conformité avec le standard XHTML.
Je jetterai un coup d'oeil un peu plus approfondi sur le lien d'ici là afin de voir si je peux et dans quelle mesure incorporer cette fonctionnalité.

Re bonjour,

J'ai mis les pages générées par le PHP en conformité XHTML. Elles passent enfin la validation.

Heu ... oublie de ma part ?
Je vais me pencher là dessus pour assurer la validation XHTML.
Merci de m'avoir signalé ce pb.

Parce que mon niveau de compétences en PHP ne justifient pas leur référence sur mon CV. En fait, je n'ai pas envie de faire du PHP dans le cadre professionnel et préfère le garder pour mon usage personnel :)

Merci pour les explications sur le status.
Ce qui est étrange, c'est que, alors que le nom de domaine est payé jusqu'en 2010, le site ne soit plus accessible. Je me demande ce qui se passe, même si le domaine windowmaker.info est présent.

Ok, je ne connaissais pas ce nom de domaine.
Merci.

Salut,
Je suis aussi l'auteur d'un album photo Web écrit en PHP et accès avant tout sur la simplicité suite à, comme toi, à une investigation déçue de l'existant (il s'appelle wagen).

Je trouve l'IHM de ton album sobre, mais jolie et efficace. Comme Damien, il serait bien que les sous-menus s'affichent sans cache les items du menu principal par exemple. Ton usage du JavaScript (à la Ajax) pour la navigation et le dimensionnement est très intéressante, toutefois, il empêche de pouvoir ouvrir un album ou une photo de celui-ci que l'on aurait cliqué de s'ouvrir dans un nouvel onglet ; c'est quelque chose que l'on m'avait durement reproché une fois.

Bonne continuation ;)

D'abord, je suis d'accord avec les commentaires sur la puissance de la ligne de commande pour effectuer des tâches avancées et que l'on ne trouve pas d'équivalent avec les outils GUI. De même j'accorde que les outils GUI sont très bien pour effectuer des opérations simples, occasionnelles ou non, et surtout lorsque l'on ne veut pas s'embêter à "apprendre".

Ensuite, pour les clients FTP, au boulot j'utilise konqueror et une bonne partie de ses fonctionnalités (FTP, SMB, etc.) et je n'ai jamais eu, jusqu'à présent (je touche du bois) de pb avec.

Néanmoins, pour moi, la vrai valeur ajoutée d'un système Unix comme GNU/Linux ou *BSD, est le respect des outils à la philosophie Unix, en l'occurence tout est fichier. Ainsi, un ftpfs est à mes yeux *la* solution : tu montes ton système de fichier distant par FTP à un noeud de ton système de fichier local (sans pour autant avoir les droits root) et tu fais ce que tu veux avec en ligne de commande ou avec un gestionnaire de fichier graphique quelqu'il soit. Il existe un module FTP pour FUSE, ce dernier étant dans le noyau Linux depuis la version 2.6.14.

Je recommande à toute personne de regarder du côté de Plan9 qui est à mes yeux ce qu'aurait dû être Unix. Les Unix ont plein d'idées à reprendre de ce système qui, rappelons le, a été initié par l'initiateur même d'Unix, Ken Thomson.

Heu, tu es sûr pour les débranchement/rebranchement de la ligne téléphonique ? Ce n'est pas plutôt le débranchement/rebranchement de la prise électrique de la Freebox ?

Et ça ce n'est pas fait en ASP .NET ?
http://www.microsoft.com/france/msdn/aspnet/coach.mspx

En tout cas, ce n'est pas non plus du bon (X)HTML :
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.microsoft(...)

De toute façon, ASP .NET ou pas, ce n'est pas la techno qui permet d'écrire du bon (X)HTML, mais ceux assis entre la chaise et la clavier. Bien sûr, une techno qui t'aide à écrire correctement les choses améliore pas mal le dév.

Parce que pour la plupart des employeurs, la valeur ajoutée que tu apportes vaut autant que celle du nouveau jeune qui va venir te remplacer à l'issue ou avant tes 2 ans de ton contrat. Cela leur permet de maintenir à un coût moindre et avec une plus grande flexibilité une certaine main d'oeuvre qu'ils n'auraient pas avec un CDD ou un CDI.

En tout cas, avec un tel contrat, je vois mal le jeune embauché demander une augmentation de peur de se voir remercier ; donc, pendant 2 ans, tu auras le même salaire, ton pouvoir d'achat va diminuer parce que le coût de la vie, lui, va continuer à progresser.

Comme gege l'a écrit dans son commentaire, les méthodes agiles n'ont de nouveautés que par l'effet de mode hype sur celles-ci... enfin presque. S'il y a nouveauté, c'est d'avoir intégré le mode de développement itératif avec les techniques "ancestrales" et de bon sens du développement logiciel.
Toutes les techniques ou méthodes sur lesquelles elles s'appuient existent depuis un bon bout de temps. Elles ne font que mettre au goût du jour celles-ci.

Il est vrai qu'avec la politique de croissance de la productivité jointe à la baisse des coûts, sans parler du dénigrement du développement informatique par les sphères manageuriales, les techniques mises en avant par les méthodes dites agiles ont été peu à peu abandonnées.
Le succès des méthodes agiles est d'avoir pu pénétrer le cercle des décideurs SI, bien connus, dans l'ensemble, pour leur ignorance crasse de l'informatique et plus particulièrement du génie logiciel.
Toutefois, en France, le succès est plutôt mitigé. Si ces méthodes se sont fait une petite place dans le milieu "chefs de projets", elles n'ont que très peu, voir pas du tout, pénétré celui des décideurs. Je pense que cela doit venir de cette caractéristique actuelle de notre société qui est le dénigrement (et la méfiance) de la technique.

Oui, je veux bien.
Et tant qu'à faire, tu peux faire aussi la même chose du côté de chez Microsoft puisque tu y travailles. Et par la même occasion, donnes aussi la liste des bogues connues mais que Microsoft ne "veut" pas corriger. Là, sur ce dernier point, ça peut-être intéressant.

C'est sûr qu'il n'y a pas de référence au cercle familiale:

Lorsque l'oeuvre a été divulguée, l'auteur ne peut interdire :
1º Les représentations privées et gratuites effectuées exclusivement dans un cercle de famille ;

Je préfère aussi ce genre de syntaxe qui est plus proche du langage naturel et qui permet, à mes yeux, de mieux exprimer un message ou un slot d'un objet.

Il y a aussi la syntaxe Smalltalk que j'aime bien:
GuiInText createIn: interface at: 5,160 width: 250 label: "object GUI_IN_TEXT : " action: self

Ces genres de syntaxes sont plus expréssifs que ceux classiques hérités des langages procéduraux. Enfin, c'est mon opinion et aussi mon expérience :)

Ok. Très bien. Merci. Est-ce qu'il fera partie de la prochaine version de la lib ?

En fait, dans le cas du message if, tel qu'il est exprimé dans BOOLEAN, je le voit mieux dans BLOCK pour la raison suivante:
- BOOLEAN.if block: BLOCK == vrai si faire_quelque_chose
=> ne veut rien dire
- BLOCK.if test: BOOLEAN == faire_quelque_chose si vrai
=> déjà c'est plus parlant.

Donc, AMHA, le message 'if:' (je l'écris à la Smalltalk), est plus logiquement compris par les objets BLOCK que BOOLEAN. Ça permet d'avoir une souplesse supplémentaire. C'est comme pour par exemple (syntaxe Smalltalk):
d'un côté, File print:
et de l'autre, String printOn:

Voilà, c'est juste pour dire ça.

Est ce que ceci signifie que je peux rajouter dans le prototype BLOCK ce slot:
if test: BOOLEAN <- deferred;
et que le compilateur va pouvoir s'en sortir pour l'interpréter en C comme:
if(test) BLOCK