"El gerente necesita seguir codificando": entrevista con Stephen Chin



Muchos desarrolladores de Java conocen a Stephen Chin . Alguien vio sus transmisiones de eventos de Java, algunos, sus entrevistas con otros famosos javists, y algunos, informes sobre Java en la Raspberry Pi. Pero lo que hay allí, en Twitter, él @steveonjava , es decir, incluso con un nombre de usuario muestra cuánto dedica su vida a este idioma.

Hasta hace poco, trabajó en Oracle, y ahora se mudó a JFrog. Puede sonar inesperado: ¿dejar Oracle cuando tu vida es Java? Pero el segundo nombre también es bien conocido por los japoneses rusos, en muchos aspectos gracias a que Baruh joguch Sadogursky trabaja allí.

Pronto, los desarrolladores rusos podrán ver a Stephen y Baruch en persona en la conferencia Joker , pero hasta ahora, Stephen nos ha contado sobre una variedad de cosas, por ejemplo:

  • ¿Qué está haciendo exactamente ahora?
  • ¿Cómo es más correcto que un desarrollador se convierta en gerente?
  • ¿Qué tan grande puede hacer un grupo de Raspberry Pi (y por qué);
  • ¿JavaFX está vivo?
  • ¿Cómo es útil una motocicleta para un activista de Java?

Oleg Chirukhin: JFrog está involucrado en CI / CD y otros, pero los javis rusos saben especialmente que Baruch trabaja allí. Probablemente lo conoces, ¿verdad?

Stephen: Sí, él y yo somos grandes amigos. Lo conocí antes del sombrero!

Oleg: Ahora eres "director senior de relaciones con desarrolladores", y el puesto de Baruch se llama "jefe de defensa de desarrolladores". ¿Qué hay exactamente detrás de esto?

Steven: DevRel es un montón de actividades diferentes. Entre ellos se encuentran los defensores de los desarrolladores: personas como yo y Baruch hablando en conferencias con presentaciones. Estos también son eventos para desarrolladores, comunicación con personas en conferencias, creación de contenido para desarrolladores, etc. En general, ahora también estoy conectado con todo esto, y vamos a aumentar la actividad en el trabajo con la comunidad.

Oleg: a juzgar por tu perfil de LinkedIn, tienes una carrera muy interesante. Primero obtuviste una licenciatura en ciencias de la computación, luego durante tres años estuviste en administración, luego durante un año: programación, luego nuevamente administración. ¿Por qué tienes tales zigzags en tu carrera? En general, ¿qué tan razonable es para un joven cambiar su campo de actividad tan a menudo?

Stephen: ¡ Es bastante razonable, así es como todos deberían comenzar una carrera! * risas *

Diría que una de las dificultades comunes para las personas que conocen bien su campo técnico es que el crecimiento profesional es más fácil de lograr al convertirse en gerente. Pero si participa en la gestión durante mucho tiempo, sus habilidades, comprensión de la tecnología y, en general, lo que lo hace valioso como líder dejan de desarrollarse. Por lo tanto, estoy convencido de que no debemos abandonar la tecnología. Continuar creando algo, continuar estudiando, continuar desarrollándose. Para una carrera, esto es solo lo más importante.

Si es necesario, tome una posición de liderazgo y ayude a los colegas a crecer; eso es genial, me alegro de eso. Pero luego me remango las mangas y hago algo específico. Creo que es importante no olvidar que esta es su principal habilidad como desarrollador.

Oleg: ¿Es fácil combinar las habilidades de un gerente y un programador en una sola persona?
Después de todo, estas son áreas muy diferentes.

Stephen: Sí, pero solo trato con la gerencia en áreas que yo mismo entiendo. Sé cómo escribir código, cómo probar, cómo aplicar metodologías ágiles, porque aprendí todo esto yo mismo. Además, he estado involucrado en la promoción de desarrolladores durante varios años, así que también tengo habilidades en esta área.

Creo que la mayoría de los gerentes tienen la parte más productiva de su carrera cuando ellos, como expertos en un determinado campo, organizan su equipo y contribuyen a su efectividad. Y luego son promovidos a gerentes intermedios típicos, y esto no trae muchos beneficios. Por lo tanto, creo que para el éxito es necesario no alejarse de lo que originalmente es bueno.

