Pourquoi pas Opera comme lecteur RSS ?

Pour ceux qui cherchent un lecteur RSS, comme Thomas, pourquoi ne pas essayer Opera ? A coté du meilleur navigateur web du monde, d’un client mail aussi révolutionnaire que peut l’être GMail pour le webmail, il inclut un lecteur RSS (mais pas Atom) assez bien fichu, puisque reprenant trait pour trait l’interface du client mail.Comme tous les autres lecteurs, il reprend le paradigme d’une lecture blog par blog, alors justement que j’ai lu un article hier expliquant que ce paradigme est douteux, surtout lorsque le nombre de blogs feedés atteint ou dépasse 200.

Objets sensibles

Sur son blog, Manu nous parle de Sensitive Objects et des possibilités d’amélioration de l’interface homme/objet mais oublie un léger détail :

L’obligation d’avoir un ordinateur pour piloter le tout (analyse des signaux du capteur, gestion des actions induites) ne pose pas du problème : à court terme, il restera indispensable (mais l’environnement dans lequel cette technologie sera mise en oeuvre au départ est probablement déjà doté d’ordinateurs), mais à plus ou moins long terme, on pourra intégrer des objets de la taille du capteur avec tout ce qu’il faut dedans (capteur, CPU, soft, Wifi, par exemple).

Oui, mais est-ce bien nécessaire ? Parce qu’il existe déjà des caméras IP, permettant donc à n’importe quel PC de se connecter dessus. Et rien n’empêche la création de capteurs munis d’une carte réseau minimaliste (après tout, ces caméras ne sont pas bien grosses) qui permettraient, par exemple via courants porteurs, de se connecter à un serveur habilement caché à la cave. D’un autre coté, utiliser le WiFi, c’est encore mieux, surtout quand on envisage comme moi un réaménagement en profondeur de son domicile 😉

IronGrid P6Spy

Anand s’extasie devant la qualité du proxy d’IronGrid : IronEye. Et c’est vrai que, de tous les proxies d’analyse JDBC que j’ai pu essayer, c’est de loin le meilleur. Le seul autre qui tienne à peu près la route, c’est Proxool, mais il est nettement moins convivial et ne correspond pas au même objectif. En fait, IronEye est l’un des compléments les plus indispensables, lors de l’optimisation d’une application Java/SQL, à un profiler Java pur. En effet, IronEye va permettre de savoir combien de fois chaque requête est exécutée. Et, pour chacune des requêtes, quel est le temps minimal/moyen/maximal d’exécution. Bref, un outil totalement indispensable, surtout vu sa facilité de mise en oeuvre.

Doit-on supporter les défaillances des autres ?

  Dans tout projet web/J2EE se pose à un moment la question complexe des bugs de navigateurs.

Qu’il s’agisse de IE, de Firefox, d’Opera ou d’autres. Et, à chaque fois que ça arrive, c’est la responsabilité du développeur de corriger les bugs.

J’ai toujours trouvé que c’était la pire des idées.

En effet, cela requiert un effort important de l’équipe de développement pour identifier le bug du navigateur, pour implémenter un contournement (qu’il soit déja connu ou non) et pour le tester sur le navigateur problématique (la partie la plus délicate étant parfois de trouver une machine disposant de ce navigateur (pensons par exemple à IE 5.5)). Pourquoi ne pas plutôt penser au mouvement de standardisation du web ? De nos jours, les webmasters tendent à promouvoir de nombreux standards W3C : XHTML, CSS, l’accessibilité, les RIA, … qui sont tous utilisés dans les projets web modernes.

