Au premier arrêt, en gare de Nurieux, à quelques 480 km de Paris, une femme monte dans le wagon, et de façon assez désagreable, lance aux deux jeunes assis près de la porte : “C’est ma place !”. Après s’être regardés, les deux jeunes, hésitants, se lèvent et l’un d’eux change de place.

A l’approche de l’arrêt suivant, à Bellegarde, la femme se lève pour descendre : elle cherche alors sa valise sans succès, et en fait part au wagon en faisant porter sa voix. Le train étant arrivé en gare, elle bondit hors du wagon pour interpeler vivement la controlleur sur le quai… A tel point que tout le wagon a pu suivre la conversation de l’intérieur : “Non madame, vous êtes descendu du wagon 12 à Nusieux et êtes remonté dans le wagon 13″. On voit alors la femme courrir le long de notre wagon 13 en direction du 12, et effectivement repasser dans l’autre sens avec sa valise !

Ce moment de vie est une belle leçon, et à plusieurs niveaux.

• Oui la place était la bonne, mais avec un peu de recule, ce n’était pas le bon wagon.
• Une bonne raison pour rester respectueux dans des situations de crise ou de conflit.
• Pour ma part, les deux jeunes portent leur part de responsabilité : ils ont été trop conciliants. Un minimum de feedback, un simple “Pourquoi ?” ou “Etes-vous certain(e) ?”
• Enfin, cela peut aller loin si on n’est pas vigilant. J’ai honte d’avouer que ma première pensée a été de me dire que les deux jeunes s’étaient vengés…

Attention aux certitudes… Avec respect !

 

Les Catégories en Objective-C : “Ça ressemble à de l’Objet, c’est encapsulé comme l’Objet… mais ce n’est pas de l’Objet”

Je suis en train de travailler sur une application iPad qui doit reprendre une partie du code source d’une précédente version de l’application.

Une des fonctionnalités que j’ai réutilisée est le blog. Il repose sur la digestion en lecture seule d’un flux JSON. Ce flux JSON, via l’API native iOS, retourne un NSDictionary (une hash map) par item, ou plus exactement un tableau (NSArray) d’items (NSDictionary).

Afin de limiter les modifications dans les sources que j’ai importées de la version antérieure, je me suis demandé si je ne pouvais pas utiliser directement les classes natives (NSArray et NSDictionary) au lieu de créer des classes dédiées (Blog et Post).
Et cela s’est finalement bien passé, et donne une solution plutôt séduisante grâce à un idiome du langage Objective-C : les Catégories.

Voir à la fin pour les sources du projet d’exemple.

En Ruby, on parle aussi de ré-ouverture de classe.

Etant donné que, contrairement au C++, Objective-C ne supporte pas l’héritage multiple, les catégories, avec les protocoles, sont un bon moyen d’étendre une classe.

Théorie

Pour ce qui est de l’aspect théorique des Catégories, je vous renvoie notamment au chapitre Catégories, extensions et sécurité (PDF) car il est en partie accessible sur le site de Pearson.

On peut notamment y trouver des arguments permettant de choisir entre héritage et catégorie :

• “La simplicité prévaut” : il est conseiller de minimiser la longueur de la chaine d’héritage
• “La création d’une sous-classe d’une classe implémentée sous forme d’un regroupement de classes, comme NSString, demande un travail important“
• “Les catégories ont une visibilité plus grande” : pour le meilleur (on peut accéder aux méthodes définies sur n’importe quelle instance) et pour le pire (y compris celle dont on ne voudrait pas). Par exemple, une catégorie de NSString définissant une méthode retournant le domaine d’une adresse email peut être appelée sur n’importe quelle string, y compris des strings n’ayant rien à voir avec un email.
• “La redéfinition avec une catégorie présente des risques” : via une catégorie on peut redéfinir les méthodes de la classe étendue, ce qui est très puissant, et donc très risqué
• “L’ajout de variables d’instance exige une sous-classe” : mais on peut contourner cette contrainte avec des property (que l’on peut créer sur une catégorie).
• “Parfois, vous n’avez d’autre choix que de créer une sous-classe“… “Si vous devez étendre la même classe de différentes manières en différents endroits du programme“
• “Certaines classes imposent la création de sous-classes“, notamment les classes abstraites qui ne peuvent pas être étendues via une catégorie.
• “Essayez la composition” : cela est vrai pour les langages orientés objets en général, de Privilégiez la composition à l’héritage.

Encore une fois, étant donné que, contrairement au C++, Objective-C ne supporte pas l’héritage multiple, les catégories, avec les protocoles, sont un bon moyen d’étendre une classe.

Pratique

Dans mon cas, un post a donc la structure JSON suivante :

