Sorcellerie Web - Tag - pratique

Ali Baba et les 40 mauvaises pratiques du programmeur (PHP)

J.Ducastel — Thu, 14 Feb 2008 18:39:00 +0100

Je suis tombé via le planet PHP sur une liste de 40 points qui font un mauvais programmeur PHP. Je vais essayer de la traduire et de la commenter.

1 - Ne pas commenter son code proprement suivant un standard comme phpDoc: C'est le service minimum en matière de commentaires. Il est vital de savoir ce qu'une fonction attend en parametre et ce qu'elle retourne. De plus, cela permet la génération d'une documentation; et certains éditeurs tels que Komodo edit s'en servent pour afficher une aide en ligne lorsque vous y faites appel .
2 - Ne pas voir le bénéfice d'un bon outil de développement intégré tel que Zend Studio ou Eclipse.: Ces usines à gaz ? Non, désolé.
3 - N'avoir jamais utilisé d'outil de contrôle de versions tel que Subversion: Plus que la qualité du programmeur, je crois que c'est surtout une question de projet. Pour une appli professionnelle ou un projet open source, c'est vital, mais on n'a pas toujours un serveur subversion sous la main pour un site perso....
4 - Ne pas adopter de convention de codage et de nommage et s'y tenir, au moins à l'échelle d'un projet.: Qui ne s'est pas déjà arraché les cheveux avec le nom des fonctions natives php (avec ou sans underscore), et pire l'ordre des arguments qui varie d'une fonction à l'autre ?
5 - Ne pas adopter une méthodologie constante: Faudrait déjà en avoir une. Personnellement, je suis plutôt habitué à La Rache.
6 - Ne pas échapper ou valider les variables pour les requêtes SQL: Là c'est plus de la mauvaise programmation, c'est l'amour du risque.
7 - Ne pas planifier l'application avant de commencer à coder.: Dans un monde idéal, les utilisateurs sauraient ce qu'ils veulent les spécifications ne changeraient pas tous les trois mois. Dans un monde idéal.
8 - Ne pas pratiquer le développement dirigé par les tests.: Les test unitaires, c'est bon. Mangez-en.
9 - Désactiver l'affichage des erreurs: La première fois qu'on l'active, ça fait mal. Mais après, c'est tellement bon. Et surtout, cela permet généralement de préparer en douceur la prochaine mise à jour de PHP.
10 - Ne pas voir les bénéfices d'un débogueur: Il n'y a qu'un débogueur ici, c'est moi. Sans rire, pour un langage web interprété, le débogueur, c'est un petit coup de rafraichissement de la page. Non ?
11 - Ne pas refactoriser son code: On peut faire autrement ? Mon nom est Refactoring. Constant Refactoring.
12 - Ne pas séparer les couches de traitement en utilisant un motif tel que MVC.: Ou MVT. Elementaire, mon cher Django.
13 - Ne pas connaitre les acronymes KISS, DRY, MVC, OOP, REST: Mouais, pas besoin de connaitre les acronymes pour pratiquer.
14 - Ne pas retourner de contenu mais faire des print() depuis les fonctions et classes: Autrement dit, éviter les effets de bord. Et appliquer le principe de la séparation des couches de traitement.
15 - Ne pas connaitre les avantages des tests unitaires et des tests en général: On avait pas dit DRY ? cf #8
16 - Retourner du html au lieu de données / objets: Pareil, voir #14
17 - Coder en dur les messages et les parametres de configuration: Coder en dur, c'est mal
18 - Ne pas optimiser ses requetes SQL: Je veux bien, mais qui le fait vraiment au lieu de juste le prétendre ?
19 - Ne pas utiliser __autoload(): J'ai la malchance de maintenir des applications PHP4. Mais j'ai mieux qu'autoload : Webappkit"
20 - Ne pas autoriser la gestion intelligente des erreurs: ???
21 - Utiliser GET au lieu de POST pour toutes les actions de destruction: Ca, c'est pour les applications accessibles aux moteurs de recherche. Qui suivront tous les liens en GET qu'ils trouveront. Et ne savent pas si cela correspond à un document ou une action sur un document. Trop dur pour vous.
22 - Ne pas savoir se servir des expressions régulières: Qui voudrait se priver de si belles migraines ?
23 - N'avoir jamais entendu parler d'injection SQL ou de scripting multisites
24 - Ne pas permettre de configurer simplement ses classes, que ce soit par arguments passés au constructeur, via des méthodes dédiées ou des constantes: Je suis moi-même un fanatique de la configurabilité. Un bon script générique avec une configuration spécifique peut parfois permettre de s'économiser bien des lignes de code. C'est ce qui a présidé au concept des Outils (Tools) pour Webappkit.
25 - Ne pas connaitre les bénéfices et limitations de la programmation orienté objet: J'ai du mal à me souvenir de ma brève période procédurale puis fonctionnelle...
26 - Mal utiliser la POO
27 - Penser que du code réutilisable implique du code POO: Parfois une bonne fonction peut suffire, mais ça devient rare...
28 - Mal choisir ses valeurs par défaut
29 - Ne pas avoir un unique fichier de configuration: Pas d'accord. Les premières versions de webappkit fonctionnaient comme cela et pour de grosses applis, cela devient un enfer à maintenir. D'autant que tout n'est pas forcément utilisé et ralentit donc inutilement le tout.
30 - Croire masquer le contenu d'un script en le renommant .inc au lieu de .php
31 - Ne pas utiliser une couche d'abstraction de base de données.: Je plaide coupable. Je suis masochiste et je préfère faire mon SQL à la main.
32 - Se répéter. Si vous devez faire du copier-coller de code, il y a sans doute une erreur de design.
33 - don't make a function/class/method do just one thing and don't make them interact.: Moi pas compris. Toi parler moi ?
34 - Ne pas se servir des mécanismes objets tels qu'interface, héritage multiple et (modifeurs d'accès ?)
35 - Ne pas optimiser l'architectire de son application en suivant les motifs de conceptions éprouvés.
36 - Ne pas autoriser les chemins relatifs: Les chemins absolus, c'est le mal. Vous brulerez en enfer pour cela.
37 - Polluer l'espace de nommage global en en préfixant pas ses noms de fonctions.
38 - Ne pas autoriser le prefixage des tables de sa base de données
39 - Utiliser un moteur de gabarits séparé: Hein ? Quoi ? Qu'est-ce qu'il entend par "séparé" ?
40 - Ne pas s'inspirer des frameworks PHP existants: Les frameworks Python, ça compte ?

