willoblog

Comme les articles d'aujourd'hui vous en ont surement persuadés, vous aurez compris que j'ai passé un premier mois de vacances à réaliser un grande partie des projets qui me tournaient dans la tête et que je n'ai pas eu le temps de creuser d'avantage cette année (parce qu'on ne l'imagine pas au début, mais une vie de prof débutant ne laisse pas beaucoup de temps pour le reste). La todo-list commençait à se faire longue et j'ai été bien content de pouvoir enfin m'y atteler sans plus penser au boulot.

Mais ceux qui me connaissent vous diront que je passe, on va dire « pour raison familiale », beaucoup de temps loin de chez moi. Et personnellement, j'ai commencé à m'intéresser à l'informatique à partir du moment où j'ai eu internet. J'associe mon plaisir de ce loisir à ma navigation sur le net, à lire de la doc pour être sûr de ce que je fais, à perdre mon temps sur des détails techniques qui permettent la compréhension d'effets de bord insoupçonnés (ça c'est mon côté chercheur :) ). À tel point que je me demande comment on faisait avant. Et que cela me manque quand ce n'est plus possible.

Être loin de chez soi n'est pas un problème. ssh, rsync (et mon script de sauvegarde) et sshfs font que l'on peut maintenant travailler sur un ordi distant comme si l'on était dessus (avoir une console, c'est bien, mais avoir ses fichiers dans le navigateur de fichiers et pouvoir les éditer avec l'éditeur classique en double-cliquant dessus sans temps de latence, c'est vraiment génial).

Mais pour pouvoir développer, en particulier des sites web, dans le train, c'est une autre affaire. Ma solution est d'avoir un serveur sur mon portable. Et finalement c'est très simple. J'ai choisi, pour changer de mon apache configuré aux petits oignons et que je commence à bien comprendre, un serveur censé être plus light : lighttpd. Finalement, sans aucune configuration, tout fonctionne du premier coup. Facile, il suffisait de taper :

sudo aptitude install lighttpd php5-cgi mysql-client mysql-server php5-mysql

On peut y ajouter le gestionnaire de bases mysql développé par Sun, mysql-query-browser, mais je l'essaie depuis environ un mois et je n'en suis pas convaincu. Il ne vaut pas PhpMyAdmin, dont je me passe néanmoins en utilisant à la roots le client mysql en console. Il n'y a plus qu'à incanter des lignes magiques dans des fichiers et peupler /var/www/.

À partir de là, au moins on peut faire du php/mysql et vérifier si cela fonctionne bien. Mais il manque les docs. Et quand on fait du php, on sait tout l'intérêt de la doc de php.net, complète et bien faite. Alors du coup, maintenant je ne sors plus jamais sans mes docs :-)

• documentation php à télécharger et à dézipper
• documentation JQuery à télécharger et à dézipper, qui est assez bluffante
• documentation mysql à télécharger et à dézipper (prendre le « HTML page/chapter »)

Bon, troisième post de la journée sur le sujet, après les deux premiers. Petits trucs et astuces pour pouvoir afficher des scripts bash comme cela est réalisé sur mon site.

Pour le transcript, deux problèmes

Balises malgré elles

SyntaxHighlighter transforme tous les chevrons « < » et « > » en entités html correspondantes, respectivement « &lt; » (less than) et « &gt; » (greater than). Ce ne serait pas grave s'il ne le faisait pas seulement pour presque tous les chevrons... Or il cherche à détecter automatiquement les balises (ce qui n'est pas très malin dans du code bash d'ailleurs, ce qui fait que mon adresse mail par exemple était comprise comme une balise, dégradant quelque peu la suite de l'affichage. Total : il faut le faire pour lui.
Au départ, j'avais choisi d'utiliser readline en php, à savoir

<pre class="brush: bash">
<?PHP  @readline('compil'); ?>
</pre>

Mais transformer les chevrons à l'avance n'est pas beaucoup plus compliqué :

<pre class="brush: bash">
<?PHP  echo str_replace('<','&lt;',str_replace('>','&gt;',file_get_contents('compil'))); ?>
</pre>

Vous aurez remarqué que du coup, dès que le fichier est modifié, c'est le code de la dernière version qui s'affiche. Zéro maintenance (le fichier compil est un lien symbolique vers /usr/local/bin/compil sur mon serveur).

Décidément, ces chevrons...

