WEBVTT

00:00:03.680 --> 00:00:05.480
Bien, bonjour à tous !

00:00:06.649 --> 00:00:09.437
Oui, tu voulais dire quelque chose, Thomas ?

00:00:10.160 --> 00:00:13.746
Très bien. Donc bonjour à tous, je m'appelle Romain.

00:00:13.746 --> 00:00:18.840
Comme l'a dit Rudy, je vais vous présenter un petit peu les solutions qu'on a élaborées

00:00:18.840 --> 00:00:21.000
dans le cadre de JoliCloud.

00:00:21.000 --> 00:00:23.360
dont je suis confondateur et CTO

00:00:23.360 --> 00:00:26.080
On a fait un usage intensif d'HTML5

00:00:26.080 --> 00:00:28.328
Donc ma mission va être de vous maintenir eveillés

00:00:28.328 --> 00:00:31.160
après cette pause déjeuner

00:00:31.160 --> 00:00:33.560
Alors juste pour resituer un petit peu le contexte

00:00:33.560 --> 00:00:36.840
pour bien comprendre les choix qu'on a fait et comment on a progressé

00:00:36.840 --> 00:00:39.440
On est parti d'un constat qui est que le Cloud remet vraiment en question

00:00:39.440 --> 00:00:41.633
les fondamentaux de l'informatique puisque

00:00:41.633 --> 00:00:44.373
on l'a vu encore ce matin avec Cloud9

00:00:44.373 --> 00:00:47.840
On utilise beaucoup plus d'applications en ligne maintenant

00:00:47.840 --> 00:00:51.548
que ce soit pour le traitement d'emails ou la gestion de documents

00:00:51.548 --> 00:00:55.380
et même maintenant avec Cloud9, l'édition de code dans le cloud

00:00:55.380 --> 00:00:59.000
Et de la même manière, toutes nos données sont aussi plus dans le cloud qu'auparavant

00:00:59.000 --> 00:01:02.600
c'est à dire qu'on a très peu de données localement sur nos machines

00:01:02.600 --> 00:01:05.840
Et en même temps les systèmes qu'on utilisent aujourd'hui sont encore relativement anciens

00:01:05.840 --> 00:01:11.280
axés sur la gestion du file system local d'un ordinateur

00:01:11.280 --> 00:01:15.000
Et alors avec l'arrivée des ordinateurs ultra-portables, les netbooks

00:01:15.000 --> 00:01:18.785
on voyait que l'usage des gens était vraiment lié à internet finalement

00:01:18.785 --> 00:01:22.720
c'était vraiment clef 3G, on se connecte dans un café, dans un train

00:01:22.720 --> 00:01:28.004
On se disait pourquoi finalement ne pas essayer de réinventer un peu l'usage de nos systèmes

00:01:28.004 --> 00:01:32.440
en utilisant la plateforme web qui est en fait la plateforme universelle pour ça

00:01:32.440 --> 00:01:35.040
Et c'était aussi pour nous une manière de dire

00:01:35.040 --> 00:01:37.800
on va essayer de proposer la meilleure expérience utilisateur possible

00:01:38.846 --> 00:01:44.080
et HTML5 et l'essor de la famille de toutes les technologies gravitant autour

00:01:44.080 --> 00:01:48.043
était pour nous la meilleure solution pour arriver à ça

00:01:49.240 --> 00:01:53.560
Donc la mission qu'on s'était fixée avec Jolicould avec Tariq Krim quand on a lancé ce projet

00:01:53.560 --> 00:01:58.909
C'est vraiment de dire on va rendre le cloud plus ouvert, plus simple, plus accessible à tous

00:01:58.909 --> 00:02:03.600
et proposer des solutions qui finalement vous aider les gens à accèder à internet

00:02:03.600 --> 00:02:06.280
et à gérer leur cloud plus aisément

00:02:06.280 --> 00:02:08.081
Donc on a développé plusieurs choses

00:02:08.081 --> 00:02:14.583
On a développé d'abord un Operating System essentiellement basé sur des technos web

00:02:14.583 --> 00:02:18.600
On a même été un peu fou puiqu'on a été jusqu'à commercialiser ça

00:02:18.600 --> 00:02:20.240
c'est un jolibook, donc on commercialisé

00:02:20.240 --> 00:02:25.080
c'est un objet un peu collector puisqu'il a été vendu exclusivment sur le marché anglais

00:02:25.080 --> 00:02:27.168
Et plus récemment une application Jolicloud

