Entrevista con Aaron Patterson, presidente de la Conferencia RubyRussia 2018

Hola Continuamos una serie de entrevistas con oradores en la conferencia RubyRussia . Aaron Patterson (también conocido como tenderlove ) es miembro del equipo central de Ruby y del equipo central de Rails, un ingeniero de software líder en una pequeña startup llamada GitHub. Pavel Argentov habló con Aaron antes de su segundo viaje a Rusia.



Comencemos con la pregunta estándar. ¿Cuál es tu historia personal de rubí? ¿Cómo tomaste este tren? ¿Cuéntame sobre tus logros? ¿Hiciste del mundo un lugar mejor?

Descubrí Ruby en 2006. Yo era entonces un programador de Java. Comencemos incluso antes: era un programador de Perl y luego me convertí en un programador de Java, pero no quería ser javista.

Por qué

Cuando escribí en Perl, ya teníamos nuestro propio marco web. Había mucho de lo que tenía Rails: simplemente podía cambiar el código, volver a cargar la página y verificar qué sucedió. Todo simplemente funcionó. Cuando cambiamos al desarrollo de Java, se hizo así: debe volver a compilar todo: tomará 10 minutos antes de que pueda verificar todos los cambios que acaba de hacer. Me gustan los lenguajes dinámicos como Perl más que Java. Se esperaba Perl 6. Entonces, mientras esperaba a Perl 6, aprendí sobre Ruby. Pensamiento: "¡Guau! ¡Esto es lo que necesito! Entonces comencé a hacer Ruby, en mi tiempo libre, por ejemplo, para proyectos paralelos. Ya sabes, solo por diversión. Todo comenzó con eso. Finalmente, en 2008, ya conseguí un trabajo en Ruby.

¿Ya era Rails?

Sí, mi amigo decidió iniciar una startup. - Usaremos Rails. ¿Quieres trabajar con nosotros en la misma empresa? Soy así: - Sí, por supuesto, ¡estaré encantado de trabajar en los "rieles"! Así empecé yo.

Honestamente, no me gustó mi trabajo en esta empresa. Por lo tanto, en cualquier oportunidad, justo en el lugar de trabajo, escribí código abierto. Esto se hizo de la siguiente manera: - Ok, el proyecto tomará 2 días. Luego terminé el asunto en un par de horas, y usé el resto del tiempo para el código abierto.

Lo que hemos llamado: "¡No golpees el bache de velocidad!" Me siento aquí tranquilamente, reparando el primus. ¡Déjame en paz, por favor!

Si! Entonces, aquí comencé a trabajar mucho con código abierto. En este trabajo, comencé a escribir Nokogiri y, en general, a trabajar en mi código abierto Ruby. Así que generalmente entré en código abierto. Simplemente "hizo una contribución" hasta que un día se unió a los equipos Ruby Core y Rails Core.

Entonces, ¿cómo terminaste en el Rails Core Team?

Acabamos de encontrar errores y desarrollamos aplicaciones Rails. Encontré errores, los arreglé y envié parches. Acabo de enviar parches. Al final, están cansados ​​del hecho de que solo estoy manejando solicitudes de extracción.

Como, ahora toma el asunto en tus propias manos, ¿verdad?

Si, seguro! En general, ¡fue como un ataque de fuerza bruta!

Suena razonable! Entonces, ¿cuál es su contribución general a Rails?

Trabajé mucho en casi todas las partes del marco. Principalmente sobre registro activo. Especialmente me gusta hacer correcciones de errores y mejorar el rendimiento. La razón de este archivo adjunto es que mejora las aplicaciones de alguien. Todos están contentos si la aplicación mejora y no es necesario que haga nada por esto. Por eso me gusta trabajar en ello.

Hace algunos refinamientos "pequeños" que hacen que todo funcione. ¿Pero no tuviste que diseñar cosas "grandes"?

Por lo general, cada vez que hago algo arquitectónico en Rails, es algo dentro. Por ejemplo, la arquitectura de trabajar con URL, asociaciones, artilugios dentro del enrutador, algo así. Ninguna de estas cosas será necesariamente notable. El usuario puede verlos, pero esto no está en la forma: "¡Aquí está, lo real!" Intento mantener ese estilo. Creo que esto es realmente bueno, porque a David ( DHH - P.A.) le gusta hacer Nuevas características finas y brillantes. Por el contrario, me digo a mí mismo: “Bueno, entonces, hagamos de estas sus Características Finas. ¡Mira, y la verdad saldrá hermosa!

Sí, alguien tiene que hacer todo el trabajo manual. Por ejemplo, su presentación en la conferencia tratará sobre ciertas partes de ingeniería profunda de Ruby en general y Rails en particular. ¿De qué se trata realmente la presentación?

