Ma remarque "Je veux bien comprendre pourquoi tu désapprouves" était une affirmation Je ne me permettrai pas de te parler comme ça ! Mais tu soulèves un point intéressant : ceux qui n’ont pas Facebook. Ils sont nombreux. J’ai pensé à l’intégration d’une connexion par SMS mais un problème majeur me gêne :
Ceux qui se connectent par Facebook doivent impérativement donner leur numéro de téléphone pour qu’ils puissent être trouvé comme amis par ceux se connectant par SMS. C’est gênant car c’est quand même une autorisation Android très intrusive. Faut-il seulement donner le choix de donner son numéro ou alors oublier cette solution ?
Mais un chat dans l’application ne pourra être que plus nul que ceux déjà existants. En soit créer un bon système de conversation, c’est créer une application à part entière !
Il faut dire que je n’y connais pas grand chose dans ce "domaine". J’ai fais cet après-midi quelques recherches… Je suis prêt à abandonner mon idée d’intégration de Messenger si j’arrive à créer moi-même un système stable et complet! Je souhaite par contre rester sur du PHP si possible. Si tu as des conseils, je suis preneur . Je vais faire un tour sur les différentes solutions SNS/GCM/Pusher ce soir.
Pour moi, POST /account/update devrait être PUT /account, GET /account/infos devrait être GET /account, et POST /events/create devrait être POST /events : POST veut dire “créér une nouvelle ressource”, PUT veut dire “modifier une resource existante”.
J’ai donc regardé SNS, GCM et Pusher. Mon choix s’est rapidement porté vers GCM (maintenant appelé Firebase Cloud Messaging (FCM)) pour un critère simple : le prix. En effet, GCM est gratuit.
ajout de gcm_registration_id dans la table members
Les maquettes sont aussi impactées par l’intégration du système de conversation interne. Il faut ajouter une tab pour les messages.
J’ai sinon voulu mettre en ligne une partie de l’API pour que vous puissiez essayer mais il s’avère qu’il y a un problème avec mon nom de domaine zonny.me Je vous tiens au courant mais d’après 1&1 il y en a pour plus de 72H d’attentes.
Ce soir il y a du travail d’achevé sur l’API. Déjà quelques modifications dans le routing de l’API.
fusion de PUT/account et POST/account. Le travail effectué finalement par ces deux routes était identiques à l’exception que l’un créait le compte et l’autre l’actualisait.
suppression de la variable ’fb_user_id’ pour PUT/account et POST/account car se fier à cette variable serait une énorme "faille". N’importe quelle personne pourrait changer le ’fb_token_access’ d’un compte.
Il reste encore à gérer quelques expressions régulières afin d’empêcher les petits rigolos d’insérer n’importe quoi dans l’API, la gestion des erreurs possibles (base de données, SDK Facebook…) et tout le système anti-flooding/logs.
Remplacement de la fonction génératrice des tokens. Avant j’utilisais la fonction ’md5(uniqid(rand(), true))’ mais il s’avère que ce n’est pas sur comme fonction. Voici la nouvelle fonction : https://stackoverflow.com/a/13733588/8219923
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<?php/* from https://stackoverflow.com/a/13733588/8219923 */functiongetToken($length){$token="";$codeAlphabet="ABCDEFGHIJKLMNOPQRSTUVWXYZ";$codeAlphabet.="abcdefghijklmnopqrstuvwxyz";$codeAlphabet.="0123456789";$max=strlen($codeAlphabet);// editedfor($i=0;$i<$length;$i++){$token.=$codeAlphabet[random_int(0,$max-1)];}return$token;}?>
J’ai tout de même une question pour vous s’il vous plaît :
Pour la variable ’informations’, qui est censée contenir les informations concernant un événement, voici ma regex :
suppression de GET/events/photos. Cela prend trop de temps/ressources pour le serveur d’aller chercher les images sur Google. Il est préférable que ce soit le téléphone de l’utilisateur par le biais de l’application qui récupère les urls des images.
Il reste encore un petit peu de travail avant de pouvoir vous montrer le résultat :
Rappeler 1&1 et leurs mettre la pression pour qu’ils remettent le ndd zonny.me en état.
Modification de la base de données, ajout de ip et error dans logs et suppression de state dans events.
J’ai décidé de reporter certaines fonctionnalités pour les prochaines versions de ZONNY. Les fonctionnalités Rechercher un évent, Sélection aléatoire d'un événement ne seront pas présentes dans l’alpha (ni dans l’API pour le moment).
Je m’attaque à la documentation https://swagger.io/ afin que vous puissiez essayer
Elle sera en ligne dans les prochains jours (mercredi ou jeudi je pense). Il y a encore quelques petites choses à corriger (à chaque fois je trouve un truc de plus à faire ). J’ai remarqué après coup qu’il manque dans la route PUT/events/edit la possibilité d’ajouter ou supprimer un participant.
Oups! Merci j’avais raté une bonne partie de ces conseils, désolé @motet-a . Je crois avoir bien relu tes conseils, ça devrait être bon maintenant !
Aujourd’hui, c’est vérification (personnelle) du bon fonctionnement de l’API et corrections des erreurs. J’ai supprimé dans la table event : les champs state et messenger qui ne sont pas/plus utiles. Le champ event_id a été ajouté dans chat_rooms. Il faut encore que je rajoute la route DELETE/account qui permettra d’effacer toutes les traces d’un utilisateur puis les routes pour le chat.
Quelques petites questions (j’ai besoin de conseils svp!) :
Est-il utile que je catch les différents types d’erreurs comme PDO_EXCEPTION… ou je peux me contenter de seulement catch les Exception en général ? Finalement l’utilisateur se moque de savoir de quel type d’erreur il s’agit. "Erreur interne" pourrait faire l’affaire, non ? Surtout que chaque erreur est loggée…
Pour l’API je pensais prendre ce VPS ( https://www.firstheberg.com/fr/vps-windows-le-moins-cher à 2,38 TTC ) mais sachant qu’il ne s’agit uniquement d’un serveur PHP je pense qu’un hébergement mutualisé fera très bien l’affaire. Connaissez-vous des hébergeurs à me conseiller dans ces prix qui correspondraient ce projet ?
Est-il utile que je catch les différents types d’erreurs comme PDO_EXCEPTION… ou je peux me contenter de seulement catch les Exception en général ? Finalement l’utilisateur se moque de savoir de quel type d’erreur il s’agit. "Erreur interne" pourrait faire l’affaire, non ? Surtout que chaque erreur est loggée…
Par sécurité, il vaut vraiment mieux ne jamais afficher les détails des erreurs aux utilisateurs.
Création de la route DELETE/account qui supprime toutes les données liées à l’utilisateur : son compte, ses liens d’amitiés, les événements qu’il aura crée et les messages qu’il aura écrit deviennent anonymes. Les logs concernant l’utilisateur ne sont pas supprimés (dans le cas d’un problème ils peuvent toujours être utiles!).
Modification de la route PUT/events. Il est maintenant possible d’éditer les participants à un événement. Les ids envoyés dans invited_friend_id qui sont déjà invités seront supprimés de l’événement. Par opposition, ceux qui n’étaient pas déjà invités le deviennent alors.
Modification/Amélioration de la gestion de certaines erreurs possibles. Il reste encore quelques cas à traiter.
Je risque de ne pas être productif demain non plus malheureusement. J’essaierai quand même d’appeler 1&1 pour gueuler un peu !
Pour la petite histoire (dont tout le monde se fou probablement mais bon ) :
J’ai acheté le nom de domaine zonny.me en avril 2017. Cependant, récemment, il y a plus de deux semaines je décide de désactiver le renouvellement automatique de mon nom de domaine (histoire qu’ils ne facturent pas encore n’importe quoi!). Le nom de domaine devient alors en "En cours d’actualisation". Impossible de faire la moindre modification DNS.
J’appelle deux jours après le service client pour leur signaler le problème. Ils me répondent que le problème sera réglé dans les 48h suivantes.
72h après mon 1er appel, je décide de les rappeler : "Vous rappelez trop tôt, cela sera fait comme convenu dans 48h". Bon je décide de patienter en supposant que c’est peut-être moi qui ai mal compris.
72h après mon 2ème appel, je décide de m’énerver. "Excusez-nous, c’est mon collègue qui est nouveau qui n’a pas fait ce qui était nécessaire. Attendez 48h, et je vous promets que le problème sera réglé".
72h après mon 3ème appel, rien n’a changé. Histoire à suivre !
C’est une bonne idée, et j’espère que ton application marchera ! En revanche sâche qu’un poids lourd de l’industrie Facebook (française) prépare aussi de son côté une application totalement similaire.
Au niveau des features, je regrette absolument ta position sur le "tracking", dans le sens où c’est l’évennement qui devrait définir le lieu, indépendamment de la position des utilisateurs (non, je n’aime pas être stalker. :p).
C’est une bonne idée, et j’espère que ton application marchera ! En revanche sâche qu’un poids lourd de l’industrie Facebook (française) prépare aussi de son côté une application totalement similaire.
Merci pour tes encouragements et de me mettre en garde de cette future application ! J’imagine que tu parles de cette application https://itunes.apple.com/us/app/events-from-facebook-find-things-to-do-near-you/id1153443320?mt=8 ? Je ne la connaissais pas en effet. Je vais la surveiller de près J’ai quand même l’impression qu’il s’agit tout simplement de la fonction évents déjà présente dans l’appli Facebook (avec quelques fonctionnalités en plus), non ? Après je compte donner un aspect plus "amical", "familial" et "convivial" au projet que Facebook qui peut paraître assez "froid" (je suis plus très clair là je pense ).
Au niveau des features, je regrette absolument ta position sur le "tracking", dans le sens où c’est l’évennement qui devrait définir le lieu, indépendamment de la position des utilisateurs (non, je n’aime pas être stalker. :p).
Tout d’abord, je dois dire que je hais aussi les applications trop intrusives et qui permettent d’être stalké !. C’est pourquoi j’ai opté pour une localisation imprécise de l’utilisateur. Je ne suis pas sur de saisir exactement le c'est l’événement qui devrait définir le lieu.
Actuellement, pour faire un p’tit recap :
Les événements imprécis (qui n’ont pas été personnalisés et n’ont donc pas de nom, d’image ni de localisation) sont situés sur la carte à équidistance de tous les invités. Peut-être que faire à équidistance entre le créateur de l’événement et l’utilisateur seulement serait bien aussi ! A réfléchir.
Les événements précis sont situés sur la carte par rapport à l’adresse définie sur l’événement.
Non, celle-là est vraiment très formelle, je parle d’une boîte française en particulier, leur produit est moins "sophistiqué" ; il n’y a pas de calendrier au sens propre par exemple, en gros leur application montre simplement les évennements à proximité temporelle : c’est vraiment "on the go". Ils sont aussi dans une optique très conviviale, comme tu dis (et c’est une bonne chose de mon point de vue, enfin pour la cible). Après ce n’est pas une question de mettre en garde, juste de voir ce que font les autres et si ça marche.
(je ne sais pas si j’ai le droit d’en parler, ce projet est sujet à un lancement massif et programmé)
Je ne suis pas sur de saisir exactement le "c’est l’événement qui devrait définir le lieu".
L’idée c’est de ne pas montrer les connaissances à proximité, mais uniquement les évennements (et donc leur lieu [edit: et les gens qui y participent]).
Non, celle-là est vraiment très formelle, je parle d’une boîte française en particulier, leur produit est moins "sophistiqué" ; il n’y a pas de calendrier au sens propre par exemple, en gros leur application montre simplement les évennements à proximité temporelle : c’est vraiment "on the go". Ils sont aussi dans une optique très conviviale, comme tu dis (et c’est une bonne chose de mon point de vue, enfin pour la cible). Après ce n’est pas une question de mettre en garde, juste de voir ce que font les autres et si ça marche.
(je ne sais pas si j’ai le droit d’en parler, ce projet est sujet à un lancement massif et programmé)
Je vais essayer de continuer mes recherches pour tenter de trouver quelques informations à propos de ce projet, bien qu’il ne doit pas y avoir grand chose si tu ne sais même pas si tu peux en parler ! Sans indiscrétion, tu as un lien avec cette boîte ?
L’idée c’est de ne pas montrer les connaissances à proximité, mais uniquement les évennements (et donc leur lieu [edit: et les gens qui y participent]).
Je comprends mieux l’idée! Mais comment fait-on pour voir qui sont ses amis à proximité pour savoir qui inviter ? Car dans le cas d’un événement éphémère de 15 minutes par exemple, l’utilisateur a intérêt à savoir qui sont les amis à proximité de lui.
Bon sinon comme prévu, pas beaucoup d’avancement aujourd’hui non plus.
Sur l’API, la gestion des erreurs est maintenant terminée! Les erreurs sont maintenant loggées de manière plus précise pour une meilleure compréhension en cas de problème. Et comme conseillé par @motet-a les erreurs restent très "générales" et non "techniques" pour l’utilisateur.
J’ai ENFIN récupéré l’accès au domaine zonny.me (merci 1&1…). La question des prochains jours est l’hébergement. J’hésitais entre un VPS low cost et un hébergement mutualisé mais je pense finalement (contrairement au dernier message ) m’orienter vers le VPS. Celui-ci précisément : https://www.firstheberg.com/fr/vps-windows-le-moins-cher. Le grand avantage est quand même de pouvoir faire ce qu’on veut (enfin presque!).
Et qui dit récupération du nom de domaine, dit arrivé de l’API en ligne prochainement mais aussi de la Landing Page et donc d’un logo.
ZONNY avait déjà un logo mais je souhaitais le retravailler afin d’avoir des lettres plus grandes car sur une petit icone (icone de l’application) on ne les voit pas beaucoup. Cependant, je crois que la nouvelle version est pire que l’ancienne, non ?
Je ne suis pas convaincu qu’un serveur sous Windows soit la meilleure option pour ce genre de projet et de technologies. Ça n’apportera rien ou pas grand chose (si ce n’est une licence à payer en plus) par rapport à un serveur sous Debian ou autre CentOS (Linux, quoi). Enfin, si tu veux prendre la version Windows (ce que le lien met en avant).
Je ne connais pas du tout cet hébergeur donc je ne me prononcerai pas à ce niveau.
Pas vraiment, leur community manager est juste un très bon ami.
Mais comment fait-on pour voir qui sont ses amis à proximité pour savoir qui inviter ? […] l’utilisateur a intérêt à savoir qui sont les amis à proximité de lui.
Dans le cas des invitations, je crois bien que c’est fait indépendamment de la proximité. Ce dont je suis sûr en revanche c’est que les utilisateurs sont notifiés des évennements proches. Et sinon pour ce genre d’évennement -très- éphémère, je pense que l’intérêt principal c’est justement de ne pas se baser sur les invitations, mais sur l’envie des gens à proximité de l’évennement.
Pour le logo, l’ancien est en effet bien plus agréable à l’oeil.
edit : peut-être voir pour un entre-deux sur la taille, mais garder le même bleu foncé que l’ancien ?
Je ne suis pas convaincu qu’un serveur sous Windows soit la meilleure option pour ce genre de projet et de technologies. Ça n’apportera rien ou pas grand chose (si ce n’est une licence à payer en plus) par rapport à un serveur sous Debian ou autre CentOS (Linux, quoi). Enfin, si tu veux prendre la version Windows (ce que le lien met en avant).
Merci de tes conseils ! Mais je te rassure, je n’ai jamais pensé prendre la version Windows Vu les config pour ce prix je vais m’orienter vers Debien. C’est léger, performant et sans suppléments inutiles (contrairement à Ubuntu qui a quelques logiciels pré-installés il me semble, non ?).
Je ne connais pas du tout cet hébergeur donc je ne me prononcerai pas à ce niveau.
Ha ouais nan, plus jamais 1&1 . Je vais prendre un mois seulement chez FirstHeberg pour essayer car les prix sont quand même très (trop peut-être…) attractifs. Pour mon petit budget pour le projet, c’est parfait ! Sinon, j’aurai seulement perdu 2,5€ et quelques heures de config. Je vous donnerai mon avis sur eux dans quelques jours/semaines.
Dans le cas des invitations, je crois bien que c’est fait indépendamment de la proximité. Ce dont je suis sûr en revanche c’est que les utilisateurs sont notifiés des évennements proches. Et sinon pour ce genre d’évennement -très- éphémère, je pense que l’intérêt principal c’est justement de ne pas se baser sur les invitations, mais sur l’envie des gens à proximité de l’évennement.
Ta vision est très intéressante. J’avais prévu une fonctionnalité secondaire (pour les prochaines mises à jours) qui consistait en la même idée. Mais comme tu me le montres, cette fonctionnalité est peut-être plus importante que je ne le pensais. Les scénarios auxquels j’avais pensé :
l’utilisateur maintient son doigt sur un point de la carte (ou touche seulement sinon l’utilisateur risque de ne jamais trouver cette fonctionnalité). L’activité de création d’un événement se lance (comme pour un événement normal sauf que tout le monde est invité). Une fois l’événement crée, tous les amis de l’utilisateur peuvent le voir sur la carte et s’y ajouter. Seuls les très bons amis de l’utilisateur (critère fourni par Facebook) ou les amis dans un certain cercle de proximité (à définir) sont notifiés.
L’utilisateur sélectionne les amis qu’il souhaite inviter à l’événement (comme un événement normal). Cependant il définit l’événement comme public avec la possibilité pour ses amis de demander à s’y incruster. Cependant cette solution est moins bien que la première car l’ami qui verra l’événement n’osera pas forcément demander à s’incruster ne se sentant pas "invité". Actuellement (dans le projet), quand l’événement est public, le créateur peut activer le mode possibilité pour mes amis de demander à s'incruster.
Les deux scénarios sont bien non ? Après trop de façons différentes de faire risque de perdre l’utilisateur…
Après, je pense tout de même que le système d’événements avec invitation est nécessaire. L’utilisateur n’a pas forcément envie que tous ses amis soient invités. Certains événements, en fonction du contexte, peuvent pousser l’utilisateur à ne pas inviter tous ses amis (Tony ne supporte plus Morgan etc).
peut-être voir pour un entre-deux sur la taille, mais garder le même bleu foncé que l’ancien ?
Pour l’essayer vous pouvez utiliser les différents tokens suivants :
test
test1
test2
test3
Vous pouvez tout essayer! Merci cependant de ne pas supprimer ces comptes. N’hésitez pas à nous faire part de vos remarques, suggestions…
La migration de MySQL vers Postgres a été un long travail… très long. En effet, beaucoup de requêtes étaient incompatibles avec Postgres (des conditions comme IF() qui devient case when then else end, des alias qui ne peuvent pas se situer partout dans la requête comme après le WHERE) ou encore la structure de la base de données qui demande des types de variables différents (varchar n’existe pas sous Postgres par exemple). Mais heureusement http://www.sqlines.com/online était là !
Les raisons de passer sous Postgres étaient Postgis mais surtout les benchmarks qui semblent montrer que Postgres est plus rapide lorsqu’il y a beaucoup de données (j’espère que c’est vrai et que j’ai pas fait tout ça pour rien ). Je dois dire que j’ai été agréablement surpris par Postgres. Certaines fonctions simplifient la vie comme par exemple COALESCE() (je ne connais pas d’équivalent sous Mysql en tout cas!).
Cependant j’ai rencontré beaucoup de difficultés dont 2 persistent :
Comment créer un alias après un WHERE ? Car par exemple j’ai la requête suivante :
La fonction va t-elle être exécutée 3 fois ? Y a-t-il un système de cache ou bien une solution plus adaptée ?
Dans l’API, la distance entre deux points est maintenant calculées par la fonction de Postgis ST_Distance(). Cependant j’ai l’impression que la distance retournée entre deux ST_Point n’est pas correcte. Je re vérifierai demain.
Merci d’avance pour votre future aide . Ce sera tout pour aujourd’hui sinon mais j’aurai d’autres questions pour demain ne vous en faites pas !
Connectez-vous pour pouvoir poster un message.
Connexion
Pas encore membre ?
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte
Je ne me permettrai pas de te parler comme ça ! Mais tu soulèves un point intéressant : ceux qui n’ont pas Facebook. Ils sont nombreux. J’ai pensé à l’intégration d’une connexion par SMS mais un problème majeur me gêne :
. Je vais faire un tour sur les différentes solutions SNS/GCM/Pusher ce soir. 
Merci au passage.
. Je crois avoir bien relu tes conseils, ça devrait être bon maintenant !
).
