Planète

Par hellosct1

Magazine Programmez Spécial Drupal

Le magazine 'Programmez', de l'été (juillet/août) 2014, numéro 176 a publié un supplément sous la forme d'un cahier spécial sur le CMS Drupa.l

programmez176.jpg

Le sommaire couvre de nombreux sujets, sous différents regards. Ainsi, vous trouverez de nombreux articles utiles comme :

  • Silicon Valley
  • Les Actus
  • Développeur du mois
  • Dossier sur l'inforamtique quantique
  • Coding For Fun
  • dossier sur les mobiles
  • etc.

Pour ma part, j'ai signé l'article suivant :

Bien démarrer avec Drupal

Commencer avec un nouveau CMS n'est jamais évident. Cependant la version 7 de Drupal a été améliorée pour mieux appréhender les projets et répondre aux attentes du web dynamique. Avec l'approche de la version 8, il est impératif de ne plus commencer de nouveaux projets en Drupal 6, même si celui-ci est disponible. il est temps de passer à Drupal 7

Consulter le magazine Programmez 176 en ligne

Par Artusamak
Julien Dubois

CMI : ... à la pratique

CMI : ... à la pratique

Nous avons précédemment vu la théorie à propos de CMI. C’est maintenant le moment de voir comment s’en servir dans des conditions réelles.

Afin de faire nos tests, je vous propose de monter deux Drupal 8 en parallèle. Appelons les Drupal-Prod et Drupal-Dev. Pour se faire, il suffit d’installer un Drupal 8 d’un côté, de prendre sa base de données et de l’injecter dans un second site.

Pour le moment, allons sur l’instance dite “dev” et faisons un petit changement rapide. Par exemple, allons changer le slogan du site.

Allez maintenant dans Configuration > Configuration Management > Onglet Full import/export > Export et cliquez sur le bouton export. Vous allez obtenir un fichier config.tar.gz

Gardez bien ce fichier au chaud, et allez faire un tour sur le 2ème site.

Sur la page Configuration > Configuration Management > Onglet Full import/export > Import, allez chercher votre config.tar.gz et uploadez le.

Si tout se passe bien, vous allez donc voir la page suivante vous indiquant qu’un élément a été modifié.

Cliquez sur le lien “View differences” et Drupal va vous montrer votre changement sous forme de “diff” directement.

Il suffit maintenant de valider les changements en soumettant le formulaire.
Et voilà, vos changements sont maintenant présents sur votre deuxième site.

Jusqu’ici, on aurait pu se contenter de transférer la base de données de “dev” sur “prod” et nous aurions eu le même résultat.
Néanmoins, n’oubliez pas une chose. Nous transférons ici uniquement de la configuration, et non du contenu. Cela signifie que le site de “prod” peut continuer à être alimenté en contenu, pendant que vous allez transférer la nouvelle configuration en production.

Utiliser CMI au sein d'une équipe

Le point important ici est: comment utiliser ce système afin de collaborer à plusieurs ?

Tout d’abord, il faut savoir que, par défaut, Drupal stocke les fichiers de configuration (les fameux fichiers « yaml ») dans un répertoire situé dans /sites/default/config/ avec une clé de hash. Cela doit ressembler à quelque chose du genre :

sites/default/files/config_1yrma6v3CrXoB35-RirGI9HNjvq1YBRNEHhezKiV6xdE6d4RiG6yrTu4el6LwKci1nuqjKtptA/staging

Néanmoins, et fort heureusement, ceci est facilement modifiable. En effet, cette clé est stockée dans votre settings.php, sous la forme :

$config_directories['staging'] = 'sites/default/files/config_1yrma6v3CrXoB35-RirGI9HNjvq1YBRNEHhezKiV6xdE6d4RiG6yrTu4el6LwKci1nuqjKtptA/staging’;

Il suffit donc de changer cette clé ici pour avoir quelque chose de plus « lisible », ou même de placer ce répertoire en dehors du webroot (bonne pratique de sécurité).

Pour notre test, changeons donc les deux clés du settings.php en :

$config_directories['active'] = 'sites/default/files/config_active';
$config_directories['staging'] = 'sites/default/files/config_staging';

Et maintenant, comment collaborer ?
C’est une chose relativement simple, à condition que chacun suive la même procédure.

Pour illustrer ceci, nous allons utiliser l’export/import de configuration via drush.

Les commandes importantes sont :

config-export (cex)   Export config from the active directory.
config-import (cim)   Import config from a config directory.

Pour commencer, lançons un export sur le site de production.

files git:(8.x) drush cex
The current contents of your export directory (sites/default/files/config_staging) will be deleted. (y/n): y
Configuration successfully exported to sites/default/files/config_staging.[success]

Puis commitez cette configuration initiale dans votre dépôt de code (git, svn …)

Chacun des développeurs va maintenant mettre à jour son dépôt local, puis importer la configuration.

A partir de ce moment, nous allons pouvoir chacun faire nos modifications en local, avant d’exporter à nouveau la configuration via drush, puis de commiter les changements.

L’agrégation des changements va se faire grâce à notre système de versionning de code.

Une fois la configuration d’une partie du site effectuée, la production sera alors mise à jour, la configuration à nouveau importée, et les changements seronts alors présent en production.
Tout simplement.

La solution repose donc, pour l’instant, sur un mélange entre ce qu’offre CMI et les fonctionnalités du gestionnaire de code (on ne le dira jamais assez, même si vous travaillez seul, c’est indispensable).

Personnellement, je ne pense pas que cela va beaucoup changer d’ici à la sortie de Drupal 8. Il va sûrement falloir se tourner vers la contrib afin de voir des solutions tierces, reposant sur ce qu’offre CMI, afin de réaliser ceci sans s’appuyer sur un gestionnaire de versionning de code.

Si vous souhaitez aller encore plus loin, nous ne pouvons que vous recommander la lecture de l'article produit par Nuvole : Packaging and reusing configuration in Drupal 8 [en]

Par Artusamak
Julien Dubois

CMI : ... à la pratique

CMI : ... à la pratique

Nous avons précédemment vu la théorie à propos de CMI. C’est maintenant le moment de voir comment s’en servir dans des conditions réelles.

Afin de faire nos tests, je vous propose de monter deux Drupal 8 en parallèle. Appelons les Drupal-Prod et Drupal-Dev. Pour se faire, il suffit d’installer un Drupal 8 d’un côté, de prendre sa base de données et de l’injecter dans un second site.

Pour le moment, allons sur l’instance dite “dev” et faisons un petit changement rapide. Par exemple, allons changer le slogan du site.

Allez maintenant dans Configuration > Configuration Management > Onglet Full import/export > Export et cliquez sur le bouton export. Vous allez obtenir un fichier config.tar.gz

Gardez bien ce fichier au chaud, et allez faire un tour sur le 2ème site.

Sur la page Configuration > Configuration Management > Onglet Full import/export > Import, allez chercher votre config.tar.gz et uploadez le.

Si tout se passe bien, vous allez donc voir la page suivante vous indiquant qu’un élément a été modifié.

Cliquez sur le lien “View differences” et Drupal va vous montrer votre changement sous forme de “diff” directement.

Il suffit maintenant de valider les changements en soumettant le formulaire.
Et voilà, vos changements sont maintenant présents sur votre deuxième site.

Jusqu’ici, on aurait pu se contenter de transférer la base de données de “dev” sur “prod” et nous aurions eu le même résultat.
Néanmoins, n’oubliez pas une chose. Nous transférons ici uniquement de la configuration, et non du contenu. Cela signifie que le site de “prod” peut continuer à être alimenté en contenu, pendant que vous allez transférer la nouvelle configuration en production.