De hecho, hablaré sobre los componentes internos de Ruby. No he inventado todo el discurso hasta el final.

GC, rendimiento, todo eso, vida, universo, 42?

Estoy pensando en hablar sobre el recolector de basura, el proceso de compilación de Ruby y el código de bytes. Básicamente, sobre bytecode en una máquina virtual y cómo se relaciona esto con el recolector de basura. Acerca de algunas de las mejoras de rendimiento que realicé en GC. No espero hablar mucho sobre Rails.

Nuestra conferencia solía llamarse Rails Club. Nuestros organizadores pensaron y cambiaron el nombre de la idea, principalmente porque Matz dijo que nunca asiste a conferencias con la palabra "Rails" en el título. ¡Entonces, ahora somos "Ruby Russia"!

¡Entonces, hablaré sobre los componentes internos de Ruby!

En su opinión, ¿qué deben hacer los programadores de Rails para lograr un mejor rendimiento en su código?

Hay varias estrategias Primero, en términos generales, no hagas nada especial. Solo escribe tu solicitud. Lánzalo, obtén clientes, comentarios, etc. Analice de inmediato los cuellos de botella detectados. Nunca trabaje con cuellos de botella hasta que el trabajo real con los clientes los revele. Si trata con cuellos de botella que realmente no lo son, es una pérdida de tiempo. Esta vez podría usarse para nuevas funciones. Sin embargo, creo que muchos dirían lo mismo, así que hablemos sobre lo que realmente afecta el rendimiento. Primero, solo mira las consultas de la base de datos que hace la página. Esta es la primera línea de defensa: intente reducir el tiempo dedicado a solicitudes específicas. Consultas en sí mismas: automatizar y reducir. No creerá con qué frecuencia nos olvidamos de agregar un índice. Ja! Entonces, haga al menos el índice en el lugar correcto.

Realizo entrevistas técnicas e imagino cómo la gente olvida incluso qué índices son en general. ¿Por qué necesita preocuparse por esto? Bueno, ¿qué dice sobre otras cosas que los rubistas deberían saber? ¿Qué cosas técnicas debe saber un rubista para hacer mejor su trabajo?

Hay un par de esas piezas. El primero, creo, es conocer el lenguaje Ruby en sí. Aprende el idioma con mucho cuidado. El segundo es entender bien UNIX.

Usted es el primer orador "mi" que dice que necesita conocer UNIX. Así que personalmente vine a Ruby desde el mundo UNIX. Trabajé en Linux, FreeBSD y toneladas de código Perl. Vine a Ruby como otro Perl para hacer mis asuntos de administrador de sistemas, y solo entonces descubrí que también era un lenguaje web. Y entonces, dices que necesitas saber UNIX. Como y por que

Es importante estudiar los estándares POSIX y cómo interactúan con el sistema operativo, ya que lo encontrará tan pronto como comience a escalar. Tu ...

... debería saber quién es el general Feiler y por qué está leyendo mi archivo?

Jaja si! Necesita saber qué cambia el rendimiento. Quizás no necesite memorizar esto especialmente de memoria, pero debe saber que existen (llamadas al sistema - P.A.) y cómo buscarlos en Google, porque definitivamente se encontrará con esta economía. Importarán porque la aplicación se implementa en un servidor UNIX, por lo que debe comprender cómo interactuará la aplicación con el sistema operativo en el que se ejecutará. Otro punto importante es que si adquirió esta habilidad en UNIX, puede aplicarla, por ejemplo, en otros idiomas. Si encuentra algún problema, siempre puede comenzar desde este punto. Esto es quizás lo principal que recomiendo a los programadores que estudien.

¿Crees que es útil para el rubista saber otro idioma? ¿Es posible ser un buen programador en Ruby sin saber nada fuera de Ruby?

Buena pregunta Honestamente, no lo se. Todos los buenos rubistas que conozco saben otros idiomas. Sin embargo, no sé si es necesario aprender otros idiomas para convertirse en un buen programador de Ruby. Creo que simplemente sucede que las personas aprenden otros idiomas.

Buena observación! Desde un punto de vista médico, cuantos más idiomas conozca una persona, más retrasará el inicio de su enfermedad de Alzheimer.

Jaja

Después de los 40 tienes que pensar en esas cosas ...

¡Me estoy acercando a los 40 años! ¡Es bueno para mí saberlo!

Hablemos del propio Ruby. Ruby es un idioma con un gran pasado. ¿Tiene un futuro? No hace mucho estuve en San Petersburgo en una de las conferencias de TI más grandes que he visto en Rusia. La comunidad local de rubíes no estuvo representada en esta conferencia. Constantemente tenía que disculparme con Ruby: Ruby NO ESTÁ TAN MUY muerto, todavía escriben Ruby. Ruby tiene, por cierto, el marco web más conocido, y todo eso. Cada idioma grande en el mercado ahora tiene algún tipo de herramienta de desarrollo web. Ve, Rust, lo que sea. ¿Cuál es el lugar de Ruby en este ecosistema y tiene "Ruby con un gran pasado" un futuro?

Creo que hay varios aspectos en la respuesta a esta pregunta. Hay muchos lenguajes diferentes para los que hay marcos web, pero sigo pensando que si los miras desde el punto de vista de la ergonomía del desarrollador, Ruby estará en la cima de todos modos. Es fácil de usar y fácil de vender. El problema es que Ruby ya no es "completamente nuevo y brillante". La gente quiere dejarse llevar por algo nuevo. Quieren tomar el próximo tren después de Rails.

¡Quieren el olor de un auto nuevo!

Si! Sobre el futuro ... Hay muchos desarrollos nuevos en Ruby, especialmente sobre JIT y con qué trabaja Koichi: guilds. Diría que Ruby definitivamente tiene un futuro, pero todos tendrán que trabajar duro para eso. Si hacemos el esfuerzo correcto, el futuro seguramente será.

¿Ruby tiene alguna perspectiva en otras áreas además del desarrollo web? ¿O conoces algún ejemplo donde Ruby ahora se usa fuera del desarrollo web?

Buena pregunta! Es difícil de responder, porque solo trato con problemas de desarrollo web.

Pregunto porque es mi interés personal. A los chicos de la comunidad Python, por ejemplo, les encanta alardear de sus éxitos en informática científica.

Sé que hay un grupo trabajando en herramientas científicas en Ruby. Pero creo que la alternativa real para Ruby es la administración del sistema.

¿Cómo podemos traer desarrolladores de otros idiomas a nuestra comunidad?

Esta es una muy buena pregunta! Creo que solo debemos centrarnos en la ergonomía del desarrollo, en lo que hace que el desarrollo de aplicaciones web sea lo más fácil posible. Tenemos que centrarnos en reducir el umbral de entrada para los nuevos desarrolladores que abordan y escriben aplicaciones web. Entonces atraeremos más programadores nuevos.

Es hora de la pregunta de Hollywood sobre JavaScript. Ya sabes, hay un dicho: "todo lo que se puede reescribir en JavaScript se reescribirá necesariamente en JavaScript". ¿Crees que Rails también se reescribirá en JavaScript? Hablamos sobre la ergonomía del desarrollo de Ruby. Esto es lo mejor de Rails. Uno de los programadores rusos muy famosos dijo que "muchos idiomas son buenos, pero solo Ruby tiene Rails". Sin embargo, los desarrolladores de JavaScript tienden a cuestionar esto. ¿Cómo podemos competir con JavaScript? ¿O deberíamos organizar una simbiosis con él?

Es cierto que solo Ruby tiene Rails. Si observa los marcos web para JavaScript, no creo que sean bastante comparables con Rails en términos de ergonomía de desarrollo. El hecho es que, dado que estamos escribiendo aplicaciones web, tendremos que trabajar con JavaScript. Debemos ser parte de la comunidad de JavaScript. Es útil para nosotros tener una simbiosis. Si puede ejecutar cualquier idioma en el servidor, ¿por qué debería ser JavaScript? Pero el lenguaje es bueno, y creo que debemos trabajar simbióticamente. La facilidad de desarrollo todavía está de nuestro lado, y es especialmente apreciada en la comunidad de Rails. Entonces, ¿viniste a la conferencia de TI y tuviste que trabajar como representante de Ruby allí?

Fue bastante informal, porque ni siquiera tenía camisetas sobre mi empresa o idioma. Así que acabo de encontrar el grupo más brillante de jóvenes que resultaron ser pitonistas, y comenzamos a chatear.

Para nosotros, es bueno si trabajamos juntos con otros idiomas y no competimos con ellos. Personalmente, creo que programar en Ruby es mucho más fácil y divertido que en otros idiomas. Por que no Estamos hablando de otros lenguajes de programación y si debemos conocerlos. Creo que es importante que los rubistas aprendan otros idiomas. Algo como Java, Haskell u otra cosa funcional como Elixir o Lisp, algo así. Creo que es útil estudiar diferentes paradigmas, porque cuando aprendes cosas nuevas, puedes quitar esto y usarlo en tu propio idioma. Una buena característica de Ruby es que podemos usar técnicas de varios idiomas en nuestros programas.

