Hooba Studios » Théorie

Hooba fait dans les bonnes oeuvres

Antoine Leclair — Wed, 18 Nov 2009 02:53:41 +0000

Je me suis fait demander récemment de commanditer un concours de vidéo qui est organisé par les bibliothèques de Lévis. Comme la demande venait d’une personne proche et qu’ils avaient besoin d’un site web, j’ai donc mis la main à la pâte.

Le concours s’appelle À l’affiche dans une bibliothèque près de chez vous. Les jeunes doivent faire un vidéo « bande-annonce » d’un livre parmi les livres sélectionnés.

Comme c’était du bénévolat et que les visiteurs allaient être des jeunes (donc plus enclins à utiliser un navigateur récent), je me suis permis d’expérimenter un peu avec le CSS3.

Box Shadow

Si vous avez un navigateur récent qui n’est pas Internet Explorer, vous pouvez voir qu’il y a un une ombre autour du contenu principal. Il s’agit de la propriété CSS box-shadow. Elle n’est actuellement implémenté que dans Webkit (Safara, Chrome) et Firefox 3.5+. Comme le CSS3 n’est pas encore ratifié, il faut ajouter l’extension des navigateurs à l’avant de la règle. C’est à dire -moz pour Firefox et -webkit pour Webkit. Par exemple, sur le site du concours, voici la règle que j’ai utilisée:

-moz-box-shadow:0 0 20px 3px black;
-webkit-box-shadow:0 0 20px 2px black;
box-shadow:0 0 20px 2px black;

La version sans préfixe sert pour le jour où cette règle CSS deviendra standard. En gros, j’ai utilisé cinq paramètres:

Offset horizontal, au cas où on voudrait décaller.
Offset vertical, même chose.
Flou (blur), détermine l’intensité du flou, un peu comme dans Photoshop.
Étendue (spread), sans avoir trop expérimenté, ça ressemble un peu à padding, mais appliqué à l’ombre. Peut être négatif si on veut la rapetisser.
Couleur. Je crois que la spécification permettra aussi d’utiliser rgba (avec de la transparence).

IE6 n’est pas mort

Après avoir fait le site web, comme tout bon intégrateur, j’ai fait le tour dans tous les navigateurs majeurs (IE6/7/8, Chrome, Firefox, Safari, Opera) afin d’y arranger les petits problèmes. Comme à l’habitude, IE6 est toujours un peu plus tannant, alors dans la même perspective qui m’avait poussé à expérimenter avec CSS3, j’ai décidé de rendre le site regardable dans ce navigateur, sans faire pieds et main pour le rendre pixel perfect. À ma grande surprise, lors des premiers jours après la mise en ligne, Google Analytics me disait qu’environ 90% du trafic était fait avec IE6! J’ai donc compris que les TI de la ville de Lévis n’avaient pas encore pris la peine de mettre à jour les navigateurs de certains employés! Par chance, après la vague de curieux à l’interne, la tendance est plutôt redevenue normale (c’est à dire, je n’ai pas revu d’IE6 depuis).

CSS3 va rocker

Dans ce projet, je n’ai utilisé qu’une seule règle de CSS3. Elle ajoute un petit quelque chose au site, sans pour autant avoir un effet dévastateur lorsqu’elle n’est pas rendue par le navigateur.

Il y a plusieurs autres règles qui, en réduisant l’utilisation d’images, vont vraiment accélérer l’intégration web et réduire la taille des pages.

Les navigateurs utilisés sont de plus en plus à jour: IE6 disparait et IE7 disparait encore plus vite maintenant qu’IE8 est sorti! On pourra donc très bientôt utiliser les derniers ajouts au fur et à mesure qu’ils arrivent.

Bon code, Bad code

Antoine Leclair — Fri, 17 Jul 2009 03:19:15 +0000

Il n’y a pas si longtemps, j’ai eu à intégrer du code PHP qu’un autre programmeur avait déjà fait pour un autre site. Le client tenait à ce que j’utilise son « module » de nouvelles en pensant sauver de l’argent. La première fois que j’ai eu à intégrer ledit module, ç’a effectivement été plutôt rapide étant donné que le site était fait dans le même pattern que le site d’origine. Par contre, la deuxième fois, c’était une toute autre chose!

Du code non-réutilisable

J’espère ne rendre personne triste en publiant cet article, mais je vais vous faire un petit copier-coller d’une fonction pour illustrer mes points.

=".$date_start." AND date_news<".$date_end;
        }
    }
    if(!isset($query)){
        $query = " ORDER BY date_news DESC LIMIT 3";
    }else{
        $query .= " ORDER BY date_news DESC";
    }

    $query = "SELECT * FROM juris_news".$query;
    $result = mysql_query($query) or die(mysql_error());
    if(mysql_num_rows($result) > 0){
        for($i = 1; $row = mysql_fetch_array($result); $i++){
?>
    ">
    
    
    " id="news" />
Aucune actualité trouvée.");
    }
}