Je pense qu’un grand pas en avant pourrait être fait si les développeurs J2EE étaient plus conscients de ça. En effet, une partie non négligeable du web est constituée maintenant de sites J2EE. Et, malheureusement, je trouve rarement des gens conscients, que ce soit du côté du client ou de celui des développeurs, des conséquences d’un tel mouvement. Le principal avantage pour le développeur de la standardisation pourrait être énoncé simplement : « Votre navigateur est pourri et je ne le corrigerai pas ! ». C’est difficile à entendre. Mais c’est la triste réalité. Tous les chefs de projets devraient vraiment penser à ça, s’ils ne souhaitent pas que leur projet s’englue dans les « incompatibilités de navigateurs ».

BloNomic draft 1

Allez, voici ma première tentative de règles pour BloNomic. Qui, du fait des limitations inhérentes au media (le blog) sera un nomic impérial.

  1. Chaque joueur doit à tout instant respecter l’esprit et la règle de BloNomic.
  2. Toute personne envoyant un commentaire (ou un trackback visible depuis ce site) pour une entrée du blonomic est un joueur du Blonomic.
  3. Chaque nouveau joueur a comme score initial zéro point.
  4. Les entrées du BloNomic sont tous les articles de la catégorie {BloNomic} de ce blog, et de tout autre lui étant lié (par trackback ou autre mécanisme bijectif).
  5. Cette partie de Nomic progresse par l’adoption ou la non adoption de propositions d’amendement, de suppression, d’ajout, de regroupement ou d’autres opérations sur les règles en vigueur.
  6. Une proposition est un article de la catégorie {BloNomic} décrivant une modification des règles du BloNomic, et dont le titre contient [Proposition].
  7. Une proposition de ou sur une règle ne peut pas être plus longue que 50 mots, quelquesoit la langue de la proposition.
  8. L’administrateur est {Nicolas Delsaux}.
  9. Pour qu’une proposition soit soumise au vote, elle doit être envoyée à l’administrateur de ce site qui la publiera.
  10. Si l’administrateur refuse de soumettre la proposition au vote, il doit expliquer pourquoi.
  11. Un vote à propos d’une proposition est un commentaire (ou un trackback visible depuis ce site) pour cet article contenant soit « POUR », soit « CONTRE ».
  12. Si un même joueur vote plusieurs fois, seul son dernier vote est compté.
  13. Une proposition est soumise au vote pour une durée définie par l’administrateur.
  14. Une proposition est acceptée si plus de la moitié des votants a voté « POUR ».
  15. Si une proposition est acceptée, l’administrateur doit reposter la liste des règles modifiée.
  16. Lorsque le vote est terminé, l’administrateur jette un dé à six faces et ajoute le résultat au score du joueur.
  17. Au moins une fois par mois, les scores des joueurs doivent être publiés.
  18. Le gagnant est le premier joueur à totaliser 100 points.

Un nomic sur table

Plutét que de réfléchir dans le vide, JVGruat nous propose sur fr.rec.jeux.nomic un jeu de règles pour un nomic sur table, que je pense pouvoir adapter facilement. Donc allons-y pour la version initiale :

  1. Cette partie de Nomic progresse par l’adoption ou la non adoption de propositions d’amendement, de suppression, d’ajout, de regroupement ou d’autres opérations sur les règles en vigueur.
  2. Le texte d’une proposition de ou sur une règle ne peut excéder 50 mots. Toute proposition doit être formulée par écrit.
  3. Les propositions sont adoptées si une majorité des deux-tiers des votes émis leur a été favorable.
  4. Les joueurs jouent à tour de règle et dans le sens des aiguilles d’une montre, jouant chacun un tour complet. Il n’est pas possible de passer ou de sauter son tour et toutes les phases du tour de jeu doivent être jouées. Tous les joueurs commencent avec zéro point.
  5. Le tour de jeu est composé de deux parties et dans cet ordre : (1) Proposer un changement de règle et soumettre ce changement au vote (2) Lancer un dé une fois et ajouter le nombre de points obtenus à son score.
  6. Le changement d’une règle prend effet à la fin du vote qui l’a entériné.
  7. Chaque joueur a une voix et une seule.
  8. Le vainqueur est le premier joueur qui totalise 100 points positifs.
  9. Si les joueurs sont en désaccord sur le caractère légal d’un coup ou sur l’interprétation ou l’application d’une règle, le joueur précédent celui dont c’est le tour de jeu sert de Juge et tranche. Aux fins de cette règle, n’importe quel joueur peut provoquer un différend en insistant. Cette procédure s’appelle l’invocation du Juge.
  10. La décision du Juge ne peut être contestée que par un vote unanime des autres joueurs, vote qui aura lieu avant le début du tour de jeu suivant. Si la décision d’un Juge est contestée, le joueur précédent le Juge dans le jeu devient le nouveau Juge, et ainsi de suite, à la seule exception qu’un joueur ne peut être Juge pendant sont propre tour de jeu ou pendant le tour de jeu d’un membre de son équipe.
  11. Si un changement de règles rend impossible la poursuite du jeu, ou si un coup ne peut être irrévocablement considéré comme illicite, ou si le Juge décide sans que sa décision ne soit contestée qu’un coup est à la fois permis et interdit, le joueur mis ainsi dans l’impossibilité de terminer son tour gagne la partie. Cette règle a priorité sur toute autre règle déterminant le vainqueur.

