juin 2011 – Brols de Killan

[BaB] Jour 55-56-57 – dans le terrier du lapin blanc

Ces derniers jours ont ciblé l’installateur mais le code n’étant pas encore prêt et grâce à une démo, une liste de bugs est remontée, donc vous imaginez bien la suite.

On peut désormais faire un lien sur une image, ce qui débloque les logos de site étant la source de cette problématique. Ce qui a engendré une série de corrections pour les bordures ainsi que les corps de site.

En parlant de lien, une assistance permet de faire un lien vers une page interne plus facilement tout en permettant les liens externes comme précédemment.

La mise en forme a été corrigé, un lien ne voulait pas s’enlever, sale bête. Il manque juste un peu de CSS et ce sera parfait.

On peut maintenant aligner son texte : à gauche, centrer ou à droite !

Les menus, un peu oubliés, ont été affinés avec l’indicateur de qui est sélectionné, aide pour les designs.

L’édition des images avec lien ou légende a été complété pour palier à tous les cas de figure.

Côté code, ça se complète, se debug, s’affine et s’optimise.

En interne, pour un peu en parler, nos outils s’affinent également, bientôt un système d’attributions de tâches évitant la déforestation pour nos longues listes de points (à faire, modif, debug, …) et aussi des outils pour développeur via le système en lui-même (en projet).

Le sujet des modules est en cours depuis quelque jours, en attente d’une interface, le système de tâche permettra de définir ce gros sujet épineux.

Côté serveur, des optimisation sont en cours également, on attaque de tous les côtés afin d’améliorer le système encore et encore. Notamment un nettoyeur périodique pour toutes les crasses qui ont lieu.

Pour un peu changer, je terminerai cet article par une satisfaction, celle d’approcher d’un système de plus en plus stable et ‘fini’.

Programme de la suite

~ installer le site mère
~ composer RACO
~ installateur
– installer photo véro
– système de modules (incorporation, options, config, utilisation partielle, …)
– publication du contenu (PROD)
– système de tâches
– gestion des modules
– inscription

—
t+=14h30=270h35;

[BaB] Jour 54 – upload sécurisé

Cela n’aura pas été sans mal. Modifier ce qui concerne l’utilisateur, prévoir un moment de mise à jour de ces données, placer les données, transmettre et contrôler… le tout à l’aveugle, codé en un beau one-shot avec succès. Bon ok un ‘;’ manquait et 2 répertoires n’avaient pas les droits d’écriture.

Ensuite c’est le refresh de la liste des fichiers qu’il fallait obtenir. Flash devait appeler une fonction JS indiquant l’état final, appelant le refresh.

Là encore, l’uploader Solmetra était bien prévu, il a juste fallu bien écrire la fonction (pas anonyme !) et ça marche comme sur des roulettes.

Ça a également permis de mettre ne fonction le refresh au lieu d’un copié 3x.

Des finalisations graphiques ont aussi été mises en place.

Programme de la suite

~ installer le site mère
~ composer RACO
~ installation d’un nouveau Buzz
– installer photo véro => système de modules
– publication du contenu (PROD)

—
t+=4h30=256h05;

[BaB] Jour 53 – upload

L’idée est d’offrir la possibilité au gens d’envoyer plusieurs fichier, et pour que ça soit joli et interactif, le flash, actuellement, il n’y a rien de mieux.

Malheureusement l’ami flash ne profite pas de la session de la page qui le charge, du coup il faut créer, rien que pour cet upload, tout un système de vérification de qui peut faire quoi et pour mettre où.

Bien entendu je vous passe la mise en place de la solution Solmetra Uploader utilisant swfobject (voir sujet précédent du même nom).

Après une mise à niveau et quelques réglages pour l’environnement daaboo base 5 me voilà butté à la fameuse erreur HTTP302… mais cette fois je dois dire que cette juste une manifestation du fait que la session n’est pas partagée et que la page ciblée demandais d’être connecté.

Après quelques heures sans comprendre avec tests et bidouilles je remercie le logiciel EffeTech HTTP Sniffer, car sans lui je chercherais encore. Non Firebug ne retrace pas les sorties flash, et HTTPfox non plus.

Du coup, on crée un module, accessible sans être connecté, puisque le système devra être pensé spécifiquement. Là on attaque la 2ème partie, recevoir les fichiers, je continue donc avec la solution Solmetra. Pour moi il y a trop de chose dans la class alors je la réécris sur base de l’originale et ne garde que +-10-15%.

