Peu de nouvelles ces derniers temps car beaucoup de travail de mon coté. Les méthodes agiles sont entrain de s’ancrer dans la plupart de mes devis et je suis donc passé à un apprentissage d’UML dans sa version 2 pour pouvoir estimer de la meilleure façon les demandes des clients. Et franchement, j’adore ça.

Revenons aux dernières réflexions autour de peanut v2. Nombreux sont les cas dans lesquels le vieux sage développeur qui croisera votre chemin vous conseillera de mettre quelque chose de « concret ». En intégration, on vous conseillera de mettre du vrai texte plutôt que du faux-texte (lorem ipsum dolor…), dans le cas du test d’une application web on vous conseillera de mettre de la « vraie » donnée et pas un « fdsfdsfe » comme en avait l’habitude mon ancien stagiaire par exemple, etc. Etc.

Etant donné que le projet est orienté pro, je me suis donc dis que créer une fausse société pourrait être sympa. Un nom de domaine plus tard, la création de la fausse société est faite avec une simple landing page (à l’ancienne). Ceux qui me connaissent depuis un long moment ne seront pas dépaysés puisque La Blackroom a déjà eu ses heures de gloires (et m’a valu quelque unfollow sur twitter :p).

Cela me permettra de créer un vrai/faux site Internet avec de faux salariés et d’ouvrir les inscriptions à toutes les personnes le souhaitant afin de créer quelque chose de sympa et surtout concret.

(première) Présentation de la société

La blackroom est une agence fictive de communication web composée d’une vingtaine de personne amoureux d’Internet. La société est spécialisée dans le numérique et l’utilisation des nouvelles technologies. Le coeur sur la main, la blackroom créer des applications web professionnelles et a choisi de les diffuser au plus grand nombre afin de se faire connaitre.

Chacun des services à des besoins différents et chacun de ses besoins est traité par le service informatique de la société. Une fois un besoin analysé et jugé intéressant par l’ensemble des membres de la société, il donne lieu à un projet estimé par le service informatique et créé. Les besoins peuvent donc être multiple et évolutifs ce qui oblige le SI à travailler autour d’une base commune et avec une méthodologie agile.

Pour plus d’informations, vous pouvez retrouver le dirigeant sur le compte twitter de la société (toujours fictive).

Le pourquoi de cette nouvelle version

Pour comprendre cette orientation CMF, je pense qu’il est important de vous situer mon expérience professionnelle :

• 2002 : Electricien dans le bâtiment en contrat d’apprentissage
• 2004 : Un peu d’événementiel dans le jeu vidéo (multitude de CDD, contrat à la sauvette et j’en passe)
• 2006 : Retour à l’informatique pour une année de Technicien d’Assistance Informatique. Accessoirement, découverte du web 2.0 aka « OH MON DIEU, JE SUIS UNE PUTE DU WEB »
• 2007 : Contrat de professionnalisation de TSSI mais surtout, premiers pas sur le web en tant qu’intégrateur avec un peu (en fait beaucoup) de wordpress
• 2008 : Début d’un projet web avec deux amis. Projet abandonné et op, un poste de webmaster chez geekspirit/mageekstore
• Fin 2008 : Chef de projet multimédia pour une société de communication opérationnelle (ce qui veux dire : on fait de tout pour les grands comptes et agences)

Résultat des courses, je pense connaitre le monde professionnel à travers ses différents aspects et donc différentes problématiques. Pour moi, le monde de l’entreprise (notamment chez les grand compte) est vraiment quelque chose de fascinant et les possibilités pour le web sont presque infinies.

Le déclencheur est quant à lui une convention, puis une autre, et encore une autre, dans lesquelles j’ai pu entendre en tant que prestataire sur l’événement des demandes de salariés à une direction bloquée par un service informatique lui-même bloqué par une infrastructure difficile à remettre en question (ne jettons pas directement la pierre sur nos amis les DSI) ou tout simplement pour un manque de moyen humain.

Et dans tout ça, avec mon petit vécu professionnel, il se passe des choses dans ma tête pour finalement se dire qu’il y a quelque chose à faire.

Les problématiques entreprises (et grand-comptes)

Revenons à nos moutons, les entreprises. Tous les développeurs web ayant pu côtoyer ce monde connaissent les principales problématiques :

• Une architecture réseau/informatique pas toujours à jour (bonjour IE6)
• Des utilisateurs avec une demande mais peu de compétences informatique
• Un SI omniprésent et verrouillant le maximum d’éléments vis à vis des prestataires externes (sauf quelques rares cas)

Coté humain :

• Des services avec des demandes différentes
• Des services ne fonctionnant pas ensemble
• Des personnes (le manager en bout de chaine avec son responsable, son RH site, son RH groupe, sa comm’ site, sa comm’ groupe etc etc) qui ne demandent qu’à évoluer dans de bonnes conditions

