-
Qui a eu des soucis de parallélisme dans la salle: 75% des gens, qui aime résoudre ce genre de problèmes ? quasi personne
-
Pas de code "thread safe" en ruby car les différentes implémentations ont des sémantiques différentes sur le threading => "code thread safe en jruby 1.7.4"
-
Explications sur les sémantiques 1.8, 1.9 et jruby
-
En 1.8 avec le lock global beaucoup de choses fonctionnent bien, même si sémantiquement elles ne devraient pas, ne pas se reposer dessus
-
Patterns:
- Éviter les données partagées entre thread autant que possible, et si c'est nécessaire utiliser des primitives de protection comme les Mutex
- Mais il ne faut pas les utiliser sur les IO, sinon on risque de tout bloquer: il faut protéger le minimum de choses
- Éviter de réveiller tous les thread en attente en même temps si seul peut prendre la main ~> utiliser des choses comme les ConditionVariable pour ne réveiller qu'un thread à la fois
-
Test
- Tester avec différents implémentations et versions
- Tester avec beaucoup de threads, certains bugs ne seront visibles que dans ce cas
- Ne pas hésiter à utiliser des synchronisation ou autre dans les tests pour tester les cas compliqués
- rappel sur Unix et la grandeur de la ligne de commande, même que dans Jurassic Park une fillette sauve tout le monde des griffes des vélociraptors parce que le système de gestion des portes tourne sous Unix et qu'elle sait s'en servir
- mais pour ça il faut respecter les conventions Unix:
- des messages d'erreurs lisibles sans stack trace ni rubyismes
- des retours utilisables par d'autres programmes: utiliser stdout et stderr et des codes de retour (man sysexits
- des pages man, même si elles sont difficiles à bundler dans des gems
- gestion des signaux
- readline si il y a une saisie à l'intérieur des programmes
Konstantin Haase (mainteneur de travis et sinatra): death to cookies, les attaques qu'on peut mener sur les cookies
- contenu opaque pour éviter de pouvoir deviner
- tout sanitizer
- utiliser CSR
- vérifier que les logins sont en post
- vérifier le referer (qui ne fonctionne pas pour le https)
- vérifier l'origin (sauf pour les vieux navigateurs et les vieilles versions de flash)
- tokens csrf
- utiliser CORS
- les cookies chiffrés ne servent à rien
- ssl, contre lequel il y a des attaques sur la compression
- d'autres solutions souvent pires
Conclusion: pour arriver à faire quelque chose de satisfaisant il faudra inventer des choses dans le browser pour remplacer les cookies
Terence Lee (ruby task force manager à Heroku): a history of fetching specs, sur le fonctionnement de rubygem
- Au début rubygems utilisait un fichier d'index unique téléchargé à chaque lancement, puis d'un appel par gem pour avoir les dépendances, c'était lent, consommait de la ram, et ne scalant pas
- Introduction d'un nouveau format et d'une nouvelle API qui permet en un seul appel de récupérer juste les données nécessaires en passant les gems en paramètre
- Difficile à cacher car chacun a son propre set de gems
- Une version de gem publiée toutes les 5 minutes, du coup plein d'invalidations intelligente
- Ne scale pas quand plein de gems dans une requête à cause des jointures SQL
- Plus compliqué à opérer (la 1ère version n'utilisait que des fichiers plats) sachant que c'est maintenu et opéré par des volontaires
- Centralisé en Virginie pour l'ensemble du monde
- Nouveau nouveau format et API à base de fichiers plats avec une entrée par ligne qui arrive bientôt
- Pas de fichier yawl ou json pour des question de perf et de taille
- Cacheable par HTTP, CDN-friendly, cachable localement
- Utilisation de http-pipelining pour le téléchargement
- Installation en parallèle pour le prochain bundler
Heroku: du travail dans le pipe sur les performances
Kinsey Ann Durham (thoughtbot): Inspiring a New Generation of Developers, sur la diversité des développeurs
- Elle a commencé par bosser dans la pub et ne s'intéressait pas à l'informatique, puis s'ennuyait au boulot
- De nombreux séminaires, mentorship, etc. pour apprendre aux gens qui n'ont jamais programmé et ou fait d'études techniques de s'y mettre qui permet d'atteindre des gens différents, c'est ce qu'elle a suivi
- Ça permet aux gens d'apprendre avec d'autres personnes débutantess ce qui les encourage en montrant qu'ils ont les mêmes soucis que les autres
- Des workshops dédiées aux femmes pour éviter qu'elles ne soient noyées dans la masse et se sentent exclues
- Encourage les gens à faire du mentorship pour des débutants dans ce genre de cadre car ça leur apprend beaucoup de choses et c'est une expérience très satisfaisante
- Importance dans son entreprise d'une équipe ouverte qui soutient les gens qui ont des profils différents même quand elle a du mal à progresser
- Avantage pour une entreprise d'avoir des gens différents: bon pour l'état d'esprit, les qualité différentes, et agrandit le pool de recrutement possible
- Programmme de mentoring de thoughtbot qui leur permet de former et découvrir des gens d'un très bon niveau, et attire des gens qui aiment partager
- Choses spécifiques aux US
- les programmeurs ont échoué vis à vis des non programmeurs, quand on voit les OS et les applications actuelles c'est une honte, les gens sont confrontés à plein de choses compliquées et qui leur font peur
- les navigateurs sont le 1er moyen qui permette de télécharger et de lancer du code sur un ordinateur sans avoir peur que ça casse l'ordinateur
- il a récupéré un iPad pour jouer à un jeu précis et s'est rendu compte qu'il était mieux fichu qu'un ordinateur pour tout sauf pour coder, ça a achevé le même niveau que le browser + js au niveau de facilité et confiance, c'est pas glorieux mais c'est un achievment
- Pour remplacer les OS il manque quelques trucs aux navigateurs
- Description du process de specification du W3C, qui est lent, orienté vers les développeurs de navigateurs, qui n'écoute pas le feedback des développeurs web, et qui donne des specs mal fichues et mal implémentées
- Au lieu de ça on devrait avoir des fonctionnalité prototypées en js par des devs web qui sont ensuite spécifiées puis implémentées par les navigateurs
- Ça demande de rendre les navigateurs extensibles pour pouvoir les utiliser pour expérimenter
- Idée qu'on pourrait prototyper: meilleur support des framworks pour ne pas tout retélécharger et recompiler, "app" installables, etc.
- Son usage de rails parce qu'il parle devant des rubyistes: pour server une API avec de l'ember en front
- ~> dans le futur ember devrait faire partie du navigateur
- Arrêter de troller sur les outils, ce qui est intéressant c'est ce qu'on fait avec, la vie est trop courte pour passer son temps sur Hacker News
- besoin d'ACL dans rails, avec des roles, des assertions custom, avec une approche déclarative qui ne transforme pas le code en spaghetti
- pas de gem existantes qui réponde => ils ont écrit la leur https://github.comifeelgood/simple_acl
- démo de l'outil
- on teste les les interactions mais pas le résultat visuel
- https://github.com/facebook/huxley : screeshot + git => on teste le résultat visuel ~> gestion de version visuelle avec l'historique visuel des écrans
- programme pour aider femmes à apprendre à rails en participant à des projets open source
- une base de code monolithique avec de nombreux utilisateurs
- une équipe qui grossit
- ces 30 derniers jours 979 commits de 72 auteurs
- sprint d'une semaine pour encourager les stories courts et des implémentations plus simples à reviewer
- découpage des fonctionalités en stories courtes
- releases toutes les semaines, incrémentales, au tempo prévisible
- pour les grosses features il est possible qu'elles soient t livrées en plusieurs releases et qu'elles restent invisibles tant qu'elles ne sont pas complètes ~> bibliothèque Arturo pour gérer la dispo d'une feature
- tout est reviewé de manière informelle et rapide
- outil de vérification pour alléger les review humaines
- essaie de faire un projet pour son talk, donc va voir sur google pour trouver un outil
- tombe sur des discussions sur SO sur les gems à utilisées, de savoir si elles sont maintenues
- savoir si la lib qu'on utilise sera toujours maintenu ça met une pression sur les développeurs
- les développeurs qui publient des bibliothèques puis cessent de les maintenir se font blâmer
- proposition: AAAR Adoption Agency for Abandonned Repos pour progresser sur ce sujet
- les soucis:
- le code avance lentamente
- les changements créent des codes
- Cercle vicieux du mauvais code: retard <=> mauvais code <=> pression
- Il y a des forces opposées à la qualité du code: changement business, changements techniques, changement de personnes
- Vouloir écrire du code en ayant peur d'introduire des bugs créé du mauvais code
- Pour améliorer le code:
- Commencer par arrêter d'écrire du mauvais code
- Essayer d'améliorer le code à chaque commit
- Une limite: pas assez d'expérience dans le refactoring.
- S'informer et discuter des changements possibles et de la manière de les faire
- Teamfactoring: session de refactoring ensemble pour faire progresser tout le monde, même si au final un refactoring en particulier n'aboutit pas
- Il faut éviter au maximum que le mauvais code s'installe. Créer des issues sur les problèmes de qualité est une bonne approche.
- Remplacer les code review formelles par des pull requests qui sont plus fluides, mais les faire synchrones, et possiblement optionnelles pour éviter de polluer le process avec des changements insignifiants
- Le critère le plus important dans une code review est la lisibilité du code
Erik Michaels-Ober (Soundcloud): sur l'évolution de la technologie de la communication depuis l'invention de la parole
Pannel des implémenteurs: Brian Shirai - Aaron Patterson - Laurent Sansonetti - Charles Nutter - Evan Phoenix modérateur
Présentation de chacun:
- Charles: jruby depuis 7 ans, essaie d'être le meilleur ruby possible sur la JVM
- Laurent: MacRuby en 2006 sur MacOS, RubyMotion en ce moment, basé sur MacRuby
- Aaron: il a une blouse de scientifique, est sur la core team de MRI depuis 4 ans
- Brian: Rubinius 2006 le but c'est d'avoir une VM moderne pour ruby
Pourquoi une autre implémentation ?
- Brian: une VM moderne avec une bonne gestion de la concurrence, il pense que plein d'implémentation sont une bonne chose
- Aaron: il aime bidouiller sur MRI parce qu'il aime bidouiller du C, il aimerait coder une version de ruby en rails avec des turbolinks
- Laurent: l'objectif depuis RubyCocoa est d'écrire des applications Mac natives en Ruby en utilisant une seusle VM
- Charles: jruby et MacRuby se ressemblent car il s'agit de porter ruy sur une VMs qu'ils apprécient. Il continue de le faire après 7 ans car il trouve toujours de nouvelles zones intéressants à faire fonctionner
Qu'est ce que ruby doit faire pour que l'utilisation de ruby continue à grossir et reste pertinente ?
- Laurent: ils recrutent des développeurs js et python qui passent à ruby pour utiliser RubyMotion
- Charles: avoir plusieurs implémentations aide à essayer des choses différentes et faire maturer le language
- Brian: certaines limitations quand à l'utilisation du matériel à son plein potentiel doivent être levées pour que les gens qui veulent utiliser ruby dans tous les cas peuvent le faire
- Aaron: c'est pas grave si on n'est plus hip, il n'y a pas à courir après ça
Les fonctionalités qu'ils aiment et n'aiment pas dans les version 2.0 et 2.1
- Aaron: aime caches de méthodes, keywords arguments, frozen strings
- Laurent: RubyMotion est en 1.9 mais est spécial car c'est un dialecte: il n'y a pas tout ruby. En 2.0 il aime le nouveau GC, frozen string qui aidera pour la mémoire sur iOS. Il trouve qu'il y a trop de nouvelles choses dans ruby et qu'il retourne à sa base avec un minimum de choses, un meilleur système d'objet et des macros
- Charles: le fait que les raffinements soient désactivables pour éviter d'avoir des surcouts d'invocations partout
- Brian: les frozen string et les refinements sont potentiellement dangereux pour les développeurs car ils risquent de causer des bugs compliqués à comprendre
Aaron explique comment il a utilisé les refinments pour gérer des dépendances au chargements plutôt qu'à l'execution
Qu'est ce qu'ils supprimeraient de ruby vu qu'ils n'ont jamais rien supprimé ?
- Charles: il y a déjà eu des trucs dangereux supprimés de langage
- Laurent: proc binding
- Aaron: taint & untrust
Laurent pense qu'il a meilleure gestion de la mémoire de toutes les implémentation car il n'a pas de GC.
Discussion sur la mémoire transactionnelle, Charles pense que c'est utile à certains endroits mais pas dans tout le code.
Le truc le plus sympa qu'ils ont eu:
- Charles: toutes les bibliothèques dispo
- Laurent: voir des gens écrire des applis en Ruby et les poster sur l'AppStore
Une chose qu'ils voudraient que leur implémentation fasse mieux
- Aaron: du JIT
- Charles: temps de démarrage, la gestion des extensions en C
- Laurent: la gestion de la mémoire
- Brian: temps de démarrage
Soucis non résolus dans ruby:
- Charles: concurrence dans le language lui-même, du coup il travaille sur des outils pour permettre aux développeurs d'avoir des primitives, l'API C qui expose trop de fonctionnalité internes pour être bien implémentée ailleurs que sur MRI
- Brian: pas assez d'outils de débuggage pour les développeurs, par exemple pour débugguer les problèmes de monkey patch
Qu'est ce qu'il faut faire pour écrire du code rapide ?
- Aaron: pas de code
- Laurent: les gens ne se rendent pas compte de la complexité de l'exécution générée par certains types de code, quand ils chainent des méthodes par exemple
- Charles: moins d'allocation d'objets