Espace de programmation

Ma façon de travailler sous Windows XP avec Eclipse sur un 20" (1600x1200) :

• code formaté à 80 caractères ; pour les scripts, 72 est un meilleur compromis encore.
• police ProFont Windows 8pt.
• le maximum d'espace vertical pour le code. L'idée étant évidemment de pouvoir visualiser les algorithmes d'un seul coup d'œil. Si chaque méthode entre dans l'écran, c'est bon. Avec cette config je dispose de 96 lignes pour bosser.
• oui, sur l'image du dessus, tout le code est bien contenu en largeur dans la colonne centrale.
• je gagne encore en verticalité en mettant la Barre des tâches sur un côté plutôt qu'en bas de l'écran.
  

Certes, comparé au regretté CodeWarrior sous Mac, c'est loin d'être la panacée. En particulier pour du multi-fenêtrage je dois utiliser des outils tiers. Mais ça permet d'avancer.

Maintenant, comment certains programmeurs utilisent le même IDE et le même écran :

• code sans limite horizontale. C'est plus lisible, paraît-il. Même quand ça déborde à droite de la zone visible ? Il se trouve que c'est le cas sur l'image : il va falloir faire défiler la ligne pour lire trois pauvres bouts de code.
  
• police Courier New 10pt
• la console qui mange le bas de l'écran. Bien large la console, pour lire les StackTraces. Important, les StackTraces.
• l'espace vertical restant est pour le code. C'est-à-dire 32 lignes sur un 20". Wow! Ne demandez pas pourquoi on rogne votre budget, vu comment vous utilisez les outils de base.
  

Pour conclure, deux questions pour savoir si votre setup est convenable :

• avez-vous du plaisir à travailler ?
• avez-vous pris le temps de réfléchir à d'autres possibles configurations ?
  

Et sur la question du plaisir pris à travailler. Certes non, une bonne configuration d'un IDE ne procure pas automatiquement une ineffable joie de vivre. En revanche, si de toute façon vous n'êtes pas content de bosser, aucune configuration d'Eclipse ne conviendra :-)

Génération internet 2.0

Employers Are Viewing Your Profile on Social Networking Sites

C'est un fait. Dans la communication, l'informatique, mais aussi le management, les petits jeunes qui chercheront du travail dans les 10 prochaines années auront déjà tenu un blog ainsi qu'un espace public Facebook / MySpace. Ils auront l'habitude d'utiliser Google et Wikipedia pour aller chercher des informations qui leur manquent, et d'utiliser la messagerie instantanée (IM ou IRC) et les discussions différées (blogs ou forums), bref, l'intelligence de groupe, pour s'aider à faire des choix et prendre des décisions. Ils auront peut-être même pris l'habitude de contribuer eux-mêmes à des silos de connaissances, sur divers sujets, avec des wikis par exemple.

Et leurs employeurs pressentis pourront eux aussi faire une recherche Google sur leur nom. Et ainsi apprendre éventuellement que tel candidat fumait tant de joints dix ans auparavant, écoutait telle musique (c'était à l'époque où le téléchargement était interdit, rappelez-vous : les années 2000), affirmait telles choses. D'ici-là il est possible que les étudiants aient appris, au fur et à mesure que s'approche le moment de chercher un emploi ou des clients, de ne plus laisser traîner sur internet n'importe quelle histoire sur leur compte, et que les seules données «confidentielles» qui aient fui soient déjà vieilles d'un ou deux ans.

Mais quel est le risque ? Est-ce que le patron risque de ne pas embaucher un étudiant à cause de ce qu'il aura découvert sur son profil Facebook ? C'est le sens de l'article que j'ai mis en lien plus haut. Dans ce cas... qui y perd réellement ? L'ex-étudiant, bien sûr, pour qui le chemin de l'embauche peut être plus difficile qu'avant. Mais on ne voit pas pourquoi il ne trouverait pas un travail au final, puisqu'ils seront majoritaires dans son secteur à avoir fait la même chose, à savoir laisser des traces de leur vie sur internet.

Non. À mon sens, celui qui y perd fondamentalement, c'est le patron, ou plutôt son entreprise. Parce que les temps changent. Et qu'un futur travailleur qui sait déjà communiquer de façon fluide avec son entourage notamment grâce aux outils à sa disposition, qui a déjà montré qu'il pouvait donner plus d'information qu'attendu (certes, il faudra peut-être recadrer. So, what?), représente une valeur interne pour l'entreprise.

Donc la question qu'on peut poser à l'étudiant blackboulé est celle-ci : souhaitez-vous vraiment travailler pour une entreprise qui de facto n'est pas adaptée aux méthodes classiques de communication ? (modernes en 2000, classiques en 2010. Selon les secteurs, of course)

De là à se retrouver en slip sur son profil Facebook, évidemment...

Référencement web de nos sites

Tel le Petit Poucet moyen, laisse-t-on suffisamment de traces sur le web pour que les zamis-zet-les-contacts puissent nous retrouver ?

Si sur le web on fait...	on obtient...
Google.com, «David Andriana», «I'm Feeling Lucky»	mon profil sur WikiPatterns, site d'Atlassian sur lequel je m'étais inscrit, à propos de patterns d'utilisation et surtout de mise en œuvre des wikis
Google.fr, «David Andriana», «J'ai de la chance»	un vague message d'avril dernier, par votre serviteur sur le forum de Mobiles Sans Gêne
Google.com, «Andrianavalontsalama», «I'm Feeling Lucky»	la page d'accueil de mes anciens sites personnels, pas mis à jour depuis 2003
Google.fr, «Andrianavalontsalama», «J'ai de la chance»
Google.com, «Je Fûte», «I'm Feeling Lucky»	l'article de ce blog sur les plateformes applicatives
Google.fr, «Je Fûte», «J'ai de la chance»
Google.com, «Avantage Compris», «I'm Feeling Lucky»	la page «À propos» du site Avantage Compris
Google.fr, «Avantage Compris», «J'ai de la chance»

Je retiens donc les éléments suivants...

• pour avoir son nom référencé chez Google, il suffit de ne pas avoir un nom trop courant (Andrianavalontsalama, anyone?), et d'apparaître dans un site à forte fréquentation. WikiPatterns compte 574 utilisateurs enregistrés, et est abondamment visité.
• pour avoir son site référencé chez Google, il suffit d'apparaître dans un blog visible (oui, oui, le blog de quelqu'un d'autre. Dingue) et d'y laisser des liens
  
• pour avoir son blog référencé chez Google, il suffit de l'héberger chez Google :-) (Blogger/blospot.com)
  
• pas besoin d'activité régulière sur ces divers points
• pas besoin d'avoir des tétrachiées de commentaires, ni d'avoir des liens sortants (le site d'Avantage Compris a une page de contact très simple, et rigoureusement aucun lien sortant)
  
• la présence dans les bases de données de réseautage social (Viadeo par exemple) n'apporte pas grand-chose non plus

Bien sûr, l'objectif recherché est de pouvoir être retrouvé : la visibilité de l'adresse e-mail suffit. S'il s'était agi de garantir l'accès à un blog, par exemple, l'état du référencement décrit ci-dessus n'aurait pas été suffisant.

Il aurait alors fallu, à partir de la liste décrite ci-dessus, mettre à jour les liens des pages les unes vers les autres, et... «consolider la nébuleuse» :-)

IoC par annotations : Guice

Je me mets sérieusement aux annotations Java 5. Les liens entre la génération de code et les annotations me semblant clairs désormais, il est temps de passer à l'utilisation frénétique des annotations et de profiter enfin des facilités de refactoring offertes par les IDEs. C'est un argument pour positionner Java, et non plus XML, comme format source du processus de développement (oui, oui, même si on doit ensuite produire du PHP).

Les candidats pour de l'IoC via les annotations sont à ma connaissance : Guice 1.0 et Spring 2.1 (pas encore sorti).

Le binding nommé est une des fonctionnalités de base que j'attends de tels frameworks. Le moins qu'on puisse dire c'est qu'avec Guice ce n'est pas immédiat.

On s'en sort avec... une indirection ;-)

Wikis publics chez Sun

Lu chez Padawan, Sun déploie des wikis publics.

Ils utilisent Confluence.

Plom, plom, plom...

Télétravail

Je finis à l'instant une séance de travail à deux, assez intensive, sur du développement Java. C'est banal aujourd'hui, bien sûr. On a dans cette séance utilisé les sempiternels wikis et messageries instantanées. On a bien sûr utilisé un gestionnaire de configuration pour le code, et un serveur d'intégration continue. Et à part ça, pas de téléphone, pas de caméra, pas d'e-mail. On peut dire qu'on est davantage dans la gestion asynchrone du temps (car on utilise par exemple le texte plutôt que la vidéo), et la capitalisation des échanges, que dans l'échange lui-même.

Là où j'ai été le plus attentif, c'est sur la qualité des idées amenées : dans quel sens joue la distance, c'est-à-dire plus exactement le fait de ne pas se trouver physiquement dans la même pièce ?
Quand je lis un article comme It Turns Out Brainstorming Has NEVER Worked — qui pointe par ailleurs l'excellent blog de Marc Andreessen, ainsi que l'étude initiale, étude qui a découvert que des personnes amenées à réfléchir en présence ensemble pouvaient être moins créatives que quand elles réfléchissaient d'abord voire exclusivement chacune de leur côté sur leur sujet commun —, j'essaie de mesurer l'avantage de cette situation.
Et j'ai l'impression qu'il est immense.

D'abord, c'est à chacun de décider s'il souhaite être interrompu. Le flow peut ainsi exister librement. C'est une pratique d'autant plus complète quand chacun essaie d'appliquer l'adage «Achieve greatness fifteen minutes at a time» (voir par ici : How to Work Like the Masters). Toutes les 20 minutes environ, on est lancés sur une tâche individuelle, et en général on arrive à quelque chose. Grand ou petit, on a quelque chose. On valide dans la foulée.

Ensuite, c'est la capitalisation. Parce que les échanges sont écrits, la pensée est formalisée. Et parce qu'ils se font par le biais de systèmes informatiques, ils sont stockés, indexés, archivés, pour être ensuite accessibles, copié/collables, modifiables.

Pourtant, il reste évident que le brainstorming, et le travail en équipe, ont une valeur intrinsèque, un je-ne-sais-quoi qui ne peut pas se retrouver dans une routine de collaboration à distance. L'écoute, et donc le partage du même temps, c'est important.

Et donc par balancier... c'est la parole qui est retrouvée quand on est ensemble :-)