Attention : nous n’allons ici tester une chaîne de caractères, non pas pour vérifier qu’il s’agit d’une adresse email qui existe vraiment mais seulement que la structure de cette chaîne répond bien aux règles de construction d’une adresse email.

Depuis PHP 5.2.0, inutile de vous lancer dans la rédaction d’expressions régulières indigestes pour vérifier que la structure d’une chaîne de caractères correspond bien à celle d’une adresse email. Il vous suffit d’utiliser la fonction filter_var.
Il faudra ici utiliser le filtre FILTER_VALIDATE_EMAIL.

Par exemple, si l’adresse est stockée dans une variable $adresseEmail,

Si $adresseEmail a bien la forme d’une adresse email, $resultat contiendra alors la même valeur que $adresseEmail.
Dans le cas contraire, $resultat contiendra false.

Si vous souhaitez récupérer, dans tous les cas, un résultat booléen (true / false), vous pouvez utiliser la petite fonction suivante :

Pour des versions de PHP antérieures à la 5.2.0, vous devrez utiliser des expressions régulières. Nous publierons bientôt une liste d’expressions régulières utiles dont une pour tester les adresses email.

Si vous avez apprécié cet article, pensez à vous abonner à notre RSS

En phase d’intégration d’un site, on intervient à de nombreuses reprises sur les feuilles de styles et, parfois, on peut se faire piéger en ne voyant pas les dernières modifications effectuées, tout simplement parce que le navigateur a mis le contenu des fichiers de CSS en cache.

Dans d’autres cas, lors de mises à jour de sites, il peut arriver que certains visiteurs se plaignent de problèmes d’affichage. Là aussi, la cause est généralement les données stockées en cache par leur navigateur.

Pour contourner ces problèmes, il y a 3 solutions côté client :

1. Vider la mémoire cache du navigateur,
2. Interdire au navigateur la mise en cache en passant par ses réglages,
3. Utiliser un module d’extension comme “Web Developer” pour Firefox.

Ces solutions, même si elles sont efficaces, sont contraignantes pour l’utilisateur. Mieux vaut donc envisager une solution côté serveur.

Je vais vous proposer ici une solution qui présente l’avantage d’être entièrement automatique une fois mise en place.

L’idée de base est de passer, lors de l’appel du CSS dans le code HTML, un numéro de version qui va forcer le chargement de la feuille par le navigateur.
Par exemple, pour une feuille de styles nommée fichier_CSS.css, on peut envisager un appel du style :

Ce système est de plus en plus répandu mais je vais vous proposer ici de l’optimiser.

Nous allons nous fixer deux contraintes pour optimiser :

1. Ne pas changer le numéro de version à chaque chargement mais uniquement à chaque mise à jour de la feuille de style
2. Ne pas avoir à changer manuellement le numéro de version

L’idée est simple : détecter la date à laquelle le fichier CSS a été modifié pour la dernière fois.
Nous allons donc utiliser la fonction PHP filemtime($filename).
Cette fonction retourne au format timestamp la date de dernière modification du fichier dont on a passé le chemin en paramètre.
Ce qui donnera par exemple :

Ce qui nous retournera côté client quelque chose du style :

Mais les perfectionnistes iront certainement un peu plus loin.
En effet, certains développeurs ont horreur de laisser traîner des adresses avec des ? et des = ou encore des &.
Ils s’orienteront donc vers les “URL rewriting”, la ré-écriture d’URLs.

Pour cela, nous allons commencer par changer l’appel de la feuille de style en déplaçant le timestamp.
Nous allons passer à :

Le code ressemblera donc à :

Et nous allons entrer une ligne d’URL rewriting dans le fichier “.htaccess” :

Ce qui fait que, lorsque le navigateur du client appellera :
http://www.mon-site.com/fichier_CSS-1209488275.css
le serveur ira pour sa part chercher le fichier :
http://www.mon-site.com/fichier_CSS.css

A noter : cette méthode peut aussi être employée pour d’autres types de fichiers comme les fichiers javascript.

Il existe bien d’autres possibilités comme, par exemple, passer le contenu des fichiers CSS dans des fichiers PHP contenant une fonction header() avec les paramètres nécessaires pour forcer le navigateur à mettre à jour ses données en cache. Mais ça, ça fera certainement l’objet d’un autre article ;-)

Si vous avez apprécié cet article, pensez à vous abonner à notre RSS

Ajax, et autres méthodes de chargement dynamique d’éléments dans une page, permettent de rendre plus conviviaux sites et applications Web en évitant des rechargements de page entières.

