Un Electron Libre...

Aller au contenu | Aller au menu | Aller à la recherche

Tag - python

Fil des billets - Fil des commentaires

vendredi 2 mai 2008

Des bonnes nouvelles d'un peu partout...

Par NiCoS le vendredi 2 mai 2008, 23:47 - En Vrac

aucun commentaire

mercredi 16 avril 2008

Nginx, wouhaou :-)

Par NiCoS le mercredi 16 avril 2008, 21:50 - Trucs de geek

Juste pour dire que j'ai installé en quelques heures vendredi soir, Steinmetz.fr sur une part Gandi avec l'infrastructure nginx, postgresql et python 2.5 (en lieu et place de Apache2/mod_wsgi, MySQL et Python 2.4).

Pour le moment cela marche du tonerre sur une configuration en plus assez équivalente que celle que j'ai chez Sivit (sauf que la part Gandi est moins chargée en sites pour le moment).

La procédure de migration d'un site django est assez simple :

  • Backup du site + bdd
  • Transfert du site
  • Installation de nginx & postgresql
  • Configuration de nginx en reprenant ce fichier de configuration (par contre la regexp sur les fichiers css & co ne fonctionne pas dans mon cas)
  • Ajustement des paramètres de mon projet django (sur les chemins vers les templates et fichiers statiques)
  • Lancement de mon application en mode fcgi
  • Lancement de nginx
  • Et on apprécie le résultat.

Pour être honnête, cela a été un peu plus compliqué ;-)

Je ferais surement un article un peu plus détaillé & étendu plus tard pour ceux que cela peut intéresser...

aucun commentaire

jeudi 27 mars 2008

En vrac (très teinté django quand même)

Par NiCoS le jeudi 27 mars 2008, 22:42 - En Vrac

  • Le changset 7370 permet de générer une doc au format HTML notamment via Sphinx et le rendu est assez sympatique. C'est assez simple à faire :
cd django/django-svn/docs
make html

Le résultat est dans un sous répertoire _build et la jolie table des matières est disponible /_build/html/index.html

Pour le reste, c'est dans mon flux del.icio.us ;-)

Edit du 31 : Le programme de Pycon FR est disponible.

aucun commentaire

mardi 25 mars 2008

Lecture : Programmation Python

Par NiCoS le mardi 25 mars 2008, 10:26 - Python - Django

Je viens de terminer la lecture de "Programmation Python", qui possède d'ailleurs son |propre site dédié au livre|http://programmation-python.org/sections/blog|fr].

J'ai trouvé le livre très intéressant et très complet. J'ai compris beaucoup de choses vu ici et là dans des bouts de code python. Autant "Apprendre à programmer en python m'avait permis d'appréhender python et son modèle objet mais sans forcément me donner toutes les clés, autant là, j'ai l'impression d'avoir une bonne bible sous la main et d'avoir fait un grand pas (quitte à avoir trop de clés dans ma besace ;-) ).

A sa décharge et au vu de mon niveau actuel en python, y a des pans du livre qui me sont passés au dessus de la tête / que j'ai survolé, estimant que j'y reviendrais surement plus tard.

Autre petit point négatif mais inhérant à sa date de publication, c'est qu'il ne couvre que la version 2.4 de Python.Sur ce point précis, j'avais hésité avec l'achat de "Au coeur de Python" (Tome 1 et Tome 2) qui couvre python 2.5. Toutefois, en parcourant ce dernier livre, j'ai eu l'impression de parcourir un peu la documentation à la php.net où on assiste à un listing exhaustif des fonctions disponibles mais sans plus. Je trouve "Programmation Python" pour le coup plus pédagogique et mieux enrobé quitte pour certains points à ne donner que l'essentiel (et un peu plus) et des pointeurs si nécessaire.

Pour finir sur un point positif, l'aspect méthodologie (test, doctest, design pattern, etc) est très bien documentée et sera complétée dans le livre Petit guide à l'usage du développeur agile.

Bref, un livre à lire tant pour des débutants (qui se focaliseront sur la première partie du livre) ou des développeurs plus expérimentés qui se focaliseront sur la seconde partie.

Il me reste juste à trouver un éditeur de code python qui me va bien pour aller plus loin... (je veux un textmate-like pour Linux)

17 commentaires

mardi 19 février 2008

SPE (Stani's Python Editor) 0.8.4.c dispo sous Archlinux

Par NiCoS le mardi 19 février 2008, 23:33 - Python - Django

Archlinux disposant d'une fort vieille version de SPE, je me suis décidé à mettre à jour le fichier PKGBUILD existant en partant de ce qui existait originellement et aussi du paquet spe-svn (paquet orphelin, tout comme spe jusqu'à ce soir).

Cela donne donc SPE 0.8.4.c pour Archlinux.

Pour l'installer :

yaourt -S spe

