Ruby Forum Rails France > Avis sur une présentation de Ruby on Rails

Bonjour à tous,

Je travaille actuellement chez CapGemini et je vais réaliser une
présentation de Ruby On Rails pour l'agence Lilloise. Je réalise cette
présentation sur mon temps libre pour permettre de présenter notre
merveilleux framework au développeur Java ou .NET de CapGemini qui
souhaite découvrir ce framework.

J'ai réalisé une première ébauche. Je sollicite votre aide pour tout
commentaire concernant cette présentation et le cas échéant la
modifier en conséquence.

Vous pouvez consulter cette présentation sur :

http://shingara.fr/export/presentation-rails.pdf

J'ai aussi créé un projet Github pour celle-ci. Elle est réalisé 
entièrement en Latex/Beamer. je me suis basé en partie sur la
présentation que Laurent Julliard a réalisé lors de Paris On rails
2007. Je l'ai entre autre adapté à Rails 2.0.

Le projet github est 
http://github.com/shingara/cap-presentation/tree/master

Merci pour vos commentaires.

--
Cyril Mougel
http://blog.shingara.fr

Bonjour,

Merci beaucoup pour cette présentation.

C'est toujours agréable de relire tout ce qu'on a déjà vu sur Rails
comme un débutant :)

A+

Pierre

> Merci pour vos commentaires.
>   
Elle est chouette, et en pdf en plus !

Sur le contenu, je trouve que ca reste un discours pas assez vulgarisé, 
du genre "1 helper par controller par défaut", si tu n'as déjà bien
saisi ce qu'est un contrôleur et que tu n'as jamais utilisé du MVC
avant, pas sur que le mot helper soit très clair ;) Après on peut
l'expliquer pendant la conférence / réunion, mais c'est bien aussi si
les gens peuvent comprendre avant ;)

c'est bien d'avoir intercalé avec des exemples.

FX

2008/4/19 FX <fxguillois@gmail.com>:
>
>
>  > Merci pour vos commentaires.
>  >
>  Elle est chouette, et en pdf en plus !

elle a ete realise en Latex avec Beamer, donc que du libre. Les images
utilises sont des PNG et les graphique realise avec graphviz

>
>  Sur le contenu, je trouve que ca reste un discours pas assez vulgarisé,
>  du genre "1 helper par controller par défaut", si tu n'as déjà bien
>  saisi ce qu'est un contrôleur et que tu n'as jamais utilisé du MVC
>  avant, pas sur que le mot helper soit très clair ;) Après on peut
>  l'expliquer pendant la conférence / réunion, mais c'est bien aussi si
>  les gens peuvent comprendre avant ;)

Je m'adresse vraiment a un public d'informaticien, developpeur.
Normalement, la connaissance du pattern MVC devrait largement etre
connu. Par contr, la definission de Helper n'est pas forcement connu.
Je vais peut-etre faire une petite precision la dessus.

>
>  c'est bien d'avoir intercalé avec des exemples.

Je vais realiser une application en demo apres la presentation

Merci de ton commentaire.

--
Cyril Mougel
http://blog.shingara.fr

> Merci de ton commentaire.
>   
Comme promis l'ébauche de ma présentation.
Beaucoup plus textuelle, mais elle est destinée à être autant lue que
projetée.
Graphiquement proche de 0, j'en conviens  :)

FX

Salut tout le monde,

comme promis, Cyril, voici mes commentaires :

* page 3, tu écris "tout est objet" : c'est un abus de langage,
précise-le, au moins à l'oral

* page 11, tu écris "Utilisation du pattern ActiveRecord": ce n'est
pas un pattern, mais une bibliothèque

* page 12, tu écris "au lieu de requêtes SQL pur" : mets "requêtes
SQL pures" ou "requêtes en SQL pur" (ma préférence va à la première
forme)

* page 13, tu affiches un fichier de migration : te serait-il
possible de l'afficher avec une coloration syntaxique, pour plus de
lisibilité des mots-clés du langage, des paramètres, etc... ?

* page 14, tu écris "La classe Mapping" : quand j'ai lu ça, je me
suis dit "tiens, c'est quoi cette classe ?" ; tu pourrais appeler ça 
l'utilisation d'ActiveRecord ; tu écris plus loin "Code de la classe
de Mapping" : là aussi le "M" majuscule est trompeur

