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

Nous Ă©tions Ă  la KubeCon Europe (1/2)

The Kubernetes Community conference

Nous y voyons plus clair, Kubernetes est pour le moment la solution de Container as a Service que nous recommandons. Nous l’avons dĂ©jĂ  dĂ©ployĂ© en production, packagĂ© avec Openshift Origin pour proposer une Platform as a Service du meilleur effet. C’est fort de notre expĂ©rience que nous avons voulu voir ce qui se fait ailleurs, dans le monde des containers. Et quoi de mieux que la Kubecon Europe pour satisfaire notre soif d’apprentissage…

La Kubecon Europe a eu lieu cette annĂ©e Ă  Londres et s’est dĂ©roulĂ©e les 10 et 11 mars 2016.

C’est l’occasion de dĂ©couvrir :

  • La vision et les nouveautĂ©s de Kubernetes 1.2 et 1.3
  • L’ensemble des solutions gravitant autour de l’écosystĂšme Kubernetes
  • Les retours d’expĂ©riences et diffĂ©rents cas d’usages

Les grands thÚmes abordés lors de cet événement ont été nombreux, nous avons pris le parti de nous concentrer sur deux sujets :

  • La Roadmap et la vision de Kubernetes
  • Kubernetes en production (qui fera l’objet d’un second article)

Dans cet article, nous traiterons le premier point sur la vision et les nouveautĂ©s de Kubernetes qui nous ont Ă©tĂ© prĂ©sentĂ©es. Il s’adresse aux amateurs confirmĂ©s de Kubernetes.

 

La vision et la roadmap et de Kubernetes

“Le entrypoint.sh dans docker c’est pour les hipsters” Kelsey Hightower

Get started quicker, get big faster. C’est de cette maniĂšre que Kelsey Hightower a introduit la premiĂšre keynote de la KubeCon 2016. Avant de lister les nouveautĂ©s Ă  venir de Kubernetes, il convient de rappeler ce qu’est Kubernetes : un framework permettant de construire un systĂšme distribuĂ©. Il s’appuie sur les technologies de container qu’il sait orchestrer. Kubernetes est un CaaS (Container as a Service) et non un PaaS (Platform as a Service).

"Kubernetes is not a PAAS. You don't install it and end up with Heroku." #KubeCon @kelseyhightower

— MichaƂ Paluchowski (@mpaluchowski) March 10, 2016

Comme beaucoup de technologies avec le vent en poupe, ces derniĂšres soulĂšvent de nouvelles problĂ©matiques, et de nouveaux usages apparaissent. Il n’est toutefois pas obligatoire de mettre son SI en chantier sous prĂ©texte que Kubernetes va TOUT rĂ©volutionner.

Kelsey Hightower rappelle ainsi quelques bonnes pratiques Ă©mergentes, parmi lesquelles :

  • Il n’est pas obligatoire d’intĂ©grer votre SI entier dans Kubernetes. Cela s’applique notamment aux bases de donnĂ©es relationnelles qui ne scalent pas simplement
  • Kubernetes permet le versionnement des composants via les tags Docker, mais attention : le tag latest n’est pas une version ;)
  • L’architecture de Kubernetes permet de scaler by design. Attention Ă  ne pas en faire trop : si vous n’avez pas d’utilisateurs sur votre plateforme, vous n’ĂȘtes pas obligĂ© de scaler tout de suite
Les nouveautées de Kubernetes 1.2 et 1.3

La version 1.2 est désormais disponible

Kubernetes 1.2 has gone GA! Read the blog this week for coverage of five of the new features https://t.co/PJg7BHjBHv

— Kubernetes (@kubernetesio) March 28, 2016

Elle embarque les nouvelles fonctionnalités suivantes:

  • Une nouvelle interface
  • La simplification des flux entrants (Ingress), facilitant le routage vers les PODs depuis Internet
  • La gestion des secrets pour simplifier la configuration ssl des frontend
  • Une meilleure scalabilitĂ©
  • L’ajout des ReplicasSet qui facilite entre autres les dĂ©ploiements en rolling update et permet d’affiner la selection des objets Ă  travers du CLI (exemple : je veux scaler tous mes frontaux de production)
  • L’apparition d’une ConfigMap qui est un descripteur clĂ© / valeur consommĂ© par les pods au dĂ©marrage pour une configuration plus fine (l’équivalent d’un cloud init)
  • La gestion automatique des clusters (gĂ©nĂ©ration de namespace; management des secret et export des ressources)
  • L’intĂ©gration simplifiĂ©e des extensions (Third Party)
  • Et bien d’autres features que vous retrouverez ici

La version 1.3 annoncĂ©e dans quelques semaines (oĂč quelques semaines = O(16)) est en cours de dĂ©veloppement et apportera :

  • Le support des applications legacy (cattle vs pets)
  • La fĂ©dĂ©ration des clusters (Ubernetes)
  • Une meilleur scalabilitĂ©, et l’autoscaling non plus des pods, mais des clusters
  • La gestion des identitĂ©s et le contrĂŽle d’accĂšs
  • La gestion des jobs (Cron)
  • Un Public Cloud Dashboard qui permettra de lancer des nightly builds et mesurer les performances du cluster
  • And lots, lots more!
Ce que nous en pensons:

Si nous faisons le focus sur nos besoins en production, les nouveautĂ©s les plus intĂ©ressantes sont la simplicitĂ© de configuration concernant la sĂ©curitĂ© (les secrets), la gestion de la mise en production sans interruption (rolling update), et l’exposition des pods (via ingress). Ajoutons Ă  cela la gestion des clusters simplifiĂ©es avec la gestion des identitĂ©s, la facilitĂ© de scaler (autant les pods que les clusters), nous avons une solution de CaaS de plus en plus robuste et sĂ©curisante pour un usage en production.

Le fait de mettre l’effort sur l’intĂ©gration des Third Party est dans la continuitĂ©. Cela nous permettra de rendre nos clusters multitenants, Ă  dĂ©faut d’ĂȘtre proposĂ© par Kubernetes.

En regardant de plus prĂšs, nous constatons que ces fonctionnalitĂ©s sont dĂ©jĂ  prĂ©sentes pour la plupart dans Openshift Origin (La solution de PaaS de RedHat basĂ©e sur Kubernetes), l’ajout des ConfigMap est un autre exemple.

Kubernetes new features vs Openshift Origin

Capture d’écran 2016-03-29 à 16.41.56

La convergence des deux solutions est frappante, Openshift v3 ayant pour lui sa capacitĂ© de Builder des projets. Il restera Ă  voir l’évolution des solutions au dessus de Kubernetes, qui devront choisir de s’adapter, ou non, aux Ă©volutions apportĂ©es par la communautĂ© Kubernetes.

Rappelons-le, Kubernetes est un framework, plus spĂ©cifiquement un CaaS. C’est aussi un Ă©cosystĂšme en pleine expansion sur lequel s’appuie de nombreux acteurs. Ces derniers s’appuient sur cette solution pour fabriquer leur PaaS, ou cherchent Ă  le rendre robuste et scalable, pour une utilisation de plus en plus demandĂ©e par les entreprises en production. Nous aborderons l’ensemble de ces pratiques et uses cases de Kubernetes en production dans le prochain article.

Articles suggested :

  1. OpenShift 3 : le PaaS privé avec Docker
  2. La Ruée vers le conteneur
  3. Nous Ă©tions Ă  la KubeCon Europe (2/2)

Catégories: Blog Société

Docker pattern : conteneur de build

Docker patternLorsqu’on dĂ©veloppe une application, la mise en place de l’environnement de build et la gestion des dĂ©pendances est un moment frustrant. DĂ©couvrons un cas d’utilisation de Docker permettant de rĂ©soudre cette problĂ©matique en laissant votre poste de travail propre.

Le contexte

Me voici nouvel Ă©quipier sur un projet et ma premiĂšre tĂąche consiste classiquement Ă  installer l’environnement sur mon poste de travail.

Le projet est une application dont le but est de fournir l’heure. Afin d’ĂȘtre multiplateforme, l’application est Ă©crite en go. Les logs de l’application sont gĂ©rĂ©s par une bibliothĂšque tierce.

Enfin, pour simplifier le dĂ©ploiement, l’application sera livrĂ©e en tant qu’image Docker.

Vous l’aurez compris, l’idĂ©e est de fournir les outils pour construire l’application ainsi que l’image Docker finale

Le code

Le code de l’application est ici trĂšs simple.

package main

import (
    log "github.com/Sirupsen/logrus" // Use some external dep
    "time"
)

func main() {
    log.Println(time.Now())
}

Le seul point d’intĂ©rĂȘt rĂ©side dans l’utilisation de logrus pour la gestion des logs.

Image de build

Dans le projet créons un fichier Dockerfile dédié au conteneur de build. Sans grande originalité je vous propose de le nommer build.Dockerfile, permettant ainsi la reconnaissance du format de fichier par un éditeur de texte.

FROM golang:1.5

RUN go get github.com/Sirupsen/logrus

VOLUME $GOPATH/src/github.com/tauffredou/clock
VOLUME /output

WORKDIR $GOPATH/src/github.com/tauffredou/clock
CMD GOOS=linux GOARCH=amd64 go build -o /output/clock

Quelques explications:

FROM golang:1.5

L’image de base utilisĂ©e est directement l’image « officielle » golang en prĂ©cisant la version souhaitĂ©e. Nous Ă©vitons ainsi de gĂ©rer l’installation du SDK go.

RUN go get github.com/Sirupsen/logrus

go get permet de tĂ©lĂ©charger la dĂ©pendance logrus dans le GOPATH. D’autres solutions telles que godep existent pour gĂ©rer les dĂ©pendances plus finement mais nous ne les utiliserons pas ici.

VOLUME $GOPATH/src/github.com/tauffredou/clock

Ce volume contiendra les sources du projet. Pour ĂȘtre prĂ©cis, il n’est pas obligatoire de le dĂ©clarer dans le Dockerfile mais cela fournit une information sur l’emplacement attendu directement.

VOLUME /output
Ce volume va recevoir les binaires compilés.

WORKDIR $GOPATH/src/github.com/tauffredou/clock

Par commoditĂ© le rĂ©pertoire d’exĂ©cution est celui des sources du projet

CMD GOOS=linux GOARCH=amd64 go build -o /output/clock

La commande par défaut du conteneur compile le projet dans le répertoire /output

Image finale
FROM busybox
COPY bin/clock /
CMD /clock

FROM busybox

Le binaire Ă©tant statiquement compilĂ©, il serait possible d’utiliser une image « scratch », l’image finale ne contenant alors que l’application. Cependant, pour disposer d’un minimum d’outils, nous utiliserons une image de base « busybox »
COPY bin/clock /

Le binaire est copié depuis le répertoire bin.
CMD /clock

Sans surprise, la commande par défaut exécute le programme

Un peu d’outillage

La dĂ©marche Ă©tant de limiter le plus possible les prĂ©requis, il n’est pas judicieux de se reposer sur un autre outil de build, sauf si vous avez la certitude que celui-ci est prĂ©sent sur les postes cibles. make, par exemple sera probablement prĂ©sent sur un environnement linux mais moins gĂ©nĂ©ralement sur un poste windows. L’utilisation de Docker sous Windows impose l’utilisation d’un terminal cygwin, nous sommes donc certain d’avoir un shell sur tous les postes.

#!/bin/sh

CWD=$(cd $(dirname $0);pwd)
MAKE=$0
IMAGE=tauffredou/clock

usage(){
cat<<-EOUSAGE
make.sh [Action]
Actions:
  builder       create builder image
  build         create binary using builder image
  image         create final image
  run           run the final image
  build-chain   builder,build,image

EOUSAGE
}

case $1 in
  builder)
    docker build -f build.Dockerfile -t $IMAGE-builder .
  ;;
  build)
    docker run -v gopath:/go/src -v $CWD:/go/src/github.com/tauffredou/clock -v $CWD/bin:/output $IMAGE-builder #note 1
    echo "Built in $CWD/bin"
  ;;
  image)
    docker build -t $IMAGE .
    echo run clock with: docker run $IMAGE
  ;;
  run)
    docker run $IMAGE
  ;;
  build-chain)
    $MAKE builder && $MAKE build && $MAKE image
  ;;
  *)
    usage
  ;;
esac

note 1 : J’utilise lors du build deux volumes : le premier est un volume nommĂ© gopath (disponible depuis Docker 1.9), le second monte le rĂ©pertoire de travail dans le conteneur en respectant la nomenclature go.

docker volume ls

DRIVER              VOLUME NAME
local               gopath

Un volume gopath est automatiquement crĂ©Ă© si celui-ci n’existe pas. Il permet d’enregistrer les dĂ©pendances en dehors du conteneur; plusieurs projets peuvent ainsi partager ce mĂȘme volume et Ă©viter de tĂ©lĂ©charger les dĂ©pendances communes.

L’essayer c’est l’adopter

S’il est besoin de vous convaincre, vous pouvez essayer avec le projet prĂ©sentĂ©. Les sources sont disponibles sur github.

git clone https://github.com/tauffredou/clock.git
cd clock
./make.sh build-chain
./make.sh run

Plusieurs images ont été créées:

docker images

REPOSITORY                                        TAG                 IMAGE ID            CREATED             SIZE
tauffredou/clock                                  latest              d41a6cf3695b        4 days ago          4.148 MB
tauffredou/clock-builder                          latest              6b56026a925b        4 days ago          725.9 MB
golang                                            1.5                 2e1c8fd5ddc3        3 weeks ago         725.2 MB

Nous constatons que l’Ă©cart de taille entre le builder et l’image finale est important. En effet le builder contient le SDK et les dĂ©pendances ; de plus nous utilisons une image de base officielle et avons donc peu de possibilitĂ©s d’optimisation.

Pour conclure cet article, je vous propose de faire le ménage

# Suppression des conteneurs 
docker rm $(docker ps -a | grep " tauffredou/clock" | awk '{print $1}' )
# Suppression des images
docker rmi tauffredou/clock-builder tauffredou/clock

L’image golang et le volume gopath sont toujours prĂ©sents, si vous ne les utilisez pas pour un autre projet, vous pouvez les supprimer. J’ai choisi de les garder.

