Miguel Moquillon a écrit 449 commentaires

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

Cela fait un certain temps que j'observe avec attention l'évolution des langages objets à prototype: ion, slate et lisaac par exemple.
J'espère que je vais pouvoir compiler cette version de lisaac avec gcc 4.x sans problèmes.
Sinon, une anecdote sur les slots de BOOLEAN. Je trouve le slot
BOOLEAN.if BLOCK mal spécifié. En effet, écrire vrai si faire_machin ne veut AMHA rien dire.
J'aurais supprimé ce slot et aurais gardé:
BOOLEAN.if_true block:BLOCK
BOOLEAN.if_false block:BLOCK
BOOEAN.if_true block_true: BLOCK else block_false: BLOCK

Puis j'aurais rajouté dans BLOCK:
BLOCK.if test:BOOLEAN

Sinon, je trouve que vous faites du bon boulot et je vais faire quelques tests avec cette version. Si elle est ok, je pense que je vais progressivement l'utiliser de plus en plus pour mes propres programmes.

Autant je suis d'accord avec toi sur le premier point, autant sur le second je suis en désacord: le choix des standards existants est important car c'est lui qui garantit l'intéropérabilité entre outils différents et permet à ce que chacun parte d'un pot commun.
En reinventant la roue, Microsoft ne fait que continuer sa stratégie de toujours :
- adopte le, modifie le, tue le.
- enfermer les utilisateurs dans le monde Microsoft (qui est assez étendu) de façon à ce que pour eux l'informatique soit synonyme de Microsoft.
En reinvantant des choses à sa façon, il complexifie le paysage informatique en imposant, de par son monopole, à ce que les autres s'alignent sur ses technologies sans pour autant leur donner les moyens de le faire facilement.

Sinon :
- Microsoft standardise ses formats XML MS-Office au sein de l'ECMA.
=> permettre que ses outils puissent être utilisés dans les administrations qui recherchent ou imposent l'utilisation de standards (et non un "standard de fait" qui n'est qu'un mauvais jeu de mots pour blouser les gens)

- Microsoft a déposé des brevets autour de ses formats XML MS-Office
=> empêcher que toute concurrence puisse lire/écrire dans son format

Conséquence : garantir son monopole et tuer ou enfermer à jamais dans des niches ses concurrents.

Bonjour,

Comme certains l'ont stipulé, le langage Eiffel est très intéressant et, avec le compilateur smarteiffel 2.0 (même en version béta), on obtient du code natif avec des performances semblables à ceux du C++. La cerise sur le gateau d'Eiffel est évidemment son garbadge collector et sa conception soignée.

Sinon, pour proposer des choses originales, il y a aussi Haskell. C'est un langage fonctionnel pure avec un compilateur natif. Je me suis un jour amusé avec en écrivant une petite appli OpenGL et j'ai été bluffé par ses performances et sa concision. Et il existe de quoquette librairies pour celui-ci. Par contre, il est vrai, il demande un effort pour appréhender son côté fonctionnel.

Sinon, si tu aimes explorer des horizons nouveaux, il y a le langage objet à prototype Io (http://www.iolanguage.com). C'est un langage à VM (à ne pas confondre avec interpréteur). Il est sous licence BSD.

Voilà. (Désolé pour les fautes d'orthographe).

Même si sans vous il n'y aurait peut-être pas eu d'informatique personnelle.

Ha les idées préconçues. Comme quoi, la vieille propagande de Microsoft laisse des séquelles.
Microsoft a progressé avec (je dirais même plus: grâce à) l'essort de l'informatique personnel, mais il n'en as pas pour autant été l'instigateur. D'ailleurs, si on l'avait suivi et s'il n'avait pas été contraint par la concurrence, on serait encore à l'ère du bronze.
A mes yeux, deux acteurs principaux sont à l'origine de l'essort de l'informatique personnel : Apple avec son environnement graphique ergonomique tout-publique (faut pas oublié que chez les particuliers les machines Apple était fortement présent, dans les débuts de l'informatique personnel), et IBM avec ses PC (et à son détriment aussi).
Si ça n'avait pas été Microsoft, ça aurait pu être Digital et les choses auraient été différentes mais on aurait dit encore cette bétise que c'est grâce à Digital qu'il y a eu l'informatique personnelle !

Bienvenu dans le monde Unix :)
Chaque programme fait une et une unique chose, le système proposant des mécanismes IPC performant pour la communication entre chaque outil.
Nextstep avait réussi à implémenter ce principe Unix au niveau de l'interface graphique, remettant ainsi en cause les préjujées d'alors sur la faisabilité d'une telle philosophie en IHM.

