Software Freethinker

RSS

Note de lecture : The C++ Answer Book, par Tony L. Hansen

Note : 6 ; Un compagnon de route au Stroustrup.

Il s’agit, comme son titre l’annonce d’un livre d’exercices corrigés. Aujourd’hui c’est un texte fort ancien. Ancien peut-être, mais volumineux, certainement. On en prend pour 520 pages sur 8 chapitres seulement, sans compter les annexes ! Voyons ce qu’il a dans le ventre.
On passera rapidement sur le 1er chapitre qui est introductif (5 pages) pour nous tourner vers le 2nd qui traite des déclarations et des constantes. Les exercices sont tous très simples, c’est aussi l’occasion d’évoquer des éléments connexes à la questions en plus de répondre à celle-ci.

Si le chapitre 2 ne comptait qu’une trentaine de pages, c’est près de cinquante que nous offre le chapitre 3 dédié aux expressions. On y a droit inévitablement aux ordres d’évaluation de expressions, mais aussi aux comportements « limite » du langage, y compris à ceux causant des problèmes de portabilité. Une partie significative du chapitre est dédié à la manipulation de chaine de caractères, à l’ancienne façon « C ». Le niveau de difficulté augmente significativement, il était au maximum à 1.5 au chapitre 1, il monte ici à 2.5 selon l’échelle exponentielle de l’auteur ! La dimension algorithmique des exercices n’est pas triviale. De quoi se rafraichir les neurones !

Au chapitre 4, on évoque les fonctions et les fichiers. Du moins c’est ce que dit le titre. 60 pages sont consacrées à cette partie qui, en fait a surtout trait à la manipulation de structures : listes, graphes ou tableaux bi-dimensionnels avec les inévitables tris et manipulation. On parle en fait assez peu de fichiers et si on évoque les différences entre C et C++, cela reste du code à affinité C. Bien sûr, le niveau de difficulté augmente sensiblement et culmine à 3.

Le chapitre 5 marque notre véritable entrée dans le C++ car il y est question de classes ! Transition en douceur, car les premiers exercices font suite au chapitre précédent et l’on commence par faire des classes avec des struct ! D’un point de vue utilisation du langage, les 80 pages de ce chapitre restent dans la simplicité. Finalement on travaille surtout à encapsuler la complexité algorithmique dans des classes, ce qui n’est pas si mal. D’un point de vue conception, l’exercice le plus complexe est l’implémentation d’un interpréteur d’expressions à l’aide d’un pattern composite (l’un de mes exercices préféré).

Afficher davantage

Innover, ce n’est pas avoir une nouvelle idée mais arrêter d’avoir une vieille idée.

-

Edwin Herbert Land

image

En Finir avec le Planning meeting ?

Je vous avais laissé sur la remise en cause des estimations. Natrellement, le sujet suivant ce dvait être le planning meeting. Nous allons nous y attaquer aujourd’hui !

Autopsie du planning meeting

Le planning meeting de Scrum, c’est une composante importante de la démarche, du moins dans le Scrum Su (). De là découle tout ce qui sera fait durant le sprint. Aussi intéressons-nous à ce qui le constitue.
Tel que décrit initialement, le planing meeting comporte 2 parties, c’est donc en fait 2 meetings en un seul [1] :

  • Une présentation des fonctionnalités souhaitées pour le prochain sprint
  • Une planification de l’execution de ces fonctionnalités pour la durée du sprint

Les textes ultérieurs ont ajouté un peu de détail, comme la présentation de l’objectif de sprint et la détermination de la capacité de travail [2]

image

Au fait, quelle est la durée de ce meeting ? Ken Schwaber nous parle d’une durée de 8 heures pour un sprint de 30 jours ! Personnellement, un tel marathon dépasse mes forces et de très loin. Heureusement, bien que les créateurs de Scrum clament la même durée de Sprint depuis 20 ans, je ne connais personne planifiant des sprints aussi long. Mais même ramené au pro-rata à 2 semaines, une durée de 4 heures me semble excessive !

