Andrey Sitnik de
Evil Martians es uno de los nombres rusos más famosos en la parte delantera: sus proyectos
PostCSS y
AutoPrefixer tienen decenas de miles de estrellas de GitHub. Pero como Andrei vive en Nueva York y viaja por todo el planeta, rara vez lo puedes encontrar en Rusia.
En mayo, estará en San Petersburgo en la conferencia HolyJS, y
Dmitry Dmitry Makhnev Makhnev y
Maxim Yuzva, miembros del comité del programa HolyJS, le preguntaron en detalle sobre
esto . ¿Por qué Andrei piensa que la interfaz está estancada y que el código de nuestros proyectos está demasiado hinchado? ¿Cuáles son las diferencias entre las comunidades de TI en diferentes países? ¿Cómo aprender inglés y por qué es menos importante de lo que parece? ¿Dónde regresó el proyecto Logux presentado en HolyJS en 2016?
Sobre proyectos actuales
Dmitry: Primero, cuéntanos brevemente sobre ti, dónde estás y qué estás haciendo.
Andrey: Mi nombre es Andrey Sitnik, vivo en Nueva York, pero trato de viajar mucho. Principalmente me conocen por código abierto y actuaciones, como ahora es popular decir, "una marca de medios en el campo de TI". No puedo decir que realmente lo merecía, pero la suerte me ayudó.
Además del código abierto, también promuevo la diversidad lingüística en Twitter
@LinguoPunk , Wikipedia en
@LostInWiki y la lucha por el positivismo sexual.
Dmitry: ¿En qué proyectos estás trabajando ahora?
Andrew: en código abierto hay varios proyectos de soporte, los más famosos son PostCSS y Autoprefixer. Quizás PostCSS ahora se esté activando ligeramente: Alexey Bondarenko
realizó una gran actualización de la API, por lo que puede haber una gran versión pronto.
Y Autoprefixer está en versiones de soporte. Lo único que estamos aserrando activamente ahora es el soporte de Grid para IE 10-11, pero está yendo mal debido a la
resistencia de Rachel Andrew, quien estaba promoviendo activamente Grid. Es una persona muy famosa y no le gustan las herramientas que automáticamente hacen algo en CSS, como una lucha religiosa. Y debido a su oposición, esta característica, desafortunadamente, no se extendió particularmente.
Dmitry: ¿Cómo puede Rachel evitar que hagas un instrumento?
Andrew: La herramienta no interfiere con hacer nada, funciona. Pero el código abierto no se trata de programación, el código abierto se trata de la sociedad y la socialización. Si nadie usa su producto o habla sobre este medio, no hay motivación para hacerlo. Como resultado, golpea la motivación de los desarrolladores que lo hicieron y continúan haciéndolo. Pocas personas hablan de su heroísmo, pero siguen siendo grandes compañeros y verdaderos héroes.
De hecho, nos dimos cuenta de todo lo que queríamos y pudimos, incluso existe una idea loca con el apoyo de las redes automáticas, que generalmente es imposible de hacer con esta especificación, pero los chicos descubrieron cómo hacerlo con una astuta combinación de magia de selector.
En general, PostCSS y Autoprefixer son compatibles, rara vez se agregan funciones y en su mayoría son pequeñas, pero Logux se está desarrollando activamente. Y este año quiero dedicar más a artículos que a un proyecto específico de código abierto.
Dmitry: Disparaste mucho, pero sobre Logux después de la
presentación en HolyJS en 2016, ¿realmente no escuchaste lo que le pasó?
Andrew: Esta es una buena pregunta, porque plantea un tema muy interesante. El hecho es que hay diferentes formas de distribuir software.
Usar código abierto no es un tipo de toma de decisiones racional. El desarrollo de software es mejor descrito por la industria de la moda. La elección técnica es, en primer lugar, moda, bombo y cosas similares.
Por lo tanto, existen varias estrategias para promover nuevas soluciones. Por ejemplo, cuando aparece algo, todavía no funciona como debería, pero debido al temor de perderse algo enorme, las personas se suben rápidamente a un tren exagerado, comienzan a serrar y lo ponen en funcionamiento.
En el buen sentido, más de la mitad de los proyectos populares de código abierto se escribieron de manera desagradable. Más bien, la exageración que los rodea es completamente inconsistente con la calidad del código y el nivel de apoyo de los organizadores. Pero dado que mucha gente se sentó en el tren de bombo de inmediato, el proyecto sobrevivió y continuó existiendo.
Por ejemplo, los complementos de Babel no tienen asincronía. No puede realizar funciones asincrónicas dentro de los complementos, y este es un problema terrible, no sé cómo entró en producción, ya que limita terriblemente los enormes mercados de aplicaciones de Babel. Pero así fue escrito, tal es su arquitectura. Babel se divierte mucho.
Esta es una forma de propagación: decir "todo se habrá ido, si no aprendes mañana, todo, el mercado necesitará personas con tres años de experiencia en esta tecnología". Pero hay otra forma. Por ejemplo, en React, lo hicieron de manera diferente: primero “cocinaban” en su entorno y luego presentaban un proyecto que estaba más o menos listo para la producción. Por supuesto, la pregunta abierta es cómo estaba exactamente listo para la producción, pero está claro que los marcos no están 100% preparados.
Logux es un sistema de comunicación cliente / servidor. La idea de las consultas, ya sea GraphQL o Ajax, no está destinada a Internet inestable y funciona en esas condiciones simplemente desagradables: este es un problema conocido de la mayoría de los sitios. Logux es un enfoque diferente y, como resultado, es técnicamente una solución muy grande. La idea no es nueva, hay muchas soluciones de este tipo, y fallaron, y me preocupó. Incluso GraphQL se hizo con un crujido terrible, y eso debería haber enseñado algo.
Mi opinión es que el tren exagerado no funciona para este tipo de tarea. No podemos tomar una decisión para que todos se encuentren con ella y todo salga bien. Cuando entregamos la solución de inmediato para el front-end y el backend, los intentos de sacarlo todo en el tren exagerado conducen a una confrontación entre las comunidades.
Por lo tanto, decidí que con Logux no haremos esto, sino que iremos con cuidado y lentamente, preparándolo dentro del proyecto. Todo este año o dos, cocinamos Logux dentro de
Amplifer , lo usamos en diferentes proyectos y vimos cómo reaccionan los patrocinadores. Traté de explicar, mostrar, y ahora Dima Salakhutdinov irá al Ruby-confu para
hablar sobre Logux, para que podamos ver cómo reaccionan, cómo le damos PR al back-end. Debido a que decirles lo que decimos a los proveedores de servicios de fondo en el espíritu de "es bombo" está mal, no funciona allí.
Dmitry: ¿Por qué no funciona?
Andrew: El backend cambió a un sistema de estancamiento o soporte: en los últimos años prácticamente no ha habido desarrollo. Y como resultado, tienen diferentes prioridades: cuando no tiene marcos nuevos cada seis meses, le afecta. Están en algún lugar de Rust or Go, pero Ruby, ¿qué hay de nuevo? Como resultado, las personas se centran en el otro. Por supuesto, simplifico enormemente, y el backend es diferente.
Quiero distribuir correctamente esto en el backend y en el cliente, quiero venir con una solución preparada que realmente funcione, que realmente probamos en producción. En 2017-2018, ya teníamos una versión funcional de 0.2, pero no había escalabilidad. Teníamos una idea de cómo escalar, y para relaciones públicas sería suficiente, pero de hecho está mal.
En cambio, nos ocupamos de los problemas de la escalabilidad real, en lugar de la teórica, cuando es incomprensible para usted y no sabe en qué momento. Y en Logux bombeamos seriamente el sistema: por ejemplo, podemos elevar fácilmente el servidor en varios servidores a la vez, y con un comando para aumentar su número.
No tiene sentido hacer esto hasta que tenga un análisis real. Porque sin él no entenderás de dónde sacaste el enchufe. Puede escalar tanto como desee, pero resulta que hay un lugar que no escala. Por lo tanto, tenemos un código que está realmente listo para escalar, y una gran cantidad de análisis: cómo y cuánto tiempo se gasta, cuántas solicitudes ingresan, puede ver dónde comienza el complemento. Por ejemplo, por el número de operaciones por segundo o por el número de usuarios, y todo esto en el servidor se resuelve de manera diferente.
Dmitry: Eso suena bastante interesante. Y, según tengo entendido, ¿los planes son lo suficientemente grandes para el futuro cercano?
Andrei: Sí, ya hemos completado los planes para la aplicación práctica, ahora lanzaré 0.3 y escribiré muelles que no son suficientes para la aplicación masiva. Y el código es bueno.
Acerca de Nano ID e Internet rápido
Dmitry: Has tocado el tema de la conexión a Internet: todos están acostumbrados al hecho de que nuestro Internet es estable y bueno, pero en realidad todo está completamente mal. Y aquí es imposible no prestar atención al tamaño de los paquetes y otras cosas, recuerde su proyecto Nano ID. ¿Por qué te molesta tanto? Comencemos con el tamaño.
Andrei: ¿No me parece que es "ahorrar en partidos" cuando todos tienen un Internet normal? Buena pregunta
Nano ID es una biblioteca de 141 bytes que genera ID. Cuando lo redujimos de 200 bytes, esto no tenía sentido práctico, pero era un "manifiesto político" que era hora de pensar en ello.
El tamaño de JS es un tema interesante. En primer lugar, los compiladores no lo resuelven, pero viceversa: la mayoría de los paquetes se combinan incorrectamente, aumentan significativamente el tamaño o lo usan de manera ineficiente.
Y el hecho de que la velocidad de las conexiones a Internet está creciendo es cierto, y al mismo tiempo no. Tan pronto como Internet se acelera, los países declaran estar donde todo está muy mal, por ejemplo, en África Central. Y también aparecen nuevos mercados, por ejemplo, móviles. Y hay un problema complicado: las velocidades de descarga están aumentando, pero los sitios no se cargan más rápido. Puede verificar algunos LTE, que deberían abrir todo rápidamente, si divide el tamaño de página del sitio por la velocidad de la red.
El problema es que la velocidad de carga real del sitio depende de otros parámetros. Por ejemplo, el
número de viajes de ida y vuelta . El hecho es que entre las solicitudes y los primeros bytes, pasa inevitablemente algún tiempo cuando llega y regresa la señal. Este tiempo es muy largo, hasta
500 ms . En primer lugar, debido a la velocidad de la luz, en segundo lugar, el equipo es lento. Y si sus archivos se cargan entre sí, el sitio se ralentizará.
Afortunadamente, descubrimos este problema hace mucho tiempo y aprendimos cómo resolverlo. Pero ella no es la única. Recientemente, encontramos otro: resulta que el problema no está en Internet, sino en la velocidad de compilación. El hecho es que 1 megabyte de imágenes es fácil de descargar y mostrar, y 1 megabyte de JavaScript es 2-3 veces más pesado para el navegador, ya que debe compilarse. Y el número de JS está creciendo. Y este es un problema objetivo de los sitios de baja velocidad.
Puede abordar astutamente la cuestión de estudiar el sitio utilizando el método de
entropía . Tenemos un sitio web que pesa 1 MB. Existe el concepto de "cantidad de información". Un megabyte no es solo el número de líneas, es la cantidad de sentido que contiene este código. ¿Y qué tan complejo debe ser un sitio para requerir 1 MB? ¿Realmente hay tantos casos de usuarios en el sitio que debe haber un volumen de código para cubrirlos?
De hecho, tales casos son pocos. Se necesita mucho en el kernel de Linux, pero no en los sitios. Y por lo tanto, tenemos un montón de código redundante.
El significado del movimiento Nano ID no es guardar cada byte, sino pensar: “¿qué tengo en el paquete? ¿Qué demonios estoy teniendo allí 1 MB? No puedo realizar tareas en las que se requeriría tal volumen ". En la mayoría de los sitios, el 75% del código no se usa. Nano ID es un movimiento en contra de nosotros enviando a los usuarios este código.
Cuando comenzamos a pensar por qué no se usa tanto código, entendemos que si no se trata de un gran equipo, no se puede escribir un megabyte de código manualmente. Esto es más que la "Guerra y paz" convencional, que se puede escribir a lo largo de los años, y el código es mucho más difícil de escribir debido a las interdependencias.
Y más a menudo este volumen es bibliotecas. La famosa historia con Moment.js: la conecta y, debido a las peculiaridades de la operación del paquete web,
carga todos los idiomas en su sitio web . Y hay muchos casos similares.
En un momento, necesitaba generar una identificación única en Logux, tomé una biblioteca y luego descubrí que pesaba 100 KB. ¿Por qué necesito tanto para generar una identificación aleatoria?
Tales tamaños se deben con mayor frecuencia al hecho de que los desarrolladores de bibliotecas los escriben incorrectamente. Por lo tanto, la idea principal es utilizar el
límite de tamaño para que los desarrolladores de la biblioteca controlen el tamaño de sus proyectos. Como ESLint, solo para el tamaño de la biblioteca. E inmediatamente vemos que una gran cantidad de bibliotecas se pueden reducir a la mitad.
Dmitry: ¿No te parece que la pregunta no es solo sobre el tamaño del código, sino también sobre los enfoques de las herramientas de desarrollo? Si exporto mi biblioteca como un objeto en lugar de funciones individuales, y no conecto el Compilador de cierre de Google bajo mi propio riesgo, nadie me cortará nada. ¿Podría el problema ser más profundo que simplemente escribir código?
Andrew: No diría que el problema de sacudir árboles es realmente relevante, porque no funciona en JavaScript. Todos piensan que trichashing resolverá el problema, pero no. El problema más común es diferente: qué está haciendo el paquete. Utilizan un
paquete acumulativo , empaquetan todo el proyecto en un solo archivo y resulta que, por ejemplo, las dependencias están empaquetadas allí. Este es un gran problema, y con la ayuda de Size Limit redujimos enormemente una biblioteca, porque eliminamos las dependencias que probablemente se repitan en cada proyecto.
El segundo problema es que accidentalmente usan alguna API de Node.js. Por ejemplo, había una biblioteca
choo.js - "marco JS compacto", donde verificaban los argumentos entrantes usando la afirmación del módulo Node.js. Y carga casi 4 KB. Y por el bien de una pequeña biblioteca, enviamos 4 KB adicionales.
Y tales problemas son mucho más comunes de lo que se usa para sacudir árboles.
La mejor recomendación para trishaking es dividir los archivos en el ensamblado, dejar que haya funciones separadas en archivos separados. Pero la mayoría de las veces el problema es diferente. Simplemente ejecute Size Limit con la opción --why y vea la enorme cantidad de basura que incrusta el paquete web cuando usa su módulo.
Maxim: ¿ Entonces resulta que usar webpack para ensamblar es de mala educación?
Andrew: viendo de qué hablar. Si crea una biblioteca, lo más probable es que no necesite un paquete web. Tiene menos del 1% de los usuarios que desean un archivo separado y, al mismo tiempo, es mejor obligarlos a usar el paquete web, porque insertan su biblioteca como un enlace a otro archivo y el sitio se ralentizará.
Pero de qué usuarios recopilan sus bibliotecas, de qué recopilan las personas los sitios, de hecho, no hay diferencia. Estamos acostumbrados a decir que si usa la biblioteca incorrectamente, todo será malo, si no cambia de paquete web a Parcel hoy, entonces todo es adiós, usted es un desarrollador pobre. No, para ser honesto, no me importan las herramientas.
Hay muchos problemas con el paquete web, este es un mal paquete, pero si funciona para usted, entonces continúe. Vi proyectos donde él ayuda a resolver problemas, a pesar de que este es uno de los proyectos más abandonados. Por ejemplo, css-loader es compatible con
una persona de Rusia. Este es un verdadero héroe, pero si está ocupado, eso es todo, nadie solucionará su problema, pero hay muchos problemas.
Si digo que deberías dejar de usar webpack, es solo porque hay mejores coleccionistas. Pero, nuevamente, pruebe un nuevo proyecto y no cambie el anterior. Nos masturbamos mucho en frameworks y herramientas, aunque de hecho no afectan la forma en que creamos el código.
¿Por qué el tren exagerado y los aristócratas son malos?
Maxim: Acabas de hablar de evitar el paquete web a favor de los paquetes más geniales. ¿Tal vez hay un problema en el hecho de que tales recomendaciones de personas de su nivel crean exageración? En lugar de recomendar el uso de algo nuevo, ¿tal vez solo diga "empujemos y hagamos que el paquete web vuelva a ser genial"?
Andrew: buena pregunta. Por un lado, realmente hay un problema cuando tales comentarios se perciben sin comprender el contexto. Pero hay otro problema: temo el estancamiento.
El hecho es que la interfaz está estancada. Hasta el final de nuestras vidas, viviremos bajo los auspicios de React; ni un solo marco nuevo puede desplazarlo, porque se gana la masa crítica. Es como en los idiomas de back-end: los idiomas antiguos no son derrotados por los nuevos, porque no hay masa crítica, condiciones para la transición, excepto en algunas tareas limitadas. Ahora el frente ha comenzado.
El estancamiento de los marcos y los sistemas de construcción significa un gran problema: el estancamiento de las personas que nos enseñarán cómo vivir. Vemos esto en este momento, porque las estrellas del front-end siguen siendo las mismas y, como resultado, no aparecerán otras nuevas. Y el estancamiento de las personas también significa el estancamiento de las ideas. Lo vemos hasta ahora por parámetros indirectos, mientras que hay suficiente inercia para traer nuevas ideas. Pero vienes a la conferencia, y todos son iguales, y realmente me deprime. En mi opinión, es hora de derribar el mundo del front-end.
Es como Java: un gran mercado donde todo está bien, pero no hay nada nuevo. Cómo hacer frente a este problema, no lo sé. Pero esta es una de las razones por las que me ahogo en pequeños proyectos y los asesoro constantemente.
Honestamente, el paquete web es muy difícil de reescribir, y su creador no se preocupa por la calidad de DX, lo escribe por sí mismo y se comunica poco con los usuarios. Además, hay problemas arquitectónicos que hacen que sea muy difícil reescribir. Hay personas en el equipo de webpack que honestamente intentan hacerlo bien, pero hay dificultades que nos impiden hacerlo.
Hay una comunidad y dónde moverla, para estabilizar y agregar herramientas antiguas o usar nuevas, no tengo respuesta.
En un mundo ideal, no crearemos la sensación de que usar herramientas viejas es malo, pero usaremos otras nuevas en proyectos nuevos. Y no sé cómo crearlo. De hecho, se hacen las recomendaciones incorrectas, y las personas comienzan a envenenar a otros por usar las cosas "incorrectas".
Maxim: En su opinión, ¿es posible que grandes corporaciones como Microsoft y Facebook comiencen a comprar grandes proyectos de código abierto como webpack y Babel?
Andrew: Para comprar, no. Esto no es beneficioso para ellos, siempre y cuando la comunidad traiga nuevas ideas, y este es un beneficio comercial real. Los controlan; funciona de manera diferente.
Desafortunadamente, este problema ya ha surgido en el front end, pero no se expresa en el hecho de que la compañía compró algo, sino en el hecho de que tenemos algunas estrellas que no cambiarán, siempre estarán arriba y dirán cómo lo haremos. escribir código Se conocen, es más fácil para ellos acercarse y pedirles que hagan algo. Por lo tanto, su opinión es más importante que la opinión de otras personas. Este es un sistema clásico de creación de élites en la sociedad.
Sin un sistema de ascensores sociales, esto lleva al hecho de que las élites se conservan, las ideas se vuelven viejas. Y el problema no es que las compañías los controlen, sino que tenemos un grupo muy pequeño de personas que deciden qué frontend tendremos. El funcionamiento del navegador está completamente determinado por un grupo muy pequeño de personas que trabajan en Chrome. Si Chrome continúa creciendo en popularidad, habrá un gran problema.
— , . , - , : , . , , , , . , , .
: « » - , ?
: . , , — . , ,
[] . ?
: , . - , , - , .
: , . , — , ,
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, - , , , .
, ? . , , , . , , .
: , ?
: , .
. . , .
: , , . , . , -, , . , , .
, . , 10, , , , , .
: , , ? , - : « , ».
: , , , . , . , . «» — , , — . , , - PostCSS. .
, - , . - : , , , , , .
— . , , , , , , . , . — , . , .
,
Dmitry: Dijiste que PostCSS ayuda a viajar. ¿Cuánto viajas y cómo combinas esto con el trabajo?
Andrew: Honestamente, el trabajo es aún mejor. Acabo de llegar a Nueva York después de un corto viaje. Es un viaje difícil, hay una Internet pobre en Marruecos, es imposible trabajar, pero en realidad hice algo útil todos los días: escribí un artículo, hice dos sitios usando una técnica completamente nueva.
Llegó a Nueva York, sentado, viendo YouTube. Viajo al trabajo de manera normal y eficiente. En un lugar, inmediatamente me convierto en un gofre, acostado en el sofá. Viajo para ser más productivo, por lo que combinar es fácil.
La única regla: no piense que podrá verlo en una nueva ciudad, trabajando, en un día. Ven con un gran margen. No pienses que caminarás por todas partes, realmente trabajarás de la misma manera. Serás un profesional independiente turco que se levanta y trabaja, come en la calle, trabaja, mira programas de televisión y duerme. Si no cambia la ciudad más de una vez cada dos semanas, entonces todo estará bien. No hay problemas particulares.
Maxim: Todos entienden que el conocimiento del inglés es necesario, pero no es tan fácil aprender bien. ¿Tenías buenos antecedentes? ¿De dónde sacaste buen inglés?
Andrew: ¿Te estás riendo? Tengo un inglés desagradable. Estoy planteando este tema en Lingvopank. Estamos acostumbrados a la escuela de que el idioma es la regla, especialmente con la cultura rusa tóxica, donde constantemente criticamos a diferentes personas. Estamos acostumbrados al hecho de que si dices y cometes un error, entonces todo está mal.
De hecho, el lenguaje es un sistema de comunicación, y siempre que lo entiendan, todo está bien. No entendemos cómo el lenguaje es un sistema duplicado. Es como un CD o un código QR. ¿Sabes que un código QR puede ser destruido la mayor parte, y aún será legible? Porque hay algoritmos especiales para duplicar información. El punto es que no necesita conocer bien el idioma, debe poder comunicarse en él.
Mi principal progreso en el lenguaje ocurrió cuando simplemente dejé de tener miedo. Todos tenemos miedo, porque somos constantemente acosados en la escuela y en Internet, un terrible twitter ruso, donde nos culpan más por un error tipográfico que por una anti-idea. De hecho, los rusos tienen buen inglés. Comenzando con el hecho de que estos son idiomas estrechamente relacionados: no algunos chinos, donde generalmente tiene un sistema lingüístico diferente. No podemos imaginar, como en el resto del mundo, es aún peor allí.
Rusia está en un nivel normal. Por supuesto, peor que Noruega y países pequeños similares que simplemente tienen que aprender el idioma, porque no hay contenido. Pero el resto de los rusos habla bien inglés, no hay problemas. La regla principal: no tenga miedo, solo comuníquese, cambie al lenguaje de señas, tome una copa antes de la discusión (esto ayuda a comprender que las cosas simples son realmente importantes).
El segundo punto: ver series con subtítulos, realmente ayuda.
Viaja, solo aprende el idioma.
Y lo más importante: trate de hablar.
Le tenemos miedo al idioma, porque en Rusia hay un problema: nos comunicamos muy poco con el mundo exterior. Por un lado, esto es bueno, ya que hay un mercado interno que permite que salgan algunas personas pequeñas. A medida que Yandex creció fuera del monopolio de Google debido a la barrera del idioma, también hay una gran cantidad de ascensores sociales que un programador puede subir, lo que nunca sucedería en Occidente.
Pero a cambio, existe el problema de que el mercado está cerrado, no miramos hacia afuera y todas las personas que se han levantado, muy buenos tipos, no van a Occidente porque temen al inglés. Mi recomendación es tener dos cuentas de Twitter, escribir en ruso en una para ayudar a su cultura (esto también es importante) e inglés para practicar. Cuando escriba en inglés, comprenderá que no es difícil. Lo único es que pocas personas te leerán, porque en Occidente ya hay suficientes, pero la masa crítica está ganando de todos modos, ganarás entre 150 y 300 lectores.
Participa en reuniones de habla inglesa en Rusia, no da miedo, nadie te va a ofender, todo está bien.
Dmitry: ¿Recomiendas tratar de moverte a un lugar por un tiempo para aprender el idioma? De ser así, ¿dónde?
Andrew: Para deshacerse del miedo, cualquier viaje es suficiente. Pero cómo aprender más es una buena pregunta. Honestamente, no sé, no conozco bien el idioma. Pero puedo decir que cuando hablas en un mitin en Nueva York, incluso si la audiencia apenas percibe tu acento, de todos modos, porque la mitad de la audiencia de India, la otra mitad de China.
Y puedo decir algo más. En Rusia, hay una narrativa popular que debe ser culpada, y en todas partes es buena: "En Rusia, todo es malo, me tiraré y seré feliz". Honestamente, esta es la motivación que es mejor no ser guiado. Porque la narrativa es muy antigua, e históricamente sabemos que no funciona desde los siglos XVIII-XIX. En otros países, no fundamentalmente mejor. Existen problemas fundamentales de gestión, pero tarde o temprano aparecen en cualquier país.
Hay un problema de elección cuando tiene una tarea, y se resuelve de diferentes maneras. Por ejemplo, queremos que se limpie la calle, y para esto, de hecho, necesitamos una sociedad centralizada. Para hacer esto, es necesario oprimir a todos los que piensan mal, como en los Estados Unidos. Existe un sistema muy estricto de reglas y equilibrios internos sobre quién debe pensar cómo y, de hecho, los Estados Unidos a este respecto son similares a China. Es solo que las reglas son tácitas, y el estado no hace esto, la sociedad lo hace.
No diría que hay una solución definitiva en la que es mejor: donde se rompen las carreteras o donde la sociedad dice cómo debe pensar. Pero esta no es una solución binaria, y es una cuestión de política y sociología. Y el esbozo general: a menudo otros países son de alguna manera mejores, porque en otros lugares son peores.
Es mejor no moverse de inmediato, sino viajar por el mundo, y luego se dará cuenta de que, en general, es importante qué cosas está dispuesto a dar para obtener otras cosas a cambio. Y con esta comprensión, puede elegir el país al que puede mudarse. Y luego moverse normalmente.
Pero para ser honesto, no serás feliz, porque la primera ola de emigración siempre es experimentar un sufrimiento terrible, estar deprimido, después de mudarte perderás todo tu círculo social.
Dmitry: Me gustaría saber cuál es la diferencia en la comunidad rusa de desarrolladores en otros países.
Andrei: Hablando de Estados Unidos, esta es una situación interesante. En primer lugar, existe realmente un sistema rígido para imponer una filosofía. Ella siempre lo fue, tienen un estricto sistema de castigo, por ejemplo, el acoso público. Pero el sistema es bastante antiguo y, en general, funciona. Honestamente, por otro lado, ella usa con mayor frecuencia las ideas correctas para propagar, y las incorrectas, bueno, los excesos en el terreno.
La idea principal es que hay un pensamiento muy estereotipado en la cultura para difundir rápidamente las buenas prácticas. Hay una gran cantidad de programadores que no cometen errores estúpidos, porque a todos se les dijo que escribieran así, todos escriben así. En cambio, es bastante difícil promover sus ideas.
Y hay una cultura especial de charla: la intimidación por ideas equivocadas crea tensión social, y en los EE. UU. Hay una gran cantidad de naciones, y no saben cómo conducir temas de comunicación conflictivos sin recurrir a la intimidación, por lo que tienen una lista de temas de detención.
Esta es la diferencia social más importante en la comunidad. De las ventajas: son fáciles de escalar y realmente cuidan que las personas no sufran. Vienes, todos son amigables, todo está bien, siempre y cuando seas una persona común que cumple las reglas.
La segunda característica interesante es que a menudo pagan mitaps, un precio simbólico de 5 a 10 dólares que se destina a la comida. De nuevo, porque el capitalismo.
Dmitry: ¿ Y si no es Estados Unidos, sino otros países?
Andrew: En segundo lugar, por la forma en que estudié a la comunidad, esto es China. Hay una característica interesante en una gran cantidad de desarrolladores y, por otro lado, tienen un formato interesante: muy poca red. Generalmente está cerrado, se le invita a un "desayuno especial", que se lleva a cabo con los líderes de la comunidad. Por otro lado, las personas en las reuniones realmente vienen a hablar sobre temas complejos y absorben nuevos conocimientos. Honestamente, todas estas características no son un marco. La comunidad es diversa, y hay suficientes anarquistas en China; en Estados Unidos, una gran cantidad de personas también escupieron prohibiciones. Bueno, en Rusia hay críticos hospitalarios, educados y buenos, no mezquinos.
Otra característica interesante de China es que están cerrados, con un mundo separado, esto es tanto un plus como un menos. Tienen una gran cantidad de sus logros, porque hay un lugar donde pueden desarrollarse. Y, por otro lado, sufren terriblemente por el hecho de que no pueden llevar a cabo sus desarrollos, como en Rusia. Todos los principales hablantes de chino tienen miedo de hablar inglés desde la palabra "general", aunque normalmente hablan inglés.
El siguiente es Japón. A pesar del hecho de que este es un país de computadoras, una superpotencia con tecnología avanzada, la programación se considera peor que la administración. Se cree que, a diferencia de los gerentes, la programación es baja: le dijeron a la persona y él escribe el código. Como resultado, no hay comunidad, y la TI se desarrolla de manera terrible, las startups se desarrollan de manera incomparablemente peor que las capacidades del país. No hay Valley, "genios-programadores", eso es todo. Y hay muchas menos mujeres en TI que en China, debido a la sociedad tradicional. En China, todo está bien con esto: hay muchas mujeres chinas con opiniones y experiencias interesantes, aunque también hay espacio para crecer.
Hay una buena comunidad brasileña. Los países hispanos no lo tienen, ya que todos están orientados a Estados Unidos. Francia también tiene una buena comunidad interna.
Pero en Sri Lanka, todo está bastante mal con la comunidad de TI, porque cuando se casan con una niña, la mayoría de las veces a través de su familia, su padre pregunta: "¿Con qué trabajas?" Y hay una lista blanca de profesiones "correctas", y los programadores aún no se han metido en ella. Por lo tanto, hay muy pocos programadores, aunque hay muchas ventajas potenciales: dinero, posibilidad de inmigración. Un buen padre agradecería que entregue a su hija en buenas manos, pero esto no sucede porque la lista aún no se ha actualizado.
Te aconsejo que hables en conferencias chinas e indias: es fácil llegar allí (aceptan con gusto a una persona de afuera), y practicas en inglés en un ambiente donde no tendrás miedo, porque nadie realmente sabe inglés y todos hablan con errores.
Conferencias ideales
Dmitry: Si hablamos de conferencias, ¿cuál es el factor decisivo para participar como orador?
Andrew: Para mí, el factor decisivo es la disponibilidad de conferencias. Aunque a veces, si mi camino pasa por algunos países, estoy de acuerdo con las conferencias que no son muy accesibles para las personas, solo para impulsar el informe.
Creo que hay un gran problema porque los precios de las conferencias son muy altos. Entiendo que las conferencias necesitan ganar dinero, no hay ningún problema con esto, pero hay algunos JSConf que toman fabulosos $ 500 y, francamente, lo gastan en esas cosas que se pueden ahorrar. Por ejemplo, para las cenas, la fiesta más poderosa, aunque, francamente, preferiría beber una cerveza desagradable, pero para que haya gente interesante.
Y los enormes precios conducen al hecho de que los oradores no están interesados en comunicarse con la audiencia, a veces es difícil apoyar el tema, ya que en la conferencia solo los empleados de grandes empresas, el mismo creador de la mejor implementación JS de CRDT
Viktor Grishchenko, no pudieron asistir, porque un boleto muy costoso. Hay muchas maneras de ahorrar, y deben aplicarse, los boletos caros están mal. La conferencia debe ser accesible.
A menudo acepto ir a una pequeña reunión, solo para que todos tengan acceso normal a las redes. Y en muchas reuniones, el diálogo es mejor que en conferencias con un alto precio de la entrada. Este es mi enfoque.
Dmitry: ¿Sin lo que una conferencia no puede ser buena? Ya está claro sobre las redes, la accesibilidad y ¿qué más?
Andrei: Bueno, como orador, realmente aprecio cuando hay un temporizador frente al escenario. En este sentido, en HolyJS todo es muy profesional, me gusta la organización de actuaciones. En general, la creación de redes es una cosa clave, las personas van a conferencias no por conocimiento, es más fácil leer un artículo que un informe, sino por un sentimiento de pertenencia a la comunidad.
La comunidad es lo más importante que sucede en las conferencias. La sensación de que estás hablando y algo ha cambiado en ti, sabes algo. Hay una buena idea de que nuestra sociedad carece de una comprensión de "por qué". Asistimos a conferencias para comprender por qué hacemos todo esto. Y una buena conferencia probablemente resolverá este problema.
Dmitry: Dijiste "no por conocimiento", este es un tema muy controvertido. ¿Irías a una conferencia donde se reúne una colección de personas con temas muy básicos, pero de comunidades muy diferentes?
Andrei: Sí, por supuesto, sería muy divertido.
Dmitry: ¿ Y sería más interesante que una conferencia donde hay informes serios y poderosos?
Andrei: Creo que ambos enfoques son buenos, y no hay ningún problema aquí.
Dmitry: Probablemente la pregunta final. ¿Qué esperas de HolyJS?
Andrew: ¡ Buena fiesta! En 2016, fue acreditado directamente, uno de los mejores de mi vida, y luego todo estuvo muy bien organizado.
Dmitry: ¿Qué recomendarías hacer esta vez para hacerlo aún mejor? ¿Deseas una fiesta?
Andrew: Trataría de organizarme con los mitaps locales. Tenemos muchas reuniones locales, y resulta genial cuando tienen la oportunidad de hacer algo por su cuenta: hay muchas personas con iniciativa, debes darles la oportunidad. Y sería genial si los organizadores de todas las manifestaciones locales o sus oradores principales recibieran un boleto gratis o algún tipo de ayuda, sería genial.
En el HolyJS más cercano (San Petersburgo, del 24 al 25 de mayo), Andrei hablará más sobre la promoción de proyectos de código abierto. Y además de él, habrá muchas otras figuras significativas del código abierto de JS: desde Ryan Dahl (Node.js, Deno) hasta Michel Weststrate (MobX, Immer). Todos los detalles sobre sus temas de informes se encuentran en el sitio web , los boletos se pueden comprar allí y gradualmente se vuelven más caros.