Bruno Michel a écrit 3285 commentaires

A List Apart a publié un article sur comment débuter avec Rails : http://www.alistapart.com/articles/gettingstartedwithrubyonr(...)

Pour débuter avec Ruby on Rails, je te conseille d'acheter (ou te faire prêter) un livre, et si possible, un livre sorti en 2008. La raison est toute simple : Rails 2.0 est sorti à la fin de l'année dernière, et qui dit changement de version majeur, dit souvent gros changements. La version 2.1 n'est pas encore sortie, et elle ne devrait rien casser pour les applications développées avec rails 2.0.

Si tu viens du monde PHP, j'ai entendu beaucoup de bien du livre "Rails for PHp developers" et du site qui l'accompagne : http://railsforphp.com/ .

Sinon, la 3ème version du livre Agile Web Development with Rails est sortie en version Beta aujourd'hui : http://www.pragprog.com/titles/rails3/agile-web-development-(...) . Les précédentes éditions étaient très bonnes, mais je n'ai pas encore eu le temps de lire celle-ci.

En français, tu peux trouver un PDF (payant) sur Peepcode : https://peepcode.com/products/rails-2-pdf-fr . En général, les PDF de Peepcode valent leur prix, mais je n'ai pas lu celui-ci en particulier.

Enfin, j'apprécie fortement les Railscasts : http://railscasts.com/ . Ce n'est pas forcément ce qui convient le mieux pour commencer, mais cela peut pratique sur un point précis. Par exemple, il y a un railscast consacré aux migrations avec rails 2.0 : http://railscasts.com/episodes/83 .

Bof, il n' y en pas vraiment besoin : les lecteurs de LinuxFR en débâtent déjà assez souvent dans les autres dépêches.

Comment faites-vous alors pour contourner ce problème ?

Oh, bah c'est simple : je n'utilise plus PHP, mais rails. Ca marche aussi avec un tas d'autres langages/frameworks.

Si php pouvait s'installer facilement en mode machine virtuelle, il serait alors le champion toute catégories des developpements web.

Faut pas exagérer, PHP a des qualités, mais il a aussi de gros défauts, à commencer avec son API qui n'est ni orientée-objet, ni cohérente.

http://article.gmane.org/gmane.comp.version-control.bazaar-n(...)

Il semble y avoir effectivement des rapports supérieurs à 1 pour 10 000 sur certaines commandes. C'est, par exemple, le cas pour log sur les 10 ou 100 dernières révisions :
Last 100 revisions:

$ time git log -100 >/dev/null
real 0m0.011s

$ time bzr log -l100 >/dev/null
real 2m10.270s

Last 10 revisions:

$ time git log -10 >/dev/null
real 0m0.007s

$ time bzr log -l10 >/dev/null
real 2m9.163s


Merci ! Je vais enfin pouvoir dire tout le mal que je pense de ce site.

