Ma Titine

Je vous ai précèdement expliqué un peu notre infrastructure, ça ce passait ici.

Aujourd’hui parlons un peu d’optimisation pour le travail à plusieurs. Pour gagner en efficacité, il est important de pouvoir développer sereinement sans embêter les copains. Or, nous sommes 3 (petit rappel pour les nouveaux). Voici comment notre environnement de travail est organisé:

• Un SVN:
  • Une branche “trunk“, nous avons tous les trois accès à cette branche. C’est ce qu’on pourrait appeler “la branche principale du projet”. Elle sert principalement aux quick fix. Si un bug est découvert, il sera fixé directement sur cette branche.
  • Chacun de nous possède sa propre branche “dev” sur le svn. C’est une “copie” de la branche “trunk” mais dans laquelle nous effectuons nos développements “long”. Par exemple je travail sur une nouvelle fonctionnalité, je vais utiliser ma branche de Dev. Ainsi Kevin ou Raf ne verrons pas mes développements dans leurs branches. Je peux avoir des fichiers de configurations différents  de mes deux collègues, sans ce que cela les affecte.

• Une base MySQL dédiée. Celle ci est partagée par nous 3. De cette manière nous travaillons sur une base commune.

• Préproduction: Il n’est pas rare d’avoir des sueurs froide lors d’un commit : tout marche en local, une fois en production, c’est la cata! Pour palier à cela. Nous avons 4 préproductions surs notre serveur dédié.
  • Préproduction correspondant à la branche trunk. Permet de voir le rendu du site comme s’il était en production.
  • Préproduction correspondant au 3 branches de dev citées plus haut. Permet de tester ses développement et de les montrer aux collègues

Et la mise en prod dans tout ça ? J’y viens justement !

• Mise en production: J’ai confectionné un script (s’il peut en intéresser certains, qu’ils me demandent)  en bash. Son rôle est de faire un “diff” entre le ftp de la production (et oui, c’est le seul accès que j’ai sur l’hébergement !), et notre branche “trunk” locale. J’entends par la qu’il va s’occuper de trouver toutes les différences entre les 2 espaces distants. Ajout, suppression, modification, gestion des droits etc. Une fois ses différences détectées, il ne reste plus qu’a rendre la production identique à la préprod. Ce script a deux fonctionnalités:
• Simulation de mise en production: Le script se comporte comme s’il effectuait la mise en production, tout les opérations sont loggués dans des fichiers textes, mais aucune n’est réellement effectuée. Cela permet tout simplement de voir ce qu’il va se passer lors de la mise en prod. Un rapide coup d’oeil sur ces fichiers pour savoir si tout va bien dérouler.
• Mise en production. Étape identique à celle du dessus sauf que les opérations sont réalisés cette fois ci. Un backup de tous les fichiers modifié ou supprimé sur la prod est effectué à chaque mise en production. Pourquoi ? En cas de gros problème il m’est possible de revenir en arrière très rapidement.

Petite astuce supplémentaire. Nous pouvons passer depuis notre interface de backend le site en maintenance! Vous autres aurez droit à une belle page de maintenance. Pour nous 3, nous verrons le site comme d’habitude. Très pratique je vous assure.

Dernier point avant de clore cet article. Qui fait quoi dans tout ça? Pour éviter les problèmes, nous procédons de la manière suivante:

• Lorsqu’un développement est terminé sur notre branche de dev. Cette branche est “mixée” (merge), avec la branche “trunk” pour ensuite la mettre en production. Cette étape est exclusivement faite par Kevin et tout le monde est prévenu.
• Lors d’une mise en production, c’est moi qui m’en charge.

Mais Raf alors ? Bah Raf il compte les points… Plus sérieusement, il s’occupe d’autres trucs que Kevin et moi ne touchons pas ;).

Oui mais s’il arrive un problème sur maTiTine et que celui qui s’en occupe est en vacances !?

Nous avons un forum interne ou nous postons, entre autre, les informations sur comment marche quoi, toutes les informations techniques etc. Ça peut toujours servir un jour ou l’autre

J’espère que cet article servira à une dream team qui veut se lancer mais qui ne sait pas trop comment s’organiser pour développer !

Suite de notre introspection transcendentale sur cette première année de développement de Ma Titine. Aujourd’hui, les regrets! Quelles sont les choses que l’on ferait différemment si c’était à refaire? Personnellement, j’en vois deux:

• d’abord, spécifier plus en détails le site avant de se lancer dans le code. On nous le répète toujours en cours et à chaque fois, on dit "oui oui, mais c’est évident", et puis le jour venu, l’excitation aidant, on fonce tête baissée sans savoir où l’on va. Du coup, erreurs, tâtonnements, ajustements, modifs, etc se succèdent. De grosses pertes de temps et des occasions multiples de s’engueuler avec ses compères. Donc pas de précipitation, commencez par faire un plan détaillé du site, définissez chaque page de façon très fine: la mise en page, la constitution des formulaires, les champs, l’interface utilisateur, les effets, etc. Pour rédiger ce document, choisissez l’outil qui vous convient le mieux: un Wiki, un Google Doc ou un Google Presenter (je pencherais personnellement pour cette dernière solution). Une fois que tout est en place, passez à l’attaque, vous pouvez coder et vous verrez que ça ira très vite.
• ensuite, utiliser un framework, on en avait débattu au départ, on avait failli partir avec Symfony et puis on a décidé de tout coder nous mêmes "from scratch". On aurait sans doute gagné du temps à utiliser un framework existant, rien ne sert de ré-inventer la roue et les fonctions basiques. Et puis cela nous aurait donné une référence commune, un cadre de travail pour développer l’application. Après avoir bien creusé le sujet, j’ai deux chouchous: Code Igniter parce qu’il est léger et très facile d’apprentissage et Zend Framework parce qu’il est très très complet. Tous deux sont bien documentés et bénéficient de communautés actives.

Voilà, c’était la séquence auto-flagellation, à vous Cognaq-Jay!

Il est temps de faire un petit bilan bilan et de tirer les principaux enseignements de cette première phase de développement. Je voudrais donc commencer par faire un point sur ces outils indispensables qui nous ont accompagné fidèlement et quotidiennement dans le développement de Ma Titine.

Communiquer

• MSN messenger: quand on travaille à 3 et à distance, y a pas de secret, il faut COMMUNIQUER! Et il faut avouer que MSN marche plutôt bien pour ça. On aurait pu se servir de Skype aussi qui a une fonction intéressante d’historique des conversations.
• un Forum: un excellent moyen pour archiver certaines informations qu’on souhaite conserver et pour retrouver le pourquoi du comment de certains choix techniques. Indispensable aussi pour communiquer en mode asynchrone quand on n’arrive pas à trouver un créneau pour se retrouver sur MSN.

Dessiner

• Inkscape: j’en ai déjà parlé, c’est le logiciel de dessin vectoriel gratuit qui permet de tout dessiner depuis le design général du site jusqu’au moindre petit bouton. Simple, puissant et facile d’accés!

Développer

• Eclipse ou Notepad++: selon qu’on est un codeur furieux ou pas on choisira l’un ou l’autre de ces éditeurs de code, les deux ont leurs avantages, Eclipse est évidemment nettement plus puissant et peut s’enrichir de nombreux plugins, Notepad++ a pour lui la légèreté
• SVN: le celèbre gestionnaire de version absolument nécessaire quand on travaille à plusieurs et particulièrement pratique pour conserver l’historique de son code.

Ajaxifier

• XAJAX: la librairie PHP/Javascript qui permet de faire des requêtes AJAX les doigts dans le nez.
• JQuery: the librairie Javascript qui monte pour faire de jolis effets très web 2.0, très riche et simplissime d’utilisation, impossible de s’en passer une fois qu’on y a goûté!

Débugger

• Firebug: l’outil ultime pour ajuster finement ses feuilles de style sous Firefox, debugger ses pages ou ses requêtes AJAX. Dommage qu’il n’y ait pas de réel équivalent sous Internet Explorer.

On a beau développer ce projet en amateurs éclairés, on  est parfois obligé d’utiliser des outils pro pour se faciliter la vie. Ce softeux de Julien m’a donc sorti un SVN de derrière les fagots pour faciliter le développement à plusieurs du site. SVN pour les novices, c’est un système qui permet de gérer la configuration du code afin de pouvoir tracer de façon très fine toutes les modifications apportées par les différents développeurs. Pour l’électronicien que je suis, SVN, c’est d’abord une sacré usine à gaz! Mais comme je n’avais pas le choix, j’ai installé Tortoise SVN et je me suis plongé dans la doc (heureusement en français). Eh bien croyez le ou non, j’ai réussi à comprendre le truc. Mieux que ça j’ai été agréablement impressionné par la facilité d’utilisation et la puissance de la chose. Bon allez, je vous laisse, j’ai quelques fichiers à “commiter”!

Voilà quelques mois que le projet est lancé et un petit bilan peut-être éfféctué :

- Les fonctionnalités de bases sont là, pas encore toute développées mais on y travaille. Plein d’idées se bousculent dans nos têtes, on les mets de coté pour l’instant mais c’est pas ce qui manque.

- Le logo est fini comme évoqué juste en dessous, le design est bien avancé, je suis en train de convertir en css/html ce que Raf m’a donné en image. C’est plutôt dans les tons de couleurs chaudes, mais je vous en dit pas plus.

- Pour le dev à proprement parlé, Kef est en ce moment même en vacances donc un peu en stand by pour le moment. Le temps que je finisse le design et je continuerai de mon coté. C’est un gros chantier mais on va y arriver, en esperant sortir une version le plus vite possible.

