ToursAnnonces.fr

06h36 : start
le jour où chui censé être au moins à la moitité des tâches,
j'ai pas compté, mais, …
ben en fait le système le fait pour moi, comme l'arbitre au tennis.

19 à faire, 16 en attente,
ah ouai d'acord, un léger vent de face,
pas grave, j'en ai vu d'autres…


Par contre ce matin la brise est fraîche, j'ail l'impression dêtre dans le gaz…
bon bref,
sysadmin.


Manitou script.

Faut que je trouve un moyen de lui dire que même si c'est pas un chiffre, il doit pas bugguer comme ça..

Tout se joue dans le test de base :
while [ -z $TASK ] || [ $TASK -gt 2  ]

SI je pouvais initialiser un tableau avant genre

tableauChoixPossible = [vl1, val2, val3]

et faire un


while [ value inthe tableau ]

Comment on fait un truc comme ça en bash ?


06h50 :
en arrivant sur ce document :
http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO.html#toc8

je croyais qu'il y avait un bug.

J'avais simplement oublié que le style des linuxiens est très épuré comme je l'aime.

Honnêtement, si ça ne tenait qu'à moi, Tours annonces ressemblerait à ça.

Bon, mais là n'est plus le sujet, lisons …

http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO-4.html
m'amène ici :
http://www.commentcamarche.net/faq/9558-sed-introduction-a-sed-part-iii
en français me je capte rien, j'ai besoin d'y aller plus molo

07h48 : Bon, j'ai pas trouvé direct un exemple, mais j'ai une idée : 
faire une fonction, puis récupérer la sortie avec $?
et voilà, mais là chui fatigué, je vais dormir encore..


09h03 : yo.


maintenance…

09h42 : Tours annonces :

Annonces : Amélioration de la recherche
Triggers prix
Lorsque l'on recherche par prix, ne pas afficher les prix NULL 


Effectivement les prix peuvent être NULL ce qui veut dire vide,
ou bien avoir une valeur numérique, allant de 0 à euh chaiplusmaisbeaucoup…

Déjà mettons une petite aide dans le formulaire pour que les utilisateurs comprennent mieux comment ça fonctionne.


Pour le prix, n'indiquez que des chiffres ou rien.
Si vous ne mettez rien, cela signifie pas de prix.
Si vous mettez 0, cela signifie gratuit.
Tout autre nombre ( ou chiffre ) représente le montant de ce que vous vendez.
Pour utiliser les centimes, utilisez le point, mais pas la virgule.



Voilà, et maintenant le pb :
il est vrai que lorsque l'on fait une recherche par prix, il est très vraisemblable que l'on cherche les prix les moins chers,
or les prix vides (non renseignés=NULL) sont actuellement pris en compte dans la recherche par prix croissants.

Je pense que théoriquement le mieux serait que si c'est une recherche par prix, que ce soit ascendant ou descendant, 
les prix null (objets sans prix) soient mis systèmatiquement en dernier;

Hélas je ne sais pas si j'y arriverais facilement, étant donné mon niveau en sql, je vais essayer vite fait, mais plus vraisemblablement,
voici ce que je peux appliquer rapidement :

Je propose que::
ssi le champ de tri = prix et que le sens du tri est ascendant, alors
ne pas afficher les prix NULL.
C'est risqué, car cela élimine des résultats.
Mais en réalité, lorsque l'on cherche par prix, on ne veut certainement pas avoir les annonces sans prix.
Je peux aussi faire d'éliminer dans les 2 sens les prix null lorsque le champ du tri est prix.
10h13
Codons quelque chose de rapide et simple et léger…

10h20 :ok, j'ai un petit doute sur la syntaxe mysql, mais ça marche en local, à faire gaffe si ça marche en prod :
AND a.prix IS NOT NULL

Donc ce que j'ai fait : le plus simple :
si c'est une recherche par prix croissant  : les prix vides (null) ne sont pas pris en compte.

Espérons que ce choix éditorial conviendra à la plupart, en tout cas pense que ce sera le cas.


La suite…


10h22

