Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

Technique

  • "envoyé depuis mon iPhone" : phonegap & Co


    Si vous êtes blogger hautetfort ou Blogspirit, vous avez peut-être lu ici ou là qu'une application iPhone était en préparation. Voici les coulisses de la préparation de cette nouveauté.

    Nous avions dans un premier temps la ferme intention de sous-traiter ce développement (partie client). Il fallait aller vite, être efficace. Nous avons lancé un appel d'offres sachant que travailler avec nous sur ces sujets est signe de travail récurrent. Nous avons reçu une vingtaine de réponses de 3000 euros à presque 30 000 ! Les uns, ne donnant guère de garanties et les autres franchement exorbitants. Même 15 kE, pour une offre sérieuse, nous semblait trop cher car le périmètre est limité à 7 services à intégrer (3 fonctions en réalité).

    Comment faire pour développer une application sans connaissance des SDK iPhone ou Androïd ?
    Finalement, nous étions en short list avec des prestataires et un ami me parle de PhoneGap, un logiciel open source qui permet de générer une appli iPhone ou Androïd en écrivant du Javascript et du html avec l'avantage d'être portable iPhone, androïd et BlackBerry. Très intéressant. 
    De nature curieuse, je demande à un développeur de me faire une étude faisabilité et un prototype ainsi qu'une étude comparative avec d'autres concurrents.
    PhoneGap ne transforme pas du Javascript en code natif. Simplement, phone gap utilise un web kit. En somme, en démarrant l'appli, vous ouvrez un navigateur qui lit le html et interprète le Javascript. PhoneGap possède une librairie basée sur jquery qui permet de dialoguer avec des webservices et surtout l'appareil photo, la géolocalisation, l'accéléromètre, ... Comme standard de dialogue nous avons retenu json qui est peu verbeux et facilement lisible en Javascript. Nous avons retenu cette solution.

    A quelques jours du lancement, Apple a lancer son nouveau SDK, son nouvel iOS ce qui a provoqué des bugs et des difficultés pour compiler PhoneGap avec la version iOS. Nous avons choisi d'attendre la nouvelle release de PhoneGap. Cette contrainte nous l'avons découvert alors que nous étions dans les starting block du lancement dans l'appstore ! A l'inverse, nous pouvons dire que la mise à jour de phone gap nous fait économiser du temps puisque si nous avions développé un code natif nous aurions été obligé de prendre à notre charge le debug. Cette mise à jour a couté 4 mois de retard au projet. Une fois les solutions trouvées, il faut remobiliser l'équipe, trouver des créneaux. Dure !

    Nous avons lancé il y a quelques jours la soumission dans l'appstore. Il faut dire que cette soumission est un véritable examen de passage ! Nous avions peur que PhoneGap ne soit pas considéré par Apple comme un service fiable. Nos lectures sur internet sont sans appel, pas de problème avec cet outil ! Nous avons été retenu du premier coup. Bravo !

    Pour conclure, je retiens cependant une règle capitale dans le choix de la solution qui se résume à une question pour un éditeur de service comme nous : l'appli mobile est elle stratégique pour le business modèle du projet ?
    - non, c'est seulement un plus. On gagnera à sous traiter l'appli.
    - oui, mais les mises à jour sont peu fréquentes et les évolutions seront rares (release semestrielle). Un outil comme PhoneGap sera adapté.
    - oui, mais les ambitions de l'appli amène à des mises à jour régulières. Développer une appli en natif en conservant la MOA et la MOE en interne me semble plus adapté.

  • Mener un diagnostique ou une étude SEO

    seo-online.pngA la demande d'un clients, nous avons réalisé une étude SEO de sa plateforme de blogs. Cette plateforme c'est plusieurs centaines de milliers de blogs actifs, une communauté très "pushy". Une telle étude est normalement vendue entre 20 et 30 kEuros mensuels avec les recommandations. On pourrait considérer que nous sommes juge et parti. L'idée était ici d'être sans complaisance sur notre produit. La confiance avec notre client est telle que nous avons joué la transparence. Nous n'avons pas non plus assassiner le client point de vue tarif. Même si je connais un peu ce domaine, c'était une première. Je vous livre ici les repères importants d'une telle étude.

    Nous avons présenté 3 volets :
    - une analyse de Logs des serveurs
    - une étude sur la base du crawl d'un blog
    - une synthèse sur l'indexation des contenus


    Analyse des Logs des serveurs web
    Nous avons développé un outil qui récupère les log des serveurs les stocke en base de données et les parse pour extraire date, heure, pages, ... Nous en profitons pour ajouter un critère de type de pages (calculé en fonction du format de URL).

    Cette étude est quantitative. Les projections de ces valeurs permettent de definir des critères qualitatifs.
    Dans cette phase, Googlebot est notre invité, il s'agit d'obtenir un feed-back de la manière dont il a été accueilli. Les serveurs Apache délivrent des Logs de chaque visite. Chaque visite est faite sur une URL, renvoi un statut de réponse (exemple : 404, les pages not found), ...
    Il importe de savoir sur quelle page googlebot se rend et sur les quelles il ne va pas, s'il y a des pages en erreurs, etc...


    L'analyse de crawl
    Il s'agit là de réaliser un crawl à la manière de googlebot. Il s'agit là de déterminer ce que Google a bien pu manger ! Nous calculons une batterie de statistiques comme :
    - nombre de liens internes externes follow nofollow.
    - nombre de paragraphes, de mots, de média
    - nombre de duplicate content
    - poids des pages / poids utile ou sec
    - temps de téléchargement
    - profondeur sur le site (lien à x clic de la home).
    - ...
    Ces données extraites donnent des informations capitales sur le comportement des blogs.

    La synthèse d'indexation
    Elle consiste à vérifier que le contenu est bien dans l'index de Google ou non.
    Le top est de pouvoir suivre des mot clef et leur positionnement.

    Recommandations
    À l'issue de ces trois volets, nous avons émis des recommandations, des fonctionnalité à mettre en place, des petites choses pour améliorer l'expérience utilisateur, diminuer le taux de rebond, favoriser la diffusion du page rank interne, corriger quelques bugs apparaissant dans des cas limites, ...

  • La règle du ticket d'entrée dans des chantiers lean

    Dans nos petites entreprises, "faire d'une pierre deux coups" n'est pas simplement un besoin, ce doit être une stratégie obsessionnelle. Voici un exemple d'approche Lean pour éliminer le Muda de niveau 1 dans les start-up et chez les éditeurs de logiciels.

    Problématique : désengorger les serveurs de fichiers.

    L'arrivée de gros clients potentiels nous ont obligé il y a 6 mois à se pencher sur certains points faibles de notre architecture.

    Le brainstorming

    Il y a six mois, je découvre un projet d'entreprise sur l'installation de Mogile FS. C'est un software juste génial qui dispatche des fichiers sur plein de serveurs pour équilibrer la charge.

    En réfléchissant et en faisant le point sur les autres chantiers, je découvre un autre projet d'exploitation super intéressant : le packaging logiciel (façon d'encapsuler des fichiers sources de logiciel pour en faciliter le déploiement, en l'occurence package Debian).

    Comme on peut pas tout faire en même temps, il est décidé de faire un rapide comparatif (je vous la fait courte).

    Les moins

    Les plus

    Mogile FS

    - intégration longue et r&d pas évidente

    - cache de fichiers statique via memcache déjà en place

    - ticket d'entrée élevé (6 mois)

     

    - diminuer les accès disques des fichiers statiques sur les serveurs de fichiers

    - supprimer un spof*

    - stimulation de bosser sur des techno hypes (faut bien motiver ses troupes)

    Package

    - changer de système de versioning (plus rapide)

     

    - limiter les accès disques des fichiers dynamiques

    - amélioration des temps de chargement des pages meilleurs

    - ticket d'entré faible (3 mois) : (1 produit packagé)

    - stabilité de l'exploitation

    Il s'avère que les deux projets de nature différentes semblent avoir en partie les mêmes objectifs. Pour se persuader de la priorité, il convient d'étudier l'impact de la mise en place de l'une et l'autre des solutions. On cherchera à savoir pour l'affichage d'une page quel est le stress sur le serveur de fichier engendré par l'appel des fichiers dynamiques et celui des fichiers statiques. En première approximation nous considérons le nombre d'accès disque.

    Je vous passe l'étude technique et financière et passe au choix qui a été décidé.

    Le choix stratégique :

    Au final, nous avons retenu le chantier packaging comme prioritaire. L'étude a montré que l'importance de ne pas centraliser les fichiers des software est prépondérante. Deplus le ticket d'entrée est plus faible. En cas d'arrivée d'un nouveau client, il a été décidé d'investir (ou location) dans un serveur de fichier supplémentaire (netapp pour 50kE qui équilibre l'installation de Mogile FS) si les gros clients sont finalement signés le temps de mettre en place MogileFs qui sera d'abord installé pour les nouveaux produits logiciels ce qui diminue le ticket d'entrée. La migration des soft existant serait trop couteux.

    Le choix du système de packaging à fixer comme premier palier la mise en place d'un nouvel outil de versionning (Bazaar) qui permet de gérer les images contrairement à notre ancien outil. Nous avons mutualisé les efforts pour diminuer le ticket d'entrée et avons cherché à dimuner le muda de niveau 1 (voir méthode lean). En effet, installer un outil de versionning n'apporte aucune valeur ajoutée au produits logiciels que nous vendons, c'est donc du gâchi, qu'il faut éliminer. Deplus l'investissement permet une efficacité dans l'exploitation au quotidien (encore du muda de niveau 1 éliminé).  La deuxième étape reste aujourd'hui de mettre en place le packaging logiciel.

    Conclusion :

    En conclusion, dans nos start up, les patrons nous demande toujours de délivrer plus vite. Côté technique une contrainte essentielle pour moi est le ticket d'entrée d'un projet doit toujours être inférieur à 3 mois.