Discussion :

[Sylvanocry]

Bonjour les loulous !

Je ne suis pas débutant sur le fofo, mais je n'écris plus trop souvent parce que je commence a avoir un peu de bouteille dans le développement et j'aime me débrouiller tout seul.

Néanmoins aujourd'hui j'ai besoin de votre communauté. La communauté c'est sacré ! C'est d'ailleurs pour ça que je vais allez faire un petit tour au niveau du forum symfony pour aider mes congénères dès que j'ai fini avec vous ^^.

Pour tout vous dire, je suis étudiant en dernière année pour un M2 informatique et je suis en train de rédiger mon mémoire. L'intitulé est "L'évolutivité et la rétrocompatibilité des Frameworks web PHP". Donc je parle de SF2, ZF2, Cake.

Je suis sur la partie de "MAINTENANCE D’UN FRAMEWORK" avec ma sous partie "IMPACTS DE MAJ".

Ici, je pense parler de l'importance des tests unitaires pour les mise a jour, des failles de sécurité qui sont résorbé, des nouvelles fonctionnalités, des corrections de bug... Mais a vrai dire je sèche un peu.
J'ai aussi beaucoup regarder les Changelog etc. Mais il est surtout dit "on a fait ça" que "on a fait ça parce que ça".

En tout cas, merci pour vos futures réponses si j'ai eu le droit de retenir votre attention jusque là =)

Sylvain.

[grunk]

En tout cas, merci pour vos futures réponses

Dans l'attente de ta future question

[Sylvanocry]

Dans l'attente de ta future question

C'est vrai... Ca me paraissait "explicite" mais non en fait ^^

"Quelles sont pour vous les impacts des mise a jour d'un Framework ? De quoi parleriez vous ?"

[grunk]

L'impact d'une mise à jour doit être le plus faible possible. Comprendre qu'un framework qui toutes les deux semaines t'obliges à répéter ton code risque de vite perdre ses utilisateurs.

Tu peux parler du fait qu'on rencontre généralement 2 types de mise à jour :

- Les correctives , celle qu'en générale on rechigne pas à faire parce que sa comble les failles de sécurité ou des bugs existants

- les fonctionnelles , qui incluent bien souvent une corrective et qui en plus ajoute de nouvelles fonctionnalités et touche parfois à l'API.

C'est moins évident mais il pourrait être intéressant de faire un point sur la proportion des sites qui tiennent leur FW à jour une fois en production.

Sur un nouveau projet on récupère en général toujours la version la plus à jour mais ensuite ? Surtout quand cette mise à jour risque d’entraîner des modifications du code et donc forcément des coûts.

[Sylvanocry]

C'est moins évident mais il pourrait être intéressant de faire un point sur la proportion des sites qui tiennent leur FW à jour une fois en production.

Sur un nouveau projet on récupère en général toujours la version la plus à jour mais ensuite ? Surtout quand cette mise à jour risque d’entraîner des modifications du code et donc forcément des coûts.

J'avoue que c'est un point intéressant. Par exemple sur mon site perso : www.switcharound.com, je suis toujours en Symfony 2.2. Donc c'est une bon point, néanmoins je cherche depuis 1 heure je trouve pas ce genre de state ^^ J'ai même installer Wappalyzer, mais il ne détecte pas les Framework.

J'aimerai avoir d'autres avis si vous me lisez ^^ Mais merci beaucoup pour ce retour grunk.

[bannik]

Et bien, je viens justement de passer ma version de codeigniter de 2.0.2 à 2.1.4.

Ce que j'ai fait:

installer la nouvelle version "vide"
Copier mon répertoire application sauf les fichiers de config
Adapté les nouveaux fichiers de config à mon application


J'ai dû aussi supprimer tous les "?>" de la fin des fichiers php car ça ajoutait des espace en début de réponse du serveur.

Pour le reste, tout roule

[imikado]

Ca dépend des frameworks, dans ma boite, on utilise beaucoup zend framework, et on a pu apprécier la non retrocompatibilité entre les versions de la même branche

Bilan on a 5-6 versions du frameworks incompatibles entre elles

