Authlogic: interdire les sessions multiples pour le même utilisateur

Pour compenser le fait qu’il y ait eu deux articles la semaine passée, celui de cette semaine sera light ;)
Il existe plusieurs systèmes d’identifications pour les applications Rails. Mes deux préférés sont authlogic et devise. Mais clearance est pas mal non plus.

Je vais parler du premier. Lorsque vous avez implémenté votre système d’identification avec ce gem, vous vous rendrez rapidement compte qu’un même utilisateur peut être connecté plusieurs fois depuis des machines ou des navigateurs différents.
Ce base, cela peut être intéressant afin d’éviter d’avoir à redemander à vos utilisateurs de se reconnecter trop régulièrement.

Mais dans d’autres cas (ou vous désirez éviter le partage de comptes par exemple), ce n’est pas l’effet désiré.
Après avoir cherche un petit peu, j’ai posté la solution à ceci sur stackoverflow.

Dans votre modèle de session (par défaut UserSession), ajoutez le code suivant :

before_destroy :reset_persistence_token
before_create  :reset_persistence_token

def reset_persistence_token
    record.reset_persistence_token
end

Nous créons deux callbacks.
Ainsi, notre méthode reset_persistence_token sera exécutée à chaque fois que nous créons ou supprimons une session utilisateur (à chaque fois que l’utilisateur se connecte ou se déconnecte).

Cette méthode réinitialise un token qui est également situé dans la session de l’utilisateur et qui nous permet de l’identifier.
Nous sommes obligés de la définir car elle l’est à l’origine, uniquement dans le modèle User. C’est dans la session que nous désirons réinitialiser ce token.
D’ou le record.. record retourne l’utilisateur auquel nous réinitialisons le token.

Ainsi, à chaque fois que notre utilisateur se connectera ou se déconnectera de l’application, le token sera modifié.
Et nous n’aurons donc pas la possibilité d’avoir deux machines connectées avec la même session :)

24 février 2010 | Tags: , , , , | Aucun commentaire »

10 raisons pour lesquelles tout développeur devrait avoir un blog technique

