Si on peut plus déconner. :lol:
Et non même pas honte. :oops:
Version imprimable
Si on peut plus déconner. :lol:
Et non même pas honte. :oops:
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).
Hello,Citation:
Envoyé par seb92400
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.
;)
lol, bien sur, mais je vais continuer dans mon rôle de vieu con aigri et demander de faire un client lourd en PHP ....Citation:
Envoyé par FredPsy
merci :lol:
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]
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
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.Citation:
Envoyé par TheNOHDirector
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.
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.Citation:
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.
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...
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.Citation:
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.
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?
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?Citation:
É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:
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 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.Citation:
# 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 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.
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.Citation:
É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.
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é.
PareilCitation:
Encore une fois ce choix repose sur l'état actuel de mes connaissances et de l'état de l'art en 2009!
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 :ccool:
Merci, les tiens aussi, évidement d'autres défenseurs de PHP sont dans ton cas ;)Citation:
Envoyé par batataw
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.
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
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
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
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
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
100% d'accord, mais en Java aussi.Citation:
Envoyé par batataw
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.Citation:
Envoyé par batataw
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!
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.Citation:
Envoyé par batataw
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!
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.Citation:
Envoyé par batataw
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!
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
Indeed!Citation:
Envoyé par batataw
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
Oui, et, non:Citation:
Envoyé par batataw
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é.
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é ;)Citation:
Envoyé par batataw
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!
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.
Effectivement PHP a été pensé pour le WEB. Si tu veux dépasser ce cadre ca peut devenir vite compliqué.Citation:
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.
Le middleware c'est pas son point fort.
Si je dois choisir un seul language et ne plus en bouger je prendrais automatiquementCitation:
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.
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.
Il faudra que tu m'expliques car c'est un des gros différent que j'ai avec Java.Citation:
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
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.
Pour un projet WEB je ne pense pas que le support est limité. On peut tout faire avec PHP.Citation:
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.
La partie présentation est une petite partie d'un Framework comme Symfony ou Zend. Ils font bien plus que cela.
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...Citation:
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!
Les projets sur lequels j'ai travaillés sont en majorité des extranets.
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.Citation:
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.
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.Citation:
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.
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.
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).Citation:
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.
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.
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).Citation:
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.
La je seche car je ne vois vraiment pas ce que des librairies peuvent apportées hormis la supervision?Citation:
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!
Oui c'est vrai mais je parlais surtout des librairies.Citation:
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.
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?Citation:
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 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é.
Au contraire y'a du choix, tu peux utiliser des librairies de messagerie dédié tel que Gearman, Kestrel ou RabbitMQ.Citation:
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!
Avec la monté en puissance du Web2 et ses appels Ajax dans tous les sens, c'est devenu impératif.
Les tiens aussi :)Citation:
Envoyé par batataw
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
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
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
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
Oui mais à quel prix, en assembleur on peut tout faire aussi, il y a des Mainframe qui sont entièrement codé en assembleur!Citation:
Envoyé par batataw
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.
Effectivement je crois que pour Drupal et EzPublish au moins, PHP est masqué, c'est du langage "propriétaire" de ces frameworks.Citation:
Envoyé par batataw
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".
Effectivement l'OS est le socle, mais la JVM certifiée RTSJ joue un rôle aussi important en Java!Citation:
Envoyé par batataw
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.Citation:
Envoyé par batataw
Pour ton commentaire sur le scripting, je ne suis pas sur de comprendre en quoi il faciliterait ce genre de problématique.
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
Je suis d'accord, mais en Java c'est la même chose :)Citation:
Envoyé par batataw
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.Citation:
Envoyé par batataw
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
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.
OK, à essayer alors :)Citation:
Envoyé par batataw
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.Citation:
Envoyé par batataw
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.
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...)Citation:
Envoyé par benwit
Tiré de la notice Xdebug (après une recherche de 5 secondes sur Google !) :Citation:
Envoyé par benwit
Citation:
Xdebug allows you to log all function calls, including parameters and return values to a file in different formats.
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 TheNOHDirector
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...Citation:
Envoyé par benwit
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 ? ...
Phpunit est un superbe plateforme de test unitaire couplé a CruiseControl il fera la couverture de code sans aucun problème.Citation:
Envoyé par TheNOHDirector
N'oublie pas qu'il n'y a pas de compilation et il n'y pas de paquets à déployer en PHP.
La je reste sur ma faim, un developpeur PHP sera traiter tous les sujets du frontend au backend...Citation:
Envoyé par TheNOHDirector
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.
Ben non et encore heureux, la partie présentation est une infime partie de PHP.Citation:
Envoyé par TheNOHDirector
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.
La notion de "a chaud" n'existe pas en PHP, il n'y a pas besoin de container.Citation:
Envoyé par TheNOHDirector
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.
Mes connaissances sont limités sur ce sujet.Citation:
Envoyé par TheNOHDirector
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?
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.Citation:
Envoyé par TheNOHDirector
Pour moi PHP + Framework = Un des plus puissant outil RAD pour le Web.
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.Citation:
Envoyé par TheNOHDirector
Je l'ai déja dit mais avec Java tu es rapidement obligé de sortir le 38 tonnes quelque soit le projet.
:ccool:Citation:
Envoyé par TheNOHDirector
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
:mrgreen:
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.Citation:
Envoyé par hugo123
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 ?Citation:
Envoyé par batataw
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".
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.Citation:
Envoyé par batataw
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.
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
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.Citation:
Envoyé par batatawMes connaissances sont limités sur ce sujet.Citation:
Envoyé par TheNOHDirector
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?
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.
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
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.Citation:
Envoyé par batataw
Par exemple le framework Play en Java.
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.Citation:
Envoyé par seb92400
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 :D (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.
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
En fait, comme je le répete souvent un bon developpeur PHP aura aussi de solide base en administration systeme, Il n'est pas rare de trouver dans une annonce Administration Systeme Requis. Dans mon cas je fournis a l'administrateur la liste des modules dont nous avons besoin pour le serveur de prod.Citation:
Envoyé par TheNOHDirector
Tous ces modules ayant été testés et installés sur le serveur de Dev. Quant a la mise en prod j'ai connu de tout de ce coté la, ca allait de la copie de fichiers via FTP directement sur le serveur de prod a l'automatisation avec Webistrano (bien évidemment, ca n'a rien avoir avec PHP)
Oui, dans le cycle de développement logiciel "classique" une release est identifié pour passer en prod, sur cette release on ne fera que du bug fixing, comme cela serait fait dans n'importe quel autre language. Cette release peut etre fourni au client.Citation:
Envoyé par TheNOHDirector
Cela dit je travaille beaucoup dans des environnements Agile et RAD les regles sont différentes (spécifications mouvantes et livraisons plus fréquentes).
Tout ca repose sur un bon outil de gestion de configuration et des bonnes pratiques mise en places des le départ.Citation:
Envoyé par TheNOHDirector
Si des develloppeurs balancent leurs fichiers directement en prod c'est qu'une étape a été loupée lors de la mise en place des processus.
Je comprends mieux ce que tu veux dire, beaucoup de developpeurs font une confusion entre gros projet et projet avec de la profondeur.Citation:
Envoyé par TheNOHDirectorJe 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
En faite un projet meme avec des mécanismes complexes, meme s'il est tres gros. PHP et son écosysteme pourront faire l'affaire tant que c'est du Web.
En revanche si le projet prend beaucoup de profondeur (middleware, temps-reel), je ne dis pas que c'est pas possible mais ca risque de se compliquer, il faudra donc bien étudier l'architecture avant de se lancer.
Contrairement aux idées recus Facebook n'utilise pas que du PHP mais l'essentielle de son site est en PHP.
Je ne me lancerais pas dans une application pour une salle de marché ou de paris en ligne en PHP (contrainte de persistence et de temps réel trop forte)
en revanche une banque en ligne ne me génerait pas plus que ca.
Comme je le dis souvent un developpeur doit etre polyglotte, PHP répond tres bien au besoin d'Agilité et du RAD.Citation:
Envoyé par Delprog
Je suis pres a essayer ce Framework prometteur si j'arrive a la meme souplesse qu'avec les Frameworks PHP. Je le surveille de pres, j'attends les retours terrain. Je crains juste qu'il soit snobé par les puristes Java.Citation:
Envoyé par hugo123
Je ne suis pas surpris les languages de script ne peuvent pas conccurencer les langages "compilés" cela dit tout est une question d'équilibre.Citation:
Envoyé par TheNOHDirector
Si les performances sont le premier critere et que ton client ne veut pas investir dans un load balancer, il faudra peut-etre choisir un autre langage.
C'est vrai qu'une mauvaise architecture peut planter un bon projet.
Nous avons opté pour un proxy cache sur le projet sur lequel je travaille actuellement comme pour les journaux en ligne (Squid, Ncache).
Oui c'est bien ça qui fait peur et j'ai l'impression que c'est moins rock n roll en Java, même si les mauvaise pratiques peuvent toujours exister.Citation:
Envoyé par batataw
Nos équipes travaillent en Scrum et les itérations sont sanctionnées par des releases. De la même manière s'il faut faire un patch, ou un patch de patch, nos équipes livrent une release clairement identifiée. Je pense que ce ne serait pas gênant en PHP.Citation:
Envoyé par batataw
A ce sujet, un ami m'a parlé d'archive PHAR, qui pourrait être l'équivalent de WAR ou de JAR. Je ne connais pas bien mais peut-être que c'est un bon moyen d'archiver les releases (je trouverais ça plus clair qu'un fichier zip).
100% d'accord sur le polyglotte! Effectivement Facebook n'est pas fait que de PHP, de la même manière que Twitter n'est fait qu'en PHP ou Ruby.Citation:
Envoyé par batataw
Pour le RAD, j'avoue que Java manquerait parfois de souplesse vis-à-vis des langages script. A ce niveau je parle de souplesse de la syntaxe, et la souplesse de l'outillage (pas de l'IDE). Avec Groovy et Play, on retrouve cette souplesse, mais je pense qu'elle n'est pas adapté à tous les cas. Et l'intégration / interaction de ces deux "modes" n'est pas encore bien clair.
En ce qui concerne Play, je n'ai pas eu le temps de vraiment investiguer, mais ca fait quelques mois que je suis le projet, et je me demande encore dans quelle direction le projet va. Personnellement j'aimerais savoir comment ce projet marcherait sur/avec du code legacy.
Comme en Java y'a pas de fichiers indépendants tu ne risques pas de copier un fichier en catastrophe sur le serveur de prod. Au final si le projet PHP est bien configuré y'a pas de soucis à se faire.Citation:
Envoyé par TheNOHDirector
Oui je fonctionne de la même façon sauf avec l'intégration continu, ca se complique un peu.Citation:
Envoyé par TheNOHDirector
Tout ce que je sais c'est que c'est en standard avec PHP 5.3 et que ce fichier peut être déployé tel quel sur un serveur Web comme les WAR. Cela dit l'intérêt est limité si c'est juste pour l'archivage. Tu vas te donner du travail pour rien.Citation:
Envoyé par TheNOHDirector
c est mieux de travailler avec les deux mais php c est le top a mon avis
J'ai l'impression que les réponses sont tres orientées vers les aspects techniques meme si certains citent les processus de gestion de projet.
Je suis surpris de lire que Php ne tient pas de grosses charges face a Java. Car mon impression est que pour faire tourner une appli Java, c'est déja tres demandeur de ressource meme si l'application n'est pas utilisée. Le ratio charge/utilisation ressources n'est donc pas linéaire.
D'ailleurs pourquoi Facebook tourne en Php si ils considerent que c'est lent ? Question historique alors, ou de couts ?
Ca amene a ma réflexion selon laquelle la composante technique (rapidite, qualite du framework, etc), n'est qu'un des nombreux elements qui menent a un choix technologique.
Comme le dit TheNOHDirector, Php semblait une mauvaise solution technique, pourtant ... ils l'ont garder...
Il y a quelques mois, j'ai griphoné ce schema:
http://blog.vincentbrouillet.com/pub...hnologique.png
source: Quelle solution de technologie Web (n'hésitez pas a critiquer ou a apporter votre contribution, il manque pleins d'éléments)
C'etait un essai, mais je voulais juste émettre l'idee que finalement ... la technique ... c'est pas si déterminant. Et c'est dommage, mais c'est comme ca. Je me trompe ?
Actuellement je bosse sur un projet .Net (pour info je suis passé par Php, Java, Ruby). Je n'aime pas vraiment .Net. Mais bon, c'est un client corporate, historique Microsoft, tout ca. Meme pas la peine de se poser la question, il y a un gros effort d'integration dans leur environment pour cette application.
Y'en as d'autres qui ont le meme sentiment que moi ? Finalement comparer truc avec bidule, est ce que c'est important ? J'aimerai entendre que oui :)
Dans la mesure où on trouve un ensemble de fonctionnalités équivalente, que ton usage s'effectue sur une sous partie des fonctionnalités disponible, ALORS oui, la technique devient très accessoire.Citation:
C'etait un essai, mais je voulais juste émettre l'idee que finalement ... la technique ... c'est pas si déterminant. Et c'est dommage, mais c'est comme ca. Je me trompe ?
D'ici là, non, la <solution> technique reste déterminante dans la réalisation de la tâche.
Tu as mis le doigt dessus.Citation:
Actuellement je bosse sur un projet .Net (pour info je suis passé par Php, Java, Ruby). Je n'aime pas vraiment .Net. Mais bon, c'est un client corporate, historique Microsoft, tout ca. Meme pas la peine de se poser la question, il y a un gros effort d'integration dans leur environment pour cette application.
Y'en as d'autres qui ont le meme sentiment que moi ? Finalement comparer truc avec bidule, est ce que c'est important ?
Tu as utilisé du .net car il possédait un sous ensemble de fonctionnalités qui arrangeait bien la vie de ton client.
Et que pour le reste des besoins, que j'imagine seulement, n'importe quelle technos en vogue aurait pu répondre.
Donc à situations égales, on prend celle qui semble la plus simple, ici c'est celle qui propose de s'intégrer dans la situation donnée le plus facilement.
A tord ou à raison, l’exploitation du projet résultant en donnera une réponse.
non ?
a+
A ce propos : http://www.clubic.com/actualite-3230...hyper-php.htmlCitation:
Envoyé par VinceMD
Je n'ai pas lu l'intégralité des échanges qui pour la plus part commence à dater.
Mais une point revient souvent sur l'utilité de PHP par rapport à JAVA et je m'interroge sur la véracité de ces propos aujourd'hui en 2011.
Je vous soumet donc mon interrogation.
PHP est-il toujours dédié seulement au site web ou est-il enfin apte à faire des application WEB tel que le fait JAVA ?
Sinon j'ai voté PHP ne connaissant pas JAVA
C'est pour le WEB, c'est sa force et sa faiblesse.Citation:
Envoyé par llaffont
PHP = RAD orienté 100% WEB.
Heu ! Tu es sur de ta question, car pour avoir beaucoup travaillé avec les deux c'est plutôt la question inverse qui me vientCitation:
Envoyé par llaffont
Java est-il enfin apte à faire de vraies applications web comme PHP*?
Java est extrêmement riche face à PHP non pas au niveau du langage, mais au niveau des usages. On fait énormément de choses qui n'ont rien à voir avec les webApp avec java.
Mais pour ce qui est des applications Web, Java est longtemps resté un gros boulé.
Excusez le terme. Mais la génération d'IHM avec JSP voir struts et consorts et tout de même loin derrière la floraison de solution sous PHP. Leur complexité de mise en œuvre a longtemps fait que PHP était plus abordable.
là où PHP se montrait à ses débuts en retrait par rapport à java c'est sur la partie accès aux donnés, traitement métier, etc.
Mais les framework MVC en nombre montrent que ce n'était pas (que) un problème de langage.
Aujourd'hui, je ne saurais dire lequel je choisirais. Je pense que ce serait plus le projet lui-même qui m'imposerait une techno que les considérations sur les langages
car question montée en charge maintenance rapidité, etc. PHP a fait ses preuves.
Question professionnalisme, pareil. J’ai travaillé sur de gros projets PHP et je dois dire qu'ils sont aussi bien structurés que des projets java.
Je dois reconnaitre que pour ceux qui ne connaissent pas du tout une recherche sur le NET et on trouve tant de bricolages (infâmes) en PHP que ça laisse à penser que c'est un langage de bricolos.
Pour moi c'est un peu comme une brique et du ciment.
Pour faire une maison super pro, on peut utiliser du béton armé, avec des super structures, des calculs scientifiques, etc. et ça fera surement une super maison.
On peut aussi utiliser de la brique et du ciment.
Or la brique et le ciment peuvent aussi être utilisés par tout le monde pour bricoler un abri dans son jardin.
Les abris bricolés par dés amateurs enlèvent-ils de la valeur à la maison en brique*?
Il faut compter de nouveaux venus dans le cercle. Le mode traditionnel des webApp avec un fonctionnement page à page laisse la place à un mode plus client(IHM)/serveur(applicatif).
Je n'aime pas utiliser web2.0, car on y met tout et n'importe quoi.
Bref de plus en plus le client s'enrichit de fonctionnalité d'interface et ne fait plus appel qu'à des services applicatifs.
Du coup, Java vois la partie où il était plus contraignant s'éloigner.
PHP entre temps a montré sa force pour répondre à cette nouvelle approche. Il faut quelques minutes pour exposer une classe comme un service web selon les protocoles en vigueur dans ce genre d'échange.
Reste l'outillage. Peut d'outils de modélisation permettent de générer du PHP alors qu'ils sont floraison pour Java.
A+JYT
Très bonne analyse sauf pour les performances, PHP est un cran en dessous de Java.
En ce moment je suis sur un vieux projet Java full JSP, je peux te dire que c'est une vrai galère. En revanche dernièrement j'ai travaillé avec le Framework Java Play ce fut un régale. J'ai enfin retrouvé des automatismes que j'avais en PHP et le plaisir d'un IDE sur mesure (Eclipse). Même si je trouve qu'il lui manque quelques fonctionnalités importantes qu'on retrouve sur Rail, Django ou Symfony.
Java n'est pas vraiment un langage web, ça oblige à faire des applications très compliqués pour simplement faire un listing d'une base de données avec 3 critères.
Java est aussi très consommateur de ressources. Sur un service très utilisé ça ce passe assez bien mais le ticket d'entrée est très cher.
Critère supplémentaire Java n'est pas libre et à été racheté par Oracle, on est donc jamais sûr de ce qui va ce passer :( .
Pour ma part je suis amusé par les derniers commentaires car au sein de la communauté Java il se dit justement que Java est avant tout un langage pour faire du Web, bien plus que pour faire du client lourd.
Swing (pour le client lourd) est en perte de vitesse et Oracle ne semble pas vouloir le faire évoluer. Java Fx se cherche encore et n'est pas une réelle alternative a Silverlight ou même GWT.
Par contre pour le Web Java est très prisé même s'il a souffert d'une réputation de lourdeur a une époque, faute aux EJB et a quelques frameworks un peu touffu (Struts 1).
Aujourd'hui le choix de framework est suffisamment bon pour faire plaisir à toutes les sensibilités.
Pour répondre en détail :
- côté lourdeur de codage, Java s'est largement amélioré avec l'utilisation des annotations et l'apparition de certains frameworks lights (Play, Grails etc...)
- côté consommation de ressources : je veux bien voir un benchmark qui prouve que Java serait plus consommateur à service rendu égal ^^ Ca me donne envie de faire un petit comparatif d'ailleurs entre Play et Php. Je vais m'y mettre ^^
- sur le côté libre, peux tu développer ? Jusqu'à preuve du contraire Java n'impose toujours aucune contrainte de droit sur les applications développées.
Ce qui veut dire par "Java n'est pas libre" cet que Oracle son propriétaire peut très bien demain comme il l'a fait avec Solaris décider de rendre JAVA payant et interdire son usage Or de ses propres produits.
Même si c'est peu probable. même si cela arrivait il y aurait une levée de bouclier. c'est un fait.
Ca ne se produira pas. l'équilibre des force est trop important pour Oracle. mais qui sait se que nous réserve l'avenir.
Le libre usage de JAVA est suspendu au bon vouloir d'Oracle.
A+JYT
Peutetre que Java demande plus de ressources au lancement, mais PHP gère mal la mémoire allouée, pour ne pas dire qu'il ne sait pas du tout la gérer (ok, la notion de garbage collector est arrivée avec PHP 5.3). Personnellement, j'ai une sainte horreur des "Fatal Error" de PHP comme le "allowed memory exhausted". On peut pas les attraper, ni les prévenir et c'est une plaie à débugger. Du coup, soit on joue la facilité et on modifie le 'memory_limit', soit l'administrateur interdit la manip et on tombe dans des considérations typiques au C++ pour chasser les fuites mémoires.Citation:
Envoyé par VinceMD
Pour info, Facebook n'utilise PHP que pour son frontend et ils ont du réécrire le moteur pour améliorer les performances. C'est pas donné à tout le monde d'avoir des équipes dédiées au C/C++ et balèzes en algorithmie, pour éviter de refondre son frontend. Leur backend est en Java + Hadoop.Citation:
Envoyé par VinceMD
Personnellement, je préfère citer Google en exemple, avec ses Google Document et autres Google Wave, que je trouve inimaginables en PHP+Javascript.
On parle de lourdeur de codage en Java, je répondrai que la lourdeur est plutot la faute du développeur que du langage. Après, c'est beaucoup plus facile de refactorer en Java qu'en PHP, ne serait ce que parce que les IDE nous le permettent. Je trouverais vachement plus cronophage de refactorer une usine à gaz made in PHP, mm avec un IDE genre ZendStudio qui m'aura coûté un oeil.
De fait, je trouve qu'un développement fait avec Java est d'avantage pérenne que s'il est afit sous PHP.
J'orienterais mon choix entre PHP et Java suivant le dimensionnement du projet:
Si c'est un site statique ou sur un projet de qq semaines, ok pour PHP
Si le projet prend qq mois, ok pour PHP mais sous couvert d'un framework type Zend ou Symfony.
Si projet > 6 mois, je m'assurerais d'avoir un cadre de travail carré, avec des gens qui savent parler tests unitaires, motifs de conception, injection de dépendances, integration continue pour garder PHP.
Si on commence à parler d'interfaces dynamiques, c'est plutot le volume de fonctionnalités à développer en javascript qui me ferait réfléchir.
Si c'est un très gros site avec des centaines de connexions par jour, des besoins en temps d'accès rapides ou que sais-je, un compromis PHP-Java serait à étudier.
Dans tous les autres cas, je ne prendrais pas Java que si PHP m'est imposé.
l'avantage que je trouve à Java est de permettre au développeur de se concentrer plus facilement sur l'essentiel de la logique à implémenter. Il y a toujours un framework qui répond mieux que les autres à un besoin particulier. Alors que coté PHP, déja, le langage ne se suffit pas à lui même, ne serait ce que pour les IHM, et puis on doit réinventer la roue sans cesse pour encapsuler maladroitement telle ou telle fonctionnalité et enfin, il y a les erreurs fatales qu'on ne peut que subir.
à te lire je crois que tu connais particulièrement mal PHPCitation:
Envoyé par Ludalito
car question refactoring c'est l'outillage et non le langage qui est en cause et on trouve de très bons outils gratuit pour php qui le font (j'ai suffisamment refactoré du php pour le savoir)
pour ce qui est des fuites mémoire Java n'est pas mieux placé.
j'ai récemment explosé un serveur avec 36 Go de ram (oui Go)
comme tu le dit le développeur y est pour beaucoup et j'ajoute quelque soit le langage
une des force de java et une de ces difficulté est justement qu'il existe 30 framework pour faire ci ou ça et qu'il ne sont pas toujours très compatible avec un autre
je trouve qu'on perd beaucoup de temps à essayer de palier les problèmes relationnel des framework eux même.
Mais c'est surement du à une mauvaise connaissance de certain. il sont si nombreux.
inconvénient que je trouve à l'écosystème java (pas ua langage) c'est qui noie la logique applicative dans une cacophonie de composants.
alors on peut du coup se passer de tout un tas de framework et autre composant tout près. mais du coup les avantage de Java se réduisent car sa richesse n'est pas dans le langage mais dans l'écosystème qui l'entoure.
côté php c'est pour moi un peu pareil. soit tu te tape les chose à la mininee et tu ne bénéficie pas de la richesse du tout. soit tu en passe par des frameworks en tout genre et tu tombe sur les mêmes travers.
dans les deux cas c'est une question d'équilibre.
un point pour php dans les interaction entre framework c'est qu'il est faiblement typé. ça peut être un piège parfois et il faut être prudent
mais combien de temps je passe en java pour faire de la conversion de type !
par contre le cœur de php s'accompagne de lib compilées pour toute sorte de choses qui se retrouve dans la lib standard de java. et là je trouve que la lib java de base est mieux structuré plus propre que celle de php qui se traine encore trop de proc procédurale.
pour ce qui est de l'IHM deux chose soit tu as un IHM java et là php n'est clairement pas fait pour ça
soit tu as une webApp et perso je trouve que java est plutôt mal loti.
pour une appli dans le navigateur je ne trouve ni l'un ni l'autre à la hauteur. et de toute façon régénéré une page ou un morceau de page sur une simple action qui peut (et dois être faite chez le client) est un aberration. en 1996 dèjà sur les webApp dans le labo où je bossais j'avais intégré TCL dans le code HTML et j'éxécutais sur le poste du client tout ce qui n'a voir qu'avec l'IHM le serveur ne faisant que s'occuper du métier (logique et ressource) quand j'ai vu tout ce concentré sur les serveur j'ai crié à l'hérésie.
on avait tout mis sur le poste client qui était devenu ingérable avec les client lourd et le serveur qui ne s'occupait que des données qu'on à fini par demander au serveur de modifier les pixel de l'écran de chaque utilisateur.
aujourd'hui on redispatche intelligemment (enfin on essai) les fonction. l'IHM au client le métier au serveur.
à moins de passer à jnlp ou à ces applet Java je ne trouve as java des plus adapté.
Php ne fait pas beaucoup mieux trop encré dans la notion de webapp ou le serveur fait tout.
du coup Javascript qui maintenant est mieux supporté par les navigateur se présente comme une alternative. mais c'est une tout autre approche qu'il faut adopter. et on vos déjà les vieux travers revenir.
comme ouvrir un connexion SQL depuis son navigateur. ainsi on revient au client serveur avec tout les pb que cela pose.
perso je ne l'utilise que pour l'IHM dans mon approche MVC il gère la vue et le contrôleur le Métier côté javascript est un proxy qui fait appel à des service sur le serveur.
et pas plus.
dans ce contexte Java est robuste efficace et lourd. Php est rapide, vites mis en œuvre léger, et moins facile à faire monter en charge (énorme charge chez moi)
le plus souvent j'utilise SOAP, Rest ou Json-RPC entre le client js et le serveur php/java
l'avantage étant que lon peut changer de techno serveur (par exemple d'un proto à un grosse appli) sans rien changer au client si on respecte l'interface de service.
pour moi java ne se suffit pas à lui-même il lui faut toujours tout un tas de lib de framework et php est exactement dans la même position.
c'est vrai pour tout les langages.
ce qui peu éventuellement faire la différence c'est les librairies standard qui vont avec le langage.
C++ par exemple sans aucune librairie et tu ne peux même pas afficher un truc dans ta console. pour ça il te faut la STL c'est pareil en java.
Bref les manque que tu décris son pour moi plus un pb de connaissance du l'écosystème PHP que de réel manques. quelqu'un qui connais mal celui de java va lui faire les même reproche.
A+JYT
Bonjour à tous et à toutes;
J'ai besoin de votre, je suis un debutant en php j'ai réalisé un site web simple et je voudrais savoire comment réaliser un generateur de pdf après avoire valider la saisie d'un formulaire, j'ai fais pas mal des recherche mais je n'y arrive pas, j'ai essayé fpdf je n'arrive pas comprendre cmt l'implemanter ds mon code php, peut être je suis pas ds le bon forum mais vue votre debat, c'est un debat des pro donc je lance un appel d'aide à vous tous svp!!!
Pour le refactoring, je ne suis pas d'accord. Vu que java est fortement typé, les outils pourront faire beaucoup plus de choses qu'en php.
De meme pour la complétion (proposer uniquement ce qui est possible).
De toute facon, le débat est dans ces deux cas plus lié au typage.
je prefere PHP pour sa facilité d'appretissage ou sa prise en main rapide.
J'ai programmé pendant plusieurs années en PHP, l'apprentissage est rapide, il y a de la documentation mais le manque de données typées est embêtant à mon gout.
Depuis quelques mois je suis passé au JEE avec le framework Spring et voici mon constat :
- l'apprentissage est long ;
- tout est objet et c'est bien pour avoir une un modèle MVC ;
- Maven est très pratique pour gérer ses dépendances ;
- l'IDE Eclipse gère très bien JAVA, je n'ai pas encore vu d'équivalent en PHP ;
- les scripts PHP sont limités en temps d'exécution, en JAVA il y a des crons disponibles.