Journal Impressionné par Heroku (Ruby on Rails)

Posté par  .
Étiquettes : aucune
0
29
fév.
2008
L'idée d'Heroku est simple et surement déjà existante par ailleurs, mais sa réalisation m'impressionne. Il s'agit tout simplement d'une interface web permettant de coder son site web avec le framework ruby on rails d'une manière parfaitement intégrée. Il est aussi possible de déployer sur un serveur privé, ou sur un hébergement externe type Amazon.

Le nombre de fonctionnalité est assez grande :
- accès à la console
- utilisation des tâches rake
- automatisation de l'installation des plugins
- bien sûr utilisation possible des assistants de génération de code
- un accès total au système de fichiers de la solution

Évidemment, des défauts existent :
- ça reste du web, l'interface ne vaudra jamais votre éditeur de texte préféré
- pas de possibilité d'onglet, et donc navigation fichier par fichier en passant pas l'aborescence
- pas de possibilité d'utiliser piston pour l'installation de plugins non-officiels (comme attribute_fu que je considère idéal pour la création de formulaire mutli-model (ce qui est galère)

En bref, j'aime beaucoup, bravo aux créateurs de ce site ! Si l'équivalent existe pour d'autres frameworks (django, cakephp, grails, etc...), je suis intéressé. Non, ce n'est pas un appel au troll, je considère qu'avoir l'embarras du choix est très positif.

Pour ceux qui veulent des invitations, envoyez-moi votre email par message privé.

  • # Coder avec un éditeur préhistorique ?

    Posté par  . Évalué à 4.

    J'avoue avoir beaucoup de mal à imaginer qu'on puisse code par l'intermédiaire d'une interface Web, c'est à dire, le plus souvent, avec des fonctionnalités inférieures à celles des traitements de texte du dernier millénaire.

    Quelqu'un peut-il m'expliquer ?

    • [^] # Re: Coder avec un éditeur préhistorique ?

      Posté par  . Évalué à 2.

      Soyons clair : ce n'est pas pour coder comme tu l'imagines. Je m'en sers pour débuter sur ce framework, apprendre des trucs, travailler dessus sans autorisation depuis mon boulot, etc... Il se trouve qu'en plus, j'ai 4 ordinateurs chez moi (oui, je suis geek) et que je ne suis pas un codeur pro. J'aime bien le fait d'avoir un site web qui concentre mes devs sans avoir à m'occuper de transférer des fichiers, d'avoir un serveur chez moi qui centralise le code, etc...

      Sinon, j'ai vu que des gens l'utilisait beaucoup par import/export depuis leur ordinateur, l'interface web n'étant dans ce cas utilisée que pour effectuer de toute petite modification et des déploiements.

      • [^] # Re: Coder avec un éditeur préhistorique ?

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

        Je pense que c'est un peu comme Zope Management Interface.

        Tu peux tout faire avec mais pour un vrai projet ce n'est pas la bonne voix. Ni pour le dev, ni pour les tests, ni pour la maintenance.

        Par contre ça permet de te plonger dans la technologie facilement, de reprendre un projet et de comprendre comment il fonctionne, de bidouiller des modifs rapides sur des instances de test, du debugage, ou d'aller regarder l'état actuel des choses.

        http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/(...)

        • [^] # Re: Coder avec un éditeur préhistorique ?

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

          Je pense que c'est un peu comme Zope Management Interface.

          C'est cette possibilité qui a fait le succès de Zope dans sa version 2. Mais ils ont fini par trouver que c'était pas une bonne idée. Pour l'actuelle version 3 ils ont tout réécrit et l'édition de code « through the web » n'est plus vraiment possible, et déconseillée.

      • [^] # Re: Coder avec un éditeur préhistorique ?

        Posté par  . Évalué à -4.

        travailler dessus sans autorisation depuis mon boulot

        Très très bon esprit, ça. Et après on se demande pourquoi les entreprises hésitent à nous embaucher, nous les jeunes.

        • [^] # Re: Coder avec un éditeur préhistorique ?

          Posté par  . Évalué à 3.

          Qui t'as dit que j'étais jeune ? :) Par contre, ça fait partie de mon boulot de me former sur les différentes technos.

          • [^] # Re: Coder avec un éditeur préhistorique ?

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

            Donc si cela fait partie du boulot, il faudrait faire comprendre au boss que non, bloquer le ssh ou le ftp c'est une connerie :) puisque cela bloque des activités légitimes ...

            /me n'a jamais compris cette parano imbécile des dsi ...
            ou alors ça n'est pas tout à fait "partie du boulot" :)

            • [^] # Re: Coder avec un éditeur préhistorique ?

              Posté par  . Évalué à 2.

              Imagine un administrateur de base de données : Il a accès à quasiment toutes les données de la boite. Pour peu qu'il sache comment récupérer les infos sensibles, d'un coup de ssh il prépare activement sa retraite.

              Le risque 0 n'existe pas de se retrouver face à un employé malveillant (demande à la SG pour voir), alors on met en place des mesures, certes débiles, mais qui freinent un petit peu les ardeurs de certains.

  • # Curieux

    Posté par  . Évalué à 1.

    Effectivement, j'en ai entendu parler plus d'une fois dernièrement et ça semble impressionnant. Maintenant, on verra à l'usage le réel bénéfice apporté.

    Ceci dit, je pense que des solutions permettant de faciliter l'installation / déploiement d'un environnement rails lève un des trois gros freins à une adoption plus large.

    Les deux autres étant à mon sens les performances perfectibles (mais ça semble en plutôt bonne voie), et surtout une certaine "inertie" des développeurs, hébergeurs, cravatteux... Inertie que j'ai parfois l'impression de ressentir plus par ici que dans d'autres régions du monde, par exemple un regardant les offres d'emploi. (non, je ne dit pas ça uniquement car on est vendredi...)

    Je t'envoie mon adresse mail par mp car je voudrais voir de mes propres yeux :)

  • # ça existe déjà ... en mieux

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


    L'idée d'Heroku est simple et surement déjà existante par ailleurs, mais sa réalisation m'impressionne.


    Oui, ça existe déjà et depuis un certain temps : seaside avec squeak (pas testé avec les autres environnements smalltalk).
    Seaside est un framework Smalltalk de développement d'applications Web orienté composant et supportant (le premier d'ailleurs) la continuation. Depuis un bon bout de temps, tu peux développer à distance via une interface Web des applications seaside.

    Et comme smalltalk est un environnement dynamique complet, tu peux donc modifier et corriger ton appli à chaud.

    Comme diraient les smalltalkers : smalltalk, toujours imité, jamais égalé ;-)

    Il n'en reste pas moins que l'initiative d'Heroku est intéressante et offre de nouvelles possibilités au framework RoR.

    • [^] # Re: ça existe déjà ... en mieux

      Posté par  . Évalué à 4.

      >"corriger ton appli à chaud"

      Franchement je me demande à quoi ça sert... pour moi le cycle de maintenance d'un site web serait plutôt ça (cas pour un seul développeur) :

      1. Modifications sur le poste de développement.
      2. Tests des modifs par le développeur.
      3. Commit des modifs sur le repo (par exemple SVN).
      4. Mise en pré-production (automatisée par des scripts bien sur)
      5. Validation par le client, si pas ok on revient en 1.
      6. Finalement, mise en production (toujours automatisée).

      Quels sont les avantages à se taper un éditeur web (tout pourri?) pour modifier un site en production ?

      • [^] # Re: ça existe déjà ... en mieux

        Posté par  . Évalué à 3.

        Qui a dit qu'il fallait modifier en production.

        Moi, l'avantage que je vois, c'est par exemple:
        l'utilisateur vient te voir, explique que patati patata il faut modifier ici, et la.
        Tu le fait en live, sur ton poste de dev, et tu as un retour immédiat.

        Par ailleurs, c'est aussi intéressant pour ce qui n'est pas testable facilement par des test unitaires, genre tout ce qui est interface graphique.
        Tu modifie, et tu vois tout de suite le résultat.
        Pas besoin de recompiler, redéployer, et éventuellement redémarer ton serveur.

        • [^] # Re: ça existe déjà ... en mieux

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

          Quelle est la différence à l'utilisation avec par ex. une appli PHP ? Tu ouvres ta vue ou ton controller ou autre, hop tu modifies quelques lignes et un refesh suffit. En rails également, je ne trouve pas qu'il y ait beaucoup de cas ou l'on ait besoin de relancer le serv, et au pire des cas cela prend quelques secondes

          • [^] # Re: ça existe déjà ... en mieux

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

            Oui tout à fait. Néanmoins c'est bcp plus rapide de porter les changements via une IHM distante (que celle-ci soit Web ou autre) et ceci d'autant plus si le serveur, même de développement, est sur une machine distante.

            En fait, la véritable plus value, à mon avis, est de pouvoir déboguer ainsi une appli. Par exemple, lorsqu'une exception se lève, de pouvoir y être informé, de corriger le pb à chaud, et d'informer l'application web de reprendre le contexte d'exécution au moment de la levée de l'exception. Et ceci sans à redémarrer l'application.
            Dans Java, avec JPDA, ceci peut-être fait, en partie, via l'IDE (Netbeans par exemple). Toutefois, cela nécessite à la JVM d'être exécutée en mode debug, ce qui est coûteux. (Reste que la partie déploiement des modifs sans redémarrer le tout, ce n'est pas encore ça !)

      • [^] # Re: ça existe déjà ... en mieux

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

        Comme l'a dit Papa Furax, tu modifies à chaud sur la plate-forme de dev, ce qui te permet d'avoir un retour immédiat (c'est d'ailleurs la façon de développer dans smalltalk: un développement interactif, itératif et incrémental).
        Ensuite, une fois la nouvelle version stable, tu la publies sur un serveur Montecillo, tu informes à l'application distante en prod qu'il y a des modifs et cette dernière va charger la nouvelle version de Montecillo à chaud (et ceci sans un arrêt/redémarrer !).

        Note : le processus d'être informé d'un changement et de récupérer en arrière-plan les changements sur un serveur Montecillo est à développer dans l'appli, mais ceci ne prend qu'une dizaine de lignes de code !

  • # J'aime quand même

    Posté par  . Évalué à 2.

    J'aime beaucoup Heroku, non pas pour l'utiliser, mais pour faire des demos de l'environnement rails.

    Ca permet de vite montrer à quelqu'un qui ne connait pas ce framework les intérêts et les faiblesses aussi.

    Mais en Rubyiste convaincu , je n'irais pas developper une apli la dessus.
    Et en tant que libriste non plus d'ailleur. Car je n'ai pas l'impression que ce soit ouvert.

Suivre le flux des commentaires

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