Skip to content

Blogs de Développeurs: Aggrégateur de Blogs d'Informatique sur .NET, Java, PHP, Ruby, Agile, Gestion de Projet

Forum Logiciel

Forum Logiciel : diffusion de connaissance et d’informations sur toutes les activitĂ©s liĂ©es au dĂ©veloppement d’applications informatiques en entreprise.

Agrégateur de flux

PiĂšges de l’Agile n°2: L’Agile endettĂ©

Tranches de vie

Voici un extrait d’une conversation entendue pendant la rĂ©trospective de fin d’itĂ©ration d’un projet Agile A, entre les DĂ©veloppeurs et le Product Owner :


P.O: Avec seulement deux stories sur les sept planifiĂ©es en dĂ©but de sprint, je peux vous dire qu’on n’avance pas Ă  un bon rythme.
DĂ©v. 1: C’est clair.
P.O: Ce qui pose le problĂšme de ce que l’on va ĂȘtre capable de montrer Ă  la dĂ©mo du COMEX. Ça a une certaine importance, parce que je comptais sur cette dĂ©mo pour faire avancer les choses du cĂŽtĂ© du service utilisateur.
Dév. 1: Clairement durant ce sprint on a été énormément ralenti..
P.O: Par quoi ? Les stories que je produis ne sont a priori pas plus compliquĂ©es que d’habitude.
DĂ©v. 2: OK, moi je pense savoir ce qui nous ralentit..
P.O: On t’Ă©coute.
DĂ©v. 2: Ce qui nous ralentit, c’est qu’on a de la dette technique Ă  ne plus savoir qu’en faire: il y a des modules entiers sans tests unitaires, d’oĂč tous ces bugs qu’on a dĂ» corriger pendant le sprint; il y a beaucoup de code redondant, et du code mort aussi, certaines parties du code sont incomprĂ©hensibles pour moi, et elles ne respectent pas les conventions de noms habituels..
DĂ©v. 3: Tu veux parler du code de Jean-Michel?
DĂ©v. 2: Pas seulement, en fait.
DĂ©v. 1: Bref, en ce moment, c’est un peu compliquĂ© de faire plus vite.

Voici un extrait d’une conversation entendue pendant la rĂ©trospective de fin d’itĂ©ration d’un projet Agile B, entre les DĂ©veloppeurs et le Product Owner:

P.O: J’ai drĂŽlement apprĂ©ciĂ© que vous ayez rĂ©ussi Ă  mettre en place le systĂšme de localisation pendant ce sprint! Ça va en jeter pour la dĂ©mo du cĂŽtĂ© du service utilisateur!
DĂ©v. 1: Ah oui! Tant mieux.
P.O: Alors merci pour ça!
DĂ©v. 1: Bah de rien.
DĂ©v. 2: Oui mais: ce systĂšme de localisation il faudra le revoir..
P.O: Ah bon, pourquoi ?
DĂ©v. 2: Parce qu’on a violĂ© certaines de nos rĂšgles de design pour l’implĂ©menter. C’est un hack.
P.O: Qu’est-ce que tu entends par « un hack » ?
DĂ©v. 1: Une solution temporaire en quelque sorte. Bref c’est de la dette technique.
DĂ©v. 3: Tiens d’ailleurs, je mets la tĂąche de refactoring  pour le sprint suivant.
DĂ©v. 2: Post-it violet! La dette technique, c’est en violet.
DĂ©v. 3: Ah oui, merci.

Dette technique ?

La diffĂ©rence marquante entre ces deux conversations, c’est l’usage qui est fait de l’expression « dette technique ». Dans le projet A, l’Ă©quipe rencontre des problĂšmes de qualitĂ© interne qui l’empĂȘchent de livrer autant de fonctionnalitĂ©s qu’elle le voudrait, et c’est ce qu’elle dĂ©signe par « la dette technique ». Dans le projet B, l’Ă©quipe rencontre peut ĂȘtre des problĂšmes de qualitĂ©, mais en tout cas, ce n’est pas ce qu’elle dĂ©signe par « dette technique ». Ce qu’elle designe, prĂ©cisĂ©ment, par ce terme, c’est la mise en place d’une solution temporaire, n’obĂ©issant pas aux standards habituels de l’Ă©quipe, mais qui permet de gagner du temps Ă  court terme.

 

Dans le premier cas, le terme dĂ©signe une maniĂšre de qualifier le code, de parler de sa qualitĂ© gĂ©nĂ©rale, qui pour le coup paraĂźt relativement prĂ©occuppante, bien qu’aucun remĂšde ne semble clairement identifiĂ©. Dans le deuxiĂšme cas, il dĂ©signe un expĂ©dient temporaire, un Ă©cart ponctuel aux standards de l’Ă©quipe, pour lequel une solution de recouvrement est non seulement identifiĂ©e, mais en plus planifiĂ©e dans le temps. Bien sĂ»r, on pourrait dire que l’Ă©quipe A a pu se « surendetter » Ă  coups d’expĂ©dients successifs. D’ailleurs, Ward Cunningham, qui est l’auteur de cette analogie, pointait dĂ©jĂ  — il y a plus de 20 ans — le risque de dĂ©rive vers un endettement technique gĂ©nĂ©ralisĂ©:

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.

 

En effet, lorsque l’Ă©quipe « emprunte techniquement », c’est Ă  sa propre vĂ©locitĂ© future, ainsi qu’au client indirectement: sans un prompt remboursement, celui-ci sera Ă  terme gratifiĂ© d’une solution temporaire qui a rendu service sur le coup, mais qui a aussi fait long feu. Qui coĂ»te, maintenant, bien cher. Et on sait qu’en logiciel, paradoxalement, le temporaire dure.

 

De la métaphore au modÚle

Continuer d’appeler « dette technique » ce qui relĂšve en fait d’un problĂšme gĂ©nĂ©ral de qualitĂ© dans le design ou le code d’une Ă©quipe, fait perdre toute son utilitĂ© Ă  cette mĂ©taphore. ConsidĂ©rez l’endettement financier d’une entreprise: l’entreprise s’endette afin d’investir, et elle investit afin de s’enrichir. Aucun chef d’entreprise ne dĂ©clarerait : « Nous nous endettons, nous ne contrĂŽlons pas vraiment le phĂ©nomĂšne, et n’avons pas vraiment d’idĂ©e de ce qu’il faut faire pour y remĂ©dier, mais en attendant, c’est ce que nous faisons ».

 

En revanche, dans le monde de l’IT, tout le monde ou presque utilise aujourd’hui la notion de dette technique prĂ©cisĂ©ment dans ce sens, c’est Ă  dire, finalement, pour exprimer l’idĂ©e d’une fuite en avant. Comme il est difficile de constater une fuite — mĂȘme une fuite en avant — sans tenter de montrer qu’on ne reste pas Ă  rien faire devant le problĂšme, on a Ă©galement identifiĂ© des moyens de mesurer la dette technique — un exploit dans l’art de faire dire aux chiffres n’importe quoi — passant ainsi subtilement de la mĂ©taphore, au modĂšle d’analyse d’impact. C’est dire si le problĂšme du surendettement technique incontrĂŽlĂ© s’est rĂ©pandu. Or une Ă©quipe engluĂ©e dans la dette technique au point d’avoir besoin d’outils pour la mesurer, c’est un peu comme une Ă©quipe qui dĂ©clarerait: « Nous accumulons des problĂšmes de qualitĂ© interne, nous ne contrĂŽlons pas vraiment cette dĂ©gradation, et nous n’avons pas vraiment de contre-mesure, mais en attendant, nous pouvons la mesurer, et c’est ce que nous faisons ».

 

Cette mĂ©taphore est-elle utile Ă  une Ă©quipe au prise avec des problĂšmes de qualitĂ©? C’est douteux. Lorsque le Product Owner — ou le Manager, ou le Technical Leader, ou qui vous voulez — n’est pas en mesure de traiter efficacement l’alerte sur les agios exorbitants que l’Ă©quipe est dĂ©jĂ  en train de subir, que peut signifier s’endetter techniquement ? Utiliserait-on encore la notion de dette dans un systĂšme financier oĂč la banque ne viendrait jamais rĂ©clamer le paiement des termes, principal et intĂ©rĂȘt ?

 

Chaque Ă©quipe utilise Ă©videmment les mĂ©taphores comme elle l’entend pour dĂ©signer telle ou telle partie de sa rĂ©alitĂ©. Mais lorsqu’une Ă©quipe se se rĂ©fĂšre Ă  un pattern, comme par exemple Singleton ou Observateur, c’est en gĂ©nĂ©ral dans l’idĂ©e d’utiliser ce pattern tel qu’il a Ă©tĂ© documentĂ©, afin de remĂ©dier Ă  un problĂšme similaire Ă  ceux que le pattern rĂ©soud habituellement.  Or avec l’Ă©quipe citĂ©e en premier exemple, il semble que l’emploi du terme ne sert aucune dĂ©marche particuliĂšre, si ce n’est jeter un voile pudique sur une rĂ©alitĂ© dure Ă  admettre (que certains appellent, loin des slides officiels, le « code Ă©crit Ă  la rache »). Force est de constater qu’on est passĂ© du pattern Ă  l’anti-pattern. 

 

Comment s’y repĂ©rer ?

Pour autant faut-il jeter le pattern aux orties? Loin s’en faut. Comme le montre l’exemple de l’Ă©quipe B, la notion d’emprunt Ă  court terme est particuliĂšrement utile — parce qu’elle dĂ©crit une situation nĂ©cessaire, inĂ©vitable dans toute Ă©quipe Agile, Ă  savoir le conflit entre les besoins Ă  court terme du projet, de l’Ă©quipe, du client, et les besoins Ă  moyen ou long termes de ces mĂȘmes parties. Si elle ne cherchait pas Ă  ĂȘtre Agile, l’Ă©quipe excellente ne contracterait jamais de dette technique. Et c’est parce qu’elle recherche l’excellence autant que l’agilitĂ©, que l’Ă©quipe Agile utilise ce pattern. Si on comparait le travail d’une Ă©quipe de dĂ©veloppement Ă  une partie d’Ă©chec, ou pourrait exprimer cette diffĂ©rence comme suit:

  • La dette technique « tactique », c’est comme un sacrifice (un Ă©change temporairement dĂ©favorable) Ă  un moment clĂ© de la partie. 
  • La dette technique « endĂ©mique », c’est plutĂŽt comme perdre ses piĂšces les unes aprĂšs les autres, et courir Ă  la dĂ©faite.  

A quoi reconnaĂźt-on qu’une Ă©quipe fait des « emprunts techniques » temporaires afin de s’assurer un avantage (Ă©galement temporaire) plutĂŽt que de s’endetter jusqu’au cou ? Il suffit d’observer ses pratiques, et d’Ă©couter ce qu’elle rĂ©pond Ă  ces questions:

  • Avez-vous un standard documentĂ© que vous pouvez afficher, ou expliquer via une session en binĂŽme ?
  • Avez-vous des tĂąches de recouvrement prĂ©vues pour les « emprunts » techniques en cours ?
  • Les tĂąches de recouvrement s’Ă©coulent elles au mĂȘme rythme que les tĂąches standards de dĂ©veloppement ?

A l’inverse, Ă  quoi reconnaĂźt on une Ă©quipe engluĂ©e dans la « dette technique » ? Voici des symptĂŽmes qui ne trompent pas:

  • Sur le tableau de l’activitĂ© de l’Ă©quipe, les tĂąches de recouvrement sont dĂ©finies en prioritĂ© basse, et s’accumulent de semaine en semaine.
  • Des graphiques dĂ©taillĂ©s affichent les rĂ©sultats des outils d’analyse automatique du code, comme la complexitĂ© cyclomatique ou le taux du couverture du code par les tests.
  • Quand on l’interroge sur ce pattern, l’Ă©quipe voit la dette technique comme un problĂšme, et non comme une solution.
Alors que faire?

Si votre Ă©quipe vous semble aux prises avec un problĂšme gĂ©nĂ©ral de qualitĂ©, vous pouvez vĂ©rifier quel usage elle fait gĂ©nĂ©ralement du terme « dette technique ». C’est un bon signal d’alarme. Et si l’alarme sonne en effet, que faire ?

  • Provoquez un temps d’arrĂȘt pour Ă©tablir un dialogue autour de ce problĂšme. Vous ne pouvez pas mener un dĂ©veloppement logiciel Ă  coups de dettes techniques rĂ©pĂ©tĂ©es, et encore moins en vous appuyant sur du code de mauvaise qualitĂ©.

  • Demandez Ă  votre Ă©quipe de dĂ©cider quels standards elle veut appliquer dans son travail. Rendez le standard explicite. Pour cela il ne suffit pas de produire un document mais il faut confronter rĂ©guliĂšrement les Ă©carts Ă  ce standard, au moyen de revues de code rĂ©guliĂšres, facilitĂ©es et documentĂ©es, ou bien par exemple en adoptant la pratique du pair programming.

  • Mesurez, au cours des revues, ce que l’Ă©quipe dĂ©note comme des dĂ©fauts de qualitĂ©. Tenez Ă  jour le nombre de dĂ©fauts relevĂ©s par revue, afin de vĂ©rifier que les actions prises remĂ©dient au problĂšme de qualitĂ©.

  • Travaillez sur les facteurs de « dette technique », c’est Ă  dire sur les pratiques de l’Ă©quipe, et non sur le code endettĂ© lui mĂȘme. La dette technique « endĂ©mique » est un dĂ©gĂąt. Travailler seulement sur les dĂ©gĂąts sans tenter de changer les facteurs, c’est comme tenter d’Ă©coper sans rechercher les voies d’eau. Aucun « gestion de la dette technique » ne permet de remĂ©dier Ă  l’absence des pratiques de base du dĂ©veloppement: testss unitaires systĂ©matiques, revues de code.

  • Mettez en place des formations, des groupes de lecture, des expĂ©rimentations visant Ă  mieux connaĂźtre et mettre en oeuvre des pratiques de qualitĂ©.

Et que ne faut-il pas faire?

 

