Chez Pascal

Bad Astronomy

2009-09-05T08:42:00.003-04:00

Je viens de terminer la lecture du livre Bad Astronomy de Phil Plait.

Ce livre est un recueil de mythes et légendes urbaines à propos de l'astronomie, de l'exploration spatiale et de la cosmologie.

La première moitié du livre aborde des questions comme pourquoi le ciel est bleu, pourquoi les étoiles scintillent ou comment fonctionne les marées. Mais le livre n'est pas un manuel d'astronomie. C'est plutôt un livre de vulgarisation et d'éducation. Il éclaircit des conceptions fausses que plusieurs ont comme, par exemple, l'idée que l'eau des toilettes tourne dans un autre sens dans l'hémisphère sud! Il prend bien la peine d'expliquer la signification de plusieurs termes. Par exemple, il explique en détail qu'elle est la différence entre un météore, une météorite et un météoroïde, termes que l'on emploie souvent indifféremment.

La deuxième moitié attaque plusieurs croyances qui n'ont pas de fondement scientifique. Car en plus d'être un astronome, Phil Plait est aussi un sceptique. Ceux qui lisent son blog le savent très bien. Phil Plait fait la guerre à toutes les pseudo-sciences et croyances populaires comme l'astrologie, le créationnisme et les visites d'ovnis! Son livre contient donc quelques chapitres consacrés à réfuter les arguments des tenants de ces idées. Il consacre un chapitre à attaquer les arguments de ceux qui croient que l'homme n'a jamais marché sur la lune. Un autre chapitre que j'ai bien aimé est celui où il énumère le top 10 des erreurs d'astronomie que font les films de science-fiction.

En gros, j'ai aimé! Plait a un sens de l'humour qui rend certains chapitres arides plus faciles à lire. Étant moi-même convaincu de l'importance de l'éducation et de la science pour une meilleure compréhension de notre monde, ce livre s'inscrit dans ce schéma. Je le recommande à ceux qui s'intéressent à l'astronomie mais aussi à la science en générale.

How to get ideas

2009-07-25T09:44:00.002-04:00

J'ai toujours cru que les personnes très créatives, celles qui ont toujours de bonnes idées, sont spéciales et possèdent un talent qui n'est pas accesible au commun des mortels. Mais le livre How to get ideas m'a convaincu que ce n'est pas une question de talent particulier. N'importe qui peu devenir créatif et avoir de bonnes idées. Il s'agit d'avoir la bonne recette.

Le livre démystifie le processus de création. Il est séparé en deux parties. La première traite de l'état d'esprit qu'il faut développer pour devenir créatif. La deuxième énumère les étapes pour trouver une idée pour solutionner un problème.

Voici quelques points que j'ai retenu:

Une idée est un assemblage d'éléments qui à première vue n'ont rien en commun. L'idée (!) est d'arriver à combiner ces éléments pour produire quelque chose de nouveau.
La curiosité est une qualité essentielle pour être créatif. La personne curieuse accumule un baggage de connaissance qui servira d'éléments de base à la création d'idées nouvelles.
Il est rare de trouver LA bonne idée d'un coup. Il faut au contraire s'efforcer de produire une grande quantité d'idées, même farfelues. L'analyse de ces idées aidera à en trouver une qui se démarque.
S'exposer le plus possible aux nouveautés stimule le processus créatif. Il faut éviter de toujours faire les choses de la même façon.
Quand on doit solutionner un problème, il faut poser des questions. Beaucoup de questions! Il est essentiel d'en savoir le maximum sur le problème.
Il y a toujours une foule de solutions à un problème. Il faut juste les voir!

À la lecture du livre, on constate que l'auteur, Jack Foster, en sait beaucoup sur le sujet. Il a enseigné ces techniques pendant longtemps et possède une longue expérience dans le domaine de la publicité.

Je crois que tous devraient en bénéficier.

Clean code

2009-05-19T21:20:00.003-04:00

Je lis présentement le livre Clean Code de Robert Martin (souvent surnommé Oncle Bob!)

Ce livre insiste sur les bonnes pratiques nécessaires pour produire du code de première qualité. Il insiste sur plusieurs principes importants et bien connus (inversion de contrôle, tests unitaires), mais un a particulièrement attiré mon attention: Single Responsability Principle, ou, traduction libre, le principe de responsabilité unique.

En gros, ce principe stipule que chaque fonction d'une classe et, à un niveau plus élévé, chaque classe d'une application doivent avoir une seule responsabilité. En suivant ce principe, on arrive à diminuer de beaucoup la taille des fonctions et des classes, ce qui les rend plus lisibles et maintenables. Ce principe permet aussi de plus facilement éliminer la duplication de code, puisque les différentes classes sont beaucoup plus faciles à réutiliser à travers l'application.

Le principe a aussi une autre conséquence intéressante: si les fonctions et les classes sont petites et focus, les modifications au code existant seront beaucoup plus rares. L'ajout de nouvelles fonctionnalités se fera la plupart du temps en ajoutant de nouvelles fonctions et de nouvelles classes. On limite ainsi de beaucoup les risques de briser quelque chose! C'est un autre principe intéressant: le Open-Closed Principle. Les applications devraient être ouvertes pour permettre facilement les ajouts mais fermées pour les modifications. En pratique, ce n'est pas toujours possible, mais c'est un principe intéressant pour produire du code de qualité.

Pour l'amélioration de mes tests unitaires

2009-04-25T08:10:00.002-04:00

J'ai une confession à faire. Malgré que j'ai toujours su la valeur et la pertinence des tests unitaires, je dois avouer que j'ai souvent écrit des tests qui laissaient à désirer. J'ai souvent négligé le principe qui stipule qu'on doit écrire les tests avant d'écrire le code. Résultat: des tests fragiles qui ne tenaient pas la route dès qu'un changement était apporté aux classes.

Début 2009, je me suis fixé l'objectif de changer tout cela! Je suis tombé dernièrement sur le livre Test Driven de Manning et la lecture des premiers chapitres m'a particulièrement aidé! Dans ceux-ci, on nous amène à écrire un petit programme en utilisant les méthodes TDD. Le principe de base? Ces trois étapes: test, code et refactor. La technique requiert passablement de discipline. Aucune nouvelle fonctionnalité ne doit être ajoutée sans qu'un test ne soit écrit avant.

D'après l'auteur Lasse Koskela, la bonne approche consiste à écrire les tests en fonction des fonctionnalités de la classe. Ça implique que l'on teste en grande majorité du temps seulement les méthodes publiques d'une classe. Le reste de la classe sera testé indirectement. Et si on se rend compte qu'on n'arrive pas à bien tester certaines méthodes privées de la classe en ne passant que par les tests aux méthodes publiques, c'est probablement le signe que ces méthodes devraient être envoyées dans une classe à part.

