L'actualité de Synbioz

Full-text search with sphinx and thinking sphinx

Martin Catty — Fri, 18 May 2012 00:00:00 +0200

What is full-text search ?

Full text search allows you to search through content, or part of a content.

It’s not designed on top of SQL, it uses an indexed DB which is much more efficient than doing some LIKE queries.

Search engine uses indexed DB. I’m not telling google is using sphinx but it’s based on the same concept.

To be able to search some terms, your content must be previously indexed. Each term of each document is indexed with a position.

So the main problem of full-text search is to keep an indexed DB up-to-date. If your content changes very often then you should index it often too.

But indexing is time consuming, and it will use some resources. In addition searching should still be available during indexation.

Sphinx and Thinking Sphinx

Sphinx is open source search server. Thinking sphinx is a gem built for rails which interact greatly with it.

Sphinx must be setup to be able to use Thinking Sphinx. It’s available for the 3 main OS.

Installing and configuring Thinking Sphinx

Thinking Sphinx can be installed as a gem and configured ìn config/sphinx.yml This is an example:

development:
  port: 9312
  enable_star: 1
  min_infix_len: 3
test:
  port: 9313
  enable_star: 1
  min_infix_len: 3

You can set the port for each environment or add the ability to search terms part. There is many other options, take a look at the advanced configuration guide.

The index has to be rebuilt when changing configuration file.

rake ts:rebuild

Thinking Sphinx will generate his own config file like config/development.sphinx.conf and maintain his indexed db in db/sphinx/development/

Indexing

As I said before, indexing is not done on the fly when you add new content. You should explicitly add a routine. Trying to index with model callbacks is not a good idea.

So you have to choose the better interval between two indexations.

Whenever is a great gem to automate this job. For example:

every 10.minutes do
  rake "ts:index"
end

every :reboot do
  rake "ts:start"
end

What about using sphinx with database filters ?

Imagine an e-commerce website. You’ve got tons of products with descriptions. Products belongs_to a category, has some pictures and a state (online or not).

product:
  title: "my great product"
  description: "my great description"
  category\_id: 1
  state: "online"

If a user browse a category and search a product, we should restrict his search to the scope of this category. We also want to be able to restrict search to product having pictures and an online state.

In fact we want to cumulate full-text search and SQL restrictions.

Thinking sphinx can interact with a SQL database like MySQL. There is attributes to do that. People often misunderstood difference between indexed fields (used with indexes) and attributes (used with has).

Fields are searchable while attributes match exact values. The state and category_id are exact values. But be careful, you should consider each attribute as an integer, even state which is a string.

So we’re gonna use the CRC32 method to index string as integer and be able to search it.

define_index do
   # fields to use for term search
   indexes title, sortable: true
   indexes description

   # attributes usable as sort / filter criteria
   has category_id

   has "CRC32(state)", as: :state, type: :integer

   has "COUNT(DISTINCT pictures.id) > 0", as: :has_pictures, type: :boolean

   join pictures
 end

  sphinx_scope :ts_online do
    { with: { state: "online".to_crc32 } }
  end

The ruby method to_crc32 is not part of the core nor ActiveSupport, it’s a thinking sphinx’s addition using Zlib.

Zlib.crc32 "ruby"
# => 3428506893

Be aware that this is not perfectly reliable as crc32 can have some collisions depending on the term.

Conclusion

And here we go, we’re now able to search products with a particular category, some pictures or not and specific terms in the title and/or description.

Sphinx is an easy to setup and powerful solution to add full-text search to your web application. I really encourage you to dig into the documentation to discover all the available options.

If you don’t want to use Sphinx there is other full-text search engine. solr is also very popular and has ruby gem like sunspot to interact with.

The Synbioz Team. Free to be together.

Les caches HTTP

Nicolas Zermati — Tue, 08 May 2012 00:00:00 +0200

Les applications web prennent de plus en plus de place dans le paysage applicatif actuel. Ce qui, hier, était une application lourde a une forte probabilité de se voir remplacée, demain, par une application web. Ce phénomène s’accentue par les nouvelles possibilités offertes par l’évolution des réseaux (ADSL, fibre, 4G, etc). Les utilisateurs sont interconnectés, les données partagées et mises à jour régulièrement ce qui encourage plus encore l’émergence des applications web.

Ce bouleversement dans l’organisation des applications n’est pas nouveau. Depuis toujours, dans le domaine de l’Informatique, on jongle entre centralisé et décentralisé. Dans le domaine des architectures matérielles, on a les systèmes clients - serveur s’opposant aux PC. Il en est de même pour le logiciel, le protocole FTP s’opposant à des protocoles décentralisés comme Bittorrent.

Les applications web se classent dans la mouvance des architectures centralisées. Le nombre de clients peut alors prendre des dimensions extraordinaires, comme pour les réseaux sociaux. Internet se base grandement sur HTTP (« Hypertext Transfer Protocol »). Ce protocole met à disposition des méthodes de mise en cache permettant d’optimiser les interactions entre client et serveur.

Cet article introduira depuis zéro ce que HTTP prévoit dans le domaine des caches. L’objectif de tels systèmes est d’éviter qu’une partie des requêtes des clients atteignent le serveur, améliorant ainsi la réactivité du serveur pour les autres requêtes. Les effets bénéfiques sont nombreux, moins de sollicitations du réseau, de la base de donnée, de temps de calcul pour le serveur, etc.

Introduction

En Informatique un cache est un système qui mémorise des données en vue d’une réutilisation ultérieure. L’objectif est d’utiliser la copie présente dans le système de cache plutôt que d’interroger la véritable source des données lors des accès futurs. Pour HTTP, les données correspondent aux contenus des pages web.

Mémoriser une donnée dans un cache implique de pouvoir identifier la donnée à mémoriser. Dans le domaine des mémoires matérielles, on utilise une adresse pour identifier les données. Dans le cas d’HTTP, on utilise l’URL pour identifier les pages. On verra par la suite que l’URL n’est pas le seul élément permettant d’identifier une page.

Un autre aspect fondamental dans ce domaine est l’expiration du contenu. En effet, il faut assurer la cohérence des données mémorisées dans le cache par rapport aux données fournies par la source. Pour atteindre ce but on doit disposer d’un moyen de valider les données mémorisées.

Les caches ne peuvent pas toujours contenir l’intégralité des données d’une source. Dans ces cas-là, ils doivent mettre en place des stratégies de remplacement des données dites cachées. Nous ne parlerons pas de cette problématique dans l’article.

HTTP ne fournit pas directement un système de cache, mais il permet, et c’est ce que nous verrons dans cet article, d’identifier, d’expirer et d’assurer la cohérence des données. Ce sera à un logiciel tiers d’exploiter ces informations ; les navigateurs et les proxys en sont deux exemples.

Exemple sans cache HTTP

Exemple avec cache HTTP

Un cache peut être partagé lorsque plusieurs programmes ou clients qui accèdent à un même serveur. Ceci implique souvent des préoccupations de sécurité puisqu’on ne peut pas toujours partager des données entre deux clients par soucis de confidentialité par exemple. Il faut donc des moyens afin de contrôler l’accès aux données cachées.

Multiple clients, attention au partage des données.

Contrôle du cache

Le contrôle du cache désigne la manière dont on va vouloir que le cache opère. On distingue deux types de contrôle : un issu d’une requête d’un client vers le serveur et un autre issu de la réponse du serveur à destination du client. Selon le type, la signification de la directive voit sa signification modifiée.

Pour spécifier la politique de cache souhaitée, on dispose de l’entête HTTP nommé Cache-Control. Ce champ peut être valué par une liste de paramètres séparés par des virgules. On peut aussi avoir plusieurs fois le champ Cache-Control dans l’entête. Ce champ permet d’uniformiser la communication entre les serveurs des uns et les systèmes de caches des autres.

Par défaut, toute réponse valide peut être mise en cache.

Voici la liste des valeurs que peut utiliser l’entête Cache-Control :

Requête

no-cache : le client désire passer outre le cache.

no-store : le client commande de ne mémoriser ni la requête, ni la réponse à cette dernière.

max-age=#SECONDS : le client accepte uniquement une réponse dont l’âge est inférieur à #SECONDS mais sans pour autant être expirée.

