Categories
Programming Python

pipenv

Stegano utilise maintenant pipenv, le nouvellement recommandé (à prendre avec des pincettes) outil Python de packaging.

Si vous n’utilisez pas encore pipenv, je vous conseil de lire cette documentation. Et pourquoi pas ce petit billet.

Et si vous êtes un peu perdu avec les outils de packaging Python, j’ai commencé ce petit historique.

Categories
Programming Python Steganography

Décret à propos de Python et Stéganô

Trump's decree on Python
Trump’s decree on Python
$ sudo pip3.5 install --upgrade Stegano
$ wget https://blog.cedricbonhomme.org/wp-content/uploads/2017/02/Trump_decree_on_Python.png
$ lsb-set reveal -i Trump_decree_on_Python.png -g eratosthenes

Plus sérieusement, quelques améliorations (et corrections) pour Stéganô sont disponibles. Bien que je ne parle pas tellement de ce projet ici, le changelog est à jour.

Categories
Cloud Python

pyAggr3g470r dans le cloud

pyAggr3g470r est dorénavant déployable sur Heroku. Évidemment, il est toujours possible de l’utiliser sur un serveur traditionnel.

Voici comment le déployer sur Heroku. Rien de plus simple. Si vous désirez le tester mais que vous n’avez pas de compte Heroku, je peux vous créer un compte ici. Et oui, pyAggr3g470r est également multi-utilisateur maintenant!

Categories
Programming Python

Grenouille: v0.3

La nouvelle version est disponible depuis hier. Les derniers efforts se sont essentiellement concentrés sur l’interface administrateur.

Il est possible de suivre les évolutions du projet (si ça vous intéresse) à cette adresse (où vous trouverez également des captures d’écran). Sur ce blog, je posterai juste à propos de ce que je juge intéressant.

Categories
Programming Python

Plateforme météorologique

Aujourd’hui je vous présente un nouveau projet. Il s’agit d’une plateforme permettant l’agrégation de données météorologiques. Elle permettra aussi de consulter les données d’une station d’un contributeur dans le monde sans avoir de compte. Je souhaite que la base de la plateforme regroupe des données publiques et impersonnelles (donc un minimum de fonctionnalités pour une personne identifiée sur le site), au maximum.
Voici l’instance de test.

Pour valider le système j’utiliserai une station Yocto-Meteo. Voici comment récupérer de cette puce la température, pression et l’humidité. Évidemment les données pourront provenir d’une station quelconque tant que l’utilisateur aura un moyen d’envoyer les informations via une requête HTTP POST. Pour ceci il manque encore les spécifications, mais des services sont déjà disponibles (un exemple) car le site reposera sur ces propres services Web pour son fonctionnement.

Voici la seule interface actuellement disponible lorsque l’utilisateur est connecté:

Grenouille-profile-screen

Comme vous pouvez le constater pour envoyer des données il faudra être authentifié et disposer d’une clé (générée automatiquement à la création de votre compte).

Aussi, il vous sera possible de déclarer plusieurs stations. Il est aussi important de pouvoir récupérer les données envoyées par une station (certainement dans un fichier JSON).

Pour terminer j’ajoute que je suis ouvert à toutes contributions (même idées). Surtout si vous disposez d’autres stations, propriétaires ou fait-maison (Arduino, etc.), et que vous désirez écrire des clients que l’on pourra ajouter au projet.
Vous pourrez utiliser le service gratuitement (mais j’accepte les Bitcoins). Pour le moment les données se situent dans une base PostgreSQL sur Heroku, à terme j’utiliserai une base ailleurs (où j’ai bien plus de place) et le code sera certainement toujours sur Heroku. À ce propos, si vous souhaitez tester de votre côté, le README montre comme il est super simple de déployer le service sur Heroku ou sur votre machine.

Categories
Programming Python

pyAggr3g470r: version 4.6

La version 4.6 de pyAggr3g470r introduit simplement l’import de flux de nouvelles via OPML ainsi que l’export des flux.

Categories
Programming Python

pyAggr3g470r: version 4.5

La nouvelle version simplifie enfin l’installation. Il y a même pas un an il fallait faire ça. Il suffira dorénavant d’exécuter un script, plus d’information ici. Le script utilise virtualenv principalement afin d’éviter les problèmes de dépendances.
L’annonce sur la page freecode du projet.

evolution-pyAggr3g470r

J’aime bien ce graphique, il résume bien l’évolution du projet, les changements de technologies (SQLite -> PyMongo, CherryPy -> Flask, PyMongo -> MongoEngine). J’ai effectivement l’impression que le code est toujours plus propre, mieux isolé (vues et «templates») et aussi plus moderne (notamment virtualenv, MongoEngine, WTForms).