Hélas, il n’y a pas que la durée qui ne va pas. Ce serait même plutôt le moindre de nos soucis. Commençons donc notre travail de dépeçage.

Afficher davantage

Note de lecture : High-Speed Windows Applications, par Bruce E. Krell

Note : 2 ; Beaucoup de lourdeurs et de formalisme, mais peu d’idées intéressantes.

Ce livre traite de la gestion multitâche sous Windows 3.1, donc en s’appuyant sur les messages Windows. On en prend pour plutôt cher : un peu plus de 330 pages hors annexes. Celles-ci sont elle-même volumineuses : 130 pages ! L’approche pédagogique est pour le moins sujette à caution, le formalisme est lourd et guindé. Le titre de section de la page 7 est assez symptomatique : « Turn off your PC ! ». Mais voyons ce que ce volume a dans le ventre. En l’occurrence, ses entrailles sont divisées en 10 chapitres.

Le premier chapitre se compose d’une douzaine de pages pour décrire l’approche générale de la méthode (car en fait, c’est une méthode). On a vite compris que l’on va s’appuyer sur les message Windows centré sur la logique utilisateur.

Le chapitre 2 est aussi une introduction, mais cette fois au SDK. C’est très descriptif et donc assez abstrait. Je ne pense pas que j’aurais pu aborder la programmation Windows avec ça (merci Charles Petzold !). Les exemples de code des fameux « WinMain » et « WndProc » n’aident guère.

Ca y est, au chapitre 3, l’auteur peut commencer à développer sa notation et son approche complètement démente. J’ai l’impression de me retrouver en plein SADT : l’horreur !

Les chapitres 4 et 5 sont dévolus à l’application au « Windows High Speed Application ». On a toujours cette emphase méthodologique qui obscurcit terriblement le propos. J’ai l’impression qu’il y a une idée d’architecture derrière. Mais le fil est ténu et masqué par la prose idéologique. Pardon, méthodologique. On parle bien de « master control task » et « master scheduler task », mais impossible de comprendre à quoi ils ressemblent.

Afficher davantage

Your quote here.

-

Bjarne Stroustrup in The C++ Language (about templates)

image

Agile Playground #15

Un conflit d’agenda m’a fait raté le 14ème rendez-vous, c’était donc une bonne surprise de voir un Agile Playground programmé en cette première quinzaine de Juillet, alors que je croyais nos rendez-vous interrompus jusqu’en Septembre !

image

Au programme de cette soirée, un ice-breaker sans prétention mais amusant proposé par Frank Beulé et une traditionnelle expérimentation de jeu.

Afficher davantage

Note de lecture : Le génie logiciel orienté objet, par Ivar Jacobson, Magnus Christerson, Patrik Jonsson & Gunnar Övergaard

Note : 3 ; Trop théorique et trop volumineux

Voici un livre qui traite vraiment de méthodologie. Jacobson est le créateur des use cases, il était donc logique que son livre se focalise sur l’analyse. Au delà de ceci, il traite bien entendu des aspects processus et conception, cependant son propos reste souvent de très haut niveau. Mais voyons plus précisément ce que recèle l’ouvrage. Tout d’abord, il est volumineux, avec plus de 500 pages sur 16 chapitres regroupés en 3 parties.

La première partie traite des concepts objet. On en prend pour 5 chapitres sur 110 pages. Le premier chapitre est représentatif du livre : de bons vieux concepts « industriels », avec un processus en phase et une grande croyance dans la réutilisation sortie des cartons… Le second chapitre est une variation de celui-ci et ne nous apprend pas grand chose. C’est avec le chapitre 3 que l’on aborde l’orientation objet. Une vue très conceptuelle et analyse de l’objet, qui fait écho à ce qui est développé dans OMT (mais sans être aussi bien formalisé). Le chapitre 4 est le prolongement « conception » de ce chapitre. J’avoue avoir du mal à distinguer en quoi il apporte quelque chose au propos. En toute logique, le 5ème chapitre traite de l’implémentation orientée objet. C’est une nouvelle illustration de l’incapacité des ouvrages méthodologiques de cette époque de traiter décemment d’implémentation !