Et c'est à ce moment que l'on relit un peu ce qui s'affiche à l'écran, et qu'on se rend compte que plein de chevrons (mais pas tous) sont restés à l'état d'entités html. Alors qu'en enlevant l'influence de SyntaxHighlighter, on obtient bien le résultat attendu. Il m'aura fallu quelques minutes pour me souvenir que lt et gt, sont des mots-clés en bash, justement pour des tests numériques plus grand/plus petit (ouais, tout est lié). Un grand dilemme se pose alors. Soit on laisse comme ça, et le code affiché est faux. Soit on s'arrange pour ne jamais avoir de chevrons (ce qui est impossible quand on a besoin de redirections). Soit on commente les mots-clés gt et lt dans le fichier de définition shBrushBash.js, et tant pis pour leurs rares apparences en tant que tests, où ils ne seront pas colorés comme il faut. J'ai choisi cette dernière solution.

Pour l'aide

Ah, là ça se corse. Au départ j'avais recopié telle quelle la réponse de compil -h. Je me suis dit alors « mais si t'as une coquille dans l'aide ou que tu la modifies, il faudra revenir ici... au secours ». Alors j'ai trouvé un moyen. Après plusieurs tâtonnements et hésitations sur la meilleure fonction php entre exec, system et passthru, j'ai opté pour

<pre class="aide">
$ compil -h
 
<?PHP 
exec('[ ! -e compil.help -o compil -nt compil.help ] && compil -h | tr -d "\033" | sed -e "s/\[1m/<b>/g" -e "s/\[0m/<\/b>/g" > compil.help');
@readfile('compil.help'); ?>
</pre>

Explication : la dernière commande lit et affiche un fichier compil.help. On va donc y mettre l'aide. Problème, j'utilise un formatage à base de caractères bizarres qui permettent de mettre en gras du texte en console. On prend donc le résultat de compil -h, on en vire donc le caractère bizarre (grâce à la commande tr -d), puis on identifie le début et la fin des mises en gras, que l'on remplace de façon moche mais fonctionnelle par des balises de formatage html.
Le début est un test, qui permet d'exécuter la commande seulement si compil.help n'existe pas ou est plus ancien que compil. Cela semble fonctionner à peu près correctement.

J'ai découvert il y a quelques semaines un (gros) bout de code génial. Bon, ce n'est pas une grande découverte, il est déjà très utilisé, mais je n'avais jamais vraiment eu besoin de ce genre de trucs jusqu'à maintenant...

Comme le dit son site, il s'agit d'un code de surlignage syntaxique, ou comment rendre des bouts de codes déjà lisibles encore plus lisibles.

L'utiliser n'est pas très compliqué, puisqu'il suffit de télécharger le dernier .zip, de le dézipper et de regarder ce qu'on trouve. Un répertoire scripts contenant en particulier shCore.js qui est le cœur de la machinerie, ainsi que plein de shBrush*.js, qui contiennent les définitions des syntaxes pour différents langages. Personnellement, je n'ai pas besoin de tout, donc je n'ai choisi de garder que ce qui m'intéresse : Bash, Php, Plain que j'utiliserai souvent, Css, JScript et Sql un peu moins, et puis aussi au cas où Diff, Perl, Python, Xml. Un dossier styles contient lui les fichiers de mise en page css, parmis lesquels shCore.css est obligatoire et ensuite shThemeDefault.css correspond au seul thème écrit en noir sur blanc (les autres font du blanc sur noir, je déteste ça). Sans oublier les trois icônes qui seront affichées dans la toolbar et l'icône de retour à la ligne.

Donc on prend tous ces fichiers, on met tout ça dans un répertoire, appelé par exemple syntaxhighlighter, à la racine de notre formidable site web qu'on adore et dont on prend soin. Il ne reste plus qu'à modifier les pages web en ayant besoin. Il faut rajouter dans l'entête html :

<script type="text/javascript" src="/syntaxhighlighter/shCore.js"></script>
  <link type="text/css" rel="stylesheet" href="/syntaxhighlighter/shCore.css"/>
  <link type="text/css" rel="stylesheet" href="/syntaxhighlighter/shThemeDefault.css"/>
  <script type="text/javascript" src="/syntaxhighlighter/shBrushPlain.js"></script>
  <script type="text/javascript" src="/syntaxhighlighter/shBrushBash.js"></script>
  <script type="text/javascript">
    SyntaxHighlighter.all();
  </script>

Ensuite, tous les paragraphes de type <pre> seront analysés, pour peu qu'on dise à quel langage ils correspondent, en ajustant la classe :

<pre class="brush: bash">

par exemple. J'ajoute aussi, pour éviter la numérotation des lignes quand il s'agit d'une simple ligne de commande :

<pre class="brush: plain; gutter: false">

Le résultat a été utilisé dans de nouvelles pages sur mon site, dédiées à des scripts dont je me sers assez souvent et que j'ai écrits pour cela. C'est là qu'on se dit que la coloration syntaxique rend le code plus lisible.