Utiliser CMI au sein d'une équipe

Le point important ici est: comment utiliser ce système afin de collaborer à plusieurs ?

Tout d’abord, il faut savoir que, par défaut, Drupal stocke les fichiers de configuration (les fameux fichiers « yaml ») dans un répertoire situé dans /sites/default/config/ avec une clé de hash. Cela doit ressembler à quelque chose du genre :

sites/default/files/config_1yrma6v3CrXoB35-RirGI9HNjvq1YBRNEHhezKiV6xdE6d4RiG6yrTu4el6LwKci1nuqjKtptA/staging

Néanmoins, et fort heureusement, ceci est facilement modifiable. En effet, cette clé est stockée dans votre settings.php, sous la forme :

$config_directories['staging'] = 'sites/default/files/config_1yrma6v3CrXoB35-RirGI9HNjvq1YBRNEHhezKiV6xdE6d4RiG6yrTu4el6LwKci1nuqjKtptA/staging’;

Il suffit donc de changer cette clé ici pour avoir quelque chose de plus « lisible », ou même de placer ce répertoire en dehors du webroot (bonne pratique de sécurité).

Pour notre test, changeons donc les deux clés du settings.php en :

$config_directories['active'] = 'sites/default/files/config_active';
$config_directories['staging'] = 'sites/default/files/config_staging';

Et maintenant, comment collaborer ?
C’est une chose relativement simple, à condition que chacun suive la même procédure.

Pour illustrer ceci, nous allons utiliser l’export/import de configuration via drush.

Les commandes importantes sont :

config-export (cex)   Export config from the active directory.
config-import (cim)   Import config from a config directory.

Pour commencer, lançons un export sur le site de production.

files git:(8.x) drush cex
The current contents of your export directory (sites/default/files/config_staging) will be deleted. (y/n): y
Configuration successfully exported to sites/default/files/config_staging.[success]

Puis commitez cette configuration initiale dans votre dépôt de code (git, svn …)

Chacun des développeurs va maintenant mettre à jour son dépôt local, puis importer la configuration.

A partir de ce moment, nous allons pouvoir chacun faire nos modifications en local, avant d’exporter à nouveau la configuration via drush, puis de commiter les changements.

L’agrégation des changements va se faire grâce à notre système de versionning de code.

Une fois la configuration d’une partie du site effectuée, la production sera alors mise à jour, la configuration à nouveau importée, et les changements seronts alors présent en production.
Tout simplement.

La solution repose donc, pour l’instant, sur un mélange entre ce qu’offre CMI et les fonctionnalités du gestionnaire de code (on ne le dira jamais assez, même si vous travaillez seul, c’est indispensable).

Personnellement, je ne pense pas que cela va beaucoup changer d’ici à la sortie de Drupal 8. Il va sûrement falloir se tourner vers la contrib afin de voir des solutions tierces, reposant sur ce qu’offre CMI, afin de réaliser ceci sans s’appuyer sur un gestionnaire de versionning de code.

Si vous souhaitez aller encore plus loin, nous ne pouvons que vous recommander la lecteur de l'article produit par Nuvole : Packaging and reusing configuration in Drupal 8 [en]

Par juliendubreuil
julien dubreuil
Depuis 2009 maintenant, je développe avec le CMS/CMF Drupal. J’étais à la recherche d’un framework capable de remplacer un projet et je n’ai jamais arrêté de m’en servir depuis ce moment.

Drupal Commerce, maitriser votre checkout

Drupal Commerce configuration du checkout

Une des demandes récurrentes de la part des utilisateurs de Drupal Commerce est la possibilité de personnaliser le checkout. Que ce soit pour changer les étapes du checkout, ou pour recueillir des données supplémentaires, l’API de Drupal Commerce permet de répondre à ce besoin facilement.

Drupal Commerce vient avec deux concepts concernant le checkout, les Pages et les panes. Les “pages” permettent l’affichage et la configuration des différentes pages du checkout, comme par exemple la page de paiement, de livraison ou encore comme la page de résumé de commande. Ces pages contiennent des “panes”, permettant d’interagir avec le client, comme illustre la saisie de l’adresse ou du numéro de carte de crédit dans le checkout.

Attention toutefois, lorsque vous rallongez votre checkout, vous complexifiez le processus d’achat et augmentez les risques de perte de clients. Incontestablement, la bonne pratique est d’avoir le checkout le plus simple et court possible, néanmoins il existe certains cas où il faut déroger à la règle.

Ordonner les étapes de votre checkout

La façon la plus simple d’ordonner les étapes de votre checkout consiste à vous rendre sur l’interface d’administration de votre site dans la rubrique checkout settings de la section store > configuration

Cette page d’administration regroupe toutes les pages de votre checkout ainsi que les panes contenus dans chaque page. Drag’n dropable, vous pouvez déplacer un pane d’une page à une autre de façon à créer l’expérience utilisateur de votre choix.

Par défaut le checkout est découpé en 4 pages:
* Checkout : la page “Checkout”, est la première étape, elle permet la collecte des informations de base.
* Review order: la page “Review order” permet d’afficher un résumé de la commande avant la validation et la soumission du paiement.
* Payement : cette page, nommée “Payment”, est uniquement utilisée lorsque qu’une méthode de paiement est dite off-site.
* Checkout complete: la page “Checkout complete”, permet d’afficher une confirmation de commande au client.

Drupal Commerce checkout configurationDrupal Commerce checkout configuration

Ajouter des pages à votre checkout

Comme bien souvent, il existe deux façons de faire avec Drupal ou Drupal Commerce pour arriver à vos fins. Soit vous utilisez un module contrib, soit vous faites un peu de code custom.

Si vous souhaitez passer par un module, il vous faudra utiliser Drupal Commerce Checkout Pages qui vous permettra d’ajouter des pages depuis l’interface d’administration de votre site.

L’autre façon, consiste à utiliser l’API de Drupal Commerce en implémentant le hook_commerce_checkout_page_info() dans un module custom. Une fois créée votre page sera accessible dans l’interface d’administration. C’est de cette manière que sont créées les pages de Drupal Commerce. Pour plus d’information, rendez-vous dans le fichier commerce_checkout.api.php du sous module checkout.

Ajouter des panes à votre checkout

De la même manière que précédemment, il est possible de faire la même chose avec les panes.

Coté module vous pouvez vous baser sur Commerce extra panes afin d’afficher une ou plusieurs nodes dans votre checkout en guise d’information.

Coté code, il vous faudra implémenter le hook_commerce_checkout_pane_info() de façon à déclarer votre nouveau pane. Notez ensuite, que vous devrez créer vos callbacks, afin d’afficher les informations désirées.
Pour plus d’information, rendez-vous dans le fichier commerce_checkout.api.php du sous module checkout.

Le mot de la fin

Comme à l’accoutumée, il est simple de personnaliser le checkout de Drupal commerce que ce soit avec un module ou un peu de code custom. Encore une fois, attention de penser à l’expérience utilisateur de vos clients quand vous complexifiez le checkout.

Par Artusamak
Julien Dubois

Drupal et Scrum depuis les tranchées - La sprint définition

Drupal et Scrum depuis les tranchées - La sprint définition

Vous avez pu lire dans le billet précedent comment passer de la vision aux stories. Voyons maintenant comment gérer ce qu'il va se passer au démarrage du premier sprint et de tous ceux qui suivront : la sprint définition.

