Allez, les balises audio et video

D’accord, on en a assez parlé, mais ça constitue une bonne introduction à cet article Parmi les nombreuses innovations de l’HTML 5 qui vont permettre au web de se séparer d’Adobe Flash Player (vous savez, cette extension qui fait planter tous les navigateurs et bouffe au moins un des cores de votre CPU), les tags <audio> et <video> sont les plus connus. Insérer une vidéo dans un article est maintenant devenu aussi simple qu’y insérer une image :
Remarquez la rétro-compatibilité avec les navigateurs HTML4 : puisqu’ils ne vont pas interpréter ce tag, ils afficheront un gentil petit mot. Pensez éventuellement à y mettre un lien vers http://getFirefox.com ^_^ .

Bien sûr ces balises ont des attributs et une API qui leur sont propre, mais ce n’est pas le sujet de l’article.

La limitation du codec

La grosse limitation pour ces attributs est l’implémentation des codecs. Les principaux navigateurs libres n’implémentent que des codecs libres (Ogg Theora+Vorbis) mais par exemple Safari ou même Android n’implémentent que le h264. La W3C ne résoud pas ce problème, ce serait comme imposer le PNG dans les éléments <img> alors que le JPEG (propriétaire) est largement répandu.

Sa solution est donc de fournir les vidéos dans les deux formats, pour que tous les navigateurs compatibles HTML 5 puissent les décoder:

Malheureusement la plupart des éditeurs vont privilégier un seul format, que ce soit par idéologie ou par contraintes techniques (temps de conversion, espace de stockage). Déjà aujourd’hui YouTube, dans sa beta HTML 5, ne diffuse ses vidéos que en h264, ce qui le rend incompatible avec, entre autres, Firefox.

La balise canvas

Un canvas n’est pas un dessin à proprement parler mais une zone possédant une API complète pour dessiner des formes en 2D grâce à un JavaScript. Rien de mieux qu’un petit exemple je pense :


Votre navigateur n'est pas compatible

Votre navigateur n’est pas compatibleEt si vous avez un navigateur compatible, vous devriez voir le résultat ci-contre.

L’API permet de tracer des rectangles, des ronds, des traits, des pixels et même d’insérer des images ou du texte. On peut aussi jouer avec des ombres, des flous ou des dégradés de couleurs. Très pratique pour faire des manipulations de style sur un texte par exemple :
Votre navigateur n’est pas compatible
Pour être exact c’est une image, mais elle a été générée par votre navigateur (comment ça c’est moche? xD)

Et puis comme c’est basé sur le JavaScript, l’image générée peut être entièrement dynamique comme ce plotter dynamique ou le très impressionnant 3D Walker.

Standardisation de Google Gears

Le HTML 5 a intégré en standard de nombreuses nouveautés introduites par Google Gears :

• Mettre en cache des pages et scripts pour un accès hors-ligne
• Stocker localement des données
• Faire tourner les scripts en arrière-plan
• Laisser les applications interagir naturellement avec votre environnement

Ces fonctionnalités étaient les prémices du rapprochement les applications natives et les WebApps. On aime ou on aime pas, mais la standardisation du W3C permettra d’accélérer ce phénomène proche du Cloud Computing.

Accès hors-ligne

En HTML 5 il est très aisé de forcer un navigateur à garder des données en cache et ainsi permettre au visiteur de revoir cette page même s’il n’a plus de connexion. Il suffit de créer un fichier manifeste page.manifest listant les fichiers et scripts à garder en cache :
CACHE MANIFEST
CACHE:
page.htm
style.css
image.jpg
script.js

Ensuite il suffit de rajouter l’attribut au tag HTML :

Et voilà, page.htm, style.css, image.jpg et script.js seront accessibles même hors ligne!

Base de donnée locale

Le HTML 5 définit une nouvelle API JavaScript window.localStorage qui permet de stocker des données dans la mémoire du navigateur. Ses deux principales méthodes sont très simples:
window.localStorage.setItem(key, value);
window.localStorage.getItem(key);
Le localStorage est lié à un nom de domaine et les données stockées le restent même si l’utilisateur quitte son navigateur et revient plus tard. Si vos données n’ont pas besoin d’une telle persistance, vous pouvez aussi profiter de l’API sessionStorage qui, comme vous l’aurez compris, permet de stocker des informations tant que l’utilisateur n’a pas quitté le site.

