ToursAnnonces.fr

07h08 : start sysadmin
Comlètement parano jusqu'alors, je considérais que le système de passphrase de ssh n'était pas très sécurisé.
Un ami qui s'y connaît en sécurité réseau m'a rassuré à ce sjuet, du coup, je vais pouvoir automatiser les tâches de sysadmin.


But : gagner du temps, assurer la continuité (et donc la crédibilité) du système de stats sur le site)
Création d'une routine qui sauvegarde la base mysql puis qui vide la table statistiques et enfin ajoute une entrée à la table statistique_totaux.

crontask1 : Automatisation de la sauvegarde mysql par un script bash.
crontask2 :(2 minutes later) Appel à un script php qui effectue ma cuisine locale sur mes tables sql.

09h33 : le premier pas est fait.
Le script de mise à jour des stats est opérationnel et fonctionnel sur les 3 villes.
La sauvegarde automatique est en place.
A améliorer … placement du fichier sql dans un dossier pratique pour le rappatriement en local, et rappatriement local automatique …



09h35 : Tours annonces.
Continuons bêtement la liste.

Commerce : alerte utilisateur pour une promo
Promo
L'utilisateur peut créer une alerte : m'avertir lorsque ce commerçant fait une promo. 



De loin, je réexploite le script d'alerte que j'ai fait pour les annonces, et je l'adapte pour les alertes_promo.
Autrement dit, chaque fois qu'une promo est postée par un commerçant,
une vérification est faite dans la table alerte_promo.
Si cette table contient des entrées qui matchent (id_commerce identique tout simplement), alors une alerte est envoyée au propriétaire de l'alerte.
A des fins statistiques, je créé de manière analogue au système précédent une table alerte_promo_trouvee.

En essayant d'insérer une promo avec une photo plus lourde que prévue, je me rends compte que le loader ajax tourne indéfiniment,
et il n'y a pas d'erreur utilisateur qui apparaît : très frustrant.
Mon memory_limit est à 32M, l'image en question pèse 2,1Mo
Passer memory_limit à 128M permet de charger cette image (en local).
Mais cela ne résoud pas mon problème d'absence d'affichage d'erreur quand cela se produit…
L'erreur en question est une fatal error :
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 17152 bytes) in .../library/PhpThumb/GdThumb.inc.php on line 107

J'ai trouvé un workaround sur le net ::
http://www.phpcs.com/codes/UPLOAD-PHOTO-AVEC-REDIMENT-PIXELS-KB_37459.aspx

//Réaloue la mémoire dont le serveur à besoin
//*******************************************
$infos_img = getimagesize($tmp); 
$memoryNeeded = round(($infos_img[0] * $infos_img[1] * $infos_img['bits'] * $infos_img['channels'] / 8 + Pow(2, 16)) * 1.65);
$mem_in_use= memory_get_usage();
//echo "Mémoire utilisée : $memoryNeeded contre $mem_in_use

";
$test = (integer) ini_get('memory_limit') + ceil(((memory_get_usage() + $memoryNeeded) - (integer) ini_get('memory_limit') * pow(1024, 2)) / pow(1024, 2)) + 1;
//solution calculée
if(function_exists('memory_get_usage') && memory_get_usage() + $memoryNeeded > (integer) ini_get('memory_limit') * pow(1024, 2))
ini_set('memory_limit', (integer) ini_get('memory_limit') + ceil(((memory_get_usage() + $memoryNeeded) - (integer) ini_get('memory_limit') * pow(1024, 2)) / pow(1024, 2)) + 2 . 'M');


super, ça fonctionne!


11h45 : création du schéma sql pour les alertes.
sch-alerte4.png

Finalement, j'ai réfléchi un peu et supprimé la table alerte_promo_trouvee,
car toutes les informations sont retrouvables par des requêtes sql, cela évite donc de faire de la redondance de code;

De plus, j'ai pensé à l'évolution et à la maintenance du système : 
le nouveau principe est de gérer l'alerte de manière plus générale :
un utilisateur écoute le "canal virtuel" d'un commerce.
Toutes les activités du commerçant (ajout de promo, ajout d'événement, ajout de cadeau, et plus plus tard…)
transitent par ce canal.
Créer une alerte_commerce, pour un utilisateur, revient à écouter potentiellement toute l'activité de ce dernier.
Concrètement, l'utilisateur a ensuite le choix de s'abonner à tel ou tel "service".
Un service étant un sous-partie définie d'un canal.
Il y a actuellement 3 services : promo, evenement, cadeau.
Dans le futur, il pourra y avoir plus de services, et le principe d'abonnement à un ou plusieurs service(s) du canal d'un commerçant 
reste inchangé;

Visuellement, je pense à des checkbox pour l'utilisateur, il coche promo, mais pas événement, ni cadeau, par exemple.
cf patch sql en fin de fichier pour plus de détails sur la structure sql

11h58 : création de la table alerte_commerce

12h27 : amélioration du schéma, 
sch-alerte5.png

Le nouveau schéma est prévu pour répondre à la problématique suivante, ignorée dans le schéma 4 :
Comment faire en sorte de ne pas alerter l'utilisateur 2 fois pour une simple modification de produit.
Avec notre schéma 4, et le itemupdatedesign installé dans le formulaire de promo, une modification de promo
entraînerait le lancement d'une autre alerte.
Ici, avec le schéma5, la technique prévue est la suivante :

Question 1 : l'utilisateur est-il abonné au canal de l'utilisateur ?
$listOfAbonnes = getAbonnedUserListByIdCommerceService($id_commerce, $code_service); // ici le service est par exemple promo

Cela nous retourne la liste des abonnés au service, sachant qu'un commerçant n'utilise forcément qu'un seul service à la fois :
soit il ajoute une promo, soit un cadeau …

2. Filtrer les utilisateurs qui ont déjà reçu cette alerte.
$toSendList = filterAlreadyRegiteredToThisObjectId($listOfAbonnes, $obj_id); // retourne le tableau des utilisateurs à qui il faut envoyer un message

Cela nous permet d'encapsuler la logique de filtrage, par exemple, si on voulait dire que au bout de 20 minutes, on accepte à nouveau
que l'envoi s'effectue, on pourrait le faire à l'intérieur de la fonction.

3. Envoyer les alertes 
sendAlerteCommerceFromList($toSendList);

12h58 : musique


14h12 : Tours annonces

15h19 : les 3 fonctions sont codées.

douche

16h45 : Comment permettre à l'utilisateur de choisir un commerçant ?
une liste déroulante ne serait pas adaptée à un nombre trop important de commerçants.
Je vais faire un autocomplete.


18h : sieste (trop fatigué)

19h13 : Joomla!
Mise en place d'un slider très pratique
http://zecommerce.fr/declochez/

20h49 : Tours annonces (je ferais Maya après)

00h15 : ca y est j'ai fini pour la partie technique pour les alertes sur les commerces.
J'ai rajouté une 4ème fonction pour des raisons de propreté de code :
updateAlerteCommerceHistoryFromList($filteredList, $id_commerce, $id_item);

Mise en ligne.

00h24 : la mise en ligne s'est effectuée sans souci.
J'ai regroupé les alertes dans la section alerte de mon compte.
Il faudra mettre à jour le tutoriel sur l'ajout d'alerte pour les annonces, ainsi
que créer un nouveau tuto pour l'ajout des alertes des commerces.
Je ferai également une doc écrite, pour moi, et disponible sur le site.

Malgré tout, je considère la tâche comme finie et je vais cocher la case dans évolution,
car le système est fonctionnel.

Je vais me finir sur maya.

C'était ling, la fourmi du web, over. 





CREATION D'OBJETS
Tan_Private_AlerteCommerce


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`.`alerte_commerce_utilisateur_history` (
  `id` INT(11) NOT NULL AUTO_INCREMENT ,
  `utilisateur_id` INT(11) NOT NULL ,
  `commerce_id` INT(11) NOT NULL ,
  `code_service` TINYINT(4) NOT NULL ,
  `obj_id` INT(11) NOT NULL ,
  `date` DATETIME NOT NULL ,
  PRIMARY KEY (`id`, `code_service`, `commerce_id`, `utilisateur_id`, `obj_id`) ,
  INDEX `fk_alerte_commerce_utilisateur_history_utilisateur1` (`utilisateur_id` ASC) ,
  INDEX `fk_alerte_commerce_utilisateur_history_commerce1` (`commerce_id` ASC) ,
  CONSTRAINT `fk_alerte_commerce_utilisateur_history_utilisateur1`
    FOREIGN KEY (`utilisateur_id` )
    REFERENCES `tan`.`utilisateur` (`id` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_alerte_commerce_utilisateur_history_commerce1`
    FOREIGN KEY (`commerce_id` )
    REFERENCES `tan`.`commerce` (`id` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB
DEFAULT CHARACTER SET = latin1
COLLATE = latin1_swedish_ci;

CREATE  TABLE IF NOT EXISTS `tan`.`alerte_commerce` (
  `id` INT(11) NOT NULL AUTO_INCREMENT ,
  `utilisateur_id` INT(11) NOT NULL ,
  `commerce_id` INT(11) NOT NULL ,
  `statut` CHAR(1) NOT NULL COMMENT '		' ,
  `date` DATETIME NOT NULL ,
  `titre` VARCHAR(255) NOT NULL ,
  `abonne_promo` CHAR(1) NOT NULL ,
  `abonne_evenement` CHAR(1) NOT NULL ,
  `abonne_cadeau` CHAR(1) NOT NULL ,
  PRIMARY KEY (`id`) ,
  INDEX `fk_alerte_commerce_utilisateur1` (`utilisateur_id` ASC) ,
  CONSTRAINT `fk_alerte_commerce_utilisateur1`
    FOREIGN KEY (`utilisateur_id` )
    REFERENCES `tan`.`utilisateur` (`id` )
    ON DELETE CASCADE
    ON UPDATE NO ACTION)
ENGINE = InnoDB
DEFAULT CHARACTER SET = latin1
COLLATE = latin1_swedish_ci;


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