21-09-2011, 05:22 PM
(Modification du message : 21-09-2011, 08:45 PM par 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.
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.
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 --).
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.
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.
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).
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.
(21-09-2011, 03:08 PM)Hideaki a écrit : 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.
(21-09-2011, 03:08 PM)Hideaki a écrit :Citation :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 --).
(21-09-2011, 03:08 PM)Hideaki a écrit : 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.
(21-09-2011, 03:08 PM)Hideaki a écrit :Citation :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.
(21-09-2011, 03:08 PM)Hideaki a écrit :Citation :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).
(21-09-2011, 03:08 PM)Hideaki a écrit :Citation :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.