Pour les plus pressés d'entre vous qui ne veulent pas profiter du fun de l'article, direction le TL;DR.

A quoi sert la sprint définition ?

Le but de l'exercice est que l'équipe constitue la liste de ce qu'elle va avoir à faire au cours du sprint. Pour cela, le product owner passe en revue la liste des stories du backlog produit de la plus prioritaire à la moins prioritaire. Pour chaque story, l'équipe va passer en revue les critères d'acceptation et identifier les taches qui en découlent. L'exercice va donner lieu à des échanges entre le product owner et les membres de l'équipe, et cette dernière va débattre de la faisabilité technique, des pistes possibles pour réaliser le besoin.
Ayez toujours à l'esprit les capacités de Drupal dans vos échanges car la maîtrise de l'outil vous épargnera de gaspiller votre temps en développements futiles.
La sprint définition est le moment durant lequel l'équipe doit comprendre chaque pixel du projet. Toutes les questions doivent être posées au cours de ce rituel car ça n'est pas une fois que l'implémentation démarrera qu'il faudra qu'elle se demande à quoi servent certains boutons / portions d'une page.

Les choix d'implémentation

Lorsque les stories sont passées en revue, l'équipe a le droit de rajouter des stories techniques, de débattre des priorités si elle pense que certaines choses doivent se faire avant d'autres. L'une des forces de l'agilité étant le principe d'itérations, le groupe est fortement invité à proposer toutes les pistes qui lui viendront à l'esprit afin de produire le plus de valeur ajoutée en un minimum de temps. L'écosystème des modules Drupal est très bon à ce petit jeu là, nous ne pouvons que vous encourager à vous en servir afin de proposer au product owner plusieurs options et de lui expliquer clairement ce qui serait faisable / non faisable comparé à sa demande initiale. Le but étant de toujours aller au plus vite à un premier résultat pas toujours parfait mais qui fait le travail et en se donnant la possbilité de choisir par la suite si le résultat constaté est satisfaisant ou si du temps supplémentaire doit être investi pour l'affiner.

Dimensionner les stories

Une fois que l'équipe n'a plus de questions sur le périmètre de la story fonctionnelle et qu'elle pense avoir son plan de bataille pour l'implémentation (pas besoin de noter tous les détails, vous pouvez vous limiter aux options / pistes possibles pour le développement) le jeu du poker planning démarre. Que vos espoirs de devenir millionnaire en jouant aux cartes dans des saloons retombent car il n'en est rien :  le concept est le suivant, tous les équipiers relisent les taches listées et réfléchissent à une taille à donner à cette story.
On ne va pas mesurer le temps que cela prend de faire la réalisation (un junior et un senior ne prendraient probablement pas autant de temps) mais on va estimer l'effort que cela implique. Pour se faire, on utilise une unité abstraite, les points de complexité.
Pour éviter les dilemmes on s'inspire de la suite de Fibonnacci, ce qui donne la liste de valeurs possibles suivante : 1, 2, 3, 5, 8, 13 puis on lui ajoute les valeurs 20, 40, 100, ? et "PAUSE" pour permettre à chacun d'indiquer que quelque chose est très gros, impossible à mesurer au vue de ses connaissances ou qu'il a besoin d'une pause avant d'y arriver.

Lorsque vous allez choisir la complexité d'une story, sa valeur absolue a peu d'importance. Ce qui va compter c'est que ce que vous allez estimer à 5 représente toujours la même chose. La story la plus difficile à estimer reste la première car on travail par la suite par comparaison. "Cette story pour laquelle nous votons 3 est-elle vraiment aussi complexe que la #651 pour laquelle on avait déjà voté 3 et qui nécessitait une gestion des droits fines en plus ?".
De la même façon l'effort doit être pris en compte. Si on évalue par exemple la création d'un type de contenu à 1, si l'un d'entre eux a 70 champs, peut être allons nous évaluer l'effort à 2 ou 3.


Partager les points de vue

L'estimation de la taille des stories se fait en simultané pour chacun des coéquipiers, tous ont devant eux un jeu de cartes d'estimations (d'où le nom de planning poker) et l'abattage des estimations doit se faire au même moment une fois que tout le monde a pris le temps de trouver son estimation (et poser les dernières questions si nécessaire). L'abattage révèle souvent des surprises (et des fous rires !) et suscite des échanges. "Pourquoi as-tu voté 2 ? C'est super compliqué de faire la couche d'abstraction, rappelles toi du projet Superfish !", "Wow, 5, vraiment ? On utilise Views Megarow et c'est parti, ça nous prendra peu de temps de construire cette interface".
Les points de vue seront donc confrontés, permettant de faire émerger des choses compliquées dont tout le monde n'avait pas conscience ou en apportant de la réassurance via la découverte de techniques / savoir-faire acquis par le passé et oubliés par certains.
Lorsque les votes sont vraiment différents (2 VS 8 par exemple) il y a une période d'échanges pour comprendre la source d'un tel écart, puis l'équipe revote jusqu'à ce que les estimations soient proches (et on prendra toujours la plus pessimiste par principe). Il est important de noter que passée une certaine taille, la faisabilité d'une story devient un risque. Si la complexité de plusieurs stories est supérieure ou égale à 8 il faut probablement envisager de découper les stories en plusieurs stories de taille inférieure afin de toujours s'assurer que vous livrez quelque chose. Si les estimations chiffrées posent problème, vous pouvez changer d'unité, XS, S, M, L, XL, XXL etc (ou libre à vous d'inventer la votre)

Une fois qu'une story est dimensionnée elle rejoint le backlog de sprint et on passe à la suivante. L'exercice se répète jusqu'à ce que l'équipe estime avoir suffisamment de travail pour la durée du sprint. Et ce choix est très important, en effet, l'équipe s'engage à livrer tout ce qu'elle a intégré à son backlog de sprint. Si des choses ne sont pas terminées à la fin de l'itération il faudra en trouver la cause pour que ça ne se reproduise pas. C'est donc une promesse faite, vis à vis du product owner mais aussi vis à vis de soi même. La capacité de l'équipe à respecter ses engagements déterminera sa vélocité. Le fait de livrer toutes les 2 semaines rend le projet excitant car on mesure les progrès d'un sprint à l'autre.

Vous l'aurez compris, les journées de sprint définition sont des journées qui sont bien remplies, alors préparez-vous en ramenant le jus de fruit, les croissants et des barres de céréales et en faisant une bonne nuit de sommeil la veille. Gardez l'exercice fun, veillez à ce que tout le monde donne sont avis et votre sprint se déroulera bien.

TL;DR

  • Au cours de la sprint définition l'équipe s'approprie le projet / la vision
  • C'est pendant la sprint définition que les questions se posent, une fois passée il est trop tard et on rentre dans l'implémentation
  • L'univers contrib de Drupal permet de faire beaucoup de choses pour un faible investissement
  • Profitez des itérations pour proposer une base fonctionnelle non parfaite mais satisfaisante puis demandez-vous s'il faut aller plus loin
  • Utilisez le planning poker pour quantifier l'effort nécessaire à la réalisation des stories
  • Apprenez à estimer par comparaison
  • Echangez afin de vous assurer que vous êtes tous sur la même longueur d'onde
  • Respectez vos engagements lorsque vous constituez votre backlog de sprint
  • Multipliez les petites stories plutôt que d'en avoir de très grosses.
  • Assurez-vous de toujours livrer quelque chose.
Par Artusamak
Julien Dubois

Drupal et Scrum depuis les tranchées - La sprint définition