{
 "date": "2013-04-04",
 "imageURL": "http://www.mydomain.com/upload/photo.jpg",
 "title": "Objective-C Category",
 "id": 6903,
 "author": "Jacques COUVREUR"
 }

J’ai donc créé une catégorie sur la classe NSDictionary qui permet de d’accéder aux valeurs sans avoir à spécifier la clef :

// NSDictionary+Post.m

@implementation NSDictionary (Post)

- (NSString*) postTitle { return [self objectForKey:KEY_TITLE]; }
- (NSString*) postAuthor { return [self objectForKey:KEY_AUTHOR]; }
- (NSString*) postDate { return [self objectForKey:KEY_DATE]; }
- (NSString*) postImageURL { return [self objectForKey:KEY_URL]; }
- (NSString*) postText { return [self objectForKey:KEY_TEXT]; }

Par expérience, j’ai pris l’habitude de préfixer le nom des messages (méthodes) de la catégorie par son nom, afin de les retrouver plus facilement par complétion et ainsi faciliter l’utilisation par la suite.
Cela permet aussi d’éviter les collisions avec des méthodes existantes sur la classe étendue.

J’ai également une méthode qui permet de prendre une version nouvellement téléchargée d’un post (un NSDictionary) et de la fusionner avec la version sauvegarder du même post (même ID) :

- (NSDictionary*) postUpdateWith:(NSDictionary*)downloaded {
  NSMutableDictionary* result = [NSMutableDictionary dictionaryWithDictionary:self];
  if (downloaded) {
    NSString* value = [downloaded postID];
    if (value) [result setValue:value forKey:KEY_POST_ID];
    [self updateFirst:result withSecond:downloaded forKey:KEY_TITLE];
    [self updateFirst:result withSecond:downloaded forKey:KEY_AUTHOR];
    [self updateFirst:result withSecond:downloaded forKey:KEY_DATE];
    [self updateFirst:result withSecond:downloaded forKey:KEY_IMGURL];
    [self updateFirst:result withSecond:downloaded forKey:KEY_TEXT];
  }
  return result;
}

J’ai ainsi fait émergé une entité de post, ses responsabilité, sans définir de classe mais en reposant sur une classe existante.
Et comme je le disais, ces posts sont recensés dans un tableau.

Pour être précis, le fonctionnement du blog est le suivant :

1. A la consultation du blog, l’App affiche les posts sauvegardés
2. L’App télécharge la liste de tous les posts en version allégée (plus de 400 posts, avec seulement le titre et l’ID)
3. L’App affiche les 20 plus récents
4. L’App télécharge le détail de ces 20 plus récents (texte et image)
5. L’App sauvegarde ces 20 posts pour pouvoir fonctionner en mode offline.

En dehors du téléchargement, j’ai décidé de centraliser les fonctionnalités de gestion des posts dans une catégorie de NSArray. On dirait bien qu’une abstraction Blog vient d’émerger :

// NSMutableArray+Blog.m

@implementation NSMutableArray (Blog) 

// Find a post by its ID
- (NSDictionary*) blogPostWithID:(NSString*)wantedPostID {
  NSArray* posts = [NSArray arrayWithArray:self];
  for (NSDictionary* post in posts) {
    NSString* currentID = [post postID];
    if ([wantedPostID isEqualToString:currentID]) return post;
  }
  return nil;
}

// Does blog contains a post?
- (BOOL) blogContainsPost:(NSDictionary*)postInfo {
  return [self blogPostWithID:[postInfo postID]] != nil;
} 

// Return a new NSArray by merging self and the recentArray.
// Only the 'size' first elements of results are returned
- (NSMutableArray*) blogUpdateWith:(NSArray*)recentArray withFinalSize:(int)size {
  NSMutableArray* keep = [NSMutableArray arrayWithCapacity:size];
  int keepSize = 0;
  for (int i = 0; i < recentArray.count && keepSize < size; ++i) {
    NSDictionary* post = [recentArray objectAtIndex:i];
    if ([self blogContainsPost:post]) {
      NSDictionary* old = [self blogPostWithID:[post postID]];
      NSDictionary* updated = [old postUpdateWith:post];
      [self blogReplacePost:updated];
    } else {
      [keep addObject:post];
    }
    ++keepSize;
  }
  NSArray* result = [keep arrayByAddingObjectsFromArray:self];
  result = [result subarrayWithRange:NSMakeRange(0, MIN(result.count, size))];
  result = [result sortedArrayUsingComparator:^NSComparisonResult(NSDictionary* a, NSDictionary* b) {
      NSString* first = [a postDate];
      NSString* second = [b postDate];
      return [second compare:first];
    }];
  return [NSMutableArray arrayWithArray:result];
} 

