Archive for category détails techniques

Mauvaises décisions et conséquences

Constat d’Echec

Il m’arrive de temps à autre de relever la tête afin de regarder où j’en suis. C’est ce que j’ai fait hier soir et c’est un constat d’échec qui s’impose :

L’application ne sera pas prête dans les temps pour une participation au concours de google.

Le plus décevant est de voir l’état d’avancée actuel du projet par rapport au temps passé dessus.

J’avais pu atteindre quelque chose de presque démontrable pour le concours SFR. Cela n’est absoluement pas le cas pour le concours google. La partie serveur et backoffice ont pris énormément de retard. Aucun développement n’a été effectué sur la partie mobile.

A l’origine de ce constat d’echec, de mauvaises décisions prises en amont que je vais essayer d’analyser ici. Je me remonte le moral en me disant qu’un bon plantage correctement analysé vaut bien 10 réussites chanceuses.

J’ai inclu trop de nouvelles technologies

J’ai confondu projet avec un objectif précis et projet boite de pétri pour tester des technologies nouvelles qui m’attirent.

En soit, tout le projet WYDW est une boite de pétri pour tester et apprendre à développer sous android. Mais petit à petit, c’est également devenu un projet réel dans lequel je voyais un objectif de plus en plus précis. J’aurai donc du avoir une approche plus pragmatique.

J’avais eu  beaucoup de chances au cours de la première itération du projet (jusqu’au concours SFR). J’avais inclu plusieurs technologies que je connaissais pas avec beaucoup de succès (Android, et une connectivité au serveur très légère grace au design Rest). Le tout m’avait permis de développer une partie serveur très rapidement. Mise à part pour android et rest, j’étais dans les technologies que je manipule au quotidien et mon efficacité fut optimale.

Pour la seconde itération, j’ai voulu essayer d’utiliser la nouvelle infrastructure de serveurs proposée par Google : L’appEngine. Cette infrastructure possède l’énorme avantage de fournir gratuitement (jusqu’à un certain niveau) des serveurs java du même type que ceux utilisés par google. Cette infrastructure permet de répondre aussi facilement à 1 requete/seconde qu’à 10000 requête/seconde. Elle permet aussi d’avoir beaucoup moins d’arrêts de service que mon petit serveur loué sur dedibox. Son développement semblait également assez facile et son couplage très facile avec GWT (une technologie frontale très adaptée au backoffice que je souhaitais également utiliser) avait fini de me convaincre de l’utiliser.

Utiliser L’appEngine fut la plus grosse erreur du projet

Essayer l’appEngine était logique. Mais je n’aurai pas du insister face aux implications que l’utilisation de ce service imposait sur le projet. Cela m’a imposé de purement et simplement recommencer la partie serveur à zéro. Pire encore, j’ai plusieurs fois eu l’illusion de toucher au but avec des coeurs d’applications qui fonctionnaient mais au final une contrainte supplémentaire m’imposait de tout changer.

Quand j’ai finalement réussi, la semaine dernière, à avoir un backoffice prometteur qui fonctionnait sur ma machine de développement je me suis apperçu que cela ne fonctionnait pas sur les serveurs de google et ne pourrait pas fonctionner. J’ai du à nouveau tout changer.

J’ai le sentiment d’avoir passé mes dernières semaines à jongler avec les problématiques imposées par l’appEngine. C’est un peu comme d’essayer de recouvrir une grande table avec une nappe trop petite. Vous arrivez près d’un bord, vous tirez la nappe et ca découvre l’autre coté de la table. Vous en faites le tour, vous tirez la nappe et vous découvrez à nouveau l’autre coté. Après de nombreux essais, vous arrivez à tourner la nappe de façon à ce qu’elle recouvre toute la table. Mais au moment d’installer la nappe sur la vrai table, vous vous appercevez que la vrai table n’a pas la même forme que celle sur laquelle vous vous êtes essayé un certain nombre de fois.

Il y a quelques succès :

GWT fonctionne à merveille. Il me permet d’avoir un frontal web qui ressemble à une application executée par le système. Voici un exemple qui fonctionnait avec le code d’il y a quelque semaines (une contrainte supplémentaire a cassé le tout.) Cet exemple n’a rien d’impressionnant. Il s’agit juste de l’implémentation des mockup balsamiq dont je parlais dans un billet précedent. J’étais très enthousiaste après avoir réalisé cela car le code sous jacent à cet exemple est très simple à comprendre et possède beaucoup de potentiel. Je pensais arriver très rapidement à développer le reste. C’était faux car une contrainte n’ayant rien à voir avec la partie GWT m’a bloqué par la suite.

J’ai également pu découvrir gson, et dozer. Deux librairies que je ne présenterais pas ici mais qui m’ont agréablement surprises et qui sont un succès à garder.

Je n’ai pas mis assez d’effort dans le recrutement

Le billet sur le recrutement sur le site n’avait servit à rien. (en mm temps personne ne visite ce site :-P ). J’en avais parlé sur twitter et mon post a été retwitté plusieurs fois. J’ai eu, suite à cette annonce, une vingtaines de visites inconnues sur le site. Pour recruter, j’ai surtout misé sur des gens de ma société de service (très portée sur les technos google) et j’ai effectivement eu une candidature interessée.

Après 3 semaines la personne n’avait toujours rien codé. Suite à une petite discussion il s’est avéré qu’elle preferait abandonner.

L’un des administateurs de Frandroid, un blog ayant plusieurs milliers de visites par jour, m’avais proposé de faire un post de recrutement sur frandroid. Je n’ai jamais saisi cette occasion et c’est un tord. J’aurai du.

De façon plus globale je me suis trop focalisé sur le développement et pas assez sur l’aspect managerial du projet.

Et maintenant ?

Même si le moral n’est pas vraiment là, je refuse de laisser partir en fumée tous les efforts que j’ai placés dans le développement de cette application. WYDW ne me rapportera toujours aucun copec, mais elle doit sortir pour que je puisse l’utiliser comme vitrine sur mon CV.

Coté développement, soit je continue à insister pour l’appEngine, soit je repasse sur mon ancien système et j’y ajoute GWT. Je pense que je vais choisir la deuxieme solution. Cela va engendrer des contraintes désagréables car GWT s’intègre assez mal à mon ancienne architecture, mais cela devrait avoir au moins l’avantage de fonctionner.

Changement de cap mon capitaine !

3 Comments

Premier retours sur la Network Based Localization

Web Your Daily Way est une application qui vise à surveiller pour vous les transports que vous prenez au quotidien.

La localisation est une fonctionnalité centrale

Un certain nombre de ses fonctionnalités utilisent la localisation :

  • Afin de savoir quand démarrer le suivi de votre trajet
  • Afin de savoir quand stopper le suivi de votre trajet
  • Tout le long de votre trajet, a chaque étape.

Il existe 2 types de localisations avec android : Le GPS et la network based localization. Le GPS consomme beaucoup d’énergie et est donc coupé la plupart du temps.  La network based localization se base sur une triangulation des cellules GPRS environnantes afin de déterminer votre localisation. Cette méthode est moins précise que le GPS mais même imprécise, elle a le mérite de pouvoir être disponible en permanence et même accessible depuis l’intérieur d’un bâtiment.

J’ai lancé le projet Web Your Daily Way sans avoir eu de retours sur la qualité de la réception et je m’attendais donc à ce que l’imprécision soit importante. Aucune faisabilité n’avais toutefois pu être faite pour la réalisation du prototype (actuellement fonctionnel).

Par ailleurs même si plus de la moitié de la population mondiale qui prend les transports en commun prend des bus, je souhaite que l’application fonctionne également dans les métro et les trains de banlieues (type RER)

Premiers tests de la network based localization

J’ai récemment reçu mon HTC Magic et j’ai commencé à tester la network based localization fournie par défaut avec le téléphone. Premier constat : Elle est effectivement très imprécise (même à l’exterieur).

Devant la gare de RER de Nogent sur marne, elle se trompe d’environ 300 mètres.

Une fois arrivé devant la station du métro 1 chateau de Vincenne, elle a une bonne précision et me positionne effectivement à quelques dizaines de mètres de ma position.

Une fois arrivé à mon travail, mon téléphone se trompe d’environ une rue soit une centaine de mètres. ce qui est tout à fait correct.

Le problème viens de l’intérieur du métro : Mon téléphone passe en Edge et me situe au niveau du centre du 11° arrondissement alors que je ne suis même pas dans paris. Une telle utilisation à l’intérieur du métro se révèle donc totalement inutile car la précision est de l’ordre de 3 ou 4 km…

La bonne nouvelle est qu’une fois sorti du train, il me situe avant même d’être sorti de la station au bon endroit (à 200 mètres près)

J’ai également testé le GPS depuis un bus. Ce dernier a une précision absolument diabolique de l’ordre de 5 mètres en périphérie du bois de Vincennes.

Conclusion de ce premier test

Il s’agit d’un test préliminaire peu éloquent car je n’ai testé que les environs de Paris et le métro sur seulement 2 stations. Je pousserai donc les tests plus loin

La précision de la network based localization du téléphone a été en dessous de mes espérances et remet sérieusement en cause le suivi de temps inter stations à l’intérieur du métro. Je vais aller tester d’autres stations mais si ce diagnostique se confirme il sera impossible de surveiller la vitesse du trajet à l’intérieur d’un couloir de métro (même en station, tant que la personne ne sors pas du train)

Les points du trajet ayant une localisation exploitable seraient alors :

  • Les stations nécessitant de sortir du train (pour un changement de ligne)
  • Les points de départ et d’arrivée avec une imprécision de l’ordre de 300 à 500 mètres (suivant l’urbanisation de la zone)

Toutefois un point est encourageant: le GPS est bien plus précis que prévu. La network Based Localization pourrait donc être utilisée pour piloter l’activation du GPS afin d’être précis sur l’heure d’entrée dans la station de départ et d’arrivée.

Une autre piste serait d’utiliser la localisation fournie par l’API SkyHook qui est annoncée être plus précise que la localisation par défaut de google.

Affaire à suivre…

No Comments