Cookies, cookies, cookies... (¿Qué es una Cookie?)

Las cookies son pequeños bits de informacion textual, que un servidor web (o un contenedor de aplicaciones) envía a un navegador cliente para identificarlo; el navegador luego retorna esa informacion (esos bits de informacion textual) cuando se visita nuevamente ese sitio web o dominio. Haciendo que el servidor lea informacion que se le había enviado previamente a un cliente, la aplicación web puede proveer a sus visitantes, con unas cuantas conveniencias que se describen a continuación:

Identificar a un usuario durante una sesión de comercio electrónico:
Si alguna vez te pusiste a curiosear Amazon.com, o alguna otra tienda en linea, ya sabrás sobre la metáfora del carrito de compras (Shopping Cart) que se puso tan de moda con el "e-Commerce", en el que el usuario selecciona un ítem, lo añade a su carrito, y sigue comprando, justo como cuando se visita el super mercado.
Como las conexiones HTTP se cierran luego de que cada pagina se envía (HTTP es Stateless), cuando el usuario selecciona un nuevo ítem para su carrito, ¿como sabe la tienda que el es ese mismo usuario que puso el ítem anterior en su carrito?... simple, con las cookies.
Es mas, las cookies son tan útiles que los Java Servlets tienen API especifico para manejarlas.

Evitar autenticarte constantemente:
Muchos sitios web grandes, requieren que te registres para utilizar sus servicios (Twitter, SlideShare, Facebook, Yahoo! Mail, etc), seria muuuuuy inconveniente, cada vez que el usuario realiza una acción (cambiar de pagina por ejemplo) preguntar constantemente el usuario y la contraseña a un usuario si ya se autentico al ingresar por primera vez. Las cookies se utilizan como parte de una solución (de baja seguridad) en la cual, se le puede dar informacion de autenticación al usuario (ID, llave de identificación, tiempo que vive la sesión, etc, nunca las contraseñas o números de tarjetas de crédito) luego de que este ingreso correctamente al sistema, luego cuando el usuario realiza una acción en el sitio, esta informacion se envia al servidor y este busca esa identificación para determinar si pertenece a ese usuario y si esta autenticado correctamente.

"De vez en cuando es bueno borrar las cookies."

Personalizar un sitio:
iGoogle es un ejemplo perfecto de la personalización de un sitio. iGoogle, entre otras cosas, usa una cookie para "recordar" que widgets le agregaste, cuantas pestañas tienes, etc...

Publicidad personalizada:
Un motor de búsqueda, como Google, puede mantener una pista de las preferencias de un usuario a lo largo del tiempo, de esta forma, la publicidad que se le muestra a ese usuario, estará enfocada a sus preferencias de busqueda. Esa es la magia de AdSense, AdWords, y de la infame cookie de Google.

"Un mundo Google nos vigila."

Proveer características convenientes a los usuarios y valor añadido al dueño del sitio es el propósito de las cookies. Y a pesar de algunos individuos paranoicos, las cookies no son una amenaza seria (por si mismas) a la seguridad de los usuarios finales.

Consideraciones sobre la seguridad de las cookies:
Las cookies no se "interpretan" o ejecutan en un sistema, por lo que no se puede insertar virus en ellas para comprometer la integridad de un sistema. Los navegadores generalmente solo aceptan 20 cookies por sitio, además un navegador nunca poseerá más de 300 cookies en total, y cada cookie esta limitada a un tamaño de 4 KB, así que no se pueden usar para llenar el disco duro de un cliente (especialmente con el tamaño de los discos duros modernos).

"300 cookies... 1 usuario."

Sin embargo, aunque las cookies no presentan una amenaza a la seguridad, si pueden presentar una seria amenaza a la privacidad. Pero más que culpa de la cookie en si, los problemas de privacidad radican en programadores con practicas poco seguras (como meter informacion de tarjetas de crédito en una cookie, ese SI que es un problema).

Dos consejos finales. Por los problemas reales que comprometen la privacidad de los usuarios, estos algunas veces deshabilitan las cookies. Así que si una cookie te da valor agregado a tu sitio, este no debe de depender totalmente de las cookies para funcionar. Y el segundo, es que los programadores de servlets que usan cookies, deben de ser cuidadosos para no almacenar informacion extremadamente importante (como: NUMERO DE TARJETAS DE CRÉDITO!!!) en las cookies.

Para más informacion sobre las cookies, puede visitar la Wikipedia , tambien Java Tips (usar una cookie de una JSP) y Cookie Central.

¡Saludos!

cookies programar java

Cookies, cookies, cookies... (¿Qué es una Cookie?)

Las cookies son pequeños bits de informacion textual, que un servidor web (o un contenedor de aplicaciones) envía a un navegador cliente para identificarlo; el navegador luego retorna esa informacion (esos bits de informacion textual) cuando se visita nuevamente ese sitio web o dominio. Haciendo que el servidor lea informacion que se le había enviado previamente a un cliente, la aplicación web puede proveer a sus visitantes, con unas cuantas conveniencias que se describen a continuación:

Identificar a un usuario durante una sesión de comercio electrónico:
Si alguna vez te pusiste a curiosear Amazon.com, o alguna otra tienda en linea, ya sabrás sobre la metáfora del carrito de compras (Shopping Cart) que se puso tan de moda con el "e-Commerce", en el que el usuario selecciona un ítem, lo añade a su carrito, y sigue comprando, justo como cuando se visita el super mercado.
Como las conexiones HTTP se cierran luego de que cada pagina se envía (HTTP es Stateless), cuando el usuario selecciona un nuevo ítem para su carrito, ¿como sabe la tienda que el es ese mismo usuario que puso el ítem anterior en su carrito?... simple, con las cookies.
Es mas, las cookies son tan útiles que los Java Servlets tienen API especifico para manejarlas.

