Un Electron Libre...

Intégration : Recette interne

NiCoS — Wed, 27 Aug 2008 17:49:00 +0200

La recette arrivant en bout de course d'un projet, elle est souvent sacrifiée pour compenser les retards de développements pour des bonnes et/ou mauvaises raisons. Il arrive donc souvent que la version livrée en recette a peu été testée (voir pas du tout ou pas de façon suffisamment significative).

Cela conduit à différentes choses :

Les jours payés par le client ne sont pas utilisés à cet effet,
L'effort de recette coté client explose puisqu'il doit assurer la recette en lieu et place du prestataire
L'effort de recette coté presta va également exploser coté prestataire et non être réduit comme escompté car il aura (souvent) tendance à :
- multiplier les livraisons correctives partielles
- générer de nombreux aller/retour pour cause de non-correction voir régression
- exploser le cout de livraison (packaging, documentation, etc)
Désorganise tant le prestataire que le client du fait de cette charge à absorber dans des plannings qui ne le permettent pas forcément
Au final, une tension croissante va pourrir les relations entre le client et le prestataire, sans compter la démotivation croissante de part et d'autres pour faire avancer le projet. Sans compter que cela ternit l'image de marque du prestataire et peut mettre fin à tout travail potentiel entre le prestataire et le client.

Au final, tout le monde est clairement perdant.

Quelques pistes d'amélioration :

Mieux estimer les périodes de recette (structurellement sous estimée) et qu'elle fasse partie du budget du projet. A croire qu'annoncer une période de recette est une honte en matière de programmation... Attention, il faut quand même que cette durée reste cohérente avec la taille/complexité de l'application.
Etre transparent/honnête avec son client en disant qu'il y aura un retard de livraison le temps de faire la recette. Après tout, c'est logique, le temps perdu au niveau du développement ne se rattrappe jamais par magie...
Mieux résister à la pression interne de livrer "à tout prix et/ou au plus vite" au client
Prendre le temps de faire cette recette
Coté presta, prévoir des zones tampons si des projets doivent se succéder afin qu'un retard sur un projet n'en condamne pas un autre. Cela suppose aussi que le chef de projet remonte les infos à temps à sa hiérarchie.
Dans le cas de plusieurs itérations, faire en sorte d'en avoir le moins possible pour ne pas se démotiver dans les phases de recette,
S'il y a des applications auxquelles se connecte le projet, soit vous êtes en mesure de mettre en place réellement cette plateforme chez le prestataire, soit il faut venir faire des tests d'intégration chez le client
Faire venir le prestataire sur site pour pouvoir travailler de concert et éviter les parties de ping-pong par mail ou téléphone,
Se dire que ce retard sera compensé par le fait que tout ce qui a été dit dans le paragraphe précédent ne se produira pas... ou dans une moindre mesure

Enfin, si le jour de la livraison il y a un retard de dernière minute ou une opération plus longue que prévue, prévenir le plus tôt possible le client et le tenir informé des éventuels reports de livraison. Ou alors se donner une vraie marge pour tenir les horaires. Cela évite en outre que le client excédé vous appelle pour savoir où vous en êtes et à quelle heure vous allez livrer.

Tout cela suppose également que le chef de projet ait une visibilité suffisamment bonne sur le travail de ces développeurs et qu'il connaisse suffisamment bien le produit sur lequel il travaille pour que ces estimations soient les plus justes possibles. Faute de quoi, il risque de se trouver dans une fort mauvaise posture (vécu inside).

A ce jour, une telle méthode m'aurait épargné un gros nombre des 100 bugs trouvés juste en cliquant à droite et à gauche (sans prendre en compte les specs fonctionnelles d'un projet) et les 5 livraisons que j'ai réduit à 3 intégrations. Je tairais le nom de la SSII, vu que ce n'est pas propre à cette SSII et que j'espère que d'autres équipes projets de cette SSII travaillent de façon plus satisfaisante. Pour avoir de l'autre coté, j'en garde également des mauvais souvenirs et des conditions de travail déplorables, se retrouvant entre le marteau (le client) et l'enclume (sa hierarchie).

Résolutions de rentrée

NiCoS — Tue, 26 Aug 2008 21:42:00 +0200