La seconde partie parle des « concepts », c’est à dire en fait des grands domaines d’ingénierie. Ce sont 7 chapitres qui constituent cette partie, la plus longue du livre avec près de 240 pages. Et l’on commence par évoquer l’architecture. En fait d’architecture, les auteurs développent plutôt une représentation en vues du système, ce qui permet d’introduire chemin faisant les cas d’utilisation. Mais tout ceci est bien abstrait. C’est de modèle d’analyse qu’il est ensuite question, en quelque sorte une reprise des chapitres 3 et 4. Puis c’est au tour de la « construction ». Pas plus que le chapitre 5, celui-ci n’est convainquant. Mais c’est l’occasion de présenter quelques diagrammes : diagramme d’interaction, d’activité et d’état-transition. Les auteurs tentent aussi de décliner quelques spécialisations , comme le temps réel avec un focus particulier sur les stimuli et la communication entre objets. On s’occupe également des bases de données, sujet mal traité qui semblait plutôt facile à aborder pourtant. On parle aussi de composants, on en parle toujours. Et c’est toujours aussi peu convainquant. Viennent finalement les tests, dont on se dit que le chapitre ne sert qu’à occuper le terrain…

Afficher davantage

Success is not final, failure is not fatal: it is the courage to continue that counts.

-

Winston Churchill

image

What to do when Scrum doesn’t works

Et d’abord, c’est quoi Scrum ?

Oui, je sais, on peut faire référence au Scrum Guide et à toute ces sortes de choses, mais pour Henrik Kniberg, ce sont :

  • De petits morceaux de fonctionnalités
  • Des équipes subdivisées en petites équipes
  • De petites tranches de temps.
  • Une valeur métier optimisée
  • Avec un processus optimisé !

Et c’est tout !

Pourtant, visiblement, tout ça peut mal se passer. Voyons comment et comment y remédier. Avec 5 cas de figure.

Mal utiliser le processus

S’en prendre à Scrum alors qu’il faudrait plutôt penser à notre façon de l’utiliser est le premier symptôme. Le grand classique est le temps consacré aux cérémonies : s’il est exagérément long, il s’agit simplement d’un avertissement, nous essayons de pratiquer Scrum comme une méthode classique !

Afficher davantage

Note de lecture : La bibliothèque standard STL du C++ - Alain-Bernard Fontaine - InterEditions 1997 - ISBN : 2-7296-0657-2

Note : 0 ; A éviter à tout prix !

Si vous cherchez dans cette sélection un livre à éviter à tout prix, vous venez de le trouver. L’auteur est probablement un bon programmeur, d’ailleurs il nous vomit des pages de code pour expliquer des choses qui seraient mieux mises en valeur sur 4 ou 5 lignes, mais il est sans aucun doute un exécrable pédagogue. Sans compter que l’auteur semble imaginer que l’on utilise les STL que pour stocker des entiers ou des flottants : les exemples se cantonnent exclusivement à cela ! Les explications sont souvent confuses et incomplètes.

Le livre ne commence sérieusement qu’avec le chapitre 3. Les deux précédents nous ont surtout servi à appréhender la pauvreté de l’expression écrite que nous aurons à subir durant le reste de l’ouvrage. Donc ce chapitre 3 sert de base pour le reste du livre, bases qui sont sans connexion directe au sujet (l’auteur pense que nous sommes assez suicidaires pour nous servir de ce texte comme base de notre savoir en C++). On y évoque de manière décousue les templates, les exceptions et surtout la bibliothèque iostream. Le tout décousu à l’envie.

