Mots-clé : php

Tiens tiens… Python vs Php…

Depuis plus de quinze ans, j’essaie d’expliquer que des fontes grosses, claires et visibles sont plus efficaces que tout le reste et le Web est allé dans ce sens il y a à peine quinze ans…

Depuis plus de dix ans, je prédis que la domotique va devenir extrêmement importante et omniprésente, et on commence à peine à parler d’objets connectés…

Il y a quinze ans j’ai eu un pressentiment très fort avec Php et j’ai écrit énormément de choses avec jusqu’à acquérir un bon niveau… car je savais que Php était l’avenir !

…jusqu’à il y a cinq ans où j’ai bien senti que tout ralentissait… Je me suis penché sur Python / Django, et j’ai eu le même enthousiasme qu’avec Php il y a quinze ans. C’est pas tous les jours qu’on a ça ! Bref. Tout ça pour dire que :

Python dépasse pour la première fois Php en nombre total de questions sur Stackoverflow.

J’avais eu un entretien de prestation pour Symfony chez… je ne cite pas, mais ils se reconnaîtront pour la description que je fais ensuite : j’avais eu le malheur de leur expliquer que non seulement Symfony c’est une usine à gaz, mais en plus qu’il était dépassé et que Django plus Python était mieux à tous les niveaux. Que n’avais-je pas dit, quel sacrilège ! Mais bon, les deux CTOs ne connaissaient même pas LoL alors que là aussi je prédis depuis plus de cinq ans qu’il y a de plus en plus d’argent à se faire dans le monde des claviers / et du gaming…

J’aimerais bien revoir ces deux CTOs… pour voir s’ils me riraient encore au nez comme ils l’avaient fait… comme si j’étais le dernier des crétins… mais la nature humaine étant ce qu’elle est, il est toujours très difficile – voire impossible pour certains – de dire humblement : « j’avoue, je m’étais trompé »… peut-être qu’ils en seraient capables, je ne les connais pas assez pour m’avancer.

Bref : j’ai toujours prédit les bonnes tendances : Delphi à l’époque, puis Php, puis des concepts comme les commandes de repas en lignes, et maintenant Python et je ne me suis jamais trompé en 25 ans… et hop, une de plus !

J’ai encore une autre grosse tendance pour laquelle je suis sûr que c’est l’avenir, et je n’en parle pas car je suis en train de développer une application dessus… il y a bien sûr une interaction avec un site développé en Python / Django, bien sûr !

Bonne journée à tous 🙂

La tendance python : vivement que la France rattrape l’international !

J’ai eu une discussion avec des fans de Symfony il y a quelques temps. Ils me soutenaient (avec une prétention qui m’a surpris) que Php était de très loin le langage le plus recherché actuellement. Ils se trompaient lourdement. Dire que Php est le langage le plus utilisé, oui. Dire qu’il est le plus demandé, et qu’il le restera, non.

Python est l’avenir

Aucune discussion possible.

Python c’est tout. End of story

Voici le mail que j’ai envoyé récemment à plusieurs de mes clients, et, qui explique la tendance python :

En tapant « most popular development languages » sur google, on voit que :

Enfin je l’ai appris ce matin de la part d’un professeur : deux universités de France retirent Php pour le remplacer par Python cette année (si vous êtes intéressé je vous dirais lesquelles, je n’ai plus en tête les villes de ces universités).

J’imagine les gens de mauvaise foi qui vont aller chercher sur le Web et sortir les deux ou trois sites qui mettent Php devant Python… oui vous allez en trouver, mais en proportion, la plupart des sites expliquent que la tendance d’aujourd’hui c’est Python et JavaScript. Quant à ce dernier, moi qui ai fait quelques sites en NodeJS, je confirme que c’est l’âge de pierre aussi bien côté serveur Web que côté langage JavaScript lui-même… peut être qu’enfin à sa version 6, il fera du scoping normal (lisez ici) déjà rien que ça c’est moisi, sans parler des principes des closures qui empêchent carrément de faire de grosses applications qu’on peut facilement maintenir… là aussi, je ne pourrai jamais convaincre des gens qui ont principalement fait du JavaScript sans avoir essayé aussi intensivement d’autres langages (on ne peut pas comparer dans ce cadre, et toute discussion devient alors impossible)…

