Bon, comme c'est les vacances et que je n'ai pas grand chose à faire, j'ai décidé de me pencher un peu sur les automates cellulaires - comme par exemple le Jeu de la Vie de Conway.

Je trouve que les automates cellulaires sont parfaits car ils ont un côté programmation, un côté algorithmique et un côté ludique non négligeable... Voilà donc de quoi tuer de sérieuses heures.

Alors bien sûr, comme utiliser un programme déjà existant ça n'est pas marrant, j'ai décidé d'implémenter le mien avec mon langage de programmation favori : Java.

Cependant, il y a déjà plein d'automates cellulaires "classiques", optimisés, paramétrables, opensource, bref parfaits. Donc, pour compliquer la tâche, j'ai décidé de choisir un pavage hexagonal au lieu du classique pavage rectangulaire que les programmeurs choisissent la plupart du temps.

Réalisation technique

L'avantage du pavage rectangulaire, c'est qu'on peut exprimer les coordonnées d'une case (un carré dans la majorité des cas) très simplement...

On peut observer alors qu'une cellule possède quatre voisins directs. En général les conditions de survie ou d'apparition de la vie dans une case dépendent du nombre de voisins vivants. La notion de "voisin" ne se limite pas aux cases immédiatement adjacentes (même si c'est comme ça dans la plupart des cas).

Avec un pavage hexagonal, établir un système de coordonnées est déjà plus complexe, même si ça n'est pas impossible.

Comme on peut le voir, cette fois-ci une cellule a six voisins directs. Cela ouvre bien sûr de nouvelles possibilités. Le système de coordonnées que j'ai choisi n'est sans doute pas le meilleur mais il permet de calculer la simulation de façon théorique relativement simplement. En fait, peu importe le système de coordonnées choisi, tant qu'il est possible de donner les coordonnées des voisins d'une cellule à partir de ses coordonnées.

Le problème est d'afficher tout ça d'une façon simple... Autant pour dessiner et colorier des rectangles, c'est simple. Pour des hexagones, c'est déjà un peu plus subtil.

Je me suis inspiré de cet excellent article expliquant comment créer une grille hexagonale en .NET. J'ai repris les grands principes, adapté à ma sauce. Voici le résultat :

Une fois que j'ai pu avoir un résultat visible, j'ai réellement été agréablement surpris au niveau des performances. Avec mon modeste Core2 Duo E6600 standard, je peux générer et afficher environ 20 fois par seconde une carte de plus de 5700 hexagones (en gros tout mon écran avec une résolution de 1680x1050 avec des hexagones ayant pour côté 10 pixels). C'est un résultat convenable et tout à fait suffisant pour un usage "simple", c'est à dire des observations basiques et l'aspect amusant de la chose, mais ça ne suffira évidemment pas à faire de grandes simulations très complexes.

Observations effectuées

Pour la suite de cet article, j'utiliserai la notation Bx/Sy pour définir les règles du jeu utilisées. Il s'agit d'une notation utilisée dans la majorité des programmes, notamment Golly. La notation est très simple à comprendre, surtout à partir d'un example : si la règle est B456/S23, alors une cellule va naître si elle a exactement 4, 5 ou 6 voisins, et elle va survivre si elle a exactement 2 ou 3 voisins.

Règle B34/S34

D'après mes premières estimations, les cellules tendent à disparaître très rapidement en formant beaucoup d'oscillateurs, le plus souvent de période 2, de formes très variées mais suivant toutes le même principe : une « chaîne » de cellules, circulaire ou non, forme le coeur de l'oscillateur et est invariable. Cette chaîne est entourée de cellules espacées en général d'une cellule vide, parfois de deux. Ce sont ces cellules là qui vont osciller, comme si elles "tournaient" autour de la chaîne.

Oscillateurs de période 2 et de longueur de chaîne respectives de 1, 2 et 5.

Il n'y a pas l'air d'avoir de motifs invariables ou de vaisseaux « simples » dans cette configuration.

Règle B34/S234

Cette règle, qui a l'air de ressembler à la précédente, est en réalité très différente.

Les motifs statiques « still life » profusent, énormément de motifs simples sont stables. Lorsqu'il y a beaucoup de cellules, elles ont tendance à former des polygônes stables, de taille très variable, oscillant avec des périodes en général comprises entre 2 et 5. Lorsque les cellules en vie sont présentes en plus grande quantité, elles forment un motif caractéristique, qui possède une capacité d'adaptation extraordinaire.

Ce motif répétable peut s'adapter à un grand nombre de formes, tout en laissant place à plusieurs types d'oscillateurs.

Règle B3/S23

Avec cette règle, éponyme à celle du Jeu de la Vie dans sa version orthogonale, les cellules vont à première vue se stabiliser très rapidement en motifs statiques invariables simples. Les oscillateurs sont rares et n'apparaîssent que très peu comparés aux autres formes statiques.

J'espère que j'ai réussi à vous donner envie de vous intéresser aux automates cellulaires, ils sont vraiment intéressants. Le projet est maintenu et distribué via Github.

C'est déjà passé.

Le compte à rebours n'a plus aucun intérêt, si vous voulez quand même le voir, revenez dans le passé, environ vers la fin du mois de juin.

Freenet est un réseau anonyme et chiffré qui est basé sur Internet. Il a été créé par Ian Clarke, est distribué sous licence GPL et est maintenu par beaucoup de développeurs bénévoles ainsi qu'un développeur à plein temps, payé grâce aux donations. Le but principal est de prôner la liberté d'expression et de rendre toute censure impossible. C'est pourquoi, par exemple, il est impossible de supprimer du contenu de Freenet une fois qu'il a été inséré dans le réseau. De même, chaque noeud (un noeud est un ordinateur faisant tourner Freenet) n'a aucun moyen de savoir ce qui transite et ce qui est stocké dans le disque dur.

De façon plus pratique, Freenet permet d'insérer des Freesites, un ensemble de pages xHTML formant un site anonyme ou non, d'effectuer du partage de fichiers, de consulter des groupes de discussion et de s'envoyer des Freemails (système d'e-mail basé sur le réseau Freenet).

