Paris on Rails, vendredi 17 novembre 2006.
3e présentation.
== Introduction à Ruby on Rails - Eric D.
- Qui êtes-vous ?
(qui dans l’assemblée programme en PHP, Ruby, Java, etc. ?)
- Qui suis-je ? Consultant PHP depuis 10 ans.
Actuellement chez SQLI.
- Rails framework :
- cadre de travail
- solution technique
- outils à disposition
- dédié au Web
C’est un guide très fort (utilisation de conventions)
C’est écrit en Ruby, c’est le point le plus intéressant.
(Il y a d’autres copies de Rails en PHP, en Java… pour la technique
ça suit à peu près, niveau feeling c’est zéro)
-
Visuel : Déploiement de Rails avec RadRails. (démonstration RadRails)
- création d’une structure d’appli Rails
- rédiger la configuration (le fichier database.yml) : à peu
près 10 lignes (à comparer à une config Java)
-
Rails : du MVC
M - objets manipulés
V - code d’affichage (généralement HTML)
C - Contrôleur : ce que vous en faîtes (NdU: ce que vous en faites)
Exemple d’application : DVDthèque.
Première version de l’appli de gestion de DVDs : 20 lignes
(en comptant le HTML)
(NdU : code incomplet ci-dessous)
date_publication_year = Time.now.year
@liste_dvds = Dvd.find :all, :order => ‘date_publication’
(Utilisation de phpMyAdmin pour créer la table, convention
pour la clé primaire : id)
En PHP : la même chose, ce sera aussi 20 lignes mais pas en MVC
Java : allez, environ 100 lignes.
- C’est simple. C’est structuré.
- ActiveRecord (= LA BRIQUE de Rails)
- décrit la liaison Objet-Relationnel
- dynamique
- basé sur des conventions.
ActiveRecord, c’est l’ORM que j’ai cherché à faire pendant 5 ans en PHP
et finalement mon ORM de rêve est en Ruby.
Utilisation de conventions : on gagne de la vitesse.
- Création d’une entité ActiveRecord
accès, création, modification, suppression
Contrôleur : destroy_by_titre
(NdU: il avait un souci de convention perso titre/title,
ce qui m’a embrouillé au niveau des notes, c’était peut-être
destroy_by_title, etc.)
for dvd in liste
dvd.destroy
end
→ code lisible
def update_times
Dvd.find(params[:id])
dvd.date_publication = Time.now
dvd.save
end
def create_new
dvd = Dvd.new
dvd.titre = ‘bambi’
end
- ActiveRecord plus loin
- sait gérer les relations, jointures, les contraintes.
Exemple : Categorie has_many :dvds
Dvd belongs_to :categorie
da = Categorie.find_or_create_by_name(‘dessin animé’)
bambi = Dvd.find_by_titre(“bambi”)
bambi.categorie = da
bambi.save
ou da << Dvd.find_by_titre …
Categorie.find_by_name(“dessin_anime”).dvds.create…
dvds = Categorie.find_by_name(“dessin animé”)
for dvd in dvds
dvd.title
end
class Dvd < ActiveRecord::Base
validates_presence_of :titre
validates_length_of :titre, :maximum => 33
end
dvd.valid?
dvd.errors_on :titre
dvd.errors.each do |msg|
…
end
L’affichage des erreurs HTML : ça prend du temps à coder en PHP,
c’est pénible…
(il montre la page d’erreur Rails classique avec l’encadré rouge)
C’est pas joli mais c’est modifiable.
-
ActiveRecord : Simple, Automatique, Efficace
vous pouvez tout faire, c’est simple et aussi vous pouvez faire
ce que vous ne faisiez pas avant (par exemple créer une
méthode: find_by_titre) -
Et le reste ?
10.years.ago
50.megabytes
7.is_multiple_of? 3
Dvd.find_by_nom()
Comment on fait ça en C, Java, PHP ?
lisibilité et confort.
simple à relire ← important
dvd.date_publication = 3.years.ago
dvd.size = 5.6.gigabyte
age = Time.now.year - dvd.date_publication.year
if (age).is_multiple_of? 10
print “heureux anniversaire”
end
(NdU: je sais pas pourquoi il a mis age entre parenthèses)
-
Le reste ? automatique !
- formulaires générées
- validations automatisées
- génération du CRUD
- Services Web plus ou moins natifs
- très dynamique
- pas de config → ou très peu
conventions de nommage
-
Reste ? Efficace ?
-
console complète : pas nécessaire de faire une interface spécifique
si on a besoin de modifier qq chose dans la base (possibilité de
faire des modifs à la volée) -
Breakpoint
-
IDE dédié RadRails
raccourcis pour passer du modèle au contrôleur, à la vue -
Tests unitaires
les tests : évident pour le chef de projet, pas forcément pour
l’équipe de dévs. -
déploiement : Capistrano.
-
code concis
-
outils intégrés : ZenTest par ex.
-
-
Et le reste ? Extensible ?
Faire évoluer son appli ?
- plugins mis en avant par DHH (développement d’opinion)
- basé sur Ruby
- simple à personnaliser
- accès aux sources : logiciel libre
- aucune limite
- plugins intégrés
réouverture de classes : pas joli, mais possible.
(NdU: mmmh, la réouverture de classes, c’est le sport
favori du rubyiste 
)
-
Moderne ?
- Ajax intégré
- JavaScript généré
- Effets visuels
- Philosophie REST
- méthodes agiles
-
Les autres outils
simples, complets, extensibles, modernes.
- plus simples d’accès
- moins d’erreurs (erreurs : plus des erreurs fonctionnelles)
- plus de réactivité
- maintenance courte
- plus de confort
- peu de limitations
développement pas forcément plus rapide, mais plus adaptable.
-
Plus productif ?
Oui mais pas sur le développement initial
Mais on gagne :- en qualité
- en maintenance (code plus simple, plus lisible)
- en évolution
- en réactivité
- en confort (moins de prise de tête )
(NdU: mais il peut y en avoir quand même :))
-
Limites actuelles (2006)
- qui s’améliorent
- documentation
- performances : 20% inférieur à PHP
- encore peu utilisé (moins d’“effet parapluie” pour les DSI)
- structurelles
- peu de limites : c’est un plus et un moins
un moins car ça donne plus de liberté à un mauvais développeur
(par opposition à Java qui est “idiot-proof” ) - évolution constante : pbs lors des mises à jour.
- reprise d’existant
- peu de limites : c’est un plus et un moins
- qui s’améliorent
→ au final, autant de temps
mais à la fin on a du code moins complexe.
logiciel d’opinion : pour les applis existants, situation
plus compliqué (exemple : problème des clés composites)
- Graphique
tirée d’un slide d’une conf Sun.
(NdU: j’ai retrouvé l’URL, c’est chez Tim B. :
ongoing by Tim Bray · Comparing Frameworks )
PHP / Rails / Java
Java : outils phénoménaux
dev speed : temps de maintenance et temps d’évolution
pas d’accord, si on remplace scaling par performances, lÃ
je suis d’accord.
pas de JVM répliqués
- Visuel
code basique, comparaison :
Ruby
nom = dvd.categorie.nom
Java
String nom = dvd.getCategorie().getNom();
PHP
$nom = $dvd->getCategorie()->getNom();
→ en Ruby, globalement moins de caractères ésotériques.
-
A retenir
Simplicité, confort, maintenabilité, agile,
réactivité, facilité d’évolution
outillage complet, moderne… -
Questions
1/ Comparaison avec Symphony, framework PHP ?
R : Faut rentrer la config dans Symphony et Propel et le fichier
UML pour le schéma de la base.
Plus d’étapes dans le process ? (à comparer à la config du
database.yml et c’est fini ou presque)
utilisations de méthodes dynamiques : simplicité, gain de temps
Rails est lent, Symphony encore plus.
2/ Lenteur ? Dû à la compilation à la volée
R : J’y réponds de deux manières.
- C’est un faux problème.
avant PHP on disait : c’était lent
??
Scalable : on met plus de machines.
Quel choix préférez-vous ? Serveur à 10 000 EUR ou 6 mois de dév
pour embaucher un développeur qui fera du tuning ?
- Pour répondre. Ruby 2
avec machine virtuelle.
Ruby plus lent que PHP
Rails : beaucoup de choses en dynamique ?
3/ Différences par rapport à Camping ? (NdU: question facétieuse(?)
de Grégoire)
R : Je connais pas. (NdU: Eric veut pas rentrer dans le jeu)
(NdU : j’adore la description dans RubyGems :
“minature rails for stay-at-home moms” )
4/ ActiveRecord permet-il l’exécution en différé, le chargement différé
?
R : Rien en Rails.
5/ Limitation au niveau du multithreading.
Exemple une appli qui fait du Comet / Flash.
PHP ne le fait pas et fait 50% du marché.
Je n’ai pas eu le besoin d’avoir des threads en Rails.
6/ Comment Rails est utilisé chez SQLI ?
Bruno Penec (?, de SQLI ?): novateur, c’est de la veille, on avance
doucement, prudemment.
Marge pour faire avancer le projet au niveau de l’équipe
7/ Tests unitaires / Intégration continue
Eric : à propos des tests je suis convaincu en théorie mais dans la
pratique, j’en fais pas assez.
ZenTest, AutoTest
Fred (??? peut-être Christophe): On a 3 niveaux de tests : tests
unitaires, tests fonctionnels et tests d’intégration (ces
derniers : fantasmes des fanas de tests, le fait de pouvoir
écrire des scénarios).
JMeter en Java ?
Richard : L’outil CIA qui fait de l’intégration continue
(NdU : voir http://dev.rubyonrails.org/browser/tools/cia )
qui s’interface avec le gestionnaire de versionnement (car
on en utilise un, bien entendu)
8/ Plugins réutilisables ?
on peut factoriser des choses et les mettre dans des plugins.
Ou dans des gems (construire un gem, c’est simple).
Plugin installable via svn.
==> Fin de la matinée
Message de Richard : Ceux de #rubyonrails.fr qui veulent
se retrouver après la conf + présentation rapide de
l’association Ruby France (Grégoire et Guillaume)
Bouffe time.
-- Jean-François.
