Images
Nouveau rebondissement dans les API de traitement d'images de Python avec Pystacia , un emballage d'imagemagick plus simple à installer que PIL, qui résiste aux outils de gestion de dépendances. Il existe aussi un fork amical de PIL par l'équipe de Plone, Pillow .
Dans tous les cas, il est intéressant de regarder la documentation kilométrique d' ImageMagick , qui fait bien plus que de changer le format ou les dimensions des photos. Son fork, GraphicMagick , plus efficient, est utilisé par Flickr ou Etsy. Les utilisateurs typo3 se souviendront de l'époque où imagemagick a changé les comportements par défaut, les obligeant à vérifier leurs installations en regardant des images de Jésus.
OpenCV (pour computer vision) est l'outil de référence pour le traitement des images. Il est connu pour ses outils de reconnaissance de visages, mais permet de faire beaucoup d'autres choses. Son binding python, bien qu'officiel, a une mauvaise réputation, et il est pénible de s'y retrouver dans ses divers bindings alternatifs. Une nouvelle bibliothèque Python, SimpleCV , propose une belle API pour explorer les capacités d'OpenCV sans aller lire des .h . Scikit, la bibliothèque ultime des scientifiques pythonistes propose divers spécialités, dont le traitement des images avec skimage qui permet de faire la jointure avec numpy et donc d'avoir des temps de calcul pas trop risible.
Base de donnée
Postgres continue de faire le malin suite aux déboires de Mysql avec son rachat par Oracle et aux déçus du NoSQL qui ont cru tout ce qui était écrit sur la plaquette produit, sans lire les petites lignes. Sa capacité en full text reste au niveau du POC, réservé aux anglophones. Rien de comparable avec le rouleau compresseur de Lucene . Postgres se vante aussi de savoir faire du pubsub et donc de remplacer Redis. Le raccourcis est la base du slogan, et du tweet, donc. Il faut bien se rappeler que Postgres est radin sur le nombre de connexion qu'il peut maintenir ouvert, étant basé sur des threads et des locks. Cela ne pose aucun soucis dans un fonctionnement classique, un pool de connexion permet de partager les accès qui de toutes façons ne sont pas si nombreux que ça, la plupart des applications utilisant le pattern des workers. Pour simuler l'envoi d'événement, Postgres propose un système de meta information dans sa connexion. Les événements sont alors des passages clandestins dans une classique requêtes, et on se retrouve alors à demander du rien à la base, pour voir si par hasard, il n'y aurait pas des événements, en cadeau. Bref, du classique polling. Il faut attendre la version 9 de Postgres, celle qui n'est pas sur Debian stable pour avoir droit au payload dans les événements. De plus, NOTIFY en plpgsql n'acceptes pas d'arguments, il faut passer par un élégant "EXECUTE 'NOTIFY ' || channel;" channel étant un argument de la procédure. Bref, ce NOTIFY/LISTEN est un outil interne de Postgres pour gérer du cache, et surtout pas un outil de pubsub.
Postgres propose un des dialectes SQL les plus riches, mais sans pouvoir masquer le poids de son âge. Le "query language" est loin d'être mort, toutes les bases NoSQL en ont un, ce qui est une belle ironie, mais le classique SQL est quand même bien pénible à utiliser. Un ORM sert à masquer ce coté pénible, mais c'est un handicap pour Postgres, les ORMs le considérant comme un gros Mysql ne sachant pas gérer ses compteurs tout seul, et donc profites peu de ces spécificités.
Mysql a intégré les travaux expérimentaux d'un développeur japonais permettant d' accéder aux données comme une base clef/valeur . On perds la notion de jointure, mais on continue de stocker les données dans le très résiliant innodb. La syntaxe utilisée est celle de Memcached. Cerise sur le gâteau, les données gardent leur cohérence au sein de la base, et il est toujours possible d'y accéder en SQL.
Redis a du mal à implémenter son mode cluster, du coups, Twitter propose un proxy qui dispatch : twemproxy . Les outils internes de Twitter sont sympa à lire, mais bon, ils correspondent à des besoins hyper spécifiques et des volumétries gargantuesques.
RCouch est un fork amical de [CouchDB[( http://couchdb.apache.org/ ) pour le rendre plus contemporain et facilement embarquable. CouchDB fait parti des pionniers des bases orientés documents et traine pas mal de polémiques dans son histoire, dont son intégration à la fondation Apache. Elle ne fait pas parti des bases les plus véloces, mais son système de réplication master/master et la possibilité d'embarquer un site web permet de faire des choses distribuées et résiliantes. Rcouch est une des briques de Refuge .
CodernityDb est une base clef/valeur avec des index, en pure python. A tester pour sa simplicité à embarquer dans un projet. Python fournit dans sa lib standard quelques libs, mais avec beaucoup de variantes selon les OS. KyotoCabinet et autre LevelDb sont toujours un poil compliqué à installer. Il y a d'ailleurs DiscoDb à surveiller, mais qui est pas mal spécialisée.
Seven databases in seven weeks est un livre agréable à lire, qui arrive à peu prés à éviter les trolls et propagandes officiels des différentes bases de données.
Développement
Python commence à s'attaquer à l'asynchrone avec la PEP-3156 . Depuis toujours Python est une bouse pour gérer l'asynchrone. Twisted a été un pionnier, mais leur fascination à crée des conventions exotiques et leur incapacité à produire des docs lisibles à tué le projet. Il est raisonnable d'utiliser un projet basé sur Twisted, mais suicidaire d'en commencer un avec. Gevent est basé sur libevent, puis libev, mais il a une approche très bas niveau, avec un clair mépris des exemples concrets. Nouvel échec. Tornado est parti sur un cas concret, le besoin d'agréger des services webs sans bloquer. Tornado est du coup un projet pragmatique, utilisable en production. Il a atteint une masse critique d'utilisateur (et la force de frappe de Facebook) pour avoir des library spécialisé et se connecter à un MongoDB, par exemple. Son code s'avère d'ailleurs neutre, et il est possible de changer le moteur asynchrone pour garder une cohérence avec d'autres bibliothèques. Plus récemment, pyuv est apparu comme un challenge à nodejs. Pour aller chercher les développeurs Windows, NodeJS à crée libuv , qui est une abstraction pour gérer l'asynchrone quel que soit la plateforme. On peut dire pour résumer que NodeJS est V8+libuv. Il y a eut un binding en Lua, puis, en python.
Il commence à y avoir des applications basé sur pyuv, comme Gaffer , un gestionnaires de processus.
C'est un peu dommage de voir toutes ses hésitations quand on a testé des langages prévus pour l'asynchrone, comme nodejs, erlang, scala ou go.
Python continue sa conquête du monde scientifique. Pour pallier à sa légendaire lenteur, il doit utiliser différentes astuces. Numpy propose un binding C/Fortran qui s'avère être plutôt intrusif, et ne résous pas grand chose pour les lenteurs d'exécution des grosses boucles. La piste actuelle semble être l'utilisation de llvm , avec différentes approches. LLVM se chargeant d'optimiser le code selon la plateforme et l'usage. Pypy est le plus ambitieux, il remplace l'interpréteur python, mais casse les lib existantes. Cython propose un dialecte qui force le typage et permet simplement de faire des bindings vers du code en C. Conçu pour optimiser des partis critiques, il est concrètement utilisé comme une alternative à swig et ctypes , devoir précompiler son code semble brimer le workflow. Numba propose une approche plus novatrice, basé aussi sur LLVM, se contentant d'annotation (pour typer) pour faire du JIT.
Tous ces outils restent spécialisé dans le calcul scientifique, il est utopique d'espérer améliorer les performances de Django avec ce genre de chose. Par contre, pour rester dans le domaine web, c'est tout à fait utilisable pour des moteurs de suggestions et autres jouets utilisant l'intelligence artificiel.
Le oreilly Programing Collective Inteligence est LA référence, parfaitement complété par le Mannging Machine Learning in Action .