* page 14, dans ton code, on lit "all_Project - Project.find :all"...
je préfère "all_projects = Project.find :all"

* page 15, tu écris "les méthodes static" et "les méthodes
accessibles en static" : attention, static est la terminologie en
JAVA et C++, mais le terme est "méthodes de classe" ; si tu as devant
toi des développeurs JAVA ou C++, ils comprendront, mais les autres
se demanderont pourquoi tu as utilisé ce terme

* page 16, tu écris "multiples systèmes de validation" : la
formulation est mal choisie à mon avis, car les développeurs risquent
de penser qu'il y a plusieurs systèmes, au sens plug-ins par exemple,
de gestion des validations ; dis plutôt qu'on peut intervenir très 
finement dans le cycle de vie de l'objet

* page 20, tu écris "avec URL correspondant" : "correspondante"

* page 21, tu écris "class ProjectController ..." et des URL
commençant par "http://localhost:3000/projects/" : il te faut un
contrôleur ProjectsController et non pas ProjectController

* page 22, on est dans la section "Composant de Vue de Ruby On
Rails" : pourquoi ce composant est-il en Français alors que les
autres sont en Anglais (Model, Controller) ? Attention, dans cette
section, tu écris partout "Ruby On Rails" alors qu'ailleurs tu écris
"Ruby on Rails"

* page 23, tu écris "réutilisation des manipulations de vues" : je ne
comprends pas ce que ça signifie

* page 26, tu écris "Test sur les classes models" : "Tests sur les
modèles"

* page 26, tu écris "Réinjection automatique des données à chaque
test" : attention, dans ce cas, tu donnes au mot "test" le sens de
"session de tests", car les données ne sont chargées (sauf cas
exceptionnel) qu'une seule fois, au démarrage du lanceur de tests, et
un "rollback" est effectué après chaque test ; soit bien clair là- 
dessus à l'oral, sinon ils vont peut-être croire que tout le jeu de
test est rechargé pour chacun des tests

* page 27, tu écris "Test sur les controllers" : "Tests sur les
contrôleurs"

* page 27, tu écris "Assertion spécifique" : "Assertions spécifiques"

* page 29, tu écris "Aptana, plugin d'eclipse" : Aptana, en soit,
n'apporte aucun support de Ruby ou de Ruby on Rails ; pour Ruby, ce
sont les "Ruby Development Tools", et pour Ruby on Rails, c'est
"RadRails" qu'il faut installer ; ces deux plug-ins d'Eclipse peuvent
être installés sans Aptana

* page 29, dans la liste des environnements de développement, tu
cites Vim et Emacs, qui ne sont pas à proprement parlé des
environnements ; si tu souhaites lister les éditeurs de code, ajoute
TextMate, le préféré de la core team :-)


Une fois arrivé à la fin de ton support de présentation, on voit que
tu vas faire une démo ; est-ce là que tu vas parler du déploiement
sur serveur d'application ? Car ta présentation est intitulée "Ruby,
Ruby on Rails et le déploiement sur serveur d'application", mais tu
n'en parles pas (mise à part l'allusion au fichier war).

Tu écris tantôt Jruby, tantôt JRuby ; c'est "JRuby" (cf. http://
jruby.codehaus.org/).


Je vais me permettre une autre remarque, qui rejoint ce qu'a écrit
FX : pour une présentation de Ruby on Rails, j'éviterai les
migrations, les helpers et REST. Tu peux en parler, rapidement, ou de
manière plus approfondie si on te pose une question à ce sujet, mais
ce sont des sujets "périphériques", qui ne doivent pas impérativement
être intégrés lorsque l'on découvre le framework.
Tu lui réponds que tu t'adresses à un public d'informaticiens, qui
plus est de développeurs, mais savent-ils pour autant ce qu'est MVC ?
A moins de l'avoir pratiqué, il y a peu de chance qu'ils saisissent
le principe sans un schéma.
Dans la partie concernant les tests, tu parles d'assertions : savent-
ils ce que c'est ? Es-tu sûr qu'ils ont déjà écrit des tests ?

