Christophe Le Bot

  • Navigation rapide
Pratique de la conception numérique

Derniers commentaires

  • Une excellente thèse sur Simile Exhibit
    • Olivier Rossel | Bonjour. Malgre les annees, avez vous toujours en memoire vos usages d’Exhibit? Je serais ravi d’en discuter avec vous. Cordialement, Olivier Rossel.
  • Utiliser le planificateur de tâches OVH (crontab) avec PHP
    • Max | Bonjour, comme faire pour appeler une version de PHP qui n’est plus proposée par défaut dans le manager ? J’essaie de lancer un cron avec php 5.3 mais le log affiche No such file...
    • Christophe | @absolument Merci pour ces précisions. Je n’ai pas mis en place de tâches cron récemment, mais j’ai reçu quelques notifications étranges d’OVH il y a quelques...
  • Récupérer le dernier auto-incrément MySQL avec PHP
    • Thy | Sujet toujours *très* utile en 2015 ! Je réponds à Serge tsimba qui récupère un « Resource id ». (Et à tous ceux qui ont le même souci mais qui ne le disent pas) :)...
  • Régler l’heure de serveurs virtuels sous Debian
    • Ares_XL | Il semble que sur Débian la commande « tzconfig &ra quo; soit dépréciée et remplacée par : « dpkg-reconfigure tzdata » elle donne accès à une...
 

Archives de la catégorie
Développer

Utiliser le planificateur de tâches OVH (crontab) avec PHP

Site web OVH

De nombreuses applications web ont besoin d’exécuter périodiquement des scripts pour réaliser des tâches automatiques : purge de logs, traitement de données, lancement de sauvegardes… Quand vous avez la main sur votre propre serveur, tout va bien : vous utilisez les crontabs. Mais quand vos applications sont hébergées sur un serveur mutualisé, c’est déjà moins accessible !

Heureusement certains hébergeurs proposent des solutions alternatives efficaces. C’est le cas d’OVH avec son Planificateur de tâches. Une aide officielle existe, mais sans être inexacte, elle est un peu rapide. Du coup, j’ai passé plus de temps que prévu pour que tout fonctionne à merveille. Voilà comment s’y prendre.

Préparer son script PHP

Première étape : préparer le script de traitement PHP qui sera appelé par la tâche planifiée. Pour que le serveur appelle le bon interpréteur (dans notre cas PHP), le script a besoin de le définir en première ligne. Il faut donc ajouter cette ligne à votre script PHP :

#!/usr/local/bin/php

Elle se place en tout premier. On obtient donc ceci :

#!/usr/local/bin/php
<?
// La suite de mon script PHP...

Si vous avez besoin d’appeler d’autres scripts PHP ou de manipuler des fichiers, n’oubliez pas de travailler avec des chemins absolus. Par exemple en utilisant une variable qui définit l’endroit où est placé votre script :

$path = dirname(__FILE__);

Une fois votre fichier PHP placé sur le serveur, il faut lui ajouter le droit d’exécution (avec votre outil FTP, par exemple). Par défaut, les droits des fichiers sont calés en lecture + écriture (604), vous devez obtenir les droits en lecture + écriture + exécution (705).

Planifier la tâche

Côté serveur, c’est fini. Maintenant, il faut planifier la tâche. Pour cela, nous passons par le Manager OVH (ou Espace client, depuis peu). Le Planificateur de tâches est caché derrière Mutualisé > Hébergement > Services web.

Manager OVH - Crontab

Lors de l’ajout d’une tâche, nous devons définir ses propriétés :

  • Description de la tâche
  • Script à exécuter (chemin depuis la racine FTP de votre espace mutualisé)
  • Langage de script (avec le choix très important de la version de PHP à exécuter)
  • Logs par e-mail (permet de recevoir par e-mail un log de l’exécution du script)
  • Activation
  • Périodicité

L’interface est si simple que je n’ai rien à expliquer !

Propriétés d'une tâche planifiée OVH

Une fois validée, la tâche sera exécutée comme vous l’avez prévu. Enfin presque… Deux écarts constatés avec la théorie :

  • La mise en place de la tâche planifiée est parfois longue (j’ai dû attendre plus de 24h sur un de mes sites avant de la voir tourner).
  • Elle s’exécute rarement à l’heure prévue (la pile d’exécutions doit être longue, du coup j’atteins parfois des décalages de 20 à 30 minutes).

Suivre l’exécution de la tâche

Une fois tout ça en place, ça devrait tourner tout seul… Je suppose que vous testerez bien votre script d’abord, mais on n’est pas à l’abri de surprises à l’exécution. OVH vous offre donc les logs par e-mail ! La fonctionnalité est proposée dans le Planificateur de tâches et limitée à 10 envois (on peut la réactiver à la demande si besoin).

Vous recevrez alors un message du genre :

Vous avez demandé l'envoi des logs pour la tâche :

Numéro            : 123456
Heure de début    : 2013-10-08 02:21:02
Heure de fin      : 2013-10-08 02:21:19
Commande exécutée : /usr/local/bin/php.ORIG.4 -c /usr/local/lib/php.ini /[path]/[file].php
Code de retour    : 0
[...]

-------------------------==  Début  ==-------------------------

X-Powered-By: PHP/4.4.9
Content-type: text/html

#!/usr/local/bin/php

-------------------------==   Fin   ==-------------------------

Si tout se passe bien, rien de plus. Sinon, vous aurez une trace d’erreur. Un exemple avec un script qui tente une opération interdite sur un fichier gunzip :

-------------------------==  Début  ==-------------------------

X-Powered-By: PHP/4.4.9
Content-type: text/html

#!/usr/local/bin/php
gzip: /[path]/toto.gz already exists;        not overwritten

-------------------------==   Fin   ==-------------------------

Et la sécurité ?

J’ai trouvé quelques didacticiels sur le Planificateur de tâches OVH. Certains sont très détaillés (encore plus qu’ici), mais aucun n’aborde le sujet de la sécurité. Pourtant, la question est vraiment capitale chez OVH. En effet, votre espace web sur le serveur mutualisé a pour objectif de diffuser des contenus publiquement sur le web. C’est sa fonction première ! Donc, si vous placez un script maladroitement sur votre serveur, d’autres pourront jouer avec.

Un exemple que j’ai vu : un dossier mysql à la racine d’un site, contenant un script backup.php qui génère un fichier dump.sql au même endroit. Autant dire qu’il y a 99% de chances qu’un hacker du dimanche récupère vos données confidentielles dans l’année ! Remarquez que ce type de didacticiels n’est pas forcément innocent… Si 2000 personnes suivent l’exemple à la lettre, c’est d’autant plus facile pour des gens mal intentionnés. Lisez les didacticiels avec un peu de recul !

Parmi les règles de protection efficaces :

  • placer votre script dans un dossier racine qui n’est pas couplé à un sous-domaine (donc inaccessible par le web)
  • si votre fichier appartient à un dossier accessible sur le web, ajouter un fichier .htaccess pour interdire sa lecture et son exécution (directive Deny from all, par exemple)

Une traçabilité fine pour un pilotage global

« Tu as besoin de combien de temps sur cette tâche ? »

Quand on vous pose cette question, vous répondez toujours avec certitude et exactitude, sans qu’il y ait de remise en cause de votre engagement en fin de projet, n’est-ce pas ? Dites-moi oui et je ne vous croirai pas !

Même si les méthodes de gestion de projets donnent des indicateurs satisfaisants, notamment en approche agile, les écarts sur certaines tâches restent problématiques. Les raisons sont multiples : besoins imprécis, évaluation partielle du travail technique, mauvaise compréhension des objectifs, compétences inadaptées, planification défaillante… Si vous cumulez tous ces exemples, ce n’est pas gagné ! Mais en général, c’est plus pernicieux. Tout semble rouler… à part quelques tâches par ci, par là. Celles qui vont grignoter votre marge si difficile à atteindre !