Ne pointez pas du doigt. Ne blĂąmez pas vos Ă©quipiers pour la façon dont ils traitent le problĂšme ou pour leur usage plus ou moins appropriĂ© du terme « dette technique ». Il y a une image de paresse apparente dans certaines Ă©quipes en butte avec des problĂšmes de qualitĂ©, dans lesquelles pourtant mĂȘme les moins courageux travaillent jusqu’Ă  10 heures par jour, tous les jours. Il y a en effet deux sens au mot courage: ce peut ĂȘtre le courage de ne pas reculer devant la peur, ou bien celui de ne pas reculer devant l’effort. Si votre projet est « complĂštement endettĂ© », le courage qui manque probablement, ce n’est pas celui de travailler plus dur, c’est celui de mettre un terme Ă  la fuite en avant et de commencer Ă  investir une partie du temps sur l’amĂ©lioration des pratiques. C’est Ă  dire le courage de dire « non ».

 

Bon courage!

 

Catégories: Blog Société

LCC 112 - Insérer la disquette 12/15

Arnaud, Emmanuel et Guillaume sont rejoints par plein de primo crowdcasteurs pour cet épisode. On y parle de beaucoup de sujets, notamment les lambda, performance, audit, OSGi, Eclipse et WebIDE sans oublier le débat du web de la semaine AngularJS 2.0.

Enregistré le 6 novembre 2014

Téléchargement de l’épisode LesCastCodeurs-Episode–112.mp3

News Langages

Lambdas en Scala et en Java du point de vue du bytecode
Lambdas et exceptions
Eviter Java 8 Optional dans vos POJO
Bye bye le JAR file

Functional programming course

Performance de différentes hashmap
Le blog d’Aleksey Shipilëv - merci à Cédric Champeau

Crypto en Java
Parameter names in Java

TypeScript 2.0
Un script engine javax.script pour CoffeeScript
https://gist.github.com/glaforge/f7ddece9d4e0ff2afe82 Ceylon 1.1.0
The future of Ceylon
Metaprogramming avec Groovy

Librairies

Concurrent trees, radix / suffix trees
Remplacement de java.util / java.util.concurrent par Cliff Click (plus scalable / efficace en multithreading)
Nouvelle librairie OSS pour du machine learning
Javers: Java object diffing / versionning for audit trails
Hibernate Envers

Infrastructure

HTTP 2.0
Max OS X Yosemite et /usr/local/bin “bug”
Faille de sécurité SSL v3 - Poodle
Oracle Linux vient avec… MariaDB
Docker 1.3

Middleware

OSGi: Le dessous des cartes - merci à Mikael Barbero
Le dessous des cartes
OSGi
Equinox
Equinox: Improving and Evolving the Core Framework par Tom Watson (IBM) March 28st 2013
Equinox Framework: A Happier OSGi R6 Implementation par Tom Watson (IBM) March 18th 2014

Infinispan 7
Jar Jar Links
Maven Shade

SpringOne 2GX - merci à Charles Bouttaz et Brian Clozel
Les présentations sur Infoq bientôt disponibles au public.
Spring Framework 4.1 - handling static web resources

Vie numérique

Se faire hacker son compte en 2 factor
iCloud copie vos documents dans les nuages
Faire de l’argent d’un produit Open Source

Outils

HTTPie

Release d’automne de la fondation Eclipse - merci à Jérémie Bresson
Luna SR1 is available!
Mars M2 is available for download or grade
Java Tools and Technologies Landscape for 2014

IntelliJ IDEA toujours sur Java 1.6 sous Mac OS X
IntelliJ 14 is out
CodeEnvy réarchitecturé en microservices

Web IDEs - merci à Jérémie Bresson
Eclipse Cloud Development
Eclipse Flux
Eclipse Che

Web

Bootstrap 3.3
Angular 2.0 non compatible avec Angular 1.x
Gens pas contents des gros changements de Angular 2
AtScript
AtScript vu par la presse

AeroGear 2.0
Introduction à D3.js par Square

Débat

Différentes cultures face au temps

Outils de l’épisode

vimswitch

Spock - merci à John Schoonheydt
Spock
Setup du pom
Page du projet
Bien comme 1er article prise en main mais débutant
Plus en détail

Conférences

Devoxx
Soutenez RivieraDEV

Global Day Of Code Retreat le 15 novembre - merci à Bouttaz et Brian Clozel - s’inscrire :

Nous contacter

Contactez-nous via twitter http://twitter.com/lescastcodeurs
sur le groupe Google http://groups.google.com/group/lescastcodeurs
ou sur le site web http://lescastcodeurs.com/
Flattr-ez nous (dons) sur http://lescastcodeurs.com/
En savoir plus sur le sponsoring? sponsors@lescastcodeurs.com

Catégories: Blog Individuel

Petit-dĂ©jeuner : Objets ConnectĂ©s – We Are Able

Dej-mobilité-blog

We Are Able : capables de quoi ? Mais de tout. 

Il faut considĂ©rer ces nouveaux objets intelligents comme bien plus que des gadgets qui vont s’échanger sous le sapin. Leur ambition est bien d’amĂ©liorer notre vie. Les premiers domaines d’application visĂ©s sont notamment dans la santĂ© sur les sujets du diabĂšte, de l’obĂ©sitĂ© ou encore des maladies cardio-vasculaires. On parle mĂȘme d’un marchĂ© (matĂ©riels, logiciels et services) estimĂ© Ă  plus de 40 Md de $ d’ici Ă  2020.
Le monde est-il prĂȘt pour cette nouvelle disruption technologique ? Nous en sommes intimement convaincus. L’explosion des Smartphones a permis d’établir quelques standards clĂ©s qui sont des fondements : 4G, Bluetooth Low Energy, NFC sans oublier les Ă©cosystĂšmes de dĂ©veloppement d’applications mobiles.

Les montres intelligentes captent l’attention mĂ©diatique et elles ne sont que la premiĂšre manifestation tangible d’une toute nouvelle classe de produits. Des pans entiers de l’industrie sont en mouvement dans les domaines de ladomotique, l’habillement, capteurs intelligents, bijouterie, lunettesou casques immersifs.

Quant au Smartphone, loin de se faire dĂ©trĂŽner, il devient le maĂźtre d’orchestre de ces nouveaux capteurs, notre porte d’entrĂ©e dans cet univers numĂ©rique.

Lors de ce petit-déjeuner, nous aborderons les thÚmes suivants :

  • Quels produits sont disponibles sur le marchĂ© et que nous promettent les constructeurs ?
  • Que peut-on faire avec une montre ou des lunettes connectĂ©es ?  Ces nouveaux terminaux vont-ils rĂ©volutionner nos usages ?
  • Comment rĂ©aliser une application adaptĂ©e ? Quel type d’Ă©quipe faut-il mobiliser ?
  • Pourquoi se positionner dĂšs aujourd’hui sur ces nouveaux usages ? Quels retours ont obtenu ceux qui ont dĂ©jĂ  franchi le cap ?

Au terme de ce petit-dĂ©jeuner, vous bĂ©nĂ©ficierez des retours d’expĂ©rience d’OCTO Technology et de trois entreprises françaises ayant dĂ©jĂ  une application en production :

  • Meetic : Thomas Diavet – R&D Manager
  • BNP Paribas : David Dahan – Mobile Manager BNP Paribas & Hello bank!
  • Le Monde : Edouard Andrieu – Responsable nouveaux Écrans

Ces retours vous permettront de :

  • ConnaĂźtre les motivations d’une entreprise pour les projets wearables
  • DĂ©couvrir les impacts de ces rĂ©alisations
  • Apprendre l’essentiel pour ĂȘtre prĂȘts Ă  lancer sereinement vos propres projets autour des wearables

Cliquez ici pour participer à ce petit-déjeuner

Catégories: Blog Société

HTML5 est-il accessible ?

Clever Age - Blog - ven, 11/07/2014 - 10:09

On nous pose souvent la question : « HTML5 est-il accessible ? » D'une part, HTML5 n'est pas une seule entitĂ©, un seul corpus technique ; d'autre part l'accessibilitĂ© n'est jamais tranchĂ©e binairement, c'est une gradation (de « trĂšs accessible » Ă  « pas accessible » selon les cas au sein d'une mĂȘme page, souvent). Tentons d'Ă©clairer la discussion.

HTML5 est qualifié par certains experts de « HTML5 and friends. » Il s'agit en effet de séparer le langage de balises, HTML, de ses API (les moyens pour le navigateur d'interagir avec le langage et avec son environnement).

De nouvelles balises de structure

Les nouvelles balises de structure, header, footer, article, etc. ne servent qu'à indiquer des informations qui manquaient dans le HTML4 et qui soulignent la sémantique globale du document.

