La couleur préférée optimale

Quelle est ta couleur préférée? Question si commune pourtant si vide de sens. Existe-t-il autre réponse à cette question qu’une variable aléatoire dont la valeur change avec le temps? En 2009, la couleur préférée d’une personne sera le rouge et ça deviendra peut-être le jaune en 2011.

Je me suis alors demandé ceci. Quand la couleur n’a que peu d’importance pour moi, y aurait-il moyen de formuler une réponse sensée, objective, à cette question supposément si simple?

Eh bien ma première tentative fut de dire que c’était le BLANC, parce que le blanc regroupe TOUTES les couleurs du spectre électromagnétique. Quoi de plus riche et intéressant qu’une couleur qui les unit toutes! Mais sur le papier, le blanc est l’absence de couleur, le manque d’inspiration, le vide. En peinture et en photographie, c’est le NOIR qui contient toutes les couleurs. Alors avec le blanc, je serai une personne riche aux yeux des éclairagistes et des artistes de la scène, adeptes de la synthèse additive, mais passerai pour une coquille vide aux yeux des artistes. L’inverse se produira avec le noir. De plus, le noir ou le blanc, c’est la saturation, la quantité plutôt que la qualité, l’absence de véritable contenu. Alors si j’opte pour l’une d’elles, cela montre que je suis une personne superficielle.

Alors, ne pourrais-je pas établir un compromis en optant pour le GRIS? Le gris, en effet, est la médiane entre le noir et le blanc: ni trop riche en couleurs diverses, ni atteint de cette absence totale de couleurs qui rend tout stérile. Mais alors, suis-je un décis, incapable de pencher vers le blanc ou vers le noir? Peut-être bien.

Ou bien dois-je y aller en fonction de ma personnalité? Si je suis d’un tempérament stressé, devrais-je opter pour le rouge afin de le dénoter, puisque le rouge est une couleur chaude? Ou bien devrais choisir le bleu, une couleur froide, pour montrer que j’aspire au calme et à la sérénité? Et le vert dans tout ça, qu’en faire? Si je le prends, puis-je le faire parce signifier que j’aime le contact avec la nature? Peut-être bien. Alors, rouge, vert ou bleu? Sais plus!

Bon et il y a les couleurs de base de la synthèse soustractive à considérer. Comment faire pour choisir entre le jaune, le magenta ou le cyan? Bon sang que je ne sais pas!

Alors peut-être la réponse est ceci: signifier mon eccentricité en choisissant une couleur qui n’a pas de nom!!! Je prendrais, par exemple, une combinaison linéaire arbitraire de rouge, vert et bleu, tiens disons 45% de bleu, 25% de rouge et 30% de vert. Mais si je prends des parts trop égales, je me retrouve avec du gris et montre le fait que je suis indécis, incapable de choisir!

Alors peut-être serais-je mieux avec une couleur qui évoque de beaux souvenirs, comme le beige qui me fait penser à la chatte Kitkat de mes parents. Oui oui, mais dans quelques années, Kitkat ne sera plus de ce monde et le beige évoquera son décès, un triste événement que j’aurai certes envie d’oublier.

Alors, ce n’est pas noir, ce n’est pas blanc, ce n’est même pas gris, ce n’est pas rouge, ce n’est pas vert, ce n’est pas bleu, on ne sait pas si c’est jaune, magenta, cyan, et c’est peut-être beige, pour le moment. Oui, ce sera ça, ma réponse!

Groovy? Pas sûr…

