#Barcamp : Les Assets Ruby on Rails

Asset Pipeline

L’asset pipeline est un outil qui concatène et minifie (compresse) les ressources CSS et JavaScript. Il nous permet aussi d’écrire nos assets avec d’autres langages ou pré-processeurs comme ERB, Sass ou CoffeeScript. En Ruby on Rails, Il est gérer par la gem sprockets-rails, dont le code a été extrait du cœur du framework dans la version 4.

Les assets sont placés dans le répertoire /app/assets. En production, Rails les précompile et les place dans le répertoire /public/assets.

Inclusion des assets

Lorsqu’on génère un contrôleur (ou un scaffold), rails crée automatiquement des fichiers CSS et JS (ou SCSS et Coffee, si les gems correspondantes sont installées). Par exemple, si on crée le contrôleur elements_controller.rb, les fichiers app/assets/stylesheets/elements.scss et app/assets/javascripts/elements.js vont être créés. Ces fichiers sont inclus dans l’application si l’instruction require tree . est présente dans le fichier application.css.

Mais il est également possible d’inclure seulement les fichiers d’assets spécifiques au contrôleur courant en utilisant les lignes suivantes dans le layout :

Organisation des assets

Les répertoires images, javascripts et stylesheets présents dans app/assets, lib/assets et vendor/assets sont gérés par l’assets pipeline. Il est possible d’ajouter des chemins au pipeline dans le fichier config/application.rb. Par exemple :

Manifest

Les fichiers app/assets/stylesheets/application.css et app/assets/javascript/application.js sont des fichiers manifest qui déterminent quelles assets inclure et servir.

Un fichier manifest ressemble à ceci :

Ici, les fichiers jquery.js et jquery_ujs présents dans un des chemins connus par l’asset pipeline sont inclus. La directive require_tree inclus tous les fichiers présents dans le répertoire courant, alors que require_directory inclus les fichiers présents dans le répertoire spécifié.

Pour exclure un fichier présent dans le répertoire courant après un require_tree, il faut utiliser la directive stub.

À noter que les assets sont inclus dans l’ordre spécifié par le manifest. Par contre, il n’y a pas d’ordre spécifique d’inclusion des assets avec le require_tree ou le require_directory. Il faut donc inclure un fichier avant le require_tree si on veut qu’il soit inclus le premier (il ne sera alors pas inclus une seconde fois).

On peut utiliser autant de fichiers manifest que le souhaite. Pour cela, il faut les ajouter à la précompilation dans le fichier /config/initializers/assets.rb :

Helpers d’assets

Il existe plusieurs helpers qui nous permettent d’inclure les assets :

Sources :

Lectures complémentaires :

 

#Barcamp : Les unités CSS

Taille de police

Par défaut, la taille de la police sous Firefox est fixée à 16px. Mais l’internaute peut modifier cette taille (et la fixer à 32px par exemple). Pareil pour la taille minimale de la police : elle n’est pas définie par défaut, mais peut l’être par l’utilisateur.

Pour améliorer l’accessibilité d’un site, il faut donc laisser la possibilité à l’internaute de redimensionner le texte. Pour cela, il faut utiliser les unités relatives (em ou rem) et non les pixels. Cela est valable autant pour la propriété font-size que pour line-height.

Sources : alsacréations

em.

L’ em est une unité relative qui se base sur l’élément parent pour déterminer sa taille. A savoir que la balise HTML se base sur la taille de police par défaut du navigateur. Attention à ne pas tomber dans le piège de la cascade qui vas augmenter rapidement la taille de police.

rem

le rem pour root em se comporte exactement comme le em à la différence que le rem se base sur l’élément racine, donc soit la balise HTML soit la police par défaut du navigateur.

vh et vw.

Il est pratique de vouloir que le texte soit d’une taille adapté en fonction de la taille de l’écran. Si vous avez une tablette, le titre de l’application va être en plus gros que le titre de la même application mais sur mobile. Et  les unités VW et WH vont permettre de réaliser cela facilement.

D’abord il faut savoir que la première lettre V de ces unités signifie viewport (donc ce sont des unités relative à la taille du viewport que vous avez définie -ou non-), ensuite, w pour width et h pour height.

Donc :

  • vw : « Viewport Width », correspond à l’unité relative à la largeur de votre écran
  • vh : « Viewport Height », correspond à l’unité relative à la hauteur de votre écran

Prenons un exemple en supposant que vous avez un écran (enfin un viewport…) de 1000px de hauteur :

La taille du texte à l’intérieur de votre div sera donc de (1000 * 20/100) = 200px.

Et si vous passez à un écran de 800px de hauteur, vous aurez alors une taille de texte de 160px.

Source : graphikArt

vmin et vmax

vmin et vmax pour viewport min et max : il correspondent à l’unité à la plus petite ou grande des deux dimensions (largeur ou hauteur selon l’orientation).

Du responsive en em ?

Pour aller plus loin il est aussi possible de définir les medias queries avec des unités relative. Ainsi si l’utilisateur utilise une taille de police importante l’interface passe en mode « tablette » ou « mobile ».  ainsi la police seras toujours adaptée en fonction du device.

Sources :

#Barcamp : Aller plus loin avec SCSS

Nous utilisons quotidiennement deux fonctionnalités de SASS dans nos projets : les variables et l’imbrication. Mais cela n’est qu’une infime partie des fonctionnalités proposées par SASS.

Les variables

L’imbrication

Il est conseillé de ne pas trop imbriquer les selecteurs (pas plus de 3 niveaux d’imbrication) : « Be aware that overly nested rules will result in over-qualified CSS that could prove hard to maintain and is generally considered bad practice. »

Les mixins

Un mixin permet de regrouper des propriétés CSS réutilisables. On peut passer des paramètres à un mixin pour le rendre plus modulaire.

Les fonctions

Une fonction se distingue d’un mixin car elle ne définit pas une série de propriétés mais retourne une valeur en fonction de paramètres passés en arguments.

Sass définit une série de fonctions natives qu’on peut utiliser directement sans avoir à les redéfinir (http://sass-lang.com/documentation/Sass/Script/Functions.html).

Les partials

On peut structurer les fichiers SCSS en les scindant en plusieurs partials. Ces différents fichiers sont compilés dans un même fichier lorsqu’ils sont inclus dans ce fichier, et ne nécessite pas d’être tous inclus dans le <head> de la page.  La convention de  nommage est la suivante : _nom_du_partial.scss.

L’héritage

Le mot-clé extend permet à un sélecteur d’hériter des propriétés d’un autre sélecteur.

À noter que cet héritage est multiple.

Les opérateurs

Grâce à Sass, on peut utiliser les opérateurs mathématiques de base (pour calculer les hauteurs, largeurs, marges, …).

Un exemple d’utilisation des opérateurs est la création de grilles responsives.

Le sélecteur « & »

Le sélecteur & fait référence au sélecteur parent. Il est donc forcément imbriqué.

Les conditions

Sass introduit les conditions.

Les boucles

Sass introduit également les boucles while, for et each.

Liens supplémentaires :

#Barcamp : Journée 1, arrivée et lancement du Barcamp 2016 !

En ce jour du mardi 22 Mars 2016 à 9H15, nous arrivons sans heurt au gîte hormis pour Matthieu, Jérémie et Julien qui avec une voiture plus que chargée (à cause des courses) se sont perdus, enfin ont pris un raccourci qui n’en était pas un 😉

Le gîte est superbe, 7 chambres distinctes, 4 salles de bain et une grande table, juste ce qu’il faut pour 7 voire 8 personnes. Petit lancé de dé pour attribuer les chambres et chacun pose ses affaires dans son espace nuit.

10H30 : Tout le monde est prêt, on lance le premier sujet et pas des moindres « la définition et la mise en commun de bonnes pratiques », sujet basé sur notre expérience individuelle et mise en commun.

Il nous aura fallu pas moins de 7 heures acharnées de discussion sur des sujets aussi variés que le nom de nos variables jusqu’à l’indentation du code en passant par les endroits et la façon de factoriser du code.

Ce sera évidemment le seul sujet abordé et on en a sûrement oublié des choses, mais forcé de constater que cela était nécessaire.

Et oui, on ne fonctionne pas en équipe à 7 comme on fonctionnait à 4, les choses changent, évoluent et de nouvelles contraintes apparaissent, de nouvelles idées aussi, il faut savoir prendre le temps qu’il faut pour mettre à plat tout ça et garder une cohérence dans l’activité du service.

La journée se termine donc à 19H, s’en suit une préparation du repas en commun ainsi qu’un tout petit moment de détente individuelle car ce soir c’est poker… Il est lancé à 21H et se soldera par une victoire de Jérémie, partie tout aussi acharnée avec chacun son moment de grâce.

Le barcamp continue demain….

Évolution majeure du protocole HTTP en HTTP/2

Si vous n’êtes pas encore au courant, mi-février, l’IESG (Internet Engineering Steering Groupa officiellement annoncé que le développement du projet HTTP/2 était finalisé.

HTTP/2, qu’est-ce que c’est ?

Il s’agit en fait de la 2ème version majeure du célèbre protocole HTTP. Celui qui permet de faire communiquer le navigateur client avec un serveur et de permettre ainsi l’affichage de page web.

Pourquoi une nouvelle version ?

Il faut savoir que depuis la première version du protocole HTTP sortie en 1996, seule une montée de version en HTTP1.1 a été réalisée, et c’est cette version qu’on utilise toujours depuis 1999.

L’amélioration des performances et la rapidité de temps de chargement devenant une priorité pour les développeurs, le protocole a dû subir un petit lifting pour s’adapter au Web d’aujourd’hui.

En bref… qu’est-ce qui va principalement changer ?

Le multiplexage

L’une des principales améliorations de cette nouvelle version est sans doute le multiplexage.

Comme on peut le voir sur le schéma ci-dessous, avec HTTP1

1 requête = 1 réponse = 1 connexion TCP

http2 multiplexageLe traitement des requêtes est séquentiel. Le client est obligé d’attendre le retour de la requête pour pouvoir en envoyer une nouvelle.

Avec HTTP1.1, une petite amélioration appelée le pipelining a vu le jour. Cette amélioration a permis de pouvoir lancer plus d’une requête en même temps dans une même connexion TCP.

L’idée était excellente si elle ne possédait pas un gros talon d’Achille.

Le serveur HTTP a l’obligation de renvoyer les réponses dans l’ordre d’envoi des requêtes. Imaginez donc si la première des requêtes demande un temps de traitement assez long. Elle bloque les autres et peut conduire au fameux « Head-of-line blocking ».

http1_1Avec HTTP2 et son multiplexage, plusieurs requêtes pourront être lancées en même temps via une unique connexion TCP comme dans le pipelining, mais cette fois, les réponses pourront se faire dans un ordre quelconque et une requête lente ne bloquera plus les autres. Le temps de chargement sera ainsi amélioré.

http2

Un protocole binaire

Dans sa nouvelle version, le protocole HTTP devient binaire. Hormis, d’avoir des entêtes moins volumineux, le principal intérêt de cette modification d’encodage vient sûrement du fait que le format binaire est plus simple, ce qui limitera les erreurs.

La compression des entêtes

Chacune des ressources servies par le serveur possède une entête. Hors certaines ressources comme les images par exemple, possèdent des entêtes quasi identiques.

Avec HTTP2, ces entêtes vont être regroupées et compressées. Les entêtes vont ainsi être servies en une fois et éviter plusieurs aller-retour serveur.

Le Push Server

Une autre amélioration intéressante dans cette évolution du protocole, est sans doute la notion de Push Server.

Une page HTML contient généralement du texte mais aussi des inclusions à des feuilles de style, des fichiers JS ou des liens vers des images.

Avec la version HTTP1.1, le client demande au serveur de lui servir le fichier index.html.

Le serveur lui renvoie le fichier.

Le navigateur l’analyse et se rend compte qu’il a besoin d’un fichier CSS, il renvoie alors une requête au serveur pour lui demander de lui fournir ce fichier. Le serveur lui renvoie. Et ainsi de suite avec les autres fichiers que le navigateur aura besoin.

sans push server

 

Avec le système de Push Server, le navigateur va demander au serveur de lui fournir le fichier index.html.

Le serveur analyse la requête et renvoie au navigateur le fichier demandé. Mais cette fois, le serveur ne va plus attendre que le navigateur lui indique qu’il a besoin des fichiers supplémentaires, il va les pousser vers le navigateur avant, en utilisant la même connexion TCP.

Au moment où le navigateur aura besoin de ces fichiers, il n’aura plus à interroger le serveur. Cela permettra donc de faire gagner du temps de chargement.

Push server HTTP2

 

Au vu des premiers tests, HTTP2 permettra de faire gagner un temps de chargement non négligeable et ainsi d’améliorer l’expérience utilisateur.

Implémentation dans les navigateurs

En ce qui concerne l’implémentation de ce nouveau protocole par les différents navigateurs, il est intéressant de savoir qu’il est déjà géré dans :

  • Chrome depuis la version 40
  • Firefox depuis la version 36

Pour IE, il sera normalement supporté à la sortie de Windows 10.

Capybara et les tests d’acceptation

Capybara est un framework de test d’acceptation pour les applications web. Il se présente sous la forme d’une gem. C’est notamment l’un des outils qu’utilisent les développeurs de MH-Communication pour mettre en place le Golden Master Testing. Grâce à cette gem, il est possible de simuler l’interaction d’un utilisateur réel avec l’application.

Capybara fonctionne avec différents frameworks de test pour Ruby on Rails : Test::Unit, RSpec, Cucumber, MiniTest::Spec, … Personnellement, Je l’ai essayé avec Test::Unit. Par défaut, Capybara utilise le driver rack-test, mais il est conseillé d’utiliser Selenium qui supporte le JavaScript.

Une fois installé, Capybara permet de naviguer sur l’application de façon automatique, et ainsi d’effectuer des tests sur les pages affichées.

Quelques méthodes utiles :

L’ensemble des méthodes utilisables avec Capybara est présenté sur le github de Capybara : Github

Definition of done, comment ?

Le but de cette veille était de voir l’intérêt de cette definition of done (définition de terminé ou fait en français) et comment la mettre en place au sein du service si cela peut être intéressant.

Déjà d’où vient cette définition ? Sur ce point je me suis souvent trompé en pensant qu’elle venait du système Kanban. Et bien non elle provient de Scrum. Mais Kanban n’est pas en reste car il possède une notion similaire qui est la ou les règles de passage d’une colonne à l’autre. Scrum nous indique que la definition of done est la liste des critères que doit remplir un incrément pour être considéré comme terminé. Scrum indique aussi que si un des critères n’est pas rempli l’incrément n’est pas terminé donc pas compté dans la vélocité (nous on ne la calcule pas vraiment donc pas de souci). Cette définition doit être composée de différents types de critères : pérennité du logiciel, support de mise en production (doc si besoin, commit de git, merge si nécessaire, …), requis du monde des affaires (prévenir le PO, les utilisateurs, tracer les changements, …). Ces différents aspects permettent de couvrir les différents points de vues des acteurs de l’incrément.

Quelques erreurs à éviter selon Scrum :

  • Liste de critères trop importante -> contre productif
  • Liste implicite peu d’intérêt plutôt mettre par écrit les choses même triviales car il arrive à tout le monde d’oublier.
  • Éviter les incréments en suspend en se disant je reviendrais dessus plus tard.
  • Il faut que dans tous les cas on puisse checker la totalité des critères.

Pour notre part on ne va pas choisir entre l’un et l’autre nous allons prendre les deux. D’un côté comment déterminer qu’une tâche est terminée et de l’autre comment faire avancer ces tâches dans chacune des colonnes de notre Kanban. Voyons maintenant comment déterminer ces règles qu’il faut écrire, afficher et partager entre tous les membres de l’équipe, l’objectif est d’avoir une façon de travailler proche et de limiter les erreurs sur des choses que l’on ne fait pas régulièrement.

De mon point de vue, il faut partir du contexte dans lequel vous êtes, prendre toutes les bonnes pratiques de chacun en discuter avec tous les membres et se mettre d’accord sur les points qui peuvent poser problème.

Par exemple, je fais une branche, j’écris au moins un test qui échoue, j’écris le code de l’application, je lance tous les tests, ils passent tous puis je merge ma branche, je push mon code, je fais un test en prod et je préviens le PO.

Voilà, il est important de prendre conscience que ces règles ne peuvent être universelles, elles peuvent être proches mais pas universelles, chacun fonctionne à sa manière et le but n’est pas de standardiser cela mais bien d’améliorer cette manière de fonctionner.

Rails et le temps réél vs Nodejs

Ah, le temps réel, saint Graal du développeur, oui mais pas si simple !

Du coup on a tenté le temps réel en Rails. Apparemment une gem, Faye, existe en Ruby donc tout semblait bien partie quand après de multiples tentatives nous nous sommes aperçus qu’il fallait pour cela 2 serveurs web, le serveur habituel de Rails (et encore que, il fallait utiliser thin en local et passenger en prod) et un second serveur web pour le temps réel. Déjà là s’est posé à nous la question de la maintenabilité de ce joyeux bazar.

Bon, passons, mais même avec ces 2 serveurs la mise en place n’est pas aisée, la documentation pour faire du Rails en temps réel n’est pas très fournie. On a cherché mais au bout de 2 heures peu fructueuses nous nous sommes dit que quitte à avoir une maintenance un peu plus lourde pourquoi ne pas partir sur du Node js si besoin, peut-être plus adapté au temps réel avec la fameuse librairie socket.io.

Ces 2 compères sont très compatibles et son souvent utilisés ensemble dans les tutoriels sur nodejs, avec une documentation assez récente et fournie.

Nous verrons bien lorsque le besoin de temps réel se fera ressentir si un proof of concept nodejs – socket.io fera l’affaire.

Affaire à suivre et à creuser.

Retour et débrief du barcamp 2015

L’heure du barcamp 2015 étant sonné, il est temps de débriefer et de faire une rétrospective (et oui contexte agile oblige 😉).

Le débrief a duré environ 2 heures, quand on donne la parole aux personnes ils la prennent et cela fait plaisir.

Plusieurs axes de retours :

L’espace de travail, des locaux : Le retour est sans appel, il nous faut à la fois un open space pour la synergie des idées à l’instant T et des espaces d’isolement pour les tâches qui demandent une concentration maximale.

Le lieux géographique : A l’identique, le retour ne donne pas place aux doutes, le barcamp doit avoir lieu à l’extérieur de la société, la proximité du quotidien à notamment pesé sur la gestion des petits tracas non urgent mais que l’on n’aime pas laisser trainer.

Renforcement de la cohésion d’équipe : Cet aspect a été complétement laissé de côté dû au fait que les personnes rentrent chez elles tous les soirs (lieux géographiques) et ne mangent pas ensemble ni n’ont d’autres activités que celle du travail. Un exemple concret la partie de poker avec des pizzas (achetés en minibus ?) le soir après 22H a manqué à chacun des participants. Ce point marque définitivement le lieux géographique de cette année comme à ne pas reproduire.

La durée : Ce point a soulevé plus d’échanges, 4 jours oui mais, la majorité indique quand même que cela est plutôt une bonne durée. La séparation est elle aussi au coeur des débats mais un système de 2*2 jours avec un week-end entre deux serait la solution préconisée. A voir les possibilités qui s’offriront à nous les prochaines fois.

Le format : deux points sortent du lot, horaires peu flexibles dommage et pas de time box sur les présentations qui du coup s’envolent un peu parfois.

Déconnexion du quotidien : Sur ce point des choses sont à améliorer ou au moins revenir à ce que l’on a pu faire en 2013, à savoir être moins à la disposition des collègues pour éviter les appels pas utiles qui génèrent toujours une pensée en plus et une déconcentration. Il est clair que ce genre d’évènement ne raisonne que si l’on ne fait que ça. Mais nous ne pouvons pas omettre que les projets ne permettent pas de faire ce que l’on veut, peut-être faut-il mieux prévoir le moment du barcamp. Un petit manque de communication aussi sur cette activité et son aspect trop peu officiel auprès de nos collègues. Encore une fois sur cet aspect l’environnement géographique prend toute son importance.

Matériel : Point positif pour les ordinateurs portables, un petit bémol sur les serveurs qui mériteraient peut être d’être préparés en amont du barcamp afin de faire des tests de manière plus rapide lors du barcamp.

Contenu : Le contenu convient car les participants les ont déterminé eux-mêmes. Petit bémol sur le manque de temps pour pousser les sujets les plus « gros » ou « intéressants ».

Ecrire les articles : Oui mais quand ? Cela pose souci à tous les participants, pendant le barcamp cela perd du temps réel de veille hors du barcamp nous n’avons plus le temps.

Préparation du barcamp : Un serveur de test, la définition du contexte et des problématiques actuelles et le partage plus tôt des sujets aurait permis une meilleure organisation du barcamp.

D’autres retours en vrac : le barcamp est apprécié par l’équipe, il permet d’approfondir les nouveautés. Mais il est sporadique donc trop chargé (trop de choses à voir), un étalement serait peut-être intéressant avec une veille de 2H par semaine avec présentation si nécessaire le vendredi après midi. Nous allons essayer cette formule et voir si cela est jouable. Il a manqué un peu de JS dans ce barcamp, pas assez de binomage sur les sujets. Un manque de mise en pratique direct même si certains sujets ont été mis en pratique, cela est loin d’être le cas standard.

Voilà pour les retours, nous essaierons d’améliorer les choses la prochaine fois.

Liste de bonnes pratiques Rails 4

La mise à jour vers Rails 4 a apporté un certain nombre de nouveautés pas toujours connues. On rencontre parfois des évolutions qui n’entrainent pas de code déprécié, comme par exemple le renommage de before_filter en before_action, l’usage des verbes HTTP PUT et PATCH selon le contexte d’une mise à jour complète ou partielle d’un objet…

Helpers pour formulaires en HTML5

Pour un champ de type week :

week_field

Pour un champ de type month :

month_field

Pour un champ de type time :

time_field

Pour un champ de type date :

date_field

Pour un champ de type datetime :

datetime_field

Pour un champ de type color (string hex) :

color_field

Active Record

Le plus gros des nouveautés est apparu dans Active Record (l’ORM de Rails), qui ajoute ou améliore de nombreuses nouvelles méthodes :

.any? / .many? : au moins un résultat ? / plusieurs résultats ? Remplace .length > 1 (doc)
.first_or_create / .find_or_create_by : si aucune entrée n’existe pour le champ recherché, une nouvelle est créée (doc)
.first_or_initialize / .find_or_initialize_by : idem mais instancie sans créer en BDD (doc)
.minimum(‘champ’) / .maximum(‘champ’) : retourne la valeur (et non l’entrée) la plus petite/grande de la colonne (doc)
.none : retourne un objet Active Record vide pour faire de la consistance (par exemple dans le retour d’une condition)
.pluck(:champ1, :champ2) : créé un tableau de tableaux de la forme [[],[]]
.reverse_order : retourne le tri par défaut inversé, cumulable avec .order (doc)
.select(‘champ’) : équivaut à .pluck(:champ) exécuté côté SQL (doc)
select(‘champ’).distinct : équivaut à pluck(:champ).uniq exécuté côté SQL
.take : différent de .first car il retourne le premier élément venu, sans effectuer de tri préalable (doc)
.to_sql : retourne en texte la requête SQL qui a été exécutée (debug)
.update_attributes(post_params) / .update_columns(post_params) : met à jour les attributs de l’objet / met à jour l’objet en base sans passer les validations
.where.not(champ: valeur) : retourne tout « sauf »

Pour tout champ d’un objet, Active Record ajoute une méthode .find_by_champ

D’autres liens à explorer :
The 10 Most Underused ActiveRecord::Relation Methods
What’s new in Rails 4.1