Mi cursada - UNQ‎ > ‎Clases‎ > ‎Bitácoras‎ > ‎Bitácoras 2011 S1‎ > ‎

Bitacoras 2012 1c

Clase Seaside - 23/05/2012

publicado a la‎(s)‎ 23 may. 2012 15:11 por gisela decuzzi   [ actualizado el 23 may. 2012 15:44 ]

Seaside

Metafora que usa Seaside 

Canvas: el lugar donde "pintamos" (el lienzo)
Brush: es un pincel, donde basicamente son las herramientas que usamos para dibujar en el canvas. Podemos decir que lo que en wicket decimos componentes aca lo vamos a llamar como pinceles. Por ejemplo un combo, textbox ...
Los brushes tienen mucha relacion con el html, de hecho la mayoria de los tags html tienen un pincel asociado, por ejemplo el div
Componentes: un componente es algo que se sabe mostrar.
Implementa el mensaje #renderContentOn: recibe un canvas y utiliza los pinceles para pintar en ese lienzo

Hoy vamos a ver:

1. Como crear un componente
2. Como pintar en el canvas con los brushes
3. Como se pueden comunicar los componentes


Trabajando en Seaside

La forma más facil de obtener seaside es: Bajandose la imagen del site de seaside que ya viene con todo instalado (pero no es la ultima versión de Pharo, es la imagen 1.2).

Para levantar el server: Desde Seaside Control Panel lo iniciamos o lo paramos
Para agregar una nueva aplicacion:
podemos desde la imagen de pharo definiendo el initialize en clase de nuestro componente para registrar la aplicación.
desde el browser entrando a /browse -> eligiendo /config

Vimos como un ejemplo la ruleta (que tanto queremos ya), la vista tenia:
- JugadorView
- RuletaView
- CasilleroView

Todos estos componentes se saben mostras, por lo que implementan el mensaje renderContentOn:
Vimos el ejemplo del jugador:
JugadorView>>renderContentOn: canvas
canvas heading level3 with: 'Dale jugá pibe'

Comparamos la diferencia entre:
canvas print: '<h1>Hola</h1>'
canvas heading: 'hola'

Y notamos que en la segunda alternativa nos independizamos de la clase del canvas, podriamos estar haciendo una aplicacion de escritorio o una web u otra cosa y la responsabilidad de renderizarce como corresponda esta en el canvas.

Vimos la RuletaView>>
renderContentOn: canvas
canvas heading: 'Ruleta'.
canvas div
class: '#ruleta';
with: [self casilleros do: [:casillero | canvas render: casillero]].
canvas div 
class: #form;
with: self form.

Despues de hablar un rato sobre los componentes dijimos que podiamos categorizar los metodos en tres:
  • Cosas de configuración pura
  • Cuando el objeto se muestra
  • cuando el objeto se modifica (su comportamiento)
Cosas de configuracion: particular de Seaside, por ejemplo los métodos
  • style:sirve para definir los estilos de esa clase
  • children: los hijos que tiene el componente (los sub-componentes que tenemos)
  • states: los objetos de los que queremos acordarnos

CasilleroView>>renderContentOn: canvas
canvas span
class: '#casillero';
with: [
canvas anchor
callback: [self ruleta comenzarApuesta: (CIUPleno a: self casillero)];
with: self casillero numero
]

El callback: es el comportamiento que quiero que se ejecute cuando alguien clickee el link, el codigo dentro del bloque se puede ejecutar codigo server side.
El concepto Clave de esto es continuations (que se escapa a la materia pero quizas sirva para empezar a buscar sopbre como es que esto es implementable)

CIUApostarTask >> renderContentOn: canvas
canvas heading level3 with: 'Creando nueva apuesta'.
canvas text: 'elija un tipo de apuesta'.
cavas select
list: CIUApuesta apuestasPosibles;
on: #apuesta of: self.
Jugamos con las continuations y la posibilidad de hacer cosas distintas cuando las usamos, vimos el onAnswer: y jugamos un poco con ellos. Implementamos una Task y definimos el método go para solucionar problemas que teniamos con la solución anterior.









