Desarrollador y facilitador, no way

Como ya comenté en un artículo anterior, desde hace un tiempo estoy trabajando en un proyecto Java, una tecnología que no domino plenamente.

El miércoles pasado participé de una retrospectiva de este proyecto que fue facilitada por Alan y que me dejó pensando un buen rato. Ocurre que durante la retrospectiva Alan hizo dos sugerencias puntuales que yo mismo he hecho a otros equipos en reiteradas ocasiones pero que curiosamente esta vez no las sugerí a mi propio equipo.

Todo el viaje de vuelta a casa me lo pasé analizando esta cuestión y finalmente llegué a una conclusión que me convenció: mi falta de pleno dominio de Java me obliga a poner demasiada energía en cuestiones técnicas, lo que me hace perder de vista algunas otras cuestiones.

Luego de pensarlo por un par de días y de consultarlo con algunos amigos me animo a arriesgar:

Para que un desarrollador pueda ocupar el rol de facilitador en su equipo es necesario que tenga un buen dominio de las cuestiones técnicas con las que debe trabajar cotidianamente.

(posiblemente esta afirmación no tenga aplicación universal, pero definitivamente aplica a mi)

El cambio tecnológico más duro de mi carrera

No fue en 2002 cuando pase de hacer sitios web en Php a trabajar con la incipiente (en aquel momento) tecnología .Net.

No fue cuando en 2005 cuando tuve que programar un web server con C++.

No fue en 2009 cuando hice mis primeras experiencias en plataformas Cloud. Ni tampoco cuando pasé de Subversion a Git.

No fue cuando en 2010 cuando me metí con Ruby.

No fue cuando a fines del año pasado volví a trabajar con Php.

Fue en este último mes y medio cuando pasé de trabajar en Ruby a trabajar en Java.

Venía acostumbrado a trabajar desde la terminal con rake, usando Sublime como herramienta de edición de código e Irb como espacio de experimentación. Sinceramente me sentía muy cómo

El pasaje al mundo Java me resultó durísimo. Si bien desde 2004 siempre he estado haciendo algunas cosillas en Java, la realidad es que eran cosas más bien pequeñas o bastante específicas. Pero ahora estoy trabajando en un proyecto de una complejidad bastante mayor en el cual se utilizan diversos frameworks y componentes de infraestructura.

Por un lado el lenguaje me resulta muy incómodo, tipado estático, chequeo de excepciones, ausencia de lambdas (Java7) y una pobre implementación de generics son algunas de las cuestiones que primero vienen a mi mente.

Por otro lado Java es posiblemente de las tecnologías más pesadas que he utilizado (si, incluso más pesado que C# con Visual Studio incluido). Mi maquina (4 GB de memoria y disco de estado sólido) sufre cada vez que intento correr las pruebas de integración o iniciar una sesión de depuración.

El Eclipse si bien es muy potente, es también muy pesado y encima el esquema de shortcuts que utiliza es totalmente distinto al de la mayoría de los otros IDEs.

En fin, aquí estoy, “curtiendome” con el todo el stack enterprise de Java e intentando aportar una mirada más amplia (y “no-java”) al equipo de proyecto.

 

 

Nuevo proyecto, full Java

Esta semana comencé a trabajar en un nuevo proyecto que va a requerir que me meta con Java en profundidad. El proyecto consiste en el desarrollo de lo que podríamos denominar un Middleware, básicamente una aplicación que permite integrar aplicaciones.

Equipo de 3 personas, iteraciones de 2 semanas, Jira, Slack, Git, Jenkins, Maven, Spring, Camel, Eclipse, JUnit, Mockito y algunas otras cosillas.

Continuará…

Primeros pasos con Cucumber-JVM

Hace poco más de dos meses estoy trabajando casi cotidianamente con Cucumber-JVM y como consecuencia de ello he aprendido muchísimo sobre dicha herramienta. Si bien ya tenía bastante experiencia con la implementación Cucumber-Ruby, resulta que la implementación Java tiene sus particularidades.

Para compartir lo que he ido aprendiendo he decidido grabar una serie de videos. He aquí el primero de ellos: Introducción a Cucumber-JVM, espero les resulte útil.

 

La explicación del porqué estoy codeando un Applet

¿Acaso pensabas que con HTML5 y el ascenso de Javascript podrías deshacerte de los applets y los ActiveX? Pues aún no es posible. Aunque cueste creerlo hay ciertas cuestiones que aún hoy se encuentran fuera del alcance de HTML5 y JavaScript. Les cuento el caso de un proyecto en el que estoy trabajando y para el cual tuve que desarrollar un applet.

Resulta que un sistema en el que estoy trabajando es una aplicación web en la que algunos usuarios deben cargar información sensible. Por esto se ha definido que cuando un usuario cargue esta información sensible, la mista deberá ser firmada. Para esto cada usuario cuenta con un token. Cuando digo token me refiero a un dispositivo físico que almacena certificados y que permite que los mismo sean utilizados para distintas cuestiones. Físicamente estos tokens son como llaves USB. Por razones de seguridad, no es posible acceder directamente a los certificados del token, sino que el acceso debe hacerse mediante un driver particular que provee el fabricante del token. Entonces nos encontramos con una página web cuya información debe ser firmada y para generar la firma resulta necesario interactuar con el driver del token. Hoy en día aún no es posible hacer esto (interactuar con un token) con HTML5/JavaScript desde un browser y la solución que nos resultó más razonable fue usar un applet. Puede que el applet parezca algo feo, pero sin duda es mucho mejor que usar componente ActiveX que sólo correría en Windows.

En próximos post compartiré algunas cuestiones que he ido aprendiendo durante la construcción de este applet.

New open source project

Yesterday I started a new open source project. It is a framework for developing video games with Java, using the MVC design pattern. My intention with this project is to help Algo3 students to develop their applications concentrating in the Model while the framework takes care of most of the complexities of the View and Controller. The name of the project is Titiritero and it is hosted in Google Code at this location: http://code.google.com/p/titiritero/