Carnet Web de Sébastien Cabot

J’ai déjà fait du code JavaScript et découvert assez rapidement qu’il était presque qu’impossible qu’il s’exécute sans erreur sur tous les navigateurs Web. Ici «tous les navigateurs Web» se limite aux trois principaux pour chacune des architectures les plus utilisée, soit Internet Explorer (IE) pour MS-Windows, Safari pour Mac OS/X et Firefox pour Linux. C’est alors que j’ai fait la découverte du Framework JavaScript «Prototype».

Prototype est gratuit et simplifie beaucoup la vie pour la portabilité. De plus, son utilisation nos protège contre des erreurs de programmation JavaScript courantes. Bien que je l’ai rapidement adopté et que je ne regrette rien, j’ai récemment découvert qu’il y a d’autres alternatives intéressantes.

Prototype : Bien écrit, bien supporté, grande communauté d’utilisateurs. Documentation succinte, très peu d’exemples. Pour les effets visuels avec Prototype, le choix qui s’impose est Scriptaculous.

mootools : Il est très léger. (mootools library pour les effets). La plus petite lib et la plus rapide. (extJS pour les effets)

YUI (Yahoo UI) Il est lourd, c’est incroyable, mais a un nombre considérable de fonctionnalités. (bloated, overly complicated, slow).

GWT (Google Web Toolkit): Concept très attrayant. Développement en Java, puis diffusion en HTML et JavaScript par conversion du code.

JQuery: Bonne documentation. Il racourci la syntaxe au maximum. Moins de code à écrire, plus productif. Léger, architecture avec greffons le garde léger et flexible pour l’ajout de nouvelles fonctions. Fully supports CSS1, CSS2, CSS3, and basic XPath. Tons of plugins. Chainable.

dojo: Big bloat and slow, but shine with vector graphics with dojox.gfx.

Backbase : Full toolkit. Big, but nice GUI.

Les besoins

1. Je veux afficher le sous-graphe (de 5 à 30 sommets) d’un immense graphe de plus de 30,000 sommets. Puis, je une interface pour naviguer dans le graphe en passant, d’un sous-graphe à l’autre.
2. Je veux expérimenter des idées de GUI, donc des contrôles non standard, et partager le résultat et mes conclusions en ligne sur le Web.

Constat pour les images vectorielles statiques

Pour ces besoins, il me faut un outil qui me permet de mettre en ligne du contenu vectoriel interactif. Présentement la solution qui s’impose est Adobe Flash. Cependnat, puisque j’utilise Linux, je n’ai pas accès à l’IDE d’Adobe car ce dernier n’est disponible que pour Mac et MS-Windows. Alors, j’ai commencé à regarder les alternatives.

La technologie SVG est très prometteuse. Déjà, c’est un format largement accepté pour échanger des images vectorielles. Lorsqu’il est temps de placer ces images en ligne, FireFox à un support minimum pour le rendu SVG, il est donc préférable, pour l’instant, de convertir l’image en SWF. Pour l’impression, il est préférable de convertir l’image en PDF. Ce scénario est une solution «freeware» intéressante pour des images vectorielles statiques.

Constat pour le contenu vectoriel animé avec interaction

Maintenant, pour gérer des interactions avec l’utilisateur les solutions sont moins évidentes. Dans l’état actuel des choses, il n’y a pas de lecteur SVG largement répandu qui implante de façon fiable les interactions. De plus, il y a encore moins d’environnement intégré de développement pour produire des SVG interactifs. Bref, tout doit être codé à la main.

Une solution plus fiable consiste à produire des SWF à la main par programmation en utilisant des libraires. L’effort est grand et les résultats laissent à désirer. Néanmoins, voici quelques liens utiles pour cette approche.

Open Source Flash et deux sous liens notoires swftools et MTASC

Solution pour l’avenir

Je ne sais pas si cette solution est et sera intéressante, elle semble vouloir tout inclure dans un seul et unique langage de programmation Web. C’est très ambitieux, mais le projet est en vie et évolue. Je vais garder un œil là dessus.

haXe

Pour l’instant, j’ai opté pour des blogues multiples afin de découvrir lequel se développera le plus. Cette approche a l’avantage, de me permettre d’utiliser des noms de domaine différents dans le futur pour les rendre plus accessibles. Par contre, je dois me brancher et me débrancher à chaque fois pour faire la gestion de chacun de leur contenu. Pire, si j’adapte le code de WordPress pour mes besoins dans un, je dois faire la modification dans autant de blogues, soit 7 pour le moment, ce qui est très lourd.

J’envisage d’utiliser un seul blogue WordPress, qui sera divisé avec le mécanisme des catégories. Mon information sera centralisée, cependant, si je décide un jour d’utiliser des noms de domaine, je vais devoir faire quelques petits tours de passe-passe. De plus, je vais devoir modifier le code de présentation de WordPress, pour accommoder mes points d’entrées multiples. Ceci à l’inconvénient de rendre la mise à jour beaucoup plus laborieuse, puisqu’il faudra se souvenir de toutes les modifications et les réappliquer.

Je ne sais pas encore si je vais migrer mes blogues multiples, dans un seul point centralisé. Je suis en réflexion.

