Fusion de la chambre intermix

Suite à l’article précédent j’ai voulu faire un tour de nettoyage et je me suis rendu compte qu’un ancien démon revenait à la charge. Nous avons divisé le code par domaine et contexte de rendu, propre et héritant d’un parent commun, et dans un service je mets le code commun à ce qui concerne Grid, ou Iso etc., de manière à isoler les calculs de l’usage selon le contexte.

Schéma avant fusion

Plus simple avec un schéma, voici la découpe avant fusion. Ce qui nous intéresse c’est la séparation 2D et Gl, puis la découpe par usage/type à savoir Sprite, Grid ou Iso, puis les regroupements de type IsoElement/GridElement, ainsi que des services relatifs aux couches.

On a une sorte de matrice à 3 dimensions en ce qui concerne cette idée. Sauf que programmer ça, en TypeScript, ben c’est pas très évident. En PHP j’aurai pu utiliser des Traits, il existe des mixins en javascript mais non merci, je vous laisse vous faire votre avis mais ce n’est pas à la hauteur. L’héritage multiple n’existe pas (cf mixin), du coup il faut savoir se renouveler et faire preuve d’audace, d’expérimentation et de refontes inévitables. C’est ce que j’ai dû faire, non sans mal.

J’étais parti pour déplacer les fonctions de rendu dans les services par couche (Grid/Iso) et de fusionner Grid2DElement avec GridGlElement, vu que leur différence réside dans le contexte de rendu (2D/Gl). Mais je me suis aperçu que bien que je gagnais en clarté à tout regrouper, on augmentait d’autre part la difficulté de ce même code et des approches. Bref, bien, mais pas bien.

Du coup revirement de situation et revenons sur nos pas de plusieurs mois quand on a justement décidé de diviser par contexte de rendu, quand les lumières sont arrivées (la version solutionnée). Revenons donc à cette idée non divisée et sans emmerder les services déjà très bons tels quels.

C’est la fusion !

Fusionner Grid2D et GridGl, Iso2D et IsoGl, ok, mais on oublie Sprite2D et SpriteGl qui héritent de SpriteElement, il faut commencer par le commencement. C’est donc une refonte jusqu’à Element pour répartir les morceaux des différentes classes Sprite*. Ainsi disparaissent Sprite2DElement et SpriteGlElement au profit d’une nouvelle classe SpriteElement toute équipée.

Quand on parle de fusion on parle bien entendu de gérer le contexte de rendu au sein même de la classe. Ceci peut paraître étrange et contre certains bons principes, mais ces morceaux de code partagent parfois jusqu’à 90% du code, ce qui va contre le principe DRY (Don’t Repeat Yourself) et comme j’ai envie de bisous (KISS : Keep It Stupid Simple), j’ai tout regroupé et cela ne m’a demandé que quelque if peu coûteux, ce qui est très important car on appelle ces bouts de code des centaines, des milliers de fois par seconde (selon complexité de votre projet).

Fusion de Sprite*Element

J’en profite pour illustrer le service de rendu Gl et montrer à partir d’où on le connecte. J’en affiche un peu plus mais ainsi on voit les 2 types de regroupement GridElement et IsoElement. Ne prêtez pas attention à GridBlock, vous le connaissez déjà.

Nous sommes bien parti, continuons. On crée une nouvelle classe GridElement et on met ce que contient Grid2D et GridGl, hop tout dedans et on essaye de faire coller les morceaux. Là où ça se corse c’est de bien segmenter les parties communes et spécifiques, puis quand on arrive à IsoElement c’est encore pire car nous sommes basé sur l’héritage donc on ne réécrit que ce qui a besoin de l’être et là on observe des couacs, des oublis pour la 2D vu qu’on s’est concentré sur Gl depuis les lumières. Par exemple la table en 2D ne fonctionne pas, juste en Gl.

Fusion terminée

