Nuevo Eclipse Ganymede - Primer experimento

Si, tal muestra la imágen, salí bastante decepcionado. Pero no es culpa de eclipse, sino de uno de los proyectos de eclipse, el Visual Editor.

Siempre me ha parecido bastante complicado instalar plugins en eclipse, desde hace ya varias versiones. Por un lado, el Update Manager me ha parecido muy lento, por esa razón, la mayoría de las veces, directamente bajo los paquetes necesarios , los descomprimo y (después de cruzar los dedos) voilá! todo anda a la perfección.

Bien, con la nueva versión de eclipse, una de las nueva features es la actualización del Update Manager, por eso decidí tratar de agregar a la versión J2EE, el Visual Editor para poder realizar los 2 tipos de aplicaciones, de escritorio y web. Por suerte, fui registrando todos los pasos en imágenes.

En la siguiente imagen, se puede ver la nueva interfaz del Update Manager, ha cambiado bastante con respecto a las anteriores


Bien, si vamos a "Available Software", aparece el primer disgusto. En realidad no es nada del otro mundo, pero sucede que pensando en que ya estaba listado el alguno de los update sites el visual editor, traté de buscarlo, dando como resultado una eterna espera por cada letra (si, por cada letra) que añadía al listado. Esto sucede porque este nuevo Update Manager no espera a tener una palabra completa para buscar, entonces, la búsqueda hacia los distintos servidores, tarda un tiempo.


Una vez aprendida la lección y agregado a mano el update site de Visual Editor, procedí muy ilusionado a agregarlo a mi lista de instalación:


Luego acepté los contratos de licencia y pulsé el botón de "Install" directamente y pensé "Esto va a tardar un buen rato....". Pero aquí aparece la primera ventaja: Fue bastante rápido en realidad. Si bien me van a decir que no sólo depende del nuevo software sino de muchas cosas más relacionadas con redes, debo decir que el emule estaba bajando a full y sin embargo, el resultado fue en menos de 40 segundos.


Por supuesto, se tiene que reiniciar todo el entorno para que los cambios surtan efecto (Punto en contra para eclipse, no puede ser que todavía sigamos reiniciando el entorno).
Bien, en este punto ya estaba bastante ilusionado, después de reiniciar el entorno, volví a ver la lista de software instalado y ahí estaba, mi nuevo Visual Editor instalado, de lujo!! pensé.
Pero quedaba probarlo, para ello, simplemente creé un nuevo proyecto de Java, e intenté crear una nueva "Visual Class", el resultado fue el siguiente:


Pero no fue por unos segundos, directamente NUNCA APARECIÓ el lienzo para armar el formulario!! (Feo feo, muy feo).
Les juro que intenté de todo, desinstalarlo, bajarlo como paquete aparte y reinstalarlo a mano, instalar todas la dependencias a mano, borrar todo el eclipse y reinstalar todos los paquetes dentro del Visual Editor, rezar, insultar, negación y por último, frustración, por lo que decidí probar la siguiente opción, para no volver en un tiempo


Bueno, ese fue mi primer encuentro con eclipse Ganymede. Pero también tiene nuevas actualizaciones que están muy buenas, especialmente en cuando al editor de código. Pero esto será para una próxima oportunidad, cuando se me pase la frustración de la primera batalla.

Saludos

Testeando performance con eclipse TPTP

Llega el momento en la vida en que nos preguntamos ¿Qué tan malo es el código que escribo?. Bien, la respuesta puede estar dada por muchos factores, el primero de ellos sería simplemente "Eres bastante malo, ni siquiera compila..."

Ya he presentado algunas herramientas que nos ayudaban a tener buenas prácticas a la hora de programar, com por ejemplo PMD. Pero lo que no se mide no se puede mejorar, decía un profesor mío (todavía me falta rendir esa materia, la última). Entonces, para poder medir un poco la performance de nuestras aplicaciones Java estuve probando TPTP (Test and Performance Tools Platform). Es un proyecto de eclipse, bastante estable y con muy buenas pantallas finales.