00:02:27.168 --> 00:02:30.360
qui est disponible pour tous les navigateurs modernes

00:02:30.360 --> 00:02:34.200
Mais ce dont on va vraiment s'intéresser aujourd'hui c'est le point commun à tous ces produits

00:02:34.200 --> 00:02:41.800
qui est le bureau HTML5 qui permet de finalement contrôler la machine

00:02:41.800 --> 00:02:44.640
et même d'aller un peu plus loin comme on le verra

00:02:44.640 --> 00:02:47.834
Alors tout d'abord je vais juste donner quelques fondamentaux

00:02:47.834 --> 00:02:51.520
sur la base de l'application HTML5 qu'on a faite

00:02:51.520 --> 00:02:54.880
Donc le web en 1997, c'était quand même ça ce qu'on pouvait faire de mieux

00:02:54.880 --> 00:03:00.320
donc on a quand même parcouru un long chemin sur le web

00:03:00.320 --> 00:03:04.480
Une application web avancée, qu'est ce que c'est finalement aujourd'hui ?

00:03:04.480 --> 00:03:06.560
C'est avant tout un client riche autonome

00:03:06.560 --> 00:03:09.280
Avant on avait un échange de pages avec le serveur

00:03:09.280 --> 00:03:11.280
ça va être maintenant quelque chose de très complexe

00:03:11.280 --> 00:03:13.480
qui va embarquer de la logique applicative

00:03:13.480 --> 00:03:15.040
on parlait avant de templating

00:03:15.040 --> 00:03:18.000
on va beaucoup être maintenant dans la programmation DOM

00:03:18.000 --> 00:03:23.160
au niveau des échanges avec le serveur, ça va être maintenant de la synchronisation de données

00:03:23.160 --> 00:03:25.822
et on parle aussi de persistence de l'état de l'application

00:03:25.822 --> 00:03:29.080
et même de mode déconnecté

00:03:29.080 --> 00:03:32.760
Donc là c'est un aperçu de l'application Jolicloud

00:03:32.760 --> 00:03:38.360
qui est le bureau de l'operating system

00:03:38.360 --> 00:03:39.986
Et on s'est dit d'abord

00:03:39.986 --> 00:03:42.320
Comment on va pouvoir implémenter cette application

00:03:42.320 --> 00:03:44.800
avec des technos modernes

00:03:44.800 --> 00:03:46.080
sans avoir justement à

00:03:46.080 --> 00:03:52.120
penser aux navigateurs anciens comme Internet Explorer

00:03:52.120 --> 00:03:55.040
qui évolue un peu moins vite que les navigateurs modernes

00:03:55.040 --> 00:04:00.164
Donc pour la structure, très succintement on a utilisé du flexible box model partout

00:04:00.164 --> 00:04:01.840
alors son support est encore expérimental

00:04:01.840 --> 00:04:04.160
ce qui fait qu'on a eu quelques petits soucis

00:04:04.160 --> 00:04:06.000
parfois de performances notamment

00:04:06.000 --> 00:04:12.285
sur les périphériques un peu... un peu comme les netbooks finalement

00:04:12.285 --> 00:04:15.880
beaucoup de media queries aussi pour gérer les différentes tailles d'écrans

00:04:15.880 --> 00:04:20.440
parce qu'il y a vraiment une grande diversité à ce niveau là

00:04:20.440 --> 00:04:22.240
et au niveau des composants de l'interface

00:04:22.240 --> 00:04:24.800
tout ce que vous pouvez voir sur cette interface

00:04:24.800 --> 00:04:29.320
va être uniquement des CSS en fait, il y a très très peu d'images

00:04:29.320 --> 00:04:31.360
donc au niveau des effets de la même façon

00:04:31.360 --> 00:04:34.160
c'est uniquement des transitions et des animations CSS

00:04:34.160 --> 00:04:37.960
parfois du canvas quand il s'agit de manipuler les images

00:04:37.960 --> 00:04:41.120
alors il y a deux choses qu'on a observé qui sont importantes à retenir

00:04:41.120 --> 00:04:44.400
si vous êtes amenés à utiliser des transitions ou des animations CSS

00:04:44.400 --> 00:04:46.120
c'est d'éviter quand même les animations infinies

00:04:46.120 --> 00:04:49.040
parce que sur des périphériques un peu low-spec comme des netbooks

00:04:49.040 --> 00:04:51.880
vous alllez avoir tendance à utiliser beaucoup de CPU

00:04:51.880 --> 00:04:56.751
et aussi ne jamais baser la logique applicative sur des callbacks de fin d'animation

