mai 2007

Si vous êtes un lecteur régulier de notre blogue, vous avez peut-être remarqué que nous avons ajouté de la publicité Google AdSense. Lors du lancement du portail M2i3, il y a plus d’un an, j’avais convaincu Jean-Marc de ne pas mettre de la publicité sur le portail. Mon point de vue est qu’un portail corporatif ne peut pas être considéré comme sérieux avec une publicité générée automatiquement. Il est normal que des portails comme Microsoft ou Apple publicisent leur produit mais pas de publicité générée automatiquement. Il est vrai que M2i3 est loin
de la réputation de Microsoft, Apple ou même 37signals et à ce jour nous n’avons pas de produit. À l’heure actuelle, il n’est pas possible d’avoir des commanditaires particuliers même à plus de 1000 visites par mois. Comme notre portail Web est surtout basé autour du blogue, nous avons décidé de complémenter nos revenus à l’aide de Google AdSense. Mais ceci a un but. Nous sommes à développer un nouveau système de clavardage basé entièrement sur la technologie Ruby on Rails. Le site est destiné auxadultes de la communauté gai. Dans un court laps de temps, nous devrons certainement passer à un serveur dédié. Un serveur dédié est beaucoup plus cher qu’un compte partagé, nous espérons que nos revenus publicitaires nous aiderons à partir du bon bien. Bonne soirée.

AVERTISSEMENT, ce blog suppose que vous connaissez l’existence des fichiers « RJS ». Si ces trois lettres ne signifie rien pour vous, je vous suggère une recherche sur Google avec les mots clefs Ruby on Rails, RJS avant d’effectuer la lecture de ce blogue.
Pour tous les autres, j’imagine introduire une méthode que j’ai découvert l’autre jour en fouillant le code source permettant l’exécution des fichier RJS. La méthode est publique et même documenté donc, j’assume ici, disponible pour être utilisé. Sans roulement de tambour… la méthode « call » permet d’insérer l’appel à n’importe quelle fonction Javascript à l’intérieur de votre fichier RJS et contrôler l’appel de celle-ci de la même façon dont vous contrôlez l’appel aux méthodes show, remove et autre. Mais pourquoi diantre voudrais-je faire ça? Eh bien! Dans une application Web2.0 vous aurez très certainement vos propres function JavaScript en plus de celle fournit part Prototype et Scriptaculous. La méthode call vous permets d’appeler ces fonctions directement. Dans mon cas (et j’ai hâte de vous montrer cette nouvelle application) c’est aussi pour minimiser la quantité d’information à échanger entre le serveur et chaque client. En plaçant les comportements nécessaire à l’avance dans mon fichier application.js, j’évite d’avoir à transmettre toutes les modifications à effectuer à ma page sur chaque mise-à-jour. Tout ce qui est transmit est l’appel à cette fonction qui se charge ensuite d’effectuer localement l’ensemble des modifications. En bref, rien ne vaut l’expérimentation… lisez donc la documentation de la méthode call et amusez-vous bien! Sur ce… à bientôt je retourne à mon projet (surtout à travailler à l’extérieur, vue sur la piscine, avec ma connection sans fil… )

Tags: Ruby on Rails, Programmation, Ruby

Un des aspects intéressant de Ruby on Rails est la conversation d’URL en controller/action et paramètres de tout acabit. Vous pensiez que le monde arrêtait avec la configuration par défaut? Il y a bien plus que la page par défaut et la séquence :controller/:action/:id à
explorer.

Le lien attrape-tout

Pour fonctionner ce dernier doit être le dernier paramètre de l’url. Sinon autant utiliser l’autreméthode décrire plus bas. Le lien attrape tout ressemble à: map.connect ‘*path’ , :controller => ‘blog’ , :action => ‘inconnu?’ Ce code appellera la méthode inconnu? sur le contrôleur et placera dans params[:path] la totalité de l’URL. Mignon? Pratique? Surtout pratique si vous voulez-faire une page intelligente pour les URLs non-existantes. En analysant l’URL on peut guider le webnaute vers un contenu qui devrait répondre à ses besoins et ce malgré l’erreur.

Les textes prédéfinis dans l’URL

Sur un de mes derniers projets j’avais besoin de publier des textes avec l’engin de document créé chez M2i3. Pour sûr je ne voulais pas avoir des liens du style « /document/show/23 ». En plus des raisons esthétiques un tel lien diminue la valeur des pages par les engins de recherche puisque l’URL n’a aucun lien textuel avec le contenu. Pourtant faire un lien simple comme « :alias_page » aurait confondu Rails puisqu’il aurait assumé que je parle ici d’un contrôleur. Donc… l’utilisation de textes prédéfinis dans l’URL permet de résoudre ce genre de situation. Voici la configuration en question: map.connect ‘:alias_page.html’ , :controller => ‘document’ , :action => ‘show’ Je n’utilise pas l’ID puisque le nom de ma page est une chaîne de caractère que j’ai nommé « alias_page ». La beauté de cette configuration est que la méthode « url_for » construit l’url proprement. Donc dans mon code lors que je veux créer un lien vers la page dont l’alias est « a-propos-de-nous » j’utilise le code: ‘document’, :action=>’show’, :alias_page=>’a-propos-de-nous’ %> et le lien généré est « /a-propos-de-nous.html » beaucoup plus propre non???

Les routes nommées

Ce truc permet de simplifier le code en nommant la route lors de la configuration. J’ai une relation haine/amour avec cette technique puisque même si elle permet de simplifier le code elle en diminue aussi la portabilité puisque la route nommé doit exister dans l’application où l’on veut copier/utiliser le bloc de code. Donc, en reprenant le truc précédent nous pourrions le réécrire avec une route nommée comme: map.document_link ‘:alias_page.html’ , :controller => ‘document’ , :action => ‘show’ Remarquez comment on remplace la méthode « connect » par une méthode représentant le nom de la route. Ça nous permet d’utiliser le code suivant: ‘a-propos-de-nous’) %>…. intéressant? non?

