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

[ #Office365 ] Comment créer un formulaire Excel ?

Le blog de Patrick Guimonet - jeu, 03/13/2014 - 09:21
La possibilité de créer une enquête Excel est accessible depuis la mise à jour d’août 2013 sur Office 365. C’est l’une des 5 solutions (avec InfoPath !) de formulaires disponibles en natif sur SharePoint /Office 365. Vous trouvere...
Catégories: Blog Individuel

La fonte, une alternative aux sprites CSS pour gérer ses icônes

Blog d’Ippon Technologies - jeu, 03/13/2014 - 09:00

Les icônes (ou pictogrammes), sur un site web, sont de petits visuels aisément identifiables associés à une action. Par exemple, on pourra mettre une flèche vers la droite pour passer à la page suivante, un dessin d’imprimante pour avoir une version imprimable de la page, une enveloppe pour avoir l’adresse mail de contact, une loupe pour une recherche… Ces images, très abondantes, posent le problème du nombre de requêtes http nécessaire pour tous les charger. En effet, nous savons que le nombre de requêtes http joue dans le temps de chargement d’un site. Une manière très commune de limiter le nombre de requêtes est de regrouper tous les pictogrammes dans une seule image. On accèdera ensuite par la css à la partie désirée. C’est ce que l’on appelle les sprites css.

Cependant, avec l’arrivée de css3 et de @font-face, une autre possibilité commence à être explorée : l’utilisation des fontes-icône, ces polices de caractères dans lesquelles les lettres sont remplacées par des symboles. Voici un exemple d’une telle police que vous pouvez utiliser. Bien entendu, le must reste de créer la sienne, en fonction de ses besoins.

Avantages et inconvénients
  • Toutes les transformations css possibles sur une police de caractère sont utilisables sur les fontes-icĂ´nes : taille, couleur, ombres. En utilisant des images, il faudrait en crĂ©er une pour chaque dĂ©clinaison.
  • Le revers de la mĂ©daille est que la fonte-icĂ´ne est forcĂ©ment monochrome, si on peut varier la couleur, on n’en a qu’une Ă  la fois.
  • Le redimensionnement par l’utilisateur ou l’utilisation d’écran hd va affecter la qualitĂ© d’une image png, mais les images vectorielles des fontes n’auront aucun problème Ă  les gĂ©rer (mis Ă  part les problèmes rencontrĂ©s avec chrome sous windows).
  • Si la fonte-icĂ´ne n’est pas chargĂ©e, le navigateur va la remplacer par une police par dĂ©faut. De mĂŞme, un utilisateur non-voyant entendra le texte correspondant Ă  l’icĂ´ne. Cela peut prĂ©senter un inconvĂ©nient, mais peut Ă©galement ĂŞtre tournĂ© Ă  notre avantage, selon le lien fait dans la fonte entre le texte et l’image.

Bref, il n’y a pas de réponse absolue, si l’icône doit pouvoir se décliner en plusieurs couleurs et dimensions, la fonte-icône semble être une réponse plus adaptée, à condition d’accepter d’avoir des pictogrammes monochromes.

Créer sa fonte-icône avec FontForge

Si on veut intégrer des pictogrammes spécifiques à notre site, le seul moyen est de créer sa propre fonte-icône. La bonne nouvelle, c’est que ce n’est pas si compliqué que cela. Faisons donc notre propre fonte en quelques étapes.

Dans un premier temps, il nous faut des icônes sous format svg. Pour la démonstration, j’ai téléchargé Iconic et utilisé un convertisseur en ligne. Ceux qui veulent approfondir la transformation d’images en svg peuvent utiliser Inkscape, ou créer les svg directement dans FontForge.

Une fois FontForge installé, à l’ouverture de l’application, on choisit de créer une nouvelle fonte.font-icone-1

On obtient une liste de caractères dont aucun n’a de dessin (glyphe) associé. font-icone-2

  On décide que le A (comme Accueil) représentera une petite maison. Je double-clique sur le A, puis je choisis dans le menu Fichier “Importer…”.

font-icone-3Je sélectionne le format svg et je vais chercher mon image. Voici ce que j’obtiens dans ma glyphe :

font-icone-4Il est possible, en laissant la sélection sur le format “Image”, de prendre un autre format que svg. Cependant, l’image ne sera pas convertie au format svg : elle sera affiché en fond, pour permettre de dessiner à la main au format svg par-dessus.

Je crée la lettre I et la lettre C de la même manière. Pour les autres lettres, j’ai triché un peu : j’y ai collé le caractère “espace” d’une autre fonte. Vous pouvez également créer le fichier svg correspondant à ce caractère pour l’importer, le svg étant du xml. Voici le contenu du fichier svg généré à partir de l’espace d’une fonte gratuite :

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd" >
<svg viewBox="0 -200 1000 1000">
  <g transform="matrix(1 0 0 -1 0 800)">
   <g  />
  </g>
</svg>

Je vais ensuite dans le menu Fichiers > Générer Fonte(s), et j’exporte ma fonte au format Web Open Font (.woff). Comme je vais tester sous Firefox, cela me suffit, mais pour un projet réel, il faudra générer les autres formats.

Voici le bout de css où je déclare ma fonte :

@font-face {
    font-family: 'maFonte';
    src:  url('test-webfont.woff') format('woff');
    font-weight: normal;
    font-style: normal;

}

.tabs li a {
    display: block;
    color: #fff;
    text-decoration: none;
    font: 1.5em 'maFonte';
    padding: 0.5em;
    border-right: 1px solid #fff;
}

Et le code html correspondant :

<ul>
        <li><a href="#accueil" title="accueil">Accueil</a></li>
        <li><a href="#ippon" title="Ippon">Ippon</a></li>
        <li><a href="#contact" title="contact">Contact</a></li>        
</ul>

Voici le résultat :

font-icone-5Pourquoi avoir écrit en toutes lettres notre menu, alors que seule la première est transformée en pictogramme, les autres étant remplacées par des espaces (et présentant l’inconvénient d’un décentrage du placement) ? C’est très simple : imaginons que pour une raison quelconque, notre police ne soit pas chargée. Voici ce que l’on obtient :

fonte-icone-6Il y a aussi un avantage en terme d’accessibilité : un logiciel de lecture utilisé par un non-voyant lira “Accueil”, “Ippon” et “Contact”. S’il lisait “A”, “I” et “C”, ce serait bien moins compréhensible.

Avec plus de pictogrammes ?

Ma petite astuce pour l’accessibilité rencontrera rapidement ses limites, par exemple si on a besoin d’une icône pour “Informations”.
Une solution préconisée est d’utiliser des caractères unicodes qui ne seront pas lus, à la place des lettres et des chiffres, pour y placer ses icônes. Ce sont des caractères appartenant à la Private Use Area (pua). C’est la solution choisie par Font-Awesome.
Une autre possibilité est d’utiliser les ligatures. En typographie, il s’agit de remplacer des caractères qui ne vont pas aller bien ensemble (par exemple : fi peut avoir le point du i qui se confond avec le haut du f) par une glyphe regroupant les deux caractères. Le gros intérêt des ligatures est de pouvoir utiliser plus aisément notre fonte-icône : pour obtenir l’image de l’accueil, au lieu d’écrire A ou &#x21dd;, on écrit Accueil, et c’est l’ensemble de ce texte qui est transformé en pictogramme par la magie des ligatures. Pousser le concept permet de créer une ligature pour chaque heure/minute du jour et afficher ainsi une horloge sur sa page. Malheureusement, il semble que les navigateurs ne prennent pas systématiquement en compte les ligatures.

Quelques ressources supplémentaires

Pour ceux que FontForge rebuterait, ce tutoriel explique comment faire avec Icomoon, un outil gratuit en ligne. Et pour les heureux possesseurs de licences Adobe, cet article expose la création de la fonte-icône de GitHub avec Photoshop, Illustrator et Font Squirrel.

Catégories: Blog Société

mdevcon 2014

Le 7 et 8 mars dernier, avait lieu la mdevcon 2014. J’ai eu le privilège d’ĂŞtre choisi aux call for paper pour prĂ©senter une session sur l’expĂ©rience utilisateur Android : « My Android is not an iPhone like any others » et j’ai pu assister aux 2 jours de confĂ©rences. En voici le compte rendu…

1er jour : « Tutorial day »

Entre deux sessions typiquement iOS (Debuging avec XCode 5 et Core data), deux sessions plutĂ´t Android (Google Maps et crash reporting), j’ai prĂ©fĂ©rĂ© me diriger vers 2 sessions transverses :
« Mobile Protoyping » le matin et « Going Mobile with the Cloud » l’après-midi.

Mobile Prototyping

Donna Lichaw est venue de New York pour nous parler de mobile prototyping. Nous avons commencĂ© par discuter du « why » du prototyping. Entre autre, cela permet de tester, affiner et valider un concept, avoir un feedback et les rĂ©actions des utilisateurs le plus vite possible, construire un MVP.
Prototyper sur mobile a encore plus de sens selon elle. La navigation est extrĂŞmement importante sur mobile, ainsi que le contenu des Ă©crans qui doivent contenir l’essentiel. C’est aussi gĂ©nĂ©ralement plus cher Ă  dĂ©velopper et surtout plus compliquĂ© Ă  corriger (elle parle notamment de l’App Store oĂą la phase de validation par Apple est un frein).
Mais au delĂ  de tout ça, prototyper permet de rassembler toute l’Ă©quipe autour du produit, Ă  condition que tout le monde participe. Aussi bien les designers que les dĂ©veloppeurs, ou encore les managers et sponsors, tout le monde s’approprie le produit, ce qui facilitera la suite du projet.

Donna nous a ensuite décrit les différents types de prototype:

  • Les storyboads qui permettent de dĂ©finir l’interaction entre l’utilisateur et le système, les diffĂ©rentes Ă©tapes d’utilisation du produit. Cela s’apparente plus Ă  une sorte de use case qu’Ă  un prototype d’Ă©cran.
  • Le paper prototyping qui permet de très rapidement dessiner des Ă©crans sur papier. C’est très bien pour brainstormer et avoir les premiers feeedbacks pour un investissement faible (https://www.youtube.com/watch?v=GrV2SZuRPv0). Le but n’est pas de rentrer dans les dĂ©tails, mais d’avoir une idĂ©e globale des diffĂ©rents Ă©crans.
  • Des maquettes imprimĂ©es. Si vous voulez quelque chose de plus raffinĂ©/dĂ©taillĂ© que le papier, vous pouvez commencer Ă  utiliser des outils de mockup ou photoshop et les imprimer pour jouer avec. C’est dĂ©jĂ  plus cher que le dessin mais cela permet d’avoir quelque chose de plus consistent Ă  montrer Ă  des utilisateurs.
  • Vous avez aussi la possibilitĂ© d’afficher des maquettes sur l’Ă©cran du device (dans la galerie) afin d’Ă©valuer le comportement des utilisateurs sur des vrais Ă©crans sur un vrai mobile.
  • Viennent ensuite les prototypes avec du code. On les utilisera plus souvent pour valider la faisabilitĂ© technique d’une fonctionnalitĂ© ou pour valider quelque chose de dynamique (animation).

Elle nous a ensuite donné quelques bonnes pratiques pour les interfaces mobiles. Adopter les conventions des systèmes: NavigationBar et TabBar sur iOS par exemple. De même pour les différents composants : préférez le DatePicker du système ou alors protoypez et testez votre version pour avoir du feedback.
Concernant les gestures, les 3 plus communes sont le tap, le swipe et le flick (swipe rapide ou scroll). Les autres sont rarement connus et utilisĂ©s par les utilisateurs. Évitez donc les swipe Ă  trois doigts ou autres actions cachĂ©es (long press, double tap, …)

Enfin, elle nous a donnĂ© une liste d’outils utiles pour prototyper. Celui qui m’a particulièrement impressionnĂ© est flinto. Regardez cette petite demo pour vous en convaincre.
Nous avons Ă©galement regardĂ© POP. Il s’agit d’une application Android et iOS qui permet de très rapidement dĂ©finir la navigation de votre application:

  • Soit vous faites du paper prototyping et vous prenez vos dessins en photo
  • Soit vous pouvez utiliser vos maquettes.

Vous définissez ensuite des zones cliquables et les actions associées :

Prototyping on Paper

Pendant le TP qui a suivi, nous avons rĂ©alisĂ© un prototype d’application de partage de photos en 20 minutes, dessins compris, grâce Ă  cette application.
D’autres outils ont Ă©tĂ© mentionnĂ©s comme Keynotopia, Axure, Appseed, Briefs, FluidUI, …

Elle a conclu son tutorial en nous disant qu’il valait mieux (qu’elle prĂ©fĂ©rait) prototyper sur mobile d’abord. Cela permet de se concentrer sur l’essentiel (1 action / Ă©cran) et de limiter les fonctionnalitĂ©s. Cela a aussi l’avantage d’ĂŞtre testĂ© facilement un peu partout. Et surtout, il est plus simple de scaler vers du web que l’inverse.

Une première matinée très intéressante ! Les slides sont disponibles ici.

Going Mobile with the Cloud

L’après midi, j’ai assistĂ© au tutoriel de Chris Risner (Evangelist Windows Azure chez Microsoft). Je ne vais pas rentrer dans le dĂ©tail de ce tutorial. Nous avons passĂ© en revue une bonne partie des fonctionnalitĂ©s d’Azure en l’intĂ©grant Ă  une application mobile. Chacun pouvait choisir sa plateforme et mettre en oeuvre le tuto Ă©galement disponible sur github.
C’Ă©tait une bonne introduction au service de Microsoft que je n’avais jamais utilisĂ©. Cela m’a permit de mettre en oeuvre pas mal de choses assez rapidement : manipulation des donnĂ©es, traitements cĂ´tĂ© serveur, notifications push, authentification… Les slides sont Ă©galement disponibles sur le github.

Soirée speakers

Nous avons ensuite passé la soirée entre speakers : dîner sur un bateau sur les canaux, puis avant-première de 300 au cinéma. Merci aux organisateurs de tout ça.

Au final une première journée assez riche !

2ème jour : « Conference day »

Les conférences ont eu lieu dans un endroit assez exceptionnel, le théâtre Tuschinski.

Keynote : Make people care !

Rob Rhyne est co-fondateur de Martiancraft, auteur entre autre de Briefs, un des outils de prototyping que je citais plus haut. Sa keynote était dédiée au marketing des applications mobiles. Selon lui, il ne faut pas viser trop haut, vouloir devenir millionaire avec une application est dérisoire. Environ 1% des applications sur les stores engendrent plus de 90% des revenus.

Ainsi la première Ă©tape consiste Ă  Ă©valuer l’audience et le prix de son application. S’il y a environ 750 000 000 devices iOS sur le marchĂ©, il est clair qu’on ne peut pas espĂ©rer tous les atteindre. Sur ce nombre, environ 1% paye pour des applications (soit Ă  l’achat, soit in-app), soit 7 500 000. Bien sĂ»r, toutes ces personnes ne seront pas intĂ©ressĂ©s par votre application. Admettons qu’il y en ait 1% (75 000), c’est un nombre raisonnable mais il s’avère qu’en gĂ©nĂ©ral il n’y a que 7.25% de ces 75 000 que vous puissiez atteindre, soit 5 625 personnes. Vous pouvez faire mieux bien sĂ»r mais aussi moins bien. Il n’a citĂ© aucune source pour ces chiffres, donc Ă  prendre avec des pincettes. Mais cela me semble une bonne moyenne.

Il a ensuite parlĂ© d’argent. Que souhaitez-vous gagner avec votre application ? 1 million de dollars ? Il faudra vendre votre application 177$. Ce n’est pas raisonnable. 250k ? 44$ l’application. Difficile! 100 000$ ? 17$ l’application. Encore bien au dessus des prix du marchĂ© ! Si vous descendez Ă  1$, vous obtiendrez 5625$. Ah non pardon 3937, Google et Apple en prenant 30 % au passage !

Bref, si vous souhaitez gagner plus, il va falloir atteindre plus de monde et pour ce faire, il faut du marketing (« Make people care ») ! Plusieurs choses Ă  faire :

  • Parlez de votre application. Mais pas seulement de l’application en elle-mĂŞme, parlez Ă©galement de comment vous l’avez faite ? Cela permettra de ramener des dĂ©veloppeurs, des geeks qui feront parler de votre app. N’attendez pas d’avoir publiĂ© l’application pour en parler. N’hĂ©sitez pas Ă  contacter des journalistes ou des blogs afin qu’ils testent l’application en premiers et fassent de la pub.
  • Partagez votre application avec les autres. Ne considĂ©rez pas que c’est VOTRE application et que personne ne doit vous dire comment la faire. Acceptez les feedbacks des utilisateurs !
  • Troisième et dernier point, « keep going ». Une fois l’application publiĂ©e, ne dormez pas sur vos lauriers. Corrigez les bugs, rĂ©pondez aux utilisateurs et continuez d’en parler et de partager.

Plusieurs fois pendant la session il a dit : « You are special« . C’est aussi avec cette note qu’il a conclu. En tant que dĂ©veloppeurs mobiles, nous avons le pouvoir entre nos mains, la capacitĂ© de crĂ©er des choses et potentiellement de gagner pas mal d’argent avec.

Resistance is Futile: Google Glasses and the cyborg workforce of the future

Resistance is futile

Donna Lichaw, encore elle, nous a fait tout un parallèle entre la science fiction d’hier et la rĂ©alitĂ© d’aujourd’hui, comparant ainsi le premier tĂ©lĂ©phone mobile au moyen de communication utilisĂ© par le Capitaine Kirk dans Star Trek.

Mais attention Ă  l’effet Robocop (Frankenstein des temps modernes), la technologie doit exister pour nous aider, rĂ©soudre des problèmes que nous avons, pas simplement pour copier tel ou tel scĂ©nario SF.

Ainsi au sujet des Google Glasses, elle cite trois aspects qui permettent de dire que ce sera (c’est) utile :

  • « J’ai un travail qui nĂ©cessite que mes mains soient libres pour le faire. » Elle cite notamment Terminator qui avait besoin de ses mains pour dĂ©gommer tout le monde. Mais plus sĂ©rieusement, de nombreux mĂ©tiers sont dans ce cas : les pilotes de chasse (qui ont dĂ©jĂ  un affichage digital sur leur cockpit ou dans leur casque), les chirurgiens (qui font un hangout pour faire une dĂ©monstration ou avoir des conseils en temps rĂ©el), les pompiers, la police qui patrouille (cf. Robocop et la police de New York qui testent les lunettes actuellement).
  • « Je suis mobile (Ă  grande vitesse) et ne doit pas utiliser mes mains ou dĂ©tourner le regard ». LĂ  encore les pilotes d’avions de chasse, mais Ă  peu près n’importe quel pilote ou chauffeur ayant besoin d’aide Ă  la navigation, peut en avoir l’utilitĂ©.
  • « Je suis atteint d’un handicap et je veux pouvoir faire ce que les autres font ». Par exemple aider les personnes mal voyantes Ă  se dĂ©placer.

Une session assez marrante et qui nous plonge dans un retour vers le futur assez flippant. Les slides sont disponibles ici.

Lightning fast mobile development at scale

Akhilesh Gupta, de LinkedIn, nous a présenté le processus de développement de leurs applications mobiles (iOS / Android / web) :

  • Petite originalitĂ© pour commencer : Les vues sont construites Ă  partir de JSON rĂ©cupĂ©rĂ©s sur le serveur. Cela leur permet de faire Ă©voluer plus rapidement leur IHM sans avoir Ă  faire de mise Ă  jour de l’application. De plus, pour certains Ă©lĂ©ments, ils utilisent les mĂŞme templates JSON. Cela leur offre une certaine cohĂ©rence entre les diffĂ©rents Ă©crans.
  • D’autres pratiques sont plus communes : IntĂ©gration continue, dates de release fixes, crash reports.
  • Concernant les tests des applications mobiles, ils utilisent appium.io, un outil de test d’interface cross-plateforme et basĂ© sur Selenium (WebDriver JSON wire protocol). CĂ´tĂ© serveur (sur node.js), ils n’a pas mentionnĂ© l’outil de test mais pour leurs tests d’intĂ©gration, ils sont passĂ©s de 30 minutes Ă  15 secondes d’exĂ©cution grâce Ă  sepia. Cela leur permet d’exĂ©cuter les test unitaires et d’intĂ©gration Ă  chaque build.
  • Ils n’utilisent pas de feature branch sur leur SCM, tout est sur le trunk ! Ils font confiance Ă  leur batterie de tests. Et lorsqu’il y a des fonctionnalitĂ©s non terminĂ©es, ils utilisent le feature flipping, pilotĂ© par le serveur.
  • Le feature flipping leur permet Ă©galement de faire le l’A/B Testing (tester une fonctionnalitĂ© pour certains utilisateurs et une autre pour d’autres). Ils font plutĂ´t cela pendant des phases de beta avec la console de dev Android et TestFlight sur iOS. Un article intĂ©ressant de LinkedIn sur l’A/B testing et les vues json.

Au final une session fort intĂ©ressante sur les pratiques d’un gĂ©ant du web.

I can animate and so can you

Aussi incroyable que cela puisse paraĂ®tre, c’est la première session exclusivement Android Ă  laquelle j’ai assistĂ©. Daniel Lew, qui nous avait dĂ©jĂ  fait rĂŞver Ă  la Droidcon de Londres en octobre dernier, a remit le couvert en nous expliquant les grands principes et bonnes pratiques des animations sur Android. Pour info, Daniel Lew est dĂ©veloppeur Android sur l’application Expedia, une application particulièrement rĂ©ussie (A tester !).
4 choses importantes quand on veut animer des vues sur une application :

  • Chaque animation est unique. Choisissez la bonne animation au bon moment et au bon endroit.
  • Le code des animations n’est pas beau. Tant pis pour les amoureux du beau code !
  • Pensez et implĂ©mentez les animations en premier. Cela sera plus simple et plus performant que d’essayer d’animer des choses qui n’ont pas Ă©tĂ© prĂ©vues pour.
  • Animez pour des devices en Android 4+. Les perfs sont mauvaises de toute façon sur les anciennes versions et surtout il n’est pas possible de tout faire.

Je ne vais pas rentrer plus dans les détails de cette session assez technique, mais les slides sont dispo ici.

My Android is not an iPhone like any others

Concernant ma session, voici les slides (un article avait déjà été publié sur ce blog) :

Controlling Grundfos pumps with iOS and Android devices

Un mot sur la session de Adrian Kosmaczewski qui nous expliquait ce qu’ils ont mis au point pour piloter des pompes. Ils ont crĂ©Ă© des connecteurs infra-rouges capable de dialoguer avec toutes sortes de pompes et pluggables sur des iPhones. Ils ont ensuite mis au point des applications permettant de rĂ©cupĂ©rer des informations de la pompe et mĂŞme de la piloter (accĂ©lĂ©rer, ralentir, augmenter le dĂ©bit, …). Tout cela pour le plus gros vendeur de pompes de la planète : Grundfos. Comme quoi il y a des applications pour tout !

Kenote de fin : What’s next ?

Saul Mora a voulu nous parler de l’après mobile. Il a commencĂ© par nous retracer l’historique de l’informatique depuis les mathĂ©matiques jusqu’au PC, en passant par la calculatrice de Leibniz, puis les ordinateurs portables et enfin les tĂ©lĂ©phones mobiles. Il nous a ensuite donnĂ© ses « prĂ©dictions ». MĂŞme si le jeu est compliquĂ©, il ne s’est pas trop mouillĂ© :

  • Des meilleures batteries, pour que nos nouveaux joujous durent plus d’une journĂ©e.
  • Les wearables : montres (Gears), vĂŞtements, chaussures (Nike), lunettes (Google Glasses), bracelets santĂ©s (Fitbit).
  • Les interfaces non touchables, commandes vocales (Siri, Google Now)
  • iBeacon ou Ă©quivalent
  • Le Machine Learning (Google Now) et les rĂ©seaux de neuronnes articificiels (IA)
  • Mesh Networking : analyse du trafic et communication entre vĂ©hicules pour les voitures autonomes

Tous ces Ă©lĂ©ments faisaient Ă©cho Ă  la prĂ©sentation de Donna le matin, oĂą comment la science fiction rejoint aujourd’hui la rĂ©alitĂ©. Et de conclure que nous (les humains) devions aussi avoir notre place dans tout ça, que tout cela ne doit exister que pour amĂ©liorer l’humanitĂ©…

Suggestion d'articles :

  1. mdevcon 2013
  2. Agile Games France 2014
  3. Mobile World Congress 2014

Catégories: Blog Société

Edito Mars 2014

Nous inaugurons une nouvelle sĂ©rie d’articles rĂ©guliers destinĂ©s Ă  vous donner notre avis sur ce qu’il se passe dans le monde Tech.

 

Javascript, ma muse ?

#WebFront
En ce début d’année 2014, les frameworks MVC Javascript sont partout. Montés en puissance en 2012 et 2013 ils sont désormais bien installés (cf Les nouvelles architectures Front Web et leur impact sur la DSI).
Les demandes de nos clients sur ces technologies nous confortent sur le fait que ces technologies doivent être maîtrisées en 2014.
Si l’une de vos bonnes résolutions de cette année est de monter en compétence sur un framework MVC Javascript, une des premières étapes est d’en choisir un.
Attention : ce choix ne devra pas être gravé dans le marbre. Il faut y aller, mais tenez vous informés régulièrement, tout bouge très vite.
Ce mois-ci, nous avons retenu un article de Craig McKeachie brossant un état des lieux des frameworks MVC Javascript à date de Septembre 2013 : Choosing a JavaScript MVC framework. Au lieu de faire une comparaison bête et méchante en terme de fonctionnalités, Craig aborde les aspects communauté, leadership, philosophie, dépendances…
A l’heure actuelle, chez Octo, nos choix se portent sur AngularJS et Backbone.js.
Le petit conseil : si vous choisissez AngularJS, voici un lien qui pourra vous aider : Apprendre AngularJS en un jour, le guide ultime (en VO : Ultimate guide to learning AngularJS in one day).

 

Refactor un jour, Refactor toujours !

#SoftwareCraftmanship
2014, ce ne sont pas que des nouveautĂ©s disruptives. Martin Fowler nous rappelle quels sont les diffĂ©rents use cases (ou workflow) de refactoring que nous sommes susceptibles de rencontrer dans notre vie de dĂ©veloppeurs de tous les jours : Worflows of Refactoring. Si vous lecteurs n’êtes pas des refactoreurs, regardez ces slides et vous comprendrez que le refactoring est un Ă©lĂ©ment de base du mĂ©tier de dĂ©veloppeur (qui a dit Software Craftsmanship ?). Parce que nous ne sommes pas des intĂ©gristes mais des pragmatiques, retenons ces 2 dernières phrases de Martin : « Remember the economic justification » et « Balance refactoring with feature delivery« .

 

Fest Assert est mort, vive AssertJ

#SoftwareCraftmanship
Qui dit refactoring dit Tests Unitaires. Nous profitons de la refonte graphique du site d’AssertJ pour vous rappeler que ce projet est un fork actif de la très populaire librairie Fest Assert. Ancien contributeur de Fest Assert, Joël Costigliola a voulu revenir à un modèle de librairie piloté par la communauté et riche d’assertions. Nous vous conseillons d’essayer cette librairie si vous ne l’avez pas encore fait. Si vous n’utilisez pas un framework de ce type pour écrire des assertions évoluées voir customisées, ou bien si vous êtes encore sur le vieillissant Fest Assert, sautez le pas et basculez à AssertJ !

 

NoSQL challenging

#NoSQL
Si le domaine NoSQL vous intéresse (j’enfonce des portes ouvertes ?), nous vous recommandons de lire les articles de Kyle Kingsbury de la série Call me maybe (Riak, NuoDb, Cassandra, Kafka, MongoDB, Redis). Il examine les bases NoSQL en les secouant très fort pour voir leurs limites en terme de durabilité, cohérence, performance : il regarde les promesses puis vérifie (!). A lire pour le contenu et l’approche ou si vous voulez challenger rapidement une base NoSQL par rapport à votre besoin.

 

#DĂ©batSansFin #AdaptAndProgress

#SoftwareCraftmanship
Nous vous signalons un article intéressant de par son originalité sur une des bonnes pratiques du mouvement Software Craftmanship : Pairing vs Code Review : Comparing Developer Cultures. Vous trouverez des palanquées d’articles suivant le schéma classique “Les [avantages|dangers] du [Pair Programming|Code Review]”, mais Paul Hinze veut en faire une comparaison orientée Culture du Développeur. Sa conclusion : admettez vos faiblesses dans votre approche et améliorez-vous. Si vous n’en avez pas encore une, trouvez une équipe pour qui le code et les bonnes pratiques sont importantes et résolvez des problèmes ensembles.
Pour nous, peu importe que vous fassiez du Pair Programming, du Code Review ou encore un mix des 2 : faites votre cuisine pour progresser et vous améliorer (Amélioration Continue).

 

Optimisations poussées

#Performances
Un nouveau pool de connections fait le buzz : HikariCP. Ce pool JDBC a Ă©tĂ© annoncĂ© comme le plus performant du marchĂ© avec « zĂ©ro overhead ». Nous vous conseillons de lire les explications très intĂ©ressantes de leurs optimisations : Down the Rabbit Hole.
L’auteur avait fait un benchmark qui s’est rĂ©vĂ©lĂ© trop optimiste. Heureusement, il l’a corrigĂ© et les rĂ©sultats sont plus rĂ©alistes mais toujours prometteurs.
Nous vous recommandons d’utiliser Tomcat JDBC Pool ou HikariCP (attention à sa maturité) qui semblent être les plus rapides du marché à l’heure actuelle et surtout d’éviter DBCP et c3p0.

Suggestion d'articles :

  1. Maven Community news – Mars 2007
  2. Maven Community news – FĂ©vrier et Mars 2008
  3. Petit-dĂ©jeuner « AgilitĂ© et ERP » avec le tĂ©moignage de Danone, le 22 mars

Catégories: Blog Société

SDK Sphero – Part 3 – Les macros

SDK Sphero – Part 3 – Les macros
Après avoir appris Ă  piloter sphero et utiliser ses capteurs, je vais clore cette sĂ©rie en vous parlant de son système de macro. Qu’est-ce qu’une macro? PrĂ©sentes dans beaucoup de logiciels, elles proposent le plus souvent de rĂ©aliser automatiquement des...
Catégories: Blog Société

[ #Office365 ] [#SharePoint 2013] Quelles solutions de formulaires pour remplacer InfoPath ?

Le blog de Patrick Guimonet - mer, 03/12/2014 - 09:25
    Pour faire suite à l’annonce officielle de la fin du support d’Infopath (cf. Update on InfoPath and SharePoint Forms) de nombreux clients et utilisateurs s’interrogent sur les besoins de formulaires dans SharePoint et Share...
Catégories: Blog Individuel

JavaScript sans bogue, la vidéo de ma conférence

Mathieu Robin - mer, 03/12/2014 - 08:23

En octobre dernier, je participais comme orateur à la Blend Conference. Très bien organisée, le WiFi était au top et surtout, ils ont filmé tous les talks. Dont le mien, du coup.

Je vous laisse découvrir la vidéo :

https://www.youtube.com/watch?v=rZQNfgK90aE

On y parle point-virgule, return, this, tests unitaires, intĂ©gration continue, etc. Tout plein de choses bien qui permettent d’Ă©viter l’essentiel des problèmes.

flattr this!

Catégories: Blog Individuel

Angular et TypeScript, un mariage heureux !

Angular est devenu en peu de temps LE framework JavaScript du moment. BĂ©nĂ©ficiant d’un "effet waouh" impressionnant, il n’en reste pas moins que ni le framework, ni sa documentation, ne sont parfaits. Une partie des problèmes d’Angular est liĂ©e Ă  des choix "logiciels" (le routeur par dĂ©faut ou les directives par exemple), l’autre partie est inhĂ©rente au langage JavaScript. C’est pour circonvenir Ă  cette deuxième catĂ©gorie que nous nous proposons d’Ă©tudier TypeScript.

TypeScript fait partie de la ribambelle de langages alternatifs compilant en JavaScript. Ses caractĂ©ristiques principales sont le typage statique Ă  la compilation et le fait qu’il soit un super-ensemble de JavaScript, visant Ă  rester le plus proche possible de la futur norme EcmaScript 6 pour la syntaxe.

Mais alors, que peut bien apporter le mĂ©lange de ces 2 technologies ? C’est ce que nous allons voir dans la suite.

Mise en place du projet

Le projet que nous allons utiliser comme support se propose d’afficher dans une page web la liste des planètes du système solaire. Vous pouvez le retrouver sur github : https://github.com/blemoine/angular-typescript-planet

Compilation de TypeScript

TypeScript étant un langage compilé vers JavaScript, la première étape pour pouvoir travailler est de mettre en place un système de compilation. Il existe pour cela des plugins dans à peu près toutes les technologies de build du moment, de Maven à Gulp en passant par Grunt.

TypeScript autorise 2 modes de compilation : EcmaScript 3 (compatibilitĂ© IE6) et EcmaScript 5 (CompatibilitĂ© IE9). Ici, nous ciblerons EcmaScript 5, car sans cela, il nous serait impossible d’utiliser les getter/setter ou encore les mĂ©thodes de haut niveau comme filtre ou map.

Un exemple de GruntFile.coffee permettant la compilation est disponible sur le repository github.

Fichier de définitions

TypeScript Ă©tant un langage typĂ© statiquement, il est nĂ©cessaire de fournir au compilateur un fichier de dĂ©finition des types lorsque l’on souhaite utiliser une librairie externe. Ce fichier de dĂ©finition apporte ensuite un confort important dans le dĂ©veloppement car il permet Ă  votre IDE de connaĂ®tre prĂ©cisement les propriĂ©tĂ©s disponibles sur un objet. On pourra retrouver un grand nombre de fichiers de dĂ©finitions pour de très nombreuses librairies sur le repository Definitely Typed

Vos fichiers utilisant la variable globale angular doivent donc maintenant commencer par une rĂ©fĂ©rence au fichier de dĂ©finition d’Angular, disponible plus prĂ©cisĂ©ment Ă  l’url : https://github.com/borisyankov/DefinitelyTyped/blob/master/angularjs/angular.d.ts. Ce fichier de dĂ©finition rĂ©fĂ©rence celui de jQuery, il est donc nĂ©cessaire de tĂ©lĂ©charger aussi celui-ci : https://github.com/borisyankov/DefinitelyTyped/blob/master/jquery/jquery.d.ts

Le modèle

La notion de modèle du pattern MV* est quelque peu cachée par Angular. TypeScript permet finalement de faire ressortir cette notion bien mieux en manipulant des objets typés plus fortement.

Nous allons ici crĂ©er une interface Planet, et utiliser le fait que TypeScript supporte le typage structurel : il n’est pas obligatoire d’implĂ©menter explicitement une interface si le contrat d’interface est respectĂ© par l’objet.

interface Planet {
    name:string
    isRocky:boolean
}
Initialisation de la page avec un controller

Nous allons maintenant rĂ©aliser l’affichage d’une liste de planètes fournie par un controller dans une page. Le controller Ă©crit en TypeScript donnera par exemple :

/// <reference path="../definition/angularjs/angular.d.ts" />
var planetsModule = angular.module('planetsModule',[]);
class PlanetsController {
    planets:Array<Planet> = [];
    constructor() {
        this.planets = [
        {name: 'Mercure', isRocky: true},
        {name: 'Venus', isRocky: true},
        {name: 'Terre', isRocky: true},
        {name: 'Mars', isRocky: true},
        {name: 'Jupiter', isRocky: false},
        {name: 'Saturne', isRocky: false},
        {name: 'Uranus', isRocky: false},
        {name: 'Neptune', isRocky: false}
        ];
    }
}
planetsModule.controller('PlanetsController',PlanetsController);

et son utilisation dans une page html :

<div ng-app="planetsModule">
      <section ng-controller="PlanetsController as planetsController">
        <ul>
         <li ng-repeat="planet in planetsController.planets">{{planet.name}}</li>
        </ul>
      </section>
</div>

On constatera ici 2 choses importantes :

  •  le controller est maintenant, explicitement, une classe et peut donc facilement ĂŞtre Ă©tendu et testĂ©. On remarquera que l’on n’utilise pas de $scope pour exposer les donnĂ©es.
  •  les donnĂ©es sont exposĂ©es via la syntaxe "controller as", nouvelle en angular 1.2 . Cette syntaxe permet de manipuler rĂ©ellement une instance de la classe controller plutĂ´t que le scope qui lui est passĂ© en paramètre.
Getter

Nous voulons maintenant filtrer les planètes par leur nom en tapant dans un champ texte. Dans la vraie vie, nous utiliserions un filter angular, mais ici nous allons faire le filtre dans le controller, pour la démonstration.

TypeScript nous permet d’utiliser une syntaxe simplifiĂ©e sous forme de getter :

class PlanetsController {

    filter:string = null;
    planets:Array<Planet> = [];

    constructor() {
        this.planets = [
        {name: 'Mercure', isRocky: true},
        {name: 'Venus', isRocky: true},
        {name: 'Terre', isRocky: true},
        {name: 'Mars', isRocky: true},
        {name: 'Jupiter', isRocky: false},
        {name: 'Saturne', isRocky: false},
        {name: 'Uranus', isRocky: false},
        {name: 'Neptune', isRocky: false}
        ];
    }

    get planetsFiltered() {
        if (this.filter) {
            return this.planets.filter((planet) => planet.name.indexOf(this.filter) >= 0)
        }
        return this.planets;
    }
}

Et le template :

 <section ng-controller="PlanetsController as planetsController">
        <input ng-model="planetsController.filter" />
        <ul>
             <li ng-repeat="planet in planetsController.planetsFiltered">{{planet.name}}</li>
        </ul>
</section>

On gagne en lisibilitĂ©, et il n’y a toujours pas besoin d’utiliser de scope.

Utilisation d’un service

Supposons maintenant que nos donnĂ©es proviennent d’un service. De la mĂŞme façon que pour les controllers, on peut utiliser une classe :

class PlanetsService {
    private planets:Array<Planet> = [
        {name: 'mercure', isRocky: true},
        {name: 'venus', isRocky: true},
        {name: 'terre', isRocky: true},
        {name: 'mars', isRocky: true},
        {name: 'jupiter', isRocky: false},
        {name: 'saturne', isRocky: false},
        {name: 'uranus', isRocky: false},
        {name: 'neptune', isRocky: false}
    ];

    findPlanets():Array<Planet> {
        return this.planets;
    }
}
planetsModule.service('PlanetsService', PlanetsService);

Pour injecter ce service dans le controller, il suffit d’utiliser la variable statique $inject :

class PlanetsController {

    filter:string = null;

    static $inject = ['PlanetsService'];
    constructor(public planetsService) {
    }

    get planetsFiltered() {
        var planets = this.planetsService.findPlanets();
        if (this.filter) {
            return planets.filter((planet) => planet.name.indexOf(this.filter) >= 0)
        }
        return planets;
    }
}

L’injection de dĂ©pendance peut se faire de la mĂŞme façon dans le service, en utilisant la variable statique $inject.

Les tests

Maintenant que les services et les controllers sont des classes, il devient beaucoup plus simple de les tester unitairement, car on peut presque se passer de référence à Angular.

On pourra par exemple conserver l’utilisation du couple Karma/Jasmine proposĂ© par la documentation d’Angular, auquel on ajoutera uniquement le prĂ©processeur TypeScript.

Les tests deviennent alors :

 

/// <reference path="../definition/jasmine/jasmine.d.ts" />
/// <reference path="../../main/typescript/PlanetsModule.ts" />
describe('PlanetsModule', function () {
    
    describe('PlanetsService', function () {
        var service:PlanetsService;
        
        beforeEach(() => service = new PlanetsService());
        describe('findPlanets', function() {
          it('should give the planet list', function () {
            var findPlanets = service.findPlanets();
            expect(findPlanets.length).toBe(8)
          });
        });
    });

    describe('PlanetsController', function () {
        describe('planetsFiltered', function() {
          it('should give the planet list if no filter', function () {
            var mockPlanet = {name: 'mock'};
            var service = {findPlanets: () => [
                mockPlanet
            ]};
            var controller:PlanetsController = new PlanetsController(service);
            controller.filter = null;
            var planets = controller.planetsFiltered;
            expect(planets).toEqual([mockPlanet])
          });

          it('should give the planet list filtered if filter', function () {
            var mockPlanet = {name: 'mock'};
            var anotherMockPlanet = {name: 'anotherMock'};
            var service = {findPlanets: () => [
                mockPlanet,
                anotherMockPlanet
            ]};
            var controller:PlanetsController = new PlanetsController(service);
            controller.filter = 'ano';
            var planets = controller.planetsFiltered;
            expect(planets).toEqual([anotherMockPlanet])
          });
        });
     });
});

Le défaut de cette approche dans les tests reste la lenteur de compilation. Sur les tests ci-dessus, il faut entre 2 et 3 secondes pour que le code compile et s’exécute.

Les directives

La syntaxe des directives ne peut malheureusement pas facilement ĂŞtre passĂ©e sous forme de classe ; en effet le seul constructeur de directive disponible prend une factory en paramètre. Cependant, il est possible de typer fortement le scope, ce qui reste un avantage dans l’Ă©criture d’une directive.

Nous allons créer une directive permettant de colorer en bleu les planètes telluriques, et en rouge les autres

interface PlanetColorScope extends ng.IScope {
    planet:Planet
}

var planetColorDirectiveFactory = function ():ng.IDirective {
    return {
        restrict: 'A',
        scope: {
            planet: '=planetColor'
        },
        link: function (scope:PlanetColorScope, element:ng.IAugmentedJQuery) {
            var color = scope.planet.isRocky ? 'blue' : 'red';
            element.css('color', color);
        }
    }
};

planetsModule.directive('planetColor', planetColorDirectiveFactory);

et son utilisation :

<ul>
    <li ng-repeat="planet in planetsController.planetsFiltered" planet-color="planet">{{planet.name}}</li>
</ul>
Conclusion

On constate d’une manière gĂ©nĂ©rale un grand gain en lisibilitĂ© lorsque l’on utilise le couple TypeScript et Angular, que ce soit par l’utilisation de classe ou par le typage. De plus la migration de JavaScript vers TypeScript peut se faire en douceur car les syntaxes sont très proches. Le seul gros dĂ©faut reste encore le temps de compilation, qui peut facilement atteindre quelques secondes.

Pour aller plus loin, on peut envisager de ne plus utiliser Angular que comme tuyauterie entre les classes et d’utiliser le système de module de TypeScript. Les possibilitĂ©s sont nombreuses, mais l’objectif de donner plus de structure et de lisibilitĂ© Ă  de grosses applications Angular est atteint.

Si vous souhaitez découvrir plus avant TypeScript, vous pouvez vous inscrire au TechEvents du 17 Mars.

Catégories: Blog Société

Client, designer, développeur: un workflow qui fonctionne

L'actualité de Synbioz - mer, 03/12/2014 - 00:00

Arrivé depuis maintenant plus d’un an chez Synbioz, j’ai eu l’occasion de travailler sur plusieurs projets avec plusieurs développeurs.

En tant que webdesigner et intégrateur j’ai la possibilité de gérer un projet de la charte graphique jusqu’aux développements JavaScript des interactions utilisateur.

Développeur back et intégrateur sont totalement complémentaires et pourtant, parmi les conversations partagées avec ces deux acteurs du web je remarque que travailler efficacement ensemble n’est pas si simple.

Lire la suite...

Catégories: Blog Société

Coding Dojo Ă©quipe @pcery

Blog d’Ippon Technologies - mar, 03/11/2014 - 15:00

Ce Mardi 4 Mars 2014 avait lieu le Coding Dojo de mon équipe. Voici un petit résumé.

Déroulement de la journée

L’objectif principal de cette journĂ©e Ă©tait de dĂ©couvrir AngularJS. Autour des maĂ®tres de cĂ©rĂ©monies, Alvin et Alexis, j’avais avec moi douze participants hyper motivĂ©s.

Coding Dojo @pcery

Après un petit-déjeuner copieux, Alvin nous a expliqué les règles du jeu :

  • travail en binĂ´me
  • 3 sprints d’une heure pour enrichir une application existante
  • après chaque sprint, dĂ©mo et rĂ©tro
  • les binĂ´mes changent Ă  chaque sprint

Nous sommes ensuite entrĂ©s dans le vif du sujet avec une prĂ©sentation rapide de la plateforme comprenant, en plus d’AngularJS, NodeJS cĂ´tĂ© serveur, MongoDB pour la base de donnĂ©es et la stack Yeoman au complet (Yo, Grunt et Bower).

Le temps d’installer les modules manquants sur les VM et nous Ă©tions prĂŞts Ă  dĂ©marrer…

Sprint 1 : Premiers pas

Pour le premier sprint, Alvin nous avait prĂ©parĂ© des stories de newbies : afficher sur diffĂ©rents Ă©crans des donnĂ©es dĂ©jĂ  prĂ©sentes dans la base de donnĂ©es (email, Twitter…). Très efficace pour dĂ©couvrir la plateforme…

Deux binĂ´mes ont eu des stories basĂ©es sur une donnĂ©e qui n’existait pas encore dans le modèle. Pas de panique, une petite manipulation cĂ´tĂ© serveur (pour rappel, NodeJS) et la donnĂ©e Ă©tait ajoutĂ©e. Magique !

Après cette entrĂ©e en matière très instructive, on avait hâte d’en savoir plus. Mais on avait aussi très faim donc pause dĂ©jeuner.

Sprint 2 : Directive et Responsive Design

Après quelques sushis, makis et brochettes, on est reparti pour en savoir plus sur AngularJS.

Dans le premier sprint, chaque binôme avait laissé place à son imagination pour implémenter sa story. Et bien sûr, pour la plupart, on a fait du spécifique pour ne pas dire de la bidouille. Il était temps de découvrir les directives et le responsive design.

Une directive est une fonction rĂ©utilisable sous la forme de balise ou d’attribut personnalisĂ©.

Le responsive design consiste Ă  adapter l’affichage en fonction de la taille de l’Ă©cran utilisĂ© Ă  l’aide de classe CSS prĂ©dĂ©finie (dans ce cas) par Bootstrap.

Sprint 3 : Pré-processeurs et Packaging

Pour ce dernier sprint, certains sont allés plus loin dans l’utilisation des directives AngularJS. Ils ont ainsi pu créer des directives qui s’appellent en cascade.

D’autres ont pu faire des expérimentations avec SASS et Compass, des outils de préprocessing CSS. Ils ont pu factoriser des CSS en créant des mixins.

Enfin, deux binômes ont étendu la chaîne de build Grunt en rajoutant et en configurant un plugin de packaging pour Grunt.

Conclusion

Il est bien Ă©videmment impossible de tout voir en si peu de temps.

NĂ©anmoins, cette journĂ©e dĂ©couverte a permis Ă  certains d’entre nous qui sommes plutĂ´t back-office de jouer un peu avec un framework front-office. Et tout cela dans la bonne humeur !  :-D

Le mot d’Alexis Seigneurin

J’ai rejoint Ippon en dĂ©but d’annĂ©e en tant que Manager Technique en charge de la capitalisation de connaissances. Une de mes missions consiste Ă  prĂ©parer, organiser et (co-)animer les Coding Dojos.

Ces journĂ©es sont un très bon moyen d’expĂ©rimenter sur des technologies qui ne sont pas forcĂ©ment celles que chacun utilise au quotidien. Et, outre la dĂ©couverte technique pure, ces journĂ©es permettent de partager des bonnes pratiques et des mĂ©thodes de travail.

Mon objectif est d’accĂ©lĂ©rer le rythme des Coding Dojo : Ă  l’horizon 2015, 4 sessions seront proposĂ©es Ă  chaque consultant, et donc 4 rendez-vous incontournables pour les Ă©quipes !

Catégories: Blog Société

Xebia accueille la 43ème soirée du Paris Scala User Group

Le prochain meeting du Paris Scala User Group sera le mardi 25 mars chez Xebia Ă  19h30.

Les inscriptions se passent ici : http://psug-43.eventbrite.fr/

Mourad DACHRAOUI nous prĂ©sentera son retour d’expĂ©rience sur Spray / RxScala / ElasticSearch, dans le cadre d’une application e-commerce. Apres une description succincte des diffĂ©rents modules qui composent Spray, nous percerons avec lui les secrets du DSL de routage sur lequel repose le module spray-routing, grâce Ă  la dĂ©mystification de l’astucieux Magnet pattern. Il nous dĂ©crira Ă©galement la mise en oeuvre de RxScala dans la parallĂ©lisation des requĂŞtes ElasticSearch.

Jetbrains – http://www.jetbrains.com/ – sponsorise l’Ă©vènement en offrant 1 Ă  2 licenses (en fonction de l’affluence). 
Si nous sommes plus de 25, nous procéderons à un tirage au sort en live ;)

Niveau requis : débutant

Xebia
156 boulevard Haussmann Ă  Paris
Immeuble A – Rez-de-ChaussĂ©e

Catégories: Blog Société

Petit-déjeuner à Genève : « Les Business Analysts face à l’agilité : de nouveaux challenges à relever »

Petit-déjeuner gratuit mercredi 9 avril

Le business analyst (BA) joue un rôle crucial dans nos organisations. Lien essentiel entre les opérationnels et l’informatique, il identifie, analyse, valide et documente les besoins métiers et participe à la mise en place de solutions.

Dans un projet traditionnel (en cascade), son activité gravite naturellement autour de la rédaction des spécifications fonctionnelles, réalisées typiquement en amont des développements.

Dans un contexte plus agile par contre, dans lequel les besoins peuvent être raffinés, repriorisés, réévalués, redéfinis continuellement et dans lequel la notion même de spécification telle qu’on la connaît est remise en cause, comment continuer à valoriser les compétences du BA ?

En abordant ces questions, c’est également le rôle des spécifications, de leur place au sein d’un projet agile et de leur lien étroit avec les tests que l’on clarifiera dans ce petit-déjeuner.

On abordera en particulier :

  • ses nouvelles relations avec le Product Owner, l’équipe QA, l’équipe de dĂ©veloppement agile et le reste de l’organisation;
  • son implication dans l’écriture de spĂ©cifications sous la forme d’exemples et de tests d’acceptance (ATDD);
  • quelques nouveaux outils pour aider le BA Ă  dĂ©finir le produit de manière plus itĂ©rative et incrĂ©mentale;

Ces principes seront illustrés sur la base d’un cas et d’outils concrets.
Avec l’avènement de l’agilité, le Business Analyst doit se renouveler. Venez découvrir les pistes qui lui permettront de travailler de manière plus agile.

 

 Cliquez ici pour vous inscrire à ce petit-déjeuner

Suggestion d'articles :

  1. Petit-dĂ©jeuner AgilitĂ© Ă  Genève : un voyage vers l’entreprise Agile!
  2. Petit-déjeuner BYOD à Genève : toutes les clés pour démarrer ou remettre votre projet sur de bons rails
  3. Petit-dĂ©jeuner « AgilitĂ© et ERP » avec le tĂ©moignage de Danone, le 22 mars

Catégories: Blog Société

[Techdays 2014] La validation UX du Store

[Techdays 2014] La validation UX du Store
Ceci est un retour de session sur la confĂ©rence “La validation UX du Store : Tout ce que vous avez toujours voulu savoir sans jamais oser le demander“. Cette session a Ă©tĂ© animĂ©e par Michel Rousseau, consultant design et UX...
Catégories: Blog Société

Perfug : Une architecture orientée Performances en mode SAAS : Prismic.io

Prismic.io est une plate-forme de gestion de contenu basée sur une architecture totalement moderne :

• d’un cotĂ© sa « Writing Room » permettant de saisir du contenu semi-structurĂ© avec une expĂ©rience utilisateur heureuse.

• de l’autre son API pour extraire le contenu et l’afficher dans diffĂ©rent contextes, tel que des sites Web ou des applications mobiles.

La mise en place d’une telle solution en mode SAAS demande une architecture parfaitement adaptĂ©e en terme de montĂ©e en charge et de disponibilitĂ©. En effet, en quelques mois, notre plate-forme a du pouvoir rapidement hĂ©berger plusieurs milliers de « repository » de contenu et notre API se doit d’ĂŞtre disponible en permanence.

Dans cette prĂ©sentation nous vous dĂ©taillerons les diffĂ©rents enjeux et problèmes posĂ©s par ces architectures de logiciels SAAS, ainsi que les patterns d’architectures et solutions techniques que nous avons mis en place pour y rĂ©pondre.

Les speakers de cette session sont Guillaume Bort et Sadek Drobi, fondateurs de Prismic.io et du framework Play!.

Pour le descriptif complet de la séance, suivez le lien.

L’Ă©vĂ©nement aura lieu le Jeudi 20 Mars Ă  19h. Pour s’inscrire, c’est sur Eventbrite.

Suggestion d'articles :

  1. PerfUG: Trouvez les problématiques de performances avec JProfiler
  2. Perfug : La programmation réactive : quel gain sur les performances ?
  3. OCTO accueille le PerfUG pour une discussion et un laboratoire sur les performances systèmes

Catégories: Blog Société

Premiers pas avec Atom.io, l’éditeur de texte de Github. Xebia vous réserve une surprise.

Atom.io est un éditeur de texte développé par Github qui a beaucoup fait parler de lui ces derniers jours. Nous vous proposons de faire un premier tour du propriétaire pour comprendre les raisons de cet engouement.

Si vous avez envie de le tester vous aussi, Xebia vous a mis de cotĂ© quelques invitations à la beta privĂ©e : les informations pratiques en bas de l’article.

Pour quel public ?

Ă€ l’opposĂ© d’un IntelliJ ou encore d’un Eclipse, l’approche d’Atom.io est semblable Ă  des Ă©diteurs de texte comme Sublime Text ou TextMate. On retrouve les mĂŞmes ingrĂ©dients :

  • un dĂ©marrage en fanfare avec un Ă©norme buzz sur la toile
  • une version payante au dĂ©marrage
  • du code closed source

Pour l’instant en beta privĂ©e, seule la version Mac est disponible en tĂ©lĂ©chargement pour les heureux Ă©lus. Si ces premiers Ă©lĂ©ments ne vous ont pas fait fuir, vous ĂŞtes donc sĂ»rement dans la cible.

C’est en regardant la stack technique utilisĂ©e qu’on devine pour quel type de projet Atom sera le plus adaptĂ©. Sous le capot d’Atom on trouve :

  • un Ă©diteur codĂ© en CoffeeScript facile Ă  inspecter via une console identique Ă  celle qu’on trouve dans Chrome
  • une intĂ©gration native de node.js
  • des composants graphiques qui s’appuient sur le prĂ©processeur CSS LESS avec la possibilitĂ© de voir le rĂ©sultat des modifications via un live reload intĂ©grĂ©
  • et bien sĂ»r un système de packages disponibles en open source sur github

On comprend vite qu’il s’agit plus d’attirer les dĂ©veloppeurs Front-End ou Fullstack que les dĂ©veloppeurs Scala.

Quelles killer features ?

La principale fonctionnalitĂ© d’Atom devrait ĂŞtre l’intĂ©gration poussĂ©e avec des repository git. Pour l’instant cette version beta ne propose que des fonctionnalitĂ©s annexes : on peut voir quelle est la branche courante de travail, les fichiers modifiĂ©s changent de couleur, on peut naviguer facilement de "diff" en "diff". On imagine que les Ă©quipes de github se laissent un peu de temps pour peaufiner les fonctionnalitĂ©s de commit/merge.

En attendant on peut se contenter de quelques nouveautĂ©s qui amĂ©liorent le workflow quotidien du dĂ©veloppeur : une "Command Palette" pour accĂ©der rapidement Ă  toutes les fonctionnalitĂ©s de l’Ă©diteur (très similaire Ă  celle de Sublime Text), une navigation au clavier, le support de nombreux langages par dĂ©faut (dont CoffeeScript bien sĂ»r), la preview temps rĂ©el des fichiers markdown et enfin une GUI pour Ă©diter sa configuration.

Dans la mĂŞme philosophie qu’Emacs, Atom mise beaucoup sur la communautĂ© pour crĂ©er des packages pouvant rĂ©pondre Ă  tous les besoins. Pour le dĂ©veloppeur Front-End, la premier rĂ©flexe sera de chercher des packages pour angular et reproduire ce qu’on fait de mieux aujourd’hui. Comme rĂ©fĂ©rence on peut garder en tĂŞte l’excellente intĂ©gration d’Angular dans WebStorm :

alt text

Source: Because WebStorm

En cherchant rapidement dans la biliothèque de packages, on trouve effectivement un package atom-angularjs :

Les fonctionnalitĂ©s de complĂ©tion sont pour l’instant assez rudimentaires, mais on imagine que de nouvelles versions du package devraient arriver rapidement.

Découvrir Atom en créant un package

Rien de tel, pour dĂ©couvrir un Ă©diteur, que d’Ă©crire un plugin pour celui-ci. La documentation de crĂ©ation d’un package, encore sommaire, est suffisante pour dĂ©marrer. Pour faciliter l’apprentissage, un premier tutorial très simple est disponible.

Github a tout fait pour que les développeurs Front-End ne soient pas perdus :

  • on retrouve un fichier package.json avec les dĂ©pendances Ă  la racine du projet
  • un support natif des tests au format jasmine : un exemple
  • un styleguide pour retrouver facilement les variables LESS Ă  utiliser :

Conclusion

Cette version beta d’Atom.io semble ĂŞtre le dĂ©but d’un produit très intĂ©ressant qu’il faudra surveiller avec attention. Pour ceux qui souhaiteraient recevoir une invitation et tester l’application, les xebians vous ont rĂ©servĂ© quelques dizaines d’invitations : pour en recevoir une, postez un commentaire sur ce billet avec un mail valide (qui ne sera pas publiĂ©). Attention, les premiers arrivĂ©s seront les premiers servis.

N’hĂ©sitez pas Ă  partager vos premières impressions.

Catégories: Blog Société

3 jours Ă  QCon London 2014

QCon London 2014 a rassemblĂ© la semaine passĂ©e plusieurs centaines de participants et plus de 100 speakers pour 3 jours de confĂ©rences. Nous n’Ă©tions que 3 pour 5 tracks en parallèle, impossible de tout suivre, mais voici ce que nous avons retenu.

HTML5 et Mobile : l’heure des frameworks

Lors de sa keynote, « Does the browser has a future? », le premier jour, Tim Bray nous a dressĂ© un avenir en demi-teinte. En 1997 dĂ©jĂ , Wired magazine titrait sur la mort du navigateur, et pourtant aujourd’hui, il est toujours lĂ  et plĂ©biscitĂ© par les utilisateurs.
Les navigateurs apportent de très bonnes choses (HTML, HTTP) mais aussi de très mauvaises (CSS, JavaScript et le modèle du DOM). Aujourd’hui le modèle DOM et JavaScript fonctionnent cĂ´tĂ© navigateur, car il y a peu de choses Ă  contrĂ´ler. Mais le nombre de devices mobiles explose avec toujours plus de capteurs, et demain un avenir avec rĂ©alitĂ© augmentĂ©e. Par exemple avec le Project Tango, Google veut donner au mobile une sensibilitĂ© de capteur permettant de donner aux applications la mĂŞme sensation d’espace et de mouvement que l’ĂŞtre humain. Étonnamment, les jeux mobiles multiplateformes sont aujourd’hui Ă©crits en C++ et non en HTML5. Alors pas d’avenir pour le navigateur ? Il faut rester modeste, des technologies comme PHP ont permis de rĂ©aliser des outils fantastiques comme Wikipedia et Facebook. Je retiendrai que pour l’instant, de nombreux frameworks viennent contrebalancer les manques du navigateur.

TimBrayBrowser
Et de nombreuses sessions sont venues en donner des exemples. Tout d’abord Andrew Bietts au Financial Times’ nous a prĂ©sentĂ© Origami, un framework de composants web dĂ©veloppĂ© afin de permettre au Financial Times de gĂ©rer 6 noms de domaines diffĂ©rents avec une certaine cohĂ©rence et rĂ©utilisation. Demain les composants Web seront normalisĂ©s par le W3C, pour l’instant Andrew nous prĂ©sente sa solution. BasĂ©es sur une simple norme, les diffĂ©rents composants sont rĂ©fĂ©rencĂ©s dans un rĂ©fĂ©rentiel qui permet d’y accĂ©der via une simple URL. De la belle architecture avec de la gestion de dĂ©pendance de CSS, de la rĂ©utilisation.

REST et Micro-services

Les architectures REST sont Ă©galement bien implantĂ©es et ont fait l’objet de retours d’expĂ©rience. Brandon Byars de chez ThoughWorks nous a prĂ©sentĂ© une rĂ©Ă©criture d’un système TĂ©lĂ©com dans une architecture REST. Celle-ci est très efficace pour gĂ©rer la complexitĂ© en la divisant en nombreux contextes spĂ©cialisĂ©s et isolĂ©s. Mais l’intĂ©gration reste en REST comme avec d’autres architectures une source de complexitĂ©. La première des règles est de retarder autant que possible l’existence de versions incompatibles. De plus il est important de sĂ©parer les tests fonctionnels des tests d’intĂ©gration – qui doivent donc ĂŞtre des tests Ă  part entière. Enfin, il faut fournir au dĂ©veloppeur des environnements qu’il maĂ®trise et des bouchons pour l’ensemble du système afin qu’il puisse systĂ©matiquement tester sans avoir l’intĂ©gralitĂ© du système sur son poste. Dernière recommandation, la loi de Postel encourage Ă  Ă©crire des services tolĂ©rants aux Ă©carts par rapport au contrat. Cela est tout Ă  fait dans la philosophie de REST Ă  condition de paramĂ©trer certains frameworks qui fonctionnent avec une philosophie code first.

Devops et Agile

Parvenir Ă  un système de dĂ©ploiement continu qui permet de faire plusieurs dizaines de dĂ©ploiements dans la mĂŞme journĂ©e sans douleur est aujourd’hui un des objectifs majeurs de Devops. DiffĂ©rents acteurs y sont parvenus, avec diffĂ©rentes mĂ©thodes.

Tout d’abord, ce qui tourne sur le poste du dĂ©veloppeur doit ĂŞtre exactement la mĂŞme chose que ce qui va tourner en production. Groupon atteint cet objectif en dĂ©coupant son application en une multitude de petites applications nodejs (une quinzaine de fichiers maximum) qui peuvent ĂŞtre lancĂ©es en isolation, et donc tourner en local dans leur intĂ©gralitĂ©. Etsy, de son cĂ´tĂ©, fournit Ă  ses employĂ©s des VM packagĂ©es avec les recettes Chef qui vont bien pour que chacun puisse lancer une copie conforme de l’intĂ©gralitĂ© de l’application de production directement en local. Ainsi, pas de surprise, et plus d’excuse de « Chez moi ça marche, maintenant c’est le problème des Ops ».

La seconde est prĂ©sentĂ©e par Dave Farley qui a mis en oeuvre le continous delivery chez LMAX : une start-up qui fournit des services d’Ă©changes Ă  faible latence dans les services financiers. Sa mĂ©thode repose sur l’automatisation de quasiment tout pour Ă©viter toute manipulation humaine, l’utilisation systĂ©matique du contrĂ´le de source de façon Ă  pouvoir reconstruire complètement un datacenter et l’accĂ©lĂ©ration des cycles de livraison. « If it hurts, do it more often – bring the pain forward ». Cette approche est nĂ©cessairement couplĂ©e Ă  une approche de qualitĂ© avec une batterie de tests, automatisĂ©s pour la rĂ©pĂ©tition et manuel pour utiliser la crĂ©ativitĂ© des testeurs. Au final : 45 minutes seulement pour dĂ©ployer en cas d’urgence. Aller vers le dĂ©ploiement continu c’est mettre rĂ©ellement en oeuvre l’un des principes de l’agile et cela fait changer de façon de travailler.

Tous ces acteurs ont aussi mis au point des outils internes qui leur permettent de simplifier leurs dĂ©ploiements. Chez Etsy par exemple, chacun peut dĂ©ployer en un clic grâce Ă  un outil qui se charge de lancer les tests (en parallèle sur un pool d’environ 400 instances Jenkins tournant dans des containers Docker sur disque SSD), et de synchroniser la nouvelle application sur tous leurs serveurs. Un dĂ©ploiement complet prend en moyenne 15 minutes chez eux.

L’obsession de la mesure se retrouvait aussi chez tous ces acteurs qui possèdent des pages entières de dashboard pour monitorer tout ce qu’il se passe, depuis la RAM, le CPU au nombre de login, logout, erreurs 404, etc. Ainsi, dès qu’une courbe semble sortir de l’ordinaire, on peut rapidement la lier au dĂ©ploiement qui a dĂ» la causer. Le point important sur lequel plusieurs speakers ont insistĂ© Ă©tait que ces dashboards doivent ĂŞtre accessibles par absolument tout le monde dans l’organisation. Dès que quelqu’un dĂ©veloppe une feature, il doit avoir accès aux mĂ©triques qui y correspondent en production, car il sera le plus Ă  mĂŞme de comprendre les implications.

Tolérance aux pannes

Lorsqu’il s’agit de concevoir des systèmes tolĂ©rants, rien n’est jamais Ă©vident. Joe Armstrong, un des pères d’Erlang – un langage rĂ©silient par nature – nous dĂ©montre ainsi que la scalabilitĂ© d’un système est fortement corrĂ©lĂ©e Ă  sa tolĂ©rance Ă  la panne. Difficiles (voir parfois impossibles) Ă  prĂ©dire, ces pannes peuvent venir de n’importe quel composant logiciel ou matĂ©riel et ce Ă  n’importe quel moment. Le système dit rĂ©silient doit alors dĂ©tecter, corriger et stopper la propagation de cette panne de manière automatique. Plusieurs choix s’offrent Ă  nous : masquer la panne, rĂ©essayer ou « let it crash ». Joe nous met Ă©galement en garde contre l’illusion du code dĂ©fensif, faisant peut-ĂŞtre du sens dans des languages basĂ©s sur une stack (programmation sĂ©quentielle), mais pas forcĂ©ment nĂ©cessaire sur des langages Acteur par exemple, ou les autres acteurs seront forcĂ©ment notifier en cas de crash d’un des leurs.

Uwe Friedrichsen nous rappelle que la prioritĂ© majeure en production est de garantir la disponibilitĂ© de ses applications (sinon pas de business). Il nous prĂ©sente ainsi quelques patterns simples et faciles Ă  mettre en oeuvre pour concevoir des programmes tolĂ©rants aux pannes : « circuit breaker », « fail fast », « shed load » ou encore « deferrable work » (pour en apprendre d’autres, lisez Distributed systems: Principles and Paradigms de Andrew S. Tanenbaum). Il faut Ă©galement investir dans la supervision, faire en sorte de pouvoir modifier Ă  chaud ces gardes-fous ce qui permet de diminuer les temps de rĂ©action en cas de problème sur un système (on peut aller jusqu’Ă  automatiser du failover). Pour gĂ©rer la rĂ©silience, mieux vaut rĂ©viser ses fondamentaux. Andy Piper nous montrait ainsi que tout algorithme de communication fiable, sur un rĂ©seau par dĂ©finition non fiable, est une affaire de compromis. Michael T. Nygard a bien illustrĂ© ce propos Ă  travers de nombreuses Ă©chappatoires possibles au thĂ©orème de CAP. Non que celui-ci soit faux, mais que rare sont les cas d’utilisations oĂą la dĂ©finition exacte de la cohĂ©rence et de la disponibilitĂ© du thĂ©orème sont nĂ©cessaires. Ainsi le système spanner en production chez Google ne respecte pas la cohĂ©rence de l’historique des modifications sur chaque noeud, mais fournit un timestamp par horloge GPS a chaque modification pour pouvoir les ordonner. La maĂ®trise intime des dĂ©finitions est donc indispensable pour choisir la meilleure rĂ©silience possible pour un système. Big Data & NoSQL Comme chacun sait, NoSQL est un Ă©cosystème très vivant : tous les produits du marchĂ©, et notamment les solutions Open Source, introduisent Ă  chaque release de nouvelles features, permettant d’optimiser l’existant et de rĂ©soudre de nouveaux problèmes. * La version 2.0 de Cassandra a apportĂ© son lot de nouveautĂ©s, et notamment le native protocol. Johnny Miller (Datastax) nous prĂ©sente les nouveautĂ©s du Driver Java natif, et notamment la possibilitĂ© de dĂ©finir des stratĂ©gies sur retry d’une requĂŞte, la reconnection ou encore le routage vers des coordinateurs possĂ©dant les donnĂ©es. * Joel Jacobson (Basho) nous explique tous les bienfaits apportĂ©s par les CRDTs (Convergent/Communtative Replicated Data Types, basĂ© sur des travaux de l’INRIA) introduits dans la version 2.0 de Riak (release courant mars) : Counters, Set, Map, Registers and Flags. Plus gĂ©nĂ©ralement, de nombreux talks ont remis les points sur les i en ce qui concerne Big Data et ses enjeux : * Mark Harwood (elasticsearch) nous rappelle que l’utilisation de donnĂ©es massives nĂ©cessite forcĂ©ment une phase d’exploration pour en tirer le meilleur. Au travers de diffĂ©rents use case (analyse des crimes et dĂ©lits Ă  Londres, d’une BDD de films ou encore de l’analyse de fraude bancaire), Mark montre Ă  quel point elasticsearch est pertinent pour explorer ces donnĂ©es, notamment grâce aux agrĂ©gations(introduits dans la v1.0) telle que significant_terms qui permet de mettre en Ă©vidence les termes les plus significatifs et non pas les plus frĂ©quents comme on avait l’habitude de voir jusqu’Ă  prĂ©sent. * Akmal B. Chaudhri (Hortonworks) prĂ©sente comment Hadoop 2 rĂ©pond toujours mieux aux 3V’s (Variety, Volume et Velocity), notamment grâce Ă  l’arrivĂ©e de YARN comme couche de partage et mĂ©diation des ressources du cluster. De nombreux frameworks, tels que Pig, Hive (Stinger) ou Tez, vont directement en bĂ©nĂ©ficier. Qui plus est, une gateway (Knox) fait son apparition pour isoler un cluster Hadoop et sĂ©curiser les accès. * Nathan Marz (Twitter) nous explique de manière Ă©lĂ©gante les architectures lambda, fondĂ©es sur l’immutabilitĂ© et oĂą chaque requĂŞte peut ĂŞtre considĂ©rĂ©e comme une fonction sur la totalitĂ© des donnĂ©es (historique + temps rĂ©el). Ce type d’architecture sur deux couches : « batch » pour le stockage de l’historique et la construction de precomputed views; « speed » pour l’ingestion des donnĂ©es temps rĂ©elles et la construction d’incremental views. (son livre est en EAP). Cloud next generation

Docker Ă©tait la principale nouveautĂ© technologique cette annĂ©e dans le monde du cloud et Chris Swan en a fait une prĂ©sentation sans surprise. Derek Collison a Ă©tĂ© plus visionnaire en considĂ©rant qu’aujourd’hui les systèmes de cloud computing manquent d’une vision intĂ©grĂ©e pour le monitoring, la supervision. L’avenir verra probablement Ă©merger l’Ă©quivalent de systèmes d’exploitation pour le cloud. Serait-ce l’avenir du cloud privĂ© ? Netflix enfin a longuement dĂ©taillĂ© les diffĂ©rents outils qu’ils mettent en oeuvre pour opĂ©rer l’intĂ©gralitĂ© de leur système sur Amazon Web Services : des outils de monitoring, de dĂ©ploiement, utilisables par tous les dĂ©veloppeurs. Cette session Ă  mi-chemin entre la rĂ©silience, le cloud et devops montre bien leur philosophie radicalement diffĂ©rente de nos habitudes. Netflix prĂ©fère en effet rĂ©agir aux erreurs du système, dĂ©clencher des erreurs en production volontairement pour ĂŞtre mieux capable d’y rĂ©agir plutĂ´t qu’investir en amont. Ă€ leur niveau de charge les erreurs sont quasi certaines. Ils dĂ©ploient donc des outils comme chaos monkey pour dĂ©brancher volontairement des serveurs en production entre 9h. et 18h. Tout le monde est lĂ  pour corriger et apprendre ce qui rend plus fort pour rĂ©agir lorsqu’un problème survient en plein milieu de la nuit.

Java et programmation réactive

Ă€ deux semaines du lancement de Java 8 Simons Ritter est venu nous prĂ©senter comment les lambdas sont intĂ©grĂ©s dans le framework. Une modification pas si minime du langage, un bon en avant dans le domaine fonctionnel et rĂ©actif. Sur ce point Node.JS Ă©tait omniprĂ©sent dans les sessions technologiques mais j’aurais aimĂ© plus de retour d’expĂ©rience. Aujourd’hui cependant Node.JS est une rĂ©fĂ©rence. Le nouveau moteur JavaScript Nashorn sur la JVM proposera une couche de compatiblitĂ© qui le rendra compatible avec 95% des applications Node.JS (manqueront les API natives de chrome V8). Oracle a voulu aller plus loin avec le projet Avatar qui fournit une vĂ©ritable API JS au dessus de JEE et une API client. J’avoue restĂ© sceptique hors du besoin d’intĂ©gration. D’autres solutions sont explorĂ©es, par exemple Vert.x avec son modèle Ă  mi-chemin entre node.js et des acteurs. Beaucoup de technologies qui permettent donc de changer de paradigme. Car il y a clairement un enjeu autour de travailler sur des flux, de travailler en asynchrone depuis le driver. Martin Thompson, CTO chez LMAX en convenant Ă©galement. Mais comment le faire concrètement? Un exemple de Rx pour concevoir un jeu vidĂ©o en rĂ©active c’est bien, mais assez Ă©loignĂ© de mes projets. Allard Buijze, crĂ©ateur de Axon framework tenait le mĂŞme discours, mais avec un exemple beaucoup plus appliquĂ© Ă  l’informatique de gestion. En effet, Axon fournit les mĂ©canismes de base pour implĂ©menter une architecture CQRS. Celle-ci permet Ă  la fois de dĂ©passer le dĂ©coupage en couche pour tirer profit d’une architecture rĂ©active tout en Ă©tant compatible avec les principes du Domain Driven Design pour gĂ©rer la complexitĂ©.
CQRS

Retour aux fondamentaux

De nombreux algorithmes permettent de rĂ©soudre les problèmes induits par les gros ensembles de donnĂ©es. Adrian Colyer (Pivotal) nous explique ainsi en quoi les Bloom Filters sont indispensables lorsqu’il s’agit de savoir si un Ă©lĂ©ment est prĂ©sent ou non dans un dataset volumineux ou encore en quoi HyperLogLog permet d’estimer le nombre d’Ă©lĂ©ments uniques dans ces mĂŞmes datasets. Pour les plus curieux, jetez un oeil à stream-lib.

Un dernier message : en informatique certains sujets sont très pointus et il faut ne jamais l’oublier. Les float avec les problèmes d’optimisations, les bibliothèques de chiffrement sans dĂ©faut, les libraries mathĂ©matiques oĂą la startup OpenGamma expliquait qu’ils prĂ©fĂ©raient intĂ©grer des librairies mathĂ©matiques reconnues en C plutĂ´t que de les porter en Java au coeur de leur plateforme. Lorsqu’on veut faire fonctionner avec prĂ©cision ces sujets, les anciennes recettes sont toujours les meilleures : des tests et le partage du savoir.

Que retenir? DevOps et Big Data sont dĂ©finitivement rentrĂ©s en production avec de nombreux retours d’expĂ©rience. Le Reactive Programming Ă©tait le sujet en vogue du moment, mais nous attendons encore les premiers retours d’expĂ©rience. HTML5 Ă©tait finalement au milieu de ces deux mondes, en progressant doucement vers une certaine maturitĂ©.

Suggestion d'articles :

  1. Trois jours Ă  QCon London 2010 : Tendances et Confirmations
  2. QCon London 2011: un peu de process, beaucoup d’architecture et de la performance pour passer Ă  l’Ă©chelle
  3. Deux jours Ă  Strata Conf London 2012

Catégories: Blog Société

Do You Speak Ippon ? Les métiers d’Ippon – Mathieu Bellange

Blog d’Ippon Technologies - lun, 03/10/2014 - 19:00

Vous rĂŞvez de nouveaux horizons… Vous cherchez une entreprise qui vit au rythme des innovations technologiques… Une sociĂ©tĂ© Ă  taille humaine qui connaĂ®t et Ă©coute ses consultants… Vous voulez savoir avec qui vous pourriez travailler et Ă©changer…

Chaque semaine, découvrez un ou plusieurs talents Ippon.

VidĂ©o 5 – Mathieu Bellange – Consultant chez Ippon

Alors, do you speak Ippon ?

Retrouvez toutes les vidéos métiers sur le blog avec le tag #doyouspeakippon

Catégories: Blog Société

L’iBeacon, la nouvelle tendance de communication de données d’Apple

Tout le monde en parle, Apple a prĂ©sentĂ© l’annĂ©e dernière sa nouvelle tendance de transmission/communication de donnĂ©es appelĂ©e « iBeacon ».

Qu’est ce que c’est ?

Une nouvelle technologie développée par Apple et conçue sur iOS,  l’iBeacon exploite les capacités du BLE (Bluetooth Low Energy).

Ce concept ouvre toute une dimension en crĂ©ant une « balise » reprĂ©sentant un petit Ă©metteur. Cet Ă©metteur placĂ© dans un espace physique permet d’envoyer des signaux sans fil Ă  faible puissance afin de localiser un utilisateur dans une zone prĂ©cise et de transmettre des donnĂ©es Ă  votre appareil mobile.

Après l’Ă©mission des signaux, un iBeacon donne la possibilitĂ© de :

  • Envoyer des notifications push, transmettre des informations, faire transiter un controller Ă  un autre, voire plus… lorsque l’application est en tâche de fond ou active et que le device entre dans la zone d’influence de la balise (pousser une offre promotionnelle disponible dans le rayon oĂą l’utilisateur se trouve, informer de l’ouverture prochaine d’un magasin dans la rue oĂą l’utilisateur passe, …).

ibeacon_example

Son Ă©nergie et sa distance de transmission font de l’iBeacon ses points forts. Grâce au BLE, cette technologie offre des fonctions proches du NFC avec une Ă©nergie moins gourmande et permet de transmettre des donnĂ©es à des distances de près de 10 mètres en pratique et 50 mètres en thĂ©orie.

NB : Attention, l’iBeacon n’est pas un protocole d’Ă©change de donnĂ©es mais uniquement une technologie permettant Ă  une balise de signaler sa prĂ©sence. A ne pas confondre avec le BLE qui propose des services en plus que l’iBeacon ne gère pas.

Que propose le marché aujourd’hui ?

Sur le marchĂ© actuel, plusieurs sociĂ©tĂ©s/startups dĂ©veloppent, proposent et commercialisent leurs propres balises. Voici une liste non exhaustive de balises que l’on pourrait trouver sur le marchĂ© :

La startup polonaise Estimote a Ă©tĂ© la première Ă  mettre en place ses balises appelĂ©es « Estimote Beacon » et reste l’une les plus connues sur le marchĂ©. Sortie depuis la fin de l’annĂ©e 2013 en version Developer Preview Kit, cette version est proposĂ©e Ă  99$ les trois balises et nous permet aujourd’hui de dĂ©couvrir, de tester et d’approfondir le fonctionnement d’iBeacon.

ibeacon

Quels sont les terminaux permettant de faire office d’iBeacon et comment une balise s’identifie-t-elle ?

Une balise n’est rien d’autre qu’un Ă©metteur Bluetooth. Cependant on peut convertir son propre appareil mobile en une balise.

Du cotĂ© iOS, l’iPhone 4S, l’iPad 3 et l’iPod 5 sous iOS 7 sont les terminaux minimum Ă©quipĂ©s du bluetooth 4.0. Du cotĂ© Android, malheureusement l’API n’offrira pas la possibilitĂ© de diffuser des signaux iBeacon mais en revanche une application Android peut reconnaitre un signal iBeacon et l’exploiter. Pour cela, il faudra disposer d’un terminal Ă©quipĂ© du bluetooth 4.0 et intĂ©grant la version minimum 4.3 Jelly Bean. Existe-t-il d’autres terminaux qui pourront Ă©galement faire office d’iBeacon? La rĂ©ponse est oui, nous pouvons prendre pour exemple, un Raspberry pi + un bluetooth dongle qui permet de le faire.

Identification d’une balise ?

Une balise est caractérisée par trois paramètres :

  • un UUID (Universal Unique IDentifier)
  • une valeur major : est utilisĂ©e pour spĂ©cifier un ensemble de balises
  • une valeur minor : est utilisĂ©e pour identifier une balise en particulier

Ces paramètres permettront d’identifier de manière unique un iBeacon et permettront d’avoir une granularité de localisation relativement précise. Voici un exemple de fonctionnement possible :

  • un UUID qui reprĂ©sentera la sociĂ©tĂ© OCTO Technology : 378FD6D5-5D38-409B-8472-83DE544F62C1
  • un major qui reprĂ©sentera un des Ă©tages de cette sociĂ©tĂ©, par exemple : major 1 = Ă©tage du 1er, major 2 = Ă©tage du 5ème et major 3 = Ă©tage du 6ème
  • un minor qui reprĂ©sentera un emplacement dans l’Ă©tage, par exemple : minor 1 = accueil, minor 2 = salle dĂ©tente, minor 3 = open space

Avec cette dĂ©termination de valeur, les paramètres (378FD6D5-5D38-409B-8472-83DE544F62C, 1, 1) correspondraient au rayon accueil du 1er Ă©tage d’OCTO Technology et les paramètres (378FD6D5-5D38-409B-8472-83DE544F62C, 3, 2) correspondraient au rayon salle dĂ©tente du 6ème Ă©tage d’OCTO Technology.

Du cĂ´tĂ© du rĂ©cepteur, votre iPhone doit reconnaitre le signal Ă©mis par la balise. Il sera alors capable d’identifier quatre Ă©tats de proximitĂ© :

  • l’Ă©tat de proximitĂ© « immediate » : la balise est Ă  moins d’un mètre
  • l’Ă©tat de proximitĂ© « near » : la balise est Ă  quelques mètres
  • l’Ă©tat de proximitĂ© « far » : la balise est au-delĂ  d’une dizaine de mètres
  • l’Ă©tat de proximitĂ© « unknown » : aucun Ă©metteur n’est repĂ©rĂ©

Prendre en note que la prĂ©cision varie en fonction des interfĂ©rences radio. La responsabilitĂ© appartiendra donc aux concepteurs d’imaginer quelles seront les utilisations Ă  en tirer.

L’iBeacon et les annĂ©es à venir ?

Seuls les Etats-Unis ont pour le moment dĂ©ployĂ© l’iBeacon dans plus de 254 boutiques. Dans les annĂ©es Ă  venir, il n’est pas improbable que les grandes enseignes d’Europe auront Ă©galement recours au dispositif.

Une Ă©tude effectuĂ©e par SWIRL a rĂ©vĂ©lĂ© que 65% des consommateurs souhaitent en apprendre davantage sur les produits et les promotions en magasin via leur smartphone. Aujourd’hui, les consommateurs pensent ĂŞtre prĂŞts Ă  recevoir des notifications push en magasin. 67 % des consommateurs ont dĂ©clarĂ© qu’ils ont reçu des notifications push commerciales sur leurs smartphones dans les six derniers mois. De ce nombre, 81% ont dit qu’ils ont lu ces alertes la plupart du temps, et 79% ont fait un achat en consĂ©quence.

image03

Mais attention, les dĂ©taillants doivent s’assurer que le contenu mobile est pertinent et utile. Les causes pouvant amener Ă  ignorer les notifications push mobiles sont dĂ»es aux informations non pertinentes comme 41% des consommateurs en tĂ©moignent. 37% dĂ©clarent que les alertes n’ont pas fourni suffisamment de valeur, 16% pensaient qu’elles Ă©taient ennuyeuses, et 6% ne les optent pas. L’iBeacon fournit aux dĂ©taillants la possibilitĂ© de diffuser du contenu numĂ©rique très pertinent et offre Ă©galement la possibilitĂ© de crĂ©er des expĂ©riences de magasinage vraiment personnalisĂ©es, ce qui est essentiel pour convaincre un maximum d’utilisateurs.

image02

Aujourd’hui, l’iBeacon est utilisĂ© en grande majoritĂ© dans le secteur commercial et la fonctionnalitĂ© la plus frĂ©quente reste pour le moment l’envoi des notifications push aux utilisateurs.

A part le secteur commercial, l’iBeacon pourrait s’ouvrir Ă  diffĂ©rents types de secteurs d’activitĂ© tels que les gares et aĂ©roports, stades et complexes sportifs (la ligue de baseball MLB qui annonce la fin des installations des iBeacons dans plus de 20 stades), banques, Ă©coles et universitĂ©s, salons professionnels et confĂ©rences, musĂ©es, villes, parcs, etc… Maintenant, Ă  nous d’imaginer quelles seront les fonctionnalitĂ©s que nous pourrions proposer Ă  ces secteurs d’activitĂ© et de faire de l’iBeacon une technologie de demain.

Et techniquement ?

Les Ă©quipes d’OCTO travaillent actuellement sur des sujets autour d’iBeacon. Une première approche serait de dĂ©montrer le fonctionnement d’un iBeacon Ă  travers un Ă©vènement connu, l’USI. Un deuxième article est prĂ©vu dans les mois Ă  venir et rĂ©pondra Ă  la question suivante : comment implĂ©menter techniquement iBeacon sur iOS et Android ?

Suggestion d'articles :

  1. PATTERN UI : le responsive design, la nouvelle tendance du web

Catégories: Blog Société

Paris Oracle Meetup : Le Compte-Rendu

Le blog des experts du groupe Infotel - lun, 03/10/2014 - 12:59
Le 6 mars, Infotel a accueilli le POM ( Paris Oracle Meetup ) au Novotel de Bagnolet pour une soirĂ©e d’expertise sur la base de donnĂ©es Oracle. A ce titre, je vous invite Ă  vous inscrire pour la soirĂ©e du … Lire la suite →
Catégories: Blog Société

QCon London 2014 - Journal de Bord - Day 3

Zenika - lun, 03/10/2014 - 11:00

7 Mars 2014, 08:42, banlieue de Londres :

En route pour la troisième et dernière journée de la QCon.

Keynote - The world "after" Cloud Computing and Big Data Par prf. Gunter Dueck Le professeur nous parle de changement, de la zone de confort et comment en sortir pour trouver de nouveaux challenges, avec humour. Comment deux souris, ne trouvant plus de fromage (le monde est devenu bacon), finissent par mourrir plutĂ´t que s'adapter. L'architecture... Read QCon London 2014 - Journal de Bord - Day 3

Catégories: Blog Société

Partagez la connaissance

Partagez BlogsdeDeveloppeurs.com sur les réseaux sociaux