Paris on Rails, vendredi 17 novembre 2006.
2e présentation.
10h34
[Slides dispo déjà depuis samedi : http://pierlis.com ]
== shopping.nouvelobs.com Enseignements d’une prestation
en Rails - Pierre-Loïc Raynaud (Pierlis)
(enrhumé)
Réalisation d’un site de commerce en ligne :
shopping.nouvelobs.com
SSII de 5 personnes spécialisé dans les langages exotiques :
Ruby serveur et Objective C/Cocoa côté client.
- Site NouvelObs
on connaissait à peine le langage quand on l’a vendu- activité offline puis online
- refonte du site
- charte graphique fournie par le client
- aspect conseil pour la gestion du site et les outils
de backoffice
catalogue du NouvelObs : spécial…entre l’Homme Moderne et
l’indéfinissable (!)
Entre 100 000 et 200 000 commandes par an.
prestataire ?
Problème : exemple les photos des produits étaient en GIF.
Comment vendre du Rails ?
on ne l’a pas dit au client ! (rires)
Rails c’est du PHP ? Euh ouais, c’est Open Source, ya du MySQL
dedans…
ils (nos clients) sont venus aujourd’hui (?).
Pour un site Web, on n’est pas obligés de mettre de l’Ajax,
de l’autocomplete ni du drag/drop
Pourquoi cet exemple ?
besoin représentatif
premier projet réalisation commerciale
- couverture fonctionnelle large
- front
- back
- intégration gros système
- intégration paiement en ligne
4 mois de recul ! (mis en production en juillet)
(je voudrais qu’on se mettre d’accord sur le prix de la journée
de prestation)
gros systèmes se brancher la dessus
- Pourquoi Rails ?
- beauté et puissance de Ruby
- qualité du framework
- client technologiquement agnostique
- ennuyé par PHP, fatigué de Java
- accès au code source
- volonté de constituer une première référence
- test en vrai grandeur, dans une prestation au forfait
comparaison Ruby/Java, très intéressante à lire
lien : IBM Developer
Hebdogiciel/Basic (NdU : comprends pas pourquoi j’ai écrit ça, il a
dû dire qu’il a appris à programmer en lisant Hebdogiciel ?)
vous êtes un peu “edgy” (NdU: early adopters ?)
RETOURS D’EXPÉRIENCE
- Graphique (même que celui de Railsconf Europe, voir les slides)
productivité avec un langage connu et maîtrisé
4/5e du temps : on n’a pas fait la moitié de ce qu’il fallait
on nous avait dit que c’est rapide, peu de LOC
vous êtes à l’aise : Principe de Moindre Surprise travail d’accoutumance
-
2e graphique
zone d’anxiété / travail effectué
“Et si on mettait une équipe PHP en parallèle ?” -
Effet Ruby + Rails
zone d’anxieté → zone de confort
vous avez fini avant : vous ne le dites pas au client ! (rires)
expérience qu’a a eu nous
- Vitesse de dév
temps de dev Rails versus PHP
- 2 ingénieurs expérimentés : C++, Java, PHP, Objective C + frameworks
- Ruby et Rails demande une bonne connnaissance de la Programmation
Orientée
Objet + expérience avec framework
pour en tirer tout le profit - dans ces conditions , nous sommes allés plus vite à périmètre
fonctionnel égal
- Structuration des projets
- apport de Rails dans la phase de dev
- structuration du projet
- méthodologie
- respect du MVC
- travail en équipe
- reprise du code facilitée
- scaffolding
- structuration du projet
génération de code : au début ça fait peur.
principe Rails : convention over configuration
avantage : en équipe, plus simple de naviguer
reprise de code : chacun n’a pas mis au point sa propre
structuration de code
dégagement de prestataire → on fait des changements dans l’organisation
des fichiers pour éviter ça (rires)
site Rails : vidéo → blog
scaffold : sert pas à grand chose
- Apports de Rails pour le développement
MVC
M : ActiveRecord : ORM, relations, validations
→ attaquer des tables avec une sémantique objet
V : ActionView : rhtml, rxml, ajax, helper , partials
→ associé au Web2.0 (pas compris ce qu’était le Web2.0) +
lib JS bien intégré au framework (presque un plaisir (mais c’est
quand même du JS))
C : ActionController : routage, clean url tout ce qui est ni modèle,
ni view, gestion d’url
- dév peut passer plus de temps sur le code orienté client, car
on a moins de code “orienté support” à écrire
-
Autres apports de Rails
- grâce à des outils couvrant presque tout le cycle de vie d’une
application - développement ruby, rails, irb
- déploiement : rake capistrano
- test : rake test
- débugging : console, breakpointer (point d’arret)
- documentation : rdoc
évolution du modele de données : rake migrate (chacun sait le faire
mais
chacun le fait à sa façon) - réutilisation & partage de code : plugins
- grâce à des outils couvrant presque tout le cycle de vie d’une
-
Sur la maintenance
Exemple, le client veut rajouter un système de promotions :
script/generate migration AjouterPrixPromotionnel
Migration
class AjouterPrixPromotionnel < AR::M
def self.up
add_column ‘produits’, ‘prix_promo’, :float
Product.find(:all, :conditions => [ ‘Prix > 100’ ]).each { |prod|
prod.prix_promo = prod.prix * 0.9
prod.save
}
end
def self.down
remove_column ‘produits’, ‘prix_promo’
end
end
-
Débugging
- irb vs console
- breakpointer
- placer des points d’arrêt
examiner variables, stack trace - appli non triviales : prend tout sens
- placer des points d’arrêt
-
Déploiement
- schemas de déploiement
-
Sur le déploiement
- outils standards pour faciliter les phases d’un déploiement
(Capistrano) - faire évoluer un modèle de données
- livraison des nouvelles version de l’appli
- relancer le service sur l’appli mise à jour
- possibilité de revenir en arrière
- en config multi-host
- permet de normer les procédures
→ agilité
pour les hébergeurs aussi
- outils standards pour faciliter les phases d’un déploiement
-
Réutilisation
-
bon framework enrichi par ses utilisateurs
pour ses besoins propres
pour tout le monde -
Enrichissement Pierlis
ModelSearch (NdU: PLR est passé sur ce sujet mais il a plus détaillé Ã
RailsConf Europe, voir les slides de la conf sur pierlis.com .)
Memoize
additions sur les classes standard
- Problèmes :
- peu de compétences disponible ?
- où sont les hébergeurs spécialisés ?
- gourmand en hardware ?
ça “rame” un peu
il faut bien optimiser votre code, machine un peu plus
puissante que l’équivalent d’une appli dans un autre langage - documentation immature?
doc de plus en plus
(ya Telecom Italia)
partenariat avec PlanetService
travailler avec les bons hébergeurs (“Rails, ça fait pas partie
de votre appli ?”)
- A qui profite Ruby on Rails
- moins de j.h mais j.h plus coûteux : pas vraiment
d’avantage côté prix - notre parti pris
- livrer des applis plus polies
- factoriser du code entre les applis que nous livrons
- interopération des specs à la recherche d’une
meilleure satisfaction clients
plus le code est testé, moins il est buggé, plus les
clients en profite
avantage client et prestataire
- Exemples
- interprétation des spec
- gestion du merchandising
comment ranger les rayons
rayons (n) ↔ produits (n)
(on voit une interface)
2 dropdowns en form
pas spécifiques à Rails - drag n drop
exemple : recadrage d’une photo (fontaine au chocolat (??))
→ croping, magie, CSS JavaScript, RMagick
- Conclusion
profitez de la jeunesse de Rails
Soyez curieux
risque ~ opportunité
si le développeur meurt ?
- qualité s’apprécie dans le temps
grande vague de fraîcheur pour les dév
(on fait de la formation)
qualité du code produit
nouvelles fonctionnalité => maintenabilité
@ror_users += ParisOnRails.participants
-
Questions : il n’y en avait pas, si je me souviens bien
le journaliste qui surveillait le bon déroulement de la conf
a proposé de renvoyer les questions à la séance de
questions-réponses à la fin de la journée.– Jean-François.
