wOueb by Romain DECKER / Another IT Guy Blog

Lorsque je prépare d’importantes modifications pour mon blog, je travaille sur une autre instance de WordPress, une « copie » installée dans un autre répertoire.

Pour éviter que les moteurs de recherche n’indexe ce répertoire (donc du contenu dupliqué) ou que des utilisateurs n’y accède, je restreins l’accès avec des règles basées sur mon adresse IP.

Voici le contenu de mon fichier .htaccess (à uploader à la racine du répertoire à protéger) :

Deny from all
Allow from 123.123.123.123

La première instruction indique qu’il faut refuser toutes les visites, et la seconde me permet d’autoriser mon adresse IP (vous pouvez dupliquer cette ligne pour rajouter d’autres adresses).

Ces instructions ont pour effet d’afficher une erreur 500 à toutes les autres personnes que moi.

Cependant, une solution plus propre consiste à rediriger automatiquement tout le trafic à la racine du blog en fonction des adresses IP : pour cela, il faut utiliser une règle de réécriture d’url.

RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^123\.123\.123\.123
RewriteRule .* http://www.woueb.net [L]

L’explication en détails :

1. Le module de réécriture d’url est activé,
2. Une condition est définie : « toutes les IP autres que 123.123.123.123″,
3. On réécrit l’url suivant la règle suivante : « pour toutes les pages du site, et pour toutes les personnes définie par la condition, le visiteur est renvoyé vers www.woueb.net »

Voilà, je ne sais pas si tout le monde a suivi, mais j’espère l’avoir expliqué assez simplement !

Note : comme le souligne Aestyle dans son commentaire, il faut que votre hébergeur ait le module URL Rewriting d’activé au niveau du serveur.

Les tests de performances hardware ne se comptent plus : tous les produits qui sortent sont testés, re-testés, encore et encore.

Pourtant, plus de 95% des éditeurs (de sites ou d’applications en ligne) ne pensent pas à faire des tests de performance, ou ne savent pas comment faire.

Or, il arrive que certains sites ne répondent plus lors de grosses affluences : ce phénomène s’appelle « Slashdot Effect« .

Slashdot effect : désigne le fait qu’un site internet soit submergé de requêtes provenant d’utilisateurs de Slashdot (ou Digg/Techcrunch) au moment de la publication d’une nouvelle le référençant, le rendant ainsi momentanément indisponible par déni de service (Wikipedia).

Vous vous souvenez de l’indisponibilité de Pownce ? Voilà un bon exemple d’un buzz qui a parfaitement fonctionné, mais d’une infrastructure qui ne tenait pas la route.

Un cauchemar, non ?
Vous lancez une application susceptible d’intéresser des milliers d’utilisateurs, vous buzzez autour, mais celle-ci est indisponible.

(suite…)

J’en parlais hier, et au courant de la nuit Xinu a fermé : un mot de l’auteur nous indique que le projet prenait trop d’ampleur pour lui, et il signale qu’il publie le code source.

Plusieurs personnes m’ayant fait la réflexion de n’avoir pas pu tester Xinu, je l’ai installé sur mon hébergement.

Vous le trouverez à l’adresse : http://www.woueb.net/xinu/

Le service restera en ligne tant que l’hébergement tiendra : si jamais je vois un problème, je restreindrai l’accès.

Xinu, toutes les statistiques de site / blog

Découvert sur Techcrunch, Xinu est un service qu’il faut conserver dans ses favoris.

Il permet de regrouper en une seule interface toutes les informations utiles à votre site :

• informations sur l’hébergement,
• les différents ranking (PR, Technorati, Alexa, etc.),
• des statistiques sur le nombre d’abonnés Feedburner,
• le nombre de pages indexées, ainsi que le nombre de liens entrants sur les différents moteurs de recherche,
• etc.

L’interface n’est pas des plus esthétiques, mais le service me séduit par sa simplicité et l’intérêt des données.

Malgré tous ces points positifs, il manque quelques points à Xinu pour devenir parfait :

• pouvoir créer un compte pour avoir un historique,
• pouvoir rajouter des API soit même (tous les compteurs ne sont pas probant pour des sites francophones).