Et voici maintenant mes commentaires numérotés à l’identique

  1. Toujours rappeler le but du nomic, c’est bien. Mais où est le respect des règles ?
  2. Ca, j’adore ! ça me rappelle follement {Conanomic} et sa fameuse règle Une coutume ne peut contenir qu’une seule phrase.. Bien sûr, la phrase Toute proposition doit être formulée par écrit. est sans objet pour un blog, forcément écrit.
  3. La majorité des deux-tiers, ça fait beaucoup. Je lui préfère une majorité plus typique de la moitié.
  4. Ca aussi, c’est une règle pour le tour de table. Mais ça pose intelligemment la question de l’ordre des propositions par le web.
  5. Tiens, c’est marrant, ces règles décorèlent l’obtention de points du résultat du vote. Très intéressant, comme mécanisme.
  6. Evidement, pas de rétroactivité
  7. J’aime bien cette règle, parce qu’elle ouvre facilement la porte à des mécanismes plus marrants (comme par exemple la corrélation au nombre de points) par une « simple » modification.
  8. Ah, tiens, un score de victoire ? Soit, c’est une partie sur table, après tout (lire : ça doit aller vite et tourner sans problème).
  9. Mouais, un Juge. Je suis toujours mitigé sur l’intérêt de la décision humaine. Pour les litiges, j’aurais tendance à tirer ça au sort, ne faisant que très modérément (surtout lorsqu’on joue de visu) confiance au jugement humain. Au fait, cette règle fait 61 mots. Elle est donc incohérente avec la règle 2, comme le sont toutes celles qui suivent.
  10. Elle est bien celle-là, car elle ouvre des possibilités intéressantes (et pas seulement parce que la notion d’équipe est introduite).
  11. Et enfin, la règle que j’appelerai de parfaite indécidabilité. Indispensable, mais rarement présente. Par exemple, Conanomic s’en passe.

Origami conceptuel

Mon pote Charles Lehalle m’a envoyé le lien suivant : http://origamiboulder.com/.Donc, moi aussi, je me mets à l’origami conceptuel.Mes instructions sont simples. Prenez une feuille de papier (de taille et de grammage quelconque).Pensez à l’origami de votre choix.Et voilà ! Vous avez sous vos yeux l’esprit de votre origami. Et, peut-être, si vous êtes patient, se réalisera-t-il.

Futures or closures ?

 Brian nous explique comment utiliser les « futures » en Java standard (c’est-à-dire avant Java 5, qui dispose du package de concurrence). Mais n’est-il pas bizarre de voir comme il est plus dur de le coder en Java qu’en … disons … Javascript (The World’s Most Misunderstood Programming Language (cliquez sur « Javascript », puis sur « The World’s Most Misunderstood Programming Language »))