Una multitud de herramientas a las que se enfrentan ya con soltura desarrolladores web (especialmente sobre plataforma Microsoft) y para las que nadie cae ya en la dificultad inicial y conceptual que representa la pregunta: ¿dónde se ejecutan las cosas?

Pregunta que sin lugar a dudas es fundamental resolver al inicio, para formaciones orientadas a nuevos profesionales del desarrollo web, especialmente para aclarar muchos conceptos derivados del funcionamiento de ASP.NET, y su transformación/creación al vuelo de HTML, CSS y Javascript… por no hablar de temas específicos de comunicación cliente-servidor y mantenimiento del estado de la página mediante uso del ViewState, Session, etc.

Un concepto tan básico para desarrolladores ya iniciados, como que cuando entramos en una web esta no se visualiza en el “limbo”, si no que es descargada una copia en local (seguramente después de un procesado de página en el servidor web) y que lo único que hace el navegador es abrir dicha copia en local y renderizarla, no es algo que tengan tan claro los recién iniciados en este mundillo. Hay que saber contarlo y empezar por ahí, ya que con esto comenzaremos a asentar conocimientos básicos de arquitectura, del mismo modo que empezaremos a dar margen a pensar en la usabilidad y tiempos de respuesta de la página al usuario (no es lo mismo ejecutar arriba que ejecutar abajo, ni resolver problemas mediante una llamada a servidor o mediante n, ni de forma síncrona o asíncrona).

Este punto debería ser pieza clave, a la hora de comenzar el: Capítulo IV. Replicando en Web. El cual describíamos en el artículo Metodología de Formación para Nuevos Profesionales del Software

Saludos.

Miguel.

Puntualizar que la experiencia ha sido siempre lanzada utilizando como base tecnología Microsoft.NET, la cual dispone de herramientas que dan cobertura completa a los conceptos de arquitectura a trasladar, pero esto no quiere decir que este método no pueda ser aplicado utilizando otras tecnologías de cobertura completa (Java por ejemplo) o incluso en combinación de varias (bajo mi punto de vista sería el objetivo a cumplir tras la primera fase del “curso” que hoy os vamos a trasladar).

Objetivos

En el momento de finalizar el curso el alumno debe haber asentado su conocimiento sobre los siguientes conceptos

1) Entorno de desarrollo tipo
2) Desarrollo de arquitecturas orientadas a n-capas
3) Desarrollo de aplicaciones SOA
4) Buenas y malas prácticas de programación
5) Diferencias fundamentales en el desarrollo de aplicaciones web y escritorio
6) Trabajo colaborativo y en equipo
7) Importancia de las pruebas en el proceso de desarrollo
Despliegue de aplicaciones en entornos no accesibles
9) Dinámica de proyecto

Mientras que los objetivos del instructor son

1) Adaptar la formación a un escenario tipo de proyecto, el alumno desde el primer día debe entrar en la dinámica del día a día de un proyecto real
2) Identificar áreas de mejora de los alumnos, tanto técnicas como no técnicas
3) Identificar puntos fuertes y puntos de mejora del alumno
4) Identificar puntos de mejora del propio método de formación

Requerimientos Previos

Referidos a los alumnos (en orden de importancia):

1) Programación orientada a objetos
2) Definición de modelos entidad-relación
3) HTML básico

La falta de conocimiento de alguno de estos puntos, requerirá que el instructor incorpore a la formación módulos adicionales que cubran la visión necesaria al respecto.

Otros valores deseables ajenos a las capacidades técnicas

1) Pro actividad
2) Eficacia
3) Eficiencia
4) Trabajo en equipo
5) Liderazgo
6) Confianza
7) Capacidad de trabajo
Nivel de interlocución

Es labor del instructor identificar puntos de mejora también en estos aspectos, potenciándolos durante el proceso formativo. No solo estamos formando a nivel técnico, también estamos formando profesionales que van a ser parte fundamental de proyectos de desarrollo que requerirán de aptitudes no solo técnicas para lograr el éxito del proyecto.

Referidos al instructor:

1) Profesional consolidado en conocimientos de arquitectura y en la tecnología/tecnologías de desarrollo que se desarrollan en el curso.
2) Experiencia de trabajo en proyectos, habiendo participado/liderado procesos de captura de requerimientos, definición de arquitecturas y procesos de implantación/despliegue, gestión de equipos, diseños funcionales, diseños técnicos, supervisión del trabajo de otros programadores y construcción.
3) Nivel de interlocución medio-alto
4) Experiencia en sesiones formativas

En resumen y por poner un símil en consultoría, las habilidades esperadas de un Jefe de Equipo.

Bases Fundamentales de la Metodología

* Dinámica de proyecto desde el primer día
* Curso eminentemente práctico
* Grupos de formación pequeños (entre 5 y 10 alumnos máximo por instructor)
* No solo centrarse en las habilidades técnicas
* Que el alumno de el primer paso: resolver el problema de forma completa con el conocimiento actual del alumno, a medida que se vayan incorporando conceptos nuevos (a posteriori) el alumno deberá resolver de forma completa el problema adaptando su solución e incorporando los nuevos conceptos adquiridos.
* El instructor no es el protagonista

