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

Événement #Startup #BackToBasics

ekito people - dim, 05/17/2015 - 23:01

Venez participer à notre événement #Startup #BackToBasics le mardi 9 juin, de 12h à 13h30.

Même format que notre précédent événement, Pitch Me Up, mais avec un contenu légèrement différent.

Le principe : venez présenter à vos collègues startupeurs vos trois fondamentaux :

  • la douleur que vous adressez (i.e., les problèmes de vos clients)
  • votre cible ; qui ils sont, leurs profils, ce qui les fait rĂ©agir…
  • vos canaux d’acquisition ; ceux mis en place, et Ă©ventuellement ceux testĂ©s puis rejetĂ©s
Startup Back To Basics Problem Cible Canaux

Back to Basics

Chaque moment de partage durera 5 minutes.
Puis une courte séance de questions-réponses avec le public, pour qu’il vous challenge ou vous propose des idées.

Partagez vos 3 fondamentaux : douleur, cible et acquisition.

Au premier hors-sujet hop, carton jaune !
Attention à ne pas déraper… ce sont vos collègues startupeurs qui vous surveilleront.

La préparation de votre présentation est l’occasion parfaite d’un peu d’introspection et de prise de recul :

  • La douleur que vous adressez est-elle aiguĂ« ? Votre cible en a-t’elle un niveau de conscience suffisant ?
  • Connaissez-vous vraiment votre cible, pouvez-vous l’affiner ?
  • Pouvez-vous prouver ces points ? Ou certains sont-ils encore Ă  l’état d’hypothèses non vĂ©rifiĂ©es ?
Pourquoi ne parler que de ces 3 composants ?

Nous rencontrons trop souvent des entrepreneurs, qui par envie de travailler au plus vite sur la solution perdent de l’énergie en créant une startup qui repose sur un problème qui n’en est pas un.
Et ça… c’est un vrai problème :-) !

Fondations instables

MĂŞme si tout semble avancer… sur des fondations instables la chute est garantie !

 

Local maxima

Au moins la chute force Ă  ouvrir les yeux. Le pire serait de ne jamais arriver Ă  franchir un palier, sans comprendre pourquoi.

Format

On n’a pas vraiment changĂ© d’avis sur l’utilitĂ© et la valeur d’un pitch. Donc :

  • Interdiction absolue de parler de vous (votre startup, votre Ă©quipe, votre super nom !)
  • Interdiction absolue de parler de votre proposition de valeur, votre solution
  • Interdiction absolue de parler de tous les trucs supers cool et qui marchent super bien auprès des B.A.
  • Interdiction absolue de parler de vos mĂ©triques off-the-charts, vos recrutements, etc. Bref, vous avez compris, tout ce qui n’est pas votre #Problème, votre #Cible ou votre stratĂ©gie d’#Acquisition. #BackToBasics :)
Infos plaisir

Notre Chef en résidence cuisinera des assiettes complètes que vous pourrez acheter sur place (6,5 €), et nous vous offrirons les boissons.

abc

Dom, notre Chef en résidence en train de réfléchir à votre futur menu.

 

Détails pratiques

Camping Toulouselogo_ekito_big

Cet événement est co-organisé par Le Camping Toulouse et ekito.

Il est ouvert à toutes les startups, qu’elles soient co-produites par ekito, en présélection, au Camping, à La Passerelle, dans une pépinière privée ou publique, un petit peu de tout ou bien rien de tout ça.

Inscription gratuite et obligatoire, par ce formulaire.

Rendez-vous au GrandBuilder, 15 rue Gabriel Péri, à 12h pour commencer à se rencontrer, manger et boire un coup. Début des présentations à 12h30, pour que chacun puisse retourner travailler à 13h30 maximum.

Vous pouvez venir assister sans présenter vos bases. Mais inscrivez-vous quand même.

Enfin, si vous n’ĂŞtes pas dispo le mardi 9, nous avons d’autres Ă©vĂ©nements pour vous :

Ă€ bientĂ´t !

The post Événement #Startup #BackToBasics appeared first on ekito people.

Catégories: Blog Société

Creating a Micro Service with Grails 3

odelia technologies - sam, 05/16/2015 - 14:47

Here a screencast on Micro Service creation with Grails 3 using the "web-micro" profile. Groovy code is also used to interact with the CRUD RESTful service created, using the groovy-wslite project.

Catégories: Blog Société

[PO Dojo] Venez découvrir l’impact mapping de notre « Fun House »

Agile Nantes - ven, 05/15/2015 - 18:43

Vous connaissez l’impact mapping ???

Nous … Non ;-( ou pas vraiment ;-)

Nous avons donc recrutĂ© un nouveau podojiste ;o) … pour dĂ©couvrir cette technique et l’appliquer Ă  notre crĂ©ation, la Fun House, notre maison auto-nettoyante !

RDV donc mercredi pour poursuivre l’aventure …

Nous vous encourageons à apporter quelque chose à manger ou à boire pour créer une ambiance plus conviviale.

 

Ces sessions PO Dojo s’adressent aux personnes connaissant dĂ©jĂ  l’agilitĂ© et souhaitant progresser dans ce rĂ´le de Product Owner.

podojo

Le PO Dojo est l’espace des Product Owners pour apprendre par la pratique. L’objectif est de rĂ©aliser les actions du product Owner pour passer d’une idĂ©e marketing Ă  une user story prĂŞte pour la planification.

A bientĂ´t,

Le groupe PO Dojo nantais

OĂą et quand ?

> Où: Chez Arpège, parc de la Gibraye, 13 rue de la Loire à St Sébastien sur Loire

> Quand: mercredi 20 mai de 19h à 21h

> Faut il s’inscrire ? Oui, grâce à ce lien

L’association Agile Nantes

Catégories: Association

Revue de Presse Xebia

RDP

RDP


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Ă© #NoEstimates – Accidental Complication or why estimates don’t work http://www.gravatar.com/6beb8800b1d5d45c22ecc81062e12448http://blog.xebia.fr/author/nlochethttp://twitter.com/nicolaslochetPar Nicolas Lochet

Cet article de Vasco Duarte est un argumentaire supplĂ©mentaire en faveur du cas #NoEstimates. Pour ma part, je ne le trouve pas tant intĂ©ressant pour les arguments qu’il apporte en ce sens que pour la distinction qu’il fait entre "essential complication" et "accidental complication" c’est Ă  dire entre la complexitĂ© inhĂ©rente Ă  une tache et celle liĂ©e Ă  son contexte.

En effet, bien souvent, les estimations faites en entreprise ne prennent pas en compte cette "accidental complication" alors qu’elle peut reprĂ©senter l’essentiel du coĂ»t de rĂ©alisation.

Pour en savoir plus, je vous invite donc Ă  lire l’article et ainsi Ă  minima prendre en compte cette dimension lors de futures "estimations".

5 reasons to switch from your kanban board http://www.gravatar.com/6beb8800b1d5d45c22ecc81062e12448http://blog.xebia.fr/author/nlochethttp://twitter.com/nicolaslochetPar Nicolas Lochet

Je prĂ©fère vous le dire tout de suite, je ne suis pas d’accord avec les conclusions de cet article qui prĂ©sente 5 raisons pour adopter un Kanban Ă©lectronique.

Si je vous le partage, c’est que les arguments avancĂ©s font partie de ceux que l’on voit rĂ©gulièrement. Voici quelques rĂ©ponses que l’on peut y apporter en faveur d’un tableau physique.

  • Espace illimitĂ©: En pratique, l’outil Ă©lectronique n’apporte rien, car si l’espace est illimitĂ©, la partie visible Ă  l’Ă©cran est plus limitĂ©e que celle d’un tableau physique. On ne peut pas bĂ©nĂ©ficier de l’effet "radiateur d’informations"
  • Informations dĂ©taillĂ©es de la carte changent: S’il est intĂ©ressant d’avoir cette information quelque part, ce n’a aucun intĂ©rĂŞt sur un kanban. En effet, trop d’informations tuent l’information. La carte doit ĂŞtre visible de loin et permettre la conversation. Nous savons tous que noyĂ©s sous les spĂ©cifications, nous avons tendance Ă  ne plus lire du tout.
  • MĂ©triques automatiques: C’est lĂ  un bon argument pour un tableau Ă©lectronique en complĂ©ment d’un tableau physique
  • Accès illimitĂ© aux informations de l’Ă©quipe: Un faux problème. On s’en sort très bien avec un tableau physique. Pensez Ă  utiliser des avatars. En les dĂ©plaçant avec la carte, vous savez qui a travaillĂ© dessus.
  • Update et monitoring facilitĂ©s: Mauvais argument, dĂ©placer un post-it reste beaucoup plus rapide qu’en changer le statut dans un outil. Par ailleurs, pour ce qui est du monitoring, un coup d’oeil Ă  un tableau physique suffit gĂ©nĂ©ralement pour s’apercevoir qu’une tâche n’a pas bougĂ© depuis plusieurs jours ou que les post-its sont en train de virer au rouge!

VoilĂ , j’espère vous avoir apporter quelques rĂ©ponses si vous deviez, vous aussi dĂ©fendre le tableau physique. L’outil Ă©lectronique reste intĂ©ressant, mais en complĂ©ment seulement.

Why Physical Task Boards Still Matter http://www.gravatar.com/6beb8800b1d5d45c22ecc81062e12448http://blog.xebia.fr/author/nlochethttp://twitter.com/nicolaslochetPar Nicolas Lochet

Après l’article contre l’utilisation de tableaux kanban physiques, celui-ci par Joel Bancroft-Connors explique leur intĂ©rĂŞt.

Vous vous en doutez, du coup je ne puis qu’en ĂŞtre partisan.

Ce qui est intĂ©ressant avec cet article c’est qu’il va au-delĂ  des arguments que j’ai dĂ©jĂ  pu rapporter au sujet du prĂ©cĂ©dent article. Vous y trouverez des informations de recherche qui expliquent l’intĂ©rĂŞt du physique. Vous y verrez aussi quelques dĂ©tails pratiques pour mieux mixer le tableau Ă©lectronique avec le tableau physique. Il n’y a guère que le point Ă  propos des Ă©quipes distribuĂ©es que l’on peut Ă©ventuellement discuter. Pour ma part dans ces cas-lĂ , je propose la duplication du tableau physique en complĂ©ment de l’Ă©lectronique. C’est certes plus contraignant, mais le bĂ©nĂ©fice en vaut le coĂ»t.