Drupal et Scrum depuis les tranchées - La sprint définition

Vous avez pu lire dans le billet précedent comment passer de la vision aux stories. Voyons maintenant comment gérer ce qu'il va se passer au démarrage du premier sprint et de tous ceux qui suivront : la sprint définition.

Pour les plus pressés d'entre vous qui ne veulent pas profiter du fun de l'article, direction le TL;DR.

A quoi sert la sprint définition ?

Le but de l'exercice est que l'équipe constitue la liste de ce qu'elle va avoir à faire au cours du sprint. Pour cela, le product owner passe en revue la liste des stories du backlog produit de la plus prioritaire à la moins prioritaire. Pour chaque story, l'équipe va passer en revue les critères d'acceptation et identifier les taches qui en découlent. L'exercice va donner lieu à des échanges entre le product owner et les membres de l'équipe, et cette dernière va débattre de la faisabilité technique, des pistes possibles pour réaliser le besoin.
Ayez toujours à l'esprit les capacités de Drupal dans vos échanges car la maîtrise de l'outil vous épargnera de gaspiller votre temps en développements futiles.
La sprint définition est le moment durant lequel l'équipe doit comprendre chaque pixel du projet. Toutes les questions doivent être posées au cours de ce rituel car ça n'est pas une fois que l'implémentation démarrera qu'il faudra qu'elle se demande à quoi servent certains boutons / portions d'une page.

Les choix d'implémentation

Lorsque les stories sont passées en revue, l'équipe a le droit de rajouter des stories techniques, de débattre des priorités si elle pense que certaines choses doivent se faire avant d'autres. L'une des forces de l'agilité étant le principe d'itérations, le groupe est fortement invité à proposer toutes les pistes qui lui viendront à l'esprit afin de produire le plus de valeur ajoutée en un minimum de temps. L'écosystème des modules Drupal est très bon à ce petit jeu là, nous ne pouvons que vous encourager à vous en servir afin de proposer au product owner plusieurs options et de lui expliquer clairement ce qui serait faisable / non faisable comparé à sa demande initiale. Le but étant de toujours aller au plus vite à un premier résultat pas toujours parfait mais qui fait le travail et en se donnant la possbilité de choisir par la suite si le résultat constaté est satisfaisant ou si du temps supplémentaire doit être investi pour l'affiner.

Dimensionner les stories

Une fois que l'équipe n'a plus de questions sur le périmètre de la story fonctionnelle et qu'elle pense avoir son plan de bataille pour l'implémentation (pas besoin de noter tous les détails, vous pouvez vous limiter aux options / pistes possibles pour le développement) le jeu du poker planning démarre. Que vos espoirs de devenir millionnaire en jouant aux cartes dans des saloons retombent car il n'en est rien :  le concept est le suivant, tous les équipiers relisent les taches listées et réfléchissent à une taille à donner à cette story.
On ne va pas mesurer le temps que cela prend de faire la réalisation (un junior et un senior ne prendraient probablement pas autant de temps) mais on va estimer l'effort que cela implique. Pour se faire, on utilise une unité abstraite, les points de complexité.
Pour éviter les dilemmes on s'inspire de la suite de Fibonnacci, ce qui donne la liste de valeurs possibles suivante : 1, 2, 3, 5, 8, 13 puis on lui ajoute les valeurs 20, 40, 100, ? et "PAUSE" pour permettre à chacun d'indiquer que quelque chose est très gros, impossible à mesurer au vue de ses connaissances ou qu'il a besoin d'une pause avant d'y arriver.

Lorsque vous allez choisir la complexité d'une story, sa valeur absolue a peu d'importance. Ce qui va compter c'est que ce que vous allez estimer à 5 représente toujours la même chose. La story la plus difficile à estimer reste la première car on travail par la suite par comparaison. "Cette story pour laquelle nous votons 3 est-elle vraiment aussi complexe que la #651 pour laquelle on avait déjà voté 3 et qui nécessitait une gestion des droits fines en plus ?".
De la même façon l'effort doit être pris en compte. Si on évalue par exemple la création d'un type de contenu à 1, si l'un d'entre eux a 70 champs, peut être allons nous évaluer l'effort à 2 ou 3.


Partager les points de vue

L'estimation de la taille des stories se fait en simultané pour chacun des coéquipiers, tous ont devant eux un jeu de cartes d'estimations (d'où le nom de planning poker) et l'abattage des estimations doit se faire au même moment une fois que tout le monde a pris le temps de trouver son estimation (et poser les dernières questions si nécessaire). L'abattage révèle souvent des surprises (et des fous rires !) et suscite des échanges. "Pourquoi as-tu voté 2 ? C'est super compliqué de faire la couche d'abstraction, rappelles toi du projet Superfish !", "Wow, 5, vraiment ? On utilise Views Megarow et c'est parti, ça nous prendra peu de temps de construire cette interface".
Les points de vue seront donc confrontés, permettant de faire émerger des choses compliquées dont tout le monde n'avait pas conscience ou en apportant de la réassurance via la découverte de techniques / savoir-faire acquis par le passé et oubliés par certains.
Lorsque les votes sont vraiment différents (2 VS 8 par exemple) il y a une période d'échanges pour comprendre la source d'un tel écart, puis l'équipe revote jusqu'à ce que les estimations soient proches (et on prendra toujours la plus pessimiste par principe). Il est important de noter que passée une certaine taille, la faisabilité d'une story devient un risque. Si la complexité de plusieurs stories est supérieure ou égale à 8 il faut probablement envisager de découper les stories en plusieurs stories de taille inférieure afin de toujours s'assurer que vous  livre quelque chose. Si les estimations chiffrées posent problème, vous pouvez changer d'unité, XS, S, M, L, XL, XXL etc (ou libre à vous d'inventer la votre)

Une fois qu'une story est dimensionnée elle rejoint le backlog de sprint et on passe à la suivante. L'exercice se répète jusqu'à ce que l'équipe estime avoir suffisamment de travail pour la durée du sprint. Et ce choix est très important, en effet, l'équipe s'engage à livrer tout ce qu'elle a intégré à son backlog de sprint. Si des choses ne sont pas terminées à la fin de l'itération il faudra en trouver la cause pour que ça ne se reproduise pas. C'est donc une promesse faite, vis à vis du product owner mais aussi vis à vis de soi même. La capacité de l'équipe à respecter ses engagements déterminera sa vélocité. Le fait de livrer toutes les 2 semaines rend le projet excitant car on mesure les progrès d'un sprint à l'autre.

Vous l'aurez compris, les journées de sprint définition sont des journées qui sont bien remplies, alors préparez-vous en ramenant le jus de fruit, les croissants et des barres de céréales et en faisant une bonne nuit de sommeil la veille. Gardez l'exercice fun, veillez à ce que tout le monde donne sont avis et votre sprint se déroulera bien.

TL;DR

  • Au cours de la sprint définition l'équipe s'approprie le projet / la vision
  • C'est pendant la sprint définition que les questions se posent, une fois passée il est trop tard et on rentre dans l'implémentation
  • L'univers contrib de Drupal permet de faire beaucoup de choses pour un faible investissement
  • Profitez des itérations pour proposer une base fonctionnelle non parfaite mais satisfaisante puis demandez-vous s'il faut aller plus loin
  • Utilisez le planning poker pour quantifier l'effort nécessaire à la réalisation des stories
  • Apprenez à estimer par comparaison
  • Echangez afin de vous assurer que vous êtes tous sur la même longueur d'onde
  • Respectez vos engagements lorsque vous constituez votre backlog de sprint
  • Multipliez les petites stories plutôt que d'en avoir de très grosses.
  • Assurez-vous de toujours livrer quelque chose.