Evitar autenticarte constantemente:
Muchos sitios web grandes, requieren que te registres para utilizar sus servicios (Twitter, SlideShare, Facebook, Yahoo! Mail, etc), seria muuuuuy inconveniente, cada vez que el usuario realiza una acción (cambiar de pagina por ejemplo) preguntar constantemente el usuario y la contraseña a un usuario si ya se autentico al ingresar por primera vez. Las cookies se utilizan como parte de una solución (de baja seguridad) en la cual, se le puede dar informacion de autenticación al usuario (ID, llave de identificación, tiempo que vive la sesión, etc, nunca las contraseñas o números de tarjetas de crédito) luego de que este ingreso correctamente al sistema, luego cuando el usuario realiza una acción en el sitio, esta informacion se envia al servidor y este busca esa identificación para determinar si pertenece a ese usuario y si esta autenticado correctamente.

"De vez en cuando es bueno borrar las cookies."

Personalizar un sitio:
iGoogle es un ejemplo perfecto de la personalización de un sitio. iGoogle, entre otras cosas, usa una cookie para "recordar" que widgets le agregaste, cuantas pestañas tienes, etc...

Publicidad personalizada:
Un motor de búsqueda, como Google, puede mantener una pista de las preferencias de un usuario a lo largo del tiempo, de esta forma, la publicidad que se le muestra a ese usuario, estará enfocada a sus preferencias de busqueda. Esa es la magia de AdSense, AdWords, y de la infame cookie de Google.

"Un mundo Google nos vigila."

Proveer características convenientes a los usuarios y valor añadido al dueño del sitio es el propósito de las cookies. Y a pesar de algunos individuos paranoicos, las cookies no son una amenaza seria (por si mismas) a la seguridad de los usuarios finales.

Consideraciones sobre la seguridad de las cookies:
Las cookies no se "interpretan" o ejecutan en un sistema, por lo que no se puede insertar virus en ellas para comprometer la integridad de un sistema. Los navegadores generalmente solo aceptan 20 cookies por sitio, además un navegador nunca poseerá más de 300 cookies en total, y cada cookie esta limitada a un tamaño de 4 KB, así que no se pueden usar para llenar el disco duro de un cliente (especialmente con el tamaño de los discos duros modernos).

"300 cookies... 1 usuario."

Sin embargo, aunque las cookies no presentan una amenaza a la seguridad, si pueden presentar una seria amenaza a la privacidad. Pero más que culpa de la cookie en si, los problemas de privacidad radican en programadores con practicas poco seguras (como meter informacion de tarjetas de crédito en una cookie, ese SI que es un problema).

Dos consejos finales. Por los problemas reales que comprometen la privacidad de los usuarios, estos algunas veces deshabilitan las cookies. Así que si una cookie te da valor agregado a tu sitio, este no debe de depender totalmente de las cookies para funcionar. Y el segundo, es que los programadores de servlets que usan cookies, deben de ser cuidadosos para no almacenar informacion extremadamente importante (como: NUMERO DE TARJETAS DE CRÉDITO!!!) en las cookies.

Para más informacion sobre las cookies, puede visitar la Wikipedia , tambien Java Tips (usar una cookie de una JSP) y Cookie Central.

¡Saludos!

cookies programar java

Deprecated Code (Codigo Obsoleto)

Todo programador, se habrá (debería?) de encontrar mas de alguna vez con este termino: Deprecated (Obsoleto).

Y este termino es especialmente frecuente al usar frameworks, que de tan "robustos y seguros", ya se estarán volviendo obsoletos en si mismos. Un excelente lugar donde encontrar código marcado como obsoleto, es utilizando metodos viejoss en un framework "nuevo", por ejemplo, llamar metodos del JDK 1.4 en el JDK 1.6.

Este "atributo" (Obsoleto) que se le da al código fuente, se especifica cuando una clase, función o API ha perdido su importancia, y tiene tan poca importancia que no debería de ser usada en lo absoluto, y probablemente deje de existir en un futuro cercano.

"Java Doc que muestra una función marcada como 'Deprecated' (Obsoleta)"

La necesidad de marcar una función, clase, API... código en general, como obsoleto, surge del desarrollo natural del código, para adaptarse constantemente a las nuevas tecnologías, mejoras de lógica, etc...

Supongamos que tienes una librería muy popular, y cada 3 meses liberas una versión nueva. Y en cada versión nueva, añades funcionalidad adicional y modificas metodos, y reescribes otros. Como tu librería es muy popular, tienes que mantener cierta compatibilidad con las versiones anteriores, y por esa razón tienes que mantener código viejo... porque tienes que darle tiempo a los developers que migren su código y comiencen a usar las novedades que has añadido a tu código. Y claro, tu no quieres que los developers sigan usando los metodos antiguas, que solo mantienes por motivos de compatibilidad, entonces la solución, es marcar el metodo, clases, o código en general, como obsoleto. ¿Útil no?

"¿Cuantos developers tendrán el 'honor' de marcar como obsoleto el codigo de alguien más?"

Como ven, la actividad de marcar clases, métodos, etc... como obsoleto, resuelve muchos problemas. Las clases existentes que usan el API antiguo continúan trabajando bien, pero el compilador reconoce y avisa sobre los elementos marcados como obsoletos.
Además, marcar el código fuente como obsoleto, es una responsabilidad que todo BUEN programador debe asumir, especialmente: cuando se trabaja en equipo, y cuando muchos developers usan el código que tu haces...