Oleg: Una vez tuviste un puesto como Chef Metodólogo Ágil. Incluso tengo miedo de sugerir lo que esto debería significar.

Stephen: Bueno, ¡todos tuvimos errores en nuestras vidas! * risas *

En cierto momento, las metodologías ágiles y la infraestructura de DevOps comenzaron a funcionar muy bien para mí. Comencé a ayudar no solo a mi equipo, sino también a otros equipos de la compañía, y también comencé a ayudar a planificar grandes lanzamientos. Luego incluso escribí una herramienta en Java para similar. La compañía comenzó a usarlo, con el tiempo se desarrolló y, como resultado, gracias a esto, pudimos salir del infierno de las tablas de Excel (si te encuentras en él, sabes que es un lugar terrible).

Pero aún así, trabajar con metodologías no es tan interesante para mí como las tecnologías. Por lo tanto, al final, volví a los asuntos anteriores.

Oleg: Sé que trabajaste mucho con JavaFX. ¿Qué te empujó inicialmente a esta tecnología?

Steven: Esta es una historia bastante interesante. Incluso antes de que saliera JavaFX 1.0, estaba trabajando en un marco de widget de escritorio. Envié un prototipo de este marco a Joshua Marinacci de Sun, quien en ese momento trabajaba como evangelista de Java. Personalmente, no lo conocía, aunque lo respetaba, así que no esperaba ninguna respuesta. Pero él respondió, dijo que le gustaba la idea y sugirió probar JavaFX, que en ese momento estaba completamente fuera de mi vista. Tuve tres días libres (debido a las vacaciones), y durante estos tres días reescribí mi marco en JavaFX, después de lo cual Joshua envió el resultado nuevamente.

En general, así es como comenzó mi conocimiento de JavaFX y apareció mi WidgetFX. Creo que sabe que no todo salió bien en la historia de esta herramienta, pero ahora creo que es absurdo usar AWT o Swing para escribir herramientas de escritorio en Java.

Oleg: estoy completamente de acuerdo. Es cierto, IntelliJ IDEA todavía usa Swing.

Stephen: Bueno, IDEA se creó a principios de la década de 2000. Por supuesto, hay personas que se dedican a admitir aplicaciones grandes con una gran cantidad de Java2D heredado, y en este caso, por supuesto, no tiene que elegir. Pero para las nuevas herramientas, en mi opinión, es una locura usar el kit de herramientas, que tiene más de 20 años.

Oleg: ¿Qué espera JavaFX en el futuro? Después de todo, ahora ella ha dejado de ser parte del JDK.

Stephen: Bueno, JavaFX sigue siendo parte del proyecto OpenJDK. Se eliminó del ensamblaje de Oracle, pero este ensamblaje sigue siendo comercial ahora, por lo que la pérdida es pequeña. ¿Qué puedo decir? Utilice las compilaciones JavaFX de Gluon. Por cierto, también están involucrados en JavaFX móvil, en general, hacen muchas cosas importantes para el ecosistema.

Oleg: ¿Y qué hay de los proyectos JavaFX como su WidgetFX ahora?

Stephen: Específicamente, el trabajo en WidgetFX ya no está en curso, pero hay otros proyectos que la comunidad apoya. En general, el ecosistema JavaFX es vibrante. Hay muchos casos en los que JavaFX es indispensable y le permite escribir cosas que son difíciles de reproducir en JavaScript.

Oleg: ¿Tienes un proyecto de Nighthacking? ¿Puedes contarnos al respecto?

Stephen: Incluso antes de comenzar a trabajar en Oracle, comencé una gran serie de entrevistas bajo el nombre general de Nighthacking. Tomé una mochila con equipo, vine a la conferencia y grabé entrevistas similares a la que me estás tomando ahora.

Utilicé varios servicios para publicarlos en Internet, pero al final me decidí por Periscope, que Chris Thalinger me sugirió. Esta es una gran plataforma para publicar entrevistas y ayudar a las personas a aprender sobre nuevas tecnologías.

Además, Baruch y yo tuvimos la idea de crear un programa en un formato similar sobre el tema de DevOps. Planeamos lanzarlo en su conferencia Joker, se llamará DevOps Speakeasy.

Oleg: Eso sería genial. Que yo sepa, ¿viajaste en motocicleta con otro desarrollador de Java que conocemos, Sebastian Dashner?

Stephen: Sí, viajamos por todo el mundo, estábamos en Europa, en Japón. A primera vista, puede parecer que una motocicleta es un medio de transporte extraño, pero cuando necesita visitar diez grupos de usuarios diferentes en diferentes ciudades en dos semanas, como lo hicimos en Japón, la motocicleta es muy efectiva.

Oleg: Ya que viste muchos grupos de usuarios de Java en todo el mundo, ¿hay alguna diferencia cultural entre grupos en diferentes partes del mundo?

Steven: Creo que hay más similitudes que diferencias. Muy a menudo, estos grupos existen a expensas de los propios geeks, que los organizan, es decir, funcionan de forma voluntaria. Yo mismo, cuando dirigía un grupo de usuarios en el área de la Bahía de San Francisco, sentí esto como una forma de ayudar a otros, tal como ellos me ayudaron en mi tiempo. Los grupos de usuarios le permiten compartir conocimientos, realmente me gusta caminar en ellos, el espíritu de la comunidad late en ellos. Para los defensores de los desarrolladores, es mejor hacer grupos de usuarios.

Oleg: Tienes muchos videos sobre robótica, Raspberry Pi y más. ¿Lo haces profesionalmente o es más un pasatiempo?

Steven: Comencé a trabajar en robótica porque en Oracle teníamos proyectos Java para Raspberry Pi y otras plataformas integradas. Y luego vi que es muy conveniente para Raspberry Pi enseñar a los niños a programar. E hice mucho de esto, organicé seminarios para niños en varias conferencias. Anteriormente, mi hija me ayudó en estos seminarios, ahora ella misma dirige los mismos seminarios. Conecta sensores integrados (como sensores de luz, acelerómetros) al Raspberry Pi, muestra ejemplos de código muy simples con estos sensores y, por lo tanto, enseña a los niños. Gracias a estas lecciones, puede aparecer una nueva generación de programadores en el futuro cuyo interés en el código surgió muy temprano.

Oleg: Quizás algún día ella juegue en Joker. ¿Sigue siendo la Raspberry Pi la mejor plataforma de robótica? Dicen que las nuevas versiones se sobrecalientan mucho, recuerda los tweets de Alexei Shipilev. Aunque da miedo imaginar a qué cargas los somete Shipilev, cuéntenos sobre un uso más "normal".



Stephen: Para aquellos que se dedican a este negocio como pasatiempo, la ventaja de Raspberry Pi es que el sistema es muy fácil de levantar: conéctelo a un puerto USB, inserte una tarjeta SD normal, toma media hora hacer todo. Como ya dije, en Oracle trabajé en un equipo que se dedicaba a sistemas integrados comerciales, aunque yo estaba involucrado en la promoción de desarrolladores, pero había mucha gente a mi alrededor que probó y configuró varias plataformas integradas. Entonces, para ejecutar las cosas más simples en un sistema comercial, tomó varias semanas gastarlo.

Las plataformas que están diseñadas para el desarrollo y no para la producción no funcionan en muchas áreas y necesitan pruebas adicionales. Surgen varios problemas, por ejemplo, puede que no haya controladores para la pantalla, algunas características pueden no funcionar, las plataformas en sí mismas a menudo no funcionan (si se trata de prototipos). Y, en general, las personas están acostumbradas a este estado de cosas: si tiene una nueva plataforma, para comenzar a trabajar en ella, debe pasar aproximadamente un mes.

Usando las mismas tecnologías, la Fundación Raspberry Pi en el Reino Unido creó una plataforma que es fácil de usar en educación, es simple, eficiente y tiene un gran ecosistema. En particular, es bueno para aquellos que desean hacer algún proyecto simple en su tiempo libre; por cierto, escribí un libro sobre Java y Raspberry Pi.