Une fois le test écrit, on ajoute le code pour faire réussir le test. Il faut écrire le minimum de code pour faire fonctionner le test! Il fait combattre la tentation d'écrire du code en prévision de futures fonctionnalités. Une fois que le test passe avec le minimum de code, on passe à l'étape de refactoring. On examine le code écrit jusqu'à maintenant et on corrige les code smells, ces indicateurs que quelque chose ne va pas dans le code. Duplication, méthodes trop longues, classes trop dépendantes, tout doit y passer. Et comme on a nos tests comme filet de sécurité, on n'a pas à craindre de perdre certaines fonctionnalités. Une autre chose que j'ai trouvé aussi très
révélatrice, c'est qu'on doit se rappeler que le code de test doit lui aussi passer par la moulinette du refactoring! Ce code doit lui aussi être exempt de code smell! C'est un point important pour que les tests restent pertinents et facile à faire suivre à mesure qu'on ajoute de nouvelles fonctionnalités aux classes.

Donc pour ceux qui, comme moi, pensent qu'ils peuvent s'améliorer dans la pratique du TDD, jetez un coup d'oeil au chapitre 2 de Test Driven. Il aborde les bases du TDD et donne une bonne idée des étapes en pratique.

Le Dernier discours

2009-03-28T07:18:00.004-04:00

Comme plusieurs, j'avais entendu parler de Randy Paush et de son Dernier discours l'année dernière. Pour ceux qui ne le connaissent pas, il était professeur à l'université américaine Carnegie Mellon. Il enseignait l'informatique, plus précisément dans le domaine de la réalité virtuelle. Randy est décédé l'été dernier des suites d'un cancer.

