La soirée du 4 juin 2013 marque l’ouverture chez Xebia du mois du JS, série d’évènements destinée à découvrir les principaux acteurs du marchés des frameworks MVC coté client.

Cette première soirée, consacrée à Ember.js, a permis à une vingtaine de personnes de découvrir comment poser les premières pierres d’une application Ember.

Lire la suite de cet article »

Depuis quelques temps, l’utilisation du javascript se démocratise. De langage permettant de faire clignoter un texte ou défiler un bandeau de pub sur votre site multimania, il est progressivement devenu un outil à part entière de toute application web, jusqu’au point, atteint récemment, d’être auto suffisant, et ainsi de voir émerger un certain nombre de librairies permettant de réaliser la partie interface d’une application (presque) exclusivement en javascript.

Pourtant, on partait de loin ! Très longtemps considéré par la majorité comme un language de bidouilleur tout juste bon à sortir du code inmaintenable, on aura tout entendu sur javascript : depuis « nan mais de toute façon javascript ca marche pas » jusqu’a « nan mais javascript c’est nul, c’est pas orienté objet : y a pas de classe » en passant par   »nan mais moi le prototype j’ai rien pigé, pourquoi ils ont fait ca, sérieux ? », sans oublier le fameux « c’est quoi ce mot clef ‘this’ qui change tout le temps ? c’est vraiment le comportement voulu ? ». Encore maintenant, alors qu’il est devenu un des outils de tous les jours de pas mal de développeurs, ce genre de question perdure, démontrant que le mysticisme autour de javascript n’est toujours pas vraiment levé…

C’est pourquoi je pense qu’il est très important de comprendre les particularités de ce langage lors de son utilisation. Langage dont les concepts sont, de plus, aussi simples que puissants, pour peu que l’on accepte qu’il ne fasse pas tout comme les autres… Cette série d’articles, qui débute avec celui-ci, aura donc cet objectif : la compréhension des concepts inhérents au langage, ainsi que les subtilités et astuces tournant autour. Back to basics.

Dans ce premier article, je vais donc tenter de montrer le plus simplement possible les différentes approches pour faire de l’orienté objet » et des « classes » en javascript (sujet qui, contrairement aux idées reçues, est abordé depuis quelques temps maintenant), jusqu’à arriver sur l’approche prototype, concept apparemment proche du voodoo, que je ne manquerai pas de démystifier. Aller, c’est parti !

Lire la suite de cet article »

Pourquoi ?

Le management de librairies externes a toujours été un casse-tête pour les développements front en javascript. Combien de fois sommes-nous allés sur le site de jQuery afin de récupérer la dernière version, de la remplacer dans notre dossier “/libs” et de faire la modification dans notre balise <script> ?. Quand on a une vingtaine de dépendances, le travail commence à devenir relativement… agaçant ; sans parler des risques de non compatibilité et la gestion des rollback. On a beau parfois râler sur maven, on ne peut nier que celui-ci soulage beaucoup les développeurs java dans sa gestion des dépendances.

Node a apporté une première solution avec son npm (Node Packaged Modules), indispensable pour le développement d’applications en node.js. Celui-ci est malheureusement uniquement orienté “back” et le travail côté front reste toujours manuel.

Puis bower s’est présenté à moi.

Lire la suite de cet article »

Backbone fut une des premières librairies à offrir une structure aux applications JavaScript. Avec le succès qu’on lui connaît — trello, airbnb, linkedin. Cet article se propose de synthétiser l’expérience de deux ans de développements à ses côtés — mauvais jours inclus — d’identifier des bonnes pratiques et d’entrevoir la suite de l’aventure.

• Plus simple, tu meurs
• Simpliste, peut-être
• Bonnes pratiques
• Idées reçues

Lire la suite de cet article »