L’inconvénient est que, dans bien des cas, le titre de la page n’a plus trop de rapport avec le contenu. Pourtant, avoir un titre adapté peut être très pratique, surtout dans le cas où l’utilisateur ouvre de multiples onglets et / ou fenêtres du même site.

Pensez donc à changer le titre de la page, à la volée, en ajoutant à vos javascripts qui appellent les contenus dynamiques une toute petite ligne de code :

Vous pouvez bien sûr passer dans le titre des variables (numéro de compte client, de livraison, etc.).

C’est tout simple et apporte un réel plus en termes d’ergonomie.

Si vous avez apprécié cet article, pensez à vous abonner à notre RSS

Jouons à l’école avec un petit cas concret ;)

Une association sportive gère ses membres via un outil en ligne écrit en PHP / MySQL. Les dirigeants de l’association souhaitent adresser un mailing à tous les membres majeurs à ce jour.

Sélectionner les membres majeursLa table “membres” contient différents champs mais nous nous intéresserons ici uniquement à deux d’entre eux : membre_id (un entier auto-incrémenté et clé primaire) et membre_naissance (un champ au format DATE contenant la date de naissance du membre).

Question : Comment sélectionner uniquement les ID des fiches des membres majeurs à ce jour ?

Il existe plusieurs méthodes, en voici une 100% MySQL.

Analysons cette requête

A priori, aucun problème pour vous sur la première partie :

En effet, nous sélectionnons ici les deux champs qui nous intéressent dans la table membres.

Ne partez pas déjà, la difficulté arrive :

Ici, nous prenons l’année (YEAR) de la date actuelle (CURRENT_DATE) à laquelle nous soustrayons l’année de la date de naissance.

Note : nous employons CURRENT_DATE() plutôt que NOW() car celle-ci retourne une date au format YYYY-MM-DD alors que
NOW() retourne une date sous la forme YYYY-MM-DD HH:MM:SS

Cette soustraction va calculer le nombre d’années entre l’année actuelle et l’année de naissance. Mais elle ne va pas donner un âge juste car elle retournera une année de trop pour ceux qui sont nés à partir de demain.

Nous rajoutons donc :

Ici, nous soustrayons donc le résultat d’un… test.
Ce test consiste à vérifier si la portion “mois-jour” (les 5 derniers caractères) de la date courante (par exemple 04-20 pour 2008-04-20) est inférieure à la portion “mois-jour” de la date de naissance.
Si le test est positif, il retournera 1. S’il est négatif, il retournera 0. Et c’est ce résultat de test soustrait à la différence entre les années qui donnera l’âge réel.

Le dernier morceau de la requête :

Il permet tout simplement de voir si le résultat du calcul donne un chiffre supérieur à 17 (la majorité en France étant fixée à 18 ans).

En changeant cette valeur, on peut également trouver tous les membres mineurs (< 18) ou tous les membres ayant un âge précis (= 30 pour trouver tous les membres de 30 ans).

Voilà. Il existe bien d’autres solutions, en passant par exemple par des timestamps. Mais celle-ci, lorsqu’on a bien compris son principe, a le mérite d’être simple et facilement adaptable.

Des suggestions ?

Si vous avez apprécié cet article, pensez à vous abonner à notre RSS

La compréhension entre les équipes intervenant sur un projet web n’est pas toujours évidente.

Nous avons vu dans le précédent article quelques recommandations pour que les informaticiens gèrent mieux leurs relations avec les équipes marketing.
Cette fois, nous nous adressons aux marketeurs.

Recommandations aux marketeurs pour maintenir de bonnes relations avec les équipes de développement.

1. Même conseil qu’aux informaticiens : N’oubliez jamais que vous travaillez dans la même entreprise, sur le même projet et que votre objectif est donc commun : la réussite du projet.
   Les conflits entre services sont stériles et improductifs. Une collaboration étroite et une bonne entente ne peuvent aboutir qu’à la réussite du projet.
2. Impliquez les équipes techniques à la préparation du cahier des charges fonctionnel.
   Faire participer les chefs de projets techniques à certaines réunions pourra vous faire gagner un temps précieux. Ils pourront vous aider à mieux définir certaines fonctionnalités en vous apportant un regard technique.
3. Ne considérez pas les informaticiens comme des extra-terrestres.
   Ce sont des humains, comme vous ! De plus, il se peut qu’ils fassent partie de la cible commerciale du site en développement, ils pourront donc peut-être avoir un avis intéressant.
4. Soyez ouverts aux suggestions des équipes techniques.
   Conséquence directe du point #3. Vous n’êtes pas parfait et pouvez vous tromper, un regard externe à l’équipe marketing peut toujours être intéressant.
