La última guerra de lenguajes/El último post sobre historia de lenguajes que necesitará leer (eso esperamos)

Un poco de diversión, humor negro... Un interesante debate que encontré en el blog de David Rupp.

Se títula La Última guerra de lenguajes/El último post sobre historia de lenguajes que necesitará leer (eso esperamos) y lo traduzco (lo más fiel posible) al español a continuación...

La Última guerra de lenguajes/El último post sobre historia de lenguajes que necesitará leer (eso esperamos)

Moderador: Hola, y bienvenidos al Primer-Y-Posiblemente-Última-Conferencia-De-Lenguajes-De-Programación (PPUCLP). Me encuentro reunido esta noche junto a distinguidos y de muy buen perfil, lenguajes de programación. Cada uno es altamente recomendado por sus seguidores, y ahora es turno de escuchar lo que cada uno de ellos tiene por decir.

Ruby (agarrando el micrófono): M y sí lo hicé! Me gustaría sacar a este individuo diciéndoles a TODOS USTEDES QUE SON MI****!!! Sí, lo dije! La letra M! Oh sí! Boom, nena! Woo! Ruby FTW!

Java (girando los ojos): Oh sí, realmente maduro. Yo, por otro lado, me gustaría decir que tengo importantes trabajos empresariales hechos, y no les haré perder su tiempo a todos uds. Les sugiero que procedamos con la conferencia de Patrones de Desarrollo para Lenguajes de Programación como se indica en JSR-6942, y del cual se habló en la conferencia Hablemos Sobre Acrónimos del Lenguaje Java (JAVATALK, el cual por cierto, no es un acrónimo para cualquier cosa).

Ruby: Chico! He escrito todo un clon completo de Google mientras tú dabas tú rebuscado discurso!

Moderador: Oh, bravo, Ruby! Me encantaría ver ese trabajo. Dónde está desplegado?

Ruby: Umm....

Lisp: En el principio, existió el Lambda. Y John McCarthy vió el Lambda. Y entonces, John McCarthy dijo que el Lambda era bueno.

Ruby (girando sus ojos): Aquí vamos...

Lisp: Y John McCarthy dijo! Su lengua habló sobre sex...

Ruby: Dijo sexo! Heeheeheeheehee!

Erlang: Si me permiten, he estado procesando algunas ideas de los panelistas, todas al mismo tiempo claro, no es que sea la gran cosa...

Ruby (girando sus ojos): Y aquí vamos con la concurrencia...

Java: Gosh darn it, Ruby! No hay necesidad de echar pooh-pooh cada vez que alguien dice algo, no crees?

Ruby: Él dijo poo-poo! Heeheeheeheehee!

Java: Ruby, Lo juro, uno de éstos días...

Ruby: Hey, no me des uno de tus estáticos! Heeheeheeheehee! Viste, lo hice de nuevo! "Static"?! Porque soy tan dinámico?! Tómala!!! Demonios, dónde están mis BAWLS Guarana...?

Ruby (segundos después): Dije bolas! Heeheeheeheehee!

C#: Desarrolladores! Desarrolladores! Desarrolladores! Desarrolladores!

Erlang: ...Compartiré mis resultados con ustedes, pero se tomará un tiempo mientras los obtengo de mi sistema de arhivos...

COBOL: (se mantiene de rodillas, sólo por ser revivido frenéticamente por apróximadamente tres bancos)

Basic: De hecho, tengo una pregunta para Ruby...

Haskell: También yo...

ML: Hey, Ruby, cuál es tu respuesta a...

Ruby: Hey, hey, hey! No tantos en [segfault]

Java: sonrisas

bash: kill -9 self

El cálculo Lambda: Podríamos todos tomarnos un momento para reflexionar sobre las implicaciones de la tesis Church-Turing...

Todos los demás: Oh, CALLATE!!!!!!

Scala: (no dice nada, pero se sienta en silencio, observando, tomando notas y aprendiendo mucho).

Moderador: Bueno, creo que es tiempo de concluir este, um, animado... debate...

Java (bruscamente): Hey! Estamos en eso!

Lisp: ))))))))))))))))))))))

Jejeje! Espero sus comentarios y/o correcciones a la traducción...

