Fallo de la Aritmética de Fechas de ActionScript

Código del Ejemplo: Date Arithmetic Example Code.

Resulta realmente alarmante cuando un día tu código falla debido a un error que sólo puede manifestarse en una fecha concreta del año. Esas situaciones son las que te recuerdan que el maldito Murphy sigue más vivo que nunca.

Por más que lo intentes jamás puedes asegurar que incluso el código más trivial está libre de errores.

Un ejemplo de esta situación se presenta cuando en ActionScript 3.0 (y posiblemente también en JavaScript) se realiza la aritmética de fechas tal y como explica la ayuda de Adobe en ActionScript 3.0 Developer’s Guide.

ActionScript 3.0 cumple con ECMAScript Language Specification, Third Edition (ECMA-262) y también incorpora funcionalidad de ECMAScript Edition 4. Mientras que el JavaScript de la mayoría de los navegadores aun sigue basado en la primera versión de ECMAScript. Aun así ninguno de los lenguajes incluye mecanismos explícitos para realizar operaciones de suma y resta en el tipo Date.

La documentación de Adobe en Performing date and time arithmetic muestra ejemplos bastante razonables de como realizar estas operaciones.

var millisecondsPerDay:int = 1000 * 60 * 60 * 24;

// sets the invoice date to today's date
var invoiceDate:Date = new Date();

// adds 30 days to get the due date
var dueDate:Date = new Date(invoiceDate.getTime() + (30 * millisecondsPerDay));

El problema es que este código fallará en períodos en los que se ha producido el ajuste del horario de invierno o de verano (Daylight Saving Time, DST). Los objetos de la clase Date mantienen de forma automática la diferencia en minutos respecto a la hora UTC en la propiedad timezoneOffset. El cambio de hora modifica el valor del timezoneOffset, que se utiliza automáticamente en todos los métodos sin el sufijo UTC.
Sigue leyendo

¿Me creo eso del Refactoring?

La primera vez que escuché algo de metodologías Agile como Extreme Programming o Scrum, una de las primeras cosas que pensé fue:

¡Vaya una mierda que nos están vendiendo!

Esta primera evaluación de las metodologías Agile fue debida precisamente a todas esas historias de trabajar al día. Programar lo justo para cumplir. Evitar la codificación de funcionalidad futura. No perder el tiempo en la creación de arquitecturas para pretendidos frameworks reutilizables. Todo se acabará mejorando en un hipotético refactoring posterior.

 

“Keep it simple, stupid” (KISS)
“You ain’t gonna needed it” (YAGNI)
“If it’s worth building, it’s worth testing. If it’s not worth testing, why are you wasting your time working on it?”

 

Habían sido muchos años de lucha contra el Spaghetti Code, intentando evitar las anti-metodológicas prácticas del Death March o el Cowboy Coding, que es a lo que me sonaba todo lo Agile.

Harto de enfrentarme a código con chapuzas, pegotes y parches, ¿¡Me vienen ahora con unas metodologías que hace apología de todas esas prácticas!?.

Lo estaba entendiendo bastante mal, porque me habían contado a medias la verdadera práctica del refactoring.

La lección aprendida es que para que el agilismo funcione, sin lugar a dudas es vital combinar “GESTIÓN + INGENIERÍA”.

Scrum proporciona una gestión y planificación agile de proyectos. La implantación de prácticas agile en un grupo muchas veces se queda sólo en Scrum, ya que la parte de gestión y planificación es es siempre más fácil de cambiar que las prácticas de ingeniería.

Extreme Programming proporciona la Ingeniería del Software Agile. Son metodologías más complicadas de introducir, ya que requiere de expertos programadores, son prácticas que emergen de la programación y no de la gestión, que es donde suele estar el mayor poder de influencia.

 

Cuando conocí el bucle micro-incremental e iterativo de TDD, o del BDP (Behaviour Driven Programming) de BDD, es cuando realmente entendí el paradigma YAGNI y sus derivados.

 

El refactoring es vital en TDD.
Si no haces un refactoring continuo no estás haciendo TDD.
Si no haces refactoring no estás diseñando.

Usando este tipo de metodologías es como se hacen viables principios como YAGNI. Así es como se puede diseñar directamente desde el código. El código nos va mostrando el diseño y la arquitectura de nuestra aplicación.

 

El refactoring es lo que hace posible que ese framework reutilizable, esa arquitectura o ese gran diseño surja de forma orgánica, justo en el momento que se necesita. Además con la libertad de modificación y trasformación que proporcionada la amplia cobertura de los Small Scaled Tests que han dirigido dicho refactoring.

Deberíamos llamar a la metodología Test Driven Refactoring (TDR).

Me horroriza oír hablar de “la deuda tecnológica”. Este concepto no debería existir. Da la sensación de que se le ha puesto un bonito nombre a lo comúnmente conocido como chapuza tecnológica.

No deberíamos calcular la chapuza tecnológica acumulada a lo largo de los sprints para decidir si necesitamos un período de refactoring. Se trata de un refactoring que nunca jamás nos van a permitir hacer, ya que nunca vamos a tener tiempos muertos.

