Arnaud

PEAR blog post

Aaron poste un billet sur "Ce qui ne va pas dans PEAR" en commentaire à l'une des raisons de la session "Six reasons PHP sucks" donnée à OSCON.

Je vous laisse lire le billet sur des problèmes et les solutions proposées.

Les commentaires vont du classique "C'est nul" à la réflexion sur les problèmes de gestion des releases.

Voici une courte de liste de problèmes choisis dans les commentaires.

Documentation: c'est à mon sense le défaut majeur. Le manque de documentation et la barrière d'entrée au système utilisé élevée (docbook)

• Un wiki devrait aider mais amène aussi des inconvénients. Un wiki est par nature peu structuré, à l'opposé de docbook donc et nécessite un effort conséquent pour garder une cohérence d'ensemble. Cependant je pense qu'un wiki serait une grande avançée.

Paquetages abandonnés ou absence des mainteneurs

• ne pas hésiter à contacter la liste pear-qa en vous proposant comme mainteneur. Le mieux pour cela est d'avoir des patchs déjà écrit. En cas de non-réponse sur cette liste écrivez à la liste pear-dev. Les temps de réponses ne sont pas immédiats, ne vous attendez donc pas à avoir une réponse dans les cinq minutes suivantes.

PEAR n'est pas PHP5. De nombreux paquetages fonctionnent correctement sous PHP5. Un lecteur remarque correctement que la compatibilité PHP5 ne signifie pas que ses fonctionnalités soit utilisées

• Pour qu'un paquetage soit vraiment PHP5 une nouvelle version majeure doit être écrite, exemples hypothétiques: Services_Amazon2, Log2, Date2, etc. Il d'ailleurs fortement recommandé pour les nouveaux paquetages d'être écrits en PHP5.

Une rapide note pour la mise à jour de Serendipity qui propulse ce blog en version 1.0 (sortie récemment).

J'en profite également pour changer le thème

J'utilise depuis peu la librairie Yahoo!. Ce billet montre comment chaque ligne d'une table peut devenir un éléments cliquable, donnant ainsi une plus grande souplesse aux utilisateurs.

J'ai récemment indiqué le renouvellement de l'équipe assurance qualité de PEAR. Suite àune question posé sur la liste de discussion voici un éclaircissement sur la participation à ce renouvellement.

Tout le monde peut participer au processus de selection des candidats ainsi qu'au vote. Pour cela vous devez disposer d'un compte sur le site pearweb. Si jamais vous n'en avez pas, vous devez en demander un en précisant que vous désirez participer au renouvellement de l'équipe.

Vous pouvez nominer n'importe quel personne qui participe aux listes de discussion pear-qa et pear-dev.

La suite se déroulera comme indiqué sur la proposition.

Nous allons voir comment utiliser le coeur du système, j'ai nommé le controlleur. Il s'agit plus précisement d'un "controlleur frontal". Le principe est simple, toutes les requêtes arrivant sur une application sont gérées par un seul objet et redistribuées comme il faut.

La structure recommandée d'une application utilisant le controlleur est:

/application
    /models
    /views
    /controllers
/document_root
    /images
    /styles
    .htaccess
    index.php
/library
  /Zend

En pratique nous avons la page document_root index.php dans ressemblant à ceci

Pour le moment le fonctionnement du controlleur suppose l'utilisation du module mod_rewrite d'apache afin que toutes les requêtes soient effectivement envoyées au fichier index.php. Une solution entièrement PHP devrait bientôt faire son apparition.

La règle à ajouter dans la configuration apache ou dans un fichier .htaccess est

RewriteEngine on
RewriteRule !\.(js|ico|gif|jpg|png|css)$ index.php

Une proposition vient d'être ajoutée à PePr (outil de gestion des propositions) pour le renouvellement de l'équipe d'assurance qualité de PEAR.

Il existe en fait deux équipes, l'une est constituée de tous les membres inscrits à la liste de diffusion pear-qa; tous les membres peuvent donc participer aux activités assurance qualité comme les tests des nouvelles version de l'installateur de paquetages. La deuxième équipe, plus restreinte, est composée de 6 membres qui ont des droits supplémentaires sur le site web (pearweb) pour gérer les mainteneurs des paquetages, retirer des releases ne respectant par les règles, etc.

Je vous encourage donc à lire la proposition et participer au renouvellement !

La proposition : http://pear.php.net/pepr/pepr-proposal-show.php?id=394

La tendance naturelle est de faire remarquer les choses qui ne vont pas et beaucoup moins souvent les chose qui vont bien. Afin d'endiguer ce phénomène je vous fait part d'une expérience agréable que j'ai eu cette semaine avec l'Administration dans sa déclinaison electronique.

Ayant besoin d'un extrait de naissance je me connecte lundi soir au site de la mairie concernée afin de connaître les démarches à suivre. Je découvre un formulaire à remplir pour recevoir le dit document, je m'empresse donc d'indiquer les informations nécessaires. Quelques minutes plus tard je reçois un mail avec le sujet "Demande traitée" et le corps de message "ok". Après avoir philosophé quelques instants sur la signification profonde du "ok" (vais-je vraiment le recevoir ? quels délais ? toutes les informations sont-elles correctes ? quelqu'un est-il parti dans les archives afin de retrouver l'original ? etc) je m'endors enfin.