Freenet est surtout connu pour avoir soulevé de nombreux débats éthiques, du fait de l'absence totale de censure. Cependant, si vous tenez à conserver un réseau où vous serez sûr que personne ne pourra vous enlever votre liberté d'expression, alors Freenet devrait vous intéresser, surtout avec les projets de loi récents visant à filtrer Internet en France (LOPPSI). Le réseau est vraiment conçu pour ça, les développeurs eux-mêmes ne pouvant arrêter le réseau, même sous pression juridique.

Un historique proche relativement chargé

Il y a quelques mois, ce projet a bien failli ne pas continuer d'exister, et ceci pour plusieurs raisons.

Tout d'abord, le bénévole chargé de l'administration du serveur principal hébergeant le serveur SVN a décidé qu'il ne pouvait plus continuer. Or, personne d'autre n'avait les compétences nécessaires et la confiance nécessaire pour le remplacer. Pour pallier cela, les sources ont été déplacées sur GitHub. Ce choix est discutable, GitHub pourrait facilement décider d'arrêter d'héberger les sources de Freenet à cause de problèmes légaux ! Finalement, git permet assez facilement de s'adapter à ce cas de situation et donc cette éventualité ne causerait pas la mort du projet.

Vu que le projet n'est alimenté en argent que par les dons et qu'un développeur est payé à plein temps, l'argent a commencé à manquer de façon très sérieuse. C'est aussi pour cette raison que le serveur principal a été coupé suite à l'abandon du bénévole chargé de son administration, il représentait un coût non négligeable. Pour donner un indice, le projet a survécu avec moins de 1000$ en réserve pendant plusieurs mois.

Finalement, à la surprise de tous, Google a versé une importante donation de 18 000$ au projet au début du mois de mai. La survie du projet n'est donc plus un problème à moyen terme. Pour rappel, Google a joué un rôle important pour le projet, notamment grâce aux Google Summer of Code (GSoC).

Les nouveautés de la version 0.7.5