Faire avancer le projet Atome, surtout que la contrib "comments", nouvelle formule vient d'attérir dans django 1.0 beta2.
Me (re)mettre à faire de l'acquisition et du montage vidéo - vu les cassettes DV qui commencent à s'empiler; ce serait dommage de pas le faire, ni de les visionner. Enfin, je veux arriver à faire mieux que ma soeur sous Windows Movie Maker...
S'occuper de ces *** de dents de sagesse et analyses sanguines

Plus de résolution, ce serait du suicide... :-P

Intégration : Cahier de recette (cet ami qui vous veut du bien)

NiCoS — Thu, 21 Aug 2008 17:45:00 +0200

Je vais lancer une série "Intégration" dans laquelle je vais parler de points vue dans mon quotidien ou dans mon passé en SSII.

Cela faisait un moment que je voulais écrire ce billet, convaincu de plus en plus que le cahier de recette devient un élément de plus en plus crucial dans un projet informatique.

Idéalement, je vois une première version réalisée à l'issue de la phase des spécifications. Sans aller parler de "Test Driven Development" (Développement piloté par les tests, qui l'on peut résumer synthétiquement par le fait d'écrire les tests avant de coder quoi que ce soit), l'idée de rédiger le cahier de tests à l'issue de la phase de spécifications a tout son sens selon moi. Rédiger le cahier de recette (technique et/ou fonctionnel) à cette étape apporte les avantages suivants :

Cela permet de consigner par écrit ce qui semble parfois "tellement évident" à certains membres du projet et qui peut ne pas l'être pour d'autres ou bien pas si évident que cela (périmètre de tests, éléments à tester, conditions de tests, etc).
On peut s'apercevoir qu'il y a des manques dans les spécifications que l'on peut alors enrichir (règles de gestion, cas non imaginés de premier abord, etc) : imaginons par ex un intranet groupe avec une authentification intégrée, par défaut, on imagine très bien le cas du français se connectant sur l'application depuis son poste france, mais que se passe-t-il s'il se déplace dans une filliale pour laquelle l'authentification intégrée n'est pas en place ? L'utilisateur pourra-t-il se connecter malgré tout à l'application ?).
Dans le cas d'une relation avec un prestataire, cela évite les mauvaises surprises en phase de recette (le cas de recette 12, pourtant tellement évident coté client et absolument pas (pré)vu par le prestataire)
A l'issue de la phase de développement, vous pouvez demander au prestataire de vous indiquer le résultat de sa recette vis à vis de ce cahier de recette (qui aura pu être complété/détaillé entre temps).
Lors de la phase de recette, vous avez un référentiel sur lequel peut s'appuyer votre démarche de recette.

En tout état de cause, il est important de faire vivre votre cahier de recette : de test très macro (état initial > étapes > résultat) réalisés dans un premier temps, vous pourrez le compléter (nouveaux cas) ou bien le détailler/préciser ou encore définir des "sous-cas" de tests.

Il est également important de communiquer ce cahier de recette aux parties impliquées pour avoir leur réaction et échanger. Cela peut le cas échéant donner lieu à des avenants/aménagements des phases de développement (cas d'évolution). Le fait que ce soit dans votre cahier de recette ne veut pas forcément dire qu'il doit être accepté systématiquement par votre équipe de développement / prestataire ; en effet, si cela n'est pas dans le périmètre de départ ou a un impact trop significatif sur les développements, il vous faudra en discuter (c'est sur qu'en cas d'engagement au forfait...)

Pour être honnête, moi même en SSII, j'ai très peu appliqué cette méthode - seulement lors de mes dernières missions en AMOA lorsque j'étais en SSII ou pour un projet interne actuel chez mon actuel employeur. Dernièrement, lors d'un POC (Proof Of Concept / Prototype), j'avoue avoir été étonné que personne ne s'en est pré-occupé avant que j'en fournisse un - permettant d'ailleurs de découvrir le cas du français en déplacement dans une autre filliale par ex. Tout le monde savait qu'il fallait tester deux fonctions "authentification" et "indexation" et il a bien été démontré que cette soit-disant évidence des tests n'allait pas de soit sur de nombreux sujets ou tout bonnement sur le périmètre même du POC.

La seule explication au fait que cela ne soit pas plus utilisé à présent dans les méthodes de développement est un temps de spécification mal estimé conduisant à ce qu'il soit négligé / repoussé à la phase de tests. Vous en voyez d'autres (bonnes|mauvaises) raisons ?

Apache : authentification intégrée sauf pour certains clients dont on ne connait pas la provenance réseau

NiCoS — Thu, 21 Aug 2008 13:01:00 +0200

