Quand on veut parler de nouvelles technologies « web », il y a de quoi faire. Depuis des mois, de nombreuses librairies ont émergé, souvent pour contourner les bugs/incompatibilités des navigateurs (jQuery) ou pour simplifier le développement d’applications web (Backbone, Knockout, AngularJS, …).

Contrairement à Flex, il n’y a pas de framework « full stack » côté client. Vous devrez donc décider quelles librairies vous allez utiliser, vous assurer qu’elles « cohabitent » bien, assembler, mélanger et vous obtiendrez peut-être une application web robuste.

Il y a des nombreuses applications web comme GMail, Google Maps, WordPress que je trouve remarquables et que j’aimerai savoir réaliser.

Au cours des derniers mois, j’ai pu tester plusieurs librairies afin de me donner une idée. Vous vous en doutez, il est impossible de tout tester dans des cas d’utilisation « réels », faute de temps. L’analyse que je vais faire n’engage donc que moi et l’expérience que j’ai eu avec ces librairies. N’hésitez pas à utiliser les commentaires si vous pensez que ce que je dis devrait être corrigé.

Mes critères sont assez simples et personnels. A noter que certains sont aussi basés sur ce que je sais déjà faire. Par exemple, je suis sûr que l’on peut faire des merveilles en PHP mais je n’y connais pas grand chose alors je ne vais pas essayer de faire le malin là dessus.

Je ne suis pas forcement intéressé par la « beauté » d’un langage / framework et je ne pense pas que le code soit « de l’art » ou de la « poésie ». Flex m’a apporté une facilité de développement dont j’ai du mal à me passer. En gros, créer des composants, taper du code, lancer en debug, faire des watch dans Eclipse ou du pas à pas dans le code, corriger et cela jusque ça marche.

Voici donc les critères qui me tiennent à coeur:

Productivité

Dans l’ensemble, il faut que la solution soit productive. C’est-à-dire que l’on arrive à créer du contenu sans y passer des heures. Ne pas passer plusieurs minutes pour tester une application, la mettre en production ou pour compiler X ou Y.

Il faut que ce contenu soit facile à maintenir et qu’il puisse être facilement réutilisé par les membres de l’équipe. Pour vous donner un exemple, la notion de « composant » en Flex est primordiale, et nous permettait de réaliser des applications complexes parfois sans effort. L’application du DRY (Don’t Repeat Yourself) et du KISS (Keep It Simple and Smart/Stupid) de manière globale permet de faciliter la maintenance et de limiter les effets de bord.

Dans l’ensemble, il faut que le développement, aussi bien côté serveur que côté client soit rapide.

Debugging

Dans une journée, je passe *beaucoup* de temps à debugger, par rapport au temps nécessaire pour écrire le code. Il faut que je puisse faire du pas-à-pas facilement, qui je puisse inspecter une valeur dans son contexte et que je puisse naviguer facilement dans mon code. Cela relève souvent du travail de l’environnement de développement utilisé (IDE) mais aussi du navigateur qui propose une partie de ces outils.

Multi-plateforme

Flash Player ne tourne pas sur le navigateur de l’iPad et cela est très embêtant, surtout d’un point de vue commercial. Sur Android, Flash Player est à la limite adapté pour afficher des vidéos mais pas du tout pour le reste. « HTML5 » fait la promesse de pouvoir s’adapter à toutes les plateformes, presque de manière « magique ». On sait tous que ce n’est pas tout à fait vrai.

Dans l’idéal, il faut une solution qui permette de s’adapter facilement à une plateforme. Ou tout du moins, qu’elle n’apporte pas de blocage pour le faire.

Un minimum de « couches »

Par expérience, plus il y a de « couches » logicielles (soit en nombre de librairies utilisées, soit en nombre de « X compilé en Y ») impliquées dans un projet, plus il est complexe à gérer. D’abord parce que la compatibilité transversale des versions est assez difficile à assurer mais aussi parce que l’introduction d’un nouveau langage / DSL doit ensuite être appris par les membres de votre équipe.

Le but est donc de minimiser le nombre de langages, sans allez dans l’excès, pour pouvoir profiter pleinement des capacités de chaque langage, individuellement.

Communauté