Los períodos de refactoring no existen porque el refactoring es continuo.

Sí, me creo eso del refactoring, pero cuando se utiliza de forma continua, incremental e integrado en un bucle de trabajo basado en Test Driven Refactoring (o Behaviour Driven Refactoring).

Entendiendo la Fotografía

Se sale bastante del tema principal de este blog, que es el Desarrollo de Software (aunque no lo parezca). Pero no puedo permitirme el lujo de tener varios blogs. Tendré que mantener en uno solo mis dos temáticas actualmente favoritas.

 

La segunda temática será acerca de: “La fotografía”.

 

Hace ya más de veinte años asistí a unos cursos de fotografía, incluyendo talleres de revelado. Desde ese momento me enamoré de ese arte. Pero a sido una pasión nunca cultivada, siempre a la espera. Demasiados hobbies. Este en concreto demasiado prohibitivo para mi nivel económico de estudiante. La cámara, los objetivos, el cuarto de revelado, la ampliadora, los reveladores, fijadores, viradores y demás artilugios.

 

La ventaja de la actual era digital, en fotografía, supone un acercamiento a cualquier usuario aficionado, aunque solo sea en el plano económico. Se abaratan enormemente los costes, al menos para un nivel de aficionado, todo un laboratorio queda sustituido por ordenador con una aplicación de edición fotográfica.

 

El impacto de lo digital en la fotografía lo describe muy bien José María Mellado en sus libros Fotografía de Alta Calidad. Nos cuenta que la fotografía se ha democratizado tanto que ahora cualquier persona conoce las posibilidades de manipulación de la imagen, unas posibilidades que han existido desde siempre, incluso en la fotografía química. La gente cree que todo lo que hacen estos programas (mal llamados “de retoque fotográfico”), son manipulaciones que deterioran el arte. No tienen en cuenta que este procesamiento de la imagen existe desde que se inventó la fotografía química allá por el siglo XIX. Pero en la era química ese conocimiento sólo estaba al alcance de pocos técnicos.

El procesamiento de la imagen fotográfica existe desde el invento mismo de la fotografía en el siglo XIX. El trabajo artístico de un fotógrafo nunca ha terminado en la captura.

La parte más dura del trabajo artístico de un fotógrafo siempre ha empezado después de la captura, en el laboratorio, con los revelados por zonas, usando cartulinas o las manos, virados y muchas técnicas más que tienen su equivalente en la herramienta de edición fotográfica.

Incluso el famoso baritado se podría considerar como un autoajuste de mejora. Es el propio papel el que permite ese aspecto tan artístico del blanco y negro.

Tanto en la fotografía química como en la fotografía contemporánea todo consiste en trucos y técnicas que permiten al artista manipular la imagen capturada para dejar su impronta creativa.

 

Tras haber mejorado mi nivel económico y estar en disposición de comprar una buena cámara seguía aparcando la práctica de esta actividad. Lo cierto es que da cierta pereza estudiarse las herramientas de procesado de imagen, a parte de que la eliminación del laboratorio parece quitarle algo de encanto. Además, todo hobby requiere un tiempo, bastante escaso, y gastarte un mínimo de mil euros para abandonarlos en un cajón no parece muy rentable.

 

Pero finalmente la ocasión se ha presentado en forma de regalo de cumpleaños, ya tengo la cámara de mi vida. Ahora tengo que sacar partido a una inversión realizada por gente muy querida.

 

Me estoy poniendo las pilas para aprender, absorbiendo todos los conocimientos posibles, ya que ahora no se nada de nada. Posiblemente este esfuerzo no me sirva para hacer buenas fotos. Aunque me pese, creo que no tengo un talento muy fotográfico, pero ya veremos.

 

Se me ha ocurrido que puedo aprovechar todo este esfuerzo de aprendizaje para ir comentando las cosas que me han costado más o menos, y así a lo mejor puedo suavizar el camino a otros que vengan después.

 

Entre las cosas que más me ha costado entender, al menos de una forma completa, está el tema de la calibración + perfilado de los monitores y gestión del color. Aunque ya hay mucha literatura sobre este tema aun sigue habiendo puntos oscuros que nadie consigue aclarar bien del todo.

Creo que ya casi he conseguido encajar todas las piezas, así que mis artículos fotográficos empezarán por esta parte.

El gurú que llevas dentro – Prólogo

Una guía para ingenieros de las TIC, informáticos, telecos y demás fauna tecnológica.

¿Que fue lo que me llevaría a elegir esta profesión?
Aun recuerdo con nostalgia esos días de antaño, con menos años sobre los hombros, cuando era joven e inocente, y me parecía que sería apasionante trabajar cada día con lo que más me gustaba.

¿Es posible que me paguen por programar? !!!Idiotas!!!
¿Trabajar haciendo lo mismo que hago ahora por diversión?

