06.01.09
Posted in Arquitectura, Patrones at 11:28 pm by Miguel
En la sección de patrones de diseño inauguramos los patrones de Ajax, con la descripción del patrón: Refresco Periódico.
El patrón viene a describir la solución a un problema común y que parte de una de las principales limitaciones de la soluciones web, la uni-direccionalidad de la relación cliente-servidor. La parte cliente es la que siempre toma la iniciativa ante cualquier transacción, por lo que si en las situaciones en las que queremos mostrar un aviso de cuándo un proceso de cálculo complejo que se ha lanzado de forma asíncrona ha terminado, o cuando por ejemplo a los usuarios autenticados en nuestra aplicación queremos mostrarles un aviso de que se ha recibido stock de un determinado producto, no tenemos más remedio que utilizar diferente estrategias, siempre por parte del cliente, para “engañar al usuario”.
Una de las soluciones a este típico problema es el uso del Patrón del Refresco Periódico, que a grandes rasgos consiste en realizar llamadas periódicas a través de ajax al servidor, para ir solicitando el refresco del estado de la información que necesitamos consultar. Como al utilizar ajax la página no se refresca de forma completa, la experiencia de usuario da como resultado algo bastante similar a lo que puede aportar una aplicación de escritorio.
Más información en http://ajaxpatterns.org/Periodic_Refresh
Saludos.
Miguel.
Permalink
11.28.08
Posted in AgilePoint, Arquitectura, BPM, Servicios Web, WCF, Web at 12:53 pm by Miguel
En un artículo anterior hablábamos de la autenticación con AgilePoint y la surrogación. Echaba en falta algún gráfico que dejara algo más clara la forma de trabajar, así que lo adjunto en esta segunda parte.
Esquema Surrogate
Como véis, se aprecian las tres combinaciones de las que se habla en la primera parte.
- Opción A: Usuario a través de un navegador web, el servidor web tiene que impersonar al usuario llamante.
- Opción B: Usuario a través de aplicación de escritorio que trabaja contra una capa de servicios, el servidor de negocio tiene que impersonar al usuario llamante.
- Opción C: Usuario a trvés de aplicación de escritorio que trabaja directamente con servicios de AgilePont, no hace falta impersonación, el propio usuario pertenece al dominio y se autentica directamente con sus credenciales de red.
Pocos artículos últimamente. Mucho trabajo.
Saludos!
Miguel.
Permalink
10.17.08
Posted in .NET, Arquitectura, Herramientas, Programación, Software, WCF at 8:22 pm by Miguel
Recientemente he tenido la oportunidad de participar en una presentación de Solid RAD, la herramienta para el desarrollo rápido de aplicaciones, ofrecida bajo el sello y garantía de calidad del equipo de Solid Quality Mentors
Jesús López y Daniel Seara (con el cual he tenido nuevamente el placer de coincidir) han sido los dos mentores de Solid que realizaron la presentación de forma conjunta.
A partir de la propia arquitectura y orientación de Solid RAD, la cual podréis conocer consultando el video provisto en el siguiente enlace mms://solidq.com/SolidRad (copiar el link y ejecutar pegando en la barra de dirección de Internet Explorer), destacar la inmensa oportunidad que supone compartir durante parte de una mañana, y de forma directa y personalizada, de los conocimientos y opiniones de los dos mentores. Lo que ha dado una pequeña “discusión” sobre el uso de las transacciones es algo que me gustaría exponer en un próximo artículo. A mi la visión me ha parecido genial.
Destacar entre otras cosas de Solid RAD, otras ideas fantásticas, como las de partir de un modelo de objetos de negocio para exponer el conocimiento a otras capas, pero sin orientar el modelo de objetos directamente a las entidades de datos, tal como haría un ORM, si no a las vistas definidas sobre dichas entidades de datos. Es una idea simplemente genial combiándola al mismo tiempo con el generador de código de Solid RAD, que automatiza la generación de las entidades de transporte de datos a partir de las propiedades de cada una de las vistas sobre la que es accedida.
Saludos.
Miguel.
Permalink
10.02.08
Posted in Arquitectura, Bases de Datos, Metodologías, Software at 8:09 pm by Miguel
[Actualizado a 05/10/2008]
A continuación os planteo un típico problema de modelo entidad-relación en base de datos, en el que se debe modelar una situación bastante común en un desarrollo de software. Os pediría que intentarais resolver el problema sin ver antes las tres soluciones que marco al “ejercicio” en la parte final del post, y comprobar así finalmente cuál ha sido el tipo de solución más habitual. Os agradecería además que razonarais la respuesta. En el caso de que vuestra solución no se ajuste a ninguna de las tres descritas, por favor, enviadme un diagrama a info@miguelmatas.es para que pueda adjuntarla al artículo. Sería estupendo además que en el razonamiento de vuestra solución no se limitara a las razones estríctamente del modelo y la base de datos, si no que estuviera acompañada de algún razonamiento relacionado con arquitectura de software, orientación al negocio, eficiencia a nivel de datos, protección del dato, etc. En el caso de que no queráis “perder” tanto tiempo, me doy por satisfecho si contestáis al post indicando si vuestra solución se acerca a una de las tres primeras o ha sido otra 
Gracias!
Enunciado:
Una conocida empresa de Rent a Car quiere informatizar su sistema de gestión de vehículos. En esencia, dicha empresa alquila de forma temporal los coches de los que dispone, y, en un primer proceso de ingeniería necesita contar con una descripción técnica de cómo se almacenarían el repositorio de los diferentes coches con los que cuenta en cartera.
La empresa cuenta con diferentes tipos de coches, son realmente los tipos de coches que maneja lo que la diferencia de los Rent a Car al uso, ya que los usuarios tienen la oportunidad de alquilar coches anfibios, coches voladores y coches oficiales blindados. Estos tres tipos de coche tienen algunas características en común que se desean conocer, como son la matrícula, el número de puertas y la marca. Además, de forma específica se necesita conocer el máximo de nudos a la hora a la que puede navegar un coche anfibio, los milímetros de blindaje y el tipo de blindaje de un coche oficial blindado, y la autonomía de horas de vuelo con las que cuenta un coche volador.
Posibles soluciones de modelado entidad-relación:
Os pediría por favor que no consultarais las soluciones hasta que hayáis desarrollado vuestra propia solución, para así no interferir en el resultado.
Solución 1
Solución 2
Solución 3
Solución 4 [nuevo 05/10/2008]
Saludos y gracias
Miguel.
Permalink
09.09.08
Posted in Arquitectura, Buenas Prácticas, Web at 11:03 pm by Miguel
En posts anteriores hablamos ya alguna vez del Principio de KISS. Hoy toca un ejemplo práctico. Últimamente no paro de cruzarme con situaciones en las que el principio resulta una premisa básica. Para qué complicarse cuando hay soluciones sencillas y facilmente mantenibles que cumplen el requerimiento funcional suficientemente y hacen que el cliente obtenga su objetivo.
Como ejemplo, un botón, no sé si disponéis de una cuenta de Gmail, si es así, podréis comprobar que en las opciones de un e-mail tenéis la de imprimirlo. Hay miles de formas diferentes de provocar una impresión desde web, y la que ha elegido Google es la siguiente:
1) Al pulsar sobre el botón de imprimir se abre una ventana emergente y se carga el texto relacionado al e-mail más información básica de las direcciones implicadas, además aparece también en la parte superior el logo de Gmail
2) A continuación, tras la carga, se lanza una sentencia javascript que provoca que en el cliente se lance el cuadro de diálogo de selección de impresora.
3) El cliente selecciona la impresora y se imprime el contenido actual.
Ala fin. Así de simple. Si quieres imprimir un e-mail, lo imprimes sin problemas, que ese era tu objetivo.
¿Para qué complicarse más?
Saludos.
Miguel.
Permalink
05.20.08
Posted in Arquitectura, Gestión de Proyectos at 10:53 pm by Miguel
Navaja de Occam
La navaja de Occam (navaja de Ockham o principio de economía o de parsimonia) hace referencia a un tipo de razonamiento basado en una premisa muy simple: en igualdad de condiciones la solución más sencilla es probablemente la correcta.
Principio Fundamental de KISS
El principio KISS es aquel que recomienda el desarrollo empleando partes sencillas, comprensibles y con errores de fácil detección y corrección, rechazando lo enrevesado e innecesario en el desarrollo de sistemas complejos en ingeniería.
Este término es un acrónimo que corresponde a la frase en inglés ”Mantenlo simple, estúpido” (Keep It Simple, Stupid). Para evitar ser tosco, el acrónimo se hace corresponder con otras expresiones tales como “Manténgalo breve y simple” (“Keep It Short and Simple”) u otras similares, pero que mantienen la misma idea del principio.
Ambas descripciones han sido extraidas de Wikipedia.
Saludos.
Miguel.
Permalink
05.08.08
Posted in Arquitectura, Bases de Datos, Programación at 11:28 pm by Miguel
En muchas aplicaciones suele ser común que existan conjuntos de datos que cambien muy poco o nada a lo largo del tiempo. Por ejemplo, si almacenamos en nuestra base de datos tablas con Países, Provincias, Comunidades Autónomas… lo más seguro es que los registros que conformen la tabla no varíen en el tiempo o si lo hacen sean cambios totalmente excepcionales.
Si esto es así e imaginando el típico formulario web donde tenemos que seleccionar un desplegable con provincias, podría resultar ineficiente hacer una consulta a base de datos por cada carga del formulario que realizaran los distintos usuarios de la aplicación. ¿Para qué vamos a consultar otra vez la base de datos si podemos asegurar en un 99% que no habrán cambiado? Sobre todo teniendo en cuenta que el acceso a base de datos suele ser de lo que más penaliza el rendimiento de una aplicación.
Una buena idea sería que en según que métodos de nuestra capa de acceso a datos, antes de realizar una consulta directa a una tabla, comprobáramos si los datos ya se han almacenado en entidad física mucho más rápida de acceder que la base de datos, por ejemplo, en una caché. Inicialmente esta caché estaría vacía, en la primera carga se rellenaría a partir de la información de la base de datos, y el resto de veces ya se atacaría siempre a la memoria cache.
El resultado, claramente es un tiempo de respuesta mucho más bajo en cada transacción de este tipo.
¿Algún ejemplo con pseudo-codigo?
public Lista<ProvinciaDTO> GetProvincias()
{
if (IsVacio(CacheProvincias))
{
CacheProvincias = RellenaConAccesoATablaProvincias();
}
return TransformaCacheEnLista(CacheProvincias);
}
Como véis sólo rellenaremos la caché de provincias con los datos de la tabla si la caché está vacía, si no lo está, directamente retornaremos los datos desde la caché.
En el pseudo-código no se están resolviendo temas de concurrencia (cómo resolver si dos usuarios al mismo tiempo comprueban si está vacío y da verdadero), y se abstrae 100% la solución propia de cómo cachear precisamente para hacerlo independiente de la tecnología en que queráis aplicar el método.
Otro tema interesante que podrían incorporarse, es la posibilidad de que la caché caduque, es decir, que no se almacene la información en la caché de forma infinita mientras la aplicación no se reinicie, si no que se establezcan periodos temporales en los como máximo la caché será renovada. Por ejemplo si tenemos una tabla que almacene Marcas puede que nos interese que se reuneve la caché cada 24 horas ya que almenos una vez al día se añade una marca nueva (me lo estoy inventando obviamente, es por dar un ejemplo). Si ante la petición de un usuario se comprueba que la caché está caducada, esta se vaciaría y se volvería a rellenar de forma automática tras una consulta a la tabla correspondiente de la base de datos.
¿Interesante?
Saludos.
Miguel.
Permalink
05.02.08
Posted in .NET, Arquitectura, Eventos, Servicios Web at 9:38 am by Miguel
El próximo jueves 8 de mayo se va a producir un evento on-line por parte de Microsoft relacionado con la Arquitectura Orientada a Servicios.
La descripción del evento es la siguiente:
“Uno de los temas más polémicos en los últimos tiempos en Arquitectura de Software es la orientación a servicios, y cómo esto mejora la agilidad, flexibilidad y el rehúso de mis soluciones. En esta sesión, nos enfocaremos en la orientación a servicios desde una perspectiva de arquitectura de software, analizaremos cómo un enfoque orientado a servicios difiere de arquitecturas basadas en objetos y componentes, así como también la discusión de algunos retos organizacionales que se experimentan al adoptar una arquitectura orientada a servicios”
Muy interesante a priori, el único problema es que para poder verlo en directo tendréis que estar delante del ordenador de 11 a 12 de la noche… O esperar más adelante a que pongan a disposición la grabación para ver el vídeo off-line.
Mas información y suscripción al evento Aquí
Un saludo.
Miguel.
Permalink
04.18.08
Posted in Arquitectura at 11:59 pm by Miguel
Para los que les llame la atención los temas relacionados con la arquitectura de software, hoy cambiamos un poco el tema de las arquitecturas en varias capas, de la que hemos hablado bastante en este blog, para presentar otra arquitectura diferente, la Arquitectura en Pizarra.
Me limito a dejar el link a la descripción de Wikipedia (ha sido una semana complicada), da una pincelada suficiente, sin profundizar, al menos para que nos hagamos un poco a la idea de su funcionamiento.
http://es.wikipedia.org/wiki/Arquitectura_en_pizarra_%28inform%C3%A1tica%29
Saludos.
Miguel.
Permalink
« Previous Page — « Previous entries « Previous Page · Next Page » Next entries » — Next Page »