Depuis ce temps j’ai pu conserver une base de données cohérente et je fais régulièrement des exports HTML, en voici un assez récent.

Categories
Programming Python

Refonte de pyAggr3g470r

pyAggr3g470r évolue de manière quasiment continue depuis janvier 2010 avec l’apparition de nouvelles fonctionnalités (utiles, ou pas) ou améliorations. Développé pour mes besoins. D’où son interface pas très sexy et un peu statique. Après plus de trois années d’utilisation et près de 70.000 articles récupérés, je trouve son utilisation toujours aussi satisfaisante.

Au départ CherryPy était utilisé avec une base SQLite et un petit fichier de configuration pour la liste des flux à surveiller. Rapidement il a fallut utiliser un autre système de base de données, j’avais choisi MongoDB (avec pymongo). Parallèlement j’ai testé diverses fonctionnalités (pas forcément à valeur ajouté) comme la détection de langue, l’export des articles vers différents formats, proxy, notifications par email, recherche indexée, etc. Bref, je me suis bien amusé avec un programme très certainement seulement utile pour moi.

En dépit de tout ceci, l’idée d’une refonte plus profonde (voir un fork) me reste à l’esprit depuis un certains temps. pyAggr3g470r me satisfait globalement et j’ai donc pris mon temps pour réfléchir si le travail qu’implique une vraie refonte serait valorisé. Et si je recommence pyAgg3r470r il faut évidemment utiliser des technologies plus modernes, essayer d’avoir un code beaucoup plus propre et simple à maintenir. Et pourquoi pas une interface un peu plus actuelle. Sur ce point ça tombe bien, dans un contexte professionnel j’ai récemment découvert Bootstrap. Parfait pour quelqu’un comme moi qui ne veut pas se prendre la tête avec du CSS et Javascript. Mais on ne va pas s’arrêter à changer uniquement les templates. On va aussi utiliser un ORM (une couche au-dessus de pymongo), MongoEngine. À ce stade là, on peut remplacer CherryPy par Flask qui est un peu plus à la mode. J’ai découvert Flask grâce au service Heroku il y a quelques temps et ma de suite intéressé (surtout à cause de son minimalisme et de toutes les extensions qu’offre la communauté). Et donc je m’y suis mis.

Voici le résultat en avant première. C’est vraiment en avant première évidemment. Les fonctionnalités de bases fonctionnent mais ne sont pas encore assez testés. Si vous voulez tester, demandez moi un compte utilisateur (pyAggr3g470r gère enfin proprement plusieurs comptes) et soyez indulgents (ou contribuez). Grâce à Bootstrap l’interface s’adapte très bien aux grands écrans comme aux écrans de smartphones. Il faut encore que je m’améliore avec MongoEngine, j’ai l’impression d’avoir perdu en performance à certains niveaux (je teste avec environ 70.000 articles).

Pour le moment je suis satisfait de cette décision.

Pour information, cette instance de pyAggr3g470r fonctionne sur le service IaaS de Numergy. Vous pouvez tester gratuitement pendant deux mois.

Categories
Programming Python

pyAggr3g470r: recherche avec un index

whoosh

Le module Whoosh est maintenant utilisé pour indexer la base MongoDB de pyAggr3g470r et faire des recherches sur le contenu des articles (texte intégral). Whoosh est entièrement écrit en Python et vraiment rapide. Avec un processeur i7 il me faut environ 3 minutes pour indexer près de 60.000 entrées et quelques dixièmes de secondes pour effectuer une recherche exhaustive.

Categories
Programming Python

Comparaison des performances de Python 2.7 et 3.3 avec Ackermann

$ time python ackermann.py 3 12
32765
 
real    2m33.121s
user    2m32.518s
sys     0m0.088s

$ time python ackermann.py 3 12
32765

real    2m57.908s
user    2m57.316s
sys     0m0.068s

$ time python3.3 ackermann.py 3 12
32765

real    4m6.365s
user    3m18.204s
sys     0m47.452s

Tests effectués avec, dans l’ordre, Python 2.7.3, 2.7.4 et 3.3.1 sur cet algorithme. Nous voyons que malgré le fait que Python 3.* s’améliore (voir ce billet), Python 2.7 est toujours bien plus rapide. Ce test n’utilise pas d’itérateurs ou objets/structures complexes. Il s’agit simplement de l’implémentation naïve de la fonction d’Ackermann. Nous avions déjà fait quelques comparaisons entre différents langages.