Publica tu how-to

Dinos como hacer lo que sabes hacer, mándanos un email a wdonet@gmail.com y lo publicamos (dos días máximo) o si te interesa unirte al equipo de redactores, también háznoslo saber por correo.

Intro a EAF (Enterprise AJAX Framework) de jackbe

Se trata de la parte AJAX de Jackbe y para trabajar con él podemos usar un proyecto en Eclipse con el plugin del EAF. Pero es necesario que Eclipse cuente con la funcionalidad WTP para poder trabajar. El proyecto en Eclipse se conforma por carpetas como:
  • WEB-INF - aquí van los archivos web
  • WEB-INF/jbml - son los archivos fuente de las pantallas web o con lo que se llama'jackbe markup language'.
  • WEB-INF/jsp - son creados de forma automática al crear pantallas jbml y básicamente, invocan al constructor de nuestra pantalla jbml
  • gc.jsp - es un archivo que almacena la configuración global para traerse al núcleo los archivos del EAF. Es de notar que en cada archivo jsp creado de forma automática, se incluye un código como sigue: <jsp:include page="./jackbe/jsp/gc.jsp"/>.
  • jackbe - almacena archivos del núcleo
  • fb - significa 'form behavior', que almacenan el comportamiento de las pantallas a través de programación javascript, así que se trata de archivos '.js'.
  • jf - aquí se guardan los 'jackbe forms' o los archivos compilados de jbml, también son archivos '.js'.
  • rb - resources boundle

Metodología de desarrollo XP

Ciclo de la metodología
  1. Planificación. Escuchar las necesidades del Cliente, hacerlo parte del equipo, pero explicar lo que es fácil de obtener y lo que no
  2. Diseño. Es importante usar patrones de diseño.
  3. Desarrollo. Hacer que el propio código comunique lo que está haciendo.
  4. Pruebas. Realizar pruebas unitarias, puedes usar frameworks muy conocidos como JUnit y DBUnit.
Valores que promueve : | Comunicación | Coraje | Simplicidad | Retroalimentación |

Ventajas:
  • Es un diseño simple
  • Obliga a que funcionen todas las pruebas unitarias, todo el tiempo.
  • Muchos comentan que no tiene, pero yo creo que solo se reduce la lógica duplicada.
  • Suele tener menor número de clases y métodos. Aunque esto depende de la modularidad de la aplicación y que el desarrollador realice un diseño claro, simple y use patrones.
Desventajas:
  • La documentación suele ser pobre.
Buenas prácticas:
  • Realizar un diseño simple
  • Pequeñas versiones. Hacer entregas constantes para que el Cliente perciba el avance y retroalimente las necesidades de negocio que afinen la funcionalidad efectiva de la aplicación.
  • Pruebas. Cada funcionalidad en la aplicacion (front, back, web-services, DAOs, VOs, Utilerías, etc.) debe ser probada.
  • Recodificar. Siempre que veamos código al que se puede aplicar un refactoring, aunque no sea nuestro, es conveniente avisar al equipo y planear su reestructuración a medida que la propia aplicación lo pida.
  • Programar en parejas. Un solo teclado, un solo ratón, una persona codifica, ambos piensan, se logran ideas más estratégicas (es importante que ambos estén abiertos a escuchar las ideas del otro con el fin de mejorar las propuestas planteadas y por consiguiente la aplicación).
  • Integrar una vez al día. Obviamente antes de integrar implica ejecutar las pruebas para validar que todo siga funcionando como lo esperan las pruebas unitarias.
  • 40 hrs por semana máximo permiten estar fresco, descansar 2 días para pensar en nuevas ideas y aplicarlas al inico de semana. Estaría bien disponer de un tiempo a medio día para descansar (siesta, break, tomar un pequeño postre) o despejar la mente realizando otras actividades (juegos de mesa, videojuegos, salas de lectura, reuniones de convivencia). Es parte del modelo laboral japonés y les funciona.
  • Establecer estándares de codificación. Usar un checkstyle y practicar revisiones en parejas del código de otros resulta bastante bueno para la aplicación pues ayuda a detectar posibles errores de estilo e incluso de lógica, de forma que cualquier nuevo integrante que llegue al equipo se familiarice más rápido con el código.

