Ok, bienvenue à tous !
Je suis ici aujourd'hui avec Lieke pour vous parler de Cloud9,
un IDE dans le cloud, avec lequel vous pouvez accéder à votre code de n'importe où, n'importe quand.
Je suis Ruben Daniels, co-fondateur et directeur de Ajax.org, et Cloud9.
Je développe en Javascript depuis 1999.
Ça fait un moment, et javascript a beaucoup évolué.
Je suis l'auteur et le créateur de la plateforme Ajax.org, qui est une librairie d'interface qu'on utilise dans Cloud9.
Notre compagnie comprend 20 personnes, et on essaie de révolutionner le développement
de code, dans le cloud.
Bonjour, je m'appelle Lieke, je parle français, mais je ne fais pas cette présentation en français,
parce que Ruben ne parle pas, et moi je ne parle pas "tant" bien.
Donc, il y a de la traduction, mais je m'intéresse : combien de gens peuvent entendre l'anglais ?
C'est presque toute la salle.
Je vais parler anglais. Je fais partie dAjax.org depuis 2009, dans les relations avec les développeurs.
Donc, ce dont on va parler aujourd'hui : premièrement, une réponse à la question "Pourquoi le cloud ?"
Ou plutôt, "Pourquoi le cloud pour des développeurs ?"
Je vous ferai une démo de l'IDE Cloud9, qui est notre vision de la manière de faire,
et ensuite nous parlerons de collaboration, que nous imaginons dans le futur du développement dans le cloud.
Je vais laisser Lieke commencer, elle va vous expliquer pourquoi le cloud est important.
Nous pensons que le développement se fera dans le cloud, donc prenons un peu de recul.
Il se peut que vous vous demandiez : pourquoi travailler dans le cloud ?
Et d'ailleurs, c'est quoi cette chose qu'on appelle le "cloud" ?
Alors, jetons un oeil au cloud...
Le cloud, c'est l'étape qui suit la virtualisation, qui nous permet de ne plus nous soucier du matériel,
mais quand même toujours de quel OS tourne, comment installer et configurer des SGBD comme MySQL,
et il faut toujours garder un oeil sur chaque serveur, on doit s'inquiéter de leur dimensionnement.
Donc, il y a deux types de systèmes que l'on appelle "cloud" :
il y en a qui sont des constructions d'APIs sur des systèmes de gestion de virtualisation,
ce qui est proche de "Infrastructure as a Service" (IaaS)
et des systèmes où la couche remonte au-dessus de l'API, "Platform as a Service" (PaaS)
Pour moi, la promesse du cloud, c'est que l'intégration remonte au niveau de l'API,
que l'on utilise en construisant des applications au-dessus.
Ça inclut donc l'espace disque, la base de données, et la puissance de calcul.
Ce niveau de cloud est pour l'instant surtout une promesse, même si Google App Engine
et Heroku sont plutôt loin dans le concept.
Donc, regardons un exemple ; il est plutôt simple, peut-être inutile,
mais j'aimerais vous expliquer ce que le cloud signifie.
Donc, disons que vous avez une boîtes de livres ; vous devez la stocker,
et plus tard, vous voudrez récupérer des livres.
Avant la virtualisation, vous deviez construire un abri ; pour protéger vos livres, avec une porte verrouillable,
mais maintenant, avec la virtualisation, l'abri est déjà prêt.
Vous avez quand même besoin de gérer l'espace à l'intérieur, construire les étagères,
et stocker les livres vous-mêmes.
Avec le cloud, vous obtenez un gars, ou un robot, vous lui donnez votre stock de livres,
il les stocke pour vous, et vous pouvez les lui redemander quand vous voulez.
C'est un exemple simple, mais il montre bien les niveaux de pré-intégration.
Alors, quelle est la fonctionnalité la plus utile du cloud ?
Premièrement, gérer le dimensionnement des serveurs.
Imaginez que vous avez une application sociale, vous commencez avec quelques utilisateurs,
et vous le faites tourner sur une VM chez Amazon.
Soudainement, Justin Bieber remarque votre appli, et il tweete dessus.
Et hop, 8 million d'adolescentes excitées, qui embourbent soudainement sur vos serveurs !
Que votre business model soit construit pour ça, c'est pas la question !
Et du coup, vos serveurs explosent...
Il faut que vous puissiez gérer vos ressources back-end rapidement, donc que faire ?
Il faut démarrer d'autres instances, et un balanceur de charge, mais d'abord, il faut gérer le dimensionnement de votre code !
La plupart de vos applications avec des fonctionnalités sociales, ou des bases de données,
ne peuvent pas se redimensionner horizontalement, sans une étude approfondie ;
c'est donc un cauchemar !
Pas juste à cause de lui, mais à cause du coût pour architecturer et dimensionner votre application
sans même savoir si elle sera populaire ou non.
L'infrastructure dans le cloud résoud ce problème ; les APIs sont exactement construites pour le dimensionnement.
En utilisant cet outil de dimensionnement tout prêt, vous pouvez dimensionner d'1 utilisateur à 1 million,
puis redescendre à 1 utilisateur !
Et ceci, sans le coût de le prévoir à l'avance, ou les pertes dûes à l'échec face à la popularité soudaine !
En gros, le cloud sauve du temps et de l'argent,
et les développeurs peuvent se concentrer sur ce qu'ils aiment faire le plus : développer des applications !
Ils peuvent se concentrer sur les fonctionnalités demandées par les utilisateurs.
Je pense qu'on peut se mettre d'accord pour dire que le cloud, c'est un truc sympa.
Ruben ?
Qu'est-ce que ça veut dire pour le développement ?
Les plateformes cloud fournissent un SDK, que vous installez sur votre machine,
et vous espérez que tout marchera pareil sur votre machine et dans le cloud, mais ce n'est jamais le cas.
Regardons App Engine, dans Google, qui embarque Big Table.
Big Table est cette énorme infrastructure dans le cloud pour stocker des données ;
vous ne pouvez pas l'installer sur votre PC.
Donc, vous devez simuler ça, quand vous installez ce SDK, vous simulez l'environnement cloud.
Et ce n'est jamais parfait ; vous aurez toujours le cas où votre application marche localement,
et vous l'uploadez, et elle ne marche pas, à cause de certaines différences.
Donc, c'est difficile, vous ne pouvez pas tester entièrement votre application, et il faut une solution.
Cloud9, c'est notre vision d'une solution au problème.
Le code que vous développez ne vit pas sur votre machine, mais dans le cloud,
vous développez dans le cloud, et puisque c'est là qu'il vit, vous pouvez accéder toute l'API, dont Big Table.
Donc quand vous buildez l'application, il n'y a pas de problème.
Vous pouvez lancer et débuguer dans le même environnement aussi.
Un autre avantage : vous n'avez pas à télécharger et installer un SDK,
sur votre système, qui est sans doute différent de celui du développeur qui a créé le SDK.
Tous ces problèmes s'en vont, vous pouvez commencer à faire ce que vous aimez faire en tant que développeur :
écrire du code.
Maintenant, prenons ce scénario, vous êtes un nouveau développeur, vous rejoignez une compagnie,
qui a distribué une web-app il y a un an ;
les clients appellent parce qu'ils ont entendu parler d'une nouvelle technologie,
et ils veulent que la web-app la supporte.
Pour ajouter cette fonctionnalité convenablement, vous avez besoin de tout l'environnement,
le serveur, la base de données, scripts pour le déploiement, et d'installer tout ça.
Il faut que vous trouviez votre chemin dans ce système : discuter avec les administrateurs,
trouver les mots de passe, comprendre la procédure de déploiement...
Du coup, avant d'avoir créé un environnement de développement que vous pouvez utiliser
sans avoir à modifier du code en live, vous devez passez une éternité à faire tout ça.
Ce problème est une réalité pour beaucoup de développeurs.
Imaginez que vous tentiez d'ajouter une fonctionnalité, ou de résoudre un bug,
maintenant, imaginez ça : un environnement de développement qui tourne dans le cloud
est ce qui est utilisé pour fabriquer cette application.
Tout l'ensemble d'outils, d'éditeurs et de processeurs sont maintenant disponibles
en entrant une simple URL dans le navigateur.
En tant que développeur, vous pouvez démarrer immédiatement, améliorer votre application,
et tester sur une ferme cloud de test.
Quand vous avez testé le nouveau code, et avec succès,
vous pouvez cliquer sur "déployer en prod", et le client est content !
Vous n'avez pas à perdre de temps à faire l'admin système, ou à répéter vos efforts !
Vous pouvez avoir tout l'environnement de développement d'un projet derrière une simple URL,
et votre vie est soudainement bien plus heureuse !
Je vais vous montrer comment un IDE dans le cloud peut marcher.
C'est notre site web, c9.io, et vous ne le voyez pas, parce qu'on a deux écrans...
Donc, vous pouvez vous loguer avec votre compte GitHub ; qui en a un ?
GitHub est un site qui héberge votre code source, avec un aspect social.
Pour les gens qui ont un compte c'est facile ; sinon, vous pouvez créer un compte avec Cloud9.
Ici, vous avez tous vos projets ; ils vivent tous dans le cloud.
Vous pouvez les ouvrir, en les clonant depuis GitHub.
On ouvre le projet Node.JS, par exemple.
Comme vous voyez, vous pouvez reconnaître des éléments d'IDE habituels.
Un éditeur, un arbre de fichiers, et des éléments d'interface pour vous aider dans certaines tâches.
Nous voulons cet éditeur innovant, meilleur que les éditeurs que vous connaissez, dans Eclipse, par exemple,
ou dans d'autres IDEs important, ou des éditeurs de textes.
Quand nous l'avons construit, en septembre 2010, nous l'avons présenté à une conférence, "JS conf",
et immédiatement, les gars de Mozilla qui construisaient un éditeur sont venus nous voir :
"votre éditeur est plus rapide, on pourrait travailler ensemble, et mêler nos efforts"
Et donc, c'est ce qu'on a fait, on a travaillé avec Mozilla pour le rendre meilleur et plus rapide.
Et maintenant, on a une vraie communauté de quelques centaines de gens qui donnent du code,
et qui rendent l'éditeur encore meilleur, avec des raccourcis vim pour ceux qui aiment.
La coloration syntaxique, et toutes ces choses que vous voulez pour en faire le meilleur éditeur
au monde, point final, le détail étant qu'il tourne dans un navigateur.
Le truc cool avec cet éditeur, c'est qui se dimensionne dynamiquement,
même avec 100000 lignes de code, il serait toujours aussi rapide ; il ne rend que la partie que vous voyez.
Cloud9 utilise ACE, cet éditeur, il est open-source, sur ace.ajax.org
et Cloud9 y ajoute notamment des onglets pour naviguer à travers les fichiers.
et les fichiers vivent dans le cloud, donc vous y accéder dans le navigateur,
et on supporte l'offline, donc sans connexion, certains fichiers restent disponibles.
Dans les versions futures, il y aura un support complet de la synchronisation,
on en a fait une démo le mois dernier.
Tout votre projet se synchronise automatiquement avec votre système de fichier local.
Vous pouvez y accéder dans le train.
Créons une application de zéro.
Une application Hello World...
On commence en créant un fichier javascript.
On l'appelle "HelloWorld", fichier vide.
On crée un fichier javascript qui s'exécute côté serveur, qui tourne grâce à Node.JS.
Qui ici connaît Node.JS ?
Pour ceux qui ne connaissent pas, c'est un runtime javascript, qui utilise V8,
et exécute du javascript côté serveur, en étant très orienté sur les entrées/sorties asynchrones.
Vous utilisez un style de développement orienté "événements", comme les événements dans le navigateur,
sauf qu'on est dans le serveur.
Pour toutes les opérations qui peuvent prendre du temps, comme la lecture d'un fichier,
vous passez un callback, qui est retourné quand le contenu du fichier est chargé.
Ça vous autorise à faire beaucoup de choses en même temps,
et de ne pas bloquer votre thread principal.
Donc, créons un petit serveur HTTP.
On crée une classe HTTP.
Ça c'est le callback, et il a deux paramètres, "request" et "response".
On lui demande d'écouter sur le port 80.
Puisqu'il tourne dans le cloud, il va nous lever une erreur, parce qu'on n'a pas le droit d'écouter sur le port 80.
Regardons... Je clique sur "debug"...
La boîte de dialogue me propose d'ajouter des arguments, mais je ne veux pas.
Et j'obtiens mon erreur.
C'est exécuté dans le serveur, qui me dit que je ne peux pas accéder ce port,
il faut que j'utilise le port qui est dans cette variable, que l'on me fournit.
donc, je copie ça là.
On devrait faire autre chose, tiens, à la récupération de la requête.
Répondons, passons "200", et lançons ça.
J'ai oublié quelque chose ?
Ah, après le "200", il faut quand même que j'envoie quelque chose.
Et voila ; c'est un petit serveur web écrit en Node. Je peux l'accéder dans le cloud, et il me dit "HelloWorld".
Maintenant, un peu plus complexe ; on ajoute un compteur.
Regardons ce que ça fait.
À chaque fois que je recharge la page, il s'incrémente, mais deux fois.
C'est parce que le serveur requête aussi la favicône à chaque requête.
Pour faire en sorte que ça ne contrarie pas notre test,
on peut ajouter cette petite condition.
Désolé ?
Oui, c'est partiellement vrai.
Parce que c'est à la favicon qu'il s'intéresse...
Faute de frappe ?
Bon, aucune idée de pourquoi ça ne marche pas, mais on peut passer à autre chose.
On peut aussi positionner un point d'arrêt.
J'arrête ce process...
Et maintenant qu'on a lancé une requête, le breakpoint l'arrête.
On peut inspecter les variables, pour voir ce qui se passe.
On peut voir la pile d'appels ici, et la visiter.
Et tout ceci, ce sont les fichiers internes à Node.JS, que l'on visite.
On peut aussi regarder ce qu'est la variable "counter".
"counter" est à 1.
On débloque, et on relance la requête ; et maintenant, c'est 2.
Vous pouvez aussi changer la variable.
Et comme vous voyez, on a changé la variable ici.
Ça permet un debugging d'application auquel on est habitué dans le monde Java.
Mais ici c'est du javascript, et c'est dans le cloud.
Donc, on n'a pas d'application qui tourne localement.
Et c'est le type de choses qui deviennent possibles avec les navigateurs qui sont de plus en plus rapides.
Beaucoup plus rapides, 3000 fois plus rapides.
Cette application, en terme de vitesse et de temps de démarrage bat Eclipse, mais parce que c'est dans le cloud,
on peut faire beaucoup plus, on peut prendre l'URL, et la partager.
On n'a pas eu à installer quoi que ce soit, j'ai juste créé un projet, pas d'installation de Node,
ou de Git, ou NPM, ou quoi que ce soit.
Ce n'est même pas mon ordinateur que je suis en train d'utiliser.
Je peux prendre n'importe quel ordinateur, et j'ai toujours accès à tous mes projets.
Ça change beaucoup de choses, mais ce qui compte encore plus, c'est la collaboration.
Travailler ensemble sur du code.
Et c'est la partie suivante de cette présentation.
Il y avait un slide de plus que je voulais évoquer, sur le projet qui tourne sous Cloud9 IDE.
Ce sont tous des projets open source que l'on a démarrés et que l'on utilise.
Le plus large est APF, Ajax.org PlatForm, une librairie d'applications qui tourne dans le navigateur.
C'est open source, et ça vous permet de mélanger plusieurs types de composants, de manière déclarative.
Et il y a ACE, je vous en ai parlé, l'éditeur avec la coloration syntaxique, la complétion de code, etc.
Et Cloud9 IDE, qui est open source aussi ; elle est sur GitHub,
vous pouvez la rélécharger, et l'utiliser localement, ou sur votre serveur Web, si vous le souhaitez.
Il y a beaucoup d'autres projets, comme JSDav, WebFS, qui est un wrapper pour le FS offline de Chrome,
et aussi quelques autres librairies.
Donc, jetez-y un oeil, sur github.com/ajaxorg, si ça vous intéresse.
Donc, comme Ruben l'a dit, c'est l'étape suivante dans la collaboration.
Jetons un oeil à la collaboration : il y a des challenges habituels.
Quand vous regardez le monde, vous voyez que c'est un énorme effort de collaboration :
bureaux, immeubles, gouvernements, ... tout est collaboration !
Et la nature lui a donné une forme particulière, qui la rend efficiente et efficace !
Prenons un exemple simple encore : des enfants, qui construisent un château de sable.
Si on veut faire un truc simple, comme un gros tas de sable, tout le monde peut travailler librement,
ils travaillent en parallèle, et il n'y a aucun problème, ils font tous la même chose.
Mais une fois que la pile de sable est finie, il faut des changements dynamiques ;
les tâches vont être séparées : un enfant va creuser une trancher, un autre construire le château,
encore un autre doit construire une porte, ...
La collaboration parallèle vient d'être remplacée par une séparation des tâches,
et quand un enfant interfère avec les tâches d'un autre, il va y avoir des caprices, sous peu...
Je ne pense pas que cet enfant déteste les châteaux de sable ;
je pense qu'il ne peut juste pas séparer ses tâches convenablement avec l'autre enfant.
C'est une partie difficile de la collaboration ; et fondamentalement, il n'y a pas une seule manière de faire.
Toutes les tâches ont des paramètres différents selon la phase du process où vous êtes.
Avec le développement, tout le monde utilise sans doute un de ces contrôleurs de sources.
Et c'est la manière de collaborer du malchanceux.
Vous devez uploader votre code pour qu'il soit livré à un serveur, peut-être dans le cloud.
Et qu'il soit re-downloadé.
C'est très distant, vous n'avez pas une réponse immédiate, il faut que vous sachiez ce que les autres font,
en utilisant une autre forme de communication.
Vous travaillez séparément, chacun dans son silo.
Il y a beaucoup d'autres moyens de collaborer, et dans Cloud9, on essaie de trouver des pistes
pour faire en sorte que les développeurs travaillent en temps réel.
Avoir un IDE dans le cloud ouvre la voie à des nouveaux modes de collaboration.
Par exemple, les revues de code interactives : vous pouvez parcourir le code, et ajouter un commentaire.
Et c'est immédiatement partagé avec les autres personnes, parce que c'est dans le cloud.
Pensez aussi à l'entraide, à la formation, au partage de morceaux de codes, ou de l'URL de votre application.
On n'aura plus besoin de dépendre d'inventions comme celle-ci, pour la programmation à plusieurs.
Il y a une nouvelle manière de collaborer qui améliore l'expérience de développement.
Disons que vous avez une équipe sur un projet, je vais prendre un exemple véridique.
Avec Cloud9, on a la possibilité de partager notre environnement de travail.
Regardons un peu la situation de notre compagnie à nous :
on a des gens qui travaillent à distance, aux USA ou en Europe,
mais l'équipe centrale de développement est à Amsterdam.
Souvent, quelqu'un a un problème, il y a un bug à corriger, du code doit être produit,
ça nécessite d'y réfléchir, et d'y collaborer ; c'est pratique de travailler ensemble sur ce problème.
Comment faire ?
Avec Cloud9, tout le projet est en ligne, pas juste le code.
Le runtime, la base de données, tout est là derrière une unique URL.
Comme vous en avez l'habitude avec d'autres services en ligne,
avec Cloud9, vous pouver partager l'URL de votre environnement avec vos collègues de l'autre côté du monde.
Pour le faire, vous positionnez des permissions, lecture seule ou lecture-écriture.
Puis, votre ami rejoint votre projet.
À l'intérieur du projet, vous pourrez communiquer directement, chat, vidéo, conversations audio ;
mais avant tout, vous pouvez coder simultanément, de manière collaborative, comme vous le faites avec Google Docs.
Et non seulement ça, mais la personne qui s'est fait inviter peut lancer l'application.
En cliquant sur le bouton "debug", vous lancez le code dans un système identique au vôtre,
parce que c'est très exactement votre système.
Donc la personne n'a pas à simuler votre environnement, et la phrase "Ça marche chez moi" n'existe plus !
Donc, en résumé : les APIs dans le cloud vous aident à dimensionner,
et avoir votre code dans le cloud vous facilitent l'accès, la collaboration, et la maintenance sur vos applications.
L'intégration permet de cibler facilement des plateformes.
Donc, c'était un aperçu de l'avenir, merci de votre attention,
et si vous voulez collaborer, ou utiliser notre application, c'est en ligne sur c9.io, ou GitHub.
Merci beaucoup !
Y a-t-il des questions ?
C'est un vieux troll, désolé de le présenter !
Mais il y a un problème avec la confiance et la sécurité, et l'accessibilité, dans le cloud.
Je peux hacker dans le train, et pusher mes commits ; mais que se passe-t-il
si je possède une compagnie privée, et je ne veux pas ne plus être capable de récupérer mes données
parce que le service est down, ou a simplement fermé ?
Je ne vous souhaite pas d'avoir à fermer Cloud9, bien sûr...
Mais quels sont les problèmes de sécurité, de confidentialité, de confiance, et comment vous les gérez ?
Je pense que ce sont des soucis généralisés au le cloud ;
et je pense que le monde s'en rend progressivement compte,
de plus en plus de grosses applications tournent en ligne,
et les gens mettent beaucoup de leur valeur dedans, regardez Salesforce, par exemple.
Il y a des solutions, notamment aux problèmes de sécurité bien entendu ;
on pourrait même avancer qu'un fournisseur de cloud investira plus dans sa sécurité,
parce que c'est son "nom", et sa compagnie n'aura aucune valeur en cas de problème de sécurité.
Mais il y a des compagnies qui veulent pouvoir contrôler ça eux-mêmes.
Je pense qu'il va toujours y avoir un équilibre entre le cloud privé, et le cloud public ;
et ceux qui se soucient plus des coûts se pencheront vers les publics,
et ceux qui se soucient plus de la sécurité se pencheront vers les clouds privés.
Dans l'exemple, vous avez fait une application en Node.JS, et je me demande,
il y a plusieurs versions de Node.JS, comment vous en sortir ?
Chaque utilisateur installe sa propre version de Node.JS ?
Est-ce qu'il y a des modules spéciaux, des hacks spéciaux ?
Ou est-ce que vous le mettez à jour à la dernière version, mais du coup le code doit être mis à jour ?
Ou alors vous restez sur une version spécifique ?
Pour le moment, nous ne supportons qu'une version, mais on travaille dur,
pour gérer ce problème de versions ; et c'est dans le SDK, et dans le runtime en effet.
Ce que vous aurez, c'est un fichier de configuration, dans votre projet, qui déclare la version,
et on les supportera toutes.
On travaille ensemble avec Joyent pour supporter toutes ces versions de Node simultanément.
Bonjour, je ne vous ai jamais vu sauvegarder votre code ;
et comment est-ce que vous gérer le versionning, aussi ?
J'ai sauvegardé du code en utilisant Cmd+S, mais c'était rapide !
Si je ne sauvegarde pas, il sauvegardera quand je cliquerai sur le bouton "debug".
Pour le versionning, vous avez dû voir vers le bas l'interface en ligne de commande ;
et vous pouvez faire beaucoup de choses que vous feriez sur votre ordinateur, comme "ls" ou "cd",
ou taper "git" ; et même "git" et ce que vous voulez.
"git status", "git push/pull", "git commit", pour gérer vos versions.
On ajoute Mercurial en ce moment aussi ; Subversion n'est pas encore sûr, mais on finira probablement par l'ajouter.
Pardon ? inaudible Peut-être, peut-être...
Il demandait aussi si ça allait fonctionner avec Bazaar.
Bonjour, si j'ai bien compris, votre IDE Cloud9 exécute du Javascript du côté du serveur ? - Oui.
Du coup, est-ce qu'on devrait l'utiliser comme CDN, Content Delivery Network ?
Est-ce possible ?
Heu... non...
Ce sont des concepts très différents...
Il exécute du code, mais qui vivra uniquement sur un serveur, quelque part dans le cloud.
Donc ce n'est pas plus proche de certains réseaux, c'est à un seul endroit,
contrairement à ce que ferait un CDN.
Ok, donc c'est juste de l'exécution locale pour tester ?
Oui, l'exécution est dans le but de développer votre application ;
donc on vous fournit toute l'infrastructure pour développer votre appli, comme vous l'installeriez localement.
Juste un petit exemple : votre IDE a l'air d'utiliser MarkItUp, pour les Cmd+S et tout.
Si vous voulez refactoriser MarkitUp avec votre IDE, que va-t-il se passer ?
Je ne comprends pas vraiment la question, désolé ?
C'est écrit en Javascript, Cloud9? - Oui. - Il utilise des librairies, des plugs-in jQuery ?
Quelque chose de similaire, mais pas jQuery, oui.
Et si je veux refactoriser un plug-in jQuery, par exemple (désolé pour mon anglais)
qui est utilisé par Cloud9 IDE ? Est-ce qu'il y a des conflits entre les exécutions ?
Non, l'exécution de votre application est complètement séparée de Cloud9.
Cloud9 est juste une application qui tourne là, et quel que soit le code que vous tapez, il tourne dans une nouvelle fenêtre.
Donc il n'y a pas de conflits.
C'était ça la question que tu voulais poser ? - Ouais ouais.
Merci beaucoup. Juste pour savoir.
inaudible
Production ? Non, c'est juste pour du développement.
La question c'est : est-ce fait pour du développement, ou aussi de la production ?
Et on veut vraiment rester concentrés sur le développement.
On travaille avec d'autres compagnies qui fournissent des environnements de production,
donc vous pouvez publier votre application depuis Cloud9, vers l'environnement que vous voulez.
Vous avez montré Node.JS, mais qu'est-ce qu'il en est de Python, de Ruby, ... ?
On était à Google I/O le mois dernier, à démontrer un runtime Python,
pour pouvoir déployer dans Google App Engine.
On travaille sur ce type de runtimes, et on les ajoutera dans les mois qui viennent.
On pourrait considérer un déploiement vers Heroku, aussi ?
Où es... ? - Juste derrière. - Ah !
Désolé ? - On pourrait considérer un déploiement vers Heroku, en d'autres langages, comme PHP ?
Oui, on pense à Ruby aussi, et peut-être PHP, et on discute avec ces fournisseurs pour déployer vers eux.
Désolé pour mon anglais. Est-ce qu'il y a des services de tests automatisés dans l'outil ?
Vous parlez de développement, de plans, d'infrastructure, ...
Très bonne question. Pas encore, mais c'est sur la roadmap.
Et on est en train de construire une jolie interface, pour brancher n'importe quel framework
de test unitaire que vous souhaitez.
Et on va aussi ajouter des tests Selenium, pour que vous puissiez les lancer,
les enregistrer dans Cloud9 mais les lancer dans le cloud, pour n'importe quel navigateur.
Bonjour, j'aimerais en savoir plus sur votre business model, est-ce que le service est gratuit ?
Pourquoi devrais-je avoir confiance en un service gratuit comme le vôtre ?
Ok, le service est basé sur du freemium, c'est-à-dire qu'il y a une partie gratuite.
C'est gratuit pour une utilisation open-source ; donc si vous avez un projet open-source,
et que vous voulez travailler dessus dans le cloud, c'est gratuit.
Si c'est un projet commercial, que vous voulez avoir en privé, alors il faut payer.
Que se passe-t-il quand vous perdez la connexion ?
On peut toujours utiliser l'éditeur et écrire du code ?
La fonctionnalité "offline" devrait disponible dans quelques semaines ;
elle permettra de synchroniser tout le projet sur votre système de fichier,
et en utilisant le manifest HTML5, l'application est disponible aussi.
Donc vous pouvez faire toutes les opérations, créer des répertoires, des fichiers, etc.
les sauvegarder, les supprimer, et ils seront resynchronisés en se reconnectant.
Si vous n'êtes pas un environnement de production, comment vous gérer les déploiements ?
L'un de vos arguments était que vous êtes dans le cloud, donc c'est facile de déployer ;
mais si la configuration de l'environnement de déploiement est différent du vôtre, vous ne résolvez pas le problème ?
Ce qu'on fait, c'est qu'on travaille ensemble avec les PaaS, ou les fournisseurs d'infrastructure.
Quand vous commencez votre projet, vous pouvez choisir : je veux créer un projet Google App Engine.
Et votre environnement se configure pour que vous développiez sur App Engine.
Et quand vous déployez, il déploie sur App Engine.
Du coup, on génère de la liberté, parce que toutes ces organisations ré-invente comment on fait ça.
Nous on ne veut pas faire ça, on veut juste fournir la meilleure expérience de développement.
Je pense qu'on n'a plus de temps.
On a deux livres, qui doivent être donnés aux meilleures questions ; mais il faut que tu me donnes un coup de main.
J'ai trouvé la première question plutôt bonne. - Moi aussi, oui.
Et qui va avoir le deuxième ?
J'ai trouvé la question sur les tests très bonne. - Mais c'est un orateur !
Mais il ne peut pas l'avoir, je sais, c'est juste une remarque pour l'honneur !
Bon, du coup, on va le garder !
Je pense que...
La dernière ?
Ok, donc pour la première et la dernière question !
Félicitations !
Voila.
Vous pouvez poser quand même une dernière question en français si vous voulez, si c'est juste la langue qui vous retient.
On traduira après.
Si vous avez honte de votre anglais...
Merci beaucoup !
Merci !