La lectura

Desde chico en casa estaba acostumbrado a ver libros, entrar a la "biblioteca" de la familia, un cuartito lleno de libros, revistas, artículos que tenían mis papás en él, a veces en las noches ver a mi papá acostado en la hamaca leyendo algo, algunas veces yo le preguntaba que leía y sentía real curiosidad por saber, pero nunca fue algo que me llamara la atención en demasía (como la mayoría de los niños en el pueblo yo me la pasaba en la calle jugando, vagando y haciendo una que otra travesura), así pasó la primaria, la secundaria, luego nos venimos a vivir a Querétaro (de donde soy originario), pasó el bachillerato, luego la ingeniería y nop, nunca me sentí muy atraído a los libros; bueno realmente si leía pero solo lo necesario para entender los temas y asignaturas de la escuela, así leía sobre Platón, Sócrates, Calculo, programación, etc. pero siempre por cuestiones académicas.

Empecé a trabajar, el hábito de la lectura continuaba igual, sólo leía artículos para poder "sacar" lo que me pedían en el trabajo, luego cambié de trabajo (mi actual trabajo) y pues todo seguía igual en ese ámbito, luego Rox empezó a traer libros al trabajo, una vez, hace como unos 3 años yo creo, nos trajo uno escrito por su esposo, dije bueno... vamos a leerlo, así empecé, leyendo cuentitos, luego me prestó otro libro donde igual su esposo era coautor y así continué, leyendo pequeñas historias, luego mi gran reto fue Canek de Emilio Abreu Gómez y así empecé con los libros, desde lectura técnica para el ámbito del desarrollo de software hasta algo de ciencia, pasando por novelas, así conforme me han ido recomendando lecturas las he tomado.

Al iniciar este año me puse un reto, como muchos más que me pongo a mi mismo siempre, y esta vez fue leer un libro cada mes, así empezó enero con cometas en el cielo (recomendado por Albaneth), febrero con el libro de los abrazos (recomendado por Armandiurix), marzo con las uvas de la ira (recomendado por Armandiurix), abril con el caballo de troya (éste mi papá lo tenía, alguna vez intenté leerlo pero no pude, pero siempre ha estado en mi mente leerlo), mayo pragmatic project automation, junio con La meta (recomendado por Ana), por ahora voy bien según el plan, 6 meses, 6 libros leídos y me he dado cuenta que me gusta esto de la lectura de todo tipo, como siempre he sido de mente abierta me es fácil digerir las letras, entender la trama e imaginar la historia, el viernes pasado terminé el libro de junio, así que ya empezaré con el de julio, en este caso un libro recomendado por Armandiurix, La 3a alternativa, veamos como nos va con él.

Realmente el leer ha cambiado de cierta forma mi vida, hoy mis hijos ven que yo leo en cuanto tengo la oportunidad, a veces se acercan a mí y me preguntan que leo, les digo de que se trata, a veces me dicen que les lea una parte, les leo unas cuantas páginas y así nos la llevamos, espero que en algún momento ellos también se interesen en leer y lo hagan por convicción y gusto, más que por una obligación.

Y tu que me lees, ¿aceptas el reto?, vamos 1 libro cada mes durante doce meses, puede ser de lo que sea, lo que te guste, lo que te llame la atención, no importa el número de páginas, ni el autor, ni el tema ya que al empezar no te podrás detener y seguramente empezarás a vagar de uno a otro sin preferencias. Por el costo pues si bien coprar libros puede resultar caro, siempre hay alguien dispuesto a prestar alguno de su acervo o puedes comprar uno sólo y al acabarlo cambiarlo con alguien más por otro y así continuar... recuerda, uno por mes.

Saludos a todos y felices lecturas.

Behavior Driven Development (BDD)

