El titulo que importa

Ayer fue mi ultimo día en mi empleo anterior y mientras iba  caminando hacia la casa de mi  mamá para recoger mi moto iba pensando en lo que dejé ahí, una de las cosas que dejé es un producto estable el cual considero como mi hijo ya que estuve yo involucrado desde la concepción, pasando por su salida a producción, tuvo (como cualquier otro hijo) su tiempo de rebeldía en que no nos aguantó la carga gracias a la cantidad de usuarios que tenía, menosprecio de algunas personas hasta llegarlo a ver como un producto muy estable y que deja una buena cantidad de dinero a la organización, pero bueno esa es otra historia que contaré luego; otra de las cosas que iba pensando es en ¿qué le dejé a las personas?, en particular a mi tribu, a mi equipo de desarrollo, mis chavos... al final es muy difícil que yo lo diga pues eso es algo que ellos dirán o al menos lo pensarán (si algo les dejé o no) y de allí salió este post.

Hay que hacernos la pregunta ¿los títulos importan?, socialmente, me queda claro que importan, algunas veces me tocó que por que visto de tenis, pantalones rotos, cabello largo "despeinado" y barbudo como rey mago la gente no me tomaba tan enserio, hasta que por alguna razón llegan a preguntar mi puesto en donde trabajo y decía (con pena) "gerente de desarrollo" y en ese momento el  trato cambiaba, eso nunca me gustó ya que soy creyente en la igualdad y en el  valor de las personas sin importar como vistan, como se vean, donde trabajen o que puesto tienen pero algo me quedó claro, socialmente los títulos importan, lo  bueno de ser yo es que eso a mi no me importa.

Bueno pasando al tema real del post hay títulos que uno tiene solo "por que si" o por que un "tercero" te dio o por que las circunstancias así fueron como el título de jefe, el de padre, el  de marido, el de responsable del equipo de fut, cuñado, primo, hermano, etc, pero esos títulos realmente de algo sirven? o que peso tienen en nosotros y en la otra persona?. Bien pues en lo que yo creo que es mejor un título que alguien te "da" y que no tienes solo "por que si" en vez de ser jefe yo prefiero ser líder, en vez de padre yo prefiero ser ejemplo, en vez de marido yo prefiero ser su amor, en vez de el responsable del equipo de fut yo prefiero ser el líder,  en vez de ser el cuñado, primo o hermano yo prefiero ser el amigo; pero por que? por que creo que un título que te da "el segundo en cuestión" (como el título de líder) por convicción es muchísimo mas importante que el que te da un "tercero" (como el título de jefe) o el que se da solo por que así es como  se le conoce "socialmente" (como cuñado).

Por último, que peso tiene esto? bien pues lo que hace es que genera un compromiso mucho mayor y un apego  mucho mayor de las dos partes, por  ejemplo el titulo de líder hace que la gente te siga, que hagan las cosas no por que tienen que hacerla, sino por que están comprometidos moralmente contigo, porque saben que ese sentimiento de respeto y de confianza es mutua, por que lo hacen por ti y de esta forma se llega a una sinergia impresionante en que las dos partes hacen hasta donde pueden por la otra parte, por el "segundo en cuestión".

Bien pues espero que esto nos haga pensar en los títulos que tenemos en todos los ambientes en que nos desenvolvemos y queramos tener los títulos que en verdad importan.

Por cierto y ahora si ya por último, déjenme decirles que para mi el  título que mas vale, el que es muy difícil de ganarse,  pero que cuando lo tienes es lo  máximo es el título de amigo. Y a mis amigos... gracias por ello.


saludos.

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.

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

Esta vez la entrada es acerca del principio  DRY o no te repitas  a ti mismo, este principio es muy conocido, tal vez uno de los principios de los que mas se habla en el desarrollo de software pero sobre todo en el contexto del código, aunque sus aplicaciones son muchas más, de estas aplicaciones es que hablaremos en el post de esta semana.

En el código

