Premier exemple d’implémentation Ajax

(Article rédigé par un groupe d’étudiants d’IUT dans le cadre d’un projet tutoré)

Ajax est un des composants importants du Web 2.0 car il apporte souplesse et dynamismes aux sites web. Il se situe au croisement de trois langages que vous devez maîtriser avant d’aller plus loin dans ce tutorial : HTML, JavaScript, PHP (ou tout autre langage interprété par le serveur).

Le but de la petite application Ajax que nous allons implémenté est, à partir d’un formulaire, de vérifier qu’un mot de passe est juste et afficher le résultat de la vérification sans rafraîchir la totalité de la page.

Pour bien mettre en évidence les différentes parties de l’implémentation, nous aurons trois fichiers :

– implement.html : Contiendra un formulaire html très simple

– implement.js : Contiendra nos fonctions JavaScript et l’utilisation du fameux XMLHttpRequest indispensable à la technologie Ajax

– implement.php : Contiendra le petit script de vérification

 

HTML

Construisons d’abord le formulaire dans implement.html, lisez attentivement les commentaires :

 <html>
 <head>
 <!-- On inclut notre future fichier JavaScript -->
 <script type="text/javascript" src="/ajax/implement.js"></script>
 </head>
 <body>
 <!--
 On déclare le formulaire en GET et en guise de page de soumission on appelle une fonction de notre futur fichier JavaScript.
 Le champs du password doit avoir une id. On récupèrera la valeur du champs grâce à cette id dans notre future fichier JavaScript
 -->
<form method="GET" action="javascript:verifier()">
 Password : <input type="text" id="pass" /><br />
 <input type="submit" value="Vérifier" />
</form>
<!-- Voilà l'endroit où le résultat sera affiché, reconnu dans notre future fichier JavaScript par son id. Pour le moment, on affiche rien. -->
<p id="resultat"></p>
</body>
</html>

 

JavaScript

Maintenant, attaquons-nous au fameux fichier JavaScript implement.js ! Comme précédemment, les commentaires expliquent le détail du fonctionnement :

/*

Fonction qui crée un objet XHR. Cette fonction initialisera la valeur dans la variable globale “requete”

*/

 

var requete = null; /* On crée une variable qui contiendra l’objet XHR */

function creerRequete() {

try {

requete = new XMLHttpRequest(); /* On essaye de créer un objet XmlHTTPRequest */

} catch (microsoft) {

/* Si cela ne marche pas, on a peut-être affaire à un navigateur de Microsoft. On tente alors de créer un objet ActiveX */

try {

requete = new ActiveXObject(‘Msxml2.XMLHTTP’);

} catch(autremicrosoft) {

/* Autre méthode si la première n’a pas marché */

try {

requete = new ActiveXObject(‘Microsoft.XMLHTTP’);

} catch(echec) {

/* Si aucune méthode ne fonctionne, on laisse l’objet vide*/

requete = null;

}

}

}

if(requete == null) {

alert(‘Votre navigateur ne semble pas supporter les object XMLHttpRequest.’);

}

}

 

function verifier() {

/* On crée notre super objet XHR global */

creerRequete();

 

/* On construit à l’avance notre URL en passant les parmètre en GET. Le paramètre de notre formulaire est seulement le contenu du champ possédant l’identifiant ‘pass’. */

var url = ‘implement.php?pass=’+document.getElementById(‘pass’).value;

 

/* On édite les propriété de l’objet : type de paramètre, url (avec paramètres) et une option autorisant une réponse du serveur */

requete.open(‘GET’, url, true);

 

/* On initialise la fonction de renvoi d’information : Après vérification que la requête est valide on met à jour le contenu HTML de la balise possédant l’identifiant ‘resultat’ avec la réponse du serveur */

requete.onreadystatechange = function() {

if(requete.readyState == 4) {

if(requete.status == 200) {

document.getElementById(‘resultat’).innerHTML = requete.responseText;

}

}

};

 

/* C’est partit ! On envoi la requête XHR au serveur */

requete.send(null);

}

PHP

Bon, la requête s’envoie correctement, reste à faire le coté serveur avec implement.php.

 

<?php