Sur papier ça parait plus beau, naturel, élégant, [mettre ici tous les beaux mots que vous désirez]… Mais dans la pratique ça demande pas mal d’efforts, de compréhension, évidemment c’est pour un mieux !

C’est quand même un impact de 33 fichiers dans le projet et son POC de démo, 8 dans TARS même, ainsi que 8 suppressions et 2 ajouts. Ça c’est pour les fichiers, mais en terme de lignes de code, même si je n’ai pas de compteur à cet instant, on a effectué une réduction notable, donc plus facile à maintenir, de par le regroupement aussi.

Preuve que ça fonctionne toujours, même si la table n’est pas gérée encore correctement en 2D.

Garder 2D et Gl ?

Pourquoi garder les 2 ? Car il est très difficile de débuger en Gl, vous ne pouvez pas dessiner aisément un repère ou une trace sans sortir les chars d’assaut et beaucoup d’heures de dev alors qu’en 2D vous êtes libre de manipuler le rendu en direct et ce rapidement.

C’est pour cela que le POC (démo) n’utilise plus les lumières en 2D, le but pour moi ici étant un debug rapide sans ajouter des soucis de performances, qui plus est, connus.

De plus, maintenant que la fusion est faite, on pourrait revoir tout le workflow d’utilisation pour ne plus devoir faire (à l’usage) une scène 2D ou une scène Gl. ainsi en changeant juste le mode, toutes les classes personnelles seraient utilisables, ce qui serait un chouette gain de temps et d’effort. De plus les 2 fonctions ajoutées is2DContext/isGlContext permettent d’agir spécifiquement si besoin était.

Et le fameux ensuite ?

Ah ben oui, ensuite quoi ? Corriger le pourquoi de la table en 2D et tenter de régler un conflit Grid/Iso sur un calcul de positionnement.

Il faut absolument faire un POC purement Grid et non Iso, genre un Mario (S)NES ou Duke Nukem 1-2, un truc tout carré pour voir que les calculs sont bons, juste une grille décorée, pas plus.

Ensuite, mes fameuses particules lumineuses et le miroir :p !

Mais bon, comme d’hab on verra ce qui me stitch comme on dit. Je vais déjà de ce pas fusionner les branches du repo et repartir sur une base saine :).

Edit

Pour ne pas refaire un article juste pour ça, j’ai également fusionné les classes du POC (treasure, door, player), leur code était identique. 3 classes de moins sur les 6 initiales (3x2D et 3xGl). Une bonne chose de faites qui va nous simplifier la vie ultérieurement. Les scènes restent dissociées car différentes, la Gl, plus complète, gère la lumière par exemple, les fusionner ne donnerait rien d’intéressant une fois en release. Au moins le debug (2D) peut se faire sans gêner le résultat final (Gl). Nous voilà dans un état propre, quelques corrections de bugs ou de manques seraient à faire pour solidifier avant d’avancer plus.

Curl, PHP et Synchrone

Contexte

Dans un projet d’assemblage de PDF (j’en parlerai surement dans un autre article) je devais pouvoir envoyer différentes pages et une structure pour établir une table des matières. Je pensais mettre à jour la structure à chaque envoie mais le résultat obtenu n’était pas celui attendu, il me manquait des choses. Je recevais bien toutes les données, le curl fonctionnait bien, mais la structure était incorrecte.

Après analyse de mon code, remise en question etc, il s’avère que c’est au niveau du curl que ça coince. En effet, faite une vingtaine de call curl à la chaîne avec transfert de fichier à taille variable et vous comprendrez que c’est entré en conflit. Droit d’écriture sur le fichier ? Verrou de fichier ? Rien n’y fait.

Un call curl (méthode PHP et consort) n’est juste pas bloquant dans la complétion de son action.

Pensez autrement

