Accéder au contenu principal

Meetup Ember JS #1

Encore une bonne surprise ce meetup consacré à ember.js !

En effet, nous nous sommes retrouvés hier soir, une bonne quarantaine de développeurs/passionnés de tout horizons, afin de participer au premier meetup organisé par Capitaine Train. Le but pour moi était une fois de plus de regarder derrière le rideau de Java et comprendre comment fonctionne ce framework MVC tout JS. Je n'ai pas été déçu, voyons pourquoi...


La rencontre

Comme tout meetup qui débute, nous sommes partis sur le format Présentations, mais ponctuées avec de très bonnes séances de Live Coding à la clé et honnêtement ce n'était pas plus mal, car ember.js n'est pas (pour ma part du moins) un framework que l'on appréhende en un claquement de doigt.

Un bref historique

Et pour cause, car ember.js est la version 2 du framework SproutCore, qui a été originalement développé par Sproutit et dont Apple a été un gros contributeur pour essentiellement sa plateforme iwork. Ce que j'ai retenu de l'introduction de Paul c'est que ember.js est une version allégée de SproutCore, en ce sens qu'il ne contient que les parties essentielles à la gestion d'un MVC simple et robuste. On trouve au menu les properties-bindings bi-directionnels, les propriétés calculées (propriété sous forme de fonction par exemple), un outil de templating efficace appelé HandleBars, qui repose sur Mustach.js, un routeur et... une machine à état permettant de formaliser les transitions entres les vues et faire une abstraction. Ainsi, il est possible de structurer et organiser une application ember.js sans un routage basé sur des URLs par exemple.

Les présentations

Nous avons eu la chance d'avoir droit à quatre présentations, rien que ça :

  • La première était une introduction assez claire sur ember.js animée par Paul. J'y ai découvert par exemple les notions d'outlet et de key value observer...
  • La seconde était une séance de Live Coding from scratch avec TextMate et Chrome animée par MartinEn deux coups d'import JS, Martin a développé une application simple et nous a montré comment "instancier" un modèle, un contrôleur avec comme vue, une simple page Html. Dans cette introduction, nous avons pu voir un peu plus en pratique Handlebars,
  • Le troisième était un introduction intéressante sur la customisation des vues. Cette présentation était animée par Grégoire. L'API d'ember.js permettant par exemple d'ajouter des attributs à chaud, mais aussi de définir proprement des templates et des compositions de templates,
  • La quatrième et dernière était une immersion un peu plus pêchue dans une application de type blog et disponible sur le github de Paul pour ceux qui veulent jouer avec.

Bilan

Et bien cette entrevue avec la communauté ember.js m'a honnêtement convaincu. En effet, j'y ai rencontré des gens, qui ont un vrai bon background de développement Web et qui ont une connaissance assez étendue des standards et outils équivalents. De ce fait, je pense que si ils ont décidé de jeter leur dévolu sur ember.js, c'est que ce choix a été mûrement réfléchi. J'ai par ailleurs oublié de mentionner que Capitaine Train utilise ember.js en production et qu'ils sont, semblerait, motivés pour animer la communauté. Donc, je ne peux que les saluer et les remercier pour cette initiative.

Quelques pointeurs

Commentaires

Mathieu ROBIN a dit…
Salut,

Merci pour ce compte-rendu !

Il y a des petites erreurs ceci dit.

Apple n'a pas développé SpoutCore. Ils ont participé comme contributeur, mais ça s’arrête là.

Ember n'est pas vraiment une seconde version de SproutCore mais une sorte de dérivé plutôt. Enfin c'est comme ça que je l'ai compris.

EmberJS n'utilise pas mustache.js mais Handlebars comme moteur de templates. Handlebars utilise juste la même syntaxe que mustache et l'enrichit à la volée.

Concernant Capitaine Train, effectivement, ça sentait la motivation chez eux. Et en effet, il y avait pas mal de gens qui avaient l'air d'avoir de l'expérience. A croire que chez les jeunes, il y a beaucoup de bricolos...
Ulrich's Blog a dit…
Merci Mathieu, je vais ajuster le post.

Posts les plus consultés de ce blog

Faire sa machine virtuelle sous Debian ARM avec QEMU

Introduction L'objet de ce article est de vous expliquer comment faire  pas à pas,  sa machine virtuelle Debian Wheezy   tournant sur un processeur ARM   avec QEMU . Il est relativement simple de trouver des ressources à ce sujet sur le Web, mais je voulais apporter ma pierre à l'édifice sous forme d'un petit  tutorial prêt à l'emploi. A propos d'ARM et d'émulation, il faut savoir qu'au jour d'aujourd'hui, VirtualBox est incapable de virtualiser un OS tournant sur ARM, cela m'a donc obligé à m'intéresser de plus prêt à QEMU. Et si vous vous demandez pourquoi, je veux émuler de l'ARM, vous le serez au prochain épisode... QEMU QEMU est un logiciel développé à l'origine par le célébrissime programmeur  Fabrice Bellard . Le succès de cet émulateur vient principalement du fait, qu'il est tout aussi capable d'émuler que de virtualiser. La principale différence entre l'émulation et la virtualisation est qu'un

Releaser avec Maven sur github

Le but de l'exercice est de releaser un projet Maven simple en utilisant le maven-release-plugin via Cygwin sur la plateforme github . En effet, la procédure serait aussi simple que sur Subversion , à la condition d'avoir ses settings et ses POM au carré, ce que nous allons voir de suite. Pour mener à bien l'opération, les pré-requis sont les suivants : Avoir un environnement de développement sous Cygwin , le mien étant Windows XP SP3 / Cygwin 2.712 , / java 1.6.0_17 / git 1.7.1 avec une auto-complétion des commandes git bien pratique, Avoir une configuration Maven opérationnelle dans le sens où vous avez accès aux maximums de repositories publics et une plateforme d'hébergement/déploiement pour vos archives. La mienne étant Maven 2.2.1 / Nexus™ Open Source Edition 1.7.1. J'avoue avoir de la chance, car j'utilise pour mes tests, ma plateforme d'entreprise (chez Vidal) configurée aux petits oignons par mon collègue Thierry que je salue au pass

Mémotech Rubik's Cube

Voici un article rapide plus destiné à un être un mémo, qu'un tutorial complet sur la résolution du Cube en 3x3x3. Je tire les informations d'un site web aujourd'hui disparu (www.rubik.gireaud.org), qui proposait des solutions pour les cubes 2x2x2, 3x3x3, 4x4x4, 5x5x5, 7x7x7. La première couronne Quand vous aurez fini la première couronne, votre cube ressemblera à ça: Le croix Le but de cette étape est de réaliser une croix qui ressemblera à ça: Comme le montre la figure ci-dessus,  il faut que la croix soit alignée avec les cubes centraux . Comme les cubes centraux ne bougent jamais (ils seront toujours au centre), c'est à vous de placer les arêtes correctement. Exemple d'une couronne mal positionnée: Ne vous souciez pas des coins ! Concentrez-vous sur les  arêtes uniquement  !! Comme c'est l'étape la plus facile, je n'ai pas détaillé toutes les possibilités de mouvements. Arrangez-vous pour placer les arêtes que vous voulez placer sur la croix sur la f