Vía La aldea irreductible

Porque un país que pretende llamarse desarrollado debe invertir en su propia tecnología en lugar de comprarla fuera, y porque la ciencia debiera estar siempre por encima del ladrillo.

Llevaba ya algún tiempo con ganas de tener una lente de tipo gran angular para la cámara.
Desde que compré la D40 con el 18-55mm y el 55-200mm me he dado cuenta de que generalmente me encuentro más cómodo tirando fotos con el primero que con el segundo.
Digamos que las fotos con zoom son una gran asignatura que tengo pendiente, y en ocasiones el lente a 18 mm se me quedaba algo corto para ciertos planos.
Así que despues de leer muchas review, hacer mis cálculos y dudar mucho (pero MUCHO) entre la Sigma 10-20 o la Tonika 12-24 al final opté por la primera.

La primera impresión que me dió al sacarla de la caja fue que pesaba bastante!
El acabado es completamente diferente al de los dos objetivos Nikon que tengo, da la sensación de ser bastante más resistente y de mejor calidad.
También me sorprendió el tamaño, la D40 se queda pequeña con el lente puesto

Todavía no estoy seguro de que haya sido la decisión más acertada, pero por el momento estoy más que satisfechos con los resultados.

Aquí os dejo algunas fotos que tomé este fin de semana estrenando la lente.

Me quedan un montón de cosas por aprender con esta lente, y en cierto modo eso es lo que me gusta de las DSLR, cada lente nueva te abre un montón de posibilidades

Leer a Kafka no significa que seas inteligente.
Ser inteligente es leer a Kafka y entender lo que dice!

RafitaFx ~ Random Conversations

En la metodología de desarrollo ágil se usan varias técnicas diferentes. Si habéis escuchado algo sobre Scrum o XP, todas esas técnicas, o metodologías tienen algunos puntos básicos en común.

Aquí os voy a hablar de alguno de ellos:

• Backlog: El backlog es algo así como la “lista de tareas” que tenemos pendientes. Es el lugar donde almacenamos User Stories, Tareas y Reportes de bugs.
  Ejemplo de Backlog:

  
  Imagen tomada usando Caimito One Team

  El backlog es prioritizado por el Product Owner y los Stakeholders (clientes, usuarios finales, etc) de manera que los asuntos más importantes siempre están en la cabezera.

• Iteraciones:El motor del desarrollo ágil son las iteraciones. Ya sean de una semana, dos o tres… el desarrollo ágil tiene como uno de sus pilares fundamentales proporcionar software que funcione lo antes posible, de manera que el cliente o los usuarios tengan acceso al código que se está desarrollando.
  Podemos entender las iteraciones como “entregas”.

  Si bien esta aproximación es muy básica, nos da una idea que sí es bastante importante. Al final de una iteración el software debe estar listo para correr en un entorno de producción.

  Esto no quiere decir que lo que se entrega esté escrito en piedra, de hecho lo ideal es que el cliente pueda probar realmente el producto y proporcionar el feedback necesario para construir lo que realmente quiere.

  Un ejemplo de una iteración sería esto:

  
  Imagen tomada usando Caimito One Team

  Como podéis ver, una iteración se compone de los mismos elementos que teníamos en el backlog. Cuando los stories están listos para comenzar a trabajar con ellos y se tiene el suficiente material como para abarcar una iteración de trabajo, se genera la iteración y todo el mundo comienza a trabajar.

  Una iteración es un compromiso que el equipo de desarrollo establece con el cliente final. Se compromete a que todos esos puntos, que se han incluido en la iteración estarán listos y funcionando al final de la misma.