Rajoutons à cela les problématiques multinationale :

• L’échange d’informations et la communication

Heureusement pour nous, il existe un grand nombre de solutions. J’ai cependant isolé deux problèmes fondamentaux et omniprésents :

• Le language : Dans les groupes, affronter les problématiques i18n et l10n est un vrai fardeau à cause du manque de connaissance et des moyens en place
• L’échange d’informations utilisateurs : le fameux serveur Activ’Directory capable de faire tant de choses mais si peu utilisés. Pensons un peu plus loin et ramenons ça à une problématique de type LDAP

Le reste n’est que « de la routine » vis à vis des développements web conséquents : gestion des droits d’accès (permissions), multitude de site (sous domaines) et de besoins (op le réseau social interne, op le wiki…) Etc, etc.

On peut donc commencer à réfléchir.

Définir un socle technique

Une fois une partie des problématiques identifiées, nous pouvons définir le socle technique du projet. Arriver du jour au lendemain dans ce genre de structure pour dire « En 2011, on passe tout en PHP. Et puis en 2012, on passera tous sur Django et après tout en Java ! » est un peu stupide. Il faut arriver à penser sur une période un peu plus longue. On a donc concrètement cette problématique de language à prendre en compte mais aussi à essayer d’anticiper les besoins utilisateurs.

Le langage Forcément, sujet délicat. Je vais personnellement opter pour PHP (si vous ne l’aviez toujours pas compris). J’aurais pu en profiter pour me mettre à regarder tranquillement du coté de Django mais je ne préfère pas pour le projet. La première raison à ce choix est la (bonne) tournure que prends PHP. Un langage mature, disposant de framework orientés professionnels (symfony/zend), des méthodologies de travail, une industrialisation possible, une compatibilité avec la pluspart des technologies naissantes et surtout un bon vivier de développeurs à se mettre sous la dent. Bref, du tout bon pour notre SI qui ne demande qu’à pérenniser. Le choix de PHP permet également de plus petites entreprises de s’équiper avec un minimum de connaissances techniques (il est très facile de trouver une personne capable de mettre en place un serveur PHP) et les coûts sont faibles. Encore un bon point.

Ceci dit et je vous l’accorde volontier, il est difficile de savoir comment faire la différence entre les développeurs PHP. Le bon, la brute et le méchant version numérique.

Le framework PHP est une chose, un framework en est une autre. Le fait même de mettre en place un framework permet de faire un pas vers les bonnes pratiques web dans le sens large du terme. Les conventions de code, le modèle MVC et l’approche objets ne sont que quelques unes des bonnes raisons. Sur ce point, je reste avec symfony dans l’optique d’évoluer vers symfony2 (ce choix a déjà été expliqué) avec une implémentation de certains composants du Zend Framework.

Coté client : xHTML, HTML, CSS 1, 2,3, javascript, jquery, moofx… Op, un autre débat. Coupons cours direct et optons pour HTML5, CSS3 (à travers LESS) et jQuery malgré les problématiques liées à IE6. Pourquoi ? Dans un premier temps parce que les services informatiques vont forcément évoluer. IE6 représente de moins en moins de machine et n’est finalement la plus que pour une raison liées au système (Windows 2000, Windows XP) ou à une problématique web liées aux outils existants. A partir du moment où l’on remet l’un ou l’autre de ses éléments en cause, il faut évoluer. Le web ne doit pas être tiré vers le bas même dans le contexte entreprise. A l’opposé, il faut prendre en compte toutes ces problématiques et proposer quelque chose d’acceptable pour les personnes sous IE6. Enfin, pensons un peu aux terminaux mobiles.

Sémantique et accessibilité à l’information Toutes entreprise de plus de 50 salariés (si ma mémoire est bonne) se doit de respecter un « quota » de travailleurs avec un handicap (quel qu’il soit). Penser sémantique et accessibilité, c’est non-seulement pousser une application vers l’interopérabilité mais aussi en faciliter l’accès sur le long terme. Une entreprise dont la taille exige un certains nombres de travailleurs handicapés se doit d’être accessible pour la totalité de ses sites Internet.

L’industrialisation et les méthodes agiles Garantir la pérennité d’un projet sur le long terme passe par une industrialisation complète de la chaine de développement. Le produit de base peut avoir une durée de vie de 5 à 10 ans (si l’on prends le cas IE6), le nombre de personnes impliquées sur le projet n’est pas quantifiable et il faut donc fixer une méthode de travail efficace dès le début.

Conclusion

