Refusé d’un job à plein temps car « autodidacte » pour ce qui est de PHP j’ai pu néanmoins apprendre des erreurs. L’autodidacte, quand il a une idée crée un modèle sur un besoin particulier, sans forcément penser à l’expension du-dit projet.
Montreuil.net, dans sa première version, était un amas de fichiers PHP, certes optimisés en terme de « requêtages SQL », de protections de tous types (à défaut d’un cluster en cas d’attaque DoS). Bref, il faisait ce qu’on lui demandait et a su faire face à deux attaques majeures (allez savoir).
Mais il s’est avéré que la création de montreuil.net dans sa prochaine version n’est pas exempt de problématiques assez lourdes du fait de son aîné.
En effet, cette seconde version nécessite une réorganisation de toute la hiérarchie de dossiers, d’un outil orienté objet « home-made » afin de prévoir l’arrivée d’une API-maison pour les partenaires, de mettre en place Smarty et ses dossiers cache, templates, etc… Enfin, ZE problématique; cette première version n’étant pas basée sur un Framework, du moins rien de sain, l’évolution notable des bases de donnée implique une foultitude de nouveaux champs, de nouvelles tables. A savoir qu’actuellement, j’ai un environnement de production (sur le serveur OVH) et un en local de dev, sur lequel j’adjoints ces modifications SQL conséquentes, mais pour ne pas me farcie des saisies dans tous les sens, je fais des dump SQL réguliers de la prod à la dev, mais je jongle avec difficulté entre les imports et ses risques de récurrence, ainsi qu’avec les tables désormais multi-formes.
Pas de scripts de dump personnalisés, tout à la mano.
Amis développeurs, prévoyez toujours un environnement sain, prévoyez un bon 30% de temps de développement initial d’un, projet à sa capacité à évoluer au fil du temps. Bon gré, mal gré, montreuil.net remporte un certain succès mais tellement de choses assez désagréables entachent son expansion, ce qui m’a amené prématurément à entamer cette nouvelle version, avec le lot de soucis techniques inhérents.
Enjoy !
PS : merci aux soutiens par mail, par le biais du formulaire de contact sur le site et ceux de Facebook?
(billet technique)
Peu de mises-à-jour depuis un temps mais beaucoup de travail « dans l’ombre ». Mon CV n’a toujours pas fait réagir à la mairie de Montreuil… à suivre (j’ose pas rappeler dans l’immédiat).
Bref, SMARTY ! Depuis quelques années, je vais et viens sur ce concept de développement, ce moteur de template. A défaut d’adopter une autre techno comme Symfony (oui, c’est pas un template engine mais bon), je me suis dit qu’on pourrait y gagner sur un projet de cette ampleur (grand mais pas trop non plus). Smarty permettra un gain de ressources; grosso modo, lorsque le site monte en charge, j’ai mis un système de cache bien sympathique avec un gain probable de 70% de requêtage SQL et encore d’avantage sur les source. Couplé à un CRON efficace pour les appels XML vers l’extérieur, la somme des efforts devrait payer.
Autre avantage, j’ai refactorisé et bien séparé toutes les couches code et rendu, m’ouvrant en grand les possibilités de portage en live pour les mobiles ou la version accessible. Tout le code du moteur (sans exception) a été revu, offrant un maximum d’abstraction et mon petit pêché mignon serait de mettre en place une platerforme SOAP, why not ?
Enfin, à terme, cela permettrait (j’y songe) à ouvrir des possbilités de personnalisation poussées pour les utilisateurs, y compris les développeurs ainsi que les futurs blogueurs de la plateforme montreuil.net souhaitant intégrer des modules sur leurs blogs respectifs. C’est pas du Netvibes à la sauce montreuil.net… ça sera juste un défi personnel mais surtout la possibilité d’impliquer les utilisateurs et les mettre en position de « proposeurs » de nouveautés.
To be continued…
Et arrête de me regarder avec cet air sévère… je vais mettre en place le cron… maintenant est-ce que ce sera sur la prochaine version ou l’actuelle ? Je me tâte.
Si vous êtes non-informaticien, le but est d’éviter ça :
(dans l’immédiat, je viens de mettre en place une petit message au lieu de cette erreur barbare)
Dans une version que je pourrais qualifier de bêta 0.8 (me demandez pas pourquoi), le Vélib’ montreuillois est désormais officiellement pris en charge sur montreuil.net. Ouf !
C’est le fruit de plein de problématiques cumulées aux problématique persos. Profitez-en déjà, c’est fonctionnel pour ce qui est des stations montreuilloises.
Maintenant un peu de techniques pour les connaisseurs, les autres pourront passer leur chemin.
Comme vous pouvez le constater, le chargement du module Vélib’ est immédiat (ou à peu près), et bien en fait. Non, car comme vous pouez l’imaginer, il y a de l’Ajax.
Dans sa première version je faisais un appel avec la bibliothèque simplexml sur le bon vieux flux xml Vélib’ de la mairie de Paris, récoltais les stations et parsais à la volée. Temps de chargement de malade, il me fallait faire de l’Ajax, pour que le reste de la page se charge sans passer par ce point obligatoire (comme pour la météo).
Mon fichier Ajax appelé, chargeait toutes les stations Vélib’ et c’était toujours assez long. Le but étant à finalité « communautaire », je me suis dit qu’il serait peut-être plus sympa de ne se focaliser que sur les stations montreuilloises dans un premier temps.
Voici le petit inventaire que j’ai fait après récupération du XML global Vélib’ :
PARIS 1 : 31007 – 63/65, rue de Paris
PARIS 2 : 31005 – 127/129, rue de Paris
PARIS 3 : 31004 – 175/179, rue de Paris
PARIS 4: 31003 – 237/241, rue de Paris
REPUBLIQUE 1 : 31002 – 38, rue de la République
REPUBLIQUE 2 : 31006 – 2/4, place de la République
CENTENAIRE : 31013 – 8, rue du Centenaire
DE GAULLE : 31009 – 13/15, place du Général de Gaulle
LAGNY : 31001 – 96, rue de Lagny
STALINGRAD 1 : 31010 – 67/69, rue de Stalingrad
STALINGRAD 2 : 31011 – 27, rue de Stalingrad
CARNOT : 31012 – 35/37, rue Carnot
VINCENNES : 31008 – 7 bis, rue de Vincennes
J’ai mis les noms de manière totalement arbitraire, ceux proposés par défaut dans le fichier n’étaient pas, dans tous les cas, particulièrement intéressants.
Ensuite, il fallait récolter le détail de chaque station sur des XML distincs, exemple pour la station PARIS 1 :
http://www.velib.paris.fr/service/stationdetails/31007
qui nous donnait :
<?xml version="1.0" encoding="UTF-8"?> <station> <available>20</available> <free>2</free> <total>25</total> <ticket>1</ticket> </station>
Après, tout roule. Mais la question de départ revient. Etant donné que dans des flux uniques (par station), je n’ai pas l’adresse ou les informations complémentaires (bornes bonus par exemple)… comment faire ? Et comme demain, je proposerais une nouvelle carte complète des stations Vélib’, avec possibilité de personnaliser SES stations favorites, il serait peut-être intéressant de charger le flux parent ?
Ceci est actuellement en réflexion, en vue de la prochaine version.
Jusqu’à présent, ceci était le cadet de mes soucis… l’aîné étant l’appel de multiples instances d’ajax (une par station affichée). Chaque fois qu’une ligne de station était affiché, c’était autant de fois que la fonction ChargeVelib() était appelé. A chaque appel de cette fonction, c’est une même variable qui se retrouvait écrasée par sa précédente occurence non chargée.
Il m’était possible d’imposer des pauses dans l’exécution du javascript mais ça ralentirait la chose.
Finalement, ma meilleure solution est la suivant et je me pose la question de savoir si elle est suicidaire ou non.
A chaque station (stockée dans un tableau PHP), une fonction JS unique est générée, avec ses propres variables uniques. Ça permait d’éviter les occurences doublonnées et donc de ne plus avoir ces soucis de chevauchements d’instances.
Deux inconvénients :
- Ça file une plus grosse charge sur les navigateurs mais… soit, ce n’est pas la mer à boire.
- Ça fait des appels PHP conséquents mais comme je compte mettre un maximum de stations favorites et un système de cache (avec Smarty) en version 2… wait & see.
A suivre…
Commentaires