Gestion de la cohérence des migrations Rails 5 en utilisant des branches Git

Nous nous sommes posés la question théorique suivante : que se passe t-il si une branche master, représentant le site de production, continue d’évoluer en parallèle d’une branche de développement, représentant un site de démonstration de fonctionnalités ?

Est-ce que le framework Rails serait capable de retrouver la cohérence entre des migrations en se basant sur leurs timestamp de génération, sachant que tous les fichiers du dossier db/ sont correctement rassemblés lors des merges, mais que le schema.rb perd l’information des champs ajoutés en base au fur et à mesure ?

Nous avons tenté l’expérience, voici notre retour :

1. Pour mettre la branche dev sur la branche master, on commence par merger master dans dev pour que les conflits aient lieu en dev.

Lors d’un conflit de schema.rb, conserver toujours la migration la plus ancienne :

Après conflit, il doit rester ceci :

2. On applique ce nouveau schema.rb sur la branche dev avec l’habituel rake db:migrate et on observe la réécriture du schema.rb :

3. On va sur la branche master et on merge dev dans master. Normalement, on est content.

Gestion des erreurs 404 et 500 en Ruby on Rails

Concept

La gestion native des erreurs en ROR souffre de deux manques : d’abord, les erreurs ne sont pas chartées selon le style de votre application, ensuite elles n’alertent pas les développeurs de ce qui s’est produit. Le code ci-dessous peut être placé directement dans l’application ou au sein d’une gem.

Étape 1 : Intercepter les erreurs 404, 422 et 500

Dans le routeur d’URL, ajouter les lignes suivantes :

Lorsqu’une erreur se produit, le moteur de Rails appelle automatiquement ces routes. En ajoutant les routes ci-dessus, on va pouvoir modifier le comportement natif de votre appli en les interceptant dans nos méthodes.

Étape 2 : Méthodes dans le contrôleur

Tout commence par la création d’un contrôleur dédié :

Ce code est simplifiable si vous ne le placez pas au sein d’une gem, mais bon, ça peut rapidement devenir un couteau suisse dans tous vos projets.

Étape 3 : le mailer

Bon là rien d’exceptionnel :

Étape 4 : Les vues des mailers fraichement créés

Pour les 404 je vous suggère d’extraire quelques infos utiles telles que @requete.remote_ip, @requete.user_agent, @requete.request_method, @requete.original_url ou encore @requete.filtered_parameters.to_s (les paramètres de la requête).
Pour les 500, vous pouvez ajouter :

Étape 5 : les vues des méthodes en question

N’oubliez donc pas de créer les vues correspondant aux méthodes selon les choix que vous aurez réalisé à la lecture de l’article.

Nous sommes à l’écoute de toute suggestion car la gestion des erreurs ne semble pas très élaboré d’origine.

Quelles technologies se cachent derrière le format de paquets snaps « by Canonical » ?

Principe de fonctionnement des snaps

Contrairement aux paquets habituels sous Linux, les snaps ne partagent pas leurs dépendances. C’est ce qui explique que les logiciels empaquetés dans des snaps soient indépendants du système. Les paquets sont bien plus lourds et chaque logiciel lancé chargera en RAM l’intégralité de ses dépendances sans les partager.

Un paquet snap est une archive SquashFS montée en lecture seule, exactement comme un Live CD sous Linux. Les paquets sont signés comme les dépôts et mis à jours de manière transactionnelle. Les mises à jours n’ajoutent que les différences entre la nouvelle version et l’actuelle, sans retélécharger intégralement le paquet.

Chaque paquet dispose d’autorisations précises pour accéder à d’autres applications, services ou fonctionnalités du système d’exploitation (via AppArmor). Leurs dossiers « tmp » sont séparés.

Un snap peut difficilement endommager ou déstabiliser le système :

Contrairement aux conteneurs à la mode, type docker et compagnie, les paquets sont montés dans des dossiers isolés par confinement, ils utilisent donc le noyau du système et n’ont pas d’interface réseau individuelle requérant une gestion NAT compliquée.

Le système Ubuntu complet a été découpé et mis dans des snaps dans l’édition Ubuntu Core. Voici à quoi ressemble l’OS actuel :

Et voici Ubunutu Core :