Realmente cambia la historia cuando tu afición se convierte en tu trabajo, quizás porque siempre acabas haciendo lo que piden otros y no lo que te gustaría. Aun así aun no he perdido esa primigenia pasión por la informática, en caso contrario no estaría escribiendo este blog. Entonces ¿qué es lo que hace que ahora mi mente tome estos caminos tortuosos de pensamientos nostálgicos?

 

El-GuruHe empezado a sospechar que a lo mejor existe dentro de mí un “gurú” que necesita salir y mostrarse al mundo.

Supongo que a muchos os habrá sucedido algo parecido. En alguna ocasión os habéis sentido todo unos “gurús” en alguna materia.

Pero nunca habéis oído a nadie comentar sobre vosotros mismos esa famosa frase de “fulanito es un gurú del nosequé”.

¿Por qué coño están ahora todas las empresas de las TIC a la caza de gurús si ya los tienen contratados en plantilla? ¿Es que no saben que ya tienen gurús?
¡Por la […piiiippp…] de Júpiter! ¡Que los dioses me abran de […piiippp…] si lo entiendo!

Sigue leyendo

Quiero un Scrum Master Especializado

Muchas veces da la sensación de que el rol del Scrum Master se está convirtiendo en una figura algo devaluada y fácilmente sustituible dentro de los equipos de Scrum.

Parece que el trabajo que realiza un Scrum Master es tan trivial que cualquiera puede desempeñarlo con sólo unas meras pinceladas de la metodología. He oído hablar incluso de equipos que se turnan el rol de Scrum Master de un sprint a otro (personalmente me parece anti-scrum).

No soy Scrum Master y nunca he desempeñado dicho rol.

Sólo soy un miembro más del equipo de desarrolladores, y aun así quiero revindicar la figura del Scrum Master. Trasmitir la importancia de que para vivir un buen Scrum es vital la existencia de un buen Scrum Master, con las habilidades adecuadas, y a ser posible formado y experimentado.

Es cierto que los equipos de Scrum son auto-organizados.

Aun así la figura del Scrum Master es fundamental. El trabajo que debe realizar al margen de los sprints requiere gran dedicación y esfuerzo.

A veces se simplifican las funciones reales de un Scrum Master, reduciéndolas a una mera organización y moderación de reuniones.

¿Es el Scrum Master un simple Moderador de Reuniones?

Sigue leyendo

Test Driven Development: Eliminando Malentendidos

Últimamente cuando alguien me pregunta por TDD acabo planteándome la misma pregunta:

¿Están interesados en la metodología de desarrollo llamada Test Driven Development o en realidad tan solo están pensando en codificar unos tests antes del desarrollo?

Parece una pregunta redundante ¿acaso no es lo mismo aplicar TDD que codificar tests antes del desarrollo de la funcionalidad?

Esta es precisamente la raíz de muchos malentendidos y la respuesta es un rotundo NO.

La Raíz de los Malentendidos

Cuando se habla de TDD en realidad muchas veces se está pensando en técnicas para  la automatización de tests de alto nivel (integración, sistema o interfaz de usuario). El interés que despierta TDD es el interés hacia las técnicas para la programación de tests automáticos, reduciendo TDD a un nombre de moda que aconseja programar los tests antes de escribir una sola línea de código funcional – lo que deja de lado aspectos fundamentales de Test Driven Development, que en realidad es una metodología con reglas propias.

Quizás el problema se deba a que la primera letra ‘T’ dirige el foco hacia el testing en lugar dirigirlo hacia la última letra ‘D’ del development (designing/coding).

Se confunde una metodología del equipo de desarrollo con una metodología del equipo de control de calidad (quality assurance).

Malentendido comprensible al formar parte del nombre de la metodología – esperemos que el cambio de vocabulario propuesto por Behaviour Driven Development con la eliminación de la palabra "test" evite este malentendido.

Test Driven Development es precisamente una metodología diseñada como herramienta de trabajo para los programadores.

No se trata de una metodología para el equipo de QA. Existen otras prácticas más directamente relacionadas con la QA como ATDD – además de prácticas específicas de Agile Testing.

Sigue leyendo

Los Inventores de las Citas Famosas

El otro día tomando café con los compañeros de trabajo en nuestra pausa mañanera, surgieron algunas conversaciones interesantes, como la mayor parte de las veces. En ocasiones surgen las típicas trivialidades que nos hacen pasar un buen rato, y otras veces surgen temas realmente transcendentales, tanto en el ámbito profesional como en el ámbito lúdico.

Y como otras tantas veces hubo alguna frase que no pude evitar marcar en mi cabeza como frase memorable que debería copiar y apuntarme para momentos de necesidad.

Pero esta vez empezaron a germinar en mi mente trastornada una serie de dudas existenciales.

¿Habéis visto alguna vez esas listas con citas de famosos? Supongo que sí. ¿Habéis visto lo ingeniosas que son a veces esa frasecitas? Esas del tipo “Hay dos cosas infinitas: el Universo y la estupidez humana. Y del Universo no estoy seguro — Albert Einstein”.

Sigue leyendo