J'ai finalement pris le temps de visionner le Dernier discours. Dans celui-ci, Randy Paush nous explique comment il a réalisé ses rêves d'enfants et comment il a travaillé à aider d'autres à réaliser les leurs également. Loin d'être déprimé par la fatalité de son état (qu'il connaissait au moment de prononcer ce discours), il nous décrit avec enthousiasme et humour les événements importants de sa vie. Au travers son histoire, il nous partage ses valeurs, axées sur l'ardeur au travail, l'intégrité et l'optimisme. « On ne peut changer les cartes qui nous sont données, juste la façon dont on va les jouer », telle est sa maxime. Il nous partage aussi sa passion pour l'enseignement et sa carrière universitaire.

Le livre, que je l'ai lu la semaine passée, est une extension du discours. Randy élabore davantage sur les anecdotes racontées lors de ce dernier. Il prend aussi le temps de nous parler de sa famille (il était père de 3 jeunes enfants). Il nous enjoint une leçon importante: apprécier la vie et chaque instant de celle-ci. Elle peut être courte ou longue, on ne sait jamais. Il nous exhorte aussi à apprécier les gens qui nous entourent et à trouver ce qu'il y a de bien dans chacun, même si c'est parfois plus difficile avec certaines personnes!

Donc un livre émouvant, mais bien écrit, qui fait beaucoup réfléchir.

Mes 3 outils de l'heure

2009-03-20T13:09:00.003-04:00

Je considère que de bons outils informatiques adaptés à vos besoins sont essentiels pour être productif si vous passez vos journées à travailler avec un ordinateur. J'ai décidé de partager 3 des outils qui me sont le plus utiles dernièrement.

Evernote

En début d'année, Google a annoncé qu'il stoppait le développement du produit Google Notebook. J'utilisais ce produit depuis environ 2 ans, mais pas de façon exclusive: je sauvegardais encore des notes directement sur mon poste ou sur Google Docs. J'ai donc commencé à chercher un remplaçant. J'ai découvert Evernote grâce à Lifehacker et j'ai été immédiatement accroché! L'application web est excellente, mais c'est l'application PC que j'utilise la majorité du temps. On peut y ajouter des notes directement à partir du presse-papier ou d'une page web. Toutes les notes sont indexées ce qui rend les recherches très rapides. On peut ajouter des tags à chaque note pour une meilleure classification. Mais surtout, ce sont les raccourcis clavier que je considère très pratiques. Grâce à eux, de n'importe quelle application, on peut rapidement envoyer du contenu vers Evernote. D'autres fonctionnalités sont à signaler comme un module de capture d'écran permettant de sélectionner facilement des portions de l'écran à envoyer vers le presse-papier, un fichier ou, évidemment, Evernote. Il y a aussi un OCR qui est automatiquement exécuté quand on insère une note avec une image, permettant ainsi de retrouver du texte dans les images. Finalement, l'aspect que je trouve le plus important est que mes notes sont accessibles partout. Quand on utilise l'application PC, les notes sont automatiquement synchronisées, ce qui les rend disponibles sur tous les PC que j'utilise. Il y a une version payante qui offre davantage d'options, mais la version gratuite me convient très bien jusqu'à maintenant.

CLCL

CLCL est un outil qui me permet de sauvegarder plus d'un élément à la fois dans le presse-papier. Ça peut paraître banal, mais je ne peux plus m'en passer! Par exemple, si je dois faire du copier-coller de plusieurs éléments, au lieu de me promener continuellement entre la source et la destination, je vais une fois à la source copier tous les éléments que j'ai besoin, et quand je retourne à l'application où je veux coller, tout est dans le presse-papier. Aussi, ça me permet de rendre des valeurs que je colle fréquemment toujours disponibles. Je considère que c'est une des applications qui me fait gagner le plus de temps durant une journée de travail.

Launchy

Un autre outil dont je ne peux absolument plus me passer! Launchy est un petit programme permettant de démarrer d'autres applications. On appuie sur Alt+Espace (configurable) et une petite boîte apparaît qui permet d'écrire le nom de l'application que l'on veut démarrer. Mais en fait, pas besoin de taper le nom au complet, car dès que Launchy comprend quelle application vous voulez (souvent après seulement une lettre), l'icône de l'application apparaît à la droite de la boîte. À ce moment, vous pouvez appuyer sur Enter et le programme sera lancé. C'est fou le temps qu'on sauve ainsi! Je me suis débarrassé de ma liste d'icônes en bas de l'écran, ce qui sauve aussi de l'espace. On peut également passer des paramètres au programme à exécuter. Launchy permet aussi de faire des recherches sur Google (ou un autre moteur de recherche). En effet, si vous tapez du texte que Launchy ne peut associer à un nom de programme, au moment où vous appuyez sur Enter, Launchy va lancer votre navigateur avec le texte de la boîte en recherche sur Google. On peut aussi s'en servir comme calculatrice et pour chercher des mots dans un dictionnaire. Plus besoin maintenant de quitter les mains du clavier pour prendre la souris quand on veut démarrer une application!

N'hésitez-pas à me faire part de vos outils favoris si vous le voulez!

Un peu de fiction cette année...

2009-03-11T21:50:00.002-04:00

Je dois avouer que je ne suis pas un grand lecteur de fiction (pas dans le sens de science-fiction mais dans le sens de fictif). Adolescent, j'en lisais beaucoup, mais depuis quelques années, j'ai préféré lire des livres de type documentaire (en anglais non-fiction). Mais après avoir lu, à quelques reprises, des remarques à propos de l'intérêt de lire davantage de fiction, je me suis fixé l'objectif d'en lire un peu plus cette année.

Donc comme premier roman de l'année, j'ai lu L'homme qui rétrécit de Richard Matheson. Je suis tombé sur ce livre un peu par hasard à la bibliothèque, ayant été intrigué par la quatrième de couverture. Après quelques recherches, je me suis aperçu que ce livre est un classique de science-fiction et son auteur est un des très prolifiques du genre. Un film basé sur le livre a même été fait dans les années 50.

En gros, j'ai bien aimé le livre. L'intrigue est bien faite et le style est tout à fait intéressant. L'idée d'un homme qui rétrécit jusqu'à devenir de la taille d'une araignée est assez originale! De plus, le livre aborde les thèmes de la survie quotidienne et de l'attente de la mort avec des idées qui porte à réfléchir. Une de ces idées est que la vie nous réserve toujours des surprises, malgré les changements inévitables qu'elle apporte.

Pas mal pour mon premier roman de l'année!

Unicode et encodages

2009-03-06T15:23:00.004-05:00

Pour mon projet courant, je dois gérer des fichiers qui ont différents formats d'encodage. Ça m'a permis de me rendre compte que je ne comprenais pas très bien les notions d'encodage et d'Unicode. J'ai donc pris du temps pour mieux comprendre le tout, et j'ai fini par me dire pourquoi pas ne pas en faire profiter d'autres!

Unicode

Le principe d'Unicode est de définir un index pour chaque charactère possible et imaginable (appelé des code points), mais pas de définir comment ceux-ci seront représentés (encodés) par un ordinateur.

Avec les premières versions d'Unicode, on pouvait représenter tous les charactères sur 2 bytes. D'où l'idée répandue que c'est un format de 2 bytes. Mais le standard a évolué depuis et maintenant, 2 bytes ne sont plus suffisants pour représenter tous les caractères.

Encodages

L'encodage ANSI est un encodage 8 bits (1 byte) de Microsoft. Il est basé sur ASCII pour les 127 premiers charactères et définit des caractères pour les langues occidentales pour les caractères 128 à 255. On appelle aussi cet encodage Windows-1252 ou CP1252.

L'encodage ISO-8859-1 est aussi un encodage 8 bits. Comme ANSI, il est basé sur ASCII pour les 127 premiers charactères et définit des caractères pour les langues occidentales pour les caractères 128 à 255. Il est très semblable à ANSI pour les caractères 128 à 255, mais il y a des différences (voir "ISO-8859-1 and Windows-1252 confusion" sur cette page).

UTF-8 est un encodage qui s'adpate en utilisant de 1 à 4 bytes selon le caractère. Il peut encoder tous les caractères Unicode. Un des avantages de cet encodage est que, si on n'utilise que des caractères ASCII, tous les caractères n'utiliseront qu'un 1 byte ce qui permet à de vieux programmes qui ne manipulent que des caractères ASCII de 1 byte de continuer à fonctionner.

UCS-2 est un format d'encodage 16 bits (2 bytes). Il supporte la majorité des caractères Unicode, mais pas tous car il n'utilise jamais plus de 16 bits pour un caractère.

UTF-16 est aussi un format d'encodage 16 bits (2 bytes). Mais contrairement à UCS-2, il peut représenter des caractères sur 32 bits (4 bytes) au besoin pour encoder tous les caractère Unicode.

Et Java?

Pour la classe String, avant la version 5, Java, ne pouvait représenter que les caractères Unicode pouvant tenir sur 16 bits (comme UCS-2). Mais depuis la version 5, on peut utiliser tous les caractères Unicode, qui seront encodés en UTF-16. (voir javadoc de la classe java.lang.Character).

Références

BetterExplained
JoelOnSoftware
dmiessler

Le retour des tables!

2009-02-05T12:18:00.004-05:00

Dans le monde du développement web, le message véhiculé depuis quelques années est que, pour la mise en page d'un site, les tables sont diaboliques (rien de moins!) et qu'on devrait toujours utiliser le combo div + CSS. Mais voilà, depuis quelques semaines sur dzone, plusieurs articles ont paru qui proposent de recommencer à utiliser les tables HTML. Certains ne se gênent pas pour dénoncer ce "dogmatisme" et revenir à une attitude plus pragmatique dans ce domaine. Voici quelques-uns de ces articles:

Everything you know about CSS is wrong - tables are the future
Tables vs CSS: CSS Trolls begone
The Cult of DIV
Why CSS should not be used for layout

Si vous allez sur dzone, vous en trouverez d'autres. Mais aussi, vous trouverez d'autres articles qui défendent le point de vue des "puristes".

À mon avis, ce qui est important, c'est de bien comprendre le pour et le contre de chacune des deux méthodes. Des fois, il est probablement exagéré de vouloir absolument éviter les tables, quand il est évident que ça rendra le travail plus facile et moins coûteux en temps. Mais dans d'autes, il ne faudra pas avoir peur de se retrousser les manches et d'utiliser l'approche div+CSS, qui est parfois, on doit l'admettre, plus complexe.

Et aussi, il faut éviter le dogmatisme. Dans le monde du développement informatique (comme dans beaucoup de domaines de la vie), l'équilibre a toujours bien meilleur goût!

Wikipedia songe à instaurer un système éditorial

2009-01-25T09:26:00.003-05:00

Cet article de cnet rapporte que le fondateur de Wikipedia songe à instaurer un système de révision éditorial pour la célèbre encyclopédie en ligne.

Ce système ferait en sorte que les mofications apportées à certains articles seraient révisées par des usagers de confiance avant d'être visibles.

Personnellement, je suis en faveur d'un tel système, mais seulement pour un petit nombre d'articles. La qualité de l'encyclopédie me pousse à dire que le système actuel est probablement toujours bon pour la majorité des articles.

Papa 24/7

2009-01-20T12:36:00.000-05:00

J'ai beaucoup ri en lisant Papa 24/7 de Martin Larocque. Ce dernier nous fait découvrir des anecdotes et des observations tirées de sa vie de papa. Divisé en petits chapitres, ce livre se lit comme du bonbon!

Martin Larocque ne s'en cache pas: il fait parti de cette nouvelle génération de père engagé revendiquant le droit de s'occuper eux aussi de leurs petits. Père de trois garçons, l'auteur écrit avec sensibilité, humour et intelligence à propos de ce métier qu'est la paternité.

Étant moi-même nouveau papa, je me suis reconnu dans quelques situations décrites dans ce livre (mes tout-petits sont encore jeunes: ça ne fait seulement que commencer dans mon cas!)

À lire pour les papas... et les mamans aussi!

Warcraft

2009-01-12T09:02:00.003-05:00

En fin de semaine, je suis tombé sur un remake flash du bon vieux Warcraft 1! De bons souvenirs!

Yes my lord!

L'univers sur un tee-shirt

2009-01-09T08:31:00.004-05:00

Pendant mon congé, j'ai lu Tout l'univers sur un tee-shirt – À la recherche d'une « Théorie du tout ».

Cet ouvrage du journaliste Dan Falk retrace 2500 ans de recherches et d'explorations, depuis l'époque des Grecs à nos jours, pour expliquer la nature de notre univers. Le livre insiste sur le désir qu'ont eu tous les acteurs de cette quête pour expliquer le plus simplement et le plus globalement le fonctionnement de l'univers. Chaque grande étape de ce périple, gravitation universelle, relativité générale, théories quantiques, tend vers une théorie unifiée – une théorie du tout – qui expliquera peut-être un jour tous les phénomènes de la physique dans un même cadre.

Depuis l'atome de Démocrite au chat de Schrödinger, en passant par la pomme de Newton, l'auteur prend la peine d'expliquer sommairement les grandes découvertes qui ont marqué cette recherche. On a même droit à une introduction à la théorie des cordes dans un des derniers chapitres.

On sent que l'auteur, qui a gagné plusieurs prix au cours de sa carrière de journaliste scientifique, a bien fait ses devoirs pour s'assurer de l'exactitude de ses explications. Il a interviewé plusieurs grands scientifiques actuels, certains encore très impliqués dans la recherche, pour réaliser ce livre.

Donc, un bon livre comme introduction aux grandes théories de la physique.

Problème de Monty Hall

2009-01-07T12:29:00.003-05:00

J'ai regardé hier le film 21. Dans une scène de ce film, Ben se fait poser un problème de math par son prof durant un cours. Il lui demande de choisir parmi 3 portes. Derrière l'une d'elle se trouve une voiture à gagner alors que derrière les 2 autres il y a des chèvres (pourquoi des chèvres? l'histoire ne le dit pas!).

