PHP, vos astuces pour palier à ses défauts ?

[srm]

Et si on avait une recherche pas dépendante du fait que l'on soit loggué ou non, ça serait REST vu que :

Dans cette architecture, un composant lit ou modifie une ressource en utilisant une représentation de cette ressource. Une ressource est une chose nommable, qui peut évoluer avec le temps.

Ce qui est le cas d'une recherche

[Sephi-Chan]

Exactement. Mais je doute que les moteurs de recherche (Google, Exalead & cie) souhaitent se priver d'information contextuelles (langue du navigateur, localisation, etc.).

[Hideaki]

Quelle mauvaise foi… Je suis certain que tu as très bien compris. Et j'espère que tu as également compris qu'il n'y avait pas de mécanisme de map comme en Java, donc plus de simplicité et moins de pertes.

Puisque je suis apparemment de mauvaise fois effectuons un petit test, j'ai installer railsintaller dernière version, créer un petit projet tout simple.
Le temps d'attente de la page est beaucoup plus long que le temps calculé ici.
J'ai relancé plusieurs fois le test (20 fois environ) et j'ai pris le meilleur résultat pour chaque test.

Le contrôleur :

class WelcomeController < ApplicationController



  def index

    @dstart = Time.now.to_f



    @var1=1

    ...

    @var100000 = 100000

  end

end

le code de la page

<p>Delta : <%= Time.now.to_f - @dstart %></p>

Le meilleur temps affiché est de 0,89 et en général proche de 1

Deuxième test même classe mais sans le @,
le meilleur temps affiché est de 0,019 et en général proche de 0,02

Tu conviendras avec moi qu'il c'est passé quelques choses pour avoir bouffé tant de temps ... donc tu ne peux pas dire que déclarer avec ou sans @ ne coute rien et mon explication reste valide

A chaque requête, le routeur détermine quel contrôleur doit être instancié et quelle action doit être appelé dessus.

Si je reprend ta phrase : 1 requête = une nouvelle instance de contrôleur, j'ai donc souhaité vérifié

class WelcomeController < ApplicationController

  #variable de classe

  @@instance_cree = 0



  #constructeur

  def initialize

     @@instance_cree += 1

   end

  

  def index

    @cree = @@instance_cree

  end



end

Le résultat est toujours 1.
Avec ce simple teste, il est clair qu'on utilise toujours le même contrôleur pour les même type de requête, avec la configuration par défaut
Je n'ai pas réussi à faire un ++ sur @@instance_cree es-ce possible en ruby ?

Il est vrai que tu apprends en cours, le fonctionnement interne d'une application java ou dotNet, maintenant leur fonctionnement général est, à l'instar des design pattern, un fonctionnement éprouvé que naturellement ruby repend sûrement, il est cependant plus difficile de trouver une documentation sur le fonctionnement de ruby sur ce point (surtout en français) qu'un autre langage plus populaire php par exemple, actuellement je ne peux pas affirmer que c'est un système similaire mais rien ne contredit encore une fois mes propos et pourquoi réinventé la roue alors qu'elle tourne bien ( pour les langages c'est autre chose mais on ne réinvente pas un design pattern ), je ne pense pas non plus que ce soit "java" qui aille inventé ce système, comme je l'ai dit dans l'un de mes précédent message que la facilité d'écriture d'un langage cache, le fonctionnement interne.

Pardon mais cette façon de balayer mon commentaire sonne encore la mauvaise foi…

Quelle genre d'obligation légale ?
C'est interdit d'avoir des URL propres en Java EE ?
Ou alors c'est mettre les paramètres de la recherche dans la requête qui est interdit ?

Comme je l'ai dit, cela ne concerne pas le langage mais la conception (ce n'est pas moi qui est de mauvaise fois), vouloir mettre un formulaire en POST, l'une des obligations légale dont je parlais est l'interdiction de présenté deux fois le même ordre de résultat pour la même recherche. Si tu veux savoir pourquoi, ils (les concepteurs) ont fait ce choix, le plus simple est de leur demandé et non je ne les connais pas
D'autres part lorsque tu parlais URL moche je pensais à rallonge etc ... cela aussi n'est pas lié au langage.

Choisir une technologie parce qu'elle est facile à héberger sur du mutualisé, c'est vraiment la loose. Quand on développe un projet sérieux, on peut investir 200€ par an pour louer un dédié/paas qui fait sauter les barrières technologiques et qui permet de choisir les technologies pour leurs qualités intrinsèques.

Pour certaine personne 200€/an, c'est un gros budget surtout pour se lancer, je vais troller un peu [TROLL] tu sous-entends que la technologie php n'est pas une technologie de qualité x)[/TROLL]

Bien sûr que tu trouves que développer en Java est facile : c'est ta techno préférée. Mais j'aurais aimé que tu répondes à ma question concernant les autres technologies Web que tu maîtrises bien.

Je ne souhaitais pas te répondre par rapport au mot "maîtrise", je ne considère pas que je maîtrise java, ni même le html, css, js etc mais je connais, je réserve ce mot "maîtrise" aux experts, comme on ne peut être expert en tout ... et j'étais certain t'avoir déjà donnée la réponse, il y a quelque temps en mp.
Dans les langages Web ( je parle ici de plateforme avec son écosystème car html est un langage web x) ) java, C#, php 4 (ca date mais j'avais commencé par cela)

[niahoo]

La technologie PHP n'est pas une technologie de qualité. Je ne penses pas que ça ait été dit autrement qu'ouvertement.

[Sephi-Chan]

Tout d'abord, je m'excuse d'avoir dit que tu étais de mauvaise foi. Je le pensais sur le coup mais le fait que tu fasses l'effort de mener quelques tests me prouve que j'ai eu tort.

Deuxième test même classe mais sans le @,
le meilleur temps affiché est de 0,019 et en général proche de 0,02

Tu conviendras avec moi qu'il c'est passé quelques choses pour avoir bouffé tant de temps ... donc tu ne peux pas dire que déclarer avec ou sans @ ne coute rien et mon explication reste valide

Mon propos portait sur le fait de passer des variables ou non à la vue : que je crée des variables locales (foo) ou des attributs (@foo), le temps pris est le même. C'est juste l'opération d'affectation qui prend du temps.

En somme, ça ne consomme pas plus de ressources de passer plus de données à la vue.

A chaque requête, le routeur détermine quel contrôleur doit être instancié et quelle action doit être appelé dessus.

Si je reprend ta phrase : 1 requête = une nouvelle instance de contrôleur, j'ai donc souhaité vérifié

class WelcomeController < ApplicationController

  #variable de classe

  @@instance_cree = 0



  #constructeur

  def initialize

     @@instance_cree += 1

   end

  

  def index

    @cree = @@instance_cree

  end



end

Le résultat est toujours 1.
Avec ce simple teste, il est clair qu'on utilise toujours le même contrôleur pour les même type de requête, avec la configuration par défaut
Je n'ai pas réussi à faire un ++ sur @@instance_cree es-ce possible en ruby ?

C'est parce que tu es en développement, l'environnement est chargé chaque fois. Si tu lances ton serveur en environnement de production (rails server -e production), tu auras le résultat escompté.

L'opérateur unaire ++ n'existe pas en Ruby (de même que --).

Il est vrai que tu apprends en cours, le fonctionnement interne d'une application java ou dotNet, maintenant leur fonctionnement général est, à l'instar des design pattern, un fonctionnement éprouvé que naturellement ruby repend sûrement, il est cependant plus difficile de trouver une documentation sur le fonctionnement de ruby sur ce point (surtout en français) qu'un autre langage plus populaire php par exemple, actuellement je ne peux pas affirmer que c'est un système similaire mais rien ne contredit encore une fois mes propos et pourquoi réinventé la roue alors qu'elle tourne bien ( pour les langages c'est autre chose mais on ne réinvente pas un design pattern ), je ne pense pas non plus que ce soit "java" qui aille inventé ce système, comme je l'ai dit dans l'un de mes précédent message que la facilité d'écriture d'un langage cache, le fonctionnement interne.

Rails a été un renouveau dans les frameworks Web. Ils ont effectivement réinventé la roue en chamboulant ce qui était institué par les solutions existantes (notamment celles des bons gros frameworks Java).

Le résultat était quelque chose de plus simple, de plus appropriés pour les besoins de la majorité des développeurs Web. Rails, c'est un peu le Apple des frameworks : ça peut tout faire mais ça met l'accent sur 20% des choses dont 80% des gens ont besoin.

Depuis, Rails a inspiré de nombreux frameworks : CakePHP, Play, Symfony, etc. Comme quoi il y avait bien une demande pour quelque chose de plus cool que les frameworks Java.

Pardon mais cette façon de balayer mon commentaire sonne encore la mauvaise foi…

Quelle genre d'obligation légale ?
C'est interdit d'avoir des URL propres en Java EE ?
Ou alors c'est mettre les paramètres de la recherche dans la requête qui est interdit ?

