L'actualité de Synbioz

L'utilisation de vim (suite)

Nicolas Zermati — Tue, 21 Feb 2012 00:00:00 +0100

Dans mon dernier article sur Vim j’ai introduit les bases de l’éditeur. Cette fois, j’aimerais vous présenter les fonctionnalités qui permettent à Vim de défendre sa place face à Mate ou à Sublime Text. C’est dans cet opus que vous découvrirez que la richesse des commandes de déplacement, d’insertion et de sélection n’est que la partie visible de l’iceberg.

Interactions avec la console

Lorsque vous êtes dans Vim vous pouvez exécuter des commandes classiques en les préfixant par :!. Dans ce cas le résultat de la commande est affiché puis Vim reprend la main après une confirmation de votre part. Pour avoir un terminal fonctionnel et prêt à exécuter plusieurs commandes à la suite c’est :sh qu’il faut utiliser.

On peut également rediriger la sortie d’une commande dans un buffer. En utilisant la syntaxe Ex :r !tree qui va écrire sous le curseur l’arborescence du répertoire courant. Comme toute commande Ex, on peut choisir une adresse, .,+10r !tree remplace les 10 lignes suivant la ligne courante par le résultat de tree.

Ce n’est pas terminé ! On peut aussi utiliser une partie d’un buffer comme entrée d’une commande avec :w !cmd ou encore filtrer en place tout ou partie d’un buffer. On peut par exemple supprimer toutes les lignes d’un fichier débutant par un # avec :%!egrep -v "^[\t ]*\#".

Ce qui est intéressant c’est que Vim profite de la philosophie Unix au mieux en jouant la carte du « pipe ».

Buffers de copie

Imaginez que vous venez de supprimer un texte accidentellement à coup de commande d. Vous pouvez annuler ou vous pouvez coller (la suppression de Vim agit plutôt comme un couper). Lorsque vous avez copié ou supprimé autre chose ou que vous n’avez pas envie de revenir en arrière sur les modifications que vous avez faites entre temps vous disposez d’un historique des 9 dernières copies / suppressions. La commande "2p va coller après le curseur le contenu de ce qui à été supprimé ou copié en avant dernier et ainsi de suite. Le workflow typique pour rechercher dans cet historique est "1pu.u.u. qui permet de remonter l’historique.

Lorsque vous réalisez des opérations de suppression ou de copie de texte, il est possible de contrôler la zone dans laquelle Vim stocke ce texte. C’est une fonctionnalité offerte habituellement par des gestionnaires de presse-papier. Vim offre 26 buffers de copie, un pour chaque lettre minuscule. Pour copier 5 lignes dans le buffer a on peut le faire grâce à la commande :.,+4y a ou avec "ay4. Lorsqu’on utilise des lettres majuscules, le contenu copié ou supprimé est ajouté au buffer portant la même lettre.

On peut par exemple réorganiser les sections d’un fichier en les accumulant dans un buffer (:24,31d X) dans l’ordre où l’on souhaite à la fin les voir. Lorsque c’est fait, on colle simplement le résultat avec "xp.

Macros

Je distingue deux types d’automatisation, celle que l’on prévoit, que je qualifie de statique et celle que l’on utilise au fil de l’édition, que je qualifie de dynamique.

Statiques

Abréviations

Vim dispose d’une commande permettant de définir des abréviations par exemple si je veux remplacer pck par parce que lorsque j’écris, la commande :ab[breviate] pck parce que me le permet. Cette commande n’a d’effet que dans l’instance de Vim actuelle. Vim dispose d’un fichier de configuration, dont nous reparlerons plus tard, auquel peuvent être intégrées ces abréviations et ainsi en bénéficier dans toutes les futures instances de Vim.

L’abréviation que l’on vient de définir s’applique aussi lorsque l’on essaye de taper une commande : la commande :pck 34 est étendue en :parce que 34. C’est gênant. Vim permet de choisir le mode dans lequel on veut que nos abréviations fonctionnent. Les commandes :ca[bbrev] et :ia[bbrev] permettent de définir une abréviation uniquement pour le mode commande ou insertion.

On peut bien entendu supprimer une abréviation avec les commandes :una[bbreviate], cuna[bbrev] et :iuna[bbrev] selon le type de l’abréviation à supprimer. C’est également une commande pratique pour corriger des fautes de frappe par exemple :ia tihs this.

Mapping

Vim permet de faire correspondre des touches à des actions, au-delà de la simple abréviation textuelle. Par exemple si vous trouvez que faire <Esc>:w<CR>a (voir la notation <>) n’est pas pratique pour faire une sauvegarde en cours d’édition. Alors, vous pouvez ajouter un raccourci pour le faire en appuyant sur F3 : imap <F3> <Esc>:w<CR>a. Dans cet exemple la commande :imap n’intervient qu’en mode insertion. Comme pour les abréviations, il existe un grand nombre de versions de :map. Ne pas hésiter à consulter la documentation officielle de la commande map.

Un autre exemple pourrait être de rajouter la commande Ctrl h en mode insertion pour insérer la date sous le curseur : :imap <C-h> <C-R>=strftime("%Y/%m/%d")<CR>. Dans les deux exemples j’ai utilisé des touches spéciales comme F2 ou bien Ctrl h en tant que raccourci. Il est tout à fait possible d’utiliser n’importe quelle combinaison de touches. J’oublis régulièrement de sortir du mode insertion pour faire un :w, j’ai ajouté ce mapping : :imap :w <Esc>:w.

Pour plus de détails sur la commande <C-R> voir la documentation de i Ctrl R. Cette commande permet d’évaluer des expressions diverses : opérations, fonctions, buffers, et autres puis d’écrire le résultat sous le curseur.

Fonctions

