Categories
Programming Python

pyAggr3g470r – export journal Web

pyAggr3g470r dispose maintenant d’un export des articles sous forme de journal Web (vraiment simple). De sorte à pouvoir exporter la base SQLite et de l’envoyer (via scp, ftp ou autre) sur un serveur.

Voici un exemple comprenant 24.999 articles (dont pas moins de 10.000 articles de L’essentiel).

Categories
Programming Python

Balloon prend de la hauteur

Depuis sa création quelques modifications apportés à Balloon le rendent déjà plus utilisable et moins bêta (il y a maintenant simplement un fichier de configuration à éditer). Une des améliorations majeures réside dans le fait que les push ne sont plus réalisés systématiquement après un commit. Balloon attend qu’une série de commits soit réalisée avant d’exécuter un push vers le serveur. Après quelques tests Balloon fonctionne plutôt bien (j’ai testé avec des fichiers textes et images de quelques méga-octets). Mais il y a encore du travail.

Lorsque le code sera un peu plus stable et mieux pensé, je n’aurai plus qu’à écrire la classe GitSync (à l’instar de HgSync) pour gérer les dépôts Git. En effet à terme Balloon pourra synchroniser plusieurs dossiers locaux (avec une racine différente) que ce soient des dossiers versionnés avec Git ou Mercurial.

Une des dernières étapes sera l’écriture d’un watcher pour Windows. Oui ce système dispose d’un noyau un peu primitif, ce n’est pas ma faute. inotify ne semble pas y être implémenté.
Pour le moment Balloon réagit aux événements: IN_CREATE, IN_DELETE, IN_MODIFY, IN_MOVED_FROM et IN_MOVED_TO. Pour la liste complète des événements voyez ce fichier: /usr/include/sys/inotify.h.

Le Wiki explique brièvement comment utiliser Balloon.

Categories
Programming Python

Balloon

Balloon est un nouveau petit projet.
Ce n’est pas le premier du genre. Et c’est une discussion aujourd’hui qui ma un peu motivée.

Ballon peut être vu comme une alternative à Dropbox avec versionnement des fichiers. Ballon pourra fonctionner avec Mercurial et Git (Mercurial pour le moment, mais bientôt Git car depuis aujourd’hui bitbucket supporte Git. Quelle coïncidence!).

Il manque encore deux ou trois modifications pour qu’il soit utilisable out of the box (gestion de plusieurs dépôts locaux, stockage des mots de passe en local). Mais ça fonctionne déjà très bien.
Pour le moment il suffit de créer un dépôt hg (privé ou public) sur votre serveur personnel (ou bitbucket, Google Code, etc.), puis de lancer Balloon sur vos différents ordinateurs avec l’adresse du dépôt hg. Les clients vont alors cloner le dépôt en local et surveiller les modifications. Par modification j’entends: ajout, suppression, renommage, modification du contenu. En fonction de l’événement détecté la commande hg appropriée est lancée de manière transparente, puis un push vers le dépôt hg est effectué. À partir de ce moment les autres clients via un simple pull détectent les modifications et mettent à jour leur dépôt local. Tout ça de manière transparente évidemment.

Et vous savez quoi? Ça fonctionne! Voici un premier test. Les messages des commits correspondent aux divers événements détectés sur mon dépôt local (Added quand j’ai ajouté un fichier, Removed quand j’ai supprimé un fichier, etc.).

Niveau sécurité une connexion HTTPS est utilisée et plus tard j’ajouterai une authentification avec certificat (mot de passe chiffré pour le moment).
Voyons ce que ça va donner.

Categories
Programming

C, Python & Ocaml ou les plaisirs simples de la vie

Un billet en trois parties qui aborde en premier lieu trois beaux langages de programmation bien différents et se ressemblant sur certains points. Ils réunissent expressivité et performance, style impératif et fonctionnel, typage dynamique (mais pas faible) et fort.

