Symfony fournit un mécanisme de journaux permettant de tracer toute sorte de messages, en leur affectant un niveau de criticité (info, warning, err, …). Ainsi, lorsque l’on constate un comportement anormal, on peut aller voir dans les logs les messages nous permettant de mieux comprendre le problème.

Néanmoins, on ne va pas fouiller ces journaux tous les jours, comment faire pour être automatiquement averti lorsqu’un problème survient ?

Il existe plusieurs plugins, par exemple sfErrorNotifierPlugin ou sfHoptoadNotifierPlugin.

sfErrorNotifierPlugin

sfErrorNotifierPlugin est tout simple, il envoie un mail lorsqu’une exception est levée. Inconvénients :

• ne se base pas sur le journal, les messages de type ‘err’ par exemple ne seront donc pas nécessairement remontés.
• se base sur la fonction mail(), ce qui peut parfois être restrictif.

Ces 2 inconvénients sont cependant facilement contournables, faisant de sfErrorNotifierPlugin une excellente solution de secours.

sfHoptoadNotifierPlugin

sfHoptoadNotifierPlugin propose quelques mécanismes très pratiques.

Il s’agit d’un plugin qui, lors d’un problème, va se connecter au site Hoptoad (initialement dédié aux applications Rails) pour lui indiquer le problème.

Les 2 principaux inconvénients de ce plugin sont :

