Ruby on rails 1.0 est sorti

Posté par  (site web personnel) . Modéré par rootix.
Étiquettes :
1
14
déc.
2005
Ruby
La première version majeure de 'Ruby on rails' vient tout juste de sortir.

Pour ceux qui ne connaîtraient pas encore 'Ruby on rails' ('RoR' pour les intimes), il s'agit d'un framework de développement d'applications Web en Ruby, qui permet de développer des applications Web évoluées très rapidement, en écrivant très peu de code.
Il est basé sur le modèle MVC, et supporte la technologie AJAX, les SGBD SQLite, MySQL, PostgreSQL, DB2, Oracle et Microsoft SQL Server, et inclut même son propre serveur web, nommé WEBrick, permettant de développer et tester son application directement sans avoir à installer de serveur web.

La première version de Ruby on Rails date de juillet 2004, et il a bien évolué depuis. Il a changé le monde des développeurs d'applications web, en permettant d'écrire des applications AJAX et des sites utilisant des bases de données, sans écrire une seule ligne de SQL ou de JavaScript. La première version majeure d'un logiciel est toujours une étape importante, montrant que celui-ci gagne en maturité, et que ses concepteurs le jugent prêt à être utilisé. Espérons qu'il en sera ainsi pour RoR, et que les hébergeurs web commenceront à s'intéresser à cette alternative très crédible au fameux PHP.