La version précédente, 0.7, datait de mai 2008. Mais cela ne veut pas dire qu'aucune nouveauté n'est apparue depuis plus d'un an. Le fonctionnement de Freenet est un peu particulier au niveau des versions. Le noeud se met à jour lui-même (en général de façon automatique) via le réseau Freenet ; le numéro de version est donc une notation symbolique pour mettre en évidence les nouveautés des précédents builds. Les développeurs n'attendent pas de date précise pour ajouter de nouvelles fonctions, ils le font lorsqu'ils jugent de façon arbitraire qu'il y en a eu suffisamment pour changer le numéro de version.

Depuis la version 0.7, de très grosses nouveautés ont été implémentées. Voici un résumé non exhaustif des plus significatives.

Résultat de plus d'un an de travail acharné, l'intégration de db4o (Database for Objects) a permis d'augmenter très grandement la performance et de réduire les ressources utilisées par le noeud. Il est par exemple possible de télécharger plusieurs gigaoctets de fichiers sans pour autant observer une augmentation de la quantité de mémoire vive utilisée. Un noeud typique consommera maintenant entre 100 et 250 mégaoctets de mémoire vive, pas plus. Grâce à db4o, on peut maintenant faire des petits serveurs dédiés Freenet en réutilisant du vieux matériel, ou bien avec du matériel miniature. Cela laisse de belles perspectives pour l'avenir : Freenet sur de l'embarqué.

L'interface web de Freenet (FProxy) a été améliorée afin de la rendre beaucoup plus accessible aux néophytes. De nouveaux installeurs ont été mis au point afin de rendre l'installation plus simple, et de renforcer la compatibilité avec Windows Vista.

Enfin, la majorité du système de plugins a été refondue en profondeur. Cela permettra par exemple d'avoir des dépendances inter-plugins, ou encore leur mise à jour automatique. C'est une modification peu importante pour l'utilisateur, mais c'est une brique nécessaire à l'achèvement de la prochaine "grosse" version de Freenet, la 0.8.

Qu'attendre à court/moyen terme ?

Freenet 0.8 comportera Freetalk/WoT, un nouveau système officiel pour communiquer avec les autres utilisateurs. Annoncé depuis longtemps comme révolutionnaire, tout le monde l'attend avec impatience. Étant donné que Freenet est un réseau entièrement décentralisé, ce système se basera sur une technique de "Toile de confiance" (Web of Trust). En gros, vous devez noter votre confiance envers les autres utilisateurs, afin de rendre impossible toute tentative de spam. Les autres utilisateurs vous notent également. Il paraît évident que les identités ayant de très mauvaises notes seront ignorées des autres, et ne pourront donc plus communiquer. C'est un système de filtrage décentralisé et « démocratique » en quelque sorte : chacun a son mot à dire, et le système se régule de lui-même.

Un nouveau type de clé sera aussi créé : les MHKs (Multiple not Duplicated Hash Key) serviront à partager de gros fichiers plus efficacement qu'à l'heure actuelle. Le fonctionnement est complexe, mais globalement, les blocs d'index seront insérés avec plus de redondance afin d'éviter la perte prématurée de données.

Enfin, les noeuds pourront aussi partager leur bloom filter avec leurs voisins immédiats. Cela signifie que votre noeud "saura" ce que stocke chacun de ses voisins, ce qui représentera un gain important de performances. En revanche, l'implémentation d'un tel système est très délicate, et il faudra donc être patient.

Le mot final

Cette avancée symbolique de Freenet a bien sûr pour but d'attirer plus d'utilisateurs, mais aussi de faire connaître Freenet aux internautes du monde entier : Freenet est indétectable de l'extérieur si utilisé en mode Darknet (en se connectant uniquement à des amis à proximité de confiance), et il faut donc au moins savoir que des solutions existent pour pallier la tendance qu'ont les gouvernements à filtrer le web, ou à envisager de le faire, tout au moins. Freenet est tout de même utilisable si on ne connaît personne qui l'utilise : le mode Opennet vous connectera à des inconnus (la seule différence par rapport au Darknet, c'est qu'on peut savoir que vous utilisez Freenet. Mais comme il n'est pas encore illégal en France, ça ne pose aucun problème).