Pour info, la coloration effectuée dans les articles du blog n'est absolument pas due à SyntaxHighlighter mais à un plugin pour Dotclear nommé SyntaxeHl.

Ça faisait très longtemps qu'on attendait ça. Pour ainsi dire, Neuf fait mieux que Free depuis assez longtemps pour un service donné ultra pratique.

À de très nombreux endroits, il est très souvent possible de voir un réseau wifi appelé « Neuf Wifi ». Il s'agit d'un réseau mis en place par Neuf-SFR qui envoie sur un portail captif où un code d'accès donné à chaque client Neuf peut être entré. Il permet de surfer tranquillement hors de chez soi. C'est assez génial et ça dépanne de façon très efficace.

Free a aujourd'hui, avec une nouvelle mise à jour des firmwares des Freebox (V5 uniquement), lancé « son » Neuf-wifi, logiquement appelé « Freewifi ». Beaucoup disent « Ah enfin », d'autres « Free copie à défaut d'innover réellement ». Certes, dans l'usage, on dirait l'offre de Neuf. Il y a cependant deux aspects techniques absolument nouveaux et qui pourraient être géniaux :

• L'adresse IP du freenaute hors de chez lui reste la même que chez lui. Autrement dit, on garde la possibilité que personne ne puisse réellement savoir où on est. On apparait réellement, même techniquement, comme si on était réellement chez nous. Et ça change beaucoup de choses : moi en tout cas ça me donne moins de peurs de surfer ou d'envoyer des mails depuis ailleurs. Accessoirement, cela permet de dire qu'on reste responsable de ses mouvements, ce qui est toujours le bien venu en ces temps d'inquisition technologique.
• Tous les protocoles sont accessibles. Et ça c'est une énorme différence avec l'offre de Neuf. Ceci est possible par une sécurisation plus importante des connexions et par la responsabilisation qu'entraîne l'IP fixée. Le wifi Neuf ne permet quasiment que de naviguer (entendre : protocole http). Tous les protocoles, ça veut dire pouvoir utiliser dehors MSN/ICQ comme à la maison, permettre d'utiliser des logiciels de mail (et non seulement les webmails), et pour tous les geeks que nous sommes pouvoir faire du ssh. Bref, être vraiment dehors comme chez soi.

Mieux, beaucoup mieux : ça devrait permettre d'établir des communications SIP hors de chez soi. En clair : téléphoner, avec les prix d'opérateurs qu'on aura choisi (certains sont vraiment pas chers), via le net, partout où une freebox est pas trop lointaine. Si ça fonctionne, je connais déjà mon cadeau de Noël : un des modèles de téléphones qui commute sur le wifi quand il le peut, et téléphone par là. Et adieu mon forfait mobile Orange, parce que ça fait déjà trop longtemps qu'on subit leur politique tarifaire indécente.

L'usage de ces appareils mobiles va exploser chez les Freenautes en zone dégroupée (3 millions d'abonnés selon Free). Et je suis sûr que dans 1 an (le temps d'être sûr que ça fonctionne) le Neuf-wifi suit la voie. Encore une fois, seul Orange sera à la traîne, gardant certainement son actuelle option payante bridée.

Le seul problème que je vois : comment sera géré le problème du roaming. L'intérêt serait nettement plus important s'il était possible de rester plus ou moins connecté en changeant de point d'accès au réseau. Je ne pense pas que ce soit ce qui est prévu, ce qui signifie qu'à chaque déplacement, il faudrait entrer à nouveau le code d'identification. Cela pourrait devenir très gênant très vite. D'où l'intérêt de voir comment évolue l'offre et son usage dans les 6 mois qui viennent.

Suite du message précédent : ah, enfin un peu de temps à soi (bon en fait, je l'ai pas vraiment, tout ce temps, mais je le prends quand même...), j'ai acheté un nouveau nom de domaine rien qu'à moi (je ne pensais pas que ça ne coûtait que 1€ chez ovh), un certificat ssh propre rien qu'à moi pour un an (à 15$ chez RapidSSLOnline comme j'en avais déjà parlé).

Et du coup je m'amuse un peu avec Apache, à faire des vrais virtual hosts et à utiliser un peu l'URL Rewriting. Ça a l'air de fonctionner maintenant (désolé pour la gêne occasionnée). Entre temps le blog a déménagé sur une nouvelle adresse rien qu'à lui, à savoir http://blog.cyril-ravat.fr/. L'ancienne adresse fonctionne toujours, a priori jusqu'à ce que j'en ai marre, et tout est redirigé automatiquement ici.