Mois : juillet 2017

Hebergement gratuit

Bonjour,

Aujourd’hui j’ai besoin d’un hébergement gratuit pour montrer un prototype.

J’ai déjà un compte chez free.fr mais je ne veux pas le polluer. De plus, la version de php est un peu vieille.

J’ai donc décidé de me faire un compte sur chacun que je trouve sur internet.

Il me faut un hébergeur qui ne me demande pas de carte de credit ou quelque justificatif.

Il ne reste que 3 candidats :

  • hostinger
  • awardspace
  • agilityhoster

Certains sont gratuits mais requièrent un nom de domaine. Vu que je n’en ai pas, et que je ne veux pas en acheter un, une partie des contestants passe à la trappe.

Celui que j’ai choisi c’est awardspace, parce qu’il me permet d’avoir un nom de domaine chez eux gratuitement.

Je vais donc utiliser mon compte chez awardspace, il est actif pendant 1 an.

Utiliser une cle ssh bitbucket

Bonjour,

De plus en plus de sites sont synchronisés via un git sur le cloud comme github ou bitbucket.

Cela permet de mettre facilement en place un service d’intégration continue.

Pour utiliser git, on serait tenté d’utiliser son identifiant et le sauvegarder sur le serveur.

Il y a une meilleure solution : utiliser une clé ssh.

Vu que l’étape de mise en place est bien expliquée, je met juste le lien vers la page bitbucket.

Voila pour aujourd’hui.

Les controleurs de version

Le contrôleur de version

Introduction

Bonjour,

J’utilise des contrôleurs de versions depuis quelques années déjà.

  • CVS en 2004 jusqu’à 2006
  • SVN de 2006 à ce jour
  • GIT de 2015 à ce jour

Celui que je maîtrise le plus est bien entendu SVN, vu que je l’ai utilisé plus de 10 ans, et oui j’ai sauté dans le train Git en retard.

Il serais intéressant de discuter de la façon dont j’utilise le controleur de version.

Le contrôleur de version ce n’est pas :

Je vais commencer par dire ce que ce n’est pas fait pour : Sauvegarder ses données.

Il faut absolument mettre Git ou Svn sous une gestion de sauvegarde (appelé communément backup). Mettre son code source sous contrôle de version ne le sécurise pas. Même si c’est sur un site comme github ou bitbucket. Il faut faire une sauvegarde régulière sur au moins un environnement que vous maîtrisez (non, l’ordinateur portable n’est pas un environnement maîtrisé). Je devrais songer à faire un billet sur les sauvegardes.

Alors, c’est quoi le contrôle de version ?

Gestion des conflits

La chose la plus importante pour moi, c’est la gestion des conflits. Il est loin, mais toujours présent dans mon esprit, le temps où travailler à 2 sur un même projet impliquait écrasement des changements d’autrui par mégarde. Les corrections mineures perdues d’une mise en production à une autre parce qu’on écrase tous les fichiers.

Le contrôle de version, est la pour dire « Attention, le fichier que tu veux écraser a été modifié, prend le temps de regarder ». Plus aucun changement n’est perdu de façon involontaire. On vérifie, on gère les changements des autres avec les notres et ça roule.

Gestion des tâches

Le 2ème problème que le contrôleur de version corrige, c’est les copies pour chaque tâche. On commence une tâche, on ne la finit pas qu’il y en a une autre plus urgente. On copie le répertoire original, on commence la 2ème tâche, et une 3ème urgence, etc…

On se retrouve avec une dizaine de copies, et on ne sais plus laquelle est la plus à jour. Avec le contrôleur de version, on fais une branche par tâche et on garde trace des dates, des changements déjà effectués etc.

Pour ne pas se perdre, il faut garder une structure propre, c’est à dire supprimer les branches qui ne sont plus actives (après avoir fusionné son contenu dans la branche principale).

Gestion de l’historique

Certains pensent que c’est la chose la plus importante, pour moi, elle vient en 3ème position. Le code source versionné c’est un historique de son évolution. Soyons francs, personne ne visite le code pour en connaître le cheminement.