La « Flash Platform » a un gros atout, c’est son énorme communauté, avec de nombreuses ressources déjà disponibles sur Internet. Cela est du en partie à son âge, mais aussi à pas mal de passionnés.

Une communauté active permet d’obtenir de l’aide rapidement et de trouver des librairies ou des bouts de code de qualité sur le net.

Voici donc un florilège de ces nouvelles technos que j’ai pu utiliser.

---

Play! Framework

Certainement mon plus gros « coup de coeur » ces derniers temps. Si vous ne connaissez pas Play! Framework, je vous conseille très vivement de suivre le tutorial officiel:

http://www.playframework.org/documentation

Ce n’est pas un simple « Hello, world » mais un tutorial bien plus long qui vous permettra de découvrir les nombreuses facettes de Play. Vous allez ainsi réaliser un « blog engine », avec personnalisation, soumission de formulaire, administration, internationalisation, tests et mise en production. Pour l’avoir fait de bout en bout, cela prend moins d’une heure et permet de bien comprendre les mécanismes qui se trouvent derrière Play.

Ici, on se trouve donc côté serveur mais même si on fait beaucoup de bruit sur tout ce qui se passe côté client, le serveur reste primordial. D’autant plus que tous les moteurs JavaScript que vous utiliser vos clients ne sont pas toujours des Webkits sous stéroïdes. Vous ne pourrez pas réaliser de « Rich Internet Application » sans faire une grosse partie du travail côté serveur.

Voici ce que j’aime chez Play!:

Aucun temps de compilation

Play! s’appuie sur le mécanisme de « hot reload » d’Eclipse, qui permet de recharger du code directement dans la JVM. On peut donc modifier les sources de son projet, rafraîchir la page dans son navigateur et voir la modification.

Personnellement, ça m’a rappelé ma (toute petite) expérience que j’ai eu en PHP, et le plaisir de ne pas devoir à recharger un Tomcat ou à lancer un build install Maven pour changer 3 caractères. Productivité maximale.

Possibilités de debug

Même si tout est rechargé à la volée, on peut toujours effectuer le debug dans son IDE, cela fonctionne sans problème. Rajoutez en plus les messages d’erreurs « humainement lisibles » générés pas Play qui ne vous donne pas simplement une grosse stack trace et vous obtenez un debug bien plus aisé.

En plus de cela, on peut voir que dans la version 2.0 de Play, Google Closure Compiler sera utilisé et affichera même des warnings/erreurs de compilation JavaScript directement dans le navigateur.

Encore une fois, très bonne expérience pour le développeur.

Le templating

Je vous rabâche ça depuis un moment mais j’essaie de trouver une sorte d’équivalent aux composant Flex. Et pour l’instant, ce qui y ressemble le plus, c’est peut-être le système de templating (côté serveur) de Play. Il est en effet possible d’isoler une partie du code dans un template (ou « tag » dans le jargon Play) mais aussi d’avoir des templates dans des templates pour la création de page complexes.

Dans sa version 1.x, Play utilise Groovy pour son engine de templating. Groovy est un langage simple, qui tourne sur la JVM. Pour ce que l’on utilise dans les templates (if / for principalement), il n’y a pas besoin d’avoir une réelle maîtrise de ce langage. Si vous connaissez un peu Java, c’est presque « naturel ».

Système de build et de dépendance

Le système de build est très important dans le cycle de développement d’une application « entreprise ». Le plus répandu et bien sûr Apache Maven mais je pense ne pas me tromper en vous disant que tous les développeurs qui y ont touché ont perdu quelques cheveux.

En version 1.x, le système de dépendances de Play est constitué d’un simple fichier dependencies.yml à plat qui parait du coup très simple et plus facile à manipuler que les XML de 5 pages de Maven.

Sur ce point, je ne suis pas sûr de savoir si c’est une bonne chose. Tous nos projets Java chez Business Geografic utilisent Maven et même si cela nous a pris des semaines à être configuré correctement, il est très apprécié par les développeurs de pouvoir ajouter une dépendance et de laisser Maven se débrouiller pour les dépendances transitives au travers des repository Maven déjà populaires. Par contre, le fort ralentissement d’Eclipse au démarrage est une plaie.

