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

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.

Videos del concurso de robótica en Querétaro, México

Bueno, he aquí los videos del 13vo Concurso Nacional de Minirobótica que se llevó a cabo en la ciudad de Santiago de Querétaro, Querétaro, México, del cual tuve el gran gusto de participar. ¡Gracias!

¡Y Olmequita lo lograba!


Claro, después de varios intentos, muchos cabezazos contra la pared (figuradamente eh, estuvo estresante e interesante)...


Y Choquito también estaba en batalla (Choquito: ¡4o lugar de 39 equipos!; aún en la espera de que los organizadores publiquen los resultados en el sitio del concurso)


Olmequita a la hora del concurso (el buen Germán a cargo de Olmequita)...


Algunos otros equipos...

¡Felicidades generación 2003-2008 LSC-UJAT-DAIS!

Bueno señores, después de cinco largos años, nosotros, los estudiantes de la Licenciatura en Sistemas Computacionales, de la Universidad Juárez Autónoma de Tabasco pasaremos a ser Licenciados. Felicidades a todos los compañeros, ¡en hora buena!

Próxima la gran recompensa a nuestro sacrificio, a nuestros estirones y jalones, navegando a través de un inmenso mar de problemas personales, familiares, a numerosas situaciones de gran entrega y lucha ante nuestros profesores... Me permití publicar esto y aunque muchos piensan o digan que está fuera de los objetivos del blog la situación no es así, después de todo es una carrera afín a las TI, y es lo menos que puedo hacer por uds. mis queridos compañeros, amigos...

La cuenta regresiva ha comenzado... Ha sido todo un placer convivir con uds., y aunque no hayamos compartido tanto tiempo de lo que sí estoy seguro es que mejores compañeros, mejores amigos que uds., en la carrera no pude haber conocido...

Gracias por todo y les deseo a TODOS una muy buen inicio de una nueva etapa en nuestras vidas, que Dios los bendiga a uds., a su familia, amigos y seres queridos quienes compartieron con uds. estos cinco largos años... Sin lágrimas por favor...

Los dejo con unas imágenes que reflejan el ardúo trabajo en la carrera, y los invito a que dejen sus comentario y que anexen sus imágenes que reflejen ese trabajo, si alguna vez se tomaron foto o video trabajando, adelante (Gabriel, está chida esa foto donde: "Para los que trabajan" y el disco duro refrescándose : D, ahí súbela x aquí, no?).






Gracias.

¿Nos vamos al JavaCup 2008?

Navegando por la Web me encontré un evento muy interesante: El JavaCup 2008. JavaCup consiste en un torneo de futbol programado con el lenguaje Java. Y cito:

"La revista Sólo Programadores, la organización sin ánimo de lucro javaHispano y Sun Microsystems hemos organizado un concurso que consiste en un torneo virtual de fútbol donde cada equipo será una clase Java que implementa una interfaz predefinida."...

"Cada participante deberá implementar un equipo virtual de fútbol. Para ello se apoyará en un software que se distribuye bajo licencia GPL y que puede obtenerse en el CD que acompaña a la revista SoloProgramadores del mes de mayo, en la página web del concurso o en el proyecto JavaCup de javaHispano.net. El software puede considerarse un framework que cuenta con puntos de extensión (que en este caso permiten crear un equipo de fútbol) y ofrece una API en la cual pueden apoyarse los equipos para construir sus tácticas de juego. Para facilitar su uso, el software se distribuye como un proyecto de Netbeans que, una vez descargado y descomprimido, está listo para ser abierto y ejecutado desde este entorno de desarrollo. No obstante, si el participante prefiere emplear otro entorno, es posible importar el código fuente en cualquier IDE."

http://javacup.javahispano.org/app/bases.html

En verdad que el concurso está muy interesante y he corrido algunas pruebas desde el IDE Eclipse y "echar a andar" las tácticas no de juego no es tan complicado, lo que implica un gran despliegue y cálculos matemáticos (principalmente trigonometría) es cómo implementar cada una de las tácticas, por ejemplo: cómo robar el balón, ¿eligiendo al jugador más cerca de la pelota?, ¿a quién pasar luego el balón? Usando qué...



Les hago una invitación abierta a todos aquellos quienes deseen participar en el concurso, y si quieren, pueden ponerse en contacto conmigo a: edario_ram@hotmail.com para cualquier comentario, duda y/o sugerencia. La invitación es principalmente a los compañeros de la División Académica de Informática y Sistemas de la Universidad Juárez Autónoma de Tabasco (DAIS-UJAT), en el estado de Tabasco, México.

