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

Java 8 est réactif !


Programmation réactive

Parmi les nombreuses Ă©volutions que nous propose Java8, l’une d’entre-elles attire particuliĂšrement notre attention. Il s’agit de la prĂ©sence de la classe CompletableFuture<>. Mine de rien, cette classe va bouleverser les applications Java. De nouvelles architectures seront proposĂ©es, de nouveaux frameworks vont apparaĂźtre pour remplacer les anciens, etc. C’est une classe majeure de Java8.

La classe Future<> propose de dĂ©clencher un traitement en tĂąche de fond et de rĂ©cupĂ©rer le rĂ©sultat plus tard, via la mĂ©thode get(). Le dĂ©veloppeur possĂšde alors une rĂ©fĂ©rence vers un rĂ©sultat futur. Il peut l’interroger pour savoir si le rĂ©sultat est disponible, ou bien le demander immĂ©diatement car il en a besoin. La mĂ©thode get() bloque alors le processus actuel jusqu’Ă  la fin du traitement asynchrone.

C’est justement la grande diffĂ©rence avec la classe CompletableFuture<>. Normalement, seul le thread associĂ© au future peut alimenter le rĂ©sultat pour dĂ©bloquer les invocations Ă  get(). Avec la nouvelle classe, il est possible d’alimenter le rĂ©sultat d’un futur depuis n’importe quel thread. Il est alors possible de rĂ©agir Ă  un Ă©vĂ©nement asynchrone pour dĂ©bloquer un CompletableFuture. Il est Ă©galement possible d’enregistrer des call-back ou des closures qui seront dĂ©clenchĂ©es lorsqu’un rĂ©sultat ou une exception sera disponible.

Pour comprendre comment cela s’organise et s’exĂ©cute, imaginons un enchaĂźnement de traitements et de transformations faisant intervenir des API bloquantes. Tout d’abord, proposons un CompletableFuture<Reader> avec le flux d’une page Web. L’objectif est de demander le chargement d’une page Web et d’avoir accĂšs au Reader lorsque la nĂ©gociation avec le serveur est terminĂ©. Pendant ce temps, le programme peut faire autre chose comme invoquer une base de donnĂ©e ou faire des calculs pour produire une page web.

CompletableFuture<Reader> getAsyncURL(URL url) {
final CompletableFuture<Reader> result = new CompletableFuture<Reader>();

// DĂ©marre un soft-thread avec un traitement alimentant un CompletableFuture
Executors.callable(() ->
 {
   // Executé dans un autre thread
   URLConnection con;
   try {
     con = url.openConnection();
     // ComplÚte le future avec un Reader
     result.complete(new InputStreamReader(con.getInputStream(),getEncoding(con)));
   } catch (Exception e) {
     // Signal l'erreur dans le future
     result.completeExceptionally(e);
   }
 });
 return result;
}

DĂšs la disponibilitĂ© du Reader, rĂ©cupĂ©rons le flux en chaĂźne de caractĂšres. Cela s’effectue Ă©galement tĂąche de fond. Le future est complet dĂšs que la page HTML est intĂ©gralement disponible.

CompletableFuture<String> page = getURLAsync(url)
 .thenApply((in) -> {
   try {
     // Transforme le Reader en String
     return IOUtils.toString(in);
   } catch (Exception e) {
     return "";
   }
  });
// ... execution d'autres traitements 
// pendant le chargement de la page ...
// puis lecture bloquante de la page
System.out.println(page.get());

Comme la mĂ©thode get() est bloquante, la fonction println() n’est pas exĂ©cutĂ©e tous de suite.

Notez qu’il n’est pas possible de propager l’exception dans thenApply, car la closure s’exĂ©cute dans un thread diffĂ©rent du thread principal. C’est une des difficultĂ©s avec les diffĂ©rentes mĂ©thodes de la classe CompletableFuture<>.

Tant que le pool de thread n’est pas saturĂ©, nous pouvons charger des pages Web en mĂ©moire en tĂąche de fond. Mais dĂšs sa saturation, il faut attendre le chargement des pages prĂ©cĂ©dentes avant d’en demander de nouvelles.

Maintenant, rendons cela rĂ©actif. Nous utilisons l’API AsyncHTTPClient. Nous devons encore utiliser une inner classe avec deux mĂ©thodes onCompleted() et onThrowable(). En effet, le framework n’est pas encore compatible avec Java8. Dans la nouvelle version de la mĂ©thode getURLAsync(), nous mappons juste ces mĂ©thodes vers leurs Ă©quivalents de CompletableFuture<>.

CompletableFuture<Reader> getURLAsync(URL url) throws IOException {
 CompletableFuture<Reader> rc = new CompletableFuture<Reader>();
 AsyncCompletionHandler handler=new AsyncCompletionHandler<Response>(){
   @Override
   public Response onCompleted(Response response) throws Exception{
     rc.complete(new InputStreamReader(response.getResponseBodyAsStream(),
     getEncoding(response.getContentType())));
     return response;
   }

   @Override
   public void onThrowable(Throwable t){
     rc.completeExceptionally(t);
   }
 };
 asyncHttpClient.prepareGet(url.toString()).execute(handler);
 return rc;
}

Et voilĂ . Notre application est maintenant non bloquante lors de la lecture de la page HTML. Nous n’avons plus besoin de l’instance Executors. L’application peut gĂ©rer une multitude de connexions sans avoir Ă  ajouter de soft-threads. En effet, le framework utilise les API asynchrone de Java pour rĂ©cupĂ©rer simultanĂ©ment toutes les pages demandĂ©es.

CompletableFuture<String> page = getURLAsync(url)
 .thenApply((in) -> {
   try {
     return IOUtils.toString(in);
   } catch (Exception e) {
     return "";
   }
  });
// ... execution d'autres traitements 
// pendant le chargement de la page ...
// Lecture bloquante de la page
System.out.println(page.get());

Pour garder le cotĂ© asynchrone, il est prĂ©fĂ©rable de ne plus utiliser get() mais d’utiliser les call-backs du CompletableFuture<>. C’est le moment de rĂ©veiller une servlet asynchrone des spĂ©cifications Servlet 3.0.

Cette classe est la porte ouverte aux architectures rĂ©actives que nous avons dĂ©crites dans d’autres articles. D’autres frameworks proposaient des classes Ă©quivalentes. Guava propose ListenableFuture<>, Async http client propose FutureCallback<>, etc.