Capítulo I: Definiendo requerimientos

Todo proyecto comienza a partir de un conjunto de requerimientos, por lo que si uno de nuestros principales objetivos es introducir al alumno en la dinámica del proyecto deberemos partir de un conjunto de requerimientos base. No es objetivo de esta formación introducir al alumno en el proceso de toma de requerimientos, por lo que nos mantendremos ajenos a él. Nuestro punto de partida puede ser un pequeño documento que describa un pequeño escenario o si queremos empezar desde ya a identificar capacidades no técnicas, un pequeña conversación (poniéndose el instructor la gorra del cliente) donde se describan los requerimientos a cubrir; es aquí donde el alumno debe comenzar a tomar notas y hacerse un pequeño esquema mental de la solución. No es una toma de requerimientos en sí, ya que lo que hará el instructor será recitar verbalmente los requerimientos como si los estuviera leyendo.

Dependiendo de a dónde queramos llegar elegiremos uno de los dos métodos, eso sí, es fundamental que sea cual sea el formato seleccionado, se abra un espacio para dudas y preguntas por parte del alumno. Es así como comenzaremos a matizar el alcance, reglas de negocio, otros requerimientos, etc; además de comenzar a identificar habilidades no técnicas del alumno.

¿Y qué vamos a construir? Bajo mi punto de vista deberíamos definir una herramienta que motive al alumno, pero cuyo funcionamiento a bajo nivel resulte algo ajeno. Es decir, evitaría temas muy comunes como el desarrollo de una aplicación de gestión para bibliotecas o temas muy complejos como el desarrollo de una herramienta de gestión de cálculo de declaraciones de renta. Como un ejemplo no muy complejo tendríamos una herramienta tipo Facebook o Google+.

Capítulo II: Plazos e hitos

La propia definición de proyecto lo lleva de serie, los plazos. No hay proyecto sin un plazo de ejecución límite, por lo que el alumno debe desde el primer día ser consciente de esta realidad, trasladándole la tensión (que no presión) necesaria para mantener su motivación y dedicación al proyecto.

Este es el momento de trasladar al alumno cuál es la planificación de su primer proyecto (la planificación del curso), con cada uno de sus hitos intermedios y su hito final. Tanto el instructor como el alumno son los responsables de que dicha planificación se cumpla (no solo el instructor), cumpliendo adicionalmente todos los objetivos establecidos para el curso.

Para cada tarea el instructor establecerá tiempos límite. El objetivo es que el alumno empiece a jugar con el tiempo, a saber cuándo puede dilatarlo y cuándo puede (normalmente más que puede debe) contraerlo. No podemos irnos por las ramas, atascarnos de forma permanente; si no podemos tomar un camino, busquemos otra alternativa. La calidad de los resultados tiene relación también con el tiempo, hay que saber jugar con estos conceptos.

Capítulo III: Desarrollo de aplicación de escritorio

Fase 1 – Familiarizarse con el entorno y la tecnología

Como comentábamos al inicio, las formaciones de este tipo siempre han venido de la mano de tecnología Microsoft .NET, por lo que el hilo argumental se basará en la experiencia con dicha tecnología. Es en este punto donde cada instructor deberá adaptar los conceptos y herramientas a la tecnología seleccionada.

En nuestro caso entonces, nuestro entorno de desarrollo podría ser Visual Studio 2010 y nuestro framework el .NET Framework 4.0 (adaptar también dependiendo de los objetivos a lograr).

En esta primera fase, el instructor trasladará al alumno el funcionamiento básico del entorno de desarrollo:

* Tipos de proyecto
* Menús
* Teclas de acceso rápido

y de la tecnología

* Framework .NET 4.0 (en nuestro caso de partida)
* Orientación a eventos

Fase 2 – Solucionar el problema con lo puesto, premisa: todo va en memoria

Manos a la obra, el alumno ya dispone de una versión mínima de funcionamiento del entorno y del framework y conoce los requerimientos a cubrir. El primer objetivo a proponer al alumno es el de construir un aplicativo de escritorio que cubra los requerimientos demandados por el cliente, obviando una de las partes fundamentales de una herramienta de gestión, como es el almacenamiento de la información en un modelo de persistencia no volátil (una base de datos o un conjunto de ficheros).

En este punto el instructor únicamente marca las siguientes premisas:

1) El alumno deberá describir en un pequeño documento las principales entidades implicadas y sus relaciones (no estamos hablando de un modelo relacional formal, simplemente queremos ver que el alumno ha entendido el requerimiento y se ha construido un mapa mental con la información a gestionar y las relaciones que existen entre ella).

2) Antes de iniciar la codificación, el alumno deberá diseñar en primer lugar las interfaces de usuario a partir del entorno visual (WYSWYG) que provee el propio Visual Studio. Interfaces sin comportamiento únicamente descripción de las pantallas.

