Ce n’est un secret pour personne, j’aime Java. C’est une technologie et un langage que j’ai appris très tôt dans ma formation (j’en faisais déjà en 2002 en fin de première année à l’N7) et à laquelle j’ai tout de suite adhéré : langage objet, gestion des exceptions, ramasse-miettes, outils de développement libres, API fournie etc. Mais surtout ce qui m’a séduit à l’époque, c’est le fait que Java est virtuellement partout : dans les environnements de travail, les navigateurs, les téléphones mobiles, les serveurs d’application, les cartes à puce, les lecteurs BluRay maintenant… En fait, en bon développeur fainéant, le principal point fort que je lui trouve, c’est qu’une fois qu’on connait Java, on n’a pas besoin d’apprendre autre chose pour développer sur toutes les plateformes évoquées (du moins, rien d’autre que les documentations des différentes bibliothèques/API).

Là où je prends un coup de vieux, c’est que c’est exactement ce que m’a sorti un jour un chef de projet chez nous à propos du développement “grands systèmes” : quand tu connais COBOL, tu sais tout faire sur AS400. Pas besoin d’apprendre quoi que ce soit de plus.

Là où je prends un gros coup de tatanne, c’est qu’on m’a demandé dernièrement de faire une étude/chiffrage pour une interface Web avec comparaison des technologies existantes à l’heure actuelle (et pas trop obscures, sinon j’aurais parlé de haXe bien entendu). En bon accro à la caféine, j’ai eu tout le mal du monde à séparer une approche par applets d’une approche basée sur Flex – jusqu’à ce que je m’aperçoive de trois choses :

• Les IHM Flex, ça a de la gueule tout de suite, le langage est très expressif ;
• Apprendre Flex, c’est à la portée d’à peu près n’importe qui sait se servir d’une souris et regarder des vidéos ;
• Java traine une image de mocheté, d’inefficacité et de lourdeur, imputable à son âge finalement respectable (pour une technologie Web).

Alors, Java relégué au rang de COBOL comme une technologie imbittable, engoncée dans des concepts très informaticiens, ou Flex nouveau VB pour les développeurs sans formation objet ? Je crois que je commence à vieux-conniser sévère…

[EDIT]

Je ne suis apparemment pas le seul à me poser ce genre de questions: je viens de tomber sur un article de la collection Java IBM developerWorks, Dead like COBOL, où les prédictions “malthusiennes” faites sur la plateforme ces dernières années sont en grande partie démontées. Maintenant, reste à savoir si ce n’est qu’une façon comme une autre de me rassurer

Hé oui, le Web mobile ce n’est pas pour demain, c’est maintenant ! Bon sauf qu’évidemment j’ai voulu essayer sur mon Renoir. Le résultat est intéressant: passé le score de 7% (soit mieux qu’IE7), le terminal affiche FAIL puis… reboote. Méchant. Et à tous les coups ça marche, c’est magique !

/me se fend d’un message au réseau des développeurs LG…

Je viens de changer de terminal, délaissant bientôt mon Motorola V360 pour un LG KC910 Renoir. Du coup, comme j’utilisais pas mal GMaps avec le V360, quelle ne fut pas ma (bonne) surprise de voir qu’il était préinstallé sur le Renoir ! Par contre, la seconde (mauvaise) surprise fut de voir qu’en mettant à jour l’application, je me retrouvais avec une version non tactile (et franchement moins pratique du coup).

Je suis finalement tombé sur un forum d’aide mobile où un lien était fourni vers une version plus ancienne. Ni une ni deux, j’ai tenté ma chance en remplaçant la version dans l’URL fourni et bingo !

Je posterai peut-être un peu plus tard pour faire mon test personnel du Renoir

[EDIT]

Alors le problème, c’est qu’apparemment on peut avoir le support de l’écran tactile OU du GPS embarqué, mais pas les deux à la fois ! La version classique me propose la fonctionnalité “ma position” mais la version tactile me dit que mon téléphone n’est pas compatible… Je continue à creuser

[There is a video that cannot be displayed in this feed. Visit the blog entry to see the video.]

(Et en plus ça me permet de tester le plugin d’inclusion vidéo)

And for the english reading public, the 3R rule of Microsoft Windows problem resolution : Reboot, Reinstall, Replace !

Publier un enregistrement SPF est chose aisée, du moment qu’on maitrise un tant soit peu la configuration d’un serveur de nom. Là où les choses se compliquent quelque peu, c’est dans la configuration des relais – par exemple, l’excellent Postfix sur Debian Etch. Il existe un certain nombre d’implémentations de SPF pour Postfix, certaines natives, d’autres faisant appel à des “daemons” externes (il existe au moins une implémentation en Python et une en Perl).

Je n’ai pas inventé la poudre, j’ai suivi les instructions sur Yoann’s BloG. J’y ajouterai les deux commentaires suivants:

• Après installation du paquet libmail-spf-query-perl, il faut récupérer le script à gzippé /usr/share/doc/libmail-spf-query-perl/examples/postfix-policyd-spf.gz
• Nul besoin d’invoquer /usr/bin/perl, le script contenant l’entête idoine pour le lancement automatique (et surtout, mettre 2 arguments sur la ligne de commande du ‘spawn’ a tendance à provoquer des retours d’erreurs dans les logs de postfix, semble-t-il)
• Surtout éviter au maximum d’avoir à utiliser CPAN avec une machine 64 bits ! Mail::SPF dépend de NetAddr::IP qui ne compile par en 64 bits pour des questions de petits indiens
• Il vaut mieux ne pas essayer d’utiliser le script le plus récent de Openspf.org, qui dépend d’une version ‘trop récente’ de NetAddr::IP (autant s’en tenir au script packagé, qui a l’insigne avantage de fonctionner avec les bibliothèques Perl présentes dans Etch)

Ouf ! Après une soirée d’arrachage de cheveux, les mails passent à la moulinette SPF avant d’arriver dans nos boites. Prochaine étape: implémenter DKIM pour signer le courrier sortant

D’ailleurs ça fait bizarre de se relire 2 ou 3 ans après…

Nouveau moteur, nouvelle apparence ; l’ancien blog NFN devrait toujours être sur pieds (quoique…), en attendant que ses articles soient importés comme il faut (et sans problème de codage si possible).

Comme d’habitude, les nouvelles les plus fraiches sont sur le blog-inou Asteromith.