Elles ne sont pas comprises par les anciens navigateurs (jusqu'Ă  IE9) , mais la rĂšgle de fallback (contournement) qu'ils appliquent est trĂšs simple : si une balise n'est pas comprise, afficher son contenu [1]. Autrement dit : si header n'est pas compris, affichons tout de mĂȘme le contenu du header. Il existe mĂȘme une petite bibliothĂšque Javascript (html5shiv) pour que les anciens Internet Explorer acceptent de les afficher proprement et mĂȘme de leur appliquer des styles comme un navigateur moderne.

Ces balises de structure ne posent pas de problĂšme d'accessibilitĂ©, et il y a fort Ă  parier qu'elles seront mĂȘme utiles, Ă  terme : aujourd'hui on peut s'appuyer sur l'attribut role pour dĂ©finir des zones notables dans la page (des landmarks). Par exemple une zone de recherche peut se voir attribuer un role="search", la partie principale du document un role="main", etc., et un raccourci clavier dans Jaws [2] permet de sauter de l'une Ă  l'autre.

La sĂ©mantique des balises de structure fait mĂȘme l'objet d'un rattachement formel aux rĂŽles ARIA dans un working draft au W3C.

On peut imaginer qu'à terme on pourra aussi, à l'aide d'un raccourci clavier, naviguer d'un élément de structure à l'autre (de la navigation à la recherche, de la recherche au contenu principal, du contenu principal au pied de page, etc.).

Un nouvel algorithme de hiérarchie de la page

Parmi les nouvelles balises de structure que nous venons de dĂ©crire, il y a aussi section. Cette balise permet de dĂ©finir des sections dans la page (d'oĂč son nom), et dans chaque section l'algorithme HTML5 prĂ©voit de rĂ©initialiser le plan de page.

Jusque-là une hiérarchie correcte en HTML4 était :

Titre niveau 1
Titre niveau 2
Titre niveau 2
Titre niveau 3
Titre niveau 2

En HTML5, on peut écrire conformément à la spécification la structure suivante :

Titre niveau 1

Titre niveau 2


Titre niveau 2
Titre niveau 3


Titre niveau 2

L'algorithme de structure de la page doit renvoyer la mĂȘme hiĂ©rarchie :

  • Titre niveau 1
    • Titre niveau 2
    • Titre niveau 2
      • Titre niveau 3
    • Titre niveau 2

En résumé, un titre dans une section devient automatiquement « l'enfant » du titre précédent dans la hiérarchie de la page. Charge au navigateur de reconstituer correctement cette hiérarchie dans sa moulinette interne.

Pour le moment la seconde structure hiĂ©rarchique (celle de HTML5), n'est pas rĂ©interprĂ©tĂ©e par les outils d'assistance (ni mĂȘme par les navigateurs au moment oĂč nous Ă©crivons ces lignes [3]). Sur ce point-lĂ , on note une lĂ©gĂšre perte en termes d'accessibilitĂ©. Un utilisateur d'outils d'assistance risque simplement de ne pas comprendre les relations hiĂ©rarchiques entre les Ă©lĂ©ments de titre, le temps que les outils se mettent Ă  niveau. Pour autant, ça n'empĂȘche tout de mĂȘme pas de sauter de titre en titre (lĂ  encore il existe dĂ©jĂ  un raccourci clavier).

Des balises média

Nouvelles balises de HTML5, audio et video posaient un souci d'accessibilité la derniÚre fois que j'ai regardé, parce que leurs contrÎles (les boutons play, pause etc.) n'étaient pas capables de prendre le focus (autrement dit, le clavier ne passe pas sur l'ensemble des contrÎles de l'interface). On ne pouvait donc pas contrÎler la vidéo ou l'audio. Dans Firefox par exemple, on peut tabuler jusqu'au lecteur vidéo, appuyer sur la touche espace pour lancer la vidéo, appuyer à nouveau sur la touche espace pour la mettre en pause, mais impossible de déplacer le curseur de temps ou de changer le volume.

Par contre, contrairement aux players vidéo en Flash par exemple, il existe une API normalisée pour pouvoir parler à ces éléments audio et video en Javascript, par exemple monMedia.play(), monMedia.pause(), etc.

LĂ  encore le principe est plutĂŽt celui d'une accessibilitĂ© “built-in” plutĂŽt que d'une rĂ©tro-ingĂ©nierie.

De mĂȘme, l'intĂ©gration des sous-titres fait l'objet d'une API assez simple : il suffit lĂ  encore d'ajouter une balise (track) qui pointe vers le fichier de sous-titre.

De nouveaux attributs de champs de formulaires

Les Ă©lĂ©ments de formulaires bĂ©nĂ©ficient de nouveaux attributs : en particulier un certain nombre de nouveaux types de champs qui permettent sur un mobile ou une tablette de faire apparaĂźtre le clavier le plus adaptĂ© Ă  la saisie : type="email", type="url" ne donnent pas le mĂȘme rĂ©sultat qu'un simple champ texte (type="text"). À l'aide de ces nouveaux types de champs, on amĂ©liore l'ergonomie/l'accessibilitĂ© sur les interfaces touch.

Si le navigateur ne comprend pas les nouveaux types [4], le mécanisme de fallback des navigateurs est tel qu'on se retrouve avec un input qui se comporte comme un champ texte. Aucune perte d'accessibilité a priori, donc.

Un type qui peut poser problÚme cependant, c'est le type="date", dont l'interface n'est pas documentée. Par conséquent, pour l'instant à ma connaissance l'accessibilité du composant implémenté par les navigateurs desktop laisse à désirer (pas de gestion correcte du clavier notamment). Ce type a été testé dans Opera avant qu'il n'hérite du moteur de Webkit [5], il affichait un calendrier qui était un vrai point de blocage au clavier (mauvaise gestion du focus, interface mal exposée aux outils d'assistance).

Pour la petite histoire, les navigateurs desktop récents que j'ai sous la main n'implémentent pas le type de champ « date » (à l'exception de Chrome), ce qui peut s'expliquer notamment par le manque de moyens de transformer l'affichage de la date pour la rendre conforme à la langue de l'utilisateur [6].

Les fabricants de navigateurs dans leur course concurrentielle sont malheureusement souvent plus pressés de lancer des features que de s'assurer de leur accessibilité. Mettons donc pour le moment un bémol sur ce type d'input, à utiliser avec précaution aprÚs avoir testé les problÚmes éventuels.

Une API DOM

Pour la premiÚre fois de son histoire, HTML5 documente l'API DOM : en clair ça veut dire que chaque élément HTML est listé ainsi que toutes les propriétés qu'il doit exposer à Javascript, et toutes les méthodes Javascript qu'on peut lui appliquer. Par exemple, l'élément image (img) nous donne accÚs à l'adresse de sa source (src) en lecture (dis-moi quelle ressource tu affiches) et en écriture (affiche telle ressource à la place de la source d'origine) ; l'élément video, on l'a vu, nous permet de le jouer (play()) et de le mettre en pause (pause()), etc.

Je ne note pas de souci d'accessibilité à ce niveau-là : le Javascript est ce que l'on en fait. Nous avons enfin une chance de nous attendre à des comportements documentés, normalisés, donc de simplifer le codage : à terme on se libÚrera du temps pour mieux écrire son code et se concentrer sur sa qualité (et donc potentiellement son accessibilité) plutÎt que sur la compatiblité multi-navigateurs.

Des nouvelles API

Les nouvelles API liées à HTML5 (localStorage qui permet de stocker des données localement, utile par exemple pour accélérer la navigation, geolocation pour savoir géolocaliser le navigateur et lui proposer des services contextualisés) n'ont pas vraiment grand-chose à voir avec l'accessibilité, nous ne voyons pas de souci a priori à utiliser ces nouveautés.

En bref

HTML5 est plutÎt une bonne chose en général, il consolide HTML4, explicite les interfaces avec les éléments du code, précise les algorithmes d'interprétation des éléments, fournit grùce à ses API des fonctionnalités jusque-là réservées à des plugins (le multimédia) ou à des applications lourdes (services géolocalisés). Pour ce qui concerne l'accessibilité, vous l'aurez compris, il n'est pas franchement plus préjudiciable que HTML4, et il ne faudrait surtout pas, pour des imperfections, rejeter en bloc toutes ces nouveautés.

[1] C'est ce qui fait, par exemple, qu'on peut mettre n'importe quelle balise dans son HTML : quoi qu'il arrive, son contenu sera exposĂ© si la balise elle-mĂȘme est Ă©trangĂšre au navigateur. Essayez d'insĂ©rer une balise toto, pour voir.

[2] Jaws est un lecteur d'Ă©cran, c'est Ă  dire un logiciel qui retranscrit, soit Ă  l'aide d'un logiciel de synthĂšse vocale, soit Ă  l'aide d'une plage Braille, ce que vous voyez Ă  l'Ă©cran.

[3] Quant aux moteurs de recherche, on n'a pas encore d'informations sur leur prise en compte de cette nouvelle structure —article de 2012, n'hĂ©sitez pas Ă  mentionner en commentaire une source plus rĂ©cente.

[4] Pour Internet Explorer : pas avant la version 10.

[5] dans un fork baptisé Blink

[6] À ce jour, le format attendu est YYYY-MM-DD, ce qui ne parle pas forcĂ©ment Ă  tout le monde, en particulier les gens qui ne baignent pas dans les formats ISO.

Catégories: Blog Société

Organiser une politique de montée en compétences


Lors de la toujours passionnante confĂ©rence Lean Kanban France, Ă©dition 2014, j’ai eu le plaisir de prĂ©senter une session sur l’organisation de politique de montĂ©e en compĂ©tences au sein d’une Ă©quipe. L’objet de cet article n’est pas de faire un...
Catégories: Blog Société

HypothĂšses et Mesures pour vos ProblĂšmes et vos User Stories

Qualitystreet - Jean Claude GROSJEAN - ven, 11/07/2014 - 01:39

ou l’art de mettre ENFIN ses idĂ©es de produit puis ses User Stories Ă  « l’épreuve du Feu ». Ce que j’aime dans une approche LEAN STARTUP couplĂ©e fortement Ă  l’UX (agileUX), c’est qu’elle permet aux Equipes, aux Product Owners et aux dĂ©cideurs, non seulement de sortir du Monde des Opinions mais aussi de revenir aux premiers objectifs de…

The post HypothĂšses et Mesures pour vos ProblĂšmes et vos User Stories appeared first on QualityStreet - Blog Pro de Jean Claude Grosjean.

Catégories: Blog Individuel

Date and Time API contre le reste du monde

Zenika - jeu, 11/06/2014 - 16:15

Java 8 apporte une nouvelle API pour manipuler les dates et heures en Java, la Date and Time API, aussi connue comme JSR 310. L'objectif de cet article n'est pas de présenter cette API, mais de montrer ce que l'on doit faire aujourd'hui, pour l'intégrer avec les librairies habituelles comme Spring ou Hibernate, et se débarrasser des java.util.Date et autres java.util.GregorianCalendar

Si vous utilisez encore Java 7, cet article est probablement transposable sur Joda Time (qui a inspirĂ© la JSR 310) ou sur le "backport" ThreeTen. Pour commencer, on va persister en base une entitĂ© Utilisateur avec un attribut dateNaissance de type java.time.LocalDate. Au niveau, JDBC, cela signifie qu'il faudra ĂȘtre capable de convertir ce type... Read Date and Time API contre le reste du monde

Catégories: Blog Société

Introduction Ă  Apache Spark

Blog d’Ippon Technologies - jeu, 11/06/2014 - 15:08

Contexte

Spark est nĂ© en 2009 dans le laboratoire AMPLab de l’universitĂ© de Berkeley en partant du principe que :

  • d’une part, la RAM coĂ»te de moins en moins cher et les serveurs en ont donc de plus en plus Ă  disposition
  • d’autre part, beaucoup de jeux de donnĂ©es dits “Big Data” ont une taille de l’ordre de 10 Go et ils tiennent donc en RAM.

Le projet a intĂ©grĂ© l’incubateur Apache en juin 2013 et est devenu un “Top-Level Project” en fĂ©vrier 2014.

La version 1.0.0 de Spark a Ă©tĂ© releasĂ©e en mai 2014 et le projet, aujourd’hui en version 1.1.0, poursuit une Ă©volution rapide. L’écosystĂšme Spark comporte ainsi aujourd’hui plusieurs outils :

  • Spark pour les traitements “en batch”
  • Spark Streaming pour le traitement en continu de flux de donnĂ©es
  • MLlib pour le “machine learning”
  • GraphX pour les calculs de graphes (encore en version alpha)
  • Spark SQL, une implĂ©mentation SQL-like d’interrogation de donnĂ©es.

Par ailleurs, il s’intĂšgre parfaitement avec l’Ă©cosystĂšme Hadoop (notamment HDFS) et des intĂ©grations avec Cassandra et ElasticSearch sont prĂ©vues.

Enfin, le framework est Ă©crit en Scala et propose un binding Java qui permet de l’utiliser sans problĂšme en Java. Java 8 est toutefois recommandĂ© pour exploiter les expressions lambdas qui permettront d’écrire un code lisible.

Notions de base

L’élĂ©ment de base que l’on manipulera est le RDD : Resilient Distributed Dataset.

Un RDD est une abstraction de collection sur laquelle les opĂ©rations sont effectuĂ©es de maniĂšre distribuĂ©e tout en Ă©tant tolĂ©rante aux pannes matĂ©rielles. Le traitement que l’on Ă©crit semble ainsi s’exĂ©cuter au sein de notre JVM mais il sera dĂ©coupĂ© pour s’exĂ©cuter sur plusieurs noeuds. En cas de perte d’un noeud, le sous-traitement sera automatiquement relancĂ© sur un autre noeud par le framework, sans que cela impacte le rĂ©sultat.

Les Ă©lĂ©ments manipulĂ©s par le RDD (classes JavaRDD, JavaPairRDD
) peuvent ĂȘtre des objets simples (String, Integer
), nos propres classes, ou, plus couramment, des tuples (classe Tuple2). Dans ce dernier cas, les opĂ©rations offertes par l’API permettront de manipuler la collection comme une map clĂ©-valeur.

L’API exposĂ©e par le RDD permet d’effectuer des transformations sur les donnĂ©es :

  • map() permet de transformer un Ă©lĂ©ment en un autre Ă©lĂ©ment
  • mapToPair() permet de transformer un Ă©lĂ©ment en un tuple clĂ©-valeur
  • filter() permet de filtrer les Ă©lĂ©ments en ne conservant que ceux qui correspondent Ă  une expression
  • flatMap() permet de dĂ©couper un Ă©lĂ©ment en plusieurs autres Ă©lĂ©ments
  • reduce() et reduceByKey() permet d’agrĂ©ger des Ă©lĂ©ments entre eux
  • etc.

Ces transformations sont “lazy” : elles ne s’exĂ©cuteront que si une opĂ©ration finale est rĂ©alisĂ©e en bout de chaĂźne. Les opĂ©rations finales disponibles sont :

  • count() pour compter les Ă©lĂ©ments
  • collect() pour rĂ©cupĂ©rer les Ă©lĂ©ments dans une collection Java dans la JVM de l’exĂ©cuteur (dangereux en cluster)
  • saveAsTextFile() pour sauver le rĂ©sultat dans des fichiers texte (voir plus loin)
  • etc.

Enfin, l’API permet de conserver temporairement un rĂ©sultat intermĂ©diaire grĂące aux mĂ©thodes cache() (stockage en mĂ©moire) ou persist() (stockage en mĂ©moire ou sur disque, en fonction d’un paramĂštre).

Premiers pas

Pour un premier exemple de code, nous allons exploiter des donnĂ©es Open Data de la mairie de Paris, en l’occurence la liste des arbres d’alignement prĂ©sents sur la commune de Paris.

Le fichier CSV peut-ĂȘtre tĂ©lĂ©chargĂ© ici. Il comporte 103 589 enregistrements. En voici un extrait :

geom_x_y;circonfere;adresse;hauteurenm;espece;varieteouc;dateplanta
48.8648454814, 2.3094155344;140.0;COURS ALBERT 1ER;10.0;Aesculus hippocastanum;;
48.8782668139, 2.29806967519;100.0;PLACE DES TERNES;15.0;Tilia platyphyllos;;
48.889306184, 2.30400164126;38.0;BOULEVARD MALESHERBES;0.0;Platanus x hispanica;;

Ce fichier présente les caractéristiques suivantes :

  • une ligne de header
  • un enregistrement par ligne
  • les champs d’un enregistrement sont sĂ©parĂ©s par un point-virgule.

Nous allons simplement compter les enregistrements pour lesquels la hauteur de l’arbre est renseignĂ©e et est supĂ©rieure Ă  zĂ©ro.

Il faut d’abord crĂ©er un “contexte Spark”. Puisque nous Ă©crivons du Java, la classe que nous utilisons est JavaSparkContext et nous lui passons un objet de configuration contenant :

  • un nom d’application (utile lorsque l’application est dĂ©ployĂ©e en cluster)
  • la rĂ©fĂ©rence vers un cluster Spark Ă  utiliser, en l’occurence “local” pour exĂ©cuter les traitements au sein de la JVM courante.
SparkConf conf = new SparkConf()
        .setAppName("arbres-alignement")
        .setMaster("local");
JavaSparkContext sc = new JavaSparkContext(conf);

Nous pouvons ensuite écrire la suite de traitements et récupérer le résultat :

long count = sc.textFile("arbresalignementparis2010.csv")
        .filter(line -> !line.startsWith("geom"))
        .map(line -> line.split(";"))
        .map(fields -> Float.parseFloat(fields[3]))
        .filter(height -> height > 0)
        .count();
System.out.println(count);

DĂ©taillons ce code :

  • Nous commençons par demander Ă  Spark de lire le fichier CSV. Spark sait nativement lire un fichier texte et le dĂ©couper en lignes.

    La méthode utilisée est textFile() et le type retourné est JavaRDD<String> (un RDD de Strings).

      sc.textFile("arbresalignementparis2010.csv")
    
  • Nous filtrons directement la premiĂšre ligne (la ligne de header). Ce filtrage est effectuĂ© par le contenu plutĂŽt que par le numĂ©ro de ligne. En effet, les Ă©lĂ©ments du RDD ne sont pas ordonnĂ©s puisqu’un fichier peut ĂȘtre lu par fragments, notamment lorsqu’il s’agit d’un gros fichier lu sur un cluster.

    La méthode utilisée est filter() et elle ne modifie par le type retourné qui reste donc JavaRDD<String>.

      .filter(line -> !line.startsWith("geom"))
    
  • Les lignes peuvent ensuite ĂȘtre dĂ©coupĂ©es en champs. Nous utilisons une expression lambda qui peut ĂȘtre lue de la façon suivante : pour chaque Ă©lĂ©ment que nous appellerons line, retourne le rĂ©sultat de l’expression line.split(";").

    L’opĂ©ration map() est utilisĂ©e et le type retournĂ© devient JavaRDD<String[]>.

      .map(line -> line.split(";"))
    
  • Le champ contenant la hauteur de l’arbre peut ensuite ĂȘtre parsĂ©. Nous ne conservons que cette valeur : les autres champs ne sont pas conservĂ©s.

    L’opĂ©ration map() est Ă  nouveau utilisĂ©e et le type retournĂ© devient JavaRDD<Float>.

      .map(fields -> Float.parseFloat(fields[3]))
    
  • Nous filtrons ensuite les Ă©lĂ©ments pour ne conserver que les hauteurs supĂ©rieures Ă  zĂ©ro.

    L’opĂ©ration filter() est Ă  nouveau utilisĂ©e. Le type reste donc JavaRDD<Float>.

      .filter(height -> height > 0)
    
  • Enfin, nous comptons les Ă©lĂ©ments du RDD.

    L’opĂ©ration finale count() est utilisĂ©e et un long est retournĂ©.

      .count()
    

Voici un extrait de ce qui est produit sur la console :

...
14/10/29 17:09:54 INFO FileInputFormat: Total input paths to process : 1
14/10/29 17:09:54 INFO SparkContext: Starting job: count at FirstSteps.java:26
14/10/29 17:09:54 INFO DAGScheduler: Got job 0 (count at FirstSteps.java:26) with 1 output partitions (allowLocal=false)
...
14/10/29 17:09:54 INFO TaskSetManager: Starting task 0.0 in stage 0.0 (TID 0, localhost, PROCESS_LOCAL, 1242 bytes)
14/10/29 17:09:54 INFO Executor: Running task 0.0 in stage 0.0 (TID 0)
14/10/29 17:09:54 INFO HadoopRDD: Input split: file:/Users/aseigneurin/dev/spark-samples/arbresalignementparis2010.csv:0+25008725
...
14/10/29 17:09:55 INFO SparkContext: Job finished: count at FirstSteps.java:26, took 0.475835815 s
6131

Spark a exécuté les traitements en local, au sein de la JVM.

Le fichier a été lu en un seul bloc. En effet, celui-ci fait 25 Mo et, par défaut, Spark découpe les fichiers en blocs de 32 Mo.

Le rĂ©sultat (6131) est obtenu en moins d’une demi-seconde. Ce temps d’exĂ©cution n’est pas, en soi, impressionant, mais nous verrons la puissance du framework lorsque nous manipulerons des fichiers plus volumineux.

Conclusion

Le code Ă©crit avec Spark prĂ©sente l’intĂ©rĂȘt d’ĂȘtre Ă  la fois compact et lisible. Nous verrons dans les prochains posts qu’il est possible de manipuler des volumes trĂšs importants de donnĂ©es, mĂȘme pour des opĂ©rations manipulant l’ensemble du dataset, et ce, sans devoir modifier le code.

Vous pouvez retrouver l’exemple complet de code sur GitHub.

Catégories: Blog Société

Loi des 2 pieds
 ici et maintenant!

Qualitystreet - Jean Claude GROSJEAN - jeu, 11/06/2014 - 14:38

Ici et maintenant…  Ici et Ailleurs… soyez acteurs de vos apprentissages DANS l’ENTREPRISE! Les praticiens et participants de l‘Open Space Technology (Forum Ouvert), ce RDV collectif, symbole de l’Intelligence Collective, fondĂ© sur des valeurs participatives et collaboratives, sont familiers de cette loi… Ă  laquelle ils adhĂšrent plutĂŽt bien, le temps d’une journĂ©e. Aujourd’hui, je vous…

The post Loi des 2 pieds… ici et maintenant! appeared first on QualityStreet - Blog Pro de Jean Claude Grosjean.

Catégories: Blog Individuel

Revue de Presse Xebia

logo-revue-presse220

La revue de presse hebdomadaire des technologies Big Data, Cloud et Web, architectures Java et mobilité dans des environnements agiles, proposée par Xebia.

AgilitĂ© S’inspirer des approches agiles pour innover en RH ? http://blog.xebia.fr/author/gbonhommeauhttp://twitter.com/gbonhommeauPar GwĂ©naĂ«l Bonhommeau

Nous le constatons tous les jours sur le terrain, une transformation Agile repose sur l’humain. Il n’est donc pas Ă©tonnant de s’interroger sur l’apport de l’agilitĂ© pour innover en RH.

Cet article, se livre avec pragmatisme, Ă  un exercice de transposition des 12 principes du Manifeste Agile vers les pratiques et approches RH. Dans la seconde partie l’auteur va plus loin, avec une analogie possible entre les activitĂ©s RH et la mĂ©thode Scrum.

Cette lecture donne de belles perspectives RH.

http://innovationsrh.over-blog.com/2014/10/s-inspirer-des-methodes-agiles-pour-innover-en-rh.html

Ambiguity in Software Requirements http://www.gravatar.com/6beb8800b1d5d45c22ecc81062e12448http://blog.xebia.fr/author/nlochethttp://twitter.com/nicolaslochetPar Nicolas Lochet

Cet article (en anglais) est en fait un extrait d’un livre de Gerald M. Weinberg, « Exploring Requirements Part 1″, postĂ© par l’auteur sur son blog.

Bien que partie d’un tout plus vaste, cet extrait propose dĂ©jĂ  une belle analyse de l’ambiguitĂ© nĂ©e de l’expression du besoin. Il nous montre aussi certains des challenges auxquels nous sommes confrontĂ©s lors de sa collecte.

Quelques Ă©lĂ©ments qu’il conviendra donc de garder Ă  l’esprit tout au long de la vie du projet. Encore une fois, cela dĂ©montre la valeur d’un rapprochement et d’une interaction constante entre les diffĂ©rents acteurs du projet.

Bonne lecture!

http://secretsofconsulting.blogspot.fr/2014/11/ambiguity-in-stating-requirements.html

Agilité à grande échelle : Scaling Scrum http://www.gravatar.com/6beb8800b1d5d45c22ecc81062e12448http://blog.xebia.fr/author/nlochethttp://twitter.com/nicolaslochetPar Nicolas Lochet

Il semble que 2014 soit l’annĂ©e de l’agilitĂ© Ă  grande Ă©chelle. Un vaste dĂ©bat, trĂšs discutĂ© et avec beaucoup d’opinions assez tranchĂ©es.

Ken Schwaber vient de publier un billet sur le sujet qui annonce peut-ĂȘtre des choses intĂ©ressantes, on notera :

  • Ken Schwaber et Jeff Sutherland sont en faveur du mouvement qui tend Ă  dire que l’agilitĂ© Ă  grande Ă©chelle requiert une attention spĂ©cifique Ă  un contexte et *ne peut pas rentrer dans le cadre d’un mĂ©ga-processus sensĂ© tout rĂ©soudre*;
  • Apparemment ils travaillent sur un framework pour donner les clĂ©s de lecture nĂ©cessaires Ă  l’Ă©laboration d’une stratĂ©gie de scaling spĂ©cifique Ă  un contexte.

On peut regretter qu’il s’agisse surtout pour l’instant de promouvoir des workshops qu’ils comptent organiser sur le mois de dĂ©cembre, mais en mĂȘme temps garder un oeil ouvert sur ce qui peut en ressortir.

Vous trouverez dĂ©jĂ  quelques questions ouvertes qui mĂ©ritent d’ĂȘtre posĂ©es si vous souhaitez dĂ©ployer l’agilitĂ© Ă  grande Ă©chelle.

Bonne lecture!

https://kenschwaber.wordpress.com/2014/10/25/scaling-scrum/

Mobilité AppCode 3.1 intÚgre le support de Swift http://www.gravatar.com/3f309c992e2b1a5c3c014e63810a2f68http://blog.xebia.fr/author/scivettahttp://twitter.com/viteinfinitehttp://github.com/viteinfinitePar Simone Civetta

Bien qu’AppCode ne fasse pas l’unanimitĂ© parmi les dĂ©veloppeurs Cocoa, il est tout de mĂȘme indĂ©niable que certaines fonctionnalitĂ©s telles que le refactoring et la complĂ©tion de code rendent l’Ă©diteur de JetBrains plus versatile par rapport Ă  Xcode.

Cependant, jusqu’Ă  aujourd’hui, les aventuriers dĂ©veloppeurs qui souhaitaient rĂ©aliser leur application en Swift devaient se contenter de l’experience infernale non optimisĂ©e de l’Ă©diteur d’Apple. Jusqu’Ă  aujourd’hui, justement, car JetBrains, dans son dernier billet de blog, a annoncĂ© la version 3.1 d’AppCode qui intĂšgre le support de ce langage en ajoutant Find Usages, Rename Refactoring, et une navigation uniforme entre Objective-C et Swift. La version 3.1 est disponible dans la page Early Access Preview de JetBrains.

Vidéos de la Droidcon London http://www.gravatar.com/1a0b01fc47a191e0fa989649c7c18cb0http://blog.xebia.fr/author/gmechlinghttp://twitter.com/NilhcemPar Gautier Mechling

Pendant la Droidcon London qui a eu lieu les 30 et 31 octobre 2014, certaines confĂ©rences ont pu ĂȘtre enregistrĂ©es en direct.

Elles sont Ă  prĂ©sent disponibles directement sur le site officiel de l’évĂ©nement.

Swift.berlin #4 (by @chriseidhof et @_Caro_N) http://www.gravatar.com/3f309c992e2b1a5c3c014e63810a2f68http://blog.xebia.fr/author/scivettahttp://twitter.com/viteinfinitehttp://github.com/viteinfinitePar Simone Civetta

Swift.berlin est le nom (et l’adresse URL) du meetup de la capitale allemande dĂ©diĂ© exclusivement Ă  Swift. Le dernier rendez-vous a eu lieu le 27 octobre dernier et a vu en tant que speakers Chris Eidhof de objc.io et Carola Nitz de nxtbgthng. Aujourd’hui nous vous proposons les vidĂ©os (en langue anglaise) de l’Ă©vĂ©nement.

La premiĂšre intervention s’est concentrĂ©e sur l’utilisation de Swift finalisĂ©e Ă  la programmation fonctionnelle. La talk explore en grande partie les sujets du livre Functional Programming in Swift par le mĂȘme Chris Eidhof et Florian Kugler.

La deuxiĂšme talk explique comment dĂ©bogguer une application Swift depuis la console de Xcode Ă  l’aide de LLDB et du REPL. Le matĂ©riel pour l’intervention se base principalement sur les vidĂ©os 409, 410 et 413 de la WWDC 2014, intĂ©grĂ©es avec des recherches personnelles de la dĂ©veloppeuse allemande.

Catégories: Blog Société

French Scrum User Group @ Xebia, mercredi 12/11 : l’état de l’agilitĂ© en France

Xebia aura le plaisir d’accueillir dans ses locaux le mercredi 12 novembre le FrenchSUG .

French Scrum User Group

Actuellement il existe assez peu d’Ă©tat des lieux concernant l’AgilitĂ© en France. Des tendances internationales se dĂ©gage assez bien de grands rapports comme le CHAOS Report ou la derniĂšre enquĂȘte annuelle de VersionOne mais cela reste assez Ă©loignĂ© de notre quotidien.

Ainsi, l’objectif de la soirĂ©e est de partager les observations de terrain et bĂ©nĂ©ficier de la sagacitĂ© de chaque praticiens du FSUG dans le but d’établir un Ă©tat de santĂ© de l’agilitĂ© en France.

Le FSUG espĂšre pouvoir construire, grace aux participants, les outils qui leur permettront d’Ă©tablir cet Ă©tat de santĂ©. A moyen terme, il s’agira d’ĂȘtre capable de donner une premiĂšre Ă©bauche de cette Ă©tude au Scrum Day 2015 qui se dĂ©roule en Avril 2015.

Cette soirĂ©e sera facilitĂ©e afin de faire Ă©merger les thĂšmes principaux et les tendances. La qualitĂ© du rĂ©sultat sera dĂ©pendante de la diversitĂ©, de la richesse et du nombre de participants. Aussi, inscrivez-vous dĂšs aujourd’hui et venez nombreux !

Pour s’y rendre :

Xebia

156, boulevard Haussmann

Immeuble A – 7Ăšme Ă©tage

75008 Paris

Catégories: Blog Société

Retour sur la premiĂšre session du BPM Professional Group France

Zenika - mer, 11/05/2014 - 14:30

Mercredi 15 octobre, s’est dĂ©roulĂ© dans les locaux de Zenika, la premiĂšre rĂ©union du BPM Professional Group.

Logo

Pourquoi un groupe sur BPM? Olivier Laporte (architecte BPMS/SOA chez Zenika) et Jonathan du Plessis (Responsable d’offre BPM et associĂ© chez Nextis Consulting) ont eu le plaisir d’animer le 15 octobre 2014 la premiĂšre session. Le premier travaillant sur l’angle technique et technologique, le second sur des sujets fonctionnels ou stratĂ©giques,... Read Retour sur la premiĂšre session du BPM Professional Group France

Catégories: Blog Société

Realm, la solution pour la persistance des données de vos applications mobiles iOS/Android ?

Blog d’Ippon Technologies - mer, 11/05/2014 - 14:22
Une base de données destinée aux mobiles, tablettes et wearables

Realm est la premiÚre base de données destinée uniquement aux plates-formes mobiles qui ne repose sur aucune autre, contrairement aux nombreuses librairies qui proposent des solutions mobiles basées sur SQLite. On peut citer par exemple le framework mis à disposition par Apple pour les applications iOS : Core Data, ou bien ORMLite qui propose de faire le pont entre des objets Java et une base de données relationnelle.

Realm est un projet jeune, en dĂ©veloppement depuis 2011, qui s’est focalisĂ© avant tout vers iOS et qui depuis le 29 septembre 2014 propose ses fonctionnalitĂ©s au systĂšme Android.

Pourquoi Realm ?

timelineCe schéma montre que les innovations apportées aux bases de données mobiles depuis 2000 sont clairement inexistantes. Cependant, depuis 2007, pléthore de bases de données orientées serveurs ont fait leur apparition, notamment grùce au phénomÚne de Big Data apparu avec la croissance phénoménale des données à stocker, traiter et analyser.

Le problĂšme majeur ici est qu’aucune d’entre elle ne peut ĂȘtre intĂ©grĂ©e dans un projet mobile/tablette ou wearable du fait qu’elles n’ont pas Ă©tĂ© conçues pour ça.

À l’heure actuelle, pour les dĂ©veloppeurs mobile, la solution la plus performante pour la persistance des donnĂ©es est d’avoir recours Ă  SQLite. Ainsi l’introduction en 2000 de SQLite a Ă©tĂ© une Ă©tape rĂ©volutionnaire dans le domaine du dĂ©veloppement mobile, mais 14 annĂ©es plus tard cette activitĂ© n’a plus rien Ă  voir. En effet, il suffit de se reprĂ©senter l’image d’un tĂ©lĂ©phone ou mĂȘme d’une “application” au dĂ©but des annĂ©es 2000 pour comprendre que la conception et le dĂ©veloppement d’applications mobiles ont bien changĂ©.

C’est Ă  ce moment que Realm intervient en mettant Ă  disposition des dĂ©veloppeurs un systĂšme de persistance de donnĂ©es multi plates-formes (iOS/Android) performant et simple Ă  mettre en oeuvre.

Performant : comment ?

Comme Ă©noncĂ© prĂ©cĂ©demment, le coeur de la technologie dĂ©veloppĂ©e pour Realm ne s’appuie pas sur une base de donnĂ©es existante et n’est pour l’instant pas open source. Ce que l’on sait Ă  propos du coeur de Realm c’est qu’il repose sur un noyau codĂ© en C++ et crĂ©Ă© dans le but de s’exĂ©cuter sur des plates-formes mobiles. En prenant donc en compte les contraintes imposĂ©es par ce type de terminaux, notamment l’espace mĂ©moire et la relative lenteur des processeurs embarquĂ©s.

Pour gagner en performance, Realm s’appuie sur les concepts de :

De plus, les fichiers .realm dans lesquels sont stockées les données sont compatibles quels que soient la plate-forme et le langage utilisés (iOS: Objective-C et Swift ou Android: Java).

Pour illustrer ces promesses de performances Realm met à disposition le code utilisé pour effectuer leurs études comparatives ici.

Benchmark

Dans un premier temps intĂ©ressons-nous Ă  l’objectif principal d’une base de donnĂ©es, la persistance, et plus particuliĂšrement les insertions.
Pour ce benchmark, la base de donnĂ©es crĂ©Ă©e contient une table Employee, avec pour attributs un nom, un Ăąge et un boolĂ©en hired = true si l’employĂ© est embauchĂ©.

La figure ci-dessous provient de l’application standalone Realm browser disponible avec Realm qui permet de consulter et Ă©diter le contenu de la base de donnĂ©es sur laquelle on travaille, un outil trĂšs pratique pour le dĂ©veloppeur.

Capture d’écran 2014-10-17 Ă  15.03.47

Capture d’écran 2014-10-16 Ă  18.12.31

La requĂȘte d’insertion a insĂ©rĂ© 200 000 fois un employĂ© avec un nom allant de “Foo0” Ă  “Foo999” avec une tranche d’ñge de 20 Ă  69 et une valeur de hired true pour les lignes impaires et false pour les lignes paires.

Ce diagramme indique que Realm, malgrĂ© sa jeunesse, promet dĂ©jĂ  plus de performance en insertion massive en une seule transaction que les frameworks actuels utilisĂ©s par des millions d’applications. On pense notamment Ă  celui mis en avant par Apple: Core Data qui permet d’insĂ©rer 5 fois moins d’enregistrements par seconde en une seule transaction.

Cependant il n’est pas plus performant sur ce terrain que la version “compiled statement” de SQLite, qui double le nombre d’insertions effectuĂ©es par seconde en une transaction.

Dans un second temps voyons comment ces bases de donnĂ©es rĂ©agissent face aux requĂȘtes qu’on leur soumet.

Capture d’écran 2014-10-16 Ă  18.13.19

La requĂȘte sur la table Employee est la suivante :

SĂ©lectionner toutes les entrĂ©es de la table Employee dont la valeur de hired est fausse et dont l’ñge est compris entre 20 et 50 et dont le nom est “Foo0”

En SQL cela donne :

SELECT * FROM Employee WHERE hired = 0 AND age >= 20 AND age <= 50 AND name = 'Foo0’;

Le rĂ©sultat est tel que Realm double au minimum le nombre de requĂȘtes effectuĂ©es par seconde pour le mĂȘme jeu de donnĂ©es que les frameworks existants.

Dans la mĂȘme lignĂ©e voici les rĂ©sultats quasiment identiques de la capacitĂ© de ces frameworks Ă  compter le nombre de rĂ©sultats retournĂ©s par la mĂȘme requĂȘte que prĂ©cĂ©demment.

Capture d’écran 2014-10-16 Ă  18.12.57

AprÚs ces tests de performance, intéressons-nous au poids de chacune de ces solutions qui sont, rappelons le, intégrées dans nos devices.

Pour cela le mĂȘme jeu de donnĂ©es a Ă©tĂ© conservĂ© avec cette fois-ci 1 millions d’entrĂ©es dans chacune des bases, les rĂ©sultats sont en Mo.

Capture d’écran 2014-10-17 Ă  15.58.42

Globalement on peut dire que ces bases de donnĂ©es sont et respectent leur engagement en tant que base “lite”, exceptĂ© pour CouchBaseLite qui affiche pour ce mĂȘme test une empreinte mĂ©moire de 348,7 Mo. Il a Ă©tĂ© retirĂ© du diagramme dans un souci de lisibilitĂ©.
Realm est le plus léger sur nos devices/wearable avec 12,6Mo contre prÚs de 17Mo pour SQLite et FMDB.

Aux vues de ces rĂ©sultats, Realm s’en sort plutĂŽt bien cĂŽtĂ© performance, mais qu’en est-t-il de sa prĂ©tendue simplicitĂ© d’utilisation ?

Facile Ă  mettre en oeuvre ? comment ?

Realm propose d’exposer vos donnĂ©es en tant qu’objets et d’y accĂ©der directement dans le code. Pour cela il suffit de faire hĂ©riter vos POJO (plain old java object) de la classe RealmObject pour dĂ©finir un modĂšle de donnĂ©es, Ă  la maniĂšre des JavaBeans.

Realm propose en tout et pour tout 3 classes majeures :

  • Realm : Le coeur du framework, permet un accĂšs Ă  la base de donnĂ©es oĂč sont stockĂ©s vos objets.
  • RealmObject : Votre modĂšle Realm, le fait de crĂ©er un modĂšle va dĂ©finir votre schĂ©ma de base de donnĂ©es.
  • RealmList<? extends RealmObject> : Permet de stocker des objets de type RLMObject, de dĂ©finir des relations au sein de votre modĂšle et se comporte comme un tableau quelconque quelle que soit la plate-forme sur laquelle vous dĂ©veloppez. Le rĂ©sultat d’une requĂȘte sur une base .realm sera de ce type.

et 1 classe utilitaire :

  • RealmMigration: Permet de conserver une base de donnĂ©es cohĂ©rente en cas de changement du modĂšle initial de donnĂ©es par le biais d’une migration.

Ainsi on peut définir le modÚle Employee héritant de la classe RealmObject de cette maniÚre :

public class Employee extends RealmObject {
    private String          name;
    private int             age;
    private boolean         hired;
    // + Standard setters and getters here

}

Ajouter une entrée de cette maniÚre :

Realm realm = Realm.getInstance(this.getContext());

// Transactions give you easy thread-safety

realm.beginTransaction();
Employee john = realm.createObject(Employee.class);
john.setName("John");
john.setAge(35);
john.setHired(true);
realm.commitTransaction();

On récupÚre une instance de la classe singleton Realm.
On créer un bloc realm.beginTransaction(); et realm.commitTransaction();
Puis entre ces deux instructions on va créer notre objet Employee et on lui affecte des valeurs.

A l’exĂ©cution de realm.beginTransaction(); notre nouvel employĂ© John sera enregistrĂ© en base et accessible Ă  tout moment par la suite.
Les transactions Realm sont thread-safe et conservent les propriétés ACID.

Pour accéder aux données en base, rien de plus simple :

RealmResults<Employee> query = realm.where(Employee.class)
                               .greaterThan("age", 20)
                               .findAll();

Les requĂȘtes sont chaĂźnables pour par exemple affiner le rĂ©sultat de la requĂȘte ci-dessus:

RealmResults<Employee> allJohn = query.where()
                                .contains("name", "john")
                                .findAll();

Les conditions supportées par Realm sont :
greaterThan(), lessThan(), greaterThanOrEqualTo(), lessThanOrEqualTo()
equalTo(), notEqualTo()
contains(), beginsWith(), endsWith()

Le chaĂźnage des requĂȘtes est par dĂ©faut configurĂ© sur l’opĂ©rateur AND, mais Realm supporte aussi l’opĂ©rateur OR, pour cela il faut explicitement faire figurer .or().

En plus de la classe RealmObject, on dispose de la classe RealmList<? extends RealmObject> permettant par exemple de définir une relation many-to-many ou many-to-one:

public class Company extends RealmObject {
    private RealmList<Employee> employees;
    // Other fields


}

Ceci Ă©tant une prĂ©sentation rapide de la mise en oeuvre d’un modĂšle simple, toutes les fonctionnalitĂ©s sont accessibles ici.

Realm propose une mise en place simple pour les dĂ©veloppeurs en exposant les donnĂ©es persistantes en tant qu’objets et propose une API relativement complĂšte et peu verbeuse pour manipuler les donnĂ©es sauvegardĂ©es.

Pour illustrer la simplicitĂ© de l’API de manipulation des donnĂ©es, on peut par exemple montrer le contenu des deux mĂ©thodes d’insertions de donnĂ©es du Benchmark, en Objective-C.
Rappelons quand mĂȘme que SQLite propose d’insĂ©rer deux fois plus de donnĂ©es par seconde que Realm, mais Ă  quel prix pour le dĂ©veloppeur ?
Voici donc la méthode permettant de faire une insertion en base SQLite compiled statement:

- (void)insertObject:(NSUInteger)index {

    sqlite3_stmt *ppStmt = NULL;
    int rc = sqlite3_prepare(self.db,
                         "INSERT INTO t1 VALUES(?1, ?2, ?3);",
                         -1,
                         &ppStmt,
                         NULL);
    if (rc != SQLITE_OK) {
        @throw [NSException exceptionWithName:@"SQL failure"
                                       reason:@"Prepare of insert statement failed"
                                     userInfo:nil];
    }

    const char *nameValue = [self nameValue:index].UTF8String;
    const int hiredValue = [self hiredValue:index] ? 1 : 0;
    const int ageValue = [self ageValue:index];

    sqlite3_reset(ppStmt);
    sqlite3_bind_text(ppStmt, 1, nameValue, -1, NULL); // name

    sqlite3_bind_int(ppStmt, 2, ageValue);  // age

    sqlite3_bind_int(ppStmt, 3, hiredValue); // hired

    rc = sqlite3_step(ppStmt);
    if (rc != SQLITE_DONE) {
        @throw [NSException exceptionWithName:@"SQL failure"
                                       reason:@"sqlite3_step on insert failed"
                                     userInfo:nil];
    }
    sqlite3_finalize(ppStmt); // Cleanup

}

Puis la méthode avec Realm :

- (void)insertObject:(NSUInteger)index {
    Employee *employee = [[Employee alloc] init];
    employee.name = [self nameValue:index];
    employee.age = [self ageValue:index];
    employee.hired = [self hiredValue:index];
    [self.realm addObject:employee];
}

La mĂȘme action avec un code beaucoup moins verbeux, Realm est certes moins performant que SQLite quand il s’agit d’insĂ©rer des donnĂ©es massivement, mais il propose aux dĂ©veloppeurs une interface relativement simple d’utilisation associĂ©e Ă  des performances trĂšs correctes en comparaison des frameworks existants.

SĂ©curitĂ© des donnĂ©es, qu’en est-il ?

Faisons un tour d’horizon des solutions proposĂ©es par Realm pour sĂ©curiser vos donnĂ©es. Pour l’instant en version 0.86.3 pour iOS et 0.71.0 pour Android, Realm est encore en bĂȘta. Il ne dispose pas de solution cross plate-forme ou officielle pour la sĂ©curisation des donnĂ©es sensibles.

iOS

Le chiffrement des données sous iOS peut se faire de différentes maniÚres

  • NSFileProtectionComplete :

    L’idĂ©e est d’enregistrer le fichier .realm Ă  sa crĂ©ation avec pour attribut NSFileProtectionComplete lors de l’appel Ă  NSFileManager. Ce qui Ă  pour but d’enregistrer le fichier .realm dans un format cryptĂ© sur le disque.
    Cette solution est facile Ă  mettre en oeuvre mais ne couvre pas tous les cas d’utilisation. En effet, on ne peut ni lire ni Ă©crire sur le fichier tant que l’appareil sur lequel il se trouve est verrouillĂ© ou tant que l’appareil dĂ©marre. Ce qui laisse tous les autres cas d’utilisation non couvert par cette protection.
    + : Facile Ă  mettre en place, accĂšs rapide aux donnĂ©es, toutes les fonctionnalitĂ©s de Realm sont conservĂ©es, la base entiĂšre est cryptĂ©e, la base Realm contient l’intĂ©gralitĂ© des donnĂ©es.
    - : iOS uniquement, effectif uniquement sur les appareils protégés par mot de passe.

  • Stocker les donnĂ©es sensibles dans le KeyChain et stocker les clef d’accĂšs au KeyChain dans Realm :

    Apple met Ă  disposition un KeyChain, qui est un espace de stockage sĂ©curisĂ© au sein des appareils. L’accĂšs aux items du KeyChain est rĂ©servĂ© aux applications, et chaque application ne peut accĂ©der qu’à ses propres items en disposant de la clef dĂ©finie lors de la crĂ©ation de celui-ci.

    + : TrÚs sécurisé, compatible iOS/OS X, accÚs aux données sensibles rapide, fonctionne sur les appareils non sécurisés par mot de passe.
    - : L’accĂšs aux donnĂ©es sensibles n’est pas direct via le systĂšme de requĂȘte Realm (on rĂ©cupĂšre la clef liĂ©e aux donnĂ©es puis on y accĂšde), la base Realm ne contient plus l’intĂ©gralitĂ© des donnĂ©es, nĂ©cessite de choisir au cas par cas les donnĂ©es sĂ©curisĂ©es, non portable sur d’autre plates-formes que celles d’Apple.

  • Utiliser des Librairies de chiffrement de donnĂ©es et sauvegarder le contenu dans Realm :

    Dans ce cas, le développeur a pour responsabilité de mettre en place le systÚme de chiffrement de données en utilisant par exemple RNCryptor ou CommonCrypto proposé par Apple.
    + : TrÚs sécurisé, toutes les données sont contenues dans la base Realm, fonctionne sur les appareils non protégés par mot de passe, accÚs aux données sensibles relativement rapide.
    - : Difficile Ă  mettre en oeuvre, dĂ©finir au cas par cas quelles donnĂ©es crypter ou non, les donnĂ©es cryptĂ©s ne peuvent ĂȘtre retournĂ©es directement par Realm, augmente les chances d’erreurs lors de l’implĂ©mentation.

Android

Du cĂŽtĂ© d’Android, pour utiliser le chiffrement de donnĂ©es il est nĂ©cessaire d’ajouter la ligne encryption=true dans le fichier local.properties avant d’utiliser la commande ./gradlew assemble.
Puis de remplacer le fichier realm-.aar de votre projet par celui situé ici :
realm/build/outputs/aar/realm-.aar

  • Sauvegarder le fichier .realm cryptĂ© lors de sa crĂ©ation :

    On va générer une clef de chiffrement 256-bit lors de la création de la base Realm afin de crypter et décrypter les données persistantes de maniÚre transparente selon le standard AES-256.

    byte[] key = new byte[32];
    new SecureRandom().nextBytes(key);
    Realm realm = Realm.create(this, key);
    
    // ... use the Realm as normal 

    
    

    La difficultĂ© de ce procĂ©dĂ© va ĂȘtre de sauvegarder la clef dans le KeyStore d’Android de maniĂšre sĂ©curisĂ©e pour qu’aucune autre application n’accĂšde Ă  cette clef.
    Un exemple de mise en place de ce procédé est disponible ici.
    + : TrÚs sécurisé, toute les données sont contenues dans la base Realm, accÚs aux données rapide.
    - : Difficile à mettre en oeuvre, usage réservé à Android

En termes de sĂ©curitĂ©, il reste du travail aux Ă©quipes responsables du projet pour intĂ©grer une solution cross plate-forme de chiffrement des donnĂ©es propre Ă  Realm. À la maniĂšre de la solution proposĂ©e pour Android, bien qu’expĂ©rimentale, qui permettrait une compatibilitĂ© entre les deux OS cibles.

Conclusion

Realm est une base de donnĂ©es crĂ©Ă©e dans le but de s’exĂ©cuter sur des plates-formes mobiles. Ses performances combinĂ©es avec sa facilitĂ© d’utilisation en font un outil trĂšs fonctionnel pour les dĂ©veloppeurs mobiles que ce soit sur un projet Android ou iOS.
On peut se demander s’il est judicieux d’utiliser Realm pour une application en production connaissant la jeunesse du Framework ?
Tout dĂ©pend de la sensibilitĂ© des donnĂ©es du projet Ă  stocker. On privilĂ©giera une technologie qui a fait ses preuves pour rĂ©aliser une application dont les donnĂ©es sont extrĂȘmement sensibles tant qu’une release du projet ne sera pas disponible.

De plus, Realm n’est disponible au public que depuis juillet 2014 seulement, en dĂ©veloppement depuis 2011 et en production depuis 2012. Notamment chez Zinga pour une application qui atteint le seuil du million d’utilisateurs quotidien.

Cependant, Realm reste un projet jeune avec une petite communautĂ© qui tend Ă  grandir, donc en cas de blocage, la bonne pratique est d’aller voir les issues github :

Realm n’est pas une alternative absolue Ă  SQLite et l’ensemble des frameworks dont il est Ă  l’origine, mais une nouvelle solution qui a lĂ©gitimement sa place dans l’écosystĂšme des bases de donnĂ©es mobiles.

Catégories: Blog Société

Nous Ă©tions Ă  Paris Web 2014

Clever Age - Blog - mer, 11/05/2014 - 13:54

Clever Age, en plus d'ĂȘtre sponsor, s'est dĂ©placĂ© massivement pour assister aux confĂ©rences et comme chaque annĂ©e, les bĂ©nĂ©voles de Paris Web se sont affairĂ©s pour nous proposer les meilleurs orateurs dans un environnement des plus agrĂ©able : le Beffroi de Montrouge.

En 2014, la barre a été placée trÚs haut : non seulement les deux amphithéùtres étaient captés et diffusés en direct sur Internet mais, dans l'un d'entre eux, les conférences étaient transcrites, traduites en français et en langue des signes à la volée. L'équipe de montage a également réussi le pari fou de manipuler les flux en temps réel, tout en préparant des vidéos indépendantes, disponibles sur Internet moins d'une demi-journée aprÚs chaque conférence (salle Lucienne et André Blin, salle Moebius).

Bien que nos consultants prĂ©sents n'aient pas suivi le mĂȘme parcours durant ces deux journĂ©es, de grandes thĂ©matiques s'envolent de leurs notes : les standards sur web, le design et la vie des projets.

Des standards à l'applicatif, le périmÚtre du web s'élargit

La pĂ©riode que nous vivons est charniĂšre. De grands standards ont Ă©mergĂ© rĂ©cemment (HTML5, CSS3
) et nous commençons Ă  les utiliser Ă  leur plein potentiel. D'autres arrivent, et nous nous interrogeons sur leur fonctionnement. Nous sommes, pour une des premiĂšres fois depuis le dĂ©but de l'histoire du web, dans une phase d'apprentissage des possibles, la standardisation ayant rattrapĂ© l'implĂ©mentation.

Prenons l'exemple des masques CSS prĂ©sentĂ©s par Vincent de Oliveira dans « Les masques CSS : vers de nouveaux usages dans le web design ». À partir d'un standard bien dĂ©fini, l'implĂ©mentation laisse Ă©merger plusieurs tactiques. La mĂ©thode du clipping offre des formes nettes, tandis que la mĂ©thode du masking offre des masques plus doux, voire flous, qui s'apparentent par bien des aspects aux masques de fusion de Photoshop. Le support des masques CSS commence Ă  ĂȘtre intĂ©ressant mais il faut avoir la main lĂ©gĂšre, car les performances sont assez mauvaises. En effet, les implĂ©mentations par les navigateurs sont aujourd'hui incomplĂštes.

MĂȘme constat pour la confĂ©rence de Bruce Lawson et Karl Groves : « Web components, la marche Ă  suivre » : les web components peuvent apporter de grandes choses, notamment en offrant des alternatives accessibles Ă  de nombreux composants riches. Mais ils ne sont pas encore prĂȘts pour la production car le standard n'est pas encore supportĂ© partout, ou prĂ©sente des zones d'ombre (performances, gestion des dĂ©pendances, organisation des projets). Autre risque : qu'un acteur unique s'accapare la rĂ©flexion, comme essaie de le faire Google au travers de son projet Polymer.

Il est pourtant important que l'évolution du standard se fasse par l'ensemble de la communauté : Google bien sûr, mais également Mozilla (avec ses projets x-tag et brick) ou toute autre personne qui souhaiterait se lancer (par exemple WebComponents.org). C'est le cas de Raphaël Rougeron dont on retiendra cette citation, durant son informelle sur les web components en compagnie de Cyril Balit :

C'est en jouant avec Bosonic que je me suis rendu compte des limites, et c'est important que d'autres fassent la mĂȘme chose. Il faut que nous trouvions les limites pour savoir comment amĂ©liorer l'implĂ©mentation.

Et les web components ne sont pas les seuls Ă  ĂȘtre amĂ©liorables. Plus proche de nous, l'e-mail en est encore Ă  ses balbutiements en terme d'intĂ©gration, notamment dans les webmails. DĂ©monstration dans la trĂšs drĂŽle confĂ©rence de RĂ©mi Parmentier, « Sortons l'intĂ©gration d'e-mails de la prĂ©histoire » : entre Outlook qui utilise depuis la version 2007 le moteur de rendu de Word (hum
) et les webmails français qui utilisent un moteur de rendu au prĂ©-fixage trĂšs
 particulier (ou qui retouchent les images qui leur sont envoyĂ©es), cela devient trĂšs difficile de s'en sortir. Malheureusement, ceux qui devraient ĂȘtre les principaux acteurs du changement, les professionnels du webmail, sont aux abonnĂ©s absents des rendez-vous du W3C depuis plusieurs annĂ©es. Un bien triste constat qui nous rappelle que nos projets sont trĂšs souvent tributaires d'acteurs trĂšs puissants qui ne jouent pas toujours le jeu.

Pourtant les enjeux sont de premiĂšre importance car le web est en pleine mutation de ses usages, comme l'expliquait notre collĂšgue JĂ©rĂ©mie Patonnier dans sa confĂ©rence « Logiciellisation du web ». Les technologies web, JavaScript en tĂȘte, permettent aujourd'hui de crĂ©er de vraies applications sur le web, bien sĂ»r, mais Ă©galement natives sur les diffĂ©rents systĂšmes d'exploitation (Windows 8, Ubuntu HTML5 App, Silk), voire mĂȘme de crĂ©er les systĂšmes eux-mĂȘmes (Firefox OS, Chrome OS).

MalgrĂ© la puissance de JavaScript, Web GL et bientĂŽt d'ASM.JS (une sous-spĂ©cification de JavaScript orientĂ©e vers la performance d'exĂ©cution), le web reste lent car les APIs utilisĂ©es par JavaScript sont encore Ă  la traĂźne. À commencer par l'API DOM, celle qu'on utilise le plus souvent dans nos sites
 Pour autant, ces Ă©volutions de performance sont le moteur de rĂ©volutions architecturales : de la mĂȘme maniĂšre que l'ordinateur de bureau est passĂ© d'une culture du mainframe Ă  celle de l'ordinateur personnel, les sites et applications web deviennent de plus en plus indĂ©pendants : bases de donnĂ©es embarquĂ©es, mode offline
 À terme, il n'est pas absurde d'imaginer que les sites tireront leurs informations de sources multiples : places de marchĂ©, places de services
 À condition que ces Ă©volutions techniques soient accompagnĂ©es d'Ă©volution et terme de design, pour guider les utilisateurs.