Enfin, Freenet étant développé entièrement en Java, il est compatible avec n'importe quel système d'exploitation disposant d'une JVM version 1.5 au minimum. Cela inclut Windows, Mac OS, GNU/Linux, FreeBSD, Solaris, ...

(Publication originale ici, rédigée par moi-même.)

Ça n'est pas grand chose, mais mon premier patch a été commité sur le svn de Freenet. Le but étant d'améliorer le plugin XMLSpider.

La première contribution à l'Open Source, un peu comme le fait de perdre sa virginité parmi les geeks libristes (ou pas).

Pour les intéressés, voici les preuves :
http://emu.freenetproject.org/cgi-bin/viewcvs.cgi/trunk/plugins/XMLSpider/db/Config.java?rev=26583&view=markup http://emu.freenetproject.org/cgi-bin/viewcvs.cgi/trunk/plugins/XMLSpider/web/ConfigPage.java?rev=26583&view=markup

Ces liens ne seront sûrement plus valables dans peu de temps, dû au changement de système de révisions... Mais bon.

GoatTracker est un tracker produisant de la musique pour le Commodore 64. Il est disponible sous license GNU et est multiplate-forme.

Cependant, il n'a pas été porté sous FreeBSD, bien qu'il fonctionne bien sous Linux. Heureusement, grâce à quelques hacks simples, il est possible d'utiliser GoatTracker sous FreeBSD.

Avant tout, vérifiez que vous avez les ports/packages SDL d'installés, ainsi que GNU Make ("gmake") différent du BSD Make par défaut ("make"). Il y a quelques différences dans la structure des Makefiles donc il faut utiliser l'un ou l'autre en fonction de ce qu'on compile.

Ensuite, procurez vous GoatTracker à cette adresse : http://covertbitops.c64.org/ (rubrique "Tools").

Unzippez les sources dans un répertoire spécial crée à cette occasion, et placez vous dedans.

Avant de compiler GoatTracker, il faut compiler 2 outils qui seront nécessaires : datafile et dat2inc.

Placez vous donc dans le répertoire src/bme. Avant de lancer gmake, il faut modifier le Makefile car il est adapté à une machine Linux. Or, les machines Linux n'utilisent quasiment pas le préfixe /usr/local pour les includes. Le Makefile va donc chercher SDL_types.h dans /usr/include, alors qu'il est situé dans /usr/local/include. Pour corriger cela, il suffit d'ajouter ceci aux CFLAGS : -I/usr/local/include. Le makefile étant ici extrêmement simple, rajoutez cela aux deux appels à gcc.

Vous pouvez ensuite lancer la compilation avec gmake. Une fois que c'est terminé, vous devez copier ces deux exécutables produits dans votre $PATH, donc en gros vous devez copier les fichiers datafile et dat2inc dans /usr/local/bin.

Ensuite, placez vous dans le répertoire src. Cette fois, le Makefile est un peu plus complexe, vous devez rajouter -I/usr/local/include à la fin de la ligne CFLAGS= dans le fichier makefile.common. La compilation se passe ensuite sans problèmes.

Vous pouvez enfin jouer avec GoatTracker, l'exécutable étant situé dans le sous dossier linux/ et commencant par gt2. Enfin, voici une preuve que ça fonctionne :

Voici un petit article vite fait pour vous faire découvrir un de mes compositeurs préférés :

« Je d-_-b cerror. »

Et c'est bon. Encore, encore...

(presque) tout cerror en un seul zip.

Parlons includes. En général, lorsqu'on réalise un projet en PHP, on découpe le travail en plusieurs parties qui se répartissent donc logiquement en plusieurs fichiers. Pourquoi ? Parce que c'est en général plus simple de savoir où on est quand on manipule un fichier dont le nombre de lignes se rapproche plus de la centaine que du millier.