Activemq : principe de messagerie interne producteur / consommateur

J’ai eu un besoin que je pensais assez particulier, mais qui, en fait, dans certains cas, semble tellement récurrent que beaucoup de choses ont déjà été faites dans ce sens.
Mon besoin est simple :

J’ai un site distant qui est d’accord pour qu’on l’interroge en lui demandant des informations sur des Ids, mais pas très souvent : une demande toute les 5 secondes. Par contre, lors de la demande, on peut lui faire passer plein d’Ids (jusqu’à 100 !).

Donc j’ai fait un script Php, lancé à la main, qui tourne en boucle, et qui va interroger ce fameux site, toutes les 5 secondes.
Une fois ce script fait, j’ai besoin que l’on puisse préciser « à la main » les Ids. Je fais donc un site Internet, et je mets à disposition de tout le monde la possibilité d’entrer des Ids « à la main ».

Problème

La demande Internet peut se faire n’importe quand, et il faut que la réponse soit rapide, donc que la demande soit immédiatement inclue dans le « paquet » lors de la prochaine interrogation. De plus, il peut y avoir plein de demandes à la fois. Et elles doivent toutes s’ajouter facilement.

Solutions

Plusieurs solutions sont possibles :

  1. Utiliser une sorte de dossiers « partagés » où d’un côté le Web/Php dépose un fichier avec un Id, et attend dans un autre dossier la réponse comportant le même nom de fichier ; gros problème : ce n’est pas une méthode 100% fiable ;
  2. Faire un serveur interne qui attend des informations, et lorsque son timer tombe, hop, fait la demande. Gros problème : écrire un vrai serveur Web en Php n’est pas une chose facile, et je n’ai pas le temps de faire tout ça ;
  3. Faire une écriture en base de données pour chaque demande Web, et du côté script, faire un simple « SELECT * FROM… WHERE DATE_DEMANDE IS NULL » (ou quelque chose comme ça). Problème bloquant : comment faire pour signaler à chaque demande Web que leur réponse est disponible ?
  4. Dernière solution : utiliser quelque chose qui existe déjà et tourne très bien : un serveur producteur/consommateur (je l’appelle comme ça mais ce n’est pas le vrai nom). Il implémente en gros tout ce que je demande : d’un côté le client qui envoie des messages, et peut – ou pas – attendre un retour de manière bloquante, et de l’autre côté, le serveur qui lit les messages qui arrivent quand il en a envie, et peut leur répondre facilement – quand je dis « facilement », je parle du point de vue du code à faire en Php.

Solution finale

La dernière solution existe, tourne depuis bien longtemps, fait partie de l’association Apache, et a une implémentation en Php, soit tout ce que je veux : cliquez ici pour plus d’informations : http://activemq.apache.org/

Résumé mémo pour mon installation sous Linux (car si je change de serveur j’aurais besoin de me souvenir de ce qui suit !) :

  • apt-get install activemq
  • Ce qui m’a fait perdre beaucoup de temps : la configuration est la même que le principe available/enabled de la configuration du serveur Web Apache, à la différence près qu’une configuration n’est pas un fichier simple, mais un dossier. Il faut donc faire un lien symbolique dans le dossier enabled sur le dossier d’exemple : sudo ln -s ../instances-available/main/
  • Pour le lancer, faire le grand classique et ne pas suivre d’autres suggestions moisies qu’on trouve un peu partout sur le Web. Simplement service activemq start
  • Enfin, installer en Php. Sur Debian, si on enlève le temps de recherche, ça prend deux minutes maximum : pecl install stomp. L’installation de stomp pour activemq va compiler une extension pour Php. Il suffit de l’inclure dans /etc/php.ini (je l’ai ajouté en fin de fichier, ça a parfaitement fonctionné) : extension=stomp.so. Au cas où, n’oubliez pas de redémarrer le serveur Web ! service apache2 restart

