Bien, bonjour à tous ! Oui, tu voulais dire quelque chose, Thomas ? Très bien. Donc bonjour à tous, je m'appelle Romain. Comme l'a dit Rudy, je vais vous présenter un petit peu les solutions qu'on a élaborées dans le cadre de JoliCloud. dont je suis confondateur et CTO On a fait un usage intensif d'HTML5 Donc ma mission va être de vous maintenir eveillés après cette pause déjeuner Alors juste pour resituer un petit peu le contexte pour bien comprendre les choix qu'on a fait et comment on a progressé On est parti d'un constat qui est que le Cloud remet vraiment en question les fondamentaux de l'informatique puisque on l'a vu encore ce matin avec Cloud9 On utilise beaucoup plus d'applications en ligne maintenant que ce soit pour le traitement d'emails ou la gestion de documents et même maintenant avec Cloud9, l'édition de code dans le cloud Et de la même manière, toutes nos données sont aussi plus dans le cloud qu'auparavant c'est à dire qu'on a très peu de données localement sur nos machines Et en même temps les systèmes qu'on utilisent aujourd'hui sont encore relativement anciens axés sur la gestion du file system local d'un ordinateur Et alors avec l'arrivée des ordinateurs ultra-portables, les netbooks on voyait que l'usage des gens était vraiment lié à internet finalement c'était vraiment clef 3G, on se connecte dans un café, dans un train On se disait pourquoi finalement ne pas essayer de réinventer un peu l'usage de nos systèmes en utilisant la plateforme web qui est en fait la plateforme universelle pour ça Et c'était aussi pour nous une manière de dire on va essayer de proposer la meilleure expérience utilisateur possible et HTML5 et l'essor de la famille de toutes les technologies gravitant autour était pour nous la meilleure solution pour arriver à ça Donc la mission qu'on s'était fixée avec Jolicould avec Tariq Krim quand on a lancé ce projet C'est vraiment de dire on va rendre le cloud plus ouvert, plus simple, plus accessible à tous et proposer des solutions qui finalement vous aider les gens à accèder à internet et à gérer leur cloud plus aisément Donc on a développé plusieurs choses On a développé d'abord un Operating System essentiellement basé sur des technos web On a même été un peu fou puiqu'on a été jusqu'à commercialiser ça c'est un jolibook, donc on commercialisé c'est un objet un peu collector puisqu'il a été vendu exclusivment sur le marché anglais Et plus récemment une application Jolicloud qui est disponible pour tous les navigateurs modernes Mais ce dont on va vraiment s'intéresser aujourd'hui c'est le point commun à tous ces produits qui est le bureau HTML5 qui permet de finalement contrôler la machine et même d'aller un peu plus loin comme on le verra Alors tout d'abord je vais juste donner quelques fondamentaux sur la base de l'application HTML5 qu'on a faite Donc le web en 1997, c'était quand même ça ce qu'on pouvait faire de mieux donc on a quand même parcouru un long chemin sur le web Une application web avancée, qu'est ce que c'est finalement aujourd'hui ? C'est avant tout un client riche autonome Avant on avait un échange de pages avec le serveur ça va être maintenant quelque chose de très complexe qui va embarquer de la logique applicative on parlait avant de templating on va beaucoup être maintenant dans la programmation DOM au niveau des échanges avec le serveur, ça va être maintenant de la synchronisation de données et on parle aussi de persistence de l'état de l'application et même de mode déconnecté Donc là c'est un aperçu de l'application Jolicloud qui est le bureau de l'operating system Et on s'est dit d'abord Comment on va pouvoir implémenter cette application avec des technos modernes sans avoir justement à penser aux navigateurs anciens comme Internet Explorer qui évolue un peu moins vite que les navigateurs modernes Donc pour la structure, très succintement on a utilisé du flexible box model partout alors son support est encore expérimental ce qui fait qu'on a eu quelques petits soucis parfois de performances notamment sur les périphériques un peu... un peu comme les netbooks finalement beaucoup de media queries aussi pour gérer les différentes tailles d'écrans parce qu'il y a vraiment une grande diversité à ce niveau là et au niveau des composants de l'interface tout ce que vous pouvez voir sur cette interface va être uniquement des CSS en fait, il y a très très peu d'images donc au niveau des effets de la même façon c'est uniquement des transitions et des animations CSS parfois du canvas quand il s'agit de manipuler les images alors il y a deux choses qu'on a observé qui sont importantes à retenir si vous êtes amenés à utiliser des transitions ou des animations CSS c'est d'éviter quand même les animations infinies parce que sur des périphériques un peu low-spec comme des netbooks vous alllez avoir tendance à utiliser beaucoup de CPU et aussi ne jamais baser la logique applicative sur des callbacks de fin d'animation vous savez comme des webkit animation end ou des moz animation end parce que d'une part ils peuvent ne pas être supportés par le navigateur que vous êtes en train de 'targeter' bon voilà c'est une meilleure pratique d'avoir toujours la logique applicative séparée des effets purement graphiques Et rapidement au niveau du fonctionnement de l'application donc l'application consiste en une seule page HTML qui finalement est très très succinte c'est un mécanisme de chargement des scripts et des styles dynamiquement et puis quelque chose qu'il faut bien retenir dans le cadre de vos développements pour des applications un peu riches en HTML5 c'est vraiment avoir une logique MVC c'est à dire qu'on est plus en train de dire on va modifier le DOM à la volée pour modifier tel ou tel élément c'est vraiment important d'avoir une vraie structure en place pour pouvoir dire : OK je vais avoir des modèles pour représenter mes données des vues qui vont me permettre justement de gérer la représentation de ces données à l'écran et puis des controleurs qui maintiendront l'état de l'application D'ailleurs y'a un excellent projet qui s'appelle Backbone.js que vous connaissez peut-être qui permet justement d'avoir une très bonne base pour ce genre de chose Donc là dans ce slide j'ai "embedder" l'application donc le bureau de JoliCloud donc tout ça c'est en CSS3 donc là idem pour tout ce qui est animation la partie drag-n-drop par contre n'étant pas tout à fait finalisée dans HTML5 elle est écrite un peu en javascript avec à la fois des petites choses HTML5 mais aussi des petites choses qui permettent d'avoir la compatibilité Alors maintenant on va rentrer un peu dans le vif du sujet parce que là on a quoi ? On a une application en HTML5 qui se connecte au cloud qui finalement récupère des données les affiche à l'écran et ça fonctionne bien, ça se synchronise le problème maintenant c'est que quand on veut faire un operating system avec ça évidemment on va se retrouver dans des contextes où il faut absolument que l'application fonctionne hors-ligne Quand vous démarrez votre netbook ... ou votre ordinateur dans un train par exemple vous n'avez pas forcément de connexion avec vous donc il faut que ça marche hors-ligne Alors d'abord pour ce qui est des ressources de l'application c'est à dire faire que l'application va être fonctionnelle offline on a utilisé appcache, la technologie qui permet justement de lister l'ensemble des ressources que vous voulez mettre en cache dans le navigateur on l'a utilisé uniquement pour du javascript et du CSS finalement on a fait le choix de dire, l'ensemble des images qui sert au fonctionnement de l'application est converti en base64 et inliner dans les CSS c'est quelque chose qu'on a testé et qu'on a vraiment bien apprécié dans les tests qu'on a pu faire puisque même si cette conversion peut avoir un petit overhead en terme de taille vous allez avoir beaucoup moins de ressources à charger et donc en terme de latence réseau notamment avec des clefs 3G c'est quelque chose qui va vraiment améliorer les performances donc là si on prend l'exemple ici de cette image tous les navigateurs modernes sont capables d'afficher des images à partir de data de data URI donc maintenant l'application fonctionne en ligne le problème c'est qu'elle a pas encore de données pour l'utilisateur donc comment on va faire pour stocker les données de l'utilisateur et les rendre fonctionnelles hors-ligne ? Alors d'abord ce qu'on a fait, c'est une sorte d'abstraction de notre API qui se connecte au cloud de sorte que à chaque fois qu'on fait une requête pour aller chercher des données sur le cloud on va stocker l'ensemble de ces réponses JSON dans localstorage et en plus lorsque l'on récupère ces données localstorage pour le mode hors-ligne on va pouvoir avoir le même fonctionnement que lorsque l'application est en ligne autre avantage lorsque les données sont très récentes dans localstorage y compris lorsque vous êtes en ligne inutile de refaire cette requête, je viens de la faire de toute façon les données sont récentes, autant les exploiter ce qu'on a fait en plus encore une fois l'ensemble des images qui sont liées au bureau de l'utilisateur ou qui sont par exemples des avatars des utilisateurs sont également converties en base 64 mises dans localstorage Alors il y a des technologies qui arrivent notamment FileSytem APIs le problème c'est qu'elle sont pas encore très répandues Elles sont encore au stade expérimental dans Chrome notamment donc on fait le choix de reprendre cette technique de LocalStorage qui fonctionne très bien Et donc bien sur il y a à gérer la synchronisation lorsqu'on revient online Alors maintenant c'est bien on a une application qui est capable de fonctionner hors-ligne mais comment on passe du mode hors-ligne au mode connecté ? et c'est finalement une problématique assez intéressante parce que dans les navigateurs y'a la propriété navigator.online mais elle est pas vraiment utile, elle est pas vraiment helpful pour ça puique finalement elle va être liée au fait que vous soyez connectés ou non au réseau et d'ailleurs elle est encore très peu implémentée dans les navigateurs Alors la solution qu'on a mise en place pour ça c'est de dire on va faire un test périodique de la connexion avec un appel XMLHTTPRequest au serveur l'avantage c'est que ça teste directement la possibilité d'atteindre votre serveur sur le réseau et donc de voir si vous êtes en ligne donc ça peut être une requête très très simple de type head par exemple et une stratégie qu'on a mis en place en supplément c'est de dire ben finalement si j'essaye d'accèder à ne ressource sur une API REST et qu'à ce moment précis, elle échoue dans ce cas je peux en déduire et signifier à l'utilisateur qu'il est passé en mode déconnecté et autre chose aussi supposons que vous soyez dans un train en train d'utiliser l'application en mode hors-ligne vous fermez votre ordinateur, vous revenez vous êtes dans un endroit maintenant connecté il serait quand même intéressant et judicieux de signifier immédiatement à l'utilisateur qu'il est maintenant en mode connecté donc on procdède à une détection pour savoir si l'utilisateur est actif, par exemple en regardant l'évènement mousemove mais ça peut être également en regardant un touch par exemple sur le mobile donc on va faire ici une rapide démo donc là on est en mode connecté sur l'application et je vais essayer de couper le réseau alors là je pourrais attendre un test périodique qui va arriver mais je vais immédiatement essayer d'accèder à une ressource donc là on constate que ... comment dire ? L'application est passée immédiatement en mode hors-ligne désactivant donc certaines des fonctionnalités parce qu'évidemment lorsque vous revenez en mode déconnecté l'utilisateur s'attend à ce que toutes ses données soient synchronisées dans le même état qu'il les a laissées donc y'a certaines choses pour lesquelles ça a du sens, d'autres moins et donc là je vais passer en mode connecté maintenant voilà et je vais immédiatement redevenir actif sur l'application donc le navigateur a détecté qu'ici je suis repassé en mode en ligne et l'application est de nouveau fonctionnelle avec l'ensemble de ses fonctionnalités