Entretien avec Aaron Patterson, président de la conférence RubyRussia 2018

Salut Nous poursuivons une série d'entretiens avec des intervenants à la conférence RubyRussia . Aaron Patterson (alias tenderlove ) est membre de l'équipe principale Ruby et de l'équipe principale Rails, un ingénieur logiciel de premier plan dans une petite startup appelée GitHub. Pavel Argentov s'est entretenu avec Aaron avant son deuxième voyage en Russie.



Commençons par la question standard. Quelle est votre histoire rubis personnelle? Comment avez-vous attrapé ce train? Parlez-moi de vos réalisations? Avez-vous rendu le monde meilleur?

J'ai découvert Ruby en 2006. J'étais alors programmeur Java. Commençons encore plus tôt: j'étais un programmeur Perl, puis je suis devenu un programmeur Java, mais je ne voulais pas être javiste.

Pourquoi?

Quand j'ai écrit en Perl, nous avions déjà notre propre framework web. Il y avait beaucoup de ce que Rails avait: vous pouviez simplement changer le code, recharger la page et vérifier ce qui s'était passé. Tout a juste fonctionné. Lorsque nous sommes passés au développement Java, c'est devenu comme ceci: vous devez tout recompiler - cela prendra 10 minutes avant de pouvoir vérifier toutes les modifications que vous venez de faire. J'aime plus les langages dynamiques comme Perl que Java. On s'attendait à Perl 6. Alors, en attendant Perl 6, j'ai découvert Ruby. Pensée: «Wow! C'est ce dont j'ai besoin! » J'ai donc commencé à faire du Ruby - pendant mon temps libre, par exemple, pour des projets parallèles. Tu sais, juste pour le plaisir. Tout a commencé avec ça. Enfin, en 2008, j'ai déjà obtenu un emploi chez Ruby.

Était-ce déjà Rails?

Oui, mon ami a décidé de démarrer une startup. - Nous utiliserons Rails. Voulez-vous travailler avec nous dans la même entreprise? Je suis comme ça: - Oui, bien sûr, je serai heureux de travailler sur les «rails»! C'est comme ça que j'ai commencé.

Honnêtement, je n'aimais pas mon travail dans cette entreprise. Par conséquent, à chaque occasion, directement sur le lieu de travail, j'ai écrit l'open source. Cela a été fait comme suit: - Ok, le projet prendra 2 jours. Ensuite, j'ai terminé l'affaire en quelques heures, et utilisé le reste du temps pour l'open source.

Ce que nous avons appelé: "Ne frappez pas le ralentisseur!" Je m'assois ici calmement, réparant le primus. Laisse-moi tranquille, pliz!

Ouais! Donc, ici, j'ai commencé à beaucoup travailler avec l'open source. Dans ce travail, j'ai commencé à écrire Nokogiri et à travailler généralement sur mon open source Ruby. J'ai donc opté pour l'open source. Il a simplement «fait une contribution» jusqu'à ce qu'il rejoigne un jour les équipes Ruby Core et Rails Core.

Alors, comment vous êtes-vous retrouvé dans l'équipe Rails Core?

Nous venons de trouver des bugs et développé des applications Rails. J'ai trouvé des bogues, je les ai corrigés et j'ai envoyé des correctifs. Je viens d'envoyer des patchs. En fin de compte, ils sont fatigués du fait que je ne fais que générer des demandes de tirage.

Comme, maintenant, prenez les choses en main, non?

Oui, bien sûr! Dans l'ensemble, c'était comme une attaque par force brute!

Cela semble raisonnable! Alors, quelle est votre contribution globale à Rails?

J'ai beaucoup travaillé sur presque toutes les parties du framework. Surtout sur Active Record. J'aime particulièrement faire des corrections de bugs et améliorer les performances. La raison de cette pièce jointe est qu'elle améliore les applications de quelqu'un. Tout le monde est content si l’application s’améliore et vous n’avez rien à faire pour cela. C'est pourquoi j'aime y travailler.

Vous faites quelques «petits» raffinements qui font que tout fonctionne. Mais n’avez-vous pas dû concevoir de «grandes» choses?

