Internet
RESTful PHP : Designer SON API !
Submitted by fbenariac on Sat, 21/08/2010 - 15:40
REST, SOAP et autres sont a la mode en terme d'architechture web. Notamment en temps que part intégrantes d'une implémentation de SOA (Services Oriented Architecture). Ne connaissant ni REST, ni SOAP, ce livre avait pour but de corriger ce manque.
Finalement, ce livre est excellent. Il explique très simplement comment mettre en place un service REST et quelques exemple pour intégrer quelques services tel que Flickr ou Yahoo! Maps. Les exemples sont codés en php un peu « a l'arrache », pas forcement très propre, mais d'un autre coté, cela permet a l'auteur de rester simple et d'illustrer clairement ses propos.
J'ai été surpris par les exemples de codes... en effet, on pourait facilement pomper les bouts de code sans réfléchir. Sauf que les explication sont claire et donc on comprend dans la foulé. Les explications sont claires et précises, pas trop longues, ce qui fait qu'on a tendance a les lire aussi.
Je conseillerais grandement ce livre... mais ceci est un ouvrage pour les developpeur PHP. Si vous ne maitriser pas ce langage, cet ouvrage ne vous apprendra rien. (Notions XML utiles également !)
Environ 200 pages en Anglais.
jQuery UI. Passer votre chemin.
Submitted by fbenariac on Fri, 20/08/2010 - 13:28
jQuery est une bibliothèque javascript permettant d'intégrer des effets graphiques facilement. Elle est librement téléchargeable et intégrable. Simple d'utilisation, je cherchais un livre me permettant d'aller plus loin que les tutoriels que l'on peut trouver.
C'est pour cela que j'ai acheté ce livre. J'avoue avoir été deçu (par les deux). En fait, les tutoriels sont nettement plus complet et les auteurs tournent en rond souvent. Finalement, je n'ai rien approfondi du tout. A part les quelques bout de code intégrables sans réfléchir (de toute façon, ils sont très peu décortiqués), ce livre n'a pas d'intéret.
Environ 400 pages en Anglais.
jQuery : La base, pas plus.
Submitted by fbenariac on Fri, 20/08/2010 - 13:22
jQuery est une bibliothèque javascript permettant d'intégrer des effets graphiques facilement. Elle est librement téléchargeable et intégrable. Simple d'utilisation, je cherchais un livre me permettant d'aller plus loin que les tutoriels que l'on peut trouver.
C'est pour cela que j'ai acheté ce livre (package avec jQuery UI 1.6). Contrairement a ce dernier, ce sont les aspects plus fonctionnels qui sont abordées. Les développeurs y trouveront une bonne introduction... mais malheureusement pas beaucoup plus.
Environs 400 pages en Anglais.
SCRUM, MOA et MOE. Je m'y perd !
Submitted by fbenariac on Wed, 18/08/2010 - 16:10
C'est parce que je cherche un job que j'évite de poster sur mon blog. Pour éviter des conflits avec de futures opportunités entre ce que j'écris et ce que je pourrais faire. Par exemple quand je compare Google a Big Brothers et qu'ils me proposent un job, c'est normal que finalement, ça ne passe pas. Mais bon, comme je n'ai pas toujours le sens de la mesure, j'évite.
Aujourd'hui, j'écris sur un sujet d'étonnement, de notion que je mélange et pourquoi. En effet, j'ai fait pas mal d'entretiens d'embauche (j'ai du mal a trouver ce que je cherche). Bref, j'ai été confronté a des DRH et des chefs de projet qui mélangent SCRUM, MOA et MOE... et j'y comprend rien.
MOA/MOE : Truc made in France...
La MOA, maitrise d'ouvrage, représente généralement les utilisateurs finaux (internes ou non). La MOE, maitrise oeuvre, représente les geeks qui construisent le truc (DSI ou autre). Cette séparation entre les utilisateurs et les concepteurs est une invention purement Française qui fonctionne plutôt bien (dans l'industrie automobile en tout cas). Le problème dans l'informatique, c'est que la séparation entre les développeurs et le métier cible n'est pas imaginable. Les développeurs ne connaissent pas toujours les métiers pour lesquels ils développent. Cela entraine des décalages entre les attentes des clients (souvent concernant des éléments implicites liées a un métier.
Ainsi, la communication entre MOA et MOE entraine la production d'une quantité importante d'informations et documents divers...
Avec les quelques stages que j'ai pu effectuer, je me trouvais dans une autre situation. En effet, l'avantage que j'ai toujours eu, c'est de travailler pour un « client interne » la plupart des temps. Ainsi, en cas de doutes, une simple question (orale) suffisait a débloquer une situation.
L'agilité et SCRUM
SCRUM est a la mode en ce moment. Cependant, a part les développeurs, je ne suis pas certains que tout le monde emploi ce terme en sachant vraiment ce qu'il signifie...
En bref, SCRUM est une méthode permettant de mettre en place un cadre général. Cela défini des interactions entre les membres d'une équipe, aussi bien les développeurs que le client (ou le représentant des clients). Cette méthode favorise la communication plutôt que les outils. Pour faire simple, l'avantage de scrum est de faire en sorte que tout le monde communique ensemble pour construire quelque chose de fini plus rapidement et de manière plus efficace. Le principe le plus connu concerne les « itérations » qui visent a obtenir a chaque fois un livrable (qui pourrait être mis en production).
Il existe d'autres méthodes dans le même genre, appelées méthodes agiles, Extreme Programming entre autre.
Pourquoi je suis perdu ?
SCRUM et MOA/MOE ne sont pas vraiment compatibles. Ce qui me perd lors des entretiens, c'est lorsque l'on me précise que l'entreprise mélange ces méthodes... Le gros truc des méthodes agiles est de rapprocher les informaticiens des clients, au contraire des MOA/MOE. J'ai peur que certains comprennent seulement le principe des itérations, qui n'est qu'une petite partie des principes et cadres définies par les méthodes agiles.
Je pense que je me trompe, mais je n'arrive pas a obtenir plus d'informations... (si vous en avez, je suis preneur !)
On me parle également de prestation au « forfait », sauf que la aussi, cela me dérange. Comment fait-on pour définir une prestation avec un périmètre fixé a l'avance en choisissant d'utiliser une méthode agile pour les développements ?
Bref, j'ai encore pas mal de chose a apprendre !
Drupal Theming : Partir d’un thème existant ou pas ? Comment ?
Submitted by fbenariac on Thu, 25/03/2010 - 11:36
Le theming drupal n’est pas facile à comprendre quand l’on commence à s’y intéresser. En effet, certains conseillent de partir de rien et de construire son thème « from scratch » d’autres conseillent de partir d’un thème existant… mais ceux-ci sont souvent complexes pour une première approche.
Personnellement, je pense que partir d’un thème existant est la meilleure solution, sous certaines conditions. Il s’agit de partir d’un thème simple, de l’adapter à notre besoin et de ainsi comprendre de nouveaux mécanismes (que l’on n’aura pas forcément saisis dès le départ) et ainsi progresser pour appréhender des thèmes plus complexes.
Quel kit de départ choisir ?
Pour commencer, il faut se rappeler des bases !
En suite, il s’agit simplement de prendre un thème simple pour le modifier. Dans mon cas, j’aime utiliser le kit de départ « Basic » , en le modifiant un peu. Je ne garde que les fichiers « .tpl.php » et le dossier « css ». Je supprime les autres fichiers, renomme le fichier basic.info en fonction du nom de mon nouveau thème… et j’adapte son contenu à mes besoins. Par exemple je n’utilise pas les « features » car je considère que cela est bien pour des thèmes génériques mais pas pour un thème custom… Finalement, je garde le fichier « template.php » au départ, mais je le vide complètement.
En bref, déjà que ce kit de départ est simpliste, mais moi, je le nettoie encore de son code, selon moi superflu.
Certains conseillent d'utiliser le starter kit "Zen"... personnellement, je ne le conseil pas car il est complexe. En effet, les thèmes de départ, sensés être simples dépendent fortement du thème principal (dont en fait ils sont des "sous-theme"). Ainsi, le thème Zen est sympa, mais pas simple a exploiter. Si vous l'utilisez, vous constaterez que le thème drupal de ce blog ressemble a l'un des sous thème Zen... sauf qu'il est en fait construit avec une copie personnalisé par mes soins du thème "basic".
La structure des css
Le système d’organisation de drupal permet de remplacer les fichiers par ceux que l’on souhaite… en fait, par défault, drupal va utiliser ses fichier de gabarit a lui dans le cas ou le thème choisi n’en possède pas. Ainsi, on remplace en quelque sorte les gabarits du système par les nôtres en utilisant un thème spécifique. Ces remplacements concernent les fichiers « .tpl.php ».
Bien évidemment, nos gabarits utilisent nos feuilles de style (css) qui sont elle même contenu dans le répertoire du thème.
La structure des fichiers CSS est elle aussi un peu spéciale, mais terriblement logique et efficace. Cette structure permet de savoir tout de suite quel fichier est à modifier pour obtenir un style précis sur un élément du code html.
Dans le cas de notre thème de base, nous avons :
- css/default.css : contient les propriétés concernant la structure de la page (wireframe), c’est a dire les mises en formes génériques concernant les différents blocks html. Il est le cadre le plus haut et concerne les éléments tel que le header, le wrapper (content) et le footer.
- css/layout.css vient juste en dessous de default.css et affine les mises en forme en gérant les principaux blocks que sont les « sidebars », les régions, etc. Cependant, ce fichier contient surtout des propriété de positionnement des éléments les uns par rapports aux autres. Ce fichier contient des propriétés portant sur les id et classes laissés sur les balises html (#content, .sidebar, etc).
- css/style.css concerne quant à lui les balises html. On retrouvera ainsi les mises en forme de liens, etc…
Ces trois fichiers permettent de tout mettre en forme. En effet, on part de default.css pour une organisation générale du rendu. On passe en suite a layout.css pour mettre en forme les blocks de la page tel que les dimension et positionnement des « sidebars », pour finalement finir par les balises html. On constate que tout reste général. Cela permet de garder une cohérence sur tout le site. Cependant, dans le cas d’un besoin précis de mettre en forme un élément en particulier, je vous invite a le faire dans un nouveau fichier css que vous indexerez dans le fichier montheme.info pour qu’il soit pris en considération par « montheme ».
Outils conseillés
Pour ces manipulations, vous n’aurez pas besoins de logiciels spécifiques. Un « block note » avec une coloration syntaxique suffit (Notepad++, SciTE, Smultron, etc). La coloration n’est pas obligatoire, mais est plus confortable ! Pour vous aider dans le choix des éléments a mettre en forme et déterminer quelle propriété intervient sur l’élément concerné, je vous conseil d’installer le plugin pour firefox nommé firebug.
Créer un thème n’est pas très complexe, mais il faut savoir comment ils fonctionnent pour arriver à un résultat propre. Vous constaterez que je n’ai pas parlé de modification concernant le fichier template.php. En fait, j’utilise ce fichier essentiellement pour la suggestion de Template. Ce sujet sera abordé lors d’un prochain billet.
PHP vs DotNet
Submitted by fbenariac on Thu, 18/03/2010 - 16:05
Le journal du net fait un appel a contribution concernant la différence entre PHP et DotNET.
En lisant les témoignages, on se rend compte que ce sont deux mondes très différents, et que les gens ne peuvent pas être d’accord. Cependant, on constate aussi que personne n’a construit de réponses réellement argumentées. C’est ce que je vais tenté ici en proposant 3 éléments positifs et trois éléments négatifs de chacun.
DotNet
Points forts :
- Support Microsoft
- Communauté de développeur employés Microsoft
- Les entreprises pensent que parce que c’est payant, c’est mieux (en bref).
Points Faibles :
- Support des technologies tierces inexistant, et intégration super complexe voir impossible.
- Ne fonctionne QUE avec IIS.
- Fonctionne mal avec les clients non Microsoft.
PHP
Points forts :
- Libre
- Standard du développement d’application web
- Fonctionne sur toute plateforme
Points faibles :
- Les entreprises n’ont pas confiance dans les technologies libres…
- Langage de script
- Dépendance vis a vis de la société Zend
Conclusion
Personnellement, je n’aime pas DotNet… donc ce qui suis n’est pas vraiment des plus objectif ! Mais j’ai constaté, lors de collaboration avec des développeurs DotNet, que le code obtenu est plus rapidement crade qu’avec PHP. En fait, normalement, PHP permet plus facilement de faire n’importe quoi, mais comme les développeurs de ce langage le savent, ils sont nettement plus attentifs a cela.
Je n’ai sans doute pas rencontré les bonnes personnes. Cependant, les (autres) développeurs que j’ai rencontré sont souvent du même avis… pourquoi essayer d’utiliser une technologie propriétaire via sont outil libre Mono pour finalement se retrouver avec une application reposant sur le .net Framework, particulièrement connu pour ses bugs et failles de sécurité (assez simples a exploiter d’ailleurs). Quand je parle des bonnes personnes a rencontrer, c’est aussi parce que je ne connais pas aujourd’hui de développeurs qui travaillent sous environnement Microsoft. Et si j’en rencontre un, j’avoue que mes préjugés feront que j’aurais de sérieux doutes concernant ses compétences. C’est marrant, parce que j’ai l’impression que c’est le contraire en entreprise… (PHP en entreprise, c’est tabou, imaginez, c’est gratuit, libre et puissant !).
Le monde du libre permet de modifier un environnement du tout au tout. C’est cela qui fait sa force et qui nous permet de construire des applications robustes et performantes. Si on a besoin de quelque chose de précis, alors il est assez facile de construire l’outil pour cela, même si cela demande de modifier un applicatif du noyau du système d’exploitation. Essayez de faire pareil avec les produits Microsoft !
Un PC, un Macbook, une Time Capsule et une Livebox
Submitted by fbenariac on Wed, 10/03/2010 - 14:31
Je présente les personnages… cette étape est utile pour que vous puissiez comprendre mon utilisation de chacun. Le Macbook est mon outil principal, c’est avec lui que je fais tout ce que l’on peut faire avec un ordinateur, c’est un super outil (mais beaucoup de personnes ont tendance à oublier qu’un ordinateur reste un outil). Le PC est une tour acheté pas cher… je m’en sert comme d’un lecteur divx et dvd puisque fonctionnant sous Windows, il ne sais pas faire beaucoup plus. J’y ai installé Linux en dual boot pour remédier à cette incompétence. La Livebox est le modem ADSL fournit par le FAI Orange. La Time capsule est le routeur a disque dur vendu par Apple. Sur le papier, j’ai acquis ce dernier bidule pour remplacer le Wifi du système orange qui ne marche pas…
Ce que je voulais faire :
Ainsi, je voulais me servir de la Time Capsule pour remplacer les fonctions de routeur wifi de la Livebox. Honnêtement, Orange vend un truc qui ne fonctionne pas, et joue sur le support technique. Un gars s’est déplacé plusieurs fois pour tenter de voir ce qui n’allais pas dans l’installation, mais n’a rien trouvé, ce qui n’est pas rassurant. Pourquoi ne pas changer d’opérateur Internet ? Simplement, parce qu’en changeant, nous auront en face de nous plusieurs acteurs qui se renverront mutuellement la faute, sans pour autant changer le problème.
Donc je pensais que la box orange étant super mal faite, elle n’arrive pas gérer de multiples connexion en wifi… environ 4 portables, 2 desktop, et 4 autres appareil (PSP, iPhone, PS3, etc). L’air de rien, cela fait pas mal de matériel a connecter a internet.
L’idée était donc de passer la Livebox en simple modem (avec une super connexion, mais dans l’esprit des modems v92 à l’ancienne !), de brancher la Capsule a la box pour servir de routeur wifi et accessoirement de disque dur réseau.
J’ai essayé plusieurs méthodes pour cela. A chaque fois, j’ai planté la Livebox…
Ce que j’ai finalement fait :
Le problème est que je n’arrive pas à trouver pourquoi cela ne marche pas. Je ne peut donc pas contourner le problème et encore moins le résoudre (d’ou la constatation que la Livebox est une grosse dobe, mais les autres box sont-elles moins pires ?).
Finalement, la connexion « marchouille » en l’état (comme c’était avant). Donc entre plantage et fonctionnement aléatoire, j’ai choisi le fonctionnement aléatoire. Ma Time Capsule pouvant alors servir a autre chose. C’est la qu’interviennent mon Macbook et mon PC.
Le PC tourne sous Windows Vista (version bridée qui permet a peine de lire des DVD et d’aller sur l’Internet) avec un écran 24 pouces et une carte réseau wifi premier prix. J’y ai installé une version de Linux (la dernière Ubuntu). Le problème de linux depuis toujours selon moi, c’est le manque de driver. Dans ce cas précis, la carte réseau wifi n’est pas prise en compte (et ça me saoul de devoir passer par ndiswrapper).
Le Macbook tourne sous Mac OS X Snow Leopard. Le coté pratique de ce portable est que je peux partager sa connexion Internet. En gros, en connectant le PC au Mac avec un câble réseau, le PC dispose de la connexion internet (issue du wifi du Mac).
Et si on rajoute un câble réseau et que l’on met la Time Capsule au milieu ?
C’est ce que j’ai fait. Du coup, j’ai un mini réseau, connecté a internet. L’utilité n’est pas flagrante, sauf si je précise que j’utilise le PC comme serveur web de pré production et de teste. En effet, j’utilise une installation locale pour mes développements (sur le Macbook), mais les testes et recettages sont plus pertinent s’ils sont effectués sur une machine avec une configuration poche du serveur de production. Et puis les 1T d’espace de stockage sont confortables. En effet, je n’utilise pas la Time Capsule comme disque de sauvegarde (j’en ai un autre en USB pour cela), mais comme disque de stockage externe (notamment pour les films, photos et musiques). Donc l’aspect partage est important.
Pour ce qui est de la configuration de la Time Capsule, j’ai juste désactivé le wifi. Pour le reste, j’ai branché et cela fonctionne. Plus tard, en changeant d’opérateur internet, je rajouterais juste un câble réseau allant de la box a la Capsule (actuellement, je suis trop éloigné de la box). Peut être même que je réactiverais le wifi !
De nouvelles orientations pour le marketing web ?
Submitted by fbenariac on Tue, 16/02/2010 - 23:33
Jusque récemment, l'Internet était en grande partie un monde de partage d’information. Cependant, durant les dernières années, Internet est devenu de plus en plus social. Nous regardons maintenant des sites Web, des habitudes, et les comportements de nos pairs afin de prendre des décisions bien informés et instruits au sujet de notre prochain « mouvement », que ce soit une décision d’achat ou la lecture d’un article approuvé. Des sites Web comme MySpace et le FaceBook ont émergés pour rendre la communication entre les individus plus rapide et facile.
Des sites Web sociaux ont été établis pour unifier des individus avec des intérêts semblables :
- Sites sociaux de nouvelles qui sont régis par la « sagesse des foules »,
- Sites de « bookmarking sociaux » qui permettent à des individus de découvrir les sites Web qu'un grand nombre de personnes ont déjà découverts,
- Sites de réseaux sociaux qui unifient des individus sous un intérêt commun.
Maintenant il est clair que la tactique traditionnelle de vente n’est plus aussi efficace que par le passé, parce que la confiance du consommateur dans ces formes de médias a diminuée. Aujourd'hui, l'information est en ligne, plus accessible, et plus de manière significative. L'information est beaucoup plus facile à trouver. Les générations deviennent de plus en plus « numérique-intuitives ». La messagerie (email et SMS) et l'activité Web deviennent une deuxième nature. Si un consommateur cherche des informations sur un produit particulier, il ne s'assiéra pas nécessairement avec une tasse de café à lire son magazine préféré pour trouver des informations sur le produit… il mettra en marche son ordinateur et cherchera des revues et des commentaires d’utilisateurs, des individus « juste comme lui ».
Le marketing social est une technologie en évolution avec beaucoup de potentiel, et il y a des études de cas réussies pour soutenir ce sentiment. Cependant, les raisons de s'engager dans une stratégie de marketing social au lieu des stratégies marketing traditionnelles sont les suivantes :
- Le marketing social facilite la découverte normale de nouveaux contenus : Le contenu peut être exposé a des centaines de nouveaux visiteurs de site web, du surfer occasionnel a l’internaute extrême, d'une manière très spontanée. À la différence d’annonces payantes, les médias sociaux laissent le contenu a la vue des visiteurs. Cela n'est pas nécessairement associé à une intention commerciale. L'idée principale est : « Si j'aime un site web parce que le marketing est « léger », novateur et « légitime », je le passerai à mes pairs/amis en employant les médias sociaux et ils la passeront à leurs tours parce qu'ils l'aiment également… ». Le contenu peut atteindre énormément de nouveaux yeux rapidement sans interférer avec le marketing traditionnel.
- Le marketing social amplifie le trafic : Le trafic vient aux sites web par des sources autres que les moteurs de recherche, et plusieurs de ces sources incluent les sites sociaux. Une fois que l’entreprise s’établi comme un participant légitime de la communauté, les personnes qui suivent l’entreprise seront intéressées par ce que l’entreprise partagera et trouveront probablement pertinentes les vidéos de l’entreprise, ou ses articles de blog et les communiqueront peut être a leurs contacts.
- Le « Social Media Marketing » permet d’établir de forte relations avec les consommateurs : Si l’entreprise prête véritablement attention aux membres des communautés qui font partie de son message de vente ou de sa cible (ou même pas associé du tout), elle pourra établir des relations fortes si elle prend le temps de répondre aux soucis ou aux retours des individus. Même les communautés qui ne sont pas nécessairement liées à une entreprise, marque, produit ou offre de service ont des membres qui peuvent individuellement être intéressés quant à en savoir plus au sujet de l’entreprise et ce qu’elle a à offrir. Et puisqu'il est si facile de diffuser son message par l'intermédiaire du bouche à oreille en ligne, si l’entreprise laisse vraiment une bonne impression sur ceux avec lesquels elle communique sur une base régulière, il est presque certain qu'ils recommanderont l’entreprise à leurs contacts qui cherchent le service ou produit de l’entreprise.
Drupal - Theming : Anatomie d’un thème
Submitted by fbenariac on Mon, 15/02/2010 - 13:57
Les thèmes s’appuient sur un moteur de Template. Par défaut et dans 99% des cas, ce moteur de Template est PHPTemplate.
.info
Le fichier « .info » est obligatoire car c’est lui qui contient les paramètres de configurations :
- Métadonnées,
- Emplacement des fichiers CSS dédiés au thème (généralement, on a un layout.cssqui concerne les « boites » et un style.css qui concerne plus globalement toutesles balises),
- Emplacement des fichiers JS dédiés au thème (différents de ceux des modules),
- Les noms des régions, ‐ Les « Features » (Ce sont les éléments personnalisables dans l’interfaced’administration de drupal tel que l’affichage du logo, du slogan du site, etc...)
- Etc...
La version du thème est à négliger, voir oublier. Les informations concernant le drupal core et le moteur de Template utilisé sont obligatoires. Pour que le drupal core soit égal à la version utilisée, on ne tapera pas « 6.14 » par Exemple mais « VERSION ».
.tpl.php
Les fichiers d’extension « .tpl.php » sont les gabarits xhtml utilisés par le thème. Ils ne sont pas obligatoires et s’ils sont présents, ils viennent en remplacement de ceux du cœur de Drupal ou des différents modules. Le code PHP qu’ils contiennent doit se réduire que a la fonction « print ». Par défaut, on constate que certains thèmes comme Garland, zen ou d’autres contiennent également des conditions (if). Idéalement, ces conditions ne devraient pas apparaitre, sauf que dans le cas de ces thèmes, cela leur permet une plus grande généricité. Pour un thème fait « sur mesure », ces conditions sont inappropriées. Il en va de même pour les features du « .info » qui deviennent alors inutiles !
Tout autre élément « logique » écrit en PHP ET lié au thème sera à inclure dans un autre fichier (template.php par exemple).
Il y a cinq gabarits principaux :
- page.tpl.php, modèle principal des pages.
- node.tpl.php, modèle de construction des nœuds (node),
- block.tpl.php, modèle de construction des blocks,
- comment.tpl.php, modèle de construction des éléments liés aux commentaires,
- box.tpl.php, est cité comme étant le modèle de construction des boites, sauf quecelles-ci ne sont plus utilisées dans la construction des pages Drupal (depuis la version 6.x incluse !).
Il est possible d’utiliser d’autres fichiers de gabarit. Pour cela, on peut utiliser des noms de fichier réservés (tel que page‐front.tpl.php pour le gabarit de la page d’accueil) ou en spécifiant le fichier a utiliser dans le fichier template.php.
La version complète en VO est ici ! 
Drupal : introduction a un CMS a la mode.
Submitted by fbenariac on Mon, 15/02/2010 - 13:34
Drupal, pour ceux qui ne connaissent pas encore, c’est un CMS open source créé par Dries Buytaert. Cet outil a été plusieurs fois récompensé, notamment en 2008 (...). Aujourd’hui, c’est le CMS qui monte dans la communauté des développeurs Web Open Source. Je vous propose une petite présentation de Drupal et de ses principes de bases ainsi que des éléments qui font que j’accroche pour la première fois pour un CMS !
Drupal, c’est plus de 1 600 modules, et une communauté de 350 000 membres au 01/08/2008.
L’installation de drupal se fait en 3 secondes… juste le temps de créer une base de données avec MySQL (en standard) et de lancer l’installeur graphique. Certains geek linuxiens pourront même utiliser l’outil Drush (...) pour installer une instance de Drupal en ligne de commande à la manière commandes apt-get.
L’installation de drupal ne pose pas de problème et on dispose rapidement d’un site standard. On peut directement commencer à entrer du contenu. Ce qui est dans un premier temps assez déroutant, c’est que l’on confond le back office du front office. En fessant une analogie avec d’autres CMS tel que le vieillot SPIP ou encore les moteurs de blog tel que Wordpress, on a pas de réelle différenciation entre la présentation du front et celle du back. On peut cependant définir des thèmes différents pour la partie administration et la partie publique.
Vue de la surface :
Drupal s’articule autour de 3 « briques » : un système de base, des modules et des thèmes.
Le système de base est la partie intéressante du CMS. C’est en effet cette partie qui fait l’originalité du système. On pourrait le comparer a un noyau linux : c’est le cœur du système. Les développeur de Drupal l’on conçu de manière a ce qu’il reste ultra-performant.
Les modules sont assez rebutant à installer pour le néophyte car cela demande de naviguer dans les répertoires du site. Mais comme dirait la publicité Apple, « Si vous voulez faire un truc, il y a un module pour cela ! ». Drupal dispose d’un système de hook. Ce dernier permet aux modules d’être bien intégré au cœur du système. Pour schématiser le fonctionnement interne des interactions entre les modules et le cœur, quand un évènements se déroule, le système demande « Un module veut-il faire cette chose ??? », si un module répond oui, alors il le fera, sinon c’est le système qui gérera le truc. Les modules s’installent indépendamment du reste. Ainsi, la désinstallation d’un module n’entraine pas de suppression en cascade des données, mise à part celle concernant le module lui même. Par exemple en installant un module de galeries d’images, en le désinstallant, on supprimera les galeries créer, mais pas forcement les images qui ont été créées et qui dépendent d’un autre module. Une solution intermédiaire est également proposé et consiste en la désactivation du module… sans impact sur les données qui seront en quelque sorte dépubliées.
Vue de la surface le système de thème est très performant. Il constitue en quelque sorte un super module a lui seul. J’aime beaucoup le système de région. Il permet de choisir d’affecter des blocks à une région et de choisir les pages sur lesquelles on souhaite l’afficher ou non et/ou en fonction de quel rôle d’utilisateur également.
Le dernier point intéressant lors d’une approche rapide de ce CMS concerne justement la gestion des permissions et des rôles des utilisateurs. En effet, on peut ajouter des rôles et leur affecter des permissions d’accès spécifiques. On peut ainsi créer un site de création de contenu communautaire et avoir des rôles tels que le visiteur (internaute standard, on inscrit), l’utilisateur, le modérateur, le contributeur, le super contributeur, le webmaster et l’administrateur. Par défaut, il y a deux rôles : l’utilisateur enregistré et l’utilisateur non enregistré… ainsi que un troisième rôle implicite d’administrateur (qui est défini par le compte créé lors de l’installation du site).
Sous la surface : une plongée (en apnée) dans le code.
Comme tout CMS, Drupal dispose d’une logique bien a lui. Cela se reflète dans la manière dont le code a été écris et dans la manière dont il faut l’écrire. Les premiers coups d’œil rapides sur les sources peuvent faire peur…
Ainsi par exemple, ce CMS n’est pas codé selon les méthodes dites Object… Cela m’a surpris au départ. Cependant le système de hook est implanté de telle manière que finalement, on s’y retrouve, même si cela peut prendre du temps. En fait, on s’aperçoit très vite que l’on n’aura généralement pas besoin de coder un module à partir de rien. Vu le nombre de module existant, il y en a toujours un qui fait a peu près ce que l’on souhaite. Il s’agit alors d’adapter ce qui existe à notre besoin. Par contre, si on ne trouve pas ce que l’on cherche, la tâche peut vite devenir lourde…
Le theming et le développement de module sont deux chose bien distinct dans le monde Drupal. Au départ, ce n’est pourtant pas évidant à saisir. En effet, certains modules vont géré la manière d’afficher certaines données… venant en quelque sorte parasiter le thème choisi. Mais dans se cas, l’affichage de ces données se fera de la même manière quelque soit le thème.
De plus, on constate que Drupal a adopté une approche MVC selon les sources officielles… Personnellement, j’ai toujours pensé que ce système MVC permettais a des acteurs ayant des profils différents de travailler ensemble a la réalisation d’un site web. Or il sera bien difficile a un graphiste ne maitrisant pas un minimum PHP d’intervenir sur Drupal.
Bref, les contacts avec les sources ne sont pas forcements simples. Cela demande en effet la lecture de nombreuses documentations pour comprendre le fonctionnement du système.
En conclusion :
Drupal est le CMS à la mode en ce moment. Il permet de faire quasiment tout ce que l’on veut via un système de gestion de modules assez redoutable et un système de thèmes performant.
L’avantage de ce CMS est d’être extrêmement modulaire et de pouvoir fonctionner aussi bien en temps que CMS (normal, c’est son objectif premier) mais également un peu comme un Framework PHP lorsque l’on maitrise son architecture interne et son système d’API.
Pour les néophytes débrouillés, il permettra de programmer un site web au moyen de la souris… ce qui est rebutant pour le développeur plus confirmé !
D’ailleurs, c’est sans doute ce dernier qui aura besoin de plus de temps pour apprivoiser Drupal. Le système de hook est bluffant mais encore faut-il le maitriser…
Drupal semble pouvoir tout faire mais a condition de rester quand même dans une réalité proche… d’abord pour qu’il y ai dans la communauté quelqu’un qui ai développer LE module dont on a besoin et en suite pour que le thème que l’on ai choisi nous convienne et que l’on ai pas besoin de trop le modifier.
Ce billet n’est qu’une introduction. Pour vraiment comprendre pourquoi j’aime bien cet outil, il faudrait que je mentionne le développement de module ainsi que le theming (dans des futurs billets !). Cependant, mes premières impressions étaient celles décrites ici !