5. Ne bâclez pas le cahier des charges fonctionnel.
   Le cahier des charges fonctionnel est au site web ce qu’est le scénario au cinéma. Trop souvent, délais obligent, vous vous contentez de remettre un document qui ressemble plus à un synopsis qu’à un scénario. Il en résulte de nombreuses incompréhensions avec l’équipe technique, de nombreux retards et, souvent, l’abandon de fonctionnalités auxquelles vous teniez particulièrement. Mieux vaut consacrer deux semaines supplémentaires à la rédaction d’un bon cahier des charges que perdre 6 mois à cause d’un document incomplet.
6. Faites savoir quand vous ne comprenez pas un aspect technique sur lequel on vous demande votre avis.
   A chacun son métier, il n’y a pas de honte à ne pas comprendre tout ce que vous dit un informaticien. Mais n’hésitez pas non plus à lui demander à parler un langage que vous comprenez.
7. Préparez des procédures de test complètes.
   Pendant la phase de développement technique, consacrez le temps qu’il faudra à la préparation d’un vrai “torture-test” qui vous permettra de vérifier point par point tous les éléments prévus dans le cahier des charges. C’est cette phase de tests qui vous permettra de valider le site, d’en détecter les bugs, les incohérences et les manques. Plus vous aurez préparé le test, plus le test sera efficace.
8. Suivez de près le développement.
   Ayez en permanence un oeil sur le planning et l’autre sur l’avancement des travaux. Ne vous contentez pas de réponses du style “ouais c’est bon on avance”, insistez pour voir des éléments concrets. Vous pourrez ainsi, à tout moment, avoir une vision globale sur les éventuels retards, les difficultés rencontrées et pourrez ainsi anticiper d’éventuels blocages ou conflits.
9. Ne vous emballez pas dès que vous avez une nouvelle idée.
   Rien de pire pour un projet que d’ajouter des tas de nouvelles fonctionnalités pendant le développement. Lorsque vous êtes certain d’avoir trouvé “l’idée du siècle”, pesez le pour et le contre, parlez-en, prenez du recul. C’est seulement une fois votre réflexion menée à son terme que vous pourrez prendre la décision de demander le développement du fruit de votre génie, soit pour tout de suite si elle est vraiment indispensable, soit pour une prochaine version, soit pour… jamais parce qu’en fait, avec le recul, vous réalisez que cette idée n’apporte rien.
10. Ne prenez pas un “non” pour un échec.
    Si un chef de projet technique rejette une de vos demande, il a peut-être de bonnes raisons. S’il n’argumente pas son refus, exigez des explications. Par contre, s’il vous a clairement exposé les raisons de sa réponse, prenez le temps d’y réfléchir et d’évaluer le bien fondé de votre demande.
11. Ne vous contentez jamais d’un “non, ça n’est pas possible”.
    En programmation web, les défis techniques impossibles à concrétiser sont de plus en plus rares. Certains développements peuvent ne pas être possibles pour des raisons budgétaires mais rarement pour des raisons purement techniques.
12. Appliquez vos compétences en interne.
    Vous êtes des marketeurs, sachez, de temps à autres, vous comporter avec les équipes de développement comme vous le feriez avec vos prospects ou vos clients. Le développement est un activité exigeante. Sachez motiver et fidéliser les équipes techniques pour qu’elles prennent du plaisir à travailler sur le projet et qu’elles évitent de se lasser que, tout au long du développement, elles se sentent impliquées.

Pour clore ce chapitre sur les relations entre marketing et développement, rappelons que l’ambiance de travail est primordiale, et encore plus dans des secteurs d’activités comme le web où les intervenants passent de très nombreuses heures au bureau.

Si vous avez apprécié cet article, pensez à vous abonner à notre RSS

Voici donc la première série de recommandations annoncées ici.

Ces 12 points sont destinées aux informaticiens et ne sont bien évidemment pas des règles absolues. Chacun peut les adapter, les améliorer, les ignorer ou les compléter.

12 recommandations aux chefs de projets et développeurs Web pour maintenir de bonnes relations avec les équipes marketing.

1. N’oubliez jamais que vous travaillez dans la même entreprise, sur le même projet et que votre objectif est donc commun : la réussite du projet.
   Les conflits entre services sont stériles et improductifs. Une collaboration étroite et une bonne entente ne peuvent aboutir qu’à la réussite du projet.