Cependant, gérer plusieurs fichiers est parfois délicat : on se retrouve confronté à des problèmes de répertoire, de path relatif difficile à prévoir et toutes ces subtilités. Et comme on décide de l'architecture d'un projet avant même de commencer le gros du code, on a vite fait de tout foutre en l'air à cause d'une mauvaise organisation. Evidemment, on ne peut jamais prévoir totalement les problèmes que causeront notre architecture choisie. Donc, au lieu de prévoir tous les problèmes possibles qui pourraient arriver, il est bien plus pratique de prévoir un système de base d'includes qui est flexible, c'est à dire que les modifications seront simples à effectuer. Changer 50 fichiers car on a besoin d'en renommer un autre est un gros problème de flexibilité par exemple. Il y a donc une bonne et une mauvaise façon de gérer ses includes.

The Bad Way

Cette méthode est malheureusement retrouvée parmi les débutants, car on la retrouve dans beaucoup de cours. C'est une mauvaise habitude pour des projets conséquents. Voyons pourquoi.

Imaginons cette architecture simple, retrouvée dans un paquet de projets (les noms sont fictifs) :

/lib
----/myFunctions.php
----/BDD.php
----/template.php
----/otherStuff.php
/requireMe.php
/index.php
/pageUn.php
/pageDeux.php
/pageTrois.php
/.htaccess

