PRISM: un framework para WPF

El pasado Febrero de 2012, Microsoft liberó la versión 4.1 de Prism, un Framework pensado para facilitar la creación de aplicaciones con WPF y Silverlight. Sobre todo, permite afrontar de forma estructurada y según los últimos patrones, aplicaciones de visualización de datos con interfaces de usuario ricas y con un negocio complejo.

¿Qué permite Prism?

•  Modularidad: particionar los componentes para crear aplicaciones a partir de módulos integrados pero independientes.
• Interfaz de usuario: desacoplamiento de los componentes de UI con respecto al resto de la aplicación.
• Servicios horizontales (log, authentication,etc)  separados de servicios verticales (business logic). Esto facilita la creación de capas realmente desacopladas.

Según Microsoft (y las características que aparecen así lo indican), las aplicaciones desarrolladas con Prism están hechas para durar mucho tiempo, y para aceptar con sencillez los cambios que sean necesarios.

Más información en este enlace, donde encontraremos:

• Descargas
• Guías
• Enlaces de acceso a Foros y Blogs para más información y solución a problemas comunes
• Documentación
• Quickstarts

La gestión de la deuda técnica

La deuda técnica es un concepto que se lleva manejando desde hace ya unos años. Muchos de vosotros habréis oido hablar de ello, y unos cuantos, como yo, lo habréis sufrido con dolor. Vamos a ver primero en qué consiste, y comentaré finalmente una iniciativa a nivel global para atender este grave problema que nos afecta en nuestra profesión.

¿Qué es la deuda técnica?

Qué curioso. Antes de explicar la deuda técnica, he querido contrastar mi definición con la de Wikipedia. Y qué decepción. Wikipedia explica, que la causa de la deuda técnica está en el ahorro de costes, que a su vez deriva en escasez de pruebas, y mala calidad de los productos implantados o incluso con errores conocidos.
Pues disiento. He visto proyectos bien sobrados de dinero, con abundancia de pruebas, y con resultados de calidad pésimos.
En mi opinión, la deuda técnica es la acumulación en el software de una o varias de las siguientes:

• Una o varias arquitecturas incongruentes entre sí o con las necesidades reales (o ausencia de arquitectura!).
• Inexistencia de estándares de programación, o existencia de varios estándares de desarrollo incongruentes entre sí.
• Falta de pruebas adecuadas a la solución requerida, de forma que posiblemente las pruebas se pasaron, pero el producto seguía adoleciendo de una baja calidad.
• Ineficacia en los programadores a la hora de realizar el código. Bien por usar soluciones inadecuadas o ineficades, no utilizar patrones cuando hubieran sido adecuados, o por el contrario, abusar de patronitis (ver mi entrada sobre esta enfermedad del software).
• En general, el uso y abuso de las distintas enfermedades del software que voy desgranando en este blog como son la ya comentada patronitis, cacheitis, etc.

Las consecuencias de todos estos problemas, se pueden ver tanto en proyectos faltos de presupuesto, como en complejos y grandes desarrollos bien dotados económicamente. Como ya he comentado en algún otro blog, los programadores tenemos la habilidad de echar siempre la culpa a los demás de todo, en lugar de hacer primero análisis, y después asumir la parte de culpa (mucha o poca) que podamos tener. Como decía las consecuencias son:

• Código espaguetti, o incluso código estructurado de formas tan diferentes entre sí, que parece una lucha de voluntades por parte del programador de impregnar cada uno, su forma de trabajar. El exceso de estándares es tan malo como su carencia.
• Ausencia de control de errores, o un uso que imposibilite obtener cualquier beneficio de dicha implantación.
• La documentación representa al software como un huevo a una castaña.
• No se ha hecho refactoring: el código se queda como está...o lo que es peor: los cambios se limitan a añadir más y más elementos, hasta que el código o es espaguetti, o dan ganas de atentar contra la vida de los diversos autores.
• Errores no subsanados, errores desconocidos (pruebas mal diseñadas).
• Control de versiones inexistente, de forma que no es posible saber qué versiones de unos módulos son compatibles con qué versiones del resto de módulos, o con la base de datos.
• Wikipedia nombra que una consecuencia sea que el producto no sea escalable. A ver, aquí encontramos una falacia: la escalabilidad tiene un coste. No todos los productos tienen una arquitectura de 7 capas con servicios distribuidos, escalables multiplataforma y bla bla bla...
• Wikipedia nombra otra consecuencia, que aunque cierta, hay que analizar: "Problemas al incorporar nuevas funcionalidades". Y es que un producto que cuesta cambiar, no tiene porqué significar que está mal hecho y que supone una deuda técnica. Todo depende del cambio. Una aplicación de gestión de personas, que se quiera adaptar a la gestión de vehículos...pues quizás el cambio no es trivial. ¿Acaso le vamos a echar la culpa al equipo de desarrollo anterior? 
• Finalmente, wikipedia indica otra consecuencia con la que discrepo: "Dificultades a la hora de actualizar la tecnología, o migrar a una nueva plataforma". Que un software admita un cambio de tecnología o de plataforma, es un requisito muy complejo. No es un requisito habitual, por otra parte. Por desgracia, no existe el software, en ningún patrón, framework o metodología que admita "cualquier tipo de mejora tecnológica o cambio de plataforma". Si esto existiese, se habría acabado la profesión de informática y sólo trabajarían unos pocos haciendo los escasos cambios necesarios. 

En general, y por simplificar, la deuda técnica es la degradación en la calidad del software y la dificultad en los cambios posteriores, debido a decisiones a corto plazo ineficientes (seguro que se os ocurre o leéis por ahí alguna otra frase más elaborada, pero bueno).

El término deuda técnica, se lo debemos a Ward Cunningham (igual os suena como el pionero del software en temas como la primera wiki, los patrones de diseño, o la programación extrema).

Lo realmente importante no es cuánto sepamos de la deuda técnica. Seguro que muchos de vosotros daréis una visión y descripción académica mucho más acertada y exacta que la mía. Lo que es importante, es que empecemos a ser conscientes de una vez de que el software no se construye y ya está. Alguien lo debe mantener, alguien debe hacerlo funcionar como realmente quería el cliente. Por desgracia, cuando pasa la época de las medallas (qué bonito es todo cuando se entrega el software y no se ha probado del todo por el cliente), llega la realidad de que el cliente no puede hacer todo lo que quería en su negocio, con las funcionalidades que al final se le han dado. Además, por desgracia, los que sufren el esfuerzo de "pulir" el software y terminarlo de arrancar, suelen ser personas totalmente ajenas a los que recibieron las medallas, víctores y premios por la entrega.

Iniciativa del SEI

El SEI (Software Engineering Institute), ha llevado a cabo recientemente un Workshop en el que se trataba la gestión de la deuda técnica desde el punto de vista de arquitectura del software. El evento tuvo lugar el 13 de marzo de 2012, pero tenéis información disponible en este link.

Además, el SEI está haciendo un esfuerzo en la investigación y estudio de este problema, que cada día se hace más palpable en el mundo del desarrollo de software.


