Genezys : humeurs d'un codeur2024-02-13T10:16:31+01:00urn:md5:62dba65156a2c4c4d9efe7347a84a147DotclearDotclear 2 & chantiersurn:md5:6043ef4224afc461e7c97794e3e370f52009-03-22T03:42:00+01:002009-03-30T18:12:15+02:00Vincent Robert <p>Un petit passage rapide pour vous dire que le blog est (enfin) passé sur Dotclear 2.</p>
<p>La migration se serait vraiment passée sans aucun problème si je n'avais pas dans le même temps voulu mettre à jour la Debian de mon serveur. C'est uniquement ma faute, la migration Dotclear s'est passée parfaitement. Seul la configuration du serveur était en cause.</p>
<p>Après quelques heures de configuration de PHP, Apache et de shell, le serveur est de nouveau en route... Pour un certain temps. Je prépare en effet une migration vers la plateforme d'hébergement de Gandi qui me semble très intéressante que ce soit dans sa rapidité, sa souplesse ou son prix tout simplement. Attendez-vous donc à d'autres coupures (le moins possible je l'espère) !</p>
<p>Concernant la migration en Dotclear 2, je n'ai pas encore redigiré les URL de la version précédente (que j'avais personnalisées). Si un expert Apache passe dans le coin, je suis preneur...</p>Définir une structure arborescente en Javaurn:md5:fa076d456dd374b533ab812fbd5226bc2009-03-18T19:34:46+00:002009-03-30T17:12:15+00:00Vincent Robert<p>Un petit mot pour vous parler d'une découverte que j'ai récemment faite à propos du langage Java.</p>
<p>Si vous avez déjà développé une interface graphique, vous savez qu'il est fastidieux la déclarer. Il est souvent difficile de suivre le déroulement de la construction car le modèle impératif du langage Java ne s'accorde pas bien avec la structure arborescente d'une interface graphique.</p>
<p>Voici maintenant une solution pour rendre beaucoup plus lisible tous vos codes déclarant des arbres ou des maps !</p> <p>Le problème avec les structures arborescente est qu'il faut construire un élément et également le rattacher à son parent. Ces deux actions sont parfois difficiles à discerner dans un langage impératif comme Java. Un petit exemple :</p>
<pre>JFrame frame = new JFrame();
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
JPanel panel = new JPanel();
frame.setContentPane(panel);
JButton button1 = new JButton("Click me");
button1.addActionListener(new ActionListener()
{
public void actionPerformed(ActionEvent e)
{
System.out.println("Clicked");
}
});
panel.add(button1);
JButton button2 = new JButton("No ! Click me instead");
button2.addActionListener(new ActionListener()
{
public void actionPerformed(ActionEvent e)
{
System.out.println("Really clicked !");
}
});
panel.add(button2);
frame.setVisible(true);</pre>
<p>Voici (en gros) un code Java permettant de créer une fenêtre contenant deux boutons et de l'afficher. On voit clairement que le développeur à choisi de regrouper chaque élément graphique lors de sa création, la construction de la structure de l'arbre étant laissé à la dernière ligne de chaque bloc (<code>setContentPane</code> et <code>add</code>). Le problème ici est que la structure n'est pas très visible et le développeur aura de forte chance de se tromper dans la construction de son arborescence. Un autre problème est que l'ajout d'un enfant à un parent se fait au moment de la construction de l'enfant, la structure du parent est donc disséminé sur ses enfants.</p>
<p>Voici une autre version du même code :</p>
<pre>JFrame frame = new JFrame();
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
JPanel panel = new JPanel();
JButton button1 = new JButton("Click me");
button1.addActionListener(new ActionListener()
{
public void actionPerformed(ActionEvent e)
{
System.out.println("Clicked");
}
});
JButton button2 = new JButton("No ! Click me instead");
button2.addActionListener(new ActionListener()
{
public void actionPerformed(ActionEvent e)
{
System.out.println("Really clicked !");
}
});
frame.setContentPane(panel);
panel.add(button1);
panel.add(button2);
frame.setVisible(true);</pre>
<p>Cette fois-ci, le développeur a choisi d'initialiser d'abord tous ses composants graphiques puis de finalement construire l'arborescense dans un dernier paragraphe. L'arborescence est ici plus lisible puisqu'un paragraphe lui est dédiée. La structure d'un parent est compacte étant donné que l'initialisation des enfants est déjà faite au dessus. Mais les initialisations des composants sont du coup loin de leur utilisation, ce qui pourrait amener le développeur à oublier de supprimer l'initialisation d'un composant après l'avoir supprimé de l'arborescence. C'est également problématique en phase de conception où le développeur devra passer sans cesse de la construction de l'arborescence à l'initialisation des composants, pas forcément proches (cet exemple est volontairement court). On pourrait également discuter de la lisibilité de l'arborescence puisqu'aucun indice ne nous permet de rapidement comprendre la structure.</p>
<p>Voici la version que je propose :</p>
<pre>new JFrame()
{{
this.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
this.setContentPane(new JPanel()
{{
this.add(new JButton("Click me")
{{
this.addActionListener(new ActionListener()
{
public void actionPerformed(ActionEvent e)
{
System.out.println("Clicked");
}
});
}});
this.add(new JButton("No ! Click me instead")
{{
this.addActionListener(new ActionListener()
{
public void actionPerformed(ActionEvent e)
{
System.out.println("Really clicked !");
}
});
}});
}});
this.setVisible(true);
}};</pre>
<p>Certains se demandent déjà si c'est vraiment du Java ? Oui c'est du Java. L'astuce se situe dans la double accolade, il s'agit en fait d'une simple accolade permettant de déclarer une classe anonyme, je dérive donc chaque classe que j'instancie. Cette classe anonyme me permet de déclarer un bloc d'initialisation à l'intérieur. N'ayant pas la possibilité de définir un constructeur, je passe par un bloc d'initialisation, principe équivalent à un constructeur en Java. La double accolade est donc un bloc d'initialisation d'une classe anonyme, c'est à dire du code qui va s'exécuter pendant le new.</p>
<p>L'intérêt de cette technique est qu'elle permet de visualiser l'arborescence grâce à l'indentation tout en conservant l'unité de l'initialisation des composants. L'inconvénient est le nombre de classes anonymes générées qui va augmenter le nombre de fichiers class compilés.</p>
<p>Cette technique est pratique pour définir des arborescences comme une interface graphiques mais elle a d'autres avantages. Il est également possible de l'utiliser pour déclarer un objet complexe sans effort, par exemple si je souhaite déclarer une Map non-modifiable et <code>final</code> :</p>
<p>De base, je ferais :</p>
<pre>Map mapLetters = new TreeMap();
map.put("A", 1);
map.put("B", 2);
map.put("C", 3);
final Map LETTERS = Collections.unmodifiableMap(mapLetters);</pre>
<p>Pas mal, mais peut mieux faire. Notamment cette map temporaire que je suis obligé de nommer, forcément avec un nom qui ne convient pas :</p>
<pre>final Map LETTERS = Collections.unmodifiableMap(new TreeMap()
{{
this.put("A", 1);
this.put("B", 2);
this.put("C", 3);
}});</pre>
<p>Voilà qui est mieux, j'arrive à me passer de la déclaration de la map temporaire, tout simplement parce que j'arrive à déclarer une map et à la remplir sans la nommer, c'est bien plus lisible ! On dirait presque que le langage Java supporte les maps nativement, ce qui le rapproche un peu plus des langages fonctionnels à la mode comme Ruby ou Javascript.</p>
<p>J'espère que ce petit interlude vous aura fait découvrir de nouveaux aspects du langage Java que j'ai moi-même découvert depuis que je m'intéresse aux langages fonctionnels. Comme quoi, il faut parfois allez voir ailleurs :)</p>Ligne de commandeurn:md5:fdb3dcd57b00097b4a225906194b3fe12008-07-26T15:36:00+00:002009-03-30T17:12:15+00:00Vincent Robert<p>Je ne suis pas un fan de la ligne de commande. Certains de mes billets contiennent même de nombreuses critiques, plus ou moins bien argumentées contre l'utilisation de la ligne de commande. Et pourtant, il se trouve que je l'utilise tous les jours... Alors pourquoi tant de haine ?</p> <p>L'argument de la difficulté de la ligne de commande est souvent l'argument le plus présenté dès qu'il s'agit de critiquer Linux ou plus exactement ses différentes distributions. L'argument avancé est que la ligne de commande n'est pas une interface utilisateur suffisante pour un débutant. Je confirme.</p>
<p>Le principe de la ligne de commande est de lancer directement des commandes, sans avoir à passer par la potentielle profondeur d'une interface graphique. Par exemple, il suffit de taper <code>curl www.google.fr</code> (sous Mac OS X) pour télécharger la page d'accueil de Google, selon les circonstances, cela peut potentiellement être plus rapide que de charger la page dans mon navigateur et de lui demander d'enregistrer cette page dans un fichier de mon disque dur. Bien sûr, le fait que la ligne de commande soit plus pratique dans ce cas dépend de nombreux facteurs : à quel point je sais utiliser mon navigateur, si l'URL se trouve dans mon presse-papier ou dans un lien, si ma ligne de commande est accessible rapidement, etc.</p>
<p>Le problème de cette ligne de commande est que la connaissance des commandes se trouve forcément dans la mémoire de l'utilisateur, aucun moyen pour un nouvel utilisateur de découvrir par lui-même la commande pour télécharger une URL. Avec Firefox, un utilisateur peut toujours parcourir les menus, découvrir la fonction de sauvegarde, l'essayer et en déduire son fonctionnement, bref l'apprendre. Ce qui différencie la ligne de commande de l'interface graphique est que l'interface graphique place la connaissance des fonctions dans le monde extérieur plutôt que dans la mémoire de l'utilisateur pour la ligne de commande.</p>
<p>Pour plus d'informations sur la différence entre placer la connaissance dans le monde extérieur et dans la mémoire utilisateur, je vous conseille l'excellent livre de Donald Norman : <a href="http://www.amazon.fr/Design-Everyday-Things-Donald-Norman/dp/0465067107/">The Design of Everyday Things</a>.</p>
<p>Le vrai problème de la ligne de commande n'est donc pas son principe mais bien que les connaissances nécessaires à son utilisation doivent se situer dans la mémoire de l'utilisateur, l'obligeant à effectuer cette phase d'apprentissage avant de réellement pouvoir utiliser l'outil. Cette phase provoque une frustration puisque l'utilisateur ne peut pas appliquer le principe d'<a href="http://en.wikipedia.org/wiki/Trial_and_error">essais et erreurs</a> pour découvrir l'outil par lui-même.</p>
<p><img src="http://genezys.net/public/DOET.jpg" alt="Couverture du livre The Design of Everyday Things" style="display:block; margin:0 auto;" /></p>
<p>Plus tard, lorsque les règles régissant l'outil sont comprises (chercher une commande sur Google, chercher dans le répertoire /bin, consulter les pages de documentation, etc.), l'utilisateur peut alors reprendre un processus à base d'essais et erreurs. Mais c'est la première phase d'apprentissage qui est généralement la plus frustrante et amène à des conclusions hâtives comme <q>la ligne de commande est un outil d'une autre époque.</q></p>
<p>Pourquoi un billet si modéré alors que j'ai depuis tant d'années si violemment critiqué la ligne de commande ? Tout simplement parce que cela fait maintenant plus de 4 ans que j'utilise Mac OS X et que j'utilise de plus en plus la ligne de commande sur ce système. Contrairement à Windows, la ligne de commande Mac est issue du monde Unix et propose des outils qui permettent de réaliser rapidement des opérations, parfois plus rapidement que dans l'interface graphique.</p>
<p>Mais l'avantage de Mac OS X sur de nombreuses distributions Linux est que la ligne de commande n'est pas nécessaire pour une utilisation basique du système. Pour prendre un exemple concret (mais loin d'être scientifique) :</p>
<ul>
<li>sur le <a href="http://forum.ubuntu-fr.org/viewforum.php?id=5">forum de support Général Ubuntu-fr</a>, je dénombre 10 sujets sur les 30 de la première page qui ont une question ou une réponse faisant appel à la ligne de commande ;</li>
<li>sur le <a href="http://discussions.apple.com/forum.jspa?forumID=1224">forum de support Mac OS X</a>, je ne dénombre qu'un seul sujet mentionnant la ligne de commande dans les 15 de la première page.</li>
</ul>
<p>30 % contre 6 %, la comparaison est vite faite... Heureusement, des distributions comme <a href="http://www.ubuntu-fr.org/">Ubuntu</a> ou <a href="http://www.mandriva.org/fr">Mandriva</a> comblent ses lacunes en développant toujours plus de petits outils graphiques destinés à fournir aux utilisateurs certains fonctions jusqu'alors limitées à la ligne de commande.</p>
<p>Attention, mon but n'est pas de taper sur Linux mais simplement de pointer du doigt les sources de frustration des utilisateurs quand ils utilisent un nouvel outil. Ceci afin que ceux qui aident ces nouveaux utilisateurs puissent y répondre plus facilement.</p>
<p>Mon but est également de montrer que cette frustration peut amener à trop vite abandonner la ligne de commande, comme par exemple celle de Windows qui malgré ses grosses limitations possèdent des fonctionnalités intéressantes, encore plus si on y ajoute le module <a href="http://www.cygwin.com/">Cygwin</a> (attention, le site est laid) permettant de profiter des outils Unix. À ces utilisateurs qui comme moi ont été frustré par la ligne de commande, je recommande la lecture du livre de Andrew Hunt et David Thomas : <a href="http://www.amazon.fr/Pragmatic-Programmer-Journeyman-Master/dp/020161622X">The Pragmatic Programmer</a> qui détaille des cas pratiques d'utilisation des outils Unix et de la ligne de commande pour un travail de programmation.</p>
<p><img src="http://genezys.net/public/the-pragmatic-programmer.jpg" alt="Couverture de The Pragmatic Programmer" style="display:block; margin:0 auto;" /></p>Vincent 2.0urn:md5:612cd51d861735c9cd7a1e6a45d5b0862008-05-12T00:58:35+00:002009-03-30T17:12:15+00:00Vincent Robert<p>J'ai beaucoup de mal à me faire à tout ces nouveaux outils web 2.0 : Facebook, Twitter et compagnie... La principale raison est que je ne vois pas l'utilité de ces outils.</p> <p>Je n'utilise pas Facebook pour rester en contact avec mes amis, je leur envoie des mails et je les rencontre dans la vraie vie. Par contre, je peux tout à fait comprendre l'intérêt des outils de réseaux sociaux dans un cadre professionnel, c'est très intéressant d'être capable de s'approcher de personnes avec les mêmes besoins professionnels. Peut-être que le succès de ces réseaux est dû à la réduction de la frontière entre vie professionnelle et vie personnelle dans notre société moderne.</p>
<p>Parmi ces outils, celui que je comprends le moins est Twitter. Quel intérêt y a-t-il à tenir un second blog et en plus à être limité dans la taille des billets (140 caractères max). Il y a apparemment des milliers d'utilisateurs qui passent leur journée à poster des billets depuis leur téléphone pour annoncer qu'ils mangent des sushis, qu'ils vont voir Iron Man, ou tout simplement qu'ils s'ennuient au travail.</p>
<p>Bref, tout ça pour vous annoncer que je me suis finalement inscrit sur Twitter. Oui je sais, pas la peine de faire un laïus sur l'inutilité de Twitter pour ensuite annoncer que je l'utilise. Désolé je suis comme ça, il faut que je comprenne cet outil étrange. Si c'est inutile et que Twitter met la clé sous la porte, je serais heureux d'avoir participé à la surcharge de leur serveur et à l'augmentation des factures qui feront que les propriétaires perdront leur maison, leur femme et leur intégrité lorsqu'ils seront obligé de vendre leur corps... Mais si c'est vraiment un outil utile, je serais heureux d'avoir mis ma fierté de côté.</p>
<p>Plus sérieusement, je souhaite vraiment prendre le temps de développer de bons articles pour ce blog, notamment sur les recherches en interface utilisateur. Mais c'est un sujet complexe et il faut souvent passer plusieurs heures pour la rédaction d'un billet. Twitter sera donc réservé pour les plus petites annonces, les petits billets de tous les jours, tous les aspects plus personnel de ce blog pour lesquels je ne prends plus le temps d'écrire un billet. J'espère que ça me permettra de redevenir plus prolixe :)</p>
<p>Rendez-vous donc sur <a href="http://twitter.com/genezys">mon compte Twitter</a> pour les plus courageux, car je ne sais pas encore ce que je vais en faire ni ce qu'il va devenir.</p>ChuWiki 2.0 alphaurn:md5:9e0247d1f9a15cf99907c0c8d357b9652008-03-01T00:54:22+00:002009-03-30T17:12:15+00:00Vincent Robert<p>Le développement continue doucement. Dans la ligné de mon billet précédent sur les numéros de versions, aucun changement majeure dans cette nouvelle version mais de nombreuses nouvelles fonctionnalités et bien sûr toujours autant de simplicité.</p> <p>(Ce billet est une recopie de <a href="http://chuwiki.genezys.net/wiki/Historique">la news du site ChuWiki</a>)</p>
<p>Le développement continue tout d'abord avec un passage en version 2.0, tout simplement parce que ce n'est pas la peine de passer un an à sortir une version si c'est pour seulement augmenter le numéro mineur de version :)</p>
<p>Après l'ajout de la gestion des templates avec <code>::include</code>, j'ai continué sur cette lancée d'ajouter des métadonnées. Voici donc <code>::toc</code> qui ajoute une table des matières générées automatiquement à partir des titres de la page.</p>
<p>On continue avec une première version de la gestion des catégories : en ajoutant un tag <code>::category Documentation | Développement</code>, vous pourrez accéder à des pages spéciales "Catégorie Documentation" et "Catégorie Développement" qui listeront toutes les pages contenant le tag.</p>
<p>Toutes ces améliorations sont disponibles aujourd'hui pour ceux qui souhaitent les tester dans la version <a href="http://chuwiki.genezys.net/wiki/Subversion">Subversion</a>.</p>IIRCurn:md5:6e21f2ae47022205963768f1cdfc514c2008-01-06T14:36:50+00:002009-03-30T17:12:15+00:00Vincent Robert<p>Cette abréviation signifie « If I Remember Correctly » et est souvent utilisée lors de discussions en ligne sur des forums, des commentaires de blogs ou même les discussions Wikipedia.</p>
<p>Je vais être franc : je déteste cette expression...</p> <p>Les origines de <a href="http://en.wikipedia.org/wiki/Internet_slang">IIRC</a> remontent aux premières discussions sur Internet, par mail ou par IRC, je ne sais pas. L'idée est simplement de réduire le nombre de caractères à taper pour une expression souvent employée. « Si je me souviens bien », vous avez sûrement déjà utilisé cette expression en discutant avec un ami ou un collègue. C'est tout à fait normal de douter de ses propres propos, personne n'est capable de retenir toutes les informations qui traverse nos minuscules amas de neurones que sont nos cerveaux, surtout de manière précise.</p>
<p>Certainement très adaptée à une discussion en directe, à la messagerie instantanée ou à IRC, je trouve que cette expression est vraiment dommageable à l'autre type de discussion : la discussion hors-ligne, celle où le contributeur prend le temps de rédiger sa réponse. Alors qu’il est possible de passer du temps à élaborer son message, certains préfèrent privilégier la vitesse de leur réponse à sa qualité.</p>
<p>Beaucoup de sites web aujourd'hui ont pris conscience de la pérennité de l'information qu'ils diffusent. Certains blogs ont atteints un niveau de vérification de l'information parfois supérieur au média traditionnel. C'est une bonne chose, la vérification d'une information augmente le nombre d'arguments en sa faveur, augmentant ainsi sa qualité et son utilité.</p>
<p>Mais cette qualité se retrouve rarement dans les contributions ajoutées par les visiteurs. <a href="http://www.joelonsoftware.com/items/2007/07/20.html">Certains</a> vont même jusqu'à remettre en cause l'idée de contribution du visiteur, et préfèrent fermer les commentaires de leurs billets ou de leur articles. Je ne suis pas d'accord avec cette idée. Si une contribution sur cent est intéressante, alors je pense que cela vaut le coup de laisser les contributions. Et puis il n'est jamais trop tard pour éduquer les gens.</p>
<p>Il est possible d'augmenter significativement le niveau de ses propres contributions d'une manière assez simple. Il suffit de prendre le temps de rédiger, n'oubliez pas que vos écrits ne sont pas publiés en temps réel, ils peuvent attendre. Si à chaque fois que vous avancez un argument dans un commentaire, un billet, essayez de l'étayer d'un lien vers ce que vous considérez comme une référence. Personnellement, je lis très souvent l'article Wikipedia associé à un sujet avant d'en parler. Cela me permet de clarifier l'état des connaissances actuelles sur le sujet mais surtout de trouver d'éventuelles références pour étayer mes arguments.</p>
<p>Cela prend du temps mais ne laissez pas les événements vous dépasser, répondre à un article en 5 ou en 20 minutes ne changera pas fondamentalement votre journée. Par contre, cela peut influencer toutes les personnes qui viendront lire vos écrits. Imaginez ce que 15 minutes de plus sur votre temps peut apporter aux milliers de visiteurs qui vous liront.</p>Dialoguer avec ses utilisateurs - Partie 2urn:md5:44fa1cf830bb8cd73796ee49c97dd3412007-08-01T23:07:43+00:002009-03-30T17:12:15+00:00Vincent Robert<p>Nous avons vu dans la <a href="http://genezys.net/blog/123-dialoguer-avec-ses-utilisateurs-1">1re partie</a> que les boites de dialogue sont une part importante de l'expérience utilisateur et qu'il est important de passer du temps sur leur conception. Mais pourquoi y a-t-il autant de différences entre les systèmes ? Pourquoi tous les logiciels tournant sous Microsoft Windows n'utilise pas ce principe alors que toutes les applications Mac OS X y sont passées. Il n'y a qu'une et une seule raison : l'API.</p> <h3>Une histoire de plateforme ?</h3>
<p>Lorsque vous développez une nouvelle plateforme, comme Windows, Mac OS X ou encore Linux, votre but est qu'elle soit utilisée. Or par définition, une plateforme n'a pas d'intérêt direct, son seul intérêt est de fournir à des développeurs des moyens de répondre rapidement et simplement à des besoins.</p>
<p><img src="http://genezys.net/public/platformes.png" alt="" style="float:right; margin: 0 0 1em 1em;" />À ce titre, il est intéressant de voir qu'il existe d'autres plateformes que les systèmes d'exploitation. On peut considérer que le web est une plateforme avec des languages comme HTML ou CSS. On peut aussi considérer certains logiciels comme des plateformes, Firefox en plus de proposer un navigateur web propose une plateforme de développement avec le principe des extensions.</p>
<p>Bref, une plateforme, c'est un outil fournissant aux développeurs des outils de plus haut niveau leur permettant de développer des applications plus rapidement que s'ils n'utilisaient pas la plateforme. Bien souvent, cela s'accompagne d'un aspect psychologique. Un développeur qui utilise une plateforme recommande généralement son utilisation à ses amis, c'est qui va faire (ou non) le succès d'une plateforme.</p>
<h3>Ah non... Une histoire de psychologie ?</h3>
<p>C'est cet aspect psychologique qui va nous intéresser. La relation avec une plateforme est généralement fusionnelle : je t'aime, tu m'aimes, je ne te quitterais pas, bref que du nian-nian. Le plus important est qu'un développeur qui est satisfait de sa plateforme va aussi avoir une tendance à ne plus considérer que cette plateforme, avec tous les travers que ça peut apporter.</p>
<p>L'API que propose une plateforme est généralement intéressante, dans le sens où il est généralement plus rapide de passer par l'API de la plateforme que de refaire à la main ce que l'on souhaite faire. Le principe est de simplifier les opérations les plus communes sans pour autant restreindre les opérations complexes. Voilà le principe fort de conception d'une API.</p>
<p>Mais voilà, ce principe n'est jamais respecté, c'est un fait. Aucun API n'est parfaite. Certaines API permettent de faire très rapidement les opérations simples mais nécessitent un effort considérable pour faire une opération complexe, bien plus considérable que si vous n'étiez pas passé par cet API à l'origine. On peut ranger ce genre de désagrément dans <a href="http://www.joelonsoftware.com/articles/LeakyAbstractions.html">la loi des abstractions qui fuient</a>.</p>
<p>Le corollaire de cette observation est que les développeurs vont avoir tendance à s'éloigner des tâches complexes comme de la peste, en prenant en compte uniquement les tâches simples lors de leur conception. Durant la phase de conception, ils vont automatiquement rejeter les idées qui leur semblent complexes à effectuer sur leur plateforme au profit de solution plus simple. On appelle cela « concevoir selon l'API » et il faut être franc, c'est la pire chose qui puisse arriver à votre logiciel car ce n'est plus seulement votre implémentation qui est dépendante d'un tiers mais toute la conception de votre application. C'est généralement le meilleur moyen de voir apparaître de nombreux clones de votre produit conçus sur le même principe.</p>
<h3>Finalement, une histoire de feignantise, tout simplement :-)</h3>
<p>Pour comprendre notre problème des boites de dialogues, il suffit de regarder les API proposées par les différentes plateformes...</p>
<p>Sous Windows, quelques solutions :</p>
<ul>
<li>la fonction MessageBox() qui vous permet d'afficher une boite Oui/Non avec un choix de quelques icônes ;</li>
<li>écrire votre fenêtre à la main.</li>
</ul>
<p>Sous Mac OS X, une seule solution :</p>
<ul>
<li>créer et gérer un objet boite de dialogue.</li>
</ul>
<p>Clairement, afficher une boite de dialogue est plus complexe dans une application Mac OS X que dans une application Windows, l'utilisation de la fonction MessageBox() étant vraiment très simple. Quelle est la conséquence de cette différence ?</p>
<p>En introduisant deux niveaux de difficulté dans son API, Windows a créé une tendance chez les développeurs à se tourner vers la solution simple et à s'écarter de la solution complexe. Bien que Microsoft recommande sur son site web de <a href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon98/html/vbconwhenthingsgowronginteractingwithusers.asp">passer du temps à concevoir les boites de dialogues</a>, l'API semble nous dire autre chose.</p>
<p>La différence principale entre ces deux API est que l'API Windows semble nous dire « Oui il faut passer du temps à concevoir les boites de dialogues, mais bon, si vous n'avez pas le temps, il est possible de faire rapidement un truc moyen ». Face à ce genre de choix, ma décision est rapide. Franchement, j'ai mieux à faire pour améliorer mon logiciel que de passer du temps sur mes boites de dialogues, non ? Le dernier Shrek est sorti au cinéma et je n'ai franchement pas envie de rater la séance.</p>
<p>Raté. Perdu. Tout faux. (Bande de petits galopins.)</p>
<p>Si votre utilisateur est frustré par l'un de vos composants, il reportera sa frustration sur tout le logiciel, le pire des composants donne donc le niveau général de qualité de votre logiciel. Vous devez donc assurez un niveau de qualité suffisant y compris dans vos boites de dialogues...</p>
<p>Oui mais voilà, c'est impossible, l'API Windows ne permet de facilement créer des boites de dialogues de qualité. Encore raté, encore perdu, encore tout faux. (Vous être vraiment une bande de petits galopins espiègles.)</p>
<p>Certes l'API Windows ne le permet pas, mais de là à dire que c'est impossible, on tombe dans de « la conception selon l'API ». Car il vous est toujours possible de créer une fenêtre, d'y placer des boutons et d'afficher ça à votre utilisateur en lieu et place de votre MessageBox(). Mieux encore, pourquoi ne pas créer votre fonction SmartMessageBox() qui permet d'afficher des boites de dialogues.</p>
<p>L'idée ici est d'arriver à sortir son esprit de la prison de l'API. Il faut tout le temps conserver à l'esprit votre but et se forcer à y arriver par tous les moyens. Parfois il suffira d'utiliser directement l'API, parfois il faudra reprendre depuis le début pour vous créer votre propre API.</p>
<p>Car finalement, le but d'une plateforme est d'arriver à minimiser votre temps de développement pour atteindre votre but, sans pour autant vous en faire changer. Il faudra donc vous demander ce qu'elle peut apporter mais surtout ce que vous ne pourrez pas utiliser par manque de qualité.</p>
<h3>Alors ? Je fais quoi moi maintenant ?</h3>
<p>Rien. En tout cas pas sur un coup de tête. Ce serait une erreur de plus que de suivre au mot mes conseils sur les boites de dialogues. Il faudra prendre le temps d'essayer, de comparer, de remettre en cause. Et puis il faudra trouver le courage de casser, de reprendre, d'améliorer.</p>
<p>Ce n'est qu'après ce long travail de recherche que le logiciel gagnera en qualité et donc en visibilité.</p>Évolution de la version d'un logicielurn:md5:512c8bc831362274b26c928a9996a3fc2007-04-05T22:57:03+00:002009-03-30T17:12:15+00:00Vincent Robert<p>Hadrien a posté un billet très intéressant présentant son avis sur <a href="http://psydk.org/archives/2007-04-04-201-evolution-de-la-version-d-un-logiciel">l'évolution à donner aux numéros de versions d'un logiciel</a> au cours de sa vie.</p>
<p>Je ne suis pas complètement d'accord avec ses propositions, je vais donc exposer les miennes maintenant.</p> <p>Tout d'abord, un point rapide : oui je sais, je n'ai pas encore mis en ligne la partie 2 de mon précédent article. Il est en cours d'écriture, considérez celui-ci comme un intermède.</p>
<p>Bon revenons à notre problème. Hadrien souhaite avoir une différence forte entre la numérotation des ajouts de fonctionnalités et les corrections de bugs. Alors qu'auparavant, il utilisait un nombre à deux chiffres pour représenter les deux, il semble s'orienter maintenant vers une séparation plus forte par un point. C'est à dire que pour désigner la 5e version avec la 4e correction, il passe de 1.54 à 1.5.4.</p>
<p>C'est une décision qui semble être suivi par de nombreux logiciels et je me sens concerné car c'est le choix de numérotation que j'ai adopté dans ChuWiki, aujourd'hui en version 1.3.1.</p>
<p>Mais voilà, il se trouve que depuis quelques temps, je suis en train de remettre en cause cette numérotation. Mon problème vient du premier chiffre de version : 1. Comment se chiffre a-t-il été choisi ? Initialement bien-sûr, lorsque le logiciel a été rendu publique pour la 1re fois en 1.0. (Je n'approuve vraiment pas les projets qui osent rendre publique une version 0.X, 1.0 signifie qu'il s'agit de la 1re version où le logiciel fait ce qu'il est censé faire initialement. Mais c'est un autre sujet que je pourrais développer une autre fois.)</p>
<p>Donc je viens de rendre publique une 1.0 dont je suis très fier. Elle ne fait pas grand chose mais elle le fait (non pas forcément bien non plus mais tant pis). Si c'est vraiment une 1.0, il y a des chances que je commence par effectuer des corrections. Ouis mais voilà, en plus de ces corrections, j'ajoute aussi quelques fonctionnalités mineures. Et hop, rapidement une 1.1 se présente. Pourquoi 1.1 ? Et bien je n'ai vraiment pas fait suffisament de modifications pour oser sortir une 2.0. J'augmente donc la version « mineure » pour signifier qu'il s'agit toujours de la version 1 mais avec quelques corrections.</p>
<p>La spirale démarre alors. Je vais finalement ajouter petit à petit (oui j'ai pas le temps !) des fonctionnalités et à chaque fois augmenter le numéro « mineure » de version. Aujourd'hui, ChuWiki est en version 1.3. Mais voilà, récemment je fais une petite correction sur le thème de la 1.3. Oh je n'ai pas modifié tant que ça la version, rien ne justifie une 1.4. Suivant la même réflexion qu'Hadrien, je crée une 1.3.1.</p>
<p>Tout cela semblerait très logique si je ne commençait pas à me poser des questions stupides comme : mais finalement, qu'est-ce qui justifierait un passage en 2.0 ? Hadrien mentionne une « évolution suffisamment significative ». Soit. Qu'est-ce qu'une évolution significative ? La nouvelle version guérit le cancer ? Ah non rien à voir... Ah mais oui ! Elle a été en partie réécrite ! Oui d'accord... Mais à quel point ? Parce que finalement, c'est ce que l'on fait tous les jours quand on fait évoluer une application que d'en réécrire des parties. Elles sont juste plus ou moins grandes.</p>
<p>« Où est-ce qu'il veut en venir ? », te demandes-tu, ô fidèle lecteur.</p>
<p>Lorsqu'on écrit un logiciel, il est normal qu'on le fasse évoluer, qu'on lui ajoute des fonctionnalités, qu'on change son architecture, qu'on corrige des bugs. Mais le plus important est finalement ce qu'on va livrer à notre utilisateur. Et dans le monde du logiciel, il n'y a que deux notions, soit vous avez modifié le logiciel, soit vous l'avez corrigé. Bingo, il n'y a que deux versions à maintenir ! La majeure : représentant le niveau de fonctionnalité et la mineure : représentant les corrections.</p>
<p>En se basant sur ce principe, ChuWiki n'est pas en version 1.3.1 mais en version... 3.1 ! Et oui, vous ne le saviez pas mais ChuWiki 3 est sorti ! C'est finalement bien plus compréhensible pour l'utilisateur. Et puis je n'ai pas à me poser toutes ces questions existencielles quand je me demande de quoi serait composé un « ChuWiki 2.0 ». J'assume enfin qu'il n'y aura jamais de version 2.0, celle qui guérit le cancer et éradique la famine dans le monde. L'évolution de mon logiciel n'est déterminé que par les ajouts que j'y fait et son histoire suit son cours.</p>
<p>Ce choix peut paraitre exagéré, mais il s'agit finalement d'assumer l'évolution de son logiciel. En effet, la version 3 de mon ChuWiki est maintenant bien loin de la version 1. Plus de fonctionnalités, pas vraiment compatibles, ses versions sont finalement plus justifiées que je ne le pensais initialement.</p>
<p>D'autres que moi ont fait ce constat. Vous avez sans aucun doute déjà entendu parler de l'histoire de cette petite plateforme appellée Java qui a évolué en version 1.0, 1.1, 1.2 (ou Java 2 comme certains « osaient » l'appeller), 1.3, 1.4 et finalement 5 puis 6. Java 6. Sun a enfin compris que les modifications apportées à son logiciel justifiaient largement un changement de version majeure. Et surtout que ce n'était pas la peine de courir derrière ce rêve qu'était Java 2.0. Je suis sûr qu'aujourd'hui, Java 6 est allé bien au-delà, pas forcément dans la même direction mais finalement dans une direction plus logique et plus tournée vers l'utilisateur.</p>
<p>Assumez vos versions ! Ne courrez pas après un rêve qui ne réalisera jamais ! À mort le 2.0 ! Vive le 3 (4, 5, 6) !</p>Dialoguer avec ses utilisateurs - Partie 1urn:md5:4a0425bee51237d1c9b6460991de5e852007-02-15T21:54:03+00:002009-03-30T17:12:15+00:00Vincent Robert<p>En ces temps de campagne présidentielle, le concept est d'actualité. Pourtant certains développeurs semblent ne pas avoir compris le concept.</p>
<p>Après tout, les boites de dialogues — car c'est bien de cela qu'il s'agit — sont une part très importante de l'expérience utilisateur dans un logiciel.</p> <p>Un des principes fort de l'utilisabilité est que les utilisateurs ne lisent pas. Loin de moi l'idée de dire que les utilisateurs ont un niveau scolaire inférieure à la maternelle, mais il s'agit plutôt de concentrer ses efforts sur ce qui est important. Les utilisateurs ne lisent pas ce qui ne les intéressent pas, en tout cas pas ce qui ne les concerne pas directement.</p>
<p>Dans le <a href="http://www.joelonsoftware.com/uibook/chapters/fog0000000062.html">chapitre 6 de son livre sur la conception d'interface</a>, Joel Spolsky nous explique comment il est préférable de minimiser le texte dans un interface utilisateur, notamment dans les boites de dialogues. En conclusion de son chapitre, il nous présente sa vision d'une boite de dialogue de confirmation pour quitter un logiciel. Selon lui, cette boite de dialogue devrait limiter ses informations au strict minimum nécessaire à la compréhension.</p>
<p><img src="http://genezys.net/public/Exit_Now.png" alt="Dialogue de confirmation contenant uniquement la question « Exit Now? » avec les boutons « Yes » et « No »" style="display:block; margin:0 auto;" /></p>
<p>Malgré tout le respect que je peux avoir pour les conceptions de Joel Spolsky, je pense qu'il est passé à côté du problème à l'époque. Le problème est rarement l'abondance d'information, le problème est qu'une interface graphique n'est pas un livre.</p>
<p>Dans un livre, on commence par introduire des personnages, puis un univers, puis les personnages dans l'univers. Ensuite commence l'histoire durant laquelle les personnages agiront sur leur monde afin de déclencher une série d'évènements les amenant inévitablement à une conclusion. C'est là, après toute leur expérience acquise durant leur histoire et avec tous les changements qu'ils auront subis que les personnages se verront attribuer la tâche souvent ingrate mais héroïque de conclure l'histoire. Bref un livre.</p>
<p><img src="http://genezys.net/public/Harry Potter 7.jpeg" alt="Couverture de Harry Potter 7" style="display:block; margin:0 auto;" /></p>
<p>Mais les histoires sont linéaires, le lecteur ne peut pas sauter à la fin du livre simplement. Il y a de grandes chances qu'il perde le fil de l'histoire ayant manqué de nombreux évènements qui ont altéré non seulement les personnages mais aussi la vision du lecteur sur l'histoire. Bref, un utilisateur qui saute à la fin d'un bouquin est perdu. (Bon sauf si le bouquin est nul, mais vu que vous ne lisez pas de mauvais bouquins, tout va bien ^^)</p>
<p>Revenons à notre interface, contrairement à un livre, celle-ci n'est pas découpée en chapitre mais en zones. Bien souvent, il est nécessaire de passer d'une zone à l'autre très rapidement, nécessaire et naturel car c'est le fonctionnement naturel de l'œil humain que de sauter de zone en zone. Voilà ce que rate Joel dans son livre. L'important n'est pas de réduire la quantité d'information distribuée à l'utilisateur mais bien de mettre en valeur les zones dans lequelles se trouve l'information importante pour en faciliter l'accès aux yeux de notre utilisateur.</p>
<p>En cela, l'interface proposée par Joel ne s'en sort pas trop mal. À première vue, il y a 3 grands points qui resortent : « Exit », « Yes » et « No ». Pourquoi ? Pour le premier c'est plutôt simple, le fait d'être en gras et en couleur le fait ressortir et attire l'œil. Les deux autres sont simplement des boutons et vont naturellement attirer l'attention de l'utilisateur de part leur nature. (C'est un syndrome naturel chez les utilisateurs de vouloir cliquouiller partout.)</p>
<p>Alors pourquoi ne pas avoir directement ajouter les actions dans les boutons, utiliser des verbes plutôt que des adverbes. Cela aurait permis à l'utilisateur de ne s'intéresser qu'aux boutons et aurait sûrement permis au développeurs de rajouter une information pertinente dans la boite de dialogue. Cette technique n'est bien sûr pas récente puisque c'est le principe retenu par Mac OS X que vous pouvez découvrir dans <a href="http://www.xvsxp.com/interface/dialogs.php">cette page comparant l'approche de Microsoft et d'Apple</a>.</p>
<p><img src="http://genezys.net/public/notsaved-x.jpeg" alt="Dialogue de confirmation de fermeture d'un document non sauvé, version Mac OS X avec les boutons « Don't Save », « Save » et « Cancel »" style="display:block; margin:0 auto;" /></p>
<p>Le principe est simple : l'utilisateur doit pouvoir répondre à la question posée simplement en regardant les boutons. Dans ce cas, on lui demande clairement de faire un choix entre « Save », « Don't Save » et « Cancel ». Si notre utilisateur est un peu pressé, voir s'il commence à acquérir une certaine expérience des boites de dialogues, il y a de grandes chances qu'il arrive à prendre une décision très rapidement. De plus, comme les boutons apportent largement assez d'informations à l'utilisateur avancé pour qu'il puisse rapidement faire un choix, pourquoi ne pas en profiter pour ajouter une information pertinente mais discrète pour aider l'utilisateur novice à faire son choix. Dans ce cas, il s'agit clairement du petit message « If you don't save, your changes will be lost. »</p>
<p>Remarquez aussi comment le bouton « Don't Save » est à une distance plus grande des deux autres boutons et à l'opposé du bouton par défaut, ceci afin de minimiser l'importance du bouton comportant le plus de risque, ainsi si notre utilisateur prend sa décision trop rapidement (par exemple parce qu'il utilise trop souvent Windows ^^), la probabilité qu'il clique sur le bouton dangereux est minimisée.</p>
<p>Bref, cette interface semble mieux conçue et plus efficace pour l'utilisateur. Comment se fait-il que d'autres systèmes (comme Windows) ne l'ait utilisée ? Pourtant, on peut trouver sur MSDN (le site de développement de Microsoft) <a href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon98/html/vbconwhenthingsgowronginteractingwithusers.asp">un article de Microsoft</a> qui conseille d'utiliser des actions dans les boites de dialogue plutôt que les boutons par défaut. Alors pourquoi abandonner cette approche ?</p>
<p><img src="http://genezys.net/public/avp06023.png" alt="Deux boites de dialogues comparant l'utilisation des boutons par défaut et de boutons décrivant des actions explicites" style="display:block; margin:0 auto;" /></p>
<p>Mais la réponse ne se situe plus dans la théorie de l'interface utilisateur mais dans la pratique. Nous verrons cela dans <a href="http://genezys.net/blog/124-dialoguer-avec-ses-utilisateurs-partie-2">la seconde partie</a> :)</p>Ce site est-il mort ?urn:md5:8074196578223ecb0fa2d0f9a27d9c4c2007-02-04T18:15:04+00:002009-03-30T17:12:15+00:00Vincent Robert<p>Oui ? Non ? Je ne sais pas...</p> <p>Il est clair que je commence à avoir honte de la date du dernier billet. Surtout quand je poste celui-ci uniquement pour faire une mise à jour, sans aucun réel contenu.</p>
<p>La question est donc simple, ce blog est-il mort ?</p>
<h3>Oui</h3>
<p>Je m'éloigne de plus en plus du monde du développement web et forcément, des blogs que j'ai initialement découvert. Ma blogosphère se réduisant, les sujets sur lesquels je peux et souhaite rebondir aussi.</p>
<p>La fonte comme neige au soleil de mon temps libre y est aussi pour beaucoup. Avec un travail me prenant une grosse partie de ma concentration de la journée, je me retrouve souvent le soir à être incapable de sortir un billet digne de ce nom. Alors je note le sujet et remet à (bien) plus tard l'écriture du billet.</p>
<h3>Non</h3>
<p>Je continue de m'intéresser au développement web, après tout, il s'agit de développement. J'ai récemment joué avec Ruby On Rails pour découvrir un peu cette nouvelle technologie. Je continue de chouchouter mon serveur pour y installer plus de fonctionnalités pour moi et d'autres.</p>
<p>Mais il s'agit plus souvent de nouveaux services que de fonctionnalités réellement liées au web. Je travaille notamment en ce moment sur une refonte de mon serveur de mail pour permettre une utilisation parallèle d'un client riche comme Thunderbird en POP3 et d'un webmail.</p>
<p>Et puis il y a pleins de nouvelles choses dont je voudrais parler. Je m'intéresse maintenant beaucoup plus aux côtés fonctionnels du développement logiciel, l'expérience utilisateur et la démarche qualité. Voici d'ailleurs un nouveau blog que j'ai ajouté à mes lectures : <a href="http://headrush.typepad.com/">Create Passionate Users</a>, où comment concevoir en direction des utilisateurs.</p>
<p>Ce blog est passionnant et s'ajoute à ma liste des blogs parlant d'expérience utilisateur. J'aimerais commencer à introduire ces nouveaux sujets sur mon blog mais je doute de ma capacité à « passionner » mes lecteurs autant qu'un Joel Spolsky.</p>
<h3>Peut-être</h3>
<p>Je vais voir, je vais essayer. Après tout, il reste encore peu de personnes en France à vraiment accorder de l'importance au côté utilisateur et à l'approche qualitative du développement logiciel. Cela semble pourtant être la tendance aujourd'hui, il suffit de voir le succès d'Apple qui malgré des prix bien supérieurs à ces concurrents directs (Dell, HP) continue son ascension dans le monde de l'électronique grand public.</p>
<p>Alors à bientôt, jusqu'à la prochaine mise à jour de ce site, un jour.</p>Programmation et valeur de retour IIurn:md5:c63c03a9cf215f3e8d6d5bfd4b17a6602006-08-01T13:58:52+00:002009-03-30T17:12:15+00:00Vincent Robert<p>Ce billet fait suite à <a href="http://genezys.net/blog/107-programmation-et-valeur-de-retour">Programmation et valeur de retour</a>, un précédent billet dans lequel je présente les problèmes que posent certains langages dans la gestion des valeurs de retour.</p>
<p>J'ai décidé d'écrire une suite à ce billet car mon expérience s'est depuis enrichie d'un nouveau langage me permettant d'apporter un nouvel argument à mon idée : Visual Basic.</p> <h3>Illustration du problème en C++</h3>
<p>Reprenons tout d'abord la fonction puissance codé originellement en C++</p>
<pre>int pow(int nValue, int nPower)
{
int nReturn = 1;
while( nPower > 0 )
{
nReturn *= nValue;
nPower -= 1;
}
return nReturn;
}</pre>
<p>Ma critique, il est vrai mal formulée dans mon premier article, vient des toutes premières lignes de cette fonction. En effet, bien que déclarant retourner un <code>int</code>, demandant donc au compilateur d'allouer de l'espace pour une valeur de retour, nous sommes tout de même obligé de déclarer un nouvel <code>int</code> dès la première ligne de notre fonction.</p>
<p>Ceci vient simplement du fait que l'espace réservé par le compilateur pour la variable de retour n'est accessible que par le mot-clé <code>return</code> permettant d'effectuer la copie d'une variable dans la valeur de retour. Le problème vient donc uniquement du fait que le programmeur ne possède aucun moyen d'accès sophistiqué à cet espace mémoire en C++.</p>
<h3>La solution en Visual Basic</h3>
<p>Dans Visual Basic au contraire, le design de ce langage permet au programmeurs de manipuler cet espace. Voici ce que donnerait la fonction puissance en Visual Basic 6.</p>
<pre>Function Pow(ByVal nValue As Long, ByVal nPower As Long)
Pow = 1
Do While nPower > 0
Pow = Pow * nValue
Loop
End Function</pre>
<p>On remarque tout de suite qu'il n'est plus nécessaire de déclarer une nouvelle variable pour retourner le résultat, le langage nous laissant utiliser le nom de la fonction pour accéder à la variable de retour. Voilà une astuce intéressante.</p>
<h3>Avantages</h3>
<p>Le premier avantage est qu'il est n'est pas nécessaire pour le programmeur d'utiliser une nouvelle variable. Le but d'une fonction est sémantiquement de créer une nouvelle variable, le langage nous fournit donc logiquement un moyen d'accéder directement à cette nouvelle variable durant son processus de création.</p>
<p>Le second avantage est la séparation forte entre la notion de valeur de retour et la notion de fin de la fonction. En C++, le mot-clé <code>return</code> a non seulement l'effet de copier une valeur dans la valeur de retour mais aussi de quitter sur le champs l'exécution de la fonction.</p>
<p>Or il est souvent nécessaire d'effectuer des traitements après avoir calculer la valeur de retour, en C++, cela n'est faisable qu'en utilisant une variable locale. Une illustration que je fais souvent de ce problème est la différence en C++ entre l'opérateur de <code>i++</code> et <code>++i</code>. Regardons l'implémentation de ces deux fonctions en C++ :</p>
<pre>int PreIncrement(int& i)
{
i = i + 1;
return i;
}
int PostIncrement(int& i)
{
const int nSave = i;
i = i + 1;
return nSave;
}</pre>
<p>On voit très bien que le <code>PostIncrement</code> devant retourner la valeur de <code>i</code> avant son incrémentation, on est obligé d'en sauvegarder la valeur dans une variable locale, consommant ainsi 4 précieux octets.</p>
<p>L'implémentation des mêmes fonctions en Visual Basic ne pose plus ce problème :</p>
<pre>Function PreIncrement(ByRef i As Long) As Long
i = i + 1
PreIncrement = i
End Function
Function PostIncrement(ByRef i As Long) As Long
PostIncrement = i
i = i + 1
End Function</pre>
<p>En Visual Basic, il est possible d'utiliser la valeur de retour comme une variable locale. Ainsi, on peut fixer sa valeur, voir même effectuer des calculs avec. La fonction <code>PostIncrement</code> n'utilise alors plus de variable locale, elle modifie juste la valeur de retour avant d'effectuer son traitement, ce qui est impossible en C++.</p>
<h3>Discussion</h3>
<p>Il est vrai que l'approche de Visual Basic n'est pas simple à appliquer à un langage comme le C++. Visual Basic initialisant toujours les variables, dans le cas d'un appel de fonction, la valeur de retour est donc toujours initialisée à la valeur par défaut pour le type de retour (0 pour les nombres).</p>
<p>Cette initialisation permet de s'assurer que même si le programmeur n'assume pas sa responsabilité de remplir la valeur de retour, son état est toujours correct. Ce genre d'approche n'est bien sûr pas du tout possible dans un langage comme C++ qui se veut bas niveau.</p>
<p>Le choix fait par C++ pour s'assurer de la validité des valeurs de retour est de toujours appeler le constructeur par recopie, cet appel étant fait par le mot-clé <code>return</code> dont la présence est obligatoire dans les fonctions. Finalement, on se rend compte que cette solution est loin d'être meilleure que celle choisie par Visual Basic.</p>
<p>Cependant, il serait intéressant de fournir un accès plus fin à la variable de retour, pour tous les avantages ci-dessus. En obligeant le programmeur a effectuer un appel à un constructeur quelconque pour le type retourné, le langage serait ainsi assuré de la validité de la valeur de retour tout en laissant la liberté au programmeur de construire la valeur de retour comme il le souhaite.</p>
<p>Ainsi la fonction PostIncrement pourrait ressembler à cela :</p>
<pre>int PostIncrement(int& i)
{
return = i; // Appel d'un constructeur par recopier de int avec la valeur i
i = i + 1;
}</pre>
<p>Et pour reprendre mon exemple du précédent article avec les matrices, voici ce que j'aimerais faire dans ma méthode <code>Multiply()</code></p>
<pre>Matrix Matrix::Multiply(const Matrix& m)
{
return = Matrix(0); // Appel d'un constructeur spécial n'initialisant pas les données
// Remplissage de la matrice Multiply
...
}</pre>
<p>La méthode <code>Multiply()</code> retrouve alors son statut de constructeur de variable, avec toute la responsabilité que cela implique. Cette approche a aussi pour intérêt que les programmeurs ne se tiennent plus à l'écart des retours par valeur, souvent très coùteux mais bien plus clair syntaxiquement et sémantiquement.</p>
<h3>Juste un mot sur GCC</h3>
<p>Les nouvelles fonctionnalités que je présente ne sont bien sûr pas présentes dans le langage C++ et il est impossible de les utiliser avec votre compilateur habituel, cependant les compilateurs redoublent d'imagination pour contourner ce problème.</p>
<p>Le choix que fait GCC n'oblige pas le programmeur à utiliser un constructeur sur la valeur de retour. Il préfère partir du principe que si le programmeur retourne une variable locale (construite avec le constructeur de son choix), son intention est en fait de définir la valeur de retour.</p>
<p>Ainsi, lorsque le programmeur définit une variable locale qui sera utilisé avec le mot-clé <code>return</code>, GCC modifie alors le code pour que le programmeur accède directement à la valeur de retour lorsqu'il utilisera cette variable locale, plutôt que de créer une nouvelle variable, faisant ainsi l'économie de la création d'une nouvelle variable.</p>Du nouveau pour ChuWikiurn:md5:2d416b81d6f19528742af14efc42fc8d2006-06-22T00:50:25+00:002009-03-30T17:12:15+00:00Vincent Robert<p>Voilà quelques temps que je délaissais mon wiki, mais de nouveaux utilisateurs amenant de nouvelles demandes, j'ai dû me remettre au travail et commencer une version 1.3.</p> <p>J'ai peu de temps pour travailler sur ChuWiki, surtout qu'il a atteint un stade où il est difficile d'ajouter des fonctionnalités sans le rendre plus complexe. Et comme il fonctionne correctement pour moi jusqu'à maintenant, je ne ressens pas le besoin de le modifier en profondeur.</p>
<p>Cependant, j'ai de plus en plus d'utilisateurs, et certains avec des wikis bien plus actifs que le mien. Le choix de ChuWiki ne parait pas toujours naturel pour ces sites à fort trafic et pourtant, on sous estime souvent le pouvoir de la simplicité sur la fonctionnalité ;)</p>
<p>Un des points critiques de ChuWiki aujourd'hui est son utilisation de fichiers. Bien que ce choix le rendre plus intéressant pour des petits wikis, dès que le volume de contenu augmente, l'accès aux fichiers devient difficile. Il est cependant hors de question que je fasse machine arrière et me décide à utiliser une base de données, l'utilisation des fichiers est une principe fondateur de ChuWiki. La prochaine version 1.3 intègre donc un nouveau système de cache permettant d'accélérer l'affichage des pages. Le principe étant de stocker la date de dernière version plutôt que de la calculer comme c'était fait auparavant. Ça semble fonctionner pour le moment puisque c'est en test sur le site même de <a href="//chuwiki.berlios.de">ChuWiki</a>.</p>
<p>Une autre nouveauté pour la version 1.3 est l'ajout d'un nouveau template. Continuant sur le template par défaut, il intègre maintenant une barre de menu sur le côté. Ceci est possible grâce à une modification du système de template permettant d'effectuer le rendu de plusieurs pages sur un seul appel. Sur une seule page du wiki, on peut donc maintenant combiner le rendu d'une page de menu et le rendu de la page courante. Voilà donc plus de souplesse pour les concepteurs de template tout en conservant une grande simplicité.</p>
<p>Enfin, mais c'est encore en test, il sera possible de protéger des pages contre l'édition. Je travaille encore sur cette fonctionnalité mais l'idée est de pouvoir indiquer simplement qu'une page est protégée contre toute édition. Seule l'administrateur du wiki, par une action sur son serveur, pourra bloquer ou débloquer une page. Je réfléchis encore au fait de proposer une telle fonctionnalité pour tout le wiki, certains voulant se servir de ChuWiki plus comme un CMS que comme un wiki. (L'ayant fait quelques temps sur ce site, je peux comprendre ^^)</p>
<p>Et enfin, la dernière mais néanmoins importante nouvelle, un forum est maintenant disponible pour vos discussion à propos de ChuWiki. Quelle galère pour trouver un système de forum qui soit conçu comme ChuWiki, simple mais efficace... Trop de forums s'appuient sur une base de données, c'est affreux. Mais j'ai trouvé ! Il s'appelle ChuForum, il a été codé par moi-même et il devrait bientôt être publié sous license GPL comme son ami le wiki ^^</p>
<p>En attendant la publication de ce nouvel outil, je vous invite à aller visiter <a href="//chuwiki.berlios.de/forum">le forum de ChuWiki</a>.</p>Rien de neuf, si ce n'est tout le resteurn:md5:9f1f89d878c346b18b06dead03990b152006-04-19T00:34:44+00:002009-03-30T17:12:15+00:00Vincent Robert<p>C'est forcément lorsqu'on annonce que l'on souhaite s'occuper un peu plus de son site que les circonstances sont là pour que ça n'arrive pas.</p>
<p>J'ai passé pas mal de mon temps à effectuer une tâche que je n'ai pas l'habitude de faire. J'ai en effet troqué pour quelque temps ma casquette de développeur de logiciel pour un casque d'administrateur système.</p> <p>Depuis quelques temps, je commence à avoir des besoins bien spécifiques en matière de disponibilité sur Internet, notamment pour héberger des développements logiciels. Malheureusement, les hébergeurs web ne proposent pas du tout ce type de services et les hébergements dédiés au développement (SourceForge ou Berlios par exemple) n'offre pas une qualité d'hébergement suffisante en terme de fiabilité ou de vitesse.</p>
<p>C'est pourquoi j'ai craqué pour un serveur dédié. Pour mes besoins, seul un serveur personnalisé me permettrait d'héberger tous les services dont j'ai besoin, plusieurs choix s'offrent alors à moi : héberger un serveur chez moi sur ma ligne ADSL, louer un serveur dédié ou acheter un serveur et louer la bande passante dans un data center.</p>
<p>Ok la dernière solution était en fait bien trop chère pour mon budget, adaptée à une société qui fait des profits mais pas à un particulier qui souhaite se lancer. J'ai vite laissé tomber si je ne souhaitais pas dormir sous un pont, mais avec un joli serveur :)</p>
<p><img src="http://genezys.net/public/freebox.jpeg" alt="" style="float:left; margin: 0 1em 1em 0;" />Héberger un serveur chez moi a été la solution à laquelle j'ai le plus longuement réfléchie. Quand on voit les débits actuels des lignes ADSL pour les particuliers, elles fleurtent aujourd'hui avec les débits que promettent certains hébergeurs. Je me suis donc mis en quète d'un ordinateur assez peu encombrant et surtout très silencieux, pour me permettre de dormir tranquille quand la bète tournerait 24h/24.</p>
<p>Je me suis tour à tour intéressé aux mini-PC, aux serveurs, mais jamais rien de bien concluant. Et puis je suis tombé sur <a href="http://www.web1.fr/comparatif_giga-webpack_fr_FR.php">une offre de la société NFrance</a>. J'avais déjà eu à faire à cette société qui propose notamment <a href="http://www.hebergement-gratuit.com/index.php">un hébergement gratuit pour celui qui possède un nom de domaine</a>. Bien que cet hébergement gratuit soit très limité (pas de base de données et peu d'espace disque), la qualité est tout de même au rendez-vous.</p>
<p>Un tel prix pour un serveur dédié, même virtuel, je ne pouvais pas ne pas essayer. J'ai donc fait chauffer la carte bleue pour essayer cette offre, franchement avec un engagement de 3 mois minimum, ça ne se refuse pas. Mais me voilà donc aussi embarqué dans une toute nouvelle aventure, l'installation d'un service d'herbegement complet à partir de... rien. Bon je connais déjà le système Debian qui est installé sur le serveur, je peux donc me débrouiller avec les maigres connaissances que je peux avoir de ce système.</p>
<p><img src="http://genezys.net/public/powered-by-debian.jpg" alt="" style="float:right; margin: 0 0 1em 1em;" />Voilà maintenant une semaine que je me débat avec ma Debian, mais pour un résultat dont je suis assez fier. J'ai déployé un serveur Apache 2, un petit PHP et une base MySql, les serveurs POP et SMTP sont aussi en place pour gérer mes mails, ce qui fait maintenant de ce serveur un serveur du même niveau que ce que propose un hébergeur actuellement. Il ne reste maintenant plus qu'à ajouter les petits plus comme un serveur SubVersion suivi d'un <a href="http://www.edgewall.com/trac/">Trac</a> ou d'un <a href="http://www.fogcreek.com/FogBugz/">FogBugz</a>, selon le budget :)</p>
<p>Bon c'est vrai, je suis un peu égoïste puisque je vous parle seulement du résultat et pas des moyens. Je devrais de ce pas commencer à bloguer les différentes techniques que j'ai utilisé pour installer tous ces services sur mon serveur. Premièrement, les résultats sont plus intéressants, tout ce que vous avez à savoir c'est que ce blog sera maintenant plus rapide, comme tous les sites que je pourrais héberger dessus. Deuxièmement, je commence à saturer du SSH, de la ligne de commande et de toutes ces choses.</p>
<p>J'aurais aimé avoir un gros « clickodrome » qui me fasse ça tout seul depuis ma connexion à distance. Je sais qu'il en existe pour des besoins aussi spécifique que configurer un firewall, mais mettre en place un serveur d'hébergement, je ne connais pas. Il faut avouer que pas mal des tâches d'administration sont très répétitives et nécessitent de développer des scripts pour se simplifier la tâche. Bien sûr, je ne l'ai pas fait, déjà parce que je n'ai pas autant de clients qu'un hébergeur professionnel, puis parce que je ne suis pas très doué en script shell, enfin parce que j'avais la flemme et que les deux excuses précédentes sont plutôt nulles.</p>
<p>Je passe sous silence la mise à jour de DotClear vers la dernière version, le changement des URL des billets grâce au plugin de <a href="http://tw.apinc.org">Steve Frécinaux</a> même si les anciennes fonctionnent toujours, la page de contact récemment ajoutée et le nouveau plugin de détection du spam basé sur un filtre bayesien et me permettant enfin de réactiver la publication immédiate des commentaires.</p>
<p>Bon surf !</p>
<p><strong>MISE À JOUR</strong></p>
<p>Comme si ça ne suffisait pas, NFrance annonce aujourd'hui que <a href="http://forum.web1.fr/read.php?f=2&i=6916&t=6916">les offres sont mises à jour à partir de mardi</a>. J'avais quelques temps hésité à prendre l'offre 2 mais je suis resté sur l'offre 1 pour cause de budget sérré, finalement, j'aurai l'offre 2 pour le même prix :-)</p>Reconception du siteurn:md5:de591a6bfb12bec8d76195982ba97a7c2006-04-04T23:55:45+00:002009-03-30T17:12:15+00:00Vincent Robert<p>Ce site est là depuis longtemps, pas forcément pour les bonnes raisons et pas forcément pour toujours poster des choses intéressantes. Cependant, je me soigne. Il faut donc que je commence forcément par donner à ce site une allure qui me corresponde plus.</p> <p>Terminé donc le Dotclear de M. Tout-le-monde ! Le site est toujours propulsé par Dotclear, mais l'outil est toujours là par simple manque de temps. En effet pour cette reconception j'ai fait un petit bilan de ce que je souhaitais voir apparaitre sur mon blog. Conclusion, c'est impressionnant le nombre de bidules dont je ne me sers jamais.</p>
<p>Voilà donc un nouveau blog reconçu pour amener uniquement les fonctionnalités qui m'intéressent :</p>
<ul>
<li>une liste des billets récents en page d'accueil ;</li>
<li>la possibilité de voir chaque billet de manière unique ;</li>
<li>la possibilité d'y laisser un commentaire facilement ;</li>
<li>la liste complète des billets publiées ;</li>
<li>les fils RSS et autres machins à la mode.</li>
</ul>
<p>Première étape de cette reconception, tout casser et proposer de nouveau ces fonctionnalités. Forcément, il est de base impossible dans Dotclear d'afficher la liste de tous les billets. Heureusement, un rapide tour sur le net et dans le code me permettent de résoudre ça rapidement. La première étape se passe plutôt bien.</p>
<p>Deuxième étape, essayer de proposer les fonctionnalités qu'il faut ou il faut. Je réfléchis beaucoup à ce genre de choses en ce moment. Pourquoi ajouter une fonctionnalité ? Bah parce qu'elle est là et qu'elle servira bien à quelqu'un un jour... Et bien non ! Ça va rendre l'utilisation trop complexe, l'utilisateur sera perdu ?.. Et bien toujours non ! (Enfin si mais vous avez déjà dépassé ce stade hein ?)</p>
<p>J'aime à penser que la conception que l'on peut avoir, les frustrations et les joies que l'on provoque chez l'utilisateur font toute partie d'un tout, oui oui, les frustrations aussi, ce sont même les plus importantes. L'humain moyen a une facheuse tendance à rester à l'écart de tout ce qui le fruste, il va donc modifier inconsciemment son comportement pour contourner cette frustration.</p>
<p>Lorsque vous répondez à quelqu'un sur un forum, vous avez toujours l'habitude de citer ses propos avant de lui répondre, point par point, comme un bon informaticien que vous êtes. Et bien allez essayer de faire cela sur <a href="http://discuss.joelonsoftware.com/?joel">le forum de Joel Spolsky</a>. Héhé, raté. Lorsque vous écrivez votre réponse, le concepteur du forum a poussé le vice jusqu'à ne pas vous montrer le fil de messages auxquels vous répondez. Croyez-le ou non, mais cette décision est intentionelle, mesurée et n'a rien à voir avec une quelconque limitation technique. Le but est d'inciter les utilisateurs à ne pas citer, afin de conserver à la discussion un flot naturelle, facilitant ainsi la lisibilité pour un utilisateur extérieur devant relire un par un tous les messages. Vous remarquerez qu'il est généralement plus simple de suivre une discussion quand il s'agit effectivement d'une discussion plutôt que d'un message répété 4 fois, dont les arguments ont été découpés, déplacés et réfutés.</p>
<p>Bon je diverge, tout ça pour dire que j'ai essayer de prendre en compte ce genre de réflexion dans la conception de ce blog, je ne suis pas encore satisfait (on voit encore les messsages précédents lorsqu'on poste un commentaire) mais il s'agit là d'une limitation de l'outil que je n'ai ni le temps ni l'envie de contourner. Le truc est que maintenant que j'ai parfaitement cadré mes besoins, ils sont incroyablement plus simple que les fonctionnalités que me proposait Dotclear, ce qui rend cet outil... euh bah... plus du tout indispensable. En fait, me recoder un outil de blog équivalent avec l'expérience que j'ai maintenant sur <a href="http://chuwiki.berlios.de">ChuWiki</a> ne serait pas si difficile.</p>
<p>Enfin voilà, la phase de transition est amorcée, je compte bien rendre ce blog plus personnel afin de m'y lacher et de vous raconter toutes les folles histoires qui me passe par la tête :)</p>Vacances !urn:md5:068e1a5848255b85397280d5d58972912006-03-18T08:27:23+00:002009-03-30T17:12:15+00:00Vincent Robert <p>Je pars au ski pour une semaine !</p>
<p>Subissant une vague de spam ces derniers temps, je suis obligé de désactiver les commentaires durant cette période, désolé.</p>
<p><strong>MÀJ</strong>: Je suis de retour, les commentaires et trackbacks sont réouverts :)</p>Un navigateur sambaurn:md5:d908b7c0c4a05ca873eaeb04584c893d2006-02-28T10:38:45+00:002009-03-30T17:12:15+00:00Vincent Robert<p>Je suis à la recherche d'un petit logiciel permettant de naviguer parmis les serveurs samba comme peut le faire un client FTP.</p>
<p>Voici donc la description de ce que je recherche. Si vous trouver que ce document ressemble à une spec, c'est normal :)</p> <h3>Ce que je cherche</h3>
<p>Pourquoi je ne veux pas utiliser Explorer :</p>
<ul>
<li>il est lent ;</li>
<li>il semble faire tous les appels en synchrones donc quand le réseau est lent, il freeze ;</li>
<li>je n'aime pas l'idée d'intégrer ce genre de fonctionnalités dans l'explorateur de fichiers, ce sont des fichiers distants et doivent être traités comme tels.</li>
</ul>
<p>Je cherche donc un programme :</p>
<ul>
<li>petit ;</li>
<li>rapide ;</li>
<li>pas trop laid (c'est incroyable comme les divers remplacement d'explorer sont laids) ;</li>
<li>tournant sous Windows.</li>
</ul>
<h3>Exemples d'utilisation</h3>
<p>Vincent, votre geek préféré, vient de recevoir une magnifique image prise par un microscope electronique. Il décide de sauver cette image sur le serveur de sa société pour la conserver pour de futurs tests. Il sauve l'image sur son bureau et lance <em>NetworkExplorer</em>. Après avoir sélectionné le groupe de travail de sa société, il voit apparaitre la liste des serveurs disponibles, double clique sur l'icône de son serveur (tiens le nom est moche, il faudra proposer au patron de le changer) et voit apparaitre la liste des partages. Il navigue alors jusqu'à son répertoire contenant toutes les données microscopiques et y crée une nouveau répertoire « images ». Il ne reste plus qu'à effectuer une petit drag'n drop de son fichier vers ce répertoire. Et voilà !</p>
<p>Philippe, chef d'entreprise préssé, veut récupérer l'image que son abruti de nouveau développeur vient de mettre sur le serveur. Il lance donc <em>NetworkExplorer</em> pour aller chercher cette image. En fouillant dans les répertoires du serveur, il tombe enfin sur un répertoire « images » (« quel nom absurde » ce dit-il) et télécharge l'image sur son PC.</p>
<h3>Comment je le vois</h3>
<p>L'interface doit ressembler à un explorer mais simplement permettre la navigation vers une ressource du réseau, avec toutes les spécificités que ça implique.</p>
<p>Elle ne doit pas permettre de lancer les commandes habituelles de l'explorateur sur les fichiers distants.</p>
<p>Elle doit permettre d'envoyer ou de recevoir des fichiers par simple drag'n drop.</p>
<h3>Mise à jour 13:08</h3>
<p>J'ai oublié de préciser que ce programme devait bien sûr fonctionner sur Windows :) Il peut fonctionner sur d'autres plateformes, ce serait un plus, mais ce n'est pas indispensable.</p>ChuWiki accepte maintenant les dons PayPalurn:md5:6e1aea36b814bce929e2f7dab40927812006-02-10T17:35:33+00:002009-03-30T17:12:15+00:00Vincent Robert <p>ChuWiki est une application qui commence à prendre doucement de l'ampleur. Comme je ne souhaitais pas mettre de publicités sur le site, j'ai décidé de mettre un petit bouton PayPal pour accepter des dons (tout en bas, en super discret ^^).</p>
<p>Je me doute bien que cela ne ramènera pas des millions mais je pense que certains ont peut-être envie d'aider le projet sans pour autant s'investir dans le développement. Si je peux vous rassurer sur un point, tout l'argent obtenu par ces dons sera utilisé pour le développement de ChuWiki (création de bounties, paiement d'hébergement, etc.).</p>
<p>Merci à tous ceux qui apportent ou pourront apporter leur contribution à ce projet :) Je rappelle tout de même l'addresse du site web de <a href="//chuwiki.berlios.de">ChuWiki</a> ^^</p>XMLHttpRequest, fonctionnalités et simplicitéurn:md5:f5a2394738c247d93a9b39d2c5ca253a2006-01-22T18:33:13+00:002009-03-30T17:12:15+00:00Vincent Robert<p>XMLHttpRequest est un objet Javascript que les développeurs web peuvent utiliser dans leur page web pour effectuer des requêtes HTTP directement depuis leur script, sans passer par le chargement d'une page dans le navigateur.</p>
<p>Dans le cadre de mon travail, j'ai récemment eu à utiliser cet objet de manière assez intensive. Ayant suivi pas mal d'articles à son propos et l'ayant un peu utilisé pour divers tests, je me suis lancé tête baissée dans un code qui ne s'est finalement pas révélé si simple à écrire...</p> <p>Je passerai sur la présentation de l'objet XmlHttpRequest, il existe de nombreuses documentations sur Internet qui vous permettront de commencer à écrire des scripts utilisant cet objet. Cependant, en effectuant une utilisation plutôt intensive de cet objet, j'ai pu remarquer que ces documentations restaient toujours muettes sur de nombreux aspects problématiques.</p>
<p>Un script de test utilisant cet objet consiste souvent à envoyer une simple requête vers une URL et à recevoir la réponse à cette requête dans une fonction callback fixée par l'utilisateur. Rien de plus simple me direz-vous ? En apparence en effet.</p>
<p>Il existe pourtant deux points qui rendent l'utilisation de cet objet non triviale dans une vraie page web dynamique :</p>
<ol>
<li>il n'existe aucun moyen de vérifier que la connexion avec le serveur a bien été établie ;</li>
<li>il n'existe aucun moyen de spécifier des callbacks indépendantes pour chaque requête.</li>
</ol>
<p>Le premier point est très grave. Lorsque vous effectuez une requête HTTP vers un serveur distant, il n'existe aucune raison que ce serveur soit disponible. Bien sûr, c'est peu probable, car le serveur appelé est souvent le même que celui de la page web, il est donc disponible puisque la page web vient de s'afficher. Voilà une affirmation bien fausse. Ce n'est pas parce que vous venez de charger une page web que le serveur ne vient pas de tomber quelques secondes plus tard, de plus, rien ne garantit que l'application web que vous développez n'est pas destinée à fonctionner plusieurs heures sans jamais recharger la page principale (ce qui était mon cas), laissant ainsi largement le temps au serveur de tomber pour surcharge ou maintenance.</p>
<p>Le second point est moins grave, mais ennuyeux. Rares sont les applications web qui font toujours les mêmes requêtes. Il y a bien sûr ceux qui ont pensé à élaborer un protocole de communication assez simple afin d'avoir des fonctions de communications génériques. Cela permet de toujours utiliser la même fonction callback pour gérer les communications. Cependant, il est des cas où on ne contrôle pas ce que le serveur retourne (c'était mon cas), dans ce cas il est souvent nécessaire de mettre en place des fonctions callback différentes selon les différents types de réponse que l'on peut recevoir. La seule solution correcte dans ce cas est de créer autant d'objet XMLHttpRequest que de types de communication. Voilà qui n'est pas très pratique pour le développeur.</p>
<p>Selon moi, l'objet XMLHttpRequest marque un tournant dans la vie des développeurs d'applications web qui ne sont enfin plus dépendants du chargement des pages web pour récupérer des données depuis un serveur distant. Cependant, il existe encore des petites anomalies dans sa conception qui me font dire que son utilisation n'est pas encore à la portée de tout le monde, en tout cas pas pour réaliser des applications de qualité.</p>
<p>Pour continuer dans la veine du précédent billet, il est clair que le futur sera aux évolutions des langages de balisage (XUL, extension du HTML, XHTML 2, etc.) afin de redonner plus de responsabilités au navigateur et de revenir à plus de simplicité dans le développement d'applications web permettant ainsi de les fiabiliser plus facilement.</p>Attribut target & XHTML 2.0urn:md5:de0f85d8a5baf1b0aefe39e348d703752006-01-18T23:00:45+00:002009-03-30T17:12:15+00:00Vincent Robert<p>Il y a maintenant plusieurs mois, une première version de la spécification XHTML 2 a été rendue publique. Je me souviens avoir été choqué en la parcourant de retrouver l'attribut target dans les liens hypertextes toujours pour la même signification, l'ouverture de ce lien dans une frame. Je me rappelle avoir songé à l'époque à une autre utilisation de cet attribut...</p> <p>Tout le monde s'accorde à dire aujourd'hui que les frames sont plus généralement source d'ennuis que d'avantages dans la conception d'un site web. (Je ne reviendrais pas sur les pages impossibles à marquer, l'indexation difficile et la surcharge serveur engendrée par l'augmentation du nombre de fichiers à télécharger.)</p>
<p>Cependant, j'avais à l'époque trouver une utilisation amusante de l'attribut target : et si celui-ci, au lieu de désigner la fenêtre de destination du lien servait maintenant à désigner l'élément de destination, en utilisant un ID. La page liée se chargerait alors dynamiquement à l'intérieur de la page courante, sans avoir à recharger la page courante. Les avantages des frames sans leurs inconvénients.</p>
<p>Aujourd'hui, tout le monde me dira que c'est très facilement réalisable en utilisant l'objet XMLHttpRequest. Mais à l'époque, cette technologie n'était pas aussi répandue qu'aujourd'hui et je trouvais qu'il s'agissait d'une bonne voie à prendre pour le futur des pages web.</p>
<p>Pour expliquer ma vision, je souhaitais développer une page web simulant ce phénomène en utilisant Javascript. Malheureusement, mon ignorance de l'objet XMLHttpRequest et ma méconnaissance des fonctionnalités du DOM m'ont empêché de réaliser cette page.</p>
<p>Suite à un billet récent de Laurent Jouanneau (pointant sur <a href="http://ljouanneau.com/blog/2005/09/29/478-ajax-est-deja-obsolete">un autre encore plus intéressant</a>), j'ai repensé à cette histoire. Avec mes connaissances actuelles de l'objet XMLHttpRequest et de la manipulation du DOM, je pouvais facilement réaliser cette démonstration. Sitôt dit, sitôt fait :)</p>
<p>J'ai fait une <a href="http://mess.genezys.net/Target">petite page web</a> affichant les fichiers et les dossiers de mon répertoire mess. Les deux liens possèdent un attribut target pointant vers un ID dans la page. Lorsque l'utilisateur clique sur un lien, le contenu pointé est chargé directement dans l'élément pointé par l'attribut target. La responsabilité du formatage reste donc du côté du serveur (pas comme AJAX) mais cela permet cependant de réaliser de manière simple et rapide une application web plutôt dynamique.</p>
<p>La version actuelle utilise bien sûr du Javascript et n'a pour le moment été testé que sur Firefox et Safari, mais cette fonctionnalité pourrait facilement être disponible nativement dans les navigateurs. Il faudrait pour cela ajouter une fonction open() dans les éléments Node comme il en existe une dans Window et normaliser le fait qu'une valeur d'attribut target commençant par un # signifie d'appeler cette fonction open() sur l'élément pointé plutôt que sur la Window.</p>Google Talk s'ouvre sur le mondeurn:md5:feeda4a230fe75d37f5dc9eb52a33d712006-01-18T22:40:58+00:002009-03-30T17:12:15+00:00Vincent Robert <p>Depuis que Google a annoncé un client de messagerie instantanée basé sur le protocole ouvert Jabber, tous les utilisateurs de ce protocole se réjouissent de la promotion de leur protocole favori. Malheureusement, lors de l'ouverture de ce service, Google proposait bien un serveur Jabber mais ne proposait pas une fonctionnalité importante de ce protocole permettant de relier ce serveurs aux autres serveurs Jabber publics.</p>
<p>Cette isolation ne le rendait finalement pas mieux que les autres services de messagerie, contraignant toujours l'utilisateur à passer par des serveurs Google pour parler à ces amis. Google avait promit l'ouverture de leur serveur mais cela se faisait maintenant pas mal attendre.</p>
<p>La chose est maintenant réparée depuis que le serveur de Google est accessible depuis l'extérieur. Ce qui signifie que toute personne utilisant un compte Google Talk peut maintenant discuter avec des amis se trouvant sur le réseau Jabber, et inversement.</p>
<p>Voilà qui va me motiver encore plus pour proposer à mes amis d'utiliser Google Talk.</p>
<p>Source: <a href="http://artis-tic.com/blog/index.php?2006/01/17/234-google-talk-souvre-au-reseau-jabber">Talou</a></p>
<p><strong>Forcément, j'oublie le lien pour que les gens puissent <a href="http://www.google.com/talk/">télécharger Google Talk</a> (nécessite Windows 2000/XP)</strong></p>