Sur Ubuntu Core, les .deb ne disparaissent pas du système pour autant mais ne sont plus la voie principale pour installer des paquets, puisqu’apt semble placé dans un conteneur (assez peu d’info trouvée à ce sujet). Dans un premier temps en revanche, l’option la plus souple semble d’installer snapd (l’apt des snaps) sur un système non-snappy tel que l’Ubuntu Desktop classique, ce qui vous prive toutefois du déploiement facilité de mises à jour d’Ubuntu Core.

Vous pouvez trouver plus d’informations en écoutant cette conférence de l’Ubuntu Party de Paris.

Que sont les paquets Snaps développés par Canonical pour la portabilité ?

Introduction

Avec son désir d’interface graphique « convergeante », c’est à dire adaptative entre des tailles d’écran très différentes, Canonical doit faire face à des problèmes de portabilité de ses applications.

Le monde mobile a ceci de particulier que les périphériques sont vendus préinstallés, à des utilisateurs néophytes, le plus souvent sur l’architecture ARM réputée plus complexe que le monde standardisé des processeurs x86 de bureau. Mettre le téléphone d’un utilisateur à jour et à distance relève dès lors du défis. L’univers Android le connait bien, puisque les téléphones reçoivent au mieux quelques mises à jour avant d’être abandonnés.

L’entreprise Canonical veut éviter de tomber dans ce piège et pouvoir gérer elle même les mises à jours de tous les périphériques utilisant son OS, mobiles comme ordinateurs de bureau. Cela lui permettra d’une part d’éviter une fragmentation importante des versions de son OS sur le marché mobile, d’autre part d’étendre la prise en charge de ses applications sur ordinateur de bureau vers d’autres distributions Linux.

Des paquets universels

La solution envisagée repose sur la création d’un format de paquet universel, différent de deb ou rpm, capable de s’installer sur tout système d’exploitation Linux ayant installé le logiciel snapd, équivalent d’apt. Snappy est déjà disponible dans Gentoo, Fedora, Arch Linux, Debian etc.

Puisque ces paquets sont portables, il existe un site expliquant comment packager des applications ainsi qu’un store d’applications empaquetées.

Microsoft Azure supporte Ubuntu Snappy depuis fin 2014, une version serveur d’Ubuntu utilisant les snaps, et Ubuntu Desktop les supporte depuis la version 16.04.

L’intérêt pour les développeurs

Tout le casse tête pour un développeur d’applications souhaitant prendre en charge l’univers Linux est de devoir s’intéresser à chaque distribution individuellement, empaqueter son logiciel en .deb, .rpm et continuer avec les nombreux autres formats, tout en s’impliquant dans un processus long et complexe de maintient de ses paquets dans les dépôts officiels des distributions qu’il veut toucher, et recommencer lors de chaque mise à jour desdites distributions, là où un .exe sous Windows peut fonctionner de XP à Windows 10 sans avoir eu à s’en soucier.

Les paquets snaps viennent de résoudre cette problématique.

L’intérêt pour les utilisateurs

En revanche, côté utilisateur, les .deb ont beaucoup d’avantages :

  • On peut les installer via un store applicatif (apt, la logithèque Ubuntu, le centre de logiciels Gnome, celui de KDE etc)
  • L’installation de paquets sur le système requiers les droits « root »
  • Tous les paquets sont vérifiés et signés, donc sûrs, leur présence dans un dépôt officiel garanti qu’ils soient libres et que ce soit bien la version officielle du développeur initial (et non trafiquée par Sourceforge)
  • Les mises à jours de tous les logiciels sont centralisées dans un seul outil, ce dont les utilisateurs de Windows rêvent depuis sa création
  • Les dépendances d’un logiciel sont partagées, rendant son téléchargement initial ultra léger (plus on a de logiciels installés plus on a de change d’avoir déjà toutes les bibliothèques les plus populaires). Autre avantage, la consommation en RAM est réduite à son minimum car une bibliothèque n’est chargée qu’une fois pour plusieurs logiciels (GTK est un bon exemple). Le système est donc rapide pour installer, lancer et mettre à jour ses logiciels.