Hier, je me suis dit que ça vaudrait la peine d’essayer d’utiliser le langage de programmation Groovy pour un projet chez Nuance. J’estime que cela va me permettre de générer et manipuler du XML plus facilement et m’éviter de répétitives constructions. Plutôt qu’écrire du code pour effectuer la même opération sur chaque item d’une liste, classifier des items selon certains critères afin de pouvoir appliquer un traitement spécifique à chaque classe d’items, ouvrir des fichiers, etc., je pourrai me concentrer davantage sur la logique du programme et éviter de perdre plein de temps à écrire de la poutine répétitive et déboguer. Eh bien pour le moment, c’est exactement tout le contraire! Voici pourquoi.

  • Cette journée a mal commencé avec un problème de connexion de mon écran. Mon laptop de Nuance est relié chez moi à mon écran par un adaptateur mini-HDMI vers HDMI, un fil HDMI qui va dans un commutateur HDMI, puis un fil HDMI vers DVI qui va dans l’écran. Eh bien je n’avais plus d’image. Pourtant, mon ordinateur personnel, lui aussi raccordé au commutateur et allumé pour des raisons qui importent peu ici, affichait le bureau d’Ubuntu. C’est arrivé à quelques reprises et j’ai dû débrancher et rebrancher le câble mini-HDMI. Eh bien en vain cette fois. Cela a fini par fonctionner en essayant avec un autre adaptateur mini-HDMI! Je ne sais pas encore si c’est vraiment l’adaptateur, car mon Raspberry Pi a aussi, hier soir, refusé d’afficher en HDMI. C’est donc peut-être le foutu commutateur si bien qu’il faudrait idéalement que je remplace mon écran par un doté de plusieurs entrées HDMI. Mais les écrans d’ordinateur ont pour la plupart une seule entrée DVI ou HDMI.
  • L’installation de mon environnement Groovy a posé des difficultés. Je n’ai eu aucun mal à installer Groovy lui-même, à mettre en place le plugin Groovy pour Eclipse, mais après, les problèmes ont commencé. Je me suis vite rendu compte qu’il valait mieux créer un nouveau projet distinct dans Eclipse pour cette nouvelle tâche, pas seulement pour éviter d’introduire des difficultés dans les builds à cause de Groovy mais aussi par souci de séparation correcte du code. Sans cela, Eclipse indiquait que le compilateur Groovy du projet, dicté par le fichier POM de Maven, ne correspondait pas au compilateur utilisé par défaut dans Eclipse. Il fallait alors modifier les propriétés du build, dans Eclipse, et il n’y avait pas de synchronisation avec le fichier POM de Maven, donc modifier le fichier POM risquait de nécessiter de refaire le paramétrage du build, et toute personne désireuse de consulter mon code dans Eclipse aurait elle aussi à paramétrer le build.
  • Trouver comment configurer mon fichier POM pour que Maven puisse gérer mon satané projet Groovy n’a pas été une mince affaire. Le plugin GMaven qui semblait devoir faire ce travail est discontinué, sans aucune alternative convainquante pour le remplacer! Le seul candidat est un plugin Groovy-Eclipse-Compiler qui me semble un joli hack utilisant le compilateur d’Eclipse en arrière-plan pour compiler du Groovy! Mais bon, c’est tout ce qu’on a alors on essaie. Eh bien il me fallut copier/coller plusieurs blocs de code dans mon fichier POM et ça ne fonctionnait même pas pour les raisons suivantes!
  • Eclipse s’est d’abord plaint qu’il y avait deux installations de Groovy dans le classpath. J’ai dû exclure celle en provenance d’un projet dépendant; c’était la 1.8 et je voulais partir avec la 2.0. Après, eh bien encore cette erreur de correspondance du compilateur: mon projet voulait Groovy 2.1, Eclipse avait la 2.0! Il m’a fallu utiliser une version antérieure de Groovy-Eclipse-Compiler, et trouver le bon numéro de version a demandé des recherches à plus finir.
  • Après tous ces efforts, eh bien Eclipse est devenu affreusement lent et gelait à tout bout de champ. Cela a fini par des erreurs à propos de mémoire insuffisante puis un plantage. Par chance, le comportement était plus normal après le redémarrage d’Eclipse.
  • Ensuite, le développement a véritablement commencé. D’abord, le plugin Groovy d’Eclipse souffre de problèmes lorsque vient le temps de proposer des noms de classes, méthodes et propriétés. Parfois, il trouve un nom, parfois pas, et c’est très arbitraire. Par exemple, j’avais une variable de type String (chaîne de caractères), et Groovy avait l’information à propos du type (à noter que ce n’est pas toujours le cas vu la nature dynamique de Groovy). Eh bien Eclipse localisait la méthode toLowerCase() mais pas toUpperCase()! La complétion de noms de classes fonctionnait parfois, mais elle n’ajoutait pas toujours l’importation nécessaire si bien qu’après coup, j’avais des erreurs indiquant que la classe récemment référencée n’était pas trouvable, devais sélectionner sa référence et appuyer sur CTRL-SHIFT-M pour ajouter l’importation. Ça fonctionnait parfois, parfois pas, il fallait alors appuyer plusieurs fois!
  • D’autres difficultés surgirent en raison de ma connaissance embryonnaire du langage Groovy. Par exemple, je me suis emmêlé les pinceux avec la notation pour construire un tableau associatif. Il ne faut pas utiliser [a:b, c:d]; ça ne va pas fonctionner, le compilateur va se plaindre de l’absence des variables b et d. Il faut plutôt utiliser [a: »b », c: »d »] ou encore [« a »: »b », « c »: »d »]. Mais pourtant, GroovySH va bêtement afficher [a:b, c:d] si on lui demande de montrer le tableau! Déclarer une variable de type List<?> ne fonctionnait pas: il fallait que j’utilise simplement List; en Java, cela déclenche un avertissement comme quoi c’est un type brut. Mais si je déclarais List[] ou List<?>[], eh bien j’avais un avertissement à propos du type brut! Il faut utiliser des listes au lieu des tableaux ou bien ne pas déclarer de type du tout. Mais je trouve ça plus clair de donner le type, surtout pour les arguments d’une fonction!
  • J’ai été bien choqué quand j’ai voulu créer une classe avec des champs et y générer des accesseurs, car la fonction d’Eclipse pour le faire n’était pas disponible en Groovy. Je me suis alors rappelé qu’il existe des annotations pour indiquer à Groovy de générer ces accesseurs automatiquement. Eh bien je n’arrivais pas à retrouver ces annotations dans la documentation et des recherches sur Internet me donnèrent à des indices pour bâtir une transformation d’AST personnalisée permettant de le faire!!! Bon sang! Par chance, il suffisait de déclarer mes champs sans modificateur d’accès pour que Groovy ait l’intelligence de les traiter comme des propriétés et alors définir les accesseurs.
  • Outre les problèmes syntaxiques, il y a aussi eu des difficultés d’API. Jusqu’à ce que je trouve la documentation du GDK, indiquant quelles méthodes Groovy ajoute à Java, je n’arrivais pas à savoir facilement comment appliquer une transformation sur tous les items d’une liste (collect peut le faire), s’il était possible d’ouvrir un fichier texte en UTF-8 avec un seul appel de méthode plutôt que construire le FileInputStream, puis le InputStreamReader, et enfin le BufferedReader, etc..
  • J’ai aussi eu des difficultés avec le débogueur qui s’est remis à se plaindre chaque fois que je définissais un point d’arrêt conditionnel. J’avais beau vérifier et revérifier l’expression de la condition, tout était OK. Pourtant, j’avais cette maudite erreur. J’ai encore été obligé de modifier le code temporairement après quoi le point d’arrêt fonctionnait, mais Eclipse n’arrivait pas à trouver le code source de la classe, dans un projet importé par dépendance Maven qui était pourtant dans mon espace de travail Eclipse! Il m’a fallu indiquer l’emplacement explicitement puis j’ai enfin pu déboguer le code. C’est possible que ce soit ça qui ait brisé les points d’arrêt conditionnels.
  • J’ai eu des erreurs d’exécution à la pelle! Le code compilait, semblait beau, mais à l’exécution, j’avais des problèmes à propos de méthodes ou de propriétés inexistantes. Cette fois-ci, ce n’était pas Groovy, ni Maven, ni Eclipse mais bien mon code; il fallait corriger les petites erreurs. Certaines erreurs ont été difficiles à corriger, surtout celles qui ont surgi quand je me suis mis à utiliser le MarkupBuilder de façon un peu exotique pour construire mon XML de façon dynamique. Oh là là! La documentation de Groovy n’explique pas très bien comment fonctionne le builder; c’est un fichier en progression. Mais pourquoi placer une page sur un site web pour simplement écrire, pendant deux ans, work in progress ou coming soon? Je ne me souviens plus exactement d’où j’ai eu les indices pour comprendre ce qui se passe, peut-être dans le chapitre sur les DSL de Groovy in Action. Le problème ici était que mon fichier XML n’était pas statique: je devais générer un élément <task> pour chaque tâche de mon application et y injecter des attributs au besoin, pas toujours tous les attributs! Par chance, la chose a été possible et peut être étendue pratiquement à l’infini.