Et notre poste de travail retrouve l’odeur du neuf !

Catégories: Blog Société

Aller plus loin avec Doctrine2 – PrĂ©sentation de Webnet au SymfonyLive 2016

Le blog Webnet - ven, 04/08/2016 - 14:04

 

Nos architectes techniques André et Amine ont présenté, lors du SymfonyLive Paris 2016, comment aller plus loin avec Doctrine2 !

L’amphi Ă©tait plein et la prĂ©sentation trĂšs apprĂ©ciĂ©e ! Nous sommes trĂšs fier d’eux &#x1f609;

 

Pour retrouver les slides de la prĂ©sentation du SymfonyLive – Doctrine2

 

Capture slide

 

Capture slide sommaire

 

 

Capture

 

IMG_1007

Catégories: Blog Société

L’Equipe Hautes Performances : une ambition Ă  votre portĂ©e

L’AgilitĂ© est souvent prĂ©sentĂ©e comme un moyen d’accĂ©der Ă  une meilleure performance gĂ©nĂ©rale, que ce soit au niveau d’une Ă©quipe ou de toute une organisation. Ainsi, Ă  mesure que l’AgilitĂ© s’est rĂ©pandue au cƓur des organisations, la notion d’Ă©quipe hautes performances est apparue comme un futur plus accessible. En tant que facilitateurs, nous sommes amenĂ©s […]
Catégories: Blog Société

Breizhcamp 2016 – Compte-rendu de la journĂ©e du vendredi

Logo breizhcamp
Dernier jour du Breizhcamp ! Et encore une belle journée. Et je vous ai sélectionné trois talks que je vais vous résumer ici.

Le rĂ©seau, cet inconnu au coeur de vos applications – par RaphaĂ«l Luta

C’est l’un des sujets qui m’a le plus surpris. A vrai dire, en tant que dĂ©veloppeur, on pense souvent que le rĂ©seau n’est pas notre affaire. Et pourtant… voici ce que nous a appris RaphaĂ«l.

