sábado, 24 de mayo de 2014

Un poco de historia.

Revisando un poco los enlaces que luego voy guardando (desde hace años procuro guardarlos en mi cuenta de Delicious.comhttps://delicious.com/rugi ) encontré esta joya documental; si bien existen ya varios poster's de este tipo, IMHO, el de O'reilly es el más completo.


The History of Programming Languages



Si sólo tomamos la versión 1 como el inicio de java, veremos que, Ruby es mayor (históricamente Oak marca el inicio del lenguaje java.)

Python es casi de la misma edad que java y en 1995, el diablo entró al mundo de los lenguajes con javaScript....  :O !!!  #bromita


Simula 67 es (efectivamente del 67) y smalltalk del 69.... entonces, ¿Por qué es que comenzamos a tener más referencias y escuchamos más sobre estos lenguajes?


Quizá esta imagen nos ayude a contestar esa pregunta:



La academia viene al rescate con paradigmas (ya probados y optimizados) para los requerimientos y condiciones de hardware actuales (Si estás haciendo una maestría/master/doctorado actualmente, felicitaciones, estás preparando el futuro de nuestra área).

Disfruten del poster y, si no tienen inconveniente, creo que deberían usarlo para substituir colocarlo junto al de esa modelo en bikini.
;)

Saludos
---
RuGI


domingo, 18 de mayo de 2014

IMDG o todo va a la RAM

No es un tema nuevo

Siendo honestos no es un tema nuevo, la primera referencia que tengo sobre el tema está en el blog de Martín Perez, Pensamientos ágiles, cuando buscaba información sobre CoherenceGrid vs. Spaces; Oracle Coherence vs. GigaSpaces

El principio básico es sencillo, basta recordar lo que nos dijeron en la facultad/carrera:

"Acceder a memoria(RAM) es infinitamente más rápido que acceder a HHDD"; 

Esta bien, esta bien.... no es infinitamente más rápido pero, los números aun sugieren que hay diferencias substanciales:

"The processing performance of main memory is 800 times faster than an HDD, 
40 times faster than an SSD and seven times faster than the fastest SDD"
Ki Sun Song in Cubrid.org

Pero, vamos muy rápido, empecemos por el principio.

IMDG

¿Que es un In Memory Data Grid (IMDG)?

"Una red de datos en memoria*  es una estructura 
que reside completamente en la memoria RAM,
 y que se distribuye entre múltiples servidores."
* Traducción libre de:


Se bien que muchas veces una imagen ayuda a entender un concepto:

IMDB. imagen tomada de http://whatis.techtarget.com/definition/in-memory-data-grid
Figura 1. IMDG [1]

¿Cuál es el objetivo de todo esto? como bien menciona Martín, reducir la latencia de acceso a datos y agilizar con esto substancialmente el tiempo de respuesta de una operación crítica.

Un IMDG  debe cumplir con las siguientes características: 
  • El modelo de datos se distribuye a través de varios servidores que pueden estar distribuidos en distintos punto geográficos.
  • Esta distribución se conoce como una fabrica de datos
  • Este tipo de modelo de datos distribuido se conoce como arquitectura "shared nothing".
  • Todos los datos se almacena en la RAM de los servidores. 
  • Los servidores se pueden agregar o quitar sin interrupciones, para aumentar la cantidad de memoria RAM disponible. 
  • El modelo de datos es no-relacional y está basado en objetos. 
  • Las aplicaciones distribuidas son compatibles (por ejemplo pueden estar escritas tanto en java como en .Net). 
  • La fabrica de datos es elástica, lo que permite la detección automática (sin interrupciones) y la recuperación ya sea de un único servidor o varios servidores.

Todas estas características nos ayudan a responder la siguiente pregunta.

¿Por qué es importante?

Paul Colmer menciona en su artículo que son 3 las ventajas que un IMDG puede proporcionar comparándolo con una solución basada en una base de datos relacional:
  • Performance. Usar la memoria RAM es más rápido que usar HHD. No hay necesidad de tratar de predecir cuales serán los datos que tienen que cargarse en la RAM. Ya todo está en la memoria. 
  • Estructura de datos. Usar el patrón llave/valor le da una mayor flexibilidad al desarrollador de la aplicación. El modelo de datos y el código de la aplicación están mejor modelados que usando una estructura relacional. 
  • Operaciones. La escalabilidad y flexibilidad son fáciles de suministrar y mantener. Las actualizaciones de software/hardware se pueden realizar de manera no disruptiva.
Menciona además 4 beneficios reales:
  • Ventaja competitiva.
  • Seguridad en el negocio.
  • Productividad.
  • Mejora de la experiencia del cliente.
Con todo esto, quizá a estás alturas de la lectura te estarás haciendo la siguiente pregunta:

¿Dónde se usa?

Dada la robustez que ofrecen las soluciones IMDG actuales y dado que el principal beneficio es la rapidez para acceder a datos críticos, son principalmente 3 las áreas que han comenzado a adoptar esta arquitectura:
  • Servicios financieros.
  • Retail.
  • Aviación.
Oracle Coherence tiene una página para difundir sus "casos de estudio"
http://www.oracle.com/technetwork/middleware/coherence/coherence-case-studies-091909.html

Dónde seguir.

Si te interesó el tema lo suficiente para continuar leyendo hasta aquí, el enlace mencionado al inicio de este post es un buen punto de partida para saber más sobre el tema: Introduction to In-Memory Data Grid: Main Features; también dzone, en su zona de arquitecura, tiene un artículo completo sobre el tema, incluye gráficas comparativas sobre el uso de memoria: In-Memory Data Grids.

Dzone tiene un refcardz para Infinispan.

InfoQ, no nos puede quedar mal, tiene bastante material sobre el tema:


Parleys también tiene presentaciones/videos:
Si te dedicas al back-end, o juegas el rol de arquitecto de software, o eres consultor TI, seguramente te servirá conocer un poco más sobre este tema.

¡¡¡ Data Grid para todos !!!

Saludos  :)
---
RuGI


Créditos:

jueves, 1 de mayo de 2014

2 links 2

Esta semana he andado muy activo en mi cuenta de twitter ^.^, y de entre los links que compartí, hay uno en particular que tuvo un interés especial.... para mi :P

El sitio se llama: http://hotframeworks.com/ y, sí, justo como su nombre lo indica, muestra un listado de los principales frameworks web.

Su indice utiliza indicadores de https://github.com/ y http://stackoverflow.com

Para mi gusto el listado se muestra coherente y por ello me permito compartirlo.

El listado para java se ve así:



Python:


Erlang:


Clojure



Me recordó un sitio ya clásico en el mundo java:
http://java-source.net/



Este sitio recopila frameworks en general y los agrupa por funcionalidad, si aún no lo tienen en su delicious, ya se están tardando ;)

---
RuGI

domingo, 27 de abril de 2014

Dime que haces.







Algo que aprendí en mis años de consultoría es que, algunas veces, puedes sobrellevar una relación con un cliente difícil explicándole de una manera digerida: Qué es lo que haces durante las 10/12 horas que estás en su oficina, y sobre todo cómo "eso" le ayuda a su trabajo/puesto/empresa.



Algunas personas que me conocen saben bien que, hasta dónde recuerdo, siempre he preferido las peluquerías/barberías sobre las "estéticas", y si bien tenía preocupación de que desaparecieran en esta ciudad, la Condesa surge como último bastión de estos locales al tener 3 en una sola calle.



Este comentario viene a colación ya que, justamente el fin de semana que me cortaba en cabello con mi peluquero de confianza, éste por razones diplomáticas (y quizá hasta financieras) ese día daba albergue a un joven estilista en su local.

En lo que yo recibía el servicio, este joven estilista recibía a una señora que se dejo a bien atender; el joven no paraba de explicarle a la señora cada paso que daba en su ejecución:

  • "Ahora voy a hacer un corte estilo X", 
  • "Este peine se usa de esta manera....", 
  • "para su tipo de cabello es preciso tomar en cuenta que..."
  • "No, esto no pueden ser llamados -rayos- yo les llamaría..."
  • "La tendencia hoy en día es el degradado californiano, debe saber."

Algo que aprecio de una barbería es justamente el dialogo en silencio, ese asentar(en su 9a acepción) con la cabeza del servicio recibido y sobre todo : poder entrar y salir sin decir una sola frase (ejercicios de silencio les llama el budismo).

El punto es que.... a pesar de esto último, tuve empatía con su estrategia. ^.^

La señora salió más que agradecida del lugar, y reconoció la labor del joven ante el dueño del local.

No me convenció de cambiar las sobrias tijeras de mi peluquero por un novedoso diálogo "masajeado" con las últimas tendencias del cabello, pero sí me recordó que, en buena parte, la confianza (ya sea en una persona, producto o servicio), se basa en una buena comunicación.

Así que, la próxima ves que les toque un cliente difícil, procuren generar empatía y (en la medida de lo posible) compartan con él un poco de "las tripas" de lo que hacen.

Quién quita y hasta se interesan. 
¿No creen?
^.^


viernes, 18 de abril de 2014

WELD-001408 o no se deja deployar.

Hace unos días requería deployar una aplicación web:
  • Spring 3.2.4.RELEASE 
  • WildFly 8.0.0.FINAL
  • jdk 1.7.0_21
El escenario era: la aplicación se logra desplegar correctamente en un Weblogic 12c y en otros app servers pero, no en WildFly.

La excepción que aparecería tenía como causa raíz lo siguiente:

"WELD-001408: Unsatisfied dependencies for type Injector with qualifiers @Default"

Revisando en los foros mencionan que la causante es la notación: javax.inject, o, dicho de otra manera la implementación del CDI: Contexts and Dependency Injection for the Java EE Platform, WildFly 8, Weblogic, Glassfish y otros utilizan una misma implementación llamada: Weld y, revisando su FAQ, encontramos que ya tienen registrado el problema y ofrecen una solución.

La solución tiene dos alternativas, modificar la configuración de todo el servidor para las aplicaciones que se despliegue sobre el asuman ya una versión específica de WELD (esto se hace entrando en modo consola =jboss-cli.sh=  y ejecutando la línea que indican):

/subsystem=weld:write-attribute(name=require-bean-descriptor,value=true)

La otra alternativa es, agregar al META-INF/ de cada aplicación un archivo llamado: jboss-all.xml para que realice esta configuración,

<jboss xmlns="urn:jboss:1.0">
    <weld xmlns="urn:jboss:weld:1.0" require-bean-descriptor="true"/>
</jboss>


Dado que el protocolo de casa es afectar lo menos posible, utilicé esta opción y, la aplicación desplegó sin problemas. (eah!!)

El CDI es lo "nuevo" que nos ofrece JEE desde la versión 6 (Java EE 6 platform) y que promete implementar todas esas cosas útiles que Spring nos acostumbró a utilizar (recordemos que ya estamos en la versión JEE7, pero, esta feature es aún -nueva- para muchos).

[Oracle] Why is Java EE 6 better than Spring
[Spring] Why using Spring instead of JEE6?
[StackOverflow] Java EE 6 vs. Spring 3

Buen fin de semana para todos!!!
---
RuGI