Fichiers de configuration

J.Ducastel — Fri, 07 Dec 2007 16:27:00 +0100

Lorsqu'on développe une application ou un composant de manière à pouvoir le réutiliser, il est nécessaire de pouvoir définir une configuration d'environnement de manière séparée du code. Cela peut être fait par inclusion d'un fichier se contentant de déclarer un suite de variables ou de constantes dans le language de l'application (c'est le cas des fichiers urls.py et settings.py de Django). Mais il est généralement préférable d'utiliser un format qui puisse être lu et modifié par un non-programmeur.

Le format INI

A la fois très simple et très largement utilisé, le format INI permet de définir des paires clefs/valeur, éventuellement organisées par sections. Il est suffisamment intuitif pour être modifié par quelqu'un qui n'en connait pas la syntaxe.

C'est le format de configuration de PHP, et une fonction native permet de lire un tel fichier et de récupérer directement les données stockées dans un tableau associatif, à deux dimensions en activant le support des sections.

Python dispose du module ConfigParser, qui supporte une syntaxe un peu plus évoluée.

Le format XML

Le patriarche des formats de structuration et d'échange de données. Plus qu'un format de fichier, XML est une grammaire dont dérivent des zillions de syntaxes, qu'elles soient standardisées ou propriétaires. Très largement utilisé pour la configuration d'application, ce n'est pourtant pas forcément des plus simples à éditer. De plus, il est généralement assez lourd à manipuler en programmation, ce qui n'est pas terrible en termes de performance. Surtout dans le cadre d'une application web, si celle-ci doit lire le fichier à chaque requete...

Le format YAML

Si vous avez besoin de données de configuration plus élaborées, notamment s'il vous faut plus de deux niveaux de données ou des textes sur plusieurs lignes, il y a le format YAML. Celui-ci se veut une alternative à XML, qui soit à la fois plus concise (donc plus légère à stocker) et plus lisible pour un être humain. Ce qui en fait un candidat idéal pour des fichiers de configuration. Comme en Python, l'indentation y joue un rôle clef.

Contrairement à INI, il n'est pas supporté nativement par PHP, mais la librairie Spyc permet de convertir ces fichiers en tableaux de données et inversement.

Python dispose de la librairie PyYaml.

Petit guide à l'usage du developpeur agile

J.Ducastel — Fri, 23 Nov 2007 10:16:00 +0100

Il etait déjà dans ma liste Amazon, mais une critique de BioloGeek m'a décidé à l'acheter sur le champ. Et je ne regrette pas. Plus qu'un ouvrage sur Python, il traite pour l'essentiel de méthodologie et de bonnes pratiques de développement. Beaucoup de conseils sont génériques et transposables à d'autres language comme le PHP.

Astuces Firefox

J.Ducastel — Fri, 18 Feb 2005 15:51:00 +0100

J'imagine que la plupart de mes lecteurs connaissent et utilisent déjà Firefox, le navigateur open-source issu de Mozilla et Netscape. Plus sûr, plus fonctionnel, plus conforme aux standards du web, plus extensible, le navigateur du geek. Je viens par hasard de découvrir une fonctionnalité qui roxe et j'en suis tout guilleret, je me suis dit que j'allais noter ici quelques astuces d'utilisation à destination des novices ou moins novices. Il existe bien un guide d'utilisation, mais encore incomplet.

signets

La découverte du jour : à la longue, les bookmarks s'accumulent et deviennent de moins en moins accessibles dans les dossiers et sous-dossiers, il faut faire faire une bonne balade à sa souris avant de retrouver celui qu'on cherche, surtout si on ne sait plus où il se trouve. Tadaam ! CTRL+B ouvre le panneau latéral des signets (Bookmarks) et met le focus sur un champ de recherche. Au fur et à mesure de la frappe, la liste des signets se réduit aux résultats de la recherche. Helas, la recherche ne porte que sur le nom du signet, pas sur les mots-clefs ni la description associés.
La barre personnelle : il s'agit d'un dossier spécial au sein des signets qui peut être affiché comme une barre d'outils, et ainsi rendre les signets couramment visités plus accessibles. Il est également possible d'y mettre des dossiers de signets.
Bookmarks Synchronizer : cette extension permet de synchroniser les signets avec un fichier de stockage accessible via FTP, très pratique si vous utilisez plusieurs ordinateurs.
Add Bookmark Here : cette extension rajoute simplement un menu homonyme à vos dossiers de signets, permettant d'ajouter directement à ce dossier la page en cours d'affichage. C'est une question de goût, moi je trouve ça plus pratique.
Fils de syndication (RSS, Atom) : Depuis la 1.0, Firefox affiche les fils de syndication comme des marques pages dynamiques ou "live bookmarks", des dossiers virtuels contenant les liens du fil, mis à jour automatiquement. Lorsqu'un fil de syndication est disponible pour une page (pour ce site par exemple), vous verrez apparaitre en bas à droite, dans la barre de statut, une icône permettant de s'y abonner en insérant ce signet dynamique dans vos favoris. Vous pourrez ainsi suivre aisément l'actualité du site et atteindre directement les contenus qui vous intéressent. Quelquefois, un site offre un fil de syndication (généralement un petit bouton orange portant la mention rss, xml ou atom) sans que l'icone apparaisse, c'est que le lien n'est pas mentionnée explicitement dans l'en tête de la page. Il est alors quand même possible d'ajouter le fil en copiant son adresse (clic droit > copier l'adresse du lien), puis en l'ajoutant manuellement dans le gestionnaire de signets (marques pages > gérer les marques pages > fichier > nouveau marque page dynamique).
Fin du fin, bookmarks home est une extension qui génère une page portail à partir de vos signets. Elle prend en compte les signets dynamiques, il est possible d'exclure des dossiers et même de modifier la feuille de style !

Onglets

Onglets : un des atouts de firefox est sans contexte la navigation par onglets, permettant de n'ouvrir qu'une fenêtre de navigateur tout en consultant simultanément plusieurs pages. Le propre de l'hypertexte est de pouvoir être truffé de liens. Avec Firefox, il est possible de les ouvrir dans un autre onglet tout en continuant sa lecture avec un middle clic (clic sur la molette ou le bouton central de la souris), en ayant configuré le navigateur pour ne pas ouvrir les liens en avant-plan (c'est la config par défaut).

De plus, il est possible de sauvegarder l'ensemble des onglets ouverts dans un dossier en cochant la case "sauver comme un groupe d'onglets" lors de la création d'un signet. Sachant qu'il est possible d'ouvrir tous les liens des dossiers comme une série d'onglets via le menu "ouvrir dans des onglets", il est alors possible de se créer des sessions thématiques, ouvrant par exemple d'un clic un site en cours de développement, phpMyAdmin, et diverses pages de documentation...

MiniT+ est une extension offrant un menu supplémentaire de configuration des onglets

Navigation

Adblock est probablement une des extensions les plus appréciées, elle permet de bloquer les bannières de publicité ou autres éléments gênants que vous lui aurez indiqué. Elle fonctionne par reconnaissance de l'adresse d'origine. Sachant que la plupart des publicités proviennent de serveurs spécialisés exterieurs aux sites visités, après quelques jours d'apprentissage celles-ci se feront de plus en plus rares. Pour cela, faites un clic droit sur les publicités (ou cliquez sur l'onglet adblock dans le cas d'un élément en Flash). Sélectionnez adblock image, ou adblock iframe la cas échéant. Une boite de dialogue s'ouvrira vous permettant d'affiner la règle de blocage basée sur l'url. Vous pouvez alors remplacer certaines parties de l'url par des * servant de jokers : tout élement ayant une url correspondant au masque ainsi défini sera alors supprimé des pages que vous visitez ! Quelques exemples de règles : http://ad.*.doubleclick.net/*, http://*.smartadserver.com/*, http://ad.*.doubleclick.net/*...
Nuke Anything permet de supprimer d'un clic droit n'importe quel élément de la page (hors Flash), ce qui permet par exemple de faire un petit nettoyage des éléments inutiles avant impression. Cela dit, il est possible que la page possède une feuille de style spécifique à l'impression qui s'en charge déjà. C'est par exemple le cas de la page que vous lisez.
Recherche dans la page : avec CTRL+F, vous ouvrez une discrète barre de recherche en bas de la fenêtre du navigateur, juste au dessus de la barre de statut. Là encore, les résultats s'affichent au fur et à mesure de la frappe, notamment si vous activez l'option surligner. Cela permet de garder la page sous les yeux tout en faisant sa recherche !

tags, meta tags delicious

J.Ducastel — Wed, 04 Feb 2004 17:43:00 +0100

english readers : please scroll down for english translation

Pour ceux qui ne connaitraient pas delicious, il s'agit d'une application web de stockage de signets en ligne. Ses points forts :

Hierarchie plate : vous classez vos signets par mots clefs (tags), chaque signet peut recevoir autant de mots clef que nécessaire. C'est un système de classement beaucoup plus puissant, je pense, que le classement arborescent par catégories.
Mutualisation : delicious se présente comme un outil social, les signets sont partagés entre tous les utilisateurs. Chaque utilisateur a le contrôle total sur ses signets et leur marquage, mais une recherche par mot-clef portera sur les signets de tous les utilisateurs : le travail de recherche et de marquage est collectif. C'est la lutte, euh, finale-euh... ;o)
Syndication : chaque page de résultats possède son propre fil de syndication; ainsi on peut suivre l'actualité d'un mot-clef par exemple.
simplicité, gratuité, ergonimie. Il est aussi simple de collecter un signet que de cliquer sur un signet special du navigateur, saisir les mots clefs et valider pour etre redirigé vers la page d'origine.

L'outil est simple et puissant. Tellement que ça donne des idées (je posterai sur le sujet prochainement). En attendant, je tente d'enrichir mes signets par l'usage de meta-tags, que je place entre [crochets], des mots-clefs qui renseignent non pas sur le contenu du signet mais plutot sur sa forme :

langue : [fr] pour un ressource francaise, [en] pour une ressource anglaise, etc. Pour des ressources multilingues je mets autant de tags que nécessaires, ainsi le signet sera present dans une recherche pour chacun de ces tags.
type : [blog], [wiki], [forum], [article] ...selon le type de site hebergeant la ressource.
licence : [gpl] GPL, [cc] creative commons, [lyber] lyber.

Je propose ici cet usage à la communauté. Si vous trouvez l'idée pertinente, reprenez la. Si vous en avez une meilleure, publiez la.

In english, please

If ever you don't know about delicious, it's a bookmarks storage web application. Its strengths are :

Flat hierarchy : bookmarks organization is done through keywords, called tags. Each bookmark can be tagged with as much tags as necessary, so it will be present on a search on all its tags. I think it's a more powerful classification than using a folders tree.
Shared bookmarks : del.icio.us is describing itself as a social bookmarks manager, because the bookmarks and their associated tags are shared amongst users. Each user has plain control over its own bookmarks and tags, but a search on a tag will browse the entire collection. Therefore, the search and classification work is made collective. Free communism rules ;o)
Syndication : each result page provides its own RSS syndication. So you can track a tag, tags combination, a user's tags...
Free, simple, easy. Implementation is just near perfect.

The tool is simple yet powerful. Enough to give me some ideas, but i'll talk about these later. For the moment, i try to enhance it by the use of meta-tags, tags which aren't about indexed content itself, but its form. I put these tags between [brackets] to distinguish them from content indexing tags. Here are the ones i used :

language : [en], [fr], [de] etc. If a content provides translations, i add as many as necessary, so the bookmark is indexed for all potential readers.
Type : [blog] [wiki] [forum] : depends on the kind of website offering the resource.
License : [gpl] GPL, [cc] creative commons, [lyber] lyber.

Use this meta-tags convention if you think it's useful. Please tell me if you have better ideas.