"Un buen programador, siempre se hace responsable del código que escribe."

En Java la etiqueta @deprecated, marca como obsoleto el código que le sigue, vean el Java API Documentator Generator (JavaDoc) para más información sobre como usar esta etiqueta en su código. Y claro no solo esta la etiqueta @deprecated, también esta el tipo de "annotation" Deprecated. Y finalmente les comparto esta útil página, que tiene información de "Cuando y Como" marcar como obsoleto el codigo fuente.

Y tu, ¿alguna vez has marcado código fuente como obsoleto?

UPDATE: Por una importante sugerencia de Xtecuan, se renombraron todas las incidencias de la palabra "funcion" por "metodos".

coding programming programacion javadoc java deprecated obsoleto

Deprecated Code (Codigo Obsoleto)

Todo programador, se habrá (debería?) de encontrar mas de alguna vez con este termino: Deprecated (Obsoleto).

Y este termino es especialmente frecuente al usar frameworks, que de tan "robustos y seguros", ya se estarán volviendo obsoletos en si mismos. Un excelente lugar donde encontrar código marcado como obsoleto, es utilizando metodos viejoss en un framework "nuevo", por ejemplo, llamar metodos del JDK 1.4 en el JDK 1.6.

Este "atributo" (Obsoleto) que se le da al código fuente, se especifica cuando una clase, función o API ha perdido su importancia, y tiene tan poca importancia que no debería de ser usada en lo absoluto, y probablemente deje de existir en un futuro cercano.

"Java Doc que muestra una función marcada como 'Deprecated' (Obsoleta)"

La necesidad de marcar una función, clase, API... código en general, como obsoleto, surge del desarrollo natural del código, para adaptarse constantemente a las nuevas tecnologías, mejoras de lógica, etc...

Supongamos que tienes una librería muy popular, y cada 3 meses liberas una versión nueva. Y en cada versión nueva, añades funcionalidad adicional y modificas metodos, y reescribes otros. Como tu librería es muy popular, tienes que mantener cierta compatibilidad con las versiones anteriores, y por esa razón tienes que mantener código viejo... porque tienes que darle tiempo a los developers que migren su código y comiencen a usar las novedades que has añadido a tu código. Y claro, tu no quieres que los developers sigan usando los metodos antiguas, que solo mantienes por motivos de compatibilidad, entonces la solución, es marcar el metodo, clases, o código en general, como obsoleto. ¿Útil no?

"¿Cuantos developers tendrán el 'honor' de marcar como obsoleto el codigo de alguien más?"

Como ven, la actividad de marcar clases, métodos, etc... como obsoleto, resuelve muchos problemas. Las clases existentes que usan el API antiguo continúan trabajando bien, pero el compilador reconoce y avisa sobre los elementos marcados como obsoletos.
Además, marcar el código fuente como obsoleto, es una responsabilidad que todo BUEN programador debe asumir, especialmente: cuando se trabaja en equipo, y cuando muchos developers usan el código que tu haces...

"Un buen programador, siempre se hace responsable del código que escribe."

En Java la etiqueta @deprecated, marca como obsoleto el código que le sigue, vean el Java API Documentator Generator (JavaDoc) para más información sobre como usar esta etiqueta en su código. Y claro no solo esta la etiqueta @deprecated, también esta el tipo de "annotation" Deprecated. Y finalmente les comparto esta útil página, que tiene información de "Cuando y Como" marcar como obsoleto el codigo fuente.

Y tu, ¿alguna vez has marcado código fuente como obsoleto?

UPDATE: Por una importante sugerencia de Xtecuan, se renombraron todas las incidencias de la palabra "funcion" por "metodos".

coding programming programacion javadoc java deprecated obsoleto

La importancia de los procedimientos almacenados

En esta ocasión, me quiero concentrar en algo muy importante del inmenso mundo (y misterioso para algunos) de las bases de datos, quiero hablarles de: Los Procedimientos Almacenados.
Los procedimientos almacenados (conocidos también como proc, sproc, stopro, o SP's por sus siglas en Ingles) son subrutinas que están disponibles para las aplicaciones que acceden a una base de datos relacional. Los procedimientos almacenados están, como su nombre lo indica, almacenados en el diccionario de datos de la base de datos.

¿Para que existen?, ¿para que usarlos, si puedo tener mis consultas bien bonitas metida en mi código (como consultas SQL Ad-hoc)? Esas preguntas exactas me hice yo hace algunos años. Que pena ser tan ingenuo. Gracias a Dios desperté de ese "lapsus ..." y si bien, no lo se todo, lo que se, lo tengo que compartir.

El uso más típico de los SP (de ahora en adelante asi me estaré refiriendo a ellos, en vez de escribir Procedimientos Almacenados) es proveer una validación integrada en la base de datos, asi como proveer mecanismos de control de acceso a la misma.

Los SP son usados para consolidar y centralizar lógica que originalmente se implementaba en las aplicaciones.

Eso quiere decir, que en vez de tener una "clase", con una lista interminable de funciones que hacen esto:

static function String getConsultaUsuario(String usuarioid) {
 return "SELECT * FROM user WHERE userid = '" + usuarioid +"'";
}

...usted debería de tener una serie SP en su gestor de bases de datos, implementado como un API "consolidado y centralizado" (en la base de datos). Lo mismo sucede con muchas consultas SQL "grandes", o secuenciales: no podemos dejarlas regadas en el codigo, necesitamos moverlas a un solo lugar...

"MySQL también tiene procedimientos almacenados"

¿Por que? bien, enumerare solo algunas razones:

• El mantenimiento de las consultas SQL es mas sencillo, porque las consultas SQL están centralizadas en el gestor.
• La seguridad se enriquece utilizando SP's, debido a que un buen DBA (Administrador de Bases de Datos) únicamente proveerá una lista de procedimientos (bien tipificados y documentados) que el programador llamara de acuerdo a sus necesidades. Asi, relevamos al programador de preocuparse de verificar que los INSERT, DELETE, etc... estén "bien", lo aliviamos de la "carga" de manipular directamente la base de datos. Y dejamos esa lógica en donde debe de ir: en el gestor.
• Suponga que debe añadir una condición extra a la función de ejemplo "getConsultaUsuario", tendrías que cambiar la cadena que se retorna en la función, probar los cambios, compilar o publicar tu aplicación. Los SP se pueden modificar, sin necesidad de recompilar y hacer un deploy completo de la aplicación.
• Y lo más importante de todo, los procedimientos almacenados SIEMPRE serán más rapidos que una consulta externa. Si no lo son, es por dos motivos: a) No puedes escribir procedimientos almacenados, y/o b) El gestor de base de datos que estas usando es deficiente.

Entonces podemos observar dos ventajas inmediatas: Reducir la carga de mantenimiento de código SQL, y aumentar la velocidad de la aplicación.
La desventajas: Nos estaremos amarrando al gestor, y más de algún programador probablemente saltara por no poder "tocar" (manipular) directamente los datos en la BD. Esto no es necesariamente malo, pero más de alguno protestará.

Tengo que aclarar que no hay usar SP absolutamente todo el tiempo y en toda aplicación a desarrollar. Un caso practico para implementar SP en una aplicación, es en el que se tiene una sola base de datos, y diferentes módulos o clientes que se conectan constantemente a esta. ¿Se imaginan tener una lista de consultas en cada modulo o cliente que se conecta?, ¿Y si se modifica la base de datos?, ¿cuantas consultas y en cuantos lugares lo iremos a modificar?

"Los SP son parte de la Alquimia de SQL que usted debe conocer"

Los SP en general, serán realmente útiles (y aplicables) en caso de estar desarrollando aplicaciones robustas, de categoría empresarial, o para servicios que deben ser seguros, que posean alta disponibilidad y con vistas a ser escalables.

¿Y dónde aprendo, donde veo ejemplos, etc? ... como siempre, Google tiene la respuesta.
¿Y tú, estas utilizando Procedimientos Almacenados en tu Software?

La importancia de los procedimientos almacenados

En esta ocasión, me quiero concentrar en algo muy importante del inmenso mundo (y misterioso para algunos) de las bases de datos, quiero hablarles de: Los Procedimientos Almacenados.
Los procedimientos almacenados (conocidos también como proc, sproc, stopro, o SP's por sus siglas en Ingles) son subrutinas que están disponibles para las aplicaciones que acceden a una base de datos relacional. Los procedimientos almacenados están, como su nombre lo indica, almacenados en el diccionario de datos de la base de datos.

¿Para que existen?, ¿para que usarlos, si puedo tener mis consultas bien bonitas metida en mi código (como consultas SQL Ad-hoc)? Esas preguntas exactas me hice yo hace algunos años. Que pena ser tan ingenuo. Gracias a Dios desperté de ese "lapsus ..." y si bien, no lo se todo, lo que se, lo tengo que compartir.

El uso más típico de los SP (de ahora en adelante asi me estaré refiriendo a ellos, en vez de escribir Procedimientos Almacenados) es proveer una validación integrada en la base de datos, asi como proveer mecanismos de control de acceso a la misma.

Los SP son usados para consolidar y centralizar lógica que originalmente se implementaba en las aplicaciones.

Eso quiere decir, que en vez de tener una "clase", con una lista interminable de funciones que hacen esto:

static function String getConsultaUsuario(String usuarioid) {
 return "SELECT * FROM user WHERE userid = '" + usuarioid +"'";
}

...usted debería de tener una serie SP en su gestor de bases de datos, implementado como un API "consolidado y centralizado" (en la base de datos). Lo mismo sucede con muchas consultas SQL "grandes", o secuenciales: no podemos dejarlas regadas en el codigo, necesitamos moverlas a un solo lugar...

"MySQL también tiene procedimientos almacenados"

¿Por que? bien, enumerare solo algunas razones:

• El mantenimiento de las consultas SQL es mas sencillo, porque las consultas SQL están centralizadas en el gestor.
• La seguridad se enriquece utilizando SP's, debido a que un buen DBA (Administrador de Bases de Datos) únicamente proveerá una lista de procedimientos (bien tipificados y documentados) que el programador llamara de acuerdo a sus necesidades. Asi, relevamos al programador de preocuparse de verificar que los INSERT, DELETE, etc... estén "bien", lo aliviamos de la "carga" de manipular directamente la base de datos. Y dejamos esa lógica en donde debe de ir: en el gestor.
• Suponga que debe añadir una condición extra a la función de ejemplo "getConsultaUsuario", tendrías que cambiar la cadena que se retorna en la función, probar los cambios, compilar o publicar tu aplicación. Los SP se pueden modificar, sin necesidad de recompilar y hacer un deploy completo de la aplicación.
• Y lo más importante de todo, los procedimientos almacenados SIEMPRE serán más rapidos que una consulta externa. Si no lo son, es por dos motivos: a) No puedes escribir procedimientos almacenados, y/o b) El gestor de base de datos que estas usando es deficiente.