// Replace existing post inside self with newPost(based on post ID)
- (void) blogReplacePost:(NSDictionary*)newPost {
  NSDictionary* old = [self blogPostWithID:[newPost postID]];
  int oldIndex = [self indexOfObject:old];
  [self replaceObjectAtIndex:oldIndex withObject:newPost];
}

J’ai décidé de créer et utiliser une méthode de remplacement plutôt que de mettre à jour directement le NSDictionary dans le NSArray, car l’API JSON retourne des NSDictionary imutables.

Dans ce cas précis, l’utilisation de catégories présente un autre intérêt.
Etant donné que les données sont peu volumineuses, en accès lecture seule et consultation “globale” (sans recherche), j’ai décidé de sauvegarder simplement les données dans les NSUserDefaults.
Or, l’enregistrement et le chargement de tableaux (NSArray) et hashmap (NSDictionary) est immédiate :

- (void) saveInUserDefaults {
  NSData* eventsData = [NSKeyedArchiver archivedDataWithRootObject:self.blogArray];
  NSUserDefaults* defaults = [NSUserDefaults standardUserDefaults]
  [defaults setObject:eventsData forKey:KEY_BLOG];
  [defaults synchronize];
}

- (void) loadFromUserDefaults {
  NSUserDefaults* defaults = [NSUserDefaults standardUserDefaults];
  NSData* eventsData = [defaults objectForKey:KEY_BLOG];
  self.blogArray = [NSMutableArray arrayWithArray:(NSArray*)[NSKeyedUnarchiver unarchiveObjectWithData:eventsData]];
}

Sources

Vous pouvez télécharger le projet XCode d’exemple (avec les tests unitaires) : lire le README.txt pour les instructions.

Conclusion

Jusqu’à présent j’utilisais les catégories pour ajouter des méthodes helpers sur des classes natives, comme par exemple une méthode “isBlank” sur NSString.

Mais dans ce cas précis, les catégories constituent une alternative séduisante, et légitime (à mon sens) à de la Programmation Orientée Objet : elles procurent les avantages de cette dernière sans avoir à écrire la moindre nouvelle classe et donc utiliser directement les objets de l’API.

A moins que vous ayez un avis contraire ?…

“Immersion dans un jeu de construction collectif”

Notamment par curiosité. Qui sont ces gens qui ont monté un groupe similaire à celui que j’ai créé avec Alex l’année dernière (Serious G@GE) ? Et qui sont ces participants ?

Également par envie de (re)jouer avec des Lego… Quel est donc cet autre jeu à base de Lego ?

Bref quelques attentes…

On reconnait bien Hamidul et Nathalie ;)

Après quelques détours j’arrive enfin à trouver l’entrée sur le campus de la HEG SO de Genève… Ah les campus, toujours un casse tête pour s’y retrouver. D’où l’importance d’un bon fléchage (le JUG GE l’a bien compris et excelle dans ce domaine). Mais les organisateurs avaient indiqués leur mobile sur le meetup avant la soirée : donc on… je… s’en est très bien sorti.

En arrivant sur place, je fais la connaissance de Cédric et Nathalie, deux des organisateurs. Une petite collation avant/pendant/après : idéale pour rompre la glace et faire connaissance.

On papote un peu et c’est parti. Oliver Wagner nous explique l’atelier et ses fondements.
Cynefin vient de Agile42.
Il a pour objectif de faire prendre conscience d’une classification de projets selon leur complexité.
L’occasion de faire la distinction entre compliqué (un Airbus par exemple) et complexe (un plat de spaghettis  ou un porte avion nucléaire….), mais aussi pour moi d’entendre ma première douleur : “il faut rendre deterministe ce qui ne l’est pas”. Ouatch… Déjà bon courage, et ensuite pourquoi s’entêter à faire rentrer un rond dans un carré ? Pourquoi ne pas considérer d’une part le carré pour la beauté de ses angles et ce qu’ils apportent, et d’autre part le rond pour la beauté de ses arrondis et ce qu’ils apportent ?

3 équipes, 3 itérations… ET DES LEGO… C’est parti !

Itération 1

Faire des tas par couleur pour deux équipes et par taille pour la 3e équipe…
Et on arrive premier en 1’40”… Ouah les stars ;)

Puis on débrief.
“Pourquoi êtes vous premiers ?”… “On a planifié !” dit un membre de l’équipe… Je ne trouve pas ! Cela exprime selon moi un vieux fantasme que la planification est gage de réussite rapide. Sans concertation, chacun a pris spontanément une couleur, certains ont passé des pièces à d’autres… Bref, une bonne grosse auto-organisation. Mais je pense que cela a bien fonctionné car finalement chacun travaillait sur son propre tas…

Itération 2