Si parfois il arrive que l’on soit trĂšs fier de l’application que l’on a dĂ©veloppĂ© (enfin, pour les vaniteux comme moi du moins, ce n’est pour autant pas forcĂ©ment le cas du client, notamment cĂŽtĂ© performance. MalgrĂ© notre attention portĂ©e Ă  toutes les optimisations (bon d’accord, « toutes » c’est un grand mot, mais quand mĂȘme), on se retrouve souvent en production avec une impression de dĂ©jĂ -vu venant tout droit venue des annĂ©es 1990 sous Windows 3.1 ?

Tout d’abord, lorsque l’on parle de rĂ©seau, on change de point de vue. Dans une application, on voit les requĂȘtes comme si elles ne faisaient qu’une. CĂŽtĂ© rĂ©seau, les seules choses qui comptent, ce sont les paquets, et la maniĂšre dont ils transitent.

Alors, quels sont les critĂšres dĂ©terminants pour le voyage de nos chers paquets ? Laissez-moi deviner, vous pensez Ă  la bande passante ? Oui, la bande passante joue un rĂŽle dĂ©terminant, mais Ă  elle-seule la bande passante n’est rien. Notre orateur cite, lui, les suivants :

  • la bande passante
  • la latence
  • le taux d’erreur
  • le duplex
  • le MTU (Maximum Transmission Unit)
  • le Jitter (ou Gigue, en français)

Il y a Ă©galement une autre mesure intĂ©ressante qui s’appelle le BDP (Bandwidth-Delay Product) qui Ă©quivaut Ă  la bande passante multipliĂ©e par la latence.

Pour comprendre le rĂŽle de chacune de ces grandeurs, et puisqu’il s’agit bien de circulation (de paquets), on peut facilement faire la comparaison avec une route pour vĂ©hicules motorisĂ©s de façon Ă  mieux se les reprĂ©senter. La bande passante reprĂ©sente le nombre de voies parallĂšles sur lesquelles les voitures vont dans un mĂȘme sens, la latence la limitation de vitesse, le MTU la taille de chaque voie, le full duplex la circulation Ă  deux sens, le half duplex la circulation alternĂ©e, le jitter les zebras, et le taux d’erreur les accidents de la route.

Cela fait dĂ©jĂ  un bon nombre de paramĂštres n’est-ce pas ? On comprend aisĂ©ment que les conditions idĂ©ales sont une bande passante trĂšs large, une latence trĂšs faible, un taux d’erreur trĂšs faible, un gros MTU et du full duplex. On comprend  aussi que si une bande passante peut accĂ©lĂ©rer de maniĂšre importante le tĂ©lĂ©chargement d’un gros fichier, elle n’est en revanche d’aucune utilitĂ© pour la vitesse d’une succession de nombreuses requĂȘtes/rĂ©ponses. Alors pourquoi ne parle-t-on quasiment que de la bande passante ? L’augmentation de la bande passante ces derniĂšres dĂ©cennies a suivi la loi de Moore. On peut l’amĂ©liorer, et la marketer sans trop de risque, car on sait qu’elle peut toujours ĂȘtre augmentĂ©e. En revanche, la latence a des limitations physiques. On pourra faire les amĂ©liorations que l’on veut, jamais personne n’arrivera a dĂ©passer la vitesse de la lumiĂšre. Ceci Ă©tant dit, certaines conditions diminuent de maniĂšre significative la latence comme par exemple la fibre optique, qui, Ă  bandes passantes Ă©gales, feront du rĂ©seau optique un rĂ©seau beaucoup plus performant qu’un rĂ©seau par cĂąble.

AprĂšs une comparaison du TCP avec l’UDP, et nous avoir fait une simulation graphique assez bluffante de l’effet des variations des diffĂ©rents paramĂštres, notre speaker nous met en garde contre le gaspillage de place.

Imaginez que vous envoyiez une clĂ© USB dans un carton Ă©norme ?! Retirons les espaces blancs, les commentaires, rĂ©duisons les noms trop longs dans tout ce qui part sur le rĂ©seau ! On peut aussi jouer sur les protocoles plutĂŽt que d’envoyer du format texte (protobuf, thrift, avro, …), compresser (avec Snappy par exemple, qui offre un bon compromis entre rapiditĂ© de sĂ©rialisation et compression). Les bases de donnĂ©es souffrent souvent, elles aussi, de nĂ©gligence dans la maniĂšre dont elles sont requĂȘtĂ©es.

Nous terminerons donc en essayant d’oublier la fausse idĂ©e que la bande passante est la solution Ă  tous nos problĂšmes. Et surtout, rappelons-nous que notre maniĂšre de dĂ©velopper et de benchmarker peut faire toute la diffĂ©rence dans l’utilisation du rĂ©seau.

Kill all the REST with the Falcor – par Hugo Wood

Ce talk a beaucoup attisĂ© ma curiositĂ© et mon intĂ©rĂȘt. Si vous aussi vous ĂȘtes fatiguĂ©s de coupler le code des ressources Ă  l’usage des clients, cette technologie est pour vous.

En effet, parfois, on se retrouve Ă  faire le choix entre remonter une arborescence gigantesque sur le rĂ©seau par une API REST ou devoir Ă©crire des routes « Ă  la pelle » pour se conformer Ă  chacun des usages des ressources.

Falcor rĂ©pond Ă  ce problĂšme en prĂ©fĂ©rant une route unique, servant Ă  la fois pour les queries ou les updates, et permettant de ne remonter que les parties du graphe d’objets dont nous avons besoin. En plus d’optimiser le trafic rĂ©seau, Falcor est facile d’utilisation puisqu’une requĂȘte ressemble comme 2 gouttes d’eau au parcours d’un objet en Javascript (ex: http://server/resource?todos[0].name), mais il est Ă©galement possible de requĂȘter un range (ex: todos[0..9].name) ou encore plusieurs ids prĂ©cis Ă  la fois ne nĂ©cessitant qu’un seul appel, et mĂȘme de lancer des requĂȘtes en batch. Avec en prime un systĂšme de cache.

Cela m’a vraiment donnĂ© envie de l’utiliser !

DevOps sur Android : D’un git push Ă  une release sur le Play Store – par JĂ©rĂ©mie Martinez

JĂ©rĂ©mie, arrivĂ© il y a quelques mois chez Captain Train, a menĂ© un bon nombre travaux pour aller vers le Continuous Delivery de l’application Android. Si vous n’avez pas la chance d’aller le voir Ă  Devoxx, voici un aperçu des expĂ©riences qu’il en a tirĂ©es et qu’il a dĂ©cidĂ© de partager avec nous.

Le premier niveau, l’intĂ©gration continue, tient Ă  plusieurs choses. Il faut d’abord se munir d’un bon gestionnaire de dĂ©pendances. Dans le monde Android, celui qui s’impose est Gradle. Il faut ensuite prendre soin de ses tests automatisĂ©s. Les tests automatisĂ©s sur Android pĂątissent de la rĂ©putation d’ĂȘtre trop compliquĂ© Ă  mettre en place. JĂ©rĂ©mie n’est cependant pas d’accord.

PremiĂšrement, si les tests utilisant des appareils physiques peuvent compliquer la tĂąche, n’oublions pas les tests unitaires! Sur Android, il est trĂšs simple d’utiliser JUnit 4. Et si l’on a besoin de mocker les interactions avec l’appareil, Robolectric est lĂ  pour vous sauver la mise. Il s’agit aussi de tester les bonnes choses. Tester Android est inutile. Tester la bonne utilisation d’Android, en revanche, est bĂ©nĂ©fique. Pour les tests d’intĂ©gration, on pourra utiliser Espresso, mais en gardant en tĂȘte seulement le user flow principal, comme rechercher un billet de train, mettre en panier, payer ou rĂ©cupĂ©rer ses billets.

Nous nous sommes ainsi dĂ©jĂ  assurĂ© de ne pas faire de grosse bĂȘtise. Mais qu’en est-il de la bonne structure du code ? JĂ©rĂ©mie, lui, utilise SonarQube et pratique beaucoup la code review avec ses collĂšgues. Il utilise Ă©galement Lint et nous en fait des louanges car trĂšs personnalisable, simple Ă  mettre en place et intĂ©grĂ© par l’IDE. Pour terminer son intĂ©gration continue, il ne reste plus qu’Ă  automatiser les diffĂ©rentes opĂ©rations de packaging en prenant garde de filtrer les ressources, et de bien signer l’APK.

Une fois passĂ© l’intĂ©gration continue, il est temps de livrer, n’est-ce pas ? JĂ©rĂ©mie et son Ă©quipe ont pris le parti d’adopter un modĂšle de release train de 6 semaines, plutĂŽt que de dĂ©ployer en continu. Cela pour s’assurer un nombre suffisant de contenu et ainsi mieux faire valoir les amĂ©liorations auprĂšs des utilisateurs. Le process de release qui nous est dĂ©crit est vraiment poussĂ© niveau automatisation, allant jusqu’Ă  automatiser les screenshots, vĂ©rifier que les permissions demandĂ©es sur le store n’excĂšde pas celles requises par le fonctionnel de l’application et utiliser l’API du playstore pour pousser le prĂ©cieux artefact.

A travers cette prĂ©sentation, JĂ©rĂ©mie a dĂ©montrĂ© que le monde de la mobilitĂ© comprend des dĂ©veloppeurs rĂ©ellement impliquĂ©s dans la qualitĂ© de ce qu’ils produisent. C’est trĂšs plaisant !

Fin du BreizhCamp

C’Ă©tait le dernier rĂ©sumĂ© du Breizhcamp sur notre blog. Je remercie sincĂšrement les organisateurs et les speakers qui ont sacrĂ©ment assurĂ©. Personnellement, c’Ă©tait mon premier Breizhcamp et une chose est sĂ»re, je serai prĂ©sent l’an prochain. J’espĂšre que notre retour vous a aussi donnĂ© envie d’y aller ! On s’y retrouve l’an prochain ?

Si vous avez raté nos deux premiers résumés, vous pouvez toujours consulter le résumé du premier de jour de Breizhcamp et aussi la journée de jeudi.

Catégories: Blog Société

Épilogue sur la Communication NonViolente (CNV)

Marshall B. Rosenberg

“La CNV favorise un dĂ©veloppement moral fondĂ© sur l’autonomie et l’interdĂ©pendance qui nous amĂšne Ă  reconnaĂźtre notre responsabilitĂ© pour nos actes, Ă  rĂ©aliser que notre propre bien-ĂȘtre et celui des autres ne font qu’un.”

En résumé :

Les quatre piliers de la Communication Non Violente (par Maxence Walbrou, OCTO Technology)

Source : http://bloculus.com/communication-non-violente-fondamentaux/

 

Je termine cette sĂ©rie d’article par un autre exemple que j’ai vĂ©cu rĂ©cemment avec ma femme en appliquant la CNV :

 

Un samedi soir, lors d’un repas entre amis, un collĂšgue me demande que je lui montre une vidĂ©o sur le Systema. TrĂšs motivĂ© Ă  l’idĂ©e de lui montrer ce qu’il se cache derriĂšre ce sport, j’ai pris l’iPad et lancĂ© une vidĂ©o. Ma femme (StĂ©phanie) me dit.

Stéphanie

“DĂ©cidĂ©ment ce Systema prend vraiment beaucoup trop de place dans notre couple en ce moment ! Ça commence Ă  me saouler !”.

Ne souhaitant pas crĂ©er de conflits devant nos amis, j’ai attendu d’ĂȘtre dans la voiture sur le trajet du retour pour comprendre sa rĂ©action.

Nicolas

“Quand j’ai lancĂ© la vidĂ©o, tu Ă©tais en colĂšre parce que tu aimerais que je te consacre plus de temps quand on est Ă  la maison ?”

Stéphanie

“Pas du tout je ne suis pas en colĂšre. Tu sais que tu peux faire ce que tu veux et que je ne t’empĂȘche rien.”

Quand nous reformulons le besoin de quelqu’un nous pouvons nous tromper (la CNV n’est pas une science infaillible !). J’aurais pu m’emporter en lui disant que je n’ai regardĂ© que deux ou trois vidĂ©os rĂ©cemment et que je trouvais son comportement injuste (ce qui aurait eu comme consĂ©quence de tendre la relation). J’ai privilĂ©giĂ© d’aller plus loin en rĂ©essayant de deviner son sentiment et son besoin.

Nicolas

“Tu es Ă©nervĂ©e parce que tu voudrais que je ne regarde pas ces vidĂ©os en ta prĂ©sence au regard des scĂšnes de violence ?”

Stéphanie

“Ça m’a Ă©nervĂ© oui mais ce n’est pas Ă  cause des scĂšnes de violence.”

Nicolas

“Je suis frustrĂ© car j’ai besoin de savoir ce que j’aurais pu faire ou dire en regardant la vidĂ©o sans susciter de l’énervement ?”

Stéphanie

“En fait ce qui me gĂȘne c’est le bruit associĂ© Ă  la vidĂ©o. Quand nous Ă©tions Ă  table et que tu as montrĂ© cette vidĂ©o ça m’a rappelĂ© la maison et Ă  quel point ces bruits sont dĂ©sagrĂ©ables quand tu regardes ces vidĂ©os.”

Nicolas (trĂšs Ă©tonnĂ© par ce que je venais d’entendre)

“Ah bon ! Je comprends donc que ce n’est pas le fait que je regarde les vidĂ©os qui te gĂȘne mais le bruit associĂ© quand je les regarde ?”

Stéphanie

“Oui car quand je lis ou regarde la tĂ©lĂ©, je n’aime pas avoir ce genre de bruits Ă  cĂŽtĂ©.”

Nicolas

“Du coup si je mets des Ă©couteurs quand je regarde ces vidĂ©os, tu n’éprouveras plus ce sentiment d’énervement ?”

Stéphanie

“Oui c’est ça mon chĂ©ri !”

Cette situation m’a fait prendre conscience que les premiĂšres rĂ©actions ne sont pas nĂ©cessairement rĂ©vĂ©latrices des sentiments et des besoins profonds de l’autre personne. La communication avec empathie permet de communiquer ce que nous ressentons avec sincĂ©ritĂ© et inviter l’autre Ă  faire de mĂȘme.

Il existe encore bien d’autres domaines traitĂ©s dans le livre de Marshall B. Rosenberg qui n’ont pas Ă©tĂ© abordĂ©s dans cette sĂ©rie d’articles (exprimer pleinement la colĂšre, user de la force dans un but de protection et non de rĂ©pression, remercier en pratiquant la CNV, etc.). Quoi qu’il en soit, cette approche saine permet selon moi de protĂ©ger et prĂ©server la relation avec l’autre tout en Ă©tant conscient des intentions, des sentiments et des besoins respectifs de chacun. MĂȘme si cela nĂ©cessite vraiment du travail pour parvenir Ă  garder la prise de recul sur soi-mĂȘme Ă  chaque instant, ĂȘtre conscient de ses besoins
 je suis convaincu que la CNV saura nous aider dans n’importe qu’elle situation de tension que nous rencontrerons durant notre vie et qu’elle nous permettra de vivre en harmonie avec nous-mĂȘmes et les autres.

Nicolas Cappello

Articles suggested :

  1. Les formes de communication bloquant la compassion et l’empathie
  2. Premiùre composante de la Communication NonViolente (CNV) : OBSERVER SANS ÉVALUER
  3. DeuxiĂšme composante de la Communication NonViolente (CNV) : IDENTIFIER ET EXPRIMER SES SENTIMENTS

Catégories: Blog Société

Modélisation Cassandra : Stocker des fichiers

Blog d’Ippon Technologies - jeu, 04/07/2016 - 15:25

Aujourd’hui, nous allons voir comment stocker des fichiers dans Cassandra. C’est une opĂ©ration assez facile qui permet de bĂ©nĂ©ficier de tous les avantages d’un cluster hautement disponible dont les donnĂ©es sont rĂ©parties et rĂ©pliquĂ©es dans plusieurs centres de calcul.

Enregistrer des fichiers est un besoin courant. Les rĂ©seaux sociaux enregistrent les photos de leurs utilisateurs. Les catalogues de produits stockent leurs images. Les applications de messagerie ou de gestion de dossiers permettent d’attacher des piĂšces jointes. Sans parler des GED ou des systĂšmes de gestion d’archives qui dĂ©passent le cadre de cet article. À chaque fois, vous aurez le choix entre conserver les fichiers dans la base de donnĂ©es applicative ou dans un systĂšme spĂ©cialisĂ© Ă  part. Il s’agit d’un choix d’architecture qui dĂ©pend des besoins et des volumes de chaque cas.

Stocker dans la base de donnĂ©es permet de simplifier l’architecture du systĂšme en Ă©vitant d’ajouter un composant technique supplĂ©mentaire. Cela facilite aussi la gestion des sauvegardes puisque toutes les donnĂ©es sont prĂ©sentes au mĂȘme endroit. Avec un seul systĂšme Ă  sauvegarder et Ă  restaurer, la cohĂ©rence des donnĂ©es aprĂšs restauration est garantie. Ce choix est adaptĂ© aux applications qui conservent peu de petits fichiers.

Disposer d’un systĂšme spĂ©cifique, c’est avoir la garantie de conserver les fichiers dans un systĂšme adaptĂ©. On Ă©vite ainsi de perturber les performances de la base de donnĂ©es avec les donnĂ©es binaires. Et l’on peut utiliser des mĂ©canismes de stockage moins chers. Ce choix sera gĂ©nĂ©ralement mis en Ɠuvre quand le nombre ou la taille des fichiers devient important.

Notez que nous ne choisissons pas une solution particuliĂšre. Le stockage dans Cassandra peut rĂ©sulter d’un stockage dans la base applicative (qui sera ici C*) ou d’un stockage dans un systĂšme dĂ©diĂ©.

PremiÚre modélisation

Nous allons commencer par le cas le plus simple Ă  modĂ©liser. Il s’agit tout simplement de crĂ©er une table pour conserver l’intĂ©gralitĂ© des donnĂ©es. Cette table unique est identifiĂ©e par l’identifiant du fichier. Elle est interrogĂ©e Ă  partir de celui-ci (RequĂȘte Q1).

Elle contient en plus des mĂ©tadonnĂ©es, ou donnĂ©es descriptives, qui dĂ©pendent de votre application. Dans l’exemple, les mĂ©tadonnĂ©es sont :

  • la taille du fichier,
  • le propriĂ©taire,
  • la date de crĂ©ation,
  • un ensemble de permissions.

Le contenu y est enregistré à cÎté des métadonnées descriptives.

Cette solution est actuellement mise en Ɠuvre chez un de nos clients.

Elle présente des avantages majeurs :

  • Le modĂšle est simple et facile Ă  comprendre.
  • Une seule requĂȘte suffit pour rĂ©cupĂ©rer le fichier et ses mĂ©tadonnĂ©es.

Elle présente aussi un inconvénient vital :

  • Ce modĂšle n’est viable que si la taille des fichiers est petite et bornĂ©e. En effet, Cassandra est sensible aux partitions de trop grandes tailles qui saturent sa mĂ©moire et sollicitent le garbage collector.

Ainsi, vous pouvez envisager cette solution lorsque vos fichiers ont une taille moyenne de 50 Ko et maximale de 5 Ă  10 Mo.

DĂ©couper les fichiers

Dans le cas général, il sera préférable de découper les fichiers en blocs qui seront stockés dans des partitions différentes. Pour cela, deux tables seront utilisées :

  1. La premiÚre contient les métadonnées du document.
  2. Et l’autre le contenu.

Le choix de la taille d’un bloc est l’objet d’un compromis entre le nombre de blocs, et donc le nombre de requĂȘtes nĂ©cessaires pour la lecture et l’Ă©criture du contenu, et la fluiditĂ© de leur gestion. Une taille de 64 Kio semble raisonnable de nos jours. C’est d’ailleurs, la taille des blocs de MongoDB GridFS.

On obtient alors le modĂšle suivant:

Cette fois-ci, on a :

  1. une table contenant les métadonnées,
  2. une table contenant les blocs de données.

Indiquer la taille du fichier est devenue nĂ©cessaire, car elle permet au lecteur d’en dĂ©duire le nombre de blocs Ă  lire. À la place, on aurait pu ajouter le nombre de blocs, mais la taille exacte est plus intĂ©ressante.

Chaque bloc est identifiĂ© par l’ID du fichier et un index reprĂ©sentant sa position dans le fichier. La clĂ© primaire est identique Ă  la clĂ© de partition pour s’assurer de la maitrise de la taille de cette derniĂšre.

Le modĂšle s’organise autour de deux requĂȘtes:

  • Q1 vĂ©rifie l’existence du fichier et lit les mĂ©tadonnĂ©es, dont la taille.
  • Q2 lit un bloc de donnĂ©es.

En gĂ©nĂ©ral, on boucle sur l’index pour lire toutes les valeurs.

Content Addressable Storage

La modĂ©lisation actuelle fonctionne correctement. Cependant, il est possible d’optimiser l’espace consommĂ©. En effet, jusqu’Ă  prĂ©sent, un fichier dĂ©posĂ© par des chemins diffĂ©rents sera enregistrĂ© plusieurs fois. Ce sera le cas si plusieurs personnes tĂ©lĂ©versent le mĂȘme document. Imaginez le nombre de copies d’un courriel ou de ses piĂšces jointes dans un systĂšme d’archivage de la messagerie d’une grande entreprise !

Pour Ă©viter le gaspillage, nous allons tenter de dĂ©doublonner les fichiers et ne conserver qu’une copie du contenu.

Une solution naĂŻve consisterait Ă  chercher les fichiers de mĂȘme contenus. Évidemment, on ne cherche pas le contenu lui-mĂȘme, mais un condensat, ou une empreinte, qui permet de trouver le doublon. Si cette solution fonctionne en principe, elle n’est pas adaptĂ©e Ă  Cassandra puisqu’elle impose une lecture avant l’Ă©criture (read-before-write). En plus, il faudra prĂ©voir une vue matĂ©rialisĂ©e pour permettre cette lecture.

On peut faire mieux en utilisant directement l’empreinte comme identifiant. Au lieu d’ĂȘtre arbitraire, l’identifiant devient intrinsĂšque au contenu. Sa valeur est dĂ©terministe et indĂ©pendante du contexte. Cette pratique est suffisamment courante pour avoir un nom : Content Addressable Storage, ou stockage indexĂ© par le contenu. Et vous l’utilisez tous les jours, puisque git qui identifie ses objets par leur SHA-1 repose sur un CAS. Cependant, le CAS prĂ©sente des contraintes. Par exemple, le contenu d’un fichier ne peut pas changer puisqu’un changement de contenu change l’identifiant. De plus, dans le cadre d’une gestion de fichiers, deux fichiers de mĂȘme contenu sont identiques.

Dans le cas pratique, on utilisera le CAS pour la conservation du contenu et de sa description intrinsĂšque. On utilisera un stockage traditionnel pour la description contextuelle du fichier.

Ainsi, on a :

    1. une table fichier identifiée par un uuid contenant :
      • les mĂ©tadonnĂ©es contextuelles (propriĂ©taire, date de crĂ©ation, permissions) ;
      • le lien vers le contenu et des champs dĂ©normalisĂ©s ;
    2. une table contenu identifiĂ©e par l’empreinte et contenant les informations descriptives du contenu ;
    3. une table bloc avec le contenu découpé en bloc.

avec-cas

Une optimisation utile permet de stocker les premiers octets, souvent le 1er Kio, dans les mĂ©tadonnĂ©es (champ first_bytes). Ce peut ĂȘtre utile dans le cas oĂč il est frĂ©quent de ne lire que les entĂȘtes (pour dĂ©terminer le type du fichier par exemple) ou lorsque l’application gĂšre de nombreux petits fichiers.

Ce modĂšle fonctionne bien pour l’Ă©criture sans modification des contenus. Dans le cas ou un fichier peut ĂȘtre supprimĂ© ou que son contenu peut ĂȘtre modifiĂ©, il faudra ajouter un mĂ©canisme de collection des contenus inutilisĂ©s. Il s’appuiera sur un champ permettant de savoir si un contenu est utilisĂ©. Sa modĂ©lisation est laissĂ©e en exercice. Proposez vos solutions en commentaire.

Conclusion

Comme nous l’avons vu, le stockage efficace de fichiers dans Cassandra est relativement facile. La complexitĂ© dĂ©pendra du cas fonctionnel et des optimisations souhaitĂ©es. La seule difficultĂ© se situe dans la maitrise de la taille des partitions qui nous oblige Ă  dĂ©couper le fichier dans le cas gĂ©nĂ©ral.

Catégories: Blog Société

Le before du Devoxx avec Matt Raible

Blog d’Ippon Technologies - jeu, 04/07/2016 - 14:26

mattraibleMatt Raible est une figure bien connue dans la communautĂ© Java. Depuis plus de 17 ans, il a aidĂ© des entreprises Ă  adopter des frameworks open source afin de les utiliser efficacement. Il a notamment Ă©tĂ© Lead UI Architect pour LinkedIn , UI Architect pour Evite.com et l’architecte en chef du dĂ©veloppement Web de Time Warner Cable.

Matt a Ă©tĂ© confĂ©rencier lors de nombreuses confĂ©rences dans le monde entier (Devoxx , Jfokus , No Fluff Juste Stuff , SpringOne 2GX , UberConf , Sommet angulaire…) Il a Ă©tĂ© rĂ©compensĂ© en 2013 d’un JavaOne Rock Star.

L’auteur du “JHipster Mini-Book”, animera Ă©galement une confĂ©rence lors du Devoxx : Get Hip with JHipster: Spring Boot + AngularJS + Bootstrap.

Le 19 avril Ă  partir de 19h sera une occasion unique d’Ă©changer avec la star sur le rooftop Ippon.

Un beau before autour d’un buffet australien avant d’entamer 3 jours de confĂ©rences Devoxx.

 

Développé par Eventbrite
Catégories: Blog Société

Découvrez le pré-programme de la conférence USI 2016

Pensez la transformation numĂ©rique autrement…

Cette annĂ©e encore, la confĂ©rence USI vous accueille au prestigieux Carrousel du Louvre. 1 500 participants sont attendus pour cette 9e Ă©dition, dont nous sommes fiers de vous prĂ©senter aujourd’hui les contours.

USI a toujours Ă  cƓur de penser la transformation digitale autrement. De vous surprendre et vous offrir une intensitĂ© intellectuelle rare.

“Beaucoup de sĂ©minaires mettent l’accent sur la rencontre, le rĂ©seau, au dĂ©triment parfois du contenu des confĂ©rences
 Alors que pour nous, c’est le plus important. Au-delĂ  du prestige, les speakers portent un savoir que l’on ne veut pas rater. Nous voulons provoquer une Ă©motion qui reste, que ce soit sur des sujets IT, de management, ou encore d’innovation et de prospective. Et tous sont, selon moi, intimement liĂ©s.” nous confie François Hisquin, fondateur de la confĂ©rence.

Le pré-programme USI 2016 répond parfaitement à ces aspirations.

Capture d'écran 2016-04-06 18.37.35

 

Zoom sur les keynotes 2016

 

Photo Andrew McafeeAndrew McAfee

Co-directeur du MIT Initiative of the Digital Economy

The Second Machine Age

VĂ©ritable rĂ©fĂ©rence au MIT, Andrew McAfee consacre la majoritĂ© de ses travaux Ă  l’impact des technologies sur notre Ă©conomie, nos business model et notre sociĂ©tĂ©.

IA, robots domestiques, voitures autonomes, algorithmes
 Son dernier best-seller co-Ă©crit avec Erik Brynjolfsson, The Second Machine Age, McAfee pousse la relation homme-machine jusqu’à sa prochaine Ă©tape : celle de la substitution.

Face à ces innovations dignes d’un roman de science-fiction, repenser nos organisations et nos contrats sociaux n’est plus une option. Andrew McAfee nous servira de guide à travers cet ouragan technologique.

 

Monica LewinskyMonica Lewinsky

Social Activist / Contributeur pour Vanity Fair

The Price of Shame

PremiĂšre victime de harcĂšlement sur Internet, Monica Lewinsky soulĂšvera le voile sur ce cĂŽtĂ© obscur de la Toile. Le phĂ©nomĂšne n’a rien d’anodin. Ses victimes : les personnes jeunes et vulnĂ©rables, mais Ă©galement le Web qui perd son essence informative au profit de dĂ©bats haineux et stĂ©riles. Un contrepoint essentiel pour apprĂ©hender les technologies numĂ©riques, abordĂ© avec intelligence par celle qui a du rĂ©inventer sa vie.

 

Photo Juan EnriquezJuan Enriquez

Directeur d’Excel Venture Management

Homo Evolutis

L’Homme a bouleversĂ© l’ordre de la sĂ©lection naturelle. L’évolution tient dĂ©sormais au choix de notre espĂšce sur ce qui doit vivre, mourir ou mĂȘme ĂȘtre modifiĂ©. Quelles en seront les consĂ©quences sur les gĂ©nĂ©rations Ă  venir ?

Auteur d’un large panel d’ouvrages techniques et sociologiques, Juan Enriquez a cette Ă©tonnante capacitĂ© Ă  croiser les savoirs, pour nous offrir un horizon d’autant plus pertinent de l’avenir. Une figure de rĂ©fĂ©rence dans le domaine de la gĂ©nomique.

 

Sa premiĂšre venue Ă  l’USI 2013 reste gravĂ©e dans la mĂ©moire des participants


Photo Yuval HarariYuval Harari

Auteur et Professeur Hebrew University of Jerusalem

Homo Sapiens

MĂȘlant sciences et histoire, Yuval Harari nous rĂ©vĂšlera comment l’Homo Sapiens s’est imposĂ© parmi les espĂšces, pour rĂ©gner aujourd’hui en maĂźtre. Mythes, religion, argent, nation, consommation
  Cet odyssĂ©e de l’homme nous poussera Ă   nous interroger sur l’avenir : quelle espĂšce voulons-nous rĂ©ellement devenir ?

 

Photo Brian MuirheadBrian Muirhead

Ingénieur en chef NASA Jet Propulsion Laboratory

Going to Mars

Son dernier ouvrage Going to Mars nous propulse dans les coulisses des missions d’exploration de Mars.

Brian Muirhead n’a pas seulement la connaissance, les anecdotes et la sagesse des personnes du terrain, c’est aussi un storyteller de talent. C’est avec passion qu’il partagera avec nous les challenges et les questionnements que suscitent toute dĂ©couverte d’un terrain inconnu. Une vision qui s’appliquerait tout aussi bien au monde de l’entreprise…

 

Photo Luc de BrabandereLuc de BarbandĂšre

Senior Advisor et CEO Boston Consulting Group & Cartoonbase

Homo Informaticus

PrĂ©sentĂ©e pour la premiĂšre fois Ă  l’USI 2016, la confĂ©rence de Luc de BrabandĂšre nous racontera une histoire passionnante : la nĂŽtre. À travers une fresque animĂ©e, le philosophe dĂ©ploiera 4 000 ans d’avancĂ©es techniques, d’Aristote Ă  Blaise Pascal en passant par George Boole ou encore Leibniz.

Pour sa troisiĂšme participation Ă  l’USI, cet orateur hors pair nous promet un voyage Ă©tonnant.

 

Photo Don TapscottDon Tapscott

CEO Tapscott Group

Blockchain Revolution

AprĂšs l’Internet de l’information, la technologie Blockchain nous apporte l’Internet de la valeur. Don Taspcott abordera les opportunitĂ©s et les risques de cette technologie publique, cryptĂ©e et dĂ©jĂ  incontournable. L’analyse d’un expert en business strategy, classĂ© 4e “business thinker” au monde par Thinkers50 2015, et auteur des bestsellers Wikinomics et The Digital Economy.

 

Photo Daniel CohenDaniel Cohen

Economiste

Homo Economicus

Daniel Cohen est un Ă©conomiste pragmatique. Son but : nous sortir la tĂȘte de nos aspirations pour nous ancrer, Ă  nouveau, dans la rĂ©alitĂ©.

Nous vivons une pĂ©riode particuliĂšre : une 3e rĂ©volution industrielle – axĂ©e sur le numĂ©rique – mais sans croissance. Un modĂšle pour lequel nous ne sommes pas prĂ©parĂ©s, et auquel s’ajoute sentiment d’insĂ©curitĂ© paralysant. Comment sortir de cette sociĂ©tĂ© de l’insĂ©curitĂ© et rĂ©inventer nos modĂšles Ă©conomiques ?

Daniel Cohen nous proposera quelques solutions… Pragmatiques.

 

A dĂ©couvrir Ă©galement Ă  l’USI…

 

Photo Richard SheridanRichard Sheridan

CEO Menlo Innovation

Build a workplace people love – Just add joy

Pour Richard Sheridan, la joie a toute sa place en entreprise. C’est mĂȘme le secret de la productivitĂ© ! Partant de sa propre expĂ©rience, ce passionnĂ© d’informatique et auteur de Joy Inc. nous donnera les clĂ©s de son approche originale et enthousiasmante de la culture d’entreprise.

 

Photo KarenMcGraneKaren McGrane

CEO Managing Partner

Content in a zombie apocalypse

Appareils mobiles, Ă©crans multiples
 Nous croulons sous les plate-formes de contenu digital. Une vĂ©ritable apocalypse zombie ! Pour survivre, l’experte UX Karen McGrane a la solution : mettre en place un stratĂ©gie Ă©ditoriale qui traiterait chaque plate-forme d’égal Ă  Ă©gal. Un talk essentiel pour maĂźtriser le contenu de demain.

 

Photo Cathy O'NeilCathy O’Neil

Mathématicien, ecrivain

Weapons of math destruction

Titulaire d’un doctorat en mathĂ©matiques Ă  l’universitĂ© d’Harvard, Cathy O’Neil est une data-sceptique. Et pour cause : cette spĂ©cialise du Big Data et des algorithmes a suffisamment Ă©tudiĂ© ces questions pour en connaĂźtre les opportunitĂ©s
 et les dangers. Comment faire en sorte que les algorithmes soient de notre cĂŽtĂ© ? RĂ©ponses Ă  l’USI, avec la pertinente Cathy O’Neil.

 

Photo Emmanuel JaffelinEmmanuel Jaffelin

Philosophe, Écrivain

L’éloge de la gentillesse

Sommes-nous terriblement cyniques pour percevoir la gentillesse comme une faiblesse ? Pour Emmanuel Jaffelin, cette qualitĂ© permet pourtant de faire le lien entre nos vieilles civilisations de l’honneur et l’entreprise du bonheur. Une vertue 3.0 !

 

Photo Lyndsey ScottLindsey Scott

DĂ©veloppeur d’applications mobiles

The INs and OUTs of Mobile App Development

DiplomĂ©e en Sciences informatiques Ă  l’Amherst College, Lindsey Scott s’est spĂ©cialisĂ©e dans le dĂ©veloppement d’applications mobiles. MĂȘlant thĂ©orie et dĂ©mo, la dĂ©veloppeuse fera le point sur les piĂšges et les idĂ©es reçues auxquels les professionnels du code sont confrontĂ©s.

Un talk pour démystifier le développement mobile.

 

Photo de Mark EspositoMarc Esposito

Professeur Harvard University & Grenoble Ecole de Management

The circular economy: society’s last chance ?

À force d’exploiter les ressources naturelles Ă  l’excĂšs, le coĂ»t et les consĂ©quences de notre croissance atteignent aujourd’hui une limite critique. Les risques d’inflation et la dĂ©valorisation des biens immobiliers nous poussent Ă  reconsidĂ©rer notre modĂšle Ă©conomique. Pour Mark Esposito, passer d’une Ă©conomie linĂ©aire Ă  un schĂ©ma “circulaire” serait une opportunitĂ© pouvant valoir des billions de dollars ! Pour en savoir plus, rendez-vous Ă  l’USI…

 

 

 

 

Catégories: Blog Société

Atelier – Plateforme 1 – AWS (2/3)

Les recettes IoT de l'atelier Xebia

La semaine derniÚre, nous avons envoyé les données notre objet connecté vers AWS. Cette semaine, nous allons compléter la liste de nos exigences fonctionnelles en ajoutant les services additionnels, et en gérant le downlink.

Stocker les données.

Pour ceux qui ont l’habitude de AWS, il n’y aura pas vraiment de surprise. Amazon offre en effet un service de base de donnĂ©es non relationnelle orientĂ©e document, Ă  savoir DynamoDB. Et comme AWS sait si bien le faire, l’intĂ©gration entre IoT et DynamoDB est aisĂ©e.

Retournons donc dans l’onglet IoT. Nous allons ajouter une nouvelle rĂšgle de gestion.

AWS IoT

Il suffit ensuite de choisir DynamoDB dans la liste dĂ©roulante. Fait trĂšs apprĂ©ciable, si votre base n’est pas prĂ©existante, AWS vous permet de la crĂ©er Ă  partir de cet Ă©cran. Nous verrons que ce n’est pas le cas chez tous les fournisseurs.

Les mĂ©canismes internes de DynamoDB, et notre façon d’accĂ©der aux donnĂ©es nous pousse vers un design simple : crĂ©er un clĂ© primaire composite, avec l’identifiant de l’objet comme clĂ© de hachage (toutes les donnĂ©es relatives Ă  un objet se retrouveront sur la mĂȘme partition), et le timestamp de la mesure comme clĂ© de tri (les donnĂ©es seront ordonnĂ©es chronologiquement sur le disque). Petite subtilitĂ©, que je n’ai pas rĂ©ussi Ă  m’expliquer : votre colonne time doit ĂȘtre au format string, faute de quoi DynamoDB refusera vos messages. Il semblerait que bien que le JSON de debug gĂ©nĂ©rĂ© dans S3 montre que le champ time est un format number, mais que la communication entre ioT et Dynamo le « convertit » en string.

DynamoDB

AWS IoT

Créez votre action, et en déclenchant votre objet connecté (ou une simulation via Postman), vous devriez voir votre table se remplir :

DynamoDB AWS

Alerter par email

Mettons maintenant en place une simple rĂšgle mĂ©tier : envoyer un mail d’alerte si la tempĂ©rature dĂ©passe 27°C. LĂ  encore, tout se fait au niveau des actions disponibles dans le module IoT.

DynamoDB AWS

Il suffit d’adapter la requĂȘte de sĂ©lection des donnĂ©es pour qu’elle reflĂšte cette rĂšgle simple. On ajoute donc une restriction dans la colonne Condition.

Souscrire Ă  Amazon Web Service

En ce qui concerne l’action dĂ©clenchĂ©e, nous allons utiliser le service de notification d’AWS, SNS. LĂ  encore, chose agrĂ©able, il est possible de crĂ©er la file SNS (et le rĂŽle associĂ©) directement depuis le module IoT.

Ensuite, direction SNS, pour ajouter un envoi de mail lors de la rĂ©ception d’un message dans la file.

Et là, magie, dÚs que votre objet envoie à Sigfox un message contenant une température supérieure à 27°C, Lambda transmet le message à IoT, qui fait suivre le message à SNS, qui transforme ce message en email :

Notification AWS

Pour un email un peu plus élaboré, il faut concocter une architecture un peu plus complexe, qui enverra un évÚnement dans le service dédié, SES.

Mettre Ă  jour un dashboard

Dernier Ă©tage de la fusĂ©e, pousser les donnĂ©es collectĂ©es sur un Dashboard « temps rĂ©el ». LĂ  au moins, c’est simple, AWS ne propose pas ce type de service. Vous avez donc deux choix : hĂ©berger votre propre instance (par exemple en utilisant Dashing) ou bien vous reposer sur un service SaaS externe. Nous avons choisi cette derniĂšre solution, avec un service de dashboarding extrĂȘmement simple, Dashku.

Une fois inscrit, nous allons créer un tableau de bord basique, affichant les derniÚres valeurs reçues par chacun de nos trois capteurs.

Sigfox IoT

Pour cela, il faut pousser Ă  chacun des trois panels un fichier JSON en REST. Vous pouvez obtenir un exemple de code d’appel depuis NodeJs en cliquant sur l’engrenage, puis sur la pastille verte. Le code ressemble Ă  celui ci :

var request = require("request");

var data = {
  "bigNumber": 500,
  "_id": "56f028b053146d7909011xxx",
  "apiKey": "7c3585c7-3ac8-45fb-840a-3e33d7e6fxxx"
};

request.post({url: "https://dashku.com/api/transmission", body: data, json: true});

L’apiKey est identique pour chacun des panels ; en revanche, l’_id varie.

Pour que notre dashboard retrouve ses petits, il est nĂ©cessaire d’Ă©diter chacun des widgets, pour les rendre plus parlant. ParamĂ©trez donc les onglets HTML, CSS, et Javascript pour remplacer data par le nim de vos champs dans le JSON Ă©mis par le module IoT (temperature, humidity et luminance).

Dasku IoT sigfox

Il reste donc Ă  faire le pont entre le module IoT d’AWS et un appel REST. Nous l’avons fait dans un sens lorsque nous avons crĂ©Ă© le bridge Sigfox, nous pouvons le faire dans l’autre sens en utilisant Lambda comme fonction de sortie au module IoT.

Reprenons donc notre Rule ‘Simple Debug’. Nous pouvons, en plus de S3, lui ajouter une sortie vers une Lambda, via le menu Edit actions.

IoT AWS resources

Comme vous en avez maintenant l’habitude, il est possible de crĂ©er une nouvelle Lambda directement depuis ce menu.

Nous pouvons crĂ©er la Lambda directement depuis l’Ă©diteur en ligne, celle ci est suffisamment simple pour qu’elle ne requiert pas un packaging Ă©voluĂ©. Nous avons simplement rĂ©Ă©crit la fonction extend pour Ă©viter d’avoir Ă  importer le package utils.

// Rewrite to avoir npm require
function extend(obj1,obj2){
    var obj3 = {};
    for (var attrname in obj1) { 
        obj3[attrname] = obj1[attrname]; 
    }
    for (var attrname in obj2) { 
        obj3[attrname] = obj2[attrname]; 
    }
    return obj3;
}

// AWS Lambda handler
exports.handler = function(event, context) {
    var httpCallsEmited = 0;
    var httpCallsEnded = 0;

    console.log('Input :', event);
    
    var data = {
        "temperature": event.temperature,
        "humidity": event.humidity,
        "luminance": event.luminance,
        "time": event.time, 
        "device": event.device,
        "apiKey": "7c3585c7-3ac8-45fb-840a-3e33d7e6fxxx"
    };
    

    function endHttpCall(err) {
        if (err) {
            context.fail("ERROR in http call");
        } else {

            httpCallsEnded++;
            if(httpCallsEmited==httpCallsEnded){
                context.succeed("SUCCESS");  
            }
        }
    }

    httpCallsEmited = 3;

    sendRequest(extend(data, {_id: "56f028b053146d7909011xxx"}), endHttpCall);
    sendRequest(extend(data, {_id: "56f028b453146d7909011xxx"}), endHttpCall);
    sendRequest(extend(data, {_id: "56f028b853146d7909011xxx"}), endHttpCall);
};

function sendRequest(data, callback){
    var http = require('https');
    
    var options = {
        rejectUnauthorized: false,
        host: 'dashku.com',
        port: 443,
        path: '/api/transmission',
        method: 'POST',
        headers: {
            'Content-Type': 'application/json'
        }
    };
    
    var req = http.request(options, function(res) {
        res.setEncoding('utf8');
        res.on('data', function (chunk) {
            console.log("body: " + chunk);
            callback();
        });
        res.on('error', function (err) {
            console.log("body: " + chunk);
            callback(err);
        });
    });

    req.write(JSON.stringify(data));
    console.log(JSON.stringify(data))
    req.end();
}

Si tout s’est bien passĂ©, chaque Ă©mission de votre objet Sigfox devrait maintenant mettre Ă  jour votre tableau de bord Dashku :

IoT sigfox Dashku

Cliffhanger

Nous en avons fini du traitement des données environnementales émises par notre objet connecté. Reste maintenant un gros morceau : le traitement des données en downlink, depuis notre cloud vers notre objet. Mais à chaque jour suffit sa peine ; nous verrons cela une prochaine fois.

Catégories: Blog Société

Afterwork Delivery Ă  GenĂšve le jeudi 14 avril : l’ADN d’un dĂ©veloppement produit rĂ©ussi

Afterwork_Delivery

Le dĂ©veloppement logiciel a beaucoup Ă©voluĂ© ces 10 derniĂšres annĂ©es : mĂ©thodes Agiles, intĂ©gration continue, tests, nouvelles architectures, Cloud, etc. Beaucoup de concepts utiles et nĂ©cessaires, mais pas suffisants Ă  la rĂ©ussite du dĂ©veloppement d’un nouveau produit.

Cette session ne vous aidera malheureusement pas Ă  dĂ©velopper une application sur base d’un Ă©pais cahier de spĂ©cifications, en respectant le budget, les dĂ©lais et la qualitĂ©. Mais elle vous permettra de rĂ©ussir un produit de qualitĂ©, Ă  forte valeur ajoutĂ©e pour vos utilisateurs ou clients, dans les temps et au budget escomptĂ© !

Au travers de retours d’expĂ©rience rĂ©cents, nous vous montrerons comment sont menĂ©s de tels dĂ©veloppements chez OCTO. Nous vous parlerons notamment d’ingĂ©nierie, de gestion du produit, d’organisation et de process, mais Ă©galement de culture.

Mais rassurez-vous, tout ceci restera applicable à tout projet de développement, développé avec ou sans OCTO !

Cliquez ici pour vous inscrire Ă  cet afterwork

Articles suggested :

  1. Retour des DevOpsDays 2010 Ă  Hambourg
  2. OCTO accueille le 3Ăšme meetup devops parisien le 16 mars
  3. Afterwork à GenÚve le 2 juillet : Agilité & top management, une thérapie pour leurs principaux challenges ?

Catégories: Blog Société

Revue de Presse Xebia


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

Agilité Why Leaders Who Listen Achieve Breakthroughs http://www.gravatar.com/avatar/d7d78d3da06350afe7093ed2858455a3http://blog.xebia.fr/author/emmanuel-sciarahttp://twitter.com/esciarahttp://github.com/esciaraPar Emmanuel Sciara

L’agilitĂ© pose les bases d’une maniĂšre diffĂ©rente de communiquer. Et l’agilitĂ© se base sur un leadership partagĂ© aussi bien qu’un leadership individuel.

Dans les environnements/Ă©cosystĂšmes prĂ©-existants, en particulier dans les moyennes et grandes entreprises, la capacitĂ© de transformer dĂ©pend surtout de la capacitĂ© Ă  Ă©couter, plutĂŽt que de parler… C’est malheureusement souvent l’inverse qui se passe, et ce, quelque soit le niveau.

Elizabeth Doty explique succinctement dans son article pourquoi les leaders qui savent Ă©couter gĂ©nĂšrent des percĂ©es dans les transformations (agiles ou non) dans l’environnement complex qu’est l’entreprise. Elle y explique Ă©galement comment ces leaders mettent en place une vraie communication bidirectionnelle. A mĂ©diter, user, et abuser.

Quelles sont les 12 choses apparemment normales que quelqu’un d’agile fait ? http://www.gravatar.com/avatar/446d657538e086173eac4467a91c9d86http://blog.xebia.fr/author/omarquethttp://twitter.com/%40omarquetPar Olivier Marquet

C’est la question Ă  laquelle Mattias Skarin essaye de rĂ©pondre dans cet article.

C’est un petit parcours Ă  travers le manifeste agile, le Gemba walk, le PDCA ainsi qu’un peu de Management 3.0 et de servant leadership.
Finallement Mattias Skarin nous parle d’habitudes qui font dĂ©jĂ  la diffĂ©rence entre « faire de l’agile » et « ĂȘtre agile ».

Mobilité Xamarin gratuit et SDK open source http://www.gravatar.com/avatar/f02fe9ef6365e1a7d4c28838da4258bahttp://blog.xebia.fr/author/adrouillyPar Pascal Drouilly

Microsoft nous fait plein d’annonces open source dont celle ci: Xamarin now free in visual studio. Le SDK sera open sourcĂ© dans les prochains mois. Avec Swift en open source il y a vraiment une nouvelle tendance de la part d’acteurs trĂšs « propriĂ©taire » auparavant.

MĂȘme si Ă  Xebia nous privilĂ©gions les applications natives c’est une nouvelle notable. De plus pour une boite dĂ©jĂ  investi dans les technos C#/.Net cette annonce est une bonne nouvelle.

Objets connectĂ©s JournĂ©e « IoT Ă  l’IUT » http://www.gravatar.com/avatar/f02a4fb1606e6f98dd3ca1cd5d183448http://blog.xebia.fr/author/sbenferdjhttp://twitter.com/%40SamehBenFPar Sameh BEN FREDJ

Le vendredi 18 mars a eu lieu la journĂ©e « IoT Ă  l’IUT » organisĂ© par l’IUT de Paris Descartes.  Ayant pour objectif d’introduire un nouveau module autour de l’IoT dans les enseignements de l’IUT Ă  partir de l’annĂ©e prochaine, le but de cette journĂ©e Ă©tait de faire dĂ©couvrir et  de vulgariser le concept de l’IoT aux Ă©tudiants et aux enseignants .

Le programme de la journĂ©e Ă©tait riche. La journĂ©e Ă©tait sous forme de prĂ©sentations donnĂ©es par diffĂ©rents interlocuteurs pour montrer les diffĂ©rentes facettes de l’IoT. Xebia a participĂ© Ă  cet event.

Les prĂ©sentations de la matinĂ©e Ă©taient orientĂ©es entreprises et industries avec la prĂ©sence de Xebia, Sigfox, IBM et Microsoft. Alors que celles de l’aprĂšs-midi Ă©taient orientĂ©es recherche, projets Ă©tudiants  et startups avec la participation de l’Inria, professeurs et Ă©tudiants de l’IUT Paris Descartes .

Un retour sur cette journée ainsi que des vidéos des différentes présentations sont disponibles via ce lien.

Front Excess XSS, un tutorial simple pour Ă©viter les failles de type XSS http://www.gravatar.com/avatar/d2d7263cc510ef945bf738083be3c4f8http://blog.xebia.fr/author/pantoinehttp://twitter.com/PhilippeAntoinePar Philippe Antoine XSS est une technique d’injection de code malveillant sur votre site rendue possible par des formulaires mal protĂ©gĂ©s. Excess XSS (http://excess-xss.com/) nous propose de rĂ©sumer les diffĂ©rents types d’attaque XSS (Persistent, Reflected, DOM-based) et les soutions Ă  mettre en oeuvre pour les Ă©viter: – Utilisation de l’encoding cĂŽtĂ© client lorsque les valeurs des inputs sont rĂ©utilisĂ©s sur une page – Mise en place d’une validation des champs de formulaire cĂŽtĂ© serveur, via une « white list » – Si possible, activation du Content Security Policy sur votre site Persistent xss Utilisez une mise en page « holy grail » avec les CSS Grid http://www.gravatar.com/avatar/d2d7263cc510ef945bf738083be3c4f8http://blog.xebia.fr/author/pantoinehttp://twitter.com/PhilippeAntoinePar Philippe Antoine L’utilisation des CSS Grid est de plus en plus rĂ©pandue. (http://bitsofco.de/holy-grail-layout-css-grid/) Un article de bitsofcode nous propose une technique simple pour implĂ©menter un layout « holy grail » avec quelques lignes de CSS: Code HTML: <body class= »hg »>     <header class= »hg__header »>Title</header>   <main class= »hg__main »>Content</main>   <aside class= »hg__left »>Menu</aside>   <aside class= »hg__right »>Ads</aside>   <footer class= »hg__footer »>Footer</footer> </body> Code CSS: .hg__header { grid-area: header; } .hg__footer { grid-area: footer; } .hg__main { grid-area: main; } .hg__left { grid-area: navigation; } .hg__right { grid-area: ads; }   .hg {     display: grid;     grid-template-areas: « header header header »                          « navigation main ads »                          « footer footer footer »;     grid-template-columns: 150px 1fr 150px;     grid-template-rows: 100px                          1fr                         30px;     min-height: 100vh; }   @media screen and (max-width: 600px) {     .hg {         grid-template-areas: « header »                              « navigation »                              « main »                              « ads »                              « footer »;         grid-template-columns: 100%;         grid-template-rows: 100px                              50px                              1fr                             50px                              30px;     } } Holy Grail CSS Grid
Catégories: Blog Société

HockeyApp et Visual Studio Team Services au service de Xamarin

AprĂšs l’annonce, fin fĂ©vrier 2016, du rachat de Xamarin par Microsoft, l’attente concernant des nouveautĂ©s ou changements vis Ă  vis de Xamarin Ă©tait forte au dĂ©marrage de la Build, il y a quelques jours. Le mystĂšre planait autour de l’avenir de Xamarin, et c’est lors de la deuxiĂšme keynote de l’Ă©vĂšnement que la bonne nouvelle […]
Catégories: Blog Société

Breizhcamp 2016 – Compte-rendu de la journĂ©e du jeudi

breizhcamp 2016 conférence

Je suis arrivĂ© Ă  la deuxiĂšme journĂ©e du 24 mars aux alentours de 10h15, aprĂšs la keynote. Juste le temps de manger quelques croissants et de boire un verre de jus d’orange que la premiĂšre session de la matinĂ©e commence.

Docker en Production ? Et quid de la sĂ©curitĂ© ? – par Jean-Marc Meessen

C’est parti pour 55 minutes d’une confĂ©rence sur la sĂ©curitĂ© de docker prĂ©sentĂ©e par Jean-Marc Meessen. Barbe blanche et coiffĂ© de son chapeau, la ressemblance avec le capitaine Iglo de la cĂ©lĂšbre marque de poissons pannĂ©s est parfaite. Introduction sympathique et dĂ©contractĂ©e, accent belge et boite de chocolats pour la salle, le ton est donnĂ© :)

DĂšs les premiĂšres slides, le speaker martĂšle que la sĂ©curitĂ© ne doit pas ĂȘtre oubliĂ©e et laissĂ©e de cotĂ©. C’est une responsabilitĂ© morale de l’ensemble de la communautĂ© de dĂ©veloppement. DĂšs la conception de l’application, les dĂ©veloppeurs doivent ĂȘtre sensibilisĂ©s. Lorsqu’un logiciel ou framework met en avant la sĂ©curitĂ©, il doit trouver un bon compromis car une sĂ©curitĂ© trop compliquĂ©e rebute les gens et au final, ne va pas ĂȘtre utilisĂ©e.

On recense 4 types d’attaquants sur les rĂ©seaux :

  • script kiddie : ils ont peu de connaissance technique et ne font qu’appliquer des recettes dĂ©jĂ  faites qu’ils rĂ©cupĂšrent sur internet,

  • attaquant interne : il possĂšde une trĂšs bonne connaissance du systĂšme puisqu’il peut tout avoir crĂ©Ă© ou en partie,

  • mafia / crime organisĂ© : pas encore vraiment prĂ©sent ils sont encore au niveau des scripts kiddies,

  • Ă©tat : avec la NSA en tĂȘte, presque rien ne peut les arrĂȘter.

AprĂšs ce tour d’horizon gĂ©nĂ©ral sur la sĂ©curitĂ©, le speaker aborde les points faibles de Docker sur ce sujet :

  • kernel partagĂ© par l’ensemble containers : si un problĂšme touche le kernel, il sera propagĂ© Ă  l’ensemble des containers,

  • les containers tournent dans la mĂȘme daemon : si un container consomme toutes les ressources, l’ensemble du systĂšme est impactĂ©,

  • une fois dans le container un attaquant peut en sortir car l’environnement de sĂ©curisation est commun,

  • les images docker proviennent d’internet et ne sont pas forcĂ©ment Ă  jour (vieilles versions d’utilitaires, pas de patch) ou peuvent tout simplement ĂȘtre altĂ©rĂ©es.

L’Ă©quipe de Docker a pleinement conscience de ces problĂšmes et de sa jeunesse du projet. A l’instar des projets agiles, ils ont sorti un MVP (Minimum Viable Product) pour ensuite l’amĂ©liorer et l’enrichir. Ainsi, afin d’apporter des solutions aux problĂšmes citĂ©s prĂ©cĂ©demment, Docker supporte maintenant tous les niveaux d’isolation du noyau Linux et propose un systĂšme de capabilities drop qui permet d’affiner les droits d’un container.

En pĂ©riphĂ©rie, du daemon et du client, Docker Ă  mis en place une infrastructure pour ĂȘtre capable de dire si le container qui est publiĂ© sur son registry a Ă©tĂ© altĂ©rĂ© pendant le transfert. En plus de cela, l’outil Docker Notary permet d’identifier de maniĂšre sĂ»re chacune des couches des images et de les signer pour Ă©viter une quelconque altĂ©ration. Il existe Ă©galement Nautilus un scanner d’images docker dĂ©tectant si la version de l’os ou des utilitaires sont Ă  jour.

Le speaker nous propose de conclure sa présentation par quelques recommandations :

  • maintenir l’hĂŽte et les images Ă  jour,

  • cloisonner en crĂ©ant une partition disque docker sĂ©parĂ©e, et pourquoi pas placer les container dans une VM,

  • limiter les communications inter-containers en Ă©tant au maximum Ă©tanche,

  • loguer tout les changements,

  • contrĂŽler les accĂšs,

  • ne pas utiliser le mode privileged s’il n’est pas nĂ©cessaire,

  • utiliser des utilisateurs applicatifs dans le container plutĂŽt que root.

Pour lui la question de savoir si Docker est sĂ©curisĂ© est une fausse question, plutĂŽt de l’ordre de la discussion de bistrot. En fonction des besoins et de la sĂ©curitĂ© espĂ©rĂ©e, les efforts seront fait pour obtenir un systĂšme dont le niveau de sĂ©curitĂ© est acceptable.

Jenkins 2.0 – On jette tout et on recommence ? – par Arnaud HĂ©ritier

La deuxiĂšme confĂ©rence Ă  laquelle j’ai assistĂ© est prĂ©sentĂ©e par Arnaud HĂ©ritier qui se propose de nous faire un tour d’horizon de Jenkins 2.0. Le sondage Ă  mains levĂ©es indique que la salle connaĂźt l’outil, la prĂ©sentation de Jenkins ne s’éternise donc pas et nous rentrons directement dans le vif du sujet. Mais avant d’aborder les nouveautĂ©s apportĂ©es par la version 2.0 Arnaud nous rappelle ce qui fait les forces et les faiblesses de la version 1.X :

  • L’installation est trĂšs simple puisqu’il suffit de tĂ©lĂ©charger et d’exĂ©cuter un war,

  • Les notions vĂ©hiculĂ©es sont rudimentaires car il est question de « job ». Il est possible de faire une chaĂźne basique en chaĂźnant des jobs entre eux. Cette façon de procĂ©der (build, job) n’est pas adaptĂ©e pour adresser les problĂ©matiques actuelles de continuous delivery,

  • L’Ă©cosystĂšme gravitant autour du produit est riche voire mĂȘme un peu trop. Parmi le millier de plugins il est difficile de savoir lesquels sont nĂ©cessaires au dĂ©marrage d’un projet. Les nouveaux se retrouvent noyĂ©s dans la masse. Au final cela rend l’expĂ©rience utilisateur compliquĂ©e,

  • Le cycle de release (weekly release) masque les changements structurants et la nomenclature de versioning n’apporte aucune clartĂ© sur ce point,

  • L’interface utilisateur est connue de l’ensemble de la communautĂ© des dĂ©veloppeurs mais est vieillissante. C’est l’unique moyen de configurer les jobs et les builds,

  • Le constat tirĂ© par les Ă©quipes de Jenkins est qu’une fois le produit installĂ©, rares sont les personnes effectuant une maintenance rĂ©guliĂšre,

  • La dette technique s’est accumulĂ©e sur une base de code datant de 11 ans. La complexitĂ© et les dĂ©pendances sont Ă©galement exposĂ©es aux plugins,

  • La documentation est difficile Ă  trouver et pas toujours Ă  jour.

Une fois le constat posé nous passons aux promesses de la version 2.0 :

  • Le changement le plus structurant est l’ajout d’un nouvel ‘item : les « pipelines ». Pour rĂ©pondre Ă  la problĂ©matique de la configuration au clic, ces pipelines pourront Ă©galement se paramĂ©trer via un DSL (un sous ensemble de groovy) qui se veut extensible. De ce fait, il sera possible de partager des bouts de pipelines en mutualisant du code. Jenkins pourra aller chercher directement sa configuration dans le SCM. La gestion des branches est native ce qui facilitera la gestion des features. Les pipelines auront des points de synchronisation Ă  partir desquels il sera possible de reprendre une exĂ©cution et accepteront des inputs des utilisateurs. Enfin Jenkins 2.0 proposera une intĂ©gration accrue vers Github ou encore Bitbucket puisqu’il sera possible de scanner des repositories entiers et d’obtenir une configuration automatique Ă  partir des informations de pipelines prĂ©sentes dans le code,

  • La version 2.0 doit amĂ©liorer l’expĂ©rience utilisateur « out of the box » en proposant un wizard qui recommandera notamment des plugins afin d’avoir une installation pleinement fonctionnelle de base. Par la mĂȘme occasion, l’interface utilisateur subira un petit lifting,

  • Du fait de l’Ă©mergence du cloud et pour se conformer Ă  des principes de sĂ©curitĂ© sains, l’installation de Jenkins se sera sĂ©curisĂ©e par dĂ©faut,

  • Bien que totalement dĂ©corrĂ©lĂ©e, la mise en ligne d’un nouveau site web plus ergonomique s’est effectuĂ©e le 23/24 Mars.

L’arrivĂ©e de la version 2.0 est prĂ©vue le 6 avril. Une version LTS amputĂ©e de tous les bugs et problĂšmes du lancement sortira durant l’Ă©tĂ©. Cet Ă©tĂ© sonnera Ă©galement le glas de la maintenance de la version 1.X Jenkins version 2.0 ne rĂ©volutionne pas le projet mais constitue un nouveau souffle pour la communautĂ©. Cette version se veut un prolongement de la version 1.X en gardant la compatibilitĂ© avec l’Ă©cosystĂšme de plugins mais pose les bases techniques qui permettront de changer en profondeur et de rĂ©volutionner Jenkins dans un futur proche.

Les requĂȘtes HTTP de l’extrĂȘme – par Vincent CassĂ©

Cette confĂ©rence de Vincent CassĂ© (OVH) est conduite avec une analogie aux dĂ©mĂ©nageurs de l’extrĂȘme. L’application servant de base au discours est un site web de dĂ©pĂŽt de fichiers dans le cloud. L’architecture simplifiĂ©e comprend une webapp en PHP gĂ©rant l’authentification et les droits ainsi qu’un object storage (Openstack Swift).

Le speaker nous propose en premier lieu de télécharger un fichier de plusieurs giga en passant par le backend PHP. La solution naïve consiste à stocker temporairement le fichier sur le serveur pour ensuite le transmettre au client. Cela pose néanmoins les problÚmes suivants :

  • espace disque sur le serveur,

  • risque de timeout entre le client et le serveur PHP car ce dernier peut mettre un temps non nĂ©gligeable Ă  descendre les quelques Giga en provenance de l’object storage. De maniĂšre gĂ©nĂ©rale, les loadblancer coupe les connexions sans trafic pour Ă©viter toute attaque SYN flood.

La solution trouvĂ©e par les Ă©quipes d’OVH est de passer une calback Ă  curl pour transfĂ©rer les paquets au navigateur au fil de l’eau. En PHP cela se traduit par curl_setopt($ch, CURLOPT_WRITEFUNCTION, $callback), la callback contenant un envoi du flux vers le navigateur client.

Le deuxiĂšme cas d’utilisation rencontrĂ© est le tĂ©lĂ©chargement de plusieurs fichiers. Les navigateurs ne proposant pas cette option, la solution communĂ©ment admise est de proposer le tĂ©lĂ©chargement d’un fichier ZIP. LĂ  encore le stockage sur le serveur n’est pas recommandĂ© en raison des griefs prĂ©cĂ©demment citĂ©s. L’utilisation des streams pour renvoyer un flux continu de donnĂ©es au client est prĂ©conisĂ©e.

Le troisiĂšme problĂšme auquel s’est heurtĂ© l’équipe d’OVH pour construire son systĂšme est la gestion des miniatures. AprĂšs avoir Ă©tudiĂ© imagemagick, cette solution fut rapidement Ă©cartĂ©e en raison de consommation CPU, de la nĂ©cessitĂ© d’accĂšs au fichier original complet et de la gestion des caches Ă  rĂ©aliser. Au vu de toutes ces problĂ©matiques, l’équipe s’est orientĂ©e vers un systĂšme de miniature maison.

Tout au long de la confĂ©rence, le speaker dĂ©livre des astuces notamment sur la gestion de l’upload des fichiers et l’affichage d’une barre de progression. Ce fut l’occasion pour une grande partie de l’assemblĂ©e de dĂ©couvrir la mĂ©thode ajax xhr.upload.addEventListener(« progress », callback) qui permet de recevoir en continu le nombre d’octets envoyĂ©s. Connaissant la taille du fichier, un simple produit en croix permet de calculer la progression totale. Au dĂ©tour d’une phrase j’ai Ă©galement appris que l’upload maximum d’une ligne ADSL est de 128ko/sec car c’est la quantitĂ© de donnĂ©es ACK nĂ©cessaire pour assurer un dĂ©bit de tĂ©lĂ©chargement de 20mb/sec.

Ce talk a permis de voir les comportements sur les limites des navigateurs, des équipements réseaux et des serveurs lors du transfert de gros fichiers. La plupart des soucis de déconvenues prévient des loadbalancers préférant couper la connexion lorsque aucun trafic ne circule et les supports des versions anciennes des navigateurs.

Catégories: Blog Société

nCrafts Conference 2016

A Duchess Community Blog for France - mer, 04/06/2016 - 12:00

 

Ncrafts conference 2016

nCrafts est une confĂ©rence indĂ©pendante et internationale dĂ©diĂ©e aux dĂ©veloppeurs qui se soucient de la qualitĂ© de code et souhaitent s’amĂ©liorer. Cette confĂ©rence qui fut d’abord initiĂ© par des dĂ©veloppeurs .net s’ouvre maintenant Ă  tous les langages de programmation. Il s’agit d’une confĂ©rence anglophone et en attendant la fin du CFP, quelques orateurs ont Ă©tĂ© annoncĂ©s.

Parmi eux, nous aurons la chance de retrouver :

  • Bodil Stokke : la prophĂšte de la programmation fonctionnelle,
  • Sandro Mancuso : un software craftsman bien connue dans la communautĂ©,
  • Liz Keogh : Consultante Lean et agile connue pour ces contributions sur des projets

Cet article nCrafts Conference 2016 est apparu en premier sur Duchess France.

Catégories: Association

Git Essentials – 3 – les alias

git essentials logo

Ceci est le troisiĂšme article d’une sĂ©rie consacrĂ©e aux commandes de Git, le systĂšme de gestion de rĂ©visions dĂ©centralisĂ©. Le sujet de cet article est le fonctionnement du systĂšme d’alias proposĂ© par Git, qui permet de mĂ©moriser les commandes complexes ou longues sous une forme plus simple.

Retrouvez les précédents articles de la série :

Tout comme les alias Bash ou autres shell rĂ©cents, Git founit un systĂšme d’alias parfaitement intĂ©grĂ© qui bĂ©nĂ©ficie de l’autocomplĂ©tion des commandes Git normales.

Les alias c’est bien, mais d’abord, pourquoi utiliserais-je la ligne de commande ?

À l’heure oĂč de nombreuses interfaces graphiques pour Git existent, que ce soit sous forme de greffon (plugin) dans l’EDI ou de logiciel indĂ©pendant, on peut s’interroger sur l’intĂ©rĂȘt d’utiliser Git en ligne de commande. Pour commencer, l’interface de Git en ligne de commande est extrĂȘmement bien faite : les commandes disposent d’une trĂšs bonne auto-complĂ©tion, qui fonctionne sur les commandes, options et arguments, la documentation intĂ©grĂ©e est trĂšs bien faite, avec de nombreux exemples. En dehors de cela, il y a trois principaux avantages Ă  utiliser l’interface de Git en ligne de commande :

  • comprendre ce que l’on fait : les interfaces graphiques masquent les options rĂ©ellement utilisĂ©es lorsque Git est appelĂ© ;
  • avoir accĂšs Ă  toute la puissance de Git : les interfaces graphiques proposent un nombre limitĂ© de possibilitĂ©s ;
  • maitriser l’interface en ligne de commande permettra de se dĂ©brouiller sur tous les OS, y compris Ă  distance (SSH) lorsqu’aucune interface graphique n’est disponible.

Toutefois, comme les commandes Git disposent de nombreuses options combinables, certaines commandes peuvent devenir longues. Si elles sont utilisĂ©es rĂ©guliĂšrement, pouvoir mĂ©moriser leur forme complĂšte et les appeler avec une forme plus courte, c’est-Ă -dire un alias, sera bien pratique.

Le fonctionnement

Comme expliquĂ© plus haut, le principe de l’alias est de permettre d’exĂ©cuter une (ou des) commande(s) longue(s) sans avoir Ă  taper la commande complĂšte, mais plutĂŽt un nom raccourci. Le type d’alias le plus connu est l’alias shell (Bash). Dans de nombreuses distributions GNU/Linux, certains sont disponibles par dĂ©faut, comme par exemple l’alias ll pour ls -l, commande permettant de lister les fichiers d’un rĂ©pertoire sous forme longue avec de nombreuses informations. Ainsi, taper ll revient Ă  utiliser ls -l. Les alias Bash sont dĂ©finis dans l’un des fichiers de prĂ©fĂ©rences utilisateur Bash, comme le fichier ~/.bashrc.

Avec Git, le principe est le mĂȘme : les alias sont dĂ©finis dans l’un des fichiers de prĂ©fĂ©rences git, gĂ©nĂ©ralement le ~/.gitconfig. Pour ajouter un alias, la premiĂšre mĂ©thode est d’utiliser la commande adĂ©quate :

git config --global alias.p push

Explication :

  • config est la commande qui permet d’interagir avec la configuration de Git ;
  • --global est l’option de config qui spĂ©cifie que la configuration que nous sommes en train de modifier est globale Ă  la machine, par opposition Ă  un projet Git donnĂ© ;
  • alias est la section de configuration concernĂ©e ;
  • p est la clĂ© de configuration Ă  ajouter, ou le nom de l’alias ;
  • push est la commande git aliasĂ©e, c’est-Ă -dire la commande qui sera appelĂ©e lorsque l’alias sera utilisĂ©.

Le rĂ©sultat est qu’Ă  prĂ©sent, nous pourrons utiliser git p en lieu et place de git push, donc en continuant Ă  bĂ©nĂ©ficier des options et auto-complĂ©tion de push.

Comme toutes les options de configurations, les alias sont stockĂ©s dans le fichier de configuration de l’utilisateur : ~/.gitconfig. AprĂšs la commande prĂ©cĂ©dente, mon fichier ressemble Ă  :

[user]
    name = bbonnet
    email = bbonnet@test.com
[push]
    default = simple
[color]
    ui = auto
[alias]
    p = push

En observant la structure de ce fichier, on peut aisément deviner la deuxiÚme méthode pour créer un alias : écrire une nouvelle ligne dans la section alias.

Exemples

Nous pouvons donc ajouter quelques alias pour raccourcir des commandes de base :

[alias]
 p = push
    co = checkout
    b = branch
    st = status
    s = status -s
    a = add
    ci = commit

Ensuite, crĂ©ons un alias permettant de visualiser le graphe le l’historique des commits sous forme synthĂ©tique :

[alias]
 

 lg = log --graph --oneline --decorate --all

L’explication de ces diffĂ©rentes options se trouve dans l’article dĂ©diĂ© Ă  la commande log.

Autre raccourci utile : un alias permettant d’effectuer un pull avec un rebase au lieu d’un merge, et ainsi de conserver un graphe de commit linĂ©aire et simple Ă  lire :

[alias]
 

 pullr = pull --rebase=preserve

L’explication du dĂ©tail de cette commande, du fonctionnement de pull et son rapport avec merge et rebase sera expliquĂ© en dĂ©tail dans un prochain article.

Terminons avec un dernier exemple correspondant Ă  un cas d’utilisation courant : visualiser les changements apportĂ©s par un commit. La commande git diff permet de le faire, mais pas de maniĂšre idĂ©ale. En effet, mĂȘme si deux lignes ne diffĂšrent que d’un ou quelques caractĂšres, la sortie de la commande affichera plusieurs lignes de contexte, et les deux versions de la ligne concernĂ©e l’une en dessous de l’autre. git diff possĂšde une option intĂ©ressante pour effectuer un diff dont la granularitĂ© est le mot et non plus la ligne complĂšte :

[alias]
 

 diffw = diff --color-words

Il est possible de réduire encore la verbosité du diff en supprimant les lignes de contexte et donnant une définition du mot plus stricte :

[alias]
 

 d = diff --unified=0 --ignore-space-at-eol --color-words='[[:alnum:]]+|[^[:space:]]'

L’explication du dĂ©tail de cette commande fera partie d’un prochaine article dĂ©diĂ© Ă  la visualisation des diffĂ©rences sous Git.

Conclusion

Nous avons vu comment abrĂ©ger les commandes Git courantes ou complexes. À prĂ©sent, plus d’excuses pour ne pas utiliser Git en ligne de commande et accĂ©der sans restriction Ă  toutes les possibilitĂ©s offertes par ce fabuleux outil de gestion de rĂ©visions !

À bientĂŽt pour le prochain article de cette sĂ©rie !

Catégories: Blog Société

Week end gagnant pour les sportifs Ippon

Blog d’Ippon Technologies - mar, 04/05/2016 - 17:24

Pour son premier concours depuis plus d’un an, la championne du monde de saut en longueur en salle 2014 a rĂ©alisĂ© 6,47 m (+1.8) Ă  la longueur, vendredi Ă  Gainesville (USA). A 156 jours des jeux olympiques de Rio de Janeiro, Eloyse Lesueur est de retour sur les sautoirs aprĂšs sa blessure au genou (rupture des ligaments croisĂ©s) en mai dernier.

La performance n’a aucune importance.
Ce qu’il faut retenir, c’est que je suis de nouveau lĂ , maintenant ! Eloyse Lesueur Lesueur Du cĂŽtĂ© de la Turquie, magnifique performance de Marie-Eve GahiĂ© (-70 kg) qui remporte, Ă  19 ans, le Grand Prix de Samsun, en battant Fanny Posvite d’un shido dans le Golden score ! gahie samsun Ippon Technologies est une sociĂ©té trĂšs impliquĂ©e dans le sport. Son fondateur, StĂ©phane Nomis, ancien judoka français de haut niveau a voulu en faire un Ă©lĂ©ment clĂ© de sa stratĂ©gie d’entreprise. C’est pourquoi Ippon compte dans ses rangs de nombreux sportifs ou anciens sportifs de haut niveau. DĂ©couvrez nos amis sportifs sur le site Ippon.
Catégories: Blog Société

Breizhcamp 2016 – Compte-rendu de la journĂ©e du mercredi

breizhcamp.png
Vous n’Ă©tiez pas au Breizhcamp

… mais vous aimeriez en savoir plus !

Comme vous auriez aimĂ© ĂȘtre en Bretagne la semaine derniĂšre et que nous sommes compatissants, nous vous avons prĂ©parĂ© un petit rĂ©sumĂ©.

Le contenu de la conférence Breizhcamp a été dense. Nous préférons découper ce résumé en 3 articles !

Voici donc un résumé de la premiÚre journée.

BreizhCamp – Premier jour

Nous sommes mercredi. Nous attaquons avec la premiÚre journée, la plus calme, mais intéressante malgré tout.

Xtreme Refactoring Deathmatch – par Marie-Laure Thuret et Antoine Michaud

La journĂ©e a commencĂ© sous les chapeaux de roue, car Marie-Laure (@mlthuret) et moi mĂȘme (@AMichaud34) avons animĂ© notre atelier Xtreme Refactoring Deathmatch. Dans cet atelier, nous jouons les rĂŽles de product owners capricieux demandant la modification d’un code existant pour implĂ©menter de nouvelles features. 2h d’efforts intenses pour nos participants. Et bien sĂ»r, pour corser le tout, un leader board sur lequel le premier Ă  implĂ©menter une feature gagne plus de points que les autres.

Bref, pas forcément les mieux placés pour faire un compte-rendu objectif, mais nous avons apprécié cette session et nous la reproposerons à plusieurs occasions sur Paris.

Ce que le kickstarter Mongo ne vous dira pas – par Pierre-Alban Dewitte et Bruno Bonnin

Partant du constat que la documentation de son Ă©diteur prĂ©sente MongoDB sous son meilleur jour, mais que la rĂ©alitĂ© aprĂšs quelques annĂ©es d’expĂ©riences est toute autre, notre orateur veut nous partager son expĂ©rience et les dĂ©boires qu’il a pu rencontrer par manque de mise en garde sur certains points.

PremiĂšre idĂ©e reçue : Mongo, c’est schemaless, on peut donc modĂ©liser comme on veut. Sauf qu’il y a plusieurs contraintes. D’une part, si l’on compte dĂ©normaliser Ă  l’extrĂȘme, il faut savoir qu’il y a une limite haute de 16 MO par document. Et de toute façon, avant mĂȘme d’atteindre cette limite, c’est gĂ©nĂ©ralement une mauvaise idĂ©e d’avoir des documents de taille si importante car ils rempliront trĂšs vite la mĂ©moire vive, indispensable pour la performance de Mongo.

Alors quoi, il suffit de placer quelques bonnes jointures pour allĂ©ger tout ça ? Dans une certaine mesure, c’est l’idĂ©e, sauf qu’il faut tout de mĂȘme faire attention : Mongo n’est pas une base ACID (https://en.wikipedia.org/wiki/ACID), c’est Ă  dire qu’il n’existe pas de systĂšme transactionnel assurant l’Ă©criture d’un ou plusieurs documents modifiĂ©s. Sans parler de l’aspect performance si l’on abuse de normalisation qui nous ferait revenir aux mĂȘmes biais que dans les bases relationnelles.

Il faut donc trouver un compromis entre normalisation et dĂ©normalisation, et lĂ , il n’y a pas de rĂšgle et je cite : « c’est un art plus qu’une science ». Cela dĂ©pend avant tout de l’usage que l’on fait des donnĂ©es. Ceci est un point sur lequel nos prĂ©sentateurs ont insistĂ© pendant les 2 heures : la conception doit toujours ĂȘtre guidĂ©e par l’usage !

Les outils

Il n’y pas grand chose de produit par MongoDB directement. Mais on trouve pas mal d’outils externes :

Les interfaces graphiques :

  • Robomongo : codĂ© en C++ plutĂŽt Ă  la traine niveau fonctionnalitĂ©s
  • MongoChef : fonctionne trĂšs bien et trĂšs complet. Payant (autour de 150€/an)
  • MongoDB Compass : permet de faire des requĂȘtes sur les documents et du schema mining. Joli mais incomplet.

La ligne de commande :

  • Mongo Hacker : colorise, fait du « pretty print », fournit des alias pour agrĂ©gations (gcount, gavg, gsum, …)
  • m : Permet de gĂ©rer plusieurs versions de mongodb sur son poste
Frameworks et APIs

Du cÎté des clients, nous retenons les outils suivants :

  • Driver Java de base : Les codecs sont lourds Ă  implĂ©menter et l’outil est un peu compliquĂ©. L’API asynchrone est cependant trĂšs efficace et agrĂ©able Ă  utiliser pour qui veut faire du non-bloquant.
  • Morphia : API fluent, riche, utilisation simple. Pour notre speaker, cet outil est tout simplement « nĂ©cessaire et suffisant ».
  • Spring Data : c’est du Spring
  • Hibernate OGM : je ne sais plus comment notre prĂ©sentateur a dit ça, mais je crois que c’Ă©tait assez nĂ©gatif :-)
  • Jongo : Vraiment cool !
Estimer la volumétrie

Le dimensionnement est une Ă©tape importante Ă  effectuer avant mise en place de la base de donnĂ©es. Il faut prototyper puis extraire des statistiques des donnĂ©es et des indexes, estimer le nombre de documents en production, ajouter un coefficient multiplicateur pour ĂȘtre tranquille et connaĂźtre la proportion des donnĂ©es rĂ©ellement utilisĂ©es en lecture Ă  un moment T (ce que l’on appelle aussi un « working set »).

Brancher Mongo Ă  un systĂšme externe

Mongo connector permet d’exporter les donnĂ©es vers du ELS, SolR, Postgre, un autre Mongo, …

Pour les migrations, un de nos deux speakers a un coup de coeur pour Apache Camel.

La vie de la prod

Pour mettre ses donnĂ©es en sĂ»retĂ©, mieux vaut utiliser un replica set. C’est trĂšs facile Ă  mettre un place. Attention cependant au chaĂźnage automatique des secondaires.

Stockage des données

Dans MongoDB, la cohĂ©rence des donnĂ©es Ă©tait traditionnellement assurĂ©e par le Write Concern qui acquitte une fois l’Ă©criture prise en compte par le master. Il existe Ă©galement un Read Concern Ă  partir de la version 3.2 qui permet de pousser un peu plus loin le niveau de cohĂ©rence au besoin.

Le moteur de stockage Ă©tait mmapv1 depuis le dĂ©but et devient Wiredtiger par dĂ©faut Ă  partir de la 3.2. Il y a Ă©galement un stockage en mĂ©moire qui est en beta mais qui, en rĂ©alitĂ©, est lent et pas du tout mature. Pour finir, un futur moteur que l’on pourrait bientĂŽt trouver, c’est RocksDB.

Pour un mĂȘme replica set, il est possible d’avoir plusieurs moteurs. Cela permettant de tirer parti du meilleur de chacun des mondes. Wiredtiger est plus performant en Ă©criture car il n’y pas de lock au niveau de la collection mais au niveau du document alors que MMap permet une lecture plus performante.

Sharding

C’est probablement la partie la plus compliquĂ©e dans Mongo. Cela consiste Ă  rĂ©partir les donnĂ©es sur diffĂ©rentes machines. On peut le faire de diffĂ©rentes maniĂšres : range based sharding, hash based sharding, tag aware sharding. Le hash based sharding est dans la plupart des cas la solution Ă  privilĂ©gier.

Lorsque l’on fait du sharding sur Mongo, il faut savoir que pour chaque shard, on doit avoir un replica set entier. Comme le sharding commence Ă  ĂȘtre rĂ©ellement intĂ©ressant Ă  partir de 3 shards, cela n’est pas nĂ©gligeable en terme d’infrastructure.

On peut aussi rencontrer le cas de lecture sur un noeud orphelin, c’est Ă  dire une donnĂ©e qui n’est plus d’actualitĂ©, lors d’un rebalancing ou lors d’une sauvegarde. On prĂ©fĂšrera ne jamais lire sur un noeud secondaire pour des donnĂ©es critiques.

Quand on dĂ©cide d’utiliser la technique de sharding, il vaut donc mieux ĂȘtre sĂ»r que cela en vaut la peine, en monitorant le working set notamment.

Monitoring

Petite liste d’outils intĂ©ressant pour l’analyse :
Mongotop, Explain, Mongostat, mtools

Conclusion de la premiÚre journée

Cette journĂ©e a trĂšs bien commencĂ© et ce rĂ©sumĂ© ne fait pas assez honneur Ă  la qualitĂ© du programme de la premiĂšre journĂ©e car mĂȘme si l’on parle ici uniquement de 2 sujets, il y en avait en rĂ©alitĂ© 17 que vous pourrez retrouver sur le programme du Breizhcamp. Rendez-vous ces prochains jours pour les rĂ©sumĂ©s des journĂ©es de jeudi et vendredi !

Catégories: Blog Société

Ippon sponsor gold de DevoXX France 2016

Blog d’Ippon Technologies - mar, 04/05/2016 - 11:28

Devoxx bannière stand 24 Linkedin

Du 20 au 22 avril 2016, la communautĂ© Java se retrouvera au palais des congrĂšs de Paris Ă  l’occasion de Devoxx France.

Devoxx France fait partie de la famille des conférences Devoxx (Belgique, Angleterre, Pologne, Maroc). Cette communauté regroupe plus de 10 000 développeurs à travers le monde.

Partenaire de cet Ă©vĂšnement depuis sa naissance en 2010, Ippon est fier d’ĂȘtre cette annĂ©e sponsor gold.

Nous vous proposerons un stand trÚs ensoleillé (numéro 24) ainsi que de multiples conférences :

Mercredi

17h10/17h40 

Vincent Beretti : Typescript, typer pour mieux coder 

 

Jeudi

12h25/12h40

JĂ©rĂŽme Mainaud: Le pattern builder Ă  l’heure de Java 8

12h55/13h40

Julien Dubois : Quoi de neuf pour JHipster en 2016

18h55/19h25 :

Vincent Beretti: Performance: Java vous déclare sa flamme

 

Vendredi

12h05/12h20

Anne Gabrillagues : Boostez votre amélioration continue avec Popcorn Flow !

13h55/14h40

Stéphane Lagraulet et Olivier Revial : Microservices IRL: ça fonctionne chez un client, on vous dit comment!

16h10/16h55

François Sarradin : Java (8) eXperiments

 

 

Si vous n’avez pas encore votre place, tentez de la gagner en jouant au Coding challenge !

Demandez votre invitation au before du DevoXX avec Matt Raible chez Ippon :

Développé par Eventbrite
Catégories: Blog Société

Créons notre premier Web Server Swift avec IBM BlueMix

Logo swift apple
Comme annoncĂ© dans une de nos rĂ©centes revues de presse, Swift est dĂ©sormais un projet Open Source et peut ĂȘtre compilĂ© facilement sur des plates-formes Linux et Mac OS X i386 (et bientĂŽt ARM).

Le but de cet article est de créer et exécuter simplement un Web Server écrit en Swift et de le déployer efficacement sur BlueMix, la solution PaaS de IBM.

Introduction

IBM BlueMix, lancé en 2014, fournit diverses solutions PaaS et BaaS (notamment Cloud Foundry Apps, Data & Analytics et Containers), avec des prix trÚs intéressants et notamment un créneau gratuit plus que suffisant pour un usage modéré du service.

Dans la suite de cet article, nous allons opter pour une solution basée sur Cloud Foundry, cela nous permettant de simplifier les étapes de mise en place du service.

Cloud Foundry est une solution PaaS Open Source dĂ©veloppĂ©e par VMWare et actuellement maintenue par Pivotal Software, qui permet le dĂ©ploiement simplifiĂ© de serveurs et supportĂ© par plusieurs fournisseurs : notre serveur pourra ĂȘtre dĂ©ployĂ© sans aucun changement sur BlueMix, sur Heroku ou encore Microsoft Azure.

Dans la suite de l’article nous allons dans un premier temps tĂ©lĂ©charger tout ce qu’il faut et crĂ©er notre premier route (Ă©tapes 0 Ă  2) puis dĂ©ployer notre Web Server (Ă©tapes 3 et 4). Si l’on souhaite directement se concentrer sur le dĂ©ploiement, on pourra tĂ©lĂ©charger le zip contenant le code complet du projet, disponible Ă  l’adresse suivante : https://github.com/xebia-france/blog-XebiaSwiftServer/releases/tag/0.1.

Les Ă©tapes qui suivent ont Ă©tĂ© testĂ©es sous Mac OS X. Pour la mise en place du projet sous Linux, les dĂ©pendances (celle mentionnĂ©es dans l’Ă©tape 0, notamment) peuvent varier.

Étape 0 : installation de Swift – Development Snapshot

Afin de pouvoir compiler le code de notre Web Server en local, nous avons besoin de Development Snapshot de Swift. À date, la derniĂšre version distribuĂ©e par Apple est celle du 1er mars 2016, disponible Ă  l’URL suivante :

Xcode Swift Development Snapshot

Nous vous invitons Ă  bien vouloir vĂ©rifier la version Ă  tĂ©lĂ©charger : il faudra bien s’assurer d’avoir rĂ©cupĂ©rĂ© le binaire Xcode Swift Development Snapshot car la distribution Swift 2.2 Release Snapshot ne vous permettra pas de compiler notre solution.

Pour l’installation de Development Snapshot, nous allons suivre les Ă©tapes dĂ©crites sur le site swift.org et disponibles dans la page de Download (https://swift.org/download/#installation).

Dans le cadre de notre tutoriel, l’étape Code Signing on OS X n’est pas nĂ©cessaire.

Pour vĂ©rifier l’installation de Development Snapshot de Swift, nous pouvons saisir la commande

swift --version

Ă  l’intĂ©rieur de la console du terminal.

Le rĂ©sultat devra ĂȘtre comme dans l’image qui suit.
apple swift

Étape 1 : crĂ©ation du projet

Pour commencer, nous allons tĂ©lĂ©charger le gabarit du projet disponible Ă  l’URL suivante : github.com/xebia-france/blog-XebiaSwiftServer/releases/tag/0.0.2.

Le gabarit se compose des fichiers suivants :

manifest.yml

Il contient les informations nécessaires au déploiement via Cloud Foundry.

applications:
- path: .
  memory: 128M
  instances: 1
  domain: mybluemix.net
  name: XebiaSwiftServer
  host: xebiaswiftserver
  disk_quota: 1024M
  buildpack: https://github.com/cloudfoundry-community/swift-buildpack.git

Le buildpack permet de prĂ©configurer l’environnement avec les dĂ©pendances systĂšme nĂ©cessaires Ă  la correcte compilation d’un projet dĂ©ployĂ© via Cloud Foundry.

La communautĂ© a produit un buildpack Swift qui permet d’installer automatiquement Development Snapshot et Clang au moment du dĂ©ploiement de notre projet via Cloud Foundry. Cela simplifie Ă©normĂ©ment le processus de dĂ©ploiement et nous permet de nous concentrer presque uniquement sur le code source Ă  Ă©crire.

.swift-version

Le fichier .swift-version sert à préciser la version Swift nécessaire à exécuter notre application. Cette variable est strictement liée aux distributions de Swift supportées par le buildpack. Autrement dit, si le buildpack ne supporte pas la version de Swift déclarée ici, le déploiement échouera.

Dans notre cas, la version à déclarer est :

swift-DEVELOPMENT-SNAPSHOT-2016-03-01-a

Fini avec l’infra, nous pouvons commencer Ă  coder.

Étape 2 : du code, finalement ! Package.swift

En premiÚre instance, nous allons créer le fichier Package.swift qui déclare les dépendances de notre projet.

La mise en place de Package.swift fait partie des spécifications introduites par Swift Package Manager, le gestionnaire de dépendances de Swift publié par Apple en novembre dernier.

À l’intĂ©rieur de Package.swift, nous allons Ă©crire les lignes suivantes :

import PackageDescription
let package = Package(
  name: "XebiaSwiftServer",
  dependencies: [
    .Package(url: "https://github.com/kylef/Curassow.git", majorVersion: 0, minor: 4),
  ]
)

Curassow, la dĂ©pendance que nous utilisons, est le cƓur de notre projet car il nous permet de mettre en place les routes de notre serveur Web.

Il existe dĂ©jĂ  de nombreuses autres solutions serveurs, les plus connues Ă©tant Zewo et Kitura, cette derniĂšre Ă©tant Ă©ditĂ©e par IBM mĂȘme. Nous n’utiliserons pas ces solutions car elles nĂ©cessitent un buildpack contenant une version prĂ©-compilĂ©e de libdispatch qui n’est pas disponible Ă  date.

main.swift

La prochaine Ă©tape consiste en l’Ă©criture du corps de notre Web Server.
CrĂ©ons un fichier main.swift Ă  l’interieur d’un dossier Sources et ajoutons les lignes suivantes :

import Curassow
import Inquiline
serve { request in
  return Response(.Ok, contentType: "text/plain", body: "Hello World")
}
Compilation

Une fois Ă©crit le code, nous allons le compiler :

cd my folder
swift build

Le binaire est maintenant disponible dans le dossier .build et peut ĂȘtre exĂ©cutĂ© avec la commande

.build/debug/XebiaSwiftServer

Notre dépendance Curassow permet de spécifier des paramÚtres additionnels qui seront passés à notre serveur. Par exemple :

.build/debug/XebiaSwiftServer --bind [ADRESSE_IP]:[PORT]
Procfile

Le Procfile est le fichier qui dĂ©clare quel processus sera lancĂ© Ă  la fin du dĂ©ploiement. Dans notre cas, le processus en objet est XebiaSwiftServer, et les paramĂštres associĂ©s concernent l’adresse et le port sur lesquels le serveur sera en Ă©coute.

Les paramĂštres du Procfile sont utilisĂ©s pour lancer le serveur sur le port $PORT, qui est une variable d’environnement de l’instance qui sera dĂ©ployĂ©e via Cloud Foundry.

Le Procfile que nous aurons obtenu contiendra donc la ligne suivante :

web: XebiaSwiftServer --bind 0.0.0.0:$PORT
Étape 3 : crĂ©ation du compte BlueMix et installation des outils Cloud Foundry

Nous allons crĂ©er notre compte sur BlueMix Ă  la page https://console.ng.bluemix.net/. Ensuite, nous devons tĂ©lĂ©charger l’outillage en ligne de commande de IBM qui nous permettra de nous authentifier depuis le terminal. L’archive auto-installable est disponible Ă  l’adresse http://clis.ng.bluemix.net/ui/home.html.

Pour crĂ©er notre instance Cloud Foundry nous avons besoin d’installer les outils en ligne de commande dĂ©diĂ©s Ă  l’adresse suivante : https://github.com/cloudfoundry/cli/releases. Une fois installĂ©s, nous pourrons exĂ©cuter la commande

cf help

afin de bien vĂ©rifier l’installation.

Le rĂ©sultat devra ĂȘtre similaire Ă  l’image qui suit :

Bluemix, outils Cloud Foundery

Étape 4 : dĂ©ploiement

Pour terminer notre article, il ne nous reste plus qu’Ă  dĂ©ployer notre serveur sur IBM BlueMix.

Pour ce faire, nous allons utiliser les commandes suivantes :

# Effectue le login sur BlueMix
bluemix login

# Crée un space, c-a-d, un espace de travail (qui peut contenir plusieurs instances / projets)
bluemix cf create-space "<MON_ESPACE>"
bluemix cf target -o "<ID_UTILISATEUR>" -s "<MON_ESPACE>"

# AccĂšde au repertoire contenant notre code
cd <MON_PROJET>

# DĂ©ploye l'application Cloud Foundry sur BlueMix
bluemix cf push

L’opĂ©ration peut prendre jusqu’Ă  5 minutes et devrait se conclure avec un message de succĂšs.

Nous pouvons donc ouvrir notre navigateur et insĂ©rer l’adresse de notre host, par exemple

http://xebiaswiftserver.mybluemix.net

xebia, swiftserver, my bluemix

Conclusion

Cet article n’est que le point de dĂ©part pour nos prochaines aventures : nous avons en effet appris comment nous servir de Swift Package Manager, des versions de dĂ©veloppement de Swift et d’un systĂšme de dĂ©ploiement automatisĂ©.

De nouveaux packages et de nouveaux services dĂ©diĂ©s Ă  l’Ă©cosystĂšme Swift voient la lumiĂšre tous les jours et nous sommes vraiment curieux de dĂ©couvrir ce que l’on pourra construire avec ces technologies.

Catégories: Blog Société

Partagez la connaissance

Partagez BlogsdeDeveloppeurs.com sur les réseaux sociaux