Ben choisit donc la première porte. Son prof, qui sait derrière quelle porte se trouve la voiture, lui annonce que derrière la porte 3, il y a une chèvre. Il lui demande donc s'il désire changer son choix et prendre la porte 2 ou bien conserver son choix initial. Ben annonce qu'il veut la porte 2, car il y a 2 chances sur 3 que la voiture soit derrière cette porte, contre 1 sur 3 pour la première. Et il gagne! La voiture est bien derrière la porte 2. Et son prof lui confirme qu'effectivement, il y avait 2 chances sur 3 pour que cette porte soit la bonne!

J'ai été intrigué par ce problème. Ma première impression fût que quelque chose n'allait pas. Pourquoi, une fois la porte 3 éliminée, les 2 portes restantes n'avaient pas des chances égales d'être la bonne? En fouillant sur le web, j'ai découvert que ce problème est un classique: c'est le problème de Monty Hall. Ce problème en intrigue plus d'un! Et comme moi, plusieurs ont longtemps pensé que les 2 portes restantes avaient autant de chance d'avoir la voiture derrière elle. Pourtant, il est maintenant prouvé mathématiquement que la porte 2 a bel et bien plus de chance d'être la bonne! Pour vous en convaincre, regardez les schémas présentés sur la page Wikipedia du problème.

Ce problème montre avec éloquence que parfois, notre intuition n'est pas un bon juge de la réalité.

De retour!

2009-01-07T08:27:00.002-05:00

Mon voilà de retour! J'ai été en congé de paternité les deux derniers mois suite à la naissance de ma fille Amélia. J'ai vraiment décroché durant ce congé! Mais malheureusement, ce blog en a souffert.

Donc je vais tenter de me reprendre au cours de la prochaine année. Mon objectif est de publier un peu plus souvent, mais avec des billets un peu plus court.

Au plaisir!

Réviser les notions de base

2008-11-11T08:19:00.015-05:00

Dans le dernier billet de ma série Comment rester à jour pour les développeurs, j'aborde l'importance de bien maîtriser les notions de base.

On entend souvent qu'il est important de rester à jour par rapport aux nouveautés. C'est indéniable. Par contre, je trouve qu'on néglige parfois de s'assurer qu'on maîtrise toujours bien les aspects élémentaires pour un développeur. Avec le temps, certaines des notions de base se perdent à cause d'habitudes qu'on a prises dans le passé. On finit par faire certaines choses machinalement, sans trop se rappeler pourquoi.

On pourrait discuter longuement de plusieurs de ces notions de base, mais dans ce billet, je vais me concentrer sur deux aspects: les structures de données de bases, ainsi que les particularités des plates-formes de développement.

Structures de données de base

Les structures de données sont parmi les premières choses que les futurs développeurs apprennent dans les cours de Programmation 101! Et pour cause: ce sont les éléments de base pour le traitement de l'information.

Les structures de données élémentaires sont les tableaux, les tableaux dynamiques, les listes chaînées et les tables de hachage. Il y en a bien sûr plusieurs autres, mais ce sont les plus courantes. Pour chacune de ces structures, il est important de bien connaître leurs particularités respectives ainsi que de savoir dans quel contexte elles doivent être utilisées. Pour chacune des situations suivantes, essayer de déterminer laquelle des structures est la plus appropriée:

1. Vous devez faire des insertions à différents endroits de la structure.
2. Vous devez faire des accès directs à des éléments de la structure.
3. Vous devez conserver l'ordre des éléments dans la structure.
4. Vous devez associer chaque élément de la structure avec une clé.

Ces situations ne sont pas que théoriques. Ce sont des situations que les développeurs rencontrent fréquemment dans leur travail de tous les jours. Mais si on a pris l'habitude, par exemple, de toujours utiliser un tableau dans toutes les situations, il est clair qu'on utilise pas toujours le meilleur outil disponible.