Et quelques inconvénients :

  • Les versions des logiciels sont figées dans les dépôts, on a rarement la dernière version du développeur, seulement les mises à jour pour la version en cours
  • Ajouter des dépôts externe créé irrémédiablement de l’instabilité, en proposant parfois des mises à jour de dépendances
  • Installer un logiciel hors des dépôts n’est pas une facilité et le mettre à jour est plus compliqué

L’avantage des paquets snaps pour l’utilisateur est la possibilité d’avoir les dernières versions disponibles de chaque logiciel sans avoir à attendre la prochaine montée de version du système. Les paquets snaps pourraient convaincre des développeurs dont le logiciel fonctionne sous Linux de faire l’effort de l’empaqueter pour le distribuer et le maintenir. Certains logiciels comme l’interface Unity représentent actuellement un trop grand défi pour être empaquetés sur d’autres distributions. Enfin, les vieux logiciels abandonnés finissent souvent par ne plus avoir de paquets deb/rpm récents et ne peuvent plus être exécutés sur les distributions récentes à cause de leurs dépendances.

Les paquets snaps arrivent avec un inconvénient, en terme de poids et consommation en RAM. Pour savoir de quoi ils sont faits, lisez la suite !

Bonnes pratiques concernant l’envoi de newsletters

Ma séance de veille du jour concerne une conférence Alsacréations de Sébastien Lejeune en 2016.

  • Pas plus de 50 caractères dans le sujet. Un sujet court et précis est plus percutant, surtout sur des emailing qui ne sont pas sollicités par les internautes.
  • Souvent dans un client mail le bouton SPAM en haut et près du corps du mail, Sébastien recommande de placer le lien de désinscription tout en haut du mail car il vaut mieux qu’un internaute se désinscrive plutôt que de signaler notre serveur et adresse comme SPAM
  • Avoir un lien miroir de l’email est pratique si l’usager n’arrive pas à visualiser correctement l’email dans son client, car les clients lourds ont souvent un mauvais moteur de rendu
  • On peut mettre ces deux liens côte côte
  • On peut mettre juste après un résumé de l’email en 100 caractères si le mail est long, car les gens passent vite à autre chose
  • On peut mettre un footer avec encore le lien de désinscription + un lien pour gérer ses préférences s’il y a un abonnement à plusieurs newsletters + des liens vers les réseaux sociaux
  • Utiliser le moins d’images possible et le plus de CSS possible car les images chargent lentement ou sont bloquées
  • Le choix d’un lien vs un bouton n’a pas toujours l’impact qu’on imagine, les liens fonctionnent très bien dans les mailing
  • Utiliser des call to action type « Lire plus sur le blog », « Acheter maintenant », « Télécharger l’application », « Réserver maintenant », « Comparer encore d’autre » etc
  • Mettre le prénom de la personne personnalise l’email, c’est très efficace
  • Sur desktop il propose en 500 et 640px de large pour éviter les scroll latéraux
  • Sur mobile, entre 280 et 320px de large
  • HTML5/CSS3 on oublie, il propose XHTML 1.0, les breakpoints sont faits en prenant les propriétés CSS par browser (par exemple pour les iPhone et compagnie), les doctypes ne sont pas pris en compte par GMAIL Yahoo Hotmail.
  • mettre un meta viewport avec un initial-scale à 1.0 pour éviter que le mail soit zoomé par défaut par les clients mails
  • Outlook jusqu’à la version 2007 utilise le moteur de rendu de Microsoft Word
  • Tester, tester, tester. Il utilise deux services en ligne, litmus et Email on acid

Nokogiri : installer avec « Building native extensions » sous Mac OSX 10.12 Sierra

Si l’installation de la gem Nokogiri provoque une erreur telle que :

Vous pouvez essayer les solutions suivantes, en adaptant le numéro de version à celui voulu :
gem install nokogiri -v 1.6.8.1 -- --use-system-libraries
gem install nokogiri -v 1.6.8.1 -- --use-system-libraries=true --with-xml2-include=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/libxml2
brew uninstall libxml2 (fourni par Xcode) puis relancer gem install nokogiri -v 1.6.8.1 -- --use-system-libraries
brew reinstall xz --universal puis relancer gem install nokogiri -v 1.6.8.1 -- --use-system-libraries

Les Rails Engines, poupées russes d’applications Rails