La rĂ©volution vient de l’intĂ©gration de cette classe dans la norme. Ainsi, tous les frameworks vont pouvoir s’appuyer sur cette classe. Il devient possible de composer des traitements complexes asynchrones, avec des donnĂ©es venant de diffĂ©rentes sources (un web service, une base de donnĂ©es, un calcul GPU, etc.).

Nous prĂ©disons qu’une alternative Ă  JDBC sera proposĂ©e, s’appuyant sur cette classe. Le dernier maillon pour gĂ©nĂ©raliser les approches rĂ©actives dans Java sera alors franchi. Pour les bases de donnĂ©es NoSQL, c’est dĂ©jĂ  possible.

CompletableFuture<> propose tout un tas de mĂ©thodes pour enchaĂźner des traitements dĂšs qu’une donnĂ©e est disponible. Par dĂ©faut, un pool de hard-thread est alors utilisĂ© pour distribuer au mieux les jobs suivant les capacitĂ©s du ou des processeurs.

Pour synthĂ©tiser les diffĂ©rentes mĂ©thodes proposĂ©es par cette classe et leurs usages, nous vous proposons un tableau Ă  la fin de l’article. À gauche, vous trouverez les donnĂ©es d’entrĂ©es, au milieu le nom de la mĂ©thode et le paramĂštre principal Ă  valoriser avec son type. Si une closure est nĂ©cessaire, les types de ses paramĂštres ainsi que le type de retour est indiquĂ©. e reprĂ©sente une exception. Enfin, la derniĂšre colonne indique le rĂ©sultat de sortie. La plupart des mĂ©thodes acceptent d’ĂȘtre suffixĂ©es par Async pour exĂ©cuter le traitement dans une autre tĂąche, et un Executors pour utiliser un pool diffĂ©rent de celui par dĂ©faut.

Le plus grand problĂšme de la classe CompletableFuture<> est la taille de son nom. Elle a vocation Ă  ĂȘtre utilisĂ©e massivement. Un nom plus court aurait Ă©tĂ© le bienvenu.

EntrĂ©e MĂ©thode ParamĂštre princ. Sortie Écriture Valorise un futur avec une valeur. CF<T>,t complete T CF<T> Valorise un futur avec une exception. CF<T>,e completeExceptionaly e CF<T> Valorise en tĂąche de fond via la crĂ©ation d’un CF. CF.supplyAsync ()->T CF<T> Lecture Bloque le thread jusqu’à obtention de la valeur ou d’une exception. Attention, bloquant ! CF<T> get T Bloque le thread jusqu’à obtention de la valeur, d’une exception ou l’expiration d’un dĂ©lai. Attention, bloquant ! CF<T> getTimeOut delais T Retourne la valeur disponible ou une valeur par dĂ©faut. CF<T> getNow default T Se synchronise sur l’un d’eux et retourne sa valeur en Object. CF<T>
CF<U>

 anyOf CF<Object> Se synchronise sur plusieurs CF. Il faut les consulter individuellement ensuite. CF<T>
CF<U>

 allOf CF<Void> Transformation Transforme en valeur depuis une valeur ou une exception CF<T> whenComplete (T,e) -> CF<T> CF<T> Transforme un rĂ©sultat en un autre. CF<T> thenApply (T) -> U CF<U> Transforme une exception en valeur. CF<T> exceptionally (e)->T CF<T> Applique une transformation avec l’un ou l’autre. CF<T>
CF<T> applyEither (T)-> U CF<U> Combine deux résultats pour en faire un troisiÚme. CF<T>
CF<U> thenCombine (T,U) -> V CF<V> Transforme une donnĂ©e via un traitement retournant un CF. CF<T> thenCompose T -> CF<U> CF<U> Terminaison ExĂ©cute aprĂšs une valorisation ou une exception. CF<T> handle (T,e) -> {
} ExĂ©cute dĂšs la valeur disponible. CF<T> thenAccept (T)-> {
} ExĂ©cute aprĂšs l’un et l’autre. CF<T>
CF<U> thenAcceptBoth (T,U) -> {
} ExĂ©cute aprĂšs l’un ou l’autre. CF<T>
CF<T> acceptEither (T) -> {
}

Philippe PRADOS et l’Ă©quipe « RĂ©active »

Suggestion d'articles :

  1. La genÚse du modÚle réactif
  2. Multitùches ou réactif ?
  3. Jusqu’oĂč peut aller un simple ordinateur de bureau avec une application web java rĂ©active ?

Catégories: Blog Société

Merci_ISEP

Paris Java User Group - mar, 06/03/2014 - 08:45

Le prochain ParisJUG est de dernier à l'ISEP.

Catégories: Association

Daily meeting kanban : Comment favoriser le flux tiré

Dans mes accompagnements, j’ai remarquĂ© que les équipes IT ayant une premiĂšre expĂ©rience Scrum pouvaient rencontrer un certain nombre de problĂšmes dans la mise en place de systĂšmes Kanban.

Ceci est dĂ» au fait que Kanban n’impose que trĂšs peu de contraintes et laisse Ă©normĂ©ment de libertĂ© dans son implĂ©mentation. Devant autant de libertĂ©, ces Ă©quipes ont tendance Ă  emprunter un certain nombre de pratiques inhĂ©rentes à Scrum.

Bien que cette approche ne pose pas de problĂšme en soi, il faut tout de mĂȘme faire attention Ă  l’implĂ©mentation qui en est faite. En effet, le contexte et les objectifs d’une Ă©quipe travaillant en Kanban sont souvent trĂšs diffĂ©rents d’une Ă©quipe travaillant en Scrum. Ceci peut limiter l’efficacitĂ© des pratiques portĂ©es d’une approche Ă  l’autre.

Nous allons en donner un exemple ici en Ă©tudiant les diffĂ©rences dans l’implĂ©mentation du Daily Meeting.

Capture-d’écran-2014-05-26-Ă -09.29.24.png

Le Daily Meeting Scrum

En Scrum, le Daily Meeting est un cĂ©rĂ©monial inscrit dans la mĂ©thode. Tous les matins, Ă  heure fixe, une Ă©quipe Scrum se rassemble autour du tableau d’avancement du sprint en cours. Chacun Ă  son tour, chaque membre de l’équipe va rĂ©pondre Ă  3 questions :

  • Qu’ai-je fait hier ?
  • Que vais-je faire aujourd’hui ?
  • Suis-je bloquĂ©, qui peut m’aider ?