Le design, Ă  l'Ă©coute des utilisateurs

Et c'est bien de design dont nous avons Ă©galement beaucoup parlĂ© durant ce Paris Web. design des interfaces, expĂ©rience utilisateur
 C'est Olivia Lor qui nous a interpellĂ© la premiĂšre avec sa confĂ©rence « Interactions : animations et interface ». Elle y abordait le questionnement inhĂ©rent Ă  toute crĂ©ation d'interface : sur quoi souhaite-t-on attirer le regard de l'utilisateur ? Doit-il interagir ? Comment lui faire passer une information sur la prise en compte de son action ? Et surtout : comment tester tout cela par des dĂ©veloppements, mais Ă©galement par des tests en conditions (presque) rĂ©elles ? Une intervention riche qui nous rappelle que le souci est souvent dans les dĂ©tails.

Des dĂ©tails qui cachent parfois, comme le dit le dicton, le Diable. ClĂ©ment HardoĂŒin, dans sa confĂ©rence « Dark patterns, la contre-attaque du pire », met en avant, avec divers exemples, tous plus vicieux les uns que les autres, les procĂ©dĂ©s visant Ă  tromper l'utilisateur afin de le pousser Ă  faire quelque chose qu'il ne veut pas ou qu'il n'a pas conscience de faire. Ces dark patterns permettent de rentabiliser un site web, soit en augmentant les prix au fur et Ă  mesure du parcours client, soit en ajoutant des produits non sollicitĂ©s au panier de l'utilisateur (c'est souvent le cas de garanties ou de « produits complĂ©mentaires » lorsqu'on ajoute un produit Ă©lectronique sur les sites e-commerce). Évidemment, cette rentabilisation basĂ©e sur la tromperie ne saurait durer, les utilisateurs Ă©tant sensibles Ă  l'Ă©thique. Cela peut mĂȘme profondĂ©ment nuire Ă  l'image de marque des plates-formes. À nous, professionnels du web, d'informer, d'alerter, de nous prĂ©munir de la mise en place de ces patterns sur les produits que nous concevons. À nous Ă©galement d'inventer de nouvelles façons d'interagir avec nos utilisateurs, d'Ă©duquer nos personnels et d'accompagner nos clients vers un design applicatif plus respectueux.