Cas d'étude : une application auxquels les collaborateurs d'une entreprise accèdent via une authentification intégrée. Pour les filliales ne disposant pas du SSO ou pour permettre à des utilisateurs extérieurs de se connecter à l'application, une connexion anonyme doit être mise en place.

Solution retenue :

Apache 2.2
mod_auth_ntlm_winbind pour l'authentification sur Active Directory via Samba / Kerberos
mod_setenvif

Principe : par défaut, le serveur va chercher à authentifier l'utilisateur par authentification intégrée.

Exception : pour l'indexation de l'application, il faut autoriser l'accès anonyme au serveur

Problématique : seuls les plages IP des pays utilisant l'authentification intégrée est connue. Il faut donc permettre l'accès en anonyme à tout le monde sauf ces IP là.

L'importance ici tient dans la directive Order, Allow , Deny, Satisfy et SetEnvIf.

LoadModule auth_ntlm_winbind_module modules/mod_auth_ntlm_winbind.so
LoadModule setenvif_module modules/mod_setenvif.so
 
<Location />
    Order Deny,Allow
    Deny From All
 
    <IfModule mod_auth_ntlm_winbind.c>
        AuthName "NTLM Authentification"
        NTLMAuth on
        NTLMAuthHelper "/usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp"
        NTLMBasicAuthoritative on
        AuthType NTLM
    </IfModule>
 
    Require valid-user
	<fModule mod_setenvif.c>
		# Declaration des clients utilisant l'authentification intégrée
		SetEnvIf Remote_Addr "10\.(10|13|14|19|20|44|45|49)\.[0-9]{1,3}\.[0-9]{1,3}" pays # Pays 1
		SetEnvIf Remote_Addr "10\.(70|18|48)\[0-9]{1,3}\.[0-9]{1,3}" pays # Pays 2
 
		# Declaration de l'IP du robot indexant le site
		SetEnvIf Remote_Addr "10\.135\.255\.(1|44|35|244)" indexation
	
		# Declaration de la machine pour generation du cache statique
		SetEnvIf Remote_Addr "(127\.0\.0\.1|10\.135\.255\.45)" local
		
		# Sont autorises en anonyme "tout le monde" sauf les pays avec authentification intégrée.
		Allow from env=local env=indexation !env=pays
	</IfModule>
	Satisfy any
</Location>

Lecture : Practical Django Projects

NiCoS — Sun, 17 Aug 2008 15:23:00 +0200

Je viens de finir la lecture de Practical Django Projects, écrit par James Bennett, qui occupe le poste de "Django Release Manager" et qui a publié sur son blog de nombreux billets sur Django et les bonnes pratiques à avoir/appliquer. Autant le dire tout de suite, le livre est de la même qualité que ses billets : accessibles, pédagogiques et pertinents.

Le livre se décompose en cinq grandes sections :

Présentation de Django
Réalisation d'un CMS simple (permettant de poser les bases)
Réalisation d'un weblog (permettant de découvrir les concepts de "template tags", manager, l'utilisation de librairies tiers, les vues génériques, etc)
Réalisation d'un dépôt de code (qui complète les points abordés précédemment et permet d'aborder le gestionnaire de formulaires).
Synthèse sur les bonnes pratiques à suivre pour du code flexible, adaptable, réutilisable, distribuable et surtout documenté !

Autant je n'ai pas appris grand chose avec les deux premières sections, autant j'ai adoré la troisième et cinquième. Pour la quatrième section, mon niveau en python & django font que pas mal de choses me sont passées pour le moment au dessus de la tête et que cela ne répond pas à mes besoins immédiats (contrairement à la troisième section).

Même si l'arrivée de la nouvelle interface d'administration et le fait que le code sur les "Signals" ait été réécrit font que quelques infimes parties du livre se trouvent aujourd'hui un peu obsolètes, le livre a le grand mérite de tout bien expliquer, de poser les bases et d'accompagner le lecteur dans une montée en puissance au niveau de sa maîtrise de Django.

Le seul reproche que je peux formuler concerne la quatrième section où l'accent n'est mis que sur les nouveautés. Du coup, on appréhende moins la construction de l'application en tant que telle. A ce jour le code source utilisé dans le livre (section de gauche) n'étant pas encore dispo sur le site d'Apress, cela n'aide pas non plus pour prendre le train en route...

