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.

ça fait maintenant des années (et oui ça va vite) que l’on parle de Web2.0, et le monde commence à se mettre d’accord sur le fait que Web2.0 est … flou.

• Welcome to the new world of Web 2.1
• What the hell is Web 2.1 RC 1 ?

Vivement la bêta du WEB2.2 … lol , ceux qui ont suivie le grand buzz du web2.0 doivent bien rigoler

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’objectif de ce groupe, est de généraliser l’utilisation et les méthodes associées aux interfaces dites « riches », en créant et faisant évoluer des APIs existantes, comme le composant XMLHttpRequest (pierre angulaire de AJAX, qui existe depuis plus de 4 ans maintenant, et qui fait un buzzard pas possible depuis quelques temps).

Le groupe de travail propose déjà une liste d’APIs, la plupart de celles ci seront des documentations, généralisation et sûrement des  standardisation de composants/APIs que nous utilisons déjà, comme : le langage de requête, XPATH, sur les fichiers XHTML/XML, un DOM plus concentré sur la gestion des événements utilisateurs, et la classe XmlHttpRequest.

D’autres APIs sont plus novatrices, presque bouleverssantes :

• L’évolution du composant d’upload de fichier, qui devrait intégrer des méthodes de contrôle plus poussées au niveau client (taille de la pièce jointe, son type etc..). On parle même d’une certaine automatisation pour ce composant, avec son lots de problème de sécurité qui en découle….
• L’implémentation d’une couche de communication « sockets »… permettant des connections autre que le HTTP, depuis le client  léger. Ce serait une évolution (révolution) majeure, on passerait du mode déconnecté à un mode connecté.
• L’évolution du stockage d’information du coté client, on passerait du cookie à un système plus complet, donnant la possibilité de stocker plus de données, on évoque la possibilité de pouvoir, grâce à ce mode de stockage persistent, utiliser une application tout en étant déconnecté du réseau.

L’objectif des 2 derniers points est de créer des sessions plus « forte » entre utilisateur et l’application.

D’autres travaux du groupe traiteront des fonctionnalités type drag&Drop, des barres de progressions etc…( un tas d’autres widgets devraient apparaitres au fil des discussions).

La plupart de ces APIs, méthodes et composants existent déjà, implémentés de différentes manières depuis des années, l’effort à réaliser pour les mettre en oeuvre était jusqu’à présent trop important.

L’objectif est de réduire l’effort nécessaire, en assurant une compatibilité entre les plate formes, une réduction du code source à écrire/maintenir (et à transférer) et surtout en leur garantissant une certaine pérennité à travers le sceau du W3C.

Pour résumer, on s’oriente vers un nouveau type d’usage du client léger ente clients et serveurs,  avec des possibiltés d’avoir des sessions plus forte, plus fiable et moins couteuses (réseaux & serveurs) grace au stockage persistent avancé sur le client et les sockets.

On buzzera surement dans quelques années sur le Web 3.0