Julio 27th, 2010

Frases celebres del desarrollo

Las 3 grandes mentiras del programador
1. El programa está completamente probado y libre de errores
2. Estamos trabajando en la documentación
3. Por supuesto que podemos modificarlo
– Anónimo

“Debugging es dos veces más difícil que escribir el código en primer lugar. Entonces si escribes el código tan astutamente como sea posible, no eres -por definición- tan listo como para debugearlo.”
– Brian Kernighan

“Sólo hay dos tipos de lenguajes: aquellos de los que la gente se queja y aquellos que nadie usa.”
– Bjarne Stroustrup

“Cualquier tonto puede escribir código que un ordenador entiende. Los buenos programadores escriben código que los humanos pueden entender.”
– Martin Fowler

“Hay dos formas de diseñar software: la primera es hacerlo tan simple que obviamente no hay deficiencias y la segunda es hacerlo tan complicado que no hay deficiencias obvias. La primera forma es mucho más difícil.”.
– C.A.R. Hoare

“Mucho del software hoy en día se parece a una pirámide egipcia: con millones de ladrillos apilados uno encima del otro, sin integridad estructural y hecho por pura fuerza bruta y miles de esclavos.”
– Alan Kay

“Medir el progreso de la programación por líneas de código es como medir el progreso en la construcción de aviones por el peso.”
– Bill Gates

“Si deseas empezar y desarrollar algo grandioso, no necesitas millones de dólares de capitalización. Necesitas suficiente pizza y Diet Coke en la nevera, una PC barata y trabajo y dedicación para realizar tu idea.”
– John Carmack

“Los programas deben ser escritos para que la gente los lea y sólo incidentalmente, para que las máquinas los ejecuten.”
– Abelson / Sussman

“Pregunta: ¿Cómo se atrasa un año un proyecto grande de software? Respuesta: Un día a la vez.”
– Fred Brooks

“Nadie debe empezar un proyecto grande. Empiezas con uno pequeño y trivial y nunca debes esperar que crezca; si lo haces solamente sobre-diseñarás y generalmente pensarás que es más importante de lo que lo es en esta etapa. O peor, puedes asustarte por el tamaño de lo que tu esperas que crezca. Así que empieza pequeño y piensa en los detalles. No pienses acerca de la foto grande y el diseño elegante. Si no resuelve una necesidad inmediata, seguramente está sobre-diseñado. Y no esperes que la gente salte a ayudarte, no es así como estas cosas funcionan. Primero debes tener algo medianamente usable y otros dirán “hey, esto casi funciona para mí” y se involucrarán en el proyecto.”
– Linus Torvalds

Añadidos:
“Programa siempre tu código como si el tipo que va a tener que mantenerlo en el futuro fuera un violento psicópata que sabe donde vives.”
– Martin Goldin

“La mayoría de expertos coinciden en que la forma más probable de que se destruya el mundo es por accidente. Ahí es donde entramos los informáticos. Nosotros causamos accidentes.”
– Nathaniel S. Borenstein (Programming as If People Mattered)

El problema de las soluciones “provisionales” es que pueden convertirse en “definitivas”, porque aplicar la solución “definitiva” viola el principio de “si funciona, no lo toques”
–Miguel Armas (Kuko)

“Si pagas cacahuetes, obtienes monos”
– James Goldsmith

“Si la depuración es el proceso de eliminar errores, entonces la programación debe ser el proceso de introducirlos”
– Edsger Dijkstra

“Cuando evaluamos un producto, las personas solemos dar una importancia ridículamente alta a la belleza y a la estética. Esta es una de las razones por las que los iPods, y ya que estamos, Keanu Reeves, son tan enormemente populares.”
– Joel Spolsky

“Emplea tu tiempo cultivándote a través de los escritos de otros, así ganarás fácilmente lo que para nosotros ha sido una dura tarea”
- Sócrates, parece que ya picaba código por el 400 a. C.

Julio 27th, 2010

Módelo Vista Controlador y algunas variantes

Flex es un framework creado para poder llegar a usar otros frameworks. Nos centraremos en este artículo en la base de otros frameworks, como PureMVC o Cairngorm, esta característica es el patrón Módelo Vista Controlador (MVC). Analizaremos este patrón que tanto nos gusta y entonces veremos algunas otras aproximaciones para compararlas y adjuntaré proyectos de ejemplo para entender el concepto que representa cada uno.