Behavior Driven Development o BDD (Desarrollo Dirigido por Comportamiento) esta técnica es a mi parecer una de las mas importantes en cuanto al desarrollo de software, veamos que es BDD,  BDD es una técnica que nos permite plasmar un requerimiento en código, asegurándonos que lo que se desarrolle va directamente a solucionar un problema muy específico de negocio, pero cómo se logra esto? inicialmente es teniendo pláticas con la gente de negocio, cliente o product owner para entender lo más claro el problema a resolver, esto se deberá de hacer en juntas pequeñas en las que lo ideal es que estén representantes de desarrollo, pruebas y negocio y así de esta forma generar un requerimiento "estable" entre los tres, tratando de en ese momento identificar no solo el problema, sino una posible solución a él y ciertos escenarios que serán el boundary del desarrollo.
Luego de esto lo ideal es plasmar el requerimiento en forma de los escenarios o comporatmiento esperado en alguna herramienta de pruebas funcionales automatizadas como jbehave, robot, gauge o fitnesse en las que se pueden crear los escenarios de pruebas usando un lenguaje apto para la gente no técnica, acá hay que mencionar otra herramienta muy ampliamente aceptada en el medio que es la notación Gherkin en la que los requerimientos se escriben en tres partes siendo éstas Given (dado que cierto prerequisito o estado del sistema), When (cuando una acción específica ocurre sobre ese estado del sistema), Then (que sucede con el estado del sistema), veamos un ejemplo de la notación:
Dado que soy un empleado que tiene derecho a 5 días de vacaciones.
Cuando pido vacaciones por 3 días.
Entonces se me conceden mis días de vacaciones y me quedaré con 2 días por disfrutar.
Usando esta notación no solo es algo que la gente de pruebas, desarrollo y negocio sabe interpretar, sino que define claramente el comportamiento esperado.
Lo que sigue ahora es empezar con el desarrollo, pero ahora la asignación del equipo de desarrollo será hacer pasar los tests creados en la herramienta, volviéndose esta su principal tarea.... espera!!!!!, cuales test? pues las pruebas de aceptación al final de cuentas son tests, es decir, la chamba del equipo de desarrollo es hacer que el "Entonces" suceda cuando el "Cuando" es ejecutado bajo la circunstancia descrita en el "Dado", con esto se logra que el desarrollador tenga un foco muy claro y algo que le define cuando el desarrollo ya está terminado (cuando ya ha hecho pasar todas las pruebas descritas).
Bien, ahora ya tenemos varios tests escritos en una herramienta y código que hace pasar esos tests y que por ende ya resuelven el problema, ahora, que pasa con lo ya desarrollado? pues bien.... yo creo que ya lo podemos pasar a producción no?... lo ideal es que si, es decir, si se tiene una buena cobertura del comportamiento esperado, incluyendo pruebas no funcionales, pues si, ya se puede pasar a producción con la bendición del Yorch sin ningún problema, pero que pasa con nuestros amigos de pruebas? pues bien, ellos ya hicieron su trabajo (y muy bien hecho) al inicio del desarrollo, agregándole calidad al desarrollo creando los escenarios de pruebas necesarias (tratando de dar la mejor cobertura a nivel negocio).
Además de todo esto, ganamos pruebas de regresión automatizadas por lo que ahora ya no hay que dedicar cada vez más a la ejecución manual de las mismas cada vez que se agrega una funcionalidad al sistema, lo cual hace que el tiempo de entrega se acorte casi un 60%, lo cual hace que nuestros clientes sean aún mas felices, lo cual hace que la empresa gane más dinero, lo cual hace que... bueno iba a decir que nos aumenten el sueldo, pero eso casi no pasa jeje.
Además de rapidez en la entrega ganamos documentación a nivel de negocio que nos dice con un nivel de certeza del 100% lo que el sistema hace ya que se puede asegurar que si un test pasa, el sistema lo hacen, si un test no pasa, el sistema no lo hace.
Bueno, muy bonito todo hasta acá, pero no todo es color de rosa ni huele a nalguita de bebé, el problema (y es donde mas hay que luchar) es que hay que cambiar hábitos y formas en la empresa,  tales como el proceso que puede ser anticuado creando casos de uso, o el hecho de que no estén dispuestos a trabajar hombro a hombro con el desarrollador o que la gente de pruebas esté ya en la sinergia de que las pruebas van al último y eso no se puede cambiar, definitivamente esto es lo más difícil, el cambio de mentalidad, pero eso lo abordaremos más adelante... bueno, mejor no, mejor lean al respecto en el blog de mi amiga Rox, ella está más metida en estos asuntos y tiene más autoridad para hablar de eso que yo.

