Archives mensuelles : janvier 2008

Plugin wordpress pour le Nabaztag

non-french speaker disclaimer :
Sorry I’am too lazzy to manage an english translation. Don’t hesitate to insult me via the comment field in order to give some motivation. :-p

Dans la catégorie ça sert à rien mais on adore ! Voici un plugin pour installer un formulaire sur une page ou un article wordpress vous permettant d’envoyer des messages vers un Nabaztag.

Il s’installe comme tous les plugins et propose un écran de configuration et un mot spécial (SEND2NAB_FORM entre crochets [ ]) a insérer ou vous le désirez.

Téléchargement :

Le panneau de configuration :

Vous trouverez ces informations dans le panneau de préférence du site de votre Nabaztag.

Il ne reste qu’a contribuer un contenu :

Ce qui donne :

Vous pouvez modifier le formulaire via votre css. Voici la mienne par exemple


#send2Nabaztag p.send2Nabaztag_error {
	font-weight: bold;
	color: #f00;
}

#send2Nabaztag p.send2Nabaztag_success {

}

#send2Nabaztag form textarea {
	width: 450px;
	height: 200px;
}

N’hésitez pas à me faire un retour si vous utilisez ce plugin. De même, j’ai trois améliorations en tête, revenez donc sur cette page pour les mises à jour.

Utilisation des filtres avec Symfony

Voila encore une fonctionnalité peu connu qui me fait aimer ce framework.

Dans Symfony, quand le système reçoit une requête il exécute une série de filtre permettant un découpage logique efficace des actions à traiter. Ce qui est intéressant, c’est que l’on peut facilement intégrer ses propres filtres afin de modifier des comportements du framework.

Par exemple, si vous voulez logguer chaque accès sur toutes les pages de votre application (c’est un exemple … ok ?), rien de plus facile.

C’est une simple classe à mettre sous le dossier lib par exemple.

< ?php

class accesslogFilter extends sfFilter

{

  public function execute($filterChain)
  {
    if ($this->isFirstCall())
        // on ne logue que le premier appel à une action
    {

      /*
      ici, on a accès à tous les objets de symfony
      $request = $this->getContext()->getRequest();
      etc ... permettant de tracer la requête,
      de savoir quel module on utilise ...
      */

      /*
      à vous de créer votre log (j'vais pas tout faire)
      */
    }
    $filterChain->execute();
  }
}

Il faut ensuite simplement activer votre filtre en ajoutant au fichier apps/myapps/config/filters.yml les lignes suivantes :

accesslog:
  class: accesslogFilter

Juste après le filtre de sécurité(security).

Simple non ?

Acheter des prestations informatiques – #2 – le cahier des charges

Le cahier des charges est un incontournable de la gestion de projets. Un point de départ en somme. C’est aussi un des documents les plus critique, notamment dans le cadre de projets réalisés au forfait par des prestataires de services. Je vais tenter dans cet article de vous donner quelques recettes et de vous indiquer les écueils à éviter pour produire un bon cahier des charges.

Cet article fait partie de la série : Acheter des prestations informatiques.

Lire la suite

Astuce symfony : limiter l’accès à la version de développement de votre application

Voici une petite astuce que j’ai vu passé sur la mailing list des développeurs Symfony.

Bien sur, quand vous mettez votre site en production, vous vous assurez de ne n’y déposer que vos contrôleurs de production (si besoin, la tâche en ligne de commande symfony clear-controllers le fait pour vous). Toutefois, il peut arriver qu’une équipe de TMA ai besoin d’accèder à la version de développement de votre application. Par exemple, pour résoudre rapidement une bug bloquant nécessitant le jeu de données du serveur de production ou pour faire une analyse des logs visant à une optimisation … bref.

Pour cela, il suffit de rajouter ces lignes dans le fichier web/.htaccess de votre projet afin d’en sécuriser l’accès par IP. (en rajoutant votre IP bien sur)

<FilesMatch "_dev.php$">
Order Deny,Allow
Deny from all
Allow from 127.0.0.1
</FilesMatch>

