Evènements Web

techdays_blog2

Ambient Intelligence & Big Data

0

Ambient Intelligence

Les Techdays 2015, organisés par Microsoft, furent l’occasion d’assister à de nombreuses conférences centrées autour du thème de l’Ambient Intelligence. Selon Microsoft, l’Ambient Intelligence est à la fois une vision et déjà une réalité, rendue possible par les avancées technologiques de l’électronique, du cloud, du Big Data et du machine learning. C’est une représentation d’un univers hyper connecté dans lequel la technologie anticipera nos besoins et nos intentions et qui sera centré sur les objets et les interconnexions entre eux. C’est également une réalité car les applications et les objets qui tirent profit de nos actions et des informations à notre disposition existent déjà et nous permettent de faire plus et mieux.

Cette vision est présente principalement dans les différents secteurs suivants :

  • Domotique
  • Internet des objets
  • E-Santé
  • Les villes intelligentes

 

Dans cet article nous nous consacrerons essentiellement à l’internet des objets.

Internet des objets

L’Internet des objets, ou Internet of Things (IOT) en anglais, représente l’extension d’Internet à des choses et à des lieux du monde physique. Il est en partie responsable de l’accroissement du volume de données générées sur le réseau à l’origine du Big Data. Il n’y a pas de définition officielle pour ce terme mais on peut utiliser la définition suivante :

« L’internet des objets est un réseau de réseaux qui permet, via des systèmes d’identification électronique normalisés et unifiés, et des dispositifs mobiles sans fil, d’identifier directement et sans ambiguïté des entités numériques et des objets physiques et ainsi de pouvoir récupérer, stocker, transférer et traiter, sans discontinuité entre les mondes physiques et virtuels, les données s’y rattachant. »

Ce terme est également utilisé pour parler des objets connectés.

L’élément principal d’un objet connecté est le microcontrôleur. Il s’agit d’un circuit programmable capable d’exécuter un programme et qui possède des circuits d’interface intégrés avec le monde extérieur. Il est composé d’un processeur (CPU), de mémoire morte (ROM), de mémoire vive (RAM) et d’entrées-sorties (I/O).

Pour pouvoir déployer le programme sur le microcontrôleur, il faut utiliser un programmateur en tant que passerelle avec l’ordinateur du développeur. Il est également possible d’utiliser des cartes programmables tel qu’Arduino ou encore Raspberry Pi. Les cartes de type Arduino sont des circuits imprimés programmables possédant un microcontrôleur ainsi que des entrées-sorties. Celles de type RaspberryPi possèdent des systèmes d’exploitation intégrés ce qui permet au développeur de les utiliser comme n’importe quel autre ordinateur. Pour citer un exemple d’objet connecté, on peut parler du bracelet Myo. Il s’agit d’un bracelet connecté qui peut envoyer un signal en fonction d’une liste de gestes réalisés par l’utilisateur.

 

Trailer du bracelet Myo
 

Big Data

Le Big Data (parfois appelé données massives ou mégadonnées en français) est un concept qui désigne des ensembles de données si volumineux qu’ils nécessitent de nouveaux outils de gestion de base de données afin d’être stockés, croisés puis analysés pour en obtenir une information utilisable par l’utilisateur final. Le Big Data occupe une place importante dans l’internet des objets. Il est la plaque tournante de la masse de données échangées entre les différents objets.

Le Big Data repose sur trois principes :

Volume

Le volume décrit la quantité de données générées par des entreprises ou des personnes. C’est en général la principale caractéristique à laquelle le Big Data est associé. Les entreprises, avec des volumes dépassant souvent le téraoctet de données doivent trouver un moyen de gérer cette quantité en constante évolution.

Variété

De nos jours, les entreprises sont confrontées au stockage de données de type de plus en plus varié fournis par les réseaux sociaux, les interactions Machine to Machine et les terminaux mobiles en évolution continue. Ces données peuvent aller de coordonnées de géolocalisation à des flux de réseaux sociaux.

