viernes, 31 de agosto de 2012

CodeRetreat v1.MX.DF.2012

Primera versión de un CodeRetreat en la ciudad de México, DF.

El sábado 25 de este mes, se realizó en la ciudad de México, el primer codeRetreat organizado por:

  

Este fue el  poster oficial:


El resumen Oficial.
Puedes leer un resumen oficial del evento en:

Así lo viví.
Fue una experiencia interesante, no tenía mucha idea de que esperar del evento, y al finalizar no tengo más que aceptar que, el saldo fue totalmente positivo.

Así sí baila mi'ja con el sr.
Debo confesar que, IMHO, me puse sensible cuando nos pidieron borrar código generado por nuestras manos (sí!! pidieron eso!! ¿Pueden creerlo?:P).

Y no tanto por tener que eliminar de la existencia de algo que, de por sí, es efímero.

Siempre he sido de la idea: "En la forma del pedir está el dar."

Imagina que ahora mismo llego a tu escritorio y te digo:
"Oye, te voy a pedir un favor; esta dinámica requiere que dejes de utilizar el código que llevas hasta el momento. Debes de comenzar de nuevo. 
Verás que, al final del día esto ayudará a que todos tengamos un mejor entendimiento de las prácticas que queremos mostrar. ¿Nos ayudas?"

Ahora imagina que llego y te digo.
"Borra tu código... o qué  ¿Eres pvt0?"

Las palabras seducen, aprendamos a utilizarlas  ;)

Siguiendo (y como suelo decir) el protocolo, hice saber mi opinión, creo que, los programadores somos tan sui-generis en nuestras personalidades que, no faltará el que esa noche, planeo mentalmente una venganza por tal afrenta.....y, siendo honestos, yo no me espere hasta la noche XD.

Estaba a punto de juntar a 7 rebeldes para tomar las instalaciones cuando el sempai chillicoder me dijo sabiamente: "RuGI, todo es apego, todo es apego.".... Esas sabias palabras, acompañadas de un poco de alimento (un rico cuernito de jamón), calmaron mis pueriles instintos de venganza.

El objetivo.
Orientado a lo que debe ser nuestro día a día como desarrolladores, todas las dinámicas estuvieron enfocadas a una sola cosa:
"Programar mejor, hacer mejor las cosas."

Como hilo conductor del evento, tuvimos la misión de implementar en parejas (aka pair programming) el famoso "Juego de la vida" (aka Game of Life).

Lo que hicimos.
Si bien, la implementación sólo era la fachada sobre la cual los cordinadores operaban sobre nuestras mentes para inculcarnos de qué vá un codeRetreat.

El evento duró todo el día, por la mañana mi primer salvatore, fue @misaelpc.
Ya en la tarde fui socorrido por @apcxiii, y dado que ya estaba en modo zen (y que quede asentado en el acta compañeros: siguiendo las recomendaciones de los organizadores), volvimos a empezar desde cero... todo. ( si quieren saber por que uso las palabras: salvatore y socorro, lean el resumen oficial y presten atención a la técnica para formar los pares de trabajo).

Entrada la noche, fuimos por un par de cervezas y unas cuantas alitas, y papas, y alitas, y papas.... y papas... XD

Pues bien, no quize quedarme con las ganas y me dí un tiempo para concluir la implementación java que diseñe junto a  @misaelpc, la solución propuesta con @apcxiii estaba basada en objetive-c y, ahí, el tiene más experiencia; y pues... #yoRespeto, #BoraRespeta

La evidencia.
A grandes rasgos, este fue nuestro cascarón principal. (Pero por supuesto... seguí la recomendación que ya hemos analizado: Comienza con un esqueleto funcional)



Aquí un video como "evidencia" de que funciona adecuadamente. ;)


GOL from Isaac Ruiz Guerra on Vimeo.


 El código esta dispobible en mi cuenta de git

La despedida.
Felicitaciones sinceras a los organizadores:

El esfuerzo (cof cof y el riesgo cof cof ) de organizar este tipo de eventos es grande, pocos "se rifan", y ellos lo hicieron, #aplausos #mePongoDePie 

Saludos y, nos vemos en el próximo codeRetreat   ;)
-------
RuGI

lunes, 19 de marzo de 2012

Conectando java con node.js usando redis como puente.

Y que volvemos después de un rato de no escribir.

Este fin de semana, (como si no tuviera una lista de pendientes) se me antojó hacer un ejercicio de integración entre java y node.js

Tenía rato de probar node.js, y como ocurre en estos casos; lo mejor es tener un escenario práctico.

La idea de fondo es la siguiente:

Graficar dinámicamente en un browser un valor X recuperado desde un contexto java usando node.js como servidor de datos.
(lo que este valor represente es lo de menos, puede ser -usando jmx- prácticamente cualquier cosa)