Je vous souhaite une bonne lecture.

Myths Of Companies With No Management http://www.gravatar.com/6beb8800b1d5d45c22ecc81062e12448http://blog.xebia.fr/author/nlochethttp://twitter.com/nicolaslochetPar Nicolas Lochet

Pour beaucoup une entreprise libĂ©rĂ©e, c’est une entreprise sans chefs. C’est cette vision un peu rĂ©ductrice Ă  laquelle s’attaque Romy Misra. Dans cet article, elle s’attache Ă  expliquer certaines des idĂ©es reçues les mieux partagĂ©es Ă  propos des entreprises sans management (c’est facile de ne pas avoir de chefs, plus de management signifie plus de structure, plus de chefs signifie qu’on est tous Ă©gaux, le management est toujours mauvais).

Pour qui est intĂ©ressĂ© par le sujet, c’est donc lĂ  un avertissement fort utile afin de mieux comprendre les enjeux d’une transformation vers ces modèles d’entreprises libĂ©rĂ©es. Au passage, vous y trouverez aussi quelques pointeurs vers des organisations ayant adoptĂ© ce fonctionnement.

Mobilité LeakCanary, chassez et colmatez vos fuites mémoires sur Android http://blog.xebia.fr/author/jmartinezhttp://twitter.com/JeremMartinezhttp://github.com/jeremiemartinezPar Jeremie Martinez

Sur le blog de Square, Pierre-Yves Ricau nous annonce la sortie de leur dernière librairie nommĂ©e LeakCanary. Elle permet de monitorer les activitĂ©s afin de dĂ©tecter d’Ă©ventuelles fuites mĂ©moires et d’afficher, le cas Ă©chĂ©ant, une notification permettant d’en trouver l’origine. Elle s’intègre très facilement dans le code existant et permet donc de dĂ©tecter des fuites tout au long du cycle de dĂ©veloppement. Elle leur a notamment permis de rĂ©duire leur OutOfMemoryException de 94% et de dĂ©tecter plusieurs fuites mĂ©moires dans le framework Android lui-mĂŞme. Un guide d’utilisation et d’installation est disponible sur leur GitHub Ă  ce lien.

Front Sortie de Backbone 1.2.0 http://www.gravatar.com/fcc468bdfdbf0a107336686362f3100fhttp://blog.xebia.fr/author/fduveauhttp://twitter.com/florentduveauhttp://github.com/FlorentDPar Florent DUVEAU

15 mois après sa dernière release (1.1.2), Backbone sort une nouvelle version de sa libraire RIA orientée data.
Pas de gros changements au programme, mais quelques Ă©volutions :

  • PossibilitĂ© de s’abstraire de jQuery pour la gestion du DOM. On peut maintenant utiliser du javaScript natif, jsdom ou mĂŞme du D3.js. Cette Ă©volution rentre totalement dans la logique de la librairie de dĂ©coupler au maximum les composants d’une application RIA.
  • Dans un environnement CommonJS, Backbone charge jQuery par dĂ©faut quand celui-ci est prĂ©sent. C’est un retour en arrière par rapport Ă  la 1.1.2 (avec notamment la popularitĂ© grandissante de browserify).
  • Ajout d’un Ă©vĂ©nement update lors d’une modification d’une collection.
  • Travail sur la compatibilitĂ© avec ES6/ES2015.
  • Divers amĂ©liorations sur le Router.

Et d’autres petites choses sympathiques ! Le mieux reste de jeter un coup d’œil sur le changelog !
Avec cette nouvelle release, Backbone ne trahi donc pas sa philosophie initiale : simplicité, stabilité et découpage.

Back Disponibilité finale de la JDK9 fin 2016 http://www.gravatar.com/0eac998a3709ea6d1b7498a49bb73ba9http://twitter.com/valdo404http://github.com/valdo404Par Laurent Valdes

Mark Reinhold a annoncĂ© le planning de rĂ©alisation de la JDK 9. L’intĂ©gration des fonctionnalitĂ©s se fera fin 2015. Et la version finale sera releasĂ©e fin 2016.

Au menu: Coin 2, http 2, jigsaw, etc…

Java 9 : Breaking changes en vue http://www.gravatar.com/b48c1ee560ff6432a574dceb746dff79http://blog.xebia.fr/author/romain-niveau%2Fhttp://twitter.com/RomainNVhttp://github.com/rniveauPar Romain Niveau

Une des grandes forces de Java est sa rétro compatibilité. Il est possible de faire tourner une application développée en Java 1 sur une JVM Java 8.

Cette rétro compatibilité facilite grandement la migration des projets vers les nouvelles versions.

Et bien avec Java 9, il va falloir faire autrement. En effet, le projet de modularisation du JDK JigSaw va apporter de profonds changements dans l’architecture mĂŞme de Java.

Cet article tente de répertorier les cas concrets où votre application ne pourra pas migrer sans douleur vers Java 9.

DevOps la success story de Huawei Par Richard Mathis

L’évolution d’Huawei, le géant chinois de la télécommunication, constitue une preuve concrète de l’efficacité des pratiques de Continuous Delivery et de DevOps au sein de son infrastructure IT.

La scalabilitĂ© procurĂ©e par ces mĂ©thodes a permis Ă  la multinationale de faire passer ses effectifs de 2 000 dĂ©veloppeurs travaillant sur 20 applications, Ă  40 000 dĂ©veloppeurs travaillant sur 1 000 applications. L’article de SDTimes dĂ©veloppant l’exemple du gĂ©ant chinois est disponible ici (http://sdtimes.com/guest-view-continuous-delivery-scaling-from-2000-to-40000-developers-worldwide/). Aujourd’hui, l’organisation d’Huawei est impressionnante, avec en exemple les volumĂ©tries suivantes :  – Plus de 2 000 releases par an  – Plus de 100 000 compilations et builds par jour  – Plus d’1 million de test cases effectuĂ©s par jour  – Plus de 30 million de lignes de codes  – Plus de 480 000 relectures et analyses de code par an  – Plus de 170 000 tests d’intĂ©gration système par an Le coin de l’Alliance XebiaLabs sera sponsor des "Belgium Testing Days" Ă  Bruxelles les 20 et 21 Mai prochains http://twitter.com/xebialabsFrPar Xebia Labs Durant 4 jours, les BTD 2015 vous proposent de participer Ă  des sessions d’échanges, workshops et confĂ©rences traitant des problĂ©matiques liĂ©es au testing, software QA et au dĂ©veloppement en gĂ©nĂ©ral. L’équipe XebiaLabs est ravie de sponsoriser l’évĂ©nement et vous attend sur son stand les 20 et 21 Mai pour dĂ©couvrir entre autre sa nouvelle solution XL Test dĂ©diĂ©e Ă  la gestion et l’agrĂ©gation ainsi qu’Ă  l’analyse des rĂ©sultats de tests !
Catégories: Blog Société

Ippevent jeudi 21 mai : Pratiques de la méthode Kanban à travers le jeu de plateau Kanbanzine

Blog d’Ippon Technologies - jeu, 05/14/2015 - 16:56
L’Ă©vĂ©nement :

DĂ©couvrez les pratiques de la mĂ©thode Kanban Ă  travers le jeu de plateau kanbanzine et sa version Open Source. Vous ferez partie de l’Ă©quipe d’Ă©dition de l’hebdomadaire Kanbanzine. Votre challenge sera d’obtenir le maximum d’audience en publiant Ă  temps des numĂ©ros complets (articles, reportages, petites annonces..). Vous serez confrontĂ© Ă  diffĂ©rentes situations qui vous amèneront, en les vivant, Ă  rĂ©flĂ©chir sur l’optimisation de votre flux et en ce sens Ă  apprĂ©hender les principes et pratiques du kanban. Ă€ l’issue, un dĂ©briefing vous permettra de mieux comprendre ce que vous avez vĂ©cu.

A la fin de la dĂ©monstration, profitez d’un buffet pour interagir avec nos speakers Ă  propos de votre expĂ©rience.

 

Quand ?

Jeudi 21 Mai Ă  partir de 19h chez Ippon Technologies :

43-47 avenue de la Grande Armée

75116, Paris

 

Les Speakers :

Anne Gabrillagues – Coach Agile chez Ippon Technologies

Victoria Pedron – Chef de projet Java/JEE chez Ippon Technologies

 

Développé par Eventbrite

 

Catégories: Blog Société

BUILD 2015 : Databinding compilé

Windows 10 apporte de nombreuses nouveautĂ©s aux dĂ©veloppeurs d’applications XAML, notamment du cĂ´tĂ© du databinding. Il s’agit probablement d’une des fonctionnalitĂ©s les plus importantes (en tout cas ma prĂ©fĂ©rĂ©e !), qui vient gommer le dĂ©savantage du binding actuel : le...
Catégories: Blog Société

LCC 124 - La loi renseignement en Node.js

Vincent, Guillaume et Emmanuel discutent la loi renseignement, WordPress en Node.js, de l’intérêt des fondations pour les projets open sources et de tous les prétendants au trône d’IRC et de Skype. Et bien d’autres choses encore.

Enregistré le 11 mai 2015

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

News Politique

Loi renseignement:

Boîte noire killer
Ma belle mère et le djihâd

Langage

Agenda pour JDK 9
Server Name Identification
NoTCP.io
QUIC
JRuby 9.0 pre2
Groovy en incubation chez Apache

Plateformes

Slick 3.0
WordPress en node.js
Nuxeo
WildFly Swarm: WildFly en fat jar pour microservices
Grails chez Object Computing

Outillage

Red Hat devient membre stratégique d’Eclipse
Éclipse et docker sont sur un bateau
Visual Studio Code sous Mac et Linux
Atom.io
Windows PowerShell sur Linux
Livre Asciidoctor
LeanPub
Git large file storage
Leak canary par Square (merci Ă  Pierre-Yves Ricau)

MĂ©thodologies

Contre la fondation node.js
RAML
Swagger
iCloud me vole mes invitations
Loi de scalabilité appliquée au management
Astuces de développement

Grosse Data

If you torture the data log enough, it will confess - Ronald Coase

Apple Mesos et JARVIS
Article sur les patterns de lecture et d’écriture aux données

Outils de la semaine

SSLLabs
TrueCrypt

Débat de l’épisode

Slacker ou ne pas Slacker lĂ  est la question Slack
HipChat
Gitter
Jitsi
Jitsi rejoint HipChat

Les conférences

Compte rendu Devoxx France
Breizhcamp
EclipseCon (merci Ă  Mickael Istria)
dotScale
JavaOne et sa track de sécurité

Nous contacter

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

Catégories: Blog Individuel

L’échappée des Ippon au TimeOut Cyclisme

Blog d’Ippon Technologies - jeu, 05/14/2015 - 07:45

Les TimeOut Sports, ce sont des soirĂ©es qui permettent Ă  une Ă©quipe de consultants Ippon de dĂ©couvrir une discipline entre collègues aux cĂ´tĂ©s d’un sportif de haut niveau et de se mesurer Ă  son boss, prĂ©sent pour l’occasion.

Après le TimeOut Escrime au mois de Janvier (dont vous pouvez retrouver les photos via ce lien) qui a permis Ă  l’Ă©quipe de Victoria de rencontrer l’escrimeuse CĂ©cilia Berder, c’est l’Ă©quipe de Vincent qui a eu la chance de participer au TimeOut Cyclisme au vĂ©lodrome de L’INSEP aux cĂ´tĂ©s de Florian Rousseau, double champion olympique (1996 et 2000) et multiple mĂ©daillĂ© aux championnats du monde de cyclisme sur piste.

Patrick, Sylvain, Quentin et Edouard nous racontent leur soirée.

 

- Comment as-tu vécu les premiers tours de piste ?

Patrick : Lors des premiers tours de piste on a un peu d’apprĂ©hension, d’une part parce que le vĂ©lo est Ă  pignon fixe (j’ai l’habitude du VTT) et d’autre part, l’inclinaison de la piste est assez impressionnante. On commence donc par rouler sur la cĂ´te d’azur (zone bleue sans pente) afin d’apprivoiser la monture si je puis dire et une fois en confiance, on commence Ă  titiller le parquet. Une fois qu’on assez de vitesse (on attend le go de Florian), on peut se lancer sur la partie haute de la piste et prendre les virages et lĂ , c’est du pur bonheur !

Quentin : Pratiquant un peu le vĂ©lo sur route je partais confiant pour cette activitĂ©. Mais quand j’ai dĂ©couvert la forte pente dans les virages du vĂ©lodrome, un lĂ©ger doute m’a envahi. Durant les premiers tours de piste, je suis restĂ© sur le bas de la piste pour me familiariser avec le vĂ©lo puis en prenant petit Ă  petit de la vitesse j’ai vu qu’il Ă©tait possible de monter plus haut. Après j’ai lâchĂ© les chevaux pour finalement atteindre les extrĂ©mitĂ©s extĂ©rieures de la piste, c’Ă©tait gĂ©nial avec une Ă©norme sensation de vitesse :).