Más información en:
http://www.sei.cmu.edu/newsitems/tech-debt.cfm
http://es.wikipedia.org/wiki/Deuda_t%C3%A9cnica
http://en.wikipedia.org/wiki/Ward_Cunningham

H.L. Mencken vs la navaja de Occam

Existe desde hace tiempo, y he podido verlo en blogs, artículos, y comentarios, el mito de la navaja de Occam.

La navaja de Occam (u Ockham, pues así también aparece escrito en diversas fuentes), permite identificar como correctas, las explicaciones más simples a una cuestión, en igualdad de condiciones.

Esto que se aplica a las explicaciones de la realidad, se ha tratado de llevar a las soluciones de los problemas de la realidad. Es decir, a tratar de identificar mediante esta sentencia, las soluciones más apropiadas a los problemas de nuestro trabajo.

El problema de la simplicidad, radica en que es muy fácil caer en el simplismo: en soluciones que parecen darnos la salida a un problema, cuando no es así. De hecho, el problema es que no es fácil determinar esa "igualdad de condiciones". Pero por otro lado, a pesar de esta visión simplista de la realidad, existe la idea de que hay que dar con las soluciones adecuadas, no con las simples. Vése por ejemplo, esta otra frase famosa de H.L. Mencken que yo personalmente alabo:

"For every complex problem, there is an answer that is short, simple, and ...wrong"

Que viene a ser:

"Para todo problema complejo, hay una respuesta que es corta, simple,...y errónea"

Es decir, siempre encontraremos quien trate de vendernos soluciones simples, y que mediante argumentos tan pueriles como la navaja de Occam, trate de vendérnoslas como definitivas.

Todo esto viene a colación de mi querido Steve McConnell, ya que estaba este fin de semana pasado releyendo por encima su "Rapid Development". Un libro que a pesar de contar en sus espaldas con unos cuantos añitos (es nada menos que de 1996), sigue siendo para sus afortunados lectores toda una referencia en ya casi dos décadas.

En uno de sus primeros capítulos, Steve ilustra la necesida de identificar soluciones adecuadas, ya que las soluciones simples, no han funcionado (y siguen sin funcionar, Steve). El dilema, es que el desarrollo de software es un problema complejo, y tal y como establece H.L.Mencken, vamos a encontrar múltiples, posibles y simples soluciones. Todas ellas erróneas en la práctica, pero que en teoría, venden. Y digo venden, porque parece que hay una plétora de personas esperando soluciones y metodologías simples, con la esperanza de que cada una resuelva el problema del desarrollo de software (y de paso explique porqué la anterior no lo hizo).

Code-and-fix

Pues nada, ahora que ya me he quitado de encima el hablar un poco del ya viejo modelo en cascada para el desarrollo de software, me apetece hablar también de un método que siempre ha estado ahí. Es anterior incluso al modelo en cascada (algunos van a alucinar), pero todavía se usa hoy, por increible que parezca.

¿Qué método es este? Pues el del título, claro: Code-and-fix

¿En qué consiste? 
Este método, que va en contra de cualquier fundamento de la ingeniería del software, es muy simple y efectivo como veremos a continuación, ya que consta tan sólo de dos pasos:

1. CODE: Programar algo tratando de que el resultado proporcione los objetivos deseados.
2. FIX: Corregir el código para que funcione (normalmente añadiendo más código, y vuelta a corregir).

¿Qué os ha parecido? Pues esto que parece que me lo acabo de inventar, y que más bien es fruto de los desvaríos de una noche de juerga, es como se trabajaba antes....muy antes.

En uno de los libros de Steve McConnell encontramos esta frase: "Code-and-fix es un modelo poco útil, pero bastante común". Y es que este método tan simple, se venía usando desde los primeros años del desarrollo de software. Sin embargo, su extensión era debida a su simplicidad, no a su efectividad. Al final, el código resultante podía funcionar...pero raramente consistía en lo que quería el cliente, adolecía de problemas de arquitectura, nula escalabilidad, etc. Hay quien todavía lo defiende para proyectos de pequeño tamaño (que no nos pase nada).

Pero claro...y si tenemos que entregar un proyecto con plazos imposibles (para ayer), de tamaño muy pequeño...¿no merece la pena programar desde el minuto 0? ¿No es mejor ponerse a teclear código ya? Pues no. Va a ser que no.

¿Cuál es el problema?
¿Pero si tenemos prisa, qué quieres que hagamos, Roberto? Pues lo que tenéis que hacer es parar a pensar primero. Sin un método, sin estrategia, no iremos a ninguna parte. El tema no es ponerse a hacer documentaciones extensas, ni requisitos complicados, ni diagramas de uso...Incluso para proyectos muy muy pequeños, existen metodologías que nos pueden ayudar.

Tal y como he leído en otro blog, el propio Steve McConnell nos ofrece un caso real donde la velocidad se consigue a través de método (simplificado, claro), técnica y disciplina: habla de un concurso de la "Australian Computer Society", en el que se tenía que desarrollar una aplicación en tan sólo 6 horas. Mientras la mayoría de contrincantes se lanzaron a programar desde el primer minuto, una consultora participante utilizó una metodología de desarrollo formal, pero reducida: utilizando etapas de análisis y diseño y otras técnicas metodológicas. En esa ocasión, la empresa consultora perdió, pero porque el código entregado, no era la versión correcta. Habían tenido un fallo de gestión de la configuración. La misma empresa consultora, en un concurso similar posterior, ganó esta vez por goleada, ya que incorporaron técnicas de versionado que le evitaron el disgusto anterior. De nuevo, se demostró que la técnica y la ingeniería, superan el "tú ves programando, y luego si eso, ya lo corregiremos".

Algunos ejemplos
Este ejemplo está obtenido del libro "Rapid Development", de Steve McConnell. Pero hay más. El autor nos muestra un par de perlas relacionadas con el Code-and-fix:

1. Código infernal. El modelo emprendedor, o de la empresa pionera, en el que se combina las técnicas de code-and-fix, y planificaciones ambiciosas, no funciona. Es un claro ejemplo de que dos mentiras no hacen una verdad.
2. Sálvese el que pueda o abandonar el plan bajo presión. En muchas empresas, se produce la situación en la que tras un inicio de planificación, control, y supuesta buena gestión...se llega a una encrucijada en la que la acumulación de problemas y la asfixia de los plazos, problemas, y errores, hace que el equipo abandone toda planificación y se dedique a programar a toda costa, en un puro y duro "code-and-fix". Esto también se produce cuando en un proyecto por entregas, una primera entrega desastrosa hace que la única decisión que se les ocurre a los gestores de turno es....abandonar toda planificación.

Pues nada, ahora ya sabéis qué nombre ponerle a eso que hacéis cuando entra el jefe por vuestra puerta y os grita histérico: "Correeeeeeeeeeee" "Produceeeeeeeeeeeeeeee"

Feliz programación

Desarrollo en Cascada (III)