Habituellement, chaque fois que je fais quelque chose d'architecture dans Rails, c'est quelque chose à l'intérieur. Par exemple, l'architecture de travail avec les URL, les associations, les gadgets à l'intérieur du routeur - quelque chose comme ça. Aucune de ces choses ne sera nécessairement perceptible. Ils peuvent être vus par l'utilisateur, mais ce n'est pas sous la forme: "La voici, la vraie chose!" J'essaie de m'en tenir à ce style. Je pense que c'est vraiment bon, parce que David ( DHH - P.A.) aime créer de nouvelles fonctionnalités brillantes. Je me dis plutôt: «Eh bien, faisons-en vos beaux traits. Vous regardez, et la vérité sortira belle! "

Oui, quelqu'un doit faire tout le travail manuel. Par exemple, votre présentation à la conférence portera sur certaines parties de l'ingénierie profonde de Ruby en général et de Rails en particulier. De quoi parle vraiment la présentation?

En fait, je vais parler des internes Ruby. Jusqu'à la fin, je n'ai toujours pas inventé tout le discours.

GC, performance, tout ça, vie, univers, 42?

Je pense à parler du garbage collector, du processus de compilation Ruby et du bytecode. Fondamentalement, sur le bytecode dans une machine virtuelle et sa relation avec le garbage collector. À propos de certaines des améliorations de performances que j'ai apportées au GC. Je ne m'attends pas à parler beaucoup de Rails.

Notre conférence s'appelait auparavant le Rails Club. Nos organisateurs ont pensé et renommé l'idée, principalement parce que Matz a dit qu'il n'assistait jamais aux conférences avec le mot «Rails» dans le titre. Alors maintenant, nous sommes «Ruby Russia»!

Donc, je vais parler des internes Ruby!

À votre avis, que devraient faire les programmeurs Rails pour obtenir de meilleures performances dans leur code?

Il existe plusieurs stratégies. Premièrement, en termes généraux, ne faites rien de spécial. Écrivez simplement votre candidature. Lancez-le, obtenez des clients, des commentaires, etc. Analysez immédiatement les goulots d'étranglement détectés. Ne travaillez jamais avec des goulots d'étranglement jusqu'à ce qu'un véritable travail avec les clients les révèle. Si vous rencontrez des goulots d'étranglement qui ne le sont pas vraiment, c'est une perte de temps. Cette fois pourrait être utilisée pour de nouvelles fonctionnalités. Cependant, je pense que beaucoup diraient la même chose, alors parlons de ce qui affecte vraiment les performances. Tout d'abord, regardez les requêtes de base de données que la page fait. Il s'agit de la première ligne de défense - essayez de réduire le temps consacré à des demandes spécifiques. Requêtes elles-mêmes - automatisez et réduisez. Vous ne croirez pas combien de fois nous oublions simplement d'ajouter un index. Ha! Alors, faites au moins l'index au bon endroit.

Je mène des entretiens techniques et j'imagine comment les gens oublient même ce que sont les index en général. Pourquoi avez-vous vraiment besoin de vous en préoccuper ... Eh bien, que dites-vous des autres choses que les rubistes devraient savoir? Quelles sont les choses techniques qu'un rubiste devrait savoir pour mieux faire son travail?

Il y a quelques morceaux de ce genre. Le premier, je pense, est de connaître le langage Ruby lui-même. Apprenez la langue très attentivement. La seconde est de bien comprendre UNIX.

Vous êtes le premier «mon» orateur à dire que vous devez connaître UNIX. J'ai donc personnellement rejoint Ruby du monde UNIX. J'ai travaillé sur Linux, FreeBSD et des tonnes de code Perl. Je suis venu à Ruby comme un autre Perl pour faire mes affaires d'administrateur système, et j'ai seulement découvert qu'il s'agissait également d'un langage Web. Et donc, vous dites que vous devez connaître UNIX. Comment et pourquoi?

Il est important d'étudier les normes POSIX et leur interaction avec le système d'exploitation, car vous les rencontrerez dès que vous commencerez à évoluer. Toi ...

... devrait savoir qui est le général Feiler et pourquoi il lit mon dossier?