Sinon d'habitude, le premier chiffre indique si on doit verifier la rétro-compatibilité
Par exemple dernièrement en inaugurant sa branche 2.* Zend framework a clairement indiqué une perte totale de retro-compatibilité, mais ici c'est normale, ils ont bien changé le premier numéro

Personnellement, c'est un soucis qui m'embêtait et j'ai fait en sorte que depuis 2009 il n'y ai aucune perte de retro-compatibilité entre les différentes mises à jour de mon framework, malgré les améliorations et fonctionnalités supplémentaires ajoutées depuis

[Sylvanocry]

Merci de vos réponse,

si je peux avoir encore des retours ça pourrait être vraiment sympa =)

Sylvain

[Sylvanocry]

Bonjour les loulous techos !


Voilà je vous avais déjà parlé de mon mémoire, et on est maintenant à 10 jours de le rendre. J'ai beaucoup avancé dessus, mais je me retrouve bloqué sur ma dernière partie, j'aurai besoin de vous =)

Que je vous explique un peu le topos. J'ai une problématique "Evolutivité et rétrocompatibilité des Frameworks PHP"

Je suis très content de mon sujet et je le trouve de plus en plus intéressant. Néanmoins, je bloque sur ma dernière partie. Ou bien je l'ai mal cernée, ou alors je l'ai mal intitulée, ou encore je me vautre complètement et je ne pars pas sur la bonne chose.


Je vous explique vite fait ce que j'ai déjà rédigé :



Mon introduction est parsemé de plusieurs questions, qui font un peu le plan de cette dernière :

Introduction

Qu'est ce que la rétrocompatibilité

Qu'est ce qu'un Framework

Qu'est ce qu'un CMS

Lequel choisir

Pourquoi certains CMS évoluent vers des Frameworks

Pourquoi ne pas faire mon propre Framework

Aspect economique de la mise en place d'un Framework

Les pours / Les contres


Première partie : Intégration d'un Framework

Structure interne du Framework

- les différents patterns avec explication de MVC

- les ORM

Intégration design

- explication des moteurs de template

Intégration métier (totalement vide... là je pense que j'empiète sur "les différents patterns" j'aurai besoin de votre aide ici ^^)

Choix du Framework

- performance, outillage, internationalisation ....


Deuxième partie : Maintenance d'un Framework

Communauté : tout se que l'on doit savoir sur les communautés !

Impact des mise a jours :

Mise a jour corrective (correction de bug, test unitaire, sécurité, changelog)

Mise a jour fonctionnelle ( très peu de contenue là aussi, à part un exemple)

Les outils

Vagrant, gestionnaire de version, gestionnaire de dépendance, intégration continue.


Troisième partie : Application rapide des mises a jour

Et donc là... J'ai l'impression que je vais refaire ma deuxieme partie. Avec Composer, les risques etc... Peut être un peu plus poussé bien sur, mais j'ai tout de même cette impression de refaire deux fois la même chose.

Auriez vous des idées, ou carrément d'une autre partie ?

J'ai lu ceci : http://blog.mageekbox.net/?post/2012...est-comme-ZF2-! qui pour moi était très intéressant, surtout au niveau de cette phrase :

"En tant que directeur technique, j'aurais adoré qu'il me parle du respect de la compatibilité entre deux versions mineures (attention, il y a un troll dans ce qui précède…), de la compatibilité avec PHP 5.4 et PHP 5.5, de la politique de support, de la durée de vie espérée de Symfony 2.1, de la feuille de route du projet, bref, qu'il me rassure sur la pérennité des développements basés surSymfony 2 que je fais réaliser aujourd'hui par mon équipe avec des éléments tangibles."

Mais élargir là chose au niveau des différents Framework, non spécifiquement Symfony2.

Voilà j'aimerai votre avis là dessus ! De plus, je compte rajouter une partie de "comparaison" des Framework dans mon introduction en présentant SF2, ZF2 et CakePHP.


Merci à tous de votre aide !

[imikado]