Dans une présentation, s'il y a trop de nouveautés, tu risques
d'effrayer le public ("oh, c'est trop compliqué, c'est trop différent
de ce que je fais aujourd'hui, je vais devoir tout réapprendre") ;
essaie au maximum de détailler ce qui est nouveau, en faisant le lien
si possible avec ce que les gens connaissent. Si tu connais ton
public, tu vas pouvoir encore plus facilement faire des comparaisons
avec ce qu'ils utilisent ("oh, finalement, c'est particulier, mais ça 
ressemble à telle et telle choses que je pratique déjà").


Voilà, j'ai essayé d'être le plus exhaustif possible :-) Si tu le
souhaites, tu peux regarder ce que j'avais présenté aux JDLL, à Lyon,
en 2007 [1]. J'espère que mes remarques t'aideront, que ta
présentation se passera bien, et que tu feras découvrir et apprécier
Ruby on Rails chez Cap Gemini !


[1] http://www.zlab.fr/files/JDLL%202007%20-%20Pr%E9sentation%20de%
20Ruby%20on%20Rails%20-%20Guillaume%20%22Zifro%22%20DESRAT.pdf (si le
lien passe mal, regarde dans http://zlab.fr/files/)

Le 17 avr. 08 à 21:04, Cyril Mougel a écrit :
> modifier en conséquence.
> tree/master
>
> Merci pour vos commentaires.
>
> -- 
> Cyril Mougel
> http://blog.shingara.fr
>
> >

Guillaume "Zifro" DESRAT
Président de l'association Ruby France
http://www.rubyfrance.org/

> * page 3, tu écris "tout est objet" : c'est un abus de langage,
> précise-le, au moins à l'oral


En quoi est-ce un abus de language  ? Je croyais que tout était 
réellement
objet ...

* page 11, tu écris "Utilisation du pattern ActiveRecord": ce n'est
> pas un pattern, mais une bibliothèque


A la base Active Record est bien un pattern décrit par Martin Fowler
dans Patterns
of Enterprise Application Architecture. "Notre" Active Record est 
simplement
une implémentation de ce pattern, je pense que c'est ce que Cyril a 
prévu de
dire ...

Emmanuel

> * page 3, tu écris "tout est objet" : c'est un abus de langage,
> précise-le, au moins à l'oral
>
> En quoi est-ce un abus de language  ? Je croyais que tout était  
> réellement objet ...

Non, tout n'est pas objet en Ruby. Les structures de contrôles, les
blocs passés en paramètres aux méthodes, et quelques autres choses
également, ne sont pas des objets.
Des langages tout-objet existe, Smalltalk par exemple (et ça fait
bizarre).

> * page 11, tu écris "Utilisation du pattern ActiveRecord": ce n'est
> pas un pattern, mais une bibliothèque
>
> A la base Active Record est bien un pattern décrit par Martin  
> Fowler dans Patterns of Enterprise Application Architecture.  
> "Notre" Active Record est simplement une implémentation de ce  
> pattern, je pense que c'est ce que Cyril a prévu de dire ...

Au temps pour moi.

Guillaume "Zifro" DESRAT
Président de l'association Ruby France
http://www.rubyfrance.org/

Le 20/04/08, Guillaume DESRAT a écrit :

>  * page 3, tu écris "tout est objet" : c'est un abus de langage,
>  précise-le, au moins à l'oral

oh, j'ai convaincu Guillaume :-)

>  * page 11, tu écris "Utilisation du pattern ActiveRecord": ce n'est
>  pas un pattern, mais une bibliothèque

Il doit sûrement parler du pattern de Martin Fowler, dans
Patterns of Enterprise Application Architecture (P of EAA).

Voir : http://www.martinfowler.com/eaaCatalog/activeRecord.html

>  * page 12, tu écris "au lieu de requêtes SQL pur" : mets
> "requêtes SQL pures" ou "requêtes en SQL pur" (ma préférence
> va à la première forme)

La 2e ne me choque pas.

>  * page 13, tu affiches un fichier de migration : te serait-il
>  possible de l'afficher avec une coloration syntaxique, pour
> plus de lisibilité des mots-clés du langage, des paramètres,
> etc... ?

pas de points de suspension après etc. c'est redondant :P

>  * page 14, tu écris "La classe Mapping" : quand j'ai lu ça, je me
>  suis dit "tiens, c'est quoi cette classe ?" ; tu pourrais appeler ça
>  l'utilisation d'ActiveRecord ; tu écris plus loin "Code de la classe
>  de Mapping" : là aussi le "M" majuscule est trompeur
>
>  * page 14, dans ton code, on lit "all_Project - Project.find :all"...
>  je préfère "all_projects = Project.find :all"

voire Project.all si on utilise Edge.

>  * page 15, tu écris "les méthodes static" et "les méthodes
>  accessibles en static" : attention, static est la terminologie
> en JAVA et C++,

C'est vrai, ça doit être pour ça que je déteste ce terme de
"méthode statique" :)

