Sous ce titre primesautier se dissimule un problème idiot rencontré hier soir sur le développement de Typo que j’aurais certainement résolu plus rapidement sans un abus de mojitos.

Je voulais modifier la manière dont Typo transforme les URL en liens permanents en supprimant les caractères spéciaux et accentués. J’ai donc fait le bout de code suivant :

L’adage pas de nouvelles, bonnes nouvelles n’a pas vraiment sa place dans l’univers open source, bien au contraire. Et malgré un nombre de commits particulièrement faible durant le mois d’août, ne croyez-pas que Typo, le blogware en Ruby on Rails soit mort, bien au contraire. Piers et moi continuons de travailler dessus durant notre temps libre, si tant-est qu’on daigne nous en laisser.

Un dernier week-end d’août plus chargé qu’une prévision Bison Futé nous apporte un lot de nouveautés comme on n’en avait pas vues sur le projet depuis bien longtemps. Je pense évidemment à la fermeture d’une quarantaine de tickets dont un bon nombre de bugs qui nous permet de passer sous la barre des 200 tickets ouverts pour la première fois depuis que j’ai repris le projet, mais pas seulement.

Comme je vous le disais vendredi, nous avons offert à l’administration de Typo une refonte graphique complète. Plus belle, plus propre, et aussi beaucoup plus simple à utiliser que l’ancienne, cette nouvelle version se trouve déjà dans la version de développement de l’application. Nous sommes toutefois conscients du travail qu’il nous reste à effectuer afin d’atteindre les standards d’utilisabilité et d’ergonomie auxquels nous aspirons à ce jour. Cette administration refondue est d’ors et déjà disponible sur notre plate-forme de démonstration.

Jordan Bracco travaille actuellement sur un portage du template Classicish vers un thème Typo. Le but de ce thème est de remplacer Scribbish, notre actuel thème secondaire, par quelque-chose d’un peu plus sexy. Jordan a déjà contribué à Typo par le passé, en portant notamment Hemingway et Kubrick à la version 4.1. Ces deux thèmes devraient rapidement rejoindre notre collection officielle. Dans la même veine, nous sommes également à la recherche d’un nouveau design afin de remplacer Azure, le thème par défaut, quelque peu démodé.

Et pour finir…

Je travaille toujours sur l’ajout d’un système de profils utilisateurs multiples (administrateur, rédacteur et contributeur) extensible. Je devrais mettre ma dernière semaine de vacances à profit afin de terminer cette importante fonctionnalité. On nous a rapporté des problèmes de performances importants survenus depuis la sortie de la 4.0. Il semble que le nouveau système de cache utilisé soit beaucoup plus lent et plus gourmand que l’ancien. Après quelques tests concluants (économies de 40% de mémoire et division par 3 des temps de réaction), nous sommes revenus à l’ancien système. La liste des convertisseurs s’allonge, et vous pouvez maintenant passer de Dotclear 1.2 à Typo. Jordan travaille également sur un convertisseur depuis Mephisto, qui devrait rapidement rejoindre le coeur de l’application (comment ça je te mets la pression ?).

Enfin, dernière nouvelle, mais pas la moindre, j’ai profité de mes insomnies afin d’offrir au projet un nouveau site officiel, en utilisant un Typo à peine modifié comme un CMS. Nous travaillons maintenant à transférer toute la documentation utilisateurs du Trac vers ce nouveau site dont je ne manquerai pas de parler au moment du lancement officiel.

Ceux qui se disent qu’une version majeure de l’application est sur le point de sortir ne sont pas forcément loin de la vérité.

Note : vous pouvez lire une version anglaise de ce billet sur le blog officiel de Typo.

Les deux animateurs de Railsenvy remettent le couvert avec leurs parodies des films publicitaires d’Apple comparant Ruby on Rails à ses concurrents. À ceux qui leur reprochaient de comparer un framework à des langages, réjouissez-vous, ils vous ont écouté et égratignent cette fois Cake PHP dans un spot qui s’avère être de loin le meilleur de la série.

À mourir de rire… sauf peut-être pour les fans de Cake PHP.

Afin de fêter dignement la rentrée, Typo, le blogware open source développé en Ruby on Rails fait peau neuve et se dote d’une nouvelle interface d’administration beaucoup plus claire et au goût du jour. Ce design devrait équiper la version 5.0 qui devrait sortir d’ici quelques semaines et apporter de nombreuses nouveautés ainsi qu’un très grand nombre de correctifs.