La réflexion ci-dessus correspond finalement à une expression initiale de besoins et est la première étape de l’utilisation de méthodes agiles (Scrum, XP…) ou encore en UML. On peut être d’accord ou non avec les informations ci-dessus mais les grandes lignes du projet sont définies. Nous allons enfin pouvoir commencer à travailler sérieusement

Ayant décidé d’assurer l’intégration continue avec Hudson, je me suis attelé à l’installation de ce dernier sur un serveur dédié Ubuntu chez OVH. Le serveur étant déjà en production et sécurisé avec iptables, j’ai du affronter quelques problèmes. Ne vous attendez pas à une installation step-by-step comme cela à été le cas pour le MAMP, mon époque réseau est révolue (Gentoo <3), je découvre beaucoup de choses d’un coup et un tuto d’installation ne serait pas forcément pertinent.

Etape 1 : l’installation d’Hudson

J’ai essayé d’installer Hudson de deux façons différentes : la première en utilisant la version hudson avec un « apt-get install hudson » et la second à travers un serveur tomcat6 et l’ajout du fichier hudson.war

Rien de spécial à ce niveau, contentez-vous de suivre les procédures classiques d’installation. Il faudra cependant autoriser le serveur Hudson à parler avec l’extérieur en ajoutant une entrée dans iptables :

$ sudo iptables -A INPUT -p tcp -i eth0 -s <votre ip publique> --dport 8080 -j ACCEPT

Etape 2 : Premier problème avec Hudson

Une fois votre serveur lancé « sudo /etc/init.d/hudson start » votre serveur devrait théoriquement vous afficher quelque chose comme « Merci d’attendre que Hudson soit prêt… » Vous pouvez attendre un petit peu ou trois heures comme moi.

- Toc Toc!
- Qui est la ?
...
...
...
...
Java !

Le problème découle directement du fait que les version de Hudson à partir de la build 1.359 utilise le multicast. Il faut donc l’activer sur iptables :

$ sudo iptables -A INPUT -p igmp  -j ACCEPT
$ sudo iptables -A OUTPUT -p igmp  -j ACCEPT

Et si ça ne fonctionne pas (comme chez moi en fait), descendez à la build 1.358 – parce que oui, la je suis vaincu.

Etape 3 : Git

Donc votre serveur Hudson tourne et vous accédez au dashboard. Installer les plugins GIT via la gestion des plugins à savoir le « Hudson Git plugin » et le « Github Plugin ». Une fois installé, une configuration de GIT est nécessaire.

Dans la configuration générale du système, ajouter une installation GIT baptisée « default » avec comme path pour l’executable « git » puis enregistrer.

Dans la configuration du projet, cela se complique un peu suivant ce que vous voulez faire à savoir dans mon cas :

1. le développeur push vers un repository local « git bare » dans un répertoire /var/git/NomDuProjet.git
2. hudson lance sa compilation et fais ses tests
3. hudson push sur un repository github

Iptables oblige, il va encore falloir ajouter une entrée pour échanger sur le port utilisé par Git.

$ sudo iptables -A OUTPUT -p tcp --dport 9418 -j ACCEPT

Hudson étant plutôt capricieux vis à vis de GIT, il faut ensuite configurer le user.email et le user.name par projet. Normal.

$ git config user.email "some@email.com"
$ git config user.name "hudson"

Cela permettra d’éviter de se faire jeter parce que monsieur Hudson chercher à s’authentifier comme anonyme.

Concernant la configuration maintenant, dans votre projet. Ajouter deux repositories pour GIT en nommant le repository comme si vous ajoutiez un remote (pour plus de facilité). Ce qui donne dans mon cas :