Dans sa prochaine version (2.x), Play intègre un nouveau système de build nommé « SBT » (Simple Build Tool) que je ne connais pas du tout. J’espère que cela pourra permettre de gérer les projets « mixtes », car cela m’a posé beaucoup de problèmes lors de mes tests en 1.x.

Une communauté active

Le Google Groups de Play est *très* actif:

https://groups.google.com/forum/?hl=fr#!forum/play-framework

Beaucoup de messages par jour et des réponses souvent pertinentes. J’ai personnellement laissé quelques questions dessus lors de mon apprentissage et j’ai reçu les premières réponses 20 minutes après avoir posté mon message.

De même, Play est basé sur un système modulaire, avec déjà de nombreux modules développés par la communauté (100+ je crois):

http://www.playframework.org/modules

Un très bon point pour les développeurs. Côté tutoriaux, c’est un peu plus léger mais la très bonne documentation officielle comble largement ce manque.

Points d’interrogation restants

Je n’ai pas encore pu tester tout ce que je souhaitais avec Play. Voici les points qui restent encore en suspens pour moi:

• Le modèle des applications Play est complètement stateless. C’est parfait si on a un site organisé en pages avec chacune une URL mais quid des applications Ajax ou « Single Page Application » (leur nouveau nom il semblerait) pour lesquelles tout se fait de manière dynamique.
• Le passage en 2.x apporte beaucoup de changements, notamment l’apparition de Scala beaucoup plus forte qui sera également utilisée pour remplacer Groovy dans les templates. Je ne me fais pas trop de souci pour l’aspect template car ici Scala servira toujours à faire des if / for. Mais je vois de plus en plus d’exemples de controllers en Scala et pas en Java. Ce serait dommage de devoir apprendre un nouveau langage, rien que pour comprendre ce que l’on trouve sur le net (pour un oeil non averti, Scala est très difficile à lire / comprendre).
• L’évolution du système de build (voir plus haut) et son intégration avec des projets existants en tant que librairies.

Dans tous les cas, il est difficile de souhaiter revenir au développement d’application J2EE classiques après avoir touché à Play. Je n’ai même pas parlé de tous les points forts de Play, comme les performances, le clustering ou la joie de ne plus écrire de getters / setters (oh oui). Je vous laisse essayer mais vous entendrez sûrement parler de Play sur html5-tutorial.fr.

---

jQuery: Incontournable

Impossible de parler de développement web sans parler de jQuery qui est devenu incontournable. Mais jQuery est principalement une librairie qui facilite l’accès au DOM et le fait très bien. Pour réaliser une application robuste, il faudra le coupler avec d’autres librairies.

---

Twitter Bootstrap

Bootstrap est un toolkit développé par Twitter:

http://twitter.github.com/bootstrap/

Pour faire simple, Bootstrap est une feuille de style CSS personnalisable permettant de donner rapidement un look sympa à vos applications. Si vous utilisez les éléments de base HTML (h1, ul / li, input), vous allez vous retrouver avec un site qui ressemble à la homepage d’Apache Tomcat (moche). Cela serait bien plus sympa avec du style CSS mais malgré un aspect « simple », CSS est *très* difficile à maîtriser, ne serait-ce que pour les problématiques de navigateurs.

Bootstrap permet de styler les éléments de base avec un minimum de CSS. En plus de cela, pas mal de « goodies » avec la possibilité de déclarer des layout directement en CSS avec un système de grille.

Combinez cela avec la librairie de composants jQuery UI et vous obtenez une librairie de composants très sympa:

http://addyosmani.github.com/jquery-ui-bootstrap/

Très pratique pour les prototypes ou pour les applications qui seront proposées en exemple sur html5-tutorial.fr.

---

Google Closure Tools: l’inconnu masqué

Google a partagé en Open Source (mais pas en open contribution) une série d’outils, utilisés au sein de Google pour la création de web apps. Quand on voit la qualité des applications Google comme GMail, Docs, etc , on ne peut que être intéressé par ces librairies:

http://code.google.com/intl/fr-FR/closure/

Avec des références comme celles-là, on pourrait se dire que cette librairie aurait du être plus populaire que jQuery. Et pourtant, pas du tout. Si vous cherchez sur Google, vous tomberez sur de nombreux articles datant de 2009, un compte Twitter mort et des très nombreux billets qui citent cet article « Google Closure: How not to write JavaScript« . Un article qui n’est plus d’actualité mais qui ressort trop souvent. Cela rappelle un peu l’histoire de Dart et des 17K lignes de code générées.