Vélocité

Devant l’envergure des données à traiter, il est essentiel pour les entreprises de pouvoir traiter ces informations aussi vite que possible. Beaucoup d’entre elles échouent dans ce domaine fautes de CRM ne pouvant analyser les données en temps réel. En effet, la vitesse de génération et stockage des données tend à évoluer si rapidement avec les nouvelles technologies que le temps que celles-ci soient analysées, elles ne soient déjà plus contractuelles.

 

Le traitement des informations en Big Data se réalise en trois étapes :

Stockage

Comme évoqué précédemment, le stockage de flux de données, très volumineux, requiert des infrastructures spécifiques. Extrêmement mutables, ces données sont en général stockées au travers de bases dans un format « schemaless ». De nos jours, de tels services sont notamment proposés par Microsoft Azure et son système de stockage ou encore Document DB.

Croisement

Afin de pouvoir exploiter les informations stockées, il faut ensuite choisir les critères sur lesquels les analyses auront lieux. En général il s’agit d’une donnée commune aux entrées stockées. On peut penser à l’âge, au sexe et à la localisation d’une personne par exemple dans le cadre d’une étude sociale.

Analyse

C’est le résultat attendu par l’utilisateur final, ou les fournisseurs des données traitées. Il s’agit de donner un propos aux résultats obtenus suite au croisement. La donnée devient alors une information. Dans le cadre d’un entrainement physique, on peut penser à l’ajustement du programme prescrit par exemple.

Afin d’accompagner les besoins de traitements complexes nécessaire dans l’analyse des données, et notamment dans l’analyse prédictive des données qui a pour but de prédire le comportement d’une entité à partir des données qu’elle génère, il existe maintenant de nombreux outils de Machine Learning.

Microsoft, à l’instar de ses concurrents (Amazon, Google, …), a ainsi intégré à Azure des services de Machine Learning. Il existe ainsi des techniques et des langages de programmation spécialisés dans l’analyse de données, tel que R.

 

Profils

Parce que le Big Data demande des compétences spécifiques, on voit apparaître ces derniers temps de nouveaux profils transverses qui accompagnent son essor. Il n’existe pas de définitions formelles de ces nouveaux postes. On parle le plus souvent de Data Analyst mais il devient fréquent de faire la distinction entre Data Engineer et Data Scientist. Bien que, jusqu’à très récemment, il n’existait pas de cursus pour ces profils, des formations commencent à apparaître afin de répondre aux besoins colossaux des grands groupes industriels et technologiques.

Data Engineer

Il est chargé de l’aspect architecture. Son travail est de s’assurer que l’architecture et les programmes permettent d’accéder aux données de façon rapide, simple et claire. Par exemple il va s’occuper du design des bases de données, la récupération des données et de la création d’API et de WebAPI pour permettre d’en faire l’analyse. C’est donc avant tout un profil technique en informatique autant à l’aise en développement qu’en administration de bases de données qu’elles soient relationnelles ou non.

Data Scientist

Une fois que les données existent et sont accessibles, c’est au Data Scientist de procéder à leur analyse. Il va devoir acquérir des connaissances propre au secteur d’activité de l’entreprise et au contexte des données qu’il va traiter. Il a bien entendu une bonne connaissance des langages d’accès aux données (SQL) mais également des outils de Machine Learning, Data Mining et de modélisation de données. Il s’agit bien souvent d’un statisticien reconverti en développeur possédant une bonne culture générale ainsi que de bonnes capacités en communication.

Data Analyst

Le Data Analyst est un mélange des deux profils précédents. Parfois ingénieur ou statisticien, il peut également être issu de parcours managériaux pour les études touchant au B.I., avec de solides compétences en Excel et en modélisation. Seul, il peut déjà offrir des conclusions intéressantes et des éléments de réponses  pertinents à son entreprise afin d’améliorer les décisions prises. Cependant, tout projet complexe nécessitera des profils plus spécialisés comme des Data Engineer et Data Scientist présentés précédemment.

 