On doit maintenant construire une tour avec 3 règles :

1. 20 étages, de couleur régulière
2. Un étage N+1 doit être plus petit ou égale en largeur à l’étage N
3. Chaque couleur ne peut être touchée que par une même personne

Là on s’est fait plié : mauvais qu’on a été !

Puis on débrief
“Il manquait des specs claires”… Je ne trouve pas non plus.
“Il faudrait faire les règles plus claires”… Toujours pas : je les trouve déjà bien plus claires que ce que l’on a dans la VVP (Vraie Vie Professionnelle)… Au contraire, pour être plus réaliste il faudrait les embrouiller ;)

Par contre nous sommes partis à faire un premier rang (les fondations) de grande dimension, de couleur unique (forcément). Du coup, on a à peine eu le temps de commencer le second étage. Les premiers on empilé 20 briques identiques avec une alternance de 2 couleurs : that’s all !!!

Ouatch, 2 itérations de quelques minutes et quelques briques suffisent pour faire office de puissant révélateur :

1) Nous sommes complètement formatés

2) Nous avons une tendance aiguë à complexifier Hallucinant !

Si le jeu s’arrêtait là se serait déjà suffisant, mais ça continue…

Itération 3

On a 30 secondes pour décider ce que l’on va faire entre une voiture et un animal. Et après, en plus des règles précédentes, on ne parle plus, et on va tourner de table en table (que les personnes, les Lego restants sur les tables). L’idée concernant les rotations est d’injecter du chaos.

Une catastrophe ! On récupère notre construction : Mais qu’est ce que c’est ? Elle ne ressemble à rien et elle est fragile. Par contre, une des équipes a réussi à faire une voiture réaliste.

Puis on débrief
Il semblerait qu’avant la première rotation ils aient réussi à faire un châssis ressemblant, avec des roues. Le message était donc clair pour les suivants, et ainsi de suite.

3) Une vision claire dés le début serait donc un élément de réussite d’un projet ?

Mais aussi deux autres nouvelles révélations :

4) Plus le projet dure dans le temps (plus il y a d’itérations) moins l’analyse et la planification initiale n’ont d’intérêt et de pertinence dans le temps

5) Quel handicap pour le projet de ne pas pouvoir se parler, communiquer, et quelle frustration pour les individus.

 

Itération 4

Pour finir, une seule personne par équipe va tourner et pas le droit de toucher sa couleur avant l’arrivée de son remplaçant.

Je propose avant de commencer qu’une personne prenne toutes les couleurs et fasse une tour avec des briques de taille identique. Cela n’est pas incompatible avec la règle “une couleur peut être touchée par une seule personne”. L’idée ne semble pas faire l’unanimité. Je laisse donc l’équipe commencer, je prend deux couleurs et fait un module : le haut de la tour, assez étroite, d’une dizaine d’étages. Une fois la première moitié construite par le reste de l’équipe (4 personnes pour faire la moitié en autant de temps que moi pour faire l’autre moitié, seul), je pose l’autre moitié dessus, et c’est fini.

En dehors du fait que a) j’ai bossé seul dans mon coin (pas très team building ;(), et que b) je sois assez fort pour porter d’une main un immeuble de 10 étages, encore une leçon :

6) Diviser pour mieux régner : décomposer un problème complexe en modules.

Mon doggy bag

Voilà donc ce que je retiens de cette soirée :

1. Nous sommes complètement formatés
2. Nous avons une tendance aiguë à complexifier
3. Une vision claire dés le début serait un élément de réussite d’un projet
4. Plus le projet dure dans le temps moins l’analyse initiale n’a d’intérêt
5. Quels handicap et frustration de ne pas pouvoir se parler, communiquer
6. Diviser pour mieux régner : décomposer un problème complexe en modules.

Mais l’atelier vise, via ses 4 itérations successives, à mettre en évidences une classification de projets : simple, compliqué, complexe et chaotique.

Cynefin framework (source: agile42.com)

Même si comme l’a répété François BEAUREGARD dans sa formation au Management 3.0 “un modèle est faux par définition“, j’ai trouvé la mise en évidence assez efficace, même si il me semble que le chaos à la fin n’ait pas été aussi évident car trop de contraintes (interdiction de parler et juste une couleur par personne). Mais existe-t-il encore dans notre métier des projets simples ou seulement compliqués ?

C’est d’ailleurs ce que je comprend comme postulat de départ de l’agilité ou même du Management 3.0.

Et j’ai l’impression que le temps, ou plus exactement les délais, courts (souvent dans l’urgence), déplacent le barycentre vers la complexité ou le chaos ?!

Et dans ce contexte, la recommandation est :

1. De commencer par *EXPERIMENTER*
2. Puis de bien *OBSERVER*
3. Et enfin *ANALYSER*…

