Statistiques@OCTO, chapitre 1 : comparaison de populations.

Introduction

Cet article est le premier d’une série de communications, visant à partager les pratiques usuelles en statistiques et analyse de données au sein de la communauté OCTO. Chez OCTO, notre vocation est de faire de l’IT et des Big Data, mais il est important de savoir que beaucoup de concepts utilisés dans les algorithmes analytics avancés s’appuient sur des fondements statistiques classiques. Connaître ces fondements permet de mieux comprendre les implications (théories sous-jacentes, limites, etc.) des solutions analytics/Big Data. Par ailleurs, l’application directe de certaines méthodes statistiques permet de répondre aux besoins de certains de nos clients, alors pourquoi nous en priver ? Et oui, parfois nous avons affaire à des volumes de données limités, à des données bien structurées dans des fichiers propres… et dans ce cas, la statistique peut nous aider, alors profitons-en !

Dans cet article, nous proposons une introduction à la comparaison statistique de populations. L’objectif général est de tester si deux ou plusieurs échantillons proviennent d’une même population mère, pour une ou plusieurs variable(s) observée(s). Des ouvrages entiers sont dédiés à ce sujet. En conséquence, cet article ne vise pas à l’exhaustivité. Le but est plutôt de faire prendre conscience au lecteur des enjeux de la problématique de comparaison de populations et des réflexes à acquérir pour mener correctement ce type d’étude.

Pour cela, cet article s’articule de la façon suivante : tout d’abord, nous rappelons brièvement pourquoi la comparaison de populations reste un sujet pertinent dans un contexte Big Data. Ensuite, nous introduisons les grands principes de la comparaison de populations, basée sur la théorie des tests statistiques : cette théorie consiste à définir une hypothèse qui sera validée ou infirmée par le calcul d’une statistique de test. Nous montrons alors comment ces tests peuvent être mis en oeuvre dans un cadre paramétrique. Dans un premier temps, il faut être capable de bien comprendre le contexte du test (cas d’application et contraintes de mise en oeuvre), qui va nous amener à la sélection d’une statistique de test adaptée. L’enjeu pour le praticien se situe essentiellement à cette étape. A titre d’exemple, nous fournissons un aperçu de la diversité de statistiques de tests pouvant exister dans divers cas d’application. Cependant, une fois la statistique choisie, le calcul de la statistique et l’acceptation ou le rejet de l’hypothèse du test se fait aisément grâce aux suites logicielles disponibles, comme nous le montrons dans la dernière partie de cette article.
(Lire la suite…)

PerfUG: Trouvez les problématiques de performances avec JProfiler

Le PerfUG vous présente ses meilleurs voeux pour 2014 et vous donne rendez-vous dès le 23 janvier. A cette occasion nous recevrons Brice Leporini et Florent Ramière qui viendront nous parler de JProfiler.

Pour cela, nous avons une belle application qui rame à souhait: elle présente un florilège de pas mal de galères rencontrées sur les projets sur lesquels nous errons.
Tu es déjà en train de te dire que ça te fait penser à un projet qui a croisé ton parcours il n’y a pas si longtemps que ça!
Ta mission, si tu l’acceptes, est de chasser les coupables et de soumettre tes recommandations.

Ton arme: JProfiler.
Sans maîtrise, la puissance n’est rien”: notre rôle est de t’accompagner dans la découverte de l’outil et de valider tes hypothèses au fil de l’eau.
Rejoins nous avec ton laptop pendant cet atelier et tu seras surpris de la vitesse à laquelle JProfiler te – car c’est toi qui va bosser – permet d’identifier les zones de contentions quelles que puissent être leur nature.

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

L’événement aura lieu le Jeudi 23 Janvier. Pour s’inscrire, c’est sur Eventbrite.

L’art du benchmark

Un benchmark comparant JavaEE et NodeJS a récemment causé un certain émoi sur la toile. J’ai été surpris des résultats et me suis mis en tête de le reproduire pour vérifier une intuition. L’article est, de plus, enrichi de plusieurs commentaires intéressants qui méritent eux-mêmes d’être commentés. Tout ceci m’amène au présent billet.

Qu’est-ce qu’un benchmark? Le benchmark est la mesure des performances d’une application. Nous tentons de reproduire en laboratoire une utilisation normale de l’application. Si vous demandez aux experts, ils vous diront qu’un benchmark est un outil extrêmement dangereux dont les résultats sont presque toujours faux. C’est, à mon point de vue, légèrement exagéré, mais pas complètement faux non plus comme nous verrons plus bas.

Une chose est sûre, quelques précautions sont toutefois nécessaires pour ne pas avoir de surprise plus tard. Par exemple:

  • Avoir une volumétrie de base de données similaire à la cible
  • Avoir une hétérogénéité des données représentatives. En particulier pour des problématiques de cache
  • Une infrastructure proportionnelle à la cible

