Deuxième journée intense, on a pu appliquer les techniques de refactoring de manière intéressante, des cas concrets avant une pleine explication des principes, certains découvraient d’autres s’émerveillaient.

Ce que j’ai retenu de cette journée c’est que l’essentiel de ce framework n’est pas dans son lot de fonctionalitée, mais, de mon point de vue, dans son coté chef d’orcheste (ça sonne bien avec ‘Symfony’ ) pour votre code; je m’explique :

Le framework, par son architecture vous guide dans l’écriture d’un code sur, fiable, et intéressant (en terme de cout, mais j’en parlerai précisement plus tard), en effet ne nombreux choix s’inspirent des « design pattern  » les plus éprouvés (j’en décrirais bientôt), et vous (certains) les suivez sans vraiment les connaître (ni meme savoir ce qu’est un design pattern), mais leurs principes vous les comprenez naturellement en pratiquant.

== Final Act ==

Confirmation de mon sentiment général, ce framework n’a pas été conçu de manière académique, mais plutôt pragmatique, fruit d’expériences et de confrontation avec des cas réels.

Cette troisième journée, à été l’occasion de voir :

• Les techniques de développement agile avec Symfony.
• De découvrir l’architecture de Symfony en nous présentant le « Workflow Symfony », le coeur de symfony, les méthodes pour étendre et/ou remplacer des composants, le système de cache composite hiérarchisé, le système d’internationalisation d’application etc…
• Techniques pour la haute disponibilité, et performance. On a mis en pratique c’est plutôt impressionnant.

Finalement ce final act a bien failli briser le coeur…. les coeurs, de mon petit macbook, quand j’ai lancé les derniers tests de charge avec Apache Bench, emporté par mon enthousiasme j’ai simulé 1000 utilisateurs simultanés sur mon projet symfony … lol bref c’était l’heure de partir prendre un dernier café, aprés la scéance Photo de groupe de la 1ere Symfony de Mozart Sensio.

(note: Le café était gratuit, illimité et de qualité pendant ces 3 jours)

Petit regret ce soir, les slides fournis de ces 3 journées, sur une clef USB offerte, sont au format .. Microsoft PowerPoint d’Office. Un format PDF aurait été sympa, sachant que 9 auditeurs sur 10 étaient sous Linux ou MaxOsX.

Pour conclure, je suis plutôt content de la qualité du travail des 2 compositeurs lors de ces 3 jours, et j’abandonne mon framework maison, que j’utilise et fait évoluer depuis des années.

Chaque auditeur devait apporter son portable pour travailler directement dessus.
La première chose qui m’a frappé, c’est le nombre important des personnes qui sont venu avec leur macbook ou macbook pro (les 2/3) , les autres des PC, mais tous les PC (sauf 1) étaient sous … linux.. incroyable !

Sur la forme, le workshop s’est passé dans un beau Hôtel Parisien, super accueil, super petit déjeuner, un brunch à 10h, un déjeuner… surprenant. ( fruits de mer ! ).

Sur le fond, j’ai pas appris grand chose… mais les échanges que j’ai eu avec Fabien Potencier et Francois Zaninotto, m’ont encore plus rassuré sur la pérénité de ce framework, surtout sur le positionnement et l’avenir de ce framework.

Vivement demain.

Il est toujours bon de rappeler que les commentaires de code, ne sont pas uniquement destinés à leurs auteurs; comme on a l’habitude de penser.

C’est fascinant de lire ces commentaires, on y trouve des choses assez commune, mais à mourir de rire.

On pourrait faire une étude anthropologique du développeur avec cette mine d’information.

Ce que j’ai observé en quelques minutes : le développeur est plutôt démocrate/de gauche, (pour faire de l’open source il faut etre un peu altruiste), inflexible avec lui même, certain d’écrire une oeuvre d’art, c’est son amour propre qui en prend un coup quand il découvre les « saloperies » des autres, .. ou les siennes…

Voici des exemples révélateurs …

Un dev, qui a du voir son club de foot prendre un but au moment où il pondait sa ligne.

Celui ci à du perdre énormément de temps à comprendre le raisonnement du précèdent développeur, JDG