3) Límite temporal para realizar estas actividades.

Adicionalmente, el instructor puede esperar a ver con qué herramientas soluciona el problema del almacenamiento en memoria el alumno o trasladar una pista inicial que es el uso de listas genéricas, que es donde el instructor pretende que el alumno llegue. Una u otra opción dependerá del plazo temporal que estipulemos para esta primera fase.

El objetivo de esta primera fase se considera alcanzado cuando el alumno ha sido capaz de construir un aplicativo libre de errores con las nociones básicas de programación en objetos de las que cuenta, las nociones de entorno, de framework y la formación en el uso de listas genéricas. Nuestro aplicativo es un aplicativo que cubre el requerimiento sobre una aplicación de escritorio, pero con el pequeño gran defecto de que al cerrar el aplicativo toda la información almacenada en memoria se pierde.

Fase 3 – Primeras Pruebas

En este punto el alumno cuenta con una aplicación que cubre los requerimientos descritos por el cliente (o que debería cumplirlos) y que está preparado para su uso masivo por parte del mismo (esperamos).

Es este el momento para trasladar la importancia del proceso de pruebas. Lo más normal es que el instructor en menos de 5 minutos haya conseguido explotar tanto vulnerabilidades del sistema (objetos no referenciados, validaciones que fallan, problemas de seguridad de acceso, navegaciones ineficientes, etc) y requerimientos que no se cumplen parcial o totalmente. Se debe estudiar cada una de las aplicaciones y trasladar de forma global a los alumnos cuáles han sido los problemas que se han detectado. Es fundamental que el instructor traslade al alumno la importancia del proceso de pruebas y verificación; se la ha de poner en la piel del cliente. El alumno debe afianzar la visión del cliente y quedarse con la máxima “me da igual cómo esté hecho por dentro, lo que te haya costado hacerlo y lo que cueste mantenerlo (esto último no debería darle igual pero ya hablaremos de ese tema otro día), necesito que funcione y solucione mi problema fácil y rápidamente”. La definición técnica y de arquitectura es básica para el éxito del aplicativo y su posterior mantenimiento, pero debemos transmitir a fondo en esta fase que ésta no es la prioridad principal del cliente, por lo que el desarrollador debe darle tanta importancia a los factores técnicos como a los factores de “cliente”. Como ya muchos de vosotros sabréis, los éxitos técnicos son estupendos y maravillosos (seguramente os hayan acusado de románticos más de una vez), pero no son suficientes si el aplicativo no hace lo que tiene que hacer o falla intentándolo; si el aplicativo no es usado, no hay éxito.

Resumiendo, no es objetivo de esta fase validar técnicamente el aplicativo, únicamente el instructor se debe poner la gorra del cliente y revisar el aplicativo a nivel de uso, siendo muy exigente con el resultado obtenido. Es buen momento para trasladar ciertas nociones de usabilidad al alumno y de establecer los mecanismos básicos de herramientas para llevar a cabo pruebas unitarias y funcionales.

Fase 4 – Trasladando buenas prácticas

El punto de entrada de esta fase es una aplicación que representa lo que el requerimiento dictamina, de forma usable y con una tasa de errores no significativa.

Es ahora el momento en el que el instructor deberá analizar cada uno de los aplicativos desarrollados por los alumnos de forma interna, evaluando cuáles son los principales problemas detectados. El nivel de conocimiento previo del alumno es el que va a marcar el camino a seguir a partir de ahora. Resalto a continuación los principales temas identificados como puntos de mejora en desarrolladores con experiencia media-baja.

* No aplicación de patrones de diseño y otras herramientas provistas por la programación orientada a objetos
* No se encapsula
* No se orienta el código a su mantenibilidad
* No se emplean estándares de codificación
* No se comentan los métodos, ni los parámetros, ni los fragmentos de código más complejos
* No se aplican las listas genéricas (si no lo hemos trasladado en una fase anterior)
* No se usan constantes
* Se hardcodean parámetros configurables a partir de ficheros externos
* No se emplean excepciones
* No hay separación entre capas

El alumno tendrá que refactorizar su código atendiendo a todas estas clausulas, logrando disponer nuevamente de una herramienta que cubra los mismos requerimientos y que pase el proceso de pruebas nuevamente. Lo interesante sería que estos conceptos se vayan dando de uno en uno, para que el alumno los vaya asentando individualmente.

Fase 5 – Concepto de capa de acceso a datos

Uno de los problemas que seguramente haya surgido en la primera fase es que no haya separación entre capas, es decir, que el alumno haya construido un aplicativo en el que desde el propio interfaz se esté aplicando la lógica de negocio y accediendo a nuestro repositorio de datos (que por ahora tenemos en memoria).

En este punto es donde vamos a tener que proponer una refactorización importante de código, ya que todo lo que tenga que ver con acceso a datos el alumno deberá moverlo a un conjunto de clases independientes agrupadas por entidades de datos. La interfaz debe dejar de saber dónde estamos almacenando el dato, pudiendo en un momento dado cambiar el modelo de almacenamiento (de memoria a una base de datos física) sin necesidad de modificar una sola línea de código en la capa de presentación. En este punto es interesante trasladar el funcionamiento de patrones como DAO y DTO.