Comme je l'ai dit, cela ne concerne pas le langage mais la conception (ce n'est pas moi qui est de mauvaise fois), vouloir mettre un formulaire en POST, l'une des obligations légale dont je parlais est l'interdiction de présenté deux fois le même ordre de résultat pour la même recherche. Si tu veux savoir pourquoi, ils (les concepteurs) ont fait ce choix, le plus simple est de leur demandé et non je ne les connais pas
D'autres part lorsque tu parlais URL moche je pensais à rallonge etc ... cela aussi n'est pas lié au langage.

Je sais bien que c'est un choix de conception, je me moquais juste des développeurs d'applications Java qui sont incapables de conserver des URL propres.

D'accord, le but était d'empêcher de présenter des résultats dans le même ordre. Mais la conception n'est pas très réfléchie : ils auraient pu servir les résultats en GET avec les paramètres dans l'URL, comme le fait Google (http://www.google.com/search?q=ruby). Ça n'aurait pas empêcher d'avoir un tri aléatoire des résultats à l'affichage et ça aurait été plus utilisable : on aurait pu mettre la page en favori, par exemple.

Choisir une technologie parce qu'elle est facile à héberger sur du mutualisé, c'est vraiment la loose. Quand on développe un projet sérieux, on peut investir 200€ par an pour louer un dédié/paas qui fait sauter les barrières technologiques et qui permet de choisir les technologies pour leurs qualités intrinsèques.

Pour certaine personne 200€/an, c'est un gros budget surtout pour se lancer, je vais troller un peu [TROLL] tu sous-entends que la technologie php n'est pas une technologie de qualité x)[/TROLL]

Je n'ai aucun problème à dire ouvertement que PHP ne doit son succès que parce qu'il est arrivé au bon moment (en remplacement du couple CGI + Perl). Ce langage n'a aucune qualité.

Et 200€ c'est une somme, j'en conviens. Mais dans la vie il faut savoir ce qu'on veut. Mettre un peu d'argent de côté ou bosser avec des technologies de merde (langage pourri et serveur mutualisé très limité et limitant).

Bien sûr que tu trouves que développer en Java est facile : c'est ta techno préférée. Mais j'aurais aimé que tu répondes à ma question concernant les autres technologies Web que tu maîtrises bien.

Je ne souhaitais pas te répondre par rapport au mot "maîtrise", je ne considère pas que je maîtrise java, ni même le html, css, js etc mais je connais, je réserve ce mot "maîtrise" aux experts, comme on ne peut être expert en tout ... et j'étais certain t'avoir déjà donnée la réponse, il y a quelque temps en mp.
Dans les langages Web ( je parle ici de plateforme avec son écosystème car html est un langage web x) ) java, C#, php 4 (ca date mais j'avais commencé par cela)

Je parlais de maîtrise au sens large, celles avec lesquelles tu es capable de créer un système. Et je vois que tu tournes autour de technologies très proches les unes des autres : même syntaxes, même features (en moins évolués pour PHP), même tendance à être centrées sur elles-mêmes (sauf pour PHP), etc. Du coup, je comprends mieux pourquoi certains concepts t'échappaient.

[Hideaki]

Mon propos portait sur le fait de passer des variables ou non à la vue : que je crée des variables locales (foo) ou des attributs (@foo), le temps pris est le même. C'est juste l'opération d'affectation qui prend du temps.

En somme, ça ne consomme pas plus de ressources de passer plus de données à la vue.

Lorsque je parlais sans @ cela s'appliquait uniquement à varXXX puis que @dstart j'en ai besoin pour calculer le temps par conséquent je transmet bien quelques choses à la vue. Si transmettre une @variable prend 4,5 fois plus de temps qu'une simple variable ...

Rails a été un renouveau dans les frameworks Web. Ils ont effectivement réinventé la roue en chamboulant ce qui était institué par les solutions existantes (notamment celles des bons gros frameworks Java).

Le résultat était quelque chose de plus simple, de plus appropriés pour les besoins de la majorité des développeurs Web. Rails, c'est un peu le Apple des frameworks : ça peut tout faire mais ça met l'accent sur 20% des choses dont 80% des gens ont besoin.

Depuis, Rails a inspiré de nombreux frameworks : CakePHP, Play, Symfony, etc. Comme quoi il y avait bien une demande pour quelque chose de plus cool que les frameworks Java.

D'une part ce que tu appelles "gros" c'est l'architecture n-tiers qui offre bien des avantages contre plus de complexité toute relative. Il est tout à fait possible de faire du mvc2 de base. Je pourrais en dire autant des frameworks java comme spring qui a inspiré Symfony par exemple ... Le lourdeur, le côté non cool vient principalement du faite que tu ne connaisses uniquement que ce que tu as appris en cours et non de la pratique réelle pendant un certain temps.