Edouard : J’ai vĂ©cu les premiers tours de piste avec une certaine apprĂ©hension dĂ»e Ă  l’absence de freins, les pignons fixes et Ă  l’inclinaison des courbes Ă  45°. C’est un sport rapidement fatigant qui demande une excellente condition physique et une bonne endurance surtout au niveau des quadriceps tendus Ă  leur maximum au bout de quelques tours. - Comment Florian Rousseau vous a-t-il encadrĂ© ? Sylvain : Florian Rousseau nous a beaucoup aidĂ© et nous a donnĂ© des conseils pour notre sĂ©curitĂ©. Il nous donnait aussi le go pour aller plus haut, si la vitesse Ă©tait suffisante. On sentait qu’il Ă©tait très concernĂ© par notre sĂ©curitĂ©.   Quentin : Florian a Ă©tĂ© super accueillant. Après nous avoir donnĂ© quelques consignes de sĂ©curitĂ© et quelques tuyaux pour rĂ©ussir notre baptĂŞme de cycliste sur piste, il nous a coachĂ© durant tout l’entraĂ®nement n’hĂ©sitant pas Ă  crier pour que l’on puisse l’entendre pendant que l’on pĂ©dalait “Plus viteeeeeeee” disait-il. Étant un grand fan de sport, je le connaissais bien, il semblait ĂŞtre quelqu’un de bien et je n’ai pas Ă©tĂ© déçu :).

Edouard : Florian Rousseau est très abordable et a Ă©tĂ© de très bons conseils et un excellent coach qui a su nous motiver Ă  prendre de la vitesse malgrĂ© la peur et Ă  dĂ©passer nos limites pour s’incliner au maximum dans les courbes. - Que retiendras-tu de cette soirĂ©e ? Sylvain : Il faut savoir ĂŞtre prudent, mais aussi dĂ©passer ses limites, et ce fut le cas pour moi! C’Ă©tait un très bon moment de dĂ©couvrir le cyclisme sur piste. Patrick : Un super moment avec Florian et tous les collègues Ippon et la dĂ©couverte d’un sport qui m’a toujours attirĂ©. Au vu des sensations Ă©prouvĂ©es lors de la session, il n’est pas impossible que je renouvèle l’expĂ©rience un de ces jours sur la piste de Saint-Quentin-En-Yvelines comme nous l’a indiquĂ© Florian.

VĂ©lodrome INSEP

Conseils Florian Rousseau

Photo de groupe Retrouvez les photos de la soirĂ©e sur l’album dĂ©diĂ© en cliquant ici.

Catégories: Blog Société

Eclipse Che, un IDE sur le Cloud

  DĂ©veloppeur, votre DSI n’a pas les moyens de vous fournir un environnement de dĂ©veloppement consistant ? Vous voulez expĂ©rimenter de nouvelles technologies et rĂ©aliser rapidement des POC sans vous tracasser avec la configuration fastidieuse d’un environnement de dĂ©veloppement ?...
Catégories: Blog Société

En juin, devenez Scrum Master ou Product Owner avec Xebia Training

Au mois de juin, profitez d’une offre tarifaire exceptionnelle de Xebia Training pour devenir Scrum Master ou Product Owner Ă  travers 2 formations certifiantes : 

Votre formatrice pour ces 2 formations, Petra Skapa, travaillant avec les méthodes agiles et Scrum depuis plus de 10 ans, mettra à votre service son expérience. Elle a mis en place l’agilité dans 5 pays différents dans plusieurs secteurs d’activités (grande distribution, transport, Télecoms, éditeurs, intégrateurs, etc.) auprès de sociétés telles que GAP, Caterpillar, Symantec, Orange, l’université de Stanford, Nationwide Insurance et Westjet Airlines pour ne citer qu’eux.

ScrumMaster Certifiante de la Scrum Alliance

Cette formation Scrum certifiante de 2 jours vous apportera tous les éléments nécessaires pour diriger ou contribuer à une équipe Scrum.

A l’issue de cette formation, les stagiaires seront en mesure de :

  • Les concepts essentiels ainsi que les outils de Scrum
  • Les diffĂ©rences entre les mĂ©thodes agiles et les mĂ©thodes traditionnelles en « cascade »
  • Comment mettre en place une feuille de route pour l’adoption de l’agilitĂ©

Cette formation certifiante Scrum Master répondra notamment aux questions suivantes :

  • Comment planifier et faire des estimations avec Scrum
  • Comment un chef de projet traditionnel devient-il un chef de projet agile
  • Comment faire travailler l’analyste fonctionnel avec les Ă©quipes agiles ?
  • Comment fonctionnent les reportings et les mĂ©triques avec Scrum ?
  • Comment travailler avec des Ă©quipes distribuĂ©es en Scrum ?
  • Comment savoir si un projet est compatible avec Scrum ?
  • Quels sont les outils principaux de Scrum ?
  • Comment s’assurer d’un rĂ©sultat coherent ? Comment amĂ©nager la salle d’une Ă©quipe agile ?

Tout le programme ici.

Scrum Product Owner Certifiante de la Scrum Alliance

Cette formation de 2 jours vous apportera tous les éléments qui vous sont nécessaires afin de devenir un interlocuteur productif, maximisant le ROI de son entreprise. Les participants apprendront les concepts et les outils essentiels de Scrum, les différences entre les projets agiles et les méthodologies traditionnelles de type cascade et comment le rôle de l’interlocuteur « business » change vis-à-vis des équipes Scrum. Les participants apprendront aussi comment gérer et prioriser efficacement les « product backlogs », les « plan releases », les « sprints » et les « track et report ».
Afin d’illustrer les principes expliqués de manière efficace et dans le souci de répondre aux problématiques particulières de chaque participant, le programme comprend des exercices pratiques, des démonstrations, des discussions vulgarisatrices, des études de cas ainsi que des cas d’usage. 

Tout le programme ici.

Pour toutes informations complémentaires, n’hésitez pas à nous contacter au 01 53 89 99 93 ou par de mail à info@xebia-training.fr.

Catégories: Blog Société

Initiation au développement de plugin Redmine

L'actualité de Synbioz - mar, 05/12/2015 - 23:00

Redmine est un outil de gestion de projet que j’affectionne pour sa simplicité et son accessibilité. Dans sa version originale il permet de gérer un éventail très large de types de projets, pas uniquement a destination des équipes de développement, mais aussi pour les bureaux d’études, administrations … Cependant, il peut arriver que l’on ai besoin de fonctionnalités supplémentaires ou de revoir ses fonctionnalités de bases pour l’adapter à son propre besoin. Comme c’est un logiciel libre, il est possible de le « forker » pour l’adapter. Mais ça à l’inconvénient de rendre l’import de fonctionnalités de nouvelles versions beaucoup plus délicat. Il est beaucoup plus avisé de s’appuyer sur le système de plugins de Redmine qui permet d’étendre et de modifier ses fonctionalités. Les pré-requis au développement de plugins sont la connaissance de Ruby avec certaines notions de meta-programmation, la connaissance du fonctionnel et du code de Redmine.

