Le petit coin de Nicolas

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

Lecture : Beginning CouchDB

J'ai profité de mes vacances pour finir la lecture de "Beginning CouchDB" de Joe Lennon.

D'un point de vue global :

  • Le livre mérite bien son nom, on part de l'historique de CouchDB jusqu'à faire des choses relativement avancées en passant par l'installation, la première base, les premiers documents et leur manipulation. Le sujet aborde également basiquement le développement avec CouchDB en python / ruby ou dans un projet Django.
  • Les propos sont clairs et les exemples en conséquence. Je recommanderais donc ce livre à un débutant (quoique sur le développement, il est vite obsolète sur couchapp a minima ; je ne connais pas assez les autres librairies mentionnées). Sur CouchDB en tant que tel, même si les version 0.10 et 1.0 sont sorties depuis, cela n'est pas encore trop pénalisant à ce stade je pense pour une première intro à CouchDB.
  • Comparativement à "CouchDB, the definitive guide", je l'ai trouvé plus concret, plus pratique. Un peu moins haut niveau en fait... Du coup, il faut bien lire les deux ;-)

Pour ma part, avec l'expérience que j'ai à ce jour de CouchDB :

  • Ce sont surtout les chapitres sur les utilisations avancées qui m'ont permis d'apprendre / clarifier certains points comme les "Views collations", le paramètre include_docs, le principe de map/reduce ou certains points de JSON.
  • J'aurais bien aimé que ce livre arrive il y a un an à mes débuts sous CouchDB l'année dernière.

Concernant mes développements sous CouchDB, maintenant que Couchapp commence à avoir une doc digne de ce nom, je vais peut être pouvoir m'y remettre prochainement...

Construire votre atelier logiciel python - Suite : Mercurial

Ce billet va être orienté sur le gestionnaire décentralisé de source mercurial (aka hg). Dans le précédent billet, nous avions juste installé le logiciel Mercurial. Il est temps de le paramétrer.

Paramétrage de base

Créons un dépot mercurial de zéro :

workon <envt>
cd Projets/Python
hg init testhg

Le contenu de ce dossier est vide à l'exception d'un dossier .hg qui contient tout votre historique et configuration de votre dépôt mercurial (les utilisateurs de svn seront un peu déboussolés car ils ne trouveront pas d'équivalent aux répertoires .svn un peu partout dans l'arborescence du projet ;-) )

Créer le fichier .hg/hgrc (si vous avez cloné un dépôt, celui-ci existe déjà avec la référence du dépôt cloné pour d'éventuelles interactions futures) et vous pouvez y ajouter plein de choses dont notamment :

  • Des paths qui vous permettent de définir facilement où sont le(s) dépôts mercurial de votre projet. Dans mon cas, "default" est sur mon serveur privé et "bitbucket" correspond à l'espace projet sur Bitbucket. La commande hg push enverra par défaut sur le dépôt "default". Si je veux pousser sur mon dépôt bitbucket, il me faudra saisir hg push bitbucket. C'est toujours plus sympa à taper que l'url complète du dépot à chaque push.
  • Un "username" qui fait que vous pouvez spécifier un compte pour vos commits ; sinon mercurial prend votre login système comme référence.
[paths]
default = ssh://login@server.com/hg/project/
bitbucket = ssh://hg@bitbucket.org/login/project/

[ui]
username = login

C'est le minimum syndical pour un dépôt mercurial à mon sens. Il existe plein d'autres options pour le fichier hgrc, ainsi que la liste des extensions de mercurial

Premières intéractions avec mercurial

Pour ajouter un fichier :

echo "Test Mercurial" > README
hg st # pour hg status
? README
hg add README # pour ajouter le fichier README dans le référentiel

Pour ajouter un ensemble de fichier (marche aussi avec une sous-arborescence)

for i in 1 2 3; do echo "Test Mercurial $i" > README-$i; done
hg st # on voit que le fichier README est bien ajouté et que les autres sont inconnus du référentiel
A README
? README-1
? README-2
? README-3
hg add # si pas de fichier précisé, on ajoute tous les fichiers inconnus du référentiel
adding README-1
adding README-2
adding README-3

Pour commiter les fichiers dans le référentiel :

hg commit -m "Import Test"

Pour contrôler le dernier commit :

hg tip
changeset:   0:830fddaa0d2f
tag:         tip
user:        login
date:        Mon Jul 19 22:49:50 2010 +0200
summary:     Import Test

Publier en une fois sur plusieurs dépôts

Les hg push && hg push bitbucket, cela va un moment. Il faudrait trouver un moyen plus sympa de publier en une fois sur tous les dépôts référencés. Pour cela, l'extension publishall est votre amie.

Une fois le fichier publishall.py récupéré, il suffit d'enrichir votre fichier .hg/hgrc de la façon suivante :

[paths]
default = ssh://login@server.com/hg/project/
bitbucket = ssh://hg@bitbucket.org/login/project/

[ui]
username = login

[extensions]
publishall = /path/to/extensions/hg-publishall/publishall.py

Au prochain commit, il vous suffira de faire un hg pusha pour publier sur l'ensemble de vos dépôts.

Installation de hg-git

Si vous voulez travailler avec github tout en conservant mercurial, c'est possible :

easy_install hg-git # Cela ne semble pas fonctionner à ce jour avec pip...

Dans le fichier .hg/hgrc de votre projet :

[paths]
default = ssh://login@server.com/hg/project/
bitbucket = ssh://hg@bitbucket.org/login/project/
github = git+ssh://git@github.com/login/project

[ui]
username = login

[extensions]
hgext.bookmarks =
hggit =
publishall = /path/to/extensions/hg-publishall/publishall.py

[git]
intree = True

Ensuite, après avoir créé bien sur votre projet sur github :

hg push github

Et votre code est alors disponible sur Github.

Publier son propre code via hgweb

Voir le tutoriel "Installer l’interface web de consultation d’un dépot mercurial" ;-)