Je vois beaucoup de développeurs anglophones qui ont des blogs techniques. Mais cela ne me semble pas si répandu que cela chez les francophones.
Du coup j’ai rédigé une petite liste de 10 raisons (en fait 11) pour lesquelles, toi, développeur, tu devrais avoir un blog technique.

  1. Le partage des connaissance

    Ne soyez pas égoïste, pensez aux autres développeurs qui vont affronter des problèmes similaires aux vôtres !
    Partager ces problèmes (en les sortant de leur contexte au besoin) vous permet ainsi de faciliter le travail de ceux qui tenteront de faire la même chose que vous après.

  2. La création d’une base personnelle de connaissances

    Parce que penser aux autres c’est gentil. Mais qui pensera à vous ! ;)
    Avec un blog, vous vous créez une base de connaissances personnelles voir un aide mémoire.
    Il m’est par exemple arrivé plusieurs fois de me rendre sur mon article Installer le gem MySQL sous mac.

  3. La veille technologique

    Avec un blog que vous tentez réellement de mettre à jour régulièrement, vous allez tenter de vous tenir toujours au courant des dernières nouveautés afin de faire de nouveaux articles.
    Ainsi j’ai écrit quelques articles sur Rails 3 dernièrement. Cela m’a forcé à me pencher sur cette version bêta. Chose que je n’aurai probablement pas fait tout de suite si ce n’est pour rédiger ces articles.

  4. Le dépassement de soi

    Lorsque vous allez tenter de découvrir ces nouvelles technologies, vous allez devoir vous plonger dans la documentation de l’application (personne n’a encore réellement fait d’article puisque la chose est toute neuve) voir dans le code même de celle-ci.
    C’est une excellente manière de vous dépasser personnellement et au passage d’améliorer vos compétences en développement.

  5. La reconnaissance des compétences

    En discutant avec Sarah il y a quelques semaines, celle-ci me disait ne pas rédiger d’articles techniques car beaucoup de monde le fait déjà en PHP. En même temps elle ajoutait avoir eu quelques personnes lui ayant dit ne pas savoir comment elle développe.

    Lorsque vous cherchez un emploi en tant que développeur, votre futur employeur (et/ou vos futur collègues) va/vont vouloir savoir comment vous développez. S’il faudra repasser derrière vous après chaque commit ou si vous allez devenir le nouveau cerveau de l’équipe.
    Deux manières existent afin de montrer du code : participer à des projets open source ou écrire des articles sur un blog :)

    Attention, ceci est également à double tranchant. En publiant du code, vous courez également le risque que tout le monde se rende compte qu’en fait, votre code n’est pas aussi propre que vous voudriez le faire croire ;)

  6. Remercier les gens qui ont pris du temps pour vous apprendre

    Bah oui, on a tous débuté un jour. Moi c’était en seconde avec Jordan et un livre sur PHP (qui est une référence en matière de mauvaises pratiques).

    Et à ce moment la, vous avez bien du demander de l’aide sur divers forums ou à des amis qui avaient déjà de la bouteille. Quelle meilleure manière de les remercier que de partager ensuite ce que vous avez appris ?

  7. La visibilité/e-réputation

    Ouais, c’est quand même l’une des raisons premières de créer un blog hein. Vous allez gagner en visibilité, en renommée (à condition de faire des articles de qualité), devenir un expert dans votre secteur (ou au moins donner l’impression que vous en êtes un :mrgreen: ).

    Les conséquences se font rapidement ressentir : vous recevrez beaucoup plus d’offres d’emploi (et serez donc mieux payé), de demandes de contact (j’ai beaucoup d’étudiants qui me contactent pour des « interviews » sur le métier de développeur web).

  8. Se la péter

    :mrgreen:

    Il ne se passe pas une semaine sans qu’un collègue, en cherchant quelque chose à propos de ruby, ne tombe sur mon blog. Et quelle meilleure manière de se « la péter » que de ressortir sur tous les résultats Google relatifs à un domaine technologique précis.

  9. Amour du prochain

    C’est pas moi qui ai dit « Aimez vous les uns les autres ». Mais ca s’applique bien ici. Et même si c’est un petit peu de la répétition avec la seconde raison, ça fonctionne tout de même.
    On ne vis pas dans un monde de bisounours. Mais en travaillant pour, on peut arriver à quelque chose de similaire ;)

  10. Se payer des bières avec les adsense

    On peut toujours rêver ! Mais rien ne vous empêche d’afficher quelques publicités sur votre blog.
    Pour info avec les revenus générés par ce blog, je peux me payer environ 3 bières par mois.

  11. Le fun

    Et oui, ça ne fait pas 10 mais 11. Et pourtant cette dernière raison est la plus importante.
    Il y a quelques jours en réfléchissant à cet article, j’ai sondé sur twitter en demandant « qu’est-ce qui vous motive à maintenir un blog technique ? ».
    S’en est suivi une discussion avec Raphael qui m’expliquait rapidement pourquoi il a fermé son blog.

    C’est la raison primordiale pour maintenir un blog technique : il faut que cela vous amuse. Si ce n’est pas le cas, autant ne rien faire.
    Vous n’arriveriez pas à vous motiver, vos articles perdraient fortement en qualité et votre blog n’aurait pas réellement d’intérêt.

Pour finir je ne donnerai que deux conseils à ceux que cela aurait (par le plus grand des hasards) motivé à créer leur blog :

  • Soyez constant.
    Évitez de publier trois articles le premier mois, puis plus rien pendant 6 mois.
    Je me force personnellement à faire un article par semaine (voir plus. La preuve, cet article est le second e la semaine). Mais cela peut être plus ou moins.
  • Relisez vous. Lors du Wordcamp Parisien de Février 2009, on m’a demandé « si j’avais un seul conseil pour un futur blogueur à donner, quel serait-il ? »
    Ma réponse fut : rédige tes articles le lundi, publie les le mardi.
    Et relis ton article avant de le publier.

