Système d'authentification

Quelques remarques

• [^]Re: Quelques remarques

  Posté par Fabien Penso (Jabber id, page perso, ) le 14/12/2005 à 11:30. (lien). Évalué à 2.

  Oui enfin l'outil proche de Trac, il est loiiiiin de Trac. Je pense même que le mettre en avant, c'est pas forcément un avantage visible. Les autres applis commerciales sont souvents celles de 37 Signals, ou de gens très proches du développement rails.

  --
  blog them all :: la photo du jour
  Je vote pour LinuxFr en Rails !
  apple push notifications

  • [^]Re: Quelques remarques

    Posté par Éric (Jabber id, page perso, ) le 14/12/2005 à 12:17. (lien). Évalué à 3.

    Si tu as touché un peu, est-ce que je peux profiter de ton retour pour te demander ce qui manque par rapport à trac ou les difficultés d'utilisations que tu as pu avoir ?

Ruby, c'est cool

• [^]Re: Ruby, c'est cool

  Posté par Fabimaru! (Jabber id, page perso, ) le 14/12/2005 à 10:32. (lien). Évalué à 2.

  Oui mais bon, je suppose que ça décollerait vraiment que si c'était adopté par des FAI genre Free.
  
  Sinon, ça donne quoi point de vue perfs ? Ca tourne vraiment en multi-thread (pas comme python/zope avec son lock global pour l'interpréteur) ?

  --
  Pas de bureau 3d libre sans drivers libres!

  • [^]Re: Ruby, c'est cool

    Posté par Guillaume DESRAT (page perso, ) le 14/12/2005 à 13:52. (lien). Évalué à 4.

    Free a prévu de mettre en place Rails pour les pages persos, juste après l'IPv6.
    
    Sisi, je vous le jure ;-)
    
    Honnêtement, il y a quelques hébergeurs qui commencent à le proposer, et c'est djà pas mal pour une technologie qui n'est en version 1.0 que depuis hier, non ?

    --
    Guillaume "Zifro" DESRAT

  • [^]Re: Ruby, c'est cool

    Posté par Luc Stepniewski (page perso, ) le 14/12/2005 à 14:12. (lien). Évalué à 4.

    Le problème c'est plutôt Ruby, qui ne supporte pas les threads natives. C'est une des raisons pour lesquelles c'est super lent. Pour chaque changement de contexte, Ruby simule le thread, alors pour recopier/remettre les données, il fait plein de memcpy.
    
    Pour le Global Lock (GIL) de Python, d'habitude ce n'est vraiment pas un problème. La plupart des applis se découpent très facilement en différents services (et c'est plus propre). Certaines applis (Twisted pour n'en citer qu'un exemple) n'utilisent pas du tout les threads, et ça fonctionne très bien et c'est super rapide.

  • [^]Re: Ruby, c'est cool

    Posté par champi (page perso, ) le 14/12/2005 à 20:12. (lien). Évalué à 0.

    Pour zope/python, y a toujours la solution de clustering ZEO: un processus par processeur. C'est pas bien compliqué à mettre en place: une instance ZEO client par proc avec un bout de fichier de conf à décommenter + une instance ZEO server.

re

• [^]Re: re

  Posté par Brice2Nice () le 14/12/2005 à 09:21. (lien). Évalué à 3.

  de maniere totalement objective : c'est mieux
  
  (allez moinsser on peut pas donner son avie perso ici, il y a un karma moutonesque)

  • [^]Re: re

    Posté par Nicolas Évrard (Jabber id, page perso, ) le 14/12/2005 à 09:42. (lien). Évalué à 7.

    Probablement parceque dire "de manière totalement objective" puis ensuite finir par "donner son avis", ça ne va pas vraiment ensemble.
    
    Pour que ce soit objectif, il faudrait que ce soit mieux que ton avis. Un truc argumenté, réfléchi, pensé. Deux lignes c'est un peu court.
    
    Et puis si tu veux lancer un troll, je te conseille franchement de prendre exemple sur les grands anciens (L. Torvalds, pour parler du plus récent), leur troll, ça a de la gueule, le tien il est tout pourri.
    
    Je ne sais pas tu aurais pu dire:
    
    

    
    De toute façon python ce n'est pas du vrai orienté-objet, et puis c'est utilisé à fond par Ubuntu qui est vraiment une distribution de neuneu. D'ailleurs je n'ai jamais aimé le fait que l'indentation soit utilisée pour séparer les blocs, et puis d'abord, il vaut mieux utiliser des Tabs que des Espaces comme renseigné dans la PEP-8, car avec les tabs je vois le code comme je le veux. Ha j'oubliais : Vim Sux0r et Emacs Rulezzzz (d'ailleurs il a été inventé par un nazi de la GPL, le communiste RMS (saviez vous que nazi c'est national-socalisme et que donc le socialisme c'est le nazisme ?)).
    

    
    
    Bon là je crois que j'ai fait le tour (je m'apperçois que j'ai oublié le TCE, les news cinéma, ... , mais j'ai la flemme de les ajouter).

    --
    Le scheme c'est bien.

  • [^]Re: re

    Posté par kang () le 14/12/2005 à 11:23. (lien). Évalué à 2.

    Ruby, c'est une syntax un peu comme perl. Dur a lire pour certains.
    Sinon, Python vs Ruby, ca se vaut sur beaucoups de points.
    
    Finalement, pourquoi les gens aiment t-il ruby ?
    => A cause de ruby on rails
    
    Pourquoi ruby on rails ?
    => Parce que ca sonne bien, avec du AJAX dedans, le site est joli et y a une demo avec textmate sous OSX en video.
    
    C'est aussi con que ca. Marketing quand tu nous tiens.. (et oui, même dans le libre :)

    • [^]Re: re

      Posté par Éric (Jabber id, page perso, ) le 14/12/2005 à 12:17. (lien). Évalué à 10.

      > Ruby, c'est une syntax un peu comme perl. Dur a lire pour certains.
      
      Ca vient du perl, c'est indéniable et il y a encore des restes. Par contre de là à dire que la syntaxe est un peu comme perl ....
      Je n'aime pas perl, j'ai toujours trouvé ça illisible. Ruby n'a pour moi rien à voir.
      
      > Finalement, pourquoi les gens aiment t-il ruby ?
      > Pourquoi ruby on rails ?
      > C'est aussi con que ca.
      
      C'est super réducteur et AMHA en large parti faux.
      
      Certes si on en parle c'est à cause de Rails. Si on parle de Rails c'est qu'ils ont eu la bonne idée de mettre à dispo des outils pour ajax et des vidéos d'introduction. Mais tout ça ne fait qu'attirer les gens à regarder.
      Derrière si après avoir regardé les gens continuent d'en penser du bien c'est qu'il y a un bon fond :
      - le langage est tout à fait dans la mouvance python : moderne, portable, objet, dynamique, facilement lisible. Personnellement j'adore le système des blocs, c'est ce qu'il m'a toujours manqué dans les autres langages de script. Le code m'a l'air très lisible (plus que du PHP ou du Python). Les possibilités de dynamismes sont aussi énormes si on regarde coté maintenance ou extensibilité. Pour exemple le langage ne gère pas les classes abstraites. Il m'a fallu quelques heures et une centaines de lignes pour rajouter ça, alors que j'ai encore assez peu d'expérience dans ruby. Je ne me verrai faire ça avec aucun autre langage que j'ai exploré.
      - Rails lui a pas mal d'avantages. Il est extrêment simple à aborder au début et automatise complètement les "80%" des projets habituels. ActiveRecord est une vrai merveille pour ça. Franchement du coté simplicité et "voici mon application en 1 mois avec très très peu de code" je ne vois aucun concurrent réel. Le seul qui peut à peu près suivre c'est Django. Le framework ne couvre pas tous les besoins, n'est pas parfait (personnellement le déteste les limitations des routes), mais couvre un réel besoin. Et pour remplir ce besoin, il est largement en avance sur tout ce qui se fait ailleurs.
      
      Il y a pas mal de buzz, c'est le buzz qui fait qu'on en parle. Mais si le buzz continue et que les technos retiennent l'attention c'est pour leurs qualité, pas pour le buzz qu'il y a autour.

      • [^]Re: re

        Posté par Stéphane Traumat (page perso, ) le 14/12/2005 à 12:38. (lien). Évalué à 2.

        http://www.riarlington.com/images/hypecyc.gif
        Je trouvais ce graphique assez bien fouttu ! et je pense que ror est dans le haut de la vague.. On va attendre que ca retombre pour voir.

        • [^]Re: re

          Posté par Guillaume DESRAT (page perso, ) le 14/12/2005 à 13:54. (lien). Évalué à 2.

          J'utilise Rails, et je n'arrive pas à tomber en "disillusionment" !
          
          Plus sérieusement, sur la liste de Rails France, il y a toujours une solution de proposée quand un problème survient.

          --
          Guillaume "Zifro" DESRAT

      • [^]Tant que tu y es...

        Posté par Arthur Accroc () le 14/12/2005 à 19:49. (lien). Évalué à 2.

        Pour exemple le langage ne gère pas les classes abstraites. Il m'a fallu quelques heures et une centaines de lignes pour rajouter ça, alors que j'ai encore assez peu d'expérience dans ruby.

        
        Si jamais en quelques heures de plus tu ajoutais de (vrais) destructeurs, je me remettrais probablement à Ruby...

        --
        « L'Homme n'est pas une marchandise comme les autres. » Nicolas S. (esclavagiste ?)

        • [^]Re: Tant que tu y es...

          Posté par Éric (Jabber id, page perso, ) le 15/12/2005 à 17:06. (lien). Évalué à 2.

          Désolé, pas d'idée la dessus. Le langage n'est pas parfait partout. Il reste cependant plus extensible à mon gout que bien des langages.
          
          (pour ceux qui ne connaissent pas la question des destructeurs/finaliseurs dans ruby : voir "Where's the destructor?" dans http://www.rubygarden.org/ruby?GCAndMemoryManagement )
          
          As tu tant besoin des destructeurs que ça ? (je sais, j'évite la question à laquelle je n'ai pas de réponse).
          Le système de bloc répond à une partie des problématiques (exemple l'implémentation de File.open(...) { .... } qui automatise la cloture du fichier)
          Dans ce qui reste le plus souvent ce sont des lignes de log ou des fermetures de connexion. Les finaliseurs de ruby ont certes une syntaxe dérangeantes mais permettent de faire le travail dans ces cas simples et clairement identifiables.
          
          Quels sont les besoins que tu as vis à vis des destructeurs et qui ne sont pas recoupés ? (je ne les remet pas en cause, je suis juste curieux)

          • [^]Destructeurs

            Posté par Arthur Accroc () le 16/12/2005 à 03:44. (lien). Évalué à 4.

            Désolé, pas d'idée la dessus.

            
            J'en avais eu une : créer une classe de base dont le constructeur crée un finaliseur appelant une méthode considérée comme le destructeur, méthode à redéfinir sur les classes dérivées.
            Seulement d'une part, le moment et l'ordre de la destruction des objets ne pourrait être garanti. Au passage, pour moi, ça démontre clairement que la gestion de la mémoire par un garbage collector est une erreur : un choix d'implémentation qui t'empêche d'implémenter un concept du paradigme, c'est un très mauvais choix.
            D'autre part, les finaliseurs sont appelés après la destruction des objets !!!
            Là, je ne vois pas ce qui obligeait à une telle aberration...
            D'un point de vue plus général, comment quelqu'un qui a fait un langage aussi génial par ailleurs a-t-il pu autant saloper la question des destructeurs ? Ruby, ça me fait penser à une Ferrari avec une roue carrée !
            
            

            As tu tant besoin des destructeurs que ça ?

            
            Que répondre ?
            Tu pourras me démontrer que je peux m'en passer, tout comme les avocats des langages qui ne supportent pas l'héritage multiple ont démontré qu'on pouvait s'en passer.
            Seulement il y a une démonstration scientifique comme quoi on peut tout programmer avec juste une machine de Turing et il est empiriquement évident qu'on peut tout faire en assembleur. Ça ne me donnera pas envie pour autant de faire mes programmes avec une machine de Turing ou en assembleur...
            Pour citer Matz :
            Above all, you can't enjoy programming with much stress.
            Là, je suis parfaitement d'accord avec lui,
            Ruby's true motto is "Enjoy programming".
            mais moi, je ne peux pas "enjoy programming" avec la complication de devoir contourner l'absence de destructeurs avec des méthodes plus lourdes ou plus moches.
            
            

            Le système de bloc répond à une partie des problématiques (exemple l'implémentation de File.open(...) { .... } qui automatise la cloture du fichier)

            
            Oui, mais cela ne se fait pas au même niveau : cela doit être fait au niveau de l'utilisation de la classe et pas seulement au niveau de sa définition comme les destructeurs.
            Si tu programmes ta classe, que tu commences à l'utiliser un peu partout, et qu'à ce moment-là, tu te rends compte qu'il faudrait que tu fasses un traitement après l'utilisation des objets, eh bien avec les blocs, tu es cuit, il faut que tu modifies toutes les utilisations de ta classe !
            
            

            Les finaliseurs de ruby ont certes une syntaxe dérangeantes mais permettent de faire le travail dans ces cas simples et clairement identifiables.

            
            D'un autre côté, si c'est pour avoir au bout du compte un programme moche, je n'ai pas d'intérêt à passer à Ruby, je reste à Perl. Au moins avec Perl, c'est la syntaxe du langage qui est moche, pas la conception de tes programmes (ou alors c'est entièrement ta faute, le langage ne t'impose pas une conception sale).
            Au niveau des concepts de programmation, Perl m'a permis de continuer à faire tout ce que je faisais avant avec d'autres langages. J'attends encore de trouver un langage qui me permette de faire tout ce que je fais maintenant avec Perl...
            Cela dit, je m'inquiète un peu pour Perl 6, qui devrait utiliser un garbage collector plutôt qu'un compteur de références. Si, comme je le crains, ça implique la destruction des destructeurs, je me rabattrai sur Python, même s'il est par ailleurs trop rigide à mon goût.
            
            

            Quels sont les besoins que tu as vis à vis des destructeurs et qui ne sont pas recoupés ?

            
            Je ne sais même plus. Quand j'avais découvert Ruby, je m'étais jeté dessus (un truc (qui m'apparaissait) aussi puissant que Perl, mais en joli !) en commençant à programmer avec le premier truc pas trop gros (mais pas trop petit non plus, quelques centaines de lignes, quoi) dont j'ai pu avoir l'utilité.
            Arrivé à un moment, je me dis "Tiens, il faut que je fasse un traitement à la destruction des objets de telle classe", mais, m'apprêtant à ajouter un destructeur, j'ai un curieux trou de mémoire sur la syntaxe des destructeurs... et là, je dois faire des recherches un peu poussées... pour finalement découvrir la merde de chat sous le tapis.
            Conclusion, j'ai fini mon programme en ajoutant une méthode et en l'appelant explicitement partout où c'était nécessaire, j'ai ensuite passé du temps à essayer de programmer des destructeurs en Ruby, et puis quand j'ai vu que ce n'était pas possible, j'ai abandonné la programmation en Ruby.
            
            Parmi les langages informatiques, Ruby est ma plus grande déception.

            --
            « L'Homme n'est pas une marchandise comme les autres. » Nicolas S. (esclavagiste ?)

            • [^]Re: Destructeurs

              Posté par Éric (Jabber id, page perso, ) le 16/12/2005 à 07:56. (lien). Évalué à 2.

              > J'en avais eu une : créer une classe de base dont le constructeur crée un
              > finaliseur appelant une méthode considérée comme le destructeur,
              > méthode à redéfinir sur les classes dérivées.
              
              Oui, mais le problème concret c'est que ton finaliseur doit recevoir des paramètres (l'objet étant détruit il faut sauvegarder un contexte avant pour pouvoir se rappeler des valeur utiles). Or un système automatique ne pourra pas savoir de quelles noms d'attributs tu auras potentiellement besoin.
              
              > D'autre part, les finaliseurs sont appelés après la destruction des objets !!!
              > Là, je ne vois pas ce qui obligeait à une telle aberration...
              
              C'est volontaire d'après ce que j'ai lu.
              L'idée c'est :
              - d'empêcher toute possibilité pour l'utilisateur de poser une référence de l'objet dans une variable externe (variable globale par exemple) pendant la destruction. Ca causerait très vite des "oops". D'après ce que j'ai lu ce problème existe en java (je n'ai pas vérifié).
              - de limiter très fortement les destructeurs pour décourager les gens de les utiliser (partant du principe que la plupart des utilisations courantes sont des erreurs).
              
              Le premier point est un choix que je peux comprendre mais c'est ce qui amène la "bizarrerie" des finaliseurs ruby. Le second point est pour moi une ahération (rendre volontairement complexe quelque chose n'a jamais été une bonne idée).
              
              
              > Que répondre ?
              > Tu pourras me démontrer que je peux m'en passer
              
              Ce n'était pas mon but. C'était une vrai question, poussée par la curiosité.
              
              > Si, comme je le crains, ça implique la destruction des destructeurs, je
              > me rabattrai sur Python, même s'il est par ailleurs trop rigide à mon
              > goût.
              
              Je peux me tromper mais de mémoire python c'est un gc aussi, pas un compteur de ref.

              • [^]Re: Destructeurs

                Posté par Troy McClure (page perso, ) le 16/12/2005 à 11:38. (lien). Évalué à 2.

                non non python fait bien du comptage de references
                
                http://www.python.org/doc/2.3.5/ext/refcountsInPython.html

            • [^]Re: Destructeurs

              Posté par Fabien Penso (Jabber id, page perso, ) le 16/12/2005 à 10:57. (lien). Évalué à 2.

              Je fais pas mal de Ruby actuellement, et le truc qui m'a emmerdé c'est quand j'ai moi aussi découvert l'impossibilité des destructeurs comme on l'entend. Je comprends pas le choix de faire comme ça, et c'est le truc qui saoûle...
              
              Donc je suis d'accord sur tout ton message (sauf que je suis pas encore deçu de Ruby, c'est juste un choix qui m'emmerde).

              --
              blog them all :: la photo du jour
              Je vote pour LinuxFr en Rails !
              apple push notifications

    • [^]Re: re

      Posté par Frederick Ros (page perso, ) le 14/12/2005 à 12:21. (lien). Évalué à 3.

      Finalement, pourquoi les gens aiment t-il ruby ?
      => A cause de ruby on rails
      
      Generalement les gens aiment Ruby pour Ruby .. Certes Rails a donne un coup de boost a Ruby (ou du moins a l'eclairage "mediatique"), mais nbon .. j'ai commence Ruby alors que Rails n'existait pas .. et j'ai aime Ruby pour sa syntaxe claire et concise ... entre autre
      
      
      Pourquoi ruby on rails ?
      => Parce que ca sonne bien, avec du AJAX dedans, le site est joli et y a une demo avec textmate sous OSX en video.
      
      Hum .. certes ils sont tres forts cote marketing ... mais c'est bien plus que cela ... Developper une appli avec Rails c'est vraiment amusant ... et c'est pour cela que les gens aiment Rails

      • [^]Re: re

        Posté par DPhil (page perso, ) le 14/12/2005 à 13:26. (lien). Évalué à 5.

        [i]Generalement les gens aiment Ruby pour Ruby .[/i]
        
        Ou n'aime pas Ruby à cause de Ruby.

    • [^]Re: re

      Posté par gc (page perso, ) le 14/12/2005 à 13:19. (lien). Évalué à 9.

      Finalement, pourquoi les gens aiment t-il ruby ?
      => A cause de ruby on rails
      
      Kof kof kof ! C'est presque une insulte pour tous ceux qui connaissaient/utilisaient/appréciaient ruby bien avant que rails n'existe.
      
      Rails a le tort de faire voir ruby comme un langage dédié au web pour beaucoup qui le découvrent aujourd'hui.

      • [^]Re: re

        Posté par fredix (Jabber id, page perso, ) le 14/12/2005 à 14:40. (lien). Évalué à 3.

        Rails a le tort de faire voir ruby comme un langage dédié au web pour beaucoup qui le découvrent aujourd'hui.
        
        Ah ce n'est pas un langage dédié à GTK+ ? :D
        
        En fait tout dépend de comment on est positionné. Il y a certainement plus de développeur web que GTK+, donc l'aspect web de Ruby via RoR est tout simplement plus visible.
        Ruby fait partie de ces langages haut niveau qui permettent de développer aussi bien un site web, qu'une interface graphique ou un script système. Au même titre que python voir perl.
        Et l'avenir est bien là je pense, n'avoir à connaitre qu'un seul langage pour faire tout type de programme.

        --
        RubyFrance

    • [^]Re: re

      Posté par Erwan (page perso, ) le 14/12/2005 à 13:55. (lien). Évalué à 5.

      Un conseil: renseigne toi un peu sur ce que sont Ruby et Ruby on Rails avant donner un avis tranche comme ca. Pas besoin d'etre expert pour donner son avis pour linuxfr, mais avec ce que tu dis on comprends vite que tu n'as jamais vu de code Ruby de ta vie (ou alors tu n'as jamais vu de code Perl).
      
      A part ca, au Japon Ruby est plus populaire que Perl et Python. Ce qui a freine son essort hors du Japon, c'est que la doc en anglais est arrivee tres tard et Python a eu le temps de s'installer un peu partout.

      • [^]Re: re

        Posté par reno () le 15/12/2005 à 22:26. (lien). Évalué à 0.

        Moi, ce que j'aimes bien c'est qu'il donne un avis extremement tranché et totalement à coté de la plaque et pourtant il est monté à +5!
        
        Cela me fait douter de la qualité de la modération..
        
        Juste pour ajouter mon vote: je déteste la syntaxe de Perl (qui encourage à écrire n'importe comment) mais j'aime bien celle de Ruby, encore qu'elle soit loin d'être parfaite à mon avis: déclaration automatique des variables (je me souviens qu'avec un outil ils ont trouvé des variables inutiles dans les librairies de base de Ruby, quelle surprise, une déclaration des variables comme dans Limbo serait plus élégant..), évolution vers une syntaxe de moins en moins simple à mon avis.
        Et non RoR ne m'intérresse pas.

    • [^]Re: re

      Posté par Guillaume DESRAT (page perso, ) le 14/12/2005 à 14:04. (lien). Évalué à 1.

      Ah, je suis également obligé de réagir !
      
      "Finalement, pourquoi les gens aiment-ils Ruby ?"
      
      J'ai découvert Ruby grâce à un copain (coucou Maz (sans "t" hein !)) fin Mars 2002, et la même personne m'a conseillé de jeter un coup d'oeil à RoR il y a de cela deux mois et quelques.
      Entre temps, je te rassure, sans connaître RoR, je me suis régaler avec Ruby.
      Donc ta première affirmation est douteuse.
      
      "Pourquoi Ruby on Rails ?"
      
      Tout simplement parce que d'une part, lorsqu'on aime bien un langage, on a envie de l'utiliser partout, et d'autre part parce qu'après avoir regardé d'un peu plus près, force est de constater que c'est bien pensé !
      C'est vrai que le site est joli (surtout depuis la 1.0), les vidéos sous OSX avec Textmate en mettent plein la vue (mais elles se montrent d'excellents exemples !), et c'est vrai qu'il y a AJAX.
      Même si c'est sympa d'avoir AJAX avec RoR, ce n'est pas ça qui fait l'intérêt du framework ! C'est en bonus ! Rien ne t'empêche de "faire de l'AJAX" avec PHP et prototype.js...
      
      Bref, Ruby j'aime (gem), RoR aussi, et je pense que l'un comme l'autre mérite qu'on s'y intéresse, sans avoir d'a priori ou un esprit réducteur comme certains...

      --
      Guillaume "Zifro" DESRAT

      • [^]Y'a pas que RoR dans Ruby

        Posté par Maz (page perso, ) le 14/12/2005 à 18:22. (lien). Évalué à 1.

        Pfiou, Mars 2002 ...
        
        Y'a une jolie vidéo pour GTK+ et GTKMozEmbed aussi, y'a pas que RoR qui fait du marketing
        
        http://ruby-gnome2.sourceforge.jp/hiki.cgi?RubyZilla
        
        Sinon, avec moins de buzz, de notable :
        
        En dev web, Nitro
        http://www.nitrohq.com/
        
        Alexandria
        http://alexandria.rubyforge.org/
        
        C'est tout ce dont je me rappelle comme ça de tête, mais il y a surement pas mal d'autres choses.

    • [^]Re: re

      Posté par Yusei () le 14/12/2005 à 17:17. (lien). Évalué à 5.

      Finalement, pourquoi les gens aiment t-il ruby ?
      => A cause de ruby on rails

      
      
      Moi j'aime Ruby parce qu'il a su conjuguer le meilleur de la programmation objet, des langages de bricoleurs comme Perl, et de la programmation fonctionnelle.

• [+] [^]Re: re

  Posté par Frederick Ros (page perso, ) le 14/12/2005 à 09:39. (lien). Évalué à -1.

  Sinon ca a l'air tres pythoniens comme langage mais je goure peut etre =)
  
  
  Pas d'insulte s'il te plait !! ;) :) ;) ;)
  

• [^]Re: re

  Posté par TNorth () le 14/12/2005 à 12:26. (lien). Évalué à 1.

  ça existe quelque chose comme ruby on rails en python pour faire des applis web (avec ajax etc.) simplement ?

  • [^]Python on rails ?

    Posté par Nimlar (page perso, ) le 14/12/2005 à 12:48. (lien). Évalué à 2.

    Il y a eu un journal la dessus il y a quelques temps.
    
    http://linuxfr.org/~manatlan/19618.html
    
    J'y ai fait de belle découverte.

  • [^]Re: re

    Posté par Éric (Jabber id, page perso, ) le 14/12/2005 à 12:57. (lien). Évalué à 3.

    Le framework python qui fait du bruit et qui ressemble le plus à RoR en ce moment c'est Django : http://www.djangoproject.com/
    
    Les idées et concepts sont assez proches, mais je ne sais pas s'ils ont intégré autant d'outils javascript/ajax

    • [^]Re: et TurboGears?

      Posté par Luc Stepniewski (page perso, ) le 14/12/2005 à 14:39. (lien). Évalué à 4.

      Django est un peu en retard au niveau d'AJAX, vu qu'ils réécrivent tout de zéro. TurboGears, aussi développé en Python (http://www.turbogears.org/ ) est beaucoup plus avancé (AMHA) sur beaucoup de niveau, et est beaucoup plus proche, voire mieux dans certains cas (AJAX par exemple, ou SQLObject pour le mapping entre les objets et la base de données) que RoR. Par exemple, un graph UML automatique (http://www.checkandshare.com/blog/?p=27 ) en AJAX a été ajouté à l'admin pour voir/modifier les données de la base.
      
      TurboGears a *aussi* un screencast (http://www.turbogears.org/docs/wiki20/20MinuteWiki.mov ) de démonstration.

• [^]Re: re

  Posté par gc (page perso, ) le 14/12/2005 à 13:18. (lien). Évalué à 2.

  Sinon ca a l'air tres pythoniens comme langage mais je goure peut etre =)
  
  je sais pas trop, moi j'aime pas du tout python et pourtant j'adore ruby. ruby est plus perlien (utilisation des regexp) et a des fonctions anonymes a la coule.

SGBD

• [^]Re: SGBD

  Posté par Philippe Fremy (page perso, ) le 14/12/2005 à 09:52. (lien). Évalué à 1.

  Le navigateur web ?
  
  
  ---> []

  --
  phil.freehackers.org

  • [^]Re: SGBD

    Posté par Papey () le 14/12/2005 à 10:55. (lien). Évalué à 10.

    Tu confonds avec Thunderfox.

Présentation en français

Ruby/Java etc

• [^]Re: Ruby/Java etc

  Posté par Vincent Behar () le 14/12/2005 à 10:56. (lien). Évalué à 3.

  simplicité, rapidité, efficacité ;-)
  et pas de configuration (ou trés trés peu, juste le login/password/type de la base de données)
  
  prends quelques minutes pour regarder les vidéos, ce sera beaucoup plus efficace que l'avis de quelqu'un que tu ne connais pas...

• [^]Re: Ruby/Java etc

  Posté par Stéphane Traumat (page perso, ) le 14/12/2005 à 11:52. (lien). Évalué à 3.

  Comme d'habitude, Java est trop riche, trop de possibilité alors que ROR répond très bien à un problème simple. Un peu comme delphi répond bien au prb du rad.
  Rien que ta question peut etre discutée.. je trouve struts horrible :D je préfère jsf et d'autres te diront que wicket est mieux.
  
  Java, c le best of breed, chacun compose sa plateforme. Nous perso, c Hibernate + Spring + JSF + JOnAS.
  
  Si je voulais fais des petites applis, ROR est pas mal mais je prendrais Java Studio Creator et j'irais aussi vite qu'avec ROR sans avoir les limitations (AOP, mapping O/R, drivers db manquants, JMS, JTA, interface riches, RMI...)

  • [^]Re: Ruby/Java etc

    Posté par bengali () le 14/12/2005 à 17:42. (lien). Évalué à 7.

    Oui avec Java tu ne te fermes aucune porte si ton application Web doit évoluer en fonctionnalités "d'entreprise" (transactions XA, connexions vers des MOM, ouverture vers les Web Services etc.) et en charge (clustering, cache distribués) mais le ticket d'entrée est beaucoup trop important pour des débutants.
    
    D'autant +, que les frameworks Web frameworks Web en Java (MVC et évenementiels avec composants) sont légion et contribuent à dérouter les newbies dans leur choix.
    
    S'il faut attendre que le débutant maîtrise hibernate + Spring, + un framework Web + un conteneur Web + un IDE pour produire une application Web qui fait du CRUD et bien bonjour sa productivité.
    
    Avec ROR, la couche persistance (active records), les contrôleurs et le modèle sont parfaitement intégrés et tu ne retrouves pas avec une multitude de fichiers XML (même si les annotations Java5 ou Xdoclet ont permis d'en réduire le nombre mais dans le même temps compliquent le build).
    Le tout est facile à tester (pas de redémarrage du serveur) et déployer (copie de fichiers sans packaging à la WAR, EAR,etc.).
    
    Spring a fait un bien énorme en simplifiant l'utilisation de "technos" JEE mais difficile de retrouver la simplicité de ROR. Ceci dit Java et son "écosystème" est une valeur sûre et éprouvée côté serveur. Pour ROR, je ne l'ai pas encore vu à l'oeuvre en entreprise...

    • [^]Re: Ruby/Java etc

      Posté par pvincent () le 14/12/2005 à 19:17. (lien). Évalué à 2.

      Ok pour le côté Java : pérennité pour l'entreprise, stabilité, performance ,etc...
      Je rajoute aussi qq arguments toujours imbattables : eclipse et le refactoring.
      Allez, j'en rajoute un dernier : le côté pédagogique/universitaire qui fait bien dans les écoles d'ingé ou de Dess
      
      Cependant Java a malgré tout des défauts qui font tâche et je vous en résume qqs uns :
      - la complexité de la version 1.5 avec les generics, enums, annotations. Au final, la lecture de l'API devient vraiment barbare pour un néophyte.
      En face, Ruby modèle de langage pur objet, magnifiquement pensé (a la smalltalk) , une cohérence, une finesse dans la structure.
      Bref, c'est beau -> pour une vraie pédagogie objet, Ruby est un candidat sérieux et en plus il n'est pas élitiste, lui !
      
      - eclipse logiciel libre et la JVM de Sun pas libre : tout le monde sait que Sun n'aime pas le logiciel Eclipse et qu'il fait tout pour lui barrer la route ; un jour IBM derrière le consortium OTI en aura vraiment marre. Clash en perspective (mais j'espère me tromper). Mais bon le refactoring saura en sortir vainqueur de toute facon.
      
      - le côté entreprise pertube toujours l'innovation. J2EE a mis je ne sais combien de temps à devenir + ou - potable (allez que je te remets une petite couche de XML) mais était vendu malgré tout sous couvert de gros arguments marketing. Bref, on se retrouve avec des vieilles versions de pseudo-J2EE Oracle, IBM ou autre vendu hyper méga-cher pour rien et ca fait mal d'expliquer que Java c'est bien quand même...même si on peut tout jeter et recommencer avec un Jonas/Tomcat
      
      En conclusion, ca me rappelle beaucoup la théorie de la cathédrale (Java) et le bazar.
      Pour l'instant je n'irais pas jusqu'à dire que le bazar est incarné par Ruby. Il faut avouer que dans le secteur : PHP reprèsente mieux le bazar suivi à qq encamblures par Python. Mais bon, c'est peut-être justement trop le bazar.
      Ruby c'est le juste milieu, un bazar cohérent.

      • [^]Re: Ruby/Java etc

        Posté par Stéphane Traumat (page perso, ) le 14/12/2005 à 20:59. (lien). Évalué à 1.

        mm pour moi, le bazar est représenté par Spring ° hibernate.

    • [^]Re: Ruby/Java etc

      Posté par Éric (Jabber id, page perso, ) le 14/12/2005 à 19:17. (lien). Évalué à 5.

      > mais le ticket d'entrée est beaucoup trop important pour des débutants
      
      Même pour les non débutants. Le ticket d'entrée est très élévé (architectures complexes et grand nombre de couches/classes même pour faire des choses simples).
      Si tu n'as pas besoin de choses poussées à l'extrême, c'est souvent beaucoup de gachi. Et en pratique coté Web on n'a pas si souvent besoin de choses aussi poussées, on peut le plus souvent se contenter de ce qu'il y a de plus simple. Oui, même en entreprise (surtout en entreprise d'ailleurs, vu que c'est là que le critère "coût" est important)
      Ruby on rails (mais aussi PHP) privilégie la possibilité de faire les 80% simplement sans perdre du temps ou ajouter de la complexité. Java et permet d'attendre les 20% derrière sans surcout, mais simplement parce que la complexité tu l'as déjà mise en oeuvre pour les premiers 80%.

      • [^]Re: Ruby/Java etc

        Posté par Stéphane Traumat (page perso, ) le 14/12/2005 à 21:02. (lien). Évalué à 4.

        Comme je le dis un peu plus haut... tu as des outils comme java studio creator qui sont des superbes rad pour le web. Simple et rapide et pas 36 couches.
        
        Quand aux couches, si elles ajoutent de la complexité, elle permette aussi une flexibilité importante et une économie de code. Sur le long terme, c'est beaucoup plus rentable et je sais de quoi je parle, j'étais développeru delphi à la base ;)

    • [^]Re: Ruby/Java etc

      Posté par Stéphane Traumat (page perso, ) le 14/12/2005 à 20:59. (lien). Évalué à 3.

      je ne suis pas tout à fait d'accord avec ton analsyse, comme je l'ai dit, il n'y a pas une plateforme Java mais plusieurs, nous on a choisi hibernate + spring + jsf car elle nous semble etre la plus propre et permet de faire du code super maintenable.
      
      Maintenant si tu veux faire un truc rapide et vite fait (crud), essaye java studio creator ou JBuilder, tu auras la même chose.

• [^]Re: Ruby/Java etc

  Posté par b (page perso, ) le 14/12/2005 à 12:25. (lien). Évalué à 9.

  Sans troller ? Mais quel interet alors ?

• [^]Re: Ruby/Java etc

  Posté par gc (page perso, ) le 14/12/2005 à 13:21. (lien). Évalué à 2.

  on ne peut comparer comme cela car rails "gère"[1] la base aussi (ou alors il faut que tu rajoutes hibernate à java/struts).
  
  [1] c'est très résumé

• [^]Re: Ruby/Java etc

  Posté par Al_trent () le 14/12/2005 à 15:17. (lien). Évalué à 2.

  Je ne pourrais pas te donner d'opinion sur Struts, mais personnellement je me suis lancé dans le developpement d'une application JSF il y a un peu pres 6 mois.
  Les avantages de java:
  - bibliotheque impressionnante. Je peux générer des PDFs (jasperrepports), des documents word ou autre (openoffice controllé par Java). De plus JSF (myfaces) est fournie avec quelques composants sympa (calendrier Web), et va recevoir 100+ composants d'Oracle tres bientot. :)
  - systeme d'i18n bien rodé
  - Java est stable et tient la charge coté serveur.
  
  Les inconvenients:
  - c'est lourd.. faut pisser pas mal de code pour ne faire qu'une seule page web...
  - le cycle compiler/deployer prend du temps...
  
  RoR me parrait tres bien, mais ne repond pas encore totalement a mes besoins (surtout de reporting), donc pourquoi pas dans 1 an ou plus...
  
  

Hébergement Rails

• [^]Re: Hébergement Rails

  Posté par Strass (page perso, ) le 14/12/2005 à 17:01. (lien). Évalué à 1.

  Certes, ce n'est pas du hard discount, mais:
  1. c'est le prix à payer pour avoir du Rails
  2. c'est le prix de la qualité (enfin, on peut l'espérer)

  • [^]Re: Hébergement Rails

    Posté par Pascal Terjan (Jabber id, page perso, ) le 15/12/2005 à 07:58. (lien). Évalué à 5.

    Faut mettre la pression à Tuxfamily pour qu'ils nous mettent ruby !

    • [^]Re: Hébergement Rails

      Posté par Florent Bayle (page perso, ) le 15/12/2005 à 19:39. (lien). Évalué à 4.

      Cela sera bien sûr proposé à terme avec d'autre langages (perl, python), mais il nous reste certains détails technique à résoudre.
      
      Donc, comme dirait mon maître spirituel :
      

      Écoutez, laissez les admins faire leur travail, et dès que j'aurais de plus amples informations vous en serez les premier informés.
      Listen, let the admins do the job, and be sure I'll give you answers as soon as possible.
      Euh, luss, lätt a admins in iüla sitt job, ja gekomme hët informëre hële sofart ja gevet vëla.

      • [^]Re: Hébergement Rails

        Posté par chl (page perso, ) le 20/12/2005 à 18:44. (lien). Évalué à 2.

        Tu as oublié de dire que c'etait acid l'auteur de la citation/ton maître spitituel.

A propos de la vidéo

• [^]Re: A propos de la vidéo

  Posté par underflow () le 14/12/2005 à 21:43. (lien). Évalué à 3.

  CoCoaMyQL
  http://cocoamysql.sourceforge.net/
  
  Et l'éditeur de texte est TextMate
  http://macromates.com

  • [^]Re: A propos de la vidéo

    Posté par Uld (page perso, ) le 14/12/2005 à 22:08. (lien). Évalué à 2.

    Scheumeneu... Tout ca c'est sous Mac OS... Pas glop, pas glop.
    Quels équivalents performants conseillez vous sous gnu/linux?

    --
    Ubuntu is an ancient african word meaning : "I can't configure Debian".

    • [^]Re: A propos de la vidéo

      Posté par Mathieu Pillard (page perso, ) le 15/12/2005 à 02:16. (lien). Évalué à 3.

      Betement, mysql-query-browser ?
      http://dev.mysql.com/downloads/query-browser/1.1.html
      
      Libre, multi plateformes, des packages partout. Seul défaut: tendance a planter de temps en temps, comme ca.

livre