Je n'ai jamais vu un site aussi innovant sur les erreurs : site qui rame, qui ne s'affiche pas correctement si on n'a pas les polices standards aux bonnes tailles, recherche qui me renvoie pas ce qu'on lui demande (c'est connu Paris-Metz et Paris-Montpellier, c'est quasiment pareil), perte de sessions, erreurs techniques en tout genre, s'acharne à me dire que mon adresse n'est sûrement pas bonne (pourtant j'utilise toujours la même, et je reçois bien mes billets), et j'en oublie tant d'autres...

Sinon, je recommande http://voyages-sncf.mobi/. Ca marche beaucoup mieux que le site web classique (oui, c'est pas dur).

Oui, git stocke aussi ces fichiers dans le répertoire courant (dans le répertoire .git). Il n'est donc pas plus à l'abri des erreurs de manipulations. La seule différence, c'est que git utilise un seul sous-répertoire, alors que svn créé un .svn par répertoire.

> http://subversion.tigris.org/faq.html#change-log-msg

OK, merci pour l'info. Je n'avais jamais entendu parlé de cette possibilité.

> Ensuite pour l'annulation d'un commit, un simple svn merge -r revAAnnuler-1:revAAnnuler suffit.

svn merge -r revAAnnuler:revAAnnuler-1 d'ailleurs.

Voici deux exemples de projets de petite taille pour lesquels git est particulièrement bénéfique.


Le premier exemple est les bundles pour TextMate :

« Whilst Git was created by Linus for managing the Linux project, I get the feeling that Git’s raison d’être was to manage TextMate bundles. Weird since Linus probably doesn’t use TextMate.

A TextMate bundle is a combination of common/default snippets and personal snippets. Those personal snippets may even be useful for other people. Other people way want them. They may even join the set of default snippets. »

Source : http://drnicwilliams.com/2008/02/03/using-git-within-a-team/

En effet, les bundles de TextMate (ou les extensions d'emacs ou les fichiers de syntaxe de vim, etc.) sont des fichiers que l'on partage, mais qui sont souvent légèrement modifiés : changer le raccourci clavier pour telle fonctionnalité car il est dur à taper sur un clavier azerty, remplacer une couleur par une autre, désactiver telle option parce que l'on a un plugin qui fait ca en mieux...



Le deuxième exemple est les plugins pour Ruby on Rails.

« Also, I believe that a lot of developers will also be motivated to move their plugins/gems to GitHub because they simply can't always maintain their own libs and/or just hope people will fork their project and contribute back. »

Source : http://railsontherun.com/2008/3/5/starting-the-migration-to-(...)

« This marks a turning point for me in my opensource contribution. The barrier to entry for pushing patches is so low that I expect to see myself cloning a bunch more repos and making my teeny tiny fixes. »

Source : http://blog.bitfluent.com/post/26592090

Quand on utilise régulièrement les plugins pour Ruby on Rails, on
se retrouve souvent à devoir faire des modifications sur les plugins : traduire les messages d'erreur, remplacer une bibliothèque par une autre (rmagick -> mini-magick), adapter le plugin pour qu'il passe avec la dernière version de rails... La plupart de ces modifications n'arriveront jamais sur le dépôt officiel, et l'on se retrouve à refaire les mêmes changements à chaque mise à jour d'un plugin, car c'est plus rapide de refaire les changements que d'essayer de merger les changements avec svn. De l'autre coté, avec git et github, on est encouragé à faire des branches séparées et les partager.

Je ne suis pas sûr que l'on se soit bien compris.

Mon exemple est le suivant : on m'envoie un patch par mail, je l'applique en local, le teste, et ca semble bien marcher. Je le commite donc dans le dépôt officiel. Dans mon message de commit, je remercie l'auteur du patch. Juste après, je retourne dans client mail, et là, je me rends que j'ai mal orthographié le prénom de l'auteur du patch.

Sous git, je peux annuler ce commit, et le refaire avec le prénom correctement orthographié. Sous svn, quel hook me permettrait de faire ca ?

> http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr(...)

Merci pour le lien. Je ne connaissais pas. Je pense que j'avais sauté cette section en me disant que vendor, c'est juste pour suivre ce qui vient de l'extérieur (svn ou autre), mais sans le modifier.

> C'est clair que git ou des choses comme ça ont leur place pour les projets hors-norme.

Justement, je pense que git a aussi sa place pour les projets moins importants. Il favorise les développements en parallèle en simplifiant le suivi et la réunification de branches.

Ca marche maintenant SVK ?

Je pose la question, car la dernière fois que je l'ai utilisé, j'ai eu plus de problèmes qu'autre chose (avec des messages d'erreur qui ne voulaient pas dire grand chose). Ca doit faire 2 ans, donc svk a largement pu évoluer depuis, et j'aimerais savoir si tu as un retour d'expérience à nous faire partager sur le sujet.

On peut annuler un commit.

Sauf à être admin, on ne peut pas annuler un commit avec svn. Par exemple, si je me suis trompé dans mon message de commit, je ne pourrais le changer, même si je m'en rends compte 2 secondes après avoir commité. Par contre, git permet de réellement annuler un commit (souvent pour le refaire plus proprement juste derrière).

> Avec subversion, seules les personnes autorisées peuvent accéder au dépôt et créer des branches pour faire des essais.

Cette politique est à la discrétion de l'admin. Des admins autorisent tout le monde à écrire dans la branche /devel par exemple. D'autres mettent tout en rw pour tout le monde car on peut "annuler" toute modification.

C'est bien ce que je dis : seuls les gens autorisés peuvent le faire. Éventuellement, l'admin peut autoriser tout le monde mais, en pratique, très peu de projets libres ont un svn ou tout le monde peut commiter.

> De l'autre coté, n'importe qui peut cloner un dépôt Git, créer sa branche expérimentale et continuer à suivre les développements fait sur le dépôt officiel.
Tu peux aussi le faire avec svn.

Si je n'ai qu'un accès en lecture seule sur le dépôt, je ne vois pas comment faire ca.

Il est présenté/discuté dans la doc de subversion (que tu devrais lire avant de parler de subversion).

J'ai lu la doc de subversion, je pense savoir de quoi je parle, et je n'ai vu nulle part comment faire une branche distante et la garder à jour. Maintenant, si tu as un lien qui dis le contraire, postes-le.

> Pour moi, la grande force des gestionnaires de versions distribués est là : pouvoir créer une branche même sans accès au dépôt officiel.

Pareil avec svn... Tu peux faire ton dépôt local si tu veux. Puis tu synchronises à la main (comme tu le fais avec git...).

Justement, avec Git, ce n'est pas à la main, et c'est ce qui fait toute la différence : git pull est là pour ca.

Franchement, si tu n'aimes pas svn et préfère git, ben utilises git. Mais ne dis pas que tel ou tel truc avec svn n'est pas possible sans te renseigner.

J'utilise quotidiennement svn au boulot, et ce depuis plusieurs années. En plus, je le trouve tout à fait adapté à cette utilisation. Par contre, pour les logiciels libres (notamment tous ceux hébergés sur sourceforge, gna, savannah, etc.), j'espère que Git va devenir plus populaire, car il permet vraiment de nouvelles manières de développer.

J'essaye de le déplacer vers la première page, mais templeet n'a pas l'air d'être du même avis que moi.

Sinon, c'est très instructif comme journal.

J'ai modifié le journal pour fermer la balise <a> qui était resté ouverte.

Je préfère un DSCM à svn pour plusieurs raisons : pouvoir commiter même sans accès au net (dans le train), parce que c'est plus simple à administrer, parce que je vais surement avoir à gérer plusieurs branches et que les DSCm me semblent bien plus efficaces que svn pour cela.

Quant aux avantages de svn, j'ai du mal à les voir.

La simplicité ? je ne pense pas que svn soit plus simple que git ou mercurial.
Puissant ? heu, tu pourrais détailler ce que svn a de plus puissant qu'un DSCM ?
Doc excellente ? Oui.
Intégration à eclipse ? Oui, mais Git a aussi un plugin, et je n'utilise pas eclipse.
Ca marche partout ? Non, ca ne marche que quand on est connecté au dépôt (donc pas dans le train).
Ca le fait ? Oui, mais un DSCM, ca le fait aussi ;-)

