Auteur : Karl Metivier

Idées, pensées et autres errances d'un architecte logiciel et practicien agile.

Le cerveau divisé

Je m’intéresse beaucoup à notre cerveau, comment il fonctionne, se souviens et comment il pense. J’ai eu quelques questionnements on regardant l’excellent vidéo (11min) de RSA Animate "The Divided Brain":

 

Je vous recommande fortement de l’écouter si le sujet vous intéresse. Avec le côté graphique qui suit le discours, c’est divertissant et instructif.

J’ai noté deux passages vers la fin qui je trouve important:

The Intuitive mind is a sacred gift and the rational mind is a faithful servant.
– Albert Einstein

But our society has forgotten the gift and have created a society that honors the servant.
-Iain McGilChrist (présentateur)

 

  • Est-ce qu’effectivement notre société met trop l’accent sur le côté rationnel de notre pensée ?
  • Est-ce que le fait de laisser côté en général notre côté intuitif résulte ainsi une baisse de créativité ?

Je pense comme le présentateur au fait que nous avons besoin des deux côtés pour bien fonctionner.  Des outils comme le Mind Map (schéma heuristique) et  la pensée visuelle sont importants devraient être enseignés et utilisés davantage.

Qu’en pensez-vous ?

Comme d’habitude, les commentaires sont les bienvenus.

Publicité

Agile Tour 2011: Un beau défi réalisé !

IMG_0282

Pour une troisième année consécutive, l’Agile Tour était de retour à Québec mercredi dernier, le 26 octobre. Je m’étonne toujours de la qualité du travail que l’on peut faire pour organiser cette conférence en dépit des circonstances. Par exemple, le fait que personne ne travaille à temps plein là-dessus. Tous les organisateurs ont déjà un premier travail.

Aussi, cette année c’est un peu spécial, car un de mes auteurs préférés de livre, Robert “Uncle Bob” C. Martin, était notre conférencier principal.

J’ai adoré sa présentation, “Clean Architecture”, qui était instructive et divertissante, comme d’habitude dans son cas.

En passant, voici les nouveautés que nous avons amenées cette année:

  • La conférence a lieu dans un hôtel au lieu de l’université Laval
  • Nous avons quatre de salles de conférences + une grande salle pour la conférence principale et les repas.
  • Les conférences sont divisées par thème et par salle afin d’en avoir pour tous les goûts chez nos participants.
  • Un comité de programme a été établi afin d’évaluer et de choisir les soumissions de conférences.
  • 18 sessions différentes, en plus de la conférence principale, étaient offertes aux participants.

Aussi, en tant qu’OSBL (organisme sans buts lucratifs), nous nous efforçons de rendre accessible cet événement au plus grand nombre possible de personnes. Nous avons eu aussi un nombre record de participants (400) et nous avons dû en refuser plusieurs pour cause de logistiques et d’espace dans les salles. L’engouement pour le développement Agile est vraiment en hausse à Québec cette année !

Certaines petites choses sont encore à améliorer, mais ce fut selon moi un très bon événement de grande qualité et pour un prix modique (50$). Ce qui concorde parfaitement avec la mission de la communauté Agile de Québec.

Un gros merci particulier à mes collègues pour qui la plupart c’était la première fois qu’ils organisaient un « Agile Tour » :

  • David Beaumier
  • Félix-Antoine Bourbonnais
  • Patrice Caron
  • Louis-Joseph Foujieu
  • Dave Jacques
  • Amélie Turgeon

Au plaisir de vous retrouver à l’Agile Tour 2012 !

Introduction à un Code Retreat par Corey Haines

Voici l’introduction d’un Code Retreat de Corey Haines que j’ai filmé lors de son passage au Code Retreat Québec 2011 en mai dernier.

J’ai téléchargé le tout sur YouTube en 3 parties pour ne pas perdre la qualité HD.:

Partie 1
Partie 2
Partie 3

Références :

Est-ce que votre code est S.O.L.I.D. ?

CrackDans ce billet, je vais vous décrire brièvement les principes SOLID pour la programmation orientée-objet avec quelques commentaires et vous suggérer quelques ressources pour approfondir ce sujet qui devrait être connu de tous les programmeurs sérieux et professionnels.

