Entrevista con el orador de la Conferencia de RubyRussia, Marcus Schirp

Hola a todos! Un poco más de una semana después, la conferencia RubyRussia se llevará a cabo en Moscú. En la entrevista de hoy, el desarrollador de Evrone , Mikhail Morgunov, habló con uno de nuestros oradores, Markus Schirp , creador de la popular herramienta Ruby Mutation Testing .


La primera pregunta es sobre Mutante . ¿Qué necesitamos saber sobre esta herramienta? ¿De qué se tratará el informe sobre RubyRussia?

Contaré la historia de la herramienta de prueba de mutaciones: Mutante. Quiero presentarle a la audiencia conceptos clave: las personas aprenderán sobre los diferentes niveles de cobertura, su significado y valor.

Esto arrojará luz sobre esas cosas en Ruby a las que estamos acostumbrados y consideramos correctas, pero de hecho hay problemas en ellas. Porque Ruby a menudo nos da una gran oportunidad para pegarnos un tiro en el pie.

¿Cómo empezaste a desarrollar mutantes?

Esta historia está relacionada con mi trabajo en DataMapper y su próxima implementación de DataMapper 2, que finalmente se denominó ROM. Projectlide Dan Kubb escribió una biblioteca de álgebra relacional llamada axioma para apoyar estos nuevos desarrollos. Cuando escribió axioma, utilizó la estrategia de "desarrollo limitado". Incluye muchas herramientas para trabajar con métricas y pruebas mutacionales.

La herramienta que usamos para las pruebas de mutación se llamaba Hackle. Tenía ciertas fallas operativas y conceptuales. Una vez pensé: "Maldita sea, ¡ni siquiera intentaré arreglarlo! Vamos a escribir uno nuevo y resolver todos los problemas de escalado de pruebas mutacionales que tenemos en DataMapper2 ".

Eso fue hace 5 o 6 años, desde que Mutant pasó por varias iteraciones. Todos ellos están conectados no con mi deseo de escribir código abierto, sino con los requisitos de los proyectos comerciales en los que trabajé. Por lo tanto, el desarrollo de Mutant depende en gran medida de mis actividades de consultoría.

Cada vez que comienzo un nuevo proyecto de Ruby, necesito estar seguro de cada fragmento de código. Y Mutante es la herramienta que uso para esto.

Es decir, ¿los clientes comerciales quieren usar Mutant?

Si Esto se confirma por el hecho de que todas las características que ve son características que los clientes comerciales me han pedido que agregue en los últimos años. Hay algunas funciones que no están en la versión pública, porque el cliente no me dio el derecho de abrir su código fuente. Pero a veces el cliente dice: "No hay problema si alguien se beneficia de esto", lo que realmente me gusta.

Por el momento, dejé DataMapper2. Nunca escribí características solo por diversión. Estos son solo los efectos secundarios del uso comercial.

Personalmente no estoy enamorado de Ruby, es solo una herramienta para mí. Mutante es una forma de hacer que Ruby sea más eficiente. El umbral para ingresar a Mutant es muy alto, pero cuando comienzas, ayuda mucho. La necesidad de capacitación es algo que hay que soportar.

Esto está en la naturaleza de las cosas cuando se usa una gema gratis :)

El 95% de las gemas gratis son solo proyectos de pasatiempo. No son adecuados para uso comercial. Los autores los hacen por interés personal. No los culpo. Pero aconsejo al equipo de desarrollo de proyectos comerciales que tengan esto en cuenta cuando toman algo de RubyGems.

Solo leí el archivo README Mutant en GitHub. Pero hasta ahora he entendido poco.

Es por esta razón que necesito pasar más tiempo escribiendo léame y documentación adicional de nivel de entrada.

Por razones personales, estuve en silencio en la comunidad durante 3 años: tuve dos hijos más, me mudé a otro país.
RubyRussia es la primera conferencia después del descanso cuando puedo hablar con la comunidad. Y quiero usar el tiempo que dedico a preparar mi informe y taller como fuente de materiales para documentación adicional.