Je trouve qu’il est plutôt drôle de les comparer. Python semble sur certains points se situer entre le C et Objective Caml. Enfin c’est mon avis et ce que je constate parfois.

Pour Guido Van Rossum, Python devait être entre un language de script (interprété comme Shell) et le C (compilé) et ainsi tenter de réunir expressivité et performances avec des structures de données évoluées (dictionnaires, tuples, listes, etc.).
Python est donc un language impératif héritant de l’éducation de Guido Van Rossum et sur ce point est proche de C. Cependant il a un typage dynamique fortement typé (inutile de définir de manière explicite le type d’une variable, mais une fois fixé le type a souvent de l’importance). Au contraire le C a un typage très fort.

Cependant des fonctions comme map ou les listes en compréhensions lui donne quelques traits de languages fonctionnels, comme OCaml (preuve que Guido a l’esprit ouvert). Biensûr sur ce point il n’arrive pas à la cheville d’OCaml et c’est normal.

Ce qui est vraiment génial avec Python, c’est la liberté et l’expressivité du langage. Ce qui fait qu’on peut faire facilement à peu près ce que l’on souhaite. Voici par exemple deux petites comparaisons:

  • Ocaml et Python
    Sans être vraiment un langage fonctionnel Python de par son expressivité définit cette fonction d’incrémentation quasiment aussi simplement que OCaml. Grâce au listes en compréhension il peut même faire mieux parfois;
  • C et Python
    En le comparant à C on comprend de suite l’avante du typage dynamique (qui peut être dangereux), mais il sera parfois moins performant pour des calculs plus complexes (par exemple en cryptographie ou pour traiter des longues chaînes de caractères). Voici encore un excellent exemple.

Il y a donc évidemment plusieurs styles pour écrire du Python. Un(e) Pythonien(ne) reconnaîtra le bon.
Lorsque l’on sait un petit peu développer on sent facilement quel langage est le plus adapté dans une situation. Hormis pour des raisons de performances je n’utilisera plus le C pour calculer un PGCD, Fibonacci ou encore jouer avec une liste mais plutôt Ocaml. Je le faisais avant, je n’en ai plus besoin. Par dessus OCaml pour les listes je préfère de loin Python, parfois aussi pour des fonctions mathématiques. Pour des traitements sur des fichiers, chaînes de caractères, le C. Bref, mes trois langages favoris qui permettent de tout faire très bien.

La première partie très plaisante de ce billet se termine sur cette question: De votre côté, comment situez vous C, Python et OCaml?

§

Maintenant parlons du développeur de l’extrême (celui qui aime les lignes de code). Typiquement:

  • il aime écrire une classe en Java juste pour une fonction mathématique (exemple: incrémenter un nombre ou mise à la puissance avec gestion avancée des paramètres dans le build.xml d’Eclipse);
  • il écrit une classe en Java pour lire un fichier texte ou ouvrir une socket;
  • s’il tente de coder un petit morceau (par exemple factorielle) en OCaml, il utilisera une boucle for.

Très souvent ce malheureux Windowsien(ne) dégainera Eclipse pour générer automatiquement un tas de morceaux de codes inutiles. Ce n’est pas forcément un mauvais développeur, il est peut être juste simplement passé à côté de la programmation. Ce sera parfois la faute de l’école, souvent celle du monde de l’entreprise. Pour guérir c’est facile, il suffit de découvrir Python, Perl ou Ocaml. Attention toutefois, OCaml peut provoquer un choc assez violent chez un développeur Java de longue date.
Généralement les systèmes type GNU/Linux vous feront naturellement utiliser Python, Perl et C. OCaml ça sera par pur plaisir.

§

Pour finir passons à une autre catégorie de développeur, le fanatique. On remarquera que cette personne utilisera entre autres Python pour tout et n’importe quoi sans même savoir si Python est bon pour cela. Par exemple pour:

Ah zut, je crois qu’il y a un problème avec la liste. Vous pouvez chercher pour moi?
Certains au lieu de Python choisirons Perl. D’autres Java. Mais ces derniers, ont-ils vraiment choisi?