La perénnité à travers le temps est une bonne question: par exemple vous installer votre application avec le framework sur un serveur à un instant T est-ce que N mois plus tard avec les mises à jours celui-ci ne va pas utiliser des fonctions d'une version plus récente de php ?

Pour votre question:
"Pourquoi certains CMS évoluent vers des Frameworks"
Je dirais plutôt le contraire, personnellement, avec mon generateur web, je me rapproche de plus en plus d'un CMS en permettant en un clic de générer un CRUD, un module intégrable, un menu et très prochainement un module d'authentification

Il est plus simple de partir d'un framework et de pousser un CMS s'appuyant dessus que le contraire: on part d'une bonne base de code avec une bonne architecture pour l'utiliser et monter une couche au dessus.

On ne commence pas à coller le papier peint sur les murs en briques

Sinon, un aspect à bien prendre en compte: la sécurité
Pour vous guider, la page sur mon framework (xss,xsrf...) trop peu de framework implémente ou sont clair sur le sujet http://mkdevs.com/security.html

Et pour comparer les frameworks n'oubliez pas http://socialcompare.com/fr/comparis...rks-comparison

[grunk]

Intégration métier (totalement vide... là je pense que j'empiète sur "les différents patterns" j'aurai besoin de votre aide ici ^^)

Tu peux parler ici des avantages du FW dans l'intégration métier. Comment il va te faire gagner du temps grâce à l'utilisation de brique prête à l'emploi.
L'exemple des bundles de SF2 est à mon avis très parlant ici.

Il faut aussi également parler des galères que celà va t'apporter. Puisque tu es contraint dans un cadre de travail (abile traduction de framework ) yu ne peux pas forcément faire ce que tu veux.
Je sais qu'à une certaines époque (c'est peut être mieux maintenant) les ORM devenait très vite un enfer à utiliser dès qu'on travaillait avec des bdd complexes.

Il faut également penser performance. Comment cette grosse usine à gaz de SF2 (troll inside) va t'il impacter les performances de mon code métier ?
Pour moi c'est déterminant dans le choix d'un framework. Par exemple si j'ai besoin d'un cache quelconque pour que ça fonctionne normalement , je passe mon chemin, en revanche si la gestion des caches intégré me permettra dans le futur de retarder le changement du serveur , là ça m'intéresse.

Troisième partie : Application rapide des mises a jour

Pas certains que la gestion de dépendances mérite une partie. Autant en parler rapidement dans les outils.

[imikado]

Tu peux parler ici des avantages du FW dans l'intégration métier. Comment il va te faire gagner du temps grâce à l'utilisation de brique prête à l'emploi.
L'exemple des bundles de SF2 est à mon avis très parlant ici.

Il faut aussi également parler des galères que celà va t'apporter. Puisque tu es contraint dans un cadre de travail (abile traduction de framework ) yu ne peux pas forcément faire ce que tu veux.
Je sais qu'à une certaines époque (c'est peut être mieux maintenant) les ORM devenait très vite un enfer à utiliser dès qu'on travaillait avec des bdd complexe.

Il faut également penser performance. Comment cette grosse usine à gaz de SF2 (troll inside) va t'il impacter les performances de mon code métier ?
Pour moi c'est déterminant dans le choix d'un framework. Par exemple si j'ai besoin d'un cache quelconque pour que ça fonctionne normalement , je passe mon chemin, en revanche si la gestion des caches intégrer me permettra dans le futur de retarder le changement du serveur , là ça m'intéresse.


Pas certains que la gestion de dépendances mérite une partie. Autant en parler rapidement dans les outils.

Effectivement il faut également comparer les performances

J'avais à l'époque fait un petit benchmark entre 3 modes:

Une base de donnée avec 100 000 entrées dans une table article
l'outil time (linux) utilisé 10 fois sur une page listant dans un tableau html ces 100 000 articles

Les résultats:
- sans framework ni orm: entre 0m0.032s et 0m0.041s
- ORM de Zend framework: entre 0m16.817s et 0m19.180s
- ORM du mkframework: entre 0m3.495s et 0m3.648s


cf : http://www.developpez.net/forums/d12...on-par-milieu/