


Un ex-collègue de boulot à moi (mais toujours collègue tout court
), Guillaume Plessis, a monté il y a quelques temps un projet de dépot de paquets PHP qu'il a nommé DotDeb. C'est un dépot de paquets debian concernant principalement PHP5.
L'avantage par rapport aux sources de paquets officielles, c'est que dotdeb est beaucoup plus à jour, et on y trouve beaucoup plus de choses.
Suhosin, xdebug, apc, memcache, ffmpeg ou encore geoip : tout y est sous forme de paquets .deb
Sans parler de PHP5.3.1 (donc toute dernière version à la date de ce billet), ce qui est plus que rare aujourd'hui dans des dépots officiels !
Une seule adresse : http://www.dotdeb.org/
Personnellement, je préfère toujours la solution compilation manuelle aux paquets. Bon c'est normal, je suis un technique qui ne passe pas une journée sans ouvrir la source de PHP, je développe de plus en plus en C dans PHP Core ou Zend Engine, il est pour moi inconcevable de tourner avec des versions provenant de paquets et intégrant des patchs non officiels divers et variés.
La solution des paquets est intéressante par contre dans d'autres situations : simplicité d'installation, gestion des dépendances et surtout déploiement sur plusieurs postes et maintient à jour des distrib !
Pour PHP5.3, utilisez le dépot http://php53.dotdeb.org
Toute l'initiative est libre, n'importe qui peut participer au projet dotdeb si ça lui chante, et trouvera de l'aide sur le site officiel si besoin
Voyez aussi cette vidéo interview du fondateur de dotdeb par PHPTV
PS : pour les adeptes d'Ubuntu - comme moi - dotdeb est prévu pour Debian, vous pouvez donc l'utiliser sous Ubuntu, mais vous aurez des problèmes de dépendances à résoudre.
Soit vous tâtez dpkg et ses amies, et donc vous saurez re-construire les paquets pour votre distrib, soit sinon vous devrez télécharger les paquets à la main. Pour celà, fouillez le site de dotdeb, et notamment les commentaires de certains billets qui donnent une aide précieuse.
Inutile donc de trop harceler l'auteur : dotdeb ne supporte pas officiellement Ubuntu, par contre je suis sûr que Guillaume serait enchanté si quelqu'un pouvait l'aider à monter un support Ubuntu pour dotdeb :-)
Voila quelques temps j'ai sorti odtphp, un script PHP qui analyse des fichiers odt à la recherche de "tags" et qui les remplace par des données que vous fournissez.
C'est très pratique pour générer des factures ou d'autres documents basés sur un template odt et une source de données type MySQL.
Bon, même si le code n'est pas super bien écrit (il utilise des regex assez complexes, j'aurai préféré jouer avec OpenDocument et DOM mais on a passé le projet en Opensource, n'importe qui peut donc s'y atteler
, ça fonctionne dans la grande majorité des cas.
Aujourd'hui je me suis penché sur LiveDocx. Il s'agit d'un service Web SOAP, qui est capable de faire la même chose que odtPHP, avec quelques différences :
Cerise sur le gateau, il existe un service Zend Framework qui permettra donc d'éviter de lire l'API. Zend_Service_LiveDocx est tout petit et tout simple à utiliser
Concernant la compatibilité OpenOffice, lisez donc ce billet (jusqu'au bout)
J'ai testé, et ça fonctionne très bien (un peu lent, mais je suis sur un compte gratuit) ^^
Lorsque je parcoure le code du Zend Framework, je vois souvent des conditions écrites sous cette forme :
if (0 == $argc) { // ... }
En même temps que s’achevait cette décennie, je passais fin janvier le cap de 10 ans de programmation en milieu professionel. L’occasion de m’essayer à une petite synthèse@ sur les changements survenus entre 2000 et 1010.
Ce qui a changé depuis 2000 :
Ce qui n’a pas changé depuis 2000 :
La liste est bien entendu pas exhaustive et totalement subjective. Vous voyez d’autres changements (ou pas) pendant cette décennie ?
Beaucoup de choses ont été dites à propos du truc révolutionnaire que facebook nous préparait pour php. Les spéculations sont allées bon train. On a eu droit à du JIT (très en vogue actuellement, notamment grace à LLVM), une réécriture du runtime de php, j'en passe et des meilleurs.
Finalement, l'info officielle est tombée le 2 fev via un post du lead developer en personne, Haiping Zhao. Inutile de vous dire que ce mec là, aux allures très sympathiques par ailleurs, va être soit adulé soit haï par toute la communauté php, du simple rédacteur de templates aux membres les plus influents du PHP Group.
OK. Donc le truc s'appelle HipHop for PHP (lien de github, qui n'existe pas encore à cet instant précis). Je ne vais pas revenir sur ce que l'on apprend à partir du post officiel de Haiping. Pour ça, je vous conseille ces deux billets en fançais ou encore celui là.
Maintenant, que pouvons-nous dire d'autre sur HipHop? Tout d'abord, j'ai comme l'impression que le code source ne sera pas divulgué de si tôt contrairement à ce que l'on pouvait attendre d'après le post officiel (en fait, j'espère que je me goure). HipHop et toute sa suite doit être une usine à gaz, tout du moins sous sa forme actuelle, c'est à dire spécifique à facebook. Voir les interventions de Scott MacVicar et Haiping Zhao ici et ici sur le google group du projet. HipHop utilise CMake comme build system. SCons ça l'aurait mieux fait quand même!
Ensuite, comme attendu, toutes les extensions de php (standard et tiers) doivent être réécrites. Haiping dévoile une liste du travail déjà accompli. Un peu plus bas dans cette même thread, on apprend que PDO sera supporté, tout du moins l'interface pour les quelques drivers les plus utilisés.
Retour d’expérience sur un projet avec Symfony, où il est question de consommation de mémoire excessive et de volumétrie.
Le site à réaliser est un portage d’un ancien projet PHP vers Symfony 1.2 + Doctrine. Un point d’attention en particulier touche à la reprise des données existantes du site V1 tournant sous un antique MySQL 3.23 et un stockage MyISAM.
Le développement d’une pake task a été privilégiée au détriment de fixtures YAML :
Quelques points sont cependant importants à vérifier.
1) Attention aux fuites mémoire avec les objets
L’import des données a donné lieu a de nombreuses boucles pour fabriquer les objets Doctrine. Ces derniers utilisent beaucoup de références circulaires, que PHP ne gère plus depuis la 5.2.5.
Ceci se résoud avec deux appels importants :
La 1ère version du script qui engloutissait la mémoire, passe désormais sous une barre satisfaisante de 128M. Une boucle de traitement sur une ancienne table donne ceci :
foreach ($results as $datav1) { $o = new ObjectV2(); $s->name = $datav1['name']; $o->save(); $o->free(); unset($o); }
2) Faire travailler au maximum MySQL plutôt que PHP
Nous avons trouvé des adresses emails folkloriques dans les comptes utilisateurs : des valeurs avec espaces et des formats d’adresses non-standard principalement, qui ont fait hurler sfValidatorEmail tout le long de l’import.