Dans ce cas, le Daily Meeting doit permettre la synchronisation de l’équipe sur la tenue des engagements du sprint, tout en favorisant la cohĂ©sion de l’équipe. Cela convient bien aux Ă©quipes Scrum qui restent centrĂ©es sur la rĂ©alisation d’un sprint court (entre 1 et 4 semaines – nommĂ© Ă©galement itĂ©ration). Mais cette approche est-elle efficace dans le cadre d’une Ă©quipe Kanban ?

Différences structurelles entre Scrum et Kanban

Pour répondre à cette question, il est important de mettre le doigt sur quelques différences structurelles que nous allons souvent rencontrer entre Scrum et Kanban.

  • L’étendue du processus pris en charge par la mĂ©thode
    LĂ  oĂč Scrum se concentre sur la phase de dĂ©veloppement, une dĂ©marche Kanban englobe un processus beaucoup plus large. Il n’est en effet pas rare de voir des systĂšmes Kanban intĂ©grer des Ă©tapes de recueil du besoin, d’écriture de user stories, de dĂ©veloppement, de tests fonctionnels, de recette, de dĂ©ploiement 

  • La structure de l’équipe
    LĂ  oĂč en Scrum on cherche Ă  construire de petites Ă©quipes pluridisciplinaires, un projet Kanban est souvent amenĂ© Ă  gĂ©rer des Ă©quipes plus importantes avec des spĂ©cialisations plus marquĂ©es. Ceci est principalement dĂ» Ă  la couverture plus large des processus mis en jeu.
  • La notion de flux et en particulier de flux tirĂ©
    En Scrum la notion de flux continu n’existe pas vraiment. En effet, le processus est entiĂšrement chargĂ© en dĂ©but de sprint, et rĂ©initialisĂ© Ă  la fin de celui-ci. Le sprint suivant Ă©tant complĂštement indĂ©pendant (rien n’oblige le product owner Ă  replacer dans un sprint les user stories non traitĂ©es dans l’itĂ©ration prĂ©cĂ©dente). Par contre, en Kanban, la notion de flux est le centre de la mĂ©thode. Tout doit ĂȘtre mis en oeuvre pour limiter le travail en cours en fluidifiant le flux des Ă©lĂ©ments dans le systĂšme. Pour cela, on doit faire le maximum pour favoriser la sortie des Ă©lĂ©ments. Ceci nous amĂšne Ă  mettre en place un flux tirĂ© (associĂ© Ă  une limitation du travail Ă  faire) dans notre systĂšme Kanban.
Impact de ces différences

Une fois ces diffĂ©rences posĂ©es, quels sont les risques auxquels une Ă©quipe Kanban s’expose si elle applique, stricto sensu, la façon de faire Scrum pour ses Daily Meeting ?

  • En donnant la parole aux membres de l’équipe les uns aprĂšs les autres, sans ordre particulier, le daily Scrum est centrĂ© sur les activitĂ©s de l’équipe, pas sur les Ă©lĂ©ments dans le systĂšme. On ne parle que des Ă©lĂ©ments sur lesquels quelqu’un travaille, ou va travailler dans la journĂ©e. Des Ă©lĂ©ments en attente dans le systĂšme peuvent donc ĂȘtre facilement oubliĂ©s si personne ne les traite au moment du daily. Ceci n’est pas en accord avec une bonne pratique Kanban, qui est de limiter le travail en cours dans le systĂšme. Le flux tirĂ© n’est pas gĂ©rĂ© naturellement.
  • La structure de l’équipe Ă©tant en gĂ©nĂ©ral moins homogĂšne en Kanban qu’en Scrum. Le fait que chacun parle Ă  son tour peut manquer de cohĂ©rence. Ceci peut entrainer certains membres de l’équipe Ă  se dĂ©sintĂ©resser de ce qui est dit.
  • Dans le cas d’équipes importantes, le daily peut trainer en longueur.
  • Le management visuel n’est pas utilisĂ© de façon efficiente, surtout dans le cadre de processus complexes. Chacun parlant de son tour, sans forcement prendre en compte l’état global du systĂšme prĂ©sentĂ© sur le tableau Kanban.

Pour tenter de rĂ©pondre Ă  ces problĂšmes, il convient d’adopter une structure diffĂ©rente pour le Daily Meeting en Kanban.

Proposition d’organisation du Daily Meeting Kanban

PlutĂŽt que de faire parler tous les membres de l’équipe un par un, nous allons utiliser le management visuel pour guider le daily. Toute la rĂ©union sera organisĂ©e autour des Ă©lĂ©ments visibles sur le tableau Kanban. Les diffĂ©rents intervenants ne parleront plus chacun leur tour, mais Ă  chaque fois qu’ils peuvent apporter leur aide sur le point en cours de discussion.

1ere Ă©tape

Avant le daily, l’animateur s’assure que le management visuel est bien à jour:

  • Les user stories sont dans le bon Ă©tat
  • Les rĂšgles sont bien respectĂ©es
  • Les blocages sont visibles

2eme Ă©tape

L’équipe passe en revue les problĂšmes dĂ©jĂ  identifiĂ©s (fiches kaizen) et en cours de traitement. On vĂ©rifie que les actions prĂ©vues sont bien menĂ©es et qu’elles portent bien leurs fruits. A ce sujet je vous recommande de lire l’article suivant : Il Ă©tait une fois un projet IT en Kanban (Episode 5 – Partie I) : GĂ©rer les obstacles – La fiche kaizen.

3eme Ă©tape

L’équipe passe en revue les points de blocage prĂ©sents sur le tableau Kanban. Elle essaie de voir si une solution peut ĂȘtre apportĂ©e rapidement. Si aucune solution rapide n’est identifiĂ©e, une fiche kaizen est rĂ©digĂ©e par l’animateur de la rĂ©union et est placĂ©e dans le processus de rĂ©solution des problĂšmes. Ceci seront traitĂ©s par des instances ad hoc hors du Daily Meeting.

4eme Ă©tape

En partant de la fin du processus (les colonnes les plus Ă  droite du tableau Kanban) l’équipe doit discuter de tous les Ă©lĂ©ments dans le systĂšme (pour des raisons d’efficacitĂ©, il est tout de mĂȘme possible de traiter certaines fiches par lot). L’objectif de la discussion doit ĂȘtre de voir comment il est possible de faire avancer les Ă©lĂ©ments discutĂ©s. Lors de cette analyse du systĂšme, les membres de l’équipe interviennent en fonction de leur spĂ©cialitĂ© et de leur capacitĂ© Ă  faire avancer les activitĂ©s. C’est lors de cette phase que le travail de la journĂ©e est distribuĂ© au sein de l’équipe. 