Es el contexto mas común en el que se aplica es este principio, y de lo que se trata es de que no se tenga código duplicado, el hecho de tener código duplicado es un problema grave en el desarrollo de software ya que es muy difícil tener identificado este código en todos los lugares donde se repite y en caso de que por ejemplo se tenga algún bug en esas líneas se tiene que replicar la corrección en todos los lugares necesarios lo cual es algo difícil de hacer sobre todo si no se sabe donde se tiene repetido el código.
Normalmente lo que se hace para solucionar esto es poner el código duplicado en un método y hacer la llamada a él en los lugares donde se se tenían los bloques duplicados. Otra estrategia es dejar en uno de los dos lugares donde se tiene el código duplicado y heredar una clase de la otra y así ya las dos usaran el mismo método vis herencia, pero ojo, esta estrategia la mayoría de las veces no es la mejor ya que normalmente se rompen oros principios como "Composition over inheritance" o preferir composición sobre la herencia y "Liskov Substitution" o substitución de Liskov, los cuales esperemos abordar en entradas siguientes.
En cuanto a la detección, ya hay herramientas de análisis estático de código que son de mucha ayuda al momento de detectar cuando se rompe este principio.

En el contexto

Este tipo de "código duplicado" es un poco mas difícil de percibir y se trata de que aunque los bloques de código por sí mismos no son iguales, si tienen el mismo objetivo, con este tipo de "código duplicado" se tiene que tener mas cuidado ya que normalmente los analizadores de código estáticos no los detectan por lo que quedan más al feeling del desarrollador.
Las soluciones son normalmente las mismas que en el caso anterior.

En los comentarios

Este caso se da mucho en los desarrolladores jóvenes ya que normalmente se les enseña que tienen que "documentar" su código y que esto es una buena práctica, el hecho es que la mayoría de las veces cuando hacen esto están violando este principio ya que te estás "repitiendo a ti mismo" en código y en comentarios, lo cual no tiene caso.
Esto parece muy trivial y uno podría llegar a pensar que que payaso soy pero cual es el problema de esto, el problema es que el software está siempre en constante evolución, lo que implica es que el código cambia tan constantemente (o tal vez mas constantemente) como las veces que uno se cambia los calzones, pero cual es el problema... el problema es que normalmente no cambiamos los comentarios, por lo que el comentario se vuelve obsoleto y si uno documentó bien chingón el código con muchos detalles pues ya valió pues ahora el comentario no es fiel a lo que hace el código y esto puede llegar a causar bugs muy graves ya que quien esa ese código (api) se pede basar en la documentación para decidir su uso o no y seguramente esperará un comportamiento muy distinto al que el código al final de 10 cambios de calzones hace.
Como solucionarlo, pues documentando con comentarios lo menos posible el código y haciendo que él por si mismo revele su intención desde el paquete, nombre de clase y nombre de método. Aguas no digo que no se pongan comentarios, solo que si se ponen o se actualicen o sean algo que realmente valga la pena, por ejemplo si tiene un código que usa una estrategia de minimax para solucionar un problema pero este algoritmo es muy complejo pues vale la pena primero que el código por si solo revele su intención y tal vez documentar un poco acerca de este algoritmo.

Principios en el desarrollo de software

Los principios en desarrollo de software son ciertas características de diseño de objetos que permiten que el código sea mas expresivo y por ende mas mantenible, hay varios principios, los más conocidos son los principios SOLID, DRY y KISS, en una serie de blogs entraremos mas en detalle en cada uno de ellos, por lo pronto y de forma muy general doy una breve descripción.

SOLID acrónimo de Single Responsability (responsabilidad única), Open-Close (abierto a extensión y cerrado a modificación),  Liskov Substitution (substitución de Liskov), Interface Segregation (segregación de interfaces) y Dependency inversion (inversión de dependencias) estos son principios que aplican de forma directa en el diseño de clases para programación orientada a objetos, como comenté, mas adelante en algún post revisaremos cada uno de estos principios.

DRY acrónimo de Don't Repeat Yourself (No te repitas a ti mismo), este principio es uno de los más publicitados en el medio y su aplicación va desde una clase hasta un sistema completo, pasando por versionamiento de la base de datos y documentación.

KISS acrónimo de Keep It Simple Stupid (mantenlo simple, estúpido) es un principio también muy conocido pero que es muy difícil de aplicar ya que por naturaleza (no le encuentro otra razón) los desarrolladores somos muy perfeccionistas, pero este principio nos dice que hay que mantener las cosas lo más simple posibles y esto es desde el código, hasta el propio producto igual, pasando por la documentación y el proceso de desarrollo de software.