00:04:56.751 --> 00:05:00.002
vous savez comme des webkit animation end ou des moz animation end

00:05:00.002 --> 00:05:02.120
parce que d'une part ils peuvent ne pas être supportés par le navigateur

00:05:02.120 --> 00:05:04.040
que vous êtes en train de 'targeter'

00:05:04.040 --> 00:05:10.160
bon voilà c'est une meilleure pratique d'avoir toujours la logique applicative séparée

00:05:10.160 --> 00:05:12.494
des effets purement graphiques

00:05:12.494 --> 00:05:15.280
Et rapidement au niveau du fonctionnement de l'application

00:05:15.280 --> 00:05:21.800
donc l'application consiste en une seule page HTML qui finalement est très très succinte

00:05:21.800 --> 00:05:26.496
c'est un mécanisme de chargement des scripts et des styles dynamiquement

00:05:26.496 --> 00:05:29.520
et puis quelque chose qu'il faut bien retenir dans le cadre de vos développements

00:05:29.520 --> 00:05:31.680
pour des applications un peu riches en HTML5

00:05:31.680 --> 00:05:34.240
c'est vraiment avoir une logique MVC

00:05:34.240 --> 00:05:38.000
c'est à dire qu'on est plus en train de dire on va modifier le DOM à la volée

00:05:38.000 --> 00:05:39.824
pour modifier tel ou tel élément

00:05:39.824 --> 00:05:42.360
c'est vraiment important d'avoir une vraie structure en place

00:05:42.360 --> 00:05:45.880
pour pouvoir dire : OK je vais avoir des modèles pour représenter mes données

00:05:45.880 --> 00:05:51.160
des vues qui vont me permettre justement de gérer la représentation de ces données à l'écran

00:05:51.160 --> 00:05:54.040
et puis des controleurs qui maintiendront l'état de l'application

00:05:54.040 --> 00:05:57.440
D'ailleurs y'a un excellent projet qui s'appelle Backbone.js que vous connaissez peut-être

00:05:57.440 --> 00:06:01.200
qui permet justement d'avoir une très bonne base pour ce genre de chose

00:06:02.508 --> 00:06:07.552
Donc là dans ce slide j'ai "embedder" l'application

00:06:07.552 --> 00:06:10.505
donc le bureau de JoliCloud

00:06:11.351 --> 00:06:15.160
donc tout ça c'est en CSS3

00:06:16.837 --> 00:06:20.680
donc là idem pour tout ce qui est animation

00:06:20.680 --> 00:06:23.920
la partie drag-n-drop par contre n'étant pas tout à fait finalisée

00:06:23.920 --> 00:06:25.720
dans HTML5

00:06:25.720 --> 00:06:30.444
elle est écrite un peu en javascript avec à la fois

00:06:30.444 --> 00:06:32.200
des petites choses HTML5 mais aussi

00:06:32.200 --> 00:06:35.064
des petites choses qui permettent d'avoir la compatibilité

00:06:36.560 --> 00:06:38.720
Alors maintenant on va rentrer un peu dans le vif du sujet

00:06:38.720 --> 00:06:41.403
parce que là on a quoi ? On a une application en HTML5

00:06:41.403 --> 00:06:43.040
qui se connecte au cloud

00:06:43.040 --> 00:06:45.040
qui finalement récupère des données

00:06:45.040 --> 00:06:46.520
les affiche à l'écran

00:06:46.520 --> 00:06:48.240
et ça fonctionne bien, ça se synchronise

00:06:48.240 --> 00:06:51.225
le problème maintenant c'est que quand on veut faire un operating system avec ça

00:06:51.225 --> 00:06:53.280
évidemment on va se retrouver dans des contextes où il faut absolument

00:06:53.280 --> 00:06:55.280
que l'application fonctionne hors-ligne

00:06:55.280 --> 00:07:00.320
Quand vous démarrez votre netbook ... ou votre ordinateur dans un train par exemple

00:07:00.320 --> 00:07:01.907
vous n'avez pas forcément de connexion avec vous

00:07:01.907 --> 00:07:03.903
donc il faut que ça marche hors-ligne

00:07:03.903 --> 00:07:07.960
Alors d'abord pour ce qui est des ressources de l'application

00:07:07.960 --> 00:07:11.440
c'est à dire faire que l'application va être fonctionnelle offline

00:07:11.440 --> 00:07:16.680
on a utilisé appcache, la technologie qui permet justement de lister