Don't Repeat Yourself Principle o DRY (segunda parte)

En la primer parte comentamos algunas de la aplicaciones del principio DRY, estas aplicaciones son enfocadas totalmente al código, en esta segunda parte le daremos uso al principio, lugares donde a veces ni nos pasa por la mente, pues bien empezamos.

En los requerimientos

Esta parte es muy importate para cuando se está usando un framework ágil y es una de las mejores prácticas en la industria, en principio dry se aplica aplica en los requerimientos... pues haciendo... como decirlo... cambiando la forma de hacer requerimientos, esto es, en si, los documentos de requerimientos son una de las tantas representaciones de lo que se supone que hace el sistema, pero éstos tienen muchas desventajas, una de ellas es que normalmente se escriben antes de que se desarrolle la aplicción, por lo que a final esta representación del sistema muy seguramente va a quedar desactualizada casi desde la primer versión productiva del sistema, la otra es que muy dificilmente es actualizada con forme el sistema va mutando y la otra es que la documentación de requerimientos es como igor (el de winnie poo), naadie lo quiere por lo que hay un momento en que queda en desuso. Otra representación del sistema es el código en si, el sistema por sí mísmo, esta representación es la que al final de cuentas es mas fiel a lo que ejem... el sistema hace en realidad, esta representación en aún mejor que la dcumentación de requerimientos ya que a ésta si se le da el mantenimeinto debido y pues 100% seguro va mutando conforme el sistema va cambiando, además de que a esta representación muchos la quieren, en si todo el equipo de desarrollo, pero cual es el problema de esta representación, pues bien esta representación asegura hacer lo que hace pero puede no asegurar hacer lo que se espera que haga, para esto existe otra representación del sistema, ésta es los casos de pruebas, en los casos de pruebas también de alguna forma se describe lo que el sistema es, por lo que es otra representación del mísmo, que dependiendo de cómo se hagan pueden ser aún mejor que el código productivo de la aplicación ya que aplicando técnicas como BDD (Business Driven Developmen) pueden llegar a ser muy útiles para describir el sistema y el comportamiento esperado.

De estas tres representaciones de lo mísmo, de una no nos podemos librar (aún) que es la segunda por lo que es tiene que segur (aún) viviendo, pero entonces donde podemos aplicar DRY es en la primera y en la tercera, esto es en la forma de levantar requerimientos haciendo que el propio requerimieto sea expresado en lo que se espera que el sistema haga usando BDD y de esta forma estamos a un paso más adelante hacia automatización de pruebas y entregas continuas.

En las pruebas

Pues bien, en las pruebas como se aplica DRY... pues automatizandolas, para que chingaos queremos andar haciendo pruebas de regresión de todo el sistema (como debe de ser) de forma manual sólo por que ahora le cambiamos el color a la página de login o corregimos un bug de validacion en un campo de entrada; para este tipo de tareas repetitivas las computadoras son mucho mejor que los humanos, por lo que lo mejor es ir creando el sistema junto con los pruebas funcionales automatizadas, acá es donde entra en escena nuevamente nuestro amigo BDD.

En la construccuón

Bueno, en la vida de una aplicacion, cuantas veces tenemos que compilar, crear paquetes instalables, instalar, ejecutar pruebas unitarias, etc. pues acá es donde de nuevo decimos para que chingaus hago yo eso una y otra vez, mejor automaticemos lo mas que se pueda el proceso de construcción.

En el deploy

Pasa algo similar que en la construcción, esto es un proceso repetitivo y que difícilmente cambia cada vez que se deploya, hay que automatizarlo, mejor aún por que no nos aseguramos de que lo que construimos, el desarrollador encargado probó, la gente de qa probó, se instaló en ambiente sandbox, se instaló en ambiente de demo y por último se instaló en los 20 app servers que tenemos para la aplicación web es exactamente lo mismo? acá es donde entra el concepto de contenedores, de lo que hablaremos mas adelante.

Bien pues hasta acá DRY, espero que ahora quede un poco mas claro el concepto y que se vea su aplicación más allá del código, más adelante estaremos hablando de cuestiones mas específicas en cosas que nos encontramos en este post.