publo.fr - blog - technique

De la géolocalisation dans Google Maps

Benjamin — Fri, 10 Jul 2009 23:30:00 +0200

Depuis hier, Google Maps propose une fonctionde géolocalisation à ses visiteurs connectés sur PC. Le service existait déjà pour les mobiles mais il a été étendu aux PC équipés de Firefox 3.5 ou de Google Chrome. Il est également compatible avec les navigateurs équipés de Google Gears.

Le blog de l'équipe de Google Maps donne plus de détails sur le service qui s'appuie sur le tout nouveau standard du W3C, l'API de Géolocalisation. Pour déterminer la position de l'internaute, le système de géolocalisation se base sur de la géolocalisation Wifi et de la géolocalisation IP.

Un lancement discret

Même si la blogosphère en parle beaucoup, ce service fait une apparition timide. Pour y recourir, il faut cliquer sur un petit bouton à l'apparence anodine qui a été ajouté à l'interface de Google Maps. Rien ne laisse d'ailleurs supposer que ce bouton sert à cela, à part le tooltip qui apparaître lorsqu'on passe la souris sur le bouton, et rien n'invite vraiment à l'essayer. Bref, il faut connaître pour l'utiliser.

Lorsqu'on clique sur ce petit bouton, c'est la machinerie de la W3C Geolocation API qui se met en marche. Sur Firefox, un bandeau de dialogue vous demande si vous souhaitez communiquer vos données de géolocalisation au site, en l'occurrence maps.google.fr.

Des résultats variables

Après une longue réflexion pour savoir si l'on va oui ou non permettre la géolocalisation, et si effectivement on l'accepte, on obtient normalement un recentrage de la carte sur la localisation probable, avec dans certains cas un disque bleu qui recouvre la zone où doit se trouver l'internaute.
Nous avons fait le test depuis deux PCs, l'un en région parisienne, l'autre en province dans le Sud-Est de la France. Dans le premier cas, la précision est impressionnante : la zone bleue fait 300m de diamètre et son centre est à moins de 50m de la localisation du PC. Dans le second cas, pas de zone bleue, une carte centrée sur le Sud-Est de la France mais qui laisse apparaître une zone de 500km par 500km environ : bref le système reste excessivement prudent quant à la localisation.

Géolocalisation IP et géolocalisation Wifi

La précision du résultat obtenu pour le PC situé en région parisienne laisse à penser que le calcul ne s'est pas appuyé uniquement sur de la géolocalisation IP. En effet, il est difficile de descendre en dessous du km pour la précision d'une géolocalisation IP sur une adresse IP résidentielle. Il y a donc de la géolocalisation Wifi derrière ce résultat.
Pour en avoir le coeur net, nous avons fait 2 tests de géolocalisation sur le PC. Pour ces 2 tests, le PC était connecté en Ethernet à notre box et le Wifi de la box était désactivé. Puis nous avons testé la géolocalisation d'abord avec la carte Wifi du PC désactivée, puis avec la carte Wifi activée.
Les résultats en image :

Avec la carte Wifi désactivée :

Le système s'est appuyé sur une géolocalisation IP et il propose la carte de toute la région parisienne. C'est une proposition excessivement prudente par rapport à ce que l'on peut obtenir à partir de l'adresse IP.

Avec la carte Wifi activée :

On voit que le Wifi doit bien servir à quelque chose... Notez que le PC n'étant pas connecté en Wifi à la box (dont le Wifi est désactivé), ce sont les box du voisinage qui ont permis de faire cette géolocalisation. En fait, le PC a écouté les boxes présentes dans le voisinage et a transmis ces informations (avec notre consentement) au système de géolocalisation qui, connaissant les boxes en question en a déduit la localisation probable du PC. Il est à noter que le résultat est variable dans le temps, probablement à cause des fluctuations de réception des signaux des boxes.

Conclusions

On peut tirer plusieurs conclusions de ces tests.

Google reste très prudent quant il s'agit de géolocalisation IP mais affiche une belle assurance lorsqu'il s'agit de géolocalisation Wifi
la région parisienne a - au moins en partie - été cartographiée en terme de Wifi. Peut-être un engin similaire à la Google car a-t-il sillonné la région en écoutant toutes les bornes Wifi qu'il rencontrait sur son chemin.
l'autorisation demandée avant la géolocalisation n'est pas superflue puisque dans le cas de la géolocalisation Wifi, il y a transmission d'informations depuis le PC. Par contre, lorsqu'il n'y a qu'une géolocalisation IP, cette autorisation perd son sens dans la mesure où le système a déjà tout en main pour faire une géolocalisation. Mais bien sûr, il peut faire semblant de ne pas être au courant ;)

Et vous, avez-vous testé cette nouvelle fonctionnalité ?

4 techniques pour optimiser le référencement d'un blog DotClear 2

Benjamin — Thu, 25 Jun 2009 23:30:00 +0200

Il ne suffit pas d'écrire des billets intéressants pour qu'ils soient lus. Encore faut-il que cela se sache. Et d'abord, encore faut-il que les moteurs de recherche le sachent !
Dans ce billet, nous décrivons quelques techniques simples permettant d'améliorer le référencement de billets créés sur le moteur de blog DotClear 2.

Soignez l'élément `<title>`