Il n’y a pas si longtemps, dans une galaxie pas si lointaine, nous souhaitions factoriser du code au sein d’une Gem Ruby. Son but, traiter à notre façon les erreurs 402, 404 et 500 que Rails affiche par défaut aux visiteurs. Ces erreurs disposent de routes automatiques native (/402, /404 et /500) qui ne sont que des routes par défaut pointant vers des fichiers statiques présent dans le dossier public.

Notre Gem devait :
– intercepter les redirections qu’opère Rails en repassant dans le routeur d’URL lors d’une erreur ou page introuvable avec match « /404 », to: « erreurs#page_introuvable », via: :all
– redéfinir un template de vue un peu plus présentable pour le visiteur (charté selon le style de l’application)
– intercepter les exceptions de l’application principale
– nous envoyer un email avec le contenu de l’exception
– éventuellement appeler notre webservice d’enregistrement de logs (selon une variable d’environnement dans l’appli)

En bref, le code déporté dans la Gem était une quasi application Rails à part entière, faisant intervenir des routes, des actions dans un contrôleur, des fichiers de vue, des actions dans un mailer et ses vues associées.

Pour cela, nous avons utilisé un Rails Engine :

Le code généré peut être facilement déporté et intégré dans n’importe quelle application Rails habituelle. Nous l’avons packagée au sein d’une gem et installée sur notre serveur de gem interne sans rencontrer de difficulté.

Pour en savoir plus, je vous invite à lire ce superbe article de Brian Leonard.

Programmation asynchrone en Ruby 3 : les Guilds (Partie 5)

Nous avons fait un tour plutôt large des diverses solutions pour réaliser un programme asynchrone en Ruby. Je vous propose de terminer cette série d’articles par une ouverture sur ce que pourrait apporter la prochaine version majeure de Ruby.

C’est en tombant sur cet article d’Olivier Lacan que j’ai entendu parler de la révision du modèle concurrentiel de Ruby.

Comme évoqué dans la partie 2, l’interpréteur Ruby souffre d’une limitation dans sa gestion des threads : ces derniers ne peuvent pas être exécutés simultanément en parallèle mais le sont chacun à leur tour. Ce mécanisme a été introduit pour offrir l’API des mutex aux développeurs et ainsi permettre de synchroniser les threads. Cette limitation a un impact important sur la performance de nos applications multi-processus.

Koichi Sasada est un développeur core de CRuby, l’interpréteur Ruby « officiel ». Il a proposé un nouveau modèle mêlant Threads et Fibers.

Voici une traduction de l’article d’Olivier cité plus haut, avec mes ajouts personnels entre crochets :
« Les Guilds sont composées d’au moins un Thread, qui à son tour a au moins une Fiber. Les Threads de différentes Guilds peuvent s’exécuter en parallèle, tandis que les Threads dans la même guilde ne peuvent pas [ils le sont à tour de rôle]. Les objets d’une Guild ne peuvent ni lire ni écrire sur les objets d’une autre Guild. »

ruby_3_guilds_threads_and_fibers

« Les Threads appartenant à la même Guild ne peuvent pas s’exécuter en parallèle car il existe un GGL (Giant Guild Lock). Cependant, les Threads de différentes Guilds peuvent s’exécuter en parallèle.

Vous pouvez penser un programme Ruby 2.x comme ayant une Guild unique. »

ruby_3_guilds_concurrency

« Un objet d’une Guild ne sera pas capable de lire ou d’écrire sur un objet mutable d’une Guild différente. Empêcher la modification [d’objets] permet aux Guilds de fonctionner en parallèle sans courir le risque d’accéder et de modifier les mêmes objets. »

ruby_3_guilds_object_access_restrictions

En revanche il sera possible de réaliser des « deep copy » d’objets d’une Guild à l’autre.

ruby_3_guilds_channels_object_copy

Il existera une méthode .freeze pour rendre immuable (constant) tout objet mutable :

Je vous invite à lire cette synthèse de Maciej Mensfeld qui récapitule ce que sont les Guilds.

Programmation asynchrone en Ruby : présentation de la gem Celluloid (Partie 4)

Après concurrent-ruby, continuons notre tour des gems avec Celluloid.

La syntaxe de la gem est identique au module Async de concurrent-ruby :

