Publicité

Affichage des résultats du sondage: Si vous deviez choisir l'un de ces langages pour l'année 2009 ?

Votants
458. Vous ne pouvez pas participer à ce sondage.
  • PHP

    270 58,95%
  • Java

    188 41,05%
+ Répondre à la discussion Actualité déjà publiée
Page 9 sur 11 PremièrePremière ... 567891011 DernièreDernière
Affichage des résultats 161 à 180 sur 201
  1. #161
    Membre éclairé Avatar de FredPsy
    Homme Profil pro Frédéric BERTHORELLY
    Formateur en informatique
    Inscrit en
    décembre 2006
    Messages
    271
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BERTHORELLY
    Âge : 38
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Formateur en informatique
    Secteur : Administration - Collectivité locale

    Informations forums :
    Inscription : décembre 2006
    Messages : 271
    Points : 317
    Points
    317

    Par défaut

    Si on peut plus déconner.

    Et non même pas honte.
    "Dites moi ce dont vous avez besoin, je vous apprendrai à vous en passer".
    Et de grâce, je ne possède pas le plugin boule de cristal de firefox, alors soyez clair dans vos questions.

    Je lutte contre le language SMS.

  2. #162
    mon_nom_est_personne
    Invité(e)

    Par défaut

    de toute facon le futur c'est le turbo pascal ! (et dire qu'il y a 5 ans on faisait la meme avec javascript et tout le monde se marrer).

  3. #163
    Rédacteur
    Avatar de benwit
    Inscrit en
    septembre 2004
    Messages
    1 675
    Détails du profil
    Informations forums :
    Inscription : septembre 2004
    Messages : 1 675
    Points : 3 549
    Points
    3 549

    Par défaut

    Citation Envoyé par seb92400 Voir le message
    Il s'agissait de stats indiquant quels langages étaient utilisés de préférences pour la conception de sites web dynamiques (sites web, donc tout ce qui est intranet, applis persos, etc... non comptées). De mémoire, php était aux environs de 67-68%, asp 21-22, et le reste pour les autres langages dont java qui devait tourner aux environs de 7%.

    Ces chiffres datent un peu il est vrai, mais la balance ne s'est pas inversée du jour au lendemain. De toute façon, même si ces chiffres sont aujourd'hui erronés, il suffit de regarder par exemple les offres des hébergeurs, combien proposent un serveur java ?
    Hello,

    Je m'étonnais de ces chiffres car je fais le distinguo entre site web et appli web (bien que la frontière soit de + en + floue)

    Je veux bien croire que php soit plus utilisé pour les sites web.

    En revanche, dans le cadre d'applications web utilisées en interne dans les entreprises, même si je ne dispose pas de chiffres et que je m'appuie surtout sur mon expérience, je doute que la proportion soit celle indiquée.


    Tout le monde savait que c'était impossible. Il est venu un imbécile qui ne le savait pas et qui l'a fait. Marcel PAGNOL
    On ne savait pas que c'était impossible, alors on l'a fait. John Fitzgerald KENNEDY.
    L'inexpérience est ce qui permet à la jeunesse d'accomplir ce que la vieillesse sait impossible. Paul (Tristant) BERNARD
    La meilleure façon de prédire l'avenir, c'est de l'inventer.

  4. #164
    Membre habitué
    Inscrit en
    mars 2007
    Messages
    135
    Détails du profil
    Informations forums :
    Inscription : mars 2007
    Messages : 135
    Points : 112
    Points
    112

    Par défaut

    Citation Envoyé par FredPsy Voir le message
    Si on peut plus déconner.

    Et non même pas honte.
    lol, bien sur, mais je vais continuer dans mon rôle de vieu con aigri et demander de faire un client lourd en PHP ....

    merci

  5. #165
    Membre du Club
    Profil pro
    Inscrit en
    avril 2006
    Messages
    51
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : avril 2006
    Messages : 51
    Points : 64
    Points
    64

    Par défaut

    Ah ça me fait plaisir, je n'avais pas vu beaucoup de commentaires intéressants à lire coté PHP, et là vous sortez les armes lourdes avec de bons arguments!
    (Au cas ou! Pas d'ironie dans ce que je viens de dire, je pense vraiment que les derniers arguments étaient bons)

    @emmanuel.remy
    http://www.developpez.net/forums/d73...a/#post4778365
    Effectivement j'ai lu des posts qui franchissait la notion de langage pour aller taper directement dans l'architecture, ce n'est effectivement pas complètement le débat, même si je trouve que c'est bien d'avoir un coup d'œil à l'architecture étant donné que le choix à faire va influer sur l'architecture. Et je pense que c'est typiquement le sujet de parler de l'écosystème qui repose sur chaque langage.

    Je ne me considère pas comme un fanboy Java, même si à l'heure actuelle j'ai une position arrêtée (mais pas pas bloquée). En effet le monde évolue. Et je trouve ta proposition de faire fonctionner une appli PHP avec du Java comme réaliste, et pas gênante dans l'absolu tant que le rôle de PHP se cantonne à la partie client web et les quelques traitements afférents.

    Dans les faits cela pourrait se rapprocher de la notion de programmation polyglotte : chaque langage exprime ce pourquoi il est fait (HTML pour structurer une page, CSS pour styler, Scala pour la programmation fonctionnelle et autres paradigmes, Perl/groovy pour le scripting, SQL pour les données, etc...)
    D'ailleurs pourquoi pas faire du PHP et le faire tourner sur une JVM

    D'ailleurs en parlant de Groovy, non ce n'est pas complètement vrai, effectivement Groovy permet de bien simplifier le développement, d'éviter de la verbosité, mais on est quand même encadré par des normes et des spécifications Java si on en a besoin.

    @seb92400
    http://www.developpez.net/forums/d73...a/#post4777576
    Les retours que j'ai eu vont dans ce sens, les frameworks PHP sont plus dur à utiliser. Comme je l'ai dit je ne connais pas super bien l'écosystème PHP mais j'ai l'impression que nous avons un écosystème bien plus varié et mature que l'écosystème PHP.

    Pour ce qui est de mes déclarations sur les dev PHP, je reste sur mes positions ce que je dis c'est que la majorité des gens que j'ai vu sont plus light, ça ne veut pas dire que je n'ai jamais vu personne de bon, au contraire les gens qui sont bon font avancer les choses, et souvent c'est ceux qui participent aux projets/framework de qualité que les gens utilisent tous les jours. Étant donné que comme partout il y a des vilains petits canards, pour moi il s'agit d'une question de proportion, quand je vais recruter un gars j'ai plus de chance de tomber sur un gars suffisamment bon en Java qu'en PHP.

    Pour les tests de performance, tu as raison il faut garder une certaine distance, je ne sais pas si j'ai été assez explicite dans ce que j'ai écrit. Cela dit les écarts sont tout de même manifestement remarquable dans les tests de performance purs. Et lorsqu'on parle de problèmes de performance lié à la base de donnée, on tombe typiquement dans des problèmes d'architecture qui vont se poser quelque soit les technologies utilisées.

    http://www.developpez.net/forums/d73...a/#post4778853
    La dessus eh bien je n'ai presque rien à dire, à par sur tes remarque de marketing. En fait je pense que que c'est plus de la sémantique et de la taxonomie, si on ne sait pas de quoi on parle précisément, comment peut-on réfléchir proprement à certains concepts, à certains problèmes.

    Par exemple un POJO, ce n'est pas simplement un objet, ce terme vient du C++. En effet en C++ un objet est un concept qui a des données encapsulées et expose une API pour interagir dessus, mais ce n'était pas l'idéal pour faire de la persistance et communiquer avec d'autres systèmes. Est alors né l'idée de POD - Plain Old Data -, il s'agit là juste d'une structure.
    Le POJO suit la même idée c'est un objet qui ne contient que des données exposées à travers des getters et des setters (pour respecter les convention JavaBean). C'est différent d'un objet dans le sens original du terme qui cache sont état interne et qui fournit surtout une api pertinente par rapport à ses responsabilités.

    @mon_nom_est_personne
    http://www.developpez.net/forums/d73...a/#post4778010
    Pour le choix PHP ou Java, pour les raisons que j'ai mentionnées, je pense quand même que Java avance plus d'avantages que PHP, donc pour moi ce n'est pas kifkif. Mais je dirais que pour certains secteurs, Java se cherche encore.

    >> Conclusion, il n'y a pas de mauvais outils mais que des mauvais ouvriers comme on dit dans le nord.

    Je suis 100% d'accord, mais les outils peuvent limiter les dégâts, par exemple en Java pas d'héritage multiple on préfère la composition, il y a d'autres exemples. Les spécifications et les normes qui encadrent des gros projets peuvent nous aider. Évidement ça ne fait pas tout, on peut quand même faire de la merde même avec tout ces garde-fous. Bref comme dans toutes les entreprises (les normes de sécurités les chaussures renforcées, les capots sur les gros boutons rouges, les fenwick, etc... protègent mais ne suffisent pas).


    ____

    Finalement je ne dis pas qu'il ne faut rien faire en PHP, je ne me souviens pas avoir écrit ça, je dis que je préfèrerais Java/J2EE pour une belle panoplie de projet. Et c'est bien là le sujet du topic : Que choisir en 2009 : PHP ou Java ?
    Encore une fois PHP et Java ce ne sont pas que des langages, ce sont des écosystèmes battis sur ces langages. Si on choisi Java ou PHP alors on aura droit à tout un ensemble de framework et de compétences relatives à la techno choisie, c'est pour ça que c'est important de parler des framework et même de jeter un coup d'œil à l'architecture! En effet les frameworks Java et probablement PHP aussi intègrent, supportent, proposent une/des architecture(s), et juste ignorer ça c'est ne pas abordé une partie de la problématique.

    Également je ne suis pas d'accord sur le fait que les partisans Java n'aurait pas dis quels étaient les choses PHP ne pouvait pas faire; plein de points abordés sur le Java n'ont simplement pas été relevé du coté des défenseurs de PHP. Ou alors j'ai des pots de saucissons devant les yeux (c'est possible).
    En voici quelques uns, probablement pas une liste exhaustive cela dit:

    # L'AOP est au mieux dérisoire, même si elle existe.
    # JTA, ce n'est pas de la persistance mais une API de transaction, ce genre de chose va beaucoup plus loin que la transaction gérée sur un appel, c'est aussi de la gestion de transaction distribuée.
    # JPA effectivement qui permet de fournir une abstraction sur les framework d'ORM, en PHP vous avez Doctrine, mais à ce que je sais vous avez un couplage fort sur ce framework.
    # Spring, framework d'IoC, en PHP vous avez plusieurs choix, mais bon rien d'aussi mature d'après ce que j'ai entendu.
    # JCA, Java Connector Architecture, afin de créer des connecteurs propres à des systèmes legacy, des mainframes, ou autre
    # JMX, l'extension de Java pour managé des bean à distance, la je ne sais pas, qu'y-t-il en Java pour ça?
    # OSGI, c'est formidable OSGI (voir JSR 8), mais qu'en est-il en PHP.
    # Le temps réel, en Java on a RTSJ (c'est la JSR 1), les systèmes financiers utilisent tous ou presque des systèmes temps réel.
    # La JVM, une véritable force, elle permet de faire tourner plein de langage plus ou moins dérivié, Scala, Erlang, Haskell, Java, Groovy, PHP!, etc...
    # Le système de classloader, qui est difficile mais utilisé correctement permet de faire de l'isolation, d'avoir des "namespaces", de donner de la visibilité, d'améliorer des performances.
    # Cluster, dans le monde Java on a des cluster qui permettent un véritable management de serveurs, pour la configuration, pour le déploiement, pour la sécurité, pour le load balancing. Apache est vraiment très très bien pour ce qu'il propose mais il est plus que limité dès qu'on veut faire du clustering au sens large. Je peux aussi citer le projet Hadoop à ce sujet.
    # Maven, formidable outils de gestion de dépendance, de compilation et de packaging, j'ai entendu parlé d'un php like, mais qui reste sous utilisé et peu mature.

    Alors oui dans le monde Java, comme ailleurs il y a eu des âneries et il y en aura encore, comme les JSP ou les EJB 2, mais généralement ces âneries ne sont pas longtemps utilisées.

    J'ai lu souvent, la version PHP 6 va changer la donne, pour quoi pas! J'ai aussi entendu ça pour PHP 5. Mais bon depuis longtemps en Java on a plein de chose, qui on eut le temps de murir. D'autres approches au développement sont régulièrement proposées, je pense au scripting et au frameworks web. Et pour ça encore je choisirait Java.

    Évidement j'aborde des sujets d'architecture ici, mais c'est bien parce que ces sujets sont traités par l'écosystème Java que j'en parle. Et c'est aussi parce que l'écosystème Java traite assez en profondeur de l'ensemble de ces questions de développement, de cycle de vie, d'architecture voire d'urbanisme, que j'émets mon choix pour Java.

    Encore une fois ce choix repose sur l'état actuel de mes connaissances et de l'état de l'art en 2009!

    [EDIT : Corrections orthographiques et grammaticales]

  6. #166
    Membre Expert
    Inscrit en
    septembre 2007
    Messages
    955
    Détails du profil
    Informations forums :
    Inscription : septembre 2007
    Messages : 955
    Points : 1 068
    Points
    1 068

    Par défaut

    Citation Envoyé par TheNOHDirector Voir le message
    Ah ça me fait plaisir, je n'avais pas vu beaucoup de commentaires intéressants à lire coté PHP, et là vous sortez les armes lourdes avec de bons arguments!
    (Au cas ou! Pas d'ironie dans ce que je viens de dire, je pense vraiment que les derniers arguments étaient bons)
    Tes commentaires sont plutot équilibrés. C'est intéressant car tu apportes des arguments beaucoup plus pertinents que la moyenne des membres. J'apprécie aussi le fait que tu utilises le conditionnel sur des sujets que tu ne maitrises pas totalement.

    Citation Envoyé par TheNOHDirector Voir le message
    Les retours que j'ai eu vont dans ce sens, les frameworks PHP sont plus dur à utiliser. Comme je l'ai dit je ne connais pas super bien l'écosystème PHP mais
    j'ai l'impression que nous avons un écosystème bien plus varié et mature que l'écosystème PHP.
    C'est difficile a dire car on peut tout faire ou presque en PHP dans un environnement Web. Je dirais que l'écosyteme Java est plus abouti car le systeme est plus ancien.
    Non les frameworks PHP ne sont pas plus dur a utiliser bien au contraire. De plus on ne peut pas dire les Frameworks PHP car Symfony, CodeIgniter, CakePHP ou ZendFramework pour ne citer qu'eux ne s'utilisent pas de la même façon. Les differences entre tous ces Frameworks peuvent être grandes meme si on y retrouve les memes patrons de conception.
    En ce qui concerne Java la configuration de Struts par exemple via un fichier XML est bien plus complexe.
    Struts n'est pas une exception de nombreuses libraries requierent un configuration via des fichiers xml plus ou moins complexes avant de les utiliser.
    Autre point important le PHP est fourni de base avec une miriade de fonctions, de classes et de librairies, je peux developper un projet complet sans installer un seul composant externe. C'est aussi son talon d'Achille sa simplicité l'a ouvert à des développeurs en herbe qui font beaucoup parler d'eux.

    Pour ce qui est de mes déclarations sur les dev PHP, je reste sur mes positions ce que je dis c'est que la majorité des gens que j'ai vu sont plus light,
    ça ne veut pas dire que je n'ai jamais vu personne de bon, au contraire les gens qui sont bon font avancer les choses, et souvent c'est ceux qui participent aux projets/framework de qualité que les gens utilisent tous les jours. Étant donné que comme partout il y a des vilains petits canards, pour moi il s'agit d'une question de proportion, quand je vais recruter un gars j'ai plus de chance de tomber sur un gars suffisamment bon en Java qu'en PHP.
    C'est un peu caricaturale, normalement un bon développeur peut manipuler n'importe quel langage. Faut-il lui laisser du temps. Les développeurs Java sont peut etre meilleurs car l'écosystème Java t'impose très rapidement des règles de programmation, ce qui est une très bonne chose cela dit en passant. En PHP la liberté est bien plus grande donc tu trouveras mécaniquement plus de développeurs qui n'ont pas encore abordés certaines méthodologies de travail.
    Cela dit j'ai l'impression qu'un bon développeur Java se contentera d'utiliser les librairies et tous les outils que "le monde Java" met a sa disposition.
    Un bon développeur PHP devra dépasser le périmètre du langage PHP. C'est fréquent pour un bon développeur PHP d'être impliqué dans tous les sujets transverses tel que la configuration des serveurs, l'optimisation des requêtes SQL ou le choix des librairies tiers...

    Pour le choix PHP ou Java, pour les raisons que j'ai mentionnées, je pense quand même que Java avance plus d'avantages que PHP, donc pour moi ce n'est pas kifkif. Mais je dirais que pour certains secteurs, Java se cherche encore.
    Voici le nerf de la guerre. Il faut regarder de pres chaque projet car je suis sur que PHP peut etre dans certains cas une meilleur réponse que Java. Je l'ai dit plusieurs fois oui les librairies Java peuvent avoir des mecanismes que PHP n'a pas mais je dois réaliser un magasin en ligne, un reseau social ou un intranet d'entreprise. Le choix n'est pas si évident que cela. Ce n'est certainement pas comme le pense certains personnes: Si tu veux une appli robuste prends Java. Garde le PHP pour les "petits" projets.
    Java et ses libraries c'est une sorte de camion 38 tonnes que tu es obligé de prendre meme pour aller chercher une baguette chez ton boulanger. C'est vraiment tres tres lourd (Je ne parle pas des performances). C'est un argument que j'entends souvent avec Java tu peux tout faire car il dispose de nombreuses librairies mais avec Java je sors le 38 tonnes meme pour la creation d'un blog car j'ai minimum besoin de JDBC et d'un conteneur web.
    De grandes compagnies font des projets en PHP et pas des petits projets. PHP étant fortement lié au WEB il dispose de classes, de functions et des composants qui facilitent le developpement de projet Web.

    Je pose toujours la même question: quel est le projet que PHP ne serait pas faire?

    Également je ne suis pas d'accord sur le fait que les partisans Java n'aurait pas dis quels étaient les choses PHP ne pouvait pas faire; plein de points abordés sur le Java n'ont simplement pas été relevé du coté des défenseurs de PHP. Ou alors j'ai des pots de saucissons devant les yeux (c'est possible).
    En voici quelques uns, probablement pas une liste exhaustive cela dit:
    La ca ce complique parceque comme l'a souligné seb92400, le jargon Java fait que ca peut exister en PHP et qu'il n'est pas l'emballage "marketing". Cela dit oui c'est possible que PHP n'est pas une fonctionalité. Apres est-ce que c'est un truc exotique réservé aux applications pour salle de marché ou une fonctionnalité de base?
    J'en sais rien mon experience m'a montré que tout est faisable en PHP mais le cout peut etre élevé quand ce n'est pas standard.
    Il faut regarder au cas par cas.

    # L'AOP est au mieux dérisoire, même si elle existe
    # JTA, ce n'est pas de la persistance mais une API de transaction, ce genre de chose va beaucoup plus loin que la transaction gérée sur un appel, c'est aussi de la gestion de transaction distribuée.
    # JPA effectivement qui permet de fournir une abstraction sur les framework d'ORM, en PHP vous avez Doctrine, mais à ce que je sais vous avez un couplage fort sur ce framework.
    # Spring, framework d'IoC, en PHP vous avez plusieurs choix, mais bon rien d'aussi mature d'après ce que j'ai entendu.
    # JCA, Java Connector Architecture, afin de créer des connecteurs propres à des systèmes legacy, des mainframes, ou autre
    # JMX, l'extension de Java pour managé des bean à distance, la je ne sais pas, qu'y-t-il en Java pour ça?
    # OSGI, c'est formidable OSGI (voir JSR 8), mais qu'en est-il en PHP.
    # Le temps réel, en Java on a RTSJ (c'est la JSR 1), les systèmes financiers utilisent tous ou presque des systèmes temps réel.
    - Je n'y crois pas trop au temps réel pour des applications WEB, parles-tu de client lourd?

    # La JVM, une véritable force, elle permet de faire tourner plein de langage plus ou moins dérivié, Scala, Erlang, Haskell, Java, Groovy, PHP!, etc...
    - PHP fonctionne plutot par bridge ou part appel externe, il n'y a pas de PVM.

    # Le système de classloader, qui est difficile mais utilisé correctement permet de faire de l'isolation, d'avoir des "namespaces", de donner de la visibilité, d'améliorer des performances.
    # Cluster, dans le monde Java on a des cluster qui permettent un véritable management de serveurs, pour la configuration, pour le déploiement, pour la sécurité, pour le load balancing. Apache est vraiment très très bien pour ce qu'il propose mais il est plus que limité dès qu'on veut faire du clustering au sens large. Je peux aussi citer le projet Hadoop à ce sujet.
    - Le clustering pour moi n'est pas lié au language a moins que tu parles d'un truc que je ne connaisse pas du tout.

    # Maven, formidable outils de gestion de dépendance, de compilation et de packaging, j'ai entendu parlé d'un php like, mais qui reste sous utilisé et peu mature.
    - Dans le monde Java un outil comme Maven peut-être essentiel mais en PHP il n'y a pas de compilation et pas de packaging (les .phar équivalent des .jar arrive avec php 5.3) C'est du scripting
    Je souhaiterais te répondre précisément sur chaque point mais il faudra que décrives le concept plutôt que de mentionner le nom des librairies car je ne connais pas tout le lexique Java.
    Je trouve aussi que ce que tu décris est lié à une façon de penser l'informatique. Ce sont des solutions élaborées pour un situation données voir même pour Java.
    Exemple la JVM c'est pas du tout la philosophie de PHP donc tu ne trouveras cette façon de faire en revanche tu trouveras des solutions équivalentes.
    Avec PHP on compile ou on installe les binaires des modules que l'on souhaite intégrer au langage, il n'y a pas de boite a tout faire comme la JVM.

    Évidement j'aborde des sujets d'architecture ici, mais c'est bien parce que ces sujets sont traités par l'écosystème Java que j'en parle.
    Et c'est aussi parce que l'écosystème Java traite assez en profondeur de l'ensemble de ces questions de développement, de cycle de vie, d'architecture voire d'urbanisme, que j'émets mon choix pour Java.
    Il faut vraiment regarder de près le projet avant de choisir une architecture. De plus la philosophie de Java c'est de tout intégrer là où PHP va plutôt utiliser des briques externes.
    J'en profite pour faire une petite digression philosophique. Je suis fervent supporter des langages a script je pense que c'est une délivrance pour le développeur.
    Je soutiens tous ce qui va dans ce sens Ruby, Python, Php je suis prêt a basculer sur n'importe quel langage qui gagnerait en puissance et en simplicité.

    Encore une fois ce choix repose sur l'état actuel de mes connaissances et de l'état de l'art en 2009!
    Pareil

    Je m'excuse je n'ai pas pu répondre sur tous tes points car ton message était très long mais je le ferais volontiers un peu plus tard

  7. #167
    Membre du Club
    Profil pro
    Inscrit en
    avril 2006
    Messages
    51
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : avril 2006
    Messages : 51
    Points : 64
    Points
    64

    Par défaut

    Citation Envoyé par batataw Voir le message
    Tes commentaires sont plutot équilibrés. C'est intéressant car tu apportes des arguments beaucoup plus pertinents que la moyenne des membres. J'apprécie aussi le fait que tu utilises le conditionnel sur des sujets que tu ne maitrises pas totalement.
    Merci, les tiens aussi, évidement d'autres défenseurs de PHP sont dans ton cas

    A propos des framework, c'est ce qu'on m'a rapporté, mais effectivement entre tel ou tel framework il y a des différences. Par exemple pour les framework de bouchonage pour les TU tel que Easymock ou Mockito, la philosophie est la même, sauf que l'api est mieux pensée chez Mockito.

    Citation Envoyé par batataw Voir le message
    En ce qui concerne Java la configuration de Struts par exemple via un fichier XML est bien plus complexe.
    Struts n'est pas une exception de nombreuses libraries requierent un configuration via des fichiers xml plus ou moins complexes avant de les utiliser.
    Indeed, ça fait quelques années que je n'aime plus trop struts, il ya d'autres framework assez sympa, qui sont plus facile à utiliser, le crédo en ce moment c'est: Convention over Configuration.

    Citation Envoyé par batataw Voir le message
    Autre point important le PHP est fourni de base avec une miriade de fonctions, de classes et de librairies, je peux developper un projet complet sans installer un seul composant externe. C'est aussi son talon d'Achille sa simplicité l'a ouvert à des développeurs en herbe qui font beaucoup parler d'eux.
    Il y a plein de chose dans l'API standard de Java aussi, il y a la partie serveur en plus, mais ç'est juste que ce qui est standard est plutôt très standard, comme à l'époque la librairie standard C.


    Citation Envoyé par batataw Voir le message
    C'est un peu caricaturale, normalement un bon développeur peut manipuler n'importe quel langage. Faut-il lui laisser du temps. Les développeurs Java sont peut etre meilleurs car l'écosystème Java t'impose très rapidement des règles de programmation, ce qui est une très bonne chose cela dit en passant. En PHP la liberté est bien plus grande donc tu trouveras mécaniquement plus de développeurs qui n'ont pas encore abordés certaines méthodologies de travail.
    Cela dit j'ai l'impression qu'un bon développeur Java se contentera d'utiliser les librairies et tous les outils que "le monde Java" met a sa disposition.
    Un bon développeur PHP devra dépasser le périmètre du langage PHP. C'est fréquent pour un bon développeur PHP d'être impliqué dans tous les sujets transverses tel que la configuration des serveurs, l'optimisation des requêtes SQL ou le choix des librairies tiers...
    Je suis d'accord, un développeur doit pouvoir étendre son périmètre de connaissance, à ma grande déception, ce n'est pas toujours le cas. Comme je l'ai dit il y a des vilain petits canards partout. Celà dit suivant les projets de 300j/h à par ex 10000 j/h, les responsabilités des gens peuvent changée pour être bien définies, et là on ne confie pas forcement la responsabilité de la base à un développeur. La base de données demande des connaissances plus précise que pour du développement standard, et ça tout le monde ne l'a pas, là ou je bosse je connais 2 personnes qui sont talentueuses en Java et en Oracle, ce sont des personnes rares.


    Citation Envoyé par batataw Voir le message
    Voici le nerf de la guerre. Il faut regarder de pres chaque projet car je suis sur que PHP peut etre dans certains cas une meilleur réponse que Java. Je l'ai dit plusieurs fois oui les librairies Java peuvent avoir des mecanismes que PHP n'a pas mais je dois réaliser un magasin en ligne, un reseau social ou un intranet d'entreprise. Le choix n'est pas si évident que cela. Ce n'est certainement pas comme le pense certains personnes: Si tu veux une appli robuste prends Java. Garde le PHP pour les "petits" projets.
    Effectivement, tu me fais réaliser que je n'aurais pas du dire ça en ces termes, "petit" n'est pas le terme approprié. Comme je l'ai dit plus haut Digg est en PHP, et d'autres "Grand" sites sont en également codé en PHP, avec leur criticité qui leur sont propre.


    Citation Envoyé par batataw Voir le message
    Java et ses libraires c'est une sorte de camion 38 tonnes que tu es obligé de prendre même pour aller chercher une baguette chez ton boulanger. C'est vraiment très très lourd (Je ne parle pas des performances). C'est un argument que j'entends souvent avec Java tu peux tout faire car il dispose de nombreuses librairies mais avec Java je sors le 38 tonnes même pour la création d'un blog car j'ai minimum besoin de JDBC et d'un conteneur web.
    Je suis globalement d'accord, mais il y a quelques frameworks assez petit. Et encore pire il y a recouvrement de certaines fonctionnalités dans les dépendances importées. Cela dit le ClassLoader de la JVM ne chargera que les classe effectivement utilisées.

    Citation Envoyé par batataw Voir le message
    De grandes compagnies font des projets en PHP et pas des petits projets. PHP étant fortement lié au WEB il dispose de classes, de functions et des composants qui facilitent le développement de projet Web.
    100% d'accord, mais en Java aussi.

    Citation Envoyé par batataw Voir le message
    Je pose toujours la même question: quel est le projet que PHP ne serait pas faire?
    PHP offre plein de chose pour le Web, et j'ai du mal à ne pas avoir de réserve, mais le plus de Java c'est aussi dans tout ce qui n'est pas web qu'il fait à mon sens la différence. Plus précisément il se distingue sur des tiers purement métier ou dans des middlewares de grands systèmes informatiques.
    Et puis par ce que j'ai cité dans mes posts plus haut, les frameworks et les spécifications abordent des secteurs technique variés sur l'ensemble de l'architecture, sur l'ensemble du SI. Cela dit je ne suis pas pour du 100% Java.
    D'ailleurs je l'ai déjà dit, ça ne me gène pas d'avoir un client Web PHP, et des tiers métier en Java ou dotNet. Ça rejoint un peu mes pensées sur la programmation polyglotte.

    Mais si je suis décideur, j'ai un projet qui demande une certaine architecture, je choisi Java. Parce que je sais que l'écosystème Java a quelque chose qui peut m'aider là dessus, parce que si je prends des gars en Java ils peuvent s'en sortir à peu près sur tout les secteurs ou l'écosystème Java est, pas besoin de compétences variées. Évidement c'est prendre avec des pincettes parce que c'est plus compliqué dans la vraie vie, parceque c'est quand même bien de ne pas vivre dans son monde purement Java, il faut être conscient des problèmes qu'il peut y avoir en dehors de l'appli.

    Si je choisi PHP, et bien pour certains aspects du SI ou de l'architecture, j'aurais un support limité ou absent. Dans les faits la plupart des projets que je connais ou le PHP est présent c'est uniquement pour le tiers présentation, donc web. Forcement j'ai entendu du bien et du moins bien de projets comme EzPublish, Drupal, WordPresse, Zend, Symphony etc, mais ces framework sont tous pour la plupart très orienté web. Je ne connais pas de framework de logging très avancés comme log4j/logback, de monitoring (ça peut se faire en JMX), de messaging... Encore une fois c'est d'après ce que je sais.
    Comme tu le disais je sais qu'un développeur PHP sera plus impliqué dans d'autres domaines que l'application elle même, ça peut être plus mais pas tout le temps!

    Citation Envoyé par batataw Voir le message
    La ca ce complique parceque comme l'a souligné seb92400, le jargon Java fait que ca peut exister en PHP et qu'il n'est pas l'emballage "marketing". Cela dit oui c'est possible que PHP n'est pas une fonctionalité. Apres est-ce que c'est un truc exotique réservé aux applications pour salle de marché ou une fonctionnalité de base?
    J'en sais rien mon experience m'a montré que tout est faisable en PHP mais le cout peut etre élevé quand ce n'est pas standard.
    Il faut regarder au cas par cas.
    Je ne suis pas d'accord sur l'emballage marketing, comme je l'ai dit c'est plus une question de sémantique et de taxonomie. Si on ne sais pas précisément de quoi on parle, qu'est-ce que ça signifie, qu'est-ce que ca implique, alors on ne peut pas adresser correctement, proprement, rapidement un problème. Ce genre de vocabulaire peut cela dit aider l'écosytème Java pour indiquer que des problématiques sont traitées.
    Sinon en salle de marché d'après ce qu'un collègue me disait, il y a des choses exotiques, mais il y a plein de choses complètement standards!


    Citation Envoyé par batataw Voir le message
    Je souhaiterais te répondre précisément sur chaque point mais il faudra que décrives le concept plutôt que de mentionner le nom des librairies car je ne connais pas tout le lexique Java.
    Je trouve aussi que ce que tu décris est lié à une façon de penser l'informatique. Ce sont des solutions élaborées pour un situation données voir même pour Java.
    Pour RTSJ je suis d'accord, le temps réel tout le monde n'en a pas besoin. Mais c'est standardisé, si certains projets en on le besoin. Comme je l'ai dit, l'écosystème Java couvre un large éventail de besoins techniques dans des domaines très variés, tout n'est pas rose non plus, mais c'est pour ça que les langages et leur écosystèmes évoluent.
    Pour PHP, il y a bien des projets qui émulent complètement PHP. http://www.caucho.com/resin-3.0/quercus/index.xtp

    Pour le temps réel, il faut bien comprendre la définition de temps réel en informatique: Le temps réel c'est la réalisation d'une opération en un temps donné, par exemple si on dit que le service prends au maximum 1min alors le service a une minute pour répondre, si le délai est dépassé c'est une erreur grave. On retrouve ces systèmes dans le nucléaire, dans l'aéronautique et dans la finance, évidement cette liste est non exhaustive. Là il ne s'agit plus uniquement de Web, mais d'un système complet, chaque brique du SI a des contraintes en temps. Évidement c'est coté serveur, mais ce n'est pas impossible de faire du temps réel sur un client lourd.

    2-3 trucs pour mieux expliquer les technos citées.
    # AOP, Aspect Oriented Programming, tu dois certainement connaitre, parfois l'OOP n'est pas assez souple pour faire des bonnes conceptions, les aspect viennent aider. Avec ce paradigme tu peux créer des aspects avec leur responsabilités, et ses aspects seront "tissés" dans le code des objets métier pour ajouter leur responsabilités. De cette façon tu peux séparer des responsabilités métier de tes objets des responsabilités plus technique comme la sécurité, le monitoring, les logs, les transactions, etc... Évidement on peut mettre n'importe quoi dans les aspects, du code métier peut avoir une bonne raison de s'y trouver.
    # JCA, Java Connector Architecture, c'est une partie de la spécification J2EE pour résoudre des problèmes d'intégration avec d'autres systèmes, c'est assez courant que des entreprises aient encore de vieux mainframes, ou des systèmes complètement exotiques dont il ne veulent pas se séparer. Et plutôt que de tout refaire ce qui couterait une vraie fortune! Ils préfèrent coder à coté une appli moderne qui se connectera au vieux système. Et l'architecture d'un composant JCA permet de faire ça de manière propre. C'est un peu comme un driver base de donnée, d'ailleurs un driver JDBC a la même architecture qu'un driver JCA. JCA permet de gérer plein de chose, comme le pooling, le cycle de vie, les transactions, la sécurité, etc.
    # JMX, Java Management eXtension, c'est un système pour exposer des objets qui vont contenir des propriétés, il est possible de modifier dynamiquement ces propriétés pour changer le comportement de l'application.
    C'est très pratique si en production on a besoin d'activer des parties de l'application, mais évidement JMX ne se limite pas à ça.
    # OSGi, Open Service Gateway initiative, c'est une spécification basé sur un framework, qui permet de gérer les modules de manière distante, avec registre de service, gestion du cycle de vie du module, de l'application, des environnement d'exécution isolé. Ca veut dire que au runtime je peux installer des modules dans une version supérieure, je peux revenir en arrière, je peux gérer finement les versions de mes modules et de leur API, c'est très important quand on a une application qui est là pour 10-20ans! Évidement la sécurité est prise en compte. Et naturellement des services sont présent par défaut. OSGi est utilisé sur les mobiles avec Java, sur les clients lourds (ex: Eclipse), les serveurs.

    Si j'aborde les clusters, c'est bien parce que l'écosystème Java offre déjà des librairies pour supporter ce genre d'architecture. Je pense qu'il faut en parler, on est pas tout seul dans son coin avec la librairie standard pour faire des choses un peu compliquées. Évidement on parle architecture et tout les projets n'ont pas besoin de cluster, encore heureux!

    Citation Envoyé par batataw Voir le message
    Exemple la JVM c'est pas du tout la philosophie de PHP donc tu ne trouveras cette façon de faire en revanche tu trouveras des solutions équivalentes.
    Avec PHP on compile ou on installe les binaires des modules que l'on souhaite intégrer au langage, il n'y a pas de boite a tout faire comme la JVM.
    Effectivement, et puis pas besoin d'installer des librairies pour les utiliser, j'apprécie ce coté assez dynamique de la JVM.


    Citation Envoyé par batataw Voir le message
    Il faut vraiment regarder de près le projet avant de choisir une architecture.
    Indeed!

    Citation Envoyé par batataw Voir le message
    De plus la philosophie de Java c'est de tout intégrer là où PHP va plutôt utiliser des briques externes.
    Là je ne suis pas complètement d'accord, il s'agit de décision d'architecture, sur un petit projet peut-être que tout est vaguement intégré, mais sur des gros projets, on urbanise un minimum. On sépare les responsabilités des applications, on sépare les machines s'il le faut. Dans les faits ce n'est plus que du Java ou son écosystème (même si un support prononcé est présent), mais tu peux avoir des frontaux web, avec derrière un ou plusieurs tiers métier, et puis pourquoi pas un middleware pour communiquer ailleurs, ou alors un vieux système tout moche, sans parler de BDD (toutes les applis ne sont pas basées sur une BDD). Ensuite suivant ton archi tu peux mettre des machines et applications ni Java ni PHP qui ont des responsabilités bien spécifiques, je pense à Memcached ou TokyoCabinet (très très gros plus à cette appli d'ailleurs), ou encore à un serveur de lock distribué comme Zookeeper, et d'autres encore.

    Citation Envoyé par batataw Voir le message
    J'en profite pour faire une petite digression philosophique. Je suis fervent supporter des langages a script je pense que c'est une délivrance pour le développeur.
    Je soutiens tous ce qui va dans ce sens Ruby, Python, Php je suis prêt a basculer sur n'importe quel langage qui gagnerait en puissance et en simplicité.
    Oui, et, non:
    Oui parce que je trouve vraiment que le script est pas mal du tout dans certains cas, et la simplicité de certaines choses sont assez plaisante.
    Non parce que les script sont rarement bien maintenable. Et en script comme le but est d'aller vite on peut vite faire de la merde, et, 1 ans après quand il faut retoucher telle partie du script et que la doc et la conception ne sont pas géniales, on est vite plus embêté que dans un langage plus encadré.


    Citation Envoyé par batataw Voir le message
    Je m'excuse je n'ai pas pu répondre sur tous tes points car ton message était très long mais je le ferais volontiers un peu plus tard
    Pas de soucis. Un post réfléchi et de qualité demande du temps. Et j'avoue que j'ai pris beaucoup de temps à écrire ces derniers messages, mais c'est aux lecteurs d'en juger la qualité

  8. #168
    Membre du Club
    Profil pro
    Inscrit en
    avril 2006
    Messages
    51
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : avril 2006
    Messages : 51
    Points : 64
    Points
    64

    Par défaut

    Ah tiens j'oubliais aussi l'API de concurrence, l'api de Doug Lea qui a été intégrée dans l'API standard il y a quelques années maintenant est une référence. Avec une gestion assez fine des lock, et des objets soumis à la concurrence d'accès.
    Dans l'ère du multiprocesseur multicore, le parallélisme a vraiment sont importance. Je conseille d'ailleurs d'être au courant des principes et des lois relatives à ce sujet, je pense par exemple à la loi d'Amdahl.

    En Java j'ai régulièrement vu des traitements parallélisés dans des applications métier, ou encore certaines tâches potentiellement bloquantes qui sont rendu asynchrone, en dehors du thread courant.
    D'ailleurs j'ouvre une parenthèse sur JMS, Java Messagin Service, qui permet d'envoyer des messages de manière asynchrone sans bloquer le thread qui envoie ces messages, l'application qui les reçoit va faire dépiler la liste des messages pour les traiter quand elle a le temps. Ces applications sont des MOM, Message Oriented Middleware, c'est fiable, on peut faire du routage, on peut persister les messages, et évidement Java à un très bon support de ce type d'architecture. Parenthèse fermée.

    Il me semble que en PHP, c'est plutôt très limité de ce coté là, il me semble qu'il est juste question de fork/join de process (c'est beaucoup moins fin qu'une thread). Cela dit avec ça on peut quand même déjà faire du parallélisme!

  9. #169
    Membre Expert
    Inscrit en
    septembre 2007
    Messages
    955
    Détails du profil
    Informations forums :
    Inscription : septembre 2007
    Messages : 955
    Points : 1 068
    Points
    1 068

    Par défaut

    J'ai lu attentivement tes commentaires. Ils sont toujours aussi riches...Cependant j'ai noté une petite confusion.
    Reprends moi si je me trompe.
    Parfois les thématiques que tu abordes sont réservées aux clients lourds ou au langage a opcode (JVM).
    PHP est un langage a script, certains mecanismes ne peuvent pas etre appliqué. De plus son écosysteme est orienté WEB.
    Il excellera si tu restes dans cet environnement. Il ne pourra pas concurrencer JAVA sur des problématiques
    client lourds. Il vaut mieux les comparer en restant sur dans un environnement client leger.

    PHP offre plein de chose pour le Web, et j'ai du mal à ne pas avoir de réserve, mais le plus de Java c'est
    aussi dans tout ce qui n'est pas web qu'il fait à mon sens la différence. Plus précisément il se distingue
    sur des tiers purement métier ou dans des middlewares de grands systèmes informatiques.
    Effectivement PHP a été pensé pour le WEB. Si tu veux dépasser ce cadre ca peut devenir vite compliqué.
    Le middleware c'est pas son point fort.

    Mais si je suis décideur, j'ai un projet qui demande une certaine architecture, je choisi Java.
    Parce que je sais que l'écosystème Java a quelque chose qui peut m'aider là dessus, parce que si je prends
    des gars en Java ils peuvent s'en sortir à peu près sur tout les secteurs ou l'écosystème Java est, pas
    besoin de compétences variées. Évidement c'est prendre avec des pincettes parce que c'est plus compliqué
    dans la vraie vie, parceque c'est quand même bien de ne pas vivre dans son monde purement Java,
    il faut être conscient des problèmes qu'il peut y avoir en dehors de l'appli.
    Si je dois choisir un seul language et ne plus en bouger je prendrais automatiquement
    le plus riche (JAVA, .NET, C++...) Celui qui couvrira a coup sur tous les domaines.
    Cela dit une architecture se choisit en fonction d'un projet au sens large (avantages, cout, ressources, delai, pérénité...).
    Je crois qu'il y a de la place pour tous et pour tout, c'est vraiment au cas par cas.


    parce que si je prends des gars en Java ils peuvent s'en sortir à peu près sur tout les secteurs ou l'écosystème Java est, pas
    besoin de compétences variées
    Il faudra que tu m'expliques car c'est un des gros différent que j'ai avec Java.
    Si tu veux t'occuper du Front-end il te faut développer des compétences Frontend, JSF, JSP, GWT, Tiles...
    Au niveau du backend il faut connaitre, Spring, Struts...
    Pour la base de données JDBC est indispensable ou bien Hibernate...
    Pour le deploiment ANT ou Maven.
    Sans parler de la plétore de fichiers XML a configurer pour utiliser tout ce beau monde.

    Si je choisi PHP, et bien pour certains aspects du SI ou de l'architecture, j'aurais un support limité ou absent.
    Dans les faits la plupart des projets que je connais ou le PHP est présent c'est uniquement pour le tiers
    présentation, donc web.
    Pour un projet WEB je ne pense pas que le support est limité. On peut tout faire avec PHP.
    La partie présentation est une petite partie d'un Framework comme Symfony ou Zend. Ils font bien plus que cela.

    Forcement j'ai entendu du bien et du moins bien de projets comme EzPublish, Drupal, WordPresse, Zend, Symphony etc, mais ces framework sont tous pour la plupart très orienté web. Je ne connais pas de framework de logging très avancés comme log4j/logback, de monitoring (ça peut se faire en JMX), de messaging... Encore une fois c'est d'après ce que je sais.
    Comme tu le disais je sais qu'un développeur PHP sera plus impliqué dans d'autres domaines que l'application elle même, ça peut être plus mais pas tout le temps!
    EzPublish, Drupal, WordPress...huuummm ce sont d'excellents projets mais ils masquent les capacités de PHP car ils font avant tout de la publication. Il existe des projets d'une autre nature comme SugarCRM, Magento (Ecommerce), WebERP...
    Les projets sur lequels j'ai travaillés sont en majorité des extranets.

    Pour le temps réel, il faut bien comprendre la définition de temps réel en informatique: Le temps réel c'est la réalisation d'une opération en un temps donné, par exemple si on dit que le service prends au maximum 1min alors le service a une minute pour répondre, si le délai est dépassé c'est une erreur grave. On retrouve ces systèmes dans le nucléaire, dans l'aéronautique et dans la finance, évidement cette liste est non exhaustive. Là il ne s'agit plus uniquement de Web, mais d'un système complet, chaque brique du SI a des contraintes en temps. Évidement c'est coté serveur, mais ce n'est pas impossible de faire du temps réel sur un client lourd.
    J'avais bien compris. La nature meme du WEB ne permet pas le temps réel. De plus le temps réel est bien plus lié a l'OS qu'au langage.

    AOP, Aspect Oriented Programming, tu dois certainement connaitre, parfois l'OOP n'est pas assez souple pour
    faire des bonnes conceptions, les aspect viennent aider. Avec ce paradigme tu peux créer des aspects avec leur responsabilités, et ses aspects seront "tissés" dans le code des objets métier pour ajouter leur responsabilités. De cette façon tu peux séparer des responsabilités métier de tes objets des responsabilités plus technique comme la sécurité, le monitoring, les logs, les transactions, etc... Évidement on peut mettre n'importe quoi dans les aspects, du code métier peut avoir une bonne raison de s'y trouver.
    C'est tres interressant, je ne suis pas surpris que ce ne soit pas tres developpé en PHP. Ce paradigme est pertinent pour des applications hétérogenes. L'interet est limité pour du WEB.
    Mais bon le jour ou le besoin sera la, peut-etre un composant verra le jour.
    D'autant plus que le scripting s'y prete volontier.

    JCA, Java Connector Architecture, c'est une partie de la spécification J2EE pour résoudre des problèmes d'intégration avec d'autres systèmes, c'est assez courant que des entreprises aient encore de vieux mainframes, ou des systèmes complètement exotiques dont il ne veulent pas se séparer. Et plutôt que de tout refaire ce qui couterait une vraie fortune! Ils préfèrent coder à coté une appli moderne qui se connectera au vieux système. Et l'architecture d'un composant JCA permet de faire ça de manière propre. C'est un peu comme un driver base de donnée, d'ailleurs un driver JDBC a la même architecture qu'un driver JCA. JCA permet de gérer plein de chose, comme le pooling, le cycle de vie, les transactions, la sécurité, etc.
    Encore un point tres interressant car il illustre une différence d'approche. La ou JAVA va apporter une solution globale pour régler tous les problemes. PHP va plutot developper une multitudes de solutions qui répondront a différentes problématiques. Si tu regardes de pres les Framework PHP tu te rendras comptes qu'ils répondent chacun a leur maniere sur des cas similaires. L'écosysteme de PHP s'est avant tout la diversité (le meilleur et le pire).
    Je me souviens avoir eu besoin de me connecter a un CRM, nous avons utilisé SOAP. Je me repete mais un bon developpeur PHP aura des compétences bien au dela de PHP pour répondre a toutes les problématiques d'un SI.

    JMX, Java Management eXtension, c'est un système pour exposer des objets qui vont contenir des propriétés, il est possible de modifier dynamiquement ces propriétés pour changer le comportement de l'application.
    C'est très pratique si en production on a besoin d'activer des parties de l'application, mais évidement JMX ne se limite pas à ça.
    Ca a l'air d'etre pour du client lourd avec PHP il n'y a pas vraiment d'application en cours d'exécution (WEB).

    Si j'aborde les clusters, c'est bien parce que l'écosystème Java offre déjà des librairies pour supporter ce genre d'architecture. Je pense qu'il faut en parler, on est pas tout seul dans son coin avec la librairie standard pour faire des choses un peu compliquées. Évidement on parle architecture et tout les projets n'ont pas besoin de cluster, encore heureux!
    La je seche car je ne vois vraiment pas ce que des librairies peuvent apportées hormis la supervision?

    Là je ne suis pas complètement d'accord, il s'agit de décision d'architecture, sur un petit projet peut-être que tout est vaguement intégré, mais sur des gros projets, on urbanise un minimum. On sépare les responsabilités des applications, on sépare les machines s'il le faut. Dans les faits ce n'est plus que du Java ou son écosystème (même si un support prononcé est présent), mais tu peux avoir des frontaux web, avec derrière un ou plusieurs tiers métier, et puis pourquoi pas un middleware pour communiquer ailleurs, ou alors un vieux système tout moche, sans parler de BDD (toutes les applis ne sont pas basées sur une BDD). Ensuite suivant ton archi tu peux mettre des machines et applications ni Java ni PHP qui ont des responsabilités bien spécifiques, je pense à Memcached ou TokyoCabinet (très très gros plus à cette appli d'ailleurs), ou encore à un serveur de lock distribué comme Zookeeper, et d'autres encore.
    Oui c'est vrai mais je parlais surtout des librairies.

    Oui, et, non:
    Oui parce que je trouve vraiment que le script est pas mal du tout dans certains cas, et la simplicité de certaines choses sont assez plaisante.
    Non parce que les script sont rarement bien maintenable. Et en script comme le but est d'aller vite on peut
    vite faire de la merde, et, 1 ans après quand il faut retoucher telle partie du script et que la doc et la conception ne sont pas géniales, on est vite plus embêté que dans un langage plus encadré.
    Le script est par nature plus permissif mais je ne pense pas qu'il soit moins maintenable. Qu'est-ce qui te faire dire ca?
    Le but du scripting ce n'est pas d'aller vite, c'est plutot de s'éloigner des couches trop bas niveau.
    C'est l'éternel combat de la machine qui s'adapte a l'homme ou l'homme a la machine.
    La vitesse est plutot une conséquence, comme je tape 1 ligne de code au lieu de 3 ben au final je vais plus vite.
    Les problemes que tu decris sont liés a la conception pas au scripting en lui meme.
    Je t'assure qu'un Framework comme Symfony avec de bons developpeurs t'apporte confort, vitesse, sécurité, maintenance aisé.

    En Java j'ai régulièrement vu des traitements parallélisés dans des applications métier, ou encore certaines tâches potentiellement bloquantes qui sont rendu asynchrone, en dehors du thread courant.
    D'ailleurs j'ouvre une parenthèse sur JMS, Java Messagin Service, qui permet d'envoyer des messages de manière asynchrone sans bloquer le thread qui envoie ces messages, l'application qui les reçoit va faire dépiler la liste des messages pour les traiter quand elle a le temps. Ces applications sont des MOM, Message Oriented Middleware, c'est fiable, on peut faire du routage, on peut persister les messages, et évidement Java à un très bon support de ce type d'architecture. Parenthèse fermée.

    Il me semble que en PHP, c'est plutôt très limité de ce coté là, il me semble qu'il est juste question de fork/join de process (c'est beaucoup moins fin qu'une thread). Cela dit avec ça on peut quand même déjà faire du parallélisme!
    Au contraire y'a du choix, tu peux utiliser des librairies de messagerie dédié tel que Gearman, Kestrel ou RabbitMQ.
    Avec la monté en puissance du Web2 et ses appels Ajax dans tous les sens, c'est devenu impératif.

  10. #170
    Membre du Club
    Profil pro
    Inscrit en
    avril 2006
    Messages
    51
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : avril 2006
    Messages : 51
    Points : 64
    Points
    64

    Par défaut

    Citation Envoyé par batataw Voir le message
    J'ai lu attentivement tes commentaires. Ils sont toujours aussi riches...
    Les tiens aussi

    Citation Envoyé par batataw Voir le message
    Cependant j'ai noté une petite confusion. Reprends moi si je me trompe.
    Parfois les thématiques que tu abordes sont réservées aux clients lourds ou au langage a opcode (JVM).
    PHP est un langage a script, certains mecanismes ne peuvent pas etre appliqué. De plus son écosysteme est orienté WEB.
    Il excellera si tu restes dans cet environnement. Il ne pourra pas concurrencer JAVA sur des problématiques
    client lourds. Il vaut mieux les comparer en restant sur dans un environnement client leger.
    Non, je parle bien de technologies coté serveur ou tiers applicatif. Effectivement certaines technologies marche aussi sur un client lourd. Et des fois ce sont les deux, par exemple pour JMX il y a le serveur et le client qui sont impliqués (le client peut être un autre tiers applicatif).


    Citation Envoyé par batataw Voir le message
    Effectivement PHP a été pensé pour le WEB. Si tu veux dépasser ce cadre ca peut devenir vite compliqué.
    Le middleware c'est pas son point fort.
    Effectivement, je viens de me rendre compte que le topic était rangé dans "Général Concetion Web", et les sujets des commentaires dépassent effectivement le cadre du Web.

    Citation Envoyé par batataw Voir le message
    Si je dois choisir un seul language et ne plus en bouger je prendrais automatiquement
    le plus riche (JAVA, .NET, C++...) Celui qui couvrira a coup sur tous les domaines.
    Cela dit une architecture se choisit en fonction d'un projet au sens large (avantages, cout, ressources, delai, pérénité...).
    Je crois qu'il y a de la place pour tous et pour tout, c'est vraiment au cas par cas.
    Oui effectivement c'est un point important. J'ajouterais que les derniers messages m'amène un peu plus à réviser mon point de vue sur PHP et son écosystème. Et je suis d'accord sur le cas par cas.

    Citation Envoyé par batataw Voir le message
    Il faudra que tu m'expliques car c'est un des gros différent que j'ai avec Java.
    Si tu veux t'occuper du Front-end il te faut développer des compétences Frontend, JSF, JSP, GWT, Tiles...
    Au niveau du backend il faut connaitre, Spring, Struts...
    Pour la base de données JDBC est indispensable ou bien Hibernate...
    Pour le deploiment ANT ou Maven.
    Sans parler de la plétore de fichiers XML a configurer pour utiliser tout ce beau monde.
    C'est juste, il y a des compétences à développer sur des sujets variés, mais finalement c'est comme tu le disais, la même chose pour un développeur sérieux en PHP


    Citation Envoyé par batataw Voir le message
    Pour un projet WEB je ne pense pas que le support est limité. On peut tout faire avec PHP.
    La partie présentation est une petite partie d'un Framework comme Symfony ou Zend. Ils font bien plus que cela.
    Oui mais à quel prix, en assembleur on peut tout faire aussi, il y a des Mainframe qui sont entièrement codé en assembleur!
    Je pense un peu plus que PHP peut faire plus de chose, qu'il peut s'intégrer à plus de chose, mais il brille plus pour son support du tiers présentation que pour ce qui est du middleware.


    Citation Envoyé par batataw Voir le message
    EzPublish, Drupal, WordPress...huuummm ce sont d'excellents projets mais ils masquent les capacités de PHP car ils font avant tout de la publication. Il existe des projets d'une autre nature comme SugarCRM, Magento (Ecommerce), WebERP...
    Les projets sur lequels j'ai travaillés sont en majorité des extranets.
    Effectivement je crois que pour Drupal et EzPublish au moins, PHP est masqué, c'est du langage "propriétaire" de ces frameworks.
    Oui il doit y avoir ce genre de framework en Java, je ne les connais pas trop, Alfresco qui est un CMS assez poussé, il doit y en avoir d'autres pour des secteurs différents, mais je n'ai pas l'impression qu'ils soient "tip top".


    Citation Envoyé par batataw Voir le message
    J'avais bien compris. La nature meme du WEB ne permet pas le temps réel. De plus le temps réel est bien plus lié a l'OS qu'au langage.
    Effectivement l'OS est le socle, mais la JVM certifiée RTSJ joue un rôle aussi important en Java!


    Citation Envoyé par batataw Voir le message
    C'est tres interressant, je ne suis pas surpris que ce ne soit pas tres developpé en PHP. Ce paradigme est pertinent pour des applications hétérogenes. L'interet est limité pour du WEB.
    Mais bon le jour ou le besoin sera la, peut-etre un composant verra le jour.
    D'autant plus que le scripting s'y prete volontier.
    Je ne suis pas d'accord, si tu peux unifié tes problématiques authentification dans un aspect pour tes pages WEB, c'est très pratique, pas besoin que ta page ou ton script connaisse les aspect techniques, ce sont les aspects qui connaissent les objets sur lesquels ils doivent se tisser.
    Pour ton commentaire sur le scripting, je ne suis pas sur de comprendre en quoi il faciliterait ce genre de problématique.


    Citation Envoyé par batataw Voir le message
    Encore un point tres interressant car il illustre une différence d'approche. La ou JAVA va apporter une solution globale pour régler tous les problemes. PHP va plutot developper une multitudes de solutions qui répondront a différentes problématiques. Si tu regardes de pres les Framework PHP tu te rendras comptes qu'ils répondent chacun a leur maniere sur des cas similaires. L'écosysteme de PHP s'est avant tout la diversité (le meilleur et le pire).
    Oui, c'est la pluralité des frameworks est manifeste, c'est dommage qu'il n'y ai pas une certaine envie de spécifier un minimum. Afin de permettre une meilleure interopérabilité.

    Citation Envoyé par batataw Voir le message
    Je me souviens avoir eu besoin de me connecter a un CRM, nous avons utilisé SOAP. Je me repete mais un bon developpeur PHP aura des compétences bien au dela de PHP pour répondre a toutes les problématiques d'un SI.
    Je suis d'accord, mais en Java c'est la même chose


    Citation Envoyé par batataw Voir le message
    Ca a l'air d'etre pour du client lourd avec PHP il n'y a pas vraiment d'application en cours d'exécution (WEB).
    Comme je l'ai dit plus haut pour JMX, c'est une technologie qui est en standard, donc c'est coté serveur et coté client (le client pouvant être un autre serveur). Ce qu'il faut comprendre c'est de pouvoir changer, monitorer des choses à chaud, ça implique donc le serveur et un client "lourd". Mais pour des soucis d'exploitation, on peut aussi voir et modifier ces bean à distance en ligne de commande. Typiquement un problème sur la prod à 4h du matin, l'admin sort de son lit, allume sa machine, ouvre un terminal, et hop il regarde et change ce qu'il faut changer très rapidement.


    Par rapport aux Clusters, ce sont nos serveurs d'application (des serveurs à la norme J2EE), qui nous permettent de faire ça. Evidement on sort du cadre de l'utilisation de librairies ou de frameworks. Je parle directement d'architectures d'exploitation. La ou je travaille, notre application fournit des service à une autre application, c'est un cluster de plus de 30 machines, et sur d'autres clusters on fournit des services à des clients extérieurs. Avec gestion de la sécurité, du load-balancing, etc... C'est assez pratique pour la scalabilité d'un appli. Évidement le cluster n'est pas la seule architecture de production qui soit intéressante.


    Citation Envoyé par batataw Voir le message
    Le script est par nature plus permissif mais je ne pense pas qu'il soit moins maintenable. Qu'est-ce qui te faire dire ca?
    Le but du scripting ce n'est pas d'aller vite, c'est plutot de s'éloigner des couches trop bas niveau.
    C'est l'éternel combat de la machine qui s'adapte a l'homme ou l'homme a la machine.
    La vitesse est plutot une conséquence, comme je tape 1 ligne de code au lieu de 3 ben au final je vais plus vite.
    Les problemes que tu decris sont liés a la conception pas au scripting en lui meme.

    Oui mais c'est ce qui me fait peur en script, on peut vite faire n'importe quoi, sans vraiment concevoir. Pour le scripting Groovy est vraiment super, et il apporte une concision très appréciable. Mais ma crainte vient encore de la maintenabilité du script s'il a été fait sans bonne pratique / conception.

    Citation Envoyé par batataw Voir le message
    Je t'assure qu'un Framework comme Symfony avec de bons developpeurs t'apporte confort, vitesse, sécurité, maintenance aisé.
    OK, à essayer alors


    Citation Envoyé par batataw Voir le message
    Au contraire y'a du choix, tu peux utiliser des librairies de messagerie dédié tel que Gearman, Kestrel ou RabbitMQ.
    Avec la monté en puissance du Web2 et ses appels Ajax dans tous les sens, c'est devenu impératif.
    Intéressant, je ne connaissais pas Gearman et RabbitMQ, celà dit ça me semble encore jeune. Et pas très interopérable, mais les buts de ces deux là n'ont pas la même portée. En ce qui concerne Kestrel, c'est du Scala sur la JVM J'avais déjà lu un article la dessus sur highscalability.

    Juste pour info, est-ce que le TDD et les test unitaires sont monaie courante en PHP ? Est-ce que les frameworks comme PHPUnit ou d'autres, sont bien, matures pour ce qu'il font. Coté Java, on en a une ribambelle, avec quelques uns qui émergent du lot notamment par leur design et leur maturité.



    Enfin pour finir, je pense en effet que la maturation de PHP et de son écosystème avance bien. Je pense bien davantage que PHP peut vraiment être un bon choix sur le tiers présentation. Mais également pour certaines applications ou l'urbanisme ne demande pas une intégration et des architectures plus poussées. De toute façon on le voit certains grands sites sont fait en PHP.

    Mais le choix de Java se justifierait davantage s'il y a des besoins plus avancés et vraiment plus larges. Java n'étant bien entendu pas le seul candidat.

    Et ça fait vraiment plaisir de pouvoir discuter en bonne intelligence avec des gens du domaine PHP. Malheureusement ça n'arrive pas si souvent que ça!

    Je reviens sur le sujet la dessus, mais plus que Java vs PHP, c'est de prendre le bon langage pour résoudre le bon problème. C'est le thème que j'avais abordés avec le paradigme de programmation polyglotte.

  11. #171
    Rédacteur
    Avatar de benwit
    Inscrit en
    septembre 2004
    Messages
    1 675
    Détails du profil
    Informations forums :
    Inscription : septembre 2004
    Messages : 1 675
    Points : 3 549
    Points
    3 549

    Par défaut

    Comment fait on de la couverture de code en PHP ?
    Pour Java : http://blog.developpez.com/julienh/p...verture-de-co/

    Tout le monde savait que c'était impossible. Il est venu un imbécile qui ne le savait pas et qui l'a fait. Marcel PAGNOL
    On ne savait pas que c'était impossible, alors on l'a fait. John Fitzgerald KENNEDY.
    L'inexpérience est ce qui permet à la jeunesse d'accomplir ce que la vieillesse sait impossible. Paul (Tristant) BERNARD
    La meilleure façon de prédire l'avenir, c'est de l'inventer.

  12. #172
    Membre du Club
    Profil pro
    Inscrit en
    avril 2006
    Messages
    51
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : avril 2006
    Messages : 51
    Points : 64
    Points
    64

    Par défaut

    Citation Envoyé par benwit Voir le message
    Comment fait on de la couverture de code en PHP ?
    Pour Java : http://blog.developpez.com/julienh/p...verture-de-co/
    Bien vu, je n'ai pas trop abordé le coté "usine logicielle", c'est vrai que dans l'écosystème, nous avons des facilités pour mettre en place de l'intégration continue avec tout ce que ça implique (Test, couverture de code, packaging intégrations de composants, déploiement sur serveur, test d'intégration, etc...)

  13. #173
    seb92400
    Invité(e)

    Par défaut

    Citation Envoyé par benwit Voir le message
    Comment fait on de la couverture de code en PHP ?
    Tiré de la notice Xdebug (après une recherche de 5 secondes sur Google !) :

    Xdebug allows you to log all function calls, including parameters and return values to a file in different formats.
    Citation Envoyé par TheNOHDirector Voir le message
    Bien vu, je n'ai pas trop abordé le coté "usine logicielle", c'est vrai que dans l'écosystème, nous avons des facilités pour mettre en place de l'intégration continue avec tout ce que ça implique (Test, couverture de code, packaging intégrations de composants, déploiement sur serveur, test d'intégration, etc...)
    C'est dingue ça ! A moins que je n'ai pas compris le sens de cette phrase, je reste sur ma position : PHP est dénigré par des personnes qui l'utilisent peu, pas ou mal (et ce, malgré tout ce que j'ai pu lire avant...).

    Citation Envoyé par benwit Voir le message
    Je veux bien croire que php soit plus utilisé pour les sites web.
    Oui, je m'étais mal expliqué dans mon message et effectivement, je pense que java et sa suite est très utilisé pour les applications autres que sites web. PHP6 veut justement redresser la barre et grignoter des parts de marché, à suivre...

    Quelques mots sur toutes les bonnes paroles d'avant, et qui plus est comme cela a été souligné, de qualité. Cependant, il ne faut pas perdre de vue que toutes les problématiques soulevées afin de mettre java en tête, ne concernent quasiment pas ou très peu des problèmes que l'on peut rencontrer sur le web pur... Il s'agit plus pour l'essentiel d'outils répondant à un besoin ponctuel et bien ciblé d'une application interne, autrement dit, un outil pour une solution, comme il en existe dans tous les langages, et qui créé les différences. Sinon, il n'y aurait qu'un seul langage qui fait tout, mais ce serait triste.

    Cependant, et là, je déborde un peu du sujet, mais j'ai le sentiment de nos jours qu'on cherche aussi à sortir le tank pour tuer un moucheron... Pour m'être trouvé entre deux "camps" dernièrement qui cherchait à prouver qu'envoyer des messages et les stocker sur le serveur en utilisant deux ou trois outils différents était préférable à une base de données pour stocker des commandes... Qui a raison, je ne sais pas. Ce qui est sûr, c'est que le résultat est le même, le soir, les données sont traitées à la chaîne ! S'il n'y a parfois qu'un seul outil pour une solution, il n'y a pas forcément qu'une seule solution au problème soulevé...

    Que l'on soit à la milliseconde près, voire 1 000 000 fois plus précis sur des systèmes nucléaires, je comprends. Mais qu'on utilise des outils exotiques et/ou qu'on écrive 10 ou 20, voire plus, de lignes de codes sous prétexte de gagner quelques dixièmes de secondes pour du web, là, j'ai plus de mal.

    Pour terminer cette digression philosophique, je pense que quelque soit le langage, il faut surtout penser à développer propre, réutilisable, etc... (si, si, ça vient de la façon de développer, pas du langage), et surtout, que ça marche !!! Après pour 80% des besoins traditionnels, utiliser java ou php... reste à mon avis une question de goût !

    Et pour les 20% qui restent ? ...
    Dernière modification par seb92400 ; 26/11/2009 à 01h08.

  14. #174
    Membre Expert
    Inscrit en
    septembre 2007
    Messages
    955
    Détails du profil
    Informations forums :
    Inscription : septembre 2007
    Messages : 955
    Points : 1 068
    Points
    1 068

    Par défaut

    Citation Envoyé par TheNOHDirector Voir le message
    Bien vu, je n'ai pas trop abordé le coté "usine logicielle", c'est vrai que dans l'écosystème, nous avons des facilités pour mettre en place de l'intégration
    continue avec tout ce que ça implique (Test, couverture de code, packaging intégrations de composants, déploiement sur serveur, test d'intégration, etc...)
    Phpunit est un superbe plateforme de test unitaire couplé a CruiseControl il fera la couverture de code sans aucun problème.
    N'oublie pas qu'il n'y a pas de compilation et il n'y pas de paquets à déployer en PHP.

    Citation Envoyé par TheNOHDirector Voir le message
    Il faudra que tu m'expliques car c'est un des gros différent que j'ai avec Java.
    Si tu veux t'occuper du Front-end il te faut développer des compétences Frontend, JSF, JSP, GWT, Tiles...
    Au niveau du backend il faut connaitre, Spring, Struts...
    Pour la base de données JDBC est indispensable ou bien Hibernate...
    Pour le deploiment ANT ou Maven.
    Sans parler de la plétore de fichiers XML a configurer pour utiliser tout ce beau monde.
    C'est juste, il y a des compétences à développer sur des sujets variés, mais finalement c'est comme tu le disais, la même chose pour un développeur sérieux en PHP
    La je reste sur ma faim, un developpeur PHP sera traiter tous les sujets du frontend au backend...
    Quid du developpeur Java. Je ne sais pas si ce que je dis est juste mais j'ai l'impression qu'un developpeur Java ne maitrise qu'une petite partie d'une application.


    Citation Envoyé par TheNOHDirector Voir le message
    Oui mais à quel prix, en assembleur on peut tout faire aussi, il y a des Mainframe qui sont entièrement codé en assembleur!
    Je pense un peu plus que PHP peut faire plus de chose, qu'il peut s'intégrer à plus de chose, mais il brille plus pour son support du tiers présentation que pour ce qui est du middleware.
    Ben non et encore heureux, la partie présentation est une infime partie de PHP.
    Pour être tout a fait honnête je ne vois pas des entreprises se lancer avec PHP sur des sites envergure si c'était que pour dynamiser des pages HTML.
    Je me répète PHP associé à un Framework comme Zend ou Symfony fait des merveilles.

    Citation Envoyé par TheNOHDirector Voir le message
    Comme je l'ai dit plus haut pour JMX, c'est une technologie qui est en standard, donc c'est coté serveur et coté client (le client pouvant être un autre serveur). Ce qu'il faut comprendre c'est de pouvoir changer, monitorer des choses à chaud, ça implique donc le serveur et un client "lourd". Mais pour des soucis d'exploitation, on peut aussi voir et modifier ces bean à distance en ligne de commande. Typiquement un problème sur la prod à 4h du matin, l'admin sort de son lit, allume sa machine, ouvre un terminal, et hop il regarde et change ce qu'il faut changer très rapidement.
    La notion de "a chaud" n'existe pas en PHP, il n'y a pas besoin de container.
    Si tu as besoin de modifier un Bean pour faire une vérification, la bonne pratique veut que tu es un spare de ton site que tu peux modifier à volonté.
    C'est du scripting donc tu as accès directement au code source.


    Citation Envoyé par TheNOHDirector Voir le message
    Je ne suis pas d'accord, si tu peux unifié tes problématiques authentification dans un aspect pour tes pages WEB, c'est très pratique, pas besoin que ta page ou ton script connaisse les aspect techniques, ce sont les aspects qui connaissent les objets sur lesquels ils doivent se tisser.
    Mes connaissances sont limités sur ce sujet.
    Dans un Framework tel que Symfony pour reprendre ton exemple je lui indique quel sont les pages qui ont besoin d'authentification ou de permissions.
    Le Framework se débrouille tout seul pour tout gérer.
    Est-ce que c'est de ça que tu parles?

    Citation Envoyé par TheNOHDirector Voir le message
    Oui mais c'est ce qui me fait peur en script, on peut vite faire n'importe quoi, sans vraiment concevoir. Pour le scripting Groovy est vraiment super, et il apporte une concision très appréciable. Mais ma crainte vient encore de la maintenabilité du script s'il a été fait sans bonne pratique / conception.
    Souvent les personnes qui veulent dénigrer PHP montrent des bouts de code infames. Justement ca me permet d'expliquer qu'au final c'est bien la méthode qui compte.
    Pour moi PHP + Framework = Un des plus puissant outil RAD pour le Web.


    Citation Envoyé par TheNOHDirector Voir le message
    Oui, c'est la pluralité des frameworks est manifeste, c'est dommage qu'il n'y ai pas une certaine envie de spécifier un minimum. Afin de permettre une meilleure interopérabilité.
    Oui et non interopérabilité entre Framework n'a pas gransd interet. Il faut conserver cette pluralité. Une des forces de l'écosystème PHP c'est de répondre précisement à un besoin.
    Je l'ai déja dit mais avec Java tu es rapidement obligé de sortir le 38 tonnes quelque soit le projet.

    Citation Envoyé par TheNOHDirector Voir le message
    Enfin pour finir, je pense en effet que la maturation de PHP et de son écosystème avance bien. Je pense bien davantage que PHP peut vraiment être un bon choix sur le tiers présentation. Mais également pour certaines applications ou l'urbanisme ne demande pas une intégration et des architectures plus poussées. De toute façon on le voit certains grands sites sont fait en PHP.

    Mais le choix de Java se justifierait davantage s'il y a des besoins plus avancés et vraiment plus larges. Java n'étant bien entendu pas le seul candidat.

    Et ça fait vraiment plaisir de pouvoir discuter en bonne intelligence avec des gens du domaine PHP. Malheureusement ça n'arrive pas si souvent que ça!

    Je reviens sur le sujet la dessus, mais plus que Java vs PHP, c'est de prendre le bon langage pour résoudre le bon problème. C'est le thème que j'avais abordés avec le paradigme de programmation polyglotte.

  15. #175
    Membre habitué
    Inscrit en
    mars 2007
    Messages
    135
    Détails du profil
    Informations forums :
    Inscription : mars 2007
    Messages : 135
    Points : 112
    Points
    112

    Par défaut

    Les gars je crois qu'on peut prendre pas mal de post et faire un petit bouquin "Java Vs PHP", vous en avez des choses à dire



  16. #176
    Rédacteur

    Homme Profil pro
    Geek entrepreneur
    Inscrit en
    novembre 2004
    Messages
    1 212
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Geek entrepreneur

    Informations forums :
    Inscription : novembre 2004
    Messages : 1 212
    Points : 2 373
    Points
    2 373

    Par défaut

    Bon, je n'ai malheureusement pas eu le courage de lire les posts précédents (surtout les tartines au dessus, désolé ^^) donc peut être que mon vote et sa justification ont déjà été donnés.


    J'ai fait du PHP avant le Java et jusqu'a maintenant je considérais que le PHP était super bien pour faire du dev Web rapide (et de qualité quand on sait bien en faire).
    Mais le Java possède un écosystème plus riche (en frameworks et outils) et mature, ce qui lui donne un avantage sur les gros projets. Et puis d'un point de vue langage, je préfère les langages typé.

    A mon sens, les deux langages permettent évidemment de faire des sites de qualité. Jusqu'à maintenant cependant je me schématisais succintement les courbe d'apprentissage, de maintenance etc... comme étant meilleures sur le court terme pour le PHP mais meilleures sur le long terme pour le Java.

    Donc j'aurais voté blanc il y a encore deux semaines. J'aime bien les deux.


    Mais depuis j'ai découvert un nouveau framework en Java : Play!
    Et la, je retrouve tout ce que j'appréciais en PHP avec la puissance de l'écosystème Java. Plus besoin de sortir l'artillerie lourde, de compiler 1 min, de lancer son serveur d'application pendant 10 minutes pour tester une pauvre modif de code.

    J'ai d'ailleurs un billet sur le sujet :
    http://hakanai.free.fr/index.php/the-news/58-play

    Bref, désormais, site rapide ou non, j'adore Java ^^ (sauf pour trouver des hébergeurs gratuits....)

  17. #177
    Membre Expert
    Profil pro
    Inscrit en
    janvier 2007
    Messages
    1 451
    Détails du profil
    Informations personnelles :
    Âge : 30
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : janvier 2007
    Messages : 1 451
    Points : 1 942
    Points
    1 942

    Par défaut

    Citation Envoyé par hugo123 Voir le message
    Bon, je n'ai malheureusement pas eu le courage de lire les posts précédents (surtout les tartines au dessus, désolé ^^) donc peut être que mon vote et sa justification ont déjà été donnés.


    J'ai fait du PHP avant le Java et jusqu'a maintenant je considérais que le PHP était super bien pour faire du dev Web rapide (et de qualité quand on sait bien en faire).
    Mais le Java possède un écosystème plus riche (en frameworks et outils) et mature, ce qui lui donne un avantage sur les gros projets. Et puis d'un point de vue langage, je préfère les langages typé.

    A mon sens, les deux langages permettent évidemment de faire des sites de qualité. Jusqu'à maintenant cependant je me schématisais succintement les courbe d'apprentissage, de maintenance etc... comme étant meilleures sur le court terme pour le PHP mais meilleures sur le long terme pour le Java.

    Donc j'aurais voté blanc il y a encore deux semaines. J'aime bien les deux.


    Mais depuis j'ai découvert un nouveau framework en Java : Play!
    Et la, je retrouve tout ce que j'appréciais en PHP avec la puissance de l'écosystème Java. Plus besoin de sortir l'artillerie lourde, de compiler 1 min, de lancer son serveur d'application pendant 10 minutes pour tester une pauvre modif de code.

    J'ai d'ailleurs un billet sur le sujet :
    http://hakanai.free.fr/index.php/the-news/58-play

    Bref, désormais, site rapide ou non, j'adore Java ^^ (sauf pour trouver des hébergeurs gratuits....)
    C'est super intéressant. Je m'y jette.

  18. #178
    Membre du Club
    Profil pro
    Inscrit en
    avril 2006
    Messages
    51
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : avril 2006
    Messages : 51
    Points : 64
    Points
    64

    Par défaut

    Citation Envoyé par batataw Voir le message
    Phpunit est un superbe plateforme de test unitaire couplé a CruiseControl il fera la couverture de code sans aucun problème.
    N'oublie pas qu'il n'y a pas de compilation et il n'y pas de paquets à déployer en PHP.
    Ba du coup pour le déploiement en PHP ça pourrait être juste l'automatisation par un script, qui va va gérer le copie des fichiers sur le serveur. Et justement comment ça se passe s'il y a des optims serveurs, je pense à la configuration du mod php et / ou du cache d'opcode. C'est géré à la mano ?
    J'ai un ami qui me dit qu'il y a souvent des merde en prod parce que les ingénieurs systèmes ou les développeurs tête en l'air copie limite directe les fichier du repo svn vers les serveurs de prod, ce qui ne marche pas correctement avec les configs SVN.

    S'il y a une livraison, un zip versionné et archivé, ca permettrait de professionnaliser vos équipes logicielles. Ça permet de préparer éventuellement une recette, un PV. Bref un client exigent pourrait apprécier.

    Autre question justement à propos de ce mode "fichier", typiquement comment vous faites pour livrer des patch et savoir quels patch sont en prod s'il s'agit juste de faire un drag&drop. Question suivi de prod c'est important. Si tout le monde peut faire n'importe quoi avec le serveur de prod, c'est pas très "clean".

    Citation Envoyé par batataw Voir le message
    La je reste sur ma faim, un developpeur PHP sera traiter tous les sujets du frontend au backend...
    Quid du developpeur Java. Je ne sais pas si ce que je dis est juste mais j'ai l'impression qu'un developpeur Java ne maitrise qu'une petite partie d'une application.
    En fait ton impression est alimentée à juste titre par le fait que les développeurs Java travaillent régulièrement sur des projets d'envergure et, histoire de ne pas donner des taches à n'importe qui, les chefs de projets donnent souvent les sujets plus sensibles / techniques à des gens plus expérimentés. Également les framework utilisés sont peut-être puissants mais parfois un peu compliqués à mettre en place, celà dit les framework ont fait de gros progrès pour proposer une api expressive et developper friendly, typiquement Spring est d'une facilité déconcertante à mettre en place. Hibernate ou iBatis pour le mapping base de données est vraiment très pratique et encore plus avec Spring. Par contre par le passé les développeurs juniors n'avaient les billes pour toucher à tout, en cours de Java on apprends vaguement le langage et ce qu'il y a dans le JDK.

    Et dans la plupart des cours ils n'apprennent même pas à être un bon développeur (principe OO, etc...) mais la je dérive.


    Citation Envoyé par batataw Voir le message
    Ben non et encore heureux, la partie présentation est une infime partie de PHP.
    Pour être tout a fait honnête je ne vois pas des entreprises se lancer avec PHP sur des sites envergure si c'était que pour dynamiser des pages HTML.
    Je me répète PHP associé à un Framework comme Zend ou Symfony fait des merveilles.
    Je conserve ce que j'ai dit plus haut, mais je reste quand même perplexe, celà dit PHP c'est un langage ET un écosystème à surveiller.

    Citation Envoyé par batataw Voir le message
    Citation Envoyé par TheNOHDirector Voir le message
    Je ne suis pas d'accord, si tu peux unifié tes problématiques authentification dans un aspect pour tes pages WEB, c'est très pratique, pas besoin que ta page ou ton script connaisse les aspect techniques, ce sont les aspects qui connaissent les objets sur lesquels ils doivent se tisser.
    Mes connaissances sont limités sur ce sujet.
    Dans un Framework tel que Symfony pour reprendre ton exemple je lui indique quel sont les pages qui ont besoin d'authentification ou de permissions.
    Le Framework se débrouille tout seul pour tout gérer.
    Est-ce que c'est de ça que tu parles?
    A mon avi le framework utilise une technique différente et dynamique pour gérer ça. Mais ce que je voulais dire sur les aspects, c'est que tu choisis complètement la portée de ton aspect, par exemple tu veux parler à un vieux mainframe, il fout ouvrir une transaction, mais pour ça il faut réserver un token sur un autre système, c'est ce genre d'aspect technique particulier à ton environnement dont tu auras besoins sur certaines pages ou certaines actions (XmlHttpRequest par ex), ou certaines sous-parties de ton processus métier. C'est sur ces aspects ou ton framework ne pourra pas t'aider que le l'AOP te servira.

    Ces aspects s'apposent sur les classes / méthodes suivant un pattern. Imagines ton appli est lente, les logs en place ne sont pas placés au bon endroit, il n'y a pas de log, ou alors ils ne loguent pas les informations voulues. Eh bien plutôt que de modifier 500 fichiers, tu vas dire à ton aspect de se tisser sur toutes les classes qui ont le pattern *CusumerAction avec les méthodes *send et *rollbock. Et hop un seul bout de code pour toutes les classes qui en ont besoin, pas de copier/coller, meilleure maintenance, facile à retirer, etc. Et en plus en Java c'est même faisable après que l'appli soit livrée.

    D'ailleurs à propos de la performance on a des profilers sympa, et en php il y a XDebug, est-ce que ça marche bien. En java les outils sont maintenant mature, il éxiste même maintenant des outils gratuit mais avec une finition moins élaborée.

    Citation Envoyé par batataw Voir le message
    Souvent les personnes qui veulent dénigrer PHP montrent des bouts de code infames. Justement ca me permet d'expliquer qu'au final c'est bien la méthode qui compte.
    Pour moi PHP + Framework = Un des plus puissant outil RAD pour le Web.
    100% d'accord, et de ce coté j'ai vu aussi un paquet de bout de code vraiment infâme en Java.

    Citation Envoyé par batataw Voir le message
    Oui et non interopérabilité entre Framework n'a pas gransd interet. Il faut conserver cette pluralité. Une des forces de l'écosystème PHP c'est de répondre précisement à un besoin.
    Je l'ai déja dit mais avec Java tu es rapidement obligé de sortir le 38 tonnes quelque soit le projet.
    Pour le coup maintenant je ne sais pas trop quoi penser, je trouve que c'est bien l'interopérabilité, ça réduit les coup de changement, et ça évite de nous lié à un vendeur, parfois ils abusent un peu. Celà dit l'innovation se produit souvent en dehors des chemins bien tracés, donc en dehors des standards.

    Par exemple le framework Play en Java.

    Citation Envoyé par seb92400 Voir le message
    C'est dingue ça ! A moins que je n'ai pas compris le sens de cette phrase, je reste sur ma position : PHP est dénigré par des personnes qui l'utilisent peu, pas ou mal (et ce, malgré tout ce que j'ai pu lire avant...).
    Je ne peux pas te contredire j'ai vu beaucoup de message dans ce sens, et moi même je ne l'utilise que assez peu. Je veux bien croire que j'ai mes habitudes avec Java, mais j'essaye de pousser le débat en bonne intelligence. Pour ce dont je parle avec PHP, j'ai effectué des recherches sur google mais parfois ça ne suffit pas, ET je me suis renseigné auprès de mes connaissances dont c'est le métier d'être développeur PHP. En ce qui concerne mon commentaire, il veut simplement dire qu'il s'agissait d'un point resté sous silence durant cette conversation; on est bien en train de parler de java ou php, et de leurs écosystèmes respectifs.

  19. #179
    Nouveau Membre du Club
    Inscrit en
    mai 2007
    Messages
    92
    Détails du profil
    Informations forums :
    Inscription : mai 2007
    Messages : 92
    Points : 26
    Points
    26

    Par défaut

    Salut,

    J'ai essayé de lire toutes les réponses, certaines en travers, mais au final, bien que le sujet permette de renouer avec un langage ou l'autre si on avait des aprioris, ça tourne un peu en rond.

    Je développe essentiellement en PHP. Mais je ne suis pas pro PHP, comme ça a été dit, il s'agit soit de comparer deux langages, soit de comparer des concepts et tout ce qui gravite autour. Il ne faut pas non plus confondre développeur et architecte logiciel. Et finalement c'est pour l'architecte que le langage qui sera utilisé aura bien plus d'impact que le développeur. Une syntaxe n'a jamais été une barrière pour un développeur, sauf mauvaise foi. Alors lire du "php c'est moche" c'est vraiment pas un argument. Un code peut-être joli avec les deux langages hein, c'est comme pour tout une simple question d'habitudes.

    Et puis choisir entre PHP et JAVA pourquoi ? La question pourrait être "Que choisir en 2009 : PHP, JAVA, C#, Flex, Ruby, ...etc. etc." qu'elle n'aurait pas plus de sens, car tout ce qu'on peut faire dans un de ces langages peut être fait dans un autre. Il ne s'agit pas juste de choisir Java ou PHP, et même pas pour une question de goûts. Il y a bien plus de paramètres qui entrent en jeu. La plupart ont été cités.

    Un des plus important pour moi reste l'architecture, et c'est la lacune des frameworks PHP aujourd'hui. Je dis bien une lacune des frameworks et non pas du langage ! Les frameworks PHP manquent encore de certaines briques qui permettent de mettre en place une architecture en couches solide et utilisable immédiatement.
    Mais c'est aussi historique, et il faut remettre les choses dans leurs contextes. PHP souffre de la mauvaise réputation que lui a collé sa version 4. En effet PHP est vraiment Objet depuis sa version 5 seulement, et c'est seulement à partir de là que nous avons vu émerger des frameworks robustes, c'est donc très récent. Depuis, l'avancée est hallucinante, mais il manque encore certaines étapes. Mais ça pousse, et ça va venir.
    Avant, les cours de PHP en DUT c'était : "Regarde ce qui est génial avec PHP c'est que tu renommes ta page toto.html en toto.php et ensuite tu peux l'enrichir comme tu veux. Regarde, essaie par ex. de foutre ta connexion MySQL ici...etc.". Résultat, les développeurs qui n'ont pas cherché plus loin et qui on rejoint une société qui ne cherche pas plus loin non plus (et il y a en beaucoup !) continuent ces mêmes pratiques. Sauf qu'aujourd'hui je vois que certaines écoles enseignent directement autour d'un framework comme Zend ou Symfony. Et ça change la donne !

    Aujourd'hui, en tant qu'architecte si je dois designer une application 3 ou 4 tiers et que le dév. doit débuter immédiatement, effectivement je choisirais plutôt JAVA, mais plus que le langage, c'est un framework que j'aurais choisi. Si maintenant on me dit que j'ai le temps pour que mes développeurs implémentent les quelques fonctionnalités qui manquent au framework PHP pour répondre à mes problématiques, et bien je fonce, et c'est certainement pas le langage qui va me rebuter. Au contraire, c'est plutôt très formateur et ça permet de bien comprendre tous les rouages des design patterns. Combien de développeurs JAVA, qui vont utiliser par ex. Spring et Hibernate savent ce qui se passe derrière ? Ok, un bon argument est de dire que ça n'intéresse pas forcément les dév. de savoir. Mouais

    En ce moment je suis sur une appli. assez importante qui sera éventuellement distribuée, et bien avec Zend nous avons réussi à faire des merveilles. Mais effectivement il a fallu tout un dév. de plus bas niveau pour pouvoir arriver à nos fins. Le résultat est que nous avons pu implémenter tout ce qui nous manquait (Services, DTO, IOC). J'ai un développeur JAVA qui bosse sur le projet, il râle un peu parfois à raison, mais la première chose que j'entend quand il retourne sur du JAVA c'est : "Rhaaa j'ai fait deux modifs et 4 minutes de compilation, maintenant je me suis habitué avec PHP !". Donc chacun apporte son lot de bienfaisance pour les développeurs

    Niveau performances, c'est vraiment difficile de donner l'avantage à un des deux langages. Encore une fois ça dépend trop des frameworks et de ce qu'on en fait. Avec l'IOC par ex. ça peut vite être catastrophique.
    Les systèmes de caches quand ils sont bien utilisés gomment presque toute la différence car il faut quand même préciser que PHP est un langage qui repose sur un interpréteur qui est lui même bel et bien compilé pour s'adresser au processeur. Les systèmes de cache d'opcode permettent de ne pas recompiler certaines parties à chaque requête (en gros hein :p).

    Quand je vois les performances de notre appli. qui n'est pas encore tout à fait optimisée, et bien je me dis que ce n'est vraiment plus un problème. Et que ce soit PHP ou JAVA, ça ne fera pas beaucoup de différences. C'est plutôt du SGBDR et des opti. des requêtes qu'il faut s'inquiéter maintenant. Parce que ok c'est pas forcément utile de savoir ce qui se passe derrière hibernate, mais parfois ça ferait prendre conscience aux développeurs de ce qu'ils font avec le lazy load (bref !).

    Maintenant, un gros problème, la liberté de PHP. Effectivement il est possible d'être rigoureux, mais quand je vois un dév. JAVA qui vient sur PHP, il commence par râler et puis ensuite il commence à profiter de cette liberté pour faire des trucs pas toujours très jojo, et ça c'est un vrai problème. PHP oblige à avoir une certaine rigueur personnelle, alors que JAVA nous l'impose (bon ça forge aussi, mais quand même :p).

    Pour ce qui est de l'hébergement, il faut quand même avouer que c'est bien plus simple d'installer un environnement LAMP qu'un environnement pour JAVA, et moins coûteux donc. Mais c'est toujours pareil, c'est vrai pour une appli. de base, mais pour une appli. qui nécessite du clustering, load balancing etc. c'est la même galère.

    Je ne saurais vous inciter qu'à patienter et voir ce que PHP va devenir. Surtout avec l'arrivée des nouvelles moutures de certains frameworks, Zend 2, Symfony 2, Doctrine 2 qui s'inspirent beaucoup du monde JAVA !

    Dans tout ça, je n'ai fait que citer deux ou trois paramètres que je met en avant, mais évidemment nous pourrions écrire un bouquin rien que pour aider une équipe à se décider sur un langage. C'est infini.

    A+ benjamin.

  20. #180
    Membre du Club
    Profil pro
    Inscrit en
    avril 2006
    Messages
    51
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : avril 2006
    Messages : 51
    Points : 64
    Points
    64

    Par défaut

    Je ne voulais pas trop en rajouter sur les performances, surtout que je ne peux pas donner de détails technique, la boite ne souhaite pas publier ce genre de chose, super! Mais avec l'annonce de Facebook, je vais me permettre ce dérapage.

    Bref, dans cette boite, on veut changer notre frontal web, aujourd'hui c'est du EzPublish. Étant donné que le site peut être énormément *sollicité* c'est l'un des plus gros de France, une équipe de test de charge a été mis en place.

    Afin de changer le frontal, des tests de charge ont donc été fait sur des CMS PHP comme Java (Drupal, Ez, etc..., Alfresco, Nuxeo, etc...). Ayant déjà l'expérience d'avoir un site fortement stressé, nous avons toutes les optimisations PHP possible dont bien sûr le cache d'OpCode.
    Les tests sont sans appel, tous les CMS PHP sont tombés, alors que même le plus mauvais CMS Java tenait la charge. Dans les faits, on prendra tout de même un CMS PHP pour des raisons pratiques et de besoins. D'une manière générale si vous choisissez PHP faites attention aux performances, il ne faut pas soupeser ces besoins pour votre client, évidement ce genre de problème sera plus ou moins visible suivant le trafic.

    Ce n'est pour rien que FaceBook, l'un des site les plus visiter au monde dit que PHP est lent! Et c'est pour ça qu'un compilateur PHP devrait être annoncé aujourd'hui. Je pense que ça changera la donne à propos de PHP, en tous cas sur le secteur des performances. 80% d'amélioration, rien que ça !

    Je ne suis toujours pas un pro PHP, mais je comprends que les gens qui font du PHP, disent que le langage (et l'écosystème) s'améliore. Effectivement ça mérite d'y faire plus attention.

    Sources :
    http://www.readwriteweb.com/archives...p_compiler.php
    (edit) http://www.readwriteweb.com/archives...th_project.php

    Un de mes posts précédant qui parle de test de performance.
    http://www.developpez.net/forums/d73...a/#post4776944

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •