Il y a quelques années nous utilisions les disquettes pour échanger des fichiers. Quand la taille des fichiers a augmenté, nous avons découpé nos fichiers sur plusieurs disquettes. Puis la révolution du CD est arrivée suivi de son graveur. Nous pouvions alors mettre nos fichiers d’un seul bloc sur un support.
Quelques années plus tard, la clé USB a fait son apparition. Moins encombrante que le CD, elle permettait l’échange de fichier facilement et plus rapidement. La taille des clés continuant d’augmenter, la démocratisation des graveurs de DVD n’a pas permis de renverser cette situation. Le CD/DVD se retrouvant cantonné au rôle de support de sauvegarde (photos, musique..)
De nos jours, avec l’internet haut débit, les espaces de stockage offerts par les FAI, les sites comme Flickr ou Picassa, les supports optiques perdent leur rôle de sauvegarde, puisque les données sur le web ont le grand avantage d’être accessibles de partout. Certains sites proposent même des interfaces dédiées et évoluées pour vos téléphones (Google Docs..). Le déport de données vers « le cloud » va même plus loin, lorsque l’on voit l’intégration d’Android avec les solutions Google, ou le MobileMe d’Apple.

Que reste-t-il à nos supports optiques?
La possibilité de copier mes CD (quand ils ne sont pas protégés) pour les mettre dans la voiture? De plus en plus de voitures présentent des connecteurs USB ou iPod….
L’autre utilité des supports optiques reste l’installation de logiciel. Nous pouvons de plus en plus acheter nos logiciels en ligne, téléchargement, réception d’une licence par mail et c’est fini, il n’y a plus de boite et support physique. De plus à JavaOne 2009, SUN a annoncé un Java application Store en ligne, façon Appstore pour l’iPhone. Il y a des chances que l’idée fasse des petits, comme l’appstore qui se retrouve décliné sur les différents modèles de téléphones. Coté logiciel, il ne reste donc plus que l’installation de l’OS sur la machine.
La dernière utilisation est celle des films. Les box modernes proposent maintenant la VOD et les disques dur multimédias de salon remplacent avantageusement les collections de DVD et platine en proposant HDMI, sortie optique et autres types de connecteurs.

Alors où allons nous?

Lors de la dernière mise à jour de sa gamme de portable, Apple a intégré un lecteur de cartes SD. S’il est vrai que cela ne m’avait jamais manqué (j’utilise un adaptateur USB qui est dans la pochette de mon appareil), certains trouvaient que son absence était un scandale pour une machine de ce prix… Apple ajoute donc ce lecteur mais explique aussi sur son site comment faire une carte SD bootable.
De plus, beaucoup de gens ont trouvé aberrant l’absence de lecteur de DVD sur le MacBook Air lors de sa sortie. Apple propose une solution pour partager facilement les lecteurs à travers le réseau, la suppression du lecteur leurs a permis de réduire considérablement le taille de la machine.
Enfin, il n’y a toujours pas de lecteur Blue-Ray dans les iMac. En aura-t-on un jour? La longue guerre des industriels sur le format (HD-DVD versus Blue-Ray) n’a pas facilité la mise en place d’un nouveau standard. Même si le Blue-Ray a gagné, il peine toujours a envahir le marché.

En 1998, Apple avait défrayer les chroniques en sortant le premier iMac sans lecteur de disquette. Les autres ont depuis suivi le mouvement.
Et si nous avions içi aussi le prochain virage technologique : la disparition du lecteur de CD remplacé par le lecteur de SD card. Il est amusant d’ailleurs de noter le retour aux sources, la forme de la SD card rappelant celle de la disquette (certaines ont même le petit trucs à glisser pour la protection en écriture…). Les avantages sont qu’une SD card ne peut pas se rayer et qu’il n’y a pas de pièces en mouvement (et donc fragile ou consommatrice de batterie) dans un lecteur de SD card. Le seul inconvénient que je vois est que l’on perd plus facilement une SD card qu’un support optique.

La question, qui se pose alors, est : que ferons nous de toutes cette place gagnée dans nos ordinateur portable? Des machines plus petites? Plus de batterie? Une meilleure dissipation de la chaleur? J’aime bien l’idée de deux disques : un petit SSD pour l’OS et les applications, travaillant conjointement avec un plus gros classique pour les données. Je choisirai donc pour un mélange des trois : disques, chaleur et batterie.

Et vous, que ferez-vous de toute cette place gagnée?