Habréis de disculparme. En mi último post de "Desarrollo en Cascada (II)", tuve un gazapo. Si leísteis algún párrafo sin sentido o aparentemente fuera de lugar, fue un error de un estilo que me hizo una juguarreta. Ya se ha corregido.
Y llegamos a esta entrega, en la que mientras revisamos el desarrollo en cascada, estamos viendo otras muchas más cosas sobre el desarrollo software.

Hoy toca hablar de porqué fracasó el modelo en cascada.

¿Qué hizo que fracasara el modelo en cascada? Pues básicamente que no había otra cosa. Existían variantes del modelo, pero la rigidez básica en que estaba basado, lo hacía inoperativo. Además, se dieron cita una serie de circunstancias:

• Los clientes quieren ver avance. Efectivamente, los clientes quieren estar seguros de que el dinero que se han gastado, está siendo usado correctamente. Existe la creencia de que lo que quieren ver, es cómo se van construyendo las funcionalidades: nada más falso. En gran número de ocasiones, al "cliente", al que "paga", le preocupa más satisfacer sus necesidades. Y entre sus necesidades, también están que su compra sea correcta, que llegue a tiempo, que no supere el presupuesto...Estos requisitos pueden ser más valiosos que el hecho de ver las funcionalidades una a una. Por ejemplo, a todos nos gusta ver cómo construyen nuestra casa. Pero porque no queremos que se gaste nuestro dinero, y nos quedemos sin casa. NO (y repito: no) queremos ver cómo se añaden funcionalidades (puertas, paredes, suelos...). No queremos que nos pregunten por cada elemento que se añade al edificio. Tenemos otras cosas que hacer. Ahora: eso sí, no nos gustaría esperar a que se termine de construir, no nos gusta que nos digan que va a costar más porque han detectado "noseque", ni que se va a retrasar la entrega de llaves "pornosecuantos". Al único que le interesa que el cliente vea cómo se añaden funcionalidades, es al equipo de desarrollo. ¿Porqué? Pues porque somos inseguros, nos sentimos perdidos al añadir 2400 casos de uso, y nos sentimos más protegidos si el cliente los va validando uno a uno. Es algo natural. Pero entonces, no digamos que escuchamos al cliente. Estamos escuchando al equipo de desarrollo.
• No tener a un cliente que valide el producto a medida que lo desarrollamos, nos impide tener la seguridad de llegar al resultado deseado. Claro, somos nosotros los que queremos cercionarnos de que vamos por buen camino.
• Las pruebas en la metodología en cascada, se producen muy tarde, cuando ya se ha realizado el esfuerzo de desarrollo. Esto es natural para simples o pequeños desarrollos, pero es antinatural para proyectos más grandes. De todas formas esto es otra falacia: las pruebas no detectan que se esté construyendo algo incorrecto. Lo que verifican las pruebas, es que lo construído se corresponda con los requisitos identificados. Y si éstos son los que se tomaron incorrectamente...tendremos un desastre. No podemos reemplazar de un plumazo el análisis, diseño y pruebas por un usuario que nos valide el producto.
• La calidad del producto no se conoce hasta que no nos encontramos en las etapas más tardías del proyecto, tras el desarrollo. Aquí también tengo que quejarme. La calidad, está basada en una serie de actividades: validación, verificación, auditoría y control. Tan sólo la primera, valida sobre el producto final, que se cumplen los requisitos. El resto, permiten identificar desviaciones en la calidad del producto. Por ejemplo, la técnica de Peer Review, se puede utilizar durante todo el ciclo de vida: desde los requisitos, hasta el despliegue final. El problema es que tradicionalmente se han asimilado todas las actividades de aseguramiento de calidad a las pruebas, y por tanto, se estaba autolimitando al equipo de desarrollo.
• Los clientes siguen proporcionando funcionalidades nuevas (o cambios sobre las existentes). El argumento que se suele dar, es que es muy complejo asimilar estos cambios. De nuevo, estoy parcialmente de acuerdo. La gestión del cambio, es un proceso de gestión que está totalmente desvinculado del ciclo de vida de desarrollo que se esté utilizando. Y hay que realizarlo siempre, aunque uses SCRUM. Que el cliente tarde 3 meses en darse cuenta de que quiere algo nuevo, va a ocurrir tanto si trabajo en cascada, como si no. La esperanza de los detractores de las metodologías tradicionales, consiste en que al ver el cliente las funcionalidades parcialmente desarrolladas, podrá darse cuenta ANTES de que se han pasado cosas por alto. Existe un miedo irracional de que si se producen cambios tras la fase de análisis, no se podrán asimilar convenientemente esos cambios. De nuevo, esto lo único que me dice, es que los procesos de gestión del cambio ESTABAN MAL IMPLANTADOS.
• La metodología en cascada enlaza estrictamente unas actividades con otras, impidiendo que una actividad empiece hasta no terminar la anterior totalmente. Esto aumenta el tiempo de desarrollo innecesariamente.
• Al separar las fases, cada especialista trabaja separado de los demás. De esta forma, los analistas trabajan como en una cadena de montaje, pasando de proyecto a proyecto durante la fase de análisis de cada uno de ellos. Lo mismo ocurre con los programadores, o con los testers. El problema es que no hay un concepto de "equipo", que sepa hacer frente a los cambios solicitados. Con el tiempo, se ha ido cambiando de un modelo de profesionales especializados, a profesionales más generalistas. Por desgracia, esto también ha ido degenerando en unos cada vez más capacitados programadores, que hacen un poco de todo. Ya no se lleva tanto el analista que se dedica exclusivamente a realizar análisis y el tester que sólo diseña, construye y ejecuta pruebas. Esto último es parte ventaja, y parte inconveniente, aunque en modelos ágiles por ejemplo, quizás encaje mejor un perfil generalista que uno muy especializado.
• El cobro de las facturas durante el proyecto, se complica al no ver el cliente algo de valor. Efectivamente, es más fácil ir cobrando al cliente por partes "ya construidas".

Desarrollo en Cascada (II)

En la primera parte de este post, hablábamos de metodologías en cascada, las definíamos, y veíamos que tenían una cierta razón de ser, al menos en un contexto y situación concretos. Vimos también que se produjo un cambio, y que por una serie de motivos, esta metodología cayó en desgracia. Vamos a recuperar las ventajas e inconvenientes del modelo en cascada para entenderla mejor, y por tanto, llegar a entender el origen del resto de metodologías:

Ventajas del ciclo de vida en Cascada

Aunque muchos no estarán de acuerdo, este proceso tiene sus ventajas y tal y como vamos a ver, es de cajón. Para más información, consultar aquí (INTECO, Marzo 2009 "Metodologías y Ciclos de Vida"). ¿Qué ocurre, que ahora va a resultar que queremos recuperar la metodología de desarrollo en cascada? No, en absoluto. Simplemente recordar, razonar y demostrar, que a pesar de las críticas radicales y muchas veces infundadas, existen motivos para que todavía se use hoy en día. Otra cosa bien diferente, es que los proyectos en que se esté usando, por desgracia, no tengan las características adecuadas a esta metodología.

