Archive for the ‘php’ tag
PHP et les timezones
Dès lors qu’une application est utilisée à différents endroits du globe, il faut gérer le stockage et l’affichage des dates selon les timezones.
La première question qui vient est : quelle référence de temps utilise t-on ?
Si l’application stocke les dates selon la timezone de l’utilisateur qui créé un contenu, il peut vite devenir difficile de convertir cette date dans la timezone de l’utilisateur qui va consulter ce contenu.
Une solution (pourrie) pourrait être de calculer le différentiel entre la timezone du créateur et celle du lecteur. On imagine le casse tête.
Je pense que le bon pattern consiste à stocker systématiquement les dates sous forme de timestamp calculés sur une base GMT ou UTC, grâce à la fonction time(), et à les afficher avec la fonction date() qui prend en compte la
timezone système PHP (valuée avec date_default_timezone_set).
Le problème n’est qu’à moitié résolu.
Imaginons une application de calcul de statistiques qui stocke des données tous les jours, à 23h, en indexant chaque entrée sur le timestamp correspondant à l’heure du calcul.
Exemple :
Je suis en France et je consulte les statistiques du jour avec le timestamp de référence suivant :
mktime(23, 59, 0, date(“m”), date(“d”), date(“y”));
Hiro est au Japon et consulte les statistiques en recherchant les entrées possédant ce timestamp de référence. Et bien il n’en trouvera pas….
Car le résultat du mktime n’est pas le même.
Pour être sûr de convertir des dates en timestamp sur les même bases, il faut utiliser une fonction méconnue en php :
Elle s’utilise de la même manière mais calcule tout sur une base GMT.
Donc pour résumer :
- les dates sont stockées en GMT
- elles sont affichées avec date(), en ayant précédemment valué date_default_timezone_set
- les converstions date -> timestamp se font avec gmmktime au lieu de mktime
Je suis preneur de vos retours.
Happy coding
ZendCon Sessions Episode 043: Improving QA on PHP Projects
Intégrer dans VI des man pages UNIX pour la documentation PHP
You made my day dude !
C’est ce que j’aurais dis à Hannes Magnusson, développeur systèmes en Suède, quand j’ai lu son billet “Unix manual pages for PHP functions”
Il s’agit d’installer les fameuses man page UNIX pour toutes les fonctions PHP.
A quoi cela peut il bien servir ?
Tout d’abord, à avoir de la documentation en ligne de commande, sans avoir à lancer un navigateur Web. Très utile quand la connexion internet est limitée ou lorsqu’on est en train de modifier du code sur un serveur de production (ce qui bien sûr ne devrait jamais arriver).
Mais surtout, l’installation de ces pages permet d’obtenir la documentation des fonctions PHP directement dans le code PHP, dans VI, mon éditeur préféré et probablement celui de tous les vieux développeurs barbus.
Let’s rock !
Installer le package pman depuis PEAR (je ne vais pas détailler ici comment installer ou configurer PEAR) :
$ pear install doc.php.net/pman
Si vous utilisez une vielle version de PEAR, il faut ajouter doc.php.net aux repositories :
$ pear channel-discover doc.php.net
puis relancer pear install
C’est fait !
Normalement, en tapant :
$ pman strstr
On obtient une man page UNIX documentant de façon extrêmement complète la fonction PHP strstr
Enfin, pour intégrer cela dans notre éditeur préféré, ajoutez juste la ligne :
set keywordprg=pman
dans le fichier .vimrc de votre profile.
Ouvrez un fichier PHP, positionnez le curseur sur une fonction PHP et appuyez sur “K”.
Magie…. une man page apparaît avec le descriptif de la fonction pointée.
Evidemment, comparé aux nouveaux IDE surpuissants, ce n’est pas grand chose. C’est un peu comme trouver un émulateur SuperNes pour Linux, ou utiliser Lynx pour naviguer sur le web. En tout cas, ça me rappelle qu’en informatique, on peut faire de belle chose avec de petits moyens.
A bon entendeur !
Consommer un service web oauth en PHP avec Zend_Oauth
Oauth est un protocole créé en 2007. Il permet aux applications web, mobiles ou de bureaux, d’accéder à des services distants via des API, sans demander aux utilisateurs d’exposer leurs identifiant / mot de passe.
Oauth est largement utilisé par Google, Twitter ou encore LinkedIn pour ne citer qu’eux.
Auparavant, l’API twitter n’est disponible qu’en passant le twitterId et le mot de passe de l’utilisateur dans l’URL du service. Cela supposait donc que les applications utilisant l’API gardaient ces informations et pouvaient donc les utiliser à mauvais escient.
Dans ce billet, j’essaye d’expliquer comment consommer un service Oauth, avec un des composants PHP du Zend Framework.
Comment utiliser les locks avec des tâches CRON en PHP ?
On utilise souvent les jobs CRON pour effectuer des traitements lourds en tâches de fond : calcul de statistiques, conversion d’image, envoi de mail etc…
L’inconvénient de CRON par rapport à d’autres systèmes de jobs intégrés dans les plateformes J2EE ou .NET, c’est qu’il ne gère pas le “chevauchement” des tâches.
Je m’explique : imaginons une tâche lancée toutes les heures et qui prend 30 min pour traiter un 1Go de données. Si la taille des données augmente, ce que nous souhaitons tous pour nos applications, le traitement s’effectuera peut être en plus d’une heure. Que se passe t-il alors si la tâche est relancée alors que l’occurrence précédente n’est pas terminée ? Au mieux, les données peuvent être corrompues, au pire, la plateforme peut tomber sous le poids des traitements.
Voici donc une façon de gérer les “lock” en PHP, afin de garantir qu’une occurrence de tâche CRON s’exécute si et seulement si la l’occurrence précédente est terminée.