Pruebas unitarias para aplicaciones JSF (primera parte)...

Finalmente he concluido el conjunto de pruebas unitarias realizadas a la aplicación Web que estoy desarrollando como proyecto de tesis. Por tanto, a continuación brindo un fragmento de las conclusiones obtenidas respecto a las pruebas unitarias.

. . . Si su aplicación Java es una aplicación de escritorio (standalone) el framework JUnit es suficiente para ejecutar pruebas unitarias a su aplicación. Ahora bien, si su aplicación Java correrá en un entorno Web (Servlets, JSP, JSF, etc.) usted seguramente necesitará un framework que extienda las capacidades de JUnit. Algunos de estos frameworks para pruebas unitarias de aplicaciones Web son: HTTPUnit, HTMLUnit, Seleniuum, JWebUnit y Cactus.

Finalmente, el conjunto de frameworks con los que he tratado para ejecutar pruebas unitarias a la aplicación fueron los siguientes: HTTPUnit, HTMLUnit y JWebUnit, sin obtener los resultados esperados ya que éstos únicamente sirven para pruebas en páginas estáticas HTML y lo que se busca probar son páginas JSF.

Por ello, traté seguidamente con Seleniuum el cual en primera instancia parece también no soportar aplicaciones JSF o basadas en Java y cuya configuración es compleja y excede los tiempos con los que se cuenta para concluir el proyecto de tesis.

Fue luego de varios días de búsqueda y lectura que encontré información sobre el framework Cactus.

Cactus es un framework para la realización de pruebas unitarias de aplicaciones Web, y dispone de elementos parar realizar pruebas unitarias sobre Servlets y páginas JSP. Diseñado para probar aplicaciones que siguen el patrón de arquitectura MVC. Soporta como controladores Servlets, clases Java, taglibs, filters.

Aunque Cactus por naturaleza propia no testea aplicaciones JSF, por su parte, JSFUnit sí soporta pruebas unitarias para aplicaciones JSF, ya que extiende las capacidades de Cactus.

Con los argumentos detallados anteriormente, por experiencia personal recomiendo utilizar el siguiente escenario/configuración si desea llevar a cabo pruebas unitarias en una aplicación JSF:

1. 
   Emplear el framework JSFUnit (el cual está basado en Cactus) realizando dichas pruebas desde el exterior del contenedor, donde, del lado del cliente se emplea una técnica habitual que consiste en implementar el protocolo HTTP en un cliente de pruebas unitarias que simula la interacción entre un usuario y el servidor Web.
   


2. 
   Asegúrese de probar al menos la correcta navegabilidad de la aplicación, la correcta instanciación/creación de objetos y/o managed beans y finalmente, la integridad y consistencia de dichos beans administrados.
   


3. 
   Si desea obtener un mejor seguimiento de los resultados de las pruebas le recomiendo utilizar un entorno de desarrollo integrado (IDE) con soporte para Java, en este renglón recomiendo el IDE Eclipse para depurar sus pruebas y así obtener los valores y posibles errores en tiempo de ejecución de su aplicación y/o pruebas unitarias.
   

Prueba gratuita de exámen de certificación de seguridad en Java/J2EE...

Hace un tiempo encontré en el portal de SANS una prueba gratuita de un exámen de certificación en seguridad de Java/J2EE...

La prueba consta de diez preguntas (en inglés, esto podría ser el aspecto negativo para algunos) y al ir respondiendo cada una de las preguntas puede ver si su respuesta fue la correcta o no, además de que le ofrece la respuesta correcta.

Obviamente, he realizado la prueba y mis resultados no fueron óptimos (40%, es decir, 4 buenas, 6 malas). No obstante, estoy satisfecho con el rendimiento dado que NUNCA he llevado un buen curso de Java y lo que he aprendido de dicho lenguaje ha sido a base de sacrificio propio, sin nadie que me enseñe. Aún llevo dos años en el mundo Java, espero regresar dentro de dos años más y medirme nuevamente, por lo pronto les dejo el enlace a la prueba: https://portal.sans.org/ssi/java.php

Por lo pronto les dejo la imagen que avala mi calificación : ( y espero sus resultados...