Développement

Entries feed - Comments feed

Monday, 21 March 2011

Fightly Game Engine : un moteur de jeux web libre

By Adrian on Monday, 21 March 2011, 10:00

Amis lecteurs, bonjour ! 

J'en avais parlé il y a quelques temps (plus de 6 mois maintenant), j'ai travaillé ces derniers temps sur un projet nommé Fightly. Comme ce projet a subit pas mal de changements, commençons par un peu d'histoire pour que les choses soient claires... 

blog-fightly.png

La vie d'un projet

Tout commence il y a environ un an, Gandi offre des noms de domaine gratuits, et j'acquiers fightly.fr et fightly.com avec dans l'idée de faire un jeu de stratégie très simple. Je garde le concept dans un coin de mon cerveau, jusqu'à ce que je découvre les WebSockets : je code quelques essais simplistes de jeu de stratégie sur carte hexagonale, et je fais des tests de communication par WebSocket. Ça me botte bien, donc j'approfondis le concept du jeu, et je lance une première campagne de recrutement en juillet dernier, sur le Site du Zéro et bien d'autres sites spécialisés : [Jeu Web] Fightly. 

À ce moment, l'idée est de créer un jeu web de stratégie au tour par tour, au concept simpliste, avec pour ambition de faire un projet réalisable par une équipe amateur. On y travaille donc pendant les deux mois de vacances, puis vient la rentrée scolaire, et le rythme ralentit pendant quelques semaines. Et j'ai là une occasion sur laquelle je saute : faire passer ce projet dans le cadre d'un projet universitaire, et ainsi pouvoir travailler sur un projet que j'ai lancé et donc que j'affectionne, et être noté pour ça ! 

Avec l'aide de Pierre-Antoine Champin, enseignant-chercheur au LIRIS et avec qui j'avais déjà travaillé, qui accepte de jouer le rôle de "client", nous remanions le projet : l'objectif sera de créer un moteur de jeu web de stratégie au tour par tour, libre, exploitant des technologies récentes du Web Ouvert, et d'implémenter une démonstration simple de ce moteur. Je recrute 4 collègues de formation, et nous voilà partis ! 

Fightly Game Engine

Venons-en donc au projet en question, et reprenons-en les objectifs. Le coeur c'est de créer un moteur de jeu, donc un outil permettant de construire et de faire tourner un jeu vidéo. En réalité, le terme "moteur de jeu" est peut être mal adapté. Ce serait plutôt un framework, puisque notre application fournira les briques de base pour créer un jeu. Il serait intéressant de débattre sur ces noms : est-ce qu'un moteur de jeu est une spécialisation de framework ? Quoi qu'il en soit, l'idée ne change pas : on fournit un ensemble de fonctionnalités de base, dont on sait qu'il constitue la base d'un certain type de jeu, et on facilite donc le développement de ce type d'application. 

La première subtilité ici est qu'on s'intéresse uniquement aux jeux Web : on n'est plus du tout dans le même cadre que les moteurs de jeu "classiques" (par exemple, le Unreal Engine, le Cry Engine ou le Gamebryo), la structure de base de l'application change totalement puisqu'il faut gérer avant tout une architecture client / serveur basée sur les protocoles du Web. On cherchera donc à fournir une application gérant les connexions de clients, l'envoi et la réception de données via le réseau, le tout étant réalisé avec un client qui s'exécute dans un navigateur. 

blog-wesnoth.jpg
Battle for Wesnoth

Deuxième point important, on se limite à un certain type de jeu bien particulier : les jeux de stratégie au tour par tour. Pensez Civilization, Dofus, Heroes of Might and Magic ou encore Battle for Wesnoth. Notre but est donc de faciliter la création de ce type de jeu dans un navigateur : gestion de parties, des tours, des joueurs, des unités, des combats entre unités, etc. Là où le Fightly Game Engine se différencie d'un moteur de jeu classique, c'est qu'il sera largement extensible. À la manière d'un framework comme jQuery, il sera possible d'ajouter des modules au moteur, pour en étendre les fonctionnalités. Nous avons l'ambition de fournir un outil avec lequel il ne sera pas nécessaire de savoir programmer pour créer un jeu : vous choisissez les modules nécessaires à votre jeu, vous les configurez pour qu'ils répondent à vos attentes, vous écrivez vos règles dans un format défini par le moteur et vous n'avez plus qu'à lancer votre serveur et à attendre vos premiers joueurs. 

