Depuis quelques semaines, Ruby on Rails permet de développer des applications web avec Ajax.
Ruby est un langage de script (comme Perl ou Python), totalement orienté objet, avec une syntaxe très propre qui la programmation élégante et amusante.
Ruby on Rails est un framework de développement d'applications Web en Ruby, utilisant le modèle MVC. Oui, c'est vrai, il en existe déjà des dizaines. Mais grâce (entre autres) à son utilisation de Ruby, Rails permet de développer des applications Web jusqu'à 10 fois plus vite qu'avec d'autres frameworks (NdM. : ce type d'information est évidemment à prendre avec toutes la réserve nécessaire), avec un code bien plus concis. Ruby on Rails a provoqué ces derniers mois un petit ras de marée dans le monde des développeurs d'applications web, en remettant en cause le classique couple PHP/MySQL. D'autant plus que le support d'Ajax vient de lui être ajouté.
Ajax (Asynchronous Javascript and XML) est une vieille technologie : son composant de base, XMLHttpRequest, existe depuis 1998 et est utilisé un peu secrètement par de nombreux sites. Il permet de mettre à jour une page web sans avoir à recharger l'ensemble de la page (pour un petit exemple, postez un commentaire sur ce blog, c'est fait pour). Démocratisé par Google ces derniers temps (essayez par exemple de chercher quelque chose sur Google Suggest), son utilisation reste difficile, car il faut écrire du code compatible avec les différents navigateurs.
C'est là que Ruby on Rails montre tout son intérêt. Après avoir permis de développer des applications Web complexes sans écrire une ligne de SQL, Ruby on Rails permet de développer des applications Ajax en quelques minutes sans écrire une ligne de Javascript. Même si Ajax n'est pas la solution ultime, il permet de rendre des applications Web bien plus interactives et agréables pour les utilisateurs. Pas convaincu ? Essayez d'uploader un fichier sur cette page et admirez la barre de progression.
Aller plus loin
- Wiki en français sur Ruby (via WebArchive) (40 clics)
- Une explication du modèle MVC (8 clics)
- Rolling with Ruby on Rails, article d'introduction sur Onlamp (4 clics)
- Article d'introduction à Ajax sur Ruby on Rails (37 clics)
- Really getting started in Rails, à lire après les articles d'Oreilly (3 clics)
- Four Days on Rails : document de 40 pages (via WebArchive) (5 clics)
# Balèze
Posté par Miair Patreau . Évalué à 3.
[^] # Re: Balèze
Posté par blobmaster . Évalué à 3.
Ceci dit niveau perf disons que ça s'améliore.
c.f.
http://linuxfr.org/comments/590765.html#590765(...)
A voir aussi :
http://www.framasoft.net/article3991.html(...)
[^] # Re: Balèze
Posté par Miair Patreau . Évalué à 2.
# consommation CPU côté client ?
Posté par TazForEver . Évalué à 5.
Donc je m'interroge sur la performance. Surtout que les accès mobiles type Nokia 770 se multiplient.
[^] # Re: consommation CPU côté client ?
Posté par fork_bomb . Évalué à 2.
<troll>
Mozilla c'est trop lent.
</troll>
[^] # Re: consommation CPU côté client ?
Posté par Mathieu Pillard (site web personnel) . Évalué à 8.
J'ai développé une nouvelle version de la toolbar et posté un journal a ce sujet, il reste certaines optimisations a faire, mais j'ai tout repris depuis zero ou presque et c'est maintenant 3 fois plus rapide qu'avant. J'ai fait des tests en forcant mon cpu a 1Ghz, et meme sur des tres grosses niouzes, les temps d'acces sont honorables avec cette version.
Bref, oui, JavaScript est pas super rapide, mais en l'occurence, le probleme de vient pas de l'interpreteur.
# Google
Posté par Geoffrey Scoutheeten . Évalué à 7.
une fois qu'on connais l'existance d'AJAX, c'est rigolo de voir que le fait de cliquer un peu partout dans ses mails ne recharge que la partie centrale de la page, et pas les menus ...
L'un des défaut de cette technologie, c'est qu'on ne peux pas directement rajouter un "Bookmark" vers la/les page(s) en question, ou utiliser le bouton précédent.
[^] # Re: Google
Posté par Maurice Svay . Évalué à 3.
[^] # Re: Google
Posté par Gniarf . Évalué à 7.
voir aussi les millions de page avec une entrée ou des menus en flash, et inutilisables sans.
[^] # Re: Google
Posté par TImaniac (site web personnel) . Évalué à 1.
# Ruby On Rails
Posté par C2RIK . Évalué à 3.
Et quels sont les outils de développement disponibles ?
[^] # Re: Ruby On Rails
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
http://about.me/straumat
[^] # Re: Ruby On Rails
Posté par Miguel Moquillon (site web personnel) . Évalué à 2.
- Struts est un framework MVC sur lequel peuvent se gréffer des technos différentes pour les aspects Vue et Modèle. La partie Contrôleur est fournie par Struts, mais il fournit aussi ses propres technos côté Modèle et surtoût Vue pour les développeurs qui ne veulent pas s'embêter.
- JSF est une techno de gestion de Vues.
Ce qui fait que l'on peut utiliser JSF avec Struts car ils sont complémentaires et non opposés.
[^] # Re: Ruby On Rails
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
http://about.me/straumat
[^] # Re: Ruby On Rails
Posté par Miguel Moquillon (site web personnel) . Évalué à 1.
[^] # Re: Ruby On Rails
Posté par Yann KLIS (site web personnel) . Évalué à 2.
[^] # Re: Ruby On Rails
Posté par Nicolas Delsaux (site web personnel) . Évalué à 0.
Dans la blogosphère J2EE, des messages ont signalé une augmentation considérable avec des temps de développements divisés par un facteur de 5 à 10 suivant les cas.
Ruby pour Windows intègre un IDE complet écrit en Ruby+FOX (et franchement très lent chez moi).
On peut aussi utiliser un plugin Eclipse peu complet pouyr le Ruby.
En revanche, de manière spécifiquement dédiée à Rails, je ne sais pas trop ce qui peut exister.
[^] # Re: Ruby On Rails
Posté par gc (site web personnel) . Évalué à 4.
Quelle est la taille des applications RoR dont tu parles ?
[^] # Re: Ruby On Rails
Posté par Miguel Moquillon (site web personnel) . Évalué à 1.
[^] # Re: Ruby On Rails
Posté par gc (site web personnel) . Évalué à 2.
[^] # Re: Ruby On Rails
Posté par Damien (site web personnel) . Évalué à 1.
À côté de ça le typage statique ne dispense pas de faire des tests... avoir une étape de compilation allonge le cycle de développement, etc
[^] # Re: Ruby On Rails
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 3.
Enfin on n'a jamais dit qu'un typage statique évitait de faire des tests ... L'étape de compilation qui rallonge le cycle de développement ça fait sourire quand même :) Compilation incrémentale, tout ça. De plus des tests ne permettent souvent pas de tester _tout_, alors des vérification en plus personnellement je crache pas dessus.
[^] # Re: Ruby On Rails
Posté par TImaniac (site web personnel) . Évalué à 5.
T'as qu'à considérer l'étape de compilation comme une étape de tests générés et exécutés automatiquement. Tiens tout à coup c'est beaucoup plus productif et ca enlarge plus ton cycle de developpement.
[^] # Re: Ruby On Rails
Posté par bobefrei . Évalué à 2.
[^] # Re: Ruby On Rails
Posté par TImaniac (site web personnel) . Évalué à 4.
T'as déjà entendu parler de compilation incrémentale ?
Tu crois franchement que tu as besoin de recompiler systématiquement toute l'appli ?
La phase de compilation c'est de l'ordre de la seconde lors d'une phase de dev normale. Avec certains IDE (Eclipse, Visual Studio) c'est même fait en background avec retour instantané (surlignage de la faute) lorsque le developpeur tappe son code.
Et puis franchement cette phase de "compilation" c'est aussi pour gagner du temps à l'exécution. Bref, c'est tout benef, il n'y a aucun inconvénient en terme de productivité, au contraire c'est une première phase de test qui permet d'éviter bien des conneries.
[^] # Re: Ruby On Rails
Posté par Damien (site web personnel) . Évalué à 4.
Bien sûr c'est possible dans une certaine mesure et grâce à des artifices subtils (le compilo d'eclipse, zerolink dans XCode...) mais ça n'est pas aussi simple et clair qu'en ruby/python/smalltalk.
[^] # Re: Ruby On Rails
Posté par TImaniac (site web personnel) . Évalué à 3.
[^] # Re: Ruby On Rails
Posté par Éric (site web personnel) . Évalué à 3.
Ah ? chez moi les compil prennent du temps. Pour avoir modifié des sources de PHP récement, à chaque modif ça recompilait le fichier, puis l'extension dont dépendait ce fichier, puis la libphp4 avec l'extension en statique (non, dynamique ça collait pas), puis finalement le php-cli qui va avec.
Le tout était *très* loin de la seconde et très loin d'être négligeable.
Et franchement non, la phase de test et la phase de compilation sont deux choses séparées.
Le but de la compilation c'est de produire du code machine. Le but d'une phase de test c'est de vérifier ton code. Certes le gcc pour pouvoir compiler fait des vérifications, mais rien n'empêcherait techniquement une phase de test sans compilation.
Si tu es concerné par les tests/vérifications l'avenir ce sont des outils d'analyse de code qui repèrent les mêmes choses (syntaxe, mauvais appels, contrôles de type, ...). Ca n'impose en rien une compilation (ou plutot ça ne devrait en rien l'imposer) et c'est une mauvaise justification de l'étape compilation.
[^] # Re: Ruby On Rails
Posté par TImaniac (site web personnel) . Évalué à 1.
Moi je te parle de C++, Java ou C#, avec un vrai compilo qui vérifies le typage statiquement (quand c'est possible) et vrai IDE.
Et franchement non, la phase de test et la phase de compilation sont deux choses séparées.
T'auras beau dire tout ce que tu veux, le compilo fait un nombre incalculable de tests, surtout avec un langage à typage fort et statique. Que tu le veuilles ou non, quand le dev compile il fait une première passe de tests. D'ailleur les méthodes de dev récentes dites "agiles" comme l'XP préconise l'utilisation intesive des TESTS unitaires. Et bizzarement dans le cycle de dev on les faits souvent s'exécuter juste après la compilation, comme si c'était la suite logique des premiers tests...
Visiblement tu n'as rien compris à ce qu'est un compilo, à ce qu'il est censé faire. Il n'est pas censer que "pondre" du code, un compilo c'est avant tout un analyseur lexical et syntaxique qui constitue une première couche de TESTS et un générateur de code. C'est loin d'être seulement la 2ème partie.
Tu dis que l'avenir est aux outils d'analyse de code : mine de rien le compilo est l'un de ses outils, rien n'empêche d'utiliser d'autres outils à côtés.
[^] # Re: Ruby On Rails
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
Et la protection qu'offre la compilation, meme si elle ne corrige qu'une partie des erreurs... beh c déja ca de pris !
http://about.me/straumat
[^] # Re: Ruby On Rails
Posté par golum . Évalué à 3.
Ce qui est contre productif c'est d'être obligé de créer des templates et de les instancier en générant du code pour pouvoir s'en servir (pile d'entier, pile de float, ...) alors qu'il est tellemnet plus simple de s'en servir sans contrainte de type.
De même disposer de pile de n'importe quoi (si je veux ajouter un entier puis un float) est plus interessant que d'être obligé de passer par des void* en C ou des Object ce qui revient à contourner le typage statique et ouvre la porte aux erreurs qu'on est sensé eviter.
Moi je préfère me concentrer sur l'idée en utilsant un langage dynamique. Tu developpes ta classe et ton test unitaire associé en même temps..
Après comme devermineur tu peux utiliser les "contrats" qui apportent plus de garanties que le simple type checking.
Si tu veux vraiment pousser, tu disposes d'outils de verification pour les langages dynamiques comme pychecker pour python.
Une voie de progrès serait d'introduire le typage statique à posteriori lors des phases d'integration du produit.
cf. debats de la communauté python
http://www.google.fr/search?q=python+optional+static+typing&sou(...)
Enfin il faut pas assimiler la validation syntaxique à la compilation comme le fait Timaniac.
Ca n'en est qu'une étape et je ne suis pas le seul à le penser
http://fr.wikipedia.org/wiki/Compilation(...)
L'intêret de la compilation est dans les performances qui peuvent être améliorée dans le cadre de l'execution et là aussi on dispose d'outils d'optimisation pour les langages dynamiques (psyco ...). Et n'oublions pas les optimisations à l'execution.
Bref la frontière entre langage interprété et complié est de plus en plus ténue en terme de performances
Par contre les inconvénients du typage fort subsistent.
http://www.mindview.net/WebLog/log-0025(...)
[^] # Re: Ruby On Rails
Posté par TImaniac (site web personnel) . Évalué à 0.
Personne ne t'empêche de tester une idée dans un langage à typage "faible".
De plus c'est pas non plus super long d'écrire le type hein.
Ce qui est contre productif c'est d'être obligé de créer des templates et de les instancier en générant du code pour pouvoir s'en servir (pile d'entier, pile de float, ...) alors qu'il est tellemnet plus simple de s'en servir sans contrainte de type.
On a inventé les génériques :
Pile maPile;
De même disposer de pile de n'importe quoi (si je veux ajouter un entier puis un float) est plus interessant que d'être obligé de passer par des void* en C ou des Object ce qui revient à contourner le typage statique et ouvre la porte aux erreurs qu'on est sensé eviter.
Mais n'importe quoi là ! Tu dis que c'est mieux d'avoir des piles de n'importe quoi, mais tu veux pas utiliser Object parcque ca apporte des erreurs ! Et ton n'importe quoi il va pas en apporter peut être ?
Tu developpes ta classe et ton test unitaire associé en même temps..
Genre toi humain t'es beaucoup plus fiable pour générer des tests unitaires exhaustifs en pouvant te permettre de te passer des vérifs qu'apporte un typage fort et statique.
Si encore tu me disais : moi je tests jamais les progs je comprendrais, t'assumerais effectivement jusqu'au bout, mais là non.
Je te ferais remarquer que l'absence de typage fort et statique t'oblige à générer beaucoup plus de tests unitaires (puisqu'en gros tu dois te coltiner le boulot du compilo), alors bon question productivité je préfères faire confiance au compilo et garder mes tests unitaires pour ce qu'il ne sait pas faire.
Une voie de progrès serait d'introduire le typage statique à posteriori lors des phases d'integration du produit.
Autant le faire dès le début, ca sera toujours ca de fait. C'est comme pour les tests unitaires : il est fortement conseillé de les écrire D'ABORD. Tout va toujours dans le même sens : on met le maximum de contraintes (tests unitaires, typage, etc.) et on code APRES.
Enfin il faut pas assimiler la validation syntaxique à la compilation comme le fait Timaniac.
Mais si ! Ca fait parti du boulot du compilateur, c'est un fait dans la plupart des compilo. Point barre. C'est fou ca vouloir faire croire aux gens que la réalité est ailleur.
'intêret de la compilation est dans les performances qui peuvent être améliorée dans le cadre de l'execution et là aussi on dispose d'outils d'optimisation pour les langages dynamiques (psyco ...)
Psycho c'est joli mais c'est x86 only, tu pers la portabilité, bref tu perds une grosse partie de l'intérêt d'un langage de haut niveau interprété, ce n'est donc pas une solution, juste un cache-misère pour faire croire que Python est portable, performant et enlarge ton penis.
Par contre les inconvénients du typage fort subsistent.
C'est quoi déjà les inconvénients ?
Ah oui tu peux pas mettre n'importe quoi dans ta pile, et c'est super long à taper le type.
PS : déclarer le type d'un objet c'est aussi une forme de documentation pour celui qui relis le code.
Taper le mot "int" ou "MaClasse" c'est une part négligeable de la rédaction du code et cela permet de gagner un peu plus loin : l'IDE ayant le type il peut te proposer les méthodes applications à ton objet , et ca question productivité c'est un gain beaucoup plus important.
[^] # Re: Ruby On Rails
Posté par golum . Évalué à 2.
Personne ne t'empêche de tester une idée dans un langage à typage "faible".
De plus c'est pas non plus super long d'écrire le type hein.
Ben c'est plus long que de ne pas l'indiquer
Il faut le mettre dans les declarations, dans les cast sans compter les
modificateurs à la pelle
On a inventé les génériques :
Pile maPile;
Quelle différence avec les templates C++
Tu es bien obligé de preciser le type d'objet lorsque tu l'utilises et donc tu as bien genéré un bytecode correspondant à ton "instanciation'"
Par exemple
List myIntList = new LinkedList(); // 1
myIntList.add(new Integer(0)); // 2
Integer x = (Integer) myIntList.iterator().next(); // 3
Tu généres en quelques sorte le bytecode de classe de ListInt.
Dans ma boîte on utilise massivement les templates C++ et je peux te garantir que ca dégrade pas mal les temps de compil, sans compter les problèmes de fabrication associés.Maintenant les genrerics en Java (depuis la 1.5 seulemen) je ne sais pas ce que ca donne
Mais n'importe quoi là ! Tu dis que c'est mieux d'avoir des piles de n'importe quoi, mais tu veux pas utiliser Object parcque ca apporte des erreurs ! Et ton n'importe quoi il va pas en apporter peut être ?
Ben justement avec un langage dynamique tu n'est pas obligé de passer par de tels artifices.
En Java tu peux aussi passer par des interfaces (plus propre conceptuellement) mais tu es de toute façon obligé de rajouter du code
(cf le lien sur la page de Bruce Eckel que j'ai donné)
Genre toi ....
Je te ferais remarquer que l'absence de typage fort et statique t'oblige à générer beaucoup plus de tests unitaires (puisqu'en gros tu dois te coltiner le boulot du compilo), ....
Absolument pas. Tu ne dois pas tester les types d'objets avec tes test unitaires
Tu définis un contrat qui est nettement plus rigoureux(précondition/postconditions , invariants) et va plus loin que la simple vérification de type.
Après tu valides le tout au moment de l'assemblage de tes composants.
Les test unitaires , ca sert uniquement à creer une suite de test et à t'assurer de la non régression.
C'est le contrat qui doit être exhaustif.
Autant le faire dès le début, ca sera toujours ca de fait. C'est comme .... et on code APRES.
cf . contrats
Enfin il faut pas assimiler la validation syntaxique à la compilation comme le fait Timaniac.
Mais si ! Ca fait parti du boulot du compilateur, c'est un fait dans la plupart des compilo. Point barre. C'est fou ca vouloir faire croire aux gens que la réalité est ailleur.
C'est une étape obligée pour pouvoir compiler mais ce n'est pas la finalité de la compilation.
Psycho c'est joli mais c'est x86 only, tu pers la portabilité, bref tu perds une grosse partie de l'intérêt d'un langage de haut niveau interprété, ce n'est donc pas une solution, juste un cache-misère pour faire croire que Python est portable, performant et enlarge ton penis.
C'est vrai que des projets comme gcj ca n'a aucun intêret c'est pour ca qu'il existent. Java ca roxe
Des trolls comme ca tu les gardes parce que moi aussi je peux jouer, genre:
En fait je comprends maintenant pourquoi on a besoin de super IDE
de la mort qui tue en Java et pas en Python
Parce faire du refactoring, tout recompiler=>(compli incrémentale), completer toutes les déclarations de type ... toussa il faut mettre les moyens pour retrouver de la productivité.
[^] # Re: Ruby On Rails
Posté par TImaniac (site web personnel) . Évalué à 1.
Pour le prototypage je reconnais qu'un langage sans typage peut être "pratique". Mais ca reste du prototypage. Ca rejoint l'idée première de ces langages qui restent des langages de "script", pas pou faire des grosses applis.
Tu généres en quelques sorte le bytecode de classe de ListInt.
Dans ma boîte on utilise massivement les templates C++ et je peux te garantir que ca dégrade pas mal les temps de compil, sans compter les problèmes de fabrication associés.Maintenant les genrerics en Java (depuis la 1.5 seulemen) je ne sais pas ce que ca donne
Les templates en C++ c'est un peu affreux, j'en convient.
En Java le compilo remplace partout la référence au type par object avec un cast. Il n'y a donc pas de génération spécifique.
En C#, le typage est conservé dans le bytecode, le code spécifique est généré à la volée, tout en conservant toutes les informations sur la "généricité".
En C# non seulement c'est un gain non négligeable en terme de fiabilité (puiqu'il permet d'éviter de nombreux casts tout en permettant au compilo d'effectuer des vérifications), mais c'est aussi un gain de temps à l'exécution (une pile d'entier est allouée sur la pile, alors qu'une pile d'objet ne l'est pas).
Enfin pour te montrer que le typage est si "important", il a constitué pour Java et C# une des principales améliorations et atouts de leur évolution, parcque réclamé par les dev.
(cf le lien sur la page de Bruce Eckel que j'ai donné)
J'ai du mal à comprendre son point de vue. Je vois pas pouquoi il posse 2 notions qui sont complémentaires. Tout est bon pour améliorer la qualité du code, que ce soit le typage statique et fort, les tests unitaires, les contrats, etc.
Le but étant d'automatiser le maximum de tâche (une machine se trompe rarement), c'est pourquoi sont apparus les Garbage collector entre autre.
Les test unitaires , ca sert uniquement à creer une suite de test et à t'assurer de la non régression.
C'est le contrat qui doit être exhaustif.
Arf effectivement si tu poses bien tes contrats tu vas résoudre pas mal de problème.
Mais on en revient toujours au même point : c'est l'humain qui rédige les contrats, et à moins d'avoir des outils comme le langage B pour formaliser tout ca et s'assurer de la validifé des contrats, il restera toujours une marge d'erreur.
Si tu rédiges des contrats en Python, ils te péteront à la tronche à l'exécution. J'espère que ca ne sera pas chez le client le jour où un contrat aura été mal rédigé.
Enfin tu me fais sourir quand même : tu veux pas écrire le type de tes variables par "gain de temps", et tu consommes une bonne partie de celui-ci à la rédaction des contrats. Cette reflexion sur les contrats doit en plus t'amner bien souvent à "réfléchir" sur le type à l'exécution de tes variables.
De plus préciser le type d'un paramètre par exemple fait parti de la signature d'une méthode, si tu mets plusieurs méthodes dans un même "conteneur", t'as une interface, qui constitue déjà une sorte de contrat, qui lui a l'avantage d'être checkable à la compilation, et donc qui sera vérifier par un outil avant d'aller péter le cas échéant chez le client.
C'est une étape obligée pour pouvoir compiler mais ce n'est pas la finalité de la compilation.
Ben dans le cas d'un langage typé fort et statiquement, si c'est une des finalités. Si pour toi contribuer à améliorer la qualité du code produit n'est pas dans les objectifs d'un compilo...
C'est vrai que des projets comme gcj ca n'a aucun intêret c'est pour ca qu'il existent. Java ca roxe
Je te ferais remarquer que gcj tourne sur un peu plus d'architecture, et il est tout à fait capable de compiler "à la volée" (JIT) le code intermédiaire : tu ne perds pas la portabilié. Et ayant généré un exécutable pour la machine cible, c'est celui-ci qui sera de nouveau exécuté. Non là tu ne perds pas la portabilité.
En fait je comprends maintenant pourquoi on a besoin de super IDE
de la mort qui tue en Java et pas en Python
Parce faire du refactoring, tout recompiler=>(compli incrémentale), completer toutes les déclarations de type ... toussa il faut mettre les moyens pour retrouver de la productivité.
Genre le refactoring tu trouves pas ca pratique ? En python t'as jamais envie d'extraire une interface d'une classe ? Ah ben non désolé y'a même pas la notion d'interface :) T'as jamais besoin de renommer une variable ? Et là tu vois un parfait exemple d'utilité du refactoring : tu modifies le type d'une variable, le refactoring applique les modifs partout, et bien le compilo te gueuleras dessus si jamais une erreur de typage a été introduite quelque part.
EN Python t'as intérêt de te rappeler quelles sont les conséquences de tes changements.
Si pour toi la complétion automatique de méthode n'est pas un gain de productivité je ne cherche plus à comprendre... Le typage fort instaurant de plus de nombreux tests automatique, il permet d'obtenir un peu plus de fiabilité, au final de bugs en moins et donc de la productivité en plus.
Enfin franchement j'ai du mal à te suivre : tu semble "fan" des contrats (j'abonde dans ton sens), mais tu refuses le typage statique, alors que les 2 notions cherchent le même but et sont complémentaire : assurer une certaine qualité du code. Enfin tu sembles préférer faire confiance exclusivement à ta rédaction des contrats plutôt que de confier des vérifications de base à un outil dont c'est en parti le boulot.
[^] # Re: Ruby On Rails
Posté par golum . Évalué à 2.
Mais si on suit ton raisonnement , on prototype rapidement avec un tel langage et après on réecrit tout avec un langage fortement typé pour assurer performance et sécurité ( ou on regénère du code à partir d'UML). Autant développer le prototype directement avec le langage cible même s'il est fortement typé quitte à sacrifier à la souplesse et à la productivité.
La démarche que j'explicite est différente.
Tu prototypes sans contrainte de type au début ce qui te permet d'explorer différentes pistes ou architectures.Tu ecris tes tests unitaires en même temps mais tu introduis tes contrats progressivement et itérativement à mesure que ta conception se précise.
Tu ne livres pas de code non testé en prod puisque ton code est testé et validé par les contrats. Tu relâches les contraintes progressivement à mesure que la qualité de ton code s'améliore (tout comme les niveaux de logging ou les options de debug) et tu conserves malgré tout une plus grande souplesse durant la phase de conception.
Concernant les IDE :
Bien entendu les fonctionnalités que tu decris sont intéressantes même pour un langage dynamique. Il n'empêche que pour des langages fortement typés, elles sont pratiquement indispensables pour compenser les manques de productivité.
La compilation JIT n'a d'utilité que pour des langages compilés comme Java.
L'expressivité et la concision de langage comme Python ou Ruby rendent moins crucial le besoin d'outils performants de refactoring, d'introspection.... Python a ses défauts inhérents à son design mais Java n'est pas exempt non plus.Relis mon post , j'ai bien précisé qu'il s'agissait d'un troll en réaction à tes à prioris
Bref tout est affaire de compromis entre performance et productivité.
Il faut donc définir sa stratégie en fonction des besoins.
Autant je t'accorde que Mono/J2EE s'impose pour des grands comptes, autant les solutions RAD type Ruby On Rails (Ai pas testé Ruby) me paraissent pertnentes lorsque le coût et le délai l'emporte sur les perfs.
cf. notre thread sur
http://linuxfr.org/comments/589849,1.html(...)
Si tu es interessé par les contrats tu retrouveras un excellent article de synthèse sur le defunt "Développeur Reference"
http://web.archive.org/web/20031204022702/www.devreference.net/devr(...)
Perso je l'utilise au travers d'un module POA dans le cadre d'un petit dev associatif et j'e ne m'en plains pas:
http://www.logilab.org/projects/aspects/documentation/contracts(...)
Mais tu trouveras sûrement de meilleurs equivalents pour .net, java ou ruby
[^] # Re: Ruby On Rails
Posté par TImaniac (site web personnel) . Évalué à 2.
Sauf qu'en général le prototype c'est pas une "référence". C'est pas forcement "bien" de partir de son code, il faut mieux parfois reprendre tout à 0 de façon plus propre, lorsque les différentes idées dans le prototype commence à se mettre en place.
Toi tu proposes d'améliorer au fure et à mesure la qualité du code de ton prototype. Pourquoi pas. Je ne suis pas partisan de cette manière de faire, je préfères faire le plus propre possible dès le début, en me basant sur un modèle plus abstrait validé "théoriquement".
Il n'empêche que pour des langages fortement typés, elles sont pratiquement indispensables pour compenser les manques de productivité.
A l'arrivé on est parfois plus productif puisque l'IDE propose automatiquement les méthodes qui s'applique à un objet. Dans un langage où le type n'est connu qu'à l'exécution ca va être "balèze". Souligner les fautes est également productif à mon goût.
Bref tout est affaire de compromis entre performance et productivité.
Je ne parlais pas de performances, là j'aurai trop epru de troller ;)
Je préfères me contenter de parler de compromis entre productivité et "qualité".
Autant je t'accorde que Mono/J2EE s'impose pour des grands comptes, autant les solutions RAD type Ruby On Rails (Ai pas testé Ruby) me paraissent pertnentes lorsque le coût et le délai l'emporte sur les perfs.
Très bonne conclusion avec laquelle je suis d'accord. Cela va assez dans mon sens : les grands comptes qui font de "grosses" applis ont besoin du maximum d'outils pour vérifier et valider des bouzins énormes. D'où l'idée qu'un typage statique fort va dans le sens de la qualité (et avec un bon IDE sans rien sacrifier à la productivité à mon goût).
J2EE va vraiment dans le sens des grosses applis, Python/Ruby pour le RAD. Mono je le situerais bien entre les 2. Peut être pas parfait dans un cas ni dans l'autre, mais à "l'aise" dans les 2.
Pour la prog par contrat je n'avais regarder que du côté de Eiffel.
Sinon une variante de Python avec typage fort et statique : Boo pour Mono.
[^] # Re: Ruby On Rails
Posté par bobefrei . Évalué à 2.
Comme ça tu perds du temps à porter ton prototype dans un autre langage...
>De plus c'est pas non plus super long d'écrire le type hein.
Un seul non, mais sur un programme ça représente une grande partie de ce que tu tapes. Surtout avec Java/C++/C# qui t'obligent à taper plusieurs fois la même info:
MonType obj = new MonType();
MaListe<MonType> Liste = new MaListe<MonType>(obj);
MonType obj2 = Liste.first();
Une bonne syntaxe associé à un interpréteur/compilateur intelligent permette de déduire le type des instances:
obj := new MonType()
Liste := new MaListe(obj)
obj2 = Liste.first();
( := est là pour faire différence entre instanciation et affectation )
Au delà de cette syntaxe fictive, des langages comme OCAML implémente ce genre de chose sous la forme de l'inférence de type.
[^] # Re: Ruby On Rails
Posté par TImaniac (site web personnel) . Évalué à 2.
De plus tu peux très bien vouloir parfois ne pas mettre le même le même type à gauche et à droite. Typiquement tu peux instancier un type dérivé et ne conserver qu'une référence à une interface, pour t'obliger à l'utiliser en tant que tel.
[^] # Re: Ruby On Rails
Posté par reno . Évalué à 4.
De plus, à la lecture, cela reste plus lourd.
Pour ton dernier point, je ne connais pas bien Ocaml mais en Limbo (un language tournant sur Plan9), la syntaxe suivante est utilisée:
my_var1 = my_var2; affecte la valeur de my_var2 à my_var1, my_var1 devant être déclaré avant.
my_var1 := my_var2; déclare my_var1 comme étant du type de my_var2, et lui affecte sa valeur.
my_var1 : my_type = my_var2; déclare my_var1 comme étant du type my_type et lui affecte la valeur de my_var2.
my_var1 : my_type; déclare my_var1 comme étant du type my_type avec une valeur par défaut correspond au type.
Simple et de bon gout.
[^] # Re: Ruby On Rails
Posté par bobefrei . Évalué à 2.
Pour le problème de l'instanciation d'un type et l'affectation à une référence vers un parent ou une interface, il suffit d'une conversion:
Ref = new MaClasse() as MonInterface
Ce genre de détail de syntaxe semble dérisoire, mais si ça rend un code plus lisible et plus agréable, ça vaut le coup.
[^] # Re: Ruby On Rails
Posté par TImaniac (site web personnel) . Évalué à 1.
Pourquoi dommage ? C'est le résultat qui compte, et avec un bon IDE, le typage devient un atout alors pourquoi s'en priver :)
Ref = new MaClasse() as MonInterface
C'est vrai que par rapport au C# ca change tout :
MonInterface Ref = new MaClasse();
Ce genre de détail de syntaxe semble dérisoire, mais si ça rend un code plus lisible et plus agréable, ça vaut le coup.
Désolé je trouves que MonInterface Ref est aussi lisible, voir plus ;)
De toute façon quand tu cherches à faire cela c'est pour "s'imposer" d'utiliser l'interface et non le véritable type. Imagine par exemple que tu es une classe A qui implémente 2 intefaces :
interface A{
string ToString();
}
interface B{
string ToString();
}
Ma classe est alors :
class C : A, B
{
public A.ToString(){return "je suis un A ! ";}
public B.ToString(){return "je suis un B ! ";}
}
Ce qui fait qu'à l'utilisation si j'ai une référence vers un A :
A var = new C();
je n'ai pas la même chose qu'avec :
B var = new C();
quand je fais :
var.ToString()
COmment tu fais dans un langage dynamique si tu ne peux pas préciser "en dur" le type de la référence ?
Comment l'IDE peut te proposer la bonne méthode ?
Je sais comment ils ont résolu le problème en Python : ils ont pas mis d'interface ;)
[^] # Re: Ruby On Rails
Posté par bobefrei . Évalué à 1.
Tu prends des cas particuliers alors que le type d'écriture dont je parle est faite pour améliorer le cas général.
Pour ton exemple avec les classes A, B, C, ce n'est pas un problème:
A var = new C(); serait remplacé par var = new C() as A;
Mais l'avantage du calcul automatique des types n'est pas à la création mais à l'affectation, aux paramètres...
Si tu écris A = B, A prends le type de B, pas besoin de le préciser sauf si tu veux faire une conversion ou utiliser un sous-type.
Autre exemple prends la fonction:
int addition(int a, int b)
{
return a + b;
}
N'est-il pas plus simple d'écrire:
addition(a, b)
{
return a + b;
}
Comme on fais une addition, a et b seront:
- des nombres entiers ou flottants avec un typage laxiste comme en Java/C++.
- des entiers avec typage plus strict comme OCAML où l'addition entre nombres flottants s'écrit +., car il s'agit d'une opération différente.
[^] # Re: Ruby On Rails
Posté par TImaniac (site web personnel) . Évalué à 1.
Gni ? Tu peux t'expliquer là ?
Tu prends des cas particuliers alors que le type d'écriture dont je parle est faite pour améliorer le cas général.
Pas du tout, j'utilises en permanence les interfaces. Ce n'est pas un cas particulier, il arrive de devoir implémenter des interfaces qui ont les mêmes méthodes.
A var = new C(); serait remplacé par var = new C() as A;
Mon dieu c'est ouachement plus kler :) Ca change strictement rien au niveau visibilité. Et tu ne m'expliques toujours pas comment en Python tu ferais pour dériver 2 méthodes avec la même signature provenant de 2 classes différentes.
N'est-il pas plus simple d'écrire:
addition(a, b)
{
return a + b;
}
Ah bah oui comme ca je vais pouvoir faire :
addition(patate, carotte)
et paf belle erreur de runtime.
C'est magnifique dis donc. T'en a d'autres des comme ca ?
[^] # Re: Ruby On Rails
Posté par bobefrei . Évalué à 2.
T'as déjà développer autre chose que des sites avec J2EE ou .NET? Je développe souvent pour PDA (Pocket PC, Palm) et plus rarement pour des systèmes embarqués, récemment j'ai fait des applications de tests de charge en cluster... Dans ces environnements, il n'y a pas toujours d'IDE complet disponible ou ton employeur n'en achètes pas ou ta machine de travail n'est pas assez puissante pour en faire tourner un, etc.
>Pas du tout, j'utilises en permanence les interfaces.
Parce que tu utilises toujours le même langage, il y a d'autres paradigmes...
>Ah bah oui comme ca je vais pouvoir faire :
>addition(patate, carotte)
Si patate et carotte ne sont pas des entiers, tu auras une erreur pendant la phase de vérification, pas à l'exécution.
> C'est magnifique dis donc. T'en a d'autres des comme ca ?
Lis ça avant de prendre un ton ironique qui montre que tu n'as rien compris: http://en.wikipedia.org/wiki/Type_inference(...)
[^] # Re: Ruby On Rails
Posté par TImaniac (site web personnel) . Évalué à 2.
Bah pour les PDA, y'a Visual Studio.
Et franchement sur ce genre de machine t'as le problème des perfs tout de même, alors bon Ruby & Co voilà quoi. Faudrait pas faire n'importe quoi non plus. Sur tes clusters aussi tu fait mumuse en Python ? Non mais franchement.
Parce que tu utilises toujours le même langage, il y a d'autres paradigmes...
Yahooooo... Donc c'est quoi les paradigme révolutionnaire de Python ? Non parcque mon paradigme c'est l'objet, les Design Pattern, etc, c'est pas limité à un seul langage, c'est reconnu et fortement répendu.
Si patate et carotte ne sont pas des entiers, tu auras une erreur pendant la phase de vérification, pas à l'exécution.
Ah bon ? Quel vérification ? Par quel outil ?
Si je fais :
if(rand() < 0.5)
o = new Carotte
else
o = new Patate
addition(new Patate, o)
Il va se passer quoi ? Tu m'expliques ?
Lis ça avant de prendre un ton ironique qui montre que tu n'as rien compris
Je sais très bien j'ai déjà codé en Caml. C'est pas le problème. Je critiques pas Caml, je critiques les langages comme Python ou Ruby qui ont un typage exclusivement dynamique et où l'inférence de type est impossible à établir (because en Python tu peux "modifier" une classe dynamiquement).
[^] # Re: Ruby On Rails
Posté par bobefrei . Évalué à 2.
Pour Pocket PC uniquement et il coute cher.
>Et franchement sur ce genre de machine t'as le problème des perfs tout de même, alors bon Ruby & Co voilà quoi.
Pour la petite histoire:
Arrête de tout ramener à Python, ça fait au moins 8 posts qu'on parle des langages en général!
Tu auras une erreur, car:
- soit o n'existait pas avant, donc il n'est dans l'espace de nom de la ligne addition(new Patate, o), mais dans celui du if et du else. Ce sont d'ailleurs deux variables o distinctes.
- soit o existait avant et il aura donc un type, par exemple Carotte, et la ligne o = new Patate sera donc incorrecte.
Pour l'application de ce principe à des langages en gardant le côté dynamiques, il faudrait l'introduire sous forme d'avertissement ou ajouter un mot clef pour dire qu'une classe peut être modifié dynamiquement ou non...
[^] # Re: Ruby On Rails
Posté par TImaniac (site web personnel) . Évalué à 2.
Visual Studio Express c 50$. Si ta boite est pas prêt à payer ca voilà quoi.
.NET est très très lent sur Pocket PC certainement parce que Winforms est pourri, car dans mon équipe on obtient des programmes plus réactifs avec une autre solution avec un serveur web embarqué et des pages HTML/Javascript..
Blablabla. Mauvais codeur, changer de codeur, pas de techno.
Arrête de tout ramener à Python, ça fait au moins 8 posts qu'on parle des langages en général!
Oué je viens de me rendre compte qu'on discutait pas mal dans le vide parcque justement on parlait pas de la même chose. Moi je parlais Ruby et Python (qui sont très similaire) et qui sont les sujets de la news.
- soit o existait avant et il aura donc un type
Faut savoir le type est défini ou il ne l'est pas ?
[^] # Re: Ruby On Rails
Posté par bobefrei . Évalué à 2.
Arg je m'avoue vaincu devant une argumentation aussi bien construite, basée sur des preuves irréfutables, issu d'une profonde réflexion et surtout très constructive.
>Faut savoir le type est défini ou il ne l'est pas ?
Blablabla, oui par inférence, tu comprends rien à rien.
[^] # Re: Ruby On Rails
Posté par TImaniac (site web personnel) . Évalué à 2.
Bah non mais bon tu me sors une phrase comme ca pif paf poum venant de nulle part remetant unilatéralement en cause une techno sans supposer un seul instant que le jugement du codeur pouvait être biaisé par ses compétences et son expérience. Je répond à ton argumentation pertinente par une autre toute aussi pertinente ;)
Blablabla, oui par inférence, tu comprends rien à rien.
Je viens de t'expliquer que je parlais de langages compilés avec typage statique et fort vs langages à typage dynamique comme Ruby ou Python. Donc arrête de la ramener avec l'inférence, je trouve ca cool l'inférence, je trouve Caml cool. Voilà. Je vais arrêter la conversation là si tu ne veux absolument pas revenir dans le sujet de la conversation.
[^] # Re: Ruby On Rails
Posté par bobefrei . Évalué à 2.
Pas de nulle part, elle vient du travail que l'on fournit en ce moment comme je l'ai dis. Ce n'est pas biaisé par nos compétences, tu peux faire l'expérience suivante:
Prends le compact framework, un pocket pc et VS.NET.
Dessine un formulaire dans l'éditeur avec une vingtaine de contrôles dessus.
Mesure le temps qu'il faut pour l'afficher.
Sans avoir tapé une seule ligne de code, ça va déjà mettre 10s se charger... On est obligé de gérer un système de cache pour compenser cette lenteur.
Pour revenir au type dynamique vs typage fort, si tu ne veux pas prendre en compte les outils annexes qui permettent de faire des vérifications sur les langages dynamiques comme cela t'as été signalé dans les posts précédents...
[^] # Re: Ruby On Rails
Posté par TImaniac (site web personnel) . Évalué à 2.
Vas-y envoi moi les 2 programmes, le serveur web+html et l'appli WinForms que je compares.
Pour revenir au type dynamique vs typage fort, si tu ne veux pas prendre en compte les outils annexes qui permettent de faire des vérifications sur les langages dynamiques comme cela t'as été signalé dans les posts précédents...
C'est pas du tout au point, et comme je te l'ai dis, le langage en soit ne le permet pas, bref ces outils ne seront jamais parfait, on n'aura jamais aucune certitude par rapport à un langage typé statiquement avec une norme bien définie.
De plus même avec la présence de ces outils (en supposant qu'ils existent et qu'ils soient performants), cela n'améliorera pas intrinséquement lespossibilités d'optimisations nombreuses qu'apporte le typage statique.
[^] # Re: Ruby On Rails
Posté par TImaniac (site web personnel) . Évalué à 2.
addition(a,b)
{
return a+b
}
dans un langage dynamique ala Python/Ruby.
Je veux déployer ma superbe bibliothèque mathématique, mais avant je veux vérifier qu'elle ne plantera pas trop chez ses utilisateurs.
Je la passe avec le superoutilquitue. Que vas-t-il faire ?
Il ne va quand même pas me dire que y'a une erreur : dans bien des cas cela va marcher et je voulais justement éviter de typer. Et même s'il me dit que y'a une erreur que dois-je faire ?
C'est la philosophie même de ces langages qui va à l'encontre de toute tentative de typage statique et donc de vérification à priori. C'est ca que je critiques dans un cadre de qualité logicielle. CAML n'entre évidemment pas dans cette catégorie de langages.
[^] # Re: Ruby On Rails
Posté par bobefrei . Évalué à 2.
Pour la winform tu peux le faire toi même, crée un projet bidon et mets une forme avec des contrôles. Par contre l'autre appli, je n'ai pas le droit de la sortir d'ici, mais le serveur web vient des outils d'iAnywhere mBusiness tu dois pouvoir télécharger une démo sur leur site.
[^] # Re: Ruby On Rails
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Ruby On Rails
Posté par bobefrei . Évalué à 2.
Dans une application de ce type, deux tâches demandent des performances: l'affichage et la gestion des données. Les langages de scripts les délèguent au navigateur web ou à des API comme Qt ou GTK pour la première et à un SGBD pour la seconde.
L'errreur de Microsoft avec le Compact Framework c'est d'avoir voulu faire de Winform un simple binding vers la GUI de win32. Résultat c'est super lent.
[^] # Re: Ruby On Rails
Posté par TImaniac (site web personnel) . Évalué à 2.
Yahoo, t'as une appli qui fait rien de dynamique, bref c'est quasiment pas une appli. Forcement, c'est facile de comparer...
Dans une application de ce type, deux tâches demandent des performances:
Oué effectivement quand t'as une appli qui fait rien c'est facile. Si t'as pas besoin d'appliquer d'algo pour manipuler les données, etc.
Maintenant fait une vrai appli HTML puisque c'est rapide sur ton PDA qui demande, aller soyons fou, un peu de "dynamisme", tu vas être obligé d'utiliser autre chose que le simple JAvascript, un truc ala PHP, qui par exemple à besoin de charger des données dans une base. Et là .NET se démerde très bien, .NET est même réputé pour ses hautes perfs dans le domaine serveur web. ON va rire quand on va sortir un interpréteur PHP ou Python côté serveur web sur le PDA.
L'errreur de Microsoft avec le Compact Framework c'est d'avoir voulu faire de Winform un simple binding vers la GUI de win32. Résultat c'est super lent.
Genre c'est vrai t'utilises un langage comme Python ou Ruby, ca sera pas du tout un binding vers la GUI de Qt ou GTK.
Franchement tes arguments sont bidons, tu compares jamais ce qui est comparable. Comparer une page HTML+javascript avec une plateforme comme le Compact Framework voilà quoi. ENfin ca confirme un peu ce que je disais à la base : quand le dev ne sait déjà pas choisir les bons outils adapter aux bons besoins...
[^] # Re: Ruby On Rails
Posté par bobefrei . Évalué à 2.
Fais toi engager comme consultant Microsoft ou Sun, tu y seras plus utile que sur linuxfr...
[^] # Re: Ruby On Rails
Posté par TImaniac (site web personnel) . Évalué à 2.
Pas besoin de me renseigner pour être persuadé qu'aucun framework graphique n'est écrit dans un langage de haut niveau comme Python ou Ruby, et en déduire qu'il est tout à fait normal qu'ils aient le même système de binding que les WinForms au dessus de win32. Il n'y en a qu'un qui l'a fait : Java avec AWT/Swing, et quand on voit le résultat on comprend l'intérêt des bindings.
Désolé j'ai essayé d'argumenter. Tu essai de me démontrer que .NET c'est lent sur PDA comparé à une page HTML+Javascript. Comment veux-tu qu'on arrive à quelque chose ! Pourquoi tu ne fais pas un peu plus preuve d'honnêteté dans tes comparaisons ?
[^] # Re: Ruby On Rails
Posté par bobefrei . Évalué à 2.
Et ton honnêteté c'est de parler sans vérifier?
C'est ce que je constate pour notre application, point. On a fait deux maquettes, l'une avec les outils Microsoft, l'autre avec les outils Sybase. Le résultat est là. Si ça ne concorde pas avec tes croyances tant pis.
Je suis ingénieur pas propagandiste, mon but c'est de prendre la meilleure solution. Sur mon précédent projet, le CF était préférable, car il y avait des graphiques complexes à faire. Sur l'actuel, c'est surtout de la gestion de données et de la synchro, le framework Sybase est plus adapté.
Les langages de scripts ont largement leur place à côté des plateformes plus lourdes. Répéter sans cesse le contraire sans chercher leurs avantages, c'est ça qui est malhonnête.
[^] # Re: Ruby On Rails
Posté par TImaniac (site web personnel) . Évalué à 2.
Mais tout à fait, je suis entièrement d'accord, quand une page HTML avec Javascript suffit, il n'y a aucun intérêt d'utiliser l'artillerie lourde comme le Compact Framework. D'où mon étonnement depuis le départ , et ma remarque comme quoi il faut parfois savoir choisir des technos adaptées.
Tu me dis de tester, je veux bien, mais tu veux pas me filer ton "appli" HTML+Javascript. Alors donne moi plus d'infos au moins : que fait l'appli ? gestion persistence ? traitement des données ?
[^] # Re: Ruby On Rails
Posté par bobefrei . Évalué à 2.
En Python je ne sais pas, je n'en fait pas souvent. Pourquoi tu me parles de Python?
[^] # Re: Ruby On Rails
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Ruby On Rails
Posté par Éric (site web personnel) . Évalué à 2.
> typage dynamique.
> Moi je te parle de C++, Java ou C#, avec un vrai compilo qui vérifies le typage
> statiquement (quand c'est possible) et vrai IDE.
Tu n'as pas compris. Je parle de développer PHP, pas de développer "avec" PHP. Je parle donc bien de développer en C ou C++ (ici c'était du C++ mais ça ne change pas grand chose) avec un vrai compilo et un typage statique.
Et oui c'était horriblement lent. Dans les dernières phases je passais plus de temps en compil qu'en test/modif
> T'auras beau dire tout ce que tu veux, le compilo fait un nombre incalculable de
> tests, surtout avec un langage à typage fort et statique.
Oui. La question c'est : est-ce qu'il est indispensable que ton langage à typage fort et statique soit un langage compilé pour pouvoir faire ce genre de vérification ? la réponse est "non".
Donc non, que tu le veuilles ou non la compilation n'est pas nécessaire pour ta phase de test et non le fait de vouloir controler tous les types n'est pas une raison pour supporter la compilation.
> Visiblement tu n'as rien compris à ce qu'est un compilo, à ce qu'il est censé faire.
> Il n'est pas censer que "pondre" du code, un compilo c'est avant tout un
> analyseur lexical et syntaxique qui constitue une première couche de TESTS et un
> générateur de code. C'est loin d'être seulement la 2ème partie.
Je ne dis pas le contraire, mais il passe aussi un temps non négligeable sur tout le reste (pour reprendre mon exemple, recompiler les fichiers modifiés c'était rapide, c'était pour reconstruire les libs et binaires derrière avec toutes les liaisons qui était long, et là les contrôles de types et l'analyse lexicale étaient déjà faits).
Que tu veuilles faire toute cette analyse je comprend. Mais non faire toute cette analyse ne justifie pas de passer du temps supplémentaire pour faire la compilation.
Tu peux t'en servir comme ça, mais tu perd inutilement du temps sur des trucs qui ne servent pas à tester, et donc qui sont inutiles à ton but premier.
[^] # Re: Ruby On Rails
Posté par TImaniac (site web personnel) . Évalué à 2.
Arf evidemment vu comme ca. Mais bon d'une manière générale les langages dynamiques interprétés ne sont justement pas typés fortement, et encore moins statiquement.
Pour le reste je suis assez d'accord. En fait je crois que votre préocupation concernant la vitesse de compilation cible avant tout C++. J'avoue que C++ voilà quoi, ca me gave et effectivement, pour peux qu'on utilise beaucoup les templates... Je préfères largement coder en C# ou Java, là je n'ai pas ces problèmes de compilation "lente", et donc pour moi le compilo n'est qu'une étape sans aucun désavantage.
[^] # Re: Ruby On Rails
Posté par Éric (site web personnel) . Évalué à 3.
> interprétés ne sont justement pas typés fortement, et encore moins
> statiquement.
Typage fort beaucoup de langages le sont (reste à voir ce qu'on met derrière le terme de typage fort mais je pense qu'il y a pas mal de langages qui peuvent valider ça). Typage statique effectivement, c'est moins habituel.
Mon idéal pour le genre d'appli auxquelles je participe ça serait un langage interprété ou semi interprété, types forts, avec un typage statique optionnel et un analyseur de code :
- tu profites de l'interpréteur "ca s'exécute à la moindre modif" voire du "debuggueur en cours de frappe"
- tu profites du typage statique : tu rajoutes les contraintes de type si tu le souhaites là où le code est plus délicat ou si tu souhaites renforcer les contrôles pour valider ton code
- tu as un analiseur potentiellement lent et long qui sait faire de la détection de type quand tu ne l'a pas déclaré toi même, et sait exploiter les types statiques pour vérifier les concordances.
Le problème c'est que je ne suis pas sûr que le tout soit conciliable avec la notion de langage dynamique tel qu'on la voit dans un python ou un ruby
[^] # Re: Ruby On Rails
Posté par TImaniac (site web personnel) . Évalué à 2.
Le prochain Visual Studio permet cela avec des langages comme C#. Je me demandes comment ils font mais visiblement pas besoin de garder le fardeau de l'interpréteur (qui mine de rien en est un question perf).
tu rajoutes les contraintes de type si tu le souhaites là où le code est plus délicat ou si tu souhaites renforcer les contrôles pour valider ton code
J'aime pas le "si" tu le souhaites. Je préfères que le langage le contraigne au développeur, pour le "forcer" à produire un code de meilleur qualité. C'est aussi ca le rôle d'un langage : ne pas être trop laxiste et forcer l'utilisateur. L'excuse du gain de temps en ne typant pas n'est pas du tout valable pour moi.
[^] # Re: Ruby On Rails
Posté par Éric (site web personnel) . Évalué à 4.
Intéressant.
> J'aime pas le "si" tu le souhaites. Je préfères que le langage le
> contraigne au développeur, pour le "forcer" à produire un code de
> meilleur qualité.
J'ai toujours eu l'opinion inverse en fait. L'informatique, la programmation, le langage, ce sont des outils pour aider l'utilisateur et le développeur. Dès qu'ils deviennent une contrainte c'est qu'il y a un défaut quelque part dans la procédure.
Si le développeur veux mettre des types partout il faut que le langage lui permette. Si le développeur pense aller plus efficacement sans les contrôles de type à court terme qu'il le fasse aussi. Si tu veux une contrainte alors demande à ton analyseur de code de te mettre un warning à chaque type manquant, mais ce n'est pas le rôle du langage.
Si tu veux forcer une syntaxe limitée pour rendre clair le code je comprend. Par contre je ne vois pas de raison de forcer le développeur à mettre des contrôles s'il n'en veut pas. S'il en veut il est assez grand pour les mettre et demander à un outil de vérifier qu'il les met.
Pour les gains de temps en développement je pense que ça dépend des habitudes. En fait je suis sûr de perdre du temps en typant mais je suis sur que ça se regagne de l'autre coté avec l'IDE qui peut proposer des completion plus pertinentes et plus souvent, ou aider beaucoup plus à la frappe. Ce qui me gêne beaucoup plus c'est la lecture du code qui contient tous les contrôles (types, accès, ...). C'est en général super lourd à lire et ça ça joue beaucoup dans la clarté pour quelqu'un qui n'a pas l'habitude. Je le comprend dans une phase de stabilisation/test, mais dans la phase de développement/conception je préfère un code clair et concis avec le moins de contrôles possibles.
[^] # Re: Ruby On Rails
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 1.
Bah tiens... Prends un projet de 1 million de ligne de code, avec 50 développeurs, sur une durée de 3 ans, réfléchis au problème d'en être chef et tu comprendras tout l'intérêt d'utiliser un langage qui donne des obligations, surtout quand 20% des développeurs sont des incompétents que tu peux pas virer pour pleins de raisons.
[^] # Re: Ruby On Rails
Posté par Éric (site web personnel) . Évalué à 2.
> développeurs, sur une durée de 3 ans
Oui, mais des projets de 150 ans/homme on en trouve pas non plus tous les jours. Ca n'est pas forcément représentatif. En tout cas ça ne concerne pas tout le monde.
Mais ce que tu dis ne contredit en rien mes propos. Tu es chef ? tu veux contrôler plus ton projet ? alors tu imposes à tes équipes de passer par l'analyseur qui contrôle les types.
Il n'y a aucune raison pour imposer à sur le langage (donc à tout le monde) juste pour quelques projets de taille énorme. Je ne dis pas que le contrôle est mal, ce que je dis c'est qu'il faut que ce soit un choix, pas une contrainte. Si c'est ton choix ou celui de ton chef tu lances cette vérification, ça s'arrête là.
Puis bon, si tes développeurs sont incompétents ce n'est malheureusement pas un typage statique contrôlé qui va résoudre tes problèmes ;)
[^] # Re: Ruby On Rails
Posté par Frederick Ros . Évalué à 1.
Tu l'as dit .. des sous-equipes sur de petites parties, des unit-test obligatoires (mieux du TDD) et de la revue de code .... c'est quand meme mieux non ?
[^] # Re: Ruby On Rails
Posté par TImaniac (site web personnel) . Évalué à 2.
Y'a mieux : des sous-equipes sur de petites parties, des unit-tests obligatoire, de la revue de code... et du typage statique.
[^] # Re: Ruby On Rails
Posté par Frederick Ros . Évalué à 1.
Sans rentrer dans votre debat, je ne suis pas forcement pour ... :) Viva el Duck Typing !
[^] # Re: Ruby On Rails
Posté par TImaniac (site web personnel) . Évalué à 2.
Non mais des projets de plusieurs centaines de milliers de ligne de code avec plusieurs développeurs sur plusieurs années il y en a une floppée, je dirais même que c'est la majorité. Et bizzarement dans tous ces projets tu retrouve rarement du Python ou du Ruby ;)
En espérant juste que ton logiciel ne devienne pas plus ambitieux.
alors tu imposes à tes équipes de passer par l'analyseur qui contrôle les types.
Tu te prends pas la tête et tu imposes un langage typé statiquement et fortement, auquel toute ton équipe est de préférence habitué.
. Je ne dis pas que le contrôle est mal, ce que je dis c'est qu'il faut que ce soit un choix, pas une contrainte.
Bah voilà c'est bon, on a déjà ca : pour les vrais gros projets où tu recherches un minimum de qualité tu prends un langage typé, compilé (parcque bon tu veux aussi des perfs tant qu'à faire), etc. Pour les petits projets où y'a 2 codeurs, tu peux te permettre de choisir un langage comme python, VB.NET ou Ruby. On se rapproche bien de l'objectif initiale de ces langages : ce sont des langages de script dynamique.
[^] # Re: Ruby On Rails
Posté par Frederick Ros . Évalué à 3.
Normal .. ces 2 languages sont suffisamment concis pour ne pas prendre plusieurs centaines de milliers de ligne de code pour ton projet ;)
: ce sont des langages de script dynamique
NON. Ce sont des languages dynamiques.
[^] # Re: Ruby On Rails
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 1.
C'est sûr que sur un projet de 1.000 lignes de code, on a pas à se poser toutes ces questions. Sur un projet de boite avec > 10 développeurs qui bossent sur le meme code, faut clairement se les poser.
[^] # Re: Ruby On Rails
Posté par bobefrei . Évalué à 3.
Ce n'est pas n'importe quoi, j'ai travailler sur des projets où c'était ça! Bien sur c'était un peu plus compliqué qu'un Hello World... Pourquoi crois-tu que j'ai le temps de poster sur linuxfr?
Ce n'est pas une compilation mais une vérification de syntaxe. Ce fonctionnement est d'ailleurs présent pour des langages non compilés.
Dans l'absolu oui, en pratique quand tu débogues ou fait des tests à répétition, ça peut faire perdre beaucoup de temps, car il n'est pas toujours possible de faire des tests unitaires...
Je ne serais pas si catégorique.
[^] # Re: Ruby On Rails
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
Si c'est une compilation.
Dans l'absolu oui, en pratique quand tu débogues ou fait des tests à répétition, ça peut faire perdre beaucoup de temps, car il n'est pas toujours possible de faire des tests unitaires...
Dans quels cas ?
http://about.me/straumat
[^] # Re: Ruby On Rails
Posté par bobefrei . Évalué à 2.
NON! Je bosse sur Visual Studio en ce moment et le fait qu'il souligne en rouge les erreurs de syntaxe n'est pas une compilation puisqu'elle ne génère pas les fichiers exécutables.
>>il n'est pas toujours possible de faire des tests unitaires...
>Dans quels cas ?
Quand tu fais des tests d'intégration!
[^] # Re: Ruby On Rails
Posté par TImaniac (site web personnel) . Évalué à 2.
Et qu'est t'en sait ? Il peut très bien générer le code intermédiaire (la première phase de compilation qui correspond au "front-end") sans te pondre explicitement le code dans un répertoire pour que tu le vois.
Quand tu fais des tests d'intégration!
C'est complémentaire, pas exclusif.
[^] # Re: Ruby On Rails
Posté par bobefrei . Évalué à 2.
Il peut aussi danser la carioca sans que je le sache, mais entre le moment où, après une modification, je lance la compilation et celui où j'obtiens mon exécutable, il s'écoule entre 30s et 3min sur mon projet actuel. A chaque session de debug, c'est particulièrement pénible.
Si tu as une technique secrête pour que mon programme soit compilé et lancé en moins d'une seconde je suis preneur!
C'est peut être même prolyxe parfois, mais en tout cas c'est relou d'attendre, ça c'est sur.
[^] # Re: Ruby On Rails
Posté par TImaniac (site web personnel) . Évalué à 2.
Cela dit le problème ne vient pas du typage fort et statique en soit, ni du compilo, la preuve en Java ou C# tu peux obtenir un très bon confort sans ces "temps" de latence, tout en conservant le compilo.
[^] # Re: Ruby On Rails
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
Pkoi ca gene les tests d'integration ? je te suis pas.
http://about.me/straumat
[^] # Re: Ruby On Rails
Posté par bobefrei . Évalué à 1.
[^] # Re: Ruby On Rails
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
http://about.me/straumat
[^] # Re: Ruby On Rails
Posté par Damien (site web personnel) . Évalué à 3.
[^] # Re: Ruby On Rails
Posté par Miguel Moquillon (site web personnel) . Évalué à 3.
En gros (avec des imprécisions) :
- le typage statique : le type des données sont connues à la compilation et sont stipulés par le codeur.
- le typage dynamique : le type des données ne sont connues qu'à l'exécution.
- typage fort : une donnée est d'un type et d'un seul bien définie.
- typage faible : une donnée n'est pas de type bien définie.
[^] # Re: Ruby On Rails
Posté par Éric (site web personnel) . Évalué à 2.
J'en profite pour rappeler que ce qui est sur wikipédia c'est ce que les gens y ont mis, rien de plus (et pas forcément La Vérité Objective)
Le problème du typage fort c'est que même avec ta définition (qui me convient assez bien) c'est assez flou. Exemple avec PHP (typage faible dynamique) :
$a = "3 maisons" ;
echo ($a +1) ; // affiche 4
echo gettype($a) ; // affiche string
$b = "3" ; echo gettype($b) ; // affiche string
$c = 3 ; echo gettype($c) ; // affiche integer
Ma donnée a bien un type clairement défini et non ambigu, simplement on fait des conversions implicites entre les différents types un peu partout. Je suppose qu'on ne peut pas pour autant dire que tous les langages qui proposent des système de conversion implicites sont en typage faible pour autant (sinon on va finir par classer C et C++ dans les typages faibles)
Je pense que les séparations entre faible et strictes n'ont pas vraiment de délimitation forte. C'est plus une histoire de philosophie et d'orientation du langage.
(La question du typage statique/dynamique n'est pas tellement plus facile avec l'arrivée des languages qui savent parfois déterminer seuls les types avant exécution sans que l'utilisateur ne précise rien)
[^] # Re: Ruby On Rails
Posté par Miguel Moquillon (site web personnel) . Évalué à 3.
Quand tu écris $a = "3 maisons" on lui a assigné une valeur de type chaîne de caractères. Mais lorsque tu fais $a + 1, si ta variable était de type fort, alors une erreur aurait été levée parce que l'on ne peut pas additionner une chaîne avec un entier. Au lieu de cela, le runtime a considéré juste la variable $a comme un entier et a donc appliqué un transtypage horrible (horrible car même le transtypage dans ce cas aurait dû aboutir à une erreur) ; c'est la raison aussi pour laquelle PHP est considéré comme non typé.
Si par contre, on avait $a = $a + 1 => "3 maisons1" alors on aurait pu dire qu'effectivement $a pourrait être de typage fort avec un transtypage implicite correcte qui est de convertir l'entier 1 en sa représentation chaîne de caractères avant de la passer à l'opération de concaténation '+' (si '+' est l'opérateur de concaténation bien sûr)
[^] # Re: Ruby On Rails
Posté par Éric (site web personnel) . Évalué à 2.
> Quand tu écris $a = "3 maisons" on lui a assigné une valeur de type chaîne de caractères.
Il n'y aurait pas contradiction entre ces deux phrases ?
Pour moi qu'une fonction gettype() puisse retourner un type déterminé non ambigue et toujours le même dans une situation similaire veut bien dire qu'un tel type existe (contrairement à d'autres domaines, je pense par exemple à sqlite pour qui tout est chaine de caractère et qui ne "résoud" les choses en nombre que lors des opérations genre addition).
> Mais lorsque tu fais $a + 1, si ta variable était de type fort, alors une erreur aurait
> été levée parce que l'on ne peut pas additionner une chaîne avec un entier.
Le fait que tu puisses faire "3 maisons " +1 ne veut pas dire que "3 maisons" n'a pas de type, ça veut dire qu'il y a transtypage implicite (le terme même de transtypage sous entend qu'il y a un type d'ailleurs).
Notes que des transtypages on peut aussi en avoir dans des langages très fortement typés comme en C ou C++ (jamais eu l'avertissement du compilo qui a casté un char dans un int ? un pointeur dans un int ? ou le contraire ?). Ca n'en fait pas des typages faibles pour autant.
> Si par contre, on avait $a = $a + 1 => "3 maisons1" alors on aurait pu dire
> qu'effectivement $a pourrait être de typage fort avec un transtypage implicite
> correcte qui est de convertir l'entier 1 en sa représentation chaîne de caractères
> avant de la passer à l'opération de concaténation '+' (si '+' est l'opérateur de
> concaténation bien sûr)
Ah ? donc si j'emploi l'opérateur de concaténation (en php c'est le point) et que ça donne ce que tu dis c'est un langage typé fort ? planté ... $a = $a . 1 donne effectivement "3 maisons1"
Pourquoi ? la seule différence entre ton $a = $a + 1 => "3 maisons1" et ce qu'il se passe réellement c'est qu'il n'a pas fait le transtypage sur la même donnée que tout. Il a fait le transtypage sur le $a au lieu de le faire sur le 1 (ce qui est plutot intelligent vu que dans l'exemple il s'agit d'une addition et pas d'une concaténation, qui sont des opérateurs différents). Mon addition est une opération qui attend deux nombres, on lui donne une chaine, il convertit donc la chaine en nombre implicitement. Ca ne contredit pas du tout la présence de typage.
Dans l'absolu l'opération est la même (transtypage), les principes mis en jeu sont les mêmes (repérer qu'une des valeurs n'a pas le type attendu et faire un transtypage implicite quand c'est possible pour faire concorder).
Ceci dit ça montre bien ce que je disais : la limite du typage fort et du typage faible n'a rien d'une limite claire et objective (même si on est tous les deux d'accord pour dire que le typage de PHP est on ne peut plus faible)
[^] # Re: Ruby On Rails
Posté par tgl . Évalué à 4.
$a="chaine"
gettype(a) // repond string
$a=1
gettype(a) // repond int
(Est-ce possible ? perso j'en sais rien je connais pas PHP)
Un typage fort devrait soit :
- t'interdire la seconde affectation parceque "int" c'est pas "string" (ni un de ses éventuels sous-type si le langage possède ce genre de notion, comme en objet)
- soit te répondre avec par type composé genre "string U int" pour les deux gettype (cette 2ème hypothèse étant bien sûr comme je la présente là un peu bidon... Inférer systématiquement des unions dès que nécéssaire, c'est un peu tuer l'idée de vérifier une certaine cohérence des types. Mais par contre, avec possibilité de déclarations explicites, ça le fait.)
[^] # Re: Ruby On Rails
Posté par Miair Patreau . Évalué à 2.
Ou alors, tu veux dire qu'un typage fort et dynamique devrait faire quelque chose du genre :
$a="chaine"
gettype(a) // repond string
settype $a=1
gettype(a) // repond int
[^] # Re: Ruby On Rails
Posté par Miguel Moquillon (site web personnel) . Évalué à 2.
Je crois que je ne me suis pas fait bien comprendre.
Dire que quand une variable référence un valeur d'un certain type n'implique pas que le langage est fortement typé.
De même, d'une variable qui référence une valeur d'un certain type, puis plus loin d'un autre type n'implique pas non plus que ton langage soit faiblement typé.
Si jamais ton langage te permet, par exemple, d'additionner un entier avec une chaîne de caractères (ton exemple) qui sont donc de deux types complétement différents, alors ton langage supporte le typage faible. Dans un typage fort, on ne peut utiliser une opération sur un type autre que celui attendu et il ne peut avoir de coercition mathématiquement incorrect. Par contre, le fait d'additionner un entier avec un réel ne posent pas de pb parce que l'un est sous-type de l'autre (on ne va pas entrer dans les détails du sous-typage), et dans ce cas on a souvent un transtypage implicite et qui est mathématiquement correcte.
Bien sûr cette condition n'est pas suffisante en elle même pour dire qu'un langage est typé fort.
Après, l'usage implicite ou explicite de coercition affaiblit la force du typage de ton langage ; c'est pour ça que l'on dit que tel langage à un typage plus fort qui tel autre, les deux étant de typage fort.
A côté de ceci, C est un langage à typage statique faible.
Le typage fort ou faible n'est pas une question de cuisine selon les points de vues. Des théories mathématiques ont déjà été élaborées pour décrire le typage (Hoar, Liskov, Cardelli pour ne citer que les plus connus).
[^] # Re: Ruby On Rails
Posté par gc (site web personnel) . Évalué à 3.
Un langage est fortement typé si les conversions implicites de types sont formellement interdites. Si de telles conversions sont possibles, le langage est faiblement typé.
on en arrive à Java faiblement typé, ce qui est un peu déconcertant.
[^] # Re: Ruby On Rails
Posté par Éric (site web personnel) . Évalué à 2.
Comme quoi ....
# Ajax on Rails en photo
Posté par Lucas . Évalué à 7.
source: al_ sur #openweb@freenode
# une conference sur le sujet ??
Posté par PloufPlouf (site web personnel) . Évalué à 2.
moi je suis pythoniste on zope alors ca me titile ce truc mais j'arrive pas vraiment a me faire une idée
j'arrive pas a lire les .mov sur le site officiel
une conference sur sujet serait tres interessante
en vous remercient...
[^] # Re: une conference sur le sujet ??
Posté par Ramso . Évalué à 6.
Mais bon, tant qu'on jette l'API de Zope, c'est déjà un progrès !
# Et déjà un livre sur le sujet
Posté par undeuxtroisout . Évalué à 4.
http://pragmaticprogrammer.com/shopsite_sc/store/html/(...)
Je n'ai aucune affiliation avec eux, je suis juste un client satisfait.
# Après avoir testé rails...
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 1.
Bref, j'ai plutôt envie de le virer pour l'instant, et si j'ai un blog à tenir par exemple d'utiliser des typepad ou autre et plus me faire chier avec la maintenance d'un outil qui change tout le temps suivant le buzz du moment.
[^] # Re: Après avoir testé rails...
Posté par Frederick Ros . Évalué à 5.
Typo est un outil fait avec Rails .. ce n'est pas Rails ...
Si tu regardes des trucs comme BackPack ou YubNub (http://www.yubnub.org/,(...) fait en 24 h lors du Rails Day), c'est assez sympa ...
De meme si tu recuperes certaines des applis faite en utilisant rails et que tu regardes le code source tu seras (peut-etre) surpris par la clarte et le peu de LOC necessaires ...
Le mieux pour s'en faire une idee c'est de developper qq chose avec .. pas d'utiliser un outil qui est base sur Rails :)
Mes .2 $
[^] # Re: Après avoir testé rails...
Posté par Damien (site web personnel) . Évalué à 3.
Bon c'est vrai, j'ai facilement des temps de rendu de quelques secondes sur mon typo (qui tourne sur une Sun 360 MHz). Mais avec du cache ça devient tout de suite plus agréable, on croirait templeet sauf que le code est lisible et pas tout mélangé :-]
[^] # Re: Après avoir testé rails...
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 0.
Puis dans le cas de Typo spécifiquement son auteur pourrait au moins faire en sorte que les appels vers les aggregations extérieures (flickr, etc) se fassent par le biais d'appel javascript pour que la page principale, dans le cas ou il faut mettre à jour toutes ces boites, s'affiche quand même rapidement.
Enfin bon au final je trouve que ça vaut pas le bruit qu'on en fait autour, mon avis changera peut-être.
[^] # Re: Après avoir testé rails...
Posté par Damien (site web personnel) . Évalué à 2.
pour les feeds, c'est un problème de temps du devel de typo... je compte le faire dès que j'ai l'esprit libre (càd. début juillet) mais libre à quiconque de proposer des patches, c'est du libre!
[^] # Re: Après avoir testé rails...
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 1.
[^] # Re: Après avoir testé rails...
Posté par Frederick Ros . Évalué à 1.
[^] # Re: Après avoir testé rails...
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 1.
Si tu parles de http://www.backpackit.com/(...) je vois mal comment je pourrais, les sources ne sont pas disponibles. Donc si tu te bases sur un site spécifiquement pour juger d'une technologie, c'est fort.
Ce site pourrait être développé en php, java, ou même en C sans que tu le saches, et en offrant les mêmes fonctionnalités. Il est fait par des mecs qui maitrisent rails, donc il utilise rails, c'est tout.
J'apprécie et je teste les sites faits par les mecs de rails, mais ces sites ne sont bien que parce que les mecs qui les codent sont bons. Flickr est pas codé sous rail, ni google map...
[^] # Re: Après avoir testé rails...
Posté par Frederick Ros . Évalué à 2.
>J'apprécie et je teste les sites faits par les mecs de rails, mais ces sites ne sont bien que parce que les mecs qui les codent sont bons. Flickr est pas codé sous rail, ni google map...
C'est sur qu'un mec bidon meme avec la meilleure des technos va pondre une merde ... mais si tu te referes au niveau des codeurs pour juger une techno ben .. je comprends pas vraiment :(
[^] # Re: Après avoir testé rails...
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 1.
Ce que je suis en train de te dire, c'est qu'on parlait de rails, et que toi tu dis "Si tu regardes des trucs comme BackPack (...), c'est assez sympa", moi je dis ouais c'est sympa, mais ça a rien à voir avec rails, c'est tout. TaskThis c'est pareil, c'est sympa, ça pourrait être fait en n'importe quoi, ça prouve en rien que rails est bien (ou non).
Tout ce que je vois avec rails pour le moment c'est que c'est chiant à mettre en place, que ceux qui en parlent le plus sont ceux qui ont pas essayés en fond de faire un site complet avec, et que ceux qui l'utilisent le mieux font partis des développeurs rails (ou pas loin).
Quand je regarde les démo et les specs de C# / .net 2.0 je vois des trucs beaucoup plus innovants, ça me fait mal de le dire, mais c'est comme ça. Et question perfs, ça a rien à voir.
[^] # Re: Après avoir testé rails...
Posté par Frederick Ros . Évalué à 3.
Effectivement puisque tu le dis, ca n'a rien a voir avec Rails .. Ca a ete fait en shell.
TaskThis c'est pareil, c'est sympa, ça pourrait être fait en n'importe quoi, ça prouve en rien que rails est bien (ou non).
NON. La difference est dans le code que tu as a ecrire (entre autre). J'ai mentionne TaskThis car tu demandais un example (je ne vois d'ailleur pas pkoi tu en as besoin si tu connais deja:)
Evidemment tout peut-etre fait en n'importe quoi .. mais bon je pense que dans l'ensemble un taskThis sera plus simple a faire avec Rails qu'en Cobol .. mais je me trompe peut-etre et c'est vrai que ca ne montre pas que Rails est mieux que le Cobol pour ecrire un appli web.
Tout ce que je vois avec rails pour le moment c'est que c'est chiant à mettre en place,
Moi pour ce que je fais avec je vois pas en quoi c'est chiant .. mais encore une fois tu peux envoyer des patchs pour simplifier le process d'installation !
que ceux qui en parlent le plus sont ceux qui ont pas essayés en fond de faire un site complet avec, et que ceux qui l'utilisent le mieux font partis des développeurs rails (ou pas loin).
C'est un peu comme les gens qui denigrent au lieu d'essayer de faire avancer le schmillibilick en envoyant des patches quand ils sont de bonnes idees.
Et question perfs, ça a rien à voir.
Woa ... l'argument massue :)
[^] # Re: Après avoir testé rails...
Posté par TImaniac (site web personnel) . Évalué à 2.
Parfois il faut mieux se faire une raison et laisser tomber une techno plutôt que de s'evertuer à envoyer des "patchs" pour tenter de transformer un cochon en une poule dans l'espoir qu'elle nous ponde des oeufs.
[^] # Re: Après avoir testé rails...
Posté par Nicolas Roard (site web personnel) . Évalué à 4.
J'ai l'impression que c'est très bien pour les trucs pour lesquels c'est fait, mais si t'as des trucs compliqués à faire c'est la merde.
Pour ce que j'en ai vu, je suis d'accord avec toi -- rails est très bien pour des applis CRUD, mais pour un truc complexe, c'est plus chiant. Mais bon, on fait souvent des trucs simples, et dans ce cas, rails est bien pratique.
Pour des trucs plus complexe, je recommande Seaside, c'est vraiment excellent et bien fichu.
http://www.seaside.st(...)
[^] # Re: Après avoir testé rails...
Posté par Stéphane Traumat (site web personnel) . Évalué à -1.
http://about.me/straumat
# Hébergeur?
Posté par Tristram . Évalué à 4.
Bien sur j'ai pas les moyens d'un dédié... Parce que pour l'instant j'ai jamais vu autre chose que du php :(
[^] # Re: Hébergeur?
Posté par Miair Patreau . Évalué à 3.
C'est bon, c'est bon, je peux sortir tout seul... Hé ! Mais ouvrez la porte avant, au moins !
[^] # Re: Hébergeur?
Posté par Frederick Ros . Évalué à 2.
http://textdrive.com/(...)
http://planetargon.com/(...)
et apparament le petit dernier:
http://www.dreamhost.com/(...)
tu peux aussi bidouiller sur freeshell.org ...
[^] # Re: Hébergeur?
Posté par Tristram . Évalué à 1.
Faudra voir ce que je ferai finalement :)
[^] # Re: Hébergeur?
Posté par Alexandre DATH (site web personnel) . Évalué à 2.
Si ca vous interesse (pour participer à la beta etc.) : rubyonrails@ikse.net
# Une photo
Posté par Pascal Terjan (site web personnel) . Évalué à 2.
[^] # Re: Une photo
Posté par Damien (site web personnel) . Évalué à 2.
https://linuxfr.org/comments/590906.html#590906(...)
faut pas poster à des heures impossibles comme ça Pascal :)
[^] # Re: Une photo
Posté par Pascal Terjan (site web personnel) . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.