Oui, au final, vous devrez revoir votre manière de vous y prendre, l’idée a été d’envoyer les fichiers, sans se soucier de la structure, de la maintenir coté client et de l’envoyer par une méthode supplémentaire du service avant d’appeler la génération finale. Le projet reste le même, juste le quand on reçoit l’info.

Ceci est une révolution…

Nous sommes chez Sivit depuis +6ans, je ne retrouve même plus la date du premier contact, c’est dire. Personnellement, je n’avais rien à leur reprocher, bon service et offre correcte, nous ce qu’on voulait, c’était développer notre offre d’hébergement, mails, domaines et de conception web, ainsi que des petits outils très en vogue à l’époque comme les compteurs, livre d’or etc. Ok ça c’est mort depuis un sacré bout de temps, les temps changent.

Depuis le rachat de Sivit par Nerim, j’ai personnellement senti une différence tant dans la qualité du service que dans leur communication.

S’en suit depuis quelques mois une séries de soucis avec nos serveurs qui n’avaient pas vraiment bougés pour dire d’en mériter. On a tout d’abord cru a une attaque par empoisonnement de cache DNS, puis a des tentatives de hack par les mails et au final plus assez de ressource sur la machine, veuillez prendre l’offre double ou quadruple… non merci, c’est pas 2 sites qui pètent un VDS même s’il est vrai que le VDS en question est pas terrible vu la concurrence.

C’est là que j’ai trouvé, grâce a des avis éclairés (encore merci à vous), une solution. Je vais changer ma manière d’opérer et aller vers cette fameuse « virtualisation ».

Il faut dire que passer des soirées et week-end entier pour de la config… à un moment donné on a autre chose à faire quand celles-ci ne vous apportent plus d’ennuis que de satisfaction. Revoir mon mode opératoire était donc indispensable, j’avais même pensé tout simplement arrêter cette partie de mon activité.

Ça plus les soucis passés ça faisaient beaucoup pour un seul homme en après journée… mais voilà qu’une nouvelle voie s’ouvre à moi comme dit ci-avant et donc on va reprendre le taureau par les cornes et affronter la bête.

J’ai jusque fin des contrats des 2 serveurs daaboo, soit +- juin, pour tout migrer, reconfigurer, adapter largement et offrir mieux pour vivre mieux.

Vous vous imaginez donc largement que tous les projets et sites sont actuellement en stand-by, le temps de mettre tout ça au clair le plus rapidement possible. Ça coûtera un peu, c’est sur, le recouvrement coûte toujours quelque chose, mais c’est pour un mieux.

badawok 7 – yaml et tests unitaires

L’inspiration m’est revenu voulant éviter Mecaclac 9 qui me sort par tous les trous. C’est ainsi que la relance de badawok 7, non terminé, m’a pris.

Je me suis mis en tête de mettre en application mes récentes recherches au sujet de PHPUnit. Ayant déjà pratiqué simpleTest, c’était là l’occasion de tester autre chose. J’aime assez bien, même si NetBeans n’a pas l’air de le reconnaitre, ce qui n’aide pas.

J’ai attaqué gentiment avec les classes t et st pour commencer en douceur, mais cela a déjà mis en évidence certaines petite lacunes de structure ou de contrôle. But atteint donc, et ce n’est là que le début, je vise une couverture maximale.

Sur mon portable, le pear yaml n’était pas installé du coup je me suis à nouveau confronté à cette non inclusion du yaml dans PHP. Chance pour moi, Fabien Potencier (Symfony) a mis sur GitHub la partie de Symfony concernant le yaml, version 1.2, mieux que ce que ne propose les libraires en ligne ou même le pear.

Il m’a suffit de quelques adaptations (pas d’utilisation de namespace, tous dans un seul répertoire), cf logger, et le tour était joué.

Ceci dit je me suis donc intéressé à l’idée namespace pour badawok, mais là, manquant de compréhention, je vais parfaire mes recherches afin de décider si oui ou non cela peut aller avec badawok. ainsi que la migration des projets clefs comme comitards.be, terragusto.be ou racougree.be v2 à venir.