L’interface de configuration.

Liste des billets en cours.

Zone de saisie d’un billet.

Cette nouvelle admin est d’ors et déjà disponible dans la version de développement de Typo, et vous pouvez la tester sur notre plate-forme de démonstration.

J’ai rejoint l’équipe de développement afin de m’occuper de l’utilisabilité de l’application, et beaucoup de progrès ont été faits malgré le chemin encore à parcourir. Nous devrions revenir très rapidement avec deux nouveaux design prévus pour remplacer les deux thèmes actuels un peu démodés. Stay tuned! comme ils disent.

La derniere keynote de Steve Jobs, la grande messe des zélotes de la Pomme a semble-t-il déçu bien des âmes pourtant toutes dévouées à la firme de Cupertino. Certes, Léopard est amusant avec ses effets visuels à tout va, et l’intégration de ZFS est une excellente nouvelle. Mais on en ressort tout de même de là avec une étrange insatisfaction, comme s’il avait manqué la killer app, ou la killer feature que tout le monde attendait. Au point de voir de nombreux blogueurs anglophones ne pas hésiter à affirmer que la keynote a perdu sa magie, comme si la seule mission d’Apple était de révolutionner les nouvelles technologies tous les six mois !

Qu’est-ce qui a bien pu décevoir à ce point les aficionados ? Certainement pas la sortie de Léopard, ni celle de Safari sous Windows, pied de nez en direction de Redmond et du défunt Internet Explorer 5.2. Pour comprendre l’ire des Mac Users, il faut se tourner vers le nouvel iPhone, et son absence – apparemment – de SDK. Ce que j’ai pu lire un peu partout sur le web à ce propos se résume à : Apple aurait pu révolutionner la téléphonie et l’informatique en sortant un téléphone ouvert pour lequel chacun aurait pu développer – et vendre – des applications spécifiques tirant partie de l’écran tactile et des spécificité de l’engin. C’est également le sentiment que nous partagions chez Actualys en septembre dernier lorsque nous discutions avec passions des premières rumeurs surgies autour de l’iPhone. Ce n’est plus mon sentiment aujourd’hui.

La réponse de Steve Jobs à ses détracteurs est cinglante, géniale, et, comme souvent, en avance sur son temps. Vous voulez développer – et vendre – des applications pour l’iPhone ? Rien de plus simple, rendez vos applications web compatibles avec Safari, rien de plus. Le SDK de l’iPhone, c’est du HTML, du Javascript et un peu de Flash, en un mot ce web que nous utilisons quotidiennement. Ce n’est pas nouveau, je suis un fervents partisan du web mobile et de l’ubiquité pour tous. Pas immédiatement, les opérateurs, les terminaux et les usages ne sont pas encore à niveau, et pas forcément de la manière dont on tente de le faire aujourd’hui – transposer ce qui doit s’afficher sur un écran de 17 pouces sur un téléphone – mais dans un futur proche, certainement. Avec Safari, l’iPhone met la barre très haut, et je suis vraiment impatient de pouvoir le tester pour le comparer à Opéra Mini.

Quant au SDK si âprement demandé, il existe, il est gratuit, multi plates-formes, convivial et installé par défaut sur Léopard (et ça pour une bonne nouvelle…) Il s’appelle Ruby on Rails.

Vous êtes un webdesigner ou graphiste de talent, et vous avez envie de vous faire un nom sur le web sans (trop) d’efforts tout en offrant quelques heures de votre temps à un projet open source motivant et motivé ? Cela tombe bien, l’équipe de Typo, le blogware en Ruby on Rails a besoin de vous, et plutôt deux fois qu’une !

Dans le cadre de la préparation de sa prochaine version majeure, Typo est à la recherche d’une bonne volonté pour le remettre graphiquement à neuf façon pub Bio de Danone : ce qu’il fait à l’intérieur doit aussi se voir à l’extérieur. Pour cela, nous avons besoin de deux choses.

Un nouveau thème par défaut

Azure, le thème par défaut de Typo a fait son temps, et il nous faut maintenant passer à autre chose d’un peu plus actuel, tout en restant à la portée du grand public. Étant la première chose que le futur utilisateur voit, le thème par défaut est fondamental, et les features et benefits (cherchez pas, c’est une private joke) de la prochaine version justifient très largement cette refonte.

Les contraintes du projet :

• Un thème sur deux colonnes, le menu à droite.
• Un design fluide – au moins jusqu’à une certaine largeur.

Un nouveau thème pour l’admin

