Standardisation et règles de nommage

Lorsqu’on démarre un développement, il vaut mieux mettre en place des règles, par exemple des règles de nommage, commentaires en français ou en anglais, utilisation de camelcase, etc.

Pour un site internet, la règle reste valable. Si on utilise un CMS, il n’a pas de règle de développement à mettre en place, mais l’intervention de prestaires externes (graphiste, rédacteur, …) fait qu’il vaut mieux mettre en place une méthode de travail et de nommage des documents qui prévaudra pendant le projet.

En mai, j’ai travaillé avec un graphiste qui m’envoyait des maquettes nommées « maquette », « propositions », « propositionsaxe1modifié », « axe1def ». Lorsqu’il a fallu retrouver la dernière version pour découper les éléments et intégrer, j’ai dû chercher dans mes mails quelle était la dernière version envoyée.

Il aurait été plus simple de lui demander dès le départ de nommer ses maquettes selon une règle, par exemple axe1v1.0, axe1v1.1, axe2v2.0, etc. Sachant que le terme « def » qui veut dire « définitif » ne peut être utilisé : le client revient souvent sur un détail et une nouvelle maquelle est produite.

Cela s’applique aussi au nommage des éléments découpés (les images) : j’ai reçu de ce graphiste des images nommées un coup avec des majuscules, un coup avec des minuscules, avec espaces, sans espaces, avec des _, Après les corrections les images ne s’appelaient plus pareil : on passait de « accueilBL » à « accueilB », « presentationInvBL » à « presentaB ». Bref, n’importe quoi. J’ai passé beaucoup de temps pour tout renommer ou modifier le code pour appeler les nouvelles images.

Ce que je retiens de cette expérience, c’est que désormais je définis en amont du projet avec le prestaire la règle de nommage de ses documents, et j’impose pour certains d’indiquer la version du document. Je gagne énormément de temps et je gagne également en confort.

J’ai même un prestaire qui m’a avoué que même si ça l’avait bien saoûlé de s’y conformer, il avait quand même trouvé cela bien pratique…

 

Les sessions dans Code Igniter

Je suis en train de développer une application SaaS avec le framework Code Igniter, et je rencontre pas mal de problème avec les sessions des utilisateurs.

Déconnexions intempestives, affichage du nom d’un autre utilisateur au sein de la même entreprise… J’ai changé de librairie pour Session Hybrid, qui remporte pas mal de suffrages, mais je continuais à avoir des déconnexions sauvages dans une entreprise où deux personnes utilisent l’outil.

Après avoir tout tenté, tout testé, j’ai eu un flash. Serait-il possible, même si improbable, que leur adresse IP change ? du coup, la vérification avec l’adresse IP (j’avais déjà viré la vérification avec le User Agent) serait la cause de ce désagrément.

Eh bien oui, il arrive que dans certaines entreprises, l’adresse IP d’un poste change en cours de route, sans déconnexion de routeur, de cable, et dieu sait quoi.

Bref, du coup je déconseille l’utilisation de la vérification par IP, et je déconseille également de la vérification par User Agent. Y’a plus qu’à espérer que les identifiants de sessions sont suffisamment aléatoires pour éviter un bon vieux mélange de compte comme décrit ici [lien HS]

Have fun !

[Edit 05/09/2016 : le lien vers le forum de CI est HS car la structure du site a changé. Je n’ai pas retrouvé le thread]

problèmes d’accès SSH et SVN chez OVH