5eme Ă©tape

Pour conclure la rĂ©union, l’organisateur demande si tout de monde sait ce qu’il a Ă  faire aujourd’hui, et si quelqu’un a quelque chose Ă  ajouter.  

DifficultĂ© d’implĂ©mentation

La principale difficultĂ© que l’on peut rencontrer dans l’application de cette façon de faire, est la longueur du Daily Meeting. Si cela vous arrive, la 1ere question Ă  se poser est de savoir si vous n’avez pas trop de travaux en cours dans votre systĂšme. Ceci peut ĂȘtre symptomatique d’une gestion en flux poussĂ© plutĂŽt qu’en flux tirĂ©. La mise en place d’un daily, favorisant le flux tirĂ©, peut alors progressivement rĂ©sorber le problĂšme. Si ce n’est pas le cas, pas de panique, comme les sujets sont traitĂ©s par ordre de prioritĂ© (ProblĂšmes > sortie du systĂšme > entrĂ©e dans le systĂšme) il est tout Ă  fait possible de time boxer la rĂ©union et d’arrĂȘter le point avant que tous les sujets n’aient Ă©tĂ© complĂštement traitĂ©s.

Conclusion

Je pense que cette approche est plus en accord avec les objectifs attendus d’un systùme Kanban. Elle a permis de rendre les Daily Meeting plus dynamiques et plus efficaces sur de nombreux projets que j’ai eu l’occasion d’accompagner.

Catégories: Blog Société

Agile : J’aime / J’aime pas

Pour animer la derniĂšre rĂ©trospective d’une Ă©quipe qui pratique l’agilitĂ© depuis 2,5 mois sur un projet de monĂ©tique, j’ai demandĂ© Ă  chaque participant de me donner un Ă©lĂ©ments de l’agilitĂ© qu’il aime et un Ă©lĂ©ment qu’il n’aime pas.

Je souhaite partager avec vous ces rĂ©ponses, qui n’engagent bien entendu que cette Ă©quipe spĂ©cifique dans son contexte spĂ©cifique :)

Tout d’abord quelques Ă©lĂ©ments de contexte :

  • Une Ă©quipe de 3 Product Owner + 1 reprĂ©sentant mĂ©tier
  • Un Scrum Master
  • Une Ă©quipe de 4 dĂ©veloppeurs
  • Les POs et les Ă©quipiers sont sur des sites distants de quelques centaines de kilomĂštres.
  • Les sprints font 2 semaines et de vrais utilisateurs sont prĂ©sents (par connexion car ils sont Ă  l’Ă©tranger) Ă  la dĂ©mo de sprint

Et voici les rĂ©ponses au J’aime / J’aime pas, assaisonnĂ© d’une petite explication dite oralement durant la rĂ©trospective

J’aime
  • Les Post IT –> Et donc le management visuel au sein de l’Ă©quipe
  • Les User Story (2 fois) –> La structure qui permet de bien comprendre ce qui est Ă  faire
  • Les retours frĂ©quents sur le produit (2 fois) –> Les feedbacks des utilisateurs sur ce qui est prĂ©sentĂ©
  • Les Ă©changes humains entre les Product Owner et les Ă©quipiers
  • Les Ă©changes de qualitĂ© entre le mĂ©tier, la maĂźtrise d’ouvrage, les clients et le prestataire
  • La dĂ©mo toutes les 2 semaines –> La cadence du projet
  • La priorisation des fonctions Ă  dĂ©velopper –> La souplesse liĂ©e Ă  la mĂ©thode et le focus sur ce qui Ă  faire maintenant
J’aime Pas
  • Google Drive –> Pour gĂ©rer le Product Backlog
  • La prĂ©paration de la dĂ©mo –> GĂ©nĂšre du stress sur des effets de bord potentiels de la derniĂšre story finie
  • Le temps rĂ©servĂ© Ă  la prĂ©paration de la dĂ©mo –> Trop long
  • La priorisation permanente –> Qui peut gĂ©nĂ©rer des insatisfactions chez les utilisateurs
  • Les rĂ©unions de pondĂ©ration (2 fois) –> Trop longue avec le Poker Planning … bien que trĂšs utile
  • Le refactoring permanent –> Pas facile pour les Ă©quipiers de reprendre souvent leur code
  • La contractualisation sous forme d’engagement de moyen –> Difficile Ă  faire accepter en interne par le management et les achats

Nous avons ensuite discutĂ© sur les « J’aime Pas » pour identifier 3 actions d’amĂ©lioration Ă  mettre en place rapidement.

Et vous, quels seraient votre « J’aime / J’aime Pas » sur votre projet ?

Catégories: Blog Individuel

Coaching et Management

Être Agile - Thierry Cros - lun, 06/02/2014 - 15:59


Expression de besoins la boite Ă  outils du Product Owner :
Le livre Spécifiez agile est disponible


DĂ©couverte du site :

Lire la suite

Catégories: Blog Individuel

Gestion des risques en Mode Agile: les clés


Qualitystreet - Jean Claude GROSJEAN - lun, 06/02/2014 - 10:35

La gestion des risques est une activitĂ© essentielle et incontournable de tout projet. Enjeu fort de tout projet, le pilotage des risques est paradoxalement passĂ© sous silence, traitĂ© Ă  la vite ou envisagĂ© au travers d’un excel poussiĂ©reux jamais rĂ© ouvert depuis sa crĂ©ation… Ce que je vous propose, remettre la gestion des risques sur…

The post Gestion des risques en Mode Agile: les clĂ©s… appeared first on QualityStreet - Blog Pro de Jean Claude Grosjean.

Catégories: Blog Individuel

Scrum perfectionnement Paris du 29 septembre au 1er octobre 2014

Être Agile - Thierry Cros - lun, 06/02/2014 - 08:32

Cette formation est constituée essentiellement d'ateliers, de jeux pour faire et pour apprendre.

Lire la suite

Catégories: Blog Individuel

[Session] Et si on maĂźtrisait vraiment notre produit, pour changer

Agile Nantes - lun, 06/02/2014 - 07:58

ATTENTION: Cet Ă©vĂ©nement aura lieu Ă  l’Epitech et non Ă  la Cantine NumĂ©rique comme prĂ©vu initialement.

