Journal Je n'aime pas le code moderne

Posté par (page perso) . Licence CC by-sa
21
15
jan.
2015

Sommaire

Cher journal,

Avant propos

Développeur PHP depuis près de dix ans, internaute depuis quinze et geek depuis vingt-cinq, comme tout bon geek, je fais de la veille. Je m'intéresse aux nouveautés, j'étudie scrupuleusement les spécifications des langages que j'utilise (soit PHP, Javascript, CSS et HTML), en bref, je me tiens au courant et j'applique les recommandations les plus récentes.

C'était mieux avant

J'adorais Internet. Je l'aime toujours, mais moins qu'avant. "Avant" ? Avant l'avènement des réseaux sociaux.

Similairement, bien que j'aime toujours coder, j'aime le code moins qu'avant. "Avant" ? Avant l'avènement des frameworks usines-à-gaz qui ne respectent même pas les principes élémentaires de codage ou du modèle MVC (du code logique dans des commentaires ? du code brut dans les templates ?).

Mon framework à moi !

Je travaille depuis quelques temps sur un framework maison, composé d'un loader du même genre que celui de CakePHP mais en plus lisible (CoreLoader::load_vendor('phpmailer') ou CoreLoader::load_controller('home') par exemple), d'un routeur particulièrement complet (prenant en charge des routes automatiques, les droits des utilisateurs en fonction de la route demandée, etc.), de templates, etc.

Bien que j'ai codé moi-même le gros du framework, l'idée reste qu'il s'agisse d'une agrégation des meilleures librairies dans leur domaine respectif:

Changement de cap

La philosophie du Libre

Hier, j'ai eu une épiphanie:

"Hey, coder toi-même ce qui existe déjà ? Pas trop la philosophie du Libre !"

Ok. Ça implique - apparemment - d'utiliser des trucs tout moches modernes du genre composer. Bon, allez, je m'y colle.

Je cherche un peu une librairie pour remplacer mon routeur, et je tombe sur un certain nombre d'entre elles:

Et puis tiens, PHP-Error pourrait être pas mal.

La déconvenue

Oh ! Il y a un éditeur intégré pour modifier le code en direct quand une erreur se présente ! Cool ! Oh, ça m'enregistre un fichier presque vide quand il y a un antislash dans un namespace ! Bon, ben encore une application moderne qui mise sur l'apparence et qui en fait est tout bugguée…

Mon application de test n'est pas à la racine. Aucun problème pour mon routeur, mais klein ne fonctionne pas sans .htaccess pour le rewrite, Aura est beaucoup trop gros et aucun des trois ne matche mes routes sur la variable PATH_INFO mais sur le chemin relatif depuis DOCUMENT_ROOT. Bizarre…

Cause et effet

De façon assez étrange, ni Smarty, ni Redbean ne mentionnent composer dans leur documentation, et PHPMailer s'en passe parfaitement. D'ailleurs, j'aime beaucoup la raison avouée pour laquelle l'auteur de Redbean ne propose pas de package composer. Certe, les trois peuvent s'installer via le gestionnaire de dépendances, mais de manière plus ou moins officieuse.

Personnellement, j'ai bien envie de tomber dans la facilité et voir un lien entre la qualité des librairies, le fait que composer soit obligatoire ou non pour les installer, et la vétusté/simplicité de leur site Internet.

J'ai testé pas mal d'autres librairies encore et je constate une chose: une grosse partie a une page web créée avec Bootstrap. Encore des clones de bootstrap… Certains mieux réalisés que d'autres toutefois, mais on sent toujours cette patte bootstrap, c'en est désespérant. Ni Redbean, ni Smarty n'utilisent bootstrap sur leur site.

Là encore, j'ai envie de tomber dans la facilité: comment avoir confiance dans une librairie dont l'auteur ne prend pas la peine de faire un site sans tomber dans le piège oisif de bootstrap, ou du moins, faire en sorte que ça ne se voit pas ?

Du coup, je ne comprends pas comment il est possible que de telles librairies ou outils puissent avoir une telle cote de popularité.

Le mal-aimé

En parlant de popularité, autre exemple: PEAR.

PEAR existait avant composer. Avoir sa librairie disponible sur PEAR était, à une époque, la quintessence, l'aboutissement, une reconnaissance extrême. Bien sûr, PEAR est un framework alors que composer est un gestionnaire de dépendances, mais tout de même. Aujourd'hui, tout le monde boude PEAR, à part Horde et quelques irréductible de ce que j'appelle l'artisanat du web, vestige d'une époque où le code devait être bien écrit, quasiment exempt de bugs, et fonctionner partout sans la moindre nécessité d'adaptation. Il semblerait qu'on ait perdu cette versatilité au prix d'artifices plus ou moins alambiqués (genre certains design-patterns, les namespaces, les traits, etc.).

Interopérable ?

Le pire, c'est que toutes ces libs modernes suivent les recommandations PSR, donc devraient être facilement utilisables partout quelle que soit la configuration du serveur sur lequel elles sont installées.

D'ailleurs, je crois que les "standards" recommandés par le PHP-FIG ne servent qu'à composer. Il y a évidemment quelques bonnes idées dedans (UTF-8 sans BOM, LoggerInterface, etc.) qui contribuent effectivement et efficacement à l'interopérabilité des librairies PHP, mais désormais, je fuirai les librairies arborant fièrement avoir suivi ces recommandations parce que cela signifie qu'il va être pratiquement impossible de les utiliser sans composer (qui a, par ailleurs, la fâcheuse tendance à installer tout un tas de truc que je n'ai jamais demandé et qui n'existe pas dans les archives).

On n'est jamais mieux servis que par soi-même

Au final, je vais faire ce que j'ai toujours fais: continuer de tester des librairies, et intégrer à mon framework les meilleures d'entre elles, les plus simples à installer et utiliser, même si elles devaient être quelque peu obsolètes (simplepie par exemple).

Pour ceux que ça intéresse, voici les différentes librairies que j'utilise, outre Redbean, PHPMailer et Smarty (sans composer et sans les avoir modifier de quelque manière que ce soit):

  • Munee - concaténation et minification à la volée de CSS et JS avec support de less, scss, coffescript, etc.
  • Parsedown - parser markdown
  • phpass - génération de hash sécurisés pour les mots de passe, en l'absence de blowfish

Happy end, quand même

Je note tout de même que cette expérience m'a tout de même apporté de bonnes surprises, comme monolog, sentry ou climate que j'intégrerai peut être à mon framework, malgré l'utilisation "nécessaire" de composer et leur usage abusif des namespaces…