Il s’agit ici de la première fonction d’une dizaine de fonctions similaires qui constituent le fichier.

Premier péché: mélanger la logique avec la présentation

La principale force de PHP est aussi sa principale faiblesse: il est très facile de mélanger du PHP avec du HTML. On peut avoir une page entière en HTML et y insérer très facilement un peu de PHP. On peut par contre aussi avoir du PHP et y insérer du HTML. Le problème avec cette fonction, c’est qu’elle génère (et affiche) du HTML.

On peut voir très facilement que le code HTML affiché n’est pas réutilisable. Il y a des appels à des fonctions JavaScript et des images dont le chemin d’accès est hard coded. Par exemple, la fonction affiche:

// mauvais
" id="news" />

Il est fort peu probablement que j’aie à utiliser les mêmes fonctions JavaScript et que j’utilise les mêmes images. Aussi, le markup HTML généré ne conviendra générallement pas aux besoins d’un autre site. Par exemple, je doute que

puissent être réutilisé.

La meilleur façon aurait été de simplement arrêter la fonction à la fin de la requête SQL. La fonction aurait simplement pu retourner un array, un objet ou un itérateur. De cette manière, on sépare la logique de la présentation. Par exemple, si la fonction retournait un array $nouvelles, on pourrait l’intégrer dans la page directement.




    Nouvelles
    
    
    
    
    En savoir plus
    
    
    Aucune nouvelle

Deuxième péché: La fonction n’accepte aucun paramètre

De la façon dont la fonction est codée, on n’a aucun moyen externe (lire: aucun paramètre) d’affecter son déroulement. Si $_GET['search'] contient quelque chose, une recherche sera faite, sinon, les trois dernières nouvelles sont affichées.

Il serait bien de pouvoir appeler la fonction en lui demandant un certain nombre de nouvelles. Je ne veux pas avoir toujours les trois dernières nouvelles dans tous les sites que je dois faire.

Aussi, si je veux faire une recherche, je ne veux pas nécessairement utiliser $_GET['search'] comme chaine à chercher.

Le prototype de cette fonction aurait plutôt dû ressembler à ceci:

function fct_display_news_list($quantity = 3, $search = NULL)

De cette manière, on aurait pu avoir des comportements par défaut si on ne passe aucun argument tout en ayant un certain contrôle en cas de besoin. Si je voulais à ce moment utiliser la fonction en utilisant la valeur de $_GET['search'] comme clé de recherche, j’aurais pu l’appeler ainsi:

fct_display_news(3, $_GET['search'])

Troisième péché: la fonction fait trop de choses

La fonction « raboute » des morceaux de requêtes SQL en créant la fin de la requête ("WHERE ...") en premier. Je trouve étrange d’avoir commencé par la fin sans raison apparente. Ça ne fait que complexifier le code.

En plus, pourquoi ne pas avoir simplement séparé la fonction en deux fonctions? Chaque fonction aurait été beaucoup plus claire et facile à maintenir. Exemple:

// mieux
function get_news($quantity = 3, $search = NULL){
    if ($search == NULL)
        return get_latest_news($quantity);
    else // $search != NULL
        return get_searched_news($quantity, $search);
}

function get_lastest_news($quantity = 3){
    // fonction qui retourne les $quantity dernières nouvelles
    // ...
}

function get_searched_news($quantity = 3, $search = NULL){
    // fonction qui retourne les $quantity dernières nouvelles trouvées selon la clé de recherche
    // ...
}

Si on regarde la liste des fonctions du fichier, on se rend vite compte qu’une approche orienté objet aurait très bien fait la job. Une classe News aurait grandement simplifié le tout.

Quatrième péché: des noms qui ne veulent rien dire

Si on retourne dans le code au début de l’article, on peut voir qu’il y a plusieurs noms encombrés d’abréviations superflues ou qui ne veulent rien dire aux yeux de la prochaine personne qui touche le code.

Est-ce que j’ai vraiment besoin de spécifier dans le nom d’une fonction qu’il s’agit d’une fonction en y préfixant fct? Aussi, un fichier nommé img_c_btn_savoir_up.gif: un fichier gif est une image, pas besoin de préfixer img à son nom. Dans le même nom de fichier, que veut dire le « c« ?

Une fonction devrait avoir un nom qui permet de savoir ce qu’elle fait tout en étant concis. display_news_list aurait été suffisant.

Cinquième péché: être vulnérable aux injections SQL

