Ruby Midwest 2011 - Keynote: Architecture the Lost Years by Robert Martin

ayudenme a recibir al tio bob al escenario

una de las ventajas de aparecer último

es que puedes corregir a los que estubieron antes

¡cucumber no es lento!

a quien haya dicho eso

probando a travez de la UI es lento

levantar rails cada ves que ejecutas un test es lento (y también estúpido)

eso es lo lento, cucumber es un pequeño paquete muy liviano

que hace una pasada con expresiones regulares, llama una función y entra y sale rápido

cucumber no es lento

alguien dijo que sería bueno que nuestra comunidad fuera diversa

miremos al rededor de nosotros, ¿Cuál parece ser la característica que se expresa de manera más frecuente que otras?

si, bello facial ...

bueno, déjenme explicarlo de esta manera

si quicieras atraer específicamente a una audiencia más diversa dentro de los desarrolladores

algo que quicieras evitar es decir grocerías durante una presentación

público: ¡totalmente en desacuerdo! (usando grocerías)

no voy a entrar en esa competencia

yo sé lo que se debe hacer con los desarrolladores de mala calidad

público: ¿lo mismo que con los jefes de proyecto?

Bob: no, no lo mismo que con los jefes de proyecto

¿y qué es todo eso sobre VIM?

quién usa VIM por aquí

¡¿Qué mierda les pasa a ustedes gente?!

Yo quería dejar de usar ese editor hace años atrás y ahora todo el mundo quiere empezar ausarlo...

o bueno...

un último comentario sobre eso. ¿Quién ve House?

¿A quién le gusta ese programa?

ok, ¿Quién de ustedes se identifica con el personaje de House?

House es un doctor que es la misma escencia de un imbécil.

solo imagínense que es la persona más iracible, negativa, horible y suertuda que puedan imagninar

explicó su comportamiento un par de años atrás en uno de los episodios

dijo: "soy tan bueno que no pueden desaserce de mi así que soy libre de actuar como me plazca"

de hecho es como él mide que tan valioso es

prueba su valía haciéndose tan repugnante y luego observando como no lo despiden.

porque es simplemente tan bueno.

House es un perdedor...

tengan esto en mente los que piensen "¡Ah, puedo romer todas las reglas que quiera!"

¡Puedo llegar a la hora que quiera e irme a casa a la hora que me plazca! ¡Puedo programar borracho!

pues lo siento, House es un perdedor.

a propósito, se me ocurrió una regla hace harto tiempo atrás sobre alcohol y programación: "lo mismo que a pilotos"

El nombre de esta presentación ... Oh a propósito darles una lección sobre ciencia primero..

¿Alguien sigue esto de E-Cat?

Bueno, es facinante, ¿si?

público: he leído al respecto.
Bob: Has leído al respecto! ok, bueno

esto es probablemente un Hoax. Probablemente.

Bueno si tubiera que darle una probabilidad, sería como 9/10 para Hoax y 1/10 para verdad,

pero el 1/10 me tiene inquieto, por cierto esa no es una de las 7 palabras de las que habla George Carling

la idea aqui es hay una persona en Italia cuyo nombre es Andrea Rossi

y por varios años ha estado diciendo que puede generar energía

mediante hacer pasar hidrógeno calentado sobre Niquel

y que los átomos de hidrógeno se fusionan con los de niquel para producir cobre y liberar energía.

esta energía se libera en forma de rayos gamma y calor y los rayos gamma pueden ser absorbidos y producir más calor

pero no hay otra forma de radiación que sea emitida, aparte de protones, neutrones o electrónes.

no es radioactiva, es solo esta reacción nuclear muy interesante.

Por supuesto que la mayoría de los científicos recuerda el horrible fiasco de la fusión en frío en 1989

todos muy escepticos, pero el dice "no, lo puedo hacer y puedo probarlo".

El 28 de octubre juntó a un grupo de profesores, a alguien que comparía su generador de 1Mw

juntó a un montón de reporteros e inició este generador y logró hacer hervir muchos litros de agua

400kw o 400kw hora de energía, no recuerdo, un montón de agua que hirvió

y luego apagó la máquina y el cliente inmediatamente pagó por el generador