La plupart des navigateurs permettent à chaque domaine de deuxième niveau de stocker 10Mo, mais le W3C recommande de demander l’autorisation de l’utilisateur si l’application a besoin de plus de place.

Attention, même s’ils se ressemblent, le Storage et les cookies n’ont pas la même utilité : n’oubliez pas que les cookies sont envoyés vers le serveur à chaque requête, ce qui pourrait rendre le trafic trop important si vous stockez de nombreuses données. À l’opposé, les données du Storage restent en local, accessibles via JavaScript.

Finalement, pour faire du vrai traitement de bases de données, il suffit de combiner le localStorage avec un JSON ou implémenter votre propre version de l’interface Database standardisée par le W3C.

Scripts en tâche de fond

Lorsqu’il exécute une opération très lourde, un JavaScript immobilise toute la page web. Parfois même l’interface du navigateur ne répond plus tant que le script n’a pas terminé. Heureusement en HTML 5, l’API Worker permet de profiter de faire tourner de tels scripts en tâche de fond.
var worker = new Worker("worker.js");
worker.postMessage(0); /* Lance le Woker avec le paramètre 0 */
worker.onmessage = function (evt) { /* Action lorsque le Worker a fini */
alert(evt.data);
};

Et le worker.js :
onmessage = function (evt) {
// evt.data est le paramètre 0
for (var i=evt.data, il=1000001; i postMessage(i);
};
};
Ce code va nécessiter pas mal de travail au cours de ses 1 000 000 itérations mais ne devrait pas immobiliser le navigateur.

Remplacer une application desktop

Finalement, les WebApps peuvent s'enregistrer elles-même pour gérer les liens vers un certain protocole ou un certain type de fichiers. On peut ainsi imaginer un client IRC en ligne qui reconnait les liens irc:// ou un éditeur de documents qui ouvre un nouvel onglet plutôt qu'OpenOffice lorsqu'il y a un lien vers un .odt :
navigator.registerProtocolHandler("irc",
"https://www.example.com/?uri=%s",
"Client IRC en ligne");
navigator.registerContentHandler("application/vnd.oasis.opendocument.text",
"http://www.example.com/?uri=%s",
"Lecteur de documents en ligne");
Malheureusement, pour des raisons de sécurité, un site ne peut s'enregistrer que pour ses propres liens : si vous tombez sur un lien irc:// sur Geekfault.org vous ne serez pas redirigé vers example.com.

Géolocalisation

Très intéressant sur le web qui devient de plus en plus mobile aujourd'hui, l'HTML 5 intègre une API qui permet d'aisément obtenir les coordonnées géographiques du visisteur :

Normalement le navigateur demande à l'utilisateur l'autorisation d'envoyer sa position. Sur un iPhone par exemple, elle sera calculée grâce à la puce GPS. Sur un navigateur desktop, la méthode est variable (triangulation WiFi, puce GPS, services de localisation d'IP ou simplement demander l'adresse de l'utilisateur).

ContentEditable

(Attention, paragraphe très... personnel ^^) Alors là je suis fan de cette fonctionnalité : elle permet de rendre n'importe quelle partie d'une page éditable. On voyait ça apparaître de plus en plus dans les applications en ligne, et maintenant c'est standardisé et extrêmement facile à mettre en place. La preuve? Essayez de cliquer sur ce paragraphe !

Et en plus c'est du WYSIWYG ! Essayez Ctrl+B ou Ctrl+I (sous Chromium) ! Et voilà le code source qui m'a permis de faire ça :

Owi, édite-moi

Je vois déjà toutes les possibilités ouvertes par une fonctionnalité si simple à mettre en place, comme par exemple corriger une erreur dans nos articles ou modifier une page de WikiPédia en deux clics.

Nouveaux inputs

Essentiellement dans le soucis de rendre le web encore plus accessible (aux handicapés) et aux système d'auto-remplissage, le HTML 5 intègre une dizaine de nouveaux types d'inputs textuels : tel, search, url, email, datetime, date, month, week, time, datetime-local, number et color. Les navigateurs sont supposés proposer une interface à l'utilisateur comme par exemple un calendrier pour remplir un datetime, mais ni Chromium ni Firefox ne semble s'y conformer pour l'instant.