• El modelo en cascada puede ser apropiado, en general, para proyectos estables (especialmente los proyectos con requisitos no cambiantes) y donde es posible y probable que los diseñadores predigan totalmente áreas de problema del sistema y produzcan un diseño correcto antes de que empiece la implementación.
• Funciona bien para proyectos pequeños donde los requisitos están bien entendidos.
• Es un modelo en el que todo está bien organizado y no se mezclan las fases. Es simple y fácil de usar.
• Debido a la rigidez del modelo es fácil de gestionar ya que cada fase tiene entregables

Inconvenientes del ciclo de vida en Cascada

• En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementación del modelo, lo cual hace que lo lleve al fracaso. Observación: el que no se siga una secuencia lineal, no es culpa del modelo, sino del responsable de adoptarlo. Existen variantes del modelo (hablaremos de ellas otro día), mejor adaptadas a según qué tipos de proyectos, así como otros modelos iterativos o ágiles que pueden ser utilizados de forma separada o combinada.
• Un cliente, no suele establecer al principio todos los requisitos necesarios. Esto provoca que el modelo no se ajuste al gran número de nuevos requisitos y cambios en otros requisitos existentes, que se van a producir. Sí, vale, pero hay que matizar que la culpa no es del cliente. Un buen analista debe llegar a conocer el negocio del cliente, y debe extraer sus necesidades. Si nos tenemos que basar en lo que nos cuenta el cliente de forma exclusiva, estamos listos (y además, estamos pagando innecesariamente un analista).
• Los resultados y/o mejoras no son visibles progresivamente, el producto se ve cuando ya está finalizado, lo cual provoca una gran inseguridad por parte del cliente que quiere ir viendo los avances en el producto. Esto pasa en todas las metodologías y ciclos de vida. Para eso existen prototipos, maquetas, y la documentación que se crea en las fases previas a la construcción. Además, existe la irracional creencia de que se está trabajando para el cliente final, cuando en realidad, también hay que tener en cuenta que el cliente de cada fase es el responsable de la fase posterior. Por ejemplo, es posible que el diseño técnico lo cree una empresa externa, y el desarrollo lo haga una tercera, las pruebas una cuarta, etc, etc.
• Existen requisitos que no se hayan tomado en cuenta desde el principio. Correcto. Siendo puristas, el ciclo de vida en cascada es imposible de llevar a la práctica. Pero para eso existen los procesos de gestión del cambio. Y no nos engañemos, TODOS los proyectos tienen cambios durante su ejecución. Y por mucho que hagamos prototipos, por mucho que usemos metodologías ágiles, por mucho que iteremos....ES IMPOSIBLE evitar que tras 20 iteraciones, 1 año de trabajo, de repente aparezcan N requisitos nuevos o cambios en los existentes. ¿Y qué queremos decir con esto? Sencillamente que la solución NO ES cambiar de metodología. LA SOLUCION ES aplicar la metodología que mejor se adapte a la situación del proyecto, realizar una toma de requisitos adecuada y adaptada, y definir y seguir un buen proceso de gestión de cambios.
• Muchas veces se considera un modelo pobre para proyectos complejos, largos, y por supuesto en aquellos en los que los requisitos tengan un riesgo de moderado a alto de cambiar. Genera altas cantidades de riesgos e incertidumbres. Efectivamente, aunque no es porque el modelo sea erróneo. Simplemente, si en un proyecto de 4 años, dedicamos 1 año a la toma de requisitos y análisis, es muy probable que tras ese año (si como se indica, hay muchos cambios), el resultado no se corresponda con la nueva realidad. Pero no nos engañemos, si no se tiene involucración del cliente, un modelo supuestamente adecuado, como sería el desarrollo ágil (SCRUM, XP,LEAN...), nos llevaría aquí también al desastre. Sin el feedback del cliente, cada sprint estaría construyendo una solución totalmente errónea, y todo el tiempo invertido en cada sprint estaría echado abajo cada poco tiempo.

¿Por qué empezó a fallar la metodología en cascada?

Esto casi lo vamos a dejar para un tercer post. Y no porque el modelo en cascada lo requiera. En sí, no lo merece: es obsoleto, ineficaz, innecesariamente simple... Sin embargo, si no entendemos lo ocurrido con este modelo, no vamos a entender qué modelos aplicar en nuestros desarrollos y qué riesgos existen en caso de adoptar uno u otro. Esto me recuerda esa frase típica de película:

"Para forjar nuestro futuro, no podemos ignorar nuestro pasado"

Desarrollo en cascada (I)

Tenía yo este post ya desde hace tiempo atascado. Quería hablar del desarrollo en cascada desde el punto de vista de la experiencia, y compararlo con las metodologías más actuales.. Y por fin me pongo a ello. Ya había hablado de las ventajas y desventajas de las metodologías ágiles como SCRUM o XP, y me parecía injusto no ser ecuánime con el waterfall.

Este post no le va a gustar a mucha gente. Está de moda el agilismo. Admitámoslo. Así que cualquier comentario que no defienda ciegamente SCRUM y no ataque despiadadamente a CMMi, metodologías tradicionales, desarrollo en cascada...causa desasosiego en las mentes que sólo ven blanco y negro. Pero el mundo no es blanco ni negro.

En un artículo que he leído hacer poco, leo algo que yo ya hace años que vengo observando. Aproximadamente cada década surge una nueva "guerra de metodologías":

• En los 70 desarrollo estructurado vs tradicional
• En los 80 desarrollo dirigido por datos vs desarrollo tradicional
• En los 90 desarrollo orientado a objetos vs tradicional
• En los 2000 el desarrollo ágil vs tradicional (algunos prefieren enfrentarlo a CMMi)

Pero claro, para los programadores más jóvenes, que no han desarrollado en los 80 ni en los 90, para ellos sólo existe algo "anterior". Ellos no han vivido las otras metodologías ni formas de trabajar. Algunos lo han estudiado en la universidad y se atreven a hablar de ello, pero no han sido conscientes, porque no lo han usado en su día a día (hablo de técnicas y metodologías de las llamadas "tradicionales").

En un post anterior, ya hablamos de las desventajas de SCRUM y de las metodologías ágiles en general. ¿Que qué estoy diciendo? Pues que efectivamente, existen puntos débiles en estas técnicas, por el mero hecho de que se basan en suponer ciertas características y restricciones, lo cual supone a su vez un riesgo y debilidad para nuestro proyecto.

Y ahora ¿qué? ¿A defender la obsoleta y moribunda técnica de desarrollo en cascada? Pues ni obsoleta ni moribunda, pero no hay porqué defenderla, sino entenderla en su contexto. En el desarrollo de software, echo de menos dejar de usar este tipo de abjetivos subjetivos por otros más profesionales como "apropiada para esto" o "inadecuada para lo otro". Y no me refiero al "depende" que muchos listillos de turno utilizan para intentar quedar bien, aunque no tengan ni puñetera idea de lo que hablan.

