Blog Arolla

Ma rétro sur Scala.io

J'ai eu la chance de pouvoir participer à la première édition française de scala.io les 24 et 25 Octobre derniers! Et pour celles et ceux qui n'y étaient pas, je vous propose de partager les quelques notes que j'ai prises.

“Failure: The Good Parts”, keynote de Viktor Klang

Viktor Klang commence par énumérer toutes les causes possibles d'erreurs techniques dans le cadre du développement d'une application:
- un disque dur qui crame
- un réseau pourrave
"Failure is an Option - Some(failure)"
L'erreur à ne pas faire, c'est de devenir parano et de polluer son code avec des try-catch pour gérer tous les cas d'erreur.
On peut "tester" son programme de deux façons :
1) La validation: est-ce que mon programme fait ce que mes utilisateurs attend de lui ? Ce sont vos tests unitaires et vos scénarios. On teste ce qui est prévu.
2) La vérification (checking) : je stresse mon programme avec des inputs au hasard, et des pannes. On teste l'imprévu.
La gestion des erreurs c'est chiant, pénible et bordélique. La meilleur chose à faire c'est de laisser les erreurs arriver et admettre qu'elles existent.
Avec Akka notamment, il existe plusieurs façons de les gérer  :
- Réplication
- Failover
- CircuitBreaker pour éviter de surcharger un système qui est déjà en difficulté
- Supervisors
- Bulkheading (compartimentation) : la mort d'un sous-système n'entraîne pas l'anarchie chez les autres sous-systèmes.
et tout ça peut être fun 🙂
Finalement, un système résilient devrait suivre cette adage : "Un escalator n'est jamais en panne, au pire c'est un escalier"

“Real world Akka recipes” par Jamie Allen

Les bus de communication promettent l'intégrité des messages qui y passent, et parfois, même de la persistance. Cependant, comme on nous l'a bien expliqué pendant cette keynote, cette vision est purement idéale. Dans la réalité, les explosions solaires altèrent les données de nos disques.

On regorge d'autres solutions comme l'event sourcing ou durable mailboxes mais ils viennent avec leur lot de problèmes.

Jamie Allen propose des patterns implémentables avec Akka non pas pour résoudre nos problèmes mais pour mieux vivre avec.

Notamment le pattern sentinel qui permet de corriger les incohérences dans un système où l'on aurait perdu des messages.

Au niveau du control flow, Jamie passe en revue 3 stratégies:

- push with rate limiting : on ne pousse un message à un acteur que toutes les N millisecondes
- push with acknowledgement : on ne pousse un message que lorsqu'on a reçu l'ack du message précédent
- pull from workers to master : les consommateurs demande les messages à leur rythme.

Ensuite il mentionne akka clusters pour créer un système distribué.

Il termine par une démo d'Activator qui permet de créer son hello akka world en quelques clics.

“Purely functional IO with Scala” par Runar Bjarnason

L'intérêt d'être purement fonctionnel est de bénéficier de l'abstraction des fonctions. A -> B est un contrat de service qui garantit que pour un A on aura toujours le même B (referential transparency). Cependant, si une telle fonction doit lire un fichier ou interroger une base de données, elle ne peut plus tenir sa promesse dans tous les cas, elle n'est plus pure.

Faire des IO purement fonctionnels (comme dans Haskell) avec Scala ne relève pas d'un tour de passe passe. Runar Bjarnason nous propose un framework pour faire cela.
Malheureusement les monoids, monads, free monads, world as state, ont eu raison de moi. Décrochage total au bout de 10 minutes.

Note à moi-même: apprendre Haskell ou lire son livre.

“Playframework Scala: democratising functional programming for web developers”, keynote de Sadek Drobi