Un tableau est une zone de mémoire continue et de taille fixe. Il est facile d'y récupérer directement un élément (#2). Le tableau dynamique est une structure semblable à un tableau, mais dans laquelle on peut insérer de nouveaux éléments, car la taille du tableau dynamique peut varier. La liste chaînée est une structure où chaque élément maintient un pointeur vers l'élément suivant (et précédent dans le cas d'une liste doublement chaînée). Il est aisé d'y insérer un élément à n'importe quel endroit de la structure, car il suffit seulement de changer les pointeurs (#1 et 3). Finalement, la table de hachage associe à chaque élément une clé unique qui permet de le récupérer sans parcourir la structure (#4).

La notation grand O, utilisée en théorie de la complexité, permet de définir un ordre de grandeur pour les opérations sur les structures de données.

Structure	Accès direct	Insertion/suppression à la fin	Insertion/suppression au milieu
Tableau	O(1)	n/a *	n/a *
Tableau dynamique	O(1)	O(1)	O(n)
Liste chaînée	O(n)	O(1)	O(1)
Table de hachage	O(1)	n/a **	n/a **

(*) Dans un tableau, comme la taille est fixe, on ne peut faire d'insertion ou de suppression.
(**) Dans une table de hachage, c'est la structure qui gère l'emplacement des éléments.

La notation O(1) signifie que l'opération s'effectue en temps constant. La notation O(n) signifie que la performance de l'opération est proportionnelle au nombre d'éléments dans la structure. Ainsi, une opération en temps O(1) s'effectue plus rapidement qu'une opération en temps O(n). Bien sûr, pour des petits nombres d'éléments, c'est négligeable. Mais si vous devez gérer un grand nombre d'éléments, il est important d'avoir constamment ces notions à l'esprit.

En Java, la classe ArrayList est un tableau dynamique, la classe LinkedList est une liste doublement chaînée et la classe HashMap est une table de hachage. Il existe d'autres classes qui implémentent ces mêmes structures, mais ces classes sont très souvent utilisées.

Les particularités des plates-formes de développement

Que ce soit .NET, Ruby, Java ou une autre, chaque plate-forme de développement possède ses particularités que tous les développeurs travaillant avec elles doivent bien connaître. Ces particularités sont souvent là pour des raisons toutes à fait uniques à la plate-forme, mais elles sont très importantes à connaître pour être efficace. Souvent, ces particularités imposent des façons de travailler qui deviennent finalement des habitudes. Et après, on peut finir par oublier pourquoi on a ses habitudes. D'où l'importance de s'assurer de réviser au besoin le détail de ces particularités.

Par exemple, pour la plate-forme Java, vérifier si vous comprenez les particularités suivantes:

* Quelle est la différence entre une exception déclarée (checked exception) et une exception à l'exécution (runtime exception)?
* Pourquoi les méthodes destroy, resume, stop et suspend de la classe Thread ont-elles été marquées comme désuètes (deprecated), c'est-à-dire qu'on doit éviter de les utiliser?
* Pourquoi ne peut-on pas hériter de la classe String et qu'est-ce que cela a comme conséquence?
* Quelle est la différence entre les classes Hashtable et HashMap ou entre Vector et ArrayList?
* Dans quels cas doit-on définir les méthodes equals et hashCode pour un Java Bean?

L'important, ce n'est pas nécessairement de connaître dans le détail absolu ces particularités, mais d'en savoir assez pour faire de bons choix.

Il est donc important de prendre du temps pour réviser les notions de base. Il faut éviter de faire des choses seulement par habitude. Il suffit parfois seulement de quelques minutes sur Google pour réviser et rester à jour!

La réalité est-elle toujours calculable?

2008-11-04T15:41:00.003-05:00

Je suis en train de lire le numéro de juillet de Science & Vie et j'ai trouvé très intéressant l'article "Ce qu'on ne peut calculer est-il encore réel?'. Cet article rapporte un article du physicien Scott Aaronson qui postule que si un modèle proposé pour expliquer un phénomène naturel ne peut être calculé dans un délai "raisonnable" par un ordinateur, c'est qu'il est forcément faux!

Par exemple, en biologie, on explique le fonctionnement des protéines en proposant un modèle où elles se configurent de façon aléatoire avant de s'arrêter à une configuration stable (je suis loin d'être un connaisseur!). Selon Aaronson, ce modèle est invraisemblable car même un hypothétique ordinateur quantique ne pourrait reproduire ce modèle à cause du trop grand nombre de combinaisons à effectuer.

Cet article fait référence à plusieurs notions de la théorie de la complexité. Un bon rappel de ces notions peut être trouvé sur le site du cours INF 6460.

La Révolution Wikipédia

2008-10-30T23:42:00.002-04:00

Comme beaucoup, je consulte Wikipédia régulièrement. Je suis fasciné par ce que des personnes d'un peu partout dans le monde et de façon tout à fait bénévole ont pu accomplir! Par contre, certaines personnes soulèvent la question à savoir si on peut vraiment considérer Wikipédia comme une source fiable d'information. Comment peut-on se fier à une encyclopédie où tout un chacun peut à volonté changer n'importe quoi? C'est la question que se sont posées 5 étudiants français dans le cadre de leur dernière année d'études en journalisme. Ils ont publié les résultats de leur recherche dans le livre La Révolution Wikipédia.

Le livre débute par la préface d'un de leur professeur à L'École de journalisme de Sciences-Po à Paris, Pierre Assouline. Le moins que l'on puisse dire, c'est que ce professeur ne porte pas Wikipédia dans son coeur! Ce dernier explique comment toute une nouvelle génération d'étudiants consulte et cite Wikipédia sans prendre la peine de valider à d'autres sources l'information qu'ils y puisent. Ce professeur reproche aussi à Wikipédia d'être un outil de désinformation, car plusieurs groupes de personnes avec des intentions douteuses peuvent utiliser l'encyclopédie en ligne pour y diffuser leur message.