L’administration de Typo (login et password : admin) laisse graphiquement à désirer alors qu’un gros travail a déjà été fait sur l’utilisabilité de la chose, et là aussi, une refonte graphique est plus qu’indispensable. Nous avons bien conscience que les zones d’administration ne sont pas la partie vue du grand public et permettant d’améliorer son Page Rank, et que cette partie du site est beaucoup moins attirante, mais nous ne pouvons malheureusement pas rétribuer qui que ce soit pour ce travail : Typo ne nous rapporte pas d’argent – il aurait même tendance à m’en coûter – et nous travaillons dessus bénévolement. La personne qui accepterait de prendre cette partie en charge le ferait donc pour l’amour de l’art

Plusieurs personnes se sont plaintes de la lenteur des dernières versions de Typo, le blogware en Ruby on Rails, sans que quoi que ce soit dans le code puisse justifier de tels problèmes de performances.

La solution a été trouvée un peu par hasard par Mathijs van Zuijlen : une ligne mal formée forçait le cache à fonctionner en mode testing, ce qui signifiait au final pas de cache du tout. Incidemment, cela empêchait également l’envoi parallèle des trackbacks au moment de la publication d’un billet.

Si vous utilisez la version de développement, la correction est présente dans le Changeset 1477.

Si vous utilisez la version stable de l’application, il vous suffit de commenter la première ligne du fichier vendor/memcache-client/lib/memcache.rb.

$TESTING = defined? $TESTING

Puis, redémarrez Typo.

Je n’ai pas pour habitude de traduire les textes d’autrui, je ferai une exception pour cette fois sans rien y ajouter ni retrancher. D’abord parce que je ne vois pas ce que je pourrais dire de plus, ensuite parce que l’esprit même du texte rentre pour une bonne partie dans son intérêt, enfin parce que Rails manque trop de bonnes documentations en français, et que celle ci vaut le déplacement.

Ceci est la traduction de Ruby on Rails rake tutorial, de Greg Pollack.

Si vous développez en Ruby on Rail, vous avez certainement utilisé l’utilitaire Rake afin de lancer les tests, ou pour mettre à jour votre base de données en lançant rake db:migrate. Mais avez-vous vraiment conscience de ce qui se passe lorsque vous lancez une tâche Rake ? Savez-vous qu’il vous est possible de créer vos propres tâches rake, ou même de créer votre propre librairies de ces si pratiques descripteurs de tâches ?

Voici quelques cas d’usages des tâches Rake :

• Récupérer une liste d’inscrits afin d’envoyer un email.
• Lancer des traitements de calcul et de statistiques pendant la nuit.
• Supprimer et régénérer le cache d’une application.
• Sauvegarder ma base de données et mon dépôt subversion.
• Exécuter n’importe quel traitement de données.
• Me saouler la gueule.

Dans ce billet, vous allez découvrir le pourquoi de l’existence de Rake, et comment il peut vous aider dans le développement de vos applications Rails. À la fin de cette lecture, vous devriez être capable de créer vos propres tâches et de finir bourré comme un coing grâce à Rake en seulement trois petites étapes.

Pourquoi faire un retour en arrière ?

Pour comprendre les origines de Rake, il convient de s’intéresser un peu à son vénérable ancêtre, j’ai nommé Make.

Je vous propose un voyage dans le temps, à l’époque où le code devait obligatoirement être compilé, c’est à dire avant que l’iPhone et les langages interprétés ne parcourent la planète.

À cette époque, quand vous téléchargiez un logiciel, vous obteniez généralement des fichiers contenant le code source et un script shell. Ce script contenait tout ce que votre machine avait besoin de savoir afin de compiler, lier et construire votre application. Vous lanciez install_me.sh, chacune des lignes du fichier était exécutée, et vous obteniez au bout d’un moment un exécutable.

Ça marchait plutôt pas mal, il faut l’avouer, à part peut être pour les quelques développeurs de l’application. Chaque fois qu’ils changeaient la moindre ligne de code, il leur fallait relancer le script afin de tout recompiler. cela prenait évidemment un temps fou pour les gros logiciels.

En 1977, Stuart Feldman des laboratoires Bell inventa Make, qui résolut la majorité des problèmes liés aux compilations à répétition. Make est également utilisé afin de compiler des programmes, mais avec deux différences majeures :