Raspberry Pi elimina la mayor parte de la incertidumbre que está abierta al usuario de otras plataformas integradas, y con ella no hay necesidad de desarrollar componentes para la plataforma usted mismo. Por lo tanto, en Raspberry Pi puede hacer sus pequeños proyectos en su tiempo libre, no tiene que hacerse profesionalmente.

Oleg: ¿Ha cambiado el lado robótico de la Raspberry Pi con los años? No hice esto a propósito, pero que yo sepa, Java tiene GPIO por defecto. ¿Hay marcos, o tal vez los propios fabricantes de hardware brindan soporte?

Steven: Hay muchos proyectos financiados por la comunidad, como Robo4J: es una plataforma robótica en IOT basada en Raspberry Pi. Otro gran proyecto con acceso GPIO es el Pi4J. Utiliza la misma biblioteca C que todos los demás, WiringPi, pero además proporciona un shell Java muy eficiente que tiene un rendimiento excelente.

Realicé encuestas GPIO de bajo nivel para simular pines analógicos. Por lo general, en Raspberry Pi esto es muy difícil de hacer, ya que no es un sistema operativo en tiempo real. El contenedor Java agrega pausas para la compilación JIT y similares. Pero con la ayuda de la biblioteca Pie4J de bajo nivel, pude usar el sensor de distancia analógico en el controlador en Java. En general, con Raspberry Pi puedes hacer muchas cosas interesantes directamente desde Java. Y, por supuesto, además de esto, hay un gran ecosistema en C, Python y más.

Oleg: Vi que la gente crea grupos de Raspberry Pi. ¿Tiene esto algún significado práctico?

Steven: En Oracle Code One, pronto habrá una presentación del proyecto en el que participé, este es un clúster de 1024 Raspberry Pi.

Como saben, no es difícil ensamblar un grupo de 10 o 20 Pi, aunque llevará bastante tiempo. Si el clúster tiene más de 1000 Pi, hay problemas con el consumo de energía, la carga desde una tarjeta SD o sobre la red, con la topología e infraestructura correctas de la red: el mensaje entre los nodos de la red no debería convertirse en un cuello de botella en los cálculos. Además, enfriar tal cantidad de Pi en una habitación no es una tarea trivial. Pero cuando superemos todas estas dificultades, será el grupo más grande de Raspberry Pi en el mundo. Por cierto, tendrá la forma de una cabina telefónica azul de la policía británica, como usted mismo sabe lo que es una serie de televisión de ciencia ficción. Espero que no hayamos violado los derechos de autor de nadie.

Un grupo de este tipo es como tener un ferrocarril de juguete con trenes, pero al mismo tiempo simula una red ferroviaria a gran escala. Según este modelo, un tren real nunca puede pasar, y la misma historia aquí: un clúster de 1024 Raspberry Pi no será más poderoso que incluso una GPU moderna con varios cientos de núcleos, pero este clúster es útil para simular el comportamiento de sistemas grandes. Además, es ideal para algunas tareas muy paralelizadas. Pero muy a menudo la red o la velocidad de lectura y escritura de las tarjetas SD se convierte en un cuello de botella. Y para algoritmos complejos, son precisamente estas cosas las limitaciones reales.

Oleg: Sí, y este clúster puede usarse como modelo de capacitación, puede intentar implementar algo usando Kubernetes, Docker y algunos productos JFrog.

Stephen: ¿Por qué no? * risas *

Oleg: Usted es un ex empleado de Oracle y ha estado haciendo Java durante mucho tiempo. ¿Cómo ves el futuro del lenguaje? ¿Quizás es para GraalVM, Valhalla o algo así?

Stephen: Con los lanzamientos de Java en el futuro cercano, aparecerán muchas tecnologías interesantes. Los dos más importantes, uno de los cuales ya ha nombrado, es GraalVM. Esta es la infraestructura del compilador de próxima generación. Estamos hablando de un compilador escrito en Java y para Java, que puede funcionar con varios idiomas, y que es mucho más fácil de optimizar que HotSpot normal. Creo que a la larga este compilador superará a otros compiladores JVM y se convertirá en una parte importante de la arquitectura Java.

