J’ai trop attendu et le travail a été plus long que prévu car plein de choses avaient du coup changé dans le framework. Des petits détails, mais déjà tout le routing ne marchait plus.

N’oubliez pas que la branche master est en anglais, mais il y a une branche traduite en français. Les deux sont téléchargeables sous forme de zip sur la page d’accueil du projet github si vous ne souhaitez pas utiliser git. Il n’y a rien à installer : unzip, lire, lancer.

D’une manière générale, le projet est toujours très pratique pour enseigner ou apprendre les bases de django en complément des supports traditionnels. Il faudra que je rajoute la partie ORM un de ces 4.

Générer une clé secrète:

import random
import string

def secret_key(size=50):
    pool = string.ascii_letters + string.digits + string.punctuation
    return "".join(random.SystemRandom().choice(pool) for i in range(size))

Générer une clé secrete avec une commande manage.py:

from django.core.management.base import BaseCommand, CommandError
from polls.models import Question as Poll

class Command(BaseCommand):
    help = 'Generate a secret key'

    def add_arguments(self, parser):
        parser.add_argument('size', default=50, type=int)

    def handle(self, *args, **options):
        self.stdout.write(secret_key(options['size']))

A mettre dans ./votreapp/management/command/generate_secret_key.py :)

Une fonction pour lire la clé depuis un fichier texte ou générer la clé si elle n’existe pas:

import io
import os

try:
    import pwd
except ImportError:
    pass

try:
    import grp
except ImportError:
    pass


def secret_key_from_file(
        file_path, 
        create=True, 
        size=50, 
        file_perms=None, # unix uniquement
        file_user=None, # unix uniquement
        file_group=None # unix uniquement
    ):
    try:
        with io.open(file_path) as f:
            return f.read().strip()
    except IOError as e:
        if e.errno == 2 and create:
            with io.open(file_path, 'w') as f:
                key = secret_key(size)
                f.write(key)

            if any((file_perms, file_user, file_group)) and not pwd:
                raise ValueError('File chmod and chown are for Unix only')

            if file_user:
                os.chown(file_path, uid=pwd.getpwnam(file_user).pw_uid)

            if file_group:
                os.chown(file_path, gid=grp.getgrnam(file_group).gr_gid)

            if file_perms:
                os.chmod(file_path, int(str(file_perms), 8))

            return key

        raise

Et une fonction pour récupérer la clé depuis une variable d’environnement ou un fichier:

def get_secret_key(
        file_path=None, 
        create=True, 
        size=50, 
        file_perms=None, 
        file_user=None, 
        file_group=None,
        env_var="DJANGO_SECRET_KEY"
    ):
    try:
        return os.environ[env_var]
    except KeyError:
        if file_path:
            return secret_key_from_file(file_path, create=create, size=size)
        raise

Le but de cette dernière est d’avoir ça dans son fichier de settings:

SECRET_KEY = get_secret_key('secret_key')

Et de foutre ‘secret_key’ dans son .gitignore.

Comme ça:

• Si on n’a pas de clé secrète, on en génère une.
• Si on a une, elle est dans un fichier qui n’est PAS dans settings.py.
• On peut commiter settings.py. Chaque env de dev et prod a sa clé secrète automatiquement.
• On peut overrider la clé avec une variable d’environnement si on le souhaite.

En attendant, j’ai proposé qu’on ajoute ça a django extensions. Et qui sait, dans le core peut être un jour ?

Donc voici la traduction de celui-ci. Faites-vous plaiz’

Hey, mon boss m’a dit de venir te voir. Il paraît que tu gères niveau web apps ?

– Ouais, je suis plus un spécialiste des systèmes distribués maintenant. Je reviens du ContainerCamp et de la Gluecon et je vais à la Dockercon la semaine prochaine. Je suis emballé par la direction que prend l’industrie – tout est plus simple et fiable. C’est le futur !

Cool. Je veux juste faire une simple Web app pour le moment – un CRUD normal avec Rails, que je vais déployer sur Heroku. C’est toujours d’actu ?

– Oh non. C’est old school. Heroku, c’est mort – plus personne ne l’utilise. Il te faut Docker maintenant. C’est le futur.

Oh, OK. Qu’est-ce que c’est ?

– Docker est la nouvelle façon de faire de la conteneurisation. Comme LXC, mais c’est aussi un format de package, une plateforme de distribution et des outils pour rendre la création de systèmes distribués très facile.

Conteneuri.. – Hein ? C’est quoi LXE ?

– LCX. C’est comme un chroot aux stéroïdes.

C’est quoi cheroot ?

– Ok, regarde. Docker. Conteneurisation. C’est le futur. C’est comme la virtualisation, mais plus rapide et moins coûteux.

Oh, comme Vagrant.

– No, Vagrant c’est mort. Tout va être conteneurisé maintenant, c’est le futur.

Ok, donc je n’ai pas besoin de savoir quoi que ce soit sur la virtualisation ?

– Non, tu as quand même besoin de la virtualisation, parce que les conteneurs ne fournissent pas toutes les couches de sécurité pour le moment. Donc ce que tu veux, c’est faire tout tourner dans un environnement multitiers de telle sorte qu’on ne puisse s’échapper de la sandbox.

Ok, je suis un peu perdu là. On rembobine. Donc il y a un truc comme la virtualisation qu’on appelle les conteneurs. Et je peux l’utiliser sur Heroku ?

– Et bien, Heroku a un support pour docker, mais je viens de le dire : Heroku c’est mort. Ce que tu veux c’est faire tourner tes conteneurs sur CoreOS.

Ok, c’est quoi ?

– C’est un OS hôte très cool qu’on peut utiliser avec Docker. Tu n’as même pas besoin de Docker, tu peux utiliser rkt.

Rocket ?

– No, rkt.

Ouais, Rocket.

– Non, ça s’appelle rkt maintenant. Rien à voir. C’est un format de conteneurisation alternatif qui n’est pas aussi intégré que Docker par défaut, et donc plus composable.

C’est une bonne chose.

– Bien entendu. La composabilité c’est le futur.

Ok, ça s’utilise comment ?

– Je ne sais pas. Je ne pense pas que qui que ce soit l’utilise.

Arf. Tu disais quoi à propos de CoreOS ?

– Ah oui, c’est un OS hôte pour Docker.

C’est quoi un OS hôte ?

– Un OS hôte fait tourner tous tes conteneurs.

Tourner mes conteneurs ?

– Ouais, tu dois avoir quelque chose pour faire tourner tes conteneurs. Donc tu te crées genre une instance EC2, tu mets CoreOS dessus, tu lances le daemon Docker, puis tu déploies tes images Docker dessus.

Quelle partie est le conteneur ?

– Tout. Écoute, tu prends ton app, écris un Dockerfile, tu en fais une image locale, puis tu la push sur n’importe quel hôte Docker.

Ah, comme Heroku ?

– Non, pas Heroku. Je te l’ai dit. Heroku c’est mort. Tu gères ton propre cloud en utilisant Docker.

Hein ?

– Ouais, c’est tout simple. Check #gifee.

Gify?

– Google’s infrastructure for everyone else. Tu prends les outils que tu veux, avec des conteneurs, et tu as la même infra que Google.

Pourquoi pas juste utiliser celles de Google ?

Tu crois que ça sera encore là dans 6 mois ?

OK, mais est-ce que quelqu’un fait du hosting pour ça ? J’ai pas la foi d’héberger mon bordel moi-même.

– Et bien, Amazon a ECS, mais il faut écrire du XML et 2, 3 merdes.

Et OpenStack ?

– Beurk.

Beurk ?

– Beurk.

Écoute, j’ai vraiment pas envie d’héberger tout ça.

– Na, c’est super simple. Tu te setup juste un cluster Kubernetes.

J’ai besoin d’un cluster ?

– Un cluster Kubernetes. Ça gère le déploiement de tous tes services.

J’ai seulement un service.

– Qu’est-ce que tu racontes. Tu as une app non? donc tu as bien au moins 8-12 services ?

Quoi ? Non. Juste une app. Service, on s’en branle. Juste un truc.

– Non, jette un coup d’oeil à la notion de microservices. C’est le futur. C’est comme ça qu’on fait tout de nos jours. Tu prends ton app monolithique et tu la divises en quelque chose comme 12 services, un pour chaque tâche.

Ça semble excessif.

– C’est le seul moyen de s’assurer que c’est fiable. Ainsi si ton service authentification tombe…

Service authentification ? J’allais juste utiliser une gem que j’avais déjà mis en place plusieurs fois avant.

– Super. Utilise la gem. Mets la dans son propre projet. Fous une API RESTful par dessus. Et fait en sorte que les autres services utilisent cette API et gèrent gracieusement les échecs. Mets ça dans un conteneur et push le bordel en déploiement continu.

Ok, donc là j’ai une douzaine de services ingérables, et maintenant ?

– Ouais, d’où Kubernetes. Il orchestre tes services.

Orchestre ?

– Ouais, donc tu as ces services, ils doivent être fiables donc il t’en faut plusieurs copies. Donc Kubernetes s’assure que tu en as assez, et qu’ils sont distribués à travers de multiples hôtes dans ta flotte de serveurs, afin qu’ils soient toujours disponibles.

Ah parce qu’il me faut une flotte maintenant ?

– Ouais, pour la fiabilité. Mais Kubernetes la gère pour toi. Et tu sais que Kubernetes ça marche vu que Google l’a fabriqué et que ça tourne sur etcd.

C’est quoi etcd ?

– Une implémentation de Raft.

OK, c’est quoi Raft.

– C’est comme Paxos.

Putain, jusqu’où ça va le terrier du lapin blanc là ? Je veux juste lancer une app. Arf. Bordel, Ok, on respire. Fiou. Ok, donc Paxos c’est quoi ?

– Paxos c’est ce très vieux protocole de consensus distribué des années 70 que personne ne comprend ou n’utilise.

Super, merci de m’en avoir parlé. Et donc Raft ?

– Comme personne ne pige Paxos, y a ce mec, Diego…

Oh, tu le connais ?

– Non, il travaille a CoreOS. Bref, Diego a créé Raft pour sa thèse de doctorat, car Paxos était trop compliqué. Futé le gars. Et il a écrit etcd comme implémentation, et Aphyr a dit que c’était pas de la merde.

C’est quoi Aphyr ?

– Aphyr est le mec qui a écrit Call Me Maybe. Tu vois, le mec spécialiste des systèmes distribués et du BDSM ?

WUT ? BDSM ?

– Ouais, BDSM. C’est San Francisco hein, tout le monde est à fond dans les systèmes distribués et le BDSM

Hum, OK. Donc il a écrit cette chanson de Katy Perry ?

– Nan, il a écrit des posts sur son blog comme quoi toutes les databases n’atteignaient jamais le CAP.

C’est quoi le CAP ?

– Le théorème CAP. Ça dit que tu peux avoir des données consistantes, disponibles et tolérantes au partitionnement, mais qu’il faut choisir 2 de ces caractéristiques sur les 3.

Ok, et donc toutes les bases de données foirent CAP. C’est à dire ?

– Ça veut dire qu’elles sont à chier. Comme Mongo.

Je pensais que Mongo scalait ?

– Ben personne d’autre ne le pensait.

Ok, et etcd.

– Ouais, etcd c’est un système de stockage de clé/valeur distribué.

Oh, comme Redis.

– Non, rien à voir. etcd est distribué. Redis perd la moitié de ce que tu écris en cas d’échec réseau.

Ok, donc c’est un système de stockage de clé/valeur distribué. Pourquoi c’est utile ?

– Kubernetes setup par défaut un cluster de 5 nodes et utilise etcd comme bus de transport de messages. En combinaison avec quelques services de Kubernetes lui-même, ça fournit un système d’orchestration assez résilient.

5 nodes ? J’ai une app. Combien de machines je vais devoir prendre pour tout ça ?

– Et bien tu vas avoir environ 12 services, et bien sûr il te faut des copies de chaque pour la redondance, quelques load balancers, le cluster etcd, ta base de données, et le cluster kubernetes. Je dirais peut-être 50 conteneurs.

WTF ?!

– Aucun problème ! Les conteneurs sont vraiment efficaces, donc tu peux les distribuer sur genre, 8 machines. C’est pas incroyable ?

C’est une manière de voir les choses. Et avec tout ça, je vais être capable de simplement déployer mon app ?

– Yep. Je veux dire, la question du stockage est toujours en suspend avec Docker et Kubernetes, et la partie réseau va demander un peu de travail, mais techniquement, tu es à 2m du bol de sangria.

Je vois. Ok, je pense que j’ai pigé.

– Super !

Merci pour l’explication.

– No problem.

Laisse-moi faire un résumé pour voir si j’ai bien tout compris.

– Bien sûr !

Donc j’ai besoin de diviser mon app CRUD toute simple, en 12 microservices, chacun avec leur propre API qui s’appellent les uns et les autres, mais qui gèrent les erreurs de manière résiliente, les mettre dans des conteneurs Docker, lancer une flotte de 8 machines qui sont des hôtes Docker tournant sous CoreOS, les orchestrer avec un petit cluster Kubernetes qui tourne avec etcd, me démerder avec la question du réseau et du stockage, et je fais tout ça en déploiement continu pour de multiples copies redondantes des microservices de ma flotte. J’ai bon ?

– Yep ! C’est pas fabuleux ?

Je retourne sous Heroku.

En relisant l’article, je réalise deux choses :

• Putain il en faut des références rien que pour comprendre la blague. Plein de devs ne savent même pas ce qu’est Heroku.
• Et franchement cette parodie est vraiment gentille, dans la réalité cette stack pose beaucoup d’autres problèmes : il y a plus de trucs que ça, ça s’emboîte mal, les versions changent, la doc est merdique, faut former les nouveaux arrivants car personne ne connaît ces technos, y a plein de roues à réinventer, il faut un temps fou pour choisir les briques technos, etc. Mais on peut aussi utiliser Docker très simplement, avec un image, à la main, sous Ubuntu. C’est presque simple et pratique.

Le protocole WebSocket vise à développer un canal de communication full-duplex sur un socket TCP.

LOL. C’est clair non ?

Vous inquiétez pas, tonton Sam est là.

Le Web a évolué. On est passé de Gopher a HTTP 1 puis 1.1. Et on a eu AJAX pour rafraîchir la page sans tout recharger.

Et maintenant on a des apps complètes qui font des centaines de requêtes au serveur alors même que l’utilisateur ne change pas de page. D’ailleurs, je parie que plein de gens ne savent même plus ce qu’est une page…

Le problème c’est qu’AJAX, c’est toujours HTTP, et HTTP est sans état (stateless) : il ne garde aucune information en mémoire d’une requête à l’autre. Ça a des avantages, mais cela implique qu’à chaque requête, il faut ouvrir une connexion et la refermer. Ce qui bouffe quelques ms à chaque fois, et d’autant plus si on utilise SSL.

Une autre limite, c’est que le serveur ne peut pas envoyer de données au client (ici le navigateur) si le client ne fait pas une requête au préalable. Du coup, pour savoir si il y a quelque chose de nouveau, le navigateur doit régulièrement faire des requêtes au serveur ou utiliser des gros hacks comme le long polling.

Les websockets (c’est un abus de langage, on devrait parler du protocole Websocket) ont été créés pour répondre à ces besoins : elles permettent d’ouvrir une connexion permanente entre le navigateur et le serveur. Ainsi, chaque requête est plus rapide, et plus légère. En prime, le serveur peut envoyer des requêtes au navigateur pour le prévenir qu’il y a du nouveau.

Ceci permet de faire tout ce que permettait de faire AJAX mais en plus rapide, et en plus léger. Et également d’envoyer des notifications (ce contenu a changé, un message est arrivé, l’autre joueur a fait cette action…) au navigateur au moment où l’événement se produit.

En gros, de faire des apps Web quasi temps réel.

Il existe d’autre technos pour faire cela : applets Java, flash, comet, server sent events…

Mais aucune n’ont décollé. Websocket est donc aujourd’hui la solution de facto.

Caractéristiques

Le protocole Websocket utilise l’abréviation ws et wss si SSL, les URLs vers des endpoints websocket ressemblent donc à : ws://domaine.tld/chemin/vers/truc/.

Intelligemment, il utilise un handshake compatible avec celui de HTTP, permettant à un serveur de gérer les deux sur les mêmes ports. Donc on peut faire du Websocket sur le port 80 et 443. Néanmoins, certains proxy se gourent quand ils voient du websocket non chiffré et gauffrent votre connexion en la traitant comme du HTTP. Donc si vous voulez une app solide, investissez dans un certif SSL.

Tout ça fonctionne à partir de IE10. Notez comme IE est devenu le standard de ce qui ce fait de moins bien à tel point que je n’ai même pas besoin de vous parler des autres, vous savez que ça marche. Il existe en plus des plugins flash pour simuler des websockets sur les navigateurs anciens, c’est à dire les encore plus vieux IE.

Par défaut, les websockets permettent de faire de requêtes crossdomain, contrairement à AJAX. Avec les nouvelles apps qui utilisent NodeJS en local (comme popcorntime) on peut imaginer une nouvelle type d’attaque : une page web qui se connecte à un serveur websocket local de votre machine. Comme les websockets sont souvent utilisées pour du RPC, il y a du potentiel.

Bon, ta gueule, et montre le code

Vous noterez que ce qui prend du temps dans l’exemple c’est la connexion, qu’on ne fait qu’une fois. Ensuite l’échange de données est super rapide.

Ceci est un exemple Javascript, mais un client websocket n’est pas forcément un navigateur. En fait, c’est très précisément le cas avec WAMP, dont les clients peuvent être des programmes Python, Objective C, Java, C++, etc. L’avantage de WAMP, c’est qu’il automatise toute la machinerie pour découper la logique de son programme en divers fonctions et services, plutôt que d’avoir à tout faire à la main avec send() et onmessage().

Dans tous les cas, il vous faudra un serveur qui supporte les Websockets pour l’utiliser. En Python, c’est Tornado ou Twisted (sur lequel est basé le serveur WAMP crossbar). En Javascript, c’est NodeJS. Quoi qu’il en soit, il vous faut un logiciel qui gère l’IO de manière non bloquante, car il y a de nombreuses connexions ouvertes en simultanées, si on veut que ça soit performant.

Internet, c’est beaucoup plus que le Web. C’est SSH, IMAP, TELNET, DNS, POP, SMTP, FTP, RTSP, NNTP, Bittorent, TOR, Freenet, Bitcoin, et quelques centaines d’autres protocoles qui se parlent.

Jusqu’ici, le Web, c’était juste HTTP. Des ressources Web, sur lesquelles on agissait via une requête textuelle verbalisée (GET, POST, PUT, OPTION, HEAD, etc) et qui retournait une réponse, généralement en forme de HTML.

Ça a un peu évolué, on a eu SSL qui s’est rajouté, et donc HTTPS, et AJAX, qui n’a pas changé le protocole, mais rendu la nature des requêtes un peu différente. Rien qui n’empêche de debugger avec CURL.

Mais c’est bientôt fini tout ça.

Aujourd’hui les nouveaux protocoles utilisés dans le cadre du Web sont en passe de prendre le pouvoir. Bien sûr il y a SPDY et QUIC, mais surtout, il a les protocoles basés sur les websockets type WAMP.ws, mais également les nouvelles capacités P2P promises par WebRTC. Et des apps qui utilisent massivement les données hors ligne, le scripting JS pour des features essentielles, de la video, du son…

Et donc adios, l’époque où vous pouviez juste dégainer requests et parler à un site. Bye bye le state less, le human readable, le cycle requête / réponse.

Le nombre de technologies qu’on doit empiler aujourd’hui pour déployer un site devient énorme : un moteur de recherche, un message broker, un gestionnaire de fil d’attente, un gestionnaire de déploiement, des technos d’isolation…

C’est fini la simplicité. C’est fini la transparence. L’ère du hacker amateur qui pouvait s’occuper d’un peu de tout, touche doucement à sa fin.

Au revoir et merci. Je me suis super amusé.

Et désolé pour les mômes qui arrivent maintenant, vous allez en chier. Mais vous avez aussi plus de possibilités qu’il n’y en a jamais eu. Plus qu’un homme ne peut concevoir. Plus que tous les hommes en fait.

Et RIP HTTP. Ou pas, puisqu’on passe notre temps à faire des APIs REST maintenant, mais aussi car on est en train de récréer un peu tout au dessus d’HTTP. Long live HTTP, alors, le nouveau TCP/IP. Sauf quand on fait du real time. Ou du P2P. Changement de status : “c’est compliqué entre moi et mon navigateur”.

Internet, phagocyté par le Web, sur lequel on reconstruit Internet et même le desktop ?

Je ne crois pas qu’il existe un seul métier qui ait autant changé en 10 ans. J’espère qu’on en laisse pas trop derrière en courant comme des fous en riant les yeux mi-clos. Pourvu qu’il y ait pas trop d’arbres en face. Pourvu qu’on aille pas dans la direction de la falaise.

En tout cas, c’est toujours fun. Je crois que je vais descendre la prochaine pente en roulant sur le côté. Et avoir la tête qui tourne. Vomir. Et dire que c’est la faute de Javascript.

Et recommencer.

Tips : la commande bang pour ddg est !wfr pour la version française de wikipédia.

Quand vous cherchez un nouveau mot à la noix comme “lulz”, un truc cochon style “bukakke” ou une abréviation obscure du genre “GTFO”, vous n’allez pas la trouver dans le dico ou sur wikipedia. La meilleure source pour ce genre de terme : urbandictionry.com. En plus, c’est drôle.

Tips : la commande bang pour ddg est !ud

Vous voulez regarder un film ou une série en VO streaming mais elle n’est pas sortie en France ? Ou alors votre connexion bride ces fournisseurs ? Ou vous avez peur de vous faire choper ?

Allez sur les sites de streaming en espangol ! Ils listent les mêmes séries, le plus souvent en VO sous-titré ES, sur des hébergeurs différents complètement hors radar de nos tristes sires français. Et en plus, il n’y a pas de limite de temps ou de débit. Exemple : seriesyonkis et peli24.

Tips : évitez les séries doublées en espagnol comme la peste. C’est HORRIBLE. Dans stargate O’Neil a la voix de Teal’c et inversement…

Vous allez sur des sites de rencontre et vous voulez évitez les faux profiles ? Clic-droit sur la photo et enregistrez l’image sur votre bureau. Allez sur Google Image, et dans le champ, cliquez sur l’appareil photo pour uploader l’image.

Vous allez très vite voir si l’image a été réutilisée.

Effectivement, c’est bien foutu, c’est propre et lisible, et il y a du choix. Alors, partant quelques jours avec une copine en voyage, je me suis dis que ça se tentait.

A l’inscription, à la réservation, un long form à remplir, avec la carte à rentrer, la caution de 70 euros dans les dents, les frais que prend airbnb qui se rajoutent en dernière minute à la facture, etc. Bon, c’est du classique, pas de quoi en faire un fromage.

Là où ça se corse, c’est qu’APRES tout ce merdier habituel, je reçois une notification me signalant que ma réservation n’était pas envoyée.

WHAT ?

Et non ! Il faut maintenant passer par un stade de “vérification”, pour votre sécurité, messieurs-dames.

A chaque fois que je lis “pour votre sécurité” (sur les panneaux signalant les caméras, les radars, sur les formulaires, sur les contrats, etc), j’ai des envies de meurtre. Je voudrais trouver le mec qui a écrit ces lignes et lui faire bouffer sa connerie pour voir si elle a un goût de sécurité.

D’abord, uploader un document d’identité.

Arg.

Bon, admettons, le mec va t’accueillir chez lui, tout ça, ils veulent rassurer le chaland. Ça fait grincer les dents du voyageur que je suis ce lissage des pratiques, mais je me soumet à l’exercice. C’est comme ça qu’on appâte le main stream et qu’on a plus de choix, moins cher.

Next page, demande de photo de profile obligatoire, publique.

Mais fuck !

J’ai pas envie que mon nom, mon prénom (qu’ils m’ont demandé, et affichent sans me prévenir dans mon profile) et ma photo soient sur le net, bordel.

Je mets un avatar de merde en espérant que les modos le voient pas.

Mais attention, il y a encore deux étapes !!!

Étape 3, pour des raisons de sécurité de mes couilles, il faut lier un compte en ligne. Mais tu te fous de ma gueule ???

Je lies un compte de test qui me sert à rien, un compte gmail de spam. Ils demandent évidement la permission de gérer mes contacts, parce que bien sûr, c’est indispensable… Toujours effectuer une sodomie après un prélèvement sanguin. C’est pour votre sécurité.

Et pour finir, faire une vidéo de 10 secondes avec ma cam, me présentant.

VAS TE FAIRE FOUTRE !

(en plus leur applet flash ne marche sous aucun nav sous Linux)

La seule bonne nouvelle, c’est que la fonction “supprimer le compte” est facile à trouver.

Voici Sametmax.com en quelques chiffres pour les curieux:

Date de création: 4 février 2012
Articles: 505
Tags: 748
Commentaires: 6472
Premier inscrit: roro
Premier commentateur: roro le 2012/04/23 at 01:27
Tampons: 208
Spams: 33,249
Visites par mois: 100,862
Vistes depuis la création du blog: 837,446
Moteurs de recherche (par mois): 38,312
Mots clefs: masturbation feminine, fkk, freeplug, sex japon, abreviation escort, git stash, sublime text 2, ubuntu 12.10, node.js …

Les posts les plus vus:

Home page / Archives		201,116
Masturbation féminine – Un peu de théorie en vidéo		95,796
Synchroniser les freeplugs (les adaptateurs réseaux CPL de free)		33,993
Une journée dans un FKK (maison close Allemande)		32,124
Les Japonais et le sexe – des gros malades… Ou pas…		20,968
10 astuces pour Sublime Text 2		14,013
Les abréviations de la prostitution et des Escorts, vous connaissez ?		13,430
Il ne faut pas prendre des gens pour des cons mais ne jamais oublier qu’ils en sont		12,302

Le pognon que ça nous rapporte:

Non contents d’avoir asséché le trafic des autres blogs du net grâce à nos articles sulfureux écrits d’une plume féérique nous avons également pulvérisé tous les records précédents en terme de monétisation.

Depuis que Sam a mis Flattr sur S&M on a récolté 45€. Ce qui paie le serveur (environ 5€/mois en VPS chez leaseweb).

Si vous voulez d’autres chiffres demandez-nous et nous les rajouterons.

Allez voir le premier post par nostalgie ;)