Módelo Vista Controlador (MVC)

El Módelo Vista Controlador es el patrón arquitectural más usado en la ingeniería del software. Este patrón nos separa el modelos de datos, el modelo de la capa de presentación (vista) y de la parte de control.

De este modelo podemos decir, que gestiona la información y advierte a las otras capas de cambios en sus datos. Representa el dominio de datos. La vista representa gráficamente el modelo para que el usuario pueda interactuar él, es la interfaz de datos. El controlador recibe las peticiones de la vista y le responde actualizando el modelo de datos. Debido a que la vista observa los cambios en el modelo de datos, esta actualiza sus componentes en función de éstos.

La finalidad de este patrón será la de conseguir un bajo acoplamiento en sus aplicaciones. Este lo logra desacoplando los modelos de las vistas, reduce la complejidad en el diseño arquitectural e incrementando la flexbilidad y mantenimiento del código.

La aplicación para el ejemplo será esta:

Módelo Vista Presentación (MVP)

Módelo Vista Presentación

Este patrón es un derivado del anterior. Está centrado en la interfaz de usuario y también pensado para facilitar el la unidad de testeo y mejorar la separación conceptos en la presentación de la lógica del programa. Genera una implementación limipia del patrón Observer entre el modelo y la vista.

El modelo funciona como una interface que define los datos que serán mostrados luego en la vista. La vista es una interface que nos muestra los datos del modelo y lanza llamadas a la capa presentacion para que luego actúe con los datos. La presentacion recupera los datos del modelo y los modera y hacia la vista.

Normalmente, la vista instancia su objecto presentacion con el que se relacionará y luego le proporciona una referencia suya.
El grado de lógica permitida en las vistas variara en función de la implementación que usemos: podremos hacer que la vista sea totalmente pasiva, alegando todas las operaciones a la presentacion. Otras versiones del MVP nos permiten más autonomía a la vista.

Si nos centramos en un punto de vista de capas, la presentacion se consideraría la capa de aplicación entre el modelo y la vista.

El creador del patrón MVP, Martin Fowler, decidió separarlo en dos patrones de presentación que ya hemos tratado en madeinflex, son el supervising presenter y el passive view.

MVC vs MVP

Los une la idea de que el modelo alberga los datos y la vista los representa. Tanto el controller como el presenter se encargan de coordinar la aplicación y es en estas clases donde está la diferencia: el Presenter tiene más responsabilidades, maneja los datos del modelo y trata las propiedades de la vista que recibirá como parámetro.

Modelo Vista Adaptación (MVA)

Como en los dos patrones anteriores, se pretende separar el modelo de datos de la vista para poder realizar cambios en la vista y que estos no afecten al modelo de datos.

MVA y MVC intentan solucionar este problema con dos aproximaciones diferentes:

  • MVC mantiene un estructura triangular entre el modelo, la vista y el controller, en la cual las tres entidades serían los vértices del triángulo y las aristas las vías de comunicación entre éstas.
  • MVA lo soluciona de otra forma, lo hace mediante una estructura lineal en la cual en una punta estará la vista, en la otra el modelo y en el centro el adapter o mediating controller, pero se evita la comunicación directa entre la vista y el modelo.

Así pués, en este modelo, la vista está totalmente separada del modelo de datos y estas entidades sólo se pueden comunicar a través el adapter, dicho de otro modo, sólo el adapter tiene conocimiento del modelo y de la vista.

Con esta separación de comportamientos, conseguiremos que una amplia variedad de vistas puedan acceder indirectamente al modelo de datos mediante el mismo adapter. Las vistas también se olvidan del modelo de datos, ya que es el adapter quien las comunica con éste.

Esto también nos permite poder usar diferentes adapters para cada par vista / modelo. Un ejemplo podría ser la aplicación de una entidad bancaria, para cada una de sus delegaciones, puede ser que con los mismos datos y la misma vista se tengan que manipular los datos de maneras diferentes, para eso podremos tener diferentes adapters sin tener que modificar ni la vista ni el modelo de los datos.

MVA también es conocido como “mediating-controller”. Hay quien cree que como base sigue la misma idea que MVP, aunque hay gurús del software que se matan y defienden diferencias entre ellos.

Aquí os dejo un enlace de un proyecto de ejemplo para que podais analizarlo vosotros mismos.

Autor: Sergi Dote Teixidor