Redmine permet de changer le statut d’une demande de plusieurs manières : - lorsqu’on consulte une liste de demandes, au travers d’un click droit. Pas commun et peu utilisable sur un smartphone par exemple. - lorsqu’on consulte une demande, en cliquant sur « modifier » puis en sélectionnant le statut. Et enfin en cliquant sur « Enregistrer », ça fait beaucoup de clics si on a plusieurs demandes à traiter.

Lire la suite...

Catégories: Blog Société

Jeudi 21 mai 2015 - Soirée Elasticsearch !

JUG Toulouse, Groupe d'utilisateur Java - mar, 05/12/2015 - 21:30

Attention adresse différente: Epitech Toulouse 14 rue Claire Pauilhac (Inscrivez vous).

Vous utilisez encore des requêtes SQL pour faire des recherches ? Vos utilisateurs vous reprochent de ne pas pouvoir chercher sur toutes les rubriques ? Votre temps de réponse moyen est supérieur à la demi-seconde avec seulement quelques millions de documents ? Il vous faut 3 jours pour produire des statistiques sur vos données ? Vous rêvez d’offrir une recherche "à la google" sur les données de votre SI ?

Ne cherchez plus !

David Pilato, évangéliste chez elastic.co, présentera au cours de la soirée pourquoi et comment il est passé de la recherche SQL à Elasticsearch en détaillant les apports de ce moteur par rapport à une solution pure Lucene.

Agenda:

  • Pourquoi Elasticsearch ?

  • L'indexation

  • La recherche

  • Les agrĂ©gations et le principe de navigation par facettes

  • La scalabilitĂ© horizontale

  • L'analyse et le mapping

  • La percolation

  • La communautĂ©

Bio : Depuis 2013, David Pilato est développeur et évangéliste chez elastic.co, après avoir passé les deux années précédentes à promouvoir le projet open-source Elasticsearch. Il en anime la communauté française.

@dadoonet et @ElasticsearchFR sur Twitter

dadoonet sur GitHub

Le programme de la soirée :

  • 18:30 - Mot de bienvenue du TDS et Toulouse JUG

  • 19:00 - ElasticSearch, par David Pilato

  • 20:00 - ApĂ©ro Pizza + Boisson/Bière

Cette soirée est organisée en partenariat avec le Toulouse Data Science http://www.meetup.com/fr/Tlse-Data-Science/

L’entrée est libre à toutes les personnes.

Attention les places sont limitées (50 pour le TDS, 50 pour le JUG), RSVP obligatoire.

Catégories: Association

Reactive App sur Cluster Raspberry Pi – Mercredi 20 Mai à 19h

Alpes JUG - mar, 05/12/2015 - 19:09
​Tu es programmeur ? Tu veux être hype ? Tu veux écrire une application performante, scalable et résiliante ? Et si en plus on faisait tourner cette application sur un cluster de raspberry pi ?
DĂ©velopper une application monolithique, saturĂ©e de stacks entreprise, a dĂ©ployer dans de monstrueux cluster de JBoss sous amphĂ©tamines n’est pas forcĂ©ment l’approche idĂ©ale. Le reactive manifesto propose une approche plus modulaire permettant d’atteindre une meilleure scalabilitĂ© ainsi qu’une meilleure rĂ©silience. Mais ca c’est la thĂ©orie, comment parvenir a ce rĂ©sultat ? vers quelles technologies se tourner ? Quels sont les pièges a Ă©viter ? Cette session sera l’occasion de dissĂ©quer une application rĂ©active basĂ©e sur des micro services et de l’Event Sourcing avec des outils comme Cassandra, ElasticSearch, Play 2 ou encore Akka. Nous aurons alors l’occasion de vĂ©rifier si l’approche rĂ©active tient ses promesse lorsque le hardware est quelque peu contraint …​

Raspberry Pi

Infos pratiques

Inscriptions : https://plus.google.com/events/cgsisi54bu5pimr33ulf8jgbj3g

Les speakers : Mathieu ANCELIN et Alexandre DELEGUE (Serli)

Le lieu de la confĂ©rence : Orange Labs – 28 Chemin du Vieux ChĂŞne, 38240 Meylan

La date et l’heure : Mercredi 20 Mai Ă  19h

Nous terminerons comme d’habitude par un buffet gratuit.
Catégories: Association

Un jour Ă  Devoxx France 2015

devoxx15La 4ème Ă©dition de Devoxx France s’est dĂ©roulĂ©e du 08 au 10 Avril dernier au Palais des Congrès de Paris.
Ce fut une nouvelle fois un grand succès servit par une organisation irréprochable.

Présents côté speakers et côté spectateurs, nous vous proposons un retour sur les présentations qui nous ont marquées.
Vous aurez, d’ici quelques semaines, tout le loisir de les visionner sur la chaine dĂ©diĂ©e de Parleys et pourrez, nous n’en doutons pas, approfondir les notions que nous allons aborder dans cet article.

Ce retour sera découpé en deux parties:

  1. Nos coups de coeur ;
  2. nos favoris; comprendre les présentations desquelles il y a un ou plusieurs petits trucs à retirer.

Les premiers feront l’objet d’un rĂ©sumĂ© dĂ©taillĂ© tandis que les secondes vous donneront un aperçu plus court du sujet.

Nos coups de coeur Changing the wheels of a moving car (Conference) http://twitter.com/ndeloofPar Nicolas DE LOOF

Nicolas De Loof, architecte chez Cloudbees, est venu nous prĂ©senter un riche retour d’expĂ©rience sur cette startup qui, en quelques annĂ©es, est devenue un acteur important du as-a-Service.

Le contexte

Cloudbees s’est longtemps positionnĂ© comme un fournisseur de PAAS avant de complĂ©ter et de recentrer son offre autour du build-on-demand via Jenkins.

Cet outil est pour le moins particulier :

  • il dĂ©pend fortement du file system et de l’API liĂ©e ;

  • il existe environ 1200 plugins Ă  gĂ©rer ;

  • une application peut faire n’importe quoi, un build fait n’importe quoi !

La mutation

Son succès ne se dĂ©mentant pas, l’Ă©quipe technique a entamĂ© une longue mutation d’un Ă©tat dĂ©cousu Ă  un système bien rodĂ©.

En 2010, leur service reposait sur :

  • des nĹ“uds de builds isolĂ©s, recyclĂ©s entre plusieurs builds ;

  • des pools de machines de builds avec un GC Mark & Swap ;

  • des snapshots des builds prĂ©cĂ©dents.

2 ans plus tard, le système d’information s’articulait autour :

  • de LXC pour l’isolation des builds ;

  • d’un pool de machines via des conteneurs avec snapshots et affinitĂ© pour un serveur chaud (i.e. lancer les builds liĂ©s sur une mĂŞme machine).

La transition a été menée de manière douce :

  • feature toggles ;

  • rollout par tranches de 10%, 50% ;

  • rollout par typologie d’utilisateurs (comptes freemium) ;

  • rollout par remplacement naturel des serveurs.

Ce dernier point est primordial car, chez Cloudbees, terminer un serveur est une action quotidienne. Tout remplacement se fait via ce biais :

  • mise Ă  jour d’OS ;
  • patch de sĂ©curité ;
  • serveur fatigué ;
  • chaos monkey.

Les services sensibles sont gérés via la technique dite du Blue/Green deployment.

Les bonnes décisions et leçons apprises

Certains choix sont au dĂ©part des hacks et s’avèrent par la suite ĂŞtre judicieux et deviennent des core platform values. C’est le cas chez Cloudbees pour la terminaison de serveurs Ă  tout va ainsi que pour la mise en place d’une application REST en façade des services EC2 et d’un simulateur des Amazon Web Services (AWS).

Enfin, Nicolas a souligné 5 éléments essentiels dans la réussite de Cloudbees :

  1. Open-Sourcing : ouvrir son code, c’est obtenir des feedbacks rapides et parfois mĂŞme les corrections prĂŞtes Ă  ĂŞtre intĂ©grĂ©es. Ce fut le cas pour l’image Docker embarquant Jenkins.

  2. Continuous Delivery : le coĂ»t d’un changement est fonction de l’Ă©cart entre les dĂ©ploiements. Livrer souvent et par petits incrĂ©ments, c’est rĂ©duire ce coĂ»t et les risques liĂ©s.

  3. Near-to zero downtime : si une interruption est assez courte, l’utilisateur se plaindra sĂ»rement de sa connexion et ne se rendra mĂŞme pas compte du dĂ©ploiement. Ne visez pas le zero-downtime Ă  tout prix !

  4. Communication : ne cachez pas vos interruptions de service ou changements, soyez transparents sur vos Ă©checs et expliquez vos actions. C’est une marque de compĂ©tence fortement apprĂ©ciĂ©e par vos utilisateurs.

  5. Monitoring : il existe un rĂ©el besoin d’outils perspicaces afin d’identifier la bonne personne Ă  informer en fonction du problème constatĂ©. Il est important d’identifier les Ă©volutions des indicateurs Ă  plusieurs niveaux :

    1. Check engine (healthcheck) ;

    2. notifications, alertes ;

    3. analytics.

Note : Nicolas a beaucoup misĂ© sur sa tenue et nous tenons Ă  l’en fĂ©liciter.

Savoir faire le deuil de son code (Quickie) http://twitter.com/%40ElleneSiberhttp://uneviededev.com/Par Ellène SIBER DIJOUX

Dans ce format court, Ellène nous aide Ă  comprendre qu’il existe de fortes similitudes entre la vie de dĂ©veloppeur et la vie privĂ©e. Ainsi, les Ă©tapes d’un deuil, quelqu’il soit (disparition, rupture, etc.), sont applicables Ă  notre code lorsque survient un bug, en production de prĂ©fĂ©rence.