Clase 3 - 28/03/2012

publicado a la‎(s)‎ 28 mar. 2012 17:11 por gisela decuzzi   [ actualizado el 28 mar. 2012 17:11 ]

Hicimos un repaso de algunos temas y hablamos de testing y manejo de errores, dijimos cosas como:
  • Hacer los test con un fin y acotado, cada test prueba una sola cosa y no cinco
  • Los tests son codigo y es algo que no tenemos que olvidar, a ese codigo tambien hay que cuidarlo, y aplica todo lo que vimos en programacion
  • Si el sistema tiene que fallar que falle lo antes posible
  • No hay que tener miedo a que las cosas "se rompan"
  • Peor que falle avisandonos es que falle y nunca diga nada :(
Para ver el por que de estas cosas y mucho mucho mas es realmente muy sano que sigan leyendo sobre estos temas, particularmente les dejamos dos apuntes para que lean, sobre:

Despues de eso nos metimos de lleno en el tema de la clase: Adapters y Validaciones
Antes hicimos una pausa y hablamos de inner clases en Java, y despues si finalmente empezamos a hablar de...

Validaciones

Quisimos agregarle una validacion a nuestro querido Conversor, queremos que: No convierta numeros negativos
Dijimos que eso es una nueva regla de negocio.
Entonces empezamos...
Donde ponemos la validacion y por que?
  • En la vista (ConversorWindow)?
    • Surgio la idea de que: al modelo solo le lleguen datos validos, entonces la vista parece un gran lugar para poner esa regla
  • En el controlador (Un action propio)?
  • En el modelo?
    • Surgio la idea de que: la imposibilidad de convertir es una regla propia de mi dominio, entonces en el modelo es un gran lugar
De las dos opciones validas, por cual vamos? Para responder esto hablamos de que es una validacion,y dijimos que hay dos cosas destancables de una validacion:
  • Una regla: algo que tenemos que cumplir
  • La ejecucion de esa regla
Dijimos que no confundamos esas cosas, en nuestro caso la imposibilidad de convertir numeros negativos es independiente de la vista, y es algo bien intrinsico a nuestro problema. Nosotros NUNCA vamos a convertir numeros negativos, y eso es logica de mi modelo entonces nos convencimos de ponerlo ahi, por lo que elegimos el modelo como su lugar. Hablamos de reutilizacion y nos imaginamos que queriamos un test, definimos que esa regla era digna de un test y nos alegramos de haber puesto esa regla porque ahora la podemos testear de ahi.


Despues nos pusimos el sombrero de usuario del conversor y hablamos modestamente de su usabilidad y lo que nos gustaria, dijimos cosas como:
  • Que si ingresamos un valor invalido nos informe mientras tipeamos (sin necesidad de apretar el boton)
  • Que ni siquiera deje setear el valor si es negativo, aca pasamos la validacion al setter
  • Que no solo nos informe que hubo error sino que deshabilite el boton, lo implementamos con arena usando el metodo disableOnError() de la clase Button.
  • Que ni siquiera me deje escribir cosas invalidas
Aca vimos que hay muchas cosas que dependen del framework que estamos usando, tomamos el ejemplo de habilitar/deshabilitar el boton y lo facil que era, y esto pasaba porque:
  • elegimos validar en el domnio
  • elegimos manejar los errores como le gustan al arena (tirando la excepcion que le gusta)
Despues para poder cumplir con la ultima motita les presentamos un nuevo feature recien salido del horno de Arena que son los TextFilter, vimos su codigo, un solo metodo:
    public boolean accept(TextInputEvent event);
Y lo usamos en nuestro conversor y de paso con una inner class:
millas.withFilter(new TextFilter(){
    public boolean accept(TextInputEvent event){
        return StringUtils.isNumeric(event.getPotenctialTextResult());
    }
});

Despues un poco nos fuimos por las ramas y dijimos, esta regla es simple, la hicimos en una linea, y se nos complico la regla: que admita comas, pensamos en mas cosas que nos pueden pasar y nuestra regla era terrible y no era una linea y tenia sentido usarla en otros lados. En ese momento vimos lo feo que era que solo existiese en esa clase y que en ese momento tener una inner class no estaba bueno, aunque sea lo sacamos a una clase nueva.

Despues nos fuimos todavia mas por las ramas y hablamos de la importancia de contribuir en proyectos de software y no estar solo en la posicion de usuarios comodos y quejarnos de que no se ajusta a nuestras necesidades, y parchear para que funcione y seguir. Tambien hablamos del tride-off y el esfuerzo que eso implica.

Volvimos y revisamos nuestro ejemplo, al final refactorizamos y dijimos:
  • Definitivamente quiero que mi regla de negocio este efectivamente en mi modelo, por lo que volvimos el metodo a la clase Conversor, en un metodo nuevo.
  • Tambien quiero que se ejecute mientras tipea el usuario se valide, entonces queremos el TextFilter y lo que vamos a hacer es que en su implementacion mande el mensaje nuevo de validacion al modelo.
Quisimos categorizar el TextFilter y dijimos dentro del MVC que es? Llegamos a la conclusion que es un controller: porque se comunica con el dominio (le manda un mensaje al modelo) actua sobre la vista (en la pantalla no aparece ese caracter) y justamente esa es la accion del controller.

Conclusion: separemos las reglas de negocio de su ejecucion.


Adapters no llegamos a verlo, con lo que nos quedo para la proxima clase (que ademas es la entrega 1 del tp).

Clase 2 - 21/3/2012

publicado a la‎(s)‎ 21 mar. 2012 15:46 por gisela decuzzi   [ actualizado el 21 mar. 2012 15:46 ]

Arrancamos haciendo un pequeño repaso de lo que ya vimos, consultando dudas teóricas y prácticas.
Luego repasamos dos cosas de Objetos 2:
  • Excepciones
  • El patrón Observer
  • Comunicación bidireccional en objetos, por ejemplo, clase subclase, o bien interfaces.
Y luego nos metemos en la Unidad 2.

Model-View-Controller

La importancia de un modelo de dominio

Dijimos que era muy importante tener un modelo de dominio separado de la tecnologia o lo que querramos hacer.
Discutimos el por que de esta separacion y pensamos que pasaria si no la tuvieramos y mezclaramos por ejemplo logica de dominio con la presentacion, esto nos llevaria a alejarnos de nuestro problema y en vez de concentrarnos en el problema (haciendo las abstracciones que se encuentran en el) pensar en problemas inherentes de la tecnologia produciendo sistemas confusos y poco escalables, tendiendo a repetir codigo y a distribuir mal las responsabilidades. Ademas recalcamos el hecho de que hace mas dificil escribir tests unitarios.


Objetos necesarios para modelar una ventana

Definimos que vamos a construir interfaces de usuario orientadas a objetos. Para eso, introducimos nuestro ejemplo del conversor de monedas y presentamos una pantalla tentativa. 
Nos preguntamos qué objetos podrían conformar esa pantalla:
  • Los obvios son los controles visuales: botones, campos de texto, ventanas.
  • Menos obvios son los layouts, que indican cómo se organizan espacialmente los objetos.
  • Y también tenemos que pensar en el objeto que tiene el comportamiento, por debajo de la ventana, al que vamos a llamar modelo de dominio.

Relación entre la interfaz de usuario y el dominio

Definimos como un objetivo la separación entre los controles visuales y el modelo de dominio
Es importante entender qué formas de relación podemos admitir entre ambos y qué formas no. Existe una relación entre ambos, no podemos pretender que no tengan "ninguna relación entre sí", eso seria engañarnos.

Según nuestra definición, el dominio no puede tener referencias explícitas a la interfaz de usuario, pero sí puede:
  • Contestar preguntas.
  • Tirar excepciones.
  • Lanzar eventos.
La interfaz de usuario sí puede tener referencias al dominio y mandarle mensajes, pero no debe tomar decisiones propias del dominio
Para entender sobre las decisiones, pensamos en las validaciones necesarias al hacer una transferencia. ¿A quién le corresponde cada validación?
  • La cuenta no puede quedar con saldo negativo.
  • El texto ingresado debe ser un número.
  • El monto de la transferencia no puede ser negativo.
Comparamos esta definición con el concepto de capas.

Como regla general, vamos a pensar que (casi siempre) cada ventana va a tener un único objeto que es responsable del comportamiento asociado a esa ventana. A ese objeto lo llamamos el modelo de la ventana. Múltiples ventanas pueden estar relacionados con un único modelo.

Eventos

El otro concepto fundamental de la forma de comunicación que vamos a utilizar es el Evento. Un evento produce una forma de interacción muy desacoplada, ya que el que informa sobre el evento conoce sólo sobre sí mismo, no sabe a quién le está informando.

Los eventos permiten enterarnos de las acciones del usuario, por ejemplo podemos hacer que la UI nos avise cuando el usuario presiona un botón, y pedirle que invoque un mensaje específico.

Los eventos y las configuraciones asociadas son el primer ejemplo que vemos del tercer rol fundamental en el diseño de una interfaz de usuario: el controller. Al decir esto podemos terminar nuestro dibujo de MVC. De a poco vamos a ver controllers más complejos, por ahora van a ser muy simples.

Binding

Ahora, ¿cómo hacemos para obtener la información que el usuario ingresó en la ventana? 
Nuestras reglas dicen que no podemos pedírsela a la ventana, pero lo que sí podemos es escuchar algún evento que nos avise cuando cambia el valor y nos reenvíe el valor nuevo. Como este tipo de comportamiento es muy común, existe una forma especial de evento que llamamos binding. El binding puede ser unidireccional o bidireccional.

Y con eso tenemos todo para construir interfaces de usuario sencillas.

Tarea y más información

Bitacora clase 14/03/2012

publicado a la‎(s)‎ 14 mar. 2012 13:03 por gisela decuzzi   [ actualizado el 14 mar. 2012 14:10 ]

Primer Bloque

Hoy arrancamos y nos cambiaron de aula... asi que para los que están perdidos vamos a estar cursando en CyT 2.
En la primera parte de la clase hicimos una introduccion a la materia, haciendo hincapie en que vamos a ver y que no.
Remarcamos la idea que es muy importante NO olvidarnos todo lo que vimos antes de programación, todo se aplica y es muy importante respetarlo.
La idea de la materia no es aprender un framework sino aprender las ideas que estan atras, vamos a trabajar con muchas tecnologías y marcar los conceptos que nos interesan destacar.
No es una materia sobre Diseño Gráfico o Usabilidad, cuando hablemos de diseño nos vamos a referir a lo mismo que se referian en Objetos 2, ese diseño. Si vamos a mencionar y sugerir algunas reglas de usabilidad principalmente enfocados en el trabajo practico, pero no es tema de la materia.
Las interfaces que vamos a ver son para aplicaciones de gestión (si, vamos a dejar afuera interfaces graficas y los videos juegos :( si quieren saber más de estos temas les recomendamos la electiva de Desarrollo de Videojuegos)
Una vez hechas estas aclaraciones pasamos a revisar el site de la materia, las secciones y las unidades. Vimos las fechas de entregas que están marcadas tanto en la planificación como en las notas.

Segundo Bloque

Hablamos de algunas herramientas que vamos a estar usando y mostramos ejemplos de uso. Particularmente hablamos de:
  • Maven
  • SVN
  • Debugger de Eclipse

Algunas preguntas que surgieron

Biblioteca (o libreria o library) vs Framework, dijimos que la principal diferencia es que los frameworks se caracterizan por tener Inversion de Control a diferencia de una biblioteca que es un contenedor de funciones y nada más.
SCM ¿y eso? SCM significa Software Configuration Management

Lecturas recomendadas

  • Resumen de la clase 1
  • Links a la wiki
  • Maven



1-4 of 4