2. Pensez toujours à l’utilisateur final.
   Les formations informatiques ont parfois un défaut : elles se concentrent totalement sur l’aspect technique et oublient souvent l’aspect ergonomique. Lorsque vous codez, gardez toujours un regard objectif, imaginez comment vous réagiriez si vous ne connaissiez rien en informatique et qu’on vous installe à un clavier face à votre site. Vous ne développez pas le site pour vous mais pour des utilisateurs, des clients.
3. Participez à la rédaction du cahier des charges fonctionnel.
   Même si les équipes marketing y sont parfois opposées, insistez pour participer aux réunions importantes pour pouvoir y apporter, si nécessaire, un avis technique et ainsi, souvent, faire gagner du temps sur certaines prises de décisions.
4. N’hésitez pas à faire des suggestions.
   Ce n’est pas parce que vous êtes un informaticien que vous ne devez pas avoir des idées ! Encore une fois, regardez le projet avec un regard neutre et servez vous de vos compétences techniques pour suggérer des idées qui pourront apporter un plus au site. Mais attention : ne soyez pas frustré ou vexé si toutes vos idées ne sont pas retenues.
5. Ne planifiez rien tant qu’on ne vous a pas remis un cahier des charges fonctionnel complet.
   Le cahier des charges fonctionnel est trop souvent négligé. Simples captures d’écran, simple schéma, feuilles volantes… Soyez intraitable sur ce sujet. Le cahier des charges fonctionnel est la base de tout votre travail. C’est lui qui permettra la rédaction du cahier des charges technique. C’est lui qui vous permettra de concevoir le planning. Un cahier des charges fonctionnel bâclé ou incomplet peut faire prendre des semaines ou des mois de retard au projet et contribuer aux mauvaises relations entre services. Et c’est sur l’informatique que sera portée la responsabilité vu que vous aurez accepté de prendre en charge un dossier incomplet.
6. Signalez toujours les incohérences fonctionnelles dès que vous les constatez.
   Au fur et à mesure que vous codez certaines fonctionnalités vous pouvez constater qu’il y a un problème, soit logique, soit ergonomique. N’attendez pas d’avoir fini de coder cette partie pour en parler : vous éviterez ainsi de perdre du temps à recoder des parties que vous venez de coder.
7. Parlez un langage que les non-informaticiens comprennent et ne faites pas semblant de ne pas comprendre lorsqu’on s’adresse à vous en termes non-informatiques.
   Tout le monde n’est pas obligé de connaître la terminologie informatique. Mettez vous au niveau de vos interlocuteurs, parlez un langage que le commun des mortels peut comprendre. Ce sera bénéfique pour votre image dans les autres services et évitera des problèmes liés à des incompréhensions sémantiques.
8. Sachez dire non… mais argumentez.
   Trop d’informaticiens se replient derrière des “non, ça n’est techniquement pas possible” ou “non, on n’aura pas le temps”, … Le “ça n’est techniquement pas possible” est de moins en moins crédible. Nous savons tous que les choses pas possibles en informatique se font de plus en plus rare.
   Le pire non que vous pourriez formuler est un “non, ça n’est pas une priorité”. Ce n’est pas à vous de dire ce qui est une priorité ou pas au niveau marketing, communication ou stratégie. Ce n’est pas votre rôle. Donc, dites non, mais uniquement si c’est justifié.
9. Sachez dire oui… mais pour la prochaine version.
   A l’inverse de ceux qui disent systématiquement non, il y a ceux qui disent toujours oui. Et ça n’est pas mieux. A force de dire oui à tout, vous finissez par surcharger votre planning et par ne plus pouvoir tenir les délais. Concertez-vous avec les demandeurs, gérez les demandes par priorités et attribuez-les aux versions adéquates.
10. Prévoyez toujours dans vos planning une marge pour les modifications imprévues mais indispensables.
    Même lorsque les cahiers des charges sont parfaits, il y aura forcément une part d’imprévisible. Le marketing peut par exemple réaliser en cours de développement qu’une fonctionnalité “vitale”, oubliée dans le projet initial, doit être codée car le principal concurrent vient de la mettre en ligne et dans ce cas, la stratégie commerciale sera la priorité et vous devrez accepter ces imprévus.
11. Tenez à jour les plannings et les états d’avancement.
    Plus vos interlocuteurs auront une visibilité réaliste et concrète sur l’avancement du projet, plus ils vous laisseront tranquille et auront confiance en vous.
12. N’oubliez pas que le code n’est pas une fin mais un moyen.
    L’utilisateur final ne verra jamais le code (sauf si vous avez mal assuré au niveau de la gestion des erreurs). Votre code n’a qu’un objectif : rendre concret un projet. Soyez humble !

Quoi de plus agréable que de s’investir dans un projet sur lequel les équipes travaillent en symbiose.