Alors, ne peut-on vraiment pas faire mieux ? Avec une démarche d’amélioration continue, si.

Mais c’est quoi, ce temps qui file ?

J’ai vécu un projet un peu difficile (c’est le moins qu’on puisse dire…) qui m’a poussé à trouver une solution efficace. Sans prétendre vous donner les recettes miracles du projet calé à la minute près, je vous présente simplement un exemple d’approche qui a remis le projet sur les rails et assurer un pilotage de grande précision.

Ce projet, c’est celui de la rédaction de mon livre Magento. Il avait toutes les caractéristiques du projet foireux :

  • Première expérience dans la rédaction d’un ouvrage de référence.
  • Sujet récent qui manquait d’informations de qualité.
  • Projet personnel réalisé en dehors des heures de travail.

Autant dire que mon évaluation de départ n’était pas réaliste : 7 mois de travail qui en sont devenus 14. Mais le pire, c’est qu’après cinq mois, je n’avais toujours pas mesuré qu’il m’en restait 9 ! Le gros du boulot me semblait bien avancé, mais les finitions allaient s’avérer interminables : relecture, corrections, création de l’index, des schémas et des images…

D’où vient le problème ?

Si le projet était personnel, je devais néanmoins le caler avec la feuille de route de mon éditeur. Au fur et à mesure de la rédaction, mes estimations s’affinaient, je connaissais le temps de rédaction pour 100 lignes, le nombre de copies d’écrans réalisées en une heure, le temps de relecture d’un chapitre… Mais, le résultat n’était pas assez précis. Je n’arrivais pas à déterminer les priorités et je débordais souvent. Sans doute à cause de ces milliers de micro-tâches de quelques dizaines de secondes éparpillées dans 550 pages.

Bon sang, mais c’est ça le problème ! Ces micro-tâches, prennent-elles 10 ou 20 secondes ? Sont-elles 200 ou 500 par chapitre ? Voilà les bonnes questions !

Tracer au plus fin

Il fallait trouver le moyen d’évaluer la moindre tâche. Pourtant, on le sait : tout mesurer est inutile et coûteux. Eh bien, non ! C’est même ce qui m’a sauvé. L’astuce a consisté à placer un marqueur dans le texte dès qu’une tâche était identifiée. Ce marqueur permettait de connaître le type de travail et le temps estimé pour le réaliser.

Une image à faire, un marqueur. Une phrase à revoir, un marqueur. Un paragraphe à rédiger, un marqueur. Une page à relire, un marqueur. En quelques jours, j’avais mes milliers de marqueurs… et un premier résultat redoutable : je voyais sous mes yeux le reste à faire presque au double de mes estimations !

Après la douche froide, ce fut un vrai plaisir. Les temps estimés étaient respectés, l’analyse des grands lots très précise, la feuille de route bien tracée. Je pouvais organiser mon travail selon mes disponibilités : « Une heure de libre ? Ah tiens, je peux faire les 7 corrections du chapitre 12 et les livrer à l’éditeur ».

Et en pratique, ça donne quoi ?

Mon éditeur m’a laissé le choix des armes : Word ou OpenOffice. Si vous avez déjà tenté de rédiger un ouvrage de quelques centaines de pages sous Word avec un sommaire, des illustrations et des index, vous comprendrez vite pourquoi j’ai choisi OpenOffice, beaucoup plus fiable et adapté aux documents volumineux et structurés. D’ailleurs, l’ouvrage a tenu 14 mois dans OpenOffice sans un seul bug ! Ce que je dis là est valable pour LibreOffice, bien entendu.

