Small Basic, un bel outil d’apprentissage

En bon papa, je voulais initier ma grande fille à la programmation et aussi lui expliquer un peu ce que je fais dans la vie.

En regardant l’environnement de développement Small Basic de Microsoft, qui est gratuit en passant, j’ai donc décidé de l’utiliser et de regarder un peu ce qu’il peut faire.

Premièrement, l’interface est très « bonbon » avec seulement quelques gros boutons. Beaucoup plus épuré que Visual Studio:

image

Par la suite, je remarque que l’intellisense est aussi très graphique:

image

J’aime bien.  Je trouve que cela rend facile de voir les possibilités du langage. Je regarde aussi dans la documentation pour me trouver quelques exemples intéressants et je tombe sur les commandes suivantes:

image

Eh oui, le langage “Logo” est inclus en partie dans le Small Basic avec la commande “Turtle”. Ce fut un de mes premiers langages de programmation sur mon vieux Commodore 64 il y a de ça de nombreuses années. D’ailleurs, cela ressemblait à ceci à l’époque:

c64-terrapin-logo-vers-a.jpg

Par la suite, je guide ma fille pour l’aider à écrire ses premières lignes de code et on y va avec la compilation:

image

Ce qui donne un petit déplacement de la tortue:

image

On a aussi repris un exemple de la documentation qui fait tourner la tortue pour faire un beau dessin. Voici le code:

image

Et son résultat:

image

Cool, n’est-ce pas  ?

D’ailleurs la documentation est assez bien faite et montre différents exemples. On peut aussi compiler le tout et faire des exécutables.  Avec cela, s’achève cette première leçon, elle préfère jouer sur l’ordinateur que de programmer semble-t-il… On va donc la laisser grandir un peu plus et on essayera une autre fois.

Références:

Publicités

Pourquoi je n’aime pas les générateurs de code ?

639165_old_factory

Je n’ai jamais vraiment beaucoup aimé les générateurs de code.

Vous savez, le genre d’outils qui peut vous générer des centaines et parfois même des milliers de lignes de code avec simplement quelques paramètres ?

Dans cet article, je vais discuter des points positifs et négatifs quant à l’utilisation d’outils de générateurs de code. Des exemples de différents générateurs seront aussi décrits.

On mentionne  souvent que ces outils nous font économiser des centaines d’heures et aide à avoir du code plus standard, je pense par contre qu’à moyen et long terme, il peut y avoir certains effets négatifs.

Comme par exemple :

  • Nuit à l’apprentissage: C’est le point le plus important d’après moi. Le simple fait que de ne pas avoir touché à une partie du code, nous rend vulnérable par rapport celle-ci. Aussi, il est important de bien comprendre un système informatique dans son ensemble et non seulement les parties du code qui n’ont pas été générées. Faut aussi savoir que tel générateur ne sera pas disponible dans un autre projet… Exemple: un générateur de code se charge de produire les contrats de services et de données en WCF. Il se charge de bien créer les classes et de mettre les bons « tags » relatifs à WCF. Dans ce cas, on ne peut pas dire que nous avons gagné de l’expérience avec WCF. Si on arrive dans un autre mandat ou projet et que le générateur n’existe pas, il nous faudra approfondir WCF car finalement, on ne le connaît pas vraiment malgré son utilisation dans un précédent projet.
  • Difficultés lors de la recherche d’erreurs : Les générateurs de code produisent en général du code un peu obscur et difficile à lire. Si une erreur se produit dans cette partie du code, la recherche peut s’avérer longue et douloureuse.
  • Pour une simple correction, on a souvent pas le choix d’utiliser le générateur de code: C’est en général non-productif de devoir refaire l’exécution du générateur pour faire un petit changement, comme renommer une méthode par exemple ou changer de type une propriété. Pour ces gestes, c’est tellement plus facile et rapide d’y aller manuellement…

Bien que j’aie déjà utilisé certains de ces outils, je peux avouer qu’ils sont parfois efficaces et, probablement, valent la peine d’être utilisé selon le contexte. Dans certains environnements avec des dizaines de programmeurs, on n’a pas trop le choix de standardiser certaines parties du code malgré les inconvénients. Bref, je crois que l’idéal est d’avoir une bonne balance entre productivité à court terme et l’apprentissage à long-terme.

Voici quelques-unes de mes expériences avec les générateurs de code:

Bonnes:

  • LINQ to SQL: Le code généré à partir de tables SQL Server n’est pas trop gros. C’est certain qu’il n’est pas très beau non plus, mais c’est assez facile de se créer une classe « extended » pour y ajouter des options particulière, comme une chaîne de connexion qui peut changer selon certaines conditions. Mais dans ce cas, le gain se fait surtout par l’utilisation directe de LINQ pour lire et modifier nos classes SQL. Le code que l’on créé ainsi manuellement est beaucoup plus lisible et simple avec LINQ.
  • Resharper: La génération de code dans Resharper se charge surtout de petits bouts de code qui seront intégrés à notre classe. Après cela, on les manipule comme on veut. Voyez ici les exemples .

Négatives:

  • Smart Client Software Factory: Il y a une bonne volonté ici de faire des outils pour générer nos vues, contrôleurs et autres structures nécessaire au pattern MVP-C. Par contre cela en résulte en un nombre assez nombreux d’événements. Lorsqu’il faut faire du débogage, on ne se sait plus trop ou donner de la tête lorsque cela saute d’un événement à l’autre.
  • CodeSmith : J’ai déjà utilisé cet outil pour générer une couche d’accès aux données dans un précédant projet. Je trouvais terrifiant de voir des milliers de lignes de codes produite pour simple une table avec une dizaine de colonne seulement. Par chance que les erreurs ne s’y trouvaient pas souvent. Noter aussi que CodeSmith a d’autres outils que je n’ai pas essayé et qui sont probablement intéressant malgré tout.
  • L’outil « Add Service Reference » de Visual Studio pour WCF: Je n’aime pas cette option qui se fait un peu trop facilement avec un clic droit de la souris. Le gros problème c’est que le fichier de configuration est rempli plein d’options sélectionnés dont plusieurs ne sont pas utile. Aussi, c’est un peu embêtant si on ajoute un deuxième service en référence dans le même projet. J’aime beaucoup mieux la méthode manuelle tel que décrit dans l’article WCF the Manual Way…the Right Way

Et vous, que pensez-vous des générateurs de code ?

Outils pour l’agilité

j0431711 Kent Beck, l’un des fondateurs du XP Programming, a écrit récemment un article, "Tools for Agility", sur l’importance des outils avec les méthodologies agiles. Voici un petit résumé de ses propos:

Dans le manifeste agile on parle entre autre de miser davantage sur les individus et les interactions que sur les outils et les processus de développement lourds.

Mais cela ne veut pas dire qu’on n’a pas besoin d’outils. On ne parle pas ici de retourner à l’âge de pierre pour écrire nos plans de projet sur des murs de pierre !!!

La priorité des outils était dans une approche de type "Waterfall" est de supporter efficacement une activité donné. Maintenant, les outils doivent supporter efficacement le changement fréquent d’activité, comme c’est le cas avec l’agilité.

Comme on effectue des livraisons fréquentes de nouvelles fonctionnalités, il y a davantage de transitions entre ces activités. L’image suivante représente bien ce problème de transition dans un mode agile:

image

La plupart des pratiques agiles ont donc besoin d’outils qui sont ajustés à ce rythme de développement. On ne pourrait pas faire de l’intégration continue sans des outils comme CruiseControl, FinalBuilder ou VSTS. Même chose pour le TDD, le refactoring et la planification itérative.

Si vous voulez en savoir plus sur l’impact des outils dans un mode agile et aussi sur l’avenir de ces mêmes outils, je vous recommande de lire l’article en question:

Tools for Agility by Kent Beck

CruiseControl.rb : intégration continue en moins de 10min ?

Bon, j’ai trouvé cette nouvelle version de CruiseControl en Ruby très intéressante:

Cruise_logo_large

On y mentionne pouvoir faire notre setup en 10 minutes (!)

Fini les fichiers XML à configurer. Hmm, cela semble attirant. Il faut cependant avoir SVN Subversion comme gestionnaire de code source et Ruby. On peut compiler des projets en Java ou en C#.

Notre code de configuration de notre build est fait en Ruby, un vrai langage de programation. Par exemple, un snippet de code peut ressembler à cela:

Project.configure do |project|
  case project.name
  when 'MyProject.Quick' then project.rake_task = 'test:units'
  when 'MyProject.BigBertha' then project.rake_task = 'cruise:all_tests'
  else raise "Don't know what to build for project #{project.name.inspect}" 
  end
end

J’adore cette manière très lisible de voir le code. Je ne pense pas que cela peut égaler la facilité d’utilisation et les nombreuses options de FinalBuilder, mais pour du OpenSource, cela semble prometteur. Moi qui n’aime pas trop les fichiers de configuration XML, voilà une bonne occasion d’essayer ce CruiseControl.rb !

Ghost Doc

