Votre utilisateur est en train d’écrire un commentaire, upload un ficher ou fait un truc quelconque qui n’est pas terminé. Puis il clique sur “fermer l’onglet”.

Dans certains cas, vous voulez lui demander confirmation pour éviter qu’il perde tout son travail.

var confirmOnLeave = function(msg) {
 
    window.onbeforeunload = function (e) {
        e = e || window.event;
        msg = msg || '';
 
        // For IE and Firefox
        if (e) {e.returnValue = msg;}
 
        // For Chrome and Safari
        return msg;
    };
 
};
 
// message de confirmation générique du navigateur
confirmOnLeave();
 
// message de confirmation personnalisé
confirmOnLeave('Vous allez perdre votre travail, êtes vous sûr(e) de vouloir quitter la page ?');

Quand vous appelez la fonction confirmOnLeave(), le callback de l’événement ‘onbeforeunload’ va être remplacé par une nouvelle fonction. Vous pouvez appeler cette fonction n’importe quand, l’événement ne se déclenche que quand l’utilisateur quitte la page de toute façon.

Cette fonction ne fait que retourner un message et assigner le message à l’attribut returnValue.

La navigateur va réagir ainsi:

• À la fermeture de la page, il va déclencher l’événement ‘onbeforeunload’.
• Au déclenchement de l’événement, il va appeler le callback.
• Le navigateur va ensuite regarder la valeur de returnValue. Si elle n’est pas undefined, il va demander confirmation à l’utilisateur avec une pop up.
• Le contenu de la pop up dépend de returnValue. Si c’est une chaîne vide, c’est un message générique, sinon, c’est le contenu de la chaîne qui est affiché.

Dans la plupart des cas, cette fonction suffit. Mais si vous utilisez d’autres codes JS qui ont besoin aussi de réagir à ‘onbeforeunload’ (comme par exemple pour faire un autosave), dans ce cas il vaut mieux utiliser utiliser une gestion avancée d’attachement de callback a des événements (pour qu’ils ne s’écrasent pas les uns les autres). Vous pouvez coder ça à la main, ou juste utiliser celui de jQuery qui fait ça très bien:

$(window).bind('beforeunload', function(){
    ...
});

Vendredi Max, dans un élan d’ébriété motivatoire, s’est lancé dans la rédaction d’un sujet qui lui tenait à cœur sur le moment “Limiter la gueule de bois après une cuite”.

Il a donc tapé l’article suivant, que je vous fais partager dans son intégralité :

aspirine avt de dormir
1 litre d’eau

Ensuite il a dévasé comme une merde toute la journée en me promettant qu’il allait le publier.

Je redécouvre ce concentré de génie en navigant les drafts, je pense qu’on doit pouvoir en faire un haiku.

Sam.

Le logiciel Bitcoin-QT, le client le plus utilisé pour échanger des BTC actuellement, sauvegarde toute sa configuration dans un dossier ~/.bitcoin.

Voilà ce qu’on trouve dedans:

Le chaine de block. Tout l’historique des transactions Bitcoin depuis le lancement du projet. Ça tient dans deux dossiers :

• chainstate
• blocks

Plusieurs Go. Si vous supprimez ces dossiers, vous en avez pour des heures à tout télécharger avant de pouvoir faire une transaction. Mais une fois je l’ai fais, et j’ai gagné 3Go de place car le format de stockage avait changé entre deux version du soft (c’est encore un projet beta, ne l’oubliez pas).

Il existe des clients lites rapides et légers qui ne stockent pas la chaîne en entier pour les gens qui s’en branle d’être un nœud de transfert dans le projet et qui veulent juste que ça marche maintenant tout de suite. Je préfère participer au réseau.

Ensuite il y a le carnet d’adresse. Si vous le supprimez, vous ne risquez rien, mais toutes vos transactions seront listées comme une suite d’adresses Bitcoin au lieu des noms que vous leur aviez donner. En plus ça prend pas de place, donc gardez les.

• addr.dat
• peers.dat

Si vous êtes paranos, ces fichiers contiennent des informations qui permettent d’aider à l’identification des participants à Bitcoin.