Ces étapes sont au nombre de sept :

  1. Etat de choc/dĂ©ni : c’est une dĂ©fense de l’esprit, aucun raisonnement n’est alors possible.

  2. Douleur et culpabilité : on cherche un moyen de compenser l’erreur commise, le plus sale soit-il.

  3. Colère : c’est un sentiment ressenti face Ă  l’injustice, qui peut nous pousser Ă  rejeter la faute sur les autres.

  4. Marchandage : c’est la chasse aux sorcières ; il nous faut un responsable !

  5. DĂ©pression/douleur : le bug est acceptĂ© mais l’on n’est pas en mesure d’y faire face ; on se trouve dans un Ă©tat passif et l’on souffre.

  6. Reconstruction : on cherche des activitĂ©s pour s’Ă©chapper, on demande de l’aide, on trouve des solutions plus propres.

  7. Acceptation : on se projette dans le futur ; les réalités de la vie sont enfin acceptées.

Dans beaucoup de cas, certains dĂ©veloppeurs s’arrĂŞtent Ă  l’Ă©tape 5 ce qui peut engendrer des abandons de carrière voire une dĂ©motivation qui se retrouve tĂ´t ou tard dans la qualitĂ© du code produit.

Pour faire face Ă  la douleur, il est donc nĂ©cessaire de comprendre ces Ă©tapes. Il s’agit d’Ă©viter les dĂ©cisions radicales prises sous le coup d’une Ă©motion. Il faut apprendre Ă  parler, Ă  se confier afin de laisser retomber les sentiments et de pouvoir agir rationnellement. Enfin, il s’agit de ne pas prendre les choses trop Ă  cĹ“ur ou trop personnellement. Il ne s’agit pas de vous, il s’agit de votre code (cf. la carte Xebia Essentials « No Blame But No Mercy »).

Tolérance aux pannes avec le Circuit Breaker Pattern (Quickie) http://twitter.com/mouloumouhcinehttps://plus.google.com/110066041990480342851/postsPar Mouhcine MOULOU

Nombreuses sont les applications qui, aujourd’hui, doivent s’interfacer avec des services externes. Avec l’avènement des conteneurs (mais pas que !), la scalabilitĂ© n’est dĂ©sormais plus un rĂŞve lointain. Mais pour ĂŞtre scalable, il faut ĂŞtre tolĂ©rant aux pannes. Or, on ne peut prĂ©tendre stabiliser des services dont on n’a pas la charge. Que faire si ces derniers, par exemple, ne tiennent pas nos pics de charge ?

Les consĂ©quences en cas d’indisponibilitĂ© sont subies et dĂ©sagrĂ©ables :

  • gaspillage des ressources (CPU, mĂ©moire) ;

  • appels plus longs car souvent bloquants (timeout) ;

  • cascading failure : la chute d’un service entraine la chute d’autres qui en dĂ©pendent.

Pour faire face Ă  ce type de situations, Mouhcine Moulou (sociĂ©tĂ© Soat) nous a prĂ©sentĂ© le Circuit Breaker Pattern. Son crĂ©do : s’il faut Ă©chouer, alors Ă©chouons vite ! Il agit en fait comme un disjoncteur entre le service appelant et le service appelĂ©.

Par défaut, le Circuit Breaker est fermé ; les requêtes sont donc possibles. Si certains critères sont atteints (erreurs, temps de réponse), alors il est ouvert et plus aucune requête ne passe, évitant ainsi les désagréments évoqués précédemment.

Après un certain temps, le Circuit Breaker repasse dans un état semi-ouvert ; il laisse passer un ou quelques appel(s) afin de déterminer la santé du service. Si le service est de retour, le Circuit Breaker repasse au statut fermé. Sinon, il redevient ouvert.

Ainsi cette solution permet :

  • des temps de rĂ©ponses rapides, mĂŞme en cas d’erreur ;

  • un meilleur usage des ressources ;

  • une diminution des cascading failures ;

  • un monitoring plus aisĂ©, puisqu’Ă  poser sur le Circuit Breaker.

Plusieurs implémentations sont disponibles, notamment en Scala & Java via Akka, où subsistent néanmoins quelques inconvénients.

Le Continuous Merge chez LesFurets.com (Conference) http://twitter.com/ArnaudPfliegerhttps://github.com/lesfurets/git-octopusPar Arnaud PFLIEGER

Arnaud Pflieger est venu nous prĂ©senter la manière dont a Ă©tĂ© mis en place le Continuous Delivery chez LesFurets.com, cĂ©lèbre comparateur d’assurances.

Lorsque l’on parle de Continuous Delivery (voir cette prĂ©sentation d’Axel Fontaine sur le sujet), on pense souvent au modèle TBD (Trunk Based Development/Deployment/Delivery). Le principe est simple ; tout se passe sur la branche master (ou trunk). Chaque commit donne lieu Ă  un build, Ă  toute une batterie de tests automatisĂ©s et in-fine, Ă  un dĂ©ploiement. Or, selon Arnaud, ce modèle possède quelques inconvĂ©nients :

  • le volume des tests automatisĂ©s requis pour s’assurer un dĂ©ploiement serein est important. Une mise en place incrĂ©mentale est donc difficile ; tout doit ĂŞtre prĂŞt pour la première MEP ;

  • idem avec l’automatisation des dĂ©ploiements ;

  • le nombre de feature toggles devient vite important et attĂ©nue la maintenabilitĂ© de l’application.

Si l’on peut ĂŞtre plus ou moins d’accord avec ces constatations, toujours est-il qu’elles ont poussĂ© LesFurets Ă  partir sur un modèle Ă  base de feature branches, oĂą l’une des règles principales est que personne ne commite dans le master. Quelques statistiques les concernant :

  • 1 MEP par jour ;

  • entre 3 et 10 feature branches par MEP ;

  • entre 40 et 70 feature branches en cours.

Arnaud nous avoue que l’Ă©quipe a longtemps planchĂ© sur la technique a utiliser pour rĂ©concilier toutes ces branches sans retomber sur le modèle TBD. Pour ce faire, LesFurets ont dĂ©veloppĂ© un script qu’ils ont par la suite publiĂ© en Open Source ; git octopus.

Octopus se charge de fusionner plusieurs branches en une seule, en se basant sur la commande git merge. Les branches Ă  fusionner peuvent ĂŞtre filtrĂ©es selon un pattern particulier, par exemple, toutes celles commençant par feature-. La branche rĂ©sultante est systĂ©matiquement recrĂ©Ă©e Ă  chaque fusion ; elle ne possède donc toujours qu’un seul commit. En se basant sur cet outil, LesFurets ont mis en place le workflow suivant :

Tout dĂ©veloppement donne lieu Ă  une nouvelle branche en local (ticket-x), tirĂ©e depuis master. Une fois ce dernier terminĂ©, la branche est poussĂ©e vers le repository features oĂą Octopus passe rĂ©gulièrement pour fusionner toutes les branches de cet environnement. Cela permet de lancer la batterie de tests automatisĂ©s sur le rĂ©sultat de la fusion. Les branches qui sont alors souhaitĂ©es en production sont poussĂ©es sur le respository releases oĂą, lĂ  encore, Octopus se charge d’en faire la fusion (en incluant la branche master) et de lancer la batterie de tests (automatisĂ©s et manuels) sur le rĂ©sultat. Si ces derniers sont satisfaisants, alors l’unique commit de la branche octopus-releases est fusionnĂ© Ă  la branche master.

Bien évidemment, les conflits peuvent surgir lors de la fusion des branches et dans ce cas, Octopus démarre une phase de diagnostic. Il va tenter de fusionner chaque branche individuellement avec la courante afin de déterminer laquelle est en conflit.

Note : ce processus de dĂ©tection n’est pas sans faille ; voir le site de git octopus pour plus de dĂ©tails.

Dans tous les cas, une résolution manuelle est nécessaire. Chez LesFurets, cela consiste le plus souvent :

  • Ă  retirer des branches non-indispensables (refactoring, reformatage) ;

  • Ă  sortir temporairement la branche fautive de la fusion ;

  • Ă  positionner une branche devant l’autre (via un git rebase).

En conclusion, nous avons pu nous apercevoir qu’il Ă©tait possible de faire du Continuous Delivery sans faire de TBD, ceci permettant de maitriser plus sereinement le rythme des MEP. En revanche, quelques inconvĂ©nients sont Ă  noter :

  • une (très) bonne maĂ®trise de git est nĂ©cessaire ;

  • la gestion des conflits reprĂ©sente le SPOF (Single Point Of Failure) de cette mĂ©thode et peut donner lieu Ă  la rĂ©Ă©criture d’un historique partagĂ© ce qui est très souvent dĂ©conseillé ;

  • la mĂ©thode s’applique très bien Ă  une application monolithe, beaucoup moins Ă  une architecture micro-services.

En tout cas, LesFurets ont fait preuve d’une belle transparence dans leurs choix, bons comme mauvais et nous ont offert lĂ  un nouvel Ă©lĂ©ment pour atteindre le Continuous Delivery.

Nos favoris De l’API au protocole (Conference) http://twitter.com/gcoupriehttp://geoffroycouprie.com/Par Geoffroy COUPRIE

Dans une confĂ©rence d’une richesse rare, Geoffroy nous invite Ă  nous interroger sur l’usage que nous faisons des protocoles afin de bâtir nos API. Il souligne l’importance de mesurer l’adĂ©quation des technologies utilisĂ©es avec le contexte dans lequel on se trouve. Selon lui, il nous faut choisir plutĂ´t que subir les choix des autres. Si, par exemple, vous ne jurez que par REST/HTTP/TCP et dĂ©testez SOAP/CORBA and co., attendez-vous Ă  ĂŞtre sacrĂ©ment secouĂ©s dans vos convictions. A ne manquer sous aucun prĂ©texte.

Unit testing concurrent code (Quickie) http://twitter.com/rafaelcodeshttps://plus.google.com/109266851795683366529/postsPar Rafael WINTERHALTER

