| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Sep | ||||||
| 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 | ||
Après une semaine d’absence, les ateliers du lundi sont de retour. Au programme de lundi prochain (le 8 septembre donc), il y aura 3 sessions :
A lundi pour ceux qui le souhaitent.
La gestion des dates sous PHP a toujours été compliquée (pour ne pas dire pénible). Aussi, nous avons commencé à réfléchir sur une classe Date (ou DateTime) qui simplifierait cela au cours d’un atelier du lundi.
Nous avons également fait une session intitulée “A la découverte de SproutCore”. SproutCore est un framework javascript qui a bénéficié du buzz lord de la dernière Keynote d’Apple. Aussi, il nous semblait intéressant de voir quel est le potentiel de ce framework. Nous sommes arrivés à la conclusion qu’il était encore trop tôt pour juger (pas encore de d’applications en ligne, pas de tutoriels à part le Hello World de base, etc.).
Pour ces 2 sessions, les slides sont disponibles : classe Date pour PHP et A la découverte de SproutCore.
Scott becker a fait un thème GitHub pour Textmate. En voici une capture d’écran (cliquer dessus pour la voir en taille réelle) :
Si vous êtes intéressé, vous pouvez téléchargez ce thème depuis GitHub.
Source : http://synthesis.sbecker.net/articles/2008/05/28/github-theme-for-textmate
Après le RailsCampParis, hier a eu lieu le Rails MashPit Paris. Ce fût l’occasion de mettre en pratique les techniques découvertes la veille.
Une quinzaine de courageux sont venus, et chose assez rare pour un MashPit, quasiment tous savaient coder. La première épreuve (après le petit déjeuner) fût le choix des projets. Après deux tours de votes, trois équipes se sont lancés dans une journée de développement intensif.
Le premier projet consistait en un doodle-like ouvert avec une interface plus sexy, nommé shareURplans. Le but est de pouvoir créer des sondages publics ou privés pour convenir d’une date. Le code, disponible via svn sur svn://paws.bearstech.com/mashpit/shareurplans/trunk, a permis de faire une démo faisant appel à l’imagination.
La seconde équipe a développé un site web pour lancer des rumeurs et voter pour ou contre ces rumeurs : uncomfirmd. Malgré un départ difficile à cause du choix du framework Merb qui n’était pas connu de tous, cette équipe a réussi l’exploit de présenter une démo avec quasiment toutes les fonctionnalités annoncées le matin. Chapeau. Le code est disponible avec un svn co svn://paws.bearstech.com/mashpit/unconfirmd/trunk.
Enfin, la troisième équipe (la mienne ^^) s’est lancé dans un CMS “dead simple”. Light Grass, c’est son nom, est hébergé sur Github : http://github.com/nmerouze/lightgrass/tree/master, ce qui s’est révélé un gros handicap dans la journée : installation d’une version récente de git sur une machine, plusieurs conflits, erreurs de manipulation ayant conduit à la perte de plusieurs fichiers… Tout ceci nous a empêché de présenter quelque chose de concluant pour la démo.
Le débriefing a permis de faire ressortir des idées pour améliorer les prochains MashPit. On pourrait inciter les futurs participants à venir avec les outils de base déjà installés (svn et git notamment). Il est également conseillé de ne pas chercher à trop paralléliser les tâches, mais plutôt essayer d’être très productif sur un point précis avant de passer au suivant. Pour cela, le pair programming semble être une technique redoutablement efficace que nous n’avons pas suffisament utilisée. Enfin, il est recommandé d’avoir des objectifs réalistes, car une fois la phase de setup passée, il ne vous restera que 2 ou 3 heures de codage intensif, ce qui passe très vite.
Pour conclure, je dirais que ce MashPit fut une expérience très intéressante pour tous. Cela nous a permis d’essayer d’autres façons de travailler en équipe et de découvrir de nouveaux outils (git, merb, le plugin paperclip, etc.). De plus, dans les 3 équipes, des personnes sont intéressées pour continuer le projet après le MashPit, ce qui montre bien la réussite de cet événement.
PS : merci à Silicon Sentier pour nous avoir accueilli dans les locaux de La Cantine, cet endroit uber-cool (rien que la nouvelle table multitouch vaut le détour).
Un petit post depuis le RailsCamp Paris à la Cantine :
Ruby France, Silicon Sentier et AF83 ont le plaisir de vous annoncer l’organisation du premier RailsCamp (BarCamp/DevCamp dédié à Ruby on Rails) parisien. Il aura lieu le samedi 17 mai 2008 dans le cadre convivial de la Cantine, Paris, France.
Le thème de cette non-conférence est bien sûr Ruby on Rails, mais aussi des sujets afférents : Capistrano, Mongrel, Prototype, Script.aculo.us… L’événement est gratuit et
ouvert à tous, des experts Rails aux débutants.
Il sera suivi le lendemain (le dimanche 18 mai) de 11h à 17h par un MashPit. Cette journée sera dédiée à la réalisation collaborative de mini-projets informatiques basés sur Ruby on Rails.
Pour s’inscrire (c’est gratuit, mais limité en nombre de places) : RailsCamp et MashPit
ICalendar is a standard (RFC 2445) for calendar data exchange. The standard is sometimes referred to as "iCal", which also is the name of the Apple, Inc. calendar program that provides one of the implementations of the standard. Source: ICalendar.
It's possible to generate ICalendar files with Ruby on Rails. This can be useful for letting users adding your events in their calendars.
The first step is the install of the icalendar gem: gem install icalendar. An alternative can be vpim.
Then, this library must be required from rails. Add require 'icalendar' to your config/environment.rb file. You can require it from elsewhre, but I think that config/environment.rb is a good place.
Here, we are ready to code our export of events fo .ics file. We suppose that we have an Events model:
We add a to_ics to this class:
Don't forget to declare PUBLIC_URL. I've done this declaration in config/environment/production.rb, so I can have different URL for development and production.
The next part is modifying the show action of the EventsController to accept .ics format:
Note: the ics format is known by rails 2.0. If it was not the case, we could add it to config/initializes/mime_types.rb.
Add a link to your ical export and we are done:
You can now enjoy your icalendar events. There are some interresting links if you want more informations:
There are several Ruby on Rails plugins for tagging. The first one was acts_as_taggable by DHH. It was simple and limited in functionality, so it was forked several times. The most popular version of these forks is acts_as_taggable_on_steroids, which is pretty performant, has tag cloud calculations and offers extras such as tests.
However, it's not possible to have several sets of tags on the same object. For example, it can be useful to separate skills and interests for users. acts_as_taggable_on implements this lacking functionality.
Cool, but how do we use it ?
First, install it like any rails plugin :
script/plugin install http://svn.intridea.com/svn/public/acts_as_taggable_on/
Then, generate the migration for creating the new SQL tables for the tags (and play this migration) :
script/generate acts_as_taggable_on_migration
rake db:migrate
The last step of the installation is to declare the User class as taggable :
Done ? OK, let's test it in script/console:
With these methods, you should be able to have tags on many models on your app, with several sets if you want. The next big step is tag clouds, because of the lacking documentation. I think an example is welcomed.
So, the first thing is finding tags with their counts :
Then, we can show them with the tag_cloud helper:
Go on http://my-web-site/clouds/skills and have a glance on the tag clouds.
The last caveat is tag clouds with tags from all the models and sets. For this, we need to dive into acts_as_taggable_on and play with ActiveRecord:
The app/views/clouds/all.html.erb view is the same as skills.html.erb. Enjoy it on http://my-web-site/clouds/ 
Cet article a pour but de décrire l'architecture employée derrière le site de micro-blogging Noumba. Il n'a pas pour objectif d'être exhaustif ni de prétendre proposer la solution idéale, mais seulement présenter un moyen de résoudre certaines contraintes selon notre contexte.
Micro-blogging
Le micro-blogging est un concept, lancé par Twitter, qui permet de s'exprimer en de courtes phrases, tenant en une centaine de caractères de manière à pouvoir être lu depuis un téléphone portable, par SMS ou WAP.
En une phrase on ne communique le même type d'information que sur son blog. Cela va donc de son humeur, un lien, ou une rapide information qui ne nécessite pas un long exposé. Ce type d'information sont plus courante que celle que l'on écrirait sur son blog, et à ce titre le micro-blogging est un complément au blog plus qu'une alternative.
Le corollaire est la possibilité de s'exprimer depuis son téléphone portable vers le site.
Au final un site de micro-blogging est souvent utilisé en tant que passerelle entre 2 outils de communication (Phone2Phone, Desktop2API, Phone2Jabber, Web2...).
Contexte
Noumba est un site web de micro-blogging en Ruby on Rails. Il est ouvert à tous, mais son orientation commerciale le prédispose à une certaine tranche d'âge d'utilisateurs, entre 13 et 25 ans. De fait il est pour l'instant plus utilisé pour du chat que du micro-blogging, ce qui génère un fort nombre de messages par utilisateur.
En outre de part le profil des utilisateurs, des filtres sont indispensable afin de garantir une certaine qualité de contenu et de confidentialité.
Pour le reste, les contraintes sont les mêmes que des sites tels que Twitter ou Jaiku, cependant Noumba a ceci de particulier qu'il propose un certain nombre de satellites utilisés par des partenaires, tel que SFR (sfr.noumba.net), NRJ, (mikl.noumba.net, 6-9.noumba.net) MyMajorCompany (mymajorcompany.noumba.net), MCM (mcm.noumba.net), ...
Contraintes
Des traitements asynchrones
Lorsqu'un message est posté, des traitements sont appliqués (filtrage, routage, emails, logs,...). Ces traitements ne doivent pas augmenter la latence entre l'utilisateur et le site web. Il n'est donc pas possible de les effectuer de manière synchrone, c'est à dire imposer à l'utilisateur d'attendre leur fin avant de lui rendre la main.
Si un fonctionnement synchrone est envisageable avec quelques utilisateurs en simultané, il est tout bonnement impossible pour un site à vocation grand public si l'on veut respecter une certaine qualité de service.
La solution est d'effectuer ces traitements de manière asynchrone, c'est à dire en parallèle, sans imposer à l'utilisateur leur fin pour lui rendre la main.
Les solutions
background
La première solution utilisée sur Noumba fut backgroundrb. Cet outil fournit un serveur de tâche permettant de les paralléliser dans un processus.
Si cette solution est intéressante pour quelques tâches simples, elle n'est plus possible dans le contexte lourd d'un micro-blogging, d'autant plus que backgroundrb utilisait les threads.
Les threads en Ruby sont peu efficaces (green thread) et une telle architecture consomme trop de ressources et est l'origine de bugs difficilement décelables.
Ces threads permettent d'exécuter les traitements, workers, cependant la communication entre eux n'est pas aisée ce qui complique l'enchainement des traitements.
Backgroundrb a depuis été repris et n'utilise plus à priori les threads. Malgré tout, une architecture robuste à base de file d'attente est préférable.
Hey MoM ! ou le monde des messages brokers
Les Message oriented Middleware sont des architectures qui permettent de faire communiquer des applicatifs de manière asynchrone par le biais d'une file d'attente. JMS est le MoM le plus connu et un certain nombre d'implémentations libres existent (ActiveMQ, RabbitMQ)
Parmis ceux-ci, certains implémentent le protocole texte stomp, plus simple et adapté à un site de micro-blogging. StompServer en Ruby en fait parti.
Plus de détails sur les MoM
Ce plugin Rails permet de communiquer vers un serveur MoM. Il lance un poller qui interroge le serveur MoM afin de lui transmettre ou lui retirer les messages.
Ce plugin est MoM agnostique, on peut interroger aussi bien un serveur ActiveMQ, StompServer et même AmazonSQS.
Noumba a utilisé un certain temps un backend StompServer / ActiveMessaging. C'est une architecture intéressante cependant l'évolution et la qualité du code de ActiveMessaging sont à surveiller de prêt.
Noumba en tant que micro-blog génère une forte charge. Or cette charge devient vite un handicap pour le bon fonctionnement du poller.
La conclusion qui s'impose est que Noumba se doit d'être le plus léger possible en effectuant le moins d'opération même par le biais d'un plugin.
Que REST il ?
REST est en effet la solution la plus simple, la plus standard (HTTP) et la moins lourde.
Dans sa dernière architecture, Noumba communique en REST avec un backend, le Hub, également en Rails. Les messages sous forme de Hash sont sérialisés puis transmis au backend.
Cependant il est toujours nécessaire d'implémenter une architecture MoM cà´té Hub afin d'obtenir un fonctionnement asynchrones.
XMPP bien sûr !
Quel serveur robuste fonctionne de fait sous forme de file d'attente, tout en étant robuste et utilisant un protocole standard, connu et ouvert ? XMPP bien sûr !
Ejabberd est un des serveurs Jabber le plus robuste. Etant en erlang, il peut facilement être réparti sous forme de cluster si le besoin se fait sentir.
Entre REST et XMPP il nous manque le lien Ruby on Rails. ActionMessenger vient le combler. Ce plugin Rails permet de transmettre des messages XMPP en utilisant un compte Jabber. Il fonctionne simplement à la manière d'ActionMailer.
Le Hub implémente ce plugin. Il reçoit les objets sérialisés et les transmet à divers comptes Jabber puis répond aussità´t à Noumba au travers de son API REST.
Powered by WordPress, Mandigo theme by tom.
Entries (RSS)
and Comments (RSS).