/*

On vérifie que le paramètre GET est bien présent. Si c’est le cas, on le compare avec le bon mot de passe et affiche le message qui va bien.

*/

if(isset($_GET[‘pass’]))

if($_GET[‘pass’]==”monpass”)

echo “Bon password !”;

else

echo “Mauvais password…”;

else

echo “Erreur GET”;

?>

Comme dit au début, on utilise ici une page PHP, mais on pourrait très bien imaginer un script shell, un servlet Java, une page ASP,… Exemple en Java de code équivalent dans un fichier implement.jsp :

<%

/*

On vérifie que le paramètre GET est bien présent.

Si c’est le cas, on le compare avec le bon password et affiche le message qui va bien.

*/

String pass = request.getParameter(“pass”);

if(pass!=null)

if(pass.equals(“monpass”))

out.println(“Bon password !”);

else

out.println(“Mauvais password…”);

else

out.println(“Erreur GET”);

%>

Les scripts ci-dessus sont simplistes, de bien plus puissantes utilisations sont envisageables, comme la recherche à la volée dans une base de donnée, des calculs mathématiques complexes, des retours d’infos sur le serveur,…

XML

Mais, comme vous êtes perspicaces et avides de connaissances, vous remarquerez que dans la dénomination Ajax, le X signifie XML. Or, point de XML dans nos remarquables explications pour le moment ! Il s’agit d’une autre utilisation de Ajax, que nous allons vous expliquer :

D’abord créez un fichier implement.xml et écrivez-y cet arbre très simple :

<?xml version=”1.0″ ?>

<root>

<pass>monpass</pass>

</root>

Ensuite reprenez le fichier JavaScript et ajoutez cette fonction :

function verifierxml() {

/* On crée notre super objet XHR global */

creerRequete();

/* On indique notre fichier XML*/

var url = ‘implement.xml’;

/* On édite les propriété de l’objet : type de paramètre, url (avec paramètres) et une option autorisant une réponse du serveur */

requete.open(‘GET’, url, true);

/* On initialise la fonction de renvoi d’information : Après vérification que la requête est valide on met à jour le contenu HTML de la balise possédant l’identifiant ‘resultat’ après exploration du XML */

requete.onreadystatechange = function() {

if(requete.readyState == 4) {

if(requete.status == 200) {

/* On récupère le contenu de notre fichier */

var xml = requete.responseXML;

/* On récupère notre password au sein du fichier */

var pass = xml.getElementsByTagName(‘pass’).item(0).firstChild.data;

/* On compare et affiche suivant le résultat */

if(pass == document.getElementById(‘pass’).value )

document.getElementById(‘resultat’).innerHTML = ‘[XML] Bon pass !’;

else

document.getElementById(‘resultat’).innerHTML = ‘[XML] Mauvais pass…’;

}

}

};

/* C’est partit ! On envoi la requête XHR au serveur */

requete.send(null);

}

 

Et voilà, il ne reste plus qu’à appeler verifierxml() dans le code HTML à la place de verifier() et le tour est joué.

Conclusion

Fondamentalement, l’Ajax repose donc sur l’objet HTMLHttpRequest permettant d’effectuer des requêtes asynchrones au serveur (c’est à dire sans recharger la page en entier). Il peut s’agir d’un fichier XML que l’on peut explorer par JavaScript une fois récupéré, ou d’un script exécuté par le serveur (PHP, ASP,…). A partir de ces deux fonctionnalités, une utilisation astucieuse de JavaScript et de HTML peut aboutir à d’impressionnants effets dignes de Flash (fondu, déplacement d’image, interactions avec la souris, affichages en temps réel,…) !

Bienvenue dans le Web 2.0 🙂

Le fonctionnement d’Ajax

(article écrit par un groupe d’étudiants d’IUT dans le cadre d’un projet)

Impossible de vous expliquer comment fonctionne Ajax si vous ne connaissez pas l’organisation du World Wide Web aussi appelé Web.
Les notions de client et de serveur sont élémentaires pour comprendre l’Internet.
Derrière l’entité serveur se cache tout simplement un disque dur contenant des données. Celles-ci peuvent être sous la forme de fichiers, d’applications ou de bases de données. Bien sûr, un serveur n’est pas forcément spécialisé et peut très bien regrouper toutes ces données. Un Client est en réalité un ordinateur relié au réseau comme celui que vous êtes en train d’utiliser. Les échanges entre ces deux entités diffèrent selon la technologie utilisée.