¿En qué consiste la metodología en cascada?
Esta metodología propugna que cada fase del ciclo de vida (SDLC del inglés Software Development Life Cycle), no debe comenzar hasta que esté totalmente terminada la fase anterior. Por ejemplo, no empezaríamos a programar, hasta tener la fase anterior de diseño técnico completada. ¿Y cuándo estaría completada? Pues cuando esté completado el entregable final, en este caso, el documento de "Diseño Técnico".

¿Qué presupone la metodología en cascada?
Este tipo de desarrollo presupone que en cada fase debemos estar preparados para la fase siguiente, porque:

• El cliente quiere ver una documentación estable (tal vez no sea el cliente, sino una PMO que quiere coordinar varios proyectos que se producen a la vez).
• Otros proveedores quieren también ver una documentación estable, porque han de interactuar con nuestro desarrollo, bien consumiendo servicios, o siendo proveedores de servicios que consumimos nosotros, y por tanto, han de conocer nuestras necesidades (por escrito, claro, porque las palabras se las lleva el viento).
• Tenemos equipos bien diferenciados: los analistas funcionales son expertos en ese tema, tienen un coste alto, y por tanto, han de "usarse" al máximo en las fases donde su labor tiene máxima necesidad: en la toma de requisitos y análisis. Posteriormente, pasaremos a utilizar otro tipo de perfiles diferenciados, los analistas técnicos o diseñadores técnicos, especializados en aterrizar los análisis funcionales en un documento técnico. Finalmente, los programadores, especializados en seguir un documento técnico bien preparado, construyen el código....y así hasta el final.
• La metodología en cascada presupone también que los cambios son costosos, por lo que hay que definir al máximo la solución al principio. Un cambio se comporta como un bug: aleja a la solución final del objetivo deseado. Es por ello, que cuanto antes se identifiquen, mejor.

¿Cuál fue el origen de la metodología en cascada? La causa
Todo lo dicho en el apartado anterior, hizo que en los años 90 sobre todo, la forma de trabajo de las factorías de software y las consultoras, provocara que la especialización por un lado, y el hecho de contar con personal poco experimentado por otro, esta técnica fuera necesaria y efectiva. Ojo cuando digo efectiva, porque aquí de nuevo se tirarán de los pelos los que solo ven agilismo: los proyectos de software siempre han fallado. Lo que digo no es que esta técnica fuera perfecta, sino que para las condiciones existentes, era muy adecuada. El "poder", la iniciativa, no estaba en los programadores. Los programadores iban y venían en los equipos. Era normal tener equipos de 10 personas al inicio del proyecto, y que muy pocos de ellos llegaran a ver el final del proyecto. La rotación era muy alta.

Y hasta aquí la primera parte. Vemos el origen. Pero ¿qué falló? ¿Porqué la metodología waterfall nos llevó a hacer proyectos con retrasos y poca calidad? Eso lo veremos en el siguiente post.

Evento Microsoft - Aplicar DI en MVC (23-03-2012)

Para los que no lo sepan, DI son las siglas en inglés de Dependency Injection (Inyección de Dependencias). El próximo 23 de Abril, tendrá lugar un interesante evento (online y gratuito), donde se explicará en detalle en qué consiste DI, y cómo usarlo en proyectos MVC.

El link de registro y más información:
https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032508692&Culture=es-ES

Evento Sharepoint (14-03-2011)

Este miércoles 14 de Marzo, tendrá lugar el evento online y gratuito: "CHARLA CON LOS EXPERTOS: TODO LO QUE SIEMPRE QUISISTE SABER SOBRE SHAREPOINT, PERO NO TE ATREVISTE A PREGUNTAR". Son 90 minutos, y comenzará a las 16h (GMT+1).
Es un buen momento para actualizar conocimientos en Sharepoint, o si os sentís con ánimos, lanzar dudas técnicas para que los mayores expertos en Sharepoint de habla hispana os puedan ofrecer soluciones.

Daros prisa, que se acaba el tiempo. El link de registro para este evento es:
https://msevents.microsoft.com/CUI/EventDetail.aspx?culture=en-US&eventid=1032506778&flag=1

Cómo no hacer un currículum

Vemos habitualmente currículums mal escritos, con información falsa, o alterada para dar una sensación de mayor experiencia y profesionalidad, de mayores éxitos de los logrados, etc.

Seguidamente vamos a ver algunos de los "errores" más habituales en los CV. Pero antes, veamos uno de los peores:

1. Desviar la atención. Esta técnica permite, cuando no se tiene experiencia o éxitos que comentar, desviar la atención en un punto supuestamente positivo, pero que no aporta nada realmente. Por ejemplo: si no tenemos ningún logro o éxito significativo que comentar en nuestro actual empleo, pero hemos tenido una buena evaluación o hemos sido promocionados de categoría, hay quien lo pone en el currículum, lo magnifica, y oculta de este modo la atención sobre otros elementos que podrían disminuir la buena impresión global. Es normal que un recién licenciado, ante la falta de otra información adicional, diga: "saqué matrícula de honor en el proyecto de carrera", o que diga las notas o hitos principales en su titulación. Vale, es normal, no tiene otra cosa de qué hablar. Lo que no es tan normal, es que gente que promulga experiencia y saber hacer, a la hora de la verdad ponga en el currículum este tipo de frases que contradicen dicha experiencia y saber hacer.

Viendo los currículums de gente con falsa experiencia, se suele encontrar frases como:

• "Experiencia multidisciplinar". Vale, la palabra suena bien, pero no me dice nada sin el matiz apropiado.
• Conocimiento y ¿experiencia? en diversas tecnologías y lenguajes de programación (por supuesto, siempre tratando de dar pocos detalles al respecto, y siempre de forma vaga respecto a los proyectos y a los períodos de aplicación). A ver señores, en nuestra vida laboral, y llevo en esto más de 15 años, no manejaremos más allá de 4 o 5 lenguajes principales. El resto, por supuesto que hemos estudiado, o usado puntualmente docenas de lenguajes. Pero el uso puntual no da el conocimiento, y la experiencia en los lenguajes se pierde en pocos años.
• Buenas evaluaciones de rendimiento recibidas en la empresa. ¿!!! Sí, bueno, claro que alguno de mis antiguos jefes me alabó, me subió el sueldo, o me subió de categoría (normalmente no todo a la vez)...¡pero no lo digo en el currículum! Mi profesionalidad no se mide por las subidas salariales que he recibido, sino por los retos superados (aunque es un reto que te suban el sueldo, creo que no estamos hablando de eso).
• Han llevado equipos de más de 20 personas ¿? Bueno, sí, una vez llegaron a estar 20 personas contando al fontanero, la secretaria, y la de la limpieza. Quizás han contado a todos los que han pasado por el proyecto, pero nunca estuvieron todos de forma coincidente. Pero sería más exacto decir de 3 a 20 personas, o usar la media del período. Incluso he visto gente de proyectos SCRUM con jerarquía nula, hablar de que han llevado "N" personas...¿pero llevar qué de qué? ¿Pues no era SCRUM? ¿No erais todos los del proyecto "iguales"? Seguro que si revisamos el currículum de los 20 del proyecto, resultará que todos han sido los jefes de los otros 19!!

