Yep, effectivement aucun de ces standards ne parle de la qualité du code. Ils sont juste là pour essayer d'homogénéiser le code d'un projet à l'autre.
Comme je le disais ces PSR sont tout-à-fait discutables, mais l'objectif est louable selon moi. Et le trio PSR-0 / Packagist / Composer est à mon avis une avancée majeure pour le développement PHP.
Enfin, nous disposons en PHP un gestionnaire de packages assez ouvert pour permettre à chacun d'apporter sa pierre à l'édifice - ce que n'était pas PEAR.
En ce qui concerne Symfony 2 et les autres frameworks que je citais, on peut ne pas aimer mais ça n'est tout de même pas de leur faute si tout le monde ne les utilise pas correctement ! :-)
On peut faire effectivement un projet Symfony dégueulasse, mais on peut tout aussi bien faire un projet "pur PHP" bien crade ;-) Là encore, le socle technique ("PHP nu", SPIP ou "Framework X") ne garantit rien concernant la qualité du code.
Ma charge à l'encontre de SPIP concernait plutôt la façon dont est fichu le code, qui me rappelle ce qu'on faisait au début des années 2000.
Quand je vois du code HTML/Javascript au milieu du fichier permettant de gérer l'authentification, personnellement ça me chiffonne.
Quand je vois ça, j'avoue que ça ne m'inspire pas non plus : $anciens = sql_allfetsel('id_auteur','spip_auteurs','login='.sql_quote($newlogin,$serveur,'text')." AND statut='5poubelle'",'','','','',$serveur);_
Bref, je me permettais juste de donner mon humble avis sur cette technologie. Je me suis permis effectivement de dénigrer le code de SPIP, mais je reconnaissais également que bien utilisé il peut donner des sites complets.
Le code source de SPIP me semble archaïque, de mon point de vue ; mais c'est tout-à-fait subjectif.
Il y avait pour moi un paradoxe entre d'un coté cette cette annonce de l'ouverture du code source d'un projet, a priori entre autres destinée à faire venir des contributeurs, et d'un autre coté le socle technique choisi, qui à mon sens était plutôt susceptible de ne pas attirer grand-monde.
Mais je constate que SPIP est encore populaire et qu'il a son public. Tant mieux ! :-)
Utiliser une technologie qui mélange l'anglais et le français, je ne suis pas convaincu pas sûr que ce soit ce qu'il y a de mieux pour lutter contre l'analphabétisme en France.
On a certes les mots "boucle", "article", "couper", mais on a aussi les "if", "else", "foreach", et autres mot-clef anglophones de PHP, ainsi que "spip_unlink", "sql_allfetsel", etc. Certes, cela ne concerne que le code source de SPIP, et tout le monde n'aura pas forcément besoin de ces fonctions.
Mais les squelettes SPIP utilisent de toute façon HTML et CSS, qui sont 2 technos anglophones, et on a certaines balises de squelette anglophones au milieu des francophones, telles que "INSERT_HEAD_CSS", "SESSION_SET", "FOREACH", "ARRAY"… Je ne vois pas trop en quoi cela va aider qui que ce soit ?
J'ai envie de dire: encore heureux parce que PHP n'est pas vraiment un modèle d'écosystème…
Justement si, depuis quelques années on assiste à l'émergence de standards dans le monde du développement PHP, qui viennent enfin professionnaliser le langage et le faire sortir de sa signification initiale, Personal Home Page : PSR-0, PSR-1…
De même, Packagist et Composer sont là pour distribuer le code et faciliter la gestion des bibliothèques développées par autrui…
Le temps où chacun faisait sa petite tambouille dans son coin, dans l'hétérogénéité la plus totale, est heureusement terminé.
Chaque projet garde bien évidemment sa personnalité, mais en suivant ces standards chacun se donne la possibilité de pouvoir utiliser les briques logicielles d'autres projets si besoin est. On peut critiquer les "PSR", mais PSR-0, associé à Composer, est tout de même une grande avancée qu'il me semble peu judicieux d'ignorer.
Cela étant, chacun est libre d'utiliser le socle technique qu'il souhaite. Je m'étonne juste de voir que SPIP semble encore si populaire à l'heure des technos comme Symfony 2, Laravel, Slim, Code Igniter… qui sont toutes interopérables, grâce à l'utilisation des standards PHP.
Désolé, je me doute bien que les commentaires comme celui que je suis en train de rédiger sont attendus, mais… SPIP ! 8-O
Je ne nie pas que SPIP bien utilisé puisse être une plateforme puissante en pratique, étant donné l'ancienneté de la technologie. Mais on est quand même à des années-lumières de ce qui se fait aujourd'hui dans le Web en général, et dans le PHP en particulier.
Je ne suis pas spécialiste de la chose, étant donné que j'ai toujours pris grand soin de me tenir éloigné de SPIP et que je ne l'ai utilisé (non sans souffrances) seulement quelques rares fois lorsque le client tenait absolument à utiliser cette techno, mais à mon humble connaissance il a toujours fait bande à part, ne se souciant absolument pas d'essayer de coller un tant soit peu à l'écosystème PHP.
Autant il peut être être bon de ne pas suivre les dogmes, autant dans ce cas-là je trouve toujours étonnant l'acharnement de SPIP à ne rien suivre de ce qui se fait.
On a tout de même des centaines de chouettes bibliothèques sur Packagist.org, avec notamment les composants Symfony 2 et Zend Framework, utilisés sur la plupart des sites Web PHP aujourd'hui et conçus pour pouvoir être utilisés de manière indépendante sans avoir à se coltiner tout le framework si on en veut pas. Des milliers de développeurs contribuent chaque jour à enrichir cet écosystème Open Source, auquel SPIP prend bien soin de rester totalement hermétique.
Et puis bien sûr, le code source en français… C'est un débat qui a été fait maintes et maintes fois, mais à un moment je pense qu'il faut tout de même accepter que l'anglais est la langue des nouvelles technologies, qu'on le veuille ou non. Si encore SPIP était basé sur un langage de programmation rédigé lui aussi en français, je dis pas, il y aurait une certaine cohérence :-)
Mais là on a toute une logique applicative en français, avec des incrustations un peu partout de mots-clefs et de fonctions natives de PHP, en anglais donc ; on se retrouve donc avec le c… entre 2 chaises, ça ne rime pas à grand-chose à mon sens.
En voyant le code source de SPIP et celui de Seenthis j'ai vraiment l'impression de voir du code PHP "à la papa", comme on en faisait dans le développement Web en 2000. Sur ce fichier pris au hasard, par exemple, on a du code HTML intégré au code applicatif, une couche d’abstraction à la BDD qui a l'air tout sauf pratique, des mélanges anglais/français en veux-tu en voilà (un fonction "spip_unlink" suivie d'une fonction "ecrire_fichier")…
Tout ça n'est que mon bien humble avis et n'engage que moi, et je n'ai aucune légitimé spécifique pour me permettre ces critiques, mais avec un tel socle technologique je ne parierais pas sur la capacité du projet à fédérer les contributeurs… :-/
Cela étant, vive l'Open Source bien sûr, et vive Seenthis ;-) (mais l'Open Source, n'est-ce pas également capitaliser sur ce qui existe plutôt que de réinventer une roue non-standardisée, totalement incompatible avec le reste ?)
Dommage tout de même qu'il manque ce qui devait être une des "killer feature " de Rails 4, à savoir la gestion intégrée des files d'attentes de processus asynchrones.
Cela dit, les gems comme Sidekiq font très bien le boulot en attendant… :-)
Pour se mettre à Ruby On Rails, en plus des excellentes ressources citées en fin d'article on peut également se référer à ce blog en français, qui détaille l'apprentissage de RoR pour un développeur PHP :
Je ne suis pas spécialement pro-dogme, mais utiliser des briques de base comme celles de Symfony 2 (ou une autre technologie "reconnue") permet notamment à un éventuel contributeur de se sentir rapidement à l'aise dans le code (il aura très probablement déjà travaillé avec ces classes), au lieu de devoir apprendre une énième couche d'abstraction de fichiers et tutti quanti.
Mais chacun est libre de faire son propre code, je ne critique pas - je voulais juste savoir ce qui avait motivé ce choix :-)
Par contre, comme le souligne Nasga, là ou c'est plus embêtant à mon humble avis c'est qu'effectivement vos classes ne respectent pas les PSR. On est pas obligé de respecter ces normes mais elles sont tout de même en train de se généraliser dans le monde du développement PHP, et ne sont pas dénuées de bon sens.
Il est tout de même plus facile d'associer du code tiers au sien si les deux ensembles de code suivent les mêmes normes, notamment pour tout ce qui concerne le chargement des classes ?
Bon courage à vous pour la suite et bonne chance à Slash-CMS, en tout cas ! Abondance de code libre ne peut nuire ;-)
Le CMS a l'air intéressant, mais pourquoi avoir tout fait "from scratch" ?
Il existe aujourd'hui de très bonnes briques applicatives en PHP (Zend Framework ou Symfony 2, par exemple ; tous deux peuvent être utilisé en tant que frameworks, avec leur architecture MVC propre, ou comme librairies en utilisant juste les briques applicatives nécessaires), qui auraient pu permettre de ne pas avoir à réinventer une énième fois la route.
Sinon on a Haxe, qui permet avec un seul langage, très propre, typé objet, etc, de compiler vers une pluralité de langages tels que le Javascript, PHP, ActionScript(ce pour quoi il a été conçu à la base), C++...
Plutôt que de rajouter une couche de script sur un langage de script comme le fait CoffeeScript (étant moi-même développeur Javascript, amha je ne vois pas trop l’intérêt ; une fois que l'on a bien saisi tous ses rouages, Javascript est un déjà un très bon langage de script), personnellement je préfère tirer le langage vers le haut, avec entre autres une couche objet digne de ce nom et un typage fort.
Haxe est robuste (il a déjà plusieurs années d'existence et d'utilisation en production), Open Source et multiplate-formes (et français, pour la petite histoire).
> http://haxe.org/doc/intro
[^] # Re: SPIP ?
Posté par JoyeuxJim (site web personnel) . En réponse à la dépêche Le code source de Seenthis est disponible. Évalué à 2.
Yep, effectivement aucun de ces standards ne parle de la qualité du code. Ils sont juste là pour essayer d'homogénéiser le code d'un projet à l'autre.
Comme je le disais ces PSR sont tout-à-fait discutables, mais l'objectif est louable selon moi. Et le trio PSR-0 / Packagist / Composer est à mon avis une avancée majeure pour le développement PHP.
Enfin, nous disposons en PHP un gestionnaire de packages assez ouvert pour permettre à chacun d'apporter sa pierre à l'édifice - ce que n'était pas PEAR.
En ce qui concerne Symfony 2 et les autres frameworks que je citais, on peut ne pas aimer mais ça n'est tout de même pas de leur faute si tout le monde ne les utilise pas correctement ! :-)
On peut faire effectivement un projet Symfony dégueulasse, mais on peut tout aussi bien faire un projet "pur PHP" bien crade ;-) Là encore, le socle technique ("PHP nu", SPIP ou "Framework X") ne garantit rien concernant la qualité du code.
Ma charge à l'encontre de SPIP concernait plutôt la façon dont est fichu le code, qui me rappelle ce qu'on faisait au début des années 2000.
Quand je vois du code HTML/Javascript au milieu du fichier permettant de gérer l'authentification, personnellement ça me chiffonne.
Quand je vois ça, j'avoue que ça ne m'inspire pas non plus :
$anciens = sql_allfetsel('id_auteur','spip_auteurs','login='.sql_quote($newlogin,$serveur,'text')." AND statut='5poubelle'",'','','','',$serveur);_
Bref, je me permettais juste de donner mon humble avis sur cette technologie. Je me suis permis effectivement de dénigrer le code de SPIP, mais je reconnaissais également que bien utilisé il peut donner des sites complets.
Le code source de SPIP me semble archaïque, de mon point de vue ; mais c'est tout-à-fait subjectif.
Il y avait pour moi un paradoxe entre d'un coté cette cette annonce de l'ouverture du code source d'un projet, a priori entre autres destinée à faire venir des contributeurs, et d'un autre coté le socle technique choisi, qui à mon sens était plutôt susceptible de ne pas attirer grand-monde.
Mais je constate que SPIP est encore populaire et qu'il a son public. Tant mieux ! :-)
[^] # Re: SPIP ?
Posté par JoyeuxJim (site web personnel) . En réponse à la dépêche Le code source de Seenthis est disponible. Évalué à 2.
Utiliser une technologie qui mélange l'anglais et le français, je ne suis pas convaincu pas sûr que ce soit ce qu'il y a de mieux pour lutter contre l'analphabétisme en France.
On a certes les mots "boucle", "article", "couper", mais on a aussi les "if", "else", "foreach", et autres mot-clef anglophones de PHP, ainsi que "spip_unlink", "sql_allfetsel", etc. Certes, cela ne concerne que le code source de SPIP, et tout le monde n'aura pas forcément besoin de ces fonctions.
Mais les squelettes SPIP utilisent de toute façon HTML et CSS, qui sont 2 technos anglophones, et on a certaines balises de squelette anglophones au milieu des francophones, telles que "INSERT_HEAD_CSS", "SESSION_SET", "FOREACH", "ARRAY"… Je ne vois pas trop en quoi cela va aider qui que ce soit ?
[^] # Re: SPIP ?
Posté par JoyeuxJim (site web personnel) . En réponse à la dépêche Le code source de Seenthis est disponible. Évalué à 2.
Justement si, depuis quelques années on assiste à l'émergence de standards dans le monde du développement PHP, qui viennent enfin professionnaliser le langage et le faire sortir de sa signification initiale, Personal Home Page : PSR-0, PSR-1…
De même, Packagist et Composer sont là pour distribuer le code et faciliter la gestion des bibliothèques développées par autrui…
Le temps où chacun faisait sa petite tambouille dans son coin, dans l'hétérogénéité la plus totale, est heureusement terminé.
Chaque projet garde bien évidemment sa personnalité, mais en suivant ces standards chacun se donne la possibilité de pouvoir utiliser les briques logicielles d'autres projets si besoin est. On peut critiquer les "PSR", mais PSR-0, associé à Composer, est tout de même une grande avancée qu'il me semble peu judicieux d'ignorer.
Cela étant, chacun est libre d'utiliser le socle technique qu'il souhaite. Je m'étonne juste de voir que SPIP semble encore si populaire à l'heure des technos comme Symfony 2, Laravel, Slim, Code Igniter… qui sont toutes interopérables, grâce à l'utilisation des standards PHP.
# SPIP ?
Posté par JoyeuxJim (site web personnel) . En réponse à la dépêche Le code source de Seenthis est disponible. Évalué à 10.
Désolé, je me doute bien que les commentaires comme celui que je suis en train de rédiger sont attendus, mais… SPIP ! 8-O
Je ne nie pas que SPIP bien utilisé puisse être une plateforme puissante en pratique, étant donné l'ancienneté de la technologie. Mais on est quand même à des années-lumières de ce qui se fait aujourd'hui dans le Web en général, et dans le PHP en particulier.
Je ne suis pas spécialiste de la chose, étant donné que j'ai toujours pris grand soin de me tenir éloigné de SPIP et que je ne l'ai utilisé (non sans souffrances) seulement quelques rares fois lorsque le client tenait absolument à utiliser cette techno, mais à mon humble connaissance il a toujours fait bande à part, ne se souciant absolument pas d'essayer de coller un tant soit peu à l'écosystème PHP.
Autant il peut être être bon de ne pas suivre les dogmes, autant dans ce cas-là je trouve toujours étonnant l'acharnement de SPIP à ne rien suivre de ce qui se fait.
On a tout de même des centaines de chouettes bibliothèques sur Packagist.org, avec notamment les composants Symfony 2 et Zend Framework, utilisés sur la plupart des sites Web PHP aujourd'hui et conçus pour pouvoir être utilisés de manière indépendante sans avoir à se coltiner tout le framework si on en veut pas. Des milliers de développeurs contribuent chaque jour à enrichir cet écosystème Open Source, auquel SPIP prend bien soin de rester totalement hermétique.
Et puis bien sûr, le code source en français… C'est un débat qui a été fait maintes et maintes fois, mais à un moment je pense qu'il faut tout de même accepter que l'anglais est la langue des nouvelles technologies, qu'on le veuille ou non. Si encore SPIP était basé sur un langage de programmation rédigé lui aussi en français, je dis pas, il y aurait une certaine cohérence :-)
Mais là on a toute une logique applicative en français, avec des incrustations un peu partout de mots-clefs et de fonctions natives de PHP, en anglais donc ; on se retrouve donc avec le c… entre 2 chaises, ça ne rime pas à grand-chose à mon sens.
En voyant le code source de SPIP et celui de Seenthis j'ai vraiment l'impression de voir du code PHP "à la papa", comme on en faisait dans le développement Web en 2000. Sur ce fichier pris au hasard, par exemple, on a du code HTML intégré au code applicatif, une couche d’abstraction à la BDD qui a l'air tout sauf pratique, des mélanges anglais/français en veux-tu en voilà (un fonction "spip_unlink" suivie d'une fonction "ecrire_fichier")…
Tout ça n'est que mon bien humble avis et n'engage que moi, et je n'ai aucune légitimé spécifique pour me permettre ces critiques, mais avec un tel socle technologique je ne parierais pas sur la capacité du projet à fédérer les contributeurs… :-/
Cela étant, vive l'Open Source bien sûr, et vive Seenthis ;-)
(mais l'Open Source, n'est-ce pas également capitaliser sur ce qui existe plutôt que de réinventer une roue non-standardisée, totalement incompatible avec le reste ?)
# Initiation à Ruby On Rails
Posté par JoyeuxJim (site web personnel) . En réponse à la dépêche Sortie de Ruby on Rails 4.0. Évalué à 3.
Dommage tout de même qu'il manque ce qui devait être une des "killer feature " de Rails 4, à savoir la gestion intégrée des files d'attentes de processus asynchrones.
Cela dit, les gems comme Sidekiq font très bien le boulot en attendant… :-)
Pour se mettre à Ruby On Rails, en plus des excellentes ressources citées en fin d'article on peut également se référer à ce blog en français, qui détaille l'apprentissage de RoR pour un développeur PHP :
[^] # Re: From scratch... ?
Posté par JoyeuxJim (site web personnel) . En réponse à la dépêche Slash-CMS, un CMS modulable et évolutif pour des développements spécifiques. Évalué à 1.
Je ne suis pas spécialement pro-dogme, mais utiliser des briques de base comme celles de Symfony 2 (ou une autre technologie "reconnue") permet notamment à un éventuel contributeur de se sentir rapidement à l'aise dans le code (il aura très probablement déjà travaillé avec ces classes), au lieu de devoir apprendre une énième couche d'abstraction de fichiers et tutti quanti.
Mais chacun est libre de faire son propre code, je ne critique pas - je voulais juste savoir ce qui avait motivé ce choix :-)
Par contre, comme le souligne Nasga, là ou c'est plus embêtant à mon humble avis c'est qu'effectivement vos classes ne respectent pas les PSR. On est pas obligé de respecter ces normes mais elles sont tout de même en train de se généraliser dans le monde du développement PHP, et ne sont pas dénuées de bon sens.
Il est tout de même plus facile d'associer du code tiers au sien si les deux ensembles de code suivent les mêmes normes, notamment pour tout ce qui concerne le chargement des classes ?
Bon courage à vous pour la suite et bonne chance à Slash-CMS, en tout cas ! Abondance de code libre ne peut nuire ;-)
# From scratch... ?
Posté par JoyeuxJim (site web personnel) . En réponse à la dépêche Slash-CMS, un CMS modulable et évolutif pour des développements spécifiques. Évalué à 1.
Le CMS a l'air intéressant, mais pourquoi avoir tout fait "from scratch" ?
Il existe aujourd'hui de très bonnes briques applicatives en PHP (Zend Framework ou Symfony 2, par exemple ; tous deux peuvent être utilisé en tant que frameworks, avec leur architecture MVC propre, ou comme librairies en utilisant juste les briques applicatives nécessaires), qui auraient pu permettre de ne pas avoir à réinventer une énième fois la route.
[^] # Haxe
Posté par JoyeuxJim (site web personnel) . En réponse à la dépêche Agrémentez votre JavaScript avec CoffeeScript 1.0. Évalué à 1.
Plutôt que de rajouter une couche de script sur un langage de script comme le fait CoffeeScript (étant moi-même développeur Javascript, amha je ne vois pas trop l’intérêt ; une fois que l'on a bien saisi tous ses rouages, Javascript est un déjà un très bon langage de script), personnellement je préfère tirer le langage vers le haut, avec entre autres une couche objet digne de ce nom et un typage fort.
Haxe est robuste (il a déjà plusieurs années d'existence et d'utilisation en production), Open Source et multiplate-formes (et français, pour la petite histoire).
> http://haxe.org/doc/intro