viernes, 26 de agosto de 2016

Algunas funciones útiles en javascript

Esto de cambiar de trabajo es muy interesante, la verdad es que uno está acostumbrado a cierto ritmo y al cambiar de trabajo tu día cambia mucho desde tomar otra ruta para llegar a la oficina, levantarte en un horario distinto hasta conocer gente distinta, reencontrarte con los antiguos camaradas, regresar a programar activamente y bueno pues como en todo encontrar problemas distintos a los ya habituales, un ritmo de trabajo distinto, un negocio distinto y cosas nuevas por aprender.

Dentro de estos cambios me ha tocado entender AWS, lo que ofrece y como manejar lo que tiene (en mi primer semana instalé dos veces en producción), algo de spring que ya tenía un poco empolvado y lo que más me ha costado, reencontrarme con los html, javascript y css, esos fueron mis amigos en mi primer trabajo hace mas o menos 10 años y desde entonces no me había tocado trabajar activamente en el front end de aplicaciones web de esta manera pues en Tralix me la pasé más con GWT, un poco de echo2 y muy poco de struts.

Y como parte de mi aprendizaje he estado viendo algunas cosas en javascrip que me llamaron la atención, en particular las funciones find, filter, map y reduce (que aún no he ocupado pero que ya son parte de mi toolbox) y de esas funciones es de lo que quiero hablar en este post. Comencemos con el arreglo definido de la siguiente manera:

mascotas = [
{
'nombre'  : 'max',
'especie' : 'perro',
'raza'    : 'dálmata',
'edad'    : '3',
'sexo'    : 'macho'
},
{
'nombre'  : 'yoshina',
'especie' : 'perro',
'raza'    : 'dálmata',
'edad'    : '5',
'sexo'    : 'hembra'
},
{
'nombre'  : 'luneta',
'especie' : 'perro',
'raza'    : 'dálmata',
'edad'    : '4',
'sexo'    : 'hembra'
},
{
'nombre'  : 'simba',
'especie' : 'perro',
'raza'    : 'dálmata',
'edad'    : '1',
'sexo'    : 'macho'
}
]

Find

La función find nos sirve para encontrar un elemento en un arreglo, por ejemplo si queremos encontrar a max dentro del arreglo lo que tenemos que hacer es:

max = mascotas.find(function(mascota) {
return mascota.nombre == 'max'
})
console.log(max)

y lo que nos va a imprimir en la consola es a max.

Filter

La función filter la usamos para obtener un sub arreglo del arreglo original, por ejemplo si queremos encontrar a todos nuestros perros machos lo que tenemos que hacer es:

machos = mascotas.filter(function(mascota) {
return mascota.sexo == 'macho'
})
console.log(machos)

en este caso nos imprimirá en la consola un sub arreglo conteniendo a max y a simba.

Map

La función map se usa cuando queremos transformar un arreglo en otro, esta es una función muy útil cuando se trabaja en un cliente de servicios REST ya que normalmente lo que el servicio nos trae son cosas generales y tal vez nosotros no queremos operar sobre todos los datos, sino sobre sólo algunos, espero esto no sea confuso, pero bueno, para que quede mas claro vamos a transformar nuestro arreglo de mascotas en un arreglo de edades de la siguiente forma:

edades = mascotas.map(function(mascota) {
return mascota.edad
})
console.log(edades)

Lo que nos imprime en la consola es el arreglo de las cuatro edades de nuestros perros (transformamos un arreglo de mascotas a un arreglo de edades).

Reduce

La función reduce normalmente la ocupamos cuando queremos generar un "sumarizado" o un resultado "agregativo" (jeje no supe como decirlo) sobre un arreglo, para que sea mas claro veamos el ejemplo:

cachorros = mascotas.reduce(function(total, mascota) {
if (mascota.edad <= 1)
return total +1
else 
return total
}, 0)
console.log(cachorros)

la salida a la consola que obtenemos es la cantidad de cachorros que hay en nuestro arreglo (los que son menores o igual a 1 año de edad), y la forma en que opera es que va iterando el arreglo, para cada elemento checa la edad de la mascota y si es un cachorro suma 1 al total, por cierto ese 0 "cero" extraño que se ve al final de la llamada a la función reduce es el valor inicial del total.