Tout cela m’a donné une bouffée d’air frais. Corriger, refondre, mettre en forme le code, adapter, simplifier, factoriser … que du bonheur !

L’avenir de badawok se dessine plus clairement maintenant. Je pense ajouter une installation, retirer ses dépendances vhost et .urls, ajouter un .htaccess longtemps mis de côté (.urls), ajouter dès lors un panneau d’administration de son badawok, donc aussi gérer les utilisateurs directement par badawok, même si cela semble se rapprocher du CMS, ce que la fusion BaB donnera probablement.

En parlant de fusion BaB, cela s’éclaircit également, un design de menu contextuel a été pensé, changeant de l’habitude mais qui pourrait être bien sympa, plus graphique ainsi que l’idée générale du comment cette édition contextuelle va se glisser, ce qu’elle gèrera, ce que cela va apporter, ses possibilités de développement pur (PHP, JS, CSS), et d’autres idées encore, comme la gestion AJAX du contenu vu que l’on gère ici des contenus dans un corps. Accompagné d’un require et d’un class.js le tour serait joué.

Un site badawok.net va arriver et ainsi pouvoir mettre en avant le redmine, le produit, une démo et un téléchargement ! Ceci dit cela se voudra être pour la sortie de la v7, on a encore le temps et il y a d’autres priorités malheureusement.

Comitards 2 – lancement

Comitards 2 a été lancé le 17 mars vers 22h-23h après 27h de boulot en 2 jours pour finir, débugger et migrer de la 1 à la 2.

Le samedi alors que nous annoncions déjà depuis un moment la sortie du site en date du 18 (St Torè) le premier pique de visite ‘pointe’ le bout de son nez avec +1500 vues et 900 le lendemain, puis plus rien pendant 3 jours… FAUX le script de stats n’avait pas été réactivé dans la conf…

Le pique du jeudi (après le St Torè) nous a laissé un indice, soit +1200 vues puis +1500 à nouveau le lendemain.

En même temps la 2.0.4 est sortie corrigeant les quelques petits bugs urgents.

C’est le samedi 6, quand nous avons lancé la newsletter, après avoir ajouté quelques fonctionnalités de modérations et du contenu, que le gros pique a explosé les stats avec +4000 vues pendant 2 jours (pour un nombre de visiteurs unique grandissant).

Et va savoir pourquoi mais lundi 15 bam repique de +2400 vues, sans raison apparente, ah ben si, les mails qui s’ouvrent après coup et boom seconde vague ! Le reste du temps, moyenne agréable de quelques centaines de pages vue et dizaines de visiteurs uniques, pour un site occasionnel… 🙂

Mais comitards 2, il change quoi ?

En gros la base de données a été refondue, et on a coupé 1/3 des tables refondues en un système unifié, plus flexible.

Le design a lui aussi été complètement réécrit, ainsi que les interfaces et la manière d’interagir.

Le contenu a été complété encore et encore et de nouveaux types de contenus ont été introduit comme les autocollants, les guerres, …

Un long travail, jamais fini, mais qui en cet état représente une belle évolution de sa version précédente.

Cela n’a pas été facile mais pour ceux qui nous ont envoyé (à Sophie et moi) des mails de contribution et même des remerciements, ça me fait plaisir de l’avoir fait. Aux autres qui râlent sans prendre la mesure, même si on traite leur demande, on a juste envie des les envoyer au diable avec leçons de politesse, de comprendre qu’il ne paye pas et que quelqu’un derrière fait nuit blanche pour eux…

Le lancement ne c’est pas fait que sur internet.

Effectivement nous avons pris part à la St Torè (Liège) et distribué des centaines de flyers et autocollants de penne en guise de campagne promotionnelle. Merci à ceux qui nous ont aidé !

Là tout de suite Comitards 2.0.4 c’est 1928 inscrits, 267 groupes folkloriques pour 4 pays et 6 traductions.