Je suis toujours surpris lorsque, la plupart du temps, à chaque fois que je parle de ces principes à de nouveaux collègues, mon interlocuteur hausse les épaules et ne sait pas de quoi je parle.

 

S.O.L.I.D. est acronyme regroupant les principes suivants:

  • Single Responsability Principle (SRP): Une classe devrait avoir une et une seul raison (responsabilité) d’être modifiée.
  • Open Closed Principle (OCP) : Chaque classe devrait être ouverte pour des extensions et fermé autant que possible pour des modifications.
  • Liskov Substitution Principle (LSK) : Les classes dérivées peuvent être substitué de leur classe de base
  • Interface Segregation Principle (ISP) : Nos classes ne doivent pas hériter, via une interface, de méthodes qu’elles n’utilisent pas.
  • Dependency Injection Principle (DIP) : On doit dépendre de classes abstraites et non de classes concrètes

De tous ces principes, le plus important à suivre selon moi est le Single Responsability Principle (SRP). Ne pas respecter ce principe peut apporter plusieurs maux, notamment lorsque l’on fait évoluer le code.  Dans mon équipe actuelle, nous avons fait du SRP le principe de base et le plus important à suivre. De cette manière nous l’avons toujours en tête et il nous sert en quelque sorte de règle de base lorsque l’on se questionne sur la grosseur de classes et de méthodes ou autre.

C’est important aussi de connaitre les autres, mais on y fait référence un peu moins souvent à mon avis.

Pour en savoir plus, sur SOLID, vous pouvez commencer par les deux références suivantes sur Internet :

Pour approfondir SOLID, je recommande fortement le livre suivant (Liens Amazon.ca commandités) de Bob Martin qui se décrit en deux versions, tout dépendant si vous êtes de type Java/C++ ou .Net:

Agile Software Development, Principles, Patterns, and Practices

