Definiciones para el Proyecto

Después de pensar, discutir y jugar con el prototipo del proyecto ya tenemos algunas definiciones.



Definiciones


No perdemos de vista los objetivos Aprender, Practicar y Comunicar. En base a ello definimos que este motor de blog no es para competir con los ya existentes, en consecuencia las caracteríscitas básicas que esperamos del proyecto son las siguientes:

1. Presentación configurable o parametrizable. Con esto lo que pretendemos es que el administrador (dueño) del blog pueda configurar la presentación del mismo, para una segunda etapa estamos pensando en permitir que los lectores del blog puedan organizar ciertos componentes que el dueño pone a su disposición. Para realizar esto vamos a utilizar hojas de estilo, skins, themes, master pages y webparts.


2. Satisfacción del usuario final. Esta definición impone la utilización de la última tecnología disponible con lo que nos referimos a AJAX y Silverlight. De hecho las herramientas (lenguajes de desarrollo) son diferentes, sin embargo existe un grado de compatibilidad en la arquitectura que se utiliza; en la medida que se pueda incorporaremos ambas tecnologías.


3. Persistencia en un motor de base de datos. Obviamente uno de Microsoft, en relación con esta definición, pretendemos utilizar LINQ. También se está manejando la idea de contar con diferentes proveedores de datos, de ese modo podremos organizar la persistencia de diferentes maneras.


4. Redes sociales. Con esto apuntamos a la web semántica y toda la interacción entre aplicaciones que existe actualmente; con esta definición nos vamos a meter en WebServices tanto para proveerlos como para consumirlos.

Especificaciones Generales de Desarrollo


Obviamente el motor de un blog se ejecuta en un servidor web, en consecuencia los diferentes componentes deben probarse en esas condiciones; esto implica que los desarrolladores deben instalar Internet Information Server - IIS, mejor si podemos probarlo en diferentes versiones; habilitar un directorio virtual apuntando al directorio donde se encuentra el sitio (local) donde ejecutamos la aplicación. Más adelante veremos la manera de contar con un lugar en algun servidor de la Web.


Respetar las capas de desarrollo, se debe lograr que sean diferentes capas las que realicen o logren los objetivos del desarrollo. La cantidad de capas por lo menos deben ser tres: Presentacion (View), Lógica (Control) y Model (Modelo de Datos). Pueden haber más capas, por ejemplo el modelo de datos puede implementar una capa de clases de negocio, la que utiliza otra capa de acceso a datos la que a su vez puede utilizar otras de acuerdo al tipo de persistencia que realice. El esquema de codificación que nos facilita ASP NET ya ofrece dos niveles el de la página o control de la web y el de código asociado, sin embargo se debe estar atentos a las posibilidades de encapsular propiedades y comportamiento común ya sea en controles de usuario y/o clase utilitarias.


La presentación se debe lograr siempre por medio de estilos o skins, lo que nos permitirá camnbiarlos sin tener que alterar el resto de las capas. Del mismo modo la lógica de control no debe interferir con los mecanismos de persistencia ni con las condiciones de presentación.


Si hace falta se crean tantos proyectos como sean necesarios, algunos serán para testear aspectos del desarrollo o para aprender algún concepto, otros serán componentes o módulos de la aplicación.


La codificación debe ser documentada, es obligatorio utilizar el documentador en línea que nos facilita el Visual Studio, es muy facil darle a las tres barras (///) en la línea anterior de cada método o propiedad e incorporar los comentarios correspondientes. La compilación se realizara en el mayor nivel de control, de manera que luego se puede revisar que falta.


El seguimiento del código se hace de a poco, no es bueno esconderse durante tres semanas escribiendo código y luego subirlo al servidor de versiones arruinando lo que hicieron todos los demás. La modalidad de trabajo es concentrarse en una o dos partes concretas, codificar y compilar hasta que no de errores y subir al servidior de manera que se genere un "code set" controlable; de este modo el resto de los desarrolladores pueden actualizar lo que están haciendo con esa pequeña porción y además controlar que no interfiera con su parte de trabajo.


Para minimizar los conflictos de versionado se debe aclarár quiénes trabajan con que aspectos del desarrollo, a veces es inevitable trabajar sobre una misma clases, implementando diferentes comportamientos de manera que en realidad no hay conflicto; para evitar esta situación es importante mantener las porciones de código donde están, no es bueno reorganizar el codigo porque nos gusta que los metodos estén despues de las propiedades o al reves; si esta situación se realiza es porque hace falta hacerlo corrigiendo alguna situación caso contrario no se hace.


Siempre es bueno hacer una copia de seguridad de lo que tenemos en nuestro equipo antes de bajarse (update) el último conjunto de código. Por supuesto antes de subir (commit) se debe hacer un update para estar seguros que lo que vamos a subir se hace sobre el último conjunto de cambios, de otro modo el conflito se puede producir en el servidor y será un laborioso resolverlo. Hacerlo en nuestro equipo es mucho más facil dado que podemos tomar deciciones cuando el programa de versionado no sabe que hacer.



Filosofía de Desarrollo


Desde el punto de vista del desarrollo de software, la simplicidad no es lo contrario de la complejidad.

Las porciones de código simples son faciles de entender, mantener, extender y reutilizar; y entre todas completan una aplicación compleja, en consecuencia para realizar este proyecto que es del tipo EEP - Eaten an Elephant by Parts, vamos a utilizar la filosofía KISS - Keep It Simple and Stupid.