Conclusion

Les TechDays furent ainsi l’occasion de mettre en lumière cette nouvelle discipline liée à l’essor des objets connectés. Alors qu’hier les données étaient générées directement par les utilisateurs, avec ce que cela  implique concernant leur quantité et leur qualité, l’Ambient Intelligence vise aujourd’hui à automatiser la collecte de ces données, notamment via les objets connectés et les initiatives autour de l’Open Data, afin d’améliorer les services proposés. La masse de données  en augmentation constante issue de cette transformation a donc entrainé la formation de nouveaux profils spécialisés  et de nouveaux outils capables de les aider à traiter cette quantité phénoménale d’informations. On peut gager que ce n’est que le début de cette révolution qui sera au cœur des décisions de demain dans les grandes entreprises  avec un réel impact sur notre quotidien.

 

Symfony Live 2013 – Processus de développement au sein d’Overblog

0

Le 4 Avril dernier, Xavier Hausherr, CTO chez Overblog, présentait à l’occasion du Symfony Live 2013 le processus de développement de son équipe.

Ce processus a été complètement revu dernièrement, et laisse derrière lui le traditionnel cycle en V au profit d’un processus agile adapté au fonctionnement d’Overblog.

 

METHODOLOGIE AGILE

 

Les besoins des produits d’Overblog évoluant très rapidement et les spécifications détaillées étant rarement fournies, l’équipe s’est tournée naturellement vers la méthodologie SCRUM pour encadrer ce nouveau processus de développement. Je ne reviendrai pas sur les bases cette méthode, vous pourrez trouver énormément de ressources la concernant sur internet, mais voici les ajustements effectués par l’équipe d’Overblog :

  • Les sprints sont d’une durée de 2 semaines.
  • L’incrément d’un sprint est mis en production le premier jour du sprint suivant.
  • Le contenu du sprint est gelé le mercredi précédent la fin du Sprint afin de consacrer les 2 derniers jours aux tâches de debug et de refactorisation ainsi qu’aux réunions de fins de Sprint (démo et rétrospective)
  • Une revue de code est organisée le dernier jour d’un sprint permettant aux membres de l’équipe de mettre en lumière des parties de code intéressantes venant d’être développées.
  • Le poker planning est étalé sur l’ensemble du Sprint à raison de 30min tous les 2 jours. Cette mesure a été prise afin, d’une part, de ne pas avoir des sessions trop longues et, d’autre part, de pouvoir évaluer rapidement un item qui apparaîtrait au milieu d’un sprint.

 

PROCESSUS DE DEVELOPPEMENT

 

Afin de sélectionner un processus de développement adapté, Overblog a fixé le cahier des charges suivant :

  • Coder sans mettre en péril le projet
  • Travailler à deux ou plus sur des features
  • Tester chaque fonctionnalité avant mise en production
  • Intégration continue pour certaines fonctionnalités
  • Release pour les grosses fonctionnalités
  • Gestion des urgences
  • Être accepté par l’équipe SCRUM

L’équipe s’est d’abord intéressée au « Git Flow ». Le Git Flow est un modèle de structure d’un repository Git présenté par Vincent Driessen (@nvie) dans son post « A successful Git branching model » début 2010. Il se présente de la façon suivante :

 

 gitflow-1

 

Dans ce modèle, le développement s’articule autour de la branche « develop » qui représente le dernier état stable du projet et de la branche « master » qui représente de son côté le dernier état livrable du projet.
Les branches de type « feature » permettent de cloisonner les développements de fonctionnalités et particulièrement ceux qui nécessite plusieurs sprints pour pouvoir être livrables. Une fois qu’une fonctionnalité est terminée et stable, elle est réintégrée à la branche « develop » via un merge.
Lors de la « feature freeze », on crée une branche de type « release » ayant pour vocation d’être livrée en production. C’est cette branche qui est testée, debuggée, refactorisée (les modifications étant également reportées sur la branche « develop »).
Une fois que la release est considérée livrable elle est mergée avec la branche « master » représentant l’état de la production.
Si des bugs importants font leurs apparitions en production, il est possible de créer une branche de type « hotfix » basée sur la branche « master » afin de corriger rapidement le bug. La correction, une fois testée, est alors réintégrée dans la branche « master » (pour pouvoir être livrée) mais également dans la branche « develop » afin que les prochaines versions en tiennent compte.