On remarque aussi l'apparition de l'input range qui vient combler une déficience qui forçait souvent à avoir recours à une librairie JavaScript.

Autres nouvelles balises

Le W3C introduit dans l'HTML 5 de nombreuses nouvelles balises, dont voici la liste exhaustive

• section, article, aside, hgroup, header, footer, nav encadrent les principaux contenus d'une page web typique. On abandonne ainsi l'utilisation constante de, par exemple, <div id="header">
• figure et son sous-élément figcaption permettent de lier une légende à une image ou une vidéo
• embed a pour but de remplacer object lors de l'insertion de Flash ou de Java (dans les rares cas où ce sera nécessaire)
• mark encadre un mot ou un texte important pour, par exemple, le surligner en CSS
• progress est l'élément à privilégier si vous affichez la progression d'une tâche
• meter représente une mesure telle que l'utilisation du disque
• time représente une date et/ou une heure
• ruby, rt, rp permet d'intégrer des annotations ruby (WTF?)
• command représente une commande que l'utilisateur peut invoquer
• details encadre un complément d'information ou des contrôles supplémentaires que l'utilisateur peut obtenir sur demande
• keygen permet de fournir une clé de contrôle pour la vérification de la validité des données
• output encadre une zone où un script affichera son résultat

La plupart de ces nouveaux éléments sont liés à l'accessibilité mais peuvent aussi présenter un avantage de lors de la création de scripts complexes.

Et nouveaux attributs

Je vouais ai déjà parlé de contentEditable mais il y a beaucoup d'autres nouveaux attributs standards en HTML 5.

• contextmenu permet de lier un menu au clic droit sur un élément
• draggable détermine si un élément peut être soumis au drag & drop. Cette fonctionnalité est malheureusement soumise à controverse à cause de sa complexité, c'est pourquoi je ne l'ai pas abordé dans l'article.
• hidden est un boléen qui remplace sa fonction homonyme en style ou CSS. L'intérêt? Cacher les éléments même dans les navigateurs pour malvoyants qui n'interprètent pas les styles.
• item et itemprop et subject permettent de regrouper des éléments
• spellcheck est un boléen qui spécifie si la correction orthographique mérite d'être activée sur un élément

Finalement, vous pouvez lier n'importe quel attribut personnalisé (ce qui peut être pratique pour certains scripts) sans contredire les standards du W3C (et donc passer les tests des validateurs) à condition que cet attribut commence par data-.

Conclusion

Avec ce nouveau standard encore à l'état de brouillon, le W3C réduit la nécessité des applets (Flash, Java) et rend le web plus accessible tout en permettant aux applications web (WebApps) d'être plus puissantes, plus faciles à coder et de vraies alternatives aux applications natives de votre ordinateur.

Si toutes les recommandations ne sont pas encore adoptées par les navigateurs, même ceux en avance sur les normes, les possibilités actuelles sont déjà très intéressantes et à prendre en compte pour tous vos prochains développements HTML/JavaScript.

Sources

Il y a encore quelques autres nouveautés dont je ne vous ai parlé, mais j'espère vous avoir donné un bon aperçu des incroyables innovations de l'HTML 5. Si vous en voulez une liste complète, je vous renvoie au site du W3C, tous les liens sont dans les sources ci-dessous.

• Brouillon des différences entre HTML4 et HTML 5 édité par le W3C
• Comparaison des fonctionnalités HTML 5 supportées par les différents navigateurs
• Référence HTML 5 de la w3schools
• Dive into HTML 5
• HTML 5 Demos

Si vous avez aimé ce post...

1. Plowshare : MegaUpload, RapidShare et autres en CLI
2. Nouveautés sur Geekfault
3. Ifconfig.me, connaitre son IP publique en un rien de temps

Python est devenu assez à la mode, pour le développement web, ces dernières années avec l’arrivée de frameworks web comme Django, Pylons et web.py. On le voit souvent utilisé sur apache2, avec mod_python, ou sur des serveurs Python dediés à ça (CherryPy, etc)

Je cherche depuis longtemps un moyen de faire du Python sur HTTP. J’ai mis pas mal de temps mais je pense avoir trouvé une configuration sympa.

Je vous propose ici d’essayer nginx, un serveur HTTP (entre autres), très performant et  beaucoup plus léger/rapide que apache2. Il est très efficace pour faire du reverse-proxy (c’est à dire être utilisé en frontal/load-balancer devant un serveur HTTP, et lui transmettre les requêtes en faisant du cache et le cas échéant du load-balancing).