J’ai découvert l’autre jour un petit utilitaire fort intéressant: Ghost Doc. Il permet de faciliter grandement l’ajout de commentaires "xml" dans le code. Ghost Doc analyse le code à commenter et génère un genre d’esquisse de commentaires et il ne nous reste plus qu’à le finaliser.

Exemple:

Voici une méthode en C# pour aller chercher une liste de répertoire sous un nom de server dans un fichier XML:

public static StringCollection GetDirectoryList(String serverName)
{
StringCollection collDir = new StringCollection();
XmlDocument xmlDoc;
XmlNodeList xmlNodeDirList;
XmlNode xmlNode;

}

Au lieu de faire les "///" traditionnelles, je me positionne sur la méthode à documenter et j’active la nouvelle option venant de GhostDoc avec le menu contextuel (clic droit), "Comment This" :

Et j’obtiens ceci sans rien faire d’autre:

/// <summary>
/// Gets the directory list.
/// </summary>
/// <param name="serverName">Name of the server.</param>
/// <returns></returns>

Je fais quelques petites modifications pour améliorer le tout et voilà:

/// <summary>
/// Used by the console or windows client to get the list of directories to scan
/// for the server name passed in the parameters
/// </summary>
/// <param name="serverName">Name of the server.</param>
/// <returns>
/// Return an array of string representing a list of directory
/// </returns>

 

Autre exemple avec une fonction de type "bool":

public static bool IsExcludeDirExist(string serverName)
{
bool nodeData = IsNodeDataExist(serverName.ToLower(), "ExcludedDirectories");
return nodeData;
}

J’utilise "Comment this" et j’obtient directement ceci:

/// <summary>
/// Determines whether [is exclude dir exist] [the specified server name].
/// </summary>
/// <param name="serverName">Name of the server.</param>
/// <returns>
/// <c>true</c> if [is exclude dir exist] [the specified server name]; otherwise, <c>false</c>.
/// </returns>

Et par la suite, j’y fais quelques modifications:

/// <summary>
/// Determines whether an excluded directory exist for the specified server name.
/// </summary>
/// <param name="serverName">Name of the server.</param>
/// <returns>
/// <c>true</c> if an excluded directory exist for the specified server name; otherwise, <c>false</c>.
/// </returns>

Intéressant, non  ?

Ghost Doc ne fait pas des miracles, mais il rend la création de commentaires XML beaucoup plus facile. Par contre, il est important de bien nommer ses fonctions et méthodes pour que Ghost Doc puisse en faire une bonne analyse. C’est en fait une bonne pratique de toujours s’assurer que les noms de fonctions et méthodes sont toujours significatifs. Pour y arriver, il s’agit simplement de suivre ces trois règles:

  • Utiliser le "PascalCasing" ou le "camelCasing" pour écrire les noms avec plusieurs mots
  • Débuter les noms des méthodes avec un verbe
  • Ne pas utiliser d’abréviation dans les noms

    GhostDoc marche principalement avec le C#, mais je crois qu’il y a quelques fonctionnalités pour VB aussi.

    Pour une simple introduction de GhostDoc, voici un article intéressant:

    http://dotnetslackers.com/articles/vs_addin/Introduction_ghostdoc.aspx

    Et pour le télécharger:

    http://www.roland-weigelt.de/ghostdoc/

  • SvnBridge – Use TortoiseSVN with Team Foundation Server

    Pour les amateurs de Tortoise SVN et de Subversion, les gens de CodeFlex travaillent actuellement sur un outil appelé "SvnBridge" pour être utilisé avec Team Foundation Server:

    http://www.codeplex.com/SvnBridge

     

    Si TortoiseSVN ou le concept de Subversion ne vous dit pas grand chose, voici quelques liens:

    Définition de "Subversion":

    http://en.wikipedia.org/wiki/Subversion_%28software%29

     

    Logiciel de subversion "OpenSource" pour .NET:

    http://tortoisesvn.net/

    Logiciel pour l’intégration de Tortoise dans .NET (~50$ la licence):

    http://www.visualsvn.com/

     

    J’ai fait l’essai de TortoiseSVN dans quelques projets et je trouve cela très bien et aussi fiable (sinon plus) que VSS.  Le concept de "merge" est puissant, ne causant que rarement des conflits. Il permet à plusieurs personnes de travailler dans le même fichier de code (ex: dans des fonctions différentes) en même temps  sans créer aucun conflits. L’intégration de Tortoise avec le "Windows Explorer" est bien réalisée, améliorant ainsi l’opération de se créer un "Working folder".  Et VisualSVN rend l’utilisation de tout ceci encore plus facile car tout se fait en direct dans Visual Studio.