Dans cette organisation, on accède aux pages directement via leur URL (/index.php) ou via un URL Rewriting qui effectue une redirection silencieuse en arrière plan (c'est équivalent à la première méthode). Chaque page inclut le fichier requireMe.php, qui inclut les fichiers annexes contenus dans /lib. Donc, chaque page accède bien au code qui est commun.

Cette méthode est très rapide à mettre en oeuvre et très simple : elle est bien adaptée à l'Extreme Programming mais malheuresement elle n'est pas vraiment flexible. En effet, pour l'instant c'est simple, mais imaginez que vous ayez 50 pages à la racine. Si, un jour, vous avez besoin de changer quelque chose qui a un rapport avec requireMe.php (comme son nom, son emplacement, ...), vous devrez modifier 50 fichiers. Amusez-vous bien à perdre du temps.

The Good Way

Maintenant, on passe à une méthode que je qualifie de "bonne", enfin c'est mon avis subjectif. Il est quand même certain qu'elle est plus flexible que la mauvaise méthode.

On a une architecture de ce type :

/lib
----/myFunctions.php
----/BDD.php
----/template.php
----/otherStuff.php
/pages
------/index.php
------/pageUn.php
------/pageDeux.php
------/pageTrois.php
/main.php
/.htaccess

On accède aux pages via URL Rewriting uniquement. Cela permet de placer les pages dans un dossier spécial. Ce qui est important ici, c'est qu'on redirige TOUTES les requêtes au script main.php. Cela permet de n'avoir qu'une ligne dans le .htaccess, peu importe le nombre de pages. Et ça, c'est flexible.

Mais qu'est-ce qui change ? Tout le système est inversé, en fait. Le fichier main.php va analyser $_SERVER['REQUEST_URI'], inclure la bonne page (ou générer une erreur du type 404 ou autre), éventuellement utiliser des regex sur cette variable pour les URI du type /Article-27/1991/Janvier/27/ et inclure en plus des fichiers annexes contenus dans /lib. On ne retrouve donc aucun include dans les fichiers des pages : tout est regroupé dans le fichier main.php ; grâce à quelques constantes bien choisies, on peut s'adapter à, à peu près n'importe quoi en changeant un minimum de choses. Le système est inversé car ce n'est plus la page qui inclut les fichiers annexes, c'est un fichier annexe qui inclut la bonne page. Il n'y a dont plus qu'un seul fichier qui gère les inclusions : système souple.

Alors certes, je n'ai rien trouvé de révolutionnaire. Mais en général, quand on se rend compte que l'architecture est à chier, c'est trop tard. Il faut faire quelques bons choix dès le tout début. En résumé : n'incluez pas les fichiers annexes dans vos pages, incluez la page dans un fichier annexe spécial !

J'ai testé Fedora 10 pendant à peu près un mois, histoire de voir comment ça a évolué depuis ma dernière expérience Linux, et également pour voir à quel point FreeBSD déchire tout. Pourquoi ? Vous allez très vite comprendre.

On passe tout de suite au premier point qui fâche : PulseAudio. Je suis pas intrinsèquement "contre" ce dernier, mais son intégration est tellement bâclée et son développement est tellement actif encore qu'il serait préférable de ne pas l'utiliser par défaut, ou encore de nous laisser le choix à l'installation. PulseAudio est l'avenir de l'audio sous tous les sytèmes, peut-être. Mais dans le futur.

Déjà la doc est relativement pauvre. En dehors du PerfectSetup, on est un peu seul dans la nature. Donc quand ça merde, on l'est aussi. Le problème de PulseAudio c'est que plein de trucs ne fonctionnent pas encore avec. Certes, il a un mode d'émulation de pérphiériques io OSS via l'utilitaire padsp, ça marche de temps en temps mais il y a également des cas ou ça ne marche pas. Par exemple avec Wine, c'est une vraie plaie pour faire marcher l'audio. Quand à l'émulation alsa, n'en parlons pas, je n'ai jamais comrpis comment m'en servir et je n'ai jamais réussi à obtenir quelque chose de concluant avec ça.

Cependant, mes problèmes ne se sont pas arrêté là, car une fois que tout marchait "à peu près", je me suis rendu compte que mon microphone n'étais pas reconnu. Et là, c'est le comble ! J'ai demandé de l'aide sur IRC, sur les forums, rien. Pourtant mon chipset est très très commun en ce moment (hda_intel).

Ensuite, un gros dernier problème en ce qui concerne la latence audio. Elle est bonne, mais cependant le son était très mauvais, avec beaucoup d'artefacts audio, ce qui est quand même dérangeant quand on est adepte de MAO.

Néanmoins, PulseAudio possède quelques fonctions qui auraient pu être sympas. Comme par exemple la diffusion RTP sur le réseau, qui permet par exemple de lire la musique de sa bibliothèque du PC du bureau avec MPD, et entrendre le son sortir par son ordinateur portable situé dans une autre pièce. Seulement, je n'ai jamais réussi à la faire fonctionner et ça n'était pas à cause du firewall ni des débits réseau (les deux PC étaient câblés directement via un hub).

Ce qui est dérangeant, c'est quand on pense qu'avec FreeBSD, tout ça fonctionne au poil, du premier coup et sans toucher à rien : un simple kldload snd_hda et paf, ça fait des chocapics. Basse latence dans MilkyTracker, et ce même si plusieurs applications utilisent actuellement le périphérique, microphone reconnu et volume bien confortable, pas de "device busy" au moindre pet de mouche, la zénitude totale quoi.

Passons maintenant à autre chose : le gestionnaire de paquets. Mon arbre de ports favori m'a réellement manqué, pas parce que PackageKit et yum sont mauvais mais qu'on arrive vite aux limites. Déjà, quand on veut compiler quelque chose, on doit installer une tonne de paquets de développement (en gros ce sont des fichiers .h) sinon ça ne compile pas. Jamais eu besoin de faire ça avec FreeBSD, étant donné que les ports utilisent les sources au lieu de paquets précompilés (bien que ça soit possible d'en installer aussi sous FreeBSD).

Ce qui était embêtant, c'était les base de données de rpm qui avaient tendance à se corrompre toutes seules, et à bloquer tous les threads jusqu'a ce qu'on supprime de fichiers bien particuliers, c'est relativement agaçant à force.

Sinon, à part ça, Fedora a quand même des trucs vraiment cool comme par exemple la possibilité d'installer les paquets i386 ou amd64 si on est en amd64, afin de lancer des programmes binaires compilés pour une architecture i386. Y'a aussi le démarrage graphique relativement rapide, un thème GNOME par défaut bien réussi et bien intégré. Enfin les goûts et les couleurs, ...

Eh oui. Pourquoi ne pas utiliser un Dotclear ou un bon vieux Wordpress déjà tout fait ? Parce que c'est prise de tête.

Déjà, il faut installer mysql-server et mysql-client, qui sont deux gros ports très très longs à installer. Ensuite, il faut utiliser le démon mysql-server. Certes, ça n'est pas la fin du monde, mais utiliser MySQL (ou n'importe quelle autre base de données, d'ailleurs) pour stocker deux misérables tables, c'est un peu ridicule.

Si on veut se passer de base de données, pourquoi ne pas utiliser Pluxml ? C'est un blog fonctionnant avec XML et très léger. Mais leur systèmes de thèmes est vraiment, vraiment désagréable et ça n'est pas aisé de modifier un thème à sa guise pour qu'il nous convienne.

J'avais découvert quelques jours auparavant les systèmes d'options de modules du noyau directement via des fichiers, par exemple /sys/devices/system/cpu/sched_smt_power_savings. Et j'ai réalisé que ça pourrait vraiment être cool d'utiliser ce système dans un script de blog PHP, que je cherchais justement à réaliser.

Ce blog est donc très simple, remplit mes besoins et justement se manipule entièrement grâce aux fichiers. Pour faire simple, il n'y a aucun panel d'administration quelconque. Il suffit de créer un fichier et de commencer à rédiger son post dedans, avec n'importe quel éditeur de texte. Ca a bien sûr beaucoup d'avantages : on ne perd pas de temps à concevoir un panel d'administration, on n'a pas besoin de s'occuper d'un système d'authentification et d'identification quelconque, ce qui simplifie déjà grandement le travail et permet donc de se focaliser directement sur l'objectif ainsi que les points très importants : les templates, l'affichage, ...

AwesomeBlog respecte sans le faire exprès le grand principe d'UNIX : tout est fichier. Les commentaires, les articles, les paramètres, tout. C'est donc facilement éditable, mais également très accessible et facilement automatisable via un script shell par exemple (ce que les formulaires xHTML classiques ne permettent pas de faire). Par exemple, imaginez un script qui active le mode maintenance via un simple "echo 1 > MaintenanceMode", effectue les maintenances puis désactive le mode maintenance une fois qu'il a terminé ? C'est simple, facile, ça va droit à l'objectif. Pas besoin de s'embêter à se connecter, aller dans quinze pages pour trouver le petit formulaire permettant de faire la même chose ; de plus on ne peut le faire de manière automatisée dans un script shell (ou très difficilement).

L'absence de base de données est également un point apprécialble dans d'autres situations : si on veut tout simplement "déplacer" le blog, en faire une copie, une sauvegarde ..., il suffit simplement de déplacer un répertoire. C'est tout. Pas besoin de s'embêter avec des dumps MySQL qui foirent en général à cause de l'encodage, de la taille du dump trop importante, ou parce qu'on a simplement oublié de le mettre avec les autres fichiers (ça semble bête, mais c'est du vécu). De plus il est également très facile d'oublier ce dump lorsqu'on veut formater le disque ( également du vécu, plus d'une fois). De plus, la lourdeur de MySQL n'est pas présente ce qui permet d'avoir des scripts relativement légers et donc rapides. L'accès aux fichiers contenant les données étant directs, plusieurs techniques permettant d'accélérer ces accès sont donc mis en place indirectement sans même qu'on aie à s'en soucier : la mémoire cache du disque dur en est un exemple. MySQL a également un cache, mais le gain de performance est bien plus intéressant quand on manipule directement des fichiers.

Etant donné que je serai probablement le seul à utiliser ce script de blog, je n'ai pas l'intention de le rendre "redistribuable". Trop d'efforts à faire, surtout si cela n'intéresse personne. Cependant, si vous tenez réellement à l'utiliser, j'aurais envie de dire "Do It yourself !" (faites le vous-même !) tellement ce script est simple, mais j'essaierai de rafistoler ça pour le rendre réutilisable. C'est pas que je développe comme un porc, pas du tout. Mais il se pourrait que j'utilise des trucs exotiques que monsieur tout le monde n'a pas sur son hébergement mutualisé ( extensions PHP qui-vont-bien, accès au HDD via des chemins absolus, URL rewriting, ...).

Si vous avez eu le courage de lire ce gros pâté jusqu'au bout, rassurez-vous : tous les posts ne seront pas comme cela.

Ou pas.