Aller plus loin

  • # Système d'authentification

    Posté par  (site web personnel, Mastodon) . Évalué à 6.

    Pour ceux qui auraient besoin d'un système d'authentification: http://penso.info/code/auth_generator

    Ca inclut une interface d'admin, un système facile pour choisir l'algo pour le chiffrage des mot de passe, etc.
  • # Quelques remarques

    Posté par  . Évalué à 9.

    La première version majeure d'un logiciel est toujours une étape importante, montrant que celui-ci gagne en maturité, et que ses concepteurs le jugent prêt à être utilisé.


    En l'occurence il existe déjà pas mal d'applications basées sur les versions antérieures de Rails. Aussi bien commerciales (Odeo, Basecamp, etc.) que libres (le système de weblog Typo, Collaboa, un outil proche de Trac, etc.).

    Vous trouverez une liste plus complète sur le site officiel : http://rubyonrails.org/applications

    Espérons qu'il en sera ainsi pour RoR, et que les hébergeurs web commenceront à s'intéresser à cette alternative très crédible au fameux PHP.


    Je dirais même que c'est une alternative plus que crédible. Malheureusement pour l'instant il n'y a qu'un seul hébergeur français qui propose Rails : Typhon. J'espère que d'autres feront de même !

    La liste des hébergeurs proposant Rails sur le site officiel : http://wiki.rubyonrails.com/rails/pages/RailsWebHosts
    • [^] # Re: Quelques remarques

      Posté par  (site web personnel, Mastodon) . É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.
      • [^] # Re: Quelques remarques

        Posté par  (site web personnel) . É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

    Posté par  . Évalué à 9.

    Pour ceux qui ne connaissent pas, je vous conseille vivement de découvrir cette technologie. Le framework est très bien pensé, rien que pour se donner des idées en design, il faut l'étudier.
    Tout est basé sur les capacités de ruby, allie de manière étonnante l'expressivité du perl et des vrais langages objets, avec quelques astuces en plus.
    Du bonheur !
    • [^] # Re: Ruby, c'est cool

      Posté par  (site web personnel) . É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) ?
      • [^] # Re: Ruby, c'est cool

        Posté par  . É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 ?
      • [^] # Re: Ruby, c'est cool

        Posté par  (site web personnel) . É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  (site web personnel) . É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

    Posté par  (site web personnel) . Évalué à 1.

    Je suis peut etre le seul mais ca me choque un peu de voir ca :

    import "rubygems"

    Sinon ca a l'air tres pythoniens comme langage mais je goure peut etre =)
    • [^] # Re: re

      Posté par  . É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  (site web personnel, Mastodon) . É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).
      • [^] # Re: re

        Posté par  . É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  (site web personnel) . É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  (site web personnel) . É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.

            http://about.me/straumat

            • [^] # Re: re

              Posté par  . É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.
          • [^] # Tant que tu y es...

            Posté par  . É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...

            « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

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

              Posté par  (site web personnel) . É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  . É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.

                « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

                • [^] # Re: Destructeurs

                  Posté par  (site web personnel) . É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  (site web personnel, Mastodon) . É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).
        • [^] # Re: re

          Posté par  . É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  (site web personnel) . Évalué à 5.

            [i]Generalement les gens aiment Ruby pour Ruby .[/i]

            Ou n'aime pas Ruby à cause de Ruby.
        • [^] # Re: re

          Posté par  (site web personnel) . É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  . É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.
        • [^] # Re: re

          Posté par  . É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  . É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  . É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...
        • [^] # Re: re

          Posté par  (Mastodon) . É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  . É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  . Évalué à 1.

      ça existe quelque chose comme ruby on rails en python pour faire des applis web (avec ajax etc.) simplement ?
    • [^] # Re: re

      Posté par  (site web personnel) . É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

    Posté par  (site web personnel) . Évalué à 5.

    les SGBD SQLite, MySQL, PostgreSQL, DB2, Oracle et Microsoft SQL Server

    et Firebird !
  • # Présentation en français

    Posté par  (site web personnel) . Évalué à 6.

    Pour ceux qui cherchent une petite présentation rapide de Rails, j'avais fait une petite présentation à mon LUG (http://strasbourg.linuxfr.org/) il y a un peu plus d'1 mois dont les slides sont ici:
    http://strasslab.net/blog/depot/Rails.pdf

    Et pour rappeler le contexte:
    http://strasslab.net/blog/index.php?2005/10/28/98-mini-conf-(...)
    http://strasslab.net/blog/index.php?2005/11/10/101-retour-su(...)
  • # Ruby/Java etc

    Posté par  (site web personnel) . Évalué à 1.

    Bonjour,
    Est-ce que quelqu'un pourrait résumer les avantages/inconvénients de Ruby Rails par rapport à Java/Struts (sans troller, SVP ;-) ?

    "Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier

    • [^] # Re: Ruby/Java etc

      Posté par  . É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  (site web personnel) . É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...)

      http://about.me/straumat

      • [^] # Re: Ruby/Java etc

        Posté par  . É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  . É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  (site web personnel) . É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  (site web personnel) . É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 ;)

            http://about.me/straumat

        • [^] # Re: Ruby/Java etc

          Posté par  (site web personnel) . É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.

          http://about.me/straumat

    • [^] # Re: Ruby/Java etc

      Posté par  . Évalué à 9.

      Sans troller ? Mais quel interet alors ?
    • [^] # Re: Ruby/Java etc

      Posté par  (site web personnel) . É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  . É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

    Posté par  . Évalué à 4.

    A ma connaissance, Typhon (http://typhon.net/ ) est le seul hébergeur français à proposer Rails. Leurs services ont l'air très bons, l'équipe est vraiment sympa, par contre le coût est assez élevé !

    Du côté des Etats-Unis, il semblerait que TextDrive (http://textdrive.com/ ) ait des gros problèmes de stabilité (même si c'est l'hébergeur "officiel" de Rails). J'ai également vu Planet Argon (http://planetargon.com/ ), qui me semble pas mal, avec un bon compris entre services et tarifs.

    Si quelqu'un a des retours d'expérience à ce niveau, je suis preneur.
    • [^] # Re: Hébergement Rails

      Posté par  (site web personnel) . É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  (site web personnel) . Évalué à 5.

        Faut mettre la pression à Tuxfamily pour qu'ils nous mettent ruby !
        • [^] # Re: Hébergement Rails

          Posté par  (site web personnel) . É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.
  • # A propos de la vidéo

    Posté par  (site web personnel) . Évalué à 2.

    Sur la vidéo du blog en 15 minutes, on voit a un moment un logiciel qui permet de dialoguer avec la base de données mysql en mode graphique. Quel est ce soft??
  • # livre

    Posté par  . Évalué à 1.

    Voici un superbe livre sur Ruby on Rails :

    Agile Web Development with Rails
    (anglais juin 2005 rails 1.0 / 550 pages / 26 euros chez amazon.fr)

    - un tutorial boutique online complete (avec admin et tout) (170 pages)
    - Rails en profondeur (+ajax + securite) (300 pages)
    - Ruby en condensé 20 pages
    - Code source (40 pages)

    a+

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.