Une autre alternative est d'utiliser les composants dans des librairies fournies par chaque outil pour utiliser leur fonctionnalité. C'est en général ce dernier cas que font les logiciels libres voulant rester "petit" et efficace ("small is beautiful").

Oui effectivement : "tout est fichier". Je ne voulais pas dire tout est système de fichiers et donc un système de fichier par utilisateur et patati et patata. D'ailleurs je n'ai jamais dis cette dernière phrase. Sinon, mise à part ceci, pour représenter des choses sous forme de fichier, cela peut se faire sous forme de système de fichiers, comme par exemple le FTP (ftpfs) ou SSH (sshfs). Le cas du mail entre, je pense, dans ce dernier cas : tu montes ta boite mail (qu'elle soit locale ou distante) sois forme de système de fichier (imapfs ou popfs) et tu y accèdes comme un système de fichier classique. Pour envoyer un mail, tu déposes par exemple ton fichier texte ou autre dans un répertoire 'sent-mail', etc. Bon, bien sûr, faut creuser un peu la dessus. A côté de ceci, rien ne t'empêche d'utiliser des outils graphiques (ton gestionnaire de fichier, ton éditeur texte ou HTML ou autre) pour ce faire.

Sinon, pour Plan9 et son système graphique :
http://www.cs.bell-labs.com/sys/doc/8½/8½.html

Et à part écrire des bêtises ? Que je suis un vilain terroriste qui veut tuer tout le monde ? J'ai écris des ... conneries ? Sans blagues ! Et en quoi ?
Parce que les protocoles mail ont dans les 2 ans. Et alors ? Ils disent comment écrire des client ces protocoles ? Non. Rien n'empêche de les implémenter sous forme de système de fichier ... à la Unix.

La façon Windows ou MacOS est une façon orientée application et non document. Faire une chose ou plusieurs choses à la fois ne peut se faire que via une application bien particulière, avec ses qualités et ses défauts. Pour le cas du mail ou de la gestion de fichier avec les fichiers distants, c'est exactement ce que font les outils KDE ou GNOME par exemple, sous GNU/Linux ou *BSD. Donc oui, ils mettent en quelque sorte aux "chiottes" le principe d'Unix selon lequel tout est fichier, que cela ne te plaise ou non.

Dans l'esprit Unix, on manipule des documents ... pas des applications ; combien parmi les développeurs sous Unix l'ont compris ? Au vues des applications que l'on a à notre disposition, je dirais pas bcp. Et pourquoi ? Probablement parce que la majorité actuelle viennent d'environnement ou de formation dans lesquels tout est perçu sous forme d'applications. Ce qui n'enlève en rien le formidable travail qu'ils ont réalisés.
Bien sûr, il faut aussi relativiser et percevoir que dans les années 70 et 80, les techniques étaient relativement modestes pour pouvoir implémenter bcp de choses sous forme de fichiers, comme par exemple le système graphique (cf. X11). C'est pourquoi ce n'est qu'à partir des années 90 que Plan9 a vue le jour.
Aujourd'hui on a les techniques de suivre la philosophie Unix jusqu'au bout, et donc de proposer une approche complètement différentes de celles de Windows ou de MacOSX et AMHA ce n'est pas plus mal.