Celui la aurait pu etre ce JDG, invoquer Dieu dans l’écriture d’un algo, c’est peu cartésien; en tout cas il l’air content, je suis persuadé qu’il ne sait pas pourquoi ça marche…

Un puriste commentant le travail d’un prédécesseur.

Alors, là trop fort, le dev justifie l’écriture des règles du « jeu de nain », au cas où il se ferait attaquer

voila aussi un puriste dans l’âme, ou un gros fainéant, remarquez le nom de la variable en dessous.


Lisez comme le développeur se fait mal au coeur à « salir » son oeuvre.


Certains sont honnête avec eux même

D’autres moins :

Le developpeur informatique est peu modeste c’est connu.

Il peut se taper des quelques délires.. de geek évidemment.

hihi, découverte macabre…

Et oui c’est dur

Ce type de commentaire est assez courant, comme il fait suite à ne nombreuses recherche sur un produit nom standard et peu documenté, on est toujours un peu énervé de trouver la solution microsoft.

idem

« Bug » c’est le mot anglais, en français c’est mieux

J’espère simplement que celui ne travail pas chez Airbus…

Paresseux !

Un concours interne, noter la nature du gros lot, c’est le franc symbolique du Geek ça !

On peut meme crier dans un commentaire

Ici, des commentaires expliquant la présence d’algorithmes anti-abrutis

Ecrire un commentaire, avant d’écrire le code, c’est pour se donner de la motivation…

Le developpeur limite homophobe… annonce la robustesse/virilité de son code

Celle là je l’aime bien, je connaissais le blanc cassé, le blanc ‘coquille d’oeuf’ le bleu azur, marine etc… mais il y a le « bleu de Bill » (Bill Gates) référence au bleu des écrans de plantage windows …

petite dédicace à Bill Gates encore une fois

Meme Jobs en prend pour son grade

Un peu de politique…

Je vous laisse découvrir d’autres perles :

Des codes sources, où le programmeur écrit délibéremment que l’application va planter

D’autres, où les utilisateurs sont pris pour les cons

Mise à jour 16/10/06 : par ce que c’est génial, je rajoute ces 2 là :

Dans le cas le plus terrible évoqué dans le précèdent billet, je situais le problème au niveau de la maîtrise d’ouvrage, l’accusant du blocage que celle ci imposait, car elle ne pouvait être intéressée par une refonte, qui rappelons le, produira une version fonctionnellement identique à la précédente.

En fait, je pense que dans ce type de cas, c’est à la MOE de calculer son risque (essentiellement financier) de refondre l’application.

En investissant du temps (de l’argent), pour refondre l’application, la MOE en gagnera sur la maintenance évolutive et correctrice qui suivra.
La MOE prête, en quelque sorte, le budget pour la refonte.

Elle peut même en faire profiter la MOA immédiatement après la refonte !

Un exemple.
Une application consomme 120 JH en maintenance correctrice/évolutive par trimestre.
Après refonte on estime ce chiffre à 48 JH.

La refonte coûte 400 JH
Pour financer celle ci, la MOE s’accorde une durée de « remboursement ». (important !)

En fonction de celle ci, la MOE peut calculer son taux de refinancement :
Si la durée est de 24 mois, elle chiffrera avec un taux de 2,04.

• sans refonte = 12 x 40 JH = 480 JH
• après refonte = 12 x (16 x 2,04 ) JH = 391 JH

Le bénéfice est immédiat.

24 mois après la refonte le coût annuel n’est plus que de 192 JH

Cette démonstration devrait permettre de comprendre comment une refonte, ou réécriture d’application, peut être intéressante.

En théorie, elle est rarement intéressante, et, de plus, dépend de paramètre fiable (coût de maintenance) et d’autres paramètres moins fiable puisque ce sont des estimations, comme le coût de réécriture, et le coût de maintenance après refonte.
De plus, la réécriture introduit de nouveaux risques, ceux liés à un développement d’application. (qualité, délais …)

Maintenant, Il faut voir qu’en pratique les applications sont réécrites, avec des objectifs comme la réduction des coûts de maintenance, l’augmentation des capacités de l’application à évoluer (évolutivité ou agilité), et peuvent aussi faire suite à des changements au niveau des plateformes (changements des politiques dans le SI etc…).