max-stale[=#SECONDS] : le client accepte une réponse expirée depuis moins de #SECONDS.

min-fresh=#SECONDS : le client exige une réponse validée depuis moins de #SECONDS.

no-transform : le client ne souhaite pas que des caches intermédiaires modifient la requête.

only-if-cached : le client ne souhaite qu’une réponse valide issue du cache ou bien une erreur 504.

Réponse

public : le serveur autorise la mémorisation de la page peu importe l’entête Authorization (voir la RFC2616 14.8).

private : le serveur interdit la mise en cache par un cache partagé.

no-cache : le serveur ne souhaite pas que sa réponse soit redistribuée sans validation préalable de sa part, malgré les directives du client.

no-store : le serveur interdit les caches de mémoriser en mémoire non volatile la réponse ou la requête à l’origine de celle-ci.

no-transform : le serveur interdit de modifier le contenu de sa réponse, par de la compression par exemple.

must-revalidate : le serveur interdit aux caches de retourner une page expirée, malgré les directives du client.

proxy-revalidate : le serveur interdit aux caches partagés de retourner une page expirée, malgré les directives du client.

max-age=#SECONDS : le serveur définit le temps restant avant expiration et implique que la réponse est public.

s-maxage=#SECONDS : le serveur définit le temps restant avant expiration, surpassant max-age ,et, implique que la réponse est proxy-revalidate.

Ces valeurs pour la directive Cache-Control montrent l’étendue des possibilités dont dispose un serveur pour s’interfacer avec un système de cache. Ces valeurs peuvent se combiner entre elles.

Expiration

Dans la directive Cache-Control nous venons de voir qu’il est question d’expiration et de validité. L’objectif d’un cache est d’éviter d’émettre des requêtes à destination du serveur source afin de ne pas surcharger ce dernier et de gagner en réactivité. Le cache doit donc décider s’il est nécessaire de solliciter ce serveur. Pour prendre cette décision, le système de cache vérifie que sa copie, s’il en possède une, n’est pas expirée ; qu’elle est toujours valide.

Âge

L’âge correspond au nombre de secondes écoulées depuis la génération de la page par le serveur.

L’âge d’une réponse est donc la différence temps-de-réception-de-la-réponse - temps-d-émission-de-la-réponse, le temps d’émission de la réponse est issue de l’entête Date qu’elle contient. L’âge peut aussi être directement présent dans l’entête Age, indépendamment de cette méthode de calcul.

Dans les cas ou il n’y a pas d’entête Date dans la requête, on se base sur Age ou, s’il n’y pas d’Age, on considère l’âge comme étant 0. Cette situation ne prend pas en compte le temps que la réponse a pu passer sur le réseau. On doit alors prendre en compte la différence temps-de-réception-de-la-réponse - temps-d-émission-de-la-requête et l’ajouter à l’âge.

Ces étapes permettent de calculer l’âge d’une page lorsqu’on la reçoit. Lorsqu’un cache retournera cette page, il devra ajouter y ajouter le temps écoulé depuis la réception de la réponse depuis le serveur source. En effet, la page est âgée de N secondes à sont arrivée dans le cache, si le cache sert à nouveau une page 10 secondes après l’avoir lui-même reçu, il devra lui donner un âge de N + 10 secondes.

Voici un récapitulatif issu de la RFC2616 :

apparent_age           = max(0, response_time - date_value)
corrected_received_age = max(apparent_age, age_value)
response_delay         = response_time - request_time
corrected_initial_age  = corrected_received_age + response_delay
resident_time          = now - response_time
current_age            = corrected_initial_age + resident_time

Calcul d’expiration

Une page est déclarée comme expirée ou viciée (stale en anglais) lorsque son âge est supérieur à l’âge autorisé par le serveur, ou lorsque le client en fait la demande. L’entête Cache-Control permet de calculer si oui ou non un cache est expiré. En plus de Cache-Control, il existe également l’entête Expires qui spécifie une date après laquelle la page est considéré comme expirée. La directive max-age de l’entête Cache-Control est prioritaire sur la date contenue dans l’entête Expires.

Si une réponse ne spécifie ni d’indication d’expiration ni de restriction concernant la politique de mise en cache alors le systèmes de caches sont libres d’utiliser des algorithmes de leur choix pour décider de la validité d’une page. L’une des informations pouvant être utilisées est l’entête Last-Modified.

Il est possible pour un client d’avoir pour une même URL deux pages différentes à un même instant. En effet, une requête peut passer par différents chemins sur le réseau et donc utiliser différents caches. Dans les cas ambigus les clients comme les caches considèrent que la réponse la plus pertinente est celle avec l’entête Date la plus récente. Lorsque la valeur de l’entête Date d’une page est inférieure ou égale à la date de la page cachée, on peut s’attendre a une nouvelle requête contenant Cache-Control: max-age=0 ou bien Cache-Control: no-cache pour forcer une revalidation auprès du serveur.

Validation

Maintenant qu’on a abordé les mécanismes du calcul de l’âge et d’expiration, on va pouvoir explorer les mécanismes de validation. La validation se produit lorsqu’un système de cache reçoit une requête de la part d’un client. Le système de cache doit alors décider de si oui ou non le contenu d’une page cachée doit être retourné au client.

Pour permettre de valider une page, les serveurs peuvent fournir des validateurs avec leurs pages. L’entity-tag et la date de dernière modification sont les deux validateurs qu’on peut retrouver dans l’entête HTTP. Le cache formulera alors des conditions sur la valeur de ces champs pour savoir si oui ou non, la page qu’il contient est valide.

Par défaut une page fraiche ne nécessite pas de validation ; c’est l’entête Cache-Control qui va permettre de jouer avec la validation.

ETag, Last-Modified et conditions de validation

Les entêtes ETag et Last-Modified et contiennent respectivement une chaine de caractère et une date au format HTTP. Un cache informe le serveur de ses conditions de validation par les entêtes suivantes :

If-Match: ETAG retourne la page demandée si elle dispose d’un entity-tag égal à ETAG (un code 412 sinon).
If-None-Match: ETAG retourne la page demandée si elle dispose d’un entity-tag différent de ETAG.
If-Modified-Since: DATE retourne la page demandée si elle est SRICTEMENT PLUS récente que DATE.
If-Unmodified-Since: DATE retourne la page demandée si elle est MOINS récente que DATE (un code 412 sinon).
If-Range: (DATE / ETAG) retourne la partie de la page demandée si elle n’a pas été modifiée : si elle est MOINS récente que DATE ou si elle dispose d’un entity-tag égal à ETAG.

On peut se demander en quoi il est intéressant de disposer de conditions comme If-Match ou If-Unmodified-Since puisqu’il s’agit de demander au serveur de ne retourner une page lorsqu’on dispose déjà de celle-ci. Ces conditions peuvent être utilisées pour n’exécuter une requête que si la page d’origine n’a pas changé. Par exemple, dans le contexte d’une architecture REST, on souhaite réaliser un PUT sur une URL mais on désire s’assurer qu’il n’y a pas eu de modification entre le moment où on a reçu le formulaire et celui où on le transmets au serveur. Dans ce cas, on peut utiliser If-Match ou If-Unmodified-Since pour exécuter notre requête uniquement si la ressource est identique à l’image que l’on avait d’elle.

Dans le diagramme suivant, un client est mis en relation avec un serveur qui lui sert une page « a » avec un client qui, 30 secondes après sa première requête, demande à nouveau la page « a » avec l’entête Cache-Control: max-age=0 ce qui signifie qu’il veut forcer la revalidation de la page. Le cache demande donc une validation au serveur en utilisant l’entête If-None-Match. Le serveur lui répond alors par un code 304 et en profite pour donner un nouvel âge maximum. Le cache exploitera alors ce nouvel âge.

Utilisation de max-age=0 durant un « Ctrl + R »

Validation forte ou faible

Lorsqu’une page (entêtes ou contenu) change, on s’attend à ce que les validateurs changent eux aussi.

On appelle validateur fort (strong validator), tout validateur vérifiant ce comportement. Cependant ce comportement n’a pas a être systématique et le serveur est libre de maintenir un validateur identique entre des pages différentes. On appelle ce dernier un validateur faible (weak validator). Dans certaines situations, le serveur peut donc considérer une page cachée comme assez proche de ce qu’il retournerait pour autoriser le cache à s’en servir.

L’ETag est un validateur fort par défaut. On peut l’utiliser en tant que validateur faible en plaçant W/ devant la valeur de l’entity-tag : ETag: W/"123456789. Last-Modified est un validateur implicitement faible puisqu’on peut modifier une page deux fois en une seconde. Dans certains cas, on peut considérer la date de dernière modification comme un validateur fort :

le serveur sait que la page ne peut être modifiée deux fois en une seconde ou
on connait la date de génération Date et elle est strictement supérieure à 60 secondes à la condition de validation If-Unmodified-Since ou If-Modified-Since ou à l’entête Last-Modified.

If-Range qui permet de récupérer une partie seulement du contenu d’une page n’utilise que des validateurs forts.

Règles autour des validateurs

HTTP spécifie des règles concernant les validateurs. Il faut bien les garder en tête lorsqu’on réalise un client ou un serveur utilisant HTTP.

Tout serveur HTTP/1.1 :

devrait envoyer un ETag, à moins qu’il soit impossible d’en générer un,
peut envoyer un ETag faible pour des raisons de performance ou car il est impossible d’obtenir un ETag fort,
devrait envoyer une Last-Modified date lorsque c’est possible et sans risque pour la cohérence des caches et
ne renvoie un statut 304 que si tout les validateurs présents dans la requête vont en ce sens.

Un client, ou un cache HTTP/1.1 :

utilise l’ETag, pour de la validation conditionnelle, lorsque ce dernier est présent,
devrait utiliser la Last-Modified date, pour de la validation conditionnelle, lorsque cette dernière est présente et qu’il n’est pas question d’une requête partielle (Range),
peut utiliser la Last-Modified date, pour de la validation conditionnelle, lorsque cette dernière est présente, qu’il est question d’une requête partielle et qu’il s’agit d’un serveur HTTP/1.0 et
devrait utiliser l’ETag et la Last-Modified date de manière conjointe, pour de la validation conditionnelle, lorsqu’ils sont disponibles.

Conclusion

Dans cet article j’ai voulu reprendre un peu le fonctionnement des caches d’HTTP et les moyens que nous avons d’interagir avec eux. Ce n’est pas exhaustif pour autant puisqu’il reste quelques sujets utiles liés à ce sujet comme l’invalidation des caches par les requêtes PUT, DELETE et POST ou la construction des réponses depuis les caches.

J’espère que cet article vous aura éclairé sur les bonnes pratiques à adopter pour tirer parti des caches.

Quelques liens

RFC 2616 (en)
Caching Tutorial for Web Authors and Webmasters (fr)
Things caches do (en)
Exemple d’un Content Delivery Network (fr)

L’équipe Synbioz.

Libre d’être ensembles.

Un seul design pour aujourd'hui et demain, le responsive web design.

Jean Rémi Laisne — Fri, 04 May 2012 00:00:00 +0200

Les internautes accèdent de plus en plus à du contenu via les mobiles, les tablettes et sur d’autres supports comme les TV par exemple. Pour le consommateur, ces terminaux offrent des expériences différentes de navigation : des sites web aux rendus différents et des expériences parfois frustrantes, surtout lorsque l’on doit zoomer avec un smartphone. Devant la multitude de formats possibles, les utilisateurs n’accèdent et ne profitent généralement pas idéalement du site web qu’il consulte, même si vous avez pensé à prévoir des designs différents pour certains terminaux. Le responsive web design répond à cette tendance actuelle de consommation des contenus web sur différents supports et a pour objectif de proposer à l’utilisateur une expérience de navigation identique, quel que soit le terminal utilisé.

Le marché web et mobile

En effet en 2011, le marché est là et ne cesse de croître : 38 millions d’internautes, 18.3 millions de mobinautes et 1,5 million de tablettes en France. Autant de nouveaux segments de marché que les entreprises ne doivent pas perdre ! Les entreprises qui désirent maximiser leurs audiences afin d’augmenter leurs revenus, doivent donc désormais composer avec des consommateurs exigeants en matière de services web : leur expérience utilisateur doit être excellente sur tous les supports. Pour ce faire, de nombreuses possibilités s’offrent à elle.

Les marques et la maximisation de leur audience

Les marques et les objectifs du Responsive web design sont concomitants et s’inscrivent dans les normes web du W3C, en tous cas pour l’accessibilité du web par tous et partout. Le responsive web design répond donc à un objectif de maximisation des audiences et à l’augmentation de l’accessibilité des services web sur tout les supports. C’est à dire qu’il permet par la conception du design et de l’ergonomie à adapter le site web à toutes les résolutions existantes et notamment aux nouvelles résolutions qui fleurissent.

Nous allons voir dans cet article quelles sont les bases du responsive web design et sa composante technique différente du design classique.

Le responsive web design et la technique

Le responsive web design a une composante technique beaucoup plus forte que le design « traditionnel ». Il va s’aider des dernières normes de l’HTML5 et du W3C tel que le CSS3, les médias queries et les grilles flexibles. Le designer prend donc une place plus importante au sein de l’équipe et s’impliquera énormément avec l’ergonome et le concepteur web.

C’est donc une évolution du métier de designer qui devra posséder des compétences techniques plus fortes qu’auparavant.

Prenons tout d’abord un exemple d’un site avec un responsive web design : http://colly.com/

Ce n’est pas simplement une adaptation sur mobile ou tablette, vous pouvez jouer directement avec la taille de votre fenêtre et vous verrez que le site n’est pas figé. C’est idéal pour travailler avec des fenêtres réduites et l’accès à d’autres terminaux comme le mobile, vous l’aurez compris.

Une conception nouvelle.

Le responsive web design s’intéresse tout particulièrement au rendu sur le mobile autant que le rendu sur desktop. Au point qu’il remet en cause les principes de conception du design des interfaces d’application en concevant le design sur le mobile avant le design sur le desktop. Le designer concevra dès lors le design mobile en version adaptée voir allégée, puis ajoutera au fur et à mesure de sa conception des fonctionnalités, des différences graphiques ou des mises en avant de service adaptées aux terminaux sur des résolutions plus grandes. L’ergonome et le designer réfléchiront particulièrement aux différents scénarios de navigation sur les différents supports. Nous aurons donc une expérience utilisateur maximale sur tout les terminaux en mettant le plus difficile en première ligne de la conception et en optimisant son contenu.

Comme nous l’avons vu en introduction, le designer devra s’aider de l’HTML5 et du CSS3. L’HTML5 est formidable sur beaucoup de point, avant d’aller plus loin il faut tout de même mettre en garde son utilisation. L’HTML5 n’est pas compatible avec les anciennes versions de navigateurs. C’est à dire que les anciens navigateurs ne supportent pas les dernières implémentations de ces technologies. C’est donc une information cruciale, si vous voulez utiliser le responsive web design, il faut alors bien connaître vos auditeurs et utilisateurs. Mais il existe des solutions que j’exposerai un peu plus tard.

Pour que ces scénarios soit véritablement efficaces sur tous les supports, on se rend compte très rapidement qu’il faut identifier ce qui est pertinent pour les utilisateurs et pour le business model. L’important n’est pas de concevoir un site adapté au plus contraignant des terminaux mais de concevoir un site web qui correspond à ce que d’une part le consommateur recherche et d’autre part à ce qui est important pour votre entreprise.

L’aspect technique

A la différence du designer qui peut n’utiliser que photoshop pour concevoir un design, le responsive web design utilise trois composantes techniques clef qui sont :

Les grilles flexibles
Le CSS3
Les medias queries

Les grilles flexibles vous permettront d’adapter en proportion les éléments du sites web en fonction de la résolution et du terminal. La conception sous forme de grille est souvent représentée sous formes de plusieurs colonnes et cette conception ne peut pas être utilisée facilement sur mobile.

Pour que le design du site web soit parfait sur le mobile, il faudra alors utiliser les media queries. Il faut bien comprendre qu’en commençant par le mobile, ce sera le desktop avec les navigateurs qui vont gérer le plus de medias queries à la fin de la conception et non pas le contraire.

Optimisation

Le même design pour chaque média pose aussi un problème d’optimisation. Si les textes s’adaptent facilement dans les colonnes et à la variation de taille, il en est autrement pour les images et les videos. Et charger une image avec des tailles différentes ne sera pas optimale, surtout en 3G ou moins sur mobiles. Il faut donc d’une part que les images soit elles aussi flexibles, c’est à dire qu’on affiche une bonne image pour le bon format et notamment de ne charger que les éléments utiles au terminal. Pour cela je vous conseille de regarder du coté de Responsive Images et de scale video. Dernier lien pour l’optimisation, vous pouvez explorer Respond pour augmenter la compatibilité avec les anciennes versions de navigateurs.

Pour résumer les points positifs du responsive web design :

On a un seul design qui s’adapte à tous les terminaux.
On peut ne pas développer une application mobile (sauf si on utilise les capacités du mobile).
Plus besoin de concevoir un nouveau site web si un nouveau format apparaît.
Inutile de développer un site mobile spécifique.
Cela correspond au principe d’accessibilité du web.
Plus d’indépendance par rapport aux différents OS mobiles.

Pour aller plus loin :

Twitter Bootstrap

Smashing Magazine : responsive web design tutorial

Exemple de site responsive web design du blogwebdesign

L’équipe Synbioz.

Libres d’être ensembles.

Créer son propre Gem et le publier

Nicolas Cavigneaux — Thu, 26 Apr 2012 00:00:00 +0200

La meilleure façon de rendre son code ré-utilisable et de le partager est de publier un Gem qui pourra ainsi être chargé dans les projets via un Gemfile.

Bundler propose de créer pour nous la structure par défaut à utiliser pour pouvoir publier notre code sous forme de Gem.

Nous allons voir comment créer un Gem simple pour pouvoir ré-utiliser notre code à travers d’autres projets.

Création du squelette

La première chose à faire est de créer la structure de votre Gem. Nous pourrions créer tout le nécessaire à la main mais bundler peut s’occuper de ça pour nous.

Nous ne parlerons pas de gems tierces comme Hoe ou Echoe qui permettent de gérer la création de gems car nous considérons que bundler est amplement suffisant dans la majorité de cas. De plus ces gems ont été écrits avant que bundler (et son système de création de gems) n’existe. L’intérêt en est aujourd’hui limité.

Nous allons créer une lib très simple qui ajoutera une méthode à la classe String. Cette méthode devra retourner un hashage SHA1 de la chaîne. L’intérêt de cette article n’étant pas le code en lui même, nous nous cantonnerons à cet exemple simple.

Vous pouvez accéder à l’intégralité du code de notre exemple depuis le dépôt Github dédié.

  bundle gem string_to_sha1

    create  string_to_sha1/Gemfile
    create  string_to_sha1/Rakefile
    create  string_to_sha1/.gitignore
    create  string_to_sha1/string_to_sha1.gemspec
    create  string_to_sha1/lib/string_to_sha1.rb
    create  string_to_sha1/lib/string_to_sha1/version.rb
  Initializating git repo in /Users/cavigneaux/Synbioz/string_to_sha1

La commande crée pour nous un répertoire portant le nom du Gem et y inclut plusieurs fichiers. Un dépôt Git est également initialisé automatiquement.

Le fichier string_to_sha1.gemspec est celui qui permet de générer le gem. Voyons ce qu’il contient par défaut:

# -*- encoding: utf-8 -*-
$:.push File.expand_path("../lib", __FILE__)
require "string_to_sha1/version"

Gem::Specification.new do |s|
  s.name        = "string_to_sha1"
  s.version     = StringToSha1::VERSION
  s.authors     = ["Nicolas Cavigneaux"]
  s.email       = ["nico@bounga.org"]
  s.homepage    = ""
  s.summary     = %q{TODO: Write a gem summary}
  s.description = %q{TODO: Write a gem description}

  s.rubyforge_project = "string_to_sha1"

  s.files         = `git ls-files`.split("\n")
  s.test_files    = `git ls-files -- {test,spec,features}/*`.split("\n")
  s.executables   = `git ls-files -- bin/*`.split("\n").map{ |f| File.basename(f) }
  s.require_paths = ["lib"]

  # specify any dependencies here; for example:
  # s.add_development_dependency "rspec"
  # s.add_runtime_dependency "rest-client"
end

On voit donc assez clairement ce qu’on doit modifier dans ce fichier puisque les chaînes en question sont marquées d’un “TODO”.

Pour résumer, cette spécification de Gem contient donc :

le nom sous lequel le gem sera connu
sa version
le ou les auteurs sous forme d’un tableau
le ou les emails des auteurs / contacts
la page de présentation du projet (page dédiée, github, rdoc, …)
un résumé à modifier pour décrire succintement le gem
un descriptif plus précis
le projet RubyForge associé (facultatif)

En plus de cela, d’autres attributs sont définis automatiquement. Ils sont déduits de la liste de fichiers gérés par Git. On a donc une génération automatique de la liste des fichiers à inclure dans le gem, de ceux qui servent aux tests ainsi que des éventuels executables.

Cette technique est très pratique puisque si vous utilisez Git pour versionner votre code, la liste de fichier dans le Gemfile sera toujours à jour sans que vous n’ayez à vous en soucier. Il reste évidemment possible de définir cette liste de fichier (tableau) à la main ou encore d’adapter les commandes pour utiliser votre SCM préféré.

Voici un exemple d’utilisation avec Mercurial :

s.files         = `hg manifest`.split("\n")
s.test_files    = `hg manifest`.split("\n").select { |f| f =~ /^(test|spec|features)/ }
s.executables   = `hg manifest`.split("\n").select { |f| f =~ /^bin/ }.map{ |f| File.basename(f) }

Le code

Voyons maintenant les fichiers qui contiendront notre code :

lib/string_to_sha1/version.rb :

module StringToSha1
  VERSION = "0.0.1"
end

qui permet de définir la version de votre Gem avant publication. Il faudra donc penser à incrémenter la version avant chaque publication.

Pour mémoire, les numéros de version sont souvent composés de la façon suivante :

X.Y.Z où :

X est le numéro de version majeur
Y est le numéro de version mineur
Z est le numéro de patch

On va donc incrémenter X à chaque ajout de fonctionnalité majeure, ou de modifications rendant la nouvelle version incompatible avec l’ancienne. On incrémentera Y pour chaque ajout de fonctionnalité mineure et Z pour chaque release de patch (correction de bug) qui sera faite.

lib/string_to_sha1.rb :

require "string_to_sha1/version"

module StringToSha1
  # Your code goes here...
end

C’est ce fichier qui sera chargé automatiquement lorsque votre gem sera chargé dans un projet. On peut mettre notre code directement dans ce fichier ou découper notre code en unités logiques qu’on placera dans des fichiers dédiés dans lib/.

Cette seconde méthode est certainement la plus propre si votre projet contient plus que quelques lignes de code. Dans notre exemple, le code étant très simple, nous nous cantonnerons à ce fichier. Voici donc les modifications à apporter pour pouvoir convertir facilement une chaîne en hashage SHA1 :

require "string_to_sha1/version"
require "digest/sha1"

class String
  def to_sha1
    Digest::SHA1.hexdigest(self)
  end
end

On charge la librairie sha1 et on ré-ouvre la classe String (Monkey Patching) pour y ajouter notre méthode.

Voilà, nous avons notre code, il ne reste plus qu’à publier le gem pour pouvoir l’utiliser dans d’autres projets.

Environnement de développement

Avant de passer à la publication, voyons deux fichiers dont nous n’avons pas parlé jusque là, ce sont le Gemfile et le Rakefile :

Gemfile

source "http://rubygems.org"

# Specify your gem's dependencies in string_to_sha1.gemspec
gemspec

Une seule instruction est présente dans ce Gemfile, gemspec. Ce fichier n’est en fait qu’un “proxy” qui va aller chercher ses dépendances directement dans string_to_sha1.gemspec. Une bonne pratique est de tester son code pour s’assurer qu’il fonctionne comme prévu, nous pourrions donc vouloir charger des outils de test :

string_to_sha1.gemspec :

# -*- encoding: utf-8 -*-
$:.push File.expand_path("../lib", __FILE__)
require "string_to_sha1/version"

Gem::Specification.new do |s|
  s.name        = "string_to_sha1"
  s.version     = StringToSha1::VERSION
  s.authors     = ["Nicolas Cavigneaux"]
  s.email       = ["nico@bounga.org"]
  s.homepage    = "http://github.com/synbioz/string_to_sha1"
  s.summary     = %q{Add SHA1 hashing from string}
  s.description = %q{This gem add a facility method to easily convert existing string to SHA1 hash.}

  s.rubyforge_project = "string_to_sha1"

  s.files         = `git ls-files`.split("\n")
  s.test_files    = `git ls-files -- {test,spec,features}/*`.split("\n")
  s.executables   = `git ls-files -- bin/*`.split("\n").map{ |f| File.basename(f) }
  s.require_paths = ["lib"]

  s.add_development_dependency "minitest"
  s.add_development_dependency "guard-minitest"
end

On peut maintenant utiliser bundler pour installer nos dépendances de développement :

$ bundle

Fetching source index for http://rubygems.org/
Installing ffi (1.0.11) with native extensions
Installing thor (0.14.6)
Installing guard (1.0.1)
Installing guard-minitest (0.5.0)
Installing minitest (2.12.1)
Using string_to_sha1 (1.0.0) from source at /Users/cavigneaux/Synbioz/string_to_sha1
Using bundler (1.0.21)

Il est donc très simple pour n’importe qui de reprendre le code et d’installer les dépendances de développement sur sa machine pour contribuer.

Si vous pensez publier publiquement votre Gem, il est de bon ton d’ajouter un fichier README qui explicitera votre projet, ses fonctionnalités, les moyens d’y contribuer, les commandes pour préparer l’environnement de développement, …

Rakefile :

require "bundler/gem_tasks"

Que nous apporte bundle ?

$ rake -T

rake build    # Build string_to_sha1-0.0.1.gem into the pkg directory
rake install  # Build and install string_to_sha1-0.0.1.gem into system gems
rake release  # Create tag v0.0.1 and build and push string_to_sha1-0.0.1.gem to Rubygems

Nous avons donc une tâche pour construire le gem, une pour l’installer sur le système à des fins de test et une autre pour releaser notre Gem sur Rubygems.org et tagguer notre code par la même occasion. Des outils simples mais utiles en phase de développement.

Publication

Notre première version est prête, nous allons donc modifier le Gemspec avant de lancer la construction du gem.

string_to_sha1.gemspec :

# -*- encoding: utf-8 -*-
$:.push File.expand_path("../lib", __FILE__)
require "string_to_sha1/version"

Gem::Specification.new do |s|
  s.name        = "string_to_sha1"
  s.version     = StringToSha1::VERSION
  s.authors     = ["Nicolas Cavigneaux"]
  s.email       = ["nico@bounga.org"]
  s.homepage    = "http://github.com/synbioz/string_to_sha1"
  s.summary     = %q{Add SHA1 hashing from string}
  s.description = %q{This gem add a facility method to easily convert existing string to SHA1 hash.}

  s.files         = `git ls-files`.split("\n")
  s.test_files    = `git ls-files -- {test,spec,features}/*`.split("\n")
  s.executables   = `git ls-files -- bin/*`.split("\n").map{ |f| File.basename(f) }
  s.require_paths = ["lib"]

  s.add_development_dependency "minitest"
  s.add_development_dependency "guard-minitest"
end

lib/string_to_sha1/version.rb :

module StringToSha1
  VERSION = "1.0.0"
end

Nous sommes maintenant prêts pour la génération :

$ gem build string_to_sha1.gemspec

  Successfully built RubyGem
  Name: string_to_sha1
  Version: 1.0.0
  File: string_to_sha1-1.0.0.gem

Et voilà un gem tout frais, prêt à l’utilisation, vous pouvez donc par exemple l’installer avec rake install puis le tester en console :

>> require "rubygems"
=> true
>> require "string_to_sha1"
=> true
>> s = "Bundler is a great tool!"
=> "Bundler is a great tool!"
>> s.to_sha1
=> "82c66f602918c5050041d8687e3413b3ae9f5e73"

Il semble donc que notre gem fonctionne ! Nous pouvons passer à l’étape suivante, le partager.

Github

C’est souvent une bonne idée de publier son code open-source sur Github pour gagner en visibilité mais aussi parce que d’autres outils intéressants sont couplés à Github.

Il faudra donc commencer par créer un dépôt pour accueillir votre code. Une fois le dépôt préparé, il faut définir cette adresse comme origine dans la config git de notre projet et y pousser notre code :

$ git remote add origin git@github.com/synbioz/string_to_sha1
$ git add .
$ git commit -m "First release"
$ git push origin master

Vous remplacerez bien évidemment l’url par celle de votre dépôt. Votre code est maintenant visible sur github, peut être cloné ou encore forké.

Autre petit plus, il est désormais possible pour quiconque d’utiliser votre gem dans son Gemfile en utilisant directement le code hébergé par Github :

gem "string_to_sha1", git: "git://github.com/synbioz/string_to_sha1.git"
gem "string_to_sha1", git: "git://github.com/synbioz/string_to_sha1.git", branch: "develop"
gem "string_to_sha1", git: "git://github.com/synbioz/string_to_sha1.git", tag: "v1.0.0"

Cette possibilité est très intéressante car non seulement vous pouvez avoir accès à tout instant sous forme de gem à la dernière version du code mais vous pouvez aussi préciser une branche, un tag ou une version à utiliser !

Rubygems

L’étape suivante consiste à publier son gem sur Rubygems.org, le dépôt officiel de gems.

Nous allons donc utiliser la tâche rake dédiée pour publier notre gem :

$ rake release

string_to_sha1 1.0.0 built to pkg/string_to_sha1-1.0.0.gem
Tagged v1.0.0
Pushed git commits and tags
Pushed string_to_sha1 1.0.0 to rubygems.org

En une seule commande, notre gem a été généré et publier sur Rubygems. Notre code a également été taggé en v1.0.0 et pushé sur notre dépôt github.

Parfait, exactement ce que nous voulions faire.

Notez que si c’est la première fois que vous publiez sur Rubygems, la commande vous demandera d’entrer vos identifiants.

Sur github, un tag est apparût et notre gem figure maintenant sur Rubygems

Il est désormais possible pour quiconque d’ajouter votre gem à son projet via le Gemfile de manière classique :

gem "string_to_sha1"

Ce sera donc la dernière version disponible sur Rubygems qui sera chargée.

Vous connaissez maintenant tout (ou presque) sur les rouages de la publication de gems, voyons tout de même quelques derniers points trop souvent délaissés.

Documentation du code

N’oubliez pas de commenter votre code pour faciliter sa lecture, sa compréhension et donc les contributions. Vous pouvez documenter votre code via RDoc ou son extension YARD qui permet d’aller plus loin.

Votre code documenté et publié sur Github, vous n’aurez plus à vous soucier de rien, vous aurez accès à la documentation de votre gem auto-générée et disponible sur rubydoc.info.

Si cette dernière n’apparaît pas, vous pouvez (en haut à droite de la page d’accueil) demander une génération de la documentation à partir de votre dépôt git.

Notez que le README est la première page affichée, la barre de gauche vous permettant de naviguer à travers fichiers, classes et méthodes.

Communiquer et buzzer

Maintenant que votre gem a été publié dans les règles de l’art, il est temps de faire connaître votre travail au reste de la communauté.

Deux sites sont absolument incontournables pour vous faire connaître, Ruby Toolbox qui permet de rechercher un gem par catégorie, comparer un gem avec ses alternatives, etc. Il y a ensuite Ruby Flow qui est un site d’agrégation des news relatives à Ruby, un vrai tremplin pour votre gem s’il est différenciant !

En ce qui concerne la communauté francophone, il y a un équivalent Ruby Live

Si vous souhaitez en savoir plus sur la création de gems, l’API de RubyGems.org et plus encore, je vous conseille ces guides.

J’espère donc que cet article de découverte vous encouragera a publier votre travail et à entretenir la force de la communauté Ruby, son ouverture et son sens du partage.

L’équipe Synbioz.

Libres d’être ensembles.

Génération de données de test, fixtures ou factories ?

Alexandre Salaün — Wed, 18 Apr 2012 00:00:00 +0200

Lors du développement de votre application Rails il est important d’avoir des jeux de données afin de pouvoir naviguer dans cette dernière ou effectuer des tests. Il y a différents outils qui vous permettent de générer ces données. Les fixtures sont l’outil par défaut pour cela. Via des fichiers Yaml vous pouvez donc avoir un jeu de données. Les factories se révèlent également utiles pour la génération de données de test. Quand est-il préférable d’utiliser l’un par rapport à l’autre, c’est ce que nous allons essayer de voir ici.

Il ne faut pas non plus oublier que les seeds servent à générer des données mais dans un registre légèrement différent. En effet, les données présentes dans les seeds sont des données en dur qui sont utiles au bon fonctionnement de l’application. Ces dernières ne seront pas modifiées par la suite.

Fixtures

Les fixtures sont disponibles par défaut dans une application Rails, il n’est donc pas nécessaire d’installer de gem. Il vous suffit d’ajouter les fichiers Yaml correspondants aux modèles que vous souhaitez tester. Pour créer des données pour un modèle Post par exemple, un fichier posts.yml sera utilisé.

post_1:
  title: Post title
  content: Lorem ipsum...
  visible: true

post_2:
  title: Post title 2
  visible: false

Il est également possible d’utiliser du code Ruby dans vos fixtures afin de générer vos données :

<% 10.times do |i| %>
post_<%= i %>:
  title: Post <%= i %> title
  content: Lorem ipsum...
  visible: true
  created_at: <%= 2.days.ago %>
<% end %>

En ce qui concerne les associations, vous avez plusieurs possibilités. En donnant le nom de votre fixture liée :

# Model Post
post_1:
  title: Post title
  content: "Lorem ipsum..."
  visible: true
  author: author_1

post_2:
  title: Post title 2
  visible: false
  linked_post: post_1

# Model Author
author_1:
  name: Test Author

On fait donc référence aux objets post_1 et author_1 via le nom donnée à ces fixtures. Il est également possible d’utiliser la méthode Fixtures.identify pour trouver l’objet associé.

# Model Post
post_1:
  title: Post title
  content: Lorem ipsum...
  visible: true
  author_id: <%= ActiveRecord::Fixtures.identify(:author_1) %>

post_2:
  title: Post title 2
  visible: false
  linked_post_id: <%= ActiveRecord::Fixtures.identify(:post_1) %>

# Model Author
author_1:
  name: Test Author

Ensuite, pour utiliser vos fixtures dans vos tests, il suffit de les charger dans votre fichier de test via la ligne suivante :

fixtures :all # Pour charger toutes les fixtures
fixtures :posts # Pour charger uniquement celles concernant le modèle Post

Enfin, lorsque vous souhaitez utiliser une fixture, vous n’avez qu’à l’utiliser comme dans le cas suivant :

assert posts(:post_1).title.blank? # => false
assert posts(:post_1).title.present? # => true

Autre information à propos des fixtures, les validations sur les modèles ne sont appliquées lors de la création de ces dernières. Vous pouvez donc avoir des objets non valides lorsque vous utilisez vos fixtures.

Les fixtures sont donc très utiles pour avoir des données correspondant aux différents cas d’utilisation. Cependant, la création des fixtures peut s’avérer longue. En effet, créer les fixtures une par une, lorsqu’il s’agit d’un projet avec de nombreux modèles, est assez coûteux en temps, d’où l’intérêt d’utiliser du code Ruby pour les générer.

Factories

Les factories sont des générateurs d’objets tandis que les fixtures sont des objets prédéfinis. C’est ce qui différencie principalement ces deux moyens de générer des données.

Contrairement aux fixtures, les factories ne sont pas intégrées par défaut dans les applications Rails, il est donc nécessaire d’installer une gem. Il en existe différentes, la plus répandue étant FactoryGirl.

FactoryGirl

FactoryGirl est donc une gem permettant de créer des données pour vos tests. Pour l’installer, il vous suffit d’ajouter la gem dans votre Gemfile puis de lancer la commande bundle install :

gem "factory_girl_rails", "~> 3.0"

Ensuite, vous pourrez créer vos factories dans le fichier factories.rb ou bien dans des fichiers séparés par modèle si vous le souhaitez. Par défaut, les factories se trouvant dans les fichiers suivants sont chargées :

test/factories.rb
spec/factories.rb
test/factories/*.rb
spec/factories/*.rb

Afin de définir des données pour le modèle Post vous pouvez donc utiliser FactoryGirl comme suit :

FactoryGirl.define do
  factory :post do
    title "Post title"
    content "Lorem ipsum..."
    visible  true
  end

  factory :not_visible , class: Post do
    title "Post title 2"
    visible  false
  end
end

Il est également possible d’utiliser d’autres champs de l’objet pour définir la valeur d’un champ :

FactoryGirl.define do
  factory :user do
    firstname "Alexandre"
    lastname "Salaun"
    email { "#{firstname}.#{lastname}@test.com".downcase }
  end

En ce qui concerne les associations, il est possible d’utiliser uniquement le nom du modèle si la factory a ce même nom ou bien en spécifiant la factory si ce n’est pas le cas :

FactoryGirl.define do
  factory :author do
    firstname "Alexandre"
    lastname "Salaun"
    active true
  end

  factory :author_inactive do
    firstname "Alexandre"
    lastname "Salaun"
    active false
  end

  factory :post do
    title "Post title"
    content "Lorem ipsum..."
    author
  end

  factory :post_2 do
    title "Post title"
    content "Lorem ipsum..."
    association :author, factory: :author_inactive
  end

L’un des avantages de FactoryGirl, par rapport aux fixtures et aussi à certaines autres gem, est la possibilité de définir des séquences, ce qui permet d’avoir des valeurs uniques.

factory :user do
  sequence(:email) {|n| "user_#{n}@test.com" } # => user_1@test.com ; la valeur de n est incrémentée à chaque appel
end

Ensuite, dans vos tests il est possible d’utiliser les factories que vous avez préalablement définies :

post = FactoryGirl.create(:post)

FactoryGirl propose différentes méthodes afin de vous aidez dans vos tests :

# build => à l'image de la méthode build de Rails, on instancie un objet Post avec les données de la factory mais l'objet n'est pas sauvé
post = FactoryGirl.build(:post)

# create => instancie un objet Post et le sauve
post = FactoryGirl.create(:post)

# attributes_for => retourne une Hash avec les attributs définis pour la factory
post_attrs = FactoryGirl.attributes_for(:post)

# build_stubbed => retourne un objet Post avec les attributs définis qui sont stubbés
post_stub = FactoryGirl.build_stubbed(:post)

Avec FactoryGirl, il est également possible d’utiliser Blueprint si cela vous convient mieux. Pour cela, il faut que vous ajoutiez les lignes suivantes dans vos tests :

require "factory_girl/syntax/blueprint"
require "factory_girl/syntax/make"

Ensuite, vous pouvez donc utilisez cette syntaxe :

User.blueprint do
  name  { "Test User" }
  email { "test@test.com" }
end

User.make(name: "Test")

Contrairement aux fixtures, pour lesquelles vous pouvez avoir des objets non valides, tous les objets créés via la méthode FactoryGirl.create() sont valides. En effet, ici les validations du modèle sont appliquées lors de la création et seul des objets valides peuvent donc être créés.

Les autres gems

Il existe différentes alternatives à FactoryGirl parmi lesquelles miniskirt ou Machinist.

MiniSkirt

MiniSkirt est une gem au comportement assez similaire à FactoyGirl. En effet, comme pour cette dernière il vous faut définir des factories dans un (ou plusieurs) fichier. Pour l’installer, il suffit d’ajouter la gem à votre Gemfile puis de lancer la commande bundle install :

gem "miniskirt"

Ensuite, vous devez ajouter miniskirt dans votre test_helper.

require "miniskirt"
require "factories" # il est nécessaire d'jouter cette ligne si vous définissez des factories dans le fichier  test/factories.rb

En ce qui concerne l’usage de cette gem, il est également possible de définir des séquences, la syntaxe est légèrement différente :

factory :user do |f|
  f.email "user%d@test.com" # %d va donc être incrémenté à chaque appel
end

Les méthodes attributes_for n’est pas disponible via MiniSkirt, pour la remplacer il vous faut utiliser la syntaxe suivante :

# attributes_for
Factory.build(:user).attributes

build_stubbed se voit reserver le même traitement et il est donc nécessaire de stubber comme vous l’auriez fait avec n’importe quelle méthode ou attribut d’un objet.

Les associations sont également définies légèrement différemment :

factory :post do |f|
  f.title "Post title"
  f.author { Factory :author }
end

Machinist

Cette gem a quant à elle un fonctionnement légèrement différent. En effet, on utilise ici Blueprint pour définir nos objets.

Pour l’installer, il faut ajouter la gem à votre Gemfile puis l’installer via bundle install :

gem 'machinist', '>= 2.0.0.beta2'

Ensuite, vous devez finaliser l’installation grâce à la commande suivante :

rails generate machinist:install

Pour définir votre object, la syntaxe est la suivante :

Post.blueprint do
  title  { "Post title" }
  content   { "Lorem ipsum..." }
end

Puis, utilisez la méthode make! pour créer cet objet.

Post.make!

Machinist permet aussi de définir des associations, des valeurs uniques pour des champs donnés… tout comme le permettent les gems précédentes.

Les factories ont donc des avantages et des inconvénients tout comme les fixtures. Elles permettent de créer un plus grand nombre de données dans un temps plus court.

Fabrication

Fabrication est une autre alternative. Elle permet la génération d’objets. Il suffit de définir des Fabricators puis vous pourrez créer vos objets dans vos tests ou même dans votre application.

Pour l’installer, il faut ajouter la gem à votre Gemfile puis lancer la commande bunde install :

gem 'fabrication'

Vous pouvez ensuite définir vos Fabricators. Ceux définis dans les fichiers suivants seront chargés par défaut :

spec/fabricators/**/*fabricator.rb
test/fabricators/**/*fabricator.rb

Les Fabricators sont définis de la manière suivante :

Fabricator(:post) do
  title "Test post"
  content "Lorem ipsum..."
end

Fabricator(:post_2, :from => :post) do
  title "Test post"
  content "Lorem ipsum..."
end

Vous donnez donc le nom souhaité à votre Fabricator puis le nom de la classe (si le nom du Fabricator n’est pas déjà celui de la classe). Ensuite, comme pour les autres outils, vous définissez vos champs.

Pour les associations, vous pouvez donner directement le nom de l’objet associé ou bien spécifié le Fabricator souhaité :

Fabricator(:author) do
  name "Author Test"
end

Fabricator(:author_2, :from => :author) do
  name "Author Test"
end

# avec le nom de l'objet
Fabricator(:post) do
  author
end

# en spécifiant le fabricator
Fabricator(:post_1) do
  author { Fabricate(:author_2) }
end

Il est également possible d’utiliser des callbacks ou des alias pour vous aider dans votre génération de données.

Enfin, pour utiliser vos générateurs, il vous faut utiliser Fabricate :

Fabricate(:post)

# en spécifiant des attributs
Fabricate(:post, :title => "Article 1")

Les méthodes build et attributes_for vous permettent également de générer un objet sans le sauver ou d’en récupérer les attributs. Et, tout comme pour FactoryGirl ou MiniSkirt, vous pouvez utiliser des séquences si vous le souhaitez.

Les usages

Les usages peuvent donc être assez différents entre fixtures et factories même si le principe de base est le même : la création de données pour effectuer des tests.

Les fixtures, avantages et inconvénients ?

Si vous avez des objets avec des valeurs spécifiques à créer il est sans doute préférable de le faire via des fixtures car vous pouvez créer vos objets un par un et donc affecter une valeur à chaque attribut. Il est bien sûr également possible de le faire via des factories mais pourquoi ajouter une gem lorsque ce que vous souhaitez faire est disponible de base ?

De plus, les fixtures peuvent aussi servir à générer des données pour votre environnement de développement.

L’un des principaux point négatif des fixtures est la difficulté à maintenir ces dernières. En effet, si vous avez un nombre important de scénarios, vous aurez donc un nombre important de fixtures et il est parfois difficile de s’y retrouver. De plus, il devient parfois difficile de savoir si telle ou telle fixture est toujours utilisée au cours de l’évolution de vos tests.

En outre, la création des fichiers Yaml pour la génération des fixtures peut être chronophage.

Les factories, avantages et inconvénients ?

Si, par contre, vous souhaitez plutôt créer une quantité importante de données les factories peuvent êtres plus utiles. En effet, les séquences par exemple permettent de s’assurer de l’unicité de valeurs alors qu’avec les fixtures il faut le vérifier lors de la création dans votre fichier yaml.

D’autre part, si pour définir un objet, vous souhaitez utiliser des valeurs d’autres champs de ce dernier, vous pouvez le faire via les factories.

L’utilisation de factories plutôt que de fixtures a également pour effet d’améliorer la vitesse de vos tests. En effet, avec les factories vous ne chargez en base que les objets dont vous aurez besoin pour le test alors qu’avec les fixtures vous ne pouvez pas spécifier quels objets charger en base. Il peut donc y avoir un gain de performance.

La création d’objet valide ou invalide peut être une contrainte déterminante dans le choix de l’outil. Comme nous l’avons vu plus tôt, les fixtures permettent de créer des objets non valides, alors que FactoryGirl crée uniquement des objets valides.

Ces deux outils peuvent être utilisés en parallèle si cela est nécessaire.

Conclusion

Les fixtures et les factories peuvent donc s’avérer complémentaires suivant les cas d’utilisation. C’est à vous de voir ce qui correspond le mieux suivant les données que vous voulez générer. Il est utile de rappeler une nouvelle fois l’utilité des tests dans votre application Rails. Différents outils de tests vous sont présentés dans les articles précédents tels que Capybara ou bien Minitest.

L’équipe Synbioz.

Libres d’être ensembles.

Présentation de backbone.js

Martin Catty — Thu, 12 Apr 2012 00:00:00 +0200

Présentation de Backbone.js

Backbone.js est un cadre applicatif pour les applications à forte teneur en javascript.

Backbone.js peut se définir comme un framework MVC mais pas au sens classique du terme. Ici le C représente des Collections d’objets. Le M et le V désignent respectivement les modèles et les vues.

Backbone.js ne possède qu’une dépendance ferme, il s’agit de underscore.js, qui est maintenu par la même équipe.

Le rôle d’underscore.js est de vous apporter tout un tas de méthodes pour vous simplifier la vie (enumerable, binding, template, comparaison…) sans faire 500ko.

Généralement jQuery vient compléter la liste des dépendances finales de l’application, car il y a fort à parier que vous aurez à minima besoin de manipuler le DOM.

Quand utiliser Backbone.js

Backbone.js est un excellent choix pour les applications dites «single page application», c’est à dire une page principale avec un nombre important d’interactions utilisateur.

Plutôt que d’avoir une navigation classique par page (ou le serveur envoie toute la page à chaque URL), la navigation, l’envoi de formulaire et toutes les actions classiques se gèrent en javascript.

Avant, quand on souhaitait faire ce genre de choses, on écrivait son propre javascript, sans aucune convention, ầ grand coup d’AJAX et on se retrouvait vite avec du spaghetti code, complexe à maintenir et à tester.

Backbone.js nous permet de cadrer cela en définissant modèle, vue et collections. On va pouvoir définir des événements sur des changements de valeurs de nos modèles et ainsi rafraichir automatiquement nos vues.

Pour cela Backbone.js possède son propre routeur. On peut faire correspondre des actions à des URL.

Le code créé avec Backbone.js peut être testé via jasmine.

Ce que Backbone.js ne fait pas

Backbone.js est uniquement une couche client, il n’a aucune vocation à gérer la persistence de vos données sur un serveur.

Mais rassurez vous cela se fait très bien, il suffit d’indiquer à nos modèles une URL et d’avoir une API JSON Restful pour être capable de réaliser du CRUD très simplement.

Apprentissage par la pratique

L’objectif de cette première partie est de créer une application qui va lister les catégories récupérées depuis le serveur.

L’application backbone.js est disponible sur github.

Le tag 0.1 correspond à cette partie.

Aperçu rapide de la partie serveur

Pour la persistence des données nous utilisons une application Ruby on Rails qui agit uniquement comme une API.

Nous avons une migration pour créer des catégories qui ont un nom, ainsi que quelques seeds. Une fois l’application clonée il vous reste à configurer votre base de données (database.yml) et lancer le chargement:

  bin/rake db:setup

Notre contrôleur categories renvoie uniquement du JSON.

class CategoriesController < ApplicationController
  respond_to :json

  def index
    @categories = Category.all
    respond_with(@categories)
  end
end

On va donc pouvoir récupérer nos catégories sur /categories.json

La partie client avec Backbone.js et coffeescript

Pour son côté pratique et maintenant par habitude, le code est en coffeescript. Jetez un œil à notre introduction à coffeescript si vous ne connaissez pas encore. Vous ne serez pas trop dépaysés.

Le fichier principal est app.coffee, il est généré dans app.js Si vous souhaitez faire des changements en local pour tester, vous pouvez utiliser le Guardfile fournit via:

  bin/guard

Il s’occupera de compiler votre coffeescript à la volée.

Explication du code Backbone.js

Logiquement notre application devrait être découplée en plusieurs fichiers, en séparant modèle, vue etc…

Ici la simplicité de l’application fait que tout est en un seul fichier. Commençons à décortiquer le code.

@app = window.app ? {}

Afin que les fichiers javascript puissent avoir connaissance les uns des autres on utilise l’objet global windows et le namespace app.

_.templateSettings = {
    interpolate: /\{\{\=(.+?)\}\}/g,
    evaluate: /\{\{(.+?)\}\}/g
};

Underscore.js possède un système de template, dont la syntaxe par défaut est la même que celle des templates ERB.

Nous changeons cela pour qu’ERB n’essaie pas de les interpréter, ce sera le rôle de Backbone.js.

Pour cela nous modifions les paramètres du template pour avoir une syntaxe proche de celle de mustache.

On va donc passer de <% %> à {{ }}.

Définition du modèle

  class Category extends Backbone.Model

Notre catégorie va simplement étendre le modèle de base de Backbone.js pour hériter de toutes ces méthodes (save…).

Ici on utilise directement le mécanisme de coffeescript. Par convention le modèle est au singulier.

En javascript on aurait plutôt:

  var Category = Backbone.Model.extend({})

Une fois notre classe créée nous la mettons dans le namespace. Nous le ferons systématiquement pour les autres classes, quelque soit leur fonction.

Définition de la collection

  class Categories extends Backbone.Collection
    url: "/categories"
    model: app.Category
  @app.Categories = Categories

La collection se trouve à mi chemin entre la vue et le modèle. Elle concerne un modèle dont elle contiendra une liste, dont le but sera d’aller peupler une vue.

Par convention la collection est au pluriel.

Partant de là nous sommes déjà en mesure de récupérer les données de l’API. Vous pouvez tester depuis la console de votre navigateur:

  categories = new window.app.Categories()
  categories.fetch()
  categories.models
  # [Category, Category]

Définition des vues

Regardons comment définir un template dans nos vues HTML.

  <script type="text/template" id="category">
    {{= name }}
  </script>

Les templates sont définis dans le head de notre HTML, de base le navigateur n’interprétera rien. Comme mentionné plus tôt nous utilisons la syntaxe de mustache.

Le but pour ces templates est d’être remplacé par le HTML correspondant à ce qu’on souhaite afficher par Backbone.js.

Par exemple #category représentera un élément LI contenant le nom de la catégorie.

Voyons comment est définie notre classe du côté de Backbone.js:

class CategoryView extends Backbone.View
  tagName: 'li'
  template: _.template($('#category').html())

  initialize: ->
    _.bindAll(@, 'render')

  render: ->
    @.$el.html @template(@model.toJSON())
    @
@app.CategoryView = CategoryView

Nous spécifions donc le tagName qui servira à l’enrobage HTML. Il existe d’autres options comme la classe CSS…

Ensuite nous indiquons quel est le template à utiliser (#category). C’est cette définition qui justifie l’enrobage $(document).ready, afin que le DOM soit prêt pour l’initialisation des templates.

Autrement on peut toujours les initialiser dans le constructeur de la vue mais cela impliquera un calcul à chaque instanciation d’objet, donc ce n’est pas recommandé.

Dans le constructeur nous allons nous assurer que le rendu de la vue se fera toujours dans le contexte de cet objet (this).

En effet le render pourra être appelé depuis d’autres endroits, notamment le modèle.

Dans ce cas nous voulons nous assurer que le this courant s’apparentera toujours à cette vue. Nous utilisons pour cela bindAll.

Enfin la méthode render va se servir du modèle que nous lui aurons passé pour générer notre LI.

Plutôt que d’appeler $(@el) on utilise @.$el qui permet d’éviter d’accéder à chaque fois au DOM en stockant une référence à l’élément.

Render doit toujours retourner this afin de pouvoir chainer les appels.

Un petit test en console:

  // creation de la categorie
  var category = new window.app.Category({ name: "Synbioz" })
  // creation de la vue
  var view = new window.app.CategoryView({ model: category })

  var content = view.render()
  content.el
  // <li>Synbioz</li>

Regardons maintenant la vue qui listera l’ensemble des catégories:

class CategoriesView extends Backbone.View
  tagName: 'ul'
  template: _.template($('#categories').html())

  initialize: ->
    _.bindAll(@, 'render')
    @collection.bind 'reset', @render

  render: ->
    @.$el.html(@template())
    node = @.$('.categories')
    collection = @collection
    @collection.each (category) ->
      view = new CategoryView
        model: category
        collection: collection
      node.append view.render().el
    @

Avec le binding du reset sur la collection nous introduisons toute la puissance de Backbone.js. Ce code va permettre de surveiller la collection, et de faire automatiquement un render de la vue associée.

Dans la méthode render nous allons utiliser la vue précédente pour générer chaque catégorie et l’ajouter à la liste.

Plutôt que de rechercher .categories dans tout le DOM nous limitons la portée au template, ce qui est nettement plus efficace.

Définition du routeur

Le routeur va nous permettre de définir les routes de notre application. Il définit les routes en GET en faisant matcher l’URL courante sur une action.

class MetricsRouter extends Backbone.Router
  routes:
    '': 'dashboard'

  initialize: ->
    window.categories = new app.Categories()
    @categoriesView = new app.CategoriesView
      collection: categories

  dashboard: ->
    window.categories.fetch()
    $("#container").html(@categoriesView.el);

@app.MetricsRouter = new MetricsRouter()

Dès que nous serons sur la home, la méthode dashboard sera appelée. Dans celle ci on récupère les catégories, ce qui exécute directement un rendering de la vue associée.

Il ne reste qu’à l’ajouter dans le DOM.

Lancement de l’application

Maintenant que tout est en place, lançons l’application:

  Backbone.history.start()

Nous n’avons pas encore de navigation mais cela n’en demeure pas moins indispensable.

Par défaut les URL sont gérées comme celles de twitter, avec un #. Mais il existe une option (pushState) qui permet d’utiliser les possibilités d’HTML5 pour mettre à jour l’historique en javascript.

Ainsi pour votre navigateur c’est complètement transparent, la navigation s’apparente à une navigation classique.

Conclusion

Le rapport puissance / taille du code du Backbone.js est assez impressionnant. Il permet de créer des applications plus fluides et réactives en limitant les aller / retour avec le serveur.

Ce cadre applicatif permet d’avoir du code bien organisé, qui plus est testable avec jasmine.

Dans la prochaine partie nous allons gérer toute la partie événementielle et formulaire afin de pouvoir interagir avec la page et naviguer comme dans une application classique.

L’équipe Synbioz.

Libres d’être ensembles.

Introduction to Ruby code optimization

Nicolas Zermati — Wed, 28 Mar 2012 00:00:00 +0200

Introduction to Ruby code optimization (part 1/2)

Okay, so here we are. We have finally released the beta version of our Ruby application. Problem is, we added a bigger dataset to our beta and now, our app become too slow. Some user have been complaining about it. Even though we were keeping a careful eye on performance issues when we coded this app, bad surprises can still happen. Not so good algorithms, slow IO or architecture issues are some typical causes of performances problems.

There are many ways to find bottlenecks in programs. You may already be aware of what’s wrong but you could also have no clue where to look. Today, I’ll give advice that cover the « no clue » case.

Profiling

In our quest to find out where a bottleneck could hide, Ruby provides classical but efficient weapons: profiling tools. Profiling is a runtime analysis that gathers information about memory usage, function calls, elapsed time in functions, etc. There are different methods to collect information from a running program:

instrumentation way that adds program instructions,
event-based way that adds hooks to trap program events and
sampling way that interrupts the program to look inside its memory space.

Depending on what you are looking for, profiler outputs different results: calls graph, object allocation, etc.

Ruby’s default profiler

Ruby have a built-in module called Profiler__ (source) that records function calls. In order to use this profiler, you must run ruby with -r profile option that will require the profile.rb file (source). If you look at the source codes then you will see how simple this profiler is (60 LOC). It is an event-based profiler that uses the Kernel#set_trace_func method (doc) to trap all the function calls.

The output and the performance of this module isn’t satisfying. I won’t, therefore, provide examples of how this profiler is used but if you’d like to know more, this resource covers in depth the profile.rb usage.

The ruby-prof gem

Ruby community provides a gem called ruby-prof. It’s a C extension and it outputs many different formats that made it faster and richer than profile.rb.

Prerequisites

To use the whole features of ruby-prof we need a patched version of Ruby interpreter. However it is not mandatory if you’re not using memory analysis. To get a patched version of the Ruby MRI you can use RVM:

rvm install 1.9.3-p125 --patch gcdata --name gcdata

If you are not using RVM, compile a patched version of Ruby yourself. You can find the gcdata patch on RVM’s github. There is a good step-by-step tutorial to do it here. I used the following steps with rbenv:

export DESTINATION=$HOME/.rbenv/versions/1.9.3-p125-gc
mkdir $DESTINATION
# Install lib yaml
cd /tmp
wget http://pyyaml.org/download/libyaml/yaml-0.1.4.tar.gz
tar xzf yaml-0.1.4.tar.gz
cd yaml-0.1.4
./configure --prefix=$DESTINATION
make && make install
# Install a patched Ruby version
cd /tmp
wget http://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.3-p125.tar.gz
tar xzf ruby-1.9.3-p125.tar.gz
cd ruby-1.9.3-p125
curl https://raw.github.com/wayneeseguin/rvm/master/patches/ruby/1.9.3/p125/gcdata.patch | patch -p1
export CPPFLAGS=-I$DESTINATION/include
export LDFLAGS=-L$DESTINATION/lib
./configure --prefix=$DESTINATION --with-opt-dir=$DESTINATION/lib --enable-shared
make && make install
rbenv global 1.9.3-p125-gc
# Install RubyGems
cd /tmp
wget http://rubyforge.org/frs/download.php/75952/rubygems-1.8.21.tgz
tar xzf rubygems-1.8.21.tgz
cd rubygems-1.8.21
ruby setup.rb
rbenv rehash
# Cleaning all sources and archives
rm -fr /tmp/yaml-0.1.4 /tmp/yaml-0.1.4.tar.gz /tmp/ruby-1.9.3-p125 /tmp/ruby-1.9.3-p125.tar.gz /tmp/rubygems-1.8.21.tgz /tmp/rubygems-1.8.21

You may want to install Graphviz, i.e. the open source reference for graph visualisation. It’s probably available via your package manager through something like:

(brew|aptitude) install graphviz

When you’ve got a patched Ruby VM, you can install ruby-prof with this classic command:

gem install ruby-prof

Once it’s installed you can run the following commands to profile a ruby program and get a nice PDF graph of its calls:

ruby-prof --mode=wall --printer=dot --file=output.dot fibonacci.rb 25
dot -T pdf -o output.pdf output.dot
your_favorite_pdf_reader output.pdf

In this example, I used a naive fibonacci.rb program found here:

# fibonacci.rb
def fib(n)
  return n if (0..1).include? n
  fib(n-1) + fib(n-2) if n > 1
end
puts fib(ARGV[0].to_i)

The output look like this: on my machine. As you can see, there are obvious optimizations in this example. The call graph shows that 50% of time is used to do the (0..1).include?(n)…

Sampling with gperftools

Sampling profilers give an advantage over event-based profilers like ruby-prof: it can be used in a production environment without changing anything in your configuration and with a small overhead. Perftools.rb is one of them. To install it use:

gem install perftools.rb

Be aware that the perftools.rb compilation will take a while.

Then, to run fibonacci.rb, let’s add some environment variables before calling the program:

CPUPROFILE=/tmp/output.prof \
CPUPROFILE_REALTIME=1 \
CPUPROFILE_FREQUENCY=1000 \
RUBYOPT="-r`gem which perftools | tail -1`" \
ruby fibonacci.rb

The output of such a command leads to a file (/tmp/output.prof) containing the captured data. A readable representation can be built with the command pprof.rbthat is provided with the perftools.rb gem:

pprof.rb --pdf /tmp/output.prof > /tmp/output.pdf

The result of such a command looks like this:

The major drawback of using a sampling method is that we only see what happen when the profiler interrupts the program.

Using perftools.rb inside a Rails app is easy since there is a Rack based middleware: Rack::PerftoolsProfiler.

Benchmarking

Benchmarking can be an additional method to find bottlenecks but it is not really its purpose. We usually perform benchmarking to get metrics about the execution of a piece of code.

The standard library provides the Benckmark module that can be used like that:

def fib(n)
  return n if 1 >= n
  fib(n-1) + fib(n-2) if n > 1
end

def fib_include(n)
  return n if (0..1).include? n
  fib_include(n-1) + fib_include(n-2) if n > 1
end

require 'benchmark'

n = ARGV[0].to_i
Benchmark.bm(8) do |x|
  x.report("1 >= n")  { fib n }
  x.report("include") { fib_include n }
end

➜ ruby fibonacci.rb 35
               user     system      total        real
1 >= n     2.180000   0.000000   2.180000 (  2.184407)
include    5.190000   0.000000   5.190000 (  5.189968)

Rails tips

This really good guide: Performance Testing Rails Applications remains the reference regarding profiling and benchmarking. In Rails’ latest versions, the benchmarking tools were moved to ActiveSupport::Benchmarkable the previous link isn’t up to date. Among the goodies that come with Rails 3, there is the new ActiveSupport’s notification system (doc). This system comes with a handy logging tool based on LogSubscriber. This allows you to easily instrument your code.

As I’ve previously said there is also a middleware for perftools.rb Rack::PerftoolsProfiler.

Conclusion

In this article, we’ve barely scratched the surface of different tools that can guide us into performance refactoring of our code. In the next article we will see a few solutions to improve ruby code performance (using C code, caching, hashing, etc).

The Synbioz Team.

Les middlewares, fondations de Rails

Nicolas Cavigneaux — Wed, 21 Mar 2012 00:00:00 +0100

Les middlewares ? C’est quoi ?

Dans un article précédent, nous avons vu comment créer un middleware pour Rails. Pour vous rafraîchir la mémoire, voici un petit rappel à propos des middlewares.

Un middleware est un morceau de code qui agit de façon indépendante, qui est appelé et fait ses traitements avant que le code de Rails à proprement parlé soit appelé. Utiliser un middleware a pour gros avantage de ne pas passer par toute la stack de Rails ce qui résulte donc en un gain considérable de performance.

Les fondations de Rails

Rails est une application compatible Rack et n’hésite pas à en tirer partie. De nombreuses choses dans une application Rails sont gérées par des applications Rack connexes, les middlewares.

Les middlewares sont particulièrement adaptés au traitement d’actions simples et récurrentes, déconnectées de la logique de l’application Rails. Ils sont donc très utiles pour des tâches tels que le logging, les remontées d’exceptions, la gestion des cookies, de la session, des messages flash, …

Les middlewares par défaut

Comme nous l’avons vu, Rails dans un souci de modularité, d’évolutivité et de performance fait largement usage des middlewares pour ses fondations. Voyons quels sont ces middlewares ainsi que leur rôle au sein d’une application Rails.

Nous sommes ici dans le cas d’une application Rails 3.2.2 avec uniquement les middlewares activés par défaut (en mode développement puis production).

Pour avoir une liste des middlewares activés sur une application donnée, voici la commande a exécuter :

$ rake middleware

use ActionDispatch::Static
use Rack::Lock
use #<ActiveSupport::Cache::Strategy::LocalCache::Middleware:0x007fb93c60d748>
use Rack::Runtime
use Rack::MethodOverride
use ActionDispatch::RequestId
use Rails::Rack::Logger
use ActionDispatch::ShowExceptions
use ActionDispatch::DebugExceptions
use ActionDispatch::RemoteIp
use ActionDispatch::Reloader
use ActionDispatch::Callbacks
use ActiveRecord::ConnectionAdapters::ConnectionManagement
use ActiveRecord::QueryCache
use ActionDispatch::Cookies
use ActionDispatch::Session::CookieStore
use ActionDispatch::Flash
use ActionDispatch::ParamsParser
use ActionDispatch::Head
use Rack::ConditionalGet
use Rack::ETag
use ActionDispatch::BestStandardsSupport
run MyApp::Application.routes

$ rake middleware RAILS_ENV=production

use Rack::Cache
use Rack::Lock
use #<ActiveSupport::Cache::Strategy::LocalCache::Middleware:0x007f9bbb596330>
use Rack::Runtime
use Rack::MethodOverride
use ActionDispatch::RequestId
use Rails::Rack::Logger
use ActionDispatch::ShowExceptions
use ActionDispatch::DebugExceptions
use ActionDispatch::RemoteIp
use ActionDispatch::Callbacks
use ActiveRecord::ConnectionAdapters::ConnectionManagement
use ActiveRecord::QueryCache
use ActionDispatch::Cookies
use ActionDispatch::Session::CookieStore
use ActionDispatch::Flash
use ActionDispatch::ParamsParser
use ActionDispatch::Head
use Rack::ConditionalGet
use Rack::ETag
use ActionDispatch::BestStandardsSupport
use Sass::Plugin::Rack
use Airbrake::Rack
run MyApp::Application.routes

ActionDispatch::Static

ActionDispatch::Static comme vous pouvez l’imaginer est utilisé pour servir les fichiers statiques sans passer par la stack. Il serait tout à fait inutile de demander à Rails de traiter la requête, l’analyser pour finalement servir un simple fichier statique.

Il faut garder à l’esprit que les middlewares sont appelés dans le sens de chargement. La toute première action lors d’une requête sera donc de vérifier si le chemin demandé correspond à un fichier statique. Si c’est le cas il sera servit, sinon on passe au middleware suivant.

La méthode call des middlewares correspond à l’action exécutée à chaque appel, voici son code :

def call(env)
  path   = env['PATH_INFO'].chomp('/')
  method = env['REQUEST_METHOD']

  if FILE_METHODS.include?(method)
    if file_exist?(path)
      return @file_server.call(env)
    else
      cached_path = directory_exist?(path) ? "#{path}/index" : path
      cached_path += ::ActionController::Base.page_cache_extension

      if file_exist?(cached_path)
        env['PATH_INFO'] = cached_path
        return @file_server.call(env)
      end
    end
  end

  @app.call(env)
end

On voit donc que si un fichier correspondant au path est trouvé (dans public/) alors il est servi, sinon on continue notre chemin.

Voici comment, en quelques lignes, sont gérés les fichiers statiques et les caches de page. Tout cela sans charger la stack complète de Rails, ce qui rend l’action très rapide.

Rack::Lock

Rack::Lock permet de forcer tout ce qui est chargé après à utiliser un unique thread. Tout ce qui sera appelé après ce middleware aura automatiquement un lock et sera synchronisé.

Si on fait, par exemple :

use Rack::Cache
use Rack::Lock
run myapp

Ici le middleware de cache pourra utiliser plusieurs threads mais pas myapp.

use Rack::Lock
use Rack::Cache
run myapp

Dans ce cas, le cache serait lui aussi cantonné à l’utilisation d’un seul thread.

On peut donc facilement contrôler à quel niveau l’app doit se synchroniser, tout simplement en déplaçant l’appel à Rack::Lock.

ActiveSupport::Cache::Strategy::LocalCache::Middleware

Rails propose un système de cache basé sur des couples de clé / valeur :

Rails.cache.write "foo", "bar"
Rails.cache.read "foo"

Ce cache se repose normalement sur le système de fichier mais le middleware permet à Rails.cache d’utiliser un stockage en mémoire pour améliorer les performances

Rack::Runtime

Rack::Runtime permet d’ajouter à la volée une entête “X-Runtime” à la réponse. Cette valeur représente le temps nécessaire à la rêquete pour être traitée. Cette valeur est exprimée en secondes.

Vous pouvez déplacer ce middleware vers le bas, par exemple juste avant l’appel à votre application ce qui aura pour effet de ne prendre en compte que le temps de rendu de votre app, en occultant les middlewares appelés avant.

$ curl -I http://host.dev

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
X-UA-Compatible: IE=Edge
ETag: "0d48246875a0f4e63c8925f0b3fd5941"
Cache-Control: max-age=0, private, must-revalidate
Set-Cookie: _host_session=BAh7B0kiD3Nlc3Npb25faWQGOgZFRkkiJTE4ODViMjZiNTI1NDI2ODE1NDNjOTY0OTcwNDcyYzJkBjsAVEkiEF9jc3JmX3Rva2VuBjsARkkiMWp5Qk80K2JXWENkZmJZbE5NbDVEQXlhUzAvMzJSZVdobFFhK3ltNnpkVnM9BjsARg%3D%3D--6e2645898c73ec7d118b91bda6f742318a326aaf; path=/; HttpOnly
X-Request-Id: 25bc69615b363e77c02d0801dcb07969
X-Runtime: 0.485419
Connection: close

Très pratique en phase de développement ou d’optimisation pour connaitre rapidement les temps de traitement d’actions données.

Rack::MethodOverride

Vous avez déjà surement remarqué, dans vos formulaires Rails, la présence d’un

<input name="_method" type="hidden" value="put" />

ajouté automatiquement pour le peu que vous utilisiez les helpers. Ce paramètre caché permet de préciser à Rails le verbe (GET / POST / PUT / DELETE) avec lequel a été appelée l’action.

Pourquoi ajouter ça puisque ce sont des verbes standards de la norme HTTP ? Parceque malheureusement tout n’est pas rose et peu de serveurs web comprennent ces quatres verbes. Pour la plupart ils ne comprennent que GET et POST.

Rails a donc pris le parti de n’utiliser que GET et POST et de simuler les autres verbes. C’est donc un moyen de s’assurer que la requête pourra être identifiée avec le bon verbe.

Le middleware Rack::MethodOverride a pour but de de vérifier les appels passés en POST à la recherche d’un paramétre _method qui permettra de redéfinir correctement la méthode HTTP (verbe) dans la requête reçue.

ActionDispatch::RequestId

ActionDispatch::RequestId permet d’ajouter un identifiant unique à chaque requête et une en-tête X-Request-Id à la réponse.

Cet id a pour but de faciliter le traçage d’une requête, dans les logs par exemple.

Vous pouvez vous référer à l’exemple précédent (Curl) qui contient un X-Request-Id dans sa réponse.

Rails::Rack::Logger

Rails::Rack::Logger permet de signaler dans les logs le démarrage d’une requête en précisant la méthode utilisée, le chemin, l’ip du client ainsi que l’heure actuelle.

Les logs sont ensuite flushés en fin de requête pour s’assurer que tous les messages soient affichés.

ActionDispatch::ShowExceptions

ActionDispatch::ShowExceptions se charge d’attraper les exceptions à la volée et d’appeler une app dédiée à les afficher (dans les logs et le navigateur) dans un format adapté aux développeurs.

ActionDispatch::DebugExceptions

ActionDispatch::DebugExceptions est l’app dédiée à l’affichage et au log des exceptions. C’est ce middleware qui affiche les pages de debug (erreur 500 par exemple) en mode développement et qui s’assure de reporter ces informations dans les logs.

ActionDispatch::RemoteIp

ActionDispatch::RemoteIp sert à stocker l’ip du client dans l’environnement de la requête ce qui permet d’y faire référence ensuite dans l’application.

Au passage ce middleware fait aussi quelques vérifications d’usage pour protéger l’app contre le spoofing.

ActionDispatch::Reloader

ActionDispatch::Reloader permet de recharger automatiquement les classes avant chaque requête lorsque vous êtes en mode développement. C’est ce qui fait (en partie) que votre application est plus lente en mode développement qu’en mode production mais c’est aussi ce qui fait que vous n’avez pas à relancer votre serveur quand vous modifiez un modèle.

ActionDispatch::Callbacks

ActionDispatch::Callbacks donne accès à des callbacks de requête (before / after). Ces callbacks seront appelés à chaque requête :

>> ActionDispatch::Callbacks.before { puts "Avant la requete" }
=> [ActionDispatch::Callbacks]

>> ActionDispatch::Callbacks.after { puts "Apres la requete" }
=> [ActionDispatch::Callbacks]

>> app.get "/"
Avant la requete
Post Load (0.3ms)  SELECT `posts`.* FROM `posts`
Apres la requete
=> 200

ActiveRecord::ConnectionAdapters::ConnectionManagement

ActiveRecord::ConnectionAdapters::ConnectionManagement sert à nettoyer les connexions actives à la base de données en fin de requête ce qui évite tout simplement d’avoir à le gérer à la main.

ActiveRecord::QueryCache

ActiveRecord::QueryCache est le middleware qui permet de cacher vos requêtes SQL pour faire en sorte que deux requêtes identiques ne fassent qu’une fois l’objet d’un appel à la base SQL ce qui a pour effet d’améliorer considérablement les performances si vous n’avez pas pris soin de gérer cela à la main. Si vous gériez ça , vous allez gagner beaucoup de code et de temps.

Ce middleware va donc, en début de requête, activer le cache. Il se chargera également de nettoyer ce cache en fin de requête :

Category Load (0.4ms)  SELECT `categories`.* FROM `categories` WHERE `categories`.`id` = 1 LIMIT 1

CACHE (0.0ms)  SELECT `categories`.* FROM `categories` WHERE `categories`.`id` = 1 LIMIT 1

ActionDispatch::Cookies

ActionDispatch::Cookies gère la lecture des cookies envoyés par le client avec la requête puis la mise à disposition de ces cookies dans le code. C’est aussi lui qui va se charger d’envoyer les cookies générés dans l’app au client via la réponse.

ActionDispatch::Flash

ActionDispatch::Flash permet de gérer le stockage et la récupération de messages flash (objet transmis entre deux actions) en session.

ActionDispatch::Flash va donc stocker un objet lors d’une requête, le mettre à disposition de l’action suivante puis le supprimer.

ActionDispatch::ParamsParser

ActionDispatch::ParamsParser se charge de parser les requêtes (xml / json / yaml) pour le convertir en hash (params).

Le code est un peu plus long que d’habitude mais reste très simple à comprendre.

Ce middleware est l’une des pierres angulaires qui permettent de facilement mettre en place des API à l’aide de Rails.

ActionDispatch::Head

ActionDispatch::Head va vérifier si la requête est de type “HEAD”. Si c’est le cas, seul le status et les en-têtes seront envoyées dans la réponse. On peut donc améliorer les temps de réponse des pages en omettant le corps de la réponse (utilisation de cache, …).

Rack::ETag

Rack::ETag permet d’ajouter une en-tête “ETag” à la réponse. Cet ETag est un hashage du corps de la réponse ce qui permet d’identifier de manière unique le contenu. On peut donc savoir si le contenu de la page a changé ou non depuis la dernière requête.

Rack::ConditionalGet

Rack::ConditionalGet permet de mettre en place du “GET” conditionnel.

Lorsque une page est demandée, le middelware génére un hash du contenu de cette page et vérifie si ce ETag est déjà connu par le client.

Si oui alors une réponse avec un corps vide et un statut 304 est envoyé pour dire que la page n’a pas été modifiée. Elle peut être chargée depuis le cache client. Le client a donc une réponse plus rapide et le serveur une charge plus faible.

Si cet ETag n’est pas connu par le client alors la réponse est envoyée normalement.

ActionDispatch::BestStandardsSupport

ActionDispatch::BestStandardsSupport est un middleware des plus simples, il ne fait qu’ajouter une en-tête supplémentaire à la réponse pour demander aux clients Internet Explorer d’utiliser le plugin Chrome Frame ou son moteur de rendu natif le plus récent.

Rack::Cache

Rack::Cache est un gem qui permet de mettre en place du cache HTTP basé sur le standard RFC 2616.

Pour conclure

Les middlewares peuvent donc s’avérer très utile pour accomplir des tâches simples mais récurrentes qui nécessitent un temps de réponse le plus court possible. Les middlewares ont pour gros avantage de court-circuiter la stack Rails qui n’est pas toujours nécessaire au regard de besoins précis.

Il est donc très intéressant de connaitre les middlewares utilisés par défaut par Rails pour notamment désactiver ceux dont vous n’avez pas besoin, en faire un meilleur usage ou encore pour vous inspirer dans le développement du votre.

Le kit du bon développeur Rails, quelques gems à connaitre, partie 3

Alexandre Salaün — Thu, 15 Mar 2012 00:00:00 +0100

Nous allons aborder la dernière partie de notre série d’articles sur les gems à connaitre pour un développeur Rails. Dans le premier article nous nous étions attardés sur des thèmes tels que l’authentification, la recherche ou encore la pagination. Ensuite, dans la deuxième partie, ce fut au tour des gems en rapport avec l’internationalisation et la gestion de fichiers. Dans ce dernier article, les gems concernant les tests et la gestion des tâches annexes seront à leur tour abordées.

Tests

Les tests sont une partie très importante de votre application Rails et il ne faut pas les négliger. Il existe différentes gems vous permettant d’effectuer des tests unitaires, des tests d’intégration ou encore des tests de performance. La plus répandue d’entre elles est sans doute RSpec (vous pouvez obtenir des informations sur la page Github de RSpec) mais ce n’est pas sur cette dernière que je vais m’attarder, il y a déjà un certain nombre de documentations très bien faites.

Capybara

Capybara est une gem permettant de tester votre site ou votre application tel que le ferait un utilisateur en navigant. Cela permet donc d’avoir des tests suivants des scénarios précis et adaptés à l’usage qui sera fait de votre site. Des informations sont disponibles sur le Github de Capybara.

Vous pouvez donc, au travers de vos tests, établir des scénarios de navigation afin de tester différentes parties de votre site ou application. Il est par exemple possible de tester le processus de connexion :

it "signs user in" do
  within("#login") do
    fill_in 'Login', :with => 'user@example.com'
    fill_in 'Password', :with => 'password'
  end

  click_link 'Sign in'
end

Ici, on remplit les champs login et password avec les informations souhaitées puis on clique sur le bouton de soumission du formulaire.

Il est également possible de tester des éléments Javascripts avec Capybara. Il suffit pour cela de le spécifier lors de votre test :

describe 'js tests', :js => true do
  it 'test a specific js part'
end

Afin de vous familiariser d’avantage avec cette gem, vous pouvez lire l’article consacré à Capybara sur notre blog.

Là encore, Capybara n’est pas la seule gem disponible, il y a une multitude de gems disponibles pour tester votre application.

MiniTest

Pour ce qui est des tests unitaires, il est possible d’utiliser différentes gems. Nous avons choisi dans notre cas Minitest qui est livré avec ruby 1.9. Si vous avez un projet en 1.8 il vous suffit de l’ajouter à votre Gemfile :

group :test, :development do
  gem 'minitest'
end

Minitest est un framework de test permettant de créer des tests unitaires pour votre site ou application, des informations sont disponibles sur la page Github.

Afin de mieux comprendre comment fonctionne cette gem, je vous conseille de lire l’article consacré à Minitest sur notre blog.

Minitest::Spec

Pour les habitués de RSpec, il est possible d’utiliser des specs avec Minitest, des matchers sont disponibles pour cela. Il est possible de trouver des listes plus ou moins exhaustives de ces matchers sur le net, comme par exemple dans ce tutoriel.

Il vous faut pour cela ajouter les lignes suivante dans votre fichier test_helper.rb ou bien directement dans votre fichier contenant les tests.

require 'minitest/spec'
require 'minitest/autorun'

Il vous est possible ensuite de créer une tâche rake pour pouvoir lancer vos specs dans votre projet Rails en ajouter un fichier (nommé spec.rake par exemple) dans le répertoire lib/tasks/ :

require 'rake/testtask'

Rake::TestTask.new do |t|
  t.name = "spec"
  t.libs.push 'spec', Dir.pwd
  t.test_files = FileList['spec/**/*_spec.rb']
end

Dans ce cas, les specs se trouvent dans un répertoire specs à la racine de votre projet (ceci vous permet ensuite de séparer les specs concernant les models, les controllers et les vues).

Simplecov

Lorsque vous avez des tests automatisés dans votre application il est toujours bon de savoir si ils couvrent une proportion raisonnable de votre application ou bien si ils ne concernent qu’une petite partie du code.

Simplecov est une gem qui vous permet de savoir quelle pourcentage de votre code est couvert par les tests. Cette dernière est très simple d’utilisation et vous apporte des informations très utiles.

Afin d’installer cette gem, il suffit de l’ajouter au Gemfile :

group :test do
  gem 'simplecov', :require => :false
end

Après avoir lancé un bundle install vous pouvez donc utilisez Simplecov ou presque. En effet, il est nécessaire d’ajouter cette gem dans le votre test_helper pour pouvoir l’utiliser.

require 'simplecov'
SimpleCov.start

Attention, ces deux lignes doivent être ajoutées tout en haut de votre fichier.

Enfin, il vous suffit de lancer vos tests via rake test:units par exemple et vous allez pouvoir savoir quel est le pourcentage de votre code qui est couvert par vos tests. Un répertoire coverage est créé dans votre application et si vous consultez le fichier coverage/index.html vous pouvez avoir toutes les informations dont vous aurez besoin.

Spork

Spork est une gem permettant d’avoir un serveur de test mais contrairement à ce que fais Rails habituellement il ne recharge pas tous les fichiers mais uniquement ceux qui ont changé. Ceci permet un gain de temps lors de l’exécution des tests (qui peut parfois s’avérer très long si le nombre de tests est conséquent).

Spork fonctionne avec différents framework de tests tels que RSpec, Cucumber. Il est également possible de l’utiliser avec guard via la gem guard-spork.

Pour utiliser spork dans votre application Rails il suffit d’ajouter la gem à votre Gemfile :

gem 'spork-rails'

ou, si vous utilisez un TestUnit

gem 'spork-testunit'

Ensuite, pour lancer spork, il vous suffit de taper la commande suivante :

spork

Puis lorsque vous lancerez vos tests spork se chargera de ne recharger que les fichiers nécessaires.

Vous pouvez trouver d’avantage d’informations sur cette gem sur la page Github de spork.

Tâches annexes et exécution de commandes

Whenever

Whenever est une gem qui vous permet de gérer les tâches récurrentes de votre projet. En effet, elle vous offre la possibilité de créer des crons jobs pour votre application, le tout dans une syntaxe simplifiée.

Dans un premier temps, il vous suffit de l’ajouter à votre Gemfile puis de de l’installer via un bundle install :

gem 'whenever', :require => false

Ensuite, une commande vous permet de générer le fichier config/schedule.rb dans lequel vous spécifierez vos crons après que vous vous soyez rendu à la racine de votre projet :

wheneverize .

Vous pouvez maintenant créer les crons jobs que vous souhaitez sous la forme suivante :

every 2.hours do
  runner "MyModel.my_process"
end

every 1.week, :at => '1:00 am' do
  rake "my:rake:task"
end

every :hour do
  command "/usr/bin/my_great_command"
end

Il est également possible d’intégrer whenever avec Capistrano pour le déploiement de votre application comme cela est expliqué sur le Github de cette gem.

Resque

Resque est une gem permettant des gérer des tâches asynchrones, en différant certaines actions à l’aide d’un système de files d’attente (ou queues).

Cela permet de rendre la main à l’utilisateur rapidement en déportant l’exécution d’un traitement lourd. On peut imaginer par exemple un envoi d’image qui sera par la suite compressée.

Plutôt que d’exécuter le traitement directement après l’envoi on crée une tâche asynchrone d’encodage et l’utilisateur peut immédiatement envoyer une autre image. Il est averti quand le traitement a été exécuté.

Avant de pouvoir utiliser Resque, il y a quelques pré-requis. Il faut en effet avoir installer redis. Ensuite, il vous faut le lancer via la commande suivante :

redis-server /usr/local/etc/redis.conf

Maintenant, vous allez pouvoir ajouter Resque à votre Gemfile puis lancer un bundle install.

Une fois installé, vous devez créer la tâche Rake correspondante pour pouvoir utiliser Resque. Pour cela, il suffit de créer le ficher /lib/tasks/resque.rake et d’y coller le code suivant :

task "resque:setup" => :environment

Les workers peuvent donc être lancé via la tâche suivante :

# Sans spécifier de queue
QUEUE='*' rake environment resque:workers

# Pour spécifier une queue
QUEUE=my_queue rake environment resque:workers

# Pour limiter le nombre de workers
QUEUE=my_queue COUNT=5 rake environment resque:workers

Vous pouvez donc maintenant mettre dans les files d’attentes des tâches de votre application afin qu’elles soient différées via la méthode suivante, par exemple depuis le model :

Resque.enqueue(Model, self.id)

Plus d’exemples et d’informations sont disponibles sur la page Github de resque ou bien dans le Railscast sur cette gem.

Delayed Job

Tout comme la gem précédente, Delayed Job permet d’exécuter des tâches différées, que ce soit pour envoyer des mails, retoucher des images ou encore bien d’autres choses. Vous pouvez trouver différentes informations à propos de cette gem sur la page Github.

Après avoir installé la gem (en l’ajoutant à votre Gemfile et en lançant la commande bundle install), une commande vous permet de créer la table nécessaire au fonctionnement de cette gem :

script/generate delayed_job
rails generate delayed_job

Vous pouvez ensuite configurer le fonctionnement de delayed_job à travers un initializer : config/initializers/delayed_job_config.rb.

Pour lancer les workers, il vous suffit de taper la commande suivante :

rake jobs:work

Il est dorénavant possible d’ajouter des tâches à la liste d’attente afin qu’elles soient effectuées en différé. Pour cela, comme pour resque, vous devez les ajouter à la queue via une méthode :

Delayed::Job.enqueue NewsletterJob.new('My newsletter...', Customers.all.map(&:email))

Cocaine

Cocaine est une gem permettant l’exécution de commandes. Pour l’installer, il suffit de l’ajouter à votre Gemfile puis de lancer la commande bundle install :

gem "cocaine"

Ensuite, vous pouvez donc exécuter des lignes de commandes depuis votre application Rails au travers des lignes suivantes :

c = Cocaine::CommandLine.new("my_command", "my 'simple' options")
c.command           # renvoie la commande, dans notre cas : "my_command my 'simple' options"
output = c.run      # exécute la commande et renvoie le résultat

Si une commande ne fonctionne pas, alors une exception est levée, il est donc possible de les récupérer :

c = Cocaine::CommandLine.new("my_command", "my 'simple' options")

begin
  c.run
rescue Cocaine::ExitStatusError => e
  e.message
end

Il est donc possible d’exécuter les commandes que vous souhaitez dans votre projet via cette gem. Vous pourrez trouver d’autres exemples et informations sur la page Github de cocaine.

Guard

Guard permet de savoir si des modifications ont eu lieu sur des fichiers de votre application afin d’exécuter différentes commandes en fonction de ces dernières. Par exemple, cette gem fonctionne avec minitest dans le but de relancer les tests quand le fichier est modifié, ou même de relancer les tests en rapport avec le model qui a changé.

Afin de pouvoir utiliser guard, il vous suffit de l’ajouter à votre Gemfile :

gem 'guard'

Puis de l’installer via la commande bundle install. Ensuite, la commande guard init vous permet de créer un fichier Guardfile. C’est dans ce dernier que vous allez pouvoir configurer la gem selon vos souhaits.

Une fois votre Guardfile à jour, il ne vous reste plus qu’à exécuter la commande guard pour lancer la gem. De nombreuses options sont disponibles suivant vos besoins (vous pouvez le voir sur la page github).

Guard vous permet également de convertir des fichiers .coffee en .js si cela est nécessaire.

La page Github de guard vous permettra d’en savoir plus sur cette gem si vous souhaitez l’utiliser.

Conclusion

Au travers de ces trois articles nous avons pu voir un certain nombre de gems très utiles lors de vos développements d’applications Rails. Bien entendu, il existe une multitude de gems et toutes ne peuvent être listées ici. Nous nous sommes efforcés de présenter les plus appropriées aux fonctions de base demandées pour une application ou un site web.

Il est utile de connaitre l’existence de ces gems, sans aller jusqu’à toutes les connaître, ou même d’avoir le réflexe de chercher si une gem existe avant de développer une fonctionnalité sur un site. En effet, la quasi intégralité des fonctionnalités de base sont disponibles via des gems, qui sont testées et mises à l’épreuve par de nombreux utilisateurs. Il vous est donc souvent plus simple d’utiliser quelque chose d’existant, voire d’y contribuer, plutôt que de tout refaire de zéro.

L’équipe Synbioz.

Libres d’être ensembles.

Retour sur les nouveautés matérielles présentées au Mobile World Congress 2012

Jean Rémi Laisne — Thu, 08 Mar 2012 00:00:00 +0100

Le Mobile World Congress (MWC) se déroulait cette année à Barcelone, plus de 60 000 visiteurs se sont rendus à cet évènement mondial et ont pu suivre attentivement les annonces des fabricants. Voici ce que nous avons retenu de ce forum mondial, qui annonce les tendances de l’année 2012 et même de 2013.

Systèmes d’exploitation mobiles : Android et iOS conservent leur avance.

Avant de présenter les nouveautés en matière de mobile, un rapide tour d’horizon sur le marché des mobiles intelligents et des tablettes s’impose. Depuis notre dernier article sur le marché mobile, on note une belle progression d’Androïd avec une part de marché de 50% et d’iOs qui lui emboite le pas avec 27% du marché. Loin derrière ces deux leaders, Windows phone stagne à 2%. Le reste des Os mobile, comme Symbian, suit tout aussi difficilement.

Course à la puissance

Les fabricants nous ont présentés leurs modèles pour l’année 2012. Une tendance au resserrement des gammes se note très clairement. Les fabricants se limitent parfois à 3 choix : bas, moyen et haut de gamme, mais qui s’adapteront à tous les budgets.

L’accent n’est donc plus mis sur la diversité des modèles et des offres mais sur la puissance des terminaux. Qualcomm n’est plus le seul à offrir des puces ARM et se voit distancé par de nouveaux entrants. Des fondeurs se sont présentés au MWC avec des nouvelles puces quadcores et Qualcomm, pourtant leader sur le marché, est aujourd’hui le seul à ne pas avoir de modèle quadcore dans ses offres. Nvidia, avec ses Tegra, Intel et Texas Instrument nous annoncent donc une vraie course à la puissance. Les grands gagnants seront ceux qui d’une part proposeront des puces économes en énergie et d’autre part un écosystème destiné aux développeurs de jeux vidéo. Dans cette course, Nvidia part avec une longue d’avance grâce à son excellente connaissance du marché des jeux vidéo et à sa Tégra-zone.

Grâce à cette compétition, c’est donc le marché des processeurs mobiles qui s’ouvre à la concurrence et dont, nous, consommateurs de mobilité, allons tirer profit.

De nouveaux Smartphones de pointe

Avant de vous présenter les nouveaux Smartphones des constructeurs, je vous annonce l’implémentation chez tous les constructeurs de la 4 G (ou la LTE), déjà bien présente en Asie et depuis l’année dernière aux USA. Pour l’Europe, il faudra très probablement attendre l’année prochaine. Nous espérons tous que le bouleversement de Free poussera SFR, Orange et même Bouygues à investir plus vite que prévu ce marché.

Autre technologie qui s’implémente du côté des constructeurs, la technologie NFC (Near field communication) nous permettra d’échanger des données. Et surtout concrètement de payer avec nos terminaux mobiles. Là encore, il faudra pourtant attendre un peu car la NFC signifie de nombreux investissements du côté des PME et des grandes entreprises pour équiper les commerçants et grandes surfaces.

HTC One

Dans le HTC One, son constructeur, HTC, ne s’écarte pas de sa ligne de design de téléphones mobiles. La pâte HTC et la qualité de ses Smartphones avec coque métallique est toujours là. Pour ma part, cependant, je regrette grandement le parti-pris de faire des coques monobloc où la batterie ne sera plus accessible. Cela étant dit, le HTC One X sera certainement le prochain Smartphone star de la marque. HTC, qui péchait il y a quelques années sur la qualité de ses photos, a aujourd’hui bien repris le dessus avec des photos de très bonne qualité et avec, du côté des applications de gestion des photos, le développement d’une application bien aboutie offrant la possibilité de filmer tout en prenant en même temps des photos.

Samsung

Samsung continue sa série de mobiles Galaxy qui a très bien marchée en 2011, grâce à des appareils de très bonne facture. Le Galaxy SIII n’a pas été présenté au MWC mais sera certainement le produit phare de 2012. Il sera à lui seul un évènement préparé pour très bientôt par Samsung. Nous avons également apprécié l’évolution du Samsung Beam, un mobile de 14 mm d’épaisseur seulement, qui dispose d’un pico-projecteur intégré et qui permettra, en association avec des softwares dédiés de faire des présentations annotées. Le Samsung Beam marque une réelle innovation au Mobile World Congress.

Sony Xperia

Sony a annoncé le rachat d’Ericsson et est maintenant seul à la barre pour le développement de ses appareils mobiles. On remarque de la part de Sony une réelle implication sur le design de ses appareils, qui se concrétise dans le design réussi de ses Smartphones déclinés en trois gammes : les séries P, U et S. Sony a certainement une carte à jouer grâce à un écosystème qui le diffère par rapport à ses concurrents, notamment en ce qui concerne ses services de musique, de vidéo à la demande et la possibilité d’inter communiquer avec d’autres périphériques comme les nouvelles Télévisions Brava.

Nokia avec Windows phone

Nokia revient sur le devant de la scène grâce à un superbe effet d’annonce marketing : un appareil photo embarqué à plus de 41 Mégapixels. Nokia, qui a fait sensation avec ses nouveaux designs l’année dernière, fait naturellement évoluer sa gamme avec le Nokia 610 de moyenne gamme et le 900 haut de gamme qui se doté d’une caméra en façade et supportera la 4G. Et annonce donc le Pureview 808, un appareil photo à 41 mégapixels interpolé, c’est-à-dire un appareil de 12 mégapixels augmenté par logiciel à 41 mégapixels. A tester donc. Le point noir pour ce mobile est qu’il est proposé sur l’OS Symbian Belle, un OS en perte de vitesse, destiné au marché émergeant et dont la fin est déjà proclamée.

Les produits Chinois montent en gamme : Huawei

Pour finir sur les Smartphones qui m’ont le plus surpris pour cette édition du MWC, je souhaite mettre en valeur les Smartphones Chinois de HuaWei. Après le P1 S “le téléphone le plus fin du monde” de 6,9 mm, Huawey sort les armes et propose le Ascend D et le quad XL “les Smartphones le plus rapide du monde” grâce à un processeur 4 coeurs maison (le K3V2). Huawey a donc mis la barre très haut et part à la conquête de son énorme marché national et attaquera sans nul doute le reste du monde en concurrence direct avec Samsung.

Tablette

Si l’année dernière l’accent de tous les constructeurs était mis sur les tablettes, cette année, les annonces étaient plus discrètes, certainement dues à des ventes qui n’ont pas été au-delà des espérances des constructeurs.

Asus

On remarquera Asus qui définit plus finement sa stratégie en renommant toutes ses tablettes Asus Transformer Pad, plus simple que l’ancien Eepad transformer. Asus nous a présenté aussi un nouveau concept : le Padphone. Le Padphone permet de glisser un Smartphone sous Androïd 4 dans un écran de 10 pouces. Cette nouvelle tablette donc, peut se brancher sur un clavier et peut être utilisé avec un stylet Bluetooth. Et le stylet peut faire office dans cette configuration de téléphone ! Asus a donc réussi un tour de force en étant le seul à proposer un écosystème complet et unique en son genre.

Apple

Apple n’était pas vraiment présent au MWC mais a été récompensé par l’industrie en remportant le Global Mobile Award par la GSM association. L’iPad 2 est la tablette qui a fait le plus de ventes et définit à elle seule le marché des Tablettes. L’ipad 3 doit être annoncé dans la Keynote du 7 mars et sera certainement encore un énorme succès pour la marque à la pomme.

Samsung Note

Un nouveau segment est apparu en 2011, à mi-chemin entre la tablette et le téléphone et dont l’ambassadeur est le Samsung Note. Le Samsung Note a véritablement été un succès pour Samsung avec 2 millions d’unités vendues. Pour cette année 2012, Samsung décline donc le Samsung note en version 10 pouce et continue à développer un stylet capacitif de haute qualité en partenariat avec Wacom et du coté software avec Adobe.

Conclusion

Le Mobile World Congress nous aura donc présenté des smartphones haut de gamme qui montent en puissance et en esthétisme. Le marché suivra certainement ces innovations. Pour nous, les réelles innovations se tourneront vers l’expérience utilisateur. C’est à dire la possibilité d’utiliser son smartphone sur plusieurs périphériques et l’échange de données gràce au cloud. Imaginez de commencer à regarder un film sur votre smartphone que vous avez acheté sur une boutique en ligne, puis sans interruption, continuez à regarder votre film sur votre télévision ou sur votre tablette… Génial, non ?