Type .Net (C#/VB)

Type Java/C++

Dans ce livre, l’oncle Bob nous explique les pratiques agiles, on y voit un peu de modélisation et aussi de nombreux chapitres sont dédiés aux principes orientés-objet. Ce livre d’environ 700 pages fait un très beau livre de référence à mettre sur son bureau pour le lire au complet ou le consulter à l’occasion.

En passant, nous aurons la chance de recevoir Bob Martin en tant que conférencier principal lors de l’Agile Tour Québec 2011. Les inscriptions devraient commencer en septembre. Pour info sur l’Agile Tour : http://at2011.agiletour.org/fr/at2011_Quebec.html

Autres articles intéressants avec exemples d’application de SOLID:

Référence pour l’image utilisée:

http://www.sxc.hu/photo/954598

C’est quoi un Lean Startup ?

En gros, c’est un mélange de développement Lean et Agile avec une bonne dose d’entrepreneurship. Le but est d’éviter le plus possible de faire du gaspillage  et de livrer un produit innovateur avec succès. On y dénote les principes suivants:

  • Les entrepreneurs sont partout (Entrepreneurs are Everywhere)
  • L’entrepreneurship c’est aussi de la gestion (Entrepeneurship is Management)
  • L’Apprentissage est validé (Validated Learning)
  • L’innovation doit être comptabilisée (Innovation Accounting)
  • Construire-Mesurer-Apprendre (Build-Mesure-Learn)

Eric Ries est à l’origine de ce terme et il en parle depuis quelque temps. Je trouve sa démarche forte intéressante et cela m’a incité à me tenir informer sur ce sujet. En passant, le concept de Lean Startup peut aussi bien être appliqué à l’intérieur d’une compagnie existante que pour une entreprise en démarrage. Pour en savoir davantage sur Eric Ries, je vous recommande le vidéo suivant d’une de ses conférences qu’il a données récemment :

 

D’ailleurs, son livre sur le Lean Startup sera publié en septembre. J’aime beaucoup le graphique suivant qui montre le cycle de développement dans un Lean Startup:

25255_387440405880_387431575880_4176788_6681867_n (1)

On peut aussi se poser la question suivante, en quoi le Lean Startup est différent du développement Agile ? Le tableau suivant  de Joshua Kerievsky résume fort bien les différences et les similitudes entre le développement Agile et le Lean Startup:

Agile Lean Startup
Product Roadmap Business Model Canvas
Product Vision Product Market Fit
Release Plan Minimal Viable Product
Sprint Kanban
Sprint Review Pivot or Persevere Decision
On-Site Customer « Get Out Of The Building »
User Story Hypothesis
Backlog « To Learn » List
Definition of Done Validated Learning
Red-Green-Refactor Learn-Measure-Build
Customer Feedback Customer Validation
Acceptance Test Split Test
Velocity AARRR
Mock Object Feature Fake
Continuous Integration Continuous Deployment
Certified Scrum Master Customer Success Manager

 

Est-ce que vous pensez que ce genre de modèle peut réussir ici au Québec ?

Est-ce qu’il y a vraiment des entrepreneurs un peu partout ici ou c’est seulement réservé à nos voisins du sud ?

Est-ce que vous connaissez des exemples de compagnies d’ici qui ont appliqué ce modèle ?

 

Références:

La place des Business Objects dans le MVP

Où doit-on placer nos composants d’affaires (i.e Business Objects) lorsque l’on utilise les designs patterns du genre Model-View-Presenter (MVP) ou Model-View-Controller (MVC) ?

C’est une bonne question et  je la retrouve régulièrement dans les projets auxquels j’ai travaillé.

Mais avant de poursuivre, voici une conversation forte intéressante que j’ai observée sur twitter il y a quelque temps entre Robert « Uncle Bob » Martin et Martin Fowler à ce sujet:

Image@unclebobmartin Views should have no knowledge of business objects. Presenters should create data structures from business objects & views should use them.
Image@martinfowler @unclebobmartin disgree. It’s both traditional and effective for views to see domain objects
Image(1)@RonJeffries @unclebobmartin i’d wanna see one or more examples showing why views shouldn’t see domain objects but instead … what, « views « of them?
Image@unclebobmartin @martinfowler The problem is that views become coupled to business logic. Changes to BOs imply changes to views.
Image@martinfowler @unclebobmartin I think the relationships between view, model and other elements is too context-specific for a general rule
Image(2)@GBGames @unclebobmartin @martinfowler To be clear, I know MVC, but it seems there’s debate about what the V knows about the M?
Image[4]@martinfowler @GBGames @unclebobmartin There are many forms of MVC with different trade-offs. I said more at http://martinfowler.com/eaaDev/uiArchs.html
Image@unclebobmartin @peter_bugge BOs change for reasons of business logic. Views need not be affected.
Image@unclebobmartin @sebasmonia A change to the BO will often cause change to presentation logic, but hopefully not to the views.
Image@unclebobmartin An object has private state and public methods. A data structure has public data and no methods. Getters and setters make data public.
Image@unclebobmartin @MahasenBandara Views are concrete. Models are abstract. Views should depend on Models.
Image@unclebobmartin Business interactions are also business objects. Controllers should invoke interactions not _be_ interactions.
…

En résumé, Uncle Bob mentionne que pour éviter le couplage, le presenter devrait se refaire de nouveaux objets et les passer à la vue. Martin Fowler nuance un peu le tout en mentionnant que ce n’est pas vrai tout le temps et que cela dépend du contexte.

Le fait de se refaire de nouveaux objets pour la vue peut amener certains problèmes. Exemple, j’ai vu très souvent ce genre de code qui, pour moi, est un beau cas de duplication:

 public ViewObject ConvertObject(BusinessObject objectFromModel)
        {
            var viewObject = new ViewObject() ;
            viewObject.Name = objectFromModel.Name;
            viewObject.Adress = objectFromModel.Adress;
            viewObject.PhoneNumber = objectFromModel.PhoneNumber;
            viewObject.City = objectFromModel.City;

            return viewObject;
        }
    }

Hmm, redondant n’est-ca pas ?

Si les objets sont pratiquement semblables, je suis d’accord avec le point de Martin Fowler et que ce genre d’objets peut être visible au niveau de la vue.

Par contre, s’il y a quelques différences ou des champs non utiles qui sont tout de même transférés à la vue, je crois qu’il vaut mieux y aller avec de nouveaux objets comme le mentionne Uncle Bob.

