Voici donc Public Folder

Ce projet est extrêment simple, il s’agit d’une interface de gestion de répertoires. À partir de la racine, on peut ainsi naviguer à travers une arborescence que l’on peut créer soit même. On peut donc créer des répertoires et uploader des fichiers directement dans l’application.

Le stockage des fichiers se fait directement sur disque dans la même arborescence que celle définie dans l’application. Elle est juste comme git, si vous créez un dossier dans l’application et qu’il ne contient aucun fichier, le dossier ne sera pas créé sur le disque.

Au niveau de la navigation, l’url correspond à l’architecture du dossier et on peut trier chaque liste par date/type/poids ou noms.

Pour réaliser cette application, la stack est full Rails, soit ActionPack et ActiveRecord. J’ai juste utilisé decent_exposure, simple_form et draper comme gems. Je ne peux plus du tout me passer d’eux tellement ils sont devenu essentiel pour moi.

Ce projet est complétement testé. J’ai une couverture de test de 99% selon Coveralls. Il a une note de 4 sur CodeClimate. Vous pouvez le voir aussi sur Travis.

Je ne compte pas continuer le développement de cette application. Je n’en ai strictement aucun besoin. Par contre, je la laisse à la postérité et aux lecteurs de code en tout genre.

Le grand avantage que j’ai vu dans decent_exposure est la facilité d’accès des variables dans les vues. Plus besoin de faire appel à des instances. On appele simplement la méthode. Si celui-ci n’était pas instancié alors decent_exposure le faisait pour nous. On obtenait ainsi un système beaucoup plus souple qui ne chargeait les objets qu’au moment ou il était nécessaire. Un eager loading intégré permettait d’éviter de rechercher en base plusieurs fois le même objet. On pouvait aussi réutiliser plusieurs fois la même vue. plus besoin de faire des assignations dans certaine action pour être sur que l’objet existe. Il suffit juste d’exposer l’objet. Après on l’utilise ou pas. De même l’utilisation des partials devient plus aisé car, on peux surcharger facilement des variables par l’usage des locals. J’y ai vu beaucoup d’intérêts.

Mais finalement cet intérêt n’existe que par l’usage de la méthode de class d’un controller helper_method. Si on crée soit même sa propre méthode avec son eager loading decent_exposure devient inutile.

decent_exposure a été pour moi un révélateur de l’utilité de la méthode helper_method. Mais à l’usage, je trouve qu’il fait finalement trop de chose caché si on utilise la méthode d’appel expose sans bloc. Je me suis ainsi retrouvé à faire des update_attributes 2 fois sur mon objet. Un dans le decent_exposure l’autre dans mon action. Forcement ça posait quelques soucis. Quand on sait que cela peut arriver, pas de soucis. Mais c’est toujours embêtant de perdre quelques heures à débugger le problème quand on le voit. Sans compter les fois ou on ne le voit pas.

Une des limitations de decent_exposure selon moi est l’override de cette méthode. Parfois pour éviter les if infini dans cette méthode il est plus judicieux de définir directement la valeur de retour de cette méthode dans sa méthode d’action. Cela permet de savoir exactement ce que retourne cette méthode, mais aussi d’éviter les conflits dans d’autre action.

Pour réalisé cela ma méthode stocke en mémoisation la variable d’instance égale au nom de la méthode. Ainsi ma méthode ressemble à ceci :

1
2
3
4

def post
  @post ||= Post.find(params[:id])
end
helper_method :post

Si je souhaite donc avoir un nouveau Post retourné par cette méthode j’ai juste à faire :

1
2
3

def new
  @post = Post.new
end

Je surcharge le retour de la méthode post par la valeur Post.new. Pour faire cela avec decent_exposure il faut surchargé la variable @_resource[:post]. Mais rien ne m’assure que ce nom de variable d’instance soit conservé dans les futurs version de decent_exposure. Une solution serait peut-être de créer une méthode post=() lors de l’exposition d’un post, mais cela devient peut-être moins pratique.

Voilà donc les raisons de mon arrêt d’utilisation de decent_exposure. Je peux très facilement émuler le comportement de decent_exposure et tout ça sans aucune dépendance externe.

Rabl la simplicité d’expression

Pour gérer ses vues en JSON ou XML, les gems classique sont JBuilder et XmlBuilder. Deux gems réalisées par DHH. Mais, personnelement, je les trouves assez verbeuses comme vues. A contrario, Rabl a une syntaxe trés simplifiée. On peux ausi avoir un système de partial qui permet une réutilisation compléte. Petit bonus par rapport à JBuilder/XmlBuilder est qu’il utilise la même vue pour générer du XML ou du JSON. Donc pas besoin de faire plusieurs vues en fonction du format de sortie.

Voici un example de vue Rabl :

1
2
3
4
5

object @post
attribute :content
child(:author) do
  attribute :firstname, :lastname
end

Tester sa vue Rabl

Pour tester le résultat de cette vue Rabl, deux possibilités s’offre à nous. Un test de la génération de la vue par un test d’intégration couplé avec le test du controller, soit un test de la vue. Finalement tester une vue Rabl c’est ni plus ni moins que tester un retour de la méthode #to_json. Donc si nous testons notre vue directement à partir des données passées, c’est plus rapide et plus unitaire.

