Sorcellerie Web

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 ?

Actu Webappkit

J.Ducastel — Fri, 15 Feb 2008 21:57:00 +0100

La version 0.10.1 est disponible depuis quelques jours. Le site web vient d'être mis à jour.

Webappkit est un système de paquets et un meta-framework pour PHP. C'est un logiciel libre et gratuit, taillé pour le développement agile.

Pour en savoir plus.

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.

Détecter les préférences du navigateur

J.Ducastel — Mon, 03 Dec 2007 19:34:00 +0100

Il bien plus agréable pour l'internaute de disposer directement du contenu qui le concerne (langue, navigateur, OS...) plutot que de devoir fouiller le site web pour l'obtenir. Cela améliore son expérience de navigation, et donc l'attrait pour votre site.

Beaucoup d'entre nous se sont habitués à chercher, en arrivant sur un site, s'il n'en existait pas une version dans sa propre langue. On cherche alors où sont les petits drapeaux, les micro-liens avec code de langue sur deux caractères, etc. Et beaucoup d'utilisateurs ne les trouvent pas, et quittent le site immédiatement, faute de pratiquer la langue affichée. Pourtant, quand le contenu d'un site est traduit, le plus gros du travail est fait; pourquoi ne pas l'afficher directement dans la langue spécifiée par l'internaute pour son navigateur ?

Ceci est également valable pour d'autres préférences. La page de téléchargement de Firefox par exemple est non seulement traduite dans la langue de l'internaute, mais la version proposée au téléchargement est celle correspondant à son système d'exploitation. Tout aussi efficace, la page de bookmarklets pour Del.icio.us est automatiquement adaptée au navigateur en cours. Ceci est possible grâce aux données de préférences et d'environnement utilisateur transmises par le navigateur au serveur web via les en-têtes HTTP.

Outre les préférences de langue, et les particularités eventuelles de l'environnement système d'exploitation/navigateur, il peut être souhaitable de détecter le support de javascript, surtout pour les sites utilisant ajax pour certaines de leurs fonctionnalités. Tout comme le support de flash. La liste est longue, car les possibilités d'HTTP sont encore largement sous-utilisées.

Bien evidemment, il faut garder à l'esprit que ces données ne sont pas fiables, et ne doivent être utilisées que pour définir la version du contenu par défaut, et toujours permettre à l'utilisateur de modifier ces réglages si possible via des liens et des contrôles manuels.

Pour ce qui est de PHP, vous pouvez utiliser un de mes bouts de script ( getting browser language settings with php), ou la classe phpsniff qui semble bien plus complete (pas encore utilisée, je viens de tomber dessus).

Optimisation PHP : les chaines de caractères

J.Ducastel — Fri, 30 Nov 2007 12:16:00 +0100

Voici une petite astuce concernant les chaînes de caractères pour optimiser vos scripts PHP, que certains découvriront peut-être. Prenez l'habitude d'utiliser les apostrophes (simple quotes) plutôt que les guillemets (double quotes). Ceci parce que les chaines entre guillemets peuvent contenir des variables qui seront évalués à l'éxécution. Par exemple :

$uper_riche='Picsou';

// ceci affiche : Bonjour, je suis Picsou
echo "Bonjour, je suis $uper_riche";

// alors que ceci affiche : Bonjour, je suis $uper_riche
echo 'Bonjour, je suis $uper_riche';

// on peut utiliser les accolades pour acceder à des noms complexes
$Picsou->neveux=array('Riri','Fifi','Loulou');
// ceci affichera : Le second neveu de Picsou est Fifi, il en a trois
echo "Le second neveu de Picsou est {$Picsou->neveux[1]}, il en a trois";

Ce qui double son travail, car le code est d'abord interprété une première fois à la lecture du script et découpé en blocs sémantiques (chunks) : variables, chaines, instructions etc. Une chaine entre apasotrophes sera alors conservée telle quelle jusqu'à la fin de l'execution du script, alors qu'une chaine entre guillemets devra être interprétée à chaque évaluation. Par conséquent, il vaut mieux les éviter autant que possible. Par exemple :

/**
* on construit une chaine de caracteres dynamiques en separant bien les chunks variables des blocs statiques
*/
$html='<p>Bonjour, je suis '.$uper_riche.'</p>';

