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