Par anavarre

Meetup Drupal Lyon - Présentation sur la sécurité

Pour le dernier meetup Drupal Lyon avant la coupure de l'été, j'ai fait une présentation sur la sécurité. Puisque le panel est assez hétérogène et qu'on parle aussi bien à des nouveaux venus sur Drupal qu'à des experts, je me suis dit qu'il serait intéressant de faire une présentation à la fois high-level et qui récapitule un ensemble de bonnes pratiques sur la sécurité qu'on a parfois tendance à oublier. L'idée principale c'est : ne pensez pas être "nul" en sécurité ou pas assez expert pour en parler ou vous y coller.

Par Artusamak
Julien Dubois

Drupal et Scrum depuis les tranchées - Constitution du backlog produit

Drupal et Scrum depuis les tranchées - Constitution du backlog produit

Une fois après avoir sauté de joie en apprenant que c'est avec nous que notre client tant convoité veut travailler, il faut se remettre au travail pour constituer la matière que les développeurs vont exploiter au moment de produire. Il va dès lors falloir que nous convertissions le cahier des charges de notre client en stories. Bonne nouvelle c'est à cela que sert le sprint 0.

Pour les gens pressés : TL;DR.

De la vision aux stories

Le sprint 0 est un sprint particulier qui ne ressemble pas aux autres, c'est celui par lequel tout débute et qui va servir à préparer la matière dont l'équipe a besoin pour démarrer le premier sprint. Au cours du sprint 0 nous allons commercer par formaliser la vision du projet. La vision est la verbalisation de pour quoi et pour qui ce projet prend vie et va nous servir de cap lorsqu'il faudra arbitrer entre deux décisions (laquelle des deux options nous permet de servir au mieux la vision ?).

Il est ensuite possible de dresser le portrait de quelques personas, cette étape n'est pas obligatoire. Les personas sont l'incarnation des profils type d'utilisateurs de notre système, on dresse leur portrait-robot et leur donne un petit nom, ce qui rend plus simple dans nos stories de désigner Mélissa ou Philippe lorsque l'on évoque un administrateur ou un contributeur à notre site Drupal.

Nous voilà fin prêts à passer en revue le périmètre fonctionnel du projet. On va commencer par lister les grands sujets du projet identifiés dans le chiffrage ou le cahier des charges puis, pour chacun de ces domaines, détailler la liste des fonctionnalités. Toutes ces fonctionnalités ne sont pas encore des stories complètes, elles ne sont que leur titre. Nous vous recommandons au cours du sprint 0 d'essayer de dresser une liste assez exhaustive des fonctionnalités pour se rendre compte de l'ampleur du travail. Une fois cette liste établie il faut la prioriser par ordre de valeur ajoutée pour l'utilisateur final de la plus importante à la moins importante. Lorsque cette partie du travail est terminée, il suffit de repasser en revue les fonctionnalités les plus importantes pour en faire de vraies stories. C'est le moment où nous allons préciser les critères d'acceptation et rédiger la description des stories reprenant le modèle "En tant que [nom du persona ou de l'utilisateur] je peux [action] afin de [but]" .

Les critères d'acceptation sont la liste des tests que le développeur et le client vont dérouler lorsqu'ils vont valider qu'une fonctionnalité remplie ses besoins. Les critères d'acceptation listent ce que doit et ne doit pas faire une story. Si par exemple des validations de format, des messages d'erreur / de confirmation doivent apparaitre il faut le préciser à ce moment là.

N'oubliez pas qu'au cours de votre sprint 0 nous ne devons pas écrire la liste exhaustive des stories détaillées de votre projet (titre, description et critères d'acceptation), ce serait un travail titanesque et surtout abérant car la liste des priorités lors du sprint 0 ne sera probablement pas la même que lors du sprint 4 (autant éviter de travailler pour rien).
Il faut se contenter de préparer un nombre suffisant de stories pour que l'équipe ait du travail au cours du sprint 1 et nous assurer que le client s'est familiarisé avec le concept de story en mettant l'accent sur les critères d'acceptation qui seront la guarantie que nous nous entendons sur le fait qu'une fonctionnalité est terminée.


Drupal impose ses propres besoins

Il ne faut pas non plus omettre qu'au cours du sprint 0 des stories techniques doivent être intégrées, votre client doit comprendre que prévoir du temps pour concevoir une API, un composant technique important de son application, etc sont des étapes nécessaires toutes aussi indispensables que des choses directement utilisées par les utilisateurs finaux.

En plus de cela, Drupal va introduire ses propres stories telles que la gestion de l'arborescence du projet, le modèle des URLs à réécrire, les permissions, l'identification de view modes...
Rappelons-nous que notre client ne connait pas Drupal, si nous attendons de lui qu'il nous livre une liste de champs pour des types de contenu nous pourrions lui fournir un livrable d'exemple pour qu'il sache comment nous aider à avancer en économisant plusieurs aller retours.

Pensons à prévoir des stories (et du temps (une demie journée) si nous faisons cela pendant le sprint 0) pour la mise en place du dépôt, des éventuels scripts de déploiement ou de la configuration spécifique que pourrait nécessiter le processus d'industrialisation.

Cette première étape est l'occasion de rappeler à notre client que nous allons travailler ensemble (et qu'il va devoir travailler lui aussi) et que nous n'allons pas être un prestataire qu'il se contente de piloter. Ah et bien entendu nous pouvons dès maintenant lui annoncer qu'il sera en retard pour livrer ses contenus !

TL;DR

  • Votre interlocuteur doit connaitre son projet et être décisionnaire pour avancer
  • Le Cahier des Charges est important car c'est la matière première à partir de laquelle on va structure le backlog produit initial
  • Rien ne sert de se précipiter, il suffit d'avoir un backlog bien préparé pour le sprint 1, il restera du temps pour l'élargir et le compléter
  • Ne pas négliger les critères d'acceptation qui sont la garantie que vous savez comment faire les choses et que lorsque les stories seront testées vous en aurez la même lecture
  • Ne pas oublier que Drupal impose ses propres stories. (Création de stories de technique et limitation des users stories à l'aspect fonctionnel)
  • Aider le client autant que possible en lui proposant des exemples lorsque vous attendez des livrables de sa part.
Par Artusamak
Julien Dubois

Drupal et Scrum depuis les tranchées - Constitution du backlog produit

Drupal et Scrum depuis les tranchées - Constitution du backlog produit

Une fois après avoir sauté de joie en apprenant que c'est avec nous que notre client tant convoité veut travailler, il faut se remettre au travail pour constituer la matière que les développeurs vont exploiter au moment de produire. Il va dès lors falloir que nous convertissions le cahier des charges de notre client en stories. Bonne nouvelle c'est à cela que sert le sprint 0.

Pour les gens pressés : TL;DR.

De la vision aux stories

Le sprint 0 est un sprint particulier qui ne ressemble pas aux autres, c'est celui par lequel tout débute et qui va servir à préparer la matière dont l'équipe a besoin pour démarrer le premier sprint. Au cours du sprint 0 nous allons commercer par formaliser la vision du projet. La vision est la verbalisation de pour quoi et pour qui ce projet prend vie et va nous servir de cap lorsqu'il faudra arbitrer entre deux décisions (laquelle des deux options nous permet de servir au mieux la vision ?).

Il est ensuite possible de dresser le portrait de quelques personas, cette étape n'est pas obligatoire. Les personas sont l'incarnation des profils type d'utilisateurs de notre système, on dresse leur portrait-robot et leur donne un petit nom, ce qui rend plus simple dans nos stories de désigner Mélissa ou Philippe lorsque l'on évoque un administrateur ou un contributeur à notre site Drupal.

Nous voilà fin prêts à passer en revue le périmètre fonctionnel du projet. On va commencer par lister les grands sujets du projet identifiés dans le chiffrage ou le cahier des charges puis, pour chacun de ces domaines, détailler la liste des fonctionnalités. Toutes ces fonctionnalités ne sont pas encore des stories complètes, elles ne sont que leur titre. Nous vous recommandons au cours du sprint 0 d'essayer de dresser une liste assez exhaustive des fonctionnalités pour se rendre compte de l'ampleur du travail. Une fois cette liste établie il faut la prioriser par ordre de valeur ajoutée pour l'utilisateur final de la plus importante à la moins importante. Lorsque cette partie du travail est terminée, il suffit de repasser en revue les fonctionnalités les plus importantes pour en faire de vraies stories. C'est le moment où nous allons préciser les critères d'acceptation et rédiger la description des stories reprenant le modèle "En tant que [nom du persona ou de l'utilisateur] je peux [action] afin de [but]" .