Pour tout ce qui est bonnes pratiques, elles sont présentes partout dans le livre. Point besoin d'attendre la 5ème section pour en bénéficier. L'auteur prend même au début le plaisir à montrer la "mauvaise façon" (ie sans prendre en compte les besoins d'extensibilité/flexibilité/...) puis montre ensuite la "bonne façon" de faire. Des conseils qui sont en général assez simple à suivre et donne de solides avantages au code généré (lisibilité, simplicité, réutilisabilité, etc).

(Mal)heureusement, je n'avais pas de PC sous la main pour coder en parallèle. Je n'ai donc pas pu capitaliser / jouer avec ce qui a été abordé. (J'aurais en outre pu en profiter pour coder la base de mon projet Atome...)

Pour conclure, si quelqu'un souhaite se mettre aujourd'hui à Django, je ne saurais trop lui recommander de lire en premier lieu "The definitive guide to Django : web development done right" puis ce livre ensuite. Avec ça et ensuite la documentation en ligne, il est prêt pour mener à bien des projets (perso/pro).

Vrac de rentrée

NiCoS — Sat, 16 Aug 2008 22:44:00 +0200

Django 1.0 Alpha 2 puis Beta 1 sont sorties, au programme :

(alpha 2) Intégration de l'application de système d'information géographique GeoDjango
(alpha 2) Extensibilité des types Fichiers (FileField) et Images (ImageField) pour permettre une manipulation plus souple de ces types d'éléments
(alpha 2) Compatibilité avec Jython (qui permet de faire fonctionner du code python dans une application Java pour faire simple)
(beta 1) Les relations génériques sont maintenant supportées dans l'interface d'admin et dans les formulaires
(beta 1) Amélioration de la flexibilité de l'interface d'administration pour tout ce qui est antérieur ou postérieur à la sauvegarde d'un élément (cf doc)
(beta 1) La distinction entre un INSERT et un UPDATE au niveau de la méthode save() est améliorée (comprendre, on peut la gérer soit même)
(beta 1) Le middleware du cache a été éclaté en 3 - CacheMiddleWare continue à exister en tant que tel et est constuit sur la base de deux nouvelles classes (une pour créer le cache, l'autre pour le lire) (cf doc)
(beta 1) Les fonctionnalités obsolètes et maintenues jusqu'alors sont supprimées (il faut donc renommer vos django.newforms en django.forms par ex).

Pour ceux qui veulent avoir un aperçu des progrès réalisés par Django en deux ans, ils peuvent lire JeffCroft.com: Top ten things that suck about Django, revisited.

Pour rester dans Python, Smile se pose la question Faut-il avoir peur de Python, ça m'a rappelé ce billet sur l'adoption (ou pas) des nouvelles techo / langages ayant le vent en poupe. Serais-je un tantinet médium ?

Pour sortir un peu de python & django, un petit point sur la compatibilité des sites avec les navigateurs avec une série d'astuces utiles. Dans la même veine, un billet pour rendre vos newsletter en html lisibles sous vos webmails & clients mails.

Un petit état des lieux sur eZ Publish 4.0 et ses bugs - ça me promet une rentrée épique ça

Prochain billet : revue de lecture sur Practical django projects de James Bennet ; il me reste les deux derniers chapitres à finir...

Conventions de codage (si tant est que j'en ai...)

NiCoS — Sat, 16 Aug 2008 22:03:00 +0200

Quand j'ai vu cette chaine sur les conventions de codage se diffuser sur le web avant l'été (ici ou encore là), je me disais "enfin une qui va me passer à coté, je peux dormir tranquille", ne me considérant pas comme un développeur (ou alors un du dimanche ) et n'étant pas non plus développeur de formation... Et bien non, Nicolas Hoizey a décidé de me refiler cette chaine.

Pour les projets réalisés dans un cadre professionnel, pour tout ce qui a été en html/css/php et autres boucles SPIP, j'ai par le passé tenté de bêtement copier ce que faisaient mes petits camarades. Cela se justifiait principalement par le fait que j'intervenais ponctuellement sur le code et ne souhaitait pas les perturber plus que nécessaire.

Pour les projets réalisés dans un cadre professionnel et dont je suis à l'origine ou pour mes projets perso, je n'ai pas de règle précise, je vise surtout une logique de lisibilté.

Cela donnera par ex pour un script bash dont l'objectif est de packager des fichiers par ex :

#
## Get relevant information for the packaging
#
 
# Do we need to send file on the front server ?
... some code ...
 
# Do we need to send file on the database server ?
... some code ...
 
#
## Let's build the package
#
 
# Package files for front server
... some code ...
 
# Package files for database server
... some code ...

Je prends souvent ce schéma pour tout ce qui a trait à l'administration système et pour les CSS (en adaptant les caractères de commentaires bien sur...).

Pour continuer sur les CSS, mon ordre de fabrication de mon fichier va être le suivant :

Eléments globaux / génériques
Section des plus "grandes" vers les plus "petites" (body > left > sidebar)
Au sein de chaque section, en premier lieux les éléments de positionnement puis ceux de mise en forme (pour reprendre une logique du plus grand au plus petit)

L'idée étant de regrouper le code en des sous-ensemble logiques.

Cela pourrait donner qqc comme :

/********************************
*  Elements généraux/generiques
********************************/
 
body {
}
 
h1 {
}
 
a {
}
 
/********************************
* Zone gauche
********************************/
 
#left {
}
 
/* Menu gauche */
 
#left #menu {
}
 
#left #menu a{
}

Par contre, là où j'ai toujours eu un souci avec PHP par ex, c'est sur la convention à suivre sur la gestion des accolades (qui en plus suivant l'IDE, l'interpréation peut changer) :

Ex :

if ($toto == "toto")
    {
    ... some code ...
    }

if ($toto == "toto")
{
    ... some code ...
}

ou :

if ($toto == "toto") {
    ... some code ...
    }

ou :

if ($toto == "toto") {
    ... some code ...
}

Ou surement encore plein d'autres choses faisant que mon code au final se trouvait mal indenté (ou pas toujours de la même façon, ne parvenant pas à décider de ce qui était le plus lisible), surtout si les choses avaient tendance à s'imbriquer.

Je pense d'ailleurs que c'est une des raisons pour lesquelles j'aime python. L'indentation que l'on doit respecter permet de donner une bonne lisibilité du code. En plus, la charte de bonne conduite est clairement définie, même si je ne la suis pas encore dans son intégralité...

"""
Profile
 
This object is used to provide some common information regarding the profile of a user.
"""
 
class Profile(models.Model):
    CIVILITY_CHOICES = (
         ('single', _('Single')),
         ('taken', _('Taken')),
    )
    who = models.ForeignKey(User, unique=True, verbose_name=_('Person'),)
    photo = models.ImageField(height_field="80", width_field="80", upload_to="photos", blank=True)
    street = models.CharField(_('Address 1'), max_length=100)
    street_bis = models.CharField(_('Address 2'), max_length=100, blank=True)
    zipcode = models.IntegerField(_('Zip code'), max_length=5)
    city = models.CharField(_('City'), max_length=100)
    country = models.CharField(_('Country'), max_length=100)
    phone = models.CharField(_('Phone'), max_length=20)
    mobile = models.CharField(_('Mobile'), max_length=20, blank=True)
    civility = models.CharField(_('Status'), max_length=20, choices=CIVILITY_CHOICES)
    birthdate = models.DateField(_('Birth date'))
    children = models.IntegerField(_('Children'), blank=True, null=True)
 
    def __unicode__(self):
        return self.who.get_full_name()
 
    class Admin:
        list_display = ('who',)
        list_filter = ['who',]
        search_fields = ['who',]
 
    class Meta:
        verbose_name = _('Civil state')
        verbose_name_plural = _('Civil states')

Pour le débat indentation vs espace, j'avoue avoir préféré les espaces. Etant feinéant, je profitais aussi de la fonction de nombreux IDE qui transforment la tabulation en 4 espaces (ce qui permettait de continuer à utiliser la touche tab pour indenter son code...)

En tous cas, si je devais donner une conclusion à cet essai, que pour adopter une convention de codage, il faut :

Regarder si une convention n'est pas définie au niveau du language, si oui, alors l'adopter.
Regarder si une convention n'est pas définie au niveau du programme que vous utilisez, si oui, alors l'adopter (et si elle entre en conflit avec celle du langue, tant pis pour le langage, il est plus logique d'avoir un code cohérent)
Si aucune des deux n'est définie, voir pour trouver une convention qui vous va bien à vous et le cas échéant à vos coéquipiers (à ce titre, mieux vaut en discuter avant le début du code qu'après, ça évitera de vous marcher dessus ensuite...)
Adopter une terminologie anglaise (penser que votre code et commentaires peuvent être lus/utilisés par un prestataire indien - que feriez vous si vous deviez reprendre un code dont les commentaires sont en chinois par ex ?)

Vacances...

NiCoS — Fri, 01 Aug 2008 17:00:00 +0200

Ce blog repart en léthargie pour une bonne raison cette fois : des vacances

Tout comme j'ai demandé à mes petits collègues de ne rien casser en mon absence, vous êtes priés d'en faire autant

On se revoit dans 15 jours avant notamment des conventions de codage à ce qu'il paraît... mais aussi de cahier de recette, d'intégration, de redirection sous IIS, etc car j'ai plein de choses à dire sur ces sujets...

Django 1.0 alpha is out (mais en juillet)

NiCoS — Wed, 23 Jul 2008 09:11:00 +0200

Le framework Django, vient de sortir en version 1.0 alpha, premier jalon d'une série de release devant nous emmener à la version 1.0 final début septembre, comme l'annonce la roadmap.

Au menu des principales nouveautés depuis la version 0.96.x :

Nouvelle interface d'administration
Support de l'unicode
Amélioration de l'ORM
L'autoescaping dans les templates, pour se prémunir des failles XSS.

Pour ceux qui mettraient à jour leur site d'une version 0.96.x vers cette version, n'oubliez pas de consulter la liste des incompatibilités ascendantes et le traitement à "infliger" à votre code pour le faire évoluer.

Sur la partie admin, je vous invite à consulter également la page dédiée à cette fonctionnalité qui donne beaucoup d'informations pour la migration. A lire et voir également, ce tutoriel et screencast pour la migration vers cette nouvelle interface d'administration.

Et pendant ce temps-là sur django-fr, David a (enfin ) publié mes traductions de la contrib webdesign, l'installation de django avec Apache/mod_python ou sous fastcgi. Il faut d'ailleurs que je mette à jour ces deux documents suite aux derniers commits...

PS : désolé pour le jeux de mot... fatigue, besoin de vacances, tout ça tout ça...

Fin de la démo de MvMo

NiCoS — Sun, 20 Jul 2008 22:08:00 +0200

La démo de MvMo hébergée précédemment sur mvmo-demo.unelectronlibre.info est coupée pour le moment au vu de sa ~~faible~~ non-utilisation.

Elle peut être rétablie à la demande...

(promis, j'essaie de faire des billets intéressants bientôt...)

Aménagements d'été (suite) : Déménagement du Chaudron.

NiCoS — Sun, 20 Jul 2008 00:59:00 +0200

Le Chaudron est déplacé vers une nouvelle url : http://www.unelectronlibre.info/projets/

La redirection générique est en place.

Pour mes besoins actuels, Sphinx et mes dépôts mercurial me suffisent amplement... Je mets donc redmine de coté pour le moment...

MiaM

NiCoS — Sat, 19 Jul 2008 09:44:00 +0200

La branche tant attendue newforms-admin est arrivée dans le trunk de Django.

Du coup, django.newforms devient django.forms.

Un grand pas en avant de fait vers la version 1.0 et qui ouvre un grand nombre de possibilités pour la constitution de back-office d'une appli Django... (pas encore testé).

Bref de quoi me motiver un peu plus pour me remettre à mes dev...

Edit du 20/07 : A lire absolument en plus de la page sur la branche newforms-admin indiquée plus haut, la documentation sur l'interface d'administration et tout ce qui s'y réfère (modèles, options d'affichage, etc)

Aménagements d'été

NiCoS — Sat, 05 Jul 2008 23:50:00 +0200

Après le dépoussièrement des tutoriels, c'est au tour de ce blog :

Passage de la racine de ce site dans le répertoire "journal" et les "index.php" ont disparu dans les urls. Normalement, toutes les redirections sont ok... Si bug, merci de le signaler...
Le flux pour les commentaires change un peu (avis aux 2 abonné(e)s) : http://feeds.feedburner.com/UnElectronLibre/Commentaires

Par contre, je trouve que le nouveau tableau de bord de dotclear 2 avec l'éditeur rapide de billet et l'intro des news, c'est moche à souhait:

Backup-Manager 0.7.7 : Bug fix sur la version FC9/i386

NiCoS — Wed, 02 Jul 2008 00:30:00 +0200

Une petite erreur sur la définition d'un chemin...

La version FC9/x86_64 n'est pas touchée.

N'ayant plus de FC8 sous le coude, je n'ai pas regardé et j'ai donc supprimé les paquets en conséquence.

Déplacement des tutoriels de wiki.unelectronlibre.info vers www.unelectronlibre.info/tutoriels/

NiCoS — Sun, 29 Jun 2008 00:24:00 +0200

Je pourrais me limiter à un "tout est dans le titre" mais ce serait pas bien...

J'initialise (enfin) la première phase de ce qui devrait être un grand chamboulement à la fin

Les tutoriels se déplacent donc d'un vieillissant dokuwki vers l'espace "Tutoriels" basé sur le jeune projet de documentation Sphinx (NDLR, il sert notamment pour la future documentation de Python et Django).

Sphinx est basé sur la syntaxe ReStructured Text, incorpore la coloration syntaxique, gère des niveaux d'arborescence et est en mesure de sortir votre documentation sous plusieurs formats (HTML, LaTeX, PDF). Il est fait pour gérer de la documentation et il le fait plutôt bien.

Certains pourraient dire qu'un wiki est plus sympa car plus ouvert mais bon vu le nombre d'apports externes que j'ai eu depuis son lancement, je risque pas grand chose. Merci quand même aux quelques contributeurs

Il me reste encore à :

~~Mettre les sources sur un dépot mercurial accessible de tous~~ FAIT
~~Annoncer la licence CC qui va bien~~ : NC-BY-SA FAIT
~~Rediriger wiki.unelectronlibre.info vers ce nouvel espace~~ FAIT

J'ai profité de l'occasion pour faire le ménage, certains tutoriels ne seront donc plus disponibles une fois la migration des urls effectives. J'en ai également profité pour mettre à jour certains (remplacement de apt-get par aptitude, php4 par php5, corrections de fautes/typo, etc).

Je peux donc oublier la syntaxe Dokuwiki maintenant (me reste encore celle de SPIP, Dotclear, Textile (Redmine) et reStructured Text (Doc Django, Projets Django, Tutoriels)). Elle me génait énormément quand je jouais simultanément avec Trac (car elles sont quasiment opposées dans leur principe, notamment pour les titres).

Edit du 30/06 : Redirection OK, Licence OK, Source OK - J'ai même crée un projet tutoriels sur mon Chaudron pour toute remarque sur les tutoriels

Futilité de passage...

NiCoS — Mon, 23 Jun 2008 23:32:00 +0200

Le Chaudron, à défaut d'être complet est à jour coté Redmine - cf Annonce de Redmine 0.7.2
Ce blog, ainsi que celui de mon fils continuent de suivre le SVN de dotclear et sont donc sous Dotclear 2.0 RC2
Jungle Disk 2.0 est sorti
Le paramétrage du serveur est quasi fini, faut que j'injecte d'une facon ou d'une autre le backup des bases postgresql dans backup-manager
Mon nombre de flux RSS suivis est passé de 100+ à une 30aine (et ça pourrait encore diminuer) - que de bruit en moins et de temps de gagné. Déjà que j'arrive pas à faire le quart de la moitié de ce que je voudrais faire... et ça m'inspire aussi que la veille / course au hype en SSII consomme un temps monstrueux pour un intérêt qui me parait aujourd'hui bien relatif...
Intéressant de voir les projets depuis un client final. C'est là où on voit que les phases d'intégration, tests et documentation sont raremement à jamais appliquées en SSII, voir pas intégrées dans le process de développement pour des bonnes et mauvaises raisons - j'y reviendrais plus tard, ainsi que sur ce document qu'est le "cahier de tests". Pour éviter toute mauvaise interprétation : moi aussi jusqu'à peu encore, j'ai aussi mal fait quand j'étais en SSII... c'est d'ailleurs assez rigolo de prédire quasiment à coup sur ce qui a été fait/pas fait par une SSII et trouver à coup quasi certains les points de manque sur une livraison...
Diigo, c'est bientot fini car je trouve leur barre insupportable, la suggestion des tags est à chier et l'intrusion dans le menu en click droit est abusive. Pire que tout dans ce fameux menu, on ne peut pas faire juste "Bookmark" mais forcément "Bookmark & higlight", chose pour lequel je n'ai trouvé aucun intérêt pour le moment. Retour sur del.icio.us sous peu... (juste après la publication de ce billet en fait...)
Il a été vu ceci sur mon PC - il parait que je me serais remis à faire du code (à défaut de trouver un éditeur qui me convienne)

django-admin.py startproject atome
django-admin.py startapp journal
django-admin.py startapp links

mais un bug lié à la version SVN de Django et de django-tagging (dont j'ai trouvé la doc un peu limité sur l'intégration dans les modèles) m'a vite bloqué -

Suite au prochain épisode...

Edit 1 : Pour django-tagging, faudrait lire la doc qui va bien aussi...

Edit 2 : Ajout de la sortie de Jungle Disk 2.0

Tel un mouton de panurge...

NiCoS — Mon, 09 Jun 2008 22:14:00 +0200

... je passe de del.icio.us vers diigo.

Pour ceux qui suivent mes marks, c'est donc par ici : http://www.diigo.com/rss/user/Nsteinmetz

Le compte del.icio.us va rester actif puisque je profite de la capacité de Diigo à sauver "ailleurs"...

Pour ceux qui ne connaissent pas diigo, cf là, ici, ou encore là.

RPM FC8 & FC9 : Backup-Manager

NiCoS — Mon, 02 Jun 2008 00:03:00 +0200

Juste pour indiquer qu'après les PKGBUILD d'Archlinux, je me mets au RPM de Fedora Core.

Pour mon premier paquet, je me suis attaqué à Backup-Manager dont j'ai besoin pour mon serveur dédié.

Attention, il a été compilé sur une machine en x86_64 (ne fonctionnera donc pas en i386) sous FC9

La version i386 et pour FC8 ~~devrait arriver prochainement...~~ est arrivée :

La version i386 et pour FC9 est arrivée :

Edit du 02/06 : ajout de la version FC8/i386

Edit du 09/06 : Restauration des commentaires suite à un petit problème sur postgresql + ajout des dépendances pour FC9 :

yum install -y perl-File-Slurp perl-XML-LibXML perl-CPAN
cpan
cpan> install Net::Amazon::S3
(répondre la valeur par défaut à toutes les questions)

Edit du 14/06 : Ajout de la version FC9/i386

Si vous lisez ce billet...

Nicolas Steinmetz — Sat, 31 May 2008 08:05:00 +0000

Cela veut dire que j'ai réussi à migrer DC2 de MySQL à PostgreSQL et que les DNS ont basculé.

Pour ceux qui voudraient passer de MySQL à PostgreSQL sous Dotclear 2, c'est très simple :

Sur votre instance dotclear en MySQL : Import/Export > Export > Exporter tout le contenu
Installer une nouvelle instance dotclear sur votre serveur avec PostgreSQL
Sur votre instance dotclear en MySQL : Import/Export > Import > Import d'un fichier de sauvegarde complet

Suivant la taille de votre blog, vous aurez peut être à uploader votre fichier de backup dans votre répertoire public de dotclear au préalable. Pensez à effacer le fichier une fois que la conversion est effective.

Tous mes sites perso sont donc passés sur un Kimsufi 2008 avec lighttpd comme serveur Web et Postgresql comme serveur de base de données. Pour les langages de scripts, y a du PHP, Python (+ DJango) et Ruby (+ Rails "à cause" de Redmine).

Petit retour "en arrière" donc sur le choix de nginx car j'ai été infoutu de comprendre comment faire fonctionner un site en PHP avec. Comme le support de PHP est très simple à mettre en place sous lighttpd, j'ai vite switché... et du coup hg.unelectronlibre.info est à nouveau disponible (pareil, pas compris comment le faire avec nginx)

Un mail effacé un peu vite - A mail deleted too quickly (django inside)

NiCoS — Tue, 20 May 2008 09:28:00 +0200

En consultant mes mails ce matin, en regardant mes spams, j'ai parcoucu la liste d'un oeil rapide en cliquant automatiquement sur "Supprimer tous les spams" quand mon oeil a été attiré par les mots "Parter Django Project" (ou quelque chose d'approchan). Si cette personne lit ce blog, je veux bien qu'elle me renvoit son mail sur la même adresse, je ferais plus attention sur les spams dans les jours à venir

When reading my new mails this morning, I jumped to the Spam section and clicked on "Delete all spams" button when my eye was attracted by a title looking like "Partner Django Project" (or something approaching). If the sender read this blog, I would appreciate that he sends me again the related mail on the same email adress. I would be more careful with spam mails in the following days

Edit : Merci à David pour le forward du mail en provenance de Djangogigs apparemment (tiens, je me rappelle pas m'y être inscrit...)