Sí, tenemos, por ejemplo, herramientas para la programación funcional o la realización de mapas / reducciones u otra cosa.

Sí, podemos usar todo esto. Si usa un lenguaje que alienta estas técnicas, puede encontrar una mejor manera de resolver el problema. No estoy seguro de que sea necesario estudiar otros idiomas para ser un buen rubista, pero este estudio definitivamente me ayuda. Honestamente, paso el 50% de mi tiempo programando en C.

C hace los dedos más fuertes!

Estoy programando en C para que otros puedan programar en Ruby.

¿Están las partes internas de Ruby escritas en C pura, no en ++?

En un limpio. Sería bueno que se escribiera más de este código en Ruby, pero para ser honesto, algunas de las cosas principales por razones de rendimiento deberían escribirse en C. Una de las cosas que estoy haciendo ... Necesitamos mejorar el perfil de la memoria. Por lo tanto, estoy trabajando en herramientas de creación de perfiles de memoria en Ruby. Como todos los interiores están escritos en C, tengo que escribir herramientas en C. En el trabajo, escribo mucho código.

¿Cómo le va a Ruby con FFI y similares?

FFI funciona lo suficientemente bien si tiene una biblioteca C en su trabajo que necesita una o dos funciones. Si algo es más complicado ... Entonces todo es más complicado. Cuando trabajas con FFI, básicamente escribes código C que es similar a Ruby. Sin embargo, aún tiene que hacer cosas misteriosas como la administración de memoria. Personalmente, me resulta más fácil cambiar entre estos mundos si usa C para administrar la memoria, etc. Y en otros casos, me cambio a Ruby.

En Ruby, ¿tenemos interfaces para otros idiomas?

Algunas interfaces con JavaScript. Vi a un tipo que se dedicaba a tareas científicas, por lo que interactuó con Python.

¿Interactuó directamente con el lenguaje en tiempo de ejecución?

Si exactamente. No como bombardeos o algo así ... El proyecto aún es muy experimental. Cuando da una demostración, dice que "todo funciona, ¡pero puede caerse!"

Conozco a un grupo de rubistas famosos que fueron a crear Rust. ¿Por qué crees que la gente hizo esto y cómo les va?

Me gusta Rust, creo que es un muy buen lenguaje. La razón por la que las personas acuden a Rust ... quieren un lenguaje que tenga más funciones de seguridad que las que proporciona C. Sería realmente increíble reescribir Ruby en Rust. Personalmente soy un gran admirador de Rust, lo amo.

¿Cómo puede ser útil? ¿Es más seguro, más rápido o qué?

Creo que es más seguro. No estoy seguro de si está más optimizado que C, pero definitivamente es más seguro. Esto es lo que me gusta de él. Cuando escribo el código C, estoy casi seguro de que no es SEGV, pero no es 100% seguro. Pero cuando escribo en Rust, estoy seguro de mucho más. Cuando escribo en C, estoy bastante seguro de que no habrá pérdida de memoria. Con Rust, está claro como un día blanco que no habrá pérdida de memoria. Es por eso que personalmente prefiero Rust en lugar de C. También comencé a aprender Rust, porque quiero escribir extensiones para Ruby en él. Hay todo un proyecto llamado "Helix", específicamente para esto. A menudo, cuando escribo en C, es como: "OK, tengo una biblioteca en C y necesito acceder a ella desde Ruby escribiendo un par de muletas". Usar Rust para esto es un cañón gorrión. En mi mundo ideal, todo, todo el sistema algún día será reescrito en Rust. El óxido será nuestro nuevo C. Si necesita resolver un problema rápidamente, escriba en Ruby. Y el sistema operativo se hará en Rust. Y todos serán felices.

¿Es Rust lo suficientemente maduro para esto?

Bueno, no lo se. Yo pienso bastante. En Mozilla, lo usan, y están satisfechos.

¿Cuál es la oportunidad de "ver registros" ejecutando un programa en Rust?

Jaja, no lo sé! ¡Esperanza baja! Ver esto no es para nada ridículo.

Especialmente cuando lanzas algo en el navegador.

Si Aparece un mensaje sobre un bloqueo, y usted es así: "OK". Ja! En el trabajo, tenemos algunas cosas en C ++ y, a veces, cuando me caigo, simplemente me gusta esto: "Hmm ..."

¡Quiero programar en un lenguaje, no en un ensamblador de macros! - Era mi broma favorita cuando cambié de C a Ruby ...