/**
* on ne force pas l'evaluation du parametre passe a une fonction
*/
echo 'Qui est le plus riche ? '.strtoupper('picsou !');

/**
* idem pour les clefs d'un tableau associatif
*/
echo $personnages['picsou']['neveux'][1];

C'est le genre de petites choses qui peuvent paraitre évidentes une fois devenues une habitude, mais qui ensuite évitent de plomber vos scripts inutilement.

Webappkit : un système de paquets pour PHP

J.Ducastel — Wed, 28 Nov 2007 00:14:00 +0100

Le but de Webappkit, c'est de faciliter la réutilisation et le partage de briques logicielles PHP pour les applications web. Pour les développeurs, cela permet de se concentrer sur le code spécifique de l'application en facilitant l'intégration de librairies génériques existantes. Pour les simples bidouilleurs ou webmestres, de créer leur site en assemblant des applications existantes telles que blog, forum, suivi statistique etc.

C'est un de mes projets, et un logiciel libre hébergé sur Google Code. Initialement, il s'agissait d'un meta-framework permettant de définir une pile de scripts à exécuter pour une url ou une branche du site. Depuis la version 0.8, j'ai changé d'approche pour me concentrer sur un système de paquets nommés kits et qui peuvent contenir de la simple librairie (avec gestion des dépendances) à l'application complète.

Tout naturellement, j'ai organisé mes propres librairies sous formes de kits. Elles sont incluses dans l'archive disponible au téléchargement, et je les détaillerai ici prochainement. Télécharger webappkit (la version actuelle est 0.9 alpha). Le projet dispose de son propre blog (en anglais), pour en suivre l'actualité, ainsi qu'un groupe de discussion google.

Utiliser un kit de librairie

Commençons par détailler l'usage le plus simple : un kit de librairie. Concrètement, les kits sont des dossiers à regrouper dans un même repertoire accessible par vos scripts (généralement webappkit/). Pour charger un kit, il faut alors appeler :


/**
* inclusion des librairies du base de webappkit
*/
include_once('webappkit/include-me.php');
/**
* les librairies du kit sont alors incluses, ainsi que les dependances
*/
Webappkit::loadKit('mon_kit');

Les kits peuvent également être organisés en arborescence, un kit contenant lui même des kits ;il est alors possible de charger directement un sous-kit si l'on n'a pas besoin du paquet total. D'ailleurs, charger un kit ne chargera pas nécessairement tous ses sous-kits, il est possible de définir les sous-kits qui seront chargés lors de l'appel du kit parent.


/**
* chargement d'un sous-kit
*/
Webappkit::loadKit('mon_kit.un_sous_kit');

Dans les prochains billets, je détaillerai les usages plus avancés, ainsi que la construction des kits.

Sorcellerie Web

J.Ducastel — Tue, 27 Nov 2007 12:30:00 +0100

Il y a dix ans, j'achetais un modem. C'était bien sûr en RTC, qui me permettait de foncer sur les autoroutes de l'information à la vitesse royale de 33,6Ko/s. Quelques semaines plus tard, j'achetais un livre de référence sur HTML (alors en version 3) et bricolais mon premier site web au bloc-notes. A vrai dire, je n'envisageais même pas encore la possibilité qu'il puisse exister un logiciel permettant de le faire autrement. Et puis il faut dire que j'aime bien mettre les mains dans le cambouis, histoire de comprendre comment ça marche.

J'ai fini par en faire ma profession : développeur web. Comme c'est souvent assez vague pour les non-informaticiens, j'ai coutume de dire que je suis dresseur d'ordinateurs, ou encore que je passe ma journée à écrire des formules magiques, des sorts qui sont lancés chaque fois que la page web est appelée. Comme la sorcellerie, le développement met en jeu des languages et des procédés incompréhensibles pour les non-initiés. Par contre, il n'y a rien de secret pour qui veut apprendre - a condition de ne pas être rebuté par les gros grimoires, et d'avoir la patience de subir quelques messages d'erreur avant de pouvoir réaliser son propre golem.

Libriste convaincu, je tiens ce carnet pour partager mon expérience, mais aussi quelques astuces et scripts, outils pratiques et autres bavardages techniques, en espérant qu'ils vous soient utiles.

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.

Tester Django - modifier ses modèles