Haha oui! Vous devez savoir ce qui change les performances. Peut-être que vous n'avez pas besoin de mémoriser cela spécialement par cœur, mais vous devez savoir qu'ils existent (appels système - P.A.) et comment les rechercher sur Google, car vous rencontrerez certainement cette économie. Ils seront importants car l'application est déployée sur un serveur UNIX, vous devez donc comprendre comment l'application va interagir avec le système d'exploitation sur lequel elle s'exécutera. Un autre point important est que si vous avez acquis cette compétence sous UNIX, vous pouvez l'appliquer, par exemple, dans d'autres langues. Si vous rencontrez des problèmes, vous pouvez toujours partir de ce point. C'est peut-être la principale chose que je recommande aux programmeurs d'étudier.

Pensez-vous qu'il est utile pour le rubist de connaître une autre langue? Est-il possible d'être un bon programmeur en Ruby sans rien savoir en dehors de Ruby?

Bonne question. Honnêtement, je ne sais pas. Tous les bons rubistes que je connais connaissent d'autres langues. Cependant, je ne sais pas s'il est nécessaire d'apprendre d'autres langues pour devenir un bon programmeur Ruby. Je pense qu'il se trouve que les gens apprennent d'autres langues.

Bonne observation! D'un point de vue médical, plus une personne connaît de langues, plus cela retarde l'apparition de sa maladie d'Alzheimer.

Haha

Après 40 ans, vous devez penser à de telles choses ...

J'approche de 40 ans! C'est bon pour moi de savoir!

Parlons de Ruby lui-même. Le rubis est une langue avec un grand passé. At-il un avenir? Il n'y a pas si longtemps, j'étais à Saint-Pétersbourg à l'une des plus grandes conférences informatiques que j'ai vues en Russie. La communauté rubis locale n'était pas représentée à cette conférence. Je devais constamment faire des excuses à Ruby: Ruby N'EST PAS SI MORT, ils écrivent toujours Ruby. Au fait, Ruby a le framework web le plus connu - et tout ça. Chaque grande langue sur le marché dispose désormais d'une sorte d'outil de développement Web. Allez, Rust, peu importe. Quelle est la place de Ruby dans cet écosystème et «Ruby au grand passé» a-t-il un avenir?

Je pense qu'il y a plusieurs aspects à la réponse à cette question. Il existe de nombreux langages différents pour lesquels il existe des frameworks web, mais je pense toujours que si vous les regardez du point de vue de l'ergonomie du développeur, Ruby sera de toute façon au top. Il est facile à utiliser et à vendre. Le problème est que Ruby n'est plus "flambant neuf et brillant". Les gens veulent se laisser emporter par quelque chose de nouveau. Ils veulent prendre le prochain train après Rails.

Ils veulent l'odeur d'une nouvelle voiture!

Oui! À propos de l'avenir ... Il y a beaucoup de nouveaux développements dans Ruby, en particulier sur JIT et avec quoi Koichi: guilds travaille. Je dirais que Ruby a définitivement un avenir, mais tout le monde devra travailler dur pour cela. Si nous faisons les bons efforts, l'avenir le sera certainement.

Ruby a-t-il une perspective dans d'autres domaines que le développement Web? Ou connaissez-vous des exemples où Ruby est maintenant utilisé en dehors du développement Web?

Bonne question! Il est difficile de répondre, car je ne traite que des problèmes de développement Web.

Je demande parce que c'est mon intérêt personnel. Les gars de la communauté Python, par exemple, adorent se vanter de leurs succès en informatique scientifique.

Je sais qu'il y a un groupe travaillant sur les outils scientifiques à Ruby. Mais je pense que la véritable alternative pour Ruby est l'administration système.

Comment pouvons-nous amener des développeurs d'autres langues dans notre communauté?

C'est vraiment une bonne question! Je pense que nous devons juste nous concentrer sur l'ergonomie du développement, sur ce qui rend le développement d'applications Web aussi simple que possible. Nous devons nous concentrer sur l'abaissement du seuil d'entrée pour les nouveaux développeurs qui embarquent et écrivent des applications Web. Nous allons donc attirer plus de nouveaux programmeurs.