Testez Xinu !

J’ai eu récemment à faire des recherches (dans le cadre professionnel) sur la taille moyenne des mails (sans inclure les spams), et le résultat est plutôt étonnant.

J’ai basé mon étude sur trois axes :

• la recherche d’informations sur des études existantes,
• une vérification sur la taille moyenne des spams,
• un calcul à partir de nos propres serveurs de mails.

Recherche de données sur la taille moyenne des mails

Contrairement à ce que je pensais, aucune étude récente et sérieuse n’est disponible : celles-ci portent en général sur la taille d’internet, le nombre de site existants, le nombre de pages, etc., mais rien sur les mails (ou alors j’ai vraiment mal cherché)…

Les seules études que j’ai trouvé ont été faites par l’Université de Berkeley :

• How Much Information in 2000 ? : 18,5 Ko par mail
• How Much Information in 2003 ? : 59 Ko par mail

En extrapolant (le nombre de mails envoyés a doublé depuis 2003), et en prenant une marge de sécurité, j’estime que la taille moyenne actuelle d’un mail doit se situer entre 80 et 100 Ko (toujours en dehors des spams).

Vérification de la taille moyenne des spams

Quels organismes pourraient faire des statistiques sur la taille des spams ?

Tout simplement, les entreprises qui offrent un service de filtrage anti-spam !

Je découvre donc chez Softscan que la taille moyenne actuelle est de 11,76 Ko par spam, cette valeur ayant tendance à augmenter fortement (Source : Vnunet).

Calcul à partir de nos propres serveurs

Enfin, puisque j’en avais les moyens, j’ai utilisé les logs mails sur nos propres serveurs mails, pour une semaine de données.

Les résultats suivants sont ressortis :

• 94 048 mails,
• 5,51 Go de données,

Une règle de trois plus loin, la moyenne nous donne 58,6 Ko par mail.

Pourquoi diable retrouverais-je le même chiffre qu’une étude officielle en 2003 ?

Ne pas se fier aux chiffres…

…car mes 94 048 mails n’ont pas été filtré en amont, et qu’ils contiennent du spam.

Selon l’institut IDC, 41% des mails dans le monde seraient des spams (Source : Vnunet).

En reprenant mes données, et en enlevant 41% du nombre total de mails, je peux refaire un nouveau calcul : je tombe alors sur 91,1 Ko par mail.

On aurait pu croire que l’augmentation allait être linéaire, mais pas du tout : je pense que les nouveaux services du web2.0 incitent les utilisateurs à publier leurs contenus multimédias en ligne (photos, vidéos, présentations) plutôt que de les envoyer par mail.

Si quelqu’un à une remarque sur mon calcul, ou d’autres données à me soumettre, n’hésitez pas à commenter!

Note : il faut certainement prendre une marge de sécurité de 10 % à 20 % mais je pense que le chiffre obtenu (91,1 Ko par mail) est assez représentatif pour la France.

Suite au dîner avec Gonzague à Luxembourg, j’avais proposé à qui le voulait de boire un verre à Strasbourg.

Quelques personnes ont de suite répondu à l’appel, et une rencontre s’est improvisée assez rapidement (3 jours), avec :

• Gilles de leGizz Blog,
• Mike qui avait fait le trajet exprès depuis le Mexique accompagnée d’une amie,
• Sacha, ancien collègue et également blogueur.

(Il manquait juste Fran6 qui n’a pas pu nous rejoindre…une prochaine fois certainement !)
Nous nous sommes retrouvés au Mooze à Strasbourg, et avons parlé de choses et d’autres, de Basecamp, de web 2.0, de blogging, etc., sans vraiment avoir de fil directeur.

J’ai été très content d’échanger avec vous, et regrette vraiment d’avoir du partir aussi tôt dans la soirée !

Sacha nous ayant convaincu, Gilles et moi nous sommes inscrits au prochain BarCamp en Alsace.

Note : si quelqu’un d’autre veut prendre un verre avec moi, je suis toujours preneur, il suffit de me prévenir !