Roms BLOG

Comme annoncé hier, free est en train de refondre son site http://mobile.free.fr afin de supporter la charge induite par leur annonce de forfait tout compris à 15,99€. JSP ne tenait pas le coup, qu’à cela ne tienne, on passe à PHP.

Les services sont montés et remis en ligne au fur et à mesure. Hier nous avons d’abord eu droit à la partie inscription pour les freenautes avec son lot de bugs notamment dans la validation des ribs (relevés d’identités bancaires) ce qui a rendu un paquet de monde hystérique au point de chercher des solutions pour générer de faux ribs permettant de valider leur inscription.

Ce matin c’est la partie inscription pour les non freenautes qui a été mise en ligne. Espérons que cela se déroule mieux pour eux.

En tout cas, ces mises en ligne nous permettent de comprendre un peu mieux comment fonctionnent les équipes de développement de Free. Si vous allez faire un tour sur la partie inscription pour les non frenautes (rapidement, car j’imagine que ce bug va vite disparaître), vous pourrez voir que le lien, en haut de page qui mène vers la section « Espace abonné » pointe en fait vers http://localhost:8080/moncompte/.

Quoi? Pas de tests chez Free? Du développement en local qui semble directement passer en production sans passer par un serveur de dev. ou de pré-prod?

Tout cela ressemble bien à la méthodologie « La Rache » qui permet de produire vite mais sans trop s’attarder sur la qualité du code

Ceci dit, et étant donné, d’une part, le contexte dans lequel ce site est redéveloppé et, d’autre part, la simplicité du code à produire, je crois que la décision peut se justifier.

J’en déduis également que la prochaine étape sera donc la remise en ligne de la partie « abonnés ».  Les premiers isncrits pourront  enfin valider que la procédure a bien été prise en compte correctement.

Quoi qu’il en soit, et en toute franchise, je tire mon chapeau à Free qui a pris un décision difficile (refonte du site) en un temps record et qui est pas loin de gagner son pari!

Dernier volet de mes tutoriels sur l’utilisation de FPDF avec PHP, nous allons voir aujourd’hui comment générer un sommaire avec des liens dans un document PDF.

FPDF propose nativement des méthodes pour générer des liens internes dans un  document :

• addlink() qui créé un lien et retourne son identifiant. Pour le moment, notre lien n’est qu’une ressource, il va maintenant falloir l’associer à un texte et ensuite préciser où ce lien doit pointer. Pour cela, il faut utiliser par exemple, la méthode cell() (qui permet d’écrire du texte) en lui passant en paramètre  l’identifiant du lien.

• SetLink() va enfin nous permettre de préciser la destination du lien. Nous l’utiliserons sur la page où le lien doit pointer

class myfpdf extends fpdf {
    public $myLinks = array();
}

<?php
...
//le numéro de la page
$numPage = 1;

//le titre de la page
$titrePage = 'première page';

//on créé un lien
$fpdi->myLinks[$numPage] = $fpdi->addLink();