Lo bonito de esto es que muchas de estas funciones existen dentro de prácticamente todos los lenguajes funcionales y nos ayudan no solo en la programación del front end en javascript.

Otra cosa a hacer notar es que todas estas funciones reciben como uno de sus parámetros una función, esto las hace muy poderosas y reusables ya que por ejemplo si quieres obtener a los adultos (en el ejemplo del reduce) lo único que tienes que hacer es cambiar a función que recibe el reduce como parámetro, lo que se hace es sacar la función a por ejemplo:

cachorros = function(total, mascota) {
if (mascota.edad <= 1)
return total +1
else 
return total
}

y tener otra función:

adultos = function(total, mascota) {
if (mascota.edad > 1)
return total +1
else 
return total


y pasar uno u otra al reduce:

numero_cachorros = mascotas.reduce(cachorros(total, mascota), 0)

o

numero_adultos = mascotas.reduce(adultos(total, mascota), 0)

Con esto se ilustra una de las bondades de la programación funcional, el poder enviar funciones como parámetros.

Este post nos sirve como capítulo introductorio a la programación funcional, de la que estaremos hablando poco a poco.

sábado, 6 de agosto de 2016

Single responsibility principle (parte 2)




Esta es la segunda parte de mi post sobre SRP, en la primer parte comentamos que es y una de las formas en que nos afecta, esta vez hablaremos de otra forma en que nos afecta y veremos algo de código, así que agaaaarrrrrrense...

Primero una de las cosas que hay que tomar en cuenta es que el software y en particular las clases en POO son una representación del negocio, por lo que es una forma muy habitual de "encapsular" ese negocio el crear una clase por ejemplo EmployeeBusiness en donde se mete todo lo que tiene que ver con el empleado, a simple vista esto es correcto ya que coo decimos, representa el negocio, pero el problema es que lo estamos viendo desde el punto de vista de la entidad y ahí es donde esta jodido este asunto, que va a pasar con esta clase?

1. Va a crecer enormemente dado todas las operaciones que se pueden hacer con el empleado.
2. Va a tener un montón de dependencias por lo que se corre el riesgo de un alto acoplamiento.
3. Va  tener muchos motivos por los cuales puede cambiar, y acá es donde se rompe este principio.

Pero entonces como CREO YO que se deben de hacer las cosas? bien, pues afectivamente separar bien las cosas de acuerdo al negocio, por ejemplo una clase para manejar las vacaciones del empleado, otra para el cálculo de su nómina, otra para cuando se da de baja y así, como se dan cuenta la separación es efectivamente por negocio y nos damos cuenta ya que cada una de estas clases tiene un "stakeholder" específico y no necesariamente el mismo, por ejemplo la gente de RH es el "encargado" de las modificaciones a las reglas de vacaciones, la gente de nómina es el "encargado" de las modificaciones a las reglas de cálculo de nómina y así sucesivamente. Así tendremos las siguientes características en cada clase:

1. Se hacen pequeñas ya que cada una sirve a un propósito my específico.
2. Las dependencias disminuyen al sólo tener las necesarias para realizar su trabajo.
3. Sólo tiene un motivo por el cual va a cambiar y no sólo un motivo, sino un solo rol que dicta que cambia cómo y porqué.
4. Es mucho más fácil de probar.
5. Cumple con una alta cohesión.

Un ejemplo de este principio lo pueden ver en mi post de patrón decorador para validar en el que las responsabilidades están muy bien definidas y son totalmente independientes cada una de las clases.

Ya se que les prometí código en este post, pero creo que la explicación es lo suficientemente buena como para convencerse de que vale la pena que nuestras clases cumplan con este principio y les dejo la liga mi post donde pueden ver la aplicación de una forma muy clara y sencilla.



sábado, 23 de julio de 2016

Single responsibility principle (parte 1)

Este es el primer post para comentar a cerca de los principios SOLID, en esta ocasión nos enfocaremos en el principio de Single responsibility o Responsabilidad única (la S en SOLID), como ya comentamos en un post anterior los principios de son ciertas características (de diseño) que el desarrollo de software orientado a objetos debe de cumplir para que se diga que está bien estructurado y que ayuda a que el codigo sea entendible y por ende matenible, así que eso es lo que abordaremos en este post enfocandonos al principio de responsabilidad única.

Bien se dice por alli que el que mucho abarca poco aprieta, pues bien, esto llevado a la programación orientada a objetos es éste principio, en el que se describe que una clase debe de tener una única responsabilidad y no más que esa, como nos damos cuenta de que nuestra clase cumple con ella? pues esto es coo muchos dice, cumple con ella si es que tiene una única razon por la que tiene que cambiar, si es así entonces se dice que tiene una sola razón de ser y si esa razón de ser cambia por alguna razón entonces la clase debe de cambiar, pero sólo por eso deber de hacerlo.

Ahora este principio no solo se refleja en clases, sino en métodos, variables, paquetes, componentes y hasta sistemas, como es esto? pues bien, una variable debe de existir para solo una cosa, esto nos lleva a un buen nombramiento de la variable y esto es parte de clean code, esto es si se tiene una variable por ejemplo nombrada x que es de tipo Integer, en si el nombre no nos dice nada, por lo que estaremos tentados a usarla para lo que se nos antoje dentro de nuestro sistema, pudiendo usarla para almacenar la edad de un empleado, como índice para iterar el arreglo de percepciones del empleado (lo bueno es que ese arreglo no es muy grande jeje), etc. esto nos lleva a problemas muy graves de mantenimiento del código, lo que provoca que existan bugs, lo que provoca que nuestros clientes se quejen de lo que hacemos, lo que provoca que la empresa pierda dinero (o reputación), lo que provoca que se pierda la confianza en el desarrollador, lo que provoca que nos despidan, lo que provoca que nos atrasemos en el pago de nuestro lujoso carro (que sacamos a crédito augurando una buena carrera) lo que provoca... bueno, creo que ya di a entender el punto y todo esto por nombrar mal una variable, pero que pasa si a esa variable le nombramos employeeAge, pues ya sabemos que esa variable representa a la edad del empleado y estaremos menos tentados a usarla para almacenar algo distinto a la edad del empleado.

Si se dan cuenta, esta variable tiene una única responsabilidad que es almacenar la edad del empleado, ahora, esto aplica igual para métodos, éstos tambien deben de tener una única responsabilidad, por ejemplo el método que calcula los dias de vacaciones que tiene un empleado, esa es su responsabilidad, no la de ir a la base de datos por las reglas de vacaciones configuradas por el departamento de RH, ni ir a la base de datos para obtener la fecha de ingreso del empleado, este método sólo debe de hacer el cálculo y ya, no más que eso, en cuanto a una clase, pues como ya lo han de intuir, aplica igual ya que ésta solo se debe de encargar de algo en específico y delegar lo más que se pueda a otras clases que podrá usar o desde las que podrá ser usada para lograr un objetivo más general, en paqutes pasa lo mismo por ejemplo un paquete que tega las clases necesarias para la sección de nómina de los empleados que incluye clases para el cálculo, para extracción de datos, excepciones probables y demñas cosas que tienen que ver con la nómina, mas arriba, al sistema completo, que tiene que tener una resposabilidad única que es manejada por la gente de negocio de nuestra organización.

Últimamente se ha escuchado mucho sobre los microservicios, ellos son un ejemplo de responsabilidad única a nivel de deployable y de sistema pues de lo que se tratan es de que cada parte sea los mas independiente posible y tiene una responsabilidad muy específica llegando incluso a ser instalada de forma independiente a las demás características del sistema completo, teniendo su propia base de datos, su propio ambiente, tal vez hasta estar hecho en un lenguaje distinto a los demás y estar instalado en un servidor virtual en la india.

Pues bien, hasta acá le dejamos en la primer parte del Single responsibility principle, espero que se haya entendido de que se trata y que se puede extender mas allá a sólo clases.

En el siguiente post hablaremos de forma mas puntual de este principio con código de ejemplo y toda la cosa.

domingo, 10 de julio de 2016

La meta

Hace tres semanas tenía pensado escribir acerca de La meta (el libro que acababa de leer) pero al empezar a escribir vi necesario decir cómo es que ese libro llegó a mi y eso me llevó a escribir sobre el reto que me había puesto de 1 libro por mes, así que borré lo poco que tenía y empecé a escribir acerca del reto, luego pensé que era difícil que entendieran ese reto si no hay un contexto, así que decidí empezar dando ese contexto y borré lo poco que tenía del reto y así fue que salió el post de la lectura, luego, la siguiente semana no escribí debido a que anduve algo enfermo de la garganta y luego la semana pasada acabó mi ciclo en Tralix, por lo que decidí escribir un poco sobre unos pensamientos que me llegaban mientras me alejaba del lugar que fue como mi hogar por poco mas de 8 años. Así que ahora si... hablaremos de "la meta".

La meta es un libro que llegó a mí por que Ana me lo recomendó, en ese momento dije "va, solo acabo el que tengo ahorita leyendo, luego el que tengo ya formado y ya luego lo empiezo, pero va..." así fue, terminé el libro 1 de caballo de Troya, luego the pragmatic project automation y empecé con la meta, cabe mencionar que tengo la mala maña de que cuando empiezo un libro lo leo desde la portada hasta la contraportada y me llamó la atención el tipo de comentarios que ponían en las primeras secciones, eso me dio curiosidad y ánimo para leerlo.

Solo haré un pequeño resumen del contenido, los que están en Tralix pueden ver con Ana si lo tiene disponible para préstamo, los que no, lo pueden conseguir en Amazon el el título de "LA META" o "THE GOAL" (para la versión en inglés). Este libro cuenta una "novela", donde se narran 3 meses de la vida del encargado de una planta manufacturera que a su vez es esposo, padre e hijo, que como muchos de nosotros tiene problemas por todos lados, es decir, ya no ve lo duro, sino lo tupido, Alex es en cargado de una planta desahuciada a desaparecer dados los malos resultados que da a la compañía, estos problemas acarrean a Alex a problemas con su pareja, de la que se separa por un tiempo, al inicio no sabe que hacer para salvar la planta hasta que recuerda una plática con su ex profesor de física de la universidad acerca de "la meta", luego él junto con algunos compañeros de trabajo y con ayuda de Noha (su ex profesor) van viendo cuales son los problemas de la planta y van viendo como solucionarlos llegando al final a ser una planta exitosa y Alex a ser ascendido, pero lo interesante no es esa parte de la novela, sino los conceptos que se describen y como llegan al éxito, así como el cambio de paradigma que proponen y es de esto de lo que me gustaría hablar en este post.

Primero, al leerlo me vi reflejado en Alex por que su vida personal reflejaba la mía de hace unos años y que creo que la mayoría de nosotros tenemos cuando tenemos que dedicarle tiempo al trabajo que debería de ser dedicado a nuestras familias y que llegas a la casa y en tu mente están los problemas del trabajo, buscando soluciones y no dejando disfrutar la vida fuera.

Luego habla sobre la meta de una compañía que es muy difícil de captar pero que al final de cuentas es ganar dinero, bajo eso como meta cada compañía tiene una forma distinta de llegar a ganar dinero, es allí donde se ve la dirección, las estrategias de cada sección, todo enfocado hacia eso, por lo que lo que sea que se haga debe de estar encaminado a esa meta, pero el problema es que muchas veces la forma de esa estrategia no es la adecuada, en el caso de la compañía de Alex, miden la productividad por sección, lo cual como se ve allí no es lo mejor, lo mismo pasa en muchas otras empresas, incluidas las de desarrollo de software donde a leguas se ve que no es la mejor forma de medir, ya muchos en ésta área han escrito de esto, llegando a estar de acuerdo en que la productividad de un desarrollador no se basa en las líneas de código que genera, o el tiempo que pasa sentado frente a su monitor, o la cantidad de bugs que resuelve, ni siquiera en la cantidad de features que genera... se debería de basar en la cantidad de dinero que ese nuevo feature le entrega a la compañía o en la cantidad de dinero que al solucionar el bug le está ahorrando a la compañía, es decir, en el valor de negocio EFECTIVO. Es aquí donde el concepto de contabilidad de costos tuerce el rabo, ya que no mide de esa forma, sino (en el caso de desarrollo de software) a cuanto tiempo le dedicas a solucionar un bug o a que hay mas? bugs o features? y eso  al final no es una métrica que ayude a "la meta".

Otro concepto interesante que mencionan en el libro es la fluctuación estadística, que es la variación que hay en hacer una tarea, por ejemplo el empleado A tarda 5 minutos en hacer una tarea, mientras que el empleado B tarda sólo 3 y el empleado C tarda 6, la fluctuación estadística es esa variación, que en manufactura puede llegar a ser algo estándar y controlable de alguna manera, pero en desarrollo de software es enorme debido a que es un proceso mas artesanal, intelectual, de feeling que un proceso mecánico, acá otro problema en el manejo de las empresas de software donde para hacer una tarea se piden tiempos fijos, escritos en piedra y firmados con sangre y que la gente administrativa, los vendedores, los directores no entienden y no ven como es posible que esas fechas nunca se cumplan teniendo que jugar con el triángulo de alcance, calidad y recursos, hay una corriente dentro del desarrollo de software que precisamente trata de atacar esto, que es no estimation.

Por último quiero mencionar otra idea interesante que se trata en el libro, que es que en términos de la meta, no necesariamente todos los recursos deben de estar produciendo todo el tiempo, de hecho esto es contraproducente... en términos de la meta, esto es, a veces (la mayoría de las veces) para llegar a la meta es muy recomendable que hayan recursos (materiales, maquinaria, equipo) y personas sin hacer nada, holgazaneando, echando la hueva, yendo a fumar, viendo los partidos de la euro, etc. esto por qué? por que de no ser así se causa un sobre inventario o una sobre carga inmanejable en ciertas secciones; esto, de nuevo, es algo que los managers no entienden y es uno de los cambios culturales más difíciles de hacer, ya que estamos acostumbrados a siempre tener a la gente ocupada (aunque no sea beneficioso en términos de la meta), haciendo algo, por que?, pues por que les pago por 8 horas de trabajo y no quiero obtener menos que eso, a esto le llamamos horas nalga, es decir, lo importante es que estés sentado frente a tu escritorio, pero como lo dice el libro y el sentido común, esto no es lo mejor, ya que si no ayudas a la meta, no tiene caso que lo hagas, por lo que lo mejor es que las cosas que se hagan estén bien pensadas y hay que aprovecharlas al máximo en términos de la meta. Acá en desarrollo de software esto se acrecienta aún más por que no sólo es que a veces es necesario que la gente no produzca, sino que como ya comentamos antes, es una actividad más parecida al arte que a otra cosa y esto implica que se debe de tener un ambiente adecuado para que fluyan las ideas y que el estado de ánimo sea el mejor para poder logra este fin, esto es, si es necesario que vean un partido de la euro para que el estado de ánimo sea el adecuado... hay que poner el partido de la euro y permitirles que lo vean sin problemas, pero esto, de nuevo, es un cambio cultural en el manager muy difícil de tener.

Ahora sí, por último, me llamó la atención cómo fue que Alex y su equipo se ganaron a un cliente muy importante, ofreciéndole entregas en partes de su pedido, con lo que pudieron cumplirle al cliente, ganaron dinero, se ganaron al cliente y le ahorraron dinero al cliente en inventarios, si, así es, hicieron sprints y entregas continuas, tenían reuniones de mejoras continuas, se enfocaban en darle valor al cliente ¿les suena?, así es, era algo muy similar a ágil, por lo que en la industria también funciona ( de hecho también existe esa corriente como "lean manufacturing").

En verdad les recomiendo ese libro, vale mucho la pena, como novela, como proceso de producción (introduciendo la teoría de las restricciones) y para los que estamos dentro del desarrollo de software, como marco conceptual del desarrollo ágil.

PD: Anita, muchas gracias por prestarme el libro, espero que cuando leas management 3.0 te sigan haciendo clic las ideas de la meta.

sábado, 2 de julio de 2016

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.

domingo, 19 de junio de 2016

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.

domingo, 12 de junio de 2016

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.