Vous trouverez aussi des commentaires et des « jQuery VS Google Closure » sur le net, où l’on vous dit que Closure servirait plutôt à faire des « medium/large-sized applications » mais à part celles réalisées au sein de Google, on a du mal à trouver des gens fiers d’avoir développé avec Closure. Étrange, non ?

Google Closure Compiler

Un des compilateurs de code JavaScript les plus puissants / malins. Il sera utilisé dans la prochaine version de Play pour vérifier les erreurs de syntaxe. Un des gros points fort de ce compilateur, est de pouvoir « simuler » du typage. En effet, en écrivant votre JSDoc comme l’attend Google, Closure Compiler va faire la vérification des appels de votre code et vous signaler par exemple si vous appelez une méthode avec un paramètre qui n’est pas du bon type. Très appréciable quand on vient d’un langage vraiment compilé (ActionScript) mais cette notation n’est pas vraiment standard et l’intérêt reste donc « interne » à votre code. A noter que certains projets commencent à s’y mettre, notamment OpenLayers.

Google Closure Library

Une librairie pour « remplacer jQuery ». En effet, celle-ci propose l’accès au DOM mais aussi de la manipulation de données. Cette librairie est utilisée dans une grande partie des applications Google (GMail, Maps, Docs ou Google +). Une librairie pas facile à prendre en main car on trouve très peu d’exemples sur le net. Il faut soit suivre les exemples officiels (un peu légers), soit consulter le (seul) livre sur Google Closure.

La Closure Library vient aussi avec des composants UI mais ceux-ci sont très « bas niveau »:

http://closure-library.googlecode.com/svn/docs/index.html (onglet Demos)

Google propose une documentation sur la création de composants pour la Closure Library mais vous devrez tout faire vous même.

Google Closure Templates

Un système de templating made in Google. ils sont loin d’être les seuls à avoir sorti un engine de templating mais la principale force de celui-ci est le fait que les templates peuvent être compilés à la fois côté serveur et côté client. Intéressant pour le côté « DRY » des webapps.

Mon avis sur Google Closure Tools

Les technologies Google sont très intéressantes et on ne peut douter de la qualité de ces librairies quand on voit ce qu’en fait Google derrière. Seulement, il semble que la sauce n’ai jamais vraiment pris et en partant sur Closure, on se retrouve plutôt seul. Pourtant, si vous regardez le repository de la Closure Library, vous verrez que des commit sont fait quasi quotidiennement par des employés de Google. Google ne fait cependant jamais la publicité de ces librairies, on peut donc se poser des questions sur leur devenir.

L’aspect « open source » mais pas « open contribution » est aussi gênant. Après quelques recherches sur le Google Code du projet, on se rend compte que de nombreux problèmes reportés ne sont pas corrigés. Google fixe sûrement ses priorités par rapport à ses propres projets, ce qui est difficile à accepter pour un développeur hors-Google.

Certains outils sont assez indépendants pour pouvoir être utilisés sans problèmes, comme le Closure Compiler. Gardez un oeil sur ce projet.

---

Vaadin : dommage

Il y a de grandes chances que vous ne connaissiez pas Vaadin et pourtant, ce framework est intéressant:

https://vaadin.com/home

Vaadin est un framework Java « full stack ». C’est-à-dire que vous ne codez qu’en un seul langage la partie serveur et la partie cliente. Pour la génération de la partie cliente, Vaadin utilise le moteur de rendu de GWT, qui crache du HTML et du JavaScript.

Nous avons utilisé Vaadin chez Business Geografic pour la création d’interfaces d’administration, j’ai donc plus de billes pour en parler

Les bons points

Simplicité d’utilisation pour un développeur Java

Un des bons points que l’on peut accorder à Vaadin, est que « même les développeurs Java » arrivent à créer des interfaces facilement. Ce n’est pas pour basher les développeurs Java et leur capacité à créer des interfaces, mais simplement pour souligner la simplicité du code à créer. Vous avez donc un composant Java « list » qui sera en fait un composant graphique web auquel vous pouvez donner directement une Map Java comme source de données. Pas de liaison à faire entre le front-end et le back-end, de services web, tout se fait côté serveur.

Librairie de composants graphiques

Vaadin dispose d’une large librairie de composants graphiques:

http://demo.vaadin.com/sampler

Parmi ces composants, vous avez de nombreux composants que l’on a dans Flex, comme une DataGrid avec sort des colonnes et multi-sélection ou des Tree. Il y a plus ou moins tout ce que vous intégrez dans une application « classique ». Rajoutez à cela des add-ons (dont la qualité varie), vous avez un excellent set de composants.

Les mauvais points

Synchronisation client-serveur permanente

Si vous avez essayé la démonstration, vous avez remarqué que lorsque vous réalisez une interaction avec l’interface client, il y un léger délai de réaction et vous pouvez aussi voir dans la barre d’état qu’une requête a été réalisée. Et c’est bien le cas, car il y a une sorte de connexion permanente entre le client et le serveur, tout doit rester synchronisé. Cela pose pas mal de problèmes, notamment car avec plus d’une synchronisation (ouverture dans 2 onglets du même navigateur), vous avez de grosses erreurs de synchronisation qui vont apparaître. J’ai cru voir que cela allait être corrigé en version 7, qui n’est pas encore sortie.

Au delà de cela, des aller-retours incessants entre le client et le serveur vont forcement impacter la rapidité de votre application.

La taille du framework JS

Autre mauvais point, la taille du « framework » qui est transféré niveau client. Si vous regardez dans l’inspecteur Chrome, vous verrez qu’un fichier de cache est téléchargé (la première fois) à une adresse du genre:

http://demo.vaadin.com/VAADIN/widgetsets/com.vaadin.terminal.gwt.DefaultWidgetSet/C54931D9BEA8856D9B20D8C36513D14C.cache.html

Un fichier de près de 700Ko qui contient la base du framework graphique. Acceptable si vous créez des interfaces d’administration sur un intranet mais dur à encaisser si vous réalisez une web app.

La soupe aux div

Comme je le disais en début d’article, le code HTML / JS est produit par GWT. Vous n’avez pas (ou presque) la main sur le code généré et c’est assez problématique. Si vous regardez le code généré, vous verrez que c’est « la soupe aux div », c’est-à-dire des div imbriqués dans des div, avec des styles CSS inline. Sale. Et vous ne pouvez pas y faire grand chose.

De même, l’intégration de simple JS dans son application se révèle difficile. Avec Vaadin, c’est tout ou rien. Si vous venez de trouver un composant sympa sur le net, vous aurez beaucoup de mal à l’intégrer (si vous y arrivez). Voici un thread avec des utilisateurs pas contents et des créateurs de Vaadin un peu bloqués:

https://vaadin.com/forum/-/message_boards/view_message/293854

Les performances

Sur un exemple simpliste, Vaadin s’en sort bien. Mais dès que vous commencez à avoir une application assez complexe, avec des panneaux, des tableaux et une interface fluide (width/height en pourcentage), vous allez souffrir. En fait, ce n’est pas vous directement qui allez souffrir mais votre machine. Pour éviter les problèmes de compatibilité cross-navigateur, Vaadin ne laisse pas le moteur de rendu faire le layout (width / height / margin / padding). Tous ces calculs vont donc se faire en JavaScript. Cela ne se passe pas trop mal avec un moteur JS rapide tel que le V8 de Chrome mais dès que vous passez sur un autre navigateur, c’est la catastrophe. Pour vous donner un exemple, pour une application même pas excessivement complexe, le replacement des composants après un resize du navigateur peut prendre plusieurs secondes.

De même sur mobile. Par exemple, j’ai testé un des exemples de Vaadin sur un iPad (1) et le « pinch and zoom » n’arrivait même pas à se faire de manière fluide. Cela vient soit du layout des éléments, soit de la soupe aux div mais dans tous les cas, c’est un problème bloquant.

Mon avis sur Vaadin

Tout vouloir faire en Java est séduisant mais on perd la vraie force du web qui est de manipuler finement le DOM et son rendu. Vaadin peut cependant couvrir vos besoin si vous développez des applications « desktop » et que vous n’avez que des développeurs Java sous la main :).