À noter, contrairement à la croyance populaire, les benchmarks sont généralement optimistes. Si vous avez de mauvais temps de réponse lors du benchmark, il y a fort à parier que ça ne s’améliorera pas en production. C’est donc de l’inverse qu’il faut se méfier. De bons temps de réponse lors du benchmark ne sont pas une garantie de bons temps de réponse en production si le benchmark n’a pas été bien fait.

Un autre point intéressant est (Lire la suite…)

Les Octos vous souhaitent une belle année 2014 !

Voeux OCTO 2014

 

Chaque année c’est la tradition chez OCTO : la carte de voeux spécialement créée par le dessinateur Philippe Vuillemin. On espère qu’elle vous plaira autant qu’à nous. Nous présentons à tous les lecteurs de ce blog nos voeux les plus sincères : réussite, challenge, et surtout du fun !

A l’année prochaine avec une nouvelle version de ce blog. C’est promis !

 

Android : Comment consommer un socket ouvert par une autre application ?

Sous Android, pour améliorer la sécurité, est-il possible d’ouvrir un socket dans une application, de s’occuper de l’authentification, puis de confier ce dernier à une autre application ?
(Lire la suite…)

Mon Android n’est pas un iPhone comme les autres

Chez OCTO, depuis quelques années maintenant, nous réalisons des applications mobiles Android et iOS, smartphones et tablettes. Forts de cette expérience et de notre R&D permanente sur les sujets mobilité et ergonomie, nous pouvons aujourd’hui faire l’affirmation suivante : Un Android n’est pas un iPhone comme les autres.

Malgré un titre un peu racoleur, cet article se veut pédagogue sur les spécificités d’ergonomie de la plateforme Android. Aussi, si vous souhaitez faire briller les yeux de tous vos utilisateurs autant que les étoiles des stores, lisez la suite…

PS : directions marketing et designers, cet article est pour vous !

(Lire la suite…)

La jouer KISS avec Selenium

Tester une application est un sujet soulevant de nombreuses problématiques, bien résumées par le schéma de Brian Marick ci-dessous.

 

Ainsi, dans un projet industrialisé, les best-practice de testing appellent plusieurs typologies de tests automatisés à se côtoyer : des test unitaires (TU), des tests fonctionnels, et éventuellement des tests passant par l’IHM.

Cette richesse est essentielle à l’amélioration de la qualité de nos applications, mais nécessite l’usage de nombreux outils.

Là où les outils de tests unitaires, de mocking,  et de tests fonctionnels sont des références, les outils de tests passant par l’IHM ne sont que peu maîtrisés, en marge des connaissances de l’équipe de développement.

Ils ont tendance à être la 5e roue de la charrette.

 

C’est le cas de Selenium.

Cet article est un retour d’expérience présentant une implémentation bien éloignée des best practices de l’outil, simple et pragmatique.

(Lire la suite…)

DevOps et l’urbanisation du Système d’Information de Production

Introduction

L’entreprise dispose d’un Système d’Information de Production (SIP). Ce SI est en grande partie caché aux utilisateurs métier, mais bien présent. (Lire la suite…)

Les nouvelles architectures front Web et leur impact sur la DSI – partie 2

Dans la partie 1 de cet article, nous avons traité des nouvelles architectures front-end basées sur des applications Web massivement Javascript appelant des API offertes par un serveur back-end : les nouvelles architectures front Web et leur impact sur les DSI – Partie 1.

Nous avons vu qu’elles sont apparues ces dernières années grâce à l’augmentation des performances des navigateurs et à l’amélioration des outils d’industrialisation des développements Javascript.

Dans cette seconde partie, nous nous intéresserons aux raisons pour lesquelles on devrait choisir ces nouvelles architectures, aux opportunités qu’elles offrent, et aux conséquences sur les organisations des directions informatiques.

(Lire la suite…)

Et si Devops nous emmenait vers TDI (Test Driven Infrastructure) ?

Des usines de développement au service de l’infrastructure ?

Le mouvement DevOps a permis aux applications de gagner en productivité et donc en rapidité d’évolutions grâce entre autre à une démarche très efficace : le Continuous Delivery.
Grâce à un rapprochement des pratiques entre Dev et Ops on arrive à apporter aux équipes infrastructures tout l’outillage du développement d’applications. Et c’est là qu’arrive l’un des grands concepts Devops : Infrastructure As Code.

Les géants du web sont largement en avance sur ce que l’on fait aujourd’hui dans la majorité des entreprises. Surtout concernant la mise en place et le déploiement des infrastructures mais également sur un sujet encore peu exploré : l’automatisation des tests d’infrastructure.

On sait aujourd’hui parfaitement tester nos applications mais quid des infrastructures qui les hébergent et que l’on automatise de plus en plus ?

Pourtant, si on rentre dans Infrastructure as Code, on écrit bien du code, on a bien un cycle de vie habituel de code, il faut donc tester ce code!

Une chose est sûre, on doit tester de bout en bout tout ce que l’on automatise soit même.

(Lire la suite…)