Que conseilleriez-vous à quelqu'un qui voudrait devenir programmeur mais sans aller à l'uni?

Un changement d’orientation professionnelle est aujourd’hui certainement plus facile qu’auparavent. La question se pose donc pour les programmeurs reconvertis mais également à ceux qui n’ont pas la possibilité d’accéder à une formation supérieure (pour cause de manque de financement, de temps, charges familiales, etc.) ou encore qui n’en ont tout simplement pas envie! Quels conseils donneriez-vous à quelqu’un voulant devenir programmeur sur le tas sans passer par une formation universitaire? Premièrement, ne pas baisser les bras c’est tout à fait possible! Le monde online donne accès à une mine d’information gigantesque. Le plus dur sera donc peut-être de s’organiser pour tirer le meilleur parti possible de ce savoir qui nous tend les bras. Dans ce sens, il faudra sûrement résister à la tentation de vouloir trop en faire. Le développement couvre une foule de sujets intéressants, attention donc à ne pas se disperser. Une tactique peut être de dresser une liste de sujets ((Ne pas hésiter à demander de l’aide pour élaborer cette liste)) à suivre afin d’assimiler tous les concepts dans l’ordre. La deuxième étape sera de trouver les informations pour chaque sujets, cela peut aller d’un simple tutoriel à un cours online et gratuit donné – justement – par une université. Internet a grandement encouragé le partage du savoir, autant en profiter!

Par où commencer?

Voici un extrait d’une discussions sur reddit:

LE livre donc par lequel commencer: SICP. Rendez-vous sur ce site, récupérez le livre – gratuitement – et étudiez-en le contenu. Etudier, c’est-à-dire lire, visionner les vidéos et – surtout – faire les exercices, tout les exercices! On n’est pas à l’école mais justement raison de plus! Il faut vraiment assimiler le contenu de ce bouquin. Un autre avantage de se focaliser sur ce livre est qu’il devrait susciter votre curiosité et vous pousser à approfondir vos connaissances dans le développement en général. Prenez note de chacun de ces domaines mais gardez-les pour plus tard! C’est aller (trop) loin que de dire qu’après avoir lu ce livre, vous serez plus avancé qu’un informaticien sortant de l’université. Par contre, ce sera certainement une excellente base! C’est un livre consistant mais gardez courage et aller jusqu’au bout¹! Parallèlement à cela, mettez la main à la pâte: CODER! C’est en forgeant qu’on devient forgeron. Pour se faire trouvez un projet open-source plutôt que de partir dans votre coin. Trouvez un projet, récupérez le code source, modifiez, testez, jouez avec. Coder est peut-être la meilleure formation imaginable mais le plus gros avantage à développer sur un projet open-source est de cotoyer des développeurs expérimentés et souvent (très) talentueux – des geeks passionés. Si vous êtes perdus et que vous ne savez pas vers quel projet vous tourner, jetez peut-être un oeil à la demande sur le marché de l’emploi pour orienter votre choix en rapport à la technologie utilisée.

Troisième et dernier conseil, prenez régulièrement du temps pour parcourir les blogs de développeurs que vous appréciez, voir au fil du temps que vous admirez. Ajoutez encore à ces blogs, un ou deux sites communautaires tels que reddit (section programming) ou encore dzone et tenez-vous ainsi au courant des tendances actuelles, des expériences d’autres développeurs ou encore de l’état actuel des produits que vous aimez. Mais attention! Fixez- vous une limite à ce temps pour qu’il ne déborde pas sur les deux princiaples activités précédemment citées.

Quelques articles intéressants de développeurs

• Teach Yourself Programming in Ten Years par Peter Norvig

• Practicing Programming par Steve Yegge

• How Not To Become a Rockstar Programmer Jeff Atwood

• Do I Need a CS Degree to be a Software Developer?

Avant de nous quitter

Le plus important: programmer doit vous faire plaisir! Si vous ne prenez pas de plaisir arrêtez, pour être développeur il faut être passionné. Devenir programmeur se résume donc à étudier, coder, et ce dans un cycle continu. Suivez-le si la passion vous anime! Voilà pour une liste non exhaustive de plusieurs choses à faire pour devenir – à mon avis – un bon programmeur…