Por supuesto que todo ayuda, pero no puede este tipo de información ser nuestra principal identidad.

A mí todo esto me da una sensación horrible. Un currículum no puede estar tan vacío. Se supone que habla de nosotros. Y si lo mejor que podemos decir de nuestra profesionalidad es que nuestro jefe nos hizo una revisión anual positiva...o que nos subió muchas veces el sueldo...pues cásate con tu jefe!

En serio, debemos siempre hablar de:

• Éxitos. Pero éxitos tangibles: logré "x" mediante "y". Ejemplo: puesta en el mercado de una nueva aplicación desarrollada por nosotros mismos (o explicitar nuestro papel en su desarrollo),  logrando una cuota de mercado "X", o logrando como clientes a los "TOP" del sector. O: desarrollo e implantación de una solución de xxxx que logró estar en el mercado durante casi 10 años y tener más de 20 grandes clientes del sector.
• Formación: certificados relativos al puesto que estamos, o al que queremos optar. Si somos analistas funcionales, a buenas horas me va a servir un certificado de programación. Claro que está bien, y aporta, pero si veo a un jefe de proyecto obteniendo certificados de programación, voy a tener serias dudas de si realmente ejerce como jefe de proyecto. Del mismo modo que si yo veo a un analista recién certificado o con cursos de ITIL, CMMi, PMBOK, etc., voy a pensar que en realidad, ejerce de jefe de proyecto (o que se prepara para dicho cargo, lo cual es loable). 

Continuemos con mentiras habituales en los currículums (fuente: link): 


2. Estudios no realizados. Dos de cada diez españoles han declarado que han falseado su nivel de estudios en su currículum. Se pretende con ello ganar puntos ante el seleccionador. Es una de las mentiras más fáciles de detectar, porque lo normal es que se soliciten los diplomas y certificados que correspondan a la formación declarada. Una de las más frecuentes es asegurar ser un experto en un determinado programa informático sin serlo. Se trata de un grave error ya que se quedará en evidencia al comenzar a trabajar y tener que manejar dicho programa.


3. Mentir en el dominio de idiomas. También es habitual indicar que se tienen conocimientos de idiomas que en realidad se desconocen. O bien poseer un nivel más elevado del que se tiene. En este caso, es inútil indicar tener más nivel del real, pues lo habitual es que, para chequearlo, el entrevistador se dirija al candidato hablando en el idioma que dice conocer. Además, hay que tener en cuenta que muchas empresas suelen hacer pruebas de nivel para verificar dichos conocimientos.


4. Exagerar las funciones anteriores. El 43% de los españoles añade en su currículum vítae más responsabilidades de las que ha asumido en sus anteriores empleos. Un ejemplo: alguien que ha trabajado como vendedor, pero que asegura haber sido responsable de equipo o director comercial de una determinada empresa. En este sentido, hay quien exagera también los años de experiencia ejercidos en una determinada función. Un ejemplo de ello puede ser asegurar que se ha trabajado en una empresa durante varios años cuando en realidad sólo fueron 15 días.


5. Empresas en las que nunca se ha trabajado. Un 18% de candidatos miente acerca de las empresas para las que ha trabajado. Según el estudio de CareerBuilder, se han dado casos de candidatos que han mentido diciendo haber trabajado en una determinada empresa sin saber que quien le entrevistaba fue director de la misma. También, con el fin de engordar el currículum, hay quien declara haber trabajado en empresas que no existen. Son más difíciles de detectar las mentiras cuando las empresas en las que se dice haber trabajado han desaparecido.

Si has llegado hasta aquí, te habrás dado cuenta que seguramente tú también has hecho algo de esto alguna vez. ¿Y? Pues nada. Esto son malas prácticas, pero no significa que cada cual lo vea justificado para un fin. Desde luego, que por traer el pan a sus hijos, la gente está dispuesta a todo. Y más con los tiempos que corren. Seguro que a vosotros se os ocurren, o habéis visto más malas prácticas como estas. El problema, simplemente reside en que los currículums se usan de modo comparativo. Y como tantas cosas en esta vida, los honestos, los experimentados, están en desventaja.

De todas formas, se puede dar la vuelta: se pueden usar estas ideas, de forma sutil, para destacar auténticas buenas prácticas y experiencias, auténticos hitos y logros personales, para un buen currículum. Y ese era al final, el objetivo de este post.

Top Mantra de los Arquitectos (II)

Este artículo es el segundo de una serie de dos. Para ver el anterior, clic aquí.

Tenía pendiente terminar este artículo que ya inicié hace algún tiempo. Vamos a ello. Estábamos hablando del Top 10 de los Mantras de un arquitecto de software. El post anterior repasaba los mantras del 1 al 5. Vamos a los números 6 al 10.

Mantra #6: ¿No estás en la capa de datos? Entonces no pongas SQL!
Tal y como establece SoC (Separation of Concerns), intenta poner cada cosa en su sitio, sin mezclar. Pon el código de acceso a datos y los detalles como connection strings, bien lejos. Tarde o temprano, tendrás que ocuparte de ellos, pero considera por separado las lógicas de negocio y presentación de cara a la persistencia. Siempre que sea posible, delega la persistencia en una herramienta ORM.

Mantra #7: la mantenibilidad es lo primero
A pesar de que ya hablé en mi post sobre los mitos de la mantenibilidad, Dino Exposito tiene más razón que un santo al establecer que si hay que elegir un atributo para el software, como arquitectos, ha de ser la mantenibilidad, por encima de la escalabilidad, seguridad, rendimiento y testeabilidad. Si código y la arquitectura son mantenibles, el resto se puede conseguir más tarde (no así al contrario)

Mantra #8: el input del usuario es pura maldad
Tal y como comenta Dino en su libro, si existe una forma en que los usuarios hagan algo mal, encontrarán la forma de hacerlo. Si te suena esta afirmación a la ley de Murphy: SI, así es.