Les invito pues a inscribirse al concurso representando una vez más al estado de Tabasco! Y a la UJAT! Pueden encontrar TODA la información en:


JavaCup 2008

Fotos del concurso de robótica en Querétaro, México

Pues aquí les dejo unas fotitos del dream-team de Robótica de la UJAT :D Quienes fuímos al 13o Concurso de Minirobótica en la Cd. de Santiago de Querétaro.... Próximamente publicaré los videos, no desesperen...

Resultados, comentarios y conclusiones del 13o Concurso Nacional de Minirobótica

Hola a todos, después de un breve tiempo de ausencia regreso con los resultados del 13o Concurso Nacional de Minirobótica que se llevó a cabo en la ciudad de Santiago de Querétaro los días 1 y 2 de Mayo del presente. Para ello divido el presente en 3 secciones: Cómo nos fue, Cómo estuvo todo, Cómo estuvieron los demás y mis conclusiones. La categoría en la que participamos fue Categoría Lego educacional abierta, específicamente en la "subcategoría" Robot transportador de Lego.

Además, es importante que toda aquella persona o institución que lea esto no se sienta ofendidad ni nada por el estilo, son más bien críticas constructivas que persiguen el puro objetivo de mejorar nuestro nivel académico, mejorar el funcionamiento de algunas instituciones en cuanto a tramités "burocráticos" y cuestiones de este estilo. Bueno, sin más preámbulos, iniciamos...

¿Cómo nos fue?

Bastante bien :D considerando que fue nuestro primer concurso de este tipo. En concreto, Roberto, Germán y yo hemos de haber quedado entre 10o y 15vo lugar :( .... de 39 equipos! Lamentablemente no pasamos a las finales, sólo los mejores 8 primeros lugares... Pero aquí viene lo bueno... Francisco y Santiago quedaron en 4o lugar!!! Y pasaron a las finales!!! :D Ya en las finales aunque lograron avanzar más lejos con la caja al parecer quedaron en el mismo 4o lugar, cuando muy bajo en quinto lugar. Nos comentaron que los resultados serían publicados en la página pero que únicamente habían considerado publicar los tres primeros lugares, la doctora María del Pilar Pozos Parra (quien fue nuestra asesora) les pidió de favor a los jueces que hablaran con los organizadores y que al menos consideraran publicar los mejores 8 equipos esto para demostrar que en verdad hubo un equipo de nosotros que quedó entre los primeros 8 mejores de 39!!! Además, de seguro que la UJAT (nuestra universidad, la Universidad Juárez Autónoma de Tabasco) preguntará cómo nos fue y así platicadito quién sabe si alguien nos crea!! :D

¿Cómo estuvo todo?

Personalmente y como en muchos concursos hubieron cosas que no me agradaron y no porque no hayamos ganado... Creo que aún no hemos aprendido que las reglas se hicieron para romperse o al menos a "doblarlas" para así obtener la flexibilidad deseada (o al menos es lo que muchos ya entendieron y así lo hacen!). A la mera hora habían escenarios que eran 3 cm. más largos o más anchos, hubo un equipo que participó con su propio escenario (y que por cierto quedaron en 2o lugar!). Héctor Ortiz-Parada (también integrante de uno de los 2 equipos que concursamos) compartió con nosotros la idea de chocar con las paredes para "enderezar" el robot? Resulta que cuando empezamos a hacer pruebas todos los equipos, NINGUNO más que nosotros utilizaba esa técnica. Habían algunos que chocaban pero por error y no porque fuese su intención. Sin embargo, como a los 15 min. en eso que estamos haciendo fila y esperando nuestro turno para hacer nuestras pruebas, empezamos a ver que ya muchos equipos hacían lo que nosotros hacíamos, pues ya habían visto nuestras pruebas!!!

¿Cómo estuvieron los demás?

Pues en la primera ronda (todos los equipos tuvimos 3 min., en estos 3 min. podíamos hacer cuanto reintentos pudiéramos si se chocaba nuestro robot o no se comportaba como quisiéramos) hasta por el equipo número 20 y la mayoría cuando mucho llegaba a donde nosotros llegabamos, es decir, estuvo bastante parejo. Algunos otros de plano fallaban muy gacho y no avanzaban mucho, se chocaba su robot antes del primer empuje a la caja, etc., etc. Sólo un equipo logró resolver el problema (de hecho, ese equipo fue el primer lugar; por cierto, implementaron unas llantitas laterales lo que le permitía al robot desplazarse bien aún cuando chocara con las paredes laterales, prácticamente lo que usted nos sugirió cuando le colocamos el "bigote" al robot, en fin, sin comentarios)...

Conclusiones

Para ser nuestro primer concurso de este tipo y contra todas las prisas y contratiempos, presiones, considerando que la Uni por poquito y no nos apoya, ya que un día antes es que aprueban el apoyo, considerando que fueron 2 días sin tocar cama! El día que llegamos a Puebla, a casa del Sr. Héctor, luego luego a seguir trabajando, nada de dormir, los taxis no nos querían levantar en Querétaro pues llevábamos la caja, ahí nos veían tirando nuestros abrigos encima del taxi para no rayarles el taxi al poner el escenario encima, en fin... El 90% de los equipos concursantes usaron el LEGO Mindstorms (un programa donde se programa el robot por diagrama de bloques o como se llame), tuve la oportunidad de platicar con un muchacho que ha de haber sido de los pocos que manejaron algún otro lenguaje, pues el uso Bricks-C o algo así me parece que se llama... Estoy seguro que fuímos los únicos en manejar Java ; ) .