Le chapitre 4 est curieusement appelé « organisation de la librairie C++ : il s’agit d’un listing des headers de la librairie C++ et d’une pseudo-description sur 3 pages de la classe string, avec un magnifique diagramme de Booch dont les éléments sont positionnés avec une précision d’un demi-centimètre !

Le chapitre 5 nous parle de gestion mémoire et des classes l’implémentant dans la librairie C++. Le propos tourne autour des modèles mémoire de Windows (car le livre évoque beaucoup Visual C++ 4.2) et les auto_ptr de la librairie qui ne sont pas utilisables avec la STL. Tout cela n’a donc aucun intérêt par rapport à la STL. Passons.

Afficher davantage

It is said that power corrupts, but actually it’s more true that power attracts the corruptible.
the sane are usually attracted by other things than power.

-

David Brin

image

Lean Agile Camp, saison 2

Le premier opus du Lean Agile Camp s’était déroulé en novembre dernier, une période peu propice pour moi et j’avais abdiqué. Pas question de rater celle-ci par, contre : programmée début Juillet, il n’y avait guère de conflit de dates à l’horizon.

Quand on veut parler de Lean sérieusement, on a de bonne chance que Régis Médina ou Antoine Contal ne soient pas loin. Nous avons eu la chance de bénéficier de l’expertise des deux !

image

Au programme de cette journée, des dojo pour aborder 3 sujets :

  • La compréhension du client
  • Le management visuel
  • La résolution de problème

Afficher davantage

Note de lecture : Swing (Les cahiers du programmeur), par Emmanuel Puybaret

Note : 4 ; Pédagogique mais trop pesant.

Cette série Eyrolles est sensée être dédiée à des ouvrages permettant de monter en compétence sur des sujets. Dans les faits, on en prend pour 500 pages. Peut-être l’auteur a-t-il été trop gourmand en essayant d’avaler de nombreux sujets ? On va voir ça !

De prime abord, le texte est découpé en 12 chapitres. Mathématiquement, cela va donner de gros chapitres, donc un découpage « à la française ». Le concept global du livre est de mener une étude de cas en mode projet, avec des itérations. Le tout à la façon extrême programming. Cela fait donc au moins 2 sujets à aborder. 3 si l’on compte le détour par SWT. Je ne compte pas toute la partie outil également aborder. Il est temps de commencer.

Le premier chapitre présente l’étude de cas : il s’agit d’un système de CAO. On évoque aussi l’approche XP (mal) qui sera utilisée et un bref exposé des cas d’utilisation (malgré que l’on soit avec XP où les user stories sont préférées). Bonne nouvelle, le tout est bouclé en 9 pages.

Il nous faut juste24 pages pour évoquer le setup de l’environnement. On s’étale trop sur Eclipse. Par contre expliquer l’usage d’une forge paraît une bonne idée, mais l’emploi de CVS est vraiment suranné tout comme l’absence de Maven (ou même de Ant). N’utilise-t-on pas d’intégration continue en Extreme Programming ?

Afficher davantage

The conventional army loses if it does not win. The guerrilla wins if he does not lose.

-

Henry Kissinger

image

Des Ressources Humaines au Capital Humain avec l’agilité

Tel que nous les vivons aujourd’hui, la gestion des ressources humaines et l’état d’esprit agile ne semblent pas fait pour se marier ensemble. Mais c’est bien de cela que nous a parlé Jas Chong lors de ce Meetup organisé par Agilebee. J’avais rencontré Jas Chong il y a peu, lors de l’open-space du Scrum Day.

Aujourd’hui c’est le retour d’expérience d’une transition qu’elle évoque avec nous.

image

Jas a passé pas mal de temps à nous camper le contexte. Pour ma part, je vais faire beaucoup plus court : il s’agit d’une transformation digitale dans le domaine du voyage. Une transformation qui passe par l’agilité et la rationalisation de l’organisation des développements à l’échelle internationnale ! C’est là que Jas intervient.

Afficher davantage

agiletourSpeakingAt
Agile Grenoble 2013 Speaker
Software Freethinker followers