Mantra #9: Optimización Post-Mortem
Tal y como indica Dino (y estoy totalmente de acuerdo), empezar a diseñar un sistema con la optimización en mente es un error. Yo voy a ir un poco más allá: es un signo de inmadurez. Y me refiero a inmadurez profesional, a falta de experiencia. Tratar de que un sistema crezca siendo óptimo desde el principio es una buena forma de perder el foco de lo que realmente es importante. Es mucho más importante (ver mantra #7) que sea mantenible, ya que ante cualquier cambio, podemos optimizarlo. Un software muy optimizado desde el principio, seguramente no será mantenible y por tanto, ante cualquier cambio (que los habrá, no os preocupéis), dejará de ser óptimo. Y por desgracia, en esa situación, ya poco habrá que hacer.

Mantra #10: La seguridad y testeabilidad, han de estar "por diseño".
Aquí poco hay que decir. Es tan radicalmente cierto, que incluso hay un estándar de la International Organization for Standardization (ISO) que explícitamente, lo establece. Un sistema, por mantenible que sea, es muy complicado (y por tanto caro) que sea seguro a base de hacer cambios. Lo mismo la testeabilidad. Si no empiezas diseñando para que sea testeable, con sus pruebas unitarias, con la arquitectura adecuada...no podrás de repente implantar la testeabilidad.

Y nada más. Que os recomiendo encarecidamente este libro. Es de los pocos, junto con los del eterno Steve McConnell, que merecen la pena comprarse y leerse más de una vez. ¡Ah, y no me llevo comisión por decir esto, eh! Más info del libro:

by Dino Esposito and Andrea Saltarello

Microsoft Press. (c) 2009

Microsoft .NET: Architecting Applications for the Enterprise

SQL Server 2012 ya está aquí

Im-presionante. Sencillamente impresionante. Estoy ahora mismo viendo una de las presentaciones técnicas correspondientes al evento de lanzamiento de SQL Server 2012. Ésta en concreto (hay más de 30, para no aburrirse), trata de la nueva característica de ColumnStore Index.

Se trata de una nueva técnica de almacenar los datos, facilitando la compresión, el acceso y la ejecución de consultas (incluso mediante paralelismo). Para no enrollarme (y así no perder el hilo de la señora), nos acaba de hacer una demo de una compleja Query: 1:29 segundos sin ColumnStore Index. Con esta característica activada...2 segundos!

Además, los datos de compresión (volumen real de los datos en disco), están en casos reales entorno un ratio de entre 15:1 y 4:1

¿Qué supone esto? BI más ágil. Menos esperas.

¿Cuándo son más útiles los ColumnStore Index?
a) Workload

• Principalmente lectura
• Principalmente incorporación de datos nuevos
• Star Join Queries
• Consultas de agregación de grandes volúmenes de datos

b) Workflow

• Permite la partición para tratar nuevos datos
• Caso típico: carga nocturna

c) Data selection

• Large fact tables
• Large dimension tables

El tema es que cuanto mayores son las tablas a tratar, algo especialmente cierto en entornos BI, mayor es el beneficio obtenido de esta técnica.

Best Practices: Crear un ColumnStore Index

• Incluir todas las columnas en el ColumnStore Index
• Convertur los datos decimal/numeric a precisión <= 18
• Usar integer donde sea posible
• Grandes cantidades de memoria para crar el columnStore Index
• Crear el ColumnStore Index a partir de un Clustered Index

Y bueno, ya vale. Ahora a digerir toda esta información!!

Lanzamiento de SQL Server 2012

En un evento multitudinario, Microsoft va a presentar el próximo 7 de Marzo de 2012 su nuevo sistema de servidor de base de datos (SQL Server), en su encarnación 2012.

Esta vez, y como ya empieza a ser habitual, Microsoft ha tirado por la ventana y ha apostado por una presentación por web:

• Más de 30 eventos
• Foros con expertos que darán respuestas a las dudas
• Premios, que serán alcanzables mediante los puntos que se obtienen al participar en las diversas actividades que tendrán lugar.

Más información de los eventos, y página de registro, están disponibles desde cualquiera de los sitios internacionales/locales de Microsoft SQLServer. Uno de ellos (y en castellano):
http://www.sqlserverlaunch.com/LATAM/Home

AADL: un lenguaje de modelado para Arquitectos de Software

Hoy voy a hablar del AADL, un lenguaje para nada nuevo, y que sin embargo es bastante poco conocido. Vamos a revisar algunas de sus características generales:

• Existe como estándar internacional desde 2004.
• Nació como lenguaje orientado a entornos de aviónica, pero actualmente su alcance es mucho más amplio.
• Está promovido por el SEI
• Pretende estandarizar en un lenguaje de modelado, el diseño de arquitecturas (hardware y software).
• Nació para sistemas embebidos, por lo que admite hardware y software.
• Es un lenguaje textual y gráfico.
• Incluye un formato de intercambio XML/XMI que permite interoperabilidad con herramientas del mercado
• Dispone de una extensión para el modelado de sistemas resistentes/tolerantes a fallos.

Puede utilizarse para modelar:

• Sistemas empotrados, como arquitectura de sistema basada en componentes.
• Las interacciones de los componentes mediante flujos, llamadas de servicio y de acceso compartido.
• Ejecución de tareas, sincronización exacta de comunicaciones.
• Plataformas de ejecución, application binding, modelos operativos y configuraciones tolerantes a fallos.

Hay muchos otros lenguajes de modelado, pero éste me ha parecido curioso y me apetecía echarle un vistazo y compartirlo.

Ejemplo.
A continuación, un ejemplo sacado de la página de AXLOG:

system system1

end system1;

system implementation system1.impl

    subcomponents

        p1: process process1.impl;

        p2: process process2.impl;

    connections

        cn: data port p1.outport -> p2.inport;

end system1.impl;

process process1

    features

        outport: out data port;

end process1;

process implementation process1.impl

    subcomponents

        t1: thread thread1.impl;

    connections

        cn: data port t1.outport -> outport;

end process1.impl;

process process2

    features

        inport: in data port;

end process2; process implementation process2.impl

    subcomponents

        t2: thread thread2.impl;

    connections

        cn: data port inport -> t2.inport;

end process2.impl;

thread thread1

    features

        outport: out data port;

end thread1;

thread implementation thread1.impl

end thread1.impl;

thread thread2

    features

        inport: in data port;

end thread2;

thread implementation thread2.impl

end thread2.impl;

Os dejo con unos enlaces en los que podréis ampliar información:
http://en.wikipedia.org/wiki/Architecture_Analysis_%26_Design_Language (Nota: para ser Wikipedia, la verdad es que la información que da es bastante pobre a fecha 5 de Marzo de 2012)
http://www.sei.cmu.edu/dependability/tools/aadl/
http://www.axlog.fr/aadl/presentation_en.html (este enlace sí que tiene bastante información, ya que AXLOG es una firma miembro del comité de estandarización de AADL).

Excusitis: otra enfermedad del desarrollo de software

Igual que existe la profesión más antigua del mundo, hoy hablamos de una de las más antiguas enfermedades en el desarrollo de software: la excusitis.

Parece que tenemos excusas para todo. Somos ingenieros. Tenemos la más alta formación, sin embargo, las más estúpidas excusas parecen salir una y otra vez de nuestras bocas de forma habitual. ¿Cuál es el problema? Como siempre, la causa más probable es el error humano.

Hay gente, que consigue prosperar a base de dos máximas:

• Si algo sale bien, les falta tiempo para dar la cara para conseguir reconocimiento y fama.
• Si algo sale mal, echan mano de la lista de culpables (que siempre tienen a mano), para conseguir su chivo expiatorio. De hecho, a veces consiguen incluso culparlos en la distancia (frases del estilo "yo no he trabajado con él, pero...<poner aquí cualquier frase que desprestigie al chivo expiatorio>")