Finalement, c’est aux i-responsables d’application, de prendre ce type de decision stratégique, en espérant qu’ils puissent faire une démonstration de leur génie, autrement qu’en argumentant leurs études basées sur les articles de magazines n°01 en Informatique.

La méthode est au moins aussi vieille que le composant XMLHttpRequest, donc date de bien avant les années 2000, on utilisait cette méthode pour transmettre données et traitements, du serveur vers le client (et vice versa) et ce, de manière transparente, …. du AJAX quoi !

Sauf que la méthode ne se base pas sur un format XML ( aujourd’hui classique pour ce type d’architecture ) pour les échanges de données, mais sur un code interprétable directement par le client à son arrivée, qui vous met à disposition des objets, tableaux, fonctions et procédures utilisables instantanément !

La méthode est idéale à mes yeux pour un échange client serveur transparent (AJAX) pour certaines opérations simples (comme le chargement dynamique de listes, de combos, modification de l’interface etc..), car il n’oblige pas l’utilisation de composants XMLhttp… ni de parser XML dont on connaît les performances (pas de problème avec le temps CPU disponible sur le client, par contre, au niveau serveur nous n’avons pas la même disponibilité.) et permet en plus des données, de transmettre du code interprétable directement !

JSON a le mérite de vouloir encadrer la méthode, par son formalisme et ses interfaces disponibles pour l’utiliser avec un maximum de languages de programmation : ActionScript,C,C++,C#,Cold Fusion,Delphi,E,Erlang,Java,JavaScript,Lisp,Lua,ML and Ruby,Objective CAML,OpenLaszlo,Perl,PHP,Python,Rebol,Ruby,Squeak…
Le seul reproche que l’on pourrait faire à JSON, c’est de ne pas pouvoir transmettre du code de traitement (fonctions et precédures…).

• JSON – http://www.json.org/

Incroyable, hier j’ai fait une présentation à une maîtrise d’oeuvre (chef de projet et devs) des principes de AJAX, sans jamais prononcer les mots AJAX, WebDeuxPointZéro etc…..

Juste présenté les avantages, les possibilités et surtout une solution à un problème technique auquel les devs n’avaient pas de solutions.

En fait la boîte pour qui je travaille est tellement réticente à travailler avec des nouvelles technologies (on peut comprendre, quand on voit la qualité des productions du service, on ne prend pas de risques…..) que je me préparais à des retours du type, « Il faut quantifier le besoin, les outils », « Etudes d’impact », »Etudes de faisabilité », « Homologation de la technologie…. », « Méthodologie…. » (ça c’est les CDP qui en fait n’ont rien compris ou qui veulent du budget) et des réflexions protectionnistes de la part des Devs … rien de tout ça, en fait la solution présentée apparaissait tellement simple et innovante sans être révolutionnaire, parce qu’elle s’appuyait sur des technos connues … (Javascript, Woaaa !), qu’elle a été immédiatement codée et l?on me demande maintenant un petit document en support pour les équipes.

En fait, le Web2.0, AJAX (ça désigne quoi, des requêtes transparentes ?) ce sont plutôt des termes obscurs pour les esprits précis et cartésiens qui caractérisent les informaticiens (les vrais, pas ceux qui utilisent Word ou qui essayent de cliquer plus vite que leurs voisins…).

Je me demande quel accueil la solution aurait reçu si j’avais prononcé ces mots un peu trop nuageux.

Attention, je ne remet pas en cause le Web2.0 ou les nouveaux usages du web qui apparaissent ici et la, la plupart du temps en beta; je vous livre une expérience… )

Au passage, je suis passé pour un gourou… lol, dans l’obscurité une étincelle peut vous paraître plus aveuglante qu’un soleil en pleine nuit (le jour quoi).

L’application combine la simplicité d’un blog avec calendrier, gestion de taches, fichiers et couts.

A noter qu’un Fil RSS est généré automatiquement en fonctions des événements.

Homepage du projet

J’ai trouvé cet article trés interessant donnant plus des astuces d’organisation pour utiliser efficacement un logiciel de mindmapping dans une gestion de projet.