Il y a peu, une annonce était faite comme quoi MySQL travaillait sur un nouveau modèle de release. La trame générale de celui-ci est maintenant fixée et approuvée.

Dans les grandes lignes, on retrouve :

  • Le trunk est toujours laissé dans une qualité de beta
  • Les GA sortiront tous les 12 à 18 mois
  • Pas plus de 2 releases avec un support actif
  • Les milestones commencent lors de beta (jamais lors d’alpha) par un merge entre le trunk et le stage tree.

Pourquoi cet article ? Pas seulement pour relayer l’actualité MySQL, mais aussi pour tenter de sensibiliser un maximum de lecteurs sur l’importance d’un modèle de release adapté. Pour un logiciel prétendant à un minimum d’évolutions et d’activité, il est capital de trouver un compromis entre ce que je nommerai la rétro-utilisabilité et la publication des nouvelles versions. J’entends par « rétro-utilisabilité » le fait d’assurer aux utilisateurs des versions passées un support, un moyen de passer aux versions supérieures efficacement.

Source : Planet MySQL (En)

Difficile d’y échapper… Firefox 3.5 est en version beta, la 5e du nom est tout juste disponible. L’occasion pour Ze Technology de promouvoir un peu plus cette nouvelle mouture. Au programme, toujours plus de tout : plus de bugs corrigés, plus de vitesse, plus de HTML5… Ainsi, cette page recense les différentes évolutions que peuvent prendre en compte les développeurs et intégrateurs HTML dans l’écriture de leurs pages et feuilles de styles. On y retrouve des trucs plutôt cools comme la gestion des polices téléchargeables, la propriété word-wrap pour effectuer des césures de mots…

Télécharger Firefox 3.5 bêta 4 en français

J’ai fini – très vite – de lire un livre. J’étais plongé dedans, me voilà donc chroniqueur d’un jour. La trame de l’histoire en elle même n’est pas des plus complexe et se résume wikipedialement ainsi :

Susan Fletcher, qui est à la tête de la division Cryptographie de la NSA, se trouve face à un problème sans précédent. Le superordinateur (TRANSLTR) à 2 milliards de dollars et trois millions de micro-processeurs utilisé pour casser tous les codes qui chiffrent les communications mondiales se trouve devant une impasse. Alors qu’il faut habituellement quelques minutes pour qu’un fichier soit déchiffré, ce TRANSLTR recherche toujours la solution après déjà 15 heures, ce qui ne peut être expliqué que par l’existence d’un code incassable.

Premier roman de Dan Brown (vous savez, le Da Vinci Code…), publié en 1998 aux États Unis, obtient toute l’attention du lecteur averti dès le début. On y parle de clé publique / clé privée, d’algorithmes de chiffrement, d’attaque brute-force… Cependant, seule la présence de ces notions est intéressante ; la manière dont elles sont abordées sont parfois approximatives, superficielles, ou parfois de manière purement fictive pour les besoins du roman.

Certes, ce n’est pas un ouvrage technique, il est normal qu’un tel roman ne nécessite pas de connaissances sur AES, de tripe DES ou de chiffrement par bloc. La simple évocation dans l’ouvrage d’un code incassable est aussi assez loufoque, mais soit, l’auteur est maître de son oeuvre et peut se permettre de telles fantaisies, d’autant qu’elles sont amenées de telle sorte à véritablement plonger le lecteur dans un problème d’envergure internationale.

L’histoire se suit au final très agréablement – un peu trop simplement peut être, à l’instar d’une super-production hollywoodienne. Les amateurs apprécieront sûrement de découvrir la signification de codes tout au long de l’histoire. Ce que je concluerai par une seule phrase :

113-19-5-28-5-53-66-113-76-19-128-10-92-15-19-128.

Cette semaine, le lien de la semaine est surtout uniquement dédié aux développeurs. C’est Google Code qui passe sous le feu des projecteurs de ZeTechnology. Google propose en effet cette immense plate-forme à destination de nos amis les codeurs. On y retrouve bon nombre d’informations, de projets rattachés à la firme de Mountain View… mais aussi, et c’est ce qui me tient à coeur, un service de dépôts SVN pour tous vos projets libres.