Grâce à la recherche par expression rationnelle (regexp en anglais) d’OpenOffice, j’avais de quoi poser des marqueurs dans le texte et les extraire pour analyse. J’ai donc imaginé une nomenclature simple pour décrire les tâches :
-TODO [priorité] [type] [chapitre] [charge] [commentaire] TODO-

  • -TODO : début de marqueur
  • [priorité] : indicateur de priorité (A ou B)
  • [type] : type de tâche (rédaction, création de figure, correction, relecture, etc.)
  • [chapitre] : numéro du chapitre
  • [charge] : temps estimé en h
  • [commentaire] : pour savoir quoi faire
  • TODO- : fin de marqueur

Voici un exemple :

-TODO A WRITE C19 0,4 exemple getData() getDemoName() TODO-

Ce marqueur indique une tâche prioritaire (A) concernant la rédaction (WRITE) dans le chapitre 19 (C19) pour une charge de 0,4h. Le commentaire précise qu’il faut rédiger un exemple d’utilisation de deux méthodes (exemple getData() getDemoName()).

Marqueurs de tâches dans OpenOffice
Exemples de marqueurs de tâches dans une page sous OpenOffice.

La regexp suivante me permettait d’extraire tous les marqueurs du document :

-TODO .* TODO-

Recherche par regexp
Recherche des marqueurs de tâches dans le document OpenOffice.

Le résultat était récupéré dans le tableur OpenOffice Calc pour faire toutes les analyses possibles : temps de charge par chapitre ou par type d’activité, pourcentage d’avancement des chapitres, charge par priorité, etc. J’étais enfin dans le concret !

Liste des tâches dans le tableur
Liste des tâches dans le tableur.
Tableau croisé dynamique de la charge
Tableau de la charge par chapitre et par type d’activité.
Graphique de la charge
Graphique de la charge par chapitre.
Graphique des taux d'avancement
Graphique des taux d’avancement par chapitre.
Graphique de priorité
Graphique des priorités et de la charge par chapitre. Sans doute l’outil le plus utile pour prendre les bonnes décisions.

Et ça marche pour tout ?

L’énorme avantage de ce système, c’est d’affiner au fur et à mesure les estimations de charge des tâches. Le temps réel est facilement comparable au temps estimé, directement sur chaque marqueur du document de travail. Par expérience, on est donc de plus en plus précis sur les estimations des tâches qui se ressemblent.

Peut-on extrapoler ce principe à d’autres activités ? Oui, mais pas toutes. La rédaction d’un ouvrage est une activité particulière, assez « linéaire » : il faut remplir le contenu page après page. D’autres activités nécessitent des tâches plus imbriquées, plus diversifiées. Dans ce cas, il est difficile d’utiliser des marqueurs communs dans des outils et contenus différents.

A mes yeux, il existe une activité pour laquelle l’approche est pertinente et efficace : le développement informatique. Depuis très longtemps, les éditeurs de code acceptent des marqueurs pour gérer le travail des développeurs. Il y a même le fameux @todo pour lister les tâches à réaliser ! Alors pourquoi ne pas aller jusqu’au bout ? Dans les solutions complexes comme Magento, il n’est pas toujours facile d’estimer l’ensemble des micro-tâches autour du développement d’un module : implémentation des méthodes, optimisation des objets, modification des interfaces, calage des feuilles des styles, optimisation des performances, refactorisation, tests, etc.

Grâce à vos marqueurs, vous verrez bien plus vite qu’un module presque terminé nécessite encore le double de travail ! L’inverse est vrai aussi : quand vous allez plus vite que l’estimation, vous le voyez plus tôt, ce qui vous permet d’optimiser votre plan de charge ! Et les développeurs sont heureux : ils n’ont pas à sortir la tête du code pour faire leur compte-rendu au chef de projet 😉

Agile Tour Toulouse 2011

Le mercredi 19 octobre 2011, l’association SigmaT organise l’étape toulousaine de l’Agile Tour.

Agile Tour Toulouse a pour objectif d’être une journée de formation, d’échange, de partage d’expérience, de réflexion et de rencontre autour de l’agilité.
En 2010, pour la 3e édition, plus de 250 personnes ont assisté à la conférence.