La question du conseil à l’étudiant a été posés à quelques « stars » du développement Java. Parmi les conseils, j’en retiens principalement trois :
– pratiquer beaucoup (Joshua Bloch)
– apprendre à utiliser les outils, explorer des nouveaux outils (Tor Norbye, Arun Gupta)
– interagir avec des experts (Ben Galbraith)

Beaucoup considère la programmation comme un art, et alors, à moins d’avoir un génie naturel, il est effectivement nécessaire de pratiquer. Mais comme pour le piano, il faut commencer par faire les gammes avant d’attaquer les concertos. Il s’agit d’ailleurs du conseil de Masood Mortazavi : commencer simple et continuer à apprendre (je reviendrai sur ce dernier point dans un prochain billet). La pratique ne doit pas se limiter à des séries de copier-coller de codes pris à droite et gauche, mais il s’agit bien d’écrire notre propre code. Les étudiants qui sortent des écoles doivent se dire qu’ils ne savent pas encore programmer et s’attendre à écrire encore de nombreuses lignes de code. Faites juste le test d’ouvrir du code que vous avez écrit l’année dernière et regardez les progrès que vous avez fait.

L’apprentissage des outils est important aussi. Sur les 5 dernières années je considère que le meilleur IDE du marché est passé de JBuilder à Eclipse puis à NetBeans (il s’agit de mon historique du classement des meilleurs IDE gratuits, puisque tout le monde sait que le meilleur est IntelliJ ). L’IDE apporte beaucoup à la productivité des développeurs, mais il faut connaitre leurs possibilités, prendre le temps d’explorer les menus et tester leurs fonctions. Ces outils évoluent très vite. Il ne faut pas rester figé sur son choix mais tester régulièrement chacun de ce produits, accepter de chercher un peu les fonctions lors du changement.

Le dernier point est l’interaction avec les experts. Il n’est pas donné à tout le monde d’avoir un gourou technologique dans le bureau voisin. Si vous le pouvez, allez les écouter dans les conférences ou lors des réunions de JUG. Vous pouvez aussi en croiser quelques-uns qui sévissent sur les forums de Developpez. Pour ceux qui ne peuvent pas aller dans les conférences ou les JUG, il reste une solution qui est la lecture de code source. Les sources de la plupart des frameworks Java sont disponibles. Prenez le temps de lire ce code, le code du JDK…. Tous ces codes ne sont pas parfaits, mais si vous choisissez des projets avec de grandes équipes de développeurs, il y a de fortes chances que ces codes soient de grande qualité.

Pour revenir à la question du début, le conseil que je me donnerais, serait triple : pratique, teste et lis.

J’ajoute juste le lien vers l’article Javalobby où j’ai trouvé ces interviews, pour les quelques conseils présents dans les commentaires.

L’auteur passe en revue ce qui pourrait améliorer la motivation des développeurs.
Pour résumer, il présente en quatre points avec :

• La compensation (poste et salaire)
• supprimer ou réduire les aspects démotivants (spécifications vagues, deadline intenable, réunionite aigüe, collègues invivables, process ou outils trop lourd, mauvais environnement de travail)
• améliorer les aspects motivants (soutenir l’apprentissage, fournir des challenges et des feedbacks, écouter les désirs des développeurs)
• Enfin l’arme de dernier recours : la peur

Si je suis d’accord avec la plupart des points de cet article, je souhaite en discuter quelques-uns.

Concernant la réunionite aigüe, je confirme que c’est une plaie et je commence à en refuser lorsque je ne juge pas ma présence indispensable. Les pires sont sans doute les grandes réunions inter-équipes. Je suis d’accord sur le fait qu’il peut être intéressant de connaitre ce que font les équipes voisines et quels sont leurs problèmes. Nous pouvons même apporter une éventuelle solutions techniques à ces équipes, mais cet apport de solution doit se faire hors réunions. Ce n’est pas la peine de bloquer plusieurs équipes projets pour une discussion entre un développeur et une des équipes avec le problème. Oui il peut être intéressant pour tous le monde de savoir la solution adoptée, mais l’intégralité du débat n’est pas indispensable, on se contentera des pours et contres et de la décision finale. Un bon indicateur est la proportion de notes prises par rapport aux gribouillis et dessins divers sur les cahiers des participants.

Pour les conditions de travail, j’insisterai sur l’importance du matériel et des outils.
Un des intérêts des projets sur des plateformes Java avec des outils comme Maven, est d’être indépendants de l’IDE ou de l’OS sous-jacent. Enfin pour l’IDE, il faut qu’il soit suffisamment récent et avec des plugins corrects.
Les délais de compilations, redéploiement des applications sur les serveurs font que le développeur perd souvent le focus de la tâche qu’il faisait. Le temps du redéploiement, on commence à répondre à un mail, on lit un blog, on va à la machine à café et discute…. Ensuite, quand on revient à notre application déployée, il arrive qu’on ne sache plus ce que l’on voulait tester….Même si on n’a pas oublié ce que l’on voulait tester, on considère couramment que le changement de tâche prend environ 15 minutes.
J’ai du mal à comprendre l’entêtement des entreprises à ne pas vouloir investir plus dans le matériel pour les développeurs. Quand on voit qu’un poste de développement correct coute moins qu’une semaine de développeur, on se demande pourquoi les entreprises rechignent tant à fournir des machines récentes avec un dual-screen au développeur. De même si le serveur d’application doit être « imposé », je pense que l’OS et l’IDE utilisés devraient pouvoir être libres.

Le dernier point que je voudrais discuter est le support de l’apprentissage. Frank Kelly affirme que les développeurs aiment apprendre. Cette affirmation n’est pas toujours vraie, j’ai vu de nombreux développeurs en poste depuis des années qui s’inquiètent à l’idée de changer de technologie. Le deuxième problème est la capitalisation du savoir. S’il est vrai que le fait d’apprendre une nouvelle technologie peut permettre d’améliorer la productivité des développeurs, du point de vue de l’entreprise, il est nécessaire d’avoir un retour d’investissement sur le temps d’apprentissage. Si on change de technologie à chaque projet, ce qui ne serait pas pour me déplaire, le cout de l’apprentissage de la technologie est alors récurrent sur tous les projets, ce qui n’est plus l’intérêt de l’entreprise.

Enfin dernier point sur le support de l’apprentissage, les sociétés devraient envoyer plus souvent les développeurs dans les conférences. Entre les sessions techniques et les conversations de couloirs, ce sont vraiment d’excellent moyen pour regonfler la soif d’apprendre.

Pour résumer, les points que je considère important pour garder des développeurs motivés :

• reconnaitre leur valeur et payer les en conséquences
• leur fournir les bons outils
• leur donner l’occasion d’apprendre

Et vous, que vous faut-il pour rester motivé?

Au premier abord je me suis dit qu’avec un titre comme cela, ce sont toutes les sociétés/personnes faisant des outils pour les bases de données qui sont poursuivies, Oracle, IBM, SUN, mais aussi eventuellement les contributeurs de projet comme PHPMyAdmin….

Le soucis est que les sociétés/personnes poursuivies proposent des services de type « WishList » ou « TodoList ». Pour en savoir un peu plus, j’ai parcouru le texte du brevet. Ma première réaction a été le sentiment que je suis mieux dans l’informatique que dans le droit. Ce texte est, comme tout texte juridique qui se respecte, incompréhensible au commun des mortels. Lisez les premiers paragraphes et rayer le mot « said » de vos dictionnaires. Il est présent 500 fois sur les 4772 mots de la page, plus d’un mot sur dix!

Quand on lit le texte, il s’agit de créer une liste d’items ayant des descriptions et de maintenir cette liste avec une application sur un poste différent du serveur. Cela correspond donc bien à nos listes. En regardant les schémas dans le bas, j’ai reconnu quelques choses de similaire à mon code du jour : un tableau d’objet et des boutons pour ajouter/modifier/supprimer les éléments du tableau. Je me demande s’il existe quelques part une application de gestion qui ne contiennent pas un écran de ce type. Alors la question est : est ce que nous n’enfreignons pas tous ce brevet?

Parmi les choses relevées dans l’article de Techcrunch, on notera qu’ils ne s’attaquent qu’à des particuliers ou petites compagnies. Quid des grosses compagnies comme Amazon ou EBay? A noter aussi que le brevet date de juillet 2005. Je ne suis pas avocat ou expert en brevet, mais à mon avis, l’état de l’art aurait du empêcher la validation de ce brevet. Enfin, ils osent même poursuivre Geert Bevin, auteur du framework RIFE et de l’application Bla-bla List, qui résident en Europe où le brevet n’est pas valide du à l’impossibilité de breveter des idées en Europe.

Histoire d’empêcher que cela ne se reproduise,je pense que quelqu’un devrait déposer un brevet sur le concept de société déposant des brevets stupides ou génériques et poursuivant ensuite des personnes sans les moyens de se défendre pour faire de l’argent. Un jour il faudra trouver un remède à ce genre de parasite.