En cuanto a la instalación, es bastante fácil, lo único que tenemos que hacer es simplemente usar el UpdateManager de eclipse usando el servidor de "Europa update site".

Y para probarlo he usado el último ejemplo que he dado en clase. Básicamente se trata de un problema Productor-Consumidor que crea 50 hilos Productores (clase Alumno) y un sólo consumidor (clase Docente) y que usa además, comunicación por Sockets.
Lo importante en este tipo de problemas, además de sincronización, es que cada hilo, tanto productor como consumidor debe finalizar su ejecución y nunca quedar en estado wait. Entonces utilicé esta herramienta para comprobarlo. A continuación, pueden ver una imagen de los resultados que arrojó:

En la imagen se pueden ver los resultados de cada hilo de ejecución, su estado, su tiempo de actividad y su tiempo de espera (es decir, el tiempo en el que se mantiene como wait) y tiempo de bloqueo. El que más me importa es el "status", en este momento me dice que todos mis hilos (clases Alumno y Docente) están en estado "Stopped", como deberían estar al finalizar el programa. En el siguiente gráfico se puede apreciar el estado incorrecto. Se trata de un trabajo práctico de uno de mis alumnos. Es un problema Productor-Consumidor donde los consumidores (clase modelo.Cliente) quedan al finalizar el programa en estado wait eterno (evidentemente, no le puse 10...).

Esta herramienta permite medir, además del comportamiento de hilos, los tiempos de ejecución de cada clase, con la capacidad de hacer drill-down hasta llegar al nivel de detalle de ejeción de métodos, con tiempos y cantidad de llamadas que realiza.

Una potente herramienta para mejorar la performance de nuestra aplicación y para mejorar nuestro código.

Saludos

"Un bean es un poroto..." - Java Educators en JavaOne

Gracias a TheServerSide.com, llegó a mi un podcast de la JavaOne muy interesante. Está titulado "What is next for Java educators?". Más allá de ser un simple ayudante de cátedra y dar cursos de java, me interesa mucho la educación tecnológica tanto a nivel universitario como el acceso a la educación tecnológica en otros niveles. Desde hace tiempo sabemos que los graduados en carreras de ingeniería están siendo un bien escazo en todo el mundo. Pero el problema todavía va a ser más grave, ya que se está dejando de lado y no se está discutiendo lo suficiente acerca de cómo se instruye a los pocos ingenieros que se reciben.

"This folks are not really prepared..." es una de la cuestiones que se plantea en el podcast. Esto me llama la atención ya que aquí, en esta pequeña ciudad perdida al final de América Latina, también se discute lo mismo. Ahora bien. dependiendo de la empresa que diga esta frase, esto puede traducirse como "Estos chicos no saben ni Hibernate ni Struts" o "Estos chicos no saben resolver problemas". Francamente, prefiero trabajar en el tipo de empresa donde se valora más la capacidad de autoaprendizaje que el conocimiento de un lenguaje en particular.

¿Cómo hacemos que nuestros estudiantes estén mejor preparados? ¿Deberíamos enseñar java en todas las universidades, desde primero hasta el último año?. Y para que no se enoje Bill, ¿Enseñar Visual Basic y .NET en los últimos años de la carrera?. Aunque parezcan graciosas estas últimas preguntas, te aseguro que se están aplicando programas de cátedras de programación similares. Creo que la pregunta esencial sería ¿Queremos formar expertos en ciertas tecnologías o expertos en resolver problemas?
Yo creo que sería más productivo la segunda opción, ya que un experto en solucionar problemas tranquilamente puede aprender lenguajes de programación y nuevas tecnologías de una manera más fácil. Y más aún, algo maravilloso, es que puede desarrollar nuevas tecnologías.

Además, ¿Hasta cuando va a existir Java y .NET?. En cualquier momento sale Java++ ó .Java. Hay que admitirlo. Antes se enseñaba Logo, después Cobol, después C, después C++, QBasic y un montón de lenguajes más. Hoy, todo se enfoca a los nuevos lenguajes que crean lenguajes, o DSL, código para generar código.

Las conclusiones, se las dejo a Uds.

Saludos