Alheim

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 :

gmmktime

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

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.

Read the rest of this entry »

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.

Read the rest of this entry »

Je suis tombé sur cet article, utile pour les développeurs débutants, mais qui pourrait susciter le débat.

Il s’agit de 5 conseils pour condenser certaines écritures PHP.

Comme vous le savez, PHP n’est pas un langage compilé, un gain de place pourrait donc être un gain de performance lors du chargement des fichiers.

Mais est ce que cela rend le code réellement plus lisible ?

1- Ternary operator

Soit le code :

if ($b>10) {

$val = true;

} else {

$val = false;

}

On pourrait le remplacer en une seule ligne :

$val = $b>10 ? $val = true : false;

Certes c’est plus court mais que ce passe t-il si on veut rajouter une condition :

$val = $b>10 && $c<30 ? $val = true : false;

Cela se complique. Il m’est arrivé souvent de "casser" une ligne contenant un opérateur ternaire lorsque les conditions se complexifient. Attention donc à ne pas en abuser.

2- Utiliser la récursion

L’auteur de l’article nous explique qu’utiliser la récursion peut racourcir la longueur du code. On gagne donc en place. Mais que perd on à enchainer un nombre plus important d’appel à des méthodes ?

Je ne suis pas sûr que ce soit un gain dans tous les cas. Deplus, les récursions ne sont pas faciles à apréhender dans tous les cas.

…

Les autres points sont tout aussi discutables.

Je pense donc qu’il faut se méfier et ne pas faire la course au code le plus court, et souvent le plus obscur. Surtout lorsque l’on est plusieurs à travailler dessus. Mieux vaut trouver de bon standards et s’y tenir.

Je me souviens des IOCC, dont le but était de créer des code en C le plus court possible et exécutant des tâches complexes.

Original article writen by Alexandre Heimburger and published on Alheim | direct link to this article | If you are reading this article elsewhere than Alheim, it has been illegally reproduced and without proper authorization.

Ce soir je suis tombé sur cet article  qui décrit une méthode particulièrement astucieuse pour éviter de se faire spammer sur les formulaires.

Alors bien sûr, il existe la fameuse captcha, mais je ne la trouve pas satisfaisante. Parfois, les séquences sont quasi-illisibles et cela rajoute de la complexité dans la saisie des formulaires. En ces temps où l’on cherche à simplifier et améliorer l’expérience utilisateur, nous devons penser à d’autres systèmes.

L’auteur nous explique sa méthode en se basant sur l’analyse suivante :

- les robots remplissent tous les champs de formulaire

==> l’ajout d’un champs masqué en css dans le formulaire permet de vérifier si le formulaire a été rempli par un être humain. Dans le code de soumission du formulaire, en vérifiant la présence de cette variable dans le POST, on peut vérifier la provenance.

- les robots remplissent les formulaires à une vitesse non humaine

==> en vérifiant le temps qui s’est écoulé entre l’affichage du formulaire et sa soumission, il est possible de vérifier si il a été rempli par un être humain.

Vous pourrez trouver la librairie PHP écrite par le bloggueur. Elle est particulièrement bien écrite.

Est-ce une bonne solution ? Comment un robot pourrait la contourner ? Vos avis ?

Original article writen by Alexandre Heimburger and published on Alheim | direct link to this article | If you are reading this article elsewhere than Alheim, it has been illegally reproduced and without proper authorization.

Voila un exemple de code absolument fantastique.

Aucun nom ne sera cité mais le leitmotiv de l’auteur est : "keep it stupid simple". Je vois bien le côté stupide mais qu’est ce qu’il y a de simple la dedans ?

Faisons un jeu :

- comment réduire ce bout de code en 3 lignes ?

- rien ne vous choque sur la structure de la table USERS ?

$password = $_POST['password'];

$sql  = "Select username from USERS";
$q->query($sql);
while($q->next_record())
{
    $chumbawumba = $q->f("username");
}

if ($password == $chumbawumba)
{
    header("Location: index.php?session=".$session);
}
else
{
    $errorMsg = "Wrong Password. Please Try again!";
}

Original article writen by Alexandre Heimburger and published on Alheim | direct link to this article | If you are reading this article elsewhere than Alheim, it has been illegally reproduced and without proper authorization.