Après adaptation, il reste 2-3 erreurs, vite corrigée grâce au sniffer, ça change une vie.

Résultat, l’upload fonctionne !

Il reste à sécuriser, savoir : qui, quoi et où.

Malheureusement cette sécurisation va demander de revoir le flux, le changement de page, le suivis, générer des clefs, ajouter des contrôles, etc.

Dans la gamme des ajouts de confort, savoir quand flash a fini, recevoir un event js pour rafraichir la liste des fichiers serait pas mal. Il faudra encore étudier swfobject, relire le code de Solmetra et faire une série de tests.

Sinon fin de journée avec Toutou on a mis en place les logos de site avec le système de bordure.

Programme de la suite

~ sécurisation de l’upload
~ installer le site mère
~ composer RACO
~ installation d’un nouveau Buzz
– installer photo véro => système de modules
– publication du contenu (PROD)

—
t+=9h=251h35;

Solmetra uploader et swfobject 2

Voici ma mise à jour vers swfobject 2 de l’uploader de Solmetra.

HTML :

<div id="uploader"></div>

Javascript :

var flashvars = {
  language: "fr",
  baseurl: "/",
  uploadurl: "upload.php",
  config: "swf/uploader.xml",
  instance: "uploader",
  allowed: "",
  disallowed: "php,php3,php4,php5",
  verifyupload: "true",
  configXml: "",
  maxsize: "2097152",
  hijackForm: "yes",
  externalErrorHandler: "SolmetraUploader.broadcastError",
  externalEventHandler: "SolmetraUploader.broadcastEvent"
};

var params = {
  menu: "false",
  allowFullScreen: "false",
  allowScriptAccess: "always",
  wmode: "transparent"
};

swfobject.embedSWF("swf/uploader.swf", "uploader", "500", "50", "8", "expressInstall.swf", flashvars, params, {});

Bon codage.

[BaB] Jour 50-51-52 – installation

Suite à la MEF racontée dans le résumé J49 & cie. d’autres aménagements ont été fait.

Notamment une correction du tableau (menu contextuel) et une finalisation pour les colonnes, on peut définir le nombre de colonne que l’on veut sur base d’un calcul préalable définissant le maximum, conseillé mais obligatoire.

Grand point suivant : l’installateur a été débuté. Il a mit le doigt sur un manque au niveau des fichiers, du coup il a fallu revoir l’idée d’url pour y accéder, fait et fonctionnel !

La partie développement en direct a été corrigée pour les erreurs connues et des idées pour l’améliorer sont en cours. C’est loin d’être le point le plus urgent mais cela peut aider au développement continu.

L’édition des images (changer l’image) a été corrigé pour un petit soucis d’utilisation.

Programme de la suite

~ upload de fichiers
~ installer le site mère
~ composer RACO
~ installation d’un nouveau Buzz
– installer photo véro => système de modules
– publication du contenu (PROD)

—
t+=12h=242h35;

[BaB] Jour 45-46-47-48-49 affinages

Outre une série de corrections d’erreurs et d’affinages d’utilisation, le système à fondamentalement changé en dessous.

En effet la distinction en DEV et PROD du système porteur de Be a Buzz (Base daaboo 5) avec le DEV et PROD de chaque Buzz fait avec notre système Be a Buzz a été réglée. Donc de notre coté on peut développer et mettre en production et vous pouvez faire votre site, le préparer puis le publier. Cette notion de publication, bien que prévu dès l’origine, n’avait pas été clairement marquée dans le code. Une fusion de quelques répertoires ainsi qu’un revisitage du flux BaB de génération et d’accès a été nécessaire. Ceci sans toucher la base 5 qui devait rester distincte de son utilisation.

Ceci a été un des points important de ces 5 jours.

L’autre point réglé fraichement ce matin de jour 50 : la mise en forme (MEF). Complètement réécrite et maintenant sans erreur, plus rapide et « plus mieux », fini et fonctionnelle comme attendue. Virer 2 grosses fonctions PHP et 2 en JS, réécrire une PHP complète en générisant, simplifiant/diminuant 3 fois le code, une vrai partie de plaisir…

Dans la gamme des attendus, la confirmation de suppression ainsi qu’une modification corrigée de l’édition. Si on édite un texte, qu’on supprime son contenu et qu’on désire le sauver, ceci correspond à supprimer le bloc conteneur. Logique, on ne va pas garder un paragraphe vide, ça ferait désordre.