J.Ducastel — Mon, 19 Nov 2007 17:16:00 +0100

Ce week-end, j'ai repris mes tests de Django, un framework web en Python. (Ou comment occuper son week-end par temps pourri et grève des transports). Histoire de me simplifier la vie et remettre à plus tard l'installation et la configuration de MySQL sur mon Mac, j'ai opté pour le stockage SQLite (qui est inclus d'office). Voici un bref compte-rendu, ainsi qu'une petite astuce pour les premiers stades d'un développement avec Sqlite

Tout naturellement, je suis parti dans la ré-implémentation incrémentale d'un de mes projets PHP. Ce qui signifie commencer avec des modèles de données très simples, et les enrichir au fur et à mesure. Avec Django, la définition des modèles de données se fait par la rédaction de classes modèles, et la création des tables de la base se fait via un utilitaire en ligne de commande : python manage.py syncdb.

Or cette commande ne crée que les tables n'existant pas encore et ne met pas à jour la structure des tables existantes, ce qui fait que très vite on se retrouve avec des tables dont la structure ne correspond plus au modèle, et une erreur du type no such column. J'ai cru un instant que la commande python manage.py flush vidait la base et donc supprimait les tables, mais elle ne vide apparemment que les données et conserve la structure des tables existantes.

C'est là qu'une fois de plus, Firefox m'a servi de couteau suisse du développement. En cherchant un utilitaire pour inspecter le contenu de la base Sqlite, je suis tombé SQLite Manager, une extension permettant d'administrer entièrement une base Sqlite ! Du coup, ça m'a permis de supprimer la table associée à chaque fois que je modifiais un modèle, et la recréer ensuite via syncdb.

Pour ce qui est de Django, je ne suis pas déçu. Cela faisait longtemps que je le surveillais du coin de l'oeil, et même un peu plus puisque j'ai réalisé une implémentation partielle de son moteur de templates en PHP (actuellement incluse dans webappkit, mon système de paquetages pour applis web PHP). En pratique, c'est encore mieux qu'attendu et la qualité et la richesse de la documentation y est pour quelque chose. Ainsi bien sûr que les qualités du language Python, qui a pas mal d'avance sur PHP a la fois en fonctionnalités et en cohérence.

Quelques liens supplémentaires :

Django-fr, proposant une partie de la documentation en français
Django Book un livre en ligne (a paraitre prochainement)
The B-list un blog très riche en informations et astuces de développement.
Mes signets Django sur Magnolia comme ça je ne recopie pas tous mes liens ici ;)

Afficher son adresse email, mais la protéger du spam

J.Ducastel — Thu, 08 Nov 2007 10:05:00 +0100

Comment donner son adresse de courriel à ses visiteurs, tout en la cachant aux yeux des moteurs cherchant des adresses à spammer ? Un usage courant est d'injecter des blocs parasites dans l'adresse, tels que identifiant[pas-de-spam-svp]@[enlevez-ceci]domaine.net. Ce qui n'est pas très lisible. Ma parade, c'est de masquer ces parasites avec une simple règle CSS. Ce qui donne :

HTML :
<a href="mailto:identifiant@[enlevez-ceci]domaine.net">
    identifiant@<span class="junk">[enlevez-ceci]</span>domaine.net
</a>

CSS :
.junk {
    display: none;
}

Et affichera : identifiant@domaine.net. Il faudra toujours supprimer à la main les blocs parasites en cas de clic sur le lien ou de copier-coller, mais l'adresse sera plus facile à noter :)

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 ?

Adultère programmé

J.Ducastel — Thu, 23 Nov 2006 10:10:00 +0100

C'était une histoire d'amour qui durait depuis 6 ans. Très vite séduit par sa souplesse, sa fiabilité (il faut dire que mon ex etait plutot du genre capricieuse) et l'étendue de ses capacités, j'avais vite changé de crèmerie... Il faut dire aussi que j'etais passé à autre chose, je voulais jouer dans la cour des grands et conquérir le monde qui s'offrait à moi.

Mais voilà, à force on finit par se lasser, et puis on finit par se rendre compte que tout n'est pas aussi rose qu'on le croyait. Et puis on a de nouvelles exigences, on en veut toujours plus...