URL of repository : git@github.com:pocky/test.git
Name of repository (blank to create default) : github
Refspec (blank to create default) : +refs/heads/*:refs/remotes/origin1/*

URL of repository : /var/git/test.git
Name of repository (blank to create default) : origin
Refspec (blank to create default) : +refs/heads/*:refs/remotes/origin1/*

Branch Specifier (blank for default): master

Ensuite configurer le Git Publisher (en bas de page) dans la partie Branches :

Branch to push : master
Target remote name : github 

Ce qu’il va se passer : Lors d’un build, Hudson va d’abord chercher à rapatrier toutes les changements depuis les différents repositories puis va lancer son build et en cas de réussite faire un push vers github. Pour un meilleur échange lors du premier build, je vous conseil de créer un fichier sur votre ordinateur puis de push vers votre remote de preprod (le serveur hudson) et votre remote github. Cela évitera à Hudson de vous renvoyer un message d’erreur lors du fetch.

Pour tester la connexion vers github après la configuration complète, rien de bien compliqué :

$ sudo su - hudson
$ ssh git@github.com

Vous saurez tout de suite si il existe un problème ou non. Si un problème de connexion vis à vis de git survient, cela provient sûrement de vos clés ssh. Il faut les rajouter dans le repertoire home de hudson dans un repertoire .ssh (qu’il faudra créer) via la procédure standard de création de clé ssh (ssh-keygen et tutiquanti). Il faudra ensuite faire prendre en compte les modifications en redémarrant la session utilisateur Hudson ou en redémarrant le serveur.

Et la on pourrait croire que c’est terminé. Mais non.

Lorsque vous allez essayer de build, Hudson va vous claquer entre les doigts à cause des submodules (malgré le fait que la connexion soit bonne). Le problème vient apparemment du fait d’utiliser « git:// ». Il va falloir aller dans le fichier « .git/config » et changer tous vos « git:// » par « http:// » et tant que vous y êtes dans le fichier « .gitmodules ». Bien entendu, si cela a été fait en amont, c’est bon.

Vous n’avez plus qu’à relancer, ça fonctionne, c’est magique et vous aurez économisé une trentaine de build en échec. Merci qui ? Merci bibi !

Au programme ce soir et malgré le manque de nouvelles, un petit récapitulatif de l’évolution de ce modeste CMS qu’est peanut. Commençons par les chiffres, depuis le début du projet jusqu’à ce jour (soit sept mois) :

• 12 sites en production utilisent le moteur dans sa dernière version
• Le site le plus rapidement créé (5 pages, un formulaire de contact) l’a été en une demie-journée (intégration comprise) – oui, il y a vraiment une charte graphique. Et avec du CSS3 svp.
• Le projet le plus long s’étale sur 20 jours/homme et est basé sur l’ensemble des plugins auxquels il ajoute un certain nombre de fonctionnalités
• 12 plugins (pas tous publiés) ont été créés pour notamment recréer l’ensemble des fonctionnalités (ou presque) de wordpress
• et… deux gros bugs clairement identifiés : gestion des nestedSet dans peanutPage, un problème de génération du sitemap sur le plugin peanutSeo du aux relations many-to-many

Et bien sur son lot d’imperfections dignes des plus grand CMS – ou pas.

Bilan

Côté humain, ces sept mois de développement m’ont vraiment permis de continuer à gravir cette montagne qu’est PHP et tout ce qui gravite autour. Cette évolution se ressent un peu sur symfony mais surtout sur les autres moteurs. J’arrive beaucoup plus facilement à comprendre/assimiler/développer sur des frameworks et faire un peu de Zend, Magento ou même Code Igniter et ils ne me font plus du tout peur. Et je ne vous parle même pas de mon dernier thème wordpress, réalisé pour des besoins pro dont l’approche est complètement différente pour moi.

Depuis environ un mois, l’idée de faire évoluer peanut afin de lui faire prendre une nouvelle orientation me travaille vraiment et de récents retours professionnel ont fini de me convaincre : il faut s’orienter vers une solution CMF, adaptée pour des besoins sans cesse grandissants et couvrant un réél besoin – notamment au niveau professionnel. Cette notion (j’ai un peu honte la) d’entreprise 2.0 m’a toujours fascinée et c’est vraiment la chose la plus attirante pour moi. Couvrir la multitude de besoins professionnels, c’est s’ouvrir à un monde dont l’exigence est haute, aussi bien au niveau technique qu’au niveau ergonomique ou fonctionnelle.

Je pense donc créer une nouvelle branche de peanut n’ayant pas du tout pour but bannir la précédente mais tout simplement de l’industrialiser. peanut ne sera plus une suite de modules dans une (ou plusieurs applications) afin de couvrir un besoin mais bel et bien une application couvrant un besoin évolutif à travers différents modules -vous pouvez relire deux fois la phrase.

Et la on se dit « mon dieu, il va faire du Symfony 2.0 ! »

Perdu.

Perdu parce que dans un premier temps, je ne me sens techniquement pas prêt à pratiquer Symfony dans sa version 2.0. Symfony est vraiment sexy sur le papier mais également trop technique pour moi -tout le monde n’est pas autodidacte comme N1k0. Je préfère donc me concentrer dans un premier temps sur quelque chose d’accessible, autour d’une communauté pouvant répondre à des questions me permettant encore d’évoluer jusqu’à me sentir techniquement prêt pour quitter symfony et faire du Symfony. À contrario, cette démarche sous-entends que je souhaite réellement me préparer à Symfony et qu’il faut donc que je m’impose des process et une industrialisation forte afin de fournir le meilleur de moi-même dans un respect total des bonnes pratiques en général.

Un peu de technique maintenant

Voici ce que j’aimerais utiliser pour la suite du projet.

Suivi du projet

• Bug tracker : Mantis
• Intégration continue : Hudson
• Controle de code : Checkstyle
• Analyseur de code : Pdepend / DRY
• Documentation : PHPDoc
• Versionning de fichier : Git

Logiciels

• IDE de développement : Netbeans
• Suivi de version : Gitti
• Gestion de base de données : Sequel Pro

Développement

• Framework PHP : symfony
• BDD : Doctrine
• Framework JS : jQuery
• Framework CSS : bic CSS + LESS
• Utilisation de HTML5/CSS3

Divers

• Convention de code : symfony
• Intégration de tests unitaires
• Intégration de tests fonctionnels
• Modélisation : UML2
• Une application symfony est un sous-domaine
• Plus d’utilisation de l’admin-generator
• Chaque application possède son API
• Le projet est orienté utilisateur sous la forme d’un CMF

La grosse interrogation pour moi est la mise en place d’Hudson et des différents plugins ainsi que l’utilisation au quotidien de l’outil. Mon macbook pro va t-il me suffire (théoriquement oui) mais est-ce forcément la meilleure solution ou ne vaux t-il mieux pas passer à une solution web hébergée sur un autre serveur (Intranet/Extranet/Internet) ? Si vous avez une idée sur la question, je suis preneur.

Pour le reste, il faudra attendre un peu. Je pense faire une présentation (plus parlante que de longues explications) du projet avec de bons vieux slides !

Nouveau billet aujourd’hui pour vous annoncer la première version de peanutSeo sous la forme d’un plugin symfony. Le plugin a été divisé en deux parties.

Première partie : un behavior + un helper disponible en standalone sur leur propre repository
Seconde partie : le plugin pour peanut, ajoutant un module seo au frontend afin de proposer un sitemap à la racine.

Je vais également créer un repo pour la version de dev contenant tous les différents modules/plugins afin d’avoir quelque chose de complet disponible en téléchargement.

La todolist pour cette partie est la suivante :

• Refactoring du helper
• Ajout de tests unitaires pour le behavior
• Ajout de tests unitaires pour le module seo
• Améliorer la gestion du sitemap (proposer une archive tar.gz, ping des serveurs google/bing/…)
• Ajout de JS dans le module SEO afin de proposer un compteur de caractères

Si cette partie m’a permise de comprendre comment fonctionnent des behaviors/helpers, la prochaine me permettra de découvrir en utilisation concret les relations many-to-many.

Pour finir et si tout se passe comme prévu, la première refactorisation de l’ensemble du projet pourra commencer dès la semaine prochaine !

Ceux qui me suivent sur Twitter ont pu voir que les choses c’étaient un peu compliqués ces derniers temps même si tout est revenu dans l’ordre pour le moment. Le plugin peanutPosts a été ajouté à son propre repository Git et est utilisable en l’état.

Au passage, un grand nettoyage a été effectué sur le repository principal au niveau des branches et le readme a été mis à jour (avec des fautes d’orthographes).

A noter que vous pouvez utiliser ce plugin indépendamment de peanut sans aucun problème puisqu’il n’a que deux pré-requis : sfDoctrineGuardPlugin (version officielle) et sfDoctrineActAsTaggablePlugin.

Le validateur du formulaire de contact sfValidatorSimpleCaptcha a également son repository et sera prochainement remplacé sur le formulaire de contact par un autre validateur sfValidatorHiddenCaptcha.

Et pour finir, parce que je ne le dirait jamais assez, Symfony est un régal à pratiquer ! A bientôt !

Itération 7 cette semaine avec la création de la branche peanutPosts. Cette branche contient non pas un mais trois modules qui sont en cours de préparation :

• Le module peanutCategories : gestion des catégories
• Le module peanutPosts : gestion des articles dynamiques
• Le module tag : via le behavior Taggable

Il y a donc pas mal de travail à faire et tout avance au fur et à mesure dans l’ordre précédent. La création de ce module m’a également permit de découvrir le behavior Doctrine nestedSet permettant de gérer un arbre et ainsi éviter beaucoup de problèmes de récursivité (avec une gestion des catégories plus classique). Je compte d’ailleurs bien utiliser ce behavior sur le module peanutPage lors de sa refactorisation

Cette itération a également connue un petit bug avec le module Doctrine sfGuardForgotPassword alors vous pouvez remercier tight qui a apporté une réponse au ticket de bug.

La semaine dernière, un site de présentation a été mis en ligne à l’adresse suivante http://www.peanut.fr. Une personne c’est déjà amusée avec le formulaire de contact et vous pouvez faire de même. Vous n’aurez cependant pas accès au backoffice pour le moment, je l’ouvrirais un peu plus tard sur un site de demo. Ce site sera bien entendu amené à évoluer avec les différents modules.

Et pour conclure, je suis toujours aussi motivé par ce projet alors n’hésitez pas à me faire part de vos bugs ou envie, j’essaierai de faire le plus d’heureux possible !

Pour cette sixième semaine, la fin de la version 1.0 du module peanutPage. Ce module est donc fonctionnel et vous pouvez d’ors et déjà l’utiliser. Un petit passage en intégration (sur un vrai-faux site) m’à même permis d’ajouter quelques fonctions bien utiles pour le commun des mortels.

Avec ce module, le plugin csDoctrineActAsSortable a été ajouté ainsi que le plugin sfCKEditorPlugin.

Quelques ajouts xHTML/CSS ont été faits afin d’améliorer un peu le tout au niveau graphique et rendre le backend un peu plus sexy.

Bonus, le module contact a également été ajouté. Rien de bien exceptionnel à ce niveau puisque le formulaire de contact met tout simplement en place le tutoriel symfony forms in action. J’ai tout de même créé un petit validateur au passage baptisé sfValidatorSimpleCaptcha permettant de valider un captcha simple (sur la base d’un addition avec deux opérateurs).

Le module contact est donc également en version 1.0

Le plus important étant que maintenant, vous pouvez utiliser peanut pour créer un site simple de quelques pages même si cela reviendra à utiliser une grosse berline pour aller acheter votre pain.

Le wiki

J’ai ajouté quelques pages au wiki github afin de vous donner quelques informations sur la suite et le programme en perspective. Si vous repérez des bugs mais que vous ne voulez pas forcément proposer une solution, n’hésitez pas à utiliser la gestion de ticket github. Tout est bon à prendre pour moi avec ce projet.

Modification de l’utilisation de Git

J’ai décidé d’utiliser les submodules git afin de gérer les plugins dans le projet. Les submodules Git sont un peu l’équivalent des externals de SVN. Concrètement cela permet d’ajouter des projets git à l’intérieur même d’un superprojet git et donc de pouvoir faciliter les updates.

Dans notre cas, cela permettra de gérer les plugins du projet en offrant à tous la possibilité de télécharger directement le plugin (ou proposer des modifications) sur le repository associé.

Deux submodules ont été ajoutés pour le moment, symfony et mon fork de sfDoctrineGuardPlugin.

Oups!

J’ai fait une « petite » erreur de manipulation avec mes branches Git suite à l’utilisation des submodules. Git a en effet quelques problèmes pour gérer l’ajout de submodule sur une branche lors d’un checkout sur une branche sans submodules (d’après ce que j’ai compris). Résultat des courses, une fausse manip en essayant de faire fonctionner le tout et ma branche master disparait. Il m’a donc fallu la recréer et… Il faut forger pour être forgeron

Un cours de Git m’attends vendredi soir pour régler les petits problèmes associés à cette erreur (rien de méchant). J’aurais donc tendance à vous conseiller d’attendre samedi pour faire une mise à jour (ou alors de ne pas oublier de créer un répertoire « cache » à la racine du projet. Au passage, peanut sera tagué en version 1 et un site demo sera mis en ligne dans la semaine.

Modification de la roadmap

Etant donné que j’ai besoin d’utiliser peanut pour un projet, je vais un peu modifier la roadmap annoncé la semaine dernière. Le projet va donc évoluer de la façon suivante :

• Création du module peanutCategories
• Création du module peanutPosts
• Création du plugin peanutPosts
• Création du module peanutComments
• Création du plugin peanutComments
• Création du module peanutSEO
• Création du plugin peanutSEO

Si tout se passe bien, le tout devrait prendre de 3 à 4 itérations pour les v1 de ses modules/plugins.

Je passerais ensuite au refactoring/amélioration/debug de l’ensemble des modules. Chacun de ses modules (à travers leurs plugins) auront leurs propres repository Git et seront intégrés sous la forme de submodules dans le projet principal. Cela permettra au passage de pouvoir profiter d’un ou plusieurs plugins de son choix sans utiliser la base (même si certains plugins comme le module peanutSEO seront dépendants d’autres plugins).

Ce sera tout pour cette semaine ! A la semaine prochaine

Et pour rappel, vous pouvez récupérer le projet sur Github.

Cette semaine a permis d’assurer la création du premier « vrai » module pour peanut à savoir le module peanutPage. Ce module a été pour moi l’occasion de me mettre aux tests unitaires. Je dois dire que j’ai vraiment trouvé ça intéressant non-seulement pour les avantages « connus » des tests unitaires mais aussi d’un point de vue intellectuel. Mes tests ne sont pas forcément les plus complets pour le moment mais je pense que tout cela s’améliorera avec mon niveau.

Comme j’aborde le sujet, sachez que je vous encourage à vous lancer dans ce genre de projet. J’ai vraiment appris en 5 semaines un nombre conséquent de nouvelles « choses » et pourtant cela ne va pas encore très loin au niveau des fonctionnalités. Mais voila, cette espèce d’obligation de ne pas livrer à tous le monde quelque chose d’innutilisable aide forcément à faire de son mieux et à respecter les bonnes pratiques dans leur ensemble. Je ne vous parle même pas de l’auto-formation et de la documentation relative à tous ce travail même si cela ne se reflête pas de façon flagrante pour le moment dans le projet. Par contre, c’est une autre histoire au niveau professionnel avec des projets interne techniquement plus solide et abouti (notamment à travers un projet d’extranet dont je suis entrain de créer les bases).

Et je me demande vraiment pourquoi j’ai autant attendu pour me mettre à dev…

Ceci dit, revenons à nos moutons. Pour l’instant le module page est complet au niveau du backoffice (avec la personnalisation des formulaires) et des fonctions ont été créées dans le model (on dit merci au TDD). Un module frontend a été créé mais n’est pas du tout adapté au besoin. Cela viendra dans la prochaine itération.

J’ai un peu affiné mes itérations, un module devrait être livré en deux à trois itérations au minimum (mon emploi du temps profesionnel l’oblige). C’est en tout cas ce qui me parait le plus sage à l’heure actuelle car je mange vraiment beaucoup de documentation en ce moment (petite pensée pour les tests fonctionnels qui arrivent). Cela devrait donc donner quelque chose dans le genre :

• Semaine 1 : Création du module, des fonctions de bases et de la partie administration
• Semaine 2 : Création du frontend et si besoin, ajout de fonctions dans le model
• Semaine 3 : Création du plugin correspondant au module

Au niveau des modules, je part à priori la dessus :

• Création du module page
• Création d’un module contact (avec un formulaire de contact type)
• Création du module post (aka articles/catégories)
• Création du module SEO

Une fois ces modules créés :

• Refactorisation du model et des différentes fonctions afin d’optimiser le tout au niveau technique
• Ajout de fonctionnalités type AJAX pour le backoffice

Et enfin, création de nouveaux modules selon le même principe : commentaires, FAQ… Le projet sera ouvert à ce niveau. Il sera bien évidemment possible de créer son propre plugin pour améliorer peanut. Il faudra également que l’on parle à un moment de la tournure du projet au niveaux des fonctionnalités, il y aura une question ouverte .

Nous pourrons donc considérer que peanut sera d’ici deux semaines utilisable en tant que CMS lite (par exemple 5 pages et un formulaire de contact) même si cela reviendra à sortir la grosse artillerie pour un petit besoin. Une fois les modules post/SEO créé, je m’occuperais de faire tourner mon blog sur peanut histoire d’avoir une démo « live ».

Pour terminer, un petit lien vers un article du blog de n1k0 qui m’a été utile pour ne pas utiliser getInstance dans la gestion I18n des formulaires du backoffice. Un blog incontournable à ajouter à ses flux RSS.

Semaine 3 – template, template, template

La semaine dernière a essentiellement servie à créer le layout du backend. Pas grand chose à dire à ce niveau, j’ai essayé de me faire un peu plaisir avec un peu de CSS3, un peu de jQuery et du xHTML (et oui, pas de HTML5 pour le backend). Je n’ai par contre pas encore pris le temps de valider les pages. Il peut donc y avoir quelques erreurs d’intégration. Le backoffice n’a également pas été testé sur la famille Internet Explorer mais je m’en occuperais dans quelques itérations au maximum car inutile de vous le cacher, mon prochain blog tournera bel et bien sur peanut (quitte à devoir évoluer avec).

Semaine 4 – spéciale sfDoctrineGuardPlugin

Comme je l’avais dis au début du projet, je comptais bien modifier sfDoctrineGuardPlugin. Lors de la création du projet, je suis parti sur la base du trunk de sfDoctrineGuardPlugin qui ajoute certaines fonctionnalités avec deux modules : sfGuardForgotPassword et sfGuardRegister permettant respectivement de récupérer son mot de passe et de se créer un compte.

Malheureusement, les process utilisés lors de ces étapes ne sont pas « corrects » dans le sens ou si effectivement ils fonctionnent, ils ne font pas forcément les choses correctement. Je me suis donc efforcé de modifier ces éléments afin de corriger un peu le tir, tout du moins à mon sens. Rassurez-vous, les modifications ne sont pas nombreuses mais en voici quelques unes.

sfGuardAuth

• Possibilité via le fichier app.yml d’autoriser ou non la connection via le nom d’utilisateur et le mot de passe

sfGuardUser

• Modification du fichier schema.yml afin qu’un utilisateur ne soit pas actif par défaut

sfGuardRegister

• Modification de la route afin de pouvoir gérer le process d’inscription
• Lors de la création de compte, un email est envoyé à l’utilisateur afin de confirmer la création du compte
• Modification du process d’inscription qui va se charger de vérifier certains points importants avant d’activer le compte

sfGuardForgotPassword

• L’email envoyé par défaut indique un délai de 24H pour valider son compte mais le code n’imposait pas de limite et n’enregistrait même pas la limite correctement
• Ajout d’une tache permettant via cronjob de supprimer tous les utilisateurs n’ayant pas validé leur compte

De façon générale - Ajout de traductions (uniquement en français)

Parce qu’il faut tout de même le dire

Ce qui est actuellement en place est bien entendu perfectible. Le process d’inscription par exemple va générer une chaine sha1 basée sur le nom d’utilisateur, son adresse email et le csrf token de l’application et comme vous pouvez vous en douter… Il y a mieux (mais il y a aussi largement pire).

Pour moi, il faudrait créer une nouvelle table permettant de stocker les utlisateurs en cours d’inscription avec une clé unique en base de donnée afin de vraiment garantir la sécurité à ce niveau. L’autre option pourrait être de générer le sha1 sur la base du timestamp de création du compte qui pourrait ainsi (puisque stocké en bdd via created_at) servir de base un peu plus fiable. Autre solution, enregistrer l’utilisateur, récupérer l’objet utilisateur et générer quelque chose d’unique basé sur le salt par exemple.

Ceci dit je préfère attendre quelqu’uns de vos retours et mettre tout ça dans ma todolist pour un (éventuel et certains) refactoring dans le futur.

Autre chose, l’ensemble de ce travail a directement été fait dans le plugin sfDoctrineGuard car cela fais vraiment parti pour moi des fonctions à assurer au minimum et non à rajouter à la volée suivant les besoins de chaques projets (contrairement à la personnalisation des templates par exemple). Vous pouvez donc très bien surcharger ce qui est fait mais par défaut, une personne s’inscrit, reçoit un email de confirmation puis confirme son compte et cela tiens quand même plus la route qu’une inscription directe sans plus de vérification que ça.

Enfin, les tests unitaires ne sont pas complets et il faut vraiment que je m’y mette. Cela me dépasse encore un peu pour le moment. Je vois bien le principe mais je ne sais pas si c’est parce que j’ai l’habitude de chercher à faire tout de suite compliqué mais la… Je ne serais pas contre un petit cours à l’oral avec démo et questions connes en direct.

Ceci dit et si jamais j’arrive (ou nous arrivons via vos éventuelles contributions) à améliorer le plugin sfDoctrineGuard, j’aimerais le proposer afin qu’il soit intégré aux plugins (voir remplacer la version actuelle). Certaines conversations lues sur IRC me font dire que ce ne serait pas une mauvaise chose.

Petit détail d’importance, il faut que vous sachiez que mon anglais est encore moins bon que mon français à l’écrit en ce moment. Si jamais vous voulez modifier ça parce que… Hum… Okay mais bon il y a mieux, n’hésitez pas. Il faudrait également s’occuper de la traduction espagnole (puisqu’il y en a une pour le plugin) pour ne pas faire de malheureux mais la… Je vous laisse faire.

A quoi peut servir peanut actuellement ?

Si jamais vous vous posez la question, peanut peut vous servir (dans l’état actuel) à tout et à rien puisqu’il n’assure rien d’autre que la gestion de vos utilisateurs, groupes et permissions. Il est donc envisageable de faire n’importe quoi autour de ça : Réseau social, trombinoscope, intranet, extranet… Et j’en passe.

J’essaierai de vous donner ce genre d’exemples à chaque itération.

Le débat de la semaine

Le débat de la semaine porte sur la traduction i18n pour les setFlash(). Un gist a donc été créé et de la même façon que lors de la précédente question ouverte, je vous invite à l’enrichir via vos différentes méthodes afin de trouver les différentes façons de faire. Vous en trouverez actuellement trois, plus ou moins sexy mais qui fonctionnent toutes.

A venir

Le premier module du CMS permettant tout simplement de créer des « pages » (comprendre pages dynamiques peu modifiées du type CGU/CGV/…) pour votre site Internet.

Et pour finir

J’ai activé le système de donation sur le projet. A défaut d’aller directement dans mes poches, tout sera stocké sur un compte paypal dédié dans le but de m’offrir certaines formations dispensées par SensioLabs Trainings qui seraient à priori :

• PHP niveau 1 : bases
• PHP niveau 2 : POO
• Symfony 1.4 + Doctrine
• Symfony et REST
• Doctrine

Bien entendu, cela pourra évoluer (je l’espère bien) avec ce projet puisque le but pour moi est de pratiquer encore et encore afin de m’améliorer jusqu’au moment où je pourrais trashtalk sur PHP .

Et pour rappel, un lien vers le projet.