PROJET AUTOBLOG


Sam & Max: Python, Django, Git et du cul

Site original : Sam & Max: Python, Django, Git et du cul

⇐ retour index

Mobile First

dimanche 23 mars 2014 à 18:59

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.

flattr this!

NoSQL : arrêtons de dire n’importe quoi

samedi 22 mars 2014 à 11:26

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.

flattr this!

Solution de l’exo la modif de flash

vendredi 21 mars 2014 à 17:25

L’exercice d’hier était plus un prétexte pour faire un peu de Python 3 avec manipulation de bytes qu’un vrai défi, mais c’est toujours marrant.

"""
    Kick flash bin ass so it stop giving us trouble will full screen
    vids on a dual screen.
"""
 
import sys
import argparse
 
# On déclare un argument positionnel obligatoire.
# Ce doit être un fichier que l'on veut
# ouvrir en lecture et mode binaire.
parser = argparse.ArgumentParser(description=__doc__)
parser.add_argument('bin', type=argparse.FileType('rb'), help="Path to flash bin, man")
args = parser.parse_args()
 
# On charge le contenu du fichier en mémoire.
# Un peu bourrin, mais tellement plus simple
# que de chercher directement dans le fichier.
flash_oh_oooooooh = bytearray(args.bin.read())
# On chercher la chaîne binaire qui correspond à la constante
# qu'on veut écorcher.
if b"_NET_ACTIVE_WINDOW" not in flash_oh_oooooooh:
    print("Flash est déjà défoncé")
    sys.exit(0)
# On remplace juste un bit 
flash_oh_oooooooh[flash_oh_oooooooh.find(b"_NET_ACTIVE_WINDOW") + 1] = 42
 
# On écrit le résultat dans dans le fichier final.
try:
    with open(args.bin.name, 'wb') as news_flash:
        news_flash.write(flash_oh_oooooooh)
except PermissionError:
    sys.exit("Fozzy says you don't have right to write in '%s', man..." % args.bin.name)
 
print("Rosebud")

Voilà, rien d’incroyable, mais on trouve deux choses intéressantes : l’utilisation de FileType pour gérer un paramètre de type chemin de fichier sans se prendre la tête, et celle de bytesarray qui nous permet d’avoir un array mutable et donc de tout charger en mémoire comme un porc sans avoir à dupliquer tout le contenu lors de la modification.

J’ai vu certains ouvrir le fichier sans le flag binaire (‘b’), attention Python peut vous bousiller tout le contenu du fichier puisqu’il va interpréter les caractères spéciaux et faire du décodage sur un contenu sur lequel ça n’a pas de sens.

La vraie question, c’est : combien y a-t-il de références pop culturelles dans ce code ?


Télécharger le code de l’article.

flattr this!

Exercice Python, round 3

jeudi 20 mars 2014 à 11:43

Continuons cette petite série fort sympathique, avec aujourd’hui un peu de manipulation de bytes, de gestion d’erreur et de parsing d’arguments de script.

Souvenez vous de ce hack qui permet d’avoir sa video Flash en plein écran sur un écran, et travailler sur l’autre, quand on est en dual screen. Le problème c’est qu’il faut le faire à la main. De plus, il faut recommencer à chaque mise à jour de flash. On va automatiser tout ça.

Faites un script (en Python 3 \o/) qui va parser les arguments de la ligne de commande avec argparse. Il doit déclarer :

Ensuite on ouvre le fichier, on cherche le fameux _NET_ACTIVE_WINDOW, on le deface, et on sauvegarde le tout dans le fichier final. Ce sera l’occasion de jouer un peu avec la gestion plus propre du binaire en Python 3.

Contrairement aux exercices précédent, on met un minimum de check d’erreur car c’est un petit script (35 lignes copieusement commentées chez moi): donc au moins avertir proprement l’utilisateur si on ne peut pas lire ou écrire dans le fichier et pourquoi.

La solution demain.

flattr this!

Droit de réponse au troll JS

mercredi 19 mars 2014 à 09:17

Comme tous les trolls, on a eu le droit à la cohue dans les comments, mais une réponse a eu l’élégance de faire ça sur un pastebin à part et de structurer l’argumentation.

Et en plus de faire un bisou.

J’aime le droit de réponse, et puisque cette personne n’a visiblement pas de blog (et que ça risque de se perdre dans le fin fond du web), je le publie ici, avec son autorisation.

C’est quand Google a enfin pu donner des perfs décentes – c’est à dire celles qu’ont d’autres langage depuis une décennie – à Javascript que les gens ont envisagé de l’utiliser sur le serveur.

Nan, c’est parce que Ryan Dahl a compris l’importance de la programmation asynchrone et que les gens qui font du JS sont déjà dans le moule de l’asynchrone et que c’était donc une communauté facile à convaincre.
C’est juste une bonne coïncidence qu’au moins une VM très performante est dispo.

Node.js massacre beaucoup d’autres langages en performance grâce à l’asynchrone, pas grand chose d’autre, sûrement pas la “vitesse du langage”.

Javascript (…) ne sert absolument à rien sans un framework côté serveur

On compare des choux et des carottes. Un langage (syntaxe, sémantique) ne sert à rien. Il faut toujours des trucs en plus. Dans un contexte web, à quoi sert Ruby sans Rails ?

côté client il est parfaitement improductif sans une lib pour gommer les incompatibilités entre les implémentations.

Le web est un pari ambitieux qui a des coûts. Mais il faut aussi comprendre les enjeux du web. Aucun téléphone ne sort sans navigateur web aujourd’hui. Ca n’est même pas une discussion. Ca a des coûts qui vont avec. On peut rêver d’un autre monde, mais essayons d’avancer dans celui qu’on a entre temps ;-)

