Ir al contenido

Autor: gustavo

Desarrollador de software, emprendedor y amante de la música

SCRUM: ¿Deberíamos re-estimar user stories casi terminados en el siguiente sprint?

Como parte de mis labores como Scrum Master en mi equipo me he dado a la tarea en las últimas semanas de ir armando un pequeño documento en format de FAQ o de preguntas frecuentes de manera que si alguien, incluso yo, tenemos dudas con parte de la metodología de SCRUM podamos tener respuestas rápidas y sobre todo una justificación de la decisión. A manera de ejercicio estaré publicando tips que creo son interesantes. Una de estas dudas que normalmente saltan es, cuando estimamos una historia que no se terminó en el sprint actual pero está casi terminada ¿Debemos re-estimarla?

SCRUM no es vitacilina

Entre las cosas místicas que nos han heredado nuestras abuelas se encuentran la pomada de la campana, las perlas de éter y particularmente la vitacilina. Para los que no tienen abuela, o no saben que es vitacilina, es uno de esos ungüentos que prometen aliviar prácticamente todo, al más puro estilo de brebajes y sustancias vendidas por merolicos en siglos pasados. Si bien este fabuloso ungüento posee algunas propiedades curativas para la piel, dista mucho de ser un medicamento que solucione todos los problemas dermáticos. Del mismo modo, en la administración de proyectos de software, pensar que una metodología solucionará todos los problemas es ser iluso.

De izquierdas y derechas

Pocas veces, desde tiempos post-revolucionarios, se ha vivido una polarización político-social como la experimentamos actualmente en México. Si bien siempre han existido naturalmente espectros diferentes en estos criterios al día de hoy lo que caracteriza el actual proceso electoral, además de las nada claras propuestas de los candidatos, es el desprecio de quienes se identifican en uno de estos espectros en contra del otro, pero no hablamos de políticos, hablamos de la ciudadanía.

Traducción de aplicaciones con gettext (parte 3)

En la segunda parte de este tutorial aprendimos como instalar las diferentes herramientas que utilizaremos para internacionalizar y localizar nuestras aplicaciones con gettext. También discutimos las diferencias entre catálogos, plantillas y las diferencias entre internacionalización y localización y porque es importante aplicarlas. En esta tercera y última parte haremos un ejercicio práctico para internacionalizar una pequeña aplicación de demo y localizarla en un par de lenguajes diferentes.

Traducción de aplicacion con gettext (parte 2)

En la publicación anterior vimos una introducción a los conceptos de internacionalización (i18n) y localización (l10n) y en esta segunda parte explicaré los conceptos que utiliza la herramienta gettext para permitirnos realizar dicha tarea en nuestro software además cubriré temas como la instalación y configuración de dicha herramienta. Para este demo estaremos usando Linux y PHP pero en realidad gettext y las demás herramientas que usaremos como PoEdit pueden ser utilizadas en cualquier sistema operativo y con cualquiera de los lenguajes de programación mas populares.

Traducción de aplicaciones con gettext (parte 1)

Hace unos días escribía sobre la importancia de utilizar el inglés como la lengua de facto en proyectos de software. Para mi, tener convenciones es muy importante sin embargo, como lo comentaba en la publicación del enlace, hay casos donde queremos proveer un lenguaje diferente al inglés en nuestro software y, de hecho, si nuestro target o mercado de usuarios será diferente al de habla inglesa pues esto se vuelve un requerimiento. Aunque existen varias herramientas diferentes para internacionalizar nuestro software me enfocaré en gettext en una serie de 3 artículos, siendo este el primero, para mantenerlos cortos, sobre como manejar varios idiomas en nuestras aplicaciones y mantenerlas actualizadas.

¿Por qué usar inglés en proyectos de software?

Pocas cosas me incomodan más en mi trabajo que ver un proyecto en spanglish, es decir, con partes en inglés y otras en español. La naturaleza del origen de la mayoría de la tecnología moderna hace que el inglés sea la «lingua franca» entre ingenieros, particularmente entre los que desarrollamos software, sin embargo, en México en particular, parece existir un complejo de identidad que no nos permite decidirnos por uno o por otro, o peor aun, mezclarlos terminando con resultados que dan pena.

Tu imagen sí es importante

Nunca fui particularmente seguidor de tendencias. Con temor a escucharme pedante diría que siempre he sido diferente; a mi hermano le gustaban las tortugas ninjas y G.I Joe mientras yo prefería jugar con trascabos y bulldozers. Siempre tuve una tendencia a preferir las cosas técnicas y más sofisticadas que los demás. Como muchos, estos patrones probablemente definieron no solo mi profesión sino mi personalidad.

De relojes, alarmas y distracciones

Hace algunos meses compré un reloj despertador, un hermoso marathon que se asemeja mucho a aquellos aparatos de la época de finales de los 50s y principios de los 60s. A un «Braun Americano» diría mi primo José Carlos, que también comparte mi gusto por la horología y la parafernalia americana. Me había decidido por un modelo de color negro pero pensé que sería más legible uno con «cara»  blanca. Al final del día terminé escogiendo el modelo dorado que se ve en la foto porque Yari mi esposa, que es arquitecta, tiene la última palabra en cuestiones de decoración del hogar, es como un pacto que tenemos.  Pero esta publicación no es acerca del reloj sino de la razón por la cual lo compre: liberarme de una distracción; el teléfono.

Service objects en Ruby

Uno de los errores más comunes que cometemos los desarrolladores es creer que un patrón de diseño va a solucionar todos nuestros problemas. A lo largo de mi carrera he utilizado (bien y mal) varios lenguajes y frameworks lo cual me ha permitido digamos tomar las mejores ideas de cada uno y por otra parte, tratar de no arrastrar las malas prácticas.