Bref, la règle à suivre selon moi est de toujours voir selon les besoins du contexte.

Et vous, qu’est-ce que vous faites dans ce cas avec les Business Objects ?

Lectures à la plage

Lectures2011

J’aime bien me faire une nouvelle sélection de livre à lire pour l’été. Et ce, même si je mets de côté certains déjà entamés…

Et oui, c’est les vacances pour les lectures en cours aussi !

Donc, je vous présente ma sélection de lectures pour l’été:

Rework par Jason Fried et David Heinemeier Hanson: Livre des deux fondateurs de la compagnie 37signals. On y parle de comment ils ont bâtit leur compagnie en ne respectant pas les manières standards de faire. Très pragmatique et Lean dans leur approche, l’ouvrage semble intéressant à lire. C’est d’ailleurs David Heinemeier Hanson qui est derrière le framework web Ruby On Rails (RoR) qui a été utilisé pour bâtir un de leurs premiers produits: Basecamp. Ils ont fait par la suite de RoR un framework Open source.

Enchantment par Guy Kawasaki: J’aime bien cet ancien d’Apple et sa manière de présenter les choses. Quoi de mieux que de lire son dernier livre pour en apprendre davantage sur lui. On y parle ici de comment « charmer » les gens, de manière positive bien sûr, pour changer les choses, offrir ses services, vendre un produit, etc.

The Well Grounded Rubyist par David A. Black : Ayant récemment terminé un tutorial sur Ruby On Rails, je voulais poursuivre en apprenant davantage la base du langage Ruby. Ce livre semble bien fait pour cela. Par contre, je ne pense pas lire les quelques 500 pages pendant l’été. Passer à travers quelques chapitres serait déjà un bon pas d’effectué.

Et d’autres moins sérieuses pour se divertir, car c’est important aussi pendant les vacances. Étant un bon amateur de bandes dessinées ou Comics Books, voici ma sélection:

Dark Tower – The Gunslinger Born : J’ai toujours voulu lire la série « Dark Tower » de Stephen King. En voici l’occasion avec le premier volume de cette adaptation en bande dessinée qui me semble très bien réussi.

Justice League International: J’aime bien cette série des années 90 où l’humour est omniprésent chez un groupe international de super-héros. Hilarant.

Et vous, est-ce que vous avez des lectures particulières pour cet été ?

En passant, n’hésitez-pas à consulter mon profil et me suivre sur Goodreads:
http://www.goodreads.com/profile/karlmet

Critique du livre Linchpin

linchpinJ’ai vraiment hésité avant de lire ce livre. À chaque fois que je passais à la librairie pas loin de mon travail, je prenais le livre et je le feuilletais. Je regardais un peu les sections, le sujet de livre et j’hésitais. Un puis un jour, je me suis lancé et je l’ai acheté histoire afin d’en avoir le coeur net.

Je connaissais que vaguement l’auteur, Seth Godin, ayant lu auparavant quelques-uns de ces articles. Mais j’ai découvert en lisant ce livre un auteur passionnant et divertissant.

Bon, revenons au livre. Ce dernier parle de comment devenir un Linchpin. Un Linchpin ressemble à cela:

Mais on ne se sert que de l’analogie ici. C’est à dire devenir l’élément essentiel d’un rouage quelconque. L’idée central de ce livre est de donner des conseils et de la motivation pour être indispensable, sortir de l’ombre de la masse.

On y parle donc de notre société en général, d’éducation, d’initiative, d’innovation et de créer de l’art. L’auteur nous dresse ainsi un portait intéressant de notre vie de travail et du fait et qu’on peut toujours faire mieux et se dépasser.

Plusieurs anecdotes se retrouvent dans le livre et sont amusantes et inspirantes à lire.

