Le blog de code34

Clever-age vient de publier un livre blanc : frameworks php pour l’entreprise qui fait le tour d'horizon des frameworks php dans un contexte d'entreprise notament zend framework & symphony, et d'autres frameworks un peu plus ancien.

Cette étude mériterait de couvrir également d'autres frameworks un peu moins en vue. Les opportunités d'imposer de nouveaux frameworks dans le monde PHP ne manquent pas. Les initiatives non plus. A mon sens, ça n'est pas le fait qu'un framework soit visible qui fait que c'est une solution d'entreprise ou pas. Il faut avant tout regarder la cohérence, la qualité, la scalabilité, l'architecture du code.

Il faut également éduquer les développeurs php aux "bonnes méthodes" de programmation.

Et c'est bien là qu'il y a de la marge de progression :)). Bon nombre de frameworks php trainent dans leurs placards les squelettes de la programmation php4, voir php3. Certains ont explosé en plein vols tant ils devient de plus en plus compliqué de les maintenir (..) Aucun a ma connaissance n'utilisent d'interfaces, et le typage de paramètre. (pas de connaissance de la programmation évènementielle, du polymorphisme etc (..) ) Bref, si j'étais extrémiste dans l'état de l'art, je recommanderais de ne pas utiliser de framework php ou de ne pas perdre du temps à apprendre ces technologies tant qu'elles n'ont pas muries. Mais il faut reconnaitre que des frameworks comme Zend ont une qualité de code élevé, et sont très bien documentés.

Au niveau Orm, il faut apprendre aux développeurs que la puissance que développe le framework est lié à l'ORM Bon nombre de frameworks utilisent leurs propres solutions qui proportionnellement à l'investissement global reste une partie sous estimée, et peu développée. Tantôt l'ORM est un mastodonte, tantôt il ne s'agit que d'un mapper du driver sgbd qui execute les requêtes.

Un terrain qui favorisera l'adoption de PMO dans les futurs frameworks.

Je viens de lire ce billet au sujet d'une faille de sécurité Debian: Vendors Are Bad For Security . Les developpeurs debian avaient modifiés les sources de la lib SSL ce qui rendait prédictible les clefs SSH, certificats SSL et ce depuis 2 ans ! voir aussi le blog de Fréderic à ce sujet.

Dormez tranquille ce n'est juste que vos numéros de cb qui étaient en péril, données confidentiels etc (..) Pour faire simple, il faut patcher, regénérer toutes les certificats SSL / clef (..) Un travail titanesque pour toutes les sites web commerciaux qui vont devoir renvoyer également leurs certificats aux autorités d'authentification :/

Plus globalement ça ne fait que me conforter dans l'idée que je me fais de linux et des distributions packagés, de l'open source en général Je fais également parti de la génération qui a utilisé la première distribution slackware.

J'ai toujours trouvé absurde et soutenu que le code open source n'était pas un gage de qualité ou de sécurité en tout cas qu'il n'apportait rien de plus à ce sujet par rapport au code propriétaire d'autant plus quand il était compilé & packagé par des tiers. proprio & open source, ça peut être crade et insecure.

Ce problème de sécurité remet en cause le mode de fonctionnement de cette distribution qui est basée sur la confiance des tiers, le packaging des programmes. Et surtout la plus value qu'elle est censée apporter face à ce type de problèmes.

Ce week end prolongé m'a permis d'explorer un peu plus en avant le développement web java . Je dois avouer qu'en terme de codage java intègre une multitudes de concepts et de fonctionnalités orientés MVC. Je ne survole ici qu'une partie des points que j'ai regardé en utilisant un Tomcat.

Un premier atout de java est le support des objets persistants. Un objet peut être chargé en mémoire en tant que simple classe java. Cet objet servlet peut hériter, entre autre, de l'objet HttpServlet qui propose des méthodes utiles pour manipuler le protocole http. Cet objet peut vivre au sein du serveur pour un temps (in)défini, et communiquer avec des pages jsp invoqué par des appels de navigateur asynchrones.