Citons également le plugin Trac pour Git : http://trac-hacks.org/wiki/TracGitPlugin et RedMine, un trac-like qui supporte Mercurial, Bazaar et Darcs (en plus de svn et cvs) : http://www.redmine.org/

Oui, je vais voir avec les autres personnes qui vont participer au projet. Mais j'aimerais bien attirer des contributeurs plus ponctuels dans les prochains mois, et pour eux, c'est plus dur de demander vu que je ne les connais pas. Je considère que les personnes qui vont lire ce journal sont suffisamment représentatives des potentiels contributeurs que cela vaut le coup de demander ici.

Oui, si les sites deviennent de plus en plus dynamiques. Une Dedibox suffit largement pour servir des fichiers statiques pour un traffic non négligeable. Par contre, sur un site comme linuxfr.org, ce qui bouffe, c'est la partie dynamique (php+mysql) alors qu'elle ne correspond qu'à une faible proportion des pages vues grâce aux caches.

J'en profite pour faire un peu de pub vers mon blog : http://blog.menfin.info/category/MyBook . J'ai écrit 2 articles sur le MyBook, le premier explique succinctement comment installer Mercurial et l'autre donne quelques lien sympathiques.

Seuls les admins et les modéros peuvent voir le karma.

Une solution plus simple consiste à proposer des dépêches. Chaque dépêche acceptée rapporte un certain nombre de points d'xp à son auteur (je n'ai plus le chiffre exact en tête).

Dans le même genre, on peut comparer le nombre de mots clés de différents langages sur le site d'Io (dont Java, Ruby et Python) : http://iolanguage.com/about/simplicity/

On avait pensé au sondage mais ca présente un gros défaut : les gens qui sont partis de LinuxFr.org ne vont pas voter, or c'est surtout leurs votes qui seraient utiles.

Pour le rant de Zed, ca a fait beaucoup de bruit pour pas grand chose. Il en veut à quelques mecs de la communauté Rails et à Dave Thomas. Soit, ce sont des choses qui arrivent. Et pour une réponse plus détaillée : http://www.akitaonrails.com/2008/1/3/zed-is-not-dead

Est-ce scalabilité signifie juste de mettre un serveur memcached dans l'architecture d'une plateforme ?
Il semblerait que ni PHP ni Ruby ni Python, out of the box ne permettent de batir des architectures scalables...

Oui, mettre un serveur memcached aide pour la scalabilité, mais ca ne fait pas tout. La scalabilité est principalement une question d'architecture, et les langages de programmation n'ont qu'un faible rôle à y jouer.

En attendant, Ruby on Rails n'est pas parfait mais il me semble être encore en avance sur les autres frameworks. Donc pour répondre à ta question initiale, Rails se porte très bien.