Par contre, sous Debian Testing, spe ne fonctionne pas suite à un problème de dépendances sur wxpython :-(

2 commentaires

dimanche 18 novembre 2007

Pygments et ReST (partie 2 sur je-sais-pas-combien-encore)

Par NiCoS le dimanche 18 novembre 2007, 23:27 - Python - Django

Suite de mon aventure sur Pygments et ReST :

En lisant la documentation rapide (QuickStart) de Pygments, on trouve comment récupérer la feuille de style fournit par défaut :

pygmentize -S default -f html > style.css

Ensuite, lors de la transformation Rest vers HTML, il suffit de faire :

rst2html.py source.txt cible.html --stylesheet-path=style.css

Il y a surement plus propre mais bon, ça marche... Cela veut aussi et surtout dire que pour produire un site à partir de document s au format ReST, il faut construire sa feuille de style CSS en incluant celle de pygments notamment.

Et voilà le résultat :

ReST et Pygments

Voir la capture d'écran

2 commentaires

Pygments et ReST (partie 1 sur je-sais-pas-combien-encore)

Par NiCoS le dimanche 18 novembre 2007, 23:00 - Python - Django

Dans le monde python, il y a :

  • Une syntaxe de documentation puissante mais pas aisée à prendre en main : ReST, pour ReStructured Text, fourni via docutils. Voir la QuickRef de ReST.
  • Pygments, un système de coloration syntaxique, un peu comme GeSHi en PHP.

Dans vos documents rédigés en ReST, il est possible d'inclure Pygments pour enrichir le rendu de vos documents.

Il vous faut pour cela :

  • docutils installé sur votre ordinateur,
  • pygments aussi
  • récupéré le fichier external/rst-directive.py présent dans le fichier source de pygments 0.9 et le copier dans /usr/lib/python2.5/site-packages/docutils/parsers/rst/directives/

Ensuite, et c'est là où le système manque un peu de flexibilité, il faut déclarer cette directive :

  • Editer /usr/lib/python2.5/site-packages/docutils/parsers/rst/directives/init.py (il y a deux "_" de chaque coté du init - bug de DC2 apparemment) pour ajouter une ligne :
_directive_registry = {
      'sourcecode': ('rst-directive', 'pygments_directive'),
      'attention': ('admonitions', 'Attention'),
      ...
      }

Cette déclaration dit que quand j'utiliserais la directive sourcecode dans mon document ReST, alors il doit aller utiliser la classe pygments_directive présente dans le fichier rst-directive.py.

  • Editer le fichier /usr/lib/python2.5/site-packages/docutils/parsers/rst/languages/en.py (et les éventuelles traductions) :
directives = {
      # language-dependent: fixed
      'sourcecode': 'sourcecode',
      'attention': 'attention',
      ...
      }

Voilà pour l'installation de pygments et docutils.

Dans votre texte au format ReST, il vous suffit d'utiliser la directive sourcecode comme dans l'exemple suivant :

Tutoriel : partie 1
===================

settings.py
-----------

.. sourcecode:: python

    # Django settings for tutoriel project.

    DEBUG = True
    TEMPLATE_DEBUG = DEBUG

    ADMINS = (
        # ('Your Name', 'your_email@domain.com'),
    )

Si vous voulez que les numéros de lignes soient également mentionnés, il vous faut décommenter la ligne suivante (dans rst-directives.py) :

et modifier votre fichier de la façon suivante (ajout de la directive :linenos: :

Tutoriel : partie 1
===================

settings.py
-----------

.. sourcecode:: python
    :linenos:

    # Django settings for tutoriel project.

    DEBUG = True
    TEMPLATE_DEBUG = DEBUG

    ADMINS = (
        # ('Your Name', 'your_email@domain.com'),
    )

Je vous fais grâce du code html de rendu, surtout que pour le moment, je n'ai pas de coloration syntaxique (cf Pygments et ReST Partie 2)

mercredi 31 octobre 2007

Lecture : Petit guide à l'usage du développeur agile

Par NiCoS le mercredi 31 octobre 2007, 00:06 - WWW, NTIC & Co

Je n'en finis pas de mes lectures. Dernier livre donc sur ma liste : Petit guide à l'usage du développeur agile.

Le livre m'a bien plu et surtout les derniers chapitres sur le Test Driven Development (TDD), Document Driven Development (zut, pas de bon lien à mettre) (DDD) et la gestion de projet. La partie sur Python en tant que telle m'est globalement passée au dessus de ma petite tête du fait de mon niveau actuel sur le langage (j'ai néanmoins glané quelques trucs ici et là, directement applicable dans mes dev en cours).

Ce livre ne vous aidera pas à appréhender python (enfin moi, cela ne m'a pas aider) et à la limite il n'aborderait pas python, ce ne serait pas grave. L'intérêt du livre n'est pas là mais bien dans les conseils, méthodo, bonnes pratiques qui sont énumérées. Bon faut quand même l'avouer, quand on voit comment TDD et DDD s'appliquent à Python, ça laisse rêveur (et l'équivalent n'existe pas pour PHP ou même Ruby apparemment, surtout pour DDD).

Les seules choses que j'ai trouvé un peu pénible dans le livre tiennent plutôt sur la forme (le formatage du code pourrait être amélioré, pas mal de typo/fautes d'orthographe, etc.)

En tous cas, à lire pour tout (bon) développeur / chef de projet qui se respecte !

D'autres critiques du livre :

samedi 20 octobre 2007

mod_wsgi disponible pour Arch

Par NiCoS le samedi 20 octobre 2007, 22:40 - Trucs de geek

Je viens juste de soumette mon troisième paquet pour ArchLinux, à savoir mod_wsgi.

mod_wsgi est un module pour le serveur web Apache et se veut une alternative à mod_python ou mod_fastcgi/mod_cgi pour les applications python. Il a pour objectif de supporter toute application compatible WSGI (Trac, Django, etc).

Il se veut plus performant que mod_python et fonctionne sous deux modes :

  • Un mode "embarqué", de façon similaire à mod_python, mod_php, etc : les applications wsgi partagent les mêmes process Apache que les applications utlisant les modules php, perl, etc.
  • Un mode "service", de façon similaire à mod_fastcgi : ce mode permet d'isoler les applications wsgi des autres applications hébergées. Ainsi les process Apache ne sont pas surchargées par le modules pour rien. Dans ce mode, mod_wsgi pourrait donc être utilisé dans le cadre d'un hébergement mutualisé par ex.

Voilà pour une présentation rapide du mod_wsgi. Pour le reste, je vous invite à consulter la documentation en ligne.

mercredi 7 février 2007

Devez-vous innover ou vous contenter de suivre la tendance générale ?

Par NiCoS le mercredi 7 février 2007, 21:07 - WWW, NTIC & Co

Billet publié originellement sur le blog de Clever Age : Devez-vous innover ou vous contenter de suivre la tendance générale ?. Pour la petite histoire, ça m'a permis de gagner un Ipod Nano ;-)

Tel est le paradoxe quotidien de l’informatique (mais pas uniquement). A l’heure du web 2.0 subsistent des applications client/serveur et AS/400 à plus ou moins juste titre. Avec le web 2.0 est arrivé le buzz autour de la société 37signals et de ses applications Basecamp ou encore Ta-da list basé sur le framework Ruby on rails. A contrario, dans les grandes sociétés françaises et internationales, les seules technologies présentes sont J2EE, .Net et dans une moindre mesure PHP (ce dernier a su acquérir ses lettres de noblesse ces dernières années). En dehors de ces technologies, point de salut. Nous pourrions nous dire que toute société de services se doit alors de maîtriser ces technologies pour pouvoir accompagner des grands comptes dans leurs projets. Pour autant, ces mêmes sociétés de services doivent-elle se priver de ces nouveaux outils qui ont fait et font leurs preuves au jour le jour ?

Il y aura toujours des partisans du "ma société fera uniquement du Java/PHP/.Net". Ce positionnement peut paraître raisonnable et raisonné pour une société s’adressant à des grands comptes :

  • Les grands comptes lancent des projets quasi uniquement sur ces technologies,
  • les compétences python (utilisé dans les frameworks Django, Turbogears, etc) ou ruby (utilisé dans le framework Rails) sont assez peu présentes en France et lorsqu’elles existent, elles sont concentrées dans un petit nombre d’entreprises (dans le cas de python). Pour ruby, cela est encore plus vrai. Dès lors, il pourrait paraître risqué pour une entreprise de se lancer dans un projet utilisant un de ces deux langages.
  • Ce manque de compétences s’explique par un manque de formation à ces langages. Les technologies les plus demandées étant Java, PHP et .Net, les développeurs et les établissements de formation ont donc naturellement privilégié ces langages. Nous pourrions donc tout à fait voir des changements d’ici quelques années avec le succès actuel que connait ruby/rails notamment mais aussi python dans cette ère du web 2.0.
  • Le langage python a en outre été mis à mal lorsqu’un de ses promotteurs, Nuxeo, a finalement décidé de passer sa solution CPS sous Java en lieu et place de Python/Zope.

Pour autant, et sans pour autant céder aux sirènes du web 2.0 ou au coté "hype" de ces frameworks, je pense que toute société de services se doit d’évaluer ces frameworks et langages et le cas échéant investir dedans. Je ne dis pas pour autant qu’il faille abandonner des technologies comme Java, PHP ou .Net, loin de là. Ces nouveaux langages et frameworks peuvent répondre à certains besoins non couverts par les autres ou bien de façon plus rapide. Ce serait quand même bête de s’en priver, non ?

Dès lors, malgré ces faiblesses conjoncturelles (manque de compétences ruby / python), il peut être opportun pour une société de services d’investir dans ces langages. Il lui reste ensuite à adapter son langage commercial pour prendre en compte ces nouvelles possibilités. C’est à la société de services de bousculer alors un peu les choses et de convaincre son client (sous réserve que ce dernier n’ait pas de contraintes technologiques à respecter) que son projet peut tout à fait être fait avec ces nouveaux frameworks, non pas pour des raisons de mode mais parce que ceux-ci sont fiables, répondent totalement au besoin du client, permettent de réaliser le projet dans un délai plus réduit que tel autre framework Java/PHP/.Net, etc.

Si la société de services n’apporte pas l’innovation source de valeur pour son client, qui le fera ?

8 commentaires

- page 1 de 2