Qu’en pensez-vous?

Critique de livre: La Religieuse de Denis Diderot

Diderot révèle au moyen de ce roman les affres du monde religieux de son époque. Ce roman suit, semble-t’il, une affaire révélée au grand public mettant aux prises une religieuse ayant voulu faire annuler ses voeux. Celle- ci en est allée jusqu’au tribunal, mais malheureusement pour elle sans succès. Le roman met en oeuvre une religieuse, du nom de Suzanne, qui est envoyée au couvent sans avoir droit au chapitre. Principalement du fait que cette Suzanne serait née d’un autre père que ses deux soeurs ainées, histoire de famille donc… Il s’ensuit que pour Suzanne c’est loin d’être la vie rêvée! Elle finit par sortir du couvent une première fois pour rapidement se retrouver dans un autre… Eh oui Suzanne n’a pas de chance dans la vie! Ce n’est qu’après un dernier transfert qu’elle se trouve dans un troisième couvent où elle sera bien traitée. La vie semble - enfin - lui sourire. Au cours de ce troisième séjour, Suzanne explique toutes ses mésaventures à la mère religieuse. Cette mère-ci est d’ores et déjà très attachée à Suzanne et prend particulièrement à cœur les épreuves de Suzanne jusqu’à dire:

Il n’y a que dans les couvents où l’hummanité puisse s’éteindre à ce point. Lorsque la haine vient à s’unir à la mauvaise humeur habituelle, on ne sait plus où les choses seront portées.

Pleine de compassion, il s’ensuit une relation vraiment spéciale entre Suzanne et cette mère religieuse… Ca en devient érotique par moment et je dois dire que ça m’a pas trop conquis! Bref, je conseille cette lecture à qui veut lire du Diderot mais qui n’a pas peur d’entrer dans l’intimité de deux femmes ayant plus qu’une amitié platonique (bien que Suzanne soit toute naïve du début à la fin).

Pour aller plus loin

Une analyse de l’oeuvre: http://membres.lycos.fr/jccau/ressourc/romem/diderot.htm

Résumé 2008

Avec un peu de retard, je voulais quand même faire un petit bilan de 2008 et poser quelques objectifs sur l’année 2009.

Le boulot

2008 a marqué mes réels débuts au sein de Logica. Après mon stage de 3 mois à Lyon, j’ai débuté ma première mission chez Merck Serono où je travaille encore actuellement. Le métier de consultant est enrichissant et offre la possibilité de progresser dans beaucoup de domaines. Très heureux de pouvoir profiter de cette opportunité, je tiens encore une fois à remercier (si elle me lit) Patricia. Merci de m’avoir donné ma chance!

Le développement

Côté technique, j’ai passé la grande majorité de 2008 à coder en PHP - PL/SQL (Oracle) - HTML/CSS - JavaScript (YUI). Sur la fin de l’année j’ai également eu le plaisir de débuter un projet à temps partiel en Java (Spring, Hibernate, Castor)… A nouveau: très satisfaisant!

Lectures

Sur mes lectures de 2008, il m’est tout bonnement impossible de ressortir qu’une oeuvre du lot. Voici un petit melting pot de mes lectures préférées sur l’année:

• Pour se marer: Gros problème de Dave Barry

• Pour un beau français : Cyrano de Bergerac de Rostand

• Pour gérer ses activités: Getting Things Done de Dave Allen

• Pour une histoire touchante: For One More Day de Mitch Albom

• Pour un moment d’Histoire: Le Maître de Garamond d’Anne Cunéo

• Pour philosopher un peu mais pas trop: Hackers and Painters de Paul Graham

Ces bouquins ne quitteront pas de sitôt ma bibliothèque!

PoXd