Oui, oui, la première étape est d’y aller, de mettre les pieds dans le plat.

Quant à Analyser, il s’agit d’analyser le processus, pour l’adapter et l’améliorer, on ne parle pas d’analyse fonctionnelle ou d’architecture technique.

J’aurais trouvé logique à ce moment de la soirée, d’entendre les keywords PDCA ou rétrospective (puisqu’on a quand même debriefé à chaque itération).

Conclusion

Et le mot de la fin (mais qui suis-je pour décider que c’est la fin ?) : Est arrivé sur le tapis la relation avec le côté féminin, plus sensible, moins directif (je me contente de citer)… C’est dingue, car cela est également arrivé sur le tapis la semaine dernière lors de la formation Management 3.0…

Au delà de la vocation initiale de l’atelier, je me dis qu’on pourrait le détourner pour mettre en évidence nos déviances, notre tendance à la complexification. En fin de chaque itération, pendant le debriefing, on pourrait se focaliser sur les extrapolations que l’on a fait et qui nous ont conduites à l’échec, du moins à la non performance :

• Pourquoi une couleur par personne au lieu de une personne avec toutes les couleurs ?
• Pourquoi une alternance de couleurs au lieu d’une unique couleur ?
• …

Vous pourrez trouver d’autres idées d’atelier dans l’un de mes précédents post :
Apprendre, Jouer, Innover et faire des erreurs : L’oeuf, la poule… Le têtard… Et la mutation !

En tout cas, je sors de cette soirée avec deux nouvelles connaissances, et une croyance : il est possible de faire une formation agile qu’avec des Lego (après tout il y a bien Serious Play)… Je vais m’y atteler !…

Merci à tous, et notamment à Oliver Wagner qui s’est mis en risque puisqu’il nous a avoué jouer cet atelier pour la première fois.

PS: J’ai bien aimé l’astuce d’Oliver pour les slides. Il a imprimé ses quelques slides sur des pages A3 qu’il a scotchées les unes sur les autres (un bout de scotch sur l’arrête d’en haut, les premières slides sur le dessus). Ainsi, à mesure qu’il parle et qu’il parcours ses slides il récole la slide courante pour passer à la suivante. Simple et ré-utilisable. Bref, agile ;)

Je me réveille tout doucement ce matin, dans un hôtel à Avignon… Avant d’aller faire un tour au Palais des Papes, je me sens tout bizarre, un peu groggy… Mais qu’ai je donc fait ces dernières 48 heures ?!..

Un puissant outil de rétrospective, que j’affectionne tout particulièrement pour se souvenir et partager, est le totem… Pour la seconde année, je déplore que nous n’ayons pas de totem, alors je me bouge…

Si je devais apporter un totem pour ces 2 jours…

Ca ne pourrait pas être Le Palais des Papes, tout d’abord parce que j’ai peur de déchirer ma poche, mais aussi parce que la conf semble se vouloir itinérante. En tout cas, cette année, l’hôtel dans les salles, et le tout à Avignon c’était top.

Si c’était une chose, se serait… Bernard, euh non… Le post-it est pas mal, mais facile. La carte à jouer aussi. Peut-être la brique Légo : cette brique qui permet de faire pas mal de choses, en assemblant / desassemblant, tout en jouant… Mais je vais choisir la patte-à-fixe : on peut prendre une grande barre de PaF, la découper en plusieurs petits morceaux, l’éparpiller selon notre volonté dans différentes salles pour coller… Décoller… Recoller ailleurs. Décoller… Puis rassembler différents petits morceaux pour en faire un plus grand… Et finalement, on peut complètement détourner cette fonction initiale pour jouer via une bonne bataille de boule de PaF ;)

Si c’était un jeu, se serait… Bernard, euh non Le Bullshit Bingo, ou comment casser notre métier, ou plus exactement notre rôle de consultant. Après il faut supporter Claude crier Bingo toutes les 3 minutes ;)) Non, j’ai encore mieux: la Crevasse… Car finalement avec peu de choses, un peu de scotch et environ 34,5 mètres linéaire d’humain, on arrive rapidement à démontrer nos limites, donc le dépassement de soi basé sur la confiance (pardon, pour montrer que j’ai bien compris, il faut dire LES 3 confiances ;). Et pas besoin d’être un grand gaillard de 2m / 90 kg pour se dépasser… Pas vrai Laurence ;) Magnifique démonstration : un simple trou permet de mettre en relief de quoi est capable l’être humain. Faudrait que je pense à toujours emporter un trou.
Le bingo, la crevasse, ça fait beaucoup pour un seul homme… Et il en rajoute en se mettant à l’horizontal appuyé sur un mur… Ca doit être l’abondance d’oxygène qu’il y a à nos basses altitudes : il ne doit plus être habitué ;) Merci Olivier