Et voilà tout fonctionne ! Le meilleur exemple – et plus parlant – à mon sens se trouve ici. Code très simple et efficace.

WordPress : thème enfant : comment inclure des fichiers « proprement »

Si vous avez crée un template « enfant », comme je l’ai déjà fait plusieurs fois, un des problèmes les plus énervants à chercher est : comment trouver le répertoire courant du thème.

En fait WordPress met à disposition deux fonctions, et il vous faut utiliser soit l’une, soit l’autre :

  • get_stylesheet_directory_uri()
  • get_template_directory_uri()

get_stylesheet_directory_uri()

Vous renvoie le répertoire de l’enfant, donc le répertoire en cours du thème « enfant » que vous êtes en train de développer.

get_template_directory_uri()

Vous renvoie le répertoire du parent, cela peut être pratique si vous voulez chercher des informations dans le parent (utiliser une feuille de style déjà présente, par exemple, afin de ne pas la copier-coller dans votre thème).

WordPress : notes pour les débutants

Petites notes que j’ai apprises lors du développement d’un plugin qui créait des champs entièrement personnalisés :

Les filtres et les actions se ressemblent beaucoup à la fois dans la documentation et dans la déclaration, pourtant :

  • un filtre est une fonction qui reçoit quelque chose en paramètre et qui doit renvoyer quelque chose en paramètre, et s’il n’y a aucune modification du paramètre qui arrive, elle doit obligatoirement renvoyer le paramètre entrant ;
  • par opposition, une action est une fonction qui ne reçoit pas forcément quelque chose en paramètre et surtout, qui n’a pas besoin de renvoyer quelque chose (même si elle renvoie quelque chose, c’est ignoré).

Dans beaucoup de fonctions, il y a deux versions : avec et sans get_ :

  • the_ID(); et get_the_ID();
  • the_category(); et get_the_category();

La version sans le get_ affiche le contenu correspondant (= echo) alors que la version avec get_ renvoie le contenu correspondant, il faut donc utiliser cette dernière en l’assignant à une variable (par exemple : $categorie = get_the_category();).

Enfin dernière astuce : très souvent (voire tout le temps), les fonctions qui commencent par wp_ affichent le contenu, elles font un echo. Exemple de code que j’ai trouvé un peu déroutant quand on ne sait pas ce qu’il en est :

echo '<div class="form-wrap">';
wp_nonce_field(
    'ma_cle_unique',
    'ma_cle_unique_nonce'
);
echo '</div>';

Ici, wp_nonce_field() affiche quelque chose. Les fonctions qui commencent par wp_ affichent quelque chose.

Voilà. En espérant que cela évite à des personnes de perdre autant de temps que cela m’en a fait perdre…

vim et xdebug principes de base pour y arriver

Le principe est de comprendre comment fonctionne xdebug sinon vous n’arriverez jamais à faire du pas à pas en Php.

L’idée plutôt bizarre mais fonctionne très bien, et ça semble le moyen le plus efficace pour y arriver.

Voici comment fonctionne une session de déboguage et après vous pourrez en déduire ce qu’il faut pour avancer :

  • Le client Web = Chrome demande une page en précisant qu’il veut faire du débogague pas à pas (ajouter dans l’URL XDEBUG_SESSION_START=1 (c’est la valeur xdebug par défaut))
  • Lorsque cela arrive sur le serveur Apache, ce dernier fait passer la demande à toutes les librairies liées à Apache, comme d’habitude. Ici, parmi celles qui l’ont demandé, il y a xdebug
  • Là, xdebug voit XDEBUG_SESSION_START=1. Il va alors essayer de se connecter au serveur de déboguage qu’on a configuré via ces directives dans php.ini :
    zend_extension=/chemincomplet/xdebug.so
    xdebug.remote_enable=1
    xdebug.remote_host=127.0.0.1
    xdebug.remote_port=9000
  • Oui j’insiste bien : Apache devient un client, et se connecte à un serveur de déboguage
  • C’est pourquoi dans vim, même si, comme moi, vous arrivez à installer correctement l’extension pour faire du pas à pas Vdebug, tant que vous n’aurez pas compris ce que j’explique juste avant, vous n’arriverez pas à faire du pas à pas
  • Donc dernière étape : je vous explique l’ordre correct de lancement des applications pour réussir à déboguer :
    1. Préparer l’URL concernée dans le navigateur avec le paramètre XDEBUG_SESSION_START=1
    2. Lancer vim avec l’extension Vdebug
    3. Appuyez sur <F5> dans vim afin qu’il se mette en mode serveur et qu’il attende une connexion. Là un message vous affiche qu’il attend 20s.
    4. Allez dans le navigateur et validez l’URL (entrée ou ‘Refresh’)
    5. Regardez vim: automatiquement il passe en mode pas à pas ! C’est magique, génial, efficace et la crème de la crème : vous pouvez déboguer directement sur un serveur distant quand vous connaissez vim. Le top.