On y retrouve les sections suivantes traduites librement:

  • Le nouveau monde du travail : On discute dans ce premier chapitre comment le travail à évoluer et que nous ne sommes plus à l’époque des usines et du travail répétitif.
  • Réfléchir à ses choix : Intéressante section qui parle des choix qui s’offre à nous et comme c’est bon de prendre des risques, d’être généreux et de vivre le nouveau rêve américain.
  • Indoctrination: Comment on est en rendu là ? L’auteur aborde ici les problèmes du système d’éducation et de la mentalité de travailleur d’usine qui y est parfois inculqué.
  • Devenir le Linchpin : La personne qui maintient le tout dans une entreprise est un Linchpin et le monde en a besoin de plusieurs. Il n’a pas peur d’amener de nouvelles idées et  à ce petit plus qui le distingue des autres.
  • Est-ce que c’est possible de faire du bon travail dans un cubicuble ?  Description du labeur émotionnel et comment ajouter de l’art dans notre travail
  • La Résistance : Probablement le chapitre le plus important. Notre cerveau détient toujours un peu de lézard dans sa composition. Ce dernier a pour objectif de nous faire survivre. De nos jours par contre, il nous guide à éviter à tout prix les erreurs et les menaces et à rechercher le confort. La résistance veut contrer ce lézard et plutôt nous faire réalisez des choses et apprendre de nos erreurs. Par exemple, on ne devrait pas avoir peur de parler en public afin d’expliquer nos idées. Pourtant, c’est épeurant pour bon nombre de personne.
  • La puissance pouvoir culturel des cadeaux : Donner un cadeau sans réciprocité; être généreux. On parle ici de rendre un service ou d’ajouter le petit quelque chose qui n’était pas demandé.
  • Il n’y a pas de carte : Faire son propre chemin sans se faire dire quoi faire tout le temps.
  • Faire un choix : Quelques exemples de Linchpin. Est-ce que l’on rentre dans les rangs ou on se démarque ?
  • La culture de la connexion : Un Linchpin ne peut réussir seul. Il se doit d’entretenir des connections sociales.
  • Les sept habilités d’un Linchpin : Liste de ce qui rend un Linchpin indispensables.
  • Quand cela ne fonctionne pas : On fait davantage d’art ou on donne des cadeaux.

Quelques passages intéressants tirés du livre:

New bargain: leverage talent and creativity and art more than obedience

Flexible in the face of change, resilient in the face of confusion

What they should teach in school ? Only two things: Solve interesting problem and Lead

Three words can kill an organization: « Not my job »

Bref, ce livre est un cadeau. Offrez-vous le ou à quelqu’un d’autre à qui cela pourrait intéresser car c’est un excellent livre.

Mes points clefs:

  • Il reste un peu de lézard dans notre cerveau. Apprenons à le dresser.
  • Combattre le Statu Quo est parfois nécessaire
  • Soyez créatif, oser, même si cela comporte des risques.

 

 

 

 

Références:

Mon expérience au Code Retreat

IMG_0040

Le 21 mai dernier, moi et deux autres collègues (Félix-Antoine Bourbonnais et Amélie Turgeon) avons organisé le premier Code Retreat à Québec. Tout cela a commencé en début février lorsque le nouveau conseil d’administration de la communauté Agile de Québec s’est réuni.

Lors d’un tour de table, il a été suggéré de tenter d’organiser cet événement. Je trouvais qu’il n’y avait pas assez d’événements de ce genre pour les programmeurs. En particulier des événements qui ne parlent pas de produit d’un vendeur ni d’une technologie particulière. Juste du code orienté-objet sans égards à un langage particulier.

Comme nous n’avions jamais fait ce genre d’événement, il nous fallait un facilitateur de calibre et qui en avait fait beaucoup auparavant: Corey Haines. Ce dernier habite Chicago  et le faire venir ici comporte certains frais, mais rien de trop astronomique. Donc, on s’est rendu compte que c’était possible de le faire venir. Dans notre planification, l’aide des commanditaires serait aussi importante et permettrait de définir le prix d’entrée, le lieu et la nourriture et les rafraichissements servis aux participants durant la journée.

Donc, au fil des mois tout s’est tranquillement mis en place pour réaliser l’événement qui fut un bon succès selon moi. Une grande majorité des participants ont apprécié. On a aussi pu noter certains aspects qui seront à améliorer la prochaine fois que l’on réalisera cet événement. Car nous avons bien l’attention d’en refaire un. Mais avec l’Agile Tour 2011 qui s’en vient cet automne, c’est bien possible que cela ait lieu qu’en 2012.