Nuevamente tras el desarrollo, el alumno deberá garantizar que la aplicación cubre los requerimientos y pasa el plan de pruebas, así como que ante un cambio de modelo de persistencia, la capa de presentación no va a sufrir ningún tipo de cambio.

Fase 6 – Definiendo un modelo relacional

El alumno ya debería estar en disposición en este punto de modelar relacionalmente la solución. Para ello, se le provee en este caso de un acceso a una instancia de SQL Server 2008, donde va a poder definir el modelo relacional. Es en este punto donde el instructor deja definir al alumno el modelo sin aplicar ningún tipo de premisa, con el objetivo de identificar necesidades formativas al respecto.

El instructor debería reforzar los siguientes conceptos

* Uso de claves primarias y foráneas
* Uso de relaciones 1-N y 1-1, definición de modelos entidad-relación basados en 3FN
* Abuso de la 3FN y problemas de rendimiento asociados
* Estándar de nomenclatura para campos y tablas
* Introducir comentarios descriptivos en campos y tablas
* Importancia de los índices
* Concepto y programación de procedimientos almacenados (muchos recién licenciados salen de la carrera sin que nadie les haya contado que es un procedimiento almacenado y para qué sirve).

Fase 7 – Almacenando la información de forma persistente

Ya tenemos una capa de acceso a datos que realizamos en la fase 5 y un modelo de datos desarrollado en la fase 6; ahora nos queda preparar nuestra capa de acceso a datos para cambiar el modelo de persistencia y comenzar a persistir sobre nuestra base de datos SQL Server 2008.

En este punto el instructor deberá seleccionar la tecnología de acceso a datos que considere. En caso de orientar la formación a un proyecto específico o tecnología esto nos llevaría a trabajar en este punto con una tecnología de acceso a datos concreta. En casos en los cuales no tengamos clara la salida del alumno, y a nivel general, recomiendo partir de las clases básicas de acceso a datos que provee el framework (ADO.NET; JDBC para formaciones Java), que accedan a los procedimientos almacenados que el alumno ha creado sobre la propia base de datos.

Esta fase va a generar una refactorización exclusivamente sobre la capa de acceso a datos (si hemos hecho bien el resto), y nuestra aplicación, sin necesidad de tocar una sola línea en el interfaz, va a pasar de almacenar la información en memoria a almacenar la información en base de datos.

Como siempre, tras este cambio, la aplicación va a tener que seguir cumpliendo el requerimiento y pasando el plan de pruebas.

Tras este desarrollo, el alumno debería percibir la importancia del trabajo en capas, la abstracción que supone el uso de capas separadas, reforzando el uso de clases con una alta cohesión y bajo acoplamiento.

Fase 8 – Concepto de capa de lógica de negocio

Nuestro código dispone en este punto de una capa de presentación que no conoce de dónde proviene el dato que está manejando, pero que sí conoce la lógica del negocio. Es decir, si para nuestro negocio dar de alta un nuevo modelo de coche en nuestro software de gestión de flotas de vehículos supone, además de realizar una inserción en la tabla que almacena los modelos a través de nuestra nueva y reciente capa de acceso a datos, enviar 3 e-mails a 3 destinatarios diferentes, replicar un conjunto de datos asociado al modelo en otro contexto diferente al nuestro, generar un fichero de comunicación con otros sistemas, etc; en este punto todo este código seguramente estará ubicado en el propio evento “onClick” del botón dar de alta nuevo modelo de coche.

El objetivo de esta fase es que una vez finalizada, nuestro aplicativo cuente con una capa de negocio que encapsule todo este comportamiento. Nuestro botón “onClick” debería llamar a un único método llamado “DarDeAltaModeloCoche” que se encargara de realizar todas las acciones pertinentes (entre otras realizar la inserción del nuevo modelo de coche a través de la capa de acceso a datos). La capa de presentación no sabe dónde se almacena el coche, y qué significa para nuestro negocio el dar de alta un modelo de coche.

Nuevamente, el aplicativo deberá respetar los requerimientos y pasar el plan de pruebas.

Fase 9 – Otras capas: Caché, Validación

Incluimos a continuación nociones de uso de otras capas como Caché, Validación, etc. Es un bueno momento para trasladar al alumno teoría de algunos patrones como Singleton, Strategy, Factory, etc.

El aplicativo debería reflejar dichos ajustes.

Fase 10 – Librerías

Nuestro código, aunque separado perfectamente en diferentes capas, ha estado formando parte de la misma aplicación en todo momento. Es este el momento de incluir los conceptos de librería de clase, y dividir cada una de las capas en librerías diferenciadas por el proyecto inicial. Acceso a Datos, Negocio, Validación, Entidades de Negocio… son librerías diferenciadas que podrán ser actualizadas de forma independiente y reutilizadas.

Capítulo IV: Replicando en Web

Es precisamente en este punto donde vamos a comenzar a reutilizar el trabajo realizado en la última de las fases de desarrollo de aplicaciones de escritorio, ya que vamos a referenciar las librerías de negocio, acceso datos, caché, validación y otras capas que hayamos creado para la aplicación de escritorio. Todo el trabajo va a ser reutilizado a excepción de la capa de presentación que es la única que va a cambiar. El alumno deberá notar la potencia de haber desarrollado su anterior trabajo con esta orientación, limitándose a realizar una nueva interfaz.

En este punto el instructor debe trasladar conocimientos avanzados al respecto de

* HTML
* Javascript
* CSS
* ASP.NET

Una vez finalizado este capítulo, el alumno cuenta con dos aplicativos diferentes que realizan exactamente la misma función y sobre los que únicamente se diferencia la interfaz (ambos referencian a los mismos proyectos de tipo librería para realizar cálculos de negocio y almacenamiento de datos).

Capítulo V: Replicando en Dispositivos Móviles

Mismo trabajo en el punto de desarrollo de aplicaciones web, pero en este caso realizando desarrollo sobre proyecto de aplicación móvil.

Capítulo VI: Distribuyendo el negocio, concepto de servicio, arquitectura SOA, independencia del dispositivo

Nuestro aplicativo ha referenciado hasta ahora librerías locales. Ha llegado el momento de distribuir el conocimiento del negocio en un aplicativo distribuido: Windows Communication Foundation. Si todo ha ido bien, las tres capas de presentación diferenciadas con las que contamos en este momento (escritorio, web, móvil), únicamente deberán cambiar su referencia de las librerías locales a los servicios web publicados por el aplicativo WCF que también crearemos en este punto.

Hasta aquí la primera versión de este método, donde intento a alto nivel dar a entender el formato de formación que hasta ahora mejor resultado viene dando, permitiendo en un plazo de 3/4 semanas situar al alumno en una dinámica de proyecto lo más cercana a la realidad, habiendo repasado conceptos de arquitectura medios y avanzados que forman parte del día a día de los proyectos de software; todo ello en un ambiente divertido y de aprendizaje continuo.

Intentaré en próximos artículos bajar de nivel de abstracción alguno de los puntos, intentando dar algo más de detalle de cómo enfocarlos a más bajo nivel.

Un saludo.

Miguel.

Mañana día 7 de marzo participo en las Jornadas NEOcom en el Centro Politécnico Superior de Zaragoza.

De 17 a 18h vamos a estar hablando de conceptos asociados Aplicaciones Distribuidas sobre Arquitecturas N-Capas y SOA; valorando entre otras cosas qué son, qué aportan y cómo las empresas pueden utilizar estas tecnologías en su beneficio.

NEOcom 2011

Un saludo.

Miguel.

La virtualización presenta una mejora principal que es el ahorro de costes asociado a la compra de servidores. Ya no va a ser necesario comprar n máquinas encargadas de soportar servidores web, servidores de base de datos, servidores de ficheros, correo electrónico. Cada máquina viene a representar un coste en Hardware más que significativo. Con la virtualización es posible disponer de un único soporte hardware que albergue n servidores virtualizados a nivel de software y que puedan dar soporte a las necesidades de la organización. Es mucho más económico adquirir uno o dos servidores para la virtualización, donde albergar n máquinas virtuales, que n servidores físicos.

Otra de las mejoras presentes con la virtualización es la escabilidad, la portabilidad y el control. Desde nuestros servidores de entornos virtualizados se puede gestionar de forma centralizada qué máquinas virtuales están activas en un momento dado así como el consumo de memoria ram y de disco de cada una de ellas. Esto nos permite tomar decisiones, y poder en un momento dado apagar una de las máquinas virtuales que no esté en uso para liberar recursos del servidor de virtualización. El despliegue de nuevos entornos virtualizados se torna también más sencillo, una vez disponemos de una máquina virtual modelo, podemos realizar réplicas para los diferentes entornos y/o proyectos, que queden expuestas a los desarrolladores una vez se han publicado en el servidor de virtualización pertinente. Respecto a la escalabilidad, las máquinas virtuales puede ser configuradas de forma dinámica con un tamaño de disco y memoria determinados, que puede variar en el tiempo, por lo que a mayores recursos necesarios para la máquina virtual, vamos a poder escalarlos mediante configuración (siempre que la máquina física disponga de los medios necesarios, claro).

Es común el uso de entornos virtualizados para dar soporte al desarrollo de aplicaciones, como por ejemplo para crear un entorno de desarrollo donde participen diferentes entidades como servidores de aplicaciones y de base de datos. También es fácil encontrar que incluso se utilice esta práctica para entornos pre-productivos.

Respecto a las pegas de estos sistemas, la principal problemática asociada es la del rendimiento, de ahí que se descarte el uso de la virtualización en muchos casos en entornos de producción, donde la velocidad de respuesta en muchos casos puede resultar crítica.