Puis viens le fichier le plus important. Le porte monnaie :

• wallet.dat

C’est votre identité. Si vous le perdez, adieu les bitcoins. Si on vous le vol, on vous vol vos bitcoins. Il ne pèse pas lourd, donc faites en un backup chiffré (une fois suffit, le fichier ne change jamais). Le contenu de ce wallet marche pour tous les clients.

Le client Bitcoin-QT permet de chiffrer automatiquement le wallet, mais ce n’est pas activé par défaut. Attention, une fois j’ai oublié mon mot de passe, et j’ai faillit tout perdre. Heureusement j’avais un backup.

Chez moi tout le dossier .bitcoin est sur une partition TrueCrypt. Une couche de sécurité de plus. C’est du pognon après tout.

Finalement vient les fichiers de log. Supprimez ça sans peine, tout le monde s’en branle.

• db.log
• debug.log

Et entre parenthèses, il y a ces fichiers qui servent au fonctionnement interne du client. Je n’ai aucune idée de ce qu’ils font ou à quoi ils servent :

• database
• DB_CONFIG

Ce qui est cool avec nginx, c’est qu’il peut très facilement se compiler avec pleinnnn de modules additionnels.

Par exemple, pour le compiler avec le support du scripting en Lua et des URLs sécurisées jetables :

set -ex
 
cd /tmp
 
# on installe quelques dépendances, exemple sous Ubuntu
sudo apt-get install libgpgme11 libgpgme11-dev git-core
 
# on récupère le codes modules additionnels
# très souvent dispo sur github, c'est la fête !
git clone https://github.com/chaoslawful/lua-nginx-module
git clone https://github.com/WebServer-Tools/nginx-accesskey-module.git
 
# on dl les sources de nginx lui même
wget http://nginx.org/download/nginx-1.2.6.tar.gz
 
tar -xvf nginx-1.2.6.tar.gz
 
cd nginx-1.2.6/
 
# on compile nginx avec les modules, on inclut aussi le support de gzip
# vu que c'est une config web, et on lui dit de mettre l'exe
# dans /usr/local/nginx
./configure --prefix=/usr/local/nginx --with-http_gzip_static_module --add-module=/tmp/lua-nginx-module --add-module=/tmp/nginx-accesskey-module 
 
# et on lance la compilation
make
sudo make install

Et voilà, un nginx tout neuf. Bon derrière, il faut modifier le fichier /etc/init.d/nginx pour qu’il démarre votre nginx custo, et pas celui des packages.

Juste pour dire que c’est facile à faire. Y a pas 40 000 dépendances, on a des features très étonnantes disponibles dans les modules, et on peut faire des configs différentes pour chaque type de serveur.

Joie.

Bilou, je veux bien te répondre, mais ton adresse me donne une “Delivery Status Notification”

Salut les gars,

J’ai cru comprendre que vous avez des sites de vidéos, vous vous
démerdez comment pour envoyer la vidéo en streaming tous en l’encodant.
Par exemple j’ai des mkv qui doivent être passer en mk4.
Une petite idée ?

Merci d’avance,

Yop,

On encode pas à la volée. On a des workers (powered by kombu) avec des files d’attente qui encodent les videos avec ffmpeg, et qui déclarent quand elles sont prêtes. Derrière on streamp tout ça avec nginx.  Ca demande beaucoup de tests (il n’y a pas de commande magique car ça dépend de ta cible client), et surtout, des disques durs énormes pour stocker tout ça.

Pour ton cas particulier, n’oublie pas qu’il y a 3 choses à prendre en compte:

• le codec video (h264, mpeg-2, etc)
• le codec audio (mp3, aac, etc)
• le conteneur (mkv, avi, mov, etc)

Donc il ne s’agit pas juste de streamer (c’est le plus facile, il suffit de compiler nginx avec l’extension qui va bien et payer un bon serveur), mais bien de trouver la combinaison des 3 qui corresponde à sa cible. Tester si on vise : le HTML5 ? Un lecteur flash ? Un truc lisible sur téléphone mobile (et quels modèles… ?). Quelle définition ? Quelle bande passante ? Quel traffic ?