A vous de montrer à vos collègues que vous n’êtes pas un “codeur autiste” mais un humain accessible et ouvert.

A suivre bientôt la troisième et dernière partie : les recommandations pour les marketeurs.

Si vous avez apprécié cet article, pensez à vous abonner à notre RSS

Parfois, (trop) souvent même, on constate dans les entreprises web un important problème relationnel entre les équipes de développement informatique et les équipes marketing.

Ce manque de communication, cette surdité des uns envers les autres, a, discrètement mais immanquablement, de lourdes conséquences sur la conduite du projet.

Retards accumulés, fonctionnalités abandonnées, incohérences dans la strucutre du site sont, avec bien d’autres, les séquelles de cette incompréhension.

L’aspect culturel des formations qui conduisent à ces deux métiers est certainement la principale cause de ce phénomène. Les marketeurs considèrent souvent les informaticiens comme des autistes alors que les développeurs classent leurs collègues du marketing dans la catégorie des guignols qui ne servent à rien.

Forcément, dans pareille configuration, personne n’avance.

Je vais donc vous proposer dans deux prochains billets deux séries de règles, assez simples à mettre en application, et qui vous permettront certainement d’assainir les relations avec les équipes avec lesquelles vous devrez, de toutes façons, travailler quotidiennement sur le même projet.

La première série s’adressera aux informaticiens. La suivante sera pour sa part destinée aux marketeurs.

à suivre…

. partie 2/3 : recommandations aux informaticiens

Si vous avez apprécié cet article, pensez à vous abonner à notre RSS

Que ce soit pour générer des statistiques, rediriger des requêtes, gérer des langues, … vous pouvez avoir besoin d’analyser la structure de l’URL qui appelle votre script.

Il est fréquent de voir dans le code de certains développeurs des fonctions complexes avec des tas d’explode, d’expressions régulières, etc.

Il existe pourtant une fonction PHP faite exactement pour ça : parse_url().

Son usage est extrêmement simple :

Le premier paramêtre, $url, est obligatoire. Il s’agit tout simplement de l’adresse à analyser.

Le second, $component, est lui facultatif. Il permet de récupérer uniquement un élément de l’URL si les autres ne vous intéressent pas.

Dans le cas où vous n’utilisez que le premier paramêtre, la fonction vous retournera un tableau. Par contre, si vous utilisez le deuxième paramêtre, vous aurez dans ce cas une chaîne en retour.

Les exemples

Imaginons que vous souhaiter analyser l’adresse suivante :

Un parse_url sur cette adresse vous retournera le tableau suivant :

Si l’on souhaite récupérer uniquement le chemin, on utilisera la constante PHP_URL_PATH.

L’appel de la fonction sera donc :

et dans ce cas, le résultat sera une simple chaîne :

Les éléments récupérables

Voici un exemple qui va solliciter tous les éléments que parse_url est capable de retourner :

Nous aurons cette fois le tableau suivant :

Ces 8 éléments peuvent être retournés individuellement en utilisant en deuxième paramêtre l’une de ces constantes :

Voilà :)

Si vous avez apprécié cet article, pensez à vous abonner à notre RSS

Il arrive souvent qu’un développeur PHP ait besoin d’intégrer à son code une fonction de génération aléatoire de mots de passe ou de clés diverses.

Je vous propose ici une fonction que j’utilise régulièrement et qui vous permettra de générer ces chaînes en choisissant leur longueur minimum, leur longueur maximum et leur type de contenu.

Je m’étais inspiré d’une fonction trouvée si je me souviens bien dans des commentaires de php.net.

Vous pouvez très bien faire évoluer cette fonction en lui ajoutant tous les éléments dont vous avez besoin. Vous pouvez par exemple lui rajouter un tableau de symboles (@#!, etc) ou supprimer certains caractères. Par exemple, certains ont l’habitude de supprimer les 0 (zéros) et les O (lettre 0) afin d’éviter toute confusion entre eux.

A vous d’être créatifs ;)

Si vous avez apprécié cet article, pensez à vous abonner à notre RSS

Bissextile : Se dit de l’année qui comporte un jour supplémentaire au mois de février, c’est-à-dire qui a 366 jours, et qui revient tous les quatre ans.

Dans les calculs de dates, il peut parfois être utile de savoir si une année est bissextile ou pas.

Rappelons que sont bissextiles, les années multiples de 4 et non multiples de 100 exceptées les années multiples de 400.

On peut donc effectuer ce test de cette façon :

ou sur une seule ligne :

C’est tout ;)

Si vous avez apprécié cet article, pensez à vous abonner à notre RSS