L'auteur, Aegir en l'occurence, nous livre son avis sur la question et selon lui aucune des deux solutions n'est totalement satisfaisante.
Alors même si Apache est largement plus déployé, si PHP tend à se généraliser, les alternatives existent-elle ?
Aller plus loin
- L'article sur LinuxFrench.net (10 clics)
# Langage typé !?!
Posté par nemerid . Évalué à 10.
Je programme par exemple en ruby et le fait de ne pas déclarer de type donne une souplesse incroyable. On manipule les listes, les objects en un clin d'oeil avec les même fonctions et très sincèrement, quand on a besoin de performances, je suis d'accord pour coder ça avec des langages de bas niveau, mais je pense que Apache/php on vraiment leur place et que leur succès n'est pas un hasard.
Par ailleurs, cela n'empêche pas d'utiliser xml ou des css2 avec php pour séparer contenu et présentation.
[^] # Re: Langage typé !?!
Posté par lorill (site web personnel) . Évalué à 10.
Je sais pas pour php, mais les langages de scripts comme Python ou Ruby sont typés. Oui, oui.
Tu n'as pas besoin de déclarer le type d'une variable, mais la valeur de la variable est typée.
Tu crois vraiment que y'aurait besoin des classes Nil, FixNum, Float, etc... si y'avait pas de type ?
[^] # Re: Langage typé !?!
Posté par matiasf . Évalué à 10.
C'est la même chose pour php.
Les variables sont typées mais il y a beaucoup de conversions implicites :
exemple :
$i = 1.5 ; // $i est un float
echo "nombre: " . $i ; // $i est toujours un float mais php fait une "cast" implicite en chaine de caractère (pour changer le type, il faut une initialisation ou utiliser settype() ).
Les types principaux sont :
- entier
- flottant
- chaine de caractère
- tableau
- objet
- ressource ?
[^] # Re: Langage typé !?!
Posté par nemerid . Évalué à 10.
La lecture de cet article m'a tout de même choqué sur certains points, car l'auteur donne des points de vues très subectif du genre que ceux qui sont pas d'accord avec moi sont des nuls en informatique.
Il ferait bien de garder un peu de recul et surtout faire preuve de moins d'arrogance, cet auteur...
[^] # Re: Langage typé !?!
Posté par Wawet76 (site web personnel) . Évalué à 10.
Enfin bref. Moi je trouve ça plus sympa quand les langage sont fortement typés.
- Il n'y a pas à réfléchir "comment ma variable va être interprété ici ?"
- Quand on utilise mal une variable, on a une erreur à la compilation (ou à l'execution pour les script) plutôt qu'un comportement inattendu. (qui peut en plus passer inaperçu...)
[^] # Re: Langage typé !?!
Posté par G. R. (site web personnel) . Évalué à 10.
C'est utile pour la lisibilité du code d'abord, ça facilite les possibilités d'optimisation pour le compilateur / interpréteur, ça permet de mieux spécifier le comportement du programme (du moins plus simplement).
J'aime beaucoup le langage Haskell (en ce qui concerne le typage) parce qu'il utilise un système de typage dynamique qui peut être contraint par le programmeur.
On a donc tous les avantages du typage explicite, sans les inconvénients.
[^] # Re: Langage typé !?!
Posté par matiasf . Évalué à 10.
J'ai développé en PHP, C et C++.
Chaques languages a ses avantages. Mais perso, je ferait pas un site web en C ou C++ :o) .
Enfin le problème de la séparation des données/traitement et de la présentation (de façon plus large l'interface homme-machine et non uniquement la présenation) existe partout même en développant en C++ ou en java .
[^] # Re: Langage typé !?!
Posté par Pierre Jarillon (site web personnel) . Évalué à 10.
Je citerai la perte d'une sonde vénusienne due à une toute petite erreur : un point au lieu d'une virgule.
DO 100 I=1,1000 ! faire la boucle 1000 fois
100 CONTINUE ! etiquette de fin de boucle
Le point ayant remplacé la virgule, le compilateur a compris :
DO100I=1.1000
Il a créé la variable double précision DO100I et lui a affecté la valeur 1.1.
Je regrette le pascal et surtout que ADA ne se soit pas généralisé.
Un langage que je regrette à un autre titre, c'est le HPL, issu des machines à calculer de bureau. C'était un langage-OS d'une puissance fabuleuse, que ce soit pour inverser des matrices, faire du pilotage de machines ou de l'acquisition.
[^] # Re: Langage typé !?!
Posté par Moby-Dik . Évalué à 8.
http://www.lysator.liu.se/c/bwk-on-pascal.html(...)
[^] # Re: Langage typé !?!
Posté par peau chat . Évalué à 10.
De toute façon, on s'en fout, à part delphi plus personne n'utilise le PASCAL.
aegir
[^] # Aaahhhhrrrrgggg
Posté par chrtela . Évalué à 10.
Quelques exemples ?
> The size of an array is part of its type
Et puis quoi encore ? On peut manipuler des pointeurs en Pascal, et on a des tableaux dynamiques, et des tableaux de Variants pour faire du OLE, et des objets listes, et des Hashtables...
> Types and Scopes
Là, Kernighan nous explique les faiblesses du typage Pascal. Sauf qu'entre temps, le Pascal est devenu objet...
> The Environment
L'environnement de développement Pascal serait pauvre. C'était vrai en 81, encore en 83, plus depuis... Jamais entendu parler de Delphi ?
Bref, tout ça pour dire, les préjugés, c'est bon de les remettre en cause de temps en temps. Tous les 10 ans, ça semble suffisant.
[^] # Re: Aaahhhhrrrrgggg
Posté par Moby-Dik . Évalué à -2.
Ce serait plus simple de mettre OLE à la poubelle.
Et puis, c'est tellement beau, les Variants, on a l'impression de faire du typage dynamique en assembleur.
Sauf qu'entre temps, le Pascal est devenu objet... [...] L'environnement de développement Pascal serait pauvre. C'était vrai en 81, encore en 83, plus depuis... Jamais entendu parler de Delphi ?
C'est standard, tout ça ? Y a un compilateur dispo en logiciel libre, et multi-plateforme ?
[^] # Re: Aaahhhhrrrrgggg
Posté par DPhil (site web personnel) . Évalué à 5.
Tu connais pas FreePascal et Lazarus ?
[^] # Re: Aaahhhhrrrrgggg
Posté par Sylvain Rampacek (site web personnel) . Évalué à 0.
NB : Kylix (Linux) = Delphi (Windows)
[^] # Re: Aaahhhhrrrrgggg
Posté par Moby-Dik . Évalué à -3.
- le standard du Pascal moderne qui-fait-tout-bien
- le compilo en logiciel libre multi-plateforme (et performant, tant qu'à faire)
- les librairies standardisées elles aussi
[^] # Re: Aaahhhhrrrrgggg
Posté par peau chat . Évalué à 7.
www.iso.ch ou bien www.ansi.org
(en particulier ISO/IEC 10206 : 1991 )
Une copie est ici : http://www.pascal-central.com/docs/iso10206.txt(...)
En ce qui concerne la partie Objet, en voici le Draft :
http://www.pascal-central.com/OOE-stds.html(...)
le compilo en logiciel libre multi-plateforme (et performant, tant qu'à faire)
Gnu-Pascal, Free-pascal ... virtual pascal (celui la je sais pas s'il est libre ou seulement freeware).
[^] # Re: Aaahhhhrrrrgggg
Posté par chrtela . Évalué à 2.
A part ça, non, j'ai pas tellement l'impression de faire du typage dynamique en assembleur. J'ai "bêtement" l'impression de faire du typage dynamique en pascal. J'ai faux ?
Ensuite, non seulement il y a effectivement un standard, et une solution libre (voir les autres posts), mais en plus, sachant que Borland est quasiment seul sur ce marché, quelle est l'importance du standard ? Le pascal objet de Delphi est un standard de fait, et le seul à ma connaissance qui soit utilisé en entreprise.
[^] # Re: Langage typé !?!
Posté par Bureau Pierre . Évalué à 2.
Faut arreter 10 secondes, si les gens etaient mieux formés ca irait mieux aussi...
[^] # Re: Langage typé !?!
Posté par boubou (site web personnel) . Évalué à 3.
[^] # Langage typé !?! Trop Typé !?!
Posté par darkleon (site web personnel) . Évalué à 3.
Il s'agit d'ariane 5, et elle s'est planté à cause d'une variable trop typée (en fait un type borné)!!!
En fait le code était déjà utilisé sur Ariane 4, et la variable d'accéleration utilisé par le "navigateur" était bornée à une valeur de X g (je ne connais pas la valeur X), en cas de dépassement de cette valeur (constraint error en ADA) le programme déduisait qu'il y avait un problème.
Et en fait Ariane 5 ayant une accéleration plus forte que Ariane 4, la fameuse valeur X a été dépassée et le navigateur s'est réinitialisé, ce qui a changé les coordonnées du points d'arrivée qui sont devenues 0,0,0 (le pas de tir).
La fusée s'est braquée à fond pour revenir au pas de tir, et comme elle n'est pas prévu pour ça, elle a commencée à se casser entrainant l'auto-destruction automatique.
Il n'y aurait pas eu de problème si l'accéleration avait été codée sur un pauvre float non bornée, et la première Ariane 5 aurait été un succès.
D'un autre côté, le fait d'avoir un typage fort permet de rejetter toute situation qui n'entre pas dans le domaine de l'application. Mais encore faut il bien vérifier que le domaine supposé codé dans le programme correspond bien au domaine réel.
C'était le cas avec Ariane 4, ce n'était plus le cas avec Ariane 5.
CE N'EST PAS UNE ERREUR DE PROGRAMMATION, C'EST UNE ERREUR DE VALIDATION.
[^] # Re: Langage typé !?! Trop Typé !?!
Posté par peau chat . Évalué à 1.
Arianespace a voulu faire l'économie d'un de ces boitiers électroniques (qui doit faire 1 ou 2 millions d'euros l'unité).
Les tests de qualification «normaux» prévoyaient de «consommer» 3 de ces boitiers.
2 ont biens été utilisés lors des tests prévus, mais le troisième n'a pas été utilisé, sous le prétexte que "cette partie là est la même qu'Ariane 4".
Lors de réunion, certains ingénieurs on fait la remarque que ce n'éait pas conforme au plan qualité (mais rien de plus qu'une remarque puisqu'ils n'étaient pas responsables de cette partie là).
Pour être plus précis, je ne crois pas qu'il s'agisse d'un problème de "G" (accélération) mais d'un problème de "poussée" et le programme original ne prévoyait pas qu'une poussée puisse être aussi élevée.
(Sur un engin plus lourd, il faut une poussée supérieure pour obtenir une accélération équivalente).
Dans le même domaine, on a un historique de bugs autant comiques qu'édifiants :
La trentative précédent juste la première réussite de satellite américain (qui a permis de découvrir les ceintures de van hallen) à fait une magnifique explosion sur le pas de tir. Raison : un pupitreur à confondu "moins" et "tiret". Ceci dit, cet échec a été particulièrement instructif, cela à permis à la NASA de tester la télémétrie (ils ont pu suivre la trajectoire du satellite projeté par l'explosion à travers le pas de tir).
Une des premières sondes VENUS (NASA encore) est passée à 2 000 000 km de vénus au lieu de 2 000. Cause : un programme faisait la confusion entre le point décimal et le séparateur des milliers (Arf' DECIMAL POINT IS COMMA).
Plus récemment, une sonde de la NASA vers mars s'est écrasée sur la planète rouge comme une bouse. Cause : des programmes calculaient en yards, et d'autres en mètres.
Dans le même genre de trucs amusants, on peut citer un crash évité de justesse lors d'un vol d'essai du chasseur F-14 : au passage de l'équateur, l'informatique de bord à "cru" que l'avion était sur le dos...
# bash-cgi ROXOR !!!
Posté par Francois Revol (site web personnel) . Évalué à 8.
sinon y a aussi perl qui ROXOR :)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
# Alternative ?
Posté par Ramso . Évalué à 10.
http://www.zope.org/(...)
C'est un serveur d'application basé sur python (C pour certains algos), multi-plateforme, objet, puissant et souple... et open source oeuf corse !
Pas de bricolage ici, tout a été conçu dans l'optique d'un framework web et objet. Les décideurs pressés ont une interface de travail, les hackerz écrivent leurs extensions en python.
C'est vraiment à essayer !
Comment ça je sors ?
[^] # Re: Alternative ?
Posté par Nicolas Roard (site web personnel) . Évalué à 10.
En gros l'idée est d'utiliser le framework *step (ici GNUstep) dans la création de site web dynamique. Du coup, tout est proprement objet, des objets prédéfinis pour gérer des objets de base (textarea, etc.) html existent, on peut bien sur en faire de plus complexes (menu, caddie, etc.) ...
Et on profite de *step : grâce aux objets distribués, c'est un jeu d'enfant de faire du load balancing, l'abstraction d'accès aux SGBDR permet de passer de MySQL à PostgreSQL ou Oracle sans se poser de questions, etc.
Evidemment, le contenu et la forme sont proprement séparés.
Bref ça roxe pas mal :)
[^] # Re: Alternative ?
Posté par Guesdon Manuel (site web personnel) . Évalué à 6.
http://www.alcove.com/alcove/newsletter/index(...)
[^] # Re: Alternative ?
Posté par Nicolas Roard (site web personnel) . Évalué à 0.
En tout cas, merci pour ton travail, je viens de me mettre à GNUstepWeb et je trouve ça vraiment épatant. Chapeau !
[^] # Re: Alternative ?
Posté par matiasf . Évalué à 6.
> C'est vraiment à essayer !
Une autre alternative. Mais c'est plustôt une extention de php :
http://www.midgard-project.org/(...)
# Houuuuuuuuuuuuuuu
Posté par Moby-Dik . Évalué à 10.
Un extrait qui tue...
«C'est pas que java/EJB soit mauvais, c'est seulement que les « application serveur » auxquels je pense n'apportent pas grand chose de plus que des problèmes et des factures. Coder en L3G c'était bien il y a 15 ans, mais maintenant on veut quand même du RAD»
[^] # Re: Houuuuuuuuuuuuuuu
Posté par Infernal Quack (site web personnel) . Évalué à 5.
Ce type a rien capté à J2EE.
Je le vois mal faire ce qu'on fait avec J2EE avec du PHP :)
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Houuuuuuuuuuuuuuu
Posté par Stanis Humez . Évalué à 5.
[^] # Re: Houuuuuuuuuuuuuuu
Posté par VACHOR (site web personnel) . Évalué à 8.
[^] # Re: Houuuuuuuuuuuuuuu
Posté par Infernal Quack (site web personnel) . Évalué à 10.
- Gestion de pools de connexions aux bases de données,
- Gestion du cycle de vie de tes Objets (panier, contrat,...) par le serveur applicatif,
- Véritable respect du modèle MVC (Model-View-Controller) avec des objets adaptés,
- Programmation objet garantisant un temps de mise en place plus rapide et une maintenabilité plus aisé (AMA),
- Connecteurs divers pour mainframe et autres gros machins déjà existant pour certains serveurs J2EE,
- Possibilité de faire des transactions de façon assez facile sur tout ce qui peut l'être (BD, Mainframe, fichier,...),
- Tag Librairies qui permettent d'alléger le code,
- ... (j'ai pas d'autres trucs en tête pour l'instant)
Voilà à peu près.
PHP a pour lui le fait qu'il est libre, proposé par plein de FAI et qu'il est assez simple à programmer.
En gros :
PHP = site perso, forum, ...
J2EE = Applications-webs, intranet, site B2C,...
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Houuuuuuuuuuuuuuu
Posté par peau chat . Évalué à -3.
NetDynamics aussi d'ailleurs (mais Sun a racheté ND et l'a fait mourrir pour qu'il n'y ait pas de concurrence aux J2E).
Bref, pas besoin de J2E pour faire ça.
[^] # Re: Houuuuuuuuuuuuuuu
Posté par Infernal Quack (site web personnel) . Évalué à 3.
Par contre l'avantage de J2EE c'est que c'est du Java et que ça sert pas que pour les serveurs applicatifs
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Houuuuuuuuuuuuuuu
Posté par peau chat . Évalué à -2.
[^] # Re: Houuuuuuuuuuuuuuu
Posté par Infernal Quack (site web personnel) . Évalué à 2.
L'avantage de J2EE c'est qu'il est normé donc une aplli développé pou l'un tournera ailleurs
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Houuuuuuuuuuuuuuu
Posté par peau chat . Évalué à -2.
[^] # Re: Houuuuuuuuuuuuuuu
Posté par pthivent . Évalué à 8.
- gestion de session, gestion de contexte
- gestion du pooling de connexion
- gestion du fail-over
- gestion du load-balancing
On notera qu'en général, les serveurs applicatifs viennent avec leur langage (propriétaire dans la plupart des cas).
A ce titre, il me semble qu'on peut dire que SilverStream (avec NetDynamics, ATG Dynamo, ...) faisait partie des premiers serveurs applicatifs.
Quant à J2EE... Construite au-dessus de la plate-forme J2SE, la plate-forme J2EE est dédiée aux développements d'applications d'entreprise orientés serveur et web. J2EE fournit un ensemble additionel de standards et de librairies permettant entre autres l'intégration de technologies d'entreprise hétérogènes.
Comparer SilverStream à J2EE n'a donc pas de sens, J2EE étant avant toute chose un modèle de développement.
Mais J2EE a effectivement son lot de serveurs applicatifs certifiés très très chers. Et SilverStream ne s'est pas imposé. L'ouverture de Java, la richesse de ses APIs, la stratégie de Sun et la qualité des serveurs applicatifs ont manifestement su séduire les entreprises. L'heure n'est plus vraiment à la lutte. D'ailleurs, beaucoup d'éditeurs de progiciels horizontaux ont recentré leurs actvités et se concentrent aujourd'hui sur l'édition de solutions verticales compatibles J2EE.
Maintenant, je ne dis surtout pas que le PHP est une solution qui doit systématiquement être écartée. Tout est une question de besoin et le choix de la technologie d'implémentation doit s'inscrire dans une problématique globale.
[^] # Re: Houuuuuuuuuuuuuuu
Posté par Stanis Humez . Évalué à 5.
- fiable,
- facile et rapide à programmer,
- suffisamment performant à ce jour,
- pas cher à mettre en oeuvre...
En entreprise, on raisonne en termes de coût global, à savoir :
- acquisition de licences,
- compétences humaines nécessaires,
- temps de développement,
- maintenabilité et évolutions futures,
- pérénité
Et dans toutes ces cases (ou presque, no troll !), PHP gagne. Si on avait besoin de créer des intranets pour des grands groupes de plusieurs milliers de personnes, avec gestion des RH, compta, paye, gestion documentaires ou je ne sais quoi, je me poserais la question de l'intérêt de J2EE, mais dans les cas que nous rencontrons au jour le jour (gestion de stock, commerce électronique "de base", bases de données d'articles ou de personnes...), PHP suffit chaque fois. Et les exemples de "gros" sites fonctionnant en PHP se multiplient.
Pour mettre en place un intranet, on arrive avec une distrib Linux, Apache, PHP et MySQL et on installe nos fichiers directement sur le serveur, paramétrage limité, déploiement immédiat, coût ridicule.
Pour que nous nous lancions dans le J2EE ou dans un serveur d'applis, il faudrait que le "ticket d'entrée" soit abordable, à savoir :
- licences libres,
- compétences de programmation "simples",
- formation limitée,
- installation et configuration simples,
- machines pas trop puissantes
A ce jour, on propose des intranets pour les PME à des tarifs pouvant descendre sous les 5000, développement et déploiement compris. Si PHP ne permettait pas ce qu'il permet, nombre de "petits comptes" n'auraient pas les moyens de s'intéresser aux nouvelles technologies...
Ceci dit, je garde constamment un oeil sur J2EE car un jour, ça baissera, des licences libres apparaîtront (ou deviendront compétitives si elles existent déjà) et l'installation sera simplifiée.
Et tous les avantages dont tu parles, outre le fait qu'ils peuvent déjà plus ou moins être contournés, seront sans doute parmi les améliorations des futures versions de PHP, ça évolue tellement vite !
[^] # Re: Houuuuuuuuuuuuuuu
Posté par Éric (site web personnel) . Évalué à 5.
- Clusterisation automatique sans ajout de code avec réplication des sessions,
Je ne peux pas dire que c'est aussi bien et encore moins que c'est sans modif de code mais il existe un serveur de session qui pourra ainsi permettre les réplications (ou alors monter un meme disque en partage sur tes cluster pour les session)
- Gestion de pools de connexions aux bases de données,
Ca existe aussi via les fonctions de connexion permanentes. Bon, c'est plus ou moins bien fait vu que c'est propre à un process et non à tous mais ca répond déjà à la pas mal de problemes. Les autres bénéficieront surement de la possibilité d'installer une application intermédiaire qui fait exactement ce boulot (je n'ai pas de nom sous la main mais j'en ai vu passé)
- Gestion du cycle de vie de tes Objets (panier, contrat,...) par le serveur applicatif
Donc là tu utilises un serveur applicatif. Tu peux utiliser Midghard (pas sur de l'orthographe) ou SRM qui feront ca pour php.
- Véritable respect du modèle MVC (Model-View-Controller) avec des objets adaptés
Là il ne tient qu'a toi. En rien le langage ne t'interdit de respecter un MVC. Si pour toi php c'est forcément les scripts perso avec tout plein de html et logique mélangés il serait bien de revoir ton jugement.
PHP = site perso, forum, ...
J2EE = Applications-webs, intranet, site B2C
Bof .. pas d'accord.
Applications web tu met quoi sous ce terme ? je vois que ca n'a pas la meme portée mais php peut encore convenir à pas mal d'usage qui correspondent à ce terme et c'est peut etre un manque d'expérience mais je ne vois pas ce qu'il n'est techniquement pas possible de faire mis à part quelques connexions à des systemes qui existent en java et pas encore en php.
Intranet là c'est encore plus flagrant
et à la limite je préfèrerait faire une base php quitte à faire "la" grosse appli en java
site B2C : ca fait aussi tres terme marketing. Ca veut dire site de commerce en ligne en gros .... vu le nombre de ces sites en java et le nombre en php je pense que tu dois etre dans le faux.
Je suis loin de mettre java et php au meme niveau pour tout mais aller dire que php reste pour les sites perso ca ne me semble pas tres bon.
[^] # Re: Houuuuuuuuuuuuuuu
Posté par boubou (site web personnel) . Évalué à 2.
[^] # Re: Houuuuuuuuuuuuuuu
Posté par Baptiste SIMON (site web personnel) . Évalué à -1.
-1
[^] # Re: Houuuuuuuuuuuuuuu
Posté par Gérald Quintana . Évalué à 3.
"Ensuite, en ce qui concerne les EJB, je me suis toujours demandé quel était l'intérêt de mettre le transactionnel dans de l'applicatif JAVA, alors que ça fait 15 ans qu'on sait le faire avec de biens meilleures performances dans le SGBDR lui-même."
L'intérêt des transactions au niveau objet plutôt qu'au niveau base:
- Faire des transactions disitrbués sur plusieurs serveurs
- Ouvrir une transaction en incluant différents types de base de données (1 Oracle+ 1 DB2) voire autre chose que des bases de données relationnelles: vive l'EAI
- Rendre les appels de méthodes (au niveau objet donc) atomiques, pour ne pas pourrir modèle objet si la transaction échoue.
- Pour automatiser la gestion des transactions (descripteurs de déploiement...)
[^] # Re: Houuuuuuuuuuuuuuu
Posté par peau chat . Évalué à 3.
Pour vous répondre, je ne connais personne qui se soit risqué à faire de la transaction multi-sgbd de cette manière, parce que justement l'atomicité n'est pas garantie.
Si sur un SGBDR je fais un :
BEGIN TRANSACTION
UPDATE TOTO...
UPDATE TATA...
COMMIT
Je suis certain que si le microprocesseur crame brusquement entre les deux updates, lorsque le SGBDR sera redémarré l'update sur la table TOTO sera annulé.
Par contre, si je fais depuis une machine tierce A un :
BEGIN TRANSACTION
UPDATE MachineB.ORACLE.TOTO...
UPDATE MachineC.DB2.TATA...
COMMIT
La machine tierce A est bien obligée d'envoyer un COMMIT successivement à B et à C. Faudrait pas que le microprocesseur grille entre les deux commit, sinon bonjour le bazar ;-)
Une solution possible, serait de gérer également un transaction-log au niveau de la machine tierce A, mais dans ce cas là, si la machine A est down, vous ne devez plus utiliser les SGBDR des machines B et C au risque d'un joyeux bazar... Et puis, une des caractéristiques de JAVA est d'etre complètement isolé du système. Alors comment s'assurer qu'une écriture est effectivement effectuée physiquement et ne traine pas dans un buffer de l'O/S ?
J'ajoute également que les différents SGBDR ont leur propre gestion de concurrence d'accès (certains mettent un verrou exclusif lors d'une eécriture et d'autres non), alors on fait comment si les bases de données sont utilisées par d'autres applis ?
Le mécanisme de répliquation entre 2 SGBDR du même éditeur, et de même version est déjà extrêmement délicat à mettre en oeuvre par l'éditeur du SGBDR lui-même alors ...
Quant à l'histoire de la portabilité qui serait un avantage par rapport à des procédures stockées, ça se réfute. C'est vrai qu'une proc stockée n'est pas portable d'un SGBDR à un autre, mais c'est aussi vrai qu'une requête toute bête en SQL n'est pas portable (quid des IsNull() COALESCE() et autres DECODE() ?).
L'argument des performances se réfute également. On entend dire que les EJB "soulagent" les SGBDR. Il n'en est rien ... ou presque. Les EJB font ce qu'ils veulent, au final c'est bien le SGBDR qui doit gérer les lectures/ecritures de données. L'application serveur peut éventuellement soulager le SGBDR des calculs (on calcule 1+2 au niveau de l'AppServ au lieu du SGBDR) mais :
- Bien souvent, cela supprime la logique ensembliste, ce pour quoi sont justement optimisés les SGBDR.
- L'overhead absolument est énorme, surtout en JAVA avec sa machine virtuelmle, sa sandbox etc. Si vous utilisez la (les) machines qui servent à fournir la puissance de calcul nécessaire à vos EJB pour faire tourner une autre instance de votre SGBDR, avec une réplication entre chaque instance du SGBDR, et un load balancer tout simple, vous vous en sortirez bcp mieux et bcp plus simplement.
EJB c'est un bon modèle, mais c'est pas une panacée. C'est *PARFOIS* utile, tout comme un moniteur transactionnel est *PARFOIS* utile.
Il faut toujours garder une chose en tête, pour savoir douter :
- L'intérêt de SUN est de rendre les clients dépendants d'eux (alors qu'avant ils ne l'étaient pas).
- L'intérêt de SUN est de vendre des machines.
# L'article est sans intérêt.
Posté par matiasf . Évalué à 10.
Il enfonce des portes ouvertes :
- les languages script c'est pas bien car c'est pas compiler.
- les languages qui nous allègent du type des variables c'est null car les variables ne sont pas typés.
Des conneries dans ce style.
Enfin, il site explicitement Apache/php et IIS/asp mais ce qu'il dit est valable pour toutes les solutions de ce type et donne l'impression qu'apache c'est la même chose qu'IIS (et il faut ne rien connaitre à apache pour le croire) et que PHP est une copie de ASP.
Un article a éviter.
# Quelques remarques
Posté par RB . Évalué à 10.
1_ Problème des passwords de DB dans le script:
Soit disant que ce n'est pas bien que l'administrateur puisse lire ces données. Si un appelle une personne administrateur c'est qu'elle doit pouvoir administrer le site. Si tout le site c'est un gros exécutable compilé appelé en cgi et que l'admin peut rien faire ce n'est plus vraiment un admin. De plus, l'accès à la DB est relatif au site, l'admin à donc accès à la partie de DB qu'il doit pouvoir consulter/modifier afin, je me répète, d'administrer son site. Donc à mon avis c'est un faux problème. Si on tient vraiment à masquer tout ça et à limiter l'admin à une gestion de template HTML par exemple, on peut grâce à certains outils préinterprêter le PHP et ainsi masquer le code et les accès.
2_ problème de vitesse
C'est aussi à mon avis un faux problème de rejeter les problèmes de vitesse sur le PHP, alors que ceux qui font des pages savent que le gros problème se sont le très grand nombre de requêtes SQL pour chaques pages. A moins de calculer la 10'000ème décimale de PI sur chaques pages, arriver à faire ramer du PHP sans accès à des DBs est très très difficile (sur une machine 'standard' et une page PHP simple, la génération de la page prend en gros moins d'un centième de seconde, ce qui représente environ 400'000 pages par jour tout de même). Les solutions pour la vitesse existent: mécanisme de cache dont certains sont gratuis, préinterprétation, ... mais comme dit précedemment, en général le problème vient surtout des accès aux DB. Pour améliorer cela on peut générer du html à partir de PHP et d'accès au DB, et une fois généré, on le stocke sur le disque et pendant X minutes on envoie le HTML plutot que de le refaire. Bien sûr, ce mécanisme ne peut pas s'appliquer à toutes la page ou à toutes les pages, mais on peut par exemple générer un menu qui ne change quasi jamais via ce système plutot que de le calculer à chaques pages. Certains système de templates utilisent aussi ce mécanisme.
3_ Séparer le contenu de la présentation
Au début, on met tout dans le PHP, c'est effectivement nul. Ensuite on fait des systèmes de gestion (en PHP) qui stockent le html séparément, dans des bases sql ou sous forme de fichiers. Le peu de données générées et écrites sur la pages directement par le PHP peuvent être formatée en métant un indicateur de class dans l'output et en le reliant avec une style sheet. Sans compter les systèmes de template comme Smarty, FastTemplate, qui servent justement à faire que des tierces personnes puissent bosser sur le site et uploader du pseudo HTML sans problèmes. Donc oui, on peut séparer à 99% le contenu de la présentation, il suffit juste de programmer les outils pour, ou d'utiliser ceux très bons qui existent déjà.
4_ Typage, puissance du language
C'est vrai que les débutants en prog aiment bien le non typage. Quand on a des projets plus gros à faire, parfois on aimerait bien pouvoir comme signalé dans l'article pouvoir bénéficier d'une meilleure analyse syntaxique grâce au typage. L'autre avantage du typage est l'optimisation, mais le PHP n'étant pas compilé cela n'entre pas en ligne de compte. En même temps, les fautes sont passablement bien signalée en PHP si on active tous les warnings et en pratique on trouve et résoud les problèmes aussi vite que dans un language typé.
Voilà, je ne suis donc pas convaincu par cet article. Je trouve dommage que l'auteur cherche tjs à illustrer des points négatifs alors qu'il sait pertinnement bien que pour la plupart des exemples évoqués il y a des solutions à mon avis viables.
Je signale encore juste que dans les prochaines versions de PHP (4.3 je crois), il y aura de grandes améliorations au niveau de language, côté orientation objet, classes avec constructeur/déstructeur... ça n'a rien à voir avec l'article mais ça montre que PHP bouge très vite et va vraiment dans le bon sens.
[^] # Re: Quelques remarques
Posté par matiasf . Évalué à 4.
Moi je me ferais pas chier pour faire une critique de leur article aussi longue. Celà sous-entend qu'il y a matière à discution. Ce n'est pas le cas.
C'est article est vide.
[^] # Re: Quelques remarques
Posté par Éric (site web personnel) . Évalué à 7.
Le probleme des mots de passe de base de donnée n'est pas le fait que l'admin ai acces à la BDD. Comme tu le dis dans 95% des cas il est normal que la personne capable de rajouter/modifier les scripts ou cgi soit capable de toucher au contenu de la bdd avec les meme droits que les scripts en question.
Par contre avoir des mots de passe en clair pose un autre probleme : celui d'une faille dans ton appli ou sur le serveur. Si quelqu'un arrive d'une maniere détournée à lire un de tes scripts (via une entrée mal protégée, via un faille d'un logiciel sur le serveur, via ..) il obtiendra le mot de passe pour acceder à la bdd, et ca c'est plus génant.
Déjà parce que nombreux sont ceux pour qui l'accès aux données est beaucoup plus grave que l'acces en lecture aux cgi et parce que si tu met à jour le programme en faute deux jours apres le méchant lui aura toujours accès à la base via le mot de passe (et au FTP/SSH chez les mauvais hébergeurs qui mettent un pass identique)
Dire que celui qui a accès aux scripts devrait avoir acces à la BDD donc que mettre un mot de passe n'est pas génant revient à dire
- les mots de passe systeme peuvent etre mis tous en clair dans un fichier controlé par root car de toute facon pour le lire il faut etre root
- les mots de passe en bdd peuvent tous etre mis en clair dans la bdd vu que l'acces est controllé par le sgbd.
C'est AMHA nier lla possibilité d'avoir des failles non encore connues dans son systeme et prendre des risques inutiles.
Bon, apres il faut faire la part des choses et les scripts apportent beaucoup de contreparties (il ne me viendrait pas à l'esprit de faire du C pour le web si je n'ai pas besoin d'un CGI qui fait des gos calculs) mais il ne faut pas dire que le probleme est un faux probleme.
[^] # Re: Quelques remarques
Posté par Moby-Dik . Évalué à 9.
Certes mais avoir des machins compilés ne change rien au problème. On peut récupérer le mot de passe en clair dans la section data (par exemple) du binaire. C'est un peu moins immédiat, mais pas vraiment bloquant pour quelqu'un de déterminé.
Il est de toute façon recommandé de bloquer tout accès à la base depuis l'extérieur (firewall et/ou config du sgbd - skip_networking sous MySQL par exemple).
[^] # Re: Quelques remarques
Posté par boubou (site web personnel) . Évalué à 1.
# c ki ce mec ??
Posté par goof . Évalué à -3.
- l'avantage que ca soit non "typé" est simple on peut mettre un entier dans une chaine de caractere simplement et d'autres truc aussi.
- le fait que ca soit un "bete" fichier texte et qu'il ne soit pas compliqué aporte une simplicité d'utilisation par raport au CGI compilé
- le code source n'est lisible que sur le serveur donc pr une personne qui as potentiellement tous les droits sur les bases de données et les fichiers.
- Un language compilé est plus "critique" en execution que du language interpreté par le serveur web car les failles sonts plus sensibles car plus pres du code machine.
- Java est compilé pour un processeur "virtuel" emulé par la machine sur laquel on le lance.
la meme question peut se poser coté client avec javascript VBscript Perlscript et autres car dans mon projet de BTS on utilise un javascript mais il n'y as aucune solution universelle pour tous les navigateur mis a part le HTML pure mais c'est vraiment pas ce qui donne le meilleur de ce qu'on veut faire
Ne pas oublié que PHP est fait pour le web avant tout pour le web alors que le VBscript est a peut pres dans tout les produits microsoft (excel word IIS ...) Java ne se limite pas au sites internet meme si c super pour certains trucs ca permet aussi de faire de "vrais" applications comme Perl qui est souvent cantoné au CGI.
c quand meme domage de limiter un language a un domaine si il a emerger d'un autre besoin.
[^] # Re: c ki ce mec ??
Posté par thedidouille . Évalué à -1.
Puis Python/Zope, c'est vrai que c'est pas mal (attention, j'ai pas dit que le reste etait moins bien!). Il y a beaucoups d'offre d'emploi en ce moment qui requiere de bien les maitriser.
[^] # Re: c ki ce mec ??
Posté par G. R. (site web personnel) . Évalué à 10.
Pour revenir sur quelques points :
- le fait de pouvoir mettre, comme tu dis, un entier dans une chaîne et vice-versa est peut-être pratique quand tu t'amuses ou quand tu fais des programmes de trois lignes, mais pour des choses plus sérieuses, le typage est un outil bien utile.
Au cas où tu ne le saurais pas, le typage fort est arrivé assez tard dans la programmation.
- Compiler un programme, ce n'est franchement pas très dur, même s'il est vrai qu'un interpréteur peut réduire un peu le temps de développement, mais pas de manière drastique.
- Un trou de sécurité est un trou de sécurité, et le fait de compiler ou pas n'y change rien.
[^] # Re: c ki ce mec ??
Posté par Infernal Quack (site web personnel) . Évalué à 3.
Quand on fait i + j on sait jamais si il va faire la somme ou concatener et faire une chaine et c'est la prise de tête.
Perso le typage c'est beaucoup mieux pour la maintenance et pour éviter les plantages quand l'appli tourne car à la compil on évite déjà les erreurs de typage
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
# Cocoon php?
Posté par Dalton joe . Évalué à 2.
Quelqu'un peu il m'eclairer?
[^] # Re: Cocoon php?
Posté par Gloo . Évalué à 2.
"j'attends toujours un serveur applicatif, basé sur XML, qui permette de séparer données, présentation, traitement des données, et dont le code est à la fois compilé, déclaratif et fortement typé [et libre]"
J'aime cocoon.
[^] # Re: Cocoon php?
Posté par Nicolas Roard (site web personnel) . Évalué à 4.
Les applications sont bien sûr compilées, on travaille en ObjectiveC, etc.
Ceci dit c'est vrai que Cocoon est peut être plus connu (au moins dans la communauté Apache); mais par exemple PHP supporte l'XML également...
Ce genre de solution existe déjà, implémentées d'une multitude de façons, donc je ne comprends pas trop les griefs d'Aegir...
[^] # Re: Cocoon php?
Posté par Yann KLIS (site web personnel) . Évalué à 2.
D'une part, c'est devenu un projet avec une architecture très propre, séparant effectivement il me semble de manière efficace, les données de la logique de la présentation. D'autre part, l'architecture utilisée à base d'extraction de données et en les formattant au format XML (on peut simplifier comme ça une partie du boulot accomplit par Cocoon) se révèle très bien adapté dès lors qu'on manipule des dialectes XML. Par exemple, générer un graphe au format SVG à partir d'une base de données (de format natif XML qui plus est) est un jeu d'enfant. Bref, Cocoon roxor !
# Faut quand même pas aller plus vite que la musique...
Posté par Tzard . Évalué à 3.
Si je comprends bien, aegir il cherche un système de publication sur le web de type framework haut de gamme professionnel et libre qui plus est... qui cause xml évidemment pour la séparation des métiers (rédacteur, graphiste, développeur, admin, ...). Bah pour l'instant des implémentations yen a pas des masses... faut attendre ou retrousser ses manches!
Néanmoins, Cocoon est un bon candidat. Tout dépend de l'ampleur de l'application visée en fait.
Ca m'énerve ce genre de débat inutile, il y en a toujours qui veulent foutre de l'objet et des bases de données partout, surement une question de culture... de toute façon il n'y a pas beaucoup de bases de données xml natives disponibles pour l'instant.
De façon plus générale, il faut pas perdre de vue que le web du futur est basé sur le principe du balisage (vous savez comme tex et surtout sgml/xml) avec éventuellement des processing instructions (genre <?php ...?> ou <?perl ...?> en xml). Bon d'accord c'est un peu ancien comme concept mais c'est puissant et c'est comme ça qu'il faut penser le truc à mon avis. Pas en termes de programmation orientée objet, ou d'une implémentation particulière des standards du web. Come back to the source!
[^] # Re: Faut quand même pas aller plus vite que la musique...
Posté par Moby-Dik . Évalué à 0.
linuxfrench utilise spip, c'est déjà pas mal non ?
[^] # Re: Faut quand même pas aller plus vite que la musique...
Posté par Tzard . Évalué à 1.
# RAD et correctifs...
Posté par Baptiste SIMON (site web personnel) . Évalué à 3.
voilà ce que j'ai répondu à un commentaire qui m'a semblé bidon :
Je ne sais pas si vous savez, mais RAD, qui signifie Rapid Application Development, ne signifie pas développement rapide d'application (de manière littérale)... et non ! Cela signifie que l'on met rapidement à disposition du maître d'ouvrage (client) un prototype permettant de faire des tests d'utilisation (appelé parfois "beta-tests")... et ainsi rendre le logiciel modulairement fiable.
Il ne faut pas tout confondre !
En plus, assimiler RAD avec du VisualBasic a été la connerie de beaucoup de SSII qui se sont plantées (à ce niveau tout du moins). En effet, comme je l'ai dit plus haut, le RAD s'applique à un développement modulaire. Faire cela avec VB (ou autre semblable), il faut être sacrément rigoureux ! et le VB est l'inverse même de la rigueure ! Le RAD s'applique beaucoup mieux à des développement d'application programmées dans un langage orienté objets...
En gros RAD est une technique de développement en spirale. Chaque "couche" de l'application est développée de la manière suivante :
o analyse globale
o Conception globale
o Développement
o Finalisation
Chaque couche est appelée prototype et est en fait une version du logiciel final aux fonctionnalités réduites, permettant, comme je l'ai dit plus haut, de faire faire des beta-tests aux utilisateurs.
Bref, RAD est, il faut l'appuyer, prévu pour des conceptions modulaires d'applications. C'est à dire, destiné plutôt pour des langages (qui, lorsqu'ils sont bien utilisés) orientés objets ou pour des concepteurs très très rigoureux...
# Un article qui a au moins l'intérêt de se poser certaines questions
Posté par _seb_ . Évalué à 5.
Cela signifie au moins que le sujet abordé (en gros les solutions de scripting vont être dépassé par les solution de type Java, .NET, WebObject, etc) est devenu un sujet à débat.
aegir apporte un début de reflexion en citant le typage des données, language compilé ou language interprété, application selon le model MVC, solution de template et je ne cite pas tout.
Je me pose les questions suivantes: Les besoins actuels des entreprises (PME/PMI, Grands comptes) ne peuvent elles plus se contenter des solutions simples, rapides à mettre en place et fonctionnellement éprouvées (je parle des solutions de scripting tel que PHP) ? Est ce que ces entreprises, sous prétext d'un discourt marketing bien huilé de la part des grands éditeurs de solution logiciel (Microsoft, Sun...), ne font que suivre une certaine mode ? Les grandes avancées dans la recherche scientifique informatique ne sont elle pas minim au contraire de ce que laisse paraitre ces même grands éditeur de solution logiciel. Les solutions J2EE et autres .NET ne font que reprendre ce qu'il a toujours été possible faire. Ces solutions essayent simplement de strandardiser des principes (et de les breveter et certifier par la même occasion) de programmation qui ont déjà été, plus ou moins, réalisé.
Les langages de scripting ont été inventé parce que des gens ne voulaient pas se casser la tête (et perdre du temps) à programmer une application qui ne durera pas (Le PHP est né comme cela). Ces gens là (et les gens qui utilisent ces programme) doivent être conscient que la plus part des langage de scripting sont des langage de programmation "batards" dans le sens qu'ils ne respectent pas toutes les subtilités d'un langage de programmation plus aboutis (le typage par exemple).
[^] # Re: Un article qui a au moins l'intérêt de se poser certaines questions
Posté par anonyme512 . Évalué à 4.
Je reviens à la charge avec un exemple: Enhydra.
C'est un serveur applicatif OpenSource (au sens OSI mais pas FSF apparament), qui a pendant longtemps été développé par Lutris, une société californienne, en collaboration avec la communauté et quelques autres boîtes (dont FT et Evidian).
Enhydra Classic est purement Java, sépare bien données-manipulation des données-présentation, est XML/(X)HTML, JDBC/SQL, etc. Et il est basé sur Tomcat. Il gère bien évidemment les sessions utilisateur, et la répartition de charge via un module apache (le director), simple mais très efficace. Il gère également les pools de connexion à une base de données, etc.
Et il marche très bien, et pas mal de gens s'en servent.
Et puis un jour, Lutris a décidé d'implémenter Enhydra Entreprise, cette fois-ci J2EE.
Et Lutris a fermé. Impossible de vendre quoique ce soit autour de ce modèle (et surtout pas du service, comme Lutris le faisait): le marché appartient à de grosses boîtes qui vendent leur serveurs applicatifs à d'autres grosses boîtes, et personne là-dedans ne comprend vraiment ce qu'il vend et ce qu'il a acheté. Dans 80% des cas, un serveur applicatif J2EE dépasse de beaucoup les besoins.
Quand à Apache/PHP et à IIS/ASP, c'est carrément dommage de les mettre dans le même sac. Le problème numéro 1 d'ASP, c'est qu'ASP ne fait RIEN ou presque, c'est juste un conteneur de toutes les cochonneries MS qu'il vous viendrait à l'idée de mettre dans votre web: VB/JScript, ODBC/ADO, OLE/COM/DCOM/ActiveX. Bref, emmerdes et trous de sécurité à l'infini, quand à la stabilité...
PHP en revanche, ça ressemble plus au noyau Linux: plein de trucs dedans, écrits spécialement pour PHP et rien que pour PHP. Donc fondamentalement plus stable et plus sûr.
Après au niveau de l'utilisation... il existe des serveurs applicatifs en PHP aussi.. mais il est vrai que je trouve le langage PHP un peu pauvre, pour plusieurs raisons (le typage faible -mais c'est discutable-, pas de gestion bien foutue des erreurs -les exceptions Java-, pas de modèle objet bien foutu et complet -très utile pour une implémentation MVC propre, et une bonne maintenabilité-). D'ailleurs, c'est dommage que l'article n'en aie pas parlé, pour juste se concentrer sur le typage qui n'est qu'un exemple bien faible, somme toute...
# L'important c'est la taille !!!
Posté par Le_Maudit Aime . Évalué à 1.
L'auteur manifestement a l'habitude :
- d'avoir une grosse connexion,
- de bosser à plusieurs sur ce genre de projets,
d'où me semble t-il son insistance :
- sur les performances,
- sur le typage
Il est finalement assez facile de reconnaître à peu près tout le monde dans ce fil :
- ceux qui disent que les performances ne sont pas très importantes sont ceux dont la puissance de calcul est largement supèrieure à ce qu'il est possible de faire passer dans leur tuyau. et/ou qui de toutes façon n'utilisent le scripting que pour compter le nombre de visiteurs. Pour ceux-là le jour ou leur liaison internet mettra à genoux leur machine, il y aura des cierges à Notre-Dame des Modems.
- ceux qui disent que le typage c'est pas important n'ont jamais travaillé à plusieurs ou ne sont jamais revenus sur un code écrit 5 ou 6 ans auparavant.
En résumé cet article c'est pour ceux qui en ont des grosses.
bon -1 parce que la réalité est un peu + subtile et que je fatigue moi...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.