Andrey Sitnik d'
Evil Martians est l'un des noms russes les plus célèbres du front: ses projets
PostCSS et
AutoPrefixer ont des dizaines de milliers d'étoiles GitHub. Mais comme Andrei vit à New York et voyage partout sur la planète, vous pouvez rarement le trouver en Russie.
En mai, il sera à Saint-Pétersbourg à la conférence HolyJS, et
Dmitry Dmitry Makhnev Makhnev et
Maxim Yuzva, membres du comité du programme HolyJS, lui ont posé des questions détaillées à
ce sujet. Pourquoi Andrei pense-t-il que le frontend stagne et que le code de nos projets est trop gonflé? Quelles sont les différences entre les communautés informatiques des différents pays? Comment apprendre l'anglais et pourquoi est-il moins important qu'il n'y paraît? Où est passé le projet Logux présenté à HolyJS en 2016?
À propos des projets en cours
Dmitry: Tout d'abord, parlez-nous brièvement de vous - où êtes-vous et que faites-vous.
Andrey: Je m'appelle Andrey Sitnik, j'habite à New York, mais j'essaie beaucoup de voyager. Surtout, ils me connaissent par l'open source et les performances - comme il est maintenant populaire de dire, "une marque médiatique dans le domaine de l'informatique". Je ne peux pas dire que je le méritais vraiment, mais la chance a contribué à moi.
En plus de l'open source, je fais également la promotion de la diversité linguistique sur Twitter
@LinguoPunk , Wikipedia sur
@LostInWiki et la lutte pour le positivisme sexuel.
Dmitry: Sur quels projets travaillez-vous actuellement?
Andrew: En open source, il existe plusieurs projets de support, les plus célèbres étant PostCSS et Autoprefixer. Peut-être que PostCSS est maintenant légèrement activé: Alexey Bondarenko a
fait une très grande mise à jour de l'API, donc il pourrait y avoir une grosse version bientôt.
Et Autoprefixer prend en charge les versions. La seule chose que nous voyons activement maintenant est le support de Grid pour IE 10-11, mais cela va mal en raison de la
résistance de Rachel Andrew, qui faisait activement la promotion de Grid. C'est une personne très célèbre, et elle n'aime pas les outils qui font automatiquement quoi que ce soit en CSS - une telle lutte religieuse. Et en raison de son opposition, cette fonctionnalité, malheureusement, ne s'est pas particulièrement répandue.
Dmitry: Comment Rachel peut-elle vous empêcher de fabriquer un instrument?
Andrew: L' outil n'interfère pas avec quoi que ce soit, il fonctionne. Mais l'open source n'est pas une question de programmation, l'open source concerne la société et la socialisation. Si personne n'utilise votre produit ou n'en parle comme média, il n'y a aucune motivation à le faire. En conséquence, cela frappe la motivation des développeurs qui l'ont fait et continuent de le faire. Peu de gens parlent de leur héroïsme, mais ils sont toujours de bons camarades et de vrais héros.
En fait, nous avons réalisé tout ce que nous voulions et pouvions, il y a même une idée folle avec le soutien des grilles automobiles, ce qui est généralement impossible à faire sur cette spécification, mais les gars ont compris comment le faire avec une combinaison astucieuse de magie de sélecteur.
En général, PostCSS et Autoprefixer sont pris en charge, il y a rarement des fonctionnalités ajoutées et principalement de petites, mais Logux se développe activement. Et cette année, je veux consacrer plus à des articles qu'à un projet open source spécifique.
Dmitry: Vous avez fait beaucoup de licenciements, mais à propos de Logux après la
présentation à HolyJS en 2016, vous n'entendez pas vraiment ce qui lui est arrivé?
Andrew: C'est une bonne question, car elle soulève un sujet très intéressant. Le fait est qu'il existe différentes manières de distribuer les logiciels.
Utiliser l'open source n'est pas une sorte de prise de décision rationnelle. Le développement de logiciels est mieux décrit par l'industrie de la mode. Le choix technique est, tout d'abord, la mode, le battage médiatique et des choses similaires.
Par conséquent, il existe plusieurs stratégies pour promouvoir de nouvelles solutions. Par exemple, quand quelque chose apparaît, cela ne fonctionne toujours pas comme il se doit, mais par crainte de manquer quelque chose d'énorme, les gens montent rapidement dans un train hype, commencent à scier et à le mettre en condition de travail.
Dans le bon sens, plus de la moitié des projets open source populaires ont été écrits simplement dégoûtants. Au contraire, le battage médiatique autour d'eux est complètement incompatible avec la qualité du code et le niveau de soutien des organisateurs. Mais comme beaucoup de gens se sont assis immédiatement dans le train hype, le projet a survécu et a continué d'exister.
Par exemple, les plugins Babel n'ont pas d'asynchronie. Vous ne pouvez pas créer de fonctions asynchrones dans les plugins, et c'est un problème terrible, je ne sais pas comment il est entré en production, car il limite terriblement les énormes marchés des applications Babel. Mais ainsi il a été écrit, telle est son architecture. Babel s'amuse beaucoup.
C'est une façon de se répandre: dire "tout est parti, si vous n'apprenez pas demain - tout, le marché aura besoin de personnes avec trois ans d'expérience dans cette technologie." Mais il y a une autre façon. Par exemple, dans React, ils l'ont fait différemment: ils ont d'abord «cuisiné» dans leur environnement, puis ils ont présenté un projet plus ou moins prêt pour la production. Bien sûr, la question ouverte est de savoir exactement comment il était prêt pour la production, mais il est clair que les cadres ne sont pas préparés à 100%.
Logux est un système de communication client / serveur. L'idée des requêtes, qu'elles soient GraphQL ou Ajax, n'est pas destinée à un Internet instable et fonctionne dans de telles conditions simplement dégoûtantes - c'est un problème connu de la plupart des sites. Logux est une approche différente et, par conséquent, est techniquement une très grande solution. L'idée n'est pas nouvelle, il existe de nombreuses solutions de ce type, elles ont échoué et cela m'a inquiété. Même GraphQL a été fait avec un craquement terrible, et cela aurait dû apprendre quelque chose.
Mon opinion est que le battage médiatique ne fonctionne pas pour ce type de tâche. Nous ne pouvons pas prendre de décision pour que tout le monde s'y heurte et que tout se passe. Lorsque nous livrons la solution immédiatement pour le frontend et le backend, les tentatives de tout retirer dans le train hype conduisent à une confrontation entre les communautés.
Par conséquent, j'ai décidé qu'avec Logux nous ne ferons pas cela, mais nous irons prudemment et lentement, en le préparant à l'intérieur du projet. Toute cette année ou deux, nous avons cuisiné Logux dans
Amplifer , l'
avons utilisé sur différents projets et regardé comment les backders réagissaient. J'ai essayé d'expliquer, de montrer, et maintenant Dima Salakhutdinov ira au Ruby-confu pour
parler de Logux, afin que nous puissions voir comment ils réagissent, comment nous donnons des relations publiques au back-end. Parce que leur dire ce que nous disons aux fournisseurs frontaux dans l'esprit de «c'est du battage médiatique» est faux, cela ne fonctionne pas là-bas.
Dmitry: Pourquoi ça ne marche pas?
Andrew: Le backend est passé à un système de stagnation ou de support: ces dernières années, il n'y a pratiquement pas eu de développement. Et par conséquent, ils ont des priorités différentes: lorsque vous n'avez pas de nouveaux cadres tous les six mois, cela vous affecte. Ils sont quelque part à Rust or Go, mais Ruby - quoi de neuf? En conséquence, les gens se concentrent sur l'autre. Bien sûr, je simplifie grandement et le backend backend est différent.
Je veux distribuer correctement cela sur le backend et sur le client, je veux venir avec une solution prête à l'emploi qui fonctionnera vraiment, que nous avons vraiment testée en production. En 2017-2018, nous avions déjà une version de travail de 0,2, mais il n'y avait pas d'évolutivité. Nous avions une idée de la mise à l'échelle, et pour les RP, ce serait suffisant, mais en fait, c'est faux.
Au lieu de cela, nous traitons les problèmes d'évolutivité réelle, plutôt que théorique, lorsqu'elle est incompréhensible pour vous et que vous ne savez pas à quel moment. Et dans Logux, nous avons sérieusement pompé le système: par exemple, nous pouvons facilement augmenter le serveur sur plusieurs serveurs à la fois, et avec une seule commande pour augmenter leur nombre.
Il est inutile de le faire tant que vous ne disposez pas de véritables analyses. Parce que sans cela, vous ne comprendrez pas où vous avez obtenu la prise. Vous pouvez évoluer autant que vous le souhaitez, mais il s'avère qu'il y a un endroit qui ne se redimensionne pas. Par conséquent, nous avons un code qui est vraiment prêt pour la mise à l'échelle, et un grand nombre d'analyses: comment et combien de temps est passé, combien de demandes entrent, vous pouvez voir où commence le plug. Par exemple, par le nombre d'opérations par seconde ou par le nombre d'utilisateurs, et tout cela sur le serveur est résolu différemment.
Dmitry: Cela semble assez intéressant. Et, si je comprends bien, les plans sont assez grands pour un avenir proche?
Andrei: Oui, nous avons déjà terminé les plans d'application pratique, je vais maintenant publier la version 0.3 et écrire des quais qui ne suffisent pas pour une application de masse. Et le code est bon.
À propos de Nano ID et d'Internet rapide
Dmitry: Vous avez abordé le sujet de la connexion Internet: tout le monde est habitué au fait que notre Internet est stable et bon, mais en fait tout est complètement faux. Et ici, il est impossible de ne pas faire attention à la taille des bundles et autres choses, souvenez-vous de votre projet Nano ID. Pourquoi cela vous dérange-t-il autant? Commençons par la taille.
Andrei: Ne me semble-t-il pas que c'est "économiser sur les matchs" quand tout le monde a un Internet normal? Bonne question.
Nano ID est une bibliothèque de 141 octets qui génère des ID. Lorsque nous l'avons réduit de 200 octets, cela n'avait aucun sens pratique, mais c'était un "manifeste politique" qu'il était temps d'y penser.
La taille JS est un problème intéressant. Premièrement, les compilateurs ne le résolvent pas, mais vice versa: la plupart des bundlers se combinent incorrectement, augmentent considérablement la taille ou l'utilisent de manière inefficace.
Et le fait que la vitesse des connexions Internet augmente est vrai, et en même temps pas. Dès que l'Internet accélère, les pays se déclarent là où tout va très mal avec lui - par exemple, en Afrique centrale. Et de nouveaux marchés apparaissent également - par exemple, le mobile. Et il y a un problème délicat: les vitesses de téléchargement augmentent, mais les sites ne se chargent pas plus rapidement. Vous pouvez vérifier certains LTE, qui devraient rapidement tout ouvrir, si vous divisez la taille de la page du site par la vitesse du réseau.
Le problème est que la vitesse de chargement réelle du site dépend d'autres paramètres. Par exemple, le
nombre d'aller-retour . Le fait est qu'entre les requêtes et les premiers octets, un certain temps s'écoule inévitablement lorsque le signal arrive et revient. Ce temps est très long, jusqu'à
500 ms . Premièrement, en raison de la vitesse de la lumière, deuxièmement, l'équipement est lent. Et si vos fichiers se chargent à leur tour, le site ralentira.
Heureusement, nous avons découvert ce problème il y a longtemps et avons appris à le résoudre. Mais elle n'est pas la seule. Récemment, nous en sommes tombés sur un autre: il s'avère que le problème n'est pas sur Internet, mais dans la vitesse de compilation. Le fait est que 1 mégaoctet d'images est facile à télécharger et à afficher, et 1 mégaoctet de JavaScript est 2-3 fois plus lourd pour le navigateur, car il doit être compilé. Et le nombre de JS augmente. Et c'est un problème objectif des sites à faible vitesse.
Vous pouvez habilement aborder la question de l'étude du site en utilisant la méthode de l'
entropie . Nous avons un site Web qui pèse 1 Mo. Il y a le concept de «quantité d'informations». Un mégaoctet n'est pas seulement le nombre de lignes, c'est le sens contenu dans ce code. Et dans quelle mesure un site doit-il être complexe pour exiger 1 Mo? Y a-t-il vraiment tellement de cas d'utilisateurs sur le site qu'il doit y avoir un tel volume de code pour les couvrir?
En fait, de tels cas sont peu nombreux. Il y en a tellement besoin dans le noyau Linux, mais pas sur les sites. Et donc, nous avons un tas de code redondant.
Le sens du mouvement Nano ID n'est pas de sauvegarder chaque octet, mais de penser: «qu'est-ce que j'ai dans le bundle? Que diable ai-je là 1 Mo? Je ne peux pas avoir de tâches où un tel volume serait nécessaire. » Sur la plupart des sites, 75% du code n'est pas utilisé. Nano ID est un mouvement contre nous envoyant ce code aux utilisateurs.
Lorsque nous commençons à penser pourquoi tant de code n'est pas utilisé, nous comprenons que si ce n'est pas une équipe énorme, un mégaoctet de code ne peut pas être écrit manuellement. C'est plus que la «guerre et la paix» conventionnelle, qui peut être écrite au fil des ans, et le code est beaucoup plus difficile à écrire en raison des interdépendances.
Et le plus souvent, ce volume est constitué de bibliothèques. L'histoire célèbre avec Moment.js: vous le connectez, et en raison des particularités de l'opération webpack, il
charge toutes les langues sur votre site Web . Et il existe de nombreux cas similaires.
À un moment donné, j'avais besoin de générer un ID unique dans Logux, j'ai pris une bibliothèque, puis j'ai trouvé qu'elle pesait 100 Ko. Pourquoi ai-je tant besoin de générer un ID aléatoire?
De telles tailles sont le plus souvent dues au fait que les développeurs de bibliothèques les orthographient incorrectement. Par conséquent, l'idée principale est d'utiliser la
limite de taille afin que les développeurs de bibliothèques contrôlent la taille de leurs projets. Comme ESLint, juste pour la taille de la bibliothèque. Et nous constatons immédiatement qu'un grand nombre de bibliothèques peuvent être divisées par deux.
Dmitry: Ne vous semble-t-il pas que la question ne concerne pas seulement la taille du code, mais aussi les approches des outils de développement? Si j'exporte ma bibliothèque en tant qu'objet au lieu de fonctions individuelles et que je ne connecte pas le compilateur Google Closure à mes risques et périls, personne ne me coupera quoi que ce soit. Le problème pourrait-il être plus profond que la simple écriture de code?
Andrew: Je ne dirais pas que le problème de tremblement d'arbre est vraiment pertinent, car il ne fonctionne pas en JavaScript. Tout le monde pense que le trichashing résoudra le problème, mais non. Le problème le plus courant est différent: ce que fait le package. Ils utilisent un
Rollup , regroupent l'ensemble du projet dans un seul fichier, et il s'avère que, par exemple, les dépendances y sont compressées. C'est un énorme problème, et avec l'aide de Size Limit, nous avons considérablement réduit une bibliothèque, car nous avons supprimé les dépendances susceptibles d'être répétées dans chaque projet.
Le deuxième problème est qu'ils utilisent accidentellement une API de Node.js. Par exemple, il y avait une bibliothèque
choo.js - «compact JS-framework», où ils vérifiaient les arguments entrants en utilisant l'assertion Node.js-module. Et il charge près de 4 Ko. Et pour le plaisir d'une petite bibliothèque, nous expédions 4 Ko supplémentaires.
Et ces problèmes sont beaucoup plus fréquents que ce pour quoi le tremblement d'arbre est utilisé.
La meilleure recommandation pour trishaking est de diviser les fichiers dans l'assembly, qu'il y ait des fonctions distinctes dans des fichiers séparés. Mais le plus souvent, le problème est différent. Exécutez simplement Size Limit avec l'option --why et voyez l'énorme quantité de déchets que le webpack intègre lors de l'utilisation de votre module.
Maxim: Ensuite, il s'avère que l'utilisation de webpack pour l'assemblage est une mauvaise manière?
Andrew: Regarder de quoi parler. Si vous créez une bibliothèque, le webpack n'est probablement pas nécessaire. Vous avez moins de 1% d'utilisateurs qui veulent un fichier séparé, et en même temps, il est préférable de les forcer à utiliser webpack, car ils insèrent votre bibliothèque en tant que lien vers un autre fichier, et le site ralentira.
Mais ce que les utilisateurs collectent vos bibliothèques, ce que les gens collectent des sites - en fait, aucune différence. Nous sommes habitués à ce que si vous utilisez la bibliothèque de manière incorrecte, tout sera mauvais, si vous ne passez pas de Webpack à Parcel aujourd'hui, alors tout va au revoir, vous êtes un mauvais développeur. Non, pour être honnête, ne vous souciez pas des outils.
Il y a beaucoup de problèmes avec webpack, c'est un mauvais bundler, mais si cela fonctionne pour vous, alors travaillez. J'ai vu des projets où il aide à résoudre des problèmes, bien que ce soit l'un des projets les plus abandonnés. Par exemple, css-loader est pris en charge par
une personne de Russie. C'est un vrai héros, mais s'il est occupé - c'est tout, personne ne résoudra votre problème, mais il y a beaucoup de problèmes.
Si je dis que vous devez cesser d'utiliser Webpack, c'est uniquement parce qu'il existe de meilleurs collectionneurs. Mais, encore une fois, essayez un nouveau projet et ne changez pas l'ancien. Nous nous masturbons beaucoup sur les frameworks et les outils, bien qu'en fait ils n'affectent pas du tout la façon dont nous créons le code.
Pourquoi le battage médiatique et les aristocrates sont mauvais
Maxim: Vous venez de parler d'éviter le webpack au profit de bundlers plus cool. Peut-être y a-t-il un problème dans le fait que de telles recommandations de personnes de votre niveau créent un battage médiatique? Au lieu de recommander l'utilisation de quelque chose de nouveau, peut-être simplement dire «poussons et rendons le webpack génial à nouveau»?
Andrew: Bonne question. D'une part, il y a vraiment un problème lorsque de tels commentaires sont perçus sans comprendre le contexte. Mais il y a un autre problème: je crains la stagnation.
Le fait est que le frontend stagne. Jusqu'à la fin de nos vies, nous vivrons sous les auspices de React - aucun nouveau cadre ne peut le déplacer, car la masse critique est acquise. C'est comme dans les langages d'arrière-plan: les anciennes langues ne sont pas vaincues par les nouvelles, car il n'y a pas de masse critique, de conditions de transition, sauf dans certaines tâches étroites. Maintenant, le front-end a commencé.
La stagnation des cadres et des systèmes de construction signifie un très gros problème: la stagnation des gens qui nous apprendront comment vivre. Nous le voyons en ce moment, car les étoiles du front-end sont toujours les mêmes et, par conséquent, de nouvelles ne viendront pas. Et la stagnation des gens signifie aussi la stagnation des idées. Nous le voyons jusqu'à présent par des paramètres indirects, alors qu'il y a suffisamment d'inertie pour apporter de nouvelles idées. Mais vous venez à la conférence, et tout est pareil, et ça me déprime vraiment. À mon avis, il est temps de faire tomber le monde frontal.
C'est comme Java - un immense marché où tout va bien, mais il n'y a rien de nouveau. Comment faire face à ce problème - je ne sais pas. Mais c'est une des raisons pour lesquelles je me noie pour de petits projets et les conseille constamment.
Honnêtement, le webpack est très difficile à réécrire, et son créateur ne se soucie pas de la qualité DX, il l'écrit pour lui-même et communique peu avec les utilisateurs. De plus, il y a des problèmes architecturaux qui rendent la réécriture vraiment difficile. Il y a des gens dans l'équipe du webpack qui essaient honnêtement de bien faire, mais il y a des difficultés qui nous empêchent de le faire.
Il y a une communauté, et où la déplacer - pour stabiliser et ajouter de vieux outils ou en utiliser de nouveaux - je n'ai pas de réponse.
Dans un monde idéal, nous ne créerons pas le sentiment que l'utilisation d'anciens outils est mauvaise, mais nous en utiliserons de nouveaux sur de nouveaux projets. Et je ne sais pas comment le créer. En effet, les mauvaises recommandations sont faites et les gens commencent à empoisonner les autres pour avoir utilisé les «mauvaises» choses.
Maxim: À votre avis, est-il possible que de grandes sociétés comme Microsoft et Facebook commencent à acheter de grands projets open source comme webpack et Babel?
Andrew: Pour acheter - non. Ce n'est pas avantageux pour eux, tant que la communauté apporte de nouvelles idées, et c'est un réel avantage commercial. Ils les contrôlent, cela fonctionne différemment.
Malheureusement, ce problème est déjà survenu dans le front-end, mais il ne s'exprime pas dans le fait que la société a acheté quelque chose, mais dans le fait que nous avons des stars qui ne changeront pas, elles seront toujours à l'étage et diront comment nous allons écrire du code. Ils se connaissent, il est plus facile pour eux de s'approcher et de leur demander de faire quelque chose. Par conséquent, leur opinion est plus importante que celle des autres. Il s'agit d'un système classique de création d'élites dans la société.
Sans système d'ascenseurs sociaux, cela conduit au fait que les élites sont conservées, les idées vieillissent. Et le problème n'est pas que les entreprises les contrôlent, mais que nous avons un très petit groupe de personnes qui décident quelle interface nous aurons. Le fonctionnement du navigateur est entièrement déterminé par un très petit groupe de personnes travaillant sur Chrome. Si Chrome continue de gagner en popularité, il y aura un gros problème.
— , . , - , : , . , , , , . , , .
: « » - , ?
: . , , — . , ,
[] . ?
: , . - , , - , .
: , . , — , ,
37signals DHH .
, , , . , , , - . , , .
, . , IT .
DHH , , : , , , . , .
: . -, - - , , ?
: Vue.js. , React, , React. , : , .
« , , », , 20–30% . — . , , Google .
Google , , . , - Instagram Facebook, , , , . . , Vue : , React .
, Vue , . , , . — , , win/win. - .
, , , -, - , , , , - .
: , .
: . : , , -.
, — : , , . « ». , , , , .
-, , 99- . , Size Limit,
, , , , Size Limit .
, : - , , , , , , . , , . .
. — « , Google», « , Google, , 99% ».
, , . , , . : , , .
, - pull request Babel, , - . , , — , .
, , - . , , . , .
— - . , PostCSS , , CSS-. Autoprefixer , Compass, , Compass , , , , Opera .
, , , . Accessibility, , URL, , . , — , . , , , Autoprefixer.
, , , , , , , .
: ? , , , JavaScript , , . , ?
: , , — , . — .
: . , , , .
: , , , , , . , . , .
- , … PostCSS , , . , , . - -, , , , , .
: ?
: , , .
: , , , ?
: , , , , - , , , , , . : «
Open Collective , , ».
, . . . , , , . « , , . Open Collective, , . , , , ».
, Babel webpack. : « , . issue,
Open Collective , ». , . , — . , , . , .
, , . -, issue, , maintainer, , , , . , issue, : «, , , . . , , ?» . , «», . , , .
: - , - ?
: . . , JavaScript , . , Ruby , JavaScript. . - , . , , JavaScript.
: , pet project . , , : , , -, , . , , ?
: - . , . , , .
« ». . , . , . — , , maintainer , , - .
, . , , . , , , issue, - , , , .
, ? Pas question. , , , . , , .
: , ?
: , .
. . , .
: , , . , . , -, , . , , .
, . , 10, , , , , .
: , , ? , - : « , ».
: , , , . , . , . «» — , , — . , , - PostCSS. .
, - , . - : , , , , , .
— . , , , , , , . , . — , . , .
,
Dmitry: Vous avez dit que PostCSS aide à voyager. Combien voyagez-vous et comment combinez-vous cela avec le travail?
Andrew: Honnêtement, le travail est encore meilleur. Je viens d'arriver à New York après un court voyage. C'est un voyage difficile, il y a un mauvais Internet au Maroc, c'est impossible de travailler, mais en réalité j'ai fait quelque chose d'utile tous les jours: j'ai écrit un article, j'ai fait deux sites en utilisant une technique complètement nouvelle.
Arrivé à New York, assis, regardant YouTube. Je voyage pour travailler normalement et efficacement. Au même endroit, je suis immédiatement devenu une gaufre, allongé sur le canapé. Je voyage pour être plus productif, donc la combinaison est facile.
La seule règle: ne pensez pas que vous pourrez le regarder dans une nouvelle ville, en travaillant, dans une journée. Venez avec une énorme marge. Ne pensez pas que vous marcherez partout, vous travaillerez vraiment de la même manière. Vous serez un pigiste turc ordinaire qui se réveille et travaille, mange dans la rue, travaille, regarde des émissions de télévision et dort. Si vous ne changez pas la ville plus d'une fois toutes les deux semaines, tout ira bien. Il n'y a pas de problèmes particuliers.
Maxim: Tout le monde comprend que la connaissance de l'anglais est nécessaire, mais ce n'est pas si facile d'apprendre bien. Aviez-vous une bonne formation? Où as-tu eu un bon anglais?
Andrew: Riez-vous? J'ai un anglais dégoûtant. Je soulève ce sujet à Lingvopank. Nous sommes habitués à l'école que la langue est la règle, en particulier avec la culture russe toxique, où nous critiquons constamment différentes personnes. Nous sommes habitués au fait que si vous dites et faites une erreur, alors tout va mal.
En fait, la langue est un système de communication, et tant que vous êtes compris, tout va bien. Nous ne comprenons pas comment la langue est un système en double. C'est comme un CD ou un code QR. Vous savez qu'un code QR peut être détruit en grande partie et qu'il sera toujours lisible? Parce qu'il existe des algorithmes spéciaux pour dupliquer les informations. Le fait est que vous n'avez pas besoin de bien connaître la langue, vous devez être capable de communiquer avec elle.
Mon principal progrès dans la langue s'est produit quand j'ai juste arrêté d'avoir peur. Nous avons tous peur, parce que nous sommes constamment intimidés à l'école et sur Internet - un terrible twitter russe, où ils nous blâment plus pour une faute de frappe que pour une anti-idée. En fait, les Russes ont un bon anglais. À commencer par le fait qu'il s'agit de langues étroitement liées: pas du chinois, où vous avez généralement un système linguistique différent. On ne peut pas imaginer, comme dans le reste du monde, c'est encore pire là-bas.
La Russie est à un niveau normal. Bien sûr, pire que la Norvège et les petits pays similaires qui doivent simplement apprendre la langue, car il n'y a pas de contenu. Mais le reste des Russes parle bien anglais, il n'y a pas de problèmes. La règle principale - n'ayez pas peur, communiquez simplement, passez à la langue des signes, prenez un verre avant la discussion (cela aide à comprendre que les choses simples sont vraiment importantes).
Le deuxième point - regarder des séries avec sous-titres, ça aide vraiment.
Voyagez, apprenez simplement la langue.
Et surtout - essayez de parler.
Nous avons peur de la langue, car en Russie il y a un problème: nous communiquons très peu avec le monde extérieur. D'une part, c'est bien, car il y a un marché intérieur qui permet à quelques petites personnes de sortir. Alors que Yandex est sorti du monopole de Google en raison de la barrière de la langue, il existe également un grand nombre d'ascenseurs sociaux qu'un programmeur peut escalader, ce qui ne se produirait jamais en Occident.
Mais en contrepartie il y a un problème de fermeture du marché, on ne regarde pas dehors et tous les gens qui se sont levés, vraiment bons mecs, ne vont pas en Occident, parce qu'ils ont peur de l'anglais. Ma recommandation est d'avoir deux comptes Twitter, d'écrire en russe en un pour aider votre culture (c'est aussi important) et en anglais pour la pratique. Lorsque vous écrivez en anglais, vous comprendrez que ce n'est pas difficile. La seule chose est que peu de gens vous liront, car en Occident il y en a assez, mais la masse critique gagne donc de toute façon, vous gagnerez vos 150-300 lecteurs.
Participez à des réunions anglophones en Russie, ce n'est pas effrayant, personne ne vous offensera, tout va bien.
Dmitry: Recommandez-vous d'essayer de vous déplacer quelque part pour apprendre la langue, si oui, où?
Andrew: Pour se débarrasser de la peur, tout voyage suffit. Mais comment apprendre davantage est une bonne question. Honnêtement, je ne sais pas, je ne connais pas bien la langue. Mais je peux dire que lorsque vous parlez lors d'un rassemblement à New York, même si le public perçoit à peine votre accent, alors tout de même, car la moitié du public indien, la moitié chinoise.
Et je peux dire autre chose. En Russie, il y a un récit populaire qui doit être blâmé, et partout est bon: "En Russie, tout est mauvais, je vais jeter et je serai heureux." Honnêtement - c'est la motivation qui vaut mieux ne pas être guidé. Parce que le récit est très ancien, et historiquement, nous savons qu'il ne fonctionne pas du XVIIIe au XIXe siècle. Dans d'autres pays, pas fondamentalement mieux. Il existe des problèmes de gestion fondamentaux, mais tôt ou tard, ils apparaissent dans tous les pays.
Il y a un problème de choix lorsque vous avez une tâche, et elle est résolue de différentes manières. Par exemple, nous voulons que la rue soit nettoyée, et pour cela, en fait, nous avons besoin d'une société centralisée. Pour ce faire, il faut opprimer tous ceux qui pensent mal, comme aux États-Unis. Il existe un système très strict de règles internes et d'équilibres sur qui devrait penser comment et, en fait, les États-Unis à cet égard sont similaires à la Chine. C’est juste que les règles ne sont pas dites et que l’État ne le fait pas - la société le fait.
Je ne dirais pas qu'il y a une solution définitive là où c'est mieux - où les routes sont cassées, ou où la société dit comment vous devriez penser. Mais ce n'est pas une solution binaire, et c'est une question de politique et de sociologie. Et le schéma général: souvent, d'autres pays sont à certains égards meilleurs, parce que dans d'autres endroits pire.
Il vaut mieux ne pas bouger tout de suite, mais voyager à travers le monde, et alors vous vous rendrez compte qu’il est généralement important de savoir ce que vous êtes prêt à donner afin d’obtenir d’autres choses en retour. Et avec cette compréhension, vous pouvez choisir le pays où vous pouvez vous déplacer. Et puis se déplaçant normalement.
Mais pour être honnête, vous ne serez pas heureux, car la première vague d'émigration est toujours de vivre de terribles souffrances, d'être déprimé, après avoir déménagé, vous perdrez tout votre cercle social.
Dmitry: Je voudrais savoir quelle est la différence dans la communauté russe des développeurs des autres pays.
Andrei: En parlant des États, c'est une situation intéressante. Premièrement, il y a vraiment un système rigide d'imposer une philosophie. Elle a toujours été, ils ont un système de punition strict, par exemple, le harcèlement public. Mais le système est assez ancien et, en général, fonctionne. Honnêtement, d'un autre côté, elle utilise le plus souvent les bonnes idées pour se propager, et les mauvaises, eh bien, les excès sur le terrain.
L'idée principale est qu'il existe une pensée très stéréotypée dans la culture afin de diffuser rapidement les bonnes pratiques. Là, un grand nombre de programmeurs ne font pas d'erreurs stupides, parce que tout le monde a été dit d'écrire comme ça, tout le monde écrit comme ça. Au lieu de cela, il est assez difficile de promouvoir vos idées.
Et il existe une culture particulière de la petite conversation - l'intimidation pour de mauvaises idées crée des tensions sociales, et aux États-Unis, il existe un grand nombre de nations, et ils ne savent pas comment mener des sujets de communication conflictuels sans recourir à l'intimidation, ils ont donc une liste de thèmes d'arrêt.
Il s'agit de la différence sociale la plus importante dans la communauté. Des avantages - ils sont faciles à grimper et font vraiment attention à ce que les gens ne souffrent pas. Vous venez, tout le monde est sympathique, tout va bien, tant que vous êtes une personne ordinaire qui respecte les règles.
La deuxième caractéristique intéressante est qu'ils paient souvent des mitaps, un prix symbolique de 5 à 10 dollars qui va à la nourriture. Encore une fois, parce que le capitalisme.
Dmitry: Et si ce n'est pas les USA, mais d'autres pays?
Andrew: En second lieu, par la façon dont j'ai étudié la communauté, c'est la Chine. Il existe une fonctionnalité intéressante dans un grand nombre de développeurs, et d'autre part, ils ont un format intéressant - très peu de réseautage. Il est généralement fermé, vous êtes invité à un "petit déjeuner spécial", qui a lieu avec les chefs de communauté. D'un autre côté, les personnes présentes aux réunions viennent vraiment parler de sujets complexes et absorber de nouvelles connaissances. Honnêtement, toutes ces fonctionnalités ne sont pas un cadre. La communauté est diversifiée et il y a suffisamment d'anarchistes en Chine; en Amérique, un grand nombre de personnes ont également craché des interdictions. Eh bien, en Russie, il y a des critiques accueillants, polis et bons, et non mesquins.
Une autre caractéristique intéressante de la Chine est qu'elle est fermée, avec un monde séparé, c'est à la fois un plus et un moins. Ils ont une énorme quantité de leurs réalisations, car il y a un endroit où ils peuvent se développer. Et d'un autre côté, ils souffrent terriblement du fait qu'ils ne peuvent pas mener à bien leurs développements, comme en Russie. Tous les meilleurs locuteurs chinois ont peur de parler anglais à partir du mot "général", bien qu'ils parlent normalement anglais.
Vient ensuite le Japon. Malgré le fait que ce soit un tel pays informatique, une superpuissance avec une technologie de pointe, la programmation est considérée comme pire que la gestion. On pense que, contrairement aux managers, la programmation est peu laborieuse: ils l'ont dit à la personne et il écrit le code. En conséquence, il n'y a pas de communauté, et l'informatique est développée de manière horrible, les startups sont développées incomparablement pire que les capacités du pays. Il n'y a pas de vallée, "génies programmeurs", c'est tout. Et il y a beaucoup moins de femmes dans les TI qu'en Chine, à cause de la société traditionnelle. En Chine, tout va bien - il y a beaucoup de femmes chinoises avec des vues et une expérience intéressantes, bien qu'il y ait aussi de la place pour grandir.
Il y a une bonne communauté brésilienne. Les pays hispaniques ne l'ont pas, car tout le monde est orienté vers l'Amérique. La France a également une bonne communauté interne.
Mais au Sri Lanka, tout va mal avec la communauté informatique, car quand ils épousent une fille, le plus souvent par le biais de sa famille, son père demande: "Avec quoi travaillez-vous?" Et il y a une liste blanche des «bonnes» professions, et les programmeurs ne s'y sont pas encore lancés. Par conséquent, il y a très peu de programmeurs, bien qu'il y ait beaucoup d'avantages potentiels: l'argent, la possibilité d'immigration. Un bon père apprécierait qu'il donne sa fille entre de bonnes mains, mais cela ne se produit pas, car la liste n'a pas encore été mise à jour.
Je vous conseille de parler lors de conférences chinoises et indiennes: il est facile de s'y rendre (ils acceptent volontiers une personne de l'extérieur), et vous pratiquez en anglais dans un environnement où vous n'aurez pas peur, car personne ne connaît vraiment l'anglais et tout le monde parle avec des erreurs.
Conférences idéales
Dmitry: Si nous parlions de conférences, quel est le facteur décisif pour participer en tant que conférencier?
Andrew: Pour moi, le facteur décisif est la disponibilité des conférences. Bien que parfois, si mon chemin passe par certains pays, j'accepte des conférences peu accessibles aux gens, juste pour pomper le rapport.
Je pense qu'il y a un gros problème que les prix des conférences sont très élevés. Je comprends que les conférences doivent faire de l'argent, cela ne pose aucun problème, mais il y a des JSConf qui prennent 500 $ fabuleux et, franchement, ils le dépensent pour ces choses qui peuvent être sauvées. Par exemple, pour les dîners, l'afterparty la plus puissante, même si, franchement, je préfère boire une bière désagréable, mais pour qu'il y ait des gens intéressants.
Et les prix énormes conduisent au fait que les intervenants ne sont pas intéressés à communiquer avec le public, il est parfois difficile de soutenir le sujet, car lors de la conférence seuls les employés de grandes entreprises, le même créateur de la meilleure mise en œuvre JS du CRDT
Viktor Grishchenko, n'ont pas pu venir, car un billet très cher. Il existe de nombreuses façons d'économiser, et elles doivent être appliquées, les billets coûteux sont faux. La conférence devrait être accessible.
J'accepte souvent d'aller à une petite réunion, juste pour que tout le monde ait un accès normal au réseautage. Et lors de nombreuses réunions, le dialogue est meilleur que lors de conférences avec un prix de billet élevé. Telle est mon approche.
Dmitry: Sans quoi une conférence ne peut pas être bonne? C'est déjà clair sur le réseautage, l'accessibilité et quoi d'autre?
Andrei: Eh bien, en tant que conférencier, j'apprécie vraiment quand il y a un chronomètre devant la scène. À cet égard, chez HolyJS tout est très professionnel, j'aime l'organisation de spectacles. En général, le réseautage est un élément clé, les gens vont à des conférences non pas pour des connaissances, il est plus facile de lire un article qu'un rapport, mais pour un sentiment d'appartenance à la communauté.
La communauté est la chose la plus importante qui se passe lors des conférences. Le sentiment que vous parlez, et quelque chose a changé en vous, vous savez quelque chose. Il y a une bonne idée que notre société ne comprend pas «pourquoi». Nous allons à des conférences pour comprendre pourquoi nous faisons tout cela. Et une bonne conférence résoudra probablement ce problème.
Dmitry: Vous avez dit «pas pour la connaissance», c'est une question très controversée. Souhaitez-vous aller à une conférence où est réunie une collection de personnes ayant des sujets très basiques, mais de communautés très différentes?
Andrei: Oui, bien sûr, ce serait très amusant.
Dmitry: Et ce serait plus intéressant qu'une conférence où il y a des rapports sérieux et puissants?
Andrei: Je pense que les deux approches sont bonnes, et il n'y a pas de problème ici.
Dmitry: Probablement la dernière question. Qu'attendez-vous de HolyJS?
Andrew: Bonne fête! En 2016, il a été directement crédité, l'un des meilleurs de ma vie, puis tout s'est très bien organisé.
Dmitry: Que recommanderiez-vous de faire cette fois pour le rendre encore meilleur? Envie d'une fête?
Andrew: J'essaierais de m'organiser avec les mitaps locaux. Nous avons de nombreuses réunions locales, et cela se révèle plutôt cool quand ils ont la possibilité de faire quelque chose par eux-mêmes - il y a beaucoup de gens d'initiative, vous devez leur donner l'occasion. Et ce serait cool si les organisateurs de tous les rassemblements locaux ou leurs principaux conférenciers recevaient un billet gratuit ou une sorte d'aide, ce serait formidable.
Au HolyJS le plus proche (Saint-Pétersbourg, du 24 au 25 mai), Andrei parlera davantage de la promotion de projets open source. Et à côté de lui, il y aura de nombreuses autres figures importantes de l'open source JS: de Ryan Dahl (Node.js, Deno) à Michel Weststrate (MobX, Immer). Tous les détails sur leurs sujets de rapports sont sur le site Web , les billets peuvent y être achetés et, progressivement, ils deviennent plus chers.