Les 5 étudiants portent un jugement plus équilibré sur Wikipédia. Ils commencent par nous rappeler la fameuse étude de la revue Nature où, en 2005, cette dernière publiait que Wikipédia est aussi fiable que la vénérable encyclopédie Britannica! Plusieurs personnes ont utilisé (et encore beaucoup aujourd'hui) cette étude pour affirmer que Wikipédia a passé le test de la fiabilité et qu'on peut maintenant s'attendre à la mort prochaine des encyclopédies classiques! Ces étudiants nous montrent que c'est une conclusion tout à fait erronée. Ils prennent le temps de décortiquer la méthodologie de Nature pour cette fameuse étude pour nous faire voir qu'en réalité, l'étude prouve plutôt que Wikipédia est moins fiable que Britannica!

On nous explique ensuite les mécanismes que Wikipédia utilise pour s'assurer de la qualité des articles qu'elle contient. Tout en reconnaissant que ces mécanismes ont bien fonctionné jusqu'à maintenant, les auteurs expliquent que ceux-ci sont beaucoup plus efficaces sur des sujets où il y a peu de controverses, comme les mathématiques, la physique ou l'informatique. Par contre, avec des sujets historiques, politiques ou religieux, c'est beaucoup moins efficace. Les consensus sont souvent difficiles à établir, ce qui oblige souvent les administrateurs de l'encyclopédie à intervenir.

À la fin, ces étudiants nous amènent à réaliser ceci: de toute façon, Wikipédia est là pour rester. Ce qu'il faut, c'est apprendre à s'en servir de façon intelligente. L'esprit critique reste encore et toujours une qualité indispensable pour utiliser cette nouvelle source d'information. Les étudiants (et les autres aussi) doivent absolument prendre le temps d'aller à d'autres sources pour comparer. Ils conseillent également de prendre le temps d'apprendre à contribuer à Wikipédia pour mieux comprendre son fonctionnement et l'enrichir!

Je considère donc ce livre comme un bon rappel. Loin de nous décourager à consulter la célèbre encyclopédie, il nous incite simplement à la prudence, ce qui est toujours un bon conseil!

Wikinomics

2008-10-18T10:23:00.003-04:00

Le livre Wikinomics: How Mass Collaboration Changes Everything explique en quoi les nouvelles technologies de l'information bouleversent la façon de gérer une entreprise. Selon les auteurs, nous vivons une époque charnière. Internet a complètement changé la façon dont les gens communiquent entre eux. L'information circule plus rapidement que jamais. Mais la tendance la plus révolutionnaire, c'est le pouvoir que ces nouvelles technologies de l'information donnent aux gens ordinaires. Aujourd'hui, les gens peuvent produire eux-mêmes l'information. Plusieurs de ces personnes créatrices d'information se réunissent en communauté. Et ces communautés font trembler mêmes les plus grandes et puissantes entreprises. Car là où ses compagnies régnaient autrefois en maître absolu, ces nouvelles communautés y prennent de plus en plus d'espace. De plus, la nouvelle génération, qui maîtrise ces nouvelles technologies comme les précédentes ont maîtrisé la télévision, va faire accélérer ces tendances.

Ce livre est donc une sorte de mise en garde pour les entreprises: coopérer ou périr. Selon les auteurs, les entreprises qui auront le plus de succès dans l'avenir seront celles qui sauront coopérer avec diverses communautés et exploiter leur potentiel. Le livre s'ouvre sur l'exemple de Goldcorp, une petite compagnie minière de l'Ontario. Cette dernière était dans une impasse: elle n'était plus en mesure de trouver de l'or dans sa mine de Red Lake dans le nord de l'Ontario. Pourtant ses géologues avaient plusieurs indices leur indiquant que d'importante quantité d'or devait encore s'y trouver. Mais voilà, après plusieurs millions investis, aucun résultat probant. La compagnie était au bord de la crise. Le nouveau CEO de l'entreprise prit alors une décision tout à fait inusitée: il demanda aux géologues de l'entreprises de mettre toutes les données à propos de la mine disponible sur Internet en offrant à ceux qui pourraient les aider à trouver l'or une récompense de 575 000$. Ils reçurent des idées de divers groupes de personnes: géologues bien sûr, mais aussi mathématiciens, physiciens, militaires, étudiants et informaticiens. Plusieurs de ces idées étaient tout à fait novatrices. Résulat: l'or fut trouvé. Et Goldcorp est passé d'une entreprise valant environ 100 millions à une valant aujourd'hui 9 milliards de dollars. Et la mine de Red Lake produit toujours.

Le coeur du livre contient sept façons dont les entreprises peuvent tirer profit de ces nouveaux outils de communication et ces nouvelles communautés d'utilisateurs. Les entreprises qui sauront exploiter ces nouvelles réalités seront les mieux placées pour réussir dans les années à venir.

D'après les auteurs, même les travailleurs vont être touchés par ces changements. Ces derniers devront être polyvalents, prêts à collaborer avec des ressources à l'extérieur de l'entreprise et surtout, savoir utiliser les nouveaux outils de collaboration.

Donc, un livre très intéressant détaillé avec beaucoup de faits vécus et de statistiques révélatrices. Je le recommande à ceux qui s'intéressent au mariage de l'économie et des nouvelles technologies.

Apprendre en s'amusant!

2008-10-04T10:02:00.008-04:00

La meilleure façon d'apprendre un nouveau langage de programmation ou pour se perfectionner est de se pratiquer. Mais voilà, souvent (dans mon cas), ce n'est pas toujours évident de trouver des idées de bout de code à écrire assez diversifiées pour être vraiment efficace pour apprendre. J'ai remarqué que de se tourner vers des problèmes à résoudre est souvent une bonne façon de s'y prendre.

Au cours des dernières années, je me suis amusé à résoudre des problèmes provenant principalement de deux sites: Ruby Quiz et Project Euler. Le premier, comme son nom l'indique, est constitué de problèmes surtout de programmation avec des solutions en Ruby. Mais rien n'empêche de les résoudre en utilisant un autre langage! L'auteur du site a même fait un livre avec certains des meilleurs problèmes. Le deuxième contient surtout des problèmes de maths. Un problème est soumis et pour prouver qu'on l'a résolu, on doit fournir la réponse (souvent numérique) au problème. Une fois résolu, on a accès à un forum dédié au problème où d'autres soumettent et discutent les différentes solutions. On peut utiliser le langage de son choix. Voici quelques problèmes que j'ai trouvé intéressants à résoudre:

Je vous invite à parcourir la liste des problèmes de ces deux sites. Vous y trouverez sûrement des problèmes intéressants.

Connaissez-vous d'autres sites intéressants où des problèmes semblables sont soumis?

The Productive Programmer

2008-09-27T07:53:00.006-04:00

Comme je vous en avais parlé dans un précédent billet, j'ai lu le livre The Productive Programmer de Neal Ford.

Ce livre est le fruit de l'expérience pratique de l'auteur. Il nous révèle ses trucs et astuces pour devenir un programmeur productif.

Son livre est divisé en deux parties. La première traite des différents outils à la disposition des programmeurs pour effectuer leur travail. Pour l'auteur, un programmeur productif utilise toujours le meilleur outil possible pour la tâche à accomplir. Il rappelle l'importance de trouver des outils nous permettant d'automatiser les tâches répétitives car ces dernières sont souvent, à la longue, celles qui font perdre le plus de temps et qui sont la cause de beaucoup d'erreurs d'inattention. Vous devez interagir avec votre système d'exploitation? Développez des scripts Bash ou Power Shell. Vous devez manipuler des fichiers? Utilisez un langage dynamique comme Ruby ou Groovy. Vous devez rechercher du texte dans des fichiers de log? Apprenez à maîtriser les expressions régulières. Avec de nombreux exemples, Ford nous démontre les avantages à utiliser ces outils.

Il prend le temps de partager certains des outils qu'il utilise pour lui permettre de travailler plus rapidement: presse-papiers multiple, éditeurs textes, engins de recherche, bureaux virtuels et autres.

Dans la deuxième partie du livre, l'auteur s'attarde aux bonnes pratiques de développement logiciel qu'un programmeur productif doit maîtriser. Cette section couvre assez sommairement une grande quantité de pratiques: les tests unitaires, l'analyse statique du code, la méta-programmation et j'en passe! Chaque chapitre de cette deuxième partie est un condensé des avantages de chacune de ces bonnes pratiques. C'est évident que, comme chacune de ses pratiques ont des livres entiers qui leur sont consacrées, vous devrez voir ailleurs pour des approfondissements. Mais ces chapitres constituent tout de même une bonne introduction (ou un bon rappel). J'ai beaucoup aimé le chapitre consacré aux programmeurs polyglottes.

L'auteur nous encourage à visiter le site du livre, où il compte continuer d'ajouter d'autres façons d'être des programmeurs productifs!

La pratique pour rester à jour

2008-09-20T10:11:00.024-04:00

Les expérimentations avec certaines technologies permettent d'aller chercher une connaissance pratique. Évidemment, ça ne peut remplacer dans votre cv une véritable expérience de travail. Mais ces connaissances vont vous permettre d'être compétitifs par rapport à d'autres développeurs qui n'ont pas pris le temps d'expérimenter avec ces technologies. Dans d'autres cas, elles vous permettent de découvrir de nouveaux outils ou de nouvelles méthodes qui servent à vous rendre plus efficaces dans vos tâches quotidiennes.

Tutoriels

Les tutoriels sont intéressants car ils permettent rapidement d'aborder une technologie sans investir (habituellement) beaucoup de temps. Beaucoup peuvent se compléter en une heure ou deux. Et ce qui est bien, c'est que la plupart sautent rapidement de la théorie à la pratique. En suivant les instructions, on est amené à jouer avec la technologie, ce qui est souvent plus motivant que de lire un long exposé théorique. Un autre avantage non négligeable: la très grande majorité des tutoriels sont gratuits!

En voici quelques uns que j'ai récemment lus:

Livres d'introduction

Comme mentionné dans un précédent billet de cette série, beaucoup de livres sont des introductions à une technologie. Bien que je trouve que ce genre de livre est rapidement désuet, ils sont souvent plus détaillés et vont plus loin qu'un simple tutoriel. Comme les tutoriels, ces livres vont rapidement à la pratique. La meilleure façon d'en profiter est de faire les exercices à mesure qu'on en fait la lecture. Certains vont apprécier pouvoir retourner plus tard feuilleter ces livres pour se replonger dans une technologie. Et si le livre aborde une technologie (ou une version d'une technologie) plus ancienne, on peut souvent avoir ces livres à rabais.