Newsletter pour chaque évolution
newsletter
Prévoir une liste de inscription/désinscription newsletter
Cette newsletter permettra principalement d'être tenu au courant des nouvelles évolutions du site,
ce qui implique un certain formatage de la liste d'évolution.



Mouais,
je vois là l'occasion de faire un système d'abonnement/désabonnement newsletter plus général (abstrait)
un peu à la manière du site du zéro.

Ben en fait dans mon cas, effectivement à chaque évolution c'est pas si mal.
Intéressant…

Ce qui est très important, notons le tout de suite, c'est que l'utilisateur peut se désinscrire/inscrire en un clic depuis son compte.

On peut donc d'ores et déjà prévoir un champ supplémentaire dans la table utilisateur_tan abonne_newsletter qui vaut 0 ou 1.

En fonction de ce réglage la suite;

Je ne veux pas me contraindre à une obligation de régularité de fournissage de contenu, ni aucune contrainte d'ailleurs.

Précisons que cette newsletter s'appliquera à évolution seulement.
Si plus tard il y a d'autres newsletter, ou envoi de promos, ou autres, cela sera l'objet d'autres réglages, ainsi l'utilisateur aura progressivement
un compte qu'il pourra finetuner, avec plein d'options, kool;

Donc pour les newsletter d'évolution, ben faut déjà que je créé le format.
Euh,

Disons un mail html, que je placerais dans un dossier, avec des noms formatés genre evolution5-1.html, evolution5-2.html…
Voilà, un jour je me tape le html.
Le mieux aurait été qu'il me génère le mail automatiquement à partir de la liste des évolutions,
mais le rproblème actuel c'est qu'il y a des choses qui ne sont pas très compréhensibles dans la liste.
Mais en réalité, cela est juste dû au fait que je n'ai pas su énoncer correctement le problème et sa description.
Je peux donc me baser sur un système automatique avec pour contrainte de bien formuler les demandes dans la partie todo_task.

Oui, je veux.

Donc, 
sur simple pression d'un bouton dans l'admin :
le système me génère une newsletter en html, à partir de la liste d'évolution, cette newsletter est hébergée sur le site,
c'est plus propre, au cas où les clients mail posent problèmes.

Puis sur une autre pression d'un autre bouton, l'envoi de mail avec gestion de ne pas envoyer le mail 2 fois à la même personne;

Mais en fait j'ai déjà fait un système comme ça, je vais voir comment le réexploiter… (pour la gestion d'envoi de mail.)

Commençons par voir ce qui a déjà été fait…

Voici ce que j'ai trouvé au niveau des tables :
sch-newsletter.png
c'est très light, et je ne vois pas à quoi cela correpsond, cherchons dans le code…


Nettement plus intéressant :
le système de gestion de l'envoi est effectivement déjà fait, et fonctionnel, malgré tout je vais l'améliorer un petit peu.
Actuellement,
il y a un script qui fait cela :


CONFIGURATION : nombre d'envoi max par passe = 20.
EXECUTION :

le script en gros fait une requête qui retourne la liste de tous les utilisateurs de Tours annonces.
le script initialise un compteur à 0;

Pour chacun des éléments de la liste,

si le compteur est supérieur au nombre d'envoi max par passe, le script s'arrête.
le script cherche si l'id de l'utilisateur est dans la table mailing_sended_list.
Si c'est le cas, le script passe au suivant.
Sinon, il inscrit l'id de l'utilisateur dans la table mailing_sended_list et envoie un mail qui formaté à partir d'un fichier html, mais le nom du fichier html est codé directement dans le code.
le compteur est incrémenté.

Ce script est appelé régulièrement par une tâche cron, par exemple toutes les 3 minutes.
Le lancement et l'arrêt de la tâcha Cron est pour l'instant défini manuellement.



Ce script est une bonne base, mais il y a plusieurs limitations,
voici ce que je vais lui faire dans le cadre de la mise en place du système de nwesletter évolution;


Au final ce script sera un module qui recevra les paramètres suivants :