> mais le terme est "méthodes de classe" ; si tu as devant
>  toi des développeurs JAVA ou C++, ils comprendront,
> mais les autres se demanderont pourquoi tu as utilisé
> ce terme

Ce sera sûrement à mon avis des devs Java ou C++

>  * page 16, tu écris "multiples systèmes de validation" : la
>  formulation est mal choisie à mon avis, car les développeurs
> risquent de penser qu'il y a plusieurs systèmes, au sens
> plug-ins par exemple, de gestion des validations ; dis plutôt
> qu'on peut intervenir très finement dans le cycle de vie de
> l'objet

Pas de commentaires, je n'ai pas les slides sous les yeux.

>  * page 20, tu écris "avec URL correspondant" :
> "correspondante"

euh... ah ? soit.

>  * page 21, tu écris "class ProjectController ..." et des URL
>  commençant par "http://localhost:3000/projects/" : il te faut un
>  contrôleur ProjectsController et non pas ProjectController

+1

>  * page 22, on est dans la section "Composant de Vue de Ruby On
>  Rails" : pourquoi ce composant est-il en Français

"en français" :P

> alors que les autres sont en Anglais (Model, Controller) ?

"en anglais"

> Attention, dans cette section, tu écris partout "Ruby On Rails"
> alors qu'ailleurs tu écris "Ruby on Rails"

Et ça s'écrit Ruby on Rails et non Ruby On Rails ni RubyOnRails.

Voir http://www.rubyonrails.org

>  * page 23, tu écris "réutilisation des manipulations de vues" :
> je ne comprends pas ce que ça signifie

Il parle des partiels ? (ou partielles)

>  * page 26, tu écris "Test sur les classes models" : "Tests sur
> les modèles"
>
>  * page 26, tu écris "Réinjection automatique des données à
>  chaque test" : attention, dans ce cas, tu donnes au mot "test"
> le sens de "session de tests",

ouais ça dépend du sens qu'on donne au mot test, on peut
utiliser test et méthode de test. Un test a plusieurs méthodes
de test.

>  * page 29, tu écris "Aptana, plugin d'eclipse" : Aptana, en soit,
>  n'apporte aucun support de Ruby ou de Ruby on Rails ; pour Ruby,
>  ce sont les "Ruby Development Tools", et pour Ruby on Rails, c'est
>  "RadRails" qu'il faut installer ; ces deux plug-ins d'Eclipse peuvent
>  être installés sans Aptana

Bah alors c'est nul Aptana ! :)

>  * page 29, dans la liste des environnements de développement,
> tu cites Vim et Emacs, qui ne sont pas à proprement parlé des
>  environnements ;

mouais discutable.  'environnements de développement'
peut ne peut pas être synonyme d'IDE.

> si tu souhaites lister les éditeurs de code,
> ajoute TextMate, le préféré de la core team :-)

Et pas que d'eux.

http://www.tbray.org/ongoing/When/200x/2007/11/20/Ruby-IDE-Survey
http://www.tbray.org/ongoing/When/200x/2007/11/26/Ruby-Tool-Survey

>  Une fois arrivé à la fin de ton support de présentation, on voit
> que tu vas faire une démo ; est-ce là que tu vas parler du
> déploiement sur serveur d'application ? Car ta présentation est
> intitulée "Ruby, Ruby on Rails et le déploiement sur serveur
> d'application", mais tu n'en parles pas (mise à part l'allusion
> au fichier war).