Depuis la version 0.6.0 de Rabl, une méthode permet de générer la vue directement. C’est cela que nous allons utiliser pour faire notre test de vue.

Voici donc un test de notre vue ( défini dans spec/views/posts/show_rabl_spec.rb )

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

require 'spec_helper'

describe "blogs/show.rabl" do

    let(:auhor) { Author.new(:firstname => 'Cyril', :lastname => 'Mougel') }
    let(:blog) { Blog.new(:content => 'hello', :author => author) }
    let(:valid_json) {
      {
        :content => blog.content,
        :author => {
          :firstname => author.firstname,
          :lastname => author.lastname
        }
      }.to_json
    }

    let(:render) {
      Rabl.render(
        blog,
        'blog/show',
        :view_path => 'app/views'
      )
    }

    it 'should render valid_json' do
      render.should eql(valid_json)
    end

end

On obtient ainsi un test unitaire vraiment simple et une validation compléte du json obtenu. Le test est vraiment très rapide et n’est pas pollué par le test du controller.

J’ai par contre découvert des limitations à ce test car, on ne peux passer à la méthode #render que les objects définis par object ou collection. Si on veux tester une vue rabl qui utilise plusieurs variables, la tâche devient très hardu. J’ai donc commencé à proposer un Pull Request pour passer directement des variables dans sa vue Rabl, de la même méthode que les partials avec l’options :locals. Vous pouvez la suivre sur github

English translation

Mon évolution de la gestions des plugins vim.

Vim a une très grande quantité de plugins disponibles et il est très rapidement indispensable d’en utiliser plusieurs. La gestion des plugins est donc très importante. Au fil des années, j’ai changé de technique en fonction des possibilités apportées par vim ou par les développeurs.

Gestion manuelle

Au début, je gérais manuellement mes plugins en les ajoutant dans les dossiers correspondant. Je versionnais mon dossier .vim et .vimrc et je pouvais le faire évoluer globalement. Le soucis de cette technique est qu’il est pas forcement évident de gérer les mises à jour des plugins et leur installation n’est pas forcement simple car il faut mettre plusieurs fichiers à plusieurs endroits.

L’arrivée des vimballs

Dans une évolution de vim, il y a eu la possibilité de gérer des vimballs. L’avantage de cette technique est qu’on avait moins de problème lors de l’installation et on pouvait gérer un peu plus facilement les mises à jour car on savait rapidement quelle version on utilisait. Mais la encore il fallait allez régulièrement sur vimscript.org pour voir si nos plugins avaient changé de version. Chose que finalement on faisait très peu au final.

Gestion par git-submodule

Avec l’arrivée de github, les choses ont pu changer. Les plugins vim ont commencé à avoir un dépôt centralisé, on pouvait suivre directement l’évolution des scripts. Même vimscript a converti tous les plugins qu’il hébergeait en repository git. Maintenant on peux gérer tous ses plugins en faisant des mises à jour de repository git. J’ai ainsi commencé a gérer des submodule et des liens symboliques vers ces submodules. La mise à jour était automatique, mais l’installation devenait encore plus compliqué qu’avant.

Janus, la distribution vim

C’est alors que Yehuda Katz et Carl Lerche ont commencé à créer janus. Ce projet se veut comme une distribution de gestion de plugins vim. Il contient un jeu de tâche rake qui permette de mettre à jour facilement ses plugins. Un .vimrc est aussi fourni pour utiliser les plugins par défaut et ajouter une configuration minimal pratique. Ce projet est vraiment génial pour commencer à pratiquer vim. On peux ainsi avoir un jeu de plugins pratique et intéressant. Par contre, la gestion des versions de janus avec ses propres usage peux vite devenir compliquée. En gros c’est bien si on ne veut jamais modifier sa conf vim.

Pathogen, le premier plugin vim de gestions de ses plugins

Très peu de temps après Tim Pope ( très prolifique développeur de plugins vim ) a sorti Pathogen. Ce plugin permet de gérer directement la gestion de ses plugins dans son vimrc. J’avoue ne pas avoir trop regardé comment fonctionne ce plugin. On m’en a toute fois dit du bien. Il y a eu pas mal de projet pour que janus utilise pathogen typiquement.

Vundle, le bundler de vim.

Mais c’est là qu’on m’a parlé du plugin qui me semble le meilleur actuellement concernant la gestion de ses plugins vim, Vundle. Comme pathogen, la gestion des plugins est faite directement dans son vimrc. Son usage y est très simplifié et pratique. Si vous connaissez Bundler alors vous comprendrez facilement sont usage car il en est très inspirés.

Utilisation de Vundle

Installation de Vundle

Pour installer vundle, un simple clone du repository du projet et 2 lignes dans votre .vimrc suffisent.

1

git clone https://github.com/gmarik/vundle.git ~/.vim/bundle/vundle

1
2

set rtp+=~/.vim/bundle/vundle/
call vundle#rc()

Configuration de ses plugins

Pour utiliser vundle une fois installé. C’est extrêmement simple. il suffit d’utiliser la commande Bundle et le chemin de votre plugin. Ainsi pour installer le plugin vim-rails il suffit juste de faire :