Siguiendo lo que dicen los libros, lo primero que debemos probar es que la solución que propongamos debe funcionar de punta a punta; es decir:  [[2 de 97]. Comienza con un esqueleto funcional]

Pensé en redis.io como puente por dos razones:

  • Tanto node-js como java tienen clientes estables para conectarse a un servidor redis.
  • Dado lo que quiero hacer (mover cantidades de un contexto a otro) el paradigma (¡Que bonita palabra!) key-value  se presenta factible.
Ya tenemos la idea completa; los ingredientes que requeriremos son:
Este diagrama de componentes es el siguiente:



El resultado es el siguiente:



Así que, ahora ya podemos contestar (con los pelos en las manos) que, es factible el uso de node.js como servidor de datos para monitoreo de algún servicio java, usando redis-io como puente.

Saludos!!!
----
RuGI

sábado, 25 de febrero de 2012

Jarhalla-Local ver CLI

Ya está lista la versión CLI de jarhalla-local, un sencillo buscador de clases y jar's hecho en java :)

Si la deseas ejecutar; sólo revisa
https://github.com/rugi/jarhalla-local/tree/master/standAlone/0.91

La carpeta principal del proyecto es:
https://github.com/rugi/jarhalla-local

Aquí el video que muestra el uso de la versión CLI:



Saludos!!!
RuGI

sábado, 21 de enero de 2012

Jarhalla Local. Algunas mejoras

Pues, el fin de año decidí cerrarlo programando e iniciar este igual programando así que, jarhalla-local tiene ya unas pequeñas mejoras:
  1. Búsqueda de jars o clases a partir del nombre.
  2. Soporta el comodín *
  3. Detección de repositorios de .ivy, .gradle y .mvn2
  4. Visualización del archivo Manifest - si lo tiene- de cada jar encontrado.
Todo esto se puede apreciar mejor en el siguiente video.


Saludos!!
---
RuGI
@rugi

sábado, 7 de enero de 2012

El Middleware


Texto basado en el documento:
Oracle Fusion Middleware
Concepts Guide
11g Release 1 (11.1.1)
E10103-03
http://docs.oracle.com/cd/E15523_01/core.1111/e10103.pdf

El Middleware.

1.1 ¿Qué es un Middleware?

El middleware es la infraestuctura que facilita la creación  de aplicaciones de negocio.
Proporciona una serie de servicios básicos como:
Concurrencia, transacciones, subprocesos, mensajería asíncrona y la implementación, Software Communications Architecture (SCA) sobre la cual se despliega una solución SOA.
Incluye tambien el tema de seguridad y habilita la "alta disponibilidad".

El Middleware incluye:
Casi toda la comunicación está basada en XML:
y

En el tema de autenticación y autorización de usuarios se recurre a:
  • Lightweight Directory Access Protocol (LDAP) o
  • Algún otro  servicio de directorio de usuarios.
La figura 1. muestra la arquitectura de un Middleware.



Figura 1. Middleware. Arquitectura.
Actualmente las empresas crecen reutilizando aplicaciones ya existentes (conocidos como sistemas legado), en muchas ocasiones estas aplicaciones legado tiene interfaces (a este nivel entenderemos como interfaces la manera que ofrece cada aplicación para interactuar -de manera externa- con ella) imposibles de modificar.
En algunos casos el costo de volver a escribir o adaptar estas interfaces es prohibitivo.

Adicionalmente  los sistemas resultantes pueden ser utilizados en una amplio rango  de dispositivos, los cuales varían en ancho de banda de consumo, poder de procesamiento local,
resolución de pantalla, capacidad de colores, etc. Estos dispositivos van desde  computadoras personales, agendas digitales, smartphones, etc.

Esto hace que las aplicaciones tengan que diseñarse pensando que a futuro serán  accedidas por esta gama de dispositivos.

1.2 Funciones del Middleware.

Las aplicaciones (empresariales) utilizan software que se encuentra  en la cima del SO, ademas de una amplia gama de protocolos para realizar las siguientes tareas:
  • Ocultar la naturaleza distribuida de una aplicación.
  • Ocultar lo heterogéneo de los sistemas de la empresa.
  • Proporcionar una serie de interfaces de alto nivel de manera uniforme, para que puedan ser utilizadas por los desarrolladores e integradores de software. Así las aplicaciones pueden ser facilmente:  compuestas, reutilizadas, "portadas", e interactuar con otros sistemas.
  • Proporcionar una serie de servicios comunes para realizar tareas y funciones generales,
 Y evitar con esto retrabajo, ademas de facilitar la colaboración entre aplicaciones.

En resumen; El middleware
  1. Facilita el desarrollo de aplicaciones: proporcionando una interface común de desarrollo.
  2. Enmascara lo heterogéneo y la naturaleza distribuida de los sistemas legados de la empresa (esto incluye software y hardware)
  3. Oculta los detalles de bajo nivel de los sistemas existentes.

1.3. Diseño de arquitectura del Middleware.

La función del middleware es mediar la interacción entre fragmentos de una aplicación con otra, o entre aplicaciones completas.

Además de los aspectos arquitectónicos, los principales problemas de diseño de un middleware se refieren a diversos aspectos propios de los sistemas distribuidos.
Cualquier sistema middleware se basa principalmente en una capa de comunicación que permita  interoperar a sus diferentes piezas.

Además, la comunicación es una función proporcionada por el propio middleware para aplicaciones en las que las entidades en comunicación que puede asumir diferentes roles tales como:
El middleware permite además modos de interacción:
  • Invocaciones síncronas.
  • Envío de mensajes asíncronos.
  • Coordinación a través de objetos compartidos.
Involucrando en esto distintos tipos de patrones.

Por lo tanto, el diseño de un sistema middleware se enfrenta a varios retos:

1) Los sistemas middleware se basan en mecanismos de intervención y direccionamiento indirecto de mensajes,  dichos mecanismos inducen una reducción en el desempeño de las aplicaciones.
Volver estos mecanismos adaptables, sólo agrega rodeos al procesamiento de dichos de mensajes innecesarios y empeoran la situación.

2) Debido a  las aplicaciones están cada vez más interconectadas e interdependientes, el número de objetos, usuarios y dispositivos tiende a aumentar considerablemente.

Esto plantea  problemas de escalabilidad, comunicación; en los algoritmos de gestión de objetos, y aumenta la complejidad de la administración.
La disponibilidad, fiabilidad, concurrencia, seguridad y rendimiento de las aplicaciones también puede ser un problema.

3) La informática generalizada/distribuida  es la visión en un futuro próximo, La movilidad y la reconfiguración dinámica será dominante, lo que requiere la adaptación permanente de las aplicaciones.

4) La gestión de aplicaciones de gran tamaño que son heterogéneas, ampliamente distribuidos, y en permanente evolución plantea muchas preguntas, tales como:
  • El monitoreo constante,
  • La seguridad,
  • El balanceo entre la autonomía y la interdependencia de los diferentes subsistemas,
  • La definición e implementación de políticas de gestión de recursos.

1.4 SOA.

La arquitectura orientada a servicios (SOA por sus siglas en inglés) es un estilo arquitectónico, cuyo objetivo es lograr un bajo acoplamiento entre las diversas aplicaciones de software que interactuen entre sí, habilitando a una organización para  que tome ventajas de las aplicaciones y sistemas con los que cuenta.

SOA facilita el desarrollo de servicios del negocio modulares que pueden ser facilmente integrados y reusados, creando así una infraestructura flexible y adaptable.
Utilizando una aproximación SOA una organización puede enfocar más los recursos de su presupuesto en innovación y no en la puesta a punto de nuevos servicios de negocio.

Algunas de las ventajas de usar SOA son:
  • Reducción en los tiempos y costo de los desarrollos.
  • Menores los costos de mantenimiento.
  • Servicios de alta calidad.
  • Reducción en los costos de integración.
¿Cómo logra SOA reducir el acoplamiento entre la interacción de los agentes de software?
Lo hace mediante el empleo de dos restricciones de la arquitectura:

1) Se proporciona un conjunto compacto y generalizado  de interfaces para que pueda ser usado por los agentes.
Las interfaces están universalmente disponibles para todos los proveedores y los consumidores.

2) Se usan mensajes descriptivos limitados por un esquema extensible.
La más mínima actividad de un sistema esta definido por un mensaje. 
Dichos mensajes están limitados por un vocabulario definido. Un esquema extensible permite que las nuevas versiones de los servicios que se creen puedan existir sin romper los  servicios existentes.

1.5 Oracle Fusion Middleware Solution

Oracle proporciona una suite completa de productos llamada: Oracle Fusion Middleware, es (comercialmente hablando) la propuesta de middleware de Oracle para el mercado empresarial.

Oracle Fusion Middleware ofrece una solución para manejar  software aplicativo empresarial  complejo y distribuido.
Esto incluye:
Y demás herramientas que apoyen el desarrollo y liberación de aplicaciones empesariales.

Oracle Fusion Middleware es una colección de productos basados en estandares de software, que incluyen un rango de herramientas y servicios: desde un entorno totalmente compatible con las implementaciones JEE5 (Java Enterprise Edition), pasando por herramientas de desarrollo para integrar servicios, bussines intelligence, entornos de colaboración, y administradores de contenidos.

Oracle Fusion Middleware ofrece un soporte completo para desarrollar, desplegar y administrar aplicaciones  empresariales.



Figura 2. Resumen de tecnologías implicadas en la Oracle Fusion Middleware.
Listado de soluciones:
  • Administrador de contenido (Content Management)
  • Application Server
  • Integracion y Business Process Management (BPM)
A grandes rasgos, ahora ya sabes que es el middleware y, la solución ofrecida por Oracle.


Saludos!!
---
RuGI