1. Make est capable de reconnaître quels fichiers ont été modifiés depuis la dernière compilation. Il pouvait donc ne compiler que ce qui avait changé d’une fois sur l’autre. Autant dire que cela a dramatiquement réduit les temps de compilation.
2. Make peut aussi résoudre les dépendances. Il sait que pour être compilé, le fichier A a besoin du fichier B, qui lui-même a besoin de fichier C. Ce qui fait que si Make tente de compiler le fichier source A et que le fichier source B n’a pas été compilé, il commence par traiter ce dernier.

Je ne devrais pas continuer sans vous expliquer que Make est un simple exécutable, un peu comme “ls”, ou “dir”, et qu’il a besoin pour fonctionner d’un fichier annexe, appelé un “makefile”, qui va contenir toutes les sources et les dépendances du programme à compiler. Les “makefiles” ont leur propre syntaxe cabalistique qu’il ne nous sera pas donné de voir ici.

Au fur et à mesure, Make a évolué, et on a commencé à l’utiliser pour d’autres langages. En fait, de nombreux développeurs Ruby l’utilisaient avant l’avènement de Rake.

“Mais, Ruby n’a pas besoin d’être compilé, alors à quoi ça sert ?”. Vous ne l’avez peut-être pas dit, mais vous l’avez certainement pensé très fort.

Oui, je suis d’accord, Ruby est un langage interprété, et nous ne compilons pas notre code. Alors pourquoi utiliser Make ?

Eh bien, pour au moins deux raisons fondamentales :

1. Automatiser des tâches : toute application d’envergure se termine presque fatalement par l’écriture de scripts à lancer en ligne de commande, qu’il s’agisse de lancer une maintenance, supprimer un cache ou faire évoluer la base de données. Et au lieu de créer une dizaine de petits scripts shell, ou un gros, vous pouvez aussi créer un seul “Makefile” dans lequel vous organiserez les choses à faire en tâches. Vous pouvez ensuite exécuter les tâches en lançant “make stupid”, c’est à dire littéralement “fait l’imbécile”, et cela lance la tâche “stupid”.
2. Vérifier la résolution des dépendances entre les tâches. Quand vous lancez des opérations de maintenance en chaîne, vous en répétez fatalement certaines d’une tâche à l’autre. Par exemple, migrer une base de données et en faire une extraction ont toutes deux une connexion à la base pour prérequis. Vous pouvez donc créer une tâche de connexion qui sera lancée juste avant la migration.

Et Rake, dans tout ça ?

Il y a quelques années, Jim Weirich utilisait régulièrement Make sur un projet en Java. Tout en travaillant sur son Makefile, il réalisa combien il lui serait pratique d’avoir des bouts de Ruby dedans. Et Rake était né.

Jim donna à Rake la possibilité de réaliser des tâches, résoudre les dépendances, et même éviter de recommencer des tâches qui avaient déjà été réalisées. C’est évidemment quelque-chose que nous ne faisons pas vraiment, puisque Ruby n’est pas un langage compilé.

Comment ça marche ?

Imaginons que je veuille me saouler la gueule, quelles en seraient les étapes ?

1. J’irais acheter à boire.
2. Je me servirais à boire.
3. Je boirais jusqu’à plus soif.

Si je voulais utiliser Rake pour chacune de ces tâches, je créerais un fichier nommé Rakefile, qui contiendrait quelque-chose comme ça :

task :acheteABoire do
  puts "Et hop, une bouteille de vodka"
end  

task :sersMoiUnVerre do
  puts "Mi vodka, mi Redbull"
end

task :ceSoirJeBois do
  puts "Wow, y'a du brouillard ce soir. Ggggarçon – hips – un autre !"
end

Je peux maintenant lancer ces tâches depuis le répertoire où se trouve mon Rakefile, comme ça :

$ rake acheteABoire
 Et hop, une bouteille de vodka
$ rake sersMoiUnVerre
 Mi vodka, mi Redbull
$ rake ceSoirJeBois
 Wow, y'a du brouillard ce soir. Ggggarçon – hips – un autre !

Sympa non ? Malheureusement, je ne vérifie pas que les tâches sont effectuées dans le bon ordre. Et bien qu’il puisse m’arriver de souhaiter être bourré avant d’avoir commencé à boire, ou même avant d’avoir acheté quoi que ce soit, ce n’est évidemment pas possible.

Rake et les dépendances

task :acheteABoire do
  puts "Et hop, une bouteille de Vodka"
end

task :sersMoiUnVerre => :acheteABoire do
  puts "Mi vodka, mi Redbull"
end