Entonces podemos observar dos ventajas inmediatas: Reducir la carga de mantenimiento de código SQL, y aumentar la velocidad de la aplicación.
La desventajas: Nos estaremos amarrando al gestor, y más de algún programador probablemente saltara por no poder "tocar" (manipular) directamente los datos en la BD. Esto no es necesariamente malo, pero más de alguno protestará.

Tengo que aclarar que no hay usar SP absolutamente todo el tiempo y en toda aplicación a desarrollar. Un caso practico para implementar SP en una aplicación, es en el que se tiene una sola base de datos, y diferentes módulos o clientes que se conectan constantemente a esta. ¿Se imaginan tener una lista de consultas en cada modulo o cliente que se conecta?, ¿Y si se modifica la base de datos?, ¿cuantas consultas y en cuantos lugares lo iremos a modificar?

"Los SP son parte de la Alquimia de SQL que usted debe conocer"

Los SP en general, serán realmente útiles (y aplicables) en caso de estar desarrollando aplicaciones robustas, de categoría empresarial, o para servicios que deben ser seguros, que posean alta disponibilidad y con vistas a ser escalables.

¿Y dónde aprendo, donde veo ejemplos, etc? ... como siempre, Google tiene la respuesta.
¿Y tú, estas utilizando Procedimientos Almacenados en tu Software?

Si no estas usando un framework...

Si no estas usando un framework para desarrollar software, probablemente estés re-inventando la rueda. La única validez que tiene el proceso de "re-inventar la rueda" es para conocer como funciona. Pero si te están pidiendo elaborar un sistema realmente amplio para una empresa, con una cobertura del 70% de las operaciones, y esa empresa NO se dedica a realizar software... entonces es una seria estupidez desarrollar software sin un framework.

"Cuidad, si re-inventas la rueda, podrías terminar así..."

Un framework, es una estructura de soporte definida mediante la cual, se desarrolla y organiza lógicamente una pieza de software. Entonces, el programa, modulo o sistema en cuestión, se apoya en un framework (en el marco de trabajo) para ser desarrollado. Un framework incluirá soporte para generar programas, una serie de librerías organizadas en módulos lógicos, y un lenguaje (que se ejecuta en una maquina virtual usualmente) para ayudar a desarrollar y unificar los módulos que conformen el proyecto.
El uso de un framework, es tan obligatorio en un proyecto de grandes magnitudes, como lo son las típicas practicas de desarrollo de software:

• Unit Testing
• Code Coverage
• MVC
• Version Control
• Automated Deployment

Para los estudiantes, o novatos en el tema, permitanme dar un sencillo ejemplo:
Imaginemos por un breve momento, que se quiere construir (de acuerdo a un plano) una casa de dos plantas, para tres personas, con cochera y jardín.
Este es el problema:

construir la casa de acuerdo a las especificaciones (del plano), construirla en un tiempo planificado y con la mayor eficiencia posible.

Bien, hay un par de caminos que podemos tomar, el primero consiste en:
1. Comprar ladrillos, cemento, arena, pintura, tejas, piso cerámico, defensas, hierro, contratar mano de obra calificada, comenzar la construcción....

"Niiiiceee...."

Al menos, eso es lo lógico, ¿no? Son los pasos "normales", lo "sano".
La misma lógica es aplicable al mundo del software.... sin embargo, existen personas que rechazan esta "linea de pensamiento" y cometen errores que en el contexto del ejemplo anterior, seria:

2. Construir la casa, desde CERO (literalmente), de manera que vamos a inventar nuestro propio cemento, pintura, techo, defensas, pisos. Vamos a usar herramientas que no estamos seguros si las vamos a aprovechar y vamos a gastar en cosas completamente innecesarias... como... flamingos rosados de mármol tallados a mano importados de la India para el jardín (wtf?).

"NOT so nice. NOT AT ALL."

Y para colmo, creen que se puede realizar la casa, en el mismo tiempo que lo haría de la manera "normal". Se que para muchos lectores, esto suena ridículo, ¡¿verdad?! suena muy ridículo. Es más, seria increíble pensar, que alguien proponga soluciones así.... pero les tengo una noticia...

Este es el caso que sucede SUCEDE en las empresas, y también SUCEDE en los equipos de desarrollo.

Casi a diario, se esta perpetrando este crimen. No solo es una perdida de tiempo, sino que también es un insulto al desarrollador de software que si tiene buenas practicas (o que intenta tenerlas). ¿Saben que es lo peor? muchos cometen el error de creer que con solo usar Java o .NET (y solamente eso), ya están usando un framework suficiente para hacer un RIA (Rich Internet Application) en 3 meses. Pues déjenme decirle, que si ese fuera el caso, no existiría Spring, Struts, IceFaces, MyFaces, ASP.NET MVC, Adobe Flex, RoR, Etc...
Lo terrible es que este suceso se sigue perpetrando, y es por simple ignorancia...

"¡Que pena ser ignorante!"

Empresas, por que rayos ¿no capacitan a sus gerentes de informática?, ¿a sus arquitectos de software?, ¿a sus team leaders?, ¿Por que no escuchan las voces de los programadores, que de cara a semejantes atrocidades, alzan la voz inmediatamente y proponen el cambio?
Ya lo dije antes, pero no me molesta volverlo a repetir...