EN ESENCIA: QUE UVM DE QUERETARO, QUE IPN, QUE VERACRUZANA NI QUE NADA!! DIMOS LATA!!! Con todo respeto para los compañeros estudiantes de esas universidades y no los estos menospreciando, es sólo que quiero que consideren que el sureste SI tiene calidad, sí damos batalla, la UJAT pelea hasta el final!! Y eso que sólo trabajamos como 2 semanas cuando mucho y trabajabamos sólo de 3 a 4 horas cuando mucho! Sin que comer, sin mucho dinero, sin todos esos "lujos y ventajas" que poseen estudiantes de universidades pagadas!! Nos medimos y estamos a la altura!!! Y ese es el mejor premio que pude haber recibido! Lástima que no llegó ningún equipo de la UNAM! :) O de alguna universidad extranjera!

Sobre nuestra situación académica como estudiantes de la ciencia informática

Quiero compartir con uds. mis conclusiones personales que he obtenido durante el desarrollo de un trabajo "extra-académico", del cual basta decir que ha servido para demostrar aquellos “huecos” y fortalezas en nuestra documentación y desarrollo de un software, esto como estudiantes de la ciencia informática.

Nuestro trabajo consistió en estudiar una serie de "postulados" y analizar si han sido puestos en práctica en alguno de nuestros desarrollos de software, y las conclusiones son las siguientes.

En la mayoría de las ocasiones (por dar una crifra, el 9 de cada 10 proyectos), existen aspectos que no son llevados a cabo debido principalmente al corto periodo de tiempo con el que se cuenta para el desarrollo de los proyectos (se habla de periodos semestrales, no obstante estos periodos "semestrales" más bien son de cuando mucho, cinco meses. Y señores, en cinco meses no se lleva a cabo un buen proyecto considerando muchos factores que muy bien muchos catedráticos y estudiantes conocemos muy bien -días "festivos", falta de disponibilidad cuando necesitamos orientación, cierto egoísmo para compartir ideas e información, etc., etc.).

Así mismo, otro factor importante en el progreso, y principalmente para la conclusión de un proyecto académico, son la orientación y experiencia del personal que imparten las distintas asignaturas que requieren el desarrollo de un software.

Al no existir un documento o una estructura estándar para el desarrollo y documentación de un proyecto de software, son muchas las posibilidades para documentar y desarrollar el mismo, por lo que, un maestro podría seguir un enfoque mientras que otro seguiría algún otro enfoque, lo que sin lugar a dudas resulta en documentación “incompleta” e “inexacta” y con un gran abanico de posibilidades, que, a la larga, termina por satisfaces a todos y a nadie a la vez. En esencia, al momento de evaluar enfoques dado lo que un estilo considera el otro no, y viceversa, es imposible satisfacer a todos con un solo enfoque.

En lo que respecta a la experiencia es otro factor relevante en el desarrollo y puesta en marcha de un proyecto de software. Ciertamente se puede poseer un gran conocimiento teórico en lo que se refiere a cómo documentar y desarrollar el proyecto, sin embargo, sin la experiencia que da el realmente poner en práctica esos conocimientos, éstos decrementan su importancia debido a que no hay nada mejor que probar las cosas, llevarlas a cabo en el mundo real y analizar, estudiar y evaluar esos conocimientos teóricos que poseemos y sobre todo, ver si realmente los resultados son los que, en teoría se espera.