Dans ce Quickie, Rafael se propose de rĂ©soudre un dĂ©fi loin d’ĂŞtre simple ; tester un code concurrent en Ă©tant le plus dĂ©terministe possible. A travers une sĂ©rie d’exemples, il nous prĂ©sente les outils existants pour ce faire (TestNG, ThreadWeaver, jcstress), leurs fonctionnements, leurs points forts et les pièges dans lesquels ils peuvent nous faire tomber (ah, sacrĂ© Java Memory Model!). Une prĂ©sentation constituant un bon point d’entrĂ©e pour quiconque souhaite s’intĂ©resser au sujet.

Uniformisez vos postes de développement avec Fig (Quickie) http://twitter.com/etiennepeiniauhttps://www.linkedin.com/in/etiennepeiniau/frPar Etienne PEINIAU

A travers un aperçu de Docker Compose (Fig ayant passĂ© l’arme Ă  droite depuis), Etienne nous propose une solution simple pour unifier et accĂ©lĂ©rer l’installation des postes de dĂ©veloppement. Il revient sur les principes mis en Ĺ“uvre (orchestration de conteneurs), sur la configuration pour ce faire (fichier YAML) ainsi que sur les avantages obtenus. Il livre en complĂ©ment quelques astuces pour Ă©viter les pièges les plus simples, comme par exemple, le partage du repository Maven pour ne pas tout recharger Ă  chaque lancement. Une prĂ©sentation efficace et applicable dès le lendemain pour se faciliter la vie ainsi que celles de ses collègues.

API asynchrones en Java 8 (Conference) http://twitter.com/JosePaumardhttp://blog.paumard.org/Par José PAUMARD

Outre les lambdas, streams, API Date et autres joyeusetĂ©s, Java 8 nous a Ă©galement apportĂ© de nouveaux outils pour faire de l’asynchrone. Dans cette prĂ©sentation, Jose Paumard nous livre un rappel sur l’existant avant cette version et dĂ©roule la JavaDoc des classes CompletionStage et CompletableFuture (l’Ă©quivalent des ListenableFuture dans Guava). IdĂ©al pour dĂ©buter sur le sujet, beaucoup moins si vous en ĂŞtes dĂ©jĂ  familiers.

Les idĂ©es reçues dans l’informatique (Conference) http://twitter.com/lcinquinPar Ludovic CINQUIN

Dans un format confĂ©rence qui aurait gagnĂ© Ă  ĂŞtre plus court, le directeur gĂ©nĂ©ral d’Octo nous prĂ©sente 8 idĂ©es reçues de l’informatique puis les contredit, chiffres et lois Ă  l’appui.
Les sujets abordés tournent autour des livraisons, de la productivité, de la maintenance, des primes, de la localisation des équipes, de la taille des projets et du coeur de métier des entreprises.

Building fault tolerant microservices (Conference) http://twitter.com/chbateyPar Christopher BATEY

Dans cette conférence, Christopher nous présente les points auxquels il faut faire attention pour avoir un service qui soit tolérant à la panne. Pour savoir si votre service l’est, il n’y a pas de secret : il faut tester ! Pour cela, Christopher utilise plusieurs outils : Cucumber pour formaliser ses tests d’acceptance et Vagrant, Saboteur ainsi que Wiremock pour simuler le service tiers que doit appeler notre service à tester. En combinant tout ça, on simule facilement des réponses inattendues ou des erreurs réseaux. On peut alors prédire le fonctionnement de notre système sur ces problématiques. De la gestion des timeouts et des threads, au monitoring avec Zipkin ou Graphite, en passant par l’utilisation de librairies tel que Hystrix, vous aurez un tour d’horizon complet des solutions qui s’offrent à vous.

Web Components, Polymer and Material Design (Conference)  http://twitter.com/LostInBrittanyPar Horacio GONZALEZ

L’entrĂ©e en matière de cette confĂ©rence est originale : Horacio commence par dire que finalement les Web Components ne sont pas nouveaux car Swing faisait la mĂŞme chose. Quand il a quittĂ© le monde du client lourd pour le web, il passait d’une interface utilisateur Ă©voluĂ©e et rĂ©active Ă … une jsp sans style et qui ne faisait pas grand chose. On Ă©tait en 2000. Ensuite le web a rattrapĂ© son retard avec JEE, Javascript, GWT et enfin les single page application et leur librairies comme AngularJS et sa notion de directive qui se rapproche des web components. On assiste ensuite Ă  un passage en revue assez exhaustif de tout ce que les navigateurs implĂ©mentent ou implĂ©menteront pour passer aux Web Components : templates, shadow DOM, elements, imports. On est rassurĂ©s car pour une fois, la standardisation ne s’est pas faite dans la douleur et on a rĂ©ellement l’impression que les vendeurs voulaient coopĂ©rer.

I don’t always write Reactive applications, but when I do, it runs on Raspberry Pi (Conference) http://twitter.com/chankslerouxPar Alexandre DELEGUE http://twitter.com/TrevorReznikPar Mathieu ANCELIN

Le sujet de l’application rĂ©active que Mathieu et Alexandre nous prĂ©sente est très sĂ©rieux : fournir Ă  la planète entière l’application indispensable lorsque les zombies attaqueront. Ce sujet très alternatif est le fil rouge de cette prĂ©sentation. On nous prĂ©sente l’architecture mise en place pour faire tourner un site soumis Ă  une charge constante durant la confĂ©rence – mĂ©triques Ă  l’appui – et hĂ©bergĂ©e sur 7 Raspberries. C’est fou ce que ces petites machines peuvent faire tourner : Elastic Search, Cassandra, NGINX ou encore Akka Cluster. En une heure, nous n’avons Ă©videmment pas le temps de nous attarder sur le code mais il est disponible sur github pour Ă©tudier tout cela Ă  posteriori. Le clou de la dĂ©monstration est le dĂ©branchement de certains Raspberry et la constatation de la dĂ©gradation du service mais sans interruption franche : le rĂ©el intĂ©rĂŞt des applications rĂ©actives.

Priming Java for Speed (Conference) http://twitter.com/giltenePar Gil TENE

Après avoir rĂ©glĂ© le problème des pauses du garbage collector, Gil a demandĂ© Ă  ses clients quel Ă©tait la deuxième chose la plus ennuyeuse avec la JVM. Il se trouve que beaucoup d’entre eux se plaignaient d’un temps de dĂ©marrage peu efficace. En rĂ©alitĂ© plus que du dĂ©marrage (cĂ´tĂ© serveur, on peut faire chauffer sa JVM comme on le souhaite), c’est plutĂ´t le moment oĂą on sollicite dans les conditions de production une JVM chauffĂ©e qui pose problème. En effet, si on prend le cas d’un système de trading, Ă  l’ouverture du marchĂ©, de nombreuses optimisations effectuĂ©es par la JVM (rĂ©ordonnancement, suppression du code mort, des variables locales, des constantes, de l’inlining, etc.) sont annulĂ©es car les donnĂ©es changent et deviennent moins prĂ©dictibles puisqu’il s’agit des vraies donnĂ©es. Or c’est bien Ă  l’ouverture du marchĂ© qu’on a besoin de notre bytecode optimisĂ©. Gil nous explique donc que la stratĂ©gie de sa JVM consiste Ă  logger toutes les optimisations avec du contexte pour expliquer pourquoi elles sont faites Ă  l’instant t afin de pouvoir les rejouer au redĂ©marrage d’une JVM. Plus besoin de temps de chauffe : votre algorithme a dĂ©jĂ  une performance maximum dès l’ouverture du marchĂ©.

Conclusion

Ce retour ne saurait être complet sans la session des Cast Codeurs, enregistrée le vendredi soir et animée par Guillaume Laforge, Emmanuel Bernard, Antonio Goncalves, Arnaud Héritier ainsi que Vincent Massol. Un moment de franche rigolade, de partage et de nostalgie bien mérité après 3 jours de dure labeur.

Catégories: Blog Société

Files MQ : Notions et Outils

 Notions et Outils Actuellement, les systèmes d’information doivent rĂ©pondre Ă  plusieurs problĂ©matiques dont l’une des plus importantes est d’ĂŞtre accessible par le plus grand nombre de vecteurs possibles. Certains de ces systèmes sont parfois anciens et se voient donc attribuĂ© une surcharge logicielle...
Catégories: Blog Société

Mix-IT 2015 - Jour 1

Zenika - mar, 05/12/2015 - 10:05

Mix-IT, c'est deux journĂ©es de rencontres et dĂ©couvertes, des prĂ©sentations de sujets techniques et agiles ainsi que des ateliers pratiques. L'Ă©vĂ©nement lyonnais est organisĂ© par une Ă©quipe de choc : membres du Lyon JUG et CARA, bĂ©nĂ©voles et mĂŞme professionnels de la gastronomie ! Toutes les conditions Ă©taient rĂ©unies pour nous offrir un programme sur mesure lors de cette cinquième Ă©dition, du 16 au 17 Avril 2015. Voici un retour sur les confĂ©rences et ateliers de la première journĂ©e auxquels nous avons pu participer (le programme de la deuxième journĂ©e est dans un autre billet).

DSC_0351.jpg

The Three Ages of Innovation Keynote d'ouverture - par Dan North (slides) Dan North n'est autre que le créateur du BDD (Behaviour-Driven Development). Conférencier invétéré, il est aussi coach, développeur et consultant, activités qu'il exerce depuis les vingt dernières années. Il nous explique que l'Innovation est définie par les trois étapes... Read Mix-IT 2015 - Jour 1

Catégories: Blog Société

Les outils de la Data Science : Spark MLlib, théorie et concepts (1/2)

Dans deux précédents articles nous vous présentions R et Python et comment ils sont utilisés en Data Science. La limite de ces langages est cependant rapidement atteinte lorsque l’on a affaire à de gros jeux de données qui ne tiennent plus en mémoire. Dans ce cas là, la solution à envisager est de distribuer les calculs sur un cluster de plusieurs machines, avec l’idée fondatrice de porter l’algorithme vers les données et non l’inverse.