y aun todo esto está rodeado de un montón de secreto ... hay un catalizador

del que el no habla al respecto, no nos cuenta que es...

Probablemente una mentira (Hoax), probablemente muy bueno para ser verdad.

Pero, alomejor no...

Investiguen sobre esto, es interesante. Quizás sea mentira ...

sea muy bueno para ser verdad... yo miro muchas cosas que parecen ser muy buenas para ser verdad

y digo "bueno, parecen muy buenas para ser vedad", pero luego veo a mi señora ...

¡Así es como obtienes diversidad en un grupo!

Lo que miran en pantalla es la estructura de alto nivel

de una aplicación Rails que hace algún tiempo atrás escribí

denle una mirada a los directorios ¿Qué es lo que ven?

bueno, ven controllers y esperan ver controllers en una aplicación Rails cierto?

y ven models y ven views y algunas otras cosas como helpers y util

bueno pueden ir al spec de por aquí porque por supuesto es dirigida por tests

¿Quién hace desarrollo guiado por pruebas?

hmmm vamos a tener que conversar...

pueden ver que también hay pruebas de controllers, models, bla bla bla, ok

¿Que es lo que ven?

si fuera a mostrarles esto y no les digiera que es una aplicación Rails

¿Podrían reconocer que de hecho es una aplicación Rails?

oh, si, se ve como una aplicación Rails. Bueno, quizás haya otros tipos

de aplicaciones que tengan esta estructura de directorios

pero es una aplicación Rails, así que ahora mi pregunta a Uds. es:

¿Porqué la estructura de alto nivel en la aplicación debiera comunicarte esto?

¿Qué es lo que la aplicación hace?

No hay ninguna pista aquí

"Substitute" es el nombre del proyecto

bueno, eso no es muy útil

aparentemente el nombre del cliente es "Angela", quizás...

pero nada en el alto nivel de la aplicación, el nivel más visible, al cual todos van primero

nada aquí habla sobre lo que la aplicación hace.

Es inmediatamente reconocible como una aplicación rails

así que quizás lo más importante sobre esta aplicación es el framework sobre el que está construido.

Y sobre el resto no nos preocupamos mucho.

Rails es un framework Web, ¿Qué es la web?

¡Gracias! ¡Si! es un mecanismo de entrega (es lo que dice en el slide)

La web es un detalle, la web no es particularmente importante para tu aplicación

la web es simplemente la forma en la que tu aplicación obtiene información del usuario

y devuelve información hacia el usuario. La web es una tubería.

No es nada más que una tubería. No es la estructura central de tu aplicación

No es la gran estructura que define tu aplicación y la convierte en lo que es.

La web es solo un tonto detalle.

y aún así, domina nuestro código.

Podemos observar una aplicación web y saber que es una aplicación web

a causa de ese directorio de controllers. No otro tipo de aplicación tendría

un directorio controllers en el nivel superior, especialmente si hay modelos y views al rededor

vamos a hablar sobre Model View Controller (MVC) y la horrible bastardización que ha ocurrido con él

vean este dibujo de alto nivel de una librería (de libros)

si no tubiera la palabra "librería" en el título podrías mirar esto y decir

" hay una gran entrada por acá, hay unas oficinas, eso parece un escritorio, donde la gente podría llegar y registrar cosas"

"parece que allí hay algunas estanterías, oh, parece que eso es una librería"

La estructura de alto nivel en una librería te mostraría que es una librería.

o ¿Qué tal una iglesia?

¿Hay siquiera una tenue duda de que eso es una iglesia?

tienes una gran entrada, puedes ver el altar, puedes ver los confesionarios.

¡Esta es una iglesia!

La estructura de alto nivel de este edificio grita su propósito a quien lo mira,

pero la estructura de alto nivel de mi aplicación Rails no grita su propósito.

grita cuál es el framework con el que fue contruído. grita Rails.

Esto es muy bueno para DHH no tan bueno para ti.

¿Por qué esto sucede?

¿Por qué creamos arquitecturas que reflejan el framework que a su vez reflejan el mecanismo de entrega

y no reflejan la aplicación?

¿Acaso no estamos construyendo una aplicación que tiene un propósito?

¿No es la arquitectura acerca del propósito?

