lunes, 2 de junio de 2014

Eliminar sesiones bloqueantes en Oracle

En estos días tuve que lidiar con ciertos procesos en lote que al fallar causaban bloqueos en tiempo de ejecución debido a la falta de un commit o rollback dependiendo del punto de vista claro. A continuación dejo un script que me fue útil para revertir tales bloqueos teniendo en cuenta que se conoce a priori el nombre de la tabla bloqueada involucrada.




           
--1. Obtener el o los ID's del objeto tabla probablemente bloqueado:

SELECT object_id FROM dba_objects WHERE object_name='USUARIO';

--2. Obtener los valores SID para el o los ID's recuperados en el paso 1:

SELECT sid FROM v$lock WHERE id1 IN (74590,75456) 

--3. Obtener los valores de sesion usando los SID's recuperados en el paso 2:

SELECT sid, serial# from v$session where sid in (67,72,131,132,198,11)

--4. Matar sesiones bloqueantes en la tabla usando pares 'sid,serial#' del paso 3:

ALTER SYSTEM KILL SESSION '11,1202'
ALTER SYSTEM KILL SESSION '67,2405'
ALTER SYSTEM KILL SESSION '72,972'
ALTER SYSTEM KILL SESSION '131,1847'
ALTER SYSTEM KILL SESSION '132,1598'
ALTER SYSTEM KILL SESSION '198,16041'


Espero les sea de utilidad.

sábado, 24 de mayo de 2014

Obtener el IP cliente con java en un esquema HA, con proxy o balanceador de carga

Eventualmente, se puede usar el comando servletRequest.getRemoteAddr() para recuperar la direccion IP del cliente que accede a nuestra aplicación java web de la siguiente manera:

 
   String ipAddress = request.getRemoteAddr();


Pero, si el usuario se conecta via un servidor proxy (ya sea de software o hardware) o en un esquema de alta disponibilidad considerando un balanceador de carga, el código original devolvera el ip del balanceador, router o proxy, no el ip del cliente original conectado.



Para resolver este problema, se debe recuperar la direccion IP del encabezado de la peticion HTTP mas conocida como “X-Forwarded-For (XFF)“ De la siguiente manera:

            
   //el cliente esta conectandose a traves de algun otro equipo?
   String ipAddress = request.getHeader("X-FORWARDED-FOR");  
   if (ipAddress == null) {  
    ipAddress = request.getRemoteAddr();  
   }


Hasta la próxima!

jueves, 22 de mayo de 2014

Configurar Jasper Reports 5 en JBoss EAP como módulo

En esta última semana tuve que resolver un problema de dependencia para poder usar el componente Jasper Reports 5 en el servidor JBoss EAP 6 instalado en Red Hat, en mi escenario ya estaba configurado el jasper como modulo sin embargo se usaba una versión anterior a la requerida por mi aplicación (específicamente la 3) lo cual desencadenaba errores al querer ejecutar los reportes del nuevo site. Por lo cual procedí a modificar la carpeta del módulo anterior ya configurado a fin de elevar la version del Jasper, primero se debe bajar el servicio del jboss con el comando en la terminal service jboss-as stop como root claro despues localize la carpeta del módulo del jasper en la siguiente ubicación /opt/jboss6/jboss-eap-6.0/modules/JasperReport3/main/


Copie todos los archivos jar necesarios en la carpeta main antes descrita a fin de que pueda levantar el Jasper Reports 5, la carpeta quedo con los siguientes archivos (dar click en la imagen para ampliar):


Luego de copiar los archivos antes descritos se debe modificar el archivo module.xml que es finalmente en el que se configuran las dependencias en los JAR del módulo, evidentemente antes en este archivo se encontraba direccionado el jar del Jasper Reports 3 y sus dependencias por lo cual solo tuve que actualizar este documento ahora referenciando a los nuevos componentes del Jasper Reports 5 copiados anteriormente.


Luego de modificar y guardar el archivo module.xml iniciamos nuevamente el servicio con el comando en la terminal service jboss-as start como root y ya podemos usar el Jasper Reports 5 en nuestro servidor.

Si desean bajar la carpeta main completa la dejo comprimida en el siguiente enlace del drive. Espero les sea de ayuda. Hasta la próxima!

lunes, 5 de mayo de 2014

Configurar pool de conexiones en JBoss EAP