Bien entendu, s'il sera possible de ne pas programmer, tout sera fait pour qu'un développeur puisse étendre ou modifier le comportement du moteur de manière simple. De même, on cherchera à faciliter grandement la création de modules, puisque c'est par eux que le moteur grandira et deviendra réellement intéressant pour les créateurs de jeux. 

Ce projet est libre, c'est-à-dire que vous pouvez, à tout moment, en lire les sources, les modifier, les redistribuer, selon les termes des licences. Notez cependant que le jeu n'est pas encore explicitement sous licence (il est donc encore soumis au droit d'auteur), mais qu'il sera très certainement distribué sous double licence MIT et GPL. 

Enfin, le Fightly Game Engine utilise des technologies émergentes du Web : les WebSockets pour une couche réseau solide et performante, Canvas côté client pour l'affichage, HTML5 et CSS3, du JavaScript côté serveur avec Node.js, et bien d'autres. Nous souhaitons profiter de toutes ces nouvelles possibilités techniques pour fournir un outil puissant et robuste, permettant la création de jeux de plus en plus poussés, qui profitent de l'énorme avantage du Web : ils marcheront sur toutes les plateformes disposant d'un navigateur récent. 

Où en sommes-nous ?

Le projet Fac est terminé, et si nous sommes loin d'avoir atteint tous nos objectifs, nous avons su créer quelque chose d'exploitable. Ce n'est pas encore un moteur à proprement parler, c'est plutôt une application configurable. Etant donnés nos délais et le peu de temps que nous pouvions consacrer au projet, nous avons du couper beaucoup de choses, et aller au plus rapide pour pouvoir avoir un résultat présentable. Nous avons donc une démo de jeu, très simple, dans laquelle les unités s'affichent sur une carte, et les joueurs peuvent les déplacer chacun à leur tour. Un bon début à mon avis, et une bonne base de code. 

Si vous souhaitez en savoir plus sur le travail que nous avons effectué durant le projet Fac, je vous invite à lire les documents que nous avons produit : le cahier des charges, la veille technologique et le dossier bilan. Ou un zip contenant les trois. 

Cependant, ce que nous avons réalisé est très loin d'être terminé. Nous n'avons pas résolu de nombreuses problématiques clés du projet : comment rendre le moteur générique et extensible, pour permettre d'ajouter ou de retirer des modules ? Comment gérer les dépendances entre ces modules ? Comment gérer les correspondances des modules côté client et côté serveur ? 

Il reste donc beaucoup à faire, il y a des défis très intéressants à relever, en terme d'architecture générique et extensible, en terme d'application orientée réseau, en terme de moteur de jeu, en terme de performances côté client, et bien d'autres choses encore. Voila pourquoi j'en viens au... 

Recrutement

Je pense qu'il est nécessaire de travailler à plusieurs sur ce projet, pour plusieurs raisons. D'abord parce que j'aime travailler en équipe. Ensuite parce que mes seules compétences ne me paraissent pas suffisantes : j'ai besoin de gens meilleurs que moi en architecture logicielle et en performances JavaScript, qui sont deux points clés de ce projet. Et enfin parce qu'on réfléchit bien mieux à plusieurs, surtout sur des problèmes complexes. 

Je recherche donc des coéquipiers pour travailler avec moi sur le Fightly Game Engine. Il y a trois axes majeurs pour le développement immédiat du projet, qui sont les suivants :

  • Architecture : Réflexion sur l'architecture du projet, mise en place de solutions adaptées à nos besoins de généricité et d'extensibilité. 
  • Communauté : Mise en place d'outils favorisant la création d'une communauté autour de notre logiciel libre. 
  • Développement : Refactoring du code sur des bases saines, mises en place de bonnes pratiques, correction des bugs existants, amélioration constante de la documentation, ajout de nouvelles fonctionnalités.

Je cherche en priorité des gens relativement compétents, avec une bonne expérience en JavaScript, en jeu vidéo ou en gestion de communauté libre. Bien entendu, le travail serait bénévole, le projet étant libre et n'ayant pas pour but de générer, de lui-même, des bénéfices commerciaux. 

Pourquoi participer à ce projet alors ? Pour l'intérêt des difficultés techniques à surmonter. Pour participer à un projet que vous estimez et que vous voulez voir aboutir. Pour avoir l'occasion de travailler sur une application dont les performances sont critiques. Pour approfondir vos connaissances en JavaScript, en jeu vidéo, en Web. Pour expérimenter le travail en équipe amateur (dans le sens, qui travaille sur son temps libre). Ou pour toute autre raison de votre choix ! 

Si vous êtes intéressé ou que vous avez des questions, n'hésitez pas à me contacter via les commentaires de ce billet, via ma page de contact ou directement par mail : adrian@gaudebert.fr

Thursday, 18 November 2010

Introduction au contexte du jeu vidéo par navigateur

By Adrian on Thursday, 18 November 2010, 10:00

Bonjour à tous !

Je vous avait parlé ici-même, il y a quelques temps, du projet Fightly : un jeu par navigateur de stratégie au tour par tour, dont le but est d'exploiter des technologies récentes du Web pour amener une expérience de jeu avancée dans un navigateur, le tout en utilisant des technologies de l'Open Web. Eh bien ce projet a quelque peu changé, puisqu'il s'est coupé en deux parties : la création du jeu en lui-même est mise en pause, pendant que l'on travaille actuellement sur un moteur de jeu web qui fournira une grosse base au développement de Fightly. 

Un des gros avantages de ce découpage, c'est que le moteur sera libre, relativement générique, et très extensible. Il aura donc pour but d'être utilisé par vous, développeurs de jeux web ! Et puis aussi par moi, quand même ! :) L'autre avantage, c'est que ce projet est développé dans le cadre de mes études en Master 2 Technologies de l'Information ! Nous sommes donc 5 à travailler dessus, et Pierre-Antoine Champin, enseignant-chercheur à Lyon, a accepté de jouer le rôle de client, et nous guide donc sur le développement de ce projet. 

