Sorcellerie Web - Bave de crapaud

Widget Gtalk

J.Ducastel — Wed, 27 Feb 2008 12:05:00 +0100

Je viens de découvrir (via Koops) que Google propose un widget Gtalk pour blog permettant aux visiteurs de la page sur laquelle il est embarqué de vous contacter sur votre messagerie. (Gtalk est son service jabber fournir avec chaque adresse Gmail).

Ma première réaction :: Wouah, super pratique, je vais le coller illico un peu partout, notamment sur mon univers netvibes.
Deuxième réaction :: Combien de temps avant de me faire spammer ma messagerie instantanée ?

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 ?

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.

Une cinquième colonne chez Google ?

J.Ducastel — Wed, 27 Jun 2007 13:21:00 +0200

Un rebond sur la théorie qui veut que le tueur de Google viendra de l'intérieur.

En sachant que Google autorise 20% du temps de travail pour la recherche de nouvelles idées je vous laisse imaginé combien de projets intéressants naissent des labos de Google.

A première vue Google est vraiment la société du moment avec un chiffre d’affaire en hausse constante. Et pourtant il se pourrait bien que la menace vienne de l’intérieur lorsque l’ont sait qu’il y’a énormément de personne douée au sein Google et que les idées intéressantes doivent pleuvoir, mais seulement un faible pourcentage d’entre elle sont retenu. Il en reste donc pour les employés qui pourrait saisir l’occasion de tenter leur chance.

-- Koops

La citation ci-dessus résume la traduction d'un article en anglais.

Il y a tout d'abord une petite inexactitude dans la source. Les employés de Google ne sont pas tenus de passer 20% de leur temps à trouver de nouvelles idées pour Google, mais peuvent s'ils le souhaitent employer 20% de leur temps sur un projet de leur choix, qu'il s'agisse d'un projet open source, d'un projet perso ou de tester leur idée géniale de nouveau produit Google. Ce qui évente un peu le concept d'une armée secrète minant le géant de l'intérieur : celui-ci n'en a cure.

