La conférence était organisée sur une alternance des “prez” 30mn sur un domaine, 30 mn sur l’autre durant 4h, saupoudrez de 30mn de pause.  Claude Aubry menait les affaires concernant Scrum, et David Larlet prenait en main les choses Python. Comme je vous le disais venant des deux mondes je me suis senti “dans le bain”, mais je m’interroge sur les personnes n’étant venu que pour un seul domaine. D’un côté cette alternance donnait du rythme mais d’un autre elle a peut-être empêché de creuser assez un sujet, ou d’interroger assez précisément un intervenant : pas assez de temps libre “off” avec les intervenants ! ,  une déception je n’ai pas eu le temps de parler rock’n roll avec Claude Aubry entre autres.

Pour résumer, c’était très agréable de replonger dans le bain django/python, et cela semble être comme le vélo : on n’oublie pas. Mais je reste encore dubitatif sur la percé du langage dans les entreprises ne serait-ce qu’en raison de la rareté des compétences locales.  Quand à Scrum rien de nouveau de mon côté, mais ce fut un plaisir de croiser et d’entendre cette présentation par Claude Aubry (il faut que je m’achète un chrono de cuisine pour mes timeboxes). J’ajoute : très beaux slides de David Larlet : simple et évocateur (des planches creative commons de flickr), une bonne idée que je vais reprendre (mais n’est-il pas developpeur web ? )

Enfin, première rencontre avec les gens de Particul.es. Sympa ! A ce sujet, ces deux conférences en une sont le prélude de formations/coaching autour de ces deux domaines (Python/Django & Scrum). Je vous encourage à aller sur le site pour en savoir plus (http://particul.es).

[ajout] Réflexion dans le bain cet après-midi : le vrai point commun entre Scrum & Python c’est le fait qu’ils sont tous les deux compacts. On s’approprie facilement et aisément les règles, librairies, de ces deux outils. inutile d’aller fouiller dans une documentation pour consulter le point x-44-b (comme Java par exemple qui se noie sous la documentation, ou CMMi…). L’outillage est là, présent, facile à appréhender, à l’esprit : c’est productif.

Non, désolé, mais cela ressemble fort à un post inutile (que les gens sensés s’arrêtent ici svp)*. Je ne cesse d’utiliser et de ne pas utiliser Eclipse. Je tergiverse devant l’éternelle question ultime du développeur dont la vie se résume à quelques bits : mais bon sang mais bien sûr quel éditeur (de code) vais-je donc utiliser ? Dans l’opensource (comme on dit “chez les restaurateur”) l’empreinte mémoire, c’est à dire la place prise en mémoire par un processus, c’est très important. On regarde de haut un outil gourmand. Et bon sang Eclipse, et Java plus généralement, sont de sacrés consommateurs de mémoire. D’où ma résistance (souvent enfoncée) à Eclipse (faut-il rappeler que je ne développe que très rarement en Java, mais surtout en PHP, voire en Python**). Cette “lourdeur mémoire” est à mon avis un des éléments fondateurs de ce désamour qui existe depuis longtemps entre l’Opensource et Java. Mais bon, Eclipse a tout pour séduire : références croisées d’un simple clique, découpage des objets (outline), lucène, tout un tas de plugins puissants et j’en passe, cerise sur le gâteau avec XDebug embarqué le tatonnement pas à pas dans le code est un délice. Mais je m’égare, ma machine râme, pédale, crachote, je fais un top (* commande unix/linux qui indique les processus en cours et leurs consommations CPU et mémoire), et je m’étouffe ! P***n java, p****n Eclipse. Ni une, ni deux, je bascule sur gedit (avec ctags). Là c’est léger, c’est rapide. Et puis j’erre dans le code, le teint pâle, le regard morne, où sont donc passés toutes ces fonctionnalités pratiques et efficaces, en un mot productives… Allez essayons Eclipse, l’éternel recommencement***.