Suite au succès des trois précédentes éditions, la journée aura lieu cette année à l’espace de congrès Diagora :

  • Un amphithéâtre de plus de 500 places pour les sessions plénières
  • Trois salles dédiées pour les ateliers et les sessions en parallèle
  • Un espace de plus de 500 m2 – la Place – où seront situés les stands des sponsors
  • Un espace salon de discussion ainsi qu’un buffet traiteur

Toutes les informations sont sur le site dédié à l’évènement :

http://agiletoulouse.org/

Livre Magento : ça, c’est fait !

Après 7 mois d’absence sur ce blog, me voici de retour ! Ce fut pour la bonne cause : mon livre consacré à Magento est maintenant terminé, imprimé et distribué par tous les bons libraires. Pour en savoir plus, je vous invite à consulter la page officielle de l’ouvrage sur le site de l’éditeur Pearson et la rubrique dédiée sur mon autre blog Magentips.

Une bonne chose de faite et du temps à ne plus savoir qu’en faire pour mon blog !

Je souffle un peu d’abord et je reviens avec plein de sujets intéressants. Le web bouge encore et toujours à toute vitesse !

Le guide pratique Scrum bientôt dans les bacs

Encore 9 jours de patience avant de découvrir un livre très attendu : Scrum, de Claude Aubry, chez Dunod. Les méthodes agiles ont le vent en poupe et les précurseurs, comme Claude, ont maintenant suffisamment de recul et d’expérience pour nous expliquer Scrum avec beaucoup d’efficacité et de pédagogie.

A lire sans retenue !

Si après ça, vous n’êtes pas convaincus, je ne sais plus quoi faire. Ah si, venir aux ateliers du SigmaT (dont Claude Aubry est le président !). Le prochain est mercredi 3 février et ce sera un XP Game, parfait pour découvrir l’efficacité d’une démarche agile.

Sauvons MySQL !

Save MySQL

En janvier 2008, le rachat de MySQL AB par Sun fut un événement majeur et plutôt bien accueilli. Mais l’ambience était tout autre après le rachat de Sun par Oracle. J’émettais de fortes réserves sur la survie de MySQL dans le giron de l’ambitieuse société californienne.

Les craintes se sont confirmées et une grande bataille se joue en ce moment pour sauver MySQL. Michael « Monty » Widenius, le créateur de MySQL, a lui-même tiré la sonnette d’alarme en décembre et a anticipé les problèmes que vont rencontrer les utilisateurs de MYSQL.

Sans réponses claires et pérennes d’Oracle, la communauté s’organise et une pétition a été lancée pour convaincre les pouvoirs publics et les autorités de régulation des marchés d’étudier le cas de la fusion Oracle-Sun-MySQL. Libre à vous de décider de l’avenir de MySQL, mais le danger est, à mon avis, bien réel. J’attends d’être convaincu du contraire…

Pour en savoir plus : Save MySQL !

Barcamp PHP toulousain : la synthèse

Bacrcamp PHP Toulouse

Jeudi dernier se tenait le Barcamp PHP Cheese & Wine. Même si le vin et le fromage ont été très appréciés, nous n’étions pas venus (seulement) pour ça. Alors pour les absents qui ont eu tort de l’être, voici une petite synthèse de cette longue soirée.

Un vrai barcamp

Premier bon point : c’est un vrai barcamp où les participants se présentent et définissent le contenu des ateliers. Tous les barcamps ne respectent pas cette règle de base… Xavier Gorse, président de l’AFUP, a donc joué le rôle de « maître de cérémonie » pour établir le programme d’après les souhaits de chacun  :

  • PHP et sécurité
  • PHP 5.3
  • Déploiement d’applications PHP
  • PHP et les bases de données « NoSQL »
  • Outillage PHP
  • PHP et testing
  • Frameworks PHP