Ciértamente lo es desde el punto de vista de la construcción. No es también cierto del ...

oh, es mi señora que me llama ... disculpen, aparé mi teléfono.

¿En qué estaba?

¡Graciás! ¿Acaso no es la arquitectura de la aplicación completamente sobre el propósito de ésta ?

¿Porqué no debiéramos ver ese propósito al nivel más alto del código?

El año era 1993

Esta persona, llamada Ivar Jacobson escribió un libro: "Ingeniería de software orientada al objeto"

"Una aproximación desde los casos de uso"

¿Qué estaba sucediendo en 1993?

¡No había web! la web aun no había nacido o quizás lo había hecho, quizás, no recuerdo

una persona escribió una página web y luego se expandió como fuego

pero no había web en el momento todos estábamos haciendo C++ o C o alguna cosa horrenda como esas

haciendo aplicaciones de clientes pesados

Y aquí llega este sujeto y escribe este libro y es un libro facinante

y resuelve el problema de la arquitectura

no es el primero en hacerlo, no será el último, pero en este libro

habla sobre como obtener el propósito de la aplicación en el nivel superior

que sea la abstracción principal sobre la que construímos.

El lo llamó "una aproximación dirigida por los casos de uso"

¿Qué es un caso de uso?

bueno eso es un caso de uso

nada muy espectacular sobre ellos

es decir, le das un nombre, hablas un poco sobre los datos que es pasada

hacia el caso de uso "crear orden", el id de cliente, alguna info de contacto del cliente

y algunas otras cosas

hablas un poco sobre como el sistema va a responder cuando obtenga esta solicitud

"el operador ejecuta un comando "Crear Orden" con los datos anteriores"

"el sistema valida todos los datos"

bla bla bla, es solo un conjunto de frases simples

que describen cómo el sistema responde cuando el usuario hace esta pequeña acción

y tiene unos comportamientos alternativos en casos excepcionales

solo formas de controlar errores y otras cosas

y Jacobson utiliza varias páginas de su libro solo para describir lo que esto es

¿Quién ha hecho casos de usos antes?

Alguien recuerda esto? wow varios de ustedes.

¿Cuál es la diferencia entre un caso de uso y una historia de usuario?

si, el nombre.

Son básicamente lo mismo solo que la historia de uso

comienza como algo muy pequeño y evoluciona en un caso de uso.

gradualmente tomamos la historia de usuario que comienza como una frase

y durante el curso del proyecto agregamos un par de frases a el y lo

convertimos en algo que se ve como esto típicamente a través pruebas de aceptación

y luego implementamos el caso de uso

Lo que Jacobson dijo fue "miren, esta es la abstracción central de su aplicación, así que eso podría ser un objeto"

El lo llamó un controller, yo lo llamaría un objeto interactor.

Lo llamaría así para que no se confundieran con MVC

así que sus objetos controller son mis interactors

son objetos que implementan un caso de uso.

los interactors tienen reglas específicas de negocio para la aplicación

¿Qué significa tener reglas específicas de negocio para la aplicación?

¡No pueden estar en un framework! ¡Claramente!

van a ser reglas de negocio que estás colocando por el propósito de la aplicación

¿Que sería una regla de negocio no específica de la aplicación?

Una regla que no fuera específica a la aplicación.

Bueno, puedes tenerlas, puedes tener...

Perdón!

Entidades

Entidades que representan objetos de negocio

que pueden pertenecer a más de una aplicación

y en cada aplicación en la que la entidad apareciera podría

encapsular las mismas reglas

así que colocas lógica de negocio agnóstica de la aplicación en tus entidades

y colocas reglas de negocio específicas de la aplicación en interactors

y noten que hay una dependencia entre ellos.

El interactor sabe sobre la entidad.

Bueno, que sería una entidad, algo como una orden, o un cliente.

o, programadores Rails, ¿Qué harían con algo como esto?

¿Cómo lo llamarían?

¿En qué directorio tendría que colocarse?

En el directorio de modelos... no no iría ah!

¡No iría en el directorio de modelos!

¿Qué es lo que va en el directorio de modelos?

cosas que derivan de ...

¿Que?

no importa...