Es por ello, que en muchos de nuestros proyectos de desarrollo de software, los resultados esperados no siempre han sido los mismos, ya que el éxito de un proyecto no depende solamente de los conocimientos que podamos adquirir y que nuestros maestros puedan compartir con nosotros, existen otros factores como la disponibilidad de tiempo del cliente, la preparación y cultura tecnólogica del cliente, entre otros, que definitivamente transforman el progreso del proyecto y obligan a hacer ajustes a esos conocimientos teóricos que poseemos, y que, como estudiantes impacta significativamente en nuestros tiempos, calidad y avance de nuestros proyectos.

Agradeceré sus comentarios al respecto... Críticas constructivas y que aporten elementos interesantes siempre serán bienvenidas.

Metodologías de desarrollo de software

Hola a todos de nuevo. Me he ausentado un periodo de tiempo debido a que estoy trabajando con el desarrollo de mi proyecto de tesis usando JSF (JavaServer Faces). En esta nueva entrada compartiré con ustedes algunos opiniones personales y algunas otras que son bastante compartidas en cuanto a las metodologías para el desarrollo de software.

En esta ocasión les platicaré un poco sobre la metodología XP (eXtremme Prograamming) pues igual en ella me apoyo para el desarrollo de mi proyecto. El interés se debe a que en pláticas con algunos compañeros existe la confusión si UML (Unified Modeling Language; Lenguaje Unificado de Modelado) es una metodología, y antes de empezar a platicarles un poco sobre XP me gustaría aclarar un poco esto en base a lecturas previas y razonamiento sobre qué es UML y qué se puede hacer con él.

En esencia, UML NO ES UNA METODOLOGIA, como su nombre lo indica, es un lenguaje para modelar las especificaciones de un sistema de desarrollo. Por tanto, UML es independiente de la metodología de desarollo, de ésta manera pueden trabajar con XP por ejemplo y apoyarse en las notaciones UML para los diagramas de clase, casos de uso, etc. UML NO ESPECIFICA COMO DESARROLLAR el software.

Ahora bien, les platicaré un poco sobre XP. eXtremme Programming es una metodología propuesta por Kent Beck y sus puntos esenciales son:

* Desarrollo del proyecto por parejas. Esto permite una retroalimentación y evita las situaciones donde entre tanta gente involucrada en el desarrollo es díficil tomar decisiones.
* Orientando todo a las pruebas, se realizan pruebas de unidad de los módulos.
* 40 horas de trabajo semanal, las horas extras mitigan los ánimos de los desarrolladores.
* Procura una homegenoidad y/o estandarización en el código.
* KISS = Keep it simple stupid!!. Mantener las cosas lo más simple posible es garantía de enredos lógicos de programación y una ardúa tarea de depuración. Lograr que funcionen las cosas como deben de funcionar y al nivel más fácil de comprender. Los "arreglos" (mejoras de eficiencia en el código, reducción del código innecesario, mayor separación entre clases de objetos, etc.) serán llevados a cabo una vez concluido el proyecto, o en su defecto, cada módulo del mismo.

De estos puntos apoyo firmemente la idea del trabajo en parejas. Ciertamente, 3, 4, 5, ..., n cerebros piensan más que 2 pero sin lugar a dudas, sin una buena organización y definición de las funciones que cada miembro del equipo de desarrollo tiene, a mediano plazo resultará en un caos donde todos piensan tener la razón y/o quieran implementar las cosas de acuerdo a sus criterios.

Un elemento MUY importante que deben de considerar es mantener una homegeneidad en el código. Me ha tocado ver aplicaciones en X herramienta (por mencionar una, Delphi) en donde los nombres de los objetos y componentes visuales de la aplicación son imprecisos. Qué más impreciso puede ser: TextEdit1 ¿? Los equipos de desarrollo deben de procurar siempre seguir lineamientos en cuanto a las nomenclaturas de objetos e inclusive en la estructura de directorios del proyecto, vaya, CADA COSA EN SU LUGAR.

Así por ejemplo, almacenen las imagenes en una carpeta imgs por ejemplo, las clases que pertenecen al modelo del problema dentro de un paquete específico, etc. Nomenclaturas "estándares" para los componentes visuales de la aplicación. Estas son prácticas y hábitos que aquel que se considere como programador debe tener muy en cuenta. Además, estas prácticas reducen el impacto "negativo" de agregar una nueva persona al equipo de desarrollo, dado que lo que esta persona debe de saber son esos lineamientos y con ello, no habrá tanto pierde.