Si c’était un animal, se serait… Bernard, euh non, la licorne, forcément. Je savais déjà de l’année dernière que la licorne couine, et j’ai appris cette année qu’elle porte des chaussettes… La licorne, car elle apparait quand nous sommes dans cet état un peu second dans lequel on est le soir une fois toute cette énergie retombée, un peu dans le gaz, un mélange d’état digestif après un lourd repas et de fatigue profonde après un triathlon (faudrait que j’en fasse un un jour ;). La licorne aussi parce que, 60 adultes, qui se réunissent pendant 2 jours à 700 km de chez eux pour faire ‘mumuse’, c’est forcément des animaux imaginaires… Ils ne peuvent pas vraiment exister ?!… Mais… Mais… alors tout ceci n’était qu’un rêve ?!

Et si c’était un humain, ça ne pourrait pas être Bernard :)…
Ca pourrait être Alex, mais j’y revient.
Ca pourrait être Guillaume Tell ;)
Ca pourrait être Gaëlle, ces gens un peu borderline à l’agilité qui font l’effort de rejoindre La Communauté de la Licorne.
Ca pourrait être Alexis, qui a le courage de se lever devant tout le monde pour lancer les choses, mais aussi la sagesse de savoir se rassoir pour laisser les autres s’exprimer.
Ca pourrait être Caroline et Emilie, qui ne carburent pas aux même substances illicites que nous.
Ca pourrait être Gilles… Gilles est complexe. Gilles est mystère. Schizophrène d’abord : il y a le Gilles qui tweet une idée de jeu le matin, et le Gilles qui vient à la conf mais qui ne connait plus ce même jeu. Et puis Gilles a avec lui un exemplaire de chaque jeu qui existe. Vous voulez un jeu, Gilles l’a sur lui. Je me suis d’abord dit, “ok : Gilles ne se déplace jamais sans ses 17 semi-remorques, comme Johnny en tournée”… Mais non, Gilles est venu en train ! Donc, la réponse est limpide : Gilles a volé le sac jaune de Sport Billy.
Ca pourrait être Alfred… Alfred, comment dire… Comme de la confiture… Non pas celle qui s’étale partout, collante et désagréable, mais ce pot ouvert de confiture fruitée et sucrée, disponible à ce que l’on vienne y plonger notre cuillère (a)vide de savoir… Comme, également, le petit lapin Duracell, qui continu à grimper l’Everest quand les autres en sont encore à essayer de traverser le Pont d’Avignon… D’ailleurs, nous sommes plusieurs à suspecter qu’il fonctionne encore même si on lui enlève ses piles. Pour ma part je suis persuadé qu’il a volé le secret de la technologie ARK à Tony Stark. Aux dernières nouvelles, il était en train d’animer un atelier sur les Mocks à quelques participants inanimés et enchainés dans le hall d’un hôtel Kyriad à Avignon… Je me demande si ensuite il a réquisitionné les voyageurs du TGV Avignon / Lyon ;)) Ca pourrait donc être Alfred… D’un autre côté, avoir un petit Alfred en mousse chez soit sur son bureau, ça serait louche.

Une autre technique agile est la métaphore.
Cette (a)conférence est pour moi comme une explosion : de jeux, de bonheur, de bonne humeur, de rencontres, de discussions, de découvertes, d’énergie… Organisée en à peine quelques semaines.
Mais pour qu’une combustion ait lieu, il faut :

1. Le carburant : cette profusion de jeux, et pas mal de re/nouveau. Cool.
2. Le comburant : nous, ces Licornes imaginaires, sans qui les jeux ne pourraient bruler
3. L’apport d’énergie initial : Alex, cette étincelle, ce feu follet ;), qui a lancé cette idée folle il y a deux ans, qui a relancé la conf cette année, et qui a su proposer de bonnes actions aux bons moments pendant ces deux jours (une rétro à 14h avant la fin… N’importe quoi… A moins que faire cela avant que les gens partent au compte gouttes… Pas con ;)
4. Mettre ces 3 éléments au même moment au même endroit : l’organisation. Merci aux éléments moteurs de l’auto organisation, ceux qui ont géré la mise en place sur Avignon, ceux qui ont fait que cela se passe bien tout au long des 2 jours, ceux qui ont pris la parole spontanément devant les autres pour que l’on avance, ceux qui ont animé des jeux, ceux qui se sont mis en risque pour les autres en rejouant des jeux qu’ils ont découvert quelques temps auparavant…