Concernant le contrôleur effectivement cela fonctionne bien avec les paramètres d'environnement que tu m'as fournit, c'est dommage que cela ne soit pas par défaut cependant je comprends la problématique, puisque les données sont transmises à la vue de manière automatique un nouvelle objet est dans l'obligation d'être créé à chaque fois, niveau performance ce n'est pas top mais si cela procure un effet de bien-être chez l'utilisateur pourquoi pas.

Je sais bien que c'est un choix de conception, je me moquais juste des développeurs d'applications Java qui sont incapables de conserver des URL propres.

D'accord, le but était d'empêcher de présenter des résultats dans le même ordre. Mais la conception n'est pas très réfléchie : ils auraient pu servir les résultats en GET avec les paramètres dans l'URL, comme le fait Google (http://www.google.com/search?q=ruby). Ça n'aurait pas empêcher d'avoir un tri aléatoire des résultats à l'affichage et ça aurait été plus utilisable : on aurait pu mettre la page en favori, par exemple.

Faire d'un cas une généralité, le raccourci est un peu facile ... pour réduire les coûts, tu dois le savoir, ils (les SSII dans la majorité des cas) choisissent des personnes ayant peu d'expérience et il suffit que cela ne soit pas noté dans le cahier des charges pour qu'ils s'en moquent.

Je n'ai aucun problème à dire ouvertement que PHP ne doit son succès que parce qu'il est arrivé au bon moment (en remplacement du couple CGI + Perl). Ce langage n'a aucune qualité.

Et 200€ c'est une somme, j'en conviens. Mais dans la vie il faut savoir ce qu'on veut. Mettre un peu d'argent de côté ou bosser avec des technologies de merde (langage pourri et serveur mutualisé très limité et limitant).

Tu es mauvaise langue je suis certain qu'en cherchant bien, tu trouveras au moins une qualité

Je parlais de maîtrise au sens large, celles avec lesquelles tu es capable de créer un système. Et je vois que tu tournes autour de technologies très proches les unes des autres : même syntaxes, même features (en moins évolués pour PHP), même tendance à être centrées sur elles-mêmes (sauf pour PHP), etc. Du coup, je comprends mieux pourquoi certains concepts t'échappaient.

Pour la syntaxe, je connais d'autres langages comme lisp qui est très loin niveau syntaxe, ce n'est pas les concepts qui m'échappent, c'est que je me place toujours dans le cas où un système est optimisé, comme je l'ai dit plus haut créer un objet contrôleur à chaque fois n'est pas vraiment l'idéal en terme de performance mais il y a des cas où cela peut être utile.

[Argorate]

Heureusement que le but a la base n'était pas la critique du langage mais d'échanger sur nos astuces de programmations :roll:

[niahoo]

et bien la question concernant la surcharge des fonctions/méthodes a été répondue, mais si tu as d'autres points à soulever concernant php vas-y, seulement le langage est assez simple syntaxiquement.

[Sephi-Chan]

Si tu savais le nombre de développeurs Rails qui sont d'anciens développeurs Java… À l'évidence, ils ne trouvaient pas ça si fun.
À l'inverse, je ne connais aucun développeur Ruby qui soit passé à Java. Je ne comprends vraiment pas pourquoi.



Parmi le public qui utilise Rails, généralement les petites et moyennes entreprises, mais certaines très grosses l'utilisent aussi, le temps homme a plus de valeur que le temps CPU. On admet donc que Rails ne sera peut-être pas aussi performant que d'autres frameworks, mais qu'il permettra un développement plus rapide et une maintenabilité accrue (moins de code, moins de bugs).

[Hideaki]

Si tu savais le nombre de développeurs Rails qui sont d'anciens développeurs Java… À l'évidence, ils ne trouvaient pas ça si fun.
À l'inverse, je ne connais aucun développeur Ruby qui soit passé à Java. Je ne comprends vraiment pas pourquoi.

J'en connais

Parmi le public qui utilise Rails, généralement les petites et moyennes entreprises, mais certaines très grosses l'utilisent aussi, le temps homme a plus de valeur que le temps CPU. On admet donc que Rails ne sera peut-être pas aussi performant que d'autres frameworks, mais qu'il permettra un développement plus rapide et une maintenabilité accrue (moins de code, moins de bugs).

Effectivement moins de code, la différence n'est pas aussi importante que tu pourrais le croire, un cochon quelques soient le langage polluera le projet avec des copier/coller etc mais je convient que java a toujours été plus verbeux, la complexion automatique cela facilite l'écriture ( longueur des mots clefs ) pour la maintenabilité je n'ai jamais eu de soucis lorsque la personne d'avant n'était pas un cochon