Je reparlerai plus en détail de ce projet, il y a beaucoup de choses à faire et à dire. Aujourd'hui, je vous livre un texte que j'ai rédigé en introduction du cahier des charges de ce projet, et qui présente le contexte de ce projet, et pourquoi il apparaît viable actuellement. 

Le Jeu vidéo

Le marché du jeu vidéo s’est beaucoup développé depuis l’arrivée de l’ancêtre Pong ou du célèbre Tetris. On joue aujourd’hui à des jeux de plus en plus beaux, demandant de plus en plus de ressources à nos machines. Mais on voit aussi d’autres utilisations du jeu vidéo arriver : le Serious Gaming, par exemple, est une branche en pleine expansion en ce moment. Le Social Gaming également, représenté activement par les nombreux jeux basés sur Facebook et ses possibilités en terme de diffusion.

Si on s’essayait à une catégorisation rapide des jeux vidéo, voici ce qui pourrait ressortir : les jeux consoles, les jeux PC “classiques”, les jeux en ligne (MMO en tous genres compris). Dans cette dernière catégorie, on trouve beaucoup de types de jeux différents : les MMO dans le genre de World of Warcraft, les jeux multijoueur comme Counter Strike ou Team Fortress, les modes multi des jeux principalement solo, et les jeux par navigateur.

Les jeux par navigateur

Le jeu par navigateur, ou Browser Game en anglais, se joue par définition dans un navigateur Internet. On retrouve donc dans cette catégorie les jeux “Facebook” cités plus haut, la majorité des jeux en Flash, mais également un très grand nombre de jeux que nous appellerons les Jeux Web, puisqu’ils se basent sur les technologies du Web ouvert. Quelques exemples de jeux web relativement connus : Ogame, Travian, ou le français Hordes.

Ces trois exemples ne sont cependant pas représentatifs de la diversité que l’on trouve dans les jeux web. Les jeux d’élevage virtuel, par exemple, sont extrêmement nombreux sur le Web. À quoi est due cette profusion de jeux web ? Majoritairement à la simplicité d’accès du développement web. Faire un jeu web, en soit, c’est développer un site web. Or, avec des technologies très répandues comme PHP, HTML et CSS, avec toutes les ressources que l’on trouve autour de ces dernières (il suffit de regarder les tutoriels du Site du Zéro pour s’en rendre compte), il est très simple pour une personne un peu motivée de créer son propre jeu web.