§

Encore une question: Y a-t-il un ordre d’apprentissage (au moins pour ces trois langages)?

Categories
Programming Python

Et de 20.000 articles

Ça y est pyAggr3g470r a franchi la barre des 20.000 articles. Il n’y a quasiment aucun impacts sur les performances, sauf peut être pour la page management qui permet d’effectuer divers statistiques sur l’ensemble de la base. Mais depuis peu il est possible de charger en mémoire qu’une partie de cette dernière.

Avant de sortir la nouvelle version j’attends que la mise à jour du wiki soit terminée, la procédure d’installation est déjà plus claire. L’installation est aussi encore plus simple qu’avant. Pas beaucoup plus facile, car ce n’était déjà pas très compliqué. Je veux aussi mettre à jour les captures d’écrans ainsi que la vidéo (ce qui est laborieux avec mon ordinateur).

La vidéo de ce billet montrait en Juin 2010 comment récupérer, lancer et utiliser pyAggr3g470r. Bientôt une nouvelle encore plus impressionnante 😉

Categories
Programming

Naissance de “~/Projects”

Avec mon “nouveau” site hébergé par AlwaysData je peux héberger le sources de mes projets versionnés avec Mercurial et ainsi me passer de bitbucket (pas pour l’aspect social).

J’ai également un wiki comprenant une page dédiée aux projets. Mais ce n’est pas génial pour la gestion de projets finalement (il faut faire des liens vers les sources, pas de rapports de bugs, etc.). DokuWiki est bon pour la documentation, mais il n’y a pas de fonction aussi avancée qu’avec un vrai environnement de gestion de projets (donc: DVCS + Wiki + Rapports de bugs, etc.).

Je vais donc enfin unifier mes projets sur ce site. Cela grâce à Redmine que je voulais tester depuis quelques temps. Redmine permet de gérer pour chaque projet un calendrier, un diagramme de Gant, un dépôt (Mercurial, Git, etc.), un wiki, des rapports de bugs, des demandes, etc.Concernant les dépôts, Redmine utilise tout simplement les dépôts locaux déjà présents (il n’y a rien à faire), il génère même des statistiques. Bref, génial 😉

Voilà, petit à petit je rassemble tout le bordel que j’ai semé sur Internet au même endroit. Et un jour le disque dur sera même chez moi (mais là va falloir bien attendre).

Categories
Programming Python

The Art of Python Programming

Un titre peut-être un peu trop prétentieux pour annoncer la sortie de pyAggr3g470r 2.7 (infomations de release pour les détails) et de Stéganô 0.3 (informations de release pour les détails). Il est maintenant possible d’installer Stéganô comme un module Python classique.

Sinon j’ai une toute petite idée derrière la tête qui pourrait permettre de partager et d’éditer collaborativement des fichiers .bib (avec le papier éventuellement associé) via un réseau pair-à-pair en utilisant Forban. Je pense que Forban ferait très bien l’affaire, je l’utilise tous les jours avec quelques gigaoctets de fichiers. Les fichiers (.pdf, etc) ainsi que les fichiers .bib associés seraient partagés au travers des différents noeuds (par exemple en mode opportuniste).

forban-bib

Voici un prototype. Il y a un filtre au niveau de l’interface sur les .bib, seules les publications sont visibles (cependant même les .bib sont échangés sur le réseau). Un lien permet de créer/éditer automatiquement un .bib (conférence, journal, etc.) et un autre lien de le récupérer (on n’est pas forcément en mode opportuniste). Il y a donc l’aspect collaboratif (au départ il peut y avoir uniquement des papiers, puis des personnes commencent à créer des .bib) et l’aspect distribué (tout le monde a tout et les mises à jours des .bib sont répendues sur les autres noeuds). L’édition pourra être assisté avec BibSonomy.

Si un jour The Art of Python Programming est publié, je sais où sera sa place en tout cas. Pour le moment c’est Kleinberg.