Vous avez envie d’essayer Dart dans votre application ? Mais vous vous voyez mal demander à vos opérationnels (Ops pour les intimes) d’installer la VM Dart sur les serveurs de production (je parle ici de code Dart côté serveur).

Je vous propose de voir comment livrer, tester et déployer automatiquement un mini-serveur web en Dart qui vous affichera un JSON (exemple : xebia-dart-bootstrap.herokuapp.com) en 15 minutes, grâce au Cloud. 

Pour ceux qui regardent le podcast Dartisans ce sera quelque chose que vous connaissez déjà, pour les autres c’est peut-être l’occasion de tester cette nouvelle techno rapidement.

Lire la suite de cet article »

C’est avec plaisir que Xebia a hébergé le dernier ParisJS dans ses locaux le 30 janvier. Voici un compte-rendu de la soirée.

Marc Bourlon a ouvert cette 25ème édition de ParisJS avec la présentation d’une librairie qu’il a développée : TipTap.js (https://github.com/marcbourlon/TipTap). Il s’agit de la seule librairie JavaScript qui permette actuellement de déclencher des actions à partir d’une combinaision d’évenement "touch" ou "click". Ce type de librairie peut s’avérer très utile pour des applications web mobiles où l’espace disponible est précieux : au lieu de présenter à l’utilisateur toute une série de boutons, qu’il n’utilisera pas forcément, les fonctionnalités sont accessibles via une série de gestes. On retiendra l’exemple d’une application mobile de retouche de photo où on préfère afficher l’image en plein écran et proposer les fonctions de retouche à travers des "gestures".

Lire la suite de cet article »

Le 31 janvier prochain à 19h, Xebia accueille le Meetup Ember.JS. Dans cette troisième édition seront abordés :

• La nouvelle API du routeur qui arrive très prochainement dans la V1 du framework par Paul Chavard ;
• Retour d’expérience, un an avec Ember.JS présenté par Benoit Lemoine et Mathieu Breton sur le site mytripset.com.

Pour les inscriptions c’est ici que ça se passe.

Lieu :

Xebia
156, boulevard Haussmann à Paris
Immeuble A – 7ème étage

Ember est un framework Javascript dont l’objectif principal est de faciliter la mise en place d’architectures MVC dans les navigateurs. L’utilisation d’Ember sur un projet pose toutefois un double problème :

• Les fichiers Javascript sont faciles à découper (un fichier par classe Javascript par exemple), mais le fait de charger des dizaines de fichiers différents est contre-performant ;
• Les templates Ember sont tous présents directement dans la page html, ce qui mène rapidement à avoir une page de plusieurs milliers de lignes, et donc difficilement maintenable.

Cet article se propose donc de montrer, via l’utilisation de wro4j, comment résoudre ces deux problèmes. 

Lire la suite de cet article »

Une des grandes tendances du moment est le multi-langage. Cet article ne va pas déroger à la règle en prenant un exemple concret implémenté en Java et en proposant une version en JavaScript. Nous étudierons ensuite les avantages et inconvénients des deux solutions et regarderons un peu ce que donnent les performances comparées.

Lire la suite de cet article »

Il est fréquent que les applications web aient besoin de sécuriser certaines actions en s’assurant qu’un utilisateur identifié est connecté. L’API de Play propose l’API Security pour faciliter et uniformiser la mise en place de la sécurité sur les actions avec une approche basée sur l’extraction d’un userid depuis le cookie de session. Malheureusement l’utilisation de cette API est assez peu documentée et les actions qui l’utilisent sont difficile à tester, que ce soit en direct ou à travers le router. Ce problème remonté aux développeurs du framework a été corrigé dans une branche non publiée de la version 2.0 et intégré en 2.1. Avec l’approche de la publication de la version 2.1, il est de moins en moins probable que le correctif 2.0 soit publié un jour. En attendant de faire une migration à Play 2.1, ce court article vous montre comment backporter le helper de test de ces actions dans votre projet. 

Lire la suite de cet article »