Ceci dit contrairement à concurrent-ruby, la méthode await n’existe pas pour écrire du code synchrone bloquant thread-safe. La gem implémente également les Futures, mais pas les Promises ni toutes les autres fonctionnalités présentées dans la partie 3. Elle est donc bien moins intéressante et ne semble pas avoir, au vu de sa faible documentation, de fonctionnalité particulière que n’offrirait pas son alternative.

Il existe probablement d’autres gems à étudier, telle que EventMachine (plus complexe et lourde à mettre en place), ceci dit je pense que concurrent-ruby peut déjà répondre à un éventail très large de cas de figure. Passons sans attendre à notre 5ème et dernière partie sur l’avenir en Ruby 3.

Ruby on Rails, Passenger et MySQL : interrompre un thread sans détruire le ConnectionPool

Imaginons. Une application Rails dispose d’une action qui lance la génération d’un gigantesque CSV. Afin de ne pas attendre le retour de l’action, on place la génération du CSV dans un thread et on fait retourner un message à l’utilisateur type « Ne vous inquiétez pas on s’occupe de tout ». Et on part tranquillement pour une heure de génération, relax.

Un petit bout de JavaScript va appeler périodiquement une autre action tant que le fichier ne sera pas prêt. Il changera un bouton de couleur en y ajoutant un lien de téléchargement dès que ce sera fini. Mais subitement, l’utilisateur change d’avis, modifie quelques options sur l’interface et demande la génération d’un nouveau fichier.

Comment on tue ce thread sans tout péter ?

La génération du CSV devant recommencer, on souhaite éviter de gâcher des ressources serveur et l’écrasement de notre fichier de sortie.

Je suis un développeur bourrin : Thread.kill

Je vais ressortir mon schéma favoris qui illustre comment le module Apache Passenger se charge de load balancer les requêtes qu’il reçoit :
passenger-request_load_balancing
L’application Rails est démarrée plusieurs fois dans des processus séparés. De ce fait, en production, Thread.list peut ne pas lister le thread dans lequel notre premier CSV est en cours de génération : tout dépend dans quelle application tombe notre requête.

Mettons que notre développeur bourrin ait de la chance, tombe aléatoirement dans le bon processus et qu’il tranche net notre thread. La connexion à la base de données ouverte par l’application Rails dans le thread pendouille sans avoir été déconnectée proprement, elle sera définitivement inutilisable jusqu’à l’arrêt de ce processus Passenger.

L’ORM ActiveRecord est configuré par défaut pour disposer d’un pool de 5 connexions à la base de données. Lorsque les 5 connexions seront bloquées, tout accès à la base de données lèvera l’erreur suivante :

Je suis un développeur ignoble : je pousse le thread à se suicider

La parade consiste alors à faire lire régulièrement un booléen « dois_arreter » au thread. Dès que le booléen passe à true, la boucle dans le thread s’interrompt et le thread se laisse mourir. Il suffit de mettre à jour ce booléen pour interrompre proprement le thread, et MySQL est un bon endroit pour stocker cette variable commune à tous les threads.

Même problème en revanche concernant la connexion à MySQL. Elle n’est plus en cours d’utilisation par un thread mort, comme disait l’erreur précédente, mais elle n’est pour autant pas refermée, donc pas libérée pour retourner dans le ConnectionPool. Après 5 décès de threads, l’erreur suivante apparait :

On ajoute le bout de code suivant juste avant la fin du thread et le tour est joué :

Suite et fin

Bon, après, libre à vous d’identifier plus précisément les threads de l’utilisateur en joignant un identifiant au booléen. Libre aussi à vous de définir si le lancement d’un nouveau thread doit attendre la mort de tous ses prédécesseurs, par exemple, en ajoutant la suppression de la ligne de BDD avant la mort du thread et en attendant que toutes les lignes aient disparues pour lancer le nouveau.

Que faire si Apache redémarre et interrompt un thread qui n’aura pas le temps d’effacer son entrée en BDD ? Comment supprimer toutes les lignes d’états de thread au démarrage de l’appli, alors que Passenger démarre et arrête des processus à tout moment ? On peut éventuellement stocker le timestamp de démarrage du serveur.

Sous Linux :

Sous Mac :

Et voilà, jusque là nous on s’en est sorti, si vous rencontrez d’autres problèmes n’hésitez pas à les partager en commentaire 🙂