Pour trouver de nouvelles musiques

Ou plus exactement, pour explorer des groupes « proches » de ceux que vous appréciez, vous pouvez demander à musicplasma. Si il a très bien marché pour mes groupes de hard-rock préférés (Manowar, Iron Maiden, Nightwish), un artiste complètement inclassable comme Ben Harper le met aux fraises. Mais c’est assez normal, de la part d’un héritier spirituel de Bob Marley, Jimi Hendrix et Marvin Gaye (oui, on peut hériter de ces trois-là sans s’emmêler les pinceaux).

Le javascrip

On dit souvent que le Javascript est un langage très limité, comme ici :

In general, pushing the UI to Javascript makes it hard to develop and debug. There are limited tools, the language is too lenient (no objects, weak typing), and testing involves cycling through webpages over and over again.

Ca m’énerve vraiment. Le Javascript a des objets (en guise de preuve, que faites vous avec votre document.write, node.childNodes, etc, …), et le typage faible n’a jamais été un manque (les langages interprétés modernes comme le Perl, le Python ou Groovy l’ont assez montré). A mon avis, javascript est vraiment mal compris. C’est un langage incroyablement puissant et rapide. Oui, rapide. Ce qui est lent en Javascript n’est pas le calcul, mais l’intégration au navigateur. Ce qui peut être facile à comprendre : imaginez que vous deviez redessiner une page entière quand vous insérez un simple DIV. Ca doit bien être lent. En guise de pense-bête, voici quelques spécificités du Javascript :

  • Les Closures comme dans ce puissant exemple, qui génère à la volée un tri sur une colonne d’une table :

https://gist.github.com/265975

C’est en javascript une manière facile de générer un tri multi critères.

Et, quand on essaye de banir le Javascript, il ne faut pas oublier que des sociétés comme Google l’utilisent intensivement (par exemple, GMail).

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 ».