Une fois en mode débogage, voici les raccourcis possibles :

<F5> : start/run (jusqu’au prochain breakpoint/ou fin du script)
<F2> : pas par dessus
<F3> : pas entrant dans la fonction
<F4> : sauter à la fin de la fonction
<F6> : stopper le déboguage
<F7> : detacher le script du débogueur
<F9> : continuer jusqu’au curseur
<F10> : mettre un breakpoint
<F11> : voir les variables du contexte (p.ex. après « eval »)
<F12> : évaluer une variable sous le curseur
:Breakpoint <type> <args>: mettre un breakpoint de n’importe quel type (voir :help VdebugBreakpoints)
:VdebugEval <code> : évaluer du code et afficher le résultat
<Leader>e : évaluer l’expression sous le curseur et afficher le résultat
Pour arrêter le déboguage, appuyez sur <F6>. Appuyez encore une fois pour fermer l’interface de déboguage.

If you can’t get a connection, then chances are you need to spend a bit of time setting up your environment. Type :help Vdebug for more information.

Voici une capture de vim / débogage de mon blog WordPress. En plus, en faisant du pas à pas dans WordPress, j’ai appris énormément de choses… Maintenant, à vous de jouer !

vim xdebug image

PhpStorm, Windows / WAMP et xdebug : howto – la solution

Si jamais vous êtes comme moi, et que vous n’avez pas réussi à faire fonctionner PhpStorm avec xdebug sous Windows avec WAMP, vous avez peut-être le même problème que moi à savoir : le serveur Apache semble mal configuré – ou configurable, et incapable d’utiliser Php correctement avec xdebug.

Je passe toutes les étapes de configuration « classiques », parce qu’elles sont simples et bien documentées – y compris dans PhpStorm. Malgré tout ça, il se peut que cela ne fonctionne pas.

La solution :

Solution PhpStorm RunDebug Configurations pour Windows - WAMP

En fait il faut configurer PhpStorm pour qu’il ne passe pas par Apache, mais qu’il lance le serveur Php intégré (si, Php a un serveur HTTP, cherchez dans la documentation).

Et ainsi, le déboguage en ligne fonctionnera.

C’est grâce à cette vidéo que j’ai eu l’idée d’essayer :

http://www.youtube.com/watch?v=LUTolQw8K9A

Bien sûr, si vous essayez xdebug sous Linux, vous aurez nettement moins de difficultés 🙂.

Packtlib : Mastering ExtJS : impressions à chaud

Pour les Anglais uniquement, vous serez sûrement intéressées :

Le livre Mastering ExtJS.