// on écrit le nom de la page et on y associe le lien
$fpdi->cell(185,5,$titrePage,0,0,'L',$fpdi->myLinks[$numPage];

//on écrit le numéro de la page
$fpdi->cell(5,5,$numPage,0,2,'R',TRUE);

?>

<?php
class myfpdf extends fpdf {
    public $myLinks = array();

    public function addPage() {
        //on génère la page en appelant la méthode
        //parente addPage()
        parent::addPage();

        // si un lien existe pour ce numéro de page,
        //on l'associe à la page
        $page = $this->pageNo();
        if (isset($this->myLinks[$page])) {
            $this->setLink($this->myLink[$page]);
        }
    }

}
?>

Avec le lancement de ma nouvelle société AlliaForm qui propose des salles de formations équipées en informatique à Bordeaux, j’ai décidé de revenir à mes premiers amours et de proposer des formations à PHP sur la région Aquitaine.

Je reprends donc avec un premier cursus de Niveau 1 dont vous pourrez trouver le plan ci-dessous :

Formation PHP Bordeaux : Apprendre à développer avec PHP

N’hésitez pas à me faire vos retours sur son contenu.

D’autres cursus devraient voir le jour dans les semaines à venir.

Voilà,
après plusieurs mois de travail et d’enfermement chez moi, le grand jour de la mise en ligne de waDaWeDo est enfin arrivé.

http://www.wadawedo.com

waDaWeDo est une application de partage d’agenda et d’événements sur Facebook. waDaWeDo permet de :

- Créer des événements évolués et les partager avec vos amis ou le monde entier
- Gérer votre agenda personnel grâce aux événements privés
- Consulter l’agenda public de vos amis et commenter ou rejoindre leur événements
- Trouver des événements publics proche de chez vous et les rejoindre
- …

waDaWeDo est accessible de 2 façons. Via sa page principale http://www.wadawedo.com mais également sous forme d’application Facebook http://apps.facebook.com/wadawedo/

Bien sûr, l’accès à waDaWeDo est entièrement gratuit.

Au niveau technique, waDaWeDo repose sur trois technologies. Bien sûr, du PHP (sans framework) et du MySQL, avec une architecture adaptée à Facebook.
Mais, grande nouveauté pour moi, tout le ‘front’ repose sur du jQuery ce qui permet de limiter la charge côté serveur à de simples appels de données.

Je vous invite à aller l’essayer et à me faire vos retours.

Ha oui, pour finir, je vais revenir au début de cet article, plus exactement au titre où je parle de ‘pré-lancement’. J’ai décidé de regarder comment la plateforme réagissait avant de considérer que nous étions dans une phase de lancement officiel.
Ceci dit, il ne faut surtout pas que ça vous empêche d’en parler autour de vous, bien au contraire. je compte, dans un premier temps, sur le bouche à oreille pour la faire connaître, alors n’hésitez pas à bloguer, twitter, Facebooker, mailer…

Les places du 1er TEDx à Bordeaux enfin disponibles !!

Depuis 25 ans, la conférence TED rassemble des esprits brillants, dans des domaines très variés, pour qu’ils partagent leurs idées avec le monde. Bordeaux a enfin sa conférence TEDx ! Elle aura lieu le samedi 28 Mai prochain à l’auditorium du CAPC (Musée d’art contemporain de Bordeaux) autour du thème “ENSEMBLE”.

Cette conférence a pour objectif de réunir les personnes qui, à Bordeaux et dans sa région, sont et seront les acteurs des changements de demain.

10 intervenants, experts dans leurs domaines, disposeront de 18 minutes maximum pour changer le monde, ou plus modestement pour diffuser des idées qui méritent d’être partagées.

Un après-midi exceptionnel pour vivre l’expérience TEDx avec 160 participants, 10 intervenants et une équipe d’organisation bénévole réunie dans l’association TEDxBordeaux.

Alors rejoignez l’aventure et rendez-vous vite sur www.tedxbordeaux.com pour réserver vos places !

http://www.tedxbordeaux.com/participez/

On ne le répète jamais assez, il ne faut jamais faire confiance aux données en provenance des utilisateurs.
Et l’origine de ces données ne se limite pas à POST et GET!

Des petits malins se sont inspirés de cet adage pour tenter t’attaquer les radars fixes :

injection sql radar fixe

Bien sûr, je pense qu’il s’agit plus d’une blague que d’une véritable tentative d’attaque mais je trouve l’idée vraiment inventive.

Source : http://www.tux-planet.fr/comment-pirater-un-radar-automatique/

Je viens d’entamer mon périple pour revenir du Web Development summit, quelques 22 heures pour faire Seattle -> New-York -> Paris avec dix heures d’escale dans l’aéroport de la grande pomme.

Je suis actuellement dans l’avion entre Seattle et New-York, siège 20C, nous avons décollé depuis 20 minutes…et je suis connecté en wifi!

Alors qu’en France, il est encore rare d’avoir une prise électrique dans un TGV, de l’autre côté de l’atlantique, les avions sont équipés en internet haut débit. Non pas que je veuille être critique envers la France – dans bien des domaines nous sommes au même niveau voir en avance sur les autres – mais là, je suis bluffé par le décalage.

Je ne voudrais pas dire de bêtises, je viens donc de faire une recherche sur Google pour vérifier si cela n’existerait pas également en France, il est vrai que je ne prends pas l’avion si souvent que cela et que certaines lignes sont peu être également équipées. Tout ce que j’ai trouvé, c’est le blog d’une personne tout excité, en Février 2008, d’expérimenter la première et unique ligne d’Air France permettant d’envoyer des textos et de faire du WAP en plein vol…MDR, du WAP, je ne savait pas que cela existait encore!

Faisons quelques tests. Je vais commencer par accéder à mon Facebook. La page d’accueil me dit « Vous vous connectez d’un endroit inhabituel. Par sécurité, veuillez confirmer votre compte ». Tu m’étonnes que je me connecte d’un endroit inhabituel, je suis à plus de 10 000 pieds d’altitude, me déplaçant à une vitesse de 700 km/h.

Petit test de performance sur YouTube. Les videos sont super fluides, pas de latence, c’est plus rapide qu’à mon bureau.

Bien sûr, tout cela n’est pas gratuit, 10$ pour la durée d’un vol mais heureusement, le temps du décollage, j’ai feuilleté le magasine de la compagnie, vous savez le truc qui se trouve dans la poche du siège devant vous, généralement plié en deux, bourré de pubs et qu’on ne lit jamais.
Bien là, je ne sais pas pourquoi, je l’ai parcouru et suis tombé sur une pub pour le service internet en question avec un code permettant de se connecter gratuitement la première fois (« DELTATRYGOGO » pour ceux que ca intéresse).

Sur ce, je vous laisse, je vais lire mes mails et continuer mon vol sur internet…

J’étais en train de jouer avec mon fils et son super Quad spider-man à piles qui avance tout seul, quand tout à coup, un mot venu de mon enfance a surgit dans mon esprit, « stompers ».
Un coup de recherche Google et tout revient. Les courses avec mon frère, les combats en face à face, les versions étanches pour jouer dans la piscine…

Les stompers étaient des jouets à la mode aux US au début des années 80. Il s’agissait de mini 4×4 (10-15 cm) à grosse roues qui avançaient tout seuls grâce à des piles. Certains disposaient même de plusieurs vitesses!

Vraiment de bons souvenirs. Je me demande si cela a existé en Europe.

Quelqu’un qui s’en souvient?

Pour la plupart des projets, l’utilisation de echo et de var_dump() suffit pde our debugger vos scripts. Le mode web est en « page à page », il est donc rare d’avoir des scripts de plusieurs milliers de lignes comme on pourrait en avoir avec les langages compilés. Il peut toutefois parfois être intéressant de faire du debuggage pas à pas et de pouvoir jouer avec les valeurs de vos variables. Je me propose donc de vous montrer comment configurer cela avec WampServer, l’extension XDebug et l’IDE PDT (Php Developpment Tool).
 
 
INSTALLATION DE XDEBUG AVEC WAMPSERVER

Commençons par installer l’extension XDebug. XDebug permet de faire trois choses :

- améliorer la gestion des erreurs de PHP (afficher plus d’informations lors d’erreurs PHP, optimisation de la présentation de var_dump());

- faire du profiling (à utiliser avec kcachegrind ou wincachegrind);

- debugger vos scripts.

Téléchargez l’extension sur le site de XDebug : http://www.xdebug.org

ATTENTION : pensez bien à télécharger la version qui correspond à la branche de PHP que vous utilisez (PHP 5.2 ou PHP5.3) et à prendre la version thread-safe.

A l’heure où j’écris ces lignes,
pour PHP 5.2 : http://www.xdebug.org/files/php_xdebug-2.0.5-5.2.dll
pour PHP 5.3 : http://www.xdebug.org/files/php_xdebug-2.0.5-5.3-vc6.dll

XDebug n’est pas un extension standard de PHP, nous n’allons donc pas la mettre dans le répertoire /ext/ de PHP afin d’éviter d’éventuels conflits avec le menu de WampServer. Je vous propose donc de la déposer dans le même répertoire que l’exécutable de PHP (php.exe), typiquement :

c:\wamp\bin\php\phpx.x.x\

Renommez l’extension en php_xdebug.dll, elle sera plus facile à manipuler.

Nous allons maintenant l’activer. Pour cela nous allons devoir ajouter des commandes dans le fichier php.ini. Dans WampServer, le fichier php.ini utilisé se trouve dans le même répertoire que le binaire d’Apache (apache.exe). Le plus simple pour l’ouvrir est de passer par le menu de WampServer.

Allez à la fin du fichier et ajoutez les lignes suivantes :

zend_extension_ts="c:/wamp/bin/php/phpx.x.x/php_xdebug.dll"
xdebug.remote_enable=1
xdebug.remote_host="127.0.0.1"
xdebug.remote_port=9000
xdebug.remote_handler="dbgp"
xdebug.remote_mode=req

où x.x.x est votre version de PHP.

En complément, vous pouvez également ajouter

xdebug.profiler_enable = 1
xdebug.profiler_output_dir = "c:/wamp/tmp/"

afin d’activer les fonctions de profiling, ou encore

xdebug.collect_params = On
xdebug.show_local_vars = On

afin d ‘améliorer les informations fournies lors de l’affichage des messages d’erreur.

Une fois ces lignes ajoutées, refermez le fichier php.ini et redémarrez votre service Apache, XDebug devrait maintenant être chargé.

Pour le vérifier, affichez votre phpinfo(). Vous devriez voir apparaître l’information ci-dessous :

Si ce n’est pas le cas, vous avez certainement fait une erreur dans le chemin d’accès au fichier php_xdebug.dll

A ce stade, vous pouvez dors et déjà profiter des fonctions d’amélioration des messages d’erreur de XDebug. Pour cela, essayez d’afficher un message d’erreur et un var_dump().
 
 
CONFIGURATION DE PDT AVEC XDEBUG

Nous allons maintenant configurer PDT pour qu’il utilise les fonctionnalités de debuggeur de XDebug.

Si ce n’est pas déjà fait, commencez par télécharger et installer PDT : http://www.eclipse.org/pdt/

Lors du lancement de PDT, choisissez « c:\wamp\www » comme WorkSpace.

Dans le menu du haut, choisissez window -> preferences.

Rentrez maintenant dans le menu « PHP » et cliquez sur « debug ».

Il existe deux façons de debugger du PHP avec PDT. La première (server) passe par votre serveur web en faisant un appel à localhost. La deuxième (PHP executable) fait un appel direct à l’exécutable de PHP.
Nous allons travailler avec la première solution qui nous offre plus de fonctionnalités et permet, notamment, d’utiliser les méthodes GET et POST.

Par défaut, PDT est livré avec des configurations type pour fonctionner avec XDebug et Zend Debugger. Comme le montre la capture d’écran ci-dessus, choisissez XDebug.

Si votre serveur n’est pas local (localhost), il faudra également modifier la configuration de votre serveur identifié sous PDT par « Default PHP Web Server« .

Voilà, la configuration de base de PDT est terminée, nous allons maintenant pouvoir utiliser PDT pour debugger en mode pas à pas et avec des points d’arrêt.
 
 
UTILISATION DE PDT COMME DEBUGGEUR

Voyons maintenant comment utiliser tout cela. La première chose à faire est de créer un nouveau projet PHP au sein de PDT. Pour cela cliquez sur file -> new -> PHP Project.

Donnez un nom à votre projet (dans la suite de cet article, notre projet s’appellera « test_debug »).
Un répertoire du même nom va être automatiquement créé dans votre répertoire « www ». Vous allez placer ou créer vos scripts PHP dans ce répertoire. Si nécessaire, appuyez sur F5 dans PDT pour que vos scripts apparaissent.

Ouvrez votre script PHP en double cliquant dessus. Votre code source devrait apparaître dans la fenêtre centrale de PDT.

Nous allons maintenant passer en mode debuggage. Cliquez sur l’icône en forme d’insecte sur la barre d’outil et choisissez Debug As -> PHP Web Page.

Cela devrait ouvrir une fenêtre de votre navigateur par défaut (Firefox par exemple) et vous faire basculer sur une perspective de debuggage dans PDT (vous pouvez retrouver les perspectives en haut à droite de PDT).

Cette perspective est découpée en 5 fenêtres :

- en haut à gauche, une fenêtre de « debug » qui vous donne des informations sur le debuggage en cours et dispose de la barre d’outils de debuggage.

- à droite de cette fenêtre, une autre qui vous donne accès aux variables de votre script et aux points d’arrêt définis.

- en dessous, une fenêtre qui présente votre code, vous montre la ligne courante et permet de définir/annuler des points d’arrêt

- encore en dessous, la fenêtre de console.

- et enfin, à droite, la fenêtre d’Output.

Pour debugger, utilisez la barre d’outils de la fenêtre « debug ».

Vous pouvez également ajouter des points d’arrêt dans votre code. Pour cela double-cliquez sur la barre grise se trouvant à gauche de votre code (idem pour retirer les points d’arrêt). Des petites boules vont apparaitre pour signaler ces points d’arrêt.

Au fur et à mesure que vous allez avancer dans le debuggage de votre page, vous pourrez voir le résultat s’afficher directement dans votre navigateur.
 
 
MODIFIER LES VARIABLES EN COURS DE DEBUGGAGE

Il va souvent être utile de modifier le contenu de vos variables en cours de debuggage. Pour cela sélectionnez la variable souhaitée dans la fenêtre d’affichage des variables et modifiez simplement sa valeur.
 
 
TRAVAILLER AVEC GET ET POST

En utilisant PDT avec XDebug, j’ai rapidement eu besoin de jouer avec les tableaux $_GET et $_POST. Malheureusement, je n’ai rien trouvé à ce sujet dans la doc ou dans Google. J’ai toutefois persisté et ai trouvé une astuce pour pouvoir m’en servir.

Commençons par $_GET. Pour le remplir, faites tourner le débuggeur sur votre script et allez jusqu’au bout de votre script. Allez ensuite dans la fenêtre de navigateur ouverte par le debuggeur. Vous devriez vous retrouver avec une barre d’URL de ce type :

Ajouter les variables que vous souhaitez dans cette url et relancez la page. Retournez maintenant dans PDT, et, magique…la session de debuggage est relancée et les variables sont maintenant disponibles sous $_GET.

Pour $_POST, lancez un debuggage sur le formulaire permettant de faire votre POST et allez au bout du script. Allez dans la fenêtre de navigateur, votre formulaire sera affiché. Remplissez le et validez le. Retournez dans PDT, vous devriez maintenant avoir une session de debuggage sur le script de réception du formulaire.

Il existe certainement d’autres méthodes plus simples pour utiliser nativement $_GET et $_POST avec PDT et XDebug, si vous les connaissez, n’hésitez pas à ajouter votre commentaire à cet article.

De mon côté, j’ai trouvé une autre solution plus efficace et plus pratique pour gérer mes sessions de debuggage, l’utilisation de l’extension XDebug Helper pour Firefox.
 
 
UTILISATION DE L’EXTENSION XDEBUG HELPER POUR FIREFOX

L’extension XDebug Helper pour Firefox va vous permettre de lancer vos sessions de debuggage directement depuis Firefox.

Commencez par installer l’extension que vous pourrez trouver ici :

https://addons.mozilla.org/fr/firefox/addon/3960

Cela va ajouter deux icônes en bas à droite de Firefox.

Le premier bouton va vous permettre de lancer des sessions de debuggage. Pour cela, il va falloir configurer PDT pour qu’il accepte le lancement externe de sessions de debuggage. Retourner donc dans la configuration de PDT :

Window -> preferences
puis PHP -> debug -> Installed Debuggers

Sélectionnez « XDebug » et cliquez sur « configure« .
Dans le menu déroulant « Accept remote session (JIT) » sélectionnez « localhost » (ou « any » si votre serveur est distant).
Vous allez maintenant pouvoir lancer vos sessions directement depuis Firefox.

Pour cela, cliquez sur le bouton de XDebug Helper qui ressemble à une croix dans Firefox (en bas à droite). Celui-ci devrait devenir vert et jaune.

Tapez l’URL du script que vous souhaitez debugger(ex : http://localhost/….) et lancez son execution. Retournez dans PDT, votre session de debugage devrait être lancée.
 
 
CONCLUSION

J’espère que ce petit tutoriel vous permettra de développer plus efficacement. A mon avis, tout développeur devrait avoir XDebug installé par défaut. J’ai bien pensé à le fournir directement avec WampServer, mais pour le moment, la structure de WampSever et son mode de fonctionnement « multi-PHP » ne me le permettent pas. Peut être dans une version future…

Plus qu’une semaine à attendre avant le retour de mon émission de jardinage préférée :

http://www.sho.com/site/weeds/home.do