vendredi 25 septembre 2009

Quick reference cards & cheat sheets

Bien souvent, quand on développe ou qu'on administre un système, le plus important n'est pas de savoir, mais de savoir où chercher.

Et quand on devient un peu expérimente dans un domaine, il n'est pas utile d'avoir accès à une documentation pléthorique, mais juste à un certains nombre de recettes les plus récurrentes.

C'est pour cela que les quick reference cards & les cheat sheets sont intéressants, puisqu'ils résument un sujet à un pense-bête d'une page ou deux (rarement plus).

2 ressources qui listent ce genre de documentation sur le web :
- http://www.digilife.be/quickreferences/quickrefs.htm
- http://www.cheat-sheets.org/

La granularité optimale de l'information est dépendante du contexte. Il y a un temps pour lire un livre de 1000 pages sur le Java, et un temps où il faut avancer et il est préférable dans ce cas de n'avoir qu'une référence sur le Java de 2 pages.

lundi 4 mai 2009

HTML begins : templates & validation

A chaque nouveau démarrage d'un projet Web, se pose la question d'utiliser une forme standard du HTM. Le copier-coller étant à la base de l'informatique, voici une référence de 2 templates, l'un avec la syntaxe avec des CSS et JS déportés, l'autre avec ces mêmes CSS & JS en local.

1ère version (avec style et script déportés)

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr" lang="fr">
<head>
<title></title>
<link href="nn4.css" rel="stylesheet" type="text/css" />
<script src="script.js" type="text/javascript"></script>
</head>

<body>
<h1>Coucou</h1>

</body>

</html>

Exemple 2 (avec style et script dans la page) :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr" lang="fr">
<head>
<title></title>
<style type="text/css">
<!-- mettre css ici -->
</style>
<script type="text/javascript">
<!-- mettre js ici -->
</script>
</head>


</head>

<body>
<h1>Coucou</h1>

</body>

</html>


Pour valider son HTML : http://validator.w3.org/check

L'image à afficher pour démontrer son passage de validation.

<p>
<a href="http://validator.w3.org/check?uri=referer"><img
src="http://www.w3.org/Icons/valid-xhtml10-blue"
alt="Valid XHTML 1.0 Strict" height="31" width="88" /></a>
</p>


Pour valider son CSS : http://jigsaw.w3.org/css-validator/


L'image à afficher pour démontrer son passage de validation.

<p>
<a href="http://jigsaw.w3.org/css-validator/check/referer">
<img style="border: 0pt none ; width: 88px; height: 31px;" src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="CSS Valide !" />
</a>
</p>

Edit : un module de Alsacreation génère ce prologue très bien. Le seul truc manquant, c'est la ligne XML donnant l'encodage utilisé pour le reste du document.

lundi 30 mars 2009

Le facteur clé d'un bon framework

Lu sur LE Lexpage :

Rasmus lerdorf dit que pour lui, chaque société / groupe devrait avoir son propre framework


Le problème avec les frameworks, c'est que l'on cherche la balle d'argent, le framework ultime. C'est une recherche de perfection qui n'a pas de fin et qui ne pourra jamais être totalement satisfaite. Il y aura toujours un cas à la marge qui ne fonctionnera pas. Et au bout d'un moment, les gens ont envie de changer, c'est humain. C'est pas un hasard qu'on parle de nouvelles technologies. Qu'on passe de client-lourd à client léger, et que ça oscille depuis la nuit des temps (de l'informatique).

Donc comme aucun framework n'est appelé à durer, les seuls bons sont ceux qui se rendent le moins indispensable. Quand Spring parle d'injection de dépendance, et que leur philosophie est de créer de simple POJO en Java, c'est positif. Ca fait que l'on peut utiliser Spring, mais que le chantier pour éventuellement passer de Spring à autre chose n'est pas si compliqué ni coûteux, car les POJO sont réutilisables sans rien faire.

De la même façon, j'avais été favorablement impressionné par iBatis (et pas par toutes les solutions d'ORM traditionelles style Hibernate). Parce que l'idée d'iBatis c'est d'utiliser le langage le plus connu, et le plus performant pour gérer une logique ensembliste : le SQL. Et iBatis se charge juste de charger/décharger les résultats des requêtes dans des beans Java. Là aussi, si iBatis vous ennuie au bout d'un moment, le chantier de réécriture n'est pas pharaonique.

Donc pour moi, le critère clé d'un bon framework c'est d'arriver à s'en passer assez rapidement (si le besoin s'en fait sentir).

Pour Django ou Rails, je les vois plus comme des outils-frameworks. C'est un peu l'équivalent de Ant+(Spring+Hibernate+...). La différence avec un framework pur, c'est qu'il y a un socle, une console, qui permet de lancer des commandes (comme Ant). L'intérêt de ces outils, c'est le protoypage rapide d'application. Tout est fait pour aller vite. Mais il faut bien connaitre bien sûr.

Mais ce que j'aime dans Django, (même s'il n'a pas le critère clé du bon framework), c'est sa philosophie très cohérente dans les templates, l'ORM, la gestion des URL.

Et faire une pile aussi cohérente en Java demanderait un gros boulot...