Je ne parlerai pas de Vaadin sur ce blog.

---

node.js: pas (encore?) pour moi

Sauf si vous avez vécu dans une cave en 2011, vous avez entendu parler de node.js:

http://nodejs.org/

Node.js est une plateforme basée sur le moteur V8 de Chrome permettant d’écrire des applications en JavaScript, côté serveur donc. Le principal avantage de node.js est que ce dernier utilise un système IO non bloquant, ce qui signifie qu’il peut supporter un grand nombre de requêtes simultanées, sans que celles-ci ne se mettent dans une file d’attente. Le cas d’utilisation principale de node.js est la création de back-end pour des applications web à haut traffic et pouvant faire des échanges temps réel avec le client au travers des WebSockets.

La technologie est intéressante, mais j’ai l’impression qu’elle n’est pas vraiment faite pour moi. Premièrement parce que Play me permet de faire ce genre de back-end facilement en Java et deuxièmement parce que je n’ai pas envie de faire du JavaScript côté serveur. On est déjà « obligés » de faire du JavaScript côté client, et je m’en passerai bien. Si je peux m’en passer côté serveur, tant mieux. J’ai déjà du mal à imaginer comment créer une architecture de code correcte côté client en JavaScript et encore plus de mal à imaginer comment faire cela côté serveur.

Certains (@k33g_org pour balancer) l’utilisent pour créer de petites applications « utilitaires », pour minifier des JS par exemple ou lancer des scripts de build. C’est peut-être ce qui est vraiment intéressant mais je n’ai pas envie d’intégrer un nouvel outil dans la chaîne pour faire ce genre de trucs.

Dans tous les cas, la pirouette reste remarquable et je vous invite à essayer node.js au moins une fois.

---

CoffeeScript

Dernièrement, CoffeeScript (Coffee pour les intimes) a eu le vent en poupe:

http://coffeescript.org/

CoffeeScript est un langage qui peut être compilé en JavaScript. Vous avez donc des fichiers .coffee en entrée et des .js en sortie. La syntaxe de CoffeeScript est très bien expliquée sur le site officielle et peut faire penser à du Java sans les accolades et les « ; ».

Vous retrouvez principalement une vraie syntaxe de déclaration de classe comme vous avez l’habitude d’en écrire en Java. On déclare des classes, de l’héritage (extends), de la composition, le genre de chose que l’on ne peut pas faire directement en JavaScript. Ensuite, le transpiler CoffeeScript transforme cela en JavaScript propre que vous pouvez utiliser dans vos applications.

Le transpiler CoffeeScript peut être appelé soit directement en JS dans votre page ou à priori grâce à node.js par exemple.

Le concept est très intéressant puisqu’il vous permet de garder des fichiers structurés, plus lisibles que si vous aviez créé la même chose en JavaScript à la main.

Grâce à un module de Play! Framework, les fichiers coffee peuvent être facilement intégrés dans vos templates Play. La transpilation en JavaScript se fait automatiquement, ce qui évite d’avoir un nouvel outil dans la chaîne. Je ne pense pas l’utiliser de suite mais cela peut-être intéressant, à garder sous le coude.

---

Backbone: Utilitaires pour MVC

Comme je l’ai dit plus haut, jQuery permet de simplifier l’accès au DOM avec pas mal de bonus. C’est très bien mais cela ne va pas (trop) vous aider à faire du MVC en JavaScript comme vous aviez l’habitude d’en faire en Flex. Pour être plus à l’aide, il vous faut des Model, des Collection, un système d’évènement, etc. C’est ce que vous apporte Backbone:

http://documentcloud.github.com/backbone/

Je n’ai pas eu le temps de jouer avec mais les APIs semblent très intéressantes. Attendez-vous à voir des tutoriaux / exemples sur Backbone sur html5-tutorial.fr par la suite.

---

IntelliJ

Pour développer des applications Flex, j’utilise Flash Builder, un IDE basé sur Eclipse. Depuis quelques mois, j’entends beaucoup de bien sur IntelliJ IDEA de JetBrains:

http://www.jetbrains.com/idea/

Un IDE multi-langage et plus léger que Eclipse. Il existe une version « community » gratuite et une version payante « ultimate ». Le prix de la version « ultimate » est de 200$, ce qui est raisonnable (et moins cher que Flash Builder).