1

Bundle 'tpope/vim-rails.git'

Installation de ses plugins

Ensuite, une fois votre vim lancé deux commandes vous suffisent. BundleInstall qui permet d’installer tous les plugins que vous avez définis et BundleInstall! qui permet de les mettre à jour.

Désormais ils ne vous reste plus qu’à trouver les plugins que vous souhaitez et les utiliser.

Mon vimrc

Si vous souhaitez découvrir mon usage de vim, mon vimrc est ainsi disponible sur github. Grâce à Vundle rien de plus simple que de le lire et découvrir rapidement les plugins vim que j’utilise.

English Translation

J’utilise dans mes déploiements monitrc pour le monitoring de mes scripts. Monit check un pidfile pour voir si le processus est actif ou pas.

J’ai donc cherché en Ruby quel était la meilleure solution pour que mon script soit un daemon et puisse générer lui-même son pidfile.

Le projet le plus connu est daemons. J’ai déjà essayé de l’utiliser, mais je n’en ai jamais été un grand convaincu. Je l’ai toujours trouvé compliqué. Il ne gére pas la génération de pidfile. Il faut donc pratiquement tout gérer soit même.

Le deuxième projet le plus connu est une sur-couche de daemons c’est daemon-kit. J’avais déjà tenté de l’utiliser, mais je le trouve vraiment trop rigide pour un simple script. C’est selon moi plus une massue qu’autre chose pour créer un daemon.

C’est alors que je me suis rappelé avoir entendu parlé d’un nouveau gem pour créer des daemons. J’ai cherché et j’ai ainsi pu découvrir dante. Ce projet est exactement ce que je cherchais. Il est simple et fait le boulot de créer un daemon.

Par défaut, il supporte quelques arguments à passer en ligne de commande. Ces arguments font l’essentiel du travail d’un daemon.

Voici une liste des arguments par défaut disponible.

1
2
3
4
5
6
7
8
9
10
11

-p, --port PORT           Specify port
                          (default: )
-P, --pid FILE            save PID in FILE when using -d option.
                          (default: /var/run/scheduler.pid)
-d, --daemon              Daemonize mode
-l, --log FILE            Logfile for output
-k, --kill [PORT]         Kill specified running daemons - leave
blank to kill all.
-u, --user USER           User to run as
-G, --group GROUP         Group to run as
-?, --help                Display this usage information.

On peux ainsi définir, le PID, le fichier de log, l’utilisateur et le group lançant le daemon ( si lancé en root ). Seul petit argument qui ne me semble pas essentiel, c’est l’argument du port. Mais l’usage initial de dante est de lancé des applications rack. Voila pourquoi on retrouve cet argument.

Une de ses autre fonctionnalités intéressantes est tout simplement le fait que l’on peux ajouter des options. Il peux donc aussi servir de gestion d’option pour son application.

Pour l’utiliser rien de plus simple. Il suffit de mettre votre script dans un block Dante.run

1
2
3

Dante.run('myapp') do |opts|
  myapp.run
end

Je suis vraiment impressionné par ce gem qui est issu de la société gomiso. Merci à elle de nous permettre d’avoir d’aussi bon gem.

English Translation

Le but de ce gem

Ce gem a été crée suite aux frustrations de l’équipe de développement de Mongoid qui a fait plusieurs fois des propositions de changement de design du driver officiel. Tous changement de design du driver a été refusé.

Thread-safe

Un des buts de ce gem est de permettre d’avoir un gem qui est le plus possible thread-safe. Le driver officiel mongoDB est parfois considéré comme non thread-safe notament par Mike Perham. C’est un vrai problème alors que la communauté ruby commence enfin à redécouvrir les threads. Cet état empêche par exemple l’usage de sidekiq avec MongoDB.

Suppression de l’extension

Avec le driver MongoDB officiel, il est très fortement conseillé d’installer le gem bson_ext sans celui-ci les performances sont beaucoup moins bonnes. Par contre cette extension étant écrite en C, elle est incompatible avec JRuby. Il a fallu créer une version JRuby du gem bson. Ça rend la maintenabilité plus complexe.

Dans le cas de moped, aucune extension C n’est à prévoir. Il est naturellement plus performant. Il arriverait même à être plus performant que l’extension C selon les benchmarks réalisés pour le projet.

Seul ombre au tableau, la génération d’un ObjectId est plus lente avec moped qu’avec le gem officiel bson selon un thread de la mailing-list de Mongoid. Mais cela pourra être améliorer par la suite, je n’en doute pas.

Une API plus simple

L’API de moped est vraiment plus belle que celle du gem mongo. Ce changement est bien sûr subjectif. Elle est beaucoup plus orienté ruby. Elle permet aussi la combinaison de recherche/mise à jour.

Meilleure gestion du replicat Set

Une des fonctionnalités principale de MongoDB est la gestion du replicatSet. Avec Moped, cette gestion devient vraiment plus souple et surtout ne lève plus d’exception la première fois que le node maître est down. Cette fois ci le basculement se fait automatiquement.

Plus besoin de passer la liste de vos nodes en configuration. Moped utilise directement les mécanismes de MongoDB pour découvrir les nouveaux nodes et ainsi les utiliser.