Là où cette fonctionnalité devient utile, c’est lorsqu’on a l’impression qu’un bug réapparaît alors qu’on est sûr de l’avoir corrigé.

On regarde la dernière version qui ne contient pas le bug et on regarde comment la correction à été écrasée. On récupère le patch et on l’applique à la version courante.

Autre utilisation

Une utilisation intéressante du contrôleur de version est pour les bases de connaissance.

J’ai un fichier qui s’appelle symfony.txt, il contient tout ce que je sais sur symfony : Installation, cheat sheet, problèmes principaux, etc.

Pour gérer les différentes versions de symfony, je pourrais faire des paragraphes dans le même fichier. Le problème c’est qu’il ne fera que se rallonger et il y aura beaucoup de duplication.

Une autre solution, serait d’avoir un fichier par version de symfony. Le problème des fichiers à rallonge est réglé, mais je vais surpeupler mon répertoire, en plus, il faudra modifier tous les fichiers si un problème touche plusieurs versions.

La solution que j’utilise c’est avec le contrôleur de version. Je met un tag par version principale du fichier. Je remonte dans la bonne version grâce aux tags. Je n’ai qu’un fichier, et aucune redondance. Quand une nouvelle version de symfony sort, je met un tag.

La difficulté viens si j’ai une correction sur une version qui n’est pas la dernière. Je vais sur la version concernée. J’applique les changements et je les propage sur toutes les versions ultérieures. Si la solution n’est plus pertinente sur une autre version, j’y vais et corrige et repropage.

Ainsi j’ai une base de connaissances qui est simple à utiliser.

Bien sur, un outil dédié aux bases de connaissances serait plus adapté, mais j’utilise cette méthode et elle fonctionne bien. Laissez un commentaire si vous avez des suggestions.

Conclusion

Même quand on travaille seul, il est indispensable d’utiliser un contrôleur de version. Sur mon ordinateur, j’ai un serveur svn qui gère la plupart de mes travaux. Les plus récents sont sous git.

Si vous utilisez de façon intéressante les contrôleurs de versioin, n’hésitez pas à commenter.

Utiliser plusieurs versions de jQuery simultanément

Bonjour,

Aujourd’hui encore, beaucoup de projets utilisent jQuery.

Malheureusement, jQuery ne garde pas une compatibilité ascendente, on peut donc avoir des projets qui ne marchent qu’avec une version précise.

Bien sûr, si j’en parle, c’est que j’en ai fais les frais.

Eh bien, j’ai du utiliser 2 composants qui dépendaient de 2 versions incompatibles de jQuery.

Après quelques recherches, j’ai trouvé la solution :

On peut renommer sur pour une des 2 la variable ‘$’.

var $j = jQuery.noConflict(true);
$j(function() {
   $j('.datepicker').datepicker({
      onSelect: function() {
         update(this);
      }
   });
});

La commande noConflict, ordonne à jQuery de ne plus utiliser l’alias $.

C’est la dernière instance chargée qui est effacée. On récupère l’instance dans une variable que l’on peut utiliser en place de ‘$’ ou ‘jQuery’.

La première instance est celle qui peut utiliser ‘$’ et ‘jQuery’.

Avec cette méthode, on peut utiliser autant de versions de jQuery que l’on veut. Il faut juste faire attention à l’ordre de chargement des scripts.

Idée sur les sites multilingues

Bonjour,

La traduction d’un site est un casse tête. Différents frameworks proposent différentes solutions.

Et si je devais construire un module de traduction sans me soucier de ce qui existe déjà ? Comment je verrais la chose ?

Voici mon idée :

Je mettrais en place une structure de base de données qui permet d’avoir autant de langues que l’on veut. Aucune langue n’est obligatoire ni aucune par défaut. C’est l’application qui fera un choix en « requêtant » la base de données.

La clé pour un texte ressemble a une variable et non a un texte.

Voici un exemple de chaque :

echo trad("client.lister");
echo trad("Lister les clients");

La fonction trad fait la traduction et rapporte les manques :

Si une clé n’existe pas dans la base de données, on la crée et on ne lui donne aucune traduction.