L'autre intérêt d'utiliser un servlet peut être par exemple de partager des ressources(rôle d'interface au sens UML), de démoniser des services (rôle controlleur au sens UML). Le servlet peut par exemple gérer les accès à une base de donnée et les partager entre les jsp (..)

Ce type d'architecture est déjà très proche du design pattern MVC. En terme de programation web 2.0 c'est redoutable, et je comprends mieux le positionnement de google sur des technos comme GWT. Les jsp peuvent être de simple vue générée dynamiquement et les servlets les controleurs qui opèrent du traitement. Le modèle peut être soit l'un soit l'autre.

Un deuxième atout est la traduction par le serveur java Tomcat - jasper des pages jsp en class java. Le résultat de la logique de transcription est intéressante à analyser . Certes ça n'a qu'un élément intellectuellement séduisant pour comprendre la logique globale de codage.

Pour se faire j'ai utilisé une documentation qui a été publiée sur le site developpez.com qui aborde le processus de traduction (page 70). Sans doc, il est aussi possible à tout moment de plonger les mains dans le code généré par le serveur java pour voir comment la traduction a été opéré. Le code compilé et les sources sont déposés après traitement dans un des répertoires du serveur. Le serveur utilise des objets et méthodes standards de la librairie java qui sont documentées par les javadocs.

En php, lorsque l'on déclare une fonction en dehors d'une classe, elle est considérée comme globale. Cela est du en fait à l'historique php qui jusqu'à php5 ne proposait pas de modèle objet.

En java, si on déclare de la même façon une méthode au sein d'une page, celle-ci sera considéré comme globale au sein de cette page. Java traduit chaque page jsp en objet.

A ce titre mafonctionphp() est visible partout

alors qu'en java, mamethodejava devient

1. unobjet{
2. public mamethodejava(){}
3. }

J'aime (miam). Autant la jsp peut être développé quick&dirty autant le code généré par le serveur reste cohérent avec le modèle objet

Voici un premier récapitulatif de l'en cours du développement de la version 0.15.

• L'arrivé de la classe PMO_MyArray qui remplace les array de PHP. Il s'agit d'un type qui implémente les interfaces PHP SPL iterator, countable. Cette classe n'utilise pas les types natifs de la SPL qui souffre d'un défaut d'implémentation (voir mon précédent post). Cet objet array a "normalement" un comportement cohérent. Lorsque l'on utilise foreach, each, while, fetch pour parcourir le array, on a toujours l'itérateur qui est reset à la fin du parcours :D

• L'utilisation de l'objet PMO_MyArray a rendu inutile l'utilisation d'autres map. PMO_MyMapHash, PMO_MyMapTable et leurs interfaces sont remplacés par PMO_MyArray La plus part des array sont remplacés par PMO_MyArray.

• Les objets PMO_MyObject voient certaines de leurs méthodes comme les initAttribute() disparaitre. Ces méthodes ne servaient plus à rien depuis l'arrivée des objets PMO_MyTable (qui décrivent les schémas de tables) et étaient encore à tord utilisé.

• La gestion des alias au niveau de PMO est supprimé car nous considérons que c'est du bloat code, et qu'il est plus intelligent de gérer les alias au niveau SQL. La gestion des alias sera donc implémenté directement au niveau du parser SQL dans une prochaine version.

• L'arrivée d'une nouvelle classe PMO_MyRequest qui sert à écrire sous la forme d'objet des requêtes SQL

1. $request = new PMO_MyRequest;
2. $request->field('last_name', 'first_name', 'title', 'film_actor.actor_id', 'film.film_id')
3. ->from('actor', 'film', 'film_actor')
4. ->where('actor.actor_id = film_actor.actor_id', 'film.film_id = film_actor.film_id')
5. ->order('last_name', 'first_name', 'title')
6. ->limit('10');
8. $controller = new PMO_MyController;
9. $map = $controller->objectquery($request);

• Un début d'implémentation des clefs étrangère qui permettra de récupérer des objets relatif à un autre objet en lazy loading; La même requête que ci-dessus avec l'usage des clefs étrangères:

1. $table = PMO_MyTable::factory('film_actor');
2. $table->setFk("actor_id", array("actor"=>"actor_id"));
3. $table->setFk("film_id", array("film"=>"film_id"));
5. $request = new PMO_MyRequest;
6. $request->field('last_name', 'first_name', 'title', 'film_actor.actor_id', 'film.film_id')
7. ->from('film_actor')
8. ->getLinked()
9. ->order('last_name', 'first_name', 'title')
10. ->limit('10');

• Le support de memcache pour envoyer ou récupérer plus rapidement sur des serveurs de cache les objets PMO.

Grosso modo, je partage la question que je me pose au sujet de la qualité du code OO en PHP. Comment améliorer la qualité de mon code, comment le normaliser pour minimiser le bloat code ? Au fur et à mesure du développement de PMO, j'ai identifié des vecteurs qualitatifs pertinents qui m'ont permis d'améliorer la scalabilité, la robustesse du code également des exemples de problèmes inhérents à PHP moins reluisants.

Au moment ou on parle d'industrialisation, et ou la communauté PHP commence à découvrir avec béatitude ce que sont les frameworks, les exemples de UGLY code se multiplient.

PHP est un langage hybride qui n'est pas orienté contrôle de qualité. Il permet par exemple de faire des choses très moches comme l'utilisation de la programmation mi procédurale mi objet. Cela est en autre du au fait qu'il n'est pas fortement typé.

Un exemple d'élément dans la production de ugly code: le array

• il n'est pas un objet

• on manipule des données au lieu d'une référence

• il peut stocker en même temps n'importe quel type de donnée

• Si le array est utilisé comme structure de donnée dans un objet et récupérer hors de l'objet via des accesseurs, il devient ANTI OO. La structure de donnée doit être encapsulée, et le array ne doit pas pouvoir être renvoyé à l'extérieur. Dans le cas contraire, on risque de voir du code dupliqué et des logiques metier exportés à l'extérieur des objets. return array = UGLY CODE

Et malheureusement dans le dernier cas, le nombre d'exemples est légions. Cela est du au fait qu'il est aussi possible d'itérer sur les atttributs d'un objets via un foreach. Autant dire que le foreach est à proscrire car potentiellement le code qui l'utilise n'est pas là ou il devrait se trouver. De plus le foreach ne replace pas l'iterateur du array au début de tableau à la fin de l'itération (..) ce qui peut poser problème quand on utilise pour le coup un array encapsulé dans un objet.

Pour pallier au problème du array non OO, je me suis intéressé à l'objet ArrayIterator SPL proposé en natif dans le package standard de PHP. L'implémentation de l'objet n'est pas robuste. Dans certains types de situations, l'iterateur pointe sur rien alors que le tableau contient bien des éléments ! Il est donc fortement déconseillé d'utiliser ce type d'objets tant que ce type de problème ne sera pas résolu.

• EEE pc : retour après quelques semaines d'utilisation. Xandros ne propose quasiment pas de programmes (pourquoi ne pas avoir choisi DEBIAN ???). L'expérience de linux sur le bureau est pauvre à côté de XP, galère pour installer des programmes, rajouter des icones, jouer (..) . L'eee PC souffre d'une résolution qui a mon gout est trop réduite pour le surf confortable, et un clavier trop étroit pour le travail. En revanche, c'est un allié indéniable pour la mobilité, et également en tant que serveur confère ce blog (prix / consommation electrique excellent).

• EEE pc bis: l'eee pc est excellent pour monter un serveur web perso / blog confère ce post . Si j'osais je partirais même avec en week end pour bénéficier à la fois de l'atout mobilité, et blog. Vous savez à quoi vous attendre si un week end ce blog, ne répond plus

• Immobilier: La fnaim annonce 1% de baisse premier trimestre 2008, 3% sur l'année. A côté les reportages, articles sont légions qui font état de 10% de baisse voir 20% de baisse ! La cause: le marché est innondé de bien neuf qui ne se vendent pas. De même les propriétaires de neuf louent leurs biens à hauteur du cout de leur prêt ! Les loyers sont trop élevés et n'attirent plus personne, les propriétaires doivent vendre. Voir "envoyé spéciale" cette semaine sur les familles qui se sont endettées avec les lois ROBIENS.

• Apple: Le mac book air c'est vraiment bof. 1 Prise usb, pas moyen d'attacher un cable kingston et donc de le déplacer. Un os qui ne m'a pas convaincu. Pour un portable, ça fait un peu léger (..) 1700 euro la bestiole (..)

• PMO: Pour mieux suivre le projet, Laplix a mis un trac en place. Qu'on s'est efforcé de remplir avec plein de bugs (sans doute plus qu'il n'en faut pour nos petits doigts). Laplix a fait excellent travail sur les commentaires (cf timeline)

• Ohloh référence PMO et estime le cout du projet à 13k et moins d'une personne sur 1 ans :D

• Reprise des cours: Comme j'ai particulièrement apprécié le cours Recherche opérationnelle et décisionnelle (algo du simplex), je re-signe pour 6 mois supplémentaire la même matière en avancé :p Au programme du simplex dans tous les sens, un bien fait que je ne pourrais que vous conseillez.

• Bruno: a sorti une nouvelle série. J'ai du mal à le suivre. Une femme géante qui arrive de l'espace ?

• ryzom est mort :/ , c'est ce que laisse supposer le rachat du domaine .fr par un inconnu. En tout cas pas de communication sur le site officiel, ce jeu aura souffert tout au long de sa vie de ce travers.

• j'ai testé Rappelz, pas à la hauteur de Ryzom mais sympa quand même.

• L'association Kokopeli condamné pour concurrence déloyale (..)