Journal : Impressionné par Heroku (Ruby on Rails)
Posté par lezardbreton (Jabber id, page perso, ) le 29 février 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é.
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é.
> Lire le journal (18 commentaires, moyenne: 2).
Vous avez demandé le commentaire #909184.
Run by 
Cette page a été générée par Templeet en 0.0525s (dont 0.005 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
ça existe déjà ... en mieux
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
>"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
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
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
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
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 !