Les limitations

Par contre, moped a certaine limitation.

Ruby 1.9 uniquement

Moped n’est pas compatible avec Ruby < 1.9. Le choix de l’implémentation a été fait de ne pas être compatible avec les plus anciennes version de ruby.

Personnellement, je suis d’accord avec ce choix, car l’usage de ruby 1.8 doit disparaitre.

Pas de support de GridFS

GridFS n’est pas supporté nativement dans moped. Ce choix a été fait pour limiter le core du gem. Bien sûr rien n’empêche de créer une extension de moped gérant GridFS.

Intégration dans Mongoid 3

Mongoid 3.x utilisera désormais moped à la place du driver mongodb de 10Gen. Si vous souhaitez donc commencer un peu à l’utiliser essayer cette nouvelle version majeur de Mongoid.

Attention, Mongoid 3 n’est actuellement pas release. Si vous souhaitez l’utiliser il faudra utiliser la branche master de Mongoid. Le dévelopment y est toujours actif.

1

gem 'mongoid', :git => 'git://github.com/mongoid/mongoid'

English Translation

Ce gems ne fait pas grand chose, mais a de grand avantage quand on développe une application Rails (> 3.1) avec des assets en utilisant la technologie ‘asset_pipeline’.

Si c’est votre cas, vous vous êtes déjà rendu compte que chaques requêtes faites à votre application pour obtenir vos assets est logués dans votre fichier de log ( development.log en environement de dévelopment ). Des requêtes comme celle-ci :

1
2

Started GET "/assets/application.js?body=1" for 127.0.0.1 at 2012-02-13 13:24:04 +0400
Served asset /application.js - 304 Not Modified (8ms)

On se retrouve ainsi à devoir remonter dans son fichier de logs pour obtenir les logs qui nous interresse vraiment ( les log de la requête courante ). Notre fichier de log est vraiment pollué par ces assets si vous en avez comme moi beaucoup.

C’est là que quiet_assets devient vraiment interressant et pratique. Vous ajoutez ce gem dans votre Gemfile au niveau du groupe ‘development’ et tous vos logs d’assets disparaissent. Ils ne sont tous simplement plus logguées dans votre fichier de log. On retrouve ainsi un fichier de log rapide a consulter et moins pollué par des informations inutiles.

Comme quoi de tout petits gems peuvent nous rendre de grand service.

Edit du 27 Avril 2012

On pourrait se dire que cela pourrait être directement integré à Rails. Hélas cela à été fait en partie, mais pas complétement.

Depuis la version 3.2.x et l’issue 2639 nous pouvons configurer le logger de Sprockets. Mais il n’est pas seul à afficher les informations. Actionpack log toujours les requêtes faites pour obtenir ces assets. Vous ne pourrez donc pas avoir un fichier de log complétement épuré.

English translation

Pour éviter de perdre toutes les informations qui ont été mis dans basecamp, nous avons réalisé un import complet. Par contre, l’import ne comprend pas les fichiers qui ont pu être ajouté dans basecamp.

Pour ne pas perdre ces fichiers qui font parti du patrimoine de l’entreprise, j’ai créé un petit script pour télécharger tous ces fichiers.

Je vous le partage si vous en avez besoin un jour.

Dans ce script j’utilise Faraday pour faire le requêtage avec l’API et aussi télécharger les fichiers. Je suis personnellement un grand fan de Faraday. C’est selon moi la meilleure librairie de requêtage HTTP actuelle du monde Ruby. Utilisez la dès que vous avez besoin de faire du requêtage HTTP.

La documentation compléte de cette fonctionnalité est sur le site de mongoid.

Grâce à cette fonctionnalité, on peut définir tout simplement qu’un champs de Mongoid est localizable. La gestion de la locale est faite de manière très intelligente et surtout en complète coordination avec MongoDB.

Contrairement à une gestion de traduction dans une Base de donnée relationnelle, qui créé une table de liaison, Mongoid stocke un hash avec la locale comme clé et la traduction comme valeur.

Mongoid n’a plus qu’à faire la glue entre le système pour que les accès en lecture/écriture en fonction de la locale et la recherche

En gros faire plein de test comme si on jouait avec la prod mais sans toucher au donnée de production.

Le plus gros soucis que l’on rencontre et beaucoup d’entre nous l’ont rencontré, c’est l’envoi d’email. Tous les emails copié de la production sont valide et posséde un utilisateur au bout. Si nous envoyons un email réellement cela peut vite être problèmatique. Les solutions utilisées généralement sont les suivantes.

Remplacement de tous les emails de la base de donnée.

Une pratique simple est courant est la tâche qui remplace tous les emails de la base de donnée par des emails possédés par la société. Cette technique marche parfaitement, mais pose quelques problèmes :

• Il faut penser a toujours faire la modification après chaque copie de la base de production.
• Il faut mettre à jour son script pour remplacer tous les nouveaux champs qui posséde des emails si on en ajoute
• Il devient difficile de savoir à qui était réelement destiné l’email initial. On peux ainsi passer à coté de quelques bugs.

Ne plus contacter de serveur SMTP et créer un fichier par email