La librairie Mahout permettait de faire cela sur un cluster Hadoop en utilisant MapReduce. Cependant, les limites de cette librairie ont vite été atteintes. Par nature, la plupart des algorithmes de Machine Learning sont itératifs: plusieurs passages sur les données sont nécessaires, générant ainsi de nombreux jobs MapReduce et beaucoup de lecture/écriture sur disque. Avec l’apparition de Spark, et de sa librairie de Machine Learning associée MLlib, ces contraintes se sont envolées, améliorant drastiquement les performances obtenues.

Cet article a pour but de prĂ©senter et de comprendre MLlib sous un angle plus thĂ©orique, et sera suivi d’un second article le prĂ©sentant sous un aspect plus pratique avec une utilisation des principaux algorithmes de Machine Learning. Nous allons donc voir ici les spĂ©cificitĂ©s de MLlib, Ă  savoir son fonctionnement global, le type de donnĂ©es qu’elle requiert, ainsi que le mode de construction des algorithmes. Toutes ces notions sont importantes pour utiliser MLlib de manière optimale.

Petit rappel de Machine Learning

Pour employer de manière efficace MLlib, il est bien entendu nĂ©cessaire d’avoir quelques bases en Machine Learning. Le Machine Learning est une branche de l’Intelligence Artificielle qui permet l’analyse et la construction d’algorithmes capables d’apprendre Ă  partir de donnĂ©es d’entrĂ©e. On peut distinguer deux catĂ©gories principales d’algorithmes: de type supervisĂ© ou non supervisĂ©. 

En apprentissage supervisĂ©, on dispose d’un dataset composĂ© de caractĂ©ristiques (features) associĂ©es Ă  des labels (target). L’objectif est de construire un estimateur capable de prĂ©dire le label d’un objet Ă  partir de ses features. L’algorithme apprend alors Ă  partir de donnĂ©es dont on connait le label et est ensuite capable de faire de la prĂ©diction sur de nouvelles donnĂ©es dont on ne connaĂ®t pas le label. On distingue les algorithmes de classification, pour lesquels le label Ă  prĂ©dire est une classe (prĂ©dire un mail comme Ă©tant spam / non spam), de ceux de rĂ©gression, pour lequels il faut prĂ©dire une variable continue (prĂ©dire la taille d’une personne en fonction de son poids et de son âge par exemple). En apprentissage non-supervisĂ©, on ne dispose pas de label pour nos donnĂ©es. L’objectif est alors de trouver des similaritĂ©s entre les objets observĂ©s, pour les regrouper au sein de clusters.

On peut de plus citer les algorithmes dĂ©diĂ©s aux systèmes de recommandation (collaborative filtering), ainsi que l’apprentissage par renforcement, qui regroupe un ensemble d’algorithmes qui vont faire leurs prĂ©dictions en apprenant de leurs erreurs au fur et Ă  mesure, et s’adapteront aux Ă©ventuels changements.

Rapide tour d’horizon de Spark

Spark est un framework d’analyse de données né il y a un peu plus de 5 ans à l’AMPLab de l’UC Berkeley. Il est désormais géré par Databricks, entreprise fondée par les développeurs à l’origine du projet. Il est devenu un projet de la fondation Apache en juin 2013 et a obtenu le label “Apache Top-Level Project” en février 2014. Il réunit aujourd’hui plus de 200 contributeurs venant de plus de 50 entreprises telles que Yahoo ! ou Intel. Spark s’est appuyé sur le framework Hadoop, déjà existant et très utilisé, en utilisant le système de fichiers distribués de ce dernier, HDFS, et le gestionnaire de ressources YARN, permettant d’exécuter des programmes Spark sur Hadoop. Cependant, à la différence d’Hadoop, Spark ne se limite pas au paradigme MapReduce et promet des performances jusqu’à 100 fois plus rapide. L’origine de ces performances : la montée en mémoire. Là où Hadoop lit les données sur des disques durs, Spark peut les monter en mémoire et gagner ainsi énormément en rapidité.

Les API et les projets attenants

Spark possède 3 API : en Scala, Python et Java. Pour les deux premiers langages il propose une interface en ligne de commande qui permet une exploration rapide et interactive des données. La version 1.4 de Spark prévue pour Juin 2015 inclura en plus une API R. Plusieurs projets se greffent au dessus de Spark : Spark SQL qui permet d’exécuter des requêtes SQL sur des RDD (Résilient Distributed Datasets) et contient l’API des DataFrames (collection de données organisée en colonnes, très utilisé en Data Science), Spark Streaming pour l’analyse de données en temps réel, GraphX pour l’exécution d’algorithmes de graphes et donc MLlib, la librairie de machine learning.

Les Resilient Distributed Datasets

Le Resilient Distributed Dataset (RDD) est un concept créé par les fondateurs de Spark. C’est sous ce format que sont gérées les données en Spark. Les RDD sont des collections immutables. Par défaut, lors de la lecture d’un fichier, les données sont manipulées sous forme d’un RDD de String où chaque élément correspond à un ligne du fichier. Il est ensuite possible de d’effectuer des opérations sur le RDD. Il en existe deux sortes :

  • Les transformations : elles transforment un RDD en un autre RDD (map, filter, reduceByKey)

  • Les actions : elles transforment un RDD en une valeur (count, collect …)

Il est important de noter que les transformations sont “lazy”, c’est-Ă -dire que Spark n’exĂ©cutera les calculs demandĂ©s que si une action est appliquĂ©e Ă  un RDD.

  rdd.png/>


NB: Dans cette prĂ©sentation, nous allons principalement prĂ©senter MLlib via l’API Scala, qui est l’API de base. Cependant, les utilisateurs des autres APIs pourront facilement s’y retrouver car l’utilisation de la librairie est relativement semblable pour tous les langages. Nous considĂ©rons de plus que l’utilisateur possède dĂ©jĂ  une connaissance minimale de Spark et des RDDs, l’objectif Ă©tant de les utiliser dans MLlib.

MLlib: Une librairie optimisée pour le calcul parallélisé

MLlib est la librairie de Machine Learning de Spark. Tous les algorithmes de cette librairie sont conçus de manière Ă  ĂŞtre optimisĂ©s pour le calcul en parallèle sur un cluster. Une des consĂ©quences directes Ă  cela est que, pour de petits datasets qui tiennent en mĂ©moire, un algorithme lancĂ© depuis Spark en local sur votre machine mettra beaucoup plus de temps Ă  s’exĂ©cuter que le mĂŞme algorithme lancĂ© depuis Python ou R, qui sont optimisĂ©s pour le mode local. En revanche, les performances deviennent extrĂŞmement intĂ©ressantes lorsque les volumĂ©tries sont très importantes.

MLlib a été conçu pour une utilisation très simple des algorithmes en les appelant sur des RDD dans un format spécifique, quel que soit l’algorithme choisi. L’architecture se rapproche ainsi de ce que l’on trouve dans la librairie scikit-learn de Python, bien qu’il y ait encore des différences notables qui vont être effacées dans les prochaines versions de l’API.

Les algorithmes présents dans MLlib sont, tout comme le reste du framework, développés en Scala, en se basant principalement sur le package d’algèbre linéaire Breeze pour l’implémentation des algorithmes. De plus, pour faire fonctionner MLlib, il est nécessaire d’installer gfortran, ainsi que Numpy si vous utilisez l’API Python.

 Les types de données spécifiques à MLlib

L’une des spĂ©cificitĂ©s de MLlib (et peut-ĂŞtre une de ses faiblesses pour le moment) est qu’il nous contraint Ă  utiliser des RDD aux types spĂ©cifiques. Les algorithmes implĂ©mentĂ©s nĂ©cessitent ainsi en entrĂ©e des RDD[Vector] (pour des donnĂ©es n’ayant pas de label), des RDD[LabeledPoint] (spĂ©cifiques Ă  l’apprentissage supervisĂ©) ou bien des RDD[Rating] (pour les systèmes de recommandation).

Vector

Les Vector sont de simples vecteurs de doubles. MLlib supporte deux types de Vector : dense (chaque entrée doit être spécifiée) et sparse (seules les entrées non nulles, avec leurs positions, doivent être spécifiées).

import org.apache.spark.mllib.linalg.{Vector, Vectors}

// Create a dense vector (1.0, 0.0, 3.0).
val dv: Vector = Vectors.dense(1.0, 0.0, 3.0)
// Create a sparse vector (1.0, 0.0, 3.0) by specifying its indices and values corresponding to nonzero entries.
val sv1: Vector = Vectors.sparse(3, Array(0, 2), Array(1.0, 3.0))

 Une remarque importante: Contrairement à ce que son nom peut sembler l’indiquer, l’objet Vector ne donne accès à aucune opération arithmétique quand ils sont utilisés en Scala ou en Java. Il correspond simplement à une représentation particulière de la donnée afin d’uniformiser l’utilisation des algorithmes.

LabeledPoint

Ce type de donnĂ©e est spĂ©cifique aux algorithmes d’apprentissage supervisĂ©, pour lesquels il est nĂ©cessaire de spĂ©cifier le label correspondant Ă  chaque vecteur pour la phase d’apprentissage. Un LabeledPoint est composĂ© d’un vecteur, dense ou sparse, associĂ© Ă  un label.

Le label est obligatoirement un double, ce qui permet d’utiliser à la fois des algorithmes de classification ou de régression. Pour la classification, le label doit obligatoirement prendre comme valeurs 0, 1, 2, 3, …, en commençant toujours par 0.

Une fois en prĂ©sence d’un LabeledPoint, il est possible d’accĂ©der au label correspondant via l’attribut .label, ainsi qu’au Vector via l’attribut .features.

import org.apache.spark.mllib.linalg.Vectors
import org.apache.spark.mllib.regression.LabeledPoint

// Create a labeled point with a positive label and a dense feature vector.
val pos: LabeledPoint = LabeledPoint(1.0, Vectors.dense(1.0, 0.0, 3.0))

// Create a labeled point with a negative label and a sparse feature vector.
val neg: LabeledPoint = LabeledPoint(0.0, Vectors.sparse(3, Array(0, 2), Array(1.0, 3.0)))
 