Il est temps pour la question hollywoodienne sur JavaScript. Vous savez, il y a un dicton: "tout ce qui peut être réécrit en JavaScript sera nécessairement réécrit en JavaScript." Pensez-vous que Rails sera également réécrit en JavaScript? Nous avons parlé de l'ergonomie de développement de Ruby. C'est la meilleure chose à propos de Rails. L'un des très célèbres programmeurs russes a déclaré que "de nombreuses langues sont bonnes, mais que Ruby a des rails". Cependant, les développeurs JavaScript ont tendance à remettre cela en question. Comment pouvons-nous rivaliser avec JavaScript? Ou devrions-nous organiser une symbiose avec lui?

C'est vrai que seul Ruby a des Rails. Si vous regardez les frameworks Web pour JavaScript, je ne pense pas qu'ils soient assez comparables à Rails en termes d'ergonomie de développement. Le fait est que puisque nous écrivons des applications Web, nous devrons travailler avec JavaScript. Nous devons faire partie de la communauté JavaScript. Il est utile pour nous d'avoir une symbiose. Si vous pouvez exécuter n'importe quelle langue sur le serveur, pourquoi devrait-il être JavaScript? Mais la langue est bonne et je pense que nous devons travailler en symbiose. La facilité de développement est toujours de notre côté, et elle est particulièrement appréciée dans la communauté Rails. Vous êtes donc venu à la conférence informatique et vous avez dû y travailler en tant que représentant de Ruby?

C'était assez informel, car je n'avais même pas de t-shirts sur mon entreprise ou ma langue. J'ai donc trouvé le groupe de jeunes le plus brillant qui se soit avéré être des pythonistes, et nous avons commencé à discuter.

Pour nous, c’est bien de travailler avec d’autres langues et de ne pas rivaliser avec elles. Personnellement, je pense que la programmation en Ruby est beaucoup plus facile et plus agréable que dans d'autres langages. Pourquoi pas? Nous parlons d'autres langages de programmation et si nous devons les connaître. Je crois qu'il est important que les rubistes apprennent d'autres langues. Quelque chose comme Java, Haskell, ou quelque chose d'autre fonctionnel comme Elixir ou Lisp, quelque chose comme ça. Je pense qu'il est utile d'étudier différents paradigmes, car lorsque vous apprenez de nouvelles choses, vous pouvez les retirer et les utiliser dans votre propre langue. Une bonne caractéristique de Ruby est que nous pouvons utiliser des techniques de différentes langues dans nos programmes.

Oui, nous avons, par exemple, des outils de programmation fonctionnelle ou d'exécution de map / réduire ou autre chose.

Oui, nous pouvons utiliser tout cela. Si vous utilisez un langage qui encourage ces techniques, vous pouvez trouver un meilleur moyen de résoudre le problème. Je ne suis pas sûr qu'il soit nécessaire d'étudier d'autres langues pour être un bon rubiste, mais cette étude m'aide vraiment. Honnêtement, je passe 50% de mon temps à programmer en C.

C rend les doigts plus forts!

Je programme en C pour que d'autres puissent programmer en Ruby.

Les internes de Ruby sont-ils écrits en C pur, pas ++?

Sur un propre. Ce serait bien si plus de ce code était écrit en Ruby, mais pour être honnête, certaines des principales choses pour des raisons de performances devraient être écrites en C. L'une des choses que je fais ... Nous devons améliorer le profilage de la mémoire. Par conséquent, je travaille sur des outils de profilage de mémoire dans Ruby. Puisque tous les intérieurs sont écrits en C, je dois écrire des outils en C. Au travail, j'écris beaucoup de code.

Comment Ruby s'en sort avec FFI et autres?

FFI fonctionne assez bien si vous avez une bibliothèque C dans votre travail qui a besoin d'une ou deux fonctions. Si quelque chose est plus compliqué ... Alors tout est plus compliqué. Lorsque vous travaillez avec FFI, vous écrivez essentiellement du code C similaire à Ruby. Cependant, vous devez toujours faire des choses mystérieuses comme la gestion de la mémoire. Personnellement, je trouve plus facile de basculer entre ces mondes si vous utilisez C pour gérer la mémoire, etc. Et dans d'autres cas, je passe à Ruby.