• comme sfErrorNotifierPlugin, ne se base pas sur le log (mais on va voir plus bas comment contourner ce problème)
• nécessite une connexion internet (vers http://hoptoadapp.com)

Service Hoptoad

Ce site offre deux services :

• Envoi de mail lors d’un problème
• Tableau de bord de suivi des problèmes

Ce qui est très intéressant est que le site détecte s’il s’agit d’erreurs similaires. Ainsi, si une centaine d’erreurs similaires sont déclarées, Hoptoad n’enverra qu’un seul mail.

Ci-dessus, le tableau de bord indique qu’il y a eu 17 erreurs du type “Error while creating new event”.

Le tableau permet également de déclarer qu’un problème a été résolu (dans l’exemple ci-dessus, le 2eme message est grisé car déclaré comme résolu), et si une nouvelle erreur de cette famille survient, un nouveau mail est alors envoyé.

Installation du plugin

Je regrette que ce plugin ne soit ps disponible dans un dépôt Subversion : il utilise git. Toutefois, l’installation reste très simple (je ne fais que reprendre le readme.txt) :

pear channel-discover pear.horde.org
pear install horde/yaml
pear install HTTP_Request
git clone git://github.com/krasio/sfhoptoadnotifierplugin.git \
             plugins/sfHoptoadNotifierPlugin

Puis ajouter dans le app.yml de l’application souhaitée:

all:
    sf_hoptoad_notifier_plugin:
      api_key: you_api_key_goes_here

Et c’est tout !

Ajustement du plugin pour se baser sur le journal

Mon besoin est de détecter les messages de type [err], et, en début de vie de l’application, détecter les messages de type [warning]. Il suffit de détecter les évènements de type ’application.log’. Pour cela :

Dans le fichier sfHoptoadNotifierPluginConfiguration.class.php, ajouter à la fin de la méthode configure() le code suivant :

$this->dispatcher->connect(
   'application.log',
   array('sfHoptoadNotifier', 'listenToApplicationLogEvent')
);

Puis ajouter dans le fichier sfHoptoadNotifier.php la méthode:

static public function listenToApplicationLogEvent(sfEvent $event) {

  $params = $event->getParameters();
  // check if there is a log level
  if (isset($params['priority'])) {

    // level high enough ?
    $log_level_str = sfConfig::get('app_sf_hoptoad_notifier_plugin_log_level',
                                   'err');
    $log_level = constant('sfLogger::'.strtoupper($log_level_str));

    if ($params['priority'] <= $log_level) {
      // yes.
      $apiKey = sfConfig::get('app_sf_hoptoad_notifier_plugin_api_key', false);
      if ($apiKey) {
        if (!defined('HOPTOAD_API_KEY')) {
          define('HOPTOAD_API_KEY', $apiKey);
        }
        $priority_str = sfLogger::getPriorityName($params['priority']);
        $exception = new sfException("'[$priority_str] " . $params[0] . "'");
        Hoptoad::exceptionHandler($exception);
      }
    }
  }
}

Enfin, ajouter dans le app.yml le niveau de criticité souhaité:

  sf_hoptoad_notifier_plugin:
    api_key: you_api_key_goes_here
    log_level: warning # ou err

Évidemment, plutôt que de modifier le plugin existant, j’aurais facilement pu faire un nouveau plugin puisque l’on se base sur un type d’évènement différent, mais je pense que le mieux est d’essayer d’enrichir le code de celui qui existe.

Twitter permet entre autres de suivre l’activité de ses amis, de faire de la veille technologique, ou de s’entre-aider.

Néanmoins, la variété des services que Twitter peut rendre ne fait que s’accroître, voici quelques exemples.

Actualités

De nombreux media papiers diffusent les actualités, comme par exemple Le Monde, Le Figaro, ou Le Point.

Divers

Twit2do (en) – permet de gérer des tâches et d’être notifié par twit.

Twittercal (en) – permet d’être notifié par twit des évènements planifiés sur Google Calendar.

TwittBourse (fr) – pour suivre le CAC40

Twansalte – pour demander une traduction via twits, mais ne fonctionne plus. Sinon il y a Twitrans.

Metweo (fr) – diffuse la météo des grandes villes françaises.

Pour la recherche d’emploi, de nombreux comptes diffusent les offres: RegionsJob, Les Jeudis, …

TwitPic (en) – permet de diffuser des photos via les twits

Twitter Search (en), Tweet Scan (en) ou TwitterFall (en) – très utile pour rechercher de l’actu en temps réel, ou pour voir les sujets « chauds » du moment. Tweet Scan permet en plus d’être notifié automatiquement par mail sur les mots clés de notre choix.

Autrement, je suis tombé par hasard sur le service Explore, si quelqu’un sait comment faire fonctionner « twitter blocks » …

Offres commerciales

Peut-etre que bientôt en France on pourra commander des pizzas, comme aux US avec Naked Pizza (en) ? En attendant, dans l’hexagone, Domino’s (fr) diffuse ses offres spéciales et répond aux questions les consommateurs …

La plupart des agences de voyage proposent leurs offres via twitter. Par exemple LastMinute ou Thomas Cook.

Jeux

beatmytweet (en) -  diffuse des anagrammes, mais … en anglais !

twitbrain (en) – jeu de calcul mental. Très basique, l’intérêt est d’être hyper réactif.

PlayTwivia (en) – quizz

Roll.the.dice (en) – permet de tirer au hasard des nombres, cartes, …

ChessTweets (en) – pour jouer aux échecs !

Annuaires

Coté annuaires de services twitter, il y en a une palanquée, mais ils sont généralement vastes avec pas mal de déchets. Exemples: JustTweetIt (en), Twellow (en), WeFollow (en).

Ensuite, on trouve des listes nettement plus réduites mais de qualité sur divers blogs. J’ai trouvé un point d’entrée intéressant sur TwitterRadar.

Au final …

Honnêtement, même si la créativité des services n’a pas de limite, la plupart de ceux cités ci-dessus ont un intérêt assez limité, car il existe souvent des alternatives simples et plus « usuelles ».

Néanmoins, l’un des intérêts que je vois dans Twitter est le fait que l’on soit capable en permanence de twitter et de recevoir les twits via le mobile. Donc tout ce qui est actu, évènements, infos nécessaires « sur le champ » (tourisme, indications utiles, …) sont de loin pour moi les services les plus utiles (du moins pour l’instant !).

Annoncé il y a un peu moins d’un an et mis en application depuis six mois, Facebook propose son nouveau concept « Facebook Connect ». Les librairies et l’API sont relativement faciles à utiliser, mais le plus dur est de se repérer dans l’amas de documentation. Cet article a pour but d’expliquer le concept, de recoller les morceaux de documentation, et combler certains manques.

Une simple recherche sur Google de facebook api donne de nombreux points d’entrées a priori intéressants :

• Le portail Facebook Developers
• Introduction de l’API Facebook
• Connexion à Facebook, alias Facebook Connect
• Le wiki
• La page wiki sur l’API
• La page wiki sur Facebook Connect
• etc…

Toutes ces pages sont plus ou moins liées, et proposent des liens vers beaucoup d’autres pages contenant des informations plus ou moins redondantes.

On trouve de nombreux exemples html + javascript, mais peu d’exemples coté serveur (php, …), il est souvent nécessaire d’aller à la pêche dans les forums pour trouver des infos supplémentaires, ou le cas échéant, à faire de la rétro-ingénierie sur les bibliothèques fournies.

Bref, un beau petit merdier !

Les bases de Facebook Connect

Facebook propose deux types d’applications : celles qui sont intégrées sur le site de Facebook (« applications Facebook »), et les applications externes qui peuvent se connecter au site de Facebook pour récupérer et/ou envoyer des informations. C’est sur ce dernier type d’application que cet article se penche, c’est le concept Facebook Connect :

Les intérêts sont multiples :

• Récupérer des informations sur l’internaute (profil, amis, photos, évènements, …). Cela permet par exemple à l’internaute de ne pas avoir à recréer son carnet d’adresses ou sa galerie photos. Cela permet également pour l’application de récupérer des contacts supplémentaires et cibler son marketing par exemple.
• Exporter des données vers Facebook (photos, évènements, …). Par exemple, dans le cadre d’une application gérant des critiques de livres, il est possible de publier sur le flux de Facebook un message lors de chaque nouvelle critique. Cela augmente d’une part la visibilité de l’application tierce sur Facebook, et d’autre part la visibilité de l’internaute dans la communauté.
• Amener facilement dans l’application externe la notion de communauté, grace à la fonction de « friend linking ».
• Ne gérer qu’une seule authentification (celle de Facebook)
• Associée à une application Facebook interne, l’application externe peut augmenter de manière importante sa visibilité.

Pour développer un site se connectant à Facebook, le principe est le suivant :

• Déclarer l’application dans Facebook afin d’une part d’obtenir une clé d’API, et d’autre part afin d’indiquer à Facebook quelques règles sur le comportement (domaines acceptés, redirection suite à une déconnexion, etc…).
• Mettre sur le serveur hébergeant l’application un fichier spécial, xd_receiver.htm, fourni par Facebook, permettant les échanges entre l’application et Facebook.
• Développer l’application, en utilisant les balises Facebook (FBML), les librairies javascript, et les autres librairies disponibles (PHP, …)

Déclarer notre application à Facebook

Facebook fournit un tableau de bord pour gérer ses applications, qu’elles soient internes ou externes. Ce tableau de bord est accessible à l’url http://www.facebook.com/developers (il s’agit en fait d’une application Facebook, qu’il faut donc ajouter à son profil).

Même si l’on ne souhaite que créer une application externe, il faut néanmoins créer une application Facebook, qui sera « vide ». Cliquer sur « Créer une application » :

Les autres paramètres de l’onglet « Général » sont optionnels, et parlent d’eux-même.

Ensuite, aller sur l’onglet « Connexion », qui est dédié précisément aux applications externes Facebook Connect :

Les autres champs ne sont pas obligatoires.

La fonction « Friend Linking » n’est pas utilisée dans cet exemple, mais est décrite un peu plus bas.

La section « Template Bundles » n’est pas utilisée non plus dans cet exemple, elle permet de définir des templates pour diffuser des informations sur le profil Facebook de l’internaute.

Fichier d’échange

Il s’agit d’un simple fichier à créer, xd_receiver.htm,sur le serveur. Le contenu de ce fichier est défini sur le wiki Facebook. Il peut être aussi bien positionné à la racine que dans un sous-répertoire. Il s’agit d’un paramètre de configuration des bibliothèques que l’on verra plus tard.

Developper l’application

Utilisation de la librairie JavaScript

Structure typique d’une page utilisant la librairie JavaScript :

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:fb="http://www.facebook.com/2008/fbml">
<head> ... </head>
<body>

 ...
 <fb:login-button></fb:login-button>
 ...

 <script src="http://static.ak.connect.facebook.com/js/api_lib/v0.4/FeatureLoader.js.php" type="text/javascript"></script>

 <script type="text/javascript">
 FB.init(xxxxxxx, '/xd_receiver.htm');
 ...
 </script>

</body>
</html>

Les points notables :

• Si l’on souhaite utiliser des balises Facebook (<fb:xxx>), il faut ajouter dans la balise <html> le namespace xmlns:fb= »http://www.facebook.com/2008/fbml »
• Ajouter dans le la librairie JS : <script src= »http://static.ak.connect.facebook.com/js/api_lib/v0.4/FeatureLoader.js.php » type= »text/javascript »></script>. Ne doit pas être placée dans le <header> car génère du code.
• Les balises Facebook peuvent être ajoutées après la librairie, et avant le FB.init. C’est l’appel à FB.init() qui va (entre autres) déclencher le rendu de ces balises.
• Avant de pouvoir appeler l’API, il faut d’abord initialiser l’application avec FB.init(api_key, channel_path). Le paramètre api_key est la clé d’API que l’on a obtenu lors de la création de l’application. Le channel_path est le chemin du fichier xd_receiver.htm, (en relatif ou en absolu).

Le wiki est plutôt bien documenté sur l’utilisation de la librairie javascript, et regorge d’exemples, la suite de l’article se focalise donc plus sur l’utilisation de la partie PHP. Quelques exemples pour utiliser la librairie javascript :

• Simple authentification
• Détection d’authentification, login, logout
• Affichage du profil suite à authentification
• Documentation de FB.init, permettant également de détecter le statut authentifié ou non
• …

Utilisation de la librairie PHP

Cela devient un peu plus freestyle, car mal documenté.

Facebook propose une API RESTful dont la documentation succincte est disponible ici : http://wiki.developers.facebook.com….

Pour bien comprendre son utilisation (URL, paramètres, enchainement des appels, …), pas d’autre solution que d’analyser le code d’une librairie cliente officielle telle que la librairie PHP. Et si on a la chance de développer un site dans un langage bénéficiant d’une telle librairie, autant l’utiliser directement !

Donc commencer par télécharger la librairie PHP, et la dézipper. Les librairies utiles sont dans le répertoire facebook-platform/php. Il y a deux fichiers interessants :

• facebook.php : contient la classe principale Facebook. Il s’agit du point d’entrée, cette classe se charge d’initialiser la connexion, et d’instancier un client REST (cf. ci-dessous).
• facebookapi_php5_restlib.php : contient la classe FacebookRestClient fournissant toutes les méthodes nécessaires pour aller appeler l’API REST de Facebook. Par exemple, l’API propose une fonction « facebook.friends.get » pour obtenir la liste des amis d’une personne. La classe FacebookRestClient fournit une méthode friends_get() qui appelle l’API en formatant correctement les paramètres, et qui désérialise/analyse la réponse pour fournir les valeurs de retour.

Exemple d’utilisation :

<?php
// Librairie PHP officielle
require_once('facebook-platform/php/facebook.php');

// Initialisation
// Le SECRET_CODE est obtenu lors de la création de l'application
$facebook = new Facebook(API_KEY, SECRET_CODE);

// si l'internaute est authentifié, retourne son identifiant
// sinon, redirige vers une page d'authentification facebook, puis retourne sur cette page
$user_id = $facebook->require_login();

// pour recuperer a tout moment l'identifiant de l'internaute:
// $user_id = $facebook->user;

// pour appeler l'API Facebook:
// $facebook->api_client->... (se référer au code source facebookapi_php5_restlib.php)

L’exemple ci-dessus détecte si l’internaute est authentifié, et le cas échéant, le redirige vers Facebook pour s’authentifier. Néanmoins, on souhaite fréquemment détecter si l’internaute est authentifié, sans pour autant le rediriger de force vers Facebook le cas échéant. Pour cela, il suffit simplement de tester la valeur $facebook->user:

<?php
// Librairie PHP officielle
require_once('facebook-platform/php/facebook.php');

// Initialisation
$facebook = new Facebook("api_key", "secret_code");

// Authentifié ?
if ($facebook->user == NULL) {
 // non authentifié
} else {
 // authentifié
}

Exemple de code affichant la liste des amis :

<?php
// Librairie PHP officielle
require_once('facebook-platform/php/facebook.php');

// Initialisation
$facebook = new Facebook("api_key", "secret_code");

// si l'internaute est authentifié, retourne son identifiant
// sinon, redirige vers une page d'authentification facebook, puis retourne sur cette page
$user_id = $facebook->require_login();

// recupere les identifiants des amis
$friends_uid = $facebook->api_client->friends_get();

// recupere les infos utiles des amis
$friends_data = $facebook->api_client->users_getInfo($friends_uid, array('uid', 'first_name', 'last_name'));

var_dump($friends_data);

Note 1 : dans certains cas, l’appel à $facebook->api_client->friends_get() (ou l’appel à d’autres méthodes) peut provoquer une erreur. C’est un effet de bord qui peut arriver lorsque l’internaute n’est pas « tout à fait » déconnecté, lorsque ses cookies ne sont nettoyés qu’à moitié. Il est donc recommandé de fiabiliser les appels à ces méthodes en ajoutant un try/catch.

Note 2 : la liste des informations que l’on peut obtenir sur les utilisateurs est décrite ici. Une restriction importante : il n’est pas possible d’obtenir l’adresse email ! Le seul contournement qu’offre l’API Facebook est un mécanisme pour envoyer des emails aux utilisateurs souhaités.

Note 3 : la fonction $facebook->require_login redirige l’utilisateur vers Facebook, le risque est donc de ’perdre’ l’internaute. Pour l’authentification, je préfère utiliser la version JavaScript (<fb:login-button>) qui ne fait qu’ajouter une fenetre popup pour s’authentifier.

Liens utiles :

• API REST Facebook
• Page d’accueil de la bibliothèque PHP officielle couvrant de manière partielle l’API
• Librairie PHP non-officielle (PEAR) couvrant toute l’API

Alléger le serveur en mixant PHP, JavaScript et FBML

Tout développement côté serveur peut engendrer une charge importante, parfois le serveur a peu d’intérêt à connaître certaines informations. D’où l’intérêt d’utiliser les balises Facebook (FBML) et les librairies javascript. Et inversement, trop utiliser les librairies JS plombent les performances côté internaute, et nuisent à l’accessibilité. Tout l’art est donc de trouver le juste milieu.

Par exemple, pour afficher la liste des amis et leur photo, le serveur peut se charger de récupérer les identifiants, et le navigateur de l’internaute se charger de récupérer les photos :

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:fb="http://www.facebook.com/2008/fbml">
<head></head>
<body>
<?php

// Librairie PHP officielle
require_once('facebook-platform/php/facebook.php');

// Initialisation
$facebook = new Facebook("api_key", "secret_code");

// recupere les identifiants des amis
$user_id = $facebook->require_login();
$friends_uid = $facebook->api_client->friends_get();
?>

<!-- affiche les photos des amis -->
<?php foreach($friends_uid as $uid) : ?>
 <fb:profile-pic uid="<?php echo $uid; ?>" linked="true"></fb:profile-pic>
<?php endforeach; ?>

<!-- necessaire pour le rendu FBML -->
<script src="http://static.ak.connect.facebook.com/js/api_lib/v0.4/FeatureLoader.js.php" type="text/javascript"></script>
<script type="text/javascript">
 FB.init("api_key", 'xd_receiver.htm');
</script>

</body>
</html>

Note 1 : dans le cas d’une application Facebook Connect, il faut utiliser la forme « <fb:xxx></fb:xxx> » à la place de « <fb:xxx /> ».

Liens utiles :

• Balises Facebook (Facebook Markup Language, alias FBML)
• Librairie cliente JavaScript

Quelques notions supplémentaires

Développement local

En phase de développement, il est nettement plus productif de développer en local sur son poste, puis ensuite, une fois l’application validée, d’exporter le code source vers le serveur définitif. Il est tout à fait possible de développer des applications Facebook Connect en local, en suivant ces consignes :

L’URL que l’on a fourni lors de la création de l’application Facebook doit exister, et doit être accessible par Facebook (même s’il n’y a rien).

Le fichier xd_receiver.htm doit être sur le serveur définitif, car Facebook essaiera de le charger.

L’URL utilisée pour le développement local doit être sur le même domaine que celui déclaré lors de la création de l’application. En clair : si le domaine déclaré est ’site.fr’, alors ajouter dans le fichier hosts local l’entrée : 127.0.0.1 local.site.fr

Et créer dans le serveur web un hôte virtuel basé sur le nom de domaine local.site.fr.

Friend linking

Comme on l’a vu dans l’exemple un peu plus haut, il est facile d’obtenir la liste des amis d’un internautes. Cependant, comment savoir si parmi cette liste, certains ont un compte sur notre application ? On peut éventuellement se baser sur le prénom et le nom, mais ce n’est pas une méthode sûre en raison des risques d’homonymie et de la manière dont les utilisateurs ont saisi leur profil (par exemple ’Frederic’ sur le profil Facebook, et ’Fred’ sur notre application).

La fonction « friend linking » (activée lors de la création de l’application) permet précisément de faire ce lien, afin de recréer les communautés au sein de notre application.

Librairies clientes

Liste des librairies clientes (PHP, ActionScript, …)

Facebook Query Language

Facebook propose un language de requêtage pour rechercher des utilisateurs, photos, évènements, … Il s’agit du Facebook Query Language (FQL).

Ces requêtes peuvent être par exemple appelées via JavaScript avec FB.ApiClient.Fql_query($query) ou PHP avec la fonction $facebook->api_client->fql_query($query).

Exemples de sites utilisant Facebook Connect

Ce n’est que depuis très peu de temps que l’on commence à trouver des sites de grande audience exploitant Facebook Connect. On peut par exemple citer :

• L’Equipe qui a mis son nouveau site en ligne le 19 mai et proposant une barre Facebook pour chatter avec les autres internautes.
• Digg qui publie dans le fil des actualités Facebook les nouvelles pages bookmarquées par l’internaute
• Joost, Vimeo, et CBS utilisent Facebook Connect pour le partage des vidéos.

Et un peu de promo pour un site perso mettant en oeuvre Facebook Connect: PocMe permettant d’être automatiquement notifié par mail des anniversaires des amis enregistrés suk.r Facebook.

En savoir plus:

• Page d’accueil Facebook Connect
• Utilisation de Facebook Connect sur iPhone
• Règles d’utilisation de Facebook et Facebook Connect

Donc principalement Symfony 1.2 et Doctrine.

Symfony 1.2

PocMe est développé en PHP, basé sur le framework Symfony (branche 1.2). Du bonheur en barre Il permet de se concentrer sur l’essentiel, à savoir la partie métier. Toute la partie technique usuelle est laissée au framework.

La principale difficulté est que l’on a régulièrement tendance à implémenter quelquechose, sans savoir que symfony fournit déjà des outils pour cela. Donc pour être efficace avec symfony, il y a un ticket d’entrée minimum pour bien comprendre les notions de controleurs, de filtres, de slots, d’helpers, etc…

Donc passage par la case doc obligatoire, et là, c’est un régal: l’aide en ligne ainsi que le tutorial jobeet constituent l’une des principales forces de symfony, tant par la pédagogie que par l’ensemble des sujets couverts.

Seul petit bémol sur la doc de l’API, qui n’est pas propre à symfony d’ailleurs: j’aurais aimé que l’index des méthodes soit classé par ordre alphabétique, et que le résumé soit affiché à droite du nom de la méthode. Car en l’état, cet index est quasi inutilisable, je passais mon temps à faire des control-F. A moins d’utiliser la doc en ligne via un IDE.

Une autre source d’info extrêmement intéressante, c’est le code source de Symfonians, qui permet de découvrir des fonctionnalités dont on n’avait pas idée, des idées de solutions techniques et conception (je pense par exemple à la gestion des mails et de leurs templates, de l’implémentation de sfGuard, …), bref, j’ai énormément pompé sur ce site, merci NiKo

D’ailleurs, au sujet de sfGuard, il s’agit d’un plugins, certes, mais il ne faut pas s’imaginer qu’il suffit de l’activer pour avoir toute la gestion des utilisateurs. Tout ce qui concerne l’enregistrement, la confirmation, l’envoi de mot de passe, la gestion du profil, … reste à implémenter. Ce qui demande un effort considérable. Bien qu’une fois fait, j’imagine qu’il est facile de récupérer la majorité du code pour l’appliquer à une nouvelle appli.

Forms

Bien qu’il s’agisse d’un composant intégré à Symfony, il s’agit d’un package important, qui a fait couler pas mal d’encre.

Pour créer un formulaire, il faut avoir son bac ! Au début, on copie/colle un exemple de formulaire pour faire le notre, ou on le génère automatiquement, mais si on veut pousser le bouchon un peu plus loin, il faut retrousser ses manches et bien lire la doc (plusieurs chapitres dédiés). Le point positif est que la partie complexe réside dans l’objet formulaire et ses éventuels validateurs/formatteurs, et une fois cela fait, le code dans les actions et les templates reste simple.

Ma principale crainte en épluchant la documentation était de voir symfony tomber dans certains écueils de certains frameworks Java. Instruction trouvée sur le site du framework Hibernate:

Avoid over-design: aiming for too much abstraction and flexibility at an early stage is a great way to waste time that could be better spent solving actual problems that your actual users are facing. Do the simplest thing that can possibly work. Don’t try to solve problems that your users don’t care about. And it DOES NOT matter if your implementation is inelegant, at least initially. What matters is delivering useful functionality in a timely manner

Une fois les principes intégrés, un peu suspicieux, et après avoir un peu galéré pour les 2/3 premiers formulaires, je reconnais que le développement des suivants est de plus en plus rapide, et plutôt agréable.

Donc lorsqu’il s’agit de formulaires plutôt standard, la productivité est bonne. Lorsque les besoins deviennent plus spécifiques, la nouvelle mouture des formulaires n’est pas vraiment optimisée pour du développement bas niveau.

Exemple: j’ai pas mal sué avec la notion d’erreur globale … J’avais besoin d’avoir des templates un peu travaillés en fonction du type de l’erreur globale. Je n’ai pas réussi. Peut-etre y’a-t-il un bug, ou plus probablement, j’ai raté une ligne dans la doc. Toujours est-il que ce n’est pas évident.

Mais bon, ma petite appli n’a que des formulaires plutôt basiques, donc dans l’ensemble, j’ai plutôt apprécié le mécanisme.

Doctrine

Pour varier un peu les plaisirs, vu que je connaissais déjà Propel, cette fois-ci je suis parti sur Doctrine. Quelques points:

• La documentation est dense, et on ne trouve pas toujours l’information souhaitée dans le chapitre auquel on s’attend. Et certaines informations importantes sont noyées dans le reste de l’info (j’ai mis du temps à découvrir les magic finder !). Néanmoins, la doc a pas mal évolué entre temps. Et je viens à l’instant de découvrir un tutorial de Doctrine sur le site de symfony, voilà ce qui me manquait

• Les possibilités de schéma sont nettement plus puissantes sous Doctrine 1.1 que sous Propel 1.2.

• La contrepartie est que du coup, le schema.yml est plus complexe, il faut toujours sa cheat sheet à coté de soi (alors que pour Propel c’etait particulièrement simple).

• Le requêtage est très proche du SQL. Avec Propel, on en était très loin, et dès que l’on voulait faire des requêtes complexes (alliant plusieurs jointures, clauses et/ou, …), il vallait mieux passer en mode requête SQL (sinon le code devenait difficilement maintenable).

• Performances ? Aucune idée

En tout cas, parfaitement intégré à Symfony.

Fonctions PocMe

Concernant l’appli PocMe, qq points notables:

S’enregistrer: sur tous les sites que je connais, pour s’enregistrer, il faut saisir 2 fois le mot de passe. Et je trouve ça irritant ! Ca devient tellement une habitude qu’au final, je fais un copier/coller du 1er password dans le 2nd, ce qui enlève tout interet à la vérification, je sais Je me doute bien que le but est d’avertir l’internaute s’il a fait une faute de frappe. Et alors ? S’il s’est trompé, il suffit qu’il fasse la demande ‘mot de passe perdu’, et voilà ! Honnêtement, dans combien de cas on se plante dans la saisie d’un mot de passe ? Disons qu’on est vraiment manchot, on se trompe une fois sur 5. Et du coup, pour 4 inscriptions sur 5, ce champs supplémentaire n’a aucun intérêt si ce n’est alourdir le formulaire d’inscription. Bref, j’avais envie de changer un peu cette habitude (oui, je sais, je suis un énorme rebelle )

Dates: c’est l’aspect le plus complexe de l’application. Car gérer des dates fixes, pas de pb, mais gérer des dates répétées (tous les mois par ex), c’est une horreur. Donc le gros du temps passé sur l’appli concerne la gestion de ces date.

Mails: j’ai tout simplement repris le principe que j’ai vu dans Symfonians, à savoir sfSwiftPlugin, allié à un module dédié pour les templates, et se connectant à un serveur SMTP de Google Apps. Seul petit hic: les performances pour l’envoi de mails, pas très rapide, il faudra que je voie si je peux améliorer cela.

Tests automatiques: comme tout le monde, j’adore ce principe, j’avais commencé à les mettre en place au début en utilisant la lib de symfony, mais ça prend du temps à mettre en place, j’ai fini par abandonner

Scripts automatiques: lancés via cron évidemment, j’ai un peu galéré car j’ai réalisé tardivement que mon script devait appeler le controlleur (notamment à cause des templates de mails). Je ne souhaitais pas passer par Apache (à cause des éventuels timeout). Je suis donc passé par le sfConsoleController au lieu de l’habituel sfWebController. Puis j’ai dû bidouiller un poil pour qu’il soit exécuté avec le rôle admin.

Voilà, au final, je me suis plutôt bien amusé, et ce n’est pas fini

Le principe est d’avoir un service très simple d’utilisation, qui ne fait que vous envoyer un petit mail le jour J, rien de plus, il ne vous proposera pas un formulaire d’inscription de 10 pages et ne vous fera pas le café.

Ceci pour vous éviter d’oublier un anniversaire ou toute autre tâche importante (loyer, réservation, …).

Fonctionnellement, le principe est simple: après vous être enregistré, vous pouvez sélectionner une date, un message, et une fréquence (tous les ans, tous les mois, une seule fois). C’est tout.

Bien sûr, vous pouvez ajouter autant de dates que vous le souhaitez, ou supprimer un évènement erroné.

Pour l’instant, l’application est dans une version assez basique, mais parmi les évolutions prévues: traduction dans d’autres langues, amélioration de l’ergonomie et du design, et quelques autres idées (import des anniversaires  des copains dans Facebook, widget rappellant les prochaines échéances, notification par twit, … la liste des idées est longue, mais après faut les développer !).

Coté technique, j’y reviendrai plus tard, sachez juste pour l’instant que c’est basé sur Symfony 1.2 et hébergé chez Pastis-Hosting (l’hébergeur pas plus haut que le bord).

Et n’hésitez pas à me remonter tout bug rencontré

Pour rappel, un profiler est un outil dont le but est d’optimiser une application. Que ce soit pour la faire exécuter plus rapidement ou pour diminuer la mémoire consommée. Habitué au profiling java (via OptimizeIt, JProbe, JProfiler …), ce n’est que récemment que je me suis intéressé au profiling PHP (j’entends déjà les mauvaises langues siffler « ben oui, php, c’est rapide et léger, pas besoin de profiler ! »).

Profiling CPU

La rapidité est un facteur intéressant aussi bien pour un script exécuté par Apache que pour un script exécuté en ligne de commande.

Avant d’expliquer comment installer le profiler, d’abord un simple exemple d’utilisation. Sur un CMS (Drupal), nous avons remarqué que de simples requêtes HTTP faisait grimper le CPU d’Apache à 100% pendant quelques secondes. Une simple coup de profiling permet de trouver très rapidement le coupable:

L’outil ci-dessus montre que la requête HTTP (index.php) a duré 2.8 secondes, et sur ces 2.8 secondes, la fonction ‘theme’ a pris 2.4 secondes. Après, il suffit de suivre le fil en double-cliquant sur les lignes jusqu’à trouver une fonction suspecte:

Et là on trouve le coupable: la fonction JSMin:minify, qui a elle seule, prend 2.2 secondes. Cette fonction sert à minifier à la volée les scripts JS que nous avons mis en place dans Drupal. Dans ce cas concret, l’optimisation est simple: nous minifions nous-meme les scripts, et la requête HTTP passe de 2.8 secondes à 0.6 seconde !

Remarque: en mesurant le temps d’exécution de la fonction, on mesure également le temps d’exécution des requêtes SQL, ce qui permet éventuellement de trouver des requêtes à optimiser.

Cet exemple permet de montrer qu’il est très facile de trouver le problème. Après, ce n’est pas pour autant que l’on trouve la solution, mais c’est déjà très intéressant dans bon nombre de cas.

Installation de l’outil:

L’extension php xdebug permet de tracer les performances de chaque instruction exécutée. Pour l’installer, c’est très simple:

• Sur Ubuntu: cf. procédure d’installation XDebug sur Ubuntu
• Sur Windows:  télécharger sur le site de XDebug la DLL correspondant à notre version de php et la sauvegarder n’importe où.

Ensuite, il faut configurer XDebug. Cela se fait simplement en éditant le fichier php.ini:

zend_extension=/path/to/xdebug.so_or_dll
xdebug.profiler_enable = On
xdebug.profiler_output_dir = /whatever/folder
xdebug.profiler_output_name = "cachegrind.out.%u"

Maintenant, tout appel à php engendrera des fichiers de logs dans le répertoire défini ci-dessus. Attention, ces fichiers peuvent être très volumineux !

Pour les dépouiller, il faut utiliser KCachegrind (KDE) ou WinCacheGrind (Windows). Ce dernier est basique mais fournit l’essentiel (les snapshots ci-dessus ont été pris avec WinCacheGrind). KCacheGrind est plus complet, le site de XDebug explique les bases de son utilisation. Il est intéressant de remarquer que l’on peut très bien avoir des logs créés par un serveur Debian et ensuite analysés sur un poste Windows.

Profiling mémoire

On a rarement recours au profiling mémoire pour des scripts exécutés sur un serveur HTTP. La durée de la requête étant en général au plus de quelques secondes, la mémoire n’a pas le temps d’atteindre des sommets, et si c’est le cas, on a vite tendance à augmenter le paramètre memory_limit dans le php.ini sans trop se poser de questions !!!

Par contre, pour des scripts exécutés en ligne de commande, qui peuvent durer plusieurs minutes, cela peut devenir problématique. Notre besoin était d’importer des contenus externes (dans Drupal). Notre script bouclait donc sur les 4.000 contenus à importer. Or, à chaque nouvelle itération, la mémoire augmentait de 100ko. Il y avait donc une fuite mémoire qu’il était nécessaire de colmater.

Malheureusement, je n’ai pas trouvé d’outil adéquat pour du profiling mémoire. Les outils java cités plus haut permettaient de manière très efficace de repérer quels étaient les données qui étaient encore en mémoire à tort, et par qui elles avaient été allouées. Mais je n’ai pas trouvé l’équivalent en php.

XDebug fournit des informations mémoires en le configurant ainsi:

xdebug.show_mem_delta = On
xdebug.trace_output_dir = /whatever/folder
xdebug.trace_output_name="trace.%u"

Mais je n’ai pas trouvé d’outil capable de dépouiller les fichiers de log (les analyser manuellement n’est vraiment pas productif), et j’ai l’impression que ces fichiers ne contiennent pas toutes les informations utiles (notamment la liste des objets encore alloués, par qui).

Donc sur ce coup là, je m’en suis tiré avec du profiling cpu, en prenant pour hypothèse que la fonction qui prend le plus de CPU serait la fonction qui prend le plus de mémoire ! Et par une immense chance, cela a fonctionné (le vilain petit canard était le module pathauto de Drupal) !

Mais si vous connaissez des outils, je suis preneur !

Le pigeon, c’est comme le cochon, c’est bon. A tous ceux qui ne connaissent pas trop cette volaille: cela n’a rien à voir avec du poulet ! La chair est plus colorée, la texture plus fondante. Il y a plein de façons de le cuisiner, mais celle que j’adore est le pigeon simplement rôti au pain à l’ail.

Pour obtenir des pigeons, deux méthodes. La première est de se pointer sur le parvis de notre dame avec une carabine. Là il faut alors être assez prompt, non pas pour viser le pigeon, mais pour détaler suffisament rapidement pour pas vous faire coffrer. Remarquez, des poulets et des pigeons dans un panier à salade, ça fait un beau plat. Si ce parcours sportif ne vous sied pas, il reste le marché, où l’on trouve auprès de la plupart des vendeurs de volaille la bestiole recherchée. En général il faut prévoir 1 pigeon par personne (~ 6 €).

Après, rien de plus simple: une noix de beurre à l’intérieur, une noix de beurre dessus, un peu de sel et de poivre, et ça y’est, le pigeon est prêt ! On peut éventuellement le larder pour qu’il soit un peu moins sec, mais restons simple, c’est tout aussi bon.

Et le petit truc en plus que j’adore c’est le pain à l’ail: il faut du pain bien sec (peut sécher en quelques heures si on met le pain sur un radiateur tiède). Puis sur chaque tartine, on y écrase une gousse d’ail. Il faut alors placer une tartine sous chaque pigeon (alors que pour le poulet on peut le mettre dedans). Ainsi, il ne ne cuira pas trop, et récupèrera le jus.

Mettre le tout au four à 200°, cuisson 30mn, il faut juste penser à les retourner au bout de 20mn (en les laissant toujours reposer sur le pain). En fin de cuisson, enlever pigeons et pain, déglacer avec une lichette de vin blanc pour récupérer les sucs. Pour l’accompagnement, c’est libre: carottes, pommes de terres, gratin dauphinois, … miam

P.S: je n’ai pas mis de photo car j’attends que vous m’offriez un 40D ! En attendant, admirez:  photo plat (bon, ok, c’est pas du meilleurs goût !)

Bref, c’est suite à ça que je me suis rendu compte à quel point le backup était important. Je me disais toujours « oui oui, c’est vrai, il faut que je backup ». Mais ça trainait. On pense toujours que ce genre d’aventure n’arrive qu’aux autres. On pense toujours qu’on peut passer à travers les mailles du filet de la malchance. Mais quand le cambriolage, l’incendie, le crash disk survient, et bien … c’est trop tard ! Aucun signe avant-coureur ! Bref, leur petite histoire m’a sacrément motivé pour rechercher une solution de backup !

Je me suis penché sur 3 solutions:

mozy fournit un petit logiciel à installer sur le poste à sauvegarder. On configure dans ce logiciel les différents répertoires à sauvegarder. Puis ensuite, tout se déroule tout seul. A heures régulières, le soft détecte les changements et les envoie sur le serveur. Le point noir que j’avais vu est qu’avant de commencer la sauvegarde proprement dite, Mozy fait de longs traitements pour en théorie optimiser le transfert. Mais pour les fichiers très volumineux (plusieurs centaines de Mo), ces traitements n’en finissent pas.

Ce que je trouvais intéressant de leur offre ‘Home’ était la facilité de calcul du prix: 4.95 $ (soit 3.75 €) par mois pour stockage illimité. J’ai cherché la petite astérisque (vous savez, celle qu’on a tendance à louper sur les contrats des assurances) pour voir si c’était réellement illimité, je n’ai trouvé aucune restriction. Étonnant quand on voit que la version pro facture 0.50 $ / Go. Mais bon … Si quelqu’un a des infos sur ce point, je suis preneur.

Les points négatifs identifiés: client disponible seulement sur Windows & Mac, et mono-poste. Pour un deuxième poste, il faut repayer 4.95 $.

Ces points négatifs ne me paraissaient pas trop embêtant: il suffisait que je monte les disques de mes différents serveurs sur mon serveur Windows, et le tour était joué: windows monoposte, 5$/mois illimité, banco !

Je me suis donc lancé dans le paiement en ligne. Et pour une raison inconnue, il a échoué (si si, le solde de mon compte était positif pour une fois !). J’ai essayé de contacter le support, qui n’a pas pu m’aider, il semblait y avoir des problèmes avec les cartes européennes.

Pas de bol !

Je me suis alors tourné vers Amazon S3. Le premier abord n’est pas très attirant: pas de logiciel proposé, c’est avant tout un service, à nous de nous débrouiller pour trouver un soft. De plus, d’après l’offre tarifaire il est assez dur d’évaluer le coût réel qui nous sera facturé :

• Stockage: 0,14 € / Go / mois
• Transfert: 0,08 € / Go transferé vers Amazon
• Requêtes: 0,01 € / requête

D’après ces chiffres, on comprends qu’il y a un cout initial de transfert, puis un coût de stockage, quand aux nombre de requêtes, il est très difficile de les évaluer.

Ca, c’était le coté un peu réfrigérant d’Amazon S3.

Si on va un peu plus loin, on peut estimer que par exemple, pour sauvegarder 20Go, cela revient à environ 1,60 € de transfert initial plus 3 € par mois de stockage (plus qq centimes pour les requêtes). C’est quand même un prix intéressant ! De plus, il n’y a plus de notion de monoposte. Amazon S3 propose un espace de stockage, après, le reste nous regarde.

Coté logiciels, l’offre est vaste, il existe une multitude de softs, que ce soit pour windows, mac, linux, pour smartphones, etc… Néanmoins, l’une est particulièrement répandue: JungleDisk.

Le logiciel fonctionne sous windows, linux, et mac. Il dispose à la fois d’une interface conviviale (elle a été énormément améliorée depuis la version 2) qui permet de sélectionner les répertoires à sauvegarder, et qui permet de définir une fréquence de backup. A chaque nouveau backup, l’outil n’envoie vers le serveur que ce qui a été modifié depuis la dernière fois bien sûr. Il dispose également d’une version en ligne de commande qui permet éventuellement de scripter l’outil. A noter également qu’il y a des options supplémentaires possibles via le fichier de config.

L’outil est néanmoins payant. 15€ dans sa version de base. Si on veut passer à la version supérieure (JungleDisk Plus), il faut payer 1€ / mois. La version supérieure n’est intéressante que si l’on a de très gros fichiers à sauvegarder, car elle permet d’interrompre et reprendre un chargement, elle est également capable d’identifier des portions qui ont été modifiées dans ce fichier. Mais pour mon besoin, la version de base est tout à fait satisfaisante.

Pour plus de détails sur l’offre JungleDisk et des captures d’écran, je vous recommande l’article d’Oncle Tom.

Dropbox se rapproche de mozy dans le sens où il s’agit d’une offre packagée, incluant le logiciel client et le service de stockage. Le logiciel est très ergonomique. Pour s’en faire une idée, allez sur leur site, et cliquez sur « watch the video ». On peut notamment voir en temps réel dans l’explorateur quels sont les fichiers qui sont à synchroniser (un peu comme TortoiseSvn).

Ergonomique, mais encore incomplet fonctionnellement: Dropbox ne permet de sauvegarder qu’un seul répertoire ! En fait, Dropbox est probablement plus orienté synchronisation de données sur plusieurs postes, plutôt que backup. Un répertoire est créé (« My Dropbox »), et tous les fichiers qui sont placés dans ce répertoire seront automatiquement sauvegardés. Si un autre poste est également relié au même compte Dropbox, alors les données sont synchronisées.

En réalité, le stockage est réalisé sur Amazon S3. Mais le paiement passe par le site Dropbox, qui propose un espace de 50 Go pour 7,60 € / mois.

Conclusion

J’ai opté pour Amazon S3 plus JungleDisk qui me permettent une grande flexibilité dans l’archivage de mes différents postes. L’offre mozy semble très intéressante pour de gros volumes (> 50 Go), avec le défaut néanmoins de ne pas proposer de client Linux.

Je n’ai pas évalué l’offre Google car inexistante à l’époque où j’avais fait mes tests.

N’hésitez pas à me faire tout retour d’expérience, non pas que je pense être cambriolé, mais … on ne sait jamais !

Mon besoin: avoir un virtual host (https://svn.domaine.fr) dans lequel je peux y gérer plusieurs repository svn (https://svn.domaine.fr/projet1, etc…). Le tout hébergé sur un serveur Ubuntu 8.04 (Hardy).

J’ai finalement adopté la solution basée sur apache2, et ce fut plus simple que certaines manips que j’ai vu sur certains forums.

J’utiliserai l’arborescence suivante pour mes dépots svn:

/var---svn         ; répertoire de base contenant tous les dépots
        +-projet1  ; repository du projet 1
        +-projet2  ; repository du projet 2
                   ; etc...

Création des repositories subversion

Installer svn:

sudo apt-get install subversion

Création d’un répertoire qui contiendra tous les repositories:

mkdir /var/svn

Puis création d’un repository pour chaque projet:

svnadmin create /var/svn/projet1

Installation d’apache et SSL

sudo apt-get install apache2 openssl

Activer le mod ssl et créer un certificat (validité 1 an dans l’exemple ci-dessous):

sudo a2enmod ssl
sudo openssl req -x509 -nodes -days 365 -newkey rsa:1024 \
                   -out /etc/apache2/server.crt -keyout /etc/apache2/server.key

Répondre aux questions posées, voici un exemple de réponses:

FR
FRANCE
Bordeaux
Ma compagnie fictive
Idem
svn.domaine.fr
nom@mail.fr

Puis modifier les droits du certificat:

sudo chmod go-rwx /etc/apache2/server.key

Lien entre apache et svn

Il faut installer le mod dav_svn:

sudo apt-get install libapache2-svn

On n’éditera pas /etc/apache2/mods-available/dav_svn.conf, on mettra les réglages directement dans le fichier vhost afin de bénéficier de la clause ServerName (sinon les réglages svn seraient appliqués pour tous les vhosts).

Si on veut un accès protégé, il faut créer un utilisateur svn ‘toto’:

sudo htpasswd -cs /etc/apache2/dav_svn.passwd toto

Puis pour ajouter d’autres utilisateurs, remplacer ‘-cs’ par ‘-s’.

Modifier l’appartenance de certains répertoires pour qu’apache puisse y accéder:

sudo chown www-data:www-data /etc/apache2/dav_svn.passwd
sudo chown -R www-data:www-data /var/svn

Activer si ce n’est déjà fait le module dav_svn:

sudo a2enmod dav_svn

Créer ensuite un virtual host, dans mon exemple il s’agit de https://svn.domaine.fr. Editer le fichier /etc/apache2/sites-available/svn, puis y coller:

NameVirtualHost *:443

<VirtualHost *:443>

    ServerName svn.domaine.fr
    SSLEngine on
    SSLCertificateFile /etc/apache2/server.crt
    SSLCertificateKeyFile /etc/apache2/server.key

    <Location / >
      DAV svn
      SVNParentPath /var/svn
      AuthType Basic
      AuthName "Subversion Repository"
      AuthUserFile /etc/apache2/dav_svn.passwd
      Require valid-user
    </Location>
</VirtualHost>

(Les 4 dernieres directives servent à protéger l’accès. Les enlever pour un accès public).

Puis l’activer:

sudo a2ensite svn

Puis redémarrer apache:

sudo /etc/init.d/apache2 reload

Ignorer les warnings « Could not reliably determine etc… ». Par contre, si un message d’erreur concernant les ports apparait, éditer alors le fichier /etc/apache2/sites-enabled/000-default, et remplacer les ‘*’ par ‘*:80′ (2 occurences). S’il y a d’autres fichiers dans ce meme répertoire, appliquer la meme modif.

Et voilà !

Vous pouvez maintenant vous rendre avec votre navigateur à l’adresse suivante: https://svn.domaine.fr/projet1

Et pour créer de nouveaux repositories, il suffira juste de taper:

sudo svnadmin create /var/svn/nouveauprojet
sudo chown -R www-data:www-data /var/svn/nouveauprojet

Le navigateur vous proposera d’ajouter une exception pour le certificat de ce site.

Non pas que ma vie ait un quelconque intérêt à être exposée sur le web. Mais c’est juste que parfois, je découvre des choses que j’ai envie de partager. Que ce soit une solution à un problème technique, ou que ce soit la découverte d’un super endroit.

Mon problème est que je me passionne pour toutes sortes de choses, du coup Internet est devenu mon plus grand malheur: une porte ouverte sur la connaissance illimitée (</envolée lyrique>). Donc au même titre que je peux bénéficier de l’information fournie par d’autres internaute, il me semble logique et intéressant de participer à cette base de connaissances.

Bon, ça, c’est la théorie. En pratique, ce qui m’a toujours freiné pour la création d’un blog c’est le temps. J’ai peur de ne pas avoir le courage de passer suffisament de temps pour faire vivre ce blog.  C’est pourquoi je vois ce blog plus comme un « bloc-notes »: je compte ne pas trop m’embarrasser de la forme, et rédiger mes remarques de manière assez synthétiques.

On verra si je peux tenir le cap !