Si une clé existe mais pas de traduction dans la langue courante, l’application décidera quoi faire : Afficher la clé, une erreur ou le texte dans une autre langue. De plus, un flag dans la base de données est positionné afin de savoir qu’une traduction manque.

Pour accélérer la traduction, on peut exporter la base de données dans plusieurs fichiers PHP (un par langue) contenant un tableau des traductions.

Enfin, un portail admin permet de voir les clés demandées sans traduction et de les traiter. Quand on valide toutes les traductions, les fichiers PHP (si l’accélération est activée) sont re-générés.

Voilà pour les grandes lignes. Si vous avez aussi des idées sur une implémentation plus aboutie, mettez les en commentaire.

Les chemins vers les fichiers en php

Bonjour,

Voici un sujet qui me donne pas mal de soucis quand je veux faire une application web.

Comment écrire ses chemins ?

Il y a plusieurs façons de procéder et je vais donner mon avis sur chacune d’elles.

Contexte

Il faut d’abord savoir dans quel contexte on est. Le contexte dans ce cas est l’environnement qui va résoudre le chemin.

On peut distinguer 3 contextes différents :

Le contexte php : C’est PHP sur le serveur qui va résoudre le chemin et consommer le fichier.

Le contexte http de la page : C’est le navigateur qui va demander le fichier et il connaît l’url en cours.

Le contexte externe : On ne connaît rien sur l’adresse du fichier à atteindre. Quand on est dans un mail par exemple.

Invocation

Dans le contexte de PHP

On peut invoquer un fichier de plusieurs façons :

! J’ai choisis la commande include, mais toutes les autres invocations marchent de la même façon pour les autres types d’inclusion

Chemin aléatoire
include "../chemin/fichier.php";

C’est une inclusion relative au chemin courant.

Cette méthode marche mais on ne sais pas toujours quel fichier est utilisé à cause de sa méthode de résolution cf doc.

On se met à dupliquer les fichiers pour être sûr de l’inclure sans se prendre la tête à comprendre la résolution de PHP.

Chemin relatif
include __DIR__."/../chemin/fichier.php";

On donne ici le chemin absolu dans l’arborescence du serveur, mais dans notre tête, c’est un chemin relatif au fichier courant.

C’est la méthode que je privilégie car il devient simple de retrouver son chemin 🙂

Chemin absolu
define("_ROOT", __DIR__."/../cheminVersRoot");
include _ROOT."/cheminDepuisRoot/fichier.php";

! Les 2 lignes ci-dessus sont dans 2 fichiers différents, généralement config.php pour la 1ère.

Ici aussi on donne un chemin absolu sur le serveur à PHP, mais dans notre tête, on donne un chemin absolu depuis la racine du projet.

C’est une solution qui fonctionne bien et qui avait son avantage à l’époque où on avait l’url qui reflétait la structure des fichiers.

Dans le contexte HTTP de la page

Pour illustrer ce contexte, j’utiliserais une balise img (et sans les attributs obligatoires).

Chemin relatif
<img src="../chemin/fichier.png">

C’est un chemin relatif, ça marchait à l’époque où le fichier php avait le même chemin que l’url pour y accéder. Depuis la réécriture d’url, c’est une technique qui ne fonctionnera pas sans y laisser ses cheveux.

Chemin absolu
<img src="/chemin/fichier.png">

C’est la méthode que j’utilise, elle a l’avantage de donner un chemin absolu par rapport à la racine du projet.

Chemin externe
<img src="http://www.domaine.com/chemin/fichier.png">

Le travail et la maintenance deviennent un vrai casse tête, il faut être certain d’avoir modifié les chemins du serveur local avant l’envoi etc.

Chemin externe aidé par PHP
define("_HTTP_ROOT", "http://www.domaine.com");
ou (pire) define("_HTTP_ROOT", $_SERVER["HTTP_HOST"]);
<img src="<?= _HTTP_ROOT ?>/chemin/fichier.png">

! Les 2 lignes ci-dessus sont censées être dans 2 fichiers différents
! J’ai choisi HTTP_HOST mais SERVER_NAME marche tout aussi bien, mais il faut faire attention avec ces variables