Tout d’abord, je vais essayer d’expliquer aux plus novices d’entre vous comment marche l’affichage d’une page web utilisant uniquement le HTML.
Si vous voulez davantage connaître l’HTML, je vous conseille de visiter cette page : http://www.ext.upmc.fr/urfist/html/html.htm.
Lorsque vous surfez sur la toile et que vous cliquez sur un lien, ou tapez une adresse, votre navigateur web (Internet Explorer ou Mozilla) envoie une requête au serveur. Le serveur étant toujours prêt à répondre aux demandes du client, il retourne au navigateur web du client une page HTML stockée sur son disque dur. C’est ensuite votre navigateur qui va interpréter et afficher la page.
Voici un petit schéma explicitant les quelques lignes ci-dessus:

Mais le web n’est pas composée que de pages statiques. En effet, avec le langage PHP les pages ont la possibilité d’être animées.Par exemple, avec un petit script PHP la page peut afficher la date et l’heure à laquelle elle a été affichée. Ici, les échanges entre serveur et client sont différents. Le processus est similaire, sauf que le serveur effectuera un traitement avant de renvoyer la page.

En effet, le serveur va devoir exécuter le script. Celui retournant la date et l’heure n’est pas gourmand en ressources système, mais certains peuvent pénaliser le serveur.Voici,un second schéma:

Un troisième langage permet de faire des pages dynamiques, il s’agit du JavaScript. Le traitement est différent car c’est du coté client que le script s’exécute. Cela permet de ne pas surcharger le serveur, et facilite ainsi sa tâche. Les traitements effectués coté client sont d’un ordre généralement différent de ceux effectués coté serveur. Le javascript est principalement utilisé pour des opération de rendu de l’affichage alors que les traitements serveur sont plus focalisés sur la gestion des données.

Cet article ne devait pas être sur le fonctionnement d’Ajax ? Si, bien sûr, mais pour comprendre son fonctionnement, il faut savoir comment les langages les plus courants opèrent puisque Ajax est en réalité un ensemble de technologie(s) et de langages.
Ajax est un mélange des deux précédents schémas : Lorsque le client télécharge une page, celle-ci intègre des composant Javascript (donc exécutés coté client) qui seront ensuite capables de requêter de nouvelles informations au serveur et se chargeront de les afficher dans le navigateur.
Les javascripts établissent ainsi une communication entre le client et le serveur par la création d’un contrôle ActiveX sous Internet Explorer et d’un XMLHttpRequest sur la plupart des autres navigateurs.
Le serveur communiquera avec le client en lui transmettant des texte souvent formatés à l’aide de XML. Le navigateur se chargera de l’interprétation et de l’affichage de ces données.

Avec l’Ajax, les échanges entre serveur et client ne nécessitent plus de raffraichissement complet de l’écran mais seulement de certaines zone de celui-ci. L’utilisateur aura donc un impression d’interactivité beaucoup plus grande. Les mises à jour de la page ont lieu régulièrement, à chaque fois que l’on est dans la situation où la requête est envoyée. Ce système est aussi plus économique pour le réseau et le serveur qui ne génèrent plus que des informations partielles (au risque de pooling près).

Mesures de performance d’un disque dur

Question du jour alors que j’envisage de remplacer ma machine par une version VIA EPIA equipé d’une compact flash en guise de disque dur… A quelle vitesse tourne mon disque actuel !

Voici donc quelques commandes utiles pour répondre à cette question:

  • hdparm -t /dev/hda donne la vitesse d’accès en lecture sur le disque, toutefois, cette commande est un maximum car les conditions choisies par hdparm sont particulières. Dans mon cas, je trouve 30MB/s
  • L’outil seek dont le source est ici permet lui de donner le plus mauvais cas, on multipliera le nombre de seek par 4 pour obtenir le nombre de KB/s. Dans mon cas, je trouve 220KB/s avec un temps d’accès de 32ms.
  • Avec hdparm -T /dev/hda il est possible de voir ce que donne une lecture dans le cache. pour ma part j’obtiens 206M/s