Au niveau de ce blog, il y a eu du changement en un an avec la phase relooking dont je suis assez satisfait bien qu’il me reste encore une ou deux choses à régler. La fréquentation est également montée d’un cran, mais ça flatte juste mon égo à la limite… Ce blog existe surtout à usage perso. Evidemment s’il devient utile à d’autres, j’en suis ravi! J’ai également publié davantage de billets sur la 2ème moitié de l’année. En espérant pouvoir continuer sur ma lancée en 2009…

2009

Dans un an il y a 2 choses principales que j’aimerais pouvoir dire:

1. “J’ai terminé la lecture de SICP et - surtout - compris tout ce que j’y ai lu.” C’est un challenge, je l’ai toujours en tête et je fais ce que je peux pour le remporter mais c’est loin d’être facile!

2.  “Voici ma première contribution à un projet Open-Source (autre qu’un projet perso).” J’ai déjà quelques idées de ce côté-là. Celà demande un peu d’investissement mais je suis persuadé que celà en vaut largement la peine. En plus le développement me passionne alors…. 

Au-delà de ces objectifs, j’aimerais beaucoup développer mes compétences business et élargir toujours plus mes contacts. J’ai beaucoup à apprendre de ce côté-là mais je préfère mettre plus l’accent pour le moment sur mes compétences techniques.

C’est reparti pour une année, rempli de volonté et de bons objectifs, souhaitons-là autant enrichissante!

Tests unitaires JavaScript avec YUI

La méthodologie TDD, on l’a vu, propose d’écrire les tests comme première étape de code. Mais comment s’y prendre en JavaScript? Jetons un oeil à la solution proposée par les développeurs Yahoo! Ceux connaissant Java ont l’habitude des frameworks tel JUnit ou encore TestNG. Le principe est le même avec YUI Test (développé donc par Yahoo!) qui va être utilisé lors de cet article. Si maintenant nous entrons dans le coeur du sujet, imaginons que nous ayons à programmer une fonction qui vérifie que l’entrée d’un formulaire est bien un nombre. Si l’on suit la méthodologie TDD, on écrit d’abord le test de cette fonction. Cela va donner quelque chose comme ça:

var oTestCase = new YAHOO.tool.TestCase({
    name: "Test Common Fonctions",
    setUp : function () {
        this.data = [-1,1,' -1', '+1', 'a234', '034'];
    },
    tearDown : function () {
        delete this.data;
    },
    testIsNumber: function () {
        var n, notN, result;
        n = this.data[0];
        result = isNumber(n);
        YAHOO.util.Assert.isTrue(result);
    },
});

Quelques explications sont peut-être nécessaires:

• On utilise ici l’objet YAHOO.tool.TestCase qui permet de rassembler nos tests. Dans l’idéal il faudrait veiller à garder un objet logique, c’est-à-dire ayant un ensemble de tests qui ont un rapport entre eux comme par exemple le test d’un fichier javascript spécifique.

• La propriété _name _permet de savoir quel test a été lancé. On le verra plus loin, une console nous permet de savoir rapidement si des tests ont échoués ou réussis.

• Les fonctions setUp et tearDown permettent de définir et détruire des objets nécessaires aux tests.

• Les tests en eux-mêmes commencent par test (ici testIsNumber). Ces contiennent ce qu’on appelle des assertions, qui en l’occurence dans le cas présent va vérifier que la valeur retournée par isNumber vaut bien true. Dans l’exemple ci-dessus je ne teste que la première entrée du membre data, mais c’est un exemple, ce n’est pas un test complet. Pour bien faire ses tests, il faut essayer de tester tous les cas possibles.

Passons maintenant à la deuxième étape: l’implémentation de notre fonction isNumber:

function isNumber(chain) {
    try {
        intval(chain);
        return true;
    } catch (e) {
        return false;
    }
}

Nous avons donc notre implémentation de prête. L’exemple est ici très simple et j’espère qu’il ne déssert par la méthodologie dans le sens que ce n’est pas une perte de temps que de commencer par les tests. Un code dont on prend la peine de bien tester devient vraiment robuste et facilement maintenable. Le développeur garde également confiance en son code et si un nouveau développeur vient sur son code il peut rapidement se faire la main simplement en parcourant les tests! Bref, de nombreux avantages… Maintenant pour lancer les tests, c’est comme toujours très simple avec YUI:

YAHOO.tool.TestRunner.add(oTestCase);
var oLogger = new YAHOO.tool.TestLogger();
YAHOO.tool.TestRunner.run();

Et encore uniquement les deux dernières lignes sont nécessaires! En ajoutant la première on a l’avantage d’avoir un affichage plus précis sur une console comme celle-là:

Simple non? La documentation fera découvrir encore d’autres utilisations possibles de YUI Test mais encore une fois, je ne peux qu’encourager cette méthode de développement qui facilitera la vie à bien plus d’un!

Pour aller plus loin

• La documentation de YUI Test pour découvrir toutes les possibilités du framework.

• La vidéo (~50 minutes) qui m’a fait découvrir YUI Test.

• Code source de l’exemple

• Autre billet parlant de YUI Test en anglais qui va dans le même sens

• Writing Effective JavaScript Unit Tests with YUI Test

Critique de livre: Un risque calculé de Katherine Neville

C’est histoire est sympathique et agréable. A découvrir par un dimanche pluvieux devant la cheminée… L’histoire tourne autour de Vérity Banks qui voudrait faire payer les banquiers verreux et corrompus. Elle-même travaille dans le mileu, à la sécurité plus particulièrement. Elle se lance alors dans un défi de plus grande envergure que ce qu’elle imaginait au départ et ce à cause (ou grâce) de Zlotan Tor… C’est assez bien écrit bien que ce ne soit pas l’histoire la plus captivante que j’ai lue. Si le milieu bancaire ou informatique vous intéresse, je vous le conseille. Sinon je ne pense pas trop qu’il en vaille la peine.

Les tekos sont plus proches des ordinateurs que de leurs congénères. Ils travaillent mieux la nuit, quand tous les animaux, à l’exception des rapaces, sont allés se coucher. Ils mangent peu et n’importe quoi, sans aucun souci de gastronomie. Ils ne voient jamais le jour. Ne respirent jamais de l’air frais. Ils ne s’épanouissent qu’à la lumière artificielle, dans une atmosphère climatisée. S’ils se marient, s’ils font des enfants, ils les répartissent en analogiques et en numériques. Ils peuvent se montrer arrogants, désordonnées, incontrôlables et antisociaux. Je sais tout sur les tekos, parce que je suis de la même race.

DOM et ses bonnes pratiques

J’ai terminé le visionnage d’une série de 3 vidéos concernant les bonnes pratiques sur du traitement DOM. Je voulais en garder une trace parce que ces vidéos contiennent vraiment des choses intéressantes…

Ceci n’est pas une introduction à DOM. Si cet acronyme vous est inconnu vous n’êtes pas sur le bon article, un bon point de départ: Wikipedia

Présentateur: Douglas Crockford

Gestionnaires d’événements

Il existe pas moins de 3 méthodes pour affecter une fonction à un type d’événement sur un noeud:

• node[“on” + type] = fonction
• _node._attachEvent(“on” + type,  fonction) - valide uniquement sur IE
• _node._addEventListener(type, fonction, false) - Recommendation W3c mais non supporté sur IE

Pour bien faire, il faut utiliser les 3! Vive le monde du web… En plus IE possède une variable globale event contenant les données de l’événement (source, target, etc.) alors que le W3C recommande le passage d’un paramètre au gestionnaire contenant ces données…

Fuites mémoire

Toujours prendre bien garde que IE 6 utilise une stratégie minimaliste concernant la gestion de la mémoire. Cette stratégie se base sur un entier incrémenté lorsqu’une nouvelle référence à un objet se crée et décrémenté lorsque cette référence est supprimée… Le problème surgit lorsqu’une application met en oeuvre des références circulaire (explications et exemples sur cet article de Crockford). Cette gestion peut facilement occasionner des fuites mémoires et ce particulièrement lorsque les gestionnaires d’événements interviennent. IE crée une référence cyclique entre le noeud DOM sur lequel on attache un gestionnaire et le code de ce gestionnaire lui-même (dans le cas où ce code utilise le noeud - donc très souvent), c’est là qu’est le problème… Ce qui fait qu’il faudra explicitement mettre à null tous les membres d’un noeud étant une fonction avant de le retirer (ou de le remplacer, attention aussi par l’intermédiaire de innerHTML) du DOM sous peine de voir proliférer des zones mémoires occupées et qui le resteront tant que IE reste ouvert!

