Hacía tiempo que no publicaba un video, hoy encontré este en UngatoNipón y me ha encantado.

Dear Japan from Matthew Brown on Vimeo.

Simplemente Genial !

Alguna vez he hablado de Tommy Oshima. Es uno de los fotógrafos japoneses cuyo trabajo sigo casi a diario en su galería de flickr y uno de los que yo llamaría maestros de la luz.

Tommy es conocido por su peculiar estilo de fotografía callejera que está a medio camino del cyberpunk y un mundo onírico muy personal al cual nos deja asomarnos de vez en cuando, retratando escenas de una gran belleza pero que a la vez parecen estar “al otro lado del espejo”.

También es bastante conocido por ser el felíz propietario de un leica Noctilux 50mm f 0.95 (si, el precio que marca amazon es correcto) pero eso es otro cantar.

Bien, pues hace unos días leí una entrevista que hicieron al maestro Oshima (la cual recomiendo a todos aquellos a los que les guste la fotografía) y me enteré de que muchas de mis fotos favoritas estaban realizadas usando fotografía infrarroja.

La verdad es que no sabía nada a cerca de este peculiar estilo de fotografía, pero me puse a buscar información y lo que encontré me llamó bastante la atención.

La fotografía infrarroja consiste en usar el espectro de la luz infrarroja para iluminar nuestras fotos. Esta luz es invisible para el ojo humano, pero es emitida por todo cuerpo caliente y tiene diversas aplicaciones tanto científicas como artísticas.

The unforgettable fire by Tommy Oshima

Las fotografías realizadas con esta técnica tienen un aspecto bastante irreal, entre tenebroso y melancólico. Los árboles pierden su verdor en favor de hojas fantasmagóricas de aspecto lechoso, y los cielos se oscurecen entre lóbregos nubarrones.
O esa es la idea en general.

Podéis ver esta búsqueda en flickr para haceros una idea de qué aspecto tiene este tipo de fotografía.

Para tomar este tipo de fotos con una cámara DSLR basta con hacerse con un filtro IR, un trípode y una cámara a ser posible más o menos vieja.

Aclaro lo de más o menos vieja porque por lo que he leído, cuando más nuevo es el sensor de la cámara mayor es el filtrado que realiza el sensor con este tipo de luz, lo que se traduce en tiempos de exposición más largos.

Un filtro IR es un filtro prácticamente opaco a la vista. Deja pasar muy poca luz, por lo que si tratáis de enfocar con el filtro montado en vuestras lentes lo veréis todo prácticamente negro.

Pronto descubrí que hacer este tipo de fotografía es bastante laborioso.

Primero se debe de encuadrar la escena, luego se recomienda apagar el autofocus y dejar la cámara en modo manual, seleccionando una velocidad de obturación y una apertura adecuada a la escena que vayáis a tomar.
Esto es porque si dejamos la cámara en prioridad de apertura o en prioridad de disparo, al tener un filtro prácticamente opaco, las mediciones que hará la cámara no serán 100% correctas.
Una vez seleccionada la velocidad y la apertura enroscáis el filtro a vuestra lente con mucho cuidado de no mover el encuadre y click!

Obtendréis una preciosa foto roja!

La luz que pasa por el filtro es de color rojizo, dependiendo del sensor (los hay que están preparados especialmente para este tipo de fotografía) podréis captar más o menos tonalidades de colores, pero al menos en mi caso, las fotos salen rojas.
Nada que no se pueda arreglar con un poco de edición.

Misma foto pasada a B&W y con el contraste ajustado.

Esta foto es literalmente mi quinto disparo usando este filtro, y si bien da más bien algo de lástima, se puede apreciar la suavidad con la que se comienzan a difuminar las formas de los objetos y lo mucho que cambia el paisaje con este tipo de luz.

Como todo en la fotografía, la práctica hace al maestro. Es importante experimentar con diferentes combinaciones de apertura y tiempo de obturación hasta encontrar poco a poco el toque que más se ajuste a vuestro estilo.

Ahora bien, si queréis ver el verdadero potencial de la fotografía infrarroja, os recomiendo que visitéis la coleción Mes nuits sont plus belles que vos jours (mis noches son más hermosas que tus días), donde podéis ver al Maestro Oshima haciéndo básicamente lo que le da la gana con la luz.

Toda una fuente de inspiración

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