Par défaut, l'élément <title> est généré par DotClear et correspond au titre du billet. Or c'est un élément important pour les moteurs de recherche et il peut être intéressant de le modifier un peu. Si vous avez accès aux templates, vous pouvez modifier le format général de vos titres (ajouter le nom du site par exemple). Si vous n'y avez pas accès, vous pouvez également utiliser le plugin miniseo de DotClear : celui-ci vous permet de définir vous-même et individuellement l'élément <title> de chacun de vos billets.
Le titre de vos billets doit être clair, de préférence pas trop long et il vaut mieux que ce qui est important se trouve au début du titre. Ce sera d'une part plus lisible sur les pages de résultats des moteurs de recherche (un titre court accroche mieux) et cela évitera que le titre soit tronqué, que ce soit sur les pages de résultats ou sur les lecteurs RSS.

Ajoutez un élément `<meta>` de description

Ce point rejoint le précédent. Comme pour le title, la description (dans un élément <meta> du header) est importante car même s'il n'est pas certain qu'elle serve pour l'indexation par mots clés, c'est bien souvent cette description qui apparaît dans les résultats de la recherche. Lorsqu'elle n'est pas renseignée, le moteur de recherche affiche généralement le début de l'article. Or il est plus efficace de lui fournir un petit résumé bien tourné que de le laisser découper bêtement le début de votre article. Là encore, le plugin miniseo est bien utile.

Fournissez toujours un extrait

DotClear donne la possibilité de fournir un extrait qui sera affiché sur la page d'accueil, les archives, les catégories et autres pages "multi-billets" du blog en lieu et place de l'article complet. Le fait que ce soit seulement un extrait qui apparaisse sur ces pages est très important car il permet d'éviter le problème du "duplicate content" : en effet les moteurs de recherche pénalisent les sites qui font apparaître un contenu similaire sur plusieurs pages.

Remaniez les URLs

Par défaut, DotClear propose des URLs pas très jolies (avec un vilain index.php et des paramètres), avec une date et en utilisant le titre de l'article. Par exemple, pour le présent billet, l'URL par défaut serait :

http://blog.publo.fr/index.php?post/2009/06/25/5-techniques-pour-optimiser-le-referencement-d-un-blog-dotclear-2

Cela a plusieurs inconvénients :

l'URL est très longue et profonde (6 niveaux!), ce qui ne plaît pas forcément aux moteurs de recherches et qui n'est pas franchement sympathique lorsque vous transmettez cette URL par mail, dans un forum ou en commentaire dans un autre blog.
l'URL contient un paramètre : là encore, méfiance vis à vis des moteurs de recherche même si Google en accepte deux normalement.
la présence de la date dans l'URL risque de laisser penser à vos lecteurs potentiels que vos billets sont obsolètes même pour les billets que le temps n'use pas...
l'URL ne contient pas forcément les mots-clés qui caractérisent le billet (ce n'est pas le cas dans notre exemple), or mettre les bons mots-clés dans une URL a des effets positifs sur l'indexation de la page correspondante
les mots-clés, quand ils sont là, sont "dilués" et vers la fin de l'URL. On peut donc craindre qu'ils ne pèsent plus grand-chose dans l'indexation. Regardez dans l'exemple le nombre de mots inutiles ("index", "post", "pour", "2009", "d"...)

La question des URLs est un vaste débat et ceux que cela intéressent peuvent jeter un coup d'oeil au débat qui suit l'article "Quel modèle de réécriture d'URL faut-il utiliser pour son blog ?" sur monetiweb.

Pour résoudre tous ces problèmes, deux étapes :

Configurez le format des URLs de vos billets : c'est l'objet d'un précédent billet sur l'amélioration des URL DotClear
Spécifiez vous-même la partie spécifique de l'URL de chacun de vos billets

En reprenant notre exemple, l'URL obtenue est :

http://blog.publo.fr/post/optimiser-referencement-blog-dotclear

Pour terminer, il est utile de rappeler que ces 4 points ne sont que des techniques pour faire en sorte que lorsqu'un billet est pertinent par rapport à certains mots clés, ils soit vu comme tel par les moteurs de recherche. Cela n'améliorera pas sa popularité qui est la deuxième composante majeure du référencement et qui ne peut se construire que par la création de liens pertinents pointant vers ce billet.

Google éternue et tout le web s'enrhume : de l'intérêt du téléchargement paresseux des javascript

Benjamin — Thu, 14 May 2009 18:10:00 +0200

Le recours à des Javascript tiers sur un site internet peut introduire un couplage gênant, comme le montre la perturbation d'accès aux services de Google que subit actuellement le web. Voici quelques mesures pour s'en prémunir.

Vu d'ici, il semble qu'il y ait de gros soucis en ce moment pour atteindre les services de Google. Problème de réseau ou dysfonctionnement des serveurs, l'autopsie de l'incident dira ce qui s'est passé. Toujours est-il que ce type d'incident révèle le nombre impressionnant de sites qui utilisent Google et dont le fonctionnement normal est intimement couplé à celui des services du géant californien.

En effet, Google fournit à de très nombreux sites de la publicité à afficher (google ads et doubleclick), des mouchards pour faire des statistiques (google-analytics) ou encore des librairies Javascript (googleapis). Tout ceci sous forme de fichiers Javascript.
Lorsque le téléchargement de ces Javascripts est ralenti, cela peut avoir des conséquences importantes sur l'affichage des pages qui les utilisent. En effet, le téléchargement des éléments d'un document HTML (feuilles de style, javascripts, images) étant généralement séquentiel, si le browser bloque sur le téléchargement d'un javascript, ce sont tous les éléments suivants qui se retrouvent dans la file d'attente. Par ailleurs, chaque fois que le browser télécharge un élément, l'affichage est figé. Et donc, suivant l'emplacement du Javascript dans le document HTML, cela peut bloquer l'affichage de toute la page (pour un script situé très haut dans le document) ou bien ne pas le perturber mais laisser le browser en attente (pour script situé en fin de document comme généralement le script google-analytics).