task :ceSoirJeBois => :sersMoiUnVerre do
  puts "Wow, y'a du brouillard ce soir. Ggggarçon – hips – un autre !"
end

Maintenant, il me faut acheter à boire et me servir un verre avant de pouvoir me saouler la gueule convenablement. Cela donne donc :

$ rake acheteABoire
 Et hop, une bouteille de vodka
$ rake sersMoiUnVerre
 Et hop, une bouteille de vodka 
 Mi vodka, mi Redbull
$ rake ceSoirJeBois
 Et hop, une bouteille de vodka 
 Mi vodka, mi Redbull
 Wow, y'a du brouillard ce soir. Ggggarçon – hips – un autre !

Comme vous pouvez le voir, avant que je ne puisse boire, il me faut acheter de l’alcool et me servir un verre. L’ordre des choses est rétabli.

Avec le temps, vous risquez d’être tenté d’accroître votre alcoolisme, et donc votre Rakefile. Vous serez aussi certainement tentés de m’inviter à boire un coup. Comme dans tout logiciel d’envergure, rien ne vaut une bonne documentation.

Comment documenter mes tâches ?

Rake possède une manière très simple de documenter les tâches. Il s’agit de “desc” et c’est simple comme bonjour :

desc "Cette tâche va aller acheter la vodka"
task :acheteABoire do
  puts "Et hop, une bouteille de Vodka"
end

desc "Cette tâche prépare le cocktail"
task :sersMoiUnVerre => :acheteABoire do
  puts "Mi vodka, mi Redbull"
end

desc "Ce soir je bois"
task :ceSoirJeBois => :sersMoiUnVerre do
  puts "Wow, y'a du brouillard ce soir. Ggggarçon – hips – un autre !"
end

Comme vous pouvez le voir, chacune de mes tâches a maintenant une description. Mes amis peuvent les lire en tapant rake -T, ou rake --tasks.

$rake --tasks  
 rake acheteABoire    # Cette tâche va aller acheter la vodka
 rake ceSoirJeBois    # Ce soir je bois
 rake sersMoiUnVerre  # Cette tâche prépare le cocktail

Facile non ?

L’espace de nommage de Rake

Maintenant que vous êtes devenu un bon alcoolique, vous utilisez un grand nombre de tâches Rake, et vous avez besoin d’un bon moyen de les classer. C’est là que viennent les espaces de nommage. Si je devais utiliser un espace de nommage dans l’exemple précédent, il deviendrait :

namespace :alcoolique do
  desc "Cette tâche va aller acheter la vodka"
  task :acheteABoire do
      puts "Et hop, une bouteille de Vodka"
  end

  desc "Cette tâche prépare le cocktail"
  task :sersMoiUnVerre => :acheteABoire do
      puts "Mi vodka, mi Redbull"
  end

  desc "Ce soir je bois"
  task :ceSoirJeBois => :sersMoiUnVerre do
      puts "Wow, y'a du brouillard ce soir. Ggggarçon – hips – un autre !"
  end
end

Vous n’avez plus qu’à classer vos tâches en fonction des catégories, et OUI, vous pouvez en avoir plusieurs dans un même fichier. Maintenant, rake --tasks me donne :

$rake --tasks  
 rake alcoolique:acheteABoire    # Cette tâche va aller acheter la vodka
 rake alcoolique:ceSoirJeBois    # Ce soir je bois
 rake alcoolique:sersMoiUnVerre    # Cette tâche prépare le cocktail

Tu ne pourrais pas être un peu sérieux pour une fois ?

Les applications Rails viennent avec un lot de tâches prédéfinies, dont vous pouvez obtenir la liste en allant dans le répertoire de travail et en lançant rake --tasks. Si vous n’avez pas encore essayé, allez y, je peux attendre deux minutes…

Afin de créer une nouvelle tâche rake pour votre application Rails, vous devez dans un premier temps vous rendre dans le répertoire /lib/tasks (créé par défaut). Si vous y placez vos Rakefiles avec le suffixe “.rake”, celles-ci seront automatiquement récupérées par Rake. Nous allons ajouter la tâche suivante à notre application Rails.

namespace :utils do
  desc "Crée des répertoires vides s'ils n'existent pas"
  task(:create_directories) do

    # Les répertoires dont j'ai besoin
    shared_folders = ["icons","images","groups"]

    for folder in shared_folders

      # Existent-ils ?
      if File.exists?("#{RAILS_ROOT}/public/#{folder}")
        puts "#{RAILS_ROOT}/public/#{folder} existe"
      else
        puts "#{RAILS_ROOT}/public/#{folder} n'existe pas, nous le créons donc"
        Dir.mkdir "#{RAILS_ROOT}/public/#{folder}"
      end
    end
  end