Traditionnellement, on est confronté à des applications de type "Single box architecture". Derrière ce terme se cache des applications monolithiques qui savent tout faire et qui ne sont spécialisées en rien. Le terme bounded context n'a pas été cité mais il vient spontanément à celui qui le connaît. Chaque application doit être découpée en micro-services bornés en termes de représentation des données: Prenons l'exemple d'un tweet: si votre service ne s'intéresse qu'aux images des tweets, alors inutile de modéliser toutes les autres données. Le monde moderne est orienté web, se compose de flux continus de données, dans des domaines très variés, qu'il faut agréger et mettre en valeur. Les micro-services doivent être accessibles, traiter des flux infinis de données et être composables, le tout composant votre application.
Ce que propose Play! framework, c'est de répondre à ces besoins de représentation de données, d'accessibilité (http), de haute disponibilité et de composabilité, le tout avec une approche fonctionnelle pas trop effrayante pour les novices, et même une version Java de l'API. Play! peut s'articuler autours de :
- HTTP qui est le protocole universel que l'on sait bien scaler
- MVC parce que ce pattern est simple et structurant
- La programmation fonctionnelle parce que le modèle d'abstraction qu'est une fonction est simple, composable et autodocumenté.
Ensuit le talk s'oriente autours de la composabilité des fonctions.
Sadek nous montre comment traiter des flux de donnée avec le combo Enumerator/Iteratee, comment les composer, et en extraire de l'information.
Ça me fait bizarrement penser au Feng Shui chinois. Vous devez créer un environnement propice au flot de données (le Qi) et sa mise en valeur. Hmm... je m'égare.
J'ai trouvé cet article dont le talk semble être inspiré.

“Scalaz for the rest of us” par Adam Rosien

"Si vous avez eu une expérience traumatisante avec scalaz, c'est parce que vous n'aviez pas assez de connaissances en mathématiques." Personnellement j'ai eu peur de Scalaz avant même d'essayer de l'utiliser. Le talk se propose de montrer des cas d'applications pratiques de scalaz plutôt que de faire un cours de math ou de plagier un talk sur Haskell. On nous propose d'introduire scalaz gentiment dans son projet.
Dans les grandes lignes :

Mémoization
La mémoization est une abstraction du concept de cache. Elle permet de tirer partie de la transparence référentielle en wrappant une fonction pour mettre en cache les résultats de calculs. Ainsi, au premier appel d'une fonction, on fait le calcul, et au second on économise son CPU en utilisant la valeur dans le cache.

Du sucre!
if f() then 1 else 0 peut s'écrire f() ? 1 | 0

val a : Some("fo")

a.getOrElse("bar") peut s'écrire a | "bar"

val c = g(f(a)) peut s'écrire c = a |> f |> g

Domain Validation

Mini-framework pour valider ses objets métier. Très propres

Opérations sur de grosses datastructure

J'ai pas super bien compris, du coup je trouve ça hyper compliqué, surtout quand on a goûté à Clojure.

Si vous voulez les détails de code, c'est ici.

Le talk est pragmatique, lent, et avec du code comme support. On arrive à suivre 🙂

Et les autres ?

Je n'ai malheureusement pas assez de notes mais j'ai aussi assisté à :

"Scraping the web with clojure" par Arnaud Bailly

Une vue d'avion de Clojure et de son écosystème.

"Pimp my GC - du Scala supersonique" par Pierre Laporte

Excellent talk qui explique le fonctionnement du GC, comment mesurer l'impact du GC sur son code et tuner les paramètres. Très riche!
Conclusion: faites des objets immutables (à courte durée de vie), c'est vraiment pas cher en GC.

"Extreme speedups and GPGPU: a tale of two practical uses of reified trees" par Olivier Chafik

J'ai découvert que Scala avait un système de macro. Tout le talk était basé sur cette fonctionnalité, donc je n'ai pas compris grand chose.

"Akka in Practice: Designing Actor-based Applications" par Age Mooij et Raymond Roestenburg

Un hands-on très didactique pour découvrir Akka. On peut même le refaire chez soi, en allant sur son repo github (scala-io-exercise-N).

Conclusion

Deux jours de bombardements fonctionnels, asynchrones et résilients. Trop de choses à voir, je n'aurai pas le temps de m'ennuyer ces prochains mois !!

La conf était très bien organisée, les talks de grande qualité, et le public très intéressant. Rendez-vous en 2014.

scala.io

Plus de publications

Post navigation

1 comment for “Ma rétro sur Scala.io

  1. Yakhya DABO
    3 décembre 2013 at 0 h 33 min

    if f() then 1 else 0 ===> f() ? 1 | 0
    val c = g(f(a)) ===> c = a |> f |> g

    En gros, les évangilistes de Scala veulent nous faire croire, nous médiocres développeurs Java, que coder comme en Assembleur est une innovation.