00:07:16.680 --> 00:07:20.800
l'ensemble des ressources que vous voulez mettre en cache dans le navigateur

00:07:20.800 --> 00:07:24.000
on l'a utilisé uniquement pour du javascript et du CSS finalement

00:07:24.000 --> 00:07:28.145
on a fait le choix de dire, l'ensemble des images

00:07:28.145 --> 00:07:31.360
qui sert au fonctionnement de l'application

00:07:31.360 --> 00:07:35.720
est converti en base64 et inliner dans les CSS

00:07:35.720 --> 00:07:41.160
c'est quelque chose qu'on a testé et qu'on a vraiment bien apprécié

00:07:41.160 --> 00:07:43.280
dans les tests qu'on a pu faire puisque

00:07:43.280 --> 00:07:48.360
même si cette conversion peut avoir un petit overhead en terme de taille

00:07:48.360 --> 00:07:52.360
vous allez avoir beaucoup moins de ressources à charger

00:07:52.360 --> 00:07:55.520
et donc en terme de latence réseau notamment avec des clefs 3G

00:07:55.520 --> 00:07:59.280
c'est quelque chose qui va vraiment améliorer les performances

00:07:59.280 --> 00:08:03.520
donc là si on prend l'exemple ici de cette image

00:08:03.520 --> 00:08:07.680
tous les navigateurs modernes sont capables d'afficher des images à partir de data

00:08:07.680 --> 00:08:10.280
de data URI

00:08:10.280 --> 00:08:12.720
donc maintenant l'application fonctionne en ligne

00:08:12.720 --> 00:08:15.120
le problème c'est qu'elle a pas encore de données pour l'utilisateur

00:08:15.120 --> 00:08:18.040
donc comment on va faire pour stocker les données de l'utilisateur

00:08:18.040 --> 00:08:21.120
et les rendre fonctionnelles hors-ligne ?

00:08:21.120 --> 00:08:24.520
Alors d'abord ce qu'on a fait, c'est une sorte d'abstraction de notre API

00:08:24.520 --> 00:08:25.360
qui se connecte au cloud

00:08:25.360 --> 00:08:27.320
de sorte que à chaque fois qu'on fait une requête

00:08:27.320 --> 00:08:29.680
pour aller chercher des données sur le cloud

00:08:29.680 --> 00:08:32.000
on va stocker l'ensemble de ces réponses JSON

00:08:32.000 --> 00:08:34.360
dans localstorage

00:08:34.360 --> 00:08:40.680
et en plus lorsque l'on récupère ces données localstorage pour le mode hors-ligne

00:08:40.680 --> 00:08:44.320
on va pouvoir avoir le même fonctionnement que lorsque l'application est en ligne

00:08:44.320 --> 00:08:47.070
autre avantage

00:08:47.070 --> 00:08:49.800
lorsque les données sont très récentes dans localstorage

00:08:49.800 --> 00:08:51.920
y compris lorsque vous êtes en ligne

00:08:51.920 --> 00:08:55.120
inutile de refaire cette requête, je viens de la faire

00:08:55.120 --> 00:08:58.657
de toute façon les données sont récentes, autant les exploiter

00:08:58.657 --> 00:09:00.920
ce qu'on a fait en plus encore une fois

00:09:00.920 --> 00:09:04.160
l'ensemble des images qui sont liées au bureau de l'utilisateur

00:09:04.160 --> 00:09:06.880
ou qui sont par exemples des avatars des utilisateurs

00:09:06.880 --> 00:09:09.988
sont également converties en base 64

00:09:09.988 --> 00:09:11.120
mises dans localstorage

00:09:11.120 --> 00:09:12.600
Alors il y a des technologies qui arrivent

00:09:12.600 --> 00:09:14.920
notamment FileSytem APIs

00:09:14.920 --> 00:09:17.600
le problème c'est qu'elle sont pas encore très répandues

00:09:17.600 --> 00:09:21.160
Elles sont encore au stade expérimental dans Chrome notamment

00:09:21.160 --> 00:09:26.480
donc on fait le choix de reprendre cette technique de LocalStorage qui fonctionne très bien

00:09:26.480 --> 00:09:29.040
Et donc bien sur il y a à gérer la synchronisation

00:09:29.040 --> 00:09:31.440
lorsqu'on revient online

00:09:31.440 --> 00:09:35.640
Alors maintenant c'est bien on a une application qui est capable de fonctionner hors-ligne

00:09:35.640 --> 00:09:41.056
mais comment on passe du mode hors-ligne au mode connecté ?