¿Que cosas derivarían de ActiveRecord?

¿Los modelos?

¿Los modelos derivan desde ActiveRecord?

Bueno, ¡Estas entidades no las quiero derivando de ActiveRecord!

Estas entidades están desacopladas de la base de datos

también los interactors, no saben nada de la base de datos

no saben nada sobre mecanismos de entrega

son agnósticos a todas esas cosas, estas son reglas de negocio.

reglas de negocio específicas de la aplicación en interactors y agnósticas en entities.

bien aisladas del resto de la aplicación

¿Cómo obtenemos la data dentro y fuera de los interactors y las entities?

y Jacobson tenía una respuesta para esto también, decía:

"usaremos fronteras"

son esencialmente interfaces, son protocolos o interfaces.

en Java los haríamos interfaces, en .Net serían interfaces

en Ruby no serían nada

pero aún estarían allí, conceptualmente, escondiéndose tras bambalinas.

un conjunto de métodos invocados por interactors o por componentes

del otro lado de la frontera con el propósito de lograr algo

y con esto establecido tenemos los tres objetos en el modelo de Jacobson

y escribió un libro completo de esto un libro facinante.

pero esos son las tres partes centrales del modelo Jacobson

tenemos un montón de interactors

donde cada uno representa un caso de uso

tenemos un montón de entities

cada una representando un objeto de negocio

todas las reglas de negocios van aquí

¿Que pasa con validación?

cosas que tienen que ejecutarse en el navegador

cosas en javascript, ¿No son esas reglas de negocio?

¿Pueden ejecutarse en estos objetos?

no lo harán, van a ejecutarse en un computador distinto...

probablemente en el computador del usuario

van a ejecutarse en un lenguaje distinto: javascript

van a estar a un lado, ¿Significa que no son parte de este modelo?

Aun son parte de este modelo

solo que están ejecutandose en otra máquina y escritos en otro lenguaje

pero están tan desacopladas como el resto de las partes, ya que tratamos

de tener todas las reglas de negocios desacopladas.

aquí está el diagrama completo

tenemos algún mecanismo de entrega, que habla con el usuario.

por cierto, tengo lásers aquí.

tienes que tener lásers.

No dejen que llegue a sus ojos!

es uno bastante brillante

y tengo uno rojo

y tengo este otro

no lo puedes ver, oh ahi casi se puede ver

que tal ahí

nahh, no se ve bien

virtualmente desaparece

ehh, uno de estos va a servir

uh, este es brillante

que tal ese

ese es aun más brillante!

que tal este, algo brillante..

que tal este

miren son todos brillantes

¿Que color es este láser?

puedes verlo un poco en mi reloj

¿Pueden ver eso?

¿No es cool?

¿Qué color es este láser?

Es un láser ultra violeta

un poco de tinte aun está en el violeta pero la mayoría de la energía

que sale es ultra violeta

¿Que tan cool es eso?

tengo un láser UV

No se que hará por mí, todo lo que puedo hacer es

hacer que mis lentes queden negros

pero ...

que tal el rojo

tenemos un usuario aquí que va a interactuar con la aplicación

a travez del mecanismo de entrega

¿Cuál es el mecanismo de entrega?

¡No me importa!

¡No me importa cual es el mecanismo de entrega!

puede ser la web, puede ser clientes pesados, puede ser una aplicación de consola

puede ser un conjunto de servicios web

¡No me importa!

y quiero que se mantenga así

no me interesa cual sea el mecanismo de entrega, voy a tener el mecanismo de entrega

hablando conmigo a través de una interface desde la cual mis interactors van a derivar

mis interactors luego van a cachear la data que viene desde el usuario a través del

mecanismo de entrega. Mi interactor impondrá lógica de negocio específica

irá a mis entidades que encapsulan lógica no específica

y tendrémos harto trabajo interesante hecho, luego juntará harta data de vuelta

enviandola de vuelta por las fronteras hacia el mecanismo de entrega llegandole al final al usuario

noten la dirección de las dependencias justo aquí

el mecanismo de entrega depende de la frontera

nada hacia la derecha del mecanismo de entrega depende de él.

no hay ninguna dependencia terminando en el mecanismo de entrega