-la liste des utilisateurs (cela me permet de choisir différente liste, et notamment dans le cas de la newsletter evolution, il s'agit
des utilisateurs actifs dont l'option recevoir la newsletter evolution est active).
-le nom du fichier html à utiliser pour le mail.
-le titre du mail
-...

Optionnellement, je m'envoie un mail, ou tout autre système pour arrêter la tâche cron une fois que la newsletter a été envoyée
à chacun des utilisateurs figurant sur la liste. (Ca c'est si j'ai le temps).


Une autre limitation, mais qui n'en est pas une pour l'instant, est le fait que ce système ne permet de gérer qu'une newsletter à la fois;


Donc cela sera pour la partie envoi de la newsletter.

Il me reste la partie création de la newsletter à définir.

Pour cela, je me baserai sur le mail qui a déjà été envoyé, afin de m'adapter aux contraintes du format de mail par html.


Bon, il me semble que mon plan d'attaque est grossièrement défini.
11h05

Passons à la réalisation, et commençons par la génération d'une newsletter à partir d'une liste de todo_task.



Voici, ce qui est déjà fait, je n'ai plus qu'à marcher sur la ligne tracée…
http://www.toursannonces.fr/mailing/general/lancement-tours-annonces-5/index.html
Cette page html est utilisée à la fois comme référence sur le site, et elle est envoyée par mail, kool.


11h16 : 
en fait, la liste est très longue, ça fait beaucoup pour le mail, je vais faire les newsletter à la main pour l'instant.
Par contre le support du mail, doit mener sur la liste exhaustive des todo_task qui ont été réalisées.
Cette liste sera générée automatiquement, à partir de nouveaux champs.
En effet, les champs de todo_task ne sont qu'une autre manière de reformuler les todo_suggestion.


Maintenant pour la présentation, il faudrait des champs change_log : titre, et description, date.
Le plus propre est soit de faire une autre table avec les nouveaux champs, soit de réécrire le change log en dur.


Il me semble que tout mettre dans une table est plus souple concernant la modularité de l'affichage des données,
aussi, je vais faire cela.

Créons une table evolution_changelog
avec les champs suivants :
id, date, titre, description

sch-evolution_changelog.png


Afin d'éprouver concrètement cette table, entrons d'ores et déjà les entrées.
J'utiliserais le même que système que pour la fac pour entrer des constantes ou des liens dynamiques.
Pour la date, ça serait bien que le système la mette automatiquement,
il faudrait donc qu'il ait la référence de la todo_task correspondante, cela implique un léger changement dans le schéma sql…
Toutefois, les evolution_changelog ne sont pas plus dépendants que ça des todo_task, d'où l'absence de relation forte.

En fait je me rends compte que le plus pratique pour moi est d'écrire un fichier texte plat.
Je vais donc trouver un système qui me permet d'insérer automatiquement les données à partir d'un fichier texte brut.



*********************************
Changelog list
*********************************

Un système de republication pour les utilisateurs méritants.
++
Possibilité pour les utilisateurs de republier leurs annonces (repasser leurs annonces en tête de liste pour un coût de
{CONST_TAO_COUT_REPUBLICATION_ANNONCE} {CONST_TAO})
++
1

*********************************
Ajout du champ siret sur le formulaire d'ajout de commerce
++
++
46
*********************************
Ajout de boutons de navigation sur l'espace perso des commerces
++
++
7
*********************************
Amélioration du système de commentaires dans la partie évolution
++
Le système permet la possibilité de mettre un commentaire à gauche ou à droite, et lorsque c'est le webmaster qui parle,
un cadrage spécial est utilisé.
++
28
*********************************
Ajout d'un style d'affichage: grid, pour les listes d'annonces
++
++
8
*********************************
Ajout d'un loader ajax pour la plupart des formulaires du site
++
++
27
*********************************
Amélioration du formulaire d'inscription
++
Une requête ajax est faite et permet d'indiquer en temps réél la disponibilité d'un pseudo.
Un test simple est effectué sur le mot de passe afin de donner une indication sur sa sécurité
++
29
*********************************
Ajout de la catégorie : projets
++
++
24
*********************************
Création du système d'alerte sur les annonces
++
L'utilisateur peut désormais placer des alertes sur des annonces,
ces alerte arrivent dans ses mails et dans son compte {CONST_WEBSITE_TITLE_DEFAULT}.
++
23
*********************************
Ajout d'une entrée dans la FAQ : les constantes système
++
++
19
*********************************
Ajout d'une vidéo dans la FAQ pour l'entrée : comment inscrire gratuitement mon commerce ?
++
++
9
*********************************
Ajout d'un logo pour matérialiser le fait que le site est en phase d'évolution
++
++
18
*********************************
Création d'un système d'alerte sur les promos d'un commerçant
++
L'utilisateur peut s'inscrire au flux de données "promo" d'un commerçant particulier par le biais
du système d'alerte.
Lorsqu'il le fait, il reçoit instantanément par mail et dans son compte {CONST_WEBSITE_TITLE_DEFAULT} les promos du commerçant en question.
++
20
*********************************
Amélioration de l'espace perso du commerçant pour les possesseurs du compte vendeur
++
Le commerçant qui possède un compte vendeur peut créer autant de "blocs" qu'il le souhaite dans la section infos
de son espace perso. Un gestionnaire de médias est à sa disposition qui lui permet de gérer un espace disque sur {CONST_WEBSITE_TITLE_DEFAULT}.
Le poids de maximum autorisé par compte est défini ailleurs. Le formulaire d'ajout de "blocs info" utilise ce gestionnaire de médias.
++
21
*********************************
Ajout de la section biographie sur le profil d'un utilisateur
++
L'utilisateur peut ajouter sa biographie par l'intermédiaire de son compte.
Si la biographie est créée, elle s'affiche sur le site, sinon, le système n'affiche rien.
++
22
*********************************
Développement de la partie rencontres
++
La catégorie rencontres est mise en avant sur le site (ajout d'un icône dans le iconsmenu), et gestion d'un popup de warning
pour alerter que du contenu choquant pourra être diffusé dans cette section.
++
25
*********************************
Modification du mécanisme de tri par prix pour les annonces
++
Les annonces sans prix ne sont plus prises en compte lors de l'affichage d'une liste d'annonces triée par prix croissant.
++
32
*********************************
*********************************
*********************************
*********************************
*********************************
*********************************




J'avoue que j'ai un peu des doutes, ça fait pas mal de redondance avec les todo_task, mais bon, restons fixé sur le fait que c'est plus
propre, et ne laissons pas notre fainéantise, pourtant moteur d'ingéniosité nous gagner ici.


Mon constructeur de evolution_changelog à partir d'un fichier brut devra :
1. S'assurer que le format de CHAQUE entrée est valide avant de commencer le processus d'insertion de la première entrée.
2. Effectuer le processus d'insertion.

Ce fichier sera un module pour la section admin du site;
Il prendra en paramètre un nom de version.

Pour faire propre, je vais séparer dans 2 tables :
une table

evolution_version
id, titre, commentaire

et evolution_changelog
id, date, titre, description, id_todo_suggestion (modif), evolution_version_id


Au final :
sch-evolution_changelog2.png


Bon, écrivons ce module...


12h58 musique
13h58 tours annonces

En fait, le fait d'automatiser l'insertion des entrées dans la table evolution_changelog n'est pas vital,
et vu que j'ai moins de 4 heures, c'st plutôt une perte de temps qu'autre chose.
Nous allons insérer les entrées à la main, pour gagner une heure..


14h23 : 5 intrées sont insérées, c'est suffisant pour tester ce que nous voulons;
Le script d'affichage doit générer la page html à partir le cette table.

Le but, c'est ça :
Tan_Private_NewsLetter::createHtmlPageFromEvolutionChangeLog($id_evolution_version, $destination, $option=array());

Go.



16h23 : L'objet me semble ok : et le format de la newsletter correct,
j'ai fait  moitié à l'arrache, cela voudra dire qu'on pourra à moitié kustomiser quand même.
Mais j'ai prévu les encapsulations principales afin de gagner du temps si jamais l'objet a bseoin d'être retouché;

Passons maintenant à l'option de l'utilisateur qui permet de se désinscrire et mettons à jour les modifications faites
sur la table evolution_version : commentaire = text


En fait, comme chui une ultime fainéasse, je vais payer le prix fort (ajout des 2 champs date_debut et date_fin)
afin que le créateur de la newshtml me génère l'intro tout seul qui sera un truc du genre :


Du 01 mai 2010 au 31 mai 2010,
Le site {CONST_WEBSITE_TITLE_DEFAULT} a subi une évolution, il est maintenant dans sa version 5.1.
Le résumé des modifications subies est affiché ci-dessous.

Vous êtes tous invités à laisser dès maintenant vos suggestions pour la prochaine évolution qui se déroulera normalement
du 01 juillet au 31 juillet. N'hésitez pas à vous exprimer.
Pour laisser une suggestion,  rendez-vous sur la page Evolution.
Nous vous remercions de l'intérêt que vous nous portez.
A bientôt.

Cordialement,
L'équipe de {CONST_WEBSITE_TITLE_DEFAULT}.



Hélas pour pousser la logique à bout je suis obligé d'ajouter en plus les champs date_next_debut
et date_next_fin, et un champ version, car titre, ce n'est pas tout à fait pareil.
Soit 5 champs tout ça pour m'éviter de modifier 3 lignes.
…

…

Ma foi, 3 lignes de moins, c'est toujours ça de gagner.
Le coût en performance pour l'utilisateur est quasi nul, donc on peut le faire...


stop : confronté à des gros problèmes de logique : pour un développement multivilles,
je dois repenser toute l'organisation, même sur l'ensemble du framework ,…
phase de méditation…


17h46



…




18h00 sport.


18h59 : Joomla

coup de tél...

21h44 : Bon , je dois annuler ma séance de maya, trop en retard sur tours annonces.
J'ai toujours pas trouvé une structure objet qui me plaise, c'est à dire qui réponde à ma problématique interne 
de multiville-villeunique… pour l'envoi de newsletter, …


je crois que j'ai trouvé un truc, mais assez blogué, silence et concentration

voix off;……………..(et pendant ce temps des choses magiques se passent partout ailleurs) ………`








CLASSES :
Tan_Private_NewsLetter
Tan_Private_NewsLetter_Evolution




PATCH SQL

SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0;
SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0;
SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='TRADITIONAL';

CREATE  TABLE IF NOT EXISTS `tan`.`evolution_changelog` (
  `id` INT(11) NOT NULL AUTO_INCREMENT ,
  `evolution_version_id` INT(11) NOT NULL ,
  `date` DATETIME NOT NULL ,
  `titre` VARCHAR(255) NOT NULL ,
  `description` TEXT NOT NULL ,
  `id_todo_suggestion` INT(11) NOT NULL ,
  PRIMARY KEY (`id`) ,
  INDEX `fk_evolution_changelog_evolution_version1` (`evolution_version_id` ASC) ,
  CONSTRAINT `fk_evolution_changelog_evolution_version1`
    FOREIGN KEY (`evolution_version_id` )
    REFERENCES `tan`.`evolution_version` (`id` )
    ON DELETE CASCADE
    ON UPDATE NO ACTION)
ENGINE = InnoDB
DEFAULT CHARACTER SET = latin1
COLLATE = latin1_swedish_ci;

CREATE  TABLE IF NOT EXISTS `tan`.`evolution_version` (
  `id` INT(11) NOT NULL AUTO_INCREMENT ,
  `titre` VARCHAR(255) NOT NULL ,
  `commentaire` TEXT NOT NULL ,
  PRIMARY KEY (`id`) )
ENGINE = InnoDB
DEFAULT CHARACTER SET = latin1
COLLATE = latin1_swedish_ci;


INSERT INTO `tan`.`evolution_version` (`id`, `titre`, `commentaire`) VALUES (NULL, '5.1', 'du 1 mai au 31 mai');

SET SQL_MODE=@OLD_SQL_MODE;
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;