Avec le framework Ruby on Rails, il est possible de définir que tous les emails envoyés sont mis dans un fichier plutôt qu’envoyer par SMTP. Il suffit de définir un nouveau smtp_delivery

1

ActionMailer::Base.delivery_methods = :file

Cette technique permet d’être sûr qu’aucun email n’est envoyé au client finaux. L’inconvénient de cette technique est le stockage et la lecture des emails. Tous les emails sont stocké sous forme de fichier directement sur le serveur. Il peux donc être fastidieux de connaitre les nouveaux emails envoyés, car ils sont classé par destinataire. On peux ainsi ne pas constater qu’un email est envoyé sous certaine conditions. De même, si votre application est utilisé par des personnes n’ayant pas un accès shell à votre serveur, ils ne pourront pas lire les mails envoyés.

Le mock SMTP

Cette technique est selon moi la meilleure actuellement. Elle consiste tout simplement à emuler un vrai serveur SMTP. Par contre, ce serveur ne transmet pas les emails qu’il reçoit. Il les stocke et vous permet de les consulter dans un client mail classique. Ils sont conservé entièrement.

L’avantage est que n’importe qui peux consulter les emails générés, sans aucune connaissance technique évolués et ils sont conservé entièrement.

A ma connaissance, il existe 3 produits qui permettent cela.

• Mailcatcher
• Mailtrap.io
• MockSMTP.app

Mailcatcher

C’est un produit open source tres simple d’utilisation. Vous télécharger le gem, vous lancer la commande mailcatcher et c’est fini. Vous avez ainsi un serveur SMTP sur le port 1025 et un client mail sur le port 1080.

Je vous le conseille dans un environement de développement. Il a en plus quelques petits addons comme la notification growl.

Le seul soucis que j’ai rencontré avec est le deployement dans un environement de staging. la commande mailcatcher ne permet pas d’écouter sur toutes les interfaces. Il faut donc mettre un proxy devant pour le rendre accessible à tout le monde. On doit donc le maintenir et le gérer. Cela peux être un peu compliqué juste pour un simple mock. Bien sûr rien ne vous empêche de le faire.

Mailtrap.io

Voici un projet que j’ai découvert que très récement. Le concept est exactement le même que celui de mailcatcher, sauf que vous n’avez plus à gérer l’hébergement vous même. Tout est géré par railsware, l’éditeur de ce service.

Vous créer un compte sur leur site, vous créer un serveur SMTP fictif et c’est fini.

Vous obtenez les informations de connection à ce SMTP. Une fois que vous définissez ces paramètres dans votre application, tous les emails seront envoyé directement à Mailtrap.

Une gestion de collaboration sur les mailbox vous permet d’ajouter vos collaborateur à cette mailbox pour qu’ils puissent voir les emails.

Cette solution est vraiment simple a mettre en oeuvre et très pratique. Petit plus, c’est encore gratuit actuellement. Donc profitez en.

Le 21 Juin se tiendra à Paris un événement auquel je vous invite à venir. Cet événement sera dédié à MongoDB, le MongoFR.

J’ai la chance de pouvoir proposer une petite conférence sur un retour d’expérience : ma migration de SQL à MongoDB sur Oupsnow. Hormis les développeurs de 10Gen, il n’y aura que des Rubyists.

Selon moi, cette nouvelle technologie qu’est MongoDB est assez prometteuse.

Pour découvrir MongoDB, venez nombreux le 21 Juin !

English translation

J’ai donc commencé à regarder un peu dans quels cas utiliser EventMachine. La première application que j’en ai trouvé c’est tout simplement le PeriodicTimer.

Son utilisation la plus simple est le remplacement d’une cronjob.

Je m’explique : une cronjob est vraiment une très bonne chose. On peut définir très précisément l’heure à laquelle on souhaite qu’une tâche s’exécute. Celle-ci s’exécute alors à ce moment précis. Cron est vraiment un outil magnifique. Cependant, dans le cas d’une tâche récurrente qui doit être effectuée régulièrement, l’utilisation d’un cronjob peut avoir un gros inconvénient.

Cron n’a aucune gestion de queue. Ainsi on peut se retrouver très simplement avec une quantité astronomique de tâches essayant de s’exécuter en même temps. Votre « load » explose et il faut redémarrer votre serveur. Bien sûr cela n’arrive que si vous lancez une tâche plus fréquemment que son temps d’exécution.

La seule solution serait d’avoir une petite application - comme : jobq - qui gére pour vous un système de queue. Bien sûr, si le fait d’avoir une queue ne sert strictement à rien, cette solution peut être un peu overkill.

L’avantage de PeriodicTimer est que les tâches sont exécutées après un temps défini. Il n’y a aucune gestion d’heure de lancement. Il y a juste un lancement de la tâche après X secondes une fois que la précédente tâche est finie et qu’aucune autre tâche ne soit en cours d’exécution. Cela entraîne effectivement un glissement progressif de l’heure de lancement. Mais globalement, ça ne pose aucun problème. L’important est que la tâche soit exécutée régulièrement. C’est le cas, par exemple dans le cas de récupération de statistique.

Voici un exemple de code qui utilise PeriodicTimer

1
2
3
4
5
6
7
8
9
10
11
12