Par ailleurs, il n'est pas suffisant d'avoir une idée géniale pour concurrencer Google (ou n'importe quelle firme informatique). Si Google rachète et assimile peu à peu tous les services web à succès, c'est par un phénomène classique de concentration que je vois difficilement s'inverser. C'est une loi similaire à celle de la gravitation : une fois qu'un corps aquiert une masse suffisante pour piéger et attirer à lui la matière environnante, le phénomène ne fait que s'accélerer.

Google ne dispose pas seulement d'une bonne part des brillants cerveaux de la Silicon Valley. Il dispose aussi de l'infrastructure matérielle suffisante pour faire tourner une floppée de services web à l'échelle mondiale. Et notamment, une seule instance de son OS maison (un dérivé de linux) tournant sur plus de cent mille serveurs.

De plus, le phénomène de concentration ne s'arrête pas aux ressources productives, matérielles et humaines; mais également aux consommateurs et à leurs données. Il existe plusieurs centaines de moteurs de recherche, mais pour beaucoup d'internautes, le web c'est google et le concept de signet leur est étranger : il suffit d'une recherche sur le moteur en page d'accueil pour retrouver tous leurs sites habituels.

Et une fois créé un compte Google, la pente de la facilité nous amène à lui confier de plus en plus de nos besoins : pourquoi multiplier les comptes d'accès quand un seul compte nous offre courriel, édition et stockage de documents en ligne, messagerie instantanée, agenda, groupes de discussion, stockage de favoris, stockage et publication de photos, lecteur de flux, blog, edition et hébergement de pages web ?

xml-rpc blah blah blah

J.Ducastel — Thu, 11 May 2006 20:08:00 +0200

Je soupçonne les concepteurs de la spécification XML-RPC d'avoir oeuvré en fonction des limitations de leur propre implémentation initiale... Je travaille en ce moment sur une librairie en php et je trouve le format assez torturé.

Par nature le XML est un format bavard puisqu'on retrouve le nom de chaque element dans le tag de fermeture, alors qu'avec ses règles strictes d'imbrication un simple </> aurait suffi. De plus, les concepteurs de dialecte XML sont souvent des gens un poil anxieux qui multiplient les éléments, je ne sais pas trop pourquoi.

Mais alors le xml-rpc, c'est franchement le bordel. Bon, il y a de quoi vouloir etre prevoyant puisqu'il s'agit d'un language générique pour faire des appels de procedure distante. (par exemple, les fameux ping et trackback des blogs). Mais quand je vois :

<?xml version="1.0"?> <methodResponse> <fault>
<value> <struct> <member> <name>faultCode</name>
<value><int>4</int></value> </member>
<member> <name>faultString</name>
<value><string>Too many parameters.</string></value>
</member> </struct> </value> </fault>
</methodResponse>

Au lieu de, par exemple, ça :

<?xml version="1.0"?> <methodResponse> <fault>
<code>4</code> <desc>Too many parameters.</desc>
</fault> </methodResponse>

Je me dis que la volonté initiale de simplicité s'est un peu perdue en route... J'ai du mal à comprendre cette volonté de se passer totalement d'attributs et d'intercaler des éléments inutiles comme le <data> entre un <array> et les <value>. Le pire, c'est encore le type des <value> qui est un élément s'intercalant entre l'élément et son contenu, et optionnel avec ça !!! Il aurait été tellement plus logique d'utiliser un attribut. Pfff...

W3C Go Home ?

J.Ducastel — Fri, 24 Sep 2004 17:40:00 +0200

Ce log est une réaction à un article d'Arno publié sur le uzine.net, critiquant (non sans raison) les ayatollahs du XHTML

Cet article enonce intelligemment pas mal de vérités, notamment que la norme en soi est moins importante que la façon de l'appliquer. Cela dit, je ne suis pas totalement d'accord avec certains des arguments; et donc avec la conclusion :

Il n'y a donc plus de méthode " naturelle " d'apprentissage pour un système tel que le XHTML " strict ". Gros avantage évidemment : seuls les professionnels de la profession qui sont allés à l'école pourront réaliser des sites Web.

Ce qui nous ramène à la justification habituelle de l'application stricte et rigide des normes : interdire l'accès aux nouveaux entrants en affichant un alibi de qualité.

Le HTML 4 ne va pas devenir obsolète. Les navigateurs sauront toujours lire les vieux sites, et les vieux navigateurs sauront toujours afficher l'essentiel (le contenu) des sites en xhtml+css
Le xhtml n'est pas plus compliqué à apprendre que le html, il partagent d'ailleurs l'essentiel de leurs balises. Ce qui est plus compliqué est la mise en page à l'aide exclusive des feuilles de style, pas la rédaction du document lui même. Or la mise en page en tableaux, n'en déplaise à Arno, n'était pas elle même beaucoup plus démocratique. Il s'agit d'une technique professionnelle qui n'a été que peu reprise par le public réllement novice. La mise en page par feuille de style, si elle est plus compliquée à réaliser, est par contre pompable : la séparation du contenu et de la mise en page permet de piquer des élements de mise en page de ci de là et de l'appliquer à son propre contenu.
Il existe certainement quelques ayatollahs, intégristes intolérants, qui se comportent comme des croisés en terre barbare. Cela dit, le mouvement d'évangélisation autour du xhtml+css ne concerne initialement que le microcosme des développeurs web; il s'agit à mon sens d'un mouvement de travailleurs (voire de prolétaires, même quand ils sont bien payés, ce qui n'est pas toujours le cas...) qui cherchent à se réapproprier et à rationnaliser leur méthodes de travail. Le coté messianique est dû à ce que cela part d'une philosophie commune à certains informaticiens et scientifiques : la standardisation pour garantir le libre accès à l'information, et que cela affecte potentiellement tous les internautes.
Ces développeurs qui militent pour une standardisation, une séparation du contenu et de la mise en forme, sont (c'est un avis subjectif) de la même école que ceux qui développent et distribuent des outils de publication web libres (la plupart utilisent les techniques en question !).

Standards, open source, même combat !

Indépendance des développeurs

J.Ducastel — Mon, 16 Aug 2004 15:45:00 +0200

Le texte en lui même est un peu insipide, j'imagine que c'est le produit du plus petit dénominateur commun de sensibilités diverses, mais son existence même est intéressante. Depuis quelques temps, un mouvement de fond agite le microcosme des développeurs (programmeurs), notamment web, en faveur de standards, de formats et de logiciels ouverts. Une brève (et personnelle) synthèse :

Les logiciels, formats et standards privés (à code source secret, dits propriétaires) lient les utilisateurs à la firme qui les produit, et c'est là leur raison d'être. Accessoirement, développer dans un tel environnement est une plaie : pénurie d'information, communauté restreinte, réusabilité restreinte voire nulle...

à l'inverse, les logiciels, formats et standards libres/ouverts, c'est à dire [à code source] publics, permettent d'adapter tout ou partie d'un logiciel à ses besoins, favorisent la diversité, et surtout, du point de vue du développeur, l'accès à l'information nécessaire ainsi que le partage et la réusabilité du code existant.

On voit ici à l'oeuvre une approche coopérative, mutualiste; adoptée par des travailleurs pour leur propre intérêt collectif; bien que guidée par un idéal de partage et de diffusion de la connaissance (qui se retrouve me semble t'il dans les milieux scientifiques); et qui sert en outre les intérêts des "consommateurs" (les utilisateurs de logiciels). C'est beau.

La declaration d'indépendance des développeurs [en]