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.
samedi 5 septembre 2009
samedi 25 juillet 2009
How to get ideas
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:
Je crois que tous devraient en bénéficier.
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!
Je crois que tous devraient en bénéficier.
mardi 19 mai 2009
Clean code
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é.
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é.
samedi 25 avril 2009
Pour l'amélioration de mes tests unitaires
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.
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.
samedi 28 mars 2009
Le Dernier discours
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.
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.
vendredi 20 mars 2009
Mes 3 outils de l'heure
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!
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!
mercredi 11 mars 2009
Un peu de fiction cette année...
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!
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!
vendredi 6 mars 2009
Unicode et encodages
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
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
jeudi 5 février 2009
Le retour des tables!
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!
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!
dimanche 25 janvier 2009
Wikipedia songe à instaurer un système éditorial
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.
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.
mardi 20 janvier 2009
Papa 24/7
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!
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!
lundi 12 janvier 2009
Warcraft
En fin de semaine, je suis tombé sur un remake flash du bon vieux Warcraft 1! De bons souvenirs!
Yes my lord!
Yes my lord!
vendredi 9 janvier 2009
L'univers sur un tee-shirt
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.
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.
mercredi 7 janvier 2009
Problème de Monty Hall
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é.
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!
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!
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!
mardi 11 novembre 2008
Réviser les notions de base
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.
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.
(*) 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.
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!
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 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!
mardi 4 novembre 2008
La réalité est-elle toujours calculable?
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.
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.
jeudi 30 octobre 2008
La Révolution Wikipédia
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!
samedi 18 octobre 2008
Wikinomics
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.
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.
samedi 4 octobre 2008
Apprendre en s'amusant!
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:
Connaissez-vous d'autres sites intéressants où des problèmes semblables sont soumis?
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:
- Écrire un compilateur de bytecode
- Convertir de la notation postfixée à infixée
- Écrire un parseur de JSON
- Trouver le 10001ème nombre premier
- Convertir en chiffres romains
- Écrire un algorithme pour résoudre les sodoku
Connaissez-vous d'autres sites intéressants où des problèmes semblables sont soumis?