En bref, quelle galère! On se demandera si tout ceci a valu le coup. Je me le demande moi aussi. Je pense que l’apprentissage de Groovy aura une utilité si bien que je prévois continuer cette exploration. Je ne saurais pour le moment mesurer la contribution exacte de Groovy, Eclipse et Maven dans cette expérience plutôt déplaisante.

Il faut garder à l’esprit que j’ai eu beaucoup de difficultés avec Eclipse, incluant des problèmes avec la complétion de noms de classes et de méthodes, les points d’arrêt conditionnels qui boguent parfois mais au moins pas de plantages, pas sous Windows en tout cas. Sous Linux, j’en ai déjà eu à plus finir. Pourtant, les alternatives à Eclipse sont plutôt limitées: NetBeans qui ne gère même pas bien le fichier POM de notre projet chez Nuance, IntelliJ dont la version gratuite est bridée (on ne sait JAMAIS quand on tombera sur un blocage demandant la version payante!!!) et puis les éditeurs de texte comme Notepad++, Emacs, Vi, etc. Ces éditeurs sont excellents, je ne peux que l’avouer, mais ils ne suffisent pas à la tâche pour gérer un gros projet Java ou Groovy avec plusieurs classes.

La vengeance des pingouins!

Hier à ma fête, j’ai eu plusieurs cadeaux de mon frère et sa blonde exploitant la thématique des pingouins, le symbole du système d’exploitation Linux. Eh bien faut croire que les pingouins n’ont pas beaucoup aimé (moi j’ai bien aimé, pourtant!), car ils se sont vengés hier soir et aujourd’hui. Voici comment, une vraie histoire d’horreur.

  • XBMC, mon lecteur multimédia sur mon HTPC Linux, a planté deux fois hier soir. Ça gelait et plus aucun contrôle ne répondait. Il fallait alors que je bascule sur la console texte et que je tue XBMC de façon brutale. En plus, la saisie de mon mot de passe trop complexe est devenu problématique, demandant entre trois et quatre essais chaque fois! J’ai fini par en mettre un plus simple, vraiment tanné de me faire embêter par ça!
  • Mon serveur de Minecraft, sous Linux, a eu des ratés parce que je pensais l’avoir mis à jour à FTB Unleashed 1.1.7 tandis qu’il exécutait toujours 1.1.3. Le client, désynchronisé, se plaignait, n’arrivant plus à établir la connexion vers le fabuleux univers de Taowa. Remettre la version recommandée ne produisait aucun effet, car il faut croire que le lanceur FTB conservait des parties de la nouvelle version plutôt que tout réinstaller.
  • FTB Launcher, le client me donnant accès à Taowa, il a fini par m’afficher un bel écran vide et plus rien ne fonctionnait. La touche ALT-F4, devenue pratiquement inopérante à présent, ne faisait plus rien encore une fois. Cliquer sur le X non plus, il fallait vraiment tuer le processus de force, encore. Ensuite, j’ai été obligé de tout réinstaller, en exécutant le lanceur dans un autre répertoire, et après, eh bien j’avais un écran noir à chaque démarrage de Minecraft. Ainsi, Ubuntu ne permet PLUS d’exécuter Minecraft, probablement encore une mise à jour qui a brisé le pipeline graphique. Ils ont brisé le pipeline pour la Intel HD4000, rendant le jeu saccadé pratiquement plus jouable, et voilà que c’est fait pour NVIDIA aussi. Faudra que j’endure ou tente ma chance avec une carte ATI, mais je n’ai rien à faire de plusieurs cartes graphiques PCI Express remisées pour incompatibilité arbitraire.
  • Une tentative d’installation de Linux Mint 16 édition Cinnamon en lieu et place de Ubuntu qui pose de plus en plus de difficultés aussi absurdes qu’imprévues a été une véritable catastrophe: pointeur de souris vraiment trop petit, options d’accessibilité pour agrandir les caractères ayant à peine un effet, l’interface graphique a gelé sans raison, me forçant à tout redémarrer, puis un plantage du programme d’installation au moment de marquer la partition principale de Mint pour formatage! Bref, ça ne fonctionne pas du tout! Le seul point positif est qu’aucune perte de données ou de configuration n’est à déplorer suite à ce court et désagréable essai, car le système n’a infligé aucun dommage à mes partitions.

On dirait bel et bien que Linux, désormais, est confiné aux machines virtuelles, aux serveurs sans écran (capacités graphiques instables) et aux appareils mobiles (genre Android). Il est possible que seules certaines cartes graphiques soient parfaitement prises en charge et que leur marque varie dans le temps.  Par contre, un problème de pilote graphique peut certes expliquer XBMC instable, Minecraft ne fonctionnant plus et le plantage de l’interface de Mint, mais pas la défaillance du programme d’installation de Mint.

Pour la défaillance de l’installeur de Mint, peut-être est-ce l’EFI, peut-être est-ce le SSD, peut-être est-ce le Ivy Bridge, peut-être n’est-ce rien de tout ça. Je ne sais pas et étant donné que l’interface de Mint m’a vraiment déplu, ça ne sert à rien de le savoir.

Les interfaces graphiques régressent, en plus. On assiste à une perte progressive de contrôle: plus moyen de changer la taille du pointeur de la souris (Ubuntu, Mint), plus moyen de grossir les caractères (Mac OS X, peut-être Mint), plus moyen de configurer les couleurs et la transparence (Windows 7+, probablement Mac OS X, peut-être même Ubuntu et Mint!).

Plutôt que travailler sur la personnalisation, eh bien les éditeurs de systèmes d’exploitation préfèrent rajouter davantage d’applications de base qui ne font rien et qui doivent, une par une, être substituées par des logiciels tiers. À quoi bon améliorer Paint si personne de sérieux ne s’en sert, le remplaçant par Paint.net, Gimp ou, « mieux » encore, par Photoshop? À quoi bon améliorer Wordpad si les gens le remplacent par Notepad++, Word ou, mieux encore, LibreOffice? Pourquoi améliorer Internet Explorer si personne ne s’en sert, le troquant pour Chrome ou Firefox?

