Après ce premier billet de cette série de tutoriaux, voici l'heure du premier bilan.

Commençons par un bilan "comptable" :

Le premier article à été assez bien accueilli puisque la fréquentation de blog à frôlé les 100 visiteurs uniques vendredi dernier grâce notamment à une petite auto promotion sur railsfrance et blogasty (sans les visites par le flux RSS que je ne suis pas en mesure de calculer puisque je ne suis toujours pas inscrit à un service comme feedburner, maintenant ce sera fait on verra le résultat ces prochains jours ;) )

Toutefois, ces articles me prennent un temps fou à écrire et j'avoue que je m'attendais à un peu plus de retour en matière de commentaires notamment.
Alors, certains diront que j'insiste mais si vous pensez suivre cette série de tutoriaux, laissez moi un petit commentaire, ça motive ;)

Faisons maintenant le point sur ce que nous avons appris :

On aura tout d'abord remarqué qu'une application rails peut s'exécuter par défaut sur trois environnements : development, production et test.
Ces trois environnements permettent d'obtenir des comportements différents de l'application ainsi que des bases de données différentes.

On peut donc choisir d'afficher toutes les erreurs, d'insérer des données "virtuelles"... dans l'environnement de développement pour tester de nouvelles "features" pendant que l'environnement de production continuera a tourner a merveille.
L'environnement de test est un peu a part puisque les données n'y sont pas conservées à l'arrêt de celui ci, il est donc réservé comme son nom l'indique, à la phase de tests

On a également découvert le mécanisme de migrations de rails. Celui ci permettra au fur et à mesure de l'avancée de notre projet, d'ajouter des colonnes, des tables... en ayant toujours la possibilité de revenir facilement en arrière et de conserver l'intégrité de nos données.

Enfin, nous avons découvert quelques une des méthodes d'ActionView, la classe qui rend l'écriture de vues encore plus simple :

Je sais que certains d'entre vous ont été "choqués" part le fait que les vues ne contenait pas la moindre miette d'HTML, sachez que cela n'est en rien une obligation et qu'il est tout a fait possible d'écrire vos vues en HTML en insérant le code ruby seulement pour les données, mais cela reviendrait à se priver d'un mécanisme vous permettant d'être pratiquement certains d'écrire du code valide XHTML, et qui s'avère à la longue bien plus clair qu'un audacieux mélange entre langage à balise et langage de script.

Enfin je reviendrais ici sur un détail évident après quelques heures de codage mais qui ne l'est donc pas pour les vrais novices, sachez donc que dans les vues, les balises <% %> entoure un code ruby sans rendu tandis que les contenus placés entre <%= %> seront eux automatiquement affichés par rails.
Enfin le signe "-" placé après le tag d'ouverture ou avant le tag de fermeture indique que rails ne doit pas imprimé des caractères d'espaces ou de retour charriot situé après ou avant le tag (cela n'aura la plupart du temps d'influence que sur la présentation des sources.)

Je vous dis désormais à bientôt pour la deuxième partie du tutorial, l'interface d'administration.