lo que significa que puedo tomar toda esta parte

y colcarla en una gema (gem)

o una dll si son programadores .Net

o un .jar si son programadores Java

puedo tomar eso y colocarlo en un lugar completamente desacoplado de todo lo demás

y puedo hacer que el mecanismo de entrega sea un plug-in para mi aplicación.

imagínense lo que eso significa para ustedes

si el mecanismo de entrega fuera un plug-in para sus aplicaciones.

eso implicaría que ustedes no tendrían que incorporarlo

cuándo no quicieras incorporar el mecanismo de entrega?

¿Cuando estás ejecutando test!

¡digamos que es cucumber!

Este mecanismo de entrega de ahí, ¡Digamos que es cucumber!

¿Que tan rápido dirías que eso se ejecuta?

bueno va tan rápido como puede, ya que no hay ningún sistema web

no hay web servers, no HTML, todo el javascript sucede en otra parte

no hay web server o parecido aquí

ahí está cucumber

puedes hacer que tus tests ejecuten muy muy rápido

así que sigamos el camino

un usuario decide que necesita interactuar con el sistema

así que el usuario tiene una buena idea, llega al sistema

escribe un montón de cosas en el teclado, este es un ambiente web, quizás

no importa

el mecanismo de entrega de alguna manera captura lo que el usuario quiere

quizás en un formulario, quizás en alguna ventana, a quien le importa

quizás en la linea de comando, no me importa

el mecanismo de entrega eventualmente obtiene todos los datos que requirere

y crea un modelo de solicitud. (Request Model)

que es esto, es una estructura de datos, no tiene métodos

es solo un conjunto de datos simples

nada dentro de esta estructura de datos parece que siquiera viene de la web

no puedes ver esta estructura y decir "oh esto debe venir de la web"

no hay ids de sesión, nada de todo lo otro

solo un conjunto de datos que representan la solicitud

eso va a través de la frontera

hacia el iteractor

ahora el interactor la tiene y es aun una tonta estructura de datos

pero el interactor sabe que hacer con ella

obtiene toda la información interesante del request model

y luego va a tener que ejecutar

¿Qué es lo que hace? habla con los objetos de entidad

hay una bonita interacción, a todo esto por eso lo llamamos un interactor

porque interactúa con las entidades

también interactúa con el usuario

es lo que como se diría, une todas las piezas

así que el interactor le indica a las entidades "haz esto, lo otro , aquello"

finalmente el interactor termina

y ha creado un modelo de resultado (Result Model)

¿Qué es un result model?

Una estructura de datos!

no tiene nada más dentro, no hay métodos, nada

solo un montón de tontos datos, nada dentro podría indicar

que es para la web, solo un montón de tontos datos

que luego envía a través de la frontera y le permite al mecanismo de entrega

como presentar este resultado el usuario

así que cuando ejecutas un test con cucumber aquí

el test de cucumber está creando la estructura de datos

está invocando en interactor correspondiente llendo a través de la frontera

toda la magia pasa en este lado, las reglas de negocio son invocadas

un modelo de respuesta es creado y se devuelve mediante el

mecanismo de entrega hacia cucumber y ahora puedes probar

todas las reglas de negocio y todos los casos de uso

de tu aplicación, y todo lo que tu aplicación hace

en el lado derecho del mecanismo de entrega,

sin tener el mecanismo de entrega presente

¿Por qué es esto importante?

¿Porqué querríamos hacer esto?

Bueno, primero que todo, si fueras a mirar esta parte del código

¿Qué crees que verías?

cuáles serían los nombres de estos directorios

interactors, boundaries (fronteras) y entidades

alguien tiene cerebro aquí .. bien

y si fueras dentro de los interactors

¿Que crees que verías dentro?

¿Como estarían nombrados?

"crear orden", eso es interesante no?

"crear orden", "agregar item a una orden"

"enviar orden", "eliminar orden"

"entregar orden", tendrían los nombres de los casos de uso

así que al nivel más alto de la aplicación verían una estructura

que se vería como el propósito de la aplicación

(diapositiva: ¿Que pasa con MVC?)

Que pasa con Model View Controller

¿No es esta la arquitectura de la web?

¿Desde donde sale esto?

oh, necesito cambiar la diapositiva

denme un segundo

Esta persona ¿Quién sabe como se llama?

oh, no era mi intensión poner el puntero entre sus ojos!

¿Quién es este tipo?

¡es Trygve! ¿Cuál es su apellido?

¡Reenskaug! tampoco lo puedo pronunciar, ¡Pero probablemente tu puedes!

Trygve Reenskaug

Que es el inventor de Model View Controller

lo inventó en 1979

si recuerdo correctamente

Probablemente sea el primer patrón de diseño al que se le puso nombre

Model View Controller

y fue una idea muy interesante y una idea muy simple

vamos a tener un modelo, que sería un modelo de alguna entidad de negocio

es donde colocamos las reglas de negocio

y el controller obtiene datos del usuario y la vista despliega información al usuario

esas son las bases de model view controller

Hay aquí una relación "observer" que es el motivo

por lo que lo dibujé con doble flecha

así que View observa el Model

y cuando el model cambia la vista

automáticamente representa este cambio

Esto fue escrito ... ¿En que lenguaje?

Smalltalk

Si hubiera una pantalla en smalltalk

que tubiera un montón de cosas en ella

¿Cuántas Views creen que habría?

cientos

Si tubieras cien cosas en pantalla, habrían cien Views

Porque este patrón de diseño fue pensado para ser usado en pequeño

cada pequeña widget en la pantalla tenía un controller, un model y una view

cada rectángulo, cada círculo, cada pequeña cosa en la pantalla

tenía sus propios model, controller y view

era un mecanismo pensado para ser usado en lo pequeño

y se replicacía una y otra vez

hemos cambiado eso de manera significativa

en el mundo Web hemos decidido que la pantalla entera es un View

bueno, esa no era la intención aquí

y ¿Cuántos modelos una vista conoce?

cientos!

Hemos mantenido la idea de los modelos

pero la View .. eh, tengo una imágen, la voy mostrar

¿Alguien reconoce esta imagen?

oh, nuestros objetos de negocio están por aquí

en los modelos, tenemos un conjunto de controllers

los controllers vailan tratando de controlar todos los modelos

"oh tengo toda esta data desde la web"

"voy a desempacar todo esto de la web"

"voy a decirle a esos objetos de negocio que hacer"

y los objetos de negocio hacen cosas

y luego en controller debe decir

"ok, que es lo que hicieron"

y debe recolectar toda la información

y pasarla a la View

y la View está esperando, escrita en un

horrible y bastardizado lenguaje

no puedes saber si es HTML o Ruby o quién sabe que cosa

y ¡Está accediendo a los objetos de negocio!

Tu View

Tus Views no debieran saber nada

sobre los objetos de negocio

tus Views debieran estar completamente divorciada de los objetos de negocio

No debieran siquiera saber que los objetos de negocio existen

tus controllers no debieran saber sobre los objetos de negocio

debieran estar completamente divorciados de eso

la comunicación entre los controllers y los views

son esas interesantes estructuras de datos

imaginen un controller

que obtiene un request HTTP

Aquí está nuestro request HTTP

cargado de datos

a todo esto, tengo que decir esto...

la web es probablemente la peor idea que ha sucedido

a nuestra industria en los últimos 40 años

(dificultades técnicas)

.... para entregar datos

Puede ser lo mejor que tengamos, pero está bastante podrida

debe haber un patrón en el que podamos hacer esto

la web...

¿Alguien ha hecho algo de programación para el 3270?

¿Reconoces esto?

Esto no es nada más que programación para 3270

y no voy a decir que en esteroides

es más como en estricnina (pesticida)

es programacíon para el 3270 envenenada con

cantidades de basura

¿Cuántos lenguajes debes saber para escribir una aplicación web?

tienes que saber, bueno, algún lenguaje de programación, pero es incidental

Ruby, Java, como séa

Luego debes saber HTML, CSS, Javascript, esto, lo otro

y esta persona de aquí dice "Creemos comunidades nivelando hacia arriba"

¿¡Nivelando hacia arriba!?

(ndt: no se entiende esta broma, está en un acento muy local)

No estamos ayudando a nuesta causa con este verdaderamente terrible