Et une des façons d'y parvenir est de n'oublier aucune composante de l'expĂ©rience utilisateur. Et dans un mĂ©dia qui fait la part belle au texte, il est important de soigner sa typographie. Une fois de plus, Marko Dugonjić nous a proposĂ© une confĂ©rence passionnante sur la « Responsive web Typography ». Cette fois-ci, l'orateur nous a prĂ©sentĂ© plein d'idĂ©es pour amĂ©liorer les textes de nos interfaces, en particulier dans un contexte responsive : interlettrage, graded fonts, graisses
 Saviez-vous par exemple que Georgia et Verdana, polices de caractĂšres bien connues sur le web, possĂšdent une version condensed qui peut faciliter la lecture sur Ă©cran mobile ? Ou que sur un Ă©cran Ă  haute densitĂ© de pixels (type retina), il peut ĂȘtre intĂ©ressant d'utiliser des polices un peu plus grasses ? Comme toujours, rien ne vaut quelques tests utilisateurs. Dix minutes suffisent : demander Ă  la personne Ă  cĂŽtĂ© de vous de lire l'interface que vous ĂȘtes en train d'intĂ©grer. Si elle trĂ©buche entre les mots, si elle plisse les yeux, si elle a besoin d'un certain temps pour lire une phrase, c'est qu'il y a sans doute un problĂšme Ă  identifier et Ă  rĂ©soudre.