require 'eventmachine'
require 'timeout'
EventMachine.run {
 EventMachine::PeriodicTimer.new(10) do
   puts "#{Time.now} : I am 10"
   sleep 10
 end

 EventMachine::PeriodicTimer.new(1) do
   puts Time.now
 end
}

Voici la sortie qui est effectuée si on lance l’application pendant 50s.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

$ ruby em_periodic.rb
Fri Mar 26 16:07:39 +0100 2010
Fri Mar 26 16:07:40 +0100 2010
Fri Mar 26 16:07:41 +0100 2010
Fri Mar 26 16:07:42 +0100 2010
Fri Mar 26 16:07:43 +0100 2010
Fri Mar 26 16:07:44 +0100 2010
Fri Mar 26 16:07:45 +0100 2010
Fri Mar 26 16:07:46 +0100 2010
Fri Mar 26 16:07:47 +0100 2010
Fri Mar 26 16:07:48 +0100 2010 : I am 10
Fri Mar 26 16:07:58 +0100 2010
Fri Mar 26 16:07:59 +0100 2010
Fri Mar 26 16:08:00 +0100 2010
Fri Mar 26 16:08:01 +0100 2010
Fri Mar 26 16:08:02 +0100 2010
Fri Mar 26 16:08:03 +0100 2010
Fri Mar 26 16:08:04 +0100 2010
Fri Mar 26 16:08:05 +0100 2010
Fri Mar 26 16:08:06 +0100 2010
Fri Mar 26 16:08:08 +0100 2010
Fri Mar 26 16:08:08 +0100 2010 : I am 10
Fri Mar 26 16:08:18 +0100 2010
Fri Mar 26 16:08:19 +0100 2010
Fri Mar 26 16:08:20 +0100 2010
Fri Mar 26 16:08:21 +0100 2010
Fri Mar 26 16:08:22 +0100 2010
Fri Mar 26 16:08:23 +0100 2010
Fri Mar 26 16:08:25 +0100 2010
Fri Mar 26 16:08:26 +0100 2010
Fri Mar 26 16:08:27 +0100 2010
Fri Mar 26 16:08:28 +0100 2010
Fri Mar 26 16:08:28 +0100 2010 : I am 10

On peut constater que la tâche qui doit s’exécuter toutes les secondes le fait bien. Par contre la tâche qui s’exécute au bout de 10 secondes effectue un lock sur le thread. Ainsi la tâche qui s’exécute toutes les secondes attend que le lock soit libéré. Une fois terminée, l’exécution de la tâche toutes les secondes recommence. La tache qui doit s’exécuter toutes les 10 secondes attendra, quand à elle, 10 nouvelles secondes après avoir été terminée.

C’est là une grande puissance de PeriodicTimer. On a facilement une succession de tâche qui ne se marchent jamais sur les pieds. Désormais, je n’utilise plus que

cette solution pour créer des scripts de récupération de données.

Les nouveautés

• Ajout d’un filtre sur la recherche des tickets pour ne voir que les tickets fermé ou non
• Possibilité d’éditer une milestone pour les admin d’un projet
• Possibilité de définir une milestone comme actuelle. Par défaut, c’est la première milestone créée
• Possibilité de récupérer son password par email
• Possibilité de rester connecter avec un remember_me
• Ajout d’information concernant le nombre de tickets filtrés ou vues
• Possibilité pour chaque utilisateur loggé de suivre un ticket. Un utilisateur qui suit un ticket recevra ainsi à chaque mise à jour de ce ticket un email concernant cette modification.
• Les utilisateurs ne peuvent plus changer leur email.

Enfin comme d’habitude voici mon fichier capistrano de déployement pour faciliter celui-ci.

Ficher de déployement capistrano

<typo:code lang=”ruby”> set :application, “oupsnow” set :repository, “git://github.com/shingara/oupsnow.git” set :domain, “dev.shingara.fr”

If you aren’t deploying to /u/apps/#{application} on the target

servers (which is the default), you can specify the actual location

via the :deploy_to variable:

set :deploy_to, “XXXXXXXXX”

If you aren’t using Subversion to manage your source code, specify

your SCM below:

set :scm, :subversion

set :scm, :git set :git_enable_submodules, 1

set :runner, “xxxx” set :user, “xxxx” set :use_sudo, false

set :thin_conf, “/etc/thin/#{domain}.yml”

set :rails_env, “production”

role :app, domain role :web, domain role :db, domain, :primary => true

task :update_config, :roles => [:app] do run “ln -s #{shared_path}/config/database.yml #{release_path}/config/database.yml” run “ln -s #{shared_path}/config/email.yml #{release_path}/config/email.yml” run “ln -s #{shared_path}/config/initializers/errornot.rb #{release_path}/config/initializers/errornot.rb” run “cd #{release_path} && echo ‘GOOGLE_ANALYTICS="XXXXXXXX"’ >> config/environment.rb” end

namespace :deploy do task :start, :roles => [:app] do

run "thin -C #{thin_conf} start"

end

task :stop, :roles => [:app] do

run "thin -C #{thin_conf} stop"

end

task :restart, :roles => [:app] do

run "thin -C #{thin_conf} restart"