En realidad tienes razón. Cada vez que escribo en C, la pregunta es en qué debería pensar. Realmente no pienso en el problema que se está resolviendo. Con Ruby, no necesito pensar en todo esto (economía de bajo nivel - P.A.). Me concentro en la lógica del programa y estoy haciendo negocios. ¡Esta es una de las razones por las que amo tanto a Ruby! Cuando era javista durante Java 1.3, eso fue antes de que aparecieran los genéricos. Cada vez que tenía que escribir algo como el mapa, por ejemplo, colecciones o iteradores, tenía que hacer "iterator.next ()", y luego emitir el valor resultante ... Solo entonces realizar la operación necesaria. Entonces comencé a aprender Ruby, donde el mapa ya estaba en Perl ...

... ¡Oh, un milagro! ¡En mis manos tengo un objeto del tipo exacto que necesito!

Si exactamente. En Java, tendría que escribir 15 líneas de código para lograr lo que puedo hacer como una sola línea en Ruby. Escribiría en Ruby, terminaría el trabajo mucho más rápido. ¡En lugar de escribir toda esta basura! Entender esto me molestó mucho en ese trabajo. ¡Pasé horas en tráfico extra!

Horror existencial!

Exactamente! Fue un punto de inflexión. Necesitaba encontrar trabajo en Ruby. ¡No puedo cortar Java hasta el final de mi vida!

¿Se puede argumentar que Ruby mejora la mente del programador?

Creo que si puede dedicar más tiempo a tareas de alto nivel, a los objetivos mismos del programa, esto ayudará a mejorar el pensamiento abstracto. Practica cada vez más pensando en el sistema en su conjunto, y no en los pequeños engranajes del programa. Permíteme recordarte que en C tengo que pensar constantemente en todas estas pequeñas cosas, y no en el problema que resuelvo. De hecho, está aprendiendo exactamente la resolución de problemas, es decir, las tareas de nivel superior. Creo que te puede mejorar como programador.

Recuerdo mi propia impresión cuando comencé en los años 90. Traté de dominar OOP. Traté de hacer C ++. Leí libros, aprendí la "santa trinidad de la OLP". Y luego vuelvo a encontrarme en el proceso de dominar los mismos trucos de "macro ensamblador". Luego intenté trabajar en Java, gané dinero en Perl. Y solo en Ruby finalmente entendí cómo funciona OOP.

Tú dices la cosa. Si piensa en otros lenguajes OOP, como C ++ o Java, entonces no todos tienen un objeto. Por ejemplo, todavía hay solo ints. Todavía hay primitivos, y deben tratarse de manera diferente que con los objetos. En Ruby, de hecho, todo es un objeto. Solo se debe tratar con POO. Más ejercicio, más significado. Realmente no pensé mucho en eso hasta que lo preguntaste.

El lenguaje está diseñado con tanto cuidado que solo te hace pensar en la dirección correcta. Da forma a la mente. La sintaxis misma explica lo que está haciendo.

Trabajé con OOP en Perl. Esto generalmente es solo un truco para cosas similares a OOP. Java, por supuesto, implementa OOP. Pero ella, entre otras cosas, tiene no objetos. Ruby en nuestra lista es el primer idioma en el que todo es realmente un objeto.

¿Con qué palabras inspirarías tanto a los programadores jóvenes como a los viejos?

Buena pregunta! Creo que esto es lo que funciona para los rubistas jóvenes y viejos: Personalmente, creo que Ruby es el único lenguaje que da fan cuando se usa. Los programadores jóvenes que ya dominan otros idiomas, prueben Ruby, porque es muy divertido. Viejos programadores con sólida experiencia en otros idiomas, puedes comparar todo y entender lo bueno que es Ruby. Cuando comiences a usar algo más, te dirás a ti mismo: wow, ¡pero Ruby no es nada!

Los fines de semana, hago algunos ejercicios pequeños en otros idiomas. Después del fin de semana, regreso al trabajo, abro mi Emacs con Ruby y me digo a mí mismo: "¡Dios mío, qué maravilloso es volver a tu tierra natal!"

Sí, creo que es bueno cambiar a otros idiomas, trabajar allí, acumular algunas observaciones. Siempre me complace volver. Siento que estoy en casa en Ruby.

Será posible hacerle preguntas personalmente a Aaron el 6 de octubre. ¡Nos vemos en la conferencia! Todos los detalles en el sitio .

Puede leer el original en inglés en hype.codes .

Y muchas gracias a las compañías que apoyan el evento principal de Ruby en Rusia:

Socio general - Toptal
Gold Partners - Gett y Cookpad
Socios de plata: Instamart , UCHi.ru , JetBrains y Qlean
Afterparty partner - Teachbase
Socios de bronce - Bookmate e InSales