Google se caractérise par une pauvreté fonctionnelle de prime abord dans l’interface exposée aux utilisateur, mais la puissance, la fiabilité, et la robustesse en font maintenant un outil globalement incontournable dans le Web d’aujourd’hui. Les internautes n’imaginent pas d’utiliser autre chose. On peut mesurer cette adhésion forte jour après jour quand on voit les autres moteurs de recherche se casser les dents, et ne pas parvenir à atteindre une masse critique. Le système Google prend toute son ampleur avec ses autres produits sur le même principe, par exemple Reader.  Il va à l’essentiel pour quelqu’un qui débute dans l’utilisation des flux RSS, et apporte des informations, et des fonctions de haut niveau pour le lecteur  chevronné.

Lorsque Apple a lancé les iPods le produit est apparu comme magique tant sa facilité d’utilisation était déconcertante. Vous mettiez cet appareil dans les main de n’importe qui, le coté intuitif rendait son apprentissage quasi instantané. D’entrée l’application iTunes a été positionnée comme outil incontournable avec l’intégration directe vers la boutique iTunes store en ligne. Cette intégration forte vers les autres produits et services de la marque à la pomme est maintenant incontournable. En chaînant ainsi les produits complémentaires, elle pérennise ses revenus. Avec l’arrivée de produits plus complexes comme l’iPod Touch, Apple est parvenu à toucher une seconde génération d’utilisateurs qui veulent plus de technologie directement accessible. Malgré ce changement les produits conservent une facilité qui garanti aussi bien une vitesse d’adoption et une addiction forte.

Les fournisseurs d’accès avec la création des box ont très largement démocratisé l’accès à internet. Si on revient un petit peu en arrière avant ces offres très intégrées, on avait des matériels qui ne remplissaient qu’une seule fonction, vous connecter à Internet. Pour le téléphone et la télévision il fallait continuer à utiliser d’autres produits. Au delà de la faible couverture fonctionnelles de ces offres, souvent les réglages pouvaient êtres aussi compliqués qu’aléatoires. Quand les offres tout en un sont arrivées, les utilisateurs ont vu débarquer des matériels qui changeait radicalement leur accès aux technologies de communications.  Une inquiétude est apparue : est ce que tout ce matériel ne va pas être trop complexe à utiliser ?  Une fois de plus l’adhésion et le succès sont passé par quelques fonctions essentielles faciles à utiliser et à mettre en oeuvre, et d’autres un peu plus complexes pour accéder aux autres services.

On pourrait citer des tonnes d’autres exemples comme par exemple Twitter avec son service qui ne fait pas grand-chose, mais qui peut être enrichit par une API ouverte.

Pour résumer tout ça, il est essentiel lorsque qu’on innove et qu’on met à la disposition du public de nouveaux produits de bien limiter le scope d’utilisation auquel est soumis l’utilisateur. Tout un chacun peut assimiler un périmètre plus ou moins restreint, ne noyons pas l’utilisateur sous trop d’innovations. La vraie innovation c’est finalement la simplicité et le fait de ne pas transformer l’utilisateur en spécialiste. C’est d’ailleurs ce dernier point qui semble être un facteur tant d’efficacité, que de succès commercial.

Folder Type from Emilio Gomariz on Vimeo.

Prenons le cas assez simple d’une table qu’on va parcourir pour mettre à jour des enregistrements. A chaque objet renvoyé par la boucle “for”, on enregistre la mise à jour dans la base.

for entity in MyModel.all().filter("color =",
   old_favorite).fetch(100):
   entity.color = new_favorite
   entity.put()

En faisant de cette manière, on fait 1 transaction pour récupérer les 100 enregistrements, puis 1 nouvelle transaction à chaque mise à jour, ce qui nous fait un total de 101 transactions. Dans le système de base de données “Bigtable” de Google Appengine c’est globalement l’appel à l’API qui coute cher. En comparaison avec ce qu’on a pu voir au dessus, il y a une autre façon de réaliser ce traitement :

updated = []
for entity in MyModel.all().filter("color =",
   old_favorite).fetch(100):
   entity.color = new_favorite
   updated.append(entity)
db.put(updated)

Le nombre de transaction chute de manière drastique puisqu’on passe de 101 à 2. L’opération d’enregistrement est beaucuop plus lourde que pouvaient l’être les 101 équivalentes, mais le nombre de call à l’API est réduit à maximum, donc plus efficace.