Les paramètres de hdparm sont un point primordial dans l’optimisation des accès disques. hdparm /dev/hdales résume:

  • multcount : indique combien de secteur sont rappatriés à chaque E/S
  • I/O support : indique si le mode d’accès est 16, 32 ou 32-async
  • unmaskint : indique si le noyau peut traiter d’autres interruption durant un accès disque
  • using_dma : indique si l’usage du DMA est activé.. primodial !

Un autre outil pour les tests d’I/O est bonnie, dans sa version plus récente Bonnie++. Cet outil permet de tester les I/O d’une machine unix en testant les accès par bloc, caractère par caractère, testant les relecture et le temps d’accès. Il semble que ce soit l’outil le plus complet. Avantage de cet outil : il n’utilise par directement le périphérique mais le répertoire courant, du coup il est possible de tester un montagne NFS par exemple.
Mes résultats sont les suivants:

  • Montage NFS (100Mb)
    • Mode char WR/RD: 9MBs / 7MBs
    • Mode block WR/RD: 9MBs / 7.5Mbs
    • Rewrite : 4MB/s
    • Seek : 130/s
    • File seq created /s : 80
    • File seq Read /s : 3791
    • File seq Deleted / s : 164
    • File rand created /s : 91
    • File rand Read /s : 5395
    • File rans Deleted / s : 132
  • Disque local:
    • Mode char WR/RD: 21MBs / 25MBs
    • Mode block WR/RD: 35MBs / 26Mbs
    • Rewrite : 13MB/s
    • Seek : 123/s
    • File seq created /s : 22144
    • File seq Deleted / s : 25867
    • File rand created /s : 22825
    • File rans Deleted / s : 22231

Accès à CVS dans un tunnel Ssh

Voici, le probleme du jour : accéder à un serveur CVS situé sur une machine n’offrant pas directement un accès ssh depuis internet. La solution fonctionne pour n’importe quel protocole.

  • Se connecter sur le serveur accessible en ssh depuis l’Internet
  • Lancez sur celui-ci un tunnel entre lui-même et le serveur offrant le service csv : ssh -a -e none -N -L 2401:localhost:2401 user@cvsServer
  • Lancez ensuite sur la machine sur laquelle vous souhaitez utiliser le service csv un autre tunnel: ssh -a -e none -N -L 2401:localhost:2401 user@sshServer
  • Maintenant il ne reste plus qu’à se logguer sur le service cvs : cvs -d:pserver:login@localhost:/home/cvs login

Explication d’une ligne Shell desctructrice

Une curiosité très efficace dans le plantage de systèmes… J’ai découvert ça il y a quelques jours, venant d’un de mes étudiants (ça fait plaisir ;o) ). il s’agit d’une petite ligne de commande shell particulièrement meurtrière et donc à ne surtout pas utiliser car elle plante immédiatement les systèmes sans ulimit… Et quand je dis immédiatement, c’est immédiatement : pas même le temps de bouger la souris pour fermer le terminal ou de taper un CTRL+C ni même le temps pour le système de tracer l’emploi de la commande.
Cette ligne a en plus la bonne idée d’être particulièrement esthétique…. bref j’adore ! Voici donc la bête :
:(){ : |:& };:
Joli non !!
Voyons un peu plus ce qu’il se passe derrière ces caractères: :() { … } correspond à la création d’une fonction. : | : & correspond à l’appel récursif de la-dite fonction en lançant 2 processus supplémentaires en tâche de fond. Enfin les derniers ; : sont l’appel de la fonction précédemment définie.
Que se passe-t-il alors ? des milliers de processus shell sont lancés sur le système jusqu’à ce que mort s’en suive…
La parade ? Il suffit de limiter le nombre de processus max d’un utilisateur une centaine pour éviter que le scheduler soit saturé et que le système plante.

Cette commande ne doit surtout jamais être utilisée sur une machine autre que votre machine personnelle … et c’est à vos risques et périls !

Locker son ecran sur Mac Os X (tiger)