Dans Ruby, avons-nous des interfaces avec d'autres langues?

Quelques interfaces avec JavaScript. J'ai vu un gars qui était engagé dans des tâches scientifiques, alors il s'est interfacé avec Python.

At-il interagi directement avec le langage d'exécution?

Oui, exactement. Pas comme des bombardements ou quelque chose comme ça ... Le projet est encore très expérimental. Quand il donne une démo, il dit que "tout fonctionne, mais ça peut tomber!"

Je connais un tas de rubistes célèbres qui sont allés créer Rust. Pourquoi pensez-vous que les gens ont fait ça et comment vont-ils?

J'aime Rust, je pense que c'est une très bonne langue. La raison pour laquelle les gens vont à Rust ... ils veulent un langage qui a plus de fonctionnalités de sécurité que C fournit. Ce serait vraiment génial de réécrire Ruby in Rust. Personnellement, je suis un grand fan de Rust, je l'aime.

Comment cela peut-il être utile? Est-ce plus sûr, plus rapide ou quoi?

Je pense que c'est plus sûr. Je ne sais pas s'il est plus optimisé que C, mais il est définitivement plus sûr. C'est ce que j'aime chez lui. Quand j'écris du code C, je suis presque sûr que ce n'est pas SEGV, mais ce n'est pas sûr à 100%. Mais quand j'écris dans Rust, j'en suis sûr beaucoup plus. Lorsque j'écris en C, je suis sûr qu'il n'y aura pas de fuite de mémoire. Avec Rust, il est clair comme un jour blanc qu'il n'y aura pas de fuite de mémoire. C'est pourquoi je préfère personnellement Rust plutôt que C. J'ai également commencé à apprendre Rust, car je veux écrire des extensions pour Ruby dessus. Il y a tout un projet appelé "Helix" - spécialement pour cela. Souvent, quand j'écris en C, c'est comme: "OK, j'ai une bibliothèque C, et je dois y accéder depuis Ruby en écrivant quelques béquilles." Utiliser de la rouille pour cela est un canon à moineau. Dans mon monde idéal, tout, tout le système sera un jour réécrit en Rust. La rouille sera notre nouveau C. Si vous devez résoudre rapidement un problème, vous écrivez en Ruby. Et le système d'exploitation sera fait sur Rust. Et tout le monde sera content.

La rouille est-elle suffisamment mature pour cela?

Eh bien, je ne sais pas. Je pense tout à fait. Chez Mozilla, ils l'utilisent - et sont satisfaits.

Quelle est la chance de «voir les registres» en exécutant un programme dans Rust?

Haha, je ne sais pas! J'espère bas! Voir cela n'est pas du tout ridicule.

Surtout lorsque vous lancez quelque chose dans le navigateur.

Oui Un message sur un crash apparaît et vous êtes comme ceci: "OK". Ha! Au travail, nous avons certaines choses en C ++, et parfois quand je tombe en panne, j'aime juste ceci: "Hmm ..."

Je veux programmer dans un langage, pas dans un assembleur de macros! - c'était ma blague préférée quand je suis passé de C à Ruby ...

Vous avez en fait raison. Chaque fois que j'écris en C, la question est de savoir à quoi dois-je penser. Je ne pense vraiment pas au problème résolu. Avec Ruby, je n'ai pas besoin de penser à tout cela (économie de bas niveau - P.A.). Je me concentre uniquement sur la logique du programme et je fais des affaires. C'est l'une des raisons pour lesquelles j'aime tant Ruby! Quand j'étais javiste pendant Java 1.3, c'était avant l'apparition des génériques. Chaque fois que je devais écrire quelque chose comme map - par exemple, des collections ou des itérateurs, je devais faire "iterator.next ()", puis transtyper la valeur résultante ... Seulement alors faire l'opération nécessaire. Ensuite, j'ai commencé à apprendre Ruby, où la carte était déjà en Perl ...

... Oh, un miracle! Entre mes mains, j'ai un objet du type exact dont j'ai besoin!