On essaie de pallier au problème ci-dessus en n’ayant qu’une constante à modifier, mais il faut quand même penser à la modifier avant l’envoi.

Dans le contexte externe

La meilleure solution est le chemin externe décrit ci-dessus.

On peut néanmoins avec quelques précautions utiliser les variables dans $_SERVER.

Conclusion

Les chemins sont toujours un casse tête en PHP. Avec un peu de rigueur et en utilisant la bonne forme, on peut s’en sortir.

Je n’ai pas mis tous les dérivés de chemins que j’ai pu utiliser mais seulement un échantillon. Si vous avez une suggestion intéressante que j’aurais oublié n’hésitez pas à la mettre en commentaire.

Principe DTF (don’t fear typing)

Bonjour,

Aujourd’hui je vais parler d’une règle que je m’impose et que j’ai appelé DTF (don’t fear typing).

Copier-coller

Il y a beaucoup de cas où on est tenté d’utiliser le copier-coller. C’est une très mauvaise habitude et pratiquement tous les bugs viennent de là.

La tentation est très grande. On a un bloc qui fait presque le boulot ailleurs. Il suffit juste de le copier et de l’adapter.

Bien sûr, on le fait et on est sûr que tout c’est bien passé car il n’y avait que 4 occurence d’une variable à changer. On pousse directement en production.

C’est la catastrophe, le script marche une fois sur 2.

Si on est tenté de copier un bloc, il vaut mieux le retaper et se refaire l’algorithme dans sa tête au fur et à mesure de sa reconstruction. Investir un peu plus de temps en développement, c’est éviter d’en perdre en débogage.

Commentaires

Un autre cas de DTF arrive quand il faut commenter une section. On ne prend pas la peine de décrire le fonctionnement. Quelques jours plus tard, on ne peut plus modifier ce code car on ne se souvient plus de son fonctionnement et qu’il est trop compliqué pour s’en refaire une idée en simple lecture.

Quelques commentaires qui décrivent l’idée générale d’une fonction peut aider à la maintenance du code.

Attention, la pire chose que de ne pas commenter c’est d’avoir un commentaire faux.
Il faut maintenir les commentaires. Quand on modifie le code, on met à jour le commentaire !

Nommage

Le nom des fonctions et des variables n’ont pas de limite restrictive. On peut donc avoir des fonction de plus de 30 caractères. Si toutes les fonctions et variables ont un nom à rallonge, ça ne va pas aider à la lisibilité. Cependant, mettre que des noms courts n’aide pas non plus.

Il faut viser le juste milieu en ayant une combinaison de 3 mots tout au plus qui définissent au mieux la fonction ou la variable.

Il ne faut pas avoir peur de transgresser la règle pour avoir une meilleure lisibilité. On peut très bien avoir une boucle très courte avec « i » comme variable d’itération.

Conclusion

Il ne faut pas avoir peur du clavier, taper quelques caractères en plus peut faire gagner beaucoup de temps dans le long terme. Commenter quand c’est nécessaire, choisir le nom de ses fonctions et variables et ne jamais copier-coller.

Détecter l’environnement de php

Bonjour,

J’ai eu besoin de connaître l’environnement de Php. C’est à dire savoir si c’est en environnement web, en ligne de commande directe, ssh ou via cron.

Je n’avais pas besoin de plus de détail, mais il fallait que ce soit fiable.

Comme d’habitude, une recherche sur stackoverflow donne plusieurs réponses. Je fais le tri et ne trouve rien qui marche bien pour mon cas. Mais une bonne piste que j’ai creusé.

Je me retrouve donc avec ceci :

php_sapi_name()=="cli"?(isset($_SERVER["TERM"])?"cli":(isset($_SERVER["SSH_CLIENT"])?"ssh":"cron")):"web";

Ce one-liner renvoie :

  • « web » en environnement web
  • « cli » en ligne de commande directe
  • « ssh » via ssh
  • « cron » quand il est lancé via cron

Ce script m’a été très utile et marche bien dans un environnement linux. Si vous avez l’occasion de le tester sur un autre système, n’hésitez pas à commenter sur votre expérience.