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 J. 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 M.
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 :slight_smile:

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 :wink: Après on peut
l’expliquer pendant la conférence / réunion, mais c’est bien aussi si
les gens peuvent comprendre avant :wink:

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

FX

2008/4/19 FX [email protected]:

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 :wink: Après on peut
l’expliquer pendant la conférence / réunion, mais c’est bien aussi si
les gens peuvent comprendre avant :wink:

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 M.
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 :slight_smile:

FX

  • 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 F.
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/

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 :slight_smile:

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 :slight_smile: 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�sentation%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 M. a écrit :

modifier en conséquence.
tree/master

Merci pour vos commentaires.


Cyril M.
http://blog.shingara.fr

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 :slight_smile:

  • 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 F., 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 :stuck_out_tongue:

  • 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” :slight_smile:

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” :stuck_out_tongue:

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 ! :slight_smile:

  • 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 :slight_smile:

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 ? :slight_smile:

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 :slight_smile:

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 :slight_smile: 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

Le 20/04/08, FX[email protected] 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[email protected] 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 J. 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

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

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 M.[email protected] a écrit :

2008/4/20 Guillaume DESRAT [email protected]:

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 :slight_smile:

  • 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 :frowning:

  • 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 :slight_smile:

  • 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 :slight_smile:

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 :slight_smile: 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 M.
http://blog.shingara.fr

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 :slight_smile:

2008/4/20 Emmanuel B. [email protected]:

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 A. [email protected]:

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 M.
http://blog.shingara.fr

2008/4/22 Yann KLIS [email protected]:

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 :slight_smile:

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 M.
http://blog.shingara.fr

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs