Revue de presse Inno #6

Design

Atomic Design

Par Patrick Bracquart 

Depuis l’avènement du web, on parle de conception de pages web. Ce terme, hérité du domaine imprimé, démontre bien la considération du contenu web depuis les années 90 : une architecture composée de pages consultables, comme un livre. 
Or, depuis maintenant quelques années, la multitude de plateformes disponibles pour consulter du contenu web ne cesse d’augmenter et de se complexifier. De l’ordinateur au mobile en passant par la télévision ou encore les montres intelligentes, il est devenu clair que le concept de design et de structure de pages web est obsolète. 

 

L’atomic design, terme inventé par Brad Frost, est une nouvelle méthodologie de design. Au lieu de penser son contenu comme une page, chaque élément de design est conçu en partant du plus petit élément (comme un call to action) vers un ensemble plus grand. On part de l’atome pour créer une molécule et elles s’assemble pour créer un organisme web cohérent et modulable. 

Chaque atome étant placé individuellement dans une librairie, l’atomic design est un gain de temps et de cohérence en plus d’une mise à jour simplifiée.

Pour en savoir plus :

Développement web

Makefile ou comment éviter de réinventer la roue

Par Samuel Sirois

Après m’être absenté pendant quelques années de la partie frontale des applications web, j’ai été récemment appelé à replonger dans ce monde à travers deux projets auxquels je collabore. Une belle occasion de revisiter mes idées préconçues et mes vieilles habitudes de travail puisqu’une base de code déjà existante et utilisant les derniers outils à la mode est présente sur mon poste après le git clone initial.

Ouf ! Ça bouge vite sur la première ligne ! De nouvelles versions d’ECMAScript supportées par les clients Web modernes, une plénitude de pseudo-langages basés sur JavaScript, la multiplication des pré-processeurs CSS… Que dire de tout ces moteurs de production maintenant disponibles spécifiquement développés par et pour les développeuses et développeurs JavaScript ?

Avec toutes ces merveilles, ces derniers (les moteurs de productions) deviennent essentiels pour éviter que l’effort nécessaire pour agréger, minifier, lier, compiler ?!, tous ces fichiers ne viennent pas annuler les gains en efficacité d’avoir dorénavant les outils nécessaires à la création d’applications web modernes.

Je me questionne tout de même à savoir s’il n’y a pas eu un petit manque de communication entre celles et ceux qui ont plus récemment eu ce besoin dans leurs projets (les développeuses et développeurs de la partie frontale) et celles et ceux qui ont déjà eu ces mêmes besoins et qui ont trouvé une solution (pas la seule) à ce problème depuis les années soixante-dix !

Je n’ai jamais ressenti le besoin d’utiliser ces outils modernes, connaissant déjà Make et ayant déjà été confronté à de nouvelles solutions à la mode à la fin du siècle dernier, j’ai finalement fait marche arrière pour revenir à ce qui fonctionnait déjà. Évidemment, je me fais un devoir de rédiger manuellement les Makefiles des projets auxquels je participe et je n’hésite pas à entretenir cet outil.

Réinventer la roue, pour refaire les mêmes erreurs ou pour vraiment améliorer la situation ? Quelques liens intéressants pour vous faire votre propre opinion :

Contribution

Des contributions au Inno Hackest

Devant le succès des après-midis de contributions, l’équipe a décidé de renforcer l’activité et de bonifier sa formule. Dorénavant, ces après-midis auront lieu aux deux semaines sous le nom de « Hackfest ».

 

Nos premiers Hackfest

 

 

Par petits groupes de personnes, jamais tout seul, nos SFLiens ont l’opportunité de se former sur de nouvelles technologies, de contribuer à des projets qui leur tiennent à cœur ou à travailler sur de nouveaux « side project ».
On y retrouve pêle-mêle des initiations à la réalité virtuelle comme la réalisation d’une simulation de chute de Domino avec le moteur physique Unity et l’Oculus Rift, un atelier sur la technologie Blockchain et l’étude du cas concret de l’annuaire des usernames de Ring, la réalisation de POC et de prototypes par exemple sur des bases de données orientées document.

Review Upgrade

Par Maxime Turcotte

La page du rapport d’analyse de migration de Drupal 8, sur laquelle sont répertoriés les modules qui seront migrés et ceux qui ne le seront pas, avait grand besoin d’une refonte afin d’améliorer l’expérience utilisateur. Durant notre après-midi hackfest, j’ai écrit une première version d’un correctif qui réutilise certains éléments de design du tableau de bord d’administration. Ainsi, en ajoutant simplement quelques icônes, il est beaucoup plus facile de voir d’un seul coup d’œil ce qui requiert notre attention.

Drupal 8 : de Barcelone à Dublin, une année à fond de train

drupal-8-logo-rgb-72

Lors du DrupalCon de Barcelone en septembre 2015, la communauté Drupal était très déçue de pas avoir réussi à finaliser Drupal 8, pourtant en développement depuis bientôt quatre ans.
Au moment du DrupalCon de Dublin en septembre 2016, Drupal 8 était non seulement disponible depuis plusieurs mois, mais deux nouvelles versions mineures (8.1.0 et 8.2.0) avaient déjà vu le jour.
Cette version est sans aucun doute la plus importante de l’histoire du projet, tant par les nouveautés apportées au logiciel que par les changements appliqués au processus de développement.
De ce fait, on peut se poser la question suivante : comment la communauté Drupal est-elle passée d’un délai de quatre ans entre les versions 7 et 8, à des itérations courtes et des nouveautés fréquentes ?

La mise en place des versions planifiées
Le graphique ci-dessous montre à quel point le temps entre chaque version de Drupal a augmenté de façon considérable.
crop_drupal

Ce délai entre Drupal 7 et 8 a aussi révélé un certain nombre de problèmes.
Puisque cette version était en mode de développement durant quatre ans, les contributeurs avaient l’impression de travailler dans une sorte de bulle, ajoutant de nouvelles fonctionnalités sans jamais savoir si elles répondaient à des besoins réels chez l’utilisateur hypothétique.
La mise en place de versions planifiées est venue remédier à ce dysfonctionnement en prévoyant une nouvelle version tous les six mois.

Cela permet aux développeurs d’ajouter des nouveautés beaucoup plus souvent, de recevoir des commentaires d’utilisateurs réels et d’être ainsi mieux à même de suivre le marché.
La sortie d’une nouvelle version marque aussi la fin du support de la précédente pour inciter les utilisateurs à tenir leur site à jour et pour éviter d’avoir à supporter plusieurs versions.
La gestion sémantique de version
Le passage d’un système de version à deux chiffres (7.x) à un système de version à trois chiffres (8.0.x), appelé gestion sémantique de version, a favorisé la mise en place des versions planifiées et permis de limiter les changements de versions majeures.
Le premier chiffre, la version majeure, n’augmente que lorsque des changements rétro-incompatibles sont nécessaires. Le troisième, la version de correctif, est augmenté chaque fois qu’une mise à jour de sécurité ou qu’un correctif de bogue est appliqué. Finalement, la version mineure représentée par le chiffre du centre, est augmentée toutes les fois que de nouvelles fonctionnalités rétro-compatibles sont ajoutées.
Dans le cas de Drupal 8, c’est cette version mineure qui est incrémentée tous les six mois.

Les modules expérimentaux
En plus des sorties planifiées et des versions sémantiques, Drupal 8 introduit aussi le concept de module expérimental.
Un module expérimental est un module qui aspire à être inclus dans le cœur de Drupal, mais qui n’a pas encore atteint une stabilité acceptable.
Comparativement à un module communautaire, un module expérimental reçoit davantage de visibilité de la part des utilisateurs et des core commiters puisqu’il est inclus dans le cœur de Drupal.
Toutes les modifications apportées à son code sont revues par une personne responsable du projet, garantissant ainsi qu’il ne contient aucune faille de sécurité connue ni aucun risque de perte de données.
Notons aussi que leur utilisation dans un environnement de production est déconseillé et que leur avenir dans le cœur de Drupal n’est pas garanti, car s’ils ne se stabilisent pas dans un délai d’un an, ils seront retirés.

Les nouveautés dans Drupal 8.2.

1) De nouveaux modules expérimentaux
– «Content moderation» qui introduit les états de modération du contenu.
– «DateTime range» qui permet d’ajouter des dates de fin.
– «Place block» qui permet de placer des blocs directement sur une page sans avoir à passer par les pages d’administration, facilitant ainsi la visualisation du rendu.
– «Settings tray» qui introduit un panneau latéral pour éditer la configuration de certaines parties des pages comme, par exemple, les menus.

2) Des améliorations à des fonctionnalités déjà présentes
– Des URL relatives converties en URL absolues lorsque présentées dans un flux RSS.
– Des révisions activées par défaut pour les nouveaux types de contenus.
– Un progrès considérable du côté du support REST, qui permet un plus grand contrôle sur un site Drupal depuis une application externe.

Que peut-on espérer pour Drupal 9 ?

Avec ce nouveau modèle de développement, certains se demandent si Drupal 9 sera vraiment nécessaire dans un futur proche.
Il est vrai que les nouveautés de Drupal 8 vues ici nous permettent d’ajouter des fonctionnalités beaucoup plus facilement et rapidement qu’auparavant, alors pourquoi ne pas continuer ainsi pendant plusieurs années ?
Nous sommes portés à croire que ce sera probablement le cas. Tant qu’il n’y aura pas un excès de couches de rétro-compatibilité qui gagneraient à être retirées ou qu’il n’y a pas de besoin urgent de faire des changements rétro-incompatibles, Drupal 8 continuera d’évoluer au rythme de ses versions mineures.
De plus, étant donné que la sortie d’une nouvelle version mineure implique la fin du support de la précédente, nous pouvons espérer que lorsque Drupal 9 sortira, la transition se fera beaucoup plus efficacement que celle entre Drupal 7 et 8. Et ce pour deux raisons.
Premièrement, puisque le plus important changement sera probablement le retrait des couches de rétro-compatibilité, et que leur dépréciation aura été annoncée progressivement au fil des versions mineures, les modules communautaires auront eu amplement le temps de s’adapter.
Deuxièmement, si des changements rétro-incompatibles sont ajoutés tels que des modifications aux API ou aux structures de données, ils seront certainement moins colossaux que ceux que nous avons vus entre les versions 7 et 8, ce qui présage une mise à jour beaucoup plus aisée.

Sources
Dries Buytaert, Driesnote, DrupalCon Dublin 2016
Gábor Hojtsy, Checking on Drupal 8’s rapid innovation promises, DrupalCon Dublin 2016