Tabla mutante: (y eso como se come?)

Que tal gente tecnologica!

Una tabla en estado mutante es cuando la tabla de base de datos se encuentra en un estado intermedio entre actualizada y no actualizada. Es verdad que eso no interesa nada cuando uno trabaja con sentencias SQL desde una aplicacion normal que hace commit regularmente, pero que pasa cuando tenemos una lógica de datos que requiere consultar datos en ese preciso instante de la mutación.

Este problema comunmente lo encontramos en los trigger, generalmente cuando requerimos updatear un valor basandonos en datos almacenados en la misma tabla que estamos mutando. Es evidente que este problema requiere un poco de ingenio, pudiendo utilizar una tabla temporal que se consulte/updatee antes y despues de tal transacción.

Este fenómeno pasa evidentemente cuando no se ha realizado correctamente el análisis de la aplicación, porque se puede desplazar fácilmente tal evaluación a la lógica de negocio antes de que aparezca el conflicto en la capa de datos.

Si tienen alguna otra solución posteenlo aquí, yo también are lo mismo …

Saludos

 

Más alla del XMLHttpRequest

Hola gente.

A decir verdad he visto mucha documentación sobre el uso de JavaScript y la técnica de usar Ajax, pasando por los distintos framework y demás historias, pero la verdad es que no he visto información sobre el porque se usa Ajax si los procesos de un simple click hacen mucho con poco esfuerzo.

La verdad es que se reduce a un simple sentido practico: mejorar la experiencia de usuario frente a las esperas de descarga del servidor (accion -> reacción). Ajax pretende mejorar la experiencia de usuario ofreciendo de una forma anticipada la siguiente posible solicitud de descarga. En lineas generales mejoran la ‘espera blanca’ que implica un request de una etiqueta <a />. Alli tenemos a google maps, una aplicacion que resultaria muy pesada al usuario si de antemano no se trabajara con mapas descargados en background.

Ya han quedado atrás los dias de las conexiones con modems de 56k, aunque algunos los mencionan pero la verdad es que ya es impensable hacer aplicaciones aceptables para esos tipos de enlaces. Las aplicaciones Ajax hacen uso del tiempo muerto del usuario para hacer cosas logicamente correctas.

En próximos post hablare de algunas aplicaciones y la explicacion del uso logico de su Motor Ajax

Saludos

 

Sistemas distribuidos

Que tal gente tecnológica.

Hoy les hablare de los sistemas distribuidos, reconozco que esta fue una cátedra que me dieron a entender cuando estudiaba en la universidad pero que como cosa rara se quedo obsoleta a raíz de los cambios tecnológicos presentes, asíque tratare de resumirlo lo mejor posible.

Se entiende por sistema todo aquello que captura, procesa y remite algo (es lo mas básico) ahora distribuido que será? pues involucra la comunicación de dos o mas sistemas. es muy simple: sistemas independientes que ayudan.

Todo sistema esta contenido por otro sistema mayor (como una súper clase), por ello hay que saber que sistema son los que estamos separando. Por regla general los sistemas evolucionan y mueren de forma independiente por ello es que es buena opción distribuir los sistemas.

No siempre los sistemas distribuidos se refieren a sistema de red, incluso en una misma maquina pueden existir dos sistemas distribuidos, en tiempos pasados cuando los equipos de computación eran costosos se tenia un solo computador en donde se gestionaba mas de un sistema.

Hoy en día los equipos informáticos resultan muy económicos y el uso de redes se ha extendido como una forma de aligerar cargas de procesamiento de datos y todas las mejoras que conlleva, es decir se han separado físicamente los sistemas que antes eran monolíticos, pesados e inmantenibles en el tiempo.

Los sistemas distribuidos ya se sobrentiende como sistemas que utilizan la red como norma general.

Pero como hacen uso estos sistemas de la red? fácil: todo sistema como lo he dicho capta, procesa y entrega resultados. Por ello es que el resultado de un sistema es la materia prima del otro. Si tenemos nociones de sistemas esto resulta fácil: dos sistemas interdependientes. Lo complicado es escoger el medio de comunicación.

Existe en el mercado muchos medios de comunicar dos sistemas (o mas), por ello debemos de elegir según la calidad de dicho enlace en función de los sistemas involucrados. Existen sistemas síncronos y asíncronos y sistemas móviles y estáticos, también existen sistemas de soporte de carga de proceso y sistemas de procesamiento paralelo. Es decir existen varios tipos de sistemas que en función de su convivencia requerirán un tipo de enlace con el otro sistema (o sistemas claro).