Bon ok, c’est pas l’info du siècle. Mais vu le nombre de sites sortant avec leurs contrôleurs de dev accessibles, je me demande si cela ne devrait même pas être une feature du framework, c’est d’ailleurs actuellement discuté.

A ce sujet également, il y a cette page sur le wiki de SF : SecuringDevFrontend.

Installer xdebug et KCachegrind sous Leopard

Cet article fait suite au deux premiers écrits au sujet de l’installation de PHP5 et MySQL5 sous Léopard.

L’idée est de faire du profiling d’application PHP en utilisant xdebug et KCachegrind.

Installation de xdebug

Si vous avez correctement installé PHP aucun problème pour xdebug :
# sudo pecl install xdebug

Ajouter « zend_extension=/usr/local/php5/lib/php/extensions/no-debug-non-zts-20060613/xdebug.so »
à la fin du fichier php.ini suffira à activer l’extension. (attention, le chemin de xdebug.so peut être un peu différent mais il sera sous /usr/local/php5/lib/).

Vous pouvez d’ores et déjà utiliser xdebug comme décrit dans cet article chez Zend. Avec symfony, les traces de xdebug seront automagiquement intégrées dans les infos de débogages.

debogage symfony xdebug

installation de KCachegrind avec fink

Xdebug va permettre de faire du profiling d’application PHP. Mais afin d’exploiter les résultats obtenus, il nous faut un logiciel bien spécifique faisant partie de KDE : KCachegrind.

Pour installer KCachegrind, il faut d’abord installer fink (qui, par ailleurs vous permettra d’installer plein de logiciels open-source disponibles sous Linux). Le projet fink fournit un installeur qui fonctionne tout seul.

Pour le faire fonctionner avec le shell que j’utilise (bash, qui n’est pas le shell par défaut sous osx) j’ai dû ajouter cette ligne dans le fichier .profile à la racine de mon compte utilisateur :

. /sw/bin/init.csh

KCachegrind n’est pas disponible dans la version stable des paquets fournis, il faut passer en unstable.

Pour cela, il faut éditer le fichier /sw/etc/fink.conf et remplacer la ligne commençant par ‘Trees:’ par :

Trees: local/main stable/main stable/crypto unstable/crypto unstable/main

Il faut ensuite mettre à jour la base locale de fink en tapant les commandes suivantes :

# sudo fink selfupdate
# sudo fink index
# sudo fink scanpackages

La commande selfupdate va durer un certain temps et sollicitera votre connexion internet. Le programme vous posera des questions sur les miroirs à utiliser, si cela ne vous parle pas, choisissez les options par défaut.

Il faut enfin lancer l’installation de KCachegrind via la commande :

sudo apt-get install kcachegrind

Vous verrez apparaitre un message de ce type :

The following package will be installed or updated:
kcachegrind
The following 164 additional packages will be installed:
....

Ici, vous pouvez allez vous coucher et revenir le lendemain … il y en a en général pour plusieurs heures (il faut télécharger KDE notamment).

Et voila, vous pouvez maintenant lancer KCachegrind depuis le terminal (celui-ci ouvrira X11 automatiquement) :

# kcachegrind

installation de KCachegrind via les binaires de KDE

Une distribution complète de KDE4 pour mac os x est disponible ici. Le plus simple est de télécharger le torrent everything. Un peu de patience et beaucoup de place sur votre disque dur sont également nécessaires pour cette phase.

Une fois l’image téléchargée, montez la et lancer l’installeur kde.mpkg

Il va installer la base de KDE ainsi qu’une version de QT compilée pour os x puis l’ensemble de KDE.

Pour lancer KCachegring il faut aller chercher le .app dans /opt/kde4/bin ce que vous pouvez faire depuis le finder en tapant ce chemin après le raccourci clavier Pomme+Shift+V.

Et voilà !

Personnellement je préfère cette dernière méthode car elle permet de se passer de X11. Par contre, le paquet est un peu instable (il plante parfois aléatoirement sur l’ouverture des fichiers). Il faudra retourner sur la page du mainteneur pour obtenir les mises à jour.

Le seul souci restant est que KCachegrind ne trouve pas l’utilitaire dot pour générer les graphiques d’appels. Pour remédier à cela, si vous avez fink, il y a une solution (un peu rapide certes) :