La configuration de nginx est très simple, et la documentation est très complète : wiki.nginx.org. L’installation de nginx est facile, il est inclus dans la plupart des distributions actuelles, donc à vos emerge/apt-get.

apt-get install nginx

nginx ne gère pas le python nativement. Il y a plusieurs solutions cependant :

• Faire du proxy vers un serveur qui gère le python, comme apache2. On perd la majeure partie de l’intêret de nginx, cependant.
• Faire du FastCGI vers un serveur FastCGI. C’est la solution la plus fréquente, en utilisant fcgi.py ou flup
• Faire du WSGI. C’est un protocole de communication entre serveurs HTTP et applications Python. Solution aussi assez fréquente.
• Faire du proxy vers un serveur qui gère le python de manière native. C’est une solution moins fréquente mais très pratique.

Avant même de penser à choisir une des solutions ici présentes, il faut les comparer entre elles.

nginx => apache2 => python

L’ennui de cette solution c’est : apache2. Utiliser nginx pour forwarder à apache2 est presque inutile. Presque ? Oui, car on peut dire à nginx de garder les fichiers statiques pour lui. Cependant, le gain de cette méthode est assez minime, et ce n’est intéressant que pour faire du load balancing sur plusieurs apaches.

le FastCGI

FastCGI c’est une norme, pour faire traiter du contenu dynamique par une application externe. Donc le support du FastCGI tout seul est inutile, il faut aussi quelque chose pour gérer derrière.

J’ai testé flup, un framework Python léger. Le résultat : ça marche, méééé c’est lent. Je tournais autour de 35/50 requêtes par seconde, et l’utilisation en mémoire vive était phénoménale, 150 mégas pour 1000 requêtes. (bien sur ces chiffres n’auront de valeur que lorsqu’ils seront comparés aux autres).

FastCGI est sympa pour faire une configuration “vite”. C’est d’ailleurs la seule solution viable, à ma connaissance pour faire du PHP sur nginx, à part le proxy vers un autre serveur HTTP.

Bref, FastCGI ne m’a pas convaincu. Et mes tests avec les autres solutions m’ont donné raison. Toujours avec moi ? On passe au WSGI !

le WSGI

WSGI is the Web Server Gateway Interface. It is a specification for web servers and application servers to communicate with web applications (though it can also be used for more than that). It is a Python standard, described in detail in PEP 333.

le WSGI, c’est le standard pour le Web Python. Il n’y a qu’à consulter wsgi.org pour se rendre compte que c’est tout un monde. Il consiste en un ensemble de normes (nom de variables, par exemple) pour permettre au serveur d’exécuter  un fichier codé en Python.

Le standard pour le WSGI sur les serveurs HTTP grand public, c’est le mod_wsgi de apache2. Il a été porté sur nginx, mais c ‘est une #@!## infame, qui ne marche que sur les vieilles versions et qui n’a pas été mise à jour depuis bientôt 2 ans et demi (cf. hg.mperillo.ath.cx/nginx/mod_wsgi/). J’ai obtenu des performances d’environ 133 requêtes par seconde avec, ce qui est déjà mieux que FastCGI, pour ceux qui suivent . Par contre, dès que j’ai voulu avancer un peu avec (toucher à la configuration, et surtout, passer à une version supérieure de nginx), j’ai été confronté à ses limites (et aux #@!## de faute de frappe dans le code source)

D’autant plus que l’auteur de mod_wsgi pour apache2 et l’auteur de mod_wsgi pour nginx reconnaissent ses limitations, respectivement ici et ici. Le premier document est très intéressant pour comprendre un peu l’architecture de nginx et ses différences avec apache2. En effet, le mod_wsgi pour nginx a été codé à partir de celui pour apache2, et il subit les différences d’architecture entre apache2 et nginx.

Attention, je ne remet absolument pas à cause le WSGI ici, juste l’implémentation de mod_wsgi dans nginx.