Una ventaja significativa de GraalVM es la compilación AOT. Es especialmente útil para dispositivos móviles e integrados. El código se compila de antemano, el binario se implementa en el dispositivo y el tiempo de inicio y la memoria requerida son comparables al código en C, Go y otros idiomas. Además, la compilación AOT le permite trabajar de manera más eficiente con microservicios o arquitectura sin servidor, donde muchos procesos se ejecutan simultáneamente en múltiples servidores o en diferentes subprocesos en la misma máquina. Si es necesario, puede ejecutar una JVM separada para cada contenedor Docker o entorno virtual. En general, para cosas como serverless en Java hoy, GraalVM se ha vuelto casi indispensable.

Otra nueva tecnología interesante en la que está trabajando el equipo de JVM es Fibers. Le permiten crear aplicaciones Java de manera tradicional, con subprocesos, pero al mismo tiempo tienen el mismo rendimiento que si estuviera utilizando un marco asincrónico, por ejemplo, Vert.x, Node.js u otro.

Siempre hay una contradicción en la programación: por un lado, la necesidad de optimizar el rendimiento del código, por otro lado, el deseo de escribir código claro y fácil de mantener. Un sistema con hilos es más fácil de leer y más fácil de buscar errores. Los sistemas asincrónicos le permiten obtener un rendimiento adicional del código, ya que cada subproceso se utiliza al máximo, ya que las solicitudes se extraen dentro de un proceso. Pero para obtener esta ventaja, es necesario cambiar el modelo de programación, el sistema se vuelve más difícil de mantener. Fibers hace posible escribir código con hilos, pero al mismo tiempo tiene el rendimiento de un marco asincrónico.

Oleg: En realidad, algunos cambios ya se han realizado en OpenJDK para prepararse para la llegada de Loom. Por ejemplo, en JEP 353: vuelva a implementar la API de Socket Legacy .

Stephen: Hasta donde yo sé, se está implementando la infraestructura básica para Fibers and Loom, pero no estará abierta a los usuarios, porque los desarrolladores no quieren que las personas trabajen con ellos directamente. Así que ahora estamos trabajando en una API para Fibras.

Oleg: ¿Usas las últimas versiones de Java?

Steven: Por supuesto, siempre tengo la última versión. Como mas? Es cierto, no estoy escribiendo código de producción en este momento. Al trabajar con prototipos o al explorar nuevas bibliotecas y marcos, no hay razón para no usar la última versión de OpenJDK. Si el trabajo va con el sistema en producción, puede ser difícil cambiar rápidamente a la última versión.

Las grandes organizaciones tienen más dificultades para cruzar la frontera de Java 9. Luego hubo modularidad y trajo consigo muchos otros cambios. A menudo, muchos de los marcos y tecnologías de los que depende el proyecto aún no se han migrado a Java 9 y versiones posteriores, lo que también dificulta la transición. Si se pasa esta línea, entonces es mucho más fácil actualizar más, ya que las próximas versiones (10, 11, 12 y, si no mezclé nada, pronto 13) son bastante similares. En términos de compatibilidad, el mayor cambio es la modularidad.

Oleg: Y dejando Java Enterprise.

Stephen: si.

Oleg: Finalmente, ¿puedes contarnos algo sobre tu nuevo informe, con el que nos acompañas en Joker?

Steven: Cuando hablas mucho con los oradores, sigues las aplicaciones que se presentan en la conferencia y, en general, las tendencias de la industria, puedes ver la cantidad de publicidad que siempre aumenta en torno a las nuevas tecnologías, ya sean chat bots, sin servidor, aprendizaje automático, inteligencia artificial o cualquier otra cosa Las personas siempre tienen mucha emoción por estas cosas debido a su novedad, siempre quieres saber todo sobre ellas lo más rápido posible.

Pero a menudo es difícil determinar si los avances importantes realmente están detrás de este bombo, o si no hay nada más que el bombo. En mi charla en Joker, quiero resolver esto. , , , , . , , .

Joker. - , — , . — , , DevOps Speakeasy. , -.

: . , , . , — -! , -.

Source: https://habr.com/ru/post/467383/


All Articles