En los sistemas síncronos resulta mejor el envío de mensajes sin estado permanente, y los sistemas asíncronos resulta conveniente la comunicación por medio de enlaces mas o menos permanentes. Por regla general cuando hablamos de sistemas con una sola dirección hablamos de sistemas síncronos (acción->reacción), son los comúnmente encontrados en procesamiento de datos, cliente-servidor, etc. Los sistemas asíncronos nos referiríamos a clustering, procesamiento en paralelo, etc. es decir un sistema dividido en varias partes. Es aquí donde entra nuestra definición de un sistema distribuido.

Cuando es un sistema distribuido y cuando es una comunicación entre sistemas? ya lo tenemos asíncrono y síncrono. Que tipo de conexión recomiendo a cada uno? pues eso depende de los gustos, los sistemas síncronos utilizan mensajes en colas, los webservice resultan una forma económica y muy extendida entre multiplataformas. En cuanto a los sistemas distribuidos siempre recomendare enlaces básicos independientes de la plataforma. Una comunicación por socket será mejor que una comunicación DCOM/CORBA y a su vez mejor que RMI, pero como lo he dicho, depende del gusto del consumidor. Porque por regla general cuando distribuimos un sistema (clustering) lo programamos usando un mismo lenguaje, por compatibilidad entre metodología, gestión de concurrencia, orquestación de módulos, etc. Con clustering se habla mucho de sistemas críticos que por lo general hacen uso de NOS comunes por aquello de la persistencia en la red, sistemas de control de servidores, enlaces, asociación de grupos, etc. son dos mundos completamente distintos que la gente sin conocimiento se refiere a ambos de la misma manera: síncronos y asíncronos.

Saludos y hasta la próxima.

 

Bases de Datos: Servicio de red

Hola que tal gente!

Hoy les hablare de los servidores de base de datos, hay muchos que al escuchar este termino ya saben de antemano que estamos hablando de servidores SQL, que para sacar datos hay que hacer select * from tabla y con eso ya tenemos la vida resuelta. Pero la verdad es que desde la óptica de un programador de aplicaciones funcionales, acostumbrado a los Diagramas FD, E-R, etc. esto resulta un poco complejo aunque parezca mentira … El separar la lógica de datos de la lógica de aplicación es un poco extraño para los que estamos acostumbrados a ver los datos como parte de la aplicación y no a la aplicación como cliente de red.

Pues ese es el secreto: la información son datos de la red y como tal son manejados y administrados como cualquier otro servicio de red tal como el servicio de ficheros, servicios de envío y recepción de mail, etc. Nuestras aplicaciones son clientes (front – end) del servicio de datos.

Antes del advenimiento de los servidores de base de datos, la información era almacenada en ficheros que almacenaban la información más o menos de forma coherente y accesible por nuestra aplicación, luego se vio la necesidad de “abrir” la exclusividad y aparecieron gestores de base de datos que de una u otra forma nos liberaban de la gestión de esos ficheros y reducían un poco la carga de trabajo de generación de informes atípicos, programación de aplicaciones utilitarias y otras cositas comunes para la época. Como ven es un proceso que ha llegado en la actualidad a separar completamente los datos que antes eran exclusivos del programa, de la aplicación que los gestionaba, he allí el lío de los sistemas actuales vistos con la óptica antigua.

Muchos programadores de la vieja data aun no son capaces de poder aceptar que la aplicación que se programa no es exclusiva para los datos y que los datos son independientes de la aplicación. Es decir se ha reemplazado los servidores de archivos (los que compartían los ficheros de sus datos por la red) por los servidores de base de datos.

Hoy en día los servidores de base de datos y sus correspondientes clientes de administración son capaces de ofrecer lo que antes se hacia por medio de aplicaciones (reindexar, copias de seguridad, informes, etc.). Las aplicaciones se han hecho más pequeñas y menos imprescindibles por este motivo (hasta por excel podemos descargar datos del servicio de base de datos).

Así que señores de la vieja escuela aceptemos: nos han quitado la exclusividad sobre los datos, las aplicaciones existirán pero son clientes de red que insertan, modifican y eliminan datos, ya no es nuestra responsabilidad el mundo y la gestión de los datos, eso es responsabilidad del servicio de red que nombramos. Las tareas de despachar datos, se programan en el servicio de base de datos y no en la aplicación cliente, se puede utilizar los comandos típicos de consulta y también podemos usar nuestros comandos personalizados (SP), también podemos usar vistas y muchas cosas más para aplicar los principios de administración de servicios de red.

Recordemos separar la capa de datos del resto de la aplicación, porque como es obvio son dos tecnologías diferentes y así nos ira mejor en el momento de programar nuestra moderna aplicación ligera.

Saludos y hasta la próxima.

 

batch y crones: Pequeños pero cumplidores

Hola gente curiosa.

Hoy les hablare de esos programitas de procesamiento tan básicos pero tan útiles para los sistemas que son comúnmente conocidos como procesos por lotes o simplemente batch y sus usos modernos.