La gestion de fichier a également avancé : design, suppression, multi sélection, filtrage et fenêtre générique modulable à l’appel. Il nous reste à coder l’upload de fichierS.

Toujours dans l’avancement, les bordures sont maintenant éditable tout en utilisant le système existant. De même les logos de site utiliseront la même idée de réutilisation en extérieure de la zone de contenu, une simplification fortement appréciée.

En parlant d’images, ce bloc est complet avec édition de légende.

Le système en lui-même arrive (enfin, je sais) à un stade « complet », il reste néanmoins des tests à effectuer tant au niveau des erreurs qu’au niveau utilisation par un utilisateur lambda.

On va pouvoir attaquer tant en amont (installation, gestion de compte, inscription au système) qu’en aval (publication PROD).

Une grosse partie va donc s’ajouter : la gestion des comptes (finances, échéances, etc…).

Bien que ce qui est gestion sera moins complexe à coder que le système en lui-même, cela ne sera certes pas folichon.

Programme de la suite

~ upload de fichiers
~ installer le site mère
~ composer RACO
– installer photo véro => système de modules
– publication du contenu (PROD)
– installation d’un nouveau Buzz

—
t+=15h=230h35;

Minecraft : wagon avec rappel

Imaginez 2 positions : A et B et un chemin de rails les reliant. Le wagon (minecart) en A est sur un rail de propulsion (poweredrail) activable avec un bouton. En B, c’est la même chose, un rail de propulsion avec bouton (button).

Jusque là on peut aller de A en B et inversement.

Selon la distance et les montées/descentes, il faudra d’autres rails de propulsion pour propulser le wagon.

Maintenant si nous sommes en A mais que le wagon est en B, comment le faire venir à nous ? En appuyant sur le bouton A on pourrait alimenter en même temps le rail de propulsion de B et ainsi le forcer à démarrer. Le wagon viendrait jusqu’à nous. De même en B quand le wagon est en A.

Sur une distance de moins de 15 blocs (distance redstone) cela fonctionnera, mais avec la limitation des 15 blocs nous aurons besoin de répéteur (repeater).

C’est là que ça se corse, le répéteur est unidirectionnel, soit A soit B pourra rappeler le wagon.

Comment faire ? Par tranche de 30 blocs, au milieu il vous faudra la plateforme du répéteur, nous allons l’aménager pour permettre le double sens. Prévoyez une large zone de travail au abord du chemin de rails.

L’idée est d’avoir un circuit de A vers B avec un répéteur et un circuit de B vers A avec un répéteur également. Le soucis est qu’une fois activé les répéteurs s’alimentent les uns les autres. Cela forme une boucle d’énergie. Le seul moyen de l’arrêter est de couper le circuit à la main en faisant sauter une des redstone du circuit. Pas terrible comme solution.

Comment couper le circuit en lui laissant le temps de parcourir tout le chemin ? N’oublions pas qu’en A on veut appeler le wagon qui est en B, et inversement.

Au niveau de notre boucle de répéteur, on va placer un rail de détection. Ainsi quand le wagon passera par là, l’idée est qu’il coupe le circuit. Malheureusement son action est d’émettre du courant et mettre une porte NOT ne nous aidera pas.

L’idée est que le courant venant d’un bouton combiné avec l’action du rail de détection ayant une porte NOT coupe la boucle.

Donc de A vers B j’ai un répéteur qui va dans une porte AND et le rail de détection entre dans une porte NOT qui va à son tour dans la porte AND (pour être alimenté en continu), ainsi la porte AND au moment d’appuyer sur le bouton laissera passer le courant vers B et au moment de passer sur le rail de détection coupera le circuit et donc la boucle de répéteur.

De B vers A, il s’agit d’un pontage avant et après ce circuit logique. Ce qui se passera de B vers A est simple. On appuie sur le bouton B, le pontage contourne le circuit logique et active le rail A. Mais en même temps vu qu’il s’agit du même circuit, le circuit logique sera alimenté aussi et donc au passage du wagon de A vers B le circuit sera coupé, la boucle interrompue et reset du système.

À chaque série de +15 blocs il faudra ce système afin de rappeler le wagon.

À tester : est-ce que 2 systèmes consécutifs s’alimenteraient malgré les coupures ou est-ce que cela fonctionnerait ? Si j’en ai l’occasion est les matériaux je referais un article.

Bon bricolage de circuit.