Depuis quelques temps déjà j'avais remarqué son coté sexy, voire carrément hot. Mais en ayant sous le capot avec ça, et plutot mature. Seulement nous ne bossions pas dans le même domaine. Mais maintenant...

...maintenant que Python se démocratise sur le web, qui est mon aire de jeu, j'ai décidé de m'offrir une petite aventure. Je vais y aller doucement et tester Django avant de coder mon propre moteur ;)

Il faut dire que j'en ai un peu marre d'avoir à coder mes propres classes de base, et ce dans un language qui est loin d'etre vraiment fait pour la programmation objet. Coder pour pour la plaisir, c'est gratifiant pour l'estime de soi et un bon exercice pour se perfectionner en programmation. A vrai dire, j'ai même été assez loin puisque j'ai commencé à développer mon propre moteur d'applications web en PHP. Ce qui prend pas mal de temps et d'energie. D'autant qu'avec les limitations de PHP, je ne suis jamais vraiment content du résultat.

Mais j'ai aussi des projets d'application web (comme quizzgeek), et c'est surtout cela qu' j'ai envie de faire avancer en ce moment. Alors j'ai décidé d'essayer de les implémenter en python, en utilisant un framework existant, histoire de me faire la main.

Je vais perdre pas mal de temps au début, mais je pense que l'investissement peut en valoir le coup. C'est assez excitant (pour un geek), ça me rappelle quand j'étais passé d'actionscript (le language de script de Flash) à PHP. Et c'est le moment ou jamais. Après un démarrage foireux (plantages à répétititon de l'hébergement au moment du mini-buzz), quizzgeek s'est rendormi. Et mes autres projets n'ont de concret que le nom de domaine listé dans mon admin gandi ;).

P.S. Pour ceux que ça intéresse, j'ai commencé par développer une implémentation en PHP du moteur de templates de django. Elle est en pièce jointe à ce billet. Je ferai peut être un billet dessus prochainement.

PHP : classe datapath

J.Ducastel — Wed, 25 Oct 2006 15:58:00 +0200

Cette classe permet d'accéder à une variable multidimensionnelle (tableaux et objets) via une syntaxe d'adressage. Le but etant de pouvoir manipuler dynamiquement de tels objets.

Toutes les methodes de cette classe sont à usage statique, et travaillent directement sur une référence de la variable à manipuler.


$data=array(
  'membres'=>array(
    array('nom'=>'dupont','prenom'=>'michel')
    , array('nom'=>'martin','prenom'=>'roselyne')));

// ceci va afficher roselyne
echo datapath::get($data,'membres.1.prenom');

// ceci ajoute un element
$membre=array('nom'=>'dupuis','prenom'=>'pascal');
datapath::set($data,$membre,'membres.2');

Méthodes publiques

string separator([string $new]) : retourne le separateur actuel de segments de chemin (. par defaut
mixed get(mixed &$data, string $path) : retourne l'element pointé par le chemin $path.
bool set(mixed &$data, mixed $value, string $path) : definit la valeur de l'element pointé par le chemin $path au sein de la variable $data.
bool setRef(mixed &$data, mixed $ref, string $path) : definit par référence la valeur de l'élément pointé par le chemin $path au sein de la variable $data.

Quelques methodes supplémentaires sont prévues, notamment en ce qui concerne l'itération, l'application de fonctions, tri, test etc.

Est également prévu une extension de la syntaxe, avec l'ajout de jokers et/ou de selecteurs de valeur à la xpath.

Edit 28/11/2007 : Télécharger le kit de la classe (voir le billet Webappkit)

hello world

J.Ducastel — Fri, 20 Oct 2006 15:27:00 +0000

Me voilà qui multiplie les blogs tel jesus les pains, à moins que ce ne soit les poissons. Enfin bref. Bienvenue sur ce blog à vocation professionnelle, où je traiterai bien évidemment de mon domaine qui est le développement web. Mes bacs à sable se nomment PHP, MySQL, XHTML, CSS, et bien d'autres noms barbares pour la plupart des gens. Pas pour vous j'imagine, ou alors c'est que vous êtes perdu(e).

Je suis l'auteur du noyau générique webAppKit, et du quizz en ligne collaboratif quizzGeek. Chacun de ces deux projets a déjà son propre blog (webappkit, quizzgeek , merci Gandi !), donc je parlerai surtout ici de choses plus générales, dont quelques librairies génériques sur lesquelles ils s'appuient; et que j'ai également la plupart du temps commises. Un sous-domaine dédié sera probablement prochainement mis en place.

Tout ça permettra de ne pas mystifier les quelques visiteurs de mon blog personnel lorsque de temps à autre je me fends d'un billet technique. Du coup, les billets en question ont été importé ici. Bonne lecture si vous les découvrez.

Intelligence artificielle, internet et assistant personnel

J.Ducastel — Wed, 26 Jul 2006 20:10:00 +0200

Suite à une discussion sur Jabber avec Fastclemmy où celui-ci me parle de son idée de bot jabber comme interface avec un compte de stockage de signets sur blogmarks...

Beaucoup de services web existent déjà pour le stockage et l'organisation de votre vie numérique : webmails, signets collaboratifs, agendas, calendriers, to-do lists, lecteurs de flux, etc. Les plus geeks d'entre nous ont ainsi une multiplicité de comptes et d'interfaces web à consulter. Et d'ailleurs, les moins geeks d'entre nous n'ont probablement tout simplement pas idée de tous ces outils et pas l'envie, le courage ou le besoin d'apprendre à maitriser toutes ces interfaces. Cependant, la plupart des ces services (je veux dire, ceux qui ne sont pas has been avant d'avoir été) proposent des API permettant un accès automatisé.

J'ai alors entraperçu dans ma boule de cristal ce qui pourrait être monnaie courante d'ici, mettons, une décennie, et ce pour le commun des mortels :

Un bot, c'est à dire un programme d'intelligence articielle, accèdera pour vous à toutes ces interfaces, suite à des demandes effectuées en language naturel via un protocole de messagerie instantanée (standard bien sur, c'est à dire jabber). Cet assistant personnel aura accès via le web à tous vos contenus et services, et pourra chercher à votre place, reserver des billets, verifier votre disponibilité dans votre agenda, filtrer vos emails, vous avertir d'un contenu interessant dans vos flux de syndication, d'une attaque de spam sur votre blog. La difficulté ici réside bien entendu dans la partie intelligence artificielle, c'est à dire dans la traduction entre language naturel et instructions executées. On peut imaginer un systeme d'apprentissage, d'autant que chaque utilisateur aura sa propre manière d'exprimer ses requetes.

Question implémentation, l'IA pourrait résider sur un serveur et être accédée via un client jabber standard, ou résider sur un programme client (c'est à dire au sein de l'ordinateur/PDA/téléphone et accéder soit directement aux services, soit via jabber à un simple pont de ceentralisation d'accès aux services. On pensera bien sûr à coupler l'interface de dialogue à un système de reconnaissance et de synthèse vocale, afin de dialoguer avec son assistant comme avec un... secrétaire particulier.

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...

Ciao Firefox

J.Ducastel — Sat, 19 Nov 2005 15:58:00 +0100

Attention, demi-troll ! Non, je n'ai pas désinstallé firefox, contrairement à Suzie. Et je n'ai pas l'intention de le faire, du moins dans l'immédiat. Et je continuerai vraisemblablement à l'utiliser quotidiennement.

Mais je ne poste pas ce billet sous firefox. Pourquoi ? Parce que je suis sous Ubuntu, et que firefox y rame sévèrement. Sur certains sites, le défilement des pages devient franchement escargotesque. Je suppose que le ralentissement est dû à l'implémentation linux de la couche d'abstraction multi-plate-formes, puisque je ne rencontre pas le problème sous windoze, à configuration équivalente. J'ai donc voulu tester un navigateur plus intégré au bureau (un peu comme explorer pour windoze). Il s'agit d'epiphany, un fork de galeon, le navigateur initial de gnome.

Après quelques heures d'essai, je suis plutôt convaincu. Plus de problèmes de ralentissement, un peu moins de consommation mémoire, bien que le moteur de rendu soit le même, gecko. La plupart des fonctionnalités de base de firefox sont là : onglets (mobiles, comme prévu pour firefox 1.5), gestionnaire de téléchargement, personnalisation de l'interface, barre de recherche etc. Il inclut également un système d'extensions, bien qu'encore peu fourni. On n'y trouve hélas pas web developper, mais quelques outils pour la validation du code html et le déboguage javascript sont disponibles. Pas de gestion des fils (flux) de syndication par contre, qui passe par un agrégateur externe, liferea.

Mais outre les meilleures performances, le motif de mon adoption est sa gestion des signets, qui est à peu de choses près (l'interfaçage avec blogmarks par exemple) celle dont je rêve pour firefox : par hiérarchie plate, c'est à dire par mots-clefs (ou tags, traduits par sujets dans l'interface. ctrl+D pour un nouveau signet, on coche un ou plusieurs mots clefs ou on en saisit un nouveau, et le signet est indexé. Il est alors disponible via chacun de ses mots-clefs dans le menu signet, via ceux de ses mots clefs qu'on aura mis dans la barre personnelle, ainsi que par une liste déroulante lors de la saisie du début d'un mot clef dans la barre d'adresse. Beaucoup plus efficace que la gestion par dossiers, de mon point de vue, et de quoi séduire quelques surfeurs sous gnome.

Bye Bye Suzie

J.Ducastel — Sun, 16 Oct 2005 16:00:00 +0200

Surfant sur la vague blogosphérique (Standblog, Ploum, Mitternacht, Dying Culture etc), j'ai changé de distribution linux pour Ubuntu (5.10, Breezy Badger).

J'avais déjà testé cette distrib lors de mon précédent changement mais je l'avais laissée de coté pour des problèmes de reconnaissance matériels, et un ami m'avait chaudement recommandé la fiabilité teutonne. C'est ainsi qu'après avoir installé périodiquement des Red Hat puis des Mandrake je m'étais tourné vers la SuSE. Je ne pouvais plus me servir de la distribution française car elle était devenu incapable d'installer correctement lilo sur mon MBR, rendant de fait la cohabitation impossible avec l'OS de Redmond.

Sur le point d'installer openSuse 10.0, j'ai d'abord testé le live-cd de Breezy Badger (vraiment bien fait : si vous insérez la galette sous windoze un menu vous propose même d'y installer quelques logiciels libres dont firefox), et les progrès réalisés ainsi que quelques déceptions accumulées m'ont décidé pour un nouveau changement, et je ne le regrette pas. Voici un bref comparatif des deux distributions, après une petite semaine d'utilisation coté ubuntu et environ un an (?) coté Suse.

Installation

Sur ce point, Suse mène encore haut la main. Son installeur est de loin le meilleur de ceux que j'ai pu tester, meilleur que ceux de Red Hat et Mandriva (le nouveau nom de la Mandrake). Entièrement graphique comme ceux de ces rivales, mais au lieu de procéder par étape (un tunnel de clics sur continuer), la configuration suggérée est calculée en un seul écran offrant alors de modifier les points qui doivent l'être. Superbement efficace, que ce soit pour le débutant confiant ou le geek maniaque.

A coté la Ubuntu fait vraiment pâle figure. Je n'avais pas vu un installeur en mode texte pour linux depuis bien longtemps. Fort heureusement, il y a beaucoup d'étapes qui sautent grâce à la configuration automatique du matériel, mais il reste l'ecueil du partitionnement avec un outil texte (partman) franchement pas intuitif pour qui n'est pas à l'aise avec ça, et même alors (il faut préciser explicitement que / est amorçable, pour les autres outils ça va de soi...). Qui plus est, ma première tentative d'installation a planté en cours de route et j'ai du recommencer. Et c'est plutot long, a tel point que je me suis demandé si les paquets n'étaient pas compilés à l'installation... Pour couronner le tout, j'ai du ré-associer en ligne de commande (chown) les dossiers de /home avec les utilisateurs existants, chose que Suse me proposait et réglait dès l'installation et la création des utilisateurs.

Au final, je doute que la Ubuntu soit installable par un utilisateur débutant qui n'aurait pas un geek sous la main pour le faire à sa place. Il y a des efforts à faire sur ce terrain dans la prochaine version pour espérer contrer Vista.

Performances

La Suse m'exaspérait par la lenteur de son démarrage, plusieurs minutes sur mon système (probablement un problème de configuration, mais la lenteur du demarrage de Suse est un fait avéré). Ubuntu est bien plus rapide, peut être un peu plus lente que windoze XP mais c'est comparable. Il semblerait que la Suse 10 soit plsu rapide que les précédentes, mais je ne l'ai pas testée.

Par contre, j'ai l'impression que Ubuntu sous gnome rame plus vite que Suse sous KDE, peut être est-ce dû à beagle ou mon usage intensif de firefox mais avec une paire de sessions ouvertes et 3-4 programmes ouverts sous chacune d'elles on commence à percevoir les délais de réaction (Celeron 2.2ghz, 512Mo ram).

Question stabilité, j'ai pu voir la Suse planter sévèrement plusieurs fois sans explication mais je manque encore de recul pour affirmer que la Ubuntu est exempte de ce défaut. Par contre, attention en ce qui concerne l'installation de packages multiverse, susceptibles de foutre un tel bordel qu'il sera parfois plus simple de tout réinstaller (à moins de savoir réparer les dégats en ligne de commande).

Usage

Autant le dire tout de suite, c'est là que Ubuntu se démarque. Si un outil de configuration central à la Yast ou DrakConf (tiens, comment l'ont ils renommé celui-là ?) fait bizarrement défaut, multipliant les entrés dans le menu des paramètres système, pour le reste je suis très agréablement surpris.

Ubuntu n'est pas exempte de petits défauts, et nécessite encore quelques incursions dans la ligne de commande, mais il est possible d'obtenir rapidement un système fonctionnel, y compris pour le multimedia. Ce n'est pas encore utilisable par tous, mais pour les geeks ou au contraire les utilisateurs cherchant un systeme fiable pour un usage web/bureautique, c'est tout à fait jouable.

Some CSS-related javascript utility functions

J.Ducastel — Fri, 16 Sep 2005 20:04:00 +0200

Hi folks. Nothing very bright or revolutionary, but here is a tiny library to play with CSS and javascript. More elaborate tricks to come. Hope it helps.

bool hasClass(DOM obj, string cName)
bool hasClasses(DOM obj, array classes)
bool addClass(DOM obj, string cName)
bool removeClass(DOM obj, string cName)
bool swapClasses(DOM obj, string class1, string class2)
bool switchClass(DOM obj, string to, string from)
array getElementsByClassName(string className, [DOM container],[string tag])

/* CSS-related javascript functions by Fred Bird http://fredbird.org
License : Public Domain file version 16/09/2005 09:30:45 */ /* has the DOM
object a certain class ? obj = DOM object, cName = a class name */ function
hasClass(obj,cName) { return new RegExp('\\b'+cName+'\\b').test(obj.className);
} /* has the DOM object a set of classes ? obj = DOM object, classes=array of
class names */ function hasClasses(obj,classes) { for (f=0;
f<classes.length; f++) { if (!hasClass(obj,classes[i])) return false; }
return true; } /* add a class to a DOM object if necessary obj = DOM object,
cName = a class name */ function addClass(obj,cName) { if
(!hasClass(obj,cName)) { obj.className+=obj.className?' '+cName:cName; } return
true; } /* removes a class from a DOM object obj = DOM object, cName = a class
name */ function removeClass(obj,cName) { if (!hasClass(obj,cName)) return
false; var rep=obj.className.match(' '+cName)?' '+cName:cName;
obj.className=obj.className.replace(rep,''); return true; } /* swap two classes
for a DOM object, whatever provided order */ function
swapClasses(obj,class1,class2) { if (hasClass(obj,class1)) {
removeClass(obj,class1); addClass(obj,class2); return true; } if
(hasClass(obj,class2)) { removeClass(obj,class2); addClass(obj,class1); return
true; } return false; } /* sets class 'to' to the DOM object obj, removes class
'from' if necessary */ function switchClass(obj,to,from) { if
(hasClass(obj,from)) removeClass(obj,from); addClass(obj,to); return true; } /*
returns an array of DOM objects having the provided class name within object
'container' and with tag name 'tag' some code from
http://www.webmasterworld.com/forum91/1757.htm (unbugged) */ function
getElementsByClassName(className,container,tag) { // default container to
document container=container||document; // default tag to * tag=tag||'*'; //
listing container descendants var all =
container.all||container.getElementsByTagName(tag); var found=new Array(); //
searching for targets for (f=0; f<all.length; f++) { var el=all[f]; if
(hasClass(all[f],className)) { found.push(all[f]); } } return found; }