Malheureusement, s’il est simple de créer un jeu web “basique”, les développeurs sont rapidement limités par les technologies qu’ils utilisent. Il est quasiment impossible de faire du temps réel avec PHP, le couple HTML / CSS n’est pas adapté à l’affichage d’effets spéciaux ou d’animations complexes, et si l’arrivée récente de frameworks JavaScript comme jQuery a permis de repousser un peu ces limites techniques, cela ne résout pas le problème.

Les technologies du web

Il existe une solution simple aux limitations techniques actuelles des technologies web : se tourner vers le futur et utiliser de nouvelles technologies, pas encore éprouvées, mais qui permettent d’aller beaucoup plus loin dans la création de nos jeux web.

HTML 5, la nouvelle mouture du langage de description des pages web, apporte au développeur un très grand nombre de fonctionnalités clés : le temps réel dans le navigateur avec les WebSockets, les manipulations graphiques avancées avec le SVG et les Canvas, la vidéo et le son avec Video et Audio, et bien d’autres.

La version 3 du langage CSS offre elle aussi d’alléchantes nouveautés : les animations, les transitions, les polices particulières, ainsi que tous les effets graphiques amplement simplifiés.

Objectifs du projet

Toutes les avancées actuelles du web ouvrent indéniablement les portes à des jeux de plus en plus impressionnants, de plus en plus profonds, le tout se passant dans un navigateur ! Il faudra cependant du temps pour que les développeurs maîtrisent tout ceci, pour que des outils facilitant l’utilisation de ces technologies apparaissent, et donc pour que l’accès à toutes ces possibilités pour nos jeux devienne simple.

Voici donc où se place ce projet : notre objectif est de fournir un outil complet, permettant de créer de façon simple et rapide un jeu profitant des dernières avancées en matière de technologie web. Il constitura un ensemble d'outils qui fournissent un cadre de développement et des fonctionnalités permettant d'implémenter tout ou partie d'un jeu.

Je serai ravi d'avoir vos avis éclairés sur cette introduction ! Peut-être ai-je raconté des bêtises, peut-être ma vision des choses est-elle fausse, trop orientée, ou idéaliste... Quoi qu'il en soit, si vous avez des commentaires à faire, ils sont tous les bienvenus ! 

À bientôt pour la suite de nos aventures ! :)

3 comments

Tuesday, 9 November 2010

Plugin jQuery : des éléments de même hauteur

By Adrian on Tuesday, 9 November 2010, 10:00

Bonjour ! 

Je vous livre aujourd'hui un bout de code qui vient de m'être utile, et qui permet d'obtenir des éléments de même hauteur. A priori, pour résoudre ce problème, on utiliserait des display: table; et display: table-cell; sur les éléments concernés. Grâce au plugin jQuery que je vous présente, les choses sont bien plus simples : le plugin calcule la plus grande hauteur des éléments concernés, et aligne tous les éléments sur cette hauteur. 

Le problème

sameheight_problem.png

Ce qu'on veut

sameheight_wanted.png

Solution

Le code d'origine est de Adham Dannaway, sur son blog cre8ivecommando : Equal height columns using jQuery. La version qui suit est légèrement améliorée, puisqu'elle permet de passer en paramètre le type des enfants à redimensionner.

Voici le code HTML utilisé pour cet exemple : 

<div class="boxes">
<div class="box">
<h1>Col 1</h1>
<p>Integer lacus orci, eleifend non semper ac, dictum ut urna. Donec sed lacus ligula, nec varius nisl. Cras eleifend porta varius. Nunc porttitor, dui ut scelerisque tincidunt, lorem nulla semper odio, non laoreet nisi dui id lorem. </p>
</div>
<div class="box">
<h1>Col 2</h1>
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi non dolor eu enim aliquam cursus. </p>
</div>
<div class="box">
<h1>Col 3</h1>
<p>Lorem ipsum stuff... </p>
</div>
<div>This div isn't a box ! </div>
</div>