J’ai décidé d’utiliser mimeTeX comme stratégie pour insérer une expression mathématique dans un article de WordPress. C’est la solution la plus simple. Il s’agit d’un simple programme CGI qui prend en entrée une suite de commande TeX et produit en sortie une image GIF pour le rendu. Pour l’installation, j’ai seulement eu à le compiler et placer le résultat dans /cgi-bin de mon /public_html. Je dois préciser que je recherchais une solution où je suis indépendant, c’est-à-dire que je n’ai pas à utiliser un autre site Web pour effectuer le rendu des équations mathématiques.

L’avantage de cette approche est sa simplicité, mais elle a ses inconvénients. Premièrement, la production de l’image se fait à chaque appel de la page. Donc peu d’espace disque est utilisé pour les images, mais une exécution est requise à chaque chargement de la page. Deuxième point négatif, la qualité du rendu est faible.

Voici un exemple d’utilisation.

Puisque je ne sais pas comment compiler TeX sur le serveur hôte, je n’ai pas accès aux autres solutions qui utilisent TeX directement. Par exemple, mathTeX produit une image de meilleure qualité, mais il faut avoir LaTeX installé sur le système. D’autre part, il y a le gadget Google «Equation editor» qui peut générer un rendu très rapidement. Voici le lien http://www.sitmo.com/latex pour l’essayer.

Pour ce qui est de mathTeX et mimeTeX c’est disponible sur http://www.forkosh.com.

Il est possible de s’éviter d’écrire le mot de passe à chaque connexion au serveur avec ssh et scp. Pour se faire, il faut générer une paire de clefs privée/publique que sera placé sur le client et le serveur.

Sur le client:

1. Créer le répertoire ~/.ssh, s’il n’existe pas (mkdir ~/.ssh).
2. Assigner les droits uniquement à l’utilisateur (chmod 700 ~/.ssh).
3. Générer une paire de clefs (ssh-keygen -t dsa, faire [entrée] à toutes les questions).

La clef privée est dans «~/.ssh/id_dsa» et la publique dans «~/.ssh/id_dsa.pub». Avant de poursuivre, copier id_dsa.pub sur le serveur.

Sur le serveur :

1. Créer le répertoire ~/.ssh, s’il n’existe pas (mkdir ~/.ssh).
2. Assigner les droits uniquement à l’utilisateur (chmod 700 ~/.ssh).
3. Placer la clef publique dans le fichier authorized_keys (cat id_dsa.pub >> ~/.ssh/authorized_keys).
4. Assigner les droits uniquement à l’utilisateur (chmod 700 ~/.ssh/authorized_key).

Voilà, la connexion avec ssh et scp ne devrait plus demander le mot de passe. Si ce n’est pas le cas, on peut vérifier le déroulement des opérations d’authentification avec «ssh -v» pour tenter d’isoler le problème.

Tout d’abord, j’ai récupéré la plus récente version de VIM avec CVS.

cvs -z3 -d:pserver:anonymous@vim.cvs.sf.net:/cvsroot/vim checkout vim7

Ensuite, pour avant de lancer la compilation avec «make», j’ai utilisé la commande «configure» suivante:

./configure –prefix=$HOME/local –disable-gpm –disable-xsmp –enable-multibyte –enable-gui=no –without-x

La destination pour l’installation est un répertoire nommé «local» dans mon répertoire personnel. J’ai désactivé toute les options utilisant la souris et celle faisant intervenir X. Le but est d’obtenir un programme VIM aussi petit que possible et indépendant de X Windows. À noter que j’ai explicitement spécifié le «multibyte», afin d’être certain que le support pour Unicode soit dans l’exécutable.

La dernière étape était une simple, «make» suivie d’un «make install».

J’ai du générer un fichier compilé de «terminfo» pour rxvt-unicode car ce dernier n’était pas présent sur le serveur dans /usr/share/terminfo/r. Premièrement, j’ai récupéré un fichier «rxvt-unicode.terminfo» non compilé. Ensuite, puisque je n’ai pas les droits pour modifier /usr/share/terminfo/r, j’ai créé un dossier ~/.terminfo/r. Enfin, j’ai exécuté la commande de compilation «tic rxvt-unicode.terminfo» qui a produit ~/.terminfo/r/rxvt-unicode. Puisque VIM a été compilé avec l’option ‘+terminfo’ les couleurs sont maintenant accessible avec cette modification.

Mes premiers pas avec WordPress français (version 2.3.2) ont été quelque peu ardues. En effet, j’ai eu à isoler un bogue pas évident du tout. Le fichier des traductions «fr_FR.mo» était effectivement lu, mais les traductions n’était pas disponibles. Résultat, tout le blogue restait en anglais. Finalement, la cause était le passage d’une machine de 32 bits à une de 64 bits. Un bogue dans le code empêchait l’extration des traductions du fichier «.mo». Afin de corriger le problème, il faut modifier la ligne 118 dans le fichier «wp-includes/gettext.php». On doit remplacer
if ($magic == ($MAGIC1 & 0xFFFFFFFF) || $magic == ($MAGIC3 & 0xFFFFFFFF)) { // to make sure it works for 64-bit platforms
par
if ($magic == $MAGIC1 || $magic == $MAGIC3) { // to make sure it works for 64-bit platforms

Et voilà, WordPress peut maintenant être en version française tout comme sur une plateforme 32 bits.

C’est le lancement de mon carnet web personnel. J’ai l’intention de le remplir en décrivant les problèmes et solutions de mes développements Web.