Les objectifs fixés sont : sortir une version beta pour nous, aux alentours de début septembre, puis passé en beta privée début octobre si tout se passe bien. D’ici là Kef va continuer developper en grosse partie, Raf va s’occuper des aspects de com’ et moi même continuer à developper et integrer tout ça dans le design.

Stay tuned

Je ne vais pas vous faire un scoop en vous dévoilant que le site sera à la sauce Web2.0.

Tant au niveau du design que des effets nous allons essayer de proposer un service dans la vague du web actuel. Cela passe par certaines technologies et notamment l’Ajax.

On a sûrement du vous la faire souvent mais l’Ajax n’a rien à voir avec un produit de nettoyage… C’est une techno mélangeant PHP et Javascript qui permet de rendre vachement plus agréable et pratique votre website. Prenons l’exemple d’une page d’inscription, rien de plus angoissant qu’une fois cliqué sur “Envoyer” vous retombiez sur la même page avec du rouge de partout. Bien souvent ça vous oblige à retaper 40 fois votre mot de passe (et en double s’il vous plaît !) et à corriger vos erreurs précédentes pour pouvoir, enfin, vous inscrire.

Avec l’Ajax, ce temps est révolu. C’est tellement plus pratique d’interroger la base de données en temps réel et d’afficher directement si le champ est correct ou non. Bref que du bonheur pour les utilisateurs que nous sommes :).

Vous l’aurez donc compris, j’utilise de l’Ajax pour notre projet. Le choix de l’outil ne s’est pas fait immédiatement. Deux solutions s’offraient à moi:

• Tout coder à la main Javascript et PHP avec du HTTPRequest et compagnie
• Utiliser un framework

J’ai choisi la deuxième solution pour une raison évidente : pourquoi s’embêter à tout refaire soit même quand des outils le font déjà ! Vint alors le choix du framework. Personnellement j’ai opté pour Xajax. C’est un petit framework qui permet de se passer de la partie “javascript”. Vous écrivez votre fonction en PHP et Xajax s’occupe de l’écrire en JS pour vous ! Il n’y a que l’appel de votre fonction qui reste du Javascript à écrire par vos soins.

Voilà pour l’instant ce que j’utilise mais il se peut que j’opte pour MooTools dans le futur pour faire des effets “qui déchirent tout!”. Je réfléchis là dessus et me suis déjà documenté. Cependant notre objectif étant de sortir une beta fonctionnelle assez rapidement, les effets de la mort qui tuent ne sont pas notre objectif premier .

A suivre donc !

Pour ceux que ça interesse, Xajax et sa doc se trouve ici : http://www.xajaxproject.org/

L’été arrive, la chaleur avec et franchement sous le capot, bah ça chauffe !
Entre Raf qui nous pond un bon petit design et Ludo qui l’aide et fait les collectes d’infos nécessaire on peut dire que ça bouge.

Coté dev’ ça bouge aussi !

Après un petit temps de flottement, j’ai enfin enclenché le starter, laissant derrière moi Symfony qui après deux semaines de bidouillage m’a laissé plutôt perplexe.

Les fonctions liées au compte utilisateurs sont quasiement términées. A savoir :

• L’inscription
• L’authentification
• La demande de mot de passe (pour ceux qui l’égare)
• Les modifications concernant ses infos personnelles, mot de passe etc.

Je vais donc devoir maintenant m’attacher au gros du site :).

Secret oblige, je ne vous en dévoilerai pas plus pour l’instant, mais ça avance, pièce par pièce le puzzle s’assemble.

Après moultes tergiversations et valses hésitations, nous avons donc choisi de développer le projet avec Symfony, le framework PHP qui monte. J’entends déjà le troll que risque d’engendrer ce billet: “Ah ouais, Symfony c’est super …” “Non, Symfony c’est nul, Ruby on Rails, c’est mieux …”. Alors avant de troller, laissez nous justifier brièvement notre choix:

• parce que c’est du PHP et qu’on connaît bien PHP (mieux que Rails en tout cas)
• parce que Julien et Eric nos deux informaticiens de métier ont beau dire “nous on n’aime pas les frameworks”, ça leur démange quand même les mimines de tester ce nouveau truc dont tout le monde parle
• - parce que les doutes qu’on avait sur la charge serveur générée sont dissipés par le fait qu’on pourra héberger le projet sur un serveur dédié
• parce que Symfony est développé par des français et, sans tomber dans la préférence nationale, c’est tout de même un plus
• parce que Symfony peut nous permettre de développer beaucoup plus rapidement et de gagner du temps sur de potentiels concurrents
• parce que ce n’est pas un mal d’utiliser un framework et un modèle MVC quand on développe à plusieurs
• et pour finir l’argument qui tue: parce que ça fait bien dans les réceptions de l’Ambassadeur de dire “on utilise Symfony”!