Depuis dimanche il y a des problèmes d’accès en SSH, SVN et SFTP sur les hébergements d’OVH, suite à une attaque « sur le port SSH » (http://travaux.ovh.net/?do=details&id=6237).

Les accès SSH et SVN sont désormais impossibles avec une adresse www.mon-domaine.tld et il faut créer un CNAME ssh.mon-domaine.tld et utiliser celui-ci pour se connecter (c’est assez long à se propager, compter une bonne demi-journée).

Pour SVN, il faut relocaliser les copies de travail avec la fonction relocate. Elle est expliquée ici. L’ancienne commande était (chez OVH)

svn+ssh://login@www.domaine.fr/homez.XX/login/svn/mon_espace_svn

il faut désormais utiliser

svn+ssh://login@ssh.mon-domaine.tld/homez.13/login/svn/mon_espace_svn

ou

svn+ssh://login@ssh.clusterNNN.ovh.net/homez.XX/login/svn/mon_espace_svn

Plus de détails .

<ironie>et encore merci, OVH, d’avoir prévenu !</ironie>

 

Les bookmarks dans Eclipse, ou comment gagner en efficacité

Je viens de découvrir une fonction fabuleuse dans Eclipse, peut-être qu’elle est archi-connue, mais bon, je la partage ici pour les derniers troglodytes qui sont comme moi.

Je suis sur un projet en Symfony, donc avec beeeeeaucoup de fichiers, et comme dans tout framework, il s’agit plus de copier-coller du code que d’en inventer, je passe donc mon temps à ouvrir des fichiers pour rechercher un bout de code qui va me resservir. J’ai le choix entre :

  • avoir 10 onglets ouverts, dont 6 masqués parce que fenêtre de l’éditeur trop petite
  • ajouter un écran (voire deux) pour pouvoir tout afficher (3 écrans sur le bureau, ça va le faire)
  • splitter mes fenêtres pour avoir les fichiers sous la main, mais je passe mon temps à jongler entre les éditeurs

Dans un éclair de lucidité, je me dis, bon sang ce serait génial si on pouvait mettre des pages en favoris, pour pouvoir les retrouver rapidement. Un petit coup de google pour savoir ce qu’on peut faire, et bam ! Eclipse a pensé encore mieux que ça.

Il y a une fonctionnalité « bookmarks » de base, qui permet tout bêtement de mettre en favori, non pas une page, mais un endroit dans le code. Avec mes DAO qui font des kilomètres, c’est encore mieux que ce que j’avais espéré.

Pour mettre un bookmark dans le code, faites un clic droit sur la gouttière de gauche (là où se trouvent les numéros de ligne) et… Add bookmark ! plus simple tu meurs. Je ne sais même pas comment j’ai fait pour ne pas voir cette fonctionnalité plus tôt.
Eclipse demande un nom puis il stocke tout cela dans la vue « bookmarks », que l’on peut afficher en allant dans Window > Show view > Other puis General > Bookmarks. Ensuite déplacez la vue où vous voulez. Ça peut être utile de l’afficher horizontalement car Eclipse indique d’autres infos en plus du nom du bookmark : la ressource, le chemin et la ligne. Perso, je m’en fiche, je l’ai déplacée à droite et je ne vois que le nom du bookmark.

Pour accéder à la ressource, double-clic sur le bookmark, pour le supprimer, clic droit > delete.

C’est une nouvelle victoire pour l’efficacité du codage.

Merci à Luis de la Rosa pour son article qui décrit très bien cette fonctionnalité, même s’il date de 2005
http://www.luisdelarosa.com/2005/02/16/eclipse-tip-use-bookmarks-to-track-important-places-in-your-code/

A noter que Netbeans utilise des signets, mais de manière beaucoup moins pratique puisqu’il n’y a pas de « navigateur » de signets, on ne peut que sauter d’un signet à un autre.
http://netbeansblog.com/tutorial/using-coding-bookmarks-in-netbeans/

 

Installer un cron chez 1and1

Cron ?

cron est le nom d’un programme qui permet aux utilisateurs des systèmes Unix d’exécuter automatiquement des scripts, des commandes ou des logiciels à une date et une heure spécifiées à l’avance, ou selon un cycle défini à l’avance.

http://fr.wikipedia.org/wiki/Cron

crontab est le nom du programme sous Unix (ou Linux) qui permet d’éditer des tables de configuration du programme cron.

http://fr.wikipedia.org/wiki/Crontab

L’autre jour, je m’amusais à installer un cron pour une petite appli  que je suis en train de développer.
Les crons, je connais, mais pas par coeur, et surtout pas la syntaxe. Comme j’installais ça chez 1and1, j’ai voulu bêtement suivre les instructions qu’ils donnaient. Evidemment, si je n’avais pas galéré pendant 3 jours, cette note de blog n’existerait pas…

Structure d’un cron

Pour commencer, je vous refais un cours vite fait sur la structure d’un cron. Vous aurez la même chose et mieux documenté ici.
Le fichier crontab est composé ainsi :
# m h dom mon dow command

  • m : minutes (0-59)
  • h : heures (0-23)
  • dom : day of month (1-31)
  • mon : month (1-12)
  • dow : day of week (0-6, 0 = dimanche, 1 = lundi, etc)
  • command : la commande à exécuter

Pour les minutes, heures, dom, dow et mois, plusieurs syntaxes sont possibles :

  • * : à chaque unité de temps
  • 5 : à chaque unité de temps 5 (j’ai mis 5, ça peut être n’importe quoi du moment que c’est dans l’intervalle 0-59 pour les minutes, 0-23 pour les heures…)
  • */5 : toutes les 5 unités de temps
  • 5,10 : les unités de temps 5 et 10
  • 5-10 : les unités de temps 5,6,7,8,9,10

C’est mieux avec des exemples (backup.sh est mon script de sauvegarde) :

5 * * * * backup.sh # backup.sh est exécuté toutes les heures passées de 5 minutes, tous les jours de tous les mois
*/5 * * * backup.sh # backup.sh est exécuté toutes les 5 minutes de toutes les heures, tous les jours, tous les mois
30 1 * * 6 # backup.sh est exécuté tous les samedi à 1h30
Inutile de préciser que la notation suivante est risquée :
* * * * * backup.sh # chaque minute de chaque heure...
La notation
30 1 * * * backup.sh >> log.txtou
30 1 * * * backup.sh > log.txtpermet de préciser que l’on souhaite que le résultat soit loggé dans le fichier log.txt. A défaut, le résultat de l’opération est envoyé par mail. Pour ne rien logger, spécifiez > /dev/null

Pendant ce temps-là, chez 1and1…

1and1 propose l’utilisation des crons à partir de leur pack pro. Les exemples donnés dans leur guide sont justes, mais ce ne sont pas des tutos, et les suivre aveuglément comme je l’ai fait, c’est s’exposer à ce que ça ne marche pas (ça m’apprendra, j’avais fait pareil pour SVN chez OVH).

Pour accéder au crontab, il faut se connecter en SSH sur l’hébergement, puis on peut éditer le fichier avec VI (de belles réjouissances en perspective…).
Pour vous connecter en SSH sous Windows, utilisez Putty. Pour utiliser VI, c’est par là (vous pouvez également suivre le tuto de 1and1).
Pour vos tests, je vous recommande chaudement de mettre en début de fichier
MAILTO=votre@adresse-email.com
A chaque exécution du cron vous serez prévenu du résultat.
Pour faire vos tests, mettez un intervalle de 5 minutes, c’est le minimum autorisé par l’hébergeur et ça vous évite d’attendre 24h entre deux tests.

Ça marche pas !

Bon, la première chose à faire quand on installe un cron, c’est d’appeler à la main le fichier qu’on veut exécuter avec le cron. Histoire de vérifier qu’il s’exécute bien, ça fait gagner du temps à tout le monde.
Ensuite, vérifiez les droits sur le fichier. Concrètement, si vous recevez un message « Permission denied », c’est que les droits ne sont pas bons. Vous pouvez modifier cela avec votre logiciel FTP ou en SSH. Un 777 devrait suffire 😉

Si vous appelez un fichier PHP
*/5 * * * * $HOME/test.php
vous aurez droit à :
?php: No such file or directory
syntax error near unexpected token blablabla

Le bougre n’a pas compris qu’il fallait interpréter PHP.

Essai suivant :
*/5 * * * * php $HOME/test.php
Normalement, y’a du mieux… sauf si
<b>Parse error</b>:  syntax error, unexpected T_STRING, expecting T_OLD_FUNCTION or T_FUNCTION or T_VAR or '}' in ...
Bon, là c’est pas de pot, vous avez utilisé du PHP5, par défaut il attend du PHP4 (qui a dit « boulet » ?)
La bonne syntaxe est la suivante :
*/5 * * * * /usr/local/bin/php5 $HOME/test.php

Voilou, c’est à vous !