El siguiente post es referido a configurar un pool de conexiones usando el servidor de aplicaciones JBoss y variables JNDI, primero indicar que este tipo de variables nos ayudan a recuperar configuraciones del mismo entorno del servidor lo que hace mas segura y configurable a nuestra aplicacion web, por ejemplo conexiones de base de datos, URL's de web services, conexiones LDAP, etc, etc.

Primero añadimos la variable JNDI de conexion (datasource) en el servidor en la pestaña profile y la opción Datasources damos click en add, llenar los campos según sea su motor de base de datos, en mi caso use oracle y quedo como se muestra la imagen (click en la img si se desea ampliar):



Una vez configurado el datasource procedemos a activarlo con el boton enable despues de seleccionarlo y testear la conexion en la pestaña Connection de la parte inferior del detalle de la configuración.



En la clase de nuestra aplicación que recupera la conexion debemos importar dos paquetes referidos al uso de variables JNDI que son javax.naming.Context y javax.naming.InitialContext luego podemos recuperar el datasource JNDI en nuestro codigo de la siguiente manera:
 
            
Connection cn = null;
try {
 Context ctx = new InitialContext();
 DataSource ds = (DataSource) ctx.lookup("java:jboss/ConfigSistemita");
 cn = ds.getConnection();

} catch (SQLException e) {
 System.out.println(e.toString());
 cn = null;
} catch (Exception e) {
 System.out.println(e.toString());
 cn = null;
}
return cn;


Hasta la próxima!

martes, 25 de marzo de 2014

Cuida tu vista regulando el color de pantalla con f.lux



Nunca pensé sentir tanta tensión en la visión por mirar pantallas luminosas durante todo el día. En algún momento de mi vida incluso pensé que mis jóvenes ojos eran invencibles. Luego, ya hace como 3 años, empecé a tener dolores de cabeza agudos al final de cada día acompañados de fastidios como aquellos en los que te entra algo casi microscópico debido al viento, finalmente decidí medirme la vista, hace un mes presente los mismos síntomas y tuve que cambiar la medida de los lentes por segunda vez,  me di cuenta de que además de mis lentes necesitaba cambiar algo adicional.



Decidí finalmente dar un cambio y empecé a googlear  y encontré a f.lux es una aplicación que cambia la temperatura de color de la pantalla, la adaptación de la luz que se ve a la hora del día, lo que ayuda a reducir la fatiga en la vista. Hay una nueva versión beta que trae algunas mejoras realmente útiles.

Por la mañana y por la tarde, verá la luz de color azul la cual la pantalla normalmente empuja hacia fuera. Cuando se pone el sol, la luz cambiará a un color más rojizo, y cuando cae la noche, va a convertirse en una luz aún más profunda de color rojo. Cada paso que el color es adaptable, así que usted puede decidir la intensidad del color.

Es normal ver a la luz azul durante el día, pero a medida que se vuelve más oscuro, esa luz fastidia en los ojos por su intensidad. La luz rojiza es más soportable en los ojos, sobre todo por la noche, es por eso que se utilizan las luces rojas para preservar la visión nocturna.


Para cualquier persona que pasa horas detrás de una pantalla, f.lux es una aplicación obligatoria a mi parecer. Pasamos un montón de tiempo y dedicamos mucho esfuerzo en asegurarnos que utilizamos teclados ergonómicamente correctos, sillas y escritorios para nuestra postura, así que creo que es tiempo de que demos a nuestros ojos un nivel similar de tratamiento. Hasta la próxima.

domingo, 23 de marzo de 2014

El impacto de explicar a los clientes el diseño web mutidispositivo

Cuando entras a una reunión con un cliente, debemos mentalizarnos casi como visitantes del futuro. Nosotros, como profesionales web, pasamos días inmersos en los nuevos paradigmas de la web multidispositivo. Sin embargo, incluso para nosotros, el cambio y los ajustes que vienen con la vida en Internet son constantes y pueden resultar en retos abrumadores. Entonces, ¿cómo creemos que se sienten nuestros clientes?

La web actual debe ser fluida e implica cambios rápidos, agiles y repentinos. Nuestros procesos para trabajar con ella y con nuestros clientes tienen la necesidad de reflejar eso. Es hora de que nos despojemos de los vestigios mentales que hemos heredado de antiguas aplicaciones para poder construir nuevos sistemas basados en la honestidad, la inclusión y la comunicación genuina. Debemos ofrecer a nuestros posibles clientes el servicio y el proceso de inmediato, permitiéndoles ver y detectar todas las fallas, mejoras y baches en el camino. A través de esta relación se convertirán en verdaderos socios al aprender a navegar mejor en este extraño y evolucionando universo digital juntos.



La perspectiva lo es todo

Cuando nuestros clientes primero piensan en un sitio web, la imagen mental que evocan es probable que sea la de un navegador web en una computadora de escritorio. Esto es completamente comprensible, después de todo, la mayoría de sus experiencias de sitios web se producen mientras están sentados en sus escritorios, experimentando continuamente en la comodidad de sus sillas.

Desde donde estamos sentados nosotros, sin embargo, vemos la web como compuesta de muchos más dispositivos. Hasta hace poco, ha sido conveniente pensar que aquellos dispositivos son solo "smartphones", "tablets " y "laptops". Pero a medida que más dispositivos y más variados han entrado en el mercado, los cubículos digitales se han multiplicado y desbordado, a manera de una aglomeración de tamaños de pantalla, resoluciones, navegadores, sistemas operativos, convenciones, y las posibilidades de la interfaz.

Esto ha requerido una revisión en nuestro pensamiento. En lugar de sitios web es una serie de construcciones perfectas prestadas en cada pantalla en detalle exigente, los diseñadores web han comenzado a pensar en términos de sistemas complejos. La flexibilidad se ha convertido en una moneda más valiosa que la especificidad.



Si sus clientes siempre han sido parte de un proyecto de diseño tradicional antiguo, esto no es lo que estarán esperando encontrar en sus reuniones. Entonces, ¿cómo comenzamos a cerrar esta brecha? ¿De qué manera ayudamos a nuestros clientes a comenzar a ver el Internet a través de nuestras gafas de diseñador web? Por amor de Dios, ¿cómo les podemos hablar de esto?

Haga de sus comentarios un bucle

La granularidad de la retroalimentación del cliente debe coincidir con el nivel de detalle de la entrega que están viendo. Echemos un vistazo a una reacción común:

    Cliente: Hmm . La maqueta se siente un poco vacía de lo que pensé que haría.

    Yo: En el documento de especificaciones nos dijo que quería que fuera a la vez sofisticado y limpio. Tal vez esto no es suficientemente sofisticado?

    Cliente: Eso suena bastante bien. ¿En qué piensas?

    Yo: No estoy exactamente seguro de lo que parece, pero yo creo que las interacciones y banners que crearemos más tarde serán una oportunidad de tener más información en el website. ¿Por qué no vemos lo que podemos hacer ahora , tal vez revisemos el esquema de color para ser más enérgicos, entonces a ver qué podemos hacer para animar las cosas una vez que tengamos la versión desplegada. ¿Le parece bien?

    Cliente: Sí! Vamos a hacerlo.

Usted debe ajustar las cosas hasta que el cliente este de acuerdo en que estemos  lo suficientemente cerca de lo ideal. Recuerde: cada solicitud del cliente para una revisión es en realidad una petición de una conversación. Mi respuesta predeterminada a cualquier cambio es, " ¿Por qué?". Ayude a su cliente a centrarse en el "por qué ", y recordarles que averiguar el "cómo" es su responsabilidad. Centrándose en el "por qué" le ayuda a abordar la raíz del problema.

Ahora podemos empezar

Tomarse el tiempo para ayudar a nuestros clientes a entender los desafíos que enfrentamos y el papel que van a jugar en nuestro proceso que hace que sean más fáciles de comunicar y trabajar con ellos. Incluso le ayudará a construir la confianza en usted, a fortalecer su relación, y confiar más plenamente en su equipo para este y futuros proyectos. Hasta la próxima.

lunes, 10 de marzo de 2014

Aplicando la estrategia mobile offline first ante la frustración de la desconexión

Cuando se trata de la creación de aplicaciones, a menudo asumimos que nuestros usuarios son muy parecidos a nosotros. Nosotros los imaginamos con los últimos dispositivos, el software más reciente, y las conexiones más rápidas. Para esto debemos tener una variedad de dispositivos(o al menos emuladores) y navegadores antiguos para las pruebas, pasamos la mayoría de nuestro tiempo de construcción desde la comodidad de nuestros dispositivos de escritorio modernos, siempre en línea.



Para nosotros, un error de conexión o servicio lento es un problema temporal en la red de telefonía o wifi el cual es rutinario. Desde esta perspectiva, se tiene la tentación de pensar en la conectividad, móvil o de otro modo, como algo que se resolverá por sí mismo con el tiempo, a medida que una mayor cobertura de la red y un servicio más rápido. Y eso funciona, siempre y cuando nuestros usuarios a mantenerse por encima del suelo en grandes y muy modernas ciudades bien desarrolladas, pero este no es el caso siempre.

Pero, ¿qué sucede una vez que suben en el metropolitano o al tren eléctrico, a bordo de un avión, en un viaje por tierra, o ir a visitar el campo? O cuando se paran en la esquina con menos cobertura de un edificio o simplemente se encuentran como parte de una gran multitud? Nuestras aplicaciones con UX cuidadosamente construidas se convierten en fuentes de frustración, porque confiamos tan
plenamente en ese enlace que irá supuestamente de nuevo a nuestros servidores.

Esta dependencia hace caso omiso de una verdad fundamental: Desconectado es simplemente un hecho de la vida. Si usted usa un móvil, usted estará desconectado en algún momento. Sin embargo. Hay maneras de tratar con este hecho.

Como encontrar el balance de conexión?

Las aplicaciones web solían ser completamente dependiente del servidor que hace todo el trabajo , y el cliente sólo muestra el resultado. Cualquier interrupción en la conexión era un problema importante : si usted se encontraba desconectado, no podía usar la aplicación.

Ese problema se resuelve, en parte, por los clientes más ricos, donde más de la lógica de la aplicación se ejecuta en el navegador como google docs (actualmente google drive), por ejemplo. Pero para una experiencia adecuada de offline first, también se desea almacenar los datos en la parte front, y si se desea que se sincronice con el almacén de datos del servidor. Felizmente, las bases de datos en el navegador están madurando, y hay un número cada vez mayor de soluciones para esto como derby.js, Lawnchair, hoodie, firebase, remotestorage.io, sencha touch entre otros- los cuales resuelven los aspectos técnicos
cada vez de manera más fácil.

Pero tenemos problemas más grandes y mucho más raros: el diseño de las aplicaciones y sus interfaces de conectividad intermitente conducen a una gran cantidad de nuevos escenarios, problemas y errores que debemos controlar dependiendo del negocio.

La experiencia de uso de un sitio web o aplicación sin conexión debe ser mucho mejor, menos frustrante y de más potencia. Necesitamos el equivalente UX de diseño de páginas web sensibles : un fuerte catálogo de guías y patrones para un mundo multidispositivo desconectado. Pues actualmente el usuario final no solo se conecta desde su móvil sino también desde la PC o tablet.



Entendiendo el ciclo de vida de la conectividad

La mayoría de las aplicaciones web tienen dos puntos de conexión relacionados de fracaso los cuales son:
el envío desde el cliente y la recepción del cliente (llega a ser equivalente a demanda de servidor).
Dependiendo de lo que hace su aplicación, es posible que el usuario final desee 3 cosas:

1. Comunicar u ocultar explícitamente el estado de conectividad y sus cambios (por ejemplo, en un cliente de chat sería informar a los usuarios que los nuevos mensajes escritos no se envían inmediatamente).

2. Permitir la creación del lado del cliente y funciones de edición, incluso cuando la aplicación se encuentre fuera de línea, y tranquilizar a los usuarios que sus datos están seguros y eventualmente se enviarán hacia al servidor (pensar en una aplicación para compartir fotos que le permite tomar y publicar fotos en cualquier circunstancia).

3. Deshabilitar, modificar, o incluso ocultar características que no pueden trabajar fuera de línea, en lugar de dejar que la gente las vea y no las pueda usar (imagine un botón de "enviar" que se transforme en un botón "enviar al recuperar la conexión").



A fin de ayudarnos entre sí y también a futuras generaciones de diseñadores, desarrolladores y expertos en interfaces de usuario (UX), te invitamos a unirte a la discusión en offlinefirst.org. La meta futura es la de crear un manual en línea que incluye los patrones UX y anti-patrones, las opciones de tecnología, y la investigación sobre el usuario. Hasta la próxima!