end end

task :update_db do run “cd #{current_path} && RAILS_ENV=#{rails_env} rake db:update” end

after “deploy:update_code”, :update_config after “deploy:symlink”, :update_db </typo:code>

English translation

Tout le monde est en droit de se poser la question. Voici donc, pour moi, l’avantage de Ruby par rapport aux autres technologies à l’heure actuelle.

Ruby c’est fun

Matz, quand il a créé Ruby, a voulu faire un langage fun avec lequel il pourrait s’amuser à coder. Aujourd’hui tous les développeurs Ruby diront à peu près la même chose. Coder en Ruby est plaisant. L’avantage de ce point est qu’un développeur Ruby est plus détendu. Un développeur détendu est un développeur plus heureux. Un développeur plus heureux est motivant pour une équipe. Un développeur heureux essayera de faire son travail proprement. L’ambiance d’une équipe de développeur Ruby peut ainsi être agréable. Moins de stress sur un projet, c’est un projet qui part avec un peu plus de chances de réussir.

Ruby aime les tests

La communauté Ruby actuelle est convaincue de l’utilité des tests unitaires. Ainsi, chaque librairie est poussée par la communauté à avoir des tests. Beaucoup de développeurs, moi y compris, privilégierons une librairie avec des tests unitaires plutôt qu’une sans aucun tests.

Cette philosophie permet d’avoir un environnement de développement de test simplifié directement dans Rails. Pas besoin de se prendre la tête pour faire des tests. Si vous ne faites pas de tests de base : soit vous ne voulez pas en faire, ce que je ne recommande pas, soit vous le faites exprès.

Ruby aime le cloud

En ce moment, l’évolution logique du net est le Cloud Computing. L’idée du Cloud Computing est simple. Nos sites internet ne sont plus hébergés sur une seule machine. Les services sont séparés pour améliorer la scallabilité. Au sein de la communauté Ruby, les développeurs sont très attachés à cette idée. Ainsi beaucoup d’utilitaires pour gérer et utiliser son cloud commencent à voir le jour comme Chef. L’architecture même de Rails permet de facilement sortir de Ruby On Rails pour ainsi utiliser son Cloud. ActiveRessource en est la preuve.

Mais coder dans un Cloud implique de coder plusieurs briques. Le Ruby a des bindings pour tous ces utilitaires, comme les systèmes de queues ou les bases de Données Non-Relationnelle. Je ne dis pas que les autres ne peuvent pas le faire. Mais là encore c’est un effet de groupe. Chaque développeur ruby a envie de jouer avec un Cloud. On pense de plus en plus en cloud.

Les plugins de Rails

Ruby On Rails possède une très grande quantité de plugins. On peut ainsi facilement trouver la petite brique que l’on cherche pour sa propre utilisation. C’est plus que l’utilisation d’un module Drupal. Car là nous sommes dans un environement facilement modifiable et sans aucune limitation. Chose que Drupal peut vite avoir.

Les Ressources

Le plus grand reproche que l’on fait actuellement au choix de Ruby On Rails, c’est le manque de ressources. Effectivement, les ressources de développeurs Ruby sont plus faibles que pour d’autres langages. Mais ceci est selon moi un faux problème. L’apprentissage de Ruby et Ruby On Rails est assez simple si on connait la logique Objet. Ainsi, n’importe quel développeur Java peut tout à fait se mettre à Ruby et Ruby On Rails. Donc avec un expert Ruby/Rails, on peut former facilement une équipe complète et compétente.

Cet argumentaire n’engage bien sûr que moi et peut donc être sujet à caution.

Donc qu’est ce que j’attends dans une offre d’emploi ?

• Le nom de l’entreprise :
  

  Le nom de l’entreprise est toujours pratique ne serait-ce que pour zapper l’annonce si on aime pas cette entreprise. Ou alors rigoler encore plus en lisant l’offre d’emploi.

• Le cœur de métier de l’entreprise :
  

  C’est toujours agréable de savoir si on va travailler pour une entreprise qui fait du beurre ou des sites Web. On peut ainsi éviter certains entretiens inutiles.

• Le nombre de développeurs dans l’entreprise :
  

  C’est une question plutôt inhabituelle pour un recruteur, mais avoir cette information permet de savoir tout de suite si on sera le geek dans son coin qui sera interrompu pour faire de l’assistance Words alors qu’il n’a plus touché à un windows depuis 3 ans. Au contraire, si on voit qu’il y a une majorité de développeurs, on pourra se dire que ça sera la fête aux trolls. Un développeur aime les Trolls \o/.

• Les personnes connues :
  

  Comme dans tous métiers, on connaît certaines personnes de réputation. Cela peut facilement aider un développeur à choisir cette offre d’emploi si une personne connue y est. En revanche, c’est aussi à double tranchant. Certains feront l’entretien juste pour voir cette personne. D’autres zapperont encore plus l’offre d’emploi à cause de cette même personne.

• L’environnement de travail :
  

  L’OS utilisé en majorité par les développeurs de la société peut être un très bon indicateur parfois. Typiquement chez AF83 où je travaille encore en ce moment, tous les développeurs sont sous UNIX, soit GNU/Linux, soit MacOSX. Pour beaucoup, cela prouve la qualité des développeurs. Et là encore la guerre aux trolls pourra facilement être ouverte.