Naturellement, qu'il s'agisse de scripts de Google ou de tout autre site (y compris les scripts de publo.fr !), le problème est le même. Comment s'en prémunir ? Comment affaiblir le couplage pour qu'un site ne soit pas perturbé par la lenteur du téléchargement de Javascripts tiers ?
Voici trois pistes:

Héberger les scripts soi-même

Cette solution consiste à héberger soi-même les Javascripts que l'on utilise. C'est bien pour tout un tas de raisons d'utiliser un réseau de distribution pour les Javascripts que l'on utilise, mais cela peut aboutir à la situation décrite précédemment.
En hébergeant les Javascript sur le même serveur que celui qui sert les documents qui les incluent, on est assuré de ne pas rencontrer cette difficulté.

Faire du téléchargement asynchrone

Les fichiers Javascript sont téléchargés de façon synchrone lorsqu'ils sont inclus dans le document au moyen de balises <javascript src="http://blog.publo.fr/post/2009/05/14/............."/> dans le document HTML.

Par contre, si l'on inclut ces scripts dynamiquement dans le DOM, ils sont téléchargés de manière asynchrone, donc parallélisable.
Pour ce faire, il faut ajouter un peu de Javascript sur la page de façon à générer dynamiquement un nouvel élément Javascript qui inclut le script tiers.

En code, cela donne

<javascript type="text/javascript">
        var script = document.createElement('script');
        script.setAttribute('type','text/javascript');
        script.setAttribute('src','.........................');
        document.getElementsByTagName('head')[0].appendChild(script);
</javascript>

En faisant cela, le téléchargement du script ne bloquera pas le téléchargement des autres éléments ni l'affichage de la page. Seul inconvénient : le browser reste en attente tant que le script n'est pas chargé.

Faire du téléchargement paresseux

Si l'on veut palier à l'inconvénient relevé pour le téléchargement asynchrone, il faut ruser en différant le chargement du script. Pour ce faire, on va comme précédemment générer dynamiquement l'élément javascript d'inclusion, mais un peu plus tard : lorsque la page sera chargée.

En code cela donne :

<javascript type="text/javascript">
function ajouteScript(){
        var script = document.createElement('script');
        script.setAttribute('type','text/javascript');
        script.setAttribute('src','.....................');
        document.getElementsByTagName('head')[0].appendChild(script);
}
if( window.addEventListener ) { 
        window.addEventListener('load',ajouteScript,false);
} else if( document.addEventListener ) { 
        document.addEventListener('load',ajouteScript,false);
} else if( window.attachEvent ) { 
        window.attachEvent('onload',ajouteScript);
}
</javascript>

dans ce code, on associe la création de l'élément Javascript à l'événement 'load' du document.

Bien sûr, ces mesures ne règlent pas tout. Elles ne permettent de traiter que le cas de Javascripts autonomes. Lorsque la page utilise plusieurs scripts liés, il est nettement plus compliqué de faire du téléchargement paresseux tout en respectant les dépendances, mais cela dépasse largement le cadre de cet article fait sur le vif !

Référencement vidéo sur Google

Benjamin — Wed, 29 Apr 2009 10:00:00 +0200

La recherche Web de Google fait apparaître depuis quelque temps des résultats de vidéo en plus des résultats "classiques". Ces résultats comprennent une petite image représentant la vidéo trouvée et se remarquent bien au milieu des autres résultats. De quoi bien perturber le "triangle d'or de Google" et donner un avantage certain à ce type de résultat face aux résultats classiques.

Le référencement de publo.fr était déjà intéressant (en première page de Google et Yahoo depuis quelques semaines pour la recherche "publicité locale") mais pour améliorer encore la visibilité, nous sommes partis en quête de référencement vidéo. Objectif : faire référencer par Google la vidéo de démonstration de notre service de publicité locale.

Héberger ou faire héberger ?

La solution de facilité consiste à déposer la vidéo sur YouTube. Seul problème : cela n'amène pas directement de trafic sur le site puisque la vidéo est sur YouTube, consultée sur YouTube et sans aucun lien vers le site...
Il faut donc plutôt héberger la vidéo sur le site et la faire référencer à cet endroit par Google.

Le robot va-t-il enfin trouver ma vidéo ?

Le référencement vidéo est un peu plus délicat que le référencement de pages webs. Pour les pages Web, il peut se faire spontanément ou bien on peut le favoriser en fournissant un sitemap (un plan de site en XML) à Google. Pour les vidéos, il semble qu'on ne puisse pas compter sur le référencement spontané, notamment lorsqu'on héberge soi-même la vidéo. Le sitemap s'impose. En effet, notre vidéo de démonstration est restée plus de deux mois sur notre site sans être jamais indexée, alors qu'elle se trouvait sur une page indexée.

Le sitemap vidéo