mecanismo que hemos adoptado

en todo caso, este es el request HTTP

llega al servidor web, pasa por un mecanismo enrutador que no importa,

es solo decodificar un monton de slashes y nombres

uh, podemos llamarlo REST supongo, como sea

aquí llega el controller y el controller es ejecutado por algo

en el servidor web que hace todo eso

y el controller maneja todos los datos del formulario o como sea

y lo coloca en el request model

no habla con ningún objeto de negocio

solo es una pequeña estructura de datos

y listo

no tiene nada más que hacer

cómo una última acción lo empuja por una interface

hacia un interactor

y el interactor hace lo que tenga que hacer

crea un response model

y el response model finalmente es pasado a través de un boundary

a un presentador

ahora, el trabajo de un presentador

ahora el trabajo del presentador, a todo esto

alguno de ustedes quizás conozca este patrón de diseño

Model View Presenter

El trabajo del presentador es tomar este modelo agnóstico

este modelo de todos los resultados del que no tiene idea como representar

y su objetivo es convertirlo en otra estructura de datos llamado ViewModel

que ha sido preparado para la web

¿Cómo preparas algo para la web?

lo llenas de basura

como por ejemplo si vas a desplegar la vista en una grilla

organizas los datos en una estructura tabular

no una que sepa sobre la web, solo una que sepa que es una grilla

en la pantalla quizás haya menúes algunos que estén deshabilitados

debieran haber booleanos aquí que digan si esos menús están deshabilitados o no

quizás hayan botones en la pantalla que tienen nombres

y estos puedan cambiar dependiendo del estado el sistema

esos nombres debieran estar en el ViewModel

así que en el final la View es este realmente estúpido pedazo de código

le pasas el ViewModel

y todo lo que la View hace es "coloca eso ahi, eso allá, eso otro acá, ok listo"

tan estúpido que no necesitas probarlo con pruebas unitarias

no necesitas escribir pruebas unitarias para esas cosillas tontas

que la View debe hacer

Así es como me gusta lidear con probar vistas

no lo hago

me aseguro de que no hay necesidad

simplemente no hay necesidad de probar esto de por aquí

o bueno, si hay algún test de aceptación que dependa de la interactividad de la View

realizo un par de test de aquellos y si, van a través de la interfaz de usuario

o quizas hago muchos de esos, pero en todo caso

no voy a probar todo esto otro, entrando de por aquí abajo (apuntando al View)

Si estoy probando reglas de negocio voy a escojer la interfaz más rápida que tenga

aquí está toda la enchilada

sin las entidades, me gusta dejarlas aparte

tenemos los interactors

estos hablan con las entidades

tenemos nuestras interfaces de frontera

los iteractors usan el request model y crean el response model

el presenter usa el response model y crea un ViewModel

el controller crea el request model

y toda esta cosa a la derecha de la línea

puede ser puesta en un .jar

y lo que está a la izquierda de la línea

puede ser puesto en otro .jar

y los puedes interconectar

si quieres

no tienes para qué

yo sé que estás pensando "ah pero tengo que hacer mi trabajo"

y si, tienes que hacer tu trabajo

así que dime cómo es tu día

primero, ¿Cuánto toma ejecutar tus test?

¡Demasiado! buena respuesta

¿Que tanto?

¡4 minutos y medio! ¿De inicio a término?

es bueno, ¿Cuantos test hay?

miles, wow, 4 minutos y miles de tests

es un buen tiempo

si es 4 minutos y medio estoy contento con eso

¿Quien tiene algo más largo?

¿Hora y media?

eso no está bien

¿atrás?

28 minutos

¿Cuántos tests?

¿Demasiados?

¿Demasiados? bueno, esa es una respuesta psicológica interesante

28 minutos, ¿Por qué?, porque hay muchos tests, hummm

y si hay muchos tests, ¿Que tendrías que hacer?

"necesitamos deshacernos de los test"

"toman mucho en ejecutar", este es el síntoma que ocurre, ¿Cierto?

"Saben, esta cosa de hacer pruebas no funciona"

"osa, con todo que toma ejecutar los tests, solo nos demora más"

"si solo pudiéramos programar y entregar"

¿Que pasa con la base de datos?