Aujourd'hui, mercredi, soit deux jours plus tard j'ai reçu l'extrait de naissance !

Un grand bravo pour l'efficacité et la rapidité de la procédure.

Zend à récemment sorti un plugin PHP pour Eclipse, un Environnement de Développement Integré.

Lisez ce billet pour voir l'installation et le résultat.

MaJ: A noter qu'il s'agit d'une version "preview" 0.5, la version finale 1.0 étant prévue pour septembre.

Lors de l'apéro PHP du vendredi 16 décembre 2005 Sarah m'a suggéré de présenter les paquetages de PEAR par les fonctions qu'ils apportent. Le site actuel permet de parcourir la liste des paquetages mais ne présente pas les paquetages en termes des tâches qu'ils permettent d'effectuer.

Je prends donc ma plume (clavier en fait) pour essayer y remédier et présenter les paquetages. Le but n'est pas d'être exhaustif mais plutôt de vous permettre de mettre un pied à  l'étrier plus rapidement.

Je travaille depuis peu de temps chez Ipnotic Telecom et nous recherchons au moins un développeur PHP ayant une bonne connaissance de PHP et du web.

Si je peux fournir plus d'infos, n'hésitez pas à  me le dire. Envoyez-moi vos cv : arnaud at limbourg point com

Ce blog à  changé de serveur et de tête, j'utilise désormais Serendipity comme moteur.

Il subsistera quelques soucis que je corrigerai au fur et à  mesure [Edit2] ca devrait être mieux maintenant

Les URL des feeds ont changées et j'ai quelques soucis avec la redirection. [EDIT] vos agrégateurs ont du recevoir la nouvelle adresse.

Et Bonne Année à  tous !

Selon Joel Spolsky dans User Interface Design for Programmers l'interface utilisateur doit être simple et répondre directement à ses besoins. Ceci étant valable si l'utilisateur à déjà des connaissances du sujet (ex: il connait la comptabilité pour utiliser un logiciel de comptabilité). Dans la conclusion du chapitre 11 "People can't remember" Joel indique qu'un logiciel doit être assez simple pour qu'un "idiot" puisse l'utiliser.

La majorité des principes est bon mais je ne peux m'empêcher de penser aux limites d'un tel raisonnement. En tant que personnes nous devons apprendre à lire, écrire, marcher, faire du vélo, etc. Aucune de ces activités n'est "simple" et pourtant sont vitales (mis à part le vélo peut-être .

Un logiciel ou une application doivent être simple mais certaines choses nécessitent d'être apprises quoique l'on fasse. Il ne suffit pas non plus de répéter ce que l'individu connaît déjà, ne rien apprendre de nouveau n'est pas stimulant.

Comme l'a dit Einstein "Les choses doivent être aussi simples que possible mais pas plus simple" (traduction de "Things should be made as simple as possible, but not any simpler.").

A la fin du webcast sur le Zend Framework on peut voir que le compteur de temps déraille un peu (sur mon poste en tout cas

J'ai reà§u aujourd'hui le DVD du Projet aardvark ou comment passer un été avec des geeks.

Le film montre comment des stagiaires chez Fogcreek, la compagnie de Joel Spolsky, on géré un projet complet de création d'un logiciel dont le résultat est ici.

Les intervenants sont excellents (Paul Graham par exemple) et voir le déroulement des événements entourant la création d'un logiciel est tout bonnement passionant.

J'ai été assez déà§u car les mouvements sont assez saccadés. Cela est vraiment visible lors des travelling ou lorsque des véhicules bougent à  l'écran. Cela n'entache pas la qualité du film je vous rassure.

Bref, a voir !

Vous désirez participer à PEAR et ne savez pas par où commencer ? Ce billet vous donne des pistes.

Pour simplifier, on distingue trois types de contributions: - nouveau paquetage - paquetage existant - documentation

PEAR dispose d'un outil de gestion des propositions nommé PePr. Une personne souhaitant proposer un nouveau paquetage ou bien une recommandation (RFC) doit publier sa proposition en utilisant cet outil.

Pour un nouveau paquetage il y a deux étapes à effectuer. La première est de vérifier l'existence d'un paquetage remplissant les mêmes fonctions. Si c'est le cas et que votre paquetage n'apporte aucune nouvelle fonctionnalité il sera probablement refusé à moins que vous n'ayez de solides arguments.

Dans le cas où le paquetage fournit des fonctionnalité supplémentaires il est préférable d'essayer de les intégrer au paquetage existant. Si cela n'est pas possible pour quelque raison que ce soit le paquetage peut tout de même être accepté après une discussion.

Contribuer à la documentation s'effectue de deux façons. Vous pouvez ouvrir des bugs en indiquant les erreurs dans le manuel. Pour aller plus loin vous pouvez contacter la liste pear-doc en envoyant vos documents à intégrer au manuel ou posez vos questions.

J'espère que cela vous aide !