end

Remarquez comment j’ai pu utiliser #{RAILS_ROOT} pour obtenir le chemin complet de l’application. Maintenant, si je lance rake --tasks dans le répertoire de mon application, je trouverai les nouvelles fonctions mélangées aux autres tâches Rake.

..
rake tmp:pids:clear              # Clears all files in tmp/pids
rake tmp:sessions:clear          # Clears all files in tmp/sessions
rake tmp:sockets:clear           # Clears all files in tmp/sockets
rake utils:create_directories    # Crée des répertoires vides s'ils n'existent pas
...

Génial ! Maintenant voyons comment ça devient vraiment utile.

Et on peux accéder aux modèles Rails depuis une tâche ?

Évidemment ! En fait, c’est même pour ça que j’utilise Rake : écrire des tâches que je lance à la main ou que je planifie en utilisant Crontab. Comme je le disais au début de l’article, j’utilise Rake pour les tâches suivantes :

• Récupérer une liste d’inscrits afin d’envoyer un email.
• Lancer des traitements de calcul et de statistiques pendant la nuit.
• Supprimer et régénérer le cache d’une application.
• Sauvegarder ma base de données et mon dépôt subversion.
• Exécuter n’importe quel traitement de données.
• Me saouler la gueule.

Sacrément utile, et facile qui plus est. Le code suivant récupère la liste des utilisateurs dont l’abonnement arrive à expiration et leur envoie un courriel :

require File.expand_path(File.dirname(__FILE__) + "/../../config/environment")

namespace :utils do
  desc "Finds soon to expire subscriptions and emails users"
  task(:send_expire_soon_emails => :environment) do
        # Find users to email
        for user in User.members_soon_to_expire
                puts "Emailing #{user.name}"
                UserNotifier.deliver_expire_soon_notification(user)
        end
  end
end

Comme vous pouvez le voir, nous accédons au modèle en deux étapes : la directive require et le => :environment.

1. require File.expand_path(File.dirname(__FILE__) + “/../../config/environment”)
2. task(:send_expire_soon_emails => :environment) do

Pour lancer ça tous les soirs à minuit, je n’ai qu’à créer une tâche dans Crontab, de cette manière :

0 0 * * * cd /var/www/apps/rails_app/ && /usr/local/bin/rake RAILS_ENV=production utils:send_expire_soon_emails

Où trouver plus d’exemples ?

Maintenant que vous en savez assez pour écrire des tâches utiles, je me suis dit que je pourrais vous laisser repartir avec quelques ressources supplémentaires. La meilleure manière de vous améliorer est encore de lire le code des autres, comme ces tâches Rake :

• Ces nouvelles tâches incluses dans Rails Edge remettent votre base de données à zéro pour vous.
• Craig Ambrose a écrit une tâche pour sauvegarder votre base de données.
• Adam Greene a écrit une série de tâches qui vous permettent de sauvegarder vos données sur Amazon S3.

C’est fait. Si vous en connaissez d’autres, n’hésitez pas à les publier dans les commentaires.

Toujours là ? Ça tombe bien, les gens de RailsEnvy à qui nous devons cet excellent article cherchent de nouveaux collaborateurs. Contactez Greg at RailsEnvy si ça vous intéresse.

Je recherche actuellement un outil ou un service me permettant de créer des sondages et de les intégrer ensuite à une page web, sous forme de formulaire ou d’un bout de javascript, bien que cette solution ne me satisfasse pas entièrement vu son caractère peu accessible.

S’il s’agit d’une solution hébergée, peu me chaut qu’elle soit payante tant que cela reste dans les limites du raisonnable, et s’il s’agit de scripts à héberger moi-même, il faudrait que ce soit du Ruby.

La solution devra être un minimum complète, puisque les sondages feront de 10 à 20 questions, et chaque question comptera jusqu’à 10 réponses possibles.

Si vous connaissez quelque-chose comme ça, je suis preneur, dans le cas contraire, je coderai un greffon en Ruby on Rails en rentrant de week-end.

Après Java, c’est au tour de PHP de subir l’humour ravageur de Gregg et Jason, dans une autre parodie des publicités Apple. Et c’est bon !

Je trouve juste dommage qu’ils tournent sous Mephisto quand Typo leur tend les bras…