Les nouveautés opengraph

En introduction, FB a mis en avant les nombreux avantages de l’opengraph actuel

• Une video vue sur dailymotion via FB génère 3 clics sur Dailymotion
• Il existe une infinité de façon de mettre en œuvre l’opengraph  via les actions. L’application senscritique.fr est un exemple de la créativité possible : j’ai envie de de, etc. ;

Concrètement les nouveautés  (et/ ou usages innovants):

• User taging :  « je voyage avec xxx » plutôt que je voyage à l’endroit y. On peu utiliser un ami comme tag d’une action
• Rechargement de tous les évènements passés avec une application sur la timeline avant qu’elle soit mise en place
• Map action l : voir nike+, on peut utiliser les lieux et des maps dans les actions
• Il faut modéliser les objects, les actions, comme un modèle de données traditionnel. Il faut bien penser cela au début car l’expérience montre qu’il est difficile ensuite de faire évoluer le modèle (problème de pertes de données, etc…)
• Les objects peuvent générer eux-mêmes des actions (à l’extrême, un évènement détécté par une cafetière peur déclencher l’action « j’ai pris un café »).
• Attention aux erreurs des publications : il faut les surveiller dans les insights
• Il est possible de se brancher sur un beta opengraph.fb.com ( ?) pour tester ces implémentations
• Il est possible de traduire le nom de son graph, ainsi que le nom des objets…mais c’est pas simple
• FB ne restitue pas les actions que l’application à soi même généré. Il faut donc que l’application pense à les historiser de son côté
• Application citée comme exemple de web app déconnectée du canva mais publiant dans l’opengraph: pose.com

Shipping et QA

Facebook a expliqué sa façon de gérer ces procesuss

• pas de testeurs, tous les collaborateurs sont des testeurs car ils sont connectés à une version beta de fb(http://beta.facebook.com/). Ils indiquent le bug temps réel et font des roolbacks en cas de problème
• Le code réalisé jusqu’au dimanche soir est mis en prod tous les mardi matin et shippé au fil de l’eau en béta. La
• Utilisation d’une suite logicielle pour gérer le code : http://phabricator.org/
• Recommandation de connecté les applis sur http://beta.facebook.com/ afin de voir si elle sera prête pour la mise en prod du mardi.
• Recours à des « dark launches » , c’est-à-dire des lancement de features sans que les utilisateurs les voit. Par exemple, lors du lancement de la timeline, ils l’ont en fait activé pour tout le monde, sans que les users puissent la voir. Cela leur a permis de vérifier tout à ta de chose (charges, bugs, etc…).
• Etant donné le nombre de serveurs de leur infra (plus de 10 000 serveurs), FB utilise bit torrent pour déployer le 1.5Gb de l’executable de FB, et en moins d’une heure maintenant (contre plusieurs heures via un déploiement en cascade précédemment)
• Chaque développeur est responsable de son code (grosse pression sur leur qualité…) – j’avais vu dans un précédant garage qu’ils étaient notés sur leur contribution et leur correction de bugs avec un leaderboard général….visible par tous !

Appplis mobile

FB a indiqué ne vouloir aider que les développeurs qui ont une version mobile de leur app et déployer l’opengraph (actions,objects). Cela signifie clairement que l’usage gracieux des ingénieurs de facebook dans le cadre de mise au point est clairement filtré.

Nouveautés :

• Possibilité de déclencher une notification par l’app mobile sans que l’app mobile n’ait à coder cette notification. Je n’ai pas tout compris, mais il semble que la génération d’une notification passe désormais par un service Facebook appelable facilement par une app (ios ou android) beaucoup plus facilement qu’avant.
• Beaucoup de démonstrations d’interaction webapp mobile app et webmobil ont été faites pour illustrer le fort niveau d’intégration possible du point de vue de l’interface utilisateur (seamless)

Remarques et nouveautés diverses

• Offilineaccess : la permission sera supprimée bientôt (elle fait trop peur)
• Le token d’autorisation valable 60j aura désormais une durée de vie repoussée à chaque nouvelle connection du user
• Attention au shallowlinking : c’est-à-dire la perte du contenu, il faut recourrir au max à du deeplinking (en particulier de l’objet opengraph qui ne dépend a priori pas du tout de la plateforme de laquelle on l’accède – mobile web, mobile app, canvas, web.
• Toute application peut  accéder à toute l’activité musicale, jeu etc – builtin- (en fait toutes les actions banalisées par FB)…Donc, de ce que j’ai compris, une appli de jeu X peut accéder au scores et achievment d’un jeu Y…Mais le namespace de ces activités n’est pas publique…donc il faut tatonner (typiquement le genre de chose que les ingénieurs doivent donner dans les échanges informels). Mais en revanche
• Rafraichissement des métadonnées des objects possible via le graphbatchAPI
• Explication de la viral loop : action dans l’appli, publication d’une action/feed, affichage de l’action / feed (c’est à ce niveau qu’intervient l’algo de FB qui filtre), puis click par le user et retour à l’application. Ils ont attiré l’attention sur les fuites qui existent dans ce loop, en particulier l’autologin qui faut pouvoir correctement gérer pour éviter des apparitions trop intrusives de la fenêtre d’ autorisation de l’application.