Au cas où vous ne l’aurez pas encore compris, je vomis sur Javascript. Mais je code avec, et j’offre même des formations dessus, car je suis pragmatique. Les besoins de l’industrie, l’inertie technologie et le contexte social / technique / économique dictent bien plus souvent les standards que nous utilisons que leurs qualités intrasèques. Sinon nous n’aurions pas utilisé le format .doc ou les VHS.
En fait, je ne détesterais pas autant Javascript si je n’en avais pas besoin quotidiennement. Je le hais du plus profond de mon âme justement parce que c’est non seulement une contrainte inamovible de mon métier, mais en plus une tumeur que les chercheurs annoncent voir grossir de jour en jour. Avec le sourire, les connards !

Bienvenue dans l’humanité ;-)

Les experts recommandent d’éviter la moitié du langage

Du fat d’être langage du web et de la contrainte de backward-compat du web, JS ne peut pas se débarrasser de ses bad parts. J’ai donné un talk sur le sujet. Être efficace en JS nécessite de comprendre un peu son histoire et les pièges à éviter. C’est le coût d’être le langage du web. Mais c’est bien le web, non ? Ca vaut le coup, non ?

En fait activer use strict dès que possible pour éviter l’insertion de ; automatiques.

wtf? N’importe quoi ! La spec ECMAScript 5 est la référence pour les différences entre strict et “sloppy” mode. Pour des ressources un peu plus digestes :
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions_and_function_scope/Strict_mode
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions_and_function_scope/Strict_mode/Transitioning_to_strict_mode

Cependant, faites gaffe quand vous convertissez du code parce que :

=> a = 1
1
=> var a = 1
undefined

Mais c’est quoi ce business de la désinformation !!
a = 1 est une expression qui permet de faire a = b = 1, donc sa valeur est la valeur de la sous-expression de droite. var a = 1 n’est pas une expression (if(var a = 1){} est une SyntaxError), donc le REPL se contente de retourner undefined, mais ça n’a aucune importance en pratique.

Ah oui, et ne pas utiliser les mots clés new ou with pour vos propres libs. Si, si, on bannit carrément des mots clés, c’est écrit dans le livre.

Douglas Crockford est une seule personne. On a le droit aussi de ne pas être d’accord. Utiliser with, c’est souvent se tirer une balle dans le pied, d’où le bannissement dans le strict mode. Mais new, c’est plus une question de style. Je suis assez expert JS, j’utilise new et je le vis bien.

Faire du JS propre présuppose l’utilisation de design patterns
En l’état, on ne peut pas écrire du JS propre.

En français aussi, il y a des figures de style. En l’état, on peut écrire du JS propre. Je veux bien admettre que ça exige beaucoup plus de disciplines que d’autres langages, mais ça s’arrête là. Encore une fois, JS est obligé de porter le poids de son histoire parce que c’est le langage du web.

Au fait, vous avez déjà essayé d’expliquer le prototypage à quelqu’un ? Bonne chance !

http://davidbruant.github.io/ObjectViz/

J’ouvre Firefox, je tape [] + {}

J’écris ça quotidiennement aussi, ça m’aide beaucoup pour écrire des interfaces facilement utilisables par les utilisateurs. [] + {} créé aussi des méta-promesses qui permettent de faire de l’asynchrone un peu plus rapide que la vitesse de la lumière.

Si tu additionnes des choux et des carottes, faut pas s’étonner. Si des fois, tu es fatigué, utilise TypeScript pour aider avec la discipline.

chaines multilignes

Ca arrive dans ES6 https://gist.github.com/lukehoban/9303054#template-strings

list compréhension à la Python

ES6 : https://gist.github.com/lukehoban/9303054#comprehensions
Implémenté dans Firefox et dans la Nightly depuis la semaine dernière.

Et encore, je suis cool, je mets un code JS qui utilise l.length directement dans la boucle et pas de variable pour l[i].

Nan, mais c’est bon, on est en 2014, plus besoin de ces conneries :-) Y’en a jamais eu besoin, c’était juste de la micro-optimisations de gens qui pensaient que ça avait un impact significatif après qu’ils aient fait un micro-benchmark sur le sujet.

Array.map arrive avec JS 1.6 et les arrays comprehensions avec la 1.7…

Cute :-)
Array.prototype.map, on peut le polyfiller

JavaScript 1.6, 1.7, ça n’existe pas. C’est des gens chez Mozilla, ils étaient bourrés (Brendan Eich a continué à boire même après avoir créé et shippé JS en 10 jours), ils ont donné des numéros de version, après le mot “JavaScript”, mais c’était pour rire (c’était lié au numéro de version de SpiderMonkey, moteur JS de Firefox). Seuls les numéros de spec d’ECMAScript ont un sens un peu sérieux.

que vous pourrez utiliser sur tous les navigateurs d’ici 2056.

.map tu peux l’utiliser depuis des années. Les array compréhension, ça marche sur Traceur

PASramètre
Comment on fait ça en Javascript ?

Tiens https://gist.github.com/lukehoban/9303054#default–rest–spread
J’ai utilisé ça en TypeScript (mais ceux qui préfèrent Traceur peuvent aussi choisir ça) sur un vrai projet qui tourne sur de vrais mobiles il y a presque un an.

Ah mais il faut utiliser coffeescript !
Oui donc pas Javascript. Point made.

Jeremy Ashkenas, inventeur de CoffeeScript le décrit en disant “it’s just JavaScript”. Je dis ça…

Vous trouvez ça normal ?
Vous trouvez que c’est le signe d’un BON langage ?

Aucune importance. C’est ce qu’on a, il faut vivre avec, bon gré mal gré.

Gros bisous,

David

flattr this!