"si un equipo de desarrollo, sumergido hasta el cuello de dificultades técnicas, pretende producir software: simplemente vamos a obtener software que es REFLEJO de las dificultades, problemas, ignorancia, malos requerimientos y mala administración en los que se vio envuelto el mismo".

Instruyace, no deje de leer, no se estanque, procure estar a la par (o solo un centímetro atrás) de la tecnología, y procure, sobre todas las cosas, escuchar a sus colegas, pero a los que saben.

Pero sobre todas las cosas, por favor, si no estas usando un framework.... ya es hora de que comience a usar uno.

¿Y tu, qué frameworks usas?
frameworks desarrollo software practicas programacion ignorancia

Si no estas usando un framework...

Si no estas usando un framework para desarrollar software, probablemente estés re-inventando la rueda. La única validez que tiene el proceso de "re-inventar la rueda" es para conocer como funciona. Pero si te están pidiendo elaborar un sistema realmente amplio para una empresa, con una cobertura del 70% de las operaciones, y esa empresa NO se dedica a realizar software... entonces es una seria estupidez desarrollar software sin un framework.

"Cuidad, si re-inventas la rueda, podrías terminar así..."

Un framework, es una estructura de soporte definida mediante la cual, se desarrolla y organiza lógicamente una pieza de software. Entonces, el programa, modulo o sistema en cuestión, se apoya en un framework (en el marco de trabajo) para ser desarrollado. Un framework incluirá soporte para generar programas, una serie de librerías organizadas en módulos lógicos, y un lenguaje (que se ejecuta en una maquina virtual usualmente) para ayudar a desarrollar y unificar los módulos que conformen el proyecto.
El uso de un framework, es tan obligatorio en un proyecto de grandes magnitudes, como lo son las típicas practicas de desarrollo de software:

• Unit Testing
• Code Coverage
• MVC
• Version Control
• Automated Deployment

Para los estudiantes, o novatos en el tema, permitanme dar un sencillo ejemplo:
Imaginemos por un breve momento, que se quiere construir (de acuerdo a un plano) una casa de dos plantas, para tres personas, con cochera y jardín.
Este es el problema:

construir la casa de acuerdo a las especificaciones (del plano), construirla en un tiempo planificado y con la mayor eficiencia posible.

Bien, hay un par de caminos que podemos tomar, el primero consiste en:
1. Comprar ladrillos, cemento, arena, pintura, tejas, piso cerámico, defensas, hierro, contratar mano de obra calificada, comenzar la construcción....

"Niiiiceee...."

Al menos, eso es lo lógico, ¿no? Son los pasos "normales", lo "sano".
La misma lógica es aplicable al mundo del software.... sin embargo, existen personas que rechazan esta "linea de pensamiento" y cometen errores que en el contexto del ejemplo anterior, seria:

2. Construir la casa, desde CERO (literalmente), de manera que vamos a inventar nuestro propio cemento, pintura, techo, defensas, pisos. Vamos a usar herramientas que no estamos seguros si las vamos a aprovechar y vamos a gastar en cosas completamente innecesarias... como... flamingos rosados de mármol tallados a mano importados de la India para el jardín (wtf?).

"NOT so nice. NOT AT ALL."

Y para colmo, creen que se puede realizar la casa, en el mismo tiempo que lo haría de la manera "normal". Se que para muchos lectores, esto suena ridículo, ¡¿verdad?! suena muy ridículo. Es más, seria increíble pensar, que alguien proponga soluciones así.... pero les tengo una noticia...

Este es el caso que sucede SUCEDE en las empresas, y también SUCEDE en los equipos de desarrollo.

Casi a diario, se esta perpetrando este crimen. No solo es una perdida de tiempo, sino que también es un insulto al desarrollador de software que si tiene buenas practicas (o que intenta tenerlas). ¿Saben que es lo peor? muchos cometen el error de creer que con solo usar Java o .NET (y solamente eso), ya están usando un framework suficiente para hacer un RIA (Rich Internet Application) en 3 meses. Pues déjenme decirle, que si ese fuera el caso, no existiría Spring, Struts, IceFaces, MyFaces, ASP.NET MVC, Adobe Flex, RoR, Etc...
Lo terrible es que este suceso se sigue perpetrando, y es por simple ignorancia...

"¡Que pena ser ignorante!"

Empresas, por que rayos ¿no capacitan a sus gerentes de informática?, ¿a sus arquitectos de software?, ¿a sus team leaders?, ¿Por que no escuchan las voces de los programadores, que de cara a semejantes atrocidades, alzan la voz inmediatamente y proponen el cambio?
Ya lo dije antes, pero no me molesta volverlo a repetir...

"si un equipo de desarrollo, sumergido hasta el cuello de dificultades técnicas, pretende producir software: simplemente vamos a obtener software que es REFLEJO de las dificultades, problemas, ignorancia, malos requerimientos y mala administración en los que se vio envuelto el mismo".

Instruyace, no deje de leer, no se estanque, procure estar a la par (o solo un centímetro atrás) de la tecnología, y procure, sobre todas las cosas, escuchar a sus colegas, pero a los que saben.

Pero sobre todas las cosas, por favor, si no estas usando un framework.... ya es hora de que comience a usar uno.

¿Y tu, qué frameworks usas?
frameworks desarrollo software practicas programacion ignorancia

Pruebas de Uso (Usability Test)