Le défit maintenant : transformer ces explosion en moteur à combustion, un enchainement d’explosions à intervalle régulier.
Une façon de clore une rétro est d’interpeler l’autre on le remerciant pour un fait. Donc merci à vous pour tout ceci.
Maintenant que c’est fait, passons aux choses sérieuse : où et quand pour la prochaine ?

Bonne digestion à tous, et surtout : restons joyeux !

j.
Membre de la Communauté de la Licorne

PS: Voir aussi le compte rendu du Petit Alfred en Mousse qui pointe vers d’autres compte rendus.

Extraire le fichier symboles à la livraison

Afin d’avoir les symboles dans un fichier de log de crash depuis n’importe quel poste (pas seulement celui de la personne qui a livré le binaire), il faut le fichier symbole, ce qui implique les étapes suivantes :

1. Clic droit sur l’archive depuis l’Organizer xCode, onglet Archives (voir screenshot)
2. Puis “Afficher dans finder”
3. Puis “Afficher le contenu du paquet”
4. Il s’agit du fichier dans le répertoire dSYMs

Obtenir les fichiers de log des crash

Une fois que vous avez synchronisé votre device via iTunes, l’emplacement  sur votre ordinateur des fichiers de crash log dépend de l’OS :

• Sur Mac ils sont ~/Library/Logs/CrashReporter/MobileDevice/<DEVICE_NAME>
• Sur Windows c’est dans C:\Users\<USERNAME>\AppData\Roaming\Apple computer\Logs\CrashReporter/MobileDevice/<DEVICE_NAME>

Utilisation du fichier

Lorsque vous récupérez un fichier de log, pour faire apparaitre les symboles (rendre “lisible” le fichier), il faut le fichier de symbole correspondant à la version de l’application (qui a généré le log).

Un double clic sur le fichier symbole devrait suffire…

Il s’agit d’un groupe naissant qui se rencontre une fois par mois à Genève en soirée pour mettre en oeuvre des (Non Video) Serious Games…

Et pour cette première, nous avons déroulé une Product Box, afin de donner un aperçu de la formation que je vais animer avec Alexandre BOUTIN (AgileToYou.com) le 29 juin prochain à Genève.
Un franc succès semble-t-il : voir le compte rendu avec les vidéos.

J’ai eu l’idée de créer ce groupe après la formation de Management 3.0 que j’ai suivie il y a quelques semaines grâce à Francois BEAUREGARD de Pyxis. Il y avait des ateliers qui n’étaient pas uniquement agiles. Et ma participation à la première conférence Agile Games France à Nantes quelques jours plus tard a fini de me convaincre, tant par ses ateliers agiles que ceux plus personnels souvent poussés par des coaches non agiles.

Mon envie de découvrir et pratiquer des Serious Games est tant motivée par une volonté personnelle et mon goût pour les jeux, que par le souhait de connaitre d’avantage de jeux et donc d’outils pour animer (au sens propre comme au sens figuré) les formations agiles que je donne.
Je suis pressé d’être au mois prochain.

Les Innovations Games sont pour vous : http://innovationgames.com

Il s’agit d’un ensemble d’ateliers, dans la lignée des Serious Games, formalisés par Luke Hohmann dans son livre éponyme, qui ont pour vocation de générer du feedback sur un produit ou un service en jouant le rôle des utilisateurs ou consommateurs.

Avec la collaboration d’Alexandre Boutin (agiletoyou.com), certifié par Luke Hohmann, nous animerons une formation d’une journée le vendredi 29 juin à Genève.
Si le sujet vous passionne, inscrivez-vous : http://inagua.ch/formations/innovation-games-geneve-2012/

Si vous êtes intéressés mais avez des doutes, vous pouvez toujours venir lundi prochain (4 juin) à la soirée du groupe Serious G@GE : SeriousGage.ch
Ce groupe gratuit, naissant, a pour vocation de réunir une fois par mois des personnes intéressées par la thématique des serious games.
La séance de lancement, lundi prochain, sera “comme par hasard” sur la Product Box, l’un des Innovation Games.

Nous espérons vous avoir convaincus que cet atelier ne nécessite aucune compétence particulière, et encore moins dans le développement logiciel.

Erreur ! Il m’a fallu 1h50 et 9 lignes de commande pour mettre en place mon environnement de développement Rails professionnel, créer mon application et la déployer sur une plateforme professionnelle : Heroku.

Un véritable exploit, quand on sait qu’il m’a fallu plusieurs jours pour faire un tutoriel Java EE… Exploit dû d’avantage aux technologies, plutôt qu’à moi… Hélas ;)

L’environnement de développement