Il me semble étrange de constater combien il est compliqué de locker son écran sous Mac OS X quand cette fonctionnalité est la première de toute démarche de sureté. Bref… heureusement une solution existe. Plusieurs d’ailleurs, référencées dans le lien ci-joint.
La méthode qui me semble la plus pratique consiste à lancer le “Trousseau d’accès” depuis “Applications/Utilitaires” puis de choisir les préférences, et dans l’onglet “général”, cocher la case “Afficher l’état dans la barre des menus”. Vous aurez alors, dans la barre des menu, en haut de l’écran un petit cadenas permettant de locker l’écran en deux clicks.

Utilisation de subversion

Subversion est un outil de gestion de sources ou plus généralement de gestion de configuration. Subversion est le successeur de cvs.
Son utilisation est à première vu similaire à celle de cvs mais avec quelques différences non anodines. Nous allons voir l’installation sur un environnement Opensuse.
Tout d’abord, il faut installer le rpm de subversion. Il faudra ensuite indiquer dans le fichier /etc/sysconfig/svnserve le répertoire où stocker le repository de subversion. C’est dans la variable SVNSERVE_OPTIONS que l’on indiquera le répertoire choisi. On enlèvera aussi l’option -R qui bloque l’accès en écriture
Il faut ensuite créér un utilisateur svn et un groupe svn. Ceci se fera en editant les fichiers passwd et group ou en utilisant les commandes useradd et groupadd

Ces premières étapes passées il faut créer le repository , pour cela, nous allons appeler la commande suivante : svnadmin create –fs-type fsfs repertoire_du_repository
Cette commande va créer un ensemble de répertoires dans repository. Nous allons commencer par editer deux des fichiers du repository:
/conf/svnserv.conf : nous allons dé-commenter les lignes suivantes:
[general]
anon-access = read
auth-access = write
password-db = passwd

Ensuite, nous allons modifier le fichier des mots de passe pour ajouter les utlisateurs nécessaires. ce fichier est conf/passwd:
[users]
# harry = harryssecret
# sally = sallyssecret
utilisateur = mot_de_passe

On vérifiera que l’utilisateur et le groupe propriétaire de tous les fichiers du repository soit bien svn:svn, sans quoi il sera impossible d’ecrire dedans par la suite.

Le serveur svn peut alors être démarré en utilisant le script fournit par suse: /etc/rc.d/svnserve restart

La création d’un projet dans le repository se fera par la commande suivante : svn import path svn://localhost/projet. Normalement, un mot de passe doit être demandé, il s’agit de celui précédemment saisi dans le fichier passwd.

Quelques commentaires :

  • Nous avons créé un repository à la norme fsfs, il s’agit de la façon dont sont stockées les données, ici sous forme de fichiers. Il existe aussi la possibilité d’utiliser un base de donnée berkeley, (option –fs-type bdb) mais d’après la documentation de svn, ce mode de fonctionnement est beaucoup moins avantageux.
  • Le repository peut être accédé de plusieurs façons, la première etant directement via le filesystem local (quand le repository est sur la même machine) ; par file://path/to/repo. Le second est l’utilisation de svnserv par svn://path/to /repo. Le troisieme svn+ssh://serveur/path/to/repo pour utiliser le protocole svn au travers d’un tunnel ssh et la dernière est http (ou https) par http://serveur/repo pour utiliser WebDav

Utilisation de MySql sur NFS

Pourquoi utiliser MySql sur un lien NFS alors que c’est franchement déconseillé ?!? Après tout là n’est pas vraiment la question car la doc de Mysql nous le déconseille fortement, par contre elle oublie de répondre à la vrai question : COMMENT ?

Car si l’on essaie de démarrer un MySql dont les base sont stockées sur un file-system monté on obtient l’erreur suivante : InnoDB: Unable to lock ./ibdata1, error: 13

Pour s’en sortir, il faut ajouter aux paramètre de NFS l’option nolock sous la forme mount … -o nolock … ou en l’ajoutant dans la liste des options de la fstab.

Maintenant pourquoi ?
Par exemple parce que l’on souhaite qu’une partie d’un file système d’une VM contenant les données ne soit pas en capsulé dans 3 couches de filesystem virtuel… en cas de crash… ça peut vous sauver la mise ; quand les perf ne sont pas la contrainte absolue et qu’en plus il ne s’agit que de l’utilisation d’un reseau virtuel au travers d’un bridge… c’est acceptable