Bueno, pues por el momento es todo. Los puntos mencionados sobre XP son los más relevantes, aunque difiero de la opinión de 40 horas a la semana, soy más de los que apoyan la idea e incluso haría más honor al nombre: ¡Programación Extrema!

Sobre el performance de apps y web services en J2EE

Estuve platicando con uno de los colaboradores del blog: José Castro, y entre la plática surgió un tema interesante: realmente es cierto que el performance de las aplicaciones y servicios Web en el mundo de J2EE es, en comparación con las herramientas (frameworks, servidores, etc.) proporcionadas por Microsoft.

De hecho, se rumora también que muchas empresas están migrando sus bases de datos que manejaban con Oracle a SQL Server. Esto debido a que Oracle ha incluído módulos/elementos desarrollados en Java y por lo tanto, según "disminuyen" el rendimiento y rápidez en las transacciones.

Por el momento, aprovecho algunos ratos "libres" para trabajar con el servidor de aplicaciones de Sun, Sun Application Server PE 9. Y les puedo comentar que los argumentos que pueden encontrar sobre un bajo performance con J2EE son poco o nada sustentables. Todo depende de los detalles de la arquitectura de servidor y configuración del mismo. De esta manera, si por ejemplo, tienen 30 apps JSP corriendo en un TomCat, sobre un servidor con un procesador Xeon a 4 GHz, y de 2 a 4 GB de RAM, sin múltiples JVM configuradas, entre otros muchos detalles erróneos en la planificación y diseño del servidor, es obvio que tú servidor reventará, pero, TU lo habras hecho reventar, dada las sutilezas en los detalles de configuración que has pasado por alto.

Y no lo digo yo nada más, muchas personas con experiencia en estas cuestiones lo saben. Y para muestra basta un botón: http://www.lugmen.org.ar/pipermail/lug-list/2005-September/037839.html, información que representa una crítica muy seria y completamente cierta y demuestra el porqué de los argumentos que "J2EE no tiene un buen performance".

Comparativa: JEE5 vs ASP.NET 3.5 (2008)

Saludos a todos, me complace presentarles mi Primer aporte al Blog de mi amigo Dario.

En esta oportunidad se muestra la comparativa de arquitecturas Web más populares y robustas en este momento como lo son JEE5 (Java Enterprise Edition 5) y ASP.NET 3.5 (ASP.NET 2008).






Espero que les haya servido de referencia a la hora de seleccionar la tecnología más adecuada para sus proyectos.

José Castro.

Sobre la preparación académica en el estado de Tabasco

La situación es esta: lamentablemente he estado notando ya desde tiempo atrás la falta de preparación por parte de los estudiantes de nivel superior de las carreras de informática y computación.

Además, la falta de buenos incentivos y apoyos por parte de las instituciones académicas hacia sus alumnos, o el hecho de que en muchas ocasiones les cierran las puertas, diciendo que se debe a tramités burocráticos o normativas que deben seguirse. No señores, no lo creo. No entiendo aún cuál sea el temor de algunas personas que por momentos parece que traten de entorpecer el avance de su prójimo. Me ha tocado ver personas talentosas a las cuales, aquellas personas quienes "están arriba" no las voltean a ver, de verdad que es un desperdicio de talento y por ello la gran fuga de cerebros (buenos) no sólo en nuestro, si no en todo el país.

Por otro lado, al igual que nuestro planeta, existe mucha gente que no está del todo preparada para egresar de una institución de nivel superior e integrarse a su medio productivo. Y entiendáse como su medio productivo al hecho de integrarse en un trabajo donde realmente desempeñe sus habilidades, experiencias y conocimientos que desarrolló durante su formación profesional. Señores, las cosas "afuera" están bien díficiles, y si nosotros optamos por hacerlas aún más difíciles es eso lo que obtendremos.

Para muestra falta un botón. Hace días leí un comentario en un blog (http://brigomp.blogspot.com/2008/03/anlisis-de-rendimiento-y-la-necesidad.html) donde el autor del mismo menciona el hecho de haber recibido un correo donde una persona que labora en una empresa X la planteaba unas dudas que pone en clara evidencia la falta de preparación de la que les hablo. Temas y situaciones que no te enseñan, la mayoría de las veces en las instituciones de educación superior. He ahí una crítica más a nuestro sistema de educación no sólo estatal, si no federal.

Señores que están "arriba de nosotros", esas personas que nos dirigen como educadores/maestros, olviden o, al menos traten de apoyar más y reconocer a los buenos talentos que sí bien son pocos son muy buenos, la gente, esos muchachos talentosos se les están escapando de las manos y están trabajando muchas veces ni para compañías del país, y aquellos que sí lo hacen, plantean dudas que no debieran ser un dolor de cabeza para ellos, prueba de su falta de conocimiento e interés por desarrollarse en su área.

Jóvenes compañeros, estudiantes de las tecnologías de la información, evalúen: ¿quiénes son? ¿Qué es lo que quieren ser? ¿Por qué están estudiando lo que estudian? ¿Realmente les gusta, les apasiona? Como muchas de las cosas en esta vida, si no te apasiona es como ir de paseo al desierto: será un verdadero sufrimiento y agotamiento para ustedes, además que, dadas las condiciones, no se desarrollarán como debe de ser.

A ponerse las pilas señores, dejemos a un lado las excusas y a sacar adelante a nuestro estado y en consecuencia, a nuestro país.

P. D. = Echen un vistazo al blog del cual les hablo, es interesante y sobre todo, sean sinceros consigo mismos: para aquellas personas que se dicen ser buenas en el desarrollo de aplicaciones, particularmente del mundo Web ¿realmente podrán saber dónde el error?

Eclipse Vs. NetBeans

Eclipse y NetBeans son dos de los IDEs más populares para el desarrollo de aplicaciones Java. Desde mi perspectiva, son quizás también los que más pudieran llegar a tener grupos de personas quienes apoyen a X ó Y.

Particularmente he trabajado con Eclipse, y puedo asegurarles que es un entorno de desarrollo bastante profesional y para mí, el mejor. Hace un par de días leí que para el lanzamiento de cada nueva versión de éste IDE el equipo de desarrollo así como los líderes que los dirigen (equipo administrativo y demás) son nuevos para cada implementación del IDE. Además, de ser un equipo de personas quienes siempre han entregado sus proyectos a tiempo (http://brigomp.blogspot.com/2007/04/eclipse-5-aos-lanzando-software-tiempo.html) ha sido realmente ¡21 proyectos de desarrollo en un solo! (http://www-128.ibm.com/developerworks/opensource/library/os-eclipse-europa/)

Actualmente estoy trabajando con el plug-in MyEclipse, y qué les puedo contar de él. Es una hermosura, desde aplicaciones Swing pasando a través de configuración de servidores, despliegue de aplicaciones, conexiones a bases de datos, persistencia de objetos, la oportunidad de desarrollar aplicaciones JSF, Struts, ICEFaces de una manera muy fácil, rápida e intuitiva (claro, con conocimientos teóricos previos), diagramas UML, ORM, debuggers (AJAX, JavaScript, JSF,...), y si a esto le agrega los miles de plug-ins externos que pueda descargar, por mencionar algunos: desarrollo de aplicaciones móviles, unidades de prueba (JUnit, JWebUnit,...), manejo de objetos persistentene con TopLink de Oracle o Hibernate y hasta donde sé, próximamente OpenJPA, un proyecto open source para persistencia de datos de uno de los gigantes del mundo Web: Apache (al menos en la versión 3.x de Eclipse, con el plug-in MyEclipse 6.0x no cuentan con ello).

Un sin fin de herramientas de apoyo que nos libera del trabajo duro ésta herramienta. Sí bien es cierto, he argumentado únicamente sobre Eclipse y particularmente de MyEclipse, y no he desplegado argumentos sobre NetBeans, pues los invito precisamente a ello, compartan las experiencias que han tenido con éste último IDE, después de todo, es una de las finalidades del blog: compartir experiencias, guiarnos los unos a los otros, compartir el conocimiento, pues el conocimiento es de todos. Quizás estoy equivocado y haya más luz del otro lado del camino. . .

¡ B I E N V E N I D O !

Hola a todos. Les doy la bienvenida a mi blog sobre Tecnología de la Información. Aquí trataremos temas sobre informática y computación, particularmente del desarrollo de aplicaciones y todo lo que involucre.

Aunque se tratarán temas sobre otras herramientas/lenguajes de desarrollo, por el momento el alcance principal del blog es difundir el desarrollo de aplicaciones empresariales con el lenguaje Java.

Dirigido a el público en general, y específicamente, a la comunidad del estado de Tabasco, quienes se interesen en compartir sus dudas, inquietudes y sugerencias sobre las temáticas abordadas.

Sientánse libres, pues la verdad os hará libres. Gracias por darle difusión y su apoyo para postear temas relevantes y novedosos...