# sudo apt-get install graphviz
# cd /bin
# sudo ln -s /sw/bin/dot .

paramétrage de xdebug

L’objectif est de paramétrer xdebug pour qu’à chaque page php demandée, il produise une trace permettant de faire notre profiling.

Il faut tout simplement ajouter les lignes suivantes à la fin du php.ini :

xdebug.profiler_enable=1
xdebug.profiler_output_dir=
/Users/olivier/tmp

et bien sur créer le répertoire /Users/olivier/tmp

# mkdir /Users/olivier/tmp
# chmod 777 /
Users/olivier/tmp

A chaque hit sur votre serveur, un fichier sera crée dans ce répertoire. Vous pourrez l’ouvrir avec KCachegrind.

Un futur article expliquera comment exploiter les résultats obtenus et parlera de profiling d’applications php en général.

Pourquoi utiliser Zend Framework quand on peut utiliser Symfony ?

Connaisseur averti de Symfony (que j’ai pratiqué sur de nombreux projets) je m’intéresse vivement aux frameworks PHP. J’ai utilisé d’autres frameworks ; par exemple, Code Igniter qui est quand même pas mal, (surtout si on est coincé avec PHP4) mais qui reste pour moi valable uniquement pour des petits projets (pub gratuite : un joli site réalisé avec ce framework par un de mes amis).

En ce moment, tout le monde s’excite beaucoup autour de Zend Framework. Je suis donc allez y jeter un coup d’œil ; Zend avait annoncé des livraisons importantes et mon dernier avis sur la question datait un peu.

Là, je dois vous dire chers lecteurs, que je suis vraiment désappointé. Franchement, vous lui trouvez quoi au Zend Framework ? (c’est une vraie question – un peu provocatrice oui – mais tout de même une question).

  • La documentation est vraiment aride,
  • il manque des bouts de MVC comme la vue !? (bien que visiblement le composant soit disponible, il n’est pas documenté !?),
  • que viennent faire les classes de connections aux services d’Amazon, de Flickr etc … pour moi c’est hors périmètre d’un framework (enfin ça ce n’est pas grave),
  • on doit fabriquer le cache à la main,
  • pas de système de plugin (c’est dommage car ce système séduit les utilisateurs comme on peut l’observer pour CakePHP ou Symfony),
  • pas de gestion d’environnements (dev, test, prod …), rien pour vous aider à instancier / déployer vos applications,
  • rien pour les formulaires 😦 (si il y a un composant de validation), pas de helpers pour faire de l’Ajax,
  • pas de scaffolding

Mon impression est que ZF a été développé de manière un peu brouillonne et désordonnée. Quelque chose de satisfaisant du point de vue d’une librairie mais pas d’un framework (comme PEAR par exemple). Je ne dis pas que le travail fait autour de ZF est mauvais (je trouve, par exemple, certaines classes très bien faites comme Zend_Memory ou Zend_PDF) mais tout ça manque de liant et de finition pour faire un bon framework.

Je pense toutefois qu’un défaut d’approfondissement dans mes recherches est la cause de tout ces manques affichés – je creuse. Si vous avez des arguments pour me faire changer d’avis, je serais ravi de vous lire dans les commentaires. Pour l’instant je continue avec Symfony.

Non cet article n’est pas un troll. Ceci oui :

troll

Le développeur communiquant

J’ai lu avec grand plaisir l’article de Sylvain Weber sur le développeur communiquant ; un brin second degré et suscitant pleins de réflexion.

Mon désaccord porte surtout sur la définition du développeur communiquant : « Il est un trolleur-blogueur-bullshiteur ».

Pour ma part je me considère comme un développeur communiquant. Oui, je suis – à la base – un développeur. Cela ne me gêne pas, j’en suis fier. Et oui, mes capacités à communiquer m’ont permis de réaliser mon parcours et de diversifier mes compétences.

Selon moi, le modèle du geek autiste est voué à disparaitre. D’ailleurs, finalement, des geeks autistes fan du point-virgule, j’en connais finalement assez peu.