Oui, exactement. En Java, je devrais écrire 15 lignes de code pour réaliser ce que je peux faire comme une seule ligne dans Ruby. J'écrirais en Ruby, je finirais le travail beaucoup plus vite! Au lieu d'écrire toutes ces ordures! Comprendre cela m'a énervé dans ce travail. J'ai passé des heures sur du trafic supplémentaire!

Horreur existentielle!

Exactement! Ce fut un tournant. J'avais besoin de trouver du travail sur Ruby. Je ne peux pas couper java jusqu'à la fin de ma vie!

Peut-on soutenir que Ruby améliore l'esprit du programmeur?

Je pense que si vous pouvez consacrer plus de temps à des tâches de haut niveau, aux objectifs mêmes du programme, cela contribuera à améliorer la pensée abstraite. Vous vous entraînez de plus en plus à penser au système dans son ensemble, et non aux minuscules rouages ​​du programme. Permettez-moi de vous rappeler qu'en C je dois constamment penser à toutes ces bagatelles, et non au problème que je résous. En fait, vous apprenez exactement la résolution de problèmes, c'est-à-dire les tâches de niveau supérieur. Je pense que cela peut vous améliorer en tant que programmeur.

Je me souviens de ma propre impression quand j'ai commencé dans les années 90. J'ai essayé de maîtriser la POO. J'ai essayé de faire du C ++. J'ai lu des livres, j'ai appris la "Sainte Trinité de l'OLP". Et puis je me retrouve à nouveau en train de maîtriser toutes les mêmes astuces de «macroassembleur». Ensuite j'ai essayé de travailler en Java, j'ai gagné de l'argent en Perl. Et ce n'est que dans Ruby que j'ai finalement compris comment fonctionne la POO.

Vous dites la chose. Si vous pensez à d'autres langages OOP, tels que C ++ ou Java, alors tous n'ont pas d'objet. Par exemple, il ne reste que des pouces. Il existe encore des primitives et elles doivent être traitées différemment des objets. En Ruby, en fait, tout est un objet. Seul le POO doit être traité. Plus d'exercice, plus de sens. Je n'y ai vraiment pas réfléchi avant que tu ne demandes.

La langue est conçue si soigneusement qu'elle vous fait juste penser dans la bonne direction. Cela façonne l'esprit. La syntaxe elle-même explique ce que vous faites.

J'ai travaillé avec OOP en Perl. Ce n'est généralement qu'un hack pour les choses de type POO. Java, bien sûr, implémente la POO. Mais elle, entre autres, a des non-objets. Ruby sur notre liste est la première langue dans laquelle tout est vraiment un objet.

Avec quels mots inspireriez-vous les jeunes programmeurs et les anciens?

Bonne question! Je pense que c'est ce qui fonctionne pour les jeunes et les vieux rubistes: Personnellement, je pense que Ruby est le seul langage qui, lorsqu'il est utilisé, donne un fan. Les jeunes programmeurs qui maîtrisent déjà d'autres langues, essayez Ruby, car c'est vraiment amusant. Anciens programmeurs avec une solide expérience dans d'autres langues, vous pouvez tout comparer et comprendre à quel point Ruby est bon. Lorsque vous commencez à utiliser autre chose, vous vous direz: wow, mais Ruby n'est rien!

Le week-end, je fais quelques petits exercices dans d'autres langues. Après le week-end, je retourne au travail, ouvre mes Emacs avec Ruby et me dis: "Oh mon Dieu, comme c'est merveilleux de retourner dans ta patrie!"

Oui, je pense que c'est bien de passer à d'autres langues, d'y travailler, d'accumuler quelques observations. Je suis toujours ravi de revenir. J'ai l'impression d'être chez moi à Ruby.

Il sera possible de poser personnellement des questions à Aaron le 6 octobre. Alors rendez-vous à la conférence! Tous les détails sur le site .

Vous pouvez lire l'original en anglais sur hype.codes .

Et un grand merci aux entreprises qui soutiennent le principal événement Ruby en Russie:

Associé commandité - Toptal
Partenaires Or - Gett et Cookpad
Partenaires Silver - Instamart , UCHi.ru , JetBrains et Qlean
Partenaire Afterparty - Teachbase
Partenaires Bronze - Bookmate et InSales