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 F., dans
Patterns of Enterprise Application Architecture (P of EAA).
Voir : P of EAA: Active Record
- 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 
-
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”
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
Après on peut
Après on peut