Skip to content

Día de Open

enero 9, 2011

Ayer celebramos el #devopenmadrid, que fue un nuevo Open Space, aunque más enfocado al desarrollo.

La idea, si no me equivoco, surgió en la retrospectiva del AOS2010, donde una de las cosas que se dijo fue que se habían echado en falta temas técnicos y se pensó la idea de que quizás se podrían hacer más eventos de ese estilo sin necesidad de estar meses organizándolo ni pensarlo para que sea algo para 200 o 300 personas. Así que dicho y hecho, Jesús Jiménez se puso manos a la obra y demostró que no hace falta mucho para organizarlo, buscó un sitio en el que poder juntarnos y no se buscó ni patrocinadores ni nada, total, ¡qué son 15 euros para cada uno de nosotros!¡Gracias por el esfuerzo!

Llegada

Fuimos llegando tempranito para poder aprovechar el día.

La asistencia no estuvo nada mal porque al final fuimos unos 50 asistentes y en cuanto estuvimos todos empezamos a proponer temas. En esta ocasión creo que estuvimos más moderados a la hora de proponer y no salieron demasiados temas, pero aún así hubo mucho donde elegir durante todo el día.

Presentación de temas

Tablón

El tablón inicial quedó creado, pero como aún quedaban algunos huecos contando como sitios de reunión el pasillo, la cocina, la cafetería de al lado o cualquier otro sitio que se nos ocurriera se dejó abierto para que si a alguien se le ocurría algún tema nuevo fuera libre de añadirlo al tablón. Esta vez, guiados por el consejo de Enrique Comba, no hicimos ninguna votación ni nada para así empezar más rápido, simplemente pusimos todas las charlas que fueron saliendo en el tablón y si luego hacía falta cambiar alguna de sala por la afluencia de gente se cambiaba y punto.

¡Y comenzamos!

La primera charla en la que me metí se titulaba “Doctor, Doctor… Modelo Anémico” y había sido propuesta por Kinisoftware y Jacegu.

En ella inicialmente se dio una definición simple y directa sobre qué es un modelo anémico: tener objetos del dominio con únicamente métodos getters y setters, sin más lógica, únicamente contenedores de datos. Empezamos a discutir por qué este modelo de datos no es bueno y se mostraron unos cuantos argumentos:

  • Te cargas la encapsulación (¿de qué te sirve tener las propiedades de esa clase privadas si realmente las estás haciendo públicas con los getters y setters?).
  • Estás usando clases como estructuras.
  • Estás creando una capa de contenedores de datos y otra capa para actuar sobre esos objetos, poniendo la lógica de negocio lejos de los datos.

¿Y qué tenemos que hacer para buscar tener un modelo bueno? Pues por ejemplo seguir los consejos del “Tell, Don’t Ask” y la Ley de Demeter para decir a los objetos que hagan cosas en lugar de preguntarle a los objetos por elementos de su estado interno.

Un ejemplo gracioso respecto a esto que propuso Alfredo Casado es que si vas a pagar la compra en una caja no le das al cajero tu cartera para que el cajero saque el dinero de ella, sino que le das directamente el dinero, de igual forma nuestros objetos debería encargarse de dar la información necesaria, no de dar otros elementos para que otro desde fuera sea quien tenga que obtener la información.

Respecto a esto alguien preguntó que por qué el getter era malo y la respuesta fue simple: el getter no es malo, lo malo es usarlo para exponer los atributos internos de una clase para que alguien desde fuera opere.

Pero un problema que nos encontramos cuando intentamos evitar modelos anémicos es que podemos acabar creando objetos demasiado grandes y con demasiada responsabilidad y la única solución que hay es estar en contacto con el cliente todo lo posible para encontrar un buen diseño del dominio y para ir buscando objetos pequeños que respondan a preguntas pequeñas en lugar de tener un objeto que responda a todas tus preguntas.

¡Es duro pero hay que intentar ponerlo en práctica!

La siguiente charla en la que estuve fue “Mockear” propuesta por Emma.

En esta charla partíamos de la pregunta de si era buena realizar tests con mocks o no. Al principio no entendimos bien de dónde surgía la duda hasta que empezamos a aclarar algunos términos y es que antes de pensar si mockear o no tuvimos que explicar un poco algunos términos de los distintos tipos de dobles de objetos que algunos no estábamos viendo como diferentes pero que en el planteamiento de la charla sí eran diferentes:

  • Stub: Permite manejar los resultados esperados en las llamadas a un objeto.
  • Mock: Doble de un objeto que permite definir las llamadas que se esperan se produzcan sobre el objeto. Se tienen que definir las llamadas esperadas antes de la llamada que se está probando y luego las verificaciones en la zona de comprobaciones. Además, si se realiza una llamada sobre el doble que no se encuentra definida entre las esperadas el test falla.
  • Spy: Es el doble de un objeto que almacena las llamadas realizadas a métodos de este objeto para poder verificar en la zona de comprobaciones si se han realizado las llamadas deseadas. Cuando se producen llamadas a métodos no esperados no falla el test y si devuelve algo el método, se devuelve un valor por defecto(por ejemplo null).

¿Y cuándo usar cada uno? Pues todo depende del problema al que te enfrentes, si quieres probar a qué métodos se llama asegurándote de que no se produce ninguna llamada más de las que estás comprobando, si sólo quieres asegurarte de que una llamada se realiza sin importarte si se hacen más llamdas o si quieres asegurar que un objeto devuelva un resultado.

Además hay que tener en cuenta que en los tests con mocks, stubs o spies el test queda acoplado al código, ya que si cambian las llamadas que estás haciendo el test puede fallar. Por ello, estos objetos dobles pueden servir para diseñar el código y olvidarte de una parte con la que tienes que integrar el código y que no depende de ti, pero es peligroso usarlos sin control ya que puedes caer en crear demasiados colaboradores dentro del código.

También hay veces que te puede interesar no recurrir a estos dobles de objetos, sino crearte tú tu propio doble del objeto que quieras probar, incluso es una técnica necesaria cuando quieres probar algunos métodos que los dobles no te dejan como el “toString”.

Así que la conclusión de esta reunión yo creo que fue que tienes que usar cada herramienta cuando realmente la necesites, no usar una siempre por el hecho de haberla aprendido y también que el mejor momento para usar estos dobles es antes de hacer el código puesto que si los escribes después es muy posible que hagas un test totalmente acoplado al código escrito que replique las llamadas realizadas en el código.

La siguiente charla en la que me metí fue “Código Expresivo” propuesta también por KinisoftwareJacegu, que llevaban tiempo hablándolo con Alberto Peña a quien al final la gripe le tuvo en cama gran parte del día.

La idea de esta charla era hablar un poco sobre el Clean Code, un libro que muchos consideran que debería darse a un programador nada más aprender a programar.

Uno de los puntos importantes que se tratan es sobre el “naming”. Es importante enseñar a nombrar las cosas desde el principio ya que si no eres capaz de ponerle nombre a algo es porque realmente no sabes lo que hace.

Pero si estás implementando en una clase un patrón de diseño, ¿deberías indicarlo en el nombre de la clase? Aquí hubo algo de discusión, ya que aunque en el libro se hace, quizás puede llevar a poner nombres que no sean realmente significativos para el dominio.

¿Y cómo de largos deberían ser los nombres? Lo mejor es buscar un equilibrio entre la longitud del nombre y que sea suficientemente expresivo y sobre todo tener en cuenta que si aparecen cosas como “y” u “o” en los nombres hay que repartir responsabilidades. En el libro se autoimpone una restricción de 120 caracteres para evitar tener nombres demasiado largos que pasen a ser ilegibles.

¿Y cómo se manejan los distintos niveles de abstracción con la legibilidad del código en un lenguaje natural? Está claro que escribiendo código tiene que haber código y que hay partes del código que al final tienen que tener nuestros algoritmos, lo importante es que en cada nivel de abstracción tengas un nivel homogéneo de información de forma que que se pueda leer de forma horizontal y cuando un usuario que esté leyendo el código quiera más información sobre una parte en concreto pueda navegar de forma vertical para ir encontrando una información más específica. Por ejemplo no sería coherente un código que fuera:

if (x + y == 4 && esDivisiblePorDos(x))

También tuvimos mucho en lo que entrar en materia cuando empezamos a hablar sobre el tema de excepciones, las cuales siempre deberían usarse para tratar casos excepcionales y no para controlar el flujo de una aplicación, aunque se acabó el tiempo y no tratarlo tanto como nos habría gustado.