00:09:41.056 --> 00:09:43.308
et c'est finalement une problématique assez intéressante

00:09:43.308 --> 00:09:46.320
parce que dans les navigateurs y'a la propriété navigator.online

00:09:46.320 --> 00:09:49.480
mais elle est pas vraiment utile, elle est pas vraiment helpful pour ça

00:09:49.480 --> 00:09:50.400
puique finalement

00:09:50.400 --> 00:09:54.480
elle va être liée au fait que vous soyez connectés ou non au réseau

00:09:54.480 --> 00:09:58.480
et d'ailleurs elle est encore très peu implémentée dans les navigateurs

00:09:58.480 --> 00:10:00.120
Alors la solution qu'on a mise en place pour ça c'est de dire

00:10:00.120 --> 00:10:03.120
on va faire un test périodique de la connexion

00:10:03.120 --> 00:10:05.840
avec un appel XMLHTTPRequest au serveur

00:10:05.840 --> 00:10:07.920
l'avantage c'est que ça teste directement

00:10:07.920 --> 00:10:10.480
la possibilité d'atteindre votre serveur sur le réseau

00:10:10.480 --> 00:10:13.146
et donc de voir si vous êtes en ligne

00:10:13.146 --> 00:10:17.349
donc ça peut être une requête très très simple de type head par exemple

00:10:17.349 --> 00:10:20.785
et une stratégie qu'on a mis en place en supplément

00:10:20.785 --> 00:10:25.320
c'est de dire ben finalement si j'essaye d'accèder à ne ressource sur une API REST

00:10:25.320 --> 00:10:27.400
et qu'à ce moment précis, elle échoue

00:10:27.400 --> 00:10:30.040
dans ce cas je peux en déduire et signifier à l'utilisateur

00:10:30.040 --> 00:10:32.120
qu'il est passé en mode déconnecté

00:10:32.120 --> 00:10:34.080
et autre chose aussi

00:10:34.080 --> 00:10:38.320
supposons que vous soyez dans un train en train d'utiliser l'application en mode hors-ligne

00:10:38.320 --> 00:10:40.480
vous fermez votre ordinateur, vous revenez

00:10:40.480 --> 00:10:42.680
vous êtes dans un endroit maintenant connecté

00:10:42.680 --> 00:10:46.560
il serait quand même intéressant et judicieux de signifier immédiatement à l'utilisateur

00:10:46.560 --> 00:10:48.360
qu'il est maintenant en mode connecté

00:10:48.360 --> 00:10:50.320
donc on procdède à une détection pour savoir

00:10:50.320 --> 00:10:53.920
si l'utilisateur est actif, par exemple en regardant l'évènement mousemove

00:10:53.920 --> 00:10:58.240
mais ça peut être également en regardant un touch par exemple sur le mobile

00:10:58.240 --> 00:11:01.680
donc on va faire ici une rapide démo

00:11:01.680 --> 00:11:05.080
donc là on est en mode connecté sur l'application

00:11:05.080 --> 00:11:09.440
et je vais essayer de couper le réseau

00:11:09.440 --> 00:11:12.160
alors là je pourrais attendre un test périodique qui va arriver

00:11:12.160 --> 00:11:14.760
mais je vais immédiatement essayer d'accèder à une ressource

00:11:14.760 --> 00:11:19.400
donc là on constate que ... comment dire ?

00:11:19.400 --> 00:11:21.459
L'application est passée immédiatement en mode hors-ligne

00:11:21.459 --> 00:11:24.240
désactivant donc certaines des fonctionnalités

00:11:24.240 --> 00:11:27.480
parce qu'évidemment lorsque vous revenez en mode déconnecté

00:11:27.480 --> 00:11:29.888
l'utilisateur s'attend à ce que toutes ses données soient synchronisées

00:11:29.888 --> 00:11:31.467
dans le même état qu'il les a laissées

00:11:31.467 --> 00:11:34.480
donc y'a certaines choses pour lesquelles ça a du sens, d'autres moins

00:11:34.480 --> 00:11:36.640
et donc là je vais passer en mode connecté maintenant

00:11:40.255 --> 00:11:41.532
voilà

00:11:41.540 --> 00:11:43.600
et je vais immédiatement redevenir actif sur l'application

00:11:43.600 --> 00:11:50.298
donc le navigateur a détecté qu'ici je suis repassé en mode en ligne

00:11:50.298 --> 00:11:52.120
et l'application est de nouveau fonctionnelle

00:11:52.120 --> 99:59:59.999
avec l'ensemble de ses fonctionnalités