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?