Lo que nos espera

El 6 de octubre habrá una charla sobre Mutante, y el 7 de octubre un taller. Se basará en ejemplos del mundo real tomados de un proyecto de código abierto que utiliza rails y rspec.

Por lo que yo entiendo, ¿usas un lenguaje de programación diferente, no Ruby?

Esto no es del todo cierto. A menudo uso Ruby, pero solo si hay una buena razón para esto. Por lo general, esta es la salvación de las aplicaciones heredadas que están a punto de bloquearse bajo el peso de su propio código.

En este caso, no puedes venir y reemplazar a Ruby en un solo paso. Hacer refactorización incremental / "estrangular" el código Ruby es mi trabajo principal. Y durante este proceso, mis manos están en mi codo en Ruby, y aquí Mutante es mi herramienta principal para vincular los ciclos de refactorización / modificación.

¿Qué idiomas prefieres?

Principalmente Haskell. Ahora para mí es el lenguaje más equilibrado en términos de usabilidad e idoneidad para desarrollar programas de valor comercial. Haskell Type Checker garantiza muchas propiedades de inmediato; propiedades por las que tendría que luchar en Ruby.

Hay varios otros lenguajes y extensiones geniales en el horizonte. Creo que los tipos dependientes llevarán la "corrección después de pasar la verificación de tipos" a un nuevo nivel.

¿Crees que Ruby y Rails tienen futuro?

Ruby y Rails tienen un umbral de entrada bajo, esto ayuda a las personas a llegar rápidamente al punto donde la aplicación genera dinero. Si bien la gente cree que Ruby y Rails tienen esta calidad, estas tecnologías tienen futuro.

Una pequeña declaración herética: las aplicaciones de Rails no pueden crecer debido a la complejidad heredada del marco, debido a las elecciones hechas por los creadores del lenguaje y el marco. Pero este deber técnico está bien si tiene una razón comercial para hacerlo. Solo tenga un plan listo para pagar esta deuda.

¿Qué opinas de Rust?

Realmente me gusta. Ahora no lo uso a menudo, no había una buena razón, ya que los proyectos de trabajo no podían obtener nada de las ventajas de Rust en comparación con otras opciones que tenía.

Principalmente desarrollo backend. O llamémoslo "RPC masivo con lógica de sujeto". Aquí, en primer lugar, es importante garantizar la corrección del programa, y ​​solo en el segundo es su rendimiento. Rust es computacionalmente muy eficiente, pero para esto requiere control manual de piezas de bajo nivel. Esto lleva tiempo, que se gasta mejor en la optimización de patrones de E / S de alto nivel (agrupación RPC, minimización de viajes de ida y vuelta, verificación de propiedades transaccionales, etc.). Es mejor hacer esto antes de optimizar las primitivas individuales a expensas del lenguaje, lo que me da más oportunidades para la optimización.

Si estuviera haciendo algo más computacionalmente pesado, un códec de video, por ejemplo, Rust sería la herramienta que elegí.

Y la última pregunta. ¿Qué puede aconsejar a los programadores novatos?

Como programador novato, encuentre un proyecto favorito e intégrelo con intereses fuera de la programación. Esto es necesario para dejarse llevar el tiempo suficiente hasta que la programación de aprendizaje comience a ganar dinero.

Muy interesante! Eso debería funcionar!

Sí, así empecé :)

Gran consejo! Gracias por la entrevista! Nos vemos en Ruby Rusia.

¡También te esperamos en la conferencia! Por cierto, quedan menos de 30 boletos, por lo que no recomendamos posponer el registro si decide ir. Y si quieres sumergirte en Mutant más a fondo, entonces estamos esperando a Markus en el taller el 7 de octubre. Todos los detalles en el sitio .

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

Y aquí hay un lugar para agradecer a las grandes 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
Socios de bronce - Bookmate e InSales