Intégrez à votre page HTML la bibliothèque jQuery, puis ajoutez le code du plugin qui suit : 

/* Plugin to make variable height divs equal heights */
$.fn.sameHeights = function(childrenSelector) {
$(this).each(function(){
var tallest = 0;
$(this).children(childrenSelector).each(function(i){
if (tallest < $(this).height()) { tallest = $(this).height(); }
});
$(this).children(childrenSelector).css({'height': tallest});
});
return this;
};

Il ne vous reste qu'à appeler cette fonction sur les éléments qui vous intéressent : 

$(document).ready(function() {
$('.boxes').sameHeights('.box');
});

Notez que le paramètre de la fonction sameHeights est optionnel : si vous ne mettez rien, la fonction prendra tous les enfants sans distinction. Ce paramètre m'a été utile pour pas appliquer la redimmension à un <div class="clear"></div> contenu dans le <div> parent. 

Voili voilou ! J'espère que ça vous sera utile ! Un grand merci à Adham Dannaway qui a partagé cette astuce. :)

Liens

PS : navré pour l'indentation, j'ai encore du boulot à réaliser sur mon blog... 

Thursday, 22 July 2010

Un serveur WebSocket en Python

By Adrian on Thursday, 22 July 2010, 00:53

Bonjour les gens !!

Bon je sais, ça fait un bail, mais voila, c'est ça aussi la vie d'un blog, y a des hauts et des bas ! 

Aujourd'hui, j'vais vous parler de deux choses, qui sont liées. Tout d'abord, je lance un nouveau projet de jeu vidéo, un jeu web (ou browser game) pour être précis. Mon annonce sur le Site du Zéro présente bien le projet, je vous invite donc à aller la lire si vous êtes intéressé. 

Pour résumer, le jeu sera un jeu de stratégie en tour par tour, faisant s'affronter des unités typées médiéval (infanterie, archerie, chevalerie) sur une carte constituée de cases hexagonales, le tout en vue 2d isométrique. Le but est de faire un jeu simple d'accès, permettant à un joueur de faire une partie rapidement, juste avec son navigateur (sans nécessiter de plugin quelconque), et sans avoir à gérer des tas de trucs avant de se lancer dans la partie. 

Voir le Game Concept Document de Fightly

Techniquement, le jeu utilisera HTML, CSS et JavaScript pour la partie client, PHP pour la génération des pages et Python pour le serveur de gestion des parties. L'intérêt est l'utilisation des récentes WebSockets, actuellement implémentées dans Chrome et Chromium uniquement, mais pour lesquelles il existe des fallback. Je vous ferai bien une présentation détaillée de l'utilisation des WebSocket, et pourquoi c'est top moumoute, mais non. J'vais plutôt vous balancer quelques liens intéressants sur le sujet : 

Et on en arrive au deuxième point : dans le cadre de ce projet, j'ai développé un début de serveur permettant de communiquer avec une page web via les WebSockets. Chez le client, on a un code JavaScript assez classique, qui utilise la très simple interface WebSocket. Et du côté du serveur, j'ai donc développé un serveur en Python qui créé les connexions, reçoit les messages des clients, les analyse et les traite comme il faut, puis renvoie aux clients le nouvel état du "monde". C'est assez étonnant de simplicité, d'autant que j'ai commencé à apprendre Python environ 3 jours avant de réussir à faire ce serveur. Bon faut avouer que je ne suis pas parti de rien, j'ai repris le code de Eneko Alonso, donné sur son blog : More WebSockets, now with Python!

Tout ça pour en venir au point intéressant : j'ai décidé de partager avec vous la partie qui gère les WebSockets. Elle est orientée objet, utilise un thread pour chaque client (donc pour chaque connexion), et vous permet assez simplement d'ajouter votre propre comportement lors de réception d'un message. 

Voir le projet python-websocket-server sur GitHub

Bon, c'est le premier truc que je fais en Python, donc y a surement des erreurs. Mais j'espère que vous saurez me les faire remarquer ! :) Je sais par exemple que je ne gère par l'arrêt du serveur par interruption, et que c'est un problème car le serveur ne s'arrête pas tant que tous les clients ne sont pas déconnectés (puisqu'il y a encore des thread en cours de fonctionnement). Je sais également que je pourrais faciliter l'utilisation du code en ajoutant un mécanisme de fonction callback, mais je sais pas encore faire ça en Python, donc ça viendra plus tard ! ^^