Mastering Ext JS montre aux lecteurs comment utiliser le potentiel de Ext JS au complet et créer une application au complet en partant de rien, mais explique aussi comment créer un thème WordPress avec ExtJS. Cette dernière section est assez surprenante, mais semble efficace.

  • Chapter 1. Getting Started
    Les bases pour installer ExtJS (LAMP, ou pour les newbies WAMP etc)
  • Chapter 2. The Login Page
    La plupart des applications ont une page d’identification. L’auteur explique comment faire l’identification « classique » avec ExtJS.
  • Chapter 3. Logout and Multilingual
    La plupart des applications ont une page de déconnexion, et en 2013, il faut savoir rapidement implémenter une autre langue. L’auteur explique comment faire cela : déconnexion et gestion du multilangue.
  • Chapter 4. Advanced Dynamic Menu
    Comment créer des menus dynamiques, qui sont constitués en fonction des droits de la personne connectée (cf chapitres 2 et 3).
  • Chapter 5. User Identification and Security
    Création d’une page de gestion complètes des identifications : comment donner les permissions à des utilisateurs (lister tous les utilisateurs, créer, éditer et supprimer des utilisateurs et aperçu d’une image d’un utilisateur qui va être envoyée).
  • Chapter 6. MySQL Table Management
    Création d’un système modulaire appelé « données statiques ». Liste de toutes les informations d’une table MySQL. Créer de nouveaux enregistrements dans la table. Live search sur les tables. Mettre en place des filtres. Éditer et supprimer des enregistrements. Créer un composant abstrait réutilisable pour toutes les tables.
  • Chapter 7. Content Management
    Gestion de contenu complexe avec ExtJS : comment gérer les associations many-to-many. Comment gérer et faire des formes avec les associations. Explication pour faire des composants réutilisables.
  • Chapter 8. Adding Extra Capabilities
    Possibilités supplémentaires. Comment imprimer des champs d’un panneau de type grille (GridPanel). Comment exporter des champs d’un panneau de type grille (GridPanel) en PDF ou au format Excel. Comment créer des graphiques /courbes. Comment utiliser des composants tiers ou des plugins.
  • Chapter 9. The E-mail Client Module
    Cette partie explique comment développer un client Web mail avec ExtJS. Comment dessiner le client email. Comment lister les emails. Comment créer la boîte de réception (gestion d’un TreePanel). Comment gérer le drag’n’drop entre deux composants (grid et tree). Améliorer le GridPanel de manière impressionnante (customisation).
  • Chapter 10. Preparing for Production
    Comment créer un thème personnaliser. Comment préparer (packager) l’application pour qu’elle soit prête pour la production. Comment utiliser le packager. Il peut sembler y avoir peu de choses dans ce chapitre, mais les explications sont longues et détaillées et j’ai appris énormément de choses.
  • Chapter 11. Building a WordPress Theme
    Je pensais que l’idée était de faire à la main un thème WordPress, mais non : l’idée est d’utiliser tout l’habillage au complet ExtJS, ainsi que le code JavaScript qui va avec, afin de l’intégrer dans une application WordPress. Comment fonctionne WordPress. Comment créer un thème, un header, un footer, une page principale, une Sidebar, une page d’articles et enfin une page de type « Page » (par opposition aux pages de type « Article »)
  • Chapter 12. Debugging and Testing
    C’est un des chapitres les plus pratiques pour la vie quotidienne : la plupart des outils avancés et peu connus y sont, pourtant il sont très utiles : comment déboguer une application ExtJS. Comment tester les applications ExtJS. Les outils utiles (JSLint, YSlow, Sas, Less, YUI Compressor…). Comment passer de ExtJS à une version mobile. Composants tiers et plugins utiles pour développer rapidement. Résumé

Au final, ce livre comporte beaucoup de choses intéressantes, et (à mon sens), même si vous êtes développeur avancé ExtJS, les trois derniers chapitres sont super intéressants et rien que pour ces trois derniers, même si vous trouvez qu’acheter un livre c’est trop cher (ce que je comprends ;)), les quelques 17 € que vous coûteront la version en ligne seront rapidement rentabilisés.

D’ailleurs en parlant de version en ligne, ils ont complètement refait leur reader en ligne, et ce dernier est très bien fait : moi qui suis très critique, je n’ai rien trouvé à redire !

Développement : Coding contest !

Challenge de codeurs !

C’est pour le fun, essayez vous aussi 

Le principe est simple

Vous aurez deux puzzles de programmation à résoudre.

Pour ce faire, vous pourrez choisir votre langage favori parmi ceux-ci : Java, C, C++, C#, Javascript, PHP, Python, Ruby, Objective-C, Haskell and Go.
La durée moyenne d’un challenge est de 2 heures et 30 minutes.

J’y serai, le 28 septembre !