Et vous, qu’est-ce qui vous pousse à maintenir (ou pas) un blog technique ?
Certains m’ont déjà répondu (merci Xavier et Bruno) et cela a fait les 6e et 9e raisons.

18 février 2010 | Tags: , | 8 commentaires »

CouchDB: recherche avec startkey et endkey

J’ai déjà plusieurs fois, dans des articles précédents, parlé de couchdb.
Notamment les bases et les vues.

Dans le second article notamment, nous avons vu la fonction emit, qui permet, dans une vue, de renvoyer un enregistrement.
Cette fonction prends deux arguments. Le premier étant la clé de l’enregistrement, à considérer comme son identifiant. Et le second étant les données de l’entrée.

Supposons une vue quelconque qui me retournerait les données suivantes :

{"total_rows":5,"offset":0,"rows":[
    {"id":"cef5872e7d32bfe45f4a0b766544878c","key":"Aptitude","value":5},
    {"id":"c1a25474f3bb36ab517945c24f3a6c34","key":"Rubinius","value":3},
    {"id":"234331917ad63b46a155d4482df350eb","key":"Rubygems","value":2},
    {"id":"317fd0be2eb4133528af6cf6e4fba4aa","key":"Rubygems","value":8},
    {"id":"5040d8ea60f951fe6a44b0b0f7eee439","key":"Rubygems","value":7},
]}

La clé est un identifiant permettant de reconnaitre chaque entrée. La valeur n’a aucun sens ici. Mais contiendra les données de votre enregistrement dans un contexte réel.

CouchDB vous permet de récupérer tous les enregistrements. Mais pour n’en récupérer que certains, cela risque d’être un petit peu compliqué.
Créer une vue pour chaque requête est à rejeter d’avance car overkill.
Deux options vont cependant venir à notre secours : startkey et endkey.

Supposons que je ne sois intéressé que par les entrées ayant pour clé « Rubinius ».
En appellant notre vue avec les paramètres ?startkey= »Rubinius »&endkey= »Rubinius », nous obtenons uniquement l’entrée correspondant à Rubinius.
Les paramètres startkey et endkey doivent être des éléments json valides. Nous devons donc y ajouter des «  » afin de spécifier une string.

Si nous voulions Rubinius et Rubygems, nous pourrions faire une recherche sur le terme Rub qui est commun aux deux.
Donc en mettant un ?startkey= »Rub »&endkey= »RubZ », nous aurons tous les enregistrements, qu’ils aient pour clé Rubinius ou Rubygems.

Que font startkey et endkey ?

Pour comprendre à quoi servent ces deux paramètres, il faut prendre les résultats de manière itérative.
CouchDB les parcours tous les uns après les autres. Lorsque startkey est présent, il supprimera tous les enregistrements jusqu’à ce que l’un d’entre eux ne matche la valeur du paramètre.

CouchDB conservera ensuite tous les enregistrements.

Si endkey est présent, il ne les conservera que jusqu’à ce que l’un d’eux ne matche la valeur de ce paramètre. Et supprimera tous ceux situés après que le premier ait matché cette valeur.

Dans notre exemple précédent, si nous avions mis « Rub » à endkey, le premier enregistrement aurait matché non seulement startkey mais également endkey.
Par conséquent nous n’aurions vu strictement aucun enregistrement. Tous auraient été enlevés des résultats.
En mettant endkey à RubZ, tous nos enregistrements Rubinius et Rubygems matchent cette valeur.
Mais si nous avions un enregistrement Python à la suite, il ne matcherait absolument pas et ne serait donc pas inclus.

Recherche dans une clé simple