Étant donné que la fonction n’accepte aucun paramètre, le programmeur a utilisé la valeur de $_GET['search'] directement dans sa fonction. Le problème que je veux souligner ici c’est la manière dont il l’a utilisée. Il l’a mis directement dans une requête sans la filtrer:

// mauvais
$query = " WHERE title LIKE CONVERT(_utf8 '%".$_GET['search']."%' USING latin1) OR content LIKE CONVERT(_utf8 '%".$_GET['search']."%' USING latin1)";

En insérant directement des valeurs fournies par l’utilisateur (ici, dans la barre d’adresse) sans les avoir filtrés au préalable est une mauvaise pratique car elle ouvre très grand les portes aux attaques par injection SQL.

En conclusion

Quand on programme, c’est important de toujours penser à la réutilisabilité du code. Il faut bien sûr parfois faire du code « quick and dirty« , mais les choses importantes que je viens d’énumérer ne sont pas compliqués à respecter. D’ailleurs, le programmeur aurait en fait sauvé du temps s’il avait fait du code réutilisable, car il a eu à reprogrammer un autre ensemble complet de fonctions pour le côté administrateur. S’il avait dès le départ fait une nouvelle classe ou simplement mieux conçu ses fonctions, il aurait facilement pu sauver beaucoup de temps en réutilisant lui-même son propre code à l’intérieur du même projet.

Conception d’applications web avec l’architecture MVC

Antoine Leclair — Thu, 11 Dec 2008 20:48:46 +0000

Un billet rapide aujourd’hui pour illuminer certains qui ne connaitrait pas encore l’architecture MVC. C’est un pattern qui sépare la logique de la présentation. MVC est un acronyme pour Model-View-Controller.

En quelques mots, le modèle gère la base de donnée, le contrôleur fait le lien entre le modèle et la vue, et la vue est ce que l’utilisateur voit. Chacun de ces composants, dans le code, est générallement une classe.

Vue

C’est ce que l’utilisateur voit. Dans le cas d’une application web, c’est, en gros, le code HTML. C’est le contrôleur qui décide de ce que va être la vue. Lorsque l’utilisateur clique sur un lien, c’est le contrôleur qui reçoit le clic, pas la vue. La vue ne fait qu’être ce que l’utilisateur voit.

Contrôleur

C’est ce qui fait le lien entre le modèle et la vue. L’utilisateur fait un clic, le contrôleur reçoit le clic et décide de ce qu’il en fera. Il communique avec le modèle pour traiter l’information reçue et/ou pour aller en chercher. Il décidera ensuite de la vue qui sera présentée à l’utilisateur.

Modèle

C’est ce qui contient tout le business logic. Il sert de lien avec la base de donnée. C’est générallement à cet endroit que va se faire la « grosse job »: rêquetes aux bases de données, validations, arranger les données d’une manière correct (en objets ou array ou autre) pour remettre au contrôleur.

Concrètement sur internet

Un utilisateur se fait présenter un formulaire pour entrer ses coordonnées lors de l’achat d’un produit (c’est la vue). Il entre ses informations et envoie le formulaire (reçu par le contrôleur). Le contrôleur demande au modèle d’inscrire l’achat dans la base de donnée. Le modèle fait une validation des champs et se rend compte que le numéro de carte de crédit ne contient pas assez de chiffres. Il retourne l’erreur au contrôleur. Le contrôleur présente le formulaire (la vue) avec les erreurs pour qu’elles soient corrigées. L’utilisateur renvoie le formulaire corrigé. Le contrôleur renvoie les informations au modèle pour inscrire dans la base de donnée. Le modèle effectue la validation avec succès et ajoute l’achat à la base de donnée. Il informe le contrôleur que tout est déroulé avec succès. Le contrôleur affiche le message de succès (la vue) à l’utilisateur.

Avantages

L’avantage principal de travailler avec l’architecture MVC, c’est qu’il permet de très bien séparer la logique de la présentation. La vue n’aura aucune logique d’imbriquée, ce qui facilitera le travail d’équipe. Aussi, étant donné que tout est très bien séparé, il est très facile d’ajouter et de modifier au code sans que le reste ne s’effondre. C’est un pattern qui se prête très bien au développement agile.

Inconvénients

Le fait de travailler avec un pattern dans un très petit projet peut alourdir inutilement la tâche. Lorsque seulement quelques lignes de codes auraient suffi, utiliser un pattern comme MVC est générallement inadapté. Aussi, on doit s’assurer que toutes les personnes qui travailleront sur le projet sont familières avec le pattern MVC, même si ce n’est pas très long à comprendre.

En résumé