Avec le temps, l’informatique nous a habituĂ© Ă  l’approximation. Les applications prĂ©sentent des dĂ©fauts, les performances ne sont pas au rendez vous, les rĂ©gressions sont courantes. Lorsque l’on regarde de l’autre cĂŽtĂ© de la barriĂšre, les Ă©quipes dĂ©ploient des efforts considĂ©rables pour garantir le bon fonctionnement mais les coĂ»ts de maintenance ne cessent d’augmenter.
Le produit ressemble bien souvent Ă  un assemblage de composants bricolĂ©s Ă  tel point qu’il arrive que l’on se demande par quel miracle l’application arrive Ă  fonctionner. Ce constat est navrant Ă  l’heure oĂč il existe une multitude de moyens pour reprendre le contrĂŽle de nos dĂ©veloppements.
Cette prĂ©sentation propose de mettre en lumiĂšre les difficultĂ©s rencontrĂ©es et les moyens d’y remĂ©dier Ă  travers des outils et des techniques Ă  notre disposition. Elle cherche Ă  progresser vers ce monde utopique oĂč le « bug » n’est plus la normalitĂ©.

Support de la prĂ©sentation (les explications peuvent ĂȘtre rĂ©cupĂ©rĂ©es en tĂ©lĂ©chargeant la prĂ©sentation sur SlideShare) :
Et si on maĂźtrisait vraiment notre produit from atnantes

 
SĂ©bastien Fauvel est rentrĂ© dans l’agilitĂ© il y a plus de 10 ans Ă  travers un projet en eXtreme Programming. Cette expĂ©rience a radicalement changer sa maniĂšre d’aborder le dĂ©veloppement logiciel. Depuis, il met en place les pratiques et diffuse la « philosophie agile ». En 2009, avec le groupe d’agilistes nantais, il participe Ă  la crĂ©ation de l’association Agile Nantes.

Quand et oĂč ?

OĂč: Epitech, 18 rue Flandres Dunkerque Ă  Nantes

Quand: mercredi 04 juin 2014, 19h-20h30

Faut il s’inscrire ? oui, c’est par ici.

N’hĂ©sitez pas Ă  transmettre l’information autour de vous.

Merci Ă  l’Epitech qui nous accueille.

Catégories: Association

Oui ? Non ? Pt’ĂȘt ben que oui, pt’ĂȘt ben que non

ekito people - dim, 06/01/2014 - 23:10

      TL;DR: 

AmĂ©liorer les messages d’alertes de @NAVIGON_ et @chronodrive

Amelioration-message-alerte-iOS-Chronodrive Amelioration-message-alerte-iOS-Navigon

http://ekito.fr/people/?p=4636

 

 

Quoi de plus énervant que de recevoir une réponse de Normand ? Devoir répondre à une question de Normand.
Et pourtant, les exemples dans les applications mobiles sont nombreux.

 

Dans ses guidelines, Apple a une section dédiée à ce sujet :

As much as possible, use verbs and verb phrases that relate directly to the alert text—for example, “Cancel,” “View All,” “Reply,” or “Ignore.” – source

en français : “utilisez des verbes pour les boutons des alertes”

Voici deux contre-exemples, avec une proposition de correctif.

 

Garmin et Chronodrive ont donné leur accord pour la publication de cet article. Nous les remercions de leur transparence.
Chronodrive fera Ă©voluer son application d’aprĂšs ces recommandations lors de la prochaine mise Ă  jour majeure !

 

1er exemple, l’excellente application Chronodrive.
Quand je veux supprimer un produit de ma liste intelligente, on me demande :

 

Chronodrive Non Oui

 

 

A ce moment, je viens de supprimer un produit via le bouton avec l’icĂŽne de poubelle. Je me doute bien que cet Ă©cran me demande de confirmer mon action.

Mais, est-ce que :

  • Non => Finalement Non je ne veux pas supprimer
  • Oui => Oui, vas y supprime

ou

  • Non => Non Je ne veux pas garder ce produit
  • Oui => Oui, finalement je veux le garder dans ma liste

Je suis obligĂ© de lire le texte de l’alerte pour savoir comment rĂ©pondre,

Et soyons rĂ©aliste, en tant qu’utilisateur, nous voulons aller vite et ne lisons pas l’intĂ©gralitĂ© des messages.

Tout ces moments d’ambiguitĂ© s’additionnent dans l’inconscient de l’utilisateur.
Un utilisateur qui sent qu’il va vite et est efficace se sent valorisĂ© (et intelligent)
 et du coup aime et recommande votre appli !

 

Remplaçons par des verbes d’action :

Chronodrive app iOS verbes actions

On constate qu’en remplaçant Oui et Non par les verbes Annuler et Supprimer, je n’ai mĂȘme plus besoin de lire le dialogue au dessus pour ĂȘtre sĂ»r de ma rĂ©ponse.

 

Au passage, raccourcissons le texte, cela le rendra encore plus lisible :

Chronodrive iOS message raccourci

 

Notre deuxiĂšme exemple est l’application de guidage GPS Navigon.

Ici, la question posée est un petit peu plus complexe. Malheureusement, la formulation rend la question trÚs peu claire.

 

Je vous laisse lire et essayer de comprendre ce que vous devez rĂ©pondre ; n’oubliez pas que vous ĂȘtes au volant et pressĂ© de vous rendre Ă  votre destination !

Il va de soit que nous dĂ©conseillons l’usage de smartphone au volant, et dĂ©clinons toute responsabilitĂ© en cas de collision avec un petit poney ; voir avec notre spĂ©cialiste sur ce sujet pour la jurisprudence en vigueur.

 

Navigon Non Oui

 

Le pire Ă©tant qu’aucune action de l’utilisateur ne dĂ©clenche l’affichage de cette alerte. Elle est prĂ©sentĂ©e automatiquement quand on veut dĂ©marrer une navigation sans avoir eu le temps de tĂ©lĂ©charger les fichiers de de guidage sonores.

Quiz du jour : Quel pourcentage d’automobilistes savent ce que veut dire l’acronyme WLAN ?

Ce message sera lu par une majoritĂ© des utilisateurs venant d’installer l’application
 pas gĂ©nial comme premier contact.

 

Remplacement par des verbes :

Navigon iOS verbes actions

 

La question est posĂ©e de maniĂšre interro-nĂ©gative “quand une connexion Wifi (WLAN) n’est pas disponible”, ce qui ne facilite pas la lecture.

Est-ce que les questions interro-négatives ne sont pas non compliquées à lire ? Hmmm