Aussi, organiser tout cela nous a permis de tester ou d’approfondir certaines technologies qui pourraient nous être utiles dans le futur :

  • WordPress: Nous avons fait un blogue pour contenir toute l’info de l’événement.
  • Eventbrite: Pour la gestion des inscriptions
  • Google Documents: Pour l’échange de documents entre les organisateurs
  • Survey Monkey: Définition et compilation des sondages d’appréciation de l’événement.

Au niveau du contenu de l’événement, j’ai aussi bien adoré. J’ai été surpris du nombre de personnes qui n’avaient jamais vraiment pratiqué le TDD avant. Mais c’est le but de ce genre d’événement, donner du temps pour pratiquer des techniques et langages qu’on n’a pas l’occasion de pratiquer au travail.  L’apport de Corey Haines a aussi été excellent. Cela nous guidera lors des prochains Code Retreat.  Car ce sera nous de jouer le rôle de facilitateurs la prochaine fois. J’ai bien aimé aussi mes différentes sessions de pairage. J’ai pu me remettre au C# (car je fais du VB.Net habituellement), voir un peu de Ruby à l’œuvre et appris quelques trucs ici et là. J’ai aussi montré l’outil Resharper à quelques-uns et du C# à un gars de Java. Bref, it was a blast !

En résumé, je suis bien content de voir qu’à partir d’une idée, et entouré de bonnes personnes, on peut voir un projet se réaliser. Il ne faut pas toujours avoir peur de commencer des choses, mais il faut plutôt oser le faire. On y découvre alors plein de choses…

Références :

Diète de l’information

MP900321066

J’aime bien lire un paquet de trucs sur différents sujets liés de près ou de loin au développement informatique. Par contre, je me rends bien compte qu’il y a beaucoup trop d’information disponible et je suis en train de subir un genre de  "information overload". Sans compter les moments pris à vérifier mes courriels, regarder twitter et mon nouveau iPhone4…

Inspiré des livres Focus et The 4-Hour Workweek(4HWW), j’ai décidé de faire une semaine de diète de l’information pour voir un peu ce que cela donne.

Je me sers de Google Reader pour lire les blogues que je suis. Il est pratique, car je peux les lire peu importe l’ordinateur que j’utiliser. Par contre, avec mes abonnements, j’ai environ billets 200-300 à voir chaque semaine:

image

C’est certain que je ne les lis pas tous. Seulement ceux d’intérêt. Par contre cela me prend de temps pour parcourir la liste. En révisant tous mes abonnements, j’en ai éliminé une vingtaine d’abonnements et réduit mon nombre de billets en une semaine à environ 100-150:

image

Et le temps de les parcourir et lire les intéressants: 20 minutes environ. Bonne amélioration ici !

Pour Twitter, j’ai aussi fait un ménage dans la liste de mes abonnements. Il y en avait plusieurs qui étaient des comptes de compagnie qui dans le fond envoyer de la pub. J’ai alors seulement gardé les pertinents. Et certains comptes aussi ne semblaient pas avoir eu de twit depuis un certain temps. J’ai donc réduit ma liste d’une vingtaine d’abonnements. Pas si mal. Faut surtout contrôler le temps passé à lire twitter.

 

Vérification des courriels

Là, je me suis discipliné. Je regardais mes courriels personnels un peu trop régulièrement à mon goût. Même si des fois cela me prends que seulement 30 secondes pour vérifier, la perte de mon focus courant est importante. Je me suis donc imposé l’horaire suivant:

  • 12h00
  • 15h30
  • 20h00

Et voilà, seulement trois fois dans la journée ! Et cela marche très bien. Il faut travailler quand même fort contre cette habitude de toujours vérifier nos courriels au cas où on manquerait quelque chose. Ah cette peur irrationnelle !

Pour mes courriels de mon travail, je me dois quand même de les regarder régulièrement, car cela fait partie de mon travail. Soit que je me programme un pomodoro pour faire uniquement le tri de mes courriels et mes tâches ou je les consulte entre deux pomodori.

Est-ce que vous avez des trucs différents pour gérer efficacement l’information provenant d’internet ?

 

Références: