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 :-)

la suite...

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 :

• LiveDocX est tourné vers le format propriétaire de Microsoft : le Docx. Comme je n'ai ni Windows ni MSOffice et que j'aime pas les formats fermés, propriétaires, complexes et payants (*voila j'ai fini de troller*), j'ai failli m'arrêter là, mais en cherchant un peu : ça fonctionne avec OpenOffice !
• LiveDocX est une service Web : La fusion du template se fait en ligne sur le processeur de la machine distante, les temps de réponses sont donc aléatoires (sauf si vous payez le service, ce qui est facultatif) et les données que vous envoyez sont ainsi susceptibles d'être mémorisées, vous n'en savez rien (même si bien sûr on vous affirme le contraire)
• LiveDocX tourne sur HTTPS, il faut avoir compilé PHP avec le support de SSL (OpenSSL) pour que le gestionnaire de flux PHP utilisé par ext/soap puisse se connecter sur le service
• Puisqu'il s'agit d'un service Web, inutile de vouloir faire de la fusion de templates hors ligne ou avec une connexion Internet "foireuse"
• LiveDocx va plus loin que odtPHP dans la mesure où il permet une sortie dans différents formats, dont PDF, BMP etc...

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) ^^

la suite...

Lorsque je parcoure le code du Zend Framework, je vois souvent des conditions écrites sous cette forme :

if (0 == $argc) {
  // ...
}

en lire plus

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 :

• PHP n’est plus “le langage pour faire des formulaires de contact”
• Javascript enrichit visuellement la page (et plus seulement avec des alert)
• Les GIF animé ont disparu
• Linux a enfin une vraie distribution orientée utilisateur avec Ubuntu
• ASP, Perl, ColdFusion…
• Les smartphones (surtout depuis l’iPhone)
• La vitesse de connexion à Internet, permettant d’y faire passer la TV et le téléphone
• La sécurité des technologies Microsoft
• Les charlatans qui imaginaient se faire rapidement du fric avec une start-up
• La gestion de configuration, de Subversion à Git

Ce qui n’a pas changé depuis 2000 :

• Flash met le feu au CPU
• Java rame
• Internet Explorer 6 est la lie de l’humanité
• Les Design Pattern, à toujours avoir dans sa caisse à outils
• Google
• L’interprétation des pages par les navigateurs, obligeant à patcher pour chacun d’entre eux
• Les commerciaux qui ne comprennent toujours rien à la technique
• Les développeurs  vus comme des ours mal léchés
• Les charettes dans les agences Web
• Les protocoles utilisés sur Internet
• Il manque toujours un truc à MySQL
• L’open source est un laboratoire de bonnes idées
• La loi de Moore
• La loi de Murphy

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.

la suite...

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 :

• volume de données important (près de 500000 comptes utilisateurs à injecter dans des sfGuardUser, sans compter toutes les données dépendantes) qui aurait abouti à des fichiers YML longs à vérifier,
• changements profonds dans la structure de la base de données entre la V1 et la V2
• avoir le contrôle sur les données importées (notamment connaitre le nombre d’erreurs et leur nature)
• pouvoir tirer malgré tout parti de la puissance de Symfony (Validators, Doctrine…)

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 :

• utilisation de la méthode free d’un objet Doctrine qui libère les ressources allouées à l’objet, et se débarrasse des références circulaires
• utilisation de unset($obj) pour supprimer la variable complètement.

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.

la suite...