Tips

Pour simple rappel perso je publie ici encore quelques conseils à ne pas oublier:

• placer les balises javascript le plus bas possible dans le document HTML
• placer les imports des fichiers CSS le plus haut possible
• rassembler les fichiers externes autant que possible (une bonne piste: YUI Compressor pour les js et les css)
• ne pas utiliser document.write
• ne pas utiliser les collections de l’objet document (anchors, forms, etc.)
• ne pas utilier document.all
• les éléments dans le DOM sont en MAJUSCULES (tendance à l’oublier)
• utiliser la méthode setAttribute des noeuds plutôt que d’affecter la valeur à la propriété directement
• cloner un noeud retourne un noeud qui n’est pas dans le DOM

Quelques indices bon à savoir pour créer une application web toujours plus performante! Note: utiliser un framework comme YUI simplifiera souvent beaucoup les choses.

Conception et développement Spring - 3ème jour

Ces 3 jours de formation ont été vraiment sympa. Ils m’ont permis de surtout en apprendre au niveau conception par rapport à l’intitulé du cours. Comme j’avais déjà parcouru le livre Spring In Action, les infos révélées en rapport à Spring lui-même ne m’ont pas été d’un grand apport. Merci donc à Logica pour cette sympathique opportunité! Le 3ème jour a été passé à implémenter la solution finale du cas d’authentification avec une intégration d’Hibernate et Struts. Je mets le code source à disposition comme simple référence. Le zip contient un versioning de chaque étape que l’on a suivi en cours. Si vous avez des questions n’hésitez pas à me contacter!

JavaFX 1.0 est sorti!

Le domaine des applications riches m’intéresse toujours plus et j’ai de la chance parce qu’en ce moment l’activité dans le domaine est chargée! Adobe prépare Flex 4 et Catalyst, Microsoft s’ouvre aussi avec Silverlight… Et aujourd’hui Sun s’y met avec son nouveau-né: JavaFX. Ca m’intéresse tellement que j’en avais ouvert un blog il y a 6 mois de cela (plus très actif pour le moment mais j’avais commencé un petit tuto sur JavaFX).

Donc aujourd’hui c’est JavaFX qui est au centre du sujet, que fait valoir Sun pour ce nouveau venu? Alors en bref:

• langage s’exécutant au sein de la machine virtuelle, on parle donc toujours de langage Java compilé au final
• applications multi-supports: desktop, web, tv, mobile
• support audio-vidéo
• découpage entre développeurs et designers

On se trouve donc à la version 1.0 de la plateforme, logique que l’on se trouve loin (très loin) de ce qu’offre Flex par exemple en terme de composants. Mais le fait que ce soit du java n’est vraiment pas pour me déplaire, ce langage m’a toujours bien plu. Le problème c’est que sans composants à mettre en avant il va être difficile de mettre en place des applications riches en entreprise… Cependant l’un des atouts majeurs de Java est d’avoir une communauté énorme de plus composée de grands talents. On peut donc espérer voir arriver bientôt un nombre important de jolies démo. Un autre point important à relever est la richesse de Java sur lequel se base JavaFX. Le nombre de librairies venant par exemple d’Apache est bien là pour démontrer la richesse de la communauté. Toutes ces librairies sont toujours utilisables depuis JavaFX, en ce sens Java a un bon coup à jouer. Last but not least, un nombre impressionnant d’applications tournent en entreprise sur Java et ce que ce soit desktop, web ou même mobile. Un point de plus donc qui fait penser que l’adoption de JavaFX peut se faire rapidement… On verra.

Pour aller plus loin:

• JavaFX : le site officiel avec beaucoup d’exemples, tutos, etc.
• Chris Oliver’s Weblog : le tout premier développeur de F3 - ancien nom de JavaFX
• James Weaver’s JavaFX Blog : blog d’un précurseur dans l’utilisation de JavaFX
• Silvera Neto blog : blog d’un autre développeur JavaFX

Test Driven Development et JavaScript

TDD est une méthodologie bien connue – devrait en tout cas – des développeurs, mais l’appliquez-vous à votre code JavaScript? Personnellement, moi non. En tout cas pas jusqu’à maintenant… Je dois dire que je n’y prêtais même pas attention, je fonçais tête baissée dans le code et ensuite hop je lançais firebug et essayais de voir ce qui n’allait pas. Pour moi, le développement JavaScript n’était pas vraiment ma tasse de thé mais il est évident qu’en procédant de cette manière, il était difficile d’espérer une autre issue Voyons donc ce que la méthodologie TDD peut apporter en terme d’efficacité et de professionalisme. Mais qu’est-ce que TDD, quels en sont les avantages, et comment l’appliquer au code JavaScript? Je vais essayer de répondre à ces questions dans cet article.

Qu’est-ce donc que TDD

TDD est une méthodologie de développement faisant la part belle aux tests unitaires. Dans la pratique cela voudra dire que les tests se feront avant le code à proprement parler. Schématisons tout ça:

Le processus est très simple – si l’on prend une fonctionnalité précise à implémenter:

1. Conception: étape où l’on définit la fonctionnalité, où l’on réfléchit à l’interface et aux paramètres d’entrée et de sortie nécessaires à son fonctionnement
2. Écriture des tests: la réponse à “comment mon code doit se comporter” – suivant ces données en entrée, je m’attend à cet état en sortie
3. Code: implémentation de la fonctionnalité
4. Lancement des tests sur le code: si les tests révèlent une erreur, retour à l’étape 3 et ainsi de suite jusqu’à ce que tous les tests soient réussis

Au premier abord, il peut paraître étrange d’écrire des tests sur du code que l’on a même pas commencé à écrire. Mais comme on va le voir, plusieurs avantages ressortent de cette manière de faire.

Ses avantages

Écrivez en premier lieu les tests unitaires de vos fonctionnalités et vous verrez alors – dans le désordre – que:

• vous aurez plus facilement identifié les tâches à effectuer pour implémenter vos fonctionnalités
• vous aurez une meilleure compréhension de votre code
• vous gagnerez du temps au final lorsqu’il faudra amener des évolutions à votre application
• vous aurez un excellent point de départ lorsqu’un bug vous sera rapporté (eh oui il y a toujours des bugs – dans ce cas soit le test unitaire n’a pas couvert totalement le code, soit la conception n’a pas prévu tous les cas possibles ou encore une utilisation de la fonctionnalité n’avait pas été prévue)

Sûrement que d’autres bienfaits ne sont pas sortis de mon cerveau à temps pour les lister ici mais c’est déjà pas mal! Ces avantages en valent certainement la peine encore faut-il essayer cette méthodologie! Dans le cas présent je voulais l’appliquer à du code JavaScript. Quelles sont les possibilités de ce côté-là?

YUI Test

YUI est un framework javascript développé par YAHOO! qui fournit de nombreux composants graphiques mais pas seulement. Bref, si vous ne connaissez pas je vous encourage vivement à y jeter un oeil, il facilite beaucoup les choses… Au passage, lire les sources du framework peut être une très bonne idée dans le but d’améliorer ses compétences dans ce langage. Le framework lui-même contient une batterie de tests complète pour chaque composant, rien de tel pour se former! Ce framework fournit les bases nécessaires pour se lancer de l’écriture de tests unitaires javascript. Par l’intermédiare des classes YAHOO.tool.TestCase, YAHOO.tool.TestRunner et YAHOO.tool.TestLogger tout est prêt pour se lancer! Il permet de plus de simuler des événement utilisateurs comme un clic de la souris. Last but not least, ce framework est compatible avec la majorité des browsers, donc plus (ou presque) de soucis à se faire!