Estos programitas interesantes tienen una historia muy larga y datan de los primeros intentos de la programación de computadoras. Muchos programas antiguos eran programados como batch, en donde indicabas un parámetro y te entregaba un resultado. Por ejemplo el ‘dir‘ del MS-DOS puede ser interpretado como proceso batch si literalmente lo vemos como un programa que lee información del disco y luego de procesar, organizar, corregir el resultado y lo muestra. Pero el ‘dir‘ no lo podemos catalogar así si metemos el factor humano como por ejemplo cambio de parámetros del comando, elección del directorio de trabajo, etc.

Un batch es un proceso no interactivo que hace cosas sin la supervisión humana en el momento de su ejecución. Comúnmente se utilizan para procesar grupos grandes de ficheros que sea necesario extraerle información de forma determinada, para procesar de forma externa datos de una base de datos, para hacer envíos de email de forma automática, generar reportes, etc.

Los batch son muy útiles para tareas de administración de sistemas y para tareas de automatización de procesos que es en donde tiene verdadera significación. Comúnmente los batch se combinan con aplicaciones de control de horario/ejecución para generar lo que se conoce como crones o tareas programadas.

Ahora la pregunta: Que son crones? pues eso batch programados dentro de un sistema de ejecución horaria. Por ejemplo si tenemos un batch que envía por email un listado de ficheros, podremos programarlo para que se envíe a una determinada hora, eso hará que el factor humano desaparezca.

Este tipo de programitas útiles se suelen encontrar en sistemas basados en UNIX, por su simplicidad de ejecución a nivel de comandos. No es común encontrarlos en sistemas basados en ambiente grafico, porque el factor humano estará casi siempre presente.

Para expandir un poco el tema les comentare que todo sistema en determinadas circunstancias encuentra errores y el batch no es la excepción. Por regla general los batch utilizan mensajes para indicar el estado de ejecución, esa es la única forma de indicarle a un supervisor su estado actual, el resultado de ejecución, etc.

Por lo general los batch deben de cumplir hasta el final su cometido y comunicar lo que no han podido realizar, eso indicara al administrador del sistema que hay cosas por atender que no se ha completado con el batch. También los batch deben de tener una forma de recuperación a un estado previo, para poder recuperar los ‘malos pasos del programa‘. Es común programar los batch con sistema de rastreo de ejecución como ficheros de log o mensajes por consola, todo ello para poder tener un control de ejecución y evaluación del sistema en momentos posteriores de ejecución.

Espero que este resumen te sea de utilidad.

Saludos

 

PHP Paginas orientadas a objeto?

Que tal gente!

Esta es la primera entrega de una serie de evaluaciones, criticas y recomendaciones sobre este lenguaje de programación tan conocido por aquellos que nos movemos en el mundo de la Internet desde hace ya tiempo.

El primer punto que quiero recordar a aquellos que no lo saben o lo evitan saber, es que PHP en su versión 5, ha mejorado significativamente en su abstracción al paradigma que manejan los grandes lenguajes de programación actuales: la orientación a objetos.

Ahora con PHP 5 podemos crear objetos con cualidades de seguridad de acceso a métodos, herencia, etc. Ahora bien mi critica: que hará una página lineal con tanta complejidad? Si el lenguaje como tal es sumamente útil como lo fue en su versión 4 porque cambiar? La verdad es que el programador no esta en la obligación de programar con clases, de hecho PHP es un lenguaje híbrido que combina las dos metodologías según la conveniencia del problema. Mi recomendación en lo personal es el usar los objetos cuando la reutilización del código sea la prioridad, cuando se reconozca que agrupando fenómenos y usos en objeto se puede mejorar significativamente la coherencia del problema, del resto la simplicidad de los procedimientos no justifica tal inversión de esfuerzo humano. Por ejemplo que utilidad tengo yo al utilizar objetos cuando mi principal objetivo sea el de imprimir una tabla proveniente del servidor SQL. La verdad que ninguna, el llevar este problema tan fácil de resolver con unas cuantas funciones generará mas inconvenientes que mejoras, a no ser que quiera agrupar mas funcionalidades a esos datos lo que implicaría complejizar el acceso a las páginas y hacerme el diseño mas diferente de lo que lo he manejado en estas cuatro versiones anteriores de PHP.

Al parecer PHP quiere competir contra Java / ASP.Net en ese sentido (reutilización de plantillas de diseño) y la verdad es que no puede aun. La experiencia adquirida por la comunidad de desarrolladores PHP lo hace muy difícil para poder ser una competencia contra esas tecnologías con más tiempo de experiencia profesional. PHP nació como simples script de servidor y asi ha sido toda su vida, eso es lo que lo ha hecho en una buena opción para combinar con otras tecnologias que no tienen tan desarrollada esa simplicidad.

Bueno en fín PHP apuesta por la orientación a objetos como una alternativa más no como un camino claramente obligado.

Saludos y hasta la próxima!