Idem, le texte descriptif est beaucoup trop long, donc mĂȘme traitement.

Au passage, on utilise le titre de l’alerte pour indiquer le contexte, et le texte pour donner les dĂ©tails nĂ©cessaires.

Navigon iOS Alerte avec titre

 

On progresse :)

Essayons de clarifier encore un peu en masquant les détails techniques. Donc au revoir la notion de fichiers.
Enfin, on simplifie encore un peu plus le texte, pour aller directement Ă  l’essentiel de la question :

Navigon-GPS-iOS-verbes-actions-pas-detail-technique

 

On finit notre processus itĂ©ratif avec une derniĂšre Ă©tape
  avec une entorse Ă  la rĂšgle juste Ă©noncĂ©e.
On avait masquĂ© la notion de fichiers, par contre nous allons ajouter la taille du fichier Ă  tĂ©lĂ©charger. En effet, un utilisateur normal a besoin de cette information pour se dĂ©cider. Quelques dizaines de MĂ©ga-octets, il sait qu’il peut essayer, plusieurs Giga-octets, il sait que ce n’est pas possible.

On en profite pour supprimer le mot maintenant, qui n’apporte pas d’info, et les parenthĂšses qui nuisent Ă  la lecture.

Navigon-iOS-avec-taille

 

Mise Ă  jour :

Laissez reposer. Montrez le autour de vous, de prĂ©fĂ©rence Ă  des gens non techniques. Puis continuez Ă  Ă©liminer tout ce qui n’est ni clair ni essentiel.
On continue les itérations, en simplifiant encore un peu plus.

Supprimer les alternatives prĂ©sentes dans le texte et les boutons. Ici “attendre une connexion WiFi“.
Le “voulez-vous” n’apporte aucune valeur contextuelle.

Navigon-iOS-verbes-actions-simplification

 

 

On compte dĂ©sormais sur vous pour simplifier les messages d’alertes de vos applis et utiliser des verbes pour les titres des boutons
 p’tĂȘt ben qu’oui, p’tĂȘt ben qu’non !

The post Oui ? Non ? Pt’ĂȘt ben que oui, pt’ĂȘt ben que non appeared first on ekito people.

Catégories: Blog Société

[ #ESPC14 ] TH10 Moving mountains with SharePoint !

Le blog de Patrick Guimonet - dim, 06/01/2014 - 10:30
This session was all about professional document management with SharePoint. It was presented by Oliver Wirkus  from Germany. Cette session avait pour thÚme la GED avec SharePoint. Elle tait présentée par O...
Catégories: Blog Individuel

[ #ESPC14 ] T10 Delivering SharePoint as a Service & TH25 Building an operational SharePoint Governance Practice

Le blog de Patrick Guimonet - sam, 05/31/2014 - 07:55
After following the pre-conference on Governance Service Delivery by Dan Holme , I was curious to follow these two sessions on Governance and Service Delivery by Anders B. SkjĂžnaa from Denmark. AprĂšs avoir ...
Catégories: Blog Individuel

Agile : l'avenir est politique

Être Agile - Thierry Cros - ven, 05/30/2014 - 08:54

Depuis le début des années 2000, ce qui est désigné par agile est en expansion. Si dans un premier temps - et sous l'égide de l'Extreme Programming - les bases étaient posées dans la communauté des Développeurs, il restait encore à embarquer l'IT dans son ensemble, au-delà l'organisation... IT ou pas. Nous en sommes à ces prémices.

Lire la suite

Catégories: Blog Individuel

[ #ESPC14 ] TH4 PowerBI and SharePoint Online / Martina Grom

Le blog de Patrick Guimonet - jeu, 05/29/2014 - 16:01
This session was presented by Martina Grom ( @magrom ) and was about Analytics on and with Office 365 data. Cette session Ă©tait prĂ©sentĂ©e Martina Grom ( @magrom ) et abordait l’Analyse des donnĂ©es dans et a...
Catégories: Blog Individuel

Notes sur l’Agile ConfĂ©rence 2014

Barre Verte ! - mer, 05/28/2014 - 21:13

Ça se passait les jeudi-vendredi 22 et 23 mai toujours au chalet de la porte jaune. Cette annĂ©e, la confĂ©rence suivait au moins 2 fils. L’un explicite « le fil rouge », activitĂ© de mĂ©diation graphique omniprĂ©sente et l’autre en trame, avec une rĂ©sonance entre la keynote de RĂ©gis MĂ©dina sur le produit lean et les sessions qui ont suivi.

L’aprĂšs-XP pour du dĂ©veloppement produit

Avis de non-responsabilitĂ© : pratiquant l’XP depuis 7 ans, en partie avec Antoine C, et travaillant avec David B, membre de l’Ă©quipe d’organisation les propos suivants sont Ă©ventuellement subjectifs ;)

Cette keynote Ă©tait une bonne introduction, une synthĂšse construite autour de l’expĂ©rience de RĂ©gis parti de l’extreme programming pour faire du lean. Ce ne sont plus des pratiques lean (les liens ci-dessous) qui sont expliquĂ©es mais l’utilisation de ces pratiques au service d’un nouveau modĂšle de gestion du systĂšme de production logicielle. Le marchĂ© a changĂ©, l’open source, les plate-formes de tĂ©lĂ©chargement (apple store, android store…), les Ă©diteurs, mettent en compĂ©tition Ă©normĂ©ment d’acteurs. Pour sortir du lot, il faut crĂ©er un effet « whaoo!! ».

Pour cela, il revient sur la mĂ©taphore artistique : il faut un rĂ©alisateur, comme pour un film. Quelqu’un qui ait

  • la vision pour positionner le challenge : trouver le segment d’utilisateur ciblĂ©, les paramĂštres clĂ©s du logiciel (par ex pour google chrome, la vitesse), et les points durs Ă  solutionner. Le gemba ou go and see, est un bon moyen d’identifier ces 3 parties du concept.
  • l’encadrement pour cultiver le dĂ©saccord : le consensus rapide que promeut l’agilitĂ© est Ă©galement source de re-travail (rework). Pour crĂ©er l’alignement, le set based design assure une discussion basĂ©e sur des faits. Le management visuel fournit des modĂšles pour animer la collaboration, propose une vision partagĂ©e du produit.
  • l’exigence de dĂ©nicher les erreurs : des revues de design permettent de crĂ©er le challenge nĂ©cessaire Ă  l’affinage de la vision. L’ouverture des vannes de retour utilisateur gĂ©nĂšre une source de rĂ©solution de problĂšme par PDCA.

IMGP6867

BenoĂźt Charles-Lavauzelle qui nous expliquait ensuite « Comment impliquer vos clients dans leurs projets », Ă©tait en parfaite continuitĂ© avec cette keynote. Il nous relatait sous format PDCA les problĂšmes, hypothĂšses, actions et leçons apprises au niveau de la gouvernance de leur sociĂ©tĂ©. Au cƓur de la dĂ©marche Ă©tait remis en cause le type de contrat au forfait. Mais comment faire accepter des contrats au temps passĂ© Ă  des clients qui choisissent (lorsqu’ils ont le choix) systĂ©matiquement le forfait ? BenoĂźt a un dĂ©clic lorsque l’un de ses clients qui lui dit « les experts c’est vous ». Ils dĂ©cident alors de vendre le temps passĂ© en invoquant :

  • leur vitesse de dĂ©veloppement. Le plus grand dĂ©fenseur du cycle en V sait que la vitesse n’est pas la force de ce type de mĂ©thode.
  • les dĂ©passements dĂ©jĂ  subis par les prospects. Ces derniers conviennent que le risque existe aussi dans ce contrat
  • le risque du temps passĂ© est partagĂ© contrairement Ă  l’argument des avocats du forfait : ThĂ©odo peut avoir des dĂ©veloppeurs en inter-contrat du jour au lendemain si le contrat est dĂ©noncĂ©, et le client rĂ©cupĂšre le code
  • leur grande expertise technique dans un marchĂ© de niche (dĂ©veloppement web PHP-symfony)

Et ça marche!

Ils mettent en place des questionnaires de satisfaction client Ă  chaque sprint avec un objectif de 8/10. Chaque Ă©cart est vu comme un problĂšme qui conduit Ă  un PDCA. Ils font participer le client au planning-poker (avec un vote). Ils envoient un mail quotidien aprĂšs chaque daily, contenant le burndown et le board virtuel Trello. Ils partagent la vision avec des boards physiques dans les Ă©quipes. De cette maniĂšre ils proposent Ă  leur client de devenir pilote de la voiture de course qu’est ThĂ©odo. Il pilote les choix fonctionnels et budgĂ©taires.

Bien sĂ»r, la session sur la rĂ©trospective continue par Antoine Contal et RĂ©gis MĂ©dina enfonçait le clou. Ils Ă©voquent les difficultĂ©s de l’amĂ©lioration continue et introduisent en prĂ©cisant que la solution n’est pas dans la rĂ©trospective mais Ă  l’extĂ©rieur : un nouveau dĂ©fi. Pour cela ils proposent de crĂ©er un environnement propice Ă  l’apprentissage, et dĂ©cider qui doit apprendre quoi pour que le format ne soit plus un soucis. Comment ?

  • En dĂ©finissant le challenge de façon mesurable en terme de qualitĂ©, dĂ©lais et productivitĂ©. En se basant sur l’idĂ©e de prospĂ©ritĂ© mutuelle, le gemba permet d’aller voir sur le terrain le problĂšme que cherche Ă  rĂ©soudre le client, comment il se traduit en euros sonnants et trĂ©buchants, en stratĂ©gie pour ses Ă©quipes. L’Ă©coute des Ă©quipes permet de conserver les talents, et on itĂšre sur le gemba
  • en rendant ce challenge visuel : montrer Ă  tous la dĂ©clinaison du challenge sur les murs. Les tĂąches quotidiennes doivent participer Ă  l’atteinte du challenge
  • en animant les exercices de kaizen (amĂ©lioration de chacun). Un problĂšme opĂ©rationnel (ex: le temps de rĂ©solution des bugs est trop important), est dĂ©clinĂ© en plusieurs PDCA qui sont pris en charge par des dĂ©veloppeurs. Par exemple ce temps de rĂ©solution de bug est Ă©levĂ© car les logs applicatives ne sont pas pertinentes. Un dĂ©veloppeur devient alors M. Logs en prenant le sujet avec l’aide d’une ou 2 autres personnes. Il devient expert dans le domaine et peut ensuite retransmettre son expertise aux autres personnes de l’Ă©quipe.

L’intervention du Thibaud BriĂšre le soir, sur l’intelligence collective, proposait de favoriser la diversitĂ© pour pouvoir bĂ©nĂ©ficier des Ă©carts entre les opinions exprimĂ©es, et trouver des nouveaux chemins. Cultivons l’impertinence. La remarque d’un participant sur l’alignement des desseins me fait aussi penser Ă  la congruence de G. Weinberg.

IMGP6900

La keynote du vendredi Ă©tait faite du mĂȘme bois, Rachel Davies nous explique l’organisation de sa sociĂ©tĂ© qui a poussĂ© l’extreme programming bien plus loin que ce que dĂ©crit la littĂ©rature. Et pour cause, Matt Cooke, le directeur technique est un expert XP depuis plus de 10 ans. Leur challenge c’est crĂ©er plus de valeur en rapprochant les opĂ©rationnels de l’expression du besoin, du mĂ©tier, des utilisateurs. Les dĂ©veloppeurs sont organisĂ©s en petites Ă©quipes de 3-4 personnes. Ils Ă©crivent les stories, font du support, ils fonctionnent en flux tirĂ©, font du set based design, chaque story a un leader. AprĂšs le dĂ©jeuner, c’est « story time » un moment pendant lequel ils explorent le besoin avec les gens du mĂ©tier. Pour les « impairs » ils ont mis en place un rĂŽle de « lone rangers« , ils sont disponibles pour la corrections de dĂ©fauts, ou rĂ©pondre aux questions fonctionnelles.

Enfin, Bernard Notoriani nous relate avec Guillaume Nurdin leur expĂ©rience de Dojo et Mob programming. Ou comment ils ont relevĂ© le challenge de la refonte d’une application financiĂšre avec une Ă©quipe rĂ©partie entre l’Espagne, La Belgique, l’Italie et la France contenant 4 experts fonctionnels, 5 dĂ©veloppeurs et un coach XP.

Ils mettent d’abord en place des Dojo-DĂ©veloppements pour faire monter en compĂ©tence les dĂ©veloppeurs dĂ©butants. 2 fois par semaine, 2h, avec une prĂ©paration minutieuse. AprĂšs avoir montrĂ© un geste (ex un CRUD), ils font rĂ©pĂ©ter le mĂȘme geste Ă  chacun d’entre eux. Puis vient l’idĂ©e du Mobprogramming c’est un poste de dĂ©veloppement, une Ă©quipe de 4-6 personnes avec un PO, des rotations tous les 1/4h derriĂšre le poste et un rĂ©troprojecteur pour que tout le monde puisse suivre. Leur implĂ©mentation est diffĂ©rente pour des raisons logistiques, ils essayent 1/2j par semaine ou 1j par semaine en sous Ă©quipe, sur les sujets complexes de l’application sans PO (pas facilement disponibles et Ă©loignĂ©s).

Ils dĂ©clinent ensuite sous forme de Requirement-Mob pendant lequel ils itĂšrent sur les spĂ©cifications. AprĂšs avoir Ă©chouĂ© Ă  travailler depuis le format FitNesse, ils utilisent un template word accompagnĂ© Ă©ventuellement d’une feuille de calcul excel. Ils dĂ©crivent les scĂ©narii (Tests d’acceptance) de l’application et incorporent les tests dans leur wiki FitNesse.

Une inconférence dans la conférence

IMGP6884

Un grand bol d’air avec un jeudi aprĂšs midi consacrĂ© Ă  une parenthĂšse d’inconfĂ©rence. La pluie s’est calmĂ©e, et a fait place Ă  de belles Ă©claircies, permettant des sessions en plein air. Bien sĂ»r il y avait un peu d’Ă©go-trip dans certaines propositions. Mais nous avons pu parler de ce qui fait qu’une Ă©quipe est agile, jouer avec l’ableton push de Guillaume Saint Etienne, parler du buzz du moment le TDD (ou plutĂŽt Requirement Driven Developpment) avec Étienne Charignon.

Dans un esprit trĂšs Agile Open (en session de la confĂ©rence) nous avons pu voir du coding live, grĂące Ă  Emmanuel Gaillot, qui nous a montrĂ© qu’on pouvait faire du TDD avec… de l’assembleur (i386 je crois). TrĂšs agrĂ©able de voir la progression mĂ©thodique et rĂ©guliĂšre qui ne laisse personne au bord du chemin sur un sujet aussi difficile qu’inhabituel.

Le format court et rapide des sessions du vendredi aprĂšs-midi dans la salle plĂ©niĂšre Ă©tait Ă©galement divertissant, avec notamment la belle prĂ©sentation de Matti Schneider sur Petit Board Deviendra Grand, ou comment faire de l’amĂ©lioration continue par les artefacts, en faisant Ă©voluer son management visuel pour qu’il modĂ©lise le systĂšme de production. Comme le modĂšle est moins complexe que le systĂšme reprĂ©sentĂ©, il est plus facile de le discuter, le modifier.
artefact
Lorsque le modĂšle rĂ©sonne avec le systĂšme, on atteint le graal : l’hyperproductivitĂ©. RĂ©trospectivement, sur un projet passĂ© dans la tĂ©lĂ©phonie (dans lequel nous avions parlĂ© de l’importance de la modĂ©lisation avec Antoine C), c’est en partie ce qui nous est arrivĂ©. Je ne l’avais jamais vu sous cet angle.

Bref, bonne Ă©dition de la confĂ©rence, mĂȘme si on sent bien une adoption de l’agilitĂ© par le « mainstream », preuve aussi de son succĂšs, l’organisation a bien su mettre l’emphase sur ceux qui continuent d’avancer. Merci Ă  eux de venir partager leurs trouvailles.

Catégories: Blog Individuel

[ #ESPC14 ] W28X Introducing Codename Oslo and the Office Graph

Le blog de Patrick Guimonet - mer, 05/28/2014 - 16:22
  This session was a very interesting and awaited one, being fully dedicated to #CodenameOslo. It was presented by Troels Walsted Hansen, from Microsoft Corp, but based in Norway, managing a team coming from the FA...
Catégories: Blog Individuel

Université de la Performance -retour sur DevoxxFR 2014

Le blog des experts du groupe Infotel - mer, 05/28/2014 - 09:37
Sebastien VAIRA, Senior Developper JEE / Grails revient sur une session Performance de DevoxxFR 2014 La performance, partie intĂ©grante du travail de chacun d’entre nous, se doit d’ĂȘtre au cƓur de nos dĂ©veloppements ; nous ne devons pas nĂ©gliger cet … Lire la suite →
Catégories: Blog Société

[ #ESPC14 ] Keynote 4 Attractive & Collaborative Business Intelligence with Microsoft Power BI and SharePoint / Rafal Lukawiecki

Le blog de Patrick Guimonet - mar, 05/27/2014 - 16:00
This 4th keynote was dedicated to BI and Power BI. It was presented by Rafal Lukawiecki ( @rafaldotnet) owner of projectbotticelli.com The slides are available here : https://projectbotticelli....
Catégories: Blog Individuel

[ #ESPC14 ] Keynote 3 Make Social Successful / Christian Buckley and Mark Kashman

Le blog de Patrick Guimonet - mar, 05/27/2014 - 07:27
#CodenameOslo #OffficeGraph #Yammer #Office365 This third keynote was fully dedicated to Social and how to make it successful. It was presented by Christian Buckley (@buckleyplanet) a well-know blogger and MVP and Mark...
Catégories: Blog Individuel

Crypt and decrypt a SQLite database in an iOS and Android application

ekito people - lun, 05/26/2014 - 10:16

We just published an article showing how to crypt a SQLite database, and decrypt it from an iOS and Android application.

 

Ceci n’est pas une base de donnĂ©e. C’est peut-ĂȘtre une base de donnĂ©e cryptĂ©e.

This is not a database. This maybe is a crypted database.

 

Image with Creative Commons license (Attribution-Noncommercial-Share Alike 3.0 Unported).
Database picture by Barry Mieny, with a Creative Commons license (Attribution-Noncommercial-Share Alike 3.0 Unported).

 

We are using SQLCipher, an open source extension of SQLite.

We show how to crypt the database on Mac OS X, and how to decrypt it to query it on mobile (iOS & Android) ; we also explain our strategy to crypt the database in your build process.

The original article, in french, is available here, with all details, step by step.
If you can’t read french, we published the code of the project on github.com/ekito.

The post Crypt and decrypt a SQLite database in an iOS and Android application appeared first on ekito people.

Catégories: Blog Société

Partagez la connaissance

Partagez BlogsdeDeveloppeurs.com sur les réseaux sociaux