• User Stories: Un story es una breve descripción sobre algo que se debe desarrollar. No es tan extenso ni detallado como un Caso de Uso, en el que se listan de antemano todas y cada una de las posibles situaciones que deben estar contempladas. Más bien podríamos definirlo como una idea encapsulada en una breve frase, la cual pasará a ser desarrollada e implementada por el equipo de desarrollo.
  Una vez implementado y entregado al cliente, el story será evaluado por él y se decidirá si se requiere algún cambio adicional.

  La idea de esto es encapsular pequeñas funcionalidades que sean entendibles por los programadores y rápidamente implementables. De manera que si es necesario modificar o descartar el story no se deba emplear o se haya perdido mucho tiempo.

  Generalmente un story se compone de esta estructura:

  Siendo un [ rol ]
  Quiero que [ funcionalidad ]
  Para que [ valor de negocio ]

  
  De ahí el famoso As a… I want … so that … que seguramente ya habréis visto por internet.
  Aquí podéis ver un ejemplo de un User Story:

  
  Imagen tomada usando Caimito One Team

  Como podéis ver, el story no entra en detalles de cómo debe ser la implementación ni engloba todos los posibles casos de uso. Simplemente define un concepto de manera que el programador que vaya a trabajar en ese story tenga una idea de por donde comenzar a trabajar.
  A medida que comienza la implementación del story y surgen las dudas, el programador colaborará con el Product Owner para aclarar esas dudas, y finalizar exitosamente el story. (En el próximo post donde explicaré los roles dentro de un equipo ágil os explicaré que es esto del Product Owner, mientras tanto os puedo dar este link[ENG])

  Escribir buenos stories es todo un arte, aquí tenéis algunos consejos para escribir buenos stories. [ENG]

  En general un story debe ser lo suficientemente pequeño como para que un programador pueda realizarlo sin problemas durante una iteración, y lo suficientemente significativo como para que añada valor de negocio al producto. Es ese equilibro el que diferencia un buen story de otro no tan bueno.

  Una vez escrito el story, el equipo de desarrollo lo lee, conversa sobre él para asegurarse de que todo el mundo entiende lo mismo y procede a estimarlo. Sobre la estimación de un story hablaré algo más adelante en este post.
  Una vez ha sido estimado, está listo para ser introducido en la iteración y comenzar su implementación.

  Es importante que exista un test para cada story que se implementa. De manera que dichos test por un lado validan el correcto funcionamiento de la implementación, y por otro sirven de documentación para el mismo.
  Si al implementar un story nos vemos incapaces de realizar un test que lo cubra, probablemente estemos tratando de implementar un story demasiado grande.
  Estos stories reciben el nombre de Épicos, y deben ser subdivididos en otros stories más pequeños.

• Tareas y Bugs: Lo ideal cuando tenemos código listo para producción es que esté libre de bugs (errores), sin embargo suele ser común que existan casos para los cuales nuestro código no haya sido debidamente probado o situaciones en las que el equipo de desarrollo no haya pensado.

  Cuando se detecta un funcionamiento anómalo en el comportamiento de nuestro código se debe reportar y rellenar un reporte de error.
  Ejemplo de un Bug Report:

  
  Imagen tomada usando Caimito One Team

  De acuerdo con la idea de tener código listo para producción, al planear una iteración, todos los Bugs Reports que tenemos en nuestro Backlog, pasan automáticamente a la iteración, ya que antes de desarrollar nuevos stories es fundamental que el código que ya existe funcione correctamente.

  En cuanto a las tareas, podríamos definirlas como pequeños stories para los que no podemos realizar un test para verificar, o no tiene sentido estimarlas.

  Ejemplo de una tarea:

  
  Imagen tomada usando Caimito One Team

  Las tareas son un arma de doble filo, por su similitud con los stories en ocasiones no resulta tentador “disfrazar” stories como tareas. Tal vez para ahorrarse escribir los test, o para ahorrarse el proceso de estimación… sin embargo es importante limitar el número de tareas con las que se trabaja.
  Principalmente el hecho de que una tarea no tenga una estimación es peligroso, ya que el trabajo realizado no se refleja directamente en la velocidad del equipo a lo largo de la iteración. (hablaré de la velocidad más adelante)

• Estimación: Estimar los stories en los que vamos a trabajar no es un proceso trivial. Mucha gente asocia estimación con tiempo. Sin embargo nosotros preferimos estimar con complejidad.
  Cuanto se estima un story no se define si se va a tardar 2, 4 o 10 horas en tener el story terminado, si no cómo de complejo de implementar ese story.
  Habitualmente esta es una de las primeras cosas que chocan contra los principios del Project Management en general, ya que muchas de las compañías pagan a sus empleados por horas, y por tanto con un estimación basada en tiempos pueden saber aproximadamente cómo de caro es un proyecto.

  La experiencia empírica demuestra que este proceso está errado. En general las estimaciones basadas en tiempo suelen ser bastante inexactas, suelen “recortarse” por parte de ciertos comerciales para competir por vender un proyecto y eso devienen en un sin fin de problemas que básicamente terminan con un equipo de programadores trabajando hasta altas horas de la noche, molestos, desmotivados y sacando el trabajo como buenamente pueden.

  No hace falta ser un visionario para darse cuenta de que ese código no solo es propenso a errores, si no que un programador, trabajando en esas condiciones no puede dar lo mejor de sí.

  Estimar en complejidad, al principio resulta bastante incierto, pero en mi experiencia personal ha demostrado ser una medida bastante más fiable a la hora de saber qué cantidad de trabajo semanal soy capáz de llevar a cabo.
  Las métricas usadas dependen completamente del equipo o el software que se esté usando para estimar.
  One Team, por ejemplo, utiliza los valores: 10, 20, 40, 80, 1000000, siendo éste último el valor asignado a stories épicos.

  

  Al principio, para nuevos equipos, es bastante habitual que la velocidad del equipo (la suma de los valores asignados a los stories que se completan al final de la iteración) varíe. Pero con el tiempo, a medida que el equipo comienza a perfeccionar sus prácticas ágiles, es habitual tener una velocidad más o menos estable, permitiéndonos de esta manera, saber cuantas iteraciones nos hacen falta aproximadamente, para finalizar el proyecto (o al menos todos los asuntos que tenemos pendientes en en backlog).