Pour ma part, j’ai participé aux ateliers :

  • Déploiement d’applications PHP
  • PHP et les bases de données « NoSQL »
  • PHP et testing

Je limite donc mon article à ces sujets, sachant que d’autres synthèses ont déjà été publiées :

Déploiement d’applications PHP

Cet atelier a mis en évidence la difficulté de déployer des applications web en général (technologies nombreuses et environnement hétérogène). Tous les outils existants ont été passés en revue, du paquet Linux (.deb) aux outils spécifiques à PHP (PEAR, Phing, Phar) en passant par des intermédiaires parfois plus adaptés (makefile, Puppet, Capistrano, Ant). Deux groupes de participants étaient clairement représentés, avec des besoins très différents :

  • Déploiement d’une solution sur un parc important et hétérogène (cas des éditeurs de solutions, comme Linagora avec OBM)
  • Déploiement d’un projet sur-mesure sur un ou quelques serveurs, mais très fréquemment et avec des contraintes d’intégration de contenus externes (cas des agences web, avec plusieurs déploiements par jour).

Dans le premier cas, la difficulté est d’identifier la configuration des serveurs cibles et de préparer les paquets d’installation correspondants (.deb pour chaque distribution Linux, .msi pour chaque version de Windows, etc.), tout en assurant la compatibilité des données sans toujours les connaître (tests de régression).

Dans le second cas, il faut savoir intégrer pendant le déploiement les données du site en exploitation (base de données, templates gérés par un web designer externe, etc.), avec d’éventuelles transformations (ETL, Extract Transform Load).

J’ai ajouté qu’un déploiement ne se limite pas à la livraison de la partie applicative mais doit aussi savoir traiter la mise à jour des outils liés au projet (plate-forme de gestion de tickets, extranet, feuille de route, tests, sauvegardes, alertes, etc.).

En dehors de PEAR, trés utilisé et qui est un outil de déploiement à l’origine, j’ai une préférence pour Ant + Phing et Capistrano.

Bases de données « NoSQL »

Là, on entre dans une autre dimension. Les bases « NoSQL » sont des bases de données non relationnelles. En gros, on ne retrouve pas le schéma habituel « tables contenant des champs et étant reliées entre elles ». L’avantage est d’obtenir des performances exceptionnelles sur des entrepôts de données énormes. Parmi les acteurs majeurs qui développent et utilisent des bases « NoSQL », on peut citer : Google (projet Big Table qui a inspiré le projet Cassandra), Facebook ou Linkedin.

Si on revient à la dure réalité d’un acteur de dimension modeste, on constate que ces technologies émergentes et prometteuses sont encore très spécifiques. Les bases relationnelles ont de beaux jours devant elles. La difficulté est notamment de réintégrer dans l’application PHP ce qui fait la force des systèmes SQL : sélection, jointures, intégrité référentielle, etc. Le volet testing des projets en prend un coup…

PHP et testing

Atelier en petit comité (6 personnes), en concurrence déloyale avec l’atelier Frameworks qui a fait le plein ! Nous avons tenté de lister les types de tests liés à une application web, en dépassant autant que possible la simple vue du développeur :

  • Tests unitaires (PHP et Javascript)
  • Tests fonctionnels
  • Tests d’IHM (via Selenium Core, Selenium RC et Selenium IDE)
  • Tests de recette
  • Tests de non régression
  • Tests de performance
  • Tests de charge
  • Tests de conformité (normes, W3C, accessibilité, etc.)
  • Tests ergonomiques (tri par cartes, paper prototyping, tests utilisateurs, etc.)
  • A/B testing

Les échanges sur nos expériences ont été très instructifs. Nous étions tous d’accord pour insister sur la définition précise des cas d’utilisation qui facilite la gestion des tests pendant toute la durée du projet avec le client. D’où une phase de spécifications sérieuse qui conditionne la qualité du travail livré. Certains tests peuvent faire l’objet de validation contractuelle, comme les wireframes issus de tests ergonomiques qui servent ensuite de feuille de route aux intégrateurs et développeurs.