Mais pour cela, l'ensemble des acteurs doit pouvoir Ă©changer, pour (se) comprendre. Une vaste problĂ©matique qui Ă©tait Ă©galement le sujet d'une confĂ©rence informelle animĂ©e par Julien Dubedout : « Comment communiquer avec ces #@$* de designers ». Designers, intĂ©grateurs et dĂ©veloppeurs, nous poursuivons tous le mĂȘme objectif : produire des interfaces de qualitĂ© pour les utilisateurs. Il faut donc pouvoir dialoguer pour que ce travail d'Ă©quipe s'organise au mieux. Cette communication passe en premier lieu par le fait de s'intĂ©resser au mĂ©tier de l'autre et par un dialogue constant. Si, parfois, les Ă©changes entre crĂ©atifs et techniciens sont difficiles, c'est peut-ĂȘtre parce qu'il nous manque un vocabulaire commun. On campe sur nos positions, on dĂ©fend notre territoire au lieu de dĂ©fendre la cause finale : servir l'utilisateur. En agences, ces situations de communication difficile sont trĂšs certainement dues Ă  l'organisation du travail en silos, pas assez itĂ©rative. On a appris Ă  communiquer Ă  certains moments-clĂ©s, mais pas de façon continue. Inclure les diffĂ©rents leads d'un bout Ă  l'autre du projet est sans doute une piste Ă  creuser pour amĂ©liorer nos processus de gestion.