Il est également possible de travailler à 2 sur une même fonctionnalité en définissant des «GIT remote » pointant vers les repository GIT des postes locaux des développeurs.

Ce processus répond à plusieurs des besoins de l’équipe mais présente plusieurs inconvénients :

  • Il n’y a pas de connexion centralisée
  • Le merge peut être compliqué et la responsabilité du merge n’est pas indiquée
  • Le moment où effectuer des tests n’est pas spécifié non plus
  • Le nom de la branche « develop » n’est pas très significatif

Ces limitations avaient déjà été remarquées par Scott Chacon, évangéliste Git.
Ce dernier propose dans un article daté d’Août 2011 une approche similaire basée sur Github qu’il appelle « Github flow ».

 githubflow-2

 

La branche « master » remplace la branche « develop » du Git Flow et la branche représentant l’état livrable devient la branche « stable ». On retrouve les branches de type « feature » et « hotfix » à l’identique mais les merges dans les branches « master » et « stable » (dans le cas d’un hotfix) se font à l’aide des pull requests de Github. Les modifications de la branche « master » sont réintégrées directement dans la branche « stable » via un processus d’intégration continue permettant de valider le code produit

Cette nouvelle méthode répondait plus largement aux besoins de l’équipe d’Overblog mais l’absence de release posait problème. Ils ont donc pris le parti de créer leur propre processus appelé modestement Overblog Flow;-)

Celui-ci reprend les points forts des 2 méthodes précédentes :

githubflow-3 

On y retrouve donc la structure principale de Github flow auquel des branches de types «release» ont été ajoutées. Leur utilisation n’est pas systématique, ainsi une feature urgente peut être mise en production rapidement via un processus d’intégration continue.

 

TESTS UNITAIRES ET FONCTIONNELS

 

Lors du développement, le développeur écrit et lance les tests unitaires dans son environnement local de développement. Une fois que la feature est considérée comme terminée par le développeur, il soumet une pull request au lead developer. L’incrément, une fois validé, est déployé sur un serveur de test afin de passer une série de tests via Jenkins :

  • Tests unitaires PHP (PHPUnit)
  • Tests unitaires JS (YUI Test)
  • Qualité du code
  • Respects des normes
  • (…)

Une équipe « Qualité » est ensuite chargée d’écrire des tests fonctionnels couvrant la nouvelle fonctionnalité. Ces derniers sont également exécutés sur la plateforme de tests via Jenkins. Ils sont rédigés dans le langage Gherkin et exécutés via Cucumber.

L’incrément est ensuite déployé sur une plateforme de « staging », plus proche de la production (configuration des serveurs, données, etc.) . Il subit alors de nouveau une série de tests via Jenkins (tests unitaires et fonctionnels).

Si les tests sont concluants, l’incrément passe alors en production. Cette dernière étant également testée fonctionnellement chaque nuit.

 

CONCLUSION

 

Dans un esprit agile, Overblog a su composer sa propre méthodologie de travail en s’inspirant et en adaptant des méthodes existantes qui ont fait leurs preuves. Il est certain que cette méthode sera affinée au fur et à mesure des sprints dans les mois et années à venir, s’adaptant aux nouvelles contraintes techniques et humaines de l’équipe et aux nouveautés à venir mais l’ensemble semble déjà un succès au vu de la qualité du travail accompli, du nombres de blogs hébergés et des bonnes critiques sur la nouvelle version du site que l’on peut lire en général.

Vous trouverez ci-dessous le lien vers les slides de la présentation ainsi que les liens se rapportant aux articles cités.

 

REFERENCES