Non content de proposer un dépôt SVN (à défaut de Git…), Google vous offre tout un espace à la sauce Trac pour gérer vos projets :

  • Gestion de pages (wiki)
  • Système de suivi de bugs
  • Navigation en ligne dans le repository
  • Espace de téléchargement

Bref, le strict minimum qu’une équipe ou un développeur solo se doit d’avoir pour un projet. Mais il est important de souligner à quel point l’outil de bug-tracking est efficace, alors qu’il paraît relativement sommaire au premier abord :

  • labels personnalisés pour les états (ouvert, résolu, vérifié, accepté…)
  • gestion assez avancée de templates prédéfinis (idéal pour guider l’utilisateur qui rapporte un problème)
  • détection automatique des références aux revisions / bugs. (Si vous mentionnez « fixed issue 42 » dans votre changelog SVN, un lien automatique sera réalisé vers ce problème, qui sera passé automatiquement en « fixed ». De même, un commentaire faisant allusion à « r65 » aura un lien pointant sur la dîte révision)

En résumé, autant de petites choses qui font qu’on a la sensation d’avoir un outil pleinement exploitable, utile, et qui rend bien des services. http://code.google.com

Ça y’est, vous êtes en train d’écrire vos tests fonctionnels pour votre application Symfony. MAIS votre application – ou une partie – nécessite une identification de la part de l’utilisateur. Il y a bien sûr la solution qui consiste à systématiquement remplir le formulaire dans chaque fichier de test.

Je vous présente ici une solution pour palier à cela. La solution consiste à étendre la classe sfTestFunctional du framework. Ce qui donne, par exemple :

class sfGuardTestFunctional extends sfTestFunctional
{
 public function __construct($browser, $lime = null, $testers = array())
 {
   parent::__construct($browser, $lime, $testers);
   $this->signin(array('username' => 'foo', 'password' => 'bar'));
 }

 /**
  * Perform user authentication
  *
  * @param   array of String         $user_data
  * @return  sfGuardTestFunctional   $this
  */
 public function signin($user_data)
 {
   return $this->info(sprintf('Login as "%s"', $user_data['username']))->
          get('/admin/login')->
          click("S'identifier", array('login' => $user_data))->

          with('form')->begin()->
            hasErrors(false)->
          end()->

          with('user')->begin()->
            isCulture('fr_FR')->
            isAuthenticated(true)->
          end()->

          with('request')->begin()->
            isParameter('module', 'admin')->
            isParameter('action', 'login')->
          end()->

         isRedirected()->
         followRedirect();
 }
}

De cette manière, dans votre fichier de test il vous suffira d’instancier votre browser avec votre nouvelle classe :

$browser = new sfGuardTestFunctional(new sfBrowser('my_vhost'));

Et voilà, vous pouvez vous considérer comme identifié et écrire directement vos tests fonctionnels ! La solution présentée ici est minimale, la mise en forme du code PHP avec Blogspot n’étant pas des meilleure et votre motivation étant sans doute plus grande à déchiffrer 20 lignes de code plutôt que 42.

Une petite mise en oeuvre de ce cette classe, mise en place au sein de Piwam. L’exemple est destiné à la version 1.2 du framework..

C’est un point très mal explicité dans la documentation de Symfony. Lorsque vous être en train de concevoir votre schéma au sein du fichier eponyme – schema.yml -, vous aimeriez bien avoir le contrôle de vos champs de type DECIMAL, non ?

La documentation n’étant pas très bavarde, peut être comme moi vous contentiez vous d’indiquer :

amount:   { type: decimal }

Pour exécuter ensuite des requêtes SQL bien placées pour modifier ce ce champ et lui affecter par exemple un stockage de 3 chiffres après la virgule. Je n’avais pas trouvé la réponse immédiatement, mais après un petit tour On Ze Ouaib, j’ai enfin déniché ce qui me manquait :

amount:  { type : decimal, size: 8, scale: 2 }

Pour un champ de type DECIMAL(8,2). Reste plus qu’à compléter la documentation Symfony…