Supongamos que estas trabajando en un software, por los últimos... cuatro o cinco meses. Y tienes que entregar un producto terminado en dos semanas (tu deadline es en dos semanas).
Resuelves bugs, tu código esta cubierto (Code Coverage), tu software pasa las pruebas unitarias (Unit Testing), y además, pasa las pruebas de deploy ("Deployar" como escuche mencionar alguna vez) y de pronto, algo realmente importante surge en tu mente, algo que tienes ahi en tu cráneo desde el principio...

¿Es usable mi programa?

Rayos!, esa, si que es una pregunta muy importante, no solo porque tienes que saber:

¿Quien usa mi programa? o ¿Cuanto van a usar mi programa?

... para ver si realmente lo que hiciste es útil. No, no solo es por eso. Es importante, debido a la simple y sencilla razón, de que el cliente o usuario final, es la razón, propósito y motivo ulterior por la que estas desarrollando software, y TU software (o el software que estas desarrollando) DEBE (si, DEBE) facilitar la vida del usuario final de la aplicación.

Que este sea el mantra de esta semana:

"Mi aplicación deberá facilitar la vida del usuario final."

La manera para asegurarte de que este mantra se cumpla lo máximo posible es utilizando las Pruebas de Uso. En el sentido técnico una Prueba de Uso consiste en realizar una prueba de "caja negra" a tu software. Es decir, observar a las personas que van a usar el producto, REALMENTE usándolo para descubrir errores y ÁREAS de mejora.

"Google realiza pruebas de uso, para conocer que áreas de una pagina son las que mas son 'visitadas' por el cursor (esto también es conocido como HeatMap)"

Suele ser de caja negra, porque no importa lo que hace en el fondo el sistema, sino la forma. Generalmente una prueba de uso, medirá que tan bien responden los usuarios en cuatro áreas: eficiencia, exactitud, recuerdo o familiaridad (recall), y respuesta emocional...

• Rendimiento -- ¿Cuanto tiempo y cuantos pasos se requieren para que una persona realice una tarea básica? (Ordenar Productos, Buscar, etc).
  
• Exactitud -- ¿Cuantos errores realizaron las personas? (Fueron errores fatales, recuperables, etc).
• Recuerdo-- ¿Que tan bien se recuerda el uso del programa, después de largos periodos de no utilizarlo?
  
• Respuesta Emocional -- ¿Como se siente una persona al completar una tarea? ¿Estresada, Confiada, Emocionada?

"Es necesario conocer que piensa el usuario final del software que usara"

¿Fácil no? ¿Ves a donde vamos con la implementar de una Prueba de Uso? Con estas pruebas, nos estamos asegurando que:

1. No estas perdiendo tu tiempo (Codificas lo que realmente se necesita)
2. Facilitas la vida del usuario final (Diseñar buenas GUI)
3. Tienes una retro-alimentación constante (Alimentas el proceso de desarrollo con criticas constructivas y mantienes los pies en la tierra)
4. Se mantienes una participación ACTIVA y proactiva del usuario y los developers (o el equipo de desarrollo).

Y definitivamente, es algo que quieres estar haciendo cada quince días o un mes como máximo, no es necesario que cien usuario prueben constantemente el software, uno siempre es mejor que ninguno. A continuación, les describo la mas simple Prueba de Usabilidad que se puedan imaginar:

• Eliges un usuario final (operativo, gerencia, financiero, etc)
• Se aísla al usuario, y se le presenta el software.
• Se le asigna una o un par de tareas a realizar en el sistema.
• Se observa al usuario resolviendo la tarea.
• Se pregunta al usuario que piensa de la tarea (¿cuando esta en el proceso?, ¿como cree que puede mejorarlo?)
• Cuando el usuario termina la prueba (si la termina sin que le de un ataque cardíaco, por la frustración), se le pregunta lo siguiente: ¿Como se siente con respecto a la tarea? ¿Que recuerda del proceso? etc...
• Repita el proceso, con los usuarios aislados (siempre es mejor, probar a un solo usuario, que a varios para las Pruebas de Uso) y evalué en base a los resultados de las pruebas anteriores.

En el blog de Robin Good, se puede encontrar en detalle una introducción al método "A/B Split Testing", les presento un extracto:

"A/B split testing

Por Lisa Halabi

A partir de cualquier estudio de usabilidad de sitio web, generalmente se encuentran un número de problemas de usabilidad. A menudo puede suscitarse un debate dentro de una organización para hallar la solución a cada problema, sin que nadie conozca realmente la solución óptima. En vez de dejar que prevalezca la opinión de la persona que grita más, una mejor opción puede ser probar dos soluciones en un entorno en vivo. Aquella que tenga el mejor rendimiento es claramente la solución superior. ¡Bienvenido al A/B split testing! ... click aquí para leer mas."

Aquí la clave (resaltada en negritas) es no dejar que prevalezca la opinión del que grita mas, sino la mejor opción, pero para el usuario.


Steve Krug en su libro Don't Make Me Think!, en el capitulo nueve, plantea una serie de aclaraciones sobre las Pruebas de Uso, que toda persona que este encargada de crear software debe de leer, pueden encontrar el capitulo 9 (en Ingles) de la primera edición de este genial libro dando clic aquí.

Espero, sinceramente, que la próxima vez que estén en un proyecto de software, que se preocupen constantemente, en la opinión del usuario final, final, final (el que realmente usara tu software todos los dias, para hacer su vida mas fácil). Para que de esta forma, realmente estés produciendo software enfocado al uso o a la "usabilidad".

Saludos!

prueba pruebas uso usabilidad usability test software development desarrollo practicas

Pruebas de Uso (Usability Test)

