18 avril 2013

Call for Paper ...

Organiser une conférence, ça veut dire établir un programme, et pour cela la grande tendance c'est le "call for paper" : laisser les speakers venir à nous (en passant quelques petits mots incitatifs auprès des rocks stars).

Le breizhcamp a ainsi reçu 120 propositions, soit à peu près 2 fois le nombre de sessions. Le tri est donc assez facile comparé à une conférence comme Devoxx, avec 500 talks "conférence" pour 50 slots à pourvoir, et des notes du coup très serrées.

Car il y a aussi les notes : chaque membre du CfP vote pour les sujets en donnant une note de 1 à 5, selon des critères qui lui sont propres (speaker, sujet, ...) et sans connaître les notes de ses camarades. Il peut aussi bien sur ne pas voter pour les sujets sur lesquels il n'a pas d'avis, faute de connaître le domaine évoqué.

Pour gérer ces votes, nous (enfin, surtout Yan) avons développé une application pile poil pour gérer les votes, ce qui nous a permis de traiter le 120 sujets en quelques heures.

L'étape suivant c'est de dépouiller les résultats. Aussi nous nous sommes retrouvés pour appliquer l'algorithme suivant :


def selection( format: String, talks: List[talk] ) : List[talk] = 
        check(talks). // relecture des propositions
        sort( talk => talk.note ). // tri par note
        filter( talk => agree )


agree étant une fonction qui prend en paramètre l'équipe du CfP, passe par une étape de discussion récursive pour donner un résultat booléen.



L'idée est de remplir un tiers du programme en fonction des notes, puis de regarder dans ce qui reste ce qui est redondant, innovant, etc et qui mérite d'être sélectionné tout de même, ou bien de reclasser un sujet dans un autre format en fonction des informations que nous a fournis le speaker.


Nous arrivons ainsi au programme dont une version graphique sera publié dans quelques jours. Les speakers promus ont été notifiés, les autres devront se contenter de venir en spectateur.



Je sais la déception que peut être de ne pas être retenu à un CfP, la frustration d'avoir proposé un bon sujet qui n'est pourtant pas retenu, amis speakers ne nous en voulez pas, la tâche n'est pas facile et il faut bien trancher à un moment donné.


14 avril 2013

1, 2, 3, scala

Coursera propose une seconde session de ses cours scala - vous pouvez encore rattrapper le cours, même si vous serez un peu hors délais pour faire un high-score, mais peut importe ça reste très intéressant.

Le principe de ces cours, c'est de proposer des sessions en vidéo et des exercices à réaliser et à soumettre pour validation.

La partie vidéo est génialissime. Très progressives, les "lectures" vous font découvrir peu à peu scala, et surtout la programmation fonctionnelle. On pourra trouver ces présentations excessivement théoriques, formalisées de manière très mathématique - elles restent cependant très didactiques, et j'adore l'option de vitesse de lecture, qui permet de passer en *1,25, *1,5 voir *2 pour des passages qu'on a déjà compris on qu'on trouve trop théoriques (ou bien quand on a pas trop de temps à leur consacrer :P). A quand la même fonctionnalité dans Parleys ?

Par ailleurs, les vidéos présentent les slides avec en filigrane le stylet de Martin Odersky, qui ajouter des schémas ou des petits bouts de code explicatifs.
Bref, coursera, c'est de la balle



La partie exercice est également parfaitement adaptée et bien préparée. On a assez peu de code à produire dans un squelette bien documenté qui nous guide vers la solution, il y a "juste" ce qu'il faut pour apprendre ce que l'exercice vise à nous faire comprendre.

Question temps, il faut compter 3 à 4h environ pour chaque semaine de cours. Pour ce qui me concerne j'ai fait le 1er sur une pause midi, le second "en tâche de fond" sur deux jours et le dernier hier soir, terminé ce matin parce que passé 23h je commençais à faire n'importe quoi.

Clairement, c'est consommateur de temps, mais bon, à étaler sur une semaine ce n'est pas si méchant que ça quand on considère la qualité du support didactique. Au moins, lors des prochains trolls anti-scala j'aurais de vrais arguments :)

et scala dans tout ça ?




Scala, c'est des fanboys, une armée de contradicteurs qui n'ont jamais regardé plus loin que le mal qu'on leur a dit de scala, et des trolls en pagaille, alors allons y :



Syntaxe 
Le premier contact est un peu rugueux : la syntaxe est déconcertante. Pour un langage qui cible la JVM et s'adresse aux développeurs Java voulant gouter à la programmation fonctionnelle, je ne comprend pas certains choix de syntaxe - ils ont sans doute une bonne raison d'être, mais ...

foo(x: Int): Boolean pour une méthode foo qui prend un entier et rends un booléen. Pourquoi donc avoir inversé l'ordre type / nom par rapport à Java ? A n'en pas douter il y a une bonne raison dans l'inférence de type ou que sais-je, mais c'est un frein à la lisibilité par le développeur Java.

import truc._ plutôt que import truc.* vous me direz que c'est un détail, mais pourquoi ne pas reprendre la même syntaxe ? Intention délibérée de se démarquer (inutilement) de Java ?

bon, évidemment on s'y fait et arrivée en "semaine 3" on n'y fait plus trop attention.