• La contribution Open source possible et faite par l’entreprise :
  

  Avoir du temps pour faire de l’Open Source selon notre désir est un plus non négligeable selon moi. J’ai énormément de projets open source en cours que je fais en parallèle de mon emploi, mais si je pouvais les faire aussi durant une partie de celui-ci, je serais vraiment heureux. Ensuite le fait que la société produise du code Open Source, peut facilement permettre au développeur de jauger de la qualité du code de cette société. En effet, pourquoi est-ce toujours la société qui doit vérifier le code de ses futurs employés ?

Selon, moi ces 6 points ne sont hélas pas toujours renseignés dans une offre d’emploi et cela serait un plus non négligeable.

A chaque release, une nouvelle admin fait son apparition, mais à chaque fois elle est meilleure que la précédente, donc c’est une excellente chose.

J’ai bien-sûr mis à jour ce blog et j’ai aussi switché sur le nouveau thème par défaut. Je suis toujours aussi nul en design.

En petit cadeau, voici mon fichier capistrano que j’utilise pour déployer ce blog. Ça peux toujours vous servir. On ne sait jamais.

English Translation

Cette nouvelle version, outre son refactoring comprend aussi l’ajout de quelques nouvelles fonctionnalités.

• Ajout d’un filtre par Status dans la recherche de ticket
• Ajout de la possibilité de changer la fonction de tous les membres d’un project
• Ajout de la preview des tickets et commentaires sur les tickets
• Ajout de la visualisation de la milestone courante dans la visualisation d’un ticket
• Possibilité d’ordonner tous les champs de recherche dans la vue des tickets
• Login par l’email et plus par le pseudo

Vous pouvez télécharger cette version sur rubyforge

Si vous souhaitez tester cette version, une version de demo de oupsnow est en ligne. Les login/mdp sont : admin@admin.com/oupsnow. Amusez vous bien.

Il suffit d’inclure Devise::TestHelpers. Ensuite pour se logger avec un utilisateur, on utilise la méthode sign_in. La méthode sign_out existe aussi.

Le plugin d’authentification le plus connu à l’heure actuel est Authlogic. Ce plugin est vraiment très performant, mais tous les essais de le rendre ORM Agnostique ont été vain. C’est alors qu’au même moment, durant le Rails Summit 2009, George Guimarães et Carlos Antonio annoncent la sortie de Devise, un plugin Rails au dessus de Warden ( Rack middleware d’authentification). C’est exactement, ce qu’il me faut, un nouveau système d’authentification a tester et peut-être une possibilité d’ajouter une couche d’ORM Agnostique dedans. En plus Warden étant un RackMiddleware, je pourrais un peu tester ce que ça donne.

J’installe donc Devise et commence à l’utiliser dans Oupsnow. Tout se passe à merveille, jusqu’au moment où il faut faire les tests. Tout de suite le bât blesse. Les tests controlleurs de Rails ne communiquent pas avec la couche Rack qui n’est pas initialisée. On se retrouve donc avec une impossibilité de définir si un utilisateur est loggé ou non et si oui, qui est cet utilisateur.

Après de nombreux tests et essais. J’ai fini par trouver comment faire. Warden ajoute à la requête une variable d’environment dans la requête. On peux y accéder par request.env['warden']. Il suffit donc de remplir cette variable.

Pour avoir un utilisateur non loggé, il faut faire :

Pour se logger avec un utilisateur en particulier il faut faire :

Personnellement, j’aime beaucoup devise. A tel point que j’ai permis de le rendre ORM Agnostique et compatible avec MongoMapper.

EDIT du 30 Novembre 2009: la technique indiquée ici n’est pas optimum et ne marche pas avec les dernières versions de Devise. utilisez plutôt la technique décrite dans mon ticket Comment tester devise ? réélement ?

Alors que je finissais une migration de SQL à MongoDB, j’en entame une nouvelle. Celle-ci beaucoup plus profonde.

La raison de ma migration ?

Rails 3. En effet, depuis Décembre 2008, soit presque un an, Merb s’est figé. Certain me diront que la communauté Merb est en train de revivre et c’est tout à fait vrai. J’en suis même ravi. Mais Merb a pris un immense retard en presque un an. Même si Rails n’a pas vraiment avancé dans sa version stable, sa version Edge a elle énormément avancée.

Voulant toujours tester les nouvelles technologies en Ruby, je voudrais tester Rails 3. Mais aucun système n’existe pour passer de Merb à Rails 3. Un rapide test m’a montré que la différence était par contre minime entre Rails 2.3.x et Rails 3. La migration de Rails 2.3.x à Rails 3 en sera donc d’autant plus simple.

Voulant vraiment sortir une version stable le plus vite possible, j’ai donc pris la décision de migrer Oupsnow vers Rails 2.3.x pour ensuite migrer sur Rails 3 pour cette fois sortir une version de Oupsnow compatible Rails 3.

Oupsnow devient donc un projet Rails/MongoMapper et non plus Merb/DataMapper comme sa dernière version. Toute aide est bien-sûr la bienvenue.

English translation