// Get the label and the features corresponding to the LabeledPoint
val label: Double = neg.label
val features: Vector = neg.features
Rating

Une donnée de type Rating est exclusivement utilisée dans le cadre du collaborative filtering, qui est un algorithme utilisé classiquement dans les systèmes de recommandation. Un Rating n’est autre qu’un tuple contenant trois éléments :

  • User: Un entier reprĂ©sentant un utilisateur

  • Item: Un entier reprĂ©sentant un item

  • Rating: Un double reprĂ©sentant la note qu’a donnĂ© User Ă  Item
import org.apache.spark.mllib.recommendation.Rating
 
// Create a rating corresponding to User 4, which gave to Item 7 a rating of 3
val rating = Rating(4, 7, 3.0) 

NB: Dans les prochaines version de Spark, ces contraintes sur les types de données vont être relâchées. Les algorithmes prendront alors en entrée des DataFrames, introduites dans la version 1.3, ce qui les rapprocheront encore plus du fonctionnement rencontré sous Python ou R.

L’architecture des algorithmes Les algorithmes

Que ce soit pour de la classification, de la régression, du clustering ou autre, tous les algorithmes possèdent leur propre classe (voire même plusieurs selon leur type d’implémentation). La démarche est alors la suivante:

  • Instancier la classe

  • Appeler les setters associĂ©s pour modifier les paramètres (qui sont relatifs Ă  l’algorithme en question)

  • Appeler la mĂ©thode run() sur un RDD pour entraĂ®ner le modèle

Cependant, pour de nombreux algorithmes (souvent les principaux utilisés), il est aussi possible d’utiliser des méthodes statiques au lieu de la classe avec les setters. Il suffit alors d’appeler la méthode train() contenue dans l’Object associé à l’algorithme qui prend comme entrées un RDD, ainsi que tous les paramètres nécessaires. Cette manière de faire est beaucoup plus proche des implémentations classiques en Python ou R, et est donc à prioriser lorsque c’est possible.

Dans tous les cas, une fois que l’algorithme est entraîné, il retourne un objet “Model”.

NB: L’API Java a exactement le même fonctionnement que celle en Scala pour la construction des algorithmes. En Python, on utilise systématiquement la méthode train().

Les classes Model

Chaque algorithme de MLlib, une fois entraîné sur des données, retourne un objet Model, qui va typiquement posséder une méthode predict(). Cette méthode va permettre d’appliquer le modèle à une nouvelle donnée ou un nouveau RDD de données pour prédire une valeur.

Prenons l’exemple de la Régression Logistique, qui est un algorithme de classification binaire qui identifie un hyperplan séparant au mieux les deux classes. L’algorithme va donc prendre en entrée un RDD[LabeledPoint] et retourner un LogisticRegressionModel qui va pouvoir prédire la classe de nouvelles données grâce à sa méthode predict(), comme le montre le schéma ci-dessous.

MLlib_algorithm.jpg Construire une chaîne de traitement de données en MLlib

En pratique, la démarche globale pour construire une pipeline de traitement de données en MLlib est la suivante:

  • Charger les donnĂ©es Ă  traiter dans un RDD

  • Transformation des donnĂ©es pour obtenir un RDD[Vector] ou un RDD[LabeledPoint] utilisable par un algorithme de MLlib

Cette Ă©tape est plus gĂ©nĂ©ralement appelĂ©e Feature Engineering. Elle regroupe tout le travail de nettoyage, de gestion des outliers et des donnĂ©es manquantes et de crĂ©ation de nouvelles features, puis de transformation au bon format de RDD requis par MLlib. Cette partie est la plus longue et Ă  la fois la plus intĂ©ressante de la dĂ©marche en Data Science car elle implique une rĂ©flexion sur la signification des donnĂ©es et permet, lorsqu’elle est pertinente, d’amĂ©liorer grandement les performances des algorithmes. 

  • SĂ©lection et entraĂ®nement d’un algorithme Ă  l’aide des mĂ©thodes run() ou train() sur le RDD crĂ©Ă©

  • PrĂ©dictions sur de nouvelles donnĂ©es grâce Ă  la mĂ©thode predict() du Model rĂ©sultant de l’étape prĂ©cĂ©dente

Dans le cas d’application de modèles supervisĂ©s (classification ou rĂ©gression), une Ă©tape supplĂ©mentaire est fortement recommandĂ©e avant l’entraĂ®nement de l’algorithme: la sĂ©paration du RDD en train et test sets. L’algorithme va alors ĂŞtre entraĂ®nĂ© uniquement sur le train set, alors que le test set va ĂŞtre utilisĂ© afin de valider les performances du modèle crĂ©Ă© (le test set correspond alors Ă   des “nouvelles donnĂ©es”, au sens oĂą l’algorithme ne les a pas utilisĂ©es pour s’entraĂ®ner, dont on connaĂ®t la vĂ©ritable valeur que l’on souhaite prĂ©dire). Cela permet notamment de tuner les paramètres pour amĂ©liorer les capacitĂ©s de gĂ©nĂ©ralisation de l’algorithme Ă  de nouvelles donnĂ©es.

La figure ci-dessous illustre la démarche complète de création d’une pipeline de traitement de données dans le cas d’un apprentissage supervisé.

MLlib_supervised_pipeline.jpg

Dans un cas non-supervisé (classiquement pour des tâches de clustering), nous n’avons pas de notion de variable à prédire. On utilise donc un RDD de Vector, et l’apprentissage se fait sur toutes les données disponibles, sans l’étape de splitting.

Remarque sur la taille des datasets

Il n’est cependant pas rare que le dataset sur lequel on souhaite entraîner l’algorithme ne soit pas très volumineux. Il peut en effet arriver d’être en possession d’une volumétrie très importante de données brutes qui nécessitent un pré-traitement en Spark (fichiers de logs par exemple), et qu’une fois ce traitement effectué, les données agrégées puissent passer en mémoire. Il est alors recommandé de passer à une librairie optimisée pour le calcul sur un seul noeud.

Il est notamment très facile de jongler de la sorte si vous utilisez l’API Python de Spark, appelée PySpark: Utiliser PySpark pour tous les pré-traitements sur les grosses volumétries jusqu’à obtenir un dataset qui tienne mémoire, puis transformer le RDD en Data Frame Pandas ou en Array Numpy et utiliser scikit-learn. De même, si vous cherchez à faire un grid-search pour tester différents paramètres pour un même algorithme, il peut être intéressant de faire un parallelize() sur la liste de paramètres et d’utiliser une librairie comme scikit-learn sur chaque noeud lorsque la volumétrie le permet. Si cependant la volumétrie après traitement de la donnée reste trop importante, alors MLlib est de loin le plus adapté.

Conclusion

Nous avons maintenant toutes les cartes en main pour appliquer les concepts de MLlib sur des cas concrets. Dans le prochain article, nous présenterons les différents packages présents dans MLlib pour construire des algorithmes de Machine Learning, et donnerons plusieurs exemples pratiques.

Catégories: Blog Société

Second anniversaire du PerfUG : Nginx et JVM Off-Heap (Architecture NUMA)

Pour son anniversaire, l’Ă©quipe du PerUG vous invite Ă  venir souffler sa deuxième bougie au cours d’une soirĂ©e spĂ©ciale ! Comme Ă  l’accoutumĂ©e, cette session sera animĂ©e pour sa première partie par un Octo suivi par une deuxième session exceptionnelle.

 

Bastien Fiorentino, consultant spĂ©cialisĂ© en architectures rĂ©actives Ă  OCTO Technology, nous fera le retour d’expĂ©rience d’une mission visant Ă  rĂ©pondre Ă  la problĂ©matique « Comment accĂ©lĂ©rer votre site web pour vos utilisateurs aux quatre coins du monde ? ». Il sera prĂ©sentĂ© l’architecture finale mise en place et la rĂ©flexion menĂ©e pour y parvenir ainsi que les problèmes rencontrĂ©s. Latence rĂ©seau, cache, TCP/SPDY, VPN feront partie des sujets abordĂ©s !

 

Gaëlle Guimezanes travaille chez Quartet FS qui développent une base de données en mémoire pour l’analyse multidimensionnelle. Leur solution est écrite en Java, et qui dit Java dit Garbage Collector qui peut poser problème sur les très gros volumes de données… On parlera off-heap (ou comment gérer plusieurs Téraoctets de données dans la JVM sans que le Garbage Collector s’en mêle). Les serveurs puissants disposant de plusieurs Téraoctets de mémoire ont souvent des architectures particulières, qui ont des impacts sur les performances. Ainsi de manière plus générale, nous parlerons d’accès mémoire non uniforme, mieux connu sous l’acronyme NUMA !

 

La session aura lieu le 21 mai dans les locaux d’OCTO Technology.
Inscriptions et informations sur Meetup. Cette session sera suivie d’un pot dans les locaux d’Octo.

Articles suggested :

  1. Compte-rendu du Performance User Group #3
  2. PerfUG : DynaTrace pour monitorer tous vos problèmes de performance
  3. PerfUG : Phaser et StampedLock Concurrency Synchronizers

Catégories: Blog Société

Best practices: key factor to a successful JIRA implementation

Le blog de Valiantys - lun, 05/11/2015 - 10:00

The relatively recent arrival of Atlassian tools means they are often installed and used in isolation from established mainstream IT. Fair enough. But as the popularity (JIRA, Confluence, etc.) grows from their ease-of-use and flexibility they are soon found delivering business critical services. Victims of their own success, the inevitable happens. For better or for worse, they end up being plumbed in to the […]

The post Best practices: key factor to a successful JIRA implementation appeared first on Valiantys Blog.

Catégories: Blog Société

Ice Cracker Express : le brise-glace ultra rapide

  Pour la plupart des gens, un ice breaker, ou brise-glace en français, est un bateau spĂ©cialisĂ© dans le cassage de la banquise afin de garder ouvertes certaines voies maritime. Mais briser la glace, c’est aussi passer la première barrière naturelle...
Catégories: Blog Société

Partagez la connaissance

Partagez BlogsdeDeveloppeurs.com sur les réseaux sociaux