Des bonnes pratiques au service de nos clients

Enfin, c'est de gestion de projet dont il a Ă©tĂ© question, une fois passĂ©es les questions de savoir-faire et de communication. Le premier rappel fort a Ă©tĂ© lancĂ© par Elie SloĂŻm et Nicolas Hoffmann dans leur confĂ©rence d'ouverture « QualitĂ© web : l'heure de passer Ă  la caisse » : ne rien faire pour amĂ©liorer la qualitĂ© de son projet, c'est s'assurer d'un Ă©chec cuisant. Il est crucial que la qualitĂ© soit au cƓur de nos processus car nos savoir-faire s'industrialisent, se complexifient et se diversifient : sans contrĂŽle, c'est l'assurance d'aller dans le mur. Reste la difficultĂ©, pour certaines agences, de vendre cette qualitĂ©. Faut-il ajouter une ligne spĂ©cifique dans les chiffrages, en faire une valeur fondamentale ? Finalement, peu importe, notre rĂŽle est surtout d'ĂȘtre pĂ©dagogues et honnĂȘtes envers nos clients : nous ne sommes pas de simples exĂ©cutants, nous sommes des accompagnateurs dans la rĂ©ussite d'un projet qui est le leur. DĂ©fendre la qualitĂ©, c'est leur assurer que ce projet ira Ă  son terme et vivra au delĂ  de notre intervention.

Comment s'exprime la qualitĂ© au sein d'un projet ? Est-ce une liste de critĂšres Ă  valider ? Cela peut l'ĂȘtre en partie, mais pas uniquement. Il s'agit avant tout d'une dĂ©marche, qui peut commencer par des choses toutes bĂȘtes. Vanessa Ilmany est venue expliquer, par exemple, « Comment tirer le meilleur parti de ses erreurs ». Elle a tĂ©moignĂ© trĂšs humainement des erreurs qu'elles faisaient rĂ©guliĂšrement, et de comment, en systĂ©matisant leur identification et le questionnement nĂ©cessaire Ă  leur rĂ©solution, elle a limitĂ© leur reproduction.

Nous avons également retrouvé cette culture de l'amélioration continue du savoir-faire dans la conférence « Things I wish I knew when I started in Digital Accessibility » de Billy Gregory, qui venait partager avec le public présent à Montrouge le résultat de plusieurs années passées au service de l'accessibilité web. Contrairement à de nombreuses conférences sur l'accessibilité, dont on ressort souvent démoralisé, celle de Billy Gregory prenait le problÚme du bon cÎté, en nous donnant quelques astuces pour évangéliser facilement sur l'accessibilité au quotidien. Et comme pour la qualité (dont l'accessibilité est une facette), ce ne sont pas les designers ni les développeurs qu'il faut convaincre de la nécessité de rendre un site ou une application web accessible, mais bien le client, car c'est lui qui va devoir régler la facture. Nous devons donc évoquer le sujet dÚs le premier jour, et l'éduquer.

On peut par exemple commencer par quelques petits projets, faciles Ă  mettre en Ɠuvre, comme un datepicker entiĂšrement accessible, puis dĂ©montrer Ă  notre client la facilitĂ© d'utilisation du widget au clavier, et l'impact minimal que cela a eu sur les charges et sur le planning. ParallĂšlement, il faut quand mĂȘme continuer Ă  sensibiliser nos collĂšgues Ă  l'accessibilitĂ© du web. Quelques idĂ©es : organiser des dĂ©jeuners techniques, oĂč chacun vient avec toutes les questions qu'il s'est toujours posĂ© sur l'accessibilitĂ©, et y rĂ©pondre. Proposer aussi d'y rĂ©pondre par e-mail Ă  tout moment.

L'essentiel est de toujours garder l'accessibilité dans la conversation, que ça soit un sujet comme un autre, présent au quotidien. L'erreur consisterait à faire reposer les objectifs en matiÚre d'accessibilité web sur les épaules des seuls intégrateurs et développeurs : il faut que la démarche soit globale et concerne tous les acteurs du projet. Et cela peut permettre de définir des bonnes pratiques de gestion de projet, comme celle d'inclure une personne en situation de handicap parmi les personas, dÚs la phase de conception.

JĂ©rĂ©mie Patonnier (encore lui), est Ă©galement venu parler de bonnes pratiques de gestion de projets dans sa confĂ©rence « Mes Projets web se passent toujours bien ». À commencer par l'identification des zones d'ombre, des zones de frustration, des processus de documentation :

Il n'y a pas de spĂ©cs ? OK, pas de problĂšme, c'est pas grave. S'il n'y a pas spĂ©cs, et bien on les Ă©crit, c'est tout [
] « VoilĂ  ce qu'on m'a demandĂ©, voilĂ  ce que je vais faire, voilĂ  le rĂ©sultat attendu ». Ça tient en trois phrases, s'il faut.

Bien sûr, pour qu'un projet se passe bien, il faut également infuser une culture du savoir, de la réutilisation des briques fonctionnelles et surtout, des tests.

Des savoir-faire, des projets
 au service d'une vision plus large

L'intĂ©rĂȘt d'un Ă©vĂ©nement comme Paris Web, c'est d'avoir un retour d'expĂ©rience ancrĂ© dans le temps, dans la difficultĂ© et l'Ă©volution. Évolution des standards, design, gestion de projets, autant de sujets abordĂ©s avec brio par Jean-Loup Yu, dans sa confĂ©rence « Mutation d'un gĂ©ant du web vers le Mobile ». On y trouvait un retour trĂšs honnĂȘte sur l'impact des acquisitions stratĂ©giques de Meetic sur sa stratĂ©gie numĂ©rique et sa longue reconquĂȘte de sa dette technique au fil des annĂ©es, alternant les cibles web et mobiles. Jean-Loup nous a Ă©galement donnĂ© un aperçu de l'organisation nĂ©cessaire Ă  l'accomplissement d'objectifs de cette ampleur : investissements importants dans la dĂ©couverte et la rĂ©tention des compĂ©tences, agilitĂ© des Ă©quipes, organisation de l'intĂ©gration continue


Des retours riches comme on espÚre en voir encore l'année prochaine.

Catégories: Blog Société

CrĂ©ation d’un lecteur GIF avec WIC et Direct2D – Partie 2


Dans la premiĂšre partie de cet article, qui a pour but d’expliquer comment crĂ©er un composant pour afficher des images/animations au format GIF dans une application universelle, nous avions vu comment initialiser les composants DirectX(DXGI et Direct2D dans notre cas)...
Catégories: Blog Société

The Open Group – Madrid 2015

Architecture Forum France (Open Group) - mer, 11/05/2014 - 08:57
Madrid, Espagne 20-23 avril,
Catégories: Association

Atelier infra grooming, reprendre le dessus sur la gestion de ses environnements

Quand une équipe de développement a quelques mois voir quelques années de vie, elle prend des habitudes.

Au cours des mois, des process ou des façons de faire souvent peu documentĂ©s Ă©mergent. S’ils ne sont pas remis en question, ils semblent parfois gravĂ©s dans le marbre. A tel point que des solutions de contournement deviennent des façons de faire “officielles”.

A l’heure oĂč l’on imagine des pipelines de dĂ©ploiement pour livrer en continu. Il faut savoir challenger les habitudes et cartographier les machines mais aussi les usages.

image2014-10-23-20039.png

Voici un format court (1 heure) d’atelier qui vous permettra de faire l’audit de vos environnements et de leurs usages. Il vous Ă©vitera des heures de recherche et d’interviews, il vous permettra de valider une vision partagĂ©e de l’état de vos environnements et des pistes d’amĂ©liorations.

But de l’atelier

Sur un format court, permettre d’accorder les visions de chacune des personnes travaillant sur la chaĂźne de production logicielle. A la fin de l’atelier, tous les acteurs auront connaissance de la cartographie des environnements, de leurs particularitĂ©s techniques, des usages spĂ©cifiques au produit dĂ©veloppĂ© et Ă  l’Ă©quipe en place.

DĂ©roulement Public :
  • DĂ©veloppeurs
  • Architectes
  • PO
  • Testeurs
  • Production
  • InfogĂ©rant
  • Tout autre personne ayant des connaissances sur le projet/produit.
Matériels :
  • Post-it / crayons ;
  • Paper board ;
  • Un mur accessible par l’ensemble des participants.
Préparation :

PrĂ©parer autant de feuilles de paperboard que vous pensez avoir d’environnements. Faites en une de plus, on dĂ©couvre souvent un environnement fantĂŽme ou clandestin


Exemple de template :

intra-grooming

  1. Fiche descriptive :
    • Nom de l’environnement
    • Liste des intervenants. Qui a des droits, qui l’utilise et Ă  quelle frĂ©quence?
    • Usages. Les usages diffĂ©rant d’un utilisateur Ă  l’autre, peut-ĂȘtre que certains l’utilisent pour de mauvaises raisons.
    • CaractĂ©ristiques taille, contraintes, puissances, flux branchĂ©s…
  2. Les points positifs de cet environnement dans son utilisation actuelle
  3. Les points négatifs de cet environnement dans son utilisation actuelle
  4. Notes : les réflexions, les remarques amenées par la discussion.
  5. Les idĂ©es d’amĂ©liorations, d’utilisations par exemple.

tableau-grooming

Un exemple de prĂ©paration d’atelier

Organisation PrĂ©sentation – 5’

Faire un tour de table si nĂ©cessaire. PrĂ©senter la raison de l’atelier, le livrable attendu Ă  la fin de l’heure.

Environnement 1 – 15’

Proposer aux intervenants de se concentrer sur le premier environnement. En silence chacun prend 5 minutes pour Ă©crire sur des post-its les informations dont il a connaissance pour le premier paperboard.

Chacun Ă  son tour les intervenants vont au tableau et expliquent leurs post-its. Si certains post-its sont en double ou triple, vous pouvez les mutualiser.

Recommencer pour chaque environnement, comptez environ 10’ pour chaque tour

DĂ©brief 10’

A cet instant vous aurez une vision globale de l’utilisation de vos environnements, vous aurez sans doute une bonne idĂ©e des bonnes et des mauvaises pratiques de votre Ă©quipe. Prenez un instant pour en dĂ©battre et faire un plan d’action sur ce qui peut et doit changer.

RĂ©sultats

AprĂšs avoir jouĂ© l’atelier une dizaine de fois, les vertus collaboratives de l’atelier sont claires.

Communication

Les diffĂ©rents intervenants discutent volontiers, les incomprĂ©hensions s’estompent. Quand on aborde des points douloureux, le partage autour de la table permet une meilleure empathie des autres intervenants. Les raisons historiques de choix Ă©tonnants apparaissent.

Collaboration

Les incohĂ©rences sont mises en avant, des plans d’actions peuvent ĂȘtre initiĂ©s. L’ensemble des acteurs Ă©tant prĂ©sents Ă  l’atelier, c’est l’occasion de discuter et de mieux comprendre les problĂ©matiques des autres. Dans une dĂ©marche DevOps ce sera l’occasion par exemple pour la prod de mieux apprĂ©hender l’environnement dev et inversement de mieux comprendre les contraintes de l’environnement de production.

Documentation

Le rĂ©sultat est facile a retranscrire dans un wiki, sous forme de tableau par exemple. Il est rapide de faire valider par l’ensemble des participants. Il pourra par la suite ĂȘtre la rĂ©fĂ©rence pour les nouveaux arrivants.

Optimisation

Il arrive rĂ©guliĂšrement que cet atelier mette en avant la sous-utilisation d’un environnement. Il est alors possible de rĂ©tablir une utilisation cohĂ©rente ou utiliser l’environnement pour autre chose.

Catégories: Blog Société

The Open Group – San Diego 2015

Architecture Forum France (Open Group) - mer, 11/05/2014 - 00:01
San Diego, USA 2-5 FĂ©vrier,
Catégories: Association

Web Components, l'avenir du web aujourd'hui

L'actualité de Synbioz - mer, 11/05/2014 - 00:00

Peut ĂȘtre avez-vous dĂ©jĂ  souhaitĂ© pouvoir dĂ©finir de nouveaux Ă©lĂ©ments HTML que vous pourriez rĂ©utiliser ou partager avec d’autres ? AngularJS avec ses directives vous a sĂ»rement apportĂ© un Ă©lĂ©ment de rĂ©ponse. Si on pousse le raisonnement un peu plus loin, on se met Ă  rĂȘver de pouvoir le faire nativement et de maniĂšre standardisĂ©e !

Les « web components » sont donc l’encapsulation de comportements et de structure dans un composant qui est rĂ©utilisable et qui peut ĂȘtre importĂ© depuis une source externe.

Lire la suite...

Catégories: Blog Société

AngularJS pour aujourd’hui et pour demain

ngeurope

Le mercredi 22 et le jeudi 23 octobre a eu lieu la confĂ©rence ngEurope Ă  Paris. Cette confĂ©rence avait principalement pour but de lever le voile sur le futur du framework front end portĂ© par Google : AngularJs. Un des objectifs principaux de ces deux jours était donc d’avoir une vision de ce Ă  quoi va ressembler la version 2.0 du framework. Cependant, loin de vivre dans le songe d’un futur encore lointain (aucune date de release n’a encore Ă©tĂ© officialisĂ©e), ces deux jours ont aussi Ă©tĂ© l’occasion de dĂ©couvrir un Ă©cosystĂšme gravitant autour du framework trĂšs riche et surtout bien ancrĂ© dans le prĂ©sent. On y a entendu des talks sur des sujets aussi variĂ©s que la sĂ©curitĂ©, l’accessibilitĂ©, les bonnes pratiques de dĂ©veloppement, le web mobile, le material design, les tests, les animations riches, les web components et bien d’autres encore.
Qu’il s’agisse de la toute fraiche version 1.3 dĂ©jĂ  sortie en version stable que du fonctionnement de la future version 2.0, cet article va se concentrer sur les nouveautĂ©s du framework annoncĂ©es pendant la confĂ©rence.

Keynote