En la siguiente hora me quería meter en una propuesta de Germán que me pareció muy interesante sobre programar unos robots para hacer una guerra de robots. Lo malo es que cuando llegué a la sala ya estaba bastante llena y no vi mucho sitio para meterme con mi ordenador y desistí, además fuera me encontré con gente con la que tenía ganas de charlar aprovechando la oportunidad de juntarnos y se nos fue la hora volando (¡en estos eventos es difícil no liarte hablando con la gente!)

Pero en la última sesión tenía claro que quería ver un poco de Clojure, así que me metí en la sesión “Clojure Koans.

En esta sesión nos pusimos manos a la obra con más ganas que experiencia a experimentar con las Clojure Koans utilizando el formato de randori. Aunque sólo nos dio tiempo de hacer unas cuantas estuvo bastante bien como toma de contacto con Clojure, ya que para mí que vengo principalmente de lenguajes con orientación a objetos un primer vistazo a Clojure asusta jeje.

Después de las charlas hicimos una pequeña retrospectiva en la que valoramos el esfuerzo de Jesús para organizar todo y por demostrar que no hay que organizar mucho para hacer un evento de este tipo, algunas personas lamentaban que no se hubiera programado más, mientras que a otras les pareció positivo haber podido hablar y discutir sobre temas técnicos y hubo también discrepancias con si empezar temprano había sido buena o mala idea, pero qué se le va a hacer, nunca llueve a gusto de todos.

Fue un día como siempre divertido e instructivo, como no puede ser de otra forma cuando estás rodeada de gente que tiene tanto para enseñar y compartir. Hubo gente nueva que no había asistido antes a eventos de este tipo y eso es bueno porque quiere decir que la comunidad ágil crece y los desarrolladores preocupados por su profesión aumentan. Lo que sentí fue la poca participación femenina, ya que sólo estábamos 4 chicas y ninguna cara nueva, todas ya integrantes de las Agile-Girls, ¡habrá que predicar más!

9 comentarios leave one →
  1. enero 9, 2011 7:41 pm

    Gracias por el resumen ..😀

  2. enero 11, 2011 10:02 am

    Cada vez me da más pena no haber podido ir al evento jeje.

    En fin, espero que para la próxima. El resumen me pareció muy interesante.

    Un saludo

  3. marzo 1, 2012 7:37 pm

    Me ha encantado tu post. Si vas este sábado verás una cara nueva femenina 😉

    • marzo 1, 2012 11:26 pm

      Jop, este finde estoy fuera de Madrid así que no podré ir, ¿me relevas haciendo una buena crónica del evento?😉

      Gracias por leer el pobre blog, aunque lo tengo al pobre un poco desactualizado, seguro que os lo pasais genial el sábado, de estas cosas siempre se sale con un montón de cosas nuevas aprendidas, quizás coincidamos en el Codemotion, ¿tienes pensado ir?

      Saludos!

      • marzo 2, 2012 2:30 pm

        No conocía el Codemotion, pero le echaré un vistazo y lo mismo me apunto. ¡Gracias!

        Sobre hacer la crónica, cuenta con ella, aunque seguramente la mía sea mas corta.

        El link que has puesto a Agile Girls no funciona pero he empezado a seguir la cuenta de Twitter.

      • marzo 5, 2012 7:15 pm

        Me temo que no voy a tener tiempo de escribir una crónica porque estoy hasta arriba de trabajo. Me sabe mal😦

        Pero ha sido genial. He aprendido mucho y me lo he pasado muy bien. ¡Espero verte en el Codemotion!

        ¡Saludos!

      • marzo 6, 2012 9:56 am

        Me alegro de que os lo pasarais bien, ya fui leyendo tuits del evento😉

        No te preocupes por la crónica, a mí me pasa lo mismo entre el trabajo y otros líos y por eso tengo tan abandonado el blog🙂.

        Y por supuesto que nos veremos en el Codemotion, ¡yo ya tengo mi entrada!

        ¡Saludos!

Trackbacks

  1. Tweets that mention Día de Open « No es sólo cosa de hombres… -- Topsy.com
  2. Agil-AZ   Blog » Blog Archive » Katas y otros juegos

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: