Je me tire pour deux semaines.

Pas d’articles.

Pas de comments.

Bisous.

Tout foire tout le temps. Le site (ou app) sans erreur n’existe pas. Après chaque mise à jour on croise les doigts et on espère que tout va bien se passer.
Les plus courageux auront fait des tests unitaires en amont qu’ils lanceront avant l’update, les autres comme moi vont commiter leurs changements et redémarrer le serveur prod. On est boucher de père en fils dans la famille…

Avant toute chose Sentry qui avant était un projet Django serveur/client a depuis évolué et est devenu un serveur uniquement, laissant le choix du client suivant votre framework/language de travail. Sentry est disponible sur à peu près toutes les plateformes (Python, PHP, Ruby, JavaScript, Java, Node.js, iOS) et les frameworks Rails et Django. La documentation est très fournie et le projet très actif.

Dans le cas d’un site web en général on a tellement de pages qu’on ne peut pas prédire à l’avance ce qui va foirer ou pas (mais ça foire toujours, tout foire, etc…). Même si vous avez fait les tests unitaires vous aurez forcément oublié quelque chose.

Cette page spéciale sur les nains obèses unijambistes scatophiles pour lesquels vous avez créé un tag unique et qui ne supporte pas que vous ayez changé votre mode de cache va lamentablement planter et vous priver de la fidélité de DSK sur votre site pour longtemps.

Heureusement nous allons pouvoir logger toutes ces erreurs et avoir des jolis graphiques post-mortems. Bien évidement ça va vous faire du taf en plus bande de feignasses.

Sentry vient en standalone ou en version gratuite limitée, hebergée par les créateurs.
J’ai voulu installer la standalone parceque je revenais de l’apéro et qu’au 8ème Ricard on veut tout faire soit-même mais la raison et 14heures de sommeil l’ont emporté, c’est à mon réveil que je me suis alors décidé à installer la version trial limitée à 7 jours de log et 2800 evenements loggés (qui au passage suffit sur un de nos plus gros site).

la mise en place est vraiment des plus simple:

Créez un compte et ensuite récupérez la clef API dans les préférences sur votre compte en ligne Sentry.

Du côté de votre projet Django:

Installez Raven, qui est un client python pour Sentry. Il va se charger collecter vos erreurs et les transmètre à Sentry.

Comme d’habitude une bonne PIP:

  pip install raven

Dans le fichier settings.py de votre projet Django:

Utilisez la clef Api fournie par Sentry (voir plus haut)

# used for sentry login
RAVEN_CONFIG = {
    'dsn': 'https://aboudouboudousplish:aboudouboudousplash@app.getsentry.com/1984',
}

Vous pouvez faire un test pour voir si tout est bien configuré:

Dans votre projet Django tapez

python manage.py raven test

Vous devriez recevoir un email de Sentry avec le récapitulatif du test raven.

L’interface Sentry:

La liste des évènements avec possibilité de filtres.

Sur le flux vous allez avoir la liste de tous les évènements loggés, vous pouvez les trier en choisissant parmi une plétore d’options. Vous pouvez nettoyer ce flux en un seul clic (lors d’un redemarrage de serveur vous risquez d’avoir beaucoup d’erreurs qui n’en sont en fait pas, donc inutile de les traiter).

L'évènement en détail, une clarté qui donne envie d'avoir des bugs ^^

Chaque évènement du flux a une vue détail où vous allez pouvoir tracer le bug, c’est clair et plein d’informations (un peu comme les pages de debug Django). Il y a la possibilité d’ajouter des notes, de relancer la requête afin de vérifier la correction effectuée.

Le mode Team:
Sentry vous permet de bosser en équipe, vous créez un projet, des utilisateurs et chacun peut monitorer, corriger des bugs etc (pas dispo dans la version trial). Vous pouvez aussi créer des groupes d’utilisateurs qui n’auront accès qu’à certains projet. Le côté équipe a bien été intégré. Vous saurez sur qui gueuler lorsque le bug aura été mal corrigé.

Conclusion:
Monitorer ses apps est un vrai calvaire quand on n’a pas les bons outils ou que ces derniers sont chiants à installer/maintenir.
Sentry offre deux possibilités d’installation et leur mode trial vaut vraiment le coup (gratuit je le répète), les plus courageux se farciront l’install.
Pour la version standalone j’ai lu un peu partout qu’il était préférable de l’installer sur un serveur à part, à méditer avant de se lancer. Les logs sont en temps réél, vous n’avez pas à attendre le lendemain pour savoir ce qui a planté la veille, vous pouvez donc corriger vos bugs rapidement.

Le plus gros problème de Sentry je pense c’est qu’on tombe accroc, je m’y rend désormais plusieurs fois par jour pour voir si il n’y a pas un petit bug à corriger :)

PS: je cherche l’équivalent pour monitorer les serveurs, Munin est trop vieux et tous les autres outils que j’ai pu tester demande à installer (entendez passer des heures à compiler) toute une machinerie. L’idéal serait des paquets à installer sur les serveurs à monitorer + service en ligne à la Sentry.

Il n’est jamais trop tard pour se reprendre en main et aller dans la bonne direction.

J’étais en train de me faire draguer par une copine de mon coloc plutôt rondoudou que pikachu quand je me suis fait la réflexion que toutes les rondes avec qui j’avais couché avait été de super bon coups.

Ça va faire raler Max, parce que lui il n’aime que les anorexiques. Il a bon goût en la matière ceci dit, et on se rejoint tous les deux sur les africaines, alors ça compense.

Par contre ça va plaire à Réchèr qui est très BBW.

Bref, 5 raisons de passer le permis poids lourd…

Elles se donnent au max

Et oui, elles font des efforts. Comme dit le dicton : “De mémoire de marin, a jamais vu une baleine faire l’étoile de mer.”

Ce dicton n’existe absolument pas et je l’ai complètement inventé.

On a pas peur de taper dans le fond

Il y a des filles, on a peur de les casser en deux. Et d’autres, on peut partir en rodéo en levrette. Or, comme l’énergie cinétique c’est 1/2 de mv carré, avoir un corps résistant pour absorber le choc est un avantage non négligeable.

Elles ont la langue super entrainée.

Les grosses sucent super bien. C’est un cliché. Je ne suis pas un échantillon représentatif.

Mais bon, je défend l’idée. On est sur internet, si je dis une connerie se sera diluée dans la masse de toute façon.

Elles ont des seins idéaux pour la branlette espagnole

Le bonnet F a plein d’avantages. On peut y plonger la tête dedans. On peut y insérer divers choses. On peut faire sa muscu avec.

Elles cuisinent bien. Et moi après, j’ai souvent faim.

Parce que le cul et la bouffe, c’est indissociable.

Et je ne dis absolument pas ça parce que j’ai pris du poids dernièrement.

La semaine prochaine on vous expliquera pourquoi brouter de la rousse est bon pour la peau.

Ca fait un bout de temps que les amateurs des claviers virtuels sautillent en criant que le mobile va remplacer le PC.

Ce mois ci la version mobile d’un site de cul de Max vient de rapporter plus d’argent en pub que la version Desktop.

C’est arrivé.

Donc c’est parti pour une énième reconversion de vos skills.

Aiguisez vos talents de responsive designer. Developpez le site pour mobile en premier, puis étendez le aux tablettes et enfin aux écranx 1024 pouces et plus. Servez-vous un red bull, ça fera passer le goût du guronsan.

Je sais vous venez tout juste de finir d’apprendre les animations CSS3, le localStorage, les nouveaux tags HTML 5 et les websockets. Vous vous disiez que vous pouviez encore attendre un peu. Faire une petite pause quoi, merde. Peut être le temps d’essayer un autre langage pour le fun ?

Nope.

Au boulot !

Et n’oubliez pas, la prog asynchrone, le WebRTC, les nouveaux frameworks comme angularjs, bref, le real time Web, est en train de monter aussi. Et demain, sûrement, les clients ne voudront plus que ça.

Au passage, vous vous souvenez comme dans les années 2000 tout le monde se touchait sur le code xHTML valide, accessible pour les handicapés ? Tout le monde s’en tape maintenant. Il n’y a pas une app new gen qui soit blind-friendly.

Bref, comme toujours, entre bonne conscience et pédance, il n’y a qu’un pas.

J’ai regardé le mouvement NoSQL évoluer au fil des années. On y retrouve à peu prêt tout ce qui fait l’informatique depuis que le monde IT est monde : brillance et troll, hype et génie, utile et gadget, buzz et fact, sam et max, etc.

De plus on peut mettre à n’importe quoi sous le label NoSQL, et du coup ça a été fait. En fait un fichier est déjà une base de données NoSQL :)

Mais rant mise à part, des projets comme redis, riak, elastic search ou mongodb changent vraiment la donne.

Malheureusement, tout comme d’autres technos du moment (prog asychrone, tout-http, pre-processeurs, generateurs…), les gens ont tendance à l’utiliser comme la barre de fer, la silver bullet, le passe partout, le tournenis sonique, bref, le truc à tout faire.

L’adage populaire dit “quand on a un bon marteau, tous les problèmes ressemblent à des clous”. Or, je constate qu’au dessus de ça, les dev appliquent aussi souvent le dicton préféré d’un de mes colocs : “arrête de taper si fort, prend un plus gros marteau”.

Ca donne du NoSQL utilisé partout, pour tout, brandi comme LA solution, vendu à des débutants comme une panacées de traitement d’informations. Zob, vous vous doutez bien que ça pose problème, non ?

Anti-fact 1 : NoSql, c’est plus facile pour démarrer

Il n’existe pas à l’heure actuelle de base NoSQL embarquée qui arrive à la cheville de SQLite : ça marche partout, dans tous les langages, sans rien à avoir installer ou configurer pour la plupart des langages.

Dès que vous demandez à un débutant d’installer un truc, vous rajoutez une barrière d’entrée énorme.

De plus, il y a beaucoup, beaucoup, beaucoup plus d’hébergeurs qui fournissent du SQL que du NoSQL en solution par défaut. Et comme toute les technos legacy, il y a 100 fois plus de doc.

Enfin, il y a la fameuse question du “quoi” ? Quel système allez-vous installer ? Couch ? Casssandra ? Mongo ? On parle de NoSQL, ou de schemaless ? C’est pas la même chose ? Memcache et Redis, c’est que pour le cache ? Elastic Search, c’est que pour la recherche de texte ? Les données géographiques, je les mets dans quoi, mongo ou un GIS spécialisé ? Attend, j’ai entendu parlé d’une super bdd de graph…

L’abondance de solutions, le manque de recul et les informations contradictoires disponibles rendent non seulement le choix difficile, mais en plus hasardeux. Car contrairement au monde du SQL, se gourrer en NoSQL peut vous pourir toute votre archi.

Souvenez-vous qu’il est beaucoup plus difficile de migrer son système de base de données NoSQL d’une solution à une autre car il n’y a pas ce petit détail en commun entre les produits : le SQL justement.

Anti-fact 2 : Avec NoSql, pas besoin de réfléchir à son modèle de données

Je crois que c’est ce qui me fait le plus grincer des dents. Les gens qui disent qu’on peut tout mettre dedans, hop, et on verra plus tard. J’ai vu les pires modèles de données possibles stockés en MongoDb ou Redis, parceque les gars qui avaient travaillé dessus avait juste dumpé leurs données sans réfléchir.

Une base NoSQL ne vous oblige pas à formaliser votre schéma, mais ça ne veut CERTAINEMENT PAS dire qu’il ne faut pas le faire. L’auteur de Redis a très bien expliqué le problème (je graisse pour donner une effet dramatique et puissant au message) :

Redis is not the kind of system where you can insert data and then argue about how to fetch those data in creative ways. Not at all, the whole idea of its data model, and part of the fact that it will be so fast to retrieve your data, is that you need to think in terms of organising your data for fetching. You need to design with the query patterns in mind.

C’est vrai pour tout système dans lequel on met ses données, SQL, NoSQL, fichier, mémoire, le tirroir de votre bureau…

Il faut penser au type des données, leurs formats, les relations entre les éléments, comment et à quelle fréquence vous allez les écrire, les lire, garantir la consistence de leurs relations et leur fraicheur (ou pas d’ailleur, mais il faut en faire le choix). Les bases SQL sont contraignantes parce qu’elles vous obligent à penser, dès le début, en ces termes.

C’est vrai, vous êtes de grandes personnes, a priori vous savez ce que vous faites, vous n’avez pas besoin qu’on vous FORCE à le faire. C’est pour ça que j’aime le typage dynamique. Je ne veux pas que tu me demandes mes papiers pour déclarer une variable, je sais ce que je fais.

Seulement il faut le faire, et ce n’est souvent pas fait. Pire, le modèle n’est généralement jamais formalisé NUL PART. Un schéma, c’est une doc. Sans doc, le coût d’entrée dans votre projet est élevé, sa maintenance est galère, le potentiel de bug lors de l’évolution est plus grand. Mais une doc c’est chiant à écrire et à tenir à jour.

C’est un des interessants effets secondaires des ORMs : les classes de définition sont le modèle documenté dans sa structures, ses relations, ses limites, ses contraintes, ses tests et vérifications, etc. La doc par le code, j’adore.

Anti-fact 3 : NoSql, c’est plus performant

A chaque fois qu’on lit “x est plus performant que z”, il faut faire une pause et réfléchir deux minutes. Généralement il y a un piège.

Les performances, ça dépend toujours du contexte. Par exemple, Redis est plus performant à la lecture et l’écriture, mais les données doivent tenir en RAM, sinon ça bouffe sur la mémoire virtuelle. Autre chose, Redis est très lent à démarrer sur des gros jeux de données (ça peut aller à plusieurs minutes si vous avez des Go). MongoDB doit normalement pouvoir tenir une augmentation de charge de manière prédictive en rajoutant des noeuds. Mais sur un seul noeud, c’est toujours moins performant qu’un PostGres. Et 0.01 % des sites ont besoin de plus d’un serveur.

Par ailleurs, les performances sont très dépendantes de l’anti-fact 2. Il faut créer les bons index, avoir un cache correctement ajusté, faire des requêtes intelligentes. Pour tous les systèmes.

Bref, encore une fois, NoSQL n’est pas une techno magique. Il est contre-productif, et j’ai envie de dire même irrespectueux envers ses collègues, de la vendre comme telle.

Anti-fact 4 : NoSQL remplace le SQL

Tweeter tourne sur MySQL ET Memcache.

Stackoverflow utiliser SQL Server 2008 ET Redis.

Il y a carrément des sites qui utilisent PostGres et MongoDb en parallèle. En fait, il y a des outils pour les faire collaborer.

Nous sur notre plus gros site on utilise Redis pour les sessions, les compteurs, les crawlers, les queues et passer des données entre process. Pas juste pour le cache. On utilise PostGres pour les données complexes avec des queries lourdes. Et on utilise Solr pour le moteur de recherche.

Les bases NoSQL sont des nouveaux outils, qui sont mieux adaptés à CERTAINS usages ou à CERTAINS contexte. Pas tout, tout le temps, partout. C’est un outil en plus, pas un obligatoire remplaçant.

Par ailleurs, on peut utiliser PostGres comme une base de données clé-valeur ou JSON, on peut mettre SQLite complètement en mémoire vive, on peut utiliser MySQL comme un moteur de recherche de texte… Multiplier les points of faillures dans une archi n’est pas toujours une bonne idée. Ces outils qu’on considère comme de l’histoire ancienne ont beaucoup plus de ressource que vous ne l’immaginez. Ils sont ultra performant. Des années et des années d’optimisation.

Le monde de la tech n’est jamais lisse. Jamais.