miércoles 8 de julio de 2009

Nuevo Rubik 360


Después de un tiempo de ausencia debido a cuestiones académicas sólo paso a dejarles una noticia que tal vez no entone con la temática del blog pero está relacionada con la creatividad humana.

Esta vez los dejo con el nuevo Rubik 360, y cito de la nota de Sputnik (http://www.sputnik.com.mx/):



El Rubik 360 (o sencillamente R360) es el nuevo acertijo creado por Erno Rubik, retraído y brillante profesor húngaro, quien ha cosechado más de 350 millones de ventas de su fantástico cubo de colores desde 1980 1.


Y un video de este juego en http://www.youtube.com/watch?v=LOiLh_1qKxg.

¿Ustedes, qué opinan al respecto?


1 Texto completo de la cita tomado de: http://www.sputnik.com.mx//index.php?option=com_content&task=view&id=4427&Itemid=1

miércoles 29 de abril de 2009

¡Y esto de la influenza ya me está cansando!


Bueno, no me quedaré sin publicar algo al respecto sobre esto de la Influenza porcina...

Y si todas las teorías sobre conspiraciones y/o complots del gobierno para mantenernos (a la sociedad) en un estado de shock, bajo su dominio, para mantener una cortina gris detrás de la cual se están suscitando cosas (como p. ej la ley de portación mínima de drogas, aprobada por el senado -http://www.el-universal.com.mx/notas/345730.html-) que ni siquiera estamos enterados ya que lo que más suena es la Influenza porcina, entonces, no es quizás el momento perfecto para levantarnos, y poner un fin al poderio y dominio del cual tanto se habla que los gobiernos mantienen sobre nosotros, las sociedades...

Si tan cierto es que la OMS está controlada y dirigida por el gobierno de los EU, entonces, porqué no empezar a desaparecer el pánico, el miedo y con nuestras actitudes demostrar que NO SOMOS la misma sociedad del pasado (siempre bajo el mandato de los gobiernos -en nuestro caso particular del gobierno de nuestro país, de México-). ¿Por qué no la población retira todos los cubrebocas y/o tapabocas, si tan falsa es la gravedad de la influenza? De ésta manera demostraremos una especie de rebelión, de inconformidad con lo que los medios de comunicación también expresan, si tantos correos, blogs, foros, etc., etc. existen hablando sobre esta farsa de la influenza porcina...

Digo, si todo esto es una mentira yo seguiría con mi vida normal, y en mi vida normal no utilizo cubrebocas, en mi vida normal acudo a mis clases, a mi trabajo, a mi restaurante favorito, y claro, también en mi restaurante favorito me atienden como siempre: puedo sentarme a comer y disfrutar de su comodidad y no soy tratado como si se trátase del fin del mundo, donde sólo salgo, hago lo necesario (comprar comida en este caso) y regreso rápido a casa.

Insisto, he leído un vasto número de correos, blogs, foros, etc., etc. tratando este tema, sin embargo mi conclusión al no ver algo reflejado en hechos sigue siendo la misma: SEGUIMOS SIENDO LA MISMA SOCIEDAD DE SIEMPRE; SIEMPRE BLA, BLA, BLA, SIEMPRE QUEJáNDONOS SIN HACER NADA AL RESPECTO...

¡Qué pena me das México, qué pena!

sábado 14 de marzo de 2009

Desafío A La Mente (Mindstorms En Español)

Hola a todos, y disculpen la ausencia, he estado atendiendo unos asuntos académicos-personales. Bueno, a lo que voy: buscando información sobre Consecuencias lógicas me encontré con un artículo titulado Desafío A La Mente (Mindstorms En Español) y conforme iba leyendo algo me llamó la atención:

alguna vez se han preguntado ¿porqué la disposición QWERTY de las teclas de una máquina de escribir y/o computadora?

La razón es la siguiente:

"...La disposición QWERTY no tiene ninguna explicación racional, sólo histórica. Fue introducida en respuesta a un problema de la primera época de la móquina de escribir: las teclas solían atascarse. La idea fue minimizar el problema de colisión separando aquellas teclas que aparecían frecuentemente en secuencia inmediata. Apenas unos años después, el mejoramiento general de la tecnología eliminó el problema de atascamiento, pero QWERTY subsistió... Estamos en proceso de atrincherarnos en un anacronismo, preservando prácticas que no tienen ninguna base racional más allá de sus raíces históricas en un período anterior del desarrollo tecnológico y teórico..."

Es una traducción al español (que hace una persona de Argentina) de Computadoras y Educación de Seymour Papert, Ediciones Galápagos. Quinta Edición, 1987.

domingo 30 de noviembre de 2008

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...

jueves 21 de agosto de 2008

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.

jueves 14 de agosto de 2008

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...


domingo 22 de junio de 2008

Concluido el primer prototipo de eZine: Aplicación Web dinámica con JSF (JavaServer Faces)


Hola a todos de nuevo. He estado algo ausente por aquí últimamente dado que estoy afinando detalles sobre mi tesis de Licenciatura (Sistemas Computacionales), la cual trata sobre el "Desarrollo de aplicaciones Web dinámicas usando el framework JavaServer Faces (JSF) basado en la plataforma J2EE". El caso práctico de desarrollo es una revista electrónica. . .

Aunque los avances en desarrollo representan aún el 50%, este primer prototipo me ha brindado la oportunidad de trabajar con JSF, efectuar pruebas, en fin, evaluar en términos generales el desempeño y sobre todo la facilidad (de la cual se habla mucho) para el desarrollo de aplicaciones Web dinámicas. Comparto con uds. mis conclusiones:



Al cumplir con mi objetivo general, demuestro, por uso personal que el framework JSF cubre satisfactoriamente sus principales objetivos y cumple con las características, bondades y ventajas que ofrece, particularmente, sobre la renderización de componentes que es la problemática principal que da origen a esta tesis. Para atender los problemas de renderización y re-utilización de componentes, he probado al menos tres librerías de componentes y las cuales son completamente compatibles con la implementación 1.1 de JSF.

Las librerías que he empleado para la renderización de los componentes son las siguientes:
• MyFaces Tomahawk 1.1.7
• MyFaces Sandbox 1.1.7
• MyFaces Trinidad 1.0.7

Las tres librerías listadas anteriormente pertenecen al grupo Apache. Tomahawk y Sandbox se comportan eficientemente aunque, el renderizado parcial de página (PPR por sus siglas en inglés, Partial Page Rendering) no lo considero estable y los resultados no son los esperados, lo que impide y/o dificulta el uso de tecnología AJAX sobre la aplicación.

Por su parte, la librería Trinidad 1.0.7, también de Apache, ofrece un comportamiento más estable y permite usar tecnología AJAX de manera más fácil y obteniendo siempre los mismos resultados, esto, a coste de una configuración de la aplicación (en el archivo faces-config.xml y en el descriptor de despliegue de la aplicación) completamente distinta y en general, más compleja que la requerida por Tomahawk y/o Sandbox.

Existen numerosas librerías de componentes para JSF, ya sean libres (entre las cuales puedo mencionar: JSF-Comp de Apache , Java BluePrints AJAX Components , Jenia , entre otros) o comerciales (WebGalileo Faces Components , NetAdvantage for JSF 2008 , Simplica’s Ecruiser , por mencionar algunos) y muchas de ellas pueden ser usadas en conjunto para ofrecerle al desarrollador Web una mayor flexibilidad y un desarrollo rápido de aplicaciones.

He optado por emplear las librerías de componentes Tomahawk 1.1.7 y Sandbox 1.1.7 del grupo Apache debido a su facilidad de uso y configuración así como de mayor disponibilidad de sitios de ayuda, foros y documentación en comparación con algunas otras librerías de componentes para JSF. Además, que en el desarrollo de los componentes se encuentran involucrados los socios de Apache, como lo es Sun, Google, Oracle, IBM y otros, por lo que la calidad y reputación de los mismos es indudable.

JSF no sólo cumple satisfactoriamente los requisitos de renderización y re-utilización de componentes, si no que, además, se ajusta perfectamente al patrón MVC para el desarrollo de aplicaciones, permitiendo así una separación entre las capas de datos, la capa lógica y capa de presentación, lo que, en conjunto con el uso de librerías de componentes permite un desarrollo rápido de aplicaciones.

El concepto de reglas de navegación (navigation rules) y beans administrados (manager beans) definidos en XML sin lugar a dudas ofrece una mejor administración y configuración de la navegación dentro de la aplicación Web.

Un alcance extra, logrado durante el desarrollo del primer prototipo de la revista electrónica es la opción de internacionalización. La internacionalización permite mostrar la aplicación según el idioma del usuario, más específicamente, en el idioma configurado de su navegador Web, además de permitir cambiar, en tiempo de ejecución entre un idioma y otro (en el caso del prototipo desarrollado, cambiar entre español e inglés).

Indudablemente (desde mi perspectiva) JSF ha revolucionado la forma de desarrollar aplicaciones para la Web, y aunque numerosos críticos quienes digan que Struts tiene una mayor madurez, es destacable considerar que JSF apenas va en su versión 1.2 y ya a estos niveles ofrece un gran potencial.

Prueba de la rápida evolución de este framework es que, hasta hace un par de años, cuando aún estaba surgiendo a la luz, no existía algún un IDE que diera soporte (ya sea de manera nativa o por medio de plug-ins) al desarrollo de aplicaciones con JSF, situación que hoy en día es todo lo contrario puesto que existen numerosos entornos de desarrollo con soporte para JSF, entre los cuales se encuentran: Eclipse, NetBeans, Exadel Studio Pro, Oracle JDeveloper.

El lector se preguntará: ¿y cuál es el mayor desafío en el uso de JSF para desarrollar aplicaciones Web dinámicas? Como todas las herramientas y lenguajes de programación el mayor desafío es, indudablemente la curva de aprendizaje requerida. JSF requiere el conocimiento, entendimiento y empleo del patrón MVC para desarrollar aplicaciones, si el programador Web no tiene experiencia con el modelo MVC, éste será su primer gran obstáculo.

También, como muchas otras cosas en el mundo de desarrollo de aplicaciones, la configuración del entorno (servidor de aplicaciones y configuración de archivos XML, en el caso de JSF, faces-config y el descriptor de despliegue) es uno más de los “problemas” que el programador Web debe de resolver...



Bueno, por el momento es todo, actualmente estoy trabajando con la segunda versión de la aplicación, en la cual buscaré emplear una librería de componentes estable y de fácil configuración para trabajar AJAX bajo JSF. La segunda versión también incluirá pruebas unitarias. Espero tener la segunda versión en un mes o menos.

Espero sus comentarios al respecto, muchas gracias.