On peut déclencher des fonctions dans les macros, il devient donc possible d’écrire une fonction dans le langage Vim et de l’exécuter n’importe quand. Je ne rentrerai pas dans le détail de l’écriture des scripts Vim dans cet article mais sachez que c’est possible, simple et assez complet. On peut même utiliser du Ruby (voir la documentation de if_ruby.

Dynamiques

On peut dynamiquement utiliser des macros grâce au mode enregistrement. Ce mode permet d’enregistrer les actions que vous êtes en train de faire afin de les rappeler plus tard. Pour moi c’est vraiment une des principales killer features de Vim. Avec qa je débute l’enregistrement d’une macro dans un buffer a, lorsque j’appuie à nouveau sur q je termine cette macro. Avec @a j’exécute cette même série de commandes et d’insertions. Dès lors que l’on reformate des données complexes et répétitives, c’est indispensable.

Templates

Comme je le disais plus tôt Vim possède un fichier de configuration. Il se trouve $HOME/.vimrc et contient en général les préférences des utilisateurs. On peut y ajouter des commandes Vim classiques et également associer des actions à des évènements, par exemple l’ouverture d’un fichier. Vim ne dispose pas d’un système de modèles lors de la création de nouveaux fichiers. Grâce au système d’évènements de Vim on peut en une ligne de configuration obtenir un tel système.

Le système d’évènements de Vim va permettre de spécifier que sur l’ouverture d’un nouveau fichier on devra écrire le contenu du fichier modèle au début de ce nouveau fichier. C’est grâce à cette commande dans le fichier de configuration qu’on arrivera à ce résultat :

  autocmd! BufNewFile * silent! 0r ~/.vim/templates/tmpl.%:e

Ici BufNewFile est le nom de l’évènement, * le motif du nom des fichiers devant être retenu (tous les fichiers ici) et silent! 0r <filename> la commande qui va insérer le contenu du fichier filename à la ligne zéro du fichier. L’utilisation de %:e permet de récupérer l’extension du fichier courrant. Ainsi pour un nouveau fichier HTML on va rechercher le fichier ~/.vim/templates/tmpl.html.

Voilà, on a notre système de modèles ; à condition d’avoir préalablement enregistré les modèles nécessaires au bon endroit.

Les replis

Les replis sont une fonctionnalité qui permet de masquer une partie d’un fichier. Ces replis peuvent bien sûr être imbriqués. Dans Vim, la plus petite unité de replis est la ligne. Il existe différents modes pour contrôler ces replis : syntax, indent, manual et expr. Je n’ai pas grande expérience avec le mode de replis syntax. Le mode indent utilise uniquement l’indentation pour déterminer les niveaux de replis. Le mode manual nécessite que l’utilisateur spécifie l’intervalle a être replié. Voici un condensé des commandes pour manipuler ces replis :

Commande	Action
zf	Utilise le mode visuel ou un déplacement pour créer un repli
zo	Ouvre le repli sous le curseur
zO	Ouvre tous les replis sous le curseur
zc	Ferme le repli sous le curseur
zR	Ouvre tous les replis du fichier
zM	Ferme tous les replis du fichier
zm	Augmente le niveau de repli
zr	Diminue le niveau de repli
zj	Déplace le curseur au repli suivant
zk	Déplace le curseur au repli précédent
[z	Déplace le curseur au début du repli
]z	Déplace le curseur à la fin du repli

Pour en savoir un peu plus sur les replis, je vous recommande cet article dédié aux replis de Vim. L’article aborde entre autres la persistance des replis effectués d’une utilisation sur l’autre de Vim.

Personnaliser les replis

Il y a quelques semaines, Martin posait une question relative à TextMate et au folding. Il n’y avait pas dans le bundle Markdown de replis prédéfinis concernant les sections. Voilà un petit script, qui placé dans un fichier .vim/ftplugin/markdown.vim permettra d’avoir des replis sur les sections.

  " Retourne le nombre de '#' au dÃ©but de la ligne dont le numÃ©ro est en paramÃ¨tre
  function! MDSectionLevel(lnr)
    let lc = getline(a:lnr)
    return matchend(lc, '^#*')
  endfunction

  " Fonction de folding pour les section markdown
  function! MDFoldLevel(lnr)
    let lvl   = MDSectionLevel(a:lnr)
    let lvlm1 = MDSectionLevel(a:lnr-1)

    if lvl > 0
      return lvl-1
    else
      if lvlm1 > 0
        return lvlm1
      else
        return '='
      endif
    endif
  endfunction


  set foldexpr=MDFoldLevel(v:lnum)
  set foldmethod=expr

Cet exemple est destiné à illustrer le mode de repli par expression. Pour utiliser ce mode, il faut donner une expression qui lors de son évaluation retourne le niveau d’indentation de la ligne numéro lnum. C’est la fonction MDFoldLevel qui est chargée de retourner ce niveau. Pour cela elle compte le nombre de # présent en début de ligne, lorsqu’il n’y en a pas, on considère que l’on est au même niveau que les lignes qui précédent en retournant '=' qui saura être interprété par Vim. Lorsqu’au contraire il y a des # en début de ligne on retourne un nombre.

Plug-ins

Avec les derniers exemples sur les templates ou le fold, on se rend bien compte que l’on ne peut pas tout écrire. Vim utilise un système de scripts pour ajouter des fonctionnalités. Des gestionnaires de paquets existent comme Vundle afin de simplifier l’utilisation de ces différents scripts. Sur la toile vous trouverez beaucoup de plug-ins facilitant l’utilisation de Ruby, Rails, Git, la recherche et l’ouverture de fichiers, les Snippets, Pastie et beaucoup d’autres choses. Sur le site officiel de Vim vous trouverez une section scripts qui répertorie les différents ajouts existants. Vous trouverez sur github beaucoup de partages de configuration Vim.

Conclusion

J’espère à travers cet article vous avoir un peu plus convaincu de l’intérêt de Vim. Et, j’espère aussi démystifier son utilisation, car beaucoup sont convaincu (à juste titre) que c’est un éditeur puissant mais très difficile à maitriser. Vim est complet, complexe, et plein de (bonnes) surprises. Pour une introduction plus complète que mes deux billets vous pouvez consulter les Vim Recipes qui sont, non pas une référence mais une introduction plus douce que la documentation officielle.

L’équipe Synbioz.

Libres d’être ensembles.

HockeyApp - A great service that lets you test your mobile or mac application.

Jean-Rémi Laisne — Tue, 14 Feb 2012 00:00:00 +0100

When you’re developing an app, there always comes a time when you need to test your app. See how users react to your app idea, check its usability, determine if and when the app crashes and how to handle the crashes, discover if any new features could be implemented… The best way to see how your app behaves on its own and how it is handled by users is to release a beta version of your app. That way, you have access to a whole community of users and developers that will test your app in every possible way.

If you’re a serious reader of our blog -– and we know you are -– , you already know we develop web apps through iteration, a concept stemming from agile web development. We apply the same process to mobile app development. So today, to show you how we test apps, let us introduce to you an outstanding app and great service: Hockeyapp, a service that has only one goal in mind: help you perfect your apps.

Quite frankly, we’re in love with Hockeyapp. It’s that great a service. Say you want to test your app but aren’t sure how to go about it or how to get people to give it a spin. Hockeyapp lets you upload your app on its platform so it can be tested and then supplies you with a seriously good bunch of services for your app. Crashreports, live reporting, bug reporting… You name it. Some of you may have heard of Testflight App: Testflight offers the same kind of services except Hockeyapp is also for Android apps and soon OSX apps.

First, you’ll need to install Hockeyapp and integrate it with your app. This video by Andreas Zeitler (for Hockeyapp) explains to you in a clear and straightforward manner how it’s done:

All integrated and ready to go? Here’s what you need to know about Hockeyapp’s handy features.

Live crash report

HockeyApp lets you know exactly when your app crashes in log like apple format, tells you why and provides you with a variety of views and statistics so you can know everything you need to know about those snide little crashes, immediately after they happen.

All you have to do is integrate an open source library (QuincyKit for iOs and HockeyKit for Android) into your app and voilà! Crash reports are immediately delivered to HockeyApp and then “translated” in a language you’ll understand – no more of that cryptic iOS and Android crash report language for you.

Hockeyapp also helps you make sense of all the crashreports so you can fix the bugs in a timely and efficient way. First, when applicable, the crash reports are grouped together, per place where the crash occurred for instance. This makes bug fixing a lot easier.

Second, you can filter your crashreports any way you like: say you only want to see crashes that occurred on a specific type of device, or just want to see a list of the crashes that haven’t been fixed yet: just create a filter and you’re good to go!

Lastly, HockeyApp can also be integrated directly into your development process so you don’t have to waste anytime working on different systems at the same time. Lucky we are, it works like a charm with our Redmine. So, all you need to do is connect the App to your bug tracking system. This will then allow you to create and assign tickets from within HockeyApp for each group of crashes.

Distribution

Hockeyapp also helps you with distribution, starting with helping you send out your app to the testers. To distribute your beta versions directly onto the testers device, simply upload your application to the server. HockeyApp will then provide you with everything you need to get the app distributed easily, including automatically generated links to install your app on the testers’ devices.

So thanks HockeyApp we won’t be annoyed anymore by sending the ipa file to each users.

Worried about security? The platform offers an array of security measures to toggle with so you can keep out tester, prevent developers from adding their own certificates to your app. Conversely, worried about seeming too restrictive and uptight? Hockeyapp lets the testers you’ve allowed easily access your app. No need to sign up or create an account. Visiting config.hockeyapp.net on your iOS device will give you quick access to all your apps through a single webclip, whether you are a developer or tester.

Analytics

Another major part of testing your device is getting feedback on it. Get an overview of the overall test coverage of your application, see how well each version of your beta app is tested, know exactly which device types the app is being tested on and how it’s performing. Get accurate measures of how long each tester has spent on your app, what they tested the most, who’s actually helping a lot in testing the app and who’s not really spending the required time on it to be useful to you. You know how test slots are precious!

HockeyApp also provides detailed analytics on the different languages your application (status for each language…), as the developers behind this service know perfectly well that more languages your application supports, the more testing is required. By giving you detailed stats on the status for each language your app supports, HockeyApp lets you focus on the areas that need attention.

Conclusion

Like we saw in this article, HockeyApp helps you to deal with your beta version. All the features you need to test your app are in HockeyApp to release a perfect application. Maybe, you are a testflightapp user and happy with that. But if you want try out a new and stunning application, it’s worth giving a shot at HockeyApp.

What is your point of view ? Testflightapp or HockeyApp ?

Adopter un modèle de versionnement efficace avec Git

Nicolas Cavigneaux — Tue, 07 Feb 2012 00:00:00 +0100

Comme vous le savez peut-être, chez Synbioz, nous versionnons le code de nos projets à l’aide du DSCM Git dans le cadre de nos sessions de développement agile.

J’ai au départ été très critique vis-à-vis de Git, de sa relative complexité d’utilisation et de sa courbe d’apprentissage plutôt ardue dès qu’il s’agit de faire des choses un peu évoluées. En effet, je viens du monde de Mercurial que j’utilise depuis plusieurs années et que je trouve beaucoup plus simple d’accès et d’utilisation.

Je me suit donc beaucoup documenté à propos de Git, fais des essais, parcouru les manuels pour comprendre les commandes et leurs utilités puis j’ai cherché à trouver un modèle de travail en équipe satisfaisant, propre et surtout simple à suivre.

Effectivement, si votre équipe ne suis pas une méthodologie de travail pré-déterminée, on se retrouve rapidement avec un historique fouillis, des merges inutiles, …

Récemment, nous avons découvert une méthodologie particulièrement adaptée à notre façon de travailler et qui tire parti des points forts de Git. Pour ne rien gâcher, cette méthologie est accompagnée d’un ensemble de scripts qui étend Git et permettent de respecter facilement les guidelines de cette méthodologie.

Avant de passer à la présentation de cette méthodologie, j’aimerai resituer le contexte. Nous travaillons à plusieurs, sur des projets qui peuvent durer plusieurs mois, voir plusieurs années. Des intervenants externes peuvent eux aussi contribuer au code. Nous avons besoin pour chaque projet d’une version de production, d’une version de développement et éventuellement de branches dédiées à de nouvelles fonctionnalités complexes qui doivent être isolées du reste du développement.

Il faut donc qu’aucun développeur ne fasse l’erreur de travailler dans master qui est considéré comme un reflet du code en production, il faut également que chaque développeur gère correctement ses branches pour ne pas polluer la branche de développement. Si toute l’équipe respecte ces règles, on se retrouve avec un dépôt propre, un historique lisible et cohérent et donc un processus simplifié pour le déploiement en production ou la maintenance d’un serveur de pré-production tout en gardant la possibilité de faire évoluer le code très vite et dans diverses directions sans polluer le code stable.

Le modèle adopté

Nos recherches nous ont mené à cet article qui décrit tout à fait la situation dans laquelle nous sommes et propose un workflow robuste.

Première constatation, le choix de Git n’est pas anodin puisqu’il est particulièrement adapté à un modèle à base de branches. Tout notre worflow se reposera donc sur un système de branches.

Lorsque nous commençons un projet, nous mettons toujours en place un dépôt central qui fait office de référence. Bien que Git soit un outil décentralisé, la mise en place d’un dépôt “maître” s’avère indispensable si vous travaillez à plusieurs. Chaque participant au projet va donc cloner le projet à partir de ce dépôt et c’est également sur ce dépôt que seront envoyées les modifications faîtes.

Une branche de production saine et cloisonnée

Sur notre dépôt, nous avons besoin de pouvoir gérer le code en production ainsi que les développements en cours.

Il est donc pertinent de considérer que la branche “master” représente l’état du code en production.

Il nous suffit maintenant de créer une branche supplémentaire “develop” qui permet de gérer les développements pour les versions à venir, c’est ce qu’on appelle souvent la branche d’intégration :

$ git branch develop
$ git checkout develop

On peut donc dès maintenant contribuer au code et le commiter dans la branche “develop” sans que cela impacte notre code de production, voilà qui permet d’avancer en toute sérénité sans craindre que quelqu’un déploie du code non-testé ou validé.

Une branche pour développer les fonctionnalités futures

Dans “develop” nous allons donc faire de multiples commits pour agrémenter notre logiciel de nouvelles fonctionnalités. Cette branche peut d’ailleurs être utilisée en pré-production pour que vos testeurs et clients puissent profiter des avancements du projet et vous faire des retours.

Mais attention, “develop” n’est pas un fourre-tout et ne devrait être utilisé que pour les petites modifications simples ayant peu d’impact et ne demandant pas plus de 30 min de travail. En effet si vous travaillez directement sur “develop” pour une fonctionnalité estimée à 1 mois de développement, il y a fort à parier que vous aller ennuyer vos collégues avec vos commits qui s’incrustent entre 2 commits légitimes sans pour autant apporter une fonctionnalité finalisée.

Si vous êtes dans ce cas de figure, il vous faut créer une branche dédiée au développement de votre fonctionnalité.

Des branches spécifiques pour les développements lourds

Ces branches de développement (feature) permettent de travailler de manière détachée du reste de l’équipe en onant vos modifications ce qui permet de ne les appliquer sur “develop” qu’une fois satisfait et par la même occasion de ne pas polluer les collègues.

On peut vouloir commencer à développer une fonctionnalité qui ne sera appliquée qu’à la release N+1, la branche de feature est donc dans ce cas l’unique solution puisque tout ce qui est dans develop est considéré comme faisant partie intégrante de la prochaine release.

Une branche de développement est créée à partir de “develop” et sera, une fois terminée, mergée dans “develop”. Ce type de branche reste généralement locale à la machine du développeur qui fini par la merger dans “develop” le moment voulu. Il reste toutefois des cas où ces branches de feature sont partagées sur le dépôt central pour une revue par les autres développeurs.

Voici comment procéder :

$ git checkout -b feature/foo develop

On a donc notre nouvelle branche “feature/foo” basée sur l’état actuel de “develop”. Nous pouvons donc coder et commiter autant de fois que nécessaire. Une fois fini, il faut intégrer cette branche dans “develop” :

$ git checkout develop
Switched to branch 'develop'

$ git merge --no-ff feature/foo
Updating ea1b82a..05e9557
(Summary of changes)

$ git branch -d feature/foo
Deleted branch myfeature (was 05e9557).

$ git push origin develop

On est donc retourné dans la branche “develop” dans laquelle on demande à git de merger notre branche de feature. L’option --no-ff permet de forcer la création d’un commit même si les changements peuvent être intégrés en fast-forward. Ceci permet de garder une trace dans l’historique du développement dans une branche dédiée. Une fois mergée, nous supprimons la branche de feature devenue inutile et on push les modifications sur le serveur central.

Passage en production

Lorsque “develop” atteint un état satisfaisant pour créer un nouvelle release et déployer, il faut merger “develop” dans “master”, bumper la version, ajouter un tag de version, mettre à jour un README, … Enfin le code peut être déployé en production.

On pourrait imaginer qu’à chaque commit dans “master”, un hook soit déclenché pour déployer en production.

Nous allons donc, lors d’une release, créer une branche de support à la release. Les releases sont créées sur la base de la branche “develop” et doivent être mergées dans “master” et “develop”.

Cette branche ne servira qu’à faire des modifications mineures liées à la création de la release :

$ git checkout -b release/v1.2 develop
Switched to a new branch "release/v1.2"

On peut maintenant bumper la version, mettre à jour le changelog, etc

$ git commit -a -m "Bumped version number to 1.2"
[release/v1.1.2 74d9424] Bumped version number to 1.2
1 files changed, 1 insertions(+), 1 deletions(-)

Il ne nous reste plus qu’à merger cette release dans master pour qu’elle prenne effet :

$ git checkout master
Switched to branch 'master'

$ git merge --no-ff release/v1.2
Merge made by recursive.
(Summary of changes)

$ git tag -a v1.2

On souhaite également récupérer ces informations de release dans “develop” :

$ git checkout develop
Switched to branch 'develop'

$ git merge --no-ff release/v1.2
Merge made by recursive.
(Summary of changes)

Notre release est donc intégrée en production (master) et en intégration (develop), on peut supprimer la branche :

$ git branch -d release/v1.2
Deleted branch release/v1.2 (was ff452fe).

Dépanner les bugs critiques en production

Il vous arrivera certainement de faire face à un bug critique passé en production. Que faire dans ce cas ? Comment est-il géré dans le workflow ? Vous pensez peut-être qu’on doit nécessairement passer par une nouvelle release mais ce n’est pas le cas, ce n’est d’ailleurs même pas souhaitable puisque vous intégreriez au passage des fonctionnalités dans “develop” qui ne sont pas encore prête pour la production.

Dans ce cas de figure, il s’agit de faire ce qu’on appelle un “hotfix”. Un hotfix est un patch qui va s’appliquer directement à la branche de production (master) et qui sera ensuite également appliqué sur la branche d’intégration (develop). On peut maintenant déployer la version de production corrigée mais aussi jouir de ces corrections dans “develop”.

Pour se faire, comme toujours nous passerons par l’utilisation d’une branche pour avoir un historique sain :

$ git checkout -b hotfix/v1.2.1 master
Switched to a new branch "hotfix-1.2.1"

On crée une branche basée sur master et on bump la version du projet :

$ git commit -a -m "Bumped version number to 1.2.1"
[hotfix/v1.2.1 41e61bb] Bumped version number to 1.2.1
1 files changed, 1 insertions(+), 1 deletions(-)

On peut maintenant corriger le bug :

$ git commit -m "Fix huge production bug"
[hotfix/v1.2.1 abbe5d6] Fix huge production bug
5 files changed, 32 insertions(+), 17 deletions(-)

Et intégrer la correction en production :

$ git checkout master
Switched to branch 'master'

$ git merge --no-ff hotfix/v1.2.1
Merge made by recursive.

(Summary of changes)

$ git tag -a v1.2.1

mais également en intégration pour ne pas perdre le fix au passage :

$ git checkout develop
Switched to branch 'develop'

$ git merge --no-ff hotfix/v1.2.1
Merge made by recursive.
(Summary of changes)

Le patch étant intégré en production et en développement, on peut supprimer la branche de hotfix devenue inutile :

$ git branch -d hotfix/v1.2.1
Deleted branch hotfix/v1.2.1 (was abbe5d6).

Tous les cas d’usages typiques ont été couverts et on voit qu’en suivant ce workflow, on peut maintenir un dépôt sain avec un historique clair et parfaitement adapté à la manipulation si d’aventure on devait revenir en arrière ou faire sauter une fonctionnalité.

C’est propre et carré mais assez fastidieux n’est-ce pas ? Suivre ce modèle au quotidien demande concentration et discipline, pour tous les développeurs. Heureusement, une bonne âme nous simplifie le travail grâce à un ensemble d’extensions pour Git qui permettent de simplifier l’application de ce workflow.

Git-flow

Git-flow est un ensemble d’extensions pour Git livré sous forme de shell-scripts très simples d’accès.

Git-flow va permettre de suivre le workflow présenté précédemment sans avoir à tout retenir, surtout si comme moi vous êtes un peu perdu avec toutes les commandes et options de Git.

Initialisation

$ git flow init

va permettre de paramétrer votre dépôt pour une utilisation via git-flow. Notez que tout ceci est local ce qui veut dire que vous pouvez très bien utiliser git-flow alors que vos collègues ne l’utilisent pas.

Des questions sur la nomenclature vous seront posées, je vous conseille vivement d’utiliser les valeurs par défaut qui sont quasiment des conventions.

Une fois terminé, vous êtes automatiquement positionné sur la branche “develop”, vous pouvez commencer à travailler.

Créer une branche de feature

$ git flow feature start foo

Vous êtes désormais dans la branche “feature/foo” dans laquelle vous pouvez développer tranquillement votre fonctionnalité. Vous pouvez bien évidemment repartir dans d’autres branches, créer plusieurs branches de feature en parallèle, etc.

Une fois vos modifications terminées et prêtent à être intégrées dans “develop”, vous pouvez finaliser cette branche :

$ git flow feature finish foo

Votre branche “feature/foo” va être mergée dans “develop” puis effacée et vous vous retrouverez à nouveau sur la branche “develop”.

Mise en production

Lorsque “develop” représente l’état souhaité en production, vous pouvez passer à la release :

$ git flow release start v1.0.0

Une branche “release/v1.0.0” est créée, vous pouvez donc bumper la version de l’appli et faire les dernières modifications avant release. Une fois paré, vous pouvez finaliser la release :

$ git flow release finish v1.0.0

Ceci aura pour effet de merger “develop” dans “master”, de taguer la release, puis de back-merger ces modifications dans “develop”. La branche de release sera ensuite supprimée et vous retournerez sur la branche “develop”.

Hotfix

Si vous avez besoin de patcher urgemment la production, vous utiliserez la commande dédiée aux hotfixes :

$ git flow hotfix start typo

Une branche “hotfix/typo” est créée et vous pouvez commencer à patcher. Une fois fini, il suffira de finaliser la branche :

$ git flow hotfix finish typo

Ceci aura pour effet d’appliquer votre fix sur master et develop, d’ajouter un tag puis de supprimer la branche de hotfix. À ce propos, n’oubliez pas de bumper la version avant de finaliser le hotfix.

J’espère avoir pu vous éclairer un peu sur la façon dont nous gérons le code source dans nos équipes et que celà vous donnera envie d’essayer ce worflow qui selon moi devrait permettre à vos dépôts de rester cohérents, de pouvoir gérer indépendamment les avancées fonctionnelles, les patchs et releases sans finir la journée avec un mal de tête !

L’équipe Synbioz.

Libres d’être ensembles.

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

Alexandre Salaün — Wed, 01 Feb 2012 00:00:00 +0100

Il est toujours bon pour un développeur de connaître quelques gems qui vont lui permettre de développer les fonctionnalités de base d’un site ou d’une application. Cet article est la suite du kit du bon développeur rails publié il y a quelques semaines sur le blog. Nous avions pu explorer des sujets tels que le déploiement, l’authentification, les formulaires de recherche mais d’autres thèmes restent à voir, nous allons en explorer une autre partie dans cet article.

Internationalisation

Un site multi-langue entraîne forcément l’utilisation de I18n qui est présent dans Rails. En effet, afin de pouvoir traduire vos contenus il est nécessaire de n’avoir aucun texte en dur dans votre code. Cependant, il est parfois nécessaire de ne traduire qu’une seule partie de la page et dans ce cas il existe des gems pour vous faciliter la tâche.

I18n

I18n est donc utilisé dans Rails pour traduire tous vos textes. Vous pouvez par ailleurs obtenir plus d’informations sur la page I18n sur le site de RubyOnRails. Pour cela, Rails se base sur la langue définie pour I18n. Il vous est possible de la définir via la ligne de commande suivante :

I18n.locale = :fr # pour dÃ©finir franÃ§ais comme langue

Il est également possible de définir une langue par défaut pour votre application dans le fichier config/environment.rb ou config/application.rb selon la version de Rails.

config.i18n.default_locale = :fr

Pour ce qui est de la traduction en elle même il vous suffit de créer des fichier (.yml ou .rb) par langues dans le répertoire config/locales de votre application. Il est également possible de prendre en compte d’autres fichiers en spécifiant où les trouver dans le fichier config/application.rb via la ligne suivante :

config.i18n.load_path += Dir[Rails.root.join('my', 'locales', '*.{rb,yml}')]

Il devient ensuite très simple d’avoir une application traduite dans plusieurs langues. On peut via le controller par exemple spécifier la langue.

class ApplicationController < ActionController::Base
  before_filter :set_locale

  def set_locale
    I18n.locale = params[:locale]
  end
end

Afin d’utiliser vos traductions, il faut utiliser la méthode translate de I18n qui retourne le texte dans la langue spécifiée. Par exemple, dans une vue, si vous avez défini la langue à français vous pouvez reprendre l’exemple qui suit :

  <%= t("views.home_title") %>

Ce code vous affiche le texte défini, en français, pour la clé home_title dans votre fichier config/locales/fr.yml:

fr:
  views:
    home_title: "Page d'accueil"

Ce fichier vous permet également de définir les libellés des attributs des models ou les messages d’erreurs.

fr:
  activerecord:
    attributes:
      category:
        title: "Titre de la catÃ©gorie"

Il est parfois nécessaire de ne traduire qu’une seule partie de la page ou du contenu saisi en base et I18n n’offre pas ces possibilités, il existe donc des gems capables de le faire.

Globalize3

Globalize3 est une gem permettant de traduire du contenu dynamique (attributs d’un modèle). Elle succède à la gem Globalize. Il est possible d’obtenir des informations sur cette gem sur la page Github.

Pour installer cette gem, il vous suffit de l’ajouter à votre Gemfile puis de lancer la commande bundle install :

gem 'globalize3'

Ensuite, il faut spécifier dans le model les champs qui seront traduits :

class Category < ActiveRecord::Base
  translates :title, :description
end

Une migration est alors nécessaire afin de créer la table où seront stockées les traductions :

class CreateCategories < ActiveRecord::Migration
  def self.up
    create_table :categories do |t|
      t.timestamps
    end
    Category.create_translation_table! :title => :string, :description => :text
  end

  def self.down
    drop_table :categories
    Category.drop_translation_table!
  end
end

Attention, pour les projets utilisant Rails 3.1 ou plus, il ne faut pas utiliser la méthode change mais continuer à utiliser up et down.

Pour une utilisation “basique” de votre application, c’est-à-dire, en utilisant une seule langue par page, vous n’aurez rien à faire dans vos vues. En effet, les champs seront affichés dans la langue du site (I18n.locale) et vous allez donc avoir les contenus stockés en base affichés suivant la locale, ce qui est le but pour des sites multi-langues où l’on veut juste avoir le contenu traduit suivant la langue choisie par l’utilisateur.

Cependant, si vous souhaitez utiliser plusieurs langues sur une même page, ce qui est demandé dans certains cas, il vous faut utiliser les blocs définis par Globalize3. Dans les vues de votre projet Rails, ces derniers servent à traduire une partie de votre contenu dans une langue choisie auparavant :

<%
  my_locale = :fr
  # my_locale peut Ã©galement Ãªtre un helper ou une variable dÃ©finie dans le controller.
%>

<% Globalize.with_locale(my_locale) do %>
  <% render :partial => "my_partial_with_locale" %>
<% end %>

On peut donc avoir le contenu des pages en anglais et uniquement la partie qui se trouve incluse dans le bloc Globalize traduite en français par exemple. Il est donc très simple d’utiliser plusieurs langues dans une même vue.

Gestion de fichiers

La gestion de fichiers est un autre point important lors de la création d’une application ou d’un site web. On peut avoir des images à stocker si on permet à l’utilisateur de les uploader par exemple. Différentes gems existent pour vous aider dans cette démarche.

Paperclip

Paperclip est une gem qui permet de gérer des fichiers suite à l’upload par un utilisateur. Il est possible d’obtenir des informations sur cette gem sur la page Github de Paperclip. Afin de pouvoir utiliser cette dernière il est nécessaire d’avoir installé imagemagick. Ensuite, pour installer Paperclip, il vvous suffit de l’ajouter dans votre Gemfile et lancer un bundle install :

gem "paperclip"

Dans le model, il faut spécifier le champ qui concerne le fichier à stocker :

class Category < ActiveRecord::Base
  has_attached_file :logo
end

Il est possible, si le fichier en question est une image de créer différentes versions du fichier, par exemple, stocker l’image dans différentes tailles :

class Category < ActiveRecord::Base
  has_attached_file :logo, :styles => { :large => "600x300>", :medium => "200x100", :thumb => "100x50>" }
  # dans ce cas l'image sera stockÃ©e quatre fois : l'image de base telle qu'elle est uploadÃ©e
  # ainsi que les trois formats dÃ©finis ci-dessus
end

Ensuite, la migration vous permettra de créer les différents champs utilisés par Paperclip :

class AddLogoToCategory < ActiveRecord::Migration
  def self.up
    change_table :categories do |t|
      t.has_attached_file :logo
    end
  end

  def self.down
    drop_attached_file :categories, :logo
  end
end

Après avoir lancer un rake db:migrate vos champs sont donc en base et vous pouvez donc uploader un logo pour vos catégories dans votre formulaire de création ou d’édition :

<%= form_for @category, :html => { :multipart => true } do |f| %>
  <%= form.label :title %>
  <%= form.text_field :title %>

  <%= form.label :logo %>
  <%= form.file_field :logo %>
<% end %>

Par la suite, vous pourrez afficher les images en question dans les formats souhaités :

# pour afficher l'image telle qu'elle a Ã©tÃ© uploadÃ©e
<%= image_tag @category.logo.url %>

# pour afficher l'image en format 'medium'
<%= image_tag @category.logo.url(:medium) %>

Pour supprimer un fichier uploader, il suffit de mettre la valeur du champ en question à nil :

@category.logo = nil

Il est possible de faire fonctionner Paperclip avec le service de stockage d’Amazon S3 via une autre gem, aws-sdk.

D’autres exemples d’utilisation de Paperclip sont disponibles dans un Railscast de Ryan Bates.

Encore une fois Paperclip n’est pas la seule gem disponible afin de vous aider dans la gestion des fichiers.

Dragonfly

Tout comme Paperclip, Dragonfly est une gem permettant de gérer les fichiers dans votre application Rails. Des informations sont disponibles sur la page Github de Dragonfly.

Afin d’installer Dragonfly, il vous faut l’ajouter à votre Gemfile :

gem 'rack-cache', :require => 'rack/cache'
gem 'dragonfly', '~>0.9.10'

La gem rack-cache est nécessaire au fonctionnement de Dragonfly.

Ensuite, ajoutez la ligne suivante dans le fichier config/initializers/dragonfly.rb (qu’il vous faudra créer auparavant si il n’existe pas) :

require 'dragonfly/rails/images'

Vous pouvez maintenant créer la migration qui permettra de stocker le fichier :

class AddLogoToCategory < ActiveRecord::Migration
  def self.up
    add_column :categories, :logo_uid, :string
  end

  def self.down
    remove_column :categories, :logo_uid
  end
end

Puis, dans le model en question (dans notre cas Category), vous devez ajouter un image_accessor :

class Category < ActiveRecord::Base
  image_accessor :logo
end

Il vous est désormais possible d’uploader les logos de vos catégories via un formulaire, dans l’une des vues de votre projet :

<%= form_for @category, :html => { :multipart => true } do |f| %>
  <%= form.label :title %>
  <%= form.text_field :title %>

  <%= form.label :logo %>
  <%= form.file_field :logo %>
<% end %>

Afin de supprimer un fichier, vous pouvez utiliser une checkbox dans votre formulaire :

<%= f.check_box :remove_logo %>

Si cette dernière a pour valeur true alors le fichier sera supprimé.

Pour ce qui est de l’affichage d’une image, contrairement à Paperclip, on ne définit pas les formats d’une image lors de la sauvegarde mais lors de l’affichage.

# pour afficher l'image telle qu'elle a Ã©tÃ© uploadÃ©e
<%= image_tag @category.logo.url %>

# pour afficher l'image dans un autre format
<%= image_tag @category.logo.thumb("200x100").url %>

Dragonfly et Paperclip sont donc deux gems pour la gestion de fichier. Chacun peut choisir celui avec lequel il a le plus d’affinités et qu’il trouve le mieux adapté à ses besoins.

Conclusion

Ces deux articles offrent un bon tour d’horizon des solutions actuelles pour les besoins récurrents. Dans la dernière partie nous évoquerons les tests et les outils annexes.

Connaître ces gems peut s’avérer très pratique, c’est un gain de temps dans la plupart des cas, cela évite de repartir de zéro lors du développement de certaines fonctionnalités.

Au delà des gems présentées, il existe des gems pour presque toutes les fonctionnalités, il vous est donc facile de trouver celle qui est la plus adaptée pour vous.

De plus, la plupart des gems sont disponibles sur Github et il est donc très simple de remonter un bug ou de poser une question. En outre, ces gems sont utilisées par de très nombreux développeurs, on peut donc considérer qu’elles sont testées et approuvées par la communauté.

Il n’y a donc aucune raison pour ne pas utiliser les gems existantes plutôt que de développer soi-même des fonctionnalités de base.

L’équipe Synbioz.

Libres d’être ensembles.

Le méconnu inverse_of

Martin Catty — Fri, 27 Jan 2012 00:00:00 +0100

Rails: le méconnu inverse_of

Active record: le patron de conception

Active record, avant d’être le nom d’une célèbre gem inclue dans rails est le nom d’un design pattern, permettant de faire du mapping objet - relationnel.

C’est à dire qu’il vous permet de manipuler sous forme d’objets vos données stockées dans une base de données.

Optimiser la communication entre les objets et la base de donnée

La gem ActiveRecord vous offre un maximum de confort en mettant à disposition toutes les méthodes pour gérer les opérations basiques de CRUD mais aussi les associations entre tables.

Imaginons deux class product et category:

  class Category < ActiveRecord::Base
    has_many :products
  end

  class Product < ActiveRecord::Base
    belongs_to :category
  end

Regardons quels sont les appels effectués à la base lorsque nous parcourons les objets:

  irb(main):008:0> c2 = Category.first(:include => :products)
    Category Load (0.1ms)  SELECT "categories".* FROM "categories" LIMIT 1
    Product Load (0.2ms)  SELECT "products".* FROM "products" WHERE "products"."category_id" IN (1)
  => #<Category id: 1, name: "TÃ©lÃ©phone", created_at: "2012-01-27 11:21:59", updated_at: "2012-01-27 11:21:59">
  irb(main):009:0> c3 = c2.products.first.category
    Category Load (0.2ms)  SELECT "categories".* FROM "categories" WHERE "categories"."id" = 1 LIMIT 1
  => #<Category id: 1, name: "TÃ©lÃ©phone", created_at: "2012-01-27 11:21:59", updated_at: "2012-01-27 11:21:59">
  irb(main):010:0> c3.object_id == c2.object_id
  => false

ActiveRecord n’est pas suffisamment malin pour comprendre que nous sommes en fait sur la même catégorie quand nous demandons la catégorie d’un produit qui fait parti de la liste des produits de cette même catégorie.

Le rôle d’inverse_of

Redéfinissons nos relations pour utiliser inverse_of:

  class Category < ActiveRecord::Base
    has_many :products, :inverse_of => :category
  end

  class Product < ActiveRecord::Base
    belongs_to :category, :inverse_of => :products
  end

  irb(main):004:0> c2 = Category.first(:include => :products)
    Category Load (0.2ms)  SELECT "categories".* FROM "categories" LIMIT 1
    Product Load (0.2ms)  SELECT "products".* FROM "products" WHERE "products"."category_id" IN (1)
  => #<Category id: 1, name: "TÃ©lÃ©phone", created_at: "2012-01-27 11:21:59", updated_at: "2012-01-27 11:21:59">
  irb(main):005:0> c3 = c2.products.first.category
  => #<Category id: 1, name: "TÃ©lÃ©phone", created_at: "2012-01-27 11:21:59", updated_at: "2012-01-27 11:21:59">
  irb(main):006:0> c3.object_id == c2.object_id
  => true

En explicitant la relation inverse ActiveRecord sait maintenant retrouver ses petits et éviter d’inutiles requêtes SQL.

Les formulaires imbriqués

Imaginons que vous souhaitiez pouvoir créer directement une catégorie avec un ou plusieurs produits et que vous produits doivent obligatoirement avoir une catégorie.

  class Category < ActiveRecord::Base
    has_many :products, :inverse_of => :category

    accepts_nested_attributes_for :products
  end

  class Product < ActiveRecord::Base
    belongs_to :category, :inverse_of => :products

    validates_presence_of :category
  end

Sans inverse_of vous risquez d’avoir des soucis à cause de la validation. En effet, le produit ayant une validation sur sa catégorie, il va chercher à la charger.

Sans inverse_of il essayera de la charger depuis la base de donnée, alors qu’elle n’existe pas encore. Avec, il sera capable de récupérer directement l’objet.

Identity map

Très franchement ActiveRecord nous a habitué à un peu plus de magie et d’automatisme pour que l’on n’ait pas envie de définir manuellement tous ses inverse_of.

D’autant plus qu’il semble assez simple de retrouver les associations concordantes et que cette fonctionnalité est présente dans datamapper.

C’est en fait le rôle de la fonction d’identity map introduite par rails 3.1 mais désactivée par défaut.

L’objectif est de n’avoir jamais à recharger un objet depuis la base quand il est déjà en mémoire.

L’activation de la fonctionnalité se fait dans application.rb

  config.active_record.identity_map = true

  irb(main):005:0> ActiveRecord::IdentityMap.use { c = Category.find(1) ; c2 = Category.find(1) }
    Category Load (57.9ms)  SELECT "categories".* FROM "categories" WHERE "categories"."id" = ? LIMIT 1  [["id", 1]]
    Category Loaded  From Identity Map (id: 1)
  => #<Category id: 1, name: "TÃ©lÃ©phone", created_at: "2012-01-27 11:21:59", updated_at: "2012-01-27 11:21:59">

L’utilisation se fait dans un bloc et l’usage est encore limité. Par exemple utiliser Category.first, même dans le bloc entrainera tout de même 2 requêtes.

De plus l’activation de la fonction ne permet pas pour le moment de remplacer le inverse_of.

C’est pourtant une fonctionnalité très importante car elle permettra de fortement limiter le nombre d’instanciation d’objets.

Pour autant elle n’est pas simple à mettre en place en conservant un comportement tread-safe : on imagine bien deux morceaux de code entrain de mettre à jour le même objet en mémoire.

En résumé, utilisez le inverse_of dès aujourd’hui si ce n’est pas encore le cas car Rails n’est pas prêt de le faire automatiquement pour vous.

L’équipe Synbioz.

Libres d’être ensembles.

L'utilisation de vim

Nicolas Zermati — Wed, 18 Jan 2012 00:00:00 +0100

Une part importante de l’activité des développeurs se résume à éditer de simples fichiers textuels. Ces fichiers permettent de communiquer des instructions aux machines chargées de les exécuter. Pour le confort et la productivité d’un développeur, l’interface qui lui permettra de saisir son code est primordiale.

Je compte deux approches différentes. Les Environnements de Développement Intégrés qui intègrent un maximum d’outils : la gestion des projets, l’édition des sources, la compilation, le débogage, le système de gestion de configuration (SCM), etc. Les EDIs que j’ai en tête : Eclipse, Netbeans ou IDEA pèsent plusieurs centaines de mégaoctets en mémoire, sont associé à une interface d’édition dont les principales fonctionnalités sont l’autocomplétion, le surlignage des erreurs et les snippets de codes. Et, les manipulateurs de textes comme TextMate, Sublime Text, EMACS ou, dans notre cas, Vim.

Je voudrai présenter les bases de la manipulation de texte. Vim est probablement l’éditeur qui embrasse le plus ce concept et je vais plutôt vous présenter les bases de celui-ci. Dans un prochain article, je présenterai quelques aspects plus avancés.

Avant de commencer, je vous recommande de vous procurer Vim, de l’installer et de le tester pendant votre lecture. Peu importe votre plateforme, Vim existe certainement pour cette dernière. Rendez-vous sur cette page de téléchargement pour l’installer.

Vim est un éditeur destiné à une utilisation en ligne de commande, il fonctionne donc tout à fait normalement à distance (en SSH par exemple). Il n’y a pas de menus classiques dans l’interface de Vim. Vim est un éditeur modal. C’est-à-dire que chaque touche va avoir un comportement différent en fonction du mode dans lequel on se trouve. Cela décuple les interactions et la complexité apparente de l’éditeur puisque chaque touche va être utilisée de façon différente selon le mode dans lequel on se trouve.

Vous vous demandez peut-être « Quels sont donc ces différents modes et à quoi servent-ils ? », alors commençons la visite.

Édition : insertion et remplacement

C’est le mode le plus rapide à présenter. En effet, chaque caractère est inséré dans le fichier sous le curseur ce qui est probablement le plus familier des comportements. Pour ceux qui expérimentent pendant leur lecture vous remarquerez que ce n’est pas le mode par défaut de Vim. En effet lorsque vous lancez Vim, vous êtes en mode commande dont on reparlera juste après.

Passer dans le mode d’édition peut se faire d’un grand nombre de manières, j’en vois déjà plus d’une dizaine. Vous pouvez accompagner ce changement de mode par un déplacement prédéfini. Ce sont ces déplacements qui sont à l’origine de cette variété.

Voici un petit récapitulatif des commandes que j’utilise :

Commande	Passage dans le mode insertion
a	après le curseur
A	en fin de ligne
i	sous le curseur
I	en début de ligne
o	sur une nouvelle ligne au-dessous
O	sur une nouvelle ligne au-dessus
R	sous le curseur en mode remplacement

Vous remarquerez qu’il est facile d’associer ces commandes à des mots : ajouter, insérer, ouvrir une ligne, remplacer. Le fait d’utiliser une majuscule ou une minuscule modifie légèrement le comportement tout en conservant l’idée de la commande originale.

Une fois passé en mode insertion, on se retrouve un peu comme prisonnier dans un champ texte, sans menu, sans copier-coller, sans même un fichier à soi. Essayons de retrouver les autres fonctionnalités des éditeurs de textes classiques. Pour cela on repasse en mode commande en pressant ESC.

Commande

Lorsque Vim se lance, on est dans ce mode dit de commande, c’est celui qui se rapproche le plus de ce que les menus peuvent fournir aux autres éditeurs. Il permet d’ouvrir un fichier, d’enregistrer, d’enregistrer-sous, de copier, de coller, etc.

Vim permet d’utiliser les commandes de l’éditeur Ex, un éditeur de texte plus historique encore que Vim lui-même. Cependant l’utilisation d’x est transparente pour l’utilisateur. Je vais présenter les deux catégories de commandes succinctement grâce à quelques exemples.

Les commandes de Vim

Il n’y a pas de retour visuel m’indiquant la commande que je suis en train de taper. Pour afficher le texte de la commande en cours tapez en mode commande : :set showcmd. Après ça vous devriez voir la commande en cours d’écriture en bas à droite de la zone de texte. On peut classer les commandes en deux catégories, les opérateurs et les déplacements. Les opérateurs modifient le texte et les déplacements, comme leur nom l’indique, déplacent le curseur d’un endroit à l’autre du fichier.

Les opérateurs que j’utilise sont les suivants :

Opérateur	Description
c	Changer du texte
cc	Changer la ligne entière
C	Changer du texte jusqu'à la fin de la ligne
d	Supprimer du texte
dd	Supprimer la ligne entière
D	Supprimer du texte jusqu'à la fin de la ligne
y	Copier du texte
yy, Y	Copier la ligne entière
p	Coller du texte supprimé ou copié après le curseur
P	Coller du texte supprimé ou copié sous le curseur
r	Remplacer le caractère sous le curseur
x	Supprimer le caractère sous le curseur
X	Supprimer le caractère précédent le curseur
>, <	Indenter, desindenter d'une tabulation
u	Défaire la dernière action
CTRL + r	Refaire la dernière action
.	Rapplique la dernière commande exécutée

Les principaux déplacements que j’utilise sont les suivants :

Déplacement	Description
w, b	Début du mot suivant ou précédent
W, B	Début du mot suivant ou précédent en ignorant la ponctuation
e, E	Fin du mot courant en ignorant ou non la ponctuation
%	Symbole ouvrant ou fermant correspondant (chevrons, parenthèses, accolades, if / end, balises XML, etc)
h, j, k, l	Gauche, Bas, Haut, Droite
g0, g$	Début ou fin d'une ligne (g facultatif)
^, _	Premier caractère d'une ligne
ENTER, +	Premier caractère de la ligne suivante
-	Premier caractère de la ligne précédente
fx	Premier caractère x après le curseur sur la même ligne
tx	Premier caractère suivi d'un x après le curseur sur la même ligne
nG	Début de la ligne n
G	Fin du fichier
gg	Début du fichier
nG	Début de la ligne n dans le fichier

Pour éditer occasionnellement des fichiers de configuration, ces commandes ne sont pas toutes utiles. Mais, pour celui qui commence à utiliser Vim régulièrement, intégrer ces dernières à son workflow peut s’avérer un gain de temps important.

Voici quelques combinaisons possibles :

Commande	Résultat
c3w	Supprime les 3 prochains mots et passe en mode insertion
5dd	Supprime les 5 lignes sous le curseur
3p	Colle 3 fois le contenu du presse papier
df.	Supprime le texte de la ligne jusqu'au prochain caractère « . »
5u	Défait les 5 dernières actions
5 CTRL + r	Refait les 5 dernières actions
y45G	Copie de la ligne courante à la ligne 45
>%	Indenter jusqu'au symbole fermant

Les commandes de Vim sont généralement de la forme [n] opérateur [m] déplacement. Il est important de pouvoir créer ses propres commandes à la volée. Cela évite par exemple les répétitions de raccourcis (CTRL + v, dix fois de suite) ou encore l’utilisation intensive de la souris pour se déplacer.

Les commandes de ex

Les commandes Ex, commencent par « : », une partie d’entre elles ont des équivalents Vim purs. Par exemple on peut fermer Vim et enregistrer le fichier courant par :x ou bien avec ZZ.

Voici donc les commandes « du style Ex » que j’utilise régulièrement :

Commande	Action
:e	Éditer un fichier
:w	Enregistrer un fichier
:w FILENAME	Enregistrer un fichier sous le chemin FILENAME
:q	Quitte la fenêtre vim
:x, :wq	Sauvegarde puis quitte vim
:n	Se déplace au début de la ligne n
:bnext	Affiche le prochain fichier ouvert (buffer)
:bprevious	Affiche le précédent fichier ouvert
:bdelete	Ferme le buffer courrant
:ls	Affiche la liste des buffers
:wa	Enregistre tous les fichiers ouverts

Visuel

En mode commande, la touche « v » permet de passer en mode visuel, où l’on va pouvoir réaliser des sélections, un peu comme à la souris. Les commandes « V » et « CTRL + v » permettent respectivement de passer en mode visuel par ligne ou par bloc. Testez-les pour en comprendre le fonctionnement ou bien consultez la documentation du mode visuel de vim.

Une fois dans ce mode les commandes de déplacement de Vim sont accessibles pour effectuer la sélection. Par exemple « v55G » passera du mode commande au mode visuel, débutera la sélection à l’endroit du curseur puis ira se placer sur le début de la ligne 55. On peut passer d’un bout à l’autre de la sélection avec « o » et donc déplacer n’importe quelle extrémité de celle-ci.

Se déplacer plus vite

Marques pages

On ne se rappelle pas forcément dans un fichier de log d’un millier de lignes quels sont les numéros de celles qui nous intéressent. Nombre d’éditeurs proposent de poser des marques sur les lignes qui ont de l’importance et auxquelles vous voulez revenir facilement. Vim propose cette fonctionnalité à travers les marques pages.

Poser des marques pages dans un fichier se fait avec « mx » où x est un identifiant. L’identifiant est une lettre minuscule. On peut se déplacer à la ligne de la marque avec « ‘x » ou bien directement au caractère marqué avec « `x ». Pour revenir à l’endroit où on était on peut utiliser « ‘’ » pour revenir à cette ligne ou « `` » pour revenir au caractère précis précédant le déplacement.

La portée de ces marques se limite au fichier ouvert. Pas possible donc de poser une de ces marques dans un fichier et d’y faire appel depuis un autre fichier. Cependant il existe un autre type de marques pages qui ont une portée globale et qui se distinguent simplement par le fait qu’ils utilisent un lettre majuscule ou bien un chiffre comme identifiant.

Gérer plusieurs fenêtres

Parfois il est plus simple, plutôt que de se déplacer, d’avoir deux parties d’un même fichier visible en même temps. Vim propose un système de fenêtres pour cela. Une fenêtre c’est une vue sur une partie d’un fichier. Deux fenêtres peuvent afficher un même fichier, et le faire à des positions différentes. Voici une capture d’écran illustrant un exemple de session où il y a deux fenêtres :

Bien sûr les fenêtres peuvent afficher des fichiers différents.

Voici un récapitulatif des commandes permettant de manipuler ces fenêtres :

Commande	Résultat
:split, CTRL + w s	Sépare horizontalement la fenêtre courante en deux
:vsplit, CTRL + w v	Sépare verticalement la fenêtre courante en deux
:close, CTRL + w c	Ferme la fenêtre si ce n'est pas la dernière
:resize n, zn, n CTRL + w _	Définit le nombre de lignes visible à n
:vertical resize n, n CTRL + \|	Définit le nombre de colonnes visible à n
:only, CTRL + w o	Conserve uniquement la fenêtre active et ferme toutes les autres
CTRL + W DIR	Se déplace dans la fenêtre suivante, dans la direction DIR (h, j, k, l, flêches)

Il est également possible d’utiliser la souris pour redimensionner les fenêtres de Vim (voir l’option mouse).

En complément des fenêtres, il existe des onglets. Ils permettent d’avoir différents ensembles de fenêtres ouvertes et de passer de l’un à l’autre. Je n’utilise pas vraiment les onglets et donc je vous recommande de regarder la documentation pour en savoir plus.

Recherche et substitution

Dans tout bon éditeur de texte, on dispose des fonctions rechercher et remplacer ; dans Vim aussi ces fonctions sont accessibles. On peut effectuer ces opérations sur une plage de ligne, sur une sélection, sur l’ensemble du fichier, etc. Je vais commencer par introduire les différentes commandes de recherches. Il faut savoir que ces commandes se combinent avec les autres comme un déplacement. On peut par exemple supprimer du texte jusqu’au prochain résultat de recherche avec d/pattern.

Commande	Recherche
/pattern	Recherche en avant le motif pattern
?pattern	Recherche en arrière le motif pattern
n, N	Saute au résultat suivant, précédent
*, #	Recherche le mot sous le curseur en avant, en arrière
g*, g#	Recherche le mot sous le curseur autorisant son inclusion dans d'autres mots
:nohlsearch	Desactive le surlignage des résultats d'un recherche jusqu'à la prochaine

Ces commandes permettent de faire de la recherche et des déplacements dans Vim. Il est possible de (des)activer la recherche incrémentale, la coloration des résultats, etc. Les patterns employés utilisent les expressions régulières avec une syntaxe spécifique à Vim.

Le remplacement dans Vim se fait grâce à la commande Ex substitute : « s ». Cette dernière fait partie de Ex et adopte la syntaxe suivante : :[adresse] commande. Les adresses sont généralement de la forme x,y où x est la ligne de début et y la ligne de fin. Il existe en plus des symboles spéciaux dans la description des adresses, essayons d’en faire le tour avec ces quelques exemples :

Adresse	Plage de sélection
1,$	L'ensemble du fichier
%	L'ensemble du fichier également
.	La ligne courante
+n	n lignes après la ligne courante
-n	n lignes avant la ligne courante
/pattern/	La première ligne en avant qui contient pattern
?pattern?	La première ligne en arrière qui contient pattern

Voici de nouveaux exemples pour comprendre l’usage des adresses et de la substitution :

Commande	Substitution
:s/old/new/	Substitue sur la ligne courante la première occurence de « old » par « new »
:s/old/new/g	Idem avec toutes les occurences de la ligne (option g)
:s/old/new/gc	Idem en demandant une confirmation pour chaque remplacement (option c)
:.,+15s/old/new/gc	Idem pour les 16 lignes sous le curseur
:.,/search/s/old/new/gc	Idem pour les lignes du curseur jusqu'à search (en avant)
:%s/old/new/gc	Idem pour toutes les lignes du fichier

Dans ces exemples simples on retrouve la syntaxe des adresses Ex que l’on a vu plus tôt. Ces dernières permettent de spécifier une plage précise de remplacement.

Commande	Substitution
:%s/\$.\$ /\\1/	Supprime tout les espaces en fin de ligne
:%s/[[=e=]]/e/g	Remplace tout les éléments de la classe d'équivalence e (é, è, ê, etc) par des « e »
:%s/todo/\U&/gi	Remplace les occurences de « todo » quelque soit leur casse en « TODO » majuscules

À travers ces trois autres exemples on voit que Vim permet de délimiter des groupes dans ces recherches avec $ et $ et de les réutiliser dans les remplacements avec \1, \2, etc. Il est aussi possible d’utiliser les expressions à crochet de POSIX pour définir des intervalles ([:alnum:], [:digit:], etc.). Et, on voit qu’il existe des caractères spéciaux à utiliser dans les remplacements (\U, &, etc).

La commande de substitution regorge d’autres astuces. Par exemple lorsque le motif recherché est vide (:s//new/) alors c’est la dernière recherche qui est utilisée. Les caractères de séparations sont libres : :s#old#new#gc est tout à fait valable.

Conclusion

Avec ce que l’on a survolé, vous pouvez peut-être déjà vous rendre compte de ce que la manipulation de texte apporte par rapport à la simple édition de texte. Si vous n’êtes pas encore convaincu, je vous invite tout de même à lire le prochain article qui, au travers de plus d’exemples, saura mieux vous convaincre du gain apporté par la maitrise d’un tel outil.

Jusque-là j’ai présenté de quoi s’en sortir avec Vim pour de l’édition occasionnelle, je n’ai pas parlé des macros, des replis, des interactions avec la console, de la configuration ou encore des plugins. Tout ceci sera dans le prochain article qui sera destiné à ceux d’entre vous qui souhaitent utiliser Vim au quotidien.

L’équipe Synbioz.

Libres d’être ensembles.

rbenv pour les développeurs

Nicolas Cavigneaux — Mon, 16 Jan 2012 00:00:00 +0100

Il y a quelques jours, j’ai décidé d’essayer rbenv dont j’entendais beaucoup parler pour sa facilité de mise-en-œuvre côté serveur.

rbenv est un gestionnaire de version de Ruby comparable à RVM mais qui m’a rapidement séduit par sa légèreté et son élégance. C’est rapide, facile à mettre en œuvre, pratique à l’utilisation et tout à fait dans la philosophie des utilitaires Unix.

J’ai donc supprimé RVM au profit de rbenv. N’allez pas croire que RVM est un mauvais outil, je me sens juste plus à l’aise avec rbenv qui correspond mieux à mes attentes.

Utilisation quotidienne

Voici un petit résumé des étapes à suivre et des pièges potentiels. Étant sous OS X, j’ai décidé d’installer rbenv via HomeBrew. il est également possible d’installer rbenv via git.

Installation

$ brew update
$ brew install rbenv
$ brew install ruby-build

Vous avez maintenant votre installation de base. Nous avons installé ruby-build qui va nous permettre de construire facilement nos versions de Ruby sans avoir à récupérer manuellement les sources. Rbenv ayant pour unique but de gérer la version de Ruby en cours d’utilisation, il préfère déléguer ses tâches à des paquets dédiés bien que vous le verrez, à l’utilisation c’est intégré de manière transparente.

Il faut maintenant demander à votre shell d’utiliser rbenv, en ajoutant ceci à votre .zsh_profil ou .bash_profile :

  eval "$(rbenv init -)"

Relancez un shell, rbenv est prêt à être utilisé.

Définition des versions

$ rbenv install 1.9.2-p290
$ rbenv global 1.9.2-p290

Vous avez maintenant Ruby 1.9.2 d’installé et défini comme version par défaut.

Si pour un projet donné vous devez utiliser une autre version :

$ cd Code/foo
$ rbenv local ree-1.8.7-2011.03

rbenv local a pour effet de créer un fichier .rbenv-version qui définit la version de Ruby à utiliser dans ce répertoire.

Il est également possible de passer d’une version à l’autre quand bon vous semble :

$ rbenv shell 1.9.3-p0

Pour finir, vous pouvez connaitre les versions installées :

$ rbenv versions

et celles disponibles à l’installation :

$ rbenv install

Les gemsets

Les utilisateurs de rbenv ont tendance à penser que Bundler est largement suffisant pour gérer les dépendances. Nul besoin de gemset quand le projet lui même peut être le gemset. Si votre projet contient un Gemfile alors pourquoi ne pas faire :

$ bundle install --path vendor/bundle

Vos gems seront directement installés dans le répertoire vendor/bundle de votre projet.

Pensez à ne pas versionner ce répertoire, ce serait un non-sens dans le contexte de l’utilisation de Bundler.

Il est possible d’automatiser ce comportement de Bundler en ajoutant ceci à votre ~/.bundle/config :

---
  BUNDLE_PATH: vendor/bundle

Pour ceux qui ne sont pas convaincus et qui continuent à penser que les gems d’un projet doivent être gérés par un “vrai” gemset, il reste l’extension rbenv-gemset.

rbenv et Pow

J’ai rencontré un problème avec Pow après avoir supprimé RVM, mes instances ne répondaient plus et les logs montraient clairement un problème de version de Ruby.

Il s’avère que Pow n’a pas connaissance des chemins nécessaires au fonctionnement de rbenv de manière automatique même si votre shell fonctionne parfaitement.

Le problème se règle en lui donnant les informations nécessaires via le fichier ~/.powconfig :

export PATH=/Users/cavigneaux/.rbenv/shims:/Users/cavigneaux/.rbenv/bin:$PATH

J’espère que ces quelques informations vous aideront et vous donneront envie de faire un petit essai de rbenv.

L’équipe Synbioz.

Libres d’être ensembles.

Rétrospective 2011

Martin Catty — Wed, 11 Jan 2012 00:00:00 +0100

Rétrospective 2011

Blog

Bilan

Force est de constater qu’en 2011 nous avons su tenir nos bonnes résolutions.

Nous nous étions fixé d’écrire un article par semaine et nous l’avons fait (49 articles en 2011).

Vous êtes de plus en plus nombreux à nous lire et nous nous en félicitons.

Perspectives

Des partenariats sont en cours afin d’élargir encore la diffusion de notre contenu. Comptez sur nous pour en parler prochainement.

Au fil de l’année nous nous sommes rendus compte que, selon les mois, nous avions entre 15 et 20% de lecteurs anglophones.

Même si le contenu français restera privilégié nous souhaitons répondre à ce besoin et avons donc commencé dès à présent à diffuser du contenu en anglais avec notre article sur le monitoring via god.

Enfin cette année a été l’occasion d’introduire quelques invités sur le blog. Nous sommes très fiers de ce partage et allons continuer dans cette voie.

Microblogging

Twitter est un outil plus complexe qu’il n’y parait, au moins en terme de dosage.

Il faut un subtil mélange entre diffusion de ses propres contenus, partage d’information et interactions avec d’autres membres.

Tout cela sans tomber dans l’excès ; au risque de noyer l’information pertinente.

En 2012 nous souhaitons multiplier les échanges avec vous.

Faire vivre les technologies que nous aimons

Ruby et rails sont nos technologies de prédilection, mais ce ne sont pas les seules que nous utilisons et apprécions.

Petit à petit d’autres technologies (html5, websocket, SVG, coffeescript…) sont venues agrémenter notre panel de compétences.

En 2012 nous voulons continuer à diffuser notre connaissance de ces technologies, qui n’ont malheureusement pas encore une place intégrante dans les cursus scolaire.

Si vous souhaitez que nous venions assurer une présentation, comme nous avons pu le faire à Supinfo cette année, n’hésitez pas à nous contacter.

Enfin, nous continuerons d’être des acteurs, voire organisateurs, des apéros ruby du Nord afin de contribuer à la communauté locale.

Cap sur 2012

En 2011, notre équipe s’est agrandie avec l’arrivée d’Alexandre et Nicolas ; faisant de Synbioz une équipe à taille humaine capable de résoudre chacune de vos problématiques.

Si vous avez une idée, un projet, un besoin, n’attendez pas, contactez nous. Nous serons heureux de vous conseiller et de vous accompagner.

Nous avons été ravis de passer 2011, alors à très vite en 2012.

L’équipe Synbioz.

Libres d’être ensembles.

Monitoring server-side processes with God

Nicolas Cavigneaux — Wed, 04 Jan 2012 00:00:00 +0100

Have you ever needed to put a critical website online? Ensure that it’s up & running 24/7? If you did, you know that it can be a real pain to check that everything is ok, that all services are running, that no process is eating too much resources (CPU / memory).

Here at Synbioz we have to ensure services reliability for our customers. There are many ways to do that, you can write your own shell scripts, play with some crontabs, send email on failure, … But it is kind of difficult to write effective scripts, ensure it’s working well and more over, most of the time your homemade scripts will not be portable and will only work with a specific application. So what is the best way to handle this?

God is upon you!

Here comes God which is a monitoring framework you can rely on to keep your processes and tasks running well. God is written in Ruby and aims to be a simple, powerful and flexible way to write monitoring tasks.

Before going deeper into God, you must know that it will only work on Unix-like systems. Sorry Windows users but hey I know you never ever want to deploy a production app on a Windows server…

God config files are written in Ruby, so you can do basically everything Ruby allows you to do, and it’s a lot of stuff.

God features are:

Config files are written in Ruby
Easily write your own custom conditions in Ruby
Supports both poll and event based conditions
Different poll conditions can have different intervals
Integrated notification system (eg: XMPP notifier)
Easily control non-deamonizing scripts

God basics

Install

You must first start by installing God on your system, I mean the production server:

$ sudo gem install god

or add it to your Gemfile like so:

gem "god"

You can now create a God configuration file for the deamon you want to monitor:

$ touch config/unicorn.god

Naming config file with .god extension is a convention but this file is in fact a plain Ruby file.

Handle deamons start and stop

RAILS_ROOT = File.dirname(File.dirname(__FILE__))

God.watch do |w|
  pid_file = File.join(RAILS_ROOT, "tmp/pids/unicorn.pid")

  w.name = "unicorn"
  w.dir = RAILS_ROOT
  w.interval = 60.seconds
  w.start = "unicorn -c #{RAILS_ROOT}/config/unicorn.rb -D"
  w.stop = "kill -s QUIT $(cat #{pid_file})"
  w.restart = "kill -s HUP $(cat #{pid_file})"
  w.start_grace = 20.seconds
  w.restart_grace = 20.seconds
  w.pid_file = pid_file
  
  w.uid = 'nico'
  w.gid = 'team'
  
  w.env = { 'RAILS_ENV' = "production" }

  w.behavior(:clean_pid_file)
end

God monitoring

We’re now going to enhance our config file to add real process monitoring. Monitoring will allow us to check CPU and memory usages by process:

RAILS_ROOT = File.dirname(File.dirname(__FILE__))

God.watch do |w|
  pid_file = File.join(RAILS_ROOT, "tmp/pids/unicorn.pid")

  w.name = "unicorn"
  w.interval = 60.seconds
  w.start = "unicorn -c #{RAILS_ROOT}/config/unicorn.rb -D"
  w.stop = "kill -s QUIT $(cat #{pid_file})"
  w.restart = "kill -s HUP $(cat #{pid_file})"
  w.start_grace = 20.seconds
  w.restart_grace = 20.seconds
  w.pid_file = pid_file
  
  w.behavior(:clean_pid_file)
  
  # When to start?
  w.start_if do |start|
    start.condition(:process_running) do |c|
      # We want to check if deamon is running every ten seconds
      # and start it if itsn't running
      c.interval = 10.seconds
      c.running = false
    end
  end

  # When to restart a running deamon?
  w.restart_if do |restart|
    restart.condition(:memory_usage) do |c|
      # Pick five memory usage at different times
      # if three of them are above memory limit (100Mb)
      # then we restart the deamon
      c.above = 100.megabytes
      c.times = [3, 5] 
    end

    restart.condition(:cpu_usage) do |c|
      # Restart deamon if cpu usage goes
      # above 90% at least five times
      c.above = 90.percent
      c.times = 5
    end
  end
  
  w.lifecycle do |on|
    # Handle edge cases where deamon
    # can't start for some reason
    on.condition(:flapping) do |c|
      c.to_state = [:start, :restart] # If God tries to start or restart
      c.times = 5                     # five times
      c.within = 5.minute             # within five minutes
      c.transition = :unmonitored     # we want to stop monitoring
      c.retry_in = 10.minutes         # for 10 minutes and monitor again
      c.retry_times = 5               # we'll loop over this five times
      c.retry_within = 2.hours        # and give up if flapping occured five times in twoÂ hours
    end
  end
end

You can repeat the God watch block as much as you need to handle other deamons your application makes us of.

Usage

Now that your config file is ready, you can check current God status

$ god status

which will tell you that unicorn is down. So we’re going to start it:

$ god -c config/unicorn.god

Same but not deamonized:

$ god -c config/unicorn.god -D

God status should now tell you that unicorn is up and running.

$ god log unicorn

will show you what God did with the deamon and will also show you monitoring results such as last memory and CPU usages in real-time.

If you like to play you can now try to kill unicorn process from another shell and look at what happen in God logs:

$ kill $(cat tmp/pid/unicorn.pid)

You should see that God detected that unicorn isn’t running anymore, deleted pid file if it existed and started unicorn deamon again.

Now if you need to stop all God monitorings:

$ god terminate

or a given one:

$ god stop unicorn

Server init process

Great we’re happy with our monitoring system, but how do I start this thing when server starts or reboots? You have to write an init script! But relax, I have one for you:

Init script

#!/bin/bash
#
# God
#
# chkconfig: - 85 15
# description: start, stop, restart, status for God
#

RETVAL=0

case "$1" in
    start)
      god -P /var/run/god.pid -l /var/log/god.log
      god load /etc/god.conf
      RETVAL=$?
      ;;
    stop)
      kill `cat /var/run/god.pid`
      RETVAL=$?
      ;;
    restart)
      kill `cat /var/run/god.pid`
      god -P /var/run/god.pid -l /var/log/god.log
      god load /etc/god.conf
      RETVAL=$?
      ;;
    status)      
      /usr/bin/god status
      RETVAL=$?
      ;;
    *)
      echo "Usage: god {start|stop|restart|status}"
      exit 1
  ;;
esac

exit $RETVAL

Global God config file

As you can see, the above script makes use of a file named /etc/god.conf. This file has only one simple purpose, load a bunch of God config files at once:

God.load "/etc/god/*.god"

This trick allows you to create a symlink of your app God config files into /etc/god/ directory to ensure it will be loaded on server boot. This is very similar to the technique used for Mongrel.

Now you can do:

$ /etc/init.d/god start

$ /etc/init.d/god status

$ /etc/init.d/god stop

Notification on failures

Let’s say you want to be notified everytime a process exits, you can add this to your God configuration file:

w.transition(:up, :start) do |on|
  on.condition(:process_exits) do |c|
    c.notify = 'devteam'
  end
end

Now god knows that everytime our process exits when starting it should send a notification to “devteam”. You can use notify in any condition block.

But what is “devteam” and how the hell are notification sent?!

Sending emails

First solution is to send email.

We’ll first start by defining some default for email in our God config file:

God::Contacts::Email.defaults do |d|
  d.from_email = 'god@synbioz.com'
  d.from_name = 'God'
  d.delivery_method = :sendmail
end

Then we need to define a contact:

God.contact(:email) do |c|
  c.name = 'Dev Team'
  c.group = 'devteam'
  c.to_email = 'team@synbioz.com'
end

You can define as much contacts as you need but be sure “name” attribute is unique! Now our dev team will receive email notification when there’s such a problem.

Jabber notifications

You don’t like emails and want XMPP notifications? No problem:

God::Contacts::Jabber.defaults do |d|
  d.host = "jabber.synbioz.com"
  d.from_jid = "foo@synbioz.com"
  d.password = "bar"
end

God.contact(:jabber) do |c|
  d.to_jid = "baz@synbioz.com"
end

Other notification systems

You can also use Campfire, Prowl, Scout, Twitter and WebHook to send notifications. They are part of God core.

You can easily extends notifications if you need to use your own system, maybe an internal tracking system.

God is good for you!

I hope this quick introduction to God will be helpful for those of you who want to monitor their applications. Don’t think God is only for Rails apps or even Ruby apps. You can use God for anything you want to monitor, Rails projects or not!

Synbioz Team.

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

Alexandre Salaün — Wed, 28 Dec 2011 00:00:00 +0100

Tout bon développeur se doit d’avoir quelques outils pour créer sites et applications. A l’instar d’un mécanicien et de sa trousse à outils, un développeur Rails a son lot de gems indispensables.

Il existe différentes fonctionnalités que l’on va retrouver sur une très grande majorité des sites ou applications web. Il n’est pas nécessaire pour celles-ci de tout refaire à la main à chaque fois, il existe des gems.

Authentification et gestion des utilisateurs

L’une des premières fonctionnalités demandée lors de la création d’un site est l’authentification d’utilisateur.

Cette fonctionnalité est particulièrement sensible en terme de sécurité, vouloir tout refaire à la main, c’est à coup sûr exposer son client à une faille.

Généralement l’utilisateur doit pouvoir créer un compte, se connecter, se déconnecter, etc… ; nous allons donc découvrir l’une des gems qui permet de gérer tout cela.

Devise

Devise est une gem disponible pour Rails 2.3 et Rails 3. Différents modules sont disponibles suivant les besoins que vous avez. Il est possible de valider les créations de compte avec un email par exemple.

Pour utiliser cette gem dans votre application il suffit de l’ajouter à votre Gemfile :

gem 'devise'

Puis, un bundle install suffit à installer Devise. Ensuite, il vous faut configurer cette gem avant de pouvoir l’utiliser. Pour cela, il vous faut lancer la commande suivante :

rails generate devise:install

Enfin, vous pouvez créer votre MODEL (que nous appelons ici USER mais vous pouvez choisir le nom que vous souhaitez) avec Devise pour pouvoir gérer des utilisateurs :

rails generate devise USER

Suite à ceci, vous allez donc avoir un model User, ainsi qu’une migration pour créer la table en base et également de nouvelles routes dans votre fichier routes.rb. Il est maintenant possible pour une utilisateur de créer un compte, de se connecter, etc…

Vous pouvez ensuite configurer le fonctionnement afin de répondre aux fonctionnalités souhaitées.

Si vous souhaitez aller plus loin avec Devise, vous pouvez consulter le Railscast de Ryan Bates.

Devise n’est pas la seule gem capable de vous aider en ce qui concerne la gestion d’utilisateurs. En effet, il existe également d’autres gems telles que Authlogic par exemple.

Il est également possible que vous ayez besoin de permettre aux utilisateurs de se connecter via différents autres sites ou outils existants (Facebook, Twitter, LDAP…). Pour vous y aider, il y a OmniAuth ; vous permettant d’intégrer la connexion via les réseaux sociaux sur votre site ou application web.

Maintenant que nous avons vu comment permettre à un utilisateur de se connecter sur votre site, vous pouvez avoir besoin de gérer des droits d’accès en définissant des rôles.

Cancan

Cancan est une gem permettant de gérer les autorisations et les droits d’accès à certains contenus. En effet, vous pouvez définir ce qui est disponible ou non pour l’utilisateur connecté. Cette gem fonctionne parfaitement avec Devise ou Authlogic par exemple.

Pour installer cette gem, si vous utilisez Rails 3, il vous suffit de l’ajouter dans votre Gemfile :

gem 'cancan'

Si vous utilisez Rails 2, vous devez ajouter cette ligne dans votre fichier environment.rb (après avoir installé la gem) :

config.gem "cancan"

Ensuite, il vous faut ajouter un champ role à votre model User. Puis, il faut définir une classe Ability_où se trouveront les permissions des utilisateurs. Si l’on a par exemple, des utilisateurs avec un rôle _admin ou author, on initialise les droits en fonction de ce rôle.

class Ability
  include CanCan::Ability

  def initialize(user)
    user ||= User.new
    send user.role
  end

  def admin
    can :manage, :all
  end

  def author
    can [:create, :read, :update], [Article, Dossier]
  end
end

Ici, l’admin a tous les droits alors que l’author ne peut que créer, lire ou modifier des Dossiers et Articles.

Vous pouvez contrôler les autorisations depuis le controller, par exemple pour vérifier si l’utilisateur connecté peut voir l’article qu’il a sélectionné :

def show
  @article = Article.find(params[:id])
  authorize! :read, @article
end

Ou bien, vous pouvez afficher un bloc dans une vue uniquement si l’utilisateur possède les droits nécessaires.

<% if can? :read, @article %>
  <%= link_to "Voir l'article", article_path(@article) %>
<% end %>

Vous pouvez également gérer les erreurs lorsque l’utilisateur n’a pas accès à une page par exemple. Plus de détails sont disponibles sur le Github de Cancan.

Créer des formulaires

La gestion des utilisateurs n’est pas le seul point indispensable d’un site. La création de formulaires en fait également parti. Il est nécessaire d’avoir des formulaires pour créer ou éditer différents objets, pour se connecter… Il existe donc différentes gems pour vous aider à créer vos formulaires.

Formtastic

Formtastic est une gem qui vous permet, à travers un DSL, de créer des formulaires. Cette gem est compatible avec Rails 2 et 3.

Pour pouvoir utiliser Formtastic dans votre projet, vous devez l’ajouter dans votre Gemfile puis lancer un bundle install.

gem 'formtastic'

Ensuite, il vous faut installer la gem grâce à la commande suivante :

rails generate formtastic:install

A partir de là, vous pouvez utiliser cette gem dans vos vues pour créer vos formulaires.

<%= semantic_form_for @article do |f| %>
  <%= f.inputs do %>
    <%= f.input :title %>
    <%= f.input :content, :input_html => { :class => 'article_content', :rows => 5, :cols => 50 }%>
    <%= f.input :draft, :as => :radio %>
    <%= f.input :categories, :as => :select, :collection => Categorie.find(:all) %>
  <% end %>
  <%= f.buttons do %>
    <%= f.commit_button %>
  <% end %>
<% end %>

Dans le cas présent, on crée un formulaire pour un article avec un champ title qui est un input de type text, un champ content qui est un text_area (pour lequel on spécifie des options), un champ draft qui est un bouton radio et enfin un champ categories qui est un select. Enfin, on retrouve le bouton de validation du formulaire. Il vous est possible de créer une multitude d’options pour mettre en forme votre formulaire selon vos souhaits.

En plus de vous simplifier la tâche, Formtastic génère un code sémantiquement riche. Il ajoute également des balises HTML5 telles que phone, email… On y retrouve également une gestion des messages d’erreurs.

Formtastic n’est pas la seule gem qui permet une création simplifiée des formulaires. En effet il existe aussi simple_form par exemple. Encore une fois, vous pouvez choisir celle qui vous convient le mieux par rapport à vos besoins et vos habitudes.

Moteur de recherche

Sur un site ayant un contenu suffisamment important, il peut être nécessaire d’avoir un moteur de recherche.

Ransack

Ransack est un outil qui vous permet de créer un moteur de recherche sur votre site. Il vous permet de gérer vos recherches selon deux types simple ou avancé (advanced). Pour l’utiliser, il vous faut tout d’abord l’ajouter à votre Gemfile :

gem 'ransack'

Ensuite, vous pouvez créer une recherche comme dans l’exemple ci-dessous :

def index
  @q = Article.search(params[:q])
  @articles = @q.result
end

On effectue une recherche sur les articles avec les paramètres transmis par un formulaire de recherche puis on retourne les articles correspondants.

Il faut également créer ce formulaire de recherche dans votre afin de spécifier les critères de recherche.

<%= search_form_for @q do |f| %>
  <%= f.label :title_start %>
  <%= f.text_field :title_start %>
  <%= f.label :content_cont %>
  <%= f.text_field :content_cont %>
  <%= f.submit %>
<% end %>

On utilise le DSL pour savoir si le contenu d’un article contient bien l’expression donnée (avec cont ajouter au nom du champ) ou bien si le titre commence par un mot ou une expression donnée (avec start ajouté au nom du champ). Il existe de nombreux critères pour effectuer votre recherche.

Encore une fois, il n’y a pas une seule et unique gem pour faire cela. Ransack est une réécriture de MetaSearch et d’autres gem existent.

Thinking Sphinx

Pour les applications nécessitant un moteur de recherche plus performant, vous pouvez utiliser le logiciel Sphinx. Celui-ci est un moteur de recherche indépendant de votre application Rails, il ne fait que génèrer un index à partir de la base de données. Cette indexation ne se fait d’ailleurs pas automatiquement, elle doit être invoquer régulièrement (par exemple via un cron). Afin de faire le lien entre votre application (en l’occurrence Active Record) et Sphinx, il existe une gem Thinking Sphinx.

Cette dernière vous propose un certain nombre d’options afin de gérer vos recherches. Vous pouvez par exemple configurer une taille minimum pour les mots ou encore effectuer une recherche sur des morceaux de mots.

Pour installer cette gem, il vous suffit de l’ajouter à votre Gemfile.

gem 'thinking-sphinx'

Ensuite, il vous faut définir les champs sur lesquels la recherche va s’effectuer pour le model que vous souhaitez.

class Article < ActiveRecord::Base
  define_index do
    indexes title, :sortable => true
    indexes content

    has created_at, updated_at
  end
end

Deux méthodes sont utilisées. La première, indexes, permet d’indexer les champs pour lesquels on pourra effectuer une recherche. La deuxième, has, permet de définir des attributs. Ils permettent de faire un tri par exemple.

Ensuite, il faut lancer l’indexation des champs grâce à la tâche rake suivante :

rake thinking_sphinx:index

Puis vous devez démarrer Thinking Sphinx :

rake thinking_sphinx:start

Enfin, vous pouvez effectuer une recherche sur vos articles:

Article.search "un article", :order => :created_at, :sort_mode => :desc
# on cherche les articles contenant dans leur titre ou contenu l'expression "un article"
# et triÃ© par ordre dÃ©croissant sur le critÃ¨re "created_at".

Il vous est donc possible d’effectuer des recherches sur un model donné. Vous pouvez obtenir beaucoup de détails sur le site de Thinking Sphinx.

Pagination

Certaines pages de votre site peuvent contenir des listes de résultats très longues et dans ce cas, il vaut mieux utiliser la pagination afin d’éviter les pages qui n’en finissent plus.

Will Paginate

Will Paginate est une gem permettant de paginer vos résultats très simplement.

Pour installer will_paginate_ dans une application Rails 3, il vous faut ajouter la gem dans votre Gemfile :

gem 'will_paginate', '~> 3.0'

Ensuite, il vous suffit de spécifier, dans votre controller, que les résultats sont paginés tout en indiquant les paramètres correspondants.

def index
  @articles = Article.paginate(:page => params[:page])
  # on indique la page sur laquelle l'utilisateur se trouve
end

Il est également possible de spécifier le nombre de résultats par page.

@articles = Article.paginate(:page => params[:page], :per_page => 20))

Vous pouvez appliquer une pagination sur une relation Active Record.

@articles = Article.where(:draft => false).paginate(:page => params[:page], :per_page => 20))

Enfin, il faut ajouter la gestion des pages dans votre vue et pour cela il vous faut uniquement ajouter le bloc suivant:

<%= will_paginate @articles %>

Ceci aura pour effet d’ajouter dans votre vue html un bloc contenant des liens vers les pages suivantes et précédentes ainsi que quelques liens directs vers des pages précises. Il est possible de configurer l’affichage du sélecteur de page dans votre vue.

De nombreux paramètres sont à votre disposition pour obtenir ce qui convient le plus à vos besoins.

Afin d’effectuer une pagination sur votre site ou application vous pouvez également utiliser la gem kaminari.

Déploiement

Le déploiement d’une application ou d’un site web n’est pas la partie la plus simple. Dans ce cas encore, l’usage d’une gem pour vous faciliter la tâche peut s’avérer utile.

Capistrano

Capistrano est un outil permettant d’exécuter des commandes sur différentes machines distantes.

On utilise pour cela un DSL afin de définir différentes tâches à exécuter. Celles-ci sont définies dans un fichier (capfile).

Une fois que vous avez créé votre fichier et que vous avez renseigné les différentes tâches à accomplir, il faut savoir sur quelles machines vous voulez déployer votre site ou application. Ceci se fait dans le fichier deploy.rb du répertoire config de votre projet. Vous pouvez obtenir plus de détails sur la façon d’utiliser capistrano dans notre article concernant le déploiement.

Conclusion

Il existe donc de nombreuses gems qui vont vous faciliter la tâche lors de l’ajout de fonctionnalités de base. Pour chacune d’entres elles, différentes gems peuvent être utilisées.

Il n’y a pas une gem parfaite dans chaque cas, c’est à vous de choisir celle qui vous semble la plus appropriée et qui vous convient le mieux.

Investissez le temps que vous ne passerez pas à développer à bien choisir vos outils et lire leur code. La gem est elle activement maintenue, puis je facilement remonter un bug, y a t-il une communauté active autour, est-elle bien testée ?

Cet investissement en veille, à l’affut des bons outils, vous sera largement récompensé à chaque fois que vous trouverez chaussure à votre pied.

L’équipe Synbioz.

Libres d’être ensembles.

Commande	Substitution
:%s/\\(.\\) /\\1/	Supprime tout les espaces en fin de ligne
:%s/[[=e=]]/e/g	Remplace tout les éléments de la classe d'équivalence e (é, è, ê, etc) par des « e »
:%s/todo/\U&/gi	Remplace les occurences de « todo » quelque soit leur casse en « TODO » majuscules

L'actualité de Synbioz

L'utilisation de vim (suite)

Interactions avec la console

Buffers de copie

Macros

Statiques

Abréviations

Mapping

Fonctions

Dynamiques

Templates

Les replis

Personnaliser les replis

Plug-ins

Conclusion

HockeyApp - A great service that lets you test your mobile or mac application.

Live crash report

Distribution

Analytics

Conclusion

Adopter un modèle de versionnement efficace avec Git

Le modèle adopté

Une branche de production saine et cloisonnée

Une branche pour développer les fonctionnalités futures

Des branches spécifiques pour les développements lourds

Passage en production

Dépanner les bugs critiques en production

Git-flow

Initialisation

Créer une branche de feature

Mise en production

Hotfix

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

Internationalisation

I18n

Globalize3

Gestion de fichiers

Paperclip

Dragonfly

Conclusion

Le méconnu inverse_of

Rails: le méconnu inverse_of

Active record: le patron de conception

Optimiser la communication entre les objets et la base de donnée

Le rôle d’inverse_of

Les formulaires imbriqués

Identity map

L'utilisation de vim

Un éditeur modal

Édition : insertion et remplacement

Commande

Les commandes de Vim

Les commandes de ex

Visuel

Se déplacer plus vite

Marques pages

Gérer plusieurs fenêtres

Recherche et substitution

Conclusion

rbenv pour les développeurs

Utilisation quotidienne

Installation

Définition des versions

Les gemsets

rbenv et Pow

Rétrospective 2011

Rétrospective 2011

Blog

Bilan

Perspectives

Microblogging

Faire vivre les technologies que nous aimons

Cap sur 2012

Monitoring server-side processes with God

God is upon you!

God basics

Install

Handle deamons start and stop

God monitoring

Usage