Requêtes SQL ActiveRecord dans la console
Il est souvent nécessaire de jeter un oeil sur les requêtes SQL et sur leur temps d’exécution dans la console, en particulier en mode production. Voici les commandes à exécuter pour cela :
ruby script/console production >> def log_to >> ActiveRecord::Base.logger = Logger.new($stdout) >> ActiveRecord::Base.connection_pool.clear_reloadable_connections! >> end => nil >> log_to => [] >> Article.all(:limit => 30, :order => 'id desc').count => Article Load (3.0ms) SELECT * FROM `articles` ORDER BY id desc LIMIT 30
Formatage de texte : Ruby on Rails Helpers
Voici quelques fonctions incluses dans la plateforme Rails à utiliser pour formater du texte :
Module : ActionView::Helpers::TextHelper
- auto_link(text, *args, &block)
Transforme les URLs et adresses email en liens cliquables - concat(string, unused_binding = nil)
S’il n’est pas possible d’utiliser <%= ‘hello’ %> dans une view - current_cycle(name = « default »)
Retourne le cycle courant quand cycle a été lancée - cycle(first_value, *values)
Permet de créer un cycle entre des éléments et appelle la fonction to_s en alternance (à utiliser par exemple pour changer de classe pour chaque ligne dans un tableau) - excerpt(text, phrase, *args)
Extrait de texte à partir de la première instance de ‘phrase’ dans un rayon. Exemple ‘Bonjour, vos amis sont mes amis’ => … amis sont mes… - highlight(text, phrases, *args)
Insert <strong class=’highlight’>…</strong> partout ou leq ‘phrases’ sont trouvés dans ‘text’ (phrases peut être un array) - markdown(text)
Retourne le texte transformé suivant la librairis de Mark Down installés (BlueCloth par exemple) - pluralize(count, singular, plural = nil)
Transforme le singulier en pluriel si cela est possible en fonction du count donné. - reset_cycle(name = « default »)
Remet à zéro le cycle s’il avait été commencé - simple_format(text, html_options={})
Retourne le texte transformé en HTML. Utile pour la transformation des paragraphes définis par des ‘\n’ en <p></p> - textilize(text, *options)
Utilise RedCloth pour transformer en HTML un texte écrit en Textile - textilize_without_paragraph(text)
Même chose que la précédente méthode, sauf qu’elle ne rajoute pas les <p> que RedCloth ajoute automatiquement - truncate(text, *args)
Tronque le texte en utilisant :length comme longueur (par défaut : 30). Si la longueur du texte obtenu est supérieure à :length, ajoute « … » ou la chaîne de caractère :omission si donnée en paramètres. - word_wrap(text, *args)
Crée des lignes à partir d’un texte en s’assurant que chaque ligne ne dépasse pas :line_width donnée en paramètre (par défault : 80)
Dès qu’on commence à utiliser ces fonctions, elles deviennet véritablemen des incontournables !
Subversion (SVN) et Ruby on Rails : déploiement en SSH
Quand je développe un projet en Ruby on Rails, j’utilise à peu près toujours un gestionnaire de version. La plupart du temps Subversion, bien que la mode soit l’utilisation de Git. Mon hébergeur (Dreamhost) m’offre un espace illimité et la création d’autant de SVN que je veux.
Dans cet article je décris la procédure que j’utilise pour déployer un site en SSH.
Setup de base
- http://adresse-de-mon-svn/app : l’URL du serveur SVN
- Le SVN est déjà créé et contient la dernière version de mon application Rails
- Certains dossiers sont ignorés (voir plus bas)
- Accès en SSH (putty) fourni par l’hébergeur
- Le fichier database.yml est déjà configuré pour le serveur production
Dossiers à ignorer dans le SVN :
Il faut utiliser le SVN seulement pour gérer la version des fichiers qui concernent le développement. Quand je mets en place un SVN avec Rails, j’ignore les dossiers suivants :
- log
- tmp
- Si l’application gère des ressources contenant des images (produits par exemple), ignorer le dossier de ces images (exemple : le dossier utilisé par attachment_fu)
Procédure
- mkdir app
Avec putty, crée un dossier VIDE qui va contenir votre application - svn checkout http://adresse-de-mon-svn/app app
« Connecte » le dossier app au SVN et télécharge les fichiers mis à jour - rails -s app
Crée les fichiers manquant pour faire rouler l’application Rails en ignorant les fichiers manquant - rm app/public/index.html
Et voilà ! Dorénavant, votre application Rails peut profiter de tous avantages d’un SVN.
Convertir Datetime en format Ruby et pour la base de données
Format personnel vers Ruby
Je veux transformer une date du style « 23/11/2009 » en Time de Ruby :
>> Time.now
=> Mon Jan 11 13:37:11 +0000 2010
>> Time.now.to_s(:db)
=> "2010-01-11 13:38:38"
>> ma_date = "23/11/2009"
=> "23/11/2009"
>> j, m, a = ma_date.split('/')
=> ["23", "11", "2009"]
>> mon_datetime = Time.local(a,m,j)
=> Mon Nov 23 00:00:00 +0000 2009
Ruby >> SQL
En Ruby :
>> Time.now => Mon Jan 11 13:23:17 +0000 2010
Pour faire la conversion (j’utilise MySQL) :
>> Time.now.to_s(:db) => "2010-01-11 13:38:38"
Behaviour (ou test) driven development : une introduction
Ce qu’on appelle le BDD (Behavior driver development), aussi appelé TDD (Test Driven Development) fait partie des dernières tendances de méthodologie de développement des applications Web. Comme on lit souvent sur Internet, un bon programmeur Rails écrit toujours des tests, et certains vont même jusqu’à considérer ceux qui n’écrivent pas de tests comme des personnes stupides (merci du peu) !
La méthodologie consiste à coder et à tester les spécifications en utilisant une plateforme comme RSpec pour Ruby et Rspec Rails pour Rails, avant d’appliquer les changements nécessaires à l’application pour faire passer les tests.
Plus précisément, le cycle en 3 étapes est connu sous le nom Red, Green et Refactor :
- Coder une spécification (ou un test) et faire rouler les tests qui vont la faire échouer (RED)
- Ecrire l’implémentation de la spécification pour faire passer le test (GREEN)
- Améliorer la structure de l’application sans changer son comportement externe (REFACTOR)
Voici un document expliquant la méthodologie du BDD et ces avantages (en anglais).
Je vous en cite quelques avantages sans trop rentrer dans le détail :
- Réfléchir à ce qu’on souhaite implémenter et l’écrire permet de mieux connaître ses objectifs et d’y rester concentré
- Faire rouler les tests sur toute l’application à chaque fois qu’on change le code permet d’indentifier immédiatement les défaillances
- L’écriture des spécifications joue aussi un rôle descriptif de l’application
- Meilleure collaboration entre développeurs
- Le cycle durant 5 à 10 minutes, quand on tombe sur un bug, on est sûr que la version d’il y a 5-10 minutes fonctionnait parfaitement et on peut y retourner très facilement
Quelques plateformes pour Rails
Il existe plusieurs plateformes de testing en Rails. L’installation par défaut de Rails intègre sa propre librairie de Testing (Test::Unit), mais d’autres ont été écrites avec pour objectifs de la remplacer ou de l’augmenter d’autres usages qu’elle ne prévoient pas :
- shoulda - une méthode alternative
- mocha – librairie de mocks et de stubs (simulation d’objets et de fonctions)
- rspec – le plus populaire, remplace le système de resting de Rails)
- Selenium - automatisation des testings des applications Web
- Cucumber – écriture de tests dans un langage compréhensible par tous
- Webrat – tests de validation
Tutoriel : créer un application Ruby on Rails en quelques minutes sous Windows
Prérequis et configuration par défaut
- Système (l’un ou l’autre)
- InstantRails (exécutable regroupant Ruby, RubyGems, Rails et MySQL)
- Wamp, Ruby, RubyGems et gem install rails (ma méthode préférée)
- Username MySQL : root / Mot de passe : aucun
- gem install rspec (Dans la console de windows : Exécuter, cmd, Entrée)
- gem install mongrel
- Un éditeur avec arborescence de fichiers (J’utilise Aptana, Netbeans ou Notepad++)
Marche à suivre
API Ruby on Rails en Javascript avec AJAX
L’API de Rails fournie par rubyonrails.org (api.rubyonrails.org) est quelque peu embêtante à utiliser. Pas de recherche incluse et donc il faut utiliser le Ctrl+F de son navigateur, ce qui n’est pas « user-friendly at all » !
Je vous montre ici comment accéder à l’API en local, et vous propose d’autres solutions bien plus intéressantes
Fonctionalités à étudier et à tester pour une application Web
Ceci est un travail en cours (auquel vous êtes les bienvenus à participer)
L’objectif de cette note est de faire un listings des différents éléments à tester quand onveut choisir ou étudier une technologie ou un système : CMS, plateforme de développement, librairie, langage, etc. L’idée est d’en faire un outil de travail qui permet de se construire rapidement une opinion de la difficulté à développer avec le sytème en question, sa mise en production et son opérabilité.
Combiner Rails et ExtJS : super tutoriel !!!
Accès au tutoriel (en anglais) : Ext JS on Rails: A ComprehensiveTutorial de Chris Scott (développeur Core de ExtJS).
ExtJS est une librairie en Javascript de développement d’interfaces Client très puissantes. Une application utilisant ExtJS peut avoir l’air d’une application Desktop évoluée. Elle est surtout utile pour les consoles d’admininistration, ou les applications client/serveur Web comme les intranets.
Mongrel très lent en localhost sous Windows Vista et Firefox
Contexte
Mongrel est le serveur de prédilection pour le développement en local (environnement de développement) avec Rails, surtout sous Windows. En production il est préférable d’utiliser Passenger, qui n’est malheureusement pas disponible sous Windows (UNIX seulement).
Problème
Sous Vista, avec Firefox et Chrome, Mongrel semble des fois très lent quand il s’agit de servir du contenu statique (images, javascript, css, etc.) à partir de localhost. Ceci peut être dû à l’implémentation de IP6 sous Vista, et la difficulté qu’il peut avoir « router » la requête vers localhost.