L’utilisateur de Mac fera la même chose, troquant Mail pour l’interface web de GMail, plus flexible et plus portable. Il délaissera iMovie pour s’en aller vers Final Cut. Il abandonnera vite Garage Band pour le remplacer par Audacity ou un logiciel audio professionnel comme Pro Tools de Avid ou Live de Ableton. Puis un jour, il voudra essayer le dernier jeu et délaissera Mac OS X complètement pour balancer un Windows sur son beau MacBook flambant neuf. C’est triste!

L’utilisateur Linux, de son côté, remplacera progressivement les applications de GNOME ou de Unity par d’autres: Totem sera abandonné au profit de MPlayer, VLC ou XBMC, GEdit pour Vi ou Emacs, Banshee pour Audacious ou autre chose, etc. Au moins avec Ubuntu, on peut obtenir toutes ces alternatives depuis le gestionnaire de paquets: pas besoin de visiter des dizaines et des dizaines de sites (quoique Ninite peut beaucoup aider sous Windows!) et surtout, pas besoin de débourser un centime pour ces alternatives.

Mais il n’en demeure pas moins qu’à cause de l’intégration de tous ces petits jouets, le cœur même du système, ses fondements, sa flexibilité, en souffrent, parce que les éditeurs se concentrent sur la mauvaise cible.