Là où IntelliJ est intéressant, c’est qu’il semble plus « à jour » qu’Eclipse, avec le support de nouveaux langages / framework. On peut voir par exemple que le support de Play! Framework est très bon:

http://www.screenr.com/O3Fs

Pour l’avoir testé pendant quelques semaines, je peux juste dire qu’au départ, on est complètement perdu quand on est utilisateur d’Eclipse. Plus de notion de workspace, raccourcis clavier différents, il faut pas mal de temps pour s’habituer mais c’est sûrement pour le meilleur.

J’ai surtout testé IntelliJ pour du développement JavaScript et j’ai été assez surpris par son « intelligence » justement et la pertinence des warnings / erreurs. De quoi éviter de perdre trop de temps à chercher une virgule oubliée ou un « this ».

---

Git & GitHub

Si vous me demandez, je vous dirais que je ne suis pas fan de Git / GitHub:

http://git-scm.com/ / https://github.com/

Le système est très bon, mais en tant qu’utilisateur, quand je tombe sur un repo GitHub, cela ressemble plus souvent à un  endroit où le développeur s’est « débarrassé » des sources avec un readme en une ligne. C’est peut-être moi mais je préfère la section Downloads d’un projet Google Code par exemple, avec des binaires téléchargeables dans N versions, le tout listé de manière claire. Et puis les fichiers non-texte comme des PDFs par exemple où il faut cliquer sur « View raw » dans GitHub pour les télécharger, je trouve cela assez moche.

Bref, je vais arrêter de râler car sans savoir se servir de Git / GitHub, on peut rater pas mal de beaux projets. Cela peut aussi me servir pour stocker les sources des projets d’exemple que je fournirai sur html5-tutorial. Cette année, j’apprends à me servir de Git :).

---

Gestion de configuration et automatisation de déploiement: Puppet / Chef / …

Voilà un domaine dans lequel je n’y connais absolument rien. Mais alors rien du tout. Par contre, je trouve le sujet très intéressant. Puppet et Chef sont deux outils différents permettent de gérer le déploiement d’applications, sur votre cluster privé par exemple. Ces outils sont aussi appelés « outils de gestion de parc ».  Il y en a d’autres mais ce sont ceux dont j’ai le plus entendu parler, désolé pour les autres.

Je ne sais pas dans quelle mesure je vais avoir la possibilité d’en parler mais j’ai envie de creuser le sujet. L’automatisation du processus de déploiement en dev / prod est le genre de pratique qui peut vous faire gagner du temps mais aussi rendre votre application plus robuste. A voir donc!

---

Mais encore…

Ça fait déjà un joli paquet de choses à expérimenter. En plus de cela, d’autres sujets m’intéressent comme par exemple tout ce qui est calcul distribué. Chez Business Geografic, on a un vrai Data Center sous les pieds nommé SynAAps. Celui-ci peut contenir 1600 lames (en étant à la moitié de sa capacité) et dispose d’une connexion directe avec les grands noeuds réseau. Autant être clair, un « cloud » sous les pieds, il faut l’utiliser à bon escient. On parle souvent de technologies qui peuvent facilement être mises en « cluster » (une grappe de serveurs) comme Play mais vous oblige aussi à gérer de nouvelles problématiques de synchronisation et de distribution (BDD, RPC, Messaging, …).

Difficile de trouver plus d’information sur la mise en place de tels systèmes sur le net, sûrement car c’est souvent un hébergeur « cloud » qui s’en occupe. Vous pouvez ordonner à Heroku par exemple d’ajouter des dynos et il va faire le boulot tout seul. J’espère trouver du temps pour pouvoir aussi partager quelques petites expériences sur le sujet car on ne fait pas tous du web. Dans « le monde de l’entreprise », on installe souvent chez le client, au chaud derrière un firewall.

---

Conclusion

Gros article pour commencer avec un petit tour de ce qui va être abordé sur html5-tutorial.fr. Comme vous l’avez lu, il y a du bon et du moins bon. J’ai souvent un avis assez catégorique, n’hésitez pas à vous faire entendre dans les commentaires.

Pour commencer, je vais surtout creuser le développement l’application avec Play (1.x) avec du jQuery pour la partie web.