Servidor Linux desde tu hogar Intro 2

Antes de entrar en tema, demos un breve recorrido por los tres pasos para levantar un servidor en tu hogar, para averiguar por qué necesitamos llevarlos a cabo:
  1. Publicar mi dirección IP. Tal vez has notado alguna vez al momento de estar conectado en el hogar, que la dirección IP que tiene asignada tu máquina por parte del ISP es una dirección local, de la LAN creada en tu hogar con el ruteador al que te conectas a Internet. Mientras tanto la dirección IP 'real' que el mundo conoce de la LAN es otra. Puedes visitar algún sitio como este, y podrás notar que aunque tu sistema informa que su dirección IP es una (a través de ifconfig por ejemplo), 'desde afuera', la dirección IP es otra, pues se trata de la dirección con la que en realidad el ruteador de tu LAN se comunica al mundo exterior. El truco en este paso consistirá entonces en hacer que la dirección IP del ruteador con el que te conectas, quede de alguna manera asignada (o más bien ligada) también a la máquina que funcionará como tu servidor.

Servidor Linux desde tu hogar Paso 3

Recordando la localización de mi servidor


Y otra vez los tres incisos:
  1. conseguir el servicio de DNS
  2. configurar el servidor
  3. probar
Servicio de DNS
Lo más recomendable es utilizar un servicio DNS que por un lado ligue la dirección IP de tu servidor/ruteador con un nombre común y fácil de recordar. Por otro lado, en caso de que tengas una dirección IP dinámica, el servicio DNS también debería asociar dinámicamente la nueva dirección IP con el nombre de tu servidor.

Servidor Linux desde tu hogar Paso 2

Levantado mi servidor

De nuevo, este paso se realiza en tres incisos:
  1. configurar el firewall, para la seguridad
  2. instalar, configurar y levantar los servicios en sí mismos
  3. probar
Configurar el firewall
Dependiendo la distribución Linux que tengas, éstas muchas veces ya vienen con utilidades de configuración que permiten establecer la seguridad del firewall en la máquina. Todo lo puedes configurar a través de estas utilidades, o configurando directamente los archivos pertinentes. En este tutorial no nos enfocaremos en ninguna de esas dos formas, solamente mencionaré lo que en sí tienes que conseguir.

Una de las cosas que requieres, y que probablemente haya quedado configurada desde el inicio cuando instalaste (o te instalaron) Linux en la máquina, es que el firewall se active desde que arranca la máquina, de otra forma tendrías que estarlo activando manualmente cada vez que reinicias tu máquina.

Servidor Linux desde tu hogar Paso 1

Publicando mi dirección IP

Este paso se realiza en dos (bueno, tres) incisos:
  1. ligar la dirección IP del ruteador con el servidor, configurando el ruteador
  2. habilitar el servidor para tomar dicha dirección
  3. probar
Ligar la dirección IP
Para publicar la dirección IP, es decir, para que la dirección IP externa, del ruteador, quede ligada a la máquina que funcionará como servidor, debes acceder a la página de configuración del ruteador. Dependiendo el modelo del aparato, esta puede cambiar. En este caso te recomiendo que consultes la documentación del ruteador para conocerla. Un caso típico es en la dirección 192.168.1.254, aunque como dije, esto depende de cada ruteador.

Una vez dentro debes buscar la opción para redirigir todas las peticiones del ruteador hacia la máquina específica del servidor. Esto se conoce como port-forwarding, y normalmente se encuentra dentro de las opciones del firewall del ruteador. Por ejemplo, en un ruteador 2Wire, accediendo a las opciones del firewall para la máquina en particular que funcionará como servidor, deberías colocar dicha máquina en el modo DMZPlus. Esto provocará que todo el tráfico que entre al ruteador sea dirigido a la máquina servidora, excepto aquel que por configuraciones del mismo firewall del ruteador se haya especificado para dirigirse a otras máquinas, para aplicaciones particulares.