Hoy en nuestro estudio virtual está Sebastian Dashner. En resumen, quién es este:
En esta entrevista hablaremos sobre los siguientes temas:
Texto oculto- Un saludo habitual: cómo le gustó en Rusia y Siberia, un paseo en bicicleta JUG;
- ¿Qué hacen los Defensores del desarrollador y si son ociosos?
- De qué lado está el código abierto de IBM;
- Mantener la productividad del desarrollador (con un enlace al YouTube de Sebastian);
- Situación actual en torno a Java EE y Jakarta EE;
- ¿Necesito fusionar Java EE y Jakarta EE;
- Opinión sobre el proceso de especificación de Eclipse;
- Una charla sobre el perfil de IBM WebSphere Liberty, las diferencias con respecto al perfil completo y la relación con el producto real;
- Relación con el proyecto Helidon y qué pasa con "tirar Java EE y volver a escribirlo";
- Soporte de nube Java: Kubernetes, Istio;
- Última pregunta: Linux en el escritorio.
Las entrevistas son, como siempre, por Evgeny Trifonov ( phillennium ) y Oleg Chirukhin ( olegchir ) del Grupo JUG.ru.
Eugene: Comencemos con un problema no técnico. En tu Twitter, vi una fotografía tuya en Novosibirsk con una sudadera JAVA. ¿Cuál es tu impresión de este viaje?
Sebastian: Me alegro de que hayas reconocido la foto, tengo esta sudadera con Joker 2017. Definitivamente recuerdo la conferencia de JBreak. Nunca hubiera imaginado que iría a un rincón tan lejano de Siberia. Creo que, de mi círculo de amigos, soy uno de los pocos que han estado allí. Además, el día antes de la conferencia, celebré mi cumpleaños y fuimos a andar en moto de nieve, después de lo cual nos sentamos en una casa de baños y comimos kebabs. En general, hay muchos recuerdos agradables. La naturaleza alrededor de Novosibirsk es muy hermosa. Y el hecho de que, si cuentas a Krasnoyarsk y Tomsk, durante mil kilómetros a tu alrededor, no hay otras ciudades importantes, es muy impresionante.
Eugene: Usted es el Defensor del desarrollador de Java en IBM. Esta no es una posición muy común: otros defensores de desarrolladores que conozco tienden a promocionar los productos de su empresa. ¿Cuáles son sus responsabilidades exactas en IBM? ¿Estás tratando de maximizar la distribución y el uso eficiente de Java de todas las formas posibles?
Sebastian: Sí, esta es una descripción bastante precisa de lo que hago. Debo agregar que, en primer lugar, me interesan no tanto la empresa o el producto, sino los desarrolladores. Me esfuerzo por facilitar su trabajo y enseñarles cosas relacionadas con Java Enterprise de una forma u otra. Comparto mis conocimientos en blogs, podcasts, seminarios y conferencias. No vendo ningún producto en particular, sino que vendo la tecnología como un todo.
Eugene: Usted es un gran defensor del código abierto, pero trabaja para IBM, que para la mayoría de las personas no está asociado con el código abierto. Al mismo tiempo, sé que IBM a veces toma una parte bastante activa en muchos proyectos de código abierto, por ejemplo, en OpenJ9. ¿Cómo se relaciona IBM con el código abierto?
Sebastian: Usted notó correctamente que muchas veces subestiman la participación de IBM en proyectos de código abierto; yo mismo no tenía idea de esto hasta que comencé a trabajar en esta empresa. Por ejemplo, IBM trabaja mucho en Cloud Native y en Java y es uno de los principales contribuyentes a Kubernetes e Istio. El acceso a la fuente OpenJ9 fue abierto por la Fundación Eclipse, que, a su vez, fue creada por IBM. La compañía también contribuyó al desarrollo de tecnologías sin servidor, como Apache OpenWhisk. En general, los programadores de IBM son muy abiertos: casi todo lo que se está haciendo en esta empresa tiene un aspecto de código abierto o una versión abierta. Hasta ahora, las personas no están lo suficientemente familiarizadas con los esfuerzos de IBM en esta dirección, y mi trabajo como Promotor de desarrolladores es, entre otras cosas, mantener informada a la comunidad.
Oleg: Hace poco leí en Twitter que hiciste un viaje especial en motocicleta JUG en Japón con Steve Chin. JUG en motocicletas, ¿qué? ¿Podrías dar más detalles sobre esto?
Sebastian: Fue un gran viaje. Steve Chin y yo ya hemos viajado en motocicletas varias veces, y cada vez tratamos de combinar esto con discursos en conferencias y grupos de usuarios. Varios de estos viajes fueron en Alemania, y tres en Japón. A primera vista, puede parecer que estamos haciendo esto solo por diversión, y, por supuesto, no podemos negar que la pasamos muy bien en estos viajes. Pero desde un punto de vista puramente práctico, una motocicleta es una forma de transporte muy conveniente para Japón o Europa Central, porque hay ciudades con grupos de usuarios y una comunidad de TI ubicadas a solo cien o dos kilómetros de distancia, y puede evitar atascos en una motocicleta. En cada uno de estos viajes, tratamos de reunirnos con el máximo número de personas y compartir nuestro conocimiento con ellos.
Oleg: Viajas mucho e incluso fuiste a Rusia, aunque no es tan fácil obtener nuestra visa. Existe la opinión de que Developer Advocate no es una ocupación seria. Como si estuvieras viajando por el mundo, divirtiéndote en conferencias, cualquier cosa, solo para no escribir código. ¿Crees que tienes un trabajo realmente duro? Parece que volar todos los días debería ser agotador.
Sebastian: Creo que ambos puntos de vista son un poco correctos. Me gusta mi trabajo, pero está lejos de ser siempre simple. Uno no interfiere con el otro. De hecho, los viajes pueden ser agotadores, especialmente si no descansa justo después de la mudanza, sino que habla en una conferencia u organiza un seminario. Y justo después de la conferencia, debe abordar el avión nuevamente, por lo que todo el día está ocupado. Por otro lado, si esta actividad no se llevara a cabo, entonces el techo pasaría rápidamente de ese ritmo, y una persona simplemente se quemaría. En general, si logro enseñarle algo a la gente y realizar un seminario exitoso en un día, incluso la fatiga se vuelve placentera.
Eugene: Hasta donde yo sé, este trabajo requiere mucho esfuerzo para mantenerse actualizado con las últimas tecnologías en el campo. Debido a las cargas de trabajo adicionales para los Defensores del desarrollador, esto es más difícil que para aquellos que programan constantemente. Sé que regularmente escribes código para Jakarta EE, por lo que obviamente no te has alejado de la tecnología. ¿Es difícil ser un Defensor del desarrollador y un desarrollador al mismo tiempo?
Sebastian: Sí, por supuesto, para mi trabajo es muy importante seguir siendo un programador, de lo contrario perderás contacto con la realidad. Para hablar sobre tecnología de manera competente, necesita experiencia constante trabajando con ella. Y el tiempo de programación es realmente mucho menor debido a las conferencias. Además, debe estar realmente fascinado por el aspecto técnico de las cosas y estaría listo para pasar las tardes y los fines de semana. En general, se necesita un cierto equilibrio entre ambos lados de la actividad.
Oleg: Pasemos a cuestiones técnicas. Hay un epígrafe en la primera página de tu blog:
Debe ser simple y productivo.
Debe resolver problemas, no crearlos.
Creo que TI es una oportunidad, no un factor de costo.
¿Cuáles son, en su opinión, los factores más importantes que determinan la productividad de un desarrollador de Java? ¿Hay algún consejo sobre cómo ser más productivo, trucos para la vida, nishtyaki técnico específico y utilidades como jcmd o sdkman, algo?
Sebastian: Sí, hay muchos de esos programas. En cuanto a la simplicidad, estamos hablando de la necesidad de luchar por deshacernos de la complejidad excesiva tanto en las herramientas que desarrollamos como en las implementaciones donde usamos estas herramientas. A menudo, los desarrolladores se sienten atraídos por la complejidad en sí misma, se agregan más y más características al producto únicamente por interés deportivo. Siempre debe preguntarse: ¿mejorará el mundo con esta característica? ¿Ayudará a resolver algún problema? ¿Nos acercará a completar el producto?
Si hablamos de la productividad del propio desarrollador, realmente puedo recomendar recursos para esto. Google mi nombre y la frase "productividad del desarrollador". Grabé un curso de video, que se publica en Youtube , y allí doy consejos solo sobre este tema. Habla sobre el uso de la línea de comandos, las teclas de acceso rápido y cómo usar el teclado. El punto general es cómo hacer más trabajo en menos tiempo. Y si comienza a profundizar en este tema, el proceso de automatización y optimización del trabajo se retrasará. Tendrás más tiempo para pensar en la solución del problema y tocarás las teclas con menos estupidez. En general, el rendimiento de programación es un tema muy cercano a mí.
Oleg: Por lo que yo entiendo, eres un committer en MicroProfile y, por lo tanto, puedes saber todo lo relacionado con él. ¿Cuéntanos qué está pasando en Java EE y Yakarta? Leí un poco al respecto, pero para mí, como persona del mundo de la primavera, todo esto es demasiado confuso.
Sebastian: Como probablemente sabrás, Jakarta EE es el sucesor de Java EE, que ahora se transfiere a la Fundación Eclipse. Este es un proceso bastante complicado, y aún no se ha completado, por lo que los desarrolladores aún no pueden usar Jakarta EE. Sin embargo, la base todavía se basa en los estándares Java EE, el punto de partida será Java EE 8. Por supuesto, en el futuro, Jakarta EE continuará evolucionando de la misma manera que Java EE evolucionó a través del JCP (Proceso de la Comunidad Java). Esto significa que una comunidad de varias compañías, corporaciones y desarrolladores individuales desarrollarán conjuntamente estándares para la nueva versión empresarial de Java.
Debido a estos cambios en Java EE, surgió MicroProfile. Fue creado por varios proveedores que ejecutan servidores Java EE. El objetivo aquí es garantizar un desarrollo más rápido de la tecnología, menos atado a estándares estrictos. Me parece muy interesante que MicroProfile está tratando de compensar las deficiencias de Java EE con respecto a los modernos microservicios nativos de la nube. Por ejemplo, Java EE todavía no tiene sistemas para configuración inyectable, tolerancia a fallas, monitoreo, todo tipo de OpenTracing y similares. MicroProfile le brinda acceso a todas estas cosas, por lo que no necesita implementarlas todas usted mismo. Además, en casi todos los casos, se respeta la compatibilidad con Java EE. Se toman como base los estándares Java EE (como JAX-RS y CDI), con los que la mayoría de los desarrolladores de JavaEE ya están familiarizados. Por lo tanto, cuando encuentro tolerancia a fallas en mi aplicación Java EE, por ejemplo, no escribo todo esto manualmente, sino que integro MicroProfile con mi aplicación. Estos dos ecosistemas se mezclan muy bien juntos. Para muchas aplicaciones, como Open Liberty o Payara, los tiempos de ejecución son compatibles con MicroProfile y Java EE. Todo lo que queda por hacer en este caso es incluir ciertas características en el tiempo de ejecución y luego agregar los proyectos necesarios de MicroProfile a la aplicación Java EE. Mientras esperamos la transición final de Java EE a Eclipse Foundation, puede usar esta solución.
Oleg: ¿Crees que MicroProfile debería formar parte de Yakarta?
Sebastian: Esta es una gran pregunta, y aún no hay una decisión final al respecto. Personalmente, creo que MicroProfile funciona mejor como una especie de incubadora para Jakarta EE. El nuevo estándar se agrega primero a MicroProfile (como se hizo con OpenTracing o configuración inyectable), y luego observamos cómo se comporta el sistema en la producción. Cuando alcanza la madurez, esos elementos de ella que han demostrado ser estándares completos. Por lo tanto, nos deshacemos de cierta incertidumbre, porque ya sabemos si el sistema funciona bien en la producción o no.
Oleg: Como estábamos hablando de estándares, vi los procesos de especificación de Eclipse, era un gran googlodok, que era muy difícil de entender. Los documentos con especificaciones preliminares de Jakarta EE parecían una maraña infernal. ¿Podrías ayudar a esta pelota a relajarse? Por ejemplo, ¿cómo difiere esto del Proceso de la Comunidad Java?
Sebastian: Eclipse Foundation es una organización de código abierto. En este momento, estamos tratando de determinar la forma de esos procesos de acuerdo con los cuales Jakarta EE se desarrollará en el futuro. Usted mencionó JCP; por lo tanto, estoy completamente de acuerdo con la opinión de que los estándares para Jakarta EE deben basarse en JCP. Creo que este modelo se mostró muy bien. Debe tenerse en cuenta que ninguna empresa tiene el monopolio del desarrollo de normas para Jakarta EE. Varias empresas con más o menos los mismos derechos participan en este proceso, por lo que no se quedará estancado en el desarrollo si una de ellas ya no puede participar en él. Creo que esta es una ventaja importante, porque esta tecnología es muy importante y es más seguro desarrollarla en una comunidad abierta.
Oleg: una tecnología tan sofisticada necesita ser probada en algo. ¿Utiliza kits de compatibilidad de tecnología para Java y Yakarta? ¿O tienes tu propio conjunto de pruebas?
Sebastian: Este también es un tema muy importante. En JCP, todos estos TCK generalmente tenían código cerrado. Esta fue una ventaja bastante dudosa. Por un lado, la especificación podría proporcionar pruebas que mostraran si alguna implementación era válida o no. Pero el desarrollador ordinario no sabía exactamente qué se probó allí dentro, cuál era la cobertura de estas pruebas, etc. Ahora TCK se ha convertido en código abierto. Todas las empresas y desarrolladores ahora pueden participar en su desarrollo y mejora. Si resulta que el producto de una compañía no funciona como se indica en la especificación, entonces no solo puede indicar esto a la compañía, sino también dejar una solicitud en TCK. O incluso mejor, puede enviar algunas solicitudes de extracción y mejorar TCK. Por lo tanto, no solo mejora el software de un proveedor, sino todo el ecosistema.
Oleg: Hay otro producto que tiene la palabra "Perfil" en su nombre: IBM WebSphere Liberty Profile. Ya que está trabajando en IBM, ¿puede decirnos qué es y cuál es la diferencia con Open Liberty?
Sebastian: WebSphere Liberty Profile es una versión comercial de Open Liberty. Este es el servidor de aplicaciones Java EE para el que IBM proporciona soporte comercial. Podría estar equivocado, pero, en mi opinión, Open Liberty se convirtió en código abierto hace un año y medio. Gracias a esto, los desarrolladores empresariales ahora tienen un servidor de aplicaciones gratuito y probado en producción. Si una empresa necesita soporte comercial o algunas características comerciales, puede utilizar el Perfil de WebSphere Liberty. Es 2019, y creo que ahora todas las empresas deberían proporcionar una versión de código abierto de su producto para que los desarrolladores tengan la oportunidad de probar el producto de forma gratuita. OpenSource es muy importante, y me alegra que IBM ahora tenga varias opciones para el antiguo WebSphere Liberty Server.
Oleg: Escuché que está escrito encima de OSGi. ¿Podrías contarnos más sobre cómo está organizado por dentro?
Sebastian: Personalmente no desarrollé Open Liberty, pero que yo sepa, realmente se encuentra bajo OSGi. Es interesante que allí simplemente puede configurar qué características se incluirán. Si desea utilizar solo MicroProfile, que cubre solo un pequeño número de estándares Java EE, puede configurar el sistema en consecuencia. O puede hacerlo para que tenga una aplicación Java EE completa. Debido al hecho de que solo se incluye lo que realmente se necesita en una instancia en ejecución, se logra un tiempo de inicio óptimo y un consumo mínimo de recursos.
Oleg: ¿La configuración y el uso de Liberty Profile son diferentes de Full Profile? ¿Se utilizan las mismas herramientas en ambos casos?
Sebastian: No hay diferencias significativas en el uso. En cuanto a la elección de características, ambos servidores se pueden configurar por igual. Si tiene una aplicación Java EE o MicroProfile, la configuración será la misma para ambos tipos.
Oleg: Las empresas han estado utilizando el perfil completo durante mucho tiempo. ¿Cuán justificado está el uso de Liberty Profile en grandes organizaciones?
Sebastián: absolutamente justificado. Incluso si la compañía compró soporte comercial, esto no significa que deba usar el perfil completo, es bastante razonable usar una versión más liviana. Si el producto de la corporación se basa en microservicios modernos y tiempos de ejecución ligeros, entonces podría ser mejor para ellos elegir WebSphere Liberty y configurarlo para que funcione, por ejemplo, solo con MicroProfile. Afortunadamente, el soporte comercial y las características comerciales no tienen nada que ver con el viejo mundo de WebSphere, por lo que el tiempo de ejecución es sorprendentemente ligero y compacto, se inicia muy rápidamente y se puede implementar en segundos. Entonces, si tiene una aplicación moderna basada en Java EE, puede configurar sus características en consecuencia e incluir solo los estándares que realmente se necesitan. Independientemente de si utiliza funciones comerciales, aún tiene acceso a este tiempo de ejecución rápido y moderno.
Oleg: En octubre, Oracle lanzó Helidon, un marco de microservicios ligero en Java. Hasta donde yo sé, no utiliza ninguno de los servidores de aplicaciones existentes, está construido sobre su propio conjunto de bibliotecas. Juntos proporcionan la base para crear microservicios: características para la configuración, la configuración de seguridad, la creación del servidor web, etc. Además de este sistema, incluso se implementó MicroProfile. Tengo la impresión de que los desarrolladores de Helidon piensan que Java EE tiene demasiado legado y necesita ser descartado y reescrito. ¿Qué opinas de esto?
Sebastian: Helidon es un proyecto muy interesante. Pero para ser honesto, me parece ingenuo pensar que Java EE necesita ser reescrito por completo. De hecho, la mayoría de las aplicaciones no necesitan Java EE en su conjunto. Como regla general, se requiere un conjunto dedicado de características / estándares, que se utiliza con mayor frecuencia en aplicaciones empresariales. Por ejemplo, un MicroProfile normal aún no proporciona JPA o scripts complejos para subprocesos múltiples. Esto requiere al menos algunos componentes Java EE. En general, ahora veo el proceso de creación de una aplicación de esta manera. Basado en los componentes más importantes y modernos de Java EE, por ejemplo, CDI, JPA, JAX-RS, JTA, etc., seleccionamos el conjunto de estándares que necesitamos, mientras ignoramos las muchas cosas heredadas que están presentes en Java EE. En base a esta elección, tomamos el tiempo de ejecución que admite todas estas características. Si estamos haciendo algo relacionado con los microservicios nativos de la nube, entonces agregamos estándares MicroProfile, por ejemplo, tolerancia a fallas. Pero un tiempo de ejecución como Helidon no admite características que pertenecen exclusivamente a Java EE, y mientras tanto, el multihilo o JPA son características que, en mi experiencia, son muy necesarias. Preferiría un tiempo de ejecución que sea compatible con Java EE / Jakarta EE y Microprofile, y al mismo tiempo da la oportunidad de elegir las características que se necesitan para una aplicación en particular. Por ejemplo, si necesita persistencia y tiene una base de datos, puede habilitar JPA. En general, tendrá un conjunto de características muy similar a MicroProfile, pero también será necesario algo de Java EE. Este tipo de tiempos de ejecución son Open Liberty, Payara, WildFly, etc.
Oleg: Hasta donde yo sé, una de las características más interesantes que se implementarán en Yakarta en el futuro cercano es el soporte para las tecnologías modernas en la nube. ¿Qué pasa con Java en contenedores en este momento? Hasta donde recuerdo, hace varios años en el rastreador de errores de OpenJDK había varios errores relacionados con la compatibilidad, el tamaño del montón, las señales, etc. ¿Es posible usar Java en contenedores ahora, en 2019?
Sebastian: Sí, definitivamente lo es. La razón de la mayoría de los problemas asociados con esto no fue Java en sí, sino la forma en que Linux funcionaba con contenedores. A menudo, el contenedor simplemente no conocía las diversas restricciones de recursos que se podían establecer. En versiones recientes, estos problemas se han resuelto. Ahora puede simplemente ejecutar Java en el contenedor, y estas opciones estarán habilitadas por defecto. Y si solicita el tamaño de la memoria en el sistema o el tamaño de almacenamiento dinámico predeterminado, estos valores se especificarán correctamente. Java EE funciona muy bien en los contenedores Docker y, en general, se integra bien con las tecnologías nativas de la nube.
Oleg: ¿Qué pasa con la infraestructura? ¿Utilizas algo como Kubernetes o Istio?
Sebastian: Sí, bastante activo. Docker, Kubernetes, — Istio. Java EE. Cloud-native , , , — , , , ..
: Java EE Kubernetes ? API ?
: Kubernetes Istio . cloud-native . . , Docker, Kubernetes. , - URL, . Kubernetes DNS Istio. . , — -, .
: Java ?
: — Java , . , enterprise- — MicroProfile, cloud-native (Istio, Kubernetes). MicroProfile , . , .
: JPoint « Java Enterprise». ?
: , enterprise-, . — - ; — . Java EE-, , , , .
JPoint. , — . Java-, — .
: . (, «» ). Linux, : ?
: . Linux , , , , . , , . , , . , , . Arch Linux — , . Linux . Ubuntu UI, . — Linux , , , . , , , .
: !
, 5-6 , JPoint «Bulletproof Java Enterprise applications for the hard production life» . Simon Ritter, Kohsuke Kawaguchi, . .
.