Les expressions régulières

Ce dernier truc permet d’obtenir des effets vraiment intéressants. Je reviens à mon exemple précédent. Par l’utilisation du texte prédéfini on peut rapidement identifier dans l’URL le type de document à servir, l’action et le contrôleur à utiliser. Pourtant le truc ne permet de traiter qu’un niveau de profondeur dans l’URL (i.e. je peux lier vers /ceci-est-une-page.html mais pas vers ceci/est/une/page.html). Le dernier truc permet justement de passer le contenu de l’URL tel que dans le lien attrape tout mais sans les avertissements que Rails vous générera si vous essayez de configurer map.connect ‘*alias_page.html’ , :controller => ‘document’ , :action => ‘show’. Dans un tel cas Rails passerait son temps à vous dire que le paramètre optionel ne peut être optionel à cause du texte. Donc, j’utilise la configuration suivante: map.document_link ‘:alias_page.html’ , :controller => ‘document’ , :action => ‘show’, :requirements=>{:alias_page => /.*/ } Le « /.*/ » est l’expression régulière qui indique à Rails de tout attraper et de passer outre les « / ». Donc mon alias de page peut maintenant ressembler à une url complète.

En conclusion

La configuration et personnalisation du fichier routes.rb permet de faire la différence entre une application Ruby on Rails qui ressemble aux autres et un site web qui a sa propre personnalité. Allez-y! amusez-vous à sortir des sentier battus 😉

Tags: Ruby on Rails, Programmation, Ruby

Dernièrement je vous parlait du problème causé par l’utilisation de Kernel.puts sous fast-cgi. On se demande alors comment générer des traces sous Ruby on Rails. Le framework vient avec un utilitaire de trace qui générera, selon la configuration dans environment.rb, un fichier developement.log, production.log ou test.log.
L’objet est accessible sous le modèle, le contrôleur ou le « mailer ». Il définit des méthodes comme « info », « warm » et « error » en fonction de l’importance du message à tracer. Donc, bien simple et presque omniprésent l’utilitaire de trace pour savoir ce que l’application fait.
Bonne trace!
Jean-Marc

Comme vous l’avez probablement remarqué, hier M2i3 et certains autres projets ont vu une page de « compte suspendu » être affiché. La raison en est simple et découle du fait que pour le moment nous utilisons un compte partagé chez Bluefur.
Voyez-vous, l’avantage d’un compte partagé est qu’il coûte moins cher que d’avoir un serveur dédié. L’espace disque y est, la bande passante aussi… le désavantage est que l’on doit partager les ressources du serveur avec d’autres gens et que le fournisseur de service peut suspendre le compte de quiconque utilise trop de ressources sur le serveur.
C’est ce qui est arrivé hier. Un des projets (actuellement hors ligne en attendant que le problème soit réglé) a vue le nombre de visiteurs augmenter énormément dans les dernières semaines et fait apparaître des problèmes de performances au niveau de l’application. Pour protéger les autres utilisateurs du serveur, Bluefur a donc suspendu notre compte le temps que l’on puisse leur expliquer la raison du problème.
Comme quoi, il n’est pas toujours avantageux de partager… ou pas toujours bien d’être populaire… du moins, sans les ressources nécessaires.

Tags: Ruby on Rails

Vous êtes à travailler sur votre dernier projet en « Ruby on Rails » et pour faire vos traces, vous utilisez l’instruction « puts » du module « Kernel ». Après, le tout c’est envoyé à la console et non au fureteur web… Non ?
Cette approche est simple et fonctionne tant que vous utilisez « Webrick ». Vous aurez bien des problèmes si vous devez utiliser « fast-cgi » sous Apache. Voyez-vous, les informations retournées à la console sont retourné au serveur Apache et le texte qui pouvait vous aider à « debugger » votre application l’empêchera tout simplement de fonctionner.
Comment est-ce que je m’en suis rendu compte ce soir ? Par la ligne suivante dans mon log d’erreur : FastCGI: incomplete headers (0 bytes) received from server « /home/…/dispatch.fcgi ».
À bon entendeur!
Jean-Marc

Bon quoi faire dans ce temps la. Nous avons quelques clients qui ne nous ont pas payés encore. Pas tout les mauvais payeurs doivent être pendus haut et court. Je ne paye pas toujours ma facture de telephone cellulaire a temps. De plus nous avons des personnes qui ont des ententes de paiement différentes. C’est correct et normal. Mais quoi faire à ceux qui vous dises que le chèque est dans le courrier. Pas de problème on vous paye pour votre bon travail et puis on entends plus jamais parler d’eux. Je vends la dette à une agence de recouvrement ? Je le poursuis aux petites créances du Québec ? Je coule son portail Web en achetant des liens dans des link farms {en}, puis je mets un mémo sur notre portail qu’il est un mauvais payeur? Je clos le sujet et je passe à autre chose. C’est pas l’envie qui me manque d’utiliser la troisième option. Je crois que nous serons tolérant et tenterons d’avoir notre argent de manière légale.

Oops! Bon, nous sommes de retour en ligne. Un petit problème de serveur chez BlueFur.com. Je dois dire que bien que le problème leur était connu et que nous avions rien à voir avec leur problème. Il leur a prit 13 minutes pour répondre à l’appel de service placé. Je dois dire que leur service technique de BlueFur.com est vraiment bon. Bonne journée.