La difficulté avec les tests, c’est de savoir placer le curseur pour ne pas s’y noyer. Il n’est pas réaliste d’appliquer les tests de façon exhaustive. C’est un idéal en contradiction avec les budgets et les délais imposés en pratique. Il faut donc savoir réaliser les bons tests, au bon endroit et au bon moment. Par exemple, sur le calcul des prix d’un panier de site e-commerce, sur l’intégration des données lors d’un couplage entre deux systèmes, sur l’ergonomie d’une interface riche, etc.

En résumé

Une excellente soirée qui a largement dépassée les 5 heures prévues ! L’accueil de Linagora et de l’AFUP était parfait, l’ambiance très sympathique et le niveau des échanges très pointu. Il y a des gens qui savent faire des choses avec PHP en Midi-Pyrénées ! Je pense qu’on remettra ça sous peu. Prochaine étape : le Bargento, lundi 9 novembre à Paris. Je serai présent avec l’équipe de l’AFUP pour organiser et animer cette journée qui s’annonce exceptionnelle. Et à la suite, le Forum PHP 2009, tout aussi exceptionnel. Sur ce coup-là, je déclare forfait. Il faut bien travailler un peu !

L’Agile Tour 2009 à Toulouse le 22 octobre

Agile Tour 2009

L’Agile Tour est de retour à Toulouse ! Le principe reste le même : faire découvrir les méthodes agiles et partager les retours d’expérience de leur application sur des projets réels.

L’édition 2008 a été un réel succès, alors ne boudez pas celle de 2009 ! L’efficacité des organisateurs et un contenu riche et utile vous rempliront la tête d’idées.

Ce sera le 22 octobre toute la journée, mais pas au même endroit que l’an dernier. Hélas ! Je ne pourrai pas m’y rendre, c’est une catastrophe… Heureusement, les comptes-rendus sont toujours complets, avec une copie des présentations faites à l’assistance. Que du bon en somme.

Informations et inscription : Agile Tour 2009

Magentips, mon nouveau blog Magento

Magentips

Il y a deux ans, quand j’ai commencé à mettre le nez dans Magento, il n’y avait rien ou quasiment rien sur le web pour traiter le sujet. Alors j’ai toujours eu l’idée d’un blog pour centraliser l’information pratique au quotidien. Mais comme souvent, les autres priorités ont gelé cette initiative assez rapidement…

Depuis, il s’est passé beaucoup de choses autour de Magento. De nombreux sites dédiés ont fleuri et m’ont fait douter de l’intérêt de créer un YABAM (Yet another blog about Magento). Alors tout cela est resté dans un carton, à moitié achevé, pendant une dizaine de mois.

Et pourtant, voilà Magentips ! Comme quoi tout arrive. Je doute de ma disponibilité pour en faire le YABAM le plus riche de la planète, mais je souhaitais partager mes expériences Magento en dehors des sentiers battus et des premières évidences. La page A propos détaille cela.

Je vois donc cette initiative personnelle comme un complément à des outils existants. Certains partages de contenu se feront donc naturellement vers des sites de référence comme le blog français officiel Magento, Fragento et Wikigento. Comme dirait Philippe Humeau (Wikigento), « on peut œuvrer ensemble dans le même sens, sans perdre son indépendance et sa liberté de ton ».

Bienvenue sur Magentips !

Vous pouvez aussi retrouver Magentips sur Twitter.

Barcamp PHP à Toulouse le 29 octobre

Bacrcamp PHP Toulouse

Linagora GSO, société spécialisée dans les Logiciels Libres, organise avec la participation de l’AFUP (Association Française d’Utilisateurs de PHP), son premier Barcamp sur le thème de PHP autour d’un Cheese and Wine.

Une bonne occasion de voir ce que le Sud-Ouest est capable de faire avec PHP, le tout chez mes amis de Linagora. Une excellente soirée en perspective !

> Informations et inscription