Con estos conceptos básicos podemos comenzar a trabajar de manera ágil. Espero que os sirva de ayuda o de referencia para iniciaros en esta metodología

Para los que me escribís diciendo que estoy desaparecido del mapa os diré que tenéis toda la razón, así que voy a aprovechar un breve lapso de tranquilidad para escribir algunas actualizaciones de lo que he estado haciendo estos meses.

• Volví a Panamá:Si, ya se que puede sonar a masoquismo pero lo cierto es que adoro este país a pesar de lo mucho que me quejo. Aunque en esta ocasión no solo regresé por estar aquí, si no que me embarqué en un proyecto al que no me pude resistir, CaDs Tech está oficialmente colaborando con Caimito Development en varios asuntos de los que en breve podré hablar (Can’t wait)




• Ruby on Rails baby!:Adicionalmente, y a costa de varias horas de sueño (tengo unas ojeras que parezco el mismo Po) estoy desarrollando un par de proyectos basados en RoR. Uno de ellos concretamente(pendiente de comprar el dominio y por tanto no lo nombro) verá la luz en los próximos meses (hope so) y me pondré bastante pesado con el tema, así que no os molestéis en preguntar detalles en este momento porque os daré la tabarra en cuanto lo levante




• Agilizandome:He abrazado la metodología ágil para desarrollar software y en general como filosofía personal. Trabajar de manera ágil tiene sus cosas buenas y sus cosas malas. En general resumiendo diré que es la mejor manera de trabajar cuando uno desarrolla software sin haber “vendido el alma al diablo”. Pero tiene como desventaja que, en general, estas siempre ocupado!!! Asi que probablemente esa sea la principal causa por la que estoy “desaparecido” (bueno eso y mi adicción a Twitter)




• J2EE no es tan malo:He incorporado a mi repertorio práctico varias de las teorías aprendidas a lo largo de los últimos meses. Resulta que si usas los frameworks adecuados J2EE es bastante cómodo (y ágil) de usar. Generalmente este tema termina provocando una discusión sobre J2EE vs Rails. Para mi es como comparar un huevo con una castaña, así que no entro en polémicas. Sólo mencionar que Spring + Hibernate + Tapestry 5 + Maven= Good Stuff ( y con menos líneas de XML de lo que uno se imagina)




• Internet es un mundo apasionante:Cada día aprendo algo nuevo sobre la red. Hay tantos y tantos proyectos, frameworks, técnicas, y sites pululando por ahí que es imposible mantenerse completamente informado y actualizado de todo. Pero aun así me gusta tratar de mantenerme “en la cresta de la ola”. A día de hoy puedo decir que se “palpa” un ambiente nuevo y fresco en la red ( o tal vez siempre haya estado allí y es ahora cuando empiezo a sentirlo). Hay un montón de gente haciendo cosas super chulas por ahí, y eso es una gran fuente de motivación e inspiración para seguir adelante.

En general este viene siendo un torpe resumen de lo que he hecho, lo que estoy haciendo y lo que espero seguir haciendo durante los proximos años.
Trabajar “en la cuerda floja” por tu cuenta tiene bastantes riesgos y no todo es bonito.

Pero el ambientillo de una startup hace que sea mas llevadero

Como se suele decir, vuelvo por mis fueros!

Después de haber pasado un par de meses en España recargando las fuerzas he vuelto a cruzar el charco hasta mi querido Panamá.
Sé que critico bastante ciertos aspectos de este país, pero a día de hoy me siento irremediablemente atraído hasta esta tierra. Será masoquismo, o serán los retos que mi estancia aquí plantea lo que me atraen? No lo se, y por el momento no me importa.

He aprendido que, al igual que en un proceso Ágil, no se puede pensar demasiado por adelantado, si no ir caminando por la vida pasito a pasito adaptándose a lo que ésta me trae, pero sin perder de vista hacia donde quiero llegar.

Hay muchas cosas sobre las que escribir, y creo que, siempre que el tiempo me lo permita, el blog volverá a tomar un rumbo interesante.

Así que aquí estamos, nuevamente al otro lado del océano. El día amanece gris, el tráfico está imposible como cada mañana. La humedad impregna el aire que respiro y el calor comienza a levantarse, perezoso, con su eterno abrazo.

Welcome to Panama