Google a défini un format spécifique pour le référencement de vidéos. Attention, quoique la structure globale soit la même que pour les pages Web (un sitemap n'est jamais qu'une liste d'URL...), on ne peut pas faire de sitemap mixte pages Web / vidéos. Il faut faire deux sitemaps séparés. Pour les sitemaps vidéo, il est vivement recommandé d'utiliser des sections CDATA dans les entités terminales, sans quoi on s'expose à des problèmes s'il y a des caractères accentués ou des '&'. Une fois le sitemap terminé et chargé sur le serveur HTTP, il reste à l'indiquer à Google dans les Outils pour Webmaster, comme un sitemap ordinaire.

Une indexation rapide

Dans notre cas, il n'a fallu que 24h pour que la vidéo soit parcourue par le robot puis indexée. Elle apparaissait alors en première page de Google pour la recherche "publicité locale démonstration" dans les résultats Web. Quand aux résultats vidéo, elle y apparaissait en première position pour la recherche "publicité locale". La concurrence y est moins rude que dans les résultats Web !

Un petit régime avant l'été ?

Benjamin — Sun, 26 Apr 2009 18:00:00 +0200

À l'occasion d'une petite campagne d'amélioration des performances de nos services sur laquelle nous reviendrons prochainement, nos gadgets météo et actualité viennent de suivre une cure amaigrissante.

Ces gadgets reposent chacun sur du Javascript généré dynamiquement par notre serveur. Le petit régime s'est fait en deux étapes

Obfuscation :

Les scripts ont été écrits (et sont maintenus) par un humain qui a une fâcheuse tendance à donner des noms explicites aux variables - des noms de plus d'une lettre - à aller à la ligne de temps en temps... C'est là qu'entrent en scène des outils d'obfuscation comme YUI Compressor de Yahoo. Leur objectif est double :

réduire la taille du code : toutes les variables sont renommées avec des noms d'une lettre de préférence, les retours chariot sont supprimés, etc.
rendre le code incompréhensible pour lutter contre le reverse-engineering et la copie

Dans notre cas, c'est le premier aspect qui nous intéressait. Seule difficulté : le Javascript est généré dynamiquement à partir de JSP et ce sont donc des templates de Javascript qu'il a fallu obfusquer. Cela a nécessité un travail un peu fastidieux pour rendre ces fichiers compréhensibles par YUI Compressor, puis retransformer en templates les résultats obtenus. Bref La transformation a permis de passer de 4,1Ko à 3,4Ko pour la météo et de 3.8Ko à 3,3Ko pour les actualités, soit une perte de poids entre 20 et 26%

Compression

Jusqu'à présent, les scripts étaient servis non compressés, pour préserver un peu la puissance de calcul du serveur. Ce n'est plus le cas ! Après une légère modification de la configuration du serveur HTTP (activation du module deflate sur Apache) une débauche de calculs (comme les scripts sont dynamiques, on ne peut pas se contenter de les comprimer une fois pour toutes) a permis de passer de 4,1Ko à 948o pour le script correspondant au gadget météo et de 3,8 Ko à 2 Ko pour le script correspondant aux actualités, soit une perte de poids de l'ordre de 47 à 78%. Il est à noter que pour les actualités surtout, le poids dépend beaucoup des actualités du moment, mais c'est l'ordre de grandeur qui importe.

Résultats

Finalement, en combinant les deux, on passe de 4,1Ko à 845o pour la météo et de 3,8Ko à 1008o pour les actualités, soit une perte de poids de 74 à 80%.

Les résultats sont synthétisés dans le tableau ci-dessous :

Composant	Poids d'origine	Poids compressé	Poids obfusqué	Poids obfusqué et compressé
météo	100%	22%	83%	20%
actualité	100%	53%	87%	26%

En conclusion, grâce à YUI Compressor et au module deflate, nos gadgets ont perdu 6K avant l'été !

IE et l'ajout d'iframe en Javascript

Benjamin — Thu, 15 Jan 2009 11:30:00 +0100

Ce billet décrit deux anomalies d'Internet Explorer dans la façon dont il gère des iframes ajoutés dynamiquement, et une façon d'y remédier.

La manipulation du DOM avec Javascript est la technique de base utilisée pour enrichir des pages HTML (c'est d'ailleurs ce qu'utilisent les gadgets publo.fr). Cependant, tous les navigateurs ne respectent pas les standard du Web, et bien sûr, certains ajoutent des bugs à ces incompatibilités.

Internet Explorer présente un bug assez original dans ce domaine. Le problème survient lorsqu'on utilise du Javascript pour ajouter un iframe au document et que l'on tente de modifier ses attributs a posteriori.

Premier exemple : les changement d'attributs sans effet

On ajoute un iframe au noeud "noeudIFrame" puis on tente de masquer sa bordure et ses scrollbars (par défaut, IE affiche une bordure et des scrollbars aux iframes, ce qui n'est pas toujours du meilleur effet).

var iframe = noeudIFrame.appendChild(
                     document.createElement('iframe'));
iframe.setAttribute('frameBorder', '0'); 
iframe.setAttribute('scrolling', 'no');

Malheureusement, les deux dernières lignes de code n'ont aucun effet (la bordure et le scrolling resteront visibles) sous IE... Il est trop tard lorsque l'iframe a été ajouté dans le DOM pour modifier ces deux attributs. Par contre, le code suivant fonctionne :

var iframe = document.createElement('iframe');
iframe.setAttribute('frameBorder', '0'); 
iframe.setAttribute('scrolling', 'no');
noeudIFrame.appendChild(iframe);

Notez au passage que la casse utilisée pour l'attribut frameBorder n'est pas une coquille de ma part : alors que le nom standard est frameborder, IE ne le comprend pas mais comprend frameBorder.

Second exemple (plus vicieux) : l'`iframe` qui plante le navigateur

On ajoute un iframe au document puis on définit sa source (attribut src) :

var iframe = noeudIFrame.appendChild(
                      document.createElement('iframe'));
iframe.setAttribute('src','http://blog.publo.fr');

Ici le résultat est encore plus catastrophique : il peut aboutir à un crash du navigateur sous Windows XP, avec IE6 et IE7 (le bug semble corrigé sous Vista). Là encore, la prudence recommande de définir la source avant d'ajouter l'élément :

var iframe = document.createElement('iframe');
iframe.setAttribute('src', 'http://blog.publo.fr'); 
noeudIFrame.appendChild(iframe);

En conclusion, si l'on veut éviter des problèmes avec certains navigateurs puis des bugs difficiles à identifier, il vaut mieux ménager le DOM ! En particulier pour les iframe : on commence par les créer, on les définit complètement puis on les insère dans le document.

Tutoriel sur le partitionnement d'un serveur Kimsufi

Benjamin — Tue, 04 Nov 2008 09:00:00 +0000

Le partitionnement de base fourni sur les serveurs Kimsufi sous Ubuntu mérite généralement un bon remaniement pour coller à ses besoins. Ce tutoriel retrace comment passer d'une partitionnement monolithique à un partitionnement plus adapté à un serveur.

Le serveur d'origine n'est pas vraiment partitionné selon mes goûts. Cela ressemble à ceci :


root@serveur:~# df -k
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1              3099260    492972   2448856  17% /
varrun                  493172        44    493128   1% /var/run
varlock                 493172         0    493172   0% /var/lock
udev                    493172        20    493152   1% /dev
devshm                  493172         0    493172   0% /dev/shm
/dev/sda2            236749404     32844 224690304   1% /home

Bref, une partition énorme pour /home et pas grand chose pour le reste : même la racine n'a droit qu'à une portion congrue. Sachant que la plus grande partie du disque sera consacrée à /var (i.e. les données) et à /usr (i.e. les applications installées), quelques transformations s'imposent.

Pour retailler les partitions, j'utilise parted en ligne de commande.

En fait, je me contente de retailler /home pour disposer d'un /var et d'un /usr de bonne taille. Le /home lui-même ne me servira pas à grand chose. Disons qu'on part pour un /var et un /usr de 100Go chacun et un /home de 49Go et on y ajoute un petit /tmp de 1Go. Pour commencer, il faut démonter la partition:

root@serveur:~# umount /home

Ensuite, une petite vérification ne fait pas de mal :

root@serveur:~#parted
GNU Parted 1.7.1
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.

On commence par regarder les partitions :

(parted) print                                                            

Disk /dev/sda: 250GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type     File system  Flags
 1      32.3kB  3224MB  3224MB  primary  ext3         boot 
 2      3224MB  250GB   246GB   primary  ext3              
 3      250GB   250GB   535MB   primary  linux-swap

Puis on vérifie rapidement l'état de /home (la deuxième dans la liste):

(parted) check 2                                                          
Information: The ext2 file system passed a basic check.  For a more comprehensive check, use the e2fsck program.

Et l'on regarde ce qu'on peut en faire :

(parted) print 2                                                          

Minor: 2
Flags: 
File System: ext2
Size:         246GB (98.5%)
Minimum size: 3900MB (1.56%)
Maximum size: 250GB (100%)

Elle est donc énorme pour le moment, mais très peu occupée (c'est un peu normal pour un serveur fraîchement installé). Voici le partitionnement souhaité (avec parted, on doit préciser où commence et où se termine une partition):

/home : début à 0, fin à 49Go
/tmp : début à 49Go, fin à 50Go
/var : début à 50Go, fin à 150Go
/usr : début à 150Go, fin à 250Go

Pour le resizing de /home, cela se passe ici (en mode intéractif, c'est plus facile!) :

(parted) resize                                                          
Partition number? 2                                                       
Start?  [3224MB]?                                                         
End?  [250GB]? 52GB                                                       
Warning: A resize operation on this file system will use EXPERIMENTAL code
that MAY CORRUPT it (although it hasn't doneso yet
in the past).
You should at least backup your data and run 'e2fsck -f' afterwards.
OK/Cancel? OK

Bon, le warning n'est pas très encourageant, mais ça fonctionne...

On commence par une partition étendue (pas besoin d'une primaire vu que je ne vais pas y installer un autre OS):

(parted) mkpart                                                           
Partition type?  primary/extended? extended                               
Start? 52GB                                                               
End? 250GB

Dans cette partition, on va placer les partitions logiques /tmp /var et /usr : pour /tmp :

(parted) mkpartfs                                                         
Partition type?  [logical]?                                               
File system type?  [ext2]?                                           
Start? 52.0GB                                                               
End? 53.0GB

et ainsi de suite pour /var et /usr

Attention, il est judicieux d'être précis sur la taille des partitions indiquées à parted, sinon c'est lui qui choisira comment il gère l'approximation. Pour une partition de 100Go, une approximation à 1Go n'est pas franchement gênante ; elle l'est plus pour une partition de 1Go, comme /tmp. C'est pour cela que j'ai précisé la première décimale du start et du end.

Finalement, on obtient :

(parted) print                                                            

Disk /dev/sda: 250GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type      File system  Flags
 1      32.3kB  3224MB  3224MB  primary   ext3         boot 
 2      3224MB  52.0GB  48.8GB  primary   ext3              
 4      52.0GB  250GB   198GB   extended               lba  
 5      52.0GB  52.0GB  8193kB  logical   ext2              
 6      52.0GB  152GB   100GB   logical   ext2              
 7      152GB   250GB   97.5GB  logical   ext2              
 3      250GB   250GB   535MB   primary   linux-swap

Reste maintenant à mettre à jour /etc/fstab pour y faire figurer les nouvelles partitions

root@serveur:~#vi /etc/fstab

/dev/sda1       /       ext3    errors=remount-ro       0       1
/dev/sda2       /home   ext3    defaults                0       2
/dev/sda3       none    swap    defaults                0       0
/dev/sda5       /tmp    ext2    defaults                0       2
/dev/sda6       /usr    ext2    defaults                0       2
/dev/sda7       /var    ext2    defaults                0       2
proc            /proc   proc    defaults        0       0
sysfs           /sys    sysfs   defaults        0       0

Et le tour est joué.
Ensuite, il reste à déplacer le contenu actuel de /usr de la partition /dev/sda1 à la partition /dev/sda5, et le contenu de /var de la partition /dev/sda1 à /dev/sda7. Tout ceci peut se faire à coups de mv, en utilisant /home comme tampon.

Attention, un mv des répertoires /usr et /lib n'est pas complètement anodin : il y a des choses qui servent là-dedans ! Pareil pour le changement de la table des partitions. En cas de grosse erreur pendant ces manip, le mode secours du Kimsufi vous permettra de remettre de l'ordre dans tout cela, mais c'est un peu pénible et cela peut donner quelques sueurs froides...

root@serveur:~# mv /usr /home
root@serveur:~# mkdir /usr
root@serveur:~# mount /usr
root@serveur:~# mv /home/usr/* /usr

et la même chose pour var, ou presque car /var/run et /var/lock sont gérés différemment, donc on les laisse en place.
Après un reboot, tout doit rentrer dans l'ordre :

root@serveur:~# df -k
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1              3099260     69504   2872324   3% /
varrun                  493172        44    493128   1% /var/run
varlock                 493172         0    493172   0% /var/lock
udev                    493172        36    493136   1% /dev
devshm                  493172         0    493172   0% /dev/shm
/dev/sda2             46884132     32848  44469648   1% /home
/dev/sda5                 74960        13      70830   1% /tmp
/dev/sda6             96116872    298880  90935440   1% /usr
/dev/sda7             93738184    124756  88851764   1% /var

Le problème des cadres arrondis en HTML

Benjamin — Fri, 10 Oct 2008 10:41:00 +0000

Faire des cadres à coins arrondis en HTML qui s'adaptent à la taille du contenu n'est pas une sinécure. Les limitations actuelles de CSS conduisent souvent à un code HTML plus ou moins pollué par la mise en forme. Cet article présente un exemple de mise en oeuvre de la technique de décoration qui fait appelle à Javascript pour pallier à cet inconvénient.

Le problème des cadres à coins arrondis est vieux comme le Web. En HTML et CSS, alors qu'il est très simple de faire des cadres rectangulaires qui se redimensionnent tout seuls, il n'existe pas de façon simple de faire le même genre de cadres avec des coins arrondis ou plus généralement des cadres composés d'images.

En attendant la prochaine version de CSS qui devrait apporter une solution propre, il faut se résoudre à utiliser un contournement. Sur ce point il y a deux écoles : ceux qui utilisent des éléments TABLEs et ceux qui utilisent des DIVs avec du CSS. Aucune de ces deux méthodes n'est satisfaisante. La première car elle détourne l'élément TABLE de son usage normal (représenter des données tabulaires). La seconde car elle introduit une multitude d'éléments DIV qui ne portent aucun sens et polluent le HTML. En outre, les inconvénients existent aussi bien du côté client (code HTML pollué donc plus lourd et moins accessible) que du côté serveur (on se retrouve avec du spaghettiware HTML à maintenir).

Cet article présente un exemple d'utilisation d'une technique qui ne résout pas tous ces problèmes mais qui permet de faciliter la maintenance du code HTML. Cet exemple ne prend pas non plus parti dans la querelle des pro-DIV contre les pro-TABLE, mais arbitrairement, il s'appuie sur un layout en TABLEs. L'objectif est d'avoir un code HTML non pollué par la mise en forme, du point de vue du développeur (on ne peut hélas pas grand chose pour le client...).

Le principe consiste à utiliser du Javascript pour décorer le code HTML en ajoutant là où on le souhaite les fameux cadres à coins arrondis. Pour développer commodément la chose et s'assurer de la portabilité du code, le recours à la librairie Prototype n'est pas inintéressant, aussi ne s'en privera-t-on pas.

Voici donc une page d'exemple : page_sans_cadre.html dont le code source est le suivant :

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="fr_FR">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
</head>
<body>
<p>Ceci est une page qui parle pour ne rien dire</p>
<div class="important">
<p>Ceci est une zone encadrée que j'aimerais bien voir encadrée</p>
<p>Et puis, je préfère les coins arrondis car c'est plus joli !</p>
</div>
<p>Ceci est le bas de la page...</p>
</body>
</html>

Le but du jeu est de faire un cadre à bord arrondis autour de la section importante (celle de class "important"). On peut bien sûr faire cela directement dans le code HTML, à coups de TABLE et CSS et en utilisant des images pour le cadre. On aboutit au code HTML suivant :

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="fr_FR" xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<link href="./cadre.css" type="text/css" rel="stylesheet" />
</head>
<body>
<p>Ceci est une page qui parle pour ne rien dire</p>
<table>
<tbody>
<tr>
<td class="coin_haut_gauche"/>
<td class="bord_haut"/>
<td class="coin_haut_droit"/>
</tr>
<tr>
<td class="bord_gauche"/>
<td class="coeur'>
<div class="important">
<p>Ceci est une zone encadrée que j'aimerais bien voir encadrée</p>
<p>Et puis, je préfère les coins arrondis car c'est plus joli !</p>
</div>
</td>
<td class="bord_droit"/>
</tr>
<tr>
<td class="coin_bas_gauche"/>
<td class="bord_bas"/>
<td class="coin_bas_droit"/>
</tr>
</tbody>
</table>
<p>Ceci est le bas de la page...</p>
</body>
</html>

avec la feuille style suivante : cadre.css

Le résultat peut être visualisé ici : page_avec_cadre.html

Cela fonctionne, mais le fichier a doublé de volume, et c'est un devenu un cauchemar pour celui qui doit maintenir ce code...

La technique de décoration avec Javascript permet de revenir à un code très voisin du code d'origine. C'est en Javascript que le DOM sera modifié pour ressembler au code complexe ci-dessus. Avec Prototype, il suffit de quelques lignes pour enrober dans une table la section "importante". Voici le code utilisé :

function decore(){
	var element = $$('.important')[0];
	var td = element.wrap('td');
	td.addClassName('coeur');
	var tr= td.wrap('tr');
	td.insert({before : '<td class="bord_gauche"></td>'});
	td.insert({after : '<td class="bord_droit"></td>'});
	var tbody = tr.wrap('tbody');
	tbody.wrap('table');
	tr.insert({before : '<tr><td class="coin_haut_gauche"></td><td class="bord_haut"></td><td class="coin_haut_droit"></td></tr>'});
	tr.insert({after : '<tr><td class="coin_bas_gauche"></td><td class="bord_bas"></td><td class="coin_bas_droit"></td></tr>'});
}
Event.observe(window,'load',decore,false);

Voici la nouvelle forme du fichier HTML :

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="fr_FR">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<script type="text/javascript" src="./prototype.js"></script>
<script type="text/javascript" src="./test.js"></script>
<link href="./test.css" type="text/css" rel="stylesheet" />
</head>
<body>
<p>Ceci est une page qui parle pour ne rien dire</p>
<div class="important">
<p>Ceci est une zone encadrée que j'aimerais bien voir encadrée</p>
<p>Et puis, je préfère les coins arrondis car c'est plus joli !</p>
</div>
<p>Ceci est le bas de la page...</p>
</body>
</html>

Vous remarquerez que l'on est revenu à une structure simple, non polluée par la mise en forme. Seule différence avec le code d'origine : les deux entités script de l'entête et bien sûr la feuille de style. Le résultat peut être vu ici : page_avec_cadre_decore.html

Prototype et l'encodage

Benjamin — Wed, 01 Oct 2008 11:34:00 +0000

Prototype est un framework Javascript qui facilite grandement le développement d'interfaces riches. Il offre notamment des objets bien utiles pour faire de l'AJAX. Hélas, même si Prototype permet de s'affranchir de nombreux problèmes de compatibilité de navigateurs, on finit toujours par être rattrapé par le problème récurrent le plus vieux de l'Internet : l'encodage dès qu'on quitte le monde merveilleux de l'ASCII.

J'avais déjà évoqué le problème de l'encodage dans les JSPs (donc côté serveur). Voici maintenant un problème rencontré côté client, sur du Javascript basé sur Prototype. Le problème survient lorsqu'on utilise l'objet Ajax.Request pour transporter dans données en JSON. Si l'on s'en tient à la documentation de Prototype, cela se fait de la manière suivante :

new Ajax.Request('/data',{
	    onSuccess: function(transport){
	    	json = transport.headerJSON;
                // et utilisez ce joli objet !
            }
});

où /data est la ressource qui renvoie les données en JSON. On aura pris soin de lui affecter un Content-type de type application/javascript et de mettre les données JSON dans un Header nommé X-JSON.
Les données renvoyées en JSON sont évaluées automatiquement et cela fonctionne très bien tant que ces données ne contiennent aucun caractère non ASCII. Par contre, si vous avez besoin de caractères non ASCII (ça peut servir, en français), les ennuis commencent.
Avec un navigateur FireFox (les curieux pourront tester sur d'autres navigateurs), dès que parmi les données, il y a des caractères accentués, FireFox lève une erreur mystérieuse : malformed URI sequence On aura beau ajouter dans la réponse du serveur toutes sortes d'artifices pour bien préciser que la réponse est encodée en UTF-8, l'erreur surgira inévitablement...

Heureusement, voici un contournement qui permet d'utiliser malgré tout nos chers caractères accentués dans les données JSON.

Primo, côté serveur, oubliez l'envoi JSON à la manière orthodoxe : renvoyez plutôt les données JSON dans le corps de la réponse HTTP et optez pour un Content-type de la forme text/html; charset=UTF-8.

Secundo, côté client (Javascript), oubliez l'évaluation automatique des données reçues : récupérez la réponse sous forme texte puis évaluez-là. En clair, cela donne :

new Ajax.Request('/data',{
           onSuccess: function(transport){
	    	json = transport.responseText;
	    	json = json.evalJSON();
                // et utilisez ce joli objet !
           }
});

C'est moins propre, moins élégant, mais cela a le mérite de fonctionner !

Google Chrome au banc d'essai

Benjamin — Fri, 05 Sep 2008 00:13:00 +0000

Dans cet article, nous comparons Google Chrome à ses principaux concurrents sur des critères de performance et de respect des standards du Web. S'il a une longueur d'avance sur les navigateurs en version stable, c'est loin d'être le cas avec les versions beta et autres versions de développement.

Difficile de passer à travers le battage médiatique qui a accompagné la sortie de la version beta du navigateur de Google : Chrome. A en croire la bande dessinée publicitaire faite par Google, leur navigateur est bien entendu le plus ergonomique, le plus riche, le plus performant...

Face à cette avalanches d'affirmations dont certaines sont probablement exactes, rien de tel que quelques tests pour se convaincre du bien fondé ou non de ce discours marketting. J'ai donc en premier lieu souhaité comparer Chrome à d'autres navigateurs du marché sur deux points:

le respect des standards du web au travers d'une célèbre batterie de tests : acid3
les performances du moteur Javascript embarqué au travers d'une autre batterie de tests : sunspider

Avant de nous lancer dans les tests, passons en revue les forces en présences

Les navigateurs testés

Chrome beta, bien sûr
Internet Explorer, l'inévitable, dans sa version 7.0, et vu que Chrome est lui-même en version beta, je me suis permis de faire également les tests avec Internet Explorer 8 beta
Firefox, son challenger dans sa version stable 3.0 et Firefox 3.1 (nightly build), la version de développement
Opera, l'aristocrate des navigateurs, dans sa version stable 9.51 et dans sa version en cours de développement (9.6)
Safari, pour les inconditionnels de la marque à la pomme, dans sa version stable 3.1.2, et dans sa version de développement WebKit (36012)

Tous ces navigateurs ont été installés sur la même machine qui tourne sous Windows XP, avec un processeur double-cœur.

Test de respect des standards du web

Tout d'abord, pourquoi tester cet aspect ? En fait, le respect des standards du web (DOM, CSS et JavaScript notamment) est primordial pour un navigateur : c'est ce qui fait que le comportement et le rendu d'une application web seront ceux attendus, et sensiblement les mêmes quel que soit le navigateur. Et pour nous développeurs, c'est ce qui permet d'éviter d'avoir à coder autant de versions d'une interface web qu'il y a de navigateurs sur le marché.

Pour tester cet aspect, je me suis donc appuyé sur le test acid3 qui permet en seulement une page web, d'attribuer une note au navigateur testé, par rapport à son respect des standards du web. D'ailleurs, pour tester votre navigateur, faites-lui passer le test acid3 !
Un sans-faute sur ce test devrait donner un rendu avec la note 100/100 .

Voici les résultats obtenus par mes cobbayes :

Chrome beta : 76/100
Internet Explorer 7.0 : 12/100
Internet Explorer 8.0 beta : 21/100
Firefox 3.0 : 71/100
Firefox 3.1 (version développement) : 84/100
Opera 9.51 : 84/100
Opera 9.6 : 84/100
Safari 3.1.2 : 75/100
Webkit (Safari version développement) : 99/100

Le gagnant de cette manche est donc WebKit, qui fait figure d'extraterrestre avec ses 99/100... On peut tout de même décerner une mention spéciale à Opéra 9.51 avec ses 84/100 puisqu'il s'agit d'une version stable, contrairement à WebKit, Chrome et Firefox 3.1. Au passage, on peut aussi remettre un bonnet d'âne à Internet Explorer pour son non respect des standard, même si ça s'améliore un peu avec la version 8 beta. Chrome est donc bien placé par rapport aux navigateurs en version stable (Internet 7, Firefox 3.0, Safari 3.1.2), mais il reste derrière Opéra (y compris version stable) et derrière WebKit et Firefox 3.1 (versions de développement).

Test des performances du moteur JavaScript

Les performances de Chrome en termes d'exécution de JavaScript constituent un argument fort de Google, et certains utilisateurs de GMail, qui met en oeuvre JavaScript de façon intensive, font déjà état de progrès fabuleux constatés par rapport à leur ancien navigateur. Voyons donc ce qu'il en est sur un test classique des performances d'exécution de moteurs JavaScript : le test sunspider. Ce test en ligne permet de chronométrer votre navigateur (ou plutôt son moteur Javascript) lorsqu'il fait des calculs, des manipulations de chaînes, de la crypto, bref, un peu de tout.
Voici les résultats obtenus :

Chrome beta : 2726.8ms (+/- 1.6%)
Internet Explorer 7.0 : 50887.8ms (+/- 5.1%)
Internet Explorer 8.0 : 10394.4ms (+/- 0.3%)
Firefox 3.0 : 4574.6ms (+/- 3.4%)
Firefox 3.1 nightly build : 2613.2ms (+/- 4.5%)
Opera 9.51 : 6468.8ms (+/- 1.8%)
Opera 9.6 : 6583.4ms (+/- 2.6%)
Safari 3.1.2 : 6127.2ms (+/- 0.8%)
Webkit (Safari en version de développement) : 4029.2ms (+/- 2.3%)

Pour Firefox 3.1, précisons que nous utilisons TraceMonkey (le tout nouveau moteur JavaScript de Firefox), que l'on peut activer en mettant à true les paramètres javascript.options.jit.chrome et javascript.options.jit.content.

Ici, Chrome affiche une supériorité par rapport aux autres navigateurs en version stable, et même la version de développement de Safari est un peu moins vive. Cependant, Firefox 3.1 (version de développement) le surpasse légèrement.
Là encore, force est de constater que Microsoft fait figure de mauvais élève.

Conclusion

Le discours de Google n'est pas complètement faux, mais totalement vrai non plus... Sur les points évalués, Chrome apporte assurément un progrès par rapport à la plupart des navigateurs du marché en version stable. Par contre, dès que l'on s'intéresse à ses vrais concurrents, c'est à dire aux versions en cours de développement, on trouve mieux. Firefox notamment donne de meilleurs résultats sur les deux séries de tests.