Parce que justement, un projet super récent, c’est…. uWSGI ! uWSGI sert à combler le manque de support du WSGI dans nginx, en rajoutant un module, meilleur que mod_wsgi. Il nécessite donc de recompiler nginx. Il y a encore une autre solution, nommée gunicorn, qui ne nécessite pas de recompiler nginx. C’est un serveur HTTP minimal qui gère le WSGI nativement. uwsgi offre plus de fonctionalitées que gunicorn, mais gunicorn a l’air assez dynamique (dans le développement), et est plus facile à utiliser (pas de recompilation, support de Django natif). Au niveau des performances, je me suis amusé à faire cette comparaison :

Comparaison des performances entre uwsgi et gunicorn en fonction du niveau de parallélisme

On constate plusieurs choses :

• Les performances augmentent en utilisant 2 workers à la place d’un, mais au delà, le gain est ridicule, puis inexistant. Le nombre 2 est dépendant du nombre de coeurs de la machine, et le nombre de workers à utiliser ne sera pas le même sous un bi-socket octocore, bien évidemment. Les meilleures performances étaient obtenues en utilisant gunicorn+3workers.
• La différence est vraiment minime, gunicorn est en moyenne légèrement au dessus de uwsgi.
• Ces tests sont réalisés sur une application Django. Les performances augmentent en utilisant des frameworks plus légers comme web.py, bien évidemment.

uwsgi dispose de plus de fonctionalitées, comme par exemple une interface d’administration de serveur wsgi dans Django. Je vais ici expliquer l’installation et la configuration des deux solutions.

Ici je vais couvrir l’installation et la configuration de uwsgi et gunicorn avec Django et web.py, même si c’est bien sur adaptable avec d’autres frameworks supportant le wsgi (liste sur wsgi.org/wsgi/Frameworks).

Installation et configuration de uwsgi

Sous Debian :

1) Rajouter les dépots source, par exemple :

deb-src http://ftp.gr.debian.org/debian/ squeeze main contrib non-free

2) Télécharger la source

apt-get source nginx
tar -zxvf nginx_*.orig.tar.gz
cd nginx-*
tar -zxvf nginx_*.debian.tar.gz

2) Télécharger uwsgi

cd ..

tar -zxvf uwsgi-0.9.4.2.tar.gz

3) Modifier le paquet source de nginx pour y ajouter uwsgi. Il faut éditer le fichier nginx-*/debian/rules, trouver le bloc qui commence par ./configure et ou se trouvent toutes les options de compilation, et y ajouter

--add-module=$(CURDIR)/../uwsgi-0.9.4.2/nginx/

$(CURDIR)/../uwsgi-0.9.4.2/nginx/ est le chemin vers le dossier du module dans la source de uwsgi

4) maintenant, dans le dossier de la source de nginx, faites (pas besoin de root) :

dpkg-buildpackage

5) installer le .deb généré ainsi (en tant que root maintenant)

dpkg -i ../nginx-*.deb

6) Dernière étape : compiler uWSGI (le binaire en lui-même, qui va communiquer avec nginx par le biais du module)

cd ../uwsgi-0.9.4.2/ && make && make install && cp uwsgi_params /etc/nginx/

Cette dernière commande (le cp uwsgi_params…) sert à placer un fichier de configuration du module uwsgi exemple dans le repertoire de nginx.

Sous les autres distributions :

Il faut télécharger la source de nginx et de uwsgi, compiler nginx avec le module uwsgi (dans le répertoire nginx de la source de uwsgi), puis compiler uwsgi.

On a maintenant un serveur uWSGI et un nginx avec  le module uwsgi. Il va maintenant falloir dire à nginx de transférer les requêtes au serveur uWSGI, avec une commande uwsgi_pass. Par exemple, dans la section server d’un de vos vhost (/etc/nginx/sites-enabled/default, par exemple, sous Debian) :

location / {
include uwsgi_params;
uwsgi_pass unix:///tmp/uwsgi.sock;
}

Il faut ensuite créer une application WSGI, par exemple, pour le framework web.py :

import web

application = web.application(urls, globals()).wsgifunc()
applications = {'/': application }

Pour Django :

import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
applications = {'/': application }

Nommez ce fichier wsgi.py et placez le dans le repertoire ou vous allez placer votre code (pour Django, dans le repertoire du projet, évidemment). Si vos nerfs n’ont pas encore lâché ici, allez prendre une petite pause de 5 minutes à titre préventif, et reprenez. Maintenant, on va démarrer un serveur uWSGI. Placez vous dans le répertoire de votre fichier wsgi.py, et faites :