Quelques livres d'introduction intéressants:

Cours en ligne

Un nouveau phénomène intéressant pour apprendre de nouvelles technologies ou méthodologies est que plusieurs universités mettent en ligne le contenu de certains cours. On peut ainsi “suivre” le cours, comme si on y était inscrit! J'aime beaucoup l'approche d'un cours. Quelqu'un a fait l'effort d'approfondir un sujet, d'en dégager des points importants et de nous proposer un cheminement pour le comprendre. Si on réussit à se procurer le manuel du cours et si on prend le temps de faire les exercices on peut en retirer beaucoup.

Quelques cours que j'ai commencé à "suivre":

Langage de programmation

Le livre Pragmatic Programmer conseille d'apprendre un nouveau langage de programmation par année! Et ce n'est certainement pas le choix qui manque. Tous les ans, de nouveaux langages font leur apparition. Et c'est sans parler de tous ces vieux langages toujours utilisés par beaucoup de développeurs mais ignorés par la grande majorité. Au cours des dernières années, les langages dynamiques attirent beaucoup l'attention. Que ce soit Ruby, Groovy ou Python tous ces langages possèdent une quantité impressionnante de documentation pour vous permettre de devenir familier avec eux.

Pourquoi ce conseil d'apprendre un nouveau langage par année? Il est très probable que beaucoup de ces langages ne deviendront pas le prochain Java ou C#. Mais la raison est que de connaître de nouveaux langages vous exposent à de nouvelles façons de régler les problèmes que celles typiquement proposées par le langage que vous utilisez régulièrement. Découvrir ces nouvelles façons de faire vous rendent plus efficaces car vous aurez une vision plus large de ces problèmes. De plus, vous pourrez utiliser ces autres langages pour certaines de vos tâches secondaires. Par exemple, pourquoi ne pas utiliser Groovy pour écrire vos tests unitaires? Ruby pour manipuler ces gros fichiers de logs? PHP pour vous bâtir une application web de test? Beaucoup de ces langages excellent à ces tâches pour lesquelles ont perd souvent un temps fou en s'obstinant à utiliser le langage dans lequel on est familier mais souvent moins adapté. Selon beaucoup, comme Neal Ford et Ola Bini, l'avenir est aux programmeurs “polyglottes” qui seront capables d'utiliser simultanément plusieurs langages à la fois. L'avenir nous dira s'ils ont raison!

Faites-nous part de vos suggestions et expériences pour pratiquer avec les nouvelles technologies!

Rencontres de développeurs

2008-09-12T19:39:00.011-04:00

Dans cet autre billet de ma série Comment rester à jour pour les développeurs, j'aborde la question des rencontres organisées pour les développeurs.

Les rencontres organisées pour la présentation de nouvelles technologies sont souvent bien intéressantes pour rester à jour. Elles permettent de rencontrer d'autres développeurs. En prenant le temps de leur parler, ou seulement en écoutant les conversations, on peut découvrir quelles technologies ou méthodologies les autres développeurs de notre région utilisent. Ça aide à savoir où on se situe dans nos connaissances et pratiques par rapport au marché.

On peut aussi avoir l'occasion de rencontrer des développeurs réputés. Lors d'une rencontre du GUJMTL, Neal Ford est venu faire une présentation sur comment améliorer son écriture de code. Ça avait été très intéressant!

Les présentations elles-mêmes permettent de découvrir rapidement de nouvelles technologies. Certains diront que souvent, un bon livre ou un tutoriel sur le web pour remplacer ce genre de présentation. Ce n'est pas faux. Mais le fait d'entendre comment d'autres utilisent une technologie peut être utile. On peut aussi poser des questions de vive voix.

Également, si vous avez envie de faire découvrir des technologies aux autres, ces groupes sont très ouverts à laisser de nouveaux présentateurs se lancer. Ça peut être une excellente façon de parfaire vos talents d'orateurs!

Dans la région de Montréal, pour un développeur Java, il y a le GUJMTL. Il y a aussi, pour ceux qui s'intéressent aux développement web avec Ruby On Rails, le groupe Montreal On Rails, qui se réunit régulièrement depuis 1 an. Leur prochaine rencontre aura lieu mardi prochain et portera sur les outils ruby autres que Rails.

MISE À JOUR: j'ai trouvé un groupe pour les développeurs Python.

Connaissez-vous d'autres groupes de développeurs dans la grande région de Montréal?

Lectures de développeurs

2008-09-07T09:00:00.018-04:00

Il existe plusieurs sortes de livres disponibles pour les développeurs. Il y a les livres de référence très proche d'une version en particulier d'un logiciel ou d'un api. Il y a les livres tutoriels qui prennent la peine de vous expliquer étape par étape comment utiliser une technologie. Il y a les livres d'introduction qui brossent un portrait global d'une technologie.

On peut lire ces types de livres assez rapidement. Il faut se rappeler que ce ne sont pas des romans. Il n'y a rien de mal à sauter des chapitres qui nous semblent moins pertients.

Enfin, il y a les livres que j'appelle les livres de "principes". Ils ont pour but d'expliquer les bonnes pratiques à l'utilisation d'une technologie ou de certains aspects du métier de développeur. Cette catégorie de livre est ma préférée et celle parmi lequel je crois que vous devriez vous attardez davantage. Contrairement aux autres livres où après une lecture on n'a plus vraiment intérêt à y revenir (à part bien sûr les livres de référence), ces livres peuvent être relus sans problème. De plus, ils demeurent pertinents beaucoup plus longtemps. Quelques exemples classiques: Design Patterns, The Pragmatic Programmer (un de mes préférés), Code Complete, Effective Java, Expert One-On-One J2EE Development Without Ejb (le livre qui a fait découvrir Spring), Refactoring et plusieurs autres. Vous êtez invités à me rapporter vos classiques favoris dans les commentaires de ce billet.

Ces livres sont ceux qui vont le plus influencer votre pratique du métier! Ce sont eux qui vont vous permettre de vous tenir à jour au niveau des bonnes pratiques.

Où trouver les livres?

Il est évident que la façon la plus simple de se procurer les livres est d'aller en librarie, soit avec pignon sur rue ou en ligne. Mais le prix pour se procurer plusieurs ouvrages grimpe très rapidement. Il existe quelques façons de trouver de bons livres sans débourser autant. Les librairies en ligne comme Amazon et Chapters offrent la possibilité d'acheter des livres usagés, ce qui permet d'économiser beaucoup. De plus, Amazon ne fait pas payer la taxe dans le cas des livres usagés. J'aime bien aussi le site Lulu, qui permet aux auteurs de vous offrir leurs livres pour souvent bien moins chers.

La bonne vieille bibliothèque est aussi un bon endroit. Les bibliothèques de petites municipalités n'ont souvent pas un choix intéressant. Par contre, si vous habitez à Montréal ou y allez souvent, la Grande Bibliothèque est tout indiquée. J'y vais régulièrement et je suis toujours surpris de voir la grande quantité de livre d'informatique disponible. C'est vrai que vous n'y trouverez probablement pas les livres du mois, mais on y retrouve plusieurs livres qui ont de six mois à un an.

Déterminer si ce livre est un bon achat

Il est frustrant de se retrouver avec un navet, surtout quand on a payé le gros prix. La façon que je préfère pour déterminer si un livre en vaut la peine est d'aller lire les critiques d'autres lecteurs sur Amazon. Il est mieux d'aller lire les critiques sur amazon.com même si vous achetez du site amazon.ca car il y a beaucoup plus de gens qui écrivent des critiques sur le site américain. Pour les livres en français, faites un tour sur amazon.fr. Ne regardez pas seulement le nombre d'étoiles. Prenez le temps de lire les critiques pour vous donner une idée du contenu et des forces et faiblesses rapportés par les lecteurs.

Une autre façon de déterminer si un livre est intéressant est de faire le tour des blogs d'autres développeurs qui prennent le temps de faire des recommandations de livres. Par exemple, cette semaine j'ai lu un billet favorable à propos du livre Behind Closed Doors: Secrets of Great Management qui a piqué mon intérêt.

Aussi, n'oubliez-pas que la plupart des grands éditeurs offrent des chapitres gratuits sur le web. Ça donne une bonne idée du ton du livre. On peut retrouver facilement ces chapitres gratuits à l'aide du site PDFoo.

Il est important pour les développeurs de prendre le temps de lire quelques livres reliés aux technologies. Peu importe le domaine d'expertise, il y a sûrement une bonne quantité de livre disponible pour se perfectionner. Ça peut être aussi une façon de se familiariser avec des technologies un peu à l'écart de son domaine d'expertise. Les livres permettent souvent d'aller plus loin que la lecture d'articles pour la compréhension d'une technologie.

Cette semaine je débute la lecture de The Productive Programmer de Neal Ford. Je vous en donne des nouvelles une fois achevée.

Bonne lecture!

Les éclaireurs

2008-09-03T19:15:00.010-04:00

Mon premier billet de la série Comment rester à jour va porter sur mes méthodes pour faire de la veille technologique. Qui sont mes éclaireurs?

Dzone

Le site dzone me permet rapidement de prendre le poul de l'actualité et des dernières tendances dans le monde du développement. Je peux constater l'arrivée de nouveaux frameworks, de nouvelles librairies et des derniers acronymes! Je prends le temps de lire certains articles soumis, mais généralement, je fais seulement passer par dessus les titres. Si je constate qu'un sujet revient régulièrement et que j'ignore en grande partie de quoi il s'agit, je m'efforce de l'approfondir un peu. Je commence généralement par faire un tour sur Wikipedia voir de quoi il retourne, puis je vais sur les sites principaux en rapport avec le sujet. Je retourne ensuite sur dzone lire un ou deux articles sur le sujet. Il se peut que je lise certains articles en diagonale, mon objectif à ce stade est de construire une connaissance générale du sujet, pas de devenir un expert.

La blogosphère

Je surveille les blogs de quelques développeurs réputés. J'aime bien suivre ce genre de blogs car l'aspect plus personnel qui s'en dégage m'aide à faire des rapprochements avec mon quotidien de développeur.

Voici quelques-uns des développeurs que je lis fréquemment:

Charles Nutter: développeur principal de JRuby chez Sun
Ola Bini: consultant chez ThoughtWorks , très technique, mais bien expliqué et varié
Neal Ford: autre consultant ThoughtWorks , un touche-à-tout et excellent communicateur
Jeff Atwood: développeur .NET, très sharp
Neal Gafter: un gourou Java, anciennement de Sun mais maintenant chez Google. Il est derrière BGGA, une des spécifications proposées pour intégrer les closures dans java 7

Votre sélection variera selon vos domaines d'expertises. Dans mon cas, comme vous le remarquez, la mienne contient principalement des blogs de développeurs Java.

Je considère ces développeurs parmi les meilleurs dans mon domaine: leur avis et opinions sont souvent de bons indicateurs des bonnes pratiques et technologies que les développeurs devraient au minimum connaître. Ces développeurs m'ont particulièrement aidé à non seulement rester à jour en apprenant à connaître les nouveautés, mais aussi en m'assurant que je maîtrise toujours bien les connaissances de base que tout bon développeur doit bien comprendre (cet aspect fera l'objet d'un futur billet dans cette série). Cela dit, il m'est très fréquent de lire certains de leurs billets en diagonale si je les juge moins pertinents pour moi. L'important est de dégager ce que je peux apprendre d'eux pour rester à jour, pas de lire religieusement tous leurs billets.

Fils RSS

Un outil particulièrement utile pour faire de la veille sans perdre un temps fou à visiter chaque site individuellement est un bon lecteur rss. Tous les sites et blogs que je surveille offrent un fils rss qui permet à ces logiciels d'aller récupérer automatiquement les derniers billets de chacun d'eux et de les afficher dans l'interface du logiciel. Ça permet de sauver un temps fou. Il existe plusieurs logiciels qui font ce travail. Celui que j'utilise est Google Reader. Pourquoi? Il est accessible en ligne. Donc pas de perte de temps à chaque fois que je change d'ordinateur à reconfigurer tous les nouveaux fils ajoutés sur une autre machine. Google Reader permet d'organiser chaque fils en groupe par un système de tags. Il permet de mettre une étoile à certains billets pour permettre de les retrouver facilement.

Derniers conseils

Un conseil à l'utilisation d'un lecteur rss: faites régulièrement le ménage parmi les fils que vous suivez. S'il y en a que vous ne trouvez plus pertinents, soyez prompts à les supprimer. Essayer de suivre trop de fils à la fois devient nuisible car vous risquez de vous décourager.

Un autre conseil plus général au sujet de la lecture d'articles et de billets en ligne: n'hésitez-pas à interrompre la lecture de l'un d'entre eux si vous n'y voyez pas d'intérêt. Combattez la tendance à vouloir lire jusqu'au bout pour rien. Vous épargnerez ainsi temps et énergie.

Finalement, il faut essayer de se fixer un moment précis et un temps limité pour faire de la veille. Par exemple, une heure le mercredi soir et une autre le samedi matin. N'en faites pas trop à la fois, vous n'en retirerez pas grand-chose.

Et vous, quelles méthodes utilisez-vous pour faire votre veille?