Como ya comentaba en mi anterior artículo "¿Por qué fallan los despliegues en producción?", no debemos buscar los culpables muy lejos. Sin embargo, resulta mucho más fácil buscar culpables, que soluciones. Y las soluciones, están siempre en el mismo sitio: formación, buenas prácticas, usar tecnologías y métodos seguros y probados, y ser sobre todo, profesionales.

Veamos las excusas más habituales:

1. Reinicia, y si sigue pasando..vuelve a llamarme
2. El análisis funcional estaba mal
3. Es que alguien no está a la altura del resto y está haciendo que mi equipo no rinda bien.
4. Pero...¿y eso para qué lo quieres?
5. Ya se que no lo pidió nadie...¿pero te gusta?
6. Funciona...pero no lo he probado
7. ESTO...no puede ser la causa de ESO.
8. Es solo una desafortunada coincidencia
9. Pero si ese módulo no se ha tocado en meses!
10. Es que ese módulo está sin terminar
11. Esto siempre ha funcionado bien...
12. Yo no he tocado nada...
13. En mi equipo sí que funciona...
14. Pero si yo ya lo probé!
15. Pero si esto pasó todas mis pruebas unitarias!
16. Estás usando la última versión?
17. Este no es mi último código...¡alguien lo cambió!
18. Nunca había visto este error antes...
19. Ese no es mi código!
20. Creo que esto nunca había funcionado antes...
21. Creo que todavía no se han hecho los cambios en la base de datos.
22. Pero...¿eso estaba incluido en el diseño funcional?
23. Nadie me lo dijo.
24. Pero...¿no estarás usando el Internet Explorer?
25. No es un fallo...¡es una característica!
26. Seguramente hiciste algo mal para que fallase así.
27. Nadie me dijo que debía hacer pruebas unitarias.
28. Eso no estaba en mi plan de pruebas
29. Ayer funcionaba
30. ¡Ya os dije que no me iba a dar tiempo de probarlo!

Fuente: http://whizzodev.blogspot.com/2008/02/top-13-excuses-for-software-developer.html

ASP.NET MVC (III)

Este artículo forma parte de una serie. Podéis ir directamente a las partes 1 y 2.

Hoy vamos a ver MVC desde otro punto de vista. Primero, una comparación con los Web Forms tradicionales. En la figura siguiente, se ilustra bastante mejor esta significativa diferencia:

En primer lugar hacer notar que ya no tenemos los eventos, el ciclo de vida de los web forms a los que estábamos ya tan acostumbrados. Ya se rompe por fin el patrón de trabajo (artificial por otro lado), que habían impuesto estos web forms:

1. Procesar una petición
2. Entrar en el ciclo de vida del documento
3. Tratar el evento
4. Pintar los controles
5. Devolver el resultado

Además, el patrón de trabajo de Web Forms nos había acostumbrado a otras cosas totalmente ajenas a la realidad de la web, basándose en esa capa virtual:

1. RAD
2. Controles ricos
3. Modelo dirigido por eventos (lo comentado justo hace un momento)
4. Desarrollo parecido a Windows Forms. Sin querer, estamos creando la ilusión de que trabajamos con una especie de formularios Windows. Nada más falso, tal y como hemos visto en el ciclo de vida de los Web Forms, justo hace un momento.
5. Difícil implementación de TDD. No es nada imposible, pero la verdad es que con los Web Forms había que hacer auténticas piruetas para establecer un TDD en condiciones.
6. Páginas pesadas (por culpa del viejo conocido ViewState).

Aquí hacer un inciso. Anque MVC está muy orientado al uso extensivo de HTML5, CSS3 y Javascript, debemos ser conscientes de una serie de realidades:

1. HTML5 no está disponible para todos los navegadores, hay que validar las funcionalidades antes de usarlas.
2. CSS3 evoluciona mucho más lento que HTML5. TODAVIA NO ES UN ESTANDAR, sino un borrador. Hay que validar el soporte de sus funcionalidades en lugar de validar la versión del navegador o el tipo. No se trata de que Chrome o Firefox o X soporten CSS3...es que CSS3 aún no existe como tal, y está sujeto a cambios.
3. JavaScript: NO ES UN ESTANDAR! El estándar actual, es ECMA-262 (versión 5, Dic. 2009). Y a él nos tenemos que aplicar. Todo lo demás, será favorecer que nuestras páginas funcionen en un navegador y en otros no.

Estructura de una aplicación MVC

Volviendo a MVC, vamos a ver su estructura. Con MVC, trabajaremos con proyectos, no con sitios web ("web sites"). Es lo primero que observaremos, ya que al crear un sitio web con Visual Studio, lo haremos a través del cuadro de diálogo "Add New Project".

La mayoría de los contenidos son ya conocidos en un proyecto ASP.NET (como App_Data, Web.Config, scripts, etc.) Sin embargo, hay carpetas específicas de un proyecto MVC:

• Content: en esta carpeta tendremos los archivos estáticos, como imágenes, hojas de estilos, y archivos html puros.
• Controllers: en esta carpeta, encontraremos todas las clases controlador. En general, por cada entidad en nuestro modelo, tendremos un único controlador. Además, podemos definir otros controladores para otras acciones como: LoginController, HomeController, NavigationController...Como podéis ver, para las clases controlador, se suele utilizar la convención NombreEntidadController.
• Models: Aquí se encuentra el código que representa el modelo de negocio. Este código interactúa con la base de datos y procesa las reglas de negocio. Si usamos Entity Framework, tendremos los archivos EDMX aquí. Por supuesto, podremos tener una dll separada, referenciada por el proyecto que contenga el modelo, por lo que en ese caso esta carpeta estaría vacía.
• Views: Aquí encontraremos las vistas (páginas ASPX, ASCX y master pages). Normalmente, la convención indica que hagamos una carpeta separada para cada controlador. Aquí también hay una carpeta llamada Shared, que se usa para vistas comunes a varios controladores (como una master page).



Windows 8 Consumer Preview

Pues ya está aquí. Y va a ser el tema de la temporada. El nuevo Windows 8 está disponible para descarga aquí en su modalidad Consumer Preview.

Una descripción detallada de novedades, la tenéis aquí.

Pues hala, a disfrutar hasta que caduque esta release, o deje de estar disponible para descarga. Recordad que como "Consumer Preview", esta versión de Windows no tiene coste, pero no deja de ser una BETA. Así que tomad todas las debidas precauciones, y leeros las notas de la release.

Hay muchísimas novedades, entre las que podemos citar:

• Windows Store. Ahora será posible descargar aplicaciones como si estuvieramos en el móvil. Seleccionar, pagar (si no es gratis), descargar....y a disfrutar.
• Metro Style. Nueva interfaz.
• Búsquedas mejoradas.
• Mayor seguridad. Tanto en navegación como en el PC.
• Nuevo Internet Explorer.
• Novedades para ITPros.
• Charms: una nueva forma de interactura.

Saludos