Journal asp.NET vNext, MVC 6, Entity Framework 7, Roslyn, Microsoft continue à libérer ses technologies ...

Posté par . Licence CC by-sa
16
3
juil.
2014

Bonjour,

Lors du dernier TechEd North America, le 12/05/2014 Microsoft a fait de nombreuses annonces allant dans le sens de la libéralisation totale de sa pile pour le développement d'applications web.

Sans oublier Razor, entity framework, etc…

Alors, je sais, la licence apache, ce n'est pas l'idéal, mais je suis content, parce que je vais enfin pourvoir coder des sites web MVC propres en C# et les héberger sur mon serveur linux préféré. J'en connais chez PHP qui doivent pleurer. La seule et unique raison d'utiliser ce truc c'était l’hébergement facile et gratuit sur un serveur LAMP.

Demain, c'est vendredi, et jour de match ;-)

  • # HS mais si ça doit devenir une dépêche...

    Posté par . Évalué à 1.

    "compilaeur" -> "compilateur" ; "c'est à dire" -> "c'est-à-dire" (douteux?) , "mais Je suis content" -> "mais je suis content", "parce-que" -> "parce que"

  • # Blague?

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

    J'en connais chez PHP qui doivent pleurer. La seule et unique raison d'utiliser ce truc c'était l’hébergement facile et gratuit sur un serveur LAMP.

    Je ne sais pas si c'est sérieux ou pas mais on va comme si, c'est plus drôle.

    Il y a déjà d'autre frameworks dans de vrais langages qui permettent de faire des sites proprement, pourtant PHP n'a pas disparu. Une des raisons (outre la facilité dangereuse avec laquelle on fait un site en PHP), c'est que PHP est partout (et PHP est partout parce que PHP est partout). Les offres mutualisés proposent d'abord du PHP et parfois, pour plus cher, du Python/Ruby/C#, les deux premiers étant gratuits et libres depuis longtemps, ce n'est pas ça qui leur permit de surpasser leur concurrent. Je ne crois pas que ce soit une bonne nouvelle de ce côté. Par contre, pouvoir développer/déployer ce genre de site sur du Linux va sans doute simplifier la vie de quelques admin système.

    J'ai un peu l'impression que MS va de plus en plus vers un modèle où l'OS n'est plus important. Bientôt, ils n'auront plus besoin de développer Windows et ils feront tourner leurs services sur du Linux/HPUX
    /Systemz.

    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Blague?

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

      PHP a quelques autres avantages qui viennent du fait qu'il est interprété directement par Apache :
      * tu peux très facilement déployer un site en PHP (upload de l'archive, et zou, c'est parti)
      * tu peux tout configurer via le site-même (les coordonnées de la base MySQL, par exemple)
      * tu peux mettre à jour en un clic directement depuis le site
      * tu peux ajouter facilement des plugins

      Je connais plutôt bien Python + Django, et ces quatre choses ne sont pas triviales du tout (à vrai dire, je ne connais aucun site en Django qui le permette). De plus, un site en Django va demander un peu de configuration Apache, ce qui est facultatif en PHP.

      • [^] # Re: Blague?

        Posté par . Évalué à 3.

        • tu peux très facilement déployer un site en PHP (upload de l'archive, et zou, c'est parti)

        Mwé enfin c'est loin d'être le seul langage qui le permet…

        • tu peux tout configurer via le site-même (les coordonnées de la base MySQL, par exemple)

        Gné ? PHP a tant changé que ça depuis ma dernière utilisation? A mon époque (<= phrase de vieux con) fallait passer par une conf à la mimine dans un fichier texte. Tu confond pas un peu PHP et framework PHP / CMS basé sur PHP?

        • tu peux mettre à jour en un clic directement depuis le site

        Mettre à jour quoi? PHP ? J'ai toujours eu à passer par une commande admin type apt-get update… Peut-être sur des ditrib/installtion particulière mais ce n'est pas une fonction propre au langage

        • tu peux ajouter facilement des plugins

        Tout dépend de ce qu'on veut dire par facile mais pourquoi pas

        Concernant Django:
        1. jamais eu de problème pour ça
        2. faut juste savoir éditer un fichier texte (même chose qu'en PHP natif)
        3. à part une montée de version qui parfois fait changer certaines API (rare mais ça arrive y a encore des trucs en travaux) c'est pas plus dure que PHP
        4. Pas plus compliqué qu'en php

        Tu es sûr que tu mélanges pas langage et environnement logiciel… on parle de langage là hein :-) En tout cas ton site perso est sympa. Tu utilise quel CMS? Wordpress?

        • [^] # Re: Blague?

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

          1. jamais eu de problème pour ça

          Tu dois pourtant configurer le wsgi dans Apache, ce n'est pas nécessaire pour php sachant que mod_php est activé par défaut dans les installation classiques.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Blague?

            Posté par . Évalué à 5.

            Tu as complètement raison, mais ça na rien à voir avec les qualités du langage.
            Sauf si on considère que le fait d'être partout est un gage de qualité, à ce moment là, Windows est bourré de qualités (ET PAF! un troll de plus, l'aviez pas vu venir celui là hein?)

            • [^] # Re: Blague?

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

              Tu as complètement raison, mais ça na rien à voir avec les qualités du langage.

              Personne n'a dit que c'était une qualité du langage mais une raison au fait qu'il soit partout.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: Blague?

                Posté par . Évalué à 2.

                Choisir un langage parce qu'il permet d'éviter 3 lignes dans un fichier de conf c'est un peu léger…
                Pour le reste, je ne vois pas non plus le rapport entre les mises à jour, les plugins et les langages dont on parle.

                Ca fait très longtemps que je ne me suis pas coltiné du PHP, quel est l'équivalent de virtualenv en python ? cad créer un environnement avec ses propres libs pip-installées par projet.

                • [^] # Re: Blague?

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

                  Choisir un langage parce qu'il permet d'éviter 3 lignes dans un fichier de conf c'est un peu léger…

                  Sauf que ça veut dire que l'utilisateur n'a pas à toucher un seul fichier de conf. Pour un admin système, ce n'est pas vraiment un problème, pour un type qui n'a jamais fait ça, c'est un avantage. Ça permet de répandre ton logiciel partout très facilement et au final, d'avoir beaucoup de contributeurs.

                  Ca fait très longtemps que je ne me suis pas coltiné du PHP, quel est l'équivalent de virtualenv en python ? cad créer un environnement avec ses propres libs pip-installées par projet.

                  Tu vas trop loin, virtualenv, c'est trop compliqué pour les avantages qui sont cités. Après, ça pose d'autres problèmes mais ce n'est pas ce genre de projet où PHP est utilisé.

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                  • [^] # Re: Blague?

                    Posté par . Évalué à 2.

                    Tu vas trop loin, virtualenv, c'est trop compliqué pour les avantages qui sont cités. Après, ça pose d'autres problèmes mais ce n'est pas ce genre de projet où PHP est utilisé.

                    On parlait de mises à jour, de plugins, de configuration en ligne… Pas d'un simple echo "hello".
                    Dès que le projet prend un tout petit peu d'ampleur cette facilité de déploiement devient toute relative si je comprends bien.

                    • [^] # Re: Blague?

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

                      Dès que le projet prend un tout petit peu d'ampleur cette facilité de déploiement devient toute relative si je comprends bien.

                      Ça dépend pour qui. Demande à l'utilisateur Wordpress de base d'utiliser virtualenv, c'est en dehors de leur capacité1 (et pas permit par la plupart des hébergement mutualisé). Si tu ne te base sur une installation standard (et tu fournit tout le reste dans ton archive), tu te coupe de beaucoup d'utilisateur.

                      Il faut bien noter que je n'approuve pas ce genre de comportement, je ne fais que le constater.


                      1. ou, en tout cas, du temps qu'ils veulent bien mettre à les obtenir 

                      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                    • [^] # Re: Blague?

                      Posté par (page perso) . Évalué à 2. Dernière modification le 04/07/14 à 14:39.

                      Mettre à jour php ? Sur un mutualisé ? Tu te conformes à la version de ton hébergeur.

                      EDIT : je lis plus bas "mettre à jour l'application". Pour PhpBB on décompresse le zip et on va sur une page du genre http://tonsite.com/forum/update.php .

                      Des plugins ? Pareil.

                      Et avec un mutualisé, tu peux monter un site pour des milliers d'utilisateurs au moins. Et encore, quelques milliers c'est chez OVH en optimisant le cache et avec du Cloudfare car si tu dépasses les 4k visiteurs uniques par jour il te met sur un sous-cluster en mousse, chez d'autres comme Infomaniak tu peux aller au-delà sans problème avec un site pas du tout optimisé pour la bande-passante (alors optimisé j'en parle pas).

                      Définis "un tout petit peu d'ampleur". Si ton projet a besoin d'un serveur dédié, l'installation pour tel ou tel langage sera kif-kif, mais tu pourras toujours coder sans apprendre de framework alors qu'en Python sans framework t'es un peu rustique et en Java tu aimes te faire du mal.

                      Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

                  • [^] # Re: Blague?

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

                    Sauf que ça veut dire que l'utilisateur n'a pas à toucher un seul fichier de conf. Pour un admin système, ce n'est pas vraiment un problème, pour un type qui n'a jamais fait ça, c'est un avantage

                    Si c'est un vrai problème. Quand le type se fera (et ça arrivera) défoncer son wordpress et que l'admin sys passera des heures à essayer de lui expliquer pourquoi il faut qu'il vire le plugin machin qui l'oblige à avoir 12 versions de wordpress de retard.

                    Faire croire qu'on peut héberger sérieusement une application web sans que personne, ni chez l'hébergeur, ni chez le webmaster, ni chez l'éditeur n'assure une expertise applicative sérieuse est juste une immense supercherie. A un moment ou a un autre, face à un problème de sécurité, de performances, un plantage, il faut quelqu'un pour mettre le nez dans le code.

              • [^] # Re: Blague?

                Posté par . Évalué à 1.

                A oui pardon, j'ai moi-même fait une relation trop rapide entre qualité et le fait d'être partout.

                Là où c'est rigolo c'est que la qualité principale de PHP est justement d'être partout.
                On a donc bien un langage qui à la base n'avait rien pour lui, qui s'est largement déployé peut-être simplement faute de concurrence à l'époque. Et maintenant qu'il existe des alternatives, c'est uniquement son large déploiement qui justifie son utilisation…

                • [^] # Re: Blague?

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

                  Il a un autre avantage, c'est d'être très facile à utiliser. N'importe qui comprenant les bases de la programmation peut faire une page PHP. En Python (par exemple), tu ne peux pas, tu dois passer par un framework, comprendre comment l'installer, décrire tes routes, il y a très souvent un modèle (du genre MVC) à respecter pour l'utiliser pour ne pas se battre contre le système. Bref, la barrière est plus haute. Il y a aussi ce type de frameworks en PHP mais ils ne sont pas nécessaire, on peut faire un truc crade facilement.

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                  • [^] # Re: Blague?

                    Posté par . Évalué à 4.

                    Tu as aussi raison sur ce point, c'est très facile.
                    Mais c'est justement, à mon avis, une de ses plus grande faiblesses. Personnellement, je ne compte plus les apprentis dev PHP qui pensent: "j'ai fait le hello world en 2 sec, je vais maintenant me lancer dans un site de vente en ligne" et c'est justement sur ce changement d'échelle que tout par en sucette.

                    Ca me rappelle aussi ces apprentis sorciers qui se font passer pour des cadors car ils sont capable de te faire tourner la compta entière d'une boîte à base d'Excel et autre VBS. "Personne arrive à comprendre comment il fait, c'est vachement compliqué, il est trop fort …". Tu m'étonnes.

                    Au risque de passer pour un vieux snob aigris (j'ai malheureusement passé trop de temps à débugger de la merde), le mec qui me dit "j'utilise le PHP parce que c'est facile à utiliser" …. J'ai envie de de lui dire "change de domaine d'activité t'a rien a foutre là et tu ferai mieux de t'en tenir à ton skyblog sur les nains de jardin."

                • [^] # Re: Blague?

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

                  Faut voir aussi qu'une fois php installé, t'as besoin de rien d'autre. Tu prends ton éditeur de texte et tu écris dans un fichier :

                  <%php echo "Salut j'apprends le PHP c'est trop cool !"; %>

                  Et voilà t'es déjà en train d'écrire tes premières lignes de PHP. Alors que Django, t'as besoin de t'adapter à l'architecture du projet (génial quand tu débutes et qu'avant de savoir ce qu'est un MVC tu sais même pas ce qu'est une classe), et ailleurs t'as des dépendances assez lourdingues en plus d'un langage plus contraignant.

                  On peut troller autant qu'on veut sur la qualité du code qu'on peut trouver en php produit par des têtes blondes ayant parcouru la moitié du tuto du Site du Zéro (je crois que le nom a changé et que le site est devenu inutilisable), mais tant qu'on n'a pas atteint le stade où on est conscient de ce qu'est un code moche, développer un site reste plus facile en php qu'en autre chose.

                  Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

        • [^] # Re: Blague?

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

          Mettre à jour quoi? PHP ?

          non, l'appli en PHP (si elle a cette fonctionnalité).

          M'enfin, ce n'est pas forcément trivial avec apache+mod_ph : il faut que les fichiers de l'appli soit installée avec les droits en écriture pour le user d'apache.

          Du coup, pour ce genre de feature, vaut mieux installer php en mode fcgi (avec php-fpm), pour lequel on peut donc indiquer un user d’exécution différent d'apache (donc en principe le user qui s'occupe de la maintenance de l'appli).

          • [^] # Re: Blague?

            Posté par . Évalué à 2.

            Une blague non !
            L'objectif de Microsoft est bien de lutter de front contre PHP en s’inspirant de ce qui est bien chez RUBY et d'autre.

            => La compilation just-in-time est de la partie aussi, tu modifies le fichier source, et hop tu exécutes (pour le meilleur et pour le pire).

            => Tu embarques ta version du framework dot.net (ou mono) avec toi, les librairies aussi, dans le répertoire de l'application.
            Tu décompresses, tu lances le script, et hop cela roule. Tu n'as pas besoin d’apache, ni de module, ni de cgi. Auto-hébergement c'est le mot à la mode (et proxy - reverseproxy, j’espère)!

            => Et tout cela avec un langage fortement typé, à peu prés orienté objet, un entity framework 7 qui devrait autoriser le stockage dans des bases nosql, un framework MVC plus que propre,
            des webservices, des webapi restfull…

            • [^] # Re: Blague?

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

              Tu n'as pas besoin d’apache, ni de module, ni de cgi.

              Si c'est pour tester, PHP aussi embarque un serveur web. pas besoin d'apache, ou autre pour exécuter une appli php.

              • [^] # Re: Blague?

                Posté par . Évalué à 3.

                Pas forcement pour tester.
                C'est la tendance en ce moment, des applis qui embarquent le serveur. Les serveurs d'applis sont chiant a installer/configurer/redemarrer de facon automatise.

                Typiquement, c'est vachement plus simple d'avoir une appli java avec jetty embedded que de se faire chier a installer tomcat ou autre.
                Java -jar monjar.jar et c'est parti.

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

                • [^] # Re: Blague?

                  Posté par . Évalué à 3.

                  Typiquement, c'est vachement plus simple d'avoir une appli java avec jetty embedded que de se faire chier a installer tomcat ou autre.

                  Ça c'est parce que tomcat est mal fichu à en mourrir. L'idée d'un serveur d'application c'est de pouvoir séparer les tâches, celui qui s'occupe de l'administration va pouvoir configurer le serveur d'application avec la base d'utilisateurs qui va bien, les data sources qui vont bien aussi et configurer le TLS correctement (et éventuellement du tunning pour gérer la charge ou utiliser au mieux la machine sur le quel c'est installé). C'est des choses qui se font très mal avec tomcat (je ne sais pas pour jetty).

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

                  • [^] # Re: Blague?

                    Posté par . Évalué à 2.

                    C'est une vision tres old school des serveurs d'applis (j'imagine que tu fais reference a JNDI?).
                    A l'heure de l'autoscaling et du configuration management, tu t'emmerdes plus avec tout ca. Tes connections DB, elles sont configurées par des fichiers properties générés au runtime par chef, ou fournies par ton discovery service.
                    Tu t'emmerdes pas non plus a héberger plusieurs services sur la meme VM, et quand bien meme tu le ferais, t'as pas besoin de les faire tourner dans le meme conteneur. Dans un environment moderne, les gros serveurs d'appli (ou meme les legers, comme tomcat) sont plus une plaie qu'autre chose, ils ne répondent pas vraiment a un problème (ou plutôt, tres mal) et créent un paquet de problèmes de déploiement.
                    Quand a TLS, tu fait comme tout le monde, tu le termines sur ton LB a l'entree de ton DC et tu poursuit ton chemin en HTTP.

                    Dit autrement, tu "n'administre" pas un serveur, t'en déplois un nouveau et met l'ancien a la poubelle. J'imagine qu'il y'a encore beaucoup de monde qui gère ses machines comme tu le décris, mais c'est pas franchement la direction que prend l'industrie depuis qq années.

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

                    • [^] # Re: Blague?

                      Posté par . Évalué à 3.

                      A l'heure de l'autoscaling

                      Je ne pense pas que le cloud (et le cloud élastique) devienne si universel que ça. Tout le monde n'en a pas besoin et ça apporte plus de complexité (pour ceux qui n'ont en pas besoin).

                      et du configuration management

                      Là tu viens de fusiller un grand paquet d'adminsys…
                      Mais je vois pas en quoi ça change quelque chose. Que ta gestion de configuration permette de configurer le serveur d'application ou l'application qui tourne dessus ça ne change pas grand chose. L'avantage de certaines indirections (au moins théoriques) c'est par exemple pour l'authentification que l'appli déclare vouloir des utilisateurs pour tel domaine de sécurité et que le serveur d'application soit configuré pour taper sur un annuaire, une suite d'annuaires, un fichier plat ou une base de données.

                      Pour un exemple peut être plus concret avec des files JMS sur weblogic, on déployait en local/intégration/preprod sans modifié les livrables alors que selon les environnement les destinataires étaient locaux ou non, qu'il y avait du loadbalancing (une file pointe vers plusieurs destinations), des fois un agent local pour fiabiliser les envois,… tout était géré par configuration des domaines weblogic.

                      L'exemple de tomcat est une plaie parce qu'il ne fait rien de vraiment bien.

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

          • [^] # Re: Blague?

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

            M'enfin, ce n'est pas forcément trivial avec apache+mod_ph : il faut que les fichiers de l'appli soit installée avec les droits en écriture pour le user d'apache.

            Ce qui est très souvent le cas pour les hébergement mutualisé (l'utilisateur d'upload étant celui d'apache).

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Blague?

          Posté par (page perso) . Évalué à -1. Dernière modification le 04/07/14 à 21:04.

          Mwé enfin c'est loin d'être le seul langage qui le permet…

          Mais quel autre langage le permet en pratique ?

          Dès que tu veux faire un site en Python, tout le monde va te conseiller de faire à la Django (même si c'est avec un autre framework), via wsgi ou gunicorn.

          Gné ? PHP a tant changé que ça depuis ma dernière utilisation? A mon époque (<= phrase de vieux con) fallait passer par une conf à la mimine dans un fichier texte. Tu confond pas un peu PHP et framework PHP / CMS basé sur PHP?

          J'ai installé récemment un Wordpress pour quelqu'un. Voilà toutes les manips que j'ai eu à faire :
          * prendre un hébergement, créer le nom de domaine,
          * créer une base de données en deux clics (le site de l'hébergeur me donne en échange les login/mots de passe/serveur MySQL)
          * uploader d'une façon ou d'une autre (par exemple FTP) le contenu de wordpress.zip
          * ouvrir l'URL http://mon.super.wordpress.fr/
          * donner les coordonnées du serveur MySQL et quelques infos supplémentaires avant de cliquer sur Next
          * Enjoy !

          Maintenant, pour installer des plugins, je vais sur la partie administration de Wordpress, je clique sur « Installer cette extension magique » et c'est tout. Pour mettre à jour Wordpress ou les extensions, je clique sur « Mettre à jour tout ce bazar ».

          Voilà ce que permet PHP. Comment fais-tu ça en Python + Django ? En tant qu'utilisateur, j'en ai rien à faire des arguments techniques comme quoi Python est mille fois mieux que PHP. Je veux simplement un truc qui fonctionne simplement parce que ce n'est pas moi qui m'en occuperai.

          • [^] # Re: Blague?

            Posté par . Évalué à 1. Dernière modification le 04/07/14 à 21:37.

            Tu as conscience que depuis le début on parle de LANGAGE? Ok donc tu mélanges tout language / CMS et framework. Ouch tu ne fais que confirmer mon avis sur certains utilisateurs de PHP …

            Du coup l'assembleur c'est super, parce que ça me permet de mettre à jour Windows en un clique … Hein ? Quoi? des "compilateurs" ? "langage" ? Non mais moi je m'en fout, ça "juste marche" donc j'ai raison :-)

            • [^] # Re: Blague?

              Posté par (page perso) . Évalué à 1. Dernière modification le 04/07/14 à 21:42.

              Mais donne-moi donc des exemples concrets ! je n'attends que ça ! En pratique, ces avantages sont liés au fait que PHP est interprété directement par Apache et qu'il peut écrire, contrairement à Python qui va plutôt être utilisé via mod_wsgi ou gunicorn.

              Alors, oui, tu peux théoriquement faire de l'interprétation de Python directement dans le HTML et tu peux sûrement faire du PHP dans un équivalent de mod_wsgi ou gunicorn, mais en pratique, ce n'est jamais le cas ; seul PHP le permet.

              • [^] # Re: Blague?

                Posté par . Évalué à 0. Dernière modification le 04/07/14 à 23:03.

                En admettant que je rentre dans ton jeux de mélanger les torchons et les serviettes … y a quoi qui m’empêche, à l'installation de lancer un python qui m'affiche une page pour générer le fichier de conf? Sans parler du fait qu'au pire modifier un fichier à la main… enfin bref

                Et puisque tu mélanges encore tout et que pour toi PHP est le seul à pouvoir le faire grâce au fait qu'il soit interpréter, je vais te prendre au moins un contre exemple concret : un cgi qui lit le fichier de conf comme le ferai PHP???

                Et de quoi tu me parle avec ton python interprété dans HTML ??? Bon fin de la discution ça mène à rien. Continue à bidouiller ton PHP dans ton coin, à ce niveau là je me dit juste que j'ai marché dans un troll (bien joué :p).

                • [^] # Re: Blague?

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

                  Ta réaction montre bien pourquoi PHP continuera à dominer le Web pour quelques temps encore.

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                • [^] # Re: Blague?

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

                  J'attends toujours tes exemples de sites web du même style que Wordpress (et modifier un fichier de conf à la main n'est pas envisageable) :) Si c'est si facile à faire, tu ne devrais pas avoir trop de mal à en trouver à la pelle. Personnellement, j'ai un peu cherché pour Django, je n'en ai trouvé aucun.

                  Accessoirement, pour faire du Django proprement, après avoir généré la conf, il faut encore choisir la bonne version de Python (je connais un certain nombre d'applis uniquement Python 3.3), installer les dépendances (via PIP ?), pouvoir relancer le service (apache + wsgi ou gunicorn + wsgi), et configurer Apache pour que certaines URL soient gérées par la partie Python et d'autres par Apache uniquement (les fichiers statiques). Mais je suis toujours intéressé par ta page magique qui me fait ça en un claquement de doigts :)

                  Si ça peut te rassurer, je ne bidouille pas du PHP, vu que je ne fais que du Python + Django quand je dois faire quelque chose qui ressemble à du web… mais ça ne m'empêche pas de reconnaître que pour mettre en place un site web facilement sans mettre les mains dans le cambouis, je ne connais que des sites en PHP. Ils vont avoir leurs défauts (genre impossible de faire autre chose que du MySQL dans 99% des cas), mais ils sont quand même 'hachement plus simples à mettre en œuvre.

                  • [^] # Re: Blague?

                    Posté par . Évalué à 1.

                    On mélange tout et n'importe quoi, langage, framework, utilisateur, admin, développeur…
                    Si tu veux un exemple, j'ai des clients sous windows pour des applis web, je leur livre un seul exe qui se met à jour et fait des sauvegardes tout seul.
                    Concernant les sites internet, si c'est un nouveau site, je vais sur une page web, clic nouveau site, je rentre le nom de domaine, le nom de l'appli et de la bdd. C'est tout. Pour les mises à jour : hg push prod, c'est tout.
                    Un plugin pour mon appli ? config.include('monplugin')
                    Tout ça en python et je ne fais franchement rien d'extraordinaire, avec des outils tout kiss python, pyramid, mercurial, supervisor, nginx, postgresql…

                    Tant qu'à tout mélanger : un exemple plus visible où tout se fait en quelques clics ? http://odoo.com

                    Ceci dit on a tous remarqué que les applis en php s'installent plus ou moins facilement avec le même genre de bidouillages. Mais ça n'a pas grand chose à voir avec le langage, c'est plus une habitude qu'autre chose. C'est l'environnement qui joue beaucoup, il a pas mal évolué en python ces dernières années avec wsgi, pypi et les frameworks web, mais le langage reste le même.

                    Je réitère ma question, est-ce que l'environnement a évolué du côté php à ce niveau où en est t-on toujours au même point avec un vulgaire zip foutoir et une config apache centralisée ?

                  • [^] # Re: Blague?

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

                    La liaison PHP <-> MySQL est de plus en plus faible, d'une part car les fonctions liées à MySQL sont désormais obsolètes, d'autre part les PDOStatements sont de plus en plus répandus et ne dépendent pas que d'une base de données.

                    Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

              • [^] # Re: Blague?

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

                En pratique, ces avantages sont liés au fait que PHP est interprété directement par Apache et qu'il peut écrire

                Gnnniii ?

                Je ne vois pas en quoi le fait que php soit en module apache ou en fastcgi ou en quoique soit d'autre changerai quelque chose à ce que tu dis.

                Ce que tu es en train de défendre, c'est qu'il existe des hébergements mutualisés proposant php et pas python.

                • [^] # Re: Blague?

                  Posté par . Évalué à 3.

                  Non je pense qu'il parle du fait qu'il n'y a pas de serveur spécifiques contrairement à Java par exemple.

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

      • [^] # Re: Blague?

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

        PHP a quelques autres avantages qui viennent du fait qu'il est interprété directement par Apache :
        * tu peux très facilement déployer un site en PHP (upload de l'archive, et zou, c'est parti)
        * tu peux tout configurer via le site-même (les coordonnées de la base MySQL, par exemple)
        * tu peux mettre à jour en un clic directement depuis le site
        * tu peux ajouter facilement des plugins

        Ce que tu décris n'a rien avoir avec le fait qu'il soit directement interprété par apache.

  • # Non je ne pleure pas

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

    J'en connais chez PHP qui doivent pleurer.

    Comme si faire du C# c'était le graal. Tu ne me fait pas pleurer, mais rire plutôt.

    Ce n'est pas parce que PHP traine encore des boulets syntaxiques ou d'interface de programmation, qu'il faut les utiliser. Le langage a énormément évolué ces dernières années.

    On peut coder très proprement en PHP. On peut faire du MVC très propre, ou tout ce que tu veux très propre. Ce n'est pas parce qu'il y a encore des scripts pourris fait par des débutants, que PHP nous oblige à coder comme des porcs. D'ailleurs, dans n'importe quel langage tu peux coder comme un porc.

    Bref, ce n'est pas parce maintenant on peut faire du C# MVC truc muche sous linux que je vais m'y mettre, encore moins si c'est pour faire plus "hype" ou pour crâner. Je pense que la majorité des dev PHP ont rien à battre de se que peuvent penser les autres sur PHP. Franchement, ceux qui se la pète parce qu'ils utilisent un langage soit-disant "plus pur", je leur ris au nez. (et je vais m’arrêter là sinon je vais commencer à dire des grossièretés).

    Le principal dans le développement, c'est de produire une appli qui marche, qui corresponde aux besoins demandés, et qui soit codée proprement pour être maintenable (et PHP n'empêche pas de faire tout ça). La technologie utilisée, on s'en tape.

Suivre le flux des commentaires

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