Actuellement, le code est celui d'un chat très simple. A chaque fois qu'un client envoie un message, le serveur le renvoie à tous les clients. Pour tester, lancer le server.py dans une console, et accédez à la page index.html depuis votre localhost. Ouvrez cette dernière dans plusieurs onglets, et envoyer un message dans l'un d'eux. Vous devriez voir apparaitre le message sur toutes les autres fenêtres quasiment instantanément. 

Pour ajouter votre propre comportement, modifiez le code de la fonction onreceive de la classe WebSocketClient (websocketclient.py). Il est aussi possible que vous ayez à changer la configuration du serveur dans le fichier config.py. 

J'espère que ce code pourra être utile à certains d'entre vous. Et bien sur, si vous avez des questions, n'hésitez-pas ! Passez à ma grotte ! Laissez-moi un message ! 

3 comments

Wednesday, 7 April 2010

Minimiser ses fichiers CSS et JS, quelles solutions ?

By Adrian on Wednesday, 7 April 2010, 14:00

Bonjour à tous ! 

Je profite d'un article de Prélude sur l'optimisation par compression ou par minimisation pour présenter les différents moyens existants pour minimiser (ou minifier en mauvais français) les fichiers CSS et JS de votre site. 

Performances des pages web

Mais déjà, pourquoi faudrait-il minimiser vos fichiers ? Au débuts de l'Internet, on avait des débits ridicules, et il fallait donc réduire au maximum le poids de nos pages. Et puis, l'ADSL est arrivé et on a petit à petit oublié les limitations liées au débit. Ce fut une erreur, parce que les internautes détestent attendre. Aujourd'hui, on entend dire que Google va prendre en compte le temps de chargement des pages pour ses algorithmes de recherche. C'est une bonne chose, car cela ramène la question de la vitesse de chargement sur le devant de la scène du développement web. 

Vous trouverez déjà beaucoup d'articles sur le web qui parlent de performance. Il y a des sites entièrement dédiés à ce pan du développement, et Google saura vous les indiquer. Je ne vais donc pas répéter ce que d'autres expliquent mieux que moi, mais je vais vous présenter une façon d'améliorer ses performances que j'apprécie. 

Compression à la volée

Si vous suivez mon blog et mes projets, vous avez vu mon plugin Minifier pour Atomik Framework. Ce plugin permet de minimiser ses fichiers CSS au moment où ils sont demandés par l'internaute. Plusieurs intérêts à ça : réduire le nombre de requêtes HTTP, réduire la taille des fichiers CSS. Au final, l'utilisateur télécharge beaucoup moins de données inutiles, pour le même résultat affiché. 

J'avais découvert cette technique sur le blog de LateralCode (Stunningly Simple CSS Minifier), et j'ai vite accroché. Je ne suis pas fan de la minimisation avant l'envoi des fichiers sur le serveur, parce que ça oblige à avoir deux versions du code (une normale, une réduite), et surtout, ça oblige à re-minimiser les fichiers à chaque changement. Comme tout développeur, je suis faignant, donc ça ne me convient pas. 

La technique proposée par LateralCode consiste donc en une compression via un script PHP, donc directement sur le serveur. On spécifie les fichiers CSS à charger, le script PHP les ouvre, les compresse et les concatène, puis renvoie le résultat. C'est ce que j'ai fait avec Minifier, en ajoutant une fonctionnalité de mise en cache. 

Mise en pratique

Prenons un exemple pratique pour bien voir tout l'intérêt de ce système : j'ai un site avec trois pages. Sur chaque page, j'ai trois fichiers CSS communs : reset.css (un système de reset CSS comme celui d'Eric Meyer), global.css (qui définit des attributs sur mes éléments HTML, comme img { border: none; }) et main.css (qui définit le design général des pages). Ensuite, sur chaque page je charge un fichier particulier, correspondant au nom de la page, qui définit le style des éléments spécifiques à cette page. J'ai donc, sur chaque page, au moins 4 fichiers CSS différents. Ceci me permet d'avoir des fichiers proprement séparés, un code CSS réparti et donc mieux organisé, etc. Seulement, au niveau des performances, c'est pas le top, car 4 requêtes HTTP sont nécessaires pour charger le CSS de la page. 