La raison pour laquelle je vous parlais de ça, c’est que mon engoûment pour le MVC est revenu tout récemment. Il y a quelque temps, j’avais fait une petite visite de Ruby on Rails, qui utilise (extrêmement bien à mon avis) le MVC. Par contre, même pour les petites applications, Ruby on Rails consomme beaucoup de mémoire vive et demande des connaissances pour le déploiement qui peuvent compliquer les choses avec certains clients. Ces compétences, par exemple, ne sont pas nécessaires pour déployer une application en PHP. C’est la raison qui m’a fait mettre Rails de côté pour quelque temps.

Par contre, tout récemment, en fouillant un peu pour trouver le CMS parfait (que je n’ai toujours pas trouvé), je suis tombé sur CodeIgniter. C’est un framework MVC en PHP, très rapide, qui ne demande pas beaucoup de ressources et qui est très simple à utiliser. Son défaut, à mon avis, est qu’il est écrit en PHP4. En lisant un peu sur le net par rapport à CodeIgniter, j’ai découvert qu’il y avait un fork qui s’appelle Kohana qui est codé en PHP5. De ce que j’en vois à date, c’est extrêmement bien et je vous conseille le coup d’oeil!

Conception en amélioration progressive

Antoine Leclair — Wed, 03 Dec 2008 16:31:09 +0000

Il n’y a pas si longtemps, je vous parlais de jQuery, une librairie JavaScript qui permet de faire des miracles avec peu de code. Par contre, en regardant sous la jupe des sites web qui utilisent du JavaScript (avec ou sans librairie), je me rends souvent compte que les concepteurs ont oublié une chose très importante: ce n’est pas tous les utilisateurs qui ont JavaScript actif dans leur navigateur.

De nos jours, il est plutôt rare de voir quelqu’un qui, sur son ordinateur, n’a pas un navigateur qui est capable de rendre le JavaScript. En fait, pour utiliser les principales librairies, on peut se fier sur des navigateurs assez vieux, comme Internet Explorer 6 qui date de 2001.

Autrefois (on recule d’un ou deux ans), on se faisait toujours sortir les mêmes histoires par rapport à JavaScript. « On ne peut pas être sur que l’utilisateur a un navigateur assez récent » et « l’utilisateur est peut-être parano et a peut-être désactivé JavaScript dans son navigateur » (il ne faut pas oublier qu’on se faisait innonder de pop-ups il n’y a pas si longtemps).

Bien qu’à mon avis ces histoires ne sont plus tellement valides, il y a une nouvelle réalité qui nous explose au visage: on peut désormais naviger sur internet à partir de plein de gadgets. De la console de jeux vidéos, au téléphone cellulaire low-budget, en passant par le décodeur numérique du téléviseur. Je ne m’avancerai pas plus, mais nous n’en somme qu’au début des « gadgets connectés ».

Toutes ces plateformes n’offrent pas les mêmes capacités. C’est pourquoi, je voulais faire un petit rappel aux développeur qui vivent dans le passé:

Faites la conception de vos sites internet en amélioration progressive (progressive enhancement)

Voici la manière dont je vois la conception web. Il faut d’abord coder de manière sémantique notre XHTML. Aucune trace de présentation dans le code à date! Parce qu’encore une fois, on ne sait pas avec quoi l’utilisateur regardera le site. Peut-être qu’il le lira avec un lecteur d’écran (pour les handicapés visuels). Ensuite, on peut ajouter du CSS, pour faire la présentation. Lorsque c’est codé, on peut modifier notre page pour l’intégrer avec le code côté-serveur. Lorsqu’on a un site fonctionnel de cette manière, on peut se permettre d’ajouter du JavaScript et de jouer avec le AJAX.

Voici le genre de truc qui me surprend toujours par son manque d’utilisabilité:

Un bouton submit actionné UNIQUEMENT par JavaScript (sans JavaScript, impossible d’envoyer le formulaire).
Une galerie d’images qui utilise JavaScript pour faire la présentation, sans avoir fait au paravant une galerie fonctionnelle (ou même présentable) sans JavaScript.
Une page qui affiche perpétuellement « chargement… » JavaScript est désactivé.
Un site web entier qui se fie sur JavaScript pour fonctionner.
Des liens du genre , qui ne fonctionnent pas sans JavaScript.

Je dis tout ça pour JavaScript, mais je pourrais égallement le dire pour Flash! On a encore moins de chances d’avoir Flash qui fonctionne dans les gadgets d’aujourd’hui que d’avoir JavaScript. Par exemple, le iPhone n’accepte pas encore Flash, même s’il se débrouille plutôt bien avec JavaScript. Même chose pour Opera Mobile. Avec Internet Explorer pour Windows Mobile, pour l’instant, oubliez même JavaScript! J’ai entendu dire que Microsoft travaillait sur un nouveau navigateur pour leur plateforme mobile, alors ils devraient eux aussi pouvoir accepter JavaScript sous peu.