Estos principios son muy usados y mencionados del desarrollo usando metodologías ágiles (de las que escribiremos en algún post posterior) y es que es muy normal que en este tipo de metodologías dada su naturaleza propicien que los desarrolladores se apeguen a este tipo de principios casi de a fuerzas pero de una forma un poco sutil.

Además de estos principios se podrían mencionar también otras características del software que un buen desarrollo debe de cumplir como el hecho de que todo código productivo debe de estar respaldado por un test o prueba unitaria automatizada y ya hablando de los tests también mencionar que estos tests no deben de ser "low class citizens", es decir, estos tests son igual (o tal vez hasta mas) de importantes que el código productivo, otra característica de un buen código es que debe de ser un código limpio siguiendo ciertos lineamientos encaminados mas que nada a que sea entendible y por lo tanto mantenible.

Bueno, pues esperen próximamente posts relacionados a todo esta madre sin sentido que les acabo de decir.

Saludos.

Patrones

Originalmente en este post iba a hablar de forma muy general de patrones, principios y herramientas, pero con forme empecé a hablar acerca del primero de ellos me di cuenta que es mejor separarlos, por lo que esta vez hablaremos sólo de patrones desde un punto de vista general, no hablaremos de un patrón en específico si no mas bien sobre que es y por que es importante, pero bueno pues a darle que es mole de olla.

Patrones, seguramente hemos oído mucho del patrón mvc (que creo es que es el único que se menciona en las universidades de México) o mvvm o singleton, pero que cosa es eso y por que son patrones? pues empecemos definiendo lo que es un patrón, también conocidos como patrones de diseño, según wikipedia "Los patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.

Un patrón de diseño resulta ser una solución a un problema de diseño. Para que una solución sea considerada un patrón debe poseer ciertas características. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reutilizable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias" tomando esta definición como base un patrón es algo que te ayuda a solucionar un problema y que de alguna forma es algo genérico, por lo que para poder aplicar un patrón hay que tener un problema de diseño que se quiere solucionar y acá es a donde muchos de los desarrolladores jóvenes no les hace mucho sentido esto de los patrones, ya que las primeras veces que uno empieza a tirar código es muy difícil que identifique estos problemas de diseño (aguas, no confundir con los problemas de negocio a solucionar) ya que en su experiencia aún no se ha topado con ellos, a veces, me atrevo a decir que no solo las primeras veces que uno tira código, los primeros sistemas en que se ve involucrado o hasta en los primeros años de "profesional" (en algún otro post hablaremos sobre esta palabra) es algo difícil de identificar estos problemas de diseño, ya conforme uno se va haciendo mas huevudito en esto del desarrollo de software y empieza a saber lo que en verdad es desarrollar software con calidad es cuando le empieza a caer el veinte de lo que son los patrones y por que son importantes; pero bueno, volvamos a la definición, otra parte de ella que llama la atención es que dice que debe de ser reutilizable, es decir debe de ser de alguna forma genérica en cuanto a la solución de un problema e diseño en específico por lo que la primera vez que uno usa un patrón para resolver un problema la siguiente vez que se encuentra con un problema similar ya tiene una herramienta más para solucionarlo y debe de poder aplicar el mismo patrón con éxito.

Pues bien eso es lo que es un patrón, y ya sabemos lo primero es identificar el problema que se tiene que solucionar, como siempre hay muchas formas de solucionar un problema pero siempre algunas de ellas son mejores que otras, pero esto también depende de la situación específica en la que se esté, ahora que es lo que sigue, pues empezar a llenar nuestra caja de herramientas aprendiendo algunos patrones y éstos los empezaremos a aprender en el transcurso de esta serie de posts (intercalados con otros temas de interés en el desarrollo de software), como primer patrón ya comentamos acerca de el patrón decorador y una situación muy específica en la que se usa.

Los patrones son importantes por que ayudan a solucionar de una forma "estándar" un problema y que puede ser aplicado en muchas ocaciones dando generalmente un software con mejor diseño, por lo que será mas desacoplado, testeable y mantenible.