Ou bien je coderai mes propres libs, les distribuerai sous licence Libre, hors composer, en mentionnant que j'ai une approche plus conservatrice du dév…

  • # Mieux avant, vraiment?

    Posté par . Évalué à 10.

    Je suis toujours un peu dubitatif face aux gens qui regrettent le "bon vieux temps". Des frameworks lourdingues et mal conçus, ça ne date pas d'hier (bonjour PHP-Nuke!), et des développeurs qui se fichent de la qualité de leur code également.

    Au contraire, le web en 2000-2001, c'était l'asile :

    • Pas de standards réels, que des standards de facto pour chaque navigateur, avec tous les hacks impossibles qui s'ensuivaient pour la compatibilité (je me remémore avec émotion les document.all/document.layers…)
    • Une mentalité "le web, c'est facile, pas besoin de se casser la tête", qui a mené entre autres à des horreurs sans nom comme les register_globals, et dont on paie encore le prix aujourd'hui (pour ne parler que du PHP).
    • Un enchevêtrement de scripts de provenances aussi diverses que douteuses, justement parce que des frameworks généralistes, ça n'existait pas.

    Où est le problème avec le fait que les gens utilisent des frameworks, si ça marche bien justement? Je connais assez mal le PHP, mais en javascript (jQuery et consort côté client, node.js côté serveur) et en Python (Django, Pyramid, etc.), je serais bien en peine de me passer de ces frameworks.

    Bien sûr il y a parfois de l'exagération, des usines à gaz utilisées pour le livre d'or de l'association de bowling cosmique des trombonistes unijambistes de Provence, mais de manière générale, ces frameworks ont au contraire apporté une bien meilleure qualité de code que ce que pourraient faire bien des développeurs (et en bien plus de temps).

    Bon, après, je ne connais pas particulièrement composer—et je n'aime pas particulièrement PHP—mais je persiste à trouver l'amalgame "des gens codent mal" -> "c'était mieux avant" un peu bancal…

    • [^] # Re: Mieux avant, vraiment?

      Posté par . Évalué à 6.

      Où est le problème avec le fait que les gens utilisent des frameworks, si ça marche bien justement? Je connais assez mal le PHP, mais en javascript (jQuery et consort côté client, node.js côté serveur) et en Python (Django, Pyramid, etc.), je serais bien en peine de me passer de ces frameworks.

      A mon avis, le problème n'est pas d'utiliser les frameworks, mais d'utiliser un framework lorsque ce n'est pas adapté, ou de ne pas utiliser le bon framework pour le bon usage. Personnellement je constate que beaucoup de projets utilisent des frameworks "usine à gaz" parce que les devs ne connaissent pas autre chose, alors que le framework n'est pas vraimentr nécessaire (ou alors un outil plus light suffirait).

    • [^] # Re: Mieux avant, vraiment?

      Posté par . Évalué à 10.

      le livre d'or de l'association de bowling cosmique des trombonistes unijambistes de Provence

      Où est le lien je veux voir ça :-D

      kentoc'h mervel eget bezan saotred

    • [^] # Re: Mieux avant, vraiment?

      Posté par . Évalué à 3.

      Ah PHPNUKE qui m'a permis d'apprendre le PHP et découvrir la GPL même si Francisco Burzi semblait programmer avec ses pieds et était laxiste avec la GPL en oubliant Thatware qui l'avait largement inspiré.

      Content de voir que certains se souviennent encore de ce fabuleux (à l'époque) CMS.

      Moi qu'en suis resté là niveau PHP, mes premier pas avec Magento et Symfony ont été douloureux.

  • # d'autres priorités?

    Posté par (page perso) . Évalué à 10. Dernière modification le 15/01/15 à 08:26.

    Là encore, j'ai envie de tomber dans la facilité: comment avoir confiance dans une librairie dont l'auteur ne prend pas la peine de faire un site sans tomber dans le piège oisif de bootstrap, ou du moins, faire en sorte que ça ne se voit pas ?

    Parce que le sujet est sa lib, pas un site web "différent", et qu'il préfère passer du temps sur sa lib que sur un site web "différent"?

    D'ailleurs, j'aime beaucoup la raison avouée pour laquelle l'auteur de Redbean ne propose pas de package composer. Bon, il met le lien, c'est djéà ça.

    Pas compris : l'auteur upstream refuse de mettre un fichier en plus dans son archive par conservatisme? (je vois qu'un fichier JSON sur le patch composer).

    C'était mieux avant.

    • [^] # Re: d'autres priorités?

      Posté par . Évalué à 4.

      Parce que le sujet est sa lib, pas un site web "différent", et qu'il préfère passer du temps sur sa lib que sur un site web "différent"?

      :) tu parle en connaissance de cause (tu as eu beaucoup de critique sur ton site si je ne me trompe pas ?)

      Mais je suis d'accord surtout qu'un peu avant il dit :

      Bon, ben encore une application moderne qui mise sur l'apparence et qui en fait est tout bugguée…

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: d'autres priorités?

        Posté par (page perso) . Évalué à 3.

        :) tu parle en connaissance de cause (tu as eu beaucoup de critique sur ton site si je ne me trompe pas ?)

        Il y a eu une belle refonte ces derniers mois j’ai l'impression, la navigation me paraît agréable pour moi maintenant ce qui est sympa (contrairement à l'ancienne version).

        • [^] # Re: d'autres priorités?

          Posté par . Évalué à 3.

          D'où l'utilisation du passé composé ^^

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # mocheté

    Posté par . Évalué à 8.

    Tu parles de « mocheté », est-ce l'aspect esthétique des sites web, ou le côté technique ?

    Parce que niveau esthétique on a quand même fait un bond en avant depuis ça :

    http://jvachez.free.fr/

    • [^] # Re: mocheté

      Posté par (page perso) . Évalué à -4.

      Ce que je critique c'est que le web est inondé de sites dont le front-end repose sur bootstrap peu ou prou modifié, et qu'il y en a marre de voir des clones de bootstrap partout.

      Je ne dis pas qu'il faut faire un site ultra beau et abouti pour présenter une librairie (justement, je dis bien que le site de Smarty est vétuste et celui de Redbean est simple et sobre). Je dis que quand on est un dev web et qu'on fait du Libre, on pourrait se creuser un peu la soupière pour faire quelque chose qui ne repose pas sur Bootstrap.

      Utiliser Foundation par exemple, ça changerait un peu…

      • [^] # Re: mocheté

        Posté par (page perso) . Évalué à 10.

        Ne pas utiliser un outil parce que les autres utilisent, quel argument pertinent.
        Sinon : programmeur web != designer web.

      • [^] # Re: mocheté

        Posté par . Évalué à 9.

        Je suis développeur, pas graphiste. Les sites beaux je sais pas faire ça tout seul. Donc si je code une lib et qu'elle a besoin d'un site, ça risque fort d'être du bootstrap. Parce que je ne veux pas faire

        encore une application moderne qui mise sur l'apparence et qui en fait est tout bugguée

        comme tu le dis si bien à propos de PHP-Error.

        Enfin bref tu te contredis et mélanges un peu tout (les traits c'est alambiqué, bootstrap c'est mal, composer c'est le diable) juste pour nous dire que tu n'as pas envie d'évoluer et d'apprendre de nouvelles technos.

        Je te rejoins néanmoins sur une chose : je n'aime pas les gros framework qui font tout même le café à la symfonie donc ouais je fais comme toi, j'assemble des libs intéressantes. Et pour ça composer est bien pratique.

        • [^] # Re: mocheté

          Posté par (page perso) . Évalué à 1.

          Je suis développeur, pas graphiste. Les sites beaux je sais pas faire ça tout seul.

          Et tu ne lis pas les posts en entier :)

          Enfin bref tu te contredis

          Pardon, je ne vois pas où je me contredis…

          et mélanges un peu tout

          Oui, je parle du code moderne, donc ça englobe un certain nombre de choses…

          juste pour nous dire que tu n'as pas envie d'évoluer et d'apprendre de nouvelles technos

          J'utilise bootstrap dans mes projets persos non diffusés, j'utilise CakePHP dans les devs pro, j'utilise foundation dans certains projets, ink (du même auteur) pour les mails HTML. Qui a dit que je ne voulais pas évoluer ou apprendre de nouvelles technos ?

          Je ne suis simplement pas prêt à accepter la modernité juste pour dire que j'utilise quelque chose de moderne.

          Par ailleurs, quand ces outils modernes fonctionnent, je les utilise avec plaisir. Par contre, je ne suis pas d'accord avec l'obligation d'utiliser un outil moderne pour utiliser des librairies bancales.

          • [^] # Re: mocheté

            Posté par . Évalué à 3. Dernière modification le 15/01/15 à 13:35.

            "encore une application moderne qui mise sur l'apparence" et "comment avoir confiance dans une librairie dont l'auteur ne prend pas la peine de faire un site sans tomber dans le piège oisif de bootstrap" c'est contradictoire.

            Par ailleurs, quand ces outils modernes fonctionnent, je les utilise avec plaisir.

            Alors fais toi plaisir : les traits, les namespaces, Composer, ne sont pas bancals ou alors je veux bien que tu m'expliques en quoi.

            EDIT : je connais la rengaine "ouais vous les utilisez juste parce que c'est à la mode". Ou alors ça a facilité la vie de beaucoup et de fait c'est devenu "à la mode". Parce que ça marche. Parce que c'est pratique. Tout à fait comme le PHP il y a 10 ans d'ailleurs.

            • [^] # Re: mocheté

              Posté par (page perso) . Évalué à 1.

              "encore une application moderne qui mise sur l'apparence" et "comment avoir confiance dans une librairie dont l'auteur ne prend pas la peine de faire un site sans tomber dans le piège oisif de bootstrap" c'est contradictoire.

              Vraiment, j'essaye de comprendre, mais je ne vois toujours pas en quoi c'est contradictoire.

              Alors fais toi plaisir : les traits, les namespaces, Composer, ne sont pas bancals ou alors je veux bien que tu m'expliques en quoi.

              Les traits sont un paliatif au fait que PHP ne supporte pas l'héritage multiple. Je trouve leur syntaxe confuse:

              class MaClass {
                  use MyTrait1, MyTrait2;
                  [...]
              

              Premièrement, jusqu'à présent, le mot-clé use n'était utilisé que pour importer une variable dans une closure. Là on a le sentiment d'importer une classe dans une autre, ce qui n'est pas exact. Je pense qu'il aurait été plus harmonieux de faire quelque chose du genre:

              class MaClass extends MyTrait1, MyTrait2 {
                  [...]
              

              Pour les namespaces, là aussi c'est la syntaxe qui me pose problème. L'antislash n'est pas un bon séparateur selon moi, le slash aurait été plus approprié, plus logique.

              Enfin pour composer, j'ai expliqué en quoi il est bancal dans un autre commentaire de ce topic.

              • [^] # Re: mocheté

                Posté par . Évalué à 4.

                je ne vois toujours pas en quoi c'est contradictoire.

                Dans le premier cas tu juges l'application sur le fait que le maximum soit mis sur l'apparence du site web, dans le deuxième cas tu juges l'application sur le fait que le maximum ne soit pas mis sur l'apparence du site web (piège oisif).

                Si c'est la syntaxe des traits et des namespaces qui te pose problème tu devrais vite changer de langage ! Parce que les incohérences de syntaxe dans PHP sont légions

                • [^] # Re: mocheté

                  Posté par (page perso) . Évalué à 1.

                  Dans le premier cas tu juges l'application sur le fait que le maximum soit mis sur l'apparence du site web, dans le deuxième cas tu juges l'application sur le fait que le maximum ne soit pas mis sur l'apparence du site web (piège oisif).

                  Non, ce que je voulais dire c'est qu'on peut faire un site vite fait bien fait sans bootstrap :)
                  Un normalizer pour la compatiblité, deux trois classes pour les liens ou les menus et voilà, pas besoin de pondre du less pour une page de présentation de la lib.

                  Si c'est la syntaxe des traits et des namespaces qui te pose problème tu devrais vite changer de langage ! Parce que les incohérences de syntaxe dans PHP sont légions

                  Oui, ça, je suis parfaitement d'accord. Les incohérences sont nombreuses et la dev team de PHP n'est pas encline à les corriger.

                  Je lorgne de plus en plus du côté de Python. Si je ne m'y suis pas encore mis, c'est parce que je veux concevoir des applications Libres que le débutant peut installer facilement. Je me disais qu'une appli PHP était plus simple à installer qu'une appli Python (en terme de paramétrage de serveur web notamment).

                  Mais vu que je passe beaucoup de temps à coder et que je n'ai pas publié grand chose, j'aurais peut être pu passer ce temps à étudier Python plutôt que m'énerver contre la "mauvaise" modernisation de PHP :)

                  • [^] # Re: mocheté

                    Posté par (page perso) . Évalué à 6.

                    Mais vu que je passe beaucoup de temps à coder et que je n'ai pas publié grand chose, j'aurais peut être pu passer ce temps à étudier Python plutôt que m'énerver contre la "mauvaise" modernisation de PHP :)

                    <Ironie> Ouuuuh là!! Attention, tu va être TRÈS décu. en effet, beaucoup de lib et d'applis s'installe avec PIP, qui est très similaire à Composer. Tu ne vas pas pouvoir faire totalement du dev à contre courant de ce que l'écosystème propose :-p </Ironie>

                • [^] # Re: mocheté

                  Posté par (page perso) . Évalué à 2.

                  Je précise quand même que certains points soulevés par PHPSadness sont franchement tirés par les cheveux:

                  • #30 - Quel développeur chaîne des opérateurs ternaires…
                  • #39 - Quel développeur choisi __lambda_funct comme nom de fonction…
                  • #28 - Je ne comprends pas le raisonnement de l'auteur, la doc de PHP est claire sur l'usage de empty()
                  • #43 - Vouloir remplir avec du vide, c'est conceptuel…
                  • #35 - Vouloir couper une chaîne vide est tout aussi conceptuel…

                  Je suis d'accord sur les inconsistances des noms de fonctions par exemple, mais le reste il faut avouer que c'est du bashing :)

                  • [^] # Re: mocheté

                    Posté par . Évalué à 2.

                    Tout à fait il y a clairement du bashing sur ce site. Et oui les incohérences sont bien présentes ce qui ne t'empêche pas d'utiliser les fonctions …

                  • [^] # Re: mocheté

                    Posté par . Évalué à 4.

                    Vouloir couper une chaîne vide est tout aussi conceptuel…

                    Ben, ça dépend, si tu dois couper une chaine en deux, et que avoir deux chaines vide en résultat n’est pas gênant. Je préfère couper la chaine en deux systématiquement. Ça simplifie le code (pas de branche multiple…) et il n’y a pas de perte de performance notable.

                    • [^] # Re: mocheté

                      Posté par (page perso) . Évalué à 3.

                      Ben, ça dépend, si tu dois couper une chaine en deux, et que avoir deux chaines vide en résultat n’est pas gênant. Je préfère couper la chaine en deux systématiquement. Ça simplifie le code (pas de branche multiple…) et il n’y a pas de perte de performance notable.

                      Mais dans ce cas, il faut aussi définir un comportement cohérent quand on coupe une chaîne ayant un caractère :)

              • [^] # Re: mocheté

                Posté par (page perso) . Évalué à 6.

                Les traits sont un paliatif au fait que PHP ne supporte pas l'héritage multiple. Je trouve leur syntaxe confuse:

                Non les traits n'est pas un paliatif. Ça n'a d'ailleurs rien à voir avec l'héritage multiple, et ça ne cherche pas à remplacer l'héritage multiple (qui pose lui même bien des problèmes dans d'autres langages).

                Et il n'y a pas que PHP qui supporte les traits, il y a d'autres langages comme le tout nouveau Rust.

                • [^] # Re: mocheté

                  Posté par (page perso) . Évalué à 2.

                  Traits are a mechanism for code reuse in single inheritance languages such as PHP

                  Source: http://php.net/manual/en/language.oop5.traits.php

                  L'objectif reste bien d'utiliser les méthodes d'une classe dans une autre, donc quelque part faire de l'héritage. Non ?

                  • [^] # Re: mocheté

                    Posté par . Évalué à 5.

                    Où il est écrit que l'héritage est une bonne manière de réutiliser du code ? Et surtout, la seule.

                    C'est pas parce que c'est la seule méthode que tu connaisse que c'est la bonne manière de faire, et encore moins que c'est un palliatif.

                  • [^] # Re: mocheté

                    Posté par . Évalué à 3.

                    Je dirais que la différence se situe dans ce que l'héritage est une liaison verticale, alors que le trait est totalement horizontale. Maintenant j'ai peu fait usage de ces deux mécanismes, alors je n'irais pas plus loin. Préférant me cantonner à marcher comme homme et aboyer comme un chien, selon les envies : )

              • [^] # Re: mocheté

                Posté par . Évalué à 7.

                Premièrement, jusqu'à présent, le mot-clé use n'était utilisé que pour importer une variable dans une closure. Là on a le sentiment d'importer une classe dans une autre, ce qui n'est pas exact. Je pense qu'il aurait été plus harmonieux de faire quelque chose du genre:

                Pour les namespaces, là aussi c'est la syntaxe qui me pose problème. L'antislash n'est pas un bon séparateur selon moi, le slash aurait été plus approprié, plus logique.

                Oh mon dieu de vrais problèmes de fond ! Je comprends ta révolte et ton désarroi.

                Note que je te soutiens aussi de manière sans limite sur le fait qu'étant un vrai opinniated developer avec du bon goût et du style, tu ne peux éviter de rendre ce monde meilleur en releasant de la vraie lib bien faite ! C'est clairement ce qu'il manque au monde du web qui n'avait pas vécu ça depuis au moins deux minutes :facepalm:

                • [^] # Re: mocheté

                  Posté par (page perso) . Évalué à -4.

                  Ok. Donc en fait, on exprime une opinion, et on reçoit des commentaires ironiques, désobligeants qui ne servent à rien, c'est donc comme ça que ça marche. Soit.

                  Ce n'étaient que des exemples des ajouts récents à PHP qui m'ont rendu sceptique. Ce n'est pas ces deux exemples le problème que je soulève dans mon post. Donc j'aurai tendance à dire que tu t'es contenté de venir pourrir les coms de ce journal sans même prendre la peine de le lire.

                  Au moins, ce post de Laurent J, en désaccord avec moi, prend la peine de me dire en quoi il estime que composer c'est bien, ce qui contribue positivement au débat. Toi, tu te contente de faire un :facepalm:.

                  J'attendais un autre niveau de la part des commentateurs en fait. J'aurai mieux fais de ne m'attendre à rien du tout.

                  • [^] # Re: mocheté

                    Posté par . Évalué à 10.

                    Ben disons que t'arrives avec tes gros sabots de c'etait mieux avant, en citant le pire language web qui ait jamais été pense, notoire pour être troue de partout, que ce soit niveau design ou niveau implementation, a l'eco système notoire pour être une veritable passoire, que ca soit niveau design ou implementation.
                    Langage/eco système qui commence finalement a sortir lentement de l'impasse, et donc le c'etait mieux a vent fait légèrement sourire quand meme.

                    Quand tu rajoutes par dessus que ce qui te plait pas c'est des \ plutôt que des / et un point mineur de syntaxe, comment dire? PHP a des problèmes, beaucoup de problèmes, mais les backslash n'en font pas partie.

                    Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                    • [^] # Re: mocheté

                      Posté par (page perso) . Évalué à -8.

                      Commentaire encore une fois très constructif, surtout de la part de quelqu'un dont la signature est:

                      Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                      Ceci explique cela.

                      Juste une question: j'ai insulté vos mères pour justifier un tel comportement de votre part ?

                      • [^] # Re: mocheté

                        Posté par (page perso) . Évalué à 5.

                        Non par contre il soulève un point intéressant. Déjà, parler de code moderne et de PHP nous laisse sourire.

                        Ensuite, parler des problèmes de syntaxes (qui ne sont que des problèmes de styles au passage, donc assez bien subjectifs) pour PHP montre une certaine ignorance des vrais problèmes de PHP qui sont de l'ordre de sa sémantique et surtout de son implémentation.

                        Il suffit de parler de PHP 6 pour se rendre compte que ce langage allait droit dans le mur et continue aujourd'hui à se dépatouyer de son héritage qui dénote particulièrement que: non, ce n'était pas mieux avant.

                        Au final ton article ressemble a un aigri qui veut continuer a faire du COBOL et se plaint qu'on puisse supplanter sa technologie (et ses habitudes) par quelque chose de nouveau (qui, avec un peu d'optimisme sur la communauté informatique, puisse nous convaincre qu'elle est objectivement mieux). Si tu reste dans cette position à dire non au code moderne (et il n'est pas moderne), tu risques de tomber dans des dogmes et finir comme le vieux tonton a chaque repas de Noël qui boit et qui se plaint - mais ton passif avec PHP n'en sera que meilleur pour en rigoler.

                      • [^] # Re: mocheté

                        Posté par (page perso) . Évalué à 3. Dernière modification le 16/01/15 à 07:55.

                        Juste une question: j'ai insulté vos mères pour justifier un tel comportement de votre part ?

                        On pourrait te retourner la question : la planète (j'avoue ne pas savoir qui exactement, tellement ça tire sur tout gratutement, donc planète) a insulté ta mère pour justifier un tel comportement de ta part ?
                        (note : jamais j'aurai eu l'idée de parler des mamans des gens, mais bon je ne fais que recopier, je m'excuse pour les gens qui trouvent ça nul : je suis d'accord, attaquer en mettant les mamans dans l'histoire est le -273ème degré d'une discussion constructive, et je sais bien que généralement c'est quand une personne n'a pas confiance en elle et veut provoquer)

                        Parce que bon, le premier à sortir des énormités, celles qui font réagir les gens, c'est toi, tu provoques les gens avec des trucs absolument pas sérieux, qui ressemblent à la blague du bar du coin, pas du tout constructif, puis tu t'étonnes qu'ils répondent, pas forcémént sérieusement, pas constructif?

                        Hum… Je propose que tu commences à être constructif avant de critiquer les autres à ce sujet.

                        • [^] # Re: mocheté

                          Posté par . Évalué à -1.

                          /hs/ hmm on dirait que la propagande actuelle à déteint sur ta personne, nous savions déjà tous, je le crois, qu'il est mauvais, dérangeant, déplacé, de parler des mamans des gens. M'enfin, je ne sais pas si j'irais jusqu'à dire comme l'auteur du journal que cétait mieux avant HAHAHA /hs/

                          • [^] # Re: mocheté

                            Posté par . Évalué à 4.

                            Je pense que la plupart des mamans, passé un certain âge, te diront que c'était mieux avant ;)

                    • [^] # Re: mocheté

                      Posté par . Évalué à 3.

                      TOut frais d'il y a 4 jours :

                      Le bon outil pour le bon usage

      • [^] # Re: mocheté

        Posté par (page perso) . Évalué à 2.

        Utiliser Foundation par exemple, ça changerait un peu…

        Et contribuerait à la diversité chère aux libristes :)

  • # à propos de Composer et autres

    Posté par (page perso) . Évalué à 10.

    De façon assez étrange, ni Smarty, ni Redbean ne mentionnent composer dans leur documentation, et PHPMailer s'en passe parfaitement.

    Parce que peut-être les développeurs de ces libs ne s'y sont pas vraiment intéressé ou ne veulent pas, ou sont réfractaires à certains changement ? D'ailleurs Redbean le dit bien : le gars est "conservateur".

    Cela ne veut pas dire que Composer c'est de la merde.

    Et tu noteras que tu cites quand même des projets vraiment vieux (voir à peine maintenu comme PHPMailer). Lourd passif donc.

    M'enfin bon, même si des libs comme celle-là ne sont pas fournie en paquet Composer, c'est juste 3 lignes de code supplémentaires à rajouter dans ton composer.json pour les intégrer dans ton projet. Pas la mort quoi.

    comment avoir confiance dans une librairie dont l'auteur ne prend pas la peine de faire un site sans tomber dans le piège oisif de bootstrap

    J'ai l'impression que tu ne maintiens pas de projet public pour dire ça, ou alors tu es super compétent en design web et c'est super facile pour toi de pondre un design html/css.

    J'ai plusieurs projets open source en PHP que je développe et maintien depuis des années. J'ai beau être compétent techniquement en HTML et CSS, je peux te dire une chose : ça me fais chier grave de faire les sites web de mes projets. Parce que je suis incompétent en design web et du coup, quand il faut que je refasse l'un deux, j'y passe des jours pour que ça ressemble à quelque chose. Ce temps, je préfère le passer à développer la lib. Donc je comprend très bien ceux qui choisissent bootstrap ou autre trucs "pour se faciliter la vie".

    ni Smarty n'utilisent bootstrap sur leur site.

    Ça c'est normal : le site de Smarty n'a pas bougé depuis 10 ans. Idem pour PHPMailer. Ils sont probablement comme moi : ils préfèrent passer du temps sur leur lib que sur le design de leur site.

    Maintenant, utiliser bootstrap, ça a ses avantages : c'est responsive nativement, ça offre d’amblé un design "moderne" etc…

    je ne comprends pas comment il est possible que de telles librairies ou outils puissent avoir une telle cote de popularité.

    parce que j'ai l'impression que tu n'as pas trop en tête les avantages qu'ils offrent…

    Aujourd'hui, tout le monde boude PEAR,

    Je te rassures, même avant tout le monde boudait Pear. Quelle a été la proportion de lib et de projets qui proposait un paquet Pear ? 0,5% ? 1%? Franchement on n'y trouvait pas grand chose.

    Et maintenant avec Composer ? 70%, 80%, 90% ? Le nombre de projets dispo via Composer est sans commune mesure avec Pear.

    Et si Composer a un tel succès, c'est bien parce qu'il offre quelque chose de mieux non ?

    Perso je n'ai jamais aimé Pear.

    Déjà, c'est un truc hyper fermé : il faut que ton projet respecte certaines règles, notamment le coding style (que je trouve horrible). Ensuite, il faut qu'il soit accepté par les gens qui gère Pear. Tu ne peux pas avoir de doublons en terme de fonctionnalité avec une autre lib. Au final, Pear ne propose pas grand chose. Ou alors des usines à gaz. Interroge toi par exemple pourquoi tu as choisi PHPMailer plutôt que leur lib de mail.

    Ensuite, sur le serveur (en particulier avec Debian), ton depôt PEAR est forcément partagé par tous tes projets. Au final, tu te retrouve coincé : tu ne peux pas mettre à jour au risque de casser tes vieux projets, et donc tu ne peux pas profiter des dernières versions pour des nouveaux projets. Et même si tu veux mettre à jour, c'est la galère avec debian, on ne sait jamais ce qu'il faut faire vraiment (y a toujours eu des trucs qui cassaient chez moi). Ne serait-ce que pour mettre à jour PHPUnit avec Pear. ça a toujours été la galère (à cause principalement qu'il faille faire ça en sudo, qu'il faille modifier le include_path dans la conf PHP etc).

    Alors qu'avec Composer, tu as un dépôt par projet, chaque projet évolue comme il veut, utilise les paquets qu'il veut. PHPUnit et les autres paquetes s'installent en deux coup de cuillère à pot. Pas besoin de droits spéciaux sur le système pour les installer. Peu importe au final le système : ton projet reste indépendant.

    M'enfin comme tu l'as dit toi même Pear c'est plus un Framework qu'un gestionnaire de dépendance. Donc au final, peu de rapport avec Composer.

    Les gros avantages de Composer, c'est qu'il fait un seul truc et le fait bien : installer des paquets et gérer les dépendances. Un apt pour PHP.

    L'autre gros avantage de Composer : il génère un autoloader. Adieu tous les includes dans tout les sens pour charger une lib ! Et si en plus les lib utilisent les namespaces (en respectant PSR-0 ou PSR-4), l'autoloader est beaucoup plus efficace.

    À l'usage on se rend compte que ça apporte plus de souplesse, moins de tracas, et plus de perf (pas de chargement de classes non utilisées).

    Le pire, c'est que toutes ces libs modernes suivent les recommandations PSR, donc devraient être facilement utilisables partout quelle que soit la configuration du serveur sur lequel elles sont installées.

    Ah non pas du tout ! Les PSR ne servent pas à faire en sorte que ça fonctionne quelle que soit la conf serveur. Je ne sais pas où tu as lu ça. Pour le moment, ils ont des recommandations pour le nommage des classes (PSR-0 et PSR-4), afin de faciliter le développement des autoloaders (que l'on n'a plus à développer si on utilise Composer), des recommandations sur le coding style (PSR-1 et PSR-2), et une recommandation sur l'interface d'un objet qui fait du log. Et ce qui est en discussion actuellement ce sont d'autres interfaces pour d'autres types d'objets courant (gestionnaire de cache, lib http…).
    (donc non, ça ne servira pas qu'à Composer).

    Bref, ce sont des choses pour améliorer l'interopérabilité entre les frameworks. Rien à voir avec la conf des serveurs.
    Et puis ce ne sont que des recommandations. Pas obligé de les suivre.

    composer qui a, par ailleurs, la fâcheuse tendance à installer tout un tas de truc que je n'ai jamais demandé et qui n'existe pas dans les archives

    Composer installe ce que les paquets ont besoin, pas plus, pas moins. Si un paquet a une dépendance envers un autre paquet et qu'il n'utilise pas, la faute est au développeur, pas à Composer. Mauvais paquet, changer paquet. (ça tombe bien, contrairement à Pear, le choix est très vaste).

    phpass - génération de hash sécurisés pour les mots de passe, en l'absence de blowfish

    Avec la nouvelle api password de PHP, cette lib est devenu inutile et obsolète (voir dangereuse, vu qu'elle n'est plus maintenue ?).

    leur usage abusif des namespaces

    Les namespaces, c'est bon, mangez-en : ça évite les collisions de classes entre libs, ça facilite l'autoloading, ça permet une programmation moderne, ça force (un peu) à mieux organiser son code.

    Je suis en train de "namespacer" mon framework, ça fait beaucoup de bien au final.

    Pour finir, Composer, on peut s'en passer, mais c'est devenu la norme maintenant pour distribuer et installer des libs en PHP. L'ignorer ou le dénigrer n'aidera pas dans tes projets présent et futurs.

    • [^] # Re: à propos de Composer et autres

      Posté par (page perso) . Évalué à 2.

      M'enfin bon, même si des libs comme celle-là ne sont pas fournie en paquet Composer, c'est juste 3 lignes de code supplémentaires à rajouter dans ton composer.json pour les intégrer dans ton projet. Pas la mort quoi.

      Moi, ce que je vois avec composer, c'est que quand tu code une appli libre, tu cherche à simplifier au maximum l'installation.

      Je suis désolé mais non, pour un débutant qui veut utiliser son application, ce n'est pas plus simple de faire:

      curl -sS https://getcomposer.org/installer | php
      composer.phar install
      

      que d'extraire une archive. D'autant que composer semble ne pas fonctionner partout de la même façon: sous Mac OSX, l'installation de CakePHP se fait exactement comme dans la doc officielle. Sous Debian, l'arborescence de vendor n'est pas la même et il devient impossible de charger le bootstrap de CakePHP sans modifier une variable pour mette le chemin en dur parce que sous Debian, il chope le repo git au lieu du repo PEAR (ou l'inverse, je ne sais plus).

      composer est bien pour gérer les dépendances d'un projet pro, statique, où personne ne va mettre son nez dedans, mais pour un projet Libre, je pense que ce n'est pas une bonne solution.

      J'ai l'impression que tu ne maintiens pas de projet public pour dire ça, ou alors tu es super compétent en design web et c'est super facile pour toi de pondre un design html/css.

      Je suis loin d'être compétent en web design. Mais bootstrap, comme tout framework qu'il soit front ou back end, est fait pour industrialiser. Quand on code une appli libre, on n'industrialise pas. On industrialise quand on se fait plein de petits projets pour soi-même. Moi aussi j'utilise bootstrap quotidiennement pour mes projets perso (genre gestion DNS, gestion d'Apache, PKI, etc.), mais pour des applications Libres, je n'utilise que normalizer (sur lequel repose bootstrap). Pour les projets pros, pareil.

      Maintenant, utiliser bootstrap, ça a ses avantages : c'est responsive nativement, ça offre d’amblé un design "moderne" etc…

      Je me suis peut être mal exprimé: je ne dis pas que bootstrap c'est de la merde, je dis qu'il faut arrêter d'en mettre partout. Je reste d'accord avec ce que tu dis.

      Je te rassures, même avant tout le monde boudait Pear

      Pas faux, le problème d'être élitiste :)

      ton depôt PEAR est forcément partagé par tous tes projets

      C'est un détail, mais non. Tu peux parfaitement utiliser PEAR pour un unique projet (c'est ce que fait Roundcube par exemple, qui n'a jamais nécessité d'installer PEAR alors qu'il en utilise des libs)

      Pareil Horde permet d'être installé avec sa propre instance de PEAR (leur site est + ou - down là sinon j'aurai mis un lien).

      À l'usage on se rend compte que ça apporte plus de souplesse, moins de tracas, et plus de perf (pas de chargement de classes non utilisées)

      Oui, je suis d'accord, mais ça serait mieux sans les pseudo-dépendances qui n'existent pas dans les archives !

      Ou alors, les paquets composer sont structurés différemment des archives, ce qui forcerait les dev à maintenir deux paquets différents ?

      Ah non pas du tout ! Les PSR ne servent pas à faire en sorte que ça fonctionne quelle que soit la conf serveur.

      Oui pardon je me suis enflammé ^

      Ceci dit ils parlent d'interopérabilité, j'ai pensé que ça avait un sens un poil plus large…

      Pour finir, Composer, on peut s'en passer, mais c'est devenu la norme maintenant pour distribuer et installer des libs en PHP. L'ignorer ou le dénigrer n'aidera pas dans tes projets présent et futurs.

      C'est bien là que le bât blesse: quelque chose qui n'a rien à voir avec PHP devient la norme pour développer avec PHP.

      Si le gestionnaire de dépendance était partie intégrante de PHP, les choses seraient différentes, mais là c'est un projet lambda. Et forcer à son utilisation est contraire à la philosophie du Libre.

      • [^] # Re: à propos de Composer et autres

        Posté par . Évalué à 5.

        La philosophie du Libre, si tant est qu'elle existe, c'est les 4 libertés, rien d'autre.

        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

        • [^] # Re: à propos de Composer et autres

          Posté par (page perso) . Évalué à -3.

          « Logiciel libre » [free software] désigne des logiciels qui respectent la liberté des utilisateurs

          Je sais, c'est de l'interprétation, mais pour moi ça implique que si une lib m'impose d'utiliser composer, ça restreint ma liberté.

          PHPUnit permet les deux types d'installation (comme d'autres). Ça, c'est la bonne façon de faire, respectueuse de la liberté des devs.

          Tu me diras, je suis libre de ne pas utiliser les libs qui me forcent à utiliser composer, je suis libre de les modifier pour les adapter à mon besoin, et ça, elles ne m'empêchent pas de le faire. Du coup on tourne en rond et la discussion devient stérile :)

          • [^] # Re: à propos de Composer et autres

            Posté par (page perso) . Évalué à 3. Dernière modification le 15/01/15 à 14:19.

            Je sais, c'est de l'interprétation, mais pour moi ça implique que si une lib m'impose d'utiliser composer, ça restreint ma liberté.

            C'est vraiment du foutage de gueule.
            Allez, Linux ne compile qu'avec GCC, ça restreint ma liberté de choisir mon compilo, Linux est contre le philosophie du libre. Ou pas.
            tu peux toujours inventer un truc à ce niveau.

            je suis libre de les modifier pour les adapter à mon besoin,

            Oui. Du coup tu dis toi-même que tes idées sur le libre sont fausses. J'avoue ne pas comprendre à quoi tu veux en venir.

            Libre != obligation à l'auteur de faire comme toi tu veux. Fournir un logiciel qui demande composer est 100% dans le respect de la liberté des utilisateurs (et personne ne te force, juste qu'on n'a pas codé pour ton désir), tu n'as aucune restriction.

            Du coup on tourne en rond et la discussion devient stérile :)

            Ben disons que quand l'auteur d'un post dit que ce post est n'importe quoi sans arrêter de penser que son post est correct, on a du mal à suivre. C'est quoi le but de cette mascarade?

            • [^] # Re: à propos de Composer et autres

              Posté par (page perso) . Évalué à -2.

              Allez, Linux ne compile qu'avec GCC, ça restreint ma liberté de choisir mon compilo, Linux est contre le philosophie du libre. Ou pas. tu peux toujours inventer un truc à ce niveau.

              Là tu extrapole.

              Déjà parce que Linux dépend de certaines extensions de GCC. Une lib qui veut s'installer via composer ne dépend pas de librairies de ce dernier (qui n'en a pas) pour fonctionner, elle fonctionne en toute autonomie.

              Ensuite, comparer quelque chose d'aussi critique que le noyau Linux et une librairie PHP qui fait du routage pour une app web, c'est osé…

              Oui. Du coup tu dis toi-même que tes idées sur le libre sont fausses. J'avoue ne pas comprendre à quoi tu veux en venir.

              Je ne dis pas que mes idées sont fausses, je dis qu'il n'y a pas de raison d'obliger un dev à passer par composer pour installer sa lib. Comme je l'ai dis plus tôt, PHPUnit propose les deux méthodes d'installation, c'est donc qu'il est possible de laisser le choix aux développeurs de leur méthode d'installation. Et bien que nous ayons la possibilité de modifier ces outils à notre convenance, tout l'intérêt d'utiliser une lib est de se simplifier la vie, et réduire le temps passé à l'adaptation de l'existant. C'est encore plus embêtant quand on suit des recommandations d'interopérabilité.

              Ben disons que quand l'auteur d'un post dit que ce post est n'importe quoi sans arrêter de penser que son post est correct, on a du mal à suivre. C'est quoi le but de cette mascarade?

              1. Je ne dis ni que mon post est n'importe quoi, ni qu'il est correct. C'est mon journal, j'y écris mon ressenti. Peut être que je m'y exprime mal, mais d'autres dans les commentaires ont compris ma démarche.

              2. Si tu n'as pas compris le but de mon journal, je t'invite à le relire. Je me suis peut être mal exprimé dans mes commentaires, mais il me semble avoir été plus que clair en disant que je n'aime pas le code moderne :)

              3. Toujours dans un soucis de clarification, ce que tu appelle "masquarade", j'appelle ça "un coup de gueule passé contre les librairies qui forcent les devs à utiliser des outils dont ils ne veulent pas sans pouvoir justifier d'une liaison si forte entre la librairie et l'outil que le premier ne peut être installé sans le second". Sur ce point aussi, il me semble avoir été clair tout au long des commentaires.

              • [^] # Re: à propos de Composer et autres

                Posté par (page perso) . Évalué à 4. Dernière modification le 15/01/15 à 15:16.

                qui forcent

                Personne ne force.

                Quitte à me répéter, le libre n'est pas faire ce que toi veut. Le libre n'est pas l'obligation de coder. Le libre c'est fournir du code avec des libertés (les 4 libertés).
                Tu extrapoles pas mal le libre.

                Que tu n'aimes pas certains liens pour une raison x, c'est ton choix et admettons (même si l'exemple que tu as donné est, de ce que j'ai compris, plutôt un refus d'accepter un patch tout bête pour proposer une autre façon de faire le package, sans rien enlever, plus que du conservatisme), mais n'associe pas le libre à ton choix et à tes idées de comment doit être un projet, le libre n'a rien à voir la dedans, ni de près ni de loin.

                • [^] # Re: à propos de Composer et autres

                  Posté par . Évalué à 5.

                  qui forcent

                  Personne ne force.

                  Tu trouve intéressant de te répéter à longueur d'année ?
                  Quand les gens affirment que tel ou tel trucs les forces, c'est qu'ils utilisent une expression très classique en français. Ici, par exemple, à la place de:

                  les librairies qui forcent les devs

                  Il fallait comprendre :

                  les librairies qui forcent leur utilisateurs

                  Ça ne change rien au reste de ton commentaire, mais éviter les hommes de paille, ça irrite beaucoup moins tes interlocuteurs et ça participe à un débat un peu plus intéressant (mais bon c'est peut être pas ce que tu recherche).

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                  • [^] # Re: à propos de Composer et autres

                    Posté par . Évalué à 2.

                    Là c'est toi qui pinaille, personne ne force personne, point. Ce n'est pas un "débat intéressant", c'est simplement n'importe quoi. Si une lib à une dépendance, et que ça ne te plaît pas, tu en choisis une autre ou tu en écris une, point. Voilà ce qu'il faut ramener au libre et certainement pas une crypto-cabale des développeurs.

                    En plus il faut vraiment être de mauvaise fois pour critiquer Composer : c'est hyper pratique et ce n'est pas une "dépendance" au sens où c'est un simple fichier qui peut être supprimé après la mise en place. Ca pourrait être drôle de comparer les temps de mise en place d'un boilerplate de 10 libs à jour avec et sans Composer. En plus c'est évidemment parfaitement intégré à l'environnement Linux donc bon.

                    Pour continuer sur les propos incohérents de l'auteur du journal, on a :

                    Mais bootstrap, comme tout framework qu'il soit front ou back end, est fait pour industrialiser. Quand on code une appli libre, on n'industrialise pas.

                    Non, c'est fait pour gagner du temps et diminuer les erreurs, comme tout framework. Je préfère qu'un dev fasse son site en Bootstrap si ça peut lui donner plus de temps pour améliorer sa lib. D'ailleurs une simple recherche "Boostrap theme" croule sous les résultats, donc en rajoutant une couche à la surcouche on arrive à un résultat pertinent et indétectable qui berne tout le monde, ce qui tend à démontrer la faiblesse de l'argumentation de l'auteur du journal.

                    Je passe sur la deuxième phrase qui montre le réel degré de liberté qu'il accorde au "libre".

                    • [^] # Re: à propos de Composer et autres

                      Posté par . Évalué à 3.

                      Là c'est toi qui pinaille, personne ne force personne, point.

                      Pour utiliser c'te lib, tu es obligé d'utiliser composer.
                      Cette lib te contraint d'utiliser composer.
                      Tu ne peux utiliser cette lib sans composer.

                      Voila si le mot "force" te gêne choisi celui que tu veux.

                      Ce n'est pas un "débat intéressant", c'est simplement n'importe quoi.

                      Tu y réponds pourtant. Ce que l'auteur veux faire ressortir c'est qu'il trouve qu'une dépendance ne lui convient pas. Il a le droit d'exprimer son avis et de l'expliquer et si cet avis et si idiot, tu peut le lui expliquer comme tu le fait dans le reste de ton commentaire, mais dire "si ça ne te plaît pas ta gueule et va voir ailleurs" ça n'a pas d'intérêt autre que de l'énerver.

                      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                      • [^] # Re: à propos de Composer et autres

                        Posté par (page perso) . Évalué à 2.

                        Pour utiliser c'te lib, tu es obligé d'utiliser composer.

                        C'est rigolo, d'habitude quand on parle de logiciel GPL qui force la licence sur du code tiers, ici ça réagit "mais non ça ne te force pas, tu es libre".

                        Donc on est bien d'accord : Barret Michel dit que la GPL est virale, elle force, et défendra les gens qui le disent.
                        Et encore, c'est pas un bon exemple, car c'est pire mon exemple : Linux est bien plus horrible, parce que bon, on ne peut pas prendre Linux, virer la dépendance à la GPL, et rediffuser, alors que la, on prend la lib, on la modifie, et hop on peut la rediffuser tout ça (on peut même proposer à l'upstream un patch pour ne pas avoir la dépendance).

                        bref, pour résumer : réaction très très sélective.

                        Rappel : l'exemple de conservatisme fourni dans le journal est le refus d'un bete fichier à inclure dans la distribution du logiciel. Qui force?

                        • [^] # Re: à propos de Composer et autres

                          Posté par . Évalué à 3.

                          Donc on est bien d'accord : Barret Michel dit que la GPL est virale, elle force, et défendra les gens qui le disent.
                          Et encore, c'est pas un bon exemple, car c'est pire mon exemple : Linux est bien plus horrible, parce que bon, on ne peut pas prendre Linux, virer la dépendance à la GPL, et rediffuser, alors que la, on prend la lib, on la modifie, et hop on peut la rediffuser tout ça (on peut même proposer à l'upstream un patch pour ne pas avoir la dépendance).

                          Oui tout à fait. Mais t'en a pas marre de ressasser toujours les mêmes choses ? De la même manière que pour le « non ça ne force pas », tu finis par prendre à parti en imaginant ce que j'ai pu dire ailleurs.

                          C'est une évidence que la GPL contraint et que le code sous GPL (mais plus généralement sous copyleft) contraint, ça n'est un secret pour personne. C'est pour ça que des gens ont créé des licences sans copyleft, c'est le genre de trucs qui font que zfs ne peux pas être intégré à linux.

                          Si tu veux aller dans les choses aussi puériles, je peux changer ma signature rien que pour toi, mais bon je me sens un peu con tellement c'est plat.

                          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                      • [^] # Re: à propos de Composer et autres

                        Posté par (page perso) . Évalué à 8.

                        J'ai la nette impression (mais je peux me tromper) que les personnes qui commente l'utilisation de composer de l'ont jamais utilisé. Je ne comprends pas le terme force à utiliser composer. composer n'est qu'un outil permettant d'installer une bibliothèque (library) dans la bonne version. Il est tout à fait possible d'installer la même bibliothèque à la main.

                      • [^] # Re: à propos de Composer et autres

                        Posté par . Évalué à 7.

                        Dire qu'on est obligé d'utiliser composer pour utiliser une lib, c'est comme dire qu'on est obligé d'utiliser un gestionnaire de paquet pour installer un logiciel. C'est simplement faux.

                        C'est juste que lorsqu'il y a un paquet compatible, c'est 50x plus plaisant de faire un simple apt-get install le_paquet_ plutot que d'aller chercher les 50 libs necessaire, les installer à la main pour ensuite pouvoir lancer l'application.

                        Composer offre en plus l'avantage de faire des installations locales, ce qui fait qu'on peut utiliser simplement plein de versions du même truc pour des sites différents.

                        Et ça reste vachement plus glamour d'avoir des messages d'erreur explicite (genre il faut avoir telle extensions de php installé pour pouvoir utiliser tel lib) aprés un composer install plutot qu'une fatal assez obscure à l'execution.

                        Certains logiciels n'utilisent pas composer (ni de tests), quel est le résultat ? On se retrouvent au bout de six mois, avec des bugs dans des librairies tierces, qui sont corrigées depuis belle lurette, mais comme on n'est pas allé voir sur les différents site où en etait les differentes librairies, ben on se retrouve à patcher dans l'urgence.

                        Alors certes, avec composer, il faut quand meme faire un update pour voir s'il y a eu des modifications. Ca reste vachement plus leger que d'aller vérifier toutes les dépendances une à une.

                        Mais dans tous les cas, composer est toujours dispensable. C'est un peu comme les dockerfiles. C'est pas parce qu'il y a un dockerfile dans le projet qu'on est obligé de l'utiliser. C'est juste une commodité fournie.

                        • [^] # Re: à propos de Composer et autres

                          Posté par . Évalué à 1.

                          Dire qu'on est obligé d'utiliser composer pour utiliser une lib, c'est comme dire qu'on est obligé d'utiliser un gestionnaire de paquet pour installer un logiciel. C'est simplement faux.

                          Comprenons-nous bien. J'en sais rien et je m'en fou. Je ne connais pas composer, je ne fais pas de PHP et je ne compte pas en faire durant la prochaine décennie.

                          Ce à quoi je répondais c'est au shemas :

                          machin m'oblige à utiliser composer

                          Ben non, gros con, si tu veux pas utiliser composer t'a qu'à pas utiliser machin

                          Réponse qui démontre aussi une totale incompréhension de ce qu'est composer.

                          Justement ce que je dis c'est qu'au lieu de répondre une réponse toute faite, qu'on revoit aussi pour systemd et pour pleins d'autres sujets. Il est largement plus intéressant d'expliquer, comme vous le faites pour me répondre, que ce n'est pas une obligation.

                          Bref ma participation était plus liée à du méta-débat qu'au débat en lui même (je ne me suis jamais prononcé sur l'intérêt ou non des lib en question ou de composer).

                          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: à propos de Composer et autres

            Posté par . Évalué à 6.

            Qu'est-ce que ça veut dire "me forcent à utiliser composer" ? Là vraiment je comprends pas.
            Utiliser composer, du point de vue du dev c'est juste fournir un json qui te dira de quelles autres librairies tu dois disposer pour que ça marche. Mais tu peux toujours faire sans ! Télécharge les sources, télécharge les dépendances et configure l'autoloading à la main. Voilà.
            Je vois composer comme un genre de Phpdoc, tu peux soit suivre le format des commentaires et l'utiliser pour générer ta doc, soit écrire tes commentaires comme tu veux et écrire ta doc à la main … Mais en aucun cas on ne te force à quoi que ce soit !

            • [^] # Re: à propos de Composer et autres

              Posté par (page perso) . Évalué à -6.

              "Forcer" est un raccourci que j'aurai dû utiliser avec plus de parcimonie.

              Je m'étonne simplement du fait que certaines libs ou certains outils (PHPUnit me vient en premier à l'esprit) mettent en avant les deux méthodes d'installation (avec ou sans composer), alors que d'autres non.

              Oui, bien sûr, on peut utiliser une lib sans composer. Mais on nous "force" la main quand même en ne precisant pas dans la doc de ces libs comment les installer sans composer. Un simple lien suffirait.

              • [^] # Re: à propos de Composer et autres

                Posté par (page perso) . Évalué à 4.

                Bah au lieu de te plaindre, c'est précisément là où tu devrais faire un patch pour être offrir une installation sans composer. Et, oh wait … C'est ça qu'on appelle le libre ! Le fait de pouvoir modifier le code et le redistribuer (vers upstream ou en fork).

          • [^] # Re: à propos de Composer et autres

            Posté par . Évalué à 2.

            « Logiciel libre » [free software] désigne des logiciels qui respectent la liberté des utilisateurs

            Je dirais plutôt la liberté des développeurs.

            • [^] # Re: à propos de Composer et autres

              Posté par . Évalué à 3.

              Je dirais plutôt la liberté des développeurs.

              Non ils contraignent les développeurs dès lors que le logiciel en question est copyleft. D'ailleurs c'est à l'utilisateur que tu dois fournir le code source de l'application. Enfin pour le développeur, ça augmente la concurrence parce que tes utilisateurs peuvent se barrer avec ton code (que tu as était obligé de leur fournir) et aller voir quelqu'un d'autre pour demander des évolutions sur cette base de code (et ils ont le droits de te faire un gros fuck si tu demande à voir le code des nouveautés).

              Vraiment la liberté, elle est coté utilisateur.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: à propos de Composer et autres

          Posté par (page perso) . Évalué à -1.

          La philosophie du Libre, si tant est qu'elle existe, c'est les 4 libertés, rien d'autre.

          J'ajouterais le Manifeste GNU (même si l'on fut déjà plus dans du concret, quoi que…)

          • [^] # Re: à propos de Composer et autres

            Posté par (page perso) . Évalué à 4.

            Non, le Manifeste GNU c'est comme le Manifeste Mozilla, c'est lié à un projet en particulier ici GNU (d'ailleurs certaines parties comme la gratuité ou la compatibilité UNIX n'ont rien à voir avec la notion de Logiciel Libre).

            Ce texte n'a donc rien d'un précepte pour la notion de LL qui n'est que les 4 libertés, le reste sont du fantasmes, des projets particuliers ou des souhaits particuliers mais rien d'officiel.

      • [^] # Re: à propos de Composer et autres

        Posté par (page perso) . Évalué à 5.

        Moi, ce que je vois avec composer, c'est que quand tu code une appli libre, tu cherche à simplifier au maximum l'installation.

        Moi quand je code, je veux faire les choses vite et bien, parce que ce qui m’intéresse, c'est avant tout de pouvoir répondre à un besoin. Alors si l'installation d'une lib est simplifiée, si les développeurs peuvent installer mon framework en déclarant une petite dépendance et en tapant une seule ligne de commande, ça me va.

        Je suis désolé mais non, pour un débutant qui veut utiliser son application, ce n'est pas plus simple de faire (…)
        que d'extraire une archive

        Tu parles d'un utilisateur, ou d'un développeur ? Parce que si c'est pour fournir une application finale (un truc comme wordpress ou phpbb) destinée aux utilisateurs, oui faut être con pour proposer ce genre de chose (encore que, si Composer est installé d'office par les distros, ça peut avoir du sens). Et si je ne me trompe pas, ce genre de projet proposent en général un zip pour les utilisateurs, comportant toutes les dépendances, à déposer quelque part, prêt à être utilisé.

        Pour les développeurs de l'application par contre, non, Composer facilite le développement, les mises à jours des dépendances, l'installation du projet etc… Et donc Composer convient très bien au développement.

        Faut pas confondre développement et utilisation. Développeur et utilisateurs.

        En ce qui concerne debian et cakephp, j'ai bien l'impression que ce que tu racontes n'a rien à voir avec Composer…

        composer est bien pour gérer les dépendances d'un projet pro, statique, où personne ne va mettre son nez dedans, mais pour un projet Libre, je pense que ce n'est pas une bonne solution.

        Désolé, mais tu me fais bien rire là :-) La majorité des packages installables par Composer sont des projets libres. Donc pour ces projets, ce n'est pas la solution ??? Pourquoi ils sont dans Composer alors ? Pourquoi c'est autant utilisés ?

        Quand on code une appli libre, on n'industrialise pas.

        Gniiii ??? c'est quoi cette histoire ? Pourquoi il ne faudrait pas "industrialiser" ?

        Parce qu'on code une appli libre, il ne faudrait pas utiliser les outils que l'on a à notre disposition pour développer, déployer, tester et tout faire à la mimine ou rien faire ???

        Bah désolé, une partie de mes projets libres, je les développe sur mon temps libre (qui se restreint de plus en plus). Tout outil qui pourrait me faire gagner du temps, qui me permettrait d'être plus productif, je les utilises.

        Et c'est d'autant plus intéressant que j'en profite pour découvrir des nouveaux outils ou libs, qui me permettent ensuite au niveau professionnel de monter en compétence, d'être plus productif (et donc éventuellement d'avoir plus de temps pour dev les projets libres).

        Si le gestionnaire de dépendance était partie intégrante de PHP, les choses seraient différentes, mais là c'est un projet lambda. Et forcer à son utilisation est contraire à la philosophie du Libre.

        J'hallucine là. Tu trolles là en fait hein ? c'est ça ?

        Je vais t'apprendre un truc : n'importe quel lib proposée par Composer, tu peux l'utiliser sans Composer. Suffit juste que tu ailles chercher toi même les dépendances, et te faire un autoloader (ce qui est une perte de temps à mon avis).

        • [^] # Re: à propos de Composer et autres

          Posté par (page perso) . Évalué à -3.

          si les développeurs peuvent installer mon framework en déclarant une petite dépendance et en tapant une seule ligne de commande, ça me va

          Oui, mais c'est encore plus simple et rapide d'extraire une archive. Je rajoute l'argument sécurité: si l'URL du dépôt de ton framework est comprise et que le dev qui utilise composer ne vérifie pas ce que composer télécharge…

          Tu parles d'un utilisateur, ou d'un développeur ?

          Peu importe: de plus en plus d'applications complètes utilisent composer comme méthode d'installation par défaut (Magento par exemple)

          En ce qui concerne debian et cakephp, j'ai bien l'impression que ce que tu racontes n'a rien à voir avec Composer…

          Possible, mais je n'ai jamais pu trouver une autre explication.

          Désolé, mais tu me fais bien rire là :-) La majorité des packages installables par Composer sont des projets libres

          La majorité des paquets composer ne sont pas des applications complètes mais des librairies. A mon sens c'est une grosse différence.

          Gniiii ??? c'est quoi cette histoire ? Pourquoi il ne faudrait pas "industrialiser" ?

          Parce qu'on code une appli libre, il ne faudrait pas utiliser les outils que l'on a à notre disposition pour développer, déployer, tester et tout faire à la mimine ou rien faire ???

          Non, ce n'est pas ce que j'ai dis. Pardon, j'abuse de raccourcis, je vais faire plus attention à comment je présente les choses.

          Ce que je veux dire c'est que quand on développe une application à destination du "grand public", on cherche à lui donner une identité. Si on se contente d'un bootstrap à peine modifié, on ne lui donne pas une identité. Mais on peut très bien utiliser bootstrap comme une base, et faire des changement plus importants que lui attribuer un nouveau swatch… J'aime bien parfois tomber sur un site dont l'esthétique me plait, me demander ce qui est utilisé pour le frontend, et découvrir que la base est bootstrap.

          On n'est pas tous web-designer, d'où l'intérêt du Libre: que des web-designers contribuent à l'identité de l'application.

          En entreprise le problème est différent: on s'en tape de l'identité visuelle d'une application à usage interne. Donc là, on industrialise en mettant du bootstrap, possiblement avec quelques corrections mineures, mais le but étant surtout que ça marche et vite. Cette prérogative de "productivité" comme dit ne devrait pas exister dans le cadre d'un projet individuel, non professionnel.

          Encore une fois, je précise que j'utilise ces outils pour mes projets privés, des projets qui ne seront jamais diffusés. Je ne suis pas contre leur usage, il faut être clair là dessus. Je suis contre leur usage pour tout et n'importe quoi et surtout lorsque le travail résultant est rendu public. Ce n'est pas un gage de sérieux selon moi.

          J'hallucine là. Tu trolles là en fait hein ? c'est ça ?

          Je vais t'apprendre un truc : n'importe quel lib proposée par Composer, tu peux l'utiliser sans Composer. Suffit juste que tu ailles chercher toi même les dépendances, et te faire un autoloader (ce qui est une perte de temps à mon avis).

          Désolé si tu as interprété mes propos comme étant du troll.

          Suffit juste que tu ailles chercher toi même les dépendances, et te faire un autoloader (ce qui est une perte de temps à mon avis)

          C'est bien ça le problème. Si les libs étaient proposées avec leur propre auto-loader (ce que fait, une fois encore, PHPUnit, PHPMailer, Smarty, etc.), il n'y aurait pas besoin de faire ça à la main. C'est à la librairie de dire comme se charger, on n'a pas à le "deviner" ou le supposer.

          • [^] # Re: à propos de Composer et autres

            Posté par (page perso) . Évalué à 8.

            Oui, mais c'est encore plus simple et rapide d'extraire une archive.

            en tant que développeur. Non. Pas du tout. Puisque j'ai même pas à connaitre l'url. Juste le nom du paquet. Une ligne dans le json (nom/version), composer install, et c'est terminé. Je veux mettre à jour ? je change la version dans le json, composer update. c'est terminé.

            Alors qu'avec une archive : je dois aller la récupérer sur le site du projet, la dézipper dans mon projet, chercher à savoir comment inclure la lib, ou instancier son autoloader, et donc faire un include (voire plus) quelque part dans mon code. Ensuite, je veux mettre à jour (souvent plusieurs mois après) : faut que je retourne sur le site (dont j'ai oublié le lien, hop, détour par google), retélécharger à la mimine, dézipper les fichiers, ajouter les nouveaux fichiers dans le subversion/git, et supprimer les fichiers qui n'existent plus dans la nouvelle version (ce qui peut être fastidieux, et je parles en connaissance de cause), vérifier dans la doc que l'autoloading ou l'inclusion se fait toujours pareil…

            Bah désolé, non, avec Composer, je n'ai pas toutes ces emmerdes, puisque Composer me télécharge tout ça automatiquement, qu'il m'évite à un inclure dans mon dépôt git ces libs externes, et parce que l'inclusion/autoloading, c'est Composer qui fait tout ça pour moi.

            Je rajoute l'argument sécurité: si l'URL du dépôt de ton framework est comprise et que le dev qui utilise composer ne vérifie pas ce que composer télécharge…

            Parce que le site où tu télécharge ton zip, il ne peut pas être compromis ? tu vérifie tout les zip des libs que tu télécharges ? cela voudrait dire que tu vérifie le contenu de chaque fichier ? et pourquoi alors tu ne pourrais pas le faire dans les sources posées dans le vendor/ par Composer ?

            L'argument de sécurité est nul ici.

            de plus en plus d'applications complètes utilisent composer comme méthode d'installation par défaut (Magento par exemple)

            Perso je trouve ça bête pour un utilisateur final. Mais Magento n'est pas un bon exemple pour ton argumentaire. Le lien que tu montres, c'est la doc pour les développeurs (c'est marqué sur la page). Donc oui, là, utiliser Composer a un sens. Puisque si tu es développeur, cela veut dire que tu vas personnaliser Magento, lui rajouter du code pour des traitements metiers, des plugins ou que sais-je, et donc probablement installer d'autres lib (en utilisant Composer ou pas).

            Pour les utilisateurs finaux, il faut aller voir sur le site pour les utilisateurs. Et qu'y trouve-t-on ? Oh, miracle, des tar.gz prêts à l'emploi ! ;-)

            La majorité des paquets composer ne sont pas des applications complètes mais des librairies. A mon sens c'est une grosse différence.

            Tu parlais de projets libre. Alors, à moins que pour toi une lib libre n'est pas un projet libre, je ne vois pas de différence.

            Ce que je veux dire c'est que quand on développe une application à destination du "grand public", on cherche à lui donner une identité. Si on se contente d'un bootstrap à peine modifié, ….

            Tu passes de PHP à Bootstrap, du coq à l'âne, donc des problématiques différentes. J'avoue que ton discours est très difficile à suivre.

            Si les libs étaient proposées avec leur propre auto-loader (ce que fait, une fois encore, PHPUnit, PHPMailer, Smarty, etc.), il n'y aurait pas besoin de faire ça à la main.

            Oui donc, au final, dans un projet, si tu utilises 25 libs, tu as alors 25 autoloaders, qui font quasiment la même chose. Bonjour les perfs. Avec Composer : on peut avoir un seul autoloader, en particulier si on utilise les namespaces (il est possible de lui indiquer des autoloaders spécifiques si nécessaire, par exemple ceux des libs ayant un autoloader spécifique).

            C'est à la librairie de dire comme se charger, on n'a pas à le "deviner" ou le supposer.

            Justement, avec Composer, on a encore moins à s'en charger, puisqu'il y a au final 0 include à faire après avoir installé une lib. Alors que, pour une lib "non composerifiée", il faut que tu saches quel fichier inclure (celui qui fait tout les includes de la lib ou qui déclare l'autoloader de la lib).

          • [^] # Re: à propos de Composer et autres

            Posté par . Évalué à 2.

            Peu importe: de plus en plus d'applications complètes utilisent composer comme méthode d'installation par défaut (Magento par exemple)

            Products/Open Source CE/View available downloads
            Un mouse over, et deux clicks
            http://www.magentocommerce.com/download
            Mais typiquement, Magento, c'est le genre de truc qui n'est pas installé par l'utilisateur final.

            Depending on the time of day, the French go either way.

      • [^] # Re: à propos de Composer et autres

        Posté par (page perso) . Évalué à 5.

        Quand on code une appli libre, on n'industrialise pas.

        Tu sais ce qu'est le libre?
        Je ne vois aucun rapport entre libre et industrialisation.
        il y a des outils non libres non industrisalisés comme des outils libres industrialisés.

        C'est insultant envers le libre de deux manières : 1/ en ne connaissant pas ce qu'est le libre 2/ En sous-entendant que le libre ne peut pas être professionel.

        • [^] # Re: à propos de Composer et autres

          Posté par (page perso) . Évalué à -5.

          Il semble que mes connaissances en la matière soient moins étendues que les tiennes (je dis sans sans la moindre ironie). Aurais-tu l'amabilité de m'indiquer un projet libre industrialisé, écrit en PHP, et à destination du "grand public" (donc pas destiné à un usage professionnel) ?

          Je ne sous entends pas que "le libre ne peut pas être professionel", je sous entends qu'une application libre non professionnelle ne devrait pas être industrialisée. Tu me suis ?

          • [^] # Re: à propos de Composer et autres

            Posté par (page perso) . Évalué à 2.

            La seule chose que je dis est que le libre n'a rien à voir avec tout ce dont tu parles.
            Libre ou pas, on s'en fout pour ce dont tu parles, c'est orthogonal.
            J'ai du mal à comprendre ce qui est difficile à comprendre la dedans : c'est comme si tu me disais qu'une voiture de couleur bleue ne peut évidement pas aller plus vite qu'une voiture de couleur verte.

          • [^] # Re: à propos de Composer et autres

            Posté par (page perso) . Évalué à 8.

            Aurais-tu l'amabilité de m'indiquer un projet libre industrialisé, écrit en PHP, et à destination du "grand public"

            Faudrait déjà que tu définisses "industrialisé", et "usage professionnel".

      • [^] # Re: à propos de Composer et autres

        Posté par . Évalué à 1.

        Je suis désolé mais non, pour un débutant qui veut utiliser son application, ce n'est pas plus simple de faire:

        curl -sS https://getcomposer.org/installer | php
        composer.phar install

        que d'extraire une archive. D'autant que composer semble ne pas fonctionner partout de la même façon: sous Mac OSX, l'installation de CakePHP se fait exactement comme dans la doc officielle. Sous Debian, l'arborescence de vendor n'est pas la même et il devient impossible de charger le bootstrap de CakePHP sans modifier une variable pour mette le chemin en dur parce que sous Debian, il chope le repo git au lieu du repo PEAR (ou l'inverse, je ne sais plus).

        composer est bien pour gérer les dépendances d'un projet pro, statique, où personne ne va mettre son nez dedans, mais pour un projet Libre, je pense que ce n'est pas une bonne solution.

        C'est pas faux. J'ai un peu le même souci avec nodejs. Mais bon, vu qu'en php il faut en plus se taper le serveur web + bases de données, normalement après ces terribles épreuves, tu sais à peu près comment géré

        curl -sS https://getcomposer.org/installer | php
        composer.phar install

        Maintenant, pour en revenir au problème que tu soulèves. Je pense que tu l'attaques par le mauvais bout. Ce qu'il te manque c'est un installeur simple et rapide, comme papa faisait avec son windows. Un double click, et après une mitraille de YES YES YES OK CONTINUE et bam c'est installé.
        M'enfin, apparemment, tout le monde y va de son store et de son système de package à l'heure actuelle. Moi cela me va tant qu'on ne m'empêche pas de publier dessus, sinon c'est de la tyrannie (genre debian et ces paquets, ma ptite crotte de nez)

  • # Python c'est mieux maintenant

    Posté par . Évalué à 7.

    Si PHP et son ecosystème ne te conviens plus il existe Python (WSGI) et un framework Django qui est MVC.

    kentoc'h mervel eget bezan saotred

    • [^] # Re: Python c'est mieux maintenant

      Posté par . Évalué à 6.

      Ou Ruby On Rails, ou node.js, ou …

      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

    • [^] # Re: Python c'est mieux maintenant

      Posté par . Évalué à 4.

      Python pourquoi pas, par contre Django bof bof, y a des choses qui me manque dedans et qui sont pas évidant à faire ou avec des plugins non-maintenue tels que Server Sent Event par example.

      Je préfère largement flask à choisir.

    • [^] # Re: Python c'est mieux maintenant

      Posté par (page perso) . Évalué à 0.

      Jamais dis que PHP ne me convenait plus: ce sont les "trucs" modernes qui ne me conviennent pas, et surtout, la quasi obligation de passer par des outils comme composer pour choper des libs.

      Je ne dis pas non plus que tous les trucs modernes me dérangent: Redbean est une lib moderne développée par un conservateur. Ça pour moi c'est l'idéal du développement en PHP.

      • [^] # Re: Python c'est mieux maintenant

        Posté par . Évalué à 0.

        Moi le framework qui me force à utiliser un ORM ça ne me convient pas. Inclure une floppée de classes juste pour écrire un CRUD propre je trouve ça tout much donc ton Redbean moderne conservateur me dérange …
        À conservateur, conservateur et demi !

        • [^] # Re: Python c'est mieux maintenant

          Posté par (page perso) . Évalué à -2.

          L'intérêt est surtout de faciliter le développement sans ciblage d'une BDD spécifique en l'occurrence.

          • [^] # Re: Python c'est mieux maintenant

            Posté par . Évalué à 2.

            Je crois (puisqu'on parle de PHP) que c'est précisément à ça que sert PDO

            • [^] # Re: Python c'est mieux maintenant

              Posté par (page perso) . Évalué à -2.

              Tout à fait, et d'ailleurs Redbean s'appuie sur PDO en simplifiant certaines opérations et surtout en modifiant à la volée la structure de la base de données.

              Si ça c'est pas fait pour aider les développeurs…

              • [^] # Re: Python c'est mieux maintenant

                Posté par . Évalué à 8.

                Si ça c'est pas fait pour aider les développeurs…

                Tu veux dire, un peu comme composer et bootstrap ?

              • [^] # Re: Python c'est mieux maintenant

                Posté par . Évalué à 3.

                en modifiant à la volée la structure de la base de données.

                C'est ce que j'appellerais moi "fancy", comme le tag de ton journal. Et je n'en veux pas. Ça diminue fortement, pour moi, la lisibilité chère aux libristes.
                TU vois, on est toujours le conservateur d'un autre autre, mais toi tu y trouves ton compte, tant mieux. Pas de quoi fustiger un non-respect d'une pseudo-éthique libre ou une "industrialisation" ou que je ne sais-je.

        • [^] # Re: Python c'est mieux maintenant

          Posté par . Évalué à 1.

          Ah ouais…. un ORM qui dispose d'un query writer me semble totalement indispensable aujourd'hui pour faire un CRUD honnête pour mes utilisateurs et sans trop d'efforts. M'enfin, y'à ceux qui regardent devant, et puis y à les autres.

  • # Plutôt d'accord

    Posté par . Évalué à 8.

    Je fait partie des vieux cons qui ont commence le web avec les CGI puis je suis passé à php à l'époque ou ça voulait encore dire "Personnal Home Page".

    J'ai récemment fait un projet avec synfony 2 et alors la j'étais sur le cul:
    - Ils ont réinventés les annotations : quitte à faire du comme avec java autant le faire en java
    - Le framework balance ses header sans même que tu le lui demande, ce qui fait que pour générer à la volée une image la seule solution a été de provoquer un trap : ce qui est quand même très moche.

    et plus généralement sur les framework php modernes j'ai lu, il y a quelques temps (je ne me rappelle plus de l'url mais il me semble que je l'avait trouvé depuis linuxfr) du créateur de php qui disait tout le bien qu'il en pense.

    • [^] # Re: Plutôt d'accord

      Posté par (page perso) . Évalué à 4.

      100% d'accord avec tes remarques sur Symfony, et c'est bien de lui que je parlais quand je disais "Du code logique dans les commentaires ?" (ça a peut être changé depuis ceci dit)

      • [^] # Re: Plutôt d'accord

        Posté par . Évalué à 3.

        J'ai retrouve l'url de l'interview de Rasmus

        Interview

      • [^] # Re: Plutôt d'accord

        Posté par . Évalué à 3.

        les "fausses" annotations sont loin de faire l'unanimité, même chez les "modernes". Tu peux faire du symfony sans les utiliser du tout, c'est pas plus compliqué, ça manque un poil de doc pour les entités doctrine, qui est le seul domaine ou la doc pousse vraiment les annotations, autant que je me souvienne.

        Mais surtout n'utilise pas symfony si t'aimes pas, un agrégat de lib qui te plaisent pour faire ta sauce, c'est cool. Et justement PSR, composer et les namespaces, ça permet de faire ça simplement et un peu plus maintenable, même s'il peut y avoir des choses à redire sur les implem/syntax.

        Ozz, qui n'a presque plus honte de faire du php pour se nourrir.

        • [^] # Re: Plutôt d'accord

          Posté par . Évalué à 2.

          Ca sert à quoi d'autre le PHP ? C'est pas du code alimantaire ? Mince alors… j'en était totalement convaincu.

    • [^] # Re: Plutôt d'accord

      Posté par (page perso) . Évalué à 7.

      et plus généralement sur les framework php modernes j'ai lu, il y a quelques temps (je ne me rappelle plus de l'url mais il me semble que je l'avait trouvé depuis linuxfr) du créateur de php qui disait tout le bien qu'il en pense.

      Un avis précieux qui convaincra tout le monde tant personne n'a jamais dit tout le bien qu'il pense de PHP :-D

  • # Laravel + Twig semble pas mal

    Posté par (page perso) . Évalué à 4.

    J'ai quitté le monde Php pour aller vers Python depuis on va dire 2007, mais j'ai l'impression qu'il existe maintenant des trucs pas trop mal en Php qui ressemble à Django, Flask, Pyramid :

    J'ai aussi l'impression que Smarty (je l'utilisais en 2002) semble dépassé, http://twig.sensiolabs.org/ semble très bien, clone du moteur de Template Jinja2.

  • # des mauvaises expériences ?

    Posté par . Évalué à 4.

    J'étais content que les PSR soit release. J'étais content que Composer soit crée. J'était moins heureux de voir la complexité de symfony2. Mais dans l'ensemble je trouve que ces outils sont des avantages pour les développeurs PHP.

    Alors je ne te comprends pas bien.

    Je ne peux que t'inviter à pousser tes tests.

    Derniere chose, Redbean, c'est bien, c'est pratique, m'enfin, ce n'est pas non plus la panacée, selon moi.
    Gabor a des avis tranché sinon il manipulerait du doctrine, mais sur ce point, ce n'est pas très argumenté.

  • # "leur usage abusif des namespaces"

    Posté par . Évalué à 10.

    Euh, QUOI ?!

    "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

  • # C'est pas le code moderne que tu n'aimes pas, c'est le PHP moderne...

    Posté par . Évalué à 10.

    Franchement, la plupart de ton journal n'est pas contre le code moderne, juste contre la façon de programmer majoritaire des utilisateur d'un seul langage, crade.
    Je passerai outre les 90% de ton journal qui parlent de PHP et de quelques framework spécifiques.

    Quand je lis ça:

    au prix d'artifices plus ou moins alambiqués (genre certains design-patterns, les namespaces, les traits, etc.).

    Alors… les design pattern, je vais devoir t'expliquer ce que c'est on dirait. Ce sont juste des noms et un peu d'explications mis sur des construction, que ce soit d'implémentation ou d'architecture, souvent utilisés. Entres autres pour éviter que quelqu'un ne les utilise à mauvais escient ou pour faciliter la communication (éviter de sortir un diagramme de classes pour parler d'une construction classique, ça fait gagner du temps dans les échanges)…
    Personnellement, quand j'ai découvert leur existence, je me suis aperçu qu'il y en à 2-3 que j'utilisais déjà depuis longtemps, inconsciemment.

    Les traits, j'ai lu dans un de tes messages que tu crois que c'est pour remplacer l'héritage multiple, ou les interfaces. Faux. C++ supporte depuis toujours l'héritage multiple. Sauf que l'héritage, ça à un coût au runtime (principalement à cause des méthodes virtuelles, il faut bien le dire), et quand tu le mêles à de la généricité, ça devient infernal de pas avoir de problèmes de compilation.
    Bien sûr, je parle de langage natif, mais, tu as parlé de code moderne, ce n'est pas limité au seul web et encore moins au seul PHP.
    Bref, les traits, ça permets, sans surcoût de performance (dans un langage compilé, hein) de pouvoir certifier à l'utilisateur (de la classe) que certaines conditions sont remplies. Ça simplifie potentiellement à la fois l'écriture du code, la documentation du code, et les messages d'erreur de la compilation (en tant que dev C++, je peux t'assurer que j'ai acquis un certain niveau en GNU-vaudou… ceci dit je préfère les incantations de clang, elles sont moins trash!).

    Les namespace, c'est aussi très utile. Je suis en train de me bricoler une classe pour encapsuler les sockets BSD. Et tu sais quoi? Grâce à eux, je n'ai pas eu besoin de me casser la tête pour les noms de classe et de fonctions: j'ai utilisé socket et poll, en sachant que, grâce au namespace, je n'aurai pas de conflits de noms (évitable pour les fonction grâce au fait qu'en C++ le prototype inclue les types, mais pas pour les classes/structs).
    Et c'est tellement plus lisible de pouvoir faire sdl::CreateSurface que de devoir se farcir des SDL_CreateSurface. Pourquoi? Parce que moyennant un import de l'espace de nom sdl, on peut juste appeler CreateSurface.

    Bref, je suis en complet désaccord avec toi pour ce qui est du code moderne.

    Maintenant… Comme toi, j'ai du mal avec les framework. Je leur préfère des collections de bibliothèques indépendantes, qui répondent très précisément à mon besoin. Et quand il faut mettre à jour ou changer (parce qu'il faut porter le projet à un autre système, par exemple) une bibliothèque, la part du code à mettre à jour est plus restreinte.
    Évidemment, ça à les inconvénients de ses qualités: il faut prendre le temps de chercher les libs adaptées, et espérer ne pas se planter, parce que tu n'as pas l'éternité devant toi pour choisir ces libs: le but n'est pas de choisir des libs, mais de coder, pas vrai?
    Donc, je comprend les utilisateurs de framework, même si je suis en désaccord avec eux.

    Ensuite… ce n'est pas parce que certains framework sont mal branlés, buggués, mal architecturés, etc, que c'est le cas de tous, ou qu'aucune lib plus petite n'est pas affectée par ces problèmes.

    Enfin… conclusion:
    Change de langage. Non, mais sérieux… tu dis dans un post que tu gardes PHP pour faciliter la vie des débutants? Bah justement, arrêtes d'enrichir l'éco-système d'un langage si décrié, adoptes un langage plus propre (je suis sûr qu'il y en a. Peut-être python, ruby? J'en sais rien, honnêtement.) et arrêtes de basher le code moderne alors que tu parles en fait d'une fraction de ses utilisateurs, qui utilisent un langage qui n'à jamais eu pour vocation d'être un langage.
    Je cite wikipedia: «Le langage PHP fut créé en 1994 par Rasmus Lerdorf pour son site web. C'était à l'origine une bibliothèque logicielle en C»…
    Si tu savais ce que je pense du C… c'est l'anti-thèse de la modernité, un langage qui rend complexe l'écriture de code sécurisé et maintenable. Je ne le considère pertinent que pour de la maintenance d'applications historiques écrites en C (et encore) et l'embarqué où l'on doit avoir un contrôle total sur la taille du binaire et son empreinte mémoire (encore que, je pense qu'un subset de C++ permets d'améliorer les choses par rapport au C tout en ayant les mêmes tailles/empreintes).

    Liste quasi-complète de ce que je lui reproche:

    • type safety très faible,
    • gestion de la mémoire complètement manuelle: ni RAII, ni GC, ni conteneurs standard (que ce soit pour les choses dynamiques ou statiques, hein),
    • obligation de copier/coller le code quand juste le type change cf abs(int), labs(long int), llabs(long long int),
    • macros qu'il ne faut jamais utiliser parce que quand ça pète, tu en as pour quelques heures pour trouver d'où ça peut bien venir.

    On reproche souvent au C++ ses exceptions, sa RTTI, mais ces gens là oublient systématiquement de préciser, que l'on est jamais obligé d'utiliser la STL (je n'ai pas trouvé en moins de 2minutes de façon d'utiliser std::vector en mode nothrow. Je pense que ça existe ceci dit, ou que ça ne devrait pas être trop complexe de spécialiser vector pour utiliser nothrow) et que pour l'allocation de classes new/delete sont incomparablement supérieurs à malloc/calloc/free, parce qu'on peut choisir de l'utiliser avec ou sans exceptions.

    Bref, vive le code moderne, à bas les langages pré-historiques, et laissez les gens choisir s'ils veulent ou non utiliser des framework.
    Ah, et surtout: à bas les bâcleurs de code, même si je pardonne ceux qui n'ont pas le choix parce que leur chef le leur impose!

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.