Ce n’est pas fini 🙂

724_g

Comitards 2.0 – phase 2 et 3

Ça y est j’ai trouvé le temps ! Impossible avant avec une maison à finir, emménager etc… mais voilà ça y est j’ai trouvé du temps !

La phase 2 est terminée dans son idée originale. La DB est fonctionnelle selon la nouvelle idée. Certaines observations me font penser que d’autre tables vont sauter, comme la correction de penne selon option d’étude.

La phase 3 est en cours, j’ai placé un autocomplete pour supprimer les formulaire rébarbatif d’encodage d’études, titres et oripeaux.

Le tout en plus ou moins 30 heures de boulot en 3 jours. La suite est planifiée, y a encore pas mal de boulot et je ne vous parle même pas d’encodage supplémentaire.

Dans un premier temps on va finir le profil, aménager le générateur de couvre chef, je pense qu’une réfection en objet serait la bonne chose à faire avec héritage et cas particulier au lieu de conditions internes un peu sauvage.

Un gros travail sur la protection des données serait le point suivant avec la finition de la DB et d’un fallback de langue.

On terminera par un grand coup de peinture (CSS) pour le côté neuf moderne.

Sans oublier les nouvelles fonctionnalités, les encodages, les outils de modération de groupes folklorique, …

Seul ce n’est pas facile mais on va y arriver ! 🙂

Noyé Joël et Ânesse Molle

Reprise de Comitards (v2), Be a Buzz remanié et j’espère le DVD OQR.

Ça ça serait bien, et si je pouvais tenter une expérience Web 3D (Nahyan) ça serait encore mieux !

Il y a aussi le site ‘maison’ (bihin-vinders.be) qu’il serait bien de construire petit à petit.

Badawok 7 – c’est parti

L’installation a été adaptée :

– suppression du module home par défaut et ajout dans le wiki une aide pour faire un module
– ajout du fichier vide pages.yml
– ajout du répertoire pour y mettre les pages

Ensuite, le nouveau système de gestion de page prend place tout doucement. Le routeur a été réécrit pour en tenir compte et une fonction d’accès avec utilisation du cache persistant a été ajoutée.

La structure permet d’avoir un nombre non fini de répertoires virtuels ainsi que des arguments !

Le fichiers des pages peut-être édité à la main et des scripts d’édition seront ajoutés plus tard pour faciliter le travail.

La prochaine étape primordiale est d’ajouter le nouveau système de rendu des contenu (cf BaB).

Ainsi le projet Comitards.be v2 pourra débuter et tester Badawok 7 concrètement.

Tout en gardant la structure des urls actuelle, le système devra gérer le contenu et les modules.

À suivre sur le redmine également.

Badawok 7

Badawok 7, anciennement 6.2, est planifié !

Il passe de 6.2 à 7 car il ne sera pas compatible à la 6.0 actuelle, du fait qu’un changement au niveau du cœur (route, aiguillage, …) sera nécessaire, même si on ne change rien au reste.

On va intégrer à Badawok la partie contenu YML de Be a Buzz et le système d’édition (à la fin). Ce qui oblige de revoir la logique de routage qui ne sera plus ‘module/action’ mais ‘page’ contenant des widgets/composants qui utiliseront les ‘modules/actions’, en gros on ajoute une étape en plus pour augmenter les possibilités.

La partie YML utilisera le système de cache pour garder la performance, de même que pour les widgets qui le désireront.

Une généralisation du système d’édition en direct est prévue également, permettant d’éditer des partie uniquement, tel qu’on l’imaginerait pour un blog ou une « bordure » (cf BaB).

Les widgets ou composants, représenteront des parties de code réutilisable tel un système de représentation tabulaire, un album photo ou une simple liste.

Cette version sera bientôt mise en développement et les informations suivront, ainsi que sur le redmine de daaboo 🙂