Allez, une petite couche sur GlassFish.

>  Tu écris tantôt Jruby, tantôt JRuby ; c'est "JRuby" (cf. http://
>  jruby.codehaus.org/).

+1

>  Je vais me permettre une autre remarque, qui rejoint ce qu'a écrit
>  FX : pour une présentation de Ruby on Rails, j'éviterai les
>  migrations, les helpers et REST.

Discutable.

Rails est peut-être (je suis pas sûr) le premier framework à 
intégrer un système de migrations, qui a été copié depuis.
C'est une caractéristique forte. On peut évoquer les helpers
pour donner un exemple du confort apporté au développeur.
Pour REST, comme Rails est 'opiniated' et penche pour REST
plutôt que WebServices, ça peut être judicieux de le signaler
(+ impact sur le design du code).

> Tu peux en parler, rapidement, ou de manière plus approfondie
> si on te pose une question à ce sujet, mais ce sont des sujets
> "périphériques",

Mouais. Discutable.

> qui ne doivent pas impérativement être intégrés lorsque l'on
> découvre le framework.
>  Tu lui réponds que tu t'adresses à un public d'informaticiens,
> qui plus est de développeurs, mais savent-ils pour autant ce
> qu'est MVC ?

J'imagine que les devs ont bouffé du Struts ou du Spring, donc
ils sont familiers avec MVC.

>  A moins de l'avoir pratiqué, il y a peu de chance qu'ils
> saisissent le principe sans un schéma.

ça ne coûte rien d'en rajouter, effectivement.

>  Dans la partie concernant les tests, tu parles d'assertions :
> savent-ils ce que c'est ?
> Es-tu sûr qu'ils ont déjà écrit des tests ?

Tu crois qu'il va s'adresser à un public de devs PHP ? :-)

>  Dans une présentation, s'il y a trop de nouveautés, tu
> risques d'effrayer le public ("oh, c'est trop compliqué, c'est
> trop différent de ce que je fais aujourd'hui, je vais devoir tout
> réapprendre") ;

C'est vrai que lorsqu'on passe à un nouveau langage, il faut
désapprendre, comme dirait Yoda :)

>  essaie au maximum de détailler ce qui est nouveau, en
> faisant le lien si possible avec ce que les gens connaissent.
> Si tu connais ton public, tu vas pouvoir encore plus facilement
> faire des comparaisons avec ce qu'ils utilisent ("oh, finalement,
> c'est particulier, mais ça ressemble à telle et telle choses que
> je pratique déjà").

Il faut peut-être réfléchir aux choses qui peuvent déconcerter :
langage interprété, pas de compilateur, duck typing, classes
ouvertes. Venant de Java, ça peut troubler.

>  Voilà, j'ai essayé d'être le plus exhaustif possible :-) Si tu le
>  souhaites, tu peux regarder ce que j'avais présenté aux JDLL,
> à Lyon, en 2007 [1]. J'espère que mes remarques t'aideront,
> que ta présentation se passera bien, et que tu feras découvrir
> et apprécier Ruby on Rails chez Cap Gemini !

C'est bizarre, en lisant ce dernier paragraphe, je vois pleins
de bisounours !

   -- Jean-François.

--
RailsCamp Paris le samedi 17 mai 2008 :
http://rubyfrance.org/evenements/railscamp-paris

Guillaume DESRAT a écrit :
> également, ne sont pas des objets.
> Des langages tout-objet existe, Smalltalk par exemple (et ça fait 
> bizarre).
les blocs ne sont pas des objets / méthodes géré par la classe proc ?
http://www.ruby-doc.org/core/classes/Proc.html

FX

Le 20/04/08, FX<fxguillois@gmail.com> a écrit :
>  >
>  FX
>
>
>
>  >
>


--
Vice-président de l'association Ruby France.
RailsCamp Paris le samedi 17 mai 2008 :
http://rubyfrance.org/evenements/railscamp-paris

[ooups fausse manip... ]

Le 20/04/08, FX<fxguillois@gmail.com> a écrit :