Le premier jour a commencĂ© par une keynote de Igor Minar et Brad Green qui nous prĂ©sentent notamment quelques chiffres autour du framework. On y apprend que la communautĂ© est trĂšs prĂ©sente sur le framework puisqu’il y a plus de 1000 contributeurs sur le repository Github (contre ~ 400 pour emberjs et ~ 200 pour backbone), que le nombre de favoris (« star ») est de plus de 30 000 pour AngularJs (contre ~11 000 pour emberjs et ~20 000 pour backbone) et que le nombre d’applications augmente de façon quasi exponentielle. Il s’agissait donc par cette introduction de montrer l’intĂ©rĂȘt que suscite AngularJs et la dynamique de sa communautĂ©.

Le reste de la keynote a Ă©tĂ© dĂ©diĂ©e Ă  introduire les diffĂ©rents concepts qui allait ĂȘtre abordĂ©s dans le reste de la confĂ©rence.

 

The « Superluminal Nudge” : AngularJs 1.3

On entre dans le coeur du sujet avec la prĂ©sentation de la nouvelle version de AngularJs “Superluminal Nudge” (1.3) qui est tout juste sortie en version stable le 14 octobre.

Une appli qui booste

Il semblerait tout d’abord qu’il y a eu un gros travail rĂ©alisĂ© sur un point critique lorsqu’il s’agit d’effectuer des traitements cĂŽtĂ© client : les performances. En effet, Jeff Cross et Brian Ford nous montrent les rĂ©sultats plutĂŽt impressionnants des tests de performance sur la boucle de $digest et sur la manipulation de DOM que voici :
Capture d’écran 2014-10-27 Ă  19.20.44

On ajoutera que des améliorations significatives de performances sont encore possibles en désactivant (pour la production) les informations de debug :

$compileProvider.debugInfoEnabled(false);

Avec Angular on a le double data binding qui nous permet d’avoir une synchronisation en temps rĂ©el entre un model et le DOM. C’est ce systĂšme qui fait en partie la force d’Angular mais cela implique aussi qu’une vĂ©rification de modification du model Ă  chaque boucle de $digest doit avoir lieu. Avec Angular 1.3 il est maintenant possible d’indiquer que l’on veut que le binding ne se fasse qu’une bonne fois pour toute afin de gagner en performance, c’est le « One Time Binding » (notez les ‘::’).

 
<table>
 <tr ng-repeat="stock in ::myStocks">
  <td ng-bind="::stock.symbol"></td>
  <td ng-bind="stock.currentQuote"></td>
  <td>Suggested Price: {{::calcValue(stock)}}</td>
 </tr>
</table>
Une appli qui a la form

Au niveau fonctionnel, de gros efforts ont Ă©tĂ© faits sur la gestion des formulaires. On citera tout d’abord la possibilitĂ© de faire des validations de formulaire asynchrone (par exemple, rechercher dynamiquement la prĂ©sence d’un login) :

ngModel.$asyncValidators.isUserAvailable = function(modelVal, viewVal) {
 var val = modelVal || viewVal;
 return $http.get('/api/isUsernameAvailable?username=' + val);
}

De nouvelles options ont également été ajoutées à ngModel :

  • debounce (attendre un delay avant de synchroniser):
    <input ng-model="data" ng-model-options="{debounce: 500}">
  • updateOn (attendre un Ă©vĂšnement avant de synchroniser) :
    <input ng-model="data "ng-model-options="{updateOn:'blur'}">

Pour finir avec les formulaires on notera la prĂ©sence d’une nouvelle directive : ngMessage. Cette directive nous permet de nous dĂ©barrasser pour de bon des div avec ng-show et une condition contenant les erreurs sous cette forme : « signup.userEmail.$error.minlength ». Maintenant pour afficher des messages d’erreurs on fera plutĂŽt de cette maniĂšre plus lisible :

<ng-messages for="signup.userEmail.$error">
 <ng-message when="required">You did not enter a field</ng-message>
 <ng-message when="email">Your field is not an email</ng-message>
 <ng-message when="minlength">Your field is too short</ng-message>
</ng-messages>
En vrac

D’autre amĂ©liorations sont Ă©galement de la partie pour cette version 1.3. On notera la prĂ©sence d’une nouvelle dĂ©pendance « ng-aria » qui permet (si elle est importĂ©e) d’ajouter automatiquement des attributs aria-xxx aux balises html suivant l’Ă©tat en cours. Par exemple, en presence d’un ng-show dans une balise, si la condition est fausse (et donc que les fils de cette balise deviennent invisibles) un attribut aria-hidden va s’ajouter automatiquement.
Un nouveau watcher fait son apparition : le $watchGroup qui permet, comme son nom l’indique, d’Ă©couter des modifications sur un panel d’objet:

$scope.$watchGroup(['user.email', 'user.name', 'user.phone'],updateUserOnServer);

Il est maintenant possible d’utiliser du SVG comme base de template d’un directive.

Angular 2.0

C’Ă©tait probablement le moment le plus attendu de la confĂ©rence, l’annonce du fonctionnement de Angular 2.0. Mais avant d’entrer dans les concepts clĂ©s de la nouvelle mouture du framework intĂ©ressons nous d’abord au nouvel environnement Javascript dans lequel va Ă©voluer le framework

Ecma Script 6, TypeScript, AtScript et Traceur

La version actuelle de AngularJs est construite grace Ă  Javascript et plus particuliĂšrement Ă  l’implĂ©mentation du standard EcmaScript 5 qui est aujourd’hui le standard compris par tous les navigateurs. Mais une nouvelle version de ce standard est actuellement en cours de validation. Il s’agit de… EcmaScript 6 ! Cette nouvelle version du standard ajoute notamment la notion de « class » et de « module » nativement Ă  javascript. AngularJS 2.0 sera donc basĂ© sur ES6 mais ce n’est pas tout !

Microsoft a crĂ©Ă© sa propre extension de langage Ă  ES6. Il s’agit de TypeScript. TypeScript se place au dessus de ES6 et ajoute la notion de typage statique Ă  ES6. Les fichiers contenant du TypeScript sont compilĂ©s pour rendre du ES6 ou ES5 traditionnel.

Mais pour Google, ce n’Ă©tais encore pas suffisant et ils ont dĂ©cidĂ© de crĂ©er leur propre extension de langage qui reprend les idĂ©es de TypeScript en en ajoutant de nouvelles. Il s’agit de AtScript. AtScript ajoute au standard l’introspection de type, et les annotations. On ajoutera que contrairement Ă  TypeScript, AtScript propose un systĂšme de typage dynamique.

atScript

AngularJS 2.0 sera donc basé sur AtScript. Cependant la compatibilité avec ES5 est toujours possible grùce au compilateur Traceur qui permet de transformer du AtScript en ES6 et / ou en ES5.

Quoi de neuf du cotĂ© d’Angular 2.0 ?

Le clou du spectacle a eu lieu au dĂ©but de la seconde journĂ©e de ngEurope. La prĂ©sentation que tout le monde attendait avec impatience n’a pas laissĂ©e indiffĂ©rente. IntitulĂ©e sobrement « AngularJS 2.0 Core » cette prĂ©sentation d’Igor Minar et Tobias Bosch nous en a appris beaucoup sur le futur d’AngularJS.

On commence par la nouvelle syntaxe utilisĂ©e dans les templates html. Ci-dessous un exemple « avant / « aprĂšs » :

Angular 1.3
<div ng-controller="SantaTodoController">
 <input type="text" ng-model="newTodoTitle">
 <button ng-click="addTodo()">+</button>
 <tab-container>
  <tab-pane title="Tobias">
   <div ng-repeat="todo in todosOf('tobias')">
    <input type="checkbox" ng-model="todo.done">
    {{todo.title}}
    <button ng-click="deleteTodo(todo)">X</button>
   </div>
  </tab-pane>
...
Angular 2.0
<div>
 <input type="text" [value]="newTodoTitle">
 <button (click)="addTodo()">+</buton>
 <tab-container>
  <tab-pane title="Good kids">
   <div [ng-repeat|todo]="todosOf('good')">
    <input type="checkbox" [checked]="todo.done">
    {{todo.title}}
    <button (click)="deleteTodo(todo)"> X </button>
   </div>
 </tab-pane>
... 

Dans cet exemple on remarque plusieurs changements. Avec Angular 2.0 on oublie les « ng-click », « ng-keyup »… Les Ă©vĂšnements sont maintenant Ă©coutĂ©s grĂące Ă  une syntaxe gĂ©nĂ©rique qui est : « (eventName) ». Cette syntaxe permet de ne pas avoir un « ng-xxx » pour chaque Ă©vĂšnement mais d’avoir une syntaxe qui fonctionne pour tous les Ă©vĂšnements existants. Dans le mĂȘme ordre d’idĂ©e, les attributs ont une syntaxe gĂ©nĂ©rique : « [attributeName]« . Un des gros avantage de cette syntaxe gĂ©nĂ©rique est d’assurer l’interopĂ©rabilitĂ© avec les web components. En effet l’API de base des web components est d’envoyer des Ă©vĂšnements et d’exposer des attributs.

Vous l’avez peut ĂȘtre remarquĂ© : il n’y a plus de « ng-controller ». Il s’agit d’un autre changement majeur en Angular 2.0. En effet, la nouvelle philosophie d’Angular est de n’utiliser que des directives. Il existera trois types de directives: les « Decorators Directives » utilisĂ©es par exemple pour remplacer les « ng-class », « ng-show », les « Templates Directives »Â utilisĂ©es notamment pour les « ng-repeat », « ng-if » et enfin les « Components Directives » qui correspondent aux directives que l’on a l’habitude de rĂ©aliser en Angular 1.x. Ce changement s’accompagne d’une nouvelle façon d’Ă©crire les directives et qui utilise intensĂ©ment les possibilitĂ©s de EcmaScript 6 et TypeScript (class, annotations, types):

Nouvelle syntaxe pour les directives
@ComponentDirective
class SantaTodoApp {
  constructor() {
    this.newTodoTitle = '';
  }
  addTodo: function() { ... }
  removeTodo: function(todo) { ... }
  todosOf: function(filter) { ... }
}

Cette dĂ©composition en directives signe Ă©galement la mort du trĂšs cĂ©lĂšbre $scope. En effet, avec Angular 2.0 le contexte d’execution est maintenant la directive et plus le controller, les appels Ă  des variables ou des fonctions depuis le template seront donc directement liĂ©s au composant dans lequel ils s’exĂ©cutent. L’injection de dĂ©pendance se fera dĂ©sormais depuis le controller des directives (ou service) et permettra par exemple Ă  deux composants de pouvoir communiquer entre eux.

Une autre grande nouveautĂ© de Angular 2.0 est la refonte du systĂšme de routing. L’Ă©quipe derriĂšre Angular a bien compris les limitations du routeur actuel (basĂ© sur le principe une URL / une vue / un controller) et a dĂ©cidĂ© de recrĂ©er un nouveau routeur. Pour cela il s’inspire grandement du composant open source « ui-router » bien plus complet car il est basĂ© sur un principe d’Ă©tat qui permet par exemple de faire des routes imbriquĂ©es. Le nouveau routeur permettra, en vrac, de gĂ©rer plusieurs routing en parallĂšle (pour gĂ©rer des transitions de façon modulaire dans l’application) ou encore d’effectuer des actions pendant l’activation ou la dĂ©sactivation d’Ă©cran. Pour ceux qui sont impatients de pouvoir l’utiliser, rassurez vous, vous n’aurez pas Ă  attendre la version 2.0 pour vous en servir car l’Ă©quipe derriĂšre Angular compte le porter pour la version 1.3.

De grandes modifications structurelles ont donc Ă©tĂ© rĂ©alisĂ©es. Une grande majoritĂ© des notions dont on a l’habitude sur Angular 1 va tout bonnement disparaitre dans la version 2. On peut Ă©galement citer la disparition de l’utilisation de JqLite (le sous ensemble de Jquery permettant de manipuler le DOM) pour une manipulation directe du DOM ou encore la disparition du systĂšme de module made in Angular remplacĂ© par l’import de module EcmaScript 6. La derniĂšre slide de la prĂ©sentation rĂ©sume bien les diffĂ©rentes modifications apportĂ©es au framework :

Capture d’écran 2014-10-31 Ă  09.39.43

Mais aujourd’hui on fait quoi ?

La version 2.0 du framework est encore en phase dĂ©veloppement intensif par les Ă©quipes de Google. Il n’y a de plus aucune date de release annoncĂ©e, tout au plus une estimation qui varie entre fin 2015 et dĂ©but 2016. Pas la peine donc de se prĂ©cipiter pour faire ses projets en Angular 2.0 (mĂȘme s’il est toujours intĂ©ressant de rester informĂ© sur son Ă©volution) d’autant plus que beaucoup d’eau va encore couler sous les ponts et ce qui a Ă©tĂ© annoncĂ© Ă  ngEurope ne sera peut ĂȘtre plus totalement vrai d’ici la sortie officielle.

Aujourd’hui il convient donc de continuer Ă  developper ses applications Angular en version 1.x. Google a assurĂ© qu’il continuera Ă  faire Ă©voluer et Ă  maintenir la branche 1.x jusqu’a un Ă  deux ans aprĂšs la sortie de la version 2.0. Cela ne veut pas dire que les applications crĂ©Ă©es Ă  partir d’une version 1.x ne fonctionneront plus ou ne pourront plus Ă©voluer mais que le langage n’Ă©voluera plus. Bien qu’il semble peu probable que le portage d’une application 1.x en 2.0 soit faisable, Google annonce tout de mĂȘme qu’aprĂšs la sortie de la version 2.0 il proposeront une maniĂšre de migrer les applications faites en 1.x.

@Clement_D

Suggestion d’articles :

  1. Paris web 2014 : les T.I.C et l’Ă©thique
  2. Retour d’expĂ©rience : 5 idĂ©es pour amĂ©liorer les performances d’une application Web AngularJS
  3. Les nouvelles architectures front Web et leur impact sur les DSI – Partie 1
  4. Les nouvelles architectures front Web et leur impact sur la DSI – partie 2
  5. DĂ©velopper un jeu avec JHipster, HTML 5 et LeapMotion

Les images et exemples de codes ont été extraits des slides des différentes sessions disponibles ici :

Catégories: Blog Société

Partagez la connaissance

Partagez BlogsdeDeveloppeurs.com sur les réseaux sociaux