Par clé simple, nous entendons un string (à l’opposé d’un tableau ou d’un hash json).
Dans le cas d’un string, CouchDB fera une comparaison > ou < entre la clé et la valeur de startkey et endkey.

Ainsi si startkey a pour valeur 3, toute clé étant un entier supérieur ou égal à 3 sera inclus dans les résultats.
Si startkey a pour valeur "Aaa", des clés telles que "Aaabbb", "Aaaaaa" seront inclues. Mais "Abaa" ne sera pas inclue.

Afin de faire une recherche sur une terme précis, je vous conseille d'ajouter un caractère très éloigné dans votre table de caractères à la fin de endkey.
En ruby le mieux pour cela est de faire :

FAR_CHAR = [0x9999].pack(‘U’)

Vous n'avez plus qu'à ajouter ce caractère, le dernier que vous pourrez trouver, à la fin de votre chaine endkey.

Recherche dans une clé multiple

Les recherches dans les clés multiples sont un petit peu plus compliquées.
Supposons une vue qui vous retournera l'élément JSON suivant :

{"total_rows":5,"offset":0,"rows":[
    {"id":"cef5872e7d32bfe45f4a0b766544878c","key":["Aptitude", "Rubinius"],"value":5},
    {"id":"c1a25474f3bb36ab517945c24f3a6c34","key":["Rubinius", "Aptitude"],"value":3},
    {"id":"234331917ad63b46a155d4482df350eb","key":["Rubinius", "Aptitude"],"value":2},
    {"id":"317fd0be2eb4133528af6cf6e4fba4aa","key":["Rubygems", "Aptitude"],"value":8},
    {"id":"5040d8ea60f951fe6a44b0b0f7eee439","key":["Rubygems", "Rubygems"],"value":7},
]}

Comment chercher dans un tableau ... :)
Simplement en y passant un tableau ! Ainsi, nous pourrions faire ?startkey=["Rubinius", "Aptitude"]&endkey=["Rubinius", "Aptitude"]
Qui nous retournera tous les enregistrements correspondant à la clé ["Rubinius", "Aptitude"] (soit 2 enregistrements).

La recherche fonctionne de la même manière que précédemment sauf que en plus de parcourir tous les enregistrements, CouchDB parcours chacunes des entrées du tableau.
Mais ne fait pas de comparaison pour chacun des éléments !

CouchDB fait en effet une comparaison d'égalité pour chacun des éléments du tableau, sauf le dernier.
Ainsi, dans notre dernière requête, une comparaison == sera faite pour l'élément "Rubinius".
Et des comparaisons < et > seront faites pour l'élément "Aptitude".

Du coup si vous placez, dans votre requête : ?startkey=["Rub", "Aptitude"]&endkey=["RubZ", "Aptitude"], vous n'aurez non pas trois enregistrements ... Mais aucun car aucun de vos enregistrements n'a pour première valeur de sa clé "Rub".

En revanche sur le dernier élément, la recherche se fait avec les mêmes comparaisons que pour une string.
Vous pouvez donc faire la recherche suivante : ?startkey=["Rubinius", "Apt"]&endkey=["Rubinius", "AptZ"], qui vous retournera correctement vos deux enregistrements ayant pour clé ["Rubinius", "Aptitude"].

Conclusion

Si vous en êtes ici et que vous avez tout compris, félicitations ! J'ai mis deux bonnes heures avant de réellement comprendre le concept ;)
Comme vous le constatez, la recherche via startkey et endkey est assez atypique comparé à une recherche SQL habituelle et dicterera généralement une partie de l'architecture de votre application et de son fonctionnement.