L'utilisation du plugin Minifier, ou de tout autre système similaire, permet de faire ceci : 

  • génération du nom du fichier cache correspondant aux fichiers CSS demandés
  • si le fichier cache existe, et que les fichiers CSS sont moins récents que le fichier cache, on renvoi directement le fichier cache
  • sinon, compression de chaque fichier séparément (retrait des espaces, des retours à la ligne, des commentaires... )
  • concaténation des fichiers
  • enregistrement du résultat dans un fichier cache
  • renvoi du fichier cache

Au final, on aura donc sur notre serveur des fichiers toujours aussi propres, et on aura en cache un fichier CSS compressé par page. Les internautes ne reçoivent donc qu'un fichier compressé correspondant au code de la page visitée. 

Problématiques

Les systèmes de compression à la volée existent depuis quelques temps, mais je ne crois pas qu'ils soient très connus. L'inconvénient majeur, c'est le temps de compression et de mise en cache nécessaire quand on change un des fichiers. Cependant, la mise en cache permet de diminuer très fortement l'impact de ce comportement. Et puis, quand vous faites un changement sur votre site, vous vérifiez bien toutes les pages, non ? ;-)

Il y a cependant un gros reproche fait à la compression des fichiers en général : ça casse une des bases du web, le fait qu'il soit ouvert. Ainsi, on ne pourra que difficilement reprendre le code CSS d'un site qui compresse, et c'est donc un frein à l'innovation. Faut-il donc perdre en ouverture et en respect du web pour gagner en performance ? 

Je propose une solution simple pour répondre à cette problématique, mais qui ne marche que dans le cadre du système que je viens de présenter. Il suffit, au moment de la concaténation des fichiers compressés, d'ajouter un commentaire contenant des liens absolus vers les fichiers originaux. Ainsi, l'internaute qui s'intéresse à notre code pourra accéder aux fichiers CSS originaux, et récupérer, analyser, comprendre ce code. Les performances sont là (au dur prix de trois ou quatre lignes de commentaire), et le web est sauvé. 

J'envisage d'implémenter ceci dans la prochaine version de Minifier. Que pensez-vous de cette solution ? Avez-vous d'autres idées pour résoudre ce problème ?

Minifiers

Bon, je suis bien d'accord, mon plugin Minifier est absolument génial (lol), mais il n'est disponible que pour Atomik Framework. Sachez donc qu'il existe d'autres projets permettant de mettre en place le même genre de comportement sur votre site. Certains sont plus simples, d'autres bien plus complets. Je ne sais pas si ils fonctionnent exactement comme Minifier, je vous invite donc à les étudier avant de les implémenter.

Voici donc une liste de projets de minimisation de vos fichiers CSS ou JS à la volée : 

Je me rend compte que je n'en connais pas beaucoup, donc si vous en avez d'autres, faites m'en part en commentaire ! :)

N'hésitez pas non plus à troller intelligemment sur les avantages et les inconvénients de la compression des fichiers CSS et JS, ainsi que sur les différentes méthodes disponibles. 

Belle fin de journée à tous ! 

Crédits : Photo "Astronomical Clock" par simpologist

4 comments

Monday, 1 March 2010

Mon tutoriel sur Atomik Framework maintenant sur le Site du Zéro

By Adrian on Monday, 1 March 2010, 10:00

Hello ! 

Je vous fait un petit billet pour vous dire que je suis vivant (je me concentre en ce moment sur la publication sur ideonimbus plutôt que sur ce blog), et que mon tutoriel sur Atomik Framework a été diffusé sur le Site du Zéro : Atomik Framework : un framework PHP simple et léger. 

N'hésitez pas à y faire un tour, j'ai apporté quelques modifications intéressantes, notamment sur le système de layout. 

Bonne journée ! 

Wednesday, 10 February 2010

[Tutoriel] Atomik Framework : installation, configuration et prise en main

By Adrian on Wednesday, 10 February 2010, 10:00

Bonjour à vous, chers lecteurs ! 