• Installation de RVM (Ruby Version Manager) pour gérer différentes versions de Ruby… Pour cela je me suis inspiré de l’article de stéphane, que j’ai mis à jour via un comment :
• (1) curl -L get.rvm.io | bash -s stable
• (2) source /Users/jacques/.rvm/scripts/rvm
• Installer la dernière version de ruby :
• (3) rvm install 1.9.3
• Puis installer rails :
• (4) sudo gem install rails
• J’ai ensuite créé un repository sur Github.com, la plateforme communautaire hébergeant Git un gestionnaire de version (comme SVN) mais distribué.

Création de l’application

• Après avoir récupéré en local le projet vide depuis le repository Github via
• (5) git clone git@github.com:<username>/myApp
• J’ai créé le squelette de mon application Rails via la commande dédiée en commençant à suivre le tutoriel Heroku sur les applications Rails :
• (6) rails new myApp
• J’ai ensuite “poussé” ce squelette sur le repositroy :
• (7) git commit -am "myApp bootstrap"

Déploiement de l’application via Heroku

• Si c’est pas déjà fait, se créer un compte (gratuitement) sur http://heroku.com
• J’ai configuré mon application pour être compatible avec Heroku :
• (8) heroku create --stack cedar
• J’ai poussé l’application en production, à savoir sur la plateforme Heroku :
• (9) git push heroku master
• Cela créé une instance de mon application sur Heroku avec un NOM_BARBARE généré automatiquement… Mon application est alors immédiatement accessible sur l’Internet Mondial via l’URL : http://NOM_BARBARE.herokuapp.com

Aller plus loin

Heroku

Cette plateforme vous permet donc, en collaboration avec Github, de mettre en oeuvre une application web professionnelle, robuste et scallable.

Mais vous allez me dire qu’une URL de la forme http://NOM_BARBARE.herokuapp.com ne fait pas très pro… Je vous l’accorde. Il vous suffit alors de vous connecter sur votre compte Heroku, d’aller sur l’onglet My Apps, de selectionner la bonne application, de saisir le nom que vous souhaitez “myFabulousApp” et puis valider ! Ca y est, votre application est disponible à l’URL http://myFabulousApp.herokuapp.com. Et si cela ne vous suffit toujours pas, vous pourrez paramétrer Heroku pour que votre application soit accessible via votre domaine http://myFabulousApp.com.

De plus, avec le temps, Heroku offre une compatibilité à de plus en plus de technologies : Deploy an application

IDE Rails

Etant un amoureux de l’IDE IDEA IntelliJ, je ne peux que recommander RubyMine, avec les deux remarques suivantes :

• Bien que j’assume pleinement ce choix, et que je reste intimement convaincu qu’il n’y a pas mieux, il n’en reste pas moins polémique : d’autres recommandent un bon viex TextMate… Mais comment peut-on encore développer dans un outil qui ne supporte même pas les refactoring, surtout avec un langage à typage dynamique comme Ruby et Rails ???
• RubyMine est payant, quelques dizaines de dolars… Mais ça les vaut largement. D’ailleurs la version d’évaluation gratuite pendant 30 jours vous le prouvera (c’est comme si on vous offrait votre première dose de drogue dure ;). Et puis il y a des possibilités pour ne pas payer sur la page RubyMine Pricing.

Conclusion

Bref, plutôt expiditif comme mise en production… Et pourtant avec une robustesse qui répond tout à fait à des besoins entreprise.80% du temps passé, est du aux téléchargements d’installation (RVM, Ruby, Rails puis IDEA RubyMine)…Ah, une dernière chose : tout cela pour 0 francs… Ou euros… Ah si, 7,40 francs, à savoir le prix d’un Frapuccino car j’ai fait cela depuis une enseigne de café ricain bien connue, avec vu sur le Léman.

I’ve just come across dash.
(free in mac app store :  http://itunes.apple.com/us/app/dash-docs-snippets/id458034879?mt=12)
And I thought you might like it.

It’s a snippet manager and an API documentation browser for Mac Os X.
Access to documentation is really fast ;-) (a nice improvement from integrated documentation browser inside XCode.)
As I use different languages (ruby, Objective-C, javascript), I find this unified interface handy.

Snippets can be created and shared (via a dropbox folder) inside a team.
(They will appear as search results)

Here is what it looks like :

iPhone/iPod Touch: application executable is missing a required architecture. At least one of the following architecture(s) must be present: armv6

As it doesn’t seem to be an isolated issue trivial to solve, I’d like to share how to we managed to fix it. We found the good hint in a comment of this post. On the setting Project -> Build Settings -> Architectures -> Release, we selected “Other…” and we removed $(ARCHS_STANDARD_32_BIT), and we added two values: first “armv6” and second “armv7“. The project settings were like this:

Making the changes at project level propagates the value in the corresponding target:

I hope this can help other people facing the same issue.

Did it work for you? Did you find another solution? Do please share it in the comments. Thanks!