Mais une fois que ceci est compris, la puissance de ce genre de recherche est assez impressionnant (dans mon cas, chez LIM, nous faisons des recherches dans des tableaux allant jusqu'à 12 entrées).
Et vous, comment l'implémentez-vous ? :p

16 février 2010 | Tags: , , | Aucun commentaire »

Rails 3 : nouvelle API ActionMailer

L’une des grandes mises à jour de Rails 3 est la nouvelle API Action Mailer.
Petit rappel : dans les versions précédentes de Rails, nous pouvons transmettre des emails en créant, dans le répertoire app/models un modèle ActionMailer.
Celui-ci pourrait ressembler (dans rails 2.3) à ceci :

class UserMailer < ActionMailer::Base
    def welcome_email(user)
        recipients user.email
        from "I'm nobody <42@unknown>"
        subject "Hello World"
        body {:user => user }
    end
end

Et dans le répertoire app/views/user_mailer, nous pourrons créer un fichier welcome_email.text.erb qui sera le contenu de notre email.
Maintenant supposons que nous désirions attacher une pièce jointe à notre email.
Nous allons devoir ajouter dans notre méthode welcome_email cette pièce jointe.

attachment "application/pdf" do |a|
    a.body = contenu_du_pdf()
end

un « beurk » suffira !

Dans Rails 3, notre méthode d’envoi d’email devient la suivante :

class UserMailer < ActionMailer::Base
    default :from => "I'm nobody <42@unknown>"

    def welcome_email(user)
        @user = user
        mail(:to => user.email,  :subject => "Hello World")
    end
end

Et lorsque nous souhaitons ajouter une pièce jointe, nous n’avons qu’à faire :

attachments['terms.pdf'] = {:content => contenu_du_pdf() }

C’est déjà plus sympa.

Mais ce n’est pas tout ! Par défaut, les fichiers welcome_mail.text.erb et welcome_mail.html.erb sont inclus dans le mail.
Ainsi la personne recevant l’email peut le lire en html ou en texte.
Mais tout comme vous le faites dans vos contrôleurs pour l’html, le json, l’xml ou tout autre format, vous pouvez vouloir rendre quelque chose de différent en fonction du format html ou texte du mail.

Go ! :) 

mail(:to => user.email,  :subject => "Hello World") do |format|
    format.text { render :text => "Mon email est en texte" }
    format.html { render :html => "Mon email est en <strong>HTML</strong>" }
end

Pour continuer lorsque vous envoyiez votre email, vous faisiez cela de la manière suivante :

UserMailer.deliver_welcome_email(@user)

Vous devrez maintenant faire :

UserMailer.welcome_email(@user).deliver

Le welcome_email vous renvoyant un objet Mail que vous pouvez ainsi modifier comme bon vous semble.
Voir le stocker pour l’envoyer plus tard par exemple.
Si vous désirez plus d’informations concernant cette nouvelle API, je vous recommande l’article sur guides.rails.info (encore en cours de rédaction).
Et le gist qui a servi de spécification pour cette nouvelle API.

9 février 2010 | Tags: , , , , , , | Aucun commentaire »

Apéro Ruby Lyon de février et introduction à bundler

Demain soir aura lieu le 4e apéro Ruby à Lyon.
Bien évidemment, je ne peux que vous conseiller de vous y rendre !
Je serai présent et j’entrainerai un jeune padawan avec moi afin de le trainer du côté clair de la force :)

C’est à l’Antre Autre, un petit bar sympa à côté des Terreaux.
Vous pouvez venir à partir de 19h. Et nous serons probablement plusieurs à manger sur place par la suite (mais bien évidemment, vous partez quand bon vous semble).

Que vous veniez ou pas, vous avez entendu parler de rails 3 !
Et peut-être de bundler, dont je ferai une présentation d’une dizaine de minutes (« lightning talk »).

Du coup, que vous veniez ou pas, vous pouvez visualiser en ligne cette introduction à bundler.
Enjoy! comme on dit. Si vous avez des remarques à faire dessus, n’hésitez pas à me les faire remonter (ou alors à forker le projet et à faire les modifictions).
Et je vous attends demain.

3 février 2010 | Tags: , , , , , | Aucun commentaire »
 
 
Fork me on GitHub