En el mercado podemos encontrar dos productos principales que ofrecen soporte respecto a la virtualización: VMWare y Virtual PC de Microsoft.

Saludos.

Miguel.

El entorno del desarrollador que podría distribuirse facilmente mediante máquinas virtuales, cuenta con todo lo necesario para la construcción. Visual Studio 2008 SP1 + Framework 3.5 SP1 para trabajar con las últimas versiones estables y consolidadas en el mercado de tecnología .NET. En el caso de estar trabajando en el desarrollo de aplicaciones web, un IIS local donde desplegar las aplicaciones web y hacer las pertinentes pruebas de desarrollo y debugs. A Visual Studio se le incorpora el plugin AgilePoint Developer para el desarrollo a medida de nuevos AgileWorks, AgileParts y AgileConnectors. Finalmente se cuenta con la disponibilidad de Microsoft Visio 2007 más el plugin AgilePoint Envision, para el desarrollo en local de las plantillas (flujos de trabajo) de AgilePoint.

En el repositorio central se almacena todo el código fuente generado por los desarrolladores mediante el uso de Team Foundation Server, que garantiza la trazabilidad del código, gestión de versiones, etc; además de poder convertirse en una herramienta de gestión y control centralizado del trabajo asociado al desarrollador. Asignación de trabajo mediante el uso de Work Items, y el control de los bugs existentes en la aplicación son algunas de sus capacidades. Al mismo tiempo, mientras el uso de Sharepoint, permite crear fácilmente portales asociados a cada uno de los proyectos en desarrollo, donde el equipo de construcción puede compartir documentación de forma centralizada y todo tipo de información de gestión o técnica asociada a cada uno de los proyectos. Debemos tener en cuenta que este entorno deberá mantener también el control de versiones asociado a las plantillas de Visio que se vayan generando mediante NVision.

El entorno de desarrollo de Agilepoint, que centraliza tanto el AgilePoint Server, la gestión web del mismo a través del Enterprise Manager, y el interfaz de servicios web que permite gestionar de forma remota y transparente el acceso a las facilidades que provee el motor de Agilepoint.

Finalmente se expone un último entorno, representativo de cada tipo de aplicación, que no hace más que definir la posible existencia de un tercer entorno de integración, necesario para el desarrollo de la aplicación, como otros servicios de comunicación u otros aplicativos existentes en el sistema sobre los que nuestra aplicación en desarrollo deba integrarse.

Un saludo.

Miguel.

Juan tiene un clavo y Pedro un destornillador. Juntos, quieren conseguir clavar el clavo en una tabla. Alberto, un amigo de ambos, tiene un martillo y también sabe usar el destornillador.

Antes de comenzar el trabajo Juan y Pedro se reunen; y tras descartar el pedirle el martillo a Alberto, por motivos que desconocemos, deciden clavar el clavo en la tabla con el destornillador.

Alberto, que participa como observador en la reunión, analiza la situación y transmite a Juan y Pedro sus conclusiones:

• Si intentan clavar el clavo con el destornillador, puede que al final lo claven, ahora bien, al no ser la herramienta más adecuada, van a necesitar invertir muchos recursos para conseguirlo, ya que van a enfrentarse a innumerables problemas.
• Si lo clavan, seguramente o quede el clavo torcido, o acaben rompiendo el destornillador.
• Si saben que yo tengo un martillo, y que sé clavar clavos con él, ¿por qué no me lo piden?

A partir de aquí aparecen las tres vertientes de la historia:

1. Juan y Pedro le piden el martillo a Alberto. El clavo se clava y todos son felices. (Esta no suele ocurrir).
2. Juan y Pedro proceden con su idea inicial. Un año más tarde de lo previsto la mitad del clavo y torcido está casi clavado en la tabla. El destornillador ya no sirve. (Esta os sonará más).
3. Juan, Pedro y Alberto siguen la reunión hablando de más alternativas, de las expectativas y necesidades de cada uno. Finalmente, caen en la cuenta que a Juan no le importa quitar algo de la superficie de su clavo (donde debería golpear el martillo), ya que la final lo que quiere es clavar el clavo y eso no le afecta a su objetivo. Curiosamente el hueco que dejan en la superficie del clavo es el suficiente para que encaje el destornillador y conseguir así, sin apenas esfuerzos extra respecto al martillo, clavar el nuevo tornillo, salido tras manipular el clavo, con el destornillador. (Esta tampoco suele ocurrir).

Para los menos imaginativos o exhaustos tras una dura jornada de trabajo, una pista: la historia la ha escrito Alberto.

Un saludo.

Miguel.

Trabajando con .NET los dos motores de base de datos más empleados son SQL Server y Oracle, y para acceder a ellos desde una de nuestras aplicaciones podemos pasar desde utilizar los drivers propios de Microsoft para acceder a ambos gestores, con clases propuestas por el propio framework, podemos acceder a oracle a traves de los Oracle Data Access Components (ODAC) para .NET, podemos usar Datasets Tipados con sus correspondientes TableAdapter para aliviar algo el tiempo de construcción… utilizar patrones de acceso a datos como DAO+DTO… y un largo etcétera que puede pasar por soluciones caseras más o menos elaboradas, aplicaciones de otros patrones de acceso a datos como puede ser Active Record o herramientas de acceso a datos orientadas entidades como el nuevo Microsoft Entity Framework y la versión de Hibernate para .NET, NHibernate. Para más diversión, incluso pueden emplearse combinaciones de alguna de las herramientas descritas en el párrafo, intentando ajustar el esfuerzo de construcción a nuestro proyecto y, lo más complicado de todo, a nuestra planificación

Pues ante toda esta lista interminable de herramientas, cada una con sus pros y sus contras, añado y expongo a continuación las ventajas aportadas por otra más, las Enterprise Library con su funcionalidad de acceso a datos: Data Access Application Block.

¿Qué nos aporta el Data Access Application Block?

Pues una de las principales ventajas que aporta el framework es que permite con la misma codificación atacar a diferentes gestores de bases de datos, es decir, tras preparar el acceso a datos de nuestra aplicación con enterprise library, podríamos ser capaces sin cambiar ni una línea de código (no os toméis esto al pie de la letra, que seguro que algo habrá que cambiar aunque sea mínimo), de pasar de atacar a un SQL Server a un Oracle. Esta puede ser una gran ventaja si estáis preparando un producto al que dependiendo del cliente al que se lo vendáis tengáis que garantizar el soporte de ambos gestores, porque por ejemplo alguno de vuestros clientes esté casado con Oracle y otro con SQL Server. Con un sólo desarrollo de vuestra capa de acceso a datos cubriréis toda la casuística (menos los procedimientos almacenados, claro, que os va a tocar picarlos dos veces ).

Otras ventajas a tener en cuenta son la facilidad de configuración. Una vez instaladas las enterprise library disponemos de una pequeña aplicación que apuntándola al Web.Config o App.Config de nuestro aplicativo permite editar las propiedades de conexión de manera visual. Pudiendo configurar el proveedor de la conexión, tipos de autenticación y más parámetros propios de una conexión a datos de forma muy cómoda y sencilla.

Una vez configurada la conexión, con una línea como la siguiente conectamos con el gestor, independientemente de cuál sea (DataBase y DataBaseFactory son clases del Data Access Application Block).

Database nuestraDB = DatabaseFactory.CreateDatabase(“nombreConnectionString”);

Para hacer una consulta que retorne un conjunto de registros a través de un procedimiento almacenado:

DataReader ejemploDR = nuestraDB.ExecuteReader(CommandType.StoredProcedure, “spu_get_allitems”);

Y para recorrer el datareader, pues como siempre, utilizando el método Read y luego en el registro sobre el que trabajamos obteniendo el dato a través del identificador de la columna.

Como véis es rápido y sencillo (no tanto para los que os toque trabajar contra Oracle, ya que os vais a necesitar conocer algún truquillo extra), y os ayuda a mantener una total independencia con el gestor de base de datos.

Bajo mi humilde opinión, Data Access Application Block podría ser un buen candidato a herramienta de acceso a datos corporativo en cuanto al desarrollo de soluciones .NET.

Saludos.

Miguel.

Dejando de lado en este capítulo las recomendaciones de arquitectura en el uso de las sesiones, simplemente plantear una solución a uno de los típicos problemas que se encuentran los arquitectos de software a la hora de definir el uso de sesiones, que son las limitaciones al uso relacionadas a entornos donde se cuente con una infraestructura que ofrezca alta disponibilidad cuando estamos trabajando con variables de sesión almacenadas en la memoria del servidor.

Para solucionar este problema, existen productos disponibles en el mercado, que lo que hacen es mantener también balanceado el contenido de la sesión de todos los servidores existentes en una granja, por lo que, aunque un usuario a medida que va lanzando peticiones, el balanceador lo vaya dirigiendo a servidores diferentes, podrá seguir trabajando con la información de sesión que haya generado, en memoria, en un servidor diferente.

Os dejo el link a uno de los productos que solventa este problema en entornos .NET: NCache

http://www.alachisoft.com/ncache/

Saludos.

Miguel.

A priori, y conociéndo únicamente las características básicas de funcionamiento de las aplicaciones cliente-servidor web y los sistemas de colas de mensajería, resulta de extrañar que pueda sacarse algún tipo de partido combinándolas, ya que:

• La relación entre un cliente web y el servidor es síncrona y uni-direccional. El cliente solicita la comunicación con el servidor, quedando a la espera de respuesta antes de poder seguir el hilo de ejecución, de forma, insisto, totalmente síncrona.
• En cambio un sistema de gestión de colas es en esencia asíncrono, ya que, a grandes rasgos, consiste en un punto de entrada que va almacenando peticiones en un determinado órden, y que garantiza que las peticiones van a llegar al destino, pero por defecto no garantiza cuándo. En cuanto la petición ha sido procesada, la respuesta se asocia a un punto de salida, el cual la aplicación llamante debe consultar para conocer el resultado del procesamiento.

Entonces, si el trabajo en web es síncrono, y los sistemas de colas de mensajería asíncronos, ¿como podemos obtener algún tipo de beneficio? Paso a enumerar escenarios:

1. Se debe realizar un cálculo que requiere de tiempos no manejables en entornos web de manera síncrona (más de 1 minuto se podría considerar como inmanejable).
2. La petición que se recibe en el servidor sólo es ejecutable en algunas ventanas de tiempo.
3. No es necesaria la notificación de ejecución completa al usuario una vez lanzado un proceso, por lo que podemos gestionar internamente cuándo lanzararemos el proceso demandando para optimizar así el consumo de cpu y memoria.

Se pueden encontrar muchos ejemplos de estos usos por ejemplo en redes sociales como Facebook, donde en muchas ocasiones se proponen envíos masivos de notificaciones, invitaciones y noticias a un grupo muy grande de usuarios. Una vez realizada la petición, esta es encolada y ejecutada a posteriori.El usuario no tiene necesidad de conocer a ciencia cierta que la petición se ha ejecutado en el momento, se conformo en saber que los avisos, llegarán. Lo mismo ocurre con otros sistemas muy habituales como son los envíos de SMS a través de teléfono móvil.

La ventaja y moraleja del artículo respecto a todo esto, es que el uso sistemas basados en colas de mensajería ayudan a maximizar la experiencia de usuario en entornos web, ya que tras una petición que podría resultar en una larga espera síncrona hasta que el servidor haya terminado de ejecutar la petición, esta termina al momento (desde el punto de vista del usuario), y el usuario puede seguir utilizando la aplicación sin problemas. Mientras tanto, por detrás, el gestor de mensajes ha encolado la petición, la cual, en su momento, será ejecutada.

Si vuestro escenario es similar al aquí planteado, emplear una solución basada en sistemas de colas de mensajería, podría ser una buena solución de arquitectura.

Saludos.

Miguel.

Sesión en Memoria vs Sesión en Sistemas Persistidos (Base de Datos o Servicios del Sistema Operativo)

La forma más eficiente de trabajar con sesiones es manteniendo su contenido en memoria. En el caso de estar trabajando con una granja de servidores, pueden utilizarse soluciones existentes en el mercado como es NCache, para balancear el contenido de las sesiones en memoria entre todos los servidores de la granja.

En caso de no poder barajar esta alternativa existen soluciones que permiten almacenar el contenido de la sesión sobre sistemas persistidos. Esta solución es más lenta, pero permite compartir la información de sesión sobre diferentes servidores, además de garantizar que aunque se reinicie el servidor de aplicaciones, la información de sesión va a permanecer disponible cuando la aplicación vuelva a arrancarse.

Cantidad de Memoria en Uso

El uso de sesión afecta directamente al consumo de memoria del servidor que está ejecutando las llamadas del cliente, por lo que deberá almacenarse en sesión únicamente la información que se considera imprescindible y que, se recomienda, esté relacionada con alguna de las siguientes características:

• Información básica relacionada con la autenticación o la seguridad del usuario y que es necesario comprobar en las llamadas o peticiones que realiza el usuario contra la aplicación.
• Otro tipo de información funcional asociada al usuario, que va a permanecer estática a lo largo de toda la vida de la sesión y que es requerida de forma constante en las peticiones que realiza el usuario a la aplicación. El objetivo de este punto sería minimizar el número de llamadas a base de datos.

Tipos de Objetos en Memoria

Los objetos almacenados en la sesión deben ser en todo caso de poco peso, minimizando así la cantidad de información almacenada por sesión por cada objeto. Se recomienda el uso de objetos de negocio que incluyan tipos de datos básicos. No se recomienda el almacenamiento de objetos propietarios de .NET del tipo Dataset ó DataTable debido al tamaño asociado a los mismos.

Manejando Información Sensible

Si el contenido almacenado en la sesión contiene información sensible, como podrían ser contraseñas o información personal del usuario activo, ésta deberá permanecer encriptada durante todo el ciclo de vida de la sesión.

Usando Sesión a modo de Caché

No debe emplearse la sesión para almacenar catálogos de datos comunes de la aplicación, como podrían ser listados de países, regiones, provincias, etc, ya que éste no es el objetivo de  este tipo de objeto. Para estos casos se deberá recurrir a un objeto de tipo caché.

Usando Sesión a modo de Viewstate (específico .NET)

No se recomienda emplear la sesión para almacenar información que será necesaria explotar entre llamadas a la misma página, ya que para ello existe un objeto preparado específicamente para resolver esta problemática como es el Viewstate de ASP.NET.

Usando Sesión a modo de POST y GET

No debe emplearse la sesión para transportar información entre páginas de la misma aplicación, ya que para ello se deberá recurrir a los objetos POST y GET.

Liberando Información de Sesión

Siempre y cuando se detecte que la información almacenada en sesión deje de ser necesaria para la sesión de usuario actual, se debe solicitar la liberación de la memoria asociada al servidor.

Saludos.

Miguel.