Sur une question de @rkueny sur Twitter, et après quelques recherches auprès de mon grand ami Google, j'ai constaté qu'il n'y avait pas de ressource française sur Atomik Framework, mon framework PHP chouchou. Je me dois donc de palier à cette lacune du web francophone. Et comme une bonne chose ne vient jamais seule, la version 2.2 d'Atomik Framework vient de sortir ! 

Dans ce tutoriel, je vais vous apprendre à : 

Continue reading...

8 comments

Wednesday, 20 January 2010

Nouvelle version de Programmateur et débuts de l'API

By Adrian on Wednesday, 20 January 2010, 17:00

Bonjour à vous, amis développeurs et autres. 

J'ai l'insigne honneur de vous annoncer aujourd'hui le passage de Programmateur à sa version 2. Au programme de cette nouvelle version : rien. Ou presque. 

Version 2.0 ?

En réalité, ce que j'appelle "version 2" est une ré-écriture du code de Programmateur, pour plusieurs raisons. D'abord, parce que Martin m'a demandé si mon code était libre, souhaitant l'utiliser pour un projet similaire. Ensuite, parce que oui, libérer mon code ne me dérange pas, et me parait même une bonne idée. Mais enfin, et surtout, parce que mon code source était juste ignoble : à la base, j'ai développé Programmateur pour m'amuser avec l'API Twitter, et du coup l'organisation du code n'a pas été ma grande priorité... 

Donc, j'ai récemment repris le code de Programmateur, et je suis passé à une version basée sur le framework Atomik (que vous devez commencer à connaitre maintenant ! ;-) ), le code final étant bien plus propre, l'organisation des fichiers plus logique, et surtout, les possibilités d'évolution sont bien meilleures ! J'en ai également profité pour améliorer grandement les performances du site, avec plusieurs mises en cache importantes qui n'étaient pas faite, et donc moins de requêtes vers le site de Twitter (qui, il faut l'avouer, est parfois lent... ). 

Le code source du site n'est pour l'instant pas disponible, parce qu'il faut encore que je fasse quelques vérifications / arrangements, et puis parce qu'il faut que je prépare tout ça, et que ça prend un peu de temps ! Je vous ferai, de toute façon, un billet sur le sujet le jour où le code sera libéré... 

Et une API, une ! 

Au niveau des fonctionnalités, elles restent les mêmes, et rien n'est ajouté. Sauf, sauf... Les premiers pas de l'API de Programmateur ! En effet, comme tout bon service web, je me dois de mettre à disposition des utilisateurs les données que je collecte. Evidemment, c'était déjà possible par le biais de Twitter (la timeline de @programmateur est publique), mais c'est tout de même mieux si ça vient directement du service lui-même. 

Pour l'instant, vous ne pouvez qu'accéder aux derniers tweets via cette URI : http://programmateur.lqbs.fr/tweets/list. Deux options sont actuellement disponibles : "format" qui permet de choisir le format des données retournées (actuellement, xml par défaut, ou json), et "count" qui permet de définir le nombre de tweets retournés (par défaut, 10, au maximum 100). En attendant que je rédige une doc, je vous laisse analyser les données retournées, je pense avoir mis des noms suffisamment clairs (d'autant que je me suis beaucoup basé sur ceux de l'API de Twitter ! ). 

Ce n'est, je l'espère, qu'un début. Je vais notamment essayer de créer rapidement un moyen de poster un tweet via l'API, mais je pense être confronté à pas mal de problèmes d'identification, principalement parce que toute l'identification du site se fait via Twitter... Il faudrait donc que je fasse identifier la requête par Twitter avant de la considérer comme acceptable ? Si vous avez des pistes sur ces problèmes, je suis preneur ! :)

Et bien sur, à terme, il y a aura une documentation complète sur cette API ! En attendant, si vous avez des questions, ou que vous voulez utiliser cette API, n'hésitez pas à vous manifester ici. 

What else ?

Pour finir, et parce que je surfe sur les modes du web, Programmateur a sa page formspring, sur laquelle vous pouvez poser toutes vos questions. Une sorte de FAQ 2.0 : formspring.me/Programmateur

Merci de votre soutien, et longue vie à Programmateur ! \o/

3 comments

- page 4 of 6 -