D'autres choses à partager sur Mercurial ?

Lecture : Scrum, le guide pratique de la méthode agile la plus populaire

Je viens de finir la lecture de l'ouvrage Scrum, le guide pratique de la méthode agile la plus populaire, rédigé par Claude Aubry et j'ai trouvé ce livre passionnant et très intéressant.

Le livre s'adresse à toute personne impliquée dans des projets de développement, qu'il soit familiarisé ou pas avec Scrum. La personne familiarisée avec Scrum pourra sauter ou lire en diagonale les premiers chapitres le cas échéant.

J'ai aimé :

  • La présentation du cadre Scrum : chaque élément est très bien décrit, que ce soit les phases, les rôles, les artefacts, etc. Et sa mise en perspective avec les autres éléments se fait aisément. La lecture du livre est très progressive et permet de consolider progressivement son appréhension de Scrum.
  • Le coté pragmatique dans la présentation de Scrum : l'auteur fait part d'un certain nombre de retours d'expérience et il indique aussi les libertés parfois qu'il a pris par rapport au cadre originel de Scrum
  • Le coté pragmatique de Scrum : je ne sais pas si cela tient à Scrum ou à la façon dont l'auteur le présente mais j'ai l'impression que Scrum permet la prise en compte d'un contexte. Peut-être parce qu'il s'agit plus d'un cadre que d'une méthodologie pure et dure, mais déjà Scrum ne couvre pas tous les aspects et l'assume pleinement ; Scrum s'appuie alors sur des techniques / méthodologies complémentaires comme la gestion des exigences (en aval d'un projet Scrum) ou bien l'intégration continue ou l'approche de développement pilotée par les tests (TDD). Ensuite, Scrum a l'air plus flexible vis à vis d'un contexte donnée afin de l'adopter progressivement et d'en tirer le meilleur à un instant T en fonction de ce que l'on a pu mettre en place de ce cadre. Deux chapitres traitent notamment d'adapter Scrum au contexte mais aussi de celui de la transition d'une équipe/organisation à Scrum.
  • La présentation d'un outil Scrum en fin de parcours qui permet de donner un coté pratique aux points évoqués précédemment. Cela fait un peu office de note de synthèse (bon par contre, lire le framework Symphony, ça doit en faire tilter plus d'un ;-) )