Les critères d'acceptation sont la liste des tests que le développeur et le client vont dérouler lorsqu'ils vont valider qu'une fonctionnalité remplie ses besoins. Les critères d'acceptation listent ce que doit et ne doit pas faire une story. Si par exemple des validations de format, des messages d'erreur / de confirmation doivent apparaitre il faut le préciser à ce moment là.

N'oubliez pas qu'au cours de votre sprint 0 nous ne devons pas écrire la liste exhaustive des stories détaillées de votre projet (titre, description et critères d'acceptation), ce serait un travail titanesque et surtout abérant car la liste des priorités lors du sprint 0 ne sera probablement pas la même que lors du sprint 4 (autant éviter de travailler pour rien).
Il faut se contenter de préparer un nombre suffisant de stories pour que l'équipe ait du travail au cours du sprint 1 et nous assurer que le client s'est familiarisé avec le concept de story en mettant l'accent sur les critères d'acceptation qui seront la guarantie que nous nous entendons sur le fait qu'une fonctionnalité est terminée.


Drupal impose ses propres besoins

Il ne faut pas non plus omettre qu'au cours du sprint 0 des stories techniques doivent être intégrées, votre client doit comprendre que prévoir du temps pour concevoir une API, un composant technique important de son application, etc sont des étapes nécessaires toutes aussi indispensables que des choses directement utilisées par les utilisateurs finaux.

En plus de cela, Drupal va introduire ses propres stories telles que la gestion de l'arborescence du projet, le modèle des URLs à réécrire, les permissions, l'identification de view modes...
Rappelons-nous que notre client ne connait pas Drupal, si nous attendons de lui qu'il nous livre une liste de champs pour des types de contenu nous pourrions lui fournir un livrable d'exemple pour qu'il sache comment nous aider à avancer en économisant plusieurs aller retours.

Pensons à prévoir des stories (et du temps (une demie journée) si nous faisons cela pendant le sprint 0) pour la mise en place du dépôt, des éventuels scripts de déploiement ou de la configuration spécifique que pourrait nécessiter le processus d'industrialisation.

Cette première étape est l'occasion de rappeler à notre client que nous allons travailler ensemble (et qu'il va devoir travailler lui aussi) et que nous n'allons pas être un prestataire qu'il se contente de piloter. Ah et bien entendu nous pouvons dès maintenant lui annoncer qu'il sera en retard pour livrer ses contenus !

TL;DR

  • Votre interlocuteur doit connaitre son projet et être décisionnaire pour avancer
  • Le Cahier des Charges est important car c'est la matière première à partir de laquelle on va structure le backlog produit initial
  • Rien ne sert de se précipiter, il suffit d'avoir un backlog bien préparé pour le sprint 1, il restera du temps pour l'élargir et le compléter
  • Ne pas négliger les critères d'acceptation qui sont la garantie que vous savez comment faire les choses et que lorsque les stories seront testées vous en aurez la même lecture
  • Ne pas oublier que Drupal impose ses propres stories. (Création de stories de technique et limitation des users stories à l'aspect fonctionnel)
  • Aider le client autant que possible en lui proposant des exemples lorsque vous attendez des livrables de sa part.
Par Marc Delnatte
Akabia

5 étapes indispensables pour un bon référencement onsite !

Pour bien référencer son site, il faut préalablement avoir étudié les mots clés sur lesquels vous souhaitez vous positionner. Après avoir réalisé cette minutieuse étude, vous pourrez vous attaquer à l’optimisation on-site.







Pourquoi choisir (ou pas) Drupal ?







Non, ce billet ne va pas vous proposer un comparatif des trois principaux CMS du marché, à savoir Wordpress, Joomla et Drupal. Parce que ce comparatif serait périmé au bout de quelques mois. Et parce que les fonctionnalités offertes par ces CMS tendent à se rapprocher de plus en plus, du fait d'une émulation réciproque. Mais alors, qu'est-ce qui peut différencier aujourd'hui ces CMS ? Essayons de faire un panorama des utilisations actuelles de ces CMS.

Thème 
Drupal
Drupal 7
Drupal 8

Par admin

DrupalFR vous invite au PHP Tour 2014

Le "PHP Tour" est l'événement tournant qu'organise l'AFUP (Association Française des Utilisateurs de PHP) et pour la troisième édition, celui-ci s'arrêtera à Lyon les 23 et 24 juin.

Il s'agit d'un rendez-vous incontournable autour du langage PHP, avec quelques têtes d'affiches, comme :

  • Rasmus Lerdorf, intitulée "Coding and Dreaming – PHP in 2014", soit un tour d’horizon des performances excitantes que permet désormais PHP 5.5.
  • Julien Pauli, sur "YooopeeCache", ou comment installer, configurer et profiter de OPCache, le cache d’OPCode par défaut depuis PHP5.5.
  • Pascal Martin sur "PHP 5.3 à PHP 5.6 : no pain but gain !", une conférence technique pour appréhender les changements de versions de PHP 5 en toute tranquillité !

De plus, les membres de l'association Drupal France et Francophonie peuvent bénéficier d'une remise sur le prix de l'entrée. Pour cela, il suffit d'envoyer un email au bureau pour que l'on vous communique le code "coupon".

Alors, vous pouvez vous rendre sur :

Enfin, de nombreuses surprises vous attendent comme les cliniques co-organisés par les sponsors, une soirée communautaire, etc...

Par juliendubreuil
julien dubreuil
Depuis 2009 maintenant, je développe avec le CMS/CMF Drupal. J’étais à la recherche d’un framework capable de remplacer un projet et je n’ai jamais arrêté de m’en servir depuis ce moment.

Yaml, le format de configuration

Yaml, le format de configuration

L’une des premières choses que vous allez remarquer en regardant le code de Drupal 8, est le nouveau format de configuration. Terminé les extensions en .info, maintenant toute la configuration réside dans des fichiers .yml écrits au format YAML (YAML Ain’t Markup Language).

Aussi facile à lire que précédemment, il permet plus de choses et s’est imposé comme l’un des formats de standardisation dans plusieurs langages de programmation, tels que C, Perl et Python. L’une des grandes décisions prise pour Drupal 8 a été de standardiser le plus possible et de réutiliser des composants existant et fiables de façon à se concentrer sur autre chose. Ainsi le format YAML remplacera nos bons vieux fichiers maison.

L’ancienne version du fichier .info du module block:


1
2
3
4
5
6
7
8
# Drupal 7 block.info
name = Block
description = Controls the visual building blocks a page is constructed with. Blocks are boxes of content rendered into an area, or region, of a web page.
package = Core
version = VERSION
core = 7.x
files[] = block.test
configure = admin/structure/block

La nouvelle version du fichier info du module block au format YAML


1
2
3
4
5
6
7
8
# Drupal 8 block.info.yml
name: Block
type: module
description: 'Controls the visual building blocks a page is constructed with. Blocks are boxes of content rendered into an area, or region, of a web page.'
package: Core
version: VERSION
core: 8.x
configure: admin/structure/block

Comme vous pouvez le voir, les deux fichiers sont similaires. La bonne nouvelle est que vous ne serez pas dépaysé en écrivant au format YAML.

Pour vous aider à comprendre les avantages et la structure de ce nouveau format, voici dans les grandes lignes à quoi ressemble la syntaxe. Si vous voulez en savoir plus, rendez-vous directement sur la page wikipédia ou sur la documentation Symfony 2

  • Les commentaires doivent être précédés par un #
  • La valeur Null peut être exprimée de deux façons, avec la chaîne de caractère null ou le symbole ~
  • Les booléens s’écrivent true ou false
  • Les chaînes de caractères doivent être entourées par des apostrophes. Néanmoins si votre chaîne de caractère contient une ou plusieurs apostrophes, vous pouvez utiliser les guillemets.
  • Les listes d’éléments peuvent être définies sur une seule ligne ou dans un bloc (sur plusieurs lignes). Utilisez un tiret pour ajouter un nouvel élément dans une liste.


1
2
3
4
5
# comment.info.yml
dependencies:
 - datetime
 - node
 - text

Ou si vous préférez, vous pouvez créer vos listes sur une seul ligne.


1
[datetime, node, text]

Les tableaux sont de simples objets au format clé:valeur.


1
2
3
4
5
6
7
# comment.info.yml
name: Comment
type: module
description: 'Allows users to comment on and discuss published content.'
package: Core
version: VERSION
core: 8.x

Il est possible d’imbriquer les tableaux, il suffit simplement d’ajouter une indentation à un tableau. Attention, les indentations doivent utiliser deux espaces et non pas des tabulations.


1
2
3
4
5
6
7
8
#block.routing.yml
block_admin_display:
  pattern: '/admin/structure/block'
  defaults:
    _content: '\Drupal\block\Controller\BlockListController::listing'
    entity_type: 'block'
  requirements:
    _permission: 'administer blocks'

Au final rien de méchant et rien de compliqué, l’intégration du format YAML ne vous donnera pas du fil à retordre. Cela aura juste pour conséquence d’unifier tous les fichiers de configurations en imposant un standard. Que ce soit pour la déclaration des modules, de fichiers de configuration en passant par le nouveau système de plug-in tout sera fait dans ce format.

Crédits Photo – Alessandro Prada

Comment Drupal est protégé contre les 10 plus importantes failles de sécurité







Dans le domaine de la sécurité, la réputation de Drupal n'est plus à faire. Interrogé sur les raisons de cette réputation, il est souvent indiqué que Drupal est sécurisé by design, c'est à dire depuis sa conception même. Autrement dit, dès le départ, Drupal a été conçu avec la notion toujours présente à l'esprit que le système doit être sûr et sécurisé. Regardons en détail comment Drupal, grâce à ses interfaces de programmations (API) si elles sont utilisées correctement, prend en compte chacune des failles de sécurité les plus importantes. Ces éléments de réponse proviennent du rapport publié régulièrement sur drupalsecurityreport.org.

Thème 
Sécurité Drupal
Prestataire
Spécialiste
Drupal

Par Artusamak
Julien Dubois

CMI : De la théorie...

CMI : De la théorie...

CMI, ou « Content Management Initiative » représente l’une des avancées majeures de Drupal 8 visant à répondre à un besoin semblant simple au premier abord : Apporter une solution permettant de synchroniser la configuration d’un site entre plusieurs instances.

Comme le disait Greg Dunlap, le leader du projet :

CMI hopes to separate management of your code and content once and for all! We want to make it possible to store your site’s configuration in a standard API separate from its content, soliving issues like feature management and content staging that are cumbersome in previous Drupal versions.”

Mais ça ressemble à quoi ?

Il s’agit principalement d’une API fournissant aux développeurs une manière simple, standardisée, de stocker de la configuration de telle sorte qu’elle soit déployable.
Pour l’utilisateur final, cela signifie que nous sommes désormais capables de créer et configurer un site sur un serveur (de développement, de préproduction) et de le « déplacer » ensuite en production cette même configuration.

Pour bien comprendre le fonctionnement, il faut d’abord clarifier deux notions que CMI utilise : Active storage et Staging Storage.

  • L’Active Storage est un espace, par défaut la base de données, où Drupal stocke la configuration courante du site.
  • Le Staging Storage est lui un espace, par défaut le système de fichier, où Drupal stocke la configuration qu’il va devoir importer.

Chaque changement entre le Staging et l’Active peut être visualisé dans l’administration de Drupal.

Examinons ensemble un exemple d’un fichier de configuration, ici le fichier définissant le type de contenu « Book » :

type: book
name: 'Book page'
description: '<em>Books</em> have a built-in hierarchical navigation. Use for handbooks or tutorials.'
help: ''
has_title: true
title_label: Title
settings:
  node:
    preview: 1
    options:
      status: true
      # Not promoted to front page.
      promote: false
      sticky: false
      revision: false
    submitted: true
status: true
langcode: en

Comme on peut le voir, la configuration reste très compréhensible et facile à lire. Le plus important à comprendre est que ces fichiers fonctionnent sur un mode déclaratif.

Qu'est-ce que le mode déclaratif ?

Voyons ce que nous dit Wikipedia :

La programmation déclarative est un paradigme de programmation. Il consiste à créer des applications sur la base de composants logiciels indépendants du contexte et ne comportant aucun état interne. Autrement dit, l'appel d'un de ces composants avec les mêmes arguments produit exactement le même résultat, quel que soit le moment et le contexte de l'appel.

En programmation déclarative, on décrit le quoi, c'est-à-dire le problème. Par exemple, les pages HTML sont déclaratives car elles décrivent ce que contient une page (texte, titres, paragraphes, etc.) et non comment les afficher (positionnement, couleurs, polices de caractères, etc.). Alors qu'en programmation impérative (par exemple, avec le C ou Java), on décrit le comment, c'est-à-dire la structure de contrôle correspondant à la solution.

Autrement dit, en simplifiant, on pourrait dire :

  • Programmation impérative : décris à la « machine » comment faire quelque chose, et il en résulte ce que vous escomptez.
  • Programmation déclarative : décris à la « machine » ce que vous souhaitez qu’il se passe, et laisse la machine trouver comment y arriver

CMI n’est pas features !

Si vous aviez l’habitude (et vous devez l’avoir !) d’utiliser le module Features, vous serez peut-être un peu perdu au début. En effet, il ne faut pas oublier le but initial de Features était de pouvoir packager des « trucs » ensemble afin qu’ils puissent être réutilisés.
Ce n’est pas du tout le but de CMI. Ici, on exporte systématiquement l’ensemble de la configuration de votre site, et non pas une petite section.

Pour résumer, CMI est donc un outil permettant de gérer la configuration de manière déclarative, versionnable, et déployable.

Prochaine étape, la pratique !

Par Artusamak
Julien Dubois

CMI : De la théorie...

CMI : De la théorie...

CMI, ou « Content Management Initiative » représente l’une des avancées majeures de Drupal 8 visant à répondre à un besoin semblant simple au premier abord : Apporter une solution permettant de synchroniser la configuration d’un site entre plusieurs instances.

Comme le disait Greg Dunlap, le leader du projet :

CMI hopes to separate management of your code and content once and for all! We want to make it possible to store your site’s configuration in a standard API separate from its content, soliving issues like feature management and content staging that are cumbersome in previous Drupal versions.”

Mais ça ressemble à quoi ?

Il s’agit principalement d’une API fournissant aux développeurs une manière simple, standardisée, de stocker de la configuration de telle sorte qu’elle soit déployable.
Pour l’utilisateur final, cela signifie que nous sommes désormais capables de créer et configurer un site sur un serveur (de développement, de préproduction) et de le « déplacer » ensuite en production cette même configuration.

Pour bien comprendre le fonctionnement, il faut d’abord clarifier deux notions que CMI utilise : Active storage et Staging Storage.

  • L’Active Storage est un espace, par défaut la base de données, où Drupal stocke la configuration courante du site.
  • Le Staging Storage est lui un espace, par défaut le système de fichier, où Drupal stocke la configuration qu’il va devoir importer.

Chaque changement entre le Staging et l’Active peut être visualisé dans l’administration de Drupal.

Examinons ensemble un exemple d’un fichier de configuration, ici le fichier définissant le type de contenu « Book » :

type: book
name: 'Book page'
description: '<em>Books</em> have a built-in hierarchical navigation. Use for handbooks or tutorials.'
help: ''
has_title: true
title_label: Title
settings:
  node:
    preview: 1
    options:
      status: true
      # Not promoted to front page.
      promote: false
      sticky: false
      revision: false
    submitted: true
status: true
langcode: en

Comme on peut le voir, la configuration reste très compréhensible et facile à lire. Le plus important à comprendre est que ces fichiers fonctionnent sur un mode déclaratif.

Qu'est-ce que le mode déclaratif ?

Voyons ce que nous dit Wikipedia :

La programmation déclarative est un paradigme de programmation. Il consiste à créer des applications sur la base de composants logiciels indépendants du contexte et ne comportant aucun état interne. Autrement dit, l'appel d'un de ces composants avec les mêmes arguments produit exactement le même résultat, quel que soit le moment et le contexte de l'appel.

En programmation déclarative, on décrit le quoi, c'est-à-dire le problème. Par exemple, les pages HTML sont déclaratives car elles décrivent ce que contient une page (texte, titres, paragraphes, etc.) et non comment les afficher (positionnement, couleurs, polices de caractères, etc.). Alors qu'en programmation impérative (par exemple, avec le C ou Java), on décrit le comment, c'est-à-dire la structure de contrôle correspondant à la solution.

Autrement dit, en simplifiant, on pourrait dire :

  • Programmation impérative : décris à la « machine » comment faire quelque chose, et il en résulte ce que vous escomptez.
  • Programmation déclarative : décris à la « machine » ce que vous souhaitez qu’il se passe, et laisse la machine trouver comment y arriver

CMI n’est pas features !

Si vous aviez l’habitude (et vous devez l’avoir !) d’utiliser le module Features, vous serez peut-être un peu perdu au début. En effet, il ne faut pas oublier le but initial de Features était de pouvoir packager des « trucs » ensemble afin qu’ils puissent être réutilisés.
Ce n’est pas du tout le but de CMI. Ici, on exporte systématiquement l’ensemble de la configuration de votre site, et non pas une petite section.

Pour résumer, CMI est donc un outil permettant de gérer la configuration de manière déclarative, versionnable, et déployable.

Prochaine étape, la pratique !

Par Artusamak
Julien Dubois

Keynote de Dries – Drupalcon Austin 2014

La keynote que Dries a tenu pour le lancement de la nouvelle édition américaine de la Drupalcon 2014 à Austin se résume à se demander ce que sera le web de demain et comment Drupal pourrait jouer un rôle dans cet écosystème.

Drupalcon Austin 2014C’est une question intéressante à se poser lorsque l’on constate que de plus en plus d’acteurs venus à Drupal commencent à faire marche arrière faute de libertés suffisantes avec Drupal 7 et d’une arrivée très tardive de Drupal 8. S’interroger sur ce à quoi ressemblera le web dans quelques années est une chose, mais s’inquiéter de savoir si Drupal fera partie de ce tableau en est une autre. La réponse est probablement non.

Mais il est intéressant de constater que l’évolution à laquelle on assiste auprès des acteurs du web est que les géants deviennent de plus en plus géants et qu’ils écrasent complètement les nouveaux venus. Il va falloir que les gens acceptent de se rebeller contre ça pour que l’équilibre d’internet ne soit pas en danger.

Il est presque déjà trop tard, Google décide actuellement de ne plus montrer certains sites, qu’en sera-t-il demain lorsqu’il aura aspiré toutes les données de vos sites et les montrera directement dans sa page de recherche sans vous renvoyer le moindre trafic ?

Dries pose cette question et se dit que Drupal pourrait avoir un rôle à jouer en vous permettant d’avoir entre les mains un outil permettant de créer un genre de plateforme riche à partir de laquelle le contenu pourrait être disséminé facilement selon le format dans lequel vous le consommeriez (article sur un PC, billet sur votre téléphone, etc).

Je trouve que cette keynote a le mérite de mettre en lumière ce problème pour lequel nous n’avons pas forcément conscience mais je reste sceptique sur le rôle que Drupal pourra jouer. Le pouvoir réside principalement sur le trafic plus que sur les moyens technologiques à disposition pour formater le contenu et adapter le message au visiteur. Drupal n’a pas d’emprise sur l’acquisition du trafic et l’on peut légitimement se demander comment s’affranchir d’un Google pour faire venir les visiteurs. C’est un acte citoyen de s’interroger sur ce point et sur nos habitudes de consommation, la réponse n’est pas simple mais il faudra accepter de soutenir des petits acteurs prometteurs faute de tous les voir disparaitre les uns après les autres.

Par admin

DrupalFR au CMS day 2014

Comme pour la troisième édition, l'association Drupal France et Francophonie (drupalfr) sera présente le 17 juin 2014 au CMS Day.

Il s'agit d'un événement consacré à la gestion de contenu open source (CMS), dont nous somme sponsor Bronze.

Pour l'édition 2014, le CMSday proposera plus de 30 tables rondes et ateliers.
Bien entendu, tout au long de la journée, vous pourrez également venir nous rencontrer pour échanger et parler du CMS Drupal.

CMS Day

Il est impératif de vous inscrire gratuitement pour obtenir votre badge.
Inscrivez-vous au CMS Day 2014

Trouver un prestataire Drupal







Vous avez un projet de site web et vous avez déjà identifié Drupal comme solution idéale ? Mais vous avez des difficultés pour trouver un prestataire Drupal ? Comment vous assurer le prestataire sera en mesure de vous développer un site internet dans le respect des règles de l’art ? Bref comment trouver un prestataire Drupal, ou comment s’assurer que le prestataire dispose effectivement des compétences nécessaires à la bonne maîtrise de Drupal ? Ce billet va essayer de vous donner quelques pistes pour vous permettre d'éviter quelques mauvaises surprises.

Thème 
Drupal
Spécialiste
Prestataire

Pages