uwsgi -s /tmp/uwsgi.sock -C -w wsgi -p2 -L

Explications : le -s indique ou placer le socket (ça pourrait aussi être une adresse au format hôte:port, pour un usage distant). Le -w wsgi indique de charger le fichier wsgi(.py), le -p2 indique de démarrer 2 processus, et le -L désactive l’envoi des requêtes à stdout (=>flood).

Si vous allez à l’adresse de votre serveur web, vous devriez voir votre application Python en face de vous ! Vous voilà en train d’utiliser nginx+uwsgi+python.

En annexe, je rappelle que uwsgi est aussi utilisable avec apache et lighttpd.

Aussi, dans le dossier source de uwsgi, vous trouverez des templates pour un module d’administration de Django, à installer dans le repertoire des templates de l’administration de Django (si, si).

Installation et configuration de gunicorn

gunicorn est carrèment plus facile à installer. Il est codé en python, donc pas de compilation, seulement un easy_install :

easy_install gunicorn

La configuration est tout aussi facile, il suffit de cela dans la configuration du vhost dans nginx :

location / {
proxy_pass http://unix:/tmp/gunicorn.sock
}

On démarre ensuite gunicorn. Pour Django, gunicorn dispose d’un support intégré, il vous suffit de vous placer dans le répertoire de votre projet, puis :

gunicorn_django -b unix:/tmp/gunicorn.sock --workers=2

Pour web.py, il faut créer un module :

import web

application = web.application(urls, globals()).wsgifunc()

Il faut ensuite démarrer le serveur Gunicorn. En étant dans le repertoire ou se trouve le module web.py (le fichier donc le code vient avant, là, au-dessus, oui), :

gunicorn -b unix:/tmp/gunicorn.sock --workers=2 wsgi

Je vous invite à consulter ce lien : gunicorn.org/tuning.html, pour vous permettre d’augmenter les performances de gunicorn.

Annexe

Fichiers statiques

location /admin-media {alias /usr/lib/pymodules/python2.5/django/contrib/admin/media;}

location /static {root /var/www/byteflow;}

Ces deux lignes, à rajouter après le “location /” avec uwsgi_pass ou proxy_pass (selon votre configuration) indiquent à nginx de traiter les fichiers statiques directement. Il faut bien évidemment adapter à votre configuration.

Munin

Vous pouvez trouver des plugins nginx pour munin ici. Je n’ai pas trouvé de plugin munin pour uwsgi/gunicorn, mais je pourrais peut-être en faire un si je trouve le temps.

Plusieurs serveurs

Si par hasard vous avez plusieurs serveurs gunicorn/uwsgi répartis sur plusieurs machines , vous pouvez les utiliser en déclarant une section

upstream nom {}

dans nginx, contenant les adresses des serveurs distant (hôte:port ou emplacement du socket) et en utilisant “nom” comme argument à uwsgi_pass et proxy_pass.

Conclusion

Ces deux architectures sont très pratiques pour faire tourner du python dans un serveur web, ici nginx. uwsgi dispose de plus de fonctionalités, mais la plupart (template d’admin Django, memory profiling) pourraient facilement être ajoutées à gunicorn, qui est beaucoup plus léger à installer/configurer/maintenir (2 commandes et 3 lignes de configuration dans nginx). J’ai les deux personellement sur mon serveur, j’ai eu à alterner entre les deux pour écrire cet article, et c’est pas bien dur, un daemon à arrêter, un autre à démarrer, et changer une ligne dans la configuration de nginx.

Liens

wsgi.org

gunicorn.org/

projects.unbit.it/uwsgi/

irc.freenode.org/#gunicorn

nginx.org/

djangoadvent.com/

www.django-fr.org/

www.djangoproject.com/

webpy.org/

Je tiens à remercier la communauté Geek{node|fault}, le chan irc #gunicorn, les développeurs de gunicorn qui sont très aimables, ainsi que Amandarn qui m’a aidé pour certains détails.

Si vous avez aimé ce post...

1. Devbox KVM+Libvirt perfect setup.
2. Maildir mbox – La migration
3. Filtrer ses mails ! Un cauchemard !

Peut être l’avez vous remarqué ? Geekfault est désormais accessible totalement en IPv6 ! Sa superbe IPv6 2001:758:1664::42 en fait frémir plus d’un