J'aurais aimé :

  • Peut être l'étude d'un cas pratique tout au long du livre (en gros le cas OMEGA aurait pu être abordé à chaque fin de chapitre, plutôt que tout à la fin dans le cadre de la présentation d'un outil Scrum).

Ce que j'en retire :

  • Une bien meilleure appréhension / compréhension de Scrum et me conforte dans l'idée que ce cadre pourrait bien m'aider dans mon projet collaboratif actuellement. Le planning et mon manque d'expérience Scrum vont me faire défaut. Toutefois, la stratégie adoptée pour le projet s'en rapproche par certains coté. A voir ce que l'on peut insérer comme éléments du cadre Scrum dans le projet ;-)
  • Un argumentaire pour aller voir certains collègues et supérieures pour promouvoir cette approche ; Du scrum sur la gestion des sites web vélos en libre service ne ferait pas de mal par exemple (plutôt que ce côté à l'arrache)

Je vais voir pour appliquer ce cadre à mes développements personnels, même si l'accumulation des rôles sur une seule personne ne me permettra pas de voir certaines subtilités ou risque de me faire prendre de mauvais plis. Reste à voir pour une formation Scrum dans le cadre du boulot ;-)

Dans tous les cas, ce livre est définitivement un "must read" pour tout développeur, chef de projet ou utilisateur.

Le mal est à la racine

Pour se changer les idées et s'occuper en cette période chaude, un petit coup de Polar-Geek :-)

Le téléphone sonna. Je sortais de ma torpeur post déjeuner :
"Tu peux venir immédiatement dans mon bureau ?"
"Euh, oui, j'arrive..."

Damn, si le Grand Chef m'appelle et précise un "immédiatement" c'est que cela doit être grave. Que s'est-il passé encore ? Malgré ce "immédiatement", je pris quelques secondes pour faire le tour des consoles de monitoring. A priori, ce n'était pas un problème système. Déjà ça de pris. Je fonçais donc vers l'ascenceur pour monter au 6ème étage. Quand il s'ouvrit, je me dirigeai droit vers la salle du fond en remarquant une grande quantité de chaises vides. Soit tout le monde était parti mais c'était un peu tôt, soit c'était la catastrophe du siècle. En rentrant dans le bureau du Grand Chef, je fus fixé. Tous les chefs de département de la DSI étaient réunis. Apparemment, cela devait durer depuis quelques heures au vu de la chaleur ambiante, du paperboard barbouillé dans tous les sens et des gobelets de café qui s'entassaient.

Le Grand Chef, assis dans un coin de la salle, m'annonça :

"Merci pour ta promptitude. Je suppose que tu as regardé le monitoring avant de monter. Tu sais donc déjà que le problème n'est pas là. Si je t'ai fait venir, c'est parce que cette nuit, à quelques heures du lancement de notre nouvelle éponge, quelqu'un de chez nous a volontairement saboté l'application Kicifrot. Nous nous en sommes aperçus à 9h en arrivant pour un dernier et ultime contrôle, même si tout avait été validé officiellement hier soir. Le saboteur a utilisé notre outil de déploiement pour envoyer sur notre plateforme de production une version antérieure à celle prévue. Depuis 9h, deux actions ont été menées :

  • Mise en place d'une nouvelle infrastructure pour redéployer la version finale de Kicifrot et être prêt pour le lancement du produit à midi.
  • Analyse de la version déployée cette nuit pour voir qu'en plus d'un bug qui a été corrigé par la suite, cette version contenait un backdoor permettant de planter l'application dans sa globalité d'une part et d'autre part de collecter les informations bancaire de nos clients.

La situation est maintenant corrigée et tout est opérationnel..."

Le Grand Chef laissa planer un moment de silence et alla se chercher un verre d'eau. J'en profitais pour digérer les informations communiquées : la catastrophe semblait avoit été évitée et tout semblait sous contrôle. Mais qu'est-ce que j'ai à faire là-dedans moi ? La réponse n'allait pas tarder à venir...

"Nous avons isolé les machines impactées par le sabotage. Je veux que tu me trouves notre saboteur ! Messieurs, vous vous mettrez à la disposition de notre petit camarade et considérez que toutes ses demandes sont à considérer comme si c'étaient les miennes" dit-il aux chefs des départements. "Personne ici, ni de vos équipes, ne rentre chez lui tant que le saboteur n'est pas trouvé ; Week-end prolongé ou pas. Allez, circulez et allez prévenir vos équipes !"

Les chefs des départements s'exécutèrent et quittèrent la salle. Alors que je commençais à me retourner pour rejoindre mon antre, une voix me dit : "Je veux ce fumier, tu m'entends ? Tu as carte blanche et tu peux bloquer tous les employés de la société le temps qu'il faudra... Maintenant, sache aussi que ma fille fête son anniversaire ce week-end et qu'il n'est pas prévu que je le rate. Bonne chance...."

Ah sa fille. Le bien le plus précieux du Grand Chef. Son point faible. 5 ans et espiègle comme tout. Elle fera souffrir des garçons celle-la. Il me restait donc 6 heures pour trouver le saboteur ou alors cela sentirai le roussis pour tout le monde si le Grand Chef devait ne pas assister à l'anniversaire de sa fille... Je retournais fissa dans mon bureau. Je venais de recevoir un mail des Admin Sys m'indiquant les nouvelles IP des serveurs sabotés. Je me connectais dessus pour trouver des informations utiles. Je fus vite bredouille. Comme je le craignais, toutes les connexions SSH étaient émises depuis la même passerelle et avec le même utilisateur : "root". Toujours la même chose, je ne cessai de les mettre en garde contre cette pratique depuis des années et elle était toujours là. Je me résignais alors à ne pas trouver mon coupable sur ces machines...

En me connectant sur la passerelle, je notais que le prompt n'était pas celui défini en standard. Encore quelqu'un qui s'est amusé avec songeais-je en me précipitant vers les fichiers de log pour en apprendre plus. Je commençais par les fichiers de l'outil de déploiement ; grand bien m'en pris car même si le saboteur avait supprimé quelques fichiers de logs de déploiements pour cacher ses méfaits, il avait oublié un fichier annexe, peu utile mais qui stockait juste l'horaire et la commande passée. Je trouvais donc que mon saboteur avait déployé quatre paquets entre 3h20 et 3h38. En continuant à analyser les fichiers de logs, et après avoir éliminer différentes IP / compte liés à des opérations de nuit, je tenais mon coupable à la limite près qu'il avait utilisé un poste en libre service placé près de la cantine et de l'accès aux parkings. Il allait me falloir traverser tout le site pour en savoir plus.

En arrivant sur le PC en libre-service, qu'elle ne fut pas ma surprise de voir que l'écran était hors-service. Après prise de renseignement, cela datait de plusieurs jours. Ainsi, mon saboteur n'avait pas pu utiliser le poste en tant que tel. Il ne lui restait que la connexion en mode Terminal Server. Je repartais donc dans mon bureau, me connectait à la machine en question en TSE et épluchait le journal d'évènements. Je le tenais enfin mon coupable. J'appelais alors le Grand Chef et lui demanda de convoquer tout les employés dans le grand amphithéâtre.

Je fis une dernière vérification en me connectant au service RH pour conforter mon opinion. Non seulement il s'était connecté avec son login en TSE sur le poste en libre service mais le relevé du parking était formel également. Je pris alors la direction de l'amphithéâtre.

La salle était comple et je me dirigeais vers la scène sous les yeux observateurs de mes collègues. Je pris le micro et annonça :

"J'ai l'identité de notre saboteur. Je peux même dire DES saboteurs, car oui parfaitement ils sont plusieurs à être complice de ce sabotage"

Un mouvement de recul et un bruit parcoururent la foule puis le silence revint. Le Grand Chef m'indiqua de continuer d'un mouvement de tête.

"Je vais commencer par les complices dans un premier temps" indiquai-je.

"Tout d'abord messieurs les admin systèmes pour utiliser le même mot de passe root partout. Sans ce point, le saboteur, ne faisant pourtant pas partie des équipes techniques, n'aurait pu accéder à nos machines. Je ne m'étendrais pas sur cette faute professionnelle qui relève du premier cours de première année d'étude réseau... Vous êtes complice de cette histoire de part votre négligence !!"

"Je disais précédemment que notre saboteur n'est pas membre des équipes techniques et n'a pas eu besoin d'un soutien d'un membre des équipes techniques car il est suffisamment aguerri par lui-même et que par ingénierie sociale, il a pu récupérer l'ensemble des informations des développeurs eux-mêmes. Il a ainsi pu accéder au code puis préparer et injecter son code à l'insu de tout le monde. Messieurs les développeurs, vous êtes les seconds complices pour ne pas avoir tenu vos langues et pour permettre le commit anonyme sur votre dépôt de sources... Vous ne valez guère mieux que nos admins sys que vous raillez au café..."

"Mais venons-en à notre vrai coupable. Il s'agit de notre cher contrôleur de gestion M. Racine. Il était brillant d'utiliser le PC en libre service mais il aurait fallu voir que l'écran était cassé et surtout ne pas utiliser votre compte pour s'y connecter. Enfin, de même, sachez que même si la barrière du parking est ouverte vu qu'elle est cassée, cela n'empêche pas le détecteur de voiture de scanner la votre à chaque passage... D'ailleurs, je suppose que l'on tient aussi notre destructeur de barrière de parking..."

La foule était médusée par mes révélations et un cercle s'était fait autour de M. Racine. Celui-ci me rendit un regard plein de haine mais restait muet.

"Je pose sur ce bureau l'ensemble des documents permettant de confondre M. Racine. Personnellement, j'en ai fini et je dois me rendre à un rendez-vous..."

Le Grand Chef me gratifia d'un regard qui valait remerciement. Il demanda aux Services Généraux d'accompagner M. Racine jusqu'à son bureau pour discuter avec lui des détails de l'histoire. Je me retournais alors vers lui :

"N'oubliez pas l'anniversaire de votre fille... M. Racine peut attendre quelques jours..."

Suite...

J'ai l'opportunité de délaisser mes tâches d"intégration pour évoluer vers un poste de chef de projet autour des solutions collaboratives, et plus particulièrement sur les réseaux sociaux d'entreprise (RSE) dans l'immédiat. Certains ont pu remarqué ce nouveau centre d'intérêt de part des bookmarks/tweets orientés communautés / "Entreprise 2.0" ces dernières semaines. En tâches de fond, deux activités issues de mon "ancienne" activité :

  • Industrialisation des solutions web, et plus particulièrement sur leur déploiement,
  • Support des équipes opérationnelles (phase de déploiement, etc).

Au sujet des RSE / Communautés, quelques ressources que je trouve utiles (si vous en avez d'autres à me suggérer, ne pas hésiter) :

  • Référentiel USEO & @Ref_USEO : une sorte de QSOS des solutions de gestions de contenus, portails, de travail collaboratif et RSE. Il porte tant sur la formalisation des usages que sur l'évaluation des solutions (et par conséquent de leur adéquation face à des types d'usages). Pour la petite histoire, il se trouve que j'ai travaillé avec le fondateur d'USEO Arnaud Rayrole lorsque j'étais chef de projet chez Linagora (comme quoi le monde est vraiment petit...)
  • Bertrand Duperrin (blog & @budperrin)
  • Anthony Poncier (blog & @aponcier ; même si pour le coup suivre ses tweets relève d'un ETP ;-) )
  • Cédric Deniaud (blog) avec un positionnement plus média / communautés externes que RSE / communautés internes.
  • Antoine Dupin (blog)
  • Carlos Diaz (@CarlosDiaz), fondateur de la solution SaaS BlueKiwi mais qui ne se limite pas à sa promotion...

Ce blog devrait donc refléter ces évolutions et je ne désespère pas à titre perso de reprendre certains développement entamés sur Django et/ou CouchDB. Les prochains billets devraient porter d'ailleurs sur le coté "Entreprise ready" de certaines solutions et sur la revue de lecture du livre "SCRUM : Le guide pratique de la méthode agile la plus populaire".

Lecture : La méthode Google ; Que ferait Google à votre place ?

Olivier, il y a de cela quelques temps, a recommandé deux livres que j'ai fini par acheter. J'ai commencé par "La méthode Google : que ferait Google à votre place ?" de Jeff Jarvis.

Globalement, je suis assez mitigé sur le livre :

  • Déjà ce n'est pas un livre sur Google - si c'est ce que vous recherchiez, passez votre chemin. (Cela n'était pas mon cas)
  • Il a le mérite d'évoquer les lois de Google (ou en tous cas les lois que Jeff Jarvis associe à Google). On y apprend rien en tant que tel mais au moins elles sont annoncées et se révèlent assez justes / pertinentes. Pour des gens qui ont une fibre opensource, il y en a pas mal qui vont de soi, même si les appliquer en entreprise ne va pas de soi par contre.
  • Appliquer la méthodologie Google à un certain nombre de secteurs d'activité traditionnels est assez intéressant comme démarche. Cela doit pouvoir donner des idées à beaucoup de monde sur des pistes de réflexion et éventuellement améliorer sa société.
  • Pour résumer le fond est plutôt intéressant mais j'ai trouvé la forme insupportable et très pénible à lire. L'auteur passe son temps à raconter sa vie ou à faire valoir telle ou telle personne. Du coup, le fil conducteur est un peu perdu parfois. Pour un journaliste, on pouvait espérer mieux... D'ailleurs comme indiqué dans certains commentaires sur Amazon, le livre pourrait s'appeler "Que ferait Jarvis ?" ; ceci est conforté par les "lois de Jarvis" mentionnés dans le livre.
  • Moi qui d'habitude dévore les livres, je crois que j'ai jamais mis autant de temps pour lire un livre de cette taille ( < 400 pages). Je recommanderais sans aucun doute ce livre s'il était réécrit de façon plus synthétique. Là pour le coup, je vous laisse choisir de le lire ou pas.
  • Peut-on appliquer des lois de Google en entreprise ? Je pense que oui. En lisant le livre, j'ai pensé à plein de choses qui pourraient s'appliquer dans mon quotidien à JCDecaux, au niveau de l'entreprise / de ses produits. Je pense notamment que certaines lois appliquées sur les systèmes vélos pourraient avoir un intérêt non négligeable sur l'image de la société ou bien sur la valeur de ce que l'on peut en tirer.

Reste maintenant à savoir si je continue sur Beginning CouchDB, SCRUM : Le guide pratique de la méthode agile la plus populaire ou encore Free ! et ce, en attendant qu'Olivier nous fasse un retour sur Start with why. ;-)

Pour échapper au fsck au prochain redémarrage de votre machine.

Plusieurs solutions :

  • Via l'argument -f de la commande shutdown. Attention, l'argument -F force le fsck au démarrage - ne pas se tromper dans la casse ;-)
  • Créer un fichier /etc/fastboot ; attention il sera supprimé suite au reboot. Si vous voulez échapper perpétuellement au fsck lors d'un redémarrage, il faut donc le (re)créer à chaque fois.
 
touch /etc/fastboot
chmod 0 /etc/fastboot

Faudrait que j'arrête de publier des tutoriels/astuces/... ici mais plutôt dans l'espace prévu à cet effet mais le manque de flux RSS lié à un espace documentaire sphinx ne m'y encourage pas :-(

Migration Slackware 13.0 vers 13.1

Ne supportant pas de ne pas être à jour, à peine Slackware 13.1 sorti que je me suis empressé de mettre à jour à distance mon linutop.

En partant des notes d'UPGRADE.txt, j'ai fait la chose suivante et ça marche :

  • Modification de /etc/slackpkg/mirrors pour pointer sur une arboresence en 13.1 + slackpkg update
  • Mise à jour des programmes de base :
slackpkg upgrade pkgtools tar findutils xz
slackpkg upgrade glibc-solibs
slackpkg upgrade slackpkg
slackpkg install-new (qui pour le coup m'installe des trucs dont j'ai pas besoin mais passons... j'ai la flemme de trier)

Suppression des paquets obsolètes (certains ne sont pas installés, pas grave) :

removepkg bluez-libs bluez-utils cupsddk device-mapper epic4 gqview \
    kdelibs-experimental lbxproxy libgtkhtml liblbxutil libungif \
    libv4l loadlin mpg321 mplayerthumbs proxymngr xf86-input-citron \
    xf86-input-elographics xf86-input-fpit xf86-input-hyperpen \
    xf86-input-mutouch xf86-video-newport xf86-video-xgixp

Mise à jour des autres paquets :

slackpkg upgrade-all

Dans les modifications des fichiers de conf, attention notamment à /etc/rc.d/rc.inet1.conf si vous ne voulez pas perdre votre conf réseau ;-)

Modification des entrées /dev/hd* par /dev/sd* comme indiqué dans le "LIBATA SWITCHOVER" de CHANGES_AND_HINTS.TXT ou en reprenant ma méthode.

Coup de bol : sur mon linutop, je suis déjà en /dev/sd* par contre, je n'échappe pas à l'initrd à regénérer...

Et après un reboot : ça marche...

Facebook : fin de compte

Devant les failles et l'exposition de ses données que je juge inadmissible sur Facebook et les entorses à la vie privée (même s'ils veulent promouvoir des nouvelles habitudes en terme de vie sociale sur le net), je viens de supprimer mon compte.

Liste non exhaustive :

Pour ceux qui veulent également supprimer (et non simplement désactiver leur compte facebook) : Delete account. Il sera préalablement désactivé pendant 15 jours avant d'être effacé définitivement.

Tant pis, je ne serais plus "mainstream" :-P

Ca me renvoit à Ces données que l'on aime tant et sa suite. Va falloir que je dépoussière tout ça ; par contre ça fait plaisir de voir que Status.net répond à peu près au cahier des charges :-)

A ce sujet, Geek & Poke publie un dessin très symbolique : 2040

Edit du 6/5 matin : Intéressant, je viens de tomber sur la présentation du projet Diaspora qui vise à faire un facebook opensource et décentralisé. A suivre...

Créer son atelier de développement logiciel Python

Aide mémoire pour la confection d'un atelier logiciel autour de Python. Il sera complété au fur et à mesure...

Pré-requis :

  • pip ; un sudo easy_install pip doit fonctionner si setuptools est installé.

Installation de Virtualenv & Virtualenvwrapper

Virtualenv permet de créer des environnements virtuels python avec les librairies de votre choix. Vous pouvez avoir un environnement virtuel pour chaque version de DJango (dj-096, dj-100, dj-110, dj-120, etc) et contre lesquels vous allez pouvoir tester l'application que vous développez. L'autre avantage est que l'on peut installer ce que l'on veut comme librairie python, sans avoir de droit système. De mémoire, on doit même pouvoir utiliser plusieurs versions de python si besoin. Bref, l'idéal pour des tests et ne pas pourrir son système global :-)

Virtualenvwrapper est l'outil pour les fainéants qui utilisent virtualenv puisqu'il simplifie l'utilisation de virtualenv. Il y a des options assez sioux ; se reporter à la documentation

sudo pip install virtualenv virtualenvwrapper

Dans votre fichier $HOME/.bashrc :

# Création du répertoire accueillant les environnements virtuels
export WORKON_HOME=$HOME/python/virtualenv
# Instructions spécifiques pour l'usage de PIP
export PIP_VIRTUALENV_BASE=$WORKON_HOME
export PIP_RESPECT_VIRTUALENV=true
# Chargement des commandes fournies par virtualenvwrapper 
. /usr/bin/virtualenvwrapper.sh

Ensuite dans votre console :

# Création du répertoire accueillant les environnements virtuels
mkdir -p $HOME/python/virtualenv
# Prise en compte des modifications réalisées précédemments
source $HOME/.bashrc

avec pour résultat :

virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/initialize
virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/premkvirtualenv
virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/postmkvirtualenv
virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/prermvirtualenv
virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/postrmvirtualenv
virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/predeactivate
virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/postdeactivate
virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/preactivate
virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/postactivate

Création de son premier environnement virtuel

mkvirtualenv demo
New python executable in demo/bin/python
Installing setuptools............done.
virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/demo/bin/predeactivate
virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/demo/bin/postdeactivate
virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/demo/bin/preactivate
virtualenvwrapper.user_scripts Creating /home/nsteinmetz/python/virtualenv/demo/bin/postactivate

Sur votre prompt, vous devez voir un petit (demo) apparaître indiquant que vous utilisez cet environnement :

Avant :

[nsteinmetz@citrouille ~]$

Après :

(demo)[nsteinmetz@citrouille ~]$ 

Comme tout projet doit avoir sa documentation et être versionné, installons sphinx et mercurial.

pip install sphinx mercurial

Il ne vous reste plus qu'à installer les autres librairies dont vous avez besoin.

Pour sortir de votre environnement, il suffit d'utiliser la commande deactivate.

Pour revenir dans votre environnement, il faut utiliser la commande workon :

  • Si vous n'avez qu'un environnement virtuel (comme dans notre cas) alors vous basculez automatiquement dans cet environnement
  • Si vous avez plusieurs environnements virtuels, alors workon liste les environnements disponibles. Pour en activer un en particulier, il faut préciser son nom ; dans notre cas workon demo.

To be continued... et je suis preneur de vos retours / idées / ...

- page 1 de 21

Bienvenue

Ce blog en actuellement en cours de travaux :-)

Pour les liens en tous genre, voir en haut & pied de page