J'ai eu droit à ma plus belle volée de tweets (record absolu) en signalant mon désaccord sur la non-utilisation du return. Car, en java, pour un algorithme récursif j'aime utiliser return pour marquer la condition de sortie:


public int recurse(int x) {
    if (x == 0) return 1;
    recurse(x - 1)
}


ce qui peut se traduire en Scala sans soucis, mais les "bonnes pratiques" suggèrent plutôt


public int recurse(int x) {
    if (x == 0) 1
    else recurse(x - 1)
}

il paraît que c'est plus "fonctionnel", que ça ne brise pas la logique, ... bon on a enlevé un return pour mettre un else, perso je ne vois pas en quoi c'est plus élégant. J'ai eu le même genre de débat en java sur le return qui devait être unique dans une méthode, quitte à imbriquer des if en pagaille ... débat sans fin. Je sens que ce billet va avoir quelques commentaires :) Bon ça aussi on s'y fait vite

Slooooooow
Scala, c'est aussi une machine à genoux. Pour lancer le premier tutorial "hello world", j'ai du définir quelques -XX dans mon JAVA_OPTS sous peine de OutOfMemoryException. Désolé, je n'ai qu'un MacBook Air 2Gb - mon MacBook est en réparation

La réputation de scala de ce côté semble fondée. Idem pour ses lenteurs de compilation : plusieurs longues secondes à attendre pour compiler les 3 classes de l'exercise, je n'ose pas imaginer un projet de grande ampleur. Je suis surtout étonné que le compilo puisse être lent à ce point. Je n'ai jamais écrit de compilateur, donc je suis mal placé pour me prononcer, mais sur une syntaxe tout de même assez simple et déterministe que peut bien foutre le compilateur à mouliner pendant tout ce temps ? (-> quelques éléments de réponse) A part celui de GWT, je ne vois pas pire...

Ou alors, c'est que scalac est écrit lui-même en scala (attention, #troll inside). Car si la programmation fonctionnelle est une façon intéressante de structurer un programme, avec une approche orthogonale à la programmation impérative, j'ai de grosses interrogations lorsque j'écris un algo sur les performances finales. Immutabilité oblige, mes graphes de données vont être répliqués de nombreuses fois, créant miriades d'objets en mémoire. Ca a de nombreux avantages en termes de structure du code, de logique, de concurrence, mais avec un tel niveau d'abstraction que je ne sais fichtrement pas dire si ce que j'ai écrit à une chance d'être performant - déjà que je ne suis pas forcément sur de pouvoir garantir que mes récursions convergent ...

L'outil de build sbt est aussi ... "étonnant", il va falloir que je creuse un peu : les projets d'exemple ont tous un répertoire "project" plein de scripts scala. A priori ce sont des "plugins" sbt. Sauf que si on doit les copier coller dans chaque projet, ce ne sont pas des "plugins" au sens maven/eclispe, partagé et réutilisables, mais des "copié-collés" ... ou au mieux des git-submodules comme on le fait avec les cookbooks puppet. A creuser
update : je suis rassuré, il y a de "vrais" plugins SBT, les exos de coursera ont juste fait "au plus vite" sur ce point. C'est un peu dommage, ça suggère de mauvaises pratiques du coup

J'attends la suite
Bref, je n'en suis qu'à la semaine 3, avec encore pas mal de boulot, et (j'espère) le temps de continuer parce que c'est vraiment trop bien fait et très intéressant. Je reste cependant encore sceptique. Je vois mal Scala être largement adopté par les développeurs lambda.

D'une part, et vous en avez certainement autour de vous, certains développeurs ont décidé de mettre leur cerveau à la retraite lorsqu'ils ont obtenu leur diplôme d'ingénieur. Ceux là ne pourront pas faire de scala, trop besoin de réfléchir.

De l'autre côté, vous avez les enthousiastes qui - eux au contraire - sont content de pouvoir enfin se servir de leurs neurones, plutôt que d'écrire 200 lignes de code pour valider un formulaire.

Ces deux populations on les connaissait déjà (avec toute une palette intermédiaire) mais je trouve qu'un langage comme scala exacerbe ces différences. Dans un contexte de start-up avec des équipes réduites et triées sur le volet ça a du sens (cloudbees a pas mal de code scala pour faire tourner la boutique, cause première de mon inscription sur coursera). Dans un contexte de SSII (pardon ESN), projet au forfait, "resources" pas cher et offshore, j'ai plus de mal à imaginer ce que ça peut donner.

Conclusion
Je suis content d'avoir l'occasion de découvrir un langage fonctionnel, qui apporte une vision nouvelle et me sera certainement profitable, au moins pour bien utiliser les lambdas en Java 8 (9?). J'attends avec impatience la suite des cours. Je souhaite à scala que quelqu'un se penche activement sur son compilateur et son outil de build, pour qu'il ne laissent pas au newbies come moi une sensation étrange de "wtf ?". 500M de mémoire et 5 secondes pour un hello world ? Même ruby fait mieux

(L'avez vous remarqué, quelques trolls se sont glissés dans ce billet. Si vous les trouvez tous, vous pouvez gagner une place au BreizhCamp)