¿Cómo es la vida de los creadores de las bibliotecas populares de código abierto? Por supuesto, es bueno cuando el resultado de tu trabajo ayuda a muchas personas en todo el mundo. ¿Pero te encuentras abrumado con tareas que ni siquiera son tu trabajo principal? ¿Cómo lidiar con eso? ¿Con qué valentía se puede delegar autoridad?
Michelle Weststrate es muy consciente de todo esto: su biblioteca
MobX tiene más de 17,000 estrellas en el github, el número de sus contribuyentes ha superado por mucho el centenar. Y pronto Michelle vendrá a Rusia para hablar en HolyJS, por lo que los chicos del comité de programa de la conferencia (Dmitry
DmitryMakhnev Makhnev y Evgeny
bunopus Kot) le preguntaron en detalle: sobre el código abierto en general, y específicamente sobre MobX y sobre las conferencias.
Eugene: ¿Puedes primero hablar un poco sobre ti para aquellos que no te conocen?"Sí, por supuesto". Mi nombre es Michelle Weststrate (que es muy difícil de pronunciar para la mayoría de las personas), soy de Holanda. La mayoría de las veces me conocen por mi trabajo en MobX o en
immer . Yo trabajo para Mendix. Hacemos software que hace software: una plataforma de desarrollo de aplicaciones que utilizan muchas empresas de consultoría. Automatizamos una gran cantidad de compañías de seguros bancarios y sistemas similares. Hago el lado técnico, es decir, lo que me gusta. Y hace unos dos años, me involucré en el mundo del código abierto, desde ese momento estuve activo tanto en la comunidad React como en la comunidad JS en general.
Eugene: ¿Qué haces exactamente en Mendix? ¿Estás ahí, asesores técnicos?- si. Tengo varios roles diferentes allí, y el principal es Tehlid. En esencia, esto significa que soy responsable de la selección de soluciones técnicas para una de nuestras
"tribus" . Por lo tanto, estoy trabajando en un producto que sea un entorno para aplicaciones móviles. Trabajamos en ello con cuatro equipos, y principalmente tomo las decisiones arquitectónicas y tecnológicas correctas. Además, todavía estoy programando. Esta es una parte de mi trabajo.
Y el otro es la participación en la comunidad de código abierto. Esta es una actividad "bidireccional". Por un lado, estamos haciendo cosas técnicas geniales que quiero compartir en las conferencias, y hablo por mi cuenta o aliento a mis colegas a hablar. Por otro lado, lo contrario también es bueno en las visitas frecuentes a las conferencias: descubres algo que puede ser útil para nosotros, luego lo estudiamos y lo incluimos en nuestra pila.
Eugene: OSS Evangelism se menciona en su descripción de Twitter. ¿Qué es y por qué es importante para ti?- La primera razón por la cual esto es importante: descubrí que si traduce su desarrollo a código abierto, no le ahorra tiempo en absoluto, pero ayuda mucho en las pruebas y mejora la calidad. Porque una biblioteca como MobX se usa en condiciones muy diferentes. Y creo que, en este sentido, el código abierto ofrece una ventaja tal que es muy difícil obtenerlo de otra manera.
Y la segunda: creo que nuestros desarrollos de "bajo nivel" no definen a la empresa, entonces, ¿por qué no compartirlos? Quiero decir, una empresa se vuelve más o menos competitiva por un producto que se basa en sus tecnologías, y no en estas tecnologías por sí mismas. Y todos se benefician de la colaboración, esto permite que el desarrollo en su conjunto se acelere.
Eugene: A veces dicen que el código abierto "no monetario" es en realidad un placer muy costoso. Proyectos como Linux requieren una tonelada de dinero de gigantes como Oracle y Microsoft. Es asi? ¿Puede existir una comunidad de código abierto sin grandes vendedores y dinero?- Creo que depende de la situación específica. Hay pequeñas bibliotecas que podrían existir así. Pero los proyectos como el kernel de Linux o React Native mencionados anteriormente son tan complejos y tanta gente depende de ellos que necesitan un modelo financiero confiable. En este caso, sin grandes patrocinadores sería muy difícil. Pero no creo que esto sea un problema. Creo que es más importante que las empresas aprendan a asumir la responsabilidad de lo que nosotros aprendemos a prescindir de ellas.
Eugene: Por ejemplo, si Facebook viene a ti y te dice "¿Vamos a comprar MobX o patrocinarlo para que el desarrollo vaya bajo nuestra marca"?- Bueno, en realidad, ¡ya patrocinan! Es divertido, pero Facebook es uno de los patrocinadores de MobX
en Open Collective . Entonces, en cierto modo, esto ya ha sucedido. En mi opinión, Open Collective es un gran ejemplo de cómo podemos mejorar la posición financiera de código abierto. Permite a las empresas patrocinar el desarrollo de una manera que les convenga, porque existe un enfoque financieramente serio, con facturas y similares.
En Mendix, esencialmente me pagan mucho por trabajar en MobX, así que no estoy interesado en cambiarme completamente a Facebook. Entiendo que esto puede interesar a otra persona, pero no veo ningún problema en esto. En mi opinión, si la licencia sigue siendo de código abierto, no hay nada de malo en el hecho de que el producto esté bajo la marca del patrocinador principal. Es como ver fútbol en la televisión: si todos pueden ver el juego, entonces no hay mucha diferencia en el logotipo de las camisetas.
Eugene: Si una gran empresa patrocina la biblioteca, ¿no puede decir "Dado que pagamos tanto, por favor, háganos esto en ella"?"No he encontrado esto, al menos, por lo que se convierte en un problema". Si no me equivoco, webpack usa dicho modelo, es posible pagar por las funciones allí. Por lo tanto, existe cierto riesgo, pero creo que es responsabilidad de los encargados de garantizar que el proyecto se mantenga fiel a su filosofía. Pero dentro de esta filosofía, es probable que haya mucho espacio para maniobrar. Y además, en código abierto, si de repente algo sale completamente mal, al menos la posibilidad de tenedor permanece.
Eugene: El desarrollo de software de código abierto es como una curva: primero haces una biblioteca que nadie más necesita, luego la gente comienza a usarla, luego gana miles de estrellas en un github y así sucesivamente. Cuando un proyecto de código abierto se vuelve popular, puede comenzar a tomar mucho tiempo. ¿Cuánto gastas en MobX?- Recientemente, no mucho. MobX es bastante estable en este momento. Pasé mucho en el pasado, por supuesto. Fue muy diferente Creo que durante el primer par de años fueron algunas noches a la semana, y hubo muchos más pequeños momentos en los que simplemente respondiste cuestiones o preguntas menores en Twitter. Estas pequeñas cosas no se sienten como una inversión significativa de tiempo, pero creo que en total agregan significativamente. Sin embargo, es muy difícil de medir. Así es como se verifica el correo del trabajo: se verifica el problema y se envía rápidamente una respuesta.
Eugene: ¿Cómo ser productivo en una situación en la que usted es desarrollador, creó una biblioteca, se ha vuelto popular y requiere más y más tiempo? Tienes suerte, tienes la oportunidad de hacerlo durante las horas de trabajo. ¿Pero si ya tienes un trabajo y un pasatiempo y el proyecto se vuelve más popular?- Bueno, cuando comencé a trabajar en MobX, también fue solo en mi tiempo libre, se agregó el que funcionaba cuando el proyecto alcanzó popularidad. Pero tengo algunos consejos. Noté que hay varias reglas que me han ayudado.
Primero: haga un seguimiento de la relevancia de la documentación. Si recibió la misma pregunta tres o cuatro veces, asegúrese de registrar la respuesta en la documentación. Porque finalmente te ahorra tiempo.
Segundo: sea muy exigente con respecto a qué problema acepta. Al principio, tan pronto como se le informe de un error, está intentando reproducir el problema según la descripción disponible. Y en algunos casos descubres que esto es imposible y que el tiempo ya se ha gastado. Por lo tanto, ahora exijo algo que pueda ejecutar directamente desde el problema, ya sea un código en el sandbox o una solicitud de extracción con pruebas unitarias. Algo que me permite determinar dónde está el problema: en la biblioteca o en el lado del usuario. Esto es muy importante, porque me permite ahorrar tiempo y asegurarme de que la autora del problema esté lista para invertir su tiempo. Algunos dicen: "No tengo tiempo para ayudar a reproducir el error", y tengo la sensación de "Bueno, entonces no tengo tiempo para ayudar a resolver su problema". Después de todo, a una persona probablemente se le paga por el trabajo en el que usa mi biblioteca. ¿Por qué debería invertir mi tiempo libre en su problema? En general, dicha selectividad ayuda, aunque te hace sentir algo menos responsable, porque quieres ayudar a todos. Pero descubrí que "ayudar a todos" es simplemente poco realista.
Y, sin embargo, dado que trabajo con varias bibliotecas, no respondo a todos los problemas al instante, sino que "salto" de una biblioteca a otra: trabajo en ella varios días a la vez, y luego paso al siguiente. Y puedo responderle en cuestión de minutos si escribió sobre el que estoy haciendo ahora, pero no puedo responder durante días si aún no ha llegado su turno. Esto me ayuda a cambiar de contexto con menos frecuencia.
Todos estos consejos ayudan cuando su biblioteca comienza a ganar popularidad.
Eugene: Cuando el creador de la biblioteca popular responde "No puedo reproducir, escriba una prueba unitaria", ¿esto no hace que las personas sientan que "es arrogante y no quiere ayudar"?- Encontré tal efecto, pero muy raramente. Creo que generalmente el usuario comprende que los mantenedores están bastante ocupados y que el problema con alta probabilidad está de su lado. Creo que si usa el filtro Lodash y tiene un problema, entonces habrá un sentimiento involuntario "probablemente, algo está mal conmigo, porque todos usan Lodash". Entonces, la mayoría de las personas entienden que deben tener cuidado en los asuntos.
Eugene: Cuando la biblioteca se vuelve popular y requiere más tiempo, ¿cuánto vale compartir su rol como contribuyente, otorgando derechos a otros miembros de la comunidad?- Esta es una gran idea, generalmente doy los derechos de un colaborador tan pronto como veo varias solicitudes de extracción buenas de una persona (o incluso una solicitud de extracción, si es grande). En mi opinión, esto funciona muy bien. Por ejemplo, en el árbol de estado MobX, la mayor parte del trabajo ahora lo realizan otras personas, no yo. Y hay otras partes de la base del código que la gente entiende mejor que yo, y es genial que todo haya llegado a ese estado. Para el MobX "central", esto no es necesario, ya que todo ya se ha establecido allí, los algoritmos no han cambiado en los últimos años, por lo que el trabajo de soporte es pequeño. Pero en el caso de MobX-state-tree, elegí deliberadamente a las personas que crean muchas bibliotecas de usuarios y les otorgé los derechos del responsable. Después de todo, si usa activamente la biblioteca en su trabajo diario, se encontrará con patrones o problemas comunes que me perdí. Y también, creo, da a los desarrolladores motivación y una sensación de fiabilidad, porque pueden ayudar a la biblioteca a trabajar con lo que enfrentan.
Eugene: Al mismo tiempo, ¿no hay sensación de que la biblioteca, cuando era niño, está siendo golpeada? ¿Quizás no estás de acuerdo en cómo exactamente otras personas lo desarrollan?- A veces sucede un poco. Pero creo que eso es normal. Has hecho una gran analogía con los niños: con el tiempo, crecen, cumplen 18 años y luego debes dejarlos ir, porque es hora de que encuentren su propio camino. Creo, hasta cierto punto, con bibliotecas de código abierto también. Si tienen éxito, entonces comienzas a enfrentar situaciones más difíciles. Comienzas a tratar casos con los que generalmente no me gustaría tratar. El código ya no será el código hermoso, limpio y minimalista que originalmente quería. Esto es inevitable
MobX tiene un gran ejemplo de esto: originalmente escribí para TypeScript, donde los decoradores son muy simples, y luego la gente comenzó a usarlo con Babel, donde hay una implementación completamente diferente. Y al final, algunas partes de la base del código son muy antiestéticas porque están tratando de determinar si estás usando TypeScript o Babel. Suena horrible y se ve horrible. Pero eso es parte del trabajo. No es necesario amarlo, pero es necesario asegurarse de que todo funcione bien en todas partes. Y en este sentido, su hijo puede ir en una dirección en la que no pensó, pero esto es normal, porque en última instancia es importante que las personas puedan utilizar con éxito el proyecto.
Eugene: El desarrollo está cambiando, mucho se está volviendo más fácil de lo que era hace 10-20 años. ¿Qué opina de la situación actual en el código abierto en relación con estos cambios y qué espera del futuro? ¿Las grandes compañías se convertirán en una fuente de energía para todos o, por el contrario, en entusiastas?- Esta es una pregunta difícil. No estoy seguro de que habrá grandes cambios. Y hay cambios en ambas direcciones a la vez. Estoy particularmente impresionado por Facebook y Microsoft: cuánto están abriendo ahora y en qué medida permiten que los desarrolladores de terceros hagan una contribución. React Native es un ejemplo particularmente sorprendente en el que una gran parte del trabajo no proviene de Facebook. Por otro lado, para un solitario, probablemente nunca fue tan fácil participar en un proyecto de código abierto o crear uno propio, como lo es ahora. Las herramientas se están volviendo más estandarizadas, tenemos excelentes IDE en línea como
CodeSandbox y
Gitpod . He estado trabajando con Gitpod en las últimas semanas, y esto es genial: puedo verificar las solicitudes de extracción sin siquiera hacer nada localmente. Simplemente puede ejecutar en Docker en un navegador y desarrollar allí. Así que no sé cuáles serán los cambios.
Eugene: Hace ocho años, cuando era desarrollador de C ++, no existía una comunidad de código abierto como ahora. Y ahora, en el mundo de la web y JavaScript, veo que el código abierto se está desarrollando cada vez más rápido. ¿Continuará este crecimiento?- Creo que el movimiento continuará. Una de las razones, en mi opinión, es la siguiente: tanto las empresas como los desarrolladores comprenden cada vez más que el código abierto no solo es útil para quienes lo desarrollan o lo usan, sino que también ayuda a encontrar empleados. Al observar la participación de una persona en código abierto, puede comprender más sobre él que si lo entrevista todo el día. La forma en que responde el problema o los inicia muestra mucho. Creo que los desarrolladores y las empresas son cada vez más conscientes de la importancia de esto.
Eugene: ¿Entonces crees que desarrollar una biblioteca de código abierto puede ayudar con una entrevista?- Exactamente Si usted es una empresa y tiene bibliotecas de este tipo que no están estrechamente vinculadas a su API, esto es excelente, porque las personas vendrán a participar, y pueden llegar a ser exactamente lo que necesita. Y si contrata a uno de sus contribuyentes, será más fácil para ellos unirse y comprenderá mejor qué esperar. Creo que, solo por esta razón, se abrieron muchas cosas interesantes.
Dmitry: Hablamos de código abierto en general, pasemos específicamente a MobX. ¿Cómo y por qué empezaste a hacerlo inicialmente?Buena pregunta En Mendix hemos tenido una aplicación de Windows escrita en C #. Hace unos años, decidimos portarlo a la web y comenzamos a descubrir qué pila usar. La reacción apenas comenzaba, Angular había existido por un tiempo, Ember era bastante popular. Y bastante rápido, nos enamoramos de React debido a su modelo de componente y su capa de abstracción propuesta.
Pero luego descubrimos que teníamos un problema de rendimiento, resultó que actualizar el DOM por completo era bastante costoso, incluso en el caso de React. En C #, actualizamos constantemente el modelo y redibujamos todo el lienzo, y nadie optimizó nada, porque de todos modos todo funcionaba muy rápido, por lo que no era necesario "abordar el renderizado de manera inteligente". Pero aquí descubrimos que en el caso del DOM, no se puede volver a dibujar todo 60 veces por segundo. Así que pensamos en cómo hacerlo de manera efectiva. Pensamos en el enfoque inmutable, pero en nuestro caso no encajó por varias razones. Uno de ellos es con qué datos trabajamos y cómo se representaron. La misma información fue presentada en varios lugares. Nuestros datos son muy difíciles de normalizar. Y en segundo lugar, parecía que todavía tenía que lidiar con demasiados detalles. Por ejemplo, tendría que escribir selectores para los datos que está procesando.
Pero, ¿qué sucede si desea escribir el mismo código simple que nuestro código C #, "renderizar algo" antes y no quiere molestarse en cómo esto cambiará en el futuro? Si no quiere decirle a los componentes "Entonces, tome esta parte de los datos de aquí, pero esta de allí, y luego puede renderizar algo". Comenzamos a estudiar qué tecnologías están disponibles actualmente, y rápidamente llegamos al paradigma utilizado en Knockout, Meteor y (al menos conceptualmente) incluso en Angular. Donde no quiere decir ni la relación entre las dependencias de datos y los componentes, ni lo que se debe representar cuando.
Comencé a entender por qué las personas a menudo odian tales enfoques, especialmente cuando la aplicación crece. Y resultó que la mayoría de las veces las personas están preocupadas por la falta de previsibilidad y "depuración", que algo se puede hacer con demasiada frecuencia, o muy raramente, o en el orden incorrecto. Y decidí que podemos hacerlo mejor. Podemos luchar por el mismo objetivo, pero un enfoque más inteligente para la implementación. Y así apareció MobX. No solo captura la relación entre observadores y observables, sino que construye un gráfico de dependencia completo, por lo que puede estar seguro de que todos los observadores se ejecutan en el orden más eficiente. En la programación reactiva, existe el concepto de "falla", por lo que aquí no puede ocurrir. En general, se tomó uno existente aquí, pero con un intento de hacerlo más predecible.
Dmitry: Es decir, si me gusta algún tipo de enfoque, pero las bibliotecas existentes no son lo suficientemente buenas, ¿puede tomar y mejorar, y esto puede volverse popular?- Sí, exactamente! Así que lo escribí inicialmente para nuestros propósitos internos, y luego fui a ReactEurope. Parece ser 2015, y se habló mucho sobre los patrones de Flux. Entonces las Guerras Flux se desataron. Y sentí que la gente pone mucha energía en un problema que ya hemos resuelto. « ». . , « Flux», - . .
: MobX , . , ?— ! « MobX Lite». , MobX, 200 . , . . , . MobX. , — API, . , , API . , MobX 5 MobX 4 ,
Proxy .
: Proxy. - , . ?— , , Proxy - , . . Chrome 8, , .
: . , jQuery -, , - . Redux MobX. ?— , . , jQuery- . , JQuery , . - . jQuery React , , , . . , state definitions .
, , React UI. . , - UI .
: ? , ?— , . , immutable values. , , immer — , immutable states JS. , state management. ,
, , . , , , GraphQL, , . …
: -, MobX?— , , , . . : , to-do list . , , todo. , - , todo- , . . , .
: . . , - . , ?— , . : , . — , , . , . Docker, . , , , . — « ». -, — , , . , , . — , , - . - -, , . , , . : -, , . .
: ( , ) , , Medium YouTube. ?— , , — . , . — . , , , … . . , . . , . , , . , , , , - . , . , (, , ) — . , , . .
Eugene: Gran consejo. Estarás en Rusia por primera vez, ¿qué esperas de Moscú y de la conferencia?- Definitivamente quiero mirar a Moscú y definitivamente me sorprenderá. Y también noté que hay muchos usuarios de MobX en Rusia. Veo esto en el rastreador, en commits. Así que espero reunirme con muchos usuarios de MobX en la conferencia.Puedes ver a Michelle y hacerle preguntas en HolyJS 2018 Moscú , que se realizará del 24 al 25 de noviembre . Allí hablará más sobre la gestión estatal. Vea una descripción de los informes de la conferencia en su sitio web .