Supongamos que estas trabajando en un software, por los últimos... cuatro o cinco meses. Y tienes que entregar un producto terminado en dos semanas (tu deadline es en dos semanas).
Resuelves bugs, tu código esta cubierto (Code Coverage), tu software pasa las pruebas unitarias (Unit Testing), y además, pasa las pruebas de deploy ("Deployar" como escuche mencionar alguna vez) y de pronto, algo realmente importante surge en tu mente, algo que tienes ahi en tu cráneo desde el principio...

¿Es usable mi programa?

Rayos!, esa, si que es una pregunta muy importante, no solo porque tienes que saber:

¿Quien usa mi programa? o ¿Cuanto van a usar mi programa?

... para ver si realmente lo que hiciste es útil. No, no solo es por eso. Es importante, debido a la simple y sencilla razón, de que el cliente o usuario final, es la razón, propósito y motivo ulterior por la que estas desarrollando software, y TU software (o el software que estas desarrollando) DEBE (si, DEBE) facilitar la vida del usuario final de la aplicación.

Que este sea el mantra de esta semana:

"Mi aplicación deberá facilitar la vida del usuario final."

La manera para asegurarte de que este mantra se cumpla lo máximo posible es utilizando las Pruebas de Uso. En el sentido técnico una Prueba de Uso consiste en realizar una prueba de "caja negra" a tu software. Es decir, observar a las personas que van a usar el producto, REALMENTE usándolo para descubrir errores y ÁREAS de mejora.

"Google realiza pruebas de uso, para conocer que áreas de una pagina son las que mas son 'visitadas' por el cursor (esto también es conocido como HeatMap)"

Suele ser de caja negra, porque no importa lo que hace en el fondo el sistema, sino la forma. Generalmente una prueba de uso, medirá que tan bien responden los usuarios en cuatro áreas: eficiencia, exactitud, recuerdo o familiaridad (recall), y respuesta emocional...

• Rendimiento -- ¿Cuanto tiempo y cuantos pasos se requieren para que una persona realice una tarea básica? (Ordenar Productos, Buscar, etc).
  
• Exactitud -- ¿Cuantos errores realizaron las personas? (Fueron errores fatales, recuperables, etc).
• Recuerdo-- ¿Que tan bien se recuerda el uso del programa, después de largos periodos de no utilizarlo?
  
• Respuesta Emocional -- ¿Como se siente una persona al completar una tarea? ¿Estresada, Confiada, Emocionada?

"Es necesario conocer que piensa el usuario final del software que usara"

¿Fácil no? ¿Ves a donde vamos con la implementar de una Prueba de Uso? Con estas pruebas, nos estamos asegurando que:

1. No estas perdiendo tu tiempo (Codificas lo que realmente se necesita)
2. Facilitas la vida del usuario final (Diseñar buenas GUI)
3. Tienes una retro-alimentación constante (Alimentas el proceso de desarrollo con criticas constructivas y mantienes los pies en la tierra)
4. Se mantienes una participación ACTIVA y proactiva del usuario y los developers (o el equipo de desarrollo).

Y definitivamente, es algo que quieres estar haciendo cada quince días o un mes como máximo, no es necesario que cien usuario prueben constantemente el software, uno siempre es mejor que ninguno. A continuación, les describo la mas simple Prueba de Usabilidad que se puedan imaginar:

• Eliges un usuario final (operativo, gerencia, financiero, etc)
• Se aísla al usuario, y se le presenta el software.
• Se le asigna una o un par de tareas a realizar en el sistema.
• Se observa al usuario resolviendo la tarea.
• Se pregunta al usuario que piensa de la tarea (¿cuando esta en el proceso?, ¿como cree que puede mejorarlo?)
• Cuando el usuario termina la prueba (si la termina sin que le de un ataque cardíaco, por la frustración), se le pregunta lo siguiente: ¿Como se siente con respecto a la tarea? ¿Que recuerda del proceso? etc...
• Repita el proceso, con los usuarios aislados (siempre es mejor, probar a un solo usuario, que a varios para las Pruebas de Uso) y evalué en base a los resultados de las pruebas anteriores.

En el blog de Robin Good, se puede encontrar en detalle una introducción al método "A/B Split Testing", les presento un extracto:

"A/B split testing

Por Lisa Halabi

A partir de cualquier estudio de usabilidad de sitio web, generalmente se encuentran un número de problemas de usabilidad. A menudo puede suscitarse un debate dentro de una organización para hallar la solución a cada problema, sin que nadie conozca realmente la solución óptima. En vez de dejar que prevalezca la opinión de la persona que grita más, una mejor opción puede ser probar dos soluciones en un entorno en vivo. Aquella que tenga el mejor rendimiento es claramente la solución superior. ¡Bienvenido al A/B split testing! ... click aquí para leer mas."

Aquí la clave (resaltada en negritas) es no dejar que prevalezca la opinión del que grita mas, sino la mejor opción, pero para el usuario.


Steve Krug en su libro Don't Make Me Think!, en el capitulo nueve, plantea una serie de aclaraciones sobre las Pruebas de Uso, que toda persona que este encargada de crear software debe de leer, pueden encontrar el capitulo 9 (en Ingles) de la primera edición de este genial libro dando clic aquí.

Espero, sinceramente, que la próxima vez que estén en un proyecto de software, que se preocupen constantemente, en la opinión del usuario final, final, final (el que realmente usara tu software todos los dias, para hacer su vida mas fácil). Para que de esta forma, realmente estés produciendo software enfocado al uso o a la "usabilidad".

Saludos!

prueba pruebas uso usabilidad usability test software development desarrollo practicas