Sondage Développeurs Québec 2012

Quoi de mieux que de commencer l’année avec un petit sondage pour les programmeurs afin d’en savoir davantage sur le profil de notre profession !

L’idée de ce sondage m’est venue lors de la conférence principale de l’Agile Tour Québec 2011 par Robert C. Martin. Ce dernier, au début de sa présentation, avait fait un sondage éclair à main levée parmi les participants afin d’en savoir plus sur les technologies utilisées et les pratiques connues. La foule n’était pas composée à 100% de développeurs et donc les résultats peut-être un peu faux à ce moment.

Histoire d’en avoir le cœur net, j’ai préparé le court et simple sondage suivant:


Merci d’avance de participer à ce sondage, en particulier si vous avez un des profils suivants ou que vous programmer à l’occasion:

  • Développeur/Programmeur
  • Chef d’équipe
  • Architecte Logiciel
  • Testeur
  • Coach
  • Formateur
  • Entrepreneur

Les résultats du sondage seront publiés sur ce blogue dans quelques semaines. Merci d’y participer.

Publicités

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

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 ?

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 :

Critique du livre: The Passionate Programmer

 

The Passionate Programmer: Creating a Remarkable Career in Software Development (Pragmatic Life)

Êtes-vous passionnés par votre travail ?

Je me suis intéressé à ce livre un peu par curiosité et je voulais voir ce qu’il pouvait apporter à ma carrière. Autrefois intitulé My job went to India: 52 ways to save your job dans sa première édition, le livre a changé de nom pour sortit un peu du titre controversé et bien refléter son sujet principal: comment avoir une carrière remarquable en tant que programmeur. L’auteur Chad Fowler est développeur connu au niveau international. Il travaille principalement avec le langage Ruby et le Framework Ruby on Rails.

Le livre est composé de 53 conseils de carrière divisés en 5 sections dont voici leurs descriptions:

  • Choisir son marché : L’importance de bien choisir dans quelles technologies et quel domaine d’affaires on veut évoluer. Ne pas se limiter à une seule technologie et bien balancer les risques potentiels.
  • Investir dans son produit : Mise à part la programmation, il est aussi important de bien connaître son domaine d’affaires. Si on ne connait pas trop certaines notions, se trouver un mentor. Si on veut voir si on connaître bien son affaire, essayer de l’enseigner à quelqu’un d’autre. Et ne pas oublier de pratiquer, pratiquer et pratiquer.
  • Exécution : Se rappeler régulièrement pour qui on travaille et s’assurer d’apporter de la valeur à l’entreprise. Noter ses bons coups et savoir comment gérer ses erreurs sont aussi important.
  • Marketing, pas seulement pour les cadres : Les perceptions sont importantes, c’est d’ailleurs le facteur principal dans les évaluations de rendement. Être présent et communicatif. Parler le langage de nos interlocuteurs.
  • Maintenir son expertise : Nous sommes déjà obsolètes ! C’est donc nécessaire de faire son plan de carrière,  de surveiller les tendances et de s’évaluer régulièrement

J’ai particulièrement aimé les sections qui parlaient des notions de Généralistes et de Spécialistes. L’auteur raconte qu’il est important d’être les deux. Je m’explique:

  • Être un généraliste: L’idée est ne pas être seulement un programmeur. Si l’opportunité se présente, ne pas hésiter à faire aussi de l’analyse, de l’architecture, de la charge de projet ou administrateur de base de données. L’idée est d’être utile à l’équipe, peu importe les tâches. C’est un peu la même chose au niveau de la technologie. Il faudrait normalement que nos habiletés transcendent les différentes infrastructures. Si on maîtrise bien une plateforme, ne pas hésiter à approfondir une autre.
  • Être un spécialiste: Bien connaître à fond un type de technologie est important. On ne parle pas ici de tout connaître, mais d’avoir une bonne profondeur pour connaître environ 80 % des situations qui pourraient se présenter au programmeur. Exemple: Si vous êtes un spécialiste .NET, vous n’avez pas d’excuses de ne pas connaître tout sauf du .Net. Il faut aussi savoir comment redémarrer un serveur IIS, faire l’installation d’un gestionnaire de code source ou corriger des problèmes de performance.

En conclusion, j’ai beaucoup aimé ce livre et d’ailleurs cela m’a pris seulement deux semaines à livre. Je le recommande à tous ceux œuvrant dans le domaine de la programmation, de près ou de loin. Les conseils de Chad Fowler, bien que pas nécessairement applicable pour tous, sont intéressants. On voit aussi à travers le livre ce qu’ont vécu l’auteur et les choix de carrière qu’il a du faire et pourquoi il les a faits. Bref, soyez passionné et remarquable !

Point négatif: On parle beaucoup du contexte américain et des emplois volatiles surtout en crise économique. Cela ne s’applique pas trop au Québec où l’on manque d’informaticiens un peu partout.

 

Mes points clefs:

  • Investir dans sa carrière est important. Il ne faut pas attendre que son employeur le fasse.
  • Être un généraliste et un spécialiste en même temps.
  • Bien connaître le domaine d’affaire de son employeur est un atout important.

 

Références :

TFS est ouvert aux vieilles technos

Je regardais récemment le scénario d’intégrer du code VB6 dans le gestionnaire de code source Team Foundation Server (TFS) 2008, histoire de faire un premier pas vers une conversion à .NET. C’est en fouinant un peu que j’ai découvert l’existence du Visual Studio Team System 2008 Team Foundation Server MSSCCI Provider

Ce petit provider de Microsoft s’avère très utile si vous avez de vielles applications et que vous voulez tout regrouper sous un même toit, comme avec TFS. On peut ainsi dire un beau bye-bye à Visual SourceSafe.

L’outil permet d’utiliser TFS comme gestionnaire de code source pour des outils de développement un peu vieillot tel que VB6 ou  Visual FoxPro. Il marche même avec PL/SQL après l’ajout d’un petit plug-in:

Du côté de VB6, tout marche très bien et les menus; ils sont pratiquement les même qu’avec Visual Source Safe (VSS):


On peut aussi changer de gestionnaire de code source au besoin grâce au programme suivant qui est installé avec le provider:

Une fois notre option choisie, on verra le bon gestionnaire de code source à la prochaine ouverture de notre outil de développement.

On peut donc ouvrir un projet VB6 sous VSS, changer le gestionnaire de code source et ouvrir une deuxième instance de VB6 qui utilisera TFS.

Points à retenir:

  • L’historique de VSS ne se copie pas dans TFS. À moins de faire une conversion, mais la procédure semble plus complexe qu’une simple copie des fichiers.
  • Le concept de fichiers partagés de VSS n’existe pas dans TFS. Si c’est utilisé, prévoir du temps pour réarranger le code.
  • La recherche dans TFS 2008 ne peut aller jusqu’au contenu des fichiers. On ne peut que chercher les titres des fichiers (!). Je ne sais pas si cette lacune est corrigée dans TFS2010 par contre.

Donc, ne jeter pas VSS aux poubelles trop vite. Il pourrait servir pour des recherches et des consultations de l’historique.