Lorsque de gros volumes de données sont à traiter il peut arriver que le temps de traitement dépasse ce qui est autorisé pour l’exécution d’une requête par Google AppEngine. Depuis la dernière version de Google AppEngine, il est possible de gérer une file d’attente des traitements sur le serveur. Prenons ici l’exemple fourni dans la documentation, il s’agit d’un mailing de masse sur l’ensemble des utilisateurs d’une base. Il y a fort à parier que ce type traitement dépasse très largement dans sa globalité les quelques secondes autorisées pour l’exécution d’une requête. En découpant le traitement en des taches suffisamment petites, et en les mettant dans une file d’attente, ce traitement devient immédiatement scalable.

# for each user, add a task to send a custom email message
for u in users:
   taskqueue.add(url='/work/sendmail',
      params=dict(to=u.email,
         subject='Hello ' + u.name, body='this is a message!'))
return # finished now, emails will be sent offline when tasks execute

# task handler at /work/sendmail, automatically called for each task created above
class MailWorker(webapp.RequestHandler):
   def post(self):
      mail.send_mail('from_me@example.com',
                          self.request.get('to'),
                          self.request.get('subject'),
                          self.request.get('body'))

L’utilisation StringListProperty permet de réduire de manière importante le nombre de Model de données à gérer. Le format de stockage des informations est beaucoup plus dense, et la recherche d’infos est plus simple. La mise en œuvre est très simple, par exemple pour gérer les couleurs favorites d’un utilisateur :

class Favorites(db.Model):
  colors = db.StringListProperty()
  username = db.StringProperty()

fav.colors = ["red", "blue", "green"]

Pour retrouver tous les utilisateurs qui aiment le jaune :

results = db.GqlQuery( "SELECT * FROM FavoriteColors WHERE color = 'yellow'")
users = [r.username for r in results]

Les petites contraintes sont par contre une consommation supérieure de CPU pour la serialisation, et les tris sont un peu plus difficiles à réaliser.

Si on compare la façon de laquelle une application de microblogging serait faite avec un outil de base de données classique :

SELECT * FROM Messages INNER JOIN UserMessages
USING (message_id) WHERE UserMessages.user_id = 'X';

Et maintenant avec App Engine :

class Message(db.Model):
  sender = db.StringProperty()
  receivers = db.StringListProperty()
  body = db.TextProperty()

results = db.GqlQuery("SELECT * FROM Message WHERE receivers = :1", me)

C’est tout de suite plus simple !

Par contre si les propertylist sont de très grande tailles (plus de 100 items) les performances peuvent être fortement affectées. La solution dans ce cas est de couper l’enregistrement en deux en mettant la liste d’un coté, et les données de l’autre. En SQL ceci nécessiterait de réaliser une complexe jointure entre les 2 tables mais ici c’est immédiatement plus simple.

class Message(db.Model):
  sender = db.StringProperty()
  body = db.TextProperty()

class MessageIndex(db.Model):
  receivers = db.StringListProperty()

indexes = db.GqlQuery("SELECT __key__ FROM MessageIndex WHERE receivers = :1", me)
keys = [k.parent() for k in indexes]
messages = db.get(keys) 

Voila pour cette rapide introduction aux structures de données de l’AppEngine. Si il y a vraiment un point qu’il ne faut pas oublier lorsqu’on utilise des outils de type CloudComputing c’est bien la scalabilité. Avec ces bonnes pratiques, c’est bien de toute l’expérience de Google sur le sujet  que vous aller pouvoir profiter .

Tout commence quand il est décidé un beau jour de mettre en oeuvre une belle solution de CRM pour automatiser les ventes, et unifier les processus à l’échelle de la planète. Un gros projet ambitieux décidé par le CEO lui même, avec un calendrier proche de la marche forcée car il faut très vite rentabiliser les licences acquise à prix d’or.  Très rapidement les formations s’enchainent et déjà les doutes commencent à s’installer.  Les formateurs n’ont d’autres arguments face aux lourdeurs remontées par les commerciaux que d’expliquerque celà va être merveilleux, les managers vont pouvoir voir en un clin d’oeuil l’état du business. Oui très bien mais la valeur ajoutée pour les relations avec les clients, dans quelle mesure ce capital informationnel engrangé dans l’outil va pouvoir être restitué ?

Après une validation de ces premières étapes qu’on considérera comme couronnée d’un franc succès (déjà là les étages de la fusée commencent à se séparer…), toujours sur le même rythme les données de l’existant business de la compagnie sont importées. Cette étape que dans bien des cas on considère comme cruciale est réalisée en quelques semaines. Des stagiaires travaillent sur la normalisation des données, et résultat des courses on se retrouve avec des informations qui sont érronées quand elle ne sont pas inexistantes. Bref pour reprendre une expression bien connue : “si vous entrez de la M____ à un bout du tuyau il est assez peu probable de voir de l’Or sortir de l’autre coté”. Il s’en suit la fermeture immédiate de tous les petits systèmes d’informations commerciales de part et d’autre et le lancement en fanfare de l’outil tant attendu.

Très rapidement le management local se rend bien compte que question agilité et souplesse c’est pas vraiment ça. Il faut trouver une solution, et il est rapidement demandé de faire le minimum visible. C’est à dire de faire le reporting et le forecast avec l’outil puisque c’est ce qui permet de faire que la partie emmergée de l’iceberg reste immaculée. C’est à ce point que ressugit le fameux “Think Global, Act Local”. Au sommet de l’Iceberg on est convaincu que tout marche parfaitement comme prévu, mais petit à petit les grains de sables viennent se mettre dans l’engrenage.  Tout allait parfaitement bien jusqu’à ce que des gens bien intentionnés décident d’exploiter le merveilleux tas d’Or sur lequel ils étaient assis. Un beau matin la direction marketing europe décide de lancer des campagnes marketing sur la base des contacts intégrés dans les outils. Je vous laisse imaginer le désastre et la perception coté client.

On pourrait s’imaginer que face à un pareil fiasco, il soit envisagé qu’il y ait eu un problème de qualification des bases, et bien non ! L’ordre a été passé d’étage en étages de la hiérarchie d’accompagner la campagne pour convaincre les clients. Ces clients étant pour la pluspart non concernés  par le domaine que touchait l’opération, le taux d’atteinte reste scotché au raz des paquerettes.  Fondamentalement ce qu’on peu retenir d’une pareille aventure c’est qu’on est dans la caractérisation d’une organisation totalement top-down ou les décisions tombent de manière intangibles, sans concertation. Chaque étage de la hiérarchie a des objectifs et demande à ses collaborateurs de propager le mouvement, sauf qu’arrivé en bas de pyramide, il faut bien trouver un compromis pour continuer à faire tourner la boutique. Seule une bonne pratique de communication interne et d’échange autour d’objectifs stratégique peut éviter ce genre de désillusions. Je parle ici de pratique et non d’outils car c’est d’abord un état d’esprit à avoir avant tout.

TwittBourse chez TwitteRadar

De nombreuses modifications ont été réalisées sur ces deux derniers jours. Tout d’abord une meilleure évolution du suivi du marché pour éviter de twitter si celui-ci n’évolue pas. Par ailleurs dans le but de réduire l’impact sur les timelines des folllowers, le nombre de twitts a été réduit de moitié. En effet de 2 twitts toutes les 1/2 heures pendant la période d’ouverture du marché, on est passé à 1 twitt toutes les 1/2 heures. Précédemment on avait un twitt dédié aux valeurs en hausse, et un autre twitt dédié aux valeurs en baisse. Maintenant on a un twitt qui comprend les 4 valeurs en plus forte hausse et la valeur en plus forte baisse, sachant que la répartition peut être inversée car elle se fait en fonction de l’orientation du marché.

twittbourse dans un CAC40 à la baisse et à la hausse

J’ai déjà pleins d’idée pour la suite, aussi bien des améliorations, que des services complémentaires, mais aussi des services plus personnalisées pour que ce twitter soit vraiment le votre….

Au fil de l’eau dans la timeline apparaitrons les principales hausses et baisses du CAC40. Toutes les 1/2 heures un Tweet permet d’avoir ces informations majeures. Dans de futures évolutions les faits marquants de l’économie et les événements financiers majeurs seront aussi relatés dans cette timeline. La vocation du service est de fournir une agrégation de flux d’informations. Par ailleurs il est aussi envisagé d’offrir à des utilisateurs la possibilité de suivre une liste de valeurs personnalisées dans leur Twitter. Nous reviendrons ultérieurement sur ces évolutions du service à venir.

Pour ce qui est de la technique qui est là dessous, ce projet était l’occasion de tester grandeur nature les capacité de Google App Engine. Autant la philosophie de l’outils avec son approche cloudcomputing est attrayante, que par contre la mise en oeuvre peut parfois réserver des surprises. Pour ce developpement je me suis basé sur l’implémentation Python de GAE. Les performances ne sont malheureusement pas au rendez-vous quand il s’agit d’aller chercher des volumes de données importants et de les insérer dans la système de stockage de données de Goggle. Il y a par contre des choses intéressantes comme les outils de développement, le dashboard pour surveiller l’appli en exploitation qui sont très bien faites, tout comme l’ensemble de l’infrastructure. On reviendra assez rapidement sur la plateforme.

Il vous reste maintenant à suivre @twittbourse, et à échanger pour faire grossir la communauté, pleins de choses devraient venir….. stay tuned.

Quel est l’intérêt de parler de ce type d’événement si ce n’est que ça amène toute la difficulté de l’exploitation d’applications par un client. Celui-ci doit maintenir un système en condition opérationnelle, en n’ayant -et c’est bien légitime- pas forcement la pleine mesure des effets de bords des opérations qui sont à réaliser sur les serveurs. Pourquoi pas lui proposer alors de passer en mode SaaS de type Cloud Computing, on externalise toute l’application et le client se connecte à ses données depuis Internet. Tout ça n’est pas si simple, il  y a d’abord la réticence évidente et paradoxale d’un client d’une petite structure à envoyer ses données sur internet, a ne plus les posséder en interne chez lui. A ce premier point s’ajoute parfois l’aspect technique, parfois des applications fonctionnement bien en local, mais pas évident que ce soit aussi efficace à distance.

De ces différentes interrogations, et assertions me vient une reflexion qui consiterait à déployer des conteneurs d’applications chez les clients et à les gérer à distance. Ainsi on isole l’application pour être certain qu’elle continue à s’executer dans un environnement intègre, on en assure la maintenance et les évolutions, et on a la certitude qu’il n’y a pas de problèmes ‘étranges’. Concrêtement cette logique peut s’envisager au travers d’une infrastructure de virtualisation chez le client et ainsi permettre de faire converger les deux préocupations, celle du client de propriété de ses données, et par ailleurs celle de robustesse et d’indépendance. On pourrait qualifier ça de ‘in house cloud computing’, l’application s’exécute dans un conteneur virtualisé, et à partir de là le client accède à un service sans plus de dicernement. Le concept reste à expérimenter, donc à suivre…

Une pause bien méritée sous la tête d’Ubine est l’occasion de prendre quelques photos de la vallée vue d’en haut, c’est toujours impressionnant ces mers de nuages vue d’en haut. Il n’est pas toujours nécessaire de partir en haute montagne pour disposer de paysages magiques comme celui-ci.

En continuant à monter par les Maupas, on arrive sur la suite de crête qui va nous emmener toit doucement vers la pointe de Lachau. Cette randonnée sans prétention, et sans risque a comme gros avantage de se faire en plein massif des cornettes de Bises, et de disposer à tout momment d’une ambiance sauvage, avec une tranquilité  extraordinaire.

La montée se fait avec à tout momment vue sur le Mont Chauffé, La Dent d’Oche, les Cornettes. Sur la photo ci-dessous le vallon de bise et les cornettes qui peuvent être une idée de suite à cette randonnée une fois arrivés au sommet.

L’interview de Bernard Perrine commence à partir de 4:48. Celui-ci, rédacteur du magazine ‘Le Photographe’ revient vers nous avec une rétrospective d’un siècle de photo. Il évoquera les différentes ruptures technologiques et culturelles que le monde de la photo a subit au fil du temps.

Je vous laisse écouter :

Après avoir fait donc ce rendu de base on va maintenant regarder comment créer des blocs de rendu, avec une possiblité d’organiser le code, et de réutiliser facilement celui-ci.

Pour aller un peu plus loin il peut être utile de structurer un peu le code et de pouvoir le décomposer en modules. Ici aussi rien d’extraordinaire, seulement des choses simples, que nous allons découvrir pas à pas. 

Principaux liens :

• App Engine Home
• Documentation
• Quotas
• Cookbooks

La première appli que j’ai vraiment adoré est “Writepad” que jous retrouverez dans la section gratuite de l’Appstore. Cette appli permet de retrouver le coté pratique de l’écriture gribouilli qu’on connaissait jusqu’alors avec les PDA et smartphones. Cette écriture se base sur une reconnaissance de caractère avec un dictionnaire qui peut être enrichi. Face a un mot non reconnu une liste de choix apparaît. Le texte entré peut alors être intégré dans un email pour être envoyé. Pour tout ceux qui -comme moi- ne sont pas des adeptes du clavier tactile, il faut immédiatement l’adopter.

La seconde appli que j’ai adopté avec un gand plaisir c’est discover. Cette application permet de partager le stockage de votre iPhone avec la liaison Wifi. Dès lors que vous lancez l’appli, on vous donne une url du style http://192.168.0.2:8888 à taper dans un browser web sur une autre machine. Le browser liste alors le Filsystem visible de l’iPhone, et on peut downloader ou uploader des fichiers très facilement. Evidement tout ça peut etre securisé par utilisateur et mot de passe pour restreindre l’accès. Il y a une fonction qui permet de rechercher les autres iPhone sur le réseau qui seraient en mesure d’échanger des fichiers. Je n’ai pas testé cette dernière fonction mais ça pourrait être assez intéressant.  Je vous invite à essayer ce produit que vous pouvez retrouver dans la section gratuite de l’Appstore.