Nous prévoyons d’ailleurs, avec LeCoyote (nouveau contributeur Geekfault), de vous parler en long et en large de ce protocole qu’internet sera bien obligé d’adopter d’ici quelques années.

ENJOY !

Si vous avez aimé ce post...

1. Geekfault recherche des partenaires
2. Difficultés techniques de Geekfault
3. IPv6 pour les nuls^Wgeeks

Nous allons voir comment installer un serveur Lighttpd (alternative à Apache), avec PHP sur un iPhone 2.2.1 jailbreaké.

Installation

Grâce à Cydia ou Icy, installez les packages suivants:

• OpenSSH un des indispensables du hacker iPhone, il lance un serveur SSH sur celui-ci (l’iPhone, pas le hacker xD)
• Lighttpd est le serveur HTTP à proprement parler. Très léger et sous license libre (BSD), c’est une très bonne alternative à Apache
• PHP: Hypertext Preprocessor que nous lierons à Lighttpd dans la configuration

Configuration

Redémarrez et connectez-vous en ssh à votre iPhone, le mot de passe par défaut est alpine.
ssh root@iPhone.local

D’abord créons tous les répertoires utiles:
mkdir /etc/lighttpd/ /etc/lighttpd/logs/ /etc/lighttpd/htdocs/

Configurons Lighttpd :
nano /etc/lighttpd/lighttpd.conf
server.document-root = "/etc/lighttpd/htdocs"
server.port = 80

#Configuration PHP
fastcgi.server = (".php" =>
("localhost" =>
("bin-path" => "/usr/bin/php-cgi",
"socket" => "/tmp/php.socket")
)
)
Lighttpd est bien sûr un serveur tout à fait standard largement utilisé sur le web : vous pouvez adapter sa configuration selon vos moindres désirs.

Lancer le serveur

Il ne reste plus qu’à lancer le serveur en une petite ligne de commande. Je n’ai pas trouvé d’interface graphique qui permette de le faire simplement.
lighttpd -f /etc/lighttpd/lighttpd.conf

Créons un petit fichier PHP pour voir si tout marche bien:
nano /etc/lighttpd/htdocs/index.php
< ?php $who = 'Geekfault';
echo 'Hello, '.$who.'.'; ?>

La configuration Lighttpd décrite ici permet de se connecter à votre iPhone avec tous les hostnames qui lui sont affectés: iPhone.local, localhost, adresse IP, …

MySQL ?

Il n’est malheureusement pas possible pour l’instant de faire tourner un serveur MySQL sur l’iPhone et, pire, le PHP proposé est compilé sans le mod_mysql, ce qui empêche même les connexion MySQL à un serveur distant.

Il faudra se contenter de SQLite. Dommage.

Source

Si vous avez aimé ce post...

1. Internet sur votre laptop via un iPhone
2. iPhone OS 3.0
3. Le “nouvel” iPhone 3GS

Tabs Open Relative

Cette première extension a un et un seul but: placer les onglets nouvellement créés à gauche de l’onglet courant. Pour que lorsque l’on navigue sur plusieurs sites différents on ne cherche pas pendant des heures l’onglet dont on a besoin.

Cette extension ne fait que ça. Ni plus, ni moins. Certains me diront que Tab Mix Plus le fais également, mais cette extension est, à mes yeux, une uzine à gaz.

Resizeable Textarea

Si, comme moi, il vous arrive d’écrire des messages assez longs sur des forums de discussion, ou d’écrire des pâtés sur vos divers profils, vous allez sans doute apprécier cette extension.

Elle permet à Firefox d’adopter le même comportement que ses concurrents basés sur Webkit: le coin en bas à droite des zones de textes (textareas) permet de redimensionner le textarea en question. Plus besoin de scroller pour avoir son argumentaire en un clin d’oeuil, pour avoir une vue d’ensemble de son commentaire. Un véritable plaisir.

Abondance de liens ne nuit pas

• L’extension Tabs Open Relative
• L’extension Tab Mix Plus
• L’extension Resizeable Textareas
• Webmasters: créer une zone de texte redimensionnable avec la bibliothèque AJS (Javascript).

Si vous avez aimé ce post...

1. Astuce Firefox : les Smart Keywords
2. Concours : deux jours d’accès à la Google Wave Sandbox
3. Synergy