Un Electron Libre...

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

Tag - développement

Fil des billets - Fil des commentaires

mardi 6 novembre 2007

Coup de pouce : David Larlet crée Welldev, pour des développements autour de Django...

Pour celles et ceux qui cherchent un indépendant familier des bonnes pratiques en matière d'accessibilité, web sémantique, développement, formats ouverts, etc, bref disons le un "passioné du web" et qui en plus fait du django (bon ça à la limite, vous vous en fichez de la solution technique, quoique...), alors pensez à David Larlet. Vous le connaissez forcément (oui oui, c'est bien celui que je cite souvent, l'auteur de Biologeek). Il vient donc de se jetter à l'eau en créant sa boite : Welldev.

Il ne manquerait qu'une corde graphique à son arc pour en faire le prestataire idéal, mais ça, je lui fais confiance pour trouver les partenaires qui vont bien en la matière ;-)

Souhaitons lui bon courage et que les formalités administratives de création d'entreprise et autres URSSAF & co ne viennent pas tuer sa motivation.

Une raison de plus pour que le Papa de Django-fr relance le projet en question... :-)

mercredi 31 octobre 2007

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

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 :

mardi 9 octobre 2007

Comment assurer la pérénité de son projet ?

Etant en train de mettre à jour un site réalisé sous SPIP 1.7 vers SPIP 1.9.2c (soit un écart proche de *21* versions intermédiaires (majeures ou mineures), voici quelques retours :

  • Ne pas suivre la mise à jour de l'outil qu'on utilise, c'est très mal. Avoir en tête tous les changements qui ont eu lieu entre ces versions relèvent parfois du casse-tête. Bon en même temps, un bug sur le critère titre_mot a empêché une mise à jour de l'outil pendant longtemps (au moins la version 1.8.2e, soit déjà 10 versions d'écart).
  • Ne pas documenter le code (php ou les squelettes SPIP), c'est mal aussi.
  • Ne pas conserver les sources des animations flash, c'est mal aussi (pour le coup, cela m'a simplement obligé à utiliser un lien symbolique suite à la réorganisation du bazar)

Du coup, on peut raisonnablement se dire que pour assurer la pérénité de son projet, il faut :

  • Documenter le code de façon satisfaisante :
    • Utilisation de la javadoc, phpdoc, ...
    • Utilisation de la balise REM pour les squelettes SPIP expliquant chaque boucle ou bloc de boucle (notamment avec les boucles HIERARCHIES)
    • Documenter le fonctionnement du site, les règles de gestion, la raison d'être des différents articles, etc que ce soit dans un document externe ou au sein des squelettes par ex
  • Le code ne correspondant pas au code source de l'application doit être clairement identifiable.
    • Seul le code source spécifique au projet doit dès lors être dans le gestionnaire de source du projet
  • Suivre les mises à jour de l'outil au fur et à mesure en tirant parti des nouvelles fonctionnalités
    • Le nouveau compilateur (plus oblige a réécrire certaines boucles vu qu'il est moins laxiste que précédemment.
    • L'apparition de #DOSSIER_SQUELETTE puis de CHEMIN{} permet ainsi de centraliser tous les éléments de vos squelettes et vous donne une plus grande flexibilité (plus de chemin en dur par ex)
    • Le coût de la mise à jour est alors minime et réparti - plutôt qu'un gros coup prohibitif lors de la mise à jour 21 versions plus tard, risquant de plonger votre projet dans l'immobilisme total...
    • La transformation de certains bouts de code en plugins SPIP (notamment pour des éléments insérés dans la partie privée) est un réel plus et améliore la lisibilité de votre site/code.
  • Suivre les mises à jour pour bénéficier des correctifs de sécurité
  • Sans oublier que la mise en page par tableaux, c'est une horreur à maintenir, illisible, etc.

La liste n'est sans doute pas exhaustive mais déjà rien que pour ce projet, je peux mettre un zéro pointé partout. Alors certes, un bug SPIP corrigé en 1.8.2e empêchait toute mise à jour vers la version 1.8 de l'outil, mais depuis, cela aurait du être fait proprement.

En tous cas, ça vous donne plein de bonnes pratiques pour vos prochains projets perso / cahier des charges / mode de gestion de projet / ... ; si ça vous en donne pas, moi si !