> les blocs ne sont pas des objets / méthodes géré par la classe
> proc ?
>  http://www.ruby-doc.org/core/classes/Proc.html

Non, les blocs de code (blocks) ne sont pas des objets donc
encore moins des objets Proc (*), mais peuvent être convertis en
objet Proc, dans ce cas, tu les lies avec un certain contexte
(le contexte courant). Pareil pour les méthodes, ce ne sont
pas des objets, mais tu peux les "objectifier" (objet Method) à 
partir d'un receveur (une fois créé tu peux le dé-lier (unbind)
de cet objet).

  -- Jean-François.

* : Laurent Julliard a mis cette erreur à chaque fois dans
ses slides de Paris on Rails 2006 et 2007.

--
RailsCamp Paris le samedi 17 mai 2008 :
http://rubyfrance.org/evenements/railscamp-paris

2008/4/20 Guillaume DESRAT <guillaume.desrat@rubyfrance.org>:
>
>  Salut tout le monde,
>
>  comme promis, Cyril, voici mes commentaires :
>
>  * page 3, tu écris "tout est objet" : c'est un abus de langage,
>  précise-le, au moins à l'oral

Je le préciserais a l'oral, mais je le pensais en faite :)

>
>  * page 11, tu écris "Utilisation du pattern ActiveRecord": ce n'est
>  pas un pattern, mais une bibliothèque

Comme les autres te l'ont fait remarquer, je pensais bien au pattern de 
Fowler.

>
>  * page 12, tu écris "au lieu de requêtes SQL pur" : mets "requêtes
>  SQL pures" ou "requêtes en SQL pur" (ma préférence va à la première
>  forme)

J'ai change pour la première version.

>
>  * page 13, tu affiches un fichier de migration : te serait-il
>  possible de l'afficher avec une coloration syntaxique, pour plus de
>  lisibilité des mots-clés du langage, des paramètres, etc... ?

Je vais essayer de trouve, mais j'ai l'impression que ça sera
difficile avec mon plugin LaTex. Si je trouve, je l'ajoute.

>
>  * page 14, tu écris "La classe Mapping" : quand j'ai lu ça, je me
>  suis dit "tiens, c'est quoi cette classe ?" ; tu pourrais appeler ça
>  l'utilisation d'ActiveRecord ; tu écris plus loin "Code de la classe
>  de Mapping" : là aussi le "M" majuscule est trompeur

J'ai modifier le titre en : Utilisation d'ActiveRecord
et supprimer la majuscule dans le Mapping. Je n'avais effectivement
pas penser a la correspondance avec un nom de classe.

>
>  * page 14, dans ton code, on lit "all_Project - Project.find :all"...
>  je préfère "all_projects = Project.find :all"

Effectivement. Pour JF, je ne vais pas mettre de commande edge. Mais
merci pour l'info sur cette commande. je ne suis pas assez les
évolutions de edges :(

>
>  * page 15, tu écris "les méthodes static" et "les méthodes
>  accessibles en static" : attention, static est la terminologie en
>  JAVA et C++, mais le terme est "méthodes de classe" ; si tu as devant
>  toi des développeurs JAVA ou C++, ils comprendront, mais les autres
>  se demanderont pourquoi tu as utilisé ce terme

Mon public sera des dev Java principalement. Le termes static sera
connu d'eux. Je modifie donc en :

les méthodes de classe (correspondant au static de Java)

>
>  * page 16, tu écris "multiples systèmes de validation" : la
>  formulation est mal choisie à mon avis, car les développeurs risquent
>  de penser qu'il y a plusieurs systèmes, au sens plug-ins par exemple,
>  de gestion des validations ; dis plutôt qu'on peut intervenir très
>  finement dans le cycle de vie de l'objet

J'ai modifie en : Multiples systèmes de gestion directement dans le
cycle de Vie de l'objet modele pour empêcher l'enregistrement en base
de données d'informations erronées


>
>  * page 20, tu écris "avec URL correspondant" : "correspondante"

Effectivement, une URL :)

>
>  * page 21, tu écris "class ProjectController ..." et des URL
>  commençant par "http://localhost:3000/projects/" : il te faut un
>  contrôleur ProjectsController et non pas ProjectController

Modifie

>
>  * page 22, on est dans la section "Composant de Vue de Ruby On
>  Rails" : pourquoi ce composant est-il en Français alors que les
>  autres sont en Anglais (Model, Controller) ? Attention, dans cette
>  section, tu écris partout "Ruby On Rails" alors qu'ailleurs tu écris
>  "Ruby on Rails"

modifie en : Composant Viez de Ruby on Rails

>
>  * page 23, tu écris "réutilisation des manipulations de vues" : je ne
>  comprends pas ce que ça signifie

Comme l'a dit JF, je pensais effectivement au "partial"

>
>  * page 26, tu écris "Test sur les classes models" : "Tests sur les
>  modèles"

Change

>
>  * page 26, tu écris "Réinjection automatique des données à chaque
>  test" : attention, dans ce cas, tu donnes au mot "test" le sens de
>  "session de tests", car les données ne sont chargées (sauf cas
>  exceptionnel) qu'une seule fois, au démarrage du lanceur de tests, et
>  un "rollback" est effectué après chaque test ; soit bien clair là-
>  dessus à l'oral, sinon ils vont peut-être croire que tout le jeu de
>  test est rechargé pour chacun des tests

J'avais mal compris le systeme du RollBack. Merci de ta precision.
J'ai donc modifier la ligne entre :

Chaque test dans une transaction et ROLLBACK a la fin de chaque test.

>
>  * page 27, tu écris "Test sur les controllers" : "Tests sur les
>  contrôleurs"

Modifie

>
>  * page 27, tu écris "Assertion spécifique" : "Assertions spécifiques"

Modife

>
>  * page 29, tu écris "Aptana, plugin d'eclipse" : Aptana, en soit,
>  n'apporte aucun support de Ruby ou de Ruby on Rails ; pour Ruby, ce
>  sont les "Ruby Development Tools", et pour Ruby on Rails, c'est
>  "RadRails" qu'il faut installer ; ces deux plug-ins d'Eclipse peuvent
>  être installés sans Aptana

Effectivement, je change Aptana en RadRails.

>
>  * page 29, dans la liste des environnements de développement, tu
>  cites Vim et Emacs, qui ne sont pas à proprement parlé des
>  environnements ; si tu souhaites lister les éditeurs de code, ajoute
>  TextMate, le préféré de la core team :-)

Rajoute avant Vim/Emacs, même si j'utilise personnellement Vim

>
>
>  Une fois arrivé à la fin de ton support de présentation, on voit que
>  tu vas faire une démo ; est-ce là que tu vas parler du déploiement
>  sur serveur d'application ? Car ta présentation est intitulée "Ruby,
>  Ruby on Rails et le déploiement sur serveur d'application", mais tu
>  n'en parles pas (mise à part l'allusion au fichier war).

Je vais supprimer le titre en supprimant la partie sur le déploiement
sur serveur d'application. Au moment de demo, je ferais une
présentation d'une application de gestion de taches pour un projet. Un
peu le blog en 20 minutes, mais pour une applications un peu plus
proches du métiers de CapGemini.

>
>  Tu écris tantôt Jruby, tantôt JRuby ; c'est "JRuby" (cf. http://
>  jruby.codehaus.org/).

Modifie

>  A moins de l'avoir pratiqué, il y a peu de chance qu'ils saisissent
>  le principe sans un schéma.
>  Dans la partie concernant les tests, tu parles d'assertions : savent-
>  ils ce que c'est ? Es-tu sûr qu'ils ont déjà écrit des tests ?

l'écriture de test est normalement une obligation dans notre
entreprises (Je connais les Utopies). Pour le Pattern MVC,
l'utilisation des 5 couches Java est rabâche sans cesse. Donc les 3
vrais couches devraient largement être connu. Pour les Helpers, je
vais modifier un peu en indiquant que ce sont les Taglib de Ruby on
Rails le parallèle permettra de facilement comprendre leur
utilisation. Ensuite quand on connait la difficulté de créer une
taglib. Ça peux aider.

Pour le REST, je trouve que cela est assez important dans la gestion
et l'utilisation de Rails.

Pour les migrations, ca permet de montrer aussi l'idée d'un seul
langage (Ruby) pour tout réaliser, même les migrations.

>
>  Dans une présentation, s'il y a trop de nouveautés, tu risques
>  d'effrayer le public ("oh, c'est trop compliqué, c'est trop différent
>  de ce que je fais aujourd'hui, je vais devoir tout réapprendre") ;
>  essaie au maximum de détailler ce qui est nouveau, en faisant le lien
>  si possible avec ce que les gens connaissent. Si tu connais ton
>  public, tu vas pouvoir encore plus facilement faire des comparaisons
>  avec ce qu'ils utilisent ("oh, finalement, c'est particulier, mais ça
>  ressemble à telle et telle choses que je pratique déjà").

Je tenterais de faire un peu plus de parallèle avec Struts et
hibernate durant la présentation, car ces deux librairies sont 
trèsutilise chez moi.

>
>
>  Voilà, j'ai essayé d'être le plus exhaustif possible :-) Si tu le
>  souhaites, tu peux regarder ce que j'avais présenté aux JDLL, à Lyon,
>  en 2007 [1]. J'espère que mes remarques t'aideront, que ta
>  présentation se passera bien, et que tu feras découvrir et apprécier
>  Ruby on Rails chez Cap Gemini !

Merci beaucoup pour tous tes commentaires, ça m'est très utile. J'ai
mise a jour ma presentation.


--
Cyril Mougel
http://blog.shingara.fr

Comme les autres l'ont souligné, ta présentation est déjà bien
complète. Trop peut-être. Le problème que j'ai eu lorsque j'ai fait ce
genre d'exercice c'est qu'il y a tellement de choses à raconter que 
çapeut devenir long pour les auditeurs.
Je me demande même si, suivant le public, une démo commentée ne serait
pas plus appropriée.

Par exemple, j'aime bien rappeler quelques principes de base de Ruby
dont Rails se sert tout le temps (method_missing, syntaxe permettant
l'écriture de DSL, etc).

++

yk

Le 17/04/08, Cyril Mougel<cyril.mougel@gmail.com> a écrit :

Comme précisé dans une conf de Greg Pollack, le pattern c'est *Active 
Record
*, et la lib ici qui implémente le pattern c'est *ActiveRecord*...

on a les précisions que l'on peut :)

2008/4/20 Emmanuel Bouton <goten4@gmail.com>:

2008/4/22 Yann KLIS <yann.klis@gmail.com>:
>
>  Comme les autres l'ont souligné, ta présentation est déjà bien
>  complète. Trop peut-être. Le problème que j'ai eu lorsque j'ai fait ce
>  genre d'exercice c'est qu'il y a tellement de choses à raconter que ça
>  peut devenir long pour les auditeurs.
>  Je me demande même si, suivant le public, une démo commentée ne serait
>  pas plus appropriée.

La démo commenté est prévue en deuxième partie de soirée :)

En effet, j'ai en gros 2h de présentation. Je compte faire 1h de
présentation avec le support  que je vous ai fourni et faire une
démonstration d'une application durant la deuxième heure. J'ai
commencé sur ce deuxième point à m'entraîner et surtout à évaluer ce
qu'il est possible de réaliser et comment en 1 heure.

J'ai ainsi réalisé un screencast[1] d'1h20 en français sur un exemple
de création d'application Rails. J'avais déjà prévue plus de chose et
j'ai donc choisi d'encore réduire. Je ferais donc un nouveau
screencast plus court plus tard.

[1] : 
http://blog.shingara.fr/articles/2008/04/22/screencast-francais-sur-la-realisation-dune-application-rails

--
Cyril Mougel
http://blog.shingara.fr

sur le slide 7:

Philosophie Ruby :
convention plutôt que configuration,

Ce ne serait pas plutôt la philosophie Ruby on Rails plutôt que Ruby ça?

2008/4/22 Patrick Aljord <patcito@gmail.com>:
> sur le slide 7:
>
> Philosophie Ruby :
> convention plutôt que configuration,